パソラーです

https://twitter.com/pasora

IT-BCP を考える

IT-BCP とは

BCP とは、Business Continuity Plan の頭文字で、
簡単に言うと「何があっても事業継続できるようにするための計画」ということだ。
そして頭に IT が付いた IT-BCP は、
いかなるシステム障害にも耐えうるサービスを構築するための計画、
ということになる。Plan なので計画になるわけだが、
計画を超えて様々な場面で「BCP が〜」と言われるので既にバズワード
しかも Google で検索する限りは日系企業が好んで使うガラパゴスバズワードらしい。

何を想定するか

「何があってもサービスを落とさない」ために、
まずは何が起こりうるかを考えることになる。
AWS の東京リージョンが使えなくなるかもしれない。
k8sクラスタが落ちたり、基幹データベースが機能しなくなるかもしれない。
大規模な災害起因だった場合、復旧にかかる人的リソースを確保できないかもしれない。
もしかしたら先日の log4j脆弱性のようなものがきっかけかもしれない。

システムが複雑であればあるほど、考え出せばキリがない。
ここで大事なのは、落とさないために落ちることを考えること。
システム・アプリケーションに対する外的要因も想定しておくこと。
それはサービス、要はビジネスに対してどんな影響を出すのか考えること。
そして最も大事なのは、その機能・コンポーネントが機能停止した場合、
本当に復旧させる必要があるのかどうかを考えておくことである。

誰が想定するべきか

この手の何が落ちるか、ということを考えるには当然
開発者、運用を担う DevOps なり SRE が必須になる。
ただ、先ほど最も大事だとした点、「それを復旧すべきかどうか」
ということを判断できるのはシステムエンジニアではない。
ビジネスを担当している側、ひいては経営者ということになる。
エンジニアリングかつ経営も行なっている場合は別だが、
そうでない人にもこういう言い方をすると違和感があるかもしれない。
しかしこれは言い方を変えれば
「全てが落ちていた場合、どれから先に復旧させるか」
という話だ。

仮に、とある会社で新幹線の座席予約システムを開発し、
とある IaaS の単一リージョンで運用していて、
そのクラウドプロバイダのネットワーク障害で
トラフィックの数割は落としているような状態に陥ったとする。
そのプロバイダからの調査結果として完全復旧までの見通しは立っていないが、
隣の Availability Zone に VM を移動させれば問題ないというレポートが上がった。
しかしサービスとしてはただ移動させるだけではダメで、
ACL の再設定や DNS の切り替えなどが必要になることは分かっている。
今現在は新幹線の座席を検索して支払いをするまでに何度もエラー画面を出すような状態で、
SNS はユーザの不満であふれている。
今は辛うじて動いているが、このまま落ちれば新幹線の運行にも影響が出る可能性が出てきた。
果たしてこの状態で、旅先での宿も一緒に予約できる機能は
一体どの優先順位が付くだろうか。

冗長ならいいのか

先ほどの例はこれを書いている時点で新幹線に乗っていて思いついたもので
あくまで仮のものとして承知してほしいが、
「もともと AZ またぎで冗長構成を取れば良いじゃないか」
と思う人も少なくないと思う。
幸い DB 等とのレイテンシが許容される範囲で各コンポーネントを多重に
デプロイできる環境にあったとして、1つ大きな問題が出てくる。
それに必要な予算だ。

サービスを提供するために必要なリソースを100として2つの AZ に撒く場合、
50と50ではダメな場合がほとんどだ。片方が落ちた時に半分のリソースしか無いからである。
50が受けきれなくて落ちたら元も子もない。単純に100と100、というのではコストが倍になる。
ではオートスケールを実装して、となるとじゃあ平常時はそれぞれどのくらいがいいのか、
実際にスケールは間に合うのか、など様々検討しなければならない。
この AZ を分散させた時に必要な最大リソースは 1 + 1/n なので
実は分散させればさせるほど100に収束する。
が、分散させればさせるほどリリース(デプロイ)が複雑になる。
そして、大抵のアプリケーションはそう簡単に横に並べればいいものではない。

BCP は投資

今までの話を総合して、(IT-)BCP は投資であると伝えたい。
どうしても話の主人公がシステムになるし、何かしらのパラメータを変更するだけで
改善できるものも出てくるかもしれない。
ただし、そのシステム障害が起きた時にすぐ復旧させるためにも、
そもそもそのシステム障害を起きないようにするにも、何かしらのコストが必要だ。

経営者が「AWS 落ちても良いように BCP 考えといて」と投げるようではダメだ。
適切な被害想定と対策を出せるエンジニア組織、
最低限守るべきところを定義し、損失を正しく見積もれるビジネス、
費用対効果を見極め投資判断ができる経営、
この全てが揃って「何があってもサービスを提供し続ける」ことができるようになると考える。