Scaling on AWS - Feb 2016

Scaling on AWS#AWSStartupJP

Amazon Web Services Japan 篠原英治2016年2⽉

{"Name" : ”Eiji Shinohara","Twitter" : "@shinodogg","Blog" : "http://shinodogg.com","Profile" : {

"Role" : "Solutions Architect","Market": "Startup&AdTech","Subject Matter Expert" : [

"Amazon CloudSearch","Amazon Elasticsearch Service","Amazon Simple Workflow Service","AWS Elastic Beanstalk"

]}

}

#AWSStartupJP

Agenda• A Primer : ⼊⾨• > 10K Users : ユーザー数1万⼈以上• > 500K Users : ユーザー数50万⼈以上• > One Million Users : ユーザー数100万⼈以上

Scaling on AWS

A Primer : ⼊⾨

• Why AWS– スケールするインフラストラクチャを⾃前で⽤意する？

• ピークのキャパシティを⾒積もり(サービスをはじめる前から…？)、• 機器の到着を待ち、• ハードウェアとソフトウェアのセットアップを⾏い、• 全てが正しく稼働することを祈る…。

– Cloudを使えば上記のような頭の痛いことが全て解決できる？– AWSを使って下記のようにスケールさせてゆく様⼦をみていきます

• ⽴ち上げ期• ユーザー数1万⼈以上• ユーザー数50万⼈以上• ユーザー数100万⼈以上

A Primer : ⼊⾨• AWSとは？

– Region• 現在世界中にリージョン• 活発に拡⼤中。丸数字はAvailability Zone(≒データセンター)の数


– Availability Zone(≒データセンター)• リージョン内のAvailability Zoneは異なる電⼒系統で、断層線や氾

濫原が異なる• リージョン内の他のAvailability Zoneに対してsingle digit

millisecondで通信可能


– AWSプラットフォームのOverview• 2006年から成⻑を続け幅広いカテゴリをカバー

AWSの豊富なサービスお客様のアプリケーション

モバイルサービスMobile Analytics, Cognito, SNS

コンテンツ配信CloudFront

ネットワークVPC, Route 53, Direct Connect

認証とログIAM, Cloud Trail,

Cloud HSM,Config

モニタリングCloud Watch,

Trusted Advisor

デプロイと⾃動化Elastic Beanstalk,Cloud Formation,

OpsWorks

管理インターフェイス

ManagementConsole, CLI

ライブラリ & SDKsJava, PHP, .NET,

Python, Ruby

グローバルインフラリージョン、アベイラビリティゾーン、エッジロケーションAZRegio

n

コンピュート処理EC2, Auto Scaling, Elastic, Load Balancing, LambdaEC2 Container Service

アプリケーションWorkSpaces, WorkDoc, WorkMail

ストレージEBS, S3, Glacier, Storage Gateway

データベースRDS, DynamoDB, Redshift,

ElastiCache

分析Elastic MapReduce,

Kinesis, Data Pipeline, Machine Learning

アプリケーションサービスAppStream, Cloud Search, SWF,

SQS, SES, Elastic Transcoder

ディレクトリDirectoryService

コード管理CodeDeploy,CodeCommit,CodePipeline

A Primer : ⼊⾨• 例えば、、(全部50以上あるのでその中の⼀部)

– 仮想サーバーのアナロジー: Amazon EC2– AWSリソースをセキュアに管理: AWS IAM– お客さま独⾃のネットワークトポロジ: Amazon VPC– リレーショナル・データベース: Amazon RDS– フルマネージドなキーバリューストア: Amazon DynamoDB– 安価で⾼速データウエアサービス: Amazon Redshift– ビッグデータ分析: Amazon Elastic MapReduce– 機械学習: Amazon Machine Learning

• Plug and Play形式で簡単に利⽤開始– 使った分だけの従量課⾦モデル(スモールスタートに最適)

A Primer : ⼊⾨• Day1, ユーザー1⼈

– まずは1つのインスタンスの中にシンプルなアプリケーションの構築– Amazon machine Image(AMI)を使う

• よくあるテクノロジースタックを提供• Marketplaceには沢⼭のカスタムAMIがあります

– 例えばBitnamiのLAMPスタック(Linux, Apache MySQL, PHP)

A Primer : ⼊⾨• Day1, ユーザー1⼈

– VPC(セキュアな仮想ネットワーク)内にEC2インスタンスを⽴てる• インターネットからは、Route 53を使って名前解決をして、Internet

Gateway経由でPublic Subnetの中のEC2にアクセス– 専⾨⽤語は追ってご説明します

A Primer : ⼊⾨• ⽤語集

– Amazon Elastic Compute Cloud (Amazon EC2)• 様々なワークロードのニーズに対応するため、様々なインスタンスタイプを取り揃えています

(CPU, メモリ, ストレージ, ネットワーク)。ワークロードリソースのニーズは、モニタリングを通して、より良いパフォーマンスやコスト効率追求への機会を導き出すことができます。

– Amazon Virtual Private Cloud (Amazon VPC)• お客さま専⽤の仮想ネットワーク。IPアドレスレンジ、サブネット、そしてルーティングルール

を完全にコントロールすることができます。– VPC Subnet

• VPC内のIPアドレスレンジ。Public Subnetの仮想ホストはインターネットからvisibleになります。サブネットをPublicにするにはルーティングルールを作成し、インターネットバウンドなトラフィックをインターネットゲートウェイに向かうように設定します。

– Amazon Route53• ⾼い可⽤性をもつ、スケーラブルなクラウドDomain Name System(DNS)サービス。極めて信

頼性が⾼くコスト効率の良い⽅法でユーザーとインターネットアプリケーションのルーティング(例: www.example.com を 192.0.2.1 といったIPアドレスに変換し、接続できるようにする)が⾏われるようにデザインされています。

A Primer : ⼊⾨• Day2, ユーザー1⼈以上

– Day1で1インスタンスで構築したアーキテクチャのスケール• より⼤きなインスタンスにする• EC2には244GBのRAM、40仮想CPUコアをもつようなインスタンスも• 例えばAmazon EBS(Elastic Block Store)をroot volumeとして使えば、

以下の流れで数分で作業は終了する1. EC2インスタンスを⽌める2. インスタンスタイプをより⼤きいものに変える3. インスタンスを再スタートさせる

• 但し、– 垂直スケール(インスタンスタイプを⼤きく)はいつか頭打ちになる– 1インスタンスしかない⇒冗⻑性がない– 1つのAvailability Zoneにのみ存在⇒単⼀のロケーションと運命を共に

することになってしまう


– 垂直スケール問題の解決• アプリケーションを分散できるように、データベースとアプリケー

ションのEC2インスタンスを分離する


– ロードバランサ(Elastic Load Balancing: ELB)を使って複数Availability Zoneに配置されたアプリケーション⽤のEC2インスタンスに負荷分散

• データベースはインターネットから直接アクセスする必要ないのでPrivate

> 10K Users : ユーザー数1万⼈以上• AWSでのデータベースオプション

– 今のままではデータベースがSPOF(Single Point Of Failure)– AWSには様々なデータベースのオプションがあります

> 10K Users : ユーザー数1万⼈以上• Amazon RDS

– データベース管理はAWSが⾃動的な夜間バックアップやソフトウェアのアップデートなどを⾏う。異なるAvailability Zoneへのシームレスなフェールオーバーなどをサポート。エンジニアリソースは限られているのでご利⽤いただくことをオススメしています。MySQL, PostgreSQL, Maria DB, SQL Server, Aurora, Oracleといったデータベースをサポート

• Amazon DynamoDB– ⾼速でフレキシブルなNoSQLデータベース。どのようなデータスケールに

おいても、⼀貫性やミリ秒レベルのレイテンシを確保するアプリケーションに向いている。フルマネージドなCloudデータベースでありDocumentおよびKeyValueの両⽅のモデルをサポート

• Amazon EC2– もしAWSが提供していないデータベースエンジンを利⽤する必要があった

り、全ての権限が必要な場合はEC2上にご⾃⾝でデータベースを構築することも可能です。

> 10K Users : ユーザー数1万⼈以上• SQL vs NoSQL

– SQL• 確⽴したテクノロジを利⽤したい場合。既存のコード/コミュニティ/事

例/スケールの確⽴されたパターンの価値を活かしたい場合• ⼤量のデータを扱うわけではない場合。ここでいう⼤量とは最初の1年

でテラバイト級のデータが発⽣するようなもの– NoSQL

• Non-Relationalなデータを⼤量に保持する必要がある場合– テラバイト級の⼤量データを扱うのであれば、NoSQLは⽔平に分

散してスケールさせやすい• 秒間数千〜数万といった⾼速なデータ登録を⾏う必要がある場合

– シンプルなデータ構造のためNoSQLでーたは登録や削除を素早く実⾏可能

• 次のセクションではAmazon RDS(SQLテクノロジ)で進めていきます

> 10K Users : ユーザー数1万⼈以上• テッパンな基本構成！

– ELB + EC2 + RDS on Multi AZ

EC2

RDSAvailability Zone

Web

WebEC2

RDSAvailability Zone

WebELB

BASE https://thebase.in/


EC2 EC2

RDS(Active

)

DB

ELB

AZ① AZ②

RDS(Standby)

ElastiCache S3

CloudFront


EC2 EC2

RDS(Active

)

DB

ELB

AZ① AZ②

RDS(Standby)

ElastiCache S3

CloudFront

> 10K Users : ユーザー数1万⼈以上• Day1のアーキテクチャの問題点

– 冗⻑性の不⾜– アプリケーションのSingle Availability Zoneへの配置

• 複数のAvailability Zoneを利⽤することでの解決– EC2インスタンスを複数のAZに配置し、トラフィックをElastic Load Balancing(ELB)で負荷分散

• ELBは冗⻑性を持ち、⽔平スケールするサービスで管理作業は不要• SSLターミネーションをサポートし、Sticky Session機能も保持• ELBはヘルスチェックを⾏いhealthyなインスタンスのみにトラフィックを流す

– Amazon RDSのMulti-AZ機能• チェックボックスにチェックをいれるだけ• マスタDBインスタンスと異なるAZにスタンバイ⽤のインスタンスを構築• 同期でデータをレプリケーション(コピー)するため万が⼀のケースでもデータロスト無し• フェールオーバー時はデータベースのDNS名は変わらないため、アプリケーション側でデー

タベース接続先の変更は不要• Amazon RDSのスケール

– サービスがポピュラーになって沢⼭の読み込みをリクエストを受け付ける必要がある場合はAmazon RDSのRead Replica機能を使ってスケール

> 10K Users : ユーザー数1万⼈以上• スケーラブルなアーキテクチャ

– アプリケーションのレイヤを更に分割し適材適所な⽔平スケーリングを実現– RDSのMulti AZおよびRead Replicatを導⼊したことでDBもスケーラブルに

> 10K Users : ユーザー数1万⼈以上• Shifting Loads to Increase Performance and Efficiency

– AWSには様々な、パフォーマンス/可⽤性/信頼性を備えたサービスがあります• これらの導⼊により、スケーラビリティをもたらします• 以下のような構成を⽬指します


– Amazon Simple Storage Service (Amazon S3)• 静的アセット(画像、動画、JavaScript、CSS)の保存および配信に利⽤可能• 容量無制限で安価に使えるストレージ(2016年2⽉現在1GBを保存するのに

約3.5円/⽉)• イレブン9の堅牢性デザイン(地理的に異なる3箇所にデータを複製)

– Amazon CloudFront• CDN。世界中の50箇所以上のエッヂロケーションから配信• SSL証明書を導⼊可能。Amazon Certificate Managerで無料SSL！• EC2もしくはS3からCloudFrontのエッヂまでのデータ転送量は無料

Amazon Simple Storage Service (S3)

• 特徴 (http://aws.amazon.com/jp/s3/)

– ⾼い堅牢性 99.999999999%– 格納容量無制限。利⽤した分のみ課⾦– 様々なAWSサービスと連携するセンター

ストレージ

• 価格体系 (http://aws.amazon.com/jp/s3/pricing/)

– データ格納容量– データ転送量(OUT) – APIリクエスト数

マネージドオンラインストレージサービス

Amazon S3

Amazon CloudFront

• 特徴 (http://aws.amazon.com/jp/cloudfront/)

– 簡単にサイトの⾼速化が実現できると共に、サーバの負荷も軽減

– 様々な規模のアクセスを処理することが可能– 世界53箇所のエッジロケーション

• 価格体系 (http://aws.amazon.com/jp/cloudfront/pricing/)

– データ転送量(OUT) – HTTP/HTTPSリクエスト数– (利⽤する場合)SSL独⾃証明書など

マネージドCDN(Contents Delivery Network)サービス

クライアント

レスポンス向上負荷軽減

AmazonCloudFront

キャッシュ

配信オフロード

Webサーバ

iQON http://www.iqon.jp/


Web/AppWeb/App

S3

CloudFront

Solr Memcached

Redis MySQL MongoDB

クローラ Zabbix

VarnishELB

PC/Mobile⽤ API⽤

GW


Web/AppWeb/App

S3

CloudFront

Solr Memcached

Redis MySQL MongoDB

クローラ Zabbix

VarnishELB

PC/Mobile⽤ API⽤

GW容量無制限なので容量を気にする必要なしまた⾼い堅牢性で個別のバックアップも不要

画像をS3に保存

Web/AppWeb/App

S3

CloudFront

Solr Memcached

Redis MySQL MongoDB

クローラ Zabbix

VarnishELB

PC/Mobile⽤ API⽤

GW

CloudFrontからの画像配信によりレイテンシ向上・EC2の負荷軽減も

画像など静的なコンテンツはS3+CloudFrontで配信



– Amazon DynamoDB• ユーザーが設定するProvision Throuputとストレージ料⾦による課⾦• 読み書きが⾮常に激しい場合などに利⽤可能

– Amazon ElastiCache• MemcachedおよびRedisをAWSが管理• ログインセッションのデータや⼀時的なデータストレージとして利⽤

Amazon DynamoDB

• 特徴 (http://aws.amazon.com/jp/dynamodb/)

– 複数のデータセンターにデータをレプリケーションすることにより、⾼い耐久性と可⽤性を提供。

– ユーザーは必要なスループットを決めるだけで利⽤可能。ストレージ容量は事前に決める必要がなく、必要に応じてプロビジョンされる。

– データ容量やスループットが増えてきても低いレイテンシで安定した性能を発揮する

– DynamoDB Streamsによって更新情報をAPIで取得可能。Lambda連携やクロスリージョンレプリケーションなどを実現。

• 価格体系 (http://aws.amazon.com/jp/dynamodb/pricing/)

– スループットキャパシティ• 書き込み: $0.00742/10ユニット/時間• 読み込み: $0.00742/50ユニット/時間

– ストレージ: $0.285/GB

Amazonが提供する⾼い信頼性、スケーラビリティ、低レイテンシで安定した性能を兼ね備えたNoSQLデータベースサービス

DynamoDBの使いドコロ• ゲーム• 広告配信• DMP• センサーデータ• モバイルアプリケーションの

バックエンド

いずれも、⾼いスループットと低いレイテンシが求められ、更に扱うデータ量が⼤きくなりやすいと

いう共通の特徴を持つ

Amazon ElastiCache

• 特徴 (https://aws.amazon.com/jp/elasticache/)

– フルマネージド環境でMemcached / Redisが利⽤可能– RedisはMulti-AZ配置することで可⽤性向上– ⼀部パラメータ以外はアプリケーション特性に応じて

変更可能– フェイルオーバーやパッチの適⽤、バックアップ

(Redis)も⾃動で⾏われる– Memcached⽤のAuto Discovery対応Client Libraryも

提供中

• 価格体系 (https://aws.amazon.com/jp/elasticache/pricing/)

– インスタンスタイプに応じて– Redisを利⽤しバックアップを有効にした場合はバック

アップストレージの利⽤量に応じて

フルマネージドキャッシュサービス

San FranciscoでDynamoDBのBest Practiceを紹介普段RDS使ってるんだけどDynamoDBってどういう時にどんな⾵に使うとイイの?• ⽇本のStartup事例をご紹介しました

For Couples. Photo Album / Chat / Date schedule

Pairy http://pairy.com/

EC2(API)

DB

ELB

MultiAZ

RDSDynamoDB

ELB

EC2(Websocket)

EC2(Worker)

ElastiCacheRedis

S3

CloudFront

SES

San FranciscoでDynamoDBのBest Practiceを紹介

Pairy http://pairy.com/

EC2(API)

DB

ELB

MultiAZ

RDSDynamoDB

ELB

EC2(Websocket)

EC2(Worker)

ElastiCacheRedis

S3

CloudFront

SES

Basic and Transaction Data

Right Database in the Right Place

Chat and News FeedHandling Massive

WriteTemporary Data

San FranciscoでDynamoDBのBest Practiceを紹介

> 10K Users : ユーザー数1万⼈以上• 今までの内容を反映すると↓のような構成図になります

> 500K Users : ユーザー数50万⼈以上• AutoScaling

– 今までは各コンポーネントを疎結合にし、適切なAWSサービスにワークロードを移⾏– AutoScalingを導⼊することでインフラを更にコスト効率良く管理することが可能に– そして、ピークに合わせたキャパシティプランニングから開放されます！

> 500K Users : ユーザー数50万⼈以上• AutoScaling

– メトリクスもしくはTime Scheduleに応じたポリシーを記述することが可能• 例)

– 5分間に渡ってCPUの利⽤率が60%を超える場合にEC2インスタンスを追加する– 毎朝9時に⼀定数のサーバーをプロビジョンする

– AutoScalingをはじめるには？• MAXとMINのインスタンス数を設定• スケールアウト(台数を増やす) およびスケールイン(台数を減らす)の設定• 新しくインスタンスを起動する際のAmazon Machine Image(AMI)を設定• EC2はオンデマンドもSpotインスタンス(余剰EC2インスタンスを⼊札形式でご提供)

> 500K Users : ユーザー数50万⼈以上• ⾃動化

– インスタンス数や利⽤するAWSサービス数が増えると管理作業が⾮効率に• ヒューマンエラーを招いてしまうこともある• アプリケーションのライフサイクルは極⼒⾃動化すべき• ⾃動化の利点

– 迅速な変化 / ⽣産性の向上 / リピータブルなデプロイメント / 再現可能な環境 / – レバレッジの効いた弾⼒性 / ⾃動テスト

– それぞれのサービスには固有の⾃動化ニーズが存在する• AWSはこの分野でもサービスを取り揃えています


– AWS CodeDeploy• CodeDeployは⾃動的にコードをAmazon EC2インスタンスおよびオン

プレミスで稼働しているサーバーにデプロイするサービスです– AWS Elastic Beanstalk

• AWS Elastic BeanstalkはJava, .NET, PHP, Node.js, Python, Ruby, Goで書かれたコード、そして DockerをApache, Nginx, Passenger, IISといったよく使われているサーバー上に簡単にデプロイできるサービス

– AWS OpsWorks• イベントドリブンなアプローチでアプリケーションを管理します。Chef

のレシピとして環境内の様々な変更をトリガーにした設定を記述できます

AWS CodeDeploy

• 特徴 (http://aws.amazon.com/jp/codedeploy/)

– Amazon.comと同様の仕組みで、管理されたデプロイを実現

– エージェントをインストールするだけでEC2でもオンプレミスでも管理可能

– グループ内に、⼀度にデプロイしたり1台ずつデプロイしたりと設定可能

• 価格体系 (http://aws.amazon.com/jp/codedeploy/pricing/)

– EC2インスタンスへのデプロイは無料• S3を利⽤した場合そのリソース分が課⾦対象

– オンプレミスインスタンスへは1台に1回デプロイすると$0.02

アプリケーションデプロイの⼀元管理サービス

AWS ElasticBeanstalk

• 特徴 (http://aws.amazon.com/jp/elasticbeanstalk/)

– 速く簡単にアプリケーションをデプロイ可能– インフラストラクチャの準備＆運営からアプリ

ケーションスタックの管理まで⾃動化– Auto Scaling によりコストを抑えながらスケー

ラビリティを確保– Java, PHP, Ruby, Python, Node.js, .NET,

Docker などに対応

• 価格体系 (http://aws.amazon.com/jp/elasticbeanstalk/pricing/)

– 追加料⾦なし– アプリケーションの保存、実⾏に必要なAWSリ

ソース (EC2, S3, RDS, DynamoDB など) に対してのみ課⾦

インフラ構成の構築・アプリデプロイの⾃動化サービス

AWS OpsWorks

• 特徴 (http://aws.amazon.com/jp/opsworks/)

– Chefのレシピを使って、デプロイや運⽤タスクを⾃動化可能

– ライフサイクルイベントにより動的な構成変更への対応が可能

– 継続的な構成管理• 価格体系 (http://aws.amazon.com/jp/elasticloadbalancing/pricing/)

– AWS OpsWorks⾃体の利⽤は無料– （OpsWorksエージェントをオンプレミス

サーバで利⽤する場合はその起動時間）

アプリケーションのデプロイ・管理サービス

AWS OpsWorks

スタック

LBレイヤー

Webレイヤー

DBレイヤー

EC2インスタンス上のOpsWorksエージェント


– AWS CloudFormation• JSONフォーマットのテンプレートを使ってあらゆるAWSリソースのプ

ロビジョニングを可能にします– AWS CodePipeline

• AWS CodePipelineは継続的デリバリー⽤のサービスで、デプロイメントプロセスをモデリングします

Amazon CloudFormation

• 特徴 (http://aws.amazon.com/jp/cloudformation/)

– テンプレートを元に、EC2やELBといったAWSリソースの環境構築を⾃動化

– JSONフォーマットのテキストで、テンプレートを⾃由に記述可能

– Microsoft Windows Server や SAP HANA などのリファレンス実装を⽤意（http://aws.amazon.com/quickstart/）

• 価格体系 (http://aws.amazon.com/jp/cloudformation/pricing/)

– 追加料⾦はありませんAWS リソース（Amazon EC2 インスタンスや Elastic Load Balancing ロードバランサーなど）に対してお⽀払いいただきます。

設定管理 & クラウドのオーケストレーションサービス

スタック

EC2Auto

Scaling

テンプレート（設定ファイル）

テンプレートに基づき各リソースが⾃動起動

EC2

CloudFormation

> 500K Users : ユーザー数50万⼈以上• 『Application Deployment on AWS』

– http://www.slideshare.net/shinodogg/application-deployment-on-aws– ⼀通り網羅されていますので是⾮ご覧ください！(⾃分が作ったスライドの

宣伝 ☺)

> 500K Users : ユーザー数50万⼈以上• Using Metrics and Monitoring Tools

– モニタリングツールを使ってデータを集めることで想定通りに稼働しているか確認できます– 取得可能なメトリクス

• Host-level metrics– Amazon CloudWatchを使⽤することで、EC2のCPU利⽤率やDisk読込のオペレーション、

そしてNetworkトラフィックのIN/OUTのボリュームといったインスタンスレベルのメトリクスを取得してモニタリング可能

• Aggregate-level metrics– CloudWatchはELBのメトリクスを取得。ヘルスチェックが成功/失敗しているインスタン

スの数、リクエスト数、レイテンシ、レスポンスコード400(クライアント起因エラー)や500(サーバー起因エラー)数などを確認可能

• Log analysis– アクセスを監査し、リソースの利⽤量をモニタリングし、トラフィックのパターンを捉え

る。CloudWatch Logsでアプリケーションログからエラー数をカウントして、通知可能• External site performance

– エンドユーザー⽬線でシステムのパフォーマンス計測– 例えばPingdom(https://www.pingdom.com/)のような3rdパーティーのサービスを活

⽤するのも良いかもしれません

CloudWatchMetrics

CloudWatch Logs を使ったログ監視

AmazonLinux Ubuntu

Windows RedHatLinux

CloudWatchLogs

CloudWatch Alarm SNS

LogAgent LogAgent

LogAgent LogAgent

VPCFlowLog

ElasticsearchService

> One Million Users : ユーザー数100万⼈以上• 今までやってきたことのおさらい

– 1つのインスタンスで全てまかなっていたのをレイヤーに分離して⽔平的なスケールを実現

– AWSプラットフォームで動作するデータベースを選択し、スケーリングおよび管理系タスクをオフロード

– ⾼いパフォーマンスをコスト効率よく実現するためAWSのマネージドサービスを活⽤

– AutoScalingを使って適切なEC2インスタンス数を維持(キャパシティプランニングからの開放)

– AWSのサービスを活⽤したプロビジョニングおよびソフトウェアデプロイメインとのライフサイクルの⾃動化を実現

> One Million Users : ユーザー数100万⼈以上• Service Oriented Architecture

– 単にアプリケーションをサーバーのロールで分割する(例:Web/Application)のではなく、サービスを⼀纏めにすることで更にリソース毎に分割していく

– それぞれのサービスを独⽴した形でそれぞれスケールさせることができる(例:決済サービス/会員認証サービス/検索サービス)

– 限られたスタートアップのリソースでSOAを実現できる？• fear not, developers• AWSプラットフォームはplug and playで汎⽤的なサービスが揃って

おり、それを活⽤することで簡単に疎結合なアーキテクチャを可能にします

> One Million Users : ユーザー数100万⼈以上• Donʻt Reinvent the Wheel(⾞輪の再発明をするな)

– メール送信 / メッセージキューイング / 動画のトランスコーディング / モニタリング / ロギング等

– それぞれ素晴らしいテクノロジーだが、そのものにはビジネス上の価値は無い– 差別化に繋がらないのに in-house で作る事に時間を使う必要がある？– AWSは下記のような⼀般的に使えるサービスを提供し、あなたがインプラス

トラクチャをクイックに構築することを⼿助けします

Amazon Simple Queue Service (SQS)

• 特徴 (http://aws.amazon.com/jp/sqs/)

– ⾼い信頼性: 複数のサーバー/データセンターにメッセージを保持

– スケーラブル: 多数の送信者/受信者に対応– ⾼スループット: メッセージが増加しても⾼スループッ

トを出し続ける

• 価格体系 (http://aws.amazon.com/jp/sqs/pricing/)

– 無料利⽤枠: 毎⽉100万Amazon SQSリクエストまで無料

– その後Amazon SQSリクエスト100万件につき0.476 USD(東京リージョン以外は0.5USD)

– 複数のメッセージを１度のリクエストで処理することにより、コスト効率をあげることも可能

⾼い可⽤性と信頼性を提供するフルマネージドなメッセージキューサービス

Producer Consumerpolling

Producer, ConsumerはEC2やモバイルデバイス、オンプレミスんサーバーなどで構成する。実際のやりとりにはAmazon SQS APIを使って行う。

message message

Amazon Simple Notification Service (SNS)

• 特徴 (http://aws.amazon.com/jp/sns/)

– 個々のメッセージ送信や、多数の受信者にメッセージをファンアウトすることが可能

– AWSの様々なサービスと連携して通知可能– フルマネージドなので⾼速かつスケーラブルで管理不要で

⾮常に安価

• 価格体系 (http://aws.amazon.com/jp/sns/pricing/)

– 無料枠: • Email/Email-JSON: 1,000件• HTTP/HTTPS: 100,000件• Simple Queue Service（SQS）: 無料

– リクエスト単価(64KBのチャンク毎に1リクエストとして課⾦)

• Email/Email-JSON: 100,000件あたり2 USD• HTTP/HTTPS: 100万件あたり0.6 USD• Simple Queue Service（SQS）: 無料

マルチプロトコルに対応したフルマネージド通知サービス

Publish

1.Topicにメッセージを送信

2. マルチプロトコルで通知

Amazon SNSPublisher Topic

HTTPHTTPS

EMAIL

SQS

Mobile Push

Subscriber

AWS Lambda

Followers

写真共有モバイルアプリ

4. メタデータをDynamoDBに登録- タイトル、コメント等

1. 認証・認可・ FBアプリと連携

6. Push通知- フレンドやフォロワーに通知

Cognito

Mobile Analytics

DynamoDB

S3

SNS7. 画像をポストしたことをAnalyticsに登録

3. 画像のリサイズ

2. S3への画像アップロード

5. 結果をSNSへ通知

App with AWS Mobile

SDK

Amazon API Gateway

• 特徴 (http://aws.amazon.com/jp/lambda/)

– OS、キャパシティ等インフラの管理不要– バックエンドとしてLambda、既存Webシス

テムを利⽤可能– スロットリング/キャッシュ

• 価格体系 (http://aws.amazon.com/jp/lambda/pricing/)

– 呼び出し回数とキャッシュ容量– 100万回の呼び出しにつき$3.5– キャッシュ容量に応じて$0.02/時〜$3.8/時

Web APIの作成・保護・運⽤と公開を簡単に

Mobile Apps

Websites

Services

API Gateway

AWS Lambda functions

AWS

API Gateway Cache

Endpoints on Amazon EC2 / Amazon Elastic

Beanstalk

Any other publicly accessible endpoint

Amazon CloudWatch Monitoring

> One Million Users : ユーザー数100万⼈以上• 100万を超えるようなユーザーを捌くには、以下のような

アプローチを全て⾏う必要が出てきます⎷ 複数のAvailability Zoneへのデプロイ⎷ Elastic Load Balancing(ELB)の活⽤⎷ Auto Scalingの導⼊⎷ Service-Orientedなアーキテクチャ⎷ コンテンツ配信に最適なAWSサービスの利⽤⎷ ElastiCacheを使ったデータベースの負荷のオフロード

> One Million Users : ユーザー数100万⼈以上• 100万ユーザーを捌くインフラ図

> One Million Users : ユーザー数100万⼈以上• 500万〜1000万ユーザーになったら？

– マスタデータベースのボトルネックが顕著になる場合が多い• Database Federation

– 機能毎にデータベースを分割していく– 例えば、フォーラムデータ/ユーザーデータ/プロダクトデータをそれぞれ異な

るデータベースに– SOA戦略を補うような考え⽅

• Sharding– Federationを⾏っても、それでもなおデータサイズが⼤き過ぎる場合に検討– 例えば、ユーザーIDをハッシュ化して保存するデータベースを分ける– 但し、横断してデータを抽出する場合や、新たにデータベースを追加する場合

等に注意が必要• NoSQL

– Join等が発⽣しない独⽴したテーブルをデータベース内に保持しているのであれば、DynamoDBのようなNoSQLを利⽤するのも1つの選択肢

– DynamoDBはデータサイズによって⾃動的にスケール

AWS上でのスケールに困ったら、、• いつでもご相談ください！

AWS上でのスケールに困ったら、、• セミナーやWebinarも開催しています！

– Black Belt Tech Webinar: 毎週⽔曜⽇18:00〜

https://aws.amazon.com/jp/about-aws/events/

AWS上でのスケールに困ったら、、• Slideshareにスライド上げたりQiitaで翻訳したりしてます

http://www.slideshare.net/shinodogg http://qiita.com/shinodogg

Technology

Scaling on AWS - Feb 2016