AWSで本格的に運用するのは厳しいかなという印象です

——　今回構築された基盤の具体的なシステム構成はどのようになっているのでしょうか？

現在のシステム構成図

吉田　AWS（Amazon Web Service）を使い倒すっていうスタンスです。一部、GoogleのGCP（Google Cloud Platform）も使っていますが。
まず、Fluentdというログ収集管理ツールでログデータを収集します。集めたログデータはElasticsearchとBigQueryという検索エンジンに入れて可視化しています。
リアルタイム分析のところはAmazon Kinesis経由でApache Sparkで分析して、分析した結果をAmazon DynamoDBに入れて、それをAPIで各サービスに還元するという構成になっています。
ログデータ自体はAmazon S3っていうデータストアに保存していますね。

——　BigQueryとElasticsearchの使い分けはどのようにしているのですか？

吉田　データの鮮度ですね。
Elasticsearchは直近3日分だけですが、BigQueryは全期間のデータを入れています。

——　Elasticsearchは直近3日分だけなんですね。

吉田　はい。Elasticsearchはマシンパワーが必要です。サーバ台数を増やせばそれだけ大量のデータを分析できるのですが、コストの関係でいまは直近3日分だけ入れています。
Elasticsearchで見た方が見やすいんで、直近データだけでもKibanaで見て、1ヶ月とか1年間とかそういったスパンでログデータを見たい場合はBigQueryを使うというような感じですね。

——　AWSインスタンスはなにをどれくらい使っているのでしょうか？

吉田　Elasticsearchのサーバは、m2.2xlargeが4台です。m2.2xlargeは、メモリを34.2GiB積んでいて、比較的大きいサーバです。
Fluentdのサーバは、m1.mediumが10台。
APIのサーバは、まだ負荷は高くないのでt2.smallが2台です。

——　思っていたより少ない印象ですが、これだけでも結構コストがかかりそうですね。

吉田　確かにElasticsearchに全体の1/3ぐらいの予算が吸い込まれています……。ですが最近、もっとコストパフォーマンスが悪い部分が露呈しました。
いまAmazon KinesisとAmazon EMRとAmazon DynamoDBを使っている部分なのですが、とくにAmazon DynamoDBのコストパフォーマンスが問題です。小規模に使っている分には問題ないのですが、大量のデータを更新するときに、どうしても高いスループットが必要になってしまい、結果的に結構なコストがかかています。具体的には、50万円／月ほどなのです……。

既存のシステム構成を簡略化した図（リクルートライフスタイル全サービス横断のリアルタイムログ収集・可視化・分析基盤より）

GCPにすべて移行した場合のシステム構成を簡略化した図

GCPでAmazon DynamoDBに対応するCloud Bigtableというサービスがあるのですが、そちらだと、同じぐらいの性能でコストが1/10ほどになることがわかりました。そちらに移行することを現在検証しています。
そうなると、Amazon KinesisとAmazon EMRも、AWSで構えるよりもGCPで構えたほうが都合がいいので、Amazon Kinesisに変わる部分としてCloud Pub/Sub、Amazon EMR変わる部分としてCloud Dataprocに移行しようとしています。

Cloud Pub/Subは今年の3月にBeta版が公開されて8月に正式版になったサービスで、Cloud DataprocはBeta版が9月に公開されたばかりです。先ほどのCloud Bigtableは今年の5月にBeta版が公開されたので、全部今年リリースされた新しいサービスですね。

——　今後、すべてをGCPに移行するという可能性もあるのでしょうか？

吉田　十分ありえます。
ただ、まだ社内で使っている前例がないので、とくにセキュリティ面に関してしっかりと検証しなければいけないです。
やっぱり、リアルタイムでデータを分析するということが肝なので、そこをいかに低コストで実現できるかがポイントですね。

——　そもそもAWSを選択した理由はどういったものだったのでしょうか？

吉田　AWSを選択した決め手は、事例が豊富にあるので、社内に知見が貯まってるっていうということでした。
ただ、AWSは見栄えはいいんですが、実際には使いにくい部分が結構あります。さきほどのAmazon DynamoDBの話もそうなんですけど、本格的に運用するのは厳しいかなという印象です。

コストパフォーマンスは重要だがコンセプトはブラせない

——　いまインフラの予算はどのぐらいあるのですか？

吉田　上期は60万円／月ぐらいに抑えていました。いまだともう少し増えてて、70万円〜80万円／月ぐらいです。

——　これは多いんでしょうか？

吉田　相対的に多いか少ないかはわかりませんが、この予算はデータ収集だけです。Elasticsearchなどのデータ分析は別の予算なので、全体ではもっと多くなるはずです。

——　ビッグデータは"ビッグ"というだけあって、本格的に稼働すると一日に数TBものデータ量になる可能性もあると伺っています。毎日発生する数TBのデータを永久に保存することは、コスト的に考えて難しいのではないかとお察ししますが、データの破棄についてはどのようにお考えですか？

吉田　正直なところ、立ち上がったばかりなので、そこまで長期的なことは考えていません。それでも、BigQueryやAmazon S3などのできる限り安いストレージに保存するようにはしています。
もし将来的に何か都合があれば、古いデータは圧縮して別のところに退避させるか、破棄するのか……。対策を考えていく必要があるかもしれませんね。

——　ちなみに、AWSではリージョンによって料金が変わるはずです。リージョン選択はどのように使い分けているのでしょうか？

吉田　すべて東京です。
我々のテーマは「リアルタイム」なので、できる限り速いリージョンを使います。
いまはAPIサーバを自前で構えているのですが、Amazon API Gatewayというサービスを使えば保守管理が必要なくなります。これまでは東京リージョンがなかったので使えなかったのですけれど、昨日（編注：2015年10月08日）の「AWS re:Invent 2015」での発表で、遂に東京リージョンもリリースされたので、GCPに移行するまでは、Amazon API Gatewayも使うかもしれないです。

——　昨日！　そういった情報収集や新技術の勉強は、どうやっているんですか？

吉田　これは大企業ならではのメリットなんですが、便利なことに社内のSlackやHipChatで自然と流れてくるんです（笑）

OSSにコミットすると我々も嬉しいし、今後使う人も嬉しい

——　AWSのサービスとOSSはどのように使い分けていますか？

吉田　なるべくインフラ運用はせずに、ビジネスに貢献するアプリを作るということに集中したいので、できる限りサービス化されているクラウドサービスを使うようにしています。OSSを使うのは、自分たちがやりたいことが既存のサービスで実現できないときだけです。

——　吉田さんはElasticsearchやApache Sparkのコントリビュータとして名前が掲載されるなど、OSSに貢献されているというお話を伺ったのですが

吉田　それは必要に応じてって感じですね。
例えば、CETでもFluentdなど一部ではOSSを使っているのですが、機能が足りなくて、今のプロジェクトで必要としてることができないという場面があります。
そういったときは積極的に我々のメンバーでそのOSSの機能を拡張して、コミットしていますね。それによって我々も嬉しいし、今後使う人も嬉しいだろうということで。

——　使わせてもらった分、自分たちのできる範囲はコミュニティーに貢献すると。

ビッグデータで新しい価値をユーザーに届ける

——　今後ビッグデータを解析することで、リクルートライフスタイルのサービスはどう進化するんでしょうか？

吉田　ビッグデータをリアルタイムに分析して、そこからなにか有用な情報とか新しい価値をユーザーに届けられるようになると思います。
もしかすると今後、ビッグデータを使ったまったく新しいサービスが立ち上がる可能性もあるかもしれないですね。

CETが試行錯誤しながら開発しているリアルタイムなビッグデータ解析基盤によって、各サービスにビッグデータを活用した機能が追加されるのも近そうだ。

終