Oktaは、お客様のニーズを満たすため、クラウドインフラストラクチャの進化を常に推進しています。毎月数十億の認証を処理するサービスに関しては、設計上の意思決定の中核として信頼性と拡張性を重視しています。最近のプロジェクトで、Oktaは最もトラフィックの多いサービスの1つを削除することに取り組み、これが運用と信頼性の大幅な改善につながりました。その詳細をご紹介します。
Oktaのエッジの概要
以前のエッジでは、OktaのWorkforce Identity Cloudに向かう顧客トラフィックの大部分を処理するため、要求の集中を防ぐアプリケーションロードバランサー、SSL終端を行うApacheベースのサービス、そしてルーティングやビジネスロジックを担うNginxベースのサービスという3つの主要サービスが機能していました。
サービスはグローバルにデプロイされ、Oktaが毎日処理する大量のトラフィックに対応できる拡張性を提供します。しかし、高いパフォーマンスを発揮しているものの、密接な結合が徐々に運用上の課題となってきました。そこで、常にインフラストラクチャの改善を目指して、部門横断的なチームがこれらのサービスの再評価に着手しました。
サービスの見直し
Oktaのお客様はパフォーマンスが高く可用性の高いサービスを期待しており、その期待に応えることが不可欠です。日常的に数多くのログインフローを処理する中で、パブリックインターネット上では予期しない事態も発生します。顧客によるものかその他の要因かを問わず、Oktaは短期間に大量のトラフィックを受け取ることがあります。
運用しているサービスを詳細に検討した結果、Apacheのスレッドごとのボトルネックが、影響を与えることなく大量のトラフィック流入を処理する能力を制限していると判断し、このサービスをエッジから完全に削除することにしました。これにより、予測不可能なトラフィックパターンをより適切に処理する手段として、Nginxのイベント駆動型アーキテクチャがスタック内で進歩します。
信頼性の向上が動機となっているとはいえ、数百台のApacheサーバーを終了させることができれば、運用上の労力が大幅に削減されます。サービスの信頼性向上、集約するシステムログの削減、運用上の負担排除、コスト削減など、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%3Flimit=1 へのリクエストはデコードされ、Nginxに /api/v1/users?limit=1として渡されていました。リクエストパスにApacheがない場合、Nginxはエンコードされたクエリ文字列を処理できず、リクエストを送信したクライアントにエラーを返していました。これに対処するため、Nginxの設定に書き換えルールを追加し、ロールアウトを継続することができました。
数回のイテレーションの後...
このように重要なサービスの削除は、決して簡単ではありませんでしたが、結果としてお客様への持続的な影響を与えることなく達成されました。この取り組みでは、複数回のイテレーションが行われましたが、以下の成果を達成するという目標は一貫して揺らぐことがありませんでした。
- パフォーマンスのボトルネックを解消する
- サービスの信頼性を向上させる
- 運用上の労力を削減する
すべての環境でこの取り組みを完了すると、すぐにメリットが明らかになりました。チームは、すでに次の改善の取り組みに向けて計画しています。
このブログ記事についてご質問がありますか？eng_blogs@okta.comまでご連絡ください。
Oktaの洞察力に富んだエンジニアリングブログで、知識をさらに深めてください。
Oktaの情熱的で優秀なエンジニアチームで働きませんか？採用情報ページをご覧ください。
Oktaは、最新かつ高度なアイデンティティ管理の可能性を解き放ちます。詳細は、セールス担当者にお問い合わせください。
