Azureを使ったリフト＆シフトの方法
ツールを使用したリホストする場合、アップロードツールとしてはAzure Site Recoveryなどを使用する。すると、オンプレミスにあるVMwareやオンプレミスのマシンを50～70％、Azureに移行できる。
またツール活用により、移行にかかる時間を大幅に短縮することができる。図の下に書かれている「移行グループごとに繰り返す」というのは、1000個サーバーを移行するのであれば、100個ずつ、10回繰り返すということである。
「ツールを使用しない場合はマニュアルで行います。PowerShellやARM（Azure Resource Manager）などのプロビジョニングツールを使って自動でプロビジョニングを行い、手動でミドルウェアコンポーネント＆アプリケーションをインストールします。
データ移行の際には、Azure Data Factoryというデータ移行サービスを活用。細かな設定を行って、テスト用アプリケーションを確認して、最終的にカットオーバーし、オンプレ環境を閉鎖します」（山本氏）
次はリフト＆最適化パイプライン。リフト＆シフトとの違いは、VMの展開はほぼ同じだが、アプリ展開でCHEFやJenkins、Azure DevOps（※資料ではVSTS）を使うこと。イメージメイク処理、データ移行し、プロビジョニングしてテストを実施する。
テストはSeleniumやAzure DevOpsを使う。そして、テスト用のアプリケーションを動かして確認。R4のリプラットフォームでは、コンテナ展開という方法もある。
「OSイメージを取得し、CHEFやJenkins、Azure DevOpsを使ってアプリのパッケージ化を行います。Azure Data Factoryでデータ移行を行い、そのままコンテナに移行できるものはそのままコンテナ化して最適化します。ただ経験上、コンテナにそのまま移行できることはありません」（山本氏）
第三はリフト＆変革のパイプライン。リファクタリングの場合は、まずアプリを分析してコードを変更する。次にデータをAzure Data Factoryで移行。アプリ構築＆展開をして、確認。これを移行グループごとに繰り返す。
「再構築の場合は、ほぼ作り直しといっても過言ではありません。Ansibleなどのプロビジョニングツールを使って、アーキテクチャの定義を行い、マイクロサービス化する場合は、Azure FunctionsやAzure Service Fabricなどを使ってマイクロサービスの定義をします。
そしてDockerやAzure Kubernetes Service（※図ではAzure Container Serviceと表記）でマイクロサービスコンテナ化し、データストアを、Azure Cosmos DB（Document DB）などで再設計します。最後はアプリ構築、展開して確認します」（山本氏）
マイグレーション＆モダナイゼーションのステップとアプローチの全体像を表すと次の図のようになる。
まず、サーバーとアプリのインベントリを持っていない場合は、ディスカバリを実施。顧客がインベントリを持っている場合は、それを活用する。
「サーバーとアプリの数が分かったら、6つのRにわけてアセスメントを行います。それと並行して、Azure上に基盤を構築。Azure Foundation Workshopを行って、どのようにAzureの基盤を作るか検討します。
アセスメントした結果、例えばカスタム60％、パッケージが40％だったとします。パッケージの場合は通常、リホスト、リプレース、リテインを選択します。カスタムアプリケーションは、リホストやリファクター、リビルド、リアーキテクト、さらにはリプレースやリテインなどの方法から選択します」（山本氏）
いずれにしても重要なのは、ステップの選択は成熟度に依存するということ。またクラウド移行のアプローチはビジネスの優先順位とアプリの特性に依存するので、しっかりアセスメントすることが重要になる。
Azure導入事例について
続いて、アバナードが手がけてきた事例が紹介された。事例1は国内製造業におけるPaaSベースのAzureプラットフォームの構築について。Azure PaaSサービスを組み合わせてプラットフォームを構築。顧客の要望を聞き入れ、セキュリティ基準を満たしたハイレベルなプラットフォームが構築できたという。
そのほかにも、国内大手金融機関における、AD、メール、ポータル基盤のリフト＆シフト事例や、国内大手製薬会社におけるSAP on Azureの事例、国内中央官庁の国民向けの基盤再構築事例が紹介された。
「さらにリフト＆変革に近いアプローチを行った事例として、国内大手通信会社のWebサイト再構築があります。規模感としてはIaaSが88インスタンス、App Service（PaaS）が49インスタンス。この規模感のWebサイトの既存インフラを、Azure基盤に統合しました」（山本氏）
海外での事例では、英国保険会社の事例はインスタンス数2100、アプリケーション数2300という非常に規模が大きな既存システムをクラウドトランスフォーメーションした大規模事例を紹介。クラウド移行により、ランニングコストが30％削減。金額にすると年間で5億円の削減が実現したという。
「グローバルなプロフェッショナルサービス企業の事例では、さらなる柔軟性とコスト削減のため、データセンターからAzureにアプリケーションの移行を決断しました。そのうちの1つのアプリケーションに対しては、Microsoft SQL Server2012だったため、2016にアップグレードする必要がありました。そこで単純にリフト＆シフトするだけではなく、データベースアーキテクチャおよび高い可用性のための技術的変更の設計をしました」（山本氏）
アバナードはマイクロソフトベースのソリューションにおける世界最大のエキスパート集団であり、Azure展開において世界的なリーダー企業。Azureに移行する包括的なプランにより、顧客のあらゆる変化に対応し、柔軟に適応しながら、発展できるようにクラウドトラン スフォーメーションを導いている。そう断言し、山本氏は講演を締めた。
【Q＆A】参加者から寄せられた質問を紹介
続いて、オンライン参加者とのQ&Aが行われた。そのいくつかを紹介する。
Q.6つのRの中で最もつまずきやすいポイントはどこか。
山本：リフト＆シフトまではすんなりいけるが、その後どうするか、次の一手が打てない企業が多い印象です。リプラットフォームを行うあたりから、苦労していることが多い。アバナードのメソドロジーを駆使して効率的にサポートしています。
Q.Azureを使う場合、セキュリティで課題になることは何か。
山本：Azureに限りませんが、特にPaaSを使う際にセキュリティで課題に挙がるのが、Azure SQL DBのパブリックのエンドポイントを全員に公開してしまうケース。もちろん、パブリックにつながらないような設計になっていますが、うっかりミスをしないことです。
Q.クラウド移行プロジェクトのスケジュールについて、事例ベースで教えてほしい。
山本：最後に紹介した事例（グローバルなプロフェッショナルサービス企業）では、移行計画の作成、Azureの移行をサポートする技術変更やドキュメント化など、企画・設計フェーズに6週間かかっています。その後は、さらに時間がかかります。
Q.クラウドネイティブを目指すにあたり、個人情報に対する考え方でトレンドはあるか。
山本：最近の流行はゼロトラストです。オンプレと同じように、ネットワークによる防御というセキュリティの考え方を、クラウドに持ち込んでいるパターンが多いですね。
しかし、現在のようなテレワークが主体となると、社員全員がVPNにアクセスすることになり、VPNがパンクしてしまいます。クラウドネイティブにするのであれば、ゼロトラストネットワークというIDによってアクセスを制御する考え方が必要になると思います。
Q.組み込み系のソフトウェア開発をしているが、どんなアプリケーション環境でもAzure環境は適合できるか。
山本：時と場合によりますが、AzureにもIoTに対するサービスがあるので、組み込みにも対応しています。ネットワークの遅延が許されない組み込みの環境もたくさんあります。そもそもインターネットが安定しない工場などもあります。そのような場所ではAzure Stuckというソリューションをお勧めします。これは工場やデータセンターでAzureを動かすという仕組みで、レイテンシーを少なくして、有効活用できます。
Q.自社開発のシステムをリファクタリングするには開発者のスキルもリファクタリングが必要になるが、どのように進めればよいか。
山本：リファクタリングは大変なので、開発者のスキルをどう上げていくかは悩みどころだと思います。アバナードではさまざまなワークショップを開催しているので、開発者だけではなく経営陣の方にも参加していただき、一緒に方向性を考えていきましょう。
Q.Azureは公開されているAPIが少ないが、運用監視面でどのような課題があり、どのように解決したか聞かせてほしい。
山本：最近、AzureではサポートリクエストできるAPIが追加されました。それらをうまく活用し、ServiceNowというSaaSアプリケーションと統合していくことで、運用監視が効率的に行えるのではと思います。
Q.顧客が移行先をAzureとGCPで悩んでいたら、どのようにAzureをお勧めするか。
山本：今のクラウドサービスは、機能面、性能面でもほとんど差はありませんが、アバナードとしてはAzureが最も適したクラウドプラットフォームだと考えています。特にOffice365やDynamicsなど、マイクロソフトのSaaS製品を使っている場合はAzureとの親和性が高いので、確実にAzureへの移行をお勧めしますね。
Q.パブリッククラウドでパフォーマンスを担保する場合、オンプレよりかかるコストについて、どのような説明をすれば説得力があるか。
山本：ディープラーニングのようにハードウェアの稼働率が100％なら、オンプレの方が良い場合もあります。ただ、クラウドは固定費がかからず、不要になったら捨てられるというのがメリット。今はオンプレで100％稼働しているかもしれませんが、半年後に50％なる、年末年始は動かないのであれば、必要なときに必要な分だけ動かせるクラウドが有利だと訴求できると思います。
Q.オンプレミスとクラウドによるハイブリッドのニーズは多いか。クラウドに移行できないのはどんなシステムが多いか。
山本：ハイブリッドのニーズは多いと思います。先ほども説明したように、ハイブリッドの構成パターンもあり得ます。パッケージの場合は、塩漬けにする方がクラウドにするよりもコストがかからなければ、オンプレミスに残す選択も考えられます。
Q.すでにコンテナで動いているアプリケーションの場合は、容易に移行できるか。
山本：同じDockerのコンフィグファイルで動かない場合があるので注意することと、ストレージの場所が変わるので変更する必要はありますが、簡単に移行できると思います。
また、以下に後日回答としていた質問を記載する。
Q.クラウド移行によって未活用のデータが活用できた事例を教えてほしい。
山本：例えば、企業のRDBにあったデータを活用するため、API連携を実現し基幹システムのデータ活用を推進しています。
Q. Windowsの.NETアプリケーション(C#)での事例はありますか？移行ツールは何を使いましたか？
山本：はい。多数あります。オフショアのマイグレーションセンターを活用し、移行ツールは様々で一概には言えないのですが、お客様の要件やアセスメント結果に応じて利用しています。