オンプレミスやホスティングサーバからクラウドへワークロードを移行させることは最近では珍しいことではなくなりました。
すでに多くの企業では基幹システムを含む多数のサーバをクラウド上に移築させています。
当ブログでは、ワークロードをクラウドへ移行するための具体的な進め方や、着手するまでの調査方法について説明してきました。
今回はそこからさらに一歩踏み込み、クラウドへ移行したシステムをより効率化させるために必要な手法について説明します。
システムのクラウド最適化度合いをチェック
まず、クラウドの利用形態の区別をおさらいしましょう。
下の図のように、オンプレミスでは物理部分からアプリケーションまでを一貫して管理するのに対し、クラウドのIaaS（Infrastructure as a Service）では、サーバ部分に該当する箇所を借りてリソースを配置することができます。
また、PaaSではさらに、ミドルウェアまでもベンダー側が用意したサービスを利用することで運用負荷を減らしたり、コストを最適化しつつ可用性を高めることが可能です。
さらに、サードパーティが提供するサービスを組み合わせることで、ユーザが車輪の再発明をすることなく、所望の機能を利用することが可能です。
本稿では、この図の右の方、すなわちより多くの機能をクラウド側が提供するサービスで賄われている状態を『クラウドに最適化されている』状態と呼ぶことにします。
（注）近年ではコンテナやサーバレスのような概念も普及していますが、話の簡単化のため、本稿ではこれらのサービスも広義のPaaSに近いものとして説明しています。
クラウド最適化を阻むもの
前述のように、システムをクラウド最適化していくとは、ユーザ自身が管理する領域を減らし、なるべくクラウドの機能を取り入れて行くことです。
一般的に、オンプレミスで動いているシステムを最小限の手間でクラウド上へ移行することをLift&Shiftと呼びます。読んで字の如く、インフラからシステムを持ち上げて（Lift）、そのまま別のインフラへはめこみます（Shift）。
ですので、クラウドへ移行した直後のシステムの多くは上図2つ目の、IaaSを主に使う構成になっているはずです。
このIaaSベースのシステムをPaaSやサーバレスを活用する際に阻害要因になるのは、例えば下記のようなものがあります。
システムがこうなっている場合には回収に多少なりともの費用と時間がかかります。
もちろん、費用対効果に見合わないような改修は避けるべきであり、クラウド最適化は常にビジネス要件との兼ね合いを探す作業になります。
次のセクションで、システムをクラウド最適化するための具体的な6つの方法について説明します。
クラウド最適化のための6つの方法
前のセクションで述べたように、システムをクラウドに最適化させるにはいくつかの方法が存在します。
費やすコストと得られる効果に応じて6つのパターンがあり、それぞれ英語で書くと頭文字が”R”で始まるため、6つのR戦略などども呼ばれています。
後に詳細に記載しますが、この6つとは以下のとおりです。
- Rehost：ホスト先だけ変更。オンプレミスからクラウドへLift&Shiftした直後
- Replatform：デプロイするプラットフォームを変更する。PaaSなどの利用のためのアプリケーション修正が発生する
- Refactor：アプリケーションの構造を作り変える。単純な微修正にとどまらず、フレームワークなども抜本的に変更する
- Retain：コスト見合いや技術的な困難があるため、何もせず、塩漬けのまま
- Repurchase：同じ機能を果たす、別のサービスを購入し直す
- Retire：システムごと破棄する
上3つはクラウド上で改修を行う戦略であり、下3つは回収を回避する策になります。
一般的に6つの戦略と費用対効果は下記のように対応付けられます。以下、詳細にそれぞれの戦略を説明します。
Rehost
Rehostは、アプリケーションのホスト先を変えることで、オンプレミスからクラウドのIaaSへとLift&Shiftすることとほぼ同じ意味です。
もっともシンプルな移行で、ツールなどによる移行の半自動化の恩恵を受けやすいこともメリットです。
一方で、特殊なミドルウェアなどを利用している場合は部分的なRepurchaseやRetireも併用する必要があります。
私のかつての経験では、監視用のエージェントがそのまま移行できなかったため、運用スキームのクラウド化検討とあわせて古いエージェントからクラウド上で利用できる監視サービスを選択しました（Repurchase）。
また、よく「一度Liftしてから最適化するのと、最適化までの道筋を立ててから一気にReplatformするのとではどちらが良いか」といった質問を受けますが、難易度の話で言うと前者を推奨します。
とりあえずアプリケーションがクラウドで動くことを確かめられますし、ネットワーク設計やデータ移行など煩雑な作業を先に片付けておくことができますので、後からPaaS化に集中することができます。
Replatform
Replatformは、アプリケーションのアーキテクチャを変更することなく、利用可能なPaaSを利用する手法です。
典型的にはIaaS上に載せたDBをRDBサービスに置き換えたり、あるいはWebなどの用途が限られたサービスをApp Serviceなどにデプロイし直すことがあります。
これだけでも一部の運用負荷やスケーリングの設定を短縮できますので確かな効果を感じられるでしょう。
Refactor
Refactorはソフトウェアのコアアーキテクチャを変更して、完全にクラウドネイティブな仕様に作り変えることを指します。
これはほぼスクラッチで開発し直すことと大差なく、当然ですが最も時間と費用を使う方法です。
私も実体験として、既存のサービスをクラウドネイティブに作り変えたいというご要望をいただくことがよくありました。
しかし、リファクタはコストを使うだけでなく、完成までの時間も長くかかることに注意が必要です。私はよくこの質問に対しては、「5年、10年後も中核となり利益を生むサービスであればリファクタを検討する余地がありますが、そうでなければReplatformくらいが最も費用対効果が大きいことが多いです」と答えていました。。
Retain
Retainとは、維持を意味します。
読んで字の如く、Rehostを含めたクラウド化を敢えてしないことを指します。Retainは消極的な選択で今以上の効率化は望めません。
しかし、無理に手を入れたところで労多くして功少なしと判断されれば、Retainも選択肢に入るでしょう。Retainを考えるべきシステムの特徴には例えば下記のようなものがあります。
実際には、これらの条件が複数同時にある場合はRetainとなることが多い印象です。
Repurchase
Repurchaseは代替となるサービスを購入することです。
ここでいう代替とは、オンプレミスのときはサーバ管理があったものを置き換えるというイメージなので、クラウド化をきっかけにサーバは捨ててしまいます。
分かりやすい例としては、オンプレミスのときは社内でExchangeサーバを建てて運用していたが、他システムの移行を契機にメールはoffice365のOutlookに移管してしまう、というようなことがあります。
その他、先程のセクションで述べたように、既存のエージェントなどがクラウドで動かない場合、その部分だけを違うサービスに買い換えることもあります。
Retire
Retireはその業務ごとシステムを放棄してしまうことです。
私が過去目にした例では、Faxによる業務をすべて停止する際に、Faxサーバも破棄したことがありました。
システムをクラウド化しようとすると、どうしても現行の業務ありきで進めようと考えてしまいますが、その前に業務そのものの必要性と見直しをすることが必要です。
さもなければ、利益につながらないシステムに不要なコストを割いてしまうことにもなります。
まとめ
この記事では、クラウド上に移行するシステムをより改善するための6つの戦略について説明しました。
クラウドとは、一度サーバを移行させてそれで終わりではありません。むしろ、継続的にビジネスを効率化するためのスタート地点にたったに過ぎません。
そして、クラウド化という手段にとらわれることなく、場合によってはRetainやRetireといった消極的な戦略が効果的であることも意識してください。
ビジネスをより発展させるために、クラウドを有効に使いこなしてください。
今回は以上です。お読みいただきありがとうございました。
コメント