Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

About me kuniteru.asami Find me Database Microsoft Azure © 2011 Microsoft Corporation All Rights Reserved. Azure 2012~

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 入門 第2回 • Data Replication and Synchronization ガイダンス 51

Slide 52

Slide 52 text

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