OCI Search with OpenSearch

解決する課題

全文検索やログ・メトリクスの分析基盤として OpenSearch（旧 Elasticsearch 系）を使いたいが、クラスタの構築、ノードのプロビジョニング、バージョンのパッチ適用、シャード設計やスケール調整といった運用負荷を抱えたくない、という課題に応えます。現行名称は OCI Search with OpenSearch で、インデックス設計と検索クエリそのものに集中できます。

• アプリケーションに全文検索や曖昧一致、ファセット検索を組み込みたい
• 大量のログやイベントを集約して分析・可視化したい
• OpenSearch クラスタの構築・パッチ・スケールの運用から解放されたい
• OpenSearch の API・クエリ DSL を使い、既存の検索資産を移行したい

AWS でいえば、マネージドな OpenSearch を提供する Amazon OpenSearch Service に近い立ち位置です。

主要概念と用語

• クラスタ（Cluster）: OpenSearch のノード群をまとめた実行単位。検索・分析の本体で、OCI Search with OpenSearch が構築・管理する
• ノード（Node）: クラスタを構成する個々のインスタンス。leader（クラスタ管理）、data（索引保持・検索）を基本に、必要に応じて search（検索専用）、coordinator（要求の振り分け・集約）、ML、OpenSearch Dashboards の役割を分離できる。旧 master の現行名称が leader
• インデックス（Index）: ドキュメントの集合。リレーショナル DB のテーブルに近い概念で、検索の対象単位になる
• ドキュメント（Document）: インデックスに格納される JSON 形式の1レコード
• シャード（Shard）: インデックスを分割した単位。複数ノードへ分散させてスループットと容量をスケールさせる
• レプリカ（Replica）: シャードの複製。可用性を高め、読み取り（検索）の並列度を上げる
• OpenSearch Dashboards: データの可視化・探索・ダッシュボード構築を行う Web UI（Kibana 相当）
• クエリ DSL: 検索条件を JSON で記述する OpenSearch の問い合わせ言語

仕様・制限・クォータ

• クラスタはノードの役割（leader・dataを基本に、search・coordinator・ML・Dashboardsを必要に応じて分離）と形状（シェイプ）、ストレージ容量を選んで構成する
• スループットや容量は主にデータノード数・ノード形状・シャード設計で決まり、ノード追加やレプリカ調整でスケールする
• 可用性を高めるには複数のデータノードと専用 leader ノードを配置し、レプリカを持たせる構成にする
• クラスタは VCN のサブネットに配置するプライベート構成が基本で、ネットワーク到達性を制御できる
• サポートされる OpenSearch のバージョンは更新されるため、アップグレード可否や互換性は最新の公式ドキュメントで確認する
• ノード数・形状・ストレージ総量などはテナンシのサービス制限（リミット）の範囲で確保し、不足時は引き上げ申請を行う
• パッチ適用、水平スケール、形状変更を伴う垂直スケールでは、処理中のクラスタが読み取り専用になる。形状を変えないストレージ容量の増加は例外なので、書き込み停止を伴う操作を保守時間帯へ置く

内部の仕組み

横にスクロール

OCI Search with OpenSearch はノードへ役割を割り当てて分散検索を実現します。データをインデックスに投入すると、インデックスは複数のシャードに分割され、各シャードがデータノードへ分散配置されます。検索クエリはコーディネーティング処理が各シャードへ分散実行し、結果をマージして返します。

• インデックスはシャードに分割され、シャードを複数のデータノードに分散することで容量とスループットをスケールできる
• レプリカシャードを持たせると、プライマリを保持するノードが障害を起こしても複製から検索を継続でき、可用性が向上する
• 専用 leader ノードはクラスタ状態の管理に専念し、データノードと役割を分けることでクラスタの安定性が増す
• ノードはコンパートメント内の VCN サブネットに配置され、セキュリティリストやネットワークセキュリティグループで到達範囲を制御する
• 可視化や探索は OpenSearch Dashboards から行う。OpenSearch 向けのツールやライブラリは流用しやすいが、Elasticsearch から移行する場合はバージョン、API、プラグインの互換性を事前に検証する

設計パターン / ベストプラクティス

• シャード数は事前に見積もる。シャードが多すぎても少なすぎてもオーバーヘッドや偏りを生むため、データ量と成長見込みから設計する
• 本番では専用 leader ノードを置き、データノードを複数の可用性ドメイン／障害ドメインに分散して単一障害点を避ける
• 検索の可用性とスループットを高めたいインデックスにはレプリカを持たせる
• ログ分析では時系列インデックス（日付などで分割）を採り、古いインデックスを削除・縮小しやすくする
• 取り込みはバルク投入でまとめ、1件ずつの書き込みによるオーバーヘッドを避ける
• 可視化・探索は OpenSearch Dashboards に集約し、アプリ側は検索 API のみを使うよう責務を分ける

運用・監視

• クラスタやノードの状態は OCI コンソールおよび OCI Monitoring のメトリクスで監視する
• クラスタ内部の負荷（ヒープ使用率、検索/インデックスのレイテンシ、シャードの偏りなど）は OpenSearch Dashboards の監視機能から把握できる
• クラスタ作成・スケール・削除などの操作は OCI Audit に記録され、変更履歴を追跡できる
• バージョンのパッチ適用やアップグレードはマネージド側で支援されるが、パッチや多くのスケール操作ではクラスタが読み取り専用になるため、取り込み停止と再開確認を保守手順へ組み込む
• 検索レイテンシの悪化やヒープ逼迫が見られる場合は、データノードの増設・形状見直し・シャード設計の調整を検討する

コスト

Search Service のコストは主に「クラスタを構成するノードのコンピュート時間」と「ノードに割り当てたストレージ容量」で構成されます。クラスタが稼働している間ノードに課金されるため、ノード数・形状・レプリカ数の適正化が最適化の鍵になります。具体的な単価は変動するため、見積もりは最新の料金情報で行ってください。

セキュリティ

• クラスタは VCN のサブネット内に配置するプライベート構成が基本で、セキュリティリストやネットワークセキュリティグループでアクセスを制限する
• クラスタの管理操作（作成・スケール・削除）の権限は IAM ポリシーで最小権限に絞る
• OpenSearch 側ではユーザー・ロールベースのアクセス制御でインデックスや操作の権限を制御する
• 通信は TLS による暗号化で保護し、保存データの暗号化や OCI Vault のカスタマー管理キー（CMK） による鍵管理も利用できる
• 認証情報やシークレットは設定へ直書きせず、OCI Vault のシークレットで管理する

Well-Architected の観点

• パフォーマンス効率: データノード数・形状・シャード/レプリカ設計でスループットを調整し、バルク投入と時系列インデックスでオーバーヘッドを抑える
• 信頼性: 専用 leader ノードとレプリカ、複数の障害ドメインへの分散で単一障害点を排除する
• 運用上の優秀性: パッチ・スケール・バージョン管理がマネージドで、Dashboards と Monitoring でクラスタを可視化できる
• セキュリティ: プライベート配置・IAM ポリシー・ロールベースアクセス制御・TLS と暗号化で多層に保護する

試験で問われるポイント

関連サービス・比較

OCI 内では、ログを集約・分析する Logging Analytics が用途の一部で重なります。Logging Analytics が OCI のログに特化したフルマネージド分析サービスであるのに対し、OCI Search with OpenSearch は汎用的な OpenSearch クラスタを提供し、検索 API やインデックス設計を自由に扱える点が異なります。

ハンズオン / CLI例

# 1. OpenSearch クラスタ一覧を確認（コンパートメント内）
oci opensearch cluster list \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --output table

# 2. 既存クラスタの詳細を取得（ノード構成・状態を確認）
oci opensearch cluster get \
  --opensearch-cluster-id ocid1.opensearchcluster.oc1..xxxx

# 3. データノードを増やしてスケールアウト（クラスタを更新）
oci opensearch cluster update \
  --opensearch-cluster-id ocid1.opensearchcluster.oc1..xxxx \
  --data-node-count 4

# 4. クラスタの状態を確認する（LIFECYCLE: CREATING -> ACTIVE）
oci opensearch cluster get \
  --opensearch-cluster-id ocid1.opensearchcluster.oc1..xxxx \
  --query 'data."lifecycle-state"' --raw-output