OpenSearch ベースのマルチテナント集中ログプラットフォームにおけるワークロード管理

本記事は 2025 年 7 月 22 日 に公開された「Workload management in OpenSearch-based multi-tenant centralized logging platforms」を翻訳したものです。

現代のアーキテクチャは、目標を達成するために多くの異なるテクノロジーを使用しています。サービス指向アーキテクチャ、クラウドサービス、分散トレーシングなどは、テレメトリやその他のシグナルデータのストリームを生成します。これらのデータストリームはそれぞれ、ログバックエンドのテナントになります。企業が複数のアプリケーションを実行している場合、IT チームはログデータの保存と処理を集中化することが多く、各アプリケーションはオブザーバビリティシステム全体のテナントになります。

Amazon OpenSearch Service を使用してログデータを保存および分析する場合、開発者であっても IT 管理者であっても、各テナントがデータを取り込み、保存、クエリできるようにリソースを提供するために、これらのテナントのバランスを取る必要があります。この記事では、ルールベースのプロキシと OpenSearch ワークロード管理を使用した多層ワークロード管理フレームワークを紹介します。これにより、これらの課題に効果的に対処できます。

ユースケースの例

この記事では、ヘルスケア、金融、小売、セキュリティ、および社内テナントをサポートする架空の企業 GlobalLog が、OpenSearch Service を使用して集中ログシステムを構築した事例について説明します。各テナントは、ビジネス要件に基づいた固有のログパターンを持っています。金融テナントは複雑で大量のクエリを生成し、ヘルスケアテナントは中程度のボリュームのログとクエリでコンプライアンスに重点を置き、小売テナントは季節的なスパイクとダッシュボードの多用を経験します。社内運用は安定した低ボリュームのログと、まれで単純なクエリを持っています。セキュリティ監視はシステム全体で常に高ボリュームの存在感を持っています。

GlobalLog のテナントがスケールするにつれて、運用上の課題が浮上しました。ピーク時に高優先度テナントのパフォーマンスが低下し、リソース集約型のクエリがノードクラッシュを引き起こし、予測不可能なトラフィックが不安定性を生み出しました。テナントのリソース使用状況の可視性が限られていたため、トラブルシューティングやクロスドメインのセキュリティ調査が複雑になりました。プラットフォームには、さまざまなワークロードパターンとピーク使用時間の堅牢な処理、テナント間の干渉を防ぐ強力なパフォーマンス分離、および年間 30% のデータ増加を管理するスケーラビリティが必要でした。

ソリューションの概要

GlobalLog は、テナントの多様な要求に対応するための包括的なワークロード管理戦略を実装しました。このソリューションは、階層化されたテナント配置、テナントプロファイルと OpenSearch クラスターのステータスに基づいて受信トラフィックを整形するルールベースのプロキシレイヤー、および各テナントの階層に比例して CPU やメモリなどのリソースを割り当てるきめ細かなリソースガバナンスを提供する OpenSearch ワークロード管理プラグインでテナンシーを管理します。監視コンポーネントは、ソリューションが評価を行い、トラフィックガバナンスのルールとポリシーをタイムリーに調整することで、リアクティブおよびプロアクティブなスケーリングとパフォーマンス関連の決定を行うために必要なインテリジェンスを提供します。

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

テナントの階層化と配置

GlobalLog は、ログ要件 (ボリューム、保持期間、クエリ頻度) に基づいてテナントを 4 つの階層に分類し、それに応じてリソースを割り当てました。統合されたプロキシレイヤーと OpenSearch ワークロード管理を通じて適用される階層化システムは、サービスレベルがビジネスの優先度に一致するようにしながら、リソースの過剰割り当てを防ぎます。各階層の仕様は次の表に詳述されています。

GlobalLog の統合アーキテクチャは、コスト配分とリソース配分モデルを合理化します。金融業界のテナントは、保証された高パフォーマンスリソースに対してプレミアム料金を支払い、より変動の大きいワークロードをサポートするインフラストラクチャを実質的に補助しています。これらのテナントは Tier 1 に分類されます。ヘルスケアテナントは、専用インフラストラクチャの全コストを負担することなく、コンプライアンスを強制する分離の恩恵を受けます。これらのテナントは Tier 2 に分類されます。小売テナントは、年間を通じて過剰な容量を維持することなく、ピークシーズン中の弾力的な容量を評価するため、Tier 3 に分類されます。Tier 4 には、効率的なリソース共有を通じて手頃な料金でエンタープライズグレードのログにアクセスできる管理テナントが含まれます。

このバランスの取れたエコシステムにより、GlobalLog は、業界固有のワークロード特性に関係なく、すべてのテナントに適切なサービスレベルを提供しながら収益性を維持できます。

次のセクションでは、GlobalLog のワークロード管理システムについて説明します。

プロキシレイヤー

GlobalLog の継続的なフィードバックループアーキテクチャは、OpenSearch Service 全体で多様なテナントワークロードにわたるリソース割り当てを最適化する動的なエコシステムを作成します。静的な構成に依存するのではなく、アーキテクチャはパフォーマンスメトリクスとテナントの使用パターンを監視して、スケーリングと修復の決定を推進します。これにより、ワークロードが時間とともに変化してもシステムが進化します。

プロキシレイヤーのコアコンポーネントは OpenSearch Traffic Gateway で、クライアントと OpenSearch クラスター間の仲介として機能します。主な機能は次のとおりです。

• リクエストパスとパラメータのパターンマッチングによるルールベースのトラフィックシェーピング
• リソースコスト配分のためのメトリクス
• トラフィックリプレイ

GlobalLog は、集中化、動的性、適応性に焦点を当てた包括的な拡張セットを通じて、OpenSearch Traffic Gateway の機能を拡張しました。この進化の中核として、重要なゲートウェイデータの集中リポジトリとして Amazon DynamoDB を使用しました。この中央データベースには、ルール、ポリシー、テナントプロファイルの完全なエコシステムに加えて、メトリクス、使用パターン、SLA 要件、階層構成、リアルタイムのクラスターステータス情報などの重要な運用データが格納されています。

この集中化の取り組みに加えて、GlobalLog はリアルタイムの調整と応答性の高い意思決定が可能な動的メカニズムでゲートウェイを変革しました。このアーキテクチャの変更により、ゲートウェイは事前に決められた経路をたどるのではなく、変化する条件にインテリジェントに反応できます。

さらに、GlobalLog は高度なコンテキスト認識を備えた適応型ルールシステムを実装しました。システムは現在のクラスター状態とテナントの使用パターンに基づいて特定のルールをアクティブ化し、仮想的なシナリオではなく実際の条件に応答する正確なリソース割り当てと保護メカニズムを可能にします。システムは時間ベースのルールスケジューリングを実装し、メンテナンスウィンドウなどの特定の期間中に異なる制限とポリシーを自動的に適用できる柔軟性を提供します。これにより、必要なシステム運用に対応しながら最適なパフォーマンスを提供します。

このソリューションは、監視システム、OpenSearch クラスター、およびプロキシレイヤー間の継続的なフィードバックループを実装しています。パフォーマンスメトリクスとテナントの使用パターンのフローが、自動化されたルールベースのスケーリングと最適化の決定を推進し、ワークロードが時間とともに変化してもシステムが進化するのを助けます。このアーキテクチャでは、Amazon EventBridge が事前定義された基準が満たされたとき (例えば、OpenSearch Service で異常が検出されたとき) に AWS Lambda 関数をトリガーし、Lambda 関数がトラフィックシェーピングルールを調整して OpenSearch Traffic Gateway にアップロードすることで問題を修復する手順を実行します。フィードバックループを安定させるために、GlobalLog は次の手順を実行しました。

• 急速なルール変更を防ぐためのダンピングメカニズムを追加
• バイナリスイッチの代わりに段階的な調整パターンを実装
• ベースラインルールへの自動フォールバックのためのサーキットブレーカーを作成

OpenSearch ワークロード管理レイヤー

GlobalLog は、OpenSearch ワークロード管理を通じてテナントレベルのアドミッション制御とリアクティブなクエリ管理を実装しました。システムはワークロード管理を使用して、テナントの重要度に基づいてリソース制限を定義し、効率的なリソース割り当てを提供してボトルネックを防ぎます。

OpenSearch のワークロード管理の主要コンポーネントはワークロードグループです。ワークロードグループは、リソースの管理とワークロードの優先順位付けに通常使用されるクエリの論理的なグループ化を指します。GlobalLog は、以前に定義されたテナント階層に基づいてリソース割り当てを管理するためにワークロードグループを使用します。エンタープライズクリティカルなワークロードは、金融業務に一貫したパフォーマンスを提供する大幅な CPU とメモリの保証を受けます。ビジネスクリティカルなテナントは中程度のリソース保証で運用され、スタンダードとベーシックの階層は、より低い優先度ステータスを反映して、より制約されたリソースで機能します。次の例は、エンタープライズクリティカルとビジネスクリティカルの階層のワークロードグループ設定を示しています。

PUT _wlm/workload_group
{
  "name": "Enterprise Critical",
  "resiliency_mode": "enforced",
  "resource_limits": {
    "cpu": 0.5,
    "memory": 0.5
  }

PUT _wlm/workload_group
{
  "name": "Business Critical",
  "resiliency_mode": "enforced",
  "resource_limits": {
    "cpu": 0.3,
    "memory": 0.25
  }

OpenSearch は、エンタープライズクリティカル階層のテナントに対して、設定されたリソース制限とワークロードグループの ID を返します。

{
"_id":"preXpc67RbKKeCyka72_Gw",
  "name":"analytics",
 "resiliency_mode":"enforced",
 "resource_limits":{
"cpu":0.5,
 "memory":0.5
  },
 "updated_at":1726270204642
}

ワークロードグループを使用するには、次のコードを使用します。

GET finindex/_search
Host: localhost:9200
Content-Type: application/json
workloadGroupId: preXpc67RbKKeCyka72_Gw
{
 "query": {
      "match": {
             "field_name": "value"
     }
}
}

実際のユースケース

このセクションでは、GlobalLog のワークロード管理システムが企業のさまざまな課題を克服するのに役立った 2 つのシナリオについて説明します。

シナリオ 1: セキュリティインシデント対応

重大なセキュリティインシデント中、GlobalLog は、それぞれ異なる優先度レベルを持つ複数のビジネスユニットからの同時ログアクセスリクエストを管理するという複雑な課題に直面しました。最上位階層はセキュリティと金融業務 (Tier 1)、次にヘルスケア業務 (Tier 2)、小売業務 (Tier 3)、社内業務 (Tier 4) でした。

プロキシレイヤーでは、GlobalLog はセキュリティと金融テナントのクエリを優先し、他のユニットには特定の制限を実装しました。ヘルスケア業務は同時クエリ 15 件に制限され、小売業務は 1 分あたり 5 クエリに制限され、社内業務は日付範囲が狭められました。

OpenSearch ワークロード管理とプロキシレイヤーは、高 CPU 使用率時の複雑な小売クエリのキャンセルを含め、リソース圧力を管理しながらセキュリティチームのクエリ優先度を維持することで重要な役割を果たしました。

シナリオ 2: 月末レポート

月末レポート期間中、GlobalLog は複数のテナントからの集中的な分析ワークロードを正常に処理しました。時間ベースのルールの実装は特に効果的で、通常の月末のオフピーク営業時間中にバッチレポート用に Tier 4 テナントを優先しました。次のコードは、このコンテキストでの GlobalLog ルールの例を示しています。最初のルールは、オフピーク営業時間中に Tier 4 テナントがレポートを実行することを許可し、2 番目のルールは営業時間中に Tier 4 テナントのリクエストを拒否します。

monthlyReportAllowRule",
"ruleConfig": {
"tenantTier": "tier4$",
"timeWindow": {
     		"dayOfMonth": "25-30",
      		"hours": "18:00-8:00"
    	      }
               }
monthlyReportDenyRule",
"ruleConfig": {
"tenantTier": "^tier4$",
"timeWindow": {
     	       "dayOfMonth": "25-30",
      	       "hours": "9:00-18:00"
    	      }
               }

システムは、OpenSearch ワークロード管理 API を使用して、オフピーク時間 (午後 6 時〜午前 8 時) の Tier 4 テナントのリソース割り当てを動的に調整しました。

この包括的なアプローチは、ピークレポート期間の管理に非常に成功し、すべてのテナント階層にわたってシステムの安定性と最適なパフォーマンスの両方を促進しました。

まとめ

継続的なフィードバックループアーキテクチャにおけるプロキシレイヤーのトラフィックシェーピングと OpenSearch ワークロード管理プラグインの統合により、多様なビジネス優先度をサポートしながら、回復力、安定したパフォーマンス、公平なリソース割り当てを実現しました。この記事で説明した実装は、大規模なマルチテナントログ環境が、パフォーマンスとコスト効率を維持しながら、共有インフラストラクチャ上で多様なビジネスニーズに効果的に対応できることを示しています。

これらのワークロード管理テクニックをご自身のユースケースで試して、フィードバックや質問をコメントで共有してください。

著者について

Ezat Karimi は、テキサス州オースティンを拠点とする AWS のシニアソリューションアーキテクトです。Ezat は、データベースアプリケーションのモダナイゼーションソリューションと戦略の設計と提供を専門としています。複数の AWS チームと緊密に連携し、お客様のデータベースワークロードの AWS クラウドへの移行を支援しています。

Jon Handler は、カリフォルニア州パロアルトを拠点とする AWS のシニアプリンシパルソリューションアーキテクトです。Jon は OpenSearch と Amazon OpenSearch Service に密接に関わり、ベクトル、検索、ログ分析のワークロードを AWS クラウドに移行したいと考えている幅広いお客様にヘルプとガイダンスを提供しています。AWS に入社する前、Jon はソフトウェア開発者として、大規模な e コマース検索エンジンのコーディングに 4 年間携わりました。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピュータサイエンスと人工知能の理学修士号と博士号を取得しています。

この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。