Microsoft de:code 2019に参加した内容を紹介します。
Chalk Talkなので、スライド公開のみとなっています。
もし間違いなどあれば、ご指摘いただけますと助かります。
[DT52] ベテラン技術者に聞く、「その .NET アプリ、クラウドでどうモダナイズするの!?」 / 2019年5月30日
TL;DR（要約）
- 日本政府でも、クラウドネイティブ、デジタルファーストという考え方が進んでいる。クラウドが基本！である。
- しかし、クラウドネイティブではなくても、コンテナをベースとした、.NET Coreを進めたほうが良い。ロードマップが発表されたのは久しぶりのこと。勇気をもって、自分の命を懸けて！リアーキテクチャしてほしい！ とりあえず塩漬け（Iaas）もよいが、Paasなどを採用し、良いコードを書く、という風に持っていってほしい
- 政府から出ているディスカッションペーパー、その中のアプリケーションの設計・開発の考え方に沿った提案が出てくるのではないか。
リソース
タイトル
初めに講師の方から
- .NET Coreを使用する技術者を育てないといけない
- [リアーキテクチャ]していかないといけない
- Javaと仲がいいのはいいが、Javaに書き換えないといけないんですか？という話になったのでこのセッションを開いた
すべてのアプリのための統一プラットフォーム
なぜクラウドでモダナイズするのか
- サーバーメンテするのが面倒なので、サーバーを持ちたくないな、というのが、最近の業界の統一見解となっている。ハードウェアを持ちたくないのと、メンテナンスと検証の時間が面倒である。
日本政府の取り組みなどについて
世界最先端デジタル国家創造宣言
世界最先端デジタル国家創造宣言や、官民データ活用推進基本計画が立ち上げられている。現状としては、ハードウェアを持っているベンダーも多いためなかなか進まない
デジタルファースト法案、可決成立
行政手続きを原則、電子申請に統一するデジタルファースト法が24日、参院本会議で可決、成立した。引っ越しや相続などの手続きがインターネット上で完結できるようになる。2019年度から順次実施する。利用者の利便性を高めるとともに、行政の効率化につなげる。
マイナンバー法と公的個人認証法、住民基本台帳法などを一括改正する。(1)手続きをIT（情報技術）で処理する「デジタルファースト」(2)同一の情報提供は求めない「ワンスオンリー」(3)手続きを一度に済ます「ワンストップ」――の3つの原則が柱となる
パスポート取得についても、ワンストップサービスでないといけない、ということを義務付ける。今までは、国の基盤の中で進めていたが、民間クラウドを使っていこう、という流れになっている。クラウドが基本！
どうやってクラウドが基本！という流れに、顧客に勧めていくのか？
.NET アプリケーション最適化モデル
今日提案しようと思っているのが、Paasを使用した既存.NETアプリのクラウド最適化である
順番に持っていこうということではなくて現在のアプリの種別ごとに落としていこうという形
ここで演者の1人から！
単純なリフトアンドシフトには反対。別にクラウドをやりたいわけではなくて、デベロッパーを増やさなければいけないはず
リフト＆シフト（リフトアンドシフト）とは
リフト＆シフトという言葉は、当初は「オンプレミスからアプリケーションをリフトして、クラウドにシフトする」といった意味合いで理解されていましたが、最近は「クラウドにリフトして、クラウドネイティブな仕組みにシフトする」という意味に解釈されています。
本題に戻って
コンテナをベースとした、.NET Coreを
クラウドネイティブではなくても、コンテナをベースとした、.NET Coreを進めたほうが良い。
ロードマップが発表されたのは久しぶりのこと。ASPも含めてアーキテクチャはだいぶ違っている。
勇気をもって、自分の命を懸けて！リアーキテクチャしてほしい！
中心となるのはデベロッパーなので、.NET Coreをベースとしてほしい！
コードを書き換えることを恐れないでほしい！
コードをに手を入れるということについて
いわゆるアプリケーションの機能要件が変わらないのに、コードをに手を入れるということについて、なかなか理解が得られない。
アプリケーションの業務要件が変わらないのにコードを変更する、そこをデベロッパは恐れないでほしいし、偉い人に押せるようにしてほしい
とりあえず塩漬けで持っていく（Iaas）ということもよいが、それだけではなくて、Paasなどを採用し、良いコードを書く、という風に持っていってほしい
クラウドバイデフォルトの推進
クラウドバイデフォルトを推進するという流れになっているため、公共関係は予算がとれる。では、民間相手にはどうやって予算が下りるのか
.NET アプリケーション最適化モデル
今からやるなら、ASP.NET Coreである。
.NET Frameworkも残るけどメンテナンスモード、新機能はのせないよ！という話となる。新しい機能が出てきた場合に、.NET Frameworkに入ることはない。
もう1つ考えればよいのは、WebFormsを使っている人が多いが、.NET Coreでは、Web Formsがメンテナンスモードになってしまった。
その場合の行き先としては、Blazor。SPAもできるし、サーバーサイドでやっていた人が行くものとしては良い移行パスである
ディスカッションペーパー
アプリケーションの設計・開発の考え方
政府から方針がでている。政府のペーパーに沿った提案が出てくるのではないか
クラウドの非機能要件・運用管理
運用管理について、オンプレとクラウドに違いがあるのではないか。
おすすめとしては、Azure アーキテクチャセンターである。24時間365日自動監視 障害一次対応を行ってくれる。
Paas運用管理の仕組み
聴講者とのQA
クラウドにおける運用管理で困っていることは？
Q:顧客がSQLサーバーを買うという形態の場合はどうすればよいか
ライセンス的な話かと思います。サブスクリプションで売れるということがあるので、セッションの後で紹介します。
Q:ログが分散したときにコンテナ間のログをどのように見ていけばよいのかがわからない
1つ1つの監視をするかKubernetesに任せていく方向が良い。
モニタリングツールをどうするか、という問題が出てくる
- OSSでやり続けるのか、クラウドの監視サービスを使うのか
- 迷ったときには実際に運用するメンバーも考えて選択したほうが良い。開発者の視点だと分かりにくいが、実際には運用するベンダーを探すという方法も考えるか、APIのホップ数を減らすということも考える。やりすぎると、追いづらいしパフォーマンスも遅くなる。
アプリケーションについては、FailSafeに設計しておけば、気が付かないうちに復活していく。具体的にはChaos Monkeyを使用する。
Q:うちでやっている案件で、マイクロサービスを使うと依存性が多くなってしまう
障害が発生したときに、発生個所以外が本当の原因ということがある。
最初に関係図を作成する
-
サービスが停止することよりも、データが消えることのほうがクリティカルな障害
- SLAも大事だけど、データが消えないように設計を行っておくことが大事
- 冗長性をとるとデータが二重になる。データが2重になってもよいようにユニーク性を考えたほうが良い
マイクロサービスを細かくしすぎない。
結果性を保つことはできない。マイクロサービスの中で完結したほうが良い。連動して動くようにすると難易度が多いし、デッドキュー
ちょうどよい粒度というのは、アクターベースで作っていくとよいのではないか。データの整合性だけを考えると、マイクロサービスに切れない。進化するユースケースを書き込んで、自己完結するサービス
-
大きくしすぎると、わかりにくい
- 出荷できるサイズがマイクロサービスのサイズ。出荷できるサイズをチームで決めてやっていく
アジャイルすると早くなるというのは幻想
- 戦略を考えてどういうサービスにしていくのが大事。どういう戦略をするとき（全体戦略、システムあーきてくちゃ）ということを考えて、設計していくことが大事
コンテキストマップについて
ユースケースという話が出てきたが、ドメイン駆動開発を採用するのが良いと思う
-
コンテキストマップ
- コンテキストマップこそが戦略なので、こういうユースケースを作るためのシステムである。レガシーはボックスにまとめて、古いシステムをラッピングする
