NEWEST / < NEXT   BACK >

保険金融系でクラウド(IaaS)が浸透するために必要なもの

IT業界の専門的な話なので
専門外の方はスルーしてください。
-----------------------------

この1ヶ月間、いろいろクラウドコンピューティングを調べる機会がありました。
土曜日も出勤してましてね・・・><

その中で、「何故保険・金融系にはクラウドが浸透しないのか」が
結構体感的に分かってきましたので、情報漏えいにならない範囲で
書き記してみます。

なお、特に断りの無い限り、インフラリソース型のIaaSについて
書きます。

まず、現状のクラウドの大きな課題として3つ挙げられます。

(1)商用RDBMSの使用にかなり制限がある

まずOracle。
「VMWare上では動作保証しません」と言い切ってます。
これは同社の仮想化ソフトウェアのOracle VMを使え、と暗に言ってると
思うんだけど、現状仮想化ソフトウェアのデファクトスタンダードとなっている
VMWare上で、RDBMSのデファクトスタンダートとなっているOracleが
無保証なのはかなり痛い。

これは、システムとして極めて高い信頼性が求められる保険金融系にとっては
クラウドに手を出しづらくなる大きな理由となります。

また、これを理由として「Oracleは使用不可」としているクラウドベンダーは多いです。
と言うかそれがデフォルトです。
この1ヶ月間で5社ほど照会かけたんだけど、全社Oracleは使用不可でした。

次にSQLServer。これは動作保証はしてるんだけど、SPLAという
ちょっと特殊なライセンスが必要になる。(CPUライセンスではダメらしい)
じゃあそれ使えばいいじゃん、という話になるんだけど、どうもいろいろ問題が
あるらしく、「MSSQLはダメ」という大手クラウドベンダーも珍しくない。
ちなみに具体的な金額公表は差し控えますが、ライセンス費は
アホみたいに高いです。CPUライセンスのほぼ2倍かかります。

続いてIBM DB2・・・これはそもそも保険金融系の大規模DBには
構造的に向きません。
クラウド化以前に、非仮想化基盤でも1時間でハングアップする
オンラインシステムが出来上がってしまうので、論外です。
あれはレガシーシステムの外から出るべきではなかったDBです。

MySQLは商用だと金取られるし、今はOracle社の傘下なので
クラウド基盤に対する考え方はOracleDBと同じはず。
そもそも「大規模」には向かないRDBMSです。(mixiレベルが限界)

PostgresSQLは・・・OLAPなどの参照系onlyなら使えますが
更新系DBでは使いものになりません。
更新系DBとして使ってる事例を見たことがありますが、
担当の人達が保守運用でかなり死ぬ思いをしていた記憶があります。
あの「vacuum問題」で。

それ以外のXML-DBとかNoSQLなどの類は、そもそもエンタープライズにおける
実績が少なすぎて、検討の遡上にすら上がり得ません。

・・・といろいろ書いていくと、この時点で「RDBMS不要なシステム」
じゃないと使い物にならないんじゃね?という結論になりかねません。


(2)データ量増加に弱い

今のクラウドベンダーは「ディスク従量課金制」を取っています。
10GBあたり月数千円~といった感じです。
つまりデータ量が増えれば増えるほど割高になります。

クラウドは考え方が「サーバの空きリソースを必要なだけ割当」という、
一昔前の「共用サーバ型ホスティングサービス」と根幹が同じなので、
当たり前と言えば当たり前なんですが。

保険・金融系のデータベースは、データ量が膨大になる傾向があります。
口座番号とか口座名義とか取引履歴とかで、口座1つあたり
最低でも10Kバイト以上の容量を使います。
これを1000万口座がある銀行で考えてみると、この時点でデータ量は100GB。

で、100GBのディスクで足りるわけではなく、データのインデックスと
(データの索引。これが無いとパフォーマンスガタ落ちで使い物にならない)
データを扱うマシンのOSとかソフトウェアとか一時領域など諸々考えると
100GBのデータを扱うのに、300~400GBのディスクが必要。

もちろんサーバ障害時にデータが飛んだら会社が飛ぶので
バックアップも当然行う。

さらに、データ流出時のリスクも考えると、個人情報に該当するデータは
暗号化が必要にもなる。
暗号化すると容量は8倍以上になります。

・・・その結果、1TBクラスのディスク(またはストレージ)が必要になることに。

こうなると、元の考え方が「共用サーバ」である現状のクラウドでは
キャパオーバーになり、クラウドではない専用サーバを2台立てたほうが
5年間ランニングコストとしては割安になってきます。

実際、5年目以降から割高になるという失敗事例
日経ITProで紹介されています(注:記事閲覧には会員登録が必要)。

5年経つとデータ容量もかなり増えてくるし、外部クラウドではなく
自社サーバとして立ててるならば、減価償却も終わっているので
サーバコストはかなり抑えられるはずが、外部クラウドなので
ずーっと同じコストがかかる。その結果5年目以降は割高に。

そもそも、キャパシティ・コストの「スモールスタート」を是とするのが
クラウドの考え方なので、その逆となる「ラージキャパシティ」には
現状脆弱であると言わざるを得ません。

この時点で、今のクラウドは保険・金融系には「構造的に向かない」
ことが分かります。


(3)ネットワークにかかるコストは減らない

現状のクラウドは「ハードウェアリソースの有効利用」なので、
ネットワークリソースの有効利用ではありません。

これに気づかず「クラウドで安く初期構築できます!」と言っている
人が多いですが、そんなわけないだろ、と。

クラウド化によって、確かに初期のハードウェア構築費は減ります。
あまり大規模でないシステムならば。

が、ネットワークリソース構築費は以前と変わらないので、
「クラウド化しても意外と安くならないね」というコメントがあちこちから
出てくることに。(実際言われました)

これはクラウドに限らない一般的な話ですが、ここ10年間の
ハードウェア技術の進歩に、ネットワーク技術の進歩が追いついていません。

特にIP-VPN関連は致命的。
保険金融系でクラウドを使う場合、社内で持っているシステムと
クラウド基盤の間をIP-VPNで繋ぐ・・・という要件が必須になってくるのですが、

「たった1MbpsのIP-VPNを引くのに何百万かかると思ってるんじゃー!」

今でもこんな状態です。
1日に何回もデータ連動しなきゃいけないのに、1Mbpsって、ねえ・・・。

まあこれはクラウドの問題と言うよりは、ネットワーク技術の問題になりますが。

------------------------


と、いろいろクラウド基盤を保険金融系で使えるように
なるまでの課題を書いてきましたが、IaaSの考え方は買ってます。

ハードウェアリソース調整がかなりお手軽に出来るようになったこと、
わざわざ別サーバを立ててクラスタリングせずにホットスタンバイに近い
状況を作れるようになったのは凄い事。

でも、そのメリットを生かせる状態には未だなっていません。
現状ではまだデメリットのほうが大きい状態です。

RDBMSの使用可否の問題、ディスク従量課金性の問題、
ネットワークの問題と、それぞれ解決には時間はかかるでしょうが、
これらの課題をクリアして、保険金融系でもクラウドが
無理なく使えるようになって欲しいです。

なお、よく言われる「セキュリティ懸念」についてはあえて触れませんでした。
国内のデータセンターを使うのなら、クラウドであろうと無かろうと
セキュリティリスク対策はだいたい同じレベルだし、アプリとしての
セキュリティ対策も、クラウドにするとこれが追加で必要となる、というのは
ないはずなので。

あ、でもニフティクラウドは例外か・・・(悪い意味で)

以上です。
 
| society | comments (0) |  

コメント

NEWEST / PAGE TOP / < NEXT   BACK >


Twitter Updates▼


ARCHIVES▼

<前月 2021年03月 次月>
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31    

OTHER▼

POWERED BY

BLOGNPLUS(ぶろぐん+)