Google Compute Engine 上の HAProxy を使用した内部負荷分散

このソリューションでは、専用の Compute Engine インスタンスで HAProxy を使用する内部ロードバランサを設定し、Apache ウェブサーバーを実行する 3 つの Compute Engine インスタンスで HTTP リクエストを分散させます。

ロードバランサは、受信ネットワーク トラフィックを受け取り、アプリケーション サーバーのグループ全体に分散します。たとえば、Google Compute Engine 負荷分散サービスは、Compute Engine インスタンスから受信トラフィックを分散します。次の図に、Compute Engine ネットワーク負荷分散の仕組みを示します。

Compute Engine ネットワーク負荷分散の説明図

内部ロードバランサは、インターネットに公開されていないプライベート ネットワークにネットワーク トラフィックを分散します。内部負荷分散は、すべてのトラフィックがプライベート ネットワーク上に留まっているイントラネット アプリケーションに対してだけでなく、フロントエンドがプライベート ネットワーク経由でバックエンド サーバーにリクエストを送信する複雑なウェブ アプリケーションに対しても有用です。

ソフトウェアのロードバランサを使用して、独自の内部ロードバランサを作成するには、Compute Engine を使用します。このようなロードバランサを実装する方法の 1 つとして、オープンソース ソフトウェアのロードバランサである HAProxy を Compute Engine のインスタンスで使用する方法があります。次の図は、Google Cloud Platform で内部負荷分散のために HAProxy を使用する方法を簡単に示したものです。

内部ロードバランサとしての HAProxy の概要図

図の緑の実線の矢印は、プライベート ネットワークのトラフィックを示しています。HAProxy サーバーはインターネットに公開されていないため、内部ロードバランサとして機能します。HAProxy サーバーは、プライベート ネットワークでリクエストを受け取り、これを内部 IP アドレスを経由してのみアクセスできるバックエンド サーバーのグループ全体に分散します。

このソリューションでは Compute Engine のインスタンスを合計 5 つ作成します。1 つは HAProxy 用で、3 つはバックエンド Apache サーバー用、残り 1 つはテスト用のマイクロ インスタンスです。次の図は、この 5 つのインスタンスがどのように連携するかを示しています。

内部ロードバランサとしての HAProxy の詳細図

信頼性に関する検討事項

HAProxy をそれ専用のインスタンスで実行すると単一障害点が形成されるため、ここでは Compute Engine の Instance Group Manager API(現時点ではベータ版)を使用してロードバランサが実行され続けるようにします。Instance Group Manager は HAProxy の Compute Engine インスタンスの状況をモニタリングし、このインスタンスが実行を停止した場合、インスタンスを再作成します。

HAProxy サーバーの基礎となるインスタンスが実行されていても、HAProxy ロードバランサ サービスが実行されているとは限りません。HAProxy サービスが失敗したイベントでこのサービスを確実に再起動するには、Debian 9 のデフォルトのインストールの一部であるシステム管理ユーティリティ systemd を使用します。

目標

  • 3 台のバックエンド Apache サーバーの設定
  • HAProxy を実行している、1 つの Compute Engine インスタンスのマネージド インスタンス グループの設定
  • テスト用として外部 IP アドレスを持つ Compute Engine マイクロ インスタンスの設定
  • バックエンド Apache サーバーにトラフィックの負荷を分散する HAProxy の設定

事前準備

  1. クリーンアップを容易にするために新しい Google Cloud Platform Console プロジェクトを作成します。

  2. Google Cloud Platform Console を使用して Compute Engine と Instance Group Manager API を有効にします

  3. Google Cloud SDK をインストールします。

  4. コマンドが冗長にならないようにワークスペースを設定します。次のコマンドの project-idmy-zone を使用するプロジェクトの値に置き換えます。

    me@local:~$ gcloud config set project project-id
    me@local:~$ gcloud config set compute/zone my-zone
    

3 台のバックエンド Apache サーバーの作成

内部ロードバランサを使用して、データベース サーバー、重要なキャッシュ、ウェブサーバーなどのさまざまなコンピューティング リソースにトラフィックを分散します。このソリューションでは、Apache ウェブサーバーを実行している 3 台のグループを使用します。その後のソリューションでは、バックエンド サーバーの自動スケール グループで内部ロードバランサを使用する方法を説明します。

Apache サーバーを含むカスタム イメージの作成

以下の手順でバックエンド サーバー向けのカスタム イメージを作成します。

  1. このカスタム イメージのベースとして使用する Compute Engine のインスタンスを作成します。

    me@local:~$ gcloud compute instances create apache-base --image-project debian-cloud --image-family debian-9
    
  2. インスタンスにログインして Apache2 をインストールします。

    me@local:~$ gcloud compute ssh apache-base
    apache-base:~$ sudo apt-get update && sudo apt-get install -y apache2
    apache-base:~$ exit
    
  3. インスタンスを終了しますが、起動ディスクはそのまま維持します。

    me@local:~$ gcloud compute instances delete apache-base --keep-disks boot
    
  4. 先ほど作成したソースディスクを使用してカスタム イメージを作成します。

    me@local:~$ gcloud compute images create apache-base-image --source-disk apache-base
    

カスタム イメージに基づいた 3 台のバックエンド Apache サーバーの作成

次のコマンドを実行して、すべてが Apache サーバーを実行している 3 台のバックエンド サーバーを作成します。

me@local:~$ gcloud compute instances create apache1 apache2 apache3 \
--image apache-base-image --no-address \
--metadata startup-script='#! /bin/bash
cat << _EOF_ > /var/www/html/index.html
This is $(hostname)
_EOF_'

--no-address オプションで、外部 IP アドレスを持たないインスタンスが生成されます。--metadata オプションには各 Apache サーバーのホームページを編集する起動スクリプトが含まれており、インスタンスの名前が出力されます。これで、ロードバランサが 3 台すべてのバックエンド サーバーにリクエストを分散しているかどうか簡単に確認できるようになります。

Compute Engine は、サーバーの名前とその内部 IP アドレスを返します。3 台のバックエンド サーバーそれぞれに内部 IP アドレスが指定されていることに注意してください。この IP アドレスは HAProxy 設定ファイルに必要です。

テスト用のマイクロ インスタンスの作成

開発用マシンには外部 IP アドレスが指定されていないため、ロードバランサとバックエンド サーバーのテストには使用できません。以下の手順でバックエンド サーバーとロードバランサをテストできるように、外部 IP アドレスを持つマイクロ インスタンスを作成します。

  1. --machine-typef1-micro を設定したテスト インスタンスを作成します。

    me@local:~$ gcloud compute instances create test-instance --machine-type f1-micro
    
  2. test-instance インスタンスへの SSH 接続を確立します。

    gcloud compute ssh test-instance

  3. curl を使用してバックエンド ウェブサーバーを確認します。

    me@test-instance:~$ curl apache1
    me@test-instance:~$ curl apache2
    me@test-instance:~$ curl apache3
    me@test-instance:~$ exit
    

HAProxy を実行する内部ロードバランサの作成

このソリューションでは、HAProxy サービスは専用 Compute Engine インスタンス上で動作します。単一障害点のリスクを抑えるため、Compute Engine インスタンスと HAProxy サービス自身の両方の正常性を守る措置を講じることができます。

基盤となっている Compute Engine のインスタンスの稼働状態を維持するには、マネージド インスタンス グループを使用します。HAProxy インスタンスがマネージド インスタンス グループの場合、Instance Group Manager はサーバーの状況を確認し、実行を停止している場合はインスタンスを再作成します。gcloud compute instances コマンドまたは Compute Engine API を使用してインスタンスを停止または終了した場合でも、Instance Group Manager はイメージを再作成します。ただし、gcloud compute instance-groups managed delete-instances コマンドまたは Instance Group Manager API を使用してインスタンスを削除した場合、インスタンスは削除されたままになります。

マネージド インスタンス グループは 3 つのステップで作成されます。最初にカスタム イメージを作成します。次に、このカスタム イメージを使用してインスタンスのテンプレートを作成します。最後にこのインスタンスのテンプレートを使用してマネージド インスタンス グループを作成します。

HAProxy サービスの稼働状態を維持するには、HAProxy サービス用のユニット設定ファイルを常に再起動するように設定している必要があります。設定が適切であれば、プロセスが強制終了した場合、通常に終了した場合、タイムアウトになった場合に、システムはサービスをすぐに再起動します。

以下の手順で HAProxy カスタム イメージ、インスタンスのテンプレート、マネージド インスタンス グループを作成します。

HAProxy インスタンス用のベースイメージの作成

  1. debian-9 イメージを使用して Compute Engine インスタンスを作成します。

    me@local:~$ gcloud compute instances create haproxy-base --image-project debian-cloud image-family debian-9
    
  2. インスタンスにログインして HAProxy をインストールします。

    me@local:~$ gcloud compute ssh haproxy-base
    haproxy-base:~$ sudo apt-get update && sudo apt-get -y install haproxy
    
  3. バックエンド サーバーのリストに設定ファイルを追加して HAProxy を設定します。internal-ip は、前の手順でメモした内部 IP アドレスに置き換えます。

    haproxy-base:~$ echo -e "\n\n# Listen for incoming traffic
    listen apache-lb *:80
        mode http
        balance roundrobin
        option httpclose
        option forwardfor
        server apache1 $(getent hosts apache1 | awk '{print $1}'):80 check
        server apache2 $(getent hosts apache2 | awk '{print $1}'):80 check
        server apache3 $(getent hosts apache3 | awk '{print $1}'):80 check
    " | sudo tee -a /etc/haproxy/haproxy.cfg
    

このコマンドを実行する前に、3 か所の internal-ip を実際の IP アドレスと置き換えることを忘れた場合、テキスト エディタを使用して置き換えてから処理を進めてください。

HAProxy サービスが常に再起動するよう設定されていることの確認

  1. テキスト エディタを使用して haproxy-check.sh という名前のファイルを表示します。

    haproxy-base:~$ sudo nano /lib/systemd/system/haproxy.service
    
  2. Restart=always[Service] セクションの下にリストされていることを確認します。Restart=always がリストされていなければ追加します。

    [Service]
    Environment=CONFIG=/etc/haproxy/haproxy.cfg
    ...
    Restart=always
    
  3. ファイルを閉じ、変更をすべて保存して、シェルを終了します。

    haproxy-base:~$ exit
    

カスタム イメージの作成

Apache サーバーのカスタム イメージを作成するために使用したものと同じ手順で HAProxy サーバー用のカスタム イメージを作成します。

  1. インスタンスを終了しますが、起動ディスクはそのまま維持します。

    me@local:~$ gcloud compute instances delete haproxy-base --keep-disks boot
    
  2. 先ほど作成したソースディスクを使用してカスタム イメージを作成します。

    me@local:~$ gcloud compute images create haproxy-base-image --source-disk haproxy-base
    

カスタム イメージを基準に HAProxy インスタンスのテンプレートを作成する

--no-address オプションを使用して、外部 IP アドレスの割り当てを防止します。

 me@local:~$ gcloud compute instance-templates create haproxy-template \
 --image haproxy-base-image --no-address

haproxy という名前のマネージド インスタンス グループの作成

--base-instance-name オプションで、Instance Group Manager が作成したインスタンスに割り当てるインスタンス名の接頭辞を設定できます。この例では、haproxy-server を接尾辞として使用します。インスタンス名は haproxy-server-xxxx のようになり、xxxx には一連の文字または数字が入ります。

me@local:~$ gcloud compute instance-groups managed create haproxy \
--base-instance-name haproxy-server --size 1 --template haproxy-template

HAProxy サーバーの名前を取得し、ロードバランサをテストする

マネージド インスタンス グループを作成すると、Instance Group Manager によってインスタンスが作成されます。gcloud compute instances コマンドを使用して新しいインスタンスの名前を検索します。

  1. HAProxy インスタンスの名前をメモしてから、インスタンス test-instance に SSH 接続します。

    me@local:~$ gcloud compute instances list --filter 'name ~ haproxy-server-\w{4}' --format='get(name)'
    me@local:~$ gcloud compute ssh test-instance
    
  2. curl を使用してプロキシ サーバーをテストします。haproxy-server-xxxx は実際のプロキシ サーバーに置き換えます。このコマンドを繰り返すと、3 台のウェブサーバーごとに値が返されます。

    me@test-instance:~$ curl haproxy-server-xxxx
    
  3. test-instance のシェルを終了します。

    me@test-instance:~$ exit
    

ロードバランサの復元力のテスト

ロードバランサの復元性をテストする 2 種類の失敗シナリオを紹介します。最初に HAProxy の Compute Engine インスタンスを停止して、Instance Group Manager がインスタンスを再作成するかどうか、起動スクリプトが HAProxy サービスを適切に再起動するかどうかをテストします。次に HAProxy サーバーにログインし、HAProxy サービスを手動で停止して、systemd が失敗を検出し、サービスを再起動するかどうかをテストします。

HAProxy インスタンスのテスト

以下の手順で HAProxy マネージド インスタンス グループの復元力をテストします。

  1. gcloud compute instances コマンドを使用して HAProxy インスタンスを停止します。haproxy-server-xxxx は実際のプロキシ サーバー名に置き換えます。

    me@local:~$ gcloud compute instances stop haproxy-server-xxxx
    
  2. 数分待ってから、インスタンスが実行されているかどうかを確認します。Instance Group Manager はインスタンスを再作成する必要があります。

    me@local:~$ gcloud compute instances list
    
  3. インスタンスが再度実行されたら、テスト インスタンスにログインし、ロードバランサが機能していることを確認します。テストを完了したらテスト インスタンスからログアウトします。

HAProxy サービスのテスト

HAProxy サービスをテストするには、開発用マシンから HAProxy インスタンスに直接接続できないため、ステップをいくつか追加する必要があります。ただし、test-instance に接続してから、インスタンス間 SSH を使用して haproxy-server-xxxx インスタンスにアクセスできます。

  1. インスタンス間 SSH を設定します。

    me@local:~$ eval `ssh-agent`
    me@local:~$ ssh-add ~/.ssh/google\_compute\_engine
    
  2. ssh-flag オプションを指定して test-instance に接続します。

    me@local:~$ gcloud compute ssh test-instance --ssh-flag="-A"
    
  3. test-instance で使用して haproxy-server-xxxx インスタンスに接続します(haproxy-server-xxxx は haproxy-server インスタンスの名前に置き換えます)。

    me@test-instance:~$ ssh haproxy-server-xxxx
    
  4. haproxy サーバーの状態を確認します。コマンド出力には running という語、最新のサービスが起動されたタイムスタンプ、起動からの経過時間が含まれているはずです。

    me@haproxy-server-xxxx:~$ sudo service haproxy status | grep Active
    
  5. HAProxy サーバー プロセスを強制終了して HAProxy サービスが再起動されるかどうかテストします。

    me@haproxy-server-xxxx:~$ sudo pkill haproxy
    
  6. 状況をもう一度確認し、HAProxy サービスが再起動されるかどうか確認します。コマンド出力では、サービスが running であるともう一度報告されますが、最後のサービス起動のタイムスタンプはより最新のものになっているはずです。

    me@haproxy-server-xxxx:~$ sudo service haproxy status | grep Active
    
  7. 両方のインスタンスのシェルを終了します。

    me@haproxy-server-xxxx:~$ exit
    me@test-instance:~$ exit
    

クリーンアップ

HAProxy のチュートリアルが終了したら、Google Cloud Platform で作成したリソースに関する料金が発生しないようにクリーンアップします。以下のセクションで、このようなリソースを削除または無効にする方法を説明します。

プロジェクトの削除

課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除するには:

  1. GCP Console で [プロジェクト] ページに移動します。

    プロジェクト ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

インスタンスの削除

Compute Engine インスタンスを削除するには:

  1. GCP Console の [VM インスタンス] ページに移動します。

    [VM インスタンス] ページに移動

  2. test-instanceインスタンスの隣のチェックボックスを選択します。
  3. ページの上部にある、[削除] ボタンをクリックし、インスタンスを削除します。

ディスクの削除

Compute Engine ディスクを削除する方法は次のとおりです。

  1. GCP Console で [ディスク] ページに移動します。

    [ディスク] ページに移動

  2. 削除したいディスクの隣にあるチェックボックスをオンにします。
  3. ページの上部にある [削除] ボタンをクリックし、ディスクを削除します。

次のステップ

プライベート ネットワークで実行される Compute Engine のインスタンスで HAProxy を使用することで、内部負荷分散ソリューションを作成する方法を確認しました。ロードバランサが Instance Group Manager API と systemd を使用して、ロードバランサの正常性を監視し、修復することによって、さらに復元力を高める方法についても確認しました。

このソリューションを拡張または変更し、データベース サーバーや重要ストアなどの別のバックエンド アプリケーションをサポートすることができます。Compute Engine Autoscaler 機能を使用することで、バックエンド サーバープールのスケーラビリティを高めることもできます。

内部ロードバランサの負荷テスト方法については、Kubernetes を使用した負荷分散テストをご覧ください。

Google Cloud Platform で使用可能な他の負荷分散ソリューションについては以下をご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...