今日（2021/9/1）は、AWSで障害が起き、かなりの会社が巻き込まれて話題になっていました。
米アマゾン・ドット・コムのクラウドサービス「アマゾン・ウェブ・サービス」（AWS）で2日、障害が発生した。複数の証券会社や大手銀行のアプリなどで接続しにくくなったほか、NTTドコモで一部サービスが利用しづらい事象が起きた。全日本空輸（ANA）や日本航空（JAL）でも不具合が生じ、影響が広がった。
この前のみずほの件と言い、システム基盤の問題が国民生活に影響を与えることが顕在化し、問題意識も高まっていますね。
今回の問題は「コアネットワークデバイスに問題が発生」という表現で語られているのですが、一般の人々や、インフラに関わったことのないIT業界の方は、こう思うのではないでしょうか。
「壊れたのなら、新しいハードウェアを持ってきて交換すれば、動くでしょ。それができないっていうのは、保守体制がおかしいんじゃないの？。交換部品を用意していないとか、交換する人員が不足しているとか。気が緩んでるんじゃないの？。」
この手の種類の不満はよく聴きました。保守担当者側としては、
「ま、コンピューターなんで、新しい部品を交換するだけじゃ動かないんですよね。複雑な設定も中に入っているし、交換する機器にはそれを移し替えなきゃいけないし、配線も元に戻さなければいけないし、復旧作業も手順があるのですぐにはできないんですよ。もちろん、すぐに作業は始めてるんですが、時間はかかるのでご承知ください。」
打ち返しとしてこれでいいとしても、それなら・・というので数時間は待ってくれるのですが、実際はもっと復旧に時間がかかる場合があります。
なぜ時間がかかるのか。みずほ銀行の場合も前日の夜に発生したので、翌朝の開局には間に合うと思っていたけど間に合わなかった、ですよね。
ここは、直接今回のAWSやみずほとは関係なく、時間がかかる障害対応のケースが１つあるので紹介しておきます。
「性能問題」です。
機器の性能限界を超えた要求を、システムが要求した時に起こります。
システムを構成するネットワークの中に、ある機器があったとします。システムが正常に動くためにはこの機器を通ることが条件だとします。とすれば、この機器、必ず何らかの方法で冗長化しますよね。例えば2台構成にする。そうすれば1台が停止したとしてももう1台が処理してくれる。
単純なハードウェア故障ならそれでもいいのですが、性能問題の場合はそうはいきません。動いている方（アクティブ機）と、待機している方（スタンバイ機）、両方の機器は性能が同じだからです。
アクティブ- スタンバイの関係の場合、アクティブが性能上限のため停止します。そうするとスタンバイに動作が切り替わります。しかし同じく性能上限で停止します。そしてもともとアクティブだった方に切り戻るのですが、全く同じことが起こり、シーソーのようにギッタンバッタンするのです。
この場合、機器自体は壊れていません。だから交換しても無駄なのです。
この話を顧客にすると、必ずこう言います。
「もっと性能の上の機器に交換できないの？」
しかし、保守というのは、壊れたら新しい機器に交換するというのが原則です。家電だって壊れて保守期間内だからってお店に持って行っても、グレードアップはしませんよね。
どうするかというと、ベンダーに、至急性能の上の機器を購入できませんか？、と緊急に相談します。もし在庫があればいいのですが、この機器の購入費用は当然かかってきますので、コストを払ってでも障害対応を優先するかどうか、ここでビジネス上の判断が必要になってきます。
昔私もそういう目にあったんですが、「上位のモデルはあるにはあるんですが・・・、今イスラエルにしかモノがないんですよ・・。空輸したとして・・。」みたいな話をされて驚愕したことはあります。だって、すぐに対応したいのにイスラエルとは！！？。
さて、性能問題を機器のグレードアップで回避できない場合や、すぐにでも復旧させなければいけない場合どうするでしょう。それは、システムの構成見直しです。性能上限を迎えるということは、何かの処理で高い負荷がかかっているのかもしれません。システム全体のトランザクションを見直し、ソフトウェア側の設計変更で逃げられないか考えます。インフラ担当もアプリケーション担当も、ここで頭をひねります。例えば、ある処理だけその機器を通さずに、同じ性能の別の機器を取り寄せて、そちらを通せないか。負荷分散で性能問題を一時的に解決するというのはよく使う手です。
でも、障害対応の途中でシステムの設計全体に手を付けるというのは、実は究極の選択だったりします。構築中はちゃんと設計図を書いて、実装して、テストをして、ようやく本番リリースします。しかし本番運用中のシステムにおいては、スピード重視のため準備に時間が欠けられません。いわゆる「火消し」と言われる人は、このあたりの判断を天才的に切り抜け、鎮火したときに崇められます。
ということで、性能問題による障害対応の難しさを話してみました。これ、じゃあ性能問題が起こらないために、性能試験はやらないの？と言う話は必ず出ます。いや、やります、性能試験。しかし、構築時の性能試験はあくまでも、机上の数字であり、データも本番データとは違います。本番時にどんなデータがどのように流れるかは、時間とともに変わっていくので、試験は通っていたけれども想定していない形で機器の性能上限を超えてしまった、というのはよくある話です。
この手の問題は、「過去安定していて実績のあるシステム」に実は起こりがちです。安定しているからこそどんどんシステムは肥大化していく。肥大化していった先に、ある場所に偏って負荷がかかっていって、ある日顕在化します。しかしもう増やしてしまったシステムはおいそれと取り除けない。
だんだんと大きくなっていくシステムは、ぜひどこかにシングルポイントとなる場所がないかどうか点検すべきでしょう。そこが冗長化されたとしても、両系が性能超過してしまったら手が付けられません。性能を超えないように、システムを分割して使うようなことを初めから考えるべきでしょう。
インフラ基盤の問題は、ハードウェア交換すれば治る障害ばかりじゃない、というお話でした。
