クラウドシフトの移行方針に困っていませんか?
投稿日: 2020/08/21
はじめに
企業のデジタル化やグローバル化、クラウドサービスの成熟度および運用コストの削減の観点から「所有から利用へ」といったクラウドシフトが一般的に検討されてきています。但し、経済産業省が2018年に公開した「DXレポート」によれば、未だに8割の企業がレガシーシステムを抱えており、想定しているようなデジタルトランスフォーメーションを実現できていないことを表しています。また、クラウドへのシフトができていない背景として、クラウド化に伴うコストが不明瞭でクラウド化への方針がないことが課題となってしまい、現状のレガシーシステムの維持運用が優先されてしまっているようです。
クラウド化する際のアプローチと考え方について
クラウド化を検討する際のよくあるパターンを記載します。
- 急遽プロジェクトとして環境が必要になった
- 物理機器のEOSLなどでシステムのリプレイスが必要になった
- クラウド化のメンバーにアサインされ検討しなければいけなくなった
上記で3つほど挙げてみましたが、アプローチと考え方について何かしらの指針に基づいて進めていく形が望ましいです。AWSとして「移行プロセス」と「移行戦略」を定義していますので先ずはそちらに当てはめて考えてみるのはいかがでしょうか。
続いてAWSの「移行プロセス」と「移行戦略」について紹介します。
5段階の移行プロセス
段階1:移行の準備およびビジネス計画
少し難しく記載していますが、ゴール設定を決めるということです。対象システム移行の5W1Hについて考え、移行の完了条件を定義することが重要です。
段階2:ポートフォリオの検出と計画
最初にシステム全体で考えてしまうと判断できなくなってしまうため、システムの機能毎に分解し、順序を付けて検討してみるのも一つの手です。小規模なシステムからの移行を早い段階で行う事で、移行時の注意点や気づきが把握できるため次回以降の改善ポイントに繋がる可能性が高いです。
システム、用途、担当者、連携しているシステム、サーバースペックなどが記載された一覧があるとより全体が把握しやすくなるかと思います。また、ステークホルダー、情報資産、コストの観点でも分類できるとより望ましいです。
※担当者にヒアリング、実機調査することで情報の精度アップ
段階3&4:アプリケーションの設計、移行および検証
段階2で洗い出したシステム、アプリケーションに対してどのように移行するのかを検討し、アジャイル開発のように移行および検証をイテレートしていきます。重要性と複雑性の低いシステムからPoC(Proof of Concept)を兼ねて進めていく形が望ましいです。
移行対象の分類は後述する「7つのR」に当てはめてみるのがイメージしやすいです。
段階5:最新の運用モデル
新しい基盤を最適化し、旧環境のシステムを停止する必要があります。想定されるタスクをいくつか挙げてみます。
- 旧環境のシステム停止/廃棄
- 新環境の構成最適化
- 新環境での運用最適化
構成最適化で一部機能をサーバレスアーキテクチャに置き換えても良いですし、運用最適化でコードを利用したオペレーションの自動化対応を検討しても良いかと思います。移行が完了すれば終わりではなく、改善を検討していくプロセスがあるとなお良いです。
7つのR(7つの一般的なアプリケーション移行戦略)
2011年にGartnerが定義した「5つのR」を踏まえて、2016年頃からAWSが「6つのR」として独自の用語を使いだしています。現在はRelocationが加わり「7つのR」となっています。
-
1. リパーチェイス
アプリケーションをSaaSなどに置き換える方法 -
2. リファクタリング
アプリケーションをクラウドネイティブなアーキテクチャに作り変える方法 -
3. リプラットフォーム
アプリケーションの仕様を維持、または一部機能を追加し、マネージドサービスやスケーラビリティを活用できるようにクラウド最適化する方法 -
4. リホスト
アプリケーションを改修せずにそのまま移行する方法。物理サーバや仮想サーバに対してツールを利用しクラウドに移行、クラウド上に同じ構成で再構築するものを表す -
5. リロケート
vSphere環境をVMC(VMware Cloud on AWS)に移行する方法 -
6. リタイア
移行対象に含めず使用停止にする方法 -
7. リテイン
移行対象に含めず保持する方法
おわりに
今回はクラウド化する際の移行方針の全体の考え方について記載してみましたが如何でしょうか? 実際には今回記載できていない課題、想定外の事象が発生するかもしれません。また、全てを一気にクラウド化するのは難しいため、検討した結果多くのシステムをオンプレミス環境に残したハイブリッド構成になる可能性もあります。
クラウド化することが目的にならないように、運用保守を含めたTCOで比較検討し、必要なものをクラウド化するといった考え方が望ましいため、検討した結果であれば問題ないです。
次回は架空システムを定義し、そのシステムをクラウド化する場合について検討してみようかと思っていますので、引き続きよろしくお願いします。
CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。