[SPL-001] de:code special session ～マイクロソフトが考える 5 年後を見据えた技術提言～

第1日目 13:25～14:25 ( Room C )

マイクロソフト コーポレーション 萩原 正義, 日本マイクロソフト株式会社 荒井 省三, 高添 修, 野村 一行

このセッションのポイントは、マイクロソフトが5年後の技術の予想をもとに提案する「既存の技術の移行（守りのIT）ではなく、新しいものをどう作るか？」についての考え方です。

Microsoft の提言

ニーズよりも、問題や価値に着目
予見不可能なビジネスには迅速な試行錯誤
継続は力、変化への対応（サービス化）
将来性のあるITシステム、技術への投資のための目利きを
限られたリソース、オープンなイノベーションを活用

今流行の「ビッグデータ」は今後どうなっていくのか？

具体的なビジネス・運用を考えたアーキテクチャについて触れていきます。

サービス化 – 機能や価格の差別化では競争できない

将来のトレンドをみていくうえで重要な考え方が「サービス化」です。現代では、モノはいきわたっているため、ヒトはモノが欲しいではなく「体験」に興味があります。その上で何ができるか？を考える必要があります。

車を所有する代わりに、車を借りてもいいと考える人が多くなりました。

「住む」という観点でも、家を買う代わりに、賃貸でもかまわないという考え方もあります。

クラウドの今はそれに似ています。ソフトウェアの「機能」が使えればいい。それは（SLA = 非機能要件など考えるべき事貼りますが）クラウドをソフトウェアのサービスとして使うという時代になっていくと思います。

クラウドのサービスを「共有」で使う、という点も「シェアハウス」の考え方と同じと言えます。

「所有する」と買い替えを継続しなければ新機能が使えません。

「サービス」であれば、常時改善がおこなわれているなら使い続ければいい。

「所有する」と自己責任が生まれます。

「サービス」であれば、サプライヤー、プロバイダーの責任であり、故障が起きると自分の損失になるためいち早く改善されるでしょう。将来の故障に対して予見するのも、また、プロバイダの責任です。

現代では、情報が瞬時に普及し、多くの人が知ることになるため、機能や価格の差別化だけで、他社より競争力を高くすることはできません。サービス提供の速さ「生産性」と、真似されるよりも早く提供し続ける「仕組み」が必要となります。

リーンエンタープライズ – 問題指向アプローチ

リーンエンタープライズは、今までのアジャイル、DevOps と近いものですが、それよりももうちょっと上のビジネスレイヤを取り扱っていきます。

ヒトは多くの場合、問題の解決＝解決指向 のアプローチで考えすぎる傾向にあります。しかし、アインシュタインは「問題の定義が80%」と言いました。解決の仕方を考えるのではなく、できるだけ「問題」のまま正確に定義し、開発のサイクルで回すことが求められます。

そこで、リアクティブパラダイム（Reactive Paradigm）が必要となります。

開発では「マイクロサービス」 = Resource as a Service の考え方。運用では「データパイプライン」＝「データの収集・データの分析」から問題の再定義が必要です。

新しいアプリケーションアーキテクチャによって、サービス化への流れ、とくに「早期投入」を実現することを考えます。

マイクロサービスアーキテクチャ Microservices Architecture (MSA)

アプリの歴史は、肥大化問題への対処の歴史でもあります。

• デスクトップ
• クライアント・サーバー
• UI・ビジネスロジック・データ（3層アーキテクチャ）

よく知られたアプローチですが、結局、システムは複雑化して、保守は難しくなりました。

特に連携するサービス同士での依存関係が切り離せなくなることが大きな問題でした。これに対する新しい時代の現実解が、Microservices です。

Microservices とは、サービスの提供（生産性）を早くする考え方です。これまでもサービス指向アーキテクチャはありましたが、これまでのモジュール化では不十分でした。

デバイス・API・サービス ……

サービスを非常に小さな集合体に分けることで、レイヤー間の依存関係のとらわれない改善が可能になります。

そのために、これまでよりコンパクトに、経済効率性を高く、リソースの配置を考える必要があります。

• より徹底したコンポーネント化
• ビジネス能力に基づく分割
• ガバナンス・データ分割

どこまで細かく分けるべきか？ということは、まだこれからの議論ですが、例えば「商品の価格」そのものが Microservice になり得ます。価格決定は非常に重要なビジネスであり、それぞれの商品の価格が、それぞれサービスとして使用され、常に価格が変動しているというのも考えら得るシナリオです。

何が Microservice か？と判断するには、次の点で考慮するとよいかもしれません。

• 単一の責務
• 別々のアーキテクチャ
• 障害のための設計

例えば、PHP で作るべきものと C# で作るべきもの（すでに作られたサービス）は、それぞれを合わせて一つのサービスにするべきではない。それぞれ別で作成され運用される、別のサービスであるべきだと、考えるべきです。アーキテクチャが異なれば、それに伴って、責務も障害の対応も異なるのが自然です。これらを、やはり、混ぜるべきではない。無理に一つにすべきではない、というのも Microservice の重要な考え方です。

マイクロソフトが描く今後のクラウドサービス – 日本のIT技術者が Microservices 実現できるか？

今までのIaaSは「3層アーキテクチャ」をベースにしています。

そのため、どうしても依存関係ができてしまう　－　これを壊さずに開発しなければならない　ー　チームの独立性が損なわれてしまう のが問題でした。できるだけ自立的にコンパクトなチームで、それぞれのエリア「サービス」ごとに 分担する ことが重要です。

日本のIT技術者が Microservices 実現するためには、次の点がポイントとなります。

• ３層モデルからの卒業　その先へ
• 開発チームの規模　ビジネス機能単位　の組織構造に変更できるか？
• サービス間のデータ連携

サービスの継続的改善では、テレメトリー( telemetry 遠隔測定の意？) によるモニタリングを通じたインサイト（Azure Application Insight） ー ログを集めて、収集して、管理して、分析して、可視化　－　という「データパイプライン」が押さえておくべき重要な技術となります。

また、データをためるための技術としては、柔軟なデータ形式をそのまま管理、分析に持っていく　－　非構造化データをそのまま保存　し、機械学習 ( Machine Learning : ML ) にかける、ということが 5年後には「普通」になっている。どんなITシステムにも使われていると思われます。これらは、アーキテクチャの最適化に使われていくことでしょう。

プログラミング パラダイム を変えよう – forループ処理ではなく LINQ で実現するという感覚

現代のオブジェクト指向プログラムでは、問題ドメインと解決ドメインが直接繋がりません。

一番わかりやすい例では、for などのループ処理。実際には一覧の中からある特定の条件のモノを抜き出して、その値の合計を計算したい場合、for ループ処理で実装するとプログラムでは if 条件式と 加算していくという構造がループ処理の中に実装されます。しかし、これを LINQ 式で実現すると次のように書けます。

var sum = data.whare(条件式).sum();

このように、やりたいことをやりたいことのまま実現出来て、ループの呪縛から解き放たれる、というが Visual Studio 2005 で初めて登場した LINQ の魅力でした。この考え方は、関数型言語のエッセンスを取り入れた非常に重要なモノです。

この本当にやりたいことを「再利用可能なアルゴリズム」としてとらえることが、問題の再定義に繋がります。

問題ドメインがいくつもの解決ドメインと繋がって、最終的な結果が導き出されるとき、どうやったら直接最終的な解決をできるか？解決ドメインのショートカットを作るということが「問題を再定義する」ということになります。

解決ドメイン（for文）にとらわれていたのでは、本質的な解決へのショートカットを考える（LINQ式を全体を眺めて組み替えて短縮する）ようなことが難しいのです。この発想で問題をとらえていくことが非常に重要です。

オブジェクト指向では、全体を一つのオブジェクトとして、その「プロパティ（状態）が変化している」ととらえてしまうような問題も、ストリームとしてみると（状態が変化しているとはとらえずに）、時間によって異なる データ オブジェクトが沢山ある、というように捉えることが出来ます。

「手続き」ではなく、「変わる」ということには、オブジェクト指向ではなくストリームとしてのとらえ方で対応することが重要です。

これらの「関数型プログラム」の考えを取り入れて応用していくことが大切です。

Microservice とは「15年経って壊れたエアコンを修理するか？」ということ

15年使って壊れたエアコンを修理しますか？（良いか悪いかは別として）買い替えるのが普通ですよね。その間の、技術革新はめざましく、修理した場合はまた壊れる可能性が高いでしょう。また修理するには、故障箇所を特定する必要がありますが、これが非常に難しい可能性もあります。

Microservice は非常に小さく、変更が必要になったときに書き換えるのではなく、新しい Microservice を作って差し替えることが出来ます。クラウドなら容易にできる「買い換え」と同じ発想です。

運用中の構成を変えるのではなく、新しく構築した構成に置き換える

モジュール、コード、インフラ・・・全てが新しいモノに置き換わる

この発想にマイクロソフトのプラットフォームも応えていきます。

OSの仮想化が既に実現されていますが、これからはアプリケーションの定義まで含めた上でごっそり入れ替えてしまいたい。それを実現する「コンテナ」という技術が注目されています。Microsoft はこれを実現する Docker に力を入れています。

Docker では、アプリケーションをパッケージ化して、OSを介さずに直接ハードウエア上で実行することが出来ます。これによって、ローカルの開発環境では OS 上でアプリケーションを動作させ、実際の運用環境ではコンテナによってハードウエアに直接配置して動作させる、ということが可能です。より効率的に、どんどん新しいモノを作って置き換えることが可能となります。

コンテナは分散クラスタリングでも注目されています。沢山のタスクがあって、それを処理しなければならないとき、最終的な目標に達成するために何をすれば良いのか？考える必要がなくなります。プラットフォームを考えずに、ただ「投げておけば良い」時代になります。そのための抽象化レイヤ実現のためにもコンテナが活躍するでしょう。

アプリケーションをパッケージ化しておかないと、いざ必要になったときに「大量に展開」ということがで来ません。

まだ適切な答えはなく、これから実現方法が検討されていくはずですが、最大のポイントは SLA（サービス品質保証）を如何に守るか？処理を公平に分散しないと、SLA を保つことは出来ないということを考えなければなりません。

処理は最終的にハードウエアが実行します。汎用プログラムが汎用CPUで動作する、と、どうしても効率的ではなく、間に沢山レイヤがあるのが不要になる場合があります。これら邪魔なモノをスルーして処理できるように、FPGA(Programmable board) という技術があります。仮想マシンに物理ネットワークを直接使えるように構成する場合に近い考え方です。この「プログラムできるハードウェア」は、株価の計算など、ある特定の計算だけ超高速に行いたい場合に使用されます。

マイクロソフトはこれらのほぼ全ての要素技術を保有しており、開発者は Cloud First ですぐに利用・検証をスタートすることが出来ます。

Resource as a Service – Microsoft の「価値の提供」

テクノロジーは新たに生まれ、淘汰され、洗練され、ビジネスにとって有益なものに進化し続けます。

その中で、マイクロソフトは Cloud OS を支える Resource (Technology) をサービスとして提供することで、時代のニーズに応えられるように、価値を提供できるようにします。

・・・

それが Aure であり、だからこそ「Microsoft の提言」を受け止めて、Azure をどう活用して自分達の価値を提供できるか？考えていければいいな、と私は感じました。

コメント