スタートアップのデータ処理・分析基盤、作るか、使うか

初めまして、tagomorisといいます。今回縁あってゲストでエントリを書くことになりました。実に感慨深い気分です。

さて本題ですが、DMM.comを含めた多くのWebサービス・インターネットサービスでは、今やデータの収集・処理・分析といったタスクが非常に重要なものになっていることは多くの方に賛同をいただけるものと思います。近年ではIoTというキーワードもよく話題になります。増え続けるデータの処理をどのようにするか、といった点に悩んでいるサービス事業者の方は多いのではないでしょうか。

この種のデータ処理・分析をどこでどうやって行うか、という問題は通常のWebサービスの開発とはかなり異なる知識と経験を要求されます。特にHadoopを中心とした分散処理基盤のデプロイとメンテナンスはこれまで多くの開発者を悩ませてきました。

一方、近年ではデータ処理・データ分析に特化したサービスもいくつも出てきました。自分でHadoopクラスタのセットアップ・運用をしなくても利用可能なこれらのサービスは特に開発者の少ないスタートアップで広く利用されるようになり、耳にされることも多いかもしれません。

このエントリでは、特にスタートアップ企業、あるいは既存企業の新規事業などにおいてデータ処理・分析基盤が必要とされるとき、どのような選択肢があるかについて概要を書いてみようと思います。

総論

まず原則ですが、これは極めて簡単で「サービスを使いましょう、作ってはいけません」です。

そのスタートアップ企業が何を専門とするかにもよりますが、多くの場合、それらの企業は自前のデータセンタなど持ってはおらず、またソフトウェアエンジニアの数もそう多くはないでしょう。そういった企業にとって自前の分散処理クラスタの保持と運用は金銭、エンジニアリングの両面で極めて高コストになります。

サービスを使う場合についてもいくつかの選択肢があります。日本国内でよく選択されているのは以下のあたりでしょう。

  • Amazon Elastic MapReduce
  • Amazon RedShift
  • Treasure Data
  • Google BigQuery

今のスタートアップ企業の多くがAWS上でサービスを展開しているだろうことを考えるとAmazon Elastic MapReduce(以下EMR)やAmazon RedShift(以下RedShift)がまず選択肢となるかもしれません。EMRはS3に格納したデータを処理するHadoopクラスタを一時的に起動できる便利なシステムで、Hive, Pig などのHadoop向けDSLなどの他に自分で記述・コンパイルしたMapReduce処理そのものを走らせることもできます。RedShiftは分析用途の分散データベースを起動できる他社にもあまりない高機能サービスです。

数年前に登場したTreasure Data社のサービスはフルマネージドHadoopとでも言うべきもので、裏側で動いている仕組みとしてはHadoopとHive(あるいはPresto)ですが、クラスタの管理やデータ保管はすべてサービスの一部として提供されており、ユーザが面倒を見る必要がない、という点が異なります。
また保管データがスキーマレスなので、データ投入側からはいつ・どのようなタイミングでもデータの内容を変更することが可能です。これは特にサービス内容を頻繁に変更するスタートアップには良いかもしれません。

Google BigQuery(以下BigQuery)は少し趣の異なるサービスで、サポートされている言語はSQL-Likeな言語一種類のみです。実行時に裏側で何が起きているのかは基本的には隠蔽されており、実際に裏側はHadoopではありません。スキーマ管理やデータ保存などもBigQueryの一部として提供されており、フルマネージドサービスのひとつと言えるでしょう。
Googleの保有する巨大なクラスタで膨大な数での並列分散処理が行われることが特徴で、大容量データに対するクエリでもかなり速く結果が返ってくることが特徴です。ただしGoogleのクラウドサービスらしく、ちょくちょくクエリの失敗などが起きるため、ユーザ側で適宜リトライしてやらなければならない、などの注意点もあります。

さてスタートアップ企業にどのサービスが向いているかということを考えると、AWSのユーザにとって、EMRやRedShiftは利用例も多くとっつきやすいとも言えるかもしれません。一方で効率的に利用しようと思うと、EMRはHadoopの、RedShiftは分散データベースの知識が必要とされ、そのあたりの知識をもったエンジニアがいなければ高パフォーマンスの利用は難しくなるケースも多いでしょう。スキーマの調整やデータ保管形式・場所・期間などの管理も自分でやる必要があり、手をかければ便利に使える一方で、手をかけることができなければデータ量やクエリ回数に対して高い利用料金となってしまうケースもありそうです。

BigQueryはGoogle Cloud Platformの1サービスということになりますが、特にGoogleのクラウドサービスを使っていなくても簡単に利用できます。実際にAWS EC2を使っていながらデータ分析にはBigQueryを利用しているケースは多いようです。また現状(2015年2月)では利用料金が突出して安く、なんとBigQueryのデータ保存料金はAmazon S3の料金よりも安いのです。スキーマ管理が行われていること、直接クエリを実行可能であることを考えると、これは驚くべきことです。クエリ実行料金を含めても安く、自分が聞いたところでは数億行/dayもしくはそれ以上の規模のデータで運用していても月に数百ドル(桁を間違えてないよ!)の費用で済んでしまった、という話もあります。既にFluentdを用いていれば、データ投入はプラグインをひとつ足すだけでできてしまうという導入の簡単さも魅力かもしれません。

FluentdといえばTreasure Dataのサービス、という選択肢もあります。こちらもFluentdの設定ひとつで簡単にデータを投入できる上、BigQueryでは必要なデータのスキーマ管理が不要という利点があります。フルマネージドサービスとしてBigQueryと比較してみると、クエリの安定度ではこちらの方が上かもしれません。
またクエリのスケジュール実行や外部データベースへのデータ連携など、他のサービスが持っていない機能をいろいろ有していることも特徴です。少し高めの料金を払ってでも可能な限り外部サービスを利用して社内エンジニアリングコストを下げようと思うのであれば、有力な選択肢になることでしょう。

いくつかの特例となるトピック

総論としては以上のようになるのですが、特に上述の総論から逸脱するケースがいくつかあります。その中でもぱっと思いつくものに以下のものがあります。

  • 機械学習やグラフ処理などが主たる処理内容になるケース
  • 既に大規模なデータセンタを自社で保有しているケース
  • データを自社外に出すだけで事業リスクになるケース
  • 風土として自社でホストするというケース

まず目的とするデータ処理が主に機械学習やグラフ処理となる場合ですが、こういった種類の処理をホストしているフルマネージドサービスは実質的に無いといってよいでしょう。なのでこの場合、Amazon EMRの使用を検討するか、あるいは自社でHadoopクラスタをホストするということが有力な選択肢となります。特にSparkの新しいバージョンを使用したいなど、EMRのアップデートを待っている余裕がなく、またそれが事業において重要な価値を持つ場合には自社でHadoopクラスタをホストするのが重要な選択肢になるかもしれません。一方Treasure DataではHivemallというHiveのUDFとして動作するライブラリもサポートしていますから、このライブラリがサポートする範囲の処理だけを行いたいということであればTreasure Dataのサービス利用も選択肢としては有効となります。

既に大規模なデータセンタを自社で保有している場合ですが、このケースであればHadoopクラスタの調達・運用コストは下がります。ハードウェアやOSの運用のためにITインフラ運用の専門チームがいるのであればなおさらでしょう。しかしHadoopそのものの運用・アップグレードなどにかかるコストなどは過小評価するべきではなく、慎重に判断する必要があると言えます。

扱うデータが非常にセンシティブなものである場合にも注意が必要かもしれません。実質上、現在の各種クラウドサービスにおいて、技術的な問題による情報漏洩のリスク等はほとんど考慮する必要はないと思います。しかし非常にセンシティブなデータを他社管理のストレージに置いているという話が公表される際、その話の伝わり方がある種の誤解を含んでしまう可能性はあります。一度の風評被害がサービスの継続において決定的な悪影響を及ぼしかねないようなケースでは、そもそも外部にデータを最初から置かない、という選択肢もあるかもしれません。

また最後に、会社の風土あるいはポリシーとして自社でHadoopクラスタをホストする、というケースも考えられます。外部サービスに依存せず可能な限り自社内でOSSを利用して解決する、という選択をとる会社は多くはないものの存在します。エンジニアの採用や動機付け面の理由であることが多いでしょうか。これはこれ、というか、他人が口を出すことではないですね。

まとめ

主にスタートアップのような状況の各社においてデータ処理・分析基盤を必要とする場合において、主にどのような選択肢があるか、どういった判断基準でそれらを採用すればよいかについて簡単に述べました。

最初はもうちょっと広い範囲を見渡した内容で書こうかと思っていたのですが、あまりに長文になりそうだったので今回は主旨に合わないかなあと思ってダイジェスト版でお送りいたしました。フルバージョンを読みたい方はコメント欄やブックマークコメントにわっふるわっふると書いてください。と思いましたが自分のブログじゃないんでした。

このエントリの内容がみなさんの参考になることがあれば幸いです。


PAGE TOP