可用性設計の基本：システム停止を防ぐAWSの考え方
目次
AWSにおける「可用性」とは？
可用性とは「必要なときにシステムを利用できる度合い」です。身近な例でいえば、電車の運行本数や遅延の少なさに相当します。ITでは稼働率（例：99.9%＝年約8.8時間停止）で表現し、利用者が継続的に使える体験を指標化します。
システムの基盤として広く利用されているAWS（Amazon Web Services）では、サービスごとにSLA（サービスレベルアグリーメント：サービス品質保証）が定められ、目標や補償条件が明示されます。ただしSLAは「無停止」を約束するものではありません。設計側（私たち）の冗長化・監視・復旧計画があって初めて、現実的な可用性が確保されます。AWSにおいて可用性を実現するためには、サーバーの配置を分散させる、マネージドサービスを使うなど様々な手法があります。
本記事では、それらの手法について解説していきます。
AWSにおける「可用性」のポイント
システムは止まるもの
日常的にスマートフォン等を通じて様々なアプリケーションを使っていると思いますが、時折使えなくなる場面に遭遇することがあります。アプリが使えなくなる原因としては、アプリを動かしているハードウェアの故障や、接続のためのネットワーク障害、運用時のメンテナンスミス、データを保存するストレージの容量不足、リリース不具合など様々です。
このように、ITの開発者、運用者、利用者は「システムは停止するもの」として前提に置く必要があります。だからこそ「一部が壊れても全体は止まらない」設計（冗長化・自動復旧）が重要です。
AWSのSLAとは
SLAは各サービスの稼働率目標と補償条件を示す契約です。サービスごとに稼働率が定められており、ユーザーはその稼働率を参考にして、システム全体の構成や稼働率を検討する必要があります。稼働率は『99%』などの数値で定められていますが、これは「稼働率が守られている」ことを示すだけであり、無停止という意味ではありません。また、SLA未達の場合の補償は主にクレジット付与であり、金銭的な損害補償ではありません。可用性の責任はユーザーとAWSで分担されるため、ユーザー側のアーキテクチャ設計も欠かせません。
可用性を高めるためのポイント
可用性向上には様々な観点があります。代表的なものは以下の通りです。
- システムの冗長化：マルチAZ構成や複数のEC2インスタンスを利用する
- 負荷対応：Auto Scalingなどでユーザ負荷の急増に備えたリソースの自動調整
- モニタリング：ヘルスチェックやシステム監視、異常時のアラート通知の整備
- 自動化：障害発生時にサーバー再起動やフェイルオーバーを自動で実行
その他にも様々な観点がありますが、本記事では『システムの冗長化』について焦点を当てていきます。
マルチAZ構成の基本と効果
AZとは？
AWSでは、AZ（アベイラビリティゾーン：可用性ゾーン）と呼ばれる単位にEC2などのサーバーを配置します。AZは同一リージョン（地域）内で電源・ネットワークが独立したデータセンター群で、地理的にも分散しており、一方の障害が他方に波及しにくい構造です。例えば東京リージョンには4つのAZがあり、利用者はそれぞれにリソースを配置できます。
シングルAZとマルチAZの違いは？
シングルAZ構成は1つのAZだけを利用するため構成がシンプルでコストも抑えられる反面、AZ障害でシステムが全面停止するリスクがあります。
マルチAZ構成は複数のAZにリソースを分散配置し、障害時も稼働しているAZでサービスを継続できるようにします。効果は主に以下の3つです。
- 耐障害性向上（片系故障でも継続）
- 計画停止時の影響低減（片側メンテ中もサービス提供）
- 段階的リリースの容易化（アップグレード時の切替が容易）
可用性を重視したシステム設計で安心して移行できるスタイルズのAWS導入・移行サービスはこちら→
マルチAZ構成のパターン例
Single Point of Failure（SPOF）の排除
SPOFとは、特定の箇所が故障するとシステム全体が停止する単一点障害のことです。マルチAZ構成ではSPOFを洗い出し、二重化や自動切替を実装します。例としてALBを用いて負荷分散を行い、複数AZに分散配置したEC2/ECSへトラフィックを振り分けます。データはRDSのマルチAZ構成で冗長化し、特定のAZに処理が集中しないようにします。
マルチAZで可用性を向上
典型的な構成は
ALB → EC2/ECS（2AZ以上） → RDS（マルチAZ構成）
ALBのヘルスチェック機能により、不安定なリソースへの接続を制御でき、AZ障害時にもシステム全体の停止を回避できます。
RDSのマルチAZオプション
RDSのマルチAZとは？
システム開発において、データベースの冗長化や負荷軽減は極めて重要な要素です。データベースが使えないと、ログイン障害やアプリケーションの遅延を招くことにつながります。AWSにおけるマネージドDBサービスであるRDSは、マルチAZ構成を実現するオプションが存在します。この構成は、スタンバイデータベースを別AZに保持し、障害時は自動フェイルオーバーして、スタンバイデータベースに切り替えることができます。
リードレプリカとは？
リードレプリカは、RDSで読み取り専用のデータベースを用意できる機能です。読み取りノードを増やし、書き込みはメインのDB、読み取りはリードレプリカで分担することで、データベース処理の負荷分散を行います。
リードレプリカとマルチAZの違い
リードレプリカとマルチAZは、スタンバイDBを用意するという点では非常に似ています。大きな違いは目的とデータ同期の処理方法です。マルチAZは可用性を重視し、同期的にデータの複製が行われています。リードレプリカは負荷軽減が主要な目的で、データの複製も非同期で行われるため、若干の遅延があります。可用性を求める本番DBはまずマルチAZ、読み取りが重いならリードレプリカ併用が定石です。
マルチAZの落とし穴
マルチAZでも障害は起こり得ます。アプリケーション側のセッション固定や処理の偏り、依存SaaS/外部API障害、リージョン全体の障害には対応できません。フェイルオーバー時は短時間の停止や書き込み中断が生じることによっても、ユーザーにとっては「アプリが使えない」という事態が発生します。継続的にSPOFの洗い出しを行い、適切なシステム構成を構築するだけでなく、十分なモニタリングや、障害検知時の復旧訓練などが不可欠となっています。
可用性を重視したシステム設計で安心して移行できるスタイルズのAWS導入・移行サービスはこちら→
まとめ
可用性は無停止の約束ではなく、「止まっても影響を最小化し、すぐ戻す力」の総称です。AWSのSLAは基礎情報にすぎず、実効性は設計と運用で決まります。基本はSPOFの排除＋マルチAZ＋自動復旧が必要です。またバックアップの取得や障害復旧訓練、システムの十分な監視も必要です。落とし穴（切替中断、外部依存、運用負荷）を理解し、定期演習と監視の改善を継続することが、現場で有効な“止まらない設計“への近道です。AWSの運用については幅広い知識も必要となってくるため、止まらないシステムを目指すためにも、専門ベンダーにぜひ相談してみてください。