【ITニュース解説】"Rate Limiting for Workloads Within Istio

システムエンジニアを目指す初心者の皆さんへ、マイクロサービス環境における重要な概念であるレートリミットと、その実装が直面する課題について解説する。レートリミットとは、ウェブサービスやAPIが一定時間内に処理できるリクエストの数を制限する仕組みである。これは、大量のリクエストが集中してシステムが過負荷になるのを防いだり、悪意のある攻撃（DDoS攻撃など）からサービスを保護したりするために不可欠な機能である。

記事では、Istioというサービスメッシュ（複数のマイクロサービス間の通信を管理するためのインフラ）とKubernetes（コンテナ化されたアプリケーションを自動でデプロイ・管理するためのプラットフォーム）を組み合わせた環境で、レートリミットを導入した経験が語られている。理論上は、Istioの公式ドキュメントに従い、Envoyというプロキシ（Istioの主要コンポーネントの一つで、リクエストのルーティングやポリシー適用を行う）の参照レートリミットサービスをデプロイすれば良いように思えるが、実際には運用上の多くの課題に直面したという。

現代の多くの企業では、Internal Developer Platform（IDP）と呼ばれる、開発者がセルフサービスでアプリケーションをデプロイ・管理できるようにするための社内プラットフォームを導入している。これは、Helm（Kubernetesアプリケーションのパッケージ管理ツール）のようなツールだけでは、数百ものビジネスサービスにわたる標準化、ガバナンス（統制）、デプロイメントのワークフローを強制するには不十分であるためだ。このため、レートリミットは単独で存在する特殊なコンポーネントではなく、既存のIDPの自然な拡張として組み込む必要があった。

その実現のためには、開発者向け契約の拡張、製品チームへの分かりやすい抽象化の提供、そしてユーザーの意図とIstioサービスメッシュの基盤となる状態との整合性を取る作業が求められた。結果として、アーキテクチャはIDP、カスタムコントロールプレーン、そしてレートリミットサービス（RLS）の3層に分かれた。IDPのコマンドラインインターフェース（CLI）から、カスタムのCRD（Custom Resource Definition、Kubernetesの機能を拡張して独自のAPIオブジェクトを定義する仕組み）を使ってレートリミットの設定を送信する。この設定はカスタムコントロールプレーンによって処理され、それがレートリミットサービスに設定をプッシュする。アプリケーションのPod（Kubernetesで動く最小の実行単位）は、リクエストを処理する前にレートリミットサービスに制限チェックを問い合わせる仕組みである。

当初、予期し、準備を進めていた課題の一つに、「非同期コンパイルとヘルスステータス」の問題があった。Kubernetes上でカスタムコントロールプレーン（Operatorとも呼ばれ、カスタムリソースで定義された「望ましい状態」と実際のシステムの状態を同期させるプログラム）が、CRDを正常に適用したとしても、そのポリシーがすぐに有効になるとは限らない。Envoyのレートリミットサービスは、設定のスナップショットをコンパイルし、メモリにロードする必要がある。もしこのポリシーのコンパイルが失敗したり、RLSがスナップショットを拒否したりした場合、そのエラーがCRDのステータスに反映されるべきである。しかし、通常のデプロイメント中にステータスフィールドを細かく確認する人は少ない。

コントロールプレーンによる状態の同期（Reconciliation）は非同期で行われ、マニフェスト（設定ファイル）が適用されてから実際にポリシーが反映されるまでに数秒かかることがある。そのため、CI/CDパイプライン（ソフトウェア開発の自動化されたワークフロー）は、下流でポリシーが失敗しても成功したと報告してしまう可能性があった。幸いにも、Argo CD（Kubernetes向けの継続的デリバリーツール）はカスタムLuaヘルスチェックをサポートしている。Luaスクリプトを作成することで、Argo CDはサブリソース（CRDに関連する子リソース）のステータスを直接評価できるようになり、コントロールプレーンがコンパイルされたスナップショットを明示的に「正常」とマークするまで、アプリケーションを「進行中」または「劣化状態」に保つことができた。これにより、デプロイメントの成功をより正確に判断できるようになった。

一方で、もっと早く対処すべきだったと感じた課題もいくつかあった。一つは、「共通言語とプラットフォーム専門用語」の問題である。筆者は最近チームに加わったばかりで、社内での定着した専門用語の影響力を過小評価していた。多くの組織では、レガシーなアーキテクチャをKubernetesに移行する際に、古いドメイン（業務領域）の用語をそのまま引き継ぐことがある。その内部用語が技術的に適切であるかどうかに関わらず、すべてのチームがそれを使っている場合、それに逆らうのは困難である。筆者は当初、CRDの仕様やIDPの定義をシンプルな用語で設計したが、コントロールプレーンとワークロードが稼働し始めると、この用語の不一致が明らかになり、CLI（コマンドラインインターフェース）に変換レイヤーを追加したり、後から修正したりする羽目になった。早い段階で現地の慣習的な用語を採用していれば、その後の大規模な修正を避けることができたはずだと後悔している。

次に、「一時的な環境と不安定なリソース」の問題があった。当初、コントロールプレーンのOperatorは、サブ秒（1秒未満）での高速な状態同期を必要としないと仮定していた。Argo CDの同期からポリシーが反映されるまで0.5秒かかろうが5秒かかろうが、ほとんど差はないと感じていた。しかし、エッジケース（特殊な状況）が発生した。IDPチームが競合状態（複数の処理が同時にリソースにアクセスしようとして問題を起こす状況）を診断するために、プラットフォームに積極的に負荷テストをかけたときだ。急速に変化する動的な環境では、リソースは安定しているわけではない。例えば、レートリミットのCRDが適用されてから2秒後にアプリケーションのデプロイが削除されたり、テスト用の名前空間（Kubernetesでリソースを論理的に分離する単位）が次々と作成・変更・削除されたりする。Operatorは、状態同期のループ中にターゲットとなるワークロードが存在し続けると当初は想定していた。しかし、名前空間が状態同期中に突然消滅すると、予期しないNotFoundエラーが発生し、開発環境でアラートが上がった。Operatorは、このような積極的なリソースの生成・削除にも堅牢である必要があり、そうでなければ頻繁にアラートが発生してしまう。

最後に、「レイテンシーバジェット、コールドスタート、ノードエビクション」の問題である。Podのエビクション（リソース不足などによるPodの強制終了）、Karpenterのようなツールによるノードの統合（効率化のためのノード再配置）、スポットインスタンスの中断（一時的な安価なクラウドインスタンスが突然利用できなくなること）は、Kubernetesの標準的な動作である。レートリミットをトリッキーにしたのは、厳格なレイテンシーバジェット（許容される応答時間の制限）があったことである。 レートリミットのチェックは、リクエストパス（ユーザーからのリクエストがシステム内を流れる経路）に直接組み込まれているため、クライアント側のタイムアウトは非常に短く、多くの場合、わずか数ミリ秒に設定される。コールドスタート（新しいPodが起動した直後、リクエスト処理の準備が整うまでの時間）の間は、応答レイテンシーが一時的に急上昇する。この状況でのレートリミットの挙動は、設定によって異なる。 「Fail-open」（failure_mode_deny: false）の場合、一時的なシステム障害の際に、レート制限されていないトラフィックが一時的に通過してしまう可能性がある。 「Fail-close」（failure_mode_deny: true）の場合、システム障害時に、正当なリクエストでさえ500エラー（サーバー内部エラー）や429エラー（Too Many Requests）で失敗してしまう可能性がある。 トラフィックのごく一部（例えば0.0x%）がレート制限をバイパスしたり、リクエストがドロップしたりしても、主要なダッシュボードが真っ赤になるほどの重大な問題にはならないかもしれない。しかし、それは「気になる」程度の黄色の点滅を引き起こし、システムの信頼性を少しずつ損なっていく。これらの問題は、システムの設計と運用において、非常に重要な考慮事項である。