企業向けの管理システムを立ち上げるとき、最初に挙がるアーキテクチャの問いはたいてい「小さなサービスに分けるか、ひとつの塊で作るか」です。結論から言えば、社内向け管理システムの多くは、よく整理されたひとつの塊が正解です。そして面白いのは「よく整理された」という部分にあります。
マイクロサービスの本当の代償
マイクロサービスが解くのは特定の問題です。複数チームが互いに独立してリリースする必要がある、あるいは一部の機能だけ拡張の要求が桁違いに大きい、という場合です。そのどちらでもないなら、費用だけを払い、利点は受け取れません。
- 分散トランザクション。ひとつの業務処理が二つのサービスにまたがった時点で原子性は失われます。補償処理、中間状態、中途半端な状況への対応が必要になります。
- 障害調査が格段に難しくなる。四つのサービスを通る要求には集約された追跡基盤が要ります。なければ、どこで失敗したかを知るだけで何時間も溶けます。
- 参照データが複製される。従業員や取引先の一覧が複数の場所へ写され、やがて食い違います。
- 運用費が増える。サービスが増えれば配信経路も設定も増え、深夜に壊れうる箇所も増えます。
モノリスは「ぐちゃぐちゃ」の同義語ではない
古い大規模システムの問題は、ひとつの塊だったことではなく、内部に境界がなかったことです。ひとつの塊のままでも、業務領域ごとに分割し、それぞれが独自のデータモデルを持ち、他の領域とは定義された口を通してのみやり取りする形にできます。
.NETでよく使われる整理の仕方です。
- 層をはっきり分ける。業務領域は基盤技術に依存しない。アプリケーション層が処理の流れを持ち、基盤層がデータアクセスと外部サービスを持つ。
- ファイル種別ではなく機能で分ける。ひとつの業務が一か所にまとまっているほうが、コマンド一式・クエリ一式・モデル一式という三つの入れ物よりはるかに読めます。
- 更新系と参照系を分ける。更新系は業務ルールとトランザクションが要り、参照系は速さと柔軟さが要ります。両方を同じモデルに押し込むことが、肥大した問い合わせの出発点です。
分割が妥当な場合
小さなシステムでも、明確に分ける価値がある場面があります。
- 重い裏方処理：大量帳票の出力、画像処理、定期同期。重い処理が画面の応答を落とさないように分けます。
- 外部公開の入口：ウェブサイトやモバイル向けのAPI。求められる安全対策や流量制限が社内向けとまったく異なります。
- 変化の多い外部連携：専用の層で包み、相手の仕様変更を一か所の修正で済ませます。
三つとも、運用上の具体的な理由で分けている点に注意してください。「今風の構成だから」ではありません。
現実的な優先順位
サービスの数より境界の正しさが重要です。境界の明確な塊は後から分割できますが、境界を誤った多数のサービスを再統合するのはほぼ不可能です。
進め方は次のとおりです。
- ひとつの塊から始め、初日から業務領域ごとにモジュールを分ける。
- 他モジュールのテーブルへの直接アクセスを禁じる。最も重要で、最も破られやすい境界です。
- 分ける前に測る。滞留を示すデータがないなら、分割は当て推量にすぎません。
- 分けるときは、コードの中に既にある線に沿って分ける。新しい線を引かないこと。
境界が壊れているサイン
- ひとつの業務ルールを直すのに、関係のないモジュールをいくつも開く必要がある。
- 三つ、四つの業務領域をまたいでテーブルを結合している。
- マスタの小さな変更が、誰も予想しなかった帳票の不具合を起こす。
いずれもサービス分割では治りません。絡まった塊を分ければ、絡まったサービスの間にネットワークが増えるだけです。まず境界を直し、その後で分離を語るべきです。
