ElasticON Tokyo 2022 最速レポート

この記事は Elastic Stack (Elasticsearch) Advent Calendar 1日目の記事です。

こんにちは、@shin0higuchiです😊

昨日11/30(水)に、ElasticON Tokyo 2022 が開催されました。
今年は2019年以来、３年振りのオフライン開催で、私もウェスティンホテル東京の現地に行って参加してきました。

午前中は基調講演やゲストスピーカー落合陽一氏の講演などが、
午後は２並列でテクニカルセッションとユーザ事例のセッションがありました。

私はテクニカルセッションを中心に聴講していましたが、
今年はクラウドベンダー各社との連携が強まった点が印象的で、Google・Microsoft・AWSのそれぞれから発表がありました。

今回参加した中でも特に印象的だったセッションは「サーバーレスアーキテクチャへの道」という発表です。
Elasticsearch社のプリンシパルソリューションアーキテクト古久保さんによる発表で、Elasticsearchのアーキテクチャの変遷と今後の展望について話されました。

このブログでは、このセッションについて詳しく紹介します。

「サーバーレスアーキテクチャへの道」

概要

セッションの動画等は公開されていませんが、下記のブログが元ネタとなっています。
www.elastic.co

ブログでは現在のアーキテクチャと、今後のアーキテクチャの２つに分けて違いが説明されていますが、セッションの中ではさらに細分化して４つに分けて説明されました。

Act-one：Elasticsearch初期のアーキテクチャ (シャード分割)
Act-two：現在のアーキテクチャ(Data Tierを用いた時系列データ管理)
Act-three：ステートレス
Act-four：サーバレス／フルマネージド

こちらが、ブログで説明されている画像ですが、Existing ArchtectureがAct-two、New ArchitectureがAct-threeに相当することになります。

https://www.elastic.co/jp/blog/stateless-your-new-state-of-find-with-elasticsearchより

話の趣旨としては、現在のAct-twoからAct-threeを目指して移行中で、更に先の将来はAct-fourを目指したいということでした。

Act-two (Existing Architecture )の特徴／課題

Act-twoでは、いわゆるHot-Warm Architectureとも言われるように、データの鮮度に応じてノード間を移動させ、新しいデータ程良いスペックのマシンに載せることで従来よりもコストを抑えつつパフォーマンスを維持することができていました。さらに最近ではレプリカをオブジェクトストレージに配置する Searchable Snapshot 機能も公開されています。
しかし、課題として下記の点が挙げられます。

レプリカを保持するためストレージコストがかかる
ノード間のデータ移動が頻繁に発生し、また、移動に時間がかかる
検索とインデクシングが同じリソースを共有するので、互いの性能に影響する

Act-three (New Architecture)の特徴

Act-twoの課題を改善すべく、新たに「ステートレス」な構造が提唱されています。
ポイントとしては、データ投入と検索を分離することで、リソースをより効率化できる点です。

書き込み時には、書き込み用のノードがオブジェクトストレージに書き込み、検索時には検索用のノードがオブジェクトストレージから読み込む。こうすることでAct-twoで挙がっていた課題が悉く解消される形になります。現行のアーキテクチャでは、データ投入と検索がCPUリソースなどを食い合うので、必要スペックの正確な見積もりが困難でしたが、その辺りも解消される形になりそうです。

オブジェクトストレージからの検索になったことで検索速度の低下が懸念されることと思いますが、キャッシュを上手く使うことで速度を改善しているとの説明でした。初回の検索が遅くなってしまう等はあるかと思うので、場合によってはSearch Tier側の暖機運転が必要になるかもしれませんが、その辺りはElastic社としても検討中かと思いますので今後の情報が楽しみです。

# Act-fourのフルマネージドはもう少し先の話になると思いますので、ここでは割愛します