#概要
　Azure ロードバランサーは、無償で提供されるレイヤー 4 (TCP、UDP) のロードバランサーです。この Azure ロードバランサーですが、現状ではオフライン機能を提供していないため、ロードバランサー配下のサーバーメンテナンスを実施する際に不便が生じるかと思われます。

　例えば運用管理者は、新規リクエストを止め、既存リクエストは中断させず処理を完了させた後にメンテナンス作業に入りたいという要望があるかと思います。このような場合、drain オフライン機能がロードバランサーに備わっていると簡単にグレースフルシャットダウンというかエラーなしでの切り離しが出来ます。

#代替え案
　ここではオフライン機能を代用する回避策として、セッション中断なくロードバランサー配下のサーバー (VM) を切り離す方法を２つ紹介します。

　何れの方法も Azure ロードバランサーがセッションを振り分けた後は、そのセッションをロードバランサー自らは切断しないという内部仕様を応用しています。これは Azure ロードバランサー経由で一度張られたセッションは、エンドポイントのサービス側もしくはクライアント端末側でセッションを切らない限り張られたままとなる事を意味します、Azure ロードバランサー自らが切断する事はありません。
###1. カスタムプローブのファイル名変更による切り離し
　Azure ロードバランサーは、常時 LB 配下のサーバーを死活監視しています。死活監視は TCP による特定ポートの監視、もしくは HTTP による特定ページの監視のいずれかを指定する事が可能です。負荷分散シナリオの多くは WEB サーバーが対象となるかと思われますが、この場合死活監視は特定の WEB ページを対象とするカスタムプローブの利用が可能です。

　カスタムプローブは、例えば /liveordead/probecheck.aspx のような特定の WEB ページを死活監視に指定します。そして、この該当ページへのプローブ呼び出しが 200 OK 以外であった場合、Azure ロードバランサーは該当サーバーが異常であると判断し、サーバーをロードバランサー配下から切り離します。

　この仕様を逆手に取り、運用管理者はメンテナンスを実施したいサーバーの probecheck.aspx のファイル名をリネームする事で 404 エラーをプローブ監視に返す事が出来ます。これにより該当サーバーは新規リクエストを受け付けなくなりますが、既存のリクエストは張られたままとなります。しばらく時間をあけ既存リクエストが掃けてからサーバーのメンテナンスを実施します。メンテナンス完了後は、リネームしたファイル名を元に戻せば再度 LB の振り先として戻ってきます。
###2. バックエンドプールから外す
　WEB サーバー以外のサービス、例えば FTP, SMTP といったサービスを Azure ロードバランサーで負荷分散する場合ですが、この場合には HTTP プローブを利用できないため TCP によるサービスポートの死活監視が必要となります。例えば FTP であれば 20, 21 ポート、SMTP であれば 25 ポートがサービスポートであり、死活監視（プローブ）ポートでもあります。

　このような状況ではサービス（ポート）自体を止めないと死活監視（プローブ）による対象とならないので 1 のような手法はとれません。このため今回は Azure ロードバランサーのバックエンドプールから対象サーバーを削除するという方法を紹介します。

　一見乱暴なやり方に見えますが、この場合でも既存セッションは切断されずに残ったままとなるため、削除処理により受け付けなくなるのは、それ以降の新規リクエストのみとなります。これにより削除処理が完了し暫く経った後にメンテナンスを実施する事でサービス中断をせずに該当サーバーを LB から切り離す事が可能となります。メンテナンス終了後は、バックエンドプールに再度追加する事で LB のメンバーとして復帰します。