はじめに
少し前の話で恐縮ですが、2026年1月5日。多くの企業にとって仕事始めとなる月曜日の朝、とある顧客企業でその事件は起きました。
午前9時、社員が一斉に業務を開始した直後、ITサポート窓口に悲鳴のような報告が相次ぎます。
- 「ネットが極端に遅い」
- 「Teamsの会議に参加できない」
- 「特定のサイトだけタイムアウトする」
本記事では、1,000台超のデバイスを管理するインフラ運用マネジャーの視点から、この「新年初日の障害」の裏側にあったZscaler（ZIA）特有の挙動と、Z-Tunnel 2.0環境におけるPACファイル設計の盲点について共有します。
1. 発生した事象：トラフィック集中による「局所的な」通信遅延
仕事始めの第1営業日、最もトラフィックが集中するピーク時間帯に申告が集中しました。
興味深いのは、全社員が影響を受けているわけではなく、「快適なユーザー」と「ほぼ通信不能なユーザー」が混在しているという点でした。
当初はISPの輻輳やZscaler全体の障害を疑いましたが、各サービスのステータスは正常。調査を進めると、特定のZscalerデータセンター（Public Service Edge）のノードにトラフィックが異常に偏っていることが判明しました。
2. 従来の設計：Proxy Hostname指定と「スティッキー」の罠
なぜトラフィックが偏ったのか。その発端は、従来のPACファイルで一般的だった「Proxy Hostname（FQDN）」による指定方法にありました。
従来のPACファイル（ビフォー）
海外のデータセンターを経由させず、確実に国内のDC（東京・大阪）を利用させるために、以下のような指定を行っていました。
// 従来の指定方法
return "PROXY tyo4.sme.zscloud.net:80; PROXY osa1.sme.zscloud.net:80; DIRECT";
この「Proxy Hostname指定」をZ-Tunnel 2.0環境で継続利用すると、大規模環境特有の問題が発生します。
- Source IPの同一化: 多くの企業ではインターネット出口でNAPTを利用していますが、Zscalerから見ると**数千人のユーザーが同一のグローバルIP（Source IP）**に見えてしまいます。
- ハッシュ値の固定: 宛先（Destination）がゲートウェイのFQDNで固定されるため、ロードバランスのためのハッシュ値が変化しません。
3. 深掘り：Zscaler DC内部の「SMLB」による負荷分散の限界
ここで重要になるのが、Zscalerデータセンター（Service Edge）内部の構造です。
Zscaler DC内部は「ノードの集合体」
Zscalerの各データセンター内には、トランザクションを処理するノードが多数稼働しており、入り口では**SMLB（Service Management Load Balancer）**がトラフィックを各ノードへ振り分けています。
なぜ「特定のノード」に固着したのか
今回のトラブルでは、このSMLBによる振り分けが以下の理由で「固着（スティッキー）」してしまいました。
- 低すぎるエントロピー: SMLBは「Source IP」と「Destination IP」をハッシュ計算の材料にします。
- NAPTの壁: 数千人が同一のSource IPに見え、かつDestination IPもHostnameで固定されるため、SMLBから見ると**「すべての通信が全く同じハッシュ値」**として計算されてしまいます。
- 局所的な過負荷: 結果として、1,000人以上のトラフィックがDC内の**「たった一つのノード」**に集中。そのノードがキャパシティオーバーを起こし、そこに割り振られたユーザーだけが通信不能になるという「局所的な障害」が発生しました。
4. 解決策：App Profile PACファイルの最適化
この問題を解決するため、Z-Tunnel 2.0でのみ利用可能な**「SVPN Virtual IP」**を用いた指定に切り替えました。
対策1：SVPN Virtual IPへの変更
SVPN Virtual IPを利用すると、ZCC（Zscaler Client Connector）が実際の宛先IPに基づいた分散処理を主導します。これにより、単一のSource IP環境でもDC内の各ノードへ適切にトラフィックが分散されます。
対策2：Z-Tunnelバージョン判別ロジックの実装
SVPN VIPはZ-Tunnel 2.0専用です。フォールバックに備え、以下のロジックを実装しました。
// App Profile PACの修正例
var tunnel2 = "${ZT2_REQUEST}";
if (tunnel2 == "true") {
// Z-Tunnel 2.0用：SVPN VIPを指定（ポート指定不要）
// 参考：https://config.zscaler.com/zscloud.net/cenr
return "PROXY 165.225.111.191; PROXY 147.161.192.55; DIRECT";
} else {
// Z-Tunnel 1.0/Legacy用：従来のHostname指定
return "PROXY ${tyo4.sme.zscloud.net_FX}:80; PROXY ${osa1.sme.zscloud.net_FX}:80; DIRECT";
}
実装のポイント:
-
165.225.111.191（東京）等のVIPを指定。 - VIP指定時はZCCが自動でポートを検出するため、
:80等のポート番号は不要です。
5. 運用マネジャーとしての学び
今回のトラブルを通じて、以下の2点を痛感しました。
- 「最新＝自動で最適」ではない: SASEのような抽象化されたサービスでも、大規模環境では「パケットが低レイヤーでどう見えるか」の理解が不可欠です。
- 技術による「納得」の形成: 現場の一次情報を整理し、ベンダーと対等に会話できる「地力」こそが、不条理な状況を打破する鍵となります。
おわりに
ネットワークの仮想化が進む今こそ、エンジニアの基礎体力が問われています。この記事が、同様の事象で悩むインフラエンジニアの一助になれば幸いです。