콜드 스타트

서버를 사서 24시간 켜 두던 시절에는 이런 지연이 없었습니다. 프로그램은 한 번 뜬 뒤 계속 떠 있었고, 첫 요청이든 만 번째 요청이든 같은 속도로 답했습니다. 대신 새벽 3시에 아무도 쓰지 않는 동안에도 기계는 돌았고 요금은 똑같이 나갔습니다. 하루 중 실제로 바쁜 시간이 두세 시간뿐인 서비스는 나머지 스무 시간을 빈 채로 사는 셈이었습니다.

클라우드가 쓴 만큼 내는 계산법을 가져오면서 이 낭비를 없앨 길이 열렸습니다. 요청이 없는 동안 실행 환경을 아예 꺼 두면 그 시간에는 돈을 내지 않습니다. 어떤 서비스에서는 서버 비용이 월 200만 원에서 20만 원으로 떨어졌습니다.

대가가 하나 생겼습니다. 꺼진 것을 다시 켜는 데 시간이 든다는 점입니다. 인프라는 바닥을 어디서 구해 오는지(형태), 그 위에 프로그램을 무엇에 담는지(실행 환경), 요청이 어떤 길로 오는지(네트워크), 사람이 몰릴 때 어떻게 키우는지(확장), 구성을 어디에 적어 두는지(관리)로 갈리는데, 콜드 스타트는 그렇게 짜인 구성 때문에 생기는 첫 지연이라 성능 갈래에 놓입니다.

실무에서는 대체로 버그처럼 나타납니다. 태오가 데모를 앞두고 로그인을 눌렀더니 4초가 걸렸는데, 이상해서 다시 눌러 보니 0.2초 만에 끝났습니다. 다시 재현하려 해도 되지 않고, 점심시간이 지난 뒤 처음 누를 때만 또 느렸습니다. 코드를 고친 적도 없고 서버 상태도 정상이어서, 이름을 모르면 원인을 찾는 데 하루를 씁니다.

꺼져 있던 자리에 요청이 들어오면 우리 코드가 실행되기 전에 네 가지가 순서대로 일어납니다.

1. 자리 확보. 이 요청을 처리할 기계나 컨테이너, 그러니까 프로그램과 실행에 필요한 것만 묶어 둔 단위를 어디에 띄울지 정하고 그 자리를 잡아 둡니다.
2. 실행 환경 시작. 그 자리에 언어의 실행기를 올립니다. 자바나 닷넷처럼 시작할 때 준비할 것이 많은 쪽은 여기서 1초 이상을 씁니다.
3. 코드 적재와 초기화. 우리가 올린 코드와 그것이 쓰는 외부 라이브러리를 읽어 들이고, 데이터베이스 연결이나 설정값 읽기 같은 준비 작업을 합니다.
4. 실제 처리. 여기서부터가 평소에 보던 응답 시간입니다.

13번에 드는 시간이 콜드 스타트입니다. 가벼운 함수는 0.2초, 라이브러리를 많이 쓰는 자바 쪽은 35초까지 갑니다. 같은 코드가 한 번 깨어난 뒤에는 20~50밀리초에 끝나니 열 배에서 백 배 차이입니다.

한 번 깨어난 실행 환경은 곧바로 꺼지지 않고 몇 분에서 수십 분 동안 살아 있습니다. 그동안 들어온 요청은 빠릅니다. 문제는 그 창이 닫힌 뒤 첫 요청과, 한꺼번에 몰려서 살아 있는 자리로 감당이 안 될 때입니다. 100명이 동시에 들어오면 살아 있는 자리 세 개를 뺀 97명이 각자 콜드 스타트를 겪습니다.

줄이는 방법은 세 갈래입니다. 3번을 가볍게 하는 쪽은 안 쓰는 라이브러리를 걷어내 코드 묶음 크기를 줄이는 것이고, 2번을 피하는 쪽은 시작이 빠른 언어를 고르는 것입니다. 마지막은 아예 안 꺼지게 두는 쪽인데, 최소 몇 개를 항상 켜 두도록 설정하면 그만큼 비용이 다시 붙습니다. 절약과 응답 속도를 맞바꾸는 조절 손잡이라고 보면 맞습니다.

가장 자주 나오는 자리는 서버리스입니다. 서버를 직접 관리하지 않고 함수 단위로 올려 두면 요청이 올 때만 실행되는 방식이라, 안 쓰는 동안 꺼진다는 성질이 그대로 콜드 스타트로 이어집니다.

오토스케일링에서도 같은 일이 생깁니다. 부하에 따라 서버 대수를 자동으로 늘리고 줄이는 기능인데, 늘리기로 결정한 순간 새 서버가 준비되기까지 30초에서 2분이 걸립니다. 그 사이에 들어온 요청은 기존 서버에 몰립니다. 그래서 규칙을 부하 80퍼센트가 아니라 60퍼센트에서 늘리도록 미리 당겨 둡니다.

캐싱을 두고도 같은 말을 씁니다. 한 번 만든 결과를 저장해 두었다가 다시 쓰는 방식이라, 저장소를 비우고 다시 띄운 직후에는 모든 요청이 원본까지 다녀와야 합니다. 배포 직후 몇 분 동안만 느린 현상이 대개 이것입니다.

문제가 되는 정도는 자리마다 다릅니다. 밤에 도는 정산 작업은 3초쯤 늦게 시작해도 아무도 모르지만, 결제 버튼 뒤의 API, 그러니까 프로그램끼리 주고받기로 약속한 창구가 4초를 끌면 사용자는 결제가 실패한 줄 알고 다시 누릅니다.

"이 API 콜드 스타트가 3초라 결제 흐름에는 못 씁니다."

사용자를 기다리게 하는 자리에는 이 구조를 쓰지 말자는 반대 의견입니다.

"아침 첫 요청만 느리다는 제보요. 콜드 스타트 같은데 로그 좀 볼게요."

밤새 요청이 없어 실행 환경이 꺼진 탓으로 보인다는 뜻입니다.

"최소 인스턴스 2개 켜 두죠. 월 8만 원이면 첫 응답 3초가 없어져요."

돈을 더 내고 지연을 없애는 쪽을 고르자는 제안입니다.

페이지덱에서는 지난 분기에 파일 미리보기 기능을 서버리스로 옮겼습니다. 평균 응답 시간은 180밀리초로 오히려 좋아졌는데, 고객 문의는 늘었습니다. 태오가 들여다보니 평균은 살아 있는 자리에서 처리된 대다수 요청이 만든 값이었고, 하루에 몇십 건씩 4초가 걸린 요청이 그 평균에 묻혀 있었습니다.

그래서 태오는 응답 시간을 평균 대신 느린 쪽 1퍼센트 기준으로 다시 그렸습니다. 그 그림에서는 4초가 뚜렷하게 보였습니다. 최소 인스턴스를 두 개 켜 두는 것으로 해결했고, 비용은 월 8만 원이 늘었습니다.

코드를 최적화하면 없앨 수 있다고 생각하기 쉽습니다. 느린 응답은 대개 코드 탓이었으니 자연스러운 추측입니다. 그런데 콜드 스타트의 상당 부분은 우리 코드가 실행되기 전에 이미 지나간 시간입니다. 코드를 아무리 다듬어도 실행 환경이 뜨는 시간은 남습니다. 줄이는 손잡이는 묶음 크기, 언어 선택, 켜 두는 개수 쪽에 있습니다.

평균 응답 시간만 보다가 못 보고 지나가는 일도 흔합니다. 콜드 스타트는 전체 요청의 1~5퍼센트에서만 일어나서, 평균으로 접으면 180밀리초처럼 멀쩡한 숫자가 나옵니다. 그대로 두면 지표는 정상인데 문의는 계속 들어오는 상태가 이어집니다. 느린 쪽 1퍼센트와 5퍼센트를 따로 보면 그 자리에서 드러납니다.