ソフトウェア開発者は、相互接続されたサービスが自律的に機能するサーバー側ソリューションであるマイクロサービスアーキテクチャを採用することが増えています。これにより、個別のチームが全体のワークフローを中断することなく個別のサービスに取り組むことができます。これは、代替アーキテクチャアプローチではほとんど見られないレベルの柔軟性です。さらに、次世代のアプローチであるマルチランタイムアーキテクチャがさらに注目を集めています。

このブログ投稿では、両方の概念と、モノリシックアーキテクチャと比較した利点と制限について説明します。

マイクロサービスとは何ですか?

マイクロサービスは、ソフトウェア開発における手法の 1 つであり、アプリケーションが小規模で自律的なサービスの集合として構築され、それぞれが独自の機能を持ち、明確に定義された API を介して通信します。このアプローチにより、アプリケーションのスケーリングが簡素化され、開発プロセスが高速化されます。

マイクロサービスアーキテクチャは、柔軟性やスケーラビリティが低く、現代の多くの要件を満たせないことが多い従来のモノリシックアーキテクチャの制限への対応として登場しました。モノリシックアーキテクチャでは、さまざまなプロセスが密接に連携し、1 つの統合システムとして動作します。したがって、アプリケーション内の特定のプロセスが需要の急増に直面すると、アーキテクチャ全体のスケーリングが必要になります。アプリケーションが進化し、そのコードベースが拡大するにつれて、新機能の導入やモノリシックアプリケーションの機能強化はますます複雑になります。さらに、モノリシックアーキテクチャでは、アプリケーション全体の可用性に対してより高いリスクが伴います。その理由は、プロセスの相互依存性と密接な結合にあります。これは、単一プロセスの誤動作がより顕著かつ広範囲に影響を与える可能性があることを意味します。

Netflix がマイクロサービスをどのように活用しているかについては、このビデオをご覧ください。

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FCZ3wIuvmHeM%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DCZ3wIuvmHeM&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FCZ3wIuvmHeM%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

マイクロサービスアーキテクチャの主な機能は何ですか?

ここで、マイクロサービスアーキテクチャの特徴をさらに詳しく見てみましょう。

モジュール性

マイクロサービスアーキテクチャの中心となるのはモジュール性の原則です。これには、ソフトウェアアプリケーションを、特定のタスクや機能を担当する小さな独立したモジュールに分解することが含まれます。各モジュールはサービスと呼ばれることが多く、自律的に動作し、API を介して他のサービスと通信します。モジュール構造により、開発者はシステム全体に影響を与えることなく個々のサービスを更新または拡張できるため、柔軟性が向上します。

分散化

マイクロサービスは、データ管理とガバナンスの両方において分散化されています。データが集中的に保存および管理されるモノリシックアーキテクチャとは異なり、各マイクロサービスは独自のロジックを持つことができるため、より回復力と適応性のあるデータ管理が可能になります。分散ガバナンスは、チームがそれぞれのサービスを独立して管理できることを意味し、開発サイクルの短縮と調整オーバーヘッドの削減につながります。

スケーラビリティ

マイクロサービスの重要な利点の 1 つはスケーラビリティです。サービスは独立しているため、需要に応じて水平方向にスケーリング (同じサービスのインスタンスを追加) できます。これは、さまざまな負荷を処理し、アプリケーションがパフォーマンスを低下させることなく増加した負荷を確実に管理できるようにするために重要です。

独立した展開

マイクロサービスアーキテクチャにより、サービスを独立して展開できます。これは、アプリケーション全体を再デプロイしなくても、特定のサービスに更新、バグ修正、または新機能を導入できることを意味します。これにより、簡素化された継続的な導入プロセスが可能になり、導入のリスクとコストが削減されます。

マイクロサービスアーキテクチャは何で構成されていますか?

マイクロサービスアーキテクチャには、サービスのほかに、API、コンテナ、サービス指向アーキテクチャ (SOA) 要素、クラウドベースのリソースが含まれます。

API

API (アプリケーションプログラミングインターフェイス) は、マイクロサービスの重要な要素ですが、別個の要素です。これは、さまざまなサービスをバインドする接着剤として機能し、リクエストと応答の交換を可能にし、それらが集合的にアプリケーションの機能を駆動します。このセットアップの中心となるのは API ゲートウェイです。これは、内部サービスと外部クライアント間の API 呼び出しのフローを調整すると同時に、セキュリティ、監視、負荷分散も管理します。これらの責任を軽減することで、マイクロサービスは俊敏性と効率性を維持します。

コンテナ

コンテナは、独立して動作するために必要なすべてのアイテムを備えたスタンドアロンの実行可能なソフトウェア単位です。これらは他のソフトウェアコンポーネントから分離されているため、複数のコンテナが同じ環境で共存できます。マイクロサービスでは、各サービスは通常、独自のコンテナー内にカプセル化され、同じサーバーまたは関連するサーバー上に常駐します。

コンテナーは共有オペレーティングシステムカーネルを利用するため、従来の仮想マシン(VM)と比較してサーバーの高密度化が可能になります。コンテナには、迅速な展開と廃止機能もあります。

マイクロサービスには必須ではありませんが、コンテナーは、その小さなフットプリントとリソース効率がマイクロサービスの小さなコードベースと一致するため、実際の実装を大幅に容易にします。Kubernetes などの高度なコンテナオーケストレーションツールは、人的介入をほとんどまたはまったく行わずに障害が発生したコンテナを再起動するなど、コンテナのライフサイクルを自動的に管理することで、この環境をさらに強化します。

対照的に、一般的な仮想マシンには、完全なオペレーティングシステム、ドライバー、およびその他のコンポーネントが含まれています。分離を強化するために VM 内にマイクロサービスをデプロイすることは可能ですが、このアプローチではパフォーマンスの低下とメンテナンスコストの増加につながる可能性があります。

サービス指向アーキテクチャ (SOA)

マイクロサービスとサービス指向アーキテクチャ (SOA) にはいくつかの共通の特徴がありますが、異なる概念を表しています。SOA は、共通のインターフェイスを介して再利用可能なソフトウェアコンポーネントまたはサービスを統合することに重点を置いた開発戦略です。このインターフェイスにより、各サービスの内部動作に関する最小限の知識で、エンタープライズサービスバスを介してサービスを連携させることができます。SOA コンポーネントは通常、通信に Extensible Markup Language (XML) と Simple Object Access Protocol (SOAP) を使用します。

SOA は、大規模なソフトウェアシステム内のトランザクションサービスや再利用可能なサービスに特に効果的です。ただし、新しいコードやリファクタリングされたコード、または迅速な継続的な開発および展開サイクルが必要なシナリオにはあまり適応できません。ここでマイクロサービスが登場します。

マイクロサービスは、SOA 原則の進歩とみなすことができます。主な違いはその範囲にあります。SOA は広範なエンタープライズレベルの運用向けに設計されているのに対し、マイクロサービスは特にアプリケーションレベルに焦点を当てています。場合によっては、SOA は、企業 IT システム全体でアプリケーションと再利用可能なサービス間の相互運用性を促進することにより、マイクロサービスを強化できます。

クラウドコンピューティング

コンテナーとマイクロサービスは、あらゆるデータセンターやコロケーション施設に導入できますが、大規模な統合サービスを管理し、急速または予測不可能なスケーリングをサポートするように設計されたインフラストラクチャで特に効果的です。パブリッククラウド環境は、スケーラブルなオンデマンドのコンピューティングリソースを提供するマイクロサービスに特に適しています。また、オーケストレーションエンジン、API ゲートウェイ、柔軟な従量課金制ライセンスモデルなど、マイクロサービスアーキテクチャに不可欠なツールも提供します。これらのコンポーネントは、堅牢なマイクロサービスインフラストラクチャを作成および維持するために不可欠です。

モノリスからマイクロサービスに移行するにはどうすればよいですか?

モノリシックアーキテクチャからマイクロサービスへの移行には、次の手順が含まれます。

ステップ 1. 現在のインフラストラクチャの評価

マイクロサービスに移行する前に、現在の設定のさまざまな側面を評価する必要があります。

中核的なビジネス目標: 開発の高速化、稼働時間の向上、イノベーション、スケーラビリティなど、マイクロサービスで達成したいことを特定します。
サービスレベルアグリーメント (SLA) : SLA が導入インフラストラクチャと一致していることを確認し、特にサーバーレスホスティングの場合、潜在的なクラウドプロバイダーの SLA を理解します。
インフラストラクチャ:マイクロサービスの疎結合の性質を考慮して、サービスのデプロイメントおよび失敗したデプロイメントの回復戦略のためのツールと方法を評価します。
DevOps:チームは DevOps の実践に精通しており、マイクロサービス環境での俊敏性を高めるための適切なテクノロジーを備えている必要があります。
セキュリティ:マイクロサービスには堅牢なサイバーセキュリティが必要です。認可、認証、API ゲートウェイ、通信プロトコル、ネットワークセキュリティ、ファイアウォールの対策を見直してください。

ステップ 2. 移行するサービスの選択

どのコンポーネントを最初に移行する必要があるかを決定することが重要です。エッジサービスから始めます。エッジサービスは依存関係が少なく定義されたコンテキストであり、通常はより小さなサービスに分割するのが簡単です。このようなサービスの例には、注文管理、請求書発行、通知システムなどがあります。

さらに、パフォーマンスのボトルネックなどの問題を解決するために、モノリシックアーキテクチャからマイクロサービスへの移行を検討してください。

ステップ 3. データの管理

マイクロサービスアーキテクチャの基本原則は、各マイクロサービスが独自の専用データベースを所有する必要があるということです。ただし、モノリシックデータベースの断片化は、データベース要素間の潜在的な重複や依存関係により困難になる場合があります。

マイクロサービス環境でのデータ管理は、特定のデータ関連パターンに基づいて編成できます。

サービスごとのデータベース

マイクロサービスアーキテクチャでは、サービスごとのデータベースパターンが重要な役割を果たします。各マイクロサービスに固有のデータベースを割り当てることで、サービスの干渉を最小限に抑えながら、データの分離と一貫性を確保します。

ただし、このアプローチではサービス全体にわたるデータの統合とクエリが複雑になり、効率的な通信プロトコルと明確に定義されたインターフェイスが必要になります。サービスの中断を防ぐには、データベーススキーマの変更を慎重に管理することが不可欠です。適切な戦略を使用すると、このパターンはマイクロサービスシステムのスケーラビリティとフォールトトレランスを大幅に向上させます。

2. 佐賀

Saga パターンは、分散システム間でのマイクロサービストランザクションのデータの一貫性を確保するために必要です。従来のデータベーストランザクションを実行するのではなく、操作を個別の元に戻せるアクションに分割します。プロセスのいずれかの部分が失敗した場合、一貫性を維持するために補償アクションが開始されます。この分散型の方法により復元力と拡張性が向上しますが、徹底的なオーケストレーションと障害処理が必要です。

3. コマンドクエリ責任分離 (CQRS)

CQRS は、サービス内でのデータ更新とクエリの同時実行に取り組みます。これにより、書き込み (コマンド) と読み取り (クエリ) の機能が分離され、サービスが主要なタスクに基づいて集中して拡張できるようになります。CQRS にはその利点があるにもかかわらず、特にサービス間でデータの一貫性を維持する際に複雑さも加わります。これを実装する前に、システムの特定の要件を考慮して、メリットとデメリットを慎重に検討する必要があります。

4. イベントソーシング

イベントソーシングは、現在の状態だけでなく、アプリケーション内のすべての状態変化を一連のイベントとしてキャプチャして保存します。このアプローチにより、システムはこれらのイベントを再生することでその状態を再構築できます。

マイクロサービスでは、これは各サービスがその履歴を個別に追跡できることを意味し、独立性と分離を促進します。イベントは包括的な記録として機能し、分析や監査などのさまざまな目的に役立ちます。この方法はエラーの回復と処理に役立ちますが、イベントのバージョン管理とストレージのスケーラビリティについて慎重に計画する必要があります。

5. API構成

API 構成は、複数のサービスからデータを取得する役割を果たします。各マイクロサービスが個別のデータを管理するシナリオでは、クライアント側での直接クエリは煩雑になる可能性があります。このパターンは、API コンポーザーやアグリゲーターなどの仲介者を利用して、さまざまなサービスからのデータを一貫した応答に統合します。これにより、クライアントのクエリが簡素化され、データ配信の効率が向上します。

6. 共有データベース

共有データベースのアンチパターンは、複数のマイクロサービスが API やメッセージングシステムをバイパスして共通のデータベースに直接アクセスする場合に使用されます。このアプローチは、個々のサービスの自律性を損ない、データの整合性に対するリスクを引き起こします。さらに、この設計ではセキュリティ上の脆弱性が生じ、システムの進化が複雑になる可能性があり、データベースの小規模な変更が大規模で調整されたタスクに変わってしまいます。

ステップ 4. サービス間通信の最適化

サービス間の通信を計画するときは、対話がどのように構造化されているかを考慮することが重要です。

サービス間の直接通信:これには、単一のサービスが各クライアント要求を処理する 1 対 1 の対話が含まれます。
協調的なサービス処理:ここでは、複数のサービスが各リクエストを協調的に処理することで、1 対多の対話が発生します。

さらに、通信は同期または非同期のいずれかにすることができます。

同期:これには、クライアントとサービス間の直接的なリアルタイムの対話が含まれ、クライアントは即時の応答を待機するため、一時的なブロックが発生する可能性があります。
非同期:このモデルでは、クライアントは即時の応答を待ちません。通信にはメッセージブローカーが関与する場合があります。メッセージブローカーでは、サービスがメッセージをポストし、他のサービスがそのメッセージをサブスクライブして都合の良いときに処理します。

可能な限り、ビジネスロジックの観点から非同期通信を選択することをお勧めします。これにより、システムの安定性が向上し、負荷分散が容易になります。

ステップ 5: テストと展開

マイクロサービスアーキテクチャでのテストは、従来のモノリシックシステムとは異なります。モノリスではアプリケーション全体が 1 つのユニットとしてテストされますが、マイクロサービスベースのアプリケーションでは複数のテスト方法が必要です。これらには次のものが含まれます。

単体テスト: 個々のサービス (ユニット) の機能に焦点を当てます。
コンポーネントのテスト:より大きなコンポーネントまたはモジュールをテストします。
統合テスト:異なるサービス間の相互作用を確認します。
パフォーマンステスト:さまざまな条件下でのシステムの応答性と安定性を評価します。
契約テスト: ユーザーとサービスの間のインタラクションを評価します。
エンドツーエンドのテスト: アプリケーション全体の全体的なパフォーマンスを検査します。

それぞれの種類のテストでは、マイクロサービスが独立および連携して効果的に動作することを検証します。ただし、マイクロサービスのテストには課題が伴います。たとえば、あるサービスの誤動作が他のサービスに問題を引き起こす可能性があり、元の問題の特定が困難になります。さまざまな通信チャネルとプロトコルが使用されるため、専門的な知識が必要です。さらに、多数のエンドポイントをテストし、自動テストを実施する必要があるため、スクリプト作成のスキルと自動化ツールの習熟度が求められます。

マイクロサービスの制限は何ですか?

マイクロサービスのデプロイプロセスは、モノリシックアーキテクチャと比較してより複雑になる可能性があり、次のようないくつかの課題が伴う場合があります。

コンポーネントの依存関係の管理はさらに困難です。
アプリケーションの全体的なパフォーマンスを監視するのは難しくなります。
デバッグプロセスはより複雑です。
統合テストはより複雑で、順番に各 API とシステム全体のパフォーマンスをテストする必要があります。
多数のサービスにわたって高可用性を維持するには、より高いコストがかかります。

ここで、これらの制限の理由を詳しく見てみましょう。

マイクロサービスは、それぞれに特定のコンテキストを使用して、さまざまなビジネス領域を分離します。ただし、このアプローチではビジネスロジックをミドルウェアから切り離すという問題が完全に解決されるわけではありません。ミドルウェアをライブラリとしてマイクロサービスに直接統合する場合は、密結合が必要です。テクノロジーの分散化が進むにつれて、マイクロサービスと統合プラットフォームの間の接続を強化することがますます重要になります。それにもかかわらず、さまざまなマイクロサービス全体で状態を管理することは依然として大きな課題です。

あるいは、エンタープライズサービスバスなどの従来の統合ミドルウェアソリューションが、必要な技術機能を提供します。ただし、このアプローチには、現代のビジネス環境の進化する需要に対応するために必要な柔軟性とスピードが欠けています。

これが、多くのマイクロサービスベースのアーキテクチャが一般的にコンテナーと Kubernetes に依存する理由です。この課題は、Mecha アーキテクチャとも呼ばれるマルチランタイムアプリケーションアーキテクチャを通じて解決できます。これにより、プログラマーは従来のミドルウェア機能を、事前構成されたセカンダリランタイムを備えたプラットフォームに移行できます。

マイクロサービスの長所と短所について詳しくは、このビデオをご覧ください。

https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F1oQJ3b8MWzw%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D1oQJ3b8MWzw&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F1oQJ3b8MWzw%2Fhqdefault.jpg&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=youtube

マルチランタイムマイクロサービスアーキテクチャとは何ですか?

マイクロサービスは、特定のレベルの標準タスクに適しています。ただし、より複雑、多機能、多様なプロジェクトの場合は、マルチランタイムマイクロサービスアーキテクチャの方が適しています。

マルチランタイムマイクロサービス (Mecha) は、さまざまなマイクロサービスが開発され、さまざまなランタイム環境を使用して実行されるマイクロサービスアーキテクチャです。マルチランタイムマイクロサービスを使用すると、各サービスが独自のテクノロジースタックとランタイム環境を選択できるため、柔軟性が高まりますが、システムの統合と管理の点で複雑さも増します。

Mecha では、ビジネスタスク専用のマイクロロジックと、より広範な範囲のマイクロサービスの間には明確な区別があります。このコンテキストにおけるマイクロサービスは、自己完結型のマイクロロジックコンポーネントとメカコンポーネントの組み合わせであり、それぞれがサービス機能全体に貢献します。

マルチランタイムマイクロサービスは、すぐに使用できる基本ユニットを提供し、オープンプロトコルおよび形式と互換性があります。Mecha は、YAML や JSON などの形式で宣言型構成をサポートし、機能の詳細な仕様やマイクロロジックエンドポイントへの接続を可能にします。また、高度な API 仕様と複雑でステートフルなワークフローとの統合にも対応します。

Mecha アーキテクチャはまだ構想段階にありますが、技術的な展開を簡素化することが期待されています。クラウドベースまたはローカルのサービスでサポートされるストレージ、メッセージ永続化、キャッシュなどの機能を一元化することで、複数の専門エージェントの必要性を排除します。

マルチランタイムマイクロサービスアーキテクチャの制限は何ですか?

マルチランタイムサービスアーキテクチャには、いくつかの制限があります。特に柔軟性が必要な大規模な分散システムの場合、必ずしも利点を上回るとは限りません。ただし、これらは設計と実装の際に対処する必要がある課題を表しています。

複雑さ: さまざまなランタイム間での管理と調整により、システムの複雑さが大幅に増加する可能性があります。この複雑さは、さまざまな言語、フレームワーク、およびランタイム環境を処理する必要があることから生じており、開発、テスト、およびメンテナンスがより困難になる可能性があります。
相互運用性の問題: ランタイムが異なれば、通信メカニズムやデータ形式も異なる場合があります。これらの間でシームレスな相互運用性を確保することは困難な場合があり、多くの場合、追加の翻訳層や適応層が必要になります。
パフォーマンスのオーバーヘッド: 異なるランタイム間の通信には、ネットワーク呼び出し、データのシリアル化、および逆シリアル化が含まれる場合があり、これにより遅延が発生し、システム全体のパフォーマンスが低下する可能性があります。
一貫性とトランザクション管理: 複数のランタイム間でデータの一貫性を達成することは、特に分散トランザクションでは難しい場合があります。これには、複雑な調整と合意プロトコルが必要になる場合があります。
スケーラビリティとリソース管理: マルチランタイムシステムのスケーリングには、個々のコンポーネントをスケーリングするだけでなく、ランタイム間の通信を効果的にスケーリングすることも含まれます。さらに、さまざまなランタイムのさまざまな要件により、リソース管理がより複雑になる可能性があります。

結論

マイクロサービスはソフトウェア開発の状況を大きく変えました。マイクロサービスは、ソフトウェア開発で長年普及してきた従来のモノリシックアーキテクチャモデルに代わる革新的な代替手段として、クラウドテクノロジーを通じてさまざまなアプリケーションを開発、監視、管理、展開、拡張するためのより効率的な方法をプログラマに提供します。

出典 : https://blog.devgenius.io/microservices-and-multi-runtime-architectures-57bc1980a8b5

Please follow and like us: