:::: MENU ::::

Microservices Meetup vol.2メモ


勉強会に参加した際のメモを記録しておきます。
http://microservices-meetup.connpass.com/event/36394/

マイクロサービスとSREの役割

  • conway’s way
    • 組織とサービスが似通う

SRECon 2016 wrap up

  • Netflix
    • Freedom & Responsible
    • すべての開発者がNetflixを壊せる権限を持つ
    • Freedomを持つためにはツールが必要
  • 社内ツールもプロダクションと同等のものを作る

  • Uber

    • 開発者はサイトの信頼性に1%程度しか興味を持てない
    • Chaos Engineeringで定期的に壊すことで障害を意識するようにする
  • 障害対応時にbotにやっていることをつぶやくことで、最終的に障害レポートを作ってくれるとか

    • New Relicでこういうことをやっている

マイクロにしすぎた結果がこれだよ

  • コンポーネント単位でAPI経由で分けるようにしていた
  • マイクロサービスのデメリット
    • 全体を見渡せる人が少ない
    • オーバーヘッドあり
    • 障害時の影響範囲の見極めが難しい。どこに問題があるかがよくわからない
    • 通信コストが多い
    • 共通部分のデプロイが多くのサーバにデプロイする必要がある
    • API IFの変更が辛い. モノリシックのDB変更がAPIレイヤーに移動したような感覚
  • マイクロサービスは組織論
    • チームをスケールさせたい時はマイクロサービスが向いていそう

マイクロサービスの実際と対策

  • 会社紹介
    • APIはswaggerで書いている
    • アプリはnode
    • mesos
    • deploy / docker / api gateway
    • kong
  • 良い点
    • デプロイが楽になる
  • マイクロサービスは要件に十分な複雑さがない限りペイしない
  • マイクロサービスを始めるには
    • 仙人のスモールチームが必要
  • マイクロサービス間の通信状況を可視化したい
    • twitterがossを出しているらしい
  • マイクロサービスのテスト
    • コンポーネント間のテストはどうするのか

より良いAPIを作るために

  • BFF Backend for Frontend
    • Backendはgo
    • frontendはrails / nodeなど、好きなやつ
  • Versionはhttp accept headerにする
  • paging情報もhttp link headerに入れる
  • wantedly/apig
    • model情報を書くとAPIが全部できるようにするgenerator

So, what do you think ?