【メルマガ】みずほ銀行 ATM障害等の報告書にもある、システムアーキテクチャに関して(2021年09月07日)

2021年2末〜3初にかけて発生した、みずほ銀行 ATM障害等の一連のトラブル。

6/15に、システム障害特別調査委員会の調査報告書が公表されました。

みずほFG：システム障害特別調査委員会の調査報告書の受領について

2021年6月15日付のニュースリリース「システム障害特別調査委員会の調査報告書の受領について」を掲載しています。…

かなり濃い内容であり(167ページあります)、内容自体もしっかりしています。
また、社会的影響も大きかったことから、報告書を読んだ識者のコメント等も多数あります。

障害の原因や問題点は散々指摘されておりますので、ここでは特段触れません。

今回は「システムアーキテクチャ」に関して、自身の経験も含めてお伝えしたいと思います。

※上述報告書より、すでに大きな障害をプラス2件起こしていますが、本文の本質とは関係ありませんので触れません。

システムアーキテクチャとは？

※話を簡単にするために、正しくは説明しておりません。ご了承ください。

「システムアーキテクチャ」とは、そのシステムを作っていく「基本思想」のようなものです。

今回、みずほのMINORIでは、「SOA」というアーキテクチャを採用しています。
「SOA」とは、「サービス指向アーキテクチャ」を指します。

「SOA」では、「サービス」＝「機能」ごとにシステムを作り、独立性を持つようにします。
独立することで、システム影響範囲や責任範囲をコンパクトにすることが可能になります。
大規模なシステムにおいても、システム開発スピードの向上や効率性、保守性の向上が期待できるというわけです。

SOAなのに、なぜ大規模障害に？

SOAは、各機能の関係性を「疎結合」にします。

MINORIもしかり、ですが、今回のATM障害では、裏で処理していた口座の切替処理が、ATMやネット等の他チャネルに波及しています。

私も「MINORIってSOAで見事に作りきったのでは･･･？」と思っていましたので、ニュースを見た時の影響範囲には驚かされました。

様々な影響を引き起こした原因は、データベースにあります。

機能毎に分割する、というとシンプルに見えますが、実際は難しいものです。
それは「データは1箇所に持つしかない」ためです。

データベースでの異常発生が、そのデータを利用する様々な機能に波及してしまうのです。

「SOA」がダメというよりは、どのように機能分割設計をしていくか、が大事なポイントですね。

※トランザクションやロック、といったお話をすると長くなりますので、割愛いたします。
※また、今回の障害ケースを正しく書こうとすると膨大な量になりますので、詳しくは報告書を参照ください。

アーキテクチャの維持は「困難の嵐」

さて、話は変わりまして、例えばその「SOA」の状態を維持していくことについてです。

こういった考え方を守っていくには、実は相当大変です。
システムは「やりたいことを実現するシステム実装の方法は、なんとでもなることが多い」ためです。

「SOA」では、「その処理はA機能の1種なので、A機能に追加すべし」といった判断が必要になります。
しかし、これが様々な要因で崩れていきます。

• そのシステムアーキテクチャを理解している人でないと判断できない。
  組織は人が変わっていくため、継続していくには相当な工夫が必要。
• コスト的な要素もあります。考え方からはNGだが、別の機能に実装した方が安くつく。
• 担当者が、他者と調整するのを面倒がって、手の内で作ってしまう。
• 開発ベンダー側の思惑や、体制確保、スケジュールなどに左右されることもあります。(正しい場所に作ることができない)
• 「とりあえず暫定的にここに作成して、後で正しい場所に作り直す。」
  「後」というのは、システム廃止に至るまで、まず来ません。
  下手をすると、次のシステムにそのまま移行されてしまう可能性もあります。

私も前職、大規模システムを見ていましたが、このような「思想を壊す人たち」とよく戦っていました。

※様々な背景もあるため、「全てノー」と言っていたわけではありませんが。

もちろん、ビジネスのためのシステムですので、システム都合最優先で最善を作っていくわけにはいきません。
しかし、この考えは、必ずシステム崩壊をまねきます。
徐々にシステムメンテナンスのコストが拡大していき、考慮不足・影響調査不足といったシステム障害が増えるでしょう。

どのように維持していけるかは、決裁権をもつ人間次第。
経営レベルでアーキテクチャを守っていく必要があるでしょう。

むしろ、現場の人間は「その場がうまくいけばよい」が基本スタンスだと思います。

MINORIも、少なくとも10年は使い続けるでしょう。

どこまで構築時の設計思想を守っていけるか。
それが、今後の障害発生の頻度にも表れてくるでしょう。

バックナンバーを見る