왜 우리는 로드 밸런서 앞에 CDN을 두었는가 (그리고 쿠키가 진짜 문제였던 이유)

Source: Dev.to

상황

우리는 두 개의 병행 작업 중이었습니다: 웹사이트 전체 재디자인과 서버 마이그레이션. 두 작업 모두 계획되어 있었고, 범위가 정의되었으며, 문제 없이 진행되고 있었습니다… 하지만 마이그레이션 후 일부 사용자 그룹에서 오류가 발생하기 시작했습니다. 모두가 아니라. 일관되게도 아니었습니다. 하지만 실제 문제가 될 만큼 충분했습니다.

범인은 쿠키입니다.

문제

이전 서버는 시간이 지나면서 쿠키가 누적되었습니다. 새로운 서버는 자체 쿠키를 도입했습니다. 사용자가 마이그레이션 중간에 도착했을 때—여전히 오래된 쿠키를 로드하고 재설계된 사이트의 새로운 쿠키를 받는 상황—두 쿠키가 합쳐진 페이로드가 로드 밸런서가 허용하는 최대 크기인 16 KB를 초과했습니다.

이 제한은 임의적인 것이 아닙니다. 대부분의 로드 밸런서와 CDN이 HTTP 수준에서 적용하는 강제 제약입니다. 이 한계를 넘으면 요청이 조용히 실패하거나 거부됩니다.

더 복잡하게 만든 점은 도메인이 우리 직접적인 통제 하에 있지 않았다는 것입니다. 외부 DNS 공급자의 CNAME을 통해 로드 밸런서로 지정되어 있었습니다. 따라서 라우팅을 변경하려면 제3자와 협의해야 했고, 로드 밸런서 설정을 직접 수정할 수 없었습니다.

Source: …

왜 어려웠는가

복잡했던 것은 기술적인 수정이 아니라 주요 제약 조건이었습니다: 변경 중에 사용자에게 어떠한 영향도 줄 수 없었습니다.

too_many_redirects 오류는 쿠키 페이로드가 큰 사용자—특정 세션, 특정 브라우저, 구 시스템과 새 시스템 사이의 특정 경로—에게만 나타났습니다. 전체 컷오버를 하면 모든 사용자가 위험에 노출될 수 있었습니다. 그리고 롤백도 깨끗한 옵션이 아니었습니다. 이미 마이그레이션이 부분적으로 라이브 상태였기 때문입니다.

우리는 다음과 같은 해결책이 필요했습니다:

• 요청이 로드밸런서에 도달하기 전에 가로채야 합니다.
• 화이트리스트를 기반으로 쿠키를 정리하고(필요한 것만 보존)
• 요청만 수정하고 리다이렉트를 발생시키지 않아야 합니다.
• 도메인 레지스트라나 로드밸런서를 건드리지 않고 배포할 수 있어야 합니다.

해결책

우리는 DNS와 로드밸런서 사이에 CDN 레이어를 도입하고, CNAME을 로드밸런서가 직접 가리키는 대신 CDN을 가리키도록 변경했습니다.

CDN 엣지에 Lambda@Edge 함수를 연결하여 들어오는 각 요청마다 실행되도록 했습니다. 이 함수의 작업은 간단했습니다: 쿠키를 읽고, 화이트리스트를 적용하고, 나머지를 모두 제거한 뒤, 정리된 요청을 아래로 전달하는 것이었습니다.

리다이렉트 없음. 화이트리스트에 있는 쿠키에 대한 세션 손실 없음. 애플리케이션 코드나 로드밸런서 설정에 변경 없음.

최종 아키텍처는 다음과 같습니다:

[DNS → Firewall] → CDN → (Lambda@Edge) → Balanceador → Cluster

CDN은 우리가 필요로 했던 엣지 실행 레이어를 제공했습니다. Lambda@Edge 함수는 요청 수준에서 정확한 제어를 가능하게 했습니다. 그리고 우리는 요청 헤더만 수정했으며—응답은 절대 수정하지 않았기 때문에—too_many_redirects 루프가 절대 발생하지 않았습니다.

우리가 배운 점

• 당신이 통제할 수 있는 것과 없는 것을 이해하라. 도메인은 우리의 기록 밖에 있었다. 로드밸런서는 고정된 한계가 있었다. 기존 사용자 쿠키는 협상할 수 없었다. 이러한 제약 내에서 작업하는 것이 모든 결정을 형성했다.
• CDN은 목표가 아니라 촉진자였다. 성능이나 캐시 때문에 추가한 것이 아니다. 우리가 추가한 이유는 정확히 필요한 곳, 즉 사용자와 로드밸런서 사이에 프로그래머블 레이어를 제공했기 때문이다.
• 화이트리스트가 블랙리스트보다 더 안전하다. 오버플로를 일으키는 쿠키를 찾아서 그만 제거하려는 대신, 접근 방식을 전환했다: 살아남아야 할 것을 정의하고 나머지는 모두 제거한다. 유지 관리가 더 간단하고 배포가 더 안전하다.
• 다운타임 없는 변경은 배포 트릭이 아니라 아키텍처 결정이다. 사용자를 영향을 주지 않고 이 변경을 할 수 있었던 이유는 운이 아니라, 아키텍처가 아래에 있는 것을 수정하지 않고 새로운 레이어를 삽입할 수 있게 해줬기 때문이다.

결론

좋은 아키텍처는 항상 가장 우아한 설계에 관한 것은 아니다. 때로는 시스템들이 서로 어떻게 상호작용하는지 이해하고, 실제로 영향을 미칠 수 있는 지점을 파악하며, 오늘 가지고 있는 제약 조건—원하는 것이 아니라—에 따라 올바른 리소스를 선택하는 것이다.

CDN와 작은 Lambda 함수가 쿠키 문제처럼 보였던 것을 해결했다. 하지만 실제로 해결한 것은 제어 문제였다.