👻

Souzoh Tech Talk #02: Microservices

2021/09/07に公開

マイクロサービス

概要

2021/08/25に開催された下記勉強会のメモです

パネルディスカッション

microservisの構成

構成
- フロントエンドとBFF
  - Typescript
- サーバサイド
  - Go
- データベース
  - CloudSQL(PostgreSQL)
- 通信
  - GraphQL
  - gRPC
40弱のサービス群
Cloud Runで動かしている
- 制約はあるがシンプル
- 結果としてはよかった
Monorepoを採用

こちらの記事も参照

0->1の立ち上げとMicroservices

なぜMicroservicesにしたのか？
- メンテナンス性の高さ、開発のスピード
- メンバーがMicroservicesに慣れていた
- モノリスでいいんじゃないかみたいな話はなかったか？
  - なかった
Microservicesにしてよかったところ
- サービスの責任範囲が明確でわかりやすい
- 難しいことができないのでスパゲッティになりにくい
- 分担しやすい
- スコープが小さく設計がシンプル
  - gRPC採用した結果、インタフェースによる強制力ができた
- オンボーディングやりやすい
Microservicesの課題
- サービス間の整合性は難しい
- ローカルで開発するときサービスを全部立ち上げる必要がある
  - 現状サービスが40こあるが、増えていった時にどうするか問題
  - MonorepoなのでMultiよりは楽
- トランザクションどう担保するか？
- 作業が冗長になりやすい
  - 似たようなのをいっぱい書く
- 設計が難しい
  - どの単位で作る？など経験が求められる
- 技術スタックが詰め込まれると誰ができる？となる

Microservicesとデータの整合性

丁寧に設計しても不整合は発生する
うまくいかないところは受け入れて、どうやって直していけるかを頑張る
冪等に作るのを大前提
- だめな時はだめなので不整合になった時どうするかを考える
小さく作る
- 整合性を保たなければいけない範囲を小さくする
  - 色々やりすぎない
  - 難しさが増える
息を吸うように意識
- 身をもって経験していく
減らす努力
- 起こった時に辻褄をあわす
検知してマニュアルで対応？自動的？
- 場合によるが、まずは仕組みを入れておくこと
- 開発段階から考えておくことが重要
整合性を担保するために工夫している点
- 冪等性/リトライ戦略/非同期処理

Microservicesの分割基準

分割基準をどのように考えているか？
- シンプルに絞る方向で
- 具体的な名前にして抽象的なサービスを作らない
  - ドメインで
    - プロダクト、ペイメント、ショップ、オーダーといったサービスがある
  - キャンペーン管理でなく、具体的なxxxキャンペーンにするなど
    - 終わったら後で切り離しもできる
失敗した事例など
- CSツールというサービスを作ったが大きくなってしまった
  - オペレーターの管理、操作ログ、メモ

Q&A

リカバリー機能はマイクロサービス？
- 答えるならyesだが、進化していくので今後はわからない
リカバリーするタイミングは？
- 自動的にするもの、調査してからでないとできないものがある
  - Big Query叩いたりもしている
マイクロービスを0から勉強するにはどうすれば良い？
- それを必要としてる組織に入る
- やってみる

Discussion