OPS

【オンプレミスからAWSへ】AWS移行の4つの手順

2020.10.21

2020.10.21

本記事のポイント

オンプレミス環境からAWS移行へ移行する際に注意すべきポイントを4つご紹介いたします。

AWSへ移行可能な要素の洗い出し

オンプレミスからAWSへ移行する際、既存のハードウェアやソフトウェアなど、同等のものを利用できるか確認が必要です。

  • ネットワーク機器 : 製品そのものを移行することは出来ないが、AWSの標準サービスなどで同等機能を実現可能な場合が多い。サードパーティの製品なども調査して実現可能かを調査する必要がある

  • OSやミドルウェア:AWSではOSやミドルウェアの種類、バージョンに制限がある。現行のオンプレミス環境で利用しているものがそのまま使えるかをチェックする必要がある。

  • ソフトウェアライセンス:OSやミドルウェアのバージョンが変更となる場合、利用しているソフトウェアのライセンスやバージョンも検討する必要がある。

  • データベース:OSSのデータベースであれば基本的に問題なくAWSでは個別のサービスとしてデータベース機能も提供している。オンプレミスでOracleなど商用利用している場合は、AWSサーバーにライセンスを移管できるかの確認が必要。

  • クラスタソフトウェア:AWS の仕様やサービスに合わせて別途検討が必要な場合が多い。特に共有ストレージ型のクラスタ構成はそのまま移行することは困難。

移行できない要素については代替手段を検討するなどして「本当にオンプレミスからAWSへ移行しても大丈夫か?」を考える必要があります。

AWS移行による影響範囲の検討

AWSへの移行が概ねOKとなった場合、次に考えるべき内容はその影響範囲です。コストや可用性のメリットを目的にクラウド化をすることはもちろんですが、サーバー上のアプリケーションなどに悪影響が無いかも慎重に検討する必要があります。

  • 移行後のコスト、運用上の影響:コストや運用のメリットがあることはもちろんですが、どの程度になるか試算が必要です。AWSにはPaaSやサーバーレスの仕組みが多数用意されていますので、そういったものを活用すると更にたくさんのメリットを享受できます。

  • 既存アプリケーションへの影響:正常稼働を目指すことはもちろんですが、既存の構成やアーキテクトを維持したまま移行するとクラウドのメリットを享受出来ない可能性があります。どのようにバランスをとっていくかが検討のポイントです。

  • 他システムへの影響:外部とのシステム間連携がある場合、その影響も検討が必要です。移行タイミングや同期処理など移行計画にも関係してきます。

非機能要件の確認

サーバーの可用性や障害対策など、様々な非機能要件を洗い出して確認する必要があります。下記はいくつかの事例になります。

  • 可用性:サーバーごとの重要度や稼働率の決定、バックアップ・リストアに関する計画や要件、想定される災害や対策と目標の復旧時間、必要なセキュリティ対策と要件、OSやソフトウェアのパッチ管理、運用アカウントの管理方法など

  • 運用:ジョブ管理、ログ管理、リソース監視、死活監視、アプリケーションの更新方法、運用実施のための組織やチームづくり、など

  • キャパシティ:性能の目標値、データベースのデータ量、スケールアップやスケールダウンの可能性、性能テストの方法

コストシミュレーション

最後に1〜3で検討した内容、構成をもとにしてAWS移行に関するコストシミュレーションをすることになります。

  • スポットの費用:要件定義、設計、データ移行、ドキュメント制作、アプリケーション改修など、移行に関して一時的にかかる費用

  • AWSの費用AWS料金計算ツール で確認が可能です。サーバーごとのスペックなどを決定しておく必要がありますが、後から変更も容易なためおおよその値で計算して良いと思います。

さいごに

以上がAWSへの移行方法になりますが、AWSの経験が豊富でない場合、自社だけで実施するのは困難です。特にAWSのどのサービスを利用することで移行がスムーズに実施できるか、アーキテクチャの構成は何が最適か、などは知識と経験が必要です。なんとか移行は出来たとしてもコストが思ったより下がらなかったり、可用性や障害対策に問題があったりなど。

当社でもAWS構築サービスを提供していますので、より詳しい内容やお困りの点がございましたら是非お問い合わせください。コストや機能要件などをもとにお見積りを作成させていただきます。

JIG-SAW OPS AWS構築サービス