1. 배경 메뉴 조건 관리에서 시작한 요구가 서버의 기능 인가로 확장됐다 초기 구현메뉴 정책 관리요구 범위 확대 프론트 조건문어드민 설정 조직별 GNB 분기메뉴 노출 관리 기능 인가API 접근 권한 판단 보여줄 메뉴를 정하는 것에서 실행할 수 있는 기능을 정하는 것으로 확장됐다.우리 팀은 여러 파트너사에 파트너스 페이지를 제공한다. 처음에는 조직과 역할에 따라 GNB를 다르게 보여주는 조건을 프론트 코드에 넣었지만, 파트너사별 요구가 늘면서 메뉴 정책을 바꿀 때마다 코드를 수정해야 했다. 그래서 메뉴 노출을 어드민에서 관리하도록 바꿨고, 이후에는 API 접근 권한과 새 API의 권한 매핑까지 다루게 됐다. 이 과정에서 마주한 문제와 각 문제를 해결한 ..

들어가기 전우리 팀은 Reactor Kafka로 직접 구성한 컨슈머에서 classic 프로토콜을 사용해 왔다. 배포로 pod가 교체되는 몇 분 동안 컨슈머 랙이 쌓였다가 줄어드는 일이 반복됐고, 컨슈머 수가 늘면서 소비가 지연되는 구간도 길어졌다. 원인을 살펴보니 리밸런스 방식과 정적 멤버 ID 설정이 함께 영향을 주고 있었다.eager 리밸런스에서는 기존 멤버가 보유한 파티션을 모두 반납했다.pod 이름으로 만든 정적 멤버 ID가 배포마다 달라져, 종료된 멤버의 세션 만료를 기다려야 했다.그래서 Spring Boot와 Kafka를 4.x로 올리면서 KIP-848의 consumer 프로토콜을 적용하고, 컨슈머 구현체도 Spring Kafka 컨테이너로 교체했다.이 글에서는 배포 중 멈춤을 만든 두 가지 ..

들어가기 전컨슈머 A와 B가 파티션 6개를 나누어 처리하고 있다. 처리량을 늘리려고 C를 추가하면 기존 컨슈머의 파티션 일부를 C에게 넘겨야 하며, 그동안 소비가 지연될 수 있다.이 지연을 이해하려면 최종 할당표보다 새 할당을 적용하기까지 누가 무엇을 기다리는지를 확인해야 한다. 전체 파티션을 반납한 뒤 다른 멤버의 합류를 기다리는지, 이동할 파티션만 반납하는지, 반납 확인에 그룹 전체가 참여해야 하는지에 따라 영향 범위가 달라지기 때문이다.classic의 eager에서는 전체 파티션을 반납한 뒤 재할당을 받지만, classic의 cooperative에서는 반납 범위가 이동 파티션으로 줄어든다. KIP-848의 consumer 프로토콜에서는 그룹 단위의 합류 대기가 멤버별 할당 조정으로 바뀐다. 같은 파..

🧐 들어가기 전파티션 8개짜리 토픽에서 컨슈머 랙이 계속 쌓였다. 그래서 컨슈머 인스턴스를 8대에서 16대로 늘려 배포했는데 랙 그래프는 그대로였다. 컨슈머 그룹 상태를 확인해 보니 새로 뜬 8대는 할당된 파티션이 하나도 없었다. 일반 컨슈머 그룹에서는 파티션 하나가 같은 시점에 그룹 내 컨슈머 하나에게만 배타적으로 할당되기 때문이다. 애플리케이션 내부에서 별도 병렬화를 하지 않는 전통적인 소비 모델이라면, 그룹 전체 병렬성의 상한은 컨슈머 수가 아니라 파티션 수다.그렇다면 파티션을 늘리면 되지만 여기에는 되돌리기 어려운 결정이 끼어 있다. Kafka는 파티션 수를 줄이는 기능을 제공하지 않는다. 파티션을 추가하면 이후 레코드의 키-파티션 매핑도 달라질 수 있어, 파티션 내 키 순서에 의존하는 애플리케..

🧐 들어가기전우리팀은 서비스 데이터는 AWS Aurora에서 관리하고, 마케팅 데이터나 외부 데이터의 수집 분석 도구로는 GCP BigQuery를 사용하고 있었다. 서로 다른 클라우드 플랫폼을 쓰다 보니, AWS 쪽 서비스 데이터를 주기적으로 BigQuery로 동기화해줘야 했다. 그리고 이 동기화를 위해 GCP에서 제공하는 Datastream 파이프라인을 이용하고 있었다. 하지만 문제는 비용이었다. Datastream 과금이 데이터 트래픽량에 따라 일별 1만~3만 원씩 빠져나가는 구조였으며, 월 30만~90만 원 사이를 오갔다. 그래서 이러한 비용 부담으로 인해 우리팀은 비용 절감이 필요하다고 판단이 들었고, 이를 위해 Datastream을 걷어내기로 하였다. Datastream을 대체하기 위해 애플리..

🧐 들어가기전"정말 필요한" 에러로그의 알림만 바로 슬랙으로 받으면 얼마나 좋을까?Datadog을 사용하던 시절에는 자동 그룹화, 패턴 인식, 알림 설정까지 잘 갖춰져 있었기 때문에 에러 로그 모니터링이 비교적 수월했다고 한다 (팀에서 Datadog을 사용하던 당시에 나는 없었기에 그 이점을 잘 모른다). 그러나 Datadog의 비용 부담이 커지면서 지속해서 사용하기 어려웠고, 대체재로 오픈소스 기반의 Prometheus + Loki + Grafana + Tempo 스택으로 전환하게 되었다. 회사를 처음에 들어오던 당시에는 해당 스택에 대한 불편함을 전혀 느끼지 못하였다. 하지만 이제 서비스를 개발하기 시작하면서 정말 필요한 에러 로그 알림만 바로 받아보고 싶다는 생각이 강하게 들기 시작하였다. 그래서..