2019年12月4日、某所で大規模なシステム障害が発生し、2019年12月17日現在まだ完全には復旧していないようです。対象が公共団体ということならびに SaaS として運用していたことから、非常に大きな社会的影響が発生しているように見受けられます。
私も似たような職種で、障害対応などは大小含めて割と場数をこなしているので、どのような修羅場が起こっているかは想像できます。
関係者の皆様のご心痛をお察し、また一刻もはやい復旧をお祈りします。
さて、このような障害に際して自分ならどのように準備、対応、対処するだろうかということを少し考えてみたいと思います。 SRE本 でもポストモーテム (postmortem 本来は検死報告、いわゆる障害報告書) の重要性は度々触れられていますが、幸い毎日障害に出会うほど不運ではないようなので、この機会に将来の自分用にメモを残したいと思います。
障害の経緯に関しては @piyokango さんが piyolog でまとめていただいてますのでそちらをご参照ください。 また日経 XTECH などでも障害内容の詳細が報告されています。
以下に個別の事象に関して思うところを書いてみたいと思います。
ストレージ障害発生
ストレージは壊れ物です。個人的にストレージは障害原因のトップバッターだと思います。とにかくストレージは壊れます。なのでストレージは壊れることを前提に運用することが必要です。
また壊れたストレージは絶対に触ってはいけません。なぜならバックアップからの復旧が不可能だった場合にディスクからデータをサルベージする必要があるからです。その場合下手に触るとよりデータ破壊が進む可能性が高いためです。故障検知後は速やかに交換し、完全復旧が確認されるまで、もしくは専門の業者にサルベージを依頼するまで、できるだけ通電せずにそっと保管しておきましょう。どうしても故障原因を特定するためにログの回収が必要といった場合以外は、通電は控えましょう。
この点 AWSなどのパブリッククラウドのストレージシステム、例えば EBS などは通常ではありえないほどの設備投資を行い、耐障害性が高められています。複数データセンターでのレプリケーションなど通常なかなか予算が取れないような対策も取られています。
また障害発生時、代替機の用意や交換などの作業もクラウド事業者側に任せられるので、個別事業者側での対処が不要であるといった大きなメリットもあります。それでも万が一に備えて スナップショットの作成などの準備をしておくことが重要です。
ストレージファームウェアの不具合
ストレージファームウェアの不具合やストレージコントローラの故障も、ディスク自体の故障から見ると随分少ないですが、残念ながら一定の割合であります。特にファームウェアの不具合は厄介で、RAID構成の破壊や論理ドライブの破壊など、迅速な復旧が困難な障害が発生する可能性があります。
唯一の対策は確実なバックアップの作成です。また RAID （特に RAID 1 (ミラーリング)） していればバックアップがなくても大丈夫と考えている方も多いと思いますが、これも危険です。
ミラーリングは二重化してるので大丈夫と思われがちですが、コントローラが故障した場合は、読み出しが不可になりますし、コントローラの不具合や故障でデータが破壊されることもあります。
またよくある故障の例として、ミラーリングしている片側のディスクでセクタ不良が発生し、読み出し不可になっているものの、その領域に対して読み出しが無かったためにセクタ不良が長い間検出されないことがあります。この状態でミラーリングのペアになっているもう片方のディスクが故障が発生し、交換後の RAID 構築時に初めて全体スキャンが走ってようやくセクタ不良が検出され、結局再構成に失敗するということもあります。
このような障害はパトロールリードなどの機能を利用して検出することも可能です。しかし一定の性能低下が避けられないためと、ミラーしていれば問題ないという誤解から未設定となっていて、障害時に初めて困ってしまうという場合が多々あります。
ストレージファームウェアをアップデートするときは、通常フルバックアップを取得するのは当然ではあるのですが、今回のように緊急時であると直前にバックアップを取得することも難しくなるので、やはり事前に定期的なバックアップをしておくことが復旧の大前提になります。
大規模なパブリッククラウドであれば、母数が大きい分、まれな不具合の検出も迅速に行われる可能性が高くまた対処も事業者側に任せることができます。
冗長構成
「ミラーリングやクラスタリングなどの冗長構成をとっていれば大丈夫だった」という意見も見受けられますが、個人的には冗長構成も必ずしも有効に働くとは限らないと思いますので過信は禁物です。
まずクラスタリングなどの仕組み自体が複雑でどうしても不具合が発生しやすいこと、また故障状態が微妙な場合に切り替えが上手くいかないケースがあることが挙げられます。
特に故障状態を全て網羅的に想定することは人類には不可能で、かつ想定していない故障状態に限って発生する、ということが多くあります。最も、想定できる故障状態ならば事前に予防保守などで対処できるため、クラスタの異常検知に引っかかる故障状態としては、想定していなかったものが多くなるのは当然かもしれません。
微妙な故障状態を再現することが中々難しいという事情もあります。
このような不具合の代表例としてスプリットブレインという事象や、フラッタリングなどの事象が挙げられます。
対処としては定期的な切り替え試験を行うことが有効です。またクラスタによる自動切り替えが上手くいかない場合の手動切り替え手順を用意しておくことも有効です。
バックアップが見つからない、取れていない
バックアップが見つからない、取れていないもしくは壊れているというのはあり得ないと思われがちですが、滅多に使わない、しかも主要機能ではないものは人間忘れてしまうもので、運用現場では意外とよく聞く話です。
理由はバックアップ機構の不具合、設定ミス、設定忘れ、運用設計時の考慮漏れなどいろいろありますが、本当にわりとあります。
また多バックアップを作成するところまでは頑張って設定するのですが、バックアップからの復旧手順が欠落しているといったケースも多いです。手順があった場合でも、システムを運用していく中で変更が積み重なり、バックアップの漏れや手順の変更漏れなどにつながってしまい、復旧が難しくなる場合もあります。
このような問題に有効なのが定期的なバックアップからの復旧訓練です。また復旧後の確認も必要なため、自動化テストの準備も有効でしょう。また定期的に訓練とテストを行うことで、障害や手順漏れの事前検出、要員が慣れることによる復旧時間の短縮などの効果も期待できます。
またどうしてもバックアップからではなくストレージからのデータサルベージが必要となった場合に備えて、データ復旧事業者の選定や連絡先、料金の確認、復旧手順の確認なども行っておくとより良いと思います。
クラウドなら大丈夫か
ではパブリッククラウドなら大丈夫かというと、そんなことはありません。現在のパブリッククラウドは、絶対に障害が起こらない、故障しないシステムという幻想を捨てたシステムです。
Amazon や Google、Microsoft など超が何個もつく大規模データセンターや大規模サービスをいくつも運用しているところは、何らかの障害が日常的に発生しているはずです。そのため障害が発生しないシステムは不可能であることを身にしみて理解しているはずです。
そのためクラウド上では壊れないシステムではなく、故障や不具合を迅速に検出し対処することを目的としたシステムやツールが多数用意されています。
Site Reliability Engineering (SRE)
そのようなクラウド環境でサービスの継続性と信頼性を確保するための考え方を整理したものが Site Reliability Engineering (SRE・サイト信頼性工学) です。
SRE では故障や障害、性能劣化などは発生することが前提で、事象の発生を迅速に検出し、可能な限り早く復旧させることが重視されます。よくレジリエンスという言葉で表現され、障害が発生してもサービスへの影響を最小に抑え、かつ復旧する能力を指します。
このような機能の代表例が オートスケーリング でしょう。
迅速に対処するためにはそもそも事象の発生を迅速に検出し、解析する必要があります。そのため可観測性が重視され、各種モニタリングツールも提供されています。Cloudwatch、X-Ray などのツールが用意され様々なメトリックが取得でき、かつイベントの発生を lambda やオートスケーリング など他のシステムと連携する仕組みが整備されています。
このような仕組みを説明すると自動化に注目が集まりがちですが、本質的には問題の分析と対処手順、方法が重要で、自動化はそのための方法の一つに過ぎません。
そのため SRE では最初に書いたようにポストモーテムが重視されます。過去の障害を振り返り、かつ改善するために障害事象と原因、対処を記録する必要があります。
カオスエンジニアリング (Chaos Engineering)
レジリエントな仕組みが構築されたとして、それが本当に効果的かを確認する必要があります。そのため実際に様々な障害を実際発生させ、実際に復旧するかどうかをテストすることが行われるようになりました。基本的にサービス影響が少なくまた、自動的に復旧することが前提なので、本当に一部を壊してみても問題ないという考え方です。
実際に NetFlix では、本番環境で定期的に行われていると聞いています。
規模のメリット
パブリッククラウドを利用することの、障害対処の観点から上げられるもう一つのメリットとしては、規模の大きさがあります。耐障害性を高めるために複数のデータセンターにデータベースのレプリケーションを配置するマルチAZなどの機能は、予算上中々個別サイトで構築することは難しいでしょう。
また災害対策サイトなどはできるだけ遠隔地に設置することが好ましいですが、海外のデータセンターを調達し、配置することは現実的実施できる組織は限られると思います。
さらに十分な予備機や、検証環境を用意する必要もありません。十分な設備が数分で調達できます。またバックアップでも触れた復旧訓練なども本番とは別に随時することが可能です。
最後に
以上、思いつくままにいろいろ書き出してみましたが、各組織の予算や文化、サービスの特性、特に収益性などを考慮して適切な障害対策を実施してください。RTO、RPOを極端に短く設定することは費用を限りなく無限に近く押し上げます。本当にサービスに必要な RTO、RPO はどの程度か、しっかりと見極める必要があります。適切な SLO を設定することが最も重要だと思います。
