「リプラットフォームとは…？」
「聞いたことはあるけど、意味がよくわからない…」
「なんとなく意味は知っているけど、リプラットフォームをした方がよいのかわからない…」
など、リプラットフォームについてよく理解していない方は多いでしょう。リプラットフォームはクラウド移行パターンの1つですが、具体的にどのようなやり方を取るのか詳しく知っている方は少ないはずです。本記事ではリプラットフォームとは、メリット・デメリット、成功させるポイントなどについて解説します。リプラットフォームについて理解を深めることで、自社でクラウド移行を検討する際に役立ててください。
リプラットフォームとは？
リプラットフォームとはAWSが提唱したクラウド移行の戦略パターンの1つです。
昨今オンプレミスのシステムをクラウドに移行し、業務効率化や生産性向上、テレワーク環境の構築を目指す企業が増えています。
しかしクラウド移行は必ずしも成功するとは限りません。委託会社に任せても失敗することはあるのです。成功させるには、システム担当者が最低限必要な知識をインプットした上で、最適な移行の戦略を練る必要があります。
オンプレミスのシステムをクラウドに移行する際、AWSは7種類の戦略パターンがあると言っています。その7つは次のものです。
-
- リホスト
- リプラットフォーム
- リファクタリング
- リパーチェイス
- リテイン
- リタイア
- リロケート
システムの状況などによってこの7種類を使い分けることをAWSは推奨しています。すべて「R」から始まるため「7つのR」と呼ばれています。
その中でもリプラットフォームは、既存システムに少し手を加えた後に移行する方法のことであり、7つのRの中でも導入例が多いとされています。
リプラットフォームの目的はシステムの一部のコンポーネントを変更し、クラウド上でシステムをより効率的に機能させ、スケーラビリティやユーザーエクスペリエンスなどの向上を実現させることです。
リプラットフォームのメリット
続いて、リプラットフォームのメリットを解説します。メリットは次の3つです。
①クラウド移行時の時間・コストをなるべく抑えられる
②最小限の手間でクラウドに合わせられる
③外部から見た時の挙動は変わらない
これらのメリットが自社にとって魅力なら、リプラットフォームでクラウド移行を進めましょう。それでは、1つ1つのメリットについて詳しく解説していきます。
①クラウド移行時の時間・コストをなるべく抑えられる
リプラットフォームは時間・コストを抑えられるのが1番大きなメリットです。
一部のコンポーネントのみ修正すれば良く、アーキテクチャの変更は必要ありません。一部のコンポーネントの修正なら、そこまで時間はかからないことが多いです。反対に、リファクタリングはアーキテクチャに変更を加えるため、移行に時間やお金がかかってしまいます。
②最小限の手間でクラウドに合わせられる
リプラットフォームなら最小限の手間でクラウドに合わせることが可能です。
修正せずに移行する場合と異なり、クラウドネイティブが実現しやすいでしょう。クラウドネイティブとは、クラウドの優れている点を活かしたシステムといった意味です。一部のコンポーネントの修正のみで、最小限の手間でクラウドに合わせられるのがリプラットフォームの特徴です。
③外部から見た時の挙動は変わらない
リプラットフォームは大規模な修正は行わないため、外部から見たときの挙動は変更せずに済みます。そのためシステムを使うユーザーへの負担をなくすことが可能です。
リプラットフォームのデメリット
続いて、リプラットフォームのデメリットを解説します。デメリットは次の3つです。
①改良した結果他に影響を及ぼすリスクがある
②予想以上に改良が必要になることもある
③システムが古すぎる場合適していない
状況によっては他のクラウド移行パターンを用いた方が、効率的だったりリスクが低かったりする可能性もあるので注意しましょう。1つ1つのデメリットについて詳しく解説していきます。
①改良した結果他に影響を及ぼすリスクがある
システムの一部を変更した結果、または移行時に予期しない不具合が発生するリスクはあります。
モジュールの独立性が弱いなど設計が悪い場合、一部の修正が他に影響を及ぼすことが多くあります。その場合、大幅な改良が必要になります。
リプラットフォームが適しているかはシステムの状況によります。修正箇所が多すぎる場合、全面改良したり別のSaaS製品に乗り換えたりする方が早い場合も多いです。
②予想以上に改良が必要になることもある
予想以上に改良が必要になることもあります。
リプラットフォームを検討している間に、改良すべき箇所が後から次々と判明することもあります。改良箇所は事前にしっかり見積もらないと追加の料金が発生したり、想定していたスケジュール通りに進まなかったりと痛い目に合うでしょう。
③システムが古すぎる場合適していない
既存システムが古すぎる場合、リプラットフォームとは相性が悪い可能性が高いです。
老朽化したシステムは少し改良した程度では、クラウド化するメリットを享受できないこともあります。その場合、既存システムは捨てて他のシステムに切り替えるのも手です。
反対に比較的新しいシステムなら、リプラットフォームで上手くいく可能性が高いと言えます。
リプラットフォームがおすすめできるパターン
ここまで、リプラットフォームのメリット・デメリットを解説してきました。それらを踏まえてリプラットフォームがおすすめできるパターンを紹介します。
-
- クラウド移行にかけられる予算・時間があまりない場合
- ある程度現行システムが洗練されている場合
- 少しの改良でクラウドの利点が活かせることが明らかである場合
リプラットフォーム化を成功させるポイント
リプラットフォーム化を成功させるポイントは次の4つです。
①現行システムの状況を洗い出す
②KPIを設定する
③システムの変更箇所を検討する
④運用体制を検討する
これら4つを意識することで、さきほど解説したデメリットを補える可能性があります。1つ1つの成功させるポイントについて詳しく解説していきます。
①現行システムの状況を洗い出す
1つ目は現行システムの状況を洗い出すことです。
現行システムのコスト・パフォーマンスを詳しく調査することが移行の第一歩です。調査することで、移行するシステムの順番を決めやすくなります。
移行する順番は重要であり、重要度が低いシステムでも移行コストが低いなら優先した方が良い場合もあります。
どのような順番でクラウドに移行を行うのかロードマップを作成しましょう。
②KPIを設定する
2つ目はKPIを設定することです。
KPI（Key Performance Indicatorsの略）とは目標を達成する過程において、達成度を測る指標のことです。わかりやすく言うと、中間目標のようなものです。
クラウド移行が順調に行われているかの判断基準を事前に作ってくのです。基準を作ることで、システム改良、移行の方針がチーム内で統一されやすくなります。
たとえば、平均応答時間や最大応答時間、合計タイムアップ、エラー率などを中間目標とします。
③システムの変更箇所を検討する
3つ目はシステムの変更箇所を検討することです。
既存システムの機能がクラウド上でも、問題なく動くか検討していかなくてはいけません。そのままの移行が不可能な場合、修正箇所として追加する必要があります。
たとえば、オンプレミスのシステムとクラウド移行したシステム間でデータ連携を問題なく行えるか、などを検討する必要があるでしょう。
もし修正すべき箇所が多すぎる場合、リプラットフォームではなく別の方法を検討することになります。なるべく早い段階（クラウド移行を検討し、計画を立てる段階）で変更箇所を上げれば、手戻りが少なくなるため、別の方法を検討しやすくなります。
④運用体制を検討する
4つ目は運用体制を検討することです。
移行後の運用・管理が不備なく行えて初めて移行成功と言えます。
オンプレミスとクラウドでは運用体制が変わります。サーバの管理はクラウド提供事業者に任せられますが、クラウド上で稼働するシステムの管理はこちらの仕事です。
対応マニュアルを準備しておくなど、移行後の運用体制を確立しておきます。
リプラットフォーム以外のクラウド移行パターン
リプラットフォームのメリット・デメリットをさきほど解説しました。リプラットフォームがクラウド移行の最良パターンとは限りません。
AWSはクラウド移行のパターンとして「7つのR」を提唱しています。リプラットフォーム以外には次の6つが存在します。
-
- リホスト
- リファクタリング
- リパーチェイス
- リテイン
- リタイア
- リロケート
これらの移行パターンのメリット・デメリットについて1つずつ解説していきます。
①リホスト
リホストはオンプレミスのソースコードの修正を全く行わずに移行する戦略です。変更せずとも問題なくクラウド上で稼働する場合に採用するべきパターンです。
リホストのメリットとしては、移行にかかる費用・時間は最小限で済むことです。また、既存コードの変更による不具合発生のリスクもゼロということになります。また、クラウド移行の専門知識がなくても可能であることです。
デメリットは改良を加えないため、システムがクラウドに最適化がされず、稼働はできるとしても機能面が劣化してしまったり、クラウドの機能を活かせなくなってしまったりする場合がある点です。
リホストでは劣化が激しいと判断する場合、1つの上のリプラットフォームを選定します。
②リファクタリング
リファクタリングはリプラットフォームより1つ上に位置する移行パターンです。リプラットフォームよりも既存システムに大きな変更を加えたうえで移行を行います。
システムのコンポーネントだけでなくアーキテクチャを変更する場合もあるため、移行までに多くの時間を費やす可能性もあります。テストにも多くのコストがかかるでしょう。
そのため、既存システムが古すぎて少しの変更ではクラウドの機能を活かせない場合などには有効と言えます。修正した結果パフォーマンスが大きく向上すれば、コストをかけるだけのメリットがあるのです。
リファクタリングにすべきかリプラットフォームにすべきか判断が難しい場合もあり、よく吟味する必要があるでしょう。
③リパーチェイス
リパーチェイスは既存システムを他のSaaS製品に完全に置き換える移行パターンです。つまり、既存システムの修正・活用を諦めるということです。
既存システムがレガシーすぎたり複雑すぎたりする場合、修正してもクラウドで全く活用できない可能性もあります。その場合、新規サービスに乗り換えた方が素早く移行できますし、余計なコストもかからないというメリットがあるのです。
既存のSaaS製品はすでにクラウド対応されているため、そのまま利用できます。
ただし、同じ会社の製品に置き換える場合ならともかく、別の会社の製品に置き換える場合、必要な機能がそろっていない場合などがあります。この場合はリパーチェイスという選択は取らない方が良いでしょう。
④リテイン
リテインはクラウド移行を止めてオンプレミスのままで運用する戦略です。「移行しない」というのも選択肢の1つということです。
システムの状況によっては下手に移行しない方が良い場合もあります。特に移行コストがかかりすぎるという理由でクラウド移行しないことは多くあります。
⑤リタイア
リタイアとはクラウド移行せず、既存システムの利用を停止することです。
クラウド移行について話し合った結果、利用を停止した方が賢明であると判明することはあります。そのシステムが業務の役にあまり立っていない場合などです。
古いシステムを廃止することで、ランニングコストやシステムを管理するための人件コストなどが削減できるメリットがあります。
⑥リロケート
リロケートは日本語で再配置という意味であり、オンプレミスのVMware環境をVMware Cloud on AWS に移行することを指します。
リロケートの場合既存システムには手を加えません。VMware Cloud on AWSはオンプレミスの仮想マシンをそのまま動かせます。
最後に
この記事で説明してきた内容をまとめると以下のとおりです。
-
- AWSが提唱した7つのクラウド移行パターン:リホスト／リプラットフォーム／リファクタリング／リパーチェイス／リテイン／リタイア／リロケート
- リプラットフォームのメリット:時間・コストをなるべく抑えられる／最小限の手間でクラウドに合わせられる／外部から見た時の挙動は変わらない
- リプラットフォームのデメリット:改良した結果他に影響を及ぼすリスク／予想以上に改良が必要になることも／システムが古すぎる場合適していない
- リプラットフォーム化を成功させるポイント:現行システムの状況を洗い出す／KPIを設定する／システムの変更箇所を検討する／運用体制を検討する
「7つのR」のなかからどれが最適かをよく吟味することが大切です。特に基幹システムなど重要度の高いシステムを移行する際は、リスクをいかに抑えて移行するかが重要となります。
株式会社エイチビーラボでは、ベトナムに特化したオフショア開発サービスを提供しております。既存システムの最適な移行パターンを吟味したうえでのクラウド移行・構築には豊富な実績があります。クラウド移行・構築でお困りの方は、ぜひお気軽にお問い合わせください。ご相談から、開発、運用まで親身にサポートいたします。
