OCI Search Service (OpenSearch)

解決する課題

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

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

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

主要概念と用語

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

仕様・制限・クォータ

• クラスタはノードの役割（マスター・データなど）と形状（シェイプ）、ストレージ容量を選んで構成する
• スループットや容量は主にデータノード数・ノード形状・シャード設計で決まり、ノード追加やレプリカ調整でスケールする
• 可用性を高めるには複数のデータノードと専用マスターノードを配置し、レプリカを持たせる構成にする
• クラスタは VCN のサブネットに配置するプライベート構成が基本で、ネットワーク到達性を制御できる
• サポートされる OpenSearch のバージョンは更新されるため、アップグレード可否や互換性は最新の公式ドキュメントで確認する
• ノード数・形状・ストレージ総量などは**テナンシのサービス制限（リミット）**の範囲で確保し、不足時は引き上げ申請を行う

内部の仕組み

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

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

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

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

運用・監視

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

コスト

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

セキュリティ

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

Well-Architected の観点

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

試験で問われるポイント

関連サービス・比較

OCI 内では、ログを集約・分析する Logging Analytics が用途の一部で重なります。Logging Analytics が OCI のログに特化したフルマネージド分析サービスであるのに対し、Search Service は汎用的な 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