マイクロサービスアーキテクチャ:クラウドネイティブ時代のシステム設計
- 1. 1.マイクロサービスアーキテクチャとは
- 1.1. 一体型 vs マイクロサービス、何が違う?
- 1.2. マイクロサービスの良いところ
- 1.3. クラウドネイティブと相性抜群な理由とは?
- 2. 2.マイクロサービス設計の鉄則:変更に強いシステムを作るコツ
- 2.1. 1つのサービスは1つの仕事だけ!:単一責任の原則 (SRP)
- 2.2. 疎結合&高凝集で、変更に強いシステムに!
- 2.3. 境界づけられたコンテキストって?
- 2.4. ドメイン駆動設計との合わせ技で最強設計!
- 3. 3.マイクロサービス分割戦略
- 3.1. マイクロサービス、どうやって分割する? 〜設計のコツ
- 3.2. サービスごとにデータベース、独立性UP!
- 3.3. API Gatewayで連携、スマートな通信!
- 4. 4.マイクロサービス間通信
- 4.1. マイクロサービス同士の通信:連携をスムーズにするには?
- 4.2. REST API、gRPC、メッセージキュー、どれを選ぶ?
- 4.3. サービスメッシュで通信管理、もっと楽になる!
1.マイクロサービスアーキテクチャとは
一体型 vs マイクロサービス、何が違う?
昔ながらのシステム開発は、全ての機能がぎゅっと詰まった「一体型」が主流でした。これは例えるなら、大きな船のようなもの。何か一つでも不具合があると、船全体が止まってしまうリスクがあります。
※ここではわかりやすく「一体型」として説明していますが、一体型とは、モノリシックアーキテクチャのことです。
モノリシックアーキテクチャとは
モノリシックアーキテクチャとは、すべてのコンポーネント(プレゼンテーション層、ビジネスロジック層、データアクセス層など)が一つのアプリケーションに統合されている構造を指した用語です。
一方、マイクロサービスは、システムを小さなサービスの集まりとして捉えます。これは、たくさんの小さなボートが協力して大きな船の役割を果たすイメージしてもらえるとわかりやすいかもしれません。たくさんの小さなボートが在ることで、一つのボートに問題があっても、他のボートは影響を受けずに動き続けることができるメリットがあります。
マイクロサービスの良いところ
- 開発スピードUP!:小さなサービスごとに開発できるから、大人数での同時並行開発もスムーズ!
- スケーラブル!:必要なサービスだけを増やせるから、負荷に応じて柔軟に対応可能!
- 障害に強い!:一つのサービスが止まっても、システム全体への影響は最小限!
- 技術選定の自由度UP!:サービスごとに最適な技術を選べるから、最新技術もどんどん導入できる!
クラウドネイティブと相性抜群な理由とは?
マイクロサービスは、クラウドの特性を最大限に活かせる設計思想です。クラウドが提供するスケーラビリティや可用性を活かして、より柔軟で回復力のあるシステムを構築できます。まさに、クラウドネイティブ時代のシステム開発に欠かせない存在と言えるでしょう。
2.マイクロサービス設計の鉄則:変更に強いシステムを作るコツ
1つのサービスは1つの仕事だけ!:単一責任の原則 (SRP)
マイクロサービスでは、「1つのサービスは1つのことだけを責任を持つ」という原則が重要です。 例えば、「商品検索」と「在庫管理」を一つのサービスにまとめてしまうと、後々変更が必要になった時に大変! それぞれを独立したサービスにすることで、変更の影響範囲を最小限に抑え、開発スピードを上げることができます。
疎結合&高凝集で、変更に強いシステムに!
疎結合とは、サービス同士の結びつきをできるだけ弱くすること。高凝集とは、一つのサービスの中に関連性の高い機能を集めることです。 疎結合にすることで、あるサービスを変更しても他のサービスへの影響を少なくできます。高凝集にすることで、一つのサービスの中だけで変更を完結させやすくなります。 これらを意識することで、変更に強く、保守性の高いシステムを構築できます。
境界づけられたコンテキストって?
大きなシステムを開発する際、チームごとに担当範囲を明確にすることが大切です。 境界づけられたコンテキストとは、まさにその担当範囲のこと。 各チームが自分のコンテキスト内だけで開発を進められるようにすることで、コミュニケーションミスや余計な依存関係を減らし、開発効率を上げることができます。
ドメイン駆動設計との合わせ技で最強設計!
ドメイン駆動設計(DDD 英語: domain-driven design)って聞いたことありますか? これは、業務知識(ドメイン)を深く理解し、それをシステム設計に反映させる手法です。 マイクロサービスアーキテクチャとDDDは相性抜群! DDDで抽出した「境界づけられたコンテキスト」を、そのままマイクロサービスに落とし込むことで、よりビジネスに沿った、変更に強いシステムを構築できます。
例えるなら、DDDは設計図を描く建築家、マイクロサービスはそれを実現する職人。 二人が協力することで、理想の家(システム)を作り上げることができるのです。
3.マイクロサービス分割戦略
マイクロサービス、どうやって分割する? 〜設計のコツ
マイクロサービスへの分割は、まるでピザをカットするようなもの。一枚の大きなピザ(モノリシックなシステム)を、食べやすいサイズ(マイクロサービス)に切り分けるイメージです。
切り分け方の一つが、ビジネス機能ごとに分割する方法。例えば、ECサイトなら「商品検索」「カート」「注文管理」など、それぞれの機能を独立したサービスとして切り分けます。こうすることで、各サービスの役割が明確になり、開発・運用がしやすくなります。
サービスごとにデータベース、独立性UP!
マイクロサービスでは、各サービスが専用のデータベースを持つことが推奨されます。 これは、各サービスが独立して開発・運用できるようにするためです。 複数のサービスが一つのデータベースを共有してしまうと、あるサービスの変更が他のサービスに影響を与えてしまう可能性があります。
API Gatewayで連携、スマートな通信!
各サービスは独立していますが、連携が必要な場合もあります。 そんな時に活躍するのがAPI Gateway。 これは、各サービスへの入り口となる窓口のような役割を果たします。 API Gatewayを使うことで、クライアントは各サービスのAPIを直接呼び出す必要がなくなり、システム全体の複雑さを軽減できます。
関連サービス:リファクタリング・リアーキテクチャ
4.マイクロサービス間通信
マイクロサービス同士の通信:連携をスムーズにするには?
同期?非同期?使い分けが重要です。マイクロサービス間の通信には、同期通信と非同期通信の2つの方式があります。同期通信と非同期通信を簡単に説明す
- 同期通信:レストランで注文するように、リクエストを送ったらすぐにレスポンスが返ってくる方式。
- 非同期通信:手紙を送るように、リクエストを送ったら一旦処理を続け、後からレスポンスを受け取る方式。
となります。
それぞれメリット・デメリットがあるので、状況に応じて使い分けることが重要です。 例えば、レスポンスをすぐに必要とする処理には同期通信、処理に時間がかかる場合は非同期通信が適しています。
REST API、gRPC、メッセージキュー、どれを選ぶ?
マイクロサービス間の通信には、様々なプロトコルや技術が使われます。
- REST API:Webサービスで広く使われている、HTTPベースのシンプルな通信方式。
- gRPC:高速かつ効率的な通信を実現する、RPC(Remote Procedure Call)フレームワーク。
- メッセージキュー:非同期通信を実現する、メッセージを一時的に保存・転送する仕組み。
それぞれ特徴があるので、要件に合わせて最適なものを選びましょう。 例えば、シンプルな通信にはREST API、パフォーマンス重視ならgRPC、非同期処理にはメッセージキューがおすすめです。
サービスメッシュで通信管理、もっと楽になる!
マイクロサービスが増えてくると、サービス間の通信も複雑になります。 そんな時に役立つのがサービスメッシュ。 これは、サービス間の通信を管理するためのインフラ層のようなものです。
サービスメッシュを導入することで、以下のようなメリットがあります。
- 通信の可視化:サービス間の通信状況を把握しやすくなる。
- トラフィック制御:サービスへの負荷を分散したり、障害発生時に特定のサービスへのアクセスを制限したりできる。
- セキュリティ強化:サービス間の通信を暗号化したり、認証・認可を行ったりできる。
サービスメッシュは、マイクロサービスアーキテクチャを大規模に運用する上で、非常に強力なツールとなります。
次回は、5.マイクロサービスのデータ管理、6.マイクロサービスのデプロイと運用について解説します。
システム開発にお困りではありませんか?
もしも今現在、
- どのように開発を依頼したらよいかわからない
- どのように開発を依頼したらよいかわからない
- 企画や要件定義の段階から依頼できるのか知りたい
- システム開発費用がどれくらいかかるのか知りたい
- 見積りがほしい
など、システム開発に関するご相談・ご依頼がございましたら、お気軽にご相談ください。APPSWINGBYでは、「アプリでお客様のビジネスを加速し、お客様とともにビジネスの成功と未来を形作ること」をミッションとしています。大手SIerやR&D部門で培った経験やノウハウ、高度な技術力でお客様の「やりたい」を実現します。
この記事を書いた人
株式会社APPSWINGBY マーケティング
APPSWINGBY(アップスイングバイ)は、アプリケーション開発事業を通して、お客様のビジネスの加速に貢献することを目指すITソリューションを提供する会社です。
ご支援業種
情報・通信、医療、製造、金融(銀行・証券・保険・決済)、メディア、流通・EC・運輸 など多数
監修
株式会社APPSWINGBY
CTO 川嶋秀一
動画系スタートアップ、東証プライム R&D部門を経験した後に2019年5月に株式会社APPSWINGBY 取締役兼CTOに就任。
Webシステム開発からアプリ開発、AI、リアーキテクチャ、リファクタリングプロジェクトを担当。C,C++,C#,JavaScript,TypeScript,Go,Python,PHP,Vue.js,React,Angular,Flutter,Ember,Backboneを中心に開発。お気に入りはGo。