Skip to main content

 

 

 

 
Language:

 

 
 
 
OutSystems

OutSystemsのマイクロサービスアーキテクチャ

サービス指向アーキテクチャ(SOA)では、適切な再利用のためにコアサービスが抽象化されます。ただし、これはマイクロサービス型の実装には該当しません。すべてのサービスが、OutSystemsアプリケーションとともに同じ環境(インストール)に常駐しているためです。

マイクロサービスのアプローチでは、サービスごとに独自のインフラがあり、各サービスは分離されています。サービスとの通信やサービス間の通信は、疎結合の軽量メカニズム(REST APIなど)によってのみ行われます。

SOAアプローチはすでにモジュール型アプローチを適用していますが、マイクロサービスによって以下の特性が強化されます。

  • コンシューマへの影響を抑えながらサービスを継続的にデプロイする。

  • 利用しているアプリケーションにはサービスコードが含まれないため占有領域が小さくなる。

  • モノリシックなサーバーが減り、各サービスの需要に応じて個別に拡張できる。

OutSystemsのマイクロサービスの主なデメリットは、以下のようにプラットフォームのRAD(高速アプリケーション開発)機能が利用できなくなり、利用できるのはREST APIのみとなることです。

  • Aggregateによるデータ取得を加速するエンティティがない。

  • 以前の制約により、マイクロサービスAPI経由ですべてのデータ取得ニーズに対応する必要がある。

  • 再利用可能なブロックがサービスによって提供されない。

マイクロサービスのアプローチを採用するには、別のインフラにサービスを配置する必要があり、アプリケーションはそうしたサービスをREST API経由で利用します。OutSystems RADを利用するために、アプリケーション側のマイクロサービスへの拡張を実装できます。

マイクロサービスを直接利用するのではなく、拡張サービスがローカルエンティティのデータをキャッシュし、再利用可能なブロックまたは複合的なビジネスロジックを提供することで、コアサービスを拡張します。これらはいずれも外部APIの推奨事項に対応しているため、新しいものではありません。

複数のマイクロサービスインフラ

マイクロサービスのアプローチでは、通常、各マイクロサービスは独自のインフラに常駐しています。これにより、各インフラは個別に拡張でき、他のマイクロサービスの負荷による影響を受けません。

分割は、独立したマイクロサービス間で行う必要があります。2つのマイクロサービスが強い依存関係(多数のデータベース参照など)で結合されている場合、プラットフォームの機能を最大限に活用し、REST API経由のみで通信を行うという制約を回避するために、それらのマイクロサービスを別のインフラに分割しないようにします。

最初はマイクロサービスをすべて同じインフラに配置し、独自のインフラや成長ポリシーが必要になった時点でマイクロサービスを分離できます。こうした操作を容易にするには、共通のインフラを使用する場合、各マイクロサービスを別のDBカタログに分離します。

複数の関連会社に対応する中央サービス

中央サービスのサポートもマイクロサービスに適しています。中央サービスは、各関連会社が利用する必要のある中央バックエンドシステムの拡張です。それらの関連会社では、それぞれ独自のインストールにカスタムアプリケーションを実装します。

マイクロサービスのライフサイクル — バージョン管理

マイクロサービスの複数のバージョンを保持するには、以下のようにします。

  • REST APIのサービス定義の複数のバージョンを公開する。

  • 実際のロジックを実装するコアモジュールにアクションの複数のバージョンを配置する。

新しいバージョンを作成するタイミング

マイクロサービスの分離により、コンシューマに影響を及ぼすことなく継続的にデプロイできるようになります。APIシグネチャが変更されない限り、新しいバージョンを公表する必要はありません。

APIを変更する必要がある場合は、現在のバージョンを更新できるか、または新しいバージョンのマイクロサービスAPIを作成する必要があるかを判断する必要があります。

1.変更に含まれるのが以下のみの場合、現在のAPIバージョンを変更します。

  • 新しいアクションの新しいメソッド。

新しいメソッドを必要としないコンシューマは、RESTサービスの定義を更新する必要がないため影響を受けません。

  • すべてのコンシューマに強制する必要があるシグネチャの変更。この場合、現在のバージョンが中断されるため、コンシューマはRESTサービスの更新を強制されます。

2.メソッドのシグネチャが変更され、すべてのコンシューマに強制できない場合は、新しいAPIバージョンを作成します。そのため、古いバージョンを保持して下位互換性を維持する必要があります。以下の2つの状況があります。

  • メソッドのシグネチャの非破壊的な変更。

新しいオプションのアトリビュートのみが含まれる場合、シグネチャの変更は非破壊的になります。

  • メソッドのシグネチャの破壊的な変更。

新しい必須のアトリビュートが含まれるか、または既存アトリビュートの名前や型が変更される場合、シグネチャの変更は破壊的になります。

この場合、古いバージョンは新しい実装と互換性がないため非推奨にする必要があります。そのため、新しいバージョンの採用をコンシューマに強制する必要があります。

インフラのシナリオ

シナリオA — 半分離マイクロサービス向けの単一環境

異なるマイクロサービスを分離するには、別のマイクロサービスゾーン(例のゾーンB)を追加します。

シナリオB — 完全分離マイクロサービス向けの個別環境

異なるマイクロサービスを分離するには、別のマイクロサービスインフラ(例のインフラB)を追加します。

シナリオの比較