Amazon OpenSearch Serviceのバックプレッシャーとアドミッションコントロールによる回復力の向上

このブログは、Improved resiliency with backpressure and admission control for Amazon OpenSearch Service を翻訳したものです。

Amazon OpenSearch Service は、AWS クラウドで OpenSearch クラスターを大規模に安全にデプロイし運用するのを簡単にするマネージドサービスです。昨年、Shard indexing backpressure とアドミッションコントロールを導入しました。これはクラスターリソースと入力トラフィックをモニタリングして、メモリ不足などの安定性のリスクを引き起こす可能性のあるリクエストを選択的に拒否したり、メモリの競合、CPUの飽和、GC オーバーヘッドなどによるクラスターパフォーマンスへの影響を軽減します。

OpenSearch Service の Search Backpressure と CPU ベースのアドミッションコントロールをご紹介できることを嬉しく思います。これにより、クラスターの回復力がさらに向上します。これらの改善は、OpenSearch のバージョン 1.3 以降のすべてのバージョンで利用できます。

Search Backpressure

バックプレッシャーは、システムが作業で圧倒されるのを防ぐ機構です。
バックプレッシャーは、クラッシュやデータ損失を防ぎ、パフォーマンスを改善し、システムの完全な障害を回避するために、トラフィックレートの制御や過剰な負荷を削減します。

Search Backpressure は、ノードが負荷状態にあるときに実行中のリソース集約型の検索リクエストを識別してキャンセルするメカニズムです。これは、ノードのクラッシュやクラスター全体の健全性への影響を引き起こしうる、異常に高いリソース使用量(複雑なクエリ、遅いクエリ、多数のヒット、重い集計など)を伴う検索ワークロードに対して効果的です。

Search Backpressure は、タスクのリソースを追跡するフレームワークの上に構築されており、各タスクのリソース使用量を監視するための使いやすい API を提供しています。Search Backpressure はバックグラウンドスレッドを使用してノードのリソース使用量を定期的に測定し、CPU時間、ヒープ割り当て、経過時間などの要因に基づいて実行中の各サーチタスクにキャンセルスコアを割り当てます。キャンセルスコアが高いほど、よりリソースを必要とするサーチリクエストになります。サーチリクエストはキャンセルスコアの降順にキャンセルされてノードが迅速に回復しますが、無駄な作業を避けるためにキャンセルされる数はレート制限されます。

次の図は、Search Backpressure のワークフローを示しています。

検索リクエストのキャンセル時には、HTTP 429 “Too Many Requests” ステータスコードが返されます。OpenSearch は、失敗したシャードが一部の場合に限り、部分的な結果を返します。以下のコードを参照してください:

{
    "error": {
        "root_cause": [
            {
                "type": "task_cancelled_exception",
                "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]"
            }
        ],
        "type": "search_phase_execution_exception",
        "reason": "SearchTask was cancelled",
        "phase": "fetch",
        "grouped": true,
        "failed_shards": [
            {
                "shard": 0,
                "index": "nyc_taxis",
                "node": "9gB3PDp6Speu61KvOheDXA",
                "reason": {
                    "type": "task_cancelled_exception",
                    "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]"
                }
            }
        ],
        "caused_by": {
            "type": "task_cancelled_exception",
            "reason": "cancelled task with reason: heap usage exceeded [403mb >= 77.6mb], elapsed time exceeded [1.7m >= 45s]"
        }
    },
    "status": 429
}

Search Backpressure　のモニタリング

ノードステータス API を使用して、詳細な Search Backpressure の状態を監視できます:

curl -X GET "https://{endpoint}/_nodes/stats/search_backpressure"

Amazon CloudWatch を使用して、クラスタ全体のキャンセルの概要も確認できます。次のメトリクスが ES/OpenSearchService 名前空間で利用可能です:

SearchTaskCancelled – コーディネーターノードのキャンセル数
SearchShardTaskCancelled – データノードのキャンセル数

次のスクリーンショットは、CloudWatch コンソールでこれらのメトリクスを追跡する例を示しています。

CPU ベースのアドミッションコントロール

アドミッションコントロールは、現在の容量に基づいてノードへのリクエスト数を先取りして制限するゲートキーパーメカニズムで、通常のトラフィック増加やスパイクトラフィックの両方に対応します。

JVM メモリプレッシャーとリクエストサイズのしきい値に加えて、移動平均の CPU 使用率をモニタリングして、入力される _search と _bulk リクエストを拒否するようになりました。
これにより、ノードが多数のリクエストで圧倒されてホットスポット、パフォーマンスの問題、リクエストのタイムアウト、その他の連鎖的な障害が発生するのを防ぎます。
過剰なリクエストは、拒否時に HTTP 429 “Too Many Requests” ステータスコードが返されます。

HTTP 429 エラーの処理

ノードに過剰なトラフィックを送信すると、HTTP 429 エラーが発生します。これは、クラスタリソースが不足しているか、リソース消費の激しい検索リクエストが発生しているか、意図しないワークロードのスパイクが発生したことを示しています。

Search Backpressure は、拒否をする理由を提供します。これにより、リソース消費の激しい検索リクエストを微調整できます。
トラフィックスパイクの場合、エクスポネンシャルバックオフとジッターを用いたクライアント側のリトライをおすすめします。

過剰な拒否をデバッグするために、これらのトラブルシューティングガイドも参考にできます:

結論

Search Backpressure は、過剰な負荷を削減するリアクティブなメカニズムで、アドミッションコントロールは、ノードの容量を超えるリクエスト数を制限するプロアクティブなメカニズムです。
この2つは協調して、OpenSearch クラスタの全体的な回復力を高めます。

Search Backpressure は OpenSearch で利用できます。私たちは常に外部からのコントリビューションを歓迎しています。まずはじめに、RFC を参照してください。

翻訳は Solutions Architect 深見が担当しました。

著者について

Ketan Verma は、Amazon OpenSearch Service で働くシニアソフトウェア開発エンジニアです。大規模分散システムの構築、パフォーマンスの改善、シンプルな抽象化による複雑なアイデアの単純化に情熱を注いでいます。仕事外では、読書を楽しみ、自宅バリスタのスキルを磨いています。