【39】スケールアウトせよ

　皆さんもネットワークシステム設計が原因と思われるオンラインゲームのトラブルを経験したことがあるでしょう。開発者として、これを避けるにはどうしたら良いでしょうか。例えばゲーム内イベントの時には接続数が通常の 1.5 倍、パッチ公開時は通信量が通常の 10 倍となることがあります。これに対して何らかの対策を講じておかなければなりません。一つの解はサーバ規模を柔軟に増減できるようにしておくことです。

　増減する方法として、個々の機器の性能を上げることをスケールアップ、台数を増やして対応できるようにすることをスケールアウトと呼びます。前者は実現が容易ですが、高性能機に置き換える方法なので、一般的にコストパフォーマンスが悪くなります。また、機器の準備に数ヶ月かかったり、その後使わなくなった時の維持コストも問題になります。後者はシステム的に可能なように設計しなければなりませんが、コストパフォーマンス良く大きな性能アップが見込めます。

クラウドを使う

　スケールアウトを効果的に利用するには、そもそも機器を柔軟に増減できなければなりません。クラウドを使うと、必要なサーバ数を短時間で用意できて、必要な時間だけ使用できるというメリットがあります。

　次に負荷分散や並列処理機能を実現します。Web サーバをノードとして構築する場合は、汎用的なロードバランサーが利用できます。それ以外では別の手段でどうにかしなければなりません。データベースはボトルネックになりがちなので、レプリカや分散データベース、分散 KVS（Key-ValueStore）を利用します。ここで使用されている分散技術は難しいものばかりですが、理解する価値があります。これらを応用してゲームサーバの分散化を実現しましょう。技術者にとってここら辺が一番楽しいところです。

ボトルネックを把握せよ

　スケールアウトできる土台が出来ました。さて、このシステムはどこまでスケールするでしょうか？ まず、システムのボトルネックを把握する必要があります。

　回線、ファイアウォール、ロードバランサー、フロントサーバ、データベースサーバなど、それぞれ 1 台当たりの性能、複数台用意したときの性能を調べます。性能測定には負荷テストツールを使用します。HTTP などの汎用プロトコルの場合は汎用ツールが利用できて、独自プロトコルの場合は自作します。ゲームでは独自プロトコルを用いがちですが、このような面からは汎用プロトコルを使用する方が得策です。別の事例のノウハウも活かしやすいです。

　スケールアウトといえども排他処理やキューの関係で、性能向上はいずれどこかで頭打ちになります。性能測定の結果、現実的な範囲外の負荷で起こりうるボトルネックの予兆を発見した場合、その起こりうる可能性と対策を検討しておくのが良いでしょう。このボトルネックの予兆に目星を付けておけるかどうかが、おそらく成否の分かれ道です。

最近のトレンド

　以前は、データベースアクセスにおけるディスク I/O がボトルネックになったのですが、最近はデータ転送量が 10Gbps 級まで増えて、ネットワーク I/O ボトルネックになる場合があります。また、一カ所のデータセンターやクラウドだけで運用すると、品質や性能、サービス継続性に関するリスクがあるので、複数カ所で運用できるようにする仕組みが必要となるでしょう。このインタークラウド環境を構築するには、まずデータの置き場所や一貫性が問題となります。

　さて、少し視点を変えて、皆さんの普段の仕事はスケールアウトできますか？ 自分を成長させるのがスケールアップ、作業分担するのがスケールアウトです。普段の仕事をスケールアウトさせるためには、その仕事を出来る人を増やすことが必要です。社内勉強会などを活用して是非スケールアウトしてみましょう。