프록시 박스 열여덟 대를 네 대로 통합하는 설계를 세우고 착수 직전에 계획을 다시 읽었다. 확인하지 않고 그럴 것이라고 적어 둔 문장이 넷 있었고 설계는 그 위에 서 있었다.
Table of contents
Open Table of contents
무너지면 설계를 다시 짜야 하는 가정
넷 가운데 하나는 나머지와 성격이 달랐는데 연결 요청이 호스트명 기반이라 대상별 비용 귀속이 가능하다는 문장이었다. 통합 설계의 핵심이 대상별로 비용을 나누는 것이므로 이것이 틀리면 설계 자체가 성립하지 않는다.
주소 기반이라면 어느 마켓인지 구분할 수 없고 주소는 공유되거나 자주 바뀐다. 그래서 가장 큰 리스크부터 확인하기로 했는데 그것이 무너지면 나머지를 확인하는 일 자체가 의미가 없기 때문이다.
상태를 바꾸지 않는 조사
성격이 다른 대표 세 대를 골랐는데 트래픽이 많은 것과 최근 추가된 다른 배포판과 가장 오래된 것이었다. 확인 항목을 원격 명령 하나에 모두 넣어 한 번에 조회했다.
접근 로그와 설정 파일과 프로세스의 자원 한계를 읽기만 하고 아무것도 쓰지 않았다. 착수 전 조사이므로 상태를 바꾸지 않는 것이 전제였다.
최대 리스크의 해소
로그를 보니 연결 요청에 호스트명이 그대로 찍히고 있었고 주소가 아니었다. 호스트와 마켓의 매핑으로 비용을 나눌 수 있다는 뜻이므로 설계의 최대 리스크가 사라졌다.
이 확인에 걸린 시간은 몇 분이었다. 착수 후에 알았다면 통합을 마친 뒤에 설계를 다시 짜야 했을 사안이다.
스펙으로 바뀐 나머지 셋
나머지 항목들은 리스크가 아니라 구체적 스펙으로 바뀌었다. 로그 형식이 응답 바이트만 기록하고 있어 양방향 집계를 하려면 형식에 요청 쪽을 명시해야 했다.
클라이언트 주소는 전부 공인 주소라 내부 경로 비중이 클 것이라는 가정이 틀렸고 로드밸런서 구성이 달라졌다. 파일 디스크립터 기본값이 배포판마다 달라 단일 이미지에서 낮은 쪽에 맞춰지지 않게 명시적으로 올려야 했고 암호화 처리 설정은 박스마다 제각각이라 누적된 편차를 어느 쪽으로 통일할지 정해야 했다.
나중에 알면 비싼 항목들
이것들을 확인하지 않고 시작했다면 비용이 어디서 발생하는지도 그려 봤다. 로그 형식은 통합 몇 주 뒤에 마켓별 트래픽을 못 뽑는다는 말을 듣고 로그를 다시 쌓아야 한다.
자원 한계값은 트래픽이 몰리는 날 특정 박스만 죽고 원인 추적에 하루가 든다. 설정 편차는 특정 마켓만 안 되는데 이유를 알 수 없는 상태를 만들며 셋 다 지금은 명령 하나로 끝나는 확인이었다.
정리
- 계획에서 확인하지 않고 적은 가정을 착수 전에 골라낸다
- 무너지면 설계를 다시 짜야 하는 것부터 확인한다
- 착수 전 조사는 읽기 전용으로 한다
- 성격이 다른 대표 몇 대를 명령 하나로 본다
- 결과는 리스크 해소와 스펙 확정으로 갈린다
- 로그 형식과 기본 한계값은 나중에 알면 비싸다
- 박스마다 다른 설정은 누적된 편차다
- 통일할 때 어느 쪽에 맞출지 먼저 정한다