$30 off During Our Annual Pro Sale. View Details »

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

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

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

Kohei Suzuki

March 11, 2022
Tweet

More Decks by Kohei Suzuki

Other Decks in Technology

Transcript

  1. © 2022 Cookpad Inc.
    6社合同SRE勉強会
    少人数でも運用できるインフラ作り
    Kohei Suzuki

    View Slide

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

    View Slide

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

    View Slide

  4. © 2022 Cookpad Inc. 4
    開発体制とインフラの変遷

    View Slide

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

    View Slide

  6. 2014年頃の様子

    View Slide

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

    View Slide

  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 を使うようになった

    View Slide

  9. ECS・Terraform 時代

    View Slide

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

    View Slide

  11. © 2022 Cookpad Inc. 11
    セルフサービス化

    View Slide

  12. セルフサービス化
    - 結論: たくさんのサービスを少人数で運用していくためには自動化とセルフサービス化しかな

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

    View Slide

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

    View Slide

  14. オーナーシップ

    View Slide

  15. オーナーシップ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  19. hako-console

    View Slide

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

    View Slide

  21. hako-console

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  34. © 2022 Cookpad Inc. 34
    アラーティング

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  43. © 2022 Cookpad Inc. 43
    まとめ

    View Slide

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

    View Slide