こんにちは、佐藤です。初回はオンプレミスのアプリケーションサーバをクラウドへ移行する際の検討のポイント、進め方をご紹介します。
クラウド移行とは
早速ですがみなさんがオンプレミスからクラウドへの移行を検討する際、どのような背景や期待があるでしょうか？物理サーバのEOL（End Of Life）でしょうか？老朽化したシステムの延命でしょうか？物理機器の運用・保守から脱却でしょうか？または、セキュリティを強化したい、クラウドの機能を活用してシステムの提供価値を上げたい、アーキテクチャをクラウドネイティブ化して開発速度を上げたい、などでしょうか？
いずれにしても、ビジネス要件、システム要件から担当者に指令が下り、検討がはじまるパターンが多いのではと思います。どのようなポイントで検討を進めればよいか？は、システムの特性によって大きく変わってきます。ここでは下記2つのシステムを例に考えてみます。
1.社内システム
・プライベートネットワークからアクセスのみで、インターネットからのアクセスはない
・Active Directory、CAD、ファイルサーバ、会計、販売、人事、給与、グループウェア、など
・基本的に営業時間のみ稼働
・自社開発のアプリケーションもあるがパッケージ製品も多い
2.インターネットからアクセスされる外部向けシステム
・利用者はインターネットからアクセス、管理者はプライベートネットワークからアクセス
・Webサービス、または、SaaS（Software as a Service)を提供している
・24時間365日稼働
・自社開発のアプリケーション
Cloud Adoption Framework
まずMicrosoftが提供しているクラウド活用のフレームワークとしてCAF（Cloud Adoption Framework）をご紹介します。文量がありますのでここではポイントをしぼって説明します。
https://docs.microsoft.com/ja-jp/azure/cloud-adoption-framework/
CAFは戦略（Strategy）、計画（Plan）、準備（Ready）、導入（Adopt）、ガバナンス（Govern）、管理（Manage）から構成され、それぞれ計画〜導入が具体的に移行を進める上でのガイダンスとなる内容となっています。ガバナンス、管理も非常に重要な項目ですが今回の内容からは割愛します。
5つのRで移行法を検討
CAFの計画のフェーズで5つのRという「試算の合理化」プロセスがあります。言葉は少し難しいですが先述のビジネス要件、システム要件などから最適なクラウドへの移行方法を検討します。
出典：https://docs.microsoft.com/ja-jp/learn/modules/microsoft-cloud-adoption-framework-for-azure/4-plan
例えば「社内システム」で、「老朽化したシステムの延命」が検討の背景だった際、下記のような状況が多いのではないでしょうか？
・移行のコストを多くかけられない
・アプリケーションの変更は極力したくない
・機能の追加は必要なく、今動いているものがそのまま動けば良い
5つのRで考えると、リホスト（リフト&シフト）が最適となる場合が多いです。単純に仮想サーバをクラウドに移行しただけでもバックアップやハードウェア部分の冗長化、運用の手間の削減など多くのメリットを享受できますが、移行して終わりではなく、利用状況を定期的に確認し、継続的な改善を行うことでシステムを効率的に安定稼働させることができます。リザーブドインスタンス化、サイズの見直し、運用手順の自動化は比較的手を入れやすく、また効果は大きいためはじめから移行後の計画に組み込んでおくことをおすすめします。
もう一つの例として「外部向けシステム」で「アーキテクチャをクラウドネイティブ化して開発速度を上げたい」が検討の背景だった際、下記のような場合が多いのではないでしょうか。
・リリース前のテスト環境が本番環境と差分があったため、この課題をクラウド移行後には解決したい
・意向を機にアプリケーションをコンテナ化し開発速度を上げたい
・サーバの面倒は極力見ないでアプリケーションの開発に専念したい
この場合は、リファクター、リアーキテクト、リビルド、リプレースのいずれかになります。
どれを選択するかは確保可能な開発工数、変更に伴うリスクなどを考慮し最適な方法を決定します。ただ、実際にはリファクター、リアーキテクトが多いかと思います。理由は、移行のタイミングでリビルド/新規、リプレースまで行う予算、期間が取れない場合が多いようです。しかし最初からリビルド、リプレースを選択肢から外すのではなく、移行できた場合、メリットがデメリットを超える可能性は本当にないのか？を最初は検討しておくことをおすすめします。
初期に検証を行い自身を持って方針を決める
机上での検討は、判断する情報の精度としては限界があります。そもそも実現可能なのか？どの程度の工数がかかるのか？を判断するために、早い段階で実際にクラウド上に最小構成を構築し、最低限のテストを行い、その結果を踏まえて方向性を決定するのが重要です。初期のこの検証、検討の精度がクラウド移行の成功是非の90%を決めると言っても過言ではありません。
弊社でクラウド移行プロジェクトを行う場合のスケジュールの例をご紹介します。
「社内システム」のリホストでの移行の場合は、既存の仮想マシンをコピーして移行するのか、新規作成しアプリケーションを再設定、データ移行をするのか、といった移行手順の検証が重要です。具体的な手順は後工程で精査していきますが、初期の段階で大きな手順の方針は検証を元に決めておくと後工程で後戻りが発生するリスクが軽減できます。
「外部向けシステム」ではアーキテクチャが変わりますので、例えばコンテナ化してアプリケーションが正常に動くのか？Web Appsにアプリケーションをデプロイしてエラーは発生しないか？など、実際にアプリケーションを動かして最低限のテストを早期に確認しておくことが重要です。後工程で詳細なテストを行った際に色々出てくるものですが、最重要な機能部分を確認しておけば微調整で対応できることが多いためです。
ステークホルダーの関心事を抑える
検討を進めていく中で、もう一つ重要なのがクラウド移行に関わる関係者（ステークホルダー）の存在です。検討を任された担当者は重要なステークホルダーの関心事を早期に捉え、適宜報告・相談をしていくとよいでしょう。これを怠ると認識違いによる、後工程での後戻り、プロジェクト期間の延長などが発生してしまいます。
関心毎の例
・ビジネスオーナー：コスト・期間は計画内に収まるのか？エンドユーザ/社内関係部署との調整事項は何か？セキュリティは大丈夫か？
・開発者：新規機能開発を行いながら移行対応をする必要があるのか？興味ある新しいチャレンジはできるのか？
・インフラ担当者：どうやってクラウドを学習すればよいか？自由にさわれるクラウド環境はあるか？技術的相談先はあるか？
特に外部向けシステムでは関係者がお金を払っている外部ユーザーであることが多いため、調整事項が検討の段階で漏れているとプロジェクト全体のスケジュールが後ろに延びてしまい、予定も多くのコスト、エンジニアの工数が取られてしまうことになりますので注意が必要です。
具体例として下記のようなものがあります。
・サービスの停止時間の調整
・IP Addressの変更対応依頼（ユーザー側でIP制限している場合）
・システムへの接続方法の変更対応依頼
・DNSの変更対応依頼（ユーザー側でDNSを管理している場合）
Azure Migrate
移行方法がリホストだった場合、Azure Migrateが活用できます。Azure Migrateは移行前の評価、移行が行えるサービスです。
評価機能
・オンプレミスのサーバで Azure に移行する準備ができているかどうかを評価
・移行後の Azure VM/Azure SQL 構成のサイズまたは Azure VMware Solution ノードの数を推定
・Azure でオンプレミス サーバを実行する場合のコストを見積もる
・相互に依存するサーバを Azure に移動できるように、サーバ間の依存関係と最適化戦略を特定
移行機能
・オンプレミスの物理サーバを移行
・Hyper-V、VMware、Xen、KVM などの上で稼働している仮想サーバを移行
・AWS、GCPなど他クラウド上のサーバを移行
評価を機械的に行い、その結果をベースにコスト、移行に必要な変更項目を洗い出すことで工数を削減できるだけでなく、抜け漏れのリスクを軽減することができます。
また、実際の移行作業もこのようなサービスを活用することで手順が簡略化でき、テスト項目の設計などエンジニアでないと対応できない作業にリソースを集中させることができますので、リホストの場合には初期の検証の中で確認することをおすすめします。
まとめ
今回はオンプレミスからのアプリケーションサーバのクラウド移行について検討のポイントを説明しました。要件から机上で移行方針を検討し、早い段階で検証・テストを行い方針を自信を持って決定、ステークホルダーの関心事をおさえつつ、ツールやサービスを活用した仕組み化による移行を行うことでエンジニアを疲弊させず、安全に移行を行うことができます。スムーズに移行を進めることはエンジニアのスキルアップやモチベーションにも大きく影響しますので、何かの参考になれば幸いです。次回はデータベースの移行についてご紹介していきます。
・関連情報ページ