複数のデータセンターにアプリケーションをデプロイすることにより得られる利点と、解決しなければならない課題

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

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

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

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

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

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

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

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

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

10. Multiple Datacenter Deployment ガイダンス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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