[レポート] 1000万ユーザーのためのAWSクラウドアーキテクチャの進化#AWSSummitOnlineKorea

こんにちは！新卒エンジニアのハウンです?

AWS Summit Online Koreaが開催されたことで、韓国語のセッションレポートを投稿しました！日本の方々ともセッションの内容を共有できたらなと思い、日本語のレポートも残しておきます。

今回の記事は模範事例の「1000万ユーザーのためのAWSクラウドアーキテクチャの進化」セッションについてまとめます。

※ 本記事で使用されているアーキテクチャ図は登壇資料をもとに修正されたものです。

登壇者紹介

Jongmin Moon

• Solutions Architect
• AWS Korea

AWSグローバルインフラストラクチャーとサービス

• AWSは全世界22箇所のリージョンを運営
• 各リージョンごとに2つ以上のアベイラビリティゾーンを持っているので、他のサービスより可用性が高い
• リージョンと216のPoP(205のエッジローケーション, 11のリージョン別エッジキャッシュ)はバックボーンネットワークで繋がれているのでレイテンシが小さい
• コンピューティング、ストレージ、ネットワーク、データベースのような中心分野だけではなく、機械学習やビッグデータ、IoT、DevOps、モバイル、オンプレミスとクラウドのハイブリッドサービス、セキュリティサービスなど175種類以上のサービスを提供

ユーザー増加によるアーキテクチャの進化

このパートではユーザー規模に合わせたアーキテクチャ設計と使用されるAWSサービスについて説明してくださいました！

ユーザー数 < 1,000

• サーバー選定 → EC2
  • 業務に相応しい、必要となる性能(IOPS)に合ったストレージ選択
  • オンプレミスと違い、インスタンスタイプの変更がしやすいため予め容量算定をしなくてもOK
  • 241種類のインスタンスタイプで主なワークロードおよびビジネス要求事項に適用可能

• サーバー二重化構成 → VPC
  • リージョン内の異なるアベイラビリティゾーンにインスタンスを生成することで可用性を確保

• 負荷分散 → AWS Elastic Load Balancing(ELB)

※ ALB VS NLB

高可用性、自動拡張をしてくれるという点は共通だが、ALBはHTTP/HTTPSを支援、コンテンツベースルーティングをサポートしている。NLBはTCP/UDP/TLSを支援、固定IPでドメインが使用できない時に有効

• DB構成 → Amazon RDS
  • Amazon Aurora, MySQL, PostgreSQL, MariaDB, SQL Server, ORACLEの中から選んだDBを自動的にインストール

※ Amazon Aurora

• MySQL, PostgreSQL 互換
• 3つのアベイラビリティゾーンに６個のデータコピー保持、最大15個のリードレプリカ設定可能
• ストレージ自動拡張および、バックアップ

• ユーザー管理機能構築 → Amazon Cognito
  • UI 内蔵
  • Google, Facebookなどのアカウントとの連携可能

• ソースコード管理 → AWS Code サービス
  • AWS Cloud9 : 開発
  • AWS CodeCommit : 構成管理
  • AWS CodeBuild : ビルド
  • Third-party tooling : テスト
  • AWS CodeDeploy : リリース
  • AWS CodePipeline : 上記の過程を総合

ユーザー数 > 1,000

• システム拡張 → EC2 Auto Scaling
  • 接続数が急増していまう場合に備え、ルールを決めておくとEC2の数を自動調整
  • 最小数量を設定しておくと、特定の臨界値に達した場合に設定した数だけEC2起動

• DB可用性確保 → Amazon RDS マルチ AZ 配置
  • 一つのアベイラビリティゾーンにMaster(プライマリ)、 別のアベイラビリティゾーンにStand by生成
  • MasterのデータをStand byにコピー後、同期
  • Masterに障害が発生した際、Stand byをMasterに自動昇格

• バックアップ管理 → AWS Backup
  • バックアップデータの保存管理ポリシーを設定すると自動的にバックアップ
  • AWS Storage Gatewayサービスと一緒に使う際、オンプレミスデータをAWSにバックアップ
  • バックアップデータの暗号化

• モニタリング → CloudWatch
  • AWSサービス別メトリクス(指標)データ収集
  • 条件に沿ってAlarmを実行
  • 複数のリージョンにかけて構成されたリソースをDashboardを通じて総合ビューを確認

ユーザー数 > 10,000

• 性能向上 → Amazon CloudFront

• • ユーザーがリソースアクセス要請をした際、まずユーザーと一番近いPoPに伝達
  • キャッシュに保存しておくことで、同じリソースアクセス要請が来た場合にキャッシュデータで応答
  • オリジン側の負荷減少および、エンドユーザーのレイテンシ低下

• 負荷分散 → RDS

※ Amazon Aurora リードレプリカ Auto Scaling

• リードレプリカを使用して平均CPU使用率、平均コネクション数に応じてAuto Scalingされるように構成
• シングルリーダーエンドポイントとして提供されるためリードレプリカが複数でも分散アプリケーションに関する問題を解決

• Amazon ElastiCache

• • キャッシュクラスタを簡単に構成できるようにしてくれるサービス
  • 1ミリ秒未満の応答速度と様々なUsecaseで活用できるという利点がある
  • 頻繁にアクセスするデータの場合、DBよりキャッシュサーバーを構成してより速い応答が必要
  • EC2 Auto Scalingを適用する場合、HTTPセッションテーブルを各EC2メモリーに保存するよりはキャッシュサーバーを別に構成したほうがいい

ユーザー数 > 100,000

• Loosely Coupled → Amazon SQS, Amazon SNS
  • SQSはプロデューサーがメッセージをqueueに送信しておくと、コンシューマーがPull方式で読み込むサービス
  • SNSはプロデューサーがtopicにメッセージを送信しておくと、そのtopicのコンシューマーがPush方式で受信

• サーバーレス、イベントドリブンアーキテクチャ → AWS Lambda
  • サーバーを予めプロビジョニングしておいたり、管理しておかなくてもリクエストに応じてリソースを自動的にスケーリング

• 分散アーキテクチャ

• • 用途に合ったDBサービスを使用
  • 特定のデータをData warehouseに入れて分析する必要がある場合、サーバー Aにputしておくと、サーバー Bから取り出しRedshiftに投入 → Amazon Redshift
  • ユーザーがDynamoDBからデータを照会する場合、API Gatewayにリクエストし、Lambdaで分散処理

• 分散システムのモニタリング → AWS X-Ray 
  • 分散アプリケーションの分析、デバッグ
  • リクエストがアプリケーションを通過した過程を追跡して、サービス全体のマップを提供
  • ユーザーは収集されたデータにより、どこでボトルネックが発生しているか確認

ユーザー数 > 1,000,000

• マルチリージョンシステムを考慮 → CloudFormation
  • 別のリージョンに同じシステムを構成したりアーキテクチャが変更される度に、開発やテスト、運営のシステムを一々修正することなくコードを作成しておいて管理

• 災害復旧 → S3, RDS Snapshot, DynamoDB, ElastiCache
  • リソースが生成された際に、別リージョンにコピー

• マルチリージョンシステム配置 → CodePipeline, Route 53
  • CodePipelineとDeployで配置対象のリージョンを複数追加してリリース可能
  • Route 53で障害対策のルーティングポリシーを構成したり、ユーザーのロケーションに合わせたルーティング構成が可能

ユーザー数 > 10,000,000

• グローバルシステム拡張およびマルチリージョンサービス拡大 → Aurora, DynamoDB, ElastiCache
  • 短いコピー時間でリージョン間データコピー
  • 別のリージョンでread-write昇格可能

Review

• サーバー構成時に、マルチ‐AZを活用した二重化構成
• リクエストに弾力的に対応するためのEC2 Auto Scaling
• 性能向上と負荷分散のためのキャッシュ構成
• 各サービス別メトリクスモニタリング
• ユーザーが直接に環境を構築するより、AWSサービスを活用
• 用途に適したデータベース使用
• システム間の疎結合のためアプリケーションの構造を変更
• グローバルインフラストラクチャーをもとに進化