いわさです。
先日 QuickSight の VPC 接続機能が新しくなり、マルチ AZ (アベイラビリティゾーン) 構成が必須となりました。
これに伴って QuickSight がどのように VPC 接続を行っているのか整理することにしました。
確認ポイントとしては、どの AZ の ENI が使用されるのかと、AZ 障害が発生したときの挙動です。
今回検証環境としては、以下の構成で VPC 接続が出来る状態のものを使っています。
通常時はラウンドロビンっぽい動きをしている
前述の構成をベースに 3 AZ で VPC 接続を作成しています。自動生成された ENI は以下のようになっています。
| IP | AZ |
|---|---|
| 172.31.43.20 | ap-northeast-1a |
| 172.31.26.118 | ap-northeast-1d |
| 172.31.5.141 | ap-northeast-1c |
この構成で、VPC 接続を使用するデータセット（ダイレクトクエリモード）を作成します。
カスタムクエリでは、次のようにクライアント IP アドレスを出力するようにしています。プライベート接続なのでどの ENI からのプライベート通信なのか PostgreSQL 側で確認が出来ています。
このデータセットを分析で使用します。
分析でデータロードが発生する度に、都度 RDS に対していずれかの ENI を経由してカスタムクエリが発行されるという形です。
実行結果
分析のリロードを繰り返したところ、結果としては次のようにリロードごとにほぼ毎回異なる ENI が使われていました。
検証前は、接続先データソース（RDS） の AZ にあわせて 1 つの ENI がずっと使われる可能性なども考えていたのですが、関係ないようです。
なお、ここまでの検証結果で明らかに無関係だとわかりますが、RDS を別 AZ にフェイルオーバーさせても同じ結果でした。
観察した感じだとラウンドロビンっぽう動きをしています。
この結果から認識しておきたいという点は AZ 間通信が発生しているという点です。
大量の通信が発生するダイレクトクエリの場合は SPICE モードへの移行が有効なケースがありそうです。
AWS FIS で AZ 通信障害を発生させたところ、通信上の問題は回避されなかった
続いて、ENI がマルチ AZ 化されているということで、特定 AZ で通信障害が発生した時にどういう挙動になるのか確認してみました。
本日時点で AZ 障害的な動きを再現出来るのは AWS FIS (AWS Fault Injection Simulator) の通信障害です。
以前、次の記事でアップデート内容や使い方を紹介したことがあります。
こちらを使って特定 AZ の通信障害を発生させ、その時の VPC 接続を使ったダッシュボードの動きを観察してみます。
ダイレクトクエリでの検証
前提として RDS for PostgreSQL が ap-northeast-1d で稼働しています。
そこで、AWS FIS で ap-northeast-1a と ap-northeast-1c の全通信を遮断させてみます。
使用するアクションはaws:network:disrupt-connectivityでスコープはallです。
10 分間障害状態を発生させます。
期待する動作としては QuickSight が、障害が発生している ap-northeast-1a と ap-northeast-1c の ENI を回避して、うまく ap-northeast-1d の 172.31.26.118 の ENI だけ使われる挙動です。
実行してみる
上記で作成した実験を開始しました。
QuickSight 側で先程と同じように分析のリロードを繰り返します。
初回は 172.31.26.118 が正常に表示されました。ap-northeast-1d の ENI を掴めた時ですね。
しかし、その後以下のように分析が読み込み中のままになる状態が何度も発生しました。
これは、ap-northeast-1a と ap-northeast-1c の ENI を掴んだときと推測出来ます。
Application Load Balancer (ALB) でも障害発生ノードが切り離されるまでは少し時間が必要なので少し時間を置くと ap-northeast-1d の ENI のみが使われる可能性もあると思いました。
そこで通信障害の実験 10 分間の間で分析のりろー度を繰り返していましたが、結果としては分析が終了するまで何度も読み込み中の状態が発生しました。
更新を繰り返すとたまに ap-northeast-1d の ENI を掴んで表示出来る場合があります。
10 分後にテストが終了すると、通常どおり ap-northeast-1a と ap-northeast-1c の ENI でも分析が表示出来るようになっています。
結果としては、特に障害が発生した AZ の ENI が切り離されて正常な AZ の ENI のみが使われるという動きにはなっていませんでした。
以前のシングル AZ 構成だと、ネットワーク障害中はずっと表示が出来ない状態でしたが、マルチ AZ であればリロードすることで表示出来る状態があるという感じなので以前よりは少し良い状況かもしれません。
SPICE での検証
続いて、SPICE でも確認してみました。
ここで期待する動作としては、SPICE の更新時に障害が発生している ENI を回避してくれることです。
まず、カスタムクエリで次のように ENI に加えて SPICE 上にデータをロードした時間を表示出来るようにしました。
今回は先程と異なり RDS for PostgreSQL が ap-northeast-1a で動作しており、それに対して QuickSight の VPC 接続は ap-northeast-1a と ap-northeast-1c のマルチ AZ で動作しています。
そこで、FIS を使って ap-northeast-1c に通信障害を発生させます。
結果としては、次のように SPICE 更新に失敗する時がありました。これは ap-northeast-1c の ENI を掴んだ時だと推測できます。
一方で成功している時もあり、ap-northeast-1a を掴んだ時だと推測出来ます。
ap-northeast-1c で失敗した場合に ap-northeast-1a でリトライしてくれると良いのだがそういう挙動にはならないようです。
分析上は失敗した旨のアラートが表示されます。
SPICE 更新の場合でも障害が発生した AZ の ENI が引き続き使われる可能性を考慮する必要があります。
また、自動でリトライされる仕組みにはなっていません。
対処方法としては SPICE の取り込み履歴を何らかの仕組み（CloudTrail で拾えないようなのでポーリングとか？）で拾って SPICE 更新のリトライをかける方法は有効そうな気がします。
うまく正常な ENI を掴めれば更新に成功します。
さいごに
本日は Amazon QuickSight のマルチ AZ が必須になった VPC 接続の通信挙動を確認してみました。
一点初めにお伝えしておくと今回の検証はあくまでも AWS FIS ベースの検証結果です。
AWS FIS は完全な AZ 障害を発生させれるものではないのでご注意ください。
例えば AZ 障害発生中に Auto Scaling Group で正常 AZ にノード寄せる機能などは、本日時点では FIS では再現出来ないです。
類似の仕組みで QuickSight 側で検出を行っている可能性もあります。
とはいえ、今回の検証結果からは正常に通信出来ない ENI を掴む場合があるので、許容出来るか検討したり、あるいは追加のワークアラウンドを独自で実装する必要があるかどうかなど検討はしても良いのかなというところです。
また、AZ 間通信を回避あるいはデータソースの AZ に追従するオプションや、ENI に対して QuickSight 側からヘルスチェック出来る仕組みがあると良いのなと思ったので、そういった要望はフィードバックを QuickSight コミュニティなどに投稿しておくと良いです。