OpenSearchの構成パターンについて考えてみた
2024.10.16先日、業務で利用しているOpenSearch Serviceで障害が発生しました。
Dashboardへのアクセスができず、ログを確認するとJavaのエラーログが延々と出ている状態でした。
原因調査したところ、データノードで利用していたt3.smallインスタンスが不安定になり、この 2 つのノードクォーラム損失が発生していました。
利用用途が社内に限られていたため、それほど大きな影響はありませんでしたが、調査の過程で現在のデータノード2台（t3.smallインスタンス）が本番では非推奨の構成だということが分かりました。
既存の仕組みということもあり、なんとなく利用していたのですが、これを機にインスタンスタイプとサーバー台数の観点から、OpenSearchの構成パターンについて自分なりに検討してみたいと思います。
※今回は、OpenSearchのバージョン2.13を対象にしています。
- 参考ドキュメント
インスタンスタイプの選定
まずはインスタンスタイプの選定についてです。
ドキュメントにはr6g.largeが小規模な本番ワークロードとして（データノードと専用マスターノードの両方として）推奨されています。
その周辺で比較的利用料金の安いインスタンスタイプを列挙してみました。
- インスタンス利用費（
ap-northeast-1）※2024年9月時点
| インスタンスタイプ | CPU | メモリ | 時間当たりコスト（USD） | 月額コスト（USD） |
|---|---|---|---|---|
t3.small.search |
2 | 2 | 0.056 | 40.8 |
t3.medium.search |
2 | 4 | 0.112 | 81.6 |
r6g.large.search |
2 | 16 | 0.202 | 147.6 |
r6g.xlarge.search |
4 | 32 | 0.404 | 295.2 |
r7g.medium.search |
1 | 8 | 0.107 | 78.12 |
r7g.large.search |
2 | 16 | 0.214 | 156.24 |
r7g.xlarge.search |
4 | 32 | 0.429 | 312.48 |
m6g.large.search |
2 | 8 | 0.164 | 119.52 |
m7g.large.search |
2 | 8 | 0.175 | 127.68 |
https://aws.amazon.com/jp/opensearch-service/pricing/
- T系インスタンス
T系のバーストインスタンス（t2やt3など）は一時的な負荷には対応できますが、負荷が持続するとパフォーマンスが不安定になるため、本番環境での使用は避けるべきです。
逆に開発環境などでは、コストを抑えるためにT系インスタンスを使用するという選択肢もあります。
r6g.xxx.search系インスタンス
OpenSearch サービスは常に、低コストでパフォーマンスを向上させる新しい Amazon EC2 インスタンスタイプを採用しています。常に最新世代のインスタンスを使用することをお勧めします。
本番稼働用ドメインで T2 や t3.small インスタンスを使用しないようにしてください。それらは負荷の高い状態では不安定になることがあるためです。r6g.large インスタンスは、小規模な本番ワークロードのためのオプションです (データノードと専用マスターノードの両方として)。
安定性を求めるなら本番環境ではr6g.large.searchを利用するのが無難そうです。
より高いスペックが必要な場合は次点でr6g.xlarge.searchを選択すると良いと思います。
r7g.xxx.search系インスタンス
推奨インスタンスタイプr6g.largeの次世代であるr7gにはr7g.mediumがあり、こちらはスペックが多少劣る代わりに利用費が安いです。
バースト系ではないので安定はしますが、CPUやメモリは検索や書き込みへのパフォーマンスに直接影響するので注意が必要です。
ある程度のパフォーマンスを犠牲にできるのであれば、コストを抑えたい場合の選択肢の一つとして考えられます。
一方、r7g.large.search は代6世代のr6g.large.search比べてコストが高くなっています。
OpenSearch サービスは常に、低コストでパフォーマンスを向上させる新しい Amazon EC2 インスタンスタイプを採用しています。常に最新世代のインスタンスを使用することをお勧めします。
とドキュメントに記載はあるので、その料金が安く改定されるのかもしれません。今後に期待です。
m6g.xxx.search系インスタンス
こちらのドキュメントを見る限り、専用マスターノードの最小インスタンスタイプとしてはm6g.large.searchが推奨に含まれています。
r6g.xxx 系と比べると安価なので、選択肢としてはありかもしれません。
- その他のインスタンスタイプ
c6g.xxx.searchやよりスペックの高いのインスタンスタイプもありますが、ここら辺まで含めると選択肢が多くなりすぎるので、今回は省略します。
マスターノード&データノードの台数選定
次に、マスターノードとデータノードの台数の選定についてです。
ここでは、
- マスターノードとデータノードの台数はどれくらいが適切か？
- 専用マスターノードを追加するか否か？
について考えてみます。
推奨構成では、専用マスターノード3台 + データノード3台と割と大きめの構成なので、それ以下のパターンを列挙してみました。
| パターン | マスターノード | データノード | 特徴 | ユースケース |
|---|---|---|---|---|
| 最小構成 | - | 1台 | 耐障害性が低い | 開発環境やテスト用 |
| 低ワークロード構成 | - | 3台 | 1台ダウンでも継続可能 | 開発環境や軽量な本番環境など |
| 推奨構成 | 3台 | 3台 | クラスタの安定性と冗長性 | 本番環境 |
| サーバーレス構成 | - | - | 自動プロビジョニング | 本番環境 |
※データノードのみの構成については、データノードがマスターノードも兼ねています。
- 最小構成
1台のデータノードのみで構成されているため、耐障害性が低く、1台ダウンで全クラスタが停止します。
そのため、開発環境やテスト環境などコストを抑えたい場合には選択肢として考えられます。
- 低ワークロード構成
低ワークロード構成では、3台のデータノードで構成されているため、1台ダウンしても動作を継続できます。
一方で、クラスタの管理（マスター選出、シャードの割り当てなど）に専念する専用マスターノードがないため、パフォーマンスが安定しないリスクがあります。
ドキュメントには本番ワークロードでは専用マスターノードを使用することが推奨されているので、開発環境や軽量な本番環境などで利用することが適していると思います。
- 推奨構成
推奨構成では、専用マスターノード3台 + データノード3台で構成されており、クラスタの安定性と冗長性が高いです。
また、この構成ならMulti-AZ with Standbyが利用できるので、より高い可用性を実現できます。
一方で、インスタンス数が増えるためコストが高くなります。
- サーバーレス構成
さらに大規模な運用を考える場合、OpenSearch Services Serverlessを利用することも検討できます。
OpenSearch Service Serverlessは、事前にインスタンスをプロビジョニングする必要がなく、自動的にスケーリングされるため、柔軟なスケーラビリティを確保できます。
計算能力は OpenSearch Compute Units (OCU) という単位で換算され、このOCUの１時間当たりの利用量に応じて課金されます。
料金の関してはこちらのブログが参考になります。
レプリカ有効時の最低料金（2OCU: 0.5 * 4）※本番向け
$488.976
レプリカ無効時の最低料金（1OCU: 0.5 * 2）※開発・テスト向け
$244.488
- これ以外のパターン
まず、2台のデータノードのみの構成など、偶数台の構成は避けるべきです。
これは自分も勘違いしていたのですが、2台のデータノードのみの構成では、1台のデータノードがダウンした場合、クォーラム損失でクラスタが停止してしまします。
OpenSearchのQuorum値は「専用マスターノードの数/2 + 1 (直近の整数まで切り捨て) 」で計算されるので、1台がダウンしてもクラスタが停止しないようにするためには、3台以上のデータノードが必要になります。
なので、2台のデータノードのみの構成は、一見高可用に見えるかもしれませんが、可用性という観点では1台のデータノードのみの構成と変わらないのです。詳しくはこちらを参照してください。
クラスタのノード数を奇数台にすることで、ネットワーク分断時でもクォーラム（過半数）を満たすグループが存在し、新しいマスターを選出できます。
専用マスターノードを追加する際は、マスターノード3台もしくは5台構成から選択できますが、5台構成ではコストが高くなりすぎるので今回は省略しています。
個人的おすすめパターン
開発環境向け
コストを第１に考えるなら、開発環境向けには
- インスタンスタイプ
t3.small.search - データノード1台
で良いと思います。
もし、スペックを上げたい場合は、t3.medium.searchを選択すると良いかもしれません。
低ワークロード向け
個人的には、
推奨構成を選択するとどうしてもコストがかかりすぎるため、もしある程度のパフォーマンスと安定性を犠牲にしても問題ない場合は、
- インスタンスタイプ
r7g.medium.search - データノード3台
ぐらいからスタートしても良いのかと思います。
そこから、ワークロードに応じてインスタンスタイプやノード数を調整してたり、専用マスターノードを追加していくのが良いと思います。
T系のバーストインスタンスは、ノードの追加やバージョン更新などでシャードの再配置になった際に、CPU利用率が上昇して不安定になるケースがよくあるので、本番利用は利用はやめたほうがいいと思います。
経験上、原因特定と復旧には結構時間がかかります。
本番環境向け
判断が難しいところですが、推奨構成である
- インスタンスタイプ
r6g.large.search - 専用マスターノード3台 + データノード3台
でスタートするのが無難かと思います。（147.6ドル/月×6台=885.6ドル/月となるため、コストが結構かかりますが。。。）
一方、サーバーレス構成 (レプリカ有効)であれば、最低利用料金は488.976ドル/月と推奨構成に比べて安くなりますが、長期間にわたり安定したワークロードが続くのであれば、サーバーレス構成の方がコスト高になる可能性もあります。
また、OpenSearch Serverlessでは一部の OpenSearch API 操作やOpenSearch プラグインはサポートされていなかったりします。
ここら辺の制約が許容できるのであれば、サーバーレス構成を検討するのも良いかもしれません。
もう１点注意としては、OpenSearch ServiceドメインとOpenSearch Serverless Collection間のデータの移行は、AWSではまだ提供されていないので、もし切り替えるとなった際は自前でデータの移行を行う必要があります。
まとめ
OpenSearchの構成において、インスタンスタイプやサーバー構成の選定には意外と考えることが多かったです。
特に本番環境では、クォーラム障害を避けるために奇数台のノードを選定し、専用マスターノードを導入することで、クラスタの安定性を確保するなどの点を考慮する必要があります。
今後のOpenSearchの導入や運用において、この記事が参考になれば幸いです。
