Upgrade to Pro — share decks privately, control downloads, hide ads and more …

少人数でも運用できるインフラ作り / Operating infrastructure wit...

少人数でも運用できるインフラ作り / 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. 自己紹介 - Kohei Suzuki (@eagletmt) - 2014年に新卒で入社し技術部開発基盤グループに - cookpad.com の

    Rails バージョンアップとか - Jenkins を使った CI 環境作りとか - ECS を使ったアプリケーション実行基盤作りとか - 2019年から SRE グループに所属 - 引き続き ECS 関連の改善とか - fluentd のバージョンを上げつつログ配送の改善とか - 古い VPC や Consul 等の社内でレガシーとなったコンポーネントの廃止とか
  2. 2014年頃の様子 - 多くの開発者がレシピサービス (cookpad.com) の開発をしていた - SRE (当時の名前はインフラ部) がレシピサービスのインフラを運用していた -

    Rails アプリを動かす EC2 インスタンス (Puppet) - MySQL や Redis を動かす EC2 インスタンス (Puppet) - IAM や Route 53 などの一部の AWS リソースは独自ツールでコード管理 - https://github.com/codenize-tools
  3. Microservices で DevOps だ!! - レシピサービス以外の新規事業が立ち上がったり、レシピサービスの一部の機能が独立した りした - 巨大なモノリシック Rails

    で動いていたレシピサービスをマイクロサービスに分割していく決断 がされ、後のお台場プロジェクトで大きく進んだ - 参考: クックパッド基幹システムのmicroservices化戦略 〜お台場プロジェクト1年半の軌 跡〜 https://techlife.cookpad.com/entry/2018-odaiba-strategy
  4. ECS・Terraform 時代 - インフラ面では ECS をベースにアプリケーション実行基盤を作っていくことにした - Hako というツールを開発し、Dockerfile と

    Hako の定義ファイルを書けば Route 53、ELB、 ECS が適切に設定されアプリケーションが動くようになっていった - AWS のマネージドサービスを積極的に活用するようになっていった - MySQL より Aurora MySQL、Memcached より ElastiCache Memcached、Redis で Pub/Sub するより SNS と SQS、etc. - これらの管理には Terraform を使うようになった
  5. 現在 - レシピサービスを構成するマイクロサービス群とクックパッドマートを筆頭に、様々なサービス が稼働している (開発環境やスタッフ向けのアプリも含む ) - ECS のサービス数: 561

    - ECS のコンテナインスタンス: ピークタイムに 800 くらい - 同時に動いている ECS タスク数: ピークタイムに 2200 くらい - 現時点で5人の SRE グループでこれらのサービスの基盤を支えている - ここ数年で減ったものの、元々多くても8人くらいの規模だった
  6. セルフサービス化 - 結論: たくさんのサービスを少人数で運用していくためには自動化とセルフサービス化しかな い - 自動化し、依頼するのではなく pull request を出すようにしたり

    Web 上での操作で完結でき るようにしたり - 適切に権限を渡して SRE の特権無しで行えることを増やす - SRE の主な役割を「運用・管理すること」から「運用・管理するためのしくみを作ること」に変え ていった
  7. hako-console - Hako アプリ単位で色々な情報を見れるコンソールを開発した - すべてのアプリが同じ基盤で動いている状態になると、色々な前提を置けて自動化できる範 囲が広がる - アプリの一覧が分かる -

    各アプリに対応する ELB が分かり、レイテンシ等の基本的なメトリクスがどこにあるか分かる - 各アプリに対応するコンテナのメトリクスや Envoy のメトリクスも分かる
  8. hako-console - 環境変数での設定を徹底する - 接続先などの設定値はハードコードせず環境変数で与える - 環境変数を見ることで利用しているものが分かる - DATABASE_URL からデータベースのインスタンスを特定

    - SENTRY_DSN からエラートラッカーのプロジェクトを特定 - これらを自動化して hako-console として提供し、どんなアプリでも使える基本的なダッシュ ボードを自動生成している - 参考: Web アプリケーションを把握するためのコンソール https://techlife.cookpad.com/entry/2018/04/02/140846
  9. マネージドサービス化 - メトリクスの閲覧は hako-console で解決したとして、次はミドルウェアの管理を委譲したい - SRE が EC2 上で運用していたミドルウェアをどんどん

    AWS のサービスに移行していった - MySQL は Aurora MySQL へ - Redis は用途に応じて SNS + SQS や DynamoDB や ElastiCache Redis へ
  10. 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
  11. Terraform の運用 - 1つのリポジトリに集約しつつも tfstate はプロジェクト (アプリケーション) 単位で分割するとい う構成にした -

    1つのリポジトリに集約したのは一覧性のためと統一的な CI を適用するため - tfstate を分割したのは事業部にオーナーシップを持たせていくため - tfstate が巨大だと terraform plan が遅すぎるという実用的な面もあるが ……
  12. 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
  13. Terraform の運用 - セルフサービス化が進んでいるいくつかのチームでは SRE の介入無しで Terraform 経由でリ ソースを操作できるようにしている -

    pull-request は誰でも出せるものの、レビューや実際の操作に SRE が入るようにしている チームがまだまだ多い
  14. SLI/SLO - 監視やミドルウェアも事業部に委譲していきたいが、全社的な SRE としてどのサービスも一定 の可用性は維持してほしい - 開発が活発で規模が大きくなりつつあるクックパッドマートから SLI/SLO の取り組みを始めた

    - エラーレートやレイテンシを SLI として SLO を定め、SRE は定期的にチェックしつつ違反の恐 れがあればマートのチームに働きかける - マートのチーム内でも定期的にチェックして違反しそうであれば改善に時間を割いてもらう - https://speakerdeck.com/hfm/slo
  15. セルフサービス化まとめ - マイクロサービス化で明確になっていったサービスのオーナーシップに沿うように、ミドルウェ ア等のオーナーシップも事業部へと委譲していく方針にした - いくつかの段階に分けて進めているところ - サービス単位のモニタリングのために hako-console を作った

    - マネージドサービスへと移行し、サービス単位で Terraform の tfstate を分けることでミドル ウェアの管理もサービス単位にした - 一部のチームでは SRE が関与することなく Terraform 経由で自由にリソースを変更できるよ うにした - クックパッドマートでは SLI/SLO の運用を始めた
  16. オンコール対応 - 少人数でやっていくにあたって一番大変なもの - PagerDuty を使ってオンコール対応をしているが、最初はすべてのアラートが high urgency で飛んできて大変だった -

    そこでアラーティングの見直しを進めていった - アラートを分類して urgency を下げる - 不要なアラートを減らす - 重度の障害状態に対して別途アラートを設定する - つまりアラートに対してメリハリをつけていった
  17. アラートの分類 - PagerDuty の機能として high urgency と low urgency の分類がある

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