マイクロサービスアーキテクチャおすすめ資料9選まとめ

最初に

業務効率化を目的とした社内システム開発でマイクロサービスアーキテクチャを採用しようという事でキャッチアップしました。
そしたら、良い感じの資料がたくさん出てきたのでそこで得た知識をまとめてみました。
一般的なフレームワークに沿ったモノリスと比較しながらまとめると理解度が上がったので、まとめた際に書いた内容を今回は紹介したいと思います。
キャッチアップに使用した資料は最後に載せてあります。
そして自分自身曖昧な部分が多くあるので、トンチンカンな事を書いていたらコメントでご指摘ください。
よろしくお願いいたします。

モノリスについて

モノリスは一般的なアプリーケーションアーキテクチャで1つのアプリに複数の機能が存在するアーキテクチャとなります。
Django, Railsのようなフレームワークで作成されたアプリに多いです。

メリット

• メソッド単位なので各機能の呼び出しは高速に行える。
• フレームワークに沿えば設計が楽。
• トランザクション等を使えるためデータの整合性が担保しやすい。

デメリット

• Slack通知処理など1つの機能に対してインスタンス（応答出来るサーバみたいなもの）を増やして拡張したいとなった場合、全ての機能を拡張する事になる。
  • 理由としては1つのアプリケーションに複数の機能が存在するため。
• 他の機能の変更が全体の機能に影響する。
• システムで障害が発生した際に全ての機能が使えなくなる。

マイクロサービスアーキテクチャについて

メリット

• 影響範囲、テストする箇所を限定的に出来る

• どれか一つの機能で障害が発生しても使えない機能が限定される。

例：Slackへの通知機能で障害が発生しても、NotionDBのデータ更新・取得する機能自体に影響はない。

• Slackへの通知処理が他の機能から大量に呼び出される事が発生しても、その機能のみ拡張させる事ができる。
• 各機能に分離されているので機能ごとで開発サイクルを個別に持つ事が出来る。

• チーム毎に各機能に対して開発〜デプロイまでを一貫して行える。
  • このチームはこの機能に対して詳しいなどの開発・運用・保守の範囲を限定的に出来る。それぞれのチームで各機能に対して、責任を持つことが出来る。担当を持つ領域に関する深いドメイン知識を蓄えていくことができる。
  • 各個人がその機能について責任を持って開発が行える。
• 各機能が分離されているので、機能ごとに言語を選択できる。
  • 速度が欲しいならRust, Goを使用したり、生成AI, 機械学習系のライブラリを使用したいならPythonなど
• 各機能で独立してライブラリをインストールしているのでライブラリ依存関係を最小に出来る。そしてライブラリ更新が楽に行える。

デメリット

• 各機能が属人化してしまい、触れる人が限られる可能性がある。
• 各機能を実行するたびにリクエストが発生するため、ネットワーク速度などに左右されやすい。リクエストが失敗する可能性も加味しないといけない。
• トランザクション管理も難しく、データの一貫性を保ちにくい。

マイクロサービスアーキテクチャに関するアンチパターン

マイクロサービス化する上で避けたい事。

• 別のマイクロサービス間でデータを共有をしてしまう。
  • サービスAとサービスBで同じDBを使用していた場合、Aでカラム追加など行うとBへ影響が及ぶため。なのでマイクロサービスでは機能ごとにDBを持つ方が良さそう。

• 循環参照をマイクロサービス間で行なってしまう。
  • B, Eが互いに参照している事でCで障害が発生した際にその影響がEにまで及ぶため、マイクロサービス間での機能の参照は極力控える方が良さそう。

メルカリでのマイクロサービス化を行う上での失敗談（おまけ）

• メルカリではマイクロサービス間の通信にgRPCを採用したがgRPCに対しての各種ライブラリなどの対応が未熟で結局REST APIを使用する事になった。2018年度の話なので現在は違うが、新しい技術よりも枯れた技術を採用する方が手戻りの少ない開発が行えそう。
  ※現在はgRPC通信を採用している。
  フロントエンドにNext.jsをおいてgRPCで通信をやりとりするためにマイクロサービス群との間にNest.js書かれたAPI Gatewayを置いてRest API → gRPCと変換していると思われる。

最後に

1~2年前は企業の技術ブログを読んでも何を言っているのかまるで分からなかったので、今回キャッチアップする上でメルカリなどのテックブログを少し読めるようになっていて、感動しました。最近はアーキテクチャについて考える機会もあるので、少しずつでだけどエンジニアとして成長しているのかもしれないと思い少し嬉しくなりました。
まだまだ作業は遅いし成長速度も早いわけではないですが、カメのように少しずつの進めればと思います。
勤めている企業には設計周りで考える機会を下さりまたエンジニアとして雇って頂けてとても感謝しています。
いつもありがとうございます。

個人ブログも新しく作り直したいし、Chromeの拡張機能アプリ作りたいしでやりたい事がたくさんある。

マイクロサービスアーキテクチャを採用するに至ってこんな事気を付けてます。この資料おすすめです等、ありましたら教えて欲しいです。未熟者ですが、ぜひ意見交換したいです🙇🏻‍♂️

参考にしたおすすめ資料9選

[日本語通訳] DevDojo Microservices Development 101

メルカリの Microservices 化について

クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌跡〜 - クックパッド開発者ブログ

その先に進むためのモジュラーモノリス再入門

【Track A-5】アーキテクチャの進化から学ぶマイクロサービスの本質

マイクロサービス化したけど結局フルリプレイしていて面白かった。

メルカリWebのマイクロサービス化、その4年 | メルカリエンジニアリング

マイクロサービスな組織との向き合い方 | メルカリエンジニアリング

これ特におすすめ、メルカリが採用しているマイクロサービスアーキテクチャについてまとめられている。

メルカリShopsはマイクロサービスとどう向き合っているか | メルカリエンジニアリング

API Gatewayについて書かれていた。

ベストな「How」は「Why」でしか規定できない––メルカリがマイクロサービスに移行した理由と、その軌跡 | ログミーBusiness

記事に関するコメント等は

🕊：Twitter
👨🏻‍💻：Github
😥：Stackoverflow

でも受け付けています。どこかにはいます。