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

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

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

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

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

Compute Engine を使用すると、ソフトウェアのロードバランサを使用して独自の内部ロードバランサを作成できます。このようなロードバランサを実装する方法の一つは、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 サーバーを作成する

内部ロードバランサを使用して、データベース サーバー、Key-Value キャッシュ、ウェブサーバーなどのさまざまなコンピューティング リソースへのトラフィックを分散します。このソリューションでは、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 アドレスをメモしてください。これらのアドレスは 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 で SSH を使用して 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 を使用して、ロードバランサの正常性をモニタリングし、修復することによって、その復元力を高める方法についても確認しました。

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

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

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

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

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