やりたかったこと

art-servers-web-ap

通常はnginxを乗せたWEBサーバからサービス用のAPサーバへとつながる内部バランサへプロクシしていますが、メンテナンス時にはこれをメンテナンス用のAPサーバへと振り分けます。

メンテナンス用のサーバ群は必要?

Sorryを表示するだけの静的ページであれば、nginxからHTMLを返却すればよいのですが、要件としてメンテナンス中の文言を容易に変更できることが挙げられており、プログラムを介する必要がありました。

検討1:サービス用のAPサーバにメンテナンス機能をのせる?

従来はAPサーバにメンテナンスの機能を持たせ、設定によってメンテナンスについて表示する方法をとっていましたが、APサーバの停止や、そもそもメンテナンス機能の実装による内部の複雑化を避けるため、メンテナンス機能を外部に出すという判断をしました。

役割分担を明確にしたかったということと、メンテナンス作業中は絶対にサービス側のAPサーバにアクセスされることがないという前提条件を設けることで、更新手順をシンプルにできると考えました。

検討2:WEBサーバ上にAPサーバをのせる?

次にメンテナンス機能を「どのサーバに持たせるか」を検討しました。

WEBサーバ上にAPサーバを同居することも考えましたが、こちらはNGです。
WEBサーバにはnginxを採用しましたが、WEBサーバにAPサーバを同居するとで発生する次のデメリットが大きいと感じました。

  • APサーバを起動させるためにサーバリソースを増強しなくてはならない
  • 障害発生時の原因特定が難しくなる(切り分けがやりにくくなる)

検討3:メンテナンス用のAPサーバを用意する?

以上について検討し、新しくAPサーバ群を用意することが妥当という結論に至りました。

メリットとして、小さなプログラムのため見通しが確保できる点、メンテナンス中はAPサーバを自由に操作できる点が挙げられます。
デメリットとして、別途サーバを用意しるため、その分のコストがかかる点が挙げられます。

プログラムがシンプルとはいえ、ここが単一障害点(SPOF)になってはいけませんので、LBを挟んで冗長化します。

メンテナンスの切り替え方法とnginxの設定

APサーバのプロクシを動的に変更し、メンテナンスへ切り替える方法は「特定ファイルの有無」で判別することとしました。

nginx.confを次のように設定します。

upstream service_ap_server {
    server lb.ap.example.com:80;
}
upstream maintenance_ap_server {
    server lb.maintenance.example.com:80;
}
server {
    listen 80;
    server_name ap.example.com
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;

    set $maintenance false;
    if (-e /path/to/dir/.maintenance ) {
        set $maintenance true;
    }

    location / {
        if ($maintenance = true) {
            proxy_pass http://maintenance_ap_server;
        }
        if ($maintenance = false) {
            proxy_pass http://service_ap_server;
        }
    }
}

/path/to/dir/.maintenanceにファイルが存在すればメンテナンスモードとして、メンテナンス用のAPサーバにプロクシするという簡単な仕組みです。
また、このファイルはJenkinsから作成、削除できるようにしておきます。

nginxのif文は制約が多いため、野暮ったい書き方になります。

nginxのifは次のような制約があります。

  • AND条件が設定できない
  • ネストできない
  • elseが設定できない

特定の環境でメンテナンスを通過する

メンテナンス中のサービス確認のため、特定のIPアドレスでアクセスした場合はメンテナンスを通過する仕組みを足します。
最終的なnginx.confは以下です。

set_real_ip_from xxx.xxx.xxx.xxx;
real_ip_header   X-Forwarded-For;

upstream service_ap_server {
    server lb.ap.example.com:80;
}
upstream maintenance_ap_server {
    server lb.maintenance.example.com:80;
}
server {
    listen 80;
    server_name ap.example.com
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Real-IP $remote_addr;

    set $maintenance false;
    if (-e /path/to/dir/.maintenance ) {
        set $maintenance true;
    }
    if ($remote_addr = "xxx.xxx.xxx.xxx") {
        set $maintenance false;
    }
    if ($remote_addr = "xxx.xxx.xxx.xxx") {
        set $maintenance false;
    }

    location / {
        if ($maintenance = true) {
            proxy_pass http://maintenance_ap_server;
        }
        if ($maintenance = false) {
            proxy_pass http://service_ap_server;
        }
    }
}

LBを設定しているのでreal_ip_headerで接続元のIPを取得し、特定IPアドレスからアクセスされた場合は変数$maintenanceをfalseで上書きするといった設定です。
もうちょっとうまいやり方がありそうですね。


スポンサーリンク
ad_336
ad_336
  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存