엣지 함수, 원본에 가기 전에 처리하기

원본에 가기 전에 끝낼 수 있는 일을 가립니다

사용자 가까운 지점에서 코드를 실행할 수 있게 되면, 원본까지 왕복하지 않고 처리할 수 있는 작업이 생깁니다. 적합한 작업은 네 가지입니다. 첫째는 주소 변경과 리다이렉트입니다. 둘째는 헤더 추가나 수정입니다. 셋째는 간단한 접근 제어입니다. 넷째는 지역이나 기기에 따라 다른 내용으로 보내는 분기입니다. 모두 공통점이 있습니다. 데이터베이스를 보지 않고 요청 정보만으로 판단할 수 있다는 점입니다. 반대로 사용자 데이터를 조회해야 하는 작업은 원본이나 데이터 계층이 필요하므로 엣지에서 끝낼 수 없습니다.

엣지에 두면 안 되는 것들

엣지 실행 환경에는 제약이 있습니다. 실행 시간과 메모리가 제한되고, 쓸 수 있는 기능도 제한됩니다. 그래서 무거운 계산이나 큰 데이터 처리를 올리면 제한에 걸립니다. 또 비밀 정보를 다룰 때 주의가 필요합니다. 엣지 코드가 비밀을 쓰려면 그 값을 배포해야 하므로, 권한이 넓은 비밀은 올리지 않습니다. 세 번째 제약은 상태입니다. 엣지는 여러 지점에서 동시에 실행되므로 지점 간에 공유되는 상태를 가정할 수 없습니다. 횟수 제한처럼 전체 합계가 필요한 기능은 중앙 저장소가 필요합니다. 그래서 올릴 작업 목록에 이 세 제약을 대조합니다.

줄어드는 왕복 시간을 계산합니다

학습용 가정으로 계산합니다. 가정값은 월 요청이 1,200,000건이고 그중 20퍼센트가 리다이렉트나 헤더 변경으로 끝나는 요청이며, 원본까지 왕복이 0.08초라고 두겠습니다. 대상 요청은 240,000건이고 절감되는 대기 시간의 합계는 19,200초, 분으로는 320분입니다. 이것이 중간 계산값입니다. 최종 효과에는 원본 부하 감소가 더해집니다. 240,000건이 원본에 도달하지 않으므로 원본은 그만큼 여유가 생깁니다. 다만 엣지 실행 자체에 요금이 발생하므로, 절감되는 원본 처리 비용과 엣지 실행 비용을 같은 기준으로 비교해야 합니다.

디버깅과 배포가 어려워집니다

결론을 뒤집는 조건은 운영 난이도입니다. 엣지 코드는 여러 지점에서 돌기 때문에 문제가 특정 지역에서만 나타날 수 있고, 로그를 모으기도 어렵습니다. 그래서 엣지에 로직을 많이 올리면 장애 조사 시간이 길어집니다. 올리는 기준을 '단순하고 거의 바뀌지 않는 작업'으로 좁히는 것이 안전합니다. 두 번째 조건은 배포 반영입니다. 엣지 코드 변경이 모든 지점에 퍼지기까지 시간이 걸릴 수 있어, 배포 직후 일부 지점은 예전 코드로 동작합니다. 그래서 예전 코드와 새 코드가 함께 돌아도 문제가 없도록 변경을 설계해야 합니다.

성능 최적화 실행 전 점검표

• 요청 정보만으로 판단 가능한 작업만 엣지로 올렸다
• 실행 제한·비밀 범위·상태 공유 세 제약을 대조했다
• 엣지 실행 비용과 원본 처리 절감을 같은 기준으로 비교했다
• 예전 코드와 새 코드가 함께 돌아도 되게 변경을 설계했다