急増するトラフィックに対応：日本のゴールデンウィーク後のトラフィック急増をどう乗り切ったか 

はじめに 

ゴールデンウィークは、多くの人が楽しみにしている大型連休ですが、ITおよびネットワーク運用チームにとっては、試練の時としても知られています。完全な休業期間を経て企業が再開すると、数百万人の従業員が現地時間午前9時に同時にログインし、激しいトラフィックの急増を引き起こしています。 

Cato Networksでは、毎年この瞬間を予測して備えています。しかし今回は、単に「対応する」ことが目標ではありませんでした。ピーク時にトラフィックが2倍以上に増加する中でも、すべてのユーザーに完璧な体験を提供することを目指しました。 

私たちは「厳しい訓練が、本番を楽にする」という信念を大切にしています。つまり、実際の運用環境が直面する可能性のある状況よりもはるかに過酷な条件を想定して、自社のインフラを準備するということです。私たちはまた、自らに最も厳しい批評家でもあります。常にストレステストを行い、前提を疑い、現実に課題が発生したときに「単に準備ができている」だけで終わらせないようにしています。私たちには自信があります。 

本記事では、私たちがグローバルネットワークにおいて最も過酷な実環境のひとつにどのように備え、妥協することなく運用を成し遂げたのか、その舞台裏のエンジニアリングとオペレーションのストーリーをお届けします。 

ゴールデンウィークの急増を読み解く 

米国では、祝日明けの業務再開が複数のタイムゾーンや州にまたがって分散しているのに対し、日本では、休暇明けの業務再開が非常に同期的かつ地理的に集中します。多くの従業員が中央都市圏から一斉に業務を再開するため、特に東京や大阪といった地域のPoPに急激な負荷が集中します。 

観測によると、業務開始から最初の30分以内に、通常のピーク時と比べてトラフィック量が2.5倍以上に急増することもあります。このトラフィックの急増は、単なるユーザーのログインだけではありません。デバイス全体の同期処理、ソフトウェアのアップデート、コラボレーションプラットフォームの更新なども含まれています。実際、急増時のトラフィック分析によると、Microsoft OneDrive、Windows Update、Office 365、Adobe、SharePoint、Microsoft Exchangeといったアプリケーションが全体の約70％を占めていました。 

こうした動きは、帯域幅やスループットを試すだけでなく、暗号処理からリアルタイムのルーティング判断に至るまで、アーキテクチャのあらゆる層に負荷をかけることになります。 

課題 

今年はゴールデンウィーク明けに大幅なトラフィックの急増があると予測しており、その予測は的中しました。SaaSアプリケーションのアップデートを主因として、同時接続ユーザーの急増と帯域幅消費の大幅な上昇が発生しました。この需要は私たちのネットワーク全体に広がっていました。支店のユーザーは再認証を行い、Windowsアップデートをダウンロードし、ファイルを同期。モバイルユーザーやリモートユーザーはVPNトンネルを介して再接続しました。クラウド上のワークロードも再び稼働を開始し、SaaSプラットフォームとの同期が行われました。リアルタイムのトラフィックには、パフォーマンスを維持するために、優先順位付け、トラフィックシェーピング、再ルーティングといった積極的な制御が求められました。私たちのアーキテクチャは、スケールだけでなく、プレッシャー下での精度も提供しなければなりませんでした。 

Cato アーキテクチャ：ピーク時の負荷とレジリエンスを見越した設計 

私たちのプラットフォームは、こうした過酷な状況を想定して設計されており、クラウドネイティブでマルチコアなアーキテクチャに、深い可観測性と自動防御機能を組み合わせています。 

マルチコアと分離設計による高負荷対応： 

急激なトラフィック需要に対応するため、私たちはいくつかの重要なアーキテクチャ機能に依存しました。 

• 分散型マルチコアアーキテクチャ：複数のCPU間で負荷を分散し、最大10Gbpsの帯域幅を持つ拠点（ソケットサイト）をサポート可能にします。 

• リソース予約機能：極端な負荷下でも、高帯域幅を必要とする拠点に対し一貫したパフォーマンスを保証します。 

• 独自のオフロードアーキテクチャ：大規模な暗号化・復号処理を独立して管理することで、CPUリソースの負担を軽減し、全体的な帯域効率を向上させます。 

DTLSの最適化とコアレベルでの終端処理： 

当社のPoPで終端されるすべての暗号化トンネルはDTLSに依存しており、これには効率的で安全かつ高スループットな復号処理が求められます。当社のインフラはこれを大規模に処理できるよう最適化されており、ハードウェアによる暗号処理のオフロードと動的なサービスコアの割り当てによって実現されています。 

トラフィック急増時のレジリエンス対応 

連休明けの急激なトラフィック増加に関係なく、当社では常時、DDoS攻撃やログインの総当たり攻撃といった悪意のある挙動を監視しています。当社独自のリアルタイム検出エンジンは、地域ごとのベースラインに基づき学習されており、悪意のあるトラフィックを即座に遮断できます 

また最近では、東京に4台目となる大容量ルーターを新たに導入し、地域内のすべてのPoPにおいてトラフィックを負荷分散することに成功しました。これにより、ピーク時における冗長性とパフォーマンスの両方を強化しています。 

トラフィック急増中のレジリエンスを保つため、以下のようなモニタリング体制を実施しました： 

• いつでも、エンドユーザーの体験に影響を与えることなく、大量のトラフィックによる攻撃（ボリュメトリック・フラッド）を検知し、軽減することができました。 

• DPDKのミスレートおよびポート使用率を監視し、NIC（ネットワークインターフェースカード）およびパケットプロセッサが想定された閾値内で正常に動作していることを確認しました。 

• ルーターの同期異常とトラフィックパターンを相関させることで、ユーザーに影響を及ぼす問題に発展する前に、微細な障害を事前に検出しました。  

これは単なるスケーリングではありませんでした。正当な需要と潜在的な攻撃的状況の両方に対するレジリエンス（耐障害性）でもありました。 

日本固有のインフラ準備 

連休明けに最初のパケットがネットワークに届く前から、私たちは日本のインフラをこの特殊な負荷シナリオに対応できるよう準備していました。実施したことは以下の通りです： 

PoPの拡張と冗長性の確保 

日本国内に新たなPoPを追加し、既存のインフラをアップグレード。地理的な分散性とレジリエンスを高めました。具体的には以下の施策を含みます： 

• ルーターのハードウェアをアップグレードし、物理的なスループットを大幅に向上させることで、ポート密度とインターフェース容量の両方を拡張しました。これにより、各ルーターは劇的に多くの同時トラフィックを処理できるようになり、日本のPoPからの需要急増に対応できる体制が整いました。 

• また、PoP内部のデータパスを拡張し、顧客向けサービスとコア処理コンポーネントを接続することで、負荷時における東西方向のトラフィック増加にも対応可能にしました。 

• さらに、パケット検査、トンネリング、暗号化といった計算負荷の高い処理をスケーラブルに対応するために、CPUコアを増設しました。 

監視機能の活用 

私たちは監視機能を活用することで、ネットワーク上のストレスポイントやプレッシャーポイントを特定し、問題を未然に回避するとともに、複数のレイヤーにわたってパフォーマンスを微調整しました。例： 

• 各PoPにおけるルーターのトラフィック、VPNトンネル数、およびトンネルスループットのリアルタイム監視 

• ポート使用率、パケットロスのレベル、コンポーネント間の同期失敗の可視化 

• 日本国内の各PoP専用のカスタムダッシュボードにより、業務再開初日の最初の1時間におけるヘルスとパフォーマンスをトラッキング 

これにより、エンジニアはシステム内のあらゆる要素を正確に把握することができ、ユーザー体験への影響を未然に防ぐことができました。 

図1では、東京PoPにおけるルーター全体のトラフィックが、4月29日（単日の祝日）からゴールデンウィーク明けの初営業日である5月7日にかけて、帯域幅で2倍に増加したことを示しています。図2（UTC表記）では、日本のPoPの1つにおいて、日本時間9:00（UTCの深夜0:00）ちょうどにルータートラフィックがピークを迎えている様子が強調されています。図3は9:00におけるVPNトンネル数の急増を示し、図4は同時刻におけるVPNトンネルのスループット（DTLSおよびIPSec接続を含む）の増加を示しています。図5および図6では、ZTNA（ゼロトラストネットワークアクセス）におけるユーザー接続数とスループットが、通常日と比較して2倍以上に急増したことが示されています。

図1：東京PoP – ルーター全体のトラフィック：4月29日（単日の祝日）から5月7日（ゴールデンウィーク明け初営業日）にかけて帯域幅が2倍に増加 

図2：東京PoP – ルーター全体のトラフィック量 

図3：東京PoP – VPNトンネル総数（DTLSおよびIPSec接続を含む）

図4：VPNトンネル（DTLSおよびIPSec接続を含む）のスループット推移 

図5：日本におけるZTNAユーザー接続数の総計 

図6：日本におけるZTNAユーザーのスループット総計 

ゴールデンウィーク明けの急増に伴うアプリケーション利用状況の詳細分析へ 

図7では、帯域幅消費の観点から最も影響の大きいアプリケーションを示しています。ゴールデンウィーク明け、日本国内の各PoPにおいて、Windows Update、Microsoft Office365、Adobe がネットワークトラフィックの主な要因となり、システム更新と業務再開が同時に発生したことを反映しています。また、OneDrive、SharePoint、Outlook、Microsoft General Services も顕著な利用が見られ、Microsoftエコシステム内での継続的なコラボレーションとコミュニケーションが行われていることを示しています。この利用分布は、Microsoftサービスが休暇明けの業務活動において支配的な役割を果たしていることを示すとともに、クラウド主導のコラボレーションを大規模に安定して支えるインフラの必要性を強調しています。 

図7：日本国内の各PoPにおける主要アプリケーションの使用状況 

運用の実行 

基盤の準備は整い、いよいよ本番を迎える瞬間が訪れました。NOC（ネットワークオペレーションセンター）チームは完全な体制で待機し、特に予想されるピーク時間帯である午前9時〜10時（日本時間）には万全の警戒態勢が敷かれました。 

自動化 × 手動による可視化体制 

自動化された異常検知と、エンジニアによる手動監視を組み合わせて運用しました。主な対応策は以下の通りです： 

• 顧客設定における負荷ポイントの週次分析（例：誤って設定されたegress IPによる不必要な経路の増加）を行い、事前にポリシーを最適化しました。 

• 各拠点ごとのサービスコアをリアルタイムで監視し、CPUコアが飽和状態に近づいていないかを常時チェックしていました。 

• また、PoP内部の通信経路およびインターネットプロバイダーとの外部ピア接続も継続的にモニタリングし、異常が発生した場合には自動化ツールを使って即時対応できる体制を整えていました。 

成果：ピーク時でも最適なユーザー体験を実現 

その結果、過去最大級のトラフィック負荷にもかかわらず、私たちのインフラ全体にわたり力強く一貫したパフォーマンスを提供することができました。主なハイライトは以下の通りです： 

• VPNトンネル数とスループットは過去最高値の2倍超を記録しましたが、遅延の増加は一切なし。 

• ルーターのトラフィック量は過去最高を更新しましたが、パケット損失率は無視できるレベルにとどまりました。 

先を見越したスケーリング、緻密なオペレーション管理、そしてレジリエンスを前提に設計されたアーキテクチャによって、私たちはお客様が本当に必要としていたものを提供することができました。それは、どんなにトラフィック量や背景の処理が複雑でも、ただ「普通に機能する」ネットワーク。