マイクロサービスとマイクロサービスのアーキテクチャ
マイクロサービスの長所と短所、そしてモノリスとの違いを確認します。
つい最近まで、ソフトウェア アプリケーションを構築するために好まれていた手法は、1 つの自律的なユニットとしてのモノリシック アーキテクチャでした。この手法は、アプリケーションが複雑化するまでは多くの開発者にとってうまく機能していました。モノリシック システムではコードのほんの一部を変更しただけで、システム全体を再構築し、システム全体でテストを実行し、まったく新しいバージョンのアプリケーションをデプロイする必要があります。
そこで登場したのが、マイクロサービスです。これは、ソフトウェア システムを小さなユニットに分割して、自律的に開発してデプロイできるようにするアプローチです。マイクロサービス アーキテクチャは、新機能、バグ修正、セキュリティ改善などの更新を継続的に提供しようとする DevOps 運動によって後押しされました。また、企業が最新のプログラミング言語やテクノロジー スタックによってレガシー アプリケーションを書き直す多くの動きにもつながりました。
マイクロサービスは小さなユニットの集まりで、大規模で複雑なアプリケーションを継続的に提供してデプロイします。
マイクロサービスとは?
単に「マイクロサービス」とも呼ばれるマイクロサービス アーキテクチャは、分散して自律的に開発される、独立してデプロイ可能な一連のサービスとしてアプリケーションを構築する手法です。これらのサービスはゆるく結合しており、個別にデプロイ可能で保守も容易です。モノリシック アプリケーションが分割できない単一のユニットである一方、マイクロサービス アーキテクチャではそのユニットを複数の独立したユニットの集合体に分割して、それらを連携させて全体を構成します。マイクロサービスはユーザー要件への迅速な対応を可能にする継続的なデリバリーの基盤となるため、DevOps に欠かせない要素です。
マイクロサービスは、1 つのドメイン ロジックを担当する Web サービスです。複数のマイクロサービスが組み合わされてアプリケーションとなり、各マイクロサービスが 1 つのドメイン機能を提供します。マイクロサービスは REST や gRPC などの API によって相互にやり取りしますが、他のサービスの内部動作については関知しません。マイクロサービス間で行われるこのような調和のとれたやり取りが、マイクロサービス アーキテクチャです。
マイクロサービス アーキテクチャを採用すると、異なるスタックと切り離されたデプロイによって、開発者は各種サービスに特化した小規模なチームを編成できます。たとえば、Jira には複数のマイクロサービスがあり、それぞれが課題の検索、課題の詳細の表示、コメント、課題のトランジションなどの特定の機能を提供しています。
マイクロサービスの特徴
マイクロサービス アーキテクチャに正式な定義はないものの、知っておくべき一般的なパターンや特徴がいくつかあります。
自律型コンポーネント
マイクロサービス アーキテクチャの基本的な構成要素であるコンポーネントは、一連の関連機能を含むソフトウェア、Web サービスまたはリソース、アプリケーション、またはモジュールで構成されています。または、Martin Fowler 氏はより簡単に「ソフトウェア コンポーネントとは、独立して交換およびアップグレード可能なもの」と説明しています。
マイクロサービス アーキテクチャでは、他のサービスの機能とアプリケーションの整合性を損なうことなく、各コンポーネントを開発、デプロイ、運用、変更、再デプロイできます。
カスタマー エクスペリエンスやビジネス価値を提供するために、コンポーネントを他のコンポーネントと組み合わせて使用できます。最も一般的なのはサービスとライブラリですが、CLI ツール、モバイル アプリ、フロントエンド モジュール、データ パイプライン、機械学習モデル、また適用できるその他多くの概念をマイクロサービス アーキテクチャ内にカプセル化できます。
明確なインターフェイス
個々のコンポーネントを作成した後、RPC、REST over HTTP、またはイベントベースのシステムなどの通信メカニズムを介して相互に通信するには、相当量のロジックが必要になります。通信方式は同期でも非同期でもよく、マイクロサービスでは両方を組み合わせて使用できます。
最も重要な側面は、各マイクロサービスが、コンシューマーがそのサービスをどのように使用できるかを説明する明確で直感的なコントラクトを提供する必要があるということです。通常、このコントラクトはサービスと共に公開される API を介して提供されます。
構築した者が運用する
「構築した者が運用する」という DevOps の理念は、アーキテクチャをマイクロサービスに変更するにはチームをどのように編成するかを考える必要があるということをよく表しています。DevOps を採用することで、開発、QA、リリース エンジニアリング、運用といった機能ロール全体のインセンティブを再調整して、高品質のソフトウェアを構築するという共通の目標を掲げる 1 つのチームを作成できます。CI/CD、自動テスト、機能フラグなどの DevOps プラクティスによって、デプロイが加速してシステムの安定性とセキュリティを維持できます。さらに、各チームは、他のチームに影響を与えることなく、自分が所有するマイクロサービスを構築してデプロイできます。
クラウドの進化によって、マイクロサービスの構築、デプロイ、運用が簡素化されました。継続的なインテグレーションとデリバリー、自動テストなどのインフラストラクチャ自動化技術によって、チームをサポートします。
サービス指向アーキテクチャとマイクロサービスの比較
SOA (サービス指向アーキテクチャ) とマイクロサービスは、どちらも Web サービス アーキテクチャです。マイクロサービスと同様に、SOA を構成するコンポーネントは相互に独立して動作し、再利用可能であり、特化された機能を持っています。この 2 種類のアーキテクチャの違いは、サービス タイプの縦割り的な分類です。
SOA には次の 4 つの基本的なサービス タイプがあります。
- Business
- Enterprise
- アプリケーション
- インフラストラクチャ サービス
これらのタイプは、基盤となるサービスの関連ドメイン固有の責任を定義しています。一方、マイクロサービスには、機能とインフラストラクチャという 2 つのサービス タイプしかありません。
どちらのアーキテクチャも、企業のさまざまなレイヤーで同じ一連の標準を共有します。SOA パターンの成功には、マイクロサービス アーキテクチャの存在が欠かせません。したがって、マクロサービス アーキテクチャ パターンは SOA のサブセットです。ここでは、各サービスの実行時の自主性を主に重視しています。
マイクロサービスのメリット
Agility
通常は、小規模で独立したチームがマイクロサービス内のサービスを構築するため、アジャイル プラクティスの採用が促進されます。チームが独立して作業し、迅速に行動できるようになり、開発サイクル タイムが短縮されます。
柔軟なスケーリング
マイクロサービスは設計別に分散されてクラスターにデプロイできるため、サービスの境界を越えて動的かつ水平に拡張できます。マイクロサービスの負荷容量が最大に達した場合は、そのサービスの新しいインスタンスを付随するクラスターに迅速にデプロイして負担を軽減できます。
頻繁なリリース
マイクロサービスの主なメリットの 1 つは、頻繁かつ迅速なリリース サイクルです。継続的なインテグレーションとデリバリー (CI/CD) の重要な要素であるマイクロサービスによって、チームは新機能を試してうまくいかなければ元に戻せます。これによってコードの更新が容易になり、新機能の市場投入までの時間が短縮されます。
柔軟なテクノロジー
マイクロサービス アーキテクチャでは、1 つのツールチェーンを使用する固定的なアプローチに従う必要がなく、希望のツールを自由に選択できます。
品質重視
ビジネス上の懸念を独立したマイクロサービスに分割することで、そのサービスを所有するサービス チームは高品質の成果物を完成させることに集中できるようになります。
高い信頼性
機能を分割することで、マイクロサービスは更新のリリース時にアプリケーションまたはコードベース全体を破壊するリスクを軽減します。個々のサービスの障害やバグを簡単に特定して修正できます。アプリケーション全体を停止することなく特定のサービスに対してのみ変更をデプロイできるため、信頼性が向上します。
マイクロサービスの課題
開発の無秩序化
モノリスからマイクロサービスへの移行は、より複雑になることを意味します。複数のチームが作成したより多くのサービスがより多くの場所で提供されます。さまざまなコンポーネントが互いにどのように関係しているか、特定のソフトウェア コンポーネントを所有しているのは誰か、依存するコンポーネントに悪影響を与えないようにするにはどうすればよいかを判断するのは、困難を極めます。無秩序を放置したままにすると、開発速度が遅くなって運用パフォーマンスが低下します。システムが大きくなるため、経験豊富な運用チームが継続的な再デプロイとアーキテクチャの頻繁な変更を管理する必要があります。
明確なオーナーシップの欠如
マイクロサービス アーキテクチャでは、誰が何を所有しているのかがさらにわかりにくくなります。DevOps チームでは、アプリケーションをデプロイするために、API、コンポーネント ライブラリ、監視ツール、Docker イメージを組み合わせて実行します。所有者、リソース、他のコンポーネント間の進化する関係など、コンポーネントに関する情報を把握することが重要です。製品を理解するために必要な情報を関係者全員が簡単に見つけられるようにするには、多数のチーム間で正確なコミュニケーションと調整を行えることが必要です。
インフラストラクチャ コストの急上昇
新しいマイクロサービスを本番環境に追加するたびに、テスト スイート、デプロイ ガイド、ホスティング インフラストラクチャ、監視ツールなどのコストが発生します。
組織への負担増大
マイクロサービス アーキテクチャ チーム間で更新とインターフェイスを調整するには、さらなるレベルのコミュニケーションとコラボレーションが必要です。
デバッグ
それぞれ独自のログ セットを持つ複数のマイクロサービスが含まれるアプリケーションをデバッグするのは、困難を極めます。1 つのビジネス プロセスが複数のマシン全体で実行されることもあるため、デバッグがさらに複雑になります。
インシデント対応
マイクロサービスを使用している人物、マイクロサービスのデプロイ場所、マイクロサービスのデプロイ方法、問題が発生した際の連絡先などの情報を含む、マイクロサービスのインシデント対応インテリジェンスが必要です。
マイクロサービスと DevOps: 相互に補完しあうテクノロジー
マイクロサービスの複雑さが増してマイクロサービスへの依存性が高まる中、デプロイ、監視、そしてライフサイクルの自動化という各 DevOps プラクティスは、マイクロサービス アーキテクチャに不可欠であると考えられています。そのため、多くの場合、マイクロサービスは DevOps カルチャーを採用するための第一歩と見なされています。これによって、次のことが可能になります。
- 自動化
- 拡張性の向上
- 管理性
- Agility
- デリバリーとデプロイの迅速化
マイクロサービス アーキテクチャの主要テクノロジーとツール
コンテナー、Docker、Kubernetes
コンテナーはアプリケーションとそのすべての依存関係をパッケージ化することで、アプリケーションを簡単に一貫してデプロイできるようにしたものです。コンテナーには独自のオペレーティング システムのオーバーヘッドがないため、従来の仮想マシンよりも小型で軽量です。より迅速にスピン アップ/ダウンできるため、マイクロサービス アーキテクチャ内に見られる小規模なサービスに最適です。
サービスやコンテナーの急増に伴い、大規模なコンテナー グループの連携と管理が不可欠になってきています。Docker は、コンテナーの構築、デプロイ、実行をサポートする、人気のコンテナー化プラットフォームおよびランタイムです。しかし、コンテナーを大規模に実行して管理することは、Docker だけでは困難です。大規模なコンテナー化をサポートするには、Kubernetes や Docker Swarm、Mesos、HashiCorp Nomad などの他のソリューションを使用できます。
コンテナー化とコンテナーのデプロイは、新しいパターンの分散インフラストラクチャです。Docker と Kubernetes は、サービスを完全なコンテナーにパッケージ化して、迅速にデプロイおよび破棄できるようにします。これらの新しいインフラストラクチャ ツールは、マイクロサービス アーキテクチャを補完します。コンテナー管理システムによって、マイクロサービスがコンテナー化されてデプロイが容易になり、簡単に管理できるようになります。
API ゲートウェイ
マイクロサービス アーキテクチャにある個々のサービスは、明確に定義された API を介して相互に通信します。API ゲートウェイはリバース プロキシの働きをして、API 呼び出しを受理し、それらを実行するためのサービスを集約し、結果を返します。複数のマイクロサービスが API にサービスを提供する場合でも、API ゲートウェイによって抽象化を行って単一の API エンドポイントを提供できます。また、API ゲートウェイは、レート制限、監視、認証、承認、および適切なマイクロサービスへのルーティングなどの懸念事項を一元管理できます。
メッセージングとイベント ストリーミング
マイクロサービスは分散型であるため、状態の変化とその他のイベントをチームで共有する手段が必要です。メッセージング システムがマイクロサービス間で通信するため、一部のマイクロサービスはプライマリ インターフェイスの一部としてイベントを処理できます。たとえば、Confluence ページを変更すると、検索のインデックスの再作成とこのページをウォッチしているユーザーへの通知をトリガーするイベントが生成されます。
ログと監視
マイクロサービスでは、複数のサービス全体で問題を特定して解決するのが困難です。ログ、監視、トレースを観察できるツールを用意することが重要です。これによって、マイクロサービスの動作を理解して潜在的な問題を特定し、問題をトラブルシューティングして障害をデバッグできるようになります。
継続的なインテグレーションとデリバリー
マイクロサービスの主なメリットの 1 つは、頻繁かつ迅速なリリース サイクルです。CI/CD の重要な要素であるマイクロサービスによって、チームは新機能を試してうまくいかなければ元に戻せます。これによってコードの更新が容易になり、新機能の市場投入までの時間が短縮されます。
開発者ポータル
分散アーキテクチャの複雑さが増す中、開発チームはエンジニアリングの成果とチームのコラボレーションに関する情報を 1 か所に統合するツールを活用できます。たとえば、アトラシアンの Compass は DevOps ツールチェーン全体にわたってデータとインサイトを提供することで、マイクロサービスの無秩序な増加を抑えるために設計されました。
マイクロサービスの未来
コンテナー化とコンテナーのデプロイは、今ではよく見られるようになったパターンの分散インフラストラクチャです。Docker と Kubernetes などのツールは、サービスを完全なコンテナーにパッケージ化して、迅速にデプロイおよび破棄できるようにします。これらの新しいインフラストラクチャ ツールは、マイクロサービス アーキテクチャを補完します。これらのツールは、マイクロサービスをコンテナー化してデプロイを容易にし、コンテナー管理システムによって簡単に管理できるようにします。
マイクロサービスの採用は、チーム当面の目標ではなく、ジャーニーとして捉える必要があります。
小規模から始めて分散型システムの技術要件を理解してから、個々のコンポーネントを拡張していくのが便利です。その後、経験を積んで知識を得るにつれて、徐々により多くのサービスを抽出します。
Compass によって マイクロサービスをナビゲートする
マイクロサービス アーキテクチャで作業する際は、アトラシアンの Compass によって拡張する分散アーキテクチャの複雑さを管理できます。Compass は拡張可能な開発者エクスペリエンス プラットフォームで、エンジニアリング成果とチーム コラボレーションに関する分断された情報を一元化された検索可能な場所にまとめます。Compass はコンポーネント カタログによってマイクロサービスの無秩序な増加を抑える上で役に立つだけでなく、スコアカードによってベスト プラクティスを確立してソフトウェアの正常性を測定する上でも役に立ちます。また、Atlassian Forge プラットフォーム上で構築された拡張機能によって、DevOps ツールチェーン全体のデータとインサイトを提供します。
