全銀ネット障害、メモリー不足が要因 事前テスト甘く
コメント
注目のコメント
うーん、、、失礼ながら、システム開発を実際にされた経験がない方からするとそんなテスト簡単だろ？とお思いだと思いますが、大規模システムにおいて本番環境と同じトランザクションを発生させてテストすることはかなり難易度の高い試験です。
私はネットワークエンジニア時代に新機種に対して負荷試験を行い、実測の性能をテストしておりましたが、性能テストというのは、機器の性能限界までのtpsを生成することが簡単ではありません。一般的には、ラボで同等の負荷をかけるわけですが、パケットジェネレーターのようなテスト専用機で負荷を発生させた上で試験を行うので、本番と全く同じ条件ではないため、特にメモリ周りのようなプログラムの条件によって扱いが変わるパラメータの試験を網羅することは難易度の高い試験だと言えます。
また、DDoSのような外部からの攻撃に対しては、そもそも全銀は開放されたシステムではありませんので、想定するリスクとしては不適切です。システミックリスクの観点で、接続先システムの設計不備によるメモリに対する悪影響等はあり得るかと思いますが、全銀接続の試験難度からすると、試験で露呈しないレベルではないのかなと思います。今回は、RC切り替えという新規システムに対するリリースであったため、起きた不備であり、全銀システム全体において起こり得る事象では無かったのかなというのが、金融SIの端くれにいた人間の所感です。
あ、ただリリース日をトランザクションの多いことが想定される5 10日前にした理由は私にははかりかねますが、全銀システムの規模となると、もはや、L8ならぬ政治レイヤーの事由かもしれませんね。
ちなみに、復旧方法はロールバックではなく、問題のあった処理をスキップするパッチ適用によるものであると報道されております。
https://xtech.nikkei.com/atcl/nxt/news/18/16084/オフトピですがウォール街の金融機関の多くもCOBOLで開発されたシステムに依存しており頭を抱えているというFortuneの記事がちょうど昨日ありました。
Wall Street’s ‘Cobol Cowboys’ are spread thin fixing legacy tech—but AI may soon ride to the rescue
https://newspicks.com/news/9049491
ここで紹介されているウォール街の企業がシステムトラブル時に駆け込むのがテキサス在住の82歳が指揮する高齢COBOLエキスパート600人からなるコンサルタント集団"Cobol Cowboys"。
会社のモットーは「初めてのロデオじゃない」(Not our first rodeo = 経験豊富)
かっちょいい。大変でしたね。お疲れ様でした。
報道その他含め、いろいろコメント出てる中でちょっと言わせて頂くと、メモリの見積りが甘いという批判は個人的には本当にそうなのか？と疑問です。
まず、よくCOBOLで書かれてるとか言われますが、本当の中心部だけという話で、周辺プログラムはjava等が使われていると聞いてます。さすがに中継コンピュータでCOBOLを使ってるとは思えない前提で話してます。
メモリが明らかに不足してるか、明らかに余計に積んでるかは判断できます。
あと、コードを一生懸命追えばめちゃくちゃメモリ効率悪いコードが存在している事も解るでしょう。
が、メモリの見積りって古の低級言語ならまだしも、高度な仮想マシンや中間言語、インタプリタが主流の現在においてどれだけの精度でやれるんですか？というのはめちゃくちゃ疑問ですけどね。
大前提としてご存じない方もたくさんいらっしゃるかもしれませんが、現在のシステムは自分達が書いたコード以外のコードの方が圧倒的に分量が多いんですよ。
オープンシステムとそうでないものでOSの振る舞い等も違いますが、JVMや.NETやMonoや各種LLのインタプリタがどの程度メモリ展開してどのタイミングで解放するかとか、現在の高度なランタイム環境でそんな精密に見積もれる人って全世界的に見てもどれだけいるんでしょう？って話と、いちいちそんな事やってたらめちゃくちゃ開発効率悪いのでは？
粗悪なコードは様々な方法で排除すれば良いと思いますが、現実問題メモリの使用量は想定されるデータ量の変化を複数パターン流してプロセスを監視してメモリ使用量の変化を見て不足してるか十分かを判断するしかないと思いますけど。
ついでに言わせてもらうと、全銀みたいなある程度クローズドなシステムに対してDDoS含む不正な大量アクセスをケアしなければならないという事はないのではと思ってます。まずシステムにリーチできないでしょう。
