Azureのデータセンターとリージョンについて
Arureは、世界中にあるデータセンターから出来ている。それらは地域ごとに分けられ、効率よくリソースを割り当てて制御されているため、どこのデータセンターを利用するのか指定する必要がある場合が多い。
※ただし、Azure ADやAzure Traffic Manager, Azure DNSなどのグローバルなサービスは特定のリージョンを選択して使用する必要はない。
なぜたくさんのグローバルリージョンがあるのか？
以下は2020.2時点での利用可能な全てのAzureリージョンとのこと。
（https://docs.microsoft.com/ja-jp/learn/modules/explore-azure-infrastructure/2-azure-datacenter-locations）
Azureがこのようにたくさんのリージョンを持っている理由は、以下3つである。
1. リソースの所在を特定できるようにするため。
2. アプリケーションをユーザの近くに配置することでスケーラビリティや冗長性を向上するため。
3. 地域によって異なる法的な目的やコンプライアンスに準じるため。
Azureの地域について
「地域」
2つ以上のリージョンからなる、同じコンプライアンスを持ったマーケットのこと。
実際には、以下の4つの地域に分られている。
- アメリカ合衆国
- ヨーロッパ
- アジア太平洋
- 中東とアフリカ
Azureの可用性ゾーンについて
可用性ゾーン（Availability Zone）とは、全てというわけではないが、各リージョンが持つデータセンターという、電源、冷却手段、ネットワークといったハードウェア環境の分離境界のことを指す。
可用性ゾーンは、障害発生時の可用性の保護の為に設定され、高速な光ファイバーネットワークによって接続可能になっている。
（https://azure.microsoft.com/en-us/global-infrastructure/regions/）
例えば、以下のリージョンには、最低3つのゾーンが存在し、回復性を確保している。
※ただし、ゾーンのサポートされたリージョンは拡大している為、最新情報は適宜チェック要。
米国中部
米国東部 2
米国西部 2
西ヨーロッパ
フランス中部
北ヨーロッパ
東南アジア
なお、ゾーンは、ハードウェア環境のためだけでなく、
よりミッションクリティカルなアプリケーション実行のため、
リソースをアプリ内で他のゾーンにレプリケート（複製）することもできる。
例えば、ゾーン冗長ストレージやSQL Databaseは複数のゾーンに自動的にレプリケートすることができる。
Azureのリージョンペアについて
上記の可用性ゾーンだけでは、非常に大きな災害などが起きた場合に全てのデータセンターが停止してしまう可能性もあるため、Azureは300マイル以上離れた場所にリージョンでのペアも作成している。
そうすることによって、何か起きた時に自動的にフェールオーバー（fail over：サーバー停止時に自動的に切り替わること）されることができる。
例えば、東アジアは東南アジアとペアで、米国東部は米国西部とペアである。
（https://docs.microsoft.com/ja-jp/learn/modules/explore-azure-infrastructure/5-region-pairs）
リージョンペアのメリットは、上記だけでなく、
税および法の執行を目的として、データは、そのペアと同じ地域に存在し続けます (ブラジル南部を除く)。
（https://docs.microsoft.com/ja-jp/learn/modules/explore-azure-infrastructure/5-region-pairs）
もある、とのこと（ここは後ほど要編集）
Azureのサービスレベルアグリーメントについて
個々のAzure製品/サービスにはSLA（Service Level Agreement）があり、Azureのパフォーマンスがその正式なドキュメントにキャプチャされている。
※ ただし、Azure Advisor（Azureデプロイメントを最適化するクラウドコンサルタント）などの無料（あるいはShared）の製品/サービスにはSLAはない。
どんなパフォーマンスをキャプチャしてくれるの？
例えば、Azure CosmosDBサービスのSLAでは、99.999%のアップタイムが提供される。これは、週あたりのダウンタイムが6秒、月では25.9秒、年では5.26分のダウンタイムとなる計算である。
Azureでは、全ての製品/サービスごとにスリーナイン（99.9%）〜ファイブナイン（99.999%）のアップタイムを維持するパフォーマンスを条件にしている。
もしも月間アップタイム率がSLAの基準を下回ったら、利用者には決められた比率のサービスクレジット（Azure請求時の割引）が適用される約束になっている。
参考：SLAのコミットメント
https://azure.microsoft.com/ja-jp/support/legal/sla/
参考：Azureでは何%の稼働率が保証されていますか？
https://licensecounter.jp/azure/blog/faq/20151209.html
サービス全体のSLAを作成する
複数の異なるサービスを利用してアプリケーションを実行する場合、それに応じてSLAは複雑になる。これを複合SLAという。
例えば、99.95%のSLA値を持つWebアプリのデータを99.99%のSLA値を持つSQL Databaseにしまった場合、複合SLAは、
99.95 percent × 99.99 percent = 99.94 percent
となり、障害発生の確率が上がってしまう。
そこで作成するフォールバックパス（fallback path）が複合SLAを用いた以下の方法である。
この設計であれば、仮にデータベースに接続できなくても、Queueというストレージのサービスを使用し、アプリは使用可能となる。
したがって、このやり方でwebアプリを作成すれば合計の複合SLAは以下の計算式のようになり、SLAの動作が向上できることになる。
1.0 − (0.0001 × 0.001) = 99.99999 percent
※括弧内はDBとキューの両方で同時に障害が発生する確率
99.95 percent × 99.99999 percent = ~99.95percent
※ただし、このフォールバックパスはキューのサポートを追加する必要があるため支出が増えたり、再試行の際の動作が原因でデータの整合性に問題が発生したりする可能性もあるため、
そういったトレードオフ(tradeoff)があることには注意しなければならない。
Azureのアプリの信頼性を向上させる
Azureソリューションは実際には、ビジネス要件やワークロード要件などのユーザーのニーズに合わせて提供されるため、相互に依存するサービスが増えてより複雑になる。
そういったそれぞれに異なるAzureアプリケーションはそのため、個別のSLAも作成される。そのパフォーマンスの目標を設定するアプローチを、アプリケーションSLAという。（いまいち具体的にピンとこないため後ほど要編集）
アプリケーションSLAは前述したようにとても複雑なので、サービス障害を予防することは困難だが、高可用性とディザスターリカバリーという回復性をでアーキテクチャ設計時の時点でよく考えて作られる必要がある。
なお、フォーナイン（99.99%）のパフォーマンス目標が定義される場合は、手動介入ではアプリケーションSLAは満たされない可能性があるなど、アップタイムの時間枠について厳格に捉えていかなくてはならない。
