デザインパターンから見た AWS と Azure
•
66 likes•14,302 views
2014年6月26日「Microsoft Architect Boot Camp セミナー」でのスライド
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to デザインパターンから見た AWS と Azure
Similar to デザインパターンから見た AWS と Azure (20)
More from Sunao Tomita
More from Sunao Tomita (20)
Recently uploaded
Recently uploaded (9)
デザインパターンから見た AWS と Azure
- 1. デザインパターンから見た AWS と Azure Japan Azure User Group Microsoft MVP for Microsoft Azure 冨田 順 http://twitter.com/harutama
- 2. 自己紹介 • はるたま（@harutama） – 冨田 順（とみた すなお） – 職業：プロ社畜 – Microsoft MVP for Microsoft Azure • Azureのコミュニティやってます – http://r.jazug.jp/ • クラウドごった煮の中の人もやってます – http://www.cloudmix.jp/ 2
- 5. パターン一覧 • 基本のパターン – 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
- 9. パターンの一覧 パターン • 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. ここで一度考えてみる 10
- 11. パターンの分類 • AWS – 基本 – 可用性を向上 – 動的コンテンツを処理 – 静的コンテンツを処理 – データをアップロード – リレーショナル データベース – 運用保守 – ネットワーク • Azure – 設計と実装 – 可用性 – データ管理 – パフォーマンスと スケーラビリティ – メッセージング – 回復性 – 管理と監視 – セキュリティ 11
- 14. AWS:DB Replication パターン • 基本的にはオプションの機能 – 最初から有効にはなっていないので、必要であれば 個別に設定する。 http://aws.typepad.com/aws_japan/2014/05/amazon-rds-for- sql-server-with-multi-az.html 14
- 16. 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
- 19. Azure:SQL データベース • 1つのプライマリーの他に、2つのセカンダ リーが自動的に作成される。 – 3つのデータベースインスタンスは、それぞれ異な る物理マシン上に配置される。 • このレプリケーションの形を変形させることは 基本的にできない。 – セカンダリーを増やすことはできない。 (アクティブなジオレプリケーション機能はプレ ビューで提供中) 19
- 22. 22 だからこんな対立も
- 27. 現実的な事を考えると • ロードバランサーは普通に使っているも ので、否定しているわけではない。 – AWS での ELB (Elastic Load Balancing) – Azure でも各サービスについてくる • 仮想マシン、Web サイト、クラウドサービス • ロードバランサーだけで可用性と信頼性 の問題は解決できている(場合が多い) 27
- 31. キャッシュ 31 Cache-Aside パターンInmemory DB Cache パターン
- 32. 優先度付きのQueue 32 Priority Queue パターンPriority Queue パターン
- 33. Queueで繋げる 33 Pipes and Filters パターン Queuing Chain パターン
- 34. 静的コンテンツ配信 34 Static Content Hosting パターンWeb Storage パターン
- 35. 特定の人へのコンテンツ配信 35 Private Distribution パターン Valet Key パターン
- 36. ヘルスチェック 36 Deep Health Check パターン Health Endpoint Monitoring パターン
- 37. • キャッシュを活用する – 全てをデータベースに頼らない • キューを活用する – 疎結合にすることでリソースを調整可能に – 同期が必要ない部分はなるべく非同期に • トラフィックを他のサービスにオフロード – ストレージやCDNを活用してアプリケーションサー バーに頼り過ぎない • アプリケーションとしてのヘルスチェック – アプリケーションサーバーだけが動作していても アプリケーションとしての機能は果たせない 37 クラウドらしい設計とは?
- 41. Let’s dream and then let’s build. - Ray Ozzie 冨田 順 (@harutama) http://twitter.com/harutama