中国国内へのファイル転送をAlibaba Cloud環境でテストしてみた(前編)
- 中国へのファイル転送
大容量ファイル転送速度の計測環境を構築しました(前編)
中国本土へのファイル転送に関する課題
当社は1999年に創業以来デジタルファイルトランスポーターを標榜し世界各地へのデジタルファイルの転送事業を中心に事業展開を行っています。当時はインターネット回線もADSLが主流の時代で、当社自身で日米間のバックボーンを保有しラストワンマイルの回線にはフレームリレーやATM、ISDNを束ねた回線からスタートしました。その後も広域イーサーなど比較的品質の高いネットワークで構成したサービスを日本、米国、EU諸国を中心に提供してきました。
その後、インターネットの高速化に伴いこれらのネットワークの構成がインターネットへと移行することになるのですが、同時に回線コストの低価格化から徐々に製造業のお客様中心に中国・ASEAN地区に対するファイルの伝送ニーズが高まってきたのです。
現状、当社の主力サービスであるオンラインストレージサービスGigaCCでは2012年に香港ゲートウェイをリリース、翌年にはASEAN地域からのアクセス改善のため、アジアンゲートウェイの名称でサービスを拡張しました。
中国本土からのアクセスは改善しましたが、さらに大容量なデータを送る場合に、中国内の地域によってはやはり時間がかかるという事象があるのは避けて通れない状況です。
日本と中国とのファイル転送速度が出ない問題には、いわゆるグレートファイアウォールの影響が指摘されています。経験上中国の重要イベントの時期や政治的なインシデント発生時にはインターネットの速度が絞られる場合があるようです。過去にお客様からファイルが届かないとの問い合わせがあり、ご依頼を受けて弊社で調査したことがあります。当時弊社が提供していたInternet Gatewayサーバの経路上のAS(インターネット上の同一ルーティングポリシを一塊にしたネットワーク)が米国のニュースサイトと同一であったため一時的なアクセス制御を受けた可能性が高いとの報告が技術担当者からありました。その時期の米国のニュースサイトでは中国に関連する記事が話題になっていたこともあり影響を受けた様です。さすがに現在はもっときめ細やかな制御がされているのではないかと期待しています。
今回実施したテストは当社の高速ファイル転送サービス「DIRECT!EXTREME」を使って日本から中国に向けたファイル転送の速度を計測してみたものです。
もちろん日本中国間の専用のバックボーン回線を利用してこれらの影響を受けづらい環境を自社拠点間で構築し運用することは可能ですが、大容量ファイル転送に利用できるバックボーンは非常に高額で、お客様にファイルを運ぶ対価としてお支払いいただける料金を超えてしまうことから、今回はあくまで通常のインターネットの回線を前提として、どこまで改善できるかについて検討するべきと考えました。
DIRECT!EXTREMEの3つの通信モードで比較
DIRECT!EXTREMEはファイルの送信方式(プロトコル)として「TCP/UDP/TCPマルチセッション」の3種類をサポートしています。現在の主な活用事例としてはアニメやテレビドラマのコンテンツや音楽のマスタリングデータの輸出入など、1ファイルが数GBから数百GBに上る大容量のデータを長距離の拠点間で転送する業務によく使われています。特に高速モードと呼ばれるUDPとTCPマルチセッションという送信方式では、長距離または通信品質の低い環境での高速ファイル転送が可能です。そこで通信環境が不安定な日本―中国間でのファイル転送を、高速モードと通常モード(TCPプロトコルでの通信で一般的なブラウザから送る方式)について比較することにしました。
少し技術的な話になりますが、ファイルを遠隔地に運ぼうとした場合、ネットワーク帯域が十分確保されていたとしても、通常のブラウザやFTPから送る場合非常に時間がかかってしまうという現実があります。(https://www.directextreme.com/service/detail.html)
中国の場合にはこれに加えてグレートファイアウォールの影響が入るということです。
一般的にはUDPモードの場合はネットワークの遅延などの影響はほとんど受けず、TCPマルチセッションモードの場合でも100msec程度の遅延までであれば通常より高速にファイルを転送することが可能になります。ネットワークの遅延はネットワーク上の物理距離により増大しますが、おおむね100~150msecはASEAN地区のサーバにアクセスした際の遅延幅と同じになります。通常で考えればかなりの高速化が期待できるのですが、果たしてグレートファイアウォール越しの場合はどのような結果になるのでしょうか。
テスト構成
今回のテスト構成はAZUREの東京リージョンに対して、中国国内の端末からアクセスして、東京の弊社オフィスから中国国内の端末に対して100MBと1GBのファイルを送受信する形で実施することとしました。通信の比較に使うのは弊社の高速ファイル転送サービス「DIRECT!EXTREME」。通常モードと高速モードで比較します。
と、ここで問題になるのは中国国内の端末…。
実は以前にGigaCCのアジアンゲートウェイのテストをグループ会社の現地法人に依頼したところ全く効果が認められないことがありました。よく調べてみたところ、なんと北京の事務所から細い専用線で東京本社を回って東京からインターネットに抜けていたという失敗があったのです。そこで今回は現地プロバイダから直接インターネットに出ている中国の複数の拠点でテストをしようと考えていました。しかし、タイミングが悪いことに今回のコロナ問題で、中国どころか国内の出張もできない状態です。そこでラストワンマイルの現地インターネット環境を通じての確認は断念して、中国国内のクラウドサービス上にPC端末を構築してテストすることにしました。これでも日中間のグレートファイアウォール越しの傾向はつかめます。
次にどの事業者のクラウド上にPCを構築するかですが、当社とお付き合いのあるソフトバンク様にご紹介いただいたSBクラウド様にご相談し、Alibaba Cloudに決定。Alibaba Cloudは中国国内に複数のリージョンを運営していて、複数の地方でのテストを実施したかった当社の要望に応えられるものでした。
これで検証の方向性が決定!
と安堵したところ最後にもう一つ課題が…。
今回の環境構築を担当する当社の技術者が「AZUREは使えるけどAlibabaはやったことない」とのコメント。私が思わず発言した「同じようなものでしょ」の一言に担当者は冷ややかな視線を返しつつ「まあちょっと触ってみます」と。
素人の私は、「きっと大変な作業で時間がかかるのかもしれない」とテストを開始するまでに時間がかかることを覚悟しました。
結果は…似たようなもののだったようで、数日後には申し込みから構築まで終わったとのメール。詳しくは次項Alibaba Cloudのセットアップをご覧下さい。安請け合いはしないけどサクッと作ってくれました。
Alibaba Cloudのセットアップ(テスト担当者のコメント)
1.SBクラウド様が提供しているサイト経由でAlibaba Cloudへログイン
2.Elastic Compute Serviceを選択し、VMを作成
OS:Windows Server 2016※サーバOSのみ提供されているため
サイズ:ecs.sn1.medium
※香港リージョンはecs.sn1.mediumがないためecs.n1.mediumを利用
ネットワーク:グローバルIPは無効
作成したリージョン:上海(Shanghai)、香港(Hong Kong)、北京(Beijing)、青島(Qingdao)、杭州(Hangzhou)
3.Elastic IPの設定
グローバルIPを指定せずにVMを作成した場合、インターネットへ接続できない問題が発生したため急遽Elastic IPを設定した
4.OSの日本語の設定
Alibaba Cloudが提供しているWindows OSは、基本英語であるためOSの言語設定で日本語に変更する必要がある
アリババクラウドの作成時に注意する点
- インターネットに接続されないと、日本語フォントが落とせずOSの言語が英語のままとなります。
- 単独でインターネットを利用するVMを作成する前提である場合、VM作成時にグローバルIPの指定することをお勧めします。
インターネットへの接続は、ECSパブリックIPアドレス、Elastic IP(EIP)、NAT Gateway、またはServer Load Balancer(SLB)サービスを利用する必要があるためです。 - リージョンの切り替えが他のクラウドサービスと異なり、プルダウンで切り替わるため、知らないと戸惑います。
- 複数同じ環境を用意する場合、出来上がったVMをテンプレートとして登録すると、VM作成後の手順が簡略化されますが、同じリージョン内のみで利用可能なため他のリージョンへの利用はテンプレートをコピーする必要があります。