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万⼈以上

A Primer : ⼊⾨
• Why AWS
– スケールするインフラストラクチャを⾃前で⽤意する？
• ピークのキャパシティを⾒積もり(サービスをはじめる前から…？)、
• 機器の到着を待ち、
• ハードウェアとソフトウェアのセットアップを⾏い、
• 全てが正しく稼働することを祈る…。
– Cloudを使えば上記のような頭の痛いことが全て解決できる？
– AWSを使って下記のようにスケールさせてゆく様⼦をみていきます
• ⽴ち上げ期
• ユーザー数1万⼈以上

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

A Primer : ⼊⾨
• AWSとは？
– Availability Zone(≒データセンター)
• リージョン内のAvailability Zoneは異なる電⼒系統で、断層線や氾
濫原が異なる
• リージョン内の他のAvailability Zoneに対してsingle digit
millisecondで通信可能

A Primer : ⼊⾨
• AWSとは？
– 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
管理インター
フェイス
Management
Console, CLI
ライブラリ & SDKs
Java, PHP,
.NET,
Python, Ruby
グローバルインフラ
リージョン、アベイラビリティゾーン、エッジロケーションAZRegio
n
コンピュート処理
EC2, Auto Scaling, Elastic,
Load Balancing, Lambda
EC2 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
ディレクトリ
Directory
Service
コード管理
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にのみ存在⇒単⼀のロケーションと運命を共に
することになってしまう

A Primer : ⼊⾨
– 垂直スケール問題の解決
• アプリケーションを分散できるように、データベースとアプリケー
ションのEC2インスタンスを分離する

A Primer : ⼊⾨
– ロードバランサ(Elastic Load Balancing: ELB)を使って複数Availability Zone
に配置されたアプリケーション⽤のEC2インスタンスに負荷分散
• データベースはインターネットから直接アクセスする必要ないのでPrivate

> 10K Users : ユーザー数1万⼈以上
• AWSでのデータベースオプション
– 今のままではデータベースがSPOF(Single Point Of Failure)
– AWSには様々なデータベースのオプションがあります

• Amazon RDS
– データベース管理はAWSが⾃動的な夜間バックアップやソフトウェアの
アップデートなどを⾏う。異なるAvailability Zoneへのシームレスな
フェールオーバーなどをサポート。エンジニアリソースは限られているの
でご利⽤いただくことをオススメしています。MySQL, PostgreSQL,
Maria DB, SQL Server, Aurora, Oracleといったデータベースをサポート
• Amazon DynamoDB
– ⾼速でフレキシブルなNoSQLデータベース。どのようなデータスケールに
おいても、⼀貫性やミリ秒レベルのレイテンシを確保するアプリケーショ
ンに向いている。フルマネージドなCloudデータベースでありDocument
およびKeyValueの両⽅のモデルをサポート
• Amazon EC2
– もしAWSが提供していないデータベースエンジンを利⽤する必要があった
り、全ての権限が必要な場合はEC2上にご⾃⾝でデータベースを構築する
ことも可能です。

• SQL vs NoSQL
– SQL
• 確⽴したテクノロジを利⽤したい場合。既存のコード/コミュニティ/事
例/スケールの確⽴されたパターンの価値を活かしたい場合
• ⼤量のデータを扱うわけではない場合。ここでいう⼤量とは最初の1年
でテラバイト級のデータが発⽣するようなもの
– NoSQL
• Non-Relationalなデータを⼤量に保持する必要がある場合
– テラバイト級の⼤量データを扱うのであれば、NoSQLは⽔平に分
散してスケールさせやすい
• 秒間数千〜数万といった⾼速なデータ登録を⾏う必要がある場合
– シンプルなデータ構造のためNoSQLでーたは登録や削除を素早く
実⾏可能
• 次のセクションではAmazon RDS(SQLテクノロジ)で進めていきます

• テッパンな基本構成！
– ELB + EC2 + RDS on Multi AZ
EC2
RDS
Availability Zone
Web
Web
EC2
RDS
Availability Zone
WebELB

BASE https://thebase.in/
EC2 EC2
RDS
(Active
)
DB
ELB
AZ① AZ②
RDS
(Standby)
ElastiCache S3
CloudFront

• 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機能を使ってスケール

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

• 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)サービス
クライアント
レスポンス向上負荷軽減
Amazon
CloudFront
キャッシュ
配信オフロード
Webサーバ

iQON http://www.iqon.jp/
Web/AppWeb/App
S3
CloudFront
Solr Memcache
d
Redis MySQL MongoDB
クローラ Zabbix
VarnishELB
PC/Mobile⽤ API⽤
GW

Web/AppWeb/App
S3
CloudFront
Solr Memcache
d
Redis MySQL MongoDB
クローラ Zabbix
VarnishELB
PC/Mobile⽤ API⽤
GW
容量無制限なので容量を気にする必要なし
また⾼い堅牢性で個別のバックアップも不要
画像をS3に保存

Web/AppWeb/App
S3
CloudFront
Solr Memcache
d
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)
ElastiCache
Redis
S3
CloudFront
SES

Pairy http://pairy.com/
EC2
(API)
DB
ELB
MultiAZ
RDSDynamoDB
ELB
EC2
(Websocket)
EC2
(Worker)
ElastiCache
Redis
S3
CloudFront
SES
Basic and
Transaction Data
Right Database in the Right Place
Chat and News Feed
Handling Massive
Write
Temporary Data

• 今までの内容を反映すると↓のような構成図になります

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

• AutoScaling
– メトリクスもしくはTime Scheduleに応じたポリシーを記述することが可能
• 例)
– 5分間に渡ってCPUの利⽤率が60%を超える場合にEC2インスタンスを追加する
– 毎朝9時に⼀定数のサーバーをプロビジョンする
– AutoScalingをはじめるには？
• MAXとMINのインスタンス数を設定
• スケールアウト(台数を増やす) およびスケールイン(台数を減らす)の設定
• 新しくインスタンスを起動する際のAmazon Machine Image(AMI)を設定
• EC2はオンデマンドもSpotインスタンス(余剰EC2インスタンスを⼊札形式でご提供)

• ⾃動化
– インスタンス数や利⽤する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 ロード
バランサーなど）に対してお⽀払いいただきます。
設定管理 & クラウドのオーケストレーションサービス
スタック
EC2
Auto
Scaling
テンプレート（設定ファイル）
テンプレートに基づき
各リソースが⾃動起動
EC2
Cloud
Formation

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

• 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パーティーのサービスを活
⽤するのも良いかもしれません

CloudWatch
Metrics
CloudWatch Logs を使ったログ監視
Amazon Linux Ubuntu
Windows Red Hat Linux
CloudWatch
Logs
CloudWatch Alarm SNS
Log Agent Log Agent
Log Agent Log Agent
VPC Flow Log
Elasticsearch
Service

> One Million Users : ユーザー数100万⼈以上
• 今までやってきたことのおさらい
– 1つのインスタンスで全てまかなっていたのをレイヤーに分離して⽔平的
なスケールを実現
– AWSプラットフォームで動作するデータベースを選択し、スケーリングお
よび管理系タスクをオフロード
– ⾼いパフォーマンスをコスト効率よく実現するためAWSのマネージドサー
ビスを活⽤
– AutoScalingを使って適切なEC2インスタンス数を維持(キャパシティプラ
ンニングからの開放)
– AWSのサービスを活⽤したプロビジョニングおよびソフトウェアデプロイ
メインとのライフサイクルの⾃動化を実現

• Service Oriented Architecture
– 単にアプリケーションをサーバーのロールで分割する
(例:Web/Application)のではなく、サービスを⼀纏めにすることで更にリ
ソース毎に分割していく
– それぞれのサービスを独⽴した形でそれぞれスケールさせることができる
(例:決済サービス/会員認証サービス/検索サービス)
– 限られたスタートアップのリソースでSOAを実現できる？
• fear not, developers
• AWSプラットフォームはplug and playで汎⽤的なサービスが揃って
おり、それを活⽤することで簡単に疎結合なアーキテクチャを可能に
します

• 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 Consumer
polling
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 SNS
Publisher
Topic
HTTP
HTTPS
EMAIL
SQS
Mobile
Push
Subscriber

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

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

• 100万ユーザーを捌くインフラ図

• 500万〜1000万ユーザーになったら？
– マスタデータベースのボトルネックが顕著になる場合が多い
• Database Federation
– 機能毎にデータベースを分割していく
– 例えば、フォーラムデータ/ユーザーデータ/プロダクトデータをそれぞれ異な
るデータベースに
– SOA戦略を補うような考え⽅
• Sharding
– Federationを⾏っても、それでもなおデータサイズが⼤き過ぎる場合に検討
– 例えば、ユーザーIDをハッシュ化して保存するデータベースを分ける
– 但し、横断してデータを抽出する場合や、新たにデータベースを追加する場合
等に注意が必要
• NoSQL
– Join等が発⽣しない独⽴したテーブルをデータベース内に保持しているのであ
れば、DynamoDBのようなNoSQLを利⽤するのも1つの選択肢
– DynamoDBはデータサイズによって⾃動的にスケール

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

• セミナーやWebinarも開催しています！
– Black Belt Tech Webinar: 毎週⽔曜⽇18:00〜
https://aws.amazon.com/jp/about-aws/events/

• Slideshareにスライド上げたりQiitaで翻訳したりしてます
http://www.slideshare.net/shinodogg http://qiita.com/shinodogg

Scaling on AWS - Feb 2016

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (16)

Semelhante a Scaling on AWS - Feb 2016

Semelhante a Scaling on AWS - Feb 2016 (20)

Mais de Eiji Shinohara

Mais de Eiji Shinohara (20)

Scaling on AWS - Feb 2016