builderscon 2019 へ行ってきた(Day1)
途中抜けだったけど今回もめちゃ楽しくて刺激を受けた。
コンパイルのライブコーディングは一体感があって楽しかった。会場からエンバグを指摘してくれたり。
マイクロサービスも多くの会社からノウハウが出てきている。
自社も一部モノリスからマイクロ化していく流れだし、今後は加速していきたい。
影響を小さくするために切ったプロダクトから派生するプロジェクトをどう管理していくか?という点は気になっていたがWandelyさんのProtocolBufferのセッションでは、結局集約して管理しているという話。
マイクロ化する中でもShcemaのような他プロダクトプロジェクトに影響する部分については、他プロダクトへ簡単に利用できるようなプラットフォーム化は同時に進めて行かないといけない。
Open SKT: メルペイ開発の裏
メルペイでのサービス軍
- 40以上のマイクロサービスで構成されている
- メルカリもメルペイの決済基盤を利用
マイクロサービス設計
- 4層アーキテクチャ
- Client -> ApiGateway(<->Authority) -> Api Service -> Backend Service
- Backend Service は無数あり、Api ServiceがClientへのレスポンスに責務を持つ
分散トランザクション
- エラーを例外として捉えない
- 共通のエラーモデル
- 共通モデル
- リトライと冪等性
- Try/Confirm/Cancelパターン
- 状態遷移モデル
- どの状態まで進んだかを記憶している
- サーバが落ちても途中から復旧できる
リコンサイル
- データの整合性確認
QA
- なぜTry/Confirm/Cancelとリコンサイルの重複処理を行うか?
- どちらか一方に不具合がないとは言えないため
- 中央にいるサービスのデータをマスタとして捉え各サービスのデータをリコンサイルする
トランザクションモニタリング
メルペイでの開発フロー
あまり聞かない部分のみ抽出
DesignDoc
- 開発設計まえの開発設計レビューがある
- ドキュメントを書き、アーキテクト、SRE、セキュリティ、関連チームからのレビュー
- 目的:今から行う事がどれくらい懸念があるかを知るり、事前にリスクを洗いしチーム間で共有する
-
- マイクロサービスの運用はすべて開発チームで行う
- PRDはSREしか見れない(個人情報、資産があるため)
- 開発チームがPRDを見れるようにマスキング、参照する仕組みを用意
メルカリとメルペイの開発フローの違い
- メルカリ
- 守るべきものは守り 強くチャレンジする
メルペイ
- より高い信頼性 その上で機能がある
最大化したい価値が異なる
- SLOを高く設定するとチャレンジできる量が減る
- メルカリはサービスを早いサイクルで回していく
- メルペイは落ちないという事がシビアに求められる(高いSLO)
業界全体のレベルを上げるためにやっていく
- メルペイの事例を公開することで
- 透明性と信頼性の向上
- 他社が参考にできるように
- 逆に他社の事例を参考にしたい
用語
- SLO
- Postman
コンパイラをつくってみよう
Go->Assembly->標準出力
- コンパイルを学ぶ事によってプログラムについてちょっと理解する事ができる
- やりながら学ぶ
- 根気が必要(これを終わるまで何もしないという制約がモチベーションだったとか)
- Goのライブコーディングがめちゃ楽しかった。個人的な今日一番おもしろかった。
Web API に秩序を与える Protocol Buffers 活用
- @south37
- Protocol Bufferの利用シーン、メリデメを知りたくて参加
- Go / Ruby .proto から自動生成されたコードをプロジェクトで組み込む(秩序)
- 共通モジュールをどうやって管理してるか?
- .proto を集約したGitリポジトリで管理して、そこで吐き出したproto file を各プロジェクトで利用している運用に切り替わってきた
Web Componentsを利用した段階的AngularJS脱出作戦
- WebComponentsについて詳しく知らないので、インプットとして良い時間だった
- 現在のWebComponentsの状況
- CustomElementでWrapしたAngular / React / Vue の利用方法
今回も運営のみなさん、スピーカーの皆さん、スポンサーのみなさん、ありがとうございました!!!!!