AWS Summit Tokyo 2016 参加メモ

AWS Summit Tokyo 2016 に参加したのでメモを残す。個人的なメモです。

PlayStation Network のユーザメッセージ機能「Messages」を支える AWS 技術

藤本 篤彦（Sony Interactive Entertainment INC　NPS開発部 サービス開発課）

PlayStation Network のサービスの一つとして、ユーザ間メッセージサービスの「Messages」があります。近年、Messages は、PS4 / PSVita / スマートフォンを介して利用されるようようになり、利用者数が激増しました。 そこで、利用者の急激な増加に対応するために、オンプレミスから AWS へサービスを継続しながら移行しました。 その中で、なぜ AWS を利用したのか、AWS を利用した開発方法、切り替え時の工夫、DynamoDB 利用時の設計上の工夫、現在から今のシステムを振り返った際の改良ポイントと今後の開発の方向性について、開発者としての視点からご紹介します。

PlayStation Message（PSM）をオンプレからAWSの移行したときの話
開催レポート動画・資料一覧にいずれ資料がアップロードされるかも

メモ

移行背景
- PSMの発売（14年）でユーザが月３倍の伸びになった。オンプレでは限界と感じてAWSに移行することになった
- オンプレでサーバー増強していたが、他のサービスで使用していないサーバーを使ったりしていて、スペックが違いチューニングに追われていた。毎週末、増強会議が開かれていた涙
- ユーザが爆発的に増加し、対応できなくなった。PSMの特徴として、ビックタイトルの発売に依存する、。でも、実際に増加するか読めない笑

AWSの設計検討

• DBは cassndra にしようと思ったけどOPSチームからAmazon DynamoDB（KVS）を推薦された

Amazon DynamoDB の性能調査

• プロビジョンドスループットの線形性、レイテンシ問題があるか調査
  • 問題なし
• DynamoDB に100万ユーザのデータセットを保存して、想定アクセスの2/10, 4/10, 6/10で評価し
  • 問題なし
  • DynamoDBは「簡単にテストできるのがいい」と感じた

設計のポイント

• DynamoDB の前段に Amazon Elasticache を設置。DynamoDB はアクセスするたびにお金がかかるので、キャッシュサーバーをおいてコスト削減！
• Cacheを更新するときは差分更新
• BatchGetItemを利用しないで、Queryでアクセスするようにプログラミング

パーティション数＝物理的なサーバ数

• スループットキャパシティは、一つのパーティション数で均等に分割される
• ホットキーができないようなテーブル設計を心がける

自前TTLの実現

• ２年前からサポートするとAmazonは言っているが、一向にサポートしてくれない涙
• なので、削除用DBを用意

移行方法

• 並行移動。ユーザがAPIにアクセスのタイミングで逐次DynamoDBにデータを移行
• 問題があった場合、切り戻し可能とする

AWSに移行してみて

• 運用費は1／4になった
• スケールアウト容易

デメリット

• たまにAWSの謎挙動に遭遇
• EC2のあたりはずれがある
• ホットキーがあった場合どうするか

AWS を使ったモバイルアプリの設計と実装

スピーカー： 塚田 朗弘（アマゾン ウェブ サービス ジャパン株式会社　技術本部 メディア・エンターテインメント部 ソリューションアーキテクト）
ゲストスピーカー： 松本 勇気（株式会社Gunosy　開発本部執行役員）

AWS のモバイル開発向けサービスは急速に進化を続けており、mBaaS の利用とは違う新しい形でモバイルアプリ開発をトータルにサポートしています。適切に活用していただくことで、プロダクトの開発スピード向上や運用コスト減に大きく寄与できる AWS モバイルサービス群。具体的なユースケースと最新情報を交えて、モバイルアプリエンジニアの方、バックエンドシステムのエンジニアの方に実践的な使い方をご紹介します。

メモ

ここのキレイにまとめられている笑 -> Developers.IO

クライアントに対する処理移譲

• AWS MObile SDK を利用
• ユーザ認証・認可をCongnito経由で
• 通知のトークン管理をSNSで
• ログの配送は直接Kinesisへ

サーバレスアーキテクチャの部分的適用

• すべてをサーバレスにはしない
  • 求めるレスポンス速度など非機能要件に応じて選定
• 非同期で運用可能なものほど向いている
  • 後述するユーザ設定管理
  • ログの配送・加工・集計

Congnito Syncによるサーバレスなユーザ管理

• Mobile側より Congnito Sync にユーザ設定値（通知のON/OFFなど）を保存
  • ユーザの設定値→何度も作っているの無駄
• Connito Sync の event -> Lambda をフック
• Lambda から Elasticache 等へ設定値を保存
  • SNS から Topic に endpoint をぶら下げるなども簡単
• 通知時刻などの管理をCongnitoSync経由で完結
  • ストレージを除きサーバを持つ必要なし
• 記事の推薦などGunosyのコアロジックはサーバーレスにしない
• マイクロサービスにサーバレスを載せた感じ

Kinesisによるログ管理フロー

• ログ中継などのリソースを持たない
  • 大規模なログ送信の管理コストは思った移譲に高い
  • 「自前でログでやるとキューがつまる」
• クライアントからKinesisへ直接ログの配送
  • MobileSDKからの送信
  • 再送ポリシーなどはクライアント側で担保する必要あり
  • クライアントは通信環境が悪いところでも使われることがあるので、そこに対応するため

• Bufferを用意していおいてログは溜める
  • なぜならば、クライアントを通信を多くとすると電池を食うのでユーザに嫌われるので
• 最近発覚したTipsで、AWS Lamdba から S3 直接配送すると細かいチャンクが送信されて、一時間で数千ファイルになる。なので後ろのプレストで一旦溜めて配送している

松本さんは、いかに速く、効率的にするかを考えている。

ドワンゴが AWS を使ってメディアストレージ基盤を開発してみた

坂井 薫平（株式会社ドワンゴ フロンティア開発部第二セクション）

AWS のサービスを活用し、サーバレスなアーキテクチャを目指して開発されたメディアストレージ基盤をご紹介します。 本基盤は新規サービスを開発する上で、面倒な実装や困難な処理を予め共通化しておくことで各チームの開発コストを減らし、開発効率を向上させるという狙いがあります。 本セッションでは、本基盤のアーキテクチャと実現方法を解説すると共に、それを用いた新規サービスについても、具体例としてご紹介します。

秒間数万のログをいい感じにするアーキテクチャ

星 北斗（クックパッド株式会社　インフラストラクチャー部 セキュリティグループ グループ長）

広告、行動分析、セキュリティなど、クックパッドでは様々な用途でログを収集・利用しており、その流量や重要度は日を追って高まっています。 本セッションでは、Fluentd や Amazon Kinesis Streams を中心としたログ収集および、 Amazon Redshift などを用いたログの活用方法についてご紹介します。

メモ

• 夕飯の時間帯がピーク。インスタンス1200台が起動
• テレビで放送されると30,000req/1s
• なぜログを集めるのか？
  • 起きたことを示すため
  • 仮設の検証。きっとよくなったではだめ。
  • パフォーマンス改善：応対速度は重要
• Web DB Press にCookPadで収集しているログデータの種別が掲載されている
• ログの要件 - Try and Error のしやすさいことが重要かなと思っている
• re:dash