初めまして、最近お客様にフォースがないアピールをするためにトルーパーに変身したg-yamaです。
今後トルーパーと名乗ります。
(画像欠けているけど)

GAE上で個人ブログを構築し運用しているのですが、GCPのベータ版機能：Serverless NEG（Network Endpoint Group)を使ってみたくなり、ブログに適用する前に検証してみたので、記事にしました。

運営しているブログ

ヤマログというブログを運営しています。
https://yamavlog.com/

GCPで触ったことなどの備忘録を書いていますが、たまにガジェットネタなんかも書いています。
※GAEでWordpressを構築する方法や今回のServerless NEGに関する記事もこちらに書いています。

Serverless NEG（Network Endpoint Group)って何？？

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

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

マルチリージョン構成で構築・運用が可能
使えなかったGCPの機能が利用可能

となります。

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

WAF(Cloud Armor)
CDN(Cloud CDN)

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

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

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

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

注意事項

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

事前準備

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

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

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

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

作業アカウントの権限確認

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

Network Admin
Compute Instance Admin
Security Admin

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

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

今回はバックエンドアプリケーションをGAEにするので、GAE SEにアプリケーションを事前にデプロイしておきます。
アプリケーションは何でも構いません。
※Hello Word!と返すだけのプログラムでもOKです。

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

静的IPアドレスの生成

**Serverless NEGはロードバランサと連携(実態はロードバランサのエンドポイント機能)**します。
このため、ロードバランサのフロントエンド(forwarding rule)用の静的IPアドレスが必要となるので作成しておきます。

静的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のインストール

Cloud SDKで設定するのでbeta componentsをインストールします。

gcloud components install beta

Serverless NEG作成

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

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

Severless NEG作成結果の確認

下記コマンドを実行し確認します。
リストに作成したServerless NEGが表示されていればOKです。

gcloud beta compute network-endpoint-groups list

NAME         LOCATION         ENDPOINT_TYPE  SIZE
xxxxxxx-neg  asia-northeast2  SERVERLESS     0

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

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

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

その他オプションについては、下記公式リファレンスをご覧下さい。
gcloud beta compute network-endpoint-groups create

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

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

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

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

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

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

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

NAME                     BACKENDS  PROTOCOL
xxxxxxx-backend-service            HTTP

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

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

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

gcloud beta compute backend-services list

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

ロードバランサの設定

コマンドを順次実行し、ロードバランサの設定を進めていきます。
ロードバランサの設定反映は多少時間がかかります。

ロードバランサの作成

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=【前述の手順で作成した静的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アドレスIPアドレス】    TCP          xxxxxxx-http-proxy

動作確認

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

ブラウザのURL入力欄に、**ロードバランサ・フロントエンドのIPアドレス(【前述の手順で作成した静的IPアドレス】)**を入力し実行します。

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

後片付け

ロードバランサの削除

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

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

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

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

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

まとめ

構築後に色々試してみたのですが、全く問題なかったので個人ブログに早速導入しました。
現在の構成はこんな感じです。
※会社の諸先輩方、アーキテクト図変じゃね？というご指摘はお手柔らかにお願いします。

個人ブログの方は常時SSL化しているので、当記事と若干設定内容が異なります。差分設定などこちらの記事にまとめました。

Cloud ArmorやCloud CDNとの連携もバッチリできます。
Cloud IAPは連携させるとエラーが出ちゃいました。
(確認中ですが、Serverless NEGとはまだ連携出来なそう??)

GCPのサーバーレスサービスの課題が、Serverless NEGでかなり解消されるんじゃないかなと思います。

またマルチリージョン化も出来るようになるので、リージョンレベルでの負荷分散や障害対策にもServerless NEGが活躍しそうです。

GAが待ち遠しいですね。

参考情報