今日、FluxNinja はステルス モードから抜け出し、最新の Web アプリケーション向けの最初のオープン ソース フロー制御および信頼性管理プラットフォームである Aperture を発表しました。
競争優位性としての信頼性
過去10年間、クラウドコンピューティング・プラットフォームはオンラインビジネスの大規模な展開を可能にし、実店舗を持つ企業もオンラインビジネスを展開する力を与えてきました。しかし、これらのアプリケーションの信頼性を維持することは、かつてないほど困難になっています。例えば、ブラックフライデーにeコマース大手のトラフィックが急増すると、エンドユーザーが画面に何も表示されない、アプリがクラッシュするといった障害が発生する可能性があります。こうした事態は顧客の信頼を失い、収益目標の達成に至らず、社内のDevOpsチームやSREチームにも大きな負担となります。
LinkedIn ( Hodor )、Google ( Handling Overload )、Netflix ( Prioritized Load Shedding )、Stripe ( API Scaling ) といった企業は、最先端のフロー制御技術によってアプリケーションの信頼性を競争優位性へと高めています。フロー制御は基本的に、アプリケーション障害が発生した場合でも、重要なユーザーエクスペリエンスの経路を維持する、つまりグレースフルデグラデーションを可能にします。
フロー制御によるグレースフルデグラデーション
現代のウェブスケールアプリは、アカウント管理、検索、決済などの機能を実装する相互接続されたマイクロサービスの複雑なネットワークです。この分離アーキテクチャには利点もありますが、新たな複雑な障害モードも生じます。トラフィックが急増すると、重要なサービスでキューが蓄積され、正のフィードバックループが発生し、連鎖的な障害が発生する可能性があります。アプリケーションはタイムリーなレスポンスを提供できなくなり、エンドユーザーの重要なトランザクションが中断されます。
アプリケーションはリトルの法則に支配されています。これは、システム内の同時リクエスト数、リクエストの到着率、および応答時間の関係を記述したものです。アプリケーションの安定性を維持するには、システム内の同時リクエスト数を制限する必要があります。レート制限や自動スケーリングといった間接的なアプリケーション安定化手法は、優れたユーザーエクスペリエンスやビジネス成果を実現するには不十分です。個々のユーザーに対するレート制限だけでは、サービスの保護には不十分です。自動スケーリングは応答が遅く、コストがかかりすぎる可能性があります。サービス数が増加するにつれて、これらの手法の導入は困難になります。
ここでフロー制御が役立ちます。Aperture でフロー制御技術を使用すると、重要度の高い機能を他の機能よりも優先させることで、アプリケーションをリアルタイムで適切にデグレードできます。
LinkedIn、Google、Netflix、Stripeなどのチームが使用しているフロー制御技術は、長年の開発期間を経ています。しかし、ほとんどの企業にはこれらの技術を社内で構築する余裕はありません。だからこそ、私たちはApertureをオープンソースプロジェクトとしてリリースできることを大変嬉しく思っています。Kubernetesがクラウドインフラストラクチャの導入を民主化したように、効果的なフロー制御を備えた信頼性の高いアプリケーションの構築を民主化したいと考えています。
Apertureの仕組み
基本的なレベルでは、Aperture はエージェントとコントローラーによって監視、分析、および作動を通じてフロー制御を可能にします。
アパーチャーエージェント
Aperture Agentは、サービスインスタンスのサイドカーとして機能し、優先度付けされた負荷制限のための重み付け公平キューイングスケジューラや、不正使用防止のための分散レートリミッタといった強力なフロー制御コンポーネントを提供します。フローは、Aperture Agentの観点から見た基本的な作業単位です。これは、API呼び出し、機能、さらにはデータベースクエリなどにも当てはまります。
サービスのグレースフルデグラデーションは、重要なアプリケーション機能をバックグラウンドワークロードよりも優先することで実現されます。飛行機に搭乗する際、ビジネスクラスの乗客は他の乗客よりも優先されますが、すべてのアプリケーションにはそれぞれ異なる優先度のワークロードがあります。ビデオストリーミングサービスでは、顧客からの映画再生リクエストを、社内の機械学習ワークロードの実行よりも優先度が高いと見なす場合があります。SaaS製品では、有料ユーザーが使用する機能を無料ユーザーが使用する機能よりも優先する場合があります。Aperture Agentsは、ワークロードの優先度に基づいてスケジュールを設定することで、過負荷状態においてもユーザーエクスペリエンスや収益を最大化します。
Apertureエージェントは、内蔵のテレメトリシステムと、顧客層やリクエストタイプなどの属性に基づいてリクエストにラベルを付ける、プログラム可能な高忠実度フロー分類器を使用して、ゴールデンシグナルを監視します。これらのメトリクスはコントローラによって分析されます。
絞りコントローラー
コントローラーは、常時稼働のデータフロー駆動型ポリシーによって動作し、サービスレベル目標（SLO）からの逸脱を継続的に追跡し、回復またはエスカレーションのアクションを計算します。コントローラーで実行されるポリシーは、ゲーム「Factorio」の回路ネットワークに似た回路として表現されます。
例えば、勾配制御回路コンポーネントは、応答時間が悪化した際にサービスの同時実行性を制限するAIMD （Additive Increase, Multiplicative Decrease）スタイルの対策を実装するために使用できます。PIDなどの高度な制御コンポーネントを使用することで、同時実行性制限をさらに調整できます。
Aperture のコントローラーは、航空機の自動操縦装置や一部の自動車のアダプティブ クルーズ コントロールと同等の機能を備えています。
Apertureの導入
Aperture は、サービス メッシュまたは SDK を使用してサービス インスタンスに挿入できます。
- サービス メッシュ: Aperture は、 Envoyを使用することで、アプリケーション コードを変更することなく導入できます。制御のために Envoy の外部認証 APIを利用し、テレメトリのためにアクセス ログを収集します。リクエストごとに、Envoy はフロー制御の決定のためにリクエスト属性を Aperture Agent に送信します。Aperture Agent 内では、リクエストは分類子、レート制限子、スケジューラを通過し、その後、リクエストを受け入れるかドロップするかの決定が Envoy に送り返されます。Aperture は、フロー分類ラベルをリクエストに挿入する際にOpenTelemetryトレース プロトコルに参加し、 Jaegerなどのトレース ツールで可視化できるようにします。
- Aperture SDK：サービスメッシュの挿入に加え、Apertureは開発者がサービスコード内で機能レベルできめ細かなフロー制御を実現するためのSDKを提供します。例えば、eコマースアプリでは、アプリケーションが過負荷状態にある場合、チェックアウトフローでユーザーを新規セッションよりも優先させることができます。Apertureコントローラは、基本的なロードシェディングが数分間トリガーされた際に、エスカレートされたリカバリアクションとして機能のパフォーマンスを低下させるようにプログラムできます。
すべてをまとめる
FluxNinjaのチームは、DevOpsチームとSREチームの苦境や、彼らが直面する運用上の課題を熟知しています。私たちは以前、マイクロサービス監視におけるネットワーク中心のアプローチの先駆者であるNetsil（Nutanixが買収）を開発しました。Apertureは、大規模Webアプリケーションの現場で長年直接運用してきた経験から得られた技術的洞察と顧客の視点から生まれたものです。
オペレーターや愛好家の皆様には、ぜひApertureを試用していただき、開発者コミュニティに参加していただきたいと思います。
信頼性は大きな競争上の優位性となる可能性があり、FluxNinja では、Web スケールでの信頼性への道は効果的なフロー制御の実装から始まると考えています。
