前回の記事では、GadgetStreem Radar（GSR）が実際のメーカー公式Feedへ接続し、AppleとNVIDIAでは取得に成功する一方、SonyではHTTP 403が発生したことを紹介しました。
Sonyの2つの情報源は、無理に取得方法を変更するのではなく、blocked_by_originとしてQuarantine。
Apple Japan、Apple Global、NVIDIAの3ソースはHealthyとして継続観測できる状態になりました。
では、3つの情報源から一度正常に取得できた時点で、GSRを次の段階へ進めてもよかったのでしょうか。
GSRでは、そう判断しませんでした。
「1回動いた」と「継続して信頼できる」は別だからです。
1回の成功では分からないこと
ニュース取得の仕組みは、一度成功しただけでは安定しているとは言えません。
翌日も同じように取得できるのか。
同じ記事を再取得したとき、重複として正しく扱えるのか。
新しい記事だけを新規データとして取り込めるのか。
取得できない情報源へ何度もアクセスしてしまわないか。
途中でSource Healthが変化しないか。
そして、何日か運用したあとでも同じ結果を再現できるのか。
こうしたことは、一度のCollectionだけでは確認できません。
そこでGSRでは、同じ仕組みを時間を空けて繰り返し実行するShadow Cycleを始めました。
「Shadow」は公開しない観測運用
ここでいうShadow Cycleは、ユーザー向けにニュースを公開するための運用ではありません。
実際の情報源を使いますが、結果は内部検証用です。
この期間も、Production Collection、Public Display、自動Scheduler、Normalization、Rankingは無効のままでした。
実データで動かす。しかし、まだ公開サービスにはしない。
対象はApple、NVIDIA、そして隔離されたSony
継続観測でも、管理対象となる情報源は5つです。
- Apple Newsroom Japan
- Apple Newsroom Global
- Sony Group Japan
- Sony Group Global
- NVIDIA Newsroom
ただし、実際に取得を試みるのはHealthyな3ソースだけです。
Apple Japan、Apple Global、NVIDIA。
Sony JapanとSony Globalは、前回のHTTP 403を受けてquarantined / blocked_by_originのままです。
Shadow Cycleを繰り返しても、Sonyへ自動的に再アクセスすることはありません。
一度Quarantineした情報源を、後続処理が勝手に復活させない。
GSRは取得処理だけでなく、こうした状態管理も継続して確認しました。
5回のOperational Cycle
GSRが継続観測のLedgerへ記録したのは、cycle-002からcycle-006までの5回です。
前回紹介した最初の実ソース接続とは別に、その後のRecurring Shadow Operationとして5回を積み上げました。
各Cycleでは、AppleとNVIDIAの3ソースがすべて成功し、Sonyの2ソースはQuarantineされたままSkipされています。
| Cycle | 取得 | 新規受理 | 重複 | 成功ソース | Quarantine |
|---|---|---|---|---|---|
| 002 | 60 | 0 | 60 | 3 | 2 |
| 003 | 60 | 2 | 58 | 3 | 2 |
| 004 | 60 | 7 | 53 | 3 | 2 |
| 005 | 60 | 2 | 58 | 3 | 2 |
| 006 | 60 | 0 | 60 | 3 | 2 |
5回とも、取得処理そのものによるSource Failureは0でした。
60件取れても、新規0件でいい
この結果で特に重要なのが、Cycle 002とCycle 006です。
どちらも60件を取得しています。
しかし、新規として受理された記事は0件。
60件すべてがDuplicateとして処理されました。
一見すると、「60件取得したのに何も増えていない」ので成果がないようにも見えます。
しかしGSRにとっては、むしろ期待通りの結果です。
同じ記事をもう一度取得しても、新しい記事として増殖しない。
ニュースを定期取得するシステムでは、この性質が非常に重要です。
新しい記事だけを追加する
一方、Cycle 003では2件、Cycle 004では7件、Cycle 005では2件が新しく受理されました。
残りは既に取得済みの情報としてDuplicate判定されています。
以前から存在する情報と、その後新しく追加された情報を分けて扱えている。
Cycle 004なら、60件のうち7件だけが新規、53件は重複。
Cycle 005では、新規2件、重複58件。
「取れた件数」が重要なのではなく、以前の観測との差分を正しく扱えるかを見ていました。
Sonyは5回ともQuarantineのまま
5回のOperational Cycleを通して、Apple Japan、Apple Global、NVIDIAはHealthyを維持しました。
一方、Sony JapanとSony Globalはquarantined / blocked_by_originのままです。
5回のCycleそれぞれでQuarantine状態が記録され、通常の取得対象には戻っていません。
これは「Sonyがずっと失敗し続けた」という意味ではありません。
そもそもQuarantine後は通常Cycleで再試行していないということです。
Cycleの結果そのものも記録する
GSRでは、単に「今回も成功した」と表示するだけでは不十分と考えました。
各Shadow CycleについてSanitized Reportを生成し、Cycle ID、実行日時、取得件数、新規受理件数、Duplicate件数、成功・失敗したSource数、Quarantine数、Source Healthなどを記録します。
一方、記事タイトルやRaw URL、Feed Payload、認証情報、データベース接続情報などはSanitized Reportへ含めません。
さらにReportにはSHA-256を持たせ、後から内容が変化していないか確認できるようにしました。
5回を「Ledger」に積み上げる
個々のReportだけでは、「時間をかけてどう変化したのか」を追いにくくなります。
そこでGSRでは、Shadow Cycleの結果を時系列のLedgerとして積み上げました。
LedgerにはCycleの順番だけでなく、前のRecordとのつながりやDigestも記録します。
いつ、どの状態で、どんな結果だったのかを連続した証跡として残す。
ことを重視しました。
Operational Cycleとは何か
GSRでは、Cycleを実行しただけでは「Operational」と数えません。
今回のShadow Cycleでは、少なくとも3つのSourceが成功し、Source Failureが0であることが条件になっています。
Sonyの2ソースは既にQuarantineされているため、Skipされた状態でも問題ありません。
重要なのは、想定していない新しい失敗が発生していないことです。
この条件を、Cycle 002から006までの5回すべてが満たしました。
Operational Cycle Count = 5
それでも「READY」にはならなかった
5回実行して、5回ともOperational。
AppleとNVIDIAはHealthy。
SonyのQuarantineも維持。
Duplicate処理も機能し、途中では新しい記事だけを正しく受理できました。
それでもGSRの判定は、NOT_READYでした。
残っていたBlockerは、minimum_observation_span_daysです。
5回のCycleは揃った。しかし、最初のCycleから最新CycleまでのObservation Spanは10日。
GSRが事前に設定していた条件には届いていませんでした。
回数だけ満たしても先へ進まない
「5回とも成功したから、もう十分ではないか」と判断することもできました。
しかし、それでは検証基準を作った意味がありません。
GSRでは、実行結果を見てから合格条件を変更するのではなく、あらかじめ決めたGateに従いました。
動いているように見えることと、次へ進む条件を満たしていることは別。
そのため、5回のOperational Cycleを達成したあとも、GSRはその場で止まりました。
次回：なぜGSRは28日待ったのか
5回のShadow Cycleを完了した時点で、Observation Spanは10日。
一方、GSRが要求していたMinimum Observation Spanは28日でした。
なぜ5回成功しているのに、さらに時間そのものを条件にしたのか。
なぜCycleを短時間で連続実行して「5回成功」にしなかったのか。
そして、28日というGateの先に何を置いていたのか。
次回のVol.5では、GSRが「動いているのに待つ」という判断をした理由と、Cycle007を含む公開前Gateについて紹介します。
GSR Development Story
Vol.1 ニュースを「探す」から「見極める」へ
Vol.2 GSRのデータ基盤を作る
Vol.3 AppleとNVIDIAは取れた。でもSonyは取れなかった
Vol.4 5回のShadow Cycleで検証したこと ← 今回
Vol.5 なぜGSRは28日待ったのか
Vol.6 AIにニュースを書かせる前に作った境界線
Vol.7 公式サイトだけではGSRを完成できなかった
Vol.8 GDELTとWikimediaへ
Vol.9 本番データを触る前に、何度も止めた理由
Vol.10 GSRはいまどこまでできているのか
Vol.11 GPIとGSRが揃うとGadgetStreemは何になるのか
コメント