こんにちは。GMOリサーチシステム部の中村といいます。
今日は技術広報の益山さんに変わって、僕がテックブログを書いてみます。
少し世間話なのですが、最近は新型コロナウイルス（COVID-19）対策で在宅勤務が続いています。
連日報道される怖いニュースのせいで自分も過度に心配してしまい、スーパーで買ってきたビールやみかんも石鹸であらってたら、知り合いに「気でもふれたか？」と言われてしまいました。
安心した暮らしを送れるように、経済が落ち着くように、そして、自分を取り戻せるようにも、早くおさまってほしいなと思います。
それでは本題ですが、本ブログでは「日中間のネットワーク検証」について取り上げさせていただきます。
- 日中間のネットワーク通信方法が気になる方
- 日中間、中国国内、それぞれの速度比較結果を知りたい方
- 中国特有のネットワーク（Great Fire Wall）に興味がある方
上記に当てはまる方にとって興味深い内容になってると思うので、ぜひ読んでみてください。
日中ネットワーク検証を実施した経緯
まずは、なぜこの検証が必要だったか？ということについて少し説明させていただきます。
前提として、弊社サービスは日本だけでなく海外にも展開しています。
通常、サービスを海外展開する時に障害となるのは言語なのですが、ある国だけは、言語をクリアしただけではまだ不十分なのです。
その国とは、お隣の大国『中国』で、そこにはどうも『通信の壁』というものが存在するととかしないとか…
中国では政府によるネット検閲があり、日本からインターネットを経由して、中国国内のサイトを参照すると、場合によっては下記のような状態になってしまうという記事を目にした方もいらっしゃるかもしれません。
- つながらなくなる
- 全然別のところに案内される
- おそーくなる
なんとかサービスを構築できたとしても、突然何らかの理由で検閲に引っかかってしまって、せっかくの準備が水の泡となってしまうのは困りますよね。
もし、この壁が実際に存在するのならば、「安定して遅延のない常時接続できるサービスをお客様に提供する」ことを実現するにあたり、この壁と上手に付き合う手段はないのだろうか？と考えたことが検証のきっかけでした。
＊＊＊ 補足 ＊＊＊
ちなみに、今回取り上げた中国の、さらにその北にあるロシアでは、インターネット上で他国のシステムに依存しない独自のネットワークを構築する方法を検証しているようです。
ロシア、インターネットからの自国切り離し実験に成功
https://japan.cnet.com/article/35147348/?tag=nl
ロシアとの通信を完全に切り離されてしまったら、もはや、我々にできることは何もないのかもしれません。
また、通信のフィールドは地球上に限られたことではなく、宇宙での覇権を各国が競っている現状もあります。
https://www.nhk.or.jp/kaisetsu-blog/900/367460.html
今回の検証によって、何かを得られたとしても、その有効期限は案外短いのかもしれませんが、意味が大いにあるので、検証してみました！
「日中ネットワーク検証」を行なった目的
では、あらためて、今回「日中ネットワーク検証」を行った目的を説明させていただきます。
現在、弊社サービスは図１に示すように、日本だけでなく海外にも展開しており、各サービスは日本に置かれた共通のAPIを呼び出して、日本に置かれたデータベースに接続しています。
しかし、中国に関してはまったく別のシステム構成です。
ほぼすべてのデータを中国国内に保持し、完全に独立したものとなっているのです。
このような構成になってしまっている要因の１つとして、前述した「通信の壁」があります。
異なる二つの管理対象があるよりは、これらを一つにまとめられたほうが、よっぽど効率がいいであろうことは容易に予想できると思います。
そこで理想とするのが、図２に示すものです。
この理想を実現するために、「通信の壁」の影響をなるべく受けない方法を探ってみました。
実際にテストしてみた①
ということで、実際に検証してみました。
検証を行うに際し注目したのが、Alibaba Cloudの「Express Connect」というサービスです。
これは日本で流行っているAWSのDirect Connectに似ているもので 、異なる場所を専用線で結び、プライベート接続を確立することができるサービスです。
この「Express Connect」を使うことで、安定して遅延のない常時接続できるサービスをお客様に提供することができたらいいな、と思ったのでした。
実際にAlibaba Cloudの中国版と日本版を用意し、二つを専用線「Express Connect」でつないで通信させてみました。
また、下記を同時計測することで三者比較も行いました。
A) 日本国内同士の通信
B) Express Connect
C) 日中間の通常インターネット
通信方法には下記を使用し、双方に、相手にレスポンスを返却できるような簡易サーバを用意して一週間ほど通信させ続けてみました。
・ping
・Apache Bench
※Apache Benchとは…
Apacheで標準に付いているWEBサーバの性能を計測するためのコマンドで「ab（Apache Bench）」と呼ばれたりします。
Apacheがインストールされていれば使えるもので、WindowsでもXAMPPをインストールすれば使えます。
シンプルなので学習コストが少なく、複雑なテストシナリオを用意する必要がありません。
通信だけに着目したテストを実施する際は、とても便利なツールだと思います。
テスト結果①
一週間ひたすら
・ping
・Apache Bench
し続けてみました。
また、ちょうどその期間中、中国国内での年に一度のある大きなイベントと重なるタイミングがありました。そんな日に、ひょっとして、ネットワーク障害が起きてしまわないだろうか？ということも同時に検証することができました 。
結果は、図４の通りです。
この結果から、日中間の接続において、クラウド型の専用線が通常のinternet回線よりも速くて安定していること、また、特別な日による影響もないことが分かりました。
しかし、日本国内同士の接続に比べ10倍遅く、速度のばらつきがあるという結果でした。
ただ、そこは、国際回線なので、仕方ないですね…
考察
この結果だけ見ると、我々が理想とするシステム構成は難しいのだろうか？と意気消沈してしまいそうになりましたが、
「はたして、今回のテスト結果が国内通信に比べて10倍遅かったことが、中国国内のユーザにとっても10倍遅いと感じさせるのだろうか？」
という疑問も同時に湧いてきました。
そもそもユーザーが求める速さとは何なのか？ということを考えた時、指標の1つとしてGoogleが提唱している最適化の基準「RAIL」というものがあります。
参照） https://developers.google.com/web/fundamentals/performance/rail
このRAILには下記のようなことが書いてあります。
- 応答が瞬時に返ってきたと感じられるのは0.1秒まで。
- 思考の流れが妨げられないのは1秒まで。
- 注意力を保てる限界は10秒まで。
- 人間がスムーズと感じられる動きは60fps
日本国内同士の接続に比較して遅い回線であったとしても、RAILの基準をクリアできる手段はないのだろうか？ということで、
- ブラウザでのJavaScriptの読み込みタイミング
- ローディング画像をうまく使う。
- 画像ロードの優先度を操作する
などのことを試行錯誤してみましたが…これといった解決策を見いだせないままでした。
しかし、通信の結果だけを見て憂いてるぐらいならば、対象とするWebサービスを実際に中国Alibabaに配置してどんな操作感なのかを見てみたほうが手っ取り早いのでは？という考えに至りました。
ということで、実際にやってみました。
実際にテストしてみた②
前述の通り、中国Alibabaに弊社Webサービスのコピーを配置して、また速度を比較してみました。
A) 日中間の通常インターネット（中国Webサービスと日本のAPIは、専用線：CENを使用※）
B) 中国国内からWebサービス接続（中国Webサービスと日本のAPIは、専用線：CENを使用※）
C) 日本国内同士の通信
※二回目のテスト時には、Express Connectに代わるCloud Enterprise Networkという別の専用線サービスができていたので、そちらを使用しました。
https://jp.alibabacloud.com/help/doc-detail/59870.htm
テスト結果②
実際に速度を比較してみた結果、A)がC)に比べて若干遅いとはいえ、ストレスなく通信を行える速度となりました。
そこで、間に通常の日中インターネット回線を介しているA)よりも条件がいいはずのB)の検証結果にかなり期待したのですが、予想に反してものすごく遅い！という残念な結果に終わりました…。
この結果にがっかりしながらも、僕は思い出したのです。
中国とGoogleの間には、どうやら気まずい空気が流れているということを…
https://www.nhk.or.jp/bunken/summary/research/focus/309.html
そこで、念のため、弊社Webサービスを見直してみると、Googleのサービスを呼んでおりました。
そして、Google Chromeの開発者ツールで個々の通信時間を調べたところ、予想的中！
Googleの特定ツール、さらには、Twitter等のSNSツールの通信が、日本国内の通信に比べて、絶望的に遅いのです。
そこで、ソース上からGoogleやTwitterと書かれた箇所をすべて取り除いてみた結果、B)でもストレスフリーな動きを確認することができました。
やはりサービス丸ごと置いてみるとわかりやすいですね。
もし、pingやApache Benchだけで日本国内と同等速度を確認できていたら、そこで「検証OK→問題なし」というシンプルな判断に至ってしまっていたでしょう。
実験開始当初はとてもじゃないけど使えない・・・と判断しかかってしまいましたが、一度目にうまくいかなかったおかげで第二段階の検証にたどり着き、その結果事前に問題点を認識することができたので、結果的によかったなと思います。
まとめ＆今後の課題
結論。我々が理想とするシステム構成の実現は可能と判断することができました。
これからその理想構成を準備することになっていくと思います。
ということで、晴れてハッピーエンド！
いざ、中国に乗り込んで、現地のエンジニアと一緒に開発を進めていこうかという段階にきて、あいつがやってきました。
新型コロナウイルス（COVID-19）です。
世界中では、外出禁止等の感染を防ぐ手段がとられており、出張もNGとなってしまいました。
現地のエンジニアとの交流や、おいしい中華料理がおあずけになってしまったのは残念ですが、遠隔でいろいろと進めていくことになるでしょうか。
＊＊＊ 補足 ＊＊＊
ちなみに、中国国内での年に一度のある大きなイベントの日、専用線を使った我々の検証は影響をうけませんでしたが、
通常インターネットでは、イベント前日から、WeChat、QQ、Alipayなど、有名なチャットAPPで、ユーザのニックネーム、顔アイコンなど、ユーザを特定できる個人情報が一時的に変更不可となっていました。
画面上では、システムメンテナンス 表示。
なお、別のイベントの時にも、同じ現象が発生したそうです。
＊
GMOリサーチでは、WEBエンジニア（サーバーサイド、インフラ、フロントエンド）を随時募集しております。
興味のある方は、ぜひこちらからご応募ください！
詳しい募集要項など採用情報はこちら
