« CloudDays Tokyo 2015 spring 2日目 | トップページ | Developers.IO 2015 Developer Day »

2015/03/22

JAWS DAYS 2015

【AWSクラウドを支えるアーキテクチャと技術】

・AWSのサービスはITアーキテクチャにおけるビルディングブロック

●リージョン
・11ヶ所存在
・冗長化されたトランジットセンター
・AZ間では1~2ms

●AZ
・28個存在
・全リージョンは2つ以上のAZ
・各AZは1つ以上のDCで成り立つ
 →同一DCに複数のAZが入ることはない
・マルチAZはAWSのコアコンセプトの1つ

●データセンター
・単一DCで50000~80000台のサーバ
・単一DCで最大102Tbpsのトラフィック
・AWSカスタムNW機器
 →カスタムのネットワークプロトコルスタック

●ラック/サーバ/NIC
・SR-IOVをサポートしたNICを利用
・最初のネットワークホップの全トラフィックは仮想化
・AWSカスタムサーバとストレージ
 クラウドに特化したサーバデザイン
 Intelプロセッサを商用で利用可能なクロック以上にカスタム

★デベロッパーから見たAWSのイノベーション再考
●Larger EBS
16TB,20000IOPS
よりシンプルに、より使いやすく
・今まで持ってこれなかったワークロードが移行可能になった

●EC2 AutoRecovery
自動復旧可能なので、より手離れのよいインフラに

●RDSマルチアベイラビリティゾーン
2014年では、40%がMulti-AZで使用されている

●Amazon Cognito
モバイルデベロッパーの難しいところを全部取り除く
・認証情報の取り扱い
・デバイス間の動機
・プッシュ通知

●Aurora
・MySQLベースで使い勝手は変わらず
・RDBMSの運用負担をより大幅に減らす
・プレビュー中でイノベーション真っ最中
 →今すぐ使える/使えないの判断はやめて。長い目で見てください。

●2lemetry
IoTの会社を買収しました。

★AWSを支える技術
AWSをプログラマ的に効率よく使う技術

●プログラマブルなプラットフォームとしてのAWS
・AWSはプログラマブルなプラットフォーム
・プログラマ的にうまく使うための要素技術

●AWSを支える技術:非同期API
・多くのユーザから送られてくるリクエストを公平に効率よく処理したい
・ユーザ側の利点
 →アプリケーションがブロックされず、処理が継続できる
・サーバ側の利点
 →スケーラブルかつ高可用なバックエンド

EC2での非同期API
→インスタンスIDは即座に返されるが、起動はあとから。


●べき等性
ある処理を何度やっても同じ結果が返ってくる
・べき等性のあるなしで、システムのしなやかさは決まる
例’EC2起動インスタンス

●一貫性
理想的な一貫性

・結果整合性
→データが更新されたらすぐに反映されてほしい
→複数サーバではやはり難しい
→データを複製し、複数のストレージに保持
→全体に行き渡ってから更新を反映

・強一貫性
→アップデートが即座に反映され、そのあとの読み込みから更新を読み込むことが可能。

AWSでは結果整合性と強一貫性を使い分ける


公式blog、ソリューションアーキテクトblog、パートナーSAblogの他、Qiitaにも書いてます!


★最後に
・ビルディングブロックをよりよく使うために

SAが主催する、JAWS-UG目黒を設立準備中!
・JAWS-UG東京の支部
・テーマ毎で技術の追求
・いっしょに運営されるかた募集中


【MMORPG on AWS】
・膨大な数のメッセージハンドリング
・ゲームサーバーのロードバランス
・サーバ間のデータ同期をいかに減らすか
・大量のIOをいかに低いレイテンシでさばくか

●メッセージハンドリング
EC2はマルチキャスト/ブロードキャストをサポートしていない。
ZeroMQを使ってみました。

●ロードバランス
経験値、アイテムドロップの効率のよいエリアにはユーザが偏るなどホットスポットの問題がある。
動的にエリアを分割=サーバを追加して負荷を下げていきます。

●データ同期の最少化
植物、動物、プレイヤーがオーバーラップしたエリアだけを同期してレンダリングしていきます。
オーバーラップ時に相手サーバに射影、攻撃などはRPCで元のサーバに戻します。

●低レイテンシで大量のIO
DBのアクセスを非同期化
MMORPGではJOINするようなデータはあまりないので、DynamoDBがおすすめです。
検索ではelasticsearchを使用しました。

まとめ
・SPOFを避けて高可用性を実現するためには分散アーキテクチャが重要
・あらゆる場所のレイテンシを考慮する。お客様はAZ間のレイテンシも計測している。
・N:Nメッセージングを実現するためのPubSubモデル
・EC2のエンハンスドネットワーキングはとても優秀
・NoSQLの検索の組み合わせーDynamoDBはとても優秀!
・データ同期の平均所要時間を縮めるために非同期IOを利用する。
・分散環境においてゲームキャラクター同士のインタラクションを実現するためにRPCを利用する


【モバイルファースト時代のクラウドネイティブアーキテクチャ】
・小さく産んで大きく育てるための設計をおろそかにしない
・AmazonSNSを使うと配信を早くできる
・ただし配信が早く終わると、瞬間的なリクエストが増える
・一気に負荷がかかるため、AutoScalingでは対応できない

●一斉アクセス対策
・配信量のコントロール
・サービスの対策
 あらかじめスケールアウト
 RDSを読み取りインスタンスで用意
 静的コンテンツならS3で。

Push配信を制するものがモバイルアプリを制する


●モバイルアプリで考えておくこと
モバイル用のAPIを作るべき
・何度も異なるAPIを呼ぶのは非効率
・画面表示までに時間がかかる
・ユーザ体験が悪い
・API毎にエラーハンドリングなどを考えなきゃダメ。

「1Screen, 1API call」

この本がオススメです。
O'Reilly
Web API: The Good Parts
http://www.oreilly.co.jp/books/9784873116860/


●クラウドネイティブ
アマゾンCTOヴォーゲルズの言葉
「AWSのすべての機能やツールには、存在している理由がある」

21世紀的なアプリケーション開発のあり方
http://www.atmarkit.co.jp/ait/articles/1212/03/news125.html

AWSを利用し、サービス全体を考える
・サーバーはダウンするという前提
・急なリクエストが発生するという前提
・定期的なシステムメンテナンスが発生するという前提
・ユーザ数が増えてもコストが激増しないように
という設計をする必要がある。

●AWS MobileSDK
モバイルから直接使えるAWSサービス
・Cognito,DynamoDB,S3,SNS,Mobile Analytucs,Kinesis,SQS

2Tier Archtecture
・クライアントとバックエンド
・クライアントに処理を持つ
・クライアントからAWSのサービスを利用する

2Tierのいいところ
・フルマネージドのサービスに直接アクセス
・サーバーレス
・EC2、RDSへの一極集中の負荷を減らせる
・なんかカッコイイ。

2Tierの課題
・AWS MobileSDKをラップする必要がある
・iOSとAndroidで実装が必要
・各サービス同士のつなぎ込みがしにくい
・ロールバックがある場合は大変

2Tierの救世主?ーLambdaー
・イベントをトリガーに処理を実行
・実行環境はAWSが管理
・オートスケール
・EC2インスタンス費用が不要
・AWS MobileSDKからは呼べない。

課題は色々あるけれど…
モバイルアプリは2Tierが増える!

・「小さく産んで大きく育てる」そのための設計をおろそかにしない
・Pushを制するものがモバイルアプリを制する
・1 Screen, 1 API Call
・AWSのすべての機能やツールには存在している理由がある
・AWSを知り、サービスを知らなければ勝利はない
・サービスは疎結合、チームは密結合

|

« CloudDays Tokyo 2015 spring 2日目 | トップページ | Developers.IO 2015 Developer Day »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: JAWS DAYS 2015:

« CloudDays Tokyo 2015 spring 2日目 | トップページ | Developers.IO 2015 Developer Day »