cookpad.connpass.com
Cookpad Tech Kitchen に ブログ枠 で参加してきました。課題となるレポートエントリです。
目次が長い><
恵比寿ガーデンプライスタワーに潜入するのは2回目。
この時期はイルミネーションで輝いていて、独り身にはつらい。
ビル前
(移動しながら撮ったからぶれまくっている)
オフィスはとても綺麗で、入った瞬間にめちゃくちゃ広いキッチンがある。羨ましい
info.cookpad.com
概要
クックパッド オフィスのキッチンで、開発について知見や学びを共有する勉強会「Cookpad Tech Kitchen」。第20回は技術部開発基盤グループから3名が登壇し、クックパッド におけるマイクロサービスプラットフォームの現状についてお話したいと思います。
タイトル通り、マイクロサービスの運用に関するお話を3つ聞く会でした。
以下はその内容、およびそのメモ。と、補足。
一応参加してない人にとっても(前提知識があれば)理解できるように書いたつもり。
聞きながら買いたメモを書き直したり、わからなかった用語を調べてたら遅くなりました :bow:
@クッ社の方々
間違っている表現、用語、説明があったら教えてください。修正します
挨拶/会の説明
@hogelog さん
技術部?
-> サービス全体、横断的な技術課題を取り組む部署
技術部の構成
モバイル基盤グループ
ユーザ決済基盤グループ
品質向上グループ
開発基盤グループ
お台場チーム (※ cookpad_all
というでかいRail Applicationをどうにかするチーム)
プラットフォームチーム (マイクロサービス技術基盤の開発、および運営を担当)
サービスメッシュの構築と運用
発表者: @taiki45 さん
speakerdeck.com
Agenda
背景の説明
クックパッド における課題
導入
どんな良いことがあったか?
次の課題
料理に関する様々なサービスを作っている会社です。
プロダクトは レシピ共有サービス( cookpad .com )がメイン
組織規模: サービス開発者は200+ , サービス数は100+
サービスチーム(サービス毎に存在) + SREチーム
使用技術はRails がメイン。たまに他言語。
SREチーム(おそらく技術部)の目標
=> 現在中央集権的に行なっているサービス運用を、サービス毎に自律的にできるような仕組みを作ること。
もともとあった課題
立ち上げ当初はモノリシックな1つのRails Applicationを運営すればよかったが、今は沢山のアプリケーションがある。
「1つのアプリケーションが死んだら複数のサービスが落ちてしまう」
「サービスが増えて連携すればするほど障害がおきた際の根本原因の調査が難しくなったり、障害の対象範囲の把握が難しくなる」
といった課題が出てきて、運用方法をちゃんと考えよう、という流れになった模様
ソリューション
ライブラリとかマネージドサービスで楽をしたい!!!
Expeditor
github.com
マイクロサービス運営において、障害が起きた際に影響を小さくすることができるやつ、との説明がありました。
聞いたことがなかったので調べたら、クックパッド の開発者ブログが出てきました。
というかこのライブラリ自体、クックパッド のOSS だった。
techlife.cookpad.com
クックパッド の開発者ブログ曰く
リクエス トを並行処理したり、よしなにリトライしたり、あるサービスで一定以上のエラーが発生したら、一定期間そのサービスへのリクエス トを停止する。
もの。
AWS X-Ray (製品や分散アプリケーションの分析とデバッグ) | AWS
いわゆるDistributed Tracing, 分散トレーシングを提供するAWS のサービス。
サービスマップを良い感じにシュッと作れる。
ただ、これらは Ruby (on Rails ) プロダクトであれば便利なんだけど、それ以外の言語/技術だと使えない 。特にExpeditor。gemだし。
x-ray はAWS が頑張ってくれているから割と対象多いけど
サービスメッシュの検討と概要
言語ごとの対応とかは置いといて、「ネットワークプロキシを間に挟んで、それにアクセスをコントロール させる」という方針が良いのでは、という話に。
その手法を取ることで、アプリケーションがどんな作りになっていても関係なく、ネットワークレベルでの制御が可能になる。
サービスメッシュ
SRECON America 2017での発表でSREチームが言葉を知ったことがきっかけらしい。
どんなもの?
-> 今までライブラリレイヤでリトライやサーキットブレイキングをしていたものを、外の別のプロキシに任せる
-> そのネットワークプロキシを、中央の別のもので管理する
中央管理にすることで、運営チームであるSREが管理をしやすく、分散していないため監視が行いやすく秩序を保ちやすい。
Envoyについて
www.envoyproxy.io
上記で説明した「ネットワークプロキシ」に該当するOSS 。
当時(2017年前半)の段階では一番良いプロダクトだったので採用となった。
Istioという別のものがあったが、そちらはKubernetes 前提で作られているプロダクトなこともあり、ECSを使っているクックパッド では見送りとなったらしい。
サービスメッシュ、Envoy採用における目的と目標
Resiliencyの設定を一覧で見れるようにしたい
resiliencyの意味・使い方 - 英和辞典 Weblio辞書
Reciliencyという言葉がピンとこなかったのでぐぐった。 「弾性力」「回復力」といった言葉らしい。
話を聞く限り、リトライやタイムアウト に関する設定、リクエス トの飛ばし先、その他諸々のネットワークプロキシが管轄する設定を全サービス分一覧で見れるようにしたい、ということっぽい。
クックパッド では、(前半でもかいたけど)サービスを開発・運用する担当がサービス毎にあって、それらを横断的に見るためのチームが存在している。その横断チームのことを「中央」と呼んでいて、この後は説明が面倒なので "中央" と呼ぶ。
その中央で横断的にサービスを監視し、及びどういったプロトコル で通信をし合うかを管理・管轄できるようになることが今回の目的。
リクエス ト量、その他諸々の可視化をするためにPrometheusを採用している。
仕組み
Envoyに便利なAPI があるのでそれを使う。
各サービスのconfigファイル(アクセスポイント、リトライ秒数、タイムアウト の判断秒数など)はS3で保管する。それを元にプロキシの設定を行う。
JSON をやり取りするマイクロサービス: API サーバはELBを使ってロードバランシングしているため、EnvoyはELBへアクセスする。
gRPCをやり取りするサーバはロードバランサに対応していないため、サーバへ直接アクセスする形を取る。
configファイルの詳細
Route Config: path毎に設定を記述する。リトライ、タイムアウト 秒数など
Cluster Config: どこにリクエス トを飛ばすか、といった設定を記述する。先はだいたいELB
Service Discovery Service API というものがEnvoyに生えていて、それを叩いて設定を変更したり諸々を適用する。
lify/discovery
という参考実装が存在したが、要件が合致しなかったらしく cookpad/sds
を自作した。らしい。
github.com
正直なところここら辺からよくわからなくなりました
Prometheusの画面紹介
障害が起きたときにどうなるか?
-> retry overflow counter
などの値が異常値を示すようになる
何がよかったか?
一時的なエラーレートの上昇などの対応が、リトライやタイムアウト の設定によりだいたいなんとかなるようになった
それにより、エラーが多少起こったりしたとしても問題のない範囲でリトライを実施したりといった形で自動対処ができるようになった。
=> SRE等の運用コストが減った
configの中央管理化によるメリット
各サービス毎に各々で管理されていた設定が集まることで、適切な設定を行いやすくなった。
サービスレベルや、ヘルスステータスの一覧表示、状況の監視がやりやすく、わかりやすくなった。
これからのミッション
EnvoyのAPI (xDS)のバージョンアップなどを行なっていく予定とのこと
発表者: @ganmacs さん
speakerdeck.com
2017卒とのこと
もくじ
これまでのサービス間連携
gRPC運用
ruby でのgRPC
前からマイクロサービスは推進していた。
Garage, GarageClientでAPI を共通化 してたり、Autodocでドキュメントを自動生成したりしてきた。
github.com
github.com
github.com
(Cookpad ほんと色々gem作ってるな)
なんでgRPCを導入するのか
IDLとスキーマ が欲しい
IDL: Inrerface Description Language
RESTだとマッピング つらい
他言語も積極的に使えるようにしたい
gRPCについて
grpc.io
Protocol Buffersでの定義の紹介
grpc.io
シンプル
動作環境
hakoっていうツールを使っているらしい(Dockerのデプロイをするやつ?)
github.com
cookpad /sds + Envoy でClient Side Loadbalancing
slow startについて
※Slow Startって?
-> サーバを立ち上げた直後はリクエス トの送信量を少なめにして、安定する(と仮定)に従って、少しずつ送信を増やしていくサービスイン時のやり方。
富士通 のこの記事がわかりやすかった
負荷分散入門(ロードバランサ入門) 第8回 連続サービス機能 : Fujitsu Japan
サービスひとつに対し、 app
コンテナ、 front-envoy
コンテナ、 envoy
コンテナ、registrator
コンテナが立ち上がる。
動きは言葉よりスライドを見た方がわかりやすそう(12ページ〜)
speakerdeck.com
registrator
がappにヘルスチェックしてくれるのが良い
サービス間通信の動き
Service1: App -> Service1: envoy -> Service2: ftont-envoy -> Service2: App
リクエス ト送信をenvoyが、受信をfront-envoyが担当している
Protocol Buffersの管理
Protocol Buffers定義用のリポジトリ があってサービスごとにディレクト リがわかれてる
repos/
├── service_a
├── service_b
└── service_c
lintがあったり、ドキュメントを自動生成するツールが用意されていたりと色々楽そう
メトリクスを取る
Envoy Status っていう機能がEnvoyにもともとあって、それを利用
アクセスログ はサービス開発者が1〜2行シュッと定義を書くだけで取ってこれるようになるらしい
Prometheus, Grafanaを使っている
grpc
っていうgemがある
grpc | RubyGems.org | your community gem host
grpc-tools
gemでサーバ/クライアントのコードを生成してくれる、あとは実装を書くだけでOK
grpc-tools | RubyGems.org | your community gem host
Interceptorや一部ライブラリは自作
その他諸々
rails runner使っているとのこと
rakeはなんかハマるらしい :thinking:
griffin
github.com
gRPCのつらみ(CPU使いきれない toka Graceful Shutdownがなかったり toka 諸々)を解消するために作っているgem
grpc gemが良い感じになったら戻れるように互換性を気にして作っている
移行中らしいです
今後
発表者: Kohei Suzuki さん
Twitter アカウントわからんかった(´・_・`)
speakerdeck.com
もくじ
環境
ほぼ全てのアプリケーションがECS上で稼働、一部Fargate。
(FargateにしているのはECSクラスタ 自体を操作するやつとか、でかいCPU/Memが必要なジョブ)
ECSクラスタ : 40
ECSサービス: 500
比率: オンデマンドインスタンス =1 / スポットインスタンス =4
オンデマンドインスタンス のオートスケール
AutoScaling GroupとECSクラスタ が1:1
AutoScalingの役割 -> desired capacityを上下すればクラスタ の増減ができるようにする / 障害時の自動復旧
Auto Scaling グループ - Amazon EC2 Auto Scaling (日本語)
Spot Fleet
役割 -> target capasityを上下するだけでクラスタ の増減ができるようにする / 障害時の自動復旧
EC2 Fleet – Manage Thousands of On-Demand and Spot Instances with One Request | AWS News Blog
サービスアウトの話
interruption noticeが通知されてから2分以内にサービスアウトをこちらでやらないと強制的に殺される。
自前でELBのtarget groupから外したら止める + 突然一部タスクが死んでも大丈夫なようにちょっと余裕を持ったキャパシティのプランニングをする
スケールイン、スケールアウトの基準
共通: CloudWatchのCPU/Memory値
スケールアウト: 各サービスのdesired_count, running_count、バッチジョブがリソース不足で失敗したとき
ログ
コンテナのstdout, stderr
fluentd経由でAmazon S3 保存、Athenaで検索できるようにしている。
CloudWatch Logsはログが多すぎて使い物にならなさそうだったので使わなかった+高い とのこと
コンテナインスタンスのホストにfluentd -> fluentdの集約ノード -> S3
aws.amazon.com
モニタリング
アプリケーションコンテナのモニタリング
cAdvisor, Prometheus, Grafanaで実現
GitHub - google/cadvisor: Analyzes resource usage and performance characteristics of running containers.
今後
QAディスカッション
サービスメッシュ
retryの冪等性担保ってどうやってますか
getとheadはそのままでOK
postはパス毎に設定をしていて、「このパスはリトライ化」みたいにしてたり
istio検討してますか
現状で問題ないと思うので。入れ替えて導入するよりは他のところにリソースを回したい
istio.io
gRPC
git submoduleつらくないですか
grpc-webの導入って検討してますか
Envoyに便利な機能があって、フロントからgRPCで投げられてもすぐ対応できる?らしい
インタフェース設計の共通化 とか
基本的にインタフェースはこちらは関与せず、アプリケーション開発者に任せている
ECS
オートスケーリングツールを運用できるほどの人員の確保は難しい
ECSはマネージドなので良い
EKSはECSより現状使いづらいのでなし
OSS の運用しんどくないですか
そこまで
英語でのコミュニケーションがつらい
社内事情と強制的に区切らなければならなくなるため、分離ができて良い
ECSクラスタ の分け方ってどんな単位
用途+セキュリティグループ
具体的には、Web App用のクラスタ 、バッチジョブのみ起動するクラスタ など
オートスケーリンググループなどの設定がやりやすい、セキュリティグループを全て同一にしたくない
共通
マイクロサービス化の始めるタイミング
規模が大きくなってきたら
コミュニケーションコスト>マイクロサービス化のコスト
になったらやる
人数でいうと150+が目安?
質問2つぐらい聞き取れなくて抜けてます
中央部分の耐障害性
(ありがとうございます)
懇親会
キッチンで作りたてっぽい色々を食べました。おいしかったです
懇親会中にスタッフの自己紹介タイムが入ってたけど全然聞けてなくて残念
感想とか
100+ 規模だからこその取り組みという感じで、とても面白い事例を知ることができて良かった。
エコシステムや既存のツールをどう使って課題を解決していくかといった話に対して、自作ツールをガンガン作っていけるのはかなり強みな気がする。
とはいえやりすぎるとそれはそれでつらいので、OSS 化したりするのは良いと思った。
Container, AWS のサービス群に詳しくなくて、その場で調べながら聞いていた。多分他の人もだいたいそうなんじゃないかと思う
実際に各々の環境で使っていくかはさておき、名前が出てきたツールやサービスは概要だけでもさらっておくと、たまに役に立つ気がするのでおすすめ。
要望、というか自分が気になったのは、今回はプラットフォームを作る側の話だったけど、 それを使ってサービスを作る開発者側の意見。
これによってどれぐらい楽になったか?とか、アプリケーション側でハマったところ、とか、気になる。
aws.amazon.com
ところで、AWS App MeshがEnvoyを中で使っているとのこと。共通点とか違う点が少し気になる。
まあ、東京リージョンには暫くこなさそうだけど。。。
Cookpad Teck Kitchenは初めて参加しましたがとても楽しかったです。また行きたい。
運営の方々、懇親会で話してくださった方々ありがとうございました!