マイクロサービスアーキテクチャにおける「サービス配置」の考え方：特集：マイクロサービス入門（4）（1/3 ページ）
マイクロサービスアーキテクチャを用いてシステム開発をする場合、アプリケーションをどのように分割して配置すればいいのか。アプリケーション間の通信はどのような点に留意すべきかを、オイシックス・ラ・大地の川上徹氏が解説します。
サービス分割の考え方
マイクロサービスアーキテクチャを用いてシステムを構築する際に頭を悩ませるのは、アプリケーションをどのように分割するかだ。サービスの分割は正解のない分野かもしれないが、ECサイト「Oisix」のマイクロサービス化に約1年取り組んできた経験を基に考え方を共有したい。
本記事は、マイクロサービスアーキテクチャにおけるサービス分割の方法を、ビジネス側とシステム側の視点で分けて整理する。ただ、それぞれの考え方は共存しないわけでなく、整理して適切に組み合わせる必要がある。どのような考え方を採用するとしても、「何のためにマイクロサービスアーキテクチャを採用するのか」という視点は欠かせない。
ビジネス視点での考え方
マイクロサービスアーキテクチャを採用することで得られるメリットの一つが、サービス単位でプロダクトを開発できることだ。
ビジネス視点でサービス分割を考える場合に重要なのは、アジャイル開発の文脈における「プロダクトオーナー」（以後、PO）が責任を持ち、開発とリリースが可能な範囲でサービスを構築することだ。
逆説的に言えば、サービスを分割するスコープに対してPOを割り当てられない組織構成の場合、マイクロサービスアーキテクチャを採用するメリットは薄れてしまうといえるだろう。これは自社サービスの開発や、受託開発の場合でも変わらない。
サービスの分割単位は、DDD（Domain-driven design：ドメイン駆動設計）の構成要素とひも付けて語られることが多いが、重要なポイントは「POが自律的な開発プロセスを回すことのできる範囲」で分割することだと筆者は考えている。
システム視点での考え方
一方で、システム視点でサービスを分割する場合は以下のような観点がある。
部分的なスケール性を確保
システムの中で特定機能に負荷が集中する、あるいは負荷の集中が想定される場合は、その部分を別のアプリケーションとして分割して開発することが有効だろう。特定機能のみにスコープを絞ったスケールアウト／スケールアップが可能な構成は、システム全体としてのコスト効率を高めることにつながる。
障害時の影響範囲の局所化を実現
後述する「サーキットブレーカーパターン」などを適用することで、別のアプリケーションとして開発した部分で発生した障害をそのアプリケーションのみにとどめておくことが可能になる。これにより、システム全体としては稼働している状態を維持できるので、信頼性の向上を狙うこともできるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
ダイソーが6年でIT内製化、マイクロサービス化、サーバレスに成功した理由
アイティメディアが開催した「ITmedia DX Summit 2019年秋・ITインフラ編」の特別講演にダイソーの丸本健二郎氏が登壇。内製化によって、データ管理基盤の最適化、高度化を図ったいきさつと結果について講演した。
クラウドネイティブ活動の指針として、CNCFのCloud Native Trail Mapをどう考えるか
本連載では、2019年7月の「Cloud Native Days Tokyo 2019」でCo-chairを務めた青山真也氏と草間一人氏に、クラウドネイティブに関してじっくり語ってもらった対談の内容を、4回に分けて掲載している。前回の「クラウドネイティブは、どう誤解されているか」に続き、今回は第2回として、「CNCFのCloud Native Trail Mapを、クラウドネイティブ活動の指針としてどう考えるか」をテーマとした部分をお届けする。
DXも台無しにしかねない日本企業の「ソーシング問題」――「内製化が難しい」なら、どう戦うか？
デジタルトランスフォーメーション（DX）の潮流が高まる中、社会全体で「イノベーション」や「スピード」といった要素が注目されている。だが、いくら「新たな価値」を生み出したところで、それがビジネス／サービスである以上、信頼に足る品質を担保していなければ意味がない。特に内製が難しいトラディショナルな企業にとっては、一般的なIT活用でもDXにおける価値創出でも、社外の開発・運用パートナーと組むことが不可欠となる。そうした中でも、今のスタンスのままで本当に「ビジネス価値」を生み出すことができるのだろうか？