레거시 시스템 전환
- 목적 조직 별로 레거시와 신규 시스템을 각자 개발하게 됨
목적조직
- 커뮤니티
글로벌 가기 전 기반 작업 (비용 효율화)
- 치솟는 환율, 글로벌 무상 트래픽(무료로 강의를 제공해야 하는데)
- 국제화 오픈 전에 비효율적인 트래픽 비용을 개선하자
png,jpeg 파일 크기가 꽤 크다. → 고품질, 저용량의 avif 파일 포맷
avif 품질 저하 없는 고효율 압축 JPEG에 비해 최대 50%까지 아낄 수있음. 대부분의 브라우저에서 지원
- 외부 캐시, 로컬 캐시 등으로 DB, Elastic cache 줄임
- CloudFront에 해당 데이터들 캐싱. S3 통해서 할거냐 vs API 응답 캐시
GET /category → CloudFront → LoadBalancer → ECS EC2 → RDS
⇒ 애플리케이션 로드 70% 감소. 로드밸런서 트래픽 50% 감소
결과 : 일 150 GB, 월 4.5TB 트래픽을 EC2로 처리하지 않아도 됨
유의사항 : CDN 은 cache-control 에 따라 쿠키도 캐시할 수 있다. 쿠키가 캐시되면 처음 로그인한 사용자의 페이지로 다른 사람들도 다 세션이 교체되어버릴수 있음
아키텍처 개선
Express → Next.js
SEO가 잘되면서 국제화도 잘 지원되었어야 했다.
Next.js 에서 프록시 설정도 가능해서 api 프록시 서버로 이용기 편하게 가능함
SSR은 Next.js가 직접
Next.js 를 통해 프록시를 하다보니 내부 다른서버용 API 가 외부에서 호출할 수 있게 됨.
- 가장 간단한 방법은 서버를 따로 나누는 것. 그러나 모든 백엔드 인프라가 2배로 늘어남
- 내, 외부 모두 세션 체크를 한다. → 분산된 환경이 커질수록 모든 API 가 세션 쿠키를 가지는 것은 인프라 부하, 코드 복잡도 가중
- 가장 쉬운 방법은 API 경로를 나누는 것. 외부에서 호출하는건 /client 를 붙이고 내부에서 호출하는 건 안붙이고 ⇒ 이러다 보니까 Route 분기가 너무 많아짐
- 동일한 url로 호출하는데 쿠키 값에 따라서 바라보는 서버가 달라져야 하는 요구사항이 있었음. (CloudFront는 기능적인 제한이 있음)
- 이럴 떄는 리버스 프록시 를 사용 (nginx. traefik)
- 고차원 조건 가능 (Header 기반 등)
- 숫자 제약 없는 Route 구성
- 서버 재시작 없는 동적 구성 변경
- traefik 에서 설정이 코드로 관리되기 때문에 어디가 어디로 가는지 다 확인이 가능함
- 이러다 보니 Cloud Front의 한계를 넘어 점진적 Next.js 개편 가능. traefik 으로 라우트 분리하는 게 너무 좋았음
Cloud Front → traefik(라우트 분리) → LoadBalancer → Express(레거시) 혹은 Next.js