--- title: "[ 祝 GCP大阪リージョン正式オープン ] 大阪と世界の距離を測ってみるテスト | grasys blog" url: "https://blog.grasys.io/post/noriko/test-gcp-osaka-region/" description: "祝 大阪リージョン正式オープン！！ ついに Google Cloud (GCP) Platform Japan Blog での発表がありましたヽ(=´▽\\ =)ﾉ リージョン名は asia-northeast2、ゾーンは a、b、c とあります。 プロダクトの詳細は プロダクト比較 をご覧ください。 そんなわけで、ま…" --- # \[ 祝 GCP大阪リージョン正式オープン \] 大阪と世界の距離を測ってみるテスト - ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[noriko](/authors/noriko/) - 公開日：2019年5月14日 - カテゴリー：[Tech](/categories/tech/) - タグ：[#Google Cloud](/tags/google-cloud/) ![\[ 祝 GCP大阪リージョン正式オープン \] 大阪と世界の距離を測ってみるテスト](/_astro/og-image.DDSiu2Ny_XHpDd.webp) 祝 大阪リージョン正式オープン！！ ついに [Google Cloud (GCP) Platform Japan Blog](https://cloudplatform-jp.googleblog.com/2019/05/google-cloud-launches-new-osaka-region-to-support-growing-customer-base-in-japan.html) での発表がありましたヽ(=´▽\`=)ﾉ リージョン名は asia-northeast2、ゾーンは a、b、c とあります。 プロダクトの詳細は [プロダクト比較](https://cloud.google.com/about/locations/?hl=en®ion=asia-pacific#region) をご覧ください。 そんなわけで、まずはネットワーク的距離について実験＆まとめてみました。 ## 東京リージョン、大阪リージョンといくつかのリージョン間の転送速度とRTTを調べてみる nuttcp server を大阪と東京リージョンに置き、他のゾーンのクライアントからアクセスします。 nuttcpするスクリプトは、GCSにアップしておいて、起動時に読み込んで実行するように設定し、その結果をGCSに保存して集計します。 1回では少ないと思うので、-r , -t オプションそれぞれ10回行ってみて平均を出します。 エラーが出た場合はデータを使いません（2回ありました）。 転送速度は時間帯によって違うので、参考程度に御覧ください。 インスタンスのスペックは server側 Plain textcontent\_copy ``` OS Debian GNU/Linux 9 (stretch) マシンタイプ n1-standard-8 ``` client側 Plain textcontent\_copy ``` OS Debian GNU/Linux 9 (stretch) マシンタイプ n1-standard-1 ``` 結果です。量が多いので画像にしました。 ### nuttcp -t (クライアント側が送信元）の場合 ![nuttcp -t (クライアント側が送信元）の場合の画面（1）](/_astro/01-1-t-681x1024-2334e08a.D79Dx_jd_ZJ6I2H.webp) ### nuttcp -r (クライアント側が送信先）の場合 ![nuttcp -r (クライアント側が送信先）の場合の画面（1）](/_astro/02-1-r-681x1024-cf68c8f1.BZJqlje5_1gwcSJ.webp) なんか transmitter 側が頭打ちしてるように見えますね。CPUパワーが足りなかったのでしょうか。 というわけで、東京リージョンと大阪リージョンの分だけ n1-standard-8 にしてやり直します。 ### nuttcp -t (クライアント側が送信元）の場合 ![nuttcp -t (クライアント側が送信元）の場合の画面（2）](/_astro/03-s8-t-1024x190-09ab8e7e.DATz-U5y_ZRax3j.webp) ### nuttcp -r (クライアント側が送信先）の場合 ![nuttcp -r (クライアント側が送信先）の場合の画面（2）](/_astro/04-s8-r-1024x190-3d1b9db4.BzfkhbFv_1w9iV4.webp) 近場のネットワークを検証したい場合は、スペックがそこそこあるインスタンスを使うべきでした。 とりあえず今日中に公開したかったので今日はこのへんで。。。 以下おまけです。 ## GSCバケットを東京リージョンと大阪リージョンに作ってファイル転送してみる VMスペックは Plain textcontent\_copy ``` OS Debian GNU/Linux 9 (stretch) マシンタイプ n1-standard8 ``` ### gsutil perfdiag テスト用コマンドがあるので、まずはこれを使います。こんな感じで。 Plain textcontent\_copy ``` $ gsutil perfdiag -n 10 -s $((1024*1024*100)) -o osaka.output.json gs://osaka-test-osaka ``` \-n はテスト回数 \-s はスループットテストで使うファイルのサイズ(今回は100M。1Gにしたら時間がちょっとかかるのでやめた) \-o はテスト結果を書き出すファイル名 10回テストを行って平均を出します。 結果です。 ファイルの転送にかかった時間です（単位: sec）。 | zone (region) | GCS (region) | UPLOAD 1024byte | DOWNLOAD 1024byte | UPLOAD 1Mbyte | DOWNLOAD 1Mbyte | | --- | --- | --- | --- | --- | --- | | asia-east1-a (taiwan) | tokyo | 0.117 | 0.167 | 0.374 | 0.181 | | asia-northeast1-a (tokyo) | tokyo | 0.091 | 0.037 | 0.156 | 0.054 | | asia-northeast2-a (osaka) | tokyo | 0.110 | 0.113 | 0.216 | 0.125 | | asia-east1-a (taiwan) | osaka | 0.119 | 0.192 | 0.684 | 0.297 | | asia-northeast1-a (tokyo) | osaka | 0.109 | 0.113 | 0.247 | 0.227 | | asia-northeast2-a (osaka) | osaka | 0.093 | 0.045 | 0.193 | 0.051 | 1秒あたりの転送速度です（単位: Mbyte)。 | zone | GCS (region) | write 転送速度 | read 転送速度 | | --- | --- | --- | --- | | asia-east1-a (taiwan) | tokyo | 76.541 | 273.260 | | asia-northeast1-a (tokyo) | tokyo | 115.562 | 358.763 | | asia-northeast2-a (osaka) | tokyo | 126.139 | 358.344 | | asia-east1-a (taiwan) | osaka | 93.931 | 185.076 | | asia-northeast1-a (tokyo) | osaka | 151.485 | 301.497 | | asia-northeast2-a (osaka) | osaka | 149.026 | 451.079 | ## mysql のレプリケーションを試してみる master を 東京リージョン、slave を東京リージョンと大阪リージョンに作成してslaveに遅延がどのくらい出るのか試してみます。 お試しなので、apt-get でサクッとインストールします。設定もデフォルトのままで行きます。 \# レプリケーションの構築方法については割愛します。 \# Debian で mysql-server をインストールすると mariaDBになりますが、便宜上 mysql の表記のままで行きます。 計測には pt-heartbeat を利用しました。 Plain textcontent\_copy ``` OS Debian GNU/Linux 9 (stretch) マシンタイプ n1-standard8 ``` 1行120byte程度のINSERT文を10000回投げてみたところ、pt-heartbeat では1秒以上の遅延は見られませんでした。 1行1Mbyte程度のINSERT文を10000回投げたところ、pt-heartbeat で1秒以上の遅延が何度か見られました。東京・大阪どちらのslaveでも同時に起こっているパターンが半分くらい。全体で5分程度かかっていいましたが、その中で遅延があったのは、東京側3回、大阪側5回でした。 もうちょっと差異が出るのかなと思っていたので何度もやってみたのですが、毎回こんな感じでした。 ## 最後に 国内向けのサービスで、東京リージョンとマルチリージョンで運用したいなぁと思った時、台湾リージョン？うーん？？？となっていたのが解消されそうです。 はじめは東京と大阪と台湾間くらい計測すればいいかなと思ったのですが、やってるうちにあれもこれもとなって、結局現在動いているゾーンすべてに対して調べることにしてみました。 スクリプトを書いて実行するので手間は別にないのですが、nuttcp server に同時にアクセスしまくるとエラーが頻発したので、ちょっとずつアクセスするようにしました。 そのせいで、スクリプトの実行には4、5時間くらいはかかった気がします。 あと、nuttcp の結果表示がこんな感じなのですが Plain textcontent\_copy ``` 15706.9843 MB / 10.00 sec = 13173.7312 Mbps 51 %TX 47 %RX 0 retrans 0.31 msRTT 2341.7562 MB / 10.01 sec = 1962.0664 Mbps 7 %TX 13 %RX 0 retrans 0.35 msRTT 166.1592 MB / 10.26 sec = 135.8743 Mbps 0 %TX 0 %RX 0 retrans 157.53 msRTT ``` 行頭にスペース入れるか入れないかはっきりして！（取っちゃえばいいんですけど） ってなりました。 書いたスクリプトが間違っていないことをただ祈るのみです。 ## この記事を書いた人 [![](/_astro/noicon.CTHOhNiB_Z24aAgM.webp)](/authors/noriko/) ### [noriko](/authors/noriko/) norikoのプロフィールと執筆記事をご覧いただけます。 [プロフィールと記事一覧](/authors/noriko/)