GSP045

概要

このハンズオンラボでは、現実のシナリオをいくつか読んでその環境を再現し、問題のあるネットワークのパフォーマンスを改善します。

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

このラボは、Colt McAnlis によるブログ投稿「Core Count and the Egress problem」と「Internal IP vs External IP」を基に作成されています。Colt は 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 コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

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

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

   重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

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

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

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、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
トラフィックの方向	内向き
一致したときのアクション	許可

これでラボを開始できるようになりました。

ユースケース 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 分間テストしてみると、結果はもっと良くなります。

Gb/秒と相関するコア数

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

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

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

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

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

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

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

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

4 基の vCPU マシン

• 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

4 基のハイ CPU マシン

• 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 アドレスに対してファイアウォールを開きます。
トラフィックの方向	内向き
一致したときのアクション	許可
プロトコルとポート	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 テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2023 年 10 月 4 日

ラボの最終テスト日: 2023 年 10 月 4 日

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