Design for Failure
掲載:2022年02月14日
執筆者:アソシエイトシニアコンサルタント 金井 優樹
用語集
Design for Failure は、障害が発生することを前提にシステム設計を行うという考え方で、「いかに障害を発生させないか」ではなく、「障害が発生したときにいかに対応するか」に重きを置いています。近年ではクラウドサービスを利用してITシステムを運用する企業が増えており、それに伴ってDesign for Failureも注目されるようになりました。本稿では、Design for Failureの基本的な考え方や実現のために必要な施策などをご紹介します。
Design for Failureが注目される背景
近年、ITシステムを自社で保有し運用するオンプレミスから、クラウドサービスを利用した運用に移行する企業が増加しています。Amazon Web Services (AWS)やMicrosoft Azureといったクラウドサービスを利用することで、企業は運用負荷を下げつつ、柔軟性の高いシステム設計が可能になるからです。
しかしその恩恵を受ける一方で、一度障害が発生すると多くの利用者に影響が及んでしまうという側面がクラウドサービスにはあります。実際に2021年、AWSで発生した障害では、仮想通貨交換業のコインチェックが全サービスを停止したり、気象庁のWebサイトが閲覧できなくなったりしました。
また、クラウドサービスで障害が発生した場合、その障害対応はクラウドサービス事業者に依存する場合が多いため、クラウドサービス利用者は復旧を待つことしかできません。そのため、クラウドサービス利用者はオンプレミス以上にシステムが停止したときのリスクを考える必要があるとも言えます。
このような背景を踏まえて注目されているのが、障害発生を前提とすることでサービスの可用性を可能な限り向上させるためのシステム設計の考え方である「Design for Failure」です。これはクラウドサービス事業者だけでなく、クラウドサービスを利用する側にも、障害発生を前提としたシステム設計を推奨する設計思想です。2010年頃からAmazonのCTOが提唱し始めたもので、現在ではAWSの設計における基本的な考え方として広く知られ、一般に浸透しています。
Design for Failureを読み解く
障害が発生することを前提としたシステム設計とは、障害に対して自動的に修正したり、障害が発生していない他の正常なサービスに切り替えたりできるシステム設計のことを指します。例えば、システムのある部分で障害が発生してもそれに左右されずに継続してサービスが提供できたり、サービスが停止しても、すぐに復旧できたりする仕組みをあらかじめ構築しておくことが、Design for Failureでは求められます。すなわち、サーバーがダウンするなど、障害が発生した際に、人の手を借りずとも自動的に早期復旧が行えるかどうかが大きな焦点となります。
また、Design for Failureでは、クラウドサービスの提供者だけではなく、利用者においても障害への対応責任が求められます。絶対にダウンしないクラウドサービスの提供は不可能であるという認識のもと、提供者は可能な限り早期復旧ができる機能を提供する一方で、利用者もその条件を基にしたシステム設計を行うべきであるという考え方が根底にあります。
Design for Failureを実現するためには
では、クラウドサービス利用者がDesign for Failureを実現するためには実際にどのような施策が必要なのでしょうか。ここでは大きく3つの具体策を紹介します。
①単一障害点(SPOF)の排除
システムの可用性を上げるためには、システム構成の特定の部分に障害が発生した際に、システム全体が停止してしまう要素となる単一障害点(SPOF)を作らないことです。具体的な取り組みとして、運用系に故障が生じた際に待機系ホストでの再起動による自動切り替えを可能とする、自動フェイルオーバー機能(HA)の導入が挙げられます。また、システムのバックアップサイトを複数のリージョンにおいて管理することも、SPOFを排除するために有効です。停電など地域的な要因でシステムに障害が発生した際に、素早く他のリージョンにシステムを切り替えることで、高い可用性を実現できます。
②多様な監視方法
障害から早期復旧するためには、脅威をいかに早く検知し、報告できるかが重要です。例えばAWSでは、CloudWatchという機能を用いて、システム内の重要なメトリクスとログの監視、異常動作の検知とアラート受信が可能です。このような機能の活用や、監視範囲、アラート発信基準の設定を見直し、迅速な障害検知体制を構築しましょう。
③組織内での運用、復旧体制の確立
いざ障害が発生した時に、組織内での動き方があらかじめ決まっていなければ、混乱を招き、早期復旧が難しくなります。障害が発生したときに、誰が、誰に、どのツールで連絡するのか等を事前に決めておきましょう。そして、その通りに動けるよう日ごろから訓練等を行い、確認を繰り返すことが早期復旧への鍵となります。
まとめ
技術がどれだけ向上しても、絶対に障害の発生しないシステムは残念ながらこの先も存在し得ません。障害が起きない設計を求めるよりも、障害の発生を前提にした仕組みを整える必要があります。
システムの可用性が高いか否かは、早期のインシデント対応や復旧の実現可能性を大きく左右します。企業・組織においてクラウドシステムを設計・利用する担当者、特にIT-BCP担当者の方々は、自社のクラウドシステムがDesign for Failureの考えを取り入れた設計になっているかどうか、今一度確認してみてはいかがでしょうか。
参考文献
おすすめ記事
- クラウドサービスを全社的にリスクマネジメントする方法-COSO-ERM for Cloud Computing徹底解説-
- クラウドサービスに特化したセキュリティ基準 ~各ガイドラインや認証制度の比較~
- ISO/IEC27017(CLS)― クラウドサービスのための情報セキュリティ管理策―
- ISMAP:政府情報システムのためのセキュリティ評価制度
- クラウドコンピューティング
- クラウドコンピューティングのセキュリティ
- BCMSとISMSにおける事業継続管理の違い
- COSO-ERMのクラウドコンピューティングへの適用ガイド(COSO-ERM for Cloud Computing)
- セキュリティ評価制度(ISMAP)の紹介動画を公開 IPA