2020年9月23日開催のMicrrosoft Ignite 2020 CON147 Azure journey for app modernization -App Modernizationを実現させるAzureジャーニー- にのスライドを公開しました。

2. Azure Journey for App Modernization
App Modernizationを実現させるAzureジャーニー
株式会社オルターブース 小島 淳（Microsoft Regional Director）

3. Agenda  クラウド化の現状把握
 App Modernizationにおける4つのプラン
 .NETアプリケーションのモダナイズ
 クラウドネイティブへのアプローチ

4. 株式会社オルターブース
代表取締役
小島 淳
Microsoft Regional Director
元ハードコアバンドのベーシストで
あり、柔道整復師の資格を持つ
ジーズアカデミー メンター
特定非営利活動法人 AIP 理事

5. クラウド化の現状把
握

6. 2025年の崖
経済産業省の報告書（DXレポー
ト）によると、2018年時点で同
じ基幹システムを21年以上運用
している企業は全体の2割だとさ
れています。これが2025年には
6割に達すると予測され、ITの老
朽化が進んでいます。
https://www.meti.go.jp/shingikai/mono_info_service/digital_transfo
rmation/20180907_report.html

7. 国内パブリッククラウド市場動向
出典元
https://www.idc.com/getdoc.jsp?containerId=prJPJ
46136120
2019年の国内パブリッククラ
ウドサービス市場規模は、前年
比22.9％増の8,778億円とな
り、2024年の市場規模は2019
年比2.4倍の2兆644億円にな
る。

8. Windows Server 2008/2008R2 EOS問題
2020年1月14日をもってWindows Server 2008/2008R2のサポートが
終了しました。しかし未だに国内には20万台以上のWindows Server
2008が稼働しており、レガシー資産の多くは塩漬け状態となってい
る。
これら多くのシステムはオンプレミス上で稼働しており、現世代の
Windows Server 2019へのマイグレーションは非常に困難な状況で
す。

9. なぜクラウド化が困難なものになってしまったのか
⚫ クラウド化アセスメントができない
⚫ ネットワークセキュリティ
⚫ アジャイル、DevOpsの導入が進んでいない
⚫ 移行コスト
⚫ etc

10. App Modernizationに
おける4つのプラン

11. App Modernizationの基本設計
App Modernizationの前提としてクラウド化しなくてはいけません。
アプリケーションだけを最新のものにしたところですぐにシステム
の限界が来てしまうからです。
Step1. 既存システムの評価
既存システムの評価は、クラウド化するための見積もり、リスク評価、改修規模など中心に行
います。
Step2. クラウドへ移行
4つの移行プランを軸に移行設計をしていきます。
Step3. リソースの最適化
継続的改善ができるように、常に状態を確認できるようにします。

12. Cloud Adoption Frameworkの活用
Cloud Adoption Frameworkとはクラウド導入におけるビジネス・テ
クノロジー戦略と実装を支援することを目的とした実証済みのガイ
ダンスです。
戦略
業務上の正当な理由と
導入による予想される
結果を定義する 。
計画
ビジネスの結果に合わ
せて実行可能な導入
計画を調整する 。
計画された変更のため
にクラウド環境を準備
する。
既存のワークロードを移行して最新
化する。
準備完了 移行
ガバナンス
環境とワークロードを管理する。
管理
ソリューションおよびハイブリッド ソ
リューションのための運用管理。

13. 4つのプラン
リホスト リファクター リアーキテクト リビルド
リフトアンドシフトで
IaaSに移行させる。
コード修正することな
く既存の仕組みをその
まま移行する。各アプ
リケーションは現状の
ままクラウドに移行す
ることが可能。
アプリケーションの再
パッケージ化をし、
PaaSもしくはIaaSに
移行する。コード修正
は最小限で行い、アプ
リケーションのスケー
ルを最大化することが
可能。
アプリケーションの
コードベースを変更し、
最新化したのちに個別
にデプロイできるアー
キテクチャーへ分散さ
せる。プロセスの高速
化、スケーリング、ア
プリデプロイの自動化
を実現する。
クラウドネイティブ化
するためにアプリケー
ションをゼロからリビ
ルドする。すべての機
能をPaaSで実現し、
フルマネージドサービ
スとしてクラウドを活
用する。
仮想マシン App Service
SQL Database
Azure Kubernetes Logic Apps
Azure Functions

14. よくある勘違い
リホストにおけるリスクは“少ない”
リファクターにおける可用性は“低い”
リアーキテクトにおける運用は“楽”
Cloud Adoption Frameworkでは上記のようなイメージができやすい
が、実装時ではなく実装後に問題が起こりやすい。

15. .NETアプリケーショ
ンのモダナイズ化

16. Windows Serverリホストにおける注意点
リホストではアプリケーションの改修を極力せず、既存のシステム
をクラウドへ移行する方法です。多くはリフトアンドシフトで移行
します。
Windows Server上でWebアプリケーションを稼働させている場合、
そのアプリケーションになるべく手を付けずに移行するためにはIIS
のバージョン遷移について理解する必要があります。
Windows2003/R2
IIS6.0
Windows2008/R2
IIS7.0/7.5
Windows2012/R2
IIS8.0/8.5
Windows2016
IIS10.0
汎用ワーカープロセス
（w3wp.exe）
統合パイプライン
TCP/IP、名前付きパイプラ
イン
64ビット対応
アプリケーションプール
単位の動作アカウント分
離
大きな変更はあまりない

17. レガシー.NETアプリケーションの移行
レガシー.NETアプリのModernizationにおいて最も重要なことはIISの
バージョンアップ対応になります。特に2003以前（IIS6.0以前）で稼
働しているアプリケーションをクラウド化する場合、まずは最新の
IISで稼働させることを前提とした移行設計を行います。
考慮すべき点は以下になります。
• ワーカープロセスの分離管理
• パイプラインの確認
• 64ビット化
• 運用、管理サービスのクラウド化

18. クラシックパイプライン（IIS6互換モード）
IISハンドラ
ASP.NET独立
パイプライン
IISモジュール
IISモジュール
IISモジュール
httpモジュール
httpモジュール
httpモジュール
ISAPModule
StaticFileModule
IISパイプライン
httpハンドラ
PageHandler
Factory
WebService
HandlerFactory
IIS6.0で使用していたASP.NET独立パイプライ
ンを入れ子にする。
IIS7.0以降のパイプラインは統合パイプラインとクラシックパイプラインがあり、特にクラシック
パイプラインはIIS6互換モードになっています。従来のASP.NET独立パイプラインも扱うことが
できるのでWindows Serverリホストの場合はクラシックパイプラインを使います。

19. .NET Coreへのモダナイズ
最新の.NET5.0へ移行するには一度.NET Coreへアプリケーションを変更
する必要があります。
https://docs.microsoft.com/ja-jp/dotnet/core/porting/
.NET Frameworkを移行するうえで使用できなくなるものは以下です。
• AppDomain
• .NET リモート処理
• CAS（コードアクセスセキュリティ）
• セキュリティ透過性
• COM＋
他にも破壊的変更がいくつかあるのでMS Docsで確認してください。
https://docs.microsoft.com/ja-jp/dotnet/core/compatibility/

20. クラウドネイティブ
へのアプローチ

21. 最適化アーキテクチャー
App Modernizationにおけるリソース最適化において実装すべきは
Azureの最適構成になります。
Well‐Architected Frameworkはワークロードの品質向上に使用できる
一連の基本原則であり、最適構成の設計に役に立ちます。
コストの最適化 もたらされる価値を最大化するためのコスト管理
オペレーショナル エクセレンス 運用環境でシステムを継続的に動作させる運用プロセス
パフォーマンス効率 負荷の変化に対応するためのシステムの能力
信頼性 障害から回復して動作を続行するシステムの能力
セキュリティ 脅威からアプリケーションとデータを保護すること

22. The Twelve-Factor Appによる実装設計
I. コードベース
II. 依存関係
V. ビルド、リリース、実行
III. 設定
IV. バックエンドサービス
VI. プロセス
VII. ポートバインディング
VIII.並行性
IX. 廃棄容易性
X. 開発本番一致
XI. ログ
XII. 管理プロセスWebアプリケーション開発における12の方法論

23. The Twelve-Factor Appの方法論
1. コードベース
バージョン管理される1つのコードベースと複数のデプロイ
2. 依存関係
依存関係を明示的に宣言し分離する
3. 設定
設定を環境変数に格納する
4. バックエンドサービス
バックエンドサービスをアタッチされたリソースとして扱
う
5. ビルド、リリース、実行
ビルド、リリース、実行の3つのステージを厳密に分離する
6. プロセス
アプリを1つ又は複数のステートレスなプロセスとして実行
7. ポートバインディング
ポートバインディングを通してサービスを公開する
8. 並行性
プロセスモデルによってスケールアウトする
9. 廃棄容易性
高速な起動とグレースフル停止で堅牢性を最大化する
10. 開発／本番一致
開発、ステージング、本番環境をできるだけ一致させた
状態を保つ
11. ログ
ログをイベントストリームとして扱う
12. 管理プロセス
管理タスクを1回限りのプロセスとして実行する

24. Factor3.設定
アプリケーションの設定は、デプロイ（ステージング、本番、開発
環境など）の間で異なり得る唯一のものである。
定数ではなく環境変数に格納し、コードから分離する。
• Web Appsのアプリケーション設定から行う
• App Configurationを使う
• Azure Key Vaultを使う
• Managed Identityを使う
Access Policy
環境変数 キー
キーコンテナー
App Services Azure Active
Directory
Key Vault
Managed ID 認証 認可

25. Factor7.ポートバインディング
ポートバインディングを通してサービスを公開する
Webアプリケーションとして公開可能な自己完結形式
• ビルトインサーバーがあること
• ASP.NET Core : Kestrel (HTTP(S)/WebSocket/Reverse Proxy)
Kestrel Application Code
HttpContext
ASP.NET Core Application
Kestrel Application Code
HttpContext
ASP.NET Core Application
http/https
Reverse Proxy Server
IIS, Nginx, Apache
http/https http

26. Appendix
⚫ アプリケーションの移行パターンと例
https://docs.microsoft.com/ja-jp/azure/cloud-adoption-framework/migrate/azure-best-practices/contoso-migration-overview
⚫ Windows Server 2008/2008R2移行サイト
https://www.microsoft.com/ja-jp/cloud-platform/windows-server-2008
⚫ Azure Migration Center
https://azure.microsoft.com/ja-jp/migration/migration-journey/
⚫ Cloud Adoption Framework
https://azure.microsoft.com/ja-jp/cloud-adoption-framework/
⚫ Well-Architected Framework
https://docs.microsoft.com/ja-jp/azure/architecture/framework/
⚫ Cloud Assessment Tool “KOSMISCH”
https://kosmisch.jp/
⚫ Azure Architecture Center
https://docs.microsoft.com/ja-jp/azure/architecture/

27. © Copyright Microsoft Corporation. All rights reserved.