Microservices Meetup vol.8 Lightning Talks Battle!に参加したので、メモを共有します。
microservices-meetup.connpass.com
マイクロサービス縦に割るか横に割るか
- ウェルネスラーニング開発
- 横で割る
- レイヤごとに専門性
- フロントの方が改修頻度が高い場合デプロイがしやすくなる
- 今回は縦で割った
- 横で割る
Microservices時代の開発環境
Qall-Dockerで作る開発環境
- 本番はk8s、開発はDocker-Composeでよいのか
- DraftというかHelmが辛そう
- Helmの難点
- テンプレートに引数をひたすら与えて分岐しまくるとツラミがある
- Helmの難点
- kustomize
- パッチをいかに楽に適用するか
Building Microservicesの輪読会が最高だった話
サービスの切り方
- 全員が高凝集，低結合についての共通認識ができた
ミニサービスアーキテクチャでハードモードな現実を乗り越えたい
苦労したこと
- ドメイン境界の定義が難しい
- モノリスをマイクロサービスに分割するのが難しい
- 運用しないと業務知識が増えない→ジレンマ
- 落としどころ
- 業務領域は一番大きい単位で
- Ross Garett
- Mini Serviceはドメイン単位のサービス分割
- MicroServiceはサービス分割してイベント駆動にして疎結合化する
- 解決できそうなこと
- トランザクション処理に悩まされない
- 業務知識
- デプロイ整備が軽減
- リポジトリサービスが乱立しない
- 全体像の把握
- https://thenewstack.io/miniservices-a-realistic-alternative-to-microservices/
新規サービス立ち上げでマイクロサービスしてない話
- 新規はモノリシックで実装するのが推奨
- 早いサービスでの改善が求められる
- マイクロサービスにしたいと思うとき
- デプロイの容易性
- 回復性
- →このパターンはマイクロサービスに失敗しがち
- マイクロサービスの分け方
- 境界づけられたコンテキスト
- 分割すると
- トランザクション境界も分かれるはず
- トランザクションが分割不可ということはコンテキストは分けられない
- トランザクション境界
- 新規サービス立ち上げのときから意識できる
- 分けるということ
- データベースを分ける
- 複数DBの扱い
- Railsでは複数DBを扱えない
- 今のプロジェクト
- 共通系統とユーザー系統でDBを分割
- octopus
デプロイおじさんのお葬式
マイクロサービスのおけるデプロイ
- 好きなときにデプロイしたい
- いろんな言語のアプリがデプロイされる
- 設定はどこにもつ？
- 中央集権/各アプリでもつ
- Dockerの場合はk8s,ecs必要
SSRに建てたnodeサーバーを認証機能を追加してBEFに転身させた話
SSR
- サーバーサイドとCLで両方APIが実行される
- 認証機能の実装
- 案1
- 別々に認証情報をもつ
- 認証情報の乖離が面倒
- 案２
- 必ずnodeサーバーを経由する
- 認証情報の管理が楽
- エンドポイントは１つにしてどのAPIを叩くかなどの情報をパラメータで渡す
- クライアントから叩くときとサーバーから叩くとき同じエンドポイント
- 必ずnodeサーバーを経由する
- 案1
Micoservicesのお陰でECS移行が大変だった話
- やったこと
- EC2からECSに５つのサービスに移行
- 感じたこと２つ
- サービス多すぎ
- 58個
- インフラ移行大変
- 58個
- 環境変数多すぎ
- サービス多すぎ
- デプロイのフローがよくわかった
マイクロサービス化によってクライアントが受けた恩恵
単一障害点の解消
- 任意のサービスが落ちても、アプリケーション全体が落ちることがなくなった
- サービスが分割したことにより、UIで複数サービスを実行することになった
- データ構造の差異
- サービス間で違ったリソースを返す
- BEF
- リソース定義の差はBEFが吸収してくれる
- 結論
- クライアント側が辛くならないように進める
マイクロサービスのCache戦略
Retty
- MicroService化していくためのプロジェクト
- API Gateway Cache
- 選択肢がある
- Aggredate前にキャッシュ
- Aggredate後にキャッシュ
- 選択肢がある
- API Gateway Cache
- まとめ
- キャッシュ戦略は異なる
- 未来を見据える
- API Gateway Cacheはよく考えて採用しよう
- FAQ
- アプリとWebでキャッシュ戦略は異なる
マイクロサービスの分析基盤
- データを集めること
- データが参照しやすいこと
- マイクロサービスで横断したい
- Fincの分析機基盤
- DMS
- クライアントログ
- FireHose→Redshift
- サーバーサイド
- Fluentd→Redshift
- S3は便利
- めったに使わないデータはS3にアーカイブ
- サービスのデータがRedshifdtのデータを直接参照しない
- Redshiftが不安定になるとサービスに影響が及ぶ
- メンテナンスで重たいクエリが走るとサービスに影響が出る
- S3にUnloadしてサービスはそちらを参照する
- Copy中にクエリを発行して問題ないか
- Redshiftが不安定になるとサービスに影響が及ぶ
マイクロサービスにおける結果整合性との戦い
www.slideshare.net
結果整合性
- 途中では整合性が崩れた状態に陥るが、十分に時間がたったら最終的には整合性がとれた状態になる
- ACIDと対照的な概念
イベントドリブンアーキテクチャ
- トランザクションが必要なデータは発行元で完結
結果整合性を担保する
- リトライするべきかしないべきか
- 同じデータでリトライしても大丈夫なように受け取り側で処理する
- 冪統制
- 失敗したら成功するまでリトライする
- どうやって冪等性を担保するの？
- 部分的なリトライ
- 解決策
- Idempotent transaction
- 未解決な問題
- 実行したかどうかをDBに保存している
- Selectが純粋に１回増える
- Indexは効くが数が増えるとDBが辛そう
- 実行したかどうかをDBに保存している
- そもそも整合性を担保できてない
- サーバー超えてトランザクション維持したいときあるよね
感想
皆さん熱の入ったLTで聞いていて楽しかったです。
懇親会も盛り上がりました。ピザおいしかったです。FiNCの皆さん、登壇者の皆さんありがとうございました。
