Skip to main content

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

Template:OutSystems/OSLanguageSwitcher
Language:

 

 

 

 

 
OutSystems

マイクロサービスについて

James Lewis氏とMartin Fowler氏は、マイクロサービス(別名「マイクロサービスアーキテクチャ」)について以下のように説明しています。

単一のアプリケーションを一連の小さなサービスとして開発するためのアプローチです。こうしたサービスはそれぞれ独自のプロセスで実行され、軽量なメカニズム(通常はHTTPリソースAPI)を使用して通信します。こうしたサービスはビジネス機能を中心に開発され、全自動のデプロイ機構によって個別にデプロイできます。こうしたサービスに対する一元管理は必要最小限に抑えられます。また、異なるプログラミング言語で記述されている場合や、異なるデータストレージテクノロジーを使用している場合があります。

マイクロサービスの誇大宣伝やモノリスの衰退とともに、構成サービスが小さくなるため、サービス境界で分けられた1つ以上の小規模なチームで最初から開発できることが明らかになりました。これにより、全体として開発作業の規模を拡大しやすくなります。

マイクロサービスの多くのメリット 付随する負担
強力なモジュール境界
マイクロサービスでは、モジュール型ストラクチャが強化されます。これは、大規模なチームにとって特に重要です。ソフトウェアシステムのストラクチャは、それを開発した組織のコミュニケーション構造を反映しています。
プロセス間通信
ネットワークの遅延や一時的な中断への対処、データのマーシャリング
複数のトランザクション
複数の独立したコミットの処理と調整
独立したデプロイ
シンプルなサービスはデプロイしやすく、自律しているため、問題が発生してもシステム障害を引き起こす可能性は低くなります。継続的デリバリーは必須になります。継続的デリバリーを実施することで、組織は市場の変化にすばやく対応し、競合他社よりも先に新機能を導入できるためです。
フォールトトレランス
通信エラーからの回復とサービスの整合性への対処
限定的なデータのマッシュアップ
メモリ内で実行され、APIに限定
セキュリティ
アクセス管理と認証
テクノロジーの多様性
マイクロサービスを使用すると、複数の言語、開発フレームワーク、データストレージテクノロジーを組み合わせることができます。
デバッグとトラブルシューティング
根本的な原因へのドリルダウン(根本的な原因は一連のサービスの中に存在する可能性があるため)
監視とロギング
効果的な監視とロギングを一元化することが必要

このように、最初はすべてメリットであっても別の負担を生み出します。プロセスの高速化として約束されたものが、今では複雑化という非常に大きな問題になっています。

モノリスとマイクロサービスは単純な二択ではなく、どちらのカテゴリにも完全には当てはまらないシステムがあることに留意します。

そのため、通常は、マイクロサービスでは生産性の向上にコストがかかるため、システムを複雑化して埋め合わせるということが想定されます。しかし、これが絶対に正しいというわけではありません。

OutSystemsは、以下の方法でこうした負担の一部をあらかじめ解決しています。

1.単一スタックの採用



OutSystemsでは、以下の処理を行うビルトイン機能が提供されています。
セキュリティ
デバッグとトラブルシューティング
* 監視とロギング
2.クエリモデルの公開



クエリモデルを公開することで、エンティティに直接クエリを実行してデータを読み取ったり、APIを使用してデータを書き込んだりすることができるため、データのマッシュアップが可能になりました。
* 限定的なデータマッシュアップ

この最初のコンテキストを念頭に置いて、次は、「OutSystemsでドメインアーキテクチャ(マイクロサービスアーキテクチャ)を採用するタイミングはいつですか?」という質問について考えてみます。それではじっくりと取り組んでいきましょう。