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