14:20からは、アイレット株式会社のエバンジェリスト、吉田真吾氏が登壇。AWS特化後の成長と、「AWSを活用した経営データの見える化、攻めのビッグデータ活用を進めるべき理由、ビッグデータ活用にどのような課題があり、どう解決すべきなのか」の具体的な事例などを踏まえて解説されました。
アイレット株式会社は、「APN プレミアコンサルティングパートナー」である 「cloudpack」（事業名）を展開する企業。EC2やS3を始め、AWSを利用する際の運用・保守の代行サービスを提供しており、1000台規模のAWSサーバーを運用して20名ほどのエンジニアが監視しています。「APN プレミアコンサルティングパートナー」は、世界中で22社、日本国内では野村総研と「cloudpack」だけが取得しており、その事からも同社の技術力がうかがえます。
クラウドサービスの客層については「中小企業の方が決算が早くて導入は早いと思っていたが、ありがたい事に中小から大企業まで万遍なくスタートしている」との事で、確かに大企業の展開が早いのは意外です。また、事例として金融系のiPhoneアプリや、大阪観光局などの公共系からも引き合いが増えていると吉田氏は述べました。
web系のシステムから、情報系、基幹系と幅広く利用されているCloudpack。「システム別には、webが91％。内33％がソーシャルゲームやメディアサイトで、圧倒的にwebが多い。ソーシャルゲームやメディアサイトのお客様は、AWSの特徴であるアジリティやスケーラビリティと非常に相性がいいので、AWSを積極的に活用している」との事。昨年より引き合いが多くなっている残りの9％は、基幹系が1％で情報系が8％。吉田氏は「今後この二つが延びるのではないか」と語りました。
ビッグデータのビジュアライゼーションに関しては、まず「データを集める、発生源が異なりデータの形式が違ったりするものを、いかに効率よく収集するか？」がネック。これに対応するため、データ収集にはFLYDATAを使用しています。FLYDATAとはシリコンバレーの藤川幸一氏がスタートアップさせたサービスで、エージェントをサーバーにインストールするだけで簡単に導入ができるもの。AWSやその他クラウドの上に入れると、発生源の散在するデータの収集が容易になり、ビッグデータの可視化にもつながります。
また、収集したデータは「誰が、何を、どう見るか？」が大切で、経営者と現場を分けて考える必用がある、と吉田氏。まず、現場には新サービスとして「WADANCE」を発表。これは様々なKPIを提供、コンポーネントも全て一つ一つ設計されたもので、複数の数値を俯瞰できるため、指標全体の数値をカバーしてサマリーを見る事ができるというもの。ものすごく乱暴かつ簡単に言えば「ビッグデータをビジュアル化して、俯瞰して見られる」もので、セッション時には公式サイトもなければアナウンスもなく、当日の朝に会場へ持ってきた、というほど直近の新サービスでした。
続いて、経営者向けの見える化のツールとして「WADANCE」ではデータが多すぎるため、経営の状況をマクロサイズで俯瞰できるサービス「Solid Air」を紹介しました。すでに提供中のものですが、中長期に渡ってビッグデータを可視化して扱えるため、「世界のどこでどんな変異が起きているか」が感覚的に理解できるツールと言えます。
これからの「情報」はビッグデータを活用するためにデータを俯瞰的に眺めて、世界の綻びや隆起のようなものを探る。そのうねりをどれだけ感覚的に掴めるか、それをどれだけ具体的なものに落とし込めるかがポイントになってきそうです。
15:20からは、田沢知志氏（クルーズ株式会社SAP事業本部VENUS&ZEUS部ディレクター）を招き、「全世界配信ネイティブゲームをクラウド(LAMP環境)で運用する際の事例とノウハウ」が詳細な実例を交えて解説されました。
クラウド導入の一般的な考慮点としては、これまでオンプレミスで培ってきたノウハウをベースに、AWSのクラウドで構成。インスタンスはwebとcacheとDB。基本的にはEC2のインスタンスを使用していて、その上にミドルウェアを展開しているとの事。インスタンスタイプは3ヶ月ないし6ヶ月スパンで新しくなるし性能も向上、料金も安くなりコストパフォーマンスは三割増しでの向上を実感しているそう。タイプは定期的に変更し、現時点のインスタンスはweb系だとM3で、m3.xlargeもしくはm3.2xlargeを使用。CacheとDBはメモリが必要になるのでR3のr3.xlargeかr3.2xlargeをメインで使用していました。
ベンチマークにおけるリージョンの選択はUSイーストをメインに、インスタンスは前述のものを使用。重要指標として、DBはストレージIOPS、もしくはqueries/s、Cacheに関してはrequests/sで、webはCPU Load Averageとユーザー使用率を。田沢氏は過去にも自分で行なうベンチマークの大切さを説いていたため、変更がなくとも常にデータ収集を行なうべきなのでしょうね。
CROOZでは、まずインスタンスを一つ作り、webもCacheもDBも水平的にスケールアウトしていくやり方をとっているそう。これは構成済みのイメージ（AMI）から新しいインスタンスを機動していく形で、CacheとDBはアプリケーションに応じ分解していくとの事。まず基本から固めていって、そこから順次拡張させていく方法でした。
次にキャパシティの考慮点。「極端にプログラムが酷くなければCPU負荷はない」としながらも、実際に運用した結果のボトルネックは、CacheとDBのレスポンス遅延がサービスダウンの要因であるとの事。Webに関してはローカルポートの不足が一番のネックで、対策としてローカルポートを増やしたり、tcpのtime_wait数をいかに少なくするか調整したりしているそうです。
コスト問題では、「インフラ部分はいかにコストを下げてパフォーマンスを上げるかが命題です」と田沢氏。氏の示した1インスタンスあたりのMaxDAUを想定したコストの算出方法は次の通り。（参考値） Web（m3.2xlarge）が60,000DAU、DB（r3.2xlarge IOPS4K）が120,000DAU、Cache（r3.large）が180,000DAU（ここから必要インスタンス数を算出し、月額コストを毎月収支予測で出す）。目標は月額売上の3％未満にインフラコストを抑える事。自社の指標を元に費用対効果を計り、適正なコストを洗い出す事が導入のポイントと言えそう。
またリソース配信について「リソースCDNにはCloudFrontを使用。USアジアヨーロッパの各拠点にロケーションがあり、オリジンサーバーはS3に格納しておけばいい。親和性があって運用しやすい。標準でリポート、解析の機能もついているので、リージョン毎のリクエスト数がどれだけあるか、DLのトラフィックが一日単位で見られる。現状、数百TBのDL配信で実際に利用している」と語り、CloudFrontに関してもリザーブドプランがあるため、三割から四割コストが安くなるそうです。使用状況にもよりますが、上手く適合する企業にとってはかなりのコスト削減につながるのではないでしょうか。
また、クラウドストレージの特性を考えるとバッファプールサイズにDBが乗っていればI/Oが問題になる事はなく、オンメモリであれば数千IOPSで済む。むしろQPSがアップアップなので、定期的にシャーディングやパーティショニングを臨機応変に行なう事が肝要なようです。Percona Server5.5系を使用したDBのベンチマークでは、IOPSを4000にまで上げれば同スペックのSSD（物理）と同等の結果を弾き出しました。また、キャッシュもIOPSではなくRPSが問題視されていました。
オンラインゲームの設計のステップアップという考え方については、レイテンシーをいかに短縮化させるかが全てであり、そのための方法が説明されました。プロトコルはJavaのGlassFishを使用。プラス、スケールアウトはredisのpub/sub機能を使用しつつも、今後はHTTP/2も視野に入れて検証を進めていくとの事。徐々に拡大させていくというリージョンは、現在基本的に全てUSイースト。これを三段階に分けて進めていき、最終的には世界の各リージョンにアプリケーションやキャッシュ/DB、edgeサーバーを配置（含むDBノード）。キャッシュ/DBも同期させ、Route53の機能で最短のedgeサーバーへアクセスしてリージョン間はDirect Connectで接続。レイテンシーは500msから1秒程度を目指していくそうです。
「弊社はオンプレのノウハウ知識を元に組み立てているので、クラウドはクラウドをベースにした設計運営に変えていく必要がある」と田沢氏。PaaSの機能を積極的に取り入れて、また、BaaS系の機能も取り入れていきたいとの事。「ヒット予測が難しいモバイルアプリの配信に対して柔軟な設計が必要」とも語りました。
ここまで実例とベンチマークの結果を交えて解説を続けてきた田沢氏は、最後に「今後AWSへ期待する事」として「無停止でのインスタンスタイプの変更。RDS関連で、PerconaやMariaDBのサポート・クラスタ化・ELBサポート、親アカウントからダイレクトに子アカウント操作ができる、リージョン間のDirect Connectの無償化」で締めくくりました。
