クラウドが停止したとき：重要なサービスにおいてインフラを所有することがなぜ重要なのか 

2025年6月12日、Google Cloud Platform（GCP）の世界規模の障害が発生し、重要なインフラが停止しました。その影響は即座に広がり、GCPに依存するPalo Alto NetworksやCloudflareのサービスも数時間にわたる障害を経験しました。これらのサービスに依存する企業は、視界を失い、無防備な状態に置かれたのです。 
 
これは初めてのことではなく、無論、これが最後でもないでしょう。しかし、これは警鐘となりました。 
 
SASE、SSE、SD-WANプラットフォームが停止すれば、ビジネスも停止します。生産性は止まり、セキュリティの隙間が生まれ、リスクが急増します。このように重要なサービスにおいて、高可用性は「あれば良い」というものではなく、「絶対条件」です。そして、それはアーキテクチャの所有、つまり自社でコントロールできるインフラを構築することから始まります。 

クラウド冗長性の幻想 

GCP、AWS、Azureといったハイパースケーラーは、スケールやグローバル展開に優れていますが、リアルタイム性能や「5ナイン（99.999%）の稼働率」を求められるネットワーク・セキュリティサービス用に設計されたわけではありません。それらは汎用クラウドであり、アプリを実行するために構築されたもので、企業のネットワークやセキュリティの重要インフラを担うためのものではないのです。 
 
これらのハイパースケーラー上にサービスを構築するベンダーは、その脆弱性を受け継ぎます。GCPが躓けば、その上にあるものもすべて躓くのです。単一クラウド内の冗長性では、6月12日に起きたようなシステム障害からは守れません。マルチクラウドの回復力ですって？いえいえ、それは基盤から設計・テストされていなければ、後付けでは機能しません。 

重要インフラには異なるクラウドが必要 

Cato SASE Cloud Platformは、設計段階から他とは異なります。私たちは、世界各地のトップクラスのデータセンターにあるCato所有のベアメタルインフラ上に、85以上のPoPを持つ独自のグローバルバックボーンを構築しました。私たちは回復力を「借りる」のではなく、「設計する」のです。各PoPは完全冗長のスタックを備え、Single Pass Cloud Engine（SPACE）がすべてのトラフィックを検査し、ポリシーを適用します。SPACEやコンピュートノード、PoPが障害を起こした場合でも、トラフィックは自動で切り替わり、介入やサービス停止は不要です。 
 
これは机上の理論ではなく、既に何度も実証されています： 
– 光ファイバー切断で大手キャリアに障害が発生した際も、ユーザーは気づきませんでした。バックボーンが即座にトラフィックを迂回させたからです 
– 英国のデータセンターが停止したときも、Catoはゼロダウンタイムで迂回しました。 
– スペインとポルトガルで停電が発生した際も、Catoの顧客は接続と保護を維持できました。 
 
これらは偶然ではなく、意図的な設計の成果なのです。 

ハードを所有するだけではなく、そのアーキテクチャこそが重要 

回復力は、ハードウェアを追加するだけで達成できるものではありません。コンピューティング、接続、検査、制御といった全ての領域で、単一障害点を排除することが鍵です。 
 
Catoのアーキテクチャでは、数千のSPACEが並列にトラフィック検査を分散処理します。各SPACEは、ラインレートで暗号化トラフィックを処理し、完全なセキュリティスタックを適用できます。1つが故障すれば、トラフィックは次のSPACEに移ります。PoPが故障すれば、トンネルは自動で最も近い正常なPoPに切り替わります。再設定もDNS伝播の待機も、フェイルオーバースクリプトも必要ありません。 
 
一方、アプライアンス型やクラウドホスト型のアーキテクチャでは、ファイアウォールやSD-WANエッジ、検査ポイントが特定のインスタンスに縛られており、フェイルオーバーには事前準備やテスト、手動介入が必要になります。それも多くの場合、危機の真っ最中にです。 

サービス稼働率はデータプレーンの所有から始まる 

SASEのような重要インフラを提供する際、可用性と回復力はデータプレーンそのものに組み込まれていなければなりません。これは、一般的な稼働率指標を目指すだけでは不十分です。データプレーン層で実際に99.999％の可用性SLAを提供しなければなりません。ユーザーセッションが検査・保護・ルーティングされる層がダウンすれば、企業はオフラインになるか、危険にさらされるのです。 

このSLAを達成するには、データプレーンに関わるすべてのコンポーネントが自動復旧を前提に設計されている必要があります。物理デバイス、外部サービス、クラウドプロバイダーなど、冗長性や高速フェイルオーバーを持たない依存先はすべて単一障害点となります。 

現実的に、インフラを自社で所有することがどうしても不可欠なのです。そうすることでのみ、設計・管理・回復力の改善を継続的に行えます。外部サービスを使う場合も、ステートレスで簡単に置き換え可能、かつ監視可能なコンポーネントとして設計し、影響なく故障できるようにする必要があります。回復は自動で行われるべきで、後手対応であってはなりません。 

もしインフラを完全にコントロールできない場合でも、その障害発生の仕方や回復速度はコントロールしなければなりません。 

企業がSASEベンダーに求めるべきこと

SASEベンダーがクラウドプロバイダーの障害に振り回されるなら、それは「SASEクラウド」を構築しているのではなく、「借りている」だけです。それでは十分ではありません。 
 
ベンダーに確認すべき質問： 
– コントロールプレーンはどこにホストされているか？ それがダウンしたらどうなるのか？ 
– セッション中にPoPが停止したらどうなるのか？ 
– プロバイダーや地域間のフェイルオーバー速度はどれくらいか？ 
– 検査エンジンはマルチテナント、自己修復、ロードバランス対応か？ 
 
そして最も重要なのは：それを実証したことがあるかどうかです。 
 
Catoには、その実績があります。それも、一度だけでなく、何度もです。