新卒エンジニア研修で「Elasticsearch の歩き方」について話した

f:id:inouetakuya:20141103002159p:plain

これは Elasticsearch Advent Calendar 2014 の 11日目の記事です。

社内の新卒エンジニア研修で、先輩エンジニア＆デザイナが自分の得意なことや好きなことをそれぞれ 1時間使って講義するという枠があって、先日 Elasticsearch について話しました。

当日はほぼ口頭で説明したので、ほとんど見出しのみのスライド＆ホワイトボードを使いましたが、今日はスライドに若干の手を加えて公開しようと思います。

彼らに伝えたかったこと

彼らに何を伝えたかったかというと、Elasticsearch の全体像です。

「ちょっとチュートリアルやってみましたー」の後に、仕事で Elasticsearch を使えるようになるには、どこをおさえておかないといけないか、を話しました。

もちろん彼らが実際に仕事で使うようになるのはもう少し先のことで、そのときは今聞いたことなんてほとんど忘れていると思うので、分からないときに何を見たら良いかも話しました。

僕は新しい分野のことを学ぶときはなるべく早く全体像を掴もうとしています。全体像を掴んでから、必要に応じて個々の点を掘り下げるというスタイル。

ですが、実は、Elasticsearch の全体像を把握するのに苦労しました。

Wantedly さんのチュートリアルっぽいやつをやって、なんとなくクエリ DSL を投げられるようになったりしたのですが、では仕事で使うんだったら、あと何が大事になってくるのかという点についてイメージが持てませんでした。

そんなときに偶然、下記の記事を見つけまして。

その記事の内容そのものよりも、そこから「Elasticsearch を（これまで親しんできた）データベースの仲間として捉えたら理解が捗るのではないか」という発想を得て、その時点から Elasticsearch に対するあらゆる理解が進みました。一気に。

例えばクエリ DSL を投げるのは、RDBS の SQL を投げることに似ています。意図したデータが取得したら嬉しいことも、意図したデータを取得できるだけで喜んではいけないことも。（パフォーマンス etc）

また、データベースと対応させて考えると、数々の思い出を抱えた my.cnf の顔が浮かびます。そうだ、きっと elasticsearch.yml もデフォルトのまま放置しておいたら、趣味レベルでは良くても、仕事だと死ぬんだろうなということに気付きます。

仕事では今日も DB のテーブル定義に熱い議論が交わされている。きっと Elasticsearch のスキーマ設定も奥が深いはず。

そして、仕事の二文字から「運用」の二文字が浮かぶ。ああそうだった。でっかいテーブルに alter かけて背筋を凍らせたっけな。Elasticsearch でもインデックスをつくる（再構築）するときに、サービスのダウンタイムをつくっちゃダメなんでしょ？そうなんでしょ？

そうやって気付いたことをカテゴライズすると、3つに分けることができました。

設定編
- elasticseaech.yml はもちろん、クラスタをどう構築するか
- スキーマ設定
検索クエリ編
- クエリ DSL。ファセットなどの様々なクエリ。パフォーマンス
運用編
- インデックス再構築時にダウンタイム出すなよ、出すなよ
- ノードがひとつ死んでもダウンタイム出すなよ、出すなよ
- インデックスぶっ壊れてもうまいことやれよ
- データ移行