プロダクト開発エンジニア全員で取り組むオブザーバビリティ

プロダクト開発エンジニア全員で取り組む オブザーバビリティ 株式会社ユーザベース 安藤裕紀 TechBrew in 東京〜オブザーバビリティのベストプラクティス〜 2024/4/11

00 自己紹介 安藤裕紀 / あんどぅ 株式会社ユーザベース NewsPicks事業 SRE Unit Leader SREチームのマネージャー 兼 テックリード 特技：AWSコスト削減や障害対応を愚直に100本ノックすること 好きなSREのプラクティス：非難なきポストモーテム文化 Incident Response Meetupというイベントを運営しています ©Uzabase, Inc. All Rights Reserved.

00 ソーシャル経済メディア NewsPicksについて ©Uzabase, Inc. All Rights Reserved.

00 本日のアジェンダ 1. NewsPicksの開発体制とサービスの運用体制 2. 開発・サービス運用の課題意識 3. プロダクト開発エンジニア全員でオブザーバビリティに取り組む 3.1. APMを徹底的に使いこなし、開発・運用に組み込む 3.2. 周辺サービスとのService Mapを拡充する 3.3. SLOを整備して、アラートとCUJを直結させる 3.4. o11yツールの市民権を獲得して、全員が使えるようにする 4. まとめ ©Uzabase, Inc. All Rights Reserved.

01 NewsPicksの開発体制とサービスの運用体制 ©Uzabase, Inc. All Rights Reserved.

01 サービス開始から10周年を迎え、多くのユーザーが利用 ©Uzabase, Inc. All Rights Reserved.

01 NewsPicksのプロダクト開発組織、エンジニア体制 ユーザベースグループ内にNewsPicks独自のプロダクト開発組織があり、70名ほどのエンジニアが在籍しています ユーザベースグループ(約1,200名※業務委託含む) NewsPicks Product Domain (15Unit 約100名) プロダクト マネージャー デザイナー カスタマーサポート ©Uzabase, Inc. All Rights Reserved. プロダクト開発エンジニア (12Unit 約70名) Media Experience Unit Media Infrastructure Unit Subscription Product Unit NPEx Product Unit SBD Product Unit BDD Product Unit Stage Product Unit NP4B Product Unit Mobile App Unit Web Platform Unit Analytics and Data Lab Unit SRE Unit 発表者はSREチームのリーダー として、サービス運用の改善や 開発基盤の改善に取り組んでい ます

01 「全員プロダクト開発エンジニア」という文化 エンジニアが開発から運用までオーナーシップを持ち、常に改善を続ける エンジニアはフルサイクルの問題解決を自走する過程で何度もデプロイを繰り返すことになり、 リリース後にはオンコールで障害対応も行い、サービスを継続的に改善する。 安全かつ高速に開発・リリースでき、問題が発生してもトラブルシューティングできる状態を 追求することが、NewsPicksのユーザーに価値を届けることにつながると考えている。 ©Uzabase, Inc. All Rights Reserved.

01 チームが分かれていても、全員で同じオンコールシフトに入る ● ユーザーから見たら一つのアプリ、一社のサービス運営会社。障害対応はエンジニア全員の仕事 ○ もしニュースが配信できない障害になったら「チームが違うから」とか言ってる場合ではない ● 経済ニュースのサービスなので、24h/365dのオンコールシフトを組んでいる (PagerDutyで管理) ○ 運用当番は、障害が発生した際の一次切り分けとエスカレーション、状況報告を推進する 24d/365d常時モバイルアプリ担当1名と サーバー担当2名の3名が『運用当番』 発表者はSREチームですがインフラのアラート だけ対応しているわけではなく、運用当番のと きはBizメンバーとのやりとりやアプリケーショ ンの障害対応もしています。Bizメンバーからす ると、バックエンドもSREも関係なく「(問題を 解決してくれる)テックの人」 ©Uzabase, Inc. All Rights Reserved.

02 開発・サービス運用の課題意識 ©Uzabase, Inc. All Rights Reserved.

02 「全員プロダクト開発エンジニア」の価値観は素晴らしいが… エンジニアは流動性の高い職種。10年続くサービスの広範囲に渡って 開発・運用のオーナーシップを醸成していくことは簡単ではない ● 入社3年以内のメンバーが大半。5年以上前の仕様や経緯を知っている人は2~3名しかいない ● 10年モノの共通バックエンドサーバーのモノリス、コードベースが大きいので認知負荷が高い ● マイクロサービス的に作られた周辺サーバー、メンテナンスを担当するチームしかわからない ● 「XX業務で問題が発生している」ときにBizメンバーの業務やオペレーションを知らないので システムでの問題解決やワークアラウンドをすぐに提示できない(Bizメンバーは数百名在籍) →ユーザーのために良いプロダクトを作り改善したいと思っているが 理解できないものにオーナーシップを持つことは（普通は）難しい ©Uzabase, Inc. All Rights Reserved.

オブザーバビリティは理解し説明できる力の尺度。上げたいです 02 書籍『オブザーバビリティ・エンジニアリング』より ❝ 簡単に言うと、私たちが考えるソフトウェアシステムの 「オブザーバビリティ」とは、システムがどのような状態 になったとしても、それがどんなに斬新で奇妙なもので あっても、どれだけ理解し説明できるかを示す尺度です。 また、そのような斬新で奇妙な状態に対しても、事前にデバッ グの必要性を定義したり予測したりすることなく、システムの 状態データのあらゆるディメンションやそれらの組み合わせに ついてアドホックに調査し、よりデバッグが可能であるように する必要があります。もし、新しいコードをデプロイする必要 がなく、どんな斬新で奇妙な状態でも理解できるなら、オブ ザーバビリティがあると言えます。 ©Uzabase, Inc. All Rights Reserved. ❞

03 プロダクト開発エンジニア全員で オブザーバビリティに取り組む ©Uzabase, Inc. All Rights Reserved.

00 本日のアジェンダ 1. NewsPicksの開発体制とサービスの運用体制 2. 開発・サービス運用の課題意識 3. プロダクト開発エンジニア全員でオブザーバビリティに取り組む 3.1. �� APMを徹底的に使いこなし、開発・運用に組み込む 3.2. 周辺サービスとのService Mapを拡充する 3.3. SLOを整備して、アラートとCUJを直結させる 3.4. o11yツールの市民権を獲得して、全員が使えるようにする 4. まとめ ©Uzabase, Inc. All Rights Reserved.

ユーザーに価値を届ける上で、とにかくユーザー視点を優先する 03 書籍『入門 監視』より ❝ まず監視を追加すべきなのは、ユーザがあなたのアプリ ケーションとやり取りをするところです。Apacheのノー ドが何台動いているか、ジョブに対していくつのワーカが 使用可能かといったアプリケーションの実装の詳細をユー ザは気にしません。ユーザが気にするのは、アプリケー ションが動いているかどうかです。とにかくユーザ視点を 優先した可視化が必要です。 最も効果的な監視ができる方法の1つが、シンプルに HTTPレスポンスコード(特にHTTP 5xx番台)を使うことで す。その次として、リクエスト時間(レイテンシとも言う) も有益です。このどちらも何が問題なのかは教えてくれま せんが、何かが問題で、それがユーザに影響を与えている ことは分かります。 ©Uzabase, Inc. All Rights Reserved. ❞

03 効果的かつ効率よくモニタリングできるAPMに全振りする ユーザーに近い ● ● Synthetic Monitoring, RUM(Real User Monitoring) ○ Synthetic Monitoringはすべてのユーザーストーリーを監視するにはコストが高すぎる ○ RUMは一般的な製品ではWebのみの機能。スマホアプリが中心の事業では適さない APM(Application Performance Monitoring) ○ ● APIエンドポイントごとのHTTPレスポンスコードやレイテンシがわかりユーザーストーリーに接続できる Infrastructure ○ CPU・メモリ・ディスク使用率、タスク数などユーザーが使えているかどうかを示すものではない ○ 例えばApplication Load BalancerのCloudWatchメトリクスでは全体のレスポンスコードやレイテンシしか わからないので、一部のクリティカルなAPIが落ちてもわからない ユーザーから遠い →俺はたった今からインフラのメトリクスを捨てる！(インフラ歴13年選手) ©Uzabase, Inc. All Rights Reserved.

03 New Relic APMで共通バックエンドAPIの利用状況を可視化 サーバーサイドはKotlin/Javaなので、エージェント導入で自動計装 →APIエンドポイントごとにエラー率・レイテンシー(95%ile)がわかる ©Uzabase, Inc. All Rights Reserved.

03 コードを読む前にAPIの内部処理がざっくり理解できる💡 あるAPIのトレースのセグメントブレークダウン ● ● ● ● DynamoDBのどのテーブルにgetItem/batchGetItemしているか MySQLのどのテーブルにselect/updateしているか Redisのzscore(ソート済みセットのスコア確認)などオペレーション xxx.ne.jp に外部HTTPアクセスしている →開発をする時にAPIが何をしているかの理解の助けになる 「この分岐は本番では通らないからロジック廃止できるのでは」の確認ができる どの処理に時間がかかっていてパフォーマンス改善の余地があるかがわかる ©Uzabase, Inc. All Rights Reserved.

03 本番のトラブルシューティングでロールバック判断に使う New RelicのDeployment Marker(Change Tracking)を見て 特定のリビジョンのデプロイが障害の原因と判断してロールバックする運用 CI/CDのデプロイ時にマーカー デプロイしたユーザーとrevisionの情報を New Relicに連携→グラフにデプロイの縦線が入る ©Uzabase, Inc. All Rights Reserved. デプロイの特定 デプロイしたユーザーとrevisionを特定し、 リリース内容の影響を確認し、ロールバック

00 本日のアジェンダ 1. NewsPicksの開発体制とサービスの運用体制 2. 開発・サービス運用の課題意識 3. プロダクト開発エンジニア全員でオブザーバビリティに取り組む 3.1. APMを徹底的に使いこなし、開発・運用に組み込む 3.2. �� 周辺サービスとのService Mapを拡充する 3.3. SLOを整備して、アラートとCUJを直結させる 3.4. o11yツールの市民権を獲得して、全員が使えるようにする 4. まとめ ©Uzabase, Inc. All Rights Reserved.

03 共通バックエンドから、周辺システムにも広げていく バックエンドの後ろのマイクロサービスの障害のユーザー影響を知りたい 結局どのユーザー操作に影響があるのか New Relic APM Agent スマホアプリ 共通 バックエンド (Spring) Web Web(Next.js) 課金 広告配信 検索 BFF(Apollo) フィード →各システムにNew Relic APM Agentを導入して分散トレーシングを行う ©Uzabase, Inc. All Rights Reserved.

03 Service Mapが作成され、コードを読まなくても関係がわかる 各システムとのAPIの呼び出し関係が可視化される →共通バックエンドの◯◯APIから広告配信の△△APIの呼び出しがあるとわかる ©Uzabase, Inc. All Rights Reserved.

00 本日のアジェンダ 1. NewsPicksの開発体制とサービスの運用体制 2. 開発・サービス運用の課題意識 3. プロダクト開発エンジニア全員でオブザーバビリティに取り組む 3.1. APMを徹底的に使いこなし、開発・運用に組み込む 3.2. 周辺サービスとのService Mapを拡充する 3.3. �� SLOを整備して、アラートとCUJを直結させる 3.4. o11yツールの市民権を獲得して、全員が使えるようにする 4. まとめ ©Uzabase, Inc. All Rights Reserved.

03 サービスレベル目標(SLO)ベースのモニタリング ユーザー操作(CUJ)からSLIを決め、SLOを設定してサイトの信頼性を定量評価していく ©Uzabase, Inc. All Rights Reserved.

03 ユーザー体験を開発チームにヒアリングし、CUJを確認 チームのミッション クリティカルユーザージャーニー エンドポイント 読者の体験改善 ニュース記事の閲覧 ● 外部記事閲覧 ● オリジナル記事閲覧 ニュースフィード閲覧 ● ニュースフィードトップ ● カテゴリタブ ニュースのPICK・コメント ● PICK・コメント ● コメント削除 フォローリスト表示 ● フォローフィード取得 新規登録 ● ● ● ● ● ● 投稿者の体験改善 新規ユーザー獲得 ©Uzabase, Inc. All Rights Reserved. Appleサインアップ・ログイン Facebookサインアップ・ログイン Googleサインアップ・ログイン Twitterサインアップ・ログイン Linkedinサインアップ・ログイン メールアドレスのサインアップ・ログイン

03 CUJから重要度をつけてSLOを策定し、モニタリング対象を決定 CUJ、担当チーム、システム対象エンドポイント、SLI/SLOをNotionデータベース化 ©Uzabase, Inc. All Rights Reserved.

03 SLOモニタリングをセルフサービスで設定できる仕組みを提供 エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©Uzabase, Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

03 開発チームはエンドポイントとSLOを設定してPR出すだけ エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 設定(PR) CDK for Terraform 反映 cdktf deploy ダッシュボード 確認 チームチャンネル に通知 New Relic Slack アラート ● APIエンドポイント ● SLOターゲット ● ターゲットレイテンシー目標 ● 担当チーム ©Uzabase, Inc. All Rights Reserved. ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

03 cdktf deployでNew Relicのリソース一式が反映される エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©Uzabase, Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

03 SLO・バーンレートからアラート閾値の自動計算、Slack通知 これはCDK for Terraform + TypeScriptのかなり大きな利点 エンドポイントごとのSLOモニタリング リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート ©Uzabase, Inc. All Rights Reserved. New Relic ● ● ● ● ● Service Levels Dashboard AlertPolicy AlertConfition Workflow

03 アラートを受けてダッシュボードを見れば、SLO違反の 原因となったエンドポイント・デプロイの特定まで可能 エンドポイントごとのSLOモニタリング ダッシュボードにチーム別のタブがあり チームの担当エンドポイントを確認できる リポジトリ (GitHub) 開発者 CDK for Terraform 反映 設定(PR) cdktf deploy ダッシュボード 確認 チームチャンネル に通知 Slack アラート New Relic ● ● ● ● ● Service Levels Dashboard SLO準拠状況タイムライン AlertPolicy AlertConfition Workflow Transaction / DeploymentMarker ©Uzabase, Inc. All Rights Reserved.

00 本日のアジェンダ 1. NewsPicksの開発体制とサービスの運用体制 2. 開発・サービス運用の課題意識 3. プロダクト開発エンジニア全員でオブザーバビリティに取り組む 3.1. APMを徹底的に使いこなし、開発・運用に組み込む 3.2. 周辺サービスとのService Mapを拡充する 3.3. SLOを整備して、アラートとCUJを直結させる 3.4. �� o11yツールの市民権を獲得して、全員が使えるようにする 4. まとめ ©Uzabase, Inc. All Rights Reserved.

03 オブザーバビリティ(o11y)にはお金がかかる New Relicのプライシングモデルはみんなで使うとお高い ● オブザーバビリティの活用にはネットワーク効果がある ○ みんなで使って複数のシステムに導入するほど サービス全体でわかることが増えて便利になる （分散トレーシング） ○ ● みんなで使うとノウハウが共有され習熟度が上がる 高い。高いがみんなで使っていきたい・・・ ○ New Relicは一部のシステムにしか導入されていない とか、一部のエンジニアしか使えないから 野良o11yツールが導入されるのは避けたかった ©Uzabase, Inc. All Rights Reserved.

03 エンジニアへの普及とAWSコスト削減を合わせて段階的に購入量を増やす 活用を広げて効果を説明し、コスト削減で予算を交渉しながら徐々に市民権を獲得した 2021 2022 2023 2024 New Relic FSO 6ライセンス (SREのみ) New Relic FSO 12ライセンス (SRE+Webリ アーキチーム) New Relic FSO 20ライセンス (SRE+Web+シニ アエンジニア) New Relic FSO 50ライセンス (エンジニア 社員ほぼ全員) AWSコスト削減 ©Uzabase, Inc. All Rights Reserved. AWSコスト削減 AWSコスト削減

03 エンジニアの喜びの声：Slackを『New Relic』で検索 エンジニアの日常業務の中で当たり前に使われてます（全員プロダクト開発エンジニア） 喜びの声を収集するまでもなく、o11yツールはもはやエンジニアの業務インフラ ©Uzabase, Inc. All Rights Reserved.

04 まとめ ©Uzabase, Inc. All Rights Reserved.

04 ● まとめ オブザーバビリティに取り組むのは、サービスやユーザーのことを理解したいから ○ 事業ミッションやユーザーストーリーにコミットするストリームアラインドチームが 使いこなして開発生産性やトラブルシューティングの効率を改善するアウトカムが重要 (DevOpsのFour Keysには変更失敗率や平均修復時間もあります) ○ そのためSREチームとしてAWSコストを削減して、 プロダクト開発エンジニア全員に使ってもらえるように導入・普及する活動を推進しました ○ オブザーバビリティというとOpenTelemetryなど計測の実装技術に注目されがちですが、 『開発組織で使いこなす』『そのために普及し予算を確保する』も大事だと思います ● プロダクト開発エンジニア全員で使いこなす道を選んで、もはや日常業務のインフラです ○ 計装の技術をおもちゃにして遊ぶよりも組織で使いこなして他社と差をつけよう！ ○ ただ、オブザーバビリティの商用サービスはもう少し安くならないかなぁ・・・ ©Uzabase, Inc. All Rights Reserved.

ご清聴ありがとうございました！ オブザーバビリティを使いこなす バックエンドエンジニア募集中です！ https://tech.newspicks.com/ ©Uzabase, Inc. All Rights Reserved.

• https://tech.newspicks.com/