Go to Qiita Advent Calendar 2024 Top
LoginSignup
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@kabe-akam(Kusuyuki Abe)inアカマイ・テクノロジーズ合同会社

HAProxyとIP Sharingを用いた冗長化ロードバランサーの作成

Posted at

はじめに

HAProxyは高可用性・負荷分散を実現するためのロードバランサー機能をもったオープンソースソフトウェアです。大規模なHTTPやその他TCPアプリケーションベースの負荷分散にも用いられています。Akamaiのcloud computing servicesで提供されているLinodeインスタンスに、IP Sharing機能を使うことで、高可用性のWebサイトを構成することができます。

NodeBalancersとの使い分け

Akamaiのcloud computing servicesでは、ManagedのロードバランサーであるNodeBalancersも用意されています。それぞれ以下の特徴がありますので構築するシステムに合わせて選択してください。

NodeBalancers

  • Managedサービスのためインフラの運用をAkamaiに任せることができる
  • GUIでの設定画面を利用でき、簡単に冗長化されたロードバランサーを構築することができる
  • ステータス画面もGUIで簡単に確認することができる

NodeBalancersの仕様は以下を参照してください

HAProxyなどのLinuxロードバランサー

  • システムに合わせて柔軟にロードバランサーを構成することができる
  • 詳細なアクセスログなど細かい情報を取得することができる
  • Linodeインスタンス上に構築するため、Cloud Firewallにて特定の通信のみを制御することができる

本記事での構成

本記事では以下の構成で構築しています。
image.png

  • HAProxyをロードバランサーとして構成（以下HAProxyサーバー）
  • 2台のHAProxyサーバーをIP SharingにてActive/Standby構成
  • Webサーバは3台構成
  • ネットワークはすべてPublic IPにて構成
  • HAProxyサーバーは証明書を取得し、SSLにてクライアントからの通信を処理
  • HAProxyサーバーはSSLオフロードを行い、WebサーバーへはHTTPに切り替えて接続
  • 負荷分散方式はラウンドロビンおよびHAProxyにてCookieを付与しセッションの永続性を適用
  • それぞれのLinodeインスタンスにCloud Firewallを適用
  • （オプション）AkamaiのWeb Secuirty/CDNサービス(Akamai Intelligent Edge Platform)を適用の際、Cloud FirewallへSite ShieldのIPアドレスリストを適用

keepalivedのインストールと設定

HAProxyサーバーにIP Sharing及び、冗長化設定を行います。
IP Sharingを用いたLinodeインスタンスの冗長化については、KeepAlivedなどの方式を用いる必要があります。設定方法については以下の記事を参考にしてください。なお本記事では東京リージョンで現時点でサポートしているARPベースでのKeepAlived方式を利用しています。（2023年7月現在、東京リージョンはBGP方式へのアップグレード中です）

HAProxyサーバーの冗長化に対応させるために、Keepalivedのコンフィグを少しだけ変更します。
check_haproxyを追加しますが、他は上記の記事と同じです。

$ sudo vi /etc/keepalived/keepalived.conf
/etc/keepalived/keepalived.conf
global_defs {
}

vrrp_script check_haproxy {   ## HAProxy用にcheck_haproxyを追加
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance Instance1 {
    state MASTER
    interface eth0
    virtual_router_id 10
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass fowebpass    #fowebpassは例。共通のパスワードを記載
    }
    unicast_src_ip 198.51.100.1 #左記は例。サーバーAの1つ目のPublic IPを記載
    unicast_peer {
       198.51.100.2   #左記は例。サーバーBのPublic IPを記載
    }
    virtual_ipaddress {
       198.51.100.3   #左記は例。IP Sharingで割り当てたIPを記載
    }
    track_script {
      check_haproxy   ## HAProxy用にcheck_haproxyを追加
    }
}

2台目のHAProxyサーバーにも設定を適用します。

/etc/keepalived/keepalived.conf
global_defs {
}

vrrp_script check_haproxy {   ## HAProxy用にcheck_haproxyを追加
    script "killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance Instance1 {
    state BACKUP    # サーバーBはBACKUPに変更
    interface eth0
    virtual_router_id 10
    priority 99    # サーバーBは99に変更
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass fowebpass    #fowebpassは例。共通のパスワードを記載
    }
    unicast_src_ip 198.51.100.2 #左記は例。サーバーBのPublic IPを記載
    unicast_peer {
       198.51.100.1   #左記は例。サーバーAの1つ目のPublic IPを記載
    }
    virtual_ipaddress {
       198.51.100.3   #左記は例。IP Sharingで割り当てたIPを記載
    }
    track_script {
      check_haproxy   ## HAProxy用にcheck_haproxyを追加
    }
}

証明書の取得

HAProxyサーバー用にサーバー証明書を取得し適用します。ここではLet's Encryptのサーバー証明書を取得します。手順については多くの方法がありますが、以下の記事にて紹介しておりますのでご参照ください。

取得したサーバー証明書、プライベートキーを一つのファイルにまとめて、/etc/ssl/private配下に保存しています。 [FQDN]は構築するWebサイトのFQDNに置き換えます。

$ sudo cat /etc/letsencrypt/live/[FQDN]/fullchain.pem /etc/letsencrypt/live/[FQDN]/privkey.pem | tee /etc/ssl/private/[FQDN].pem

作成した/etc/ssl/private/[FQDN].pem を2台目のHAProxyにもコピーして保存します。

HAProxyのインストールと設定

2台のHAProxyサーバーに、haproxyソフトウェアをインストールし設定を行います。

haproxyのインストールを行います。SSLも利用しますのでopensslも一緒にインストールします。

$ sudo apt update -y
$ sudo apt install -y haproxy openssl

haproxy.cfgを修正します。

$ sudo vi /etc/haproxy/haproxy.cfg

haproxy.cfgファイル文末に以下を追記します。maxconnなどHAProxyのパラメーターについては構築するシステムに併せて修正してください。2台とも同じ設定を行います。

/etc/haproxy/haproxy.cfg
<文末>

frontend front_in
    #bind [共有IP]:80   # HTTPでのテスト用
    #bind 個別のPublic IP:443 ssl crt /etc/ssl/private/[FQDN].pem   #IP Sharing未使用でのテスト用
    ##  SSL binding ##
    bind [共有IP]:443 ssl crt /etc/ssl/private/[FQDN].pem
    maxconn 30000
    default_backend web_backend

backend web_backend
    mode http
    balance roundrobin
    cookie lbsessionid insert nocache indirect preserve httponly secure maxidle 30m maxlife 8h
    # HTTPでのテスト時はsecure設定を外す
    # cookie lbsessionid insert nocache indirect preserve httponly maxidle 30m maxlife 8h 
    server web1 [web01のpublic IP]:80 maxconn 30000 check cookie w01 inter 2000 rise 2 fall 5
    server web2 [web02のpublic IP]:80 maxconn 30000 check cookie w02 inter 2000 rise 2 fall 5
    server web3 [web03のpublic IP]:80 maxconn 30000 check cookie w03 inter 2000 rise 2 fall 5
    option forwardfor
    option httpchk GET /server.html   #死活監視用のターゲットコンテンツ。ここではserver.htmlを指定

listen stats
   bind  :8222 ssl crt /etc/ssl/private/[FQDN].pem
   #mode http   # HTTPでのテスト用
   stats enable
   stats uri /stats
   stats hide-version
   stats show-node
   stats auth USER:PASSWORD  # HAProxyのステータス画面のユーザー名およびパスワード

HAProxyサービスを起動します。

$ sudo systemctl start haproxy
$ sudo systemctl enable haproxy

Webサーバーの準備

3台のWebサーバーを準備します。ここではシンプルなserver.htmlを準備して、どのサーバーに接続されているかわかりやすくしています。Webサーバーの構築については割愛します。

/var/www/html/server.html
<html><head></head><body>
<h1>Web-01</h1>
</html>

Webサーバーの冗長化確認

最後に、接続するFQDNのDNSレコードを追加し接続を行います。DNSサーバーの設定については保持しているドメインにより異なりますので割愛します。AレコードのIPアドレスはIP Sharingで割り当てられたHAProxyの共有IPアドレスです。

image.png

作成したWebサイトのURLにアクセスします。
https://[FQDN]/server.html

ラウンドロビンでランダムに割り振られて、セッション永続性のためのCookieが付与されます。ここではWeb01にリクエストが振られました。
image.png

haproxy.cfgで指定したCookieが付与されています。

haproxy.cfgの抜粋
　#この行にて、lbsessionidというCookieを付与しています。
  cookie lbsessionid insert nocache indirect preserve httponly secure maxidle 30m maxlife 8h

そのCookieを用いて、セッション永続性が機能していることがわかります。
（スクリーンショットはChromeブラウザのEditThiscookie拡張機能を用いて表示しています）

なおHAProxyの上では以下のようなアクセスログが確認できます。

Jul  4 02:01:52 localhost haproxy[32097]: 198.51.10.1:1562 [04/Jul/2023:04:01:52.422] front_in~ web_backend/web1 0/0/5/1/6 304 187 - - --VU 1/1/0/0/0 0/0 "GET /server.html HTTP/1.1"

Web01をシャットダウンしてから再度アクセスしてみます。今度はWeb02にリクエストが切り替わりました。HAProxyにてHTTP GETによるコンテンツ応答確認を行っていますので、プロセスが落ちてしまった場合でも切り替わります。
image.png

Cookieも同様にweb02に変更されています。

HAProxyの「listen stats」項で設定しているポートにてHAproxyの接続状況及びWebサーバーのステータスを可視化することができます。
https://[FQDN]:8222/stats

Web01に接続したときのステータス画面です。Web01でセッションがカウントアップしていることがわかります。
image.png

Web01をシャットダウンした後のステータス画面です。Web01がダウン状態となり、かつWeb02のセッションがカウントアップしていることがわかります。
image.png

なおAkamai CDN を手前に配置するケースでは セキュリティ強化のため 443 ポートで受け付ける必要があるため、CDN 上で ステータス用のパスに対してオリジンにフォワードするポートを 8222 に設定してください。

HAProxyの冗長化確認

続いて、HAProxyサーバーの冗長化を確認します。
image.png

まずは通常時の構成です。1台目のhaproxy01にて処理されていることがわかります。（※事前にOSのホスト名設定が必要です）
image.png

1台目のHAProxyサーバーをシャットダウンしてみます。しばらく待つと今度は「haproxy02」で処理されていることが確認できます。KeepAlivedにてHAProxyのプロセスが落ちてしまった場合でも切り替わります。
image.png

割り当てられた共有IPの移動および、ログレベルでのKeepalivedでの状態遷移はコマンドにて確認可能です。詳細についてはIP Sharingの記事を確認してください。

Cloud Firewallの設定

Akamaiのcloud computing servicesで提供されているCloud FirewallにてLinodeインスタンスへのアクセス制御を行うことが可能です。
image.png

Cloud Firewallの設定方法については以下の画面をご参考ください。

haproxy-lb Firewallルール

まずは1つ目のFirewallを作成してルールを適用します。
image.png
作成したルールを、2台のHAProxyサーバーへ適用します。
image.png　

haproxy-web Firewallルール

続いて2つ目のFiwarellを作成してルールを適用します。
image.png
作成したルールを、3台のWebサーバーへ適用します。
image.png

以上により、それぞれのLinodeインスタンスでアクセス制御を行うことができました。

Site Shieldの設定

AkamaiのWeb Secuirty/CDNサービスを併用する場合、AkamaiからのIPアドレスのみを許可することができます。
image.png

SiteShieldの詳細については以下をご参考ください。

Site Shieldで利用されるIPアドレスリストをFirewallのルールに適用するだけでアクセス制御が完了します。
image.png

まとめ

Akamaiのcloud computing servicesではManagedのロードバランサーも提供されておりますが、Linuxで稼働するロードバランサーソフトウェアでもサービスの冗長と分散を行うことができます。ぜひ、システムの要件に合わせて最適なソリューションを検討してください。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?