CDP 勉強会 - Multiple Datacenter Deployment ガイダンス

Slide 1

Slide 1 text

JAZUG 第 3 回 CDP 勉強会 Multiple Datacenter Deployment ガイダンス 2014/10/18 浅見城輝株式会社 pnop / Cloudlive 株式会社

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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  一緒に運営してくれるメンバーを募集中です。

Slide 4

Slide 4 text

JAZUG の Facebook グループへのご参加をお願いします。 4 https://www.facebook.com/groups/jazug/

Slide 5

Slide 5 text

本よろしくです！クラウドデザインパターン Azure を例としたクラウドアプリケーション設計の手引き http://amzn.to/1oTJNVH 15 人の JAZUG メンバーで半泣きになりながら監訳しました 5 @k1hash

Slide 6

Slide 6 text

内容クラウドアプリケーション設計の頻出課題集 Software design pattern の Cloud Application 版 • 24のパターン • 10のガイダンス • ポスター – http://azure.microsoft.com/en- us/documentation/infographics/cloud-design- patterns/ kyrt @takekazuomi 6

Slide 7

Slide 7 text

回答集じゃない課題が整理され、考慮点について記述されている • 8の問題領域 • 10の code sample kyrt @takekazuomi 7

Slide 8

Slide 8 text

Microsoft Azure 自習書シリーズ 8 http://blogs.msdn.com/b/windowsazurej/archive/2014/06/02/blog-published-azure-self-learning-series.aspx Azure msdn 自習書検索

Slide 9

Slide 9 text

Microsoft Azure スライドシリーズ 9 http://www.slideshare.net/MicrosoftAzure_Japan/presentations

Slide 10

Slide 10 text

Multiple Datacenter Deployment ガイダンス

Slide 11

Slide 11 text

今日のゴール複数のデータセンターにアプリケーションをデプロイすることにより得られる利点と、解決しなければならない課題を理解していただくこと。

Slide 12

Slide 12 text

複数のデータセンターにシステムをデプロイすることにより、利点を得ることができます。 • 可用性の向上 • 世界的に広い地域でのレスポンスの向上しかし実現するためには、難易度の高い課題もあります。 • データの同期 • 規制による制限

Slide 13

Slide 13 text

複数のデータセンターにデプロイする理由

Slide 14

Slide 14 text

複数のデータセンターにデプロイする理由時間と共に成長するキャパシティユーザーに最低限の遅延でグローバルリーチを提供パフォーマンスと可用性の維持

Slide 15

Slide 15 text

時間とともに成長するキャパシティ

Slide 16

Slide 16 text

ユーザーに最低限の遅延でグローバルリーチを提供

Slide 17

Slide 17 text

ユーザーに最低限の遅延でグローバルリーチを提供

Slide 18

Slide 18 text

パフォーマンスと可用性の維持

Slide 19

Slide 19 text

パフォーマンスと可用性の維持

Slide 20

Slide 20 text

複数のアプリケーションデプロイへのリクエストのルーティング

Slide 21

Slide 21 text

障害時にどうやってトラフィックをリダイレクトするか？

Slide 22

Slide 22 text

障害時にどうやってトラフィックをリダイレクトするか？

Slide 23

Slide 23 text

複数のアプリケーションデプロイへのリクエストのルーティング複数のデータセンターにアプリケーションをデプロイしていても、その内の 1 つのデータセンターに障害が発生した場合には、他のデータセンターに自動的にはリダイレクトされません。アプリケーション障害時の手動再ルーティングアプリケーション障害時の自動再ルーティング Microsoft Azure Traffic Manager による再ルーティング

Slide 24

Slide 24 text

アプリケーション障害時の手動再ルーティング DNS エントリの変更や、リダイレクトページを利用してこれを手動で変更することで、指定のデータセンターにトラフィックが流れるようにします。しかし、これらのアプローチには、いくつかの課題があります。

Slide 25

Slide 25 text

手動再ルーティングの課題 #1 障害をすぐに検出することができ、すみやかに手動切り替えを実施できる必要があります。常に稼働している切り替え用のデプロイ（ホットスワップデプロイ）がない場合、それを起動しまた正しく動作していることを検証する必要があります。業務時間外に障害が発生し、担当者がその場にいない場合は、さらに切り替えに遅延が発生することがあります。

Slide 26

Slide 26 text

手動再ルーティングの課題 #2 DNS エントリを変更することによってリクエストを再ルーティングする場合、その変更が世界中に伝搬するまでに数時間～数日かかることがあります。

Slide 27

Slide 27 text

手動再ルーティングの課題 #3 リダイレクトページや、バックアップ先のデータセンターにリクエストを再ルーティングさせるメカニズムを使用すると、そこが単一障害点になります。リダイレクトページなどにも障害が発生していた場合、バックアップ先のデータセンターにアクセスされません。

Slide 28

Slide 28 text

手動再ルーティングの課題 #4 元々プライマリ側だったデータセンターの障害が復旧した時には、再度ルーティングを戻すように設定を変更する必要があります。 DNS によってルーティングを制御していた場合、その設定変更の伝搬に再度、数時間～数日の時間がかかります。

Slide 29

Slide 29 text

アプリケーション障害時の自動再ルーティングルーティング変更のための切り替えの遅延を回避するために、各デプロイの正常性を監視し、最適なデプロイに再ルーティングすることを自動化することが可能です。自動再ルーティングのメカニズムは、複数データセンターを使用するシナリオにより異なります。

Slide 30

Slide 30 text

シナリオ 1：災害復旧再ルーティングの自動メカニズムは、バックアップ用のデプロイを起動して動作を確認し、その後、ユーザーからのアクセスをバックアップ側のデプロイにルーティングします。

Slide 31

Slide 31 text

シナリオ 2：ホットスワップ再ルーティングの自動メカニズムは、バックアップ用のデプロイが正常に動作していることを確認し、ユーザーからのアクセスをバックアップ側のデプロイにルーティングします。

Slide 32

Slide 32 text

シナリオ 3：グローバルリーチ再ルーティングの自動メカニズムは、リクエストを調査して、正常なデプロイの中から適切な（最も近い）データセンターにルーティングします。

Slide 33

Slide 33 text

自動再ルーティングの課題 #1 自動再ルーティングを司るサーバー自体が単一障害点と成りえます。これを回避するためには、複数のデータセンターに自動再ルーティングを管理するサーバーを配置し、これ自体にDNS ラウンドロビンでリクエストを分散することで可能ですが、構成の変更があった場合に、これらのサーバー同士で同期をとる必要があります。

Slide 34

Slide 34 text

自動再ルーティングの課題 #2 プライマリ側の瞬断や、障害の誤検知により断続的に切り替えが発生してしまうことを防ぐために、再ルーティングを遅らせることを検討する必要があります。この問題への対策は、プライマリ側への接続が複数回連続で失敗してから障害と判断し、切り替えをすることです。

Slide 35

Slide 35 text

自動再ルーティングの課題 #3 元々プライマリ側だったデータセンターの障害が復旧した時には、再度ルーティングを戻す仕組みが必要になります。

Slide 36

Slide 36 text

Microsoft Azure Traffic Manager による再ルーティング Traffic Manager はアプリケーションの障害検出と動的 DNS ルーティングを組み合わせた Azure のインテリジェントな DNS サービスです。 Traffic Manager は選択したポリシーに応じて、ルーティング先のデプロイを決定します。ラウンドロビンポリシーフェールオーバーポリシーパフォーマンスポリシー

Slide 37

Slide 37 text

ラウンドロビンポリシー Traffic Manager に登録されているデプロイの Endpoint に対して、『順番に』リクエストをルーティングします。アプリケーションが稼働しているデプロイに均等にアクセスを分散します。障害を検出したデプロイにはルーティングしないことで、可用性を維持します。アクセスもとの場所は考慮しないので、遠いデータセンターにアクセスしてしまうことがあります。

Slide 38

Slide 38 text

フェールオーバーポリシー管理者がデプロイに対するルーティングの優先順位のリストを構成し、Traffic Manager はそのリストの内、障害のない最優先のデプロイにルーティングします。プライマリデプロイが使用できない場合にのみバックアップにアクセスする、ホットスワップのシナリオにマッチします。

Slide 39

Slide 39 text

パフォーマンスポリシーユーザーからのリクエストを、ネットワークの遅延が最も小さいデータセンターのデプロイにルーティングします。障害を検出した場合、そのデプロイの代わりに、ユーザーから次に近いデータセンターのデプロイにルーティングします。可用性とパフォーマンスが最適な組み合わせとして、このパフォーマンスポリシーを選択することが推奨されています。

Slide 40

Slide 40 text

複数のデータセンターへのデプロイに関する検討事項

Slide 41

Slide 41 text

アプリケーションを複数のデータセンターにデプロイする場合、いくつかの課題や検討事項があります。データセンターの場所とドメイン名規制または SLA 制限データ同期データとサービスの可用性アプリケーションの構成バージョンと機能テストとデプロイカスタマーエクスペリエンスユーザーを規定とは異なる他のデータセンターに再ルーティングした場合は、それを示すメッセージをユーザーに表示するとよいでしょう。

Slide 42

Slide 42 text

データセンターの場所とドメイン名アプリケーションをデプロイする場所をどのように指定できるかを考慮します。リージョン、サブリージョンの指定可用性セットの指定による物理的な分割 ※ 言葉の意味はクラウドプロバイダーにより異なる

Slide 43

Slide 43 text

規制または SLA 制限 SLA や、適用される可能性のある法的規制を考慮する必要があります。国や地域によっては、特定の地域外へのデータの持ち出しや、データの処理を行うことを禁止されている場合があります。 SLA などにより可用性の要件が定義されていることがあります。その場合、ルーティングの切り替えにかかる時間がこの要件を満たす必要があります。

Slide 44

Slide 44 text

データ同期ユーザーが POST したデータは、そのユーザーが接続したデータセンターのストレージに保存されます。障害などによりユーザーが依然と異なるデータセンターにルーティングされた場合、そのデータが利用できないかもしれません。データセンター間のデータの同期が完了していないと、同じデータにアクセスできません。フェールオーバーのシナリオでは、プライマリとバックアップのデータセンターでデータの同期を行う必要があり、また RTO を定義する場合にこれが完了する時間も考慮する必要があります。

Slide 45

Slide 45 text

データとサービスの可用性設計や構成によっては、すべてのデータセンターで利用することができないデータやサービスがある場合があります。データの内容を拠点ごとに分割した場合は、データ同期のためのコストを最小化することができますが、別のデータセンターから再ルーティングされたユーザーには必要なデータが不足しているかもしれません。ひとつのデータセンターにのみデプロイし、そこをすべてのデータセンターから参照している場合、そのサービスが停止するとアプリケーションが障害となります。

Slide 46

Slide 46 text

アプリケーションの構成バージョンと機能データセンターごとに微妙に異なったアプリケーションをデプロイすることがあります。グローバルリーチのシナリオで、それぞれのデータセンターにローカライズしたバージョン（対応言語の違い）をデプロイすることがあります。この場合、障害により再ルーティングされると、ユーザーにマッチした言語が提供されない可能性があります。データセンターごとに正常時の負荷を基に必要最低限のインスタンス数だけを稼働させている場合、オートスケールなどによって障害時の再ルーティング先のデータセンターへのアクセスが向上しても対応できるようにしておきましょう。あるいは、障害時には機能をダウングレードする仕組みを用意し、アクセス量を制限しましょう。

Slide 47

Slide 47 text

テストとデプロイすべてのデータセンターでアプリケーションが正しく動作することを確認し、更新や障害を管理・計画するために、テストを実施することが重要です。すべてのデータセンターのアプリケーションを新しいバージョンにアップグレードする方法複数のデータセンターに対してデプロイ可能なスクリプトやユーティリティのような自動メカニズムを検討しましょう。データセンターごとに異なるピークタイムを回避するための更新タイミングの調整一部のデータセンターのみで発生する更新の失敗やパフォーマンスの低下をロールバックする方法を検討しましょう。一部のデータセンターのサービスを停止して、そのサービス地震の復旧、再ルーティングやフェールオーバー、再ルーティング先のオートスケールのテストをしてください。

Slide 48

Slide 48 text

カスタマーエクスペリエンス頻繁なデータセンターの切り替えは避けるべきで、プライマリの環境が確実に利用できない場合にのみ切り替えされるべきです。切り替えがされた場合に以下に対応すべきかもしれません。セッション管理遅延の増大やパフォーマンスの低下アプリケーションの不安定さとエラー

Slide 49

Slide 49 text

関連するパターンとガイダンス Compute Partitioning ガイダンス Data Replication and Synchronization ガイダンス Federated Identity パターン

Slide 50

Slide 50 text

JAZUG の Facebook グループへのご参加をお願いします。 50 https://www.facebook.com/groups/jazug/

Slide 51

Slide 51 text

次回予告第 4 回クラウドデザインパターン勉強会 http://jazug.doorkeeper.jp/events/16501 2014/11/18(火) 19:30-21:50 • Asynchronous Messaging 入門第２回 • Data Replication and Synchronization ガイダンス 51

Slide 52

Slide 52 text

アンケートよろしくお願いします • http://bit.ly/1rFGhzP • 1, 2 分で終了します。 52