「クラウドネイティブ」や「デジタルトランスフォーメーション」が、昨今の企業ITのキーワードとなっている。しかし、ミッションクリティカルな基幹系システムをはじめ、SoR領域の既存システムを安易にクラウドに移行したのでは、大きな壁にぶつかってしまうことになる。デジタルの成果を取り入れつつ、自社のビジネスの安定的な運用を実現するためには、これまでのシステムとクラウドをハイブリッド・システムとして構築し、特徴の異なる両システムを同時に維持・発展させていくことが求められてくる。そのための現実的かつ実効的なアプローチとは何かー。IBMのクラウド事業本部長、三澤智光氏にインプレス IT Leaders 編集主幹 田口潤がお話を伺った。（本文中敬称略）
SoRとSoEとをつなぐには「方程式」がある
ここ数年、ビジネスのあらゆる分野でデジタルトランスフォーメーションが叫ばれている。しかし、企業が真剣にデジタルトランスフォーメーションに対応しようとすると、当然ながら様々なシステムをアーキテクチャ・レベルから見直さねばならない。そこで重要になってくるのが、いわゆるSoR（System of Record）とSoE（System of Engagement）それぞれのシステムのプラットフォームをどうするかだ。新陳代謝の激しいSoEについてはクラウド化が正解であるとするのは当然として、ではSoRをどうするべきかが問題となってくる──。
田口：世間ではSoRとSoEはまったくの別物だと捉えがちですが、私は自転車の両輪のようなものだと考えています。後輪がSoRで前輪がSoE。SoRだけだとどの方向に進むかわからないし、逆にSoEだけだと推進力がないので同じ場所をくるくる廻るだけになってしまう。前輪と後輪の双方がシンクロしながら、前へと進むのが大事なのでしょう。
そのため、システムをアーキテクチャ・レベルからどうするかを真剣に考えないといけないわけですが、企業の現状を見ると、SoRについては従来からのIT部門、SoEの方はデジタル推進部門のようなところが管轄していることが多く、双方を包括的に捉えることが難しいという課題を抱えています。そうしたなか、SoRの方も何らかのかたちでクラウドとの連携やクラウドへの移行を検討しなければ、となったときに、企業はどのように判断すればいいのでしょうか。
三澤：SoRとSoEの関係性や企業が抱える課題についてはおっしゃるとおりなのですが、SoRのプラットフォームをどうするかを判断する際には、実は方程式があるのです。
日本IBM 取締役専務執行役員 IBMクラウド事業本部長の三澤智光氏まず、SoRの中でも重くてミッションクリティカルなものには、クラウド化するとむしろコストが高くつき、稼働も不安定になってしまうケースがたくさんあります。このタイプのものは、基本的にはそのまま残すようにします。ただし、フロント側の仕組みがSoE化され、クラウドネイティブでつくられるようになってくると、こっちはものすごいスピードでシステム改変が行われるようになって来ます。そうなるとSoRは何も変わらないのだけど、SoE領域側からSoR領域のデータを参照したいというときに問題が生じてくるでしょう。
そこで、SoRのレガシーな仕組みのフロント部分にAPIを組み合わせる──これが方程式でして、当社の大手の顧客のクラウド化は皆この方式を採用しています。レガシーなインターフェースにAPIをかぶせるソリューションというのは、ずっと以前からIBMが提供しており、断トツで得意な分野だと自負しています。
クラウド移行のメリットがないSoRはオンプレミスに残し、APIを介してSoEと連携拡大画像表示
田口：その方程式を活用した国内企業の具体的な事例も紹介してもらえますか。
三澤：例えば、ある銀行では多くの企業と同様にIT部門とデジタル推進部門があって、デジタル推進部門はレガシーシステムにREST(REpresentational State Transfer)のAPIをつくれとずっと言っていて、一方のIT部門側は自分達がSOAでつくったのだからこのインターフェースに合わせろと戦っていたんです。
田口：「戦い」ですか（笑）。
三澤；はい、まさに戦いです。要は何が起きているかというと、SoR側のデータをSoEから参照するのに、レガシーシステムそのものを変えるのなんて待っていられないというわけです。そうであれば、REST APIをつくって連携させてしまうのが手っ取り早いだろうと、最終的にはIT部門側にも納得してもらえました。この方程式はどこの企業であっても適用できるはずなのですが、SoRにあるどういうデータやプロセスをAPI化すればいいのか、この部分を見極めるのが、日本の企業は苦手なんですね。
インプレス IT Leaders 編集主幹 田口潤田口：やはり、フロント側のSoEとバックオフィスのSoRとで担当している部門がぜんぜん違うことの弊害ですよね。フロントの人たちが何をやりたいのか、IT部門がいまいち理解できていないのでしょう。
三澤：そんな両者の仲を取り持つことができるサービスとしてIBMでは「Garage（ガレージ）」を提供しています。端的に言えば、お客様が何をやりたいのか、それを実現するためにはどういうかたちでAPIを公開すればいいのかなどを、デザインシンキングをしながらプロトタイピングによって支援をしていくサービスです。IBM Cloudのプラットフォーム上には、180以上のサービスやAPIがすぐに使える状態でカタログ化されています。これとこれを組み合わせてこんなプロトタイプをつくってみました、とお客様に提示して、実際に動かしてもらいながら改良していくことができる。「IBM Cloud Garage Method」と呼んでいる確立した手法とお客様と協働して開発していくサービスを提供しているのはIBMだけです。
田口：特に日本企業のニーズにぴったりなので、引き合いも多そうですね。
三澤：はい、採用件数は急速に増えています。例えば流行のブロックチェーンをやりたいといった相談も最近では多いですね。この場合も、本当の実装部分をどうつくるかまで「Garage」の中でプロトタイプはできてしまいます。
SoRをシームレスにクラウドへ、IBM Cloudのベアメタルサービスが実現する価値
SoRの領域でデジタルトランスフォーメーションを起こすうえで重要となるのが、IBMが掲げるクラウド戦略「リフト＆シフト」だ。クラウドに載せる「リフト」とクラウドに最適化する「シフト」を段階的に行うことで、システム要件に合わせたクラウド活用を実現する。その「シフト」を支えるサービスの1つとして「VMware on IBM Cloud」がある。果たしてこのサービスには、どのような狙いがあるのだろうか──。
三澤：そもそもオンプレミスのアーキテクチャとクラウドネイティブのそれというのはあまりにも違いすぎる、という認識がIBM Cloudの根底にあります。
何が違うかというと、まずSoRとSoEではインシデント管理の考え方がまったく違いますよね。オンプレミスのSoRの場合、何か起きた際には、どのシステムがどこのレイヤーでどのリソースが不足したのかなどといった本当のルート構図を把握することができます。しかしSoEの稼働プラットフォームとして広く使われているAWSなどの一般的なパブリッククラウドのIaaSでは、従来インフラ側で対応していたサーバーの管理や監視、バックアップなどの非機能要件がサポートされていません。そのためSoRをきちんとクラウドで動かすとなると非機能要件をアプリケーションに実装しなければならない。ところが、このようなアプリケーションの書き換えには膨大な工数が必要となってしまうのです。
ワークロードや取り扱うデータにあわせて、アプリケーションやコンピューティング環境を組み合わせて利用する、IBMの「リフト＆シフト」戦略拡大画像表示
田口：ITの潮流が過渡期にある象徴とも言えますね。何でもかんでもクラウド移行すればいいのではなく、まずは動いて使えるものをつくらないと。
三澤：その通りです。変えなくていい、もしくは変えないほうがいいシステムはオンプレミスに残す。一方、コスト削減などのメリットが得られるシステムは、そのままクラウドに上げる。これが「リフト」。そしてクラウドに上げたシステムのうち、クラウドネイティブに作り変える価値があるものは、「シフト」――アーキテクチャから見直してクラウドに最適化する。
もっとも、そのままクラウドに上げると言っても、オンプレミスでVMwareの仮想化基盤を利用しているケースは一筋縄ではいきません。AWSなどのパブリッククラウドはVMwareと互換性がない。だから、IaaS側がベアメタルサービスを提供していることが非常に重要になります。
IBM CloudのIaaSは、前身のSoftLayerがサービスを開始したときから、ベアメタルサービスを提供していた老舗で、そのベアメタルのインフラを利用して、オンプレミスのVMware環境を変更することなく、シームレスにワークロードをクラウド移行できるようにしたのが、「VMware on IBM Cloud」なのです。
田口：ベアメタルという言葉、既に定着している感があってあまり厳密に意味を考える機会がないのですが、IBMが提供するベアメタルの特徴はどこにあるのでしょうか。
三澤：まず、通常のパブリッククラウドはサーバーやストレージ、ネットワークなどが全部仮想化されています。そのためSoRを稼働させるには、オンプレミスのインフラで対応していた非機能要件をアプリケーション側で対応するように変更が必要になるわけです。しかしベアメタルを活用すれば、もともとの非機能要件をそのままクラウドに持ち込むことができます。
IBMのベアメタルサービスの最大の特徴は、サーバー、メモリ、ディスクなど欲しいリソースをWebからリクエストすると、大抵はわずか20分程度で立ち上がってくるというスピード感にあります。どんなに大きな環境でも4時間もあれば十分。国産のクラウドサービスの中にも「ベアメタル」をうたっているものがありますが、もしリソースを追加したいとなったら、見積もりを取ってどうこうと軽く数週間はかかってしまうでしょう。そのようなサービスを果たして“クラウド”と呼べるでしょうか？
田口：最近では、「VMware Cloud on AWS」が登場して話題を集めていますが、このサービスもAWSにVMware用のベアメタルレイヤーを用意していることから、「VMware on IBM Cloud」と同様のアプローチとは言えないですか。
三澤：VMware Cloud on AWSの場合、アメリカ・オレゴン州にある1つのデータセンターでαサービスの提供が始まったばかりで、日本企業がすぐ使える段階にはありません。一方、IBMのサービスは21拠点のデータセンターで提供しており、既に1400社の利用実績があります。また、AWSのサービスはサーバー、ネットワーク、ストレージをすべて仮想化する「VMware Cloud Foundation」の利用が前提となっており、そのせいで最小構成がサーバー4台からとなっています。中堅企業規模でも手を出しにくい規模です。
対してIBMでは、サーバー仮想化のみでの利用も可能ですし、サーバー1台から使うことができます。自社のVMwareライセンスをベアメタルの上で活用いただいてもいいんです。もちろん、VMware Cloud Foundationのフルスタック構成にも対応しています。現実的に利用するとなれば、IBMとAWS、お客様にご提案できる選択肢の差は大きいはずです。
田口：クラウド時代のITアーキテクチャに対する本当の意味での理解というのは、ユーザー企業はもちろんのこと、我々メディアやITベンダーの間でもまだまだ十分にできていないように思います。そこは今後もIBMがしっかり発信するともに、ソリューションやサービスで具体的なあるべき姿を示し続けてくれることに期待しています。本日はありがとうございました。
VMwareの仮想化基盤は、多くの国内企業で使われており、その中にはシステム更改を控えているものも少なくない。そうした企業は、オンプレミスの仮想化基盤への投資を増やして拡張を続けていくか、システム改修にコストや手間をかけてでもクラウドに移行するかの難しい判断を迫られている。オンプレミスへの投資を抑制し、アプリケーションの一斉大規模改修を回避しつつ、段階的な最適化を可能にする「リフト＆シフト」戦略は、企業にとってまさしく現実解となるものであろう。
なお、「VMware on IBM Cloud」と「VMware Cloud on AWS」については、別途ダウンロード資料にて詳細な比較を行っている。VMware仮想マシンの移行先検討されている方は、ダウンロードして、ぜひご確認いただきたい。
ホワイトペーパーをダウンロード頂けます。
本資料では、デジタルトランスフォーメーション時代を迎えるにあたってのハイブリッド・クラウド構築の在り方、そして、オンプレミスのVMware環境のクラウド移行を成功させるためのポイントについて提示していく。
イベント告知
日本IBMは、vFORUM 2017に参加します。東京開催では、三澤氏によるセッション、ハンズオンラボ、展示ブースにて、全世界で1400を超える企業で利用されているVMware on IBM Cloudを紹介。大阪開催でも三澤氏によるセッションが行われます。他社クラウドとの違いをご確認したいかたは、ぜひご登録・ご参加ください。
vFORUM 2017 Tokyo
セッションID:IPC4S459X
2017年11月1日（水）13:55 - 14:40
「IBMの三澤が語る 1400社の導入実績から見えてきたVMware Cloudの真実」
日本アイ･ビー･エム株式会社
取締役専務執行役員 IBMクラウド事業本部長 三澤 智光
vFORUM 2017 Osaka
セッションID:IPC4S713Y
2017年11月21日（火）17:20 - 18:05
1400社の導入実績から見えてきたVMware Cloudの真実
