tortoise

メルカリのOSS「Tortoise」を監査した。 結論：本番運用を前提とした工学的受入は不可。 【1. 監査対象】 - 対象：Mercari / Tortoise - 開発主体：株式会社メルカリ - URL：mercari/tortoise - 対象コミット：13928a6070cff60d44d913d54515bd88a24c6ba6 - 監査日：2026年10月26日 【2. 対象の定義・目的】 Kubernetes上のCPU・メモリ割当と自動スケーリングを調整するソフトウェア。 目的は、計算資源の利用効率を改善し、適切なリソース配分と安定運用を両立すること。 【3. 目的適合性評価】 基本設計は目的に適合するが、目的の成立に必要な安全条件が欠落している。 資源の最適化は、稼働の安定性を損なわないことが前提となる。 ところが本実装には、設定された資源下限を適用時に保証しない経路が存在する。 最適化の結果としてシステムを停止させるなら、目的適合性は成立しない。 【4. 健全性評価・検出欠陥】 ① 資源下限制約の破綻［実運用報告＋実装確認］ メモリ要求量が12,288Mから128Mへ変更され、PodがOOMに陥った事例が報告されている。 資源の推奨値を計算する段階では下限を考慮していても、Podへの適用段階では下限制約を再確認していない。 これは最適化精度の問題ではない。守るべき制約を最終出力で保証できていない。 tortoise#436 ② 障害影響範囲の過大化［設定確認］ Webhookがクラスタ全体のHPA操作を対象とし、障害時には対象外のHPA作成・更新・削除まで失敗させ得る。 実際に、システム領域への干渉を警告する報告も存在する。 資源管理ツール自身の障害が、無関係な管理操作まで侵害する設計は不適切。 tortoise#437 ③ 標準導入手順の破綻［利用者報告＋設定確認］ 公式の"make deploy"について、設定の不整合、存在しない参照先、リソース名の重複による実行失敗が報告されている。 対象コミットにも該当する設定が残る。 標準手順で導入できないソフトウェアは、受入検査の入口で失格。 tortoise#440 ④ 更新競合処理の不備［コード確認］ 競合時に再試行する処理が、古い状態を取得し直さずに再送している。 競合が解消されるための条件を作らない再試行であり、復旧機構として不十分。 github.com/mercari/tortoise/blob/13928a6070cff60d… ⑤ ゼロ除算への防御欠落［コード確認］ 既存のCPU・メモリ要求量がゼロの場合に、比率計算でゼロ除算が生じる経路がある。 入力境界を確認せず、算出値を後続の資源・実行環境設定に利用する構造は健全ではない。 github.com/mercari/tortoise/blob/13928a6070cff60d… ⑥ 品質検査の不足［CI設定確認］ 設定ファイルだけを変更したPull Requestでは通常テストが起動しない。 さらに標準導入手順の成立を確認する検査が不足している。 導入設定を検査せず、導入不能な状態を公開できる品質管理になっている。 【5. 総評・監査判定】 今回の問題は、単なる細かなバグの集合ではない。 - 最適化対象の安全下限を保証できない。 - 障害の影響範囲を適切に限定できない。 - 標準導入の再現性を保証できない。 - 失敗時の回復処理と検査工程が不十分。 いずれも、ソフトウェアの目的を成立させるための基本条件である。 高機能な最適化アルゴリズムを備えていても、その出力が運用を破壊し得るなら、工学製品としての品質は成立していない。 本番環境への導入判定：不合格。 【6. 改善提案・受入条件】 - 資源下限を実際のPod変更直前にも強制する。 - Webhookの対象範囲を限定し、障害時の影響を局所化する。 - 競合時には最新状態を再取得する。 - ゼロ値・異常値への防御を追加する。 - 公式導入手順をCIで実行検証する。 - OOM・Webhook停止・更新競合・異常入力の再現試験を行う。 上記が再現試験で成立するまで、本番運用を受け入れる合理的根拠はない。 なお、実際のOOMと導入失敗は公開Issueの報告に基づく。その他は対象コミットの静的監査結果であり、今回独自のクラスタ実行試験は行っていない。 @mercari_inc @mercaridev