【ITニュース解説】Using ETag/If-None-Match Style Patterns for Local WMI Cache Freshness

システムエンジニアを目指す皆さんに、効率的なデータ管理の一つのアイデアを紹介する。車両識別番号（VIN）を扱うようなシステムでは、世界製造業者識別子（WMI）というデータが必要になる場合がある。WMIは、VINの最初の3文字を構成し、車両の製造元を示す情報だ。このWMI情報は、米国道路交通安全局（NHTSA）のような機関が管理している。

もし皆さんが、VINから製造元を素早く確認する無料のサービスを開発するとしたら、WMIデータをローカルに持っておくと便利だろう。なぜなら、ユーザーがVINを入力するたびにNHTSAに問い合わせていては、通信の遅延や、NHTSA側の利用制限（クォータ）に引っかかってしまう可能性があるからだ。そこで、WMIデータを皆さんのシステム内のキャッシュとして保持することが考えられる。キャッシュとは、よく使うデータを手元に一時的に保存しておくことで、元のデータ源に毎回問い合わせる手間を省き、処理を高速化する仕組みだ。

しかし、このWMIデータは「めったに変わらないが、時には変わる」という特性を持っている。新しい製造業者が登場したり、既存の製造業者名が更新されたり、訂正が入ることもある。この「たまに変わる」データをどう効率的に管理するかが課題となる。

一般的なキャッシュの仕組みとして「TTL（Time-To-Live）」、つまりデータの有効期限を設定する方法がある。これは、「このデータは〇分間は有効なので、その間は元のデータ源に問い合わせなくて良い」というルールだ。しかし、TTLだけでは問題がある。例えば、TTLを短く設定しすぎると、まだ変更されていないデータに対しても頻繁に元のデータ源へ問い合わせてしまい、通信量やリソースを無駄に消費する。これは、記事でいう「リフレッシュが多すぎてクォータを浪費する」状態だ。逆にTTLを長く設定しすぎると、データが更新されても長い間古い情報を使い続けてしまう可能性がある。これは「リフレッシュが少なすぎて、数週間も名前が変更されたメーカーの情報を表示し続ける」状態だ。

つまり、TTLは「いつ再問い合わせを許可するか」という時間に関する問いには答えられるが、「データ自体が本当に変更されたか」という内容に関する問いには答えられない。私たちが本当に知りたいのは、キャッシュが古くなったからといって、無条件に新しいデータをダウンロードするのではなく、データが実際に変更された場合にのみダウンロードすることだ。

この課題を解決するために、ウェブの世界で広く使われている「ETag（エンティティタグ）」と「If-None-Match」という仕組みをローカルキャッシュに応用するアイデアがある。これらはHTTPプロトコルの一部で、ウェブブラウザがウェブサーバーからコンテンツを取得する際に、データが更新されたかどうかを効率的に確認するために使われる。

ETagは、特定のウェブコンテンツの内容を表す「タグ」のようなものだ。コンテンツの内容が少しでも変われば、ETagの値も変わる。ウェブブラウザが一度コンテンツを取得し、そのETagを記憶しておくと、次に同じコンテンツにアクセスする際に、「If-None-Match: [以前に取得したETag]」という情報をリクエストに含めてウェブサーバーに送る。サーバーは、ブラウザから送られてきたETagと、現在サーバーにあるコンテンツのETagを比較する。もし両者が同じであれば、コンテンツは変更されていないと判断し、新しいコンテンツデータを送り返す代わりに「304 Not Modified」という短い応答を返す。これにより、ブラウザは手元のキャッシュデータがまだ有効であることを知り、新しいデータをダウンロードする手間が省ける。データが実際に変更されていた場合は、サーバーは新しいコンテンツと新しいETagをブラウザに返す。

このETagとIf-None-Matchの考え方を、WMIのローカルキャッシュ管理に応用できる。WMIキャッシュの場合、NHTSAのような外部のデータ源から定期的にデータを取得し、皆さんのシステム内のデータベースやファイルに保存する。このとき、WMIデータの「内容」からETagを生成する。具体的には、取得したWMIデータの各行を特定の順序で並べ、それらを結合した文字列全体のハッシュ値（データの内容を一意に識別する短い文字列）を計算し、それをETagとする。このETagは、WMIデータの内容が少しでも変われば、必ず異なる値になるように設計する。

キャッシュエントリには、このETagに加えて、データを取得した日時（fetchedAt）と、このデータが「新鮮」であるとみなせる期間（maxAgeMs）を保持させる。もし、現在の時刻がfetchedAtからmaxAgeMsを過ぎていれば、キャッシュは「古い」状態だと判断する。

キャッシュが古くなった場合、すぐに全てのWMIデータをダウンロードするのではなく、条件付きで更新を試みる。皆さんのシステムは、過去に取得したETagをNHTSAのデータ源、あるいはNHTSAからデータをプルして皆さんのために提供している中間システムに送って、「もしこのETagの内容がまだ変わっていなければ、新しいデータは送らないでください」とリクエストする。

もしNHTSAのデータ源（または中間システム）が、送られてきたETagと現在のWMIデータの内容が同じであると判断すれば、「304 Not Modified」に相当する応答を返す。この場合、皆さんのシステムは新しいWMIデータをダウンロードする必要はなく、キャッシュの取得日時（fetchedAt）だけを現在の時刻に更新し、引き続き手元の古いデータを「新鮮な状態」として利用できる。これにより、無駄な通信とデータ処理を回避できる。

一方、もしNHTSAのデータ源でWMIデータが更新されていた場合、新しいWMIデータと、その新しいWMIデータに対応する新しいETagが返される。このとき、皆さんのシステムは古いキャッシュデータを新しいデータに置き換え、新しいETagと取得日時を保存する。この置き換えは、システム利用者がデータ更新の途中に古いデータと新しいデータが混じったような不完全な状態を見ることがないように、アトミック（不可分）に行う必要がある。例えば、新しいデータセットを一時的に別の場所に作成し、準備が整ったら、現在参照しているデータセットのポインタを一気に新しいデータセットに切り替えるといった手法が考えられる。

この方式は、WMIデータそのものだけでなく、ウェブサイトのレイアウト変更のように、データの内容は変わらないが、表示の仕方だけを変えたい場合にも応用できる。もし、WMIデータの内容は変わらず、ETagも同じであるにもかかわらず、ユーザーインターフェースでのメーカー名の表示方法だけを変更したい場合、ETagを無理に変更する必要はない。ETagはあくまでデータの内容の整合性を保証するものであり、表示に関する変更は、例えば「presentationVersion」のような別のバージョン管理情報で扱うべきだ。こうすることで、データ変更と表示変更が混同されず、運用時の監視もよりクリアになる。

運用上のヒントとしては、実際にデータが変更された（modified）場合と、変更されなかった（not-modified）場合を区別してログに記録することが重要だ。これにより、どれくらいの頻度でデータが更新されているのか、そしてどれだけの通信量が削減できているのかを把握できる。また、NHTSAからのデータ取得中にエラーが発生した場合でも、ユーザーへのサービス提供が止まらないよう、古いキャッシュデータを使い続け、管理者向けの画面でのみ「WMIデータが古い可能性があります」といった警告を表示するべきだ。さらに、ETagやキャッシュデータをシステムの再起動後も使えるように永続化しておくことも重要だ。これにより、システムが再起動するたびに不要な「変更があった」と誤認される状況を避けることができる。タイムスタンプはシステム時刻のずれによって信頼性が低下する可能性があるため、データのハッシュ値であるETagを検証の主要な手段とすることが推奨される。

まとめると、ETagとIf-None-Matchというウェブ技術の考え方を、ローカルのWMIデータキャッシュ管理に応用することで、キャッシュが古くなった際に本当にデータが変更されたかどうかを効率的に判断し、必要に応じてのみ新しいデータを取得できる。これにより、VINの検証処理は高速なままでありながら、メーカー情報がいつまでも古いままになる心配もなくなる。これは、キャッシュの無駄な通信を減らし、かつ常に最新に近い情報を提供するための、賢いデータ管理方法だと言える。