少人数でも運用できるインフラ作り / Operating infrastructure with less effort

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 - Kohei Suzuki (@eagletmt) - 2014年に新卒で入社し技術部開発基盤グループに - cookpad.com の Rails バージョンアップとか - Jenkins を使った CI 環境作りとか - ECS を使ったアプリケーション実行基盤作りとか - 2019年から SRE グループに所属 - 引き続き ECS 関連の改善とか - ﬂuentd のバージョンを上げつつログ配送の改善とか - 古い VPC や Consul 等の社内でレガシーとなったコンポーネントの廃止とか

Slide 3

Slide 3 text

アウトライン - クックパッドでの開発体制やインフラの変遷 - セルフサービス化 - モニタリングの委譲 - マネージドサービス化 - SLI/SLO - アラーティング - まとめ

Slide 4

Slide 4 text

Slide 5

Slide 5 text

2014年頃の様子 - 多くの開発者がレシピサービス (cookpad.com) の開発をしていた - SRE (当時の名前はインフラ部) がレシピサービスのインフラを運用していた - Rails アプリを動かす EC2 インスタンス (Puppet) - MySQL や Redis を動かす EC2 インスタンス (Puppet) - IAM や Route 53 などの一部の AWS リソースは独自ツールでコード管理 - https://github.com/codenize-tools

Slide 6

Slide 6 text

2014年頃の様子

Slide 7

Slide 7 text

Microservices で DevOps だ!! - レシピサービス以外の新規事業が立ち上がったり、レシピサービスの一部の機能が独立したりした - 巨大なモノリシック Rails で動いていたレシピサービスをマイクロサービスに分割していく決断がされ、後のお台場プロジェクトで大きく進んだ - 参考: クックパッド基幹システムのmicroservices化戦略〜お台場プロジェクト1年半の軌跡〜 https://techlife.cookpad.com/entry/2018-odaiba-strategy

Slide 8

Slide 8 text

ECS・Terraform 時代 - インフラ面では ECS をベースにアプリケーション実行基盤を作っていくことにした - Hako というツールを開発し、Dockerﬁle と Hako の定義ファイルを書けば Route 53、ELB、 ECS が適切に設定されアプリケーションが動くようになっていった - AWS のマネージドサービスを積極的に活用するようになっていった - MySQL より Aurora MySQL、Memcached より ElastiCache Memcached、Redis で Pub/Sub するより SNS と SQS、etc. - これらの管理には Terraform を使うようになった

Slide 9

Slide 9 text

ECS・Terraform 時代

Slide 10

Slide 10 text

現在 - レシピサービスを構成するマイクロサービス群とクックパッドマートを筆頭に、様々なサービスが稼働している (開発環境やスタッフ向けのアプリも含む ) - ECS のサービス数: 561 - ECS のコンテナインスタンス: ピークタイムに 800 くらい - 同時に動いている ECS タスク数: ピークタイムに 2200 くらい - 現時点で5人の SRE グループでこれらのサービスの基盤を支えている - ここ数年で減ったものの、元々多くても8人くらいの規模だった

Slide 11

Slide 11 text

Slide 12

Slide 12 text

セルフサービス化 - 結論: たくさんのサービスを少人数で運用していくためには自動化とセルフサービス化しかない - 自動化し、依頼するのではなく pull request を出すようにしたり Web 上での操作で完結できるようにしたり - 適切に権限を渡して SRE の特権無しで行えることを増やす - SRE の主な役割を「運用・管理すること」から「運用・管理するためのしくみを作ること」に変えていった

Slide 13

Slide 13 text

オーナーシップ - マイクロサービス化を進める上で重要な概念 - マイクロサービス化の最大のメリットの1つがオーナーシップの明確化 - マイクロサービス化でアプリケーションコードのオーナーシップが明確になっていった - この流れに乗って、アプリケーションコードだけでなくサービスを構成するすべてのリソースのオーナーシップを事業部に渡していく

Slide 14

Slide 14 text

オーナーシップ

Slide 15

Slide 15 text

オーナーシップ

Slide 16

Slide 16 text

オーナーシップ - 最終的にはデータベース等のメンテナンスや障害時の対応等も事業部に委譲していきたい - 最初のステップとして、データベース等も含む 1つのサービス単位でメトリクスを閲覧できる状態を目指した

Slide 17

Slide 17 text

hako-console - Hako アプリ単位で色々な情報を見れるコンソールを開発した - すべてのアプリが同じ基盤で動いている状態になると、色々な前提を置けて自動化できる範囲が広がる - アプリの一覧が分かる - 各アプリに対応する ELB が分かり、レイテンシ等の基本的なメトリクスがどこにあるか分かる - 各アプリに対応するコンテナのメトリクスや Envoy のメトリクスも分かる

Slide 18

Slide 18 text

hako-console - 環境変数での設定を徹底する - 接続先などの設定値はハードコードせず環境変数で与える - 環境変数を見ることで利用しているものが分かる - DATABASE_URL からデータベースのインスタンスを特定 - SENTRY_DSN からエラートラッカーのプロジェクトを特定 - これらを自動化して hako-console として提供し、どんなアプリでも使える基本的なダッシュボードを自動生成している - 参考: Web アプリケーションを把握するためのコンソール https://techlife.cookpad.com/entry/2018/04/02/140846

Slide 19

Slide 19 text

hako-console

Slide 20

Slide 20 text

hako-console ログ連絡先リポジトリエラートラッカーダッシュボード実行中のコードオーナー

Slide 21

Slide 21 text

hako-console

Slide 22

Slide 22 text

hako-console RPS Latency CPU Memory Memory CPU CloudWatch Deploy CloudWatch Prometheus

Slide 23

Slide 23 text

hako-console - これにより SRE の専門知識がなくても、事業部のエンジニアが自分たちのサービスの状態を把握しやすくなった - 元々メトリクスはどこか (CloudWatch、Prometheus、etc.) にとられていたが、自分に関係するメトリクスの在り処が見えるようになった

Slide 24

Slide 24 text

マネージドサービス化 - メトリクスの閲覧は hako-console で解決したとして、次はミドルウェアの管理を委譲したい - SRE が EC2 上で運用していたミドルウェアをどんどん AWS のサービスに移行していった - MySQL は Aurora MySQL へ - Redis は用途に応じて SNS + SQS や DynamoDB や ElastiCache Redis へ

Slide 25

Slide 25 text

Terraform - Hako が管理しない AWS サービスは Terraform で管理していくことにした - 以前から codenize-tools (roadworker, miam, puculet, etc.) や Terraform を利用して Infrastructure as Code を実践していたが、セルフサービス化を進めていくには Terraform への一本化が適していると判断した - 参考: AWS リソース管理の Terraform 移行 https://techlife.cookpad.com/entry/2020/02/28/120000

Slide 26

Slide 26 text

codenize-tools の思想 AWS サービス毎にリソースを横に一元管理

Slide 27

Slide 27 text

アプリケーション単位で様々な AWS リソースを管理 Terraform の場合

Slide 28

Slide 28 text

Terraform の運用 - 1つのリポジトリに集約しつつも tfstate はプロジェクト (アプリケーション) 単位で分割するという構成にした - 1つのリポジトリに集約したのは一覧性のためと統一的な CI を適用するため - tfstate を分割したのは事業部にオーナーシップを持たせていくため - tfstate が巨大だと terraform plan が遅すぎるという実用的な面もあるが ……

Slide 29

Slide 29 text

Terraform の運用 . ├── service-a │ ├── .terraform.lock.hcl │ ├── aws.tf │ ├── backend.tf │ └── rds.tf └── service-b ├── .terraform.lock.hcl ├── acm.tf ├── aws.tf ├── backend.tf ├── elb.tf ├── s3.tf ├── sg.tf └── vpc.tf

Slide 30

Slide 30 text

Terraform の運用 - セルフサービス化が進んでいるいくつかのチームでは SRE の介入無しで Terraform 経由でリソースを操作できるようにしている - pull-request は誰でも出せるものの、レビューや実際の操作に SRE が入るようにしているチームがまだまだ多い

Slide 31

Slide 31 text

SLI/SLO - 監視やミドルウェアも事業部に委譲していきたいが、全社的な SRE としてどのサービスも一定の可用性は維持してほしい - 開発が活発で規模が大きくなりつつあるクックパッドマートから SLI/SLO の取り組みを始めた - エラーレートやレイテンシを SLI として SLO を定め、SRE は定期的にチェックしつつ違反の恐れがあればマートのチームに働きかける - マートのチーム内でも定期的にチェックして違反しそうであれば改善に時間を割いてもらう - https://speakerdeck.com/hfm/slo

Slide 32

Slide 32 text

クックパッドマートでの SLI/SLO リクエスト成功率 p90 レイテンシ

Slide 33

Slide 33 text

セルフサービス化まとめ - マイクロサービス化で明確になっていったサービスのオーナーシップに沿うように、ミドルウェア等のオーナーシップも事業部へと委譲していく方針にした - いくつかの段階に分けて進めているところ - サービス単位のモニタリングのために hako-console を作った - マネージドサービスへと移行し、サービス単位で Terraform の tfstate を分けることでミドルウェアの管理もサービス単位にした - 一部のチームでは SRE が関与することなく Terraform 経由で自由にリソースを変更できるようにした - クックパッドマートでは SLI/SLO の運用を始めた

Slide 34

Slide 34 text

Slide 35

Slide 35 text

オンコール対応 - 少人数でやっていくにあたって一番大変なもの - PagerDuty を使ってオンコール対応をしているが、最初はすべてのアラートが high urgency で飛んできて大変だった - そこでアラーティングの見直しを進めていった - アラートを分類して urgency を下げる - 不要なアラートを減らす - 重度の障害状態に対して別途アラートを設定する - つまりアラートに対してメリハリをつけていった

Slide 36

Slide 36 text

アラートの分類 - PagerDuty の機能として high urgency と low urgency の分類がある - 翌営業日の対応で十分なやつの urgency を low に下げた - ユーザ影響の無いジョブキューの監視とか - 開発用途のアプリケーションやストレージの監視とか

Slide 37

Slide 37 text

不要なアラートを減らす - 一時的に問題のある状態になってもすぐに回復できればアラートを発砲しないようにした - 「一瞬エラーレートが上がったけどすぐ回復した」のような場合、深夜に叩き起こされてもその場でやることがない - ECS 移行やマネージドサービス移行により、とくに工夫しなくても自動回復できるパターンが大きく増えた - 代わりに定期的にメトリクスをチェックして、気になったところを調査すれば十分とした - 発砲条件に期間を追加

Slide 38

Slide 38 text

不要なアラートを減らすこういうので起こされたくない。後から原因調査できれば十分。

Slide 39

Slide 39 text

不要なアラートを減らす - サービス間通信でのエラーレートは原則アラート対象とはしないようにした - マイクロサービス化された状態ではサービス間通信でのエラーはある程度仕方ない - Envoy のリトライや各サービスでの graceful degradation でカバーしていく - カバーしきれずユーザ影響が出てしまう場合は、エンドユーザと前面のサービスの間のエラーレートが上がるはず

Slide 40

Slide 40 text

不要なアラートを減らす backend-y のエラーレートが高くても frontend-a のエラーレートが低ければ問題ない

Slide 41

Slide 41 text

不要なアラートを減らす backend-x の影響で frontend-a のエラーレートが高まった場合はアラート

Slide 42

Slide 42 text

重度の障害状態への備え - アラートが多すぎるのは大変だが、不十分だとサービスの提供に支障が出る可能性が高まる - 最終防衛ラインとして、明らかに高いエラーレートが一定期間続いた場合は通常とは異なるエスカレーションポリシーを適用することにした - レシピサービス (Web、API) で高いエラーレートの状態が5分間続いたらプライマリとセカンダリに同時に通知 - 「滅多に発生しないが発生したら複数人での対応が必須」というラインを決めた

Slide 43

Slide 43 text

Slide 44

Slide 44 text

まとめ - たくさんのサービスを少人数で運用していくために自動化とセルフサービス化を中心にやってきた - SRE の主な役割を「運用・管理すること」から「運用・管理するためのしくみを作ること」へ - オーナーシップを意識しながら SRE が抱えていたものを事業部へと委譲していった - セルフサービス化以外にも現状に沿ったアラーティングの見直しを行って負担を減らしてきた