[릴리즈의 모든 것] 2장. 사례 연구: 항공사를 멈추게 한 예외

스터디 메인 페이지

목차

- ☆ 표시가 붙은 부분은 스터디 중 나온 얘기 혹은 제 개인적인 생각이나 제가 이해한대로 적어놓은 것으로, 책에 나오지 않는 내용입니다. 따라서 책에서 말하고자 하는 바와 다를 수 있습니다.

- 모든 이미지의 출처는 Release의 모든 것(마이클 나이가드 지음) 책 입니다.

 

---

 

2장. 사례 연구: 항공사를 멈추게 한 예외

• 작은 프로그래밍 오류로 만들어진 눈덩이가 언덕 위에서 굴러 내려오고 있다. 눈덩이의 속도가 빨라지고 문제의 규모는 조금씩 커진다. 한 대형 항공사에 이런 사고를 겪어 수십만 달러의 손해를 본 사례이다.
• ☆ 이하 사례가 상세히 설명되어 있는데, 다 적기 뭐해서 매우 많이 축약했다.
• ☆ 대충 엄청 잘 구성된 시스템이었다는 얘기들. 고질라도 대비!

• ☆ 아무튼 db를 1에서 2로 시스템 전환하는 작업을 함.
• ☆ 근데 2시간 뒤에 모든 체크인 키오스크가 빨간불뜸. IVR 서버도 빨간 불.
• 어떤 경우라도 서비스 복원이 최우선이다. 조사보다도 서비스 복원이 먼저다.
• ☆ 원인은 사후 분석 하기로 하고, 우선 서버들 재시작해서 다행히 초록색 이었고, 경과 시간은 세 시간이 넘었다고 함.
• ☆ 장애가 항공사에 미친 영향 : 키오스크가 정지됬으므로 항공사는 비번으로 쉬고 있는 직원을 불러야 했고, 초가 근무로 급여 50% 올려서 줌. 업무가 밀려 있었으니 오류가 났던 세 시간보다 더 걸려서 상황이 정리됨. 또한 탑승 시간이 오래 걸리다보니 비행기가 게이트에서 빠져나갈 수 없어서 파생된 여러 문제 발생. 연방항공국에서 항공사의 연례 성적표에 정시 도착과 출발 여부를 반영하는데 여기서도 불이익. 등
• 사후 분석은 미스터리 살인 사건과 비슷하다. 시체가 사라지고 없기 때문에 장애 사후 분석은 살인 사건을 해결하는 것보다 더 어려울 수 있다.
• ☆ 아래와 같은 EJB 코드가 있었고, 여기서 stmt.close()에서 SQLException이 발생할 수 있다고 함. 대부분 일어나지 않는 일이지만, DB 서버를 대체 서버로 교체하는 것 같은 이 사례와 같이, 연결을 닫으려는 IOException을 만날 때만 이렇게 SQLException이 발생한다고 한다. 그래서 결국 stmt가 닫히지 않아 자원 누수가 발생했고, 자원 풀이 40개 였으므로 이런식의 호출이 40번 발생한 후 풀이 가득차 블록된 경우이다.

...
Connection conn = null;
Statement stmt = null;
try {
	conn = connectionPool.getConnection();
    stmt = conn.createStatement();
} finally {
	if (stmt != null) stmt.close();
    if (conn != null) conn.close();
}

 

 

외양간 고치기?

• 코드 리뷰로 이런 버그를 잡을 수 있을까? -> 코드 검토자가 오라클 JDBC 드라이버의 내부를 알고 있거나 리뷰 팀이 메서드마다 몇 시간을 들여야만 가능할 것이다.
• 테스트를 더 많이 했다면 예방할 수 있을까? -> 그럴 수도 있다. 하지만 어디를 봐야 할지 알면 그것을 찾는 테스트를 만드는 건 쉽다. 일반 테스트 프로파일은 버그를 드러낼 정도로 이 방법을 충분히 수행하지 않았다.
• 이런 버그 하나하나가 모두 제거되기를 기대하는 것은 환상일 뿐이다.
• 이 지점에서 가장 심각한 문제는 한 시스템의 버그가 관련이 있는 다른 모든 시스템으로 전파될 수 있다는 사실이다.
• 버그를 예방할 방법을 찾는 것보다 더 나은 질문은 '한 시스템의 버그가 다른 시스템에 영향을 미치지 않게 하는 방법은 무엇인가?' 이다.