CloudFront ARN 한도를 넘긴 날 v2를 만들었다

신규 사이트 한 개의 deploy 가 실패했습니다.

실패 메시지에는 CloudFront 의 어떤 자원이 더 못 만들어진다는 내용이 적혀 있었습니다. 정확한 한도 숫자보다는 한도에 닿았다는 신호가 먼저 눈에 들어왔습니다. 그 자원은 portfolio 안의 모든 사이트가 공유하는 종류였고, 한 portfolio 가 한 AWS 계정 안에서 가질 수 있는 개수 자체에 상한이 있었습니다.

지금까지 portfolio 의 모든 신규 사이트는 같은 공유 자원을 참조하고 있었습니다. bal-pe-kr-rewrite 라는 이름의 자원이 하나 있고, 그 ARN 을 CDK 스택에서 받아서 신규 사이트의 CloudFront distribution 에 연결하는 흐름이었습니다. 한 자원을 여러 사이트가 참조하는 구조였고, 자원 자체의 개수는 늘지 않으니까 한도와 무관하다고 생각했습니다.

문제는 자원 한 개가 가질 수 있는 부속 attachment 한도였습니다. 100 개를 한참 넘은 시점에 그 부속 한도가 채워졌고, 새로 사이트 한 개를 더 붙이려고 하면 그 자원 쪽에서 거부가 떨어지는 흐름이었습니다.

deploy 가 멈춘 그 자리에서 두 가지 선택지를 떠올렸습니다.

기존 자원 안에서 빈자리를 만들어 신규 한 개를 끼워 넣을지, 아니면 새 자원을 한 개 더 만들고 신규 사이트들을 새 자원 쪽으로 보낼지. 첫 번째 쪽은 임시 처방이었습니다. 두 번째 쪽은 한 번의 작업으로 한도 문제 자체를 다음 100 개까지 미루는 처방이었습니다.

bal-pe-kr-rewrite-2 를 만들었습니다. 이름의 -2 는 자기 설명적입니다. 설정·동작·정책은 -1 과 같고, 다른 점은 attachment 한도가 새 자원이라 다시 0 부터 시작한다는 것뿐입니다.

기존 사이트들을 -2 로 옮기는 작업은 하지 않기로 했습니다. 옮기는 작업은 사이트당 CloudFront distribution 재구성을 동반하고, 그 사이에 짧은 다운타임이 있습니다. portfolio 전체에 적용하면 그 다운타임이 100 개에 곱해집니다.

규칙을 박아두었습니다. 신규 사이트의 CDK 스택은 무조건 bal-pe-kr-rewrite-2 의 ARN 을 참조한다. 기존 ARN 을 그대로 복사하면 -1 쪽 한도를 다시 채우게 됩니다. agent 가 신규 사이트를 dispatch 할 때 이 규칙을 의식하지 않으면 같은 실패가 반복되고, 실제로 v2 분리 직후 며칠 사이에 같은 실패가 두세 번 더 일어났습니다.

이 작은 사건에서 한 가지를 적어둡니다. 한도 자체보다 한도에 닿은 감각이 더 중요한 신호였습니다. 자원이 -1 한 개로 충분하던 시절에는 그 자원의 attachment 수를 매주 보지 않았습니다. 보지 않으니까 한도에 다가가는 속도가 의식 바깥에 있었고, 닿은 순간에야 사건이 됐습니다. 자원이 -2 로 갈라진 다음에는 두 자원 모두의 attachment 수를 한 번씩 봅니다. -2 가 -1 의 한도에 다가가는 속도와 비슷한 속도로 차오르고 있어서, -3 이 필요한 시점도 멀지 않다는 감각이 같이 옵니다.

다음 한 번은 이 사건의 신호로 움직이려 합니다. -2 가 한도의 70% 쯤에 닿는 시점에 -3 을 먼저 만들어두는 것. 한도가 채워진 다음 만드는 자원과, 한도 전에 미리 만들어두는 자원은 같은 자원이지만 의사결정의 결이 다릅니다. 후자가 한 박자 빠른 흐름이고, 이번 -2 의 작업은 후자 쪽에 더 가까운 시점에 시작했어야 했습니다.