👻

Souzoh Tech Talk #02: Microservices

2 min read

概要

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

https://mercari.connpass.com/event/221977/

https://www.youtube.com/watch?v=9ZRZeHWR80Q

パネルディスカッション

microservisの構成

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

こちらの記事も参照

https://engineering.mercari.com/blog/entry/20210806-3c12d85b97/

0->1の立ち上げとMicroservices

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

Microservicesとデータの整合性

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

Microservicesの分割基準

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

Q&A

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

Discussion

ログインするとコメントできます