こんにちは、Treasure Data の西澤無我です。今回は、今年の 9 月下旬にローンチしました Yahoo! JAPAN のサービスである「Yahoo!ビッグデータインサイト」の話題を取り上げようと思います。
Yahoo!ビッグデータインサイトとは、大まかに説明しますと、IDCF クラウド上で動いているトレジャーデータのサービスのことです。トレジャーデータは AWS US のリージョン上で数年の間サービスを提供しておりますが、それと同様に IDCF クラウド上でもサービス提供を開始しました。現在、Yahoo!ビッグデータインサイトは、AWS 上の弊社サービスとほぼ同等の機能を提供できています。むしろ、IDCF クラウド上でコンソールや API サーバが動作していますので、日本からアクセスする場合、AWS のと比較しコンソールがサクサク動くのが体感できるかと思います。また、IDCF クラウド上でサービスが提供されていますので、セキュリティポリシー上データを国外に出せないという場合でも安心してご利用いただけます。
ここでは、Yahoo!ビッグデータインサイトの機能を説明していきながら、IDCF クラウドのどのような機能を利用し、トレジャーデータのシステムのポーティングを実現しているのかについて部分的にお話できればと考えています。
分散ストレージ Riak CS の利用
以下は、Yahoo!ビッグデータインサイトのコンソール上でクエリを発行できるクエリエディタのページです。しっかり Yahoo!ビッグデータインサイトのロゴが入っています。もう少し基本的なサービスの利用方法については、「Yahoo!ビッグデータインサイトを使ってみた, IDC Frontier Engineers' Blog」を参照してください。
このクエリが実際に実行される際に、ユーザの方々からお預かりしているデータは弊社で開発したストレージシステムである PlazmaDB に格納されていますが、PlazmaDB のバックエンドとして、IDCF クラウドが提供する分散ストレージである Riak CS が使われています（PlazmaDB に関する詳しい情報は、「Treasure Data の PlazmaDB を理解する」を参照してください）。IDCF クラウドに弊社システムをポーティングするにあたり、一番大きな障壁だと思われたのが、PlazmaDB のバックエンドとして IDCF クラウドの Riak CS を利用できるかどうか、でした。PlazmaDB にはそのバックエンドを差し替えられる拡張ポイントがすでに用意されており、理想的には Riak CS も利用できるわけですが、充分な性能が出せるかどうか、もしくは正しく結果が返ってくるのかどうか、については実際に試してみないと分かりません。そのため、想定されるアクセスパターンを利用して Riak CS の性能を測定し、弊社サービスに充分な性能を Riak CS が出せていることを数週間かけて確認しました。また、Riak CS のアーキテクチャ上、不得意と思われるリクエストを送信しないよう PlazmaDB 側を修正したりもしました。
インスタンス管理
弊社システムの特徴上、大量のインスタンスを一度に作成・削除することがしばしばあります。そのためにはインスタンス生成をほぼ自動で行えると便利であり、弊社では IDCF クラウドが提供する CloudStack API を利用しています。CloudStack API をラップしたライブラリがインターネット上にいくつも見受けられます。それらを利用し、AWS 上の弊社システムの既存の運用ツールを拡張し、ほぼ同じインターフェイスで IDCF クラウドのインスタンスを運用できるようにしました。
また、弊社システムを構成する様々なコンポーネントをどのインスタンスタイプで動かすべきかについても考える必要がありました。AWS 上で充分にノウハウが蓄積されているとはいえ、AWS と IDCF クラウドではコアの性能がそれなりに違うように見受けられましたので、性能/コストのベンチマークを取りつつインスタンスタイプを選んでいく必要がありました。特に、弊社システムでは、クエリエンジンを多数のインスタンス上で実行し、スケールアウトさせて、クエリのレイテンシを向上させることが多いので、コスパの良いインスタンス選びが必須となります。例えば、Hadoop のスレーブノードの場合であれば、コアがなるべく集積されており、1 map/reduce slot を一番低いコストで割り当てられるインスタンスという観点からベンチマークを行いタイプを選びました。
さらに、マシンの環境変数を AWS と IDCF クラウドのインスタンス全体で明示的に揃えることをしています。例えば、タイムゾーンなどです。弊社システムのコードベースは単一ですが、継続デプロイの仕組みを利用し、AWS, IDCF クラウドの両クラウド上にほぼ同時にデプロイが行われます。片方のクラウド上で何か不具合が発生している場合、両クラウドでそれが再現しているかを確認するのが、問題の切り分けの第一歩になります。その際に、両クラウドのインスタンス上で別々のタイムゾーンが利用されていると、両クラウド上の弊社システムのソフトウェアのログ（特に同時刻のログ）をつき合わせて確認するときに不便が生じる可能性があります。
おわり
ここまでつらつらと Yahoo!ビッグデータインサイトとそのポーティングについてお話させていただきましたが、いかがでしょう。また、もし Yahoo!ビッグデータインサイト興味のある方がいらっしゃいましたら、ぜひお試しください。それではメリークリスマスと良いお年を ༼ つ ◕_◕ ༽つ