アイレット株式会社 Advent Calendar 2025

アイレット株式会社

【Google Cloud入門】システムのメンテナンスとモニタリング

Last updated at 2025-12-24Posted at 2025-12-24

皆様、こんにちは！
アイレット株式会社 DX開発事業部の楊林と申します。

前回の投稿では、Google Cloud でシステム設計を行う際に重要となる指標について整理しました。

今回はその続きとして、Google Cloud におけるメンテナンスとモニタリングの考え方について整理していきます。

バージョン管理

マイクロサービスアーキテクチャの主な利点は、個々のマイクロサービスをそれぞれ独立してデプロイできる点にあります。一方で、各サービスが独立して進化していくため、サービス API を安定して利用できるようにするための設計が重要になります。

そのため、API のバージョニングは必須です。新しいバージョンをデプロイする際には、既存のクライアントに影響を与えないよう、下位互換性を十分に考慮する必要があります。一般的な方法として、URI にバージョンを含めることで、下位互換性のない変更を行う場合に明示的にバージョンを切り替えられるようにします。

ソフトウェアの新しいバージョンのデプロイには常にリスクが伴います。そのため、公開前に十分なテストを行い、問題がないことを確認したうえで、可能な限りゼロダウンタイムでデプロイできる仕組みを整えることが重要です。

ローリングアップデート

ローリングアップデートは、ダウンタイムなしで新しいバージョンをデプロイするための代表的な手法です。一般的な構成では、ロードバランサの背後に複数のインスタンスが配置されており、それらを一度にすべて更新するのではなく、1 インスタンスずつ順番に更新していきます。

この方法は、API の仕様が変更されない場合や、下位互換性が維持されている場合、あるいは更新中に同一サービスの複数バージョンが同時に稼働していても問題がない場合に特に有効です。

インスタンスグループを使用している場合、Compute Engine ではローリングアップデートは組み込みの機能として提供されています。更新時にローリングアップデートの戦略を定義するだけで適用できます。
Kubernetes では、Deployment の標準挙動としてローリングアップデートが採用されており、置き換え後の Docker イメージを指定することで自動的に更新が行われます。
App Engine でも、ローリングアップデートは基本的にプラットフォーム側で自動的に処理されます。

Blue/Greenデプロイ

サービスの複数バージョンを同時に稼働させることが難しい場合には、Blue/Green デプロイが有効です。

Blue/Green デプロイでは、2 つの独立したデプロイ環境を用意します。
現在本番稼働している環境を Blue 環境、新しいバージョンをデプロイする環境を Green 環境とします。

まず Green 環境に新しいソフトウェアバージョンをデプロイし、十分にテストを行います。問題がなければ、トラフィックを Blue 環境から Green 環境へ切り替えます。万が一問題が発生した場合でも、すぐに元の Blue 環境へ戻せるため、リスクを最小限に抑えることができます。

Compute Engine では、DNS の切り替えなどを利用してトラフィックを移行できます。
Kubernetes では、Service のラベル設定を変更することで、新しい Pod へトラフィックを向けることが可能です。
App Engine では、トラフィック分割機能を利用して環境の切り替えを行えます。

カナリアリリース

さらにリスクを抑えたい場合、ローリングアップデートの前段階としてカナリアリリースを利用することもできます。

カナリアリリースでは、既存のバージョンを稼働させたまま新しいデプロイを追加し、新しいバージョンにごく一部のトラフィックのみを流して挙動を監視します。問題がないことを確認しながら、段階的にトラフィックの割合を増やしていき、最終的にすべてのリクエストを新しいバージョンへ切り替えます。

Compute Engine では、新しいインスタンスグループを作成し、それをロードバランサの追加バックエンドとして設定することで実現できます。
Kubernetes では、既存の Pod と同じラベルを持つ新しい Pod を作成することで、Service が自動的に一部のリクエストを新しい Pod にルーティングします。
App Engine でも、トラフィック分割機能を使ってカナリアリリースを行うことが可能です。

費用計画

キャパシティプランニング

キャパシティプランニングは、一度実施して終わりにするものではなく、継続的に見直していくことが重要です。

まずは必要な容量を見積もり、実際の利用状況をモニタリングしながら、その予測が妥当であったかを検証します。その結果をもとに、次のサイクルで予測を更新していきます。

予測した容量に基づいて必要なリソースを割り当てることで、費用を見積もり、リスクと成果のバランスを取ることができます。設計と費用が承認された後は、その構成をデプロイし、実運用の中で継続的に改善していくことが求められます。

コンピューティング費用最適化

費用最適化を考えるうえで、まず Compute Engine の料金体系を正しく理解することが重要です。

最初は小規模なマシン構成から始め、需要の増加に応じて自動スケーリングでスケールアウトできるように設計するのが一般的なアプローチです。

長期間利用する VM に対しては、確約利用割引を検討することで大幅なコスト削減が期待できます。また、アプリケーションがフォールトトレラントであり、インスタンスの中断を許容できる場合には、Spot VM を利用することで Compute Engine の費用を大きく抑えることが可能です。

Compute Engine には VM インスタンスの適正サイズを推奨する機能も用意されており、ワークロードに見合ったサイズを選択することで無駄なコストを削減できます。

ディスク費用最適化

よくある失敗として、必要以上に大きなディスク容量を割り当ててしまうケースがあります。これは費用効率の観点では望ましくありません。

ディスクの選定では容量だけでなく、アプリケーションが求めるパフォーマンス特性を考慮する必要があります。たとえば、読み取りと書き込みの頻度やデータの性質（主に読み取り専用かどうか）を把握することで、適切なディスクタイプを選択できます。

SSD 永続ディスクは標準永続ディスクに比べて高価ですが、必ずしもすべてのワークロードで必要になるわけではありません。I/O パターンを正しく理解することで、ディスクコストを大幅に削減できる可能性があります。

インタネット費用最適化

ネットワーク費用を最適化するためには、アクセスするデータにできるだけ近い場所にリソースを配置することが基本となります。

下り通信の料金は特に注意が必要ですが、すべての通信が課金対象になるわけではありません。同一ゾーン内の下り通信は無料です。また、同一リージョン内での Google Cloud サービス間通信は、内部 IP、外部 IP のいずれを利用する場合でも基本的に無料ですが、Memorystore for Redis など一部例外があります。

一方で、同一リージョン内のゾーン間通信や、インターネットへの下り通信については課金が発生します。

GKE費用最適化

GKE 使用状況測定を利用することで、Kubernetes クラスタの過剰なプロビジョニングを防ぐことができます。

この機能では、エージェントがリソースリクエストを収集し、あわせて PodMetrics オブジェクトをポーリングして実際の使用状況を取得します。収集されたデータは BigQuery にエクスポートされ、リクエストされたリソースと実際の使用量を比較することで、無駄な割り当てを可視化できます。

ストレージ費用最適化

ストレージやデータベースサービスの選択は、費用に大きな影響を与えます。そのため、各サービスの特性とコストを十分に比較したうえで選定することが重要です。

アーキテクチャの工夫によって費用を抑えられる場合もあります。たとえば、静的コンテンツに Cloud CDN を利用したり、Memorystore をキャッシュとして活用したりすることで、バックエンドリソースの負荷とコストを削減できます。

また、サービス間の通信を Pub/Sub のメッセージングやキューで分離することで、データストアの依存関係を減らし、結果としてストレージ使用量を抑えられるケースもあります。

費用モニタリングと分析

既存サービスの費用を把握するためには、Cloud Billing レポートの活用が有効です。前月比での費用変化を確認できるほか、プロジェクトやプロダクト、リージョン単位でのフィルタリングも可能です。また、Compute Engine の適正サイズに関する推奨も確認できます。

より高度な分析を行いたい場合は、課金データを BigQuery にエクスポートすることで、費用の内訳を詳細に分析できます。Looker Studio を使えば、期間ごとの利用額をダッシュボードとして可視化し、関係者と共有することも容易です。

さらに、予算を設定することで、想定外のコスト増加を早期に検知できます。予算アラートはメールだけでなく Pub/Sub 経由でも受信できるため、Cloud Functions と組み合わせて費用管理を自動化することも可能です。

最後に

今回は本シリーズの最終回となります。
本シリーズは、Google Cloud の公式コンテンツを用いて学習した際のメモを整理し、記事としてまとめたものです。

これから Google Cloud の学習や資格取得を検討している方の参考になれば幸いです。

以前の投稿

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up