インフラエンジニアの光野(@kotatsu360)です。 今週のテックブログは豪華二本立てでお送りいたします。 一本目はバックエンドエンジニアの木曽による「福利厚生を使ってAWSソリューションアーキテクト アソシエイトを取得しました」でした。 二本目はUserData、OpsWorks、Lambdaを組み合わせ、常に新鮮なSpotFleetインスタンスでサービスを運用するという取り組みについて紹介させていただきます。 なお、本記事は先日開催されたX-Tech JAWS 【第2回】~9割のX-Techと1割の優しさで切り拓く未来~での登壇資料を補足するものです。適宜スライドを取り上げて説明をいたします。 キーワード:EC2 SpotFleet、AWS Lambda、UserData、Apache Mesos ネットワーク概要 弊社が運営するIQONは、独自のクローラーを用いて契約済みECサイ
こんにちはフロントエンジニアの茨木です。一ヶ月ほど前からSwiftでiOSアプリ開発をやっています。iOS開発経験は浅いですが、Lottieというライブラリを使用し、いきなりアニメーションごりごりの画面を担当してみました。 LottieはAirbnb社が開発したライブラリで、僅かなコードでアニメーションを実装できるスグレモノです。 本記事では、SwiftにおけるLottieの使い方を説明します。 Lottieの特徴 Lottieの最も大きな特徴は、Adobe After Effectsで出力したアニメーションデータをそのまま読み込むだけでアニメーションを実装できることです。その為、沢山のコードや画像が不要なのはもちろんのこと、デザイナーが作ったアニメーションを忠実に再現することが可能です。更に、LottieはAndroidやReact Nativeもサポートしているので、クロスプラットフォ
VASILYのiOSエンジニアにこらすです。最近、Swift Evolutionに私の2つ目の提案がマージされました。 今回は、Swiftで型にExtensionを作る特殊な方法について説明します。 今回紹介する方法を使ってExtensionを作ると、名前空間が切り分けられ、コードの読み書きがしやすくなります。 ブログを書くに当たって、この Extension 実装方法を研究しましたが、この手法の正確な名前がわからなかったため、この記事では「Targeted Extensions」と呼ぶことにします。 Extensionについて 通常、 Extensionを書くとき、String なら下記のようになります。 extension String { var count: Int { return characters.count } } "hello".count // 5 Extension
こんにちは、Androidエンジニアの堀江です。最近はiOSのプロジェクトに参加してSwiftを書いています。新しいことを始めるのは楽しいですね。 ところで今ご覧になられている弊社の技術ブログ「VASILY DEVELOPERS BLOG」は、VASILYのエンジニアが交代で更新しています。記事に何を書くかは各エンジニアの裁量に任されていますが、公開前に社内でレビューをするようにしています。 レビューをする際には、以下のような点に注意しています。 誤字脱字・文法上の間違いが無いか 間違った情報が無いか 文章中にわかりにくい表現や解説が無いか このうち、誤字脱字・文法上の間違いは、文章校正ツールを使うことで機械的にチェックすることが可能です。それによって、文章そのもののより本質的なレビューに時間を割くことができます。記事はレビュー前に文章校正済みであるのが理想ですが、実際には忘れる事も多いで
こんにちは、バックエンドエンジニアの塩崎です。 先日、VASILYバックエンドチームにインターン生が来てくれました。 この記事では彼がインターンで作ってくれた機能や、インターン中のスケジュールなどを紹介します。 インターンに来たのはこんな学生 インターンに来たのはこの春に大学4年生になったばかりの、柴犬大好き系エンジニアのT君です。 好きな言語はClojureというなかなかギークな学生さんでした。 インターンに来てもらう前に提出してもらった事前課題では、コードの綺麗さが光っていました。 この課題はRuby on Railsで「とあるお題」に従ったWeb APIを作るものなのですが、Rubyでありながら変数の再代入を嫌う傾向はさすが関数型に慣れているだけのことはあるなと感じました。 やってもらったタスク 目標 今回のインターンでT君にやってもらったタスクはMySQLからBigQueryのデー
わーい!コンテナたのしー!🐾 こんにちは。流行りには積極的に乗っていきたい。インフラエンジニアの光野です。 弊社が運営するファッションサイトIQONでは、日々200以上の提携ECサイトから100万のオーダーで商品をクロールしています。 新商品の追加・商品の在庫状況・セールの開催など情報は日々変化するため、弊社において「正しくクロールすること」と「速くクロールすること」は肝心カナメの要素です。 本記事では、特に「速くクロールする」という目的で構築したコンテナベースの新クローラーシステムを紹介いたします。 このクローラーシステムは、最終的にクロール時間67%減、 維持コスト70%減という成果が得られました。 キーワード: コンテナ, Docker, Apache Mesos, Marathon, AWS Lambda, Amazon EC2 SpotFleet 問題解決手段の検討 -> コン
こんにちは、バックエンドエンジニアのじょーです。大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すA
iOSエンジニアの庄司 (@WorldDownTown) です。 最近、業務で新しいiOSアプリを立て続けにいくつか開発する機会に恵まれました。 そんな中、いくつもアプリを使っていると、どのアプリでもよく使う処理があぶり出されてきます。 そういう処理はSwiftのExtensionとして別ファイルに書き出し、他のアプリへも切り出しやすいように個別のFrameworkにして管理しています。 Frameworkの管理については過去のこちらの記事を参考にしてみてください。 今記事では、最近の開発でよく使ったExtension集をご紹介します。 Swift標準ライブラリ Date private let formatter: DateFormatter = { let formatter: DateFormatter = DateFormatter() formatter.timeZone = N
2017年2月末、IQONのロゴやアイコンが新しく生まれ変わりました。 ただ単に見ためやイメージを変えたいという目的ではなく、新機能リリースとともにコンセプトから見直したリブランディングを行い、それを元にチームで磨き上げて完成させています。 これからもユーザーに愛されるサービスへと進化させていくために、私たちがどのような想いを込め、どんなプロセスを経てIQONのリブランディングを行ったのか、そして新しくなったロゴについてもご紹介いたします。 リブランディングの経緯IQONはサービス開始から約5年の間、ロゴのリニューアルを1度行っています。 当時もサービスの方向性や規模に合わせての変更でしたが、時が経つにつれ、時代にフィットしつつ今のIQONの価値や思想が表現できているロゴとは言い難くなっていました。 IQONロゴの変遷これからも愛されるサービスで居続けるには、サービスの方向性や価値を見直し
こんにちは、バックエンドエンジニアの塩崎です。 今まではiQONの全文検索用のインデックスには形態素解析だけを用いていましたが、先日Ngramも併用することで検索を改善しました。 その結果、検索結果のヒット数が向上し、なおかつ検索ノイズの増加を軽微なものに抑えることができました。 この記事では、Ngramを併用することのメリット、およびそれをApache Solrで利用する方法について紹介します。 欲しい情報が見つからないとは そもそも、「検索したけど欲しい情報が見つからない状態」とはどのような状態でしょうか? ここではその状態を以下の2つの状態に分解して考えてみます。 欲しい情報の数が少ない 1つ目の状態は「欲しい情報が検索結果中に少ない」状態です。 例えば、旅行情報サイトで「東京」と検索した時にDBの中には数千件のデータがあるのに検索結果数がわずか数件しかないような状態です。 欲しくな
データサイエンティストの中村です。今回はイメージファーストなファッションアイテム検索システムを作ってみたのでそちらの紹介をしたいと思います。 本記事で紹介する技術はIBIS2016でも報告しています。 概要 ファッションアイテムを探すとき、見た目の印象はとても大事な要素です。ファッションは感覚的なものなので、自分が欲しい服について言葉で説明することは難しいですが、そのアイテムの良し悪しは画像を見ただけで判断できるからです。 今回開発した検索システムは見た目の印象を大事にしたいので、画像をクエリとします。ただし、ただの画像検索では面白くないので、色や形状などの属性情報を付加した状態で検索を実行できるようにしました。 例えば、「シルエットは良いんだけど、これの赤いやつが欲しい」のような感覚的な注文を、以下のGIFのように画像に属性を付加する形で拾っています。 よくある検索システムではカテゴリに
iOSエンジニアの庄司 (@WorldDownTown) です。 iOS 10.1 のリリースから遅れること3日、Xcode 8.1 がリリースされました。この Xcode 8.1 では Swift のバージョンが 3.0.1 にアップデートされています。 iQON の iOS アプリでは、Xcode 8 リリース後すぐに Swift 2.3 へのアップデートは済ませたのですが、最近 Swift のバージョンを 2.3 → 3.0.1 にアップデートしました。 本記事は、作業中に対応したエラー修正の記録のようなものです。とても長くなっていますが、Swift 2系 → 3系にアップデートするときの手助けになればと思います。 モチベーション 現在も引き続きSwift 2.3 で開発を続けることはできますが、いずれは Swift 3.x 系へアップデートすることになるでしょう。 一方、 Real
データサイエンティストの中村です。VASILYではファッションに特化した画像解析エンジンを開発しています。本記事では、スナップ写真からファッションアイテムを検出するシステムを紹介したいと思います。 概要 このシステムの入力はスナップ写真です。スナップ写真が入力されたとき、システムは以下のタスクを解きます。 写真中からファッションアイテムに該当する領域を検出する 検出したファッションアイテムのカテゴリを予測する 検出したファッションアイテムに似ているアイテムをDBから検索する 各タスクを解く方法は様々ありますが、弊社のシステムでは2種類のネットワークを使ってこれを達成しています。 ファッションアイテムの検出とカテゴリ予測 検出は画像認識の基本的なタスクで盛んに研究されていて様々な手法が提案されていますが、今回はSingle Shot MultiBox Detector (SSD)*1 と呼ば
こんにちは、データチームの後藤です。この記事では、一般物体認識で優秀な成績を収めた代表的なニューラルネットワークモデルを、ファッションアイテムの画像データに対して適用し、どのアーキテクチャが有用か、どれだけの精度を出せるのかを調べる実験を行います。 今回は、 AlexNet Network In Network GoogLeNet DenseNet の4つのアーキテクチャを試しました。 背景 iQONでは毎日500以上のECサイトをクロールし、一日平均1万点もの新着アイテムを追加しています。この過程で、新着アイテムがiQONのどのカテゴリに属するのかを決める必要がありますが、この作業を人手で行うと膨大なコストになってしまいます。この問題に対して我々は、アイテムの名前や説明文、画像データを活用してカテゴリを判別する仕組みを作りました。とくに画像データによる判別には、畳み込みニューラルネットワ
こんにちはVASILYエンジニアの松本です。VASILYではクローラーの仕組みを大幅に見直した際にDynamoDBの導入を行いました。今回はその導入方法とDynamic DynamoDBを用いた運用方法について話したいと思います。 DynamoDBを導入した理由 iQONではクローラーで取得したデータをDynamoDBに保存しています。DynamoDBを導入した理由は以下の通りです。 ・ ECサイトごと、さらには商品ごとにクロールするデータの形式が異なるためスキーマレスである必要があったこと。 ・ DynamoDBはデータベース容量が増大した際も自動でスケールしてくれるのでメンテナンスコストがかからないこと。 ・ 平均レイテンシーは1桁台のミリ秒単位であること。 iQONでは1日約80万点のアイテムをクロールしているので、メンテナンスコストがかからず、ある程度のパフォーマンスが担保できるこ
はじめまして。バックエンドエンジニアの吉田です。 2013年5月末の入社以降、大量のEC2インスタンスのVPC移行を担当した後、今はiQONの商品DBを支えるクローラーの改善に取り組んでいます。今回はその改善の1つとして開発したRedis::DistMutexという分散ロック機構のruby実装を紹介をしようと思います。 Redis::DistMutex 開発の経緯や細かい設計の話は後述するとして、まずはつくったgemの紹介をします。 Redis::DistMutex Redisベースの分散ロック機構 rubyのライブラリにあるMutex互換 スレッド間だけでなく、プロセス間・ホスト間でも共有できるMutex 時限つきロックの作成が可能(redisのsetnxとexpireを活用) namespaceを指定できるので、特定の処理ごとにロックの作成が可能 redis2.6以上のみサポート(1秒
こんにちは、VASILYエンジニアの塩崎です。 今回はiQONを支えているクローラーの並列処理について紹介したいと思います。 並列処理の効率化をする過程でresqueを見限りsidekiqに移行した理由、移行時に書き換えた部分などについてもお話ししたいと思います。 iQONのクローラーの並列処理の仕組み iQONでは毎日数100万点のアイテムのクローリングを行っています。 一度クローリングしたアイテムも毎日1回再クロールし在庫や値下げをiQON内のDBと同期しているため、大量のアイテムを効率良くクロールする仕組みが必要です。 クロールの処理は「ダウンロード」と「スクレイピング」の2つに大きく分けることができます。 このうち、ダウンロードの部分については、提携ECサイトに対して負荷がかからないようにスケジューリングをする必要があります。 この部分の効率化についてVASILYでは分散Mutex
こんにちは。iQONのバックエンドエンジニアを担当しているjoeと申します。 最近、iQONのお知らせ機能のDBをMySQLからDynamoDBへ移行しました。 移行する際に発生した問題点である並列処理によるデータ欠損とProvisioning超過の対策を書きます。 間違っているところや改善点があればご指摘ください。よろしくお願い致します。 お知らせ機能とは お知らせ機能とは、facebookで言うところの「◯◯さんがあなたの投稿に「いいね!」といっています」のような、ユーザーに対するアクションがあったことを通知したり、アイテムが値引きされた、アイテムの在庫が少なくなった等のlikeしたアイテム情報をユーザーに通知する機能です。 既存のお知らせ機能の問題点 既存の構成における問題点は以下の二点です。 データの肥大化 レスポンスが遅い お知らせのデータ構造は、下記のようになっています。 My
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く