スポンサーリンク

Serverless NEG(Network Endpoint Group)を設定し、ロードバランサとGAEと連携する

この記事は約11分で読めます。
スポンサーリンク

What is ServerlessNEG(Network Endpoint Group)?

端的に言えば、GCPのロードバランサのエンドポイントにサーバーレスサービス(GAE,Cloud Run,Cloud Functions)を指定できる機能です。

これにより、GCPのサーバーレスサービスが、

  1. マルチリージョン構成で環境構築・運用が可能
  2. 使えなかったGCPの機能が利用可能
  3. URIにより、バックエンドサービスを指定できる

となります。

2.について個人的に特に注目しており、

  • WAF(Cloud Armor)
  • CDN(Cloud CDN)

が、利用できるようになる点が非常に嬉しいです。

これらはロードバランサとの組合せでの利用が前提の機能なので、GCPのサーバーレスサービスでは利用が出来ず泣き所だったのですが、このデメリットがようやく解消される事になります。

また、GCPのロードバランサとネットワークは他のパブリッククラウドの追随を許さない性能を誇るので、1.についても相当な物が期待出来るでしょう。

ServerlessNEGの詳細については、以下リンク記事をご覧頂けたらと思います。

Serverless network endpoint groups overview  |  Load Balancing

前振りが長くなりましたが、早速試してみることにします。

スポンサーリンク

注意事項

当記事執筆時点ではServerless NEGはbeta版となっており、GCPのSLAは保証されません、ご利用される際はご注意下さい。

GAになりました。

スポンサーリンク

事前準備

Cloud SDKの最新化と認証、config設定

手順は割愛させて頂きますが、Serverless NEGを設定する前に

  • Cloud SDKの最新化
  • Cloud SDKの認証
  • config設定(作業プロジェクトや作業アカウントの指定)

は事前に行っておく必要があります。

GCPサービスの権限確認

作業アカウントに、下記IAMロールが付与されているかご確認下さい。

  • Network Admin
  • Compute Instance Admin
  • Security Admin

プロジェクト管理者/編集者のIAMロールが付与されているアカウントであれば大丈夫だと思います。

Setting up a load balancer with Cloud Run (fully managed), App Engine, or Cloud Functions

GAEアプリケーションのデプロイ

今回はバックエンドアプリケーションをGAEにするので、GAE SEにアプリケーションを事前にデプロイしておきます。

アプリケーションは何でも構いません。

※Hello Word!と返すだけのプログラムでもOKです。

私はテスト用のWordpressをデプロイし試す事にしました。

GAEでWordpressを構築する方法について

以下の記事をご覧下さい。

スポンサーリンク

静的IPアドレスの生成

Serverless NEGはロードバランサと連携(実態はロードバランサのエンドポイント機能)します。

このため、ロードバランサのフロントエンド(forwarding rule)用の静的IPアドレスが必要となるので作成しておきます。

※GCPで推奨されています。

静的IPアドレスの生成

gcloud compute addresses create 【静的IPアドレス論理名】 
     --ip-version=IPV4 
     --global

生成した静的IPアドレスの確認

gcloud compute addresses describe 【作成した静的IPアドレス論理名】 
    --format="get(address)" 
    --global

実行するとIPアドレスが表示されます。

後ほど利用するので控えておきます

Cloud SDK beta版 componentsのインストール

GAになりましたので当手順は不要です。

Serverless NEGは当記事執筆時点でbeta版機能として提供されているので、Cloud Consoleから設定する事は出来ません。

Cloud SDKで設定が可能ですが、設定にあたりbeta componentsをインストールする必要があります。

下記コマンドを実行し、インストールします。

gcloud components install beta
スポンサーリンク

Serverless NEG作成

下記コマンドを実行し、Serverless NEGを作成します。

gcloud compute network-endpoint-groups create 【ServerlessNEG論理名】 
     --region=【リージョン名】 
     --network-endpoint-type=SERVERLESS  
     --app-engine-app 
     --app-engine-service=default

補足1:コマンドオプションについて

今回指定したコマンドオプションは次の通りです。

オプション説明
regionServerless NEGを作成するリージョン名。
バックエンドアプリケーションと同じリージョンにする必要があります。
network-end-point-typeNEGの種別
Serverless NEGにする場合は値をSERVERLESSにします。
app-engine-appデフォルトルーティングでGAEを有効にする。
app-engine-serviceServerless NEGに追加するGAEのサービス名。
指定が無ければ省略可。

その他オプションについては、下記公式リファレンスをご確認下さい。

gcloud beta compute network-endpoint-groups create
スポンサーリンク

補足2:マルチリージョン構成にする場合

マルチリージョン構成にする場合はリージョンごとのServerless NEGを作成し、バックエンドサービスに作成したServerless NEGを全て追加すればOKです。

※バックエンドサービスへの追加は手順5.5.2を参照下さい。

Severless NEG作成結果の確認

下記コマンドを実行し確認します。

リストに作成したServerless NEGが表示されていればOKです。

gcloud compute network-endpoint-groups list

NAME         LOCATION         ENDPOINT_TYPE  SIZE
xxxxxxx-neg  asia-northeast2  SERVERLESS     0
スポンサーリンク

ロードバランサ・バックエンドサービスの設定

コマンドを順次実行し、バックエンドサービスの設定を進めていきます。

バックエンドサービスの作成

gcloud compute backend-services create 【バックエンドサービス論理名】 --global

NAME                     BACKENDS  PROTOCOL
xxxxxxx-backend-service            HTTP

バックエンドサービスにServerless NEGを追加

gcloud compute backend-services add-backend 【作成したバックエンドサービス論理名】 
     --global 
     --network-endpoint-group=【作成したServerlesNEG論理名】 
     --network-endpoint-group-region=【リージョン名(ServerlessNEGと同じリージョンにする必要あり)】

バックエンドサービスの確認

gcloud compute backend-services list

NAME                     BACKENDS                                           PROTOCOL  LOAD_BALANCING_SCHEME  HEALTH_CHECKS
xxxxxxx-backend-service  【リージョン名】/networkEndpointGroups/xxxxxxx-neg       HTTP      EXTERNAL
スポンサーリンク

ロードバランサの設定

コマンドを順次実行し、ロードバランサの設定を進めていきます。

※URLマップ=ロードバランサと同義です。

※設定反映は多少時間がかかります、ご注意下さい。

ロードバランサの作成

gcloud compute url-maps create 【ロードバランサの論理名】 
     --default-service 【作成したバックエンドサービス論理名】

NAME             DEFAULT_SERVICE
xxxxxxx-url-map  backendServices/xxxxxxx-backend-service

ターゲットhttpプロキシを作成しロードバランサに追加

gcloud compute target-http-proxies create 【ターゲットhttpプロキシ論理名】 
     --url-map=【作成したロードバランサの論理名】

NAME                URL_MAP
xxxxxxx-http-proxy  xxxxxxx-url-map

フロントエンド(forwarding rule)をロードバランサに追加

gcloud compute forwarding-rules create 【フロントエンド論理名】 
     --address=【3.4.2 生成した静的IPアドレスの確認で控えたIPアドレスを指定】 
     --target-http-proxy=【作成したターゲットhttpプロキシ論理名】 
     --global 
     --ports=80

ロードバランサ・フロントエンドの確認

gcloud compute forwarding-rules list
 
NAME                       REGION  IP_ADDRESS     IP_PROTOCOL  TARGET
xxxxxxx-http-content-rule          【IPアドレス】      TCP          xxxxxxx-http-proxy
スポンサーリンク

動作確認

ロードバランサにリクエストしてみます。

ブラウザのURL入力欄に、ロードバランサ・フロントエンドのIPアドレス(【3.4.2 生成した静的IPアドレスの確認で控えたIPアドレス】)を入力し実行します。

ロードバランサ経由でGEAに接続し、Wordpressの画面が表示されました。

スポンサーリンク

後片付け

ロードバランサの削除

[Cloud Consoleメニュー]->[ネットワークサービス]->[負荷分散]から、今回作成したURLマップを削除します。

Serverless NEGと静的IPアドレスの削除

下記コマンドを実行します。

# Serverless NEGの削除
gcloud compute network-endpoint-groups delete 【作成したServerlessNEG論理名】 --region=【リージョン名】

# 静的IPアドレスの削除
gcloud compute addresses delete 【作成した静的IPアドレス論理名】 --global
スポンサーリンク

まとめ

  • WAFが使えなかったので、CloudRunに移行しApacheで対応しようと思っていたのでServerless NEGの情報を聞いた時は歓喜しました。
  • beta版ですが個人で使う分には全く問題ないので、早速当ブログに反映してみようと思います。
  • スパイクアクセスへの対処が必要なシステム(ゲームなど)にうってつけのシステム構成が組めると思います、GAが待ち遠しいですね。
スポンサーリンク

参考情報

GCP公式Doc:Setting up serverless NEGs

GCP公式Doc:gcloud beta compute network-endpoint-groups create

スポンサーリンク
GCP
ヤマログ
タイトルとURLをコピーしました