[レポート]1000万DL突破!BrainWarsを支えるAWSサービスたち #AWSSummit

[レポート]1000万DL突破!BrainWarsを支えるAWSサービスたち #AWSSummit

Clock Icon2015.06.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、城内です。 今回は、 AWS Summit Tokyo 2015TC-06セッションのレポートです。こちらはランチセッションでした。

セッション情報

  • セッション名:1000万DL突破!BrainWarsを支えるAWSサービスたち
  • スピーカー:株式会社トランスリミット CTO 松下雅和氏

IMG_6201

スライド

[slideshare id=48923410&doc=brainwarsaws-150603042812-lva1-app6892&w=640&h=480]

セッション内容

スピード最優先

  • 積極的にアーキを変更、半分以上は置き換わっている
  • 面白そうなプロダクトはどんどん採用
  • 海外ユーザが多いので、海外リージョンを採用

コストはシビアに

  • 費用対効果に合わないプロダクトは使わない
  • 費用が掛からないなら自作
  • 管理画面など不要なものは作らない

運用は楽に楽しく

インスタンス(Socketサーバ、APIサーバ)の管理にOpsWorksを採用

  • timeとloadでスケールできるのが嬉しい
  • 週末のランキング確定時にtimeでオートスケール
  • ResourcesとしてRDSを設定(Ruby on Railsで有効)

工夫している点

  • ファイルディスクリプタのチューニング(要monitプロセスの再起動)
  • CloudWatchには独自のカスタムメトリクスを追加
  • カスタムAMIを作成、EBS-Bootで事前起動しておくことで起動時間を短縮(7分→2分)

DynamoDBの活用

  • 操作ログを保存
  • ハッシュとレンジの両方を利用
  • データ量93GB、データ数1.1億
  • Socketサーバで対戦相手が見つからなかった場合やサーバがダウンした時、DynamoDBのデータをReadしてbotがゴーストとして対応する(メッセージのやり取りも同じ仕組み)

SNSの活用

  • ChatOps経由で一括通知
  • 料金がすごく安い
  • APIの呼び出し頻度に制限がある

SESの活用

  • エラー通知はSNSとSQSを組み合わせて対応
  • バウンスが多すぎると警告があるので注意が必要

監視/モニタリング

  • CloudWatchで監視、通知はSNSからLambdaに連携してチャットに流す

データ分析

  • SQSに溜め込んで、MAC端末経由でBigQueryを利用

まとめ

  • どのサービスも使いこなせば最強
  • 事例通りではうまくいかない
  • 向いていない使い方は身を滅ぼす
  • それぞれのサービス特性を理解する
  • コスト感や運用のイメージを持つことが大事

感想

JAWS-DAYのセッションでも、他のスタートアップ企業のシステム開発環境でbotを利用しているケースが紹介されていましたが、最近チャットからのbot処理という仕組みが主流なようです。今回は、障害通知もLambdaを介してbotのAPIからチャットに流すなど、すごく徹底されている感じがしました。

弊社もチャットを使っているので、botがあったらいいなーと、ちょっと羨ましくなりました(笑)

資料リンク

AWS Summit Tokyo 2015 開催レポート動画・資料一覧

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.