はぜにっき

日記です。（毎日更新ではない）

「Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状」に参加しました #cookpad_tech_kitchen

Enginnering

cookpad.connpass.com

Cookpad Tech Kitchen に ブログ枠 で参加してきました。課題となるレポートエントリです。

目次が長い＞＜

場所: クックパッド株式会社

恵比寿ガーデンプライスタワーに潜入するのは2回目。
この時期はイルミネーションで輝いていて、独り身にはつらい。

f:id:hazeblog:20181128235724j:plain
ビル前
（移動しながら撮ったからぶれまくっている）

オフィスはとても綺麗で、入った瞬間にめちゃくちゃ広いキッチンがある。羨ましい

info.cookpad.com

概要

クックパッドオフィスのキッチンで、開発について知見や学びを共有する勉強会「Cookpad Tech Kitchen」。第20回は技術部開発基盤グループから3名が登壇し、クックパッドにおけるマイクロサービスプラットフォームの現状についてお話したいと思います。

タイトル通り、マイクロサービスの運用に関するお話を3つ聞く会でした。

以下はその内容、およびそのメモ。と、補足。
一応参加してない人にとっても（前提知識があれば）理解できるように書いたつもり。

聞きながら買いたメモを書き直したり、わからなかった用語を調べてたら遅くなりました :bow:

＠クッ社の方々
間違っている表現、用語、説明があったら教えてください。修正します

挨拶/会の説明

@hogelog さん

Cookpadの技術部の説明

  1. 技術部？
    -> サービス全体、横断的な技術課題を取り組む部署

技術部の構成

  • モバイル基盤グループ
  • ユーザ決済基盤グループ
  • 品質向上グループ
  • 開発基盤グループ
    • お台場チーム （※ cookpad_all というでかいRail Applicationをどうにかするチーム）
    • プラットフォームチーム （マイクロサービス技術基盤の開発、および運営を担当）

サービスメッシュの構築と運用

発表者: @taiki45 さん

speakerdeck.com

Agenda

  • 背景の説明
  • クックパッドにおける課題
  • 導入
  • どんな良いことがあったか？
  • 次の課題

Cookpadの組織について

料理に関する様々なサービスを作っている会社です。
プロダクトは レシピ共有サービス（ cookpad.com ）がメイン

組織規模: サービス開発者は200+ , サービス数は100+
サービスチーム（サービス毎に存在） + SREチーム

使用技術はRailsがメイン。たまに他言語。

SREチーム（おそらく技術部）の目標

=> 現在中央集権的に行なっているサービス運用を、サービス毎に自律的にできるような仕組みを作ること。

もともとあった課題

  • 歴史を踏まえた運用の課題

立ち上げ当初はモノリシックな1つのRails Applicationを運営すればよかったが、今は沢山のアプリケーションがある。

「1つのアプリケーションが死んだら複数のサービスが落ちてしまう」
「サービスが増えて連携すればするほど障害がおきた際の根本原因の調査が難しくなったり、障害の対象範囲の把握が難しくなる」

といった課題が出てきて、運用方法をちゃんと考えよう、という流れになった模様

ソリューション

ライブラリとかマネージドサービスで楽をしたい！！！

Expeditor

github.com

マイクロサービス運営において、障害が起きた際に影響を小さくすることができるやつ、との説明がありました。
聞いたことがなかったので調べたら、クックパッドの開発者ブログが出てきました。
というかこのライブラリ自体、クックパッドのOSSだった。

techlife.cookpad.com

クックパッドの開発者ブログ曰く

リクエストを並行処理したり、よしなにリトライしたり、あるサービスで一定以上のエラーが発生したら、一定期間そのサービスへのリクエストを停止する。

もの。

AWS X-ray

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

EnvoyのAPI

Service Discovery Service API というものがEnvoyに生えていて、それを叩いて設定を変更したり諸々を適用する。
lify/discovery という参考実装が存在したが、要件が合致しなかったらしく cookpad/sds を自作した。らしい。

github.com

正直なところここら辺からよくわからなくなりました

Prometheusの画面紹介

障害が起きたときにどうなるか？

-> retry overflow counter などの値が異常値を示すようになる

何がよかったか？

一時的なエラーレートの上昇などの対応が、リトライやタイムアウトの設定によりだいたいなんとかなるようになった

それにより、エラーが多少起こったりしたとしても問題のない範囲でリトライを実施したりといった形で自動対処ができるようになった。
=> SRE等の運用コストが減った

configの中央管理化によるメリット

各サービス毎に各々で管理されていた設定が集まることで、適切な設定を行いやすくなった。
サービスレベルや、ヘルスステータスの一覧表示、状況の監視がやりやすく、わかりやすくなった。

これからのミッション

  • EnvoyのAPI（xDS）のバージョンアップなどを行なっていく予定とのこと

gRPC in Cookpad

発表者: @ganmacs さん

speakerdeck.com

2017卒とのこと

もくじ

  • これまでのサービス間連携
  • gRPC運用
  • rubyでのgRPC

これまでのCookpad

前からマイクロサービスは推進していた。
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を使っている

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

github.com

gRPCのつらみ（CPU使いきれない toka Graceful Shutdownがなかったり toka 諸々）を解消するために作っているgem
grpc gemが良い感じになったら戻れるように互換性を気にして作っている

移行中らしいです

今後

Amazon ECS の安定運用

発表者: 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

Kubernetes, EKS採用しないんですか

  • オートスケーリングツールを運用できるほどの人員の確保は難しい
  • ECSはマネージドなので良い
  • EKSはECSより現状使いづらいのでなし

OSSの運用しんどくないですか

  • そこまで
  • 英語でのコミュニケーションがつらい
  • 社内事情と強制的に区切らなければならなくなるため、分離ができて良い

ECSクラスタの分け方ってどんな単位

  • 用途＋セキュリティグループ
  • 具体的には、Web App用のクラスタ、バッチジョブのみ起動するクラスタ　など
  • オートスケーリンググループなどの設定がやりやすい、セキュリティグループを全て同一にしたくない

共通

マイクロサービス化の始めるタイミング

  • 規模が大きくなってきたら
  • コミュニケーションコスト＞マイクロサービス化のコスト になったらやる
  • 人数でいうと150+が目安？

質問2つぐらい聞き取れなくて抜けてます

中央部分の耐障害性

（ありがとうございます）

懇親会

キッチンで作りたてっぽい色々を食べました。おいしかったです

懇親会中にスタッフの自己紹介タイムが入ってたけど全然聞けてなくて残念

感想とか

100+ 規模だからこその取り組みという感じで、とても面白い事例を知ることができて良かった。
エコシステムや既存のツールをどう使って課題を解決していくかといった話に対して、自作ツールをガンガン作っていけるのはかなり強みな気がする。
とはいえやりすぎるとそれはそれでつらいので、OSS化したりするのは良いと思った。

Container, AWSのサービス群に詳しくなくて、その場で調べながら聞いていた。多分他の人もだいたいそうなんじゃないかと思う

実際に各々の環境で使っていくかはさておき、名前が出てきたツールやサービスは概要だけでもさらっておくと、たまに役に立つ気がするのでおすすめ。

要望、というか自分が気になったのは、今回はプラットフォームを作る側の話だったけど、 それを使ってサービスを作る開発者側の意見。
これによってどれぐらい楽になったか？とか、アプリケーション側でハマったところ、とか、気になる。

aws.amazon.com

ところで、AWS App MeshがEnvoyを中で使っているとのこと。共通点とか違う点が少し気になる。
まあ、東京リージョンには暫くこなさそうだけど。。。

Cookpad Teck Kitchenは初めて参加しましたがとても楽しかったです。また行きたい。
運営の方々、懇親会で話してくださった方々ありがとうございました！