Blog

今月で Google Cloud の Professional 認定資格を全冠しました。このブログでは、これから Google Cloud 認定を受験しようと考えている方に向けて、試験で問われる内容や対策について紹介したいと思います。本記事で紹介する内容は、あくまで個人の所感を交えています。認定試験は頻繁にアップデートが入るので、最新情報や詳細な出題範囲については公式サイトの試験ガイドを確認してください。

Google Cloud のデータベースソリューションへの移行を支援するフルマネージドなマイグレーションサービスとして Database Migration Service（DMS）があります。DMS は、オンプレミスまたは他のクラウドサービスから Google Cloud へのデータベース移行、もしくは Google Cloud プロジェクト間でデータベース移行する際に、複雑な作業プロセスをマネージドに実行・管理してくれます。データベースの移行作業は、例えば初期データのダンプとインポート、アプリケーションが稼働している間の更新データの整合性の確保、スキーマの互換性チェックと調整、最終的なマスター昇格作業といった多くのステップが必要になります。DMS では、これらのプロセスを一元的に管理して複雑な移行プロセスを支援するように設計されています。直近、Google Cloud プロジェクト間で Cloud SQL を移設する際に DMS を使ったマイグレーションを実施したので、今回のブログでは DMS の紹介を交えつつ、データベース移設手順について紹介したいと思います。

複数の Google Cloud プロジェクトに跨るリソース間の通信が発生する場面では、VPC ネットワークを通じて安全に接続できる仕組みが必要です。Google Cloud では、主に Cloud VPN によるプライベート接続で VPC 間にトンネリングを構築する方法、VPC Peering で VPC 間を直接接続する方法、比較的規模の大きいサービスでは Shared VPC を利用してネットワークを共有する方法等があります。中でも Cloud VPN を使用した接続は、プロジェクト間を柔軟かつセキュアに接続したい、異なるネットワーク構成を維持したまま通信させたいといった場合に有効です。Cloud VPN は、トラフィックの暗号化や論理的なネットワーク分離を重視するケース、推移的ルーティングが必要となる場面で多く採用されています。今回のブログでは、Cloud VPN を利用して異なるプロジェクトの VPC をセキュアに接続する方法について紹介したいと思います。

2025 年 4 月 1 日から Docker Hub の Rate Limit が引き締められ、未認証ユーザによるイメージ Pull は 1 時間あたり 10 回まで に制限されました。Rate Limit に引っかかると、Docker Hub からのイメージ Pull が一定の期間規制されるため、コンテナが起動できなくなる危険があります。 特に、マネージド Kubernetes の場合、イメージ Pull はクラスタの IP（NAT IP 等）アドレスを送信元としてリクエストされるため、同一の IP アドレスから大量の Pull リクエストを送信すると、その IP に対して Docker Hub の Rate Limit が適用されます。このため、単一の Pod が Rate Limit に引っかかると、他の Pod もイメージの取得ができなくなり、ImagePullBackOff や ErrImagePull に陥る可能性があります。今回は Google Cloud Artifact Registry の Remote Repository と Amazon ECR の Pull Through Cache を活用した Docker Hub の Rate Limit 対策を紹介したいと思います。

2024 年 10 月から約 3 ヶ月に渡り Google Cloud が主催する Google Cloud Innovators Gym #9（通称 G.I.G.）というプログラムに参加してきたので、振り返りも兼ねてブログを書きたいと思います。 今後参加される方や、Google Cloud 認定資格試験を受けようと考えている方に向けて、何かの参考になれば幸いです。

Google Kubernetes Engine（GKE）は Google Cloud が提供するマネージド Kubernetes サービスで、クラウドネイティブなアプリケーションの実行基盤として広く利用されています。 Kubernetes クラスタの運用において、アップグレード作業はセキュリティの確保や新機能の利用のために不可欠なプロセスです。一方、Kubernetes のマイナーリリースは 通常 3 - 4 ヶ月に 1 回のペースで実施される上、アップグレード作業にはいくつもの考慮事項があるため、メンテナンスコストが高くなりがちです。また、マネージド Kubernetes の場合、サポートを受けられる期間も限られているため、継続的なクラスタバージョン追従が必要になります。このような GKE のメンテナンスに関する課題に対して、Google Cloud は作業負荷を下げるための仕組みを用意してくれています。このブログでは、GKE の効果的なアップグレード戦略について Google Cloud の内間さんが出している こちらのスライド を参考にまとめてみます。

先日開催された Qiita Hackathon 2024 に参加をし、無事に予選を通過してきたので、振り返りも兼ねてブログを書こうと思います。

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 日間の参加レポートをまとめたいと思います。

サーバ仮想化技術は、物理サーバのコンピュートリソースを最大限活用するために、従来から利用されてきました。 サーバ仮想化を実現する代表的なハイパバイザに KVM（Kernel-based Virtual Machine） があります。 KVM は、オープンソースでありながら高い性能と安定性を持ち、Linux に深く統合されていることから、多くのオンプレミス環境やプライベートクラウドで採用されてきた実績があります。昨今ではパブリッククラウドが普及したことで、オンプレミスのサーバから GCE や EC2、AVM といったコンピュートマシンへのリフトアンドシフトが進んでいます。 大半の場合、パブリッククラウドが提供するコンピュートマシンは、それ自体が仮想化された VM として提供されます。ここで、従来利用してきた「KVM によるサーバ仮想化はクラウドプロバイダが提供する VM でも利用できるのか」という疑問が生じました。答え、クラウドプロバイダが提供する VM でも Nested Virtualization（Nested V12n） という仕組みを利用できます。 Nested V12n は、その名の通りネストされた仮想化を意味し、VM の中で別の VM を実行（VM in VM）することを指します。 Nested V12n を使用すると、クラウドプロバイダが提供する VM 内で KVM を利用することができます。しかし、実際にはオンプレミスの物理マシンとクラウドプロバイダが提供する仮想マシンでは、KVM の構築に際して仕組み上異なる部分があり、後者の場合は特有の制約もあります。今回のブログでは、Google Cloud の VM（GCE）で Nested V12n を利用し、libvirt を用いて Linux KVM を構築してみたので、クラウドサービスの VM で KVM を実行する方法や、VM ネットワークの違いについて紹介したいと思います。