Architect's Log

I'm a Cloud Architect. I'm highly motivated to reduce toils with driving DevOps.

Microservices Meetup vol.8 Lightning Talks Battle!に参加しました

Microservices Meetup vol.8 Lightning Talks Battle!に参加したので、メモを共有します。

microservices-meetup.connpass.com

マイクロサービス縦に割るか横に割るか

  • ウェルネスラーニング開発
    • 横で割る
      • レイヤごとに専門性
      • フロントの方が改修頻度が高い場合デプロイがしやすくなる
    • 今回は縦で割った

Microservices時代の開発環境

speakerdeck.com

Qall-Dockerで作る開発環境

  • 本番はk8s、開発はDocker-Composeでよいのか
  • DraftというかHelmが辛そう
    • Helmの難点
      • テンプレートに引数をひたすら与えて分岐しまくるとツラミがある
  • kustomize
    • パッチをいかに楽に適用するか

Building Microservicesの輪読会が最高だった話

サービスの切り方

  • 全員が高凝集,低結合についての共通認識ができた

ミニサービスアーキテクチャでハードモードな現実を乗り越えたい

speakerdeck.com

苦労したこと

  • ドメイン境界の定義が難しい
  • モノリスをマイクロサービスに分割するのが難しい
  • 運用しないと業務知識が増えない→ジレンマ
  • 落としどころ
    • 業務領域は一番大きい単位で
  • Ross Garett
    • Mini Serviceはドメイン単位のサービス分割
    • MicroServiceはサービス分割してイベント駆動にして疎結合化する
  • 解決できそうなこと

新規サービス立ち上げでマイクロサービスしてない話

speakerdeck.com

  • 新規はモノリシックで実装するのが推奨
  • 早いサービスでの改善が求められる
  • マイクロサービスにしたいと思うとき
    • デプロイの容易性
    • 回復性
    • →このパターンはマイクロサービスに失敗しがち
  • マイクロサービスの分け方
    • 境界づけられたコンテキスト
    • 分割すると
      • トランザクション境界も分かれるはず
      • トランザクションが分割不可ということはコンテキストは分けられない
  • トランザクション境界
    • 新規サービス立ち上げのときから意識できる
  • 分けるということ
    • データベースを分ける
    • 複数DBの扱い
      • Railsでは複数DBを扱えない
  • 今のプロジェクト
    • 共通系統とユーザー系統でDBを分割
    • octopus

デプロイおじさんのお葬式

マイクロサービスのおけるデプロイ

  • 好きなときにデプロイしたい
  • いろんな言語のアプリがデプロイされる
  • 設定はどこにもつ?
    • 中央集権/各アプリでもつ
  • Dockerの場合はk8s,ecs必要

SSRに建てたnodeサーバーを認証機能を追加してBEFに転身させた話

SSR

  • サーバーサイドとCLで両方APIが実行される
  • 認証機能の実装
    • 案1
      • 別々に認証情報をもつ
      • 認証情報の乖離が面倒
    • 案2
      • 必ずnodeサーバーを経由する
        • 認証情報の管理が楽
      • エンドポイントは1つにしてどのAPIを叩くかなどの情報をパラメータで渡す
        • クライアントから叩くときとサーバーから叩くとき同じエンドポイント

Micoservicesのお陰でECS移行が大変だった話

  • やったこと
    • EC2からECSに5つのサービスに移行
  • 感じたこと2つ
    • サービス多すぎ
      • 58個
        • インフラ移行大変
    • 環境変数多すぎ
  • デプロイのフローがよくわかった

マイクロサービス化によってクライアントが受けた恩恵

単一障害点の解消

  • 任意のサービスが落ちても、アプリケーション全体が落ちることがなくなった
  • サービスが分割したことにより、UIで複数サービスを実行することになった
  • データ構造の差異
    • サービス間で違ったリソースを返す
    • BEF
      • リソース定義の差はBEFが吸収してくれる
  • 結論
    • クライアント側が辛くならないように進める

マイクロサービスのCache戦略

Retty

  • MicroService化していくためのプロジェクト
    • API Gateway Cache
      • 選択肢がある
        • Aggredate前にキャッシュ
        • Aggredate後にキャッシュ
  • まとめ
    • キャッシュ戦略は異なる
    • 未来を見据える
    • API Gateway Cacheはよく考えて採用しよう
  • FAQ
    • アプリとWebでキャッシュ戦略は異なる

マイクロサービスの分析基盤

  • データを集めること
  • データが参照しやすいこと
    • マイクロサービスで横断したい
  • Fincの分析機基盤
    • DMS
    • クライアントログ
      • FireHose→Redshift
    • サーバーサイド
      • Fluentd→Redshift
  • S3は便利
  • めったに使わないデータはS3にアーカイブ
  • サービスのデータがRedshifdtのデータを直接参照しない
    • Redshiftが不安定になるとサービスに影響が及ぶ
      • メンテナンスで重たいクエリが走るとサービスに影響が出る
    • S3にUnloadしてサービスはそちらを参照する
    • Copy中にクエリを発行して問題ないか

マイクロサービスにおける結果整合性との戦い

www.slideshare.net

結果整合性

  • 途中では整合性が崩れた状態に陥るが、十分に時間がたったら最終的には整合性がとれた状態になる
  • ACIDと対照的な概念

イベントドリブンアーキテクチャ

  • トランザクションが必要なデータは発行元で完結

結果整合性を担保する

  • リトライするべきかしないべきか
  • 同じデータでリトライしても大丈夫なように受け取り側で処理する
  • 冪統制
    • 失敗したら成功するまでリトライする
  • どうやって冪等性を担保するの?
  • 部分的なリトライ
  • 解決策
    • Idempotent transaction
  • 未解決な問題
    • 実行したかどうかをDBに保存している
      • Selectが純粋に1回増える
      • Indexは効くが数が増えるとDBが辛そう
  • そもそも整合性を担保できてない
  • サーバー超えてトランザクション維持したいときあるよね

感想

皆さん熱の入ったLTで聞いていて楽しかったです。

懇親会も盛り上がりました。ピザおいしかったです。FiNCの皆さん、登壇者の皆さんありがとうございました。