cdp 勉強会 - multiple datacenter deployment ガイダンス
DESCRIPTION
複数のデータセンターにアプリケーションをデプロイすることにより得られる利点と、解決しなければならない課題TRANSCRIPT
JAZUG 第 3 回 CDP 勉強会Multiple Datacenter Deployment ガイダンス2014/10/18
浅見城輝
株式会社 pnop / Cloudlive 株式会社
About me
kuniteru.asami
Find me
DatabaseMicrosoft Azure
© 2011 Microsoft CorporationAll Rights Reserved.
Azure 2012~
JAZUGのご紹介 Japan Azure User Group略称：JAZUG(じゃずゆーじー)
コミュニティ活動概要:「Azureを通じて、技術、交流、実ビジネスを楽しむ。」“ちょっと興味がある=ゆるふわな方”から“実ビジネスで使うんだよね”な方まで大歓迎！ゆるふわコミュニティです。
JAZUGへの参加はFacebookで。Japan Windows Azure User Group（Facebookグループ）https://www.facebook.com/groups/jazug/
JAZUG女子部、大阪(関西Azure研究会)、福岡(ふくあず)、札幌(きたあず)、名古屋(あずちゅう)、仙台、静岡、しなの、青森
Twitter: #jazug 一緒に運営してくれるメンバーを募集中です。
JAZUG のFacebook グループへのご参加をお願いします。
4
https://www.facebook.com/groups/jazug/
本よろしくです！
クラウド デザインパターンAzure を例としたクラウドアプリケーション設計の手引き
http://amzn.to/1oTJNVH
15 人の JAZUG メンバーで半泣きになりながら監訳しました
5@k1hash
内容
クラウド アプリケーション設計の頻出課題集
Software design pattern の Cloud Application 版
• 24のパターン
• 10のガイダンス
• ポスター– http://azure.microsoft.com/en-
us/documentation/infographics/cloud-design-patterns/
kyrt @takekazuomi 6
回答集じゃない
課題が整理され、考慮点について記述されている
• 8の問題領域
• 10の code sample
kyrt @takekazuomi 7
Microsoft Azure 自習書シリーズ
8
http://blogs.msdn.com/b/windowsazurej/archive/2014/06/02/blog-published-azure-self-learning-series.aspx
Azure msdn 自習書
検索
Microsoft Azure スライドシリーズ
9
http://www.slideshare.net/MicrosoftAzure_Japan/presentations
Multiple Datacenter Deployment ガイダンス
今日のゴール
複数のデータセンターにアプリケーションをデプロイすることにより得られる利点と、解決しなければならない課題を理解していただくこと。
複数のデータセンターにシステムをデプロイすることにより、利点を得ることができます。
• 可用性の向上
• 世界的に広い地域でのレスポンスの向上
しかし実現するためには、難易度の高い課題もあります。
• データの同期
• 規制による制限
複数のデータセンターにデプロイする理由
複数のデータセンターにデプロイする理由
時間と共に成長するキャパシティ
ユーザーに最低限の遅延でグローバルリーチを提供
パフォーマンスと可用性の維持
時間とともに成長するキャパシティ
ユーザーに最低限の遅延でグローバルリーチを提供
ユーザーに最低限の遅延でグローバルリーチを提供
パフォーマンスと可用性の維持
パフォーマンスと可用性の維持
複数のアプリケーションデプロイへのリクエストのルーティング
障害時にどうやってトラフィックをリダイレクトするか？
障害時にどうやってトラフィックをリダイレクトするか？
複数のアプリケーションデプロイへのリクエストのルーティング複数のデータセンターにアプリケーションをデプロイしていても、その内の 1 つのデータセンターに障害が発生した場合には、他のデータセンターに自動的にはリダイレクトされません。
アプリケーション障害時の手動再ルーティング
アプリケーション障害時の自動再ルーティング
Microsoft Azure Traffic Manager による再ルーティング
アプリケーション障害時の手動再ルーティング
DNS エントリの変更や、リダイレクトページを利用してこれを手動で変更することで、指定のデータセンターにトラフィックが流れるようにします。
しかし、これらのアプローチには、いくつかの課題があります。
手動再ルーティングの課題 #1障害をすぐに検出することができ、すみやかに手動切り替えを実施できる必要があります。常に稼働している切り替え用のデプロイ（ホットスワップデプロイ）がない場合、それを起動しまた正しく動作していることを検証する必要があります。業務時間外に障害が発生し、担当者がその場にいない場合は、さらに切り替えに遅延が発生することがあります。
手動再ルーティングの課題 #2
DNS エントリを変更することによってリクエストを再ルーティングする場合、その変更が世界中に伝搬するまでに数時間～数日かかることがあります。
手動再ルーティングの課題 #3リダイレクトページや、バックアップ先のデータセンターにリクエストを再ルーティングさせるメカニズムを使用すると、そこが単一障害点になります。リダイレクトページなどにも障害が発生していた場合、バックアップ先のデータセンターにアクセスされません。
手動再ルーティングの課題 #4元々プライマリ側だったデータセンターの障害が復旧した時には、再度ルーティングを戻すように設定を変更する必要があります。DNS によってルーティングを制御していた場合、その設定変更の伝搬に再度、数時間～数日の時間がかかります。
アプリケーション障害時の自動再ルーティング
ルーティング変更のための切り替えの遅延を回避するために、各デプロイの正常性を監視し、最適なデプロイに再ルーティングすることを自動化することが可能です。
自動再ルーティングのメカニズムは、複数データセンターを使用するシナリオにより異なります。
シナリオ 1：災害復旧再ルーティングの自動メカニズムは、バックアップ用のデプロイを起動して動作を確認し、その後、ユーザーからのアクセスをバックアップ側のデプロイにルーティングします。
シナリオ 2：ホットスワップ再ルーティングの自動メカニズムは、バックアップ用のデプロイが正常に動作していることを確認し、ユーザーからのアクセスをバックアップ側のデプロイにルーティングします。
シナリオ 3：グローバルリーチ再ルーティングの自動メカニズムは、リクエストを調査して、正常なデプロイの中から適切な（最も近い）データセンターにルーティングします。
自動再ルーティングの課題 #1自動再ルーティングを司るサーバー自体が単一障害点と成りえます。これを回避するためには、複数のデータセンターに自動再ルーティングを管理するサーバーを配置し、これ自体にDNS ラウンドロビンでリクエストを分散することで可能ですが、構成の変更があった場合に、これらのサーバー同士で同期をとる必要があります。
自動再ルーティングの課題 #2プライマリ側の瞬断や、障害の誤検知により断続的に切り替えが発生してしまうことを防ぐために、再ルーティングを遅らせることを検討する必要があります。この問題への対策は、プライマリ側への接続が複数回連続で失敗してから障害と判断し、切り替えをすることです。
自動再ルーティングの課題 #3元々プライマリ側だったデータセンターの障害が復旧した時には、再度ルーティングを戻す仕組みが必要になります。
Microsoft Azure Traffic Manager による再ルーティングTraffic Manager はアプリケーションの障害検出と動的DNS ルーティングを組み合わせた Azure のインテリジェントな DNS サービスです。
Traffic Manager は選択したポリシーに応じて、ルーティング先のデプロイを決定します。
ラウンドロビンポリシー
フェールオーバーポリシー
パフォーマンスポリシー
ラウンドロビンポリシーTraffic Manager に登録されているデプロイの Endpoint に対して、『順番に』リクエストをルーティングします。
アプリケーションが稼働しているデプロイに均等にアクセスを分散します。
障害を検出したデプロイにはルーティングしないことで、可用性を維持します。
アクセスもとの場所は考慮しないので、遠いデータセンターにアクセスしてしまうことがあります。
フェールオーバーポリシー管理者がデプロイに対するルーティングの優先順位のリストを構成し、Traffic Manager はそのリストの内、障害のない最優先のデプロイにルーティングします。
プライマリデプロイが使用できない場合にのみバックアップにアクセスする、ホットスワップのシナリオにマッチします。
パフォーマンスポリシーユーザーからのリクエストを、ネットワークの遅延が最も小さいデータセンターのデプロイにルーティングします。
障害を検出した場合、そのデプロイの代わりに、ユーザーから次に近いデータセンターのデプロイにルーティングします。
可用性とパフォーマンスが最適な組み合わせとして、このパフォーマンスポリシーを選択することが推奨されています。
複数のデータセンターへのデプロイに関する検討事項
アプリケーションを複数のデータセンターにデプロイする場合、いくつかの課題や検討事項があります。
データセンターの場所とドメイン名
規制または SLA 制限
データ同期
データとサービスの可用性
アプリケーションの構成バージョンと機能
テストとデプロイ
カスタマーエクスペリエンス
ユーザーを規定とは異なる他のデータセンターに再ルーティングした場合は、それを示すメッセージをユーザーに表示するとよいでしょう。
データセンターの場所とドメイン名アプリケーションをデプロイする場所をどのように指定できるかを考慮します。
リージョン、サブリージョンの指定
可用性セットの指定による物理的な分割
※言葉の意味はクラウドプロバイダーにより異なる
規制または SLA 制限SLA や、適用される可能性のある法的規制を考慮する必要があります。
国や地域によっては、特定の地域外へのデータの持ち出しや、データの処理を行うことを禁止されている場合があります。
SLA などにより可用性の要件が定義されていることがあります。その場合、ルーティングの切り替えにかかる時間がこの要件を満たす必要があります。
データ同期ユーザーが POST したデータは、そのユーザーが接続したデータセンターのストレージに保存されます。障害などによりユーザーが依然と異なるデータセンターにルーティングされた場合、そのデータが利用できないかもしれません。
データセンター間のデータの同期が完了していないと、同じデータにアクセスできません。フェールオーバーのシナリオでは、プライマリとバックアップのデータセンターでデータの同期を行う必要があり、また RTO を定義する場合にこれが完了する時間も考慮する必要があります。
データとサービスの可用性設計や構成によっては、すべてのデータセンターで利用することができないデータやサービスがある場合があります。
データの内容を拠点ごとに分割した場合は、データ同期のためのコストを最小化することができますが、別のデータセンターから再ルーティングされたユーザーには必要なデータが不足しているかもしれません。
ひとつのデータセンターにのみデプロイし、そこをすべてのデータセンターから参照している場合、そのサービスが停止するとアプリケーションが障害となります。
アプリケーションの構成バージョンと機能データセンターごとに微妙に異なったアプリケーションをデプロイすることがあります。
グローバルリーチのシナリオで、それぞれのデータセンターにローカライズしたバージョン（対応言語の違い）をデプロイすることがあります。この場合、障害により再ルーティングされると、ユーザーにマッチした言語が提供されない可能性があります。
データセンターごとに正常時の負荷を基に必要最低限のインスタンス数だけを稼働させている場合、オートスケールなどによって障害時の再ルーティング先のデータセンターへのアクセスが向上しても対応できるようにしておきましょう。あるいは、障害時には機能をダウングレードする仕組みを用意し、アクセス量を制限しましょう。
テストとデプロイすべてのデータセンターでアプリケーションが正しく動作することを確認し、更新や障害を管理・計画するために、テストを実施することが重要です。
すべてのデータセンターのアプリケーションを新しいバージョンにアップグレードする方法
複数のデータセンターに対してデプロイ可能なスクリプトやユーティリティのような自動メカニズムを検討しましょう。
データセンターごとに異なるピークタイムを回避するための更新タイミングの調整
一部のデータセンターのみで発生する更新の失敗やパフォーマンスの低下をロールバックする方法を検討しましょう。
一部のデータセンターのサービスを停止して、そのサービス地震の復旧、再ルーティングやフェールオーバー、再ルーティング先のオートスケールのテストをしてください。
カスタマーエクスペリエンス頻繁なデータセンターの切り替えは避けるべきで、プライマリの環境が確実に利用できない場合にのみ切り替えされるべきです。切り替えがされた場合に以下に対応すべきかもしれません。
セッション管理
遅延の増大やパフォーマンスの低下
アプリケーションの不安定さとエラー
関連するパターンとガイダンス
Compute Partitioning ガイダンス
Data Replication and Synchronization ガイダンス
Federated Identity パターン
JAZUG のFacebook グループへのご参加をお願いします。
50
https://www.facebook.com/groups/jazug/
次回予告
第 4 回 クラウドデザインパターン勉強会
http://jazug.doorkeeper.jp/events/16501
2014/11/18(火) 19:30-21:50
• Asynchronous Messaging 入門 第２回
• Data Replication and Synchronization ガイダンス
51
