この記事は Alibaba Cloud の日本サイト の環境（ドキュメントやアカウント、そのアカウントでの検証結果）に基づいて記載しています。 日本サイトと国際サイトでは各プロダクトごとに提供機能が一部異なることがあります（そのほとんどは国際サイトの方が日本サイトよりも多機能になっている）。記事の内容は適宜最新化する予定です。
Alibaba Cloud 東京リージョンのマルチゾーン化に主要プロダクト（ECS/RDS/SLB)が対応しました。 構成を具体的に考えてみたいと思います。
今回はECSによるWebフロントエンド、RDSによるMySQLバックエンド、それをSLBでインターネットに公開するシステムを想定します。マルチゾーンでゾーンレベルの障害に対応できることが前提条件です。 以下のようなイメージです。
マルチゾーン設計に関するこれまでの4つの記事を総括します。
「Alibaba Cloud マルチゾーン設計」は以下の5つの記事から構成されています。
目次
マルチゾーン設計ポイントのまとめ
これまで以下の観点でマルチゾーンの冗長構成の設計ポイントを説明してきました。色々とわかったことを踏まえて具体的な構成案をまとめていきます。
- ネットワーク
- ECS
- RDS
- SLB
構成案#1 Active/Standby 構成
高いネットワーク性能を実現する構成です。 Zone B側のECSはStandbyです。通常時はZone A側のECSだけの管理となり運用（性能やログ分析など）がシンプルです。
欠点はSLBインスタンスレベルで障害が発生した場合、Clientsへのサービス提供が停止することです。また、待機側でECSコストが発生します。ECSコストを削減したい場合はバースト型インスタンス（tシリーズ）とAuto Scalingを利用することでコスト最適化を検討します。
- Zone Aをメインの処理系として構成
- SLBは購入時にZone Aを指定
- ECSはZone AをActive（SLBの分散ルールでActive/Standbyを構成）
- RDSは購入時にZone Aを指定
なお、Zone Bに寄せる構成も可能です。 新しいZone Bの方がネットワークなどより高性能であることも確認されており、性能を追求する場合は良い選択かもしれません。 ただ、Zone Aにしか構成出来ないプロダクトもあるのでそこは事前に確認しましょう。
構成案#2 Active/Active 構成
ECSをActive/Activeとします。 構成案#1と比較して時間当たりの処理量が優れていることが特長です。
欠点はZone A障害時は処理能力が半減することです。また、Zoneまたぎの通信の遅延が発生します。構成案#1同様にSLBインスタンスレベルで障害が発生した場合、Clientsへサービス提供は行えません。
- Zone AとZone Bの両方で処理を実施
- SLBは購入時にZone Aを指定
- ECSはZone AとZone Bに配置し、Active-Active（SLBの分散ルールでActive/Activeを構成）
- RDSは購入時にZone Aを指定
構成案#3 高可用性パターン
構成案#1をベースにGlobal Traffic Managerを利用することで、SLBインスタンスレベルの障害時にもClientsへ継続してサービスを提供可能です。
欠点はGlobal Traffic Managerはベータ版であることです（現在無償提供ですが2019年4月以降に有償化される予定です）。また、 構成案#1同様に待機側のECSコストが発生します。バーストタイプのECSとAuto Scalingの利用をすることでコスト最適化を検討するとよいです。
SLBを2つ購入しない構成も可能です。 2つ目のSLBの代わりにECSのパブリックIPを利用する考えです。 Global Traffic ManagerにSLBのパブリックIP、ECSのパブリックを登録し分散します。 これで十分な気もします。
- Zone Aをメインの処理系として構成
- SLBを2つ購入
- 1つ目のSLBは購入時にZone Aを指定、2つ目もZone Aを指定
- ECSはZone AをActive（SLBの分散ルールでActive/Standbyを構成）
- RDSは購入時にZone Aを指定
- Global Traffic Managerを購入し2つのSLBへの振り分けを構成
通常時
SLB#1が障害時
Zone Aが障害時
構成案の比較
3つの構成案について比較表にまとめました。 基本は構成案1で検討しつつ、SLBインスタンス障害を許容出来ない場合は構成案3をお勧めします。
構成案2の検討時は、Zoneまたぎの通信の1msの遅延と障害時にECSの処理能力が半減することを許容出来るか確認してください。
| 構成案1 | 構成案2 | 構成案3 | |
| Zone障害 | ○ | ○ | ○ |
| SLB障害 | × | × | ○ |
| RDS障害 | ○ | ○ | ○ |
| 通信Latency | ○ | ▲ | ○ |
最後に
2019年1月29日に東京リージョンがマルチゾーン化しました。システムをどう設計するべきか考えてみました。 SLBのプライマリがZone固定であること、RDSの内部でもSLBが動作していること、プライマリは購入後に変更出来ないこと、という3つの落とし穴を発見できてよかったです。
購入後に変更出来ないという、後戻り出来ない系の落とし穴は、クラウドなのでとりあえず買って、試して、どんどん直せばよい、というアプローチでは避けたいものではありますが、やってみないとわからないというジレンマですよね。
次はVPN Gatewayの設計について調べて、試して、書いて見る予定です。（本当はCENやExpress Connectも含めたいのですが個人には高くて・・）
- 複数（2以上、３と５とかそれこそ17リージョン）のVPCを接続する
- On-premisのVPNと接続する
- AWSやAzure、GCPと相互接続する
- 上記いろいろやった場合の設計、設定ポイントを明らかにする
以上
