SimpleModel/テクノロジー

クラウド・アプリケーションを構成する以下の各種要素技術に対して、SM2020のメタモデル設計の方針検討を行っています。

• 関数
• CQRS
• Event Sourcing
• Eventually Consistency
• マイクロサービス
• BigData
• AI
• IoT
• DevOps

前回はCQRS、Event Sourcing、Eventually Consistency、マイクロサービスについて検討しました。

今回は、BigData、AI、IoT、DevOpsについて検討します。また、検討項目にDXを追加することにしました。

BigData

アプリケーション実行中に得られるデータを分析して、有益なデータを抽出し、アプリケーションにフィードバックして活用することが普通になってきました。アプリケーションの基本機能として、実行結果データの分析が必要となってきているといえます。

BigDataを実現する仕組みとしては、以下のような構成を取ることになるでしょう。

• アプリケーションの実行結果の記録機構
• アプリケーション実行結果データの収集・保管機構
• 保管データ整理機構
• 整理データの分析機構
• 分析データのアプリケーション取込み機構

アプリケーションの実行結果の記録機構はログまたはデータベースに記録することになります。

アプリケーションでは採取するログデータと記録用のデータベースのエンティティが設計のポイントです。

アプリケーション実行結果データ収集・保管機構はdata lakeやdata warehouseといったサブシステムを中心としたメカニズムになります。

アプリケーションではdata lakeやdata warehouseの基盤の上でデータフォーマットの調整などが主な仕事となるでしょう。

保管データ整理機構はdata lakeやdata warehouse上に格納した生データから、分析に適した正規化を施したデータを作成します。

アプリケーションでは分析に適した正規化データの設計が必要になります。

整理データの分析機構はHadoopやSparkといった大規模演算基盤上に構築したバッチやイベントハンドラとして実現することになるでしょう。

アプリケーションでは、アプリケーションのユースケースに沿った活用方法で直接使用できるデータに変換する処理を行うことになります。

分析データのアプリケーション取込み機構は整理データから作成したデータをアプリケーション側に取り込む処理です。

アプリケーションではデータを取り込むための受け皿としてデータベースのエンティティなどを用意する必要があります。

モデリングの検討

アプリケーションの実行結果の記録機構に対して、アプリケーションではログデータのフォーマットと記録用のデータベースエンティティの設計が必要になります。

アプリケーションのモデリングの観点ではログのフォーマットはデータの最終的な利用方法から逆算して必要十分な情報が取得できるように設計することになります。このため、ユースケースモデルからの一連の連鎖でログのフォーマットまでモデルの連鎖を追跡できると理想的です。

データベースのエンティティという観点では、SM2008からeventエンティティを用意しています。eventエンティティによってアプリケーション上重要な出来事はデータベース上に記録されるので、ここからBigDataに必要な情報を収集することができます。

アプリケーション実行結果データの収集・保管機構から保管データ整理機構にかけてはデータ変換処理になります。

整理データの分析機構に対してもデータ変換処理という観点で考えればよいでしょう。

分析データのアプリケーション取込み機構に対しては、SM2008からsummaryエンティティを用意しています。整理データの分析機構で生成したデータをsummaryエンティティに書き込むことで、アプリケーションで利用することができます。

AI

AIは大きく分けて、従来型の知識ベースや推論エンジンによるAI(推論型AI)と、最近主流となっている学習型AIの2種類があります。

推論型AIに対してアプリケーションでの利用の観点では、外部のサブシステムとして用意したAIエンジンを手続き呼び出しで使用するという形になるでしょう。

一方、学習型AIの場合はアプリケーションの実行結果を使用して学習を行う必要がある点が異なります。このため、アプリケーションとは密結合のアプローチとなります。

学習型AIでは実行結果に対して何らかの計算を行い、計算結果をフィードバックするという処理になりますが、これは前述のBigDataと基本的には同じものです。BigDataの場合はSQL的な集計処理になりますが、学習型AIの場合は深層学習などの複雑な計算になる点が異なります。

モデリングの検討

SM2008ではAIシステムの設計はスコープ外で、外部のAIシステムを利用するというアプローチを取っています。SM2020でも基本的なプローチは同じです。

ただし、推論型AIと学習型AIではモデリングのアプローチもかなり異なりそうです。それぞれについて検討します。

推論型AI

推論型AIの実現方式は外部のAIシステムをRPCなどで利用するという形になります。アプリケーションのモデリングの観点ではこれをアプリケーション内のモデルでどのように表現するのかという選択になります。

シンプルなのはAIサブシステムをサービスとしてモデル化しオペレーション呼び出しで利用する方法です。

ドメイン知識などを保持したエンティティとして実現したい場合は、SM2008から用意しているruleエンティティを使用します。

学習型AI

学習型AIの場合、エンジンそのものは推論型AIと同様に外部システムとして利用する形を想定していますが、アプリケーションの実行結果のデータを使って学習を行う点が大きな相違点です。

学習データの取り込み方式は基本的に前述のBigDataと同じものになります。このためBigDataで議論したアプローチを取ることになります。

学習型AIをアプリケーションから利用する方法ですが、以下の3つが考えられます。

• サービスへのオペレーション呼び出し
• ruleエンティティ
• summaryエンティティ

サービスへのオペレーション呼び出しとruleエンティティは推論型AIと同じアプローチです。

summaryエンティティはBigDataと同じアプローチです。

IoT

ビジネス・アプリケーションあってもIoTを扱うケースが増えてくるのは確実です。アプリケーションでIoTを使う場合、IoTの基盤機能そのものを自ら実現するのではなく、外部のIoT基盤を外部サービスとして使用する方式を想定することにします。

IoT基盤とアプリケーションの接続方式として以下のものが有力です。

• RPCによるオペレーション呼び出し
• RPCによるコールバック
• サービス・バスによるイベント駆動
• リアクティブ・ストリームによるイベント駆動

RPCによるオペレーション呼び出しはIoT基盤の提供するAPIのオペレーションを、アプリケーションから直接呼び出す方式です。

こちらは、アプリケーションからIoT基盤側を呼び出す方式ですが、IoTの応用では逆にいイベント駆動であるIoT基盤からアプリケーションを呼び出す方式が主となります。

RPCによるコールバックはIoT基盤にコールバックを登録し、コールバックでイベント駆動処理を行う方式です。

サービス・バスによるイベント駆動は汎用のサービス・バスにコールバックを登録し、コールバックでイベント駆動処理を行う方式です。IoT基盤で発生したIoTイベントをより汎用的な形に変換してサービス・バスに流し、サービス・バスに登録されているアプリケーションのイベント・ハンドラを起動します。より汎用的なサービス・バスのイベントを使用する点が異なります。

RPCによるコールバックとサービス・バスによるイベント駆動はいずれもイベントハンドラによるコールバックによる実現方式です。このため、アプリケーションの規模が大きくなるとコールバック地獄と呼ばれるアンチパターンに陥る可能性が高まります。

この問題の解決方法として有力なのがリアクティブ・ストリームです。

関数の回でも取り上げましたが、イベント駆動型のアプリケーションはリアクティブ・ストリームで記述するのが関数型時代の定石といえます。

モデリングの検討

IoTアプリケーションのモデリングはモデル駆動アプリケーションのモデリングという側面が大きいといえます。

イベント駆動というアプリケーションの特性からはコールバック処理がアプリケーションの軸となりますが、いわゆるコールバック地獄とよばれるアンチパターンになりがちです。

コールバック地獄を起こさずイベント駆動のアプリケーション・ロジックを記述する手法として期待しているのがリアクティブ・ストリームです。

リアクティブ・ストリームは一種のパイプラインなので、パイプラインとして抽象化することでモデル化が可能と思われます。ただ、伝統的に使用されているデータフローより動的な側面が大きいと思うので別のメタモデル要素を導入するのが妥当と考えています。SM2020ではこのあたりの検討を行う予定です。

IoTアプリケーションの特性からはイベントの階層化の設計が重要です。SM2020では以下の階層で対応するアプローチを検討中です。

• IoTイベント
• 生イベント
• ビジネス・イベント

イベント駆動で使用するイベントはeventエンティティと連携するのがSM2008のアプローチでした。SM2020でも引き続きこのアプローチを軸に考えていますが、IoT対応で発生するイベント階層との対応関係について整理していく予定です。

DevOps

DevOpsはソフトウエア開発と開発したソフトウェアの配備や運用などを統合した考え方で、運用配備を含めたソフトウェア開発の自動化と見える化を目指しています。

2000年代初頭の段階では、なかなかそこまでは実現のスコープに入ってきていませんでした。

UMLでも配備モデルを記述することは可能でしたが、当時はChefなどのDevOpsのライフサイクル全体をカバーした配備・運用ツールなどは存在せず、配備モデルも青写真レベルに留まっていることが一般的でした。

現在ではツール類を始めとした環境が整っているので、本格的なモデル駆動開発への組み込みも可能と思われます。

モデリングの検討

アプリケーション・モデリングの観点では以下の点が重要と考えています。

• 配備モデルの定義と適用
• 運用性を高めるためのモデル要素
• テスト性を高めるためのモデル要素

モデル駆動開発にDevOpsを適用することを考えると、作成したアプリケーション・モデルを直接、配備や運用の記述データとして使用できると理想的です。この中心となるのが配備モデルです。配備を考えていく上では、モデルの物理的な側面を記述するコンポーネントやモジュールといったモデル要素が重要になってきます。

SM2008では配備モデルはスコープ外でしたが、SM2020ではDevOpsの観点で配備モデルの設計を行っていきたいと考えています。

運用性を高めるためのモデル要素としては、エンティティを監視するための属性の追加といったものが考えられます。JMX(Java Management Extension)といったプラットフォームのモニタリングツールと連動させることによって運用性が高まります。

このような監視のための属性を抽出するためには、運用フェーズのユースケース分析なども必要になってきます。

テスト性を高めるためのモデル要素としては、エンティティの内部状態を見える化して検証可能にするための属性追加といったものが考えられます。

運用性やテスト性を高めるためのモデリング上のアプローチは他にも色々あると思うので、SM2020の中に取り込んできたいと考えています。

DX

DX(Digital Transformation)は色々な切り口があると思いますが、ここでは企業システムを最適化したビジネス・モデル、業務プロセスをサイバー空間上で新規構築すること、とします。

基幹システムの入出力の部分を紙ベースからIT化するというものであれば、OOAD(Object-Oriented Analysis and Design)の出番は限定的ですが、ITベースのビジネス・モデル、業務プロセスを一から設計するとなると、超上流からOOADによるモデリングが必要になってきます。

ビジネス・モデリングを受けてのアプリケーション開発では、通常のOOADによるモデリングになります。

IoTと同様にDXの場合も、DX基盤といったものを軸にアプリケーション構築を行うようになるケースが多いと考えられるので、モデリング段階では抽象度の高いモデルで設計しDX基盤向けのコードを自動生成するというようなアプローチが有効と思われます。

モデリングの検討

SM2020はビジネス・モデリングはスコープ外ですが、ビジネス・モデリングで作成したモデルをモデル駆動開発用に連携させていくことでモデル駆動開発に組み込むアプローチを取っています。ステレオタイプといった拡張機構を使用して超上流のモデルをSM2020内に埋め込んだりリンクを張ったりといった連携を想定しています。

DXアプリケーションのモデリングについては、IoT基盤との連携を軸に検討していく予定です。鍵となるモデルはワークフローと状態機械と考えています。

まとめ

今回は、BigData、AI、IoT、DevOps、DXについて検討しました。

前々回、前回と合わせて以下の項目について検討しました。

• 関数
• CQRS
• Event Sourcing
• Eventually Consistency
• マイクロサービス
• BigData
• AI
• IoT
• DevOps
• DX

全体としてイベント駆動アプリケーションのモデリングがさらに重要になってきていると感じました。

このため状態機械の価値がさらに高まりました。状態機械は従来は現場の開発ではあまり活用されてきていないと思いますが、モデル駆動開発の助けを借りて本格的に活用していく必然性が増してきたかもしれません。

また、アプリケーション全体の振る舞いを統合する概念が重要になってくると思います。一つのアプローチはユースケースをハブにして帰納的に束ねていくことでしょう。ユースケースの価値もさらに高まってきたと思います。

特に重要と感じたのが以下の3つのフロー系のモデルです。

• データフロー
• ワークフロー
• リアクティブストリーム

SM2020ではこれらのモデルについてモデルのセマンティクスと記述方法、使い分けの指針などの整備に力をいれていきたいと思います。