冷却装置のトラブルによるAWS障害は未然に防げなかったのか

AWS障害の理由は冷却システムだったと発表されていますが、客観的に考えれば冷却システムなど簡単に交換できそうなものです。しかし、実際にはそうはならず、障害は大規模なものとなりました。ここではこうしたトラブルは未然に防げなかったのか探ってみます。

 

トラブルはなぜ防げなかったのか?

AWSが仕事をしていなかったのでは?

一般人からすれば冷却装置、冷却システムと聞いてイメージするのは冷凍庫、エアコン、扇風機あたりでしょう。コンピュータを冷却する時にもファンを使用して冷やすという方法を用いることは多いですが、大量にデータ格納庫が集まっていて、常に40度以上になってしまうような端末を冷やし続けるとなると冷却は単純な話ではありません。

 

冷やし過ぎもダメで、加熱されてしまうのもダメ、一定の温度範囲を維持できるように冷却システムを動かし続けなければいけません。

 

サーバー、クラウドサービスを常時動かし続けるには、根本的に電気が必要ですが、それにより発熱する端末を冷やしておける冷却システムも必須です。そして、冷却システムはより劣化しやすく、交換やアップデート、冷却効率の向上、省電力化が重要視されています。サーバー管理のビジネスでは、大小ありますが、箱さえあればなんとかなりますが、運営としては主に電気代を節約しないと経費を削減できないのです。

 

冷却システムの交換や新調を怠っていたというレベルのミスは起きていないはずですが、AWSのシステムは端末含めて古いという噂はずっとありました。今回のAWS障害ではそれが露呈したのはおおよその所間違いないでしょう。

 

GCPでもAzureでもサーバーを設置する土地、安定した場所、年間を通して冷却しやすい場所を選んでデータセンターが置かれます。AWSでも工夫はしていたはずですが、冷却システムの障害が出るほど、何かをしていなかったか、何かを怠ったのは紛れもない事実だと思います。

 

古い冷却装置をそのままにしたのでは?

たいてい大規模なデータセンターでは、一定期間ごとに耐久期間の過ぎた端末の交換を行い、障害が出ないように管理します。製品チェックも可能な限り動作確認もして新しいものと交換しますが、一気にまとめてサーバーを増設した場合には、その交換時期をずらす関係で老朽化や耐久期間を超えてシステムが動いてしまう状況も出てきます。こうなると怖いのが耐久期間を超えた部分の故障や障害です。

 

時系列で見て、一気に増設した部分の交換時期、装置の交換のタイミング、使用していた端末の弱さなどが重なって一気にエラーが起きてしまった可能性があります。ロードバランサーの動きがよくなかったのも、複数人で導入作業を行い、経験の浅い人か、疲れすぎていた人が設定、導入で細かなミスをして、その部分だけ根こそぎ反応が悪くなってしまった可能性もあります。

 

場合によっては小さなデータサーバーを冷却する部分ではなく、データセンターの一室まるごとの空調がダメになって交換に時間がかかった可能性もあります。そのロットまとめて異常が起きてしまった場合は、今回のような広範囲な障害につながる可能性もあります。細かなホコリや昆虫の侵入さえ許さないのが理想的な状況で、窓を開けて扇風機で冷却するというアナログな冷却ができない場合は対処のしようがない場合もあります。

 

トラブル対応訓練をしてなかったのでは?

事前に、導入段階である程度試験運用して、組んで導入していればマニュアル通りの対応で障害復旧できるはずですが、あちこち同時に障害が出てしまったのは連携が取れていなかった、または、日頃の訓練を行うまで余裕がなかった可能性があります。利益を重視して、必要最小限の人間だけで現場を回し、無理に装置を導入してシェアを伸ばしていた可能性は十分考えられます。

 

国内では有名なセブンイレブンの7Payもそのような対応不足、技術者を大切にしない体質が招いたとも言えます。AWSでも同じような古い体質、間違った認識があって、問題が大きくなった可能性はあります。

 

AWSの内部の評判としてあまり良い噂を聞かなかったのも、無理にシェアを伸ばして十分な技術者がいなかったのも両方とも問題です。Amazonは物販から始まっていて、元々データセンターの運用のプロではありませんので、AWSがより強固になるために必要な障害だったとも考えられます。

 

AWS東京リージョンだけなぜ?

FGOはAWSを使っていたが障害は起きなかった

オタク界隈では根強い人気を誇るFGOは障害が起きず、オセロニアやアズールレーンは落ちたという事で、それぞれのサービスの管理レベルが少し垣間見えたという点もあるでしょう。FGOはよくメンテナンスが入ることが知られていましたが、単純に今回はラッキーで障害を受けなかったか、障害に負けないように地道に裏で作業をしていたとも考えられます。

 

どのリージョンを使っていたか、いくつのAZを設定していたかもFGOはだいたい予想が付きますが、今回のような障害が起きたおかげで、事前に障害対策ができて、サービスそのものもより強固なシステムを構築できるでしょう。

 

FGOは障害が起きたAZを使っていなかっただけで、もし、東京リージョンのAZを使っていたら障害が起きていたかもしれません。日本には大阪と東京にAZがあり、大阪に1つのAZ、東京近辺に4つのAZがあるため、FGOは3つ以上のAZを設定していたか、大阪リージョンのAZを頼っていたという可能性もあります。もしかしたら、そもそも日本ではない他の地域のリージョンを頼っていた可能性もあります。

 

他のAWSリージョンと東京リージョンの違いは?

日本の東京リージョンは、日本のメインのリージョンとして4つAZを持ちますが、大阪リージョンは1つしかAZがなく、このことからローカルリージョンとも呼ばれます。大阪リージョンは2018年頃に導入された比較的新しいリージョンですが、制限もあり必ずしも完ぺきとは言えないものでした。東京リージョンは日本のメインのものとして選ばれながら、災害時には海外のシンガポールや中国のリージョンを選んで障害対策とするような事情もありました。

 

首都直下地震が起きたときに、日本国内のリージョンを使っていたらサービスが動かなくなるのは目に見えているので、自然災害の影響を最小限にできるように、程よく距離があって、日本の災害の影響を受けない場所として海外リージョンが選ばれます。この代わりのものとしても少し頼れそうなのが大阪リージョンで、補完的に導入されました。

 

決済系システムは、国内で運用しないと個人情報やセキュリティ面で良くない、また、基準を満たせないため、大阪リージョンができてからAWS導入を決めたところもありましたが、今回の障害発生で、導入を更に見直したり、撤回したりする所が出てくるのは仕方がないでしょう。銀行、勘定系、決済などのシステムが動かなくなると会社の営業が一時的にすべて手動になり、管理が追いつかなくなってしまいます。

 

システムに頼り切った業務をしていると、それが途切れたときに致命傷を負うこともあるので、クラウドサービス選びは慎重にならざるを得ません。東京リージョンは世界のさまざまな場所で頼られていたかもしれませんが、障害が起きたことで東京リージョンよりは中国のリージョンを選んだほうがマシではないかとする考えに至る海外企業も出てくるかもしれません。

 

メンテナンスやサポートの質の重要性を再認識

東京リージョンの評判を下げて、日本のAWS、AZを頼らないほうが良さそうだということと、放射能、地震を煽ってしまえば、安定を求める企業が東京、大阪リージョンを選ぶことはないでしょう。日本が選ばれないことでメリットを被るのはどこなのかを考えれば、サイバーテロだった場合の敵組織は把握しやすいものです。

 

メンテナンスやサポート、脆弱性調査、情報収集と研究が大切なのは言うまでもなく、セキュリティについても意識しないとゼロデイを突かれていることにすら気づかずにAWSされ被害者ヅラする可能性があります。サイバーテロだった場合は、被害者であることに間違いないですが、セキュリティ専門エンジニアを導入して、予防線を作らずに被害を受けたならば責任はAWSにもあります。

 

こうした事情からサポートの質、まともなサポートが有るかどうか、丁寧、かつ、親切なサポートがあるかどうかはクラウドサービス選びで重要です。使いにくい、分かりにくい、サポートが悪い、連携や連絡が取れないようでは、そのサービスはあまり信頼できないでしょう。

 

障害発生時にも何が起きているか明確に把握できなければサービス側、フロント側でどうしたら良いか意思決定すらできないのでは、どちらにしても運営側の失態です。

 

十分努力した上での障害ならば仕方ないですが、そうでなかったならば、人員を増やしたり、新しい端末を導入したりする改善を選び、担当エンジニアが健康と心の余裕を持てるくらいの給与を支払うべきです。問題が起きてしまったのは仕方がないですが、同じ失敗を繰り返さないようになにか変えて、努力していくのがここしばらくのインフラ屋のやるべきことになりそうです。

 

コメントを残す

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

CAPTCHA