Compute Engine 上の HAProxy と Consul を使用した内部負荷分散の自動スケーリング

このソリューションでは、Google Cloud Platform 上にある HAProxy ベースの内部負荷分散システムの一部として使用される HashiCorp 社の Consul の使用方法を説明します。

内部ロードバランサは、ネットワーク トラフィックをプライベート ネットワーク上のサーバーに分散します。内部ロードバランサとサービスの配布先のサーバーは、いずれもインターネットには公開されていません。Google Compute Engine 上で HAProxy を使用する内部負荷分散のチュートリアルには、内部負荷分散に関する基本的な説明や、HAProxy と Google Compute Engine を使用する内部ロードバランサの設定手順が記載されています。

このソリューションは、HAProxy 負荷分散階層とバックエンド サーバー階層の両方で自動スケーリングをサポートするように以前の構成を拡張します。この変更によって、それぞれの階層でサーバーを適切に追加または削除できるので、インフラストラクチャで負荷の変化に対応したり、障害から回復したりすることができます。 Consul は、この負荷分散アーキテクチャを実現するためのサービス ディスカバリおよび分散設定メカニズムを提供します。

ソフトウェア スタック

テクノロジー 説明
Consul サービス ディスカバリを提供します。サーバーを Consul に登録すると、クラスタ内の他のサーバーから検出できるようになります。
Consul テンプレート consul-template のデーモンを使用すると、Consul からファイル システムに簡単に値を入力できます。
Dnsmasq ドメイン ネーム サービス(DNS)クエリをインスタンスから Consul に転送します。これにより、DNS に依存するアプリケーションが Consul 内のサービスを簡単に検出できるようになります。
HAProxy ハイパフォーマンス TCP / HTTP ロードバランサ。
バックエンド サーバー Compute Engine インスタンスのローカル メタデータを JSON として出力する単純な Go アプリケーション。
フロントエンド サーバー バックエンド サーバー API からの JSON を消費し、HTML としてレンダリングするシンプルな Go アプリケーション。
Packer 事前設定された Google Compute Engine VM イメージを作成するためのツール。Packer は、Consul と HAProxy を起動可能なイメージにインストールおよび設定するために使用されます。
Cloud Platform マネージド インスタンス グループとオートスケーラー マネージド インスタンス グループは、共通のインスタンス テンプレートから作成された同種のインスタンスのプールです。オートスケーラーは、マネージド インスタンス グループからインスタンスを追加または削除します。

学習内容

以下の各セクションでは、アーキテクチャ図の特定の要素について説明し、Compute Engine でそのセクションをプロビジョニングするための詳しい手順を説明します。ドキュメントを最後まで読むと、アーキテクチャの各セクションに関する詳細を学習し、ご自身の環境で実行および使用できるようになります。

始める前に

  1. Google アカウントにログインします。

    Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

  2. GCP プロジェクトを選択または作成します。

    [リソースの管理] ページに移動

  3. プロジェクトに対して課金が有効になっていることを確認します。

    課金を有効にする方法について

  4. Cloud SDK をインストールして初期化します。

sudo gcloud components update を実行するように要求された場合は、必ず実行してください。

Consul クラスタ

Consul は、このアーキテクチャでサービスの登録と検出の機能を提供します。HAProxy を実行する Compute Engine インスタンスは、起動時に haproxy-internal という名前の Consul サービスに登録し、フロントエンド サーバーが、Consul に対する DNS クエリを使用してすべての HAProxy サーバーを検出できるようになります。同様に、バックエンド アプリケーションを実行しているインスタンスは、backend という名前の Consul サービスに登録し、HAProxy サーバーによって検出可能になります。

サービスの登録と検出をサポートするために、少なくとも 1 つの Consul サーバーを実行する必要があります。Consul の作成者は、データセンターあたり 3~5 台の Consul サーバーを実行することを強く推奨しています。このドキュメントの例では、3 つの Consul サーバーの実行を推奨しています。

ハンズオン: Consul サーバーの起動

  1. gitpacker がプリインストールされた tool という名前の Compute Engine インスタンスを作成します。

    gcloud compute instances create tool \
      --scopes=cloud-platform \
      --zone=us-central1-f \
      --image=debian-8 \
      --metadata "startup-script=apt-get update -y && \
        sudo apt-get install -y git unzip && \
        curl -o /tmp/packer.zip https://releases.hashicorp.com/packer/0.8.6/packer_0.8.6_linux_amd64.zip && \
        curl -o /tmp/consul.zip https://releases.hashicorp.com/consul/0.6.3/consul_0.6.3_linux_amd64.zip && \
        sudo unzip /tmp/packer.zip -d /usr/local/bin/ && \
        sudo unzip /tmp/consul.zip -d /usr/local/bin/"
    
  2. インスタンスに SSH 接続する前に、スクリプトの実行時間のために数分待ちます。

  3. 新しい tool インスタンスに接続します。

    gcloud compute ssh tool --zone=us-central1-f
    
  4. ソースコード レポジトリのクローンを tool インスタンスに作成します。

    cd ~
    git clone https://github.com/GoogleCloudPlatform/compute-internal-loadbalancer.git
    
  5. プロジェクト ID を含む環境変数を設定します。解決策はすべて自動的に処理されるため、PROJECT_IDproject-id を置き換えないようにします。

    export PROJECT_ID=$(curl -H "metadata-flavor: Google" http://metadata.google.internal/computeMetadata/v1/project/project-id)
    
  6. Consul イメージ ファイルが含まれるディレクトリに変更します。

    cd ~/compute-internal-loadbalancer/images/consul
    
  7. packer を使用して、Consul サーバー用の Google Compute Engine VM イメージを構築します。PROJECT_ID は前の手順で変数として設定済みのため、これをプロジェクトの ID に置き換えないようにします。

    packer build -var project_id=${PROJECT_ID} packer.json
    
  8. 作成したイメージの ID をコピーします。ID は Builds finished メッセージ内に表示されます。たとえば、次のメッセージでは、ID は consul-1450847630 です。

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: consul-1450847630
    

    この ID をメモします。次の手順やこのソリューションで後で必要になります。

  9. 3 台の Consul サーバーを起動します。必ず、--image フラグの値を前の手順で作成したイメージ ID に置き換えます。

    gcloud compute instances create consul-1 consul-2 consul-3 \
      --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
      --zone=us-central1-f \
      --no-address \
      --image=YOUR_CONSUL_IMAGE_ID
    
  10. tool インスタンスをクラスタに参加させます。

    consul agent \
      -data-dir=/tmp/consul \
      -retry-join=consul-1 \
      -retry-join=consul-2 \
      -retry-join=consul-3 &
    
  11. インスタンスがクラスタに正常に参加したことを示すメッセージが表示されたら clear を入力して、コンソールをクリアします。この時点ではプロンプトは表示されず、点滅するブロック カーソルのみが表示されます。

  12. クラスタ メンバーを表示し、consul-1consul-2consul-3server タイプとして参加していることを確認します。

    consul members
    

    次のような出力が表示されます。

      Node          Address           Status  Type    Build  Protocol  DC
      consul-1      10.240.0.5:8301   alive   server  0.6.0  2         dc1
      consul-2      10.240.0.3:8301   alive   server  0.6.0  2         dc1
      consul-3      10.240.0.4:8301   alive   server  0.6.0  2         dc1
      tool          10.240.0.2:8301   alive   client  0.6.0  2         dc1
    

バックエンド アプリケーション

この例のバックエンド アプリケーションは、実行されている Compute Engine のインスタンス メタデータを返す単純なマイクロサービスです。アプリケーションは、HTTP GET リクエストに対するレスポンスの JSON 文字列としてインスタンス メタデータを返します。バックエンド アプリケーションを実行しているインスタンスには非公開の IP アドレスはありますが、公開アドレスはありません。サンプル アプリケーションのソースコードは GitHub から取得できます。

バックエンドのブートストラップ

バックエンド アプリケーションを実行している VM は、オンラインになったときに既存の Consul クラスタに参加し、それ自体をサービスとしてクラスタに登録してから、アプリケーション プロセスを起動して HTTP リクエストに応答する必要があります。2 つの systemd ユニット(consul_servers.servicebackend.service)がこのブートストラップを実行します。

  • consul_servers.service: このユニットが consul_servers.sh シェル スクリプトを呼び出し、このスクリプトがインスタンスのメタデータ ストアから Consul サーバーの名前を取得して、それらを /etc/consul-servers ファイルに書き込みます。Consul サーバーがすでに実行されている必要があり、バックエンド サーバーが consul_servers という名前のメタデータ属性を使用して起動される必要があります。この属性の値はカンマで区切られた Consul サーバー名のリストです。ユニット ファイルは次のようになります。

    [Unit]
    Description=consul_servers
    
    [Service]
    Type=oneshot
    ExecStart=/bin/sh -c "/usr/bin/consul_servers.sh > /etc/consul-servers"
    
    [Install]
    WantedBy=multi-user.target
    
  • backend.service: このユニットは consul_servers.service の後に実行されます。このユニットは、Consul サーバー名を /etc/consul-servers から読み取り、その後で backend-start.sh スクリプトを実行します。このスクリプトは、Consul サービス ファイルを作成し、次にクラスタに参加してサービスを登録してから、最後にバックエンド アプリケーションを起動します。

    backend.service ユニット ファイルを以下に示します。

    [Unit]
    Description=backend
    After=consul_servers.service
    Requires=consul_servers.service
    
    [Service]
    EnvironmentFile=/etc/consul-servers
    ExecStart=/usr/bin/backend-start.sh
    LimitNOFILE=9999999
    
    [Install]
    WantedBy=multi-user.target
    

    backend-start.sh スクリプトを以下に示します。

    #! /bin/bash
    export zone=$(curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/zone" | grep -o [[:alnum:]-]*$)
    
    # Set zone in Consul and HAProxy files
    envsubst < "/etc/consul.d/backend.json.tpl" > "/etc/consul.d/backend.json"
    
    # Start consul
    consul agent -data-dir /tmp/consul -config-dir /etc/consul.d $CONSUL_SERVERS &
    
    # Start the microservice
    /opt/www/gceme -port=8080
    

バックエンドの Consul サービス

backend.service の起動時に生成される /etc/consul.d/backend.json サービス ファイルを以下に示します。

{
  "service": {
    "name": "backend",
    "tags": "us-central1-f",
    "port": 8080,
    "check": {
      "id": "backend",
      "name": "HTTP on port 8080",
      "http": "http://localhost:8080/healthz",
      "interval": "10s",
      "timeout": "1s"
    }
  }
}

バックエンド サーバー上で Consul エージェントが起動されると、そのサーバーが Consul クラスタに backend サービスとして登録され、サーバーが実行されている可用性ゾーンがタグとして使用されます。DNS 名 backend.service.consul. を解決することで、サービスのメンバーを検出できます。特定の可用性ゾーンでサービス メンバーを検出するには、us-central1-f.backend.service.consul. のように名前の前にタグを付けます。

ハンズオン: バックエンド サービスの起動

このハンズオン セクションでは、Packer を使用してバックエンド サービスのための VM イメージを構築し、次にインスタンス グループを使用して、バックエンド サーバーのクラスタを作成および管理します。

  1. tool インスタンスで、バックエンド イメージ ファイルが含まれるディレクトリに変更します。

    cd ~/compute-internal-loadbalancer/images/backend
    
  2. packer を使用して、Consul サーバー用の Compute Engine VM イメージをビルドします。繰り返しますが、このコマンドラインは現在の変数値を使用しているのでどの部分も置き換えないでください。

    packer build -var project_id=${PROJECT_ID} packer.json
    
  3. 次のような、作成されたイメージの ID をコピーします。

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: backend-1450847630
    

    この ID をメモします。次の手順やこのソリューションで後で必要になります。

  4. バックエンド サーバーの設定を記述するインスタンス テンプレートを作成します。必ず、YOUR_BACKEND_IMAGE_ID を前の手順の出力に置き換えてください。

    gcloud compute instance-templates create backend \
      --no-address \
      --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
      --image=YOUR_BACKEND_IMAGE_ID
    
  5. バックエンド テンプレートを使用して 2 つのバックエンド サーバーを起動するインスタンス グループを作成します。

    gcloud compute instance-groups managed create backend \
      --base-instance-name=backend \
      --template=backend \
      --size=2 \
      --zone=us-central1-f
    

HAProxy ロードバランサ階層

HAProxy は、バックエンド サーバーへの負荷分散リクエストに使用されます。HAProxy を実行している VM は、オンラインになったときに既存の Consul クラスタに参加し、それ自体をサービスとしてクラスタに登録してから、バックエンド サービス内でサーバーを検出し、HAProxy を起動する必要があります。バックエンド サーバーと同様に、HAProxy サーバーは非公開 IP アドレスを持っており、公共のインターネットを介してアクセスすることはできません。

HAProxy Consul サービス

各 HAProxy サーバーによって Consul に登録されるサービスは、haproxy-internal という名前が付けられ、次のように定義されます。

{
  "service": {
    "name": "haproxy-internal",
    "tags": "us-central1-f",
    "port": 8080,
    "check": {
      "id": "haproxy",
      "name": "HTTP on port 8080",
      "http": "http://localhost:8080",
      "interval": "10s",
      "timeout": "1s"
    }
  }
}

前のバックエンド サービスと同様に、haproxy-internal サービスはインスタンスがで実行されている可用性ゾーンでタグ付けされます。これにより、フロントエンド アプリケーションが haproxy-internal.service.consul 名を使用して任意のロードバランサに接続できるようになり、さらに、ルックアップ名の前に特定のゾーンを付けることでゾーン固有のルックアップが可能になります。たとえば us-central1-f.haproxy-internal.service.consul は、us-central1-f 可用性ゾーンのサービス メンバーのみを返します。

consul-template を使用したバックエンド サービス内のサーバーの検出

負荷分散リクエストのために、すべての正常なバックエンド サーバーの IP アドレスを知る必要がある HAProxy サーバーのグループを作成します。このソリューションは、consul-template を使用して /etc/haproxy/haproxy.cfg という名前の HAProxy の設定ファイルを更新し、バックエンド サービスのメンバーが変更されるたびに HAProxy サービスを再ロードします。この haproxy.cfg テンプレートのスニペットは、ゾーン固有の us-central1-f.backend サービスを表示します。このサービスは、反復処理され、使用可能なサーバーを示す server ディレクティブを HAProxy に書き込みます。

listen http-in
        bind *:8080&lcub;{range service "us-central1-f.backend"}}
        server &lcub;{.Node}} &lcub;{.Address}}:&lcub;{.Port}}&lcub;{end}}

consul-template は、次のように systemd によって実行されます。

consul-template -template "/etc/haproxy/haproxy.ctmpl:/etc/haproxy/haproxy.cfg:service haproxy restart" -retry 30s -max-stale 5s -wait 5s

詳しくは、consul_template.service ユニット ファイルをご覧ください。

ハンズオン: HAProxy ロードバランサの起動

このハンズオン セクションでは、Packer を使用して HAProxy ロードバランサ サーバーのための VM イメージを構築し、次にインスタンス グループを使用して、サーバーのクラスタを作成および管理します。

  1. tool インスタンスで、HAProxy イメージが含まれるディレクトリに変更します。

    cd ~/compute-internal-loadbalancer/images/haproxy
    
  2. packer を使用して、Compute Engine VM イメージをビルドします。以下のコマンドをそのまま使用します。

    packer build -var project_id=${PROJECT_ID} packer.json
    
  3. 次のような、作成されたイメージの ID をコピーします。

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: haproxy-1450847630
    

    この ID をメモします。次の手順やこのソリューションで後で必要になります。

  4. バックエンド サーバーの設定を記述するインスタンス テンプレートを作成します。必ず、YOUR_HAPROXY_IMAGE_ID を前の手順の出力に置き換えてください。

    gcloud compute instance-templates create haproxy \
      --no-address \
      --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
      --image=YOUR_HAPROXY_IMAGE_ID
    
  5. 2 つの HAProxy サーバーを起動するインスタンス グループを作成します。

    gcloud compute instance-groups managed create haproxy \
      --base-instance-name=haproxy \
      --template=haproxy \
      --size=2 \
      --zone=us-central1-f
    

フロントエンド アプリケーション

この例のフロントエンド アプリケーションは、HAProxy ロードバランサを介してバックエンドからの JSON 出力を消費し、それを HTML としてレンダリングします。

フロントエンド アプリケーションを実行しているインスタンスは、それぞれ公開 IP アドレスと非公開 IP アドレスを持っています。それらのインスタンスは、インターネットからリクエストを受信し、プライベート IP アドレスを使用して HAProxy サーバーに対してリクエストを実行します。サンプル アプリケーションのソースコードは、GitHub で入手できます。

バックエンドへのフロントエンドの接続

フロントエンド アプリケーションは、ランタイム フラグとしてバックエンドの場所を受け取ります。

gceme -frontend=true -backend-service=http://BACKEND_SERVICE_ADDRESS:PORT

フロントエンド サーバーも Consul クラスタのメンバーなので、DNS を使用して HAProxy サービスを簡単に検出することができ、フロントエンド プロセスが起動するときにそのサービス名を値として backend-service フラグに提供できます。

gceme -frontend=true -backend-service=http://us-central1-f.haproxy-internal.service.consul:8080

DNS と Dnsmasq を使用した Consul サービス ディスカバリ

Packer スクリプトは、フロントエンド サーバー上で dnsmasq をインストールします。/etc/resolv.conf は、ネームサーバーとして 127.0.0.1 を含めるように変更されるので、dnsmasq が .consul TLD に対するクエリを解決できます。次に consul-template が、HAProxy サービス内のホスト名とロードバランサのアドレスが含まれる /etc/hosts.consul という名前の 2 番目のホストファイルをレンダリングします。/etc/hosts.consul を生成するための consul-template ファイルは次のとおりです。

&lcub;{range service "$zone.haproxy-internal"&rcub;}
&lcub;{.Address}} $zone.&lcub;{.Name}} $zone.&lcub;{.Name}}.service.consul&lcub;{end}}

consul-template は、HAProxy サーバーがインスタンス グループで追加または削除されるたびにこのファイルをレンダリングし、dnsmasq サービスを再起動します。レンダリングされた /etc/hosts.consul は次のようになります。

10.240.0.8 us-central1-f.haproxy-internal us-central1-f.haproxy-internal.service.consul
10.240.0.9 us-central1-f.haproxy-internal us-central1-f.haproxy-internal.service.consul

最後に、dnsmasq が追加のホストファイルを使用するように設定され、フロントエンド アプリケーションからの haproxy-internal.service.consul に対する解決リクエストに応答できるようになります。インスタンス設定の詳細は、images/frontend ディレクトリにあります。

ハンズオン: フロントエンド アプリケーションの起動

このハンズオン セクションでは、Packer を使用してフロントエンド サーバーの VM イメージをビルドし、次に公開 IP アドレスを使用して単一のフロントエンド インスタンスを起動します。

  1. tool インスタンスで、フロントエンド イメージ ファイルが含まれているディレクトリに変更します。

    cd ~/compute-internal-loadbalancer/images/frontend
    
  2. 次のコマンドを実行して、フロントエンド サーバーへの HTTP アクセスを許可するファイアウォール ルールを作成します。

    gcloud compute firewall-rules create frontend-http \
        --source-ranges=0.0.0.0/0 \
        --target-tags=frontend-http \
        --allow=TCP:80
    
  3. packer を使用して、Compute Engine インスタンス イメージをビルドします。以下のコマンドをそのまま使用します。

    packer build -var project_id=${PROJECT_ID} packer.json
    
  4. 次のような、作成されたイメージの ID をコピーします。

    ==> Builds finished. The artifacts of successful builds are:
    --> googlecompute: A disk image was created: frontend-1450847630
    

    この ID をメモします。次の手順やこのソリューションで後で必要になります。

  5. 公開 IP アドレスとポート 80 を開く frontend-http タグを使用して、フロントエンド インスタンスを作成します。YOUR_FRONTEND_IMAGE_ID は前の手順の出力に置き換えてください

    gcloud compute instances create frontend \
        --metadata="^|^consul_servers=consul-1,consul-2,consul-3" \
        --zone=us-central1-f \
        --tags=frontend-http \
        --image=YOUR_FRONTEND_IMAGE_ID
    
  6. 作成オペレーションが成功すると、インスタンスの詳細が出力されます。出力は次の例のようになります。

    NAME     ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP   STATUS
    frontend us-central1-f n1-standard-1             10.240.0.10 104.197.14.97 RUNNING
    
  7. ターミナル ウィンドウから、EXTERNAL_IP の値をコピーし、ブラウザで開いてフロントエンド アプリケーションを表示します。

  8. ページを数回更新すると、別のバックエンドがリクエストを処理していることがわかります。

自動スケーリングと失敗の処理

作成した HAProxy イメージを使用してインスタンスを起動すると、インスタンスは自身を Consul に自動的に登録するので、フロントエンド インスタンスが DNS を介してインスタンスを検出できるようになります。同様に、HAProxy インスタンスが失敗した場合、Consul が失敗を検出して、consul-template で dnsmasq を再起動することでフロントエンドに通知します。結果として、リクエストが失敗したインスタンスを経由してルーティングされなくなります。これらのインスタンスのブートストラップは検出可能であり、安全に失敗するので、Compute Engine Autoscaler を追加して、使用状況に応じて負荷分散の使用量を自動的に追加または削除するのは単純なタスクです。

ハンズオン: HAProxy ロードバランサの失敗のシミュレーション

前に作成した HAProxy インスタンス グループには、グループ内に 2 つのインスタンスがあります。次のように、グループのサイズを 1 インスタンスに変更し、いずれかのインスタンスの失敗をシミュレートすることができます。

gcloud compute instance-groups managed resize haproxy --size=1

インスタンス グループ マネージャがランダムにインスタンスを選択してシャットダウンします。Consul からの失敗を示す通知が tool ターミナルに表示されます。

2015/12/27 20:00:43 [INFO] memberlist: Suspect haproxy-gg94 has failed, no acks received
2015/12/27 20:00:44 [INFO] serf: EventMemberFailed: haproxy-gg94 10.240.0.8

失敗したインスタンスは、サービスのメンバーではなくなり、フロントエンド サーバーはそのサービスを除外するように更新されます。

consul members を実行して、終了した HAProxy インスタンスを表示できます。次のような出力が表示されます。

$ consul members
Node          Address           Status  Type    Build  Protocol  DC
backend-lfwe  10.240.0.6:8301   alive   client  0.6.0  2         dc1
backend-mq5c  10.240.0.7:8301   alive   client  0.6.0  2         dc1
consul-1      10.240.0.5:8301   alive   server  0.6.0  2         dc1
consul-2      10.240.0.3:8301   alive   server  0.6.0  2         dc1
consul-3      10.240.0.4:8301   alive   server  0.6.0  2         dc1
frontend      10.240.0.10:8301  alive   client  0.6.0  2         dc1
haproxy-gg94  10.240.0.8:8301   failed  client  0.6.0  2         dc1
haproxy-tm64  10.240.0.9:8301   alive   client  0.6.0  2         dc1
tool          10.240.0.2:8301   alive   client  0.6.0  2         dc1

ハンズオン: HAProxy 自動スケーリングを有効にする

既存のインスタンス グループの自動スケーリングを有効にすることができます。オートスケーラーは、CPU 使用率、カスタム指標、またはその両方を基にしたスケーリングをサポートします。この例では、集計された HAProxy サーバーの CPU 使用率が 70% を超えた場合またはネットワーク入力レートが 1 ギガビット / 秒を超えた場合に容量を追加するようにオートスケーラーを設定します。

次のコマンドを使用して、HAProxy サーバー グループの自動スケーリングを有効にします。

gcloud compute instance-groups managed set-autoscaling haproxy \
  --zone=us-central1-f \
  --min-num-replicas=2 \
  --max-num-replicas=8 \
  --scale-based-on-cpu \
  --target-cpu-utilization=.7 \
  --custom-metric-utilization="metric=compute.googleapis.com/instance/network/received_bytes_count,utilization-target=1000000000,utilization-target-type=DELTA_PER_SECOND"

Cloud Deployment Manager を使用したマルチゾーンのデプロイ

Google Cloud Deployment Manager は、Cloud Platform リソースの作成と管理を自動化することで、ユーザー向けのサービスとアプリケーションの開発に専念できるようにするインフラストラクチャ管理サービスです。Cloud Deployment Manager を使用すると、わずかな手順を踏むだけで、複数の可用性ゾーンでソリューション全体を実行できます。

  1. tool インスタンスから ~/compute-internal-loadbalancer/dm/config.yaml ファイルを編集します。前の手順で Packer を使用して作成したイメージのイメージ ID を挿入します。

    ...
    haproxy_image: REPLACE_WITH_YOUR_IMAGE_ID
    backend_image: REPLACE_WITH_YOUR_IMAGE_ID
    frontend_image: REPLACE_WITH_YOUR_IMAGE_ID
    consul_image: REPLACE_WITH_YOUR_IMAGE_ID
    ...
    

    イメージのリストが手元にない場合は、tool インスタンスに接続されたターミナル ウィンドウから gcloud compute images list を実行します。

  2. gcloud を使用してアーキテクチャ全体をデプロイします。

    gcloud deployment-manager deployments create internal-lb-demo \
        --config=$HOME/compute-internal-loadbalancer/dm/config.yaml
    
  3. デプロイが処理されているときに、Cloud Deployment Manager コンソール ページを表示して進行状況を追跡します。

  4. デプロイが完了したら、HTTP ロードバランサ コンソール ページを開き、[受信トラフィック] 列で IP アドレスをクリックしてフロントエンドにアクセスし、アプリケーションが稼働していることを確認します。デプロイが完了してからロードバランサがリクエストの処理を開始するまでに数分かかることがあります。

クリーンアップ

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

プロジェクトの削除

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

プロジェクトを削除する手順は次のとおりです。

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

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

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

インスタンス グループの削除

Compute Engine インスタンス グループを削除するには次のようにします。

インスタンスを削除する

Compute Engine インスタンスを削除する手順は次のとおりです。

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

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

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

ディスクの削除

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

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

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

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

イメージの削除

Compute Engine ディスク イメージを削除するには次のようにします。

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

    [イメージ] ページに移動

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

Cloud Deployment Manager デプロイの削除

デプロイを削除するには、次のコマンドを実行します。

gcloud deployment-manager deployments delete internal-lb-demo

次のステップ

Compute Engine インスタンス上で HAProxy と Consul を使用し、非公開ネットワークで実行されるスケーラビリティと復元性のある内部負荷分散ソリューションを作成する方法を理解しました。さらに、サービス ディスカバリが負荷分散階層およびそのクライアントの両方の登録と検出を有効にする方法も学びました。

データベース サーバーや Key-Value ストアなどの異なるバックエンド アプリケーションをサポートするようにこのソリューションを拡張または変更できます。

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

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

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

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