連載
» 2019年12月17日 05時00分 公開

特集:マイクロサービス入門(4):マイクロサービスアーキテクチャにおける「サービス配置」の考え方 (1/3)

マイクロサービスアーキテクチャを用いてシステム開発をする場合、アプリケーションをどのように分割して配置すればいいのか。アプリケーション間の通信はどのような点に留意すべきかを、オイシックス・ラ・大地の川上徹氏が解説します。

[川上徹,オイシックス・ラ・大地]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

サービス分割の考え方

 マイクロサービスアーキテクチャを用いてシステムを構築する際に頭を悩ませるのは、アプリケーションをどのように分割するかだ。サービスの分割は正解のない分野かもしれないが、ECサイト「Oisix」のマイクロサービス化に約1年取り組んできた経験を基に考え方を共有したい。

 本記事は、マイクロサービスアーキテクチャにおけるサービス分割の方法を、ビジネス側とシステム側の視点で分けて整理する。ただ、それぞれの考え方は共存しないわけでなく、整理して適切に組み合わせる必要がある。どのような考え方を採用するとしても、「何のためにマイクロサービスアーキテクチャを採用するのか」という視点は欠かせない。

ビジネス視点での考え方

 マイクロサービスアーキテクチャを採用することで得られるメリットの一つが、サービス単位でプロダクトを開発できることだ。

 ビジネス視点でサービス分割を考える場合に重要なのは、アジャイル開発の文脈における「プロダクトオーナー」(以後、PO)が責任を持ち、開発とリリースが可能な範囲でサービスを構築することだ。

 逆説的に言えば、サービスを分割するスコープに対してPOを割り当てられない組織構成の場合、マイクロサービスアーキテクチャを採用するメリットは薄れてしまうといえるだろう。これは自社サービスの開発や、受託開発の場合でも変わらない。

 サービスの分割単位は、DDD(Domain-driven design:ドメイン駆動設計)の構成要素とひも付けて語られることが多いが、重要なポイントは「POが自律的な開発プロセスを回すことのできる範囲」で分割することだと筆者は考えている。

システム視点での考え方

 一方で、システム視点でサービスを分割する場合は以下のような観点がある。

部分的なスケール性を確保

 システムの中で特定機能に負荷が集中する、あるいは負荷の集中が想定される場合は、その部分を別のアプリケーションとして分割して開発することが有効だろう。特定機能のみにスコープを絞ったスケールアウト/スケールアップが可能な構成は、システム全体としてのコスト効率を高めることにつながる。

障害時の影響範囲の局所化を実現

 後述する「サーキットブレーカーパターン」などを適用することで、別のアプリケーションとして開発した部分で発生した障害をそのアプリケーションのみにとどめておくことが可能になる。これにより、システム全体としては稼働している状態を維持できるので、信頼性の向上を狙うこともできるだろう。

システム視点での考え方 システム視点での考え方
       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。