AWSは、「どんなものもいつでも壊れる前提」で作られている
マーケティング部の渡辺です。
データやITなどに関する様々なことをゆるく書いているコラムです。
クラウドの大きな障害が話題になっていました（2025/04の事件）
これを執筆しているよりも少し前（執筆しているのは2025年5月の中頃で事件は4月）、クラウドサービスの障害で多くのサービスが停止する事件があり、世の中でも話題になりました。今回は、そのことについて書いてみたいと思います。
クラウドサービスの障害（の原因）とは具体的にはAWS（Amazon Web Services）での大きな障害でした。多くのサービスが障害の影響を受けてしまい、スマホ決済サービスが停止して突然お金が払えなくなってしまう、飛行機に乗る前に手荷物を預けるときに使うシステムが使えなくなる、多くのスマートフォンゲームが緊急メンテナンス状態になってゲームが遊べなくなるなど、世の中でも多くの問題が起こりました。
世の中ではますますITの活用が進み、ビジネスはITと切り離すことができなくなっています。クラウドサービスが障害を起こして止まってしまうリスクとは、自社のビジネスが止まってしまうリスクに直結します。そこで、「クラウドサービスが止まってしまう」ことについて、あるいは「クラウド時代の安全安心の考え方」について、少し書いてみようと思います。
クラウドはサービスが使えなくなったりすることがあるもの
昨今は、DXだとか言われるようになってからも時間が経ち、各社でITを活用しなければ、という雰囲気はものすごくあります。そのような取り組みにおいて「クラウドを導入する」あるいは、既存のIT活用を「クラウド化する」ことは熱心に進められている取り組みではないか、と思います。
ただ、その一方であまり考慮されていない気もしているのが、クラウドサービスはいろいろ便利だったりする反面、現実的には「止まってしまったりすることがある」前提で利用ぜざるを得ないことが多いことです。
「サービスレベル（SLA）が99.9%」とは現実には？
例えば、このクラウドサービスはサービスレベル（SLA）が99.9%だと謳われていたとします。数字の印象からは、高い水準での安定稼働がオファーされているように見えるかもしれません。しかしながら現実には、「数年に一回くらいは丸1日サービスが止まって使えない」かもしれません、というのがこの数字です。朝から晩ではなく、「朝9時から夕方まで止まっていて、今日1日仕事にならなかった」ならば、1年に一回くらいあってもこの水準は満たすことになります。
体感的にも、昔からクラウドサービスを利用している人なら、数年に一回程度は「何か起こっている日」はあったりするものではないか、と思います。長年にわたり全く問題が起こっていませんというようなサービスは珍しいはずです。
「クラウドにする」とは、今日はクラウドの調子が悪くて電子メールが使えませんとか、今日はSlackの調子が悪いですとか、そういう日が「時々はある」前提で使わねばならないということです。多くのクラウドサービスが現実的にはそういう実情だからです。
ただし、世の中には他にも多くのリスクや不確実性があります。電車が止まってしまう日もありますし、災害が起こってしまうこともあります。ITにだけあまりにも完璧を求めてもしょうがないところもあります。「そのようなものだ」と思うしかないところもあります。
AWSは「どんなものも壊れる」前提で作られている
ここまではクラウドサービス利用側の目線で「現実問題として、時々使えなくなったりするものである」という話をしました。次に、クラウドの中で「安定稼働させる」こととは、どういうことになっているのか少し話題にしてみましょう。
例えば自動車を買うかどうか迷っていて、その車が故障するのかどうか不安になったとします。それに対して「いやいや安心ですよ」という説明があったとしたらどんな感じでしょうか。「故障などしない高品質の部品を使っています」とか、「出荷前の品質管理を厳重にしています」みたいな説明がされるのではないかと思います。つまり、「壊れません」から安心してください、という説明がされると思います。
AWS（クラウド）は「壊れません」という考え方ではない
例えばクラウドサービスのAWS、今では多くの企業が業務で自社のITシステムの開発の基盤として用いています。つまり実績として「ビジネスで利用できる水準である」と判断されているとみなせる状況です。ではAWS、「壊れない部品を使っております」のような説明をしているのかというと実はそうではありません。
AWS（Amazon）でCTOをしているWerner Vogelsさんの有名な言葉で「Everything fails, all the time」（どんなものでも壊れる、いつでも壊れる）というものがあります。つまりAWSでは「あらゆるものがいつでも壊れうる」を前提としており、「壊れなくしましょう」ではなく「現実的には壊れちゃうよね」が考え方の基本になっています。
「壊れない」ではなく「壊れるが回復する」の考え方
もちろん、「壊れてサービスが止まりました。そういうものだから仕方ないですよね」のような無責任なことをしているわけではありません。「壊れなくする」ことにとにかく力を注ぐのではなく、「いつでもなんでも壊れる」前提を受け入れて、その代わりに「壊れてもすぐに回復する仕組み」によって、システム全体での継続稼働を実現する考え方をとっています。つまりクラウドは、従来とは「考え方そのもの」が違うのです。
例えば、高価な高信頼性のハードウェアを用意して「そもそも壊れない」ことを追求して安定稼働を目指すのではなく、常に複数台の仮想マシン（Amazon EC2）を動作させ、トラブルなく動作しているかを常に監視し（死活監視）、仮想マシンが障害を起こしたと判断されたなら当該仮想マシンをすぐに切り離し、新しい仮想マシンを別途起動して回復することで稼働を維持するような考え方です。
- 仮想マシン（Amazon EC2）を常に複数起動して利用し、どれかが壊れてもすぐに代わりの仮想マシンを利用することで稼働を維持するような仕組みと考え方
このような考え方を採用すると、利用しているうちに故障してしまうこともある安価なハードウェアでもシステムを作れるようになり、低コストなサービス展開も可能になります。
2025年4月の障害で起こったこと（マルチAZ構成だったかどうか）
その上で再度、2025年4月に起こった大きな障害について考えてみましょう。「壊れるけれども回復する」の考え方はわかったけれども、AWSの障害で各社のサービスが止まる事件が起こってしまったのはどういうことなのか？とも思えるかもしれません。
実はAWSを利用するサービスなら一律に影響を受けたのではなく、「障害の影響を受けて止まってしまったサービス」と「影響を受けなかったサービス」がありました。
先ほどの例では「仮想マシンが壊れる前提」で「壊れてもすぐ切り替えられる」ようにしました。しかし、そのレベルの備えでは不十分なことがあります。例えば「データセンタそのもの」（AWSではデータセンタのことを概ねですが「Availability Zone」と呼びます）が障害を起こした場合にはどうでしょうか。仮想マシンを複数台稼働させて備えていても、「データセンタごと全部ダウン」してしまってはどうしようないことはイメージできると思います。
そして2025年4月の障害はAWSのデータセンタ（AZ）規模の障害でした。電源障害によるもので、主電源が故障したので予備の副電源に切り替わったがそちらも故障していたため停電が発生してしまい、「データセンタレベルでの機能停止が発生した」ことによる事故でした。ちなみに、それ以前には2019年にも同レベルの障害が発生しています。
- 「仮想マシンを複数起動」すれば「仮想マシンが壊れる」事態には「壊れても回復する」考え方で備えられる。しかし「データセンタごと壊れる」事態には対処できない
実はAWS、AWSを利用してシステム開発をする人に対して「AZ（Availability Zone）の障害に備えたシステムアーキテクチャにすること」を推奨しています。つまり、仮想マシンなどを常に「複数のAZ（データセンタ）にまたがって分散させて稼働」して死活監視することを進めています（マルチAZ）。そのようにしていれば、2025年4月の障害においてもサービス停止せずに済んだのです。
- 仮想マシンを複数起動する際に、仮想マシンが複数のデータセンタ（AZ）に分散して起動されるようにする。そのような形でAZを複数利用した状態にする（「マルチAZ」の構成）
- そのようにしておけば、データセンタ自体が壊れる事態が起こっても、全ての仮想マシンが同時に停止することは避けられるため、全体としてはサービス停止せずに済む。
あるいは今回の障害でサービス停止したところは、AWSから推奨されていた「マルチAZ構成」ができていなかったか、あるいはAZが一つ死んだときに生き残った仮想マシンへのアクセス集中の対策などができておらずに障害を起こしてしまったということになりましょう。
ソーシャルゲームでの障害発生が目立つ状況だったのですが、ゲームなので「もしもの時はサービス停止しても差し支えない」（シングルAZで割り切った方が費用は安い）と考えていて、意図的にノーガードになっていた可能性もあります。
- 「一時的なサービス停止があっても仕方ない」と考えて、あえて対策しない選択肢もある（「何かあった時には停止してしまうリスク」を対策せずに引き受けることも、ビジネス上の選択肢）
安全安心を心配しはじめると際限ない：「どこまで備える」のか
AWSはマルチAZ構成を推奨していますが、それ以上は考慮しなくても大丈夫なのか、というと実はそうではありません。
「東京リージョン」（東京付近）に配置してある「複数のAZが全部障害を起こす」事態も考えられるからです。具体的には、首都圏全域の大停電とか、地域全体が巨大災害に襲われてしまったような事態には、個別のデータセンタではなくて東京付近にあるデータセンタがすべて止まってしまう事態が考えられます。
- 複数のAZを利用すれば、すべてのリスクがなくなるわけではない
そのような事態まで想定するなら、「リージョン自体が壊れてしまった」状況にも備える必要が出てきます。つまり、複数のリージョンにまたがった構成にする必要（マルチリージョン構成）があります。具体的には「東京リージョン」と「大阪リージョン」を併用したシステム構成として地理分散するような構成が考えられます。
- 「リージョンごと全滅」まで考えるなら「マルチリージョン構成」が必要
マルチリージョンにすれば何もかも問題ないのか、というとまだそうではありません。AWS自体が大障害を起こすとか、AWSが社会的事情や政治的事情で突然サービス停止に追い込まれる事件なども起こりえないことではないからです。そのようなリスクは、GoogleクラウドやAzure、あるいはオンプレミスなどとリスク分散させないと防げません。
- 「AWS自体が丸ごと停止してしまう」リスクまで考えるなら、「マルチクラウド構成」が必要になる
このように「もしも」を考えると防ぐべきリスクはどんどん出てきます。そして、高度な対策をすればするほど、大変な対策が必要になってきます。
自社でどこまで対応するのか、という問題
こういう話を知ると、「自社システムは完全なマルチクラウド構成にする！」みたいな要望も出てきがちです。ただし、難しいことをしようとするほど技術力や工数を要してしまうことが多く、場合によっては難易度が高すぎて開発が完了しなくなります（開発炎上もITの重大なリスクです）。自社にとって現実的にどこまでの対応が必要で可能なのかよく考える必要があります。
あるいは逆に、自社には技術力がないからと、ここまで話題にしてきたような対応について縁のない話である、と思ってしまうこともあるかもしれません。しかし、何かあって「自社のITが止まってしまう」とか「データが消えてしまう」状況になって会社ごとなくなってしまいました、でも困るはずです。実際に事故が起きてしまった場合に、自社はどこまでなら耐えうるのかは考えておく必要はあるでしょう。
自社のITやデータの、どの部分をどのように守るか
現実的に考えるポイントとして、現実の「自社のIT」とは単一のITシステムではなく、複数のITシステムやクラウドサービスの組み合わせで出来ている事実があります。すべてのITシステムを同じように守り通す必要はなく、年に一日くらいならシステムが止まっても許容できるものもあるはずですし、手作業での事務作業などで一時応急できるものもあるはずです。
そのように考えれば、厳重に備えるべき「本当に守らないといけない部分」は全部ではないことが多いはずで、それならば現実的に検討がしやすくなるはずです。
さらには、「事業に関するデータそのものが喪失する」ことは許容できないが、「システムが一時停止する」ことは許容できる場合もあるでしょう。例えば東京が全滅するような事態においても、自社システムは平常通りの安定稼働を続ける必要性があるだろうか？と考えると、そうではないこともあるでしょう。そうならば、「データが失われないようには高度な対策をしておくが、システムは一時的に止まっても仕方ない」とすることで、現実的に十分な対応ができることもあるでしょう。
「壊れないIT」メインフレームとの組み合わせ
ここまで読んできて、そもそも「壊れる前提である」ことに違和感を持った人もいるかもしれません。つまり、ITにおいても「高信頼性の部品を使い、徹底的な品質管理をしているので、まず壊れません」のような考え方の方が私は同意できるなあ、と思った人もいるかなと思います。
AWSのような考え方は今のIT（や関連するビジネス）では主流ですが、品質や安全安心を徹底追及すること「以外」にも重要なことがある（素早いサービス展開や、提供コストなど）というような問題意識に基づいた「今の時代に合わせた考え方」でもあります。今風ではあっても、「あらゆる状況でこの考え方が適切」というわけでもありません。
ITにおいても「とにかく壊れない」「安全安心さを最重視」「徹底的な安定稼働」が、切実で重要な状況はもちろんあります。人命にかかわるITシステムなど、「何かあったら社会に取り返しのつかない影響が出てしまうITシステム」は、むしろそのような考え方であるべきでしょう。
実際にそのような安全安心最重視で作られているITシステムもあります。例えば「メインフレーム」がそうです。メインフレームは安定稼働することを大変に重視して作られており、我々が普段使っているようなハードウェアとは異次元の作りになっています。OSはもちろん、CPUも高信頼性を実現するための独自のものになっているくらいに、何もかもに高水準で異次元な配慮があります。
メインフレームは、今では「古臭いIT」として人気がなかったり、「レガシーIT」と呼ばれて廃止すべきものだとされていたりしますが、「とにかく安定稼働することが最重要である」状況においては、今なおメインフレームは非常に頼もしい存在です。
- 弊社のファイル連携ミドルウェアの「HULFT」も、メインフレーム水準の「圧倒的な高品質」を実現できる製品として支持されてきました。「そもそも壊れないから安心」を徹底的に実現しているプロダクトなので、ITシステムに「圧倒的な安全安心」が必要なら、ぜひ検討ください。
-
▼HULFT製品についてもっと詳しく知りたい
⇒ HULFT10│製品紹介ページ
メインフレームとの「レガシー連携」で両方の長所を光らせる
ただし、メインフレームだけでは「2020年代に必要なモダンITシステム」のすべての機能を作りきることが難しいのも事実です。例えば「スマホ対応したい」と思ったとして、メインフレームだけで開発に取り組むのは難しいことが多いでしょう。
そこで、止まっては困る業務のコア部分はメインフレームで実現し、スマホ対応など「今風の部分」はクラウドを用いるなど新しいITで実現して、その双方を「つなぐ」技術で実現することで新旧ITの良いところを組み合わせる（レガシー連携）こともできます。
「安全安心」には色々な考え方がある
というわけで、日本で広く影響が出てしまったクラウドの大きな障害の話題から「ITシステムを安定稼働させる」ことについて様々な話をさせていただきました。
最初にも書きましたが、世の中では、「とにかくクラウドにすべし」みたいな空気がありますが、現実にはクラウドサービスは時々障害を起こしたりします。さらにはサービスそのものが休止終了してしまうこともあります。それで大丈夫なのかは（あるいは何らかの対策が必要ないのかは）よく考える必要はあるのではないか、と思います。
世の中では「漠然と語られること」も多いITシステムに対する「品質」や「安全安心」ですが、クラウドとメインフレームを一例として「考え方自体が根本的に違う」アプローチがあります。クラウド流の考え方でも「どこまで想定して対策をするのか」で多くの選択肢があります。漠然と安全安心を語るのではなく、自社はどの考え方をどのように採用するのかを判断しなければいけません。
クラウドを自在に組み合わせて活用するには
「自社のIT」とは多くの場合には、複数のITシステム（部門ごとにそれぞれ導入されているシステムなど）やクラウドサービスで構成されていると思います。ならば、それぞれの部分で適切な対応を取り（必要なら重要な部分を別システムに切り出し）、対策水準の違うシステムをうまく組み合わせて、連携させて全体として機能させることが必要になってくるはずです。
例えば、どうしても安定稼働が求められる機能についてはメインフレームを継続利用し、クラウドで開発する必要がある部分とは連携（レガシー連携）して組み合わせて利用する。クラウド上で動かすシステムについても、停止した時のリスクを踏まえてそれぞれで適切に対応する。このように、複数のITシステムやクラウドを自在に連携して「つなぐ」ことができれば取り組みがうまく進むはずです。
そこで覚えておいてほしいのは弊社の「HULFT Square」や「DataSpider」です。GUIだけで多種多様なITシステムやクラウドと自在に連携することができ、多くのクラウドサービスと「つなぐ」こともできます。
「データだけでも高度な対策をする」のような場合には、まさしく「つなぐ」技術は大活躍できます。例えば、AWSの東京リージョンで稼働しているシステムからデータを読み取り、大阪リージョンに地理分散バックアップし、Googleクラウドにもマルチクラウドでバックアップするような作りこみを、GUIだけで実現することができます。
-
▼HULFT Squareサービスについてもっと詳しく知りたい
⇒ HULFT Square│サービス紹介ページ
-
▼DataSpider Servista製品についてもっと詳しく知りたい
⇒ DataSpider Servista│製品紹介ページ
クラウド時代の考え方「Resilience over strength」（強さよりも回復する力）
AWSに限らずクラウドでは「壊れるけれども回復する」考え方が採用されていることがよくあるわけですが、これは「クラウド時代の新しい考え方」として他の多くのことで参考にすることもできるのではないかと思います。
元MITメディアラボ所長の伊藤穣一氏は、このような新しい考え方を「Resilience over strength」（強さよりも回復する力）として、変化と不確実性がますます高まっている現在において一般的に大事な考え方（9つの考え方の基本原則のうち一つ）だとしています。
メインフレームの話で書いた通りに、新時代の考え方だからといってあらゆる場面で万能な考え方ではない（Strengthが重要であることはなおもある）ことには注意しなければいけませんが、ともすると個別の個人の責任感や完遂能力など（Strength）に依存しがちな日本の我々にとって「考え方レベルで違うアプローチがあり、クラウドサービス実現においてはそちらの考え方が採用されている」ことは考えてみるべきことではないかと思います。
また、外力に影響されず耐え抜く強さよりも、起こったことに素早く対応して回復し続ける考え方の方が「予測しない変化への対応能力」も高まることが期待できます。「これからは変化と不確実性の時代である」とは盛んに言われていることですが、「強さ」と「回復する力」は組み合わせて利用できることとも併せて、予測困難な未来に立ち向かわざるを得ない我々の今後を考えるヒントになるはずです。
執筆者プロフィール
渡辺 亮
- ・マーケティング部 デジタルマーケティング課 所属
- ・2017年 株式会社アプレッソより転籍
- ・大学で情報工学（人工知能の研究室）を専攻したあと、スタートアップの開発部で苦労していました
- ・中小企業診断士（2024年時点）
- ・画像：弊社で昔使われていた「フクスケ」さんを私が乗っ取りました
- （所属は掲載時のものです）
