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

6社合同 SRE勉強会での発表資料です。
https://line.connpass.com/event/236497/

Transcript

1. © 2022 Cookpad Inc. 6社合同SRE勉強会 少人数でも運用できるインフラ作り Kohei Suzuki
2. 自己紹介 - Kohei Suzuki (@eagletmt) - 2014年に新卒で入社し技術部開発基盤グループに - cookpad.com の Rails バージョンアップとか - Jenkins を使った CI 環境作りとか - ECS を使ったアプリケーション実行基盤作りとか - 2019年から SRE グループに所属 - 引き続き ECS 関連の改善とか - fluentd のバージョンを上げつつログ配送の改善とか - 古い VPC や Consul 等の社内でレガシーとなったコンポーネントの廃止とか
3. アウトライン - クックパッドでの開発体制やインフラの変遷 - セルフサービス化 - モニタリングの委譲 - マネージドサービス化 - SLI/SLO - アラーティング - まとめ
4. © 2022 Cookpad Inc. 4 開発体制とインフラの変遷
5. 2014年頃の様子 - 多くの開発者がレシピサービス (cookpad.com) の開発をしていた - SRE (当時の名前はインフラ部) がレシピサービスのインフラを運用していた - Rails アプリを動かす EC2 インスタンス (Puppet) - MySQL や Redis を動かす EC2 インスタンス (Puppet) - IAM や Route 53 などの一部の AWS リソースは独自ツールでコード管理 - https://github.com/codenize-tools
6. 2014年頃の様子
7. Microservices で DevOps だ!! - レシピサービス以外の新規事業が立ち上がったり、レシピサービスの一部の機能が独立した りした - 巨大なモノリシック Rails で動いていたレシピサービスをマイクロサービスに分割していく決断 がされ、後のお台場プロジェクトで大きく進んだ - 参考: クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌 跡〜 https://techlife.cookpad.com/entry/2018-odaiba-strategy
8. ECS・Terraform 時代 - インフラ面では ECS をベースにアプリケーション実行基盤を作っていくことにした - Hako というツールを開発し、Dockerfile と Hako の定義ファイルを書けば Route 53、ELB、 ECS が適切に設定されアプリケーションが動くようになっていった - AWS のマネージドサービスを積極的に活用するようになっていった - MySQL より Aurora MySQL、Memcached より ElastiCache Memcached、Redis で Pub/Sub するより SNS と SQS、etc. - これらの管理には Terraform を使うようになった
9. ECS・Terraform 時代
10. 現在 - レシピサービスを構成するマイクロサービス群とクックパッドマートを筆頭に、様々なサービス が稼働している (開発環境やスタッフ向けのアプリも含む ) - ECS のサービス数: 561 - ECS のコンテナインスタンス: ピークタイムに 800 くらい - 同時に動いている ECS タスク数: ピークタイムに 2200 くらい - 現時点で5人の SRE グループでこれらのサービスの基盤を支えている - ここ数年で減ったものの、元々多くても8人くらいの規模だった
11. © 2022 Cookpad Inc. 11 セルフサービス化
12. セルフサービス化 - 結論: たくさんのサービスを少人数で運用していくためには自動化とセルフサービス化しかな い - 自動化し、依頼するのではなく pull request を出すようにしたり Web 上での操作で完結でき るようにしたり - 適切に権限を渡して SRE の特権無しで行えることを増やす - SRE の主な役割を「運用・管理すること」から「運用・管理するためのしくみを作ること」に変え ていった
13. オーナーシップ - マイクロサービス化を進める上で重要な概念 - マイクロサービス化の最大のメリットの1つがオーナーシップの明確化 - マイクロサービス化でアプリケーションコードのオーナーシップが明確になっていった - この流れに乗って、アプリケーションコードだけでなくサービスを構成するすべてのリソースの オーナーシップを事業部に渡していく
14. オーナーシップ
15. オーナーシップ
16. オーナーシップ - 最終的にはデータベース等のメンテナンスや障害時の対応等も事業部に委譲していきたい - 最初のステップとして、データベース等も含む 1つのサービス単位でメトリクスを閲覧できる状 態を目指した
17. hako-console - Hako アプリ単位で色々な情報を見れるコンソールを開発した - すべてのアプリが同じ基盤で動いている状態になると、色々な前提を置けて自動化できる範 囲が広がる - アプリの一覧が分かる - 各アプリに対応する ELB が分かり、レイテンシ等の基本的なメトリクスがどこにあるか分かる - 各アプリに対応するコンテナのメトリクスや Envoy のメトリクスも分かる
18. hako-console - 環境変数での設定を徹底する - 接続先などの設定値はハードコードせず環境変数で与える - 環境変数を見ることで利用しているものが分かる - DATABASE_URL からデータベースのインスタンスを特定 - SENTRY_DSN からエラートラッカーのプロジェクトを特定 - これらを自動化して hako-console として提供し、どんなアプリでも使える基本的なダッシュ ボードを自動生成している - 参考: Web アプリケーションを把握するためのコンソール https://techlife.cookpad.com/entry/2018/04/02/140846
19. hako-console
20. hako-console ログ 連絡先 リポジトリ エラートラッカー ダッシュボード 実行中のコード オーナー
21. hako-console
22. hako-console RPS Latency CPU Memory Memory CPU CloudWatch Deploy CloudWatch Prometheus
23. hako-console - これにより SRE の専門知識がなくても、事業部のエンジニアが自分たちのサービスの状態を 把握しやすくなった - 元々メトリクスはどこか (CloudWatch、Prometheus、etc.) にとられていたが、自分に関係す るメトリクスの在り処が見えるようになった
24. マネージドサービス化 - メトリクスの閲覧は hako-console で解決したとして、次はミドルウェアの管理を委譲したい - SRE が EC2 上で運用していたミドルウェアをどんどん AWS のサービスに移行していった - MySQL は Aurora MySQL へ - Redis は用途に応じて SNS + SQS や DynamoDB や ElastiCache Redis へ
25. 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
26. codenize-tools の思想 AWS サービス毎にリソースを横に一元管理
27. アプリケーション単位で様々な AWS リソースを管理 Terraform の場合
28. Terraform の運用 - 1つのリポジトリに集約しつつも tfstate はプロジェクト (アプリケーション) 単位で分割するとい う構成にした - 1つのリポジトリに集約したのは一覧性のためと統一的な CI を適用するため - tfstate を分割したのは事業部にオーナーシップを持たせていくため - tfstate が巨大だと terraform plan が遅すぎるという実用的な面もあるが ……
29. 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
30. Terraform の運用 - セルフサービス化が進んでいるいくつかのチームでは SRE の介入無しで Terraform 経由でリ ソースを操作できるようにしている - pull-request は誰でも出せるものの、レビューや実際の操作に SRE が入るようにしている チームがまだまだ多い
31. SLI/SLO - 監視やミドルウェアも事業部に委譲していきたいが、全社的な SRE としてどのサービスも一定 の可用性は維持してほしい - 開発が活発で規模が大きくなりつつあるクックパッドマートから SLI/SLO の取り組みを始めた - エラーレートやレイテンシを SLI として SLO を定め、SRE は定期的にチェックしつつ違反の恐 れがあればマートのチームに働きかける - マートのチーム内でも定期的にチェックして違反しそうであれば改善に時間を割いてもらう - https://speakerdeck.com/hfm/slo
32. クックパッドマートでの SLI/SLO リクエスト成功率 p90 レイテンシ
33. セルフサービス化まとめ - マイクロサービス化で明確になっていったサービスのオーナーシップに沿うように、ミドルウェ ア等のオーナーシップも事業部へと委譲していく方針にした - いくつかの段階に分けて進めているところ - サービス単位のモニタリングのために hako-console を作った - マネージドサービスへと移行し、サービス単位で Terraform の tfstate を分けることでミドル ウェアの管理もサービス単位にした - 一部のチームでは SRE が関与することなく Terraform 経由で自由にリソースを変更できるよ うにした - クックパッドマートでは SLI/SLO の運用を始めた
34. © 2022 Cookpad Inc. 34 アラーティング
35. オンコール対応 - 少人数でやっていくにあたって一番大変なもの - PagerDuty を使ってオンコール対応をしているが、最初はすべてのアラートが high urgency で飛んできて大変だった - そこでアラーティングの見直しを進めていった - アラートを分類して urgency を下げる - 不要なアラートを減らす - 重度の障害状態に対して別途アラートを設定する - つまりアラートに対してメリハリをつけていった
36. アラートの分類 - PagerDuty の機能として high urgency と low urgency の分類がある - 翌営業日の対応で十分なやつの urgency を low に下げた - ユーザ影響の無いジョブキューの監視とか - 開発用途のアプリケーションやストレージの監視とか
37. 不要なアラートを減らす - 一時的に問題のある状態になってもすぐに回復できればアラートを発砲しないようにした - 「一瞬エラーレートが上がったけどすぐ回復した」のような場合、深夜に叩き起こされてもその 場でやることがない - ECS 移行やマネージドサービス移行により、とくに工夫しなくても自動回復できるパターンが 大きく増えた - 代わりに定期的にメトリクスをチェックして、気になったところを調査すれば十分とした - 発砲条件に期間を追加
38. 不要なアラートを減らす こういうので起こされたくない。後から原因調査できれば十分。
39. 不要なアラートを減らす - サービス間通信でのエラーレートは原則アラート対象とはしないようにした - マイクロサービス化された状態ではサービス間通信でのエラーはある程度仕方ない - Envoy のリトライや各サービスでの graceful degradation でカバーしていく - カバーしきれずユーザ影響が出てしまう場合は、エンドユーザと前面のサービスの間のエ ラーレートが上がるはず
40. 不要なアラートを減らす backend-y のエラーレートが高くても frontend-a のエラーレートが低ければ問題ない
41. 不要なアラートを減らす backend-x の影響で frontend-a のエラーレートが高まった場合はアラート
42. 重度の障害状態への備え - アラートが多すぎるのは大変だが、不十分だとサービスの提供に支障が出る可能性が高まる - 最終防衛ラインとして、明らかに高いエラーレートが一定期間続いた場合は通常とは異なるエ スカレーションポリシーを適用することにした - レシピサービス (Web、API) で高いエラーレートの状態が5分間続いたらプライマリとセカンダ リに同時に通知 - 「滅多に発生しないが発生したら複数人での対応が必須」というラインを決めた
43. © 2022 Cookpad Inc. 43 まとめ
44. まとめ - たくさんのサービスを少人数で運用していくために自動化とセルフサービス化を中心にやって きた - SRE の主な役割を「運用・管理すること」から「運用・管理するためのしくみを作ること」へ - オーナーシップを意識しながら SRE が抱えていたものを事業部へと委譲していった - セルフサービス化以外にも現状に沿ったアラーティングの見直しを行って負担を減らしてきた