ポイント: マイクロサービスアーキテクチャは、アプリケーションを独立したサービスの集合として構造化し、スケーラビリティとアジリティを向上させます。このアプローチにより、チームは自律的にサービスを開発および維持でき、回復力が向上しますが、複雑さと潜在的なセキュリティリスクも導入されます。
- マイクロサービスは、より迅速な反復と開発者の独立性を促進します。
- 各サービスは独立して動作およびスケールし、全体のシステムの回復力を高めます。
マイクロサービスアーキテクチャ、すなわちマイクロサービスは、単一のアプリケーションを緩く結合されたサービスの集合として構築する特定のソフトウェアシステム設計手法です。アプリケーションは通常、モノリシックアーキテクチャから始まり（その詳細は以下に）、時間とともに相互接続されたマイクロサービスのセットに成長します。マイクロサービスの主なアイデアは、特定のタイプのアプリケーションは、多くの小さな部分に分解されて協力して動作する方が構築しやすく、維持しやすいということです。アーキテクチャは複雑さを増しますが、マイクロサービスは依然としてモノリシック構造に比べて多くの利点を提供します。マイクロという概念は、特に企業が10年以上存在する場合、ほとんどの企業が使用していた既存のモノリシックインフラストラクチャから派生しています。マイクロサービスアーキテクチャの各コンポーネントは、
- 独自のCPUを持つ
- 独自のランタイム環境を持つ
- しばしば、各サービスが相互に独立していることを確保するために作業する専任のチームがいる
このアーキテクチャは、各サービスが：
- 独自のプロセスを実行する
- 他のマイクロサービスやアプリケーション全体に依存せずに自律的に通信する
分離されて再結合できるこの能力は、全体のシステムを decay から保護し、アジャイルプロセスをより良く促進します。これは、特にモノリシックインフラストラクチャを使用している組織にとって魅力的です。この記事では以下について説明します：
マイクロサービスの動作
マイクロサービスは、全体のアプリケーションを機能させるために協力するサービスのセットです。このアーキテクチャは、ユーザーのクエリやデータストリームなどの情報を、あるサービスから別のサービスに渡すためにAPIを利用します。基盤となるソフトウェアの動作や、サービスが構築されるハードウェアは、サービスを構築したチームに完全に依存します。これにより、チーム間の通信やサービスのアップグレードが非常にダイナミック（反応的）になり、ソフトウェア会社やチームがより回復力を持つことができるようになります。Kubernetesは、マイクロサービスの推進に寄与しましたが、必ずしも必要な構成要素ではありません。クラウドコンピューティングとネットワークコンピュータの台頭は、次の2つのことを実現しました：
- ユーザーがすべての必要な操作を実行するために強力なコンピュータを持つ必要がなくなった
- ユーザーがアプリケーションを実行するたびに、サービスを実行するために個々のサーバーを使用する責任が企業に課せられる
マイクロサービスの場合、ユーザーのマシンは基本的な処理を担当するかもしれませんが、主に他のコンピュータとのネットワークコールの送受信を担当します。アプリケーションを使用する際には、あなたの体験を支えるために、他に5台程度のコンピュータが起動したと考えるのが合理的です。FacebookやUberのようなものの場合、さらに10,000台のコンピュータが情報を処理していると期待するのがより合理的です。マイクロサービスは、サービス指向アーキテクチャ（SOA）の論理的進化と見なされることが多いですが、両者の間には明確な違いがあります。
マイクロサービスアーキテクチャの例
マーチン・ファウラーが指摘するように、多くの大企業が現在、アーキテクチャ内でマイクロサービスを利用しています。Netflixはその中でも最も早く、最もよく知られた採用者の一つです。他の有名な例には：
- eBay
- Amazon
- PayPal
- SoundCloud
- Gilt
- ガーディアン
これらの企業には、マイクロサービスのネットワークが存在します。たとえば、SoundCloudは、新しいユーザーマイクロサービスを持っていて、ユーザーをアプリケーションにオンボードします。このマイクロサービスは、バックエンドでユーザーのアカウントをアクティブにし、ユーザーに歓迎のメールを送信したり、ユーザーが最初にアプリケーションにログインするときにウォークスルーを提供したりする責任があります。SoundCloudの別のマイクロサービスは、ユーザーの曲をプラットフォームにアップロードして保存することを処理するかもしれません。別のマイクロサービスは、検索機能や推奨アーティストを担当します。企業が営業担当者、ファイナンシャルアナリスト、銀行員など、異なる責任を持つ人々で構成されているのと同様に、企業のマイクロサービスは、全体の責任を個々のアクションに分割します。このマイクロサービス設計とモノリスとの違いは、SoundCloudがこれらの部分を処理するための単一のアプリケーションを持っていないことです。例えば、毎年春にリリースされ、CD-ROMに配布されるものです。むしろ、各部分（マイクロサービス）は：
- 全体に貢献するために自律的に動作する
- 継続的開発と統合（CI/CD）の現代的な方法でアップグレードできる
(成功裏に立ち上げるのに役立つマイクロサービスのベストプラクティスを探索してください。)
モノリシックアーキテクチャ対マイクロサービスアーキテクチャ
モノリシックアーキテクチャパターンは、過去、Kubernetesやクラウドサービスのない時代に使用されていたアーキテクチャスタイルです。モノリシックアーキテクチャでは、ソフトウェアはCD-ROMに配布される単一のアプリケーションであり、最新のアップデートを含む新しいバージョンが年に一度リリースされます。例としては、Photoshop CS6やMicrosoft 2008があります。
そのスタイルは、ソフトウェアを構築するための標準的な方法でした。しかし、技術が進化するにつれて、アーキテクチャスタイルも進化しなければなりません。KubernetesやCI/CDワークフローの時代において、モノリシックアーキテクチャは多くの制限に直面しています。企業はマイクロサービスに移行する必要があります。モノリシックアーキテクチャの特徴：
- 変更が遅い
- 変更が高コスト
- 特定のまたは変化する製品ラインに適応しにくい
モノリシック構造はアプリケーションへの変更を極めて遅くします。コードの小さなセクションを修正するだけでも、ソフトウェアの完全な再構築と展開が必要になることがあります。(アプリのモダナイゼーションやコードリファクタリングの複雑さについて学んでください。)開発者がアプリケーションの特定の機能をスケールしたい場合、全体のアプリケーションをスケールしなければならず、変更やアップデートがさらに複雑になります。マイクロサービスはこれらの課題を解決するのに役立ちます。
マイクロサービスの利点
独立したモジュラーコンポーネントとして構築されたアプリケーションは、テスト、メンテナンス、および理解が容易です。これにより、組織は：
- アジリティを高める
- ワークフローを改善する
- 生産性を向上させるのにかかる時間を短縮する
各独立したコンポーネントは複雑さを増しますが、そのコンポーネントにはそれを打破するための追加の監視機能を持たせることもできます。マイクロサービスの最も一般的な利点と、なぜ多くの企業がすでにそれを使用しているのかを以下に示します。
開発者の独立性
各マイクロサービスには、通常、維持するために単一の開発チームが割り当てられます。したがって、開発者の自由度と独立性が向上します。並行して作業している小規模なチームは、大規模なチームよりも迅速に反復作業を行うことができます。特定のサービスが人気を博すと、小規模なチームはより大きく複雑なチームを待つことなく、自分たちでサービスをスケーリングすることもできます。
隔離と回復力
コンポーネントの1つが、古い技術やコードのさらなる開発の失敗などの問題により失敗した場合、開発者は他のコンポーネントを立ち上げることができ、アプリケーションの残りは自立して機能し続けることができます。この能力は、開発者が必要に応じてサービスを開発および展開する自由を提供し、アプリケーション全体に関する決定を待つ必要がありません。
スケーラビリティ
マイクロサービスは、はるかに小さなコンポーネントで構成されているため、リソースを少なく使用し、特定のコンポーネントの需要の増加に対応するためにより容易にスケールできます。その隔離により、マイクロサービスはサイズやボリュームの大きな変化があっても適切に機能することができ、さまざまなプラットフォームやデバイスを扱う企業にとって理想的です。
自律的に開発された
モノリスとは異なり、個々のコンポーネントは継続的デリバリーパイプラインや複雑な展開シナリオに適合させやすくなります。変更が必要な場合、修正と再展開が必要なのは特定されたサービスのみです。サービスが失敗した場合、他のサービスは独立して機能し続けます。その自律的な性質は、チームに次のような利点をもたらします：
- スケーリングと開発を可能にする
- 他のチームとの調整をあまり必要としない
マイクロサービスは、企業がより分散化され、従業員がリモートになるときに特に有利です。
ビジネスとの関係
マイクロサービスアーキテクチャは、ビジネスドメインの境界に沿って分割され、物流、請求などの機能を中心に組織されています。これにより、独立性と理解が組織全体で高まり、さまざまなチームが特定の製品を利用し、ライフサイクル全体にわたってそれを所有し維持できるようになります。
進化的
マイクロサービスアーキテクチャは、非常に進化的です。マイクロサービスは、開発者が将来アプリケーションにアクセスするデバイスを完全に予測できない状況において優れたオプションです。また、アプリケーション全体を遅延させることなく、ソフトウェアに迅速かつ制御可能な変更を許可します—したがって、機能や新製品の開発においてより反復的に行動できます。
マイクロサービスの欠点
もちろん、マイクロサービスアーキテクチャには学習曲線があります。初めてのユーザーは次のことを判断するのに苦労するかもしれません：
- 各マイクロサービスのサイズ
- マイクロサービス間の最適な境界と接続ポイント
- サービスを統合するための適切なフレームワーク
より広範に言えば、マイクロサービスには次のような欠点があります：
- 複雑さの増加
- コストが高い
- より大きなセキュリティリスク
複雑さの増加
まず第一に、マイクロサービスははるかに複雑なシステムです。学習曲線は急である可能性がありますが、一度学んでしまえば、ほとんどのことと同様に、容易に使用できるようになります。新しいソリューションが常に最善であるわけではなく、異なる問題を同じ解決策で解決しようとする多くのコンサルタントや若手エンジニアの責任です。マイクロサービスアーキテクチャは、アプリケーションにとって常に最良の解決策ではありません。一部のアプリケーションには、必要以上に複雑すぎるかもしれません。
コストが高い
マイクロサービスはコストがかかる場合があります。通常、独自の環境で独自のCPUを使用して実行されます。APIコールを介して機能し、料金が発生します。最後に、環境が複雑になるほど、それを構築できるエンジニアのチームが必要になるため、労働コストも高くなります。
より大きなセキュリティリスク
最後に、マイクロサービスは異なる実行マシンで異なる環境を介して存在し、異なるAPIコールを持っているため、攻撃者がシステムに侵入し、損害を与えるための接点が増えます。
マイクロサービスはDevOpsをサポートします
最終的に、マイクロサービスは、多くの組織が取り組んでいるDevOpsへの包括的なシフトの一部です。DevOps環境は、ITがよりアジャイルになるように、開発チームと運用チーム間の強力な協力を促進します—それにより、ビジネスもアジャイルになります。マイクロサービスは単なる技術であり、代わりに、組織がビジネス目標をサポートするために開発チームの文化、知識、構造を採用する必要があるより大きな概念の一部です。
関連するリーディング
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。