OpenSearch の物理設計・スケーリング戦略の思考フロー💡

こんにちは！

今回は Amazon Elasticsearch の後継である OpenSearch の物理設計やスケーリング戦略の思考フローについて話していきます！考え方は Elasticsearch と変わらないのでそちらに触れた経験がある人にとっては馴染みのある内容となっています。では早速解説していきましょう。

想定する読者

• OpenSearch を初めて利用するヒト
• OpenSearch のスケーリング戦略について考えているヒト
• Elasticsearch を利用していたヒト

はじめに

まず OpenSearch とはどんなものなのかを公式ドキュメントから読み取っていきましょう。

Amazon Elasticsearch Service の後継である Amazon OpenSearch Service は、AWS クラウドでの OpenSearch クラスターのデプロイ、オペレーション、およびスケーリングを容易にするマネージドサービスです。Amazon OpenSearch Service は、OpenSearch とレガシーの Elasticsearch OSS をサポートします。クラスターを作成するときに、どの検索エンジンを使用するかのオプションがあります。OpenSearch Service は、ソフトウェアの最終的なオープンソースバージョンである Elasticsearch OSS 7.10 との幅広い互換性を提供します。最近のサービスの名前変更による変更内容、および実行する必要があるアクションについては、「Amazon OpenSearch Service – 変更の概要」を参照してください。

引用元： Amazon OpenSearch Service とは？

提供している内容は主に Elasticserach と同じです。Elasticsearch との違いはあまりありませんので、調査の際に一部 Elasticsearch の記事を参考にしても支障はないでしょう。ちなみに Kibana も名称変更されていて、「OpenSearch Dashboards」という名前になっています。

マネージドされている範囲も前の Amazon Elasticsearch と基本的には同じになりますので、以前と同様の設計が必要となってきます。

必要な設計範囲

OpenSearch はマネージドサービスとはいえ、完全にインフラ部分を無視できるわけではありません。意識しなければいけないポイントには以下があります。

• ストレージ
• シャード数
• インスタンスタイプ
• 専用マスターノード

設計する上では、どのくらい利用頻度があるのか、負荷はどれくらいかかるのかを予測したうえで行なってください。それでは1つずつ解説していきましょう。

ストレージ

まず OpenSearch を利用する場合のワークロードとしては以下の2つに大別されます。

長期存続インデックス	データを 1 つまたは複数の OpenSearch インデックスとして処理し、ソースデータの変更に伴ってそれらのインデックスを定期的に更新するコードを記述した場合。一般的な例としては、ウェブサイト、ドキュメント、e コマースの検索などがあります。
ローリングインデックス	データは継続的に一時的なインデックスに受け渡され、インデックス作成時間や保持期間が指定されます。たとえば、日次のインデックスは 2 週間保持されます。代表的な例は、ログ分析、時系列処理、クリックストリーム分析などです。

つまりエンドユーザーが利用できる検索機能なのか、開発者がシステム運用や分析のために利用する検索機能なのかの違いです。これに応じてストレージ要件を整理していきます。

長期存続インデックスの場合は、ソースデータの容量に応じて選択できるのでシンプルに設計ができます。

ローリングインデックスの場合は、以下の計算式に基づき必要な容量を確認します。

ソースデータ x (1+ レプリカの数) x (1 + インデックス作成オーバーヘッド) ÷ (1 – Linux 予約スペース) ÷ (1 – OpenSearch Service のオーバーヘッド) = 最小ストレージ要件

引用元： ストレージ要件の計算

計算式の例を挙げると、30 GiB のデータが存在してレプリカを1つ必要とする場合、最小ストレージ要件は 30 * 2 * 1.1/0.95/0.8 = 86 GiB になります（小数点以下は切り捨て）。

ストレージ設計を見誤ると、クラスターが不安定になってしまいますのでご注意ください。計算式の具体的な例については引用元の記事をご覧ください。

なおこの計算式を用いる前に一定の期間でどれだけのソースデータがあるのかを見極めなければいけませんので、その点を忘れぬようご留意ください。

シャード数

次にインデックス作成の戦略を行います。

OpenSearch はデフォルトで、各インデックスに対して 5 つのプライマリシャードと 1 つのレプリカ (合計 10 個のシャード) に分割されています。一度作成したら変更は不可ですので、事前設計がとても重要になります。

シャード数を選択する目的は、インデックスを均等に分散させるといった点にあります。難しい問題ではありませんが、このシャードというのは大きすぎたり多すぎたりすると障害復旧が困難になります。

AWSのドキュメントに記載のある適度なサイズは「10～50 GiB」なので、この範囲でシャードのサイズを設定してください。

シャードの数を導き出すには、以下の計算式を用います。

(ソースデータ + 拡張の余地) * (1 + インデックス作成オーバーヘッド)/希望シャードサイズ = プライマリシャードの概数

引用元： シャード数の選択

計算式の例を挙げると、同じ 30 GiB のデータが来年は 4 倍になると想定される場合、シャード数はおよそ (30 + 120) * 1.1/30 = 5 となります（小数点以下は切り捨て）。

こちらも具体例については引用元の記事をご覧ください。

インスタンスタイプ

次にインスタンスタイプを選択します。

これはストレージ、シャードの計算結果をもとにすれば必要なサイズが導き出されます。時間が経つにつれてデータが増加することを考慮し、余裕を持って拡張できるインスタンスタイプを選択してください。高い負荷が一時的に発生する場合は、より大きなものを指定してください。

またインスタンスタイプによってサポートされている内容が異なるので、必ず事前にインスタンスタイプの一覧表を確認してください。

サイズについては以下の表に応じて決定していきます。

Instance count	推奨される最小専用マスターインスタンスタイプ
1～10	m5.large.search または m6g.large.search
10～30	c5.xlarge.search または c6g.xlarge.search
30～75	c5.2xlarge.search または c6g.2xlarge.search
75～200	r5.4xlarge.search または r6g.4xlarge.search

なお T2・T3 インスタンスは、使える機能が制限されるためお試し以外では使わないようにしてください。また M3 などの古いインスタンスタイプでは、保管時の暗号化がサポートされていないので選択しないようにしてください。EBS ボリュームがサポートされていないインスタンスタイプもあるので、よく確認して選択するようにしてください。

そのため基本的には、上記の表をもとにインスタンスタイプを選ぶようお願いします。

専用マスターノード

最後に専用マスターノードの数とサイズを決めます。専用マスターノードは、クラスターの管理タスクを実行する役割を担っています。

マスターノードの数は仕様上、３と５しか設定できないため規模に応じて選択していきましょう。推奨値は「３」です。なお設定値が奇数しかないのは Elasticsearch からの仕様が原因となっております。

大規模な容量を扱う場合を除けば、多くのケースは「３」を選択するべきです。

こちらはほかの設計と比べてかなりシンプルに決定することができます。

ここまでの設計が完了すれば、OpenSearch のインフラ設計は完了となります。あとはとにかくテストをして、推測できる値をなるべく正確なものに近づけ、その値をもとに設計をすることでより正確な設計ができるでしょう！

関連記事

• Amazon OpenSearch Service のベストプラクティス
• Amazon OpenSearch Service でサポートされるインスタンスタイプ
• Amazon OpenSearch Service の専用マスターノード
• ElasticSearchとDynamoStreamの連携/実装方法を解説！すぐに使える実践テクニックを紹介します😎
• DynamoDB VS ElasticSearch！🤔データアクセス思考なDBMS使い分けの思考方法を解説します！😎

まとめ

OpenSearch の設計は自分に知識がないと感じたら、必ず AWS のドキュメントを道標にしてください。一度作成すればそのあとの変更が難しいリソースですので、なんとなくでやってしまうと後悔することになります。ドキュメントでわからないことがあれば AWS サポートとできる限りディスカッションを重ねて、要件を詰めていってください。この記事が参考になれば幸いです。

このブログでは、AWS の記事をどんどん公開しておりますので、ご興味のある方は他の記事もご覧いただければと思います。

AWS に関する開発は、お気軽にお問い合わせください。