政府・公共機関向け Microsoft Azure > 3. クラウド移行参考情報

クラウド移行参考情報

基本的な考え方と Microsoft の移行事例

クラウド移行における選択肢

新規システムはパブリッククラウド前提で設計構築する事が多くなっています。既存システムのクラウド移行の検討を行う場合は、移行の選択肢が複数登場します。そのため、検討の前提知識として選択肢にどんなものがあるかの理解がまず必要となります。本項では、クラウド移行における選択肢について説明します。

SaaS/PaaS/IaaS などクラウドそのものの種類などについて概要をお知りになりたい方は、「2. クラウド概念 IaaS/PaaS/SaaS」をご参照ください。

「政府情報システムにおけるクラウドサービスの利用に係る基本方針」においては、SaaS > PaaS > IaaS の順で検討する事が推奨されています。政府の基本方針と Microsoft IT 事例をふまえて既存システムの移行における選択肢をイメージ図としたものが下記の図です。

既存システムの移行先を考えた場合、以下の 2 つが候補となります。

パブリッククラウド (Public Cloud)
オンプレミス(ハウジング、ホスティング、HCI、プライベートクラウド等)

まずはパブリッククラウドを検討し、難しければオンプレミスでの更改を検討します。

クラウドも考慮した既存システムの移行方式選択肢

既存システムの更改を考えた場合に、システム観点での移行方式は簡単にまとめると以下の 7 つの方式があります。既存システム単位の移行を考える場合、いずれの方式が望ましいか検討を行います。検討対象システムの将来のあるべき姿、目的に応じて最適な方式を選択します。

Retire
統廃合で別システムに集約する。または統廃合対象にもせずに廃棄する。
Replace
SaaS など、既に提供されているクラウドサービスを採用する(データ移行等のみ行う)。
例: Microsoft Teams, Exchange Online 等を利用する。
Rearchitect
クラウドならではの機能利用を前提にコード追加やアプリケーション改修を伴ってクラウド上に移行する。
例: クラウド移行と同時に、クラウドを活用して提供機能を追加する。
Rehost / Lift & Shift
仮想サーバーや物理サーバー環境を、特に大きな変更を伴わずに単純にクラウド上で展開しなおす。
例: Hyper-V のプライベートクラウド基盤上の仮想マシンを Azure 上に移行する。
例: Windows Server 2012 R2 (Linuxも同様) の既存システムを、Azure 上で OS バージョンやミドルウェアバージョンを最新化して展開しなおす。
Refactor
ソースコードを含めたアプリケーションの部分的改修を行った上で、クラウドに移行する。
例 1: データベース部分は IaaS に移行せず、Azure Database for PostgreSQL (PaaS) や Azure SQL DB (PaaS) を利用する。
例 2: アプリケーションの一部をコンテナ化して、Web App for Containers (PaaS) 上に展開する。
Rebuild
既存のシステムを流用するのではなく、基本的にアプリケーション含めて新規に開発し、データのみ移行する。
例: サーバーやサーバー上でのミドルウェアパッケージ製品の利用を廃止し、Web App (PaaS) 、 Azure SQL DB (PaaS) 、Azure Functions (PaaS) などを用いて、近代化されたアーキテクチャでシステムを再設計する。
Retain
既存環境を維持する。
例: オンプレミスで再度大きな変更なく更改する。

Microsoft IT のクラウド移行事例

Microsoft のデジタルトランスフォーメーションやクラウド移行に関して、「Inside Track」のページ (英語サイト) で詳細が公開されていますのでご興味のある方は是非ご参照ください。本項では、前項で説明した移行方式を用いながら、Microsoft IT のクラウドへの移行について概要を説明します。

まず、クラウド移行に関する全体像をイメージ図にしたものをご参照ください。

上図内左の逆三角形の図形は、各システムに対してどのような順序で移行方式を決定したかを示しています。

Microsoft が最初に行った検討は、検討対象システムの統廃合と廃棄です。このプロセスを徹底的に行うことにより、30% のシステムを廃棄もしくは統廃合としました。

次に Replace、つまり SaaS の採用検討です。該当システムで行っていた業務が、既に存在する SaaS で対応できないかという事を徹底的に検討を行い、15% を SaaS に移行しました。オンラインのビデオ会議やチャットを提供する Microsoft Teams や、メールサービスの Exchange Online などはわかりやすい SaaS 化の例です。

3 番目から、移行先候補として Microsoft Azure が登場します。この時点で、統廃合や SaaS 化により、全システムの 45% は既に対応が完了している点にご注目ください。残り 55% のシステムに関して、Microsoft Azure や場合によってはオンプレミスをどう活用していくかという検討となります。ここで検討を行うのは、Rearchitect、Rebuild、Refactor などの PaaS 活用を原則とした移行です。

4 番目の移行先検討としては、IaaS を利用した移行の検討です。つまり主に Lift & Shift の方式を検討する選択肢です。

最後に残っているシステムは、今すぐ統廃合はできない、もしくはクラウド化が難しいシステムです。これらのサービスはオンプレミスに残存させました。

このように弊社移行では、

廃棄・統廃合 > SaaS > PaaS > IaaS >オンプレミス

の順に検討・移行をおこないました。弊社事例がご参考になれば幸いです。

アプリケーション観点での移行選択フロー

アプリケーション観点での移行方式選択フローが役に立つ場合もあります。

「Boosting Microsoft’s migration to the cloud with Microsoft Azure」(英語サイト) で詳細が公開されていますのでご興味のある方は是非ご参照ください。

本項では、Microsoft が利用していたアプリケーション観点の移行方式選択フローについて概要を紹介します。

Microsoft がクラウドへの移行を行う中で最終的にたどり着いたフローが上の図です。

Applications、つまり検討対象のアプリケーションに注目します。

新規開発するアプリケーションであれば、PaaS などを活用して近代化されたシステムを構築する。
ソースコードのないパッケージアプリケーションを含む 3rd-party のアプリケーションであれば改修は困難なので、SaaS もしくは IaaS に移行を行う。
ソースコードがあり改修も可能な既存アプリケーションであれば、アプリケーションはミッションクリティカルか否かを判断する。
1. ミッションクリティカルである場合は、PaaS を活用した近代化されたシステムへの改修が望ましい。
  1. 改修コストが確保可能な場合は、PaaS を活用して近代化されたシステムへ移行する。
  2. 改修コストが現時点で確保できない場合は、まずは IaaS に移行して次のタイミングで近代化されたシステムへの改修を実施する。
2. ミッションクリティカルでない場合は、IaaS 中心に移行を行う。

このようにアプリケーション観点の移行選択フローを活用する事で、システム全体でのクラウド検討方向性がより明確になります。

まとめ

本章で紹介したクラウド移行に関する参考情報は下記のとおりです。

新規システムは、パブリッククラウドの SaaS、PaaS 中心に検討を行う。
既存システムは、パブリッククラウドの SaaS > PaaS > IaaS > オンプレミスの順に検討を行う。
システム単位の移行方式選択肢と、アプリケーション観点の移行選択フローを用いて、移行の方向性を決定する。

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。