Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem

あなたが巨大で複雑なクラウド都市「OpenStack」を建設する大規模なグローバル建設チームの一員だと想像してください。この都市は一人の人間によって建てられるのではなく、シンドア、グランス、ノヴァなどの何百もの地区（プロジェクト）で働く何千人もの労働者（開発者）によって建設されています。都市が崩壊しないようにするため、誰かが新しいレンガを追加したり配管を変更したりするたびに、一連の自動化された「安全点検」（テスト）が実行されます。

理想的には、これらの安全点検は完璧な信号機のように機能すべきです。緑は「進め、変更は安全である」を意味し、赤は「停止、問題が発生している」を意味します。

しかし、時折、信号機が点滅します。特に理由もなく赤になり、再確認すると緑になり、再び赤になります。ソフトウェアの世界では、これを「不安定性（Flakiness）」と呼びます。これはまるで気まぐれなテストのようであり、コードに変更が加わっていないにもかかわらず、通過するか失敗するかを判断できない状態です。

この論文は、この「気まぐれ」な振る舞いが一つの地区だけでなく、OpenStack 都市全体にどのように広まっているかを追う探偵物語です。

彼らが発見した 2 つの大きな問題

研究者たちは、この「気まぐれ」な振る舞いがトラブルを引き起こす 2 つの具体的な方法を発見しました。

1. 「感染性」のある不具合（プロジェクト間での不安定性）
ドアの鍵が機能するか確認するための特定の安全点検（テスト）を想像してください。この都市では、同じ鍵チェックがシンドア地区、グランス地区、ノヴァ地区のすべてで使用されています。

• 問題点: その鍵チェックは「気まぐれ」です。3 つの地区すべてでランダムに失敗します。
• 影響: 地区がこの 1 つのテストを共有しているため、単一の不具合のあるテストが複数の場所で同時に進行を停止させます。研究者たちは、OpenStack の地区の**55%**がこれらの感染性のある不具合の影響を受けていることを発見しました。まるで 1 つの腐ったリンゴが樽全体を腐らせるようですが、そのリンゴは実際には誰もが使用しているテストなのです。

2. 「選び取る」不具合（一貫性のない不安定性）
今度は、同じ鍵チェックがシンドア地区とノヴァ地区で使用されていると想像してください。

• 問題点: シンドアでは、テストは完全に信頼性が高く（常に緑）、ノヴァでは、全く同じテストが「気まぐれ」（赤と緑の間で点滅）になります。
• 影響: これは混乱を招きます。テスト自体が壊れているわけではなく、ノヴァの環境に何らかの問題があることを意味します。まるであなたの車庫では完璧に始動する車が、友人の家で始動させようとすると毎回かすれるようなものです。研究者たちは、このような「選び取る」不具合が 1,100 件以上存在することを発見しました。

大きな驚き：「ユニットテスト」さえも病気に

通常、開発者はユニットテストをソフトウェア世界の「顕微鏡」と考えています。これらは真空状態の中で、コードの小さく孤立した部分（単一の関数など）を覗き見るものです。外部世界と通信しないため、これらは最も安定し、予測可能なテストであると考えられています。

論文の衝撃的な発見:
研究者たちは、これらの「顕微鏡」テストの**70%**が実際には「感染性」のある不具合に関与していることを発見しました。

• 比喩: トースターを固定している小さく孤立したネジが、台所全体の電気システムをショートさせる原因となっていることが判明したようなものです。これらの小さなテストは安全で孤立していると考えられていましたが、巨大な生態系の中では深く接続されており、不安定性を至る所に広げることができます。

なぜこれが起こるのか？（原因）

チームは、なぜテストが一部の場所では動作し、他の場所では動作しないのかを突き止めるためにログを掘り下げました。彼らは 3 つの主な犯人を見つけました。

1. 「競合状態」（89% の原因）: これが最も一般的な原因です。2 人の労働者が全く同じミリ秒に同じ道具を掴もうとする状況を想像してください。時には労働者 A が掴み、時には労働者 B が掴みます。テストが他の何かによって既に使用されているリソース（サーバーやファイルなど）を掴もうとした場合、失敗します。掴めた場合は通過します。このランダム性を「競合状態」と呼びます。
2. 不一致の設定: ある国のレシピを使って、別の国の材料でケーキを焼こうとするようなものです。テストは特定のセットアップ（特定のバージョンのライブラリや特定のサーバー速度など）を期待していますが、環境が一致していません。
3. 依存関係の問題: ある地区が「電力網」（ソフトウェアライブラリ）を更新した一方で、隣町は更新していません。テストは更新された町では機能しますが、古い町では失敗します。

「様子を見る」アプローチのコスト

テストが失敗した場合、OpenStack での標準的な反応は、「ああ、これは不具合に違いない。もう一度実行（再確認）して待ちましょう」と言うことです。

• コスト: 研究者たちは、この「再確認して待つ」という習慣が、1,156 日ものコンピューティング時間とお金を無駄にしていると計算しました。
• 比喩: 交通警官が赤信号を見て、センサーが壊れていると仮定し、車を通行させ、再び確認し、再び通行させるようなものです。これは燃料（コンピューティングリソース）を無駄にし、すべての人の通勤（コードレビュー）を遅らせます。

労働者たちは何を言っているか？（開発者のフィードバック）

研究者たちは、実際の建設者（開発者）にこれについて尋ねました。

• 不満: 多くの開発者は無力を感じています。「私は新人で、誰に相談すればいいかわからないので、通過するまで『再確認』を押し続ける」と言います。
• 現実: 彼らは、これらの問題を修正することが難しいことを認めています。なぜなら、複数のチームと話す必要があるからです。シンドアの問題が原因でノヴァでテストが失敗した場合、ノヴァの開発者はシンドアのチームが修正するまで待たなければなりません。
• ツールの不足: 彼らは、支援するツールは存在するが、誰もメンテナンスする時間がないため、しばしば壊れたり放棄されたりすると述べています。彼らが必要としているのは、片手間でやるボランティアではなく、CI システム専用の「整備士」です。

教訓

この論文は、巨大で接続されたソフトウェア生態系において、テストを孤立した島として扱うことはできないと結論付けています。

• 開発者にとって: 単に「再確認」して待つのをやめなさい。あなたのコードとは無関係に見える場合でも、テストが失敗した理由を調査しなさい。
• チームリーダーにとって: 全地区にわたってテストの実行方法を標準化する必要があります。ある町が特定のツールを使用している場合、全員が使用する必要があります。また、どの「ネジ」が緩んでいるかを全員が把握できるように、これらの不具合の追跡を一元化する必要があります。
• 未来に向けて: テストが不安定である理由を自動的に教えてくれるより良いツールが必要です（単に「失敗した」ではなく、「サーバーがダウンしていたため失敗した」など）。

要約すると、この論文は、OpenStack 都市をスムーズに稼働させるためには、テストの失敗を単なる偶然の悪運として扱うのをやめ、都市全体に影響を与えるシステム的な調整問題として扱う必要があると主張しています。