「データセンターの電源トラブルで楽天ペイと楽天カードが一時使用できない状況に」記事へのコメント

金融機関として失格

[Anonymous Coward]

仮にもお金を扱う事業者なのにＤＲサイトも用意してないってどうなってるんだよと。

金融庁が介入せざるを得ない状況を自分から作りに行くバカってこういうのを言うんだね。

Re:金融機関として失格

[Anonymous Coward]

DRサイトは冗長用ではなく、本番サイトがテロや災害で機能しなくなった場合に備えてのバックアップ。
そして、いざDRに倒そうにもDR側に人員を常駐させていないから操作できなくて倒せないという罠。よくある。

Re:金融機関として失格

[Anonymous Coward]

まあ、自動的にDRサイトに切り替わることで、GitHub [developers.srad.jp]みたいに事故ることもあるからね。
今回みたいなのに対応するんだったら、プライマリ+バックアップ(近くのデータセンタ)+DR(遠くのデータセンタ)の3DC構成を組むべき

Re:

[Anonymous Coward]

めっちゃ正しい構成だと思うけど、それクラウド無しに組むとどのくらいの費用になるんだろう。バックアップのDCは言わばAZだから高速接続必要だろうし。

ここ最近、AWSとかの障害がニュースになってたけど、オンプレでも事故るときは事故るし対策も費用かさむよなぁ。

Re:金融機関として失格

[Anonymous Coward]

今回のQTnet(Qic)の事例で言うと福岡市内に後2カ所サイトがあるので
https://www.qtpro.jp/cloud/qicdc/ [qtpro.jp]
市内をダークファイバーで引き回せばマルチアベイラビリティゾーン構成はどうとでもなる

Re:

[Anonymous Coward]

オンプレで高く付くのは回線コストなので、高速接続は諦めてIP-VPNとかで結べばぶっちゃけクラウドで組むよりは安い。
性能もバックアップで本番の80％、DRは50％くらいで考えれば3倍はかからん。
(作業員が現地まで行く必要があるのでその人件費をコストとして考えるなら・・・だが、日本では人件費＝タダ)

クラウドを使って安くDR構成が組めるとしたら災害時に直ちにスケールアウトするところまで作り込んでる場合だけど、
設計コストが高く付く(＆素人が頑張って組めば障害が起きてみないと分からない部分もある)って問題がある。

Re:金融機関として失格

[nim (10479)]

回線を奢らないとデータ同期ができないし、
遅延同期でオンライントランザクション処理を切り替えるには
それなりのアプリケーション設計しないといかんからね。

まあ、AWSのマルチリージョンでも高速オンライントランザクションは
無理なので、クラウドDRでも事情は一緒ですが。