카나리 릴리스

배포는 오랫동안 켜거나 끄거나 둘 중 하나였습니다. 금요일 밤에 새 버전을 올리면 그 순간부터 모든 사용자가 새 코드를 씁니다. 테스트 환경에서 아무 문제가 없었으니 괜찮을 것이라는 판단이 유일한 근거였습니다.

그런데 테스트 환경에서 잡히지 않는 결함이 있습니다. 실제 사용자만 만드는 조건에서 나는 것들입니다. 2015년에 만든 오래된 계정의 설정 값이 지금 형식과 달라서 새 코드가 읽지 못하거나, 한 팀이 문서 8천 건을 쌓아 둔 탓에 목록 화면이 30초씩 걸리는 식입니다.

문제가 전원에게 동시에 열린 뒤 드러나면 대응은 늘 늦습니다. 고객 문의가 쌓이기 시작할 때쯤 개발팀이 알아채고, 원인을 찾고, 되돌리는 배포를 다시 합니다. 그 사이에 몇천 명이 깨진 화면을 봤고 그중 일부는 다시 들어오지 않습니다. 장애의 크기는 결함의 심각도보다 그 결함에 노출된 사람 수로 정해지는데, 전원 배포는 그 수를 처음부터 최대로 잡아 놓고 시작합니다.

카나리 릴리스는 그 수를 손으로 조절합니다. 새 코드를 아주 작은 집단에만 먼저 열어 두고, 그 집단에서 이상이 보이면 나머지는 겪지 않은 채로 끕니다. 이름은 탄광에서 유독가스를 먼저 알아채던 카나리아에서 왔습니다. 소수가 먼저 겪어 나머지를 지키는 자리라는 뜻입니다.

기능을 스위치 뒤에 넣어 꺼 둔 채로 배포하고, 아주 작은 집단에만 켠 뒤, 미리 정해 둔 항목을 비교해 열지 닫을지를 정합니다.

1. 피처 플래그를 심고 꺼 둔 채로 배포합니다. 피처 플래그는 코드를 올려 둔 채 기능만 켜고 끄는 스위치입니다. 이 스위치가 없으면 대상을 좁히는 일도 되돌리는 일도 배포를 다시 해야 하므로 절차 전체가 성립하지 않습니다.
2. 누구에게 먼저 열지 정합니다. 사내 계정처럼 문제가 나면 바로 말해 줄 수 있는 쪽을 맨 앞에 두고, 그다음이 전체의 1퍼센트입니다. 계약 규모가 크거나 장애에 민감한 고객사는 이 단계에서 빼 둡니다.
3. 무엇을 볼지 미리 적습니다. 오류율, 응답 속도, 기능의 성공률처럼 나빠졌는지 판단할 항목과 그 기준선을 켜기 전에 정합니다. 켜고 나서 숫자를 보며 무엇이 문제인지 고르기 시작하면 대개 괜찮다는 쪽으로 읽게 됩니다.
4. 켜고 정해 둔 시간만큼 지켜봅니다. 보통 몇 시간에서 하루입니다. 이때 새 기능을 켠 집단과 끄고 있는 집단을 나란히 놓고 비교합니다. 켠 집단의 숫자만 보면 원래 그 시간대가 느린 것인지 새 코드 탓인지 구분할 수 없습니다. 시스템 안에서 무슨 일이 벌어지는지 밖에서 알 수 있는 정도를 관측성이라고 하는데, 이것이 갖춰지지 않은 팀은 1퍼센트에 열어 놓고도 나빠졌는지 모릅니다.
5. 판정합니다. 이상이 없으면 노출 비율을 단계적으로 올리는 퍼센트 롤아웃으로 넘어가고, 나빠졌으면 킬 스위치로 기능만 즉시 끕니다. 끄는 데 배포가 필요 없어 몇 초면 끝납니다.

실제 사용자 데이터 위에서만 드러나는 결함을 찾을 때 잘 맞습니다. 오래된 계정, 큰 규모의 팀, 예상 못 한 사용 순서 같은 조건은 테스트 환경에서 만들어 낼 수 없습니다. 부하에 민감한 변경에도 잘 맞습니다. 새 조회 방식이 데이터베이스에 얼마나 부담을 주는지는 진짜 트래픽 아래에서만 측정됩니다.

반대로 드물게 나는 결함은 이 방식으로 잡지 못합니다. 1퍼센트가 300명이라면, 1천 명 중 한 명에게만 나는 오류는 그 집단에서 한 번도 안 나타날 가능성이 큽니다. 하루를 지켜보고 괜찮다고 판단해 전원에게 열면 그때 300건이 한꺼번에 들어옵니다. 그래서 카나리를 통과했다는 말은 안전하다는 뜻이 아니라 큰 문제는 없었다는 뜻입니다.

대상 집단이 전체를 대표하지 못할 때도 결과가 어긋납니다. 사내 계정에만 열어 두면 사용 방식이 한쪽으로 쏠려 있어 실제 고객이 겪을 문제를 못 봅니다. 데이터를 새 형식으로 옮기는 작업이 같이 붙어 있을 때도 다루기 어렵습니다. 스위치를 꺼도 이미 새 형식으로 쌓인 데이터는 남아 있어서, 그 데이터를 옛 코드가 어떻게 읽을지를 미리 정해 둬야 합니다.

"일단 사내 계정에만 카나리로 열고 내일 오전에 보죠."

전원 배포를 미루고 소수 집단에서 하루치 숫자를 먼저 쌓아 보자는 제안입니다.

"카나리에서 오류율이 0.3에서 1.8로 튀어서 껐습니다."

작은 집단에서 이상이 잡혀 비율을 올리지 않고 되돌렸다는 보고입니다.

"카나리 집단에 그 고객사는 빼 주세요."

장애를 겪으면 곤란한 고객을 대상에서 제외해 달라는 요청입니다.

페이지덱이 문서 저장 방식을 새로 바꿀 때의 일입니다. 태오가 화면에는 아무 변화가 없게 두고 새 저장 경로를 먼저 돌려 본 뒤, 사내 계정 45개에 기능을 켰습니다. 반나절 동안 아무 일도 없어서 전체의 1퍼센트로 넓혔더니 그때 저장 실패가 보이기 시작했습니다. 문서에 이미지가 40장 넘게 들어 있는 경우에만 나는 오류였고, 사내 계정에는 그런 문서가 하나도 없었습니다.

지현은 킬 스위치를 내리고 그날 회고에서 카나리 대상 정하는 규칙을 고쳤습니다. 사내 계정으로 시작하되 실제 고객 1퍼센트까지는 무조건 거치고, 그 구간에 문서가 무거운 팀이 포함됐는지 확인한 뒤 넘어가기로 했습니다.

카나리 릴리스를 실험으로 아는 경우가 많습니다. 일부에게만 새것을 보여 주고 결과를 비교한다는 모양이 실험과 같아서 그렇습니다. 하지만 보는 것이 다릅니다. 실험은 새 안이 옛 안보다 더 좋은지를 묻고, 카나리는 새 코드가 망가졌는지를 묻습니다. 그래서 카나리는 전환율이 올랐는지 따지지 않고 오류율과 속도만 봅니다. 이 둘을 섞으면 대개 판단이 늦어집니다. 성과 지표가 유의미해질 때까지 기다리느라 명백한 오류를 켠 채로 며칠을 보내게 됩니다.

켰다가 문제가 없으면 끝이라고 생각하는 것도 흔합니다. 카나리는 시작 단계일 뿐입니다. 1퍼센트에서 보이지 않던 부하 문제가 25퍼센트에서 처음 드러나는 일이 흔하므로, 비율을 올리는 단계마다 같은 항목을 다시 봅니다. 여기서 멈추고 곧바로 전원에게 열면 카나리를 돈 이유가 사라집니다.