Offcanvas

How To / 애플리케이션

'시한폭탄 동시실행 버그' SW 시험만으로는 역부족인 이유

2014.03.14 Paul Rubens  |  CIO

페이스북이 IPO하던 날, 나스닥(Nasdaq)이 사용한 코드에 숨겨져 있던 동시실행 버그(concurrency bug)도 존재를 드러냈다. 레이스(Race) 상태로 인해 주문 확인 제공이 중단됐으며 주문이 반복적으로 제출되는 사고가 터졌다. 이로 인해 페이스북의 IPO를 지원한 UBS는 3억 5,000만 달러의 손실을 입었다

 이 버그로 인해 나스닥은 1,000만 달러의 SEC 벌금을 물었으며 4,000만 달러 이상의 보상비를 지불해야 했다. 뿐만 아니라 이미지에 측정이 불가능한 피해를 입었다.

이 버그가 시험 중 발견되지 않은 이유는 무엇일까? 2012년 이 운명적인 날 이전에 이런 문제가 드러나지 않은 무엇일까?

레이스 상태로 인한 동시실행 시한폭탄
동시에 실행되는 소프트웨어에서 발생할 수 있는 레이스 조건과 같은 일부 버그는 시험으로 발견하는 것이 쉽지 않다. 시험만으로는 충분하지 않다. 100번이나 심지어 1,000번이라도 소용 없다.

레이스 조건이 적용된 동시 실행 애플리케이션은 폭발을 앞둔 시한폭탄 같다. 그리고 특정 환경이 갖추어져 갑자기 문제가 발생할 때까지 수 년의 시간이 소요될 수 있다.

이런 문제들을 간략하게 살펴보도록 하겠다. 성능을 높이면서 레이턴시(Latency)를 낮추기 위해 애플리케이션 코드가 2개 이상의 프로세서 코어에서 구동하며 여러 명령이 동시에 실행된다. 어떤 명령이 데이터를 메모리에 쓰는 동안 다른 명령은 이것을 읽을 수 있다.

일반적으로 쓰기는 읽기 전에 실행된다. 하지만 이따금씩 쓰기를 담당하는 스트림(Stream)이 제 시간에 실행 상태로 진입하지 못할 수 있다. 다른 스트림이 먼저 읽기 상태에 도달한다. 이것이 레이스 상태다.

동시 실행 앱의 경우, 무엇이 언제 또는 어디에서 구동할지 지시할 수 없다
단일 코어 프로세서는 이런 일이 발생할 수 없다. 그렇다면 스트림이 동시에 구동되는 다중 코어 프로세서에서는 결과가 항상 일정할까? 항상 같은 스트림이 레이스에서 승리할까? 안타깝게도 항상 그런 것은 아니다. 동시 실행 애플리케이션은 비결정론적 동작을 보인다. 즉, 항상 같은 결과를 도출하지 않는다.

그 이유를 이해하기 위해서는 먼저 개발자가 애플리케이션이 구동하게 될 환경의 모든 부분을 제어할 수 없다는 것을 염두에 둬야 한다.

실행은 프로그램의 어떤 비트(Big)가 언제 구동할지를 결정하는 저수준 스케줄러(Scheduler)에 의해 결정된다. 코드 작성자는 여기에 접근이 불가능하다. 또한 하드웨어는 프리페치(Prefetch) 데이터와 지시사항 등을 실행하고 캐시(Cache)와 정보를 교환한다는 사실을 잊어서는 안 된다.

실제로는 애플리케이션이 실행될 때마다 배경조건이 달라진다. 문제는 애플리케이션이 실행될 때 1만 번에 한 번 나타날 수 있으며, 이보다 더 낮은 확률로 나타날 수도 있다.

이 때문에 버그를 찾기가 매우 어렵다. 시험에서 애플리케이션의 버그가 발견된다 하더라도 비결정적 수단으로 버그의 재현이 불가능할 수 있다. 명확하게 동일한 조건 하에서 시험을 다시 진행해도 애플리케이션은 문제 없이 구동하는 경우가 태반이다.

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.