ElasticsearchおよびKibanaのデプロイ
Elasticsearchは、オープン・ソースのエンタープライズ・グレードの検索エンジンです。Elasticsearchでは、広範なAPIを介してアクセスできるため、データ検出アプリケーションをサポートするクイック検索を強化できます。何千ものサーバーをスケーリングし、ペタバイトのデータに対応できます。大容量は、複雑な分散アーキテクチャから直接引き出されます。
Elasticsearchの最も一般的なユースケースは、構造化データ・ソースおよび非構造化データ・ソースからの超高速データ抽出を使用した分析と、広範な問合せ言語および自動補完による全文検索です。
アーキテクチャ
このリファレンス・アーキテクチャでは、ElasticsearchおよびKibanaのクラスタ化されたデプロイメントを示します。
図elk-oci.pngの説明
このアーキテクチャには、次のコンポーネントがあります。
- 可用性ドメイン
可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。可用性ドメインは、電源や冷却などのインフラストラクチャや内部可用性ドメイン・ネットワークを共有しません。したがって、ある可用性ドメインで障害が発生しても、リージョン内の他の可用性ドメインに影響する可能性はほとんどありません。
- フォルト・ドメイン
フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインには、独立した電源とハードウェアを備えた3つのフォルト・ドメインがあります。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションでは、フォルト・ドメイン内の物理サーバー障害、システム・メンテナンスおよび電源障害を許容できます。
- 要塞ホスト
要塞ホストは、クラウド外部からトポロジへのセキュアで制御されたエントリ・ポイントとして機能するコンピュート・インスタンスです。要塞ホストは通常、非武装地帯(DMZ)でプロビジョニングされます。これにより、クラウドの外部から直接アクセスできないプライベート・ネットワークに機密リソースを配置することで、機密リソースを保護できます。トポロジには、定期的に監視および監査できる単一の既知のエントリ・ポイントがあります。したがって、トポロジのより機密性の高いコンポーネントへのアクセスを損なうことなく、公開を回避できます。
- ロード・バランサ
ロード・バランサは、データ・ノードに対する索引操作と、マスター・ノードに対するKibanaアクセスのバランスを取ります。マスター・ノードのバックエンドとデータ・ノードのバックエンドを使用して、Kibana用と索引データ・アクセス用の2つのリスナーを使用します。ロード・バランサは、パブリックIPアドレスを持つパブリック・サブネットにあります。
- マスター・ノード
マスター・ノードは、索引の作成やシャードのリバランスなどのクラスタ管理タスクを実行します。データは格納されません。高可用性を確保するために、3つのフォルト・ドメインに3つのマスター・ノード(大規模なクラスタに推奨)がデプロイされます。
- データノード
高可用性のために、3つのフォルト・ドメインに3つのデータ・ノードがデプロイされます。Elasticsearchは使用可能なメモリー量に依存するため、メモリーが最適化されたコンピュート・インスタンスをお薦めします。各データノードは200個のGiBブロックストレージで構成されます。Oracle Cloud Infrastructureは、VMに加えて、クラスタ内で非オーバーサブスクリプション25 Gbネットワーク・インフラストラクチャに接続された強力なベア・メタル・インスタンスを提供します。この構成により、低レイテンシと高スループットが保証され、高パフォーマンスの分散ストリーミング・ワークロードが実現します。
- Kibana
マスター・ノードと同様に、Kibanaには比較的軽いリソース要件があります。ほとんどの計算はElasticsearchにプッシュされます。このデプロイメントでは、Kibanaはマスター・ノードで実行されます。
推奨事項
実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。開始点として次の推奨事項を使用します。
- VCN
VCNを作成する場合、VCNのサブネットにアタッチする予定のリソースの数に基づいて、必要なCIDRブロックの数と各ブロックのサイズを決定します。標準のプライベートIPアドレス空間内にあるCIDRブロックを使用します。
VCNを作成した後、CIDRブロックを変更、追加および削除できます。
サブネットを設計する際には、トラフィック・フローとセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。
リージョナル・サブネットを使用します。
- ネットワーク・セキュリティ・グループ(NSG)
NSGを使用して、特定のVNICに適用されるイングレス・ルールおよびエグレス・ルールのセットを定義できます。NSGではVCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストではなくNSGを使用することをお薦めします。リファレンス・アーキテクチャでは、すべてのネットワーク通信はNSGを介して制御されます。
- ブロック・ストレージ
このアーキテクチャでは、200 GBのブロック・ストレージが使用されます。より多くの領域が必要な場合は、ボリュームを拡張できるように論理ボリューム・マネージャ(LVM)を構成することをお薦めします。各ブロック・ボリュームは、バランスのとれたパフォーマンスを使用するように構成され、35,000 IOPSおよび480 MBpsのスループットを提供します。
- コンピュート・シェイプ
このアーキテクチャーは、すべてのデータノードに仮想マシンシェイプ(VM.Standard2.24)を使用します。これらのコンピュート・インスタンスは25 Gbpsでトラフィックをプッシュし、320 GBのRAMを提供できます。
注意事項
- パフォーマンス
Elasticsearchは、使用可能なメモリーの量によって異なります。最高のパフォーマンスを得るには、適切な量のメモリーを提供するコンピュート・シェイプを使用します。最大768 GBのRAMを搭載できるベア・メタル・シェイプを使用できます。
- 可用性
フォルト・ドメインは、可用性ドメイン内で最善のリジリエンスを提供します。可用性を高める必要がある場合は、デプロイメントに複数の可用性ドメインまたは複数のリージョンを使用することを検討してください。
- 拡張性
マスター・ノードとデータ・ノードは手動でスケール・インおよびスケール・アウトできますが、高負荷でリソースのサービスが不足する可能性を最小限に抑えるために自動スケーリングを使用することをお薦めします。自動スケーリング戦略では、マスター・ノードとデータ・ノードの両方を考慮する必要があります。
- コスト
Elasticsearchデプロイメントのコストは、メモリーおよび可用性の要件によって異なります。選択したコンピュート・シェイプは、このアーキテクチャに関連するコストに大きな影響を与えます。
デプロイ
この参照アーキテクチャのデプロイに必要なコードは、GitHubで入手できます。シングルクリックでコードをOracle Cloud Infrastructure Resource Managerにプルし、スタックを作成してデプロイできます。または、GitHubからコンピュータにコードをダウンロードし、Terraform CLIを使用してコードをカスタマイズし、アーキテクチャをデプロイします。
- Oracle Cloud Infrastructure Resource Managerを使用してデプロイします。
をクリックしますまだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。
- 条件を確認し、受け入れます。
- スタックをデプロイするリージョンを選択します。
- 画面に表示されるプロンプトと指示に従って、スタックを作成します。
- スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
- ジョブが完了するまで待機し、計画を確認します。
変更を加えるには、「Stack Details」ページに戻り、「Edit Stack」をクリックして、必要な変更を行います。次に、プラン処理を再度実行します。
- これ以上変更が必要ない場合は、「Stack Details」ページに戻り、「Terraform Actions」をクリックして、「Apply」を選択します。
- Terraform CLIを使用してデプロイします。
- GitHubに移動します。
- コードをローカル・コンピュータにダウンロードまたはクローニングします。
cluster/single-ad/README.mdの手順に従います。