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

アイレット株式会社

【Google Cloud入門】信頼性のあるシステムを設計しましょう

Last updated at 2025-12-23Posted at 2025-12-23

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

前回の投稿では、Google Cloud におけるマイクロサービスの設計方法とアーキテクチャについて整理しました。

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

パフォーマンス指標

信頼性を確保するための設計では、主な指標として可用性、耐久性、スケーラビリティを考慮する必要があります。

可用性

可用性とは、システムが稼働しており、リクエストを正常に処理できる時間の割合を指します。

高可用性を実現するためには、継続的なモニタリングが重要です。
ヘルスチェックを利用することで、アプリケーションが正常に動作しているかを検出できます。また、リクエストの成功率や失敗率といったホワイトボックス指標を用いてサービスを詳細にモニタリングすることで、問題の早期検知や予兆の把握に役立ちます。

可用性を向上させるには、単一障害点を排除し、フォールトトレラントな構成を採用することが不可欠です。バックアップシステムも、可用性を補完する重要な要素となります。

耐久性

耐久性とは、ハードウェアやシステム障害が発生した場合に、データが失われにくい性質を指します。

データを継続的に使用可能な状態で保持するためには、レプリケーションとバックアップの両方が必要です。
データは複数のゾーンに複製することで障害耐性を高められます。また、定期的にバックアップからの復元テストを行い、復旧プロセスが想定どおり機能することを確認する必要があります。

スケーラビリティ

スケーラビリティとは、ユーザー負荷やデータ量が増加しても、システムが性能を維持しながら動作を継続できる能力のことです。

モニタリングと自動スケーリングを組み合わせることで、負荷の変動に柔軟に対応できます。
スケーリングの指標としては、CPU やメモリなどの標準的な指標を利用することもできますし、ゲームサーバーの同時接続プレーヤー数のようなカスタム指標を使用することも可能です。

信頼性のある設計

単一障害点の回避

データを複製し、複数の仮想マシンインスタンスをデプロイすることで、単一障害点を回避できます。
デプロイの単位を明確に定義し、その処理能力を把握することが重要です。

障害対応やアップグレードを考慮し、2 つの追加インスタンスを含む N+2 構成を採用することで、余裕を持った運用が可能になります。
各ユニットが負荷増加に対応できることを確認し、キャパシティプランニングを通じてデプロイ単位の能力を把握する必要があります。

また、容易にスケーリングできるよう、デプロイ単位は相互に交換可能なステートレスなクローンとして設計することが推奨されます。

相関障害

相関障害にも注意が必要です。これは、関連する複数の要素で同時に障害が発生する状況を指します。

たとえば、1 台のマシンで障害が発生すると、そのマシンが処理しているすべてのリクエストが失敗します。
ハードウェアレベルでは、トップオブラックスイッチ（top-of-rack switch）で障害が発生すると、ラック全体が影響を受けます。
クラウドレベルでは、ゾーンやリージョンが利用不能になると、そこに配置されたリソース全体が影響を受けます。

また、同一のソフトウェアや構成を利用しているサーバー群では、同じ不具合によって同時に障害が発生する可能性があります。
構成データも相関障害の要因となり得ます。グローバル構成システムで障害が発生すると、それを参照している複数のシステムが同時に影響を受ける可能性があります。

このように、同時に障害が発生し得る関連要素の集合は、障害発生ドメイン（フォールトドメイン）と呼ばれます。

相関障害を回避するためには、障害発生ドメインを把握し、マイクロサービスを複数のドメインに分散して配置することが有効です。
ビジネスロジックを分割し、複数のゾーンやリージョンにデプロイすることで、影響範囲を限定できます。

さらに詳細なレベルでは、役割を細分化して複数のプロセスに分散させることが推奨されます。
すべての役割を 1 つの要素に集約すると、1 つの障害が全体停止につながる可能性が高くなります。

マイクロサービスを設計する際は、独立性と疎結合を意識し、1 つのサービスの障害が他のサービスに連鎖しないようにすることが重要です。

カスケード障害

カスケード障害は、あるシステムの障害が引き金となり、他のシステムが過負荷になって連鎖的に障害が発生する状況を指します。
たとえば、バックエンド障害によりメッセージ処理が滞り、キューが過負荷になるケースが該当します。

このような障害には、デプロイプラットフォームの機能を活用して対処できます。
Compute Engine のヘルスチェックや、GKE の readiness Probe および liveness Probe を利用することで、異常なインスタンスを検出し、自動修復できます。

また、新しいインスタンスが迅速に起動し、他のバックエンドに依存せずにサービス提供を開始できる設計が理想的です。

死のクエリ

特定のリクエストが原因で障害を引き起こす「死のクエリ」への対策も必要です。
表面的にはリソースの過剰消費として現れますが、根本原因はビジネスロジックの欠陥であるケースが多くあります。

診断が難しいため、適切なモニタリング、オブザーバビリティ、ロギングが不可欠です。
レイテンシ、リソース使用率、エラー率をリクエスト単位で可視化することで、原因特定に役立ちます。

正のフィードバックサイクル過負荷障害

障害対応として再試行を増やした結果、逆に過負荷を引き起こす「正のフィードバックサイクル過負荷障害」にも注意が必要です。

すでに過負荷状態のサービスに対して再試行を集中させると、障害が悪化する可能性があります。
そのため、再試行は制御された形で実施する必要があります。

代表的な対策は次の2つです。

指数バックオフパターン：再試行を即座に行わず、失敗のたびに待機時間を延ばすことで、サービスの回復時間を確保します。
回路ブレーカーパターン：サービスが異常状態と判断された場合にリクエストを遮断し、状況の悪化を防ぎます。サービスが回復すると、制御された形でリクエストを再開します。GKE を利用している場合、Istio サービスメッシュによって回路ブレーカーを実装できます。

遅延削除

遅延削除は、ユーザーの誤操作によるデータ削除からの復旧を可能にする仕組みです。

削除操作を行うと削除パイプラインが開始され、段階的に処理が進みます。

Trash：一定期間内であればユーザー自身がデータを復元できます。
Soft-deletion：ユーザーからは見えなくなりますが、管理者やサポートによる復元が可能です。
Hard-deletion：復元不可となり、バックアップが存在しない場合はデータを回復できません。

災害計画

高可用性を実現

高可用性を実現するためには、リージョン内の複数ゾーンにデプロイします。

Compute Engine では、リージョンインスタンスグループを使用することで、自動修復とロードバランシングによる高可用性構成が可能です。

ストレージの可用性は、選択するサービスによって異なります。

Cloud Storage では、レイテンシ要件を満たす場合、マルチリージョンバケットを利用できます。
Cloud SQL では、フェイルオーバーレプリカを構成することで高可用性を実現できます。
Firestore と Spanner は、シングルリージョンおよびマルチリージョン構成をサポートしており、マルチリージョンではリージョン障害時も可用性を維持できます。

GKE クラスタもシングルゾーンまたはマルチゾーンでデプロイ可能です。
リージョンクラスタでは、コントロールプレーンとノードが複数ゾーンに分散され、可用性が向上します。

高可用性構成では追加コストが発生するため、リソース費用だけでなく、サービス停止時の影響コストも含めて検討することが重要です。

障害復旧戦略

障害復旧戦略には次の 2 種類があります。

コールドスタンバイ：バックアップをマルチリージョンに保存し、障害時に別リージョンで環境を起動します。復旧手順の文書化と定期的なテストが重要です。
ホットスタンバイ：複数リージョンにインスタンスを配置し、グローバルロードバランサでトラフィックを分散します。構造化データにはマルチリージョン対応データベースを使用します。

いずれの戦略でも、目標復旧時点（RPO）と目標復旧時間（RTO）の両方を考慮する必要があります。

障害シナリオを洗い出して構造化し、優先順位を付けることで、適切な復旧計画を策定できます。
計画は文書化するだけでなく、関係者への共有と定期的なテストを行い、少なくとも年に一度は検証することが推奨されます。

最後に

今回は、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