Redis는 In memory 기반의 데이터베이스로 빠른 읽기/쓰기 성능과 다양한 자료구조로 데이터베이스 캐시로 많이 사용되고 있습니다.만약 Redis 에 저장한 데이터가 빈번하게 변경되지 않지만 payload 사이즈가 커서 매번 Redis에서 값을 가져오는 것이 비효율적인 경우,클라이언트 캐시를 사용하기도 합니다. 하지만 클라이언트 캐시가 항상 최신 데이터를 가지고 있지 않을 수 있습니다.이런 경우 클라이언트 캐시와 Redis 의 데이터를 동기화 하는 것이 필요합니다.쉬운 방법으로는 Local cache의 Expiration을 설정하여 일정 시간이 지나면 Redis의 값을 읽어서 동기화하는 방법도 있습니다.이 방법은 캐시의 데이터가 즉시 동기화되지 않아도 무방한 경우 단순하고 효과적인 방법이기도 합니다.하지만 Redis의 데이터가 변경되는 것을 즉시 Notification을 받아서 Local Cache를 Redis와 동기화할 수 있으면 어떨까요?이 글에서는 Redis Client Caching 을 사용하여 클라이언트 캐시와 Redis 의 데이터를 동기화 하는 방법을 설명합니다.Redis Client Caching 은 Redis 의 데이터를 클라이언트 캐시에 저장하고 동기화 하는 기법입니다.먼저 Local Cache를 사용하는 기본적인 방법부터 알아보고 이후 Redis Client Caching 을 사용하는 방법을 알아보겠습니다.Redis에서 매번 값을 읽으면 불필요한 Network I/O가 발생하고 Redis의 자원을 비효율적으로 사용하게 되거나 서비스의 Latency를 증가시키게 됩니다.이런 문제를 해결하기 위해서는 클라이언트 캐시를 사용하는 것이 필요합니다.위그림은 Local Cache의 기본적인 동작을 설명하고 있습니다.여기서는 하나의 클라이언트가 Redis에서 값을 가져와서 Local cache를 참조하도록 설계되었는데,만약 다른 클라이언트에서 foo 값을 변경하면 Local cache의 값과 Redis의 값이 다르게 됩니다.이런 경우 클라이언트는 다시 Redis에서 값을 가져와서 동기화해야 합니다.클라이언트A가 값을 변경하면 Redis는 해당 값의 Invalidation 여부를 클라이언트B에게 알립니다.클라이언트B는 이 메시지를 받으면 Redis에서 값을 읽어 Local cache를 갱신합니다. 이런 방식으로 클라이언트 캐시와 Redis의 데이터를 동기화 할 수 있습니다.이렇게 Invalidation 메시지를 받아서 동기화하는 방식이 Redis Client Caching 입니다.Redis Client Caching 은 크게 두 가지 모드로 동작합니다.이 모드에서 Redis 서버는 클라이언트A가 관심있는 key가 어떤 것인지 기억합니다.클라이언트A가 관심있는 key가 변경되면 Redis 서버는 클라이언트A에게 Invalidation 메시지를 보냅니다.이 모드는 클라이언트가 관심있는 key가 적은 경우 유용하지만, 서버의 메모리를 사용한다는 점을 유념해야 합니다.이 모드에서는 클라이언트가 어떤 key를 관심있는지 명시적으로 알려야

안녕하세요, 강남언니 백엔드 엔지니어 Eddy(안정균)입니다.저는 현재 강남언니에서 미용 의료 병원용 B2B SaaS 제품(이하 KOS)을 개발하고 있습니다.KOS 제품을 개발하면서 자동화 테스트에서는 성공하였으나 운영계 배포 후 버그가 발생했던 아찔한 경험을 한 이후로 테스트를 작성하는 방법이 많이 바뀌었는데요. 이번 글에서는 KOS의 예약 시스템 개발 과정에서 발생했던 사례를 기반으로 배운 인사이트에 대해 소개드려보고자 합니다.KOS의 서비스들은 여러 Microservice들로 이루어져있고, 여러 컴포넌트 간 동기 방식의 HTTP 통신 또는 메시지를 발행하여 Message Broker 등을 활용하는 등의 여러 통신 방식이 존재합니다. 그리고 메인 데이터베이스로는 MongoDB를 사용하고 있습니다.대개 복잡한 비지니스 요구사항을 만족하기 위해 시스템은 하나의 명령(Command)이 실행 되었을 때 여러 서비스 컴포넌트 간 여러 인프라를 이용한 통신이 발생하고 이를 제어하기 위해선 하나의 유즈케이스에 많은 의존성이 필요해질 때가 있습니다.다음과 같이 복잡한 비즈니스 요구사항과 시스템 제약사항을 만족하기 위해 다양한 의존 관계가 형성되었을 때, 어떻게 시스템을 설계하고 테스트를 작성하는지에 대한 경험을 KOS 예약 시스템의 예제 코드 기반으로 공유하고자 합니다.• 동일한 내원객(Visitor)은 동 시간대 중복 예약을 할 수 없어야 한다.• 예약 완료 시 해당 내원객에게 예약 확정 SMS 문자가 발송되어야 한다.• 예약 완료 시 내원객 스케줄의 조회 모델이 만들어져야 한다. (ref. CQRS)• 위 조건을 만족하기 위해, 스케줄 서비스에서 발생한 사건들(Events)을 발행하여 Downstream Services 에서 요구사항에 맞게 소비하여 처리하고 있습니다.예약 요구사항을 만족하기 위한 시스템 구성도스케줄 서비스에서 예약 성공 후 발행되는 도메인 이벤트를 알림 이벤트 처리기와 스케줄 이벤트 처리기 등에서 소비하여 요구사항을 만족하는 과정을 추상적으로 도식화해 보면 위와 같습니다.내원객의 식별값(visitorId)으로 내원객 정보를 읽어오는 Reader입니다.⇒ Spring Webflux의 WebClient를 이용하여 Visitor Service를 호출합니다.중복 예약 방지 요구사항을 만족하기 위해 필요한 내원객의 식별 값과 예약 시간을 파라미터로 받는 중복 예약 검증기입니다.⇒ 예약 시 Redis에 캐싱하여 내원객 + 예약 시간 기반으로 중복 예약인지 검증합니다.KOS는 예약 시스템에 Event Sourcing을 적용하여, 명령이 발생하면 관련된 도메인 이벤트들을 스토어에 적재하고 있습니다. EventStore는 도메인 이벤트들을 관리하는 스토어입니다. (ref. 시간여행이 가능한 시스템 아키텍처)⇒ MongoDB와 AWS Kinesis Data Stream을 이용하여 생산된 Message에 대해 Store and Forward 작업을 수행합니다.이어서 유즈케이스 구현체에 대응하는 테스트를 작성해 보겠습니다.현재의 구조에서는 테스트를

안녕하세요, 힐링페이퍼 백엔드 엔지니어 안정균(Eddy)입니다.저는 현재 강남언니 팀에서 미용 의료 병원용 B2B SaaS 제품(이하 KOS)을 개발하고 있습니다.KOS 제품을 개발하면서 자동화 테스트에서는 성공하였으나 운영계 배포 후 버그가 발생했던 아찔한 경험을 한 이후로 테스트를 작성하는 방법이 많이 바뀌었는데요. 이번 글에서는 KOS의 예약 시스템 개발 과정에서 발생했던 사례를 기반으로 배운 인사이트에 대해 소개드려보고자 합니다.KOS의 서비스들은 여러 Microservice들로 이루어져있고, 여러 컴포넌트 간 동기 방식의 HTTP 통신 또는 메시지를 발행하여 Message Broker 등을 활용하는 등의 여러 통신 방식이 존재합니다. 그리고 메인 데이터베이스로는 MongoDB를 사용하고 있습니다.대개 복잡한 비지니스 요구사항을 만족하기 위해 시스템은 하나의 명령(Command)이 실행 되었을 때 여러 서비스 컴포넌트 간 여러 인프라를 이용한 통신이 발생하고 이를 제어하기 위해선 하나의 유즈케이스에 많은 의존성이 필요해질 때가 있습니다.다음과 같이 복잡한 비즈니스 요구사항과 시스템 제약사항을 만족하기 위해 다양한 의존 관계가 형성되었을 때, 어떻게 시스템을 설계하고 테스트를 작성하는지에 대한 경험을 KOS 예약 시스템의 예제 코드 기반으로 공유하고자 합니다.• 동일한 내원객(Visitor)은 동 시간대 중복 예약을 할 수 없어야 한다.• 예약 완료 시 해당 내원객에게 예약 확정 SMS 문자가 발송되어야 한다.• 예약 완료 시 내원객 스케줄의 조회 모델이 만들어져야 한다. (ref. CQRS)위 조건을 만족하기 위해, 스케줄 서비스에서 발생한 사건들(Events)을 발행하여 Downstream Services 에서 요구사항에 맞게 소비하여 처리하고 있습니다.예약 요구사항을 만족하기 위한 시스템 구성도스케줄 서비스에서 예약 성공 후 발행되는 도메인 이벤트를 알림 이벤트 처리기와 스케줄 이벤트 처리기 등에서 소비하여 요구사항을 만족하는 과정을 추상적으로 도식화해 보면 위와 같습니다.내원객의 식별값(visitorId)으로 내원객 정보를 읽어오는 Reader입니다.⇒ Spring Webflux의 WebClient를 이용하여 Visitor Service를 호출합니다.중복 예약 방지 요구사항을 만족하기 위해 필요한 내원객의 식별 값과 예약 시간을 파라미터로 받는 중복 예약 검증기입니다.⇒ 예약 시 Redis에 캐싱하여 내원객 + 예약 시간 기반으로 중복 예약인지 검증합니다.KOS는 예약 시스템에 Event Sourcing을 적용하여, 명령이 발생하면 관련된 도메인 이벤트들을 스토어에 적재하고 있습니다. EventStore는 도메인 이벤트들을 관리하는 스토어입니다. (ref. 시간여행이 가능한 시스템 아키텍처)⇒ MongoDB와 AWS Kinesis Data Stream을 이용하여 생산된 Message에 대해 Store and Forward 작업을 수행합니다.이어서 유즈케이스 구현체에 대응하는 테스트를 작성해 보겠습니다.현재의 구조에서는 테스트

안녕하세요. Azar Matching Dev Team 의 Zeze 입니다. Flink 는 대다수의 백엔드 엔지니어들에게 친숙한 기술은 아니지만, 이벤트 스트리밍 처리를 위한 대표적인 기술 중 하나입니다. 대규모 실시간 데이터 스트리밍 처리를 위해 분산 환경에서 빠르고 유연하게 동작하는 오픈소스 데이터 처리 엔진이며, 팀 내에서는 Azar 의 핵심 로직인 매칭 서버를 구현하는 데에 사용되고 있고, 사내에서는 보통 Kafka 를 source 및 sink 로 사용하는 애플리케이션 코드를 직접 작성하는 방식으로 많이 사용하고 있습니다. 오늘 소개할 Flink SQL 은 애플리케이션 코드를 직접 작성하지 않고도 SQL 을 통해 이벤트 스트리밍 처리 앱을 구현할 수 있도록 해주는 기능입니다. 이번 글에서는 이벤트 스트리밍 처리를 위해 Flink SQL 을 채택한 이유와 클러스터 환경 구축 및 운영 경험을 공유하려고 합니다.Azar Matching Dev Team 에서 관리하던 여러 Flink 기반 앱들 중, CPU 를 무려 96개나 사용하던 매우 무거운 레거시 앱이 있었습니다. 이 앱은 여러 매치 이벤트를 조인하고, 로직에 따라 조건부로 새로운 이벤트 발행하거나 Redis에 플래그를 저장하는 등 다양한 기능을 한 곳에 몰아넣은 모놀리식 구조였습니다. 유지보수가 어려운 상태에서 전사 인프라 작업으로 인해 해당 앱의 실행 노드를 변경하자, 앱이 정상적으로 동작하지 않는 문제가 발생했고, 몇 차례 단순 튜닝을 시도해 보았지만 빠르게 해결하기 어려웠습니다. 그 결과, 높은 운영 피로도를 감수하며 이 앱을 계속 유지보수 할지 아니면 다른 방법으로 대체할지를 결정해야 했습니다.다행히 기존 앱의 로직 중 중요한 이벤트들을 조인하는 기능은 (아래 그림에서 에 해당하는 부분) 별도의 프로젝트를 진행해 이미 새로운 Flink 앱으로 구현해 놓은 상태였기 때문에 이를 레버리지하는게 유리한 상황이었습니다. 그렇다면 위 그림처럼 이벤트 조인 이후 수행하는 조건부 이벤트 발행 또는 로직 수행 부분을 어떤 방식으로 대체할지를 고민해야 했는데요, 다음과 같은 선택지 및 장단점이 있었습니다.• 하나의 Flink App 으로 구현• 장점 - 하나의 앱만 관리하면 되므로 운영이 간편합니다.• 단점 - 또 다시 거대한 앱이 될 가능성이 크며, 앱의 한 부분이 실패할 경우 다른 기능도 영향받기 쉽습니다.• 여러 Flink App 으로 구현• 장점 - 각 앱을 독립적으로 관리할 수 있어 유연합니다.• 단점 - 앱의 개수가 늘어나면, 클러스터/리소스/배포 관점에서 부담이 증가할 수 있습니다.• Flink SQL 을 사용• 장점 - 쿼리를 통해 로직을 정의하므로 빠른 개발이 가능하며, 하나의 클러스터만 관리하면 됩니다.• 단점 - SQL 만으로는 복잡한 로직을 표현하기 어렵고, 팀이 클러스터 관리에 익숙하지 않다면 어려울 수 있습니다.팀에서는 Flink 의 내부 구현에 대해 꽤나 이해도가 높아져 있는 상태였기 때문에, Flink SQL 을 사용하면 생산성 및 운영 효율성에서 이점이 있