はじめに
こんにちは。CYBIRDエンジニア Advent Calendar 10日目の伊藤です。9日目は@sanjaponさんの今年開催された社内勉強会（インフラ編）でした。若手エンジニアのアニキとして慕われていて、業務の傍ら、いろいろな勉強会を開いてエンジニアの意識を高めてくださっています。いつもありがとうございます。
お詫び
今日のエントリは「痛恨のミス 2016」の予定だったのですが、書いてみたら悲惨すぎて公開できるものではありませんでした（やっぱり。）そこでセーフなタイトルに変えさせていただきます。
「海外へのゲーム配信で注意すること」
自分はスマホ向けゲームスタジオの技術プロデューサーをしています。
今年リリースした某ゲームは日本、香港、欧州、アメリカ、アジアで計31カ国に配信しています。
日本で作ったゲームを外国で配信する場合、ローカライズが取りざたされますが、開発上で注意するべきこともあります。
チェックリストにしてみましたので、これから海外配信するゲームを作る方はご活用ください。
チェックリスト 
a. 通信速度が遅い国対策、レイテンシ対策
(1) 下り1Mbpsでも動くか？
(2) CDNを使っているか？
(3) DNSサーバは分散してるか？
(4) 多重リクエスト対策しているか？
(5) アプリ本体の容量vs差分ダウンロードの容量の配分は、意図的に決めてあるか？
b. チート対策
(中華圏に出す場合は特に)
(1) root化 /Jailbreakチェックしてるか？
(2) 通信のSSL化してるか？
(3) APIに渡すパラメタにはハッシュをつけて突合してるか？
(4) 値の範囲チェックしてるか？
(5) API再送チェックしてるか？
c. そのほか
(1) Google Play developer Consoleでスペックの足りない機種を非対応化してるか？
(2) タブレット対応してるか？
(3) SNSログインできるか？
(4) 35度以下に放熱を抑えてあるか？
(5) タイムゾーンごとにバッチが回る場合、1時間以内で終わるようになってるか？
説明
a. 通信速度が遅い国対策、レイテンシ対策
(1) 下り1Mbpsでも動くか？
キャリア通信速度
| 東京 | ロンドン | 香港 |
|---|---|---|
| 10〜20Mbps | 1〜5Mbps | 1Mbps以下〜20Mbps |
公衆Wi-FI速度
| ロンドン | 香港 |
|---|---|
| 1MBps〜3Mbps | 20〜40Mbps |
出張時、あるいは現地のQA会社にデバッグを依頼したときに、ついでにモバイルデータ通信速度を測ってみたところ、同じ国でもピンキリでした。
いろいろ聞いてみると、スマホゲームを遊んでくださる方は、アプリをダウンロードする時は家や学校とか会社ののWi-FIを使って、出先ではしょうがないから3G(まれに4G)を使うパターンが多いようです。
出先で隙間時間に遊んでもらえるようにするには、「全く通信しないで遊べる」ゲームか、「通信するけど軽い」必要があります。
我々は通信が必要なゲームを作っているので、APIの通信が1Mbps以下でも動く条件を守るようにしました。
(2) CDNを使っているか？
静的ファイル配信はCDNを使うのがセオリーですが、10分の1とかに短縮できるわけではないです。
例）AWS CloudFrontでの、某ゲームのアセットダウンロード時間
| 東京 | ロンドン | エッジが近くに無い国 |
|---|---|---|
| 30秒 | 1分 | 4分 |
ロンドンをはじめ、AWSのCloudFrontエッジロケーションは世界の大都市付近には配置されていますが、大都市だけなので、田舎のほうにも対応したい場合、Akamai CDNを導入すると良いと思います。
(3) DNSサーバは分散してるか？
1画面を表示するために何回もAPIや静的ファイルをリクエストするアプリの場合は、リクエスト毎のURLのドメインの名前解決にかかる時間のチリツモが見過ごせない長さになってしまうでしょう。AkamaiとかAWSを使うと良いと思います。Ddos対策にもなりますし。
(4) 多重リクエスト対策しているか？
回線が不安定だと、上りはいけても下りが切れることがあります。課金やガチャやイベントなど、リトライすると内容が変わってしまう処理は、レスポンス内容をサーバー側で一定時間キャッシュしておき、同じリクエストが来た場合にキャッシュ内容を返却するのが良いと思います。
(5)アプリ本体の容量vs差分ダウンロードの容量の配分は、意図的に決めてあるか？
日本だと、appストアやGooglePlayで配信するアプリ本体は100MB以内を死守して、そこに入りきらない素材を、初回起動時にダウンロードをしている場合が多いと思います。
しかし全く逆の考えの国があります。
・アプリのダウンロード時はどうせWi-Fiを使うのでアプリ本体は100MBを超えても良い.
・逆にWi-Fi圏内にいない時に大量の素材ダウンロードが発生するとユーザー離脱につながる.
・だからアプリ本体に素材を全部含める。ストアからダウンロードしたあとはすぐ遊べて、API通信は電文だけ。
残念ながら、AppストアもGoogle Playも、国によってバイナリを分けられないので、100MB以内死守か全量を含めるか、どっちの方針にするのか決めなければなりません。
収益の主要国を決める戦略に関わります。
開発前に決めてる必要があります。
b. チート対策
一般的な範囲で説明します。
(1) root化 /Jailbreakチェック
・いろいろなチートツールは要root化/JailBreakなので、これらを検知し起動させない。
・新しい手法がでるので定期的にパトロールして対策を追加する必要あり。
・中国語のわかるスタッフがいるとたいへん助かる。
(2)通信をSSL化してるか？
・必須。
(3) APIに渡すパラメタにはハッシュをつけて突合してるか？
・あるいは暗号化でも良いと思います。
(4) 値の範囲チェックしてるか？
・アプリ内でもAPIでも必須。
・上限だけでなく下限チェックも絶対です。
例）課金アイテムのマイナス値リクエストによりアプリ内通貨の保有量を増やされた
(5) API再送チェックしてるか？
・アプリとの通信を傍受して、ガチャが当たったときのリクエストをコピーして鬼のように再送するチート手法がある。多重リクエスト対策をいれる過程で防げる。
c.そのほか
(1) Google Play developer Consoleでスペックの足りない機種を非対応化してるか？
Google Playのカスタマーレビューで、「ダウンロードしたけれども動かないんじゃゴルァ★☆☆☆☆」という低評価を避けるための施策。大変ですが、もしストアのおすすめ枠に掲載された場合、この処置をしておくことにより、レビューの評価レベルを守れる効果があります。
やり方；
apkをGoogle Play Developer Consoleにアップロードすると、ビルド時に指定したAPIレベルに応じて、対応機種が自動的に絞り込まれる。
12/9現在、Google Playの全対応機種は13656機種だが、APIレベル15+のアプリをアップロードすると、自動的に12518機種に絞り込まれる。
↓
絞り込まれた機種を全部調べる。
あるいは工数とのトレードオフで、主要なメーカーだけ対象とし、各メーカーの機種それぞれのスペックをGSM Arenaなどで調べる。
（スクレイピングしたり人海戦術で。）
世界上位１０位メーカーまで調査して非対応化の措置をとれば、安心材料と言えると思います。
http://www.appbrain.com/stats/top-manufacturers
Samsung
LG
Huawei
Lenovo
Motorola
Sony
HTC
Xiaomi
Asus
Oppo
ですね。
↓
世界的にはシェアは低いが配信国ではよく使われる機種も、調査する。フランスに配信するならAlcatel、インドならMicromaxなど。
↓
デベロッパーコンソールで１機種づつ非対応化する。
Google Play Developer Console＞アプリを選択＞APK＞サポート対象の端末数「リストを表示」＞機種名で検索してスライダーをオフにして保存。
数が多いとかなりたいへんです。
私たちのチームでは普段Unityで開発してるイケメンがchrome拡張をつくってくれたので一撃でした。
(2) タブレット対応してるか？
タブレットの普及している国のユーザーにうけが良いです。
Apple /Googleももちろん推奨しており、ストアのおすすめ枠掲載には絶必と言われています。
(3) SNSログインできるか？
機種変更時のデータ引継ぎを「ユーザーID+パスワード」でする仕組みは古くて、
Facebookや iOSのGameCenterなどを使う場合がスタンダードになっています。
パスワード忘れ時へのカスタマーサポートの対応も減らせます。
(4) 35度以下に放熱を抑えてあるか？
「異常な状態は避ける」防衛本能のある国だと、放熱が激しいと遊んでもらえないです。
暑い国の夏の時期でも触りたくないでしょう。笑い事ではなく。
fpsをあげてヌルヌル動かすことを正義にしてると、40度近くになっていることがあります。
充電しながらだとよけい暖まるので、充電してない状態で35度以下を守るべきだと思います。
(5) タイムゾーンごとにバッチが回る場合、1時間以内で終わるようになってるか？
タイムゾーンは30分刻みのもあるので、その場合は30分以内に終わらせる必要があります。
そうでないと次のタイムゾーンの処理と輻輳化してしまうので、太平洋とか大西洋を渡っている間に終わってくれと祈る羽目になります。
だいぶ長くなってしまいましたが、説明は以上です。
最後に
CYBIRD エンジニア Advent Calendar(http://qiita.com/advent-calendar/2016/cybird) 明日は、@cy-kuniyoshi-setoさんの「デザイナーがADVアプリを無理やり作った話」です！ 何をつかってどうやったのか、そして無理やりなのはどういうところが？ たいへん興味ぶかいです。楽しみにお待ちしています！ 