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

どうも、もこ@札幌オフィスです。

今年はAWS Summit Onlineという事で、2020/9/8〜9/9の間のライブセッションと、09/30まで視聴可能なAWS認定セッション、お客様事例セッション、 セルフペースハンズオン、Partner Discovery Session (パートナーセッション) などなど、場所を選ばずにオンラインで、好きな時に好きなだけ学べるような環境になっています。

本記事ではライブセッション Day1 Track4 12:30〜13:00の「1人から1000万人までの道のり： AWS におけるスケールするインフラ設計とは？」のセッションレポートとなります。

セッション情報

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

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 インターネットメディアソリューション部 ソリューションアーキテクト 石見 和也

AWS を利用した Web アプリケーションを構築する時、あなたはどのようなアーキテクチャから始めますか？本セッションでは、ユーザーが 1 人から 1000 万人に拡大する中で、 フェーズごとにどの AWS サービスを組み合わせて利用すると良いのか、スケールするインフラ設計を行う際に意識すべきポイントは何なのかといったベストプラクティスをご紹介します。

レポート

• フェーズや目的によって目指すべきアーキテクチャは異なる
  • フェーズごとにどのAWSサービスを組み合わせて設計するとよいのかを学ぶ
  • システムをスケールさせていくとどのような課題が発生しうるのかを学んで対策を学ぶ

フェーズ1、〜100人規模 / 社内向け

• シンプルで安価な構成にしたい
  • 可用性や拡張性は求められていない

• ElasticIP / EC2 / RDS構成
• DNSはAmazon Route 53を利用

• 将来的な課題

  • 単一障害点が複数存在して可用性に課題がある

フェーズ2、〜10,000人規模 / サービスを一般公開するフェーズ

• 複数アベイラビリティーゾーンを利用した単一障害点の無い構成を目指す
• アベイラビリティーゾーンとは、一つのデータセンターの事

• 二つ以上のアベイラビリティーゾーンを使うことによって、一つのデータセンターで障害が起きてもサービスを継続できるようにする

• 一台のサーバーのスペックを上げるだけでは限界がある
• スケールアップはサーバー一台あたりのリソースを強化する事

• Application Load Balancerを利用して複数のアベイラビリティーゾーンに展開
• EC2も複数アベイラビリティーゾーンで起動して、Application Load Balancerに紐付ける
• EC2はステートレスであることが大切
  • セッション情報や、アプリケーションのログなどをステートレスにする必要がある
  • セッション情報をRDSに含めたり、ログをCloudWatch Logsに送信するようにする

フェーズ3、〜1,000,000人規模 / 多数のユーザーが最適に利用出来るよう改善するフェーズ

• ユーザー増加に伴いサーバー台数が増加
• 可用性や拡張性が求められる
• 自動化やコスト最適化が求められる

• 画像などの静的ファイルをEC2からオフロードする
  • CDNを利用する事で、前段でキャッシュすることが出来る
  • オブジェクトストレージを利用する事を検討
• Amazon CloudFront
  • 地理的に分散したサーバー群(エッジロケーション)からコンテンツをキャッシュしたり、代理配信するサービス
  • ユーザーから一番近いエッジロケーションを利用するため高速にレスポンス
  • キャッシュを活用することによりOriginの負荷を下げれる
• Amazon S3
  • オブジェクトストレージ
  • CloudFrontが参照する先とする
• CloudFront + S3を利用する事で静的コンテンツのリクエストをオフロードして、EC2の負荷を下げてコスト削減

• データベースの読み込みクエリーをオフロード
• Amazon Aurora
  • MySQL/PostgreSQL互換のRDBMS
  • クラウド向けに再設計されたデータベースエンジン

• 頻繁に使用されるデータをキャッシュする
  • インメモリキャッシュサービスAmazon ElastiCacheを利用する
  • Memcached/Redisのマネージドサービス
  • 簡単に構築、スケーリング、バックアップも容易
  • キャッシュ、セッション管理、リアルタイム集計などの用途に
• 確保したリソースと実際の需要が乖離していると「コストの無駄・機会損失」が発生する。

• AutoScalingを利用する事で、需要に応じたスケーリングをすることが可能

• これまでの振り返り
  • 一般的な大規模サービスのモダンな構成
    • MultiAZ
    • ALB
    • CloudFront+S3の静的ファイル配信
    • RDS リードレプリカ
    • ElastiCache
    • AutoScaling
• 事前に本番相当の負荷テストを行うことが大切
• AWSのサービス上限にも注意して、必要に応じて上限緩和申請を行う

さらに意識して計測・分析・改善のサイクルを回すphase

• ログ分析をして課題の分析を行って、対策を行う必要がある
• アプリケーションパフォーマンスの改善のために
  • アプリケーションのプロファイリング実施や、メトリクス・ログを詳細に出力して分析
  • アプリケーションロジックやSQLの改善
  • 様々なレイヤーでのキャッシュ利用
  • 非同期処理化
• RDSプライマリインスタンスへの負荷集中対策のために
  • DBのシャーディング
  • NoSQLの利用
• 運用の改善のために
  • 様々なレイヤーでマネージドサービスを活用し、可用性やスケーラビリティなどの単位で分割
  • サービスをモジュール、コンポーネント、マイクロサービスなどの単位で分割
  • 運用オペレーションの自動化
  • Infrastructure as CodeやCI/CDの導入
• まとめ
  • ユーザーの増加に伴ってスケーリングするようにする
  • 完璧なベストプラクティスがあるわけでは無い
  • 将来的にどのようにするのかを意識する必要があるけど、最初から作り込みすぎないで、シンプルな設計を検討する。