こんにちは、システムエンジニアの大貫です。

先日、2019/8/23（金）12:30頃～AWS（Amazon Web Services）にて、大規模な障害が発生しました。

その影響で、国内のさまざまなサービス（PayPay、ユニクロ、mixi、DMM.bitcoinなどなど）、サイト／アプリなどが利用できない状態となりました。

今回の障害は、様々な要因はありそうですが、空調（冷却）システムの障害とのことで、手動による復旧も受け付けられなかったとのことで、復旧に時間がかかったようです。

復旧としては、ほとんどの環境では、6時間後の、18時ごろ問題が解消したのですが最終的にすべての環境が復旧したのは、22時頃。

ちなみに、冷却システムの障害ということでは、2017年にも、Microsoftのクラウドサービス Azure（アジュール）で、7時間サービスが停止したことがあったらしいです。。

AWSについても1回の事故で、クラウドサービスは安定稼働するというイメージが崩壊してしまったなど、信頼失墜に繋がった利用者もいれば、障害内容に対する迅速な対応力に感銘を受けている利用者もいるようなので、自分自身もトラブルを発生させない努力と、万が一発生してしまった場合のシミュレーション、および真摯なトラブル対応を実施していくべきと感じました。

また、今回のトラブルで、様々なサービスが止まることにより、サイト利用者に迷惑がかかったり、場合によっては商品購入が出来ず、機会損失に繋がったなど、各企業単位で被害があったかと思います。

AWSにはSLA（品質保証の基準）もありますが、条件も厳しく、今回の障害では、SLAの対象外の可能性が高そうです。
また、SLAと対象なった場合でも、返金ではなく、ポイントで還元だったり、サーバ利用料を超えての保証はされていないので、各利用者が、自己防衛をしていく必要があります。

今回のケースも、冗長化構成であればサービスが継続できたのではないかという論争も広がております。

サーバやクラウドサーバは、基本的には、サーバ会社からサービスを借りている状態ですので、サービスが止まった場合のリスクを考慮しながらサーバ構成を組む必要があり、サーバの構成を組むのは、お客様の自由です。

例えば、中小企業のサイトを、大規模な構成にする必要はないと思います。

今回の障害で感じたことは、

形あるものは壊れる

ということ。
クラウドだから落ちにくいということではなく、レンタルサーバ、専用サーバに限らずどんな環境でも、落ちる可能性があるということになります。

障害が発生する前提でシステムをどう構築するのか、あるいは障害をどこまで許容するのか、お客様と共有していく必要があると感じました。

弊社では、サイトの規模とお客様のご要望に応じて、サーバ構成やサービスを使い分けておりますので、サイト制作の際は、サーバの件についても弊社にすべてお任せください。
御社のサイトに最適なサーバを選定した上で、内容のご説明をさせていただきます。