- Cookpadにおけサービスメッシュ、gRPC、ECSの導入事例を紹介してもらいました。
- gRPCやEnvoy等気になっているサービスの話を聞くことができて参考になりました。
- 講演だけでなくQAセッションもあり、採用する技術に対する深い話も聞くことができてとてもよかったです。
| タイトル | 発表者 |
|---|---|
| クックパッドでのサービスメッシュについて | 小野大器 |
| gRPC in Cookpad | 岩間雄太 |
| Amazon ECS の安定運用 | 鈴木康平 |
クックパッドでのサービスメッシュについて
- 小野大器さん(Cookpad)
背景
- 開発者200+
- サービス100+
- 色んな開発チームとSREチーム
- 運用をSREチームから各チームへ移していきたい
課題
- 昔は大きなモノリシック
- 今は100近いアプリが相互に連携通信している
- マイクロサービス内でインシデント起きた時の特定が大変
- キャパシティプランニングも難しい
- 何が起きているか見えるようにしたい
解決策
- Expeditor
- Hystrixのruby版
- aws-xray
- 分散トレーシング
- ruby以外も各々作って改善を続けていかないといけない
- ネットワークプロキシを挟んでそこでやらせればいいのではないか
- サービスメッシュ
- 2017年ころから
導入と運用
- 2017年はじめに計画
- 2017年終わりにMVP作った
- 2018年から利用
Envoy
- 当時使えるもので一番良かった
- Istioはまだなかった
- AmazonECSを使っていた
- IstioはKubeが前提だから使えないかも
ゴール
- 各アプリで管理するのではなく中央で制御したい
- メトリクスはPrometheus
- 運用コストを抑えたい
運用
結果
- 一時的なエラー率上昇がタイムアウトリトライの設定で回避できるようになった
- SREチームの負荷が下がった
- 設定が中央に集まったのでレビューしやすくなった
- Observability
- 情報が可視化されるようになった
QA
- 冪等性をどう担保している
- GET/PUTは自動でリトライ
- POSTとgRPCはリトライできると分かったるものはリトライ
- デフォルトはリトライオフ
- Istio使わない?
- 今の構成で安定してるから今はこのまま
- マイクロサービスを導入するタイミングは?
- 組織が大きくなってきてコミュニケーションコストが大きくなってきたとき
- 明らかペイするのは2000人とかの規模
gRPC in Cookpad
- 岩間雄太さん(Cookpad)
これまでのCookpadのサービス感通信
CookpadでのgRPC
gRPC
- IDLとしてProtocol Buffersが使える
- Protocol Bbufferでクライアント/サーバのコード生成
- 多言語対応
- HTTP2上で動作
- Interceptorでログ、認証、エラー処理など
gRPCの運用
サービス定義(ProtocolBuffer)の管理
メトリクス
- Envoyコンテナでメトリクス取る
- Prometheusに入れてGrafanaで見る
rubyでgRPC
- grpc gem
- grpc-tool gemでクライアント/サーバのコード生成
- 公式のgRPC実装を使用してる
- フレームワークは使ってない
今後
- Envoyの機能を使ったかなりあリリース
- 自作gRPCライブラリへの移行
- grpc-gatewayの導入
QA
- gRPCをRESTで叩くことはしてない
- gRPC使う時はクライアント/サーバどちらもgRPCでやってる
Amazon ECS の安定運用
- 鈴木康平さん(Cookpad)
前提
- ほとんどのアプリがECSで動いてる
- hakoを使ってデプロイやバッチ起動
- ECSインスタンス 40
- ECSサービス 500
- 1日あたりのRun Task 80000
コンテナインスタンスの管理
- オンデマンドインスタンスはAutoScalingGroup
- スポットインスタンスはSpotFleet
- オンデマンド:スポット=1:4
- Fargate
- 一部使ってるけど基本自前管理
- 自前のほうが安いから
- 起動が遅いし起動時間が安定しないから
- 使うケース
- ECSクラスタのオートスケールするジョブ
- 特別大きいCPUリソースを使うジョブ
- 一部使ってるけど基本自前管理
オンデマンドインスタンス
- 自前でオートスケール
- AutoScalingGroup
- desired capacityをいじってECSクラスタの増減
スポットインスタンス
- オートスケールは自前
- SpotFleet
- target capacityをいじってECSクラスタの増減
オートスケーリング
- capacityをいじってECSクラスタの増減
スケールアウト
- CloudWatchの値をチェックして閾値を超えたらスケールアウト
- 各サービスの値をチェックしてスケールアウト
- hako oneshotがリソース不足で失敗したときにSQSで通知を受け取ってスケールアウト
スケールイン
ログ
- fluentd経由でS3に保存
- Athenaで簡易検索できるようにしてる
CloudWatch Logs
- 量が多すぎてピークタイムではリアルタイムにに入りきらない
- スケーラブルで安価なS3を使うことに
ログ配送
- 各コンテナからfluentdの集約ノードへ転送
- 集約ノードには大量のログが来ることになる
- 集約ノードのfluentdが1分毎にログをS3へ
ログ検索
- Athenaで検索できるようにGlueでカタログを日時更新
モニタリング
- CloudWatchにサービス単位のメトリクスはある
- タスク単位やコンテナ単位はない
- アプリ開発者はアプリコンテナのメトリクスだけ見たい
- cAdvisorでメトリクスを取得しPrometheus送りGrafanaで可視化
QA
- なぜECS?なぜkubeでない?EKSは?
- 運用する人が多くないからできるだけマネージドがいい
- EKSがECSくらい使いやすくなったら使うかも
- 今はECSほどマネージドではない
- 今すぐ移行するというほどではない
