Azure Application Gatewayの仕様と試行錯誤
最近、ApplicationGatewayのルールの種類を「Basic」から「パスベース」に変更する作業をドキドキしながら実施しました。(本番作業はいつでもドキドキするのですが・・・）
なぜドキドキしたかというと、本番運用中でメンテナンス時間を設けずに作業した為、通信断を発生せずに完遂する必要があったからです。
ここでいう通信断は弊社が提供しているアプリが数分使えない事態を指します。
Azureの仕様でルールを「Basic」から「パスベース」への変更はAzureポータルから行えず、AzureCLI,AzurePowerShellでの実装となります。
まだ、コマンド作業に不安がありましたので今回はAzureポータルから実施しました。
「Basic」ルールから「パスベース」ルールに変更はできないので「パスベース」のルールを追加し、「Basic」ルールより「パスベース」ルールの優先度を上げる事で通信断なく切替えできるのではと考えたが、この方法はできませんでした。
切替えなので既存と同一ホスト名、同一ポートのマルチサイトリスナーを新規で作成し、「パスベース」ルールに関連づけし登録する必要があるのですが、リスナー名を別名にしても、同一ホスト名、同一ポートのマルチサイトリスナーを作成することがAzureの仕様で作成できない事がわかりました。
そして、考えた策が次です。
リスナーの種類を「Basic」で作成する事で既存マルチサイトリスナーと平行してと登録する事ができる。
「Basic」なのですべてのリクエストを受け付けるのですが、弊社サイトのApplicationGatewayに到達するリクエストはマルチサイトリスナーのホスト名となるように経路制御しているので、「Basic」でも今迄通りリクエストを受け付ける事ができます。
これで、「Basic」ルールより「パスベース」ルールの優先度を上げて切り替える設計はできました。
Azureポータルからポチポチ対応する場合の流れ
流れはこうなります
１．新リスナーを種類Basicで作成
２．既存Basicルールのリスナーを新リスナーに変更 ※通信を維持したまま断がない
３．優先度を上位にして新パスベースのルールを作成して、Basicルールで利用していた既存リスナーを設定する ※変更なのでほぼ断がないと想定
４．既存Basicルールを削除 (お掃除)
５．新リスナーBasicを削除 (お掃除)
コマンド実施による変更の弊害か
コマンドで実施すれば、この流れの作業いらないと考える人が多いと思いますが、過去にコマンドで実施した結果、ApplicationGatewayの書き換えルールで「名前と関連付け」でルール名やターゲット名を選択する為、設定内容が表示されるのですが、なぜかコマンド実施する前の「Basic」のルール名が表示されてしまいます。ルール一覧にはないルール名が表示されるので、混乱してしまいます。※MSサポートに問合せれば、修正する方法があるのかも・・・
念の為の裏どり
「Basic」ルールを「パスベース」ルールに変更するには骨の折れる作業です。
だったら、最初からパスでの振り分け要件がなくても、「パスベース」ルールで作成して、パスベースの規則は「/*」で設定すれば、「Basic」ルールとかわらないのではないかと思います。
これなら後からパスでの振り分け要件に対しても柔軟に対応ができます。
念の為、MSサポートに「Basic」ルールと「パスベース」ルールによる機能面の差がないか問合せた結果、
Basicとパスベース (e.g. /*) ルールのスループット差分につきましては、 処理性能に差分が発生しているといったような報告、障害事例を聞き及んでおりません。
との回答と共に
機能面につきましては、パスベースの規則では、ご認識の通り、URLパスに基いて、バックエンド設定、及び、バックエンドプールを選択することができるため、将来的なご要件に柔軟に対応すべく、予め、パスベースのルーティング規則を作成しておくことをお勧めいたします。
との回答を得る事ができました
まとめ
コードで変更する運用保守の方にはあまり関係がありませんが、Azureポータルで変更するケースも考慮し、将来的な要件に柔軟に対応する為に構築当初からパスベースのルールを作成する案も一つの方法かと思います。
補足
Application Gatewayの設定変更には以下Support Blogに記載の通り、設定変更により影響があります。SKUによってはネットワーク的な断はなくせないのでご注意ください。
Discussion