10年前くらいはマイクロサービスする環境が整っていなかったが一気に環境が進んだ
実行環境のコンテナ化(仮想化)
実行環境間の通信(HTTP通信、非同期メッセージング)
クラウド上に提供される様々な実行環境サービス
それらに対応したフレームワーク・ライブラリ
マイクロサービスパターン
現実のビジネス活動は、一般的には非同期・並列パターンで行われています。
そういうビジネス活動を支えるしくみとして、マイクロサービシズによるアプリケーションで非同期・並列パターンを採用することは、有力な選択肢となりえます
(同期 | 非同期) x (直列 | 並列)を適切に組み合わせる
直列 - 同期: モノリスのようなパターン
直列 - 非同期: 結果を次のキューに詰めて、サービスをリレーする
並列 - 同期: 複数サービスに同時にリクエストを発行して、同時にレスポンスを末(フロントエンドの画像読み込みなど)
並列 - 非同期:トピックにPublicして、それを複数サービスにSubscribeさせる
非同期・直列&並列による集約パターンも存在すする。
トピックで複数サービスにSubscribeさせ
各サービスが結果をキューに積める
最後の末端サービはキューを順場に処理していく
同期方式
長所
モノリシックなサブルーチン呼び出しと同じ考え方で設計できるので、多くのエンジニアにとって取り組みやすいパターンでしょう。
短所
しかし、依存関係が強く、また処理のタイミングが同じですので、分割したサービス間が密結合になり、変更の影響がほかのサービスに波及しやすくなります。
非同期方式
長所
キューやトピックと呼ばれるメッセージ送信のしくみ(チャネル)を間に挟みサービス間の関係を疎にできます
原理的には、送信相手について何も知る必要はありません
変更への対応を迅速に低コストで実現するためには、非同期方式の疎結合が優れています
短所
非同期方式の通信スタイルでアプリケーションを組み立てることは、同期方式と異なる設計ノウハウが必要です。
処理の順番やタイミングがばらばらになるので、同期的な連携とは本質的に異なる設計が必要です。
どういう方針で分割するか?
重要なのは「独立性」であり「境界」です。
粒度を均一するわけではない
意味のない単位まで分解しすぎてもいけない
意味的に独立し、サービス間の境界が単純明解になる場所を探すことが基本です。
つまりドメイン知識、サービスへの深い知識が求められる
私見的直観
銀の弾丸ではない
モノリスtoマイクロに失敗したサービスもある
モノリスに戻したサービスもある
モノリスでは1つの修正の影響範囲が大きくなるため、影響範囲減らしたいしたいというのが主な目的
責務を分割化することで影響範囲を小さくとどめる
影響範囲が少ないのでチームを細かく分けて開発を高速化できる
小さいパーツを組み上げていけばいいので、言語の縛り・フレームワークの縛りが減り、技術者の裁量になる
様々な技術を使用できるので良いエンジニアの受け皿にもなる
マイクロサービスの疑問点
どういう粒度でマイクロ化するのが良いかは、そのサービス次第。
つまりドメイン知識がかなり求められる
モノリスの歴史や文脈、方向性を把握していないと分割は難し
私はかつてモノリスをマイクロ化しようとしたけど失敗したのを思い出した
チーム粒度の悪さ
チームの開発力=APIの良し悪し、APIの追加対応のスピード
チームバランスを保てずAPIを作るのにコストがかかり、関数呼び出しをおこなうようになり再度モノリス化した
2010年代始めなので、今はもっとAPIも作りやすいし、API呼び出しも簡単になっているので当時と比べたらマイクロ化はしやすくなった(フレームワークに沿っていけばよいだけになった)はず
参考文献
Software Design 2020年1月号
100万行オーバーのモノリシックRailsアプリをマイクロサービス化したクックパッドの手順