大規模な障害を知り自組織でできる対策を考える

2021年だけでもAWSやFacebookなど、GAFAに含まれる超大手企業の大規模障害が数回発生しています。これらはご自身の商売や業務とは全く関係のない、他人事なのでしょうか。もちろん影響のない軽微な障害も多くあるでしょう。一方で何らかの関連のある場合、ご自身で提供しているサービスも同時に停止する可能性があります。もし止まったら、他社の復旧をひたすら待つことしか方法は無いのでしょうか。この記事では障害とその事例について概要を知り、自組織としてできる対策をまとめています。

大規模障害の概要と原因を知る

障害はその数だけ理由があり、慣れているはずの企業も起こしています。影響力のある国際的なIT企業ですら、情報セキュリティの「可用性」を維持できないことがあります。2021年だけでも以下のような規模の大きい障害がありました。この章ではそれぞれの概要と原因をまとめています。

AWS（Amazon Web Services）の場合

2021年2月

障害の時間帯	2月19日23時50分～2月20日5時30分頃（日本時間）
概要	AWS東京リージョンで、EC2およびEBSのサービスが停止
原因	・サーバーの冷却システムへの電力供給が正しく行われず、サーバールームの一部で温度が上昇しサーバーが停止
主な影響範囲	・気象庁の公式サイト ・仮想通貨取引所 ・一部オンラインゲーム

2021年9月

障害の時間帯	9月2日7時30分～9月2日13時42分頃（日本時間）
概要	北東アジア太平洋地域（AP-NORTHEAST-1）に接続するためのデバイスに問題発生
原因	・ネットワークデバイスに導入された新しいプロトコル ・特定の条件が揃ったときに問題を引き起こす欠陥（上記のプロトコルを無効化で解消）
主な影響範囲	・羽田空港（チェックインを行うシステム） ・航空会社（貨物の情報に関するシステム） ・大手銀行アプリ・ネット証券のWebサイト ・金融系のサービス（auPayなど） ・気象庁の公式サイト

Facebookの場合

障害の時間帯	10月5日0時40分～10月5日8時頃（日本時間）
概要	Facebook全社を接続するネットワークでシステムの保守時に、コマンドの操作によって意図しないネットワークの停止
原因	・データセンター間のネットワークを調整する機器の設定変更 ・ネットワークの中断が連鎖的に他に影響を与え、サービス全体が停止
主な影響範囲	Facebook、Instagram、Facebook Messenger、WhatsApp、Oculusのサービス停止

Fastly（CDNサービス）の場合

障害の時間帯	6月8日19時17分～6月8日21時頃（日本時間）
概要	米Fastly（ファストリー）が提供するCDNサービスに障害があり、このサービスを利用している世界中で多くのWebサイトへアクセスが不可になった
原因	・もともとソフトウェア内にあったバグが、利用者が行った設定変更により表面化し、障害へとつながる
主な影響範囲	FastlyのCDNサービスを利用している以下のWebサイト ・米国や英国など政府、報道機関のWebサイト ・日本では政府や報道機関のほか、メルカリ、note、TVerなどのWebサイト

CDNには重要な役割がある一方、想定外の弱さを抱えていることがわかります。

カゴヤのサーバー研究室ではCDNについて、わかりやすく解説しています。

自組織にとり有効な対策を考える

いったん大規模障害が発生すると、その原因がいかに一大事であったとしても、サービスの利用者にとってはただ使えないことに変わりはありません。そのためさまざまなサービスを利用して商売をする事業者にとって、決して他人事ではありません。

そうは言っても、やみくもに何かを買って設置するだけで安心というわけではありません。まずは焦ることなく、リスクマネジメントの手順で順番に分析し対処することが重要と考えます。周囲にしかるべき専門家も多くいます。自組織にとって、より適切な手段を選択していきましょう。

概要

情報システムでのリスクマネジメントの手法が、わかりやすく効果があると考えています。おおまかな流れは以下の通りです。

1. 「リスクアセスメント」（リスクの特定、分析、評価）の実施
2. 国際規格をもとに「リスク対応」する手順の作成
3. 対策計画を立案
4. 対策するための具体的な手段（サービス）を選択し導入

詳細は、下記のカゴヤのサーバー研究室の記事にて詳しく解説をしています。

これらの流れを参考にして調査や分析、対策案の決定、そして手段の選択に絞り、以下のように整理しました。

調査と分析

対象が膨大なため自組織にとっての優先順位をつけ、有限な作業時間と費用の範囲内で実施することが現実的です。考慮すべき点は以下と考えます。

1. 利用する外部のサービスにおいて、自組織の事業運営にどのようなリスクがあるか
2. そのリスクが発生したら、自組織の利用客にどのような損失などの影響があるか
3. そのリスクが発生する頻度は高いか
4. いつまでに対策をしておかなければならないか
5. 代替方法は何か

数ある調査方法の一つに監査ログの仕組みがあります。対象の動作が、あらかじめ決めていたように動いているのか確認できます。監査ログとそのシステムについて、カゴヤのサーバー研究室では以下の記事で概要をまとめています。

さらに、以下のようなリアルタイムの情報の入手も必要になるでしょう。

• 利用しているサービス提供会社のサイトやTwitterなどでの公式情報
• IT専門のニュースサイトでの分析情報

対策案の決定

次に分析し優先順位を付けたリスクに対して、自組織の向き合い方を決めます。代表的な対応方法は以下の通りです。

• 別のやり方に変える
• 徹底して対策する（専門家の力をかりる）
• あきらめて現状を維持する
• やめる

対策案を作成する際には気をつけたいことがあります。

• むやみに時間をかけて完璧にすることを目標にすべきではない（計画の精度を上げ過ぎない）
• 決めたことが実際にできること
• 対策として効果があること

大規模障害の情報に触れ、自組織の教訓として行動計画に反映することは有益です。例えば以下のことがわかれば、自組織の行動マニュアルを作成する際に役立つと考えます。

• 障害毎にその原因は異なる場合が多い
• 原因は一つのだけの場合もあれば、複数の原因が揃った時に発生する場合もある
• バックアップだけでなく復旧するための訓練を真剣に、定期的に実施する
• 手順を定期的に見直し、必要に応じて改定する
• 弱い部分がぜい弱になる可能性がある（いくら完璧に対策をしていても、冗長化していない部分があると全体としては意味がない）
• 対策が継続できるように、実施内容や費用に無理な部分や無駄を部分があれば可能な限り省く
• 似たような対策や代替方法の導入は共倒れになる場合があるため、可能であれば違う分野の代替方法を組み合わせる

冗長化を考えて手段を選択する

冗長化とは、現在使用している仕組みと同じように動くものを別に用意することです。これで、たとえ故障などで動かなくなったとしても、予備の仕組みに切り替えれば長時間停止させずに「可用性」を維持することができます。

別の仕組みを用意する際の注意点として、可能な限り「別のもの」を選択することが望ましいと考えます。「同じもの」場合に、一つが停止すると予備も同じように止まる可能性が高まるからです。例えば、サービスの利用者として以下の「分散」があります。

• 複数の業者と契約をする
• 機器の設置場所は一か所に集中しない
• 特定の時間帯に集まらないように、作業や処理を配分する
• 対応方法を複数用意し、一つが駄目でも切り替えて対応できるようにする
• 複数の作業者が対応できるようにする

そもそも「冗長」の意味には、無駄や余計なものといった悪い意味があります。リスクマネジメントでは逆に、普段からの備えとして、あえて「無駄や余計なもの」を活かす積極的な意味で使われています。

実際に対策をする

考えなければならないことがあまりにも多く、全てを理解することはできません。そのため、実際に対処するときは無理をしないことをおすすめします。

専門家に相談する理由と選定方法

事情と優先順位を熟知している専門家に相談し、自組織にとってちょうどいい手段を導入することが肝心です。この場合、専門家には客観的な指摘と適切な解決手段を提言する人（企業）と、専用システムの導入や運営を支援する人（企業）がいます。

自組織で専門家を新たに探す方法もありますが、すでに取引をしているサーバー業者などに相談するのも有効な手です。後者の方がより具体的で成果が上がると考えます。それは多くの困ったことに直面し、その経験から学んだ現場のノウハウの蓄積があるからです。

障害対応の事例

ここまでご説明してきた内容の具体例として、カゴヤ・ジャパンの障害対策を最後にご案内します。

自社所有のデータセンターに、専任のエンジニアが24時間365日体制で待機しています。障害が起きた場合に、状況確認や対応、復旧までを迅速に対応しています。利用する組織や事業の状況にあわせて、ネットワークやサーバーの冗長化設計や監視システムをご提案可能です。詳しくは以下のページをご参照ください。

自組織だけではなかなか対応が難しい障害の対処は、慣れている企業に任せ、本業に専念していただきたいと切に願います。