Microservices Meetup vol.2
勉強会に参加させてもらったのでメモ
勉強会概要
microservices-meetup.connpass.com
発表
「マイクロサービスとSREの役割」by 鈴木@kenjiszk (株式会社FiNC)
- コンウェイの法則
- 理想形？各microsericeのチームにSREをいれるのがよい？
- SREのリソースがネックになりつつある
- SRE業務ができる人材を育てる。権限の委譲を進めながら
- 開発/SREの壁をどんどんとり払っていく
- SREももちろんコードを書く
- SREが責任を持って守るライン
- セキュリティ
- コスト管理
- スケール
- 新技術の取り組み
マイクロサービスの本やInfrastructure as Codeの話等々を踏まえて自分は、セキュリティは独立したチームを組むべきで、逆にそれ以外は各microservicesのチームに託していくべきだと思っている。
SRE（の役割）とは各microservicesのチームに含まれている部分もあれば、独立して担う役割の部分があると思ってる。当然各チームや会社によって範囲は変わってくる。
なのでマイクロサービスとSREというのはそれぞれの解釈？定義が違うので一概に語ることは難しく、FiNCさんの場合はという感じで聞いていた。
参考
マクロサービスアーキテクチャを数回読んだ - tsyoshin blog
Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code に参加してきた - tsyoshin blog
「SRECon 2016 Wrap Up」by 坂本さん@takus (スマートニュース株式会社)
- Freedam & Responsibility
- どの開発者もNetflixのシステムを買わせるほどのアクセス権がある
- そこでSREの作るツールが重要になる
プロダクトを作っている感覚でSREはツールを作っていく
SRE should be a Enabler , SRE should not be a Servant
SREcon16の内容とか追っていなかったのでそこでの話などとても為になった
「マイクロにしすぎた結果がこれだよ！」by 榎本さん@mosa_siru (株式会社Gunosy)
www.slideshare.net
- AWSのsecurityグループとIAMを活用して経路自体に制限をかけてまとめた
- 全体構成が複雑が複雑になり人数いないと機能しない話
- 少人数のために各APIを管理する統合管理画面なるものを作成してその為だけのAPIを作った話
- ここまでくるとちょっと辛いし、microsericeは自立したチームでもあるので、組織構成が大切だなと
「Microservicesの実際と対策」by 大谷さん@shot6 (株式会社 ファーストリテイリング)
- swagger使ってる
- appはnodeで書くパターンが多い
- kong使ってる
- 体制が重要で。専任のスモールチームが必要
- そもそもマイクロサービスとは、すごく優秀な数名で最大限に活用するモデルがmicroservice
- 課題
- 運用面。既存の仕組みとの連携方法が難しい
- 共通的に解決しなくてはいけない課題をどう乗り越えるか？
- 答えがないのでどうやって横のつながりを増やすか
- サービス間の通信の可視化
- 依存関係の把握
- microserviceのテストの課題。dockerにすりゃ済む話ではない。10個以上docker立ち上げられないよローカルで
ウェルネスタイム (大好評、FiNCトレーナーによるストレッチタイム)
- タバタトレーニング
- しんどかった。勉強会で筋肉痛になったの初めて
「より良いAPIを作るために」by 相川さん@awakia (ウォンテッドリー株式会社)
- 最初からHerokuを使っていてその後、Dockerへ移行
- 2002年にamazonの社長だした司令の話
Kong使ってる事例を初めてみたけど、使ってる感じどうなのかなぁ？って思ってる。ざっくり聞きたいな
