OpenSearchでOCI検索サービスを使用してログを集計します

OpenSearch (OracleのOpenSearch管理サービス)を使用したOCI検索サービスを使用すると、強力な索引を活用して、大規模なデータセットを検索し、結果をミリ秒単位で表示できます。OpenSearchは、Apache 2.0のライセンスElasticsearch 7.10.2とKibana 7.10.2から導出されたコミュニティ主導型のオープンソース検索とアナリティクス・スイートです。

OpenSearchを使用したOCI検索サービスは、次のもので構成されます。
  • 検索エンジン・デーモン- OpenSearch
  • 視覚化およびユーザー・インタフェース- OpenSearchダッシュボード
OpenSearchを使用したOCI検索サービスでは、同じElasticsearchおよびKibana APIを活用できるため、既存のスタックを簡略に移行できます。
OpenSearchを使用したOCI Searchサービスはどのような場合に役立ちますか。
  • ログの分析
    • イベント・データを格納、調査および接続して、問題をできるだけ迅速に検出して修正し、アプリケーションのパフォーマンスを向上させます。
    • イベント・データの季節変動に対応するために、クラスタ・サイズをシームレスに拡張します。
    たとえば、出張インセンティブ会社は、OCI検索サービスをOpenSearchとともに使用して、複数のプロバイダにわたるコール量を分析し、問題を迅速にターゲット設定して解決し、顧客リクエストが目的のチームに到達するようにできます。
  • アプリケーションの検索

    アプリケーション、Webサイトおよび大規模なデータ・リポジトリでは、データセットのサイズが常に増加し、高速でカスタマイズされた検索エクスペリエンスが必要になります。OpenSearchを使用したOCI検索サービスでは、特定のデータ/ページのソース頻度または時間に基づく最も高速な結果を有効にできます。

    たとえば、フォト・アーカイブ・ビジネスでは、最近リクエストしたイメージに対して、アクセス頻度の低い古いイメージをウォーム・ストレージに移動して索引付けをできるかぎり高速に保つために、画像結果をより速くレンダリングできます。

アーキテクチャ

このリファレンス・アーキテクチャは、サーバーのロギング、処理および統合のための簡単なユースケースを示します。

次の図は、この参照アーキテクチャを示しています。



oci-opensearch-log-analytics-arch-oracle.zip

上の図は、OCI上の簡略化された高可用性アプリケーション環境を示しています。ロード・バランサの背後にある2つの仮想マシン・インスタンスに焦点を当てています。インスタンスは2つの異なる可用性ドメインに存在します。

各仮想マシン・インスタンスは、ログの転送にファイル・ビートを使用します。ファイル・ビートは、仮想マシン・インスタンスにインストールされた軽量エージェントで、指定したログ・ファイルと場所をモニターし、ログ・イベントを収集してLogstashに転送します。

ログの解析および変換のためのデータ処理パイプラインであるLogstashは、2つの異なる可用性ドメインに配置されたインスタンスで実行されます。Logstashは、変換されたログをOpenSearchでOCI検索サービスに送信します

OpenSearchを使用したOCI検索サービスは、組込みの冗長性を持つリージョン別マネージド・サービスです。OpenSearchを使用したOCI検索サービスは、OpenSearchおよびOpenSearchダッシュボードのプライベート・エンドポイントを備えているため、トラフィックはインターネットを通過しません。

ローカル・マシンからOpenSearchを使用してOCI検索サービスに接続するには、パブリック・サブネットの要塞ホスト、およびインターネット・ゲートウェイをターゲットとするルート・ルールを設定します。ポート転送に要塞ホスト(SSHトンネリングとも呼ばれる)を使用し、マシン内の選択したポートと、目的のOpenSearch/OpenSearchダッシュボード・プライベート・エンドポイント宛先ポートとのセキュアな接続を作成できます。
  • OpenSearchの場合は9200
  • 5601 (OpenSearchダッシュボード)
プライベート・サブネットに存在するアプリケーション・インスタンスには、要塞ホストからアクセスすることもできます。

アーキテクチャには次のコンポーネントがあります。

  • テナント

    テナンシは、Oracle Cloud Infrastructureのサインアップ時にOracleがOracle Cloud内で設定するセキュアで分離されたパーティションです。テナンシ内のOracle Cloudでリソースを作成、整理および管理できます。テナンシは、会社または組織と同義です。通常、会社は1つのテナンシを持ち、そのテナンシ内の組織構造を反映します。単一のテナンシは通常1つのサブスクリプションに関連付けられており、1つのサブスクリプションには通常1つのテナンシのみが含まれます。

  • ポリシー

    Oracle Cloud Infrastructure Identity and Access Managementポリシーでは、誰がどのリソースにアクセスできるか、およびその方法を指定します。アクセスはグループ・レベルおよびコンパートメント・レベルで付与されます。つまり、特定のコンパートメントまたはテナンシ内の特定のアクセスのタイプをグループに付与するポリシーを作成できます。

  • コンパートメント

    コンパートメントは、Oracle Cloud Infrastructureテナンシ内のリージョン間論理パーティションです。コンパートメントを使用して、Oracle Cloudでリソースを編成し、リソースへのアクセスを制御し、使用割当てを設定します。特定のコンパートメント内のリソースへのアクセスを制御するには、誰がリソースにアクセスできるか、および誰が実行できるアクションを指定するポリシーを定義します。

  • 仮想クラウド・ネットワーク

    OCIの最初のステップの1つは、クラウド・リソースの仮想クラウド・ネットワーク(VCN)を設定することです。VCNは、OCIリージョンに設定したソフトウェア定義ネットワークです。VCNはサブネットに分割できます。サブネットはリージョンまたは可用性ドメインに固有です。リージョン固有および可用性ドメイン固有のサブネットの両方が同じVCN内に共存できます。サブネットはパブリックまたはプライベートにできます。

  • 可用性ドメイン

    アベイラビリティ・ドメインは、リージョン内のスタンドアロンで独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。アベイラビリティ・ドメインは電源や冷却、内部アベイラビリティ・ドメイン・ネットワークなどのインフラを共有しません。そのため、1つの可用性ドメインで障害が発生しても、リージョン内の他の可用性ドメインには影響しません。

  • Bastionホスト

    Bastionホストは、クラウド外部からのトポロジに対するセキュアで制御されたエントリ・ポイントとして機能するコンピュート・インスタンスです。プライベート・ネットワークに配置されている機密リソースにアクセスでき、クラウドの外部から直接アクセスすることはできません。トポロジには、定期的に監視および監査できる単一の既知のエントリ・ポイントがあるため、トポロジへのアクセスを損なうことなく、より機密性の高いコンポーネントの公開を回避できます。

  • ロード・バランサ

    Oracle Cloud Infrastructure Load Balancingサービスは、1つのエントリ・ポイントからバックエンド内の複数のサーバーへの自動トラフィック分散を提供します。

  • コンピュート・インスタンス

    Oracle Cloud Infrastructure Computeでは、コンピュート・ホストのプロビジョニングおよび管理が可能です。リソース要件(CPU、メモリー、ネットワーク帯域幅およびストレージ)を満たすシェイプでコンピュート・インスタンスを起動できます。コンピュート・インスタンスの作成後、セキュアにアクセスしたり、再起動したり、ボリュームのアタッチとデタッチを行ったり、不要なときに終了したりできます。

  • インターネットゲートウェイ

    インターネット・ゲートウェイによって、VCNのパブリック・サブネットとパブリック・インターネット間のトラフィックが許可されます。

  • 動的ルーティング・ゲートウェイ(DRG)

    DRGは、VCNとリージョン外のネットワーク(別のOracle Cloud Infrastructureリージョン内のVCN、オンプレミス・ネットワーク、別のクラウド・プロバイダ内のネットワークなど)間のプライベート・ネットワーク・トラフィックのパスを提供する仮想ルーターです。

  • Vault

    Oracle Cloud Infrastructure Vaultでは、クラウド内のリソースへのアクセスを保護するために使用するデータやシークレット資格証明を保護する暗号化キーを集中管理できます。

  • サイト間VPN

    Site-to-Site VPNは、オンプレミス・ネットワークとOracle Cloud Infrastructure内のVCN間のIPSec VPN接続を提供します。IPSecプロトコル・スイートは、パケットがソースから宛先に転送される前にIPトラフィックを暗号化し、到着時にトラフィックを復号化します。

  • FastConnect

    Oracle Cloud Infrastructure FastConnectは、データ・センターとOracle Cloud Infrastructureの間の専用プライベート接続を簡単に作成する方法を提供します。FastConnectは、インターネットベースの接続と比較して、高帯域幅のオプションとより信頼性の高いネットワーキング体験を提供します。

  • Webアプリケーション・ファイアウォール(WAF)

    Oracle Cloud Infrastructure Web Application Firewall (WAF)は、ロード・バランサやWebアプリケーション・ドメイン名などの強制ポイントにアタッチされた、PCI (PCI)準拠の地域ベースおよびエッジ強制サービスです。WAFは、悪意のある不要なインターネット・トラフィックからアプリケーションを保護します。WAFは、インターネット接続エンドポイントを保護することで、顧客のアプリケーションに対する一貫したルール適用を実現できます。

推奨

開始点として次の推奨事項を使用します。実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。
  • VCN

    VCNを作成する際、必要なCIDRブロックの数と、VCNのサブネットにアタッチする予定のリソース数に基づいて各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。

    プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは他のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。

    VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。

    サブネットを設計する際は、トラフィック・フローおよびセキュリティ要件を考慮してください。セキュリティ境界として機能する、特定の層またはロール内のすべてのリソースを同じサブネットにアタッチします。

  • セキュリティ

    ポリシーを使用して、会社が所有するOCIリソースにアクセスできるユーザーと、そのアクセス方法を制限します。OpenSearchクラスタの作成でOCI検索サービスを成功させるには、特定のポリシーが必要です。ボールトを使用して、キー、証明書およびシークレットをさらに保護します。

    ネットワーキング・サービスには、セキュリティ・ルールを使用してパケット・レベルでトラフィックを制御する2つの仮想ファイアウォール機能(セキュリティ・リストおよびネットワーク・セキュリティ・グループ(NSG)があります。NSGは、単一のVCN内の選択したセットのVNICのみに適用される一連のイングレスおよびエグレス・セキュリティ・ルールで構成されます。たとえば、VCN内の複数層アプリケーションのWeb層でWebサーバーとして機能するすべてのコンピュート・インスタンスを選択できます。

    NSGセキュリティ・ルールはセキュリティ・リスト・ルールと同様に機能します。ただし、NSGセキュリティ・ルールのソースまたは宛先では、CIDRブロックのかわりにNSGを指定できます。そのため、セキュリティ・ルールを記述して、同じVCN内の2つのNSG間のトラフィック、または1つのNSG内のトラフィックを簡単に制御できます。データベース・システムを作成する場合、1つ以上のNSGを指定できます。また、既存のデータベース・システムを更新して、1つ以上のNSを使用することもできます。

  • コンピュート

    適切なOCPUとメモリーの組合せでシェイプを選択し、各インスタンスに対して必要に応じてローカルNVMeまたはブロック・ストレージをプロビジョニングします。

注意事項

このアーキテクチャを実装するときは、次のパラメータの要件を考慮してください。

  • ロギング

    このリファレンス・アーキテクチャでは、ログ解析および変換にLogstashを使用します。

    ファイル・ビートは、ログをOpenSearchに直接送信することもできます。この方法は、単一の種類のログ、または非常に均一なログの場合に使用できます。ファイル・ビートでは、ログの高度なフィルタリングおよび変換の機能がないため、フォーマットが異なる場合、異なる種類のログの集約が困難になります。

  • インスタンス

    このリファレンス・アーキテクチャでは、Logstash専用のインスタンスを使用します。別の方法として、Logstashは各ソース・インスタンスまたはサーバーで実行できます。これにより、ソース・インスタンスまたはサーバーでリソース消費が増加します。

    Logstashの高可用性のために、複数のインスタンスをフォルト・ドメインやアベイラビリティ・ドメインに分散することを検討します。ファイル・ビートは、個別のロード・バランサを使用せずに、Logstashインスタンス間でロード・バランシングできます。

  • 永続キュー

    Logstashの永続キューの構成を検討します。Logstash永続キューは、処理中のメッセージ・キューをディスクに保存することで、異常終了時のデータ損失に対する保護に役立ちます。

謝辞

  • 作成者: Nuno Goncalves
  • コントリビュータ: Jordan Oliver、Hassan Ajan、Mark de Visser、Samuel Herman、Anupama Pundpal