Oktaのエッジインフラストラクチャの進化
Oktaは、お客様のニーズを満たすため、クラウドインフラストラクチャを常に進化させています。毎月数十億件の認証を処理するサービスに関しては、設計上の意思決定の中核として信頼性と拡張性を重視しています。本記事では、最もトラフィック量の多いサービスの1つを削除した最近のプロジェクトが、運用と信頼性の大幅な改善につながった経緯について詳しく説明します。
Oktaのエッジの概要
以前のエッジでは、OktaのWorkforce Identity Cloudへの顧客トラフィックの大部分を処理するため、リクエストの集中を防ぐアプリケーションロードバランサー、SSL終端を行うApacheベースのサービス、ルーティングやビジネスロジックを担うNginxベースのサービスという3つの主要サービスが機能していました。
これらのサービスはグローバルで展開されており、Oktaが日々処理する大量のトラフィックに対応できるように拡張されています。しかし、高いパフォーマンスを発揮しているものの、密接な結合が徐々に運用上の課題となってきました。そこで、常にインフラストラクチャの改善を目指している当社では、部門横断的なチームを結成し、これらのサービスの再評価に着手しました。
サービスの見直し
Oktaのお客様はパフォーマンスが高く可用性の高いサービスを期待しており、その期待に応えることが不可欠です。日常的に数多くのログインフローを処理する中で、パブリックインターネット上では予期しない事態も発生します。お客様によるものかどうかに関わらず、Oktaは短期間に大量のトラフィックを処理しなければならないことがあります。
運用中のサービスを詳細に検討した結果、Apacheのスレッドごとのボトルネックが、大量のトラフィックを影響なく処理する当社の能力を制限していることが判明しました。このため、このサービスをエッジから完全に削除することにしました。これによって、Nginxのイベント駆動型アーキテクチャをスタックの前面に移行させ、予測できないトラフィックパターンをより効果的に処理できるようになります。
信頼性の向上が動機となっているとはいえ、数百台のApacheサーバーを終了させることができれば、運用上の労力が大幅に削減されます。サービスの信頼性向上、集約するSystem Logの削減、運用上の負担排除、コスト削減など、Apacheサービスを廃止することで大きなメリットを得ることができます。
当社のチームは、トラフィックをApacheサービスから直接Nginxに移行するための堅牢で綿密に設計された手順を開発し、テスト環境で明らかになった問題を迅速に反復処理してから、この変更をグローバルな本番環境に徐々に適用できるようにしました。
テストでは..
OktaのApacheサービスは、軽量なJavaアプリケーションをカスタム構成で実行し、受信リクエストを処理してからNginxサービスに渡します。Apacheを削除する際には、このサービスが提供するすべての機能が確実にNginx内で再現されるようにする必要がありました。当社のチームは総合テストを通じて、Apacheサービスの削除によって適切に処理されなくなった複数の受信リクエストのパターンを迅速に特定しました。
「ダブルスラッシュ」の問題
顧客トラフィックを最初に受け取るアプリケーションとして機能していたApacheには、不正なリクエストを識別し適切に対応するためのロジックが長年にわたって組み込まれてきました。しかし、Oktaのエッジインフラストラクチャが成熟するにつれて、この機能がスタックのより早い段階に移行してきました。それでも、Apacheを削除することによって、//を含むリクエストを適切に処理できなくなるという問題があることがすぐに明らかになりました。
Apacheサービスを排除したテスト環境では、//を含むすべてのリクエストに対してNginxが不適切なステータスコードを返していました。例として、/api/v1/usersへのAPIコールは期待どおりに動作し続けた一方で、//api/v1/usersに対するコールはクライアントエラーのHTTPレスポンスを返すことが確認されました。
Apacheサービスはこれらのリクエストを単純な書き換えルールで処理していましたが、Nginxは書き換えなしのリクエストに対してエラーコードを返すため、この機能を復元するために新しい書き換えルールを導入する必要がありました。
RFC 3986に従った結果として、予期していなかった利用方法や挙動が問題として浮上する状況（「ハイラムの法則」と呼ばれます）を初めて経験したのです。
「クエリ文字列」の問題
「ダブルスラッシュ」問題の解決策を検証するための総合的なテストを完了し、Apacheサービスの段階的な削除をステージング環境で開始しました。Apacheを使用せずに処理されるトラフィックが徐々に増加するにつれて、Apacheによって以前は問題なく処理されていた特定のリクエストに対して、Nginxが不適切な応答コードを返すことが再び観察されました。
以前と同様に、Apacheが不正なリクエストを書き換えて、Nginxが処理できる形式にしていたケースが発見されました。RFC 1738に反して、Apacheはエンコードされたクエリ文字列をデコードした値に書き換えていました。例えば、/api/v1/users{3}limit=1へのリクエストがデコードされ、Nginxには /api/v1/users?limit=1として渡されていました。リクエストパスにApacheが介在しない場合、Nginxはエンコードされたクエリ文字列を処理できず、リクエスト元のクライアントにエラーを返します。 これに対処するため、Nginxの構成に書き換えルールを追加して、展開を継続できました。
数回のイテレーションの後...
このように重要なサービスの削除は、決して簡単ではありませんでしたが、結果としてお客様への持続的な影響を与えることなく達成することができました。この取り組みでは、複数回のイテレーションが行われましたが、以下の成果を達成するという目標は一貫して揺らぐことがありませんでした。
- パフォーマンスのボトルネックを解消する
- サービスの信頼性を向上させる
- 運用上の労力を削減する
すべての環境でこの取り組みを完了すると、すぐにメリットが明らかになりました。チームは、すでに次の改善の取り組みに向けて計画しています。
以上の内容は、原文（英語）の参考和訳であり、原文と内容に差異がある場合は、原文が優先されます。