aki_iic’s blog

己の欲せざる処人に施す事無かれ、狂人の真似するは即ち狂人なり

RC23

 全銀システム障害の解説。impress watchより、例のマイナンバー関連記事書いた人です。

www.watch.impress.co.jp

 少々長いが重要なので引用、詳細は上記記事参照。駄目テックの記事見てない(出ているかすら知らない:)が、この人の記事は専門性があり、まともな記事で且つ解りやすい(実務経験踏まえた知見と解説だろう)のでスラスラ読める。そういえばリレーコンピュータは定石かもしれないが、最初に知ったのはあのみずほ統合システム障害での各行接続したリレーコンピュータであった:)

impress watchより引用)

障害を起こした全銀システムの仕組みと流れ

全銀システムは1973年に運用を開始した、銀行間での内国為替取引を中継してオンライン処理するための「インターバンク・システム」と呼ばれるものだ。大量の取引データをオンラインでやり取りしてリアルタイム処理できるという点では世界的に見ても大規模な仕組みであり、これまでほぼ8年周期でシステムの刷新が行なわれてきた。

現在は2019年に稼働を開始した第7次システムであり、次の更改タイミングとなる2027年に向けて順次切り替えが行なわれていたタイミングでの障害だった。なお、全銀協などによれば顧客取引に影響が出るレベルでの障害は運用開始以来初の出来事ということで、その点がクローズアップされたのも今回の特徴といえる。

全銀システムの更新の歴史(全銀協の資料より抜粋)

下図は、全銀協が「次期全銀システム」と呼ぶ第8次システムの構成概念だ。全銀システムに参加する金融機関は各々が勘定系の基幹システムを抱えており、「RC」と呼ばれる中継コンピュータ(Relay Computer)を介して全銀システムとネットワーク接続される。今回障害が起きたのはこのRCの部分で、RCに搭載されたソフトウェアの不具合が原因となって発生した。

「次期全銀システム」こと「第8次システム」の構成概念図(出典:全銀協)

図表の用語解説をしておくと、「テレ為替」というのは1件1件振り込み指示を行なう都度送金の仕組みで、「新ファイル転送」とはこうした複数の送金指示をまとめてファイル化することで一気に処理を流す仕組み。用途に応じて使い分けられる。

前述のように、今回の障害の発端となったのはRCの部分であり、第7次から第8次システムへの移行過程での機器のリプレイスによって発生している。全銀協ではこのリプレイス作業を「レベルアップ」と呼んでいるが、第7次システムでは「RC17」と呼ばれていたものが、第8次では「RC23」となっており、機能面の拡充や柔軟性の強化、それと同時に使われない機能の簡素化なども行なわれている。

“レベルアップ”作業は年4回の実施が計画されており、第8次への移行過程の第1弾となるRC23へのリプレイスが行なわれたのが10月7日から9日の3連休のタイミングとなる。

金融機関14行でのリプレイス終了後、10日朝の営業時間開始のタイミングで11行の取引が正常に行なわれていないことが判明し、障害発生の報が打たれた……という流れだ(正確にいうと障害が発生していたのは10行だが、詳細は後述)。

筆者はRC17とRC23の違いについていろいろ調べていたが、両者の変更点をまとめて可視化できるほどの情報を得られなかったため、現時点で判明している2つのポイントで両者の違いを見ていく。1つは下図にあるように、RCの配置に特徴がある。2027年から先の第8次システム以降の話題にも絡むため、詳細は後述するが、これまで参加行側に“アプライアンス”装置として提供されていたRCが、RC23では全銀システム側に置かれる形になった。

全銀システムへの接続要件が「IP-VPNの閉域網を介してRCを中継する形で各行の基幹システムを全銀システムへと接続する」となっていたものが、RCそのものは全銀システムに接続するための閉域網(ネットワーク)の向こうに置かれるため、(推測になるが)参加行の運用管理負担の軽減につながるとともに、将来的な“RCの廃止”への布石となっている。

第7次から第8次システムへの移行期間における接続概念図。今回のトラブルはこのRC23側で発生した(全銀協の資料より抜粋)

RC17とRC23の違いの2つめは、今回の障害の原因となった「内国為替手数料のチェックプログラム」の存在にある。これまで全銀システムを介して銀行間のやり取りで発生する手数料については電文の種類に応じて「62円」などの一意の金額が割り当てられていたが、RC23のタイミングではこの金額に柔軟性を持たせるべく、異なる計算手法を導入している(“料金テーブル”のようなものを参照すると思われる)。ただ、問題の洗い出しの過程でRC23へのリプレイスが行なわれた14行でも障害の発生した金融機関とそうでない金融機関における違いを精査したところ、当該機能を利用しているか否かの部分が分かれ目だったため、11日の時点でいったん「すべての手数料を0円にする」形でRC23のプログラムを書き換え、オンラインでの処理が流れる形にすることで問題を解消する方法を選んだ。ここで行なわれなかった手数料計算は後ほど集計の形で処理される。

先ほど、「実際に障害が発生したのは11行ではなく10行」と記したが、この部分について用語解説を含めて少しだけ補足したい。対象行の数が減ったのは、当初数としてカウントされていた「JPモルガン・チェース銀行」では影響がなかったことによる。

(引用おわり)

 連休中の作業によるシステム更新に起因、最終的なシステムに向けての逐次的作業の一環、は過去の事例とも共通する点がある様だが、原因がソフトウェアのバグだったのは後知恵ではあるがシステムの検証不足と言え、その意味では金融庁が偉そうに報告を求めるのもその社会的影響度を踏まえるに妥当なのだろう。

 これらの情報から個人的に言える事は上記技術的内容とは全く関係無くて、

駄目テック、要らない(スッキリスッキリ)。

でありました:)