Microservices x SRE な話
株式会社FiNC主催の勉強会
SRE=Site Reliability Engineering
ウェルネスタイムあり
カレーあり（管理栄養士作）
What is FiNC
データ収集、分析、ソリューション、EC
健康系アプリ
食事習慣とか改善しましょう的なやつ
ダイエットとか
色んな分野に福利厚生的なことでサービス提供
FitBitと提携
MicroservicesとSRE
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チーム二人しかいないのでやってくれる人募集中。
マイクロにしすぎた結果がこれだよ！
ボンバーマンで留年2階下
DeNA→Gunosy
アプリ寄り
ニュースパスの構成
2016/6 KDDIと協業で提供
けっこうちゃんとリソースごとにスタック分けてる
それぞれをガチガチにセキュリティ固めてる
なぜこんなことしたか？
前のプロジェクトでディストピア
カオス状態
コンポーネントは分かれてたのにみんな同じDB使ってるから意味なかった
OpsWorksのおかげ
作った結果
すごいことになった
やり過ぎた巻
4ヶ月で45コのGitHubRepository
30のスタック
マイクロサービスのデメリット
全体構成が複雑
巧み的な人が少なくなってしまう
大きめの機能をアーキテクトが少ない
開発が遅い
障害時に調査範囲が広い
ボトルネックの把握が難しい。
オーバーヘッドがネックになったりする
ピタゴラスイッチ
リソース配分、余ったリソースを融通できないから無駄が多い
共通部分がしんどい
共通部分に手を入れるだけで全部に反映するのがツラい
内部APIのIF変更ツラい
3段階デプロイが必要
少しミスるだけで障害になる
モノリシックでDBがネックになるのがレイヤー変わっただけ？
統合管理画面がヤバイ
管理画面のためのAPI作成？
みんなどうしてる？
djangoのREST Framework使ってやった
ロジック書かずにデータメンテできるようにした
失敗だったか？
うっすらこうなることは予想できた
とりあえずやれる例を作りたかった
今のところしんどいけど手綱は握れてる感
まとめ
マイクロサービスは組織論
少人数でやってもしょうがない。
スピード重視の場合はまずはモノリス
銀の弾丸はない
Microservicesの実際と対策
ファーストリテイリング
半スタートアップ、半エンタープライズ
コアなエンタープライズなところをマイクロサービスで作り替えてる
色々けっこうがんばらなきゃいけないことがある
大きく分けると
ビジネスロジック
全部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って初めて知った
- マイクロサービスの境界はめっちゃ考える
- マイクロサービスのフレームワークはそこそこあるけどまだまだな感じ
懇親会
画像は懇親会の様子ですが、料理がめっちゃうまかったです。
タンドリーチキンうまかった。
ありがとうございました！！！
雑感
- SREってそういうことか。
- 自分は8割くらいSREだということがわかった
- マイクロサービスあるある
- やっぱ辛いよなあ
- 運用の所をまだ考えキレてないからまじめに考えよう
- GoでAPI作りたい
- Kong使おう
- 認証どうしてんのかな？
- フィールドクエリは実際には取ってるけどレスポンスに出さないのか、実際にも指定されたものしか取らないのかどっちなんだろ？
- 後者だとしたら実装はだいぶ複雑になるし個別実装になるから辛いだろうな…。
- 健康大事なので引っ越したらまた運動始める
- みんなに興味を持ってもらうにはどうしようか悩む。