2015/02/19 Developers Summit 19-E-1 にて発表した資料です。 #devsumi

1. クラウドデザインパターンから始め
るクラウドの利点と弱点の理解
～提案から設計・開発・保守に活かす！～
2015.2.19 Developer Summit 19-E-1
株式会社ネクストスケープ
アーキテクト
上坂貴志

2. アジェンダ
• AWS, Azureのクラウドデザインパターンの違い
• AWSクラウドデザインパターンについて
1. 入門パターン
① 仮想サーバー
② オートスケーリング＆ロードバランサー
③ Webストレージ
④ CDN
2. クラウド利点活用パターン
① 高可用
② スケーリング
③ WebStorage
④ その他
3. 今回紹介しなかったパターン
4. まとめ
• Azureクラウドデザインパターンについて
1. SLA100%未達への対処
2. スケーリングへの対処
3. 今回紹介しなかったパターン
4. まとめ

3. 自己紹介
• 上坂貴志（うえさかたかし）
• 学生時代にWindows95発売してたっけ？な年齢
• 学生時代のアルバイトがプログラマーだったのが運のつき
• 保守運用があまりに辛くて、どうしたものかとWebを彷徨って
いた頃に流行っていたのがITアーキテクトという言葉
• これぞ銀の弾丸か！と思ってITアーキテクトになろうとそれ以
来、孤軍奮闘
• そんな訳でいまだにアーキテクチャと格闘しています。（もは
や趣味か）
• ここ数年はクラウドどっぷりなシステム開発に従事
• 機会があればセッションしてます
• 株式会社NEXTSCAPE
• このセッションはACE（Azure Council Experts）の
枠です。

4. AWSクラウドデザインパターンと
Azureクラウドデザインパターンの違い

5. AWS クラウドデザインパターン
• AWS, Azureのクラウドデザインパターンの違い
• AWSクラウドデザインパターンについて
1. 入門パターン
① 仮想サーバー
② オートスケーリング＆ロードバランサー
③ Webストレージ
④ CDN
2. クラウド利点活用パターン
① 高可用
② スケーリング
③ WebStorage
④ その他
3. 今回紹介しなかったパターン
4. まとめ
• Azureクラウドデザインパターンについて
1. SLA100%未達への対処
2. スケーリングへの対処
3. 今回紹介しなかったパターン
4. まとめ

6. Snapshot パターン
Ondemand Disk パターン
ScaleUp パターン
Stamp パターン
仮想サーバー
AMI
SnapshotEBS
EC2
ブート
領域
EBS
データ
領域
Snapshot
EBS
データ
領域
新たな仮想ディスクで
復元時にサイズアップ
EC2
Small
EC2
xLarge
起動
インスタンスタイプ変更
入門パターン
マシンイメージとして登録
EBS(仮想ディスク)
EC2仮想サーバー
AMI(マシンイメージ)
Snapshot
(EBSのスナップショット)
ポイント
• 独自マシンイメージを作れる
• マシンイメージを元に複数の仮想サーバー
を立ち上げられる
• 後からマシンのスペックを変えられる
• 後からデータ容量を増やせる

7. オートスケーリング＆ロードバランサー
入門パターン
ELB
EC2
AMI
CloudWatchAlarm
EC2
EC2仮想サーバー
AMI(マシンイメージ)
ロードバランサー
CloudWatchAlarm(監視通知
サービス)
起動
EC2
起動
監視
MultiServer パターン
ELB
EC2 EC2
Auto Scaling Group
Scale Out パターン
ポイント
• メトリクスを元に仮想サーバーの数を自動的に調整
するオートスケーリングはクラウドの最大の特徴
• オートスケーリングとロードバランサーの組み合わ
せが鉄板

8. Webストレージ
入門パターン
Amazon S3 EC2
PNG
MP4
html
WebStorage パターン
EC2 Amazon S3
Private Distribution パターン
認証Token
取得
Token認証付
きでアクセス
EC2仮想サーバー
Amazon S3(Webストレージ)
ポイント
• Webストレージは簡易Webサーバーとして
の機能がある
• Token認証URLによるアクセス制限をかけ
ることができる

9. CDN(Contents Delivery Network)
入門パターン
EC2 Amazon S3
Private Cache Distribution パターン
制限付
URL取得
制限付URLで
アクセス
CloudFront
EC2 Amazon S3
URL Rewrite パターン
CloudFront
Upload(同期)
PNG
MP4
HTML中の静的コ
ンテンツのURLを
CDNのURLに書き
換える
EC2仮想サーバー
Amazon S3(Webストレージ)
CloudFront(CDN)
ポイント
• Webストレージの前にCDNをおく構成は
クラウドの典型的パターンの一つ
• アクセス制限をかけたい場合はCDNの
Token認証URL機能を使用

10. クラウド利点活用パターン

11. 高可用性パターン
Multi-Datacenter パターン
ELB
EC2
Availability Zone - A
EC2
Availability Zone - B
Route 53
Server Swapping パターン
EC2
AMI
EBS
データ EC2
マシンイメージを
作成しておく
①障害発生！
②新しい仮想サー
バー起動
③マウント
クラウド利点活用パターン
EC2仮想サーバー
Amazon Route53(DNSサービス)
ロードバランサー
EBS(仮想ディスク)
AMI(マシンイメージ)
or
ポイント
• DR構成の作成がとても簡単
• マシンイメージさえ作っておけば、障害が
起きてもなんとかなる

12. スケーリングパターン
クラウド利点活用パターン
SQS
Amazon EC2
message
Amazon EC2
message
SQS
Amazon EC2
messagemessage
Queuing Chain パターン
EC2仮想サーバー
ロードバランサー
EBS(仮想ディスク)
AMI(マシンイメージ) SQS(SimpleQueueサービス)
ポイント
• キューを上手に使って高負荷のタスクだけ
をスケールアウト
• キューとオートスケーリングの組み合わせ、
これ最強。課金低く、処理は速く！
Job Observer パターン
Auto Scaling Group
EC2
Queue
Message
Amazon SQS
Auto Scaling Group
EC2
Scaling
Policies
CloudWatchAlarm
①キューの閾値
をチェック
追加

13. Bootstrap パターン
スケーリングパターン
クラウド利点活用パターン
AMI
EC2
Amazon S3
①起動
②設定値読み込み
Gitなど外部
サービス
③設定
WAF Proxy パターン
ELB
WAF
Proxy
WAF
Proxy
EC2 EC2
WEB WEB
EC2
Auto Scaling Group
ポイント
• マシンイメージの更新についても考えてお
かないと、後で苦労する
• 何も考えずにスケールアウトすると、有償
のアプリケーションのライセンス費用が恐
ろしいことになる
EC2仮想サーバー
ロードバランサー
AMI(マシンイメージ)
Amazon S3(Webストレージ)

14. WebStorage
Web Storage Archive パターン Write Proxy パターン Storage Index パターン
EC2
Amazon S3
ログ
削除
アーカイブ
EC2
ログ
削除
アーカイブ
Amazon S3
EC2
①アップロード
②受信（圧縮して
あったら解凍）
③高速プロトコル
で転送
クラウド利点活用パターン
DynamoDB(KVS)
EC2 Amazon S3 EC2
①アップロード
②保存
③メタ情
報を格納
④検索
⑤メタ情報を検
索してS3のパ
スを取得
⑥取得
ポイント
• WebStorageは安いことが最大の売り
• でも書き込みが遅い（その代わりに三重化
されており、データ損失しない）
• 柔軟な検索を行うためには一工夫が必要
EC2仮想サーバー
Amazon S3(Webストレージ)
DynamoDB(KeyValueストア)

15. 今回ご紹介しなかったパターン達
• Scheduled Scale Out パターン
 スケールイン・アウトをメトリクスではなく、設定したスケジュールを元に行うこ
とで、あらかじめ予測された高負荷に備える
• Scheduled AutoScaling パターン
 仮想サーバーの立ち上げ、削除を時刻を元に行う（日次・月次バッチなどに用い
る）
• Cache Distributionパターン
 CDNを用いて、地理的に近い箇所からの配信を可能に。CDNそのものの機能。
• DB Replicationパターン
 Multi-AZによるHA構成は、MySQL、PostgresSQL, Oracleだとウィーザードで選
択することで簡単に設定できるが、SQLServerにはそのオプションがない。ひどい
扱い。
• Read Replicaパターン
 読み取り専用のレプリカの作成によるパフォーマンス改善。こういう機能があるよ、
という説明。右クリックで簡単作成可能。
 同期はマスターが更新された後に非同期にレプリカに同期されるので、マスターと
は内容がずれちゃうことを前提にしないといけないです。

16. 今回ご紹介しなかったパターン達
• Floating IPパターン
 仮想サーバーは起動しなおすとIPが変わってしまう。ElasticIPを使うと固定のIPを振
れる。障害発生時にはこのIPを他のサーバーに割り当てることで素早い復旧を可能
とする。
• Sharding Writeパターン
 DBサーバーにシャーディングソフトウェアをインストールし、水平分割したデータ
のバックエンドにDBサービスを利用する
• Stack Deploymentパターン
 AWSのCloudFormationサービスそのもの。インスタンスの作成、その作成順をテン
プレート化しておき、それを起動することでまとまった環境を作成可能にする。
Azureではオートメーションがこれに相当する。
• Weighted Transitionパターン
 Route 53の重み付けラウンドロビンの使い方例。オンプレからクラウドへ、または
クラウド上のシステム全体を他のリージョンに移すときとかに用いる。Azure Traffic
Managerでも同じ機能あり。
• CloudHubパターン
 VPNハブをクラウド上の仮想ネットワークサービスを用いて構築する。

17. 今回ご紹介しなかったパターン達
• State Sharingパターン
 スケールアウト/イン時に備え、セッション情報をKVSに格納する。
• Cache Proxyパターン
 Webサーバーの前段にCacheサーバーを配置する。（CDNじゃなくてCacheサー
バー。）
• Rewrite Proxyパターン
 URL Rewriteパターンを用いた時に、静的コンテンツのURLの書き換えのための
Proxyサーバーを用意する。
 Proxyサーバーをスケーリングできるようにするために、Proxyサーバーの前段
にロードバランサーを置く。
• Inmemory DB Cacheパターン
 キャッシュサービスを用いて、クエリ結果を保存する
• Functional Firewall パターン
 セキュリティグループという仮想的なファイアウォール機能がある。
 Web,DBなど機能別にサーバーをグルーピングして、IPアドレスやポートで設定する。

18. 今回ご紹介しなかったパターン達
• Operational Firewall パターン
 セキュリティグループを使うファイアウォール機能を利用して、各組織がアクセス可能なリソー
スを制限する。
 セキュリティグループを複数適用できる、という使用例。
• Backnet パターン
 管理用ネットワークとしてNICを公開用とは別にもう一つ用意する。（Azureでも複数NICはサ
ポート済み。ただし管理ポータルからは設定不可）
• Rename Distribution パターン
 CDNにキャッシュされたデータをパージするのではなく、ファイル名を変更することでクライア
ントに最新データを送出する。ベースコンテンツはキャッシュしないか、TTLを短く。（JSファ
イルや画像の後ろのクエリ文字列でバージョン管理と似た発想）
• Ondemand NAT
 セキュアなシステムでは、各サーバーのインターネットへのアクセス（アウトバウンド）を禁止
していることが多い。その場合、OSパッケージのアップデートなど、インターネットへアクセス
する必要があるメンテナンス作業ができなくなる。
 VPC(Azureでいうところの仮想ネットワーク）でPrivateCloudを構築した場合に、OSやミドル
ウェアのアップデートを行うために期間限定のNATサーバーを立ち上げる。更新終了後は元に戻
す、というパターン。
• Multi Load Balancerパターン
 デバイスごとにSSL証明書を変えたい、セッション設定を変えたい場合に、複数の仮想ロードバ
ランサーをそれぞれ用に用意する

19. 今回ご紹介しなかったパターン達
• Direct Hosting パターン
 スケールイン・アウトをメトリクスではなく、設定したスケジュールを元
に行うことで、あらかじめ予測された高負荷に備える
• Direct Object Upload パターン
 仮想サーバーの立ち上げ、削除を時刻を元に行う（日次・月次バッチなど
に用いる）
• Clone Server パターン
 Auto Scallingグループによる設定をしていない場合に手動でスケーリング
するパターン。
• Priority Queueパターン
 処理の優先度付けをキューで実現する。こっちのキューは優先度高、だか
ら仮想サーバー沢山。もう１つのキューは優先度低、だから仮想サーバー
少なめ、とすることで差を出す。
• NFS Sharingパターン
 読み書きが必要な共通のコンテンツは外だししておかないと、サーバーに
よって挙動が変わってしまうから気を付けましょう、というパターン。

20. 今回ご紹介しなかったパターン達
• NFS Replicaパターン
 NFS Sharingパターンの発展形。NFSがボトルネックになってしまった場合、
各スケールした仮想サーバーにデータをプッシュして同期させる。
• Cloud DIパターン
 スケールアウトしたサーバごとに異なる固有情報を持たせたい場合（DB
の参照先とか、マシン名とか）、サーバーにつけたタグを元に固有情報を
外部に保存しておき、アプリケーションがそれを元にセットアップする、
というパターン。
• Deep Health Checkパターン
 システム全体としての稼働を保証するために、使用している全サービスを
上から下までテストした結果をWebステータスとして返す。システムに問
題がある場合はELBで正常なシステムに振り分ける。
• Monitoring Integrationパターン
 クラウドのサービスが公開しているメトリクスだけだと仮想サーバー内の
アプリケーションログやミドルウェアの情報を取得できないので別途監視
ソフトを入れた仮想サーバーが必要。モニタリング先が複数になって管理
が面倒なので１つにまとめる。

21. AWSパターンから見たクラウドの利点と弱点
利点
1. スモールスタートが可能である
 マシンイメージを元にスケーリングできる
 スケールアップも可能（水平じゃなくたってOK）
2. 複数のサービスを組み合わせれば、なんでもできちゃう
 パフォーマンスへの対応もCDNで、とか
3. 高可用性の担保がとても簡単
 オンプレで複数サーバー用意するより簡単
 DR構成も簡単
4. リリース後のパフォーマンス対応がしやすい
 キューを用いて高負荷のタスクだけを切り出してスケールアウトすることでス
ループットをあげることができる
5. Webストレージはとにかく便利
 大容量、安い、簡易的なWebサーバーになる

22. AWSパターンから見たクラウドの利点と弱点
弱点
1. 水平スケーリングとの相性の悪いものがある
 元となるマシンイメージの変更への対応を最初から考えおかなければな
らない
 有償ソフトのコストへの考慮
2. Webストレージへの書き込み速度は遅い
 サービスイン時までに大量のコンテンツをアップロードしなければ
ならない場合は致命的なことがある

23. Azure クラウドデザインパターン
• AWS, Azureのクラウドデザインパターンの違い
• AWSクラウドデザインパターンについて
1. 入門パターン
① 仮想サーバー
② オートスケーリング＆ロードバランサー
③ Webストレージ
④ CDN
2. クラウド利点活用パターン
① 高可用
② スケーリング
③ WebStorage
④ その他
3. 今回紹介しなかったパターン
4. まとめ
• Azureクラウドデザインパターンについて
1. SLA100%未達への対処
2. スケーリングへの対処
3. 今回紹介しなかったパターン
4. まとめ

24. SLA100%未達への対処

25. SLA100%未達への対処
Retry パターン

26. Circuit Breaker パターン
SLA100%未達への対処
成功の閾値に
達した
失敗の閾値に
達した
操作が失敗した
タイムアウトタ
イマーが期限切
れになった

27. SLA100%未達への対処
長時間トラン
ザクションの
各手順の逆向
きの操作を記
録
フライトF1の
座席を予約
フライトF2の
座席を予約
フライトF3の
座席を予約
ホテルH1の
部屋を予約
ホテルH2の
部屋を予約
補正ロジック 補正ロジック 補正ロジック 補正ロジック 補正ロジック
旅行プランをキャンセルする補正トランザクション
逆向きの操作につい
てビジネスルールと
して適用する補正ロ
ジック
Compensating Transaction パターン
旅行プラン作成の操作手順

28. SLA100%未達への対処
サービスの活用
Health Endpoint Monitoring パターン

29. スケーリング時の問題対処

30. スケーリング時の問題対処
OnStart時
にリソース
の初期化
Runでタスク
を作成して完
了を待つ
OnStop時にリソース
のクリーンアップ
Compute Resource Consolidation パターン

31. スケーリング時の問題対処
External Configuration Store パターン
外部の構成ストア
代替オプション

32. スケーリング時の問題対処
Runtime Reconfiguration パターン
構成情報
update
構成情報
ファイル
実行中に
変更を反映
アプリケーション
再起動
実行中の反映が
できないので
変更をキャンセル

33. 今回ご紹介しなかったパターン達
• 1.Cache-Asideパターン
 リード・スルー（キャッシュがない場合はデータソースから読み込み）、ライト・
スルー（データ・ソースへの変更時にキャッシュを破棄）に対応していないキャッ
シュを使用する場合の実装パターン。
 AWSパターンのInmemory Db Cacheパターンと同じに見えるが、こちらはデータ更
新時の挙動まで考慮してある。 （データソースだけ更新し、キャッシュは削除する）
• 6.Command and Query Responsibility Segregation(CQRS)パターン
 データの読み取りと更新処理を完全に分離するパターン。表示のパフォーマン
スを最大化できるので最近流行りのパターン。
 結果整合性が適用できる場合にしか用いないこと。
 一般的にEventSourcingパターンと同時に使われる。
• 7.Event Sourcingパターン
 CRUDシステムのせいでパフォーマンス、応答性に問題がある場合で、複数
ユーザーによるデータ更新の競合がある場合に用いる。
 リソースに対する操作を保存しておく。
 リソースに対する操作の結果は、マテリアライズドビューとして保存して外部
からは使用する。
 CQRSパターンと、MaterializedViewパターンと組み合わせるのが王道。

34. 今回ご紹介しなかったパターン達
• 9.Federated Identity パターン
 認証機能を外部に任せ開発ボリュームを減らす。またユーザー管理の
運用コストを下げる。シングルサインオンの実現。
 今時のGoogle認証とかの外部認証を使用する、もしくは自前で認証
サーバーを持つ形になる。
• 10.Gatekeeper パターン
 不正なリクエストからアプリケーションやサービスを保護するために、
前段にゲートキーパーを挟みこむ。
 構成的にはAWSパターンのWAF Proxyパターンと全く同じ。目的が異
なるが。
• 12.Index Table パターン
 データストアはプライマリインデックスを持つが、RDBMSのようにセ
カンダリインデックスを持つとは限らない（例えばNoSQL）。このパ
ターンではセカンダリインデックスを元のデータ（FactTable）とは別
のインデックステーブルに保持することで、検索の高速化を図る。
• 14.Materialized View パターン
 データソースに対して、複雑なクエリを返すと時間がかかるので、あ
らかじめ結果を保持しておく。

35. 今回ご紹介しなかったパターン達
• 20.Scheduler Agent Supervisor パターン
 Retryで済まないような永続的なエラーが発生した場合に、そのエラーに
対する挙動を決定するための戦略パターン。３つのロールを用いて構成す
る。
1. スケジューラー。ワークフローを構成し起動する。各タスクの状態をStore
に格納。
2. エージェント。サービスの呼び出しを担当する。タスクによって呼ばれる。
ほぼタスクと同義。
3. スーパーバイザー。Storeされたタスクの状態を監視。処理失敗のタスクの挙動を
決定する。
• 21.Sharding パターン
 単一DBの性能限界がきたら、DBもスケールアウトすることになる
（Sharding）。だが、欲しいデータはどこにある？
 Shardキーを外部テーブルに持つ。
1. ルックアップ…Shradキー１つ１つが、どこのShardにデータがあるかを持つ。
データの管理が必要。SPOFになるのでレプリカしないといけない。
2. レンジ…データのレンジ（例えば月で）で、どこのShardにデータがあるかを持つ。
ホットスポットになりやすい。（特定にShardにデータが集中する）
3. ハッシュ…ShardキーをHash値とする。Shard別のデータが均等に分散される。
データの管理は必要ない。ただ計算するだけだから。データの場所はランダムな
のでリバランスが難しい。

36. 今回ご紹介しなかったパターン達
• 23.Throttling パターン
 いかにAutoScallingで大量リクエストをさばけるとしても、インスタンスを立ち上げてい
る途中は処理できない。SLAを担保するためにはそのインターバル中にサービスがリソー
ス不足となることを防ぐために、大量リクエストがサービスに到着する前にリクエストを
拒否する。
 一般的なWebサーバーならThrottling設定ができる。

37. Azureパターンから見たクラウドの利点と弱点
• 弱点
1. SLA100％ではない
 いつサービスが落ちていても良いような実装をしておかなければなら
ない。
 Retryし続けてはいけない。呼び出し元のリソースを圧迫しないために
もいつまで呼び出し続けるのか、いつになったらまた呼び出すのか、
仕掛けを入れておく必要がある。
 外部サービスを使用することが多いため、トランザクションはかけら
れない。どうやって元に戻すのか、方法を考える必要がある。
 結果整合性の採用検討を。(逆に全てに採用してはダメ)
 複数のサービスを組み合わせる、ということはSLAはどんどん下がっ
ていく。システムが正常に稼動していることを確認するためには呼び
出し先まで含めて常にチェックしなければならない。

38. Azureパターンから見たクラウドの利点と弱点
• 弱点
2. 安易なスケーリングは危険
タスクを細かく分割し過ぎると、とてもコストがかかる。
タスクをキューでつないでスケーリング、は確かにクラウ
ドの鉄板パターンだけどコストと無関係ではなくなった、
ということを忘れずに。
• でも組み合わせをあらかじめ決めるのはかなり難しい・・・。
» 事実上不可能。やってみなければわからないので、サンプル
作成を。
» 可能なら、後で分離や統合ができるようなソフトウェアアー
キテクチャを構築
スケーリングをする、ということは管理対象のサーバーが
莫大な量になるということ。
• アプリケーションの構成情報は、外部にもち、かつ動的に変更し
たい場合は変更イベントをハンドリングして即時反映するのか、
再起動が必要なのか。実装が必要。

39. ご清聴ありがとうございました！
株式会社NEXTSCAPE
上坂貴志でした！