みなさま　こんにちは、JMASの島田です。

今回のコラムは、AWS移行プロセスシリーズ 2回目「移行フェーズ」についてお話します。

▼AWS移行シリーズ
第1回：移行準備フェーズ
第2回：移行フェーズ（本コラム）
第3回：運用＆最適化フェーズ

第1回：移行準備フェーズでは、移行の準備に必要な以下の4つについてご紹介いたしました。
１）事前調査
２）移行方式検討
３）全体設計
４）移行プラン

移行は、目的の明確化、および移行プランの作成が重要なことをご理解いただけましたでしょうか？
まだご覧になっていない方は、そちらも合わせてお読みください。

今回は、移行プランに対する実際の移行作業を行う移行フェーズについて、以下のステップで進めていきます。

■共通基盤について
これまで立案した移行プランに基づき個別システム毎の移行を実施しますが、自由度の高いAWSを企業内で安全に利用するためには、システム管理者が管理できる統制された環境を構築する必要があります。

そのためには、ガバナンスが効いた共通基盤が必要となります。
統制された共通基盤を構築することにより、個別システム担当者は、意識することなくAWSをベストプラクティスで利用することができ、ビジネスをドライブすることに注力することが可能となります。

共通基盤機能としては、以下の項目があげられます。

共通基盤は、導入後のエンハンスのし易さのためにAWSマネージドサービスを利用し、複数システムの統制、管理を行うため、様々な個別システムとシームレスに接続できるように個別のAWSアカウントで構成することが望ましいと考えます。

これまでのノウハウ等を活用するために、オンプレミスで利用していたツールをそのまま利用する場合もあるかと思いますが、運用支援ツール的なものを提供しているパートナー様もいらっしゃいますので、やはりAWSマネージドサービスを最大限に活用した新しい方法にチャレンジすることを推奨いたします。
それがみなさまにとってのDX（デジタルトランスフォーメーション)のきっかけになると思います。

■アカウント分割例
共通基盤のコストを情報システム部門が一括で負担する場合や、利用システム毎に按分する場合など、お客様によって共通基盤のコスト負担方法が異なります。
そのため、お客様の要件によっては、アカウントを統合したり、さらに分割したり、カスタマイズが必要になるシーンもあると思います。

構築中はモノ作りにフォーカスしがちですが、構築後に「あれ？AWSの費用は使った分だけ？費用按分は？」などということにならないように、費用按分についても構築前に定義しておくことを忘れずに実施しましょう。

今回は、弊社のJ-COS運用共通プラットフォームサービスにおけるAWSのアカウント分割の例をご紹介いたします。

1. マスターアカウント

AWS共通基盤上のすべてを総合的に管理するためのアカウント

・ネットワーク管理
・コスト管理
・アカウント管理
・業務システムカタログ
・リソース管理

など

2. ログ集約アカウント

AWS操作／変更ログ、ネットワークログを保管するためのアカウント

3. セキュリティ管理アカウント

セキュリティインシデントの検出、監査を実施するためのアカウント

4. 個別システムアカウント

業務システムを稼働させるためのアカウント

■共通基盤アーキテクチャ構成図

今回は移行パターンとして多く発生する、2つの移行パターンについてについてご紹介いたします。

■サーバをそのまま移行する「Re-Hostパターン」
サーバをそのまま移行する場合は、「CloudEndure」を利用してマイグレーション（移行）いたします。
CloudEndureを使用すると、物理サーバ、仮想サーバ、クラウドサーバを迅速にリフトでき、互換性の問題やパフォーマンスへの影響もなく、切り替えに伴う停止時間も可能な限り短縮することが可能なツールとなっています。

その他にも「AWS Server Migration Service」、「VM Import」などのやり方もあります。エージェントをインストールする必要がありますが、弊社では物理サーバにも対応でき、ネットワーク帯域制御が可能でダウンタイムが少ない「CloudEndure」を採用することが多いです。

先日もIPアドレスを変更できないというお客様のご要望に対して300台超サーバをCloudEndureで移行いたしました。本件の事例については別途、事例紹介いたします。

CloudEndure についてはこちらのコラムもご覧ください。
リモートワークの効率化はAWSへのマイグレーションから！CloudEndureツールを活用した「AWSクイック移行サービス」で強力支援

■リビルドして移行する「Re-Platformパターン」
AWSへそのまま移行できないメインフレーム（大型汎用機）やオフコン（オフィスコンピュータ）などのレガシーシステム、老朽化したUNIXシステムを、AWSに対応したOS・DB・プログラム言語、フレームワークへコンバージョン（変換）する場合は、AWS、およびAWS　Marketplace等でもツールは存在しておらず、リビルド（再構築）が必要になります。

弊社は、既存業務の棚卸しを行い、スリム化を行いながら既存業務ロジックを変更することなく、コンバージョンを独自の先進的なAI変換技術にてコンバージョンを実施いたします。最初にスリム化の実施後にコンバージョンを実施するため、高割合で変換することが可能です。

もちろん、AWSに対応したOS、ミドルウェアの老朽化に伴う、バージョンアップが必要な場合は、AWS上に最新のOS、ミドルウェアの環境を構築して、この環境にアプリケーションをデプロイメント（展開）して、不具合箇所を修正していくやり方も多数の実績がございます。

移行作業中は、様々な課題、問題点が発生することが多く、「日本初、世界初」などの障害と向き合うこともあるかと思います。先日も仮想アプライアンスのバグを踏みましたが、メーカーにファーム改修を依頼して、現在は正常稼働しています。
このように、ひとつひとつの課題を確実に解決していくためには、プロジェクト関係者が一丸となる必要があります。

JMASでは、クラウドエンジニアだけでなく、アプリケーションエンジニアも多数在籍しています。そのため、Re-Hostパターンで移行できない場合でもRe-Platformパターンなどにより多数の移行実績があります。そのため、移行で発生する様々な課題に対してもオンプレミス、クラウド、アプリケーション、多角的な解決策を検討することが可能です。

DX（デジタルトランスフォーメーション）を行うためには、様々なデータのデジタル化だけでなく、課題解決のためにクラウド移行を実施して、これまで発生していたシステム維持管理に発生していた工数を削減することも重要だと思います。
まだ、オンプレミスにサーバが残っているお客様は、是非ご連絡ください。

【J-COS 移行サービス】現行システムからのAWS移行をあらゆるシーンで完全サポート
移行に関する資料もありますので、興味のある方は、お気軽にお問い合わせください。

次回は、運用＆最適化フェーズについてご紹介していきます。
楽しみにしていてください！！