Cookpad Tech Kitchen に ブログ枠 で参加してきました。課題となるレポートエントリです。
- 場所: クックパッド株式会社
- 概要
- 挨拶/会の説明
- サービスメッシュの構築と運用
- Cookpadの組織について
- もともとあった課題
- ソリューション
- サービスメッシュの検討と概要
- Envoyについて
- サービスメッシュ、Envoy採用における目的と目標
- 仕組み
- Prometheusの画面紹介
- 何がよかったか？
- これからのミッション
- gRPC in Cookpad
- これまでのCookpad
- なんでgRPCを導入するのか
- gRPCについて
- 動作環境
- Protocol Buffersの管理
- メトリクスを取る
- Ruby / Rails でのgRPC実現
- griffin
- 今後
- Amazon ECS の安定運用
- 環境
- コンテナインスタンスの管理
- ログ
- モニタリング
- 今後
- QAディスカッション
- 感想とか
目次が長い＞＜
場所: クックパッド株式会社
I'm at クックパッド株式会社 in 渋谷区 https://t.co/rz0B34kPHI
— はぜ (@haze_it_ac) 2018年11月28日
恵比寿ガーデンプライスタワーに潜入するのは2回目。
この時期はイルミネーションで輝いていて、独り身にはつらい。
オフィスはとても綺麗で、入った瞬間にめちゃくちゃ広いキッチンがある。羨ましい
概要
クックパッドオフィスのキッチンで、開発について知見や学びを共有する勉強会「Cookpad Tech Kitchen」。第20回は技術部開発基盤グループから3名が登壇し、クックパッドにおけるマイクロサービスプラットフォームの現状についてお話したいと思います。
タイトル通り、マイクロサービスの運用に関するお話を3つ聞く会でした。
以下はその内容、およびそのメモ。と、補足。
一応参加してない人にとっても（前提知識があれば）理解できるように書いたつもり。
聞きながら買いたメモを書き直したり、わからなかった用語を調べてたら遅くなりました :bow:
＠クッ社の方々
間違っている表現、用語、説明があったら教えてください。修正します
挨拶/会の説明
@hogelog さん
Cookpadの技術部の説明
- 技術部？
-> サービス全体、横断的な技術課題を取り組む部署
技術部の構成
- モバイル基盤グループ
- ユーザ決済基盤グループ
- 品質向上グループ
- 開発基盤グループ
- お台場チーム （※
cookpad_allというでかいRail Applicationをどうにかするチーム） - プラットフォームチーム （マイクロサービス技術基盤の開発、および運営を担当）
- お台場チーム （※
サービスメッシュの構築と運用
発表者: @taiki45 さん
Agenda
- 背景の説明
- クックパッドにおける課題
- 導入
- どんな良いことがあったか？
- 次の課題
Cookpadの組織について
料理に関する様々なサービスを作っている会社です。
プロダクトは レシピ共有サービス（ cookpad.com ）がメイン
組織規模: サービス開発者は200+ , サービス数は100+
サービスチーム（サービス毎に存在） + SREチーム
使用技術はRailsがメイン。たまに他言語。
SREチーム（おそらく技術部）の目標
=> 現在中央集権的に行なっているサービス運用を、サービス毎に自律的にできるような仕組みを作ること。
もともとあった課題
- 歴史を踏まえた運用の課題
立ち上げ当初はモノリシックな1つのRails Applicationを運営すればよかったが、今は沢山のアプリケーションがある。
「1つのアプリケーションが死んだら複数のサービスが落ちてしまう」
「サービスが増えて連携すればするほど障害がおきた際の根本原因の調査が難しくなったり、障害の対象範囲の把握が難しくなる」
といった課題が出てきて、運用方法をちゃんと考えよう、という流れになった模様
ソリューション
ライブラリとかマネージドサービスで楽をしたい！！！
Expeditor
マイクロサービス運営において、障害が起きた際に影響を小さくすることができるやつ、との説明がありました。
聞いたことがなかったので調べたら、クックパッドの開発者ブログが出てきました。
というかこのライブラリ自体、クックパッドのOSSだった。
クックパッドの開発者ブログ曰く
リクエストを並行処理したり、よしなにリトライしたり、あるサービスで一定以上のエラーが発生したら、一定期間そのサービスへのリクエストを停止する。
もの。
AWS X-ray
AWS X-Ray (製品や分散アプリケーションの分析とデバッグ) | AWS
いわゆるDistributed Tracing, 分散トレーシングを提供するAWSのサービス。
サービスマップを良い感じにシュッと作れる。
ただ、これらは Ruby (on Rails) プロダクトであれば便利なんだけど、それ以外の言語/技術だと使えない。特にExpeditor。gemだし。
x-ray はAWSが頑張ってくれているから割と対象多いけど
サービスメッシュの検討と概要
言語ごとの対応とかは置いといて、「ネットワークプロキシを間に挟んで、それにアクセスをコントロールさせる」という方針が良いのでは、という話に。
その手法を取ることで、アプリケーションがどんな作りになっていても関係なく、ネットワークレベルでの制御が可能になる。
サービスメッシュ
SRECON America 2017での発表でSREチームが言葉を知ったことがきっかけらしい。
どんなもの？
-> 今までライブラリレイヤでリトライやサーキットブレイキングをしていたものを、外の別のプロキシに任せる
-> そのネットワークプロキシを、中央の別のもので管理する
中央管理にすることで、運営チームであるSREが管理をしやすく、分散していないため監視が行いやすく秩序を保ちやすい。
Envoyについて
上記で説明した「ネットワークプロキシ」に該当する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
EnvoyのAPI
Service Discovery Service API というものがEnvoyに生えていて、それを叩いて設定を変更したり諸々を適用する。
lify/discovery という参考実装が存在したが、要件が合致しなかったらしく cookpad/sds を自作した。らしい。
正直なところここら辺からよくわからなくなりました
Prometheusの画面紹介
障害が起きたときにどうなるか？
-> retry overflow counter などの値が異常値を示すようになる
何がよかったか？
一時的なエラーレートの上昇などの対応が、リトライやタイムアウトの設定によりだいたいなんとかなるようになった
それにより、エラーが多少起こったりしたとしても問題のない範囲でリトライを実施したりといった形で自動対処ができるようになった。
=> SRE等の運用コストが減った
configの中央管理化によるメリット
各サービス毎に各々で管理されていた設定が集まることで、適切な設定を行いやすくなった。
サービスレベルや、ヘルスステータスの一覧表示、状況の監視がやりやすく、わかりやすくなった。
これからのミッション
- EnvoyのAPI（xDS）のバージョンアップなどを行なっていく予定とのこと
gRPC in Cookpad
発表者: @ganmacs さん
2017卒とのこと
もくじ
- これまでのサービス間連携
- gRPC運用
- rubyでのgRPC
これまでのCookpad
前からマイクロサービスは推進していた。
Garage, GarageClientでAPIを共通化してたり、Autodocでドキュメントを自動生成したりしてきた。
（Cookpadほんと色々gem作ってるな）
なんでgRPCを導入するのか
gRPCについて
Protocol Buffersでの定義の紹介
シンプル
動作環境
- hakoっていうツールを使っているらしい（Dockerのデプロイをするやつ？）
- cookpad/sds + Envoy でClient Side Loadbalancing
slow startについて
※Slow Startって？
-> サーバを立ち上げた直後はリクエストの送信量を少なめにして、安定する（と仮定）に従って、少しずつ送信を増やしていくサービスイン時のやり方。
富士通のこの記事がわかりやすかった
負荷分散入門(ロードバランサ入門) 第8回 連続サービス機能 : Fujitsu Japan
サービスひとつに対し、 app コンテナ、 front-envoy コンテナ、 envoy コンテナ、registrator コンテナが立ち上がる。
動きは言葉よりスライドを見た方がわかりやすそう（12ページ〜）
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を使っている
Ruby / Rails でのgRPC実現
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
gRPCのつらみ（CPU使いきれない toka Graceful Shutdownがなかったり toka 諸々）を解消するために作っているgem
grpc gemが良い感じになったら戻れるように互換性を気にして作っている
移行中らしいです
今後
Amazon ECS の安定運用
発表者: Kohei Suzuki さん
Twitterアカウントわからんかった(´･_･`)
もくじ
- コンテナインスタンスの管理
- ログ
- モニタリング
環境
ほぼ全てのアプリケーションが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
モニタリング
アプリケーションコンテナのモニタリング
cAdvisor, Prometheus, Grafanaで実現
今後
- ECSにシークレットな環境変数を設定できる機能がきたので導入したい: AWS Launches Secrets Support for Amazon Elastic Container Service
- AutoScalling Groupでスポットインスタンスの管理: New – EC2 Auto Scaling Groups With Multiple Instance Types & Purchase Options | AWS News Blog
QAディスカッション
サービスメッシュ
retryの冪等性担保ってどうやってますか
- getとheadはそのままでOK
- postはパス毎に設定をしていて、「このパスはリトライ化」みたいにしてたり
- デフォルトはオフ
istio検討してますか
- 現状で問題ないと思うので。入れ替えて導入するよりは他のところにリソースを回したい
gRPC
git submoduleつらくないですか
- 特につらくない
grpc-webの導入って検討してますか
- Envoyに便利な機能があって、フロントからgRPCで投げられてもすぐ対応できる？らしい
インタフェース設計の共通化とか
- 基本的にインタフェースはこちらは関与せず、アプリケーション開発者に任せている
ECS
Kubernetes, EKS採用しないんですか
- オートスケーリングツールを運用できるほどの人員の確保は難しい
- ECSはマネージドなので良い
- EKSはECSより現状使いづらいのでなし
OSSの運用しんどくないですか
- そこまで
- 英語でのコミュニケーションがつらい
- 社内事情と強制的に区切らなければならなくなるため、分離ができて良い
ECSクラスタの分け方ってどんな単位
- 用途＋セキュリティグループ
- 具体的には、Web App用のクラスタ、バッチジョブのみ起動するクラスタ など
- オートスケーリンググループなどの設定がやりやすい、セキュリティグループを全て同一にしたくない
共通
マイクロサービス化の始めるタイミング
- 規模が大きくなってきたら
コミュニケーションコスト＞マイクロサービス化のコストになったらやる- 人数でいうと150+が目安？
質問2つぐらい聞き取れなくて抜けてます
中央部分の耐障害性
Envoy は各サービスインスタンスにたくさんいて(side-car container)、中央管理している Envoy のための API サーバーは冗長化している、という状況ですね
— Taiki Ono (@taiki45) November 28, 2018
（ありがとうございます）
懇親会
キッチンで作りたてっぽい色々を食べました。おいしかったです
懇親会中にスタッフの自己紹介タイムが入ってたけど全然聞けてなくて残念
感想とか
100+ 規模だからこその取り組みという感じで、とても面白い事例を知ることができて良かった。
エコシステムや既存のツールをどう使って課題を解決していくかといった話に対して、自作ツールをガンガン作っていけるのはかなり強みな気がする。
とはいえやりすぎるとそれはそれでつらいので、OSS化したりするのは良いと思った。
Container, AWSのサービス群に詳しくなくて、その場で調べながら聞いていた。多分他の人もだいたいそうなんじゃないかと思う
実際に各々の環境で使っていくかはさておき、名前が出てきたツールやサービスは概要だけでもさらっておくと、たまに役に立つ気がするのでおすすめ。
要望、というか自分が気になったのは、今回はプラットフォームを作る側の話だったけど、 それを使ってサービスを作る開発者側の意見。
これによってどれぐらい楽になったか？とか、アプリケーション側でハマったところ、とか、気になる。
ところで、AWS App MeshがEnvoyを中で使っているとのこと。共通点とか違う点が少し気になる。
まあ、東京リージョンには暫くこなさそうだけど。。。
Cookpad Teck Kitchenは初めて参加しましたがとても楽しかったです。また行きたい。
運営の方々、懇親会で話してくださった方々ありがとうございました！