コラム
はじめまして。BTCクラウドCoEの池浦と申します。
インフラエンジニアを15年程やっておりまして、クラウドCoEではクラウド移行、ハイブリッドクラウドなど、オンプレ周りを主に担当しています。
というわけで、ブログの最初のテーマはクラウド移行にしました。
初回は「クラウド移行パターン」や「クラウド移行ストラテジー」と呼ばれている用語について、元祖といえるGartnerの用語をベースにしつつ、パブリッククラウドの代表格であるAWSとAzureにおける用語を比較してみたいと思います。
例の「Re」なんちゃらっていうあれです。
Gartnerの「5つのR」
まず押さえておきたいのはGartnerの「5つのR」です。2011年に定義されたようです。
私もクラウド移行について勉強を始めたとき最初に目にしたのがこれです。
下になるにつれてクラウド最適化の度合いが高まります。以下、AWS、Azureも同様の順序で記載します。
- Rehost(リホスト):アプリに改修を加えずそのまま移行。物理サーバや仮想サーバをツールを使ってクラウドにそのまま持っていく。クラウド上で同じ構成を再構築する場合もこれ。
- Refactor(リファクタ):アプリ仕様は維持し、一部をマネージドサービスに置き換える。典型的なのは、RDBやキャッシュサーバ等をマネージドサービスに置き換える。
- Revise(リバイズ):既存のアプリ仕様をベースに機能を追加、改修する。クラウドのスケーラビリティを活用できるようにオートスケール機能やイミュータブル化、ダウンタイムのないデプロイ(Blue/Greenなど)を取り入れる。
- Rebuild(リビルド):既存のアプリをクラウドネイティブなアーキテクチャに作り変える。
- Replace(リプレース):既存のアプリをSaaSやDaaSに置き換える。
AWSの「7つのR」
続いてAWSです。
2015年頃は以下の資料にあるとおりGartnerの用語を引用していたようです。
https://media.amazonwebservices.com/jp/summit2015/docs/TA-07-Tokyo-Summit-2015.pdf
2016年頃から「6つのR」としてAWS独自の用語を使いだしています。
https://aws.amazon.com/jp/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/?nc1=f_ls
いまAWSの最新の定義は、「6つのR」にRelocation(リロケーション)が加わり「7つのR」となっています。
Web上では見つからなかったのですが、「AWSへの移行を加速させるための戦略」というタイトルの資料に記載がありました。
- Retain(リテイン):保持。オンプレ環境に残すので移行ではない。
- Retire(リタイア):使用停止。これも移行ではない。
- Relocate(リロケート):vSphereのサーバをVMware Cloud on AWSに移行する。
- Rehosting(リホスティング):Gartnerの用語と同じ。別名「Lift and Shift(リフトアンドシフト)」。
- Replatforming(リプラットフォーミング):アプリのコアアーキテクチャは変えずにクラウド最適化。別名「Lift Tinker and Shift(リフトティンカーアンドシフト)」。GartnerのRefactorとReviseの両方にまたがるような位置づけ。
- Refactoring(リファクタリング)/Re-architecting(リアーキテクティング):GartnerのRebuildと大体同じ。
- Repurchasing(リパーチェイシング):GartnerのReplaceと大体同じ。
Azureの「4つのR」
最後に、Azureです。以下のサイトに記載がありますので詳しくはそちらを参照してください。
https://docs.microsoft.com/ja-jp/azure/cloud-adoption-framework/migrate/azure-best-practices/contoso-migration-overview
- Rehost(リホスト):Gartnerと同じ。
- Refactor(リファクタ):Gartnerと大体同じ。
- Rearchitect(リアーキテクト):GartnerのReviseと大体同じ。
- Rebuild(リビルド):Gartnerと大体同じ。
それぞれを比較してみる
図にしてみるとこんな感じでしょうか。
Gartner用語をベースにしつつ、AWSもAzureもそれぞれ独自の色を出していますね。
AzureにSaaS利用への移行についての用語がないのが個人的には興味深いところです。王者の貫禄を感じます。
注意したいのはRefactor(ing)ですね。GartnerとAzureが一部をマネージドサービスに置き換えるという、比較的クラウド最適化度の低い意味で使用しているのに対して、AWSはクラウドネイティブなアーキテクチャに作り変えるという意味で使用しています。
「Lift and Shift (リフトアンドシフト)」とは?
さて、もう一つ誤解を生みがちな用語に「Lift and Shift (リフトアンドシフト)」があります。
いろいろ見たところ、大きく2つの意味合いで使われているようです。
A: Rehostによりクラウドに移行することそのもの。オンプレからLiftして、クラウドにShiftする。
B: Rehostでクラウド移行(=Lift)した後に、クラウド最適化されたアーキテクチャに変更すること(=Shift)。
私はもともとBの意味で捉えていたのですが、調べてみるとAの意味で使われていることのほうが多いように感じられました。
AWSやAzureははっきりとRehost(ing)の別名として「Lift and Shift」と記載してありますね。
ただ、最近の国内の記事を見ているとAの意味からBの意味に変わってきているとする論調もあるようです。
個人的には後者の意味のほうがしっくりきます。
Aの意味の場合、オンプレからのLift先はどこ?と素朴に思ってしまいました。中継地点があるならイメージつくんですが。。。言葉(第一言語)の違いもあるかもしれませんね。
まとめ
今回、クラウド移行パターンにまつわる用語について比較してみました。
厳密な定義があるわけではないのでそんなに神経質になる必要はありませんが、クラウド移行パターンについて話をするときは以下のような点を意識し、いらぬ誤解を生まないように注意したいところですね。
- クラウドベンダ固有の用語を標準的な用語として使わない
- Refactorは大きく意味が異なる場合があるので特に注意
- 「Lift and Shift」も誤解を生まないように注意
今回はこれで終わりです。ではまた。
-
PICK UP
ピックアップ
-
ピックアップコンテンツがありません
-
RANKING
人気の記事
-
-
1
ハイブリッドクラウドを知る
ハイブリッドクラウドを知る
2021/09/27
-
2
異なるサブスクリプション、異なるADテナントでVN…
異なるサブスクリプション、異なるADテナントでVNet Peering
2021/11/20
-
3
社内システムも、転送データを暗号化した方が良い?と…
社内システムも、転送データを暗号化した方が良い?と聞かれたときの回答
2023/06/12
-
4
IAMを理解する第2回(IAMポリシー編)
IAMを理解する第2回(IAMポリシー編)
2020/06/02
-
5
EKSを理解する(第1回)eksctl・IAM・R…
EKSを理解する(第1回)eksctl・IAM・RBAC
2020/04/09
-
-
ARCHIVE
アーカイブ
-
- July 2024 (1)
- January 2024 (1)
- December 2023 (2)
- June 2023 (2)
- May 2023 (1)
- April 2023 (1)
- March 2023 (2)
- February 2023 (2)
- January 2023 (1)
- December 2022 (2)
- October 2022 (2)
- September 2022 (2)