クラウド移行の新定番「リフト＆シフト」方式とは

クラウドシステムが、エンドユーザーや運用管理者の期待に応えられていないと批判されるのは今や珍しい話しではありません。「動作が遅い」「使いにくい」「コストが肥大化する」「セキュリティが甘い」などクレームには枚挙に暇がありません。今回はクラウドにシステム移行するうえでの「コツ」を解説します。

スケーラビリティ設計の必要性

「クラウドで稼働するシステムのパフォーマンス向上や効率化を実現するには、スケーラビリティ（拡張性）を重視した設計が必要」というのが定説。一方スケーリング（自動的にリソースを増減すること）機能を実現する場合、大半のシステムは再設計が必要になります。

再設計するにはコストと時間が必要。それを避けるためオンプレミスシステムをそのままクラウド移行する「リフト＆シフト」方式を採用する企業が増えつつあります。ところが実のところエンドユーザーや運用管理者の不満を減らして使い勝手を向上させるには、クラウド向けに設計を最適化する必要性が生じるのです。

リフト＆シフト方式とは

フォークリフトで荷物を縦横に移動するよう、システムをクラウドに移動する方式のこと。その長所は業務への影響を最小限に抑えられることです。この方式で移行できれば移行中と移行後も同じアプリケーションの使用を続けられるメリットがあります。

他にはシステムは同じでもハードウェアが新しくなりアプリケーションの動作速度が向上、セキュリティが強化されるメリットも。コンピューティングやストレージのリソースは追加のハードウェアを購入することなく使用量を増やせることでピーク時に合わせた過剰なハードウェア投資を削減できます。

デメリットは、システムをそのままクラウドに移行するため、開発環境下で使用しておらず、問題が生じる可能性があること。仮に動作したとしても、パフォーマンスの低下を招きやすい。クラウド特有のセキュリティ対策やコンプライアンス（法令順守）対策が必要になる場合も生じるため、オンプレミスシステムをそのまま移行した場合、機能要件などの面で合致しない場合もあります。

移行に伴う成否は

クラウドで稼働するシステムの成功には、入念な計画と開発環境で実際に構築する際のテストの実施が不可欠。机上で仕様と要件を練り上げる開発であれば本番で問題が発生しやすくなる傾向にあり、実際にエンドユーザーや運用管理者がツールを使うと新たな問題が発生しがちです。開発の初期段階だけでなく変更時においても、システムが関係者の要望を満たせるかどうか、適宜確認を取る必要があります。本来は変更点のテストが全て完了するまで、本番環境で稼働開始をしないことが望ましいのです。

例えばある企業の失敗例では、システムのリソース使用量や処理のプロセスを安易に増やした結果、パッチ（修正プログラム）適用作業に追われることに。データベースの管理運用が難しくなり、データ処理速度の遅延を防ぐためクラウドストレージの一定領域を余剰領域として確保する「オーバープロビジョニング」を実施せざるえない状況に陥りました。

システムによっては、リフト＆シフト方式でも問題なく機能しますが、クラウドの利用量増大を抑えるため利用頻度を制限したり、コスト高騰を受け入れたりしなければならないものもあります。こうしたシステムはクラウド移行時に手直しが必要で、その構築運用には慎重な検討を要するのです。