マイグレーションを実現するために - 第 2 回 : 移行戦略と移行パスとは ?

2020-11-02
ビジネス x クラウド

佐藤 伸広

エンタープライズ・トランスフォーメーション・アーキテクトの佐藤伸広です。ソリューションアーキテクトの中でも主にクラウド移行の上流工程をご支援させて頂いております。

リモートを主とした在宅勤務などの新しい生活様式にもなれてきたことかと思いますが、我が家も家事分担の見直し実施を行い、私が中学生の娘のためにお弁当を毎朝作ることになりました。以降、常に明日のお弁当には何を入れよう、と考えています。夕ご飯はきれいに食べてしまって残りは無いし、娘の好きな唐揚げ弁当を毎日作るのも何だし、と悩みは尽きることがありません。しかしながら、前日のうちに次の日のお弁当のメニューを予め考えておくことでスッキリと眠ることが出来ますし、朝の忙しい時間にメニュー選択で慌てることもなくなります。

毎朝のお弁当作りと同じ様に、クラウド移行をする際にも、将来判断する必要があることを事前に予測し、最初から対応を考えておくことは非常に重要です。言わば移行戦略をいかに事前にきちんと立てておくかがその後の移行をスムーズに行えるかの重要なファクターであるということです。

このシリーズでは、既存システムのクラウド移行=マイグレーションについてお話をさせていただきますが、今回は移行戦略と移行パスについてお話したいと思います。

第 1 回:既存システムのマイグレーションはなぜ必要なのか ? 
第 2 回:移行戦略と移行パスとは ? (今回)
第 3 回:具体的な移行方法とは ? 


さて、移行戦略とは何でしょうか ? 

いろいろな解釈はあると思いますが、

何のために、何を、何に、いつまでに、どの様に移行するのか

を決めておくことです。

この移行戦略をきちんと作らずに移行を始めてしまうと、移行プロジェクトが何らかの原因で進行が遅れた際や止まってしまった際に、混乱の末に何で今このプロジェクトやっているのか、と言うそもそも論の議論を引き起こす原因にもなりますし、その議論が沸騰した際の「立ち戻り先」がない状況になります。よって、この移行戦略を移行が開始される前に決めておくことはクラウド移行をブレなく実行するためにも非常に重要なことなのです。

ただし、移行戦略について考える前に、そもそも今抱えている課題がクラウド移行により解決されるものなのかを検討する必要があります。もちろん、クラウド移行はあくまで手段であり目的ではないため、どの様にすれば課題が解決できるかは入念に検討する必要があります。以降はクラウド移行が有用であると判断された前提で話を進めていきます。

では、移行戦略の一つ一つを見ていきましょう。

はじめに、「何のために」「何を」ですが、第 1 回でお話をさせていただいたとおり、多くの企業において、ビジネスの発展のためデジタルトランスフォーメーションが必要であり、既存システムにかかっているコストをビジネス環境の変化に対応できるシステムへの投資に振り分けるためIT負債を解消するということが必要になっています。この様にクラウド移行がビジネスの課題解決に有用であると判断された際は、移行戦略の中の「何のために」と「何を」にこれらの理由があたっていきます。

さて、次の「何に」が色々選択肢が出てくるところです。

現在、オンプレミスで情報システムを運用されている企業において、今のままオンプレミスで行くのか、クラウドに行くのか、SaaSやパッケージの適用が可能か、どのクラウドを利用するべきか、と言ったことを考える必要があります。これらはそれぞれに考慮ポイントがあります。

オンプレミスかクラウドか、という判断においては、法令や社内規定に関するコンプライアンス要件、システムを自社ですべてコントロールする必要がある完全制御要件、制御対象の機器の近くにシステムがないといけないようなネットワークのレイテンシー要件等で判断しなければなりません。

併せて、ビジネスの変革にともなうシステムの変更に対して、既存のシステムや開発、運用、保守を行っているベンダーが対応できるのか、という観点も必要になります。

img_migration-to-cloud-2_02

次に SaaS やパッケージの適用が可能か、という判断では、対象業務の特定とその業務に合う SaaS やパッケージの候補があるかを吟味しなければなりません。加えてコスト面でもメリットが有るかを算定し、ビジネス改革に一番適切な SaaS やパッケージの選定を行っていきます。

どのクラウドを適用するべきか、という観点では、よくありがちなのは時間的なある断面で機能比較をして利用するクラウドベンダーを決めることです。しかし、変化の速いクラウドの世界ではそれはアンチパターンになっています。日々行われるアップデートにより、今日のベストプラクティスは明日のアンチパターンといったこともありえてしまうことから、時間的なある断面での機能比較はあまり意味を成さないのです。また、一つ一つのサービスは必ずしも同一の機能を提供されているわけではなく微妙な差があり 1 対 1 の比較が出来ない場合もあります。結局はシステムでどのような機能をユーザーに提供しどのような使われ方をするのかというユースケース次第と言えることになります。

img_migration-to-cloud-2_03

もちろん、一度クラウドに移行すると長く使うことになりますので、クラウドベンダーの企業ビジョン、市場シェア、業界での評価、コスト低減の実績、パートナーやコミュニティの規模、Web や書籍等での情報入手の容易性、導入実績、第三者観点での稼働率の実績、等をユースケースに加えて判断材料とすることが必要になります。

これらを網羅的に検討することにより、「何に」が決まります。

次は、「いつまでに」ですが、これは様々な状況によって異なるポイントです。
データセンターの廃止が見えている際はその廃止時期が期限になりますし、そのような期限がない場合は、ハードウェアやミドルウェアの EOSL のタイミングが期限になるでしょう。実際は、そのような期限に加えて、社内稟議のリードタイム等を考えて、いつプロジェクトを開始すればよいか、という逆算でスケジュールを引いていくことも必要になります。

最後に「どのように」です。
クラウド移行に際して、どのようなアーキテクチャを採用するのか、ということを個々のシステムごとに考える必要があります。これを移行パスと呼び、英語の頭文字を取って 7 つの R でまとめることが出来ます。

移行パスの名称

概要

ポイント

1.     リロケート

VMWare Cloud on AWSを用いて、既存オンプレミスのアーキテクチャそのままをAWSに移行

移行時間を最小化しハードウェアの老朽化対応から開放される。ただし既存システムの複雑性をそのまま継承してしまう

2.     リホスト

3 層 Web アプリであれば EC2 で 3 層を構築するなど、既存オンプレミスのアーキテクチャそのままを AWS に移行

クラウドの拡張性や可用性を享受できる。ただし既存システムの複雑性をそのまま継承してしまう

3.     リプラットフォーム

OS やミドルウェアのバージョンアップや RDBMS エンジンの変更、RDS の採用、メインフレームや商用 Unix からの移行

クラウドの拡張性や可用性を享受できる。コスト高な RDBMS エンジンを OSS に変更すれば運用や保守のコスト低減にもつながる。ただし、移行コストやテスト工数は比較的増加する

4.     リファクタリング

 

マルチアベイラビリティーゾーンや Auto Scaling などのクラウドならではの機能を取り入れた構成への変更やマネージドサービスや Lambda や Amazon Elastic Container Service などのサーバーレスを取り入れたクラウド最適化

クラウドの拡張性や可用性を享受できる。サーバーレスを利用することによってサーバーレイヤーの運用から開放され、ビジネスロジックの構築に集中できるようになる。ただし、移行コストやテスト工数は増加する

5.     リパーチェス

SaaS やパッケージの適用

カスタマイズできない場合は SaaS やパッケージに業務を合わせることが必要

6.     リテイン

クラウド移行せず残置

どうしてもクラウド移行が出来ない要件がある場合やクラウド移行による付加価値が出ない場合に選択

7.     リタイア

システムの統廃合による廃止

見直しの結果、他システムへの統合やシステムそのものの廃止が可能な場合に選択

これらは、既存システムが戦略的に変化対応力を求めるシステムなのか、現状のまま稼働し続けることを重視するシステムなのか、また既存のシステムのアーキテクチャや、使用しているパッケージやミドルウェアがどういったものなのか等を把握し、最初の段階で移行パスを決めておくことが必要になってきます。例えば、データセンターの契約終了が近いためまずはリロケートにてクラウドに移行するとしても、将来的にはビジネス価値最大化のためサーバーレスのシステムに移行する、といったような「意思ある二段階移行」を最初から考えているのと全く考えていないのではその後の対応に大きな変化があります。移行戦略を最初に検討していなかったために、リホストすることがゴールとなってしまい、本来のクラウドのメリットを享受しきれていないのでは、といった状況も目にしているのが現状です。

img_migration-to-cloud-2_01

では、移行パスはどのような観点をもって選択すればよいのでしょうか。
観点は色々あるかと思いますが、

  • クラウド適合度
  • クラウド移行難易度

の 2 つの軸で検討することも一案かと思います。
ビッグデータや機械学習はすでにクラウド上で稼働させることが標準であることや、MySQL や PostgreSQL を使っている場合はライセンスに左右されること無くクラウド移行が可能であることから、クラウド適合度は高いと評価できるでしょう。また、クラウドではリージョン間で災害対策 (Disaster Recovery : DR) の構成が容易に取れることや、標準で世界中のリージョンが利用できることからクローバル展開が必要なシステムも適合度が高いと言えます。

一方で、メインフレームや商用 Unix、アプライアンスを利用している場合、そのままではクラウドへ移行できない事や、TCP/IP ベースでない通信プロトコルを利用している場合はクラウド移行難易度が高くなると考えられます。

システムを点数化したサンプルの図は以下のとおりです。システムごとの大まかな特性に応じて推奨される移行パスを示したものです。また、この図は大まかな移行パスを示すとともに、現在のシステムポートフォリオを示すこととなります。なお、以下の例は移行対象システムの対象が企業全体であったり、ある事業部門全体といった広い範囲の場合のアプローチを示していますが、システム数が少ない場合は必ずしも分類の必要はなくシステム単位で移行パスをご検討頂く方がシンプルかと思います。

img_migration-to-cloud-2_04

これら企業毎に異なる様々な事情やシステムの特性を点数化し、システムごとにクラウド適合度とクラウド移行難易度の軸で分類し、大きな枠で移行パスを決めていくということを最初にするだけでもその後のクラウド移行の検討工数削減の実現が可能になります。また、移行パスを考える際には、データ連携があり関連が強いシステム群や、CRM や SCM などの業務分類での一括移行も検討されるべきです。

移行戦略を策定する中で、必ずやっておくべきなのが、大きなまとまりを踏まえたシステムごとの移行パスの策定なのです。

ビジネス価値の最大化を見据えてクラウド移行を行う際に、クラウド移行の最初の段階で移行戦略を考えておくこと、移行パスを決めておくことがほぼ移行戦略そのものであり、かつ移行戦略の最も重要なことであると言えるでしょう。加えて、外部環境、内部環境の変化やテクノロジーの変化に応じて、移行期間中に移行パスを含めた移行戦略の見直しをかける柔軟性も必要だと言えます。

今回は、クラウド移行の移行戦略と移行パスについてご紹介しました。移行戦略を最初に決めておくことでクラウド移行に関するブレがなくなりますし、企業によって様々なシチュエーションがあり評価の観点も異なると思いますが、移行パスの選択根拠を数値化して決めておけばなぜそのアーキテクチャを採用したのか、なぜ採用する必要があったのかをあとからトラッキングすることも容易にできるようになるなど、非常に重要なポイントであることをお話させていただきました。

次回は、既存システムの「具体的な移行方法」についてお話したいと思います。お楽しみに !

プロフィール

photo_sato-nobuhiro

佐藤伸広 (さとうのぶひろ)
アマゾン ウェブ サービス ジャパン株式会社
エンタープライズ・トランスフォーメーション・アーキテクト

営業、SE、プロジェクトマネージャー、コンサルタントを経て、AWS ではお客様のクラウド移行戦略や構想の策定支援を行う部署に所属。日々お客様のビジネスの発展のためにクラウドをどう使っていただくかを考えている。趣味はテレビ鑑賞。定期的に北の国から、白い巨塔、イデオンの DVD を見直している。再販されたホワイトベースのプラモデル入手しました。積んであります。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する