はじめに

こんにちは。インフラエンジニアの鈴木です。
この記事は、株式会社asken (あすけん) Advent Calendar 2024 の20日目の記事です。

あすけんでは、一部機能でOpenSearchを使い始めています。
たとえば、前にバックエンドの高橋さんがOpenSearchを活用したメニュー検索を記事にしてくれています。
今回は、OpenSearchを商用サービスで半年運用した経験で得られたノウハウとして、商用運用における注意点や、パフォーマンスを上げるための方法を記載します。

※本記事では、Amazon OpenSearch Service（AWS上で提供されるOpenSearch）を前提としています。

OpenSearchは何に使うか

OpenSearchは主に検索に使用し、代表的な用途は「文字列検索」や「ベクトル検索」です。
特に、文字列の部分一致検索はRDBMSなどのデータベースでは重くなりがちなため、OpenSearchの活用が適しています。
OpenSearchの基本的な構成についてはこちらのブログが参考になります。

OpenSearchを利用する際のノウハウ

本記事で紹介するノウハウは、文字列検索やベクトル検索といった異なる検索用途においても共通して適用可能なものです。
運用上、優先して押さえておくべきノウハウを以下にまとめました。
もっと幅広く詳細なノウハウが知りたい方はAWS公式のベストプラクティスに記載されているため、そちらも参照してください。

1. VPC内（プライベートネットワーク）に配置しよう

ポイント：セキュリティ強化のため、OpenSearchはVPC内に配置しましょう。
- VPC内に配置することで、接続元をセキュリティグループで限定できます。
- パブリック配置でもIP制限などが可能ですが、アクセス自体はできて権限が無いというエラーになるため、存在が第三者に認識されるリスクがあります。
課題と解決策：
- VPC内に配置すると、OpenSearchが持っているダッシュボード（Kibana）へのアクセスが課題となります。
  - ダッシュボードを表示するにはVPC外のローカルマシンからVPC内にアクセスできる必要があります。
- 以下のような解決策があります。
  - セッションマネージャでポートフォワーディングして、ブラウザからアクセス（参考ブログ）
    
    ポートフォワーディング設定のコマンド例
```
  aws ssm start-session --target  [SSM接続できるEC2のインスタンスID] \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["OpenSearchエンドポイント"],"portNumber":["443(OpenSearchのポート)"],"localPortNumber":["ブラウザから接続するポート"]}'
```
  - Amazon WorkSpaces Secure Browserを使って、ブラウザからアクセス（参考ブログ)）

2. 高可用性構成を作ろう

ポイント：OpenSearchの商用運用では、可用性を高めるために以下を実施しましょう。
- 3AZ構成：ノードを3つのAZに分散配置
- スタンバイAZを設定： 1つのAZをスタンバイ専用に設定
- マスターノードの導入：検索処理とは別にノード管理を担当する専用ノードを設定
東京リージョンでの構成例
- AZに合わせてノードを作成するため、「3の倍数」でノードを作成します。
  - 例: データノード6台、マスターノード3台で構成

[補足]

スタンバイAZ
- 3AZに配置することで可用性が高まりますが、さらにOpenSearchでは可用性を高めるために1つのAZをまるごとスタンバイにする機能があります。
- スタンバイになるAZは一定時間で入れ替わるので、AZ障害のときにもこの設定だけで対応できます。
マスターノード
- ノードの増減やデプロイなどの管理作業を専門に実施するノードです。
- マスターノードを作らずとも、データノードで同じことはしてくれるのですが、本来の検索処理とは別のことをさせるので安定性が下がります。

3. シャードとレプリカ配置の戦略を考えよう

OpenSearchを扱う上で避けたいけど避けられないものがあります。それが「シャード」です。
プライマリシャードとレプリカシャードがありますが、どう設定して良いか悩む箇所です。
「プライマリシャード」：元データを分割したもの。
「レプリカシャード」：プライマリシャードを複製したもの。
シャードの設定がOpenSearchの性能に影響してきます。

ポイント：用途、ストレージサイズ、ノード数からシャード数を考えましょう。
- シャード数を考える基本式は以下になります。
  全シャード数 = プライマリシャード数 + (プライマリシャード数 × レプリカシャード数)

[各シャード数の考え方]

プライマリシャード数：用途とストレージサイズを元に決定
- 1つのシャードが10～30 GiB (検索ワークロードの場合) または 30～50 GiB (ログワークロードの場合)になるように分割します。
レプリカシャード数：データノードの数を元に決定
- すべてのデータノードにシャードが配置されるようにします。
  - 例：データノード3台なら、プライマリシャード1つに対しレプリカシャード2つ
    - データノードに対してレプリカを含めたシャードの数は足りているのかがハマるポイントになるため、以下のように図示して整理するとわかりやすいです。
      
      OpenSearchシャード構成イメージ
      （実際は各ノードに対して、もっとバラバラに配置されますが、分かりやすく並べてます）

4. JVM メモリを監視しよう

OpenSearchはJavaベースで動作しており、JVMメモリの状態が性能に大きな影響を与えます。

ポイント：メモリ使用率ではなく「JVMMemoryPressure」（JVMメモリ負荷）を監視しましょう
JVMMemoryPressure（平均値）はいくつであれば良いのか（参考）
- 40-60%以下：実際に運用してみての経験から、安定運用可能です
- 75%以上：GarbageCollector（GC）発動による性能低下の可能性があります。JVMメモリ負荷が 75% に達すると、GCが発動して速度が落ちます
- 92%以上：書き込みオペレーションをブロックします
- 100%：JVMメモリ不足によるプロセス強制終了（OOM）を引き起こします
  
  以下は実際に運用しているときのJVMMemoryPressureの抜粋です。緑色の線が平均値で40-60%以下で安定推移しています。