AWS障害の「冗長構成」と「AZ」とは

AWS障害の話で出てくるAZはAvailability Zoneのことを指し、冗長構成(冗長化)はマルチAZ化した途中経路のロードバランサーやサーバーのマルチ化をして障害耐性を高める目的で導入されます。今回のAWS障害ではそのどちらにも問題が発生してしまったとのことです。ここでは、おおまかにそれぞれの違いや用途、事情を解説します。

 

AWSやクラウドの冗長化とは

障害耐性を高めるのが冗長化

AWSで導入されている冗長化は障害が起きたときに、その影響が最小限になるようにするための工夫です。一般的に、ひとつの入れ物に全てのサービスを入れて稼働させますが、冗長化する時は複数の入れ物にサービスを分散して保管し、稼働率を安定させるようにします。一つのサーバーがだめになっても、他のサーバーが生きていればその生きているサーバーでサービスを継続するというのが目的です。

 

データの入れ物だけ複数個用意していても、途中の経路で異常が起きてしまうと、複数の入れ物がある意味がありません。そこで、ロードバランサーと言われるような、サーバーからの応答、クライアントから応答を受けて適切に流す役目を担う連絡役が必要です。

 

エラーが起きたときにはフェイルオーバーというような応答を受ける場所を変える操作をして、生きているサーバーから応答が来るようにしますが、障害の規模やユーザーの規模によっては、一時的にサーバーダウンすることもあります。

 

このフェイルセーフ、ロードバランサー、サーバーのマルチ化も2つより3つ、3つより4つと多い方が安心ですが、コストはかかり、管理やメンテナンスも大変です。こうしたサーバーのマルチ化を行うと仮想IP、ローカルIP、グローバルIPというような割当でエラーが起きてしまうこともあるため、保守・運用の仕事が非常に大切です。

 

同じ環境内での冗長化だけでは全体的なダウン時に対処できないので、バックアップサーバーを設置するのが無難な対策ですが、大規模なサーバーではこのバックアップサーバーを用意するだけのコストがかなり掛かります。

 

IPゲートウェイも壊れると反応しなくなるので、複数台ゲートウェイを用意して通り道を複数用意しておけばトラブルにも対処しやすいです。また、複数経路を確保できている場合は、メンテナンスもしやすくなります。

 

通り道が一つしかないと、端末が故障しそうなときにはメンテナンスとして必ずサービスを停止しないといけませんが、複数経路があれば、メンテナンス中でも異常のないものがサービスを継続してくれます。

 

要となるのはALB(アプリロードバランサー)

AWS障害では冷却装置のトラブルだけでなく、ロードバランサーもうまく動いていなかったと発表されています。ロードバランサーも複数用意し、AZのマルチ化もしていればそこまで多層的にトラブルが起きることはなかったはずですが、冗長化しすぎて、反応しなくなったサーバーと、それに関係するロードバランサー、IPゲートウェイ部分が混乱して人為的ミスが起きた可能性はあります。

 

エラー部分の切り分けはデータセンターが複雑になるほど難しくなります。新しい設備で、メンテナンス性も改善されていて、最新環境になっていれば今回のようなトラブルは防げたはずです。巷でよく言われていた「AWSは端末が古い」という話はおそらく事実で、その構成の古さ、端末そのものの古さも問題を大きくした可能性があります。

 

ただし、既に運用されていて、なかなか停止できない状態のサーバーを移行するのは困難です。おそらく、システム的な脆弱性があることは現場のエンジニアは把握していて、上司にも申し立てを行い、改善をすべきだと言ったはずです。

 

それでも、コストや手間を考えて事前のトラブル予防を行わなかった、または、そういう指示を出した上層部が引き起こした事件でしょう。東京リージョンで問題が起きたというのもそれを物語っているように思えます。

 

7Payでもエンジニアをないがしろにして、コストや安全性を後回しにしてサービスをリリース、運用した結果、あのようなどうしようもない状態になり、今回はAWS障害で似たような現象が起きていたと予測できます。Amazonという知名度が高いだけのサービスで、傲慢か、自惚れか、対策を怠ったことで、比較的簡単に交換できる冷却装置でトラブルが起きるという事態になったと考えられます。

 

コストをかけて障害耐性がなかった可能性も?

さまざまな経路でマルチ化をしていて大々的に宣伝もしていたようですが、実際は優秀なエンジニアと端末頼りだっただけで、そこまで脆弱性対策やトラブル予防に手間とコストをかけていなかったのでしょう。もしかしたら、訓練中やメンテナンス中のトラブルになったのかもしれませんが、結局ロードバランサーでもエラーが起きているので、障害耐性が十分だったとは言えない可能性があります。

 

特に決済系のサービスまで停止していたというのが問題で、支払いができない、連携が取れないという状態で損害を被った人は多かったはずです。これが医療システムや個人情報をやり取りするシステム、クレジットカードのシステム、銀行のシステムだったら、さらに大きい問題になったでしょう。医療系のシステムがここを頼っていたら、死人が出た可能性もあります。

 

障害耐性があると信じてAWSを使っていた人からすれば、結局問題が起きると広範囲にエラーが出る状態なのは変わりないということで、騙されたと感じている人もゼロではないでしょう。

 

自宅サーバーを運用していても、AWSを頼っていてもエラーが出るのは同じなので、障害が起きてもすぐに復旧できるように、きちんと工夫する、リスク分散をもっと工夫するというのが現状の課題です。

 

冗長構成が必要なのも、結局はサーバーの仕組みそのものは進化していないからで、まだまだ科学技術的な進歩は十分ではありません。おそらく向こう10年、100年経っても絶対に落ちないサーバーというのは存在しないでしょう。

 

AWSの話で出てくる「AZ」とは

アベイラビリティ・ゾーン=「AZ」

AWS障害の各メディアの記事を見ていると必ずと言ってよいほど出てきたはずの「AZ」はアベイラビリティ・ゾーン(Availability Zone)のことです。日本にはTokyo RegionとOsaka Regionがあり、AZ(Availability Zone)はTokyoの近くに4つ、Osakaの近くに1つあります。TokyoとOsakaの真ん中あたりにはPoint of Presence(PoP)は1つあります。

 

Point of Presence(PoP)は、リモートサーバーに接続するポイントのことで、各Regionに1つは必ずあります。中国の臨海部で、人口の多いポイントではPoPが適宜配置されるようなこともあります。インドのMumbaiにはAZは3つ、PoPは4つ、インドの北部と南部に分かれて設置されています。

 

PoPはインターネットへの接続ポイントと考えておけば理解には困らないでしょう。詳細はAWS公式のインフラストラクチャー(https://www.infrastructure.aws/)で確認してみてください。

 

「AZ」は物理的なリソース(データセンター)みたいなもの

AZは言い換えてしまえば、HDD、データを格納しておく所がたくさん集まったものと考えましょう。データセンターともいいますが、大きなデータセンターは小規模のサーバールームとは規模が異なり、倉庫のようなところに大量のサーバーがあって、それぞれのサーバーをさらに複数接続して組み上げられています。

 

大きい規模のAZに対して一つだけロードバランサーがあるという感じではなく、複数のロードバランサーを構築して、マルチ化するのが障害対策と考えれば、理解はできるでしょう。

 

「AZ」も複数のデータセンター経由で構成

AWSでは、既に複数のAZを使うように指示されていましたが、2019年夏に起きたAWS大規模障害ではAZを複数指定していても障害が発生してしまっていました。これはロードバランサーがうまく働いていなかった、または、ロードバランサーの部分でも障害が起きたと発表されていました。

 

AZを2箇所設定していた場合は障害が起きたようで、AZを3つ設定すればもしかしたら障害は起きなかったかもしれません。2AZでは少し障害に対して脆弱ですが、3AZにしたところで、ロードバランサーを増やしたところで安定するか、絶対に落ちないかと言うとそうとも限りません。

 

AWSで構成してしまったサービスを他のクラウドサービスに移行するのも簡単ではないですが、外部の他のサービスでも復帰できるように備えておくのは管理者側でやるべき努力項目でしょう。AWSだけに頼っている時点で、1AZと同じようなものと考えて、AzureやGCP(Google Cloud Platform)にも頼れるようにしておき、いざという時はすぐに切り替えできるようにするのが理想形かもしれません。

 

これも実際に試験的にサービスを落としてみてきちんと回るか確かめてみるしかないため、管理者や担当者が実験して障害耐性を各自チェックするのがここしばらくの仕事になるでしょう。

 

ただし、サービス内容によってはそこまで対応する必要があるか、そこまでの価値があるか、それほどコストを払ってまで落としてはいけないものなのか、と葛藤に陥るものもあるようです。

 

同じような障害を起こさないようにするには、サービス規約で障害で落ちることもあることを書いて、ユーザーに理解してもらい、担当者では、マルチAZを導入しておいて、いつでもAWSから他のサービスに移行できるよう、GCP、Azure、AWSどこでも使いこなせるように学んでおく必要があります。

 

今現在AWSしか使っていない場合は、早いうちにGCP、Azureなどの大手のクラウドサービスを使えるように学びましょう。担当者の使えるサービスをマルチ化して、マニュアルを作っておくのがサービスとしての強さになるでしょう。

 

また、エンジニアとしてはどのサービスでも使えることがスキルの証明になるので、導入方法を学んで、簡単なサービスでも、WordPressでも良いのでそれぞれの環境で実装できるようにすれば実力が高まるはずです。日頃の準備と学習と対策があれば、障害に負けることはおそらくないでしょう。

 

GCPもAWSもAzureも全てダメになる時は、おそらく世界が終わるときか、核戦争をしている時か、エンジニアが発狂した時ですので、念の為、全てに備えたい場合は核シェルター内で、自己電源で運用する自宅サーバーを作るところまで考えれば最強でしょう。

 

そこまでできれば、外部のクラウドサービスに頼らない、完全独立の安定サービスとして、それそのものがクラウドサービスを提供できるくらいの力・実力・スキルを持つことにもなります。

 

コメントを残す

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

CAPTCHA