第6回Elasticsearch勉強会

第6回Elasticsearch勉強会に参加したので、記憶が新しいうちにメモ. 内容は資料を見れば分かると思うので、個人的に特に記憶に残ったポイントと、感想のみ.

Aggregationあれこれ @johtani 氏

資料
商用での利用事例、という意味ですごく興味深かった
DSPの配信システムで利用. 最大秒間30000ログ. 1.5TB/日くらい
各サーバのログ –> fluentd –> Elasticsearch –> MySQL/Redis という構成
fluentdは10インスタンス
ElasticsearchはCoordinate:2ノード, Search:2ノード, Data:28ノード.全てAWSのr3.largeインスタンス. メモリは30GBくらい？
- diskは途中でSSDに変えた
- CoordinateとSearchを分離する、というのは世間で見かけるけど、実際に負荷をみると必要性が疑問
- 1日1index, 1index12shard, 1レプリ.
単純なログのinsertのみではなく、Bidと紐付けるべきログが来ると、元のBidのログに項目を追加する. fluentd pluginとして実装
運用ツールとしては、Elasticsearchのpluginとしてhead, bigdesk, ElasticHQ. 死活監視やfluentdのメトリックにはZABBIX
個人的な感想
- サーバスペック、台数、流量の具体的な事例としてとても参考になった
- indexサイズはかなり大きくなるけど、いけるものなんだ.
- お金の計算に関わる部分に、fluentdとかElasticsearchとか使っている、というのに驚いた

資料
スキーマをちゃんと設計して、それに合わせてマッピング定義するのは面倒. どんなフィールドでどんなマッピングが最適、とか個別に設計すると人材がスケールしない.
そこで、dynamic templateとindex templateを使い、ノウハウが必要な部分はtemplateに集約、各利用者(データを投入する人)にはフィールド名のネーミングルールを周知する、というアプローチにした
例えば、利用する言語を”language”というフィールドの値として設定し、template側でそれに合わせて適切なanalyzerを定義しておくことで、多言語に対してもうまくindexできる.
個人的な感想
- 確かに、どんな型にして、どんなanalyzerにして、とかはノウハウの部分になるので、それをtemplateに集約するのはとても良いアプローチだと思った

Elasticsearchのソースコードを読み始めてみた
開発者の人には、はじめにREST APIを受けて検索する部分の動作をみてみるといいよ、と言われたけど、それがどこか分からなかったので、起動の部分を追いかけてみた話
個人的な感想
- ちょうど、そろそろソースみないと、と思っていたのでそのとっかかりとして大変参考になった

資料
Reroute APIを使って、具体的にどのシャードをどこに配置するとかの制御ができるよ、という話
リバランスを有効にしていると、APIでシャードを別のノードに配置しても、リバランスされてしまうので注意
個人的な感想
- オチがとてもおもしろかった.
- Reroute APIって、制御できるのは良いけど、逆にいちいち制御するのはやってられないし、どーいう場面で使うのだろう、と思った.

資料
indexのスナップショットを取れるようになったけど、普通にやるとリストア対象のindexを一旦closeしないといけない. サービスの継続を考えると、ダウンタイム無しでやりたい、という話
予めクライアントからはalias経由でアクセスするようにしておく. aliasの切り替えはatomicにできるので、それを利用して、リストア完了後にスッパリ切り替える、という形にする
個人的な感想
- リストアだけでなく、mappingを変えるためにindexしなおすとか、aliasを使うと便利な場面はありそう
- しかし、自分の環境はfluentdで”name-YYYY.MM.DD”の形でindexを作っているので、この場合aliasはどうしたらいいんだろう