퍼센트 롤아웃

배포에는 오랫동안 두 상태만 있었습니다. 안 나갔거나, 전원이 보거나입니다. 새 기능을 켜는 순간 모든 사용자가 그것을 보게 되니, 결함이 하나 있으면 그것도 모든 사용자에게 동시에 갔습니다.

그래서 배포일 저녁은 늘 비슷했습니다. 금요일 6시에 새 편집기를 열고, 7시부터 문의가 들어오고, 9시에 어느 환경에서 저장이 안 되는지 파악한 뒤 새벽에 롤백을 걸었습니다. 되돌리기는 했지만 그 사이 저장에 실패한 사람이 몇천 명인지는 아무도 몰랐습니다.

팀이 배운 것은 테스트를 더 하자는 것뿐이었는데, 문제는 테스트로 잡히는 결함이 아니었습니다. 동시 접속자가 일정 규모를 넘어야 서버가 버티지 못하는 지점, 오래된 계정에만 남아 있는 데이터 형태처럼 실제 트래픽으로만 드러나는 것들이 있습니다.

퍼센트 롤아웃은 이 확인을 배포 이후로 옮긴 방식입니다. 결함이 남아 있다는 전제를 깔고, 그 결함을 겪는 사람 수를 최소로 유지한 채 찾아내는 것입니다.

가장 작은 집단에 먼저 열어 보는 카나리 릴리스를 통과한 다음, 비율을 계단처럼 올리는 단계가 이것입니다. 순서는 여섯입니다.

1. 스위치를 심습니다. 코드를 배포한 채 기능만 켜고 끄는 장치를 피처 플래그라고 하는데, 비율을 바꾸는 일이 전부 이 스위치 위에서 일어납니다.
2. 누구를 넣을지 정하는 기준을 만듭니다. 사용자 아이디를 해시로 바꿔 배정하는 방식이 기본입니다. 요청마다 무작위로 뽑으면 같은 사람이 새 화면과 옛 화면을 번갈아 보게 되어 문의부터 들어옵니다.
3. 볼 숫자와 중단 기준을 미리 적어 둡니다. 오류율, 응답 속도, 저장 성공률처럼 항목을 고르고, "오류율이 대조군보다 0.5퍼센트포인트 높으면 중단" 처럼 선을 숫자로 써 둡니다.
4. 비율을 올립니다. 1에서 5, 25, 50, 100으로 가는 식이고 단계마다 최소 몇 시간에서 하루를 둡니다. 1퍼센트에서 300명이 보던 화면을 25퍼센트로 올리면 7500명이 봅니다.
5. 단계마다 두 집단을 나란히 봅니다. 기능을 켠 집단과 끈 집단의 숫자를 같은 시간대에 견줍니다. 시스템에서 무슨 일이 벌어지는지 밖에서 알 수 있는 정도를 관측성이라고 부릅니다.
6. 100퍼센트에 닿으면 정리합니다. 코드에서 분기와 스위치를 걷어내고 옛 경로를 지웁니다.

중간에 숫자가 나빠지면 비율을 0으로 내립니다. 기능만 끄는 장치를 킬 스위치라고 하고, 배포를 다시 하지 않으므로 몇 초 만에 끝납니다. 원인을 밝힌 뒤에 끄는 것이 아니라 끄고 나서 원인을 찾습니다.

되돌리기가 값싼 변경에 맞습니다. 화면 하나를 바꾸거나 기능 하나를 더하는 일은 스위치를 내리면 원래대로 돌아갑니다.

사용자 수가 충분해야 성립합니다. 1퍼센트가 몇 명인지가 이 방식의 실효를 정합니다. 월 사용자가 3만 명이면 1퍼센트는 300명이고, 이 정도면 눈에 띄는 오류는 드러납니다. 하지만 5천 명뿐인 서비스에서 1퍼센트는 50명이라, 오류율이 올라도 한 건 차이여서 신호와 잡음이 구분되지 않습니다.

데이터를 다루는 방식이 바뀌는 변경에는 이것만으로 부족합니다. 새 저장 구조와 옛 구조가 한동안 함께 돌아야 하고, 비율을 내렸을 때 새 구조로 쌓인 데이터를 어떻게 할지가 남습니다. 사용자에게 보이지 않게 새 경로만 뒤에서 돌려 보는 다크 런치를 앞에 둡니다.

사용자끼리 보는 화면이 달라진다는 점도 한계입니다. 협업 문서 도구에서 한 사람은 새 공유 화면을 보고 같은 팀의 다른 사람은 옛 화면을 보면, 서로 다른 설명을 하다가 지원 문의가 늘어납니다. 이런 기능은 사람 단위가 아니라 팀 단위로 배정합니다.

지표가 좋아졌는지 판정하는 도구도 아닙니다. 두 안을 무작위로 나눠 보여 주고 결과를 비교하는 실험을 A/B 테스트라고 하는데, 비율 롤아웃의 집단은 크기가 단계마다 바뀌어 그 비교에 쓸 수 없습니다. 여기서 보는 것은 망가지지 않았는지입니다.

"지금 5퍼센트인데 오류율 차이 없습니다. 오후에 25로 올리겠습니다."

앞 단계 기준을 통과했으니 다음 계단으로 가겠다는 보고입니다.

"25에서 저장 실패가 늘었어요. 0으로 내리고 원인부터 보죠."

기능을 즉시 끄고 그다음에 조사하자는 결정입니다.

"이번 건은 50에서 이틀 두고 봅시다. 월말 트래픽까지 지나가야 알 것 같아요."

부하가 몰리는 시기를 포함해서 확인하자는 뜻입니다.

페이지덱이 새 편집기를 열 때가 그랬습니다. 태오가 스위치를 심어 배포해 두고 1퍼센트를 열어 400명이 보게 했고, 오류율이 같은 것을 확인한 뒤 5퍼센트로 올렸습니다. 25퍼센트에서 처음 문제가 나왔습니다. 문서를 100개 넘게 가진 계정에서 목록 불러오는 시간이 세 배로 늘어난 것인데, 그런 계정이 전체의 1퍼센트도 되지 않아 앞 단계에서는 한 명도 걸리지 않았습니다.

지현이 그 자리에서 비율을 0으로 내렸고, 태오가 사흘 뒤에 고쳐 다시 25부터 시작했습니다. 전원 공개로 한 번에 열었다면 문서가 많은 계정 전부가 같은 날 같은 일을 겪었을 것입니다.

비율을 나눠 올리기만 하면 안전해진다고 생각하는 경우가 가장 많습니다. 단계가 있으니 그 자체로 장치가 생긴 것처럼 보여서 그렇습니다. 하지만 단계를 나누는 값은 단계 사이에 숫자를 보는 데서 나옵니다. 정해 둔 항목이 없거나 보는 사람이 없으면 1퍼센트든 50퍼센트든 문의가 들어올 때까지 모르고, 그러면 옛 방식과 다를 것이 없는 채로 일정만 며칠 길어집니다.

100퍼센트에 닿으면 끝났다고 보는 것도 흔합니다. 사용자에게는 끝난 일이 맞지만 코드에는 분기가 남아 있습니다. 이것을 치우지 않으면 다음 기능을 만들 때 옛 경로까지 함께 고려해야 하고, 스위치가 스무 개쯤 쌓인 코드에서는 어느 것이 살아 있는지 아무도 모르는 상태가 됩니다.