Azure で冗長構成の LAMP サーバーを構築 (後編)

前編の続き。

Load Balancer を使う場合

参考: Load Balancer | Microsoft Docs

純粋にレイヤー 4 でバランシングする場合は Load Balancer を使う。 AWS の ELB (CLB) のように、レイヤー 4 かと思いきや SSL ターミネーションができたり Cookie を使ったスティッキーセッションがあったりといった柔軟な感じではなく、本当にレイヤー 4 だけ。

※注: スティッキーセッションはCookieベースではなく、L4までの情報 (ソース IP、接続元ポート、接続先 IP、接続先ポート、プロトコルの組み合わせ) を判別することで行うことが可能。

ちなみに、SLA がショボいほうの Basic SKU はタダ。

Basic Load Balancer は無料で提供されます。
価格

設定手順

バックエンドとして、前編で作った可用性セットを関連付け。

プローブ (ヘルスチェック) の設定。

負荷分散規則の設定。
必要に応じてセッション永続化も設定しよう。

ちなみに、ちらっと写っている通り Direct Server Return (戻り通信は LB を通さずバックエンドから直に返すヤツ) も対応できるそうで。

留意すべき点

SSL 証明書は各サーバーに配備
アプリケーションの実装やファイル同期方法次第で、管理画面系やファイルアップロードがある画面へのアクセス等を片寄せする必要がある
- 管理画面アクセス用の DNS 名 (例: admin.example.com) をサーバーに設定してバランシングしないようにする（所謂、運用でカバー)
- ただし、アップロードしたファイルの URL に管理画面アクセス用の DNS 名が残っちゃうんですが……など、アプリケーションの実装次第で面倒くさいことになるかも

WordPress、きみだよ。

Application Gateway を使う場合

レイヤー 7 の LB。 AWS の ALB (Application Load Balancer) 的なやつですね。 HTTP リクエストのパスを見てバックエンドプールのルーティングができるので、前述の LB では難しかった管理画面アクセスの片寄せも対応できる。SSL ターミネーションも可。

また、こいつは ALB より優秀で、バックエンドとして任意の DNS 名や IP アドレスを指定できる。つまり、AWS の EC2 をバックエンドにしても良いわけ。~~MS のくせに、なかなかどうして……~~

設定手順

以下、LB とバックエンド間の通信は HTTP で済ます想定。

前編で作ったゲートウェイ用のサブネットに作成。
また、静的 IP にできないので、CNAME 登録用の DNS 名ラベルを適宜指定。

バックエンド設定 (表側サイト用) => バランシングする。

バックエンド設定 (管理画面用) => 片寄せ。

バックエンド接続設定。
必要に応じて、セッションアフィニティ (スティッキーセッション) や接続ドレインを設定。

リスナー設定。

SSL 証明書は pfx 形式でアップロード。

パスベースのルーティング設定。
下記は WordPress の例。

留意すべき点

ミドル、アプリケーションにおける X-Forwarded-For、X-Forwarded-Proto への対応
その他、なんかあるかな……?

おわりに

LB や Application Gateway の設定がクソ遅く、無理やり先に進んで急かすとエラー吐きまくるので、茶でもシバきながら気長に待ちましょう( ^^) _旦~~