GCP PCDのサンプル問題（本番形式・解説付き）

解説

カーネルモジュールへの依存とライセンス持ち込み(BYOL)は Compute Engine を選ぶ合図であり、スケールと自己修復が要るという要件にはマネージドインスタンスグループ(MIG)のオートスケーラーと自動修復(autohealing)が対応する。Cloud Run services はコンテナのサーバーレス実行でありカーネルモジュールの読み込みを前提にできない。GKE Autopilot はノード管理を任せたい場合の選択肢で、OS・カーネルへの依存という要件には応えられない。Cloud Run jobs はリクエストを受けず実行して終了するバッチ型で、常駐する解析基盤の要件に合わない。

解説

Cloud Run のローカルディスクはインメモリ(tmpfs)扱いでインスタンス終了時に消えるため、セッションは Memorystore などの外部ストアへ外出しするのがリファクタリングの正解である。セッションアフィニティはベストエフォートで、スケールインやリビジョンの入れ替えが起きれば別のインスタンスに回されるため状態の保存手段にはならない。ポートは環境変数 PORT で待ち受けるのがコンテナの契約であり、固定値への変更は契約に反する。リクエストタイムアウトの引き上げは1リクエストの処理時間の上限を変えるだけで、インスタンスをまたぐ状態の消失は解決しない。

解説

レイテンシの設計原則はユーザーに近いリージョンで受けデータを計算の近くに置くことであり、大陸をまたぐ往復は数十ミリ秒から100ミリ秒超になるため、1リクエストで複数回クエリを投げる設計では致命的に遅くなる。同一リージョン内のゾーン間往復はおおむね1ミリ秒未満から数ミリ秒で、この規模の遅延の説明にならない。マルチリージョン化は要件にない限りコストと書き込み遅延が跳ね上がる方向であり、ここでの原因はリージョンの不一致そのものである。区分をマルチリージョナルへ引き上げることは可用性の話であり、往復の距離が縮むわけではない。

解説

UDP を分散したい、クライアントの実 IP をアプリケーションで見たい、という要件はパススルーネットワークロードバランサであり、外部の機器から受けるので外部パススルーネットワークロードバランサになる。アプリケーションロードバランサはプロキシであるため送信元は Google のプロキシ IP になり、実クライアント IP は X-Forwarded-For ヘッダーで渡される。グローバル外部アプリケーションロードバランサとリージョン外部アプリケーションロードバランサはいずれも L7(HTTP/HTTPS)で、UDP をそのまま通す用途に当たらない。内部アプリケーションロードバランサは VPC 内の HTTP 振り分け用である。

解説

GENERATED_COOKIE はロードバランサが発行する Cookie を鍵にするため HTTP(S) で最も一般的で、IP が変わっても維持される点がこの場面の決め手になる。CLIENT_IP は単純だが NAT 配下の多数ユーザーが同一バックエンドに偏るという弱点が要件と正面から衝突する。HEADER_FIELD はマイクロサービスで独自のキーを使う場面のもので、携帯回線の利用者が送るヘッダーを前提にできない。HTTP_COOKIE は既存のセッション Cookie に合わせる場合の選択で、アプリケーション側に Cookie を用意させる必要がある。