可用性、冗長性を考慮したGoogle Cloudのインフラ構築の考え方
クラウドサービスを使ったインフラ構築では、稼働率・冗長性・災害対策などに気を付けて設計する必要があります。
本記事では Google Cloud を例に、 SLA の目標値、 災害対策方針を元に最低限必要なインフラ構成を考えます。
OS・アプリケーションレベルの品質は本記事では扱いません。
はじめに
システム障害による停止は、売上や信頼に直結する大きなリスクとなっています。
クラウドや Web サービスが生活やビジネスの基盤となった今、止まらない仕組みが欠かせません。
その実現のために、可用性の確保と冗長性の設計が重要視されています。
用語と設計前提
まずは、この記事で登場する用語と設計前提について整理します。
本記事では、ここで記載の内容を踏まえて、Google Cloud を利用した Web サービスの冗長構成について整理していきます。
この記事で登場する用語
-
稼働率
提供するシステムやサービスが使える状態である時間の割合です。
例：稼働率 99.9% なら、月間ダウンタイムは最大約 43 分まで許容されます。
| 稼働率 | 月間の最大停止時間（30日換算） |
|---|---|
| 99.0% | 約7時間12分 |
| 99.9% | 約43分 |
| 99.95% | 約22分 |
| 99.99% | 約4分23秒 |
-
RTO（Recovery Time Objective）
障害発生からシステムが復旧するまでの許容時間の目標値です。
例：RTO が 20 分なら、障害発生から 20 分以内にサービスを復旧する必要があります。 -
RPO（Recovery Point Objective）
障害時にどの時点までのデータ復元が必要かを示す目標値です。
例：RPO が 1 時間なら、最新から 1 時間以内のバックアップを取得する必要があります。 -
SLA（Service Level Agreement）
サービス提供者と利用者の間で合意する「サービス品質保証契約」です。
SLA には稼働率や RTO/RPO などの目標値が明記され、これらを満たせなかった場合の補償・対応（例：返金、サービス延長等）についても取り決めます。
インフラ構成では、SLA で定めた稼働率などの目標値を満たせるように設計する必要があります。
例：SLA で「稼働率 99.9%」が目標とされている場合、システム全体が 99.9% 以上の稼働率を達成できるよう構成します。
SLA に定められた条件を満たさなかった場合、返金または補償の対象となることがあります。 -
冗長性
障害が発生してもシステムを継続できるように、予備を持たせる設計です。
例：サーバを 2 台構成にすれば、 1 台が停止してもサービスを継続できます。 -
災害対策（DR：Disaster Recovery、DR構成）
自然災害やリージョン障害など大規模な障害に備えた復旧計画です。
例：データを別リージョンにもコピーしておくことで、迅速にシステムを復旧できます。
今回の目標と想定障害
次に本記事で扱うサービス品質の目標と、想定する障害レベルを整理しておきます。
目標
- SLA：稼働率 99.9%
- RTO：1 時間
- RPO：1 時間
想定障害
| 障害レベル | 対応方針 |
|---|---|
| リージョン障害 | SLA 対象。インフラ構成で耐障害性を確保 |
| 国レベル障害 | SLA 対象外。RTO/RPO を 24 時間で設計 |
| 大陸レベル障害 | コスト・運用負荷からデータ退避は非対応 |
対象サービス
今回はフロントエンド、バックエンド、データベースを使用する一般的な Web 構成を対象し、サービスは以下を利用することを想定します。
※金融システムや公共システムなど、 24/365 で無停止が求めらえるような、ミッションクリティカルなシステムは対象外とします。
- フロントエンド (※以下 FE) ： Cloud Run
- バックエンド (※以下 BE) ： Cloud Run
- データベース： Cloud SQL（PostgreSQL）
冗長性の考え方
ここからは、対象サービスである Cloud Run と Cloud SQL を例に、実際の冗長性設計について考えていきます。
Cloud Run の稼働率と冗長性の方針
Cloud Run の稼働率は以下の通り SLA が定められています。
冗長性は Google Cloud が標準で自動スケーリングする機能を持っていますが、可用性を高めるには下記の設計が重要です。
- SLA：稼働率 99.95%
- 複数サービスを用意（例：FE 用 2 台、BE 用 2 台）
Cloud SQL の稼働率と冗長性の方針
Cloud SQL（PostgreSQL）は複数エディションがあり、 SLA で定められた稼働率も異なります。
冗長性では、エディション選定と高可用性 (HA:High Availability) 構成の設定が重要です。
Enterpriseエディション
- SLA ：稼働率 99.95%
- HA 構成対応（自動フェイルオーバーあり）
- 標準的な高可用性が必要な場合に適しています。
Enterprise Plusエディション
- SLA ：稼働率 99.99%
- HA 構成対応（自動フェイルオーバーあり）
- マルチゾーン構成・高速フェイルオーバー対応
- リードレプリカによるスケーラビリティ拡張・災害対策も可能です。
- 重要業務やダウンタイム最小化を求める場合に推奨される構成です。
Cloud SQL（PostgreSQL）の構成例 :
| 構成 | 説明 |
|---|---|
| シングル構成 | 1 台のみのインスタンス ※ SLA 非保証 |
| HA構成 | 2 台以上のインスタンスを別々のゾーンに配置し、自動フェイルオーバー対応 |
| DR構成 | 2 台以上のインスタンス（レプリカ）を別々のリージョンに配置し、フェイルオーバー対応（自動/手動は要設計）※後述 |
HA 構成にすると自動フェイルオーバーでゾーン障害に備えることができます。
可用性を設計するための稼働率の計算方法
では、実際に稼働率をどう計算するのかを確認しましょう。これは後述で「構成ごとの比較」を行うための基礎になります。
サービスごとの稼働率の計算方法
サービスを単体で使用する場合は稼働率をそのまま計算に使用できますが、同じサービスを複数台利用する場合は並列度から稼働率を算出する必要があります。
並列度を求めるには以下の公式を使用します。
※A には稼働率、n にはサービス台数を代入します。
この公式を使用して、実際に Cloud Run を 2 台使用する場合の稼働率を計算してみます。
システム全体の稼働率の計算方法
システム全体の稼働率を計算するにはそれぞれのサービスごとの稼働率を掛け合わせます。
例として Cloud Run を FE 2 台、 BE 2 台と Cloud SQL の Enterprise エディション 1 台を使用する場合の稼働率を計算してみます。
SLA ：稼働率 99.9% を満たす構成と満たさない構成の比較
ここまでで個別サービスの冗長性と稼働率の計算方法を整理しました。
前述で整理した Cloud SQL の構成例に記載の通り、シングル構成では SLA が非保証であり、稼働率を算出できません。
また、 DR 構成は稼働率に依存しないので、冗長性では HA 構成を検討ポイントとします。
では、「SLA ： 稼働率 99.9% を満たせるかどうか」を以下の 4 パターンを例に挙げて、稼働率を比較してみます。
| 構成パターン | Cloud Run | Cloud SQL |
|---|---|---|
| 1 | FE2サービス＋BE2サービス | Enterprise Plus（HA構成） |
| 2 | FE2サービス＋BE2サービス | Enterprise（HA構成） |
| 3 | FE1サービス＋BE1サービス | Enterprise Plus（HA構成） |
| 4 | FE1サービス＋BE1サービス | Enterprise（HA構成） |
構成1と稼働率
| 構成1 | 稼働率 |
|---|---|
| Cloud Run （FE2台、BE2台）× Cloud SQL （Enterprise Plus HA構成） | 約99.98% |
→ 稼働率 99.9% を満たす構成です。
構成2と稼働率
| 構成2 | 稼働率 |
|---|---|
| Cloud Run （FE2台、BE2台）× Cloud SQL （Enterprise HA構成） | 約 99.94% |
→ 稼働率 99.9% を満たす構成です。
構成3と稼働率
| 構成3 | 稼働率 |
|---|---|
| Cloud Run （FE1台、BE1台）× Cloud SQL （Enterprise Plus HA構成） | 約99.89% |
→ 稼働率 99.9% を満たさない構成です。
構成4と稼働率
| 構成4 | 稼働率 |
|---|---|
| Cloud Run （FE1台、BE1台）× Cloud SQL （Enterprise HA構成） | 約99.85% |
→ 稼働率 99.9% を満たさない構成です。
冗長性観点での構成の結論
比較結果をまとめると、SLA 99.9% を満たすには Cloud Run の並列構成と Cloud SQL の HA 構成が必要だということがわかります。
ミッションクリティカルなシステムでない限り、 Cloud SQL は Enterprise エディションで十分であるため、冗長性の観点からは構成 2 が現実的かつ十分な選択肢であると考えました。
この構成なら一箇所の不具合で全体が止まることを回避でき、システム全体の稼働率を高められます。
- Cloud Run ：FE 2 台、BE 2 台
- Cloud SQL ：Enterprise エディション HA 構成
災害対策の考え方
インフラ構成の選定では災害対策方針・目標を考えることも大切です。
Cloud Run と Cloud SQL（PostgreSQL）を例に、構成決定の考え方を整理します。
まずはそれぞれのコンポーネントでどのような災害対策ができるか確認します。
Cloud Runの災害対策
Cloud Run の災害対策は、どのレベルの災害発生時までサービス提供を継続するかによって構成を決定します。
Cloud Run はデフォルトでリージョン内の複数ゾーンへ自動展開されます。
ゾーンレベルの障害であれば、特別な設定を必要なしに正常なゾーンへ接続してくれます。
リージョンレベル、またはそれ以上の災害に対応する場合は個別に設定が必要になります。
具体的には複数リージョンへサービスを展開し、Cloud Load Balancing で正常なサービスへ振り分けるよう設定します。
これにより、リージョンレベル以上の災害にも短いダウンタイムで対応できます。
Cloud SQLの災害対策
データ退避
データの退避は災害発生時にデータが失われないよう、別リージョンなど安全な場所に複製（レプリケーション）・バックアップしておくことを言います。
Cloud SQL では標準でバックアップ機能があり、任意の時間単位でバックアップを作成できます。
バックアップはデフォルトで大陸内の複数リージョンに保存されるので、リージョンレベルの障害時にもアクセスが可能です。
よりミッションクリティカルなサービスの場合は、レプリケーション機能を利用します。
高可用性( HA )をオンすることでデータを別ゾーンへレプリケーションして、ゾーンレベルの障害時にもデータへアクセスできるようにします。
クロスリージョン・リードレプリカ機能、Enterprise Plus で利用可能な高度な災害対策オプションを利用することでリージョンレベルの災害まで同様に対処できます。
代替システムの構築
代替システムの構築は、上記のデータ退避策で退避したデータを利用して災害の影響を受けていないリージョンでサービスを提供できるようにしておきます。
高可用性( HA )、Enterprise Plus で利用可能な高度な災害対策オプションはデータのレプリケーションだけでなく、代替システムへの自動繋ぎ変え機能も兼ねています。
障害・災害時には自動でレプリカをプライマリに昇格し、短いダウンタイムと小さいデータ損失でサービス継続できます。
クロスリージョン・リードレプリカ機能の場合は同じ接続情報で自動繋ぎ変えする機能はありません。
ヘルスチェック失敗時に繋ぎ変えを行うようにシステム構築するか、手動で繋ぎ変えを行うようにします。
ミッションクリティカル性が高くないサービスで RTO が十分に長い場合、バックアップと手動リストアに頼るという方針も有効です。
障害発生時は正常なリージョンへ新たにインスタンスを作成し、バックアップファイルからリストア、 Cloud Run から接続するまで手動で復旧します。
災害対策目標に合わせた構成の決定
今回満たしたい災害対策目標は以下の通りでした。
| 障害レベル | 対応方針 |
|---|---|
| リージョン障害 | SLA 対象。インフラ構成で耐障害性を確保 |
| 国レベル障害 | SLA 対象外。RTO/RPO を 24 時間で設計 |
| 大陸レベル障害 | コスト・運用負荷からデータ退避は非対応 |
これらを満たすインフラ構成を選定します。
Cloud Run
リージョン障害では 1 時間以内の復旧が必要です。
東京リージョンに加えて大阪リージョンへもデプロイし、Cloud Load Balancing で正常系に振り分ける構成をとります。
国レベル障害時は 24 時間の猶予があるため、国外リージョンへの手動デプロイで復旧する方針とします。
Cloud SQL
リージョンレベル障害は 1 時間以内に復旧が必要なので、メインリージョンの東京に加えて大阪リージョンでも準備が必要です。
障害発生時に自動繋ぎ変えをしたいところですが、そのために必要な Enterprise Plus オプションは非常にコストがかかるので今回は利用を見送ります。
クロスリージョン・リードレプリカを用いて大阪リージョンにレプリカを作成し、障害発生時は手動で切り替える方針とします。
国レベル災害時は 24 時間の猶予があるため、国外リージョンへバックアップから手動でリストアして復旧します。
また、RPO24 時間を満たすために日次でバックアップを行います。
災害対策観点での構成の結論
- Cloud Run：東京リージョン、大阪リージョンへデプロイ、ロードバランサで振り分け
- Cloud SQL：東京リージョン Enterprise エディション 、クロスリージョン・リードレプリカを大阪リージョンへ構築
まとめ
冗長性・災害対策観点を総合した構成の結論
双方の結論を総合して以下のような構成とします。
- Cloud Run：東京リージョン（FE1 台、BE1 台）、大阪リージョン（FE1 台、BE1 台）
- Cloud SQL：東京リージョン Enterprise エディション HA 構成、クロスリージョン・リードレプリカを大阪リージョンへ構築
この構成での稼働率は以下のようになります。
- 稼働率：約 99.99%
実際のサービスではここからコスト面を考慮し、システム品質とのバランスがとれるよう目標数値の調整などを行いますが、本記事ではこの構成で決定とします。
場合によっては手動での対処が必要な構成であるため、運用体制や復旧手順が揃っていなければいけません。
定期的なリカバリテストなどしっかり準備をし、体制・運用ルールも含めた設計をします。
おわりに
本記事では、Google Cloud の主要サービスを例に、冗長性と災害対策の考え方、そして実現するための構成例を整理しました。
クラウドサービスを利用したインフラ構築では、SLA で定められた稼働率や災害対策の目標を満たすための設計が重要です。
Discussion