楽天カードのシステム障害については既報のとおりである。
これはこれで収束に向かいつつあるが、気になることがある。楽天カードのことを調べると大量にオラクルのコマーシャル記事が出てくることである。
「会員に長期に渡って安心・安全な利用環境を提供したい」 楽天カードがクラウド基盤にオラクルを選んだ理由 - ITmedia NEWS
楽天カード株式会社 Oracle Cloud at Customerの導入でビジネスのスピードアップと急成長を盤石なものに | Oracle 日本
メインフレームから全面移行--楽天カードのクレジットカード業務 - ZDNet Japan
楽天カード、基幹システムのオープン化で安定した環境をユーザーに提供 - クラウド Watch
楽天カード、クレジットカード業務の基幹システムを全面刷新 | 財経新聞
日本オラクル、楽天カードの基幹システム刷新 | ICT ニュース | 日刊工業新聞 電子版
これぐらいにしておくが・・。日本オラクルとしては、クラウド競争の中では後発だったOracle Cloudを紹介するときの具体的事例として、楽天カードの基幹システムリプレースのことを大いに事例として出してきたに違いない。
どうして、今回の障害が発生してしまったのだろう。各記事にうたわれていることが、ブーメラン裏目になってしまっている。
旧システム（メインフレーム）では一度もこのような大型障害は起こっていなかったに違いない。メインフレームベンダーは、今回の件を「悪しき事例」として営業提案の中で話すだろう。特に今回の事例は、Oracle Cloud at Customerだけではなく、Oracle Exadata、Oracle Exalogicまで製品名が出てしまっているのでなかなか厄介な広告記事となってしまっている。そもそもの原因が公開されていないので、競合ベンダーにとっては格好のネタになってしまうだろう。
Oracleだけではなく、クラウド環境をオンプレミスに持ち込み、ベンダーが保守するというスタイルは各社が実施している。一番有名なのはマイクロソフトのAzure Stackだ。IBMも最近、IBM Cloud Privateという製品を発表している。この分野ではOracleは先行していて一定の存在感を示してきただけに、大きなミスとなった感がある。本当の原因は基盤にはないのかもしれないしあるのかもしれない。この辺りがオープンにならないまま、上記広告記事だけがあると「違うじゃないか」という声も説得力が出てしまう。
さて、アーキテクチャ的なことも考える。金融機関がパブリッククラウドを使うのは、情報系に限られ基幹系はオンプレミスとするのは半ば常識だろうと思う。いわゆるハイブリッドクラウドだ。AWSは全部をパブリッククラウドにしたがっているが絶対はそうはならないと思う。今回の楽天カードのシステムの場合は、パブリッククラウドすら使わずその設備をオンプレミスに持ち込む形を取った。前段のOracle Cloud at Customerだ。私はこのアーキテクチャは、リスクの一つになると思う。パブリッククラウドの生産性は、クラウドベンダーが一括管理するから高められるのであり、環境がばらばらのデータセンターに点在して配るような方式はリスクが高いと思う。温度や湿度もばらばらだ。障害発生トリガーも一括管理するパブリッククラウドと比べると千差万別だと思う。また、保守についても人がずっと張り付くにしても点在していればリソースが削がれる。私はこれを機に、クラウド機器をオンプレに置くアーキテクチャは反対派に転じたいと思う。これまで中立派だったがこれだけ大規模なことが起こると考え方も変わる。
ということで、オラクルにもしアドバイスできるならば、上記の大量の広告記事を一度非公開にしたらどうか。記事中にうたわれている導入効果と今回の障害のギャップが痛すぎる。
再度、楽天カード基幹システム刷新による、オラクルがとなえている結果（Result）を復習しておく。
→ 自社データセンター内に設置したOracle Exadata、Oracle ExalogicおよびOracle Cloud at Customerをシームレスに連携することで、楽天グループで開催するイベントやセール企画、また月末のピーク時間帯におけるシステム上の負荷に対処するためのダイナミックな拡張性と負荷分散を実現し、その結果、毎月末の入金取込処理速度を40%向上させた
→ Oracle Cloud at Customerを導入しオンプレミスで導入したOracle ExadataおよびOracle Exalogicとの間でデータ移行や作業負荷の分散ができるようになり、ピーク時の負荷に合わせたシステム設計を不要とすることで初期投資を大幅に抑えた
→ メインフレームからのデータ移行はOracle Cloud at Customerを活用することで、わずか1日で完了させることができ、また基幹システムすべての切り替えも、のべ3日間という限られた時間内に完了できた
→ Oracle Cloud at Customerによる企業向けの「Infrastructure as a Service (IaaS)」を利用してシステムインフラの運用効率を上げ、基幹システムのみならずWebアプリケーションや他の業務システムの処理速度も改善した
→ Oracle Cloudのend-to-end management services機能を利用してシステムに起因する問題を迅速に解決し、クレジットカード取引の遅延を最小限に抑え、ビジネスにおける安定性と継続性を確かなものとした
→ COBOLベースの開発環境を汎用性の高いJavaベースのオープン環境に置き換え、アプリケーション開発を加速化した
→ 高性能エンジニアド・システムの負荷テストにあたって、Oracle Cloud at Customerを使ってオンプレミスのマシンに対してもクラウド経由で高い負荷をかけることが可能になり、テスト実施にかかる時間とコストを低減した
→ 最重要視していたデータの品質の面については、旧システムで処理した入力データのログを使った検証試験で、新システムでも同一の出力が得られることを確認することでデータの正確性・信頼性を担保し、会員が不利益を被らない対応ができた
https://www.oracle.com/jp/customers/rakuten-1-exadata-jp.html
とりあえずは４月のバッチを乗り越えられるかがヤマであるとは思いますが、私もサブではありますが楽天カードのユーザーですので、安定稼働のための最大の努力を望みます。
追記
・Oracle Cloud at Customerのアーキテクチャを理解するなら下記のスライドが分かりやすいと思います。
Oracle Cloud at Customer：サービス概要のご紹介
・あと、はてなブックマークのコメントは読んでいます。随時、文の乱れを修正しています。ご指摘ありがとうございます。
・「憶測記事では？」というコメントを頂いてますが、憶測であり個人の感想です。予想外にシェアされたため、原因がきちんと公表され、かつ全く基盤に関係がないのであれば、本記事は取り下げたいと思います。
・ブーメランの使い方に違和感があるとの指摘について、修正しました。日本語は難しい。なお、「裏目」でもしっくりこないなら何がいいんですかね・・。うーん。
・「温度や湿度」と記載しましたが、これってオンプレ経験していると肌感としてあるんですよね。機械って環境によって故障率が全然違ってきます。同じデータセンターの中でも目の前に熱い機器があるだけで、ディスクの破損率が変わったり。パブリッククラウドならかなり環境を標準化していますが、オンプレのセンターだと当たりはずれがあって・・。いずれ記事に書きたいと思います。
・「Oracleのネガキャンに見える」という指摘がありましたが、原因を公開しない中でPR記事を大量に放置することで、そう見えるのではないか、という問題提起です。
・“データセンターの中でも目の前に熱い機器があるだけで、ディスクの破損率が変わったり。パブリッククラウドならかなり環境を標準化していますが、オンプレのセンターだと当たりはずれがあって”ここもっと知りたい、については記事を追加しました。
サーバー機器の故障率は環境によって大きく違うという件 - orangeitems’s diary
