Microservices Meetup #2


Microservices x SRE な話

株式会社FiNC主催の勉強会

SRE=Site Reliability Engineering
ウェルネスタイムあり
カレーあり（管理栄養士作）

## What is FiNC

データ収集、分析、ソリューション、EC
健康系アプリ

食事習慣とか改善しましょう的なやつ
ダイエットとか
色んな分野に福利厚生的なことでサービス提供

FitBitと提携

# MicroservicesとSRE

@kenjiszk

AWS, Azure

## What is Microservices

まあ知っての通り。

コンウェイの法則

各マイクロサービスがあって、設計の切り方と同じように組織が分かれてる

## What is SRE

サイト信頼性エンジニアリング
従来のインフラ部署がSREを言い出してる

主にインフラ。
アプリケーションにも責任持つ。

新規で開発するもの以外は担保してる
SREのチームがマイクロサービスのチームとは別に独立して存在している。
サーバーの種類が多くて大変
開発陣がアグレッシブで大変
全体を管理する側からするとかなり大変。
マイクロサービスは分割したりとかで増えることがある。

SREのリソースがネックになりそう。

実際に増えてた。

Rails5がでて4は排除の空気
マイクロサービスが増えるとそれぞれやるの大変。

各マイクロサービスにSRE担当があればいいんじゃないか。

### 問題

そもそも全チームに張り付くほどSREの人間はいない。
共有した方がいいものはある。
デプロイとかCIとか…

### 対策

人的リソー-素
SREできる人材を育てる
開発チームに任せる。
インフラかんだことある人に委譲したり

共有
デプロイコンポーネントは一つのマイクロサービスとして提供する

## SREできる人を育てました

各チームに配置ではなく、各チームで捕まえてSREやらせた

インターンの場合
Railsつまらんとか言って調子こいてた
興味を引かせた
http://developer-blog.finc.co.jp/post/146345735002/fincでの機械学習の使われ方-数学からuiそしてインフラまで


新卒の場合
プロジェクト1つ任されて調子こいてた
Terraformで全台管理できるようにしてくれた

開発・SREの壁をどんどん取り払いたい

## 守るべきライン

開発者が見れてはいけない部分もある。
コード書いてる人が遺伝子情報見れたらまずい

新技術の導入
コスト管理
スケール

## 質問

各チームにSREがいると理想型？
理由は？
→切り分けのライン
オーケストレーションとか
全体見るチームはあってもおｋ

# マイクロサービスとSRECon SRECon 2016 Wrap Up

@takus
スマートニュース
SREチーム
OLAP druiid.io
Slack本書きました。

スマニュー自主渡航奨励制度
半期に1回くらいお金出してもらっていける

## SRE Conとは？
セッション色々ある。

マイクロサービスに関するセッションはない。

でも、当たり前。

マイクロサー-ビスに対するSREの関わり方

## Netflixの場合
190の国を5人のエンジニアで見てる
どこまで自由？
各サービスは開発チームに任せてる。
サービス壊されたりしないの？
SREが出してるツールがめっちゃ重要になる。
開発者は他のツールを用意したりしない。
SREが使いやすく事故の起きないツールを提供してる

Spinnaker
社内向けツールの開発もプロダクト開発のつもりで。
ロードマップとかもちゃんと作る。

## Uber
障害に現実感を持ってもらおう
信頼性を高めることにモチベーションが起きにくい
滅多に起きないことには時間を割けない
NetflixのChaos Engineeringみたいなもん。
定期的に障害を起こして現実感を持たす。
組織に良い習慣を自然に作る仕組み

## NewRelic
インシデントどう対処してるか
ボットにステータス更新を話しかける
タイムライン情報後から振り返るときに重要

## まとめ

SREは何かを可能にしていく人

SREがやってはいけない→
運用の細かい部分をやる
球拾いは50%以上やらない。
ちゃんと計測して働き方を考える
将来何かをよくするための時間とどっちが重要なのかを考える。
障害対応は率先してアシスト。

SREチーム二人しかいないのでやってくれる人募集中。

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

@mosa_siru

ボンバーマンで留年2階下
DeNA→Gunosy
アプリ寄り

## ニュースパスの構成

2016/6 KDDIと協業で提供
けっこうちゃんとリソースごとにスタック分けてる
それぞれをガチガチにセキュリティ固めてる

なぜこんなことしたか？

前のプロジェクトでディストピア
カオス状態

コンポーネントは分かれてたのにみんな同じDB使ってるから意味なかった
OpsWorksのおかげ

## 作った結果

すごいことになった
やり過ぎた巻
4ヶ月で45コのGitHubRepository
30のスタック

## マイクロサービスのデメリット

### 全体構成が複雑
巧み的な人が少なくなってしまう
大きめの機能をアーキテクトが少ない

### 開発が遅い

### 障害時に調査範囲が広い
ボトルネックの把握が難しい。

### オーバーヘッドがネックになったりする
ピタゴラスイッチ
リソース配分、余ったリソースを融通できないから無駄が多い

### 共通部分がしんどい
共通部分に手を入れるだけで全部に反映するのがツラい

### 内部APIのIF変更ツラい
3段階デプロイが必要
少しミスるだけで障害になる
モノリシックでDBがネックになるのがレイヤー変わっただけ？

### 統合管理画面がヤバイ
管理画面のためのAPI作成？
みんなどうしてる？
djangoのREST Framework使ってやった
ロジック書かずにデータメンテできるようにした

## 失敗だったか？

うっすらこうなることは予想できた
とりあえずやれる例を作りたかった
今のところしんどいけど手綱は握れてる感

## まとめ

マイクロサービスは組織論
少人数でやってもしょうがない。
スピード重視の場合はまずはモノリス
銀の弾丸はない

# Microservicesの実際と対策

@shot6

ファーストリテイリング
半スタートアップ、半エンタープライズ

コアなエンタープライズなところをマイクロサービスで作り替えてる
色々けっこうがんばらなきゃいけないことがある

大きく分けると

ビジネスロジック
全部Swagger
ファイルやりとりのAPI
Notification
イベント駆動

## 技術的な話

AWSをベースに作ってる
一部Azure
マルチクラウドしんどい
ほとんどオートスケール、デプロイはJenkins

APIはSwaggerで標準化
アプリはNodejs

Elasticseaarch使うことが増えてる
ELKスタック使ってる
Beamに置き換えたい

Mesosphere使ってる
Dockerコンテナ管理、API Gateway
今のところうまくいってる

API GatewayにKong入れてる

コミュニケーションはSlack使ってる

## チーム的な話

### マイクロサービス良い点

チームの人数が多いと効果がある
デプロイをパラでやるような感じだといい。
中の実装を好きに変えられるのは精神的な負担が軽い

### マイクロサービスは誰のモノ？

十分な複雑さがない限りペイしない

----------

## 体勢が非常に大事

専任のスモールチームが必要
黒帯的なチームがあって、みんなを育てていかないといけない。

## 変化

人数を追加したところで優秀な人の代わりには慣れない
技術力のある数名で最大限に活躍するモデル
これがマインドセット
クラウド徹底活用、自動化

## 課題

課題は運用面
自動化
既存の仕組みとの連携をどうするか
そこが重い

投資する側としては、モノリシックの方が安い
1回作るとあとで振り替えれない

マイクロサービスはドメインドリブン
共通的な解決する課題をどうするか

## 状況

誰かが答えを持っているわけではない
他の会社と情報交換してる
ベンダーに聞けるもんじゃない
USの会社と話す
エンタープライズ系が多い
辛抱強くやってて根付いてる

## 技術的な課題

サービス間の通信を可視化
一元的な可視化
トラフィックを見えるようにしないと増えてくると運用が破綻する
ドメイン単位でどう言う通信をするかを考えてる

依存関係の把握
トラッキング可能にする

テスト
コンポーネント感のテストはどうするか
コンテナにすればすむって話ではない
テストのしやすさを担保する方法が現時点で世の中にはほとんどない
取組中
できたら共有するよ

Wearex
6割くらいが英語
一緒にやってくれる人募集

# ウェルネスタイム

エンジニアのためのストレッチ
デスクワークが続くと胸の筋肉が固くなって猫背になるよ
生産性ダウン

120〜130くらいの心拍が一番燃焼する
HIIT
田端プロトコル

# よりよいAPIを作る

Wantedly
インフラリーダー

キレイなAPI速習会

SRE→インフラチーム
アーキテクチャは自由に言語を選びたい

もとからHerokuだったのでDockerでマイクロサービスやりやすかった
CoreOS
最近マイクロサービス化に力入れてる

## どうなったらマイクロサービス？
2002年にAmazonが出した社内に指令
後出しでRate Limitとかできてきた

APIで全部行う→マイクロサービス

## Backends for Frontends
シンプルなRestServerとビジネスロジックがはいったものは別にしてる

## キレイなAPIを角煮は
API通信が多いので大事

Heroku参考にした
FacebookのAPIが徐々に進化している

## 深いネストはしない。
1段＋その先くらい

## フィールドクエリ
データ通信量を減らすために

## バージョンはヘッダで管理
バージョン1から2に上げるはいつやれば良いのか分からん問題
一般的なバージョニングにしてる。
v1.0.0

ページングとかメタ情報はヘッダに入れる

## 言ってても社内で広まらないだろうな
ということでGoでジェネレータを作った

apig

# LT

- Netflixの[Falcor](https://github.com/Netflix/falcor)って初めて知った
- マイクロサービスの境界はめっちゃ考える
- マイクロサービスのフレームワークはそこそこあるけどまだまだな感じ

# 懇親会

![curry](https://dl.dropboxusercontent.com/u/3391731/images/microserv-curry.jpeg)

画像は懇親会の様子ですが、料理がめっちゃうまかったです。
タンドリーチキンうまかった。
ありがとうございました！！！

# 雑感

- SREってそういうことか。
	- 自分は8割くらいSREだということがわかった
- マイクロサービスあるある
	- やっぱ辛いよなあ
	- 運用の所をまだ考えキレてないからまじめに考えよう
- GoでAPI作りたい
- Kong使おう
- 認証どうしてんのかな？
- フィールドクエリは実際には取ってるけどレスポンスに出さないのか、実際にも指定されたものしか取らないのかどっちなんだろ？
	- 後者だとしたら実装はだいぶ複雑になるし個別実装になるから辛いだろうな…。
- 健康大事なので引っ越したらまた運動始める
- みんなに興味を持ってもらうにはどうしようか悩む。