엣지 컴퓨팅

코드로 줄일 수 없는 시간

서울에서 미국 동부(버지니아)까지 직선거리는 약 11,000km입니다. 빛은 진공에서 초속 30만km로 갑니다. 광케이블 안에서는 그보다 느리고, 케이블은 직선으로 깔려 있지도 않습니다.

서울 → 버지니아 편도   약 100ms
왕복                   약 200ms

이건 서버가 0밀리초에 응답해도 사라지지 않는 200밀리초입니다. 코드를 최적화해서 줄일 수 없고, 서버를 두 배로 사도 줄지 않습니다. 물리 법칙이기 때문입니다.

게다가 페이지 하나를 여는 데 왕복이 여러 번 필요하면(이름 찾기, 연결 맺기, 요청 보내기) 200밀리초가 몇 배로 곱해집니다. 첫 강의에서 본 그 단계들입니다.

그래서 남은 방법은 하나뿐입니다. 거리를 줄이는 것.

CDN에서 한 걸음 더

앞 강의에서 우리는 파일 복사본을 사용자 가까이에 뒀습니다. 그런데 곰곰이 생각해 보면, 그 지점들에는 이미 컴퓨터가 있습니다. 파일만 주고 놀리기엔 아깝습니다.

엣지 컴퓨팅은 이렇게 묻습니다.

저 지점에서 판단까지 하면 안 되나?

엣지에 어울리는 일

이런 일들은 무겁지 않고, 본사의 데이터가 거의 필요 없습니다.

• 로그인 토큰 검증 — 서명만 확인하면 되므로 엣지에서 끝납니다. 유효하지

않으면 여기서 바로 돌려보냅니다. 본사는 이 요청을 구경도 못 합니다.

• 접근 통제 — 이 나라에서는 이 콘텐츠를 못 봅니다. 엣지에서 판단합니다.
• A/B 테스트 분기 — 이 사용자는 B안 페이지. 엣지에서 정합니다.
• 리다이렉트, 기기별 이미지 크기 선택 — 전부 엣지에서 됩니다.

이런 요청이 전체의 상당 부분입니다. 그리고 이것들이 본사까지 가지 않게 되면, 사용자는 200밀리초 대신 5밀리초를 경험합니다.

엣지에 어울리지 않는 일

• 결제, 주문, 재고 차감 — 전 세계에서 동시에 일어나므로 한곳에서 결정해야 합니다.
• 큰 데이터베이스 조회 — 데이터를 300개 지점에 다 복사할 수는 없습니다.
• 정확한 최신값이 필요한 것 — 잔액, 재고 수량.

경계선은 대체로 이렇게 그어집니다.

"틀려도 되나?" 틀리면 안 되는 것은 중앙으로 보냅니다. "모두에게 같은 답인가?" 모두에게 같으면 엣지로 내립니다.

공짜가 아닌 부분

엣지를 300곳에 두면 문제도 300곳에 생깁니다.

• 배포: 코드를 300곳에 동시에, 안전하게 밀어야 합니다. 절반만 새 버전이면

사용자마다 다른 동작을 보게 됩니다.

• 디버깅: 어느 지점에서 났는지 모르는 오류를 재현해야 합니다.
• 일관성: 엣지가 들고 있는 설정이 방금 바뀐 것과 다를 수 있습니다.
• 제약: 엣지에서 도는 코드는 대개 실행 시간과 메모리에 엄격한 제한이 있습니다.

그래서 엣지에 올리는 로직은 작고 단순하게 유지하는 것이 원칙입니다. 엣지에 큰 애플리케이션을 통째로 올리려는 시도는 거의 실패합니다.

결정권자가 알아야 할 것

"우리 서비스가 해외에서 느립니다"라는 보고에 서버 증설로 답하면 돈만 나가고 아무것도 나아지지 않습니다. 원인이 용량이 아니라 거리이기 때문입니다. 두 원인은 증상이 비슷하지만 처방이 완전히 다릅니다.

직접 해보세요

아래 과제에서 원본 서버는 아주 멀리 있습니다. 용량은 충분합니다 — 유실이 없습니다. 그런데도 사용자는 오래 기다립니다. 왜 서버를 늘려도 소용이 없는지, 그리고 무엇이 실제로 효과가 있는지 직접 확인하세요.