#シノアリス の配信日件について

初めに

最近「経験のない人はシノアリスのメンテ状態の話するな」はよくある発言ですね。まずは、私はご覧の経験を持っている：

※AWSの経験は5年ぐらい
※プロジェクト管理の経験はある
※企業とIT関係の経験は10年＋
※5年ぐらいはフォーチュン500会社レベルの客インフラストラクチャをサポーつする仕事

シノアリスインフラの様子

まずはシノアリスアプリはどこに繋がっているのを確認しました。Androidは確認してないが、iOSアプリは「api-sinoalice.pokelabo.jp」と繋がっています。ただこれだけじゃ繋がることは出来ません。DNS検索は必要です。DNSと言うのは基本「api-sinoalice.pokelabo.jp」みたいな名前をIPアドレスに交換するサーバーです。そのDNS検索をしたら：

この情報で分かることはまずゲームのAPIサーバー管理は開発会社Pokelaboがやっています。次はAWSを使っています。で、複数のDNS検索をしたら：

結果のIPアドレスに少し差があります。AWSのRoute53と言うDNSサービスならロードバランシングは可能です。ロードバランシングの基本は複数のサーバーを立って、サーバー負荷によってクライエントに返すサーバーIPは変わります。そしてそのサーバー全ての様子を特定の間隔がたったら確認します。もしサーバー一体の調子が悪かったらクライエントに返すDNSレコードに入れません。このへんはまあ、特に問題ありません。

で、そのIPを一つずつ確認すれば裏のサーバーはEC2で動いているのはわかります：

公式の説明

なお、シノアリスの公式アカウントを確認したところで、この説明が出てきました：

二つの問題は：

• CDNのサーバー負荷
• DBのサーバー負荷

CDNの問題

CDNと言うのは「Content Delivery Network」の略です。このCDNはあんまり変わってないフィアル（画像、音楽等）を素早くクライエントに届くためのサービスです。AWSなら「CloudFront」のCDNサービスがあります。CDNを使用するプロセスなら：

1）　クライエントアプリの初実行は現在のデータを一気にDLする（CDNからZIPファイル等）
2) そのデータをクライエント側で解凍する

で、クライエントはゲーム内で画像とかCDNでありそうなファイルを求める場合はローカルの画像とCDNの画像に差があるかどうかを確認する、またはローカルファイルのみを使用する。

ローカルファイルのみは一番はやいが、その画像を直したい場合は次のアップデートまで更新した前の画像になってしまいます。ローカルとCDNの差を確認するのは一番確実だが、回線の問題でゲームが遅くなってしまう恐れは十分あります。

こう考えるとCDNの問題は少し怪しいです。まあ、公式が詳しくを教えないと分かりませんが。

DBの問題

DBの問題は正直分かりづらいです。AWSならRDSやDynamoDBのDBサービスはあるが、セキュリティーのためにそのサーバーの詳しくをネットから隠すのはよくあることなので、どんなDBサーバーを使っているのは確認出来ません。

なので、問題の原因はこれぐらい予想している：

• アーキテクチャが悪い（AWSのDBサービスでも可能性はある）
• DB関係コードが悪い（一番ありえる）

今の情報だとこれしか分かりませんね。

お前ならどうする

まあ、それは気になる人居ますね。まずはAWSを使っているのでそのへんはあんまり変わりません。

サーバー言語

iOSやAndroidアプリは使用する言語結構限られているのでそのへんもあんまり変わらないと思います。しかし、サーバー言語について私ならマルチスレッドの強い言語を使用します：

• Google Go
• Erlang
• JVM言語（Scala、Clojure、Java等）

CやC++は早いけど、メモリー管理的に少し厳しいかもしれません。

データベース

一番難しいところですね。さすがに全てを一つずつ説明するのは非常に多くの時間が必要なので基本の考えを置いてきます。

まずはよくアクセスされているデータとそこまでアクセスされてないデータをDBサーバーレベルで分けたいです。後、登録済みとそうではないユーザーのデータを更に分けたいです。理由はやはりリセマラのサーバー負荷ですね。それでも配信日は流石にリセマラの人は非常の多いので、とりあえずユーザーデータを数千人ぐらいでパーティションしたいです。それでDBサーバーの拡大は少し楽になります。

テスト

ゲームサーバーの基本機能を確認するインテグレイションテストは欲しいですね。iOSとAndroidのテストフレームワークも使用したいです。何かのバグがあったら、それは二度と起こさないためのリグレッションテストはいいですね。

配信日の前はまずβテストです。βテストは実際にアプリを使ってみないと分からないバグは一部のユーザーが探します。報告されたバグを直しながらアプリのパーフォーマンスをモニターします。これでDBのサーバー負荷になりそうなコードを出来る限り減らせます。

問題の説明

問題を完全に避けるのは不可能です。だが、IT企業では「postmortem（適当な翻訳だと事後検討みたいな感じ）」と言うプロセスがあります。例え：

○：○○　異常なDBサーバー負荷を確認しました
○：○○　メンテナンスに入りました
○：○○　DBログの確認で非常に多いDBクエリーを確認しました
○：○○　DBコードの問題を確認しました
○：○○　DBコードを書き直しました
○：○○　DBサーバーを再起動しました
○：○○　メンテナンス終了

等の具体的なことが書いてあります。なお、殆どはやってみないと分からないので情報が入った次第ドキュメントを更新するのはよくあることです。勿論このドキュメントを更新する人は問題を直している人と違う人物です。

最後に

まあ、私が言いたいのはこれぐらいですね。もう少し詳しい情報が入ったらまとめを更新するが、公式のアカウントはそこまで確認してないので結構時間がかかると思います。