More Related Content
Similar to デザインパターンから見た AWS と Azure (20)
More from Sunao Tomita (20)
デザインパターンから見た AWS と Azure
- 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
- 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
- 37. • キャッシュを活用する
– 全てをデータベースに頼らない
• キューを活用する
– 疎結合にすることでリソースを調整可能に
– 同期が必要ない部分はなるべく非同期に
• トラフィックを他のサービスにオフロード
– ストレージやCDNを活用してアプリケーションサー
バーに頼り過ぎない
• アプリケーションとしてのヘルスチェック
– アプリケーションサーバーだけが動作していても
アプリケーションとしての機能は果たせない
37
クラウドらしい設計とは?
- 41. Let’s dream and then let’s build.
- Ray Ozzie
冨田 順 (@harutama)
http://twitter.com/harutama