Amazon OpenSearch Service (旧 Elasticsearch Service) とは？AWSでの始め方・使い方

By /

Amazon OpenSearch Service (旧 Elasticsearch Service) とは？AWSでの始め方・使い方 を詳細解説

はじめに：検索・分析基盤の新たな選択肢、Amazon OpenSearch Service

今日のデジタルビジネスにおいて、膨大なデータの収集・蓄積・分析は不可欠です。特に、ウェブサイトのログ、アプリケーションのパフォーマンス監視データ、セキュリティイベントログ、顧客の行動データなど、時間とともに大量に生成される時系列データや、ドキュメント形式の非構造化データを効率的に検索・分析するニーズは高まっています。

このようなニーズに応える強力なツールとして、これまで「Elasticsearch」が広く利用されてきました。Elasticsearchは、全文検索、構造化データ検索、分析、可視化をリアルタイムで行うことができる分散型のRESTful検索・分析エンジンです。そして、AWSはそのマネージドサービスとして「Amazon Elasticsearch Service」を提供し、多くのユーザーがその恩恵を受けてきました。

しかし、Elastic社がElasticsearchおよびKibanaのライセンスモデルを変更したことを受け、AWSを含む多くの組織は、オープンソースの原則を維持し、よりコミュニティ主導の開発を推進するために、ElasticsearchおよびKibanaの最終的なオープンソース版（Apache License, Version 2.0）をフォークしました。これが「OpenSearch」プロジェクトです。

OpenSearchは、Elasticsearch 7.10.2をベースにした検索・分析エンジンと、Kibana 7.10.2をベースにした可視化ツール「OpenSearch Dashboards」から構成されています。そして、AWSは既存のAmazon Elasticsearch ServiceをOpenSearchプロジェクトを基盤としたサービスへと移行・発展させ、名称を「Amazon OpenSearch Service」と改めました。

この記事では、このAmazon OpenSearch Serviceがどのようなサービスであり、AWS上でどのように開始し、実際にデータを投入して活用するのかを、約5000語の詳細な解説を通じてご紹介します。ログ分析、アプリケーション監視、セキュリティ分析、あるいは自社製品への全文検索機能組み込みなどを検討されている方は、ぜひ参考にしてください。

Amazon OpenSearch Serviceとは？概念と特徴

Amazon OpenSearch Serviceは、AWSが提供するフルマネージド型のサービスであり、スケーラブルなOpenSearchクラスターを簡単にデプロイ、運用、スケールすることができます。前述の通り、これは既存のAmazon Elasticsearch Serviceの後継サービスであり、OpenSearchプロジェクトの検索エンジンとOpenSearch Dashboardsを基盤としています。

OpenSearchとOpenSearch Dashboards

  • OpenSearch: Apache License 2.0の下でリリースされている、分散型のRESTful検索・分析エンジンです。高いスケーラビリティと可用性を持ち、全文検索、構造化データ検索、時系列データの分析など、幅広いユースケースに対応します。Elasticsearch 7.10.2との高い互換性を持っています。
  • OpenSearch Dashboards: OpenSearchのためのデータ可視化・UIツールです。Elasticsearch Service時代のKibanaに相当します。データの検索、分析、グラフ作成、ダッシュボード構築などを直感的なWebインターフェイスで行うことができます。

Amazon OpenSearch Serviceは、これらのオープンソースソフトウェアを基盤としながら、AWSのマネージドサービスとしての利点を加えて提供されます。

マネージドサービスとしての利点

Amazon OpenSearch Serviceを利用する最大のメリットは、そのマネージド性です。セルフマネージドでOpenSearch（あるいはElasticsearch）クラスターを構築・運用する場合、以下のような多くの課題が発生します。

  • ハードウェアプロビジョニング: サーバーの選定、購入、セットアップ。
  • ソフトウェアインストールと設定: OpenSearch、Javaなどのインストール、各種設定ファイルの編集。
  • クラスター構成と運用: ノード間の通信設定、シャード分散計画、レプリカ設定。
  • スケーリング: データ量やトラフィック増加に応じたノード追加、再設定。
  • モニタリングとアラート: クラスターの状態、リソース使用率、パフォーマンスの監視。
  • バックアップとリカバリ: 定期的なスナップショット取得、障害発生時のリストア。
  • セキュリティ: 認証、認可、通信の暗号化、ネットワークセキュリティ。
  • バージョンアップグレード: 互換性の確認、ローリングアップグレード手順の実行。
  • 障害対応: ハードウェア故障、ネットワーク問題、ソフトウェアバグへの対応。

これらの運用タスクは専門的な知識と多大な労力を必要とします。Amazon OpenSearch Serviceは、これらの面倒な作業の多くをAWSが代行します。ユーザーは、必要なクラスター構成（ノード数、インスタンスタイプ、ストレージなど）を指定するだけで、数分から数十分でOpenSearchクラスター（ドメインと呼びます）をプロビジョニングできます。その後のモニタリング、パッチ適用、障害時のノード交換などもAWSが行います。これにより、ユーザーはインフラ運用ではなく、データの活用という本来の目的に集中できます。

主要な機能

Amazon OpenSearch Serviceは、OpenSearchが提供する基本的な検索・分析機能に加えて、AWS独自の機能拡張や統合を提供しています。

  • スケーラビリティ: データ量やクエリ負荷に応じて、ノード数を増減させたり、インスタンスタイプを変更したりすることで、容易にスケールアップ・スケールアウトが可能です。
  • 可用性: マルチAZ配置による高可用性構成をサポートしており、ノード障害やAZ障害発生時にもサービスを継続できます。
  • セキュリティ: VPC内での起動によるネットワーク分離、IAMとの連携による細かいアクセス制御、Cognitoを使ったOpenSearch Dashboardsへの認証、保存データの暗号化、ノード間通信の暗号化など、多層的なセキュリティ機能を提供します。
  • 多様なストレージオプション:
    • Hot Storage: 高速な検索・分析に適したSSDベースのストレージ。頻繁にアクセスするデータに使用します。
    • UltraWarm Storage: 大量の読み取り専用データを低コストで保存・分析するためのストレージ層。S3を基盤としており、Hotノードと比較して大幅にコストを削減できます。アクセス頻度は低いが、まれに分析が必要なデータに適しています。
    • Cold Storage: UltraWarmよりさらにコストを抑えた、最も安価なストレージ層。アクセス頻度が非常に低い、長期保存したいデータに適しています。Coldデータにアクセスする際は、まずUltraWarmに復元（warm up）してからクエリを実行します。
  • データの取り込み: Amazon Kinesis Data Firehose, AWS Lambda, Amazon S3, CloudWatch Logsなど、様々なAWSサービスとの連携により、多様なソースからデータを効率的に取り込むことができます。
  • OpenSearch Dashboards: WebブラウザからアクセスできるUIを通じて、データのインデックス作成、検索、分析、可視化、ダッシュボード作成が行えます。旧Kibanaとほぼ同じインターフェイスと機能を提供します。
  • 豊富なプラグイン: OpenSearchプロジェクトおよびAWSが提供する様々なプラグイン（SQL/PPLサポート、異常検知、ISMなど）を利用できます。
  • モニタリングとログ: Amazon CloudWatchと連携し、CPU使用率、メモリ使用率、ディスク使用率、検索/インデックス作成のレイテンシなど、クラスターの主要なメトリクスを詳細に監視できます。また、スローログやエラーログをCloudWatch Logsに出力し、トラブルシューティングに役立てることができます。
  • 自動スナップショット: 設定した期間で自動的にクラスターのスナップショットがS3に保存され、災害対策やデータ復旧に利用できます。
  • ISM (Index State Management): インデックスのライフサイクル（作成、ロールオーバー、UltraWarm/Coldへの移行、削除など）を自動化するポリシーを定義できます。

OpenSearchとElasticsearchの互換性

Amazon OpenSearch Serviceは、OpenSearchエンジンのバージョンに加えて、互換性維持のために特定のElasticsearchバージョン（7.10以下）を選択してドメインを作成することも可能です。既存のElasticsearchクラスターからの移行を容易にするために、APIレベルでの互換性が重視されています。

ただし、Elasticsearchの有料機能や、Elastic社独自のライセンスで提供される一部の機能（例: Machine Learning機能の一部、Security機能の一部高度な設定、Watcherによるアラートなど）は、OpenSearchまたはAmazon OpenSearch Serviceでは利用できないか、代替機能が提供されています（例: Amazon OpenSearch ServiceのAnomaly Detection機能）。OpenSearchはコミュニティ主導で開発が進んでいるため、今後Elasticsearchとは異なる機能進化を遂げる可能性があります。利用したい特定の機能がある場合は、互換性リストやドキュメントで確認することが重要です。

利用シーン

Amazon OpenSearch Serviceは、その柔軟性と強力な機能により、様々なユースケースで活用されています。

  • ログ分析: サーバーログ、アプリケーションログ、システムログなどを集約・分析し、エラーの特定、パフォーマンスの監視、セキュリティイベントの検知を行います。
  • アプリケーションパフォーマンス監視 (APM): アプリケーションのメトリクス、トレース、ログを関連付けて分析し、ボトルネックの特定や障害原因の調査を行います。
  • セキュリティ分析: ファイアウォールログ、侵入検知システムログ、認証ログなどを分析し、不審なアクティビティやセキュリティ脅威を特定します。
  • 全文検索: Webサイト、ドキュメント管理システム、ECサイトなどに強力な検索機能を提供します。曖昧検索、ファセット検索、サジェスト機能などを容易に実装できます。
  • クリックストリーム分析: ユーザーのWebサイト上の行動データ（クリック、ページビューなど）を分析し、マーケティング効果の測定やユーザー体験の向上に役立てます。
  • IoTデータ分析: IoTデバイスから収集される時系列データをリアルタイムに分析し、異常検知やトレンド分析を行います。

AWSでの始め方：OpenSearch Serviceドメインの作成とアクセス設定

Amazon OpenSearch Serviceを利用するには、まず「ドメイン」と呼ばれるOpenSearchクラスターを作成します。ここでは、AWSマネジメントコンソールを使ったドメイン作成手順を詳細に解説します。

ステップ0: AWSアカウントの準備

Amazon OpenSearch Serviceを利用するには、まずAWSアカウントが必要です。まだお持ちでない場合は、AWSのWebサイトでアカウントを作成してください。

ステップ1: OpenSearch Serviceドメインの作成

AWSマネジメントコンソールにサインインし、サービス検索バーで「OpenSearch Service」と入力して選択します。

  1. 「ドメインを作成」ボタンをクリック: OpenSearch Serviceダッシュボードが表示されるので、左側のナビゲーションペインまたは中央の「ドメインを作成」ボタンをクリックします。

  2. デプロイメントタイプとバージョン:

    • デプロイメントタイプ: 用途に応じて選択します。
      • 開発/テスト: 単一ノードの構成など、小規模なテスト環境向け。高可用性は提供されません。
      • 本番: マルチAZ構成などが可能で、高可用性とスケーラビリティが求められる本番環境向け。今回は「本番」を選択します。
    • バージョン: 利用したいOpenSearchまたはElasticsearch互換のバージョンを選択します。特別な理由がない限り、最新のOpenSearchバージョンを選択することをお勧めします。ここでは、例として最新のOpenSearchバージョンを選択します。

  3. ドメイン名:

    • ドメイン名は、作成するOpenSearchクラスターを識別するためのユニークな名前です。AWSアカウント内で一意である必要があります。任意の分かりやすい名前を入力します（例: my-log-analytics-domain）。

  4. インスタンスの設定:

    • データノード:
      • インスタンスタイプ: 各データノードのコンピューティングリソース（CPU、メモリ）を決定します。利用するデータ量、検索/インデックス操作の負荷、必要なパフォーマンスに応じて適切なインスタンスタイプを選択します。rまたはi系のインスタンスタイプは、メモリやストレージI/Oが豊富でOpenSearchに適していることが多いですが、t系やm系も小規模な用途には利用できます。ここでは例として r6g.large.search を選択します。インスタンスタイプによって料金が大きく変わるため、コストとパフォーマンスのバランスを考慮しましょう。
      • インスタンス数: データノードの数を指定します。本番環境では最低2つ（高可用性のため、マルチAZ構成では各AZに1つずつ配置されます）から始め、負荷に応じてスケールアウトします。今回は例として 3 を指定します。
      • UltraWarmデータノード: UltraWarmストレージを利用する場合に有効にします。有効にする場合は、UltraWarmノードのインスタンスタイプと数を指定します。
      • Cold Storage: Cold Storageを利用する場合に有効にします。
    • 専用マスターノード:
      • 専用マスターノードは、クラスターの状態管理（ノードの参加/離脱、シャード割り当てなど）のみを担当するノードです。データノードの負荷からマスターノードの処理を分離することで、クラスターの安定性と信頼性を向上させます。本番環境では、データノードが3つ以上の場合は専用マスターノードを利用することが強く推奨されます（最低3つの専用マスターノードでクォーラムを形成します）。
      • 有効にする場合は、インスタンスタイプと数を指定します。マスターノードはデータ処理を行わないため、データノードより小さめのインスタンスタイプで十分なことが多いです。数としては、安定性のために奇数（3または5）を指定します。今回は例として、有効にしてインスタンスタイプ m6g.large.search、インスタンス数 3 を指定します。
    • Configure data storage: データノードに紐づくストレージを設定します。
      • ストレージタイプ: EBS を選択します。
      • EBSストレージタイプ: gp3 (汎用SSD) がデフォルトで推奨されます。より高パフォーマンスが必要な場合は io1 (プロビジョンドIOPS SSD) を選択します。コスト効率を重視する場合は st1 (スループット最適化HDD) も選択肢になりますが、検索性能はSSDに劣ります。今回は gp3 を選択します。
      • EBS容量: 各データノードに割り当てるストレージ容量をGB単位で指定します。必要なストレージ容量は、保存するデータ量、レプリカ数、インデックスのオーバーヘッドなどを考慮して見積もる必要があります（目安としては、ソースデータ量の1.1倍～2倍程度必要になることが多いです）。今回は例として 100 GB を指定します。
      • Provisioned IOPS: io1 を選択した場合にプロビジョニングするIOPSを指定します。gp3 でもIOPSとスループットを個別設定できますが、デフォルト設定で多くのケースで十分です。

  5. ネットワーク:

    • ネットワークタイプ:
      • VPCアクセス: 推奨される設定です。OpenSearch ServiceドメインをVPC内に配置し、プライベートIPアドレスを通じてアクセスします。これにより、インターネットからの不正アクセスを防ぎ、セキュリティを大幅に向上させます。
      • パブリックアクセス: インターネット経由でドメインにアクセスできるようにします。セキュリティリスクが高いため、特別な理由がない限り推奨されません。利用する場合は、IPアドレス制限などのアクセスポリシーを厳格に設定する必要があります。
      • 今回は VPCアクセス を選択します。
    • VPC: OpenSearch Serviceドメインを配置するVPCを選択します。
    • サブネット: VPC内のサブネットを複数（本番環境では、選択したAZの数と同じ数）選択します。選択したサブネットにデータノードが配置されます。
    • セキュリティグループ: OpenSearch Serviceドメインへのアクセスを許可するセキュリティグループを指定します。通常は、ドメインにアクセスするEC2インスタンスやLambda関数などが所属するセキュリティグループからのインバウンドトラフィック（多くの場合TCP 443またはTCP 9200）を許可する設定を行います。

  6. 詳細な設定:

    • デフォルト設定で問題ないことが多いですが、必要に応じて調整します。
    • シャードの割り当ての認識: クラスターのノードが複数のAZに分散配置されている場合に、プライマリシャードとそのレプリカシャードが同じAZに配置されないようにする設定です。高可用性のために有効化を強く推奨します。
    • ドメイン名によるアクセス: ドメインエンドポイントへのアクセスにドメイン名を使用するかどうか。通常は有効で問題ありません。

  7. アクセスポリシー:

    • OpenSearch Serviceドメインへのアクセスを制御するための重要な設定です。誰が、どのリソースに対して、どのような操作（インデックス作成、検索など）を許可されるかを定義します。
    • 以下のいずれか、または組み合わせて設定します。
      • IAM: AWS Identity and Access Management (IAM) のユーザー、ロール、グループに対してアクセス権限を付与します。最も推奨される方法です。
      • Cognito: OpenSearch DashboardsへのアクセスにAmazon Cognitoユーザープールを使った認証を設定します。
      • IPアドレスベース: 特定のソースIPアドレスからのアクセスのみを許可します（パブリックアクセスの場合に利用されることが多いですが、VPCアクセスでも利用可能です）。
    • ドメインアクセスポリシー: リソースベースのアクセスポリシーです。ドメイン自体にアタッチされ、どのプリンシパル（IAMユーザー/ロール、IPアドレスなど）からのリクエストを許可/拒否するかをJSON形式で記述します。
      • ここでは例として、特定のIAMロールからのアクセスを許可するポリシーを設定します。「カスタムアクセスポリシーの定義」を選択し、JSONエディタでポリシーを記述します。
        json
        {
        "Version": "2012-10-17",
        "Statement": [
        {
        "Effect": "Allow",
        "Principal": {
        "AWS": "arn:aws:iam::<Your-AWS-Account-ID>:role/<Your-IAM-Role-Name>"
        },
        "Action": "es:*",
        "Resource": "arn:aws:es:<Your-Region>:<Your-AWS-Account-ID>:domain/<Your-Domain-Name>/*"
        }
        ]
        }
        <Your-AWS-Account-ID>, <Your-IAM-Role-Name>, <Your-Region>, <Your-Domain-Name> は自身の環境に合わせて置き換えてください。"Action": "es:*" は全ての操作を許可する例です。必要に応じてより細かい権限（es:ESHttpGet, es:ESHttpPost, es:ESHttpPutなど）に絞ることを検討してください。
    • OpenSearch Dashboards認証: OpenSearch Dashboardsへのログイン方法を設定します。
      • IAMユーザーとロールの使用: IAM認証情報を使ってアクセスします。推奨されます。
      • Amazon Cognito認証情報を使用: CognitoユーザープールとIDプールを使って認証を設定します。ユーザーごとにアクセスを管理したい場合に便利です。
      • 基本認証情報の作成: OpenSearch Dashboards用のユーザー名とパスワードを直接作成します（開発/テスト用途推奨、本番ではIAMまたはCognitoを推奨）。

  8. 暗号化:

    • 保存時の暗号化: EBSボリュームに保存されるデータを暗号化するかどうか。機密データを扱う場合は有効化を推奨します。AWS KMSを利用して暗号化キーを管理します。
    • ノード間暗号化: クラスター内のノード間通信をTLSで暗号化するかどうか。セキュリティ向上のために有効化を推奨します。

  9. タグ:

    • コスト管理やリソースの整理のために、タグ（キーと値のペア）を付与します。

  10. メンテナンスウィンドウと自動スナップショット:

    • メンテナンスウィンドウ: AWSがサービスアップデートやパッチ適用を行う時間帯を指定します。影響を最小限にするため、業務時間外などを指定します。
    • 自動スナップショット: 自動スナップショットが取得される頻度と時間帯を指定します。デフォルト設定で問題ないことが多いです。

  11. 設定の確認と作成:

    • 設定内容を確認し、「作成」ボタンをクリックします。
    • ドメインの作成には通常10分から30分程度かかります。ドメインの状態が「アクティブ」になるまで待ちます。

ステップ2: 作成したドメインへのアクセス設定

ドメインが「アクティブ」状態になったら、データ投入やOpenSearch Dashboardsへのアクセスが可能になります。

  1. ドメインエンドポイントの確認: 作成したドメインの詳細画面を開くと、「ドメインエンドポイント」と「OpenSearch Dashboards URL」が表示されます。これらのURLを使ってドメインにアクセスします。
  2. VPCからのアクセス: ドメインをVPC内に作成した場合、そのVPC内にあるEC2インスタンスや、VPC Peering、Transit Gatewayなどを介して接続できるネットワーク内のリソースからのみアクセス可能です。
    • セキュリティグループの設定: ドメイン作成時に指定したセキュリティグループ（または新しく作成したセキュリティグループ）に対して、アクセス元となるEC2インスタンスなどが属するセキュリティグループからのHTTPS (TCP 443) またはHTTP (TCP 80。HTTPS推奨) およびOpenSearch API (TCP 9200など) のインバウンドトラフィックを許可するルールを追加する必要があります。
    • アクセス元リソースからの確認: アクセス元のEC2インスタンスなどから、curl -XGET <ドメインエンドポイント> のようにコマンドを実行して、接続できるか確認します。認証設定によっては、認証情報が必要になります。
  3. アクセスポリシーに応じた認証:
    • IAM認証: アクセス元のEC2インスタンスに、ドメインアクセスポリシーで許可したIAMロールをアタッチします。アプリケーションやコマンドラインツールは、そのロールの認証情報（AWS SDKが自動的に取得します）を使ってOpenSearch APIにリクエストを送信します。例えばPythonのrequestsライブラリを使う場合、aws-requests-authなどのライブラリを使ってリクエストに署名を付与する必要があります。
    • Cognito認証: OpenSearch Dashboardsにアクセスする際に、Cognitoのログイン画面が表示されます。ユーザー名とパスワードで認証します。
    • 基本認証: OpenSearch Dashboardsにアクセスする際に、設定したユーザー名とパスワードを求められます。
    • IPアドレス制限: アクセス元IPアドレスがドメインアクセスポリシーで許可されている必要があります。

ステップ3: OpenSearch Dashboardsへの接続

ブラウザを開き、ドメイン詳細画面に表示されている「OpenSearch Dashboards URL」にアクセスします。

  • 設定した認証方法（IAM, Cognito, 基本認証）に応じてログインします。
  • ログインに成功すると、OpenSearch Dashboardsのホーム画面が表示されます。これで、データの投入、探索、可視化などの操作を行う準備ができました。

Amazon OpenSearch Serviceの使い方：データ投入と活用

OpenSearch Serviceドメインの作成とアクセス設定が完了したら、いよいよデータを投入し、検索・分析に活用していきます。

データの投入方法

OpenSearch Serviceへのデータ投入は、様々な方法で行うことができます。ユースケースやデータソースに応じて最適な方法を選択します。

  1. Logstash:

    • Logstashは、多様なデータソースからデータを収集、変換し、様々な出力先へ転送するためのサーバサイドデータ処理パイプラインです。ログ収集の分野で非常によく利用されます。
    • 使い方: Logstashをデータ収集サーバーにインストールし、設定ファイル（logstash.conf）を作成します。

    • 設定例（基本的なFileInputとOpenSearch Output）:
      “`conf
      input {
      file {
      path => “/var/log/myapp/*.log” # 監視するログファイルのパス
      start_position => “end” # Logstash起動時に既存のファイルをどこまで読み込むか
      sincedb_path => “/path/to/.sincedb” # 読み込み済みの位置を記録するファイル
      type => “myapp_log” # データのタイプ（インデックス名などに利用可能）
      }
      }

      filter {
      # 必要に応じて Grok, Date, Mutate などのプラグインを使ってデータを構造化・整形
      grok {
      match => { “message” => “%{COMBINEDAPACHELOG}” } # Apacheログの例
      }
      date {
      match => [ “timestamp”, “dd/MMM/yyyy:HH:mm:ss Z” ] # タイムスタンプのパース
      }
      mutate {
      convert => { “bytes” => “integer” } # 特定フィールドの型変換
      }
      }

      output {
      amazon_es {
      hosts => [““]
      region => “”
      aws_access_key_id => “” # またはIAMロール/環境変数を使用
      aws_secret_access_key => “” # またはIAMロール/環境変数を使用
      index => “myapp_log-%{+yyyy.MM.dd}” # 日付ベースのインデックス名
      ssl => true # HTTPS接続を有効に
      ssl_certificate_validation => false # 自己署名証明書などの場合、本番では推奨されない
      # user => “” # 基本認証の場合
      # password => “” # 基本認証の場合
      }
      }
      ``
      *      amazon_es`プラグインは、AWS署名バージョン4に対応しており、IAM認証を使って安全にOpenSearch Serviceにデータを投入できます。EC2インスタンスにIAMロールをアタッチする方法が最も推奨されます。
      * Logstashはフィルタリング機能が強力で、非構造化ログから必要な情報を抽出・構造化するのに適しています。

  2. Fluentd/Fluent Bit:

    • Fluentdおよび軽量版のFluent Bitも、ログ収集・転送のための人気のオープンソースツールです。Logstashと同様に、様々な入力元と出力先をサポートします。Fluent Bitは特にリソース消費量が少なく、コンテナ環境やIoTデバイスでの利用に適しています。
    • 使い方: Fluentd/Fluent Bitをデータ収集サーバーやコンテナにインストールし、設定ファイル（fluent.confまたはfluent-bit.conf）を作成します。

    • 設定例（Fluentd）:
      “`conf@type tail
      path /var/log/myapp/*.log
      pos_file /path/to/fluentd/myapp.pos
      tag myapp.log @type apache2 # または他のパーサー、regexなど


      @type amazon_es
      host
      region
      logstash_format true # Logstash形式の日付ベースインデックス名
      logstash_prefix myapp_log
      include_tag_key true
      tag_key @log_name
      ssl_verify false # 本番では推奨されない
      # user “” # 基本認証の場合
      # password “” # 基本認証の場合
      # AWS認証は、IAMロールまたは環境変数で設定可能

      “`
      * Fluentd/Fluent BitにもAmazon OpenSearch Service (Elasticsearch) への出力プラグインがあり、AWS認証をサポートしています。

  3. AWSサービス連携:

    • Amazon Kinesis Data Firehose: ストリーミングデータをOpenSearch Serviceにほぼリアルタイムに配信するためのマネージドサービスです。データのバッファリング、変換、圧縮を自動で行ってくれます。
      • 使い方: Kinesis Data Firehoseの配信ストリームを作成し、送信先としてAmazon OpenSearch Serviceを選択します。データ変換が必要な場合は、AWS Lambdaを指定して変換処理を記述できます。データソース（例: Kinesis Data Streams, CloudWatch Logs, IoT Core）からFirehoseにデータを送信するように設定します。
      • メリット: サーバーレスで運用が容易、データのバッファリングやリトライが自動で行われるため信頼性が高い、スケーラビリティが高い。
    • AWS Lambda: イベント駆動でコードを実行できるサーバーレスコンピューティングサービスです。S3へのファイルアップロード、SQSキューへのメッセージ到着、DynamoDB Streamsの更新などをトリガーにしてLambda関数を実行し、その関数内でOpenSearch Serviceにデータを書き込むことができます。
      • 使い方: トリガーとなるイベントソースを設定し、OpenSearch ServiceのPythonやNode.jsなどのクライアントライブラリを使ってデータを投入するLambda関数を作成します。
      • メリット: 柔軟なデータ変換処理が可能、サーバーレスで運用が容易、様々なAWSサービスをトリガーにできる。
    • Amazon S3: S3に蓄積されたログファイルなどを、バッチ処理としてOpenSearch Serviceに投入する場合に利用します。LambdaやAWS Glueなどを使ってS3上のファイルを読み込み、OpenSearch Serviceに書き込む処理を実装します。
    • CloudWatch Logs: CloudWatch Logsに集約されたログデータをOpenSearch Serviceにストリーミングできます。
      • 使い方: CloudWatch Logsのロググループを選択し、「アクション」から「サブスクリプションフィルターの作成」→「Amazon Kinesis Data Firehose」を選択します。Firehoseの送信先にOpenSearch Serviceを指定しておけば、CloudWatch Logsから自動的にログが転送されます。

  4. プログラムからの直接投入 (REST API):

    • アプリケーションから直接OpenSearch ServiceのREST APIを呼び出してデータを投入します。特に、構造化された少量のデータをリアルタイムに投入する場合などに利用されます。
    • 使い方: OpenSearchのREST API（例: POST /<index>/_doc で単一ドキュメント、POST /_bulk で複数ドキュメントを一括投入）を呼び出します。HTTPクライアントライブラリや、各言語向けのOpenSearch/Elasticsearchクライアントライブラリ（Pythonのelasticsearch-py/opensearch-py, JavaのHigh-Level REST Clientなど）を使用します。
    • 認証: IAM認証を使う場合は、SigV4署名ライブラリ（例: Pythonのaws-requests-auth）と組み合わせて利用します。
    • Bulk API: 大量のデータを効率的に投入するには、Bulk APIを使用することが強く推奨されます。1つのHTTPリクエストで複数のドキュメントのインデックス、更新、削除操作を実行できます。

データの検索と分析 (OpenSearch Dashboards)

OpenSearch Serviceにデータが投入されたら、OpenSearch Dashboardsを使ってデータの探索、検索、分析、可視化を行います。

  1. Discover:

    • 投入されたデータを時系列で表示し、探索するための画面です。
    • 左上のタイムピッカーで表示する時間範囲を選択します。
    • 表示するインデックスパターン（例: myapp_log-*）を選択します。
    • 中央にドキュメントのリストが表示されます。各ドキュメントを展開して詳細を確認できます。
    • 左側のフィールドリストから、表示したいフィールドを選択・絞り込むことができます。
    • 上部の検索バーにクエリを入力して、特定のドキュメントを検索します。Luceneクエリ構文やOpenSearch Query DSL (Domain Specific Language) を使用できます。
      • Luceneクエリ例: status:200 AND response_time:>1000 (ステータスコードが200で応答時間が1000msを超えるドキュメント)
      • Query DSL例 (Dev Toolsで実行):
        json
        GET myapp_log-2023.10.27/_search
        {
        "query": {
        "bool": {
        "must": [
        { "match": { "message": "error" } },
        { "range": { "timestamp": { "gte": "now-1h" } } }
        ]
        }
        }
        }
    • フィルターを追加して、特定の条件に一致するドキュメントのみを表示できます。

  2. Visualize:

    • データから様々なグラフやチャートを作成するための画面です。
    • 「Create new visualization」をクリックし、グラフタイプ（棒グラフ、折れ線グラフ、円グラフ、ヒートマップ、マップなど）を選択します。
    • データソースとなるインデックスパターンを選択します。
    • X軸、Y軸、集計方法（Aggregation）などを設定してグラフを作成します。
      • 集計 (Aggregations): OpenSearchの強力な機能の一つで、大量のデータをグループ化、集計、分析できます。
        • Terms: 特定のフィールドの値でグループ化し、各グループのドキュメント数をカウント（例: ステータスコード別のアクセス数）。
        • Date Histogram: 時系列フィールドを指定した間隔（分、時、日など）でグループ化（例: 時間ごとのリクエスト数）。
        • Metrics: 各グループに対して集計値を計算（例: count, avg, sum, min, maxなど）。
        • 他にも、Geo-distance, Filters, Samplerなど多様なAggregationタイプがあります。
    • 作成した可視化は保存して、Dashboardに配置できます。

  3. Dashboard:

    • 作成した複数の可視化（Visualize）や、Discoverの検索結果などを集約して一つの画面に表示する機能です。
    • システムの全体状況や特定の指標の推移などを一目で把握するための「監視ダッシュボード」を作成できます。
    • 各パネルはインタラクティブで、例えば特定のグラフの一部をクリックすると、関連する他のパネルやDiscoverのデータも自動的にフィルタリングされます。

  4. Dev Tools:

    • OpenSearchのREST APIを直接実行できるコンソールです。インデックスの作成/削除、マッピングの確認/変更、ドキュメントの手動投入、Query DSLやAggregationのテスト、クラスター状態の確認など、高度な操作やデバッグに利用します。

  5. Searching and Querying:

    • OpenSearchの検索は、Luceneベースの転置インデックスを利用しており、高速な全文検索が可能です。
    • クエリには、シンプルクエリ（検索バー）や、より複雑なQuery DSLを使用します。
    • Query DSL: JSON形式で記述され、フルテキスト検索、フレーズ検索、ワイルドカード検索、正規表現検索、あいまい検索、条件検索（範囲、ターム）、論理演算（AND, OR, NOT）、ブースト設定など、豊富な検索機能を利用できます。
    • SQL/PPL: OpenSearchは、SQL (Structured Query Language) または PPL (Piped Processing Language) を使ってデータを検索・分析する機能も提供しています。SQLライクなクエリで直感的にデータを扱いたい場合に便利です。OpenSearch Dashboardsの「SQL Query Workbench」または「PPL Query Workbench」で実行できます。

高度な機能

Amazon OpenSearch Serviceは、OpenSearchの機能に加えて、運用を効率化したり、高度な分析を可能にする機能を提供しています。

  • Index State Management (ISM): インデックスのライフサイクル管理を自動化します。時間の経過とともにインデックスに対して、UltraWarm/Coldへの移行、スナップショット取得、削除などのアクションを実行するポリシーを設定できます。例えば、「ログデータインデックスは7日後にUltraWarmに移行し、90日後に削除する」といったポリシーを設定できます。
  • UltraWarm and Cold Storage: 大量の古いデータを低コストで保持するためのストレージ層です。Hot Storageと比較して大幅にコストを削減できます。UltraWarmのデータはHotノードと同じようにクエリ可能ですが、パフォーマンスはHotに劣ります。Cold Storageのデータはクエリ前にwarm upが必要です。
  • Trace Analytics: OpenTelemetryやJaeger、X-Rayなどのトレーシングシステムから収集した分散トレーシングデータをOpenSearch Serviceに取り込み、OpenSearch Dashboardsで可視化・分析できます。サービス間のリクエストフロー追跡、レイテンシの分析、エラーの特定などに役立ちます。
  • Anomaly Detection: 機械学習アルゴリズムを使って、時系列データ内の異常を自動的に検知する機能です。アプリケーションのメトリクス（エラーレートの急増、応答時間の異常など）やセキュリティログ（通常と異なるログイン試行など）の異常を早期に発見するのに役立ちます。OpenSearch Dashboardsで設定・監視できます。
  • Observability: ログ、メトリクス、トレースといった可観測性データをOpenSearch Serviceで一元的に管理・分析するための機能です。関連データをシームレスに横断検索・分析できます。
  • Security Analytics: セキュリティイベントログ（SIEMデータなど）を分析し、既知の脅威パターンとのマッチングや異常検知を通じて、セキュリティ脅威を特定するための機能です。Sigmaルール形式での検知ルール定義などをサポートします。

運用と管理

Amazon OpenSearch Serviceを安定して、効率的に運用するためには、以下の点に注意が必要です。

  • モニタリング: Amazon CloudWatchと連携して、OpenSearch Serviceドメインの主要なメトリクス（CPU使用率、メモリ使用率、ディスク使用率、Cluster Status, Indexing Rate, Search Rate, Error Rateなど）を監視します。重要なメトリクスに対してアラームを設定し、閾値を超えた場合に通知を受けるように設定します。
  • ログ: OpenSearch Serviceは、エラーログ、検索スローログ、インデックススローログを出力できます。これらのログを有効化し、CloudWatch Logsに出力することで、クラスターの問題やパフォーマンスボトルネックの調査に役立てることができます。
  • スケーリング: データ量の増加やクエリ負荷の増大に応じて、データノードのインスタンス数やインスタンスタイプを変更してクラスターをスケールアウト・スケールアップできます。また、ストレージ容量もオンラインで拡張可能です。これらの操作はマネジメントコンソールやAPIから簡単に行えます。
  • バージョンアップグレード: OpenSearchやElasticsearchの新しいバージョンがリリースされると、Amazon OpenSearch Serviceでも利用可能になります。マネジメントコンソールから簡単な操作でバージョンアップグレードを実行できます。アップグレード前に互換性を確認し、本番環境への適用はメンテナンスウィンドウを考慮して計画的に行うことが重要です。
  • スナップショット: Amazon S3にOpenSearchクラスターのスナップショットを自動で保存する機能がデフォルトで有効になっています。手動でスナップショットを取得したり、特定のスナップショットからクラスターを新しいドメインとして復元することも可能です。データのバックアップと障害復旧に不可欠な機能です。
  • コスト管理: Amazon OpenSearch Serviceの料金は、主に利用しているインスタンス（データノード、マスターノード、UltraWarmノード）の種類と稼働時間、使用しているストレージ（Hot, UltraWarm, Cold）の容量、データ転送量、スナップショットストレージ容量などによって決まります。データ量やアクセス頻度に応じて、適切なインスタンスタイプ、ストレージタイプ（特にUltraWarm/Coldの活用）、ノード数を選択することで、コストを最適化できます。また、リザーブドインスタンスを利用することで、長期間利用するインスタンスのコストを削減できます。

移行について (旧 Elasticsearch Serviceからの移行)

既存のAmazon Elasticsearch Serviceドメインをご利用の場合、AWSによって自動的にAmazon OpenSearch Serviceドメインとして扱われるようになっています。名称は変更されましたが、Elasticsearch互換バージョン（7.10以下）を選択していたドメインは、そのまま引き続き利用できます。

OpenSearchプロジェクトはElasticsearch 7.10.2をベースとしているため、APIレベルでの互換性が高く、ほとんどのユースケースでは大きな変更なしにOpenSearch Serviceに移行できます。

もし、セルフマネージドのElasticsearchクラスターからAmazon OpenSearch Serviceへ移行したい場合は、以下の方法が利用できます。

  • Snapshot/Restore: 既存のElasticsearchクラスターでS3リポジトリへのスナップショットを作成し、Amazon OpenSearch Serviceでそのスナップショットを登録してリストアする方法です。
  • Reindex API: 既存のElasticsearchクラスターから、HTTP経由でAmazon OpenSearch Serviceドメインへデータを直接Reindex（再インデックス）する方法です。
  • データ投入パイプラインの移行: LogstashやFluentdなどのデータ投入ツールから、出力先を既存クラスターから新しいOpenSearch Serviceドメインに切り替える方法です。

具体的な移行手順は、元のクラスターのバージョンや構成によって異なるため、公式ドキュメントを参照しながら慎重に進める必要があります。

料金体系

Amazon OpenSearch Serviceの料金は、以下の要素によって決まります。

  • EC2インスタンス時間: データノード、専用マスターノード、UltraWarmノードのインスタンスタイプごとの料金と、稼働時間（秒単位）に基づいて課金されます。
  • EBSボリューム: Hot Storageとして使用しているEBSボリュームのタイプ（gp3, io1など）とプロビジョニング容量（GB月額）に基づいて課金されます。
  • UltraWarmストレージ: UltraWarmストレージに保存されているデータ量（GB月額）に基づいて課金されます。
  • Coldストレージ: Coldストレージに保存されているデータ量（GB月額）に基づいて課金されます。
  • スナップショットストレージ: Automated SnapshotとしてS3に保存されているスナップショットデータの容量（GB月額）に基づいて課金されます。最初の特定の容量（例: 15GB/月）は無料の場合があります。
  • データ転送量: AWS内外へのデータ転送に対して課金されます（通常、同じリージョン内のAWSサービス間や、インターネットからのインバウンド転送は無料または低額です）。

料金を最適化するためには、以下の点を考慮します。

  • ワークロードに合った適切なインスタンスタイプと数を慎重に選択する。
  • アクセス頻度が低い古いデータはUltraWarmまたはCold Storageに移行する。
  • 長期間（1年または3年）利用することが確定しているワークロードには、リザーブドインスタンスを利用する。
  • 不要になったインデックスやドメインは削除する。
  • ISMを活用して、データのライフサイクル管理を自動化し、コスト効率の良いストレージ層への移行や削除を自動化する。

最新かつ詳細な料金情報は、AWS公式サイトのAmazon OpenSearch Service料金ページを必ずご確認ください。

まとめ：Amazon OpenSearch Serviceで検索・分析基盤を構築しよう

Amazon OpenSearch Serviceは、OpenSearchプロジェクトを基盤とした、AWSが提供するフルマネージドな検索・分析サービスです。旧Amazon Elasticsearch Serviceのユーザーは自動的にこの新しいサービスに移行され、Elasticsearchとの高い互換性を保ちつつ、OpenSearchの新しい機能やコミュニティの恩恵を受けられます。

このサービスを利用することで、インフラの構築・運用に煩わされることなく、ログ分析、アプリケーション監視、セキュリティ分析、全文検索などの多様なユースケースに対応するスケーラブルで可用性の高い検索・分析基盤を迅速に構築できます。OpenSearch Dashboardsを使った直感的なデータ探索、可視化、ダッシュボード構築が可能であり、さらにISM、UltraWarm/Cold Storage、異常検知といった高度な機能を利用することで、運用効率を高め、より高度なデータ活用を実現できます。

AWSマネジメントコンソールを使えば、数ステップでOpenSearch Serviceドメインを作成し、様々な方法でデータを投入、OpenSearch Dashboardsからデータの分析を開始できます。セキュリティ、スケーラビリティ、可用性もAWSのインフラとマネージドサービスとしての機能によって担保されます。

もしあなたが、増加し続けるログやイベントデータを効率的に検索・分析したい、あるいは強力な全文検索機能をアプリケーションに組み込みたいと考えているなら、Amazon OpenSearch Serviceは非常に有力な選択肢となるでしょう。まずは小規模なドメインを作成し、サンプルデータを使ってOpenSearch Dashboardsの機能を試してみることから始めてみてはいかがでしょうか。そして、必要に応じてスケールアップ・スケールアウトし、UltraWarmやCold Storageを活用することで、コスト効率良く大規模なデータ分析基盤を構築していくことができます。

検索・分析の世界は常に進化しています。OpenSearchプロジェクトは活発なコミュニティによって開発が進められており、Amazon OpenSearch Serviceも今後さらなる機能強化が期待されます。このパワフルなサービスを使いこなし、あなたのビジネスにおけるデータ活用の可能性を最大限に引き出してください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール