【メルマガ】またもやクラウドサービス(AWS)障害。障害前提の業務構築を(2020年10月27日)

先日、AWSの一部でサービス障害が発生しました。
影響範囲が大きかったので、もしかすると影響を受けた方もいらっしゃるのではないでしょうか。
(PayPayも影響を受けたようですね。)

繰り返しになりますが、システムは障害が発生するもの。
それに対して、どのように付き合っていくか、が大事なことかもしれません。

止まらないように、多重化を進めるのも「アリ」だが・・・

今回は、AWSの「東京リージョン」と呼ばれている区画の「一部」で障害が発生したようです。

今回の事象でいくと、対策として、マルチリージョン、さらにはマルチクラウド(「Google Cloud Platform」や「Microsoft Azure」等)の利用も考えられます。

しかし、やはりシステム構築の難易度、構築コストは跳ね上がります。
ザックリと適当な表現をしてしまいますが、99.9999点 を 99.99999点 にするために、数倍以上のコストがかかるイメージです。

止まらないシステムはない

先日のメルマガでもお伝えした「東証システムトラブルに見る、考慮すべき点」でもありますように、二重化、三重化していても、止まる時は止まります。

メルマガ

2020年10月1日、東京証券取引所のシステム障害により、終日売買停止となりました。 1999年5月にシステム化して以降、初の終日売買停止です。 私も前職では証券関連のシステムに関わっておりましたので、この事象は過去に記憶のない、大[…]

東証の時はハードウェア障害でしたが、ソフトウェアのバグでももちろん止まることはありえます。

マルチリージョン、マルチクラウド化など、どんな対策をしても100%止まらないようにすることは不可能です。
むしろ、障害発生部位が増えることで、「サービスを稼働させる」という観点からすると、悪化する可能性もありえます。

「システムがない前提」での業務の構築を

「システムは止まる」と考えると、大事なのは「システムがない場合」の業務を構築しておくことでしょう。

もちろん業務内容や重要度にも関係することですが、最低限「ワーストケースを考えておく」ことをオススメします。

・別システムを稼働させて、最小限の機能でなんとか業務をカバーする
・前日終了時点のデータから、あらためて本日の業務を実施する
・紙で代替して、後でシステムに一括反映する
・業務中止!と割り切る

などなど、考えてみると色々と備えが必要だとお感じになるのではないでしょうか。
事前に何を準備しておけばよいのか、も、明確になってくるかと思います。

クラウド障害の発生頻度が上がってきている感触があります。(AWSに限りません)
より大規模、より高機能になり、障害発生の確率も上がっているのでしょう。

メルマガ登録をする!!(無料)

    お名前(ハンドルネーム可)*
    メールアドレス*
    個人情報の取扱いについて* Privacy Policy

    ご入力頂いたメールアドレス宛に、広告を含むご案内のメールをお送りする場合があります。
    また、ご入力いただいた個人情報は「Privacy Policy」の記載に基づいて適切に管理します。

    One more thing

    何度もお伝えしてきている、クラウド障害。
    過去を見ても、定期的にクラウド大規模障害は発生しています。

    これで万全、というお話ではありませんが、データの保管をマルチクラウド化しておくことは、ある程度用意です。

    関連記事

    先日、当サイトでご紹介した「MultCloud」というサービス。 しばらく使用しましたので、サービスレビューいたします。 [sitecard subtitle=関連記事 url=https://gloria.cool/blog/20[…]

    バックナンバーに戻る