CET リアルタイム集計・分析基盤構成メモ[NOINDEX]

以下引用

@see https://engineer.recruit-lifestyle.co.jp/techblog/2015-11-27-yoshida-interview-2/

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