Más contenido relacionado La actualidad más candente (20) Similar a A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた (20) A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた1. AWS のクラウドデザインパターンを
Windows Azure に持ってきてみた
Japan Windows Azure User Group
Microsoft MVP for Windows Azure
冨田 順
http://twitter.com/harutama
10. Windows Azure に無いもの
Direct
CloudWatch Auto Scaling Elastic IP Route 53
Connect
Simple Identity and Elastic Simple Simple
Workflow Access Network Notification Email
Service Management Interface Service Service
Import/Ex Mechanical Security Availability
port Turk Group Zone 10
18. Snapshot
Stamp
Scale Up
Ondemand Disk
基本
18
20. Snapshotパターン
クラウド上で仮想サーバーの
データ(OS含む)やその他の
データをインターネットスト
レージに複製するのは簡単で、
スナップショットを定期的に実
施する負担は小さい。
クラウドでのスナップショッ
トは管理画面でワンクリックす
るだけで取得できるほか、API
を使用して取得することもでき
る。つまりプログラムを使用し
て自動化できるということだ。
20
23. Stampパターン
一度OSやミドルウエア、ア
プリケーションの設定を行って
しまえば、それらをコピーして
おき、あたかも「Stamp(スタ
ンプ)」を押すかのように仮想
サーバーを複製することで、環
境設定済みの仮想サーバーを大
量に用意できる。
クラウドではサーバーやディ
スクなどのリソースを論理的に
扱えるため、こういった作業を
容易に行うことができる。
23
25. Sysprep の役割
• 複数のディスクイメージが作成された際
に、矛盾が起こらないようにするコマン
ド。
– コンピュータ名
– 一意なSID(セキュリティID)
– ドライバキャッシュ
• インスタンスの元になるイメージは、必ず
Sysprep を実行しないと競合が起こる。
– http://technet.microsoft.com/ja-jp
/library/dd744263(v=WS.10).aspx
25
28. Scale Upパターン
仮想サーバーのスペック
(CPU、メモリーサイズな
ど)を必要に応じて切り替える
ことが可能である。
稼働後にリソース不足に陥っ
た場合、従来は物理サーバーを
交換してOSを再インストール
することが必要だったが、クラ
ウドでは必要ない。
ひとまず仮想サーバーを起動
してシステムを稼働し、リソー
ス利用量を確認しながらサー
バースペックを変更する。
28
30. Ondemand Diskパターン
クラウドでは仮想ディスクを
利用できる。
仮想ディスクは、いつでも好
きなタイミングで必要なだけの
容量を確保可能である。
仮想ディスクを利用すれば、
前もって精緻に見積もらなくて
もよい。システムを稼働させた
後に利用量を見ながら必要な容
量のディスクをオンデマンド
(OnDemand)に確保すればよ
い。
30
34. DB Replication
Read Replica
Inmemory DB Cache
Sharding Write
リレーショナルデータベース
34
36. データベースサービス比較
SQL Database RDS
インスタンス構成 専用の構成 EC2ベースの仮想マシン
パッチの適用 自動 自動 or 手動
レプリケーション 標準で3重化 ユーザーが構成
スケジュール指定の自動
バックアップ 手動バックアップ
手動バックアップ
Federation DBMSの機能や
シャーディング
により提供 周辺ソフトで対応
基本的に変更不可能 パラメータグループで
パラメータの変更
自動チューニング ある程度変更可能
容量の制限 150GBytes 実質 無制限
36
37. Replicationパターン
地理的ロケーションをまたい
だレプリケーションを行うパ
ターン。
このパターンによりデータロ
ストを防ぎ、データアクセスの
可用性を担保する。クラウド以
前からもあったパターンである
が、クラウドを用いることで安
価に複数の地理的ロケーション
を利用できるようになり、現実
的な選択肢となった。
37
38. Read Replicaパターン
読み込みを複数の「リードレ
プリカ(読み込み用のレプリ
カ)」に分散させることで、全
体のパフォーマンスを向上して
いる。
リードレプリカは、マスター
に対する書き込みに追随する形
で、自分自身のデータを反映さ
せる。
読み込みは主にリードレプリ
カを利用することで、マスター
の負荷も減らすことになる。
38
39. SQL Databaseでの
レプリケーション
• プライマリと2台のセカンダリによって、
保持しているデータは複製されている。
– いずれかのマシンが停止した場合、自動的に
昇格され、新たなレプリカを作成し、常に3台の
マシンでデータが
分散される。
– ユーザーは何も
する必要はない。
– ただしAZの概念は
無い。
39
41. Sharding Writeパターン
複数のデータベースサーバー
で書き込みパフォーマンスを上
げる方法に「シャーディング」
がある。
基本的には、同じ構造のデー
タベースを用意して適切なテー
ブルのカラムをキーにして分割
し、書き込み処理を分散する。
クラウドが提供するRDBMS
サービスを用いれば、可用性が
高く、運用効率もよいシャー
ディングが可能になる。
41
42. SQL Database Federation
• SQL Database の上でシャーディングを行
うための仕組み
– SQL Database Federation の仕様
http://msdn.microsoft.com/ja-jp
/library/windowsazure/hh700294.aspx
– SQL Azure Federation入門
http://www.atmarkit.co.jp/fdotnet/bookpreview/i
ntrowinazure_0404/introwinazure_0404_01.ht
ml
42
43. もっと Federation!
• SQL Azureを徹底活用
– 第7回 スケールアウトとSQL Azure Federation
http://gihyo.jp/admin/serial/01/sql_azure/0007
– 第8回 SQL Database Federationを使用する
ための最初の一歩
http://gihyo.jp/admin/serial/01/sql_azure/0008
– 第9回 SQL Database Federationをスケールさせる
http://gihyo.jp/admin/serial/01/sql_azure/0009
43
45. SQL Database の注意点
• 提供されるもの
– データベースエンジン
– レポーティング (SQL Reporting)
– データ同期 (SQL Data Sync)
• 現状で未サポートの機能
– Server Agent、SQL CLR など
– バックアップと復元
• 管理ポータルからインポート・エクスポート可能
– テーブル パーティション分割
• Federationで対応
http://msdn.microsoft.com/ja-jp/library/windowsazure/ff394102
45
46. SQL Server 版 RDS の注意点
• 提供されるもの
– データベースエンジン
– フルテキスト検索
– Safe SQL CLR
• SQL Databaseでは未サポートの機能
• 現状で未サポートの機能
– Replication、Server Agent、Reporting など
• Replication は SQL Database 標準機能
• Windows Azure ではSQL Reportingとして提供
http://docs.amazonwebservices.com/AmazonRDS/latest/UserG
uide/Concepts.DBEngine.SQLServer.html 46
48. 仮想マシンサービスの比較
Virtual Machines EC2
インスタンス構成 仮想マシン 仮想マシン
パッチの適用 手動 手動
レプリケーション ユーザーが構成 ユーザーが構成
バックアップ ユーザーが構成 ユーザーが構成
シャーディング ユーザーが構成 ユーザーが構成
パラメータの変更 すべて自由 すべて自由
48
49. RDBを利用する際の候補
データベースサービス 自
動
運
用
RDS SQL Database
仮想マシンサービス
自
由
度
EC2 Virtual Machines
50. Inmemory DB Cacheパターン
データベースからの読み込み
パフォーマンスを向上にする方
法として、頻繁に読み込まれる
データをメモリーにキャッシュ
するのがこのパターンである。
一度利用したデータをキャッ
シュしておくことで、次に使う
ときに(ディスクからでなく)
メモリーからの読み込みで済ま
せる方法である。
キャッシュするデータの典型
的な例としては、データベース
処理において時間のかかるクエ
リーの結果や複雑な計算結果な
どが挙げられる。 50
52. 新しい Caching
• 旧 AppFabric Caching で提供されていた
キャッシュの機構とは異なる
– Cloud Services (Web ロール・Worker ロール)の
メモリを利用してデータをストア
• ロールインスタンスのメモリを一部使用
• キャッシュ専用ロールインスタンス
– memcached 互換のプロトコルをサポート
– 現在は Preview Release 中
52
55. Web Storage
Direct Hosting
Private Distribution
Cache Distribution
Rename Distribution
静的コンテンツを処理
55
57. Web Storageパターン
大容量のファイルをインター
ネットストレージへ配置し、そ
こから直接ファイルを配信する
ことで、Webサーバーのネット
ワーク負荷とディスク容量の問
題を解決する。
インターネットストレージに
保存したオブジェクトは、公開
設定にすることでユーザーに直
接アクセスさせることができ
る。これを利用してインター
ネットストレージから配信する
ように、Webサーバーのネット
ワーク負荷を下げることができ
る。 57
59. Direct Hostingパターン
クラウドが提供するインター
ネットストレージから直接デー
タを配信する。
インターネットストレージに
保存したオブジェクトを公開設
定にすることで、インターネッ
トストレージ上のデータに直接
アクセスさせることができる。
インターネットストレージは
元々共有ストレージとして使用
される前提で設計されているの
で、キャパシティー面では問題
ない。負荷対策を行う必要が無
くなる。
59
62. Private Distributionパターン
インターネットストレージで
提供される制限付きURL発行機
能を用いると、コンテンツに対
して、アクセス元IPアドレスや
アクセス可能期間を設定でき
る。
ユーザーごとにURLを発行
し、その制限付きURLでのみコ
ンテンツをダウンロードするよ
うにすれば、期限が切れたリン
クや異なるIPアドレスを持つ人
がアクセスを試みてもダウン
ロードできない。実質的に特定
ユーザーにのみコンテンツを提
供することが可能になる。 62
63. Shared Access Signature
日経システムズ「クラウド設計のデザインパターン」
http://itpro.nikkeibp.co.jp/article/COLUMN/20110713/362355/
63
64. Cache Distributionパターン
世界各地に配置されたロケー
ションに、コンテンツ配信元
(マスター)から配布されるコ
ンテンツのキャッシュデータを
配置する。
こうすることで、地理的によ
り利用者に近いロケーションか
らコンテンツを配信することに
なり、地理的/物理的な制約を
解決できる。
このパターンを適用すると、
ユーザーとコンテンツの距離が
短くなるので、ユーザーへのレ
スポンスを向上させることがで
きる。 64
65. CDN
• コンテンツデリバリネットワーク = CDN
– ユーザーが要求するコンテンツを、ネットワーク
的に近い場所にあるキャッシュサーバーから配信
することで、速度の向上と、サーバーへの負荷を
分散させる。
http://www.geekpage.jp/blog/?id=2009/4/27/1
65
68. CDNの有効化
• 詳細な手順は以下を参照
– http://buchizo.wordpress.com/2011/03/10/%E8%AA%B0%E3%82%82%
E7%9F%A5%E3%82%89%E3%81%AA%E3%81%8B%E3%81%A3%E
3%81%9Fwindows-azure-cdn/
<asp:Image ID="Image1" runat="server"
ImageUrl="http://harutama.cloudapp.net
/iremono/pic1.jpg" />
<asp:Image ID="Image1" runat="server"
ImageUrl="http://az4452.vo.msecnd.net
/iremono/pic1.jpg" />
68
70. Rename Distributionパターン
エッジサーバー上のキャッ
シュデータは、そこにアクセス
するURLがキーになる。
アクセスURL自体を変更する
ことで、エッジサーバーの
キャッシュタイムアウトにかか
わらず新しいコンテンツを配信
できる。
70
71. Revving Filenames
「/v~/」の部分を変えるだけで
配信ファイルをコントロール
http://example.com/v1/pic.jpg
http://example.com/v1/pic.jpg
RewriteEngine on
配信するファイルの管理は RewriteRule ^/v[0-9]*/(.*) /$1 [PT]
このURLの実体を変更する
http://example.com/pic.jpg
http://5net.com/blog/2012/03/reducing-operational-task-by-revving-filenames-
in-cloudfront-with-ec2.html#more
71
72. Rewrite Module for IIS 7
http://www.microsoft.com/ja-jp/download/details.aspx?id=7435
72
75. Let’s dream and then let’s build.
- Ray Ozzie
冨田 順 (とみた すなお)
http://twitter.com/harutama/
http://d.hatena.ne.jp/haru-tama/
75