[스타트업 연계] 캐싱 프록시 서버 프로젝트 간단 회고

시놀 | Notion

해당 스타트업에서 요청한 요구사항에 따라 SI 외주 업체의 입장에서 진행

배경

현재 운영중인 메인 서버는 JavaScript 기반으로 로직을 동기적으로 처리하고 있어서,
향후 트래픽 증가에 따른 지연 증가에 적절히 대처할 수 없다고 한다.

캐싱 프록시 서버 도입

현재 운영중인 메인 시스템의 Spring/Java로의 migration 전에 성능 개선을 위해 도입할 수 있는 부분을 고민했다고 한다.

결과로 제안된 것이 캐싱 서버이다. 현재 시스템은 monolithic한 구조로 모든 요청은 프록시 서버에 전달된다.

요구사항으로 전달된 예상 시스템

 

이러한 시스템 구조는 SPOF 문제가 있으므로 Nginx 또는 k8s를 활용하여 다중 인스턴스에 대한 로드 밸런싱이 필요하다.
그러나 In-memory 캐싱의 특성상, 단순 복제를 하면 불필요한 중복 캐싱이 많아질 것으로 생각한다. 때문에 이러한 경우에는 분명한 기준에 따른 샤딩이 적합하다. 이러한 고도화에 대한 요구사항은 없었기에 넘어갔다.

요구사항

사용자의 요청을 In-memory 캐싱을 기반으로 반환하는 프록시 서버를 구현하는 것이 목표였다.

캐시에 대한 조회 및 삭제 기능과

캐시가 유효한 시간(TTL)을 HTTP API를 통해 동적으로 수정 가능하는 기능이 필요하고,

이에 대한 요청을 인증을 통해 진행할 수 있도록 지원해야 했다.

이 중 캐시에 대한 조회 및 삭제 기능은 초기 설계를 클라이언트 측에서 전달했기 때문에 필요한 기능이었다.
만약 기존에 캐싱된 정보에 대한 TTL을 수정하면, 해당 캐시를 삭제해야만 TTL 갱신이 가능할 것으로 판단했다고 한다.
이 부분은 이후 MVVC 모델링에 착안한 TTL versioning을 통해 개선했다.

구현

프로젝트 구조도

1. Auth Server

보안에 대한 전문적 지식이 있는 것이 아니고, 외부 인증 서버를 활용하는 것이 아닌, 간단한 내부 인증 처리를 활용할 때에는 Keycloak만한 기술이 없다고 생각하여 추진했는데, 유지보수에 대한 자신이 없다는 이유로 Spring 자체 인증 서버로 회귀했다. 적합한 기술을 익히고 적용할만한 능력이 없는 것인지, 아니면 굳이 애쓰고 싶지 않은 마음인지, 어떤 의미로든 구성원이 단순히 기능적으로 동작하는 것을 목표로만 개발하려는 것을 보니 개발 문화가 좋게 느껴지지는 않았다.

 

2. Durability

현재 HTTP을 통한 가장 단순한 MVC 구조로 API를 개방된 상태이다. 향후 Durability를 위한 고도화가 필요하다면 메세지 큐를 두고 이벤트 처리에 대한 로직을 구현할 필요가 있다. 이 부분은 다음 웹소켓 프로젝트의 포스트에서 간단히 다룰 예정이다.

 

3. Redis Key-value Storage

원래 @RedisHash를 통해 TTL을 정적으로 간단히 설정할 수 있는데, 동적인 TTL 설정은 지원하지 않는 것 같다. RedisTemplate의 opsForValue().set() 메서드를 활용하여 동적으로 적용할 수 있다.

 

4. 동적인 TTL 수정

Redis은 메모리 기반으로 동작하기 때문에 혹시 모를 장애로 인한 데이터 유실을 생각하면 Version에 대한 정보는 RDBMS에 저장하는 것이 적합하다. 그러한 부분이 Metadata에 저장되어 있고, 이에 대한 조회를 2차 캐시로 진행하면 데이터 수정시에만 갱신하여 조회하기 때문에 로직은 단순해지고, DB 참조에 따른 성능 이슈도 방지할 수 있다.