인프런 아키텍처 2024 ~ 2025 - 느낀점

인프콘 2024 영상 느낀점 기록

 

영상 링크

https://youtu.be/5E5vfGwzLMU?si=yhhDo3-dPblHb56x

2023 인프런

레거시 코드를 점진적으로 제거하려고 노력
But, 기존 레거시가 점점 사라지는 조직도 있었고 그렇지 않은 조직도 존재
왜? 글로벌 진출 - 국제화를 하려다 보니까 불가능(국제화 서비스)
그래서 먼저 신규 기술 스택부터 적용. 기존 본인 팀의 프로젝트는 drop

=> 우리 회사도 한 팀이 다른팀을 도와준 적이 있었는데 신규 기술스택을 배울 수 있고
해당 서비스도 먼저 오픈할 수 있었다. 이런 방식들은 좋은 것 같다

트래픽 비용 개선

가장 쉬운 방법 - 이미지 크기
기본적인 최적화 방법 - cdn 쿼리스트링으로 크기 전달.
Cloud Front 캐싱 - 람다엣지 리사이징 - s3 원본보관
근데 위 방법만으로도 한계. 이미지 따라 파일 크기 차이가 극명
Avif - 품질 저하 없는 고효율 압축파일
지금 브라우저에서 지원? 거의 대부분 브라우저 지원
그래서 쿼리스트링에 파일 포맷도 변환

개선 60% 이상

=> avif 좋은 것 같다 나중에 이미지 관련 서비스 만들 때 제안하고 써봐야할듯

JSON CDN 캐시

페이지에서 호출되는 전체 카테고리가 json인데 호출이 너무 많이됌 (하루 150기가)
DB에서 직접 호출하고 있었음

엘라스틱 캐시로 변경
DB부하는 줄었지만 엘라스틱 캐시 서버를 3대이상 써야했음(DB한대값) - 비용개선이 없음

그래서 로컬 캐시로 변경
ec2는 EhCache로 운영
캐싱으로 비용은 줄임

하지만 ec2자체로 요청하는 수가 너무 많았음
결국 ec2에 요청은 여전히 많아 개선이 안됐음(많은 동일 api 조회)

이것도 json파일을 내려주는 cdn캐시를 해도 되지 않을까?

한 번 내려준 데이터는 CDN에서 캐시
그래서 로드밸런서 ec2로 안감

그럼 저 파일은 어디서 보관?
S3 or api 응답 캐시

S3 단점
파일 교체 필요
File write 필요

Api 응답 캐시는 기존 api만 변경

결과
로드밸런서 트래픽 50% 감소
애플리케이션 로드 70% 감소

유의사항
Api cdn캐시는 맨 처음 헤더의 캐시를 쿠키 가져옴
모든 사람들이 한 사용자로 될 수도 있음
캐시, 쿠키 컨트롤 잘해야함

=> 이런 개선이 인프라의 비용을 줄일 때 큰 힘을 발휘하는 것 같다
그냥 캐싱은 알고 있었는데 cdn캐싱방법은 처음본 것 같다

아키텍처 개선

서비스 국제화를 위해 Express -> Next.js

next.js rewrite로 api 프록시 가능

분산 환경 단점 - 세션 체크 X
백엔드끼리는 internal-api 로 api 키 체크
근데 문제는 내부의 api가 외부에서 호출 가능할 수 있는데 위험
그래서 외부 , 내부로 따로 나눔
그러다보니까 인프라 비용이 2배

그래서 세션 쿠키 들고다니면서 체크하다보니
인프라 부하, 코드 복잡도 가중

프로젝트도 분리하지않고 , 세션체크도 안하려면?
Api path 추가
프론트엔트가 호출하는건 client 패스 추가 그걸로 세션체크

그래서 외부(모바일) external로 url next.js는 internal client , 서버는 internal
그러다보니 라우터 너무 많아짐
레거시, 새로운소스(넥스트)
사용사별 나누려니 너무 힘들다 (사용자 A,B,C의 쿠키 가지고있으면 기존 나머지는 새로운거)
=> 이 부분 생각했는데 어렵나보구나…

그래서 리버스 프록시 도구 사용
Trafik
Go 기반
고차원 조건 가능(헤더 기반)
숫자 제약 없는 라우트 구성
특히 서버 재시작 없는 동적 구성 변경

그래서 로드밸런서 전 중간 리버스 프록시(트래픽) 통해 분류

=> 우리 회사랑 좀 다른게 우리 회사는 배포 반영 구분을 쉽게 나눌 수 있어 차이가 있었다.
저렇게까지 사용할 필요 없이 쉽게 사용하고 있었다는걸 깨달았다

펠리컨적 사고 “일단 시도함”
넘어지더라도 앞으로 넘어지자

=> 최근 변화를 위해 고민하고 있던게 있는데 이 말 보고 더욱더 시도해보자는 의지가 생겨났다
일단 해보고 안되면 그때가서 다시 고민해봐야겠다