Recap 2023

もう2024年だよ。

技術

新しく触ったのはこの辺：

• Prometheus, PromQL
• OpenTelemetry
• GraphQL Server
• Kubernetes

あとはGo言語とかなりお友達になったりAWS SAA認定取ったり。

仕事

グレードが2つ上がった。さよなら新卒ラベル。

エンジニアリングだけではなく物理イベントのお世話もした。イベントオーガナイザーであることもあり音響の技術者であることもありタレントであることもありなので立ち振舞いがむずい。3役はさすがにできない。

ディスカバリーにも関与し始めたところ完全に脳のキャパシティを超えてショートしかかっている状態。瞬発より安定が欲しい。

技術イベント

• 【オンライン登壇】Hatena Engineer Seminar #23「チームとプロダクトを育てる Mackerel 開発合宿」
• 【オフライン登壇】YAPC::Kyoto 2023 前日祭 ネコトーストラボ杯争奪東西対抗LTマッチ「新卒エンジニアが1年間で顔を売るために取った行動100連発」
• 【オンライン登壇】個人開発祭り #2「孤独な個人開発からの脱却: バトグラ技術部への憧憬」
• 【オンライン登壇】第2回 Slack 活用アワード 決勝プレゼン大会「はてなピアスターで生まれるコミュニケーション」
• 【司会】Mackerel Meetup #14 Tokyo
• 【オフライン登壇】Mackerel 徹底使いこなし術 - Mackerel Drink Up #11 Tokyo「仮説検証サイクルでユーザーの声を高速に叶える『キカク組』の取り組み」
• 【当日スタッフ】SRE NEXT 2023
• 【オフライン登壇】PHP Conference Japan 2023「学園祭Web開発の現場とPHPのこれまでとこれから──技術選定と教育から語る」
• 【オフライン登壇】Scalaわいわい勉強会「Scala の好きなところ 難しいところ」
• 【ブース出展】技術書典 15
• 【オフライン登壇】Salesforce World Tour Tokyo「感謝を伝え合う社内Slackアプリ『はてなピアスター』の取り組み」
• 【司会】Mackerel Meetup #15 Tokyo

各詳細は僕がまとめたものより以下の記事に詳しい：

developer.hatenastaff.com

ほか、Mackerel Drink Upにはほぼ顔を出していたし、OpenTelemetry MeetupやPepabo Tech Conferenceなど参加者として行ったイベントもいくつか。ISUCONにも出た。

旅行

京都に6回、大阪に3回行ったらしい。

あとはポケモン世界大会関連で横浜市街に出かけたけど、僕自身横浜市民なので旅行と呼んでいいのか。

ファッション

7年ぶりに金髪に戻った。

ネイルサロンにも行き始めた。指を使う仕事なのでテンション上がるオススメです。

服は下着以外ほぼ買ってない。コスプレも今年はやらなかった。

買い物

blog.arthur1.dev

住居

変化なし。

満員電車が苦痛なので2024年は山手線の内側に引っ越すかもしれない。でも今の家コスパ半端ないので引っ越さないかもしれない。

テーブルゲーム

新規開拓した中重量級ゲームはこの辺り：

• ブラス・バーミンガム
• アーク・ノヴァ

ポケモンカードはついにPTCGO・PTCGLではなくリアルでやるようになった。これが2023年の自分の変化で一番デカいまである。

音楽制作

個人名義では全くしなかった。アレンジは少々。

恋愛

void。27歳になったらアイドル辞められると思ってた。

音楽鑑賞

これはまたどこかでブログを書く予定。取り急ぎ、個人的に今年1番だと思う楽曲はこれでした：

www.youtube.com

以下思い出アルバムコーナー

WCS Yokohama、街としての盛り上がり最高でしたね

yakudoかぜよみ

最後？の工大祭

リアルイベントでたくさんお話しました

買ってよかったもの2023

2023年もけっこういい買い物したな〜の記録

マイク SHURE SM7B

買ってよかった: ★★★★☆ (4/5)

今年はトータル8件も登壇していて、うちリモート開催のものもいくつかありました。良い声で聞いてもらえるように良いマイクを買いました。満足はしているんですがちょっと控えめな点数なのは、SM7dBというプリアンプ内蔵の後継機種が今年登場してしまったからですね。どうせ買うならこっちがよかった。

SHURE シュア ダイナミックマイク SM7B カーディオイド 単一指向性 XLR 有線 ノイズ除去 配信 ストリーミング 録音 YouTube レコーディング 実況 ゲーム ゲーミング ボーカル ポッドキャスト DTM 宅録 テレワーク【国内正規品/メーカー保証2年】

マイクアーム Logicool Blue Compass

買ってよかった: ★★★☆☆ (3/5)

SM7Bを支えるためのマイクアームです。普通に使えるので3点はあるけど気になりポイントがいくつか：

• しっかりしすぎていて見た目がごつい
• 設置方向によってBlueというあんまりかっこよくないロゴがデカデカとWebカメラに映り込んでしまう
• 自分の机が大きすぎるからかアームを最大限伸ばす必要があり、するとSM7Bの重さに耐えきれずマイクが下がり気味になる
• キャノンケーブルのコネクタとマイクアームの丸い出っ張りが干渉する

ロジクール G Blue Compass マイクスタンド マイクアーム BA100CBK 国内正規品 2年間メーカー保証

オーディオインタフェース YAMAHA AG08

買ってよかった: ★★★★☆ (4/5)

まさにこういう（PCに複数の音声デバイスとして登録され、アプリごと物理フェーダーを割り当てられる）デバイスが欲しいとずっと前から言い続けてきたので本当に嬉しいです！！！めちゃくちゃ便利なのでストリーマーの皆さんぜひ買いましょう。

星5ではない理由は、macOSのドライバが不安定で僕の環境ではよくOSがpanicを起こすこと、そして最新のmacOS Sonomaにまだ対応していないことです。Windowsで使う分には特に困ってません。音仕事はmacですることが多いのでレコーディングに使うにはpanicちょっと怖いかなあ。

ヤマハ YAMAHA ライブストリーミングミキサー ライブ配信 8チャンネル ボイスチェンジャー内蔵 ブラック AG08 B

スマートフォン Google Pixel 7a

買ってよかった: ★★★★☆ (4/5)

AirDrop便利そうだな〜と横目に見つつ頑なにAndroidを使っています。不満点は電池の持ちがそこまでよくないことぐらい。特に感動体験もないけど安くて動作が安定しているだけで日用道具としては十分でしょう。

store.google.com

キーボード Logicool KX850FT MX MECHANICAL

買ってよかった: ★★★★☆ (4/5)

MXシリーズ待望のメカニカルキーボードです！自分はこれのUS配列バージョンを海外から輸入して使っています。US配列のものも日本のLogicoolブランドで扱ってくれれば良いのですが。これまでのMXシリーズよりゲームでも使いやすくなって最高です。

macOSでもWindowsでも使えるのも魅力なのですが、結局macOSでクラムシェルする際にはTouch IDが使えるMagic Keyboard一択だなと思っており、そこまで重要視しなくてもいいかなと考えつつあります。

なぜかキーキャップが1つすぐ壊れてしまった（かつ破片が穴に詰まったままでキャップ交換も不可）ので星4です。あんまり使わないキーだったから耐えてます。

ロジクール KX850FT MX MECHANICAL ワイヤレス メカニカル パフォーマンス キーボード 茶軸 タクタイル テンキー 静かな打鍵感 特に静か Logi Bolt bluetooth Unifying非対応 薄型 無線 windows mac chrome Android KX850 国内正規品 グラファイト

Webカメラ Logicool Brio C1000s

買ってよかった: ★★★★★ (5/5)

Windows Helloで顔認証でPC開けるの超便利ですね。これだけで価値があります。認証の精度も悪くないと思います。macOSでも顔認証できたらわざわざMagic Keyboard買わなくて済むのですが……これはOSの問題なので仕方なし。

4K撮影もできるのですが、ビデオチャットツールの限界が大体1080pなのと、USB2.0の速度までしか出ないハブ経由で使っているので帯域が足りず試していません。だったら顔認証対応してるWebカメラがELECOMからもっと安く出ているのでそれでよかったのでは？でも4Kはロマン。

ロジクール Webカメラ Brio C1000s Ultra 4K HD 60fps オートフォーカス HDR 対応 プライバシーシャッタ― 自動光補正 ノイズキャンセリング マイク プラグアンドプレイ Windows Hello 対応 ウェブカメラ ウェブカム PC Mac ノートパソコン Zoom Skype 国内正規品

寝袋 Bears Rock ねぶくろん

買ってよかった: ★★★★★ (5/5)

これまで友達が泊まりにきた時にペラッペラの寝袋を貸していたのですが、流石にかわいそうになってきたのでいいやつを買いました。自分でも試しに使ってみたのですが、あったかいし寝心地が良いです。

Bears Rock ベアーズロック ねぶくろん 来客用 布団セット コンパクト 寝袋 TX-701 チョコブラウン

Mackerelのカスタムダッシュボードにグラフアノテーションを表示する機能は如何にして生まれたか

arthur-1 Mackerel Advent Calendar 2023 マラソン25日目の記事です。いよいよラストのエントリとなりましたが、特別なことは書かずにこれまでと同じ調子で書きます。

カスタムダッシュボードにグラフアノテーションを表示できるようになりました！

blog.arthur1.dev

上記エントリで頭だしはしていたのですが、カスタムダッシュボードにグラフアノテーションを表示する機能がリリースされました。（Mackerel公式の告知は追ってされると思います。フライングしてすみません。）

今回はMackerelの仮説検証アジャイル開発のMVP（Minimum Viable Product）として実装したこの機能について、どのような思考を経て生まれたのかをご紹介します。

いくつかの機能パターン

Mackerelにはグラフアノテーションという機能があるのですが、これはサービス・ロールグラフの全画面表示やサービス詳細ページでのみ表示・編集ができるものの、カスタムダッシュボードでは表示すらできない状態でした。素早く価値を届けてユーザーの反応を伺うために、編集のことを考えつつもまずは表示だけできる状態でリリースすることを決めました。

表示だけとはいえ、いくつかの機能パターンが考えられます。

• 全てのグラフウィジェットに対応させるorサービス・ロールグラフだけ対応させる
• カスタムダッシュボード全体に設定を持つorウィジェットごと設定を持つ
• 1つのサービス・ロールを指定できるor複数のサービス・ロールを指定できる
• 設定を永続化するor設定を永続化しない

今回MVPとして以下のような仕様でリリースしました

• 全てのグラフウィジェットに対応させるorサービス・ロールグラフだけ対応させる
• カスタムダッシュボード全体に設定を持つorウィジェットごと設定を持つ
• 1つのサービス・ロールを指定できるor複数のサービス・ロールを指定できる
• 設定を永続化するor設定を永続化しない

全てのグラフウィジェットに対応する理由

MVPとして、サービスやロールグラフのグラフウィジェットにのみ、それぞれ対応するアノテーションを表示すれば良いという考えもありましたが、棄却しました。これは単純に、ホストグラフや式グラフ・としてラベル対応メトリックのPromQLグラフでグラフアノテーションを表示できないのは不便だと考えたからです。未来のMackerelを想像したときに、新機能であるPromQLグラフのことは見据えておきたいです。

サービス・ロールグラフ以外はサービス・ロールに紐づけるための情報がないため、ユーザーがどのサービス・ロールのグラフアノテーションを表示するかを設定する必要があります。サービス・ロールグラフ以外のウィジェットだけそのように外から指定できるようにしても良いのですが、機能が複雑になると感じました。そこで、全てのグラフウィジェットの種類で統一で、グラフアノテーションを表示したいならサービスやロールを指定する必要があるというインタフェースにしました。

1つだけしかサービス・ロールだけを指定できない理由

将来的にカスタムダッシュボードの画面上からもグラフアノテーションを追加したり編集できたりするようにしたいです。ところが、Mackerelの既存のUIではサービスやロールが1つに定まっていることが前提のデザインになっています。

サービスやロールは選択できず、サービスとロールどちらに紐づけるかのトグルスイッチのみ

新しいUIを作らなければ追加や編集の機能提供ができず時間を要すること、また、仮にたくさんのサービスやロールに紐づくグラフアノテーションを表示したとしても、色分けなどで区別できるようにしたいなど表示においてもデザイン上の懸念があることから、単一のサービス・ロールのみを指定してグラフアノテーションを表示する機能としました。

カスタムダッシュボード全体に設定を持つ理由&設定を永続化しない理由

どのサービス・ロールのグラフアノテーションを表示するかという設定をグラフウィジェットごと個別に持つ方法で提供したいと最初は考えていました。なぜなら、同じダッシュボード上に複数のサービスやロールのグラフを表示するユースケースは多く存在するからです。その場合、ウィジェットの定義に含めることになるので自然と設定が永続化されます。

しかし、1つだけしかサービス・ロールだけを指定できない仕様との相性が悪いと考えました。サービス同士に依存関係がある場合があるため、複数のサービス・ロールを指定したり、あるいは1つしか指定できなくても切り替えたりできるようにしたいです。しかし、前述した通り複数のサービス・ロールを指定しない機能とすることに決めたので、表示する対象のサービス・ロールをスムーズに切り替えられるようにする必要があります。

ウィジェットごと設定を持ってしまうと切り替えが困難になるため、ダッシュボード全体に設定を持ち、これをダッシュボードのヘッダーから簡単に切り替えられるようにしました。

また、デフォルトで特定のサービス・ロールのグラフアノテーションが表示されている状態でダッシュボードを開くことができるよう、この状態をURLのクエリパラメータに持つようにしました。

まとめ

Mackerelの仮説検証アジャイル開発は素早くユーザーに価値ある機能を提供することを目指しています。今回の機能は「素早く」と「価値ある」の両立ができるように、さらにOpenTelemetry（ラベル対応メトリック）が中心となる世界でも通用する機能となるように熟考して作られました。

今後はユーザーの皆さまの反応を見ながらさらに1ステップ進めていくことになります。このUXの延長で編集する機能を追加するかもしれないし、やっぱりウィジェットの設定としてどのサービス・ロールのアノテーションを表示するかを持つ機能にシフトチェンジするかもしれません。また、サービス・ロールを選択するときに、そこにすでにグラフアノテーションが投稿されているかが分かると嬉しいというアイデアもあります。

ぜひMackerelのイベントやSNSなどで本機能について意見をお寄せください！

Mackerel Slackアプリを雑に作ってみる: unfurl編

arthur-1 Mackerel Advent Calendar 2023 マラソン24日目・およびSlack Japan Champions Network (JCN) アドベントカレンダー 2023 24日目の記事です。

MackerelとSlackのインテグレーション

Mackerelの通知チャンネルとして、Slackを選択することができます。これはIncoming WebhookのURLを設定する方式になっており、Mackerelでアラート発報などのイベントが起こるとSlackのWebhookにリクエストを送り、結果としてメッセージが投稿されます。

これでも十分便利なのですが、Slackアプリとして提供するともっと良い体験ができるはずだと思っています。例えば、

• ＊Mackerelのリンクが貼られたらその情報を展開する
• Slack上でアラートを閉じられる
• アラートの状況が変化したらSlackの投稿も変化する
• 同じアラートに関する通知が1つのスレッドにまとまる

などのことができるようになるでしょう。

今回はお試しとして、「＊Mackerelのリンクが貼られたらその情報を展開する」が実現できるSlackアプリを作っていきましょう。

リンクの展開

SlackにURLが貼られたとき、その下にサイトの情報が表示されることがあります。これをリンクの展開（unfurling）と呼びます。

基本はSlackのクローラーかアプリがリクエストを投げて取ってくるのでパブリックなサイトでしか表示できないのですが、Slackアプリを使うとプライベートなサイトのリンクに対しても展開することができるようになります。

api.slack.com

この機能を用いて、Mackerelのアラートのリンクが貼られた時にその情報を展開するようなSlackアプリを作ります。

できたもの

Mackerelのアラートリンクを貼ると展開してくれるSlackアプリが以下のようにできました。

ソースコードはGitHubの以下のリポジトリに掲載しています。

github.com

コードの解説

Slackアプリが簡単に作れるBolt for Javascriptフレームワークを用いています。Slackにリンクが貼られたときのイベントをハンドリングするには以下のような関数を作ります。

app.event("link_shared", async ({ event, client, logger }) => {
  // ここにリンクが貼られたときの処理を書く
})

event.linksの中にURLの情報が入っているので、これをパースしてMackerelのアラートのURLかを判定します。MackerelのアラートURLであればURLの最後のパスはアラートIDなので、これを取り出してMackerelのAPIのアラート取得エンドポイントにリクエストを投げます。

const url = new URL(link.url);
const paths = url.pathname.split("/");
const res = await fetch(
  `https://api.mackerelio.com/api/v0/alerts/${paths[4]}`,
  {
    headers: {
      "X-Api-Key": process.env.MACKEREL_API_KEY ?? "",
    },
  }
);
const alert = await res.json();

あとはSlackのchat.unfurl APIにリクエストするclient methhodを呼び出し、先ほど取得したアラート情報から組み立てたLinkUnfurlsというオブジェクトや、情報を付与したい投稿のID（ts: タイムスタンプ）やチャンネルIDを渡します。

const unfurls: LinkUnfurls = {
  [link.url]: {
    blocks: [
      {
        type: "section",
        text: {
          type: "mrkdwn",
          text: alert.status,
        },
      },
    ],
  },
};
client.chat.unfurl({
  ts: event.message_ts,
  channel: event.channel,
  unfurls: unfurls,
});

これでアプリケーションとしては完成ですが、Slack Appとして動かすにはSlack側での設定も必要です。Slackアプリのmanifestファイルを以下に掲載しておきます。

display_information:
  name: Mackerel
features:
  bot_user:
    display_name: Mackerel
    always_online: false
  unfurl_domains:
    - mackerel.io
oauth_config:
  scopes:
    bot:
      - links:read
      - links:write
settings:
  event_subscriptions:
    request_url: ***your_request_url***
    bot_events:
      - link_shared
  org_deploy_enabled: false
  socket_mode_enabled: false
  token_rotation_enabled: false

ポイントはlink_sharedイベントを購読する際にはunfurl_domainsの指定が必要なことです。今回はMackerelのドメインだけを引っ掛けてイベントを送信するようにmackerel.ioと指定しました。

最後に

このようにSlackアプリは簡単に作ることができます。このソースコードを育てて機能を増やすとともに、最終的には認証認可周りも頑張って、ユーザーが各自のワークスペースにインストールするものとして仕上げられたら良いなと思っています。

仮説検証サイクルでユーザーの声を高速に叶える「キカク組」の取り組み

arthur-1 Mackerel Advent Calendar 2023 マラソン23日目の記事です。

「キカク組」の取り組みをMackerel Drink Upでお話ししました

2023年9月26日に行われたMackerel Drink Up #11で、私 id:arthur-1 が本エントリタイトルと同じ「仮説検証サイクルでユーザーの声を高速に叶える『キカク組』の取り組み」という題で発表させていただきました。

speakerdeck.com

本エントリはこの発表を少しアップデートした上でブログにまとめたものになります。

Mackerel開発の課題

現在、MackerelチームではOpenTelemetry対応とSAML対応という2本の大きな開発を進めています。チーム内の多くのエンジニアがこちらの大型開発に携わっています。そのため、ユーザーの要望やdogfoodingから生まれた既存の他の課題を解決するためのリソースが限られてしまっている状況です。

エンジニアリソースが限られているからといって、Mackerelの小さな進化を停滞させることはできません。この状況では、様々な課題に対してどの優先順位で取り組み何を作るのかという判断がよりシビアになってきます。やれることが限られているからこそ、何をするかが大事になってくるということです。

これまでMackerelチームにはどんな施策を優先すべきかという数値指標がなく、プロダクトオーナーの判断やそれをサポートするメンバーの助言によって優先順位が決められていました。プロダクトオーナーが単一障害点になる（視座が固定され得る）ことが、何をするかという選択がより重要となる状況において問題になりました。

また、課題を解決するためにとても大きなものを作ろうとするとリリースが停滞してしまいます。開発サイクルでエンジニアが自信を持ってモノづくりに集中できるよう、ディスカバリーの時点で小さく作れる確度の高いネタになっていて欲しいです。

キカク組の始動

ユーザーに価値ある機能を素早く届けることを目指したユニットとして「キカク組」が発足しました。これはエンジニアだけでなくディレクター・プランナー・CRE・セールスなども所属する職種混合ユニットです。仮説検証型アジャイル開発という手法を取り、価値探索とアジャイル開発のサイクルを回し続けています。

正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

価値探索のサイクルでは、要望やすでにリリースした施策の検証結果などをもとにまず仮説を立てます。その仮説の論理的整合性や実現手段の妥当性などを検証・評価して、MVP（Minimal Viable Product）というニーズを満たす最小のプロダクトを特定します。

1つ仮説検証をするにも時間がかかりますから、どのネタから手をつけ始めるかという優先順位としてRICEという指標を導入しました。

www.intercom.com

開発のサイクルでは小さく回しMVPを素早くリリースしてユーザーの反応を伺い、その後の検証に利用します。また、ユーザーの利用状況を検証の材料とすることがよくあるので、利用状況が観測可能な状態にすることも開発の完了条件の1つに盛り込んでいます。

キカク組のエンジニアは何をするのか

キカク組のエンジニアは仮説検証とアジャイル開発両方のサイクルに深く関与しています。

仮説検証のサイクルでは、エンジニア自身もMackerelの利用者であるという目線を活かし、1ユーザーとして企画を持ち込んだり、立案されたソリューションが本当に課題を解決するのか、あるいはMVPとして過大ではないかなどを検査したりしています。

アジャイル開発のサイクルでは、あらゆる技術領域に触れて実際にアイデアをカタチにしています。また、エンジニアでないと設計できないAPIのインタフェースを考えたり、ドキュメントを書いたりしています。さらに、リリースしたモノの利用状況を観測可能にするための実装やデータ基盤への改修も行っています。最近は手戻りを少なくするためにモブプログラミングもはじめました。

半年の振り返り

私はおよそ半年間キカク組エンジニアとして走り続けてきました。率直に言ってとても大変でした。自分がエンジニアとして開発するのはもちろん、ディスカバリーにおいても既存の枠組みから外れて突拍子もないアイデアを考えるのが得意なので、常に両方のサイクルのために頭をフル回転させている状態でした。議論においても「本当にこれでいいんですか？」と声を上げるのは自分が多かった気がします。

開発において検証に使うデータを収集する実装の整備を行ったり、開発を効率化させるためにCIを整えたりしたのは今後にも繋がる良い投資ができたと思っています。ディスカバリーの方でも継続してサイクルを回せるようにしていきたく、例えば特定の個人に依存しないようスキルやナレッジを継承していきたいものです。

来年以降も私はキカク組エンジニアでい続けることになると思います。ユーザーのみなさまにはMackerelのイベント・SNS・CREとのコミュニケーションなどでぜひフィードバックをお寄せくださいますようお願いいたします。私個人に伝えてくださっても構いません。仮説検証においてユーザーの声をとても参考にしています。来年はユーザーの皆さまとのミーティングにも我々キカク組開発エンジニアが同席してお話しできたらと考えています。

25日目のエントリとして、キカク組がMVPとして作りリリースしたとある機能に関する記事を書こうと思います。こちらもお楽しみに。

Mackerelのメトリックと集約

arthur-1 Mackerel Advent Calendar 2023 マラソン22日目の記事です。

メトリックの時間方向の集約

Mackerelのグラフは表示範囲を広くしていくとメトリックの粒度がどんどん荒くなっていきます。これは、Mackerel内製の時系列データベースが、周囲の点の平均を取ることで点の数を間引いていることによって起こります。以後、このように時間方向に点を間引く操作を集約（aggregation）と呼びます。

集約はどうして行われるのでしょうか。

ひとつは大域的な変化に着目しやすくするためです。表示範囲を広くしてグラフを見ているとき、1分単位の細かな変動よりも大域的な変動に着目したいはずです。1分単位でグラフを描画するとグラフがギザギザしてしまい、本来着目したい変化がわかりづらくなってしまうことがあります。

二つ目の理由に、通信量の最適化が挙げられます。点を間引きたいだけならクライアントであるWebコンソール側で行えば良いのですが、時系列データベース上ですでに間引いたものをユーザーに返しています。必要のない点をレスポンスに載せないことで、通信にかかる時間や大量のデータをクライアントで処理する時間が減り、結果として高速にグラフを描画することができます。

また、Mackerelの時系列データベースでは集約した結果をメモ化しておくことにより、表示範囲が広くなっても高速にグラフを描画できるようにしています。例えば1か月（30日）間のグラフを表示するには1系列あたり最大で43,200個の点が必要です。これをリクエストの度に集計して100個ほどに間引くのは計算コストが大きいため、あらかじめ特定の粒度に間引いたものをストレージに保管しています。ある程度古いメトリックがもう更新され得ないことを利用したテクニックです。

そもそも投稿時からすでに集約されている

この集約はDiamond上だけで行っているように見えるものの、実際にはユーザーがメトリックを投稿する際に似た操作を自然と行っています。この文脈においてはサンプリングという言葉を用いた方がわかりやすいかもしれません。

mackerel-agentは1分間に一度システムメトリックを取得してMackerelに投稿しています。これらのメトリック（の源泉となる値）は実際には連続した時系列データと捉えることができ、その濃度（cardinality）は連続体濃度になります。平たく言えば数えられないほど無限に点が存在するということですね。しかし、無限回数システムメトリックを取得することはいろんな意味で不可能だしする理由もないでしょう。そこで、一定の間隔で計測することで間引いているというわけです。本来であればここでサンプリング定理などに触れるべきだし、数学的にはもっと厳密な表現をしたいところですが、主題ではないのでこの程度にしておきましょう。

Mackerelの仕様上メトリックの最小粒度は1分であることから、1分よりも細かいメトリックを1分単位のメトリックに集約してから投稿するのはユーザーの責務になります。この話題としては、cloudwatch-logs-aggregatorを用いた手法を過去にご紹介しました。

blog.arthur1.dev

Mackerel上での集約は平均だけであることに注意

ユーザーがMackerelに投稿するためにどのような集約方法を用いたとしても、Mackerelのグラフを描画するために行われる集約方法は平均のみです。これを意識せずにグラフを閲覧すると、思わぬ誤解を生んでしまう可能性があります。

一番分かりやすいのは何らかの（分単位の）実行数をグラフで閲覧しているケースです。

これはmackerel-plugin-mysqlを用いて計測したクエリの実行数のグラフです。これは2日間粒度のグラフになっています。

このグラフを見てSelectクエリが2日間で70回ほど実行されていると思った方は要注意！これは分単位で数えられたものの平均値なので、「この時刻のあたりでは1分あたり70回ほどのSelectクエリが実行されている」と読み解くのが正しいです。もし2日間でどれほどのクエリが実行されているかが知りたければ、毎分メトリックを投稿しているなら掛け算をすると良いでしょう。2日間/1分=2880なので、2880倍してあげると2日間で実行されたSelectクエリの数が20万ほどと概算でわかります。

システムメトリックは平均で構わないが

mackerel-agentがシステムメトリックだけをMackerelに投稿するような時代には時系列データベース上の集約が平均だけで良かったのですが、先ほどの例のように平均ではなく合計を集約に用いたいケースが現代にはたくさん存在します。他にもレイテンシの集約のためなどに最大・最小あたりは欲しいです。

前述の通り、Mackerelは1分単位より細かいメトリックを受け付けられないので、ユーザーの責務で1分単位に集約する必要があります。この集約の方法に合わせてMackerel上の集約方法も選択できるようになる未来にしたいなと思っています。最初に紹介した時系列データベースのメモ化の仕様上、この夢を実現するためにはやることがたくさんあって大変なのですが……

Argo CDでSyncが完了したらMackerelのグラフアノテーションに記録する（告知もあるよ！）

arthur-1 Mackerel Advent Calendar 2023 マラソン21日目の記事です。しばらく1日ずつ遅れますがよろしくお願いします。

Argo CDでdeployした記録をMackerelに残したい！

Argo CDとは、KubernetesでGitOpsを実現する継続的デリバリーツールです。Gitのリモートリポジトリに更新があったら自動でKubernetesクラスタにapplyすることができます。

manifestがapplyされるということは、基本的になんらかのアプリケーションをデプロイするタイミングだと思います。このバイナリプッシュは障害を起こす主な要因の一つです。

監視サービスにおいて、いつデプロイしたかの情報を紐づけてグラフを閲覧できるというのは大事な機能です。Mackerelにはグラフアノテーションという機能があり、グラフ上に時刻と紐づけてメモを残すことができます。

今回はArgo CDでSyncが完了したら、その時刻でグラフアノテーションに書き込み、デプロイイベントとグラフを紐づけて描画できるようなものを作っていきます。

Argo CDのResource Hooksが使える

Argo CDにはResource Hooksという機能があります。同期の前や後にコンテナを動かしてスクリプトを動かすことができるものです。

argo-cd.readthedocs.io

まさに今回やりたいことにぴったりな機能です。今回であれば、HooksのうちPostSync（Syncが完了したら動く）という種類のものを使えばよさそうです。

さらに、MackerelのCLIツールであるmkrは公式で軽量なコンテナイメージを配布しています。mkr annotationsコマンドで以下のようにしてグラフアノテーションを作ることができます。

mkr annotations create --title "synced!!" -s mackerel-service-name -r mackerel-role-name --from $(date +%s) --to $(date +%s)

最低限5つのオプションがあれば動かせます。--titleでグラフアノテーションの見出しを設定できます。-s や -r オプションで、グラフアノテーションを記録する先の（Mackerelの）サービスやロールを指定しましょう。また、--from --toにUNIX秒を入れることで時間範囲を指定できます。

これを組み合わせることで、Sync起因でmkrを動かしグラフアノテーションを書き込むことができそうですね。では早速Resource Hooksのmanifestを書いていきましょう。

manifests/iot-monitor/mackerel-sesame/postsync.yml

apiVersion: batch/v1
kind: Job
metadata:
  generateName: mackerel-sesame-deploy-annotation-
  annotations:
    argocd.argoproj.io/hook: PostSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: mkr-create-annotation
          image: docker.io/mackerel/mkr:latest
          env:
            - name: MACKEREL_APIKEY
              valueFrom:
                secretKeyRef:
                  name: mackerel-arthur-1
                  key: apikey
          command: ["sh", "-c"]
          args:
            - |
              mkr annotations create --title "synced mackerel-sesame" \
              -s iot-monitor -r mackerel-sesame \
              --from $(date +%s) --to $(date +%s)
      restartPolicy: Never

以上のようなmanifestをpushしてArgo CDでSyncすると、以下のようにSync駆動でグラフアノテーションを書き込むことができました！

デプロイ起因でシステムメトリックが少し跳ねている様子が観察できますね。グラフアノテーション機能はデプロイイベントを記録する場所として非常に便利なのでぜひ使ってみてください。

最後に

ところで、先ほどのスクリーンショットを見て既存のMackerelユーザーのみなさんは違和感を持った方もいるのではないでしょうか。気づいた人はいますぐカスタムダッシュボードのメニューバーをチェック！！！