Downloaded 17 times
Uploaded byRyo Nakamaru
コンソールゲームを世界展開してみた - JAWS DAYS 2015
AWSのマネージドサービスやDockerを使った環境構築のメリットや世界展開に必要な製品の作り方から、どうすれば開発運用をより楽に行えるかを考えます。
More Related Content
![[JAWS DAYS 2017 ワークショップ] 不安で夜眠れないAWSアカウント管理者に送る処方箋という名のハンズオン](https://cdn.slidesharecdn.com/ss_thumbnails/20170311jawsdays2017h1-170311030315-thumbnail.jpg?width=640&height=640&fit=bounds)
![[JAWS Days 2015 LT]使い始めて3年半、ようやくテスト始めました](https://cdn.slidesharecdn.com/ss_thumbnails/jasw-days-lt-150323200941-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証](https://cdn.slidesharecdn.com/ss_thumbnails/auroradeep-150322203758-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to コンソールゲームを世界展開してみた - JAWS DAYS 2015
コンソールゲームを世界展開してみた - JAWS DAYS 2015
- 1.
- 2.
- 3.
- 4.
- 5. 1. マネージドなAWSを使ってみよう 2. AWSに学ぶ、世界展開2つのポイント 3.今っぽい技術でDevOpsの改善を 今日のストーリー
- 6.
- 7. AWSのDevOps 昨年12月に発行されたAWSホワイトペーパーには 一般的によく語られる自動化やCI中心の、こんな図があります。 “Introduction to DevOpson AWS” http://d0.awsstatic.com/whitepapers/AWS_DevOps.pdf （5ページ目からの引用）
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16. 運用業務をアウトソースしたい 専門性のあるひとを雇うより安い （参考） EC2 m3.xlarge 100%usage- $296.46/month RDS db.m3.xlarge 100%usage - $355.02/month 月7,200円程度でフルマネージドなMySQL！？
- 17.
- 18.
- 19. 1. 画像・音声・ゲームデータの配信に最適 2. 世界中にエッジロケーションTCP最適化 3.マルチオリジンCORS 4. 動的なコンテンツにも！ CloudFront 4つのメリット 稀に起こるAWS起因の避けがたい障害はたしかにやっかい。 その影響を最小限に抑えるためのノウハウもあることや 日々受けられる恩恵を考えれば・・ ゲーム運用的にうれしかった
- 20.
- 21.
- 22. 3. マルチオリジン CORS 製品とユーザデータはわけて管理したい！！ クロスドメインでも動作するアプリにしたい！ //www.app.com/ //static.app.com/users/avatar/10235.png //static.app.com/assets/js/index.js index.htmlください 静的ファイルはstatic.app.comにあるよ users* はユーザバケット assets* は製品バケット CORS設定 Cache-Control設定 CORS設定 Cache-Control設定 LifeCycle設定 OPTIONSメソッド有効 クエリ文字列をフォワード ユーザデータ生成 設定もかんたんで直感的。
- 23. 4. 動的なコンテンツにも！ リクエストヘッダ、クッキー、クエリ文字列をオリジンへ フォワード。またそれらを利用してキャッシュ制御すれば 静的ファイルで受けられる恩恵を動的コンテンツにも！！！ ・全リクエストが静的ファイルと同じ恩恵をうける ・Re-Usableな動的コンテンツのキャッシュ - その検索結果、1秒後には変わるの？ ・Route53とCDNでレイテンシを最小に ・PUT/POST最適化: アップロード時間の短縮 ! ※ LBRについてはre:Invent 2013の資料がよいです Dynamic Content Acceleration: Fast Web Apps with Amazon CloudFront and Amazon Route 53 AWS Summit 2014 http://www.slideshare.net/AmazonWebServices/aws-summit-tlv201413dynamic-content-acceleration Dive Deepしたい方へ
- 24.
- 25. 1. DB性能の変更がかんたん 2. 柔軟に使えるリードレプリカ 3.任意時点へのリカバリ RDS 3つのメリット AWSによる物理サーバの強制ローリングアップデートのリスク （これまではメンテナンスウィンドウで処置されている）
- 26. 1. DB性能の変更がかんたん CPU、メモリ、IOPS、設定の変更が数クリック。 ただし数分間の機能停止が伴うケース多数。 http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/ Overview.DBInstance.Modifying.html 例: 数分間の機能停止 db.m3.large vCPU:2 Memory: 7.5GiB SingleAZ db.m3.xlarge vCPU: 4 Memory: 15GiB MultiAZ
- 27. 2. 柔軟に使えるリードレプリカ リージョンを超えてレプリカを作ったり(MySQL)、 オンラインのまま増やしたり減らしたり、 レプリカのレプリカを作ったり。 db.m3.largedb.m3.large db.m3.large db.m3.large db.m3.xlarge db.m3.xlarge db.m3.xlarge db.m3.xlarge 例: 起動中DBのインスタンスクラスの変更は機能停止を余儀なくされるが、 リードレプリカを使えば無停止で性能変更することも可能。（実例・・）
- 28. いわゆるPoint-in-Timeリカバリも数クリック！ ただしエンドポイント（接続先）変わります・・ 3. 任意時点へのリカバリ ※RDSの2種類あるリストアは、使う前にぜひ把握を！ 14:35時点にリカバリ 例: 14:30 14:35 14:40 14:45 14:50 稼働中 稼働中 障害発生
- 29.
- 30.
- 31.
- 32. まとめ • AWSのマネージドサービスはメリット多し • CloudFrontを使えば高速に配信できる！ •RDSを使えば容易にスケールできるサービスに • CloudFrontもRDSもかんたんに使える
- 33.
- 34.
- 35.
- 36.
- 37. 数学において、冪等性は、大雑把に言って、ある 操作を1回行っても複数回行っても結果が同じで あることをいう概念である。(Wikipediaからの引用) べきとう？ 処理1回目 もう1回やってみる 3回目に挑戦 -結果IDはXXX - 結果はYYY - ステータス：成功 - 結果IDはXXX - 結果はYYY - ステータス：成功 - 結果IDはやっぱりXXX - 結果は変わらずYYY - ステータス：もちろん成功
- 38. In computing, alocale is a set of parameters that defines the user’s language, country and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier. (en.wikipedia.orgから引用) 「ユーザが画面で見たいもの」が何かを決める材料 日本での発売日いつ？ 日本語ページがない.. 日本に発送できる？ ろけーる？ 例：ロケールが考慮されていないサービスの典型・・
- 39.
- 40.
- 41. • 負荷を分散しやすい • リトライできる •デバッグかんたん • テストもしやすい • 結果を遅延生成できる 処理が冪等なら
- 42.
- 43.
- 44. ・内容を読んでもらえる（あたりまえ） ・適切なサービスが届けられる - 日本だけにプロモーションしたい -オーストラリアでは試験的にサービスを先行開始したい ・問い合わせ時のエスカレーションが地域ごとに変えられる ・ユーザ分析時に有用 ロケールを考慮しておけば 円滑にサービスを運用する上では 避けて通れない必須の考慮点 （最初に考えておかないとほんと大変）
- 45.
- 46. • 処理開始時にマスタのスナップショットを保存 • 乱数に利用するシード値の保存 •データの整合性を担保すべき範囲の把握 • 可能な限り、処理をより小さなものに分割 • ただしエラーの発生は環境にもよるのでログ大事 処理を冪等にするために insert into A’ from (select * from A where..) CloudWatch Logs.. fluentd..
- 47.
- 48.
- 49.
- 50.
- 51. 神資料 • Asynchronous IO •Retries with Exponential Backoff • http://docs.aws.amazon.com/ja_jp/general/latest/gr/api-retries.html • Idempotency • Eventual Consistency 大規模分散システム ”Amazon Web Services” の使い方 ! ! AWSエンジニア 橋本さん http://cloud-spiral.enpit.jp/wp-content/uploads/Slides_Koji.pdf
- 52.
- 53. まとめ • 処理は負荷分散＋再現しやすいよう冪等に • AWSを使うなら、AWS同様に作ってみる •非同期API • 指数関数的後退を伴うリトライ • 冪等性 • 結果整合性 • 円滑なサービス運営のためのロケール • 居住地と言語は分けて考える
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61. 事例2：本番環境に使ってみた結果、快適 • 数百人が利用するWebアプリ（ゲームではない） • EC2t2.mediumを1台、CoreOSのAMIから起動 • 構成は事例1に近い • 社内のDockerリポジトリを参照 • 無停止のブルーグリーンデプロイもSlackから
- 62. 事例2：ブルーグリーンデプロイメント 80 80 8080 80808080 1. この状態で稼働中（ブルー） 2. 新環境（グリーン）立ち上げ 3. 確認後、接続先を切り換え 4. ロールバック不要なら旧環境を破棄
- 63.
- 64. 事例3：ブランチ別の環境をあっというまに • 本番環境だと100台程度の、中規模プロジェクト • 複数レイヤ：Nginx、PHP、Java、MySQL、etc.. •CI環境で • 社内のDockerリポジトリを参照して • SlackからGitのブランチを指定して環境立ち上げ • 指定ブランチ環境のエンドポイントが返ってくる
- 65.
- 66.
- 67. ところでAWSのDocker事情 EC2: CoreOSのAMIもあるよ ECS: コンテナ管理サービス。クラスタ管理が容易に ElasticBeanstalk: DockerイメージでもDockerfileでも OpsWorks: Chefレシピを書けば何でも + ・VPCやRDS、セキュリティなど既存のAWSリソースが使える！ ・Elastic BeanstalkやAutoScalingなら、DevOpsのための機能 （ローリングアップデート）がより高速に使える..はず！ バージョニングやOpsWorksのcloneはブルーグリーンデプロイメントには有用ですが Dockerのよさが半減するかも
- 68. まとめ • Dockerは万能ではないが、とても有用！！ • 開発環境やテスト環境では夢が広がった •小規模（∼数台）なら本番でも便利 • AWSは選択肢が豊富で夢が広がる • EC2にはCoreOSのAMI • ECSはこれから成長しそう • Elastic BeanstalkのDockerサポートうれしい • OpsWorksと組み合わせることもできる
- 69.
- 70. セキュリティやネットワークの設定 • なるべくCloudFormationテンプレートを使う • Gitによるバージョン管理（コミットメッセージに摘要） •CloudFormationDynamoDBLambdaで自動適用（しようとしてる） • 環境コピーがとてもかんたん！！素晴らしい • ブルーグリーンデプロイメントもできるよ IAMポリシーはじめ、セキュリティグループやNACL VPCの各リソースの関係性、これらのAWSリソース どう管理してますか？ うちも零細企業ながら、すでに手管理はつらい。 AWSが推奨するDevOpsに従って・・
- 71. 静的ファイルの更新 • 差分のあるファイルのみファイル名を変更 • Cacheをリソースごとに適切に設定してがんばる •S3のprefixをバージョンで切る • CloudFrontディストリビューションのCNAME変更 • 新規CloudFrontディストリビューション作成 + CNAME変更 • etc.. いろんなパターンがあるものの、 ゲームは全ユーザへブラウザなどの端末に依存することなく 同時に最新のファイルがあたる必要があるので DNSを使った手なら細心の注意を・・
- 72. アップデートメンテナンス • ELBにSorryページをぶら下げる • 各サーバのローリングアップデート •CloudFrontディストリビューションの作成、新しいCNAMEをふる • Route53のレコード更新 • アプリ、Webからの静的ファイルパス変更 • 新verへのDB更新、インデックス再構築・・ • 関係各社のみへサービス公開、最終確認 ゲーム屋さん、 あえてサービスを止めてメンテしているかもしれません。