クラウドMacの通信品質をnetworkQualityとMTU検査で切り分ける

リモートセッションでフレーム落ちが始まったり、依存関係の取得速度が不安定になったりしても、すぐにツールチェーンを再インストールしたり、1回の速度測定だけで結論を出したりしないでください。クラウドMacの使用感は、スループット、負荷時の遅延、DNS、ルーティング、経路MTUのすべてに左右されます。まず測定条件を固定して再現可能なベースラインを収集し、比較検証によって、問題が利用側のネットワーク、通信経路、リモート側のタスク競合のどこで発生しているかを切り分けることが重要です。

測定前にテスト条件を固定する

ネットワークの測定結果を比較できるのは、条件が一致している場合に限られます。macOSのバージョン、使用インターフェース、VPN経由かどうか、測定時間帯、その時点で実行中だったタスクを記録してください。リモートマシンが依存関係をダウンロードしている、大容量ファイルを同期している、または高並列ビルドを実行している場合、得られるのは「業務負荷がかかった状態のネットワーク」測定値です。アイドル時の結果と混在させてはいけません。

最初にアイドル時のベースラインを作成し、次に実際のタスクを実行しながら同じ測定を繰り返します。各測定は少なくとも3回実行し、単発のピーク値ではなく中央値を採用します。SoarMacのノードは、コンソールで現在選択できる構成を基準に選んでください。リージョン間で比較する場合も、利用側のネットワークと測定先を変更しないようにします。

mkdir -p "$HOME/network-baseline"
cd "$HOME/network-baseline"

date -u
sw_vers
scutil --nwi
route -n get default
networkQuality -v | tee "networkquality-$(date +%Y%m%d-%H%M%S).log"

scutil --nwiでは、実際に通信を運んでいるインターフェースを確認できます。routeにはデフォルトの送信経路が表示されます。有線、無線、トンネルの各インターフェースが同時に存在する環境では、メニューバーの接続状態だけを見ていると、通信経路を誤って判断しやすくなります。

ベースラインの目的は、ネットワークが「速い」と証明することではありません。障害の前後、アイドル時と負荷時、直接接続とトンネル接続の間で比較できる一連のデータを得ることです。

スループットと負荷時の応答性を併せて確認する

networkQualityは、ダウンロード、アップロード、応答性の測定結果を表示します。大容量ファイルの同期では持続的なスループットがより重要ですが、リモートデスクトップ、SSH入力、デバッグ操作では、負荷時の往復応答性がより大きく影響します。帯域幅の数値が高くても、操作が必ず滑らかになるとは限りません。

並行測定でキューイングを特定する

ターミナルを2つ開きます。1つ目でnetworkQuality -vを実行し、2つ目で同じ対象に対して継続的にpingを実行します。

export TARGET_HOST="your-controlled-endpoint"
ping -c 40 "$TARGET_HOST" | tee ping-under-load.log

まずアイドル状態で1回実行し、次に大容量ファイルのアップロード中に実行します。平均遅延、最大遅延、変動幅を重点的に比較してください。アイドル時の遅延は安定しているのに、アップロード中だけ大幅に上昇する場合、利用側の上り回線が飽和し、出口でパケットがキューに滞留している可能性があります。この場合、リモート開発ツールを変更するよりも、同期タスクの並列数や帯域を制限するほうが一般に効果的です。

DNSとルーティングを個別に切り分ける

依存関係のダウンロード失敗が、必ずしも帯域幅の問題とは限りません。ネットワーク設定画面だけを見るのではなく、システムが実際に使用しているリゾルバを最初に確認します。

scutil --dns | tee dns-state.log
dscacheutil -q host -a name "$TARGET_HOST"
route -n get "$TARGET_HOST" | tee target-route.log

scutil --dnsには、複数のリゾルバと、それぞれに対応するドメインが表示される場合があります。コマンドラインからIPアドレスにはアクセスできるものの、ホスト名を安定して解決できない場合は、DNSを先に修正してください。名前解決は正常でも、通信が想定外のトンネルインターフェースに入っている場合は、ルーティングの優先順位を確認します。設定変更前の出力を保存し、変更後も同じコマンドで再測定してください。一度に複数の変数を変更しないことが重要です。

pingだけでなく実際のポートを確認する

対象によってはICMPに応答しないため、pingの失敗だけでサービスに到達できないと判断することはできません。自分で管理している対象では、実際に業務で使用するポートを確認します。

nc -vz -G 5 "$TARGET_HOST" 443

ポート接続には成功し、pingには応答しない場合、少なくともTCP接続の経路は利用できます。ポート接続がタイムアウトする場合は、ルーティング、ファイアウォールポリシー、トンネルの出口を引き続き確認してください。ブラウザで1回成功しただけで、断続的な障害ではないと判断してはいけません。

ペイロードを段階的に増やして経路MTUを確認する

VPNや追加のカプセル化を使用すると、実際に運べるペイロードが小さくなります。典型的な症状は、小さなリクエストは正常なのに大容量ファイルの転送が停止する、または接続確立後に長時間進捗がない、といったものです。macOSのpingでは、フラグメント禁止フラグを設定し、ペイロードサイズを変更できます。

export TARGET_IPV4="192.0.2.10"

for size in 1200 1300 1400 1450 1472; do
  echo "payload=$size"
  ping -D -c 3 -s "$size" "$TARGET_IPV4"
done

例示したアドレスは、自分で管理しているIPv4の対象に置き換えてください。小さいペイロードは安定して成功する一方、大きいペイロードが継続的に失敗する場合は、その境界値を記録し、直接接続時とトンネル接続時の両方で再測定します。リモート側インターフェースのMTUをすぐに小さくしてはいけません。まず経路のどの区間に制限があるのかを特定してください。特定しないまま変更すると、本当の問題を覆い隠し、ほかの接続にも影響する可能性があります。

後から検証できる受け入れ記録を作成する

一式の記録には、システムバージョン、インターフェース、デフォルトルート、DNSの状態、アイドル時と負荷時のnetworkQuality、同じ対象へのping、MTUの境界値を含めます。共有前に機密性の高いアドレスや内部ドメイン名をマスキングする必要がありますが、時刻、コマンドの引数、測定条件は残してください。

修正後は、元と同じ順序で測定を再実行します。測定先を変更したり、最も良い結果だけを採用したりしてはいけません。受け入れ基準には、アイドル時と負荷時の両方の結果が記録されていること、リモート操作中に持続的な高遅延が発生しないこと、ドメイン名の解決と業務ポートへの接続が連続して成功すること、大容量ファイルの転送が安定して完了すること、直接接続とトンネル接続の差異を説明できることを採用できます。こうして得られた結論であれば、サポートチケットやチームの運用手順書に反映でき、次回の障害発生時にもベースラインと直接比較できます。

よくある質問