はてなのシステムプラットフォームチーム (以下シスプラ) で SRE として働いている id:KashEight です。社会人 2 年目です。

この記事は、はてなの SRE が毎月交代で書いているSRE連載の 4 月号です。3 月の記事は id:onk さんのはてなの「PWG」という取り組みを builderscon 2024 で話してきましたです。

この記事では DMARC レポートを自社サービスである Mackerel、オブザーバビリティデータをいい感じに扱うためのプロジェクトである OpenTelemetry を用いて可視化した話の導入編となります。文量の都合上、実際の実装やサービス提供の話は次の SRE 連載に回します。

DMARC、DMARC レポート
今までの運用
- 問題点
Mackerel 化するに至るまで

DMARC、DMARC レポート

まずは DMARC について記載します。おそらく、メールサーバの運用をしてる方々には DMARC の対応に頭を悩ませられた経験が多いのではないでしょうか。はてなでも id:MysticDoll さんが過去に Platform Engineering Meetup #8 や JPAAWG 7th General Meeting に「はてなにおけるメール基盤とDMARC対応」という内容で発表しています。

資料の方でも詳しく説明されていますが、DMARC は RFC 7489 で定義されているメールのなりすまし防止のための仕組みとなっています。既存の仕組みである SPF (RFC 7208)、DKIM (RFC 6376) と組み合わせて使用するため両者の設定は必須となります。詳しい解説をするとこれだけで埋まるので解説は省略します。参考として前述資料やベアメールさんのブログ記事がわかりやすいかと思います。

一方、DMARC レポートは受信側のメールサーバから送信される DMARC での認証結果等を示した XML 形式のレポートとなります。スキーマは RFC の Appendix C で示されており、これに沿って自分たちはレポートを解析して DMARC での認証が成功しているかどうか等を確認することができます。こちらもベアメールさんのブログ記事がわかりやすいです。

今までの運用

はてなの DMARC レポート可視化の仕組みは parsedmarc + OpenSearch + Grafana*1 の構成で行っていました。

ECS 上にデプロイした parsedmarc を用いて DMARC レポートを解析、その解析したデータを OpenSearch に記録、 Grafana ダッシュボードで可視化する構成です。構成図は以下のような感じです:

また、Grafana ダッシュボードの表示は以下のようになります:

問題点

さて、この Grafana ダッシュボードですが以下の問題がありました:

外部のインターネットから接続不可である。
- 利用者がこのダッシュボードを利用する際は、踏み台を通して内部からアクセスをする必要がある。
VPN を繋いだ状態だと踏み台にアクセスできない。
- 踏み台のサーバと VPN は別々のネットワークで構築されているため。
- 加えて、社内のネットワーク構成の問題で VPN からは踏み台のサーバにアクセスできない。
- つまり、Grafana ダッシュボードにアクセスする場合、VPN の接続を切る必要がある。

VPN を繋いだままだと Grafana ダッシュボードにアクセスできない状態であれば、VPN からの通信を許可すればいいのではとなりますが、Grafana ダッシュボードへのアクセスは踏み台サーバを前提としています。そして、前述の VPN からは踏み台のサーバにアクセスできないなどの問題点があるためそれらを解消させる必要があります。

また、これ以外にも以下の問題がありました:

OpenSearch を使っているため定期的なアップデートが必要になる。
- OpenSearch は AWS のマネージドサービスなのでサポート期限がある。
- サポート期限が切れると追加料金が発生するため定期的なメンテナンスコストがかかる。
OpenSearch のアップデートとともに Grafana の動作検証もする必要がある。
- Grafana は OpenSearch のデータを参照しているため、依存関係として密となっている。

以上のような運用の面でも問題点が存在していました。よく Platform Engineering の文脈で話される認知負荷がありますが、今の運用は認知負荷を上昇させる問題を潜在的に持っていました。加えて、シスプラ内ではこの Grafana ダッシュボードは都度あれば対応するぐらいのかなり消極的な運用をしていました*2。

Mackerel 化するに至るまで

以上のような問題点がある状態で Grafana 等は運用されていましたが、すぐに Mackerel 化しようと行動するわけではありませんでした。都度あれば対応するぐらいのかなり消極的な運用だったので、優先度がかなり低く、何かあれば対応する、最悪消えても問題はないぐらいの認識でいました。

とある改善要望

ある日、Slack 上で以下のような改善要望がありました (一部、内容に脚色はしています):

メールの DMARC レポート監視としてシスプラ管理の Grafana ダッシュボードを使用させていただいております (今後も新規でメールを追加することが想定されるため引き続き利用させていただきたいと思っています)。
現在こちらにアクセスするには (内部 URL) でアクセスしているのですが IP 制限が踏み台サーバの IP しか通らなく VPN ではアクセスできない状態です。もし可能であれば、VPN でも接続できるようにしてはいただけないでしょうか…？

先述の問題点であったような、VPN を繋いだままでのアクセスがしたいという内容です。

これ自体は妥当な内容なのですが、そのために踏み台サーバと VPN の接続を行えるように社内ネットワークを見直しをする必要がある等の面倒なところが多く、ぶっちゃけて言うとあんまり実行しようとは思わない内容でした。また、同時にシスプラ内としても積極的にこの可視化サービスが使われているとは思ってもいなかったため、少し戸惑いもありました。

使用用途のヒアリング

一旦、どのように使用しているのかヒアリングを行いました。理由としては以下があります:

どのように、何のために使用しているかわからなかったため。
シスプラ内部でもこのシステムの運用維持に消極的なためできるだけ最小限のコストで対応したい。
- 最悪、無理な場合は無理と言い切る。

そして、ヒアリング結果として以下の 3 つが返ってきました。

新しくメールアドレスを追加した際に DMARC 認証ができているか、SPF や DKIM の設定漏れが無いかをチェックしたい。
DMARC ポリシーを変えたときに問題なく表示できていることを確認したい。
メールが送られてこないといったお問い合わせに対して調査ログの一部として確認したい。

以上の 3 つのうち、最初の 2 つに関しては設定の追加や変更等でちゃんとできているかどうかという過去と現在の比較をしたいというニーズがあることがわかります。そして 3 つ目に関してはデータが保持されていつでも見れる状態というニーズがあることがわかります。

ニーズから考えてみる

ヒアリング結果から 2 つのニーズがあることがわかりました。では、次はそのニーズをどのように達成するかを考えてみます。

単純な考えとしてぱっと思いつくのは以下の 3 つです:

既存の Grafana ダッシュボードに VPN から繋げるようにする
既存の構成を見直して再度新しい構成で Grafana ダッシュボードを再構築する
DMARC レポートを可視化できる外部サービスを利用する

まず、1 は何回か書いたようにネットワークの見直し等が発生するコストが高い方法なので避けたいです。 2 はこの中ではまだマシな方ですが、踏み台のサーバと VPN でのアクセスを両立させるという問題を解決させ、かつ、運用も現在と同等かそれより低い状態にもってこないとやるコストと結果が見合わない状態になってしまいます。 3 に関しては、運用の観点では一番楽ですが、外部サービスを利用する点でセキュリティ的に大丈夫か、そのサービスは信用できるか等の技術以外に考えることが多く、できれば避けたい選択肢です。

どれもぱっとしないので、一旦これらを整理してみます。まず、利用者目線で求めるものは前述の過去と現在の比較とデータが保持されていつでも見れる状態というニーズです。一方で、運用者目線で求めるものは、対応コストの低さと運用コストの低さとなります。それらをできるだけ多く満たす選択をするのがベターと言えるでしょう。

OpenTelemetry と Mackerel のラベル付きメトリック

一旦話は変わりますが、はてなでは社内社外ともに OpenTelemetry の活用を進めております。実際に Mackerel では OpenTelemetry を利用したメトリック投稿ができるようになっています*3。

OpenTelemetry で属性 (attribute) を設定することで Mackerel 側でラベル付きメトリックとして投稿することができます*4 (以下 OpenTelemetry の属性は Mackerel 側の呼称に沿ってラベルと表記します)。このラベル付きメトリックは PromQL というクエリ言語を使うことで柔軟にグラフの表示や数値の表示、アラートの設定が可能となります*5 *6。

さて、少し話を戻して、この機能を実際にレポートの可視化に使えるか考えてみます。前述の利用者目線と運用者目線での計 4 つのニーズから考えてみましょう:

過去と現在の比較 (利用者目線)
- メトリックという性質から時系列データを扱うためそれを応用することは可能そう。
- Grafana での折れ線グラフ表示は移行できそうであり、円グラフは百分率表示で代替できそう。
データが保持されていつでも見れる状態 (利用者目線)
- Mackerel 側で保持されているため、いつでも見ることが可能。
- ラベルがついているため、それらを活用すれば利用者が見たいデータも絞ることも可能。
対応コストの低さ (運用者目線)
- Mackerel に DMARC レポートをラベル付きメトリックという方法で送信する必要がある。
- また、それを実現するための構成も考える必要はある。
運用コストの低さ (運用者目線)
- サービス提供は Mackerel に一存できるため運用は比較的楽に済ませられそう。
- 運用側で見るのは Mackerel へ投稿する部分のみに集中できそう。