irumo のギガを Mackerel で監視する

この記事は Mackerel Advent Calendar 2024 の 9 日目の記事です。

普段使いのモバイル回線は docomo というか irumo なんですが、自宅から離れて生活するとギガを使い切って買い足す日々を送っています。

11 月は 3 GB 買い足した

データ通信量ってなんか上手いことアラート出せないですよね。2GB 使った後に「使ってるよ」って言われても困る。というわけで Mackerel で監視するようにしました。

まずはブラウザから https://irumo.docomo.ne.jp/ を触って Developer Tools の Network タブを眺める。

日ごとの数字が入っていそうな JSON 発見

https://irumo.docomo.ne.jp/api/uw/tra/v1.0/getdatareferenceinf への POST で JSON が返ってきているっぽいのが分かったので、リクエストヘッダをどこまで削っても取れるかを試す。

今回は spsp Cookie だけ渡せば動くっぽかったです。

curl 'https://irumo.docomo.ne.jp/api/uw/tra/v1.0/getdatareferenceinf' \
-H 'User-Agent: DataUsageCheckerBot/1.0 (@onk)' \
-H 'Cookie: spsp=xxxxxxxx' \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-raw 'requestpatterncode=0009&getuser_div=3'

{
  ...
  "data": {
    ...
    "daydatainfo": {
      ...
      "dayusedatainfo_list": [
        {
          "targetdate": "20241201",
          "daydatadetailinfo": {
            "databypacket": "973737",
            "databygb": "0.93",
            "speedlimitreleasecount": "0"
          },
          "speedlimitreleasecountinfo": {
            "databypacket": "0",
            "databygb": "0.00"
          },
          "highspeeddatainfo": {
            "databypacket": "973737",
            "databygb": "0.93"
          }
        },
        ...

各日のデータに speedlimitreleasecount として買い足した回数が入ってるのがちょっと面白い。highspeeddatainfo と speedlimitreleasecountinfo はそれぞれ通常時と速度制限時で使った通信量ですね。

JSON が取れたらあとは加工して Mackerel に送れば完成しそう！

値を取るのは jq でエイってやります。

... | jq -r '
.data.daydatainfo.dayusedatainfo_list[] |
 select(.targetdate | test("20241201")) |
 .daydatadetailinfo.databypacket'

973737

それっぽい数字が取れたので送信用にちょっと加工。

まずハードコードして試していた test("20241201") の部分は外から --arg today $(date '+%Y%m%d') と渡します。

また、Mackerel 向けに投げるならタブ区切りの文字列にしたいですよね。+ で文字列と繋げられるし、now で現在時刻を錬成できるので、全体はこうなります。

... | jq -r --arg today $(date '+%Y%m%d') '
.data.daydatainfo.dayusedatainfo_list[] |
 select(.targetdate | test($today)) |
 "custom.irumo.data-usage\t" + .daydatadetailinfo.databypacket + "\t" + (now | floor | tostring)'

custom.irumo.data-usage 908991  1733754915

あとは mkr throw で投げて完成です。

... | mkr throw --service irumo

グラフができました

データが溜まったら線形回帰関数を使ってアラートを投げたりして遊びましょう。身の回りのメトリックっぽいデータはとりあえず Mackerel に投げておくと、そのうち使い道を思いつくものです。

Mackerel Advent Calendar 2024、明日は id:taxintt さんです。

コミュニティ生活で大切な三つの袋

これは はてなエンジニア Advent Calendar 2024 の 3 日目の記事です。昨日は id:todays_mitsui による 不動点コンビネータで無名再帰を作る流れをおさらい with JavaScript - 無駄と文化 でした。

さて、オフライン回帰している昨今、In-Person でのコミュニティ活動や大規模カンファレンスがだいぶ復活してきました。少なくとも私の周り (京都) では In-Person イベントがデフォルトに戻ったなぁと思っています。そんなコミュニティ生活で、学びや繋がりを深めるためにはちょっとした「コツ」があります。そのコツを、三つの袋に例えてみました。

ノベルティ袋

最初の袋は「ノベルティ袋」です。これは自分の存在を認知して貰うための袋です。

コミュニティ活動では、たくさんの人と出会いますが、後日「見たことはある気がするんだけど」となりがちですよね。ここで活躍するのが、ステッカー類です。

例えば自分のアイコンのステッカーや、ちょっとユーモアの効いた名刺などを配ると、それが記憶に残って次回も話しかけて貰えたりします。先日もこんな話を見かけました。コミュニティの性質を感じて面白いですね。

あるいは自社のノベルティも効果的です。「あっこれ前貰った！」と覚えてくれる可能性が高まります。

ステッカーを貰って困るという人も多いかもしれませんが、カンファレンスでのノベルティ類はカンファレンスや年ごとにクリアファイルにまとめて取っておくと、数年後に見返したときに時代を感じて面白いですよ。毎回処遇に困っている方はぜひやってみてください。

ノベルティ袋、ぜひみなさんも準備していきましょう。自分の存在感を強める武器になります。

胃袋

次は「胃袋」です。これは特に遠方でのカンファレンスで重要です。

遠方開催の場合、たいていの人が小旅行として泊まりがけで参加します。そういう場だと、懇親会も一次会、二次会、そして三次会まで続くことも珍しくありません。懇親会の最初の方はどうしてもフォーマルな雰囲気が残っていますが、時間が進むにつれてお互いに打ち解け、本音や深い話が出てくるものです。それを味わえるのが三次会などの深夜の時間帯です。

特に「同じ時間を共有する」というのが良いのでしょう。懇親会の後半になってリラックスした時間、本音が漏れてくるような時間帯は、ただの情報共有ではなく心の距離を縮める時間になります。単なる単純接触効果を超えた効果がここにある気がしています。

同じ時間を共有した結果、朝帰りになったことで「戦友」という肩書きが増えていくのも、グッと絆を深めるポイントです。

もちろん全員にすべての会に参加しろというわけではありません。健康第一です。でも、たまには「今日は締めのラーメンまで付き合うぞ」と覚悟を決めてみるのもいいものです。そのようにして生まれた絆や信頼関係はかけがえのないものになるはずです。

命を削って参加してますからね。

胃袋をしっかり鍛えて、楽しみながら会話を重ねて、信頼関係を構築していきましょう。

パッチ袋

最後は「パッチ袋」です。

コミュニティに初めて参加するときに、自分から積極的に自己紹介するのは難しいかもしれません。でもコードを GitHub にアップしておくことで、自然とコミュニティの一員になれます。

先日 Kaigi on Rails 2024 に参加した際、以前 sinatra-activerecord gem に Pull Request を数件出していたことで @cupnoodle (現 sinatra-activerecord のメンテナ) から話しかけて貰えました。この出来事自体は 3 年前の Pull Request に言及してくれるという、ちょっと本当に凄すぎるエピソードなんですが、こういうこともあるんですよ。いや本当にビックリした。

先ほど「胃袋」とお伝えしましたが、飲み会で生まれるのは一時的な親近感だと思います。それも大事なんですが、長期的なコミュニティの存続のためには具体的な成果物が根底にあるべきと考えます。

コーディングは、成果物を共有できる、共同で成長できる、という性質を持っています。「このコミュニティにいると技術的に成長できる」「価値のある貢献ができる」という体験が Social Coding にあります。プログラマとしての我々がコミュニティに提供できる最高のものは、やはり工数。継続的に労働力を提供し続けるのが一番の貢献です。

パッチ袋には、コミュニティの存続を支える力が詰まっています。コードを通じた繋がりもいいものですよ。

むすび

というわけで、「三つの袋」について話してきました。ノベルティ袋で繋がって、胃袋でイベントを楽しみ、パッチ袋で技術を共有する。この三つの袋を持っていれば、コミュニティ生活をより充実したものにできます。ぜひ準備して、今後のコミュニティ生活を思いっきり楽しんでください。

はてなエンジニア Advent Calendar 2024、明日は id:susisu です。

Modular Monolith はどの辺りから考え始めるものなのか

モノリスでは大変なので、マイクロサービスやモジュラーモノリスにして認知負荷を減らしたり、生産性の劣化に抗いたいという考え方がある。

モジュラーモノリスとは

モジュラーモノリスについては、だいたい infoq.com のモノリスシリーズ（？）を読めば良いんじゃないか。

有名なのは Shopify のヤツ。

モノリスとマイクロサービスの中間にある、1 アプリケーションなんだけどモノリスでは無い、アプリ内でモジュール分けされているアーキテクチャのこと。app/ の直下に MVC を置くんじゃなくて、COMPONENTS (例えば billing)/app/ の下に MVC を置く、ようなイメージ。

モジュラーに移行するタイミング

僕の感覚だと、数百モデルは全然モノリスで扱えると思っている。少なくとも 300 models 程度でモジュラーにしていく必要はまったく感じない。

世の中で見つけたモデル数だと

の辺りは確かモノリスだったと思う。800 なり 1000 なりを超えても普通にモノリスで扱っているのは割と勇気が貰える数字だよね。

SmartBank さんは B/43のサーバーサイド開発の醍醐味と伸びしろ - inSmartBank の中で

現在はモノリスで開発していますがモジュラーモノリスだったりマイクロサービスのようなアーキテクチャも検討していきたい

と書かれてもいる。

800 は割としんどい数字なのだろう。この辺りが「移行したくなるタイミング」なのは僕の感覚とも合っている。

認知負荷が非常に高まってからでは遅い

じゃあ 800 になってからモジュラーに分割し始めるのかと言うと、痛みが表面化してから分け始めると、完了するまでずっと痛みを抱えていることになるし、既に密に絡まり合いまくっていて、分割するのはとてもコストがかかる作業になる。

その手前、400-500 models 辺りから着手し始めると、ちょうど安定的な生産性を得続けられるんじゃないだろうか。触っていて厳しさを感じずに開発できる環境を維持するチャンスがこのタイミング。ぜひ開発合宿とかでチャレンジしてみて欲しい。

逆に言うと、400-500 models にまだ手が届かない状態でモジュラーに分け始めるのは時期尚早っぽいと僕は思う。普通のリファクタリングがその手前にいっぱいあるんじゃないかな〜。

このタイミングでやるべきだった、という後知恵を集めたい。御社の例を教えてください。

僕はモノリス派なので話半分に聞いてもらうとして、じゃあ 200-250 models を超えたらモジュラーにし始めるタイミングなのかもしれないね。モジュラーでも爆速で走る方法を知っていて、それで困りが無いのであれば、いつ導入してもいいわけだし。

複雑なアプリケーションを運用する功夫《クンフー》は無限に積んでおきたいものである。

OpenTelemetry でのメトリック収集の始め方について話してきた

Findy さんのイベント で OpenTelemetry + Metrics の話をしてきた。(10分トーク)

スライドは、

  • Primary Signals (Metrics, Logs, Traces) はそれぞれ特性がある
    • メトリックも役割が存在しているので、(自サービスの状況に合わせて) 収集しよう
  • どうやってメトリックを収集するか

というストーリーです。

speakerdeck.com

イベント中/後に

  • メトリックを OTel で収集したことがまだなかった
  • Receiver は LISTEN するだけだと思っていた
    • Receiver から値を取得しにいくイメージを持っていなかった

といった声も寄せられたので、とっかかりとなる最初の一歩を置いておくのは大事だなと思いました。

実際、監視やダッシュボードよりもオブザーバビリティを高める方にみんなの意識が向いているし、既存の監視ツールで既に網羅されていることが多いので、今 OpenTelemetry + Metrics の話を聞くことは少なめです。SaaS によっては Traces だけ送っておくと勝手に Metrics になるしね。

自サービスにメトリックの収集を導入して、そもそも何が見られるか。何を見ているか。今までと比べて何か変わった実感を得たところは何か。といった例を増やしていければ良いなと思います。

Disclaimer: 私はメトリックを収集する SaaS の開発に関わっています。ぜひ 試してみてください 。

株式会社はてなに入社しました

株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

7 年目。老化のせいかコロナ禍のせいか、まだ 3-4 年目ぐらいの感覚である（何も成し遂げていない）

変化バジェットという考え方

この記事は はてなエンジニア Advent Calendar 2023 の 1/2 の記事です。昨日は id:nakataki の 1904年になりました(dayjsでの年入力の話) - nakatakiの日記 でした。190x 年から脱出できない面白い不具合でした。

変化バジェット

「変化バジェット」という考え方があります。というか世の中には無いんですが、僕は社内でこの概念をよく使っています。

だいたい名前から想像するものと同じなんじゃないでしょうか。組織が変化に対して許容できる予算枠だったり、組織が変化に対して投資する予算枠だったりを指しています。

変化バジェット＝許容量

変化バジェットは、組織が効果的に変化を取り入れ、消化できる能力の範囲を指します。

組織の変化に許容量があるという概念は、組織に対してパッチを当てると言い換えると分かりやすいでしょう。小さな Pull Request ならすぐにレビュー＆マージできますが、大きな PR は時間が掛かりますし、より多くの場所で障害が生じる可能性があります。

組織は、しばしば新しい変化に対して抵抗を示します。この抵抗は主に既存のプロセスへの馴れから来ています。

大きな変化を起こすと、その後一定期間は次の変化を起こせなくなります。新しい変化に体が馴染み、適応するために時間やエネルギーを使うからです。また、小さな変化を起こし続けていると、一定の力を変化への適応のために使い続けているため、目標達成のために全力を出せない状態になっているかもしれません。この状態だと大きな変化にも耐えられないでしょう。

チームが許容できない量の変化を持ち込むと、変化への適応をやりきれず、J カーブで成長していくつもりが、変化によって低下している期間が思った以上に長く続いて、アウトプットが下がります。

変化に適応するためには、組織が変化を取り入れ、消化できる能力の範囲、つまり「変化バジェット」を認識して変化を持ち込むことが必要なのです。

変化バジェット＝消化すべき予算

変化に許容量があるのはなんとなく分かると思うけど、許容量があるということは、これはリソースなので、戦略的に使い切りたい。

そもそも変化すべきであるというのは前提として良いでしょう。半年後に同じ生産性だと何も成長していない＝市場についていけなくなるので、何かしら変化を持ち込む必要は、あります。

変化バジェットを十分に消化できなかった場合、組織は本来すべきだった成長機会を失っていると考えるのが望ましいと私は考えます。各メンバーのスキルアップやプロセスの最適化、新しい技術の採用、とかの具体例を想像すると、消化していないと長期的に影響があることが分かりやすいんじゃないでしょうか。プロダクト開発のロードマップと突き合わせて、どのタイミングでどんな変化を持ち込むかを考えましょう。

変化バジェット＝使うと増えていく

また、変化バジェットは人間の感覚的な抵抗なので、基礎変化量からの比で表せることにも注目しましょう。ウェーバーの法則ですね。この法則は、基本的な刺激量からの相対的な比率で刺激を知覚することを示しています。

たとえば、100の刺激が110になったときはじめて「増加した」と気付くならば、200の刺激が210に増加しても気付かず、気付かせるためには220にする必要がある。

変化に慣れていない組織では、わずかな変化 (例えば100から110への増加) が顕著に感じられ、適応リソースを払うべきものになりますが、変化に慣れている組織では同じ変化量と感じるためには、より大きな変化 (200から220への増加) が必要になります。これは、日常的に多くの変化を乗りこなしている組織だと、小さな変化には適応リソースを少なく、より大きな変化に対しても適応しやすくなることを意味します。

変化バジェットを未使用のまま放置すると、組織は変化しない状態を「新たな標準」と見なし始める可能性があります。SRE におけるエラーバジェットと同じですね。安定への期待が過度に高くなり、変化への対応能力が低下するリスクがあります。

逆に変化バジェットを積極的に使っていくと、変化することが当然となっていくので、変化バジェットは徐々に増えていきます。

まとめ

組織変革 (Change Management) において、変化バジェットという考え方を書いてみました。

組織には、変化を受け入れられる許容量があり、これを「変化バジェット」として考えることができます。変化バジェットをリソースとして適切に計画し管理することで、組織の適応性や成長を高めていくことができます。

変化バジェットは感覚的な要素を含み、馴れによって容量が拡大することがあります。つまり継続的に小さな変化を導入することで、変化に対する耐性の高い、強い組織を作れます。変化バジェットの小さいところでは、無理に大きな変化を起こすのではなく、小さな変化から始めることが有効です。

精神的なものだけじゃなく、仕組みによっても拡大します。アジャイルなマインドセットや、イテレーションごとのふりかえりが機能している、チームの生産性を定量・定性的に観測しているチームは、絶えず変化と適応を繰り返しているので、変化バジェットが大きくなりがちですね。また、小さな変化だけでなく、狙いを持った大きな変化を定期的に持ち込むというのも効果がありそうです。組織体制を変えるとかですね。

はてなエンジニア Advent Calendar 2023、まだ続いていきそうです。

*1:日付を絞っているのは PHPカンファレンス福岡2023に proposal を出した から。

「キャッシュは麻薬」という標語からの脱却

これは はてなエンジニア Advent Calendar 2023 の 18 日目の記事です。昨日は id:gurrium による private-isuで70万点取るためにやったこと - ぜのぜ でした。私は 50 万点ぐらいで満足してしまっていたので、しっかり詰めていて凄いなと思う。

developer.hatenastaff.com

Web アプリケーション開発において、「キャッシュは麻薬」という言葉がインターネット上をよく飛び交っています。YAPC::Kansai OSAKA 2017 の id:moznion のトークでよく知られるようになったワードじゃないかな。

初出はちゃんとは分からないんですが、少なくとも 2011 年には言われていますね。

キャッシュに頼ると即時的にパフォーマンスが解決する。この即時効果に魅了されてしまい、根本的なパフォーマンス問題を覆い隠したままキャッシュに依存するようになり、そして脱出するのが難しい、という性質をよく表している言葉です。ですが、本当にキャッシュに依存するのは間違っているんでしょうか。

「キャッシュは麻薬」という言葉により「キャッシュ＝使うべきではない」と思考停止してしまう、しまっているのではないか。十把一絡げに「麻薬」と言うのではなく、キャッシュをパターン化して乗りこなすというのが望ましい姿でしょう。現代的な Web アプリケーション開発において、キャッシュを使うのはむしろ前提としないと機能しないと私は考えます。

パターン化は moznion の発表でもされていたんだけど、私の目線からも分類してみます。

HTTP Response キャッシュ (我々が server のとき)

レスポンスをまるっと CDN 等でキャッシュしてしまうパターン。現代の Web アプリケーションでは基本的に CDN は挟む前提でしょうから、これはもちろん許容されているキャッシュでしょう。

ありがちな失敗として、認証が必要なページをキャッシュしてしまうというのがある。また、PC とスマホとで出し分けるときなど、CDN のキャッシュキーとアプリケーションの出し分け条件が異なっていて、違う環境向けのコンテンツをキャッシュしてしまうミスも時々発生している。

一度キャッシュしてしまったらアプリケーションの制御下よりも手前で返してしまうため、キャッシュのパージがそこそこ難しい。

べき等な、副作用の無い処理ならキャッシュ可能という考え方で扱うんだけど、副作用のあるリクエストでも Idempotency-Key Header を利用して高速にレスポンスを返すパターンもある。これはクライアントからのリトライ時に使います。

HTTP Response キャッシュ (我々が client のとき)

サーバー側があったので、クライアント側も書いておく。自分が受け取ったレスポンスを保存（キャッシュ）しておくのは、速度以外だと主に以下の目的です。

  • 外部にリクエストを投げ過ぎないように
  • 外部が落ちていても運用に影響が出ないように

リクエストを投げすぎないようにするためには、最終取得日時を持って、比較しながらリクエストを投げれば良い。Squid 等の proxy や、 unique 制限付きの request queue (同じ URL に対する queue は 1 つにマージする的な) で対応することも多そう。

リクエスト先が落ちていてもキャッシュからどうにかするのは、SWR 的な考え方ですね。「stale でも緊急時に使って良いキャッシュ」というのはある。

カウンターキャッシュ

Rails Guide に書いてある程度には一般的なキャッシュ。belongs_to にオプションを追加するだけという、非常に手を出しやすいモデリングがされているので、これも使って良いキャッシュだろう。

guides.rubyonrails.org

例えば Entry -> Comment という関連があるときに、entries テーブルに comments_count カラムを持って、コメントが作られる/削除されるたびに comments_count カラムを更新する。

このように「子の要素数を親に持っておく」のは非常に一般的な要件だと思うんだけど、カウンターキャッシュ以外に名前付いているんですかね？このパターンの名前を他に聞かないなと思っている。

ところで Rails でカウンターキャッシュを実現するときに、ActiveRecord に組み込みのものと、より柔軟に扱える counter_culture gem とがあります。counter_culture はコード読むのとてもオススメです。README だけでも「カウンターキャッシュ」にだいぶ色んな要件があるのが分かって面白いと思う。

データを引きやすい形に加工したキャッシュ

どう言えばいいのか分かんなくてパターン名を付けられていない。イメージはカウンターキャシュと同じ。ただカウンターキャッシュがカウンターに特化しているのと比べ、必要なデータを必要な形に加工して保存しておくというのが特徴。

例えば Markdown で書いたブログの HTML Body がこのパターンに当たる。マスタとなるデータを更新するときに、一緒に or 非同期でキャッシュデータを生成する。

アクセス数ランキングもそうですね。アクセスログというイベントデータと、その加工先としての本日のアクセス数ランキング。ランキング表示時にアクセスログを毎回舐めたりはせず、事前に集計しておいた、引きやすい形に加工したものを持っているはずです。

アクセス数ランキングを想像すると、イベントソーシングの考え方とも近しい存在であるというのが分かると思います。イベントを全てアプライしたリソースは、仮に失ってもイベントから再生成できるので、キャッシュのようなものですね。

このパターンの場合、今見ているキャッシュはどこまでをアプライしたものなのかが分かりづらくなるんですが、同期的に扱えていればこの悩みとは無縁です。なのでトランザクションを持つデータストアで、マスタデータとキャッシュとを同じデータストアで扱うと楽になります。そうでない場合は、頑張りましょう。（実装パターンは幾つかあるんだけど、余白が足りない）

フラグメントキャッシュ

HTML のパーツ単位でキャッシュする。これも Rails ガイドにありますね。

guides.rubyonrails.org

レンダリング時にキャッシュがあれば使う、なければキャッシュを作る、という動きをする。具体的には以下のようなコード。

<% @entries.each do |entry| %>
  <% cache entry do %>
    <%= render entry %>
  <% end %>
<% end %>

これは entry を render したものを、entry の id と updated_at をキーとしてキャッシュしている。updated_at がキーに含まれているので、更新するとキャッシュキーが変わる＝キャッシュミスとなり、更新された新しいコンテンツで描画される。（実際はもっと複雑なことをしているけど、概要としては合ってるはず）

View やシリアライザでキャッシュするという考え方なので、HTML を離れて JSON API となっても活用することはできる。

ところで開発が活発な（？）アプリケーションでのフラグメントキャッシュでは、コンテンツの更新とテンプレートの更新との両方がキャッシュに影響します。Rails の場合はキャッシュキーにテンプレートの digest が入るようになりました（Rails 4 からなので 10 年前ですね）。このおかげで、コンテンツの更新だけを考えれば良くなっている。

透過的なキャッシュ

Webアプリケーションのキャッシュ戦略とそのパターン で言うところの Broker パターン。Primary なデータストアにアクセスする前に 必ず 通るキャッシュ。

透過的なので実装時に認識しづらく、デバッグも割と困難なため、あまり導入するべきではないが、ここぞと言うときに入れるとバグも少なく負荷が軽減される。ミドルウェアを挟むだけで実現できるのもまさしくいざというときに効く。

最初から設計していないとリロードするまで最新情報が表示されない等の副作用も出るので、いきなり導入するのは非常時の手段。

Read Through Cache、Write Through Cache と呼ばれることもあり、読み込み時のみならず、書き込み時も Broker を介して書き込む場合もある。これをやると書き込み直後のキャッシュが必ず最新を保てるが、常にダブルライトするのは無駄になることも多い。

Broker ではないが、データストアのレプリケーションを利用しての Read/Write Splitting も特徴がかなり似たキャッシュ形態だろう。Read/Write Splitting も飛び道具として機能することが多い。

レプリケーションであれば、「普段は replica 向きの connection を使う。保存系のクエリは primary に向け、そのリクエストの続き or そのユーザの数秒以内のリクエストでは読み込み系のクエリでも primary 向きの connection を使う」のような connection pooling の仕組みがあると、副作用を最小限にしていい感じに扱えるかもしれない。Rails の複数 DB はよくできているので、こちらもコードを読むのをオススメします。

アプリケーション的に自前で入れるキャッシュ

これが賛否両論あるヤツで、いわゆる麻薬です。下手に入れると本当に困る。

キャッシュ アサイド パターン - Azure Architecture Center | Microsoft Learn と言われる。

Caching Strategies and How to Choose the Right One | CodeAhoy や Webアプリケーションにおける正しいキャッシュ戦略 - Sansan Tech Blog でも同じ名前が当てられていますね。

アプリケーションコード内のあらゆる箇所でこの制御を入れようとすれば、あっという間にカオスになります。

が本当にそうなので、このパターンを使用するときは被害を最小限に食い止める設計と一緒じゃないと死です。無計画にやっていると、50 個を越えた辺りから不吉な臭いが漂ってくるだろう。この辺りから意図せず多段キャッシュになってしまい、どこのキャッシュをパージし忘れているせいでデータが更新されないのかを追えなくなっていく。

他にも色々

HTTP キャッシュは Web配信の技術 にすべてが書いてある。

また、フロントエンドのキャッシュもいっぱい話題はある（Apollo Client のキャッシュとか、Next.js のキャッシュとか。それぞれで 30 分トークができちゃう）んだけど、僕があんまり専門じゃないので他の人にお任せします。

ところでユーザリクエスト起因でキャッシュしているとキャッシュパージ時に非常に困るという話を以前したので、こちらも参考にどうぞ。

onk.hatenablog.jp

書いておかなければいけない宣伝

このエントリの骨格は YAPC::Hiroshima 2024 に CfP を出した ものでしたが、なんと前夜祭で、id:Soudai さんと一緒に話すことになりました。ここまでを下敷きとして、更に深い話をします。

まだチケットを購入可能なので、ぜひ来てください。

まとめ

キャッシュは麻薬と言われていますが、絶対に避けなければいけないものではありません。整合性が壊れやすくなることが問題なのです。そこでキャッシュの幾つかを分類し、これは使っても良いキャッシュであろうというパターンを挙げました。また、使うと後世で困りがちなキャッシュについて、気を付けるポイント（主にキャッシュアサイドパターンで多段キャッシュになるのが問題である）を書いてみました。

＼キャッシュと上手に付き合おう！／

はてな Advent Calendar 2023、明日は id:tokizuoh さんです。

参考 URL