CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
6 likes1,378 views
複数のデータセンターにアプリケーションをデプロイすることにより得られる利点と、解決しなければならない課題
CDP 勉強会 - Multiple Datacenter Deployment ガイダンス
- 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. 複数のデータセンターにシステムをデプロイすることに より、利点を得ることができます。 •可用性の向上 •世界的に広い地域でのレスポンスの向上 しかし実現するためには、難易度の高い課題もあります。 •データの同期 •規制による制限
- 14. 複数のデータセンターにデプロイする理由 時間と共に成長するキャパシティ ユーザーに最低限の遅延でグローバルリーチを提 供 パフォーマンスと可用性の維持
- 15. 時間とともに成長するキャパシティ
- 18. パフォーマンスと可用性の維持
- 19. パフォーマンスと可用性の維持
- 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 プライマリ側の瞬断や、障害の誤検知により断続 的に切り替えが発生してしまうことを防ぐために、 再ルーティングを遅らせることを検討する必要が あります。 この問題への対策は、プライマリ側への接続が複 数回連続で失敗してから障害と判断し、切り替え をすることです。
- 36. Microsoft Azure Traffic Manager による 再ルーティング Traffic Manager はアプリケーションの障害検出と動的 DNS ルーティングを組み合わせたAzure のインテリジェ ントなDNS サービスです。 Traffic Manager は選択したポリシーに応じて、ルーティ ング先のデプロイを決定します。 ラウンドロビンポリシー フェールオーバーポリシー パフォーマンスポリシー
- 37. ラウンドロビンポリシー Traffic Manager に登録されているデプロイのEndpoint に 対して、『順番に』リクエストをルーティングします。 アプリケーションが稼働しているデプロイに均等にア クセスを分散します。 障害を検出したデプロイにはルーティングしないこと で、可用性を維持します。 アクセスもとの場所は考慮しないので、遠いデータセ ンターにアクセスしてしまうことがあります。
- 38. フェールオーバーポリシー 管理者がデプロイに対するルーティングの優先順 位のリストを構成し、Traffic Manager はそのリスト の内、障害のない最優先のデプロイにルーティン グします。 プライマリデプロイが使用できない場合にのみ バックアップにアクセスする、ホットスワップの シナリオにマッチします。
- 39. パフォーマンスポリシー ユーザーからのリクエストを、ネットワークの遅延が最 も小さいデータセンターのデプロイにルーティングしま す。 障害を検出した場合、そのデプロイの代わりに、ユー ザーから次に近いデータセンターのデプロイにルー ティングします。 可用性とパフォーマンスが最適な組み合わせとして、 このパフォーマンスポリシーを選択することが推奨 されています。
- 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