Close

マイクロサービスとマイクロサービスのアーキテクチャ

マイクロサービスの長所と短所、そしてモノリスとの違いを確認します。

マイクロサービスとは?

「マイクロサービス」という用語は、分散されてネットワーク化されたプロジェクトにおける従来の「懸念の分離」パターンを表す現代的な用語です。マイクロサービスは、「小さくて鋭いツール」の古い基本的な Unix 哲学に従うアイデアです。両方の概念は、別の基本的なコンピューター サイエンスのパターンの「構成」の上に構築されています。つまり、複雑なシステムは、下位レベルの構成可能なエンティティの集合であるということです。

マイクロサービスの記事

[続き]

構成は、ソフトウェア プロジェクトのすべてのレイヤーを介して行われます。最下位レベルの「ユニット レベル」では、個々の独立したコード関数は、共有インターフェイスを介して相互作用し、コードのコレクションまたは「ライブラリ」を作成します。オペレーティング システムのシェル レベルでは、シェル コマンドを構成して上位レベル機能のパイプラインを作成できます。マイクロサービスは Web サービス間で発生する構成のレベルで、ドメイン ロジックの 1 つの部分を担当する Web サービスです。アクションを完了するために REST のような単純なネットワーク プロトコルを介して相互作用しますが、他のサービスが内部的にどのように機能するかについての知識はありません。マイクロサービス間のこの調和のとれた相互作用は、マイクロサービス アーキテクチャです。

マイクロサービス アーキテクチャ (MSA) は、ソフトウェア チームがリリース ワークフローを改善する新しい方法を模索するようになるにつれて、多くの注目を集めています。Amazon、Netflix、Ebay は、ソフトウェアを構築しているこの方法を公然と採用している企業であり、独自の経験を公開して他企業による導入を支援できるツールを開発することによって、コミュニティに貢献してきました。

マイクロサービスの指針は、ビジネスのコンポーネントを相互に独立してデプロイして運用できる小規模なサービスに分割することによって、アプリケーションを構築することです。

大きな立方体を多数の小さな立方体にどのように分割できるかを示す図。

その後、開発者は、異なるスタックと切り離されたデプロイを使用して、各種サービスに特化した小規模なチームで編成できます。この懸念事項と分離されて独立した機能を分離することで、継続的なデリバリーや統合などのアジャイル ソフトウェア開発プラクティスを合理化できます。

サービス指向アーキテクチャ (SOA) とマイクロサービスの比較

サービス指向アーキテクチャとマイクロサービスは、より大まかな 2 種類の Web サービス アーキテクチャです。マイクロサービスは、SOA のライト バージョンとして考えられます。2 種類のアーキテクチャ タイプの違いは、サービス タイプの専門的な分類です。SOA には、ビジネス、エンタープライズ、アプリケーション、インフラストラクチャの各サービスの 4 種類の基本タイプがあります。これらのタイプは、基礎となるサービスの関連ドメイン固有の責任を定義します。一方、マイクロサービスには、機能とインフラストラクチャという 2 つのサービス タイプしかありません。

どちらのアーキテクチャも、企業の異なるレイヤーで同じ一連の標準を共有します。SOA パターンの成功には、MSA の存在は欠かせません。したがって、MSA パターンは SOA のサブセットです。ここでは、各サービスの実行時の自主性を主に重視しています。

モノリス アプリケーションとマイクロサービスの比較

継続的なデリバリーにおけるモノリスとマイクロサービスの違いを示す図。

マイクロサービスは、主要なビジネス ドメイン固有の懸念を別々の独立したコード ベースに分離します。モノリシック アプリケーション アーキテクチャは、マイクロサービスの逆として考えられます。モノリスは、ビジネス上のすべての懸念をまとめる 1 つのコード ベースです。コード管理の認知コストとデプロイを容易にするために、プロジェクト期間の早期段階で重宝する場合があります。これによって、モノリスのすべてを一度にリリースできます。

多くのプロジェクトは、最初はモノリスとして始まり、その後マイクロサービス アーキテクチャに進化します。モノリスに新しい機能が追加されると、多くの開発者を特異なコードベースに取り組ませるのは面倒になってくるかもしれません。コードの競合がより頻繁になって、ある機能を更新することで無関係な機能にバグが入るリスクが増加します。このような望ましくないパターンが発生した場合は、マイクロサービスへの移行を検討するときかもしれません。

マイクロサービス アーキテクチャの仕組み

例として、e コマース ソフトウェア プロジェクトがあると考えてみましょう。明確に定義されたドメイン固有のビジネス機能がいくつかあります。e コマース サイトには、ユーザーのログイン、ログアウトのための認証システムがあります。ユーザーが興味を持っている製品のリストを含むショッピング カートがあります。課金システムで、ユーザーは自分の購入代金を支払えます。

マイクロサービス アーキテクチャでは、これらのビジネス ドメインの例は独立したサービスになります。具体的な例として、請求システムを挙げます。企業の従業員数に応じて、この請求用マイクロサービスの開発と品質保証を所有する専用の「請求チーム」がある場合があります。請求用マイクロサービスには、独自のリリース スケジュールとデプロイ ガイドがあります。請求サービスは文書化されてバージョン管理された API を提供するため、他のサービスがその機能とやりとりして利用できる可能性があります。

マイクロサービスの長所と短所

+ 水平拡張

マイクロサービスは設計別に分散されて、クラスタにデプロイできます。これによって、サービス境界全体にわたって動的な水平拡張が可能になります。マイクロサービスの負荷容量が限界に達している場合は、そのサービスの新しいインスタンスを付随するクラスタに迅速にデプロイして、負担を軽減できます。

+ チームの独立した実行

マイクロサービス責任者チームは、組織にある他の機能チームとは独立して運用できます。これによって、新機能をより迅速に実行して配信できます。

+ 品質を深く掘り下げる

ビジネス上の懸念を独立したマイクロサービスに分離すると、そのサービスを所有するサービス チームは高品質の成果物一式に集中できます。

- 指数関数的なインフラストラクチャ コスト

組織が本番環境に追加する新しいマイクロサービスには、テスト スイート、デプロイ ガイド、ホスティング インフラストラクチャ、監視ツールなどの独自のコストが伴います。

- 組織への負担増大

マイクロサービス アーキテクチャ チーム間の更新とインターフェイスを調整するには、さらなるレベルのコミュニケーションとコラボレーションが必要です。

- 開発環境の複雑さ

プロジェクトが複数のマイクロサービスに分割されると、ローカル開発設定中に分散アーキテクチャを再現するという課題が追加されます。

マイクロサービスの未来

コンテナー化とコンテナーのデプロイは、新しいパターンの分散インフラストラクチャです。Docker や Kubernetes などのツールは、サービスを完全な「コンテナー」にパッケージ化するために使用されます。このコンテナーは、迅速にデプロイして破棄できます。これらの新しいインフラストラクチャ ツールは、マイクロサービス アーキテクチャを補完するものです。マイクロサービスはコンテナー化されて、コンテナー管理システムを使用して簡単にデプロイして管理できます。

マイクロサービスの採用は、チーム当面の目標ではなく、ジャーニーとして捉える必要があります。小規模から始めて、分散システムの技術要件、故意の失敗、個々のコンポーネントの拡張方法を理解します。その後、さらに経験を積んで知識を得るにつれて、徐々にサービスを抽出できます。

マイクロサービス アーキテクチャはまだかなり若いですが、それはアプリケーションを開発する有望な手段であり、それは間違いなく検討する価値があります。しかし、(まだ) それはあなたのチームには適していないかもしれないことを覚えておいてください。

Claire Maynard
Claire Maynard

Claire は、Atlassian のマーケティングのベテランで、入社以来、成長、パフォーマンス、製品マーケティングに関する業務を担当してきました。現在、彼女は Confluence Cloud のブランド、コンテンツ、マーケティング戦略を推進しています。プライベートでは、サンフランシスコや世界中の初めて訪れる都市でサーフィンやランニング、未開拓のレストラン巡りを楽しんでいます。