[DT08].NET とクラウド ネイティブ ～ 本格化するクラウド移行とそのアーキテクチャ / 2019年5月30日
TL;DR（要約）
- クラウドネイティブと呼べるのは、Caas、Pass, Faasとなる。クラウドネイティブの中でどの部分においてもAzureを使うことができる。
- これからの技術要素として、コンテナー（Docker）は外せない。高速起動でアプリケーションを展開したいという場合に、Dockerは優位になる。Visual Studioにおいても、Dockerのサポートは十分にされている。
- 小さいサービスで機能を分離するマイクロサービスの考え方が大事になる。 .NET マイクロサービスアーキテクチャリファレンス 、およびドキュメント（PDF）に詳しいので、ぜひ読んでほしい。
リソース
クラウド側の需要は増していく
前編でも話したように、クラウド側の需要はより増していく。
歴史を振り返ってみよう
2002年ごろは
2002年は、動画で流した通り、.NET Frameworkが発表された年
動画の中では、女性の管理者がいて、サーバー管理者がいて、オーダーをいっぱい受け付けてピークが来た時にサーバー管理者を心配して、様子を見に行く。
すると、サーバー管理者が、余裕ですよ！と.NET Frameworkが、高負荷な環境でも耐えうる性能を持っているということをアピールするコマーシャル。
現在は
そのころと違うのは、今はサーバーを心配する時代ではない、ということ。
今は、ハード面については、クラウド事業者に任せ、クラウドがすべてを解決する時代。ハードウェア、サーバーのスケーラビリティは、クラウドが面倒を見てくれる。
クラウドの利用形態とAzureのサービス範囲
この図はクラウドの利用形態により、どの部分をユーザーが管理し（青色）、どの部分をベンダー（クラウド業者）が管理をするか（緑色）ということを示した図となる。
利用形態と特徴
| 利用形態 | 特徴 | クラウドネイティブ |
|---|---|---|
| オンプレ | ハードウェアの保守部分までユーザーが行う必要がある | × |
| Iaas | 仮想化までをクラウド側で行う | × |
| Caas | 仮想マシンと異なり、OSをユーザー側で考慮する必要はない | ○ |
| Paas | スケーリングを考慮する必要がある。 | ○ |
| Faas | スケーリングを考慮する必要がない。クラウド側で適切に行ってくれる アプリケーションの実装に集中することができる |
○ |
| Saas | Office 365などを指す | × |
この中で、クラウドネイティブと呼べるのは、Caas、Pass, Faasとなる。
Faasとは？
Serverless Function（Azure Functions）を使用する形態を指す。関数を呼び出した瞬間にのみクラウドのリソースを使用する
クラウドネイティブ（Cloud Native）とは？
Cloud Native Foundationが定義し、能力と技術との対応を示している。
では、クラウドネイティブが全て兼ね備えていないといけないのか？、というとそういうことはない。
この図の解釈としては、クラウドネイティブのアプリケーションを構築する場合は、こういった要素を意識して構成してもらえるといい、というものになる。
.NET のクラウドネイティブを支えるAzureサービス
クラウドを使用するにあたり、.NETが元気ないのでは、という心配を受ける声もあるが、そんなことはない。
- クラウドネイティブの中でどの部分においてもAzureを使うことができる。
- Iaasが必要であれば使うことができる
- AKS（Azure Kubernetes Services）をデプロイできる
Azure Function も.NET Core(C#)でコーディングできる。また、SignalRもメッセージの1つとしてスケーラビリティを持たせたサービスとして作ることができる。SignalRを使用して、大きなサービスでスケーラビリティを持たせたい場合に使える。
ML.NET、モニタリング、そしてストレージを.NETのアプリケーションから使用できる。
Containers
これからの技術要素として、コンテナーは外せない。
コンテナとは、一種の仮想化技術でOSレイヤーとは分離した形でアプリケーションを簡単に展開できる
仮想マシンとコンテナの違い
Hyper-Vベースの仮想化マシンは、仮想ドライブのイメージ（VHD）の中には、OSも入っていてドライバも入っているので、基本的には大きいサイズ。Iaasにデプロイもできるが、それなりに時間がかかる。
高速起動でアプリケーションを展開したいという場合に、Dockerは優位になっていくる。
ホストのオペレーティングのシステム上では動作するが、ホストとは分離した形で動くので、よりコンパクトに動いて、高速に展開、動作させることができる
一度イメージを作るとどこでも動く！
一度イメージを作ると、Dockerエンジンが動作しているところに移動すると、ほぼどこの環境でも動作させることができる。
DevからOps側にいざ回したときに、コンパイルすると動かないよ！、ライブラリが足りなかった…、OSの設定が足りなかった…、などの問題を回消するための技術である。DevOpsの中で無駄を省いて、自動化できるところは自動化するというDeVOpsの考えの中で重要な位置づけを占めている。
共通デプロイ単位
つまり、Dockerというのものは、共通デプロイ単位として成立している。
Azure PlatformやAKS、複数のインスタンス、多数のインスタンスを立てるということもできる
これから、自分のアプリケーションを作っていく中では、デフォルトとして考えてもよい。
皆さんが使用されるVisual Studioにおいても、Dockerのサポートは十分にされている。
Web App for Containers
Dockerのイメージを作ってDeployするというのも非常に簡単。もし、マイクロサービスを作らず、シングルサービスを作るうえでも、非常に簡単に行うことができる。
【デモ】Visual StuioでDockerを作る
- Docker Desktopをインストール。
- VSでプロジェクトタイプとしてDockerのサポート入れた上で作製する（Dokcer Compose）
- ターゲットOSを選ぶ。 今回はLinux
- ブラウザが上がってくるが、すでにもうこれは、Dockerで動いている
- サンプルプログラムでは、実行しているOSの種別を表示させるような仕組みを入れているのでLinuxで動作していることが確認できた。
- Dockerなので、アドレスは、localhost
- Docker Engine上で動いているものについてもDebugができる。ブレークポイントが使える。
Microservices
モノリシック
- 昔からあるモノリシックでもよい。もちろん。
- それぞれを1つのコンテナーイメージとして作る
マイクロサービス
- 小さいサービスで機能を分離
- 停止、開始するとき影響が少ない単位でデプロイの面で、非常にメリットになってくる
ではどのように分割しするのか？
- "Micro"だから小さくしなければいけないのか、そんなことはない。オーダーの単位、ビジネスドメインの単位ということであれば、垂直的な3階層が良いこともある。クラウドをどのように使っているのかということを考えて、分割が必要
- アプリケーションの部分だけをMicroサービスとして作っていくことが重要になってくる
Azure Kubernets Services(AKS)
複数のコンテナーを管理していくことによって非常に簡単に行える。
Kubernetesは、環境を構築するまでがなかなか難しいが、AKSを使えば、VMを準備するだけで、Kubenrnetesの準備を行う必要がない
Kubernetesを使う場合のライフサイクル
Azure Dev Spaces
デバッグしながら、ビルドして変更することが必要になった際に、自分だけの名前空間の中に、自分のものをビルドすることができる。
ここで重要なのは、特に、自分だけの名前空間というところ
マイクロサービスのダイレクトコミュニケーション
では、認証トークンを個々のサービスで管理しないといけないのか？ ゲートウェイを介したうえで、Microサービスに渡していくという考え方が非常に重要となる。Microサービスを増やしてもスケールを簡単に行うためのパターンは次のようになる。
ゲートウェイに追い出してしまえば、スケールはAzureが行う。
エンドポイントが一元定期に管理しやすくなる、アプリケーションとしても、固定のエンドポイントを考えればよいし、認証周りの管理も踏まえて、1つのエンドポイントに対して、認証トークンを管理するということで楽になるし、バックエンドについてもAzureに任せると楽になる
一方で、単一障害店になるので注意が必要（APIマネージメントに追い出す）
.NET マイクロサービスアーキテクチャリファレンス
オンライン、およびドキュメント（PDF）。ぜひ読んで！
.NET の移行について
.NET アプリのモダナイズとクラウドネイティブ
まず、.NET アプリケーションとして、通常の構成をクラウドに乗せてみよう。
やり方としては、まずはIaasという考え方になる。しかし、よりクラウドネイティブということを考えると、
モノリシックだとしてもコンテナー構成とすることで、アーキテクチャを変えないまでも、クラウドに親和性が高いアプリケーションとすることができる。
最終的にはコードの変更が必要となってくる。
.NET Coreと.NET Framework
移行パターン（.NET Framework）
まずは、VMとして載せて、アプリケーションだけを追い出す。次に、Windows Containerとしてやっていくのが運用として楽なのかもしれない。
ただし、クラウドネイティブなアプリとして最終的なおすすめは、Azure App Serviceとなる
移行パターン（.NET Core）
.NET Core では、Linuxコンテナーを使用することができ、デバッグもできる。
最終的なおすすめは、Linux Containersとなる
同世代の .NET Core 3.0 では Windows 限定機能(WPF, UWP)にもついに対応する。もう .NET Framework の方でしか使えない機能が残っていない。
新規案件で .NET Framework を使うメリットがもう何もない、
保守モードな既存のアプリでは .NET Core への移行は必要ない。そのための「保守アップデート」が .NET Framework 4.8となる。セキュリティパッチとかはきっちり当てて出す
3.5と4.8
無理に移行する必要は特にない。3.5についてもOSがサポートされている限りは、問題ない。
