orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

リスクを考えるときに見逃されがちな1つのこと

f:id:orangeitems:20181111001038j:plain

 

リスクとの戦い

IT業界におけるインフラエンジニアの仕事はリスクとの戦いです。設計・構築のフェーズであっても、運用のフェーズであっても、いかにリスクを減らし安定した運用を心掛け、サービスレベルを100%に近づけていくか。すべてのシステム関係者がITインフラに期待していることです。いざトラブルが起きれば、暫定対応・原因追及・恒久対応やユーザーや上層部への報告など大変です。何も起きなければシステム関係者は幸せになれます。設計・構築を何件も手掛けてサービスインした結果、総じて安定していれば信頼を得ますしそうでなければ、二度と頼まれなくなるという厳しい世界です。運用フェーズであれば、一度起こした問題を再度起こすと、もう最悪です。反省してないじゃないか、原因追及が浅いのではないか。このように、どんなフェーズでも安定こそすべてなのです。

 

見逃されがちなリスクとは

私の経験を振り返って見ると、いろいろな人が設計・構築時に見逃しがちなリスクを1つ知っています。その見逃したリスクは運用フェーズで表面化します。もっとあのときに考えておけばよかったと。

そのリスクとは、「うまく行き過ぎたときをイメージしておらず、システムが対応できないこと」です。

普通リスクへの対応と言うと、以下がポピュラーな例ではないでしょうか。

・ネットワークにシングルポイントがないか点検し、機器に問題が起こってもサービスが継続できるように冗長化しておく
・サーバーが物理的に故障したときに、縮退運転してサービスが継続できるようにしておく
・いろいろな監視パラメータを設定し、障害が発生する前に予防できるようにしておく
・バックアップを常に取得し、ストレージに問題が起こってもリストアできるようにする
・運用時の本番作業のルールを決めておき、ヒューマンエラーを無くす

このように、「うまくいかなかったときをイメージし、できるだけ対策をする」ということがリスクマネジメントというイメージが非常に強いと思います。

いろんなシステムでこういった対応をするのは比較的誰でも思いつくのです。そしてサービスインから1年ほどは何も問題なく経過するのですが。

 

いまく行き過ぎた時に何が起こるか

WEBAPサーバーとDBサーバーからなるスタンダードなWEBシステムを例に取ります。負荷対策としてWEBAPは5台置きます。前にロードバランサーを置きます。DBはアクティブ-スタンバイでクラスターを構築しました。インターネットとの境界にはファイアウォールを置く。いたって普通の構成です。

この状況で、ビジネス計画上3年後のユーザー増加まで耐えられ、かつWEBAPは場合に応じてスケールアウト、つまり台数を増やす予定です。

ここまでは穴が無いように見えますが、最近は私はこう考えます。もし、ものすごく人気が出て急にトラフィックが100倍になったとして、耐える方法が用意されているかどうか。

こんな話をすると関係者は「そうなるといいですね」と微笑し、そこで思考停止するのです。ビジネスがバズるのは「大変うれしいこと」ですし、快不快で言えば快に当たるので、これをリスクだと考えない人が大変多い印象です。

しかし、インフラエンジニアにとってはこれは「逆」で、急にトラフィックが100倍になった時に、システム的にそれに耐えうる迅速な拡張方法を用意してないと、関係者から大変深い失望をされてるのがオチです。もし、システム屋がちゃんと対応してくれたら大成功したはずなのに。そして、バズるのは運やタイミングが大きく絡むので、取り返すこともできないのです。それは、将来に向けての大きなリスクです。

この場合だと、WEBAPを5台から200台に増やして対応できるのか、もしかしたら基盤が200台も用意できないのではないか。200台に増やしたらインターネット回線が枯渇するのではないか。WEBAPだけ急増したらDBの負荷も急増し、アプリケーションのボトルネックになるのではないか。

このように、「うまくいかなかったとき」と「うまく行き過ぎた時」は、リスクマネジメントの観点で言えば同義であり、両方検討しないと痛い目に合うということを身をもって体験してきました。

人は悲観的に考えた方が慎重になりうまくいく。この思い込みのために、思い切りうまく行き過ぎることがリスクになりうることを人間は見えなくなりがちではないかと思うのです。

もっと身近な例で考えるなら、例えばパン屋を開業するときに、お客さんが来なかった時どうするか考える。知人にしばらくサクラとして来てもらう。広告を配ってみる。などなどを考えがちです。しかし、パン屋が繁盛しすぎて店の周りに違法駐車があふれる。アルバイトが確保できなくて働きづめになる。材料が足らなくて困る。というふうに、うまく行き過ぎることはいたってリスクになりがちです。

 

大規模システムになることを前提とした準備

インフラ設計の話に戻ると、結果的にはシステムが大規模となったときのイメージをしっかり固めておくことにつながります。

小さなシステムをたくさん共有環境に詰め込んで、ビジネス拡大に基づいてサーバーやストレージを増やしていけばいい。この考え方はかなり危険で、小さなシステムのうち1つだけが急成長してトラフィックを受けすぎてしまい、そのシステムのために他のたくさんの小さなシステムに同時障害を引き起こしてしまう。こんな設計をこれまでたくさん見てきました。

リスクを考えるときに見逃されがちな1つのことは、うまく行き過ぎることを真面目に考えないことです。何か計画を立てるときは実施するときは、うまく行かないことの対策だけではなく、うまく行くことへの対策もセットで考えておきましょう。