Embed Size (px)
DESCRIPTION
2014年6月26日「Microsoft Architect Boot Camp セミナー」でのスライド
Citation preview
デザインパターンから見たAWS と Azure
Japan Azure User Group
Microsoft MVP for Microsoft Azure
冨田 順
http://twitter.com/harutama
自己紹介• はるたま（@harutama）
–冨田 順（とみた すなお）
–職業：プロ社畜
– Microsoft MVP for Microsoft Azure
• Azureのコミュニティやってます
– http://r.jazug.jp/
• クラウドごった煮の中の人もやってます
– http://www.cloudmix.jp/
2
AWS のデザインパターン
3
パターン一覧• 基本のパターン
– Snapshotパターン（データのバックアップ）– Stampパターン（サーバの複製）– Scale Upパターン（動的なサーバのスペックアップ／ダウン）– Scale Outパターン（サーバ数の動的増減）– Ondemand Diskパターン（動的なディスク容量の増減）
• 可用性を向上するパターン– Multi-Serverパターン（サーバの冗長化）– Multi-Datacenterパターン（データセンターレベルの冗長化）– Floating IPパターン（IPアドレスの動的な移動）– Deep Health Checkパターン（システムのヘルスチェック）
• 動的コンテンツを処理するパターン– Clone Serverパターン（サーバのクローン）– NFS Sharingパターン（共有コンテンツの利用）– NFS Replicaパターン（共有コンテンツの複製）– State Sharingパターン（ステート情報の共有）– URL Rewritingパターン（静的コンテンツの退避）– Rewrite Proxyパターン（URL書き換えプロキシの設置）– Cache Proxyパターン（キャッシュの設置）– Scheduled Scale Outパターン（サーバ数のスケジュールにあわせ
た増減）
• 静的コンテンツを処理するパターン– Web Storageパターン（可用性の高いインターネットストレージ活
用）– Direct Hostingパターン（インターネットストレージで直接ホス
ティング）– Private Distributionパターン（特定ユーザへのデータ配布）– Cache Distributionパターン（ユーザに物理的に近い位置へのデー
タ配置）– Private Cache Distributionパターン（CDNを用いたプライベート
配信）– Rename Distributionパターン（変更遅延のない配信）
• データをアップロードするパターン– Write Proxyパターン（インターネットストレージへの高速アップ
ロード）– Storage Indexパターン（インターネットストレージの効率化）– Direct Object Uploadパターン（アップロード手順の簡略化）
• リレーショナルデータベースのパターン– DB Replicationパターン（オンラインDBの複製）– Read Replicaパターン（読込専用レプリカによる負荷分散）– Inmemory DB Cacheパターン（頻度の高いデータのキャッシュ化）– Sharding Writeパターン（書き込みの効率化）
• バッチ処理のパターン– Queuing Chainパターン（システムの疎結合化）– Priority Queueパターン（優先順位の変更）– Job Observerパターン（ジョブの監視とサーバの追加・削除）– Scheduled Autoscalingパターン（バッチ処理サーバの自動オンオフ）
• 運用保守のパターン– Bootstrapパターン（起動設定の自動取得）– Cloud DIパターン（変更が多い部分の外出し）– Stack Deploymentパターン（サーバ群立ち上げのテンプレート化）– Server Swappingパターン（サーバの移行）– Monitoring Integrationパターン（モニタリングツールの一元化）– Web Storage Archiveパターン（大容量データのアーカイブ化）– Weighted Transitionパターン（重みづけラウンドロビンDNSを使った
移行）
• ネットワークのパターン– OnDemand NATパターン（メンテナンス時のインターネット設定変
更）– Backnetパターン（管理用ネットワークの設置）– Functional Firewallパターン（階層的アクセス制限）– Operational Firewallパターン（機能別アクセス制限）– Multi Load Balancerパターン（複数ロードバランサの設置）– WAF Proxyパターン（高価なWeb Application Firewallの効率的な活
用）– CloudHubパターン（VPN拠点の設置）
5
全体像
6
http://aws.clouddesignpattern.org/images/a/ac/Cdp-overview-org.png
Azure のデザインパターン
7
8http://msdn.microsoft.com/en-us/library/dn568099.aspx
パターンの一覧パターン• Cache-Aside Pattern• Circuit Breaker Pattern• Compensating Transaction Pattern• Competing Consumers Pattern• Compute Resource Consolidation Pattern• Command and Query Responsibility
Segregation (CQRS) Pattern• Event Sourcing Pattern• External Configuration Store Pattern• Federated Identity Pattern• Gatekeeper Pattern• Health Endpoint Monitoring Pattern• Index Table Pattern• Leader Election Pattern• Materialized View Pattern• Pipes and Filters Pattern• Priority Queue Pattern• Queue-Based Load Leveling Pattern• Retry Pattern• Runtime Reconfiguration Pattern• Scheduler Agent Supervisor Pattern• Sharding Pattern• Static Content Hosting Pattern• Throttling Pattern• Valet Key Pattern
ガイダンス• Asynchronous Messaging Primer• Autoscaling Guidance• Caching Guidance• Compute Partitioning Guidance• Data Consistency Primer• Data Partitioning Guidance• Data Replication and Synchronization
Guidance• Instrumentation and Telemetry Guidance• Multiple Datacenter Deployment Guidance• Service Metering Guidance
9
ここで一度考えてみる
10
パターンの分類
• AWS
– 基本
– 可用性を向上
– 動的コンテンツを処理
– 静的コンテンツを処理
– データをアップロード
– リレーショナルデータベース
– 運用保守
– ネットワーク
• Azure
– 設計と実装
– 可用性
– データ管理
– パフォーマンスとスケーラビリティ
– メッセージング
– 回復性
– 管理と監視
– セキュリティ
11
12
特にデータベースについて
AWS は自分でデータの可用性・回復性を
構成する
Azure はサービスがデータの可用性・回復性を
提供する
AWS:DB Replication パターン
13
AWS:DB Replication パターン
• 基本的にはオプションの機能
–最初から有効にはなっていないので、必要であれば個別に設定する。http://aws.typepad.com/aws_japan/2014/05/amazon-rds-for-sql-server-with-multi-az.html
14
AWS:Read Replicaパターン
15
AWS:Read Replicaパターン
• 基本的にはオプションの機能
–最初から有効にはなっていないので、必要であれば個別に設定する。http://aws.typepad.com/aws_japan/2014/05/amazon-rds-for-sql-server-with-multi-az.html
• 個別で設定できる利点
– MySQL での多段リードレプリケートhttp://dev.classmethod.jp/cloud/aws/evaluate-multistage-rds/
–クロスリージョン・リードレプリカhttp://aws.typepad.com/aws_japan/2013/11/cross-region-read-replicas-for-amazon-rds-for-mysql.html
16
RDS を作成する際の項目
17
使用するインスタンスの大きさを指定
Multi-AZへのデプロイ設定
ストレージのサイズ設定
ストレージのパフォーマンス設定
Azure:SQL データベース
18
http://gihyo.jp/admin/serial/01/sql_azure/0001
Azure:SQL データベース
• 1つのプライマリーの他に、2つのセカンダリーが自動的に作成される。
– 3つのデータベースインスタンスは、それぞれ異なる物理マシン上に配置される。
• このレプリケーションの形を変形させることは基本的にできない。
–セカンダリーを増やすことはできない。(アクティブなジオレプリケーション機能はプレビューで提供中)
19
SQL データベースでのパフォーマンスの考え方
20
21
語弊はありますが…
AWS はインフラエンジニアのためのクラウド
Azure はディベロッパーのためのクラウド
22
だからこんな対立も
AWS:Multi-Serverパターン
23
AWS:Multi-Datacenterパターン
24
Azure:Circuit Breakerパターン
25
Azure:Circuit Breakerパターン
Webサーバーをさらに追加したり負荷分散を実装したりすることで、システムをスケールすれば、リソースが枯渇する状況を先送りできる場合もあります。
しかし、依然としてユーザーのリクエストが反応しない状態となり、全てのWebサーバーが最終的にはリソース不足に陥る可能性があるので、問題の解決にはなりません。
26
現実的な事を考えると
• ロードバランサーは普通に使っているもので、否定しているわけではない。
– AWS での ELB (Elastic Load Balancing)
– Azure でも各サービスについてくる
• 仮想マシン、Web サイト、クラウドサービス
• ロードバランサーだけで可用性と信頼性の問題は解決できている(場合が多い)
27
でも、将来は状況が違うかも…
28時間
ここまでならロードバランサー
だけで
ロードバランサーだけだと
怪しくなってくる
アプリに手を入れないと無理
トラフィック
29
可用性・回復性をどう解決するか?
30
お互いに分かり合えないわけではない
キャッシュ
31
Cache-Aside パターンInmemory DB Cache パターン
優先度付きのQueue
32
Priority Queue パターンPriority Queue パターン
Queueで繋げる
33Pipes and Filters パターン
Queuing Chain パターン
静的コンテンツ配信
34
Static Content Hosting パターンWeb Storage パターン
特定の人へのコンテンツ配信
35
Private Distribution パターン Valet Key パターン
ヘルスチェック
36
Deep Health Check パターン
Health Endpoint Monitoring パターン
• キャッシュを活用する– 全てをデータベースに頼らない
• キューを活用する– 疎結合にすることでリソースを調整可能に
– 同期が必要ない部分はなるべく非同期に
• トラフィックを他のサービスにオフロード– ストレージやCDNを活用してアプリケーションサーバーに頼り過ぎない
• アプリケーションとしてのヘルスチェック– アプリケーションサーバーだけが動作していてもアプリケーションとしての機能は果たせない
37
クラウドらしい設計とは?
38
Azure のパターンはソフトウエアの観点からもう少し踏み込んで
Compensating Transactionパターン
39
キーになるのは
40
結果整合性Eventual Consistency
と冪等性
Idempotence
Let’s dream and then let’s build.- Ray Ozzie
冨田 順 (@harutama)http://twitter.com/harutama
