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