毎日のようにコードを書きかえているのに、少し変えただけで別の場所がエラーになる。思ったより面倒。自分のせいじゃないのに、なぜか責任を感じてしまう。あなたの作業がスムーズに進まない理由、それは「システムがつながりすぎている」からかもしれない。
Contents
マイクロサービスってなに？
マイクロサービスは、システムの中身を小さなパーツに分ける考え方。
たとえばネットショッピングのアプリを考える。ログイン、商品を見る、カートに入れる、注文する、支払いする。こういう機能をそれぞれ別のサービスに分けるのがマイクロサービス。
全部を1つにまとめて作る方法を「モノリシック」と呼ぶ。それに対して、小さな部品をバラバラに作って動かす方法がマイクロサービス。
ただ分けるだけじゃなくて、“どうつなぐか”がとても大事になる。
「ゆるくつなぐ」ってどういうこと？
マイクロサービスを支える考え方が「疎結合（そけつごう）」。
これは、サービス同士のつながりをできるだけ少なくしておくという意味。たとえば「ユーザー管理」と「支払い」のサービスがあったら、なるべくおたがいの中身を知らずにやりとりする。
学校でいうと、別のクラス同士が必要なことだけメッセージカードで伝え合うような感じ。直接行って手伝ったりはしないけど、ちゃんとつながってはいる。
この「ゆるいつながり」が、マイクロサービスのいちばん大事な部分になる。
疎結合でなにが良くなるの？
● 別々に作って、別々に動かせる
「ログイン」を作るチームと、「注文」を作るチームが、同時に作業できる。ほかのチームを待たなくていい。完成したらそれぞれ別に動かせる。
● ひとつ止まっても、ほかは止まらない
「支払い」のサービスが一時的に止まっても、「商品を見る」はそのまま使える。全部が一気に止まることがないから安心。
● よく使うサービスだけパワーアップできる
たとえばセールで「注文」のサービスだけすごく使われるなら、その部分だけ数を増やして対応できる。他のサービスはそのままでOK。
● 道具が違っても一緒に使える
「ユーザー管理」はJava、「データ分析」はPython、とちがう作り方でも同じチームで動かせる。サービス同士は中身を知らなくても、決められたルールでやりとりする。
これら全部が「疎結合」でつながっているからできること。
逆に「つながりすぎる」とどうなるか？
「強結合（きょうけつごう）」という考え方になる。サービス同士がベッタリくっついている状態。
- ひとつ変えたら全部に影響が出る
- 1つが止まると全部が止まる
- 作る順番を考えないと開発できない
- デバッグ（原因さがし）がむずかしい
まるでたこ足配線で電気を使っていて、1本がショートしたら全部止まるような状態。
疎結合を作る方法
● APIという「共通のことば」を使う
RESTやgRPCなどのルールを使えば、どのサービスも同じルールで会話できる。中身がどうなっているかを知らなくてもOK。
● メッセージを送って「あとでやってもらう」
すぐに返事がいらないときは、メッセージキューという箱にリクエストを入れておく。サービスが落ちていても、あとで取り出してやってくれる。
学校で言えば、「後で見てね」ってメモを机に置いておくような感じ。
● おたがいの約束を決めておく
OpenAPIなどで「どういうやりとりをするか」を先に書いておけば、そのルールを守れば、中身は自由に変えてOK。
レストランの注文票みたいなもので、「この紙通りに作ってね」とだけ伝えれば、あとは厨房がどう作っても自由。
サービスって何なの？
マイクロサービスでは、「サービス」はただの部品じゃない。
サービスには3つのものがある：
- データ（たとえばusersテーブル）
- やること（たとえばユーザーを作る、在庫をへらす）
- つなぐ口（API）
これらがセットになって、はじめて「サービス」と言える。
サービスはただのデータ置き場じゃない
たとえば「在庫管理」は、ただデータを記録するだけじゃない。
「在庫が少なくなったら自動で発注する」「ゼロになったら通知を出す」といった判断ルールも中に入っている。
サービスは、小さな頭脳が入った部品とも言える。
例：ネットショッピングのマイクロサービス
| サービス名 | やること |
|---|---|
| ユーザー管理 | 登録、ログイン、認証など |
| 注文管理 | 注文の作成、ステータスの管理 |
| 在庫管理 | 在庫数を減らす、ゼロなら自動で発注する |
たとえばユーザーが注文すると、注文サービスが在庫サービスに「この商品へらして」とお願いする。それぞれが自分のことだけやっているけど、連携はしている。
もし在庫サービスが一時的に止まっても、注文の情報はいったんメッセージキューに保存されてあとで処理できる。こうすると全体が止まらない。
困ることもある
疎結合にもむずかしさはある。
- 原因を見つけるのがたいへんになる
- サービスの数が増えると管理が大変
- 通信が多くなるとスピードが落ちることもある
だけど工夫すればカバーできる。ツールやルールをちゃんと使えば大丈夫。
まとめ
マイクロサービスでは、「小さく分ける」だけじゃなく「どうつなげるか」がとても大事。
疎結合という考え方で、つながりすぎないようにしておくと、こわれにくくて動かしやすいシステムになる。
ゲームで言えば、ひとつのキャラが倒れてもパーティー全体が戦えるようなもの。
しっかり設計すれば、変化に強くて、チームで作りやすいアプリができあがる。やることは多いけど、いい未来を作る仕組みとして、とても使える考え方。