AWS Summit 2015 に参加してきました Day1 #AWSSummit
sparkgene
こんにちは、sparkgeneです。
6/2〜6/3はAWS Summit 2015が開催されています。
2日間とも参加しますが、初日の参加レポートをお送りしたいと思います。
2012年から４回目となるAWS Summitですが、毎年参加者が増えているとのことです。
去年は8,000人以上の方が来場し、今年は13,900のレジストレーションがあったとKeyNoteで紹介されていました。
KeyNoteもかなり広い会場でしたが、満席となってしまって遅れてきた人は残念ながら入れないという状況でした。
KeyNoteではAmazon Data Service Japanの代表取締役である長崎さんが今回のセッション規模の話やAWS誕生の話から始まりました。
Amazonのサービスを開始するにあたり、Amazon.comの創業者でありCEOのジェフ・ベゾス氏がナプキンに書いたと言われる図が紹介されました。この図は、
- 低コストの仕組みを作り
- コスト削減により得られた利益で低価格化を進め
- そのことでユーザーが得られる体験を向上させ
- さらにユーザーが集まり
- そこに販売したい人がどんどん参入し
- 更に低コストを進め
- 以下無限ループ…
と言ったサイクルを表しています。
この中で低コストの仕組を作るために、エンジニアが多くの時間を割いていたインフラのメンテナンスをAPI化することが進められ、その仕組をAmazonの外にも提供したのがAWSということでした。
元々はAmazonという巨大なECサービスを提供する（支える）ためのものだったのが、今となっては世界で一番使われているクラウドサービスとなっています。
KeyNoteではさらにクラウドワークス社、リクルートテクノロジーズ社、ファーストリティリング社から事例の紹介がありました。
ちなみに、私のジンクスとしてAWS Summitに参加すると、必ず仕事のほうでなにか起きる→リモート対応するというのがあるのですが、今年は比較的平和な感じでした。
以下、参加したセッションの紹介です。
リクルートの利用事例から考える AWS の各サービスとセキュリティ
我々がいつもお世話になっているリクルートテクノロジーズの宮崎さんから、リクルートグループで使われているAWSのセキュリティー及びユーザーの管理についてのお話。
東京リージョンが登場し、VPC、IAMが使えるようになったことで、AWSを利用できるようになったとのことで、逆にこれらの機能がなければAWSは導入されなかっただろうとおっしゃってました。
（つまり、AWSが使われていなかったら、私も中途入社することもなかったかもしれないですねw）
サーバ構築したら当然定期的なメンテナンスが必要となってきますが、IAMのポリシーも同じく定期的なアップデートや運用ルールの見直しが必要ですよねというのが印象的でした。
急成長しつづける freee、AWS との付き合い方
現在は30万以上の事業所で導入がされているクラウド会計ソフトfreeeは、リリース時からAWSを利用していて、事業の拡大に合わせてシステムの構成が少しづつ変わり、成長し続けているという話。
初期バージョンではさくらVPS＋Herokuと言う環境で動かしていたが、リリース時にはVPC+EC2＋RDSといった構成に変えたそうです。
最初はインフラ担当はおらず、CTOが１人で環境を構築して事業の成長に注力していました。
ユーザーも順調に増え続け、社員も30名ぐらいに（ついにインフラエンジニアも）増えたことで、Elasticacheや解析基盤を組み込んでいったりと、AWSのサービスを積極的に採用していった。
半年後には新しいサービスも追加され、共通認証基盤が追加されたり、DBもインスタンスも増えていきました。
現在は社員が100人程までになり、サーバ台数も増えたりサービスも複数あることからデプロイの時間がかかっているので、そのあたりの改善を進めていきたいとのことでした。
AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ
AWSのサービスの中でもデプロイに関するサービスのそれぞれの違いや位置づけについてのセッションでした。
実際にAWS上で構築されているサービスは、すべて同じ方式のデプロイが向いているのではない。
そのために、複数の方法（デプロイサービス）として用意していますと。
現在はOpsWorksを使うことが多いのですが、デプロイに関してはCodeDeployで提供されている、1台づつデプロイといった機能がOpsWorksにも取り入れてほしいなと思いました。
Amazon
EBSの特徴の説明が前半にありましたが、実際に何をもってどのEBSを使うのがいいかというのが分かるセッションでした。
EBSのパフォーマンスは以下の3つの要素で決まるとのこと。
- EC2インスタンス側のスループット
- CloudWatchのメトリックスやOSの数値を見て足りてるかを調べる
- 足りなければインスタンスタイプを上げることを検討する
- EBS側のI/O処理性能
- CloudWatchのVolumeのRead/Writeのメトリックスをみて足りているかを調べる
- 足りなければタイプの変更を検討する
- EBS側のスループット
- CloudWatchのVolumeのRead/Writeのメトリックスをみて足りているかを調べる
- 足りなければタイプの変更を検討する
I/Oが足りていてもスループットが出ない（上限に達してる）事もあるので、EBSの種類による上限値もちゃんと把握しておく必要あり。
各ブロックに対して、初回アクセスに限り5〜50%の性能劣化が起きるため、急激なアクセスがある場合はプレウォーミングをしておくのが良い。
それでも性能が出ない場合はインスタンスストアを使うと良い（Stopするとデータが消えるので、使えるかは要件次第）。
EBS暗号化オプションをONにしてもハードウェアで処理するので、性能劣化はほとんど無い。
まとめ
セッションだけではなく展示ブースで実際に利用しているミドルウエアやASPサービスの会社の人と話をしたり、AWSの方に最近抱えている問題を相談したりと、非常に学びの多い1日でした。
夜は「Developers Night」と題してイベントが行われ、IoTハッカソンの成果発表なども行われ、最後まで楽しめるイベントでした。
Day2はよりテクニカルなセッションを聞く予定ですので、またレポートしたいと思います。