レジリエントなアーキテクチャでサービス停止を回避

Fastly はレジリエントなアーキテクチャの原則を採用し、パフォーマンスを損ねることなくサービス停止の回避、障害の深刻度の緩和、保証された可用性を満たすサービスの提供を実現しています。私たちは構造的に「単一障害点」のリスクを排除し、スケーラブルなソリューションの構築において、分散化とレジリエンスを常に優先しています。

Fastly のコントロールプレーンの信頼性と分散型アーキテクチャが、多くの方の関心を引いている Fastly の主な差別化機能であると最近知った際、私たちは意外に思いました。サービス障害のリスクが絶対に無いと言い切れるクラウドベンダーは存在しませんが、私たちは Fastly のネットワークやコントロールプレーン、データプレーンのレジリエンスと冗長性の強化を通じて、このようなリスクの緩和に継続的かつプロアクティブに取り組んでいます。この取り組みは、最悪のインシデント発生を事前に防ぎ、実際に起きても与える影響の深刻度を緩和することで、そのようなインシデントからネットワークを保護することを目指しています。 

「#HugOps</u>」の精神に基づき、最近サービスの停止を経験した業界の仲間たちに私たちは大いに共感します。これは、誰にとっても最悪の悪夢だからです。さらにここ最近、お客様からレジリエンスに対する Fastly の現在のアプローチについて尋ねられることが何度もあったため、このブログ記事ではこれをテーマに取り上げることにしました。

まず、Fastly のレジリエンスを高めるために私たちが下した決断と、その目的に向けて数年前に開始した取り組みについてご紹介します。ここでいう「レジリエンス」は、想定しない事態 (データセンターの完全な喪失など) からインターネットのサービス停止や高度な DDoS 攻撃といったより一般的なシナリオまで、あらゆることに対するレジリエンスを意味します。そのため、コントロールプレーンやデータプレーンに加えて、Fastly のネットワーク全体やトラフィック処理などにもレジリエンスを組み込む必要があります。このブログを読み終える頃には、Fastly がレジリエンスを体現している理由がお分かりいただけると思います。また、冗長性においても Fastly が圧倒的に優れている理由をご説明します。 

分散型ソリューションで単一障害点を削減

分散型システムの構築と単一障害点の削減は、私たちが Fastly プラットフォーム全体に適用している最も重要な原則のふたつです。 

3年ほど前、Fastly Reliability Task Force (RTF) と呼ばれる複数の部門からなる社内チームの主導の下、Fastly のアーキテクチャを継続的に評価し、強化するプロセスが正式に導入されました。RTF チームは定期的にミーティングを実施し、プラットフォームの存続にかかわるリスクの軽減を目的とするトリアージ、評価、優先順位付けなどについて話し合いを行っています。このフォーラムは、大きな改善の促進と、次に取り組む課題の継続的な計画に大きく貢献しています。このようなタスクフォースを設立するきっかけとなった要因のひとつに、「(当時の) Fastly がデータセンターの停電に十分に備えていない可能性がある」という認識があったことがあります。特定されたリスクに対処するため、私たちは社内全体に及ぶ、(真に) 大規模な取り組みに着手し、ふたつの理由から「Cloudvolution」というコードネームが付けられました。まず、Fastly のプラットフォーム全体を運用する方法に進化的な (evolutionary) 変化をもたらし、よりレジリエントなマルチクラウドかつマルチリージョンのアーキテクチャを実現したいと考えたためです。次に、これは社内専用のコードネームだったので、ダジャレっぽい愉快な名前を採用したかったのです。何もかもにアルファベットの略語を使用する必要はないと考えたわけです。

コントロールプレーンとデータプレーンのレジリエンス

「Cloudvolution」は、Fastly のコントロールプレーンとデータプレーンを強化し、コアプラットフォームのサービスの可用性を高めることで、プラットフォームのレジリエンスを向上させることを目的としていました。システム設計の抽象化を反復的に進化させてレジリエンスを高め、サービスの境界をより明確にし、顧客の成長がレベルアップした際に簡単にスケーリングできるよう備えることが、主な目標のひとつでした。基本的に、依存関係やリスク、障害の発生箇所を減らし、レジリエンスを高めたいと考えたのです。 

破壊的な障害が発生した際に信頼性の高いサービスを維持するには、アーキテクチャのこのようなアップグレードが重要な鍵を握ることを私たちは認識していました。現在、Fastly のコントロールプレーンとデータプレーンには、マルチクラウドおよびマルチリージョンが採用されています。私たちはこの課題に熱心に取り組み、Fastly が単一のデータセンターや単一の可用性ゾーン、単一のクラウドプロバイダーに依存することを避けました。Fastly のコントロールプレーンは2つの独立した、地理的に離れたリージョンで実行され、必要に応じてセカンダリリージョンへのウォームフェイルオーバーが可能です。同様に、Fastly のデータプレーン (Fastly の可観測性機能と分析機能のベース) も2つの独立したリージョンとウォームフェイルオーバーの機能を備えていますが、コントロールプレーンとは別のクラウドプロバイダーを使用しています。これにより、実質的に破壊的イベントの影響範囲が制限されるため、Fastly の観測機能 (データプレーン) とアクション機能 (コントロールプレーン) の両方が失われる状況が発生する可能性が大幅に削減されます。 

また Fastly のデータセンターは、送電網からバックアップの発電機を備えた無停電電源装置 (UPS) のバッテリーへのフェイルオーバーが可能ですが、チェックリストにこのような対策が含まれているだけでは十分とは言えません。Fastly の事業継続計画 (BCP: Business Continuity Plan) の一環として、アクティブなリージョンとスタンバイ用リージョン間でフェイルオーバーを実行し、地域のクラウドプロバイダーで停電が発生した際に、このようなフェイルオーバーの仕組みが機能することを継続的にテストしています。 

より優れたアーキテクチャに Fastly のコントロールプレーンとデータプレーンを移行させた後、Fastly のエンジニアリングチームがこのアーキテクチャを使用して構築しやすいようにする重要性を私たちは認識していました。これにより、Fastly が構築するものすべてに高いレジリエンスを確保できるためです。そこで、コントロールプレーンとデータプレーンを統合プラットフォームとして利用できるようにし、最小規模のテストやアルファ版のプロジェクトも含め、安全かつスケーラブルな上、デフォルトでレジリエントな新しいプロダクトや機能をエンジニアが実装できるようにしました。これにより、少人数のエンジニアリングチームが新たに何かを構築する際に、コアシステムの独自のバージョンを再作成する必要がなくなり、リスクのさらなる軽減につながります。その結果、誰もが最も安全かつレジリエントな方法で容易に構築できるようになりましたが、それだけではありません。

すでに最初の優先課題に対処し、コントロールプレーンとデータプレーンの次のイテレーションに取り組んでいる一方、RTF は引き続き改善の余地がある領域の特定に努めています。このような改善を完全に導入するには数年かかる可能性があるので、必要になる前に取り組みを開始することが大切です。来年にかけてコントロールプレーンのスティッキーなシステム抽象化をさらに切り離す計画をすでに進めており、これによってシステムのレジリエンスを強化できるだけでなく、プロダクト開発の加速も可能になります。

ネットワークのレジリエンス (コントロールプレーンを超えて)

低レイテンシと高い可用性を約束するグローバルエッジネットワークの運用において直面する課題は、プラットフォームのコントロールプレーンとデータプレーンに影響するデータセンターの障害だけではありません。Fastly のコントロールプレーンとデータプレーンを分散化させ、レジリエンスを確保している方法について詳しくご紹介したところで、今度は Fastly のエッジネットワークに単一障害点が存在せず、自動的かつインテリジェントに素早く問題に対処できる理由をご説明します。Fastly では、レジリエンスについて語る際、大抵の場合、Fastly のエッジネットワークとコンテンツ配信サービスのレジリエンスを指しているので、この点について見てみましょう。

トラフィックとネットワークの停止にレジリエントに対応

Fastly 規模のネットワークにとって、トラフィックの異常やレイテンシの問題、インターネットの停止は日常的な現実です。インターネットトランジットのプロバイダー全体で通常、短期間の一時的な接続低下やパフォーマンス低下が、1日につき数回から数百回、発生しています。このような事象は総称して「Internet weather」と呼ばれ、大規模なインターネットの停止は世界的なニュースとして注目を浴びることもあります。ほとんどの場合、(比較的には) すぐに回復する小さなイベントですが、たとえインターネット環境の「小さな」イベントでも、それによって生じるレイテンシやパフォーマンスの低下によって、深刻な影響がもたらされる可能性があります。 

現在、BGP (Border Gateway Protocol) によるルーティングの変更などの手法が業界のベストプラクティスとして採用されていますが、BGP ではアプリケーションレベルの障害を検出することができないため、問題の解決に長時間 (数時間) かかることもあります。BGP の外側にあるモニタリングシステムや可観測性システムが問題を検出し、問題のあるルートを推測してソリューションを計画し、ネットワークトポロジーを変更して障害のあるルートを回避するよう BGP を通じて指示する必要があります。このような指示が出されると BGP によって問題を素早く修正できますが、それまでの工程に数分から数時間かかる可能性があるのです。つまり、ネットワークで比較的小規模な中断や停止が発生した際に細かい変更を行うのに BGP はあまり効果的ではありません。ほとんどの場合、このような問題は BGP による変更が効果を発揮する前にすでに解消されていることが多いのです。ネットワークが停止している1秒1秒にその影響を実際に受けているサイトやアプリケーションの状況改善のために BGP によって何らかの動作が行われることはなく、サイトやアプリケーションはネットワークが復活するのを待つしかないのです。

私たちがグローバルネットワーク全体をコントロールしていないのは事実ですが、それを口実に、お客様によりレジリエントで優れたサービスを提供する方法を模索する努力を怠るようなことは、Fastly ではあり得ません。以下では、お客様やエンドユーザーに最速かつ最も信頼性の高いエクスペリエンスを提供するために私たちが取り組んでいるイノベーションの一部をご紹介します。エッジネットワークの運用におけるこのような進歩は、Fastly の先進的なネットワークアーキテクチャと、真の意味でソフトウェア定義型のネットワークを構築している事実があってこそ可能なのです。Fastly ネットワークでは、あらゆるレイヤーでロジックを適用できる上、プログラムによるスケーリングとネットワークフローの調整を自在に行い、インターネット環境の問題を回避しながらアップタイムと信頼性を確保できます。

Fastly のシステム全体を通じて次の共通点があることにご留意ください。1) Fastly のシステムは自動化され、自己修正機能を備えており、人間による介入を待つことなく素早く問題に対応できます。2) Fastly の POP フリート全体を通じてシステムがプロビジョニングされています。

インターネット接続の問題を解決するために依存関係を排除する

私たちは問題解決に取り組むのが好きですが、インターネット接続の問題において最も困るのが、問題を引き起こしている実際の原因が私たちのコントロール範囲外にあるために修正できないことです。別の誰かが所有または管理するグローバルなインターネットインフラの一部で問題が発生している場合、イベントの性質にかかわらず、私たちのコントロール範囲外で起きていることになります。しかし、私たちがコントロールできることがあるのも事実です。そこで私たちは、インターネット環境が荒れている場合にその場所を回避してサービスを向上させる方法を、いくつか開発しました。そのひとつが「Fast Path Failover</u>」と呼ばれるテクノロジーです。 

Fast Path Failover によって、トランスポートレイヤーでパフォーマンスの低いエッジ接続を自動的に検出し、回避することができます。これにより、Fastly の POP の外で発生しているインターネット接続の問題による影響を緩和することが可能になります。インターネット接続の問題の多くは完全な停止ではなく、ほとんどの場合がレイテンシの増大などの問題です。つまり、厳密にはネットワークのリンクは接続された状態に維持されているものの、パフォーマンスが著しく低下し、問題をもたらしているのです。このような問題を緩和する標準的なアプローチは、BGP を使用して障害のあるインターネットのパスを避けるようトラフィックをルーティングすることです。この手法は、完全にインターネットが停止している場合にはある程度役に立ちますが、劣化した接続に対するソリューションとしては、まったくお勧めできません。undefined 

パス上のリンクが使用できなくなった場合、BGP はそのリンクを含むルートを撤回し、利用可能な代替パスが存在する場合は、ISP をトリガーして、トラフィックを再ルーティングして問題を回避します。こにより、ISP はトラフィックを再ルーティングして問題を回避します。しかし、パスが著しく劣化しているものの、完全に接続が切断されていない状況では、BGP によるルートの撤回がまったくトリガーされない可能性があります。そのため、場合によってはサービスプロバイダーが問題を検出し、手動でトラフィックを再ルーティングして問題を解決しなければならず、プロバイダーによって、このプロセスに数分から数時間かかることがあります。 

一方 Fast Path Failover は、BGP が Fastly のお客様のために問題を修正してくれるのを待ちません。何らかの問題が発生している場合、すぐに問題を顕在化させ、迅速に再ルーティングして素早く復活させるのが私たちのアプローチです。BGP 経由でネットワーク全体の解決策が施行されるのを待つことなく、Fast Path Failover によってパフォーマンスの悪いエッジ接続を自動的に検出して再ルーティングできます。ピアやトランジットプロバイダーから、パスに障害が発生しているという報告を受けるのを待つまでもなく、私たち自身でそれを確認できるのです。したがって、それらのルーティングソリューションを待つことなく自分たちで異なるルートを試せます。Fastly のエッジクラウドサーバーは、接続における通信の進行状況を判断してインターネットパスの健全性を推測し、必要に応じて迅速に代わりのパスを選択できます。 

分散アーキテクチャのもうひとつのメリットは、POP 全体のルーティング決定のボトルネックとなる一元化されたハードウェアルーターに依存していないため、ルーティングのさらなる高速化を実現できることにあります。分散された方法で接続ごとにルーティング決定を行うことで、Fastly のエッジサーバーは素早く問題に対応することができます。これにより、良好な状態の接続に影響することなく、劣化している接続のみを再ルーティングする、正確なフェイルオーバーの決定が可能になります。このメカニズムは、標準的なネットワーク監視テクノロジーでは一般的に正確な検出や緩和が困難な、非常に小規模で短期間のインターネット接続の問題を特定して緩和するのに非常に効果的です。Fast Path Failover について詳しくはこちら</u>をご覧ください。

さらに、インターネット接続の問題がネットワークトポロジーの中心に近い所にある場合、トラフィックが障害のあるルートを回避するのに利用できる代替パスが存在しない可能性があります。実行可能な代替手段を持たない他のベンダーだったら、このような問題に対してなす術が無いかもしれませんが、私たちは諦めません。Fastly では、トランジットやピアリングの接続が大規模に多様化されているので、エンドユーザーに配信しようとする際にネットワークのボトルネックのせいでサービスが中断されるリスクを大幅に軽減できます。

自動化されたスマートなトラフィックルーティング 

Fast Path Failover によって、Fastly のエッジクラウドプラットフォームからのコンテンツリクエストが、Fastly のコントロールが及ばないインターネットの部分を通過する際の接続性を向上させることができます。さらに私たちは、Precision Path と Autopilot の機能を追加し、Fastly がコントロールできるネットワーク部分のパフォーマンスを強化しています。  

Precision Path</u> は、お客様のオリジンサーバーと Fastly ネットワーク間のインターネットパス全体のパフォーマンス向上に役立ちます。一方 Autopilot</u> は、自動化されたエグレス・トラフィック・エンジニアリングのソリューションです。このふたつを組み合わせることで、優れたメリットが得られます。人間が状況を分析してプランを決定するのを待つことなく、すぐに問題に対応できます。問題が広がり、ネットワーク上での影響が拡大するのを防ぐ上で、迅速な対処は非常に重要です。

Precision Path

Precision Path は、世界中に配置されている各 Fastly POP におけるオリジンへの接続を、すべて継続的にモニタリングしています。(インターネット接続の問題などにより) パフォーマンスの低いオリジンへの接続を検出した場合、影響を受けるオリジンへのすべての代替パスを自動識別し、リアルタイムで最適な代替パスに再ルーティングします。Fastly では多くの場合、500番台のエラーがエンドユーザーに配信される前に良好なオリジンへの接続を再確立できます。非常に迅速かつ効率的にネットワーク問題を修正できるので、ほぼ問題が存在しなかったようなものです。また、Fastly のリアルタイムログストリーミング</u>機能によっても、Fastly サービスで発生する可能性があるオリジン接続の再ルーティングイベントをモニタリングできます。 

さらに、Fastly のエッジクラウドプラットフォームからエンドユーザーにコンテンツを確実に届けることも、 Precision Path の重要な役割のひとつです。コンテンツを配信する際、Fastly はすべての TCP 接続の健全性をトラックします。接続に影響を及ぼす劣化 (輻輳など) が観測された場合、Fastly は Fast Path Failover によって自動的に配信経路を新しいネットワークパスに切り替え、問題を回避します。この自動対策は、デフォルトですべての Fastly POP で有効になっているので、Fastly の全トラフックに適用されます。そのための追加設定は不要です。

Autopilot

Autopilot は、前回のスーパーボウル配信中、人間の介入一切なしで 81.9 Tbps という記録的な量のトラフィックの配信を成功</u>させた立役者です。トラフィックが多く、影響の大きいこのイベント全体を通じて、手動による介入は不要でした。2023年2月以降、トラフィック量がスーパーボウルのレベルを超え、記録が更新されたことが何度もありました。つまり、スーパーボウルレベルのトラフィックが発生する可能性が、いつでもあるということです。スケーリングできる機能が役に立つのは年に1回だけではありません。この機能は1年を通じて日々活躍し、トラフィックの最適化と Fastly の効率の最大化に大きく貢献しています。

Fast Path Failover と同様に、Autopilot も BGP の欠点を補うために構築された機能です。BGP には「キャパシティを認識できない」という問題があります。BGP は、インターネット上の宛先に到達できるか否かを伝えることしかできません。「必要な量のトラフィックを配信するのに十分な容量があるか」、「その配信のスループットやレイテンシはどれくらいか」といったことは教えてくれません。例えるなら、配達業者が「配達できる」と言って荷物を受理した後で、荷物が車に入らなかったことが判明するようなものです。

Autopilot はリンクの残りの容量とネットワークパスのパフォーマンスを継続的に推定し、このような問題に対処します。ネットワーク測定機能を通じて毎分収集されるこれらの情報を利用してトラフィックの割り当てを最適化することで、リンクの輻輳を回避することが可能になります。Precision Path は超高速に動作しますが、パフォーマンスの悪い接続からトラフィックを遠ざけることが主な目的で、パスの決定を行う際に新しい接続に関してあまり把握していません。Autopilot では、Precision Path に比べて反応時間が若干遅くなるものの、数分間分の高分解能のネットワークテレメトリデータを使用し、より多くの情報が考慮された決定が行われます。(Precision Path のように) 単に障害のあるパスからトラフィックを遠ざけるのではなく、より大量のトラフィックをネットワークのより最適な部分に「誘導する」のです。 

そして、Precision Path と Autopilot を連携させることで、問題に直面しているフローを正常に機能しているパスに迅速に再ルーティングしながら、安全な判断に必要なデータに基づいて、定期的に全体的なルーティング設定を調整することが可能になります。両システムは24時間365日稼働しており、間近のスーパーボウルは、これらの有効性が実証された好例と言えます。それぞれ 300 Gbps と 9 Tbps のトラフィックを再ルーティングしていました。これらのトラフィックは両システムがなければ、障害がある、輻輳が発生している、またはパフォーマンスが低下しているパスを経由して配信され、Fastly ネットワークの処理能力を低下させていたでしょう。このような自己管理機能によって、Fastly ネットワーク上で起こり得る障害や輻輳、パフォーマンス低下の問題を高頻度で確認し、素早く対応できるのです。

Autopilot は Fastly に多くのメリットをもたらしますが、ネットワークプロバイダーの障害や DDoS 攻撃、予想外のトラフィックスパイクなどのイベントへの対応能力が向上したことで、お客様にもより安心していただけるようになりました。もちろん、エンドユーザーへのシームレスなエクスペリエンスが損なわれることはありません。Autopilot と Precision Path について詳しくはこちら</u>をご覧ください。 

大規模な DDoS 攻撃も自動保護機能でブロック

すべてのネットワーク問題が意図的でないとは限りません。ネットワークレジリエンスにおいて重要な一端を担うのは、最近話題になった Rapid Reset</u> 攻撃のような大規模な分散型サービス妨害 (DDoS) のイベントに対するネットワークの耐久性です。この攻撃は今でもインターネット上で問題を起こしていますが、Fastly は被害を受けませんでした。「Attribute Unmasking」と呼ばれる手法を使用する自動化されたシステムで、攻撃の特定と緩和をすぐに開始できたのがその理由です。

Attribute Unmasking

DDoS 攻撃は年々威力を増し、より迅速にスケールアップするようになりました。数秒の間に0 RPS (1秒当たりのリクエスト数) から100万 RPS、あるいは数億 RPS へと急増することも珍しくなく、またすぐに攻撃が終了することもあります (1分以内に終了するケースもあります)。HTTP/2 プロトコルの、これまで悪用されたことがなかった性質を利用した前述の Rapid Reset</u> 攻撃にも見られるように、DDoS 攻撃が巧妙化していることも事実です。 

Rapid Reset の影響を受けた大規模なプラットフォームのほとんどが、この新手の攻撃によって大きな被害を被りました。しかし Fastly は Rapid Reset 攻撃を受けた際、Attribute Unmasking 機能のおかげで迅速かつ自動的にネットワークトラフィックから正確にフィンガープリントを抽出できました。Attribute Unmasking は、他の複雑な攻撃に対しても同じように機能します。ネットワークを通過する各リクエストには、レイヤー3やレイヤー4のヘッダー、TLS 情報、レイヤー7の詳細など、トラフィックを特徴づけるのに使用できる多くの特性があります。Fastly のシステムは、Fastly ネットワーク上で受信したリクエストからメタ―データを取り込み、それに基づいて正常なトラフィックと悪意のあるトラフィックを識別します。これにより、攻撃トラフィックをブロックしながら正常なトラフィックを通過させることができるのです。

高速なレスポンスを確保するため、DDoS 対策が Fastly ネットワークのエッジで実行されます。スタックを処理するネットワークアプリケーションレイヤーとカーネルに検出機能と防御機能がビルトインされているのです。これも (Fast Path Failover と並び)、完全にソフトウェア定義型の Fastly ネットワークだからこそ可能な分散型ソリューションの一例です。Fastly ではサーバー全体でより分散された方法で並行して関数を実行できます。さらに Fastly のシステムはモジュール型なので、新種の攻撃が発見されても、それに対処するのに新しいメカニズムを一から開発する必要がなく、検出機能と防御機能を素早く強化することが可能です。Rapid Reset のような攻撃を受けた場合、いくつかの関数を検出とレスポンスのモジュールに追加するだけで、新種の攻撃にも驚くほど短時間で対処できます。Attribute Unmasking と Rapid Reset 攻撃について詳しくはこちら</u>をご覧ください。

レジリエンスは継続的な取り組みの産物

このブログ記事では多岐に渡り細かくご説明しましたが、以下に要点をまとめました。 

1. 実際に問題が発生する前に、起こり得る問題について考える努力を優先します。

2. 多くのリソースを割り当て、アーキテクチャの改善に取り組みます。

3. 継続的に単一障害点のリスクを特定し、排除します。

4. Fastly のコントロール範囲外で発生する問題に備え、ソリューションのイノベーションに取り組みます。

5. これらの取り組みを継続的に行うことが重要であると私たちは考えます。常に明日の未来に備える努力に励み、「他に何かできることはないか」と自分たちに問いかけます。 

私たちの取り組みやイノベーションによる効果によって Fastly のお客様にもたらされるパフォーマンスやセキュリティ上のメリットに興味がおありの場合は、ぜひ Fastly の無料アカウント</u>をお試しいただくか、またはお問い合わせ</u>ください。