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

まちいろエンジニアブログ

南池袋のWebサービス開発会社、株式会社まちいろのエンジニアブログです。

AWS Summit Tokyo 2016 Day2 参加レポート

イベントレポート

こんにちは、まちいろの工藤 (@macococo) です。

6/1〜6/3 の間に開催された AWS Summit Tokyo 2016 の Day2 に参加してきましたので、レポートを公開します。

www.awssummit.tokyo

他社様事例でスライドが公開されていないものについては、内容ざっくりで。

Day2 キーノート

  • 東京リージョンは5周年
  • 10年で売上1兆円到達
  • デジタルトランスフォーメーションを支えるプラットフォームとしての AWS

全体的に初心者向け・エンタープライズユーザー向けの内容。
AWS Japan 長崎社長の立ち居振る舞い、トーク力が印象に残りました。

Fate/Grand Order における、ディライトワークス流 AWS 導入&活用術

  • 元々は Azure で運用、リリース以降に様々な課題が発生していた
  • Azure 運用での性能の課題
    • DB がボトルネックだった
    • Azure 環境でやれることを試したが、なかなか改善されず
  • Azure 運用での可用性の課題
    • 前触れのないサーバーダウン
    • メンテナンスによる再起動により、15分程度のサービス停止が発生する
  • 昨年 AWS に移行

リリース直後に不具合・メンテ頻発で話題?だった「Fate/Grand Order」。
私自身も前職でソーシャルゲームを開発していたので、当時を思い出しながらセッションを聞いていました・・・。

IP コンテンツということで、当初からある程度の負荷を想定した開発を進めていたとのことですが、
実際にリリースしてみると想定以上の負荷となっていたようです。あるある。

ソシャゲは更新処理の頻度が高いので、DB がボトルネックになりがちですね。

Amazon Aurora deep dive ~性能向上の仕組みと最新アップデート~

  • Aurora の概要紹介
    • MySQL 5.6 互換
    • 高いクエリ実行並列度、データサイズが大きい環境で性能を発揮
    • 高可用性、高速なフェイルオーバー
  • フェイルオーバー、リプレース
    • リードレプリカが存在すれば1分以内にフェイルオーバー可能、存在しない場合は 15分程度
    • クラスタエンドポイントを参照することで、常にアプリはマスターを参照できる
  • SQL でクラッシュシミュレート可能
  • MySQL 5.6/5.7 との性能比較
    • READ/WRITE 性能が 3〜5 倍程度高い
    • 資料のグラフを見る限り、インスタンスタイプ変更によるスケールアップの性能幅が大きい
  • チューニング指針
    • まずはデフォルトのパラメータグループを使用
    • インスタンスタイプによるスケールアップ
    • Aurora は並列処理に強いので、バッチ処理などでテーブル全行走査したい場合は、数千件単位で分割して実行したりするとパフォーマンスが改善されることがある
  • リリース後の数ヶ月の間で沢山の改善を行っている

昨年発表された Aurora、AWS の中でも最速で成長しているサービスだそうです。

残念ながらまだ弊社では Aurora を導入するような規模感のサービスはないのですが、
非常に魅力的なサービスですので触っておきたいと思います。

新時代の幕開け、サーバーレスアーキテクチャの衝撃!〜開発・運用・セキュリティ・コストがどう変わる?〜

スライドが公開されていたので内容は割愛。

今回の AWS Summit では「サーバーレス」という単語がよく聞こえてきました。

Lambda をうまく利用することで、開発・運用コストの最小化でき、
かつアプリケーションからビジネスロジック以外のコードを切り出すことができる、というのはかなりキャッチーですね。

事例で紹介されていた、EC2 インスタンスを日中だけ起動しておくよう Lambda で制御する、というのは面白いなと思いました。

現場が語る AWS でのパーソナライズ導入事例-Amazon Redshift, Amazon S3, Amazon DynamoDB, Amazon Kinesis

  • Redshift
    • コストが安い
    • データ量を気にしなくて良い
    • インターフェースは PostgreSQL と同じ
  • Redshift だけではリアルタイム処理が実現できなかった
  • そこで Kinesis を使い、リアルタイムに欲しい情報とそうでない情報を分けた
  • AWS であれば、低コストで検証 -> ボトムアップで提案が可能だった

レコメンドエンジン周りの話を期待していたのですが、その辺は割愛されていました。残念。
正直 Kinesis 自体がどういうのものかちゃんと理解できていなかったので、概要を把握する良い機会を得られました。

まとめ

当初は Day3 の Deveploper Conference を目当てにしていましたが、今回は都合により Day2 のみの参加となりました。
General Conference は沢山の人で溢れていて、どのセッションも行列ができるほどの盛況っぷりでした。

AWS やその他のクラウドサービスによって、アイディアをすぐに形にするための環境は揃っており、
後はそのアイディアをスピード感を持って Try できるかが重要である、と改めて感じました。

会場でいただいた AWS 事例本、読ませていただきます :)