Janet Wagner著
大規模な信頼性の高いアプリケーションを構築するアプローチとしてのマイクロサービスは、近年人気が高まっています。また、Amazon、Microsoft、Netflixなどの大手企業は、かなり前からマイクロサービスについて話しています。この記事では、特にモノリスから始めて後でマイクロサービスに移行する場合と、最初からマイクロサービスを始める場合のマイクロサービス戦略について見ていきます。
モノリスとは？
開発者がモノリシックアプリケーションについて話すとき、通常は単一のユニットとして扱われ、密結合であり、通常は単一のサーバーへの1回限りのデプロイが必要なアプリケーションを意味します。モノリシックアプリケーションは単一のユニットとしてスケーリングされ、1つのデータベース（通常はリレーショナル）を共有する可能性が高く、アプリ全体で1つの巨大なコードベースを持つことがよくあります。フロントエンドやサーバーサイドロジックなど、すべてがコードベースで定義されており、通常、アプリの構築には少数の言語のみが使用されます。場合によっては、モノリシックアプリケーションを複数のサーバーにデプロイすることもできますが、アプリは依然として1つのユニットとして扱われます。
マイクロサービスとは？
マイクロサービスはアプリ開発者の間で大きな話題になっていますが、マイクロサービスが何であるかについての業界で合意された定義はありません。マイクロサービスは、分散アプリを開発するためのコンセプトに近いものです。ただし、多くの業界リーダーの間では、マイクロサービスの特性に関するコンセンサスがあります。これらの特性の中には、サービスが疎結合であるがコンテキストによって制限されており、相互に独立してデプロイおよびスケーリングでき、軽量メカニズム（HTTP、REST API、WebSocketなど）で通信できるというものがあります。短い定義は、サム・ニューマン著の書籍「Building Microservices」で提供されています。「マイクロサービスは、連携して動作する小さく自律的なサービスです。」
アプリの構築 – モノリスを先にするかマイクロサービスを先にするか？
マイクロサービスとAPIの戦略に関しては、最初にモノリシックアプリケーションを使用し、後でマイクロサービスに移行するか、最初からマイクロサービスを開始するかによって大きく異なります。
業界リーダーは、モノリスを最初にするか、マイクロサービスを最初にするかに関して、さまざまな考え方を持っています。有名な著者であり、ソフトウェアエンジニアであり、ThoughtWorksのチーフサイエンティストであるMartin Fowlerは、モノリスを最初にするアプローチを提唱しています。彼は、モノリスから始めて、必要に応じて後でマイクロサービスに移行するのが良いとアドバイスしています。innoQの共同創業者兼プリンシパルコンサルタントであるStefan Tilkovは、モノリスのコンポーネントが最終的にお互いに密結合になるという理由で、マイクロサービスを最初にするアプローチを提唱しています。これにより、後でモノリスを個々のサービスに分割するのが非常に困難になります。
アプリケーション開発には多くの方法があり、モノリスを最初にするかマイクロサービスを最初にするかの2択だけではないことに注意してください。たとえば、GamutのシニアエンジニアリングリードであるDarby Freyは、Mediumの記事で、彼のチームが最初にモノリスやマイクロサービスを実行しないことに決めたと説明しています。チームは代わりに2つのアプリを作成しました。マイクロサービスでもモノリスでもありません。チームが構築したアーキテクチャには、必要なだけ多くのバックエンドサービスを持つことができるAPIゲートウェイレイヤーが含まれています。
アプリケーションのアーキテクチャを選択する前に考慮すべきことはたくさんあります。開発チームがマイクロサービスの構築経験がない場合は、モノリスの方が良い選択肢になる可能性があります。アプリの機能が最先端のものであることを望む場合は、各機能に最適な言語、フレームワーク、ライブラリを使用する必要があります。この場合、マイクロサービスの方が良い選択になります。これは、最先端の機能を備えたモノリスを構築できないということではありません。ただし、モノリスはいくつかの言語に制限される傾向があるため、アプリのすべての機能に最適ではない言語で機能を構築することになる可能性があります。
モノリスから始める
モノリスから始めたいと思う理由は何でしょうか？マイクロサービスと比較して、モノリスは通常、1つのサーバーへの1回のデプロイであるため、デプロイが一般的に簡単です。また、アプリは単一のユニットとして扱われるため、エンドツーエンドテストの監視と実行がはるかに簡単です。モノリシックアプリケーションと比較して、分散アプリの監視とテストは、サービスが異なるランタイム環境を持つことが多いため、より困難です。さらに、サービスをテストする必要がある場合、そのサービスが依存する他のすべてのサービスも起動する必要があります。
では、なぜモノリスから始めない方が良いのでしょうか？モノリスから始めない方が良い最大の理由の1つは、モノリスが最終的に多数の密結合されたコンポーネントになることです。これにより、コードのスケーリングと保守が非常に困難になります。もう1つの理由は、密結合されたコンポーネントがすべてあるため、コードベースが理解しにくくなり、新しい開発者のオンボーディングが困難になることがよくあるためです。
マイクロサービスから始める
マイクロサービスから始めたいと思う理由は何でしょうか？マイクロサービスは自律的であるため、サービスの開発、デプロイ、テスト、スケーリングを独立して迅速に行うことができます。サービスは任意の言語を使用して開発することもできるため、開発者は他のアプリの部分に干渉することなく、新しいテクノロジーを試して新しい機能を追加できます。また、1つのサービスに問題がある場合でも、他のサービスは稼働し続ける可能性があります。1つまたは複数のサービスに問題があるためにアプリケーションがダウンするリスクが大幅に軽減されます。
APIエバンジェリストのKin Laneは、興味深い見解を持っています。それは、コードを記述する前にマイクロサービスのすべてのコンポーネントを決定するためにOpenAPI仕様を使用できるというものです。ドキュメンテーション、サービスのモック表現、検出メカニズム、およびその他の多くのマイクロサービスコンポーネントは、OpenAPIおよびOpenAPI関連ツールを使用して生成できます。
では、なぜマイクロサービスから始めない方が良いのでしょうか？マイクロサービスから始めない方が良い理由の1つは、マイクロサービスが構築されるにつれて発生する傾向があるクロス切断の懸念事項です。ログ、キャッシュ、承認などのセキュリティとクロス切断の懸念事項は、マイクロサービスに関しては対処が難しく、多くの開発が必要になることがよくあります。一部の企業は、クロス切断の懸念事項とセキュリティが一元的に実装されるように、APIゲートウェイを使用します。
マイクロサービスから始めるのが最善の選択肢ではないもう1つの理由は、チームにマイクロサービスの構築経験が不足している場合です。マイクロサービスアーキテクチャは本質的に複雑であるため、チームがマイクロサービスの構築経験がない場合は、マイクロサービスを構築するのは危険です。
マイクロサービス間の通信
マイクロサービスは自律的なサービスであり、このタイプのアーキテクチャを備えたアプリケーションには、数十、時には数百のサービスがあることがよくあります。これらのサービスは、相互に、およびクライアントと通信できる必要があります。マイクロサービスは、相互作用するためにプロセス間通信（IPC）メカニズムを使用するコンテナを使用してデプロイされることがよくあります。IPCメカニズムの最も一般的な通信方法（特にリクエスト/レスポンスサイクルを伴う場合）はRESTfulです。これは、HTTP/JSON APIの使用を意味することがよくあります。
サービスは効率的かつ確実に通信できる必要があるため、通信戦略を計画することが重要です。サービス間の通信に関しては、レイテンシー、障害、ルーティングなど、多くの課題があります。Red Hatのクラウドアプリケーション開発のチーフアーキテクトであるChristian Postaによる最近の記事では、サービスを呼び出し、サービスを相互に通信させることは、マイクロサービスを開発する上で最も難しい部分の1つであると述べています。
アプリに最適なアプローチを選択する
マイクロサービスは、高速で信頼性が高く、高度にスケーラブルなアプリを開発できるため、アプリケーション開発で人気のアプローチです。しかし、分散アプリケーションは非常に複雑になる傾向があります。マイクロサービスは、そのアプローチがアプリケーションに最適である場合にのみ選択してください。
ご精読いただきありがとうございます。APIリソースをさらに探していますか？Swaggerニュースレターを購読してください。最高のAPI記事、トレーニング、チュートリアルなどを毎月メールでお届けします。購読