デザインパターンから見た AWS と Azure

Preview:

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

4http://aws.clouddesignpattern.org/

パターン一覧• 基本のパターン

– 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

Recommended