変わる「リフト＆シフト」の意味――既存システムのクラウド移行、成功のポイント：各種クラウド機能の適用基準とは（2/3 ページ）

[文：斎藤公二／構成：荒井亜子／インタビュー：内野宏信,＠IT]

最適なクラウド機能を選択するために

──　一方で、移行を推進する上で障害になりやすいポイントは何でしょうか。

＠IT編集長 内野宏信

福垣内氏　代表的なものはデータベースの移行です。例えばクラウド移行に際して、コスト削減を狙ってオンプレミスで使ってきた「SQL Server」や「Oracle Database」などを他社DBやオープンソースソフトウェアに移行しようとすると、うまく動かないケースが多くあります。データベースが動かないとアプリケーションも移行できませんから、そこに一番時間が取られる。移行できてもパフォーマンスに問題が出て、ツールを使ってチューニングを施す地道な作業が必要になるケースが目立ちます。

伊藤氏　コンテナへの移行でつまずくケースも増えています。コンテナは仮想化のようにハイパーバイザー上で独立した仮想マシンを動かすのではなく、ホストOS上で一部カーネルを共有する複数のコンテナを稼働させるアーキテクチャです。仮想マシンの場合は基本的にベアメタルと同様の仕組みのため、アプリケーションの構造を変える必要がなく、ネットワークも複雑な構成になりにくいといったメリットがある一方、コンテナは基本的に単一の機能を動かす仕組みであるため、仮想マシンよりも軽量、高速というメリットがある反面、アプリケーションの構造を変える必要がある他、コンテナ同士の通信が必要なためネットワークが複雑になるなどのデメリットもあります。

──　コンテナをサーバ仮想化の延長というように捉えてしまう誤解もまだ多いようですが、クラウド同様、コンテナに向くシステム、向かないシステムをきちんと見極める必要があるわけですね。

伊藤氏　仮にアプリケーションを再設計して動かせたとしても、運用が煩雑になっただけなど、コンテナのメリットを享受できていないケースが現状では目立つと思います。オンプレミスで延命したり、従来の意味合いでの「リフト＆シフト」で、単純にIaaS上に移行したりする方が合理的という場合もあります。Web系のようにマイクロ秒単位の処理だけをさばくならいいが、基幹系のようなバッチ処理や数10秒単位の処理も入るシステムには向かないなど、システムごとに適切にコンテナの適用を判断することが大切です。

──　ではクラウドに移行するに当たり、何を基準に各種サービスを適用すればよいのでしょうか。貴社ではどのようにアドバイスされているのですか。

福垣内氏　弊社では、どのクラウドプラットフォームを利用するべきなのかを判断する上でのロジックを整理するために、例えば以下のようなフローチャートを独自に作成して、お客さまと共に検討しています。ただ、企業によって注力すべき点は異なるため、毎回このフローチャートと同じものを使うわけではなく、企業の課題に応じて内容を変えながら使っています。あくまでサンプルとしてご理解ください。

　これは「どのような要件の下、何を、どう実現したいか」によって、SaaS、PaaS、FaaS、CaaS、IaaS、オンプレミスを選択できるように整理したものです。一般に、開発保守の対象範囲が小さいほどオンプレミスからSaaSに近づきます。コストや運用負荷を削減するためには、開発する範囲・領域の少ないクラウドサービスから検討し、どの条件にも合致しなかった場合にIaaSを選択するという判断となります。

　例えばフローチャートの1つ目の質問、「SaaS上のサービスで業務が可能かどうか」を判断して、YesならSaaSを選択し、Noなら次の質問に移ります。2つ目の質問では「クラウドベンダーが提供するミドルウェアでアプリが稼働可能か」を判断します。これがYesならPaaSを選択し、Noなら次の質問に移ります。弊社の場合は、これを基軸にしてSaaSからオンプレミスの物理環境までを仕分けています。

クラウド活用のフローチャート（出典：アクセンチュア）《クリックで拡大》

サービスの成熟度やベンダーの取り組みを考慮しつつ大局を見極める

──　昨今注目されているサーバレスも、定義が難しいところがありますが、このチャートのように、どのような要件の、どのようなアプリケーションを実現したいのかによって、サービスの適用を判断できるわけですね。

伊藤氏　サーバレスは、PaaS、FaaS、CaaS辺りが関係します。PaaSの中でも「トランザクションに応じてスケールアウトで拡張可能」で、かつ「フレームワーク上で稼働するシンプルで軽量なアプリケーション」ならFaaSを、「トランザクションに応じてスケールしたいが軽量でなく、標準的な技術の組み合わせで複数環境に配布可能」ならCaaSを選択するといった流れですね。

福垣内氏　ただ、PaaS、FaaS、CaaSはクラウドサービスごとに特性もあるので区別して利用することが前提です。例えば、AWSのAPI Gatewayは「かつては」グローバルIPからのアクセスしか受け付けないという制限がありました。社内システムのデータベースアクセスでも一度社外に出る必要があった。クラウドサービスを選択してからこうした制限が見つかると、アーキテクチャや要件を後から変える必要も出てきてしまいます。それぞれの特性と最新情報を押さえておくことと、ある程度、自分たちでカスタマイズできるスキルが必要です。

伊藤氏　サービスとしての成熟度も関わってきます。チャートを使って選別しても、サービス自体が出たばかりなら、成熟していないと判断して外すべき場合もあれば、あえて使ってみようという判断もあります。下層のIaaSの方ほど構築コストは増えますから、SaaSやPaaSが使えなかった場合、追加コストが余分に発生することも押さえておきたいポイントです。

──　クラウドサービスが充実して選択肢が増えた今、自社システムの特性を見極めつつ、テクノロジーの最新動向もキャッチアップして、主体的かつ合理的に判断する姿勢が一層重要になるということでしょうね。

福垣内氏　そうですね。また、マルチクラウドが加速する中で、自社のアプリケーションやデータをどう管理するかも大きな課題となりますが、中でも一番のポイントは認証だと考えます。実際、ユーザー認証やID管理、デバイス管理などをクラウド上で統合し、オンプレミスを含めた統合認証基盤を構築するケースが増えています。マルチクラウド環境管理の在り方を大局的に見て、ベンダーやサービスを慎重に選択する必要があります。