Release 의 모든 것 (15장)

Release 의 모든 것 (15장) 의 내용 중, 인상적이었던 부분을 발췌 및 요약합니다.

사례 연구 : 고객에게 짓밟히다.

시스템 출시일에 발생할 수 있는 예상치 못한 일들

QA 지향

통합 프로젝트는 결국 콘웨이의 법칙을 따른다.

시스템을 설계하는 조직은 그 조직의 의사소통 구조를 모방한 구조의 설계를 만들어내도록 제약을 받는다.

안정성 패턴을 적용해서 전체 시스템을 구축했다고 하더라도 전혀 새로운 시스템이란 말은 운영 환경에서 어떻게 돌아갈지는 아무도 모른다는 뜻이다.
예를 들어, 운영 환경에는 QA 환경에는 없는 방화벽이 있을 수도 있고, 여러 인스턴스로 클러스터가 구성되어야 할 수 도 있다. 당연히, 테스트 환경과 운영 환경을 같게 만들 수는 없으니 이 불일치를 무시하면서 넘어간다.
심지어, 호스트명, 포트 번호, URL, 데이터베이스 연결 매개변수 와 같은 운영 환경에서 바뀌어야 할 것 같아 보이는 속성 목록들도 수십개의 파일에 흩어져 있을 수 있다. 만약에 DB 1개의 비밀번호를 변경하기 위해 수십 개의 서버에 수백 개의 파일을 수정해야 한다고 상상해봐라.
이런 문제를 해결하기 위해 간접화 단계를 추가해야 한다. 애플리케이션 코드 기반과 별도로 유지되는 속성 재정의 구조를 만들어서, 속성 각각이 정확히 한 곳에 존재하도록 구조화해야 한다.

부하 테스트

부하 테스트의 요건으로 사용자 25,000 명이 있다고 생각해보자. 그런데 사용자 25,000 명이란 것은 애매한 기준이다.
사용자 100% 가 첫 페이지만 보고 떠나는 경우와 사용자 100% 가 실제로 구입할 때를 비교하면, 처리 능력의 차이가 있을 것이기 때문이다. 심지어 네트워크 요청은 짧게 불연속적으로 연이어서 도달한다.
우리는 식별 가능한 연속된 요청을 세션이라고 구분한다. 그러나, 서버는 다시 클릭하지 않을 사용자와 아직 클릭하지 않은 사용자를 구분할 방법이 없다. 따라서, 서버는 사용자의 마지막 클릭 이후 일정 시간 동안 세션을 살리고, 세션 수는 언제나 실제 사용자 수보다 많이 집계된다.
이런 상황에서, 25000 활성 세션이라는 목표를 다시 생각해보자.

대중에 의한 살인

부하 테스트를 성공적으로 마치더라도 출시 일에 시스템이 무너졌다. 사이트를 죽인 것은 세션 수 였다. 세션은 특히 메모리를 소비한다. 부하 테스트는 실제 브라우저를 사용하는 사용자를 모방한 스크립트로 수행된다.
이 가상 사용자는 페이지를 링크로 이동하며, 쿠키를 사용해 세션을 추적한다. 하지만 현실의 사용자는 그렇지 않다.
대표적으로 검색 엔진이다. 검색 엔진은 사이트의 변화를 알아차리고, 캐시된 페이지를 모두 다시 가져간다. 기존에 사이트를 접속하려고 시도하기에 404 트래픽을 위한 세션이 다량으로 만들어지며 SEO 주스를 초기화한다. 또 다른 문제는 검색 엔진이 신규 페이지를 수집해가고, 웹 수집기와 샵봇의 공격을 받았다.

테스트 간극

우리는 애플리케이션을 원래 사용 방식대로 테스트했다. 어떤 부하 테스트 스크립트도 동일 URL 을 쿠키 없이 초당 100회 접속하려고 하지 않았다. 테스트와 관련된 다음의 농담이 있다.

테스트 담당자가 술집에 들어간다.
맥주 한잔을 시킨다.
맥주 0잔을 시킨다.
맥주 99999잔을 시킨다.
도마뱀을 시킨다.
맥주 -1 잔을 시킨다.
sdasfdf 을 시킨다.

부하 테스트도 이와 같아야한다. 잡음과 혼돈을 만들어내야 한다. 뿐만 아니라 애플리케이션 개발자가 심각한 상황을 차단하는 안전 장치를 구축해야 한다.

결론

상황이 발생하면, 신속한 대응 활동은 공통적인 주제를 공유한다.

1. 임시 처방만큼 영구적인 것은 없다.
2. 모두 주로 매출이 줄어든다는 측면에서 엄청난 비용을 지불한다.
3. 손실이 필요하지 않았을 수도 있다. 사이트 출시 2년 후, 동일 모델 서버로 4배 이상의 부하를 처리할 수 있었다. 소프트웨어가 그만큼 개선되었기 때문이다.