Webアプリで中国市場に対応する方法

中国国内に何もデプロイしなくても、フロントエンドコードを素直に最適化するだけで十分なスタートを切れます。ここでは、Great Firewallに対処するための中国特有の最適化と、すでに馴染みのある標準的な手法を組み合わせて解説します。

遅延の原因を突き止める

Great Firewallは、中国国外の特定ドメインへの中国ユーザーからの通信を、不規則に遅延させたり中断させたりします。特に打撃が大きいのはユーザー生成コンテンツを扱うサイトで、たった一人のユーザーのアップロードがサイト全体に影響することもあります。たとえばImgurの画像1枚の読み込みに60〜90秒かかる場合があります。同様に、SaaSドメイン、特にStripeのようにFirewallから目を付けられがちな大手企業からのJavaScript読み込みは極端に遅くなることがあります。こうした不安定な遅さは、明確に遮断されている場合よりも原因の特定や対処が難しいのが厄介な点です。さらに、ユーザー生成コンテンツを埋め込むこと自体が、自社ドメインをブラックリスト入りさせるリスクにもなります(ユーザー生成コンテンツを直接ホストするのは、さらに悪手です)。

明るい面としては、ブラックリストに載っていないドメインへの中国からのFirewall越しの通信は、概ね問題なく行えます。したがって、自社ドメインが帯域制限を受けていない限り、自社ドメインの十分な速度を活かしてサードパーティ起因の遅延を解消できます(もし制限を受けている場合は、まったく異なる、はるかに困難な解決策が必要になります)。

最初のステップは、ネットワーク呼び出しのパフォーマンスを詳細に計測することです。開発者がパフォーマンスを反復的に分析・改善するうえで最も柔軟なのは、Firefox Dev ToolsやGoogleのHAR Analyzerといった標準的なブラウザ内開発ツールを活用する方法です。ただし、これには中国国内のVMへのアクセスが必要です。代わりに、Webベースのサービスでも必要な情報のほとんどを得られます。WebPageTestは有力な選択肢で、その他のツールはこちらで紹介されています。

リソースは自社で配信する

読み込みが最も遅いサードパーティの画像、JavaScript、CSSを特定したら、それらを自社ドメインから配信するようにします。ファイルを自社の静的サーバーに置くか、サードパーティのソースへのプロキシを設定しましょう(これは、専門のサードパーティサーバーに一部のコンテンツ配信を任せるという、グローバルユーザー向けの一般的なアプローチとは真逆の発想です)。

進めていくうちに、Webアプリが中国ユーザー向けとそれ以外のユーザー向けで異なる機能を持つようになっていくはずです。たとえば、中国国外の決済処理の多くは、それを使えない中国の顧客にとっては無関係です。中国の顧客向けにこれらを除外すれば、無駄なJavaScript読み込みによる遅延を回避できます。そのうえで中国の決済手段を組み込むことになりますが、これには後述する商用Webアプリへの法的制約があるため、別種の取り組みが必要になります。

リソースの読み込みに比べると、サードパーティドメインへのAJAX呼び出しを高速化するのはさらに難しい課題です。これらの呼び出しもプロキシ化することは検討できますが、中間者攻撃に対するセキュリティ制御の関係で容易ではありません。アプリケーションがサードパーティに依存しないほど望ましい、というのが原則です。たとえ外部サービスを使う代わりに自前で作り直すことで開発が遅れたとしても、です。

後回しにしてきた最適化に取り組む

ここまでは中国特有の最適化ですが、標準的なフロントエンド最適化も併せて実施すべきです。速度がすでに十分であれば後回しにしてきたかもしれませんが、リソースの読み込みに不規則に数分かかり得る環境では、Webアプリはどのリソースもレンダリングをブロックしないだけの堅牢性を備えなければなりません。すべてをミニファイし、可能な限りリソースを非同期で読み込み、onLoadイベントの後にロードしてページのレンダリングを止めないようにしましょう。

ここまで対応すれば、中国からも基本的には動作するアプリケーションになり、かなりの所まで対応できます。それでも、普段期待しているような信頼性とスピードは得られず、アクセスはいつ遮断されてもおかしくありません。

続いて、一見お手軽に見えて実はそうではない解決策——中国向けCDN、VPN、香港デプロイ——について触れておきます。

CDNはアクセラレーターであって、トンネルではない

中国向けCDNは、中国国外のサーバーへの中国国内顧客のアクセスを高速化します。ただしこれはあくまでアクセラレーターであって、ファイアウォール越えのトンネルではありません。CDNプロバイダーはライセンスを維持し遮断を回避するためにGreat Firewallと協調する必要があり、同じコンテンツ規制が適用されます。中国向けCDNは、もともと速いサイトをやや速くする程度のもので、前述したような最大のボトルネックの解消には役立ちません。

さらに、これらのCDNはフロントエンドからサードパーティサーバーへのアクセスを制御してくれません。先述したように自社ドメインからリソースを配信していない限り、これがしばしば最大のボトルネックになります。CDNには他にも欠点があります。DNS設定が複雑で、CDNの所有権がしばしば変わるため、APIが不安定になりがちです。

当てにならないトンネリング

VPNはGreat Firewall越えのトンネリング手段の一つです。中国国内では広く使われていますが、違法です。少数の既知ユーザー向けに社内アプリを使えるようにする用途であれば、許容できる解決策かもしれません。しかしWebアプリ提供者としては、アクセスを最大化したいはずで、顧客にVPNの利用を強いるのは避けたいところです。VPNが使える場合でも、Firewallからの干渉や、VPNがネットワーク通信にもう一段重なることによって、トラフィックは直接の非VPNアクセスよりはるかに遅くなることが少なくありません。さらに、当局が特定して遮断することでVPNはいつでも停止する可能性があり、もっと厄介なことに、不規則に低速化されることもあります(Marc Bevand氏は、高度なディープパケット検査のサイドチャネルリークによってVPNが破られた興味深い体験談を紹介しています)。

香港もFirewall外の一拠点に過ぎない

香港でのデプロイは魅力的に映ります。香港は深圳に隣接し中国の管轄下にありながら、ネットワークの自由が保たれています。中国本土では禁止されているGoogleでさえ、香港にデータセンターを構えているほどです。残念ながら、得られる効果は限定的です。Firewallは他の地域と同様、中国本土から香港へのアクセスも依然として遅延・中断させます。中国国外の顧客に近い場所にサーバーを置いてミリ秒を稼ぐのと同じように、香港は中国にいくらか近づけてくれますが、本質的な問題は解決しません。

中国国外でのホスティングでは要件を満たせないなら、中国国内へのデプロイを検討することになります。そのためには、まずライセンス取得のプロセスを開始する必要があります。

Internet Content Provider(ICP)ライセンスには2つのレベルがあります。

• ICP届出(備案/Bei'an):中国国内でWebサイトを公開する前に必須の法的要件です。
• サイトが商用でオンラインサービスを販売している場合、フルICPライセンスが必要です。これは中国資本が過半数を占める企業にのみ取得が認められます。

フルライセンスではなくICP届出のみで進めるのは明らかにかなり制約が大きいのですが、本記事では届出のみが選択肢である前提で解説します。

ここで申し上げておくと、私は技術者であって弁護士ではありませんし、まして中国認可の弁護士でもありません。実行に移す前に必ず詳細を確認してください。法律も現場の実態も常に変化しています。ただし、このプロセスが見た目どおり本当に複雑であることだけは保証できます。

備案を取得する

ICP届出のためには、従業員とオフィスを持つ中国子会社を設立してください。形式上の存在では不十分で、子会社が実在することを証明する審査を通過しなければなりません。具体的には、実際のオフィス内で従業員がクラウドプロバイダー提供のポスターを掲げている写真の提出までが含まれます。その従業員は単なる形式上の存在ではありません——ルールがクラウドデプロイにどう影響するかを深く理解している人材は、極めて大きな資産になります。

これを代行してくれる中国のパートナー企業を探すという選択肢もありますが、執行状況が変動し続けているため、確実な解決策とはいえません。

次に、ICP届出は早めに提出してください。プロセスには数週間かかります。ICP番号が発行されたら、ホームページのフッターに表示する必要があります。

中国で実際に商品を販売したいのであれば、ICP届出だけでは足りません。ICPライセンスが必要であり、しかも会社が中国に登記されているだけでなく、中国資本が過半数を占めている必要があります。

クラウドの選択肢には、Alibaba(Aliyun)やTencentといった中国国内のプロバイダーと、AWSやAzureといった海外クラウドプラットフォームがあります。私が強くおすすめするのはAWS ChinaとAzure Chinaで、慣れ親しんだ一貫性のあるAPIをそのまま利用できます。これらの技術には、世界中のエコシステムが生み出した質の高い英語ドキュメント、記事、トレーニング、StackExchange、フォーラム投稿が揃っています。AlibabaとTencentの英語ドキュメントは、追いつこうとする努力にもかかわらず依然として手薄なままです(実のところ、AWS ChinaとAzure Chinaの中国特有の事項に関するドキュメントや投稿も驚くほど少ないのですが、少なくともAPIまわりについては必要な情報が手に入ります)。

AWSとAzureはAmazonとMicrosoftではない

AWS ChinaはAmazonが所有しているわけではなく、Azure ChinaもMicrosoftが所有しているわけではありません。これらのサービスを運営しているのは中国企業であり、米国企業からは技術がライセンスされているだけです。

これらは別リージョンではなく、たまたま同じ技術を使っている別個のクラウドだと考えるべきです。両者は統合されていません。たとえばAWSでは、中国国内と中国国外で別々のユーザーアイデンティティを作成する必要があります。AMIを中国との間でコピーすることはできず、グローバルDNSを実現するRoute 53も存在せず、リージョン間をPrivate Linkで接続することもできません。

中国クラウドへのサインアップは、はるかに手間がかかります。グローバルなクラウドプロバイダーであれば、通常はクレジットカード番号さえあれば済みます。中国のプロバイダー(AWS ChinaやAzure Chinaも含む)では、ICP届出と中国子会社のライセンスが必要です。さらに、複数の身分証明書の写真や詳細な個人情報を求められる、はるかに厳格な不正対策の「実名登録」要件への対応も必要です。無料枠は非常に限定的か用意されておらず、支払いは前払いです。

中国へのデプロイを構築する過程では、いくつかの技術的な制約に直面することになるはずです。

もたつくデプロイ体験

AWS ChinaとAzure Chinaは、本家プロバイダーの新技術導入から遅れがちです。

そして、クラウドプロバイダーへの登録やVMの削除といった当たり前の操作にすら、慣れているよりはるかに多くの人手によるサポートが必要になることが多く、特に中国独自のクラウドプロバイダーで顕著です。サポートエンジニアはプロフェッショナルですが、英語スキルのレベルは普段慣れているものとは異なります。

GUIコンソールを使った中国国外からのアクセスは、ときどき遅くなることがあります。同様に、開発・デプロイ用の接続が失敗することもあります。Continuous Integrationのプロセスは、中国以外のリージョンに対して実行することを検討してください。

ICP届出なしでは、80番や443番といった一般的なHTTPポートを公開できません。つまり、開発とテストはすべて別のポートで行い、本番環境でのみ標準ポートに切り替える必要があります。

同じ理由で、テストの大部分は現実に近いDNS構成では行えません。テストのためだけに届出を行う価値はないからです。ドメイン(たとえばtest-mycompany.com)もSSL証明書も、ICP届出に基づいて承認されなければなりません。

枯れた技術で万全に備える

明るい面としては、中国と中国国外のサーバー間のネットワーク接続は、通常クラウド内の他の接続と同程度に高速です。最小限の機能セットだけを中国クラウドにデプロイし、中国国外にある本拠地のデプロイメントと連携させましょう。

遮断済みのサービスがかつて使っていたIPアドレスを割り当てられるという不運に見舞われない限り、クラウド間の連携は通常どおり可能です。それでもいつ遅延が発生するか分からないので、それを前提に連携を設計してください。Great Firewallの内側と外側で独立したデータベースを保持し、非同期で同期させましょう。クラウドプロバイダーは、Firewallを回避する直結リンクを使った大容量データの送出サービスを提供しています。ただしこれらは高価で通常用途には不要であり、一般的な非同期アーキテクチャで十分です。

中国のクラウドプラットフォームで何が利用でき、どれが成熟しているかを確認したうえで、枯れた技術でアーキテクチャをシンプルに保ちましょう(中国のプラットフォームは、グローバル版から常に少し遅れて追従しています)。AWSやAzureから複雑なアーキテクチャ全体をリフト&シフトしようとしてはいけません。代わりに、適切に分割されたマイクロサービスアーキテクチャの一部を切り出してください(そういうアーキテクチャがまだないなら、今こそ整える好機です!)。中国でどうしても必要なマイクロサービスのセットだけをデプロイしましょう。中国クラウドの要件に合わせるためにコードをフォークする必要があるかもしれませんが、AWSやAzureから中国版プラットフォームへの移行であれば、変更点はそれほど多くないはずです。