Elastic Cloud を使うようになって変わったこと
Elastic Cloud を使うようになって、変わってきたシステムアーキテクチャーと設計方針
寒くなってきましたね。趣味のキャンプも１１月で今年はおしまいです。上の写真は今年最後のキャンプで撮った１枚。焚き火をしながら凍えそうでした。
Elasticsearch Advent Calendar 2019 ２日目、最近まったく情報発信できていなかったのでリハビリもかねて。久しぶりに Elasticsearch 関連の記事がんばって書きます！
Elasticsearch を使い始めたのは、かれこれ５、６年前（Hello! Elasticsearch ブログを公開したのが、２０１４年なので、多分その１、２年前）。その前は、今は無き FAST ESP (Fast Datasearch) と言う商用のサーチエンジンを使ってシステムを設計、構築していました。
Elasticsearch に出会って衝撃を受けたのは、そのシステム構築のし易さと、柔軟なスキーマ・インデックス設計。それまでの検索エンジンに対する私の印象は、レース場でしか走れない F1 マシンといった感じでした。そして、Elasticsearch の登場でその印象は大きく変わります。例えるなら、街乗りもアウトドアもこなすちょっと高級な SUV と言ったところでしょうか。
それでも、やっぱり検索エンジンのアーキテクチャーは慣れないエンジニアには難しく、ビジネス要件を満たすシステム設計と運用は経験者の知見が必要でした。
そして、Elastic Cloud の登場です。Elasticsearch に出会った時と同じくらい衝撃的でしたね。
クラスターはデータ量とその情報の用途や特徴で分ける
変わったこと その１は「データ量や扱う情報の用途や特徴でクラスターを分ける」です。
Elastic Cloud が登場する前は、１つのクラスターで、いろんなデータをインデックスして、集中管理するようなアーキテクチャーを設計していました。なぜならクラスターが増えれば、それだけ運用が面倒になるし、専門的なエンジニアが必要になると考えていたからです。
この設計思想は、さらに Elasticsearch のシステム構成や運用の敷居を上げていました。検索エンジンのシステム構築で一番難しいのは、検索のパフォーマンスよりも、むしろドキュメントのインデックスパフォーマンスです。
いろんな情報を１つのクラスターで管理することで、データ構造だけでなく、データ数やデータ量、またその更新頻度と様々な要件の情報を考慮する必要があります。あまりにシビアな更新頻度要件を満たそうとしたら、関係ない情報に対する検索のパフォーマンスにさえ、影響を与えかねません。
この辺りの悩みは、Elasticsearch の登場だけでは解決されず、ずっと悩みの種でした。
しかし、Elastic Cloud が登場したことで一気に解消しました。
Elastic Cloud は、Elasticsearch を初めて使う人にも分かりやすい Web コンソールが提供されていて、新しいクラスターの作成もほんの数クリックで完了します。
さらに、作成したクラスターのスナップショットも自動的に取得され、スナップからのデータのリカバリーや、スナップショットから新しいクラスターの作成も Web コンソールから簡単にできてしまいます。
これだけ簡単に Elasticsearch を構築・運用できれば、最初から10万件または 10GB を超えるような情報はクラスター分ければ良くない（数字はあくまでも感覚です）？という考えに変えてくれました。
もともと、それほど関係ない情報を１つのクラスターで管理していると、高負荷や障害発生時に影響を受けあってしまいますし、別で管理した方が理にかなっています。
今では、４００万件を超える問い合わせ情報、５０万件を超える旅行体験談（口コミ）情報、検索精度が鍵を握る FAQ 情報、止まってしまうのが一番困る商品情報と言うように、データ量とその情報の用途や特徴でクラスターを分けるように変わりました。
積極的にアップグレード
変わったこと その２は「マイナーバージョンは積極的に、メジャーバージョンは計画的にアップグレードする」です。
これまで、新しいバージョンの機能を使いたい。もしくは、解決しなければならないセキュリティ的な問題がない限り、メジャーバージョンアップはしない方針が多かったように思います。それもこれも、検索エンジンのシステムは構築・運用するのが難しかったからです。
Elastic Cloud を使っていると、マイナーバージョンアップはとても簡単でボタンをポチッと押すだけです。不安なら現在稼働中のクラスターから取得したスナップショットを使って、マイナーバージョンアップ後のクラスターを作成し動作検証することもできます。
メジャーバージョンアップも新しいクラスターを作成しておき、Reindex API を使って、現在稼働中のデータをフィードし直すだけで簡単に構築できてしまいます。
あと、Elastic Cloud では、強制的に EOL が過ぎたバージョンは使えなくなっていくと言うのがあります。
このような状況なので、マイナーバージョンアップは積極的にアップデートして、メジャーバージョンアップは、EOL を把握して計画的にアップグレードしています。
EOL が近いバージョンを使用していれば、Elastic Cloud からちゃんとメールでお知らせが来ます。
過去に EOL が過ぎているバージョンをしばらく利用してると、Elastic Cloud から「◯月◯日までにアップグレードしないと、利用可能な最新バージョンに勝手にアップグレードしちゃうよ。」というようなメールが来ました。この時は流石に焦りました💦
Elasticsearch は、鬼のようにリリースが早いのですが、EOL の期間は鬼ではありません。ちゃんと計画してアップグレードすれば問題ないはずです。
あまり ES 側で無理しない
最後となりますが、変わったこと その３は、「クライアント側でできることは、クライアント側でやってもらう」です。
以前は、その柔軟性と高機能さゆえに、Elasticsearch で提供されている機能を駆使していましたが、頻繁にバージョンアップを行うことを考えると、Elasticsearch には本来の役割に徹してもらう方が総合的にみて良いのではないかな？と考えています。
設計する際に気をつけているのは、Script 系 と Inner hits はなるべく使わないようにしています。Script Query / Filter は使うことはあっても、Script field は使いません。Inner hits もレスポンスするデータ構造が複雑になってしまうため使いません。
Script field も Inner hits ともにレスポンスに関わる機能です。アプリケーションで言えば、表示する内容に関わる機能です。表示する内容は一番変わりやすいですし、クライアント側で処理できるものはクライアント側でやってもらいましょう。
まとめ
Elastic Cloud の宣伝みたいな記事になってしまいましたが、流石に本家で提供しているだけあって、特にシステムの構築や運用面でよく考えられてるなぁ。という印象です。これから Elasticsearch の導入を検討されている方は、Elastic Cloud を選択肢に入れてみるのは良いと思います。
また、Elastic Cloud で物足りなければ、Elastic Cloud Enterprise や Elastic Cloud on Kubernetes も提供されています。個人的には Elastic Cloud on Kubernetes 気になりますね。時間があるときに使ってみたいです。
３日目は shoito さんです。お楽しみに♪
