6社合同SRE勉強会について

クックパッド技術部 SRE チームの @eagletmt と @mozamimy が、以下の Connpass で告知・募集されている「6社合同SRE勉強会」に登壇します。

https://line.connpass.com/event/236497/

6社合同SRE勉強会は、IT 企業 6 社 (LINE/メルカリ/クックパッド/ディー・エヌ・エー/サイバーエージェント/リクルート) が合同で開催する、Site Reliability Engineering (SRE) 領域の勉強会です。各社が特徴的な事例を共有し、各セッションのAsk the Speakerでは違う会社の登壇者がモデレーター兼聞き手を務めて、知見共有＆深堀りを行なっていきます。

多様なバックグラウンドを持つ各社の SRE が取り組んでいる課題について、技術的な面から組織的な面までを絡めた、魅力的な内容のセッションが盛りだくさんとなっています。

以下、クックパッド SRE によるセッションの概要をご紹介します。現在、鋭意資料の準備中ですので、本番では細かい内容が変更になる可能性がありますがご容赦ください。

Track B 13:30-14:15: 少人数でも運用できるインフラ作り

技術部 SRE グループの鈴木 (id:eagletmt) です。このセッションではクックパッドにおけるインフラ構成の変遷を概観しつつ、その変遷の根底にあったマネージドサービス化やセルフサービス化について話そうと思っています。

私がクックパッドに入社した2014年当時、社内の多くのエンジニアはレシピサービス (cookpad.com) の開発にかかわっており、モノリシックな Rails アプリケーションが Amazon EC2 上にデプロイされてレシピサービスが実現されていました。SRE *1 の仕事もレシピサービスに関することが中心でした。一方でみんなのカフェや料理教室といったサービスをレシピサービスとは独立したアプリケーションで提供しており、API での連携の基礎ができてきたりマイクロサービス化が始まりつつありました https://techlife.cookpad.com/entry/2014/09/08/093000 。レシピサービスのマイクロサービス化についてはお台場プロジェクト https://techlife.cookpad.com/entry/2018-odaiba-strategy へと続いていき、このお台場プロジェクトによって大きく進みました。現在のレシピサービスは Web フロントエンドの一部を Next.js で提供するようになったり https://techlife.cookpad.com/entry/2020/12/01/093000 、スマートフォンアプリ向け API の一部は Java で実装された BFF を利用していたり https://techlife.cookpad.com/entry/2019-orcha-bff 、Go で実装された広告配信サーバがあったり https://techlife.cookpad.com/entry/dynamodb-accelerator-usecase-adserver 、実装言語も異なる様々なアプリケーションから成り立っています。そして事業面でもレシピサービスだけでなくクックパッドマートにも力を入れていて、多くのサーバーサイドエンジニアがレシピサービスの Rails アプリ開発に従事していた頃とは大きく状況が変わっています。

このようなアプリケーションの変化に合わせて、インフラ構成や SRE の役割も変化していく必要があります。新規事業や新しいマイクロサービスがどんどん増えていく状況では、10人にも満たない SRE チームがアプリケーションに合わせて EC2 インスタンスや MySQL を用意して運用していてはそれだけで手一杯になってしまいます。そこでサービス開発において SRE がボトルネックとならないようにするため、可能な限り AWS のマネージドサービスを利用するようにして SRE にとっても運用負荷を軽減しつつ、事業部のエンジニアへと運用を委譲しやすくしました。さらに、新規のアプリケーションを本番環境で動かすために必要な作業を自動化したり、インフラ操作の権限を委譲していくことで、できるだけ SRE の手作業無しでも新規リリースやミドルウェアの変更を行えるようにセルフサービス化を進めてきました。このセルフサービス化の考え方について話しつつ、とくに自分が中心的に関わっていた ECS 関連や Terraform 移行について一例として触れようと思っています。

また、SRE の運用負担について話す上でオンコール対応は切っても切れない話題でしょう。マイクロサービス化に合わせてインフラが複雑化する中、アラーティングの基準やオンコール体制をどう変化させたかについても触れようと思っています。

Web アプリケーションを把握するためのコンソール https://techlife.cookpad.com/entry/2018/04/02/140846
ECS インフラの変遷 https://techlife.cookpad.com/entry/2021/08/05/114810
AWS リソース管理の Terraform 移行 https://techlife.cookpad.com/entry/2020/02/28/120000

Track A 15:15-16:00: AWS コストを可視化して「説明」できるようにするための取り組み

技術部 SRE グループの mozamimy です。本セッションでは、クックパッドにおける、AWS のコストを可視化・管理し、最適化までカバーする取り組みについて話す予定です。AWS コストを、と銘打っていますが、その根本的な考え方や各テクニックの本質的な部分は GCP や Azure といった他のパブリッククラウドでも役に立つでしょう。

会社のミッションを達成するための原動力として、お金は有限のリソースであり適切に管理するべきです。サービスを提供するためのインフラはそれ自体が利益を生むことはできません。したがって、ユーザ向けに同じクオリティのサービスや、社内の開発者向けに同じ開発効率を提供できるのであれば、インフラコストを下げて、事業に直接関係する投資などの有意義なお金の使い方をするほうがよいでしょう。

AWS のコスト管理・最適化の枝葉のテクニックはいろいろありますが、「コストを説明できる」というところに集約できるとわたしは考えています。クックパッドではこの考え方をベースにして、年次の AWS の予算案の作成、月次の経営層をまじえてのコストの振り返り、週次の SRE 定例ミーティングなどを中心とした、コスト管理の業務プロセスを実践しています。

本セッションでは、まず「コストを説明できる」というのはどういうことかを説明したのち、過去 (2019 年頃) のクックパッドにおける AWS コスト管理の課題を振り返り、どのような流れで現在の業務プロセスになったのかを説明します。

次に、その業務プロセスを支える技術について、以下の仕組みについてそれぞれ説明します。