第9回：クラウドの障害対策と可用性設計の基本

Cloud
ページ内に広告が含まれる場合がございます。
第8回：クラウドにおけるリソースの購入戦略と料金プラン設計 – Presales Note

「クラウドだから障害がない」は大きな誤解です。

むしろクラウドにおいても「どこで・何が・どれだけ止まるか」を想定し、あらかじめ備える設計（可用性設計）が重要です。

本記事では、AWS・GCP・Azureにおける障害対策と可用性設計の基本的な考え方、よくあるパターン、設計時のポイントを解説します。

クラウドでも障害は起こる

クラウドにおける主な障害の種類

種類例対策の方向性
インスタンス障害VMの停止、再起動自動復旧、自動スケール
ゾーン障害AZ（Availability Zone）単位の停止マルチAZ配置
リージョン障害地域全体の停止（まれ）バックアップ＋DR構成
サービス障害S3やDNSなどの一部機能停止サービス依存を分散設計

各クラウドにおける「可用性設計」の階層

階層AWSGCPAzure
ゾーンAvailability ZoneZoneAvailability Zone
リージョンRegionRegionRegion
グローバルGlobalサービス（S3, IAM）Global Load BalancerGlobal Load Balancerなど

VM・アプリケーションの可用性を高める設計

基本方針
  • 単一インスタンスに依存しない
  • 1つのゾーン障害でも継続できる
  • フェイルオーバーを自動化する
典型的構成例（AWSベース）
  • EC2 × 2台（別AZに分散）＋ Auto Scaling Group
  • RDS Multi-AZ構成（レプリカ自動フェイルオーバー）
  • ALB（Application Load Balancer）でトラフィック分散

各クラウドでの高可用性構成要素

項目AWSGCPAzure
VM自動復旧Auto Recovery（EC2）Self-healing VMVM自動再デプロイ（可用性セット）
ゾーン分散Auto Scaling Group with Multi-AZInstance Group with ZonesAvailability Set / Availability Zone
ロードバランサALB / NLBCloud Load BalancingAzure Load Balancer / Application Gateway
データベース可用性RDS Multi-AZ / Aurora ClusterCloud SQL High AvailabilityAzure SQL Geo-replication

フェイルオーバー設計の要点

自動フェイルオーバーの設計ポイント
  • VM停止時の自動再起動 or 自動再配置
  • DBのプライマリ → セカンダリ切替を自動化
  • DNS切り替え（Route 53 / Cloud DNS / Azure DNS）との連携
定期的なフェイルオーバーテストも必須
  • 手動フェイルオーバーによる挙動確認
  • 切替時間や影響範囲の把握

障害対策のためのデータ保護

保護対象対策備考
スナップショットEBS Snapshot / GCP Disk Snapshot / Azure BackupバックアップはAZ間・リージョン間に分ける
オブジェクトストレージS3 versioning / GCS Object Versioning / Azure Blob Soft Delete意図しない削除対策として有効
バックアップの多重化リージョンまたぎのコピーVault、LifeCycle設定で自動化可能

ディザスタリカバリ（DR）構成の基本

DRとは？

障害発生時に、別リージョンやオンプレミスに切り替えて業務を継続する仕組み

DRタイプ概要コスト復旧時間
ホットDR常時同期・常時稼働高数分以内
ウォームDR定期同期・起動は手動中数十分〜
コールドDRバックアップだけ保持低数時間〜数日

各クラウドでのDR構成支援サービス

  • AWS：Route 53、CloudEndure DR、S3 Cross-Region Replication
  • GCP：Storage Transfer Service、Cloud DNS、Backup and DR Service
  • Azure：Azure Site Recovery、Geo-redundant Storage（GRS）

高可用性構成の注意点とベストプラクティス

課題解決策
費用が高くなりがちスポット/プリエンプティブ＋最小構成で設計
テストが難しい計画障害によるシミュレーションを月1で実施
設計が複雑化まずはシンプルな「二重化」から始めること

おわりに：クラウドでも「止まる前提」で設計する

クラウドは高可用性を支援する仕組みが豊富ですが、自動で可用になるわけではありません。

障害を前提に「構成の冗長化、フェイルオーバー、復旧手順」をあらかじめ設計することが、信頼性の高いシステムの鍵です。

次回は、「マルチクラウド・ハイブリッドクラウド設計の基本」をテーマに、各クラウドを併用するパターンと注意点を解説します。

第10回：マルチクラウドとハイブリッドクラウド設計の基本 – Presales Note