GSP045

概要

このハンズオンラボでは、現実のシナリオについて読み進め、その環境を再現することで、問題のあるネットワークのパフォーマンス改善に取り組みます。

トラブル シューティングのユースケースに対応するように、さまざまなインスタンスを比較検証してみてください。そうすることで、結果を実証してシステムのパフォーマンスを改善するための手順を理解できます。

このラボは、Colt McAnlis 氏によるブログ投稿「Core Count and the Egress problem」と「Internal IP vs External IP」を基に作成されています。McAnlis 氏は Medium で Google Cloud のネットワーク パフォーマンスに関するブログを投稿しています。

目標

• オープンソース ツールを使用して、ネットワークの接続とパフォーマンスをテストする
• オープンソース ツールを使用して、ネットワーク トラフィックについて調べる
• マシンのサイズがネットワークのパフォーマンスに与える影響について確認する

前提条件

• Google Cloud サービスに関する基本的な知識があること（すでに「Google Cloud Essentials」のラボを受講していれば尚可）
• Google Cloud ネットワーキングと TCP/IP に関する基本的な知識があること（すでに「Networking in the Google Cloud」コースのラボを受講していれば尚可）
• Unix / Linux コマンドラインに関する基本的な知識があること

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 左側の [ラボの詳細] ペインには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] ペインでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] ペインでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

このラボの目標は、コアサイズとスループットの関係を学習することです。ラボにはすでに 6 つのインスタンスが組み込まれています。これらのインスタンスは、このラボを開始したときに作成されたものです。

• Cloud コンソールで、ナビゲーション メニュー > [Compute Engine] > [VM インスタンス] の順に移動して、インスタンスを表示します。

注: 実際のインスタンスのリージョンとゾーンは、このスクリーンショットとは異なる場合があります。

接続テスト

簡単な接続テストを行って、問題がないことを確認します。

1. コンソールで、インスタンス名の横にある [SSH] ボタンをクリックして、instance-1 に SSH 接続します。

2. 新しいシェル ウィンドウで、次のコマンドを実行して別のインスタンスを ping します。<external ip address of instance-2> は instance-2 の外部 IP アドレスに置き換えてください。

ping -c 5 <external ip address of instance-2>

出力例:

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.158.169 PING 35.194.158.169 (35.194.158.169) 56(84) bytes of data. 64 bytes from 35.194.158.169: icmp_seq=1 ttl=76 time=1.89 ms 64 bytes from 35.194.158.169: icmp_seq=2 ttl=76 time=0.409 ms 64 bytes from 35.194.158.169: icmp_seq=3 ttl=76 time=0.542 ms 64 bytes from 35.194.158.169: icmp_seq=4 ttl=76 time=0.557 ms 64 bytes from 35.194.158.169: icmp_seq=5 ttl=76 time=0.559 ms --- 35.194.158.169 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.409/0.792/1.894/0.554 ms

3. さらに、別のインスタンスを ping します。<external ip address of instance-3> を instance-3 の外部 IP アドレスに置き換えて、instance-3 を ping します。

ping -c 5 <external ip address of instance-3>

出力例:

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.187.75 PING 35.194.187.75 (35.194.187.75) 56(84) bytes of data. 64 bytes from 35.194.187.75: icmp_seq=1 ttl=64 time=1.59 ms 64 bytes from 35.194.187.75: icmp_seq=2 ttl=64 time=0.336 ms 64 bytes from 35.194.187.75: icmp_seq=3 ttl=64 time=0.338 ms 64 bytes from 35.194.187.75: icmp_seq=4 ttl=64 time=0.302 ms 64 bytes from 35.194.187.75: icmp_seq=5 ttl=64 time=0.270 ms --- 35.194.187.75 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.270/0.568/1.596/0.514 ms

問題なさそうなので、次に進みます。

ファイアウォール ルールの確認

このラボ用にファイアウォール ルールも作成されています。

• ファイアウォール ルールを確認するには、ナビゲーション メニュー > [ネットワーキング] > [VPC ネットワーク] > [ファイアウォール] の順に移動し、iperftesting ファイアウォールをクリックします。

ファイアウォール ルール iperftesting は、以下のように設定されています。

フィールド	値	備考
名前	iperftesting	新しいルールの名前
ターゲット	ネットワーク上のすべてのインスタンス
ソース IP の範囲	0.0.0.0/0	インターネット上の任意の IP アドレスにファイアウォールを開放
プロトコルとポート	tcp:5001; udp:5001
トラフィックの方向	Ingress
一致したときのアクション	許可

これでラボを開始する準備が整いました。

ユースケース 1: ネットワーキングと Compute Engine のコア数

この最初のシナリオでは、使用しているマシンのサイズが、スループットの測定にどのように影響するかを調べます。

Dobermanifesto はペット専用の動画ミニブログ ネットワークです。動物の動画を世界中からアップロードでき、どこからでも視聴して楽しむことができます。

このネットワークでは、Compute Engine バックエンドとのデータの転送中に測定された帯域幅が、期待を下回るものでした。

タスク 1. 動作を再現する

この動作を再現するために、同じゾーン内に 2 つのインスタンスを作成し、それらの間で iperf を 100 回実行しました。

パフォーマンスはさらに悪化しました。何か問題があるようです。Dobermanifesto から詳しい情報と詳細な再現ステップを入手する必要があります。

ここでシナリオを設定します。

Dobermanifesto の環境

1. Compute Engine コンソールの VM インスタンスのリストに戻ります。

2. instance-1（1 vCPU 3.75 GB）に SSH 接続し、次のコマンドを実行して iperf の「受信者」を設定します。

iperf -s

3. 次に、instance-2（1 vCPU 3.75 GB）に SSH 接続し、instance-1 に対する iperf トラフィックを生成します。

iperf -c <external ip address of instance-1>

出力例:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.225.180.44 ------------------------------------------------------------ Client connecting to 35.225.180.44, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.0.4 port 56330 connected with 35.225.180.44 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0000-10.0010 sec 4.66 GBytes 4.00 Gbits/sec

4. instance-1 に戻り、CTRL + C を押して受信を終了します。

テスト環境

1. Compute Engine コンソールに戻り、instance-6（1 vCPU e2-micro 0.6 GB）に対する別の SSH ウィンドウを開きます。

2. 次のコマンドを実行し、このインスタンスを「受信者」として設定します。

iperf -s

出力例:

student-00-aafd1bd9c185@instance-6:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

3. instance-2 の SSH ウィンドウで、instance-6 への接続をテストします。

iperf -c <internal ip address of instance-6>

出力例:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.7 ------------------------------------------------------------ Client connecting to 10.40.0.7, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.5 port 54029 connected with 10.40.0.7 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.29 GBytes 1.96 Gbits/sec

4. instance-6 に戻り、CTRL + C を押して受信を終了します。

どうなりましたか？帯域幅が広くなったようです。これは実際の環境にも当てはまるかもしれません。

次のセクションでは、帯域幅が総コア数によってどのように制限されるかを見ていきます。この狭い範囲のコア数（コア数 1）では、帯域幅が 2 Gbit/秒を超えることはありません。そのため、ネットワーク速度は遅くなり、帯域幅が制限され、Dobermanifesto の環境と同じ問題が生じます。4 CPU のマシンを使用して 1 分間テストしてみましょう。より良い結果が得られるはずです。

Gbit/秒と相関するコア数

結果がそれほど変わらなかったのはなぜでしょうか。Compute Engine のドキュメントには、次のように記載されています。

仮想マシンからの送信トラフィック、つまり外向きトラフィックは、ネットワークの最大外向きスループットの影響を受けます。この最大値は、仮想マシン インスタンスにある vCPU の数に依存します。各コアの容量は、ピーク パフォーマンス時で 2 Gbit/秒（Gbps）です。コア数を追加することでネットワークの容量が増加し、理論的には仮想マシンごとに最大で 16 Gbit/秒となります。

つまり、ネットワーク内の仮想 CPU の数が多いほど、ネットワーキング スループットは向上します。

これが実際にどのように見えるかを理解するために、さまざまなコアサイズ グループを同じゾーンに設定し、そこで iperf を 1,000 回実行しました。

コア数が増加するにつれて、平均スループットと最大スループットは増加しています。この簡単なテストでも、上位マシンに 16 Gbit/秒という上限があることがわかります。

注: iperf を複数のスレッド（8 程度）で実行すると、10 Gbit/秒を超えることがあり、e2-standard-16 以上を使用すると、最大約 16 Gbit/秒に達します。このラボ環境にはこうしたサイズのマシンが用意されていないため、複数のスレッドでテストしてみましょう。 より料金の高い N2、N2D、C2、C2D シリーズの VM を利用することも可能です。これらの VM では、広い帯域幅（50～100 Gbit/秒）の Tier 1 構成を選択できます。

タスク 2. 結果の改善方法

Dobermanifesto が接続するネットワークでは 1 vCPU マシンが使用されています。コアのサイズを大きくすれば、おそらく結果は改善されるはずです。この理論を試してみましょう。

1. instance-3（4 vCPU 15 GB メモリ）に SSH 接続し、次のコマンドを実行します。

iperf -s

出力例:

student-00-aafd1bd9c185@instance-3:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. instance-4（4 vCPU 15 GB メモリ）に SSH 接続します。

iperf -c <internal ip address of instance-3>

出力例:

student-00-aafd1bd9c185@instance-4:~$ iperf -c 10.40.0.2 ------------------------------------------------------------ Client connecting to 10.40.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.4 port 54081 connected with 10.40.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 8.93 GBytes 7.67 Gbits/sec

3. 今度は 4 つのスレッドでもう一度試してみます。

iperf -c <internal ip address of instance-3> -P4

4. 8 つのスレッドでも試してみます。

iperf -c <internal ip address of instance-3> -P8

5. instance-3 に戻り、CTRL + C を押して受信を終了します。

これらの実験では、サーバーとクライアントの両方が 4 vCPU であり、速度は大幅に向上しました。転送速度は 6.64 GB、帯域幅は 5.71 Gbit/秒の改善となり、マルチスレッドのパフォーマンスではコア数の上限に達することができました。

6. 次に、instance-5 でテストを行います。これも 4 vCPU の高性能マシンで、インスタンス タイプは「highcpu-4」です。

このインスタンス タイプでは、CPU はより高速ですが、メモリは少なくなっています。何か違いは生じたでしょうか？マルチスレッドでも試してみましょう。

ここで、Dobermanifesto のチームはどの対策をとるか決める必要があります。CPU 使用率をプロファイルし、料金を調べた結果、e2-standard-4 マシンを使用することにしました。これにより、平均スループットはほぼ 4 倍に向上し、費用も e2-standard-8 マシンより低くなります。

大型のマシンに移行することの利点の一つは、実際には実行頻度が少なくなることです。つまり、データ転送のためだけに、マシンが長時間待機することになります。マシンサイズを変えることでインスタンスのダウンタイムが増えれば、ロードバランサは 1 日あたりのインスタンスの総数を減らすことができます。高性能のマシンに費用をかけることにはなりますが、その一方で、毎月のコア時間を減らすことができるのです。

パフォーマンスが収支に直接影響を与える場合は、何を優先して何を犠牲にすべきか、微妙な違いを検討する必要があります。

ユースケース 2: 内部 IP を使用した Google Cloud ネットワーキング

次の例では、iperf を使用してスループットの速度をテストします。1 つのマシンをサーバーとして設定してから、そのサーバーと通信する複数のマシンを設定して結果を比較します。

Gecko Protocol は、カスタム軽量ネットワーキング プロトコルをゲームやリアルタイム グラフィック システム用に提供する B2B 企業です。同社では、大規模な動画やグラフィック ファイルの転送とコード変換を行うバックエンド マシンで想定を下回るスループットが課題となっています。

ベースラインの iperf テストの結果は次のとおりです。

------------------------------------------------------------ Client connecting to 104.155.145.79, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 53504 connected with 104.155.145.79 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.03 GBytes 884 Mbits/sec

再現テストを実施したとき、ネットワーク設定は同じでしたが、テスト結果は次のようにまったく異なっていました。

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.128.0.2 ------------------------------------------------------------ Client connecting to 10.128.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 38978 connected with 10.128.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.27 GBytes 1.95 Gbits/sec

1.95 Gbit/秒という速度は、Gecko Protocol のグラフで見られたものよりもはるかに高い数値です。何が起きているのでしょうか。

このシナリオを再現してみましょう。

1. コンソールで instance-1 に SSH 接続し、iperf の「受信者」を設定します。

iperf -s

出力例:

student-00-aafd1bd9c185@instance-1:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. instance-2 に SSH 接続し、外部 IP アドレスを使った接続を確認します。

iperf -c <external ip address of instance-1>

出力例:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.201.145.135 ------------------------------------------------------------ Client connecting to 35.201.145.135, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 58691 connected with 35.201.145.135 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.36 GBytes 1.16 Gbits/sec

Gecko Protocol と確認したところ、マシンの接続には外部 IP アドレスが使用されていたことがわかりました。ベースライン テストでは内部 IP アドレスを使用した点が異なります。マシンがネットワーク内にある場合、それらを内部 IP に接続するとスループットが向上します。

3. 今度は、内部 IP アドレスを使った接続を確認します。

iperf -c <internal ip address of instance-1>

出力例:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 42950 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.26 GBytes 1.94 Gbits/sec

2 つのテストで転送速度と帯域幅レートが異なることに注目してください。2 回目のテストで内部 IP アドレスに変更したことで、転送速度が 0.9 GB、帯域幅が 0.78 Gbit/秒、改善されました。つまり、内部接続のほうが速いことが証明されました。

Dobermanifesto の問題の解決策から考えると、マシンサイズを大きくすることでネットワーク速度は改善されるでしょうか。instance-2 の vCPU は 1 つだけです。このマシンを少し大きくすると、接続はどの程度速くなるでしょうか。さらに大きくした場合はどうでしょうか。内部 IP アドレスを使用してテストを続けます（時間がある場合は、外部 IP アドレスもテストしてみましょう）。

vCPU を 4 個に増やした場合

• instance-3 に SSH 接続し、内部 IP アドレスでの接続をテストします。

iperf -c <internal ip address of instance-1>

出力例（実際の結果はこれとは異なる場合があります）:

student-00-aafd1bd9c185@instance-3:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.6 port 39115 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 4.53 GBytes 3.89 Gbits/sec

ハイ CPU マシン 4 個の場合

• instance-5 に SSH 接続し、内部 IP アドレスでの接続をテストします。

iperf -c <internal ip address of instance-1>

出力例:

student-00-aafd1bd9c185@instance-5:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.3 port 39736 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 10.3 GBytes 8.84 Gbits/sec

このように、スループットは大幅に改善されます。

よって、Gecko Protocol は、最適なコアサイズについても検討の余地があると言えます。今回の簡単なテストでも、動画とグラフィックのデータ転送速度が約 14 倍向上しました。同社のサービスがハイ パフォーマンス コンピューティング シナリオ向けのパフォーマンス バックエンド サービスを基に構築されていることを考えると、実際にはこれ以上の改善が見込まれる可能性があります。

タスク 3. 独自の環境でのテスト

このラボでは、受講生が独自のシステムをテストする方法については扱いませんが、その際に役立つ追加の情報を以下に示します。独自のネットワーク テストに関する詳細は、iPerf を使用したネットワーク スループットのテストをご覧ください。

時間があれば、VM を設定してテストすることもおすすめします。VM を作成するときは、必ず「iperftest」ファイアウォール ルールとタグを使用してください。内部 IP アドレスと外部 IP アドレスの両方をテストしてみましょう。

独自のネットワークをテストするための設定

1. コンソールで、ナビゲーション メニュー > [ネットワーキング] > [VPC ネットワーク] > [ファイアウォール] の順に移動します。

2. [ファイアウォール ルールを作成] をクリックします。以下の構成を使用してファイアウォール ルールを作成します。

フィールド	値	備考
名前	iperf-testing	新しいルールの名前
ターゲット	ネットワーク上のすべてのインスタンス
ソース IP の範囲	0.0.0.0/0	インターネット上の任意の IP アドレスにファイアウォールを開放
トラフィックの方向	ingress
一致したときのアクション	許可
プロトコルとポート	tcp:5001; udp:5001

3. [作成] をクリックします。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。ファイアウォール ルールを作成する

ワークロードをできるだけ 100% に近づけようとするため、ディスクのデフラグなどのためのスペースはほとんど残りません。

使用率が健全であれば 90～93% ですが、98% になると多くの競合が発生するため、パフォーマンスが低下します。

テスト中に IO パフォーマンスが低下した場合は、スロットル カウンタを確認します。スロットリングされていない場合は、CPU 使用率を調べてください。高い場合は問題があります。

タスク 4. 復習

ラボ インターフェースの左側にある [受講者向けリソース] に、このラボに関連する動画へのリンクがあります。ぜひご覧ください。

お疲れさまでした

これで完了です。このラボでは、オープンソース ツールを使用してネットワークの接続とパフォーマンスをテストする方法と、マシンのサイズがネットワークのパフォーマンスにどのように影響するかについて学びました。

次のステップと詳細情報

• Google Cloud ブログ投稿「Using Google's cloud networking products: a guide to all the guides（Google のクラウド ネットワーキング サービスの使用: すべてのガイドのガイド）」を読む
• Compute Engine のネットワーキングに関するドキュメントを読む
• サブネットワークの詳細を確認する
• Stackoverflow で google-compute-engine タグまたは google-cloud-platform タグを付けて質問を投稿し、回答を得る

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2024 年 11 月 8 日

ラボの最終テスト日: 2024 年 11 月 8 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。