1990년 미국 AT&T 장거리 전화 네트워크 장애

AT&T의 장거리 전화 네트워크 장애

• AT&T는 미국 전역에 퍼져 있는 114개 컴퓨터 기반 스위칭 시스템(4ESS)의 네트워크를 통해 장거리 콜(calls)을 라우팅 함. 각각이 시간 당 7십만건의 콜을 처리할 수 있는 이 스위치들은 CCS7(Common Channel Signaling System No. 7)라 알려진 네트워크로 연결되어 있음. 4ESS 스위치에 올라가 있는 DLN(Direct Link Node) 프로세서는 해당 스위치를 CCS7 시그널링 네트워크에 연결하며 타 스위치들의 상태 정보도 담고 있음
• 1990년 1월 15일 월요일 2:30pm(EST)에 AT&T의 뉴욕 네트워크 운영 센터의 네트워크 관리자는 전체 네트워크를 그래픽하게 나타내는 72개 스크린 비디오 어레이 상에서 빨간 경고 신호가 급격히 늘고 점차 다른 곳으로 퍼져 나가는 것을 보게 됨
• AT&T 엔지니어들이 표준 절차에 따른 네트워크 복구 작업에 들어갔지만 실패하였고, 그날 밤 11:30pm(EST)이 되어서야 겨우 네트워크를 안정시키는데 성공함
• 이 9시간의 장애 동안 AT&T를 거치는 콜의 거의 50%(약 7천5백만건의 콜)가 연결에 실패함. 이로 인해 AT&T가 약 6천만 달러의 손실을 입었으며, 전화 의존도가 높은 사업체(예, 비행기 예약, 호텔, 차 대여 에이전시 등)가 입은 손실도 큰 것으로 추정됨

장애 원인

• 장애가 발생하기 얼마 전인 12월 중순에 AT&T가 특정 타입의 메시지 프로세싱을 더 빠르게 하여 네트워크 성능을 향상시키려는 목적으로 DLN 프로세서에 올라가는 소프트웨어를 업그레이드 함
• 이 업그레이드된 소프트웨어 코드에 실수로 결함이 포함됨. 구체적으로는 C 언어로 작성된 프로그램의 한 부분에 다소 길이가 긴 "do... while" 구문이 있는데 이것이 내부에 "switch" 구문을 포함하고 있으며 이 "switch" 구문은 다시 "if" 절을 포함하고 있음. 이 "if" 절 내부에는 해당 "if" 절을 빠져나가도록 의도하고 삽입한 "break" 문이 있는데 코딩 시 오타로 인해 대신 "switch" 구문 전체를 빠져나가게 되는 실수를 함
• 이 코딩 에러가 있는 소프트웨어가 AT&T 네트워크의 모든 4ESS 스위칭 시스템의 프론트엔드 프로세서에 로드되었고, 실험실 환경에서 수행된 테스트에서는 예상하지 못했던 특정 이벤트 조합(아래에 자세하게 설명)에서 해당 버그가 모습을 드러내면서 네트워크 전체에서 실패가 일어남

AT&T 네트워크 실패가 발생한 상황을 살펴보면 아래와 같다.

①     1990년 1월 15일 오후, 뉴욕 시에 있는 AT&T의 4ESS 톨 스위칭 시스템 중 하나(편의상 ‘스위치 A’로 표기)에서 사소한 하드웨어 문제가 발생하였고 이것이 스위치 내부에 있는 일상적인 결함 복구 루틴(대략 4~6초 소요되는 자동 리부팅)을 작동시킴. 이 결함 복구 액션을 마칠 때까지 스위치 A가 신규 콜을 처리하는 것을 잠시 중단하게 됨에 따라 자신에게 신규 콜을 보내지 말라고 알리는 메시지를 연결된 다른 4ESS 스위치들에게 자동 전송함. 이 메시지를 수신한 스위치들은 스위치 A가 서비스 중단 상태임을 자신의 내부 로직(상태 맵)에 기록함

②     몇 초 후 스위치 A가 성공적으로 복구를 완료하고 콜 처리를 재개할 준비가 되자 IAM(Initial Address Messages)라 알려진 콜 시도(call attempts)를 연결된 타 스위치들에게 전송함. 스위치 A로부터 IAM을 수신한 스위치 B는 스위치 A의 서비스가 재개되었음을 기록하기 위해 자신의 내부 로직을 리셋함. 하지만 스위치 B가 자신의 내부 로직을 리셋하는 도중에 스위치 A로부터 두 번째 콜 시도 메시지를 수신하면서 문제가 시작됨(스위치 A로부터 첫 메시지가 온지 10ms가 안되어 두 번째 메시지가 도착)

③     첫 번째 메시지가 아직 처리 중이므로 유입된 두 번째 메시지는 나중을 위해 일단 저장되어야 하지만 업데이트된 소프트웨어의 버그 때문에 두 번째 메시지가 중요 통신 정보를 덮어쓰고 데이터 훼손을 유발함. 스위치는 데이터 훼손의 경우를 대비해 지속적으로 자신을 모니터하도록 프로그램 되어 있으므로 스위치 B의 소프트웨어가 이를 감지하여 “CCS7 프로세서가 비정상이다”고 스위치 B에게 알렸고, 스위치 B는 문제가 번지는 것을 막기 위해 자신을 셧다운(리셋)함. 이 때 스위치 B가 자신이 서비스를 중단하고 추가적인 트래픽을 받지 않음을 알리는 메시지를 연결된 타 스위치들에게 전송함

④     이 후 스위치 B가 자신을 리셋 한 후에 다시 가동을 시작하고 CCS7 링크를 통해 콜 프로세싱 재개를 알리는 메시지를 보냄. 이를 수신한 4ESS 스위치들은 스위치 B의 서비스 재개를 기록하기 위해 자신들의 내부 로직을 리셋하게 되었고, 마찬가지로 리셋 프로세스 도중에 스위치 B로부터 두 번째 메시지를 받게 되면서 스위치 B에 연결되어 있던 타 스위치들도 똑같은 상황에 빠지게 됨(우연히 10ms 이내에 두 개의 연이은 메시지가 유입되지 않은 일부 스위치들은 운 좋게 이 상황에 빠지지 않았지만 일단 문제가 생긴 스위치들이 계속 실패를 반복하며 네트워크 상의 다른 스위치로 전염시킴)

⑤     이렇게 연쇄 반응이 일어나면서 동일한 문제가 네트워크의 114개 4ESS 스위치에서 계속 반복해서 발생하게 됨(즉, 스위치들이 계속 자신을 리셋 하기를 반복함)