PyCon JP 2016 にダイヤモンドスポンサーとして参加してきました。
はじめまして、株式会社フンザの尾関と申します。
普段はチケットキャンプのサーバサイドをPython/Djangoで開発しています。
趣味はドローンでの空撮です。
エンジニアブログですが、技術的な話は特にありません。すみません。
9/21, 9/22の2日間、PyCon JP 2016という日本最大のPythonistaが集うカンファレンスに参加してきました。
当社では創業時からチケットキャンプのサーバサイドをDjangoで開発しており、我々のビジネスができているのも全てPythonという存在のおかげ！という思いもありまして、その恩返しとしてダイヤモンドスポンサーとして出資させていただきました。
個人的には、2013年と2015年に一般で参加したので雰囲気は分かっていましたが、今回はスポンサーとしてブースを出す！ということでまた違った視点から参加できました。
もちろん、ブースを出すからには、フンザという会社を知ってもらいたい！チケットキャンプを知ってもらいたい！いい人がいれば採用につなげたい！という目的があり、それを全面に打ち出すブースづくりを心がけました。
↓設営の様子
このあたりは、我々のようにイベント慣れしていない担当者が、初めてブースを出すことになった場合の参考に少しでもなればいいなと思って書いています。
と言っても、我々も反省点だらけでまだまだ改善の余地があるので、来年またスポンサーとして出展できるのであれば、もっと良い形にできるだろうと思っています。
ブースでやったこと
話さなくても事業・社内の様子が分かるように
実際に開発者が使っている32インチ4Kのディスプレイを2台持ってきて、片方はTVCMの動画を流すことで事業の紹介と、もう片方は社内イベント・社内風景などの様子も流して、会社全体の雰囲気が伝わるように心がけました。
けっこう立ち止まって見てくれる方もいらっしゃったり、実際にお話したときに「楽しそうな職場ですね」と言って頂けたりしたのでこれは見る側としても良かったんじゃないかと思いました。
ブースに来てくれた方にプレゼント
これはやっぱりノベルティですね。今回は奮発してTシャツとステッカーを配りました。1日目に配ったものを2日目に着てくれていた方もいて、配っているこちら側も嬉しい気持ちになれました。
さらに、『積極採用中！』と記載された名刺サイズのカードも沿えて配りました。これは『よくある採用のチラシを配っても、正直あまり見られない』と親会社からアドバイスをうけて作りましたが、配る方も配りやすく、もらう方も負担にならないのでかなり良かったんじゃないかと思いました。
実際に渡したデザインがこちらです。必要なメッセージだけに絞っています。
キャラクターで認知してもらう
他の企業を見ていると、特に、モノタロウさんはすごく良く出来ていて、というかモノタロウ侍のマスコットだけで、参加者の心を鷲掴みにしていましたね。やっぱかわいいゆるキャラはみんな好きですよね。
去年のPyConでも人気者でしたし、当然今年もモノタロウ侍が会場に来ることは分かっていたので、我々も負けじとチケットキャンプのマスコットであるチケキャン犬というキャラクターでアピールしました。
モノタロウ侍とのコラボ。チケキャン犬の彼ももちろんエンジニアです。
現在はもう契約上、動画は載せられませんが、、実はこれ、小島瑠璃子さんがCMで実際に着ていた衣装です。なんだか台無しにしてしまった気もするので、ファンから怒られないか心配です。気になる方はググってください
PyConJP2016に参加されている方への印象
ありがたいことにそんなブースに足を止めてくださった方も多く、様々な方とお話させていただきましたが、今年は思った以上に学生さんが多い印象でした。
聞けば、大学の研究で機械学習を使っていて、それをPythonで書いているという方の多いこと多いこと！
去年参加した時も、機械学習系の方が多い印象でしたが、今年はさらに多く、また傾向としては『機械学習』がメインの研究テーマというよりも、何か別の研究テーマがあって、その精度を上げるために機械学習を用いているという方が多く、かなり実用的なところで使われているんだなぁと関心しました（小並感）
一方、アプリケーションエンジニアとしてPythonを使っている企業というのは日本ではまだまだ少ないなぁという印象でした。
弊社の発表
2日目にジョブフェアというセッションがあり、お昼ごはんを食べながら企業の話を聞く機会がありまして、そこで弊社CTOの酒徳もパネルディスカッションに参加しました。
企業のブースで直接話を聞くのは緊張するけど、企業側の話を聞きたいという方にとってはすごくいい機会になりますね。
また、弊社エンジニアの小松もLTに登壇しました。こちらは動画・資料も公開されています。
2日目のLT終了後、プレゼントのコーナーがあり、受け取ると景品がもらえるカラーボールを弊社の小松 チケキャン犬くんが頑張ってたくさん投げていました。受け取れた方、おめでとうございます。
まとめ＆所感
Everyone's different, all are wonderful.「みんなちがって、みんないい」
今年は上記のテーマで開催されたPyConJPでしたが、実際に業務でPythonを使っている身としては、こういうコミュニティを通して知り合いを増やし、楽しく仕事や相談の出来る仲間が増えるといいなと思っていまして、その受け皿としてこのコミュニティはとても居心地がよく、今後もPyConJPに参加していきたいなと思った所存でございます。
最後に
最後まで読んで頂き、ありがとうございました。
もし興味がありましたらご連絡ください！
「プログラミングチャレンジ with モンスターストライク」開催！
※こちらの記事は過去のブログから転載したものです。
はじめまして！XFLAGの中の人こと、ムチフミです。
ムチフミって誰やねん！って。。。皆さんお思いでしょうが、これからXFLAG™ スタジオの活動について、積極的に配信していく案内人の一人です！
どうぞ宜しくお願いいたしますmm
さて、先日、小学４～６年生を対象とした、「プログラミングチャレンジ with モンスターストライク」を株式会社ミクシィの本社オフィスにて開催いたしました！
2020年から小学校でも必修化が検討されているプログラミングですが、このイベントは、CA Tech Kids社が運営しているプログラミングスクール「Tech Kids School」の講師と、モンスターストライクを開発しているXFLAG スタジオのエンジニアたちが協力し、実際にモンスターの動きや画面をプログラミングで再現するといったワークショップです！
当日は、たくさんのご応募から当選された子供たち約30名が参加してくれたのですが、なんと、遠くは山形から来てくれた参加者も！入口に貼られたポスター （縦 約1.5メートル、横 約4メートルの特大ポスター！）に興奮しながら、目を輝かせて会場に入ってきてくれた様子がとても印象的でした。
人気投票ベスト3のモンスターがラインナップ！
会場に流れていたBGMが止まり、子供たちもいよいよか！と気合い十分。
まずは"ウエンツ校長"とXFLAG スタジオのエンジニア "けちゃらさん"から開校の挨拶！
そして、待ちに待った開発タイムがスタート！
この日、使用された開発ツールは、モンスターストライクの開発現場でも使用されている「Xcode」。
子供たちにはこの日限定の"秘伝の書"が配られ、実際のエンジニアさながら、開発が始まっていきました！
ワークショップでは、実際にモンスターストライクを開発しているエンジニアたちの仕事紹介も行いました。
スクリーンに映し出されるスタジオの様子に、子供たちからは大きな歓声が♪
また、応募時に寄せられていた 「どうしたらゲーム開発者になれますか？」など、それぞれの質問に対する回答にみんなが聞き入っている様子は、子供たちがこれからの未来を思い描いている様子を実感できる瞬間でした☆
ワークショップが進むにつれ、ボールを動かしたり当てたりするだけでなく、BGMをつけたり、ステージの背景を設定したり、はたまた好きなキャラ絵やボール絵を設定できたり。このような色んなアレンジプログラミングも用意していたのですが、なんと中には時間内に全てのプログラミングを実行できたお子さんも！ （最近の小学生の技術には脱帽です！）
その後は体験会が始まり、それぞれのお友達がプログラミングした作品を試しあい、会場は大賑わい♪
今回のイベントを通して、子供たちが普段何気なく遊んでいる 「モンスターストライク」をさらに好きになってくれたり、そして、ぼんやり描いていた将来の夢が少しでも具体的にイメージできるようになってくれていたら、とっても嬉しいです！
M@c Proをラックマウントしたお話
※こちらの記事は過去のブログから転載したものです。
こんにちは。XFLAG™ スタジオの三沢です。
普段はデータセンターに籠ってあんな事やこんな事をして汗水流しております。
弊社ではiOSのビルド環境をM@c miniやM@c Proを使い構築しています。
美しいですねー。
今回は弊社でのM@c Proのラックマウント方法をご紹介しようと思います。
ラックマウント方法を検討してみよう
データセンターでは19インチの標準的なラックを利用しております。
探してみると19インチラックで使えるM@c Pro用のマウントキットが幾つか市販されているようです。
SONNET RackMac Proや、 H-Squared MP Rackなどがありました。
ラックへの搭載効率を考えると4U2台搭載のRackMac Proより、6U6台搭載のMP Rackのようなタイプの方が良さそうです。
当初、ラックマウントキットを購入し搭載する方向で考えていましたが、
残念ながら弊社と取引のある代理店などでの取り扱いが無く、MP Rackを模して自作しようかなと考えました。
が、上司より、
「自作するならそのままぽいっと置いとけばいいんじゃね？ 」
とのお言葉を頂いたため、
じゃあぽいっと置いて紐で縛って置こうかー
という方向になりました。
ラックにマウントしてみよう
と言うことで、
縛って。
縛って縛って。
ラックに棚板付けて、置きましたっ！
おっと、順序を間違えて先に縛ってしまいました。てへ('e')
美しいM@c Proが縛られる事により更に美しくなりましたね。
底面に耐震マットを貼り棚板に乗せています。
耐震マットはなかなか強力で、結構な力が掛からないと倒れたりする事はなさそうです。
更に進化
あ、耐震より免震のが良いんじゃあ？
M@c Proの免震？ラッキングを考案。
免震になっているかは微妙です。。。
だが美しい。
最終形態
即席なので紐の耐久性など不安があるため、最終的にはこんな感じになりました。
念のため転倒の可能性を考慮し上部を紐で吊っています。
M@c Proを立てて6U+棚板×2枚で2Uの8Uのスペースに6台のM@c Proが搭載できる仕様です。棚板を使っている分MP Rackには劣りますが、RackMac Proよりは効率的にラックを使えそうです。
※写真ではM@c Proと上部の棚板との間隔を空けていますが詰めれば、、、
まぁ、どんなに美しくセットしても。
暖気の回り込みを防ぐためにフロントパネルを付けてしまうので、見えなくなってしまうのですけどね、、、残念。
まとめ
さて、如何でしたでしょうか。
今回はできませんでしたが、今後エアフローの効率を上げる工夫などしたいなと考えております。M@c Proのラックマウント方法を検討中や、マウントキット買う予算無いよ、という方々の参考になりましたら幸いです。さらなるスタイリッシュなマウント方法などを考案されたら教えて頂けると嬉しいです。
次回は、紐技術の習得についてお話したいと思います。お楽しみに。
※なお、今回使用した紐は自前です('e')
スマートフォンゲームのチート事情（@ITセキュリティセミナー）
※こちらの記事は過去のブログから転載したものです。
こんにちは。セキュリティ室の亀山です。普段仕事では情報セキュリティ周りの診断や情報展開などしております。セキュリティからもひとつネタを投稿したいと思います。
先月になりますが、2016年2月26日にアイティメディア@IT編集部主催の@ITセキュリティセミナーに登壇させて頂きました。
内容はタイトルの通りですが、セミナーのサブタイトルにあるようダークサイドの視点を意識したものになっています。 前半は事例の動画も交えてチートのリアルな現状と手法を説明し、後半は弊社における取組みを紹介しました。
上記は会場の様子です。機材セッティングの作業員かと思いきやそのまま登壇。
今回のイベントのように「攻撃者の視点」と「被害者の視点」両方にフォーカスするのは、とても大事なことだと思います。守る側は色々な事情や課題を抱えていると思うのですが、この現実と理想のギャップを極力埋めてリスクと折り合いをつけるためには、両方の視点を持ちながらもろもろを考えていくことが必要だと思います。
上記は講演の様子です。なんとも言えない微妙なテンションが読取れます。
講演後は色々な方とご挨拶させて頂き、上流工程へのアプローチの重要性と難しさに共感したという声、踏込んだところまで公開していたことに驚いたといった声を頂きました。共感頂ける部分があったようで、嬉しさと同時に仲間がいるようで励みにもなりました。講演資料については公開する予定はありませんでしたが、せっかくですので動画など一部を除き以下に掲載いたします。
スマートフォンゲームのチート事情 from 直生 亀山
動画が無いとモンスト成分があまり無い資料になりますがご容赦ください...。
@ITレポート
私のつたない発表を美しくまとめて頂きました。ありがとうございます。以下がレポートへのリンクです。
おわりに
セキュリティで名だたる方々に混じり、若干の場違い感もありつつでしたが、スマホゲーム特有のセキュリティの話が出来たのは良かったかなと個人的に感じています。あまり公の話題になることが少ないので、これを機に少しでも業界内での意見交換や情報発信が活発になればいいなと思い馳せている今日この頃です。
以上です。次の機会があるかは分かりませんが、皆様とお会い出来ることを楽しみにしております。
ノハナ開発品質向上合宿を行いました
こんにちは、side_tana です。まずは画像を見ていただきたいのですが、こういった活動を行ってきました。
最高ですね。ノハナでは 3月16日から18日にかけて、湯河原温泉のおんやど恵さんで開発品質向上合宿を行ってきました。
開発品質向上合宿とは
ソフトウェア開発を行う中で様々な課題と向き合う必要があります。例えばテストが薄い箇所の改善や古くなったドキュメントの整理、短期的な課題解決のため少々強引に変更を加えられた箇所の修正といった課題です。しかしながら、これらの課題と並行して日々の運用や機能追加といった業務をこなす必要があり、多くの場合短期的に優先度の高い運用や開発業務が優先されることになります。その結果として、開発に関わる困難に取り組む時間は限られてきます。
そこでノハナでは、エンジニア開発品質向上合宿という形でそれらに集中できる場所と時間をつくってみました。
進行
会社で開発合宿を企画するのは意外と労力がかかります。企画における労力を圧縮するため、今回は
- ミーティングはキックオフと合宿後の振り返りのみ
- あとはSlack中心に進め、決まったことをtrelloでカードにし、担当者をアサインする
といったアプローチをとりました。とはいえ宿や施設の調整・経路の確保など、事前の作業が多いものは負荷が高くなりがちなので、そのあたりは今後改善が必要といえます。
宿決め
いくつかの宿をリストアップし検討したのですが、今回はおんやど恵さんを利用させていただきました。ポイントとしては
- 開発合宿プランがある
- 無線LANが利用できる
- 机と椅子が利用できる
- 座敷での長時間作業は結構つらい
- 温泉が深夜まで利用できる
といったところになります。コンビニまでの距離（徒歩15分弱）が少し気にかかったのですが、おんやど恵さんの食事が非常に豪華だったため、間食などのためコンビニに行くということはほとんどなく、問題にはなりませんでした。
様子
初日は新宿駅に集合
ロマンスカーで小田原まで移動中の様子
宿へ到着
作業スペースとしてお借りした会議室はこんな感じ
初日の夕食（これでも一部です！）
二日目の夜は懇親会をしました。エンジニアの懇親会ですからやることといったらLTです。
最終日はチェックアウト後、小田原駅まで戻り貸し会議室で作業を続けました。
まとめ
日々の業務から離れ、割り込み作業の発生しにくい環境をつくることにより、
- リファクタリング
- テストの拡充・CIの追加
- 開発ツールの更新とそれに合わせた社内ライブラリのメンテ
- ドキュメント整理
といった作業に集中して取り組むことができ、当初の目標だった「開発品質の向上」「継続的に改善をしていくための土台作り」に対して一定の成果を得ることができました！
おわりに
合宿での思い出はフォトブックに！
ノハナでは一組でも多くの家族に笑顔を届けるために困難に立ち向かうエンジニアを募集しています！
Android・iOSエンジニア【Android・iOSエンジニア】さらなる飛躍のための自社サービスのグロースハック、新規事業の創造に興味あるスマホアプリエンジニア募集!!
モンストのIPv6対応
※こちらの記事は過去のブログから転載したものです。
こんにちは。XFLAG™ スタジオの中野です。普段はモンストのクライアントサイドの開発をしています。今回はモンストをIPv6（NAT64+DNS64）ネットワークに対応させた話をしようと思います。
iOS9のアプリからIPv6（NAT64+DNS64）ネットワークで動作することを求められるようになりました。
モンスターストライクもVer5.5からNAT64+DNS64環境に対応しています。
このエントリではモンストのIPv6対応で苦労した点などを書いてみようと思います。
モンストIPv6対応の課題
モンストをNAT64+DNS64環境で動作させるために解決するべき課題はいくつかありましたが、最大の課題がマルチプレイでした。
モンストはインターネット上に配置したTURNサーバーとTURNプロトコル（RFC 5766）で通信することで、リアルタイムのマルチプレイを実現しています。
しかし RFC 5766はIPv4を前提とするプロトコルなので、IPv6に対応させるためには工夫する必要があります。
TURNをIPv6に対応させる方法
TURNをIPv6に対応させる方法は大きく分けて2つ考えられます。TURNサーバーに直接グローバルIPv6アドレスを付与するか、IPv4アドレスのみ付与してNAT64+DNS64を使うか、です。
TURNサーバーにIPv6アドレスを付与する方法（RFC 6156を使う）
TURNサーバーにIPv4とv6双方のアドレスを付与して、クライアントから TURN Extension for IPv6（RFC 6156）を使って通信する方法です。
この方法には、RFCに沿った実装で実現でき、NAT64+DNS64のないIPv6の環境でもマルチプレイが行えるというメリットがあります。
しかし IPv4/v6 の双方を付与したサーバーをどうやって大量に確保するか？が問題になりました。
現在モンストではTURNサーバーをクラウド上に配置していますが、サーバーにグローバルIPv6アドレスを付与できるクラウドプロバイダは多くありません。
サーバーにグローバルIPアドレスを付与するために、
- TURNサーバーをデータセンターに配置する
- グローバルIPv6アドレスをサポートしているクラウドプロバイダを使う
などの選択肢もありますが、モンストは海外展開も行っており、これらの方法が海外で使えない可能性もあるため、今回は別の方法を使うことにしました。
TURNサーバーにIPv4アドレスとドメイン名を付与する方法（NAT64+DNS64を使う）
TURNサーバーにIPv4アドレスとドメイン名を付与して、クライアントからドメイン名を使って通信する方法です。
DNS64がある環境で名前解決を行うと、IPv4のAレコードしか存在しないドメイン名でもNAT64 IPv6アドレスを返してくれます。
クライアントはNAT64 IPv6アドレスにconnect(2) して通信すれば、NAT64がパケットを変換してIPv4のサーバーに運んでくれます。
しかし TURNはIPアドレスでリレー先ポートを管理するプロトコルです。この方法に対応するには TURNサーバーかクライアントを拡張し、ドメイン名でリレー先ポートを管理するように変更する必要があります。
一方で、グローバルIPv4アドレスが付与されたサーバーとDNSサーバーがあれば環境を構築できるため、データセンターや特定のクラウドプロバイダにロックインされることがなくなります。
今回はインフラ構成の自由度を重視して、こちらの方法を採用しました。
実装
リレー先ポートはIPv4アドレスのまま管理して、クライアントがTURNサーバーに接続する直前（socket(2)でソケットを開く直前）に以下の変換を行い、IPv6アドレスを得る方針で実装しました。
- IPv4アドレスを特定のルールでドメイン名に変換（たとえば、 192.0.2.1 を 192-0-2-1.example に変換）
- ドメイン名をgetaddrinfo(3)で名前解決してIPv4/v6アドレスを得る
- IPv6アドレスが得られた場合はv6に、得られなかった場合はv4に接続
iOS 9.2 以降であれば、ドメイン名を経由せずに getaddrinfo(3) だけで IPv4 から NAT64 IPv6 アドレスに変換できるのですが、iOS 9.1 以下とAndroidに対応するために、必ずドメイン名を経由するようにしています。
実際のコードは以下のようになります（エラー処理は省略しています）。
struct sockaddr_in sin4; // 変換するIPv4アドレス
// 1) IPv4アドレス => ドメイン名に変換
unsigned char ip[4] = {0};
memcpy(ip, &sin4.sin_addr, sizeof(ip));
char domain[256] = {0};
snprintf(domain, sizeof(domain), "%d-%d-%d-%d.example", ip[0], ip[1], ip[2], ip[3]);
// 2) ドメイン名を名前解決してIPv4/v6アドレスを得る
struct addrinfo hints;
struct addrinfo *addrlist;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
getaddrinfo(domain, NULL, &hints, &addrlist);
for (struct addrinfo *addr = addrlist; addr != NULL; addr = addr->ai_next) {
if (addr->ai_family == AF_INET6) {
// IPv6を取れた場合はNAT64環境下にいる
// 3) IPv6接続処理
} else if (addr->ai_family == AF_INET) {
// 3) IPv4接続処理
}
}
// Android 5.1より前のlibcでは freeaddrinfo(NULL) がクラッシュするので
// NULL チェックが必要
// ref: https://code.google.com/p/android/issues/detail?id=13228
if (addrlist != NULL) {
freeaddrinfo(addrlist);
}
検証には社内のNAT64/DNS64環境のネットワークを使いました。このネットワークのおかげで開発時、QA時の環境セットアップの手間が省けて大助かりでした！
まとめ
モンストのIPv6対応話でした。NAT64+DNS64のおかげで、モンストは IPv4端末とIPv6端末間でのマルチプレイも可能になっています。よろしければお試しください！
拠点冗長した話（内部トラフィックボリューム編）
※こちらの記事は過去のブログから転載したものです。
こんにちは。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情報を見て処理できるとかっこいいのですが、インフラとサービスを一緒に運用している会社なので、このまま密な連結で今のところは良いかなぁと思っています。
現在も内部トラフィックの傾向を見ながら増強を検討しています。
次回以降では予算を抑えるためにクラウドを使う話と実際の網設計の話ができればと思います。
