BeeX Technical Blog

  • 6,233
  • bxadm

【寄稿】「リフトアンドシフト」で始めるデジタルトランスフォーメーション

 

本記事は、JSUGが選定した旬なテーマを掲載する新しいテーマ別臨時メールマガジン「JSUG Express VOL.1」連動記事です。

第1回のテーマは「デジタルトランスフォーメーション」

AI、IoT、BIGデータをはじめとした最新テクノロジーは、かつて無いほどのペースでビジネスや人々の生活に変化を起こしています。
企業はビジネス変革へのニーズに応えるべく、最新のテクノロジーを活用した「デジタルトランスフォーメーション」の実現が期待されています。

一方で安全性・整合性・統合性を優先した従来の基幹システムは、拡張性、柔軟性が欠如しており、企業が目指すべき生産性や創造性を加速させる活動ができないという課題を持っているのが現状です。また「業務の効率化」や「データの統合」を追求した結果、システムが密結合となった故に、基幹システムのすべてをクラウドへ移行することのハードルが高く、さまざまな課題が伴うために悩まれている企業は少なくありません。このような現状を踏まえつつ、デジタルトランスフォーメーションへの取り組みのきっかけとなる既存のSAPシステムのクラウドマイグレーション(クラウド移行)の現実解として「リフトアンドシフト」と呼ばれる手法をご紹介します。

 

「リフトアンドシフト(Lift and Shift)」とは

用語の出自は見つけられませんでしたが、2015年にGartner社が発表したクラウド神話Top10の中で、クラウドマイグレーション(クラウド移行)のトピックで使われたのが有名です。

要は「まずはクラウド上にそのまま既存システムをあげて(Lift)、その後に随時変更していく(Shift)」という意味であり、しばしば対比される手法は「クラウドネイティブ(Cloud Native)」、つまりクラウド上での利用を前提として設計されたシステムやサービスで新しく構築するということです。


 

まずはLIFT

従来のオンプレミス環境では5年毎にハードウエア保守が切れるため、それに伴い金物をリプレースせざるをえない状況がありました。特にSAPシステムの場合、必要なシステムリソースが大きく、大規模なシステム構成となりやすいため、結果的に膨大なコストがかかります。よって、基盤リプレースと同時にアプリの機能拡張や運用レベル向上などその他のメリット、効果の提供を同時に抱き合わせることで、なんとか社内コンセンサスを得て先に進めることが行われていました。

クラウド化のメリットの一つにH/Wライフサイクルからの解放があげられます。いったんクラウド化すれば定期的な金物のリプレースから解放され、無理な抱き合わせが不要となり、求める機能の拡張に集中しやすい環境に変革することが可能となります。

クラウドマイグレーション(クラウド移行)の種類

Lift and Shift以外にも、幾つかの方法があります。

出典:https://medium.com/aws-enterprise-collection/cloud-native-or-lift-and-shift-99970053b25b

1. Re-host(Lift and Shift

現状の環境に大きな変更を加えることなくクラウドへ移行するLift and Shift。Re-Hostと呼ばれることもあります。

2. Re-platform(Lift & Reshape)

OS・DB・ミドルウェアの変更やアプリケーションのアップグレードをクラウド化と同時に実施する手法です。SAPシステムではクラウド化とともにOS/DBのマイグレーション(HANA化を含む)などを同時に実施する場合がありますが、これらはRe-Platformに位置づけられます。ただSAPシステムの場合、OS/DBの変更がアプリケーションロジックにあたえる影響が極小なので広義の意味でRe-host=Lift and Shiftという言うことができます。

3. Re-purchase(Purchase Drop and Shop)

直訳すると買い替えですが、SaaSの採用などを意味します。経費精算システムにConcurを採用するなどが本対応となります。

4. Re-architect(Re-writing/Decoupling applications)

クラウドネイティブに全面的に置き換える手法です。全面的にと書きましたが、機能を分解しマイクロサービス化して、求められる市場ニーズに対応できるようにしておくことがポイントです。

Lift and Shiftをお勧めする理由

現実解としての選択

クラウドパワーを最大化するためには、4.Re-architectですが、SAPのようなパッケージソフトを全面的におきかえるのは現実的には厳しく、まずは一部の周辺システムの置き換えに留まるのが現実的かと思います。

よって、Lift&Shiftでクラウド化のメリットを享受しつつ、段階的にPaaS/SaaS等の活用・サーバレスアーキテクチャの採用し、クラウドパワーを最大化する方法にシフトしていくというのがお勧めの方法となります。

Lift and Shift手法に否定的な意見もあります。

現状の環境を、そのままクラウド化するだけではクラウドの効果はなく、クラウド化するならクラウドネイティブに置き換える、出来ないならクラウド化すべきではない、という意見です。確かにクラウドのパワーを最大化するのであればクラウドネイティブで作りなおす点効果が高いですが、だからと言って、クラウド化することに、効果がないということにはなりません。先に述べた「H/Wライフサイクルから解放」以外にも、「無尽蔵のリソースを活用できる」、「続々でてくるクラウドサービスとの連携が容易になる」など、今後デジタルトランスフォーメーションへむけて、変化に対応しやすいよう基盤を刷新しておくことは重要です。

また、いきなりクラウドネイティブといっても、そのような人材もいない、なにからはじめて良いか分からない、とうのが現実かと思います。まずはLift and Shiftでクラウド化して、クラウドを経験し、クラウドを学ぶ・慣れることからはじめ、そこからPaaS,SaaS等などのマネージド・サービスを順次に活用していくことにより、クラウドのスキルを段階的に向上させるとともに、今までオンプレミスの不要なワークロードを削減し、組織をクラウドレディな状態に変革していくことが重要であると考えています。

進化し続けるクラウドへの移行と実際

SAP基幹システムのLift and Shift の最先端の現場にいる、我々の今の感覚を最後にお伝えしたいと思います。

IaaS上でSAP環境を運用にのせるために利用するクラウドサービスが限定的であること、多くのお客様が利用した成果として技術実装や運用に関するベストプラクティスは既に熟成しており、コスト効果も明確であることから従来のオンプレベースの基盤更改プロジェクトと同等の感覚で進められる状態にあります。むしろ、リソースが無尽蔵に使えるというクラウドの特性を活かし、オンプレミス同士の移行よりも、移行を容易にする手法も適用し始めています。

クラウドの特徴として、APIが公開されプログラミング可能であることがあげられます。自分たちで様々なものを開発し、運用を効率化することが可能となります。ただ注意しなければならないのは、過去のオンプレミスでしばしば起こったように、使っている使っていないか分からないスクリプトが大量にある、作った人しか仕様がわからないといったことにならないようにすることです。

クラウドは進化は本当にはやいです。開発しても途中で該当機能がクラウド標準機能としてサービス提供された結果、途中で開発を止めて新しく出た標準機能を採用するといううことも起きえますが、クラウドは利用してなんぼの技術ともいえます。作り込まずに標準的なサービスや、業務アプリ用途とは別に運用のためのPaaS,SaaSなどもうまく利用して、無駄な保守運用費を抑制しつつ、変化に追随しやすい環境にすることが重要と考えています。

次のステップへ

リフトアンドシフトによる「移行」と「クラウド活用体制」が整ったら、いよいよ攻めITへの変革を進めます。例えばスピードが求められる UIとインターフェースについては、SAP Cloud Platformを使って、マイクロサービス化した疎結合なシステムへの変革、大量データを蓄積するために各種マネージドサービスを活用したデータレイクの構築、センサーデータ、SNS等の大量データのストリーミング基盤の構築、そして それを支える SAPシステムの  S/4 HANA化による リアルタイムプラットフォームへの変革など。全ては クラウド化よるスピード向上がなければ 対応できません。

デジタルトランスフォーメーション自体が非常に大きなテーマですが、今回はどこからはじめたらよいのかという点で、「リフトアンドシフト」のご説明と、リフトアンドシフトの現場にいる我々の現場感覚をお伝えしました。

何かのご参考になれば幸いです。

長文、最後までお読み頂きありがとうございました。

 

弊社はJSUGゴールドサポーターとして、SAPユーザー会(JSUG)をサポートしております