ReDoS脆弱性の排除とリトライ移行の罠：retry から tenacity への刷新で起きた「ジッター遅延」と「デコレータ順序」の盲点
1. 概要
エンタープライズ向けのSaaSやオンプレミス製品を開発する際、コンテナイメージのセキュリティスキャンで検出される「間接的依存パッケージの脆弱性（CVE）」の排除は避けて通れない。 しかし、脆弱性を抱える古い共通ライブラリをモダンな代替ライブラリ（例: retry から tenacity）へ移行するリファクタリングには、コードの表面上は綺麗に見えても、背後で「リトライのウェイト時間（Jitter）のわずかなズレ」や「デコレータの順序によるメタデータの喪失」といった、システムのレイテンシやデバッグ容易性（Observability）を静かに破壊する罠が潜んでいる。 本稿では、Onyxで発生したサプライチェーン脆弱性の排除に伴うリトライエンジン移行バグ（onyx-dot-app/onyx#12000）を事例に、依存関係のクリーンアップにおける挙動維持の難しさと、デコレータ設計のディテールについて分析する。
2. インシデントの分析：間接的脆弱性（ReDoS）の排除と移行の罠
2.1. 背景：古い retry パッケージと CVE-2022-42969
Onyxでは、外部APIとの通信やインデックス同期の堅牢性を保つため、古くから retry というPythonパッケージを利用していた。このパッケージは2016年を最後にメンテナンスが停止しており、内部で間接的に（トランジティブ依存として）古い py パッケージを引き込んでいた。
この py パッケージには CVE-2022-42969 (ReDoS: Regular Expression Denial of Service) という深刻な正規表現脆弱性（細工された入力を処理する際に、正規表現のバックトラッキングでCPUを100%に張り付かせてサービス拒否を起こす）が存在した。 企業のコンテナスキャナーでこれが毎回検知され、セキュリティ審査で弾かれる原因になっていたため、開発チームは retry を廃止し、すでに依存ツリーに含まれていたモダンなリトライライブラリである tenacity への全面移行を決定した。
2.2. 罠①：暗黙の「ジッター（Jitter）」の追加によるレイテンシの揺らぎ
移行時、開発チームは tenacity をラップした共通の retry_builder デコレータを作成し、既存の18箇所の呼び出し元を書き換えた。しかし、ここに 「ジッター（Jitter：リトライ間隔のランダムな揺らぎ）」の挙動のサイレントな変化 が生じた。
- 従来の
retry: デフォルトでjitter=0であり、指定された遅延（例:@retry(tries=5, delay=5)➔ 常に正確に5秒の間隔）でリトライを試みる。 - 新規の
retry_builder: tenacityの仕様に合わせ、デフォルトでjitter=1（リトライのたびにランダムに最大1秒の追加遅延を加算する）の挙動を組み込んでいた。
この結果、GPUの稼働状況をミリ秒単位で厳密に監視・ポーリングする gpu_utils.py のような極めて高頻度でレイテンシに敏感な処理において、リトライのたびに「5秒 + uniform(0, 1)秒」の無用なランダム遅延が加わることになった。 一見わずかな差に見えるが、これが連鎖することでシステム全体の応答速度（レイテンシ）に予測不可能な揺らぎ（Jitter）が発生し、本番のパフォーマンス特性が劣化する原因となった。
2.3. 罠②：デコレータ順序のねじれによる「関数名（メタデータ）」の消失
もう一つの盲点は、Pythonにおけるデコレータの「重ね掛け」の順序であった。 移行コードにおいて、@functools.wraps(func) と @tenacity_retry の重ね順に不整合があった。
Pythonのデコレータは、記述する順序（上下関係）によって関数のラッピング順が変わり、メタデータ（__name__ や __doc__）の引き継ぎ可否に影響を与える。 順序のねじれが発生すると、デコレータを適用した関数がクラッシュした際、エラーログやスタックトレースに出力される元の関数名がすべて wrapped_func や retry_wrapper のような「デコレータ内部のダミー名」に上書きされてしまう。 これにより、本番環境で実際にエラーが発生した際、「ログをいくら見ても、どのビジネスロジックでエラーが起きたのかが全く特定できない」 という、オブザーバビリティ（監視容易性）の完全な崩壊を引き起こす直前の状態となっていた。
2.4. 「自前コード無風」の理不尽とデコレータ（インターセプター）の魔力
このインシデントのデバッグを何よりも困難にしたのは、**「開発者が自前で書いたビジネスロジック（GPUステータスの取得など）には、1文字のバグも、1文字の変更もなかった」**という理不尽さである。
開発者がエラーに直面した際、まず疑うのは自前で変更を加えたコードのロジックである。しかし、そこには変更が一切なく、完璧に正しい。 犯人は、コードの「外側」にふわりと掛けられたデコレータ（メタプログラミング）という皮膜の挙動変化であった。
デコレータやAOP（アスペクト指向プログラミング）は、コードの見た目を綺麗にする優れた抽象化ツールである。 しかし同時に、「対象のコードを一切書き換えないまま、実行時（ランタイム）の挙動やメタデータを完全にインターセプト（横取り）する」という魔力を持っている。 このため、問題が発生した際、「自分のコードは何も変わっていないし、絶対に正しい」という認知のバイアスがデバッガを幻惑し、原因がデコレータの挙動差（Jitterやfunctools.wrapsの順序）にあると気づくまでの時間を無限に引き延ばしてしまうのである。
3. 実体験：ライブラリ移行で「暗黙のタイムアウト」がすれ違い、キューが詰まったバグ
外部ライブラリを移行する際、インターフェース（関数の引数名など）を同じにしても、ライブラリ内部の「暗黙のデフォルト値」の違いが、システム全体の可用性を一撃で破壊することがある。
- 実体験エピソード: バックエンドサービスで、外部の決済API（Payment API）と通信する際のHTTPクライアントを、古いライブラリからモダンな
httpxに移行するタスクを担当した。 「関数を差し替え、引数もすべて合わせてテストも通った」ため、リリースした。 リリース後、決済の処理件数が詰まり、バッチ全体のキューが処理遅延を起こしてサーバーがハングアップする障害が起きた。 原因は、旧ライブラリのデフォルトのタイムアウト設定が「5秒（明示的なタイムアウト）」だったのに対し、新ライブラリ（httpx）はデフォルトで タイムアウトが無制限（None / 無限に待つ） になっていたことだった。 外部APIが一時的に過負荷でレスポンスを返さなくなった際、旧ライブラリであれば5秒でエラーを投げてキューを次に進めていたが、新ライブラリは相手からの返答を「永久に待ち続けて」スレッドを占有し続け、結果として全スレッドがフリーズしてキューが詰まってしまった。 「ドキュメントのデフォルト値の違い」をコードレビューで見落とすと、システムは一瞬で窒息する。
4. 解決策と「リトライ移行」における設計原則
この移行トラブルを防ぐため、開発チームは以下の詳細な挙動維持とデコレータ修正を行った。
4.1. jitter=0 の明示的指定による定数遅延（Constant Delay）の維持
ポーリングやGPU監視などのレイテンシに敏感な処理においては、jitter デフォルト値に依存せず、明示的に jitter=0 および backoff=1（指数バックオフを無効化）を渡すことで、移行前と全く同一の定数ウェイトを保証する。
# 挙動を厳密に保存したリトライ設計（gpu_utils.py）
@retry_builder(
tries=5,
delay=5,
backoff=1, # 指数バックオフを無効化 (定数遅延)
jitter=0 # 暗黙の追加ランダムウェイトを完全に排除
)
def gpu_status_request(indexing: bool) -> bool:
return _get_gpu_status_from_model_server(indexing)4.2. 正しいデコレータ順序の徹底によるメタデータ保護
関数のメタデータを完全に維持するため、functools.wraps が最外周（Outer wrapper）に正しく位置するようにデコレータの適用順序を厳密に配置し、ログやスタックトレースが元の関数名（例: gpu_status_request）をそのまま表示できるように設計を修正した。
4.3. 8分で地雷を特定した「自動化された防衛網」の解決速度
この移行時のステルスバグが本番環境で牙を剥く前に水際で防げた最大の教訓は、「厳密なテストコード」と「AI自動レビューボット」が連動した防衛プロセスの圧倒的なスピードにある。
本インシデントでは、以下のタイムラインで解決が完了している。
- 17:37: 依存関係刷新のPR作成。
- 17:45（8分後）: AIレビューボット（Cubic）が
gpu_utils.pyのjitter=0の漏れを機械的に検知・指摘。 - 17:46（9分後）: 別ボットがデコレータの順序によるメタデータ消失の危険を指摘。
- 19:10（1時間半後）: 指摘を受けた開発者が修正をプッシュし、マージ完了。
もし、この検証を「人間の手動テスト」や「目視のコードレビュー」だけに依存していた場合、無風に見える自前コードの差分や暗黙のデフォルト値の差（Jitter）は高確率で見落とされ、デバッグに数日〜数週間を費やす惨事になっていたはずである。 「最初に厳密な待機時間のアサーションテストを書いておいた開発者の誠実さ（時空を超えた防衛）」と、「PR作成から10分以内に行間の一貫性の欠如を見破るAIレビュー」という自動化された防衛網（檻）をあらかじめ敷いておくことこそが、極限環境のシステム開発における可用性を担保する唯一の道である。
5. 結論
依存ライブラリのセキュリティ移行（サプライチェーン対策）は極めて重要であるが、機械的な置換はパフォーマンスの揺らぎやデバッグの崩壊を招く。 共通リトライライブラリを再設計する際は、「暗黙のジッターの差がレイテンシに与える影響を特定する」、「デコレータが関数のメタデータ（Qualname）を完全に引き継いでいるかテストで検証する」 という、実行時特性とオブザーバビリティの双方を維持するための厳密な回帰検証が必須である。
6. 参考文献 / 一次情報
- replace retry with tenacity to drop CVE-2022-42969 (py): onyx-dot-app/onyx#12000
- ReDoS vulnerability in py package (CVE-2022-42969): NVD Vulnerability database