クラウドのためのアーキテクチャ設計 - ベストプラクティス -

クラウドのための
アーキテクチャ設計
- ベストプラクティス -
2011年5月19日
玉川憲 (@KenTamagawa ), エバンジェリスト
大谷晋平 (@shot6), ソリューションアーキテクト

ウェビナーへようこそ！
参加者は、自動的にミュートになっています
質問を投げることができます！
 GoToWebinarの仕組みを使って、書き込んでください
 ただし環境によっては、日本語の直接入力ができないので、
お手数ですが、テキストエディタ等に打ち込んでから、
コピペしてください

 最後のＱ＆Ａの時間で、できるだけ回答させて頂きます

 書き込んだ質問は、主催者にしか見えません
Twitterのハッシュタグは#jawsugでどうぞ

Copyright © 2011 Amazon Web Services

AWSアーキテクチャセンターのご紹介

aws.amazon.com/jp/architecture/

Webinarのご案内
ホワイトペーパー紹介

「クラウドのための
アーキテクチャ設計
ベストプラクティス」
by Jinesh Varia

日本語版、近日公開！！


クラウドコンピューティングの特徴

抽象化されたサーバーやハードディスクの実体は気にせずに、
リソースインスタンスとボリュームを扱える

必要なときに
瞬時に調達
必要なときに瞬時に調達でき、何時でも止められる

スケールアウト
自由自在
実際のピークに応じてスケールアウト/イン

従量課金実際に使った分だけ支払う

プログラマブルなインフラストラクチャ。APIを用いて自動
自動化
化できる。

AWS プラットフォーム

いつでも、必要なだけ、安価に、
コンピュータリソースを利用可能に

スケーラビリティ
AWSを用いたスケーラブルなアーキテクチャ構築

スケーラブルなインフラストラクチャを活用するには、スケーラブ
ルなアーキテクチャが必要

スケーラブルなアプリケーションの特徴

リソースの増加に比例して、パフォーマンスが増
加する
回復力に富んでいる
成長するにつれて費用効率がさらに良くなる
（ユニット数が増加するにつれて、
ユニット単位あたりコストが下がる）。

スケーラブルなアプリケーションは
クラウド以前でも言われてきた
クラウド以前から大切だったこと
 スケーラビリティ（拡張性）の大切さ
スケールアップ / スケールアウトなどの手法
クラウド以後で、より大切になること
 Elasticity – 弾力性：いつでも必要なだけ安価に
リソースが調達できるならば？？
 「非常に迅速な」リソースの増減を可能とする
アーキテクチャ？？


Elasticity(弾力性)の真価を理解する

※AWSエコノミクスセンター： http://aws.amazon.com/jp/economics/

1日のCPU負荷

14
12
10
8
負荷

6
25% 節約
4
2
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
時刻

年間のCPU負荷

12

10

8
Load

6

4

2

0
50% 節約
1 5 9 13 17 21 25 29 33 37 41 45 49
Week

弾力性のある賢いアーキテクチャを作ろう
自社のアプリケーションを弾力性のあるものに！
 アーキテクトは想像力を高めよう

もはやアーキテクチャ上の設計要件の一つ
 弾力性を高めるとどんなメリットが？
 どのコンポーネントに弾力性を？
 どのレイヤーに弾力性を？

弾力性のあるアーキテクチャは芸術的


クラウドの制約をむやみに恐れない

よくある言い訳
 「クラウドは、大量のRAMを積んでいるものがない」
 「私のデータベースはもっとIOPSが必要です」
工夫しましょう
 分散キャッシュを使えば？複数サーバーで分割すれ
ば？？
抽象的なクラウドリソース
x オンデマンド調達モデル
= 無限の可能性


クラウドのためのアーキテクチャ設計
ベストプラクティス

1. 故障のための設計(Design for failure)
2. 疎結合なコンポーネント
3. 弾力性の実装
4. 全レイヤにおけるセキュリティ担保
5. 並列処理の使い倒し
6. 異なるストレージの使い分け

1. 故障のための設計
そうすれば、何も故障しない

“あらゆるものが何時でも故障しうる"
Werner Vogels, CTO Amazon.com

単一障害点を避ける
全てが故障すると仮定したうえで、さかのぼって設計する
ゴール: たとえ、物理的ハードウェアが故障したり置きかえられたりしよう
とも、アプリケーションは動き続ける

人生を楽にするツール達

サーバーコピーをAMIとして取得し、何時でも起動可能に

www.myphpwebsite.com

Amazon Route 53
(DNS)
Elastic Load LB
Balancer

Web Server
Amazon Machine
Image
App Server

Amazon EC2
Instance

Auto Scaling Group

Amazon EC2
Instance
EBS

Availability Zone #1


Amazon Route 53
(DNS)
Elastic Load LB
Balancer

Web Server
Amazon Machine
Image App Server

Amazon EC2
Instance

Auto Scaling Group

Amazon EC2
Instance
EBS



アプリケーションを耐障害性の高いサービスで補強する


Amazon Route 53
(DNS)
Elastic Load LB
Balancer

Web Server

App Server

Amazon EC2
Instance

Auto Scaling Group

Amazon EC2
Instance
EBS


(dynamic traffic) media.myphpwebsite.com
(static load)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront

Web Server
Logs
Amazon Machine Buckets
Static Data
Image
App Server Amazon S3

Amazon EC2
Instance

Auto Scaling Group

Dynamic Data

Amazon EC2
Instance
EBS


(dynamic traffic) media.myphpwebsite.com
(static load)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront

Amazon SNS Web Server
(notifications) Logs
Static Data
Image

Amazon EC2
Instance
Amazon SimpleDB
(Catalog and Config data) Auto Scaling Group

Dynamic Data

Amazon EC2
Amazon CloudWatch Instance
(Monitoring)
EBS


Design for Failure with AWS
Tools to make your life easier

Amazon Elastic Block Store (EBS)のスナップショットを用いる

(dynamic data) media.myphpwebsite.com
(static data)
Amazon Route 53
(DNS)
Elastic Load
LB
Balancer
Amazon
Distribution
CloudFront

Web Server
Logs
Static Data
Image

Amazon EC2
Instance

Auto Scaling Group

Amazon EC2
Instance
EBS
Snapshots



自動復旧のために自動スケーリング(Auto-scaling)を用いる

(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront

Web Server
Logs
Static Data Buckets

Amazon EC2
Instance

Auto Scaling Group

Amazon EC2
Instance
EBS
Snapshots


(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront

Web Server Web Server
Logs
Static Data Buckets
App Server App Server Amazon S3

Amazon EC2 Amazon EC2
Instance Instance

Auto Scaling Group

Amazon EC2
Instance
EBS
Snapshots



Multi-AZを用いたデータ同期とデータ復旧

(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront

Logs
Static Data Buckets

Instance Instance

Auto Scaling Group

Amazon EC2
Instance
EBS
Snapshot
s
Availability Zone #1 Amazon EC2
Instance
EBS

(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Amazon
Distribution
CloudFront

Logs
Static Data Buckets

Instance Instance

Auto Scaling Group

Snapshots
Amazon EC2
Instance
EBS

Availability Zone #1 Amazon EC2
Instance
EBS


異なるAZへのオンデマンドなアプリケーションプロビジョニング

(static data)
Amazon Route 53
(DNS)
Elastic Load LB
Balancer
Distribution

Amazon
CloudFront

Logs Buckets
Web Server Web Server Web Server Web Server Static
Data
App Server App Server App Server App Server Amazon S3

Amazon EC2 Amazon EC2 Amazon EC2 Amazon EC2
Instance Instance Instance Instance

Auto Scaling Group

Instance Instance
Synchronous
EBS Replication EBS
Snapshots

Availability Zone #1 Availability Zone #2


異なるAZへのオンデマンドなアプリケーションプロビジョニング
Multi-AZを用いたアプリケーション配備とデータ同期

(dynamic data)
Amazon Route 53 media.myphpwebsite.com
(DNS) (static data)
Elastic Load Balancer LB

Auto Scaling group : Web Tier Auto Scaling group : Web Tier

Web Server Web Server Web Server Web Server
App Server App Server App Server App Server Distribution

Amazon
Amazon EC2 CloudFront

Memcache Memcache Memcache Memcache
Tomcat Tomcat

Cache Tier Cache Tier

DB Multi-AZ
Buckets
Amazon RDS Slave
Master Read
Replica

Availability Zone #1 Availability Zone #2 Amazon S3

(dynamic data)
(DNS) (static data)

Auto Scaling group : Web Tier
App Server App Server Distribution

Amazon
CloudFront

Memcache Memcache
Tomcat

Cache Tier

DB
Multi-AZ
Buckets
Slave
Master

Availability Zone #2 Amazon S3

(dynamic data)
(DNS) (static data)

Auto Scaling group : Web Tier
Web Server Web Server Distribution
App Server App Server
App Server App Server
Amazon
CloudFront

Memcache Memcache
Tomcat

Cache Tier

DB
Multi-AZ
Buckets
Slave
Master

Availability Zone #2 Amazon S3

疎結合であればあるほど、スケールする

コンポーネントを独立させる
ブラックボックスとみなして設計
コンポーネント間を疎結合に
アプリケーションをステートレスに

Amazon SQSをバッファに用いる
密結合 Controller A Controller B Controller C

Q Q Q
キューをもちいて
疎結合に Controller A Controller B Controller C

弾力性は、クラウドの基本

コンポーネントの健全性や場所を、決めつけない
リブートを何時でもできるよう設計する
インスタンスをブートストラップ
インスタンス自身が“ 自分の役割 ”を分かるように
動的なコンフィギュレーションを可能にする

Auto-scaling（オートスケーリング）を利用する
Elastic Load Balancingを複数レイヤで利用
SimpleDBに設定情報を入れて、インスタンスをブートストラップ
Chef、Puppetのような構成管理ツールを用いる

3. 弾力性を実装する
Standardized Technology Stacks
標準的なアプリケーションスタック

WebIIS
Apache
Server

ASP.NET
Mongrel
Tomcat
App Server

ASP.NET MVC
Struts
Rails
MVC

Your Code

Log4Net
logger
Log4J
Libraries

Spring.NET
RubyGems
Spring
Packages

memcached
nHibernate
Hibernate
DB Caching

Ruby JEE
Runtime
.NET
Framework

Windows
Centos
Linux
OS

Java Stack .NET Stack RoR stack

3 Approaches to design MDE
AMIを設計する3つのアプローチ

設定が簡単

AMIの完全コピー

ブート時に設定する
“ゴールデンAMI”

JeOS とChefを
用いたAMI
メンテナンスが楽
柔軟にコントロール可能

AMIの完全コピー

Apache
Apache

Tomcat Tomcat

Struts Struts
IIS IIS

Your Code Your Code IIS

ASP.NET MVC
IIS

IIS
IIS

ASP.NET MVC

IIS

Your Code ASP.NET MVC
Your Code
IIS

Log4Net Log4Net
Your Code
ASP.NET MVC

Log4J Spring.NET
Log4Net
Spring.NET

Log4J
Your Code

nHibernate nHibernate
Spring.NET
Log4Net

.NET .NET
nHibernate
Spring.NET

Windows Windows

Spring
.NET
nHibernate

Windows
.NET

Spring Windows

Hibernate
Hibernate Amazon EC2
JEE

JEE Linux

Linux
.NET Stack Java AMI

“Golden AMIs” with fetch on boot
ゴールデンAMI

Apache Your
Code Fetch on boot time
Source Control
Tomcat

Struts Struts
Log4J
Spring
Your Code IIS

Amazon S3 IIS IIS

IIS IIS
IIS

IIS

Log4J .NET

Windo .NET
ws
IIS
.NET

Windo .NET Windo
Apache ws ws
Windo

Spring ws

Tomcat

Hibernate Hibernate

JEE
Amazon EC2
JEE
Linux
Linux
Java Stack Java AMI

JeOS とChefを用いたAMI

Apache Your
Code Cookbooks
Tomcat Source Control
Recipes

Struts
Apache Chef Server

Your Code Struts
Tomcat
Log4J
Hibernat
Log4J e Spring
CHEF
Agent

Spring Amazon S3
Windows

Hibernate
CHEF Agent
JEE
Linux
Amazon EC2
Linux
Java Stack AMI (JeOS)

自己管理するEC2インスタンスの構築

TagあるいはUserDataを読み込んでインスタンス起動
Startupコードに、コンフィグデータをチェックさせる
上記の動的な情報を基にして、インスタンスの役割をセットする
パッケージをインストール/アップデートする
サービスを開始する
アプリケーションのコードをインストール/アップデートする
必要なEBSボリュームをCreate/attachする
Elastic IPアドレスを付加する
追加のTagをセット
最後にヘルスチェックを実施して、オンラインにする


常にセキュリティを考えながら設計する

セキュリティは責任分担モデル
全てのレイヤでセキュリティを考える
必要がある

責任分担モデル

顧客 1 顧客 2 … 顧客 n

顧客が管理ハイパーバイザー

仮想インタフェース
顧客1
セキュリティグルー
プ
顧客2
プ
… 顧客n
プ
ファイヤウォール
AWSが管理
物理インタフェース


セキュリティは責任分担モデル(Shared Responsibility)
出入りするデータの暗号化
SAS 70 Type II Audit その他のデータの暗号化
ISO 27001/2認証 AWS セキュリティ証明書
PCI DSS 2.0 Level 1-5 秘密鍵のローテーション
HIPAA/SOX Compliance インフラストラアプリケーアプリケーション、OS、ミドル
クチャションウェアレベルの担保
セキュリティセキュリティ
どのようにAWSが
どのようにしてアプリケー
インフラをセキュア
ションを守るか？
にしているか？
サービス
セキュリティ

セキュリティを高めるため IAMポリシー
にどのような機能を使うこ認証デバイス, VPC, S3 バケッ
とができるか？トポリシー, EC2セキュリティグ
ループ, EFS in EC2等..

セキュリティグループ


シーケンシャルな処理にこだわるのは過去の話に

異なるアーキテクチャを、並列に実証実験する
クラウドサービスに、マルチスレッドでアクセスする(S3, SimpleDB)
ワークフローを分割して並列化して処理する(SQS)
並列なジョブをAmazon Elastic MapReduce上で走らせる
Elastic Load Balancingを用いて複数サーバーに処理を分散する
HPCを帯域保障されるネットワークでつないで並列処理を行う(EC2)

6. クラウドストレージの使い分け
クラウドストレージは用途に応じて用意されている

Amazon S3: 大容量の静的なオブジェクト
Amazon SimpleDB: シンプルなデータのインデックスとクエリー
Amazon EC2 local disc drive : 揮発性のあるデータ
Amazon EBS: 永続的データ (RDBSにも使える)
Amazon RDS: 自動管理されたMySQL (Oracleも近日)

6. クラウドストレージを使い分ける
クラウドストレージの適材適所

Amazon S3 + CF Ephemeral Amazon EBS Amazon Amazon
Store (EC2) SimpleDB RDS

理想的な大量のデータ。一一時的なあらゆる種類軽量の属性付リレーショナ
使い方度書き込んで、沢データの書の永続的デーデータルDBのデー
山読みだすき込みタ。EC2インスタ
タンスと寿命
異なる
良い使用音声、ビデオ、画設定データ、クラスタリング、クエリー用、複雑なトラン
例像、バックアップ、一時処理ブートデータ、マッピング用、ザクションシ
アーカイブデータ、ログ、商用DB タグ付け、メタステム、
Tempデータのデータデータオーダー処
理
お勧めしクエリー、検索顧客データ、リレーショナル
ない使いデータベークエリ(join)
方スログ、バッ
クアップ
悪い使用データベース、ファセンシティブコンテンツ配 OLTP 単純なデー
例イルシステムなデータ信タ保管

ここまでの道のり
クラウドアーキテクチャのベストプラクティス

1. 故障のための設計(Design for failure)
6. 異なるストレージの使い分け

Q&A


ご参加ありがとう
ございました


Webinar終了後の
お茶の間トークも
楽しんでいただけましたか？


AWSのはじめ方

下記のスライドシェア資料をご参照ください

①AWSアカウント開設
http://t.co/3eBGHaG
②EC2でWebサーバー立ち上げ
http://t.co/HiinYgI
③S3にwebコンテンツ保存
http://www.slideshare.net/kentamaga
wa/s3web
④EC2でWindowsサーバ立ち上げ
wa/ec2windows
⑤CloudFormationでRedmine立ち上げ
wa/aws-cloudformation-redmine

AWSプレミアムサポート
アーキテクチャ設計に関するガイダンス、ベストプラクティス
も日本語でご案内できます
aws.amazon.com/jp/premiumsupport/
ブロンズシルバーゴールドプラチナ

初回応答時間１２時間４時間１時間１５分

サポート連絡先１人２人３人無制限

24/365対応なしなしありあり

TEL可能不可不可可能可能

専任スタッフなしなしなしあり

特別サポートなしなしなしあり
AWS利用総額の
AWS利用総額の
$0~$10K: 10%
AWS利用総額の 10%
料金 $49
5%
$10K~$80K: 7%
$80K~: 5%
（最低$15K）
（最低$400）

クラウドのためのアーキテクチャ設計 - ベストプラクティス -

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to クラウドのためのアーキテクチャ設計 - ベストプラクティス -

Similar to クラウドのためのアーキテクチャ設計 - ベストプラクティス - (20)

More from SORACOM, INC

More from SORACOM, INC (20)

クラウドのためのアーキテクチャ設計 - ベストプラクティス -