1人から1000万人までの道のり：AWSにおけるスケールするインフラ設計とは？

AWS Summit Online 2020

Transcript

1. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1⼈から1000万⼈までの道のり︓ AWSにおけるスケールするインフラ設計とは︖ ⽯⾒ 和也 ソリューションアーキテクト 技術統括本部 インターネットメディアソリューション部
2. Kazuya Iwami Internet Media Solution Architect, Amazon Web Services Japan Machine Learningプロジェクトの⽀援も⾏う 最近お気に⼊りのAWSサービス - AWS CDK - AWS Fargate - AWS Chime SDK
3. Webアプリケーションを構築する場合、 どのような構成から始めますか︖ Web DB
4. DB プライマリ/ スタンバイ CDN オブジェクト ストレージ Web ロード バランサ Web Web インメモリ キャッシュ NoSQL DB サービス A サービス B キュー DB リード レプリカ Webアプリケーションを構築する場合、 どのような構成から始めますか︖
5. フェーズや⽬的によって ⽬指すべきアーキテクチャは異なる それ以上 - 1,000,000人 - 10,000人 - 100人
6. 本セッションのねらい • AWSでWebサービスを構築する場合、フェーズごとに どのAWSサービスを組み合わせて設計するとよいのかという基礎を学ぶ • システムをスケールさせていく上でどのような課題が発⽣しうるかを 知り、⼀般的な対策を学ぶ • 基礎となる仮想サーバー利⽤時の考え⽅にフォーカスします • セキュリティに関する運⽤、個別のAWSサービスの詳細はお話しません
8. プロトタイプのフェーズ Web DB 数⼈から数⼗⼈ • シンプル 安価 • 可⽤性や拡張性は求められていない - 100人
9. AWSでの構成例 VPC Elastic IP address EC2 Instance Amazon RDS instance Amazon Route 53 Elastic IP Address Amazon EC2 Amazon RDS User Amazon Route 53 - 100人
10. データベースの選択肢 電源、ネットワーク ラック導⼊管理 サーバメンテナンス OSのパッチ ミドルウェアのパッチ バックアップ スケーリング 可⽤性 ミドルウェアの導⼊ OSの導⼊ アプリケーション実装 オンプレミス EC2 お客様がご担当する作業 AWSが提供するマネージド機能 電源、ネットワーク ラック導⼊管理 サーバメンテナンス OSのパッチ ミドルウェアのパッチ バックアップ スケーリング 可⽤性 ミドルウェアの導⼊ OSの導⼊ アプリケーション実装 電源、ネットワーク ラック導⼊管理 サーバメンテナンス OSのパッチ ミドルウェアのパッチ バックアップ スケーリング 可⽤性 ミドルウェアの導⼊ OSの導⼊ アプリケーション実装 AWSマネージドなDBサービス
11. ⾃動 バックアップ スナップ ショット パッチ更新 • フルマネージドのRDBMSサービス • DBエンジンはMySQL, Oracle, SQL Server, PostgreSQL, MariaDB, Aurora から選択可能 • DBのセットアップやバックアップ、パッチ適⽤などをAWSが管理してくれるため メンテナンスコストを⼤幅に削減 Amazon RDS (Relational Database Service) アベイラビリティゾーン 1 アベイラビリティゾーン 2 負荷分散のための 「読み取り⽤レプリカ」 別AZにデータを同期 ⾃動的にフェイルオーバー
12. 現在の構成における将来的な課題 VPC Elastic IP address EC2 Instance Amazon RDS instance 🔥 🔥 可⽤性に課題 User Amazon Route 53 - 100人
13. 現在の構成における将来的な課題 VPC Elastic IP address EC2 Instance Amazon RDS instance スケールアップには限界 可⽤性に課題 User Amazon Route 53 - 100人
14. サービスを⼀般公開するフェーズ DB プライマリ ロード バランサ Web Web DB スタンバイ ⼀般向けに公開 数百⼈から数千⼈ • 可⽤性 拡張性 - 10,000人 - 100人
15. 可⽤性向上のために 複数のアベイラビリティゾーンを利⽤した 単⼀障害点の無い構成を⽬指す
16. AZ3 AZ1 AZ2 リージョン内の構成 • 複数のDCから構成されるAZ (Availability Zone) • リージョン内に地理的に離された複数のAZを⽤意 • DC間は冗⻑化された数ｍsecの低遅延メッシュネットワーク
17. リージョン内の構成 • 複数のDCから構成されるAZ (Availability Zone) • リージョン内に地理的に離された複数のAZを⽤意 • DC間は冗⻑化された数ｍsecの低遅延メッシュネットワーク AZ1 AZ2 AZ3
18. 中⻑期的な拡張性を確保するために
19. VPC EC2 Instance Amazon RDS instance (スタンバイ) ALB AZ1 AZ2 EC2 Instance Amazon RDS instance (プライマリ) Application Load Balancer (ALB) User Amazon Route 53 - 10,000人 - 100人
20. ステートレスなアプリケーションであることが⼤切 • セッション情報 • Amazon RDSやAmazon DynamoDBのようなDBサービスに保存 • もしくはAmazon ElastiCache (Memcached/Redis) のようなインメモリキャッシュに保存 • ログ • CloudWatch Agentを利⽤し、Amazon CloudWatch Logsにログを送信 • Kinesis Agentを利⽤し、Amazon Kinesis Data Firehoseを経由しAmazon S3にログを送信 ⻑時間存在するすべてのデータは、 ステートフルなバックエンドサービスに格納しなければならない
21. VPC EC2 Instance Amazon RDS instance (スタンバイ) ALB AZ1 AZ2 EC2 Instance Amazon RDS instance (プライマリ) Amazon CloudWatch ログ / メトリクス Amazon CloudWatch User Amazon Route 53 - 10,000人 - 100人
22. 現在の構成における将来的な課題 VPC EC2 Instance Amazon RDS instance (スタンバイ) ALB AZ1 AZ2 EC2 Instance Amazon RDS instance (プライマリ) Amazon CloudWatch User Amazon Route 53 - 10,000人 - 100人 ログ / メトリクス
23. 現在の構成における将来的な課題 VPC EC2 Instance Amazon RDS instance (スタンバイ) ALB AZ1 AZ2 EC2 Instance Amazon RDS instance (プライマリ) Amazon CloudWatch 🔥 💰 User Amazon Route 53 - 10,000人 - 100人 ログ / メトリクス
24. 多数のユーザーが快適に利⽤できるよう 改善するフェーズ Web DB プライマリ/ スタンバイ ロード バランサ Web Web CDN オブジェクト ストレージ DB リード レプリカ - 1,000,000人 - 10,000人 - 100人 • ユーザーが数万⼈から数⼗万⼈に増加しても 安定したレイテンシでサービスを提供したい • 可⽤性 拡張性 • ⾃動化やコストの最適化 インメモリ キャッシュ
25. 静的コンテンツ配信部分をオフロード VPC EC2 Instance Amazon RDS instance (スタンバイ) ALB AZ1 AZ2 EC2 Instance Amazon RDS instance (プライマリ) CDN User Amazon Route 53 - 1,000,000人 - 10,000人 - 100人 オブジェクト ストレージ コンテンツの キャッシュ 安価で耐久性 が⾼いストレージ
26. Amazon CloudFront CDN導⼊の利点 • ユーザーを⼀番近いエッジロケーションに誘導することで 配信を⾼速化 • エッジサーバでコンテンツのキャッシングを⾏い オリジンの負荷をオフロード クライアント オリジン （配信元） Amazon CloudFront レスポンス向上 負荷軽減 CDN (Content Delivery Network) とは • ⼤容量キャパシティを持つ地理的に分散したサーバー群(エッジ)から コンテンツをキャッシュしたり代理配信をするサービス
27. Amazon S3 (Simple Storage Service) • データ保存・バックアップ⽤途に向くオブジェクトストレージ • S3⾃体に静的コンテンツ配信機能あり • ⾃動的に3箇所以上のAZに隔地保管 • データ耐久性は、99.999999999% • 容量無制限、サイジング不要 • REST APIを介してデータを操作 • 1プレフィックス辺り秒間5500回以上GETリクエストが可能 • 従量課⾦ 1GByteあたり⽉間 $0.0125~ • ⻑期アーカイブ⽤なら$0.00099〜 ※ 2020年6⽉時点での⽶国東部の⾦額
28. 静的コンテンツ配信部分をオフロード Amazon CloudFront S3 bucket User Amazon Route 53 - 1,000,000人 - 10,000人 - 100人 VPC EC2 Instance Amazon RDS instance (スタンバイ) ALB AZ1 AZ2 EC2 Instance Amazon RDS instance (プライマリ)
29. データベースへの読み込みクエリをオフロード VPC ALB AZ1 Instance Instance Instance Amazon RDS (リードレプリカ) Amazon CloudFront S3 bucket User Amazon Route 53 - 1,000,000人 - 10,000人 - 100人 Amazon RDS (プライマリ) ⾮同期 レプリケーション 読み込み専⽤ DBインスタンス 🔥
30. クラウド向けに再設計された MySQL, PostgreSQL と互換性のあるRDBMS コマーシャルデータベースの性能と可⽤性を1/10のコストで フルマネージド ハードウェアの⽤意、 ソフトウェアのパッチ適⽤、 セットアップ、構成、 バックアップといった 管理タスクからの解放 ⾼い安全性 ネットワーク分離、 保管時/通信の暗号化 優れた性能と拡張性 標準的なMySQLと⽐べて5倍、 標準的なPostgreSQLと⽐べて 3倍のスループットを実現; リードレプリカを最⼤ 15 個 追加してスケールアウト可能 耐障害性、⾃⼰修復機能を 兼ね備えたストレージ; 3 つのAZにわたり、6 個の コピーを保持; Amazon S3への継続的な バックアップ ⾼可⽤性と耐久性 Amazon Aurora
31. 頻繁に利⽤されるデータをキャッシュ VPC ALB AZ1 Instance Instance Instance Amazon RDS (リードレプリカ) Amazon CloudFront S3 bucket User Amazon Route 53 - 1,000,000人 - 10,000人 - 100人 Amazon RDS (プライマリ) インメモリ キャッシュ • ⾮常に⾼速なデータストア • メモリ上にデータを格納
32. Amazon ElastiCache • フルマネージド • インメモリキャッシュを数クリックで起動、実⾏、スケーリング可能 • 可⽤性を向上させる機能 （モニタリング、⾃動障害検出、復旧、拡張、パッチ適⽤、バックアップ） • ⾮常に⾼いパフォーマンス • ⾮常に⾼速な2種類のエンジン(Memcached, Redis)をサポート • ミリ秒未満の応答時間を実現 • AmazonによるRedisの機能拡張 • 主な⽤途 • キャッシュ、セッション管理、リアルタイム集計
33. 頻繁に利⽤されるデータをキャッシュ VPC ALB AZ1 Instance Instance Instance Amazon RDS (リードレプリカ) Amazon CloudFront S3 bucket User Amazon Route 53 - 1,000,000人 - 10,000人 - 100人 Amazon RDS (プライマリ) ElastiCache Redis
34. Auto Scaling コスト最適化 管理の⾃動化 Auto Scaling
35. インフラのコスト 時間 ビジネスの需要予測 Key: ビジネス需要に応じたキャパシティ準備
36. インフラのコスト 時間 確保されたリソース Key: ビジネス需要に応じたキャパシティ準備 ビジネスの需要予測
37. インフラのコスト 時間 確保されたリソース Key: ビジネス需要に応じたキャパシティ準備 実際の需要
38. コストの 無駄 Key: ビジネス需要に応じたキャパシティ準備 機会損失 インフラのコスト 時間 確保されたリソース 実際の需要
39. 実際のAWSリソース ビジネス需要に応じたキャパシティ準備 Auto Scalingサービス群により 実際の需要に合わせたオートスケールが可能 • 確保しすぎることによる無駄を極小化 • 機会損失を極小化 インフラのコスト 時間 Key: 実際の需要
40. VPC Instance Amazon RDS (スタンバイ) ALB AZ1 AZ2 Instance Amazon RDS (プライマリ) Instance Instance Instance Instance Amazon RDS (リードレプリカ) Amazon RDS (リードレプリカ) Amazon CloudFront S3 bucket ElastiCache Auto Scaling group ここまでの振り返り User Amazon Route 53 - 1,000,000人 - 10,000人 - 100人 ElastiCache
41. ここまでの振り返り（補⾜） • 想定される課題に応じて、各コンポーネントの導⼊順序は変わりうる • 次のフェーズでのコンポーネントの導⼊を⾒越したアプリケーションの 設計にできると望ましい • 負荷テストを⼗分に⾏うことが⼤切 • AWSのサービス上限にも注意し、AWSサポートに上限緩和を申請 - 1,000,000人 - 10,000人 - 100人
42. VPC ALB AZ1 Instance Instance Instance Amazon CloudFront S3 bucket 現在の構成における将来的な課題 Auto Scaling Group User Amazon Route 53 Amazon RDS (プライマリ) Amazon RDS (リードレプリカ) ElastiCache 🔥 - 1,000,000人 - 10,000人 - 100人
43. 更に意識して計測・分析・改善の サイクルを回すフェーズ それ以上 - 1,000,000人 - 10,000人 - 100人 • ユーザーが数百万⼈以上に増加しても 安定したレイテンシでサービスを提供したい • 可⽤性 拡張性 • ⾃動化やコストの最適化 • 組織 運⽤
44. 具体的な改善の例 アプリケーションパフォーマンスの改善のために - アプリケーションのプロファイリングの実施や、メトリクス・ログを詳細に出⼒し分析 - アプリケーションロジックやSQLの改善 - 様々なレイヤーでのキャッシュの利⽤ - ⾮同期処理化 RDSプライマリインスタンスへの負荷集中対策のために - DBのシャーディング - NoSQLの利⽤ 運⽤の改善のために - 様々なレイヤーでマネージドサービスを活⽤し、可⽤性やスケーラビリティを担保 - サービスをモジュール、コンポーネント、マイクロサービスなどの単位で分割 - 運⽤オペレーションの⾃動化 - Infrastructure as CodeやCI/CDの導⼊
45. 具体的な改善の例 アプリケーションパフォーマンスの改善のために - アプリケーションのプロファイリングの実施や、メトリクス・ログを詳細に出⼒し分析 - アプリケーションロジックやSQLの改善 - 様々なレイヤーでのキャッシュの利⽤ - ⾮同期処理化 RDSプライマリインスタンスへの負荷集中対策のために - DBのシャーディング - NoSQLの利⽤ 運⽤の改善のために - 様々なレイヤーでマネージドサービスを活⽤し、可⽤性やスケーラビリティを担保 - サービスをモジュール、コンポーネント、マイクロサービスなどの単位で分割 - 運⽤オペレーションの⾃動化 - Infrastructure as CodeやCI/CDの導⼊
46. RDSにおけるDBの分割⽅法 Forum DB User DB Product DB C B A User ShardID 002345 A 002346 B 002347 C 002348 B 002349 A
47. Amazon DynamoDB • 完全マネージド型の NoSQL データベースサービス • 3つのAZを利⽤した⾼い可⽤性と堅牢性 • 必要な分だけのスループットを確保可能 • パッチ適⽤やアップグレードなどの運⽤管理の必要なし • ストレージの容量制限が無い
48. 具体的な改善の例 アプリケーションパフォーマンスの改善のために - アプリケーションのプロファイリングの実施や、メトリクス・ログを詳細に出⼒し分析 - アプリケーションロジックやSQLの改善 - 様々なレイヤーでのキャッシュの利⽤ - ⾮同期処理化 RDSプライマリインスタンスへの負荷集中対策のために - DBのシャーディング - NoSQLの利⽤ 運⽤の改善のために - 様々なレイヤーでマネージドサービスを活⽤し、可⽤性やスケーラビリティを担保 - サービスをモジュール、コンポーネント、マイクロサービスなどの単位で分割 - 運⽤オペレーションの⾃動化 - Infrastructure as CodeやCI/CDの導⼊
49. モダンなソフトウェア開発におけるCI/CD AWS CodeBuild + サードパーティー AWS CodeCommit AWS CodeBuild AWS CodeDeploy AWS X-Ray AWS CodePipeline モニター デプロイ テスト ビルド コード管理 開発 AWS Cloud9 AWS IDE toolkits Amazon CloudWatch AWS CloudFormation AWS SAM AWS Cloud Development Kit インフラの コード化 Amazon CodeGuru
50. 具体的な改善の例 アプリケーションパフォーマンスの改善のために - アプリケーションのプロファイリングの実施や、メトリクス・ログを詳細に出⼒し分析 - アプリケーションロジックやSQLの改善 - 様々なレイヤーでのキャッシュの利⽤ - ⾮同期処理化 RDSプライマリインスタンスへの負荷集中対策のために - DBのシャーディング - NoSQLの利⽤ 運⽤の改善のために - 様々なレイヤーでマネージドサービスを活⽤し、可⽤性やスケーラビリティを担保 - サービスをモジュール、コンポーネント、マイクロサービスなどの単位で分割 - 運⽤オペレーションの⾃動化 - Infrastructure as CodeやCI/CDの導⼊
51. Amazon Builder’s Libraryもぜひご覧ください
52. • AWSでWebサービスを構築する場合、フェーズごとに どのAWSサービスを組み合わせて設計するとよいのかを学ぶ • システムをスケールさせていく上で意識すべきポイントを知り、 ⼀般的な対策を学ぶ • 最初から過度に作り込みすぎず、要件を⼗分満たすことのできる シンプルな設計を検討する • 計測・分析・改善のサイクルを回し続ける
53. 関連セッションのご案内 AWS-01 今だからこそ知りたい、AWSのデータベース 2020 基礎 AWS-04 30分で理解するAWSストレージサービスの全体像 AWS-15 クラウドへのシステム移⾏戦略 Lift & Shift とクラウドネイティブ AWS-21 モダンアプリケーションのためのアーキテクチャデザインパターンと実装
54. Thank you! © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
55. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
56. 開発を⽀援するサービスの⼀覧 CI/CD tools Monitoring & tracing SDKs IDE IDE and DevOps toolkits CLI and scripting tools Web apps Mobile Languages Infrastructure as code AWS CodeStar AWS CodePipeline AWS CodeBuild AWS CodeCommit AWS CodeDeploy AWS CloudFormation AWS CDK AWS Cloud9 AWS X-Ray Amazon CloudWatch AWS Elastic Beanstalk AWS Amplify Amazon Corretto