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

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

サービス分割の考え方

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

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

ビジネス視点での考え方

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

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

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

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

システム視点での考え方

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

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

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

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

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

システム視点での考え方