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

당신이 OpenStack이라는 거대하고 복잡한 클라우드 도시를 건설하는 막대한 글로벌 건설 팀의 일원이라고 상상해 보세요. 이 도시는 한 사람이 건설하는 것이 아니라, Cinder, Glance, Nova 와 같은 수백 개의 다른 구역 (프로젝트) 에서 일하는 수천 명의 근로자 (개발자) 들이 함께 건설합니다. 도시가 붕괴하지 않도록 하기 위해, 누군가 새로운 벽돌을 추가하거나 파이프를 변경할 때마다 일련의 자동화된 "안전 점검 (테스트)"을 실행합니다.

이상적으로 이러한 안전 점검은 완벽한 신호등과 같아야 합니다: 초록색은 "이동하세요, 변경 사항이 안전합니다"를 의미하고, 빨간색은 "정지하세요, 문제가 있습니다"를 의미합니다.

하지만 때때로 신호등이 깜빡입니다. 아무런 이유 없이 빨간색으로 변했다가 다시 확인했을 때 초록색으로 변했다가 다시 빨간색으로 변합니다. 소프트웨어 세계에서는 이를 **"불안정성 (Flakiness)"**이라고 부릅니다. 이는 마치 기분이 변덕스러운 테스트처럼, 코드에 아무런 변경이 없는데도 통과인지 실패인지 알지 못하는 것과 같습니다.

이 논문은 이러한 "변덕스러운" 행동이 하나의 구역이 아닌 전체 OpenStack 도시로 어떻게 퍼져나가는지에 대한 탐정 이야기입니다.

그들이 발견한 두 가지 큰 문제

연구자들은 이러한 "변덕스러운" 행동이 문제를 일으키는 두 가지 구체적인 방식을 발견했습니다.

1. "전염성" 결함 (교차 프로젝트 불안정성)
문이 잠금 장치가 작동하는지 확인해야 하는 특정 안전 점검 (테스트) 이 있다고 상상해 보세요. 이 도시에서 동일한 잠금 장치 점검은 Cinder 구역, Glance 구역, 그리고 Nova 구역에서 모두 사용됩니다.

• 문제: 잠금 장치 점검이 "변덕스럽습니다." 세 구역 모두에서 무작위로 실패합니다.
• 영향: 구역들이 이 하나의 테스트를 공유하기 때문에, 하나의 결함 있는 테스트가 여러 곳에서 동시에 진전을 막습니다. 연구자들은 OpenStack 의 모든 구역 중 **55%**가 이러한 전염성 결함의 영향을 받고 있음을 발견했습니다. 이는 하나의 나쁜 사과가 통째로 바구니를 썩게 하는 것과 같지만, 실제로는 모두가 사용하는 테스트라는 사과입니다.

2. "선택적" 결함 (불일치 불안정성)
이제 동일한 잠금 장치 점검이 Cinder 구역과 Nova 구역에서 사용된다고 상상해 보세요.

• 문제: Cinder에서는 테스트가 완벽하게 신뢰할 수 있습니다 (항상 초록색). 하지만 Nova에서는 정확히 같은 테스트가 "변덕스럽습니다" (빨간색과 초록색 사이를 깜빡입니다).
• 영향: 이는 혼란스럽습니다! 이는 테스트 자체가 고장 난 것이 아니라, Nova의 환경에 무언가 문제가 있음을 의미합니다. 마치 당신의 차고에서는 완벽하게 시동이 걸리지만, 친구의 집에서는 시동을 걸 때마다 부글부글 거리는 자동차와 같습니다. 연구자들은 이러한 "선택적" 결함이 1,100 건 이상 발견되었습니다.

큰 놀라움: "단위" 테스트조차도 병들고 있습니다

일반적으로 개발자들은 **단위 테스트 (Unit Tests)**를 소프트웨어 세계의 "현미경"으로 생각합니다. 그들은 진공 상태에서 코드 (단일 함수와 같은) 의 작고 격리된 조각들을 살펴봅니다. 외부 세계와 소통하지 않기 때문에 가장 안정적이고 예측 가능한 테스트로 여겨집니다.

논문의 충격적인 발견:
연구자들은 이러한 "현미경" 테스트 중 **70%**가 실제로 "전염성" 결함에 관여하고 있음을 발견했습니다.

• 비유: 토스터를 고정하는 작고 격리된 나사가 전체 주방의 전기 시스템을 단락시키는 동일한 나사라는 사실을 발견한 것과 같습니다. 우리는 이러한 작은 테스트가 안전하고 격리되어 있다고 가정했지만, 거대한 생태계에서는 깊이 연결되어 있어 불안정성을 모든 곳으로 퍼뜨릴 수 있습니다.

왜 이런 일이 발생합니까? (원인)

팀은 로그를 파헤쳐 테스트가 어떤 곳에서는 작동하고 다른 곳에서는 작동하지 않는 이유를 찾았습니다. 그들은 세 가지 주요 범인을 발견했습니다.

1. "경쟁 상태" (89% 의 주범): 이것이 가장 흔한 원인입니다. 두 명의 근로자가 정확히 같은 밀리초에 같은 도구를 잡으려고 노력하는 상황을 상상해 보세요. 때로는 근로자 A 가 그것을 얻고, 때로는 근로자 B 가 그것을 얻습니다. 테스트가 이미 다른 것에 의해 사용 중인 리소스 (서버나 파일과 같은) 를 잡으려고 시도하면 실패합니다. 만약 그것을 얻으면 통과됩니다. 이러한 무작위성을 "경쟁 상태 (Race Condition)"라고 합니다.
2. 불일치 구성: 한 나라의 레시피로 다른 나라의 재료를 사용하여 케이크를 굽는 것과 같습니다. 테스트는 특정 설정 (특정 버전의 라이브러리나 특정 서버 속도 등) 을 기대하지만, 환경이 일치하지 않습니다.
3. 의존성 문제: 한 구역은 "전력망" (소프트웨어 라이브러리) 을 업데이트했을 수 있지만, 이웃 도시는 그렇지 않을 수 있습니다. 테스트는 업데이트된 도시에서는 작동하지만 구식 도시에서는 실패합니다.

"기다려 보기" 접근법의 비용

테스트가 실패할 때 OpenStack 의 표준 반응은 "아, 결함일 거야. 다시 실행 (재확인) 하고 기다리자"라고 말하는 것입니다.

• 비용: 연구자들은 이러한 "재확인 및 대기" 습관이 1,156 일의 컴퓨팅 시간과 자금을 낭비했다고 계산했습니다.
• 비유: 이는 교통 경찰이 빨간불을 보고 센서가 고장 났다고 가정하고 차들을 지나치게 한 후, 다시 확인했다가 다시 차들을 지나치게 하는 것과 같습니다. 이는 연료 (컴퓨팅 자원) 를 낭비하고 모든 사람의 출근 (코드 검토) 을 지연시킵니다.

근로자들은 무엇을 말합니까? (개발자 피드백)

연구자들은 실제 건설자 (개발자) 들에게 이에 대해 물었습니다.

• 좌절감: 많은 개발자들이 무력감을 느낍니다. 그들은 "나는 새내기라 누구에게 물어봐야 할지 모르니, 통과될 때까지 계속 '재확인'을 누른다"고 말합니다.
• 현실: 그들은 이러한 문제를 해결하는 것이 어렵다고 인정합니다. 여러 팀과 대화해야 하기 때문입니다. Cinder의 문제 때문에 Nova에서 테스트가 실패하면, Nova 개발자는 Cinder 팀이 문제를 해결할 때까지 기다려야 합니다.
• 도구 격차: 그들은 도움을 주는 도구가 존재하지만, 유지 관리할 시간이 있는 사람이 없어 종종 고장 나거나 방치된다고 언급했습니다. 그들은 부업으로 하는 자원봉사자가 아닌, CI 시스템을 위한 전담 "기계공"이 필요하다고 말합니다.

교훈

이 논문은 거대하고 연결된 소프트웨어 생태계에서는 테스트를 고립된 섬으로 취급할 수 없다고 결론 내립니다.

• 개발자를 위해: 단순히 "재확인"하고 기다리는 것을 멈추세요. 테스트가 실패한 이유를 조사하세요. 그것이 당신의 코드와 관련이 없어 보이더라도요.
• 팀 리더를 위해: 모든 구역에서 테스트를 실행하는 방식을 표준화해야 합니다. 한 도시가 특정 도구를 사용한다면, 모두 사용해야 합니다. 또한 이러한 결함의 추적을 중앙화하여 누가 "나사"가 느슨한지 모두 알 수 있어야 합니다.
• 미래를 위해: 테스트가 불안정한 이유를 자동으로 알려주는 더 나은 도구가 필요합니다 (예: "서버가 다운되어 실패했습니다"라고 알려주는 것, 단순히 "실패했습니다"라고 말하는 것이 아닌).

요약하자면, 이 논문은 OpenStack 도시가 원활하게 작동하려면 테스트 실패를 무작위의 불운으로 취급하는 것을 멈추고, 전체 도시에 영향을 미치는 체계적인 조정 문제로 취급해야 한다고 주장합니다.