Blog

8 月 1 - 2 日（2 Days）パシフィコ横浜にて開催された Google Cloud Next Tokyo'24 に現地参加してきました。基調講演では主に生成 AI の最新動向や将来性について、実際の活用事例や今後の展望、使用していく上での課題や解決策に関する話題がメインでした。今回のブログでは、基調講演をはじめ、いくつか気になったセッションに関してまとめようと思います。

マルチクラウド環境において、AWS から GCP のマネージドサービスに対し、OIDC によるキーレス連携を実現する GCP Workload Identity Federation の仕組みについて紹介します。多くのクラウドサービスでは、API キーや Credential（AWS アクセスキーや GSA アカウントキー）を発行することで、各種マネージドサービスにアクセスすることが可能です。しかし、永続的に使用できてしまう認証情報は、キーローテーションによる管理の煩雑化や、流出によるセキュリティリスクが存在します。GCP Workload Identity Federation では、Credential として有効期限の短い STS トークンで認証・認可を行うため、前述のセキュリティリスクを軽減できます。これらの処理はクライアントライブラリによって隠蔽されるため、サービスの開発者やワークロードは OAuth 2.0 Token Exchange の複雑な仕組みを意識することなく、通常の Credential と同じように利用することができます。GCP Workload Identity Federation は非常にセキュアで利便性が良いですが、内部でどのような手続きが行われているのか気になったので DeepDive してみました。

5 月 28 - 30 日（3 Days）Google Cloud が開催する Platform Engineering のハンズオンセミナーに参加してきました。 今回のセミナーは Google Cloud カスタマーエンジニアの公演を聞きながら、Google Kubernetes Engine（GKE）を活用して実践的に Platform Engineering を学ぶコンテンツとなっており、座学とラボの両方が実施されました。今回のブログでは、振り返りも兼ねて 3 日間の参加レポートをまとめたいと思います。

サイバーエージェント新卒研修にて『生成 AI を用いた SNS』というテーマで 3 週間の短期開発に取り組みました。僕たちのチームは 'AI で生成した美女' を共有する SNS アプリケーションを開発し、成果発表では インフラ部門で技術賞 を頂きました。今回のブログでは、開発したサービスと実際に構築した運用アーキテクチャについて設計思想や技術選定を交え、紹介したいと思います。

Kubernetes でリクエストを Pod に負荷分散する際にクライアントの送信元 IP アドレスを保持したいケースがあります。LoadBalancer や NodePort を使用する Service の場合、負荷分散の過程で送信元 IP アドレスが NAT（SNAT：Source NAT）されるため、Pod に到達するパケットからはクライアントの IP アドレスを知ることができません。Service の External Traffic Policy を Local に設定すると、外部からのトラフィックは受信したノード上の Pod にのみ転送されるため SNAT は回避できますが、単一ノードにトラフィックが集中するためクラスタワイドな負荷分散ができません。また、Ingress Controller を利用すると HTTP X-Forwarded-For ヘッダに送信元情報を付加することができますが、L7 LB が前提となるため、L4 LB のような低レベルロードバランサでは有効に機能しません。ベアメタル Kubernetes でネットワークロードバランサをプロビジョニングするための代表的な OSS に MetalLB があります。MetalLB には L2 モードと BGP モードの 2 種類の負荷分散方式が用意されています。多くの場合は前者が利用されますが、後者の BGP モードでは、より柔軟なネットワーク構成や負荷分散の制御が可能になり、送信元 IP アドレスを保持したままリクエストを分散することができます。今回のブログでは、MetalLB の BGP モードを利用して SNAT を回避しつつ、クラスタワイドな負荷分散を実現する構成について紹介したいと思います。