会社で導入したDatadogの機能と今年のさだまさしについて振り返る

みなさんさだまさしは好きですか？私は好きです。

2022年は年初から動乱続きの1年で、清水寺で発表される今年の漢字も「戦」になるなど不穏な社会情勢を表すような出来事が多かった印象です。
私にとっても2022年は変化の年で、転職を行い、ロールとしても今まで専門職としては未経験のSREのロールで働いています。

「さだまさし界」 も大変動きの大きい年で、まさかの連ドラ出演、深夜生放送のラジオ番組の開始、そしてデビュー50周年に伴う記念イベントなどなど、毎年毎年「活発に活動する」方ではあるのですが例年にも増して活動が活発で、印象深い年になりました。

ということで、年末を彩る Advent Calendar にふさわしい記事として、今年1年を振り返りたいと思います。
テーマは、私のSREとしての取り組みのひとつとして Observability の向上のために採用している Datadog について、そして さだまさし についてです。
それぞれ、交互に紹介していきたいと思います。

さだまさしについて、ただ書いていくと宣伝にしかならないので、Datadogについての記事という文脈で書かせていただく事もあり、諸々の事象をテクニカルに 「数値化」「可視化」 することを目的とし、あくまでデジタルにデータ指向のアプローチで記事を書きたいと思います。

Datadog の IaC 環境の整理 (GitHub Actions, Terraform)

Datadog についてのイントロダクション的な説明は不要と思うので割愛します。多くの会社で導入されている Monitoring SaaS です。

まず最初は一般的な機能紹介というより、会社の中でどのように使っているか、という環境の整備周りの話について書きます。

今の会社に私が入社したのは7月なのですが、そのタイミングですでに Datadog は会社として導入が行われていて、ダッシュボード機能など一部機能が業務でも使われていました。
監視周りの環境をより一層整備するために、以下の整理を入社後行うことにしました

1. 監視プラットフォームの統一 (AWS, GCP 等のメトリクスを集約)
2. 監視設定の IaC 化 (Terraorm)
3. GitHub Actions と連携した各種処理の自動化
4. 監視ルール基準の作成

1. 監視プラットフォームの統一

1つ目は監視環境の集約です。今の会社でもいくつかのクラウドサービスを並行して使っており、各システム上の監視についてはそれぞれのクラウドプラットフォームで行っていましたが、機能によって見るべきダッシュボードや監視等の設定がバラバラになっている事が課題となっていました。
Datadog でなくても良いのですが、現在 SaaS の監視ツールで最も使い勝手が良いサービスなので、Datadog 導入済みの事もありこちらに各サービスのメトリクスをすべて集約するようにしました。アラート通知の設定も Datadog に基本一元化する方向にしています。

2. 監視設定の IaC 化

2つ目。アラートの設定を一元管理する際に、ツールとして Terraform を採用しました。
Terraform は Datadog 向けの Provider も提供されていますし、Datadog で IaC 的なことを行おうとする環境としてはほぼ唯一のツールでもあるので、自然と採用が決まりました。

Terraform でダッシュボードの設定なども含めて管理できるのですが、現時点ではあまり範囲を広げすぎずに、アラート通知のところにだけスコープを狭めて Terraform を適用しています。この辺は体制とルールが整い次第、追々範囲を広げて行く予定です。

resource	provider
アラート通知 (monitor)	https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/monitor
Synthetic Test	https://registry.terraform.io/providers/DataDog/datadog/latest/docs/resources/synthetics_test
他サービスとのインテグレーション	AWS, GCP

3. GitHub Actions と連携した各種処理の自動化

Terraform のような IaC ツールを導入した理由の一つは、GitHub で設定ファイルを管理することで監視の構成管理を行う、というのも目的の一つです。
変更内容について履歴を残し、内容のレビューや議論を行えるようにする、というものです。

そしてその判断の補助のためにいくつかの処理を自動化しています。いわゆる linter 的なものの導入です。
会社では GitHub Actions を CI ツールとして使用しており、現在は以下ツールを有効にして自動的に各種チェックを行いっています。

tool	description
tflint	tf ファイルの lint ツール
tfsec	tf ファイル中にセキュリティ的に問題がある記述がないかチェック
tfcmt	terraform plan した結果を PullRequest に投稿するツール
tfupdate	terraorm 本体や provider などのバージョンチェックツール。 tfupdate-action と組み合わせて最新版があれば自動的に PullRequest を生成
actionlint	terraform と直接関係ないですが、GitHub Actions の構文に問題がないかチェック

上記ツールのうち Lint 的なものについては Status が All Green にならない限り基本的に PullRequest のマージは行われないようにしています。
Lint だけで補えていない要素につては PullRequest Template の方に明文化し、レビュワーによって判断のブレがなるべく起こらないようにはしています。

4. 監視ルール基準の作成

監視の基準がサービスや機能、担当者によってまちまちだと運用時の混乱の元になるので、監視においての基準についてもあわせて整理しました。
こちらは現在は Wiki にドキュメントとして集約して記述し、その内容を開発者には参照してもらうようにしています。

書いている内容は、以下のようなものです。

• Datadog のタグ設計
• アラート通知レベルの整理
• 閾値決めのルール
• 通知内容のフォーマット（タイトル、本文）

将来的には、この辺のルールについてもたとえば conftest とかを用いてポリシー化し、より strict に運用できるようになると良いかな、とは思っています。

さだまさし、連ドラに多数出演

さだまさし、コンサートには行ったことないし曲も「関白宣言」や「北の国から」くらいしか知らないけど、テレビでは見たことがある、という人がここ10年来増えてきました。
主要な原因はNHKの生放送の番組ですが、2022年は何故かドラマに多数出演することになり、今まで以上にさだまさしのテレビへの露出が増えた1年だったなと思います。

今年出演したドラマをまとめると以下のような感じ。

name	description
カムカムエブリバディ (~2022年4月)	ラジオ英会話のアナウンサー「カムカムおじさん」の平川唯一役
石子と羽男-そんなコトで訴えます?- (2022年7月~9月)	石子の父親で潮法律事務所の所長・潮綿郎役
舞い上がれ！ (2022年10月〜)	バラモン凧役。ナレーター

朝の連続ドラマ小説に1年で2作も参加しており、下手したら毎日さだまさしの声がテレビから聴こえてくる、といったなかなか異様な状況でした。

もちろん朝の連ドラ出演は、今回が初めて。さだまさしは今年70歳ですが、70の爺、それも確固たる知名度とパブリック・イメージが定着している有名人が今まで未経験の領域に脚を踏み込むのは並大抵の神経では無理だなと感嘆します。

やはりドラマに出たりすると一般の方の知名度もかなり上がるようで、会社の人からも 「さだまさし、石羽に出ますよね？今季イチオシのドラマです！」 といった声をかけられたりすることもありました。私は所詮ファンでしかなく、関係者でもなくもちろん本人でもないですが、何か嬉しい気持ちになりますね。

さて、感覚的に 「テレビの露出が増えた」 と書いてますが、もう少し定量的に分析してみます。
ここでは、 「SADA」 という指標（Sadamasashi Appearance time DAta） を基に、以前とくらべてどの程度変化があるかを見ていきます。

算出手法として、EPGに登録されている出演者情報などを基に、概算の出演時間(Estimated SADA)を割り出す手法が考えられます。
自前での構築はいきなりは難しいので、同種のデータを検索することができるサイトの数値を基に計算させていただきます。

さだまさしのページはこちら

上記サイトのデータを引用し、手元で月単位でグラフ化したものが以下です。

トレンドラインを見ると、SADA の数値が確実に右肩上がりになっており、テレビへの露出が増えていることがわかります。棒グラフを見ると特に今年の10月以降にその傾向が顕著で、これは「舞い上がれ！」のナレーター出演が大きく影響していると思われます。ざっくりと、「さだまさしのテレビの露出（SADA）が増えている」は真である、とみなすことができます。

テレビの露出の増加にともない一般の方の行動にどの程度影響を与えたか、を見てみたいと思い、Googleトレンドの数値もみてみました。ただし、SADAの増加とGoogleトレンドの数値にはあまり相関はなさそうです。よりリアルな行動をトラッキングできれば、もう少し違う結果も見られるかもしれません。

ちなみに、 ドラマについて、「当然全話見たでしょ？」 とよく言われるんですが、申し訳ないですが私は１話も見ませんでした。
ドラマは自分のペースで見れないので、苦手なんです。すみません。

Datadog APM を用いたパフォーマンス監視

今年、最も有効活用したといって良いのが、 Datadog APM でした。アプリケーション上のボトルネックの特定やパフォーマンス改善のためにフル活用しています。

各言語向けに提供されている Trace の仕組みを導入することで、プログラム内で実行されている処理の実行回数や所要時間を可視化することができるツールです。
我々の会社は PHP メインで開発しているため、PHP 用のインストーラーを使用して導入をしています。
https://docs.datadoghq.com/ja/tracing/trace_collection/dd_libraries/php/

Datadog APM 自体は Qiita などでも多数記事が存在し、基本的な機能や導入方法についてはそちらでまとめられているためこの記事では割愛します。
ここでは、会社でのユースケースについて記載します。

遅い API 処理や SQL が発生した場合定期的に Slack 通知

Datadog APM 含め、Datadog で取り扱われているデータは基本的にすべて メトリクス として定義されていて、それらの数値を基に自前のダッシュボードを作ったり、閾値を設定してアラートを通知したり、ということが自由自在に行えることが Datadog の強みだと思います。

この利点を用いて、Datadog APM の機能を使って、遅い API や遅い SQL について Monitor の定義を使ってアラート通知を行うようにしています。
たとえば Slow Query の Slack 通知対応をしようとすると俺々スクリプト的なものが登場しがちですが、Datadog APM の値を使うと統一的な方式で管理できるので、今はこちらを採用しています。

avg(last_30m):avg:trace.PDOStatement.execute{env:xxx,service:pdo} by {resource_name,resource} > xx

こちらのようなクエリーを Monitor に登録し通知設定を行い、閾値を超過した SQL を検知したら Slack に通知するようにしています。
通知内容には以下のような記述で SQL 自身や　Datadog APM の URL を含めてます。URL をクリックすることで当該 SQL の実行頻度や、アベレージのレイテンシー、呼び出し元などが網羅的に確認できるため、問題点を迅速に捉えることができるため重宝しています。

- SQL: {{resource_name.name}}
- APM: https://app.datadoghq.com/apm/resource/pdo/PDOStatement.execute/{{resource.name}} 

パフォーマンスレポートに使用

パフォーマンスチューニングを行った後の効果測定にも Datadog APM を使用しています。
人によって方法は若干ゆらぎがありますが、私が何かしらのチューニング対応を行った際はDatadog Notebook を用いて当該機能の Datadog APM グラフを添付し、対応前後でどの程度のパフォーマンス変化があったかを可視化するようにしています。

報告をする際にも便利ですし、実際の効果のあるなしが Fact で理解できるため、意思決定・判断のツールとして有効活用されています。

上記グラフは、実際にパフォーマンスチューニングをした前後の、DB、API それぞれの Latency のグラフを、Datadog APM のデータを基に作成したものです。
赤い点線が前週の結果で、実線が対応を行った週のデータです。チューニング対応は Wed 14 に実施しています。
このように、顕著にパフォーマンスが改善していることを Fact を基に判断することができますし、組織の中での共有もしやすいので便利です。

さだまさし、ニューアルバム「孤悲」発売。コンサートツアー41公演完走

ほとんどの人にとって、今やさだまさしは歌手というより 「しゃべりの長いおじさん」 というイメージの方が強いと思いますが、れっきとした現役バリバリのミュージシャンです。
御年70歳を迎えた今年も、ニューアルバム 「孤悲」 を発売し、このアルバムをタイトルに掲げたコンサートツアーも実施し先日41公演を無事完走しました。

「孤悲」は「こい」と読みます。さだまさしの創作した言葉かというとそうではなく、いわゆる「恋」の万葉仮名で、万葉集の中では大伴家持などの歌に見られる表現のようです。

さだまさしは、近年のコロナ禍における人々の孤独さ、心の悲しみをテーマにしてアルバムを作りたいという思いから、「孤独で悲しい」という含意をもつこの文字をアルバムタイトルとしたようです。

ちなみに、コンサートグッズでは「孤悲」グッズもいくつか存在しており、私もファンの嗜みとしてTシャツを持っているのですが、こういうデザインになっており事情を知らない人には 「孤独」アピールをしてる謎の人 という印象を与えかねないため外で着用するのは自粛しています。

今回のアルバムはかなりの難産だったようですが、個人的にはとても意欲的な作品に仕上がっていると思います。
ウクライナ戦争を題材に平和への強い祈念と独裁者への怒りを歌にした 「キーウから遠く離れて」、太宰府天満宮で行われている神事を題材に世の中にはびこる嘘や矛盾、悲しみが「幸い」に変わるようにと歌う 「鷽替え」、そしてコロナの中で直面した心の孤独さや悲しさをテーマにした 「孤悲」、等。
楽曲のクオリティの高さもそうですが、今我々が生きている「時代」をテーマに据え、正面から歌にする、という姿勢に一番感銘を受けます。

アルバム「孤悲」を冠にかかげたコンサートツアーも大変盛況で、全国41箇所の公演はほぼ全席ソールドアウト。
私は今ツアーは10公演ほど参加させていただき、最前列も最後列（3階席の一番後ろ）も経験させていただきましたがどの会場に行ってもびっくりするくらい人が埋まっており、これほどの人気を長年維持できているというのも稀有な存在だなと思います。

さだまさしのコンサートの最大の特徴は、楽曲のパフォーマンスも素晴らしいのですが、最近つとに有名になった 「トーク」 でしょうか。
今ツアーは、2時間半のコンサートで、歌う曲はたった「13曲」、のこりは全部トークです。「さだまさしは歌っている時間よりトークの方が長い」 という都市伝説が流布されていますが、今ツアーに関してはとくにそんな感じがしました。

感覚的な表現はよろしくないので、ここでも数値で分析してみます。
さだまさしのコンサートツアーのセットリストを基に、ツアーごとの曲数と、曲の演奏時間、そして推測されるそれ以外の時間（≒トークの長さ）を計算してみたいと思います。

さだまさしは「歌手」であると主張しているので、歌を歌う時間よりトークの方が長いとなると、さだまさしのアーティストとしての存在価値が問われる事態になります。
なので、その防衛ラインを、 「SADA」 (Sadamasashi Artist Defense Average) という指標で定義することにします。端的に、 演奏時間 > トーク になるラインで、さだまさしのコンサートは歌っている時間以外の時間はすべてトークとみなして良いので SADA = 上演時間 / (演奏時間 x 2) と定義します。 SADA が 1 より大きい場合、トークの方が長い、と判断します。

演奏時間は、セットリストに含まれた曲のオリジナル音源の長さを足し合わすことで算出します。
トークの時間は、頼りない数値ですが私の「このツアーはこれくらいの上演時間だったはず」という記憶のもと計算して算出してます。
コロナ(2020年)以後は、基本的に2時間以内に演目がすべて終わるよう計画されていて、結果トークが長引いて2時間15分〜2時間半程度になることが多かった印象です。
それ以前は最大で3時間、短くて2時間半弱くらいの感じでした。

年	曲数	演奏時間	演奏時間x2	上演時間-max (SADA)	上演時間-mid (SADA)	上演時間-min (SADA)
2022	13	66	132	150 (1.14)	135 (1.02)	120 (0.89)
2021	14	63	126	150 (1.19)	135 (1.07)	120 (0.95)
2020	15	80	160	150 (0.94)	135 (0.84)	120 (0.75)
2019	15	85	170	180 (1.06)	162 (0.95)	144 (0.85)
2018	16	84	168	180 (1.07)	162 (0.96)	144 (0.86)

年を重ねるごとに、楽曲の数も、演奏時間も減少してきています。この辺はさすがにさだまさしも年齢を重ねてきているので無理が効かなくなってきているのかな、と感じさせます。
しかし体感的に「コンサートが短くなった」とは感じられず、その要因はトークの時間がそこまで減ってない（むしろ比率は増えている）、ということが挙げられそうで、こうして数値でまとめてみてもその傾向は顕著です。

結果を見るに、「さだまさしは歌っている時間よりトークの方が長い」 という説は、コンサートごとに若干の傾向の差があるので一概には言えないが、近年そうなる可能性は高まっていて、その傾向は加速しています。
そもそも、演奏時間とトークの長さが比率的に同じくらいの水準にある時点で、だいぶAnomalyな事象な気はします。

さだまさしのトークの中では、数十分を超える「大ネタ」と呼ばれるものも披露されます。今回の大ネタが何であるかはここには記載しませんが、ツアーを重ねるごとに内容がブラッシュアップされ洗練させれていく様は、お笑い芸人の単独ライブを見ているかのような趣でした。
コンサートごとにトークにはバージョンが割り振られており、そのバージョニング手法に 「カレンダーバージョニング」 が用いられている事も、エンジニアの方々には知っていてほしい事実です。

Datadog RUM を用いたパフォーマンス監視

Datadog APM と並んで、Datadog RUM についてもかなり有効活用をさせていただきました。 RUM = Real User Monitoring ということで、ユーザーの行動をトラッキングすることができるツールです。

ユーザーの行動をトラッキングしたい画面に datadog-rum.js という JS を埋め込み、ユーザーサイドで起こっている様々なアクティビティをブラウザから Datadog サーバーに送ることで、トラッキングを実現しています。
Datadog APM はシステム内部の状況のトラッキング、Datadog RUM は実際にユーザーサイドで起こっている状況のトラッキング、という形で棲み分けがされています。

<script src="https://www.datadoghq-browser-agent.com/datadog-rum-v4.js" type="text/javascript"></script>
<script>
  window.DD_RUM &&
    window.DD_RUM.init({
      clientToken: '<CLIENT_TOKEN>',
      applicationId: '<APPLICATION_ID>',
      site: '<DATADOG_SITE>',
      //  service: 'my-web-application',
      //  env: 'production',
      //  version: '1.0.0',
      sampleRate: 100,
      premiumSampleRate: 100, // 含まれない場合 - デフォルト 100
      trackInteractions: true,
    })
</script>

RUM によってできることはいくつかあるのですが、会社の中では特に以下について活用しています。

• LCP の値のモニタリング
• セッションリプレイ機能を用いたボトルネックの特定

LCP (Largest Contentful Paint)

LCP はGoogle が 2020 年ころから提唱しはじめた Core Web Vitals の指標のひとつで、Web サイトにリクエストが送られてから大部分の画面の描画が終わるまでの時間を表す指標です。
おおむね2.5秒以内であればOK（GOOD: Green)、4.0秒以上だとパフォーマンスに問題がある（POOR: Red）と判断します。

体感的にストレス無い体験をユーザーに提供できているかどうかの数値として、私の会社の中では技術者以外の人も参考にする指標として活用しています。

Datadog RUM では、Performance Monitoring の画面で　URL ごとの LCP の数値が一覧で確認できるようになっているため、この画面を通してどの画面で問題が起こっているかをひと目で判断できます。 Total Sessions (リクエスト数×所要時間) の数値が大きい順に表示されており、基本的に上に表示されるほどよく使われている重要な URL となります。

上記のデフォルトで用意されている画面も便利なのですが、私の会社では独自のダッシュボードを用意し、バージョンごとにどのように LCP の数値が変化しているかをトラッキングできるようにしています。

諸般事情で縦軸横軸のデータは削っていますが、棒グラフはアクセス数で、色の違いがバージョンの違いを表してます。折れ線グラフがLCPの数値です。グラフの色が変わったタイミングでLCPのトレンドがよい方向に変われば、施策が正しかった、と判断ができるようにしています。

セッションリプレイ

Chrome の DevTools のように、その画面上で読み込んだファイルの種類や、読み込みにかかった時間を時系列で確認することが出来る機能です。
Datadog RUM の場合はサーバー側にデータが蓄積されているので、過去のデータについても後追いで確認でき共有もしやすいため、重宝します。

主に、ユーザーにとって本当に重たい処理は何なのか、というボトルネックの特定にとても役立っています。基本的にサーバーサイド側のボトルネックが理由の大半なのですが、不要なJSファイルの読み込みなどが悪さをしていることなどもあり、網羅的に問題を特定することに有用です。

Datadog RUM は本当に便利なツールでまだまだすべての機能をフル活用できてないので、引き続き組織の中で活用していきたいと思います。

さだまさし、音楽活動50周年。記念日にグレープ再結成記念コンサート開催

さだまさしは、1973年にフォークデュオ「グレープ」でメジャーデビューをしました。その「グレープ」がアマチュア時代に初めてライブ活動をしたのが1972年11月3日ということで、2022年は音楽活動50周年という記念の年になりました。
記念日には神田共立講堂で「グレープ再結成コンサート」も開催されましたし、周年を祝うイベントが来年にかけて引き続き実施される予定です。
さだまさしファンは、しばらく忙しい日々が続きそうですね。

1976年にソロ活動を開始してからもさだまさしは積極的にコンサート活動を続けており、今年の12月1日のコンサートでソロデビューから数えて 「4567回」 目のコンサートを迎えました。ソロミュージシャンのコンサート回数としては二位以下をぶっちぎりで突き放すダントツの一位です。

ここでは、さだまさしの歩んできたコンサートの軌跡を可視化してみたいと思います。
公式サイトに今までのコンサートの履歴が掲載されているため、こちらをデータとして引用し、Google Spreadsheet → Google Map に import して地図上にプロットしてみました。

日本全国くまなく訪れ過ぎていて、日本の都市という都市はすべて埋め尽くされており、さだまさしのたどった道のりがほぼ日本列島の形そのものになっています。現代の伊能忠敬。47都道府県踏破とかそういった次元で語ってはいけないことが伝わってきます。

東京近辺だけ眺めてみてもこの密集度です。

1年あたりどのくらいコンサートを実施しているのかも、グラフにしてみました。
1976年はデビューした年で、10月からの記録。それ以降は、軽く年間100回以上のコンサートを長年こなしてきているのが分かります。最も多い年で1982年の162回。
さだまさしは何故こんなにもコンサートの回数を重ねてきてたのか、極めて明確な理由があるのですがここでは割愛させていただきます。

近年は年のためかコンサートはさすがに減少傾向で、コロナのタイミングでも大きく落ち込みましたが、それでも年間50回以上のコンサートを実施しています。

都道府県ごとのコンサート回数も見てみます。やはり東京が一番で、次いで大阪、愛知、埼玉、千葉、神奈川と続きます。
街の規模を考えると、長崎県と長野県の実施回数が多いです。この辺はさだまさしと縁のある街である、ということが大きいのかなと思います。（長崎：出身地、長野：かつて住んでいた場所）

最近のコンサートツアーの動員数もまとめてみます。各コンサートの動員数は会場の総座席数で近似しています。実際さだまさしのチケットの売れ方を考えると少なく見積もっても9掛けくらいの数字は実際に動員していると思います。

年	ツアー名	公演数	動員数	1公演あたり動員数	補足
2015	風の軌跡	42	90807	2162
2016	月の歌	36	80290	2230
2017	惠百福	40	87726	2193
2018	45周年記念コンサートツアー Reborn 〜生まれたてのさだまさし〜	50	117909	2358
2019	新自分風土記	46	104040	2262
2020	存在理由〜Raison d'être〜	41	90929	2218	※コロナに伴う入場規制のため実際はこの半分位
2021	さだ丼〜新自分風土記Ⅲ〜	37	93342	2523
2022	孤悲	41	98623	2405

45周年ツアーで動員数が跳ね上がり、その数字を維持していた最中にコロナが直撃、という流れです。2020年は会場の総座席数の半分くらいしかチケットを売らなかったので、この年については実動員数は記載の半分くらいと思われます。
それでもここ数年はコロナで落ち込んだコンサートの動員を年々再回復させている段階、という感じです。

いずれにせよ、歳を重ねるごとに、動員数を普通に増やしている、というのが見て取れます。
さだまさしのコンサートのトークで 「今日はじめてさだまさしのコンサートに訪れるという人は拍手を」 というお決まりの下りがあるのですが、毎回相当数の拍手が鳴り響きます。これだけのベテランでありながら、常に新しいユーザーを獲得し続けているからこその数字、だと思います。

こうしてデータをまとめて可視化してみることで様々な事が見えてきますが、あらためてさだまさしはとてつも無い人だな、と痛感させられます。
今後も、どうぞお元気で、多くのファンを魅了するステージをできるだけ長く続けてほしいなと思います。

Datadog で Queue の SLI / SLO を監視

最後のトピックです。
今の会社のシステムでは Queue をシステムバウンダリとした非同期処理を実施していて、重たい処理や大量処理のオフロードを Queue を使って実施しています。サービスの中でもかなり中核なシステムになっています。

Queue については今までも監視はしていたのですが、より個々の処理に対するきめ細かい監視を行うために、SLI / SLO を定めて監視するようにしました。

雑な絵ですが、処理内容に応じて Queue を切り分けていて、Queue ごとに役割が異なり、それぞれに性能要件も異なります。いままでは Queue システム全体に対する監視のみを行っていましたが、各機能ごとに適切な監視をできるようにした、という話です。

SLI

まず、それぞれの Queue に SLI (Service Level Indicator) を設定しました。
この際の指標は、以下にしています。

• 処理遅延時間 (Enqueue されてから Dequeue されるまでの時間)
• 処理滞留件数 (Queue に滞留している Job の件数)

Queue ごとに、どちらの指標が監視ポイントになるか、性能要件が異なるため、各 Queue の実装担当チームと協議をしながら、Indicator の種類と閾値について決めていきました。
その前提として、Queue の細かいメトリクスの取得も必要で、こちらはカスタムメトリクスとして Datadog 上で扱えるようにしています。この説明は割愛します。

定義した SLI に応じて、 Datadog の Monitor 定義を作成します。SLI に定めた値が満たされなかった場合、まず Datadog からアラートが担当者に飛ぶようにしています。

SLO

そして SLO (Service Level Objective)ですが、こちらは Datadog SLO の機能を用いて設定を行っています。

Datadog SLO では SLI を以下の２種から選択できるようになっており、私の会社では上述の通り SLI に従って Monitor の設定を行っているので Monitor ベースで SLO の定義を行っています。

• Metrics Based
• Monitor Based

基本100%がもちろん理想ですが、SLOを設定しておきこれが満たせない場合にシステム拡張などの投資を行う、という判断基準として運用する予定です。
こちらについては運用が始まったばかりなので、今後組織の中でどのように浸透させていくか、引き続き取り組んでいいたいと思います。

監視の仕組み、可視化の仕組みでシステムに貢献する方法は様々あると思いますが、今後も様々なメトリクスをもとに Obserbability 向上施策を執り行っていき、結果としてサービスを使っていただいているユーザーの価値につながればと思っております。

なお、この記事では Obserbability の計測・可視化周りの話だけを書いていますが、SREチームでは各システムのパフォーマンスチューニングのためにSQLチューニングや実装の修正など、サービスの改善に直接貢献するような作業も行っています。最近はQueueの仕組みの抜本改善のため、システムアーキテクチャの変更作業にも取り組んでいます。
システムのリアーキテクチャについては以下のイベントで登壇させていただいていたりしますので、もし興味がある方はこちらもご覧になっていただければと思います。