拠点冗長した話（内部トラフィックボリューム編）
※こちらの記事は過去のブログから転載したものです。
こんにちは。XFLAG™ スタジオの吉野です。普段はネットワークの設計・調達・構築・運用、インフラ関連したちょっとした開発やバックオフィス業務をしています。今回は弊社のオンプレ設備を拠点冗長した話をしようと思います。
1年前の2015年2月くらいに拠点の冗長しようかという話がありました。
会社からのやりたいことの要望は大まかに以下の点でした。
- 使ってもらえて動く物を作る
- 早く作る
- サービス影響なしでやる
- 予算の上限はランニング含めて、==秘密==くらい（想像よりは少ないはず）
要求されるスピード感としてはおおよそ以下でした。
- 2015/2にサービスを開発運用しているメンバーとちゃんと運用し続けるために何をどうやるのかを調整すること
- このまとめた結果から2015/3に費用を含め役員の承認を取ること
- 2015/6月末くらいには使えること
2015年2月時点で設備の冗長は最低限で、データセンターの停止等が発生するとサービスに影響が発生する状況でした。
クラウドに接続可能なネットワーク拠点等にMariaDB等のスナップショットとバイナリログを置くことで、問題発生時にはクラウドでサービスを再開する構成を取っていました。震災後から徐々にリスクと普段の消費電力とそれにより発生するコストのバランスを取る形でこの構成に移行していました。
データベースの再構築時間とキャッシュが温まり性能がでるまでの時間とサービスの復旧目標時間から、今回改めてサーバを置くデータセンターを冗長しました。
この記事では、これをやるために最初の設備のサイジング作業を紹介できればと思います。
構成要素とトラフィック量
システムの概要の記事にある構成要素を2つに分類しました。
1つ目は、Application(以前の記事ではAPIとしていた部分）とBatch等のステートレスな使い捨てできるサーバです。
2つ目は、キャッシュ（Memcached）やデータストア（MariaDB,Redis）等のサーバです。
データを持つ部分のトラフィック量を調べる
今回は2015年2月時点での測定結果を記載しています。
トラフィックの測定方法として、単純にサーバnicのIfHCInOctetsとIfHCOutOctetsの値を通信量と近似しています。
監視等の通信やバックアップの転送等いろいろなトラフィックが混ざっていますが、無視します。
モンスターストライクの日本サービスの内部トラフィック量（2015年2月頃）はざっくり以下のとおりです。
ゲーム内イベント等でトラフィック量は上下するので、週単位のトラフィックピークを3週間分集めてそのレンジを書きました。
### MariaDBの通信
- Input 0.8Gbps - 2.4Gbps
- Output 2.0Gbps - 2.8Gbps
この量にはbinlog等の通信も含まれています。
InputにはDBのrestoreが混ざっていますし、Outputにはバックアップの転送が含まれるのでおおよその量です。
### Memcachedの通信
- Input 4.3Gbps - 5.9Gbps
- Output 9.2Gbps - 12.0Gbps
Inputの支配的な部分はsetによるもので、Outputの支配的な部分はgetによるものと考えられます。
### Redisの通信
- Input 0.2Gbps - 0.3Gbps
- Output 0.2Gbps - 0.2Gbps
データセンターを超えてこれらのトラフィックが行き来する場合に、ピークでざっくり15Gbps程度に耐えられる構成を組めばよさそうです。（【追記】で補足しています）
初期ではセンターを超えても20Gbps程度は常に帯域があることを期待できる形でネットワークを組むことにしました。
※【追記】
上記3種類のInputの合計が8.6Gbps、Outputの合計が15Gbpsであり、appサーバが片方に集中している時に、反対のセンターに全てのリクエストが回った時にどのくらい流れるかを計算しています。
物理配置をマッピングすると以下のようになります。
まとめ
普段からサービスの内部トラフィックを把握することで適切なサイジング等ができるためコストの最適化が可能になります。
本当はflow情報を見て処理できるとかっこいいのですが、インフラとサービスを一緒に運用している会社なので、このまま密な連結で今のところは良いかなぁと思っています。
現在も内部トラフィックの傾向を見ながら増強を検討しています。
次回以降では予算を抑えるためにクラウドを使う話と実際の網設計の話ができればと思います。
