2016年04月21日

事例:ANAシステムトラブル


初めての方はこちらを「はじめに

先日、三月に起きたANAのシステムトラブルについての詳細な記事が上がっていたので、今回は趣向を変えて実際の内容を具体例として信頼性について考えてみたいと思います。
ただしANAのシステムに対しての意見ではなくて、あくまで自分の持つ信頼性という考え方を説明する為の材料としてこの例を利用するに過ぎません。そもそもこの様なシステムの設計を担当した事は無いのでシステム自身については推測で書いている部分もありますし必ずしも正しくない部分もあるかもしれません。しかしそこが主題なのではなく「信頼性というのはこういう考えなのではないだろうか」という話です。

記事:記者の眼 - 判明、ANAシステム障害の真相:ITpro

システムの概要と現象


記事の内容から今回の話に関係がある部分にフォーカスした自分なりに理解したシステムの概要と現象を述べます。

構造

53N004_002.jpg
四角で囲ったもの(以降ブロックと呼ぶ)は物理的に何かがあるというよりは基本的には概念でまとめた抽象的な構造を表しています。システムに関わった事が無くイメージが掴みにくい人にとっては一つのブロックが関数だと考えても差し支えないと思います。ブロックの中のブロックは関数から呼び出される下位の関数というイメージになります。

一番大きな括りで見ればアプリケーション(AP)があってデータ(DATA)を読み書きするというソフトウェアの普遍的な構造と見なせます。それぞれのブロックの内容は以下の通りです。
AP:実際の予約とか発券とかのアプリケーションの総体
DATA:APのデータを受け持つ所
DB:データベース
CTR:下の#1~#4を管理する部分
#1~#4:物理的な四台のデータベースサーバー
NET: DATA内でのネットワークを専用に受け持つ所
スイッチ:物理的に複数のネットワークを繋げる機器。予備機(#B)もセットされています。
ストレージ:実際にデータを格納しておく所。物理的にはハードディスク。
MNG:全体を監視して適宜制御する部分。記事中では「運用管理システム」と称されています。

動作

APから来たデータはDBの中では性能確保等の目的で#1~#4の四つで分担して処理をしています。#1~#4はバラバラに処理をしているので四つの間で不整合が発生しない様にNETを介して通信し合ってお互いに常に同期を取っています。(図中の青線部分)

現象

結論から言うとスイッチが壊れたという事らしいです。
システムの設計的にはスイッチが不良を起こすと自分でエラーをMNGに通知します。そして通知を受けたMNGがスイッチを、故障した#Aから#Bに切り替えるという事らしいです。
53N004_003.jpg
しかし今回起きたのはスイッチ(#A)が正常に動作しなくなったのにエラーの通知が出なかったという事らしいです。エラーが通知されなかったので切り替えが成されずに#Aが使われ続けました。#Aはまともに動かないのでDBの#1~#4の間の通信がエラーになってしまい四つとも相次いで自動的に停止。DBの停止は仕様通りなのでスイッチの単独犯という事になります。

信頼性についての考え方


システムがダウンしない事に対する自分なりの信頼性の考え方を述べてみたいと思います。

機械的な判断

記事の中ではANAの対応が非常に早くてネットでもそういう声があったという評価をしています。その一方で記事の終わりの方ではあるベテラン(?)の意見として大規模システムとしては何度か経験する事であり仕組みが足りないという意見を取り上げています。
ここで着目したいのは評価がどうなのかという事ではなくて現場の意見として高い信頼性の拠り所が経験になっているという点です。自分自身はニュースになる様なトラブルの経験はありませんが、今回の様なシステムのトラブルに限らず原発等の世の中一般の事故のニュースに触れる度に「どうしたら防げたのか?」「何が問題だったのか?」という事をいつも考えてきました。考えた結果として信頼性というのは計算できなければならないのではないかと思えています。また、実際に計算できるのではないだろうかという思いもあります。どこまで計算可能かは別にしても、考え方の方向性としては設計時の指標として機械的に判断できるものを目指すべきなのだとは思います。

抽象的な構造

一般的なのかどうかは分かりませんが信頼性を判断するベースとして大事だと思っているのは上の構造図で示した様な抽象的な構造の設計だと思っています。何故かというと抽象的な構造の単位で考えると漏れが無くなるからです。例えばAPとDATAという二つのブロックの視点で対策を考えればそれだけでシステム全体を100%網羅している事になります。どこにも抜けはありません。

想定外という事

ちなみに信頼度という指標自体は世の中に存在しています。しかしそれは簡単に言えば部品の故障率からシステム全体が正しく動く確率を求めるようなもののようです。これだと元になる故障率が何かしら過去のデータに依存する事になると思うのですが、今欲しいのは言うなれば想定外を見積もる指標という事だと思います。想定外という事は過去の実績とかスペックとかの想定している範囲の外の事なのでそれらの内容は全く意味が無いという事になります。という事は内容には依存しないので考えても仕方が無く、対象のブロックが丸々駄目になる事態を考える以外に無いように思えます。従って信頼性を確保するという事は対象のブロックが駄目になった時に代替手段が用意されているかどうかという事だと思われます。

信頼性が確保された姿


この様な考え方で今回の件を考えてみたいと思います。
まず問題となったスイッチですがここは二重化(#A、#B)されていて代替手段が用意されているように見えます。しかし先程説明したように信頼性の確保は対象ブロックが駄目になった時に代替手段が用意されているかという事なので、仮にスイッチ#Aが駄目になった場合を考えると何も起きないで、#Bには切り替わらないので代替手段が用意されているとは言えません。対象ブロックが駄目になるという状態では対象ブロック自身には何も期待できないので、DB部分の様に必ず「外側から管理するブロック」が必要になると思われます。NET部分にはこの管理部が存在しません。よって信頼性が確保できていないという考え方になります。

では信頼性が確保された姿というのはどの様なものになるのでしょうか?
NET部分は実際はハード的な機器の集まりなのでデータベースサーバーの出力部分に管理ソフトが噛む様な形なのかもしれません。
53N004_004.jpg

もしくはNET内部の二重化は諦めてNET自身を二重化してDB部分側で切り替えを担当するという形なのかもしれません。具体的にはDBからNETへの出力でエラーが発生した時に何かしらの処理で切り替えるという事だと思われます。
53N004_005.jpg

ただ、いずれにせよストレージ部分を考慮に入れていないですしこんな簡単な話では無いのかもしれません。あくまで考え方という話です。

信頼性を計算で弾き出せるようにする為には


上記のような考え方で少なくとも設計の見通しは良くなるように思えるのですがどうなのでしょうか?
仮にそうだとしてそれではこれで「完全に安全」なのでしょうか?
勿論違います。
単純な話、二重化したとしても二つとも駄目になる可能性があります。では三重化すれば良いのでしょうか?
勿論二重化の時よりは安全になるでしょうがやはり三つとも駄目になる可能性はあります。もしくは幾ら多重化をしたとしても管理部が駄目になると全て駄目になります。その場合は親のブロックを二重化していないと駄目になります。どこまで行っても100%はありません。
そう考えると、もし100%を確保しようと考えたら最後の代替手段としては必ず人が手動で対処可能になっている必要があると思われます。設計時のブロックのどこかに「人」が組み込まれる事になるのだと思います。とは言っても全ての処理が必ずしも人で代替できるとは限らないかもしれません。そうなると結局どこで妥協するかという話になります。そしてどこで妥協するかという点を見つけ出す為には発生確率と対応コストから投資効果を判断する必要があると思われます。コストはまさしくかかる費用なので割り出せるとして、発生確率は問題です。ここでいう確率は「想定外に駄目になる」確率だからです。つまり今までは想定内の事に対する確率で判断してきたものを想定外も含めた確率を計算して判断するという事なのかもしれません。
想定外の確率などというものが計算できるのでしょうか?
正直分かりません。分からないけれども信頼性を完全に計算可能なものにする為には避けて通れないように思えます。
機会があったら検討してみたいと思います。

一覧


メニュー

関連


事例:ボーイング737MAXの墜落事故
事例:天文衛星「ひとみ」の事故


記事を広める



posted by 善 at 17:57 | Comment(0) | TrackBack(0) | 事例 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック