読者です 読者をやめる 読者になる 読者になる

ITお絵かき修行

3歩歩いても忘れないために

AWS Summit Tokyo 2014いってきた

いくつかセミナーに参加したのでまとめと感想文を書いておく。

AWS Summit Tokyo 2014 ~「あなた」のクラウドがここに~ | 2014年7月17日(木)~18日(金) アマゾン ウェブ サービスの無料クラウドカンファレンスが東京2Days 開催!


AWS + Windows(C#)で構築する.NET最先端技術によるハイパフォーマンスウェブアプリケーション開発実践

【概要】
株式会社グラニという会社(Web+DB Pressの裏表紙とかによく広告出稿してる)の方の講演で、「神撃のヴァルハラゲート」を中心としたソーシャルゲーム開発の中で気をつけていることを紹介。
発表者曰く「C# 50% , AWS 20% その他30%」という構成の内容で、実際その通りだと思った。
こちらの連載と少し内容がかぶっている。
第1回 C#へのこだわりは,より良いサービスへのこだわり:AWS+Windows環境における大規模ソーシャルゲーム開発/運用の実際|gihyo.jp … 技術評論社


【印象に残った点】(※話題別にまとめる)
C#
1.C#での開発は非同期処理の実装が比較的簡単であり、非同期処理を積極的に使うことで処理時間を短縮している。(C#5.0の非同期構文のおかげ)
→「Time to First Byte」を重要視している。
2.C#でモデルクラスの自動生成を行う際は、T4テンプレートとADO.NETを使用している。

●DB
1.運用時の問い合わせに対応するため、NoSQLは使用せずRDBMSを使用しており、SQLは手で書いている。
SQLServerRDBMSとしては貧弱なのでMySQLを使用。
2.垂直分割と水平分割について
DBの管理はGUIツールを使用しており、発表者いわく「イケている」らしい。そのため、GUIツールが使用できなくなる水平分割は行わないようにしている。
→DBのスケールオーバの際、「どこどこのIDからどこどこのIDはこのサーバ」というような水平分割は行うべきでない(ただしO-Rマッパを使用している場合は別)

●Redis
1.データを用途別にグループ分けし、それぞれのグループごとにデータをサーバに格納する設計としている。またMaster-Slave構成とし、ダンプ出力を行う際はSlaveデータからダンプを行うようにしている。
2.Redisではコマンドのパイプライン処理ができるので、1回のコネクションで複数コマンドを実行できる。

●その他
1.DB・アプリ・クラスなどの全階層でキャッシュを多用している。
→DBデータの結合はアプリ側で行っている。
2.10,000リクエスト/s 1億pv/日に対して、APサーバ100台+Webサーバ2台?+MySQLサーバ7台+Redisサーバ20台で対応している。


【感想】
・一般的な内容を話されていたので参考になる点がたくさんあった。(意外?)
・アプリ開発者が常にシステムの稼働状況を見られるように可視化することが大事、とおっしゃっていたのが特に印象に残った。(発表者の会社ではGlimpseという可視化フレームワークを使っているらしい)


AWS上のシステムはこう作る! InfrastructureAsCode/ImmutableInfrastructureを実践した構築自動化とHinemosで実現するクラウド運用自動化

【概要】
NTTデータのChef+ServerSpecソリューション紹介。


【印象に残った点】(※発表の時系列でまとめる)

●II(ImmutableInfrastructure)の日本文化への適応
米国・・・ユーザ系エンジニア
日本・・・非ユーザ系エンジニア
の比率がそれぞれ高い。
よって、日本では(日本のユーザ企業にとっては)他社とのコラボレーションが重要となる。また日本式の運用=厳格な運用であり、Chef等のツールの使い方は工夫しなければならない。

●問題
問:Chefで構築したサーバでバグが見つかった場合、あなたはどうしますか。
1.サーバの設定を手動で直す。
2.Recipeのコードを修正したうえで、サーバの状態を修正する。
3.故障番号単位で故障箇所を修正するRecipeを作成し、サーバを修正する。
  元のRecipeを修正するまでは作成したRecipeを使用してサーバ構築を行う。
4.サーバを捨て、Recipeを修正し実行し直す。




答(NTTデータでの対応):
現状は、3.と4.のハイブリッド。Webサーバ・APサーバ等、ELBを使用してサーバを切り替えることができるサーバは4.の対応。DBサーバなどデータの移行・サーバ切り替えが難しいサーバは3.で対応している。

NTTデータでの実行コード開発について
・Chef・ServerSpec等の実行コードはオフショア開発している(インド・中国など)。
現在はjenkinsからボタン押下でサーバを作れるようなサービスの開発をしている。
・ChefとServerSpecを使って「基盤自動化フレームワーク」としてソリューション化しており、自動化を受け入れるためのルール作りが導入にあたって大事らしい。

●Hinemos(NTTデータが開発したAWS運用管理ソフト)で運用自動化
・いろいろ機能があるが、基本的にはヘルスチェックやAWSAPIを組み合わせた、運用管理機能+各種状態見える化ソフト。Hinemos(Hinemosサーバ)のクラスタリングも可能。
・9月に翔泳社からHinemos本が出るらしい。
・Hinemos自体はOSSで、Hinemosの導入支援・運用支援をNTTデータのグループ会社が担当している。


【感想】
・Hinemosのエコシステムがすごいとおもいました(弱)


実用フェーズにはいったHPCクラウドの実力

【概要】
AWS発のクラウド環境上のHPCインスタンスの紹介。


【印象に残った点】(※発表の時系列でまとめる)

AWS on HPC
・一般的な企業で使用されているHPC・・・HPC使用までの待ち時間と運用がネックとなっている。
AmazonのHPCはスパコンのTOP500で60位くらいにつけている。
→1時間25万円?ほどで世界60位のスパコンが特別な審査なしで使えるのが魅力。

●お客様事例(ホンダ)
1.「HPCに対するニーズ」
・並列数
・コア数
・メモリ
・期間
・できるかどうかを試したい
・たまにしか使わない
→ちょっとだけ貸して

2.ホンダ社内でのHPCの変遷
【初期】 各事業部ごとにHPC所持
【中期】 HPCリソースを一括管理
 [リソース一元管理でも対応しきれなかった課題]
 ・ルーチン化されないニーズへの要望
  ・社内設備では対応しきれない要望
【現在】 AWS HPCと一元管理したHPCのハイブリッド

3.何故AWS?
 (1)待ち時間の短縮
 (2)サーバの使用開始~終了までのサイクルが早い(短い)
 (3)最新のCPU(GPU)をすぐに使える
AWSにすることでコストが1/5に減った。


【感想】
・1000台のPCを並列で動かして計算する、とかスケールの大きい話が聞けたので面白かった。
Amazonでできないことなんてないじゃないか、という気にさせられかけた。危なかった。



【おみやげ】
f:id:hhhhhskw:20140718204208j:plain

Amazon Web Services 基礎からのネットワーク&サーバー構築

Amazon Web Services 基礎からのネットワーク&サーバー構築