マイクロサービス：概要とメリット
2013 年頃まで、企業は通常、大規模なコードベースを持つ単一のユニット、つまりモノリシック・アーキテクチャとしてアプリケーションを構築することで、エンタープライズ・ソフトウェアを構築していました。ソフトウェアがより複雑になり、クラウド・コンピューティングが普及するにつれて、このアプローチは実用的ではなくなりました。
サービスとしてのソフトウェア製品（クラウド提供型アプリケーション）の出現により、企業は Amazon Web Services などのプロバイダを利用して、迅速に新しいサーバーを作成し、冗長性を追加できるようになりました。これにより、アップグレード時もサービスをオンラインで維持できるようになりました。また、サービスとしてのソフトウェアにより、ベロシティとアジリティの新時代も到来しました。ユーザーは迅速なアップグレードと改善を期待するようになり、企業は開発プロセスの変更を求められました。
企業は、アプリケーションをより小規模で独立したサービス、つまりマイクロサービスに分割し始めました。たとえば、モノリシックの e コマース・プラットフォームの一部としてメッセージの受信トレイを含めるのではなく、この機能のために個別のマイクロサービスを作成しました。
それと並行して、開発者は、より小規模で専門的なグループで作業を始め、アプリケーション全体を危険にさらすことなく、個々のサービスを変更・改善しました。多くの場合、これらのグループはコードの運用にも責任を負いました。このモデルは DevOps と呼ばれています。これらの変更を促進するために、プロジェクト・マネージャーは、アジャイルなどの新しい手法の開発を進めました。アジャイルでは、プロジェクトをより小規模の、頻繁なリリースに分割します。
マイクロサービスベースのアプリケーションの構造に関する詳細は、以下でご確認ください。また、アトラシアンの Compass によって複雑さを軽減しながら、開発者がこのアーキテクチャ・モデルでのメリットを得る方法もご覧ください。
Compass を無料で試す
開発者のエクスペリエンスを向上させ、すべてのサービスをカタログ化し、ソフトウェアの健全性を高めましょう。
マイクロサービスとは?
マイクロサービスは、1 つのロジックに関与する機能です（以下でご説明するドメイン・マイクロサービスを除く）。複数のマイクロサービスを組み合わせて、Jira Software などの分散型アプリケーションを作成します。
マイクロサービスには次の 3 つの種類があります。
- ドメイン・マイクロサービスは、関連する機能でサービスをゆるく結合します。
- 統合マイクロサービスは、無関係なアプリケーション間の相互作用を促進します。
- 作業単位マイクロサービスは、単一の機能を処理します。
マイクロサービスでは、API（アプリケーション・プログラミング・インターフェイス）を利用して相互に通信します。個々のサービスで作業を行う開発者は、他のマイクロサービスの内部動作を確認できます。これは、モノリシック・アーキテクチャにはない、もう 1 つのメリットです。
マイクロサービスベースのアーキテクチャには多くのメリットがありますが、複雑さも増します。だからこそ、アトラシアンは Compass を開発しました。企業が拡大するにつれて、簡素化できるようにします。この開発者エクスペリエンス・プラットフォームでは、エンジニアリング成果とチーム・コラボレーションに関するすべての情報を、一元化された検索可能な場所にまとめます。
マイクロサービスの主な原則
マイクロサービスベースのアーキテクチャには、いくつか際立った機能があります。開発者は、コンポーネントに適した言語とテクノロジーを利用して、サービスを独立して開発し、デプロイできます。
マイクロサービス間の通信は API ベースで行い、変更することなく、さまざまなソースからデータにアクセスできます。個々のサービスは需要に応じて拡張できるため、コストを節約し、可用性を確保できます。
これらの属性により、マイクロサービスベースの分散型アプリケーションは柔軟で、容易に維持できます。
マイクロサービスのメリット
マイクロサービスには多くのメリットがあります。マイクロサービスにより、開発やプロジェクト管理を簡素化できます。開発者が構築したマイクロサービスの運用を処理できるため、個別の運用チームが不要になる場合もあります。
マイクロサービスには、他にも次のようなメリットがあります。
回復力と障害分離
モノリシック・アーキテクチャでは、1 つのエラーがアプリケーション全体に影響します。しかし、マイクロサービスは独立しています。1 つの障害がアプリケーションの他の部分に影響を与えることはありません。
Agility
アプリケーションを小さな単位に分割すると、開発がスピードアップします。これにより、チームはソフトウェアをより迅速に構築、テスト、デプロイできます。
テクノロジーの多様性
マイクロサービスでは、開発者が業務に適したツールとテクノロジーを選択できます。これにより、効率と生産性が向上します。
保守の改善
個々のコンポーネントをテストできるため、アプリケーション全体をオフラインにすることなく、簡単にバグを発見して修正できます。
マイクロサービスの課題
マイクロサービスベースのアーキテクチャには多くのメリットがありますが、課題もあります。
マイクロサービスの課題の 1 つは、独立した各サービスでログが生成されることです。これは、開発者チームと運用チームに信頼できる唯一の情報源が提供される、モノリスの一元化されたログと比べるとデメリットになります。また、多くの不確定要素が存在するため、監視やインフラストラクチャ管理もより複雑になります。モノリスとは異なり、IDE（統合開発環境）が存在しないため、テストやデバッグは困難になります。
アトラシアンの Compass を利用すると、これらすべての課題を解決できます。Compass はコラボレーションを促進し、企業が規模を拡大するにつれて分散型アーキテクチャの複雑さを管理できるようにします。分断された情報を中央の検索可能な場所にまとめて、Compass で課題解決を実現します。
マイクロサービス・アーキテクチャの利用目的
多くの場合、消費者向けの大規模な Web サイトでは、何百、何千ものマイクロサービスを利用しています。マイクロサービスは特に、次のユース・ケースや業界で役立ちます。
- e コマース・サイト：eBay などでは、ショッピング・カート、モバイル・アプリ、メッセージに個別のマイクロサービスを利用しています。
- 金融機関：Bank of America などでは、マイクロサービスを利用して外部サービスと通信しています。また、ユーザー認証や取引の表示などの機能の処理にも利用しています。
ソーシャル・メディア・プラットフォーム：Instagram や Facebook などでは、マイクロサービスを利用してユーザーのニュース・フィード、メッセージ、通知、友達のネットワークを表示しています。
マイクロサービスを管理するためのベスト・プラクティス
長年にわたり、開発者はマイクロサービス開発に不可欠なベスト・プラクティスを多数作成してきました。ごく一部の例をご紹介します。
- SRP（単一責任の原則）では、各モジュールまたはマイクロサービスは 1 つの機能のみを保持する必要があると定めています。SRP での CI（継続的インテグレーション）は、ソースコード管理の手法であり、プロジェクトにマージする前のコードの品質チェックを自動化します。個別の QA プロセスをなくすことでベロシティを向上させます。この DevOps のベスト・プラクティスはベロシティの向上に役立ちます。CI は、CD（継続的なデリバリー）に先行し、自動構築ツールを実行してソフトウェアをデプロイできる状態に保ちます。
- API ゲートウェイは、マイクロサービス間の通信を簡素化し、認証や承認を管理し、セキュリティを強化します。
- マイクロサービス間の非同期通信によって自律性を維持し、アプリケーション機能を遅くする可能性のある依存関係を減らします。
-
開発者がオペレーション全体を削除するなど、重大な変更を実装する場合は、マイクロサービスのバージョン管理が非常に重要です。このプラクティスにより、トランジションが円滑になり、サービス中断の可能性を最小限に抑えられます。
Jira Software が提供する、アトラシアンの Open DevOps により、チームはアトラシアンとパートナーのツールを自動的に簡単に統合して、ソフトウェアの構築や運用に集中できるようになります。
Compass でマイクロサービス・アーキテクチャをより適切に管理する
アトラシアンの Compass は、開発者エクスペリエンス・プラットフォームであり、分散型ソフトウェア・アーキテクチャとコラボレーションするチームを 1 か所にまとめます。Compass では、チームが取り組んでいるコンポーネントとサービスすべての概要を簡単に把握できます。また、ソフトウェア・コンポーネント・カタログも含まれているため、開発者は必要とするものを簡単に見つけられます。
Compass では、コンポーネント管理、所有権の追跡、関係の監視を簡単に行えます。また、変更をリアルタイムで追跡できます。
Compass は、開発環境に簡単に統合できます。Compass の UI はカスタマイズ可能で、社内ツールやサードパーティ・ツールと互換性があるためです。Compass でマイクロサービス・アーキテクチャを管理する方法や、分断された情報を一元化された場所にまとめる方法をご覧ください。
マイクロサービス：よくある質問
マイクロサービスで一般的に利用されているツールは何ですか？
企業では多くの場合、Kubernetes や Docker などのコンテナー化ツールを利用しています。また、マイクロサービスとクライアント間で API ゲートウェイも頻繁に利用します。これらのゲートウェイは、認証、アクセス制御、負荷分散などの API トラフィック機能を実行します。
マイクロサービスとモノリシック・アーキテクチャとの違いは何ですか？
モノリスは、1 つのシステムとして機能する大規模なコードベースです。モノリスでは、更新とデバッグのためにシステムのダウンタイムが必要になります。マイクロサービス・アーキテクチャは、より小さく独立した機能を持つ分散型アプリケーションです。開発者は、アプリケーション全体をオフラインにすることなく、これらのモジュールをアップグレード、改善、デバッグできます。これにより、拡張が簡素化され、開発のベロシティが向上します。
マイクロサービスは DevOps にどのような影響を与えますか？
DevOps を理解すると、継続的インテグレーションと継続的なデリバリー（DevOps CI/CD パイプライン）が DevOps 手法の中心であることがわかります。マイクロサービスのモジュール性は、このアプローチと完全に一致します。マイクロサービスにより、開発者は小規模で頻繁なリリースを迅速に作成、テスト、デプロイできるようになります。
アトラシアン・コミュニティに参加して、マイクロサービスの記事やディスカッションをご覧ください。