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