엣지 컴퓨팅

서비스의 계산은 오랫동안 한 곳에서만 일어났습니다. 서버를 미국 동부에 두었다면 서울에서 접속한 사람의 요청도 태평양을 건너갔다가 돌아와야 했습니다. 이 왕복에만 200밀리초가 듭니다. 화면 하나를 그리는 데 그런 왕복이 네댓 번 필요하면 1초가 그냥 사라지고, 코드를 아무리 빠르게 고쳐도 이 시간은 줄지 않습니다. 빛이 지구를 도는 속도가 정해져 있기 때문입니다.

먼저 해결된 것은 파일이었습니다. CDN이 그림이나 스크립트처럼 모두에게 똑같이 나가는 자원을 세계 여러 거점에 미리 복사해 두면서, 서울 사용자는 서울 거점에서 10밀리초 만에 파일을 받게 되었습니다. 남은 문제는 사람마다 달라지는 부분이었습니다. 로그인한 사람인지 확인하고, 그 사람의 언어에 맞는 페이지로 보내고, 실험 대상인지 갈라내는 판단은 미리 복사해 둘 수 없어서 여전히 중앙 서버 몫이었습니다.

그래서 이런 회의가 반복됐습니다. 아시아 사용자 이탈률이 높다는 지표를 놓고 고칠 곳을 찾는데, 코드에도 데이터베이스에도 느린 구간이 없습니다. 남는 답은 거리 하나이고, 그러면 대책은 지역마다 서버를 한 벌씩 세우는 것뿐이었습니다. 운영할 서버가 세 배로 늘고, 데이터를 어느 쪽에 맞출지를 두고 또 다른 문제가 시작됩니다.

엣지 컴퓨팅은 서버를 통째로 옮기는 대신 판단하는 부분만 가까이 내보냅니다. 이미 세계 곳곳에 파일을 놓아둔 거점이 있으니, 그 자리에서 코드도 조금 돌게 만들자는 발상입니다.

먼저 중앙 서버가 하던 일 가운데 거점으로 내보낼 조각을 고르는 것으로 시작합니다. 이후 절차는 다섯 단계입니다.

1. 옮길 처리를 고릅니다. 입력이 작고 결과가 금방 나오는 판단이 대상입니다. 쿠키를 읽어 로그인 여부를 확인하는 일, 접속 국가에 따라 다른 주소로 보내는 일, 실험군과 대조군을 가르는 일이 여기 들어갑니다.
2. 그 조각을 엣지 실행 환경에 맞게 고쳐 씁니다. 거점의 실행 환경은 일반 서버와 달라서 제약이 있습니다. 한 요청당 쓸 수 있는 시간이 대개 수십 밀리초, 메모리는 128메가바이트 안팎이고, 파일을 만들어 쌓아 두는 일도 못 합니다.
3. 배포합니다. 한 번 올리면 같은 코드가 전 세계 거점에 자동으로 복제됩니다. 지역마다 따로 올릴 일이 없다는 점이 서버를 여러 지역에 세우는 방식과 다릅니다.
4. 어떤 요청이 거점에서 처리될지 경로 규칙을 적습니다. /api 로 시작하는 요청은 중앙으로 보내고 나머지는 거점에서 받는 식으로 갈라 둡니다.
5. 지역별 응답 시간을 잽니다. 전체 평균만 보면 효과가 묻히기 때문에 서울·프랑크푸르트·상파울루처럼 서버에서 먼 지역을 따로 봅니다. 옮기기 전후로 이 값이 안 움직이면 애초에 거리가 원인이 아니었던 것입니다.

거점에서 데이터베이스를 부르지 않는 것이 이 절차의 전제입니다. 판단에 필요한 값은 요청 자체에 담겨 오거나 캐싱된 상태로 거점에 놓여 있어야 합니다. 거점에서 중앙 데이터베이스를 한 번이라도 호출하면 없애려던 왕복이 그대로 돌아옵니다.

맞는 자리는 판단이 짧고 그 판단이 화면 전체의 속도를 좌우하는 곳입니다. 로그인 여부를 확인해 못 들어올 사람을 돌려보내는 검문, 접속 지역에 따라 다른 언어 페이지로 넘기는 분기, 실험 대상을 가르는 처리가 대표적입니다. 결과는 사람마다 다른데 계산 자체는 1밀리초면 끝나는 일들이라, 중앙에 두면 200밀리초를 기다린 끝에 1밀리초짜리 판단을 받게 됩니다.

반대로 맞지 않는 자리가 셋 있습니다.

1. 데이터가 중앙에만 있는 처리. 주문 내역을 읽어 와야 하는 화면은 거점에서 돌려도 결국 중앙을 부르게 되어 아무것도 줄지 않습니다.
2. 무거운 연산. 이미지 변환이나 대용량 집계는 실행 시간 제한에 먼저 걸립니다.
3. 순서와 정합성이 중요한 처리. 결제나 재고 차감처럼 한 번만 일어나야 하는 일을 여러 거점에서 동시에 받으면 맞추기가 까다로워집니다.

운영에서 감수할 것도 있습니다. 문제가 생기면 어느 거점에서 생겼는지부터 찾아야 하고, 내 노트북에서 재현하기도 어렵습니다. 서버리스처럼 쓰지 않을 때 잠드는 구조라 첫 요청이 느려지는 콜드 스타트도 따라붙습니다. 다만 거점 실행 환경은 담는 그릇이 가벼워서 이 지연이 일반 서버리스보다 짧은 편입니다.

"이 리디렉션은 엣지로 빼죠. 중앙까지 갔다 오는 게 아까워요."

판단 하나 때문에 왕복 한 번을 쓰고 있으니 거점에서 처리하자는 제안입니다.

"엣지에서는 DB 못 부릅니다. 필요한 값은 토큰에 넣어 주세요."

거점 코드가 중앙 데이터를 읽을 수 없으니 요청에 값을 실어 보내라는 요구입니다.

"미국은 그대로인데 아시아만 400밀리초 줄었어요."

서버에서 먼 지역일수록 효과가 크다는 결과 보고입니다.

페이지덱의 서버는 미국 서부에 있습니다. 태오가 지역별 응답 시간을 뜯어보니 서울과 싱가포르에서 첫 화면이 뜨는 데 1.4초가 걸렸고, 같은 화면이 미국에서는 0.5초였습니다. 코드에는 느린 구간이 없었습니다. 차이의 대부분은 로그인 여부를 확인하고 워크스페이스 주소로 보내는 첫 판단 한 번이었고, 그 판단을 받으려고 태평양을 건너고 있었습니다.

태오는 그 판단만 거점으로 옮겼습니다. 쿠키에서 토큰을 꺼내 유효한지 보고 맞는 주소로 넘기는 30줄짜리 코드였습니다. 배포 다음 날 아시아 첫 화면 시간이 0.9초로 내려갔고 미국 수치는 그대로였습니다.

엣지에 올리면 무엇이든 빨라진다고 읽는 경우가 가장 많습니다. 가까운 데서 돈다는 말이 그렇게 들립니다. 하지만 줄어드는 것은 네트워크 왕복 시간 하나뿐이고, 거점에서 중앙 데이터베이스를 부르는 순간 그 왕복이 되돌아옵니다. 데이터를 읽어야 하는 처리를 거점으로 옮기면 왕복 횟수가 오히려 늘어, 옮기기 전보다 느려진 채로 운영 복잡도만 얻습니다. 옮기기 전에 그 처리가 중앙 데이터를 필요로 하는지부터 확인합니다.

중앙 서버가 필요 없어진다는 오해도 자주 봅니다. 거점에서 도는 것은 문 앞에서 끝나는 판단이고, 주문을 저장하고 내역을 읽는 본체는 그대로 중앙에 남습니다. 엣지 컴퓨팅을 도입하면 관리할 곳이 하나 줄어드는 게 아니라 하나 늘어납니다. 그 값을 치를 만한지는 먼 지역 사용자가 얼마나 되는지로 판단합니다. 사용자 대부분이 서버와 같은 나라에 있으면 얻을 것이 거의 없습니다.