LoadBalancing on LIFELOG

Cookieに backend-a と書いても backend-a2 へ届く。ALBのセッションアフィニティを実測した

Sun, 13 Sep 2026 00:00:00 +0900

概要
#

ログイン状態をサーバ側のメモリに置いている。ロードバランサが毎回違うバックエンドへ振ると、数リクエストごとにログアウトする。同じクライアントを同じバックエンドへ送りたい。

Google Cloud のロードバランサには session_affinity があります。リージョン外部ALBで選べるのは6種類です。

NONE / CLIENT_IP / GENERATED_COOKIE / HEADER_FIELD / HTTP_COOKIE / STRONG_COOKIE_AFFINITY

この記事で比べるのは Cookie を使う2つです。違いは「誰が発行するか」ではありません。

GENERATED_COOKIE はLBが発行した Cookie を使います。一方 HTTP_COOKIE が使うのは、名前を指定した Cookie の値です。その名前の Cookie が無ければLBが生成します。

後者を使うとき、こう書きたくなります。

self.send_header("Set-Cookie", "ROUTE=backend-a; Path=/")

これはバックエンドの指定になりません。 固定はされますが、backend-a という綴りがバックエンド backend-a を指すわけではありません。実測では、ROUTE=backend-a を送ったリクエストが10回とも backend-a2 に届きました。

あわせて、固定が外れる条件と、効いていることをどこで確かめられるかも測ります。後者は予想と違いました。

Google Cloud のロードバランサを触ったことがある人向けです。構成の作り方はリージョンALBの回で扱っており、ここではアフィニティの差分だけを見ます。gRPC やステートフルなセッション管理の設計は扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.44.0
Google Cloud SDK 562.0.0、curl 7.81.0
初回検証は2026年9月13日、再検証は2026年9月19日、いずれも asia-northeast1

初回・再検証は別デプロイです。AFFLOG の Cookie 関連の記録（6件のログなど）は9月13日、request_count・backend_request_count の94件／30件を含む指標系の集計は9月19日の再検証結果です。断りのない数値は、それぞれの取得時点のデプロイでの集計としてください。Cookie の対応だけは、作り直す前と後の2回ぶんを並べています。

Cloud Armorで送信元IPを拒否したら、リクエストはバックエンドに届かなかった

Fri, 11 Sep 2026 00:00:03 +0900

概要
#

Cloud Armor で送信元を絞ったとき、拒否されたリクエストはどこまで来ているのか。 バックエンドのログに出ないのは「届いていないから」なのか、「出していないだけ」なのか。

見えないものを「無い」と決めるのは危ないので、クエリ文字列に識別子を入れたリクエストを送って確かめます。同じ1回のリクエストを、クライアント・LBのログ・バックエンドのログの3か所で追えます。

あわせて、プレビューの動作も確かめます。ルールを有効にする前に「もし有効だったら何が止まるか」を見る仕組みです。

プレビューにしたルールは判定するだけで、実際には止めません。判定はログと専用メトリクスに残ります。

3つの状態で、応答・ログ・メトリクスの見え方を並べます。

Google Cloud のロードバランサを触ったことがある人向けです。構成の作り方は前々回で扱っており、ここでは Armor の差分だけを見ます。WAF ルールやレート制限は扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.0
Google Cloud SDK 562.0.0

使用するコードは Advanced-Examples/09-regional-alb-cloud-armor です。

cd Advanced-Examples/09-regional-alb-cloud-armor
cp terraform.tfvars.example terraform.tfvars
# project_id / allowed_src_ips（自分のグローバルIPを /32 で）/ iap_member を書く
terraform init
terraform apply
terraform apply   # 2回目。理由は後述

create_deny_client = true にすると、許可リストに載っていない送信元として使える検証用 VM も作られます。access_config {} でエフェメラルな外部IPが付くので、そのIPで出ていきます。

draining=300のままNEGからバックエンドを外したら、gcloudが320秒終わらなかった

Fri, 11 Sep 2026 00:00:02 +0900

概要
#

ロードバランサの設定値は、既定のままでも動きます。動くので、何秒で効くのかを知らないまま運用に入りがちです。

デプロイの手順を書いていて、次のような形にすることがあります。

# バックエンドを1台外す
gcloud compute network-endpoint-groups update NEG --remove-endpoint ...
# 外れたので入れ替える
...

このコマンド、Provider の既定値（draining=300秒）のままだと5分以上終わりませんでした。 しかも新しいリクエストは、その前に届かなくなっています。

detachNetworkEndpoints は Operation を返す非同期APIで、gcloud はその完了を待ってから戻ります。 以下で「5分」と書くのは、この完了待ちを含んだ時間です。HTTP応答そのものの速さは測っていません。

対象はリージョン外部 Application Load Balancer です。検出にかかる時間と、バックエンド削除の挙動を実測します。

Google Cloud のロードバランサを触ったことがある人向けです。構成の作り方は前の記事で扱っており、ここでは時間だけを見ます。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.0
Google Cloud SDK 562.0.0

使用するコードは Advanced-Examples/08-regional-external-alb-neg です。:81 はゾーンaの2台（backend-a / backend-a2）、:82 はゾーンcの1台（backend-b）に向きます。

proxy-onlyサブネットを塞ぐと、リージョンALBはHEALTHYのまま504を返した

Fri, 11 Sep 2026 00:00:01 +0900

概要
#

ロードバランサのトラブルは「ヘルスチェックが赤い」から入ることが多く、そこを直せば通ります。リージョン外部 Application Load Balancer には、緑のまま通らない入り方があります。

バックエンドから見ると、同じロードバランサからの通信がヘルスチェックと実トラフィックの2つに分かれています。片方だけを塞ぐと、こうなります。

今回測ったのは、IPv4のVMを GCE_VM_IP_PORT 型のゾーンNEGに登録した構成です。ハイブリッドNEGやバックエンドバケットでは経路が変わるので、そのまま当てはめられません。

何が来るか	送信元
ヘルスチェック	`35.191.0.0/16`
実トラフィック	proxy-only サブネットの範囲

ファイアウォールを片方しか開けていないと、片方だけ通ります。ヘルスチェックだけ開けていれば、バックエンドは HEALTHY のまま、クライアントには 504 が返ります。

ファイアウォールを1本だけ外す対照実験で、これを実際に起こします。

Google Cloud のロードバランサを触ったことがある人向けです。ALB の種類の選び方や、Cloud Armor・セッションアフィニティは扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.0
Google Cloud SDK 562.0.0

使用するコードは Advanced-Examples/08-regional-external-alb-neg です。

cd Advanced-Examples/08-regional-external-alb-neg
cp terraform.tfvars.example terraform.tfvars   # project_id と iap_member を書き換える
terraform init
terraform apply

Apply complete! Resources: 33 added, 0 changed, 0 destroyed.

Outputs:
vip = "34.146.203.171"

バックエンドVMに外部IPはありません。インターネットからの入口はロードバランサだけです。

ドメイン認証がFAILEDになった9分後にAUTHORIZEDへ戻り、証明書はACTIVEになった

Sun, 06 Sep 2026 00:00:00 +0900

概要
#

リージョン外部 ALB で、公開の Google マネージド証明書を使うとします。選べるのは Certificate Manager の DNS 認証です。

Compute Engine のマネージド証明書は使えません。自己管理証明書なら別途使えます。

Compute Engine Google-managed SSL certificates aren’t supported for regional external Application Load Balancers, regional internal Application Load Balancers, or cross-region internal Application Load Balancers.

残るのは Certificate Manager です。認証方式は DNS認証とLB認証の2つで、どちらを選ぶかで証明書を用意できるタイミングが変わります。

ただしリージョン証明書で使えるのは DNS 認証だけです。 この記事では、比較のためにグローバル外部ALBで LB 認証も試します。

両方を同じプロジェクトに作り、発行までを実測しました。29分の時点では両方 FAILED でした。

対象読者
#

Terraform で Google Cloud のロードバランサを作ったことがある
terraform apply の出力を読める

扱わないもの
#

Terraform と Google Cloud の入門
自己管理証明書、private PKI
Cloud Armor、URL マップの詳細

証明書の発行と、ロードバランサへの取り付けに絞ります。

TerraformでGKEのスタンドアロンNEGを消したらLBのバックエンドが戻らなかった話

Thu, 03 Sep 2026 00:00:00 +0900

概要
#

GKEのPodをInternal HTTP LB（NEG）でポート別に振り分けるでは、スタンドアロンNEGを作るところまでを扱いました。しかし運用で怖いのはその先です。「Serviceを間違って消してしまった」「クラスタを作り直した」というとき、ロードバランサは自動で復旧してくれるのでしょうか。

NEGはGKEが作り、LBのバックエンドはTerraformが管理します。作る主体が違うため、片方だけが変わると両者の認識がずれます。障害が起きてから手探りで復旧手順を探すのは避けたい。そこで、実際に壊して直るまでを先に確認しておきます。

対象読者は、GKEでNEGを使ったLB構成を組んだことがある人です。NEGそのものの入門は扱いません。

Internal LBは扱いません（前掲の記事で扱っています）。Cloud Armor、マネージドSSL証明書、Shared VPCも扱いません。

検証すること
#

正常系: 外部LB経由でPodへ到達できること
検証1: Serviceを削除するとどうなるか。再作成すればLBのバックエンドは自動で戻るか
検証2: LBを残したままGKEクラスタを作り直すとどうなるか

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

使用するTerraformコード
#

Advanced-Examples/18-gke-standalone-neg-recovery

今回の構成
#

リージョナル・2ゾーンのプライベートGKEクラスタと、グローバル外部Application LBです。NEGはゾーンごとに作られるため、複数ゾーンにしています。

TerraformでGKEのPodをInternal HTTP LB（NEG）でポート別に振り分けてみた

Tue, 01 Sep 2026 00:00:00 +0900

概要
#

GKEプライベートクラスタと踏み台を作った後、複数のアプリケーションをクラスタに同居させたくなる場面があります。リクエストをアプリごとに振り分けたい、という場面です。GKEのServiceだけではVPC内部からの経路が用意されません。Ingressを使わない場合、Podへの入り口をどう作るかが課題になります。

Internal HTTP LB（INTERNAL_MANAGED）は、GKEのPodをNetwork Endpoint Group（NEG）というバックエンドの形で直接受け取れます。Terraformが手動で作るNEGとは異なる点です。GKEのServiceにcloud.google.com/negというアノテーションを付けるだけです。GKEコントローラがNEGを自動的に作成します。

Terraformの基本操作と、前回のGKEプライベートクラスタ＋踏み台構成は前提としています。

Session Affinity（Cookie）は本記事では扱いません。外部ALB向けの構成例がterraform-gcp-examplesの10-regional-alb-session-affinityにあります（Terraformコードのみ）。Ingress（GKEのL7 LBコントローラ）や外部公開も扱いません。

検証すること
#

GKEのServiceアノテーションから、Network Endpoint Group（NEG）が自動作成されること
Internal HTTP LBで、共有VIPの3つのポート（:81/:82/:83）を、それぞれ異なるバックエンドへ振り分けられること
踏み台からVIPの3ポートへ実際に接続し、意図したバックエンドが返ること（LB作成の確認とは別）

前提環境
#

Google Cloud CLI、Terraform、Docker
Billingが有効な検証用Google Cloud Project
GKE、Compute Engine、IAMを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.3、google 7.46.0

今回の構成
#

GKEのServiceにcloud.google.com/negアノテーションを付けると、GKEコントローラはクラスタが配置されているゾーンごとにNEGを作成します。この構成では3ゾーンにノードプールを配置しているので、1つのServiceにつき3つのNEG（ゾーンごと1つ）が対応します。

LoadBalancing on LIFELOG

Cookieに backend-a と書いても backend-a2 へ届く。ALBのセッションアフィニティを実測した

概要 #

検証環境 #

Cloud Armorで送信元IPを拒否したら、リクエストはバックエンドに届かなかった

概要 #

検証環境 #

draining=300のままNEGからバックエンドを外したら、gcloudが320秒終わらなかった

概要 #

検証環境 #

proxy-onlyサブネットを塞ぐと、リージョンALBはHEALTHYのまま504を返した

概要 #

検証環境 #

ドメイン認証がFAILEDになった9分後にAUTHORIZEDへ戻り、証明書はACTIVEになった

概要 #

対象読者 #

扱わないもの #

TerraformでGKEのスタンドアロンNEGを消したらLBのバックエンドが戻らなかった話

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

今回の構成 #

TerraformでGKEのPodをInternal HTTP LB（NEG）でポート別に振り分けてみた

概要 #

検証すること #

前提環境 #

今回の構成 #

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

対象読者
#

扱わないもの
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

今回の構成
#

概要
#

検証すること
#

前提環境
#

今回の構成
#