マイクロサービスと効率的なアプリケーション開発とマルチエージェントシステム

マイクロサービスと効率的なアプリケーション開発とマルチエージェントシステム

マイクロサービスパターン「実践的システムデザインのためのコード解説」より。

“マイクロ”にはエンジニアの探究心をくすぐる響きがある。そして”サービス”、これがソフトウェアコンポーネントを意味することは明らかである。ソフトウェアエンジアであれば、ソフトウェアコンポーネント化の手法に関して興味を抱くことも自明であろう。加えてエンジニアでなくても、英語に不慣れでも”マイクロサービス”が小さなサービスを意味することも自明となる。

しかし、このわかりやすいネーミングは混乱・誤解の元でもある。マイクロサービスの技術的説明の際にうける定番の質問に「小さいってどれくらい?」というものがある。これに対して「マイクロサービスパターン「実践的システムデザインのためのコード解説」の著者であるChris Richardson氏は次のように提唱している「サービスのサイズはあまり重要でない」「マイクロサービスというネーミングの問題点は”マイクロ”が目立っていることだ」とある。

マイクロサービスのゴールとは、素早く、高頻度にアプリケーションを開発、リリース、メンテナンスすることにある。それには、システム開発対象ドメインは小さい方が良いので、ドメイン駆動設計等のドメインを分割するための分析設計手法を活用する。また、開発・運用を担うチームも小さい方が自律的に素早い判断を下しやすい。そこで、コンウェイの法則やアジャイル手法を参考にしながらチーム・フォーメーションと開発運用プロセスを工夫する。

その結果として、成果物のソフトウェアコンポーネントである”サービス”のサイズは小さくなることが多いという傾向にある。”小さなサービス”というのはあくまで結果でしかなく、ゴールではない。場合によってはマイクロサービスであっても”大きなサービス”で運用するケースもあるかもしれない。すなわち、”小さなサービス”という格好から入ってはダメだということをChris Richardson氏は言っている。

それではマイクロサービスとは何なのか? Chris Richardson氏は次のように述べている。「一つのアプリケーションを複数のサービスに機能的に分割するためのアーキテクチャスタイルである」アーキテクチャスタイルとは、建築”様式”のこととなる。構造設計(アーキテクチャ)だけでなく、開発・運用手法、組織体制や運営等、構造物の開発・運用に対する一切合切をまとめたものが”アーキテクチャスタイル”となる。

ウォーターフォール型プロジェクトでソフトウェアコンポーネント設計のみに着目し、小さなサービスを実装してみても、本当にスピーディで高頻度のアプリケーション開発、リリース、メンテナンスに効果があるか疑わしい。設計だけ真似て、それをマイクロサービスと呼ぶのは意味を履き違えているものとなる。アーキテクチャスタイルとして捉え、分析、設計、開発、運用、組織運営等々に対して最適な手法や技術を適用することが重要となる。

Chris Richardson氏が主催するwebサイト”Microservice Architecture“は、マイクロサービスに関するデザインパターンを収集し整理の上、公開しているwebサイトとなる。ここではそれらに基づいたマイクロサービスに関するマイクロサービスアーキテクチャスタイルをまとめたものに加えて、Anuj Kumar氏による”Microservice with Clojureで関数型言語であるClojureを用いたMicroserviceの実装について述べている。

以下詳細について述べる。

理論と実装

• マイクロサービスシステムの概要について

マイクロサービスは、ソフトウェア開発アーキテクチャのアプローチの一つであり、アプリケーションを複数の小さな独立したサービス(マイクロサービス)に分割することを特徴としたものとなる。各マイクロサービスは、個別に開発、展開、拡張、保守が可能であり、独自の機能を持っている。ここではこのマイクロサービスを構成する要素の概要について述べている。

• Unityの概要と外部システムとの連携について

Unityは、Unity Technologiesによって開発され、広く使用されているゲーム開発やアプリケーション開発のための統合開発環境(IDE)となる。Unityはゲーム、VR、AR、シミュレーション等様々な領域で利用されている。ここでは、このUnityとCMS、chatbot、ES、機械学習、自然言語処理等の人工知能システムとの連携について述べている。

• モノリシック地獄からの脱出
• サービスへの分割
• マイクロサービスアーキテクチャで使われるプロセス間通信
• サーガによるトランザクションの管理
• マイクロサービスアーキテクチャにおけるビジネスロジックの設計
• イベントソーシングを使ったビジネスロジックの開発
• マイクロサービスアーキテクチャでのクエリの実装
• 外部APIパターン
• マイクロサービスのテスト
• 本番環境に耐えられるサービスの開発
• マイクロサービスのデプロイ
• マイクロサービスのリファクタリング
• Clojureを使ったマイクロサービスシステム

ここでは、一般的なパターンとプラクティスを学び、プログラミング言語Clojureを使用して適用する方法を紹介する。アーキテクチャ設計とRESTful通信の基本的な概念を学び、開発時および運用時のスケールに対応した管理可能なコードを提供するパターンを紹介する。また、これらの概念とパターンをClojureでどのように実践するかについても例示している。

• モノリシックサービスからマイクロサービスへの移行とサービス設計

よく設計されたモノリシック・アーキテクチャは、多くのソフトウェア・アプリケーションを成功に導く鍵となっていた。しかし、マイクロサービスベースのアプリケーションは、自律的で柔軟であるという固有の特性、独立して拡張する能力、およびリリースサイクルの短さから、インターネットの時代において人気を集めてきている。

• マイクロサービスアーキテクチャの概要

理想的な企業システムは、緊密に統合され、特定の技術スタックとハードウェアに最適化された単一のユニットとして、すべてのビジネス機能を提供するものとなる。このようなモノリシックなシステムは、時間の経過とともに複雑化し、単一のチームによって単一のユニットとして理解することが困難になることがよくある。ドメイン駆動設計では，このようなシステムをより小さなモジュール式のコンポーネントに分解し，それらを，限定されたコンテキストで単一のビジネス能力に焦点を当てるチームに割り当てることを提唱してい。．いったん分解されると，そのようなコンポーネントはすべて自動化された継続的インテグレーション（CI）プロセスの一部となり，断片化を避けることができる．これらのコンポーネントは孤立して構築され、しばしば独自のデータモデルやスキーマを持っているので、様々なビジネス活動を調整するために、コンポーネントと相互作用するための明確な契約が必要である。

ここで、ドメイン駆動設計という言葉は、2003年にEric J. Evans氏が著書のタイトルとして最初に作ったものとなる。Evans氏は、マイクロサービスアーキテクチャの基礎となるbounded contextとcontinuous integrationの重要性を説いている。

• マイクロサービスのためのREST API概要

RESTはrepresentational state transferの略で、分散型ハイパーメディアシステムのアーキテクチャスタイルを定義している。RESTは、ステートレスで拡張性の高い、独立したコンポーネント実装を作成することに重点を置いている。RESTをサポートするアプリケーションは、クライアントの状態に関する情報をサーバー側に一切保存しない。このようなアプリケーションでは、クライアント自身がステートを維持し、アプリケーションによって公開されるHTTP APIなどのRESTスタイルの実装を使用して、クライアントとサーバーの間でステートを転送する必要がある。REST APIを利用するクライアントは、サーバーに最新の状態を問い合わせ、クライアント側で同じ状態を表現することで、クライアントとサーバーを同期させることができる。

• Pedestalを利用したClojureによるマイクロサービスの為のREST APIの実装

PedestalはAPIファーストのClojureフレームワークで、動的な性質を持つ信頼性の高い並行サービスを構築するためのライブラリ群を提供するデータ駆動型の拡張可能なフレームワークであり、コンポーネント間の結合を減らすためにプロトコルを使って実装されている。

• 次世帯DBであるDatomicを利用したマイクロサービスの為のデータベース構築

今回は、マイクロサービスに用いられるデータベースである次世代データベースDatomicについて述べる。Datomicはマイクロサーピスのようなデータ指向アプリケーション(データ指向アプリケーションとは、データの量や複雑さ、変化が課題となるアプリケーション)向けのデータを確実に保存し、取得する為の、基盤となるデータベースとなる。DatomicはClojureで書かれたライブラリであり、AWSで提供されているクラウドサービスでもある。

• マイクロサービスでのセキュリティ- ClojureでのAuthとPedestalを使ったAPI

マイクロサービスは、分離してデプロイし、使用状況を監視する必要がある。現在の作業負荷と処理時間を監視することで、それらをスケールアップするタイミングやスケールダウンするタイミングを判断することもできる。マイクロサービスベースのアーキテクチャのもう1つの重要な側面は、セキュリティとなる。マイクロサービスのセキュリティを確保する方法の1つは、各サービスが独自の認証・認可モジュールを持つようにすることとなる。だがこの方法はすぐに問題になる。各マイクロサービスが孤立してデプロイされるため、ユーザーを認証するための共通の基準に合意することが信じられないほど難しくなるためである。また、この場合、ユーザーとそのロールの所有権は、サービス間で分散してしまう。この章では、このような問題を取り上げ、マイクロサービスベースのアプリケーションを安全に、監視し、拡張するためのソリューションについて述べる。

• マイクロサービスを含めたシステム運用監視の為のElasticStashの活用

「Microservice with Clojure」より。今回はマイクロサービスシステム運用監視の為のElasticStashの活用について述べる。ここで述べた監視システムはマイクロサービスシステム以外にも広く適用可能となる。ElasticStashを用いた検索エンジンへの活用は”検索ツールElasticsearch -立ち上げ手順“等に詳細述べているのでそちらも参照のこと。

• マイクロサービスのデプロイと運用-DockerとKubernetes

マイクロサービスは、1つのコマンドで複製やデプロイができる自己完結型のアーティファクトとしてパッケージ化されている必要がある。また、サービスは数秒以内に稼働できるように、起動時間が短く軽量である必要もある。コンテナは、ホストOSと必要な依存関係を持つベアメタルマシンをセットアップするのに比べ、固有の実装により迅速にデプロイすることができる。また、コンテナ内にマイクロサービスをパッケージ化することで、開発から本番環境への移行をより速く、自動化することも可能となる。よってマイクロサービスはコンテナ内にパッケージ化することが推奨されている。

• 強化学習の概要とシンプルなMDPモデルの実装

強化学習の概要とシンプルなMDPモデルのpythonでの実装について述べる。

• モデルベースアプローチによる強化学習の概要とpythonでの実装

前回述べた迷路の環境をベースに計画を立てる手法について述べる。計画を立てるには「価値評価」と「戦略」の学習が必要となる。そのためにはまず「価値」を実体に即した形で定義し直す必要がある。

ここでは動的計画法(Dynamic Programming)を用いたアプローチについて述べる。この手法は迷路の環境のような遷移関数と報酬関数が明らかな場合に利用でき。このように遷移関数・報酬関数をベースに学習する手法を「モデルベース」の学習法と呼ぶ。ここでの「モデル」とは環境のことで、環境の動作を決定する遷移関数・報酬関数がその実態となる