マイクロサービスと設計原則 — 設計Night2018 登壇報告 #sekkei_n2018
qsona です。先日、”設計Night2018"というイベントが行われ、「マイクロサービスと設計原則」という題目で登壇させていただきました。
懇親会まで盛り上がり、楽しいイベントでした！企画・お誘いしてくださった主催の 猫型🐱蓄音機 さん、Classi様、会場をご提供いただいたRetty様、ありがとうございました。
登壇内容と補足
マイクロサービスの設計に対して、どう設計原則を使うのか、という話をしました。本稿では、資料中のいくつかの点に補足したいと思います。
SRP (単一責任原則)
単一責任原則原則について、提唱者である Robert C. Martin 氏が2014年にさらに考察している記事を紹介しました ( The Single Responsibility Principle )。
この中では、変更する理由は「人」であるということに強くフォーカスされています。この考え方は、マイクロサービスの現実の問題に非常にマッチするため、今回取り上げました。ただ、筆者個人の考えではつねにこの「人」にフォーカスするのが常に現実の問題を解決するのに役立つかは疑問で、場合によっては受け取り方には注意が必要かなと思います。単一責任原則は、この追記がなくても長く大事にされてきたものです。
マイクロサービスの統合
マイクロサービスをどう統合していくのかというのは、非常に重要な設計課題です。マイクロサービスの結合点については、以下のトークでもお話しました。
また、このトークを行ったイベントについて、以下のレポートでまとめています。クライアントサイド視点でのマイクロサービスについて多く触れていますので、よければこちらもご覧ください。
分断されたモノリス
「分断されたモノリス」は、Quipper社の kyanny さんが上の発表の中で使った言葉で、主に複数サービスでDBを共有しているような状況を指しています。
私の今回の発表でも触れたように、共有データベースはサービス間の密結合をすすめてしまうものの、実際には特にスタートアップのフェーズでメリットもあり、多くの企業にて見られるパターンです。その後辛くなってきたときにどうリアーキテクトしていくかの方向性の一つとして、
- 既存のデータを中心としたバックエンドサービスを作る
- 現在あるサービスは、プレゼンテーションに近いサービスと捉え、バックエンドサービスを集約する (DBへの依存を剥がしていく)
というパターンを資料 p.44–45 で示しましたが、この考えについても、実は kyanny さんと話している中で提示してもらったものです。
トークの中では口走りましたが、SoE/SoRという分類の考え方も近いかもしれません。また、以下の記事も参考になります。
GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて — lacolaco
なお、いわゆる分断されたモノリスについての考察を、以下の同人技術書に書いていますので、ご興味ある方はぜひ。(kyannyさんと、食べログの寺島さんに取材させていただきました)
Presentation / Domain の境界について
PDS (Presentation Domain Separation) という原則を使って話を進めましたが、現実にはこの境界が曖昧なものが存在することがあります (p.48) 。これについての一つの事例を書いたことがあるので、ご紹介します。
マイクロサービス指向 Rails API 開発ガイド (事例は p.40〜)
内容の補足は以上になります。マイクロサービスを始めたり進めたりしていく上での、設計を支える何かになれば幸いです。
末筆ですが、今回のイベントは 猫型🐱蓄音機 さんのbuildersconでの素晴らしい発表 をベースに作られたもので、資料を作るにあたりこの発表資料を読み返したり、マイクロサービスに適用してみるといった考える過程で私自身に多くの発見がありました。おかげさまで楽しく登壇させていただきました。ありがとうございました。
エンジニア積極採用中！
FiNCのサービスを作っていく上では、日々このようなマイクロサービスの設計判断をしながら、小規模サービスをスピード感をもって開発しています。マイクロサービスの設計に興味がある方、ぜひ Wantedly や twitter (qsona, DM開放中) などで気軽にお声がけ下さい。お待ちしています。
