マイクロサービスとは

マイクロサービスは、最新のアプリケーション配信の重要な部分を占めています。ソーシャル・ネットワーキング・アプリからオンライン小売、ストリーミング動画まで、現在のほとんどすべての主要なソフトウェアアプリケーションはマイクロサービスを使用して構築されています。しかし、それは何でしょうか？そして、ソフトウェアをどのように改善しているのでしょうか？実際のメリットを検証し、マイクロサービスを使用する場合の潜在的なデメリットについても説明します。

サービス指向アーキテクチャ（SOA）は、アプリケーション開発におけるモノリシックアーキテクチャが進化した形態です。SOAはマイクロサービスアーキテクチャに先行し、アプリケーションをより小さく管理しやすいピースに分割します。これらのピースはサービスと呼ばれ、メッセージを使用して相互に通信するように設計されています。また、サービスは相互に独立して設計されているため、アプリケーションの他の部分に影響を与えることなく、交換やアップグレードが可能です。

SOAは多くの場合、ウェブベースのアプリケーションで使用されます。このアプリケーションでは、ビジネスロジックをプレゼンテーションロジックから分離し、データアクセスをデータストレージから分離します。

サービス指向アーキテクチャを使用すると、保守と拡張が容易なアプリケーションを構築できます。また、よりモジュール化された柔軟なアプリケーションの作成にも役立ちます。

サービス指向アーキテクチャを使用する主なメリットは次のとおりです。

• 保守と拡張が容易

• よりモジュール化された柔軟なアプリケーション

• 開発時間の短縮

エンタープライズ・サービス・バス（ESB）は、プロセス間通信の中心的なポイントを提供するソフトウェアアプリケーションです。多くの場合、SOAのコンテキストで他のアプリケーションにサービスを提供するために使用されます。

ESBにより、組織はSOAソリューションを簡単に構築、展開、管理できます。組織のITインフラ内のすべてのサービスを管理、監視、調整します。

このタイプのテクノロジーは、社内外の通信に使用できるため、人気が高まっています。ユースケースには次のようなものがあります。

• データ統合
• サービスの探索と登録
• サービスオーケストレーション
• イベントの通知とロギング

マイクロサービスアーキテクチャは、アプリケーション開発における新たな手法です。SOAと非常に似ていますが、マイクロサービスアーキテクチャは、前のアーキテクチャが残したギャップを埋めるために作成されました。これは、1つが他方より劣っているという意味ではありませんが、実際にはユースケース次第です。SOAは、企業のニーズを満たすように設計されています。つまり、サービスが分離されているにもかかわらず、システムは相互依存性を持つように設計されています。つまり、サービスをビジネスの他の部分に再利用できるようにすることです。

一方、マイクロサービスは真に独立したものです。マイクロサービスアーキテクチャは、データの重複とデータ共有を追求するため、パフォーマンスへの影響はありません。マイクロサービスでは、ESBも不要です。

Software as a service (SaaS) アプリの増加とコンテナの普及により、より効率的な開発方法に対する需要が高まっています。これに対応するために、アプリケーション自体が変化しています。多くのことをうまく行うモノリスから、特定の機能に対応する分散型の独立したサービスの集合体にまで変化しています。

マイクロサービスが提供する主なメリットには、以下のようなものがあります。

1 点。信頼性の向上

各マイクロサービスは、より大きなアプリケーション内で単一の論理機能を実行します。そのため、開発者は変更を必要とするサービスだけに分離されたアップデートを提供します。通常、アプリケーション内のマイクロサービス間には明確に定義されたインターフェースがあります。変更がリアルタイムで行われていても、それがそのままである限り、アプリケーションは機能し続けることができます。

2 点。開発時間の短縮

個々のサービスは、特定の要件に基づいて構築できる、各コンポーネントに明確に定義された一連の機能を提供します。これにより、複数のチーム間で開発作業を水平方向に拡張することが簡単になります。また、新機能の迅速な更新や追加が容易になります。

3 点。アプリケーション機能の向上

開発チームは、複数のコンテキストで再利用できる個々のコンポーネントを作成できます。より広範なユーザーに対応し、より深い機能を提供する新しいアプリケーションを作成しても、同じ作業を繰り返すことはありません。

4 点。疎結合リソース

アーキテクチャスタイルにより、各マイクロサービスが複数のアプリケーションとインターフェースを提供できるため、開発者向けのカスタム実装の数が削減されます。また、独立した設計では、あるマイクロサービスを変更しても、別のマイクロサービスに影響はありません。ただし、これはクライアント側とサーバー側の両方でリクエストを管理するために負荷分散が必要であることも意味します。

最終的に、マイクロサービスを使用することで開発者はアプリケーション固有の機能に集中し、複数のアプリケーションを結合することで発生する開発上の問題を回避できます。アプリケーションを管理可能なピースに分割することで、開発者は自動テストなどの新しいソフトウェア開発手法を活用して、高品質の結果をこれまで以上に迅速に提供できます。

マイクロサービスも、関連するサービスが自己完結型であるため、保守が容易です。依存するすべてのサービスは、個別の管理ツールを使用して独自のプラットフォームで実行されるため、一貫性が向上します。また、大規模なモノリシックアプリケーションに組み込まれている場合よりも、関連するコンポーネントのコレクション全体を簡単に管理できます。

エンタープライズアプリケーションを開発する場合、マイクロサービスアーキテクチャを追求することは、モノリシックアーキテクチャよりも明らかに優れています。しかし、これに潜在的な問題がないわけではありません。マイクロサービスを使用することには、いくつかの顕著なデメリットがあります。

1 点。未定義のマイクロサービス境界の可能性

ドキュメントや要件が適切に定義されていないと、サービスの依存関係やアプリケーション機能全体の管理が困難になる可能性があります。しかし、設計パターン（アーキテクチャパターンとも呼ばれる）は、一般的な問題を回避するために使用できる再利用可能なソリューションです。

2 点。セキュリティの脆弱性

マイクロサービスでは、ネットワークセキュリティも潜在的な欠点となる可能性があります。各サービスは独立して展開され、多くの場合、独自のセキュリティ制御セットがあります。そのため、誰がどのコンポーネントにアクセスできるかが必ずしも明確ではなく、その結果、悪性のアクティビティの可能性が高まります。

マイクロサービス間のコールは多くの場合APIベースであるため、ネットワークトランスポートを介して行われます。これらのサービスが通信する方法は、サイバー犯罪者の攻撃ベクトルになる可能性があります。開発者は、マイクロサービスの展開に使用するプラットフォームとフレームワークを選択する際に注意を払う必要があります。これには、それらを保護するために使用される設定も含まれます。

3 点。コードの保守が複雑で困難

最大のデメリットは、拡張と保守が困難であることです。これは、各サービスをシステム内の他のサービスとは個別に独立して管理する必要があるためです。

4 点。修正が困難なエラー

マイクロサービスのきめ細かで分散されているという性質を考えると、エラーの修正は困難な場合があります。サービス指向アーキテクチャやモノリシックアーキテクチャとは異なり、マイクロサービスアーキテクチャの1つの領域を調整しても、残りの領域に影響はありません。つまり、スタッフは問題の特定とトラブルシューティングに多くの時間を費やすことになる可能性があります。

マイクロサービスには、さまざまな展開オプションがあります。通常、開発者はマイクロサービスをコンテナベースのサービスとして専用ホストに展開することを選択します。または Akamai CloudなどのPlatform as a Service (PaaS) プロバイダーを使用することもできます。

PaaSプロバイダーを使用すると、サービスを簡単に拡張できる機能や、ホストの保守が不要になるなど、クラウドネイティブのメリットがいくつかあります。しかし、開発者は外部のクラウド・サービス・プロバイダーに依存することに関連するリスクを考慮する必要があります。このオプションは、独自のインフラを展開するよりもリスクが高くなります。

マイクロサービスのセキュリティを確保するために、開発者は次のことを行う必要があります。

• 暗号化されたデータ転送にHTTPSを使用
• サービスを保護するためにファイアウォールを導入してください。
• 疑わしいアクティビティを監視するロギングメカニズムを実装
• APIはマイクロサービスとバックエンドサービス間の通信を処理することが多いため、API通信のセキュリティを確保

分散システム：マイクロサービスは本質的に分散システム向けに設計されており、各サービスを異なるサーバー間や異なるデータセンター間で個別にホストおよびスケーリングできます。この分散化により、1つのコンポーネントに障害が発生しても個々のサービスが機能し続けることができるため、回復力が強化されます。

マイクロサービスの自動化：マイクロサービスベースのアーキテクチャでは自動化が不可欠です。導入、スケーリング、監視などのタスクは、継続的インテグレーションと配信（CI／CD）を確保するために自動化されることがよくあります。KubernetesやDockerなどのツールは、マイクロサービスのオーケストレーションとスケーリングを自動化し、分散システムの管理を容易にします。

マイクロサービスはInfrastructure as Code（IaC）もサポートしています。IaCでは、設定とインフラ管理がコードによって自動化されます。これにより、一貫性のある繰り返し可能な展開が可能になり、人的ミスの可能性が減少します。