[レポート] はじめての1000万人ユーザーに向けてのスケーリングアップ #reinvent

re:Invent2019のセッション、「ARC211-R - [REPEAT] Scaling up to your first 10 million users」のレポートです。
2019.12.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。AWS事業本部のShirotaです。

いつもの挨拶を省いてお届けしているのは、re:Invent2019のセッションレポートについて速攻でお届けしようと思っているからです!
今回はセッション、「Scaling up to your first 10 million users」についての内容をお届けしたいと思います。

それでは早速行ってみましょう!

セッション情報

セッション名

ARC211-R - [REPEAT] Scaling up to your first 10 million users

セッションの概要

Cloud computing gives you a number of advantages, such as the ability to scale your web application or website on demand. If you have a new web application and want to use cloud computing, you might be asking yourself, “Where do I start?” Join us in this session to understand best practices for scaling your resources from one user to millions of users. We show you how to best combine different AWS services, how to make smarter decisions for architecting your application, and how to scale your infrastructure and serverless components in the cloud.

このセッションで、1000万人ものユーザーが使うアーキテクチャを構築する場合、「じゃあ何から始めよう?」という悩みに対するベストプラクティスを学べるそうです。

スピーカー

  • Brian Farnhill - Solution Architect, Amazon Web Services
  • Hong Pham - Solutions Architect, Amazon Web Services

セッションの内容

まずはBrian Farnhillさんのトークで開始。

  • 実際にどれだけのユーザーが使っているシステムに携わっているかをオーディエンスに聞く
    • 少数だが今回の目標の1000万人のユーザーが使っているシステムに携わったことのある人がいた!
  • AWSのインフラストラクチャは全世界で提供されている
    • 22の地理的リージョン
    • 69のアベイラリティゾーン
    • 187のPoP(Points of Presence)
  • AWSのサービス紹介
    • 青文字はスケーラビリティ、高可用性、フォールトトレラントなサービス
    • 赤文字はスケーラビリティ、高可用性

▲ こうやってみるとサービス豊富です

  • システムは構築、測定、学習で育てて行くもの
  • スケーリングするシステムについて考える際に出てくる3つの教義
    • 価値をとどけない無駄な作業を識別して、避ける
    • サーバレスvsマネージドvs自力での運用
    • セキュリティファースト

ユーザーが1人以上のシステムを作ろう

  • まずはAmazon Lightsailで手軽に始める
  • データベースはどうする?
    • EC2だと自分で管理する
    • フルマネージドならRDS,DynamoDB,Neptuneなどがある
    • Auroraの紹介
      • DBエンジンはMySQLかPostgresSQLが選べる
      • 自動ストレージスケーリング(最大64TBまで)
      • 最大15のRR
      • S3への連続的なバックアップ
      • 6つの手段でストレージを3つのアベイラビリティーゾーンに自動的にレプリケート
      • サーバレスオプションがある
        • Aurora serverless
    • NoSQLにするか、SQLにするか
      • 初めはSQLで
        • 初めて100万人のユーザーが利用するデータベースならSQLにしておく方がいい
      • NoSQLが必要になる時
        • 1年間に5TB以上使うならSQL
        • 非常に強いデータのワークロードが必要な場合
      • NoSQLを使いたくなるのはどんな時か
        • アプリケーションでとても低レイテンシーが必要
        • メタデータ駆動のデータセット
        • ノンリレーショナルデータを扱う
        • スキーマレスのデータを構築する場合
    • レジストレーションやサインインといったものが必要になって来たら
      • Cognitoが使い易い

ユーザーが100人以上になったら

  • インスタンスのサイズアップ、スケーリングを考える
  • インスタンスを大きくするということ
    • 一番シンプルなアプローチ
    • PIOPSやI/O、メモリ、CPU、ストレージ全てを大きくできる

ユーザーが1000人以上になったら

  • 負荷分散を考える
    • ALB,NLB,CLB
    • オススメはALB
      • 高可用性
      • ヘルスチェック
      • スティッキーセッション
      • コンテンツベースなルーティング
      • コンテナベースのAPPも扱える

ユーザーが10000人以上になったら

  • ある程度のロードをシフトして行く
    • CloudFront+S3を追加
      • S3
      • CloudFront
      • CloudFrontがある時とない時のレスポンスタイムの比較

▲ 比較を実際に見ると分かり易い

  • 更にロードをシフトしていく
    • ElasticCacheを追加
  • もう一声追加
    • DynamoDB
      • マネージドなNoSQLデータベース
      • グローバルテーブル

ここで話者交代。 Hong Phamさんが話します。

  • AutoScalingについて
  • Amazon.comのトラフィックを見てみよう
    • 普段はプロビジョンドで何とかなるトラフィック
      • 普段は24パーセント、11月末は70パーセント超えに!

ユーザーが500,000人以上になったら

  • Auto Scalingを使おう
  • 自動化を使おう
    • AWS Systems Managerは自動でオペレーションタスクをやってくれる
      • オンプレもクラウドも
      • Parameter Store
  • AWSのインフラストラクチャの自動化の粒度について
    • 手動の度合いが強いけどコントロールがし易いサービス
    • EC2
    • ECS,EKS
    • OpsWorks
    • コード化(IaC)
      • CloudFormation
      • AWS CDK
    • ハイレベルだけど便利なサービス
    • Elastic Beanstalk
    • Fargate

▲ どのサービスがどのような立ち位置なのか分かりやすい

  • デプロイ周りのサービス
    • AWSのコードサービスの紹介
    • AWS CodeStar
  • モニタリングして解析して行く事が大事になる
    • Amazon CloudWatch
      • メトリクスやログを収集
    • Amazon CloudWatch Logs insights

Web/Appのレイヤーにも踏み込んで行く

  • モノリシックなアーキテクチャ
    • SOA
    • モダンなアーキテクチャに移行して行く
      • ECS,EKS,Batchといったコンテナを利用したサービス
      • Lambda function
    • 再開発しなくてもサーバレスに移行できる!
    • 拡張性はSQSとSNSで
    • イベント駆動のコンピューティングはLambdaで
      • 拡張性を上げて行くと自由になって行く
    • サーバレスなWebアプリケーション
    • 様々なAPIゲートウェイ
  • マイクロサービスなアーキテクチャ
    • API Gateway,Lambda,コンテナ等を使って行く
    • AWS X-Rayの紹介
      • サービスにおけるパフォーマンスのボトルネックやエラーを調べられる

ユーザーが100万人以上になったら

▲ コメントを書く

ユーザーが500万、1000万人になってきたら

  • データベースをどうするか
    • 水平にスケーリングする
      • アプリケーションレイヤーがより複雑に
      • 拡張性の実用限界がなくなる
      • RDBMSを使うかNoSQLを使うか
    • NoSQLへの移行
      • リーダーボード
      • 一時的なデータの保存(ECサイトのカートのデータなど)
      • "ホット"なテーブル

話者交代。Brian Farnhillさんが50分間のまとめをします。

サクッと今回のセッションのまとめ

  • インフラストラクチャはマルチAZにする
  • 自分でスケーリングしてくれるサービスを使おう
    • ALB,S3,Lambda,SNS,SQS,Step Functionなど
  • どの段階でもそれぞれの冗長性を確保しよう
  • SQLで始める( マジな話 )
  • キャッシュデータをインフラストラクチャの外部、内部両方に
  • インフラストラクチャの自動化ツールを使おう
  • メトリクスや監視、ログ収集をやる事でいい状態を保てるようになる
  • 使う準備が整ったならオートスケーリングを使う
  • Service Oriented Architectureを実現しよう
  • わざわざ1からやり直すことはやめよう

ユーザーが1000万人以上になってきたら……

  • 1000万人を目指す時にやってきた事をより拡張させて推進して行く

セッションを受けてみてのまとめ

いきなり1000万人へのスケーリングを目指すのではなく、それぞれの段階で必要となる物をAWSのサービスなどを使い導入してく事で、最終的には求めていた大人数が使うサービスが構築できるんだという考え方がとても分かりやすく解説されていました。
よく見るマイクロサービスなアーキテクチャに辿り着くまでの道程を知る事が出来て満足です!

また、今までイメージがつきづらかった大人数が利用するサービスのアーキテクチャに向き合う上での考え方を学べたので、今一度今回のセッションについて見直して学んでいきたいと思います。