AWS障害に学ぶ【クラウドサービス】の安全な頼り方が見えてきた

クラウドサービスに限らず、コンピュータやパソコンの上に成り立っているサービスは電気と端末に頼っているという意味ではもちろん脆弱で、目に見えないものを使っているという点で、脆弱ではあります。それでもクラウドサービスを賢く活用して、リスクを承知の上で管理しながら運用すれば安全性を十分高めたサービスを提供できます。

 

クラウドサービスは脆いのは事実

インターネットはそもそも脆い

近年のインターネットは、回線がパンパンで、回線速度を維持するのも難しいくらいになってきています。特にパソコン、スマートフォン、PS4、Nintendo Switchなどの影響で、各家庭だけでもネットが混線して時間帯によっては動画もブログも見れなくなってしまうこともあります。

 

インターネットすらそもそも重くなっていて、いくらサーバーが優秀でも、その応答を受ける側が逼迫していると十分な品質で情報を受け取れません。

 

クラウドサービスはどこで、どのように運用されていて、どんな仕組みで使えているのかよく分からずに使っている人が多いという点でもリスクがあります。特に日本では地震や台風などが頻繁に起こる地域で、その影響で電気が止まったり、その地域の電線が破損して一時的に機能しなくなったりすることもあります。

 

近年はそうしたリスクに備えて、十分対策されてはいますが、今回のAWS障害のように見えないところで起こるトラブルはユーザー側では何も対処できないので裁量や管理の事を考えるとやはり弱い点があります。

 

レンタルサーバーでの運用リスクは分かっていたはず

レンタルサーバーにシステムの心臓部を頼るのは良いですが、何か起きたときには心臓部をサーバーの管理者やサーバー会社に任せるしかないというのは事前に分かっていたはずです。たいていはお金を払っているから、まさか問題は起きないだろうと考えてレンタルサーバーを頼りますが、責任重大なサービスであるほどリスク管理し、いざという時に問題にならないようにしましょう。

 

この点に関してはサービス管理者に責任があります。サービス管理者がきちんとリスクを分散して、事前に備えておき、トラブルの可能性を減らして予防しておかないといけませんが、それを「おそらく大丈夫だろう…」と甘い判断で対処できるリスクに対処しなかった場合は、レンタルサーバーだけでなく、サーバーの利用者も運用努力不足です。

 

目に見えない、はっきりと仕組みを理解していないものを頼った時点でリスクはそのまま残っているので、真剣に、慎重に対処しなければいけません。AWS障害も誰もが大手だから大丈夫だと過信していたはずです。当然GCPもAzureもエラーやバグは目立たないレベルでちょくちょく発生しています。

 

AWSでも細かなものは頻発していて、こまめに対応しているから目立たないだけで大きなトラブルが重なると今回のような事態になるのは、どのサービスでも同じです。

 

マルチAZやロードバランサーだけでは足りないかも

AWS障害では、マルチAZでも、ロードバランサーでもエラーが起きていたとのことです。そのため、一つのレンタルサーバー、クラウドサービスだけでは十分安全ではないという判断になるでしょう。AWS内でマルチ化するだけでなく、使用するクラウドサービスも複数頼り、マルチ化する、または、いつでもマルチ化できるようにするのがエンジニアや現場の担当者がやっておくとよいことになりそうです。

 

AWS内のAZをマルチ化しても、ロードバランサーがAZ一つに対して一つしかなければ脆弱になるのでマルチ化して2つのロードバランサー、または、2AZを3つのロードバランサーで回すような使い方をすればリスクは減らせるでしょう。

 

どの部分もメンテナンス性と安全性を高めるためにマルチ化していくのが今後のクラウドサービスの流れになるでしょう。既にリスク管理しているところはマルチ化やさらに安全な方法を導入していますが、最新のクラウド管理の情報は入ってこない、見つけにくいので、エンジニアや担当者は苦労が耐えません。

 

決済・認証系サービスは落ちてはいけなかった

AWS側で決済・認証系は落ちないようにサポートすべき

2019年夏に起きたAWS障害は、100歩譲ってゲームやシンプルなアプリ系が動かなくなってしまうのはまだ許せますが、決済系サービスや認証系サービスまで落ちたのは信頼を著しく落としてしまいました。

 

ゲーム系では、アズールレーン、オセロニア、黒騎士と白の魔王、崩壊学園など、アプリ系ではスタディプラス、Backlog、バンダイチャンネル、dTVなどです。約900件近くのサービスでエラー、障害情報、不具合報告があり、大規模な障害となりました。

 

Paypay、AWESOME STORE、CLIP STUDIO、mixi、CAMPFIRE、ラクマ(楽天フリマアプリ)、Find job、宣伝会議、Chatworkなどビジネス利用されているサービスや、お金を決済するサービス、SNS、販売サービスでも障害が起きていました。特に金銭のやり取りをするPaypayやラクマ、Campfireのようなサービスは障害発生のタイミングによっては仕事にも影響があったかもしれません。

 

決済の遅延や販売取引のトラブルなどそこまで大きなものはなかったかもしれませんが、決済系のエラーはサービス提供者やサービス利用者両方から信頼を失ったことになります。

 

AWSの障害だったから各サービスは何も悪くないという考え方は間違いで、これらのサービスが取るべきだったAWS以外のクラウドサービスへの回避、障害発生時の回避を検討、及び、訓練していなかった落ち度があります。多くの方がAWSだから、よほどのことがないと落ちない、と会議やミーティングなどで話が終わってしまったはずです。

 

そもそも決済・認証系はAWS側でマルチAZ4つ以上にする

決済や認証を必要とするサービスは、AWS側でマルチAZにして、ロードバランサーの設定もマルチ化して、障害耐性を根本的に高めることを強制するとベストでしょう。これまではどのサービスに対してもだいたい同じようなマルチAZ、2個か3個のAZを指定するだけで良かったのですが、決済、認証があるサービスは3つ~4つのマルチAZを強制にすると少しはましになるでしょう。

 

また、東京Regionの4つのAZを頼るだけでなく、他の地域のAZも頼れば少しリスクを減らせるはずです。さらに、管理者、エンジニア側でGCP、Azureも合わせて分散するのが理想です。また、可能な限り自前でサーバーも構築できるように心がけて、他のサービスに頼らなくても成り立つように努力するほうが良いでしょう。

 

せめて、クラウドサービスがダメになって一般ユーザーが使えなくても、有料ユーザーや社内のユーザーだけでも稼働させられるくらいの環境は整えたいところです。

 

バックアップと復旧の対策・訓練も必須

さまざまな工夫をして、お金をかけて端末、クラウドサービスを良いものにしても、いざという時の復旧や復元ができなければ意味がありません。障害やトラブルは必ず起こるものなので、そうしたときに備えて日頃から訓練をするのも大切です。

 

サーバー管理者だけでなく、セキュリティエンジニアも、何か合ったときのためにすぐに元通りの状態に戻せるよう復旧訓練やマルウェアやランサムウェアが何もない状態のものを、すぐに復元できるよう訓練を行います。

 

サーバー管理者も、クラウドサービス担当者も、その人、または、チームだけで復旧ができるよう日頃の用意が全てです。防災や減災と同じで、現代のクラウドサービスでのトラブルは、災害のようなものです。訓練、対策、予防策をきちんと取り、ケース予測をして特殊なトラブルにも対応できるようにするのが担当者の仕事です。

 

これには終わりはなく、常時情報を収集し、学び、試験運用して実務的に実施できるようにし続けるのが一番です。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA