全銀システム障害の原因判明、メモリー不足でインデックステーブルが不正確な状態に
銀行間送金を担う「全国銀行データ通信システム（全銀システム）」で2023年10月10～11日に発生した障害の原因が10月16日、分かった。全銀システムと各金融機関のシステムをつなぐ中継コンピューター（RC）において、メモリー不足に起因し、金融機関名などを格納したインデックステーブルに不正な値が紛れ込んだ。 インデックステーブルはRCのディスク上にあるファイルから展開する。このファイルを作成するプログラムを実行したタイミングで、一時的に確保するメモリー領域が不足し、ファイルの内容が不正確になったという。 全銀システムの障害を巡っては、三菱UFJ銀行やりそな銀行などで他行宛ての振り込みに遅れが生じた。全銀システムを運営する全国銀行資金決済ネットワーク（全銀ネット）によると、概算値ながら10月10～11日の2日間で仕向けと被仕向けを合わせて500万件超の送金に影響が出たとしている。
みずほと富士通がシステム開発に生成AI、品質向上を狙った業務とは
みずほフィナンシャルグループ（FG）は2023年6月、富士通と共同でシステム開発・保守における生成AI（人工知能）の利用を目指した実証実験を始めると発表した。システム開発および保守に関わる品質や、障害が発生した際の迅速な復旧（レジリエンス）力の向上を狙う。 「IT人材の不足が叫ばれる中、5～10年先に現在のようなシステム安定稼働の体制を維持できるのか」。みずほ銀行の山口和哉ITシステムグループ副CIO（最高情報責任者）は、危機感をにじませる。将来にわたる課題に対応するため、いち早くノウハウを吸収するべく手を打ったのが生成AIの活用だ。 具体的にはシステム開発段階において、設計書のレビュー業務を生成AIで支援する。過去のレビュー表やレビュー観点のノウハウを基に、生成AIが設計書の記載間違いや漏れを自動検出し、開発品質の向上を目指す。 「MINORI」の一部システムが対象 第1段階では、みずほ
橋の設計ミスで工費3倍に、工期は4年半延長
長野県が建設を進める国道148号雨中バイパスの新柳瀬橋（小谷村）に設計ミスがあり、上部工の工費が当初の6億6200万円から22億6900万円に膨らむことが分かった。再設計の結果、材料費がかさんだ他、仮設費が増大した。2021年1月までだった工期は25年8月まで延長した。
「みずほe-口座」のデータ更新45万件が重なりメモリー不足、みずほ銀行システム障害
みずほ銀行で2021年2月28日に発生したシステム障害を巡り、同行は3月4日、通帳を発行しない「みずほe-口座」関連のデータ更新処理が発端になったと明らかにした。定期預金関連で定例のデータ更新のほか、1年以上記帳がない口座を自動的にみずほe-口座に変更する約45万件の不定期処理が重なり、定期預金コンポーネントでメモリー容量不足が発生した。 みずほ銀行は2021年1月18日から、みずほe-口座の取り扱いを始めていた。それに関連し、2月下旬から3月上旬にかけて、1月末時点で1年以上記帳がない口座をみずほe-口座に段階的に変更する予定だった。2月28日はこうしたみずほe-口座への変更処理の約45万件に、定期預金の積み立てなど定例の処理も含めた合計で約70万件のデータ更新を予定していた。 この約70万件の処理でメモリー容量不足が発生。その結果、定期預金関連の取引ができなくなり、さらにピーク時で7割
AWSがKubernetesサービスを半額に、1時間0.1ドル
米アマゾン・ウェブ・サービス（Amazon Web Services）は2020年1月21日（米国時間）、コンテナ群を管理する「Kubernetes（クーバネティス）」のマネージドサービスである「Amazon Elastic Kubernetes Service（EKS）」の料金を半額にしたと発表した。Kubernetesクラスターごとに1時間当たり0.2米ドル（約22円）を同0.1米ドル（約11円）に値下げした。
50自治体システム障害はIaaSで使うソフトのバグが原因、復旧メド立たず
12月4日に発生した東京都中野区など約50の自治体のシステム障害で、12月5日も住民票の発行やホームページの閲覧などができない状態が続いている。原因は各自治体が利用している日本電子計算のIaaS「Jip-Base」にシステム障害が発生したため。現状で復旧のメドは立っていない。 4日の時点ではディスク故障が原因とされていたが、詳細が分かってきた。2019年12月4日午前10時56分に同社のシステムにアラートがあがり、システム障害が発生した。調査したところストレージ装置のファームウエアにバグがあり、ディスクの読み書きができなくなったためだった。 各自治体の障害の影響範囲については、「自治体ごとにIaaSを利用しているシステムが異なるため一概には言えない。明確になり次第お知らせしていく」（日本電子計算 広報）とした。11月23日にもQTnetのデータセンター障害で福岡県庁のシステムが一時的に利用
AWS大障害、冗長構成でも障害あったと公式に認める
米アマゾン ウェブ サービス（Amazon Web Services）は2019年8月23日に発生したクラウドサービス「Amazon Web Services（AWS）」東京リージョンの大規模障害に関して同月28日、新しい報告をWebサイトに掲示した。障害が発生したサービスを追加したほか、利用企業が複数のアベイラビリティーゾーン（独立性の高いデータセンター群、AZ）横断の冗長構成にしたシステムにも一部で障害（予期せぬ影響）があったと認めた。 障害が発生していたサービスとして追加したのは日経 xTECHの既報の通り、アプリケーションロードバランサーの「Amazon ALB」、インメモリーキャッシュの「Amazon ElastiCache」、データウエアハウスの「Amazon Redshift」、仮想デスクトップの「Amazon Workspaces」などだ。仮想マシンの「Amazon EC2
Oracle DBの「非公開バグ」が表面化、大阪市基幹システム障害の真相
大阪市で住民票などの証明書発行業務を担う基幹システムが停止。復旧まで21時間を要し、8000件近い証明書発行業務に影響が及んだ。原因はOracle Databaseのクラスタ機能に潜むバグだった。ネットワークの不調をきっかけにシステムが停止し、再起動もできなくなった。米オラクルはバグの存在を把握しながら対外開示をしていなかったとみられる。 2019年6月7日午後0時5分頃。大阪市内の24の区役所や出張所、梅田・難波・天王寺のサービスカウンターで、住民票の写しや記載事項証明書、国民健康保険や税務関連の証明書などが印刷できなくなった。金曜日の昼休みということもあり、週内に書類を発行してもらおうと区役所など窓口に来ていた住民からは悲鳴と怒号が上がった。 同じ頃、大阪市西区の阿波座にある大阪市ICT戦略室も騒然としていた。システム障害を知らせる警報が鳴り、各区役所からトラブル発生を知らせる電話が相
Oracle DBのバグでファイル破損、大阪市がシステム障害の原因を初公表
システム障害を起こしたのは基幹系システム「大阪市統合基盤システム」である。2015年1月に運用を開始し、住民票や税務、国民健康保険、福祉、介護保険など市民向けサービスを提供している。 同システムのOracle Databaseはログイン時の認証に必要なデータや印刷履歴などを管理している。今回の障害により、区役所や出張所などで住民票などの発行ができなくなり、7994件の発行業務に影響が出た。 同システムで2019年6月7日の午後0時5分ごろに発生したシステム障害では、2ノードあるDBサーバーがほぼ同時に停止した。担当者が再起動を試みたが再起動できなかった。 この原因について大阪市ICT戦略室は「Oracle Databaseには（データを格納するストレージとDBサーバーをつなぐ）通信経路で伝送エラーが生じた際、システムファイルが破損するバグが存在していた」と明かす。システム開発を担当したNT
みずほ銀行がアジャイル開発に挑戦、技術者30人は「俊敏」になれたのか
新しい勘定系システム「MINORI」の全面稼働を1カ月後の2019年7月に控えるみずほフィナンシャルグループ（FG）。2011年に3つの勘定系システムの刷新・統合を決め、4000億円以上を投じた世界最大級のプロジェクトがゴールを迎えようとするなか、慣れ親しんだウオーターフォール型開発から脱却し、業務システム開発でもアジャイル開発を採用しようとする動きが出てきた。 「IT構造改革の名の下に、2018年からパブリッククラウドの活用やテストの自動化、ノンコーディングツールの導入、アジャイル開発の採用などが進んでいる」。みずほ銀行の福島亮一IT・システム統括第二部市場系システム推進チーム次長は「MINORI後」に向けた新しい取り組みをこう話す。 50人のトレーダーを支える操作画面、超高速開発とアジャイルで刷新 成果の1つが2019年9月に稼働を予定する、外国為替予約システムのWebフロントエンド（
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
マイクロサービスの最難関、どうするDB分割？
「マイクロサービスアーキテクチャー」はどれくらい世に広まっているだろう。小さなサービスを疎結合に組み合わせ、一連のアプリケーションを構成するマイクロサービス。ソフトウエアの改変しやすさに強みがあり、米ネットフリックスや米アマゾン・ドット・コムといった、サービス改善のスピードを突き詰めたいネット企業を中心に導入が進んできた。 日本でも活用事例は増えている。日経SYSTEMSの特集記事「マイクロサービスの現実解」では、全日本空輸（ANA）や楽天トラベル、モノタロウなどを取り上げた。メリットが大きい半面、特に既存システムからの移行は一筋縄では行かないという印象だ。マイクロサービスの難しさを考えてみたい。 従来型システムに比べたマイクロサービスのメリットは明らかだ。現在主流のWebアプリは、プレゼンテーションと業務ロジック、データアクセスの3レイヤーを一体で開発するのが一般的。こうしたモノリス（一
クラウド移行を阻むネットワークの「3つの壁」
国内では2000年代後半から多くの企業がクラウド化に取り組みはじめ、今ではクラウドの利用が一般化しつつある。その理由として、クラウドへの移行手法が確立してきた点が挙げられる。 クラウド移行の手法で最も分かりやすいものが「リフト＆シフト」である。オンプレミスで利用しているシステムをそのままの構成でクラウドに移す手法だ。システム構成を変更せずに済むためコストを最小化できるところがメリットである。だが、オンプレミスと全く同じ構成を踏襲できない部分がある。それはネットワークである。 クラウド移行には、ネットワークの「3つの壁」がある。 ●「物理と仮想のネットワークの考え方の違い」 ●「クラウドネットワークの詳細仕様の難しさ」 ●「閉域接続の難しさ」 これらを越えられずにクラウド移行に失敗するケースは少なくない。逆にうまく突破できればクラウド移行を成功に導ける。 今回はクラウド移行を検討した際に突き
失敗の全責任はユーザー側に、旭川医大とNTT東の裁判で逆転判決
電子カルテを中核とする病院情報管理システムの開発が失敗した責任を巡り、旭川医科大学とNTT東日本が争っていた訴訟の控訴審判決は一審判決を覆す内容だった。 札幌高等裁判所は2017年8月31日、旭川医大に約14億1500万円を支払うように命じた。2016年3月の一審判決は旭川医大の過失割合が2割、NTT東が同8割として双方に賠償を命じていたが一転、旭川医大に100％の責任があるとした。同医大は2017年9月14日、判決を不服として最高裁に上告した。 なぜ判決が覆ったのか、裁判資料かと判決文から見ていく。旭川医大とNTT東は日経コンピュータの取材に「コメントできない」と回答した。 高裁もユーザーの義務違反を認定 旭川医大は2008年8月に病院情報管理システムの刷新を企画し、要求仕様書を基に入札を実施。NTT東が落札した。日本IBMと共同開発したパッケージソフトをカスタマイズし、6年リースで提供
［続報］OCNの通信障害、米グーグルによる誤った経路情報の大量送信が原因か
2017年8月25日、NTTコミュニケーションズ（NTTコム）のインターネット接続サービス「OCN」で発生した通信障害に関して、インターネット通信関連の識者は誤った経路情報が大量に流れたことが原因ではないかとの見方を示した。ここでいう経路情報はルーターがBGP（Border Gateway Protocol）というプロトコルを使って交換するものだ。 日本ネットワークインフォメーションセンター（JPNIC）の岡田雅之氏は、NTTコムは複数の組織と対等な関係でネットワークの経路情報をやり取りしているが（これを「ピアリング」という）、そのうちのある組織が誤った経路情報を大量に流したのではないかと話す。その結果、「NTTコムを介してインターネットに接続していた企業のルーターが、大量の経路情報を受け取り高い負荷がかかり、一部はフリーズしたような状態に陥るなどして通信障害につながったのではないか」（岡
中堅中小SIerの逆襲が始まる
多重下請け構造が広がるIT業界で、ある異変が起きている。これまで下請けだった中堅中小のシステムインテグレーター（SIer）が、ユーザー企業と直接取引し始めているのだ。大手SIerとのコンペでも案件を勝ち取る例も珍しくない。理不尽な立場に追い込まれていた下請けSIerの“逆襲”と呼ベるが、ピンハネや丸投げを繰り返してきたような一部の元請けは窮地にさらされそうだ。 何もしないのに「4割」持っていく元請け 下請け時代に「死ぬまでやってくれる」と元請けから評され、約30年にわたって苦しみに耐えてきた中小SIerのシナプスイノベーション。同社は現在、下請けから元請けへと昇格し、ユーザー企業と直接取引できるようになった。同社の藤本繁夫社長はかつての元請けへの怒りをこうぶちまける。「（元請けが手掛ける）上流工程の遅れはすべて下請けがかぶらされる。料金をもらえない仕様変更も頻発。労働時間は全くコントロール
怒りを通り越してあきれるOracleユーザー
「Oracle Database（DB）は信頼性や可用性が高く、当社のシステムには欠かせない。しかしここ数年、保守料が右肩上がり。IT予算に占めるOracle DBの保守料金の割合が増えて困っている」。 製造業A社のシステム部長は悩んでいた。会計や販売管理、生産管理など社内の主要なシステムは全てOracle DBを利用している。しかし開発時期はバラバラで、システム構築を依頼したITベンダーもシステムごとに異なっていた。Oracle DBのライセンスはシステム構築に合わせて、その都度購入している。システムごとに同じOracle DBとはいえ、バージョンは異なり、システム部門の保守作業も手間になっていた。 「Oracle DBを使っているシステムの維持費用を削減したい」。こう考えたシステム部長は、安定稼働していて、今後も大きな業務機能の変更もないと想定できるシステムのデータベースの保守契約を止
「もう従来DBかNoSQLか悩まずに済む」、Googleが基幹用RDB「Cloud Spanner」を発表
「もう従来DBかNoSQLか悩まずに済む」、Googleが基幹用RDB「Cloud Spanner」を発表 米Googleは現地時間2017年2月14日、ミッションクリティカルなアプリケーション向けの分散リレーショナルデータベース（RDB）「Cloud Spanner」を発表した。現在、公開ベータ版を提供している。 Googleによると、Cloud SpannerはACIDトランザクションとSQLセマンティックをサポートし、トランザクションの一貫性を保証する一方、水平スケーリングと高可用性を実現する。「一貫したトランザクションの従来データベースか、拡張性とデータ分散のNoSQLかで悩む必要がなくなる」とGoogleは述べている。 GoogleはCloud Spannerの利点として、シャーディングやクラスタリングを行わずにRDB管理システムをスケールアウトし、NoSQLデータベースに移行す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スマホの画質は2024年に一眼カメラ超え、ソニーGが見通し示す
多摩のビル建設現場火災、AWS向けデータセンターの可能性が濃厚
