글

11월, 2025의 게시물 표시

KEDA를 활용한 로그 시스템 오토스케일링 경험담

우아한형제들은 KEDA를 활용하여 100만 TPS의 로그 시스템에 오토스케일링을 성공적으로 적용하였습니다. 이 경험을 통해 로그 처리의 변동성을 관리하며 비용 효율성을 높이는데 기여하게 되었습니다. 본 문서에서는 KEDA 도입 과정과 실제 운영 사례를 통한 운영 환경 개선 방안에 대해 설명합니다. KEDA 적용을 통한 로그 시스템 아키텍처 변화 KEDA를 도입하기 전, 우아한형제들은 기존 HPA를 이용하여 로그 시스템의 오토스케일링을 시도했습니다. 하지만 평균 CPU 및 메모리 사용량을 기준으로 스케일링이 진행되면서 한계에 봉착하게 되었습니다. KEDA의 도입 이후, 이벤트 기반으로 스케일링을 설정함으로써, 로그 시스템의 아키텍처를 유연하게 설계할 수 있었습니다. KEDA는 다양한 이벤트 소스를 지원하여 로그 시스템의 특성에 맞는 스케일링 기준을 설정할 수 있게 해줍니다. 예를 들어, Fluentd의 버퍼 사용률을 기준으로 스케일링 트리거를 설정함으로써, 시스템이 실제로 부하를 받기 시작하기 전에 프로세스를 조정할 수 있었습니다. 이는 로그 처리의 안정성을 크게 향상시켰고, 유연한 리소스 관리로 비용을 줄일 수 있는 기반을 마련하였습니다. 이러한 변화는 로그 시스템 아키텍처의 효율성을 높이고, 운영 환경을 개선하는 데에 결정적인 역할을 했습니다. 다양한 메트릭을 조합하여 스케일링 미세 조정이 가능해짐으로써, 시스템 부하가 예상되는 피크 시간대에도 원활하게 처리할 수 있는 역량을 갖추게 되었습니다. KEDA 도입을 통한 메트릭 기반 스케일링 효과 KEDA의 도입은 로그 시스템의 메트릭 기반 스케일링을 가능하게 하였습니다. 기존 HPA와 달리, KEDA는 프로메테우스를 이용해 다양한 지표를 직접적으로 활용할 수 있게 해줍니다. 이를 통해 CPU 및 메모리 사용량 외에도 Fluentd 버퍼와 같은 중요한 메트릭을 스케일링 기준으로 설정할 수 있었습니다. Fluentd의 버퍼가 일정 사용률을 초과할 경우 이를 위기 상황으로 간주하여 스케일 아웃을...
자세한 내용 보기

KEDA를 활용한 로그 시스템 오토스케일링 경험담

우아한형제들은 KEDA를 활용하여 100만 TPS의 로그 시스템에 오토스케일링을 성공적으로 적용하였습니다. 이 경험을 통해 로그 처리의 변동성을 관리하며 비용 효율성을 높이는데 기여하게 되었습니다. 본 문서에서는 KEDA 도입 과정과 실제 운영 사례를 통한 운영 환경 개선 방안에 대해 설명합니다. KEDA 적용을 통한 로그 시스템 아키텍처 변화 KEDA를 도입하기 전, 우아한형제들은 기존 HPA를 이용하여 로그 시스템의 오토스케일링을 시도했습니다. 하지만 평균 CPU 및 메모리 사용량을 기준으로 스케일링이 진행되면서 한계에 봉착하게 되었습니다. KEDA의 도입 이후, 이벤트 기반으로 스케일링을 설정함으로써, 로그 시스템의 아키텍처를 유연하게 설계할 수 있었습니다. KEDA는 다양한 이벤트 소스를 지원하여 로그 시스템의 특성에 맞는 스케일링 기준을 설정할 수 있게 해줍니다. 예를 들어, Fluentd의 버퍼 사용률을 기준으로 스케일링 트리거를 설정함으로써, 시스템이 실제로 부하를 받기 시작하기 전에 프로세스를 조정할 수 있었습니다. 이는 로그 처리의 안정성을 크게 향상시켰고, 유연한 리소스 관리로 비용을 줄일 수 있는 기반을 마련하였습니다. 이러한 변화는 로그 시스템 아키텍처의 효율성을 높이고, 운영 환경을 개선하는 데에 결정적인 역할을 했습니다. 다양한 메트릭을 조합하여 스케일링 미세 조정이 가능해짐으로써, 시스템 부하가 예상되는 피크 시간대에도 원활하게 처리할 수 있는 역량을 갖추게 되었습니다. KEDA 도입을 통한 메트릭 기반 스케일링 효과 KEDA의 도입은 로그 시스템의 메트릭 기반 스케일링을 가능하게 하였습니다. 기존 HPA와 달리, KEDA는 프로메테우스를 이용해 다양한 지표를 직접적으로 활용할 수 있게 해줍니다. 이를 통해 CPU 및 메모리 사용량 외에도 Fluentd 버퍼와 같은 중요한 메트릭을 스케일링 기준으로 설정할 수 있었습니다. Fluentd의 버퍼가 일정 사용률을 초과할 경우 이를 위기 상황으로 간주하여 스케일 아웃을...
자세한 내용 보기

장시간 비동기 작업 RDB 기반 태스크 큐로 해결

전자계약서 시스템의 대용량 엑셀 파일 생성 작업에서 발생한 Kafka 기반의 문제를 해결하기 위해 RDB 기반의 태스크 큐 아키텍처로 변경한 경험을 공유합니다. 이 글에서는 새로운 아키텍처의 구현 과정을 상세히 설명하며, 장시간 비동기 작업의 안정성과 효율성을 향상시키는 방법을 제시합니다. 최종적으로, 이 전환이 조직에 미친 긍정적인 영향을 파악할 수 있을 것입니다. 장시간 비동기 작업 처리의 어려움 장시간 비동기 작업을 처리하는 과정에서는 여러 가지 도전 과제가 존재합니다. 기존의 Kafka 기반 시스템은 대량의 데이터를 처리하는 데 있어 비효율적이었고, 이로 인해 동일 메시지가 중복 처리되는 문제가 발생하였습니다. 특히, 엑셀 파일 생성과 같은 작업은 외부 API 호출로 인해 시간이 소요되기 때문에, 해당 프로세스가 타임아웃에 걸리는 상황이 빈번하게 발생했습니다. 이런 문제점을 해결하기 위해 RDB 기반의 태스크 큐 아키텍처로 전환하는 것이 논의되었습니다. 새로운 아키텍처에서는 요청한 작업을 RDB에 영구적으로 기록함으로써, 상태 관리의 단순화를 이루었습니다. 이제 작업이 진행되는 동안의 상태를 지속적으로 추적할 수 있으며, 비정상적인 종료 시에도 작업 복구가 가능해졌습니다. 이를 통해 각종 장애 상황에서도 데이터 유실이 방지되며, 사용자에게 보다 안정적인 서비스를 제공하게 된 것입니다. 더불어, 이 아키텍처는 작업의 재시도 메커니즘을 자동으로 처리하게 설계되었습니다. 도중에 발생하는 외부 API 오류나 네트워크 문제로 인한 중단이 있더라도 최대 3회까지 작업을 자동으로 재시도합니다. 이를 통해 사용자는 더욱 신뢰할 수 있는 서비스를 경험하게 됩니다. 장기간 소요되는 비동기 작업의 처리에서 이러한 혁신적인 변화는 고객 만족도를 높이는 데 기여할 수 있습니다. RDB 기반 태스크 큐 아키텍처의 장점 RDB 기반의 태스크 큐 아키텍처 변경은 여러 장점을 가져왔습니다. 첫째, 시스템의 복잡성이 크게 감소했습니다. Kafka와 같은 메시지 ...
자세한 내용 보기

프런트엔드 독립 배포로 변화한 서비스 구조

우리 팀의 프런트엔드 개발 환경은 과거의 방식에서 벗어나 독립적인 배포 체계로 전환하는 과정을 거쳤습니다. 이 과정에서 index.html 파일을 프런트엔드 리포지터리로 이관하며 팀 내에서 발생했던 여러 문제를 해결하게 되었습니다. 이제는 프런트엔드 개발자들이 자율적으로 배포할 수 있는 환경이 조성되어, 효율성은 물론 역할 분담의 명확성까지 확보할 수 있었습니다. 프런트엔드 독립 배포의 의미 프런트엔드 독립 배포는 단순히 프런트엔드 리포지터리의 자율성을 강화하는 데 그치지 않습니다. 과거에는 백엔드 리포지터리에서 index.html 파일을 관리하면서 프런트엔드 개발자들이 HTML 파일의 수정이나 배포에 큰 제약을 받았습니다. 이는 서비스의 민첩성을 저하시켰고, 결국 성능 최적화 작업 또한 버겁게 만들었습니다. 독립 배포 체계 구축을 통해 프런트엔드 개발자들은 직접 HTML 파일을 수정하고 즉시 배포할 수 있게 되어, 신속하게 변화하는 사용자 요구에 대응할 수 있는 능력을 갖추게 되었습니다. 이러한 변화는 프런트엔드 리포지터리에 대한 책임을 명확히 하는 계기를 만들었습니다. 이제 프런트엔드 개발자들은 index.html 파일뿐만 아니라 모든 정적 리소스의 관리와 배포를 전적으로 담당하게 되었습니다. 이는 팀 내의 커뮤니케이션 비용을 줄이고, 문제가 발생했을 때 보다 빠른 원인 파악과 해결 방안을 제시할 수 있는 역량을 키우게 됩니다. 결과적으로 프런트엔드 독립 배포는 팀 전체의 업무 효율성을 크게 향상시켰습니다. 정적 리소스 관리의 체계적 변화 index.html 파일을 포함한 정적 리소스의 관리는 이전까지 백엔드와 프런트엔드 간의 경계가 불명확했습니다. 백엔드 리포지터리에서 모든 정적 자원을 관리하다보니, 프런트엔드 개발자는 자주 전화 연락이나 이메일을 통해 수정보다 불편을 느끼는 경우가 많았습니다. 하지만 프런트엔드 독립 배포가 자리잡으면서 이러한 문제는 해결되었습니다. 이제는 프런트엔드 팀이 직접 정적 리소스를 관리함으로써, HTM...
자세한 내용 보기

우아콘 2025 기술 공유와 미래 전달

2025년 10월, 우아한형제들은 삼성동 그랜드 인터컨티넨탈 파르나스에서 "Delivering the Future"라는 슬로건 아래 기술 콘퍼런스 WOOWACON 2025를 개최했습니다. 행사에서는 총 11개 분야에서 41개 세션이 진행되었으며, 58명의 발표자들이 참여하여 기술적 도전과 그 해결 방안을 공유했습니다. 이번 우아콘은 단순한 정보 공유의 자리에서 벗어나 기술과 사람의 교류를 통해 더 나은 미래로 나아가기 위한 의미 있는 축제로 자리매김했습니다. 우아콘 2025의 기술적 경험 공유 우아콘 2025는 기술 생태계의 발전을 위해 적극적으로 경험과 노하우를 나누는 자리로 꾸려졌습니다. 발표자들은 백엔드, 프런트엔드, AI/ML, 디자인 등 다양한 분야에서 실제로 사용된 기술적 경험과 사례를 공유했습니다. 특히, AI/ML 세션에서는 AI Agent를 통해 문제 해결의 구체적인 사례를 발표하고, '물어보새'와 같은 AI 데이터 분석 서비스의 발전 과정 또한 소개되었습니다. 이러한 세션은 참가자들에게 직접적인 인사이트와 영감을 제공했습니다. 발표자들은 자신의 실무 경험을 기반으로 한 이야기를 나누며, 기술적 문제를 해결하기 위한 다양한 관점을 제시했습니다. 로봇 세션에서는 B마트 배달을 위한 실외 로봇 '딜리'의 배달 수행 과정에 대해 이야기하며, 이를 위한 맵 서비스의 개발 과정과 도전 과제를 소개하였습니다. 백엔드 세션에서는 Kafka 장애 해결 사례를 통해 기술적 안정성과 확장성을 확보하는 방법에 대해 심도 있는 논의를 진행했습니다. 각 세션은 참가자들이 실무에 적용할 수 있는 유용한 팁과 교훈으로 가득 차 있어 실질적인 도움이 되었습니다. 우아콘은 단순히 기술적 성과를 나누는 것에 그치지 않고, 참가자들이 서로 소통할 수 있는 장으로도 기능하였습니다. 멘토링 세션과 발표자와의 대화를 통해 참가자들은 자신의 고민과 질문을 자유롭게 나누며 서로의 경험을 존중하는 분위기를 조성하였습니다....
자세한 내용 보기

플로팅웹뷰 도입으로 구현한 웹과 네이티브의 조화

웹과 네이티브의 경계가 허물어지는 시대에 접어들면서, 커머스 서비스는 사용자 경험을 높이기 위해 혁신적인 방법을 모색하고 있습니다. 플로팅웹뷰 도입을 통해 혁신적으로 웹과 네이티브의 조화로운 공존을 가능하게 하였으며, 이는 사용자에게 매끄러운 탐색 경험을 제공하는 데 기여했습니다. 이 글에서는 플로팅웹뷰가 어떻게 웹과 네이티브를 조화롭게 연결하여 새로운 사용자 경험을 창출했는지를 살펴보겠습니다. 조화롭게 공존하는 웹과 네이티브의 경험 플로팅웹뷰의 도입은 웹과 네이티브가 조화롭게 공존하게 만들어 줍니다. 초기에는 웹 페이지와 네이티브 영역의 분리가 이루어졌지만, 사용자 경험을 개선하기 위한 시도가 늘어나면서 두 영역이 접점에서 상호작용하게 되었습니다. 특히, 네이티브 내비게이션 탭바가 도입되면서 상단 헤더 영역에 네이티브가 포함됨으로써 두 영역 간의 충돌이 발생하게 되었습니다. 이와 같은 변화는 웹 기반의 하단 내비게이션 탭바의 문제를 부각시켰습니다. 페이지 로딩이 완료되기 전까지 하단 내비게이션이 미노출되면서 사용자는 불편한 탐색 경험을 하게 되었습니다. 이러한 상황에서 플로팅웹뷰는 투명한 UI를 통해 네이티브 영역 위에 웹 콘텐츠를 적절히 표시해 주는 솔루션이 되었고, 이를 통해 사용자들은 방해받지 않고도 필요한 정보를 쉽게 접근할 수 있게 되었습니다. 플로팅웹뷰는 단순히 페이지를 격리하는 것이 아닌, 웹과 네이티브의 경계를 허물고 자연스럽게 연결할 수 있는 역할을 수행하고 있습니다. 이처럼 두 영역의 조화는 신속한 사용자 탐색 경험을 가능하게 하며, 궁극적으로 커머스 서비스의 가치를 높이는 데 중요한 기여를 합니다. 누구나 인정할 수 있는 것은, 이러한 변화가 사용자에게 더 나은 서비스 경험을 제공하며, 이를 통해 고객 만족도를 향상시키는 데 기여한다는 점입니다. 플로팅웹뷰를 통한 사용자의 새로운 기대 플로팅웹뷰 도입으로 인해 사용자는 기대 이상의 새로운 경험을 하게 됩니다. 이전에는 웹과 네이티브가 서로 격리되어 있었지만, 플로...
자세한 내용 보기

Vite CSS 우선순위 문제 해결 사례

## 서론 우아한공방은 일관된 UI/UX를 제공하기 위해 개발된 디자인 시스템으로, 이번 글에서는 Vite 환경에서 발생한 CSS 우선순위 문제를 해결한 사례를 공유하고자 합니다. 이 문제는 컴포넌트의 스타일이 의도와 다르게 나타나는 원인이 되었으며, 일관성을 유지하기 위해 여러 시행착오를 거쳤습니다. 이를 통해 Vite에서 CSS 우선순위를 관리하는 방법을 깊이 있게 살펴보겠습니다. ## Vite에서 발생한 CSS 우선순위 문제 ### Step 1: 현상 파악 우아한공방은 코어 패키지를 중심으로 운영되며, 각 패키지는 서로 다른 스타일 파일을 갖고 있습니다. 특정 컴포넌트를 추가하거나 빌드 시 발생하는 CSS 우선순위 충돌은, 주로 스타일 import 순서에 따라 발생합니다. 특히 Chip 컴포넌트에서 발생한 스타일 문제는, reset CSS와 공용 스타일이 아닌 Flex 컴포넌트의 스타일이 덮어쓰는 현상을 보여주었습니다. 이는 의도하지 않은 스타일 적용으로, 사용자의 혼란을 초래할 수 있습니다. 우아한공방에서는 이와 같은 스타일 우선순위 문제를 해결하기 위해, import 순서에 따라 클래스가 변동하는 구조를 명확히 이해할 필요가 있었습니다. 이를 위해 다양한 테스트와 분석을 수행하였고, Vite의 빌드 프로세스가 ESM import 규칙을 준수한다는 사실을 발견했습니다. 이를 통해 import 순서가 최종 style.css에 어떻게 영향을 미치는지를 명확히 이해하게 되었습니다. ### Step 2: 문제 재현과 원인 분석 정확한 원인 분석 후, Vite의 CSS 우선순위 문제를 해결하기 위한 단계로 나아갔습니다. Vite는 Core CSS Plugin을 통해 각 스타일 청크를 load하고 build 과정에서 순차적으로 결합하는 방식을 취합니다. 이러한 과정에서 import 순서가 변동되면, 최종적으로 생성되는 style.css의 순서에도 영향을 미친다는 점을 확인했습니다. 특히, VanillaExtract와 같은 CSS 모듈 방식은 ...
자세한 내용 보기

우아한형제들 기술블로그 개인정보처리방침 변경 안내

우아한형제들은 기술블로그의 개인정보처리방침을 일부 변경하여 이를 공지하였습니다. 이번 개정은 개인정보의 수집, 이용 및 보유 기간에 대한 내용, 파기 절차 및 방법, 쿠키 허용/차단 방법에 대한 내용을 포함하고 있습니다. 개정 사항은 2025년 11월 12일에 공고되며, 2025년 11월 20일부터 시행됩니다. 개인정보의 수집 및 이용 기간의 변화 우아한형제들은 서비스 제공을 위해 개인정보를 수집하고 이용하는 방식을 지속적으로 개선하고 있습니다. 이번 수정된 개인정보처리방침에서는 회사가 수집한 개인의 정보를 이용하는 다양한 목적이 정리되었습니다. 이용자는 자신의 정보가 어떻게 활용되는지를 보다 명확히 이해할 수 있을 것입니다. 시스템적인 효율성을 높이기 위해 재구성된 이 내용은 이용자 식별 및 본인 확인, 뉴스레터 발송, 민원처리 및 고객상담, 고지사항 전달, 불법 및 부정 이용 방지 등 여러 항목으로 나뉘어 있습니다. 또한, 개인정보의 보유 및 이용 기간에 관해서도 명확하게 기술되어 있습니다. 과거와 동일하게 서비스 접속 기록 보관을 위한 목적은 중요하게 다뤄지며, 보유 기간은 3개월로 설정되어 있습니다. 이와 같은 조치는 고객의 개인정보 보호를 더욱 강화하기 위한 노력의 일환으로 볼 수 있습니다. 개인정보 파기 절차 및 방법의 현행화 개인정보의 파기 절차 및 방법 또한 이번 개정에서 기준이 더욱 확고히 다져졌습니다. 법령을 준수하여 개인정보를 안전하게 처리하는 것은 기업의 의무입니다. 기존의 개인정보 파기 관련 세부사항이 법령에 따라 업데이트되었으며, 통신비밀보호법 제15조의2 제2항에 준하여 보유된 데이터의 파기 절차가 구체적으로 명시되었습니다. 파기와 관련하여 예를 들어 보유 기간이 지난 후 어떤 방식으로 정보를 삭제할 것인지에 대한 구체적인 언급이 이루어졌습니다. 이러한 변화는 이용자의 개인정보가 불필요하게 오랜 기간 동안 보관되지 않도록 하며, 정보 유출의 위험성을 최소화하는 데 기여할 것입니다. 회사는 개인정보 보호 및 안전...
자세한 내용 보기

제민희 AI UX라이터의 개발 여정과 성과

우아한형제들이 새롭게 개발한 AI UX라이터 ‘제민희’는 UX라이터와 개발자들이 협력하여 많은 시행착오를 겪으며 완성한 프로젝트로, 디지털 프로덕트에서 사용자의 상호작용을 원활하게 돕는 역할을 합니다. 이 과정에서 문제 정의, 기술 검증, RAG 기반의 AI 발전 등 다양한 단계들이 있었으며, 이를 통해 효율적인 라이팅 업무를 구현하기 위해 노력했습니다. 따라서 제민희는 앞으로 사용자의 의도를 더욱 깊이 이해하고 창의적인 라이팅을 지원하는 목표로 진화해 나갈 것입니다. ‘진짜 문제’ 정의와 효율화의 시작 제민희 프로젝트의 첫 단추는 문제를 정의하는 것이었습니다. 프로젝트 초반, UX라이터와 개발자는 서로의 전문성에 대한 이해가 부족했습니다. UX라이터는 자기의 역할과 필요성에 대해 설명했지만, 개발자는 기술적 제약을 먼저 논의했습니다. 여기서 문제가 다소 비협조적으로 엉켜버린 것입니다. 이러한 상황을 극복하기 위해, UX라이터들은 기존의 작업 요청을 분석했습니다. 그 결과 ‘가이드 원칙의 일관성 체크’와 ‘의미 전달을 명확히 하기 위한 문구 수정’ 요청이 전체의 상당 부분을 차지하고 있다는 사실을 발견했습니다. 한마디로, 규칙을 패턴화할 수 있는 여지가 굉장히 크다는 것이었습니다. 이를 기반으로 간결하고 일관된 답변을 전달하는 방향으로 범위를 좁히고, 기술적 판단 기준을 세우는 데 성공했습니다. 이후, 프로젝트는 기존 라이팅 업무의 비효율성 문제를 해결하기 위해 ‘자동화’라는 대안을 중심으로 구성하게 됩니다. 하지만 비록 그 길이 순조롭지만은 않았습니다. 규칙 기반 툴을 구현하기 위한 기술 검증 단계에서는 예상한 것보다 많은 복잡성이 뒤따랐고, 각종 문장부호, 날짜 및 금액 표기 등 다양한 규칙을 포함해야 했습니다. 이에 따라, 빠르게 적용할 수 있는 기존 맞춤법 검사기나 오픈소스 형태소 분석기의 활용 가능성을 점검하게 되었습니다. 그러나 이 과정에서 업체의 기술 지원 중단이나 방대한 데이터 처리의 어려움 등 많은 도전에 직면하게 되었고, 이로 인...
자세한 내용 보기

LLM 연동 문제 해결 GenAI SDK 개발기

최근 LLM(대형 언어 모델)의 발전 속도가 가속화되면서 다양한 제공사에서 수많은 솔루션이 등장하고 있습니다. 이러한 변화에 따라 여러 모델의 API를 효과적으로 연동하는 것이 필수가 되었으며, 이를 위해 GenAI SDK가 개발되었습니다. 이 SDK는 LLM 호출을 단일 인터페이스로 간소화하고, API 키 관리의 번거로움을 줄이며, 모든 호출을 안전하게 기록하는 기능을 제공합니다. LLM 호출의 단일 인터페이스 제공 여러 LLM을 사용할 때 이들 각각의 제공사에서 요구하는 API 형태와 호출 방식이 달라 개발자는 복잡한 코드를 작성해야 했습니다. GenAI SDK는 이러한 문제를 해결하기 위해 단일 인터페이스 를 제공합니다. SDK의 구조는 LiteLLM이라는 오픈소스 라이브러리를 기반으로 하여, 각 LLM의 API를 통합하는 방식으로 설계되었습니다. 이를 통해 개발자는 단순히 메서드 호출을 통해 원하는 LLM을 호출할 수 있습니다. 예를 들어, AWS Bedrock이나 Google Gemini 같은 서로 다른 제공사의 API를 호출할 때도 동일한 메서드로 명령을 내릴 수 있습니다. 이로 인해 코드의 가독성이 향상되며, 유지보수가 용이해졌습니다. 또한, 사용자는 API 제공사를 명시할 필요 없이 모델 이름만으로도 통일된 방식으로 호출할 수 있습니다. 이러한 통합된 API 호출 방식은 특히 새로운 모델이나 제공사가 추가될 때 큰 장점을 제공합니다. 개발자는 추가적인 구성을 고려하지 않고도 새로운 모델이 지원되면 즉시 활용할 수 있습니다. 따라서 GenAI SDK는 개발자에게 빠른 프로토타이핑과 실험을 가능하게 하여 혁신적인 AI 솔루션의 개발을 촉진합니다. 중앙화된 API 키 관리 방식 도입 LLM 서비스를 개발할 때 API 키 관리 문제는 자주 발생하는 불편입니다. 각 LLM 제공사에서 발급받은 API 키를 별도로 관리하는 것은 시간과 노력을 소모하게 만들며, 새로운 제공사가 추가될 때마다 이 과정은 더욱 복잡해집니다. GenAI SD...
자세한 내용 보기

Redis CacheEvict 메커니즘 분석과 운영 주의사항

Redis의 @CacheEvict 어노테이션은 Spring 애플리케이션에서 캐시를 효율적으로 관리하는 데 유용하지만, 잘못 활용할 경우 심각한 성능 저하를 초래할 수 있습니다. 본 글에서는 @CacheEvict의 동작 메커니즘과 함께, 특히 allEntries = true 설정의 위험성을 분석하고 안전한 운영 방안을 제안합니다. 따라서, 이 글을 통해 캐시 관리의 고위험 요소를 인지하고 실무에 적용할 수 있는 인사이트를 제공하고자 합니다. 1. Redis CacheEvict 동작 메커니즘 분석 Redis에서 @CacheEvict 어노테이션은 캐시를 관리하는 강력한 도구지만, 그 작동 원리를 이해하는 것이 중요합니다. Spring에서는 @CacheEvict를 사용할 때, 캐시를 비우는 방식을 정의하는 여러 가지 메커니즘을 제시합니다. 특히, allEntries = true로 설정하면 특정 키가 아닌 전체 캐시를 비우게 되는데, 이는 캐시 무결성을 유지하기 위해 신중히 사용해야 합니다. 이 설정을 통해 전체 캐시를 지우는 과정에서 KEYS 명령어가 사용될 가능성이 큽니다. KEYS 명령어는 Redis에서 주어진 패턴으로 모든 키를 검색하며, 이 과정은 복잡한 연산으로 인해 많은 비용이 발생합니다. 이로 인해 Redis 서버는 과부하가 걸릴 수 있으며, 다른 요청들이 지연될 위험이 있습니다. 따라서, @CacheEvict의 메커니즘을 깊게 이해하고, 가능한 한 expensive operation인 KEYS를 피하는 것이 좋습니다. 대신 삭제할 키의 범위를 명확히 알고 있다면, 단일 키를 삭제하는 DEL 명령어를 사용하는 것이 더 바람직합니다. 이 방식은 단일 키에 대해 상수 시간이 소요되므로 서버에 미치는 영향이 적습니다. 개발자는 캐시의 구조와 기능에 대한 이해를 바탕으로, 어떤 경우에 어떤 방식을 사용할지를 신중히 판단해야 합니다. 2. 운영 환경에서의 @CacheEvict 주의사항 캐시 관리에서 @CacheEvict의 사용은 특히 운영...
자세한 내용 보기