春商戦を逃す楽天モバイル

Comments:2

ymo 2020年1月20日 10:47

発生している事象の原因が本当にデータベースのデッドロックであるのならば、処理能力を上げてもなんら解決にはならないと考えるのが一般的だと思います。処理能力を上げれば発生する可能性は下げられるかもしれませんが、根本的にはデータベースの排他処理の設計が悪いのが原因なので、そこを直さない限り普通は解決しません。
デッドロックは、幅が狭くて離合できない区間で対向車が来てしまったのに、お互い譲らずに睨み合いをしていて進めないような状態です。処理能力(車のスピード)を上げれば、離合できない区間を通過する時間は少なくなり、1台の車としての対向車と鉢合わせする確率は下がるかもしれませんが、5000台の車ですら鉢合わせすることがあるのであれば、台数が増えれば可能性は確実に増えます。離合できる所で車を待たせるとかそういう処理を入れない限り再発は防げないと思います。
と、想像で書いていても、実際の所は楽天なのでどうなのかは不明ですが。F&Fさんが処理能力を上げるのが先だと判断されている理由が私にはわからなかったので、意見させていただきました。

F&F 2020年1月20日 11:43

ドコモの障害の時に、処理遅延が起き始める→リクエストが溜まる→リトライしてくる→リソースを食い尽くす→サーバが止まると言う話から(本当は)処理能力かなと思ったわけです。
当初楽天は「ネットワーク障害が起きた、障害を公表しなかったのは原因追及を優先した」と発表していました。

その後楽天は「処理の不具合に起因する」「ロック処理が遅延してもデッドロックを発生させない対処を実施した」「DBMSに潜在的なバグ」と言っているので、ymoさんの書かれている通りですね。

DBで排他処理がうまくいかないはずはないと思っていたところもありますし、ノキアのシステムがそんなにボロなのか？と疑うところも。

楽天Payはサーバの電源異常だったそうで、常用電源から予備電源に切り替わった時にサーバーが止まったと言っています。
これにしても、そもそも瞬断が起きるのか？瞬断が起きるような予備電源システムなのか？
と言う疑問に対して楽天は「想定外の盲点」「UPSを外していた」「障害が発生したのはウチだけじゃない」と回答していました。

まあ起きるはずがない事が起きるから障害になるわけですけど。
設備の不具合は楽天責任、バグならベンダーの責任。
Payの(電源回復後も)復旧が遅れたのは過負荷が原因だとか。

楽天は仮想化システムが原因ではないと付け加えています。
これは他社が、仮想化システムは低コストにはなるが過負荷耐性が低く信頼性確保が難しいと言った事への反論でしょう。

真実は楽天のみが知る、いやベンダーしか知らないのかも。