この記事は Alibaba Cloud の日本サイト の環境（ドキュメントやアカウント、そのアカウントでの検証結果）に基づいて記載しています。 日本サイトと国際サイトでは各プロダクトごとに提供機能が一部異なることがあります（そのほとんどは国際サイトの方が日本サイトよりも多機能になっている）。記事の内容は適宜最新化する予定です。
Alibaba Cloud 東京リージョンのマルチゾーン化に主要プロダクト（ECS/RDS/SLB)が対応しました。 構成を具体的に考えてみたいと思います。
今回はECSによるWebフロントエンド、RDSによるMySQLバックエンド、それをSLBでインターネットに公開するシステムを想定します。マルチゾーンでゾーンレベルの障害に対応できることが前提条件です。 以下のようなイメージです。
マルチゾーン構成におけるECSの設計および考慮ポイントを紹介します。
「Alibaba Cloud マルチゾーン設計」は以下の5つの記事から構成されています。
目次
ECS インスタンスの検討ポイント
マルチゾーンで冗長化を行う場合のECSの検討ポイントは以下でしょうか。
- Zone間の通信のLatency
- SLBインスタンスのプライマリ、バックアップの構成
- 複数のECS間でのデータ共有
- ECSタイプファミリーの選択
Point#1 Zone間の通信のLatency
Zone AとZone Bのそれぞれに配置したECSやRDSについて、Zone間の通信のLatencyを考慮する必要があります。
実際にZone間通信のLatencyを測ってみました。新しいZone BのほうがZone Aより高速でした。 Latency重視ならZone Bをメインで使うのがよさそうです。
- 同じZone内の通信はZone Bが高速 （新しいZoneだからでしょうか）
- Zone A-B間の通信について、Zone B→Aの方がA→Bより高速(差が出る理由は不明）
- ECSとRDSの通信について、基本的にECSと同じ傾向（Zone内であれば1ms以下、Zone間の場合2ms以下）
- RDS側でswitch overを実行しマスターとスレーブを切り替えても結果が変わらない。 これはECSの接続先はMySQLインスタンス本体ではなく、RDS購入時に自動的に配備されるSLBインスタンスとなるため。なお、RDS側でswitch overしてもSLBインスタンスは切り替わらない。
| To Zone A ECS | To Zone B ECS | To Zone A RDS | To Zone B RDS | |
| From Zone A ECS | 0.263 ms | 1.908 ms | 0.160 ms | 1.510 ms |
| From Zone B ECS | 1.448 ms | 0.154 ms | 1.413 ms | 0.097 ms |
上記のテストは以下の環境で実施しています。
- ECSのインスタンスタイプファミリーは” ecs.t5-lc1m1.small”
- RDSのインスタンスタイプファミリーは” rds.mysql.t1.small”
- CentOS 7.6上でpingからavgを確認 （Packets 50 over)
Point#2 SLBインスタンスのプライマリ、バックアップの構成
以下の投稿で紹介したとおりSLBインスタンスのプライマリ（マスター）、バックアップ（スレーブ）は購入時にしか指定出来ません。 運用中に手動で切り替えることが出来ないということになります。
Point#1でZone内およびZone間のLatencyの測定結果からZone BがLatency面で優れていることがわかっています。
設計は以下のように考えるとよいと思います。
- Latencyを重視する場合はSLBインスタンスのプライマリをZone Bに構成し、フロントエンドのECSもZone Bをメインとする（2台であればActive/Standby、3台以上なら重みづけなどでZone Bに優先振り分け）。また、RDSのマスターもZone Bとする。
- ただ、Zone間通信の1msを無視できる場合はSLBインスタンスのプライマリのZoneに限らずZone AとZone Bに配置したECSに処理を分散する構成で問題ありません
Point#3 複数のECS間でのデータ共有
Webのフロントエンドを構成する中で、複数のECSインスタンス間でデータを共有したいケースはままあります。 DB以外の構成ファイルやテンポラリデータなどです。サービス（Daemon)から常時参照する性質のデータやバックアップ的な参照できなくともサービス提供には直接影響しないデータもあります。
データ共有の方式は以下が考えられます。 NASがマルチゾーンで冗長化されていれば文句無しの一択だったのですが、現状はどの方法を選ぶにせよ色々と工夫が必要となります。
| メリット | デメリット | |
| Alibaba Cloud NAS | ・マネージドサービス ・NFS,CIFSに対応 | ・マルチゾーンの冗長化は未対応 |
| Alibaba Cloud OSS | ・マネージドサービス ・安価 | ・ファイルシステムとはしては直接利用できない ・atomicではない |
| rsyncやscpによるコピー | ・安価 ・カスタマイズ | ・スクリプトの作成 ・障害時の切り戻しなどの考慮 |
Point#4 ECSタイプファミリーの選択
東京リージョンのZone AとZone Bでは提供されているタイプファミリーのラインナップが異なります。 詳細は以下記事。
結果的には大きな問題にはならないのですが、例えばCPU:メモリ=1:4のタイプファミリーを選ぶ場合、Zone Aではsn2とsn2neの2つ、Zone Bはgの1つとなります。 sn2neとgはスペックが同じなのでこの2つを選ぶことになります（スペックが違う構成も可能ですが）。この時の考慮事項としては、スペックは同じなのにgが若干安価であること、また、タイプファミリーの名前が異なること（気分的な問題）でしょうか。
まとめ
- 1msレベルでLatencyを考慮する必要がある場合は、Zone Bをメインに利用する、SLBやRDSのプライマリのZoneを考慮することが必要
- 複数のWebフロントエンドでデータ共有を行いたい場合、Alibaba Cloudの標準プロダクトでのベストプラクティスは無いのが現状（工夫する）
- Zone AとZone Bでは提供タイプファミリーが異なるので仕様や価格を確認して環境を揃える必要あり
以上
