Quiz: WAR Deployment Without Downtime

톰캣 병행 배포(app##001.war, app##002.war)에서 기존 세션을 가진 사용자의 요청은?

• 무조건 가장 높은 버전(##002)으로 간다
• 세션이 만들어졌던 버전(##001)으로 계속 간다
• 무작위로 분배된다
• 오류가 발생한다

병행 배포의 버전 문자열을 ##1, ##2, ##10 으로 붙였을 때 생기는 문제는?

• 톰캣이 세 자리 이상 버전을 지원하지 않는다
• 세션이 공유되어 데이터가 섞인다
• WAR 전개가 실패한다
• 문자열 비교로 정렬되므로 ##10 이 ##2 보다 낮은 버전으로 취급된다

DB 스키마가 함께 변경되는 릴리스에 병행 배포를 쓰기 어려운 이유는?

• 두 버전이 같은 DB 를 보는데 스키마 기대가 다르면 둘 중 하나가 깨지기 때문
• 톰캣이 DB 연결을 버전별로 분리하지 못해서
• 병행 배포는 세션을 지원하지 않아서
• WAR 크기가 커지기 때문

큰 WAR 를 네트워크 너머에서 webapps 로 직접 복사할 때 발생할 수 있는 문제와 그 해결책은?

• 복사에 시간이 오래 걸릴 뿐 전개는 완료된 뒤에 시작되므로 문제가 없다
• 복사 중에 톰캣이 반쪽 파일을 전개하려다 실패한다 — 임시 이름으로 복사 후 mv 로 옮긴다
• 네트워크로 옮긴 WAR 는 자동 전개 대상에서 빠져 수동으로 풀어야 한다
• 전개 실패를 감지한 톰캣이 스스로 재기동하면서 다른 웹앱까지 끊긴다

배포 스크립트에서 '전개 완료 폴링' 없이 복사 직후 성공을 출력하면 생기는 가장 큰 문제는?

• 전개를 기다리지 않으므로 배포 창 안에 작업을 끝내기 어려워진다
• 실패한 배포를 성공으로 보고하게 되어, 문제가 사용자 신고로 발견된다
• 전개 로그와 배포 로그의 시각이 어긋나 추적이 어려워진다
• 전개 도중 파일이 잠겨 WAR 가 손상된 채로 남을 수 있다

운영 조직이 이미 WAS 단위로 기동·감시·백업 절차를 표준화한 상황에서, 신규 서비스만 실행 가능 JAR 로 가려 할 때 고려해야 할 실제 비용은?

• JAR 파일이 WAR 보다 커서 스토리지 비용이 증가한다
• JAR 는 자바 버전을 선택할 수 없다
• 그 한 서비스를 위해 별도의 운영 절차·감시 항목·장애 대응 문서가 새로 필요해진다
• JAR 는 로그를 남길 수 없다