11日に発生したCARDNET障害、特定接続先で処理件数が増加し高負荷に 21
ストーリー by nagazou
インフラのシステム障害が増えてる気が 部門より
インフラのシステム障害が増えてる気が 部門より
11月11日の夕方から全国的なクレジットカードの決済トラブルが発生した。原因はJCBの子会社である日本カードネットワークの決済システム「CARDNET」で起きた障害によるもの。このシステムはクレジットカード決済時に加盟店と国内のクレジットカード会社や金融機関を中継する役割を持つ。障害は同日の13時23分から20時52分までの間に発生し、一部の取引は17時45分ごろから約1時間程度行えない状況だった。この結果、障害発生時には、JR東海の東京駅での新幹線切符売り場や大手コンビニなどでもクレジット決済ができない状況が生じた（JCB、NHK、ツギノジダイ）。
日経クロステックの記事によると、システム障害の原因は、新旧データベース間の同期処理や特定の接続先とのデータ処理によって負荷が高まったことであるという。日本カードネットワークによると、11日に障害が発生した際、データベースの同期処理を実行中であり、特定の接続先とのデータ処理において通常よりも処理件数が増加し、これがシステムの負荷を引き起こしたと述べている。同社は、負荷を軽減するための対策を試みたが、負荷が増大し、多くの決済が正常に処理されなくなったとしている。現在は原因究明を進めている（日経クロステック）。
日経クロステックの記事によると、システム障害の原因は、新旧データベース間の同期処理や特定の接続先とのデータ処理によって負荷が高まったことであるという。日本カードネットワークによると、11日に障害が発生した際、データベースの同期処理を実行中であり、特定の接続先とのデータ処理において通常よりも処理件数が増加し、これがシステムの負荷を引き起こしたと述べている。同社は、負荷を軽減するための対策を試みたが、負荷が増大し、多くの決済が正常に処理されなくなったとしている。現在は原因究明を進めている（日経クロステック）。
昨日今日 (スコア:1)
昨日は近所のお店で電子マネー支払い全面中止
今日はコンビニでd払い利用不能(メンテ中表示)
もしかして不具合が波及してる？
Re: (スコア:0)
午前2時からドコモで障害発生してたので、起きた時点で注意しとくべきだったのでは
Re: (スコア:0)
お使いのサービス全てに障害が出ていないか、毎日2時からチェックするのは常識ですよね
Re: (スコア:0)
当人がそれで困ったとは言ってないように思うけど…
何を責めることあるのか、いちいちギスギスしすぎ
Re: (スコア:0)
日記で困ってたそうですが
https://srad.jp/~nemui4/journal/665167/ [srad.jp]
Re: (スコア:0)
ちょっと前には銀行取引がやられてたし
あれか (スコア:0)
独身の日でなんかセールスマンしたんかな
Re:あれか (スコア:1)
ちがうよ。
リンク先には、ハードウェア更新作業の前準備として、データ移行の作業中だった、って書いてある。
タレコミには「新旧データベース間の同期処理や特定の接続先とのデータ処理」ってあるけど
これは、旧ハードウェア上の旧データベースのデータを、新ハードウェア上の新データベースに同期（つまりコピー）していたってことだと思われる。
Re: (スコア:0)
コピーと同期は同じ意味ってこと？
コピーするだけでなぜ負荷が高くなったのかすら理解できないんですが
もし事実ならバックアップすら負荷に繋がることになりかねない
Re:あれか (スコア:4, 興味深い)
バックアップってのは、すごい量の読み込みと、すごい量の転送と、すごい量の書き込みが同時に動いている状態です。
すごく負荷がかかります。
どこかにボトルネックがあれば他の箇所は助かります。
（例えば書き込み先が遅いなら、読み込みも転送も大した速度を出せないので負荷は知れてる）
でも同期のような、「これまで動作していた速いDB」から「これから動作する速いDB」に「多分接続用に用意した速いバス」を通じてデータを全力同期するなら、負荷は凄まじいことになります。
Re: (スコア:0)
ファイルサーバーからファイルサーバーにドラッグアンドドロップしてるわけじゃねーんだからそれなりに負荷かかるに決まってるだろOracleデータベースだぞ
Re: (スコア:0)
バックアップは超高負荷な処理だよ
DB遅延の原因になる事はとても多い
Re: (スコア:0)
既存の設備を止めないままバックアップしたのかもよ
カード屋系のoracleパッチ当ては片肺運転にして止まってる方に当てて一旦戻してもう片方をという手順
銀行屋以上に原則止められないミッションクリティカルなので何かあると今回の事案になる
Re: (スコア:0)
他の人も書いてるけど、バックアップは超高負荷な処理だよ。
ファイルサーバのバックアップであっても、サーバからネットワーク経由で1TBとかのデータ
をバックアップする場合は、例えできる限り高速なコピー処理で組んでも1日じゃ終わらないよ。
しかも、高速なコピー処理で組んだら、コピー処理が逐次の早い順番に入って実行されるから、
通常ユーザがファイルサーバのファイルを開くよりコピー処理が優先される結果になる。
結果的に、平時にバックアップを実行すると、通常ユーザがファイルを開くのに時間
が掛かる事になるよ。
だから、そうならないようにする為に、バックアップはできる限り誰も使用していない時間
に自動で実行されるように処理を組むんだよ。
Re: (スコア:0)
結果論にしかならないが、負荷見積もりが甘かったと思われる。
同期(コピー)処理とトランザクション処理を同時に行って大丈夫?。
ただ単純に積み上げただけのような気がする。
Re: (スコア:0)
>データベースの同期処理と特定の接続先とのデータ処理は、理論上は競合するものではないと判断していた。
ということだか負荷見積もりが甘かったわけではなさそう。
うわー。負荷めっちゃ上がってるやん！なんで？え？なんで？やばいやばいやばい！みたいな。
Re: (スコア:0)
独身の日か
中国では既に飽きられて毎年売り上げが下がってるとか
今年は不況の影響もあるだろうけど
独身だからって買う意味がわからない
と中国人がテレビで言ってるの見て笑ってしまった
本番サーバーで良くやらかすやつか (スコア:0)
データ解析しようとSQLを叩いたら負荷が上がって焦るやつ（神頼み）
Re: (スコア:0)
生半可な知識でSQL叩いたら、SQLの内容とインデックスの張り方によっては
全件サーチなんてこともおきたりしますからね。
しかも途中で強制終了もできなかったりして。
ネットワーク帯域を食いつぶしたことはある (スコア:0)
他のサーバーに向けてダンプしようとしてネットワーク帯域を食いつぶしたことはある。
急に繋がりが悪くなってすぐに止めたので何事もなかったけど。
負荷が？ (スコア:0)
最初の記事で負荷が高くなったとあったから
何かのイベントで決済が急激に増えたのかと思ったら
メンテナンスでやらかしただけかよ
まぁ一応負荷が高まった影響なんだろうけど