マイクロサービス化は必要か？ 独立した変更と運用負担で判断する

システムを小さなサービスへ分けた。それなのに、変更のたびに全チームが集まり、同じ夜に一斉リリースしている。図では分かれていても、仕事の進め方は以前と変わらない。増えたのは、確認する接続と運用する場所だけかもしれない。

マイクロサービス化を考えるときは、分割数より先に、独立して何を変えたいかを問いたい。別々に変更する必要があり、試験・配備・データの扱いを分けられる部分は切り出す。一緒に変えなければ成立しない部分は、一体型の内部整理から始める。 新しい構成を採用することを、改革の成果そのものにしないための選び方である。

一体型だから、速く届けられないのか

一体型のアプリケーションは、一つのまとまりとして動かし配備する方式である。その内部の責任分担まで曖昧である必要はない。モジュールの境界を整理し、変更箇所の影響を確かめやすくすることは、一体型でも取り組める。

Shahinらの2018年の著者公開論文は、9か国19組織の実務者21人への面談と、専門職91人への調査を通じて、継続的なソフトウェア提供と構成の関係を検討している。一体型と継続的な提供は本質的に両立しないものではなく、小さく独立して配備できる単位や運用への配慮が重要だと整理した。原論文

ただし、これは構成を無作為に割り付けた比較実験ではない。実務者の経験と回答から得た知見であり、分割すれば何日速くなるといった因果効果を示すものではない。回答者が継続的な提供に関わる人々である点も、一般化の範囲に関係する。

したがって、一体型を続けることを無条件に保守的と評価するのも、分割を無条件に先進的と評価するのも早い。今の遅れが、構成の結び付き、試験環境の待ち、承認、運用の準備不足のどこから生じるかを分けたい。

求めるのは、サービスの数より変更の独立性

DORAの研究紹介では、他チームと細かな調整を重ねずに変更でき、独立して試験・配備できる組織と技術の構造を重視している。古い技術でもその状態を実現でき、新しい技術を採用しても実現できない場合があると説明する。DORAの公式解説

この知見は、独立性を目標にする理由になる。一方、調査上の関連を、特定の製品や構成への移行が必ず成果を生む証明として使うことはできない。技術の名称ではなく、仕事を待たずに進められる範囲を確かめる必要がある。

例えば、一つの機能の修正でも、別サービスのデータ構造を同時に変える必要があるなら、切り分け方を再検討したい。別々の実行環境へ置いたことと、変更を独立させたことは異なる。接続先の振る舞いが変わらない約束を保てるかが重要になる。

その独立性は、変更履歴でも確かめられます。単独で試験・配備・切戻しできた変更と、他チームの同時変更や承認を待った変更を分けます。互換期間やデータ所有を変える費用も含め、サービス数ではなく、独立して届けられる変更が増えるかを比較します。

切り出す前に、運用できる境界を作る

以下は研究と実務資料から組み立てた編集上の提案である。最初の候補は、変更する理由や頻度が周囲と異なり、仕事上の責任を説明できる部分から探す。画面の数やコードの行数だけで細かく切ると、利用者の一つの操作が多くのサービスをまたぐ構成になり得る。

次に、障害が起きたときに誰が調べ、何を復旧するかを決める。あるチームが開発だけを受け持ち、運用側には接続全体の知識がないなら、独立性を作ったつもりで調整を移しただけになる。

Fowlerの2014年の実務記事は、マイクロサービスに進む前提として、迅速な環境準備、監視、配備などの能力を挙げている。これは実務家による経験の整理であり、統計的な優劣の検証ではない。Microservice Prerequisites

サービスが増えると、どこで処理が止まったかを追えることも必要になる。分割した後で監視を考えるより、最初の切出しで、利用者の処理と各部分の状態を対応づけて確認できるかを試す方が判断しやすい。

データだけ共有したまま、独立したと言えるか

複数サービスが同じ表を自由に書き換える状態では、一方の修正が他方の前提を壊す可能性がある。逆に、データを別々にすれば問題が消えるわけでもない。同じ取引の途中で、一方だけ成功する状態への対処が必要になる。

ここでは「データベースを何個にするか」だけを決めない。どの情報を誰が更新し、相手は何を約束として利用するのかを定める。更新のずれを許せない処理なのか、後から整合させられる処理なのかによって、分ける難しさが変わる。

独立性に必要な設計を説明できない段階で分割を先行させると、通信越しに同じ結び付きを持つことになる。内部の依存関係を整理することには、移行しない場合にも価値がある。

同じ販売システムでも、選ぶ境界は違う

架空の販売システムで、商品紹介の内容を毎日変える一方、受注処理は安定しているとする。紹介部分が受注データを直接更新せず、必要な情報を決めた方法で受け取れるなら、別々の変更周期を持たせる候補になる。

条件を変え、割引の適用、在庫の確保、注文の確定を頻繁に同時変更しているとする。そのルールもまだ変わり続けているなら、機能名だけで細かく切るより、同じ業務上の判断として内部を整理する方が有力になる。分けることで同時変更が減る見込みがなければ、独立性への投資理由は弱い。

さらに、紹介部分の独立性は高いが、担当できるのは同じ少人数で、運用準備も手作業だとする。その場合は、切出しの前に配備や監視の共通基盤を整える選択がある。技術的に分けられることと、今その構成を維持できることは別だからだ。

この例は特定の構成を推奨する万能表ではない。切り出す価値が生まれる理由と、その費用を引き受けられる条件を同じ場で比較するための仮想例である。

最初から分けるべきだという反論もある

実務家のStefan Tilkovは2015年の記事で、後から切り離すつもりで一体型を作っても、依存関係が強くなって分離が難しくなる点を論じ、マイクロサービスを目指すなら最初から境界を分ける立場を示している。本人による論考

この反論は、一体型なら準備を先送りしてよいという考えを退ける。一方、統計的な比較実験ではなく、経験に基づく設計上の議論である。分ける境界が既に分かり、独立運用の能力もある組織と、業務のまとまり自体を探している組織で、出発点を同じにする必要はない。

一体型を選ぶ場合でも、どの部分が他の内部へ直接依存してよいかを決め、実際の変更でその境界が保たれるかを見る。将来切り出すという予定だけを、現在の整理をしなくてよい理由にしない。逆に、境界が明確な部分まで一律に同じ配備単位へ閉じ込める必要もない。

最初の切出しで、移行を続ける理由を確かめる

評価は、作ったサービスの数より、その部分を変えるために待った時間へ向ける。独立したリリースが増えたか、全体試験に戻る回数が減ったか、障害時に原因を絞れるかを確認する。同時に、問い合わせや運用作業が別チームへ増えていないかも見る。

改善が見えない場合、全ての分割が誤りとは限らない。境界が悪いのか、共通の承認が残っているのか、計測できないだけなのかを分ける。ただし、サービス数を増やせばいつか効くとして、同じ問題を拡大しないようにする。

独立した変更が必要で、運用とデータの境界も成立するなら切り出す。まだ一緒に変える仕事なら、まず一体型の中で責任と依存を整理する。構成の刷新に投資する理由は、箱が増えることではなく、必要な変更を他の仕事を止めずに届けられることにある。