line·2026년 7월 31일·5분 읽기큐레이션 요약

Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

관측성 데이터가 메트릭·로그·트레이스·프로파일별로 분산되면, 장애 원인을 파악하기 위해 사람이 여러 도구를 오가며 맥락을 연결해야 합니다. LY Corporation의 Home SRE 팀은 이를 해결하기 위해 Grafana 플러그인인 SRELens를 개발했습니다. SRELens는 자연어 질문을 바탕으로 LLM 에이전트가 관측성 데이터를 조회하고, 도구 호출과 비용·권한·안전 정책을 백엔드에서 통제하며 원인 후보를 근거와 함께 제시합니다. ## 관측성 데이터가 분산되며 발생한 문제 - 메트릭은 Grafana·IMON, 로그는 LaaS·IU, 트레이스는 IMON 트레이스·Tempo, 프로파일은 별도 도구에서 확인해야 했습니다. - 장애 분석 과정에서 시간 범위, 서비스명, 라벨, 트레이스 ID 등의 맥락을 여러 시스템에 반복해서 옮겨야 했습니다. - 자체 호스팅형 LGTM-P 스택을 구축해 데이터를 통합했습니다. - Mimir: 메트릭 - Loki: 로그 - Tempo: 트레이스 - Pyroscope: 프로파일 - OpenTelemetry Collector: 데이터 수집 및 전달 - 데이터가 한곳에 모여도 사용자가 적절한 데이터소스와 라벨, 쿼리 방법을 알아야 한다는 문제는 남았습니다. - 예를 들어 서비스명이 데이터소스마다 `service_name`, `resource.service.name` 등 다른 필드로 표현될 수 있습니다. ## 오픈소스 PoC에서 확인한 한계 - **사용자 컨텍스트와 권한 전파** - Grafana 인증 사용자 정보를 대화 기록, 사용량 한도, 조회 권한에 안정적으로 연결하기 어려웠습니다. - **시스템 프롬프트 제어** - 도구 호출 순서, 재시도, 위험 작업 제한 같은 운영 정책을 사용자 질의와 분리해 보호하기 어려웠습니다. - **짧은 도구 호출 라운드** - 메트릭·트레이스·로그를 순차적으로 확인해야 하는 장애 분석을 충분히 수행하지 못했습니다. - **데이터소스별 라벨 차이** - 올바른 데이터소스를 선택해도 라벨이나 필드가 다르면 검색 결과가 0건이 될 수 있었습니다. - **운영 및 라이선스 제약** - 사내 환경에 맞게 수정하고 배포하는 데 한계가 있었습니다. - 이를 통해 단순한 자연어 질의 기능보다, LLM 에이전트의 행동을 운영 환경에 맞게 통제하는 것이 더 중요하다는 결론을 얻었습니다. ## SRELens 아키텍처 - SRELens는 Grafana 애플리케이션 플러그인으로 동작합니다. - 프런트엔드는 Grafana 내부에 채팅 UI를 제공합니다. - 백엔드는 다음을 담당합니다. - LLM 호출 - 시스템 프롬프트 합성 - 도구 오케스트레이션 - 사용량 및 비용 제한 - 결과 크기와 재시도 제어 - 관측성 데이터 조회는 MCP 게이트웨이를 통해 수행합니다. - 업스트림 MCP 도구 외에도 Grafana 패널 검색과 이미지 렌더링을 위한 로컬 도구를 제공합니다. - `find_grafana_panel` - `render_grafana_panel` - 업스트림 도구와 로컬 도구는 `CompositeClient`를 통해 LLM에 일관된 인터페이스로 노출됩니다. ## 세 계층으로 분리한 프롬프트 설계 ### 베이스 시스템 프롬프트 - 조직 전체에 적용되는 전역 행동 정책입니다. - 다음과 같은 규칙을 포함합니다. - 도구 호출 순서 - 결과가 없을 때의 폴백 전략 - 결과가 잘렸을 때 집계 쿼리를 재실행하는 방법 - 대시보드 생성·수정·삭제 등 위험 작업의 안전 규칙 - 응답 형식과 분석 근거 제시 방식 - 관리자만 수정할 수 있으며, 별도 설정이 없으면 코드에 포함된 기본 프롬프트를 사용합니다. ### 데이터소스 프래그먼트 - 환경별 관측성 시스템 정보를 YAML 형태로 제공합니다. - 주요 내용은 다음과 같습니다. - 우선 사용할 Mimir·Loki·Tempo 데이터소스 UID - 서비스명을 찾기 위한 라벨 후보 - Loki 로그의 JSON 파싱 및 구조화 메타데이터 처리 방법 - SRE의 운영 지식을 미리 제공해 불필요한 탐색을 줄이고 분석 성공률과 속도를 높입니다. ### 사용자 프롬프트 - 담당 서비스, 선호 응답 형식, 자주 사용하는 대시보드 등 개인·팀의 맥락을 저장합니다. - Redis에 저장되며 시스템 프롬프트의 추가 컨텍스트로 주입됩니다. - 베이스 프롬프트를 덮어쓰지 않으므로 개인화가 조직 공통 안전 정책보다 우선할 수 없습니다. ## 백엔드 중심의 툴 오케스트레이션 - 프런트엔드가 시스템 프롬프트를 조립하지 않고, 백엔드 오케스트레이터가 모든 프롬프트 합성을 담당합니다. - 에이전트는 다음 루프를 반복합니다. 1. 사용자 질문을 LLM에 전달 2. LLM이 요청한 MCP 또는 로컬 도구 실행 3. 도구 결과를 다시 LLM에 전달 4. 최종 분석이 나올 때까지 반복 - 운영 안정성을 위해 코드 수준의 가드레일을 적용했습니다. - 최대 10라운드로 도구 호출 제한 - 동일 도구·동일 인자의 중복 호출 차단 - 도구별 재시도 최대 2회 - 개별 도구 결과 크기 제한 - 전체 요청이 커질 경우 오래된 도구 결과를 플레이스홀더로 치환 - `tool_call_id`를 유지해 호출과 결과의 연결 보장 - 결과가 없으면 라벨, 시간 범위, 데이터소스를 바꿔 재시도하도록 유도 ## 비용·요청량 및 장애 대응 정책 - 사용자별 일일 토큰 한도를 적용합니다. - 분당 요청 수를 제한하고, 한도 초과 시 HTTP 429를 반환합니다. - 응답 후 OpenAI가 반환한 실제 프롬프트·출력 토큰 사용량을 사용자별 일일 버킷에 기록합니다. - 사용량은 Asia/Seoul 기준 자정에 초기화됩니다. - Redis는 대화 기록, 사용자 프롬프트, 쿼터 저장에 사용됩니다. - Redis 장애가 발생해도 단일 채팅 요청은 계속 처리할 수 있도록 설계했습니다. - 대화 기록 및 개인화 기능은 제한될 수 있습니다. - SRELens 전체가 동시에 중단되지는 않습니다. ## 실제 장애 분석 방식의 변화 - 사용자는 “특정 시간대에 왜 에러가 늘었는가”처럼 자연어로 질문할 수 있습니다. - SRELens는 하나의 분석 흐름에서 메트릭, 로그, 트레이스를 연결해 확인합니다. - 예시 시나리오에서는 베타 환경의 오류 급증을 분석하면서 특정 API 요청인 `CopyMedia` 호출 증가와 관련된 원인까지 범위를 좁혔습니다. - 기존처럼 대시보드, 로그 검색 시스템, 트레이스 도구를 오가며 사람이 상관관계를 직접 맞출 필요가 줄어듭니다. - 분석 결과는 단순한 결론이 아니라 조회된 관측성 데이터와 근거를 함께 제시하는 것을 목표로 합니다. 운영 환경에서 LLM 기반 장애 분석을 도입할 때는 자연어 인터페이스보다 통제 구조를 먼저 설계하는 것이 중요합니다. 조직 정책과 환경별 데이터소스 지식을 프롬프트 계층으로 분리하고, 도구 호출·권한·비용·재시도를 백엔드 코드로 제한해야 안정적이고 재현 가능한 분석 도구를 만들 수 있습니다.

원문 읽기(새 탭에서 열림)

redis옵저버빌리티모델 컨텍스트 프로토콜grafana+3

gitlab·2026년 7월 8일·5분 읽기큐레이션 요약

AI 에이전트를 활용해 GitLab의 레이트 리미팅을 마이그레이션한 방법

GitLab은 3명의 엔지니어와 AI 에이전트를 활용해 레거시 애플리케이션·Rack 기반 레이트 리미팅을 `labkit-ruby` 단일 구현으로 통합했다. 에이전트는 코드 탐색, 사양 작성, 반복적인 구현과 테스트에는 효과적이었지만, 아키텍처 결정·점진적 롤아웃·관측성 설계·최종 판단은 여전히 사람의 책임이었다. 프로젝트의 성공을 결정한 것은 에이전트 자체보다 명확한 작업 루프, 작은 변경 단위, 점진적 배포, 그리고 실패를 되돌릴 수 있는 운영 체계였다. ## 레거시 레이트 리미팅 통합의 목표 - GitLab에는 다음 두 가지 레이트 리미팅 경로가 수년간 공존했다. - 애플리케이션 수준의 `Gitlab::ApplicationRateLimiter` - Rack 수준의 별도 레이트 리미터 - 목표는 두 시스템을 `labkit-ruby`의 단일 구현으로 통합하는 것이었다. - 새로운 구현은 다음 조건을 만족해야 했다. - 모든 요청에 적용될 만큼 안정적일 것 - 동작을 관측하고 테스트할 수 있을 것 - 장애 발생 시 되돌릴 수 있을 것 - 모놀리스와 다른 환경에서 동일하게 운영할 수 있을 것 - 기존 시스템에는 121개의 레이트 리미팅 키가 존재했다. ## 3명으로 구성된 포드와 AI 에이전트의 역할 - 포드는 세 명의 GitLab 엔지니어를 중심으로 구성됐다. - 모놀리스 측 구현과 롤아웃 담당 - `labkit-ruby`와 아키텍처 담당 - 범위 관리와 초기 gem 코드 작성 담당 - AI 에이전트는 다음 작업을 수행했다. - 코드와 기존 맥락 분석 - 기술 사양 초안 작성 - 범위가 제한된 변경 구현 - 테스트 작성 - 머지 리퀘스트 사전 검토 - GitLab Duo Code Review도 머지 리퀘스트의 품질 검토에 활용됐다. - 사람은 다음을 직접 맡았다. - 작업 범위 결정 - 아키텍처 설계 - 배포 및 롤아웃 판단 - 최종 리뷰와 승인 ## 사양-구현-검증 반복 루프 - 팀은 다음과 같은 엄격한 순서를 적용했다. 1. 에픽과 기존 코드 읽기 2. 사양 작성 3. 적대적 리뷰로 사양의 문제점 검토 4. 차단 이슈가 해결된 뒤 구현 5. 명시적인 증거를 바탕으로 검증 6. 머지 리퀘스트에 대한 적대적 리뷰 7. 필요 시 사람에게 에스컬레이션 8. 머지 - 적대적 리뷰는 최대 두 번의 해결 라운드까지만 허용하고, 이후에는 사람의 판단을 받도록 했다. - 프로젝트에서는 14개의 번호가 매겨진 사양과 30개가 넘는 `labkit-ruby` 머지 리퀘스트가 만들어졌다. - 레거시 코드처럼 맥락 파악과 반복 검증이 중요한 작업에서는 이처럼 제한된 루프가 에이전트 활용에 적합했다. ## 단계적 롤아웃과 에이전트가 잘한 작업 - 첫 번째 코호트에서는 트래픽이 많은 5개 키를 다뤘다. - `pipelines_create` - `notes_create` - `user_sign_in` - 그 외 주요 키 - 트래픽 비율을 `1% → 10% → 50% → 100%`로 단계적으로 높였고, 2026년 5월 5일 100% 배포를 완료했다. - 기존 `ApplicationRateLimiter`와 새 구현의 결과가 일치하는지 확인했지만, 단순히 불일치가 없다는 사실만으로 성공을 판단하지 않았다. - 실제로 제한에 걸릴 정도의 트래픽이 발생하지 않았을 가능성도 있기 때문이다. - 두 번째 코호트에서는 모놀리스 83개와 EE 12개를 포함한 95개 호출 지점을 두 개의 기능 플래그로 통합했다. - 이 작업을 수작업으로 했다면 약 95개의 플래그 변경과 190개의 YAML 수정이 필요했을 수 있지만, 에이전트는 이런 반복적인 코드베이스 전반의 변경에 특히 강했다. ## 관측성은 있었지만 실패 유형을 구분하지 못함 - 두 번째 코호트는 며칠간 섀도 모드에서 기존 구현과 비교되었고, 대체로 일치했다. - 그러나 강제 적용 모드로 전환한 뒤 인증되지 않은 일부 경로에서 식별자가 조용히 유실되는 문제가 발생했다. - 원인은 세 개의 `String` 값이 두 개의 원시 슬롯에 압축되면서 잘못된 값이 식별자를 덮어쓴 구조적 충돌이었다. - 일부 사용자는 짧은 시간 동안 일반적인 오류 메시지를 받았다. - 비교 시스템은 해당 키의 불일치를 이미 감지했지만, 대시보드가 다음을 구분하지 못했다. - 정상적인 동작 차이 - 데이터 구조 충돌 - 사용자에게 영향을 줄 수 있는 치명적 불일치 - 팀은 즉시 강제 적용 플래그를 끄고, 이틀 뒤 긴급 수정 사항을 배포했다. - 문제는 사양, 적대적 리뷰, 구현, 코드 리뷰, 점진적 롤아웃을 모두 통과했으므로, 단순히 “에이전트가 위험하다”기보다는 관측성이 충분히 세분화되지 않았던 것이 핵심 교훈이었다. ## 전체 키 인벤토리 관리의 실패 - 처음에는 다섯 개 코호트로 마이그레이션을 끝낼 계획이었다. - 마스터 브랜치 감사 과정에서 누락된 항목이 발견되어 여섯 번째 코호트를 추가했다. - Claude가 놓친 항목에는 다음이 포함됐다. - EE 전용 `notification_emails` - 일부 EE 레지스트리 항목 - 웹훅 관련 키 3개 - 1초 미만 주기의 `partner_*` 키 3개 - 고립된 어댑터 행 - 총 121개 키 중 17개가 초기 코호트에서 빠져 있었다. - 각 항목이 특정 코호트에 쉽게 들어가지 않는 이유는 있었지만, 목록에서 보이지 않아도 될 이유는 없었다. - 근본적인 실수는 에이전트와 사람이 전체 키 인벤토리 대비 진행 상황을 지속적으로 집계하도록 요구하지 않았다는 점이다. ## Redis 인프라 병목과 운영 판단 - `redis-cluster-ratelimiting`은 4개 샤드 클러스터로 운영됐다. - 마이그레이션으로 사용량이 증가하면서 기존에 알려져 있던 인프라 병목이 다시 나타났다. - 팀은 `maxclients`를 단계적으로 높였지만, 연결 수를 100,000까지 밀어붙이지 않고 75,000에서 중단했다. - 더 많은 연결을 허용하면 각 프라이머리의 CPU가 포화될 수 있었기 때문이다. - 각 샤드는 명령 실행에 하나의 코어를 사용했고, 수직 확장으로 해결할 여지도 제한적이었다. - 따라서 에이전트가 코드를 생성하더라도, 실제 배포 속도와 범위는 인프라 용량과 운영자의 판단에 의해 결정됐다. ## AI 에이전트가 바꾼 병목 - 에이전트 덕분에 코드 작성 자체는 더 이상 가장 느린 단계가 아니었다. - 대신 병목이 다음 영역으로 이동했다. - 사람의 리뷰 처리 용량 - 롤아웃 시점과 범위에 대한 판단 - 운영 중인 시스템을 주의 깊게 관찰하는 능력 - 에이전트는 요청하면 95개의 기능 플래그 같은 반복 작업도 만들어내지만, 그런 설계가 실제로 필요한지는 판단하지 못한다. - 예를 들어 코호트 1 이후 팀은 레이트 리미트마다 별도 기능 플래그를 두는 방식이 과도하다고 판단해 이후 마이그레이션에서는 적용하지 않기로 했다. - 에이전트와 협업하는 방법 자체도 학습이 필요했으며, 때로는 에이전트와 반복적으로 막혀 직접 처리하는 편이 빠르다고 느끼는 순간도 있었다. ## 최종 상태와 실용적인 교훈 - 2026년 6월 중순 기준으로 여섯 개 코호트가 모두 100% 롤아웃됐다. - `ApplicationRateLimiter`의 121개 키가 새 프레임워크를 통해 동작하게 되었고, 감사로 결과를 확인했다. - 이 사례에서 권장할 만한 방식은 다음과 같다. - 에이전트에는 반복적이고 범위가 명확한 변경을 맡긴다. - 아키텍처, 위험 허용 수준, 배포 중단 기준은 사람이 결정한다. - 전체 마이그레이션 대상을 인벤토리로 관리하고 누락 여부를 자동 검증한다. - 단순한 불일치 감지를 넘어 실패 원인과 심각도를 구분하는 관측성을 구축한다. - 기능 플래그와 점진적 롤아웃으로 즉시 되돌릴 수 있게 한다. - 코드 생성 속도가 빨라져도 리뷰와 운영 관찰에 필요한 사람의 시간을 충분히 확보한다.

원문 읽기(새 탭에서 열림)

redisAI 에이전트옵저버빌리티gitlab-duo-agent-platform+4

datadog·2026년 4월 21일원문

대규모 스테가노그래피: Datadog 위젯 스크린샷에 공유 URL 삽입하기 (새 탭에서 열림)

데이터독(Datadog)은 사용자가 위젯을 스크린샷으로 캡처하더라도 쿼리, 시간 범위, 대시보드 설정과 같은 풍부한 컨텍스트를 보존할 수 있도록 픽셀 단위의 '보이지 않는 워터마크' 시스템을 구축했습니다. 위젯의 메타데이터 전체를 이미지에 직접 담는 대신, 해당 데이터를 저장한 Redis 캐시의 고유 키를 위젯 테두리 픽셀의 RGB 값을 미세하게 조정하여 인코딩하는 방식을 채택했습니다. 이를 통해 사용자 경험을 해치지 않으면서도 하루 10억 개 이상의 위젯에 대해 스크린샷만으로 원본 데이터에 접근할 수 있는 연결성을 제공합니다. **스크린샷의 한계와 워터마킹의 도입 배경** - 대시보드 위젯을 복사하여 붙여넣으면 라이브 프리뷰와 데이터 연결이 유지되지만, 많은 사용자는 직관적이고 권한 문제에서 자유로운 스크린샷 방식을 선호합니다. - 하지만 일반적인 스크린샷은 캡처 시점의 쿼리, 시간 범위, 시각화 유형 등 유용한 메타데이터를 모두 잃어버린다는 단점이 있습니다. - UI에 요소를 추가하지 않고도 이 정보를 보존하기 위해, 육안으로는 식별할 수 없지만 알고리즘으로 읽을 수 있는 픽셀 기반 워터마킹 기술을 도입했습니다. **데이터 최적화 및 캐싱 전략** - 위젯 정의 데이터는 평균 2KB로 이미지에 직접 인코딩하기에는 너무 크기 때문에, 전체 데이터는 Redis 캐시에 저장하고 이를 참조하는 짧은 고유 ID만 워터마크에 포함합니다. - 위젯이 렌더링될 때마다 프론트엔드에서 낙관적(Optimistic)으로 ID를 생성하여 백엔드 응답을 기다리지 않고 즉시 워터마크를 삽입함으로써 성능 저하를 방지합니다. - 조직 ID와 8바이트 무작위 ID를 조합하여 대규모 환경에서도 ID 충돌 가능성을 극도로 낮추었으며, 데이터는 스크린샷이 주로 활용되는 시간대를 고려해 1시간 동안 캐싱됩니다. **픽셀 레벨의 미세 인코딩 기법** - 모든 대시보드 위젯이 공통적으로 가진 1px 두께의 테두리를 데이터 삽입 공간으로 활용하여 시각화 유형에 상관없이 일관된 적용이 가능하게 했습니다. - RGB 모델의 각 채널 값을 미세하게 오프셋(Offset)하는 방식을 사용합니다. 기본 배경색에서 각 채널값을 조정한 뒤 0~7 사이의 값을 더해 픽셀당 약 9비트의 데이터를 저장합니다. - 워터마크의 시작과 끝을 알리는 센티널(Sentinel) 픽셀을 배치하고 그 사이에 8개의 데이터 픽셀을 넣어 총 8바이트의 ID를 인코딩하며, 이는 육안으로 거의 식별되지 않습니다. 이 시스템은 장애 대응이나 협업 과정에서 스크린샷이라는 익숙한 도구를 사용하면서도, 필요할 때 언제든 원본 데이터 컨텍스트로 복귀할 수 있는 강력한 연결성을 제공합니다. 대규모 트래픽 환경에서도 성능 영향 없이 작동하도록 설계된 이 기법은 단순한 이미지를 지능적인 데이터 포인터로 변환하는 실용적인 해법을 제시합니다.

redisdatadog성능 최적화watermarking+3

datadog·2026년 4월 21일원문

대규모 스테가노그래피: Datadog 위젯 스크린샷에 공유 URL 임베딩하기 (새 탭에서 열림)

Datadog은 사용자가 대시보드 위젯을 스크린샷으로 캡처할 때 유실되는 쿼리, 시간 범위 등의 컨텍스트를 보존하기 위해 픽셀 수준의 보이지 않는 워터마크 기술을 도입했습니다. 위젯의 테두리 픽셀에 미세한 색상 변화를 주어 메타데이터 키를 인코딩함으로써, 정적 이미지에서도 원본 데이터와 상호작용할 수 있는 기능을 구현했습니다. 이 시스템은 하루 10억 개 이상의 위젯 렌더링을 처리하면서도 사용자 경험에 영향을 주지 않는 성능과 투명성을 유지합니다. ### 스크린샷의 한계와 보이지 않는 워터마크의 필요성 - 대시보드 공유 링크는 실시간 데이터와 쿼리 정보를 포함하지만, 많은 사용자는 여전히 직관적이고 권한 문제에서 자유로운 스크린샷 공유를 선호합니다. - 일반적인 스크린샷은 이미지 픽셀 정보만 남기 때문에, 당시의 구체적인 타임프레임이나 기반 쿼리, 대시보드 상태와 같은 중요한 컨텍스트가 모두 사라집니다. - Datadog은 사용자 인터페이스를 해치지 않으면서도 스크린샷 내부에 보이지 않게 메타데이터를 심어, 이미지를 다시 Datadog이나 협업 도구(Slack 등)에 붙여넣었을 때 원본 위젯을 복구하고자 했습니다. ### 효율적인 데이터 관리를 위한 Redis 캐싱 전략 - 위젯 정의(Definition) 데이터는 평균 2kB로 이미지에 직접 모두 인코딩하기에는 너무 큽니다. - 이를 해결하기 위해 전체 위젯 정의는 Redis 캐시에 저장하고, 이를 식별할 수 있는 짧은 8바이트 고유 키(Snapshot ID)만 워터마크로 인코딩합니다. - 하루 10억 건 이상의 위젯 렌더링과 초당 35,000건의 피크 타임을 감안하여, 충돌 방지를 위해 조직 ID(Org ID)를 조합한 키 구조를 사용하며 데이터는 1시간 동안 유지됩니다. - 지연 시간을 최소화하기 위해 프론트엔드에서 낙관적(Optimistic)으로 ID를 생성하여 렌더링 즉시 워터마크를 적용합니다. ### 픽셀 단위의 RGB 인코딩 메커니즘 - 모든 위젯에 공통적으로 존재하는 1픽셀 두께의 테두리(Border)를 데이터 삽입 위치로 선정하여 시각적 일관성을 유지합니다. - 워터마크는 총 10개의 픽셀로 구성됩니다. 시작과 끝을 알리는 2개의 센티널(Sentinel) 픽셀과 그 사이의 8개 데이터 픽셀이 배치됩니다. - 각 데이터 픽셀은 1바이트(8비트)를 저장하며, RGB 채널에 비트를 분산(R: 3비트, G: 3비트, B: 2비트)하여 저장합니다. - 기본 색상에서 채널별로 아주 미세한 오프셋(최대 +7)만 조정하기 때문에 육안으로는 원본 테두리 색상과 구분이 불가능합니다. 이 기술은 대규모 트래픽 환경에서도 성능 저하 없이 정적 이미지에 생명력을 불어넣는 창의적인 엔지니어링 사례입니다. 협업 과정에서 스크린샷을 자주 활용하는 팀이라면, Datadog의 이러한 기능을 통해 이미지 너머의 원본 지표와 쿼리를 즉시 추적하여 문제 해결 속도를 높일 수 있습니다.

redisdatadogincident-managementwatermarking+3

toss·2026년 4월 16일원문

Apache Flink + RocksDB 튜닝으로 광고 Frequency Capping 실시간 집계를 일주일까지 확장하기 (새 탭에서 열림)

토스 데이터 서비스 플랫폼 팀은 광고 노출 집계의 정확성을 높이고 서빙 효율을 개선하기 위해, 기존 Airflow 배치와 Flink 스트리밍이 혼재된 시스템을 전면 Flink 기반의 실시간 슬라이딩 집계 시스템으로 전환했습니다. 1분부터 7일까지의 광범위한 집계 구간을 단일 Redis 조회로 제공하기 위해 집계 특성별로 Flink 앱을 분리하고, RocksDB 및 런타임 설정을 최적화하여 비즈니스 오차를 최소화했습니다. 이 과정에서 대규모 상태(State) 관리와 초기 데이터 적재의 정합성 문제를 해결하며 운영 신뢰성을 확보했습니다. ### 광고 노출 제어(Frequency Capping)의 중요성 * 광고주 예산 낭비를 막고 노출 기회 손실을 방지하기 위해 사용자별 광고 노출 횟수를 정확하게 카운트하고 제어하는 메커니즘입니다. * 광고 상품에 따라 '하루 3회', '7일간 1회' 등 집계 구간이 다양하므로, 1분부터 7일까지의 모든 구간에 대해 이벤트 단위의 정밀한 슬라이딩 윈도우 집계가 필요합니다. ### 기존 시스템의 한계와 개선 동기 * 기존에는 Airflow를 이용해 당일(Head), 과거(Mid), 경계 보정(Tail)의 3단계로 나누어 처리하는 배치 구조를 사용했으나, 유지보수해야 할 DAG가 너무 많고 구조가 복잡했습니다. * 서빙 시점에 구간별로 Redis를 최대 4회 조회해야 하는 구조적 번거로움이 있었으며, 실시간으로 변하는 슬라이딩 윈도우를 정밀하게 구현하는 데 한계가 있었습니다. ### 병목 패턴에 따른 앱 분리 및 아키텍처 * 집계 구간별 병목 현상이 다르다는 점에 착안하여 시스템을 **Minutes**(1~30분), **Hours**(최대 12시간), **Days**(최대 7일)의 3개 앱으로 분리했습니다. * **Minutes**: 빈번한 만료 처리로 인한 Write Stall이 주요 병목이며, RocksDB Write 경로 튜닝이 핵심입니다. * **Hours**: 대량의 광고 ID 누적으로 인한 Filter Block Cache Miss와 CPU 포화가 발생하여 Managed Memory 증설이 필요합니다. * **Days**: Savepoint가 230GB에 달하는 대규모 상태가 병목이며, Checkpoint I/O 문제를 해결하기 위해 Changelog State Backend를 활용합니다. * Flink State를 '단일 진실 공급원(SSOT)'으로 삼아, 장애 발생 시에도 Redis를 State로부터 언제든 다시 구성할 수 있도록 설계했습니다. ### 초기 적재와 전환 정합성 확보 * 7일치의 과거 데이터를 채우는 과정에서 '백필(카운트만 수행)'과 '캐치업(카운트와 만료 타이머 함께 등록)' 파이프라인을 분리하는 2단계 구조를 설계했습니다. * 백필 도중 만료 타이머가 미리 발화하여 집계가 틀어지는 문제를 방지하기 위해, 백필 완료 후 특정 시점부터만 Redis에 쓰기가 수행되도록 제어했습니다. * `withIdleness` 설정을 통해 특정 파티션의 지연이 전체 Watermark 진행을 막지 않도록 하고, `timerState`의 TTL을 윈도우보다 길게 설정해 지연 상황에서도 감소 로직이 누락되지 않도록 보장했습니다. ### RocksDB와 런타임 최적화 * **Minutes 앱**: Write Buffer Manager(WBM) 압박을 완화하여 RocksDB가 쓰기를 멈추는 Write Stall 현상을 방지했습니다. * **Hours 앱**: Bloom Filter 및 메모리 설정을 통해 캐시 미스를 줄여 CPU 효율을 높였습니다. * **Days 앱**: 거대한 SST 파일로 인한 체크포인트 부하를 줄이기 위해 레벨 최적화와 Changelog 메커니즘을 적용했습니다. 대규모 데이터를 다루는 실시간 집계 시스템에서는 모든 구간을 하나의 설정으로 처리하기보다, 데이터의 규모와 병목 지점에 따라 앱을 분리하고 각기 다른 RocksDB 튜닝 전략을 적용하는 것이 운영 안정성 측면에서 효과적입니다. 또한, 상태(State)를 시스템의 최상위 데이터 원천으로 관리하는 원칙을 지킬 때 장애 복구와 데이터 정합성 유지가 훨씬 용이해집니다.

redis데이터베이스 설계apache-flinkairflow+3

gitlab·2026년 4월 15일원문

GitLab 19.0의 중대 변경 사항 가이드 (새 탭에서 열림)

GitLab 19.0은 이전 메이저 업데이트 대비 파괴적 변경 사항(Breaking Changes)의 수를 대폭 줄여 안정성을 높이는 한편, 최신 보안 표준과 현대적인 인프라 기술로의 전환을 가속화합니다. 이번 릴리스는 NGINX Ingress의 대체, PostgreSQL 최소 요구 버전 상향, 보안상 취약한 인증 방식 제거 등 시스템 운영의 핵심적인 변화를 포함하고 있어 사용자들의 철저한 사전 준비가 필요합니다. 각 배포 유형에 따라 2026년 5월부터 순차적으로 적용될 예정이므로, 운영 환경의 호환성을 미리 점검하고 마이그레이션을 계획해야 합니다. ### 배포 유형별 업데이트 일정 * **GitLab.com (SaaS):** 2026년 5월 4일~6일 사이에 주요 변경 사항이 적용되며, 5월 11일~13일이 예비 기간으로 설정되었습니다. * **Self-Managed:** 2026년 5월 21일부터 공식적으로 19.0 버전을 사용할 수 있습니다. * **GitLab Dedicated:** 배포판 관리 정책에 따라 2026년 6월 22일 주간의 유지보수 창 내에 업데이트가 진행됩니다. ### 인프라 및 네트워킹 구성의 변화 * **Gateway API 및 Envoy 전환:** NGINX Ingress가 2026년 3월 종료됨에 따라, GitLab Helm 차트의 기본 네트워킹 구성이 Envoy Gateway 기반의 Gateway API로 변경됩니다. 기존 NGINX 사용자는 20.0 버전 전까지 수동으로 활성화하여 유지할 수 있으나 조속한 마이그레이션이 권장됩니다. * **내장형 컴포넌트 제거:** 테스트 및 PoC 용도로 제공되던 Helm 차트 내 번들 PostgreSQL, Redis, MinIO가 라이선스 및 유지보수 이슈로 인해 완전히 제거됩니다. 해당 서비스를 사용하는 환경은 반드시 외부 서비스로 전환해야 합니다. * **OS 지원 종료:** Ubuntu 20.04의 표준 지원 종료에 맞춰 해당 OS용 리눅스 패키지 제공이 중단됩니다. 19.0 업그레이드 전 Ubuntu 22.04 이상의 지원 버전으로 OS를 교체해야 합니다. ### 데이터베이스 및 미들웨어 요구사항 강화 * **PostgreSQL 17 필수화:** PostgreSQL 16 지원이 중단되고 17 버전이 최소 요구 사항이 됩니다. 리눅스 패키지 사용자는 18.11 버전에서 자동 업그레이드가 시도될 수 있으며, 클러스터 사용자는 수동 업그레이드가 필수입니다. * **Redis 및 Valkey 지원:** Redis 6 지원이 종료됩니다. 외부 Redis 운영 환경은 Redis 7.2 또는 새롭게 지원되는 Valkey 7.2로 마이그레이션해야 합니다. (AWS, GCP 등 클라우드 매니지드 서비스 포함) ### 보안 및 빌드 환경 업데이트 * **ROPC OAuth 흐름 제거:** 보안상 결함이 있는 리소스 소유자 비밀번호 자격 증명(ROPC) 방식이 OAuth 2.1 표준에 따라 완전히 제거됩니다. 이를 사용하는 앱이나 통합 서비스는 Authorization Code flow 등 보안이 강화된 방식으로 수정해야 합니다. * **Auto DevOps 빌더 업데이트:** 클라우드 네이티브 빌드팩(CNB) 이미지가 heroku/builder:22에서 24 버전으로 업데이트됩니다. 이를 통해 최신 런타임 환경을 지원하며 관련 파이프라인의 빌드 방식이 변경될 수 있습니다. 성공적인 GitLab 19.0 전환을 위해 Self-Managed 운영자는 18.x 버전대에서 제공되는 PostgreSQL 17 마이그레이션 도구를 미리 활용하고, Helm 차트 사용자는 Gateway API로의 네트워크 인프라 전환 계획을 우선적으로 수립할 것을 권장합니다.

redis데이터베이스 설계gitlabPostgreSQL+4

figma·2026년 3월 25일·3분 읽기큐레이션 요약

피그마의 차세대 데이터 캐싱 플랫폼 | 피그마 블로그

Figma는 Redis 기반 캐싱 인프라가 성장하면서 연결 수 한계, 급격한 확장 시 연결 폭주, 관측성 부족 등으로 가용성 위협이 커지자 이를 근본적으로 재설계했다. 그 결과 stateless RESP 프록시인 FigCache를 구축해 Redis 연결과 클라이언트 서비스 규모를 분리하고, 라우팅·보안·관측성을 중앙화했다. 2025년 하반기 핵심 API에 도입한 이후 캐싱 계층은 99.9999% 가동률을 달성했다. ## Redis 캐싱 인프라의 성장통 - Figma의 Redis는 단순한 보조 구성 요소에서 사이트 가용성에 직접 영향을 주는 핵심 의존성으로 발전했다. - Redis 클러스터의 연결 수가 한계에 가까워졌고, 클라이언트 서비스가 빠르게 확장될 때 대규모 연결 생성이 동시에 발생하는 ‘thundering herd’ 문제가 나타났다. - 중앙화된 트래픽 관리와 일관된 접근 방식이 없어 애플리케이션이 서로 다른 클러스터의 데이터를 오염시키거나 손상시킬 위험이 있었다. - 클라이언트 라이브러리마다 관측 기능이 달라 장애 원인 분석과 대응이 어려웠다. - 장애 조치나 토폴로지 변경 시 클라이언트 상태가 올바르게 유지되는지 전체 서비스에 일관된 보장을 제공하기도 어려웠다. - Figma는 일부 API 시스템에서 Redis 의존성을 제거하고, 서비스별 연결 풀링을 도입해 단기적으로 장애 영향을 줄였지만 장기적인 공통 플랫폼이 필요하다고 판단했다. ## 장기적인 설계 목표 - **클라이언트 연결 변동성으로부터 Redis 격리** - Redis가 처리하는 연결 수를 클라이언트 애플리케이션의 규모와 탄력적 확장성에서 분리한다. - 서비스가 급격히 확장될 때 Redis로 연결 요청이 몰리는 현상을 막는다. - **기본 제공 observability** - 서비스 소유자와 플랫폼 운영자가 멀티테넌트 환경에서 개별 워크로드의 가용성과 성능을 확인할 수 있도록 한다. - 여러 계층에서 일관되고 세밀한 모니터링 기능을 제공한다. - **투명한 수평 확장** - 클라이언트가 인프라 확장이나 축소를 직접 알 필요 없도록 한다. - 클러스터 확장·축소, 노드 장애 조치, 샤드 전체 손실 같은 복잡한 Redis Cluster 동작을 클라이언트 라이브러리 아래 계층에서 처리한다. - **단일 범용 엔드포인트** - 여러 Redis 클러스터를 애플리케이션별 개별 설정 없이 중앙 라우팅한다. - 클러스터 격리 수준, 내구성, 중요도, 트래픽 규모가 서로 다른 환경의 분할 결정을 중앙에서 관리한다. - **대체 저장소의 플러그인 가능성** - 같은 프로토콜과 API를 유지하면서 필요에 따라 진정한 내구성을 제공하는 다른 저장 기술을 연결할 수 있도록 한다. - **기본 확장성** - 인라인 데이터 암호화, 보호 장치(guardrail), 트래픽 백프레셔 등 Figma 고유의 데이터 플레인 기능을 애플리케이션마다 반복 구현하지 않도록 한다. ## FigCache의 구조와 역할 - FigCache는 **stateless RESP-wire-protocol 프록시 서비스**다. - Redis 데이터 플레인과 진입 계층 역할을 하며, 애플리케이션에는 언어와 무관한 일관된 Redis 인터페이스를 제공한다. - 여러 Redis 클러스터와 백엔드 사이의 트래픽 라우팅 및 클러스터 관리 복잡성을 애플리케이션에서 숨긴다. - 연결 멀티플렉서로 동작해 클라이언트 서비스의 연결 변동이 Redis에 직접 전달되지 않도록 한다. - FigCache 자체와 함께 Figma가 관리하는 전용 클라이언트 라이브러리를 제공해 캐싱 스택 전반의 동작을 표준화한다. ## 플랫폼 전환의 효과 - Redis 연결 확장성과 클라이언트 서비스의 용량 변동을 분리할 수 있게 됐다. - 중앙화된 라우팅으로 애플리케이션이 여러 클러스터의 엔드포인트를 직접 관리할 필요가 줄었다. - 보안 정책과 트래픽 제어를 공통 계층에서 적용할 기반이 마련됐다. - 전체 캐싱 스택에 걸친 종합적인 관측성을 확보했다. - 2025년 하반기 Figma의 메인 API 서비스에 적용한 뒤 캐싱 계층은 **99.9999% 가동률**이라는 안정성 목표를 달성했다. ## 실용적인 시사점 Redis를 서비스의 핵심 경로에서 사용할 때는 개별 애플리케이션의 연결 풀링만으로 문제를 해결하기보다, 연결 중계·라우팅·클러스터 토폴로지 관리·관측성을 공통 플랫폼으로 분리하는 것이 효과적이다. 특히 클라이언트 수가 탄력적으로 변하는 환경에서는 프록시 계층을 통해 Redis가 직접 연결 폭주를 겪지 않도록 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

redis옵저버빌리티분산 시스템caching+2

line·2026년 3월 24일원문

SRE 팀의 반복 작업을 10분의 1로 줄인 SRE 봇 개발기 (새 탭에서 열림)

LINE Home DevOps 팀은 인프라 전환과 서비스 확대로 급증한 운영 문의 및 반복적인 배포 요청 문제를 해결하기 위해 Slack 기반의 통합 자동화 도구인 'SRE 봇'을 구축했습니다. 기존에 수동으로 수행하던 Jira 티켓 생성, 컨플루언스 체크리스트 복사, 배포 매뉴얼 검색 등의 프로세스를 자동화하여 업무 시간을 획기적으로 단축하고 휴먼 에러를 방지했습니다. 이를 통해 팀은 단순 반복 업무에서 벗어나 서비스 안정화와 인프라 고도화라는 본연의 업무에 집중할 수 있는 환경을 마련했습니다. ### 수동 운영 프로세스의 한계와 비효율성 * **복잡한 워크플로와 컨텍스트 스위칭:** 배포 요청 한 건을 처리하기 위해 Slack, Confluence, Jira 등 여러 플랫폼을 오가며 정보를 복사-붙여넣기해야 했으며, 이 과정에서 1건당 약 1시간의 시간이 소요되었습니다. * **휴먼 에러의 빈번한 발생:** 수동 작업 특성상 릴리스 버전 설정 오류, 필수 체크리스트 항목 누락, Epic 링크 연결 누락 등 실수가 잦았고, 긴급 상황일수록 이러한 문제는 더욱 심화되었습니다. * **가시성 부족과 정량화의 어려움:** Slack 멘션으로 들어오는 요청은 휘발성이 강해 진행 상황 추적이 어려웠으며, 팀의 업무량을 정량적으로 파악하여 성과로 증명하기 힘든 구조였습니다. ### 사용자 편의와 시스템 안정성을 고려한 기술적 설계 * **Slack 워크플로 기반 UI:** 사용자가 직접 명령어를 입력하는 방식 대신 Slack 워크플로 양식을 채택하여 필수 항목 누락을 방지하고 사용자의 진입 장벽을 낮췄습니다. * **백그라운드 비동기 처리:** Slack API의 응답 제한 시간(3초) 내에 외부 시스템(Jira, Confluence)과의 복잡한 연동을 마칠 수 없으므로, 즉시 응답 후 실제 작업은 백그라운드에서 수행하는 비동기 방식을 선택했습니다. * **Redis를 활용한 상태 관리:** Slack 스레드와 Jira 티켓 간의 매핑 정보를 Redis에 저장(TTL 30일 설정)하여 100ms 미만의 빠른 조회 성능을 확보하고, 트랜잭션을 통해 여러 SRE가 동시에 작업할 때 발생할 수 있는 동시성 문제를 해결했습니다. ### 헥사고날 아키텍처를 통한 유연한 확장성 확보 * **포트와 어댑터 패턴 적용:** Slack, Jira, Redis 등 외부 시스템과의 결합도를 낮추기 위해 헥사고날 아키텍처를 도입했습니다. * **비즈니스 로직 보호:** 인터페이스를 통해 외부 환경을 격리함으로써 Jira API 버전 업그레이드나 Slack SDK 변경 등 외부 변화가 발생하더라도 내부의 핵심 비즈니스 로직을 수정할 필요가 없도록 설계했습니다. * **테스트 및 유지보수 용이성:** 각 레이어가 명확히 분리되어 있어 기능 추가 시 영향 범위를 최소화할 수 있으며, 테스트 코드 작성이 수월해져 안정적인 코드베이스 유지가 가능해졌습니다. ### 도입 후 시나리오별 변화 및 성과 * **배포 요청 처리 시간 단축:** 기존 30분 이상 걸리던 배포 요청 처리가 SRE 봇 도입 후 1분 이내로 단축되었습니다. 봇이 Fix Version 생성, 티켓 연결, 매뉴얼 검색을 10초 만에 자동 수행하기 때문입니다. * **긴급 대응 및 가시성 개선:** 긴급 요청 시 즉시 우선순위가 높게 설정된 티켓이 생성되고 채널에 알림이 공유됩니다. SRE는 이모지 클릭만으로 본인에게 티켓을 할당하고 상태를 업데이트할 수 있어 실시간 추적이 용이해졌습니다. * **정기적인 업무 정량화:** 모든 요청이 정형화된 Jira 티켓으로 자동 기록됨에 따라, 팀원당 투입 시간과 처리 건수를 명확히 데이터화하여 운영 성과를 증명할 수 있게 되었습니다. 단순 반복적인 운영 업무로 인해 팀의 에너지가 고갈되고 있다면, 기술적인 자동화 레이어를 구축하여 'Zero Manual Work'를 지향하는 것이 장기적인 팀 생산성 향상의 핵심입니다. Slack과 같은 협업 툴을 Single Point of Truth로 설정하고 외부 시스템을 유연하게 연결하는 아키텍처를 고민해 보시기 바랍니다.

redis데이터베이스 설계slackjira+4

daangn·2025년 12월 23일원문

당근페이 AI Powered FDS로 가는 여정: 룰엔진구축부터 LLM 적용까지 (새 탭에서 열림)

당근페이는 급변하는 이상거래 패턴에 유연하게 대응하기 위해 룰엔진 중심의 FDS를 구축하고, 최근에는 LLM을 결합하여 탐지 정교화와 모니터링 효율성을 극대화하고 있습니다. 초기 룰엔진은 조건, 규칙, 정책의 계층 구조로 설계되어 실시간 탐지와 제재를 가능하게 했으며, 여기에 LLM 기반의 맥락 분석을 더해 검토 시간을 단축하고 판단의 일관성을 확보했습니다. 금융 보안 규제를 준수하면서도 최신 AI 모델을 실무에 적용해 사용자 자산을 보호하는 선도적인 FDS 운영 사례를 제시합니다. **유연한 탐지를 위한 룰엔진의 구조** * 룰엔진은 조건(빌딩 블록), 규칙(조건의 조합), 정책(규칙의 묶음)의 3단계 계층 구조로 설계되어 레고 블록처럼 탐지 로직을 조립할 수 있습니다. * '가입 후 N일 이내', '송금 횟수 N건 이상'과 같은 개별 임계값을 자유롭게 변경하며 새로운 사기 패턴에 즉각적으로 대응할 수 있는 환경을 마련했습니다. * 이벤트 유입 경로는 즉시 차단이 필요한 '동기 API'와 대량의 이벤트를 실시간으로 분석하는 '비동기 스트림'으로 분리하여 처리 효율을 높였습니다. **룰엔진 기반의 위험 평가 및 사후 처리** * 유입된 모든 거래 이벤트는 설정된 정책과 규칙에 따라 위험 평가를 거치며, 그 결과에 따라 LLM 평가, 고객 서비스팀 알람, 유저 제재 등의 후속 조치가 자동 수행됩니다. * 시스템 도입 후 실시간으로 규칙을 추가하거나 변경하며 사기 트렌드를 빠르게 반영한 결과, 금융 및 수사기관으로부터의 사기 관련 정보 요청 건수가 유의미하게 감소했습니다. * 탐지 로직의 유연화는 단순 차단을 넘어 시스템 전반의 유저 상태 동기화까지 통합적으로 관리할 수 있는 기반이 되었습니다. **LLM 도입을 통한 지능형 FDS로의 진화** * 기존의 수동 검토 방식은 건당 5~20분이 소요되고 담당자마다 판단 결과가 달라질 수 있는 한계가 있어, 이를 해결하기 위해 LLM을 통한 맥락 분석 기능을 도입했습니다. * 전자금융업의 망분리 규제 문제를 해결하기 위해 '혁신금융서비스' 지정을 받았으며, AWS Bedrock의 Claude 3.5 Sonnet 모델을 활용해 보안과 성능을 모두 잡았습니다. * BigQuery의 사기 이력을 Redis에 캐싱하고, 이를 구조화된 프롬프트(XML 태그 및 JSON 형식)에 결합하여 LLM이 사기 여부와 그 근거를 일관되게 평가하도록 설계했습니다. 효율적인 FDS 운영을 위해서는 룰 기반의 명확한 통제와 AI 기반의 유연한 맥락 분석이 조화를 이루어야 합니다. 특히 LLM을 실무에 적용할 때는 규제 준수를 위한 기술적/행정적 준비와 함께, AI가 정교한 판단을 내릴 수 있도록 단계별로 명시적이고 구조화된 프롬프트를 설계하는 과정이 무엇보다 중요합니다.

redisAI대규모 언어 모델fraud-detection+5

line·2025년 12월 5일원문

동적 사용자 분할을 활용한 새로운 A/B 테스트 시스템을 소개합니다 (새 탭에서 열림)

동적 유저 세분화(Dynamic User Segmentation) 기술을 도입한 새로운 A/B 테스트 시스템은 사용자 ID 기반의 단순 무작위 배분을 넘어 특정 속성과 행동 패턴을 가진 정교한 사용자 그룹을 대상으로 실험을 수행할 수 있게 합니다. 이 시스템은 타겟팅 엔진과 테스트 할당 로직을 분리하여 데이터 기반의 의사결정 범위를 개인화된 영역까지 확장하며, 서비스 품질 향상과 리소스 최적화라는 두 가지 목표를 동시에 달성합니다. 결과적으로 개발자와 마케터는 복잡한 사용자 시나리오에 대해 더욱 정확하고 신뢰할 수 있는 실험 데이터를 얻을 수 있습니다. ### 기존 A/B 테스트 방식과 고도화의 필요성 * **무작위 배분의 특징**: 일반적인 시스템은 사용자 ID를 해싱하여 실험군과 대조군으로 무작위 할당하며, 구현이 쉽고 선택 편향(Selection Bias)을 줄일 수 있다는 장점이 있습니다. * **타겟팅의 한계**: 전체 사용자를 대상으로 하는 일반적인 테스트에는 적합하지만, '오사카에 거주하는 iOS 사용자'처럼 특정 조건을 충족하는 집단만을 대상으로 하는 정교한 실험에는 한계가 있습니다. * **고도화된 시스템의 목적**: 사용자 세그먼트를 동적으로 정의함으로써, 서비스의 특정 기능이 특정 사용자 층에게 미치는 영향을 정밀하게 측정하기 위해 도입되었습니다. ### 유저 세분화를 위한 타겟팅 시스템 아키텍처 * **데이터 파이프라인**: HDFS에 저장된 사용자 정보(UserInfo), 모바일 정보(MobileInfo), 앱 활동(AppActivity) 등의 빅데이터를 Spark를 이용해 분석하고 처리합니다. * **세그먼트 연산**: Spark의 RDD 기능을 활용하여 합집합(Union), 교집합(Intersect), 차집합(Subtract) 등의 연산을 수행하며, 이를 통해 복잡한 사용자 조건을 유연하게 조합할 수 있습니다. * **데이터 저장 및 조회**: 처리된 결과는 `{user_id}-{segment_id}` 형태의 키-값 쌍으로 Redis에 저장되어, 실시간 요청 시 매우 낮은 지연 시간으로 해당 사용자의 세그먼트 포함 여부를 확인합니다. ### 효율적인 실험 관리와 할당 프로세스 * **설정 관리(Central Dogma)**: 실험의 설정값은 오픈 소스 설정 저장소인 Central Dogma를 통해 관리되며, 이를 통해 코드 수정 없이 실시간으로 실험 설정을 변경하고 동기화할 수 있습니다. * **할당 로직(Test Group Assigner)**: 클라이언트의 요청이 들어오면 할당기는 Central Dogma에서 실험 정보를 가져오고, Redis를 조회하여 사용자가 타겟 세그먼트에 속하는지 확인한 후 최종 실험군을 결정합니다. * **로그 및 분석**: 할당된 그룹 정보는 로그 스토어에 기록되어 사후 분석 및 대시보드 시각화의 기초 자료로 활용됩니다. ### 주요 활용 사례 및 향후 계획 * **콘텐츠 및 위치 추천**: 특정 사용자 세그먼트에 대해 서로 다른 머신러닝(ML) 모델의 성능을 비교하여 최적의 추천 알고리즘을 선정합니다. * **마케팅 및 온보딩**: 구매 빈도가 낮은 '라이트 유저'에게만 할인 쿠폰 효과를 테스트하거나, '신규 가입자'에게만 온보딩 화면의 효과를 측정하여 불필요한 비용을 줄이고 효율을 높입니다. * **플랫폼 확장성**: 향후에는 LY Corporation 내의 다양한 서비스로 플랫폼을 확장하고, 실험 생성부터 결과 분석까지 한 곳에서 관리할 수 있는 통합 어드민 시스템을 구축할 계획입니다. 이 시스템은 실험 대상자를 정교하게 선별해야 하는 복잡한 서비스 환경에서 데이터의 신뢰도를 높이는 데 매우 효과적입니다. 특히 마케팅 비용 최적화나 신규 기능의 타겟 검증이 필요한 팀이라면, 단순 무작위 할당 방식보다는 유저 세그먼트 기반의 동적 타겟팅 시스템을 구축하거나 활용하는 것을 권장합니다.

redisapache-sparkdata-architecturepersonalization+3

airbnb·2025년 10월 9일원문

에어비앤비의 키-값 저장소에서 정적 속도 제한에서 적응형 트래픽 관리로 (새 탭에서 열림)

에어비앤비는 분산 키-밸류 저장소인 'Mussel'의 트래픽 관리 방식을 단순 요청 횟수 제한(QPS)에서 자원 기반의 적응형 제어 시스템으로 진화시켰습니다. 이 시스템은 요청의 실제 비용을 계산하는 자원 인식형 속도 제한(RARC)과 우선순위 기반의 부하 차단(Load Shedding) 계층을 도입하여 시스템의 유용 작업량(Goodput)을 극대화합니다. 결과적으로 Mussel은 예기치 못한 트래픽 급증이나 DDoS 공격 상황에서도 핵심 서비스의 성능을 안정적으로 유지할 수 있게 되었습니다. ### 정적 QPS 제한의 한계와 자원 인식형 제어(RARC)의 도입 기존의 단순 QPS 제한 방식은 요청의 복잡도와 상관없이 동일한 할당량을 차감했기에 효율적인 자원 관리가 불가능했습니다. * **비용 가변성 해결**: 단일 행 조회와 수만 행의 스캔 작업을 동일하게 취급하던 문제를 해결하기 위해, 행 수, 바이트 크기, 대기 시간(latency)을 결합한 '요청 단위(RU, Request Unit)' 개념을 도입했습니다. * **RU 계산 모델**: 읽기 비용은 $1 + w_r \times \text{읽은 바이트} + w_l \times \text{대기 시간}$과 같은 선형 모델을 통해 산출되며, 이는 하드웨어 리소스(CPU, I/O)에 가해지는 실제 부하를 더 정확하게 반영합니다. * **토큰 버킷 알고리즘**: 각 디스패처(Dispatcher)는 짧은 에포크(Epoch)마다 할당된 RU를 로컬 토큰 버킷에 채우고, 요청마다 실시간으로 계산된 비용을 차감하여 할당량 초과 시 즉각적으로 요청을 거부합니다. ### 지연 시간 비율 기반의 적응형 부하 차단 트래픽이 급격히 변하거나 특정 샤드에 병목이 발생할 때, 시스템 전체의 붕괴를 막기 위해 실시간 신호를 기반으로 한 부하 차단 메커니즘을 운용합니다. * **지연 시간 비율(Latency Ratio) 활용**: '장기 p95 지연 시간'을 '단기 p95 지연 시간'으로 나눈 비율을 시스템 스트레스 지표로 사용합니다. 이 비율이 설정값(예: 0.3) 이하로 떨어지면 시스템 부하가 급증한 것으로 판단합니다. * **임계치 기반의 단계적 대응**: 시스템 스트레스가 감지되면 낮은 우선순위의 클라이언트 그룹부터 RU 비용을 가중해 부과함으로써 자연스럽게 트래픽 백프레셔(Backpressure)를 유도합니다. * **P² 알고리즘 적용**: 고정된 메모리 내에서 대기 시간의 백분위수(Percentile)를 추정하는 P² 알고리즘을 사용하여, 별도의 샘플 저장소나 노드 간 통신 없이도 개별 디스패처가 신속하게 의사결정을 내릴 수 있습니다. ### 데이터 접근 패턴 최적화 및 안정성 확보 단순히 요청을 차단하는 것을 넘어, 데이터 접근의 불균형으로 인한 병목 현상을 해결하는 메커니즘을 포함합니다. * **핫키(Hot-key) 탐지 및 완화**: 특정 키에 대한 요청이 집중되는 패턴을 실시간으로 감지하여, 백엔드 저장소에 도달하기 전 캐싱하거나 중복 요청을 하나로 합치는(Coalescing) 방식으로 저장소 계층을 보호합니다. * **트래픽 분리 및 고립**: 특정 클라이언트의 데이터 패턴으로 인해 발생한 병목이 전체 클러스터로 전이되지 않도록 격리 수준을 높여 다중 사용자(Multi-tenant) 환경의 안정성을 강화했습니다. 멀티 테넌트 환경의 대규모 시스템을 운영한다면 단순한 횟수 기반의 제한보다는 자원 소비량을 기반으로 한 RU 모델과 시스템 상태에 반응하는 적응형 부하 차단 전략을 도입하는 것이 서비스 가용성 확보에 훨씬 유리합니다.

redis쿠버네티스분산 시스템rate-limiting+4

line·2025년 8월 7일원문

자네, 해커가 되지 않겠나? Hack Day 2025에 다녀왔습니다! (새 탭에서 열림)

LY Corporation의 'Hack Day 2025'는 19년째 이어져 온 전통 있는 사내 해커톤으로, 직무와 국적에 상관없이 구성원들이 자유롭게 아이디어를 기술로 구현하는 혁신적인 개발 문화를 상징합니다. 참가자들은 24시간 동안 몰입하여 프로토타입을 제작하며, 'Perfect the Details' 정신을 바탕으로 기술적 검증과 협업의 가치를 실현합니다. 이번 행사는 단순한 개발을 넘어 글로벌 동료들과의 네트워크를 강화하고 창의적인 시도를 장려하는 LY Corporation만의 독보적인 기술 축제로 자리매김했습니다. **자유로운 협업과 글로벌 팀 빌딩** * 과거 야후 재팬 시절부터 시작되어 19회차를 맞이한 Hack Day는 기획자, 디자이너, HR 등 사내 구성원 누구나 참여할 수 있는 열린 행사입니다. * 온/오프라인 밋업과 Zoom, Miro 등의 툴을 활용해 한국, 일본, 대만, 베트남 등 다양한 국가의 멤버들이 'Global Mixed Team'을 구성하여 협업합니다. * 하이브리드 워크 환경에 맞춰 이동 시간 및 업무 집중 시간을 보장하는 'Travel Day' 제도를 통해 원격 근무자들이 오프라인에서 밀도 있게 협업할 수 있는 환경을 제공합니다. **몰입을 돕는 환경과 해커톤의 문화** * 행사 기간 동안 오피스의 한 층을 통째로 사용하며, 팀별 독립 공간과 화이트보드, 모니터 등 개발에 필요한 인프라를 전폭적으로 지원합니다. * 1일 차 오전 9시, 전 참가자가 모여 "Hack Time!"을 외치는 개회 선언을 통해 행사의 본격적인 시작을 알리는 전통이 있습니다. * 에너지 소모가 큰 해커톤 특성을 고려하여 시간대별로 도넛, 컵라면 등 다양한 간식과 전 세계 법인에서 가져온 이색 먹거리를 무제한 제공하여 개발에만 집중할 수 있게 돕습니다. **AI 모델을 활용한 기술적 실천과 유연한 피보팅** * 실제 프로젝트 사례로 Slack 커뮤니케이션 기록과 AI 모델을 결합해 개개인의 협업 성향을 분석하는 '전투력 측정' 프로그램을 개발했습니다. * 성격 심리학 모델인 'Big 5 Personality'를 도입하여 데이터의 신뢰성을 확보하고, 이를 게임 캐릭터 능력치처럼 시각화하여 재미 요소를 더했습니다. * 개발 마지막 단계에서 포토 프린터 하드웨어 장애라는 변수가 발생하자, 실물 카드 출력 대신 파일 다운로드 방식으로 기획을 신속하게 변경하며 해커톤 특유의 유연한 문제 해결 능력을 발휘했습니다. **성과 공유를 위한 90초 발표와 부스 운영** * 3일 차에는 각 팀이 결과물을 공유하며, 90초라는 엄격한 시간 제한 속에서 핵심 기능과 데모를 선보이는 '라이브 피칭'을 진행합니다. * 발표 후에는 별도의 부스 운영 시간을 통해 심사위원과 다른 참가자들이 직접 서비스를 체험해 보고 기술적인 디테일에 대해 심도 있는 질의응답을 나눕니다. * 창의성, 기술적 완성도, 발표 전달력을 종합적으로 평가하여 시상하며, 이를 통해 사내 기술 트렌드를 공유하고 성취감을 고취합니다. Hack Day와 같은 사내 해커톤은 일상적인 업무에서 벗어나 최신 기술(AI 등)을 실험하고 동료와의 유대감을 쌓을 수 있는 최고의 기회입니다. 기술적 성장에 목마른 조직이라면, 결과물의 완벽함보다는 24시간 동안의 몰입 경험과 그 과정에서 발생하는 유쾌한 시행착오를 장려하는 문화를 구축해 보길 추천합니다.

redisAI생성형 AI프롬프트 엔지니어링+5

datadog·2025년 8월 4일원문

대규모 성능을 위해 Rust로 구축한 실시간 시계열 저장소를 다시 발전시키다 (새 탭에서 열림)

데이터독(Datadog)은 급증하는 데이터 볼륨과 고카디널리티(high-cardinality) 워크로드를 처리하기 위해 Rust 기반의 6세대 실시간 시계열 데이터베이스 엔진을 새롭게 설계했습니다. 기존 시스템의 한계를 극복하기 위해 인제스션(Ingestion), 저장, 쿼리 실행 구조를 근본적으로 재구성함으로써 수집 성능은 60배, 쿼리 속도는 최대 5배까지 향상시키는 성과를 거두었습니다. 이 글은 지난 15년간 데이터독이 카산드라에서 시작해 Rust 기반의 전용 엔진에 이르기까지 거쳐온 기술적 진화 과정과 그 과정에서 얻은 교훈을 다룹니다. ### 데이터독 시계열 저장소의 아키텍처 데이터독의 메트릭 플랫폼은 데이터의 효율적인 처리를 위해 실시간 저장소와 인덱스 데이터베이스를 분리하여 운영합니다. * **RTDB (Real-time DB):** `<timeseries_id, timestamp, value>` 형태의 원시 메트릭 데이터를 저장하고 집계하며, 최신 데이터를 실시간으로 서빙합니다. * **인덱스 데이터베이스:** 메트릭 식별자와 태그 정보를 `<timeseries_id, tags>` 형태로 관리합니다. * **데이터 흐름:** 쿼리가 발생하면 상위 서비스가 RTDB와 인덱스 노드에 각각 접속하여 결과를 가져오고, RTDB 노드 내부는 인테이크(Intake), 스토리지 엔진, 스냅샷 모듈, gRPC 쿼리 실행 계층 등으로 구성되어 유기적으로 동작합니다. ### 1세대부터 3세대: 확장성과 운영 효율의 탐색 초기 데이터독은 기성 솔루션을 활용하며 실시간 쿼리 성능과 운영 편의성을 확보하는 데 집중했습니다. * **Gen 1 (Cassandra):** 뛰어난 쓰기 확장성을 제공했으나, 알람 및 분석에 필요한 복잡한 실시간 쿼리를 지원하기 어렵고 대규모 데이터셋 반환 시 효율이 떨어지는 한계가 있었습니다. * **Gen 2 (Redis):** 빠른 읽기 속도와 운영 가시성을 제공했지만, 싱글 스레드 특성상 라이브 트래픽 처리 중 스냅샷 작업이 어려웠고 데이터 직렬화/역직렬화에 따른 CPU 및 메모리 비용이 증가했습니다. * **Gen 3 (MDBM):** `mmap`을 통해 OS 페이지 캐시를 활용하는 메모리 맵 방식의 키-값 저장소를 도입했으나, 대규모 워크로드에서 성능과 정확성 이슈가 발생하며 명시적인 I/O 관리의 필요성을 체감했습니다. ### 4세대와 5세대: 커스텀 엔진과 기능 확장 성능 한계를 돌파하기 위해 범용 DB를 벗어나 전용 스토리지 엔진을 직접 구현하기 시작했습니다. * **Gen 4 (Go 기반 B+ Tree):** Go 언어로 구현된 커스텀 B+ 트리 엔진을 도입하여 '코어당 스레드(thread-per-core)' 모델의 기초를 닦았으며, 처리량과 지연 시간 면에서 큰 진전을 이루었습니다. * **Gen 5 (RocksDB 통합):** 분포 메트릭(distribution metrics)과 DDSketch 타입을 지원하기 위해 RocksDB를 병행 도입했습니다. 하지만 기존 Go 엔진과 RocksDB가 공존하는 구조는 관리가 복잡하고 효율성이 분산되는 결과를 낳았습니다. ### 6세대: Rust 기반의 통합 엔진으로의 전환 파편화된 엔진을 통합하고 성능을 극대화하기 위해 Rust를 선택하여 차세대 시스템을 구축했습니다. * **통합 및 최적화:** 스칼라 값과 스케치 데이터를 모두 처리할 수 있는 단일 엔진을 Rust로 구축하여 언어 차원의 안정성과 고성능 I/O 제어권을 확보했습니다. * **성능 성과:** 이 구조적 변화를 통해 데이터 수집 성능을 60배 높였으며, 피크 시간대 쿼리 속도를 5배 향상시켜 전례 없는 규모의 트래픽을 효율적으로 수용하게 되었습니다. **결론 및 추천** 시스템 규모가 커짐에 따라 범용 데이터베이스나 `mmap`과 같은 추상화 계층은 오히려 성능 병목이 될 수 있습니다. 데이터독의 사례처럼 워크로드의 특성에 맞춰 I/O와 메모리 레이아웃을 직접 제어할 수 있는 전용 엔진을 구축하는 것이 기술적 부채를 해결하고 폭발적인 성장을 뒷받침하는 핵심 전략이 될 수 있습니다. 특히 Rust와 같은 시스템 프로그래밍 언어는 고성능 실시간 시스템을 재설계할 때 강력한 도구가 됩니다.

redis데이터베이스 설계Rustgrpc+4

discord·2025년 5월 1일·4분 읽기큐레이션 요약

디스코드가 수조 개의

Discord는 메시지 검색을 Elasticsearch 기반으로 운영했지만, 메시지와 트래픽이 조 단위로 증가하면서 Redis 큐 유실, 장애에 취약한 벌크 색인, 대규모 클러스터의 운영 부담, 단일 인덱스의 문서 수 제한 문제가 발생했다. 이를 해결하기 위해 Kubernetes와 Elastic Kubernetes Operator(ECK)를 도입하고, 거대한 클러스터 대신 여러 개의 작은 클러스터를 운영하는 셀(cell) 아키텍처로 전환하려 했다. 목표는 장애 격리, 무중단 업그레이드, 확장성, 비용 효율성을 동시에 확보하는 것이었다. ## 기존 메시지 검색 구조 - 2017년 Discord는 Elasticsearch에 메시지를 색인했다. - 메시지는 Discord 서버(guild) 또는 DM 단위로 Elasticsearch 인덱스에 분산했다. - 같은 guild의 메시지를 한곳에 모아 검색 속도를 높였다. - 클러스터를 여러 개로 나누어 관리 가능한 규모를 유지했다. - 사용자가 검색을 이용하지 않는 경우를 고려해 메시지는 지연 색인(lazy indexing)했다. - Redis 기반 메시지 큐와 작업자가 메시지를 묶음으로 가져와 Elasticsearch 벌크 색인을 수행했다. ## Redis 메시지 큐의 메시지 유실 - Elasticsearch 장애로 색인 작업이 밀리면 Redis 큐에 메시지가 빠르게 쌓였다. - 큐가 과도하게 커지면서 Redis CPU 사용량이 한계에 도달했고, 결국 메시지가 유실됐다. - 즉, 색인 대상 메시지를 안정적으로 보관해야 할 큐 자체가 장애 지점이 되었다. ## 장애에 취약한 벌크 색인 - 한 번의 벌크 요청에 서로 다른 인덱스와 Elasticsearch 노드에 속한 메시지가 함께 포함됐다. - 예를 들어 50개 메시지를 색인하는 요청이 최대 50개 노드로 분산될 수 있었다. - 그중 단 하나의 노드라도 실패하면 벌크 요청 전체가 실패하고, 모든 메시지를 다시 큐에 넣어 재시도해야 했다. - 100개 노드 클러스터에서 50개 메시지를 무작위로 색인할 때, 특정 노드 하나가 장애 나면 요청 중 약 40%가 실패할 수 있었다. - 실제 장애 하나가 색인 실패와 재시도를 대량으로 유발해 Redis 큐 적체를 악화시켰다. ## 대규모 Elasticsearch 클러스터의 운영 부담 - 메시지와 guild 수가 증가할 때 노드와 인덱스를 추가하는 방식으로 수평 확장했다. - 하지만 클러스터가 커질수록 하나의 벌크 작업이 더 많은 인덱스와 노드로 분산됐다. - 이로 인해 노드 간 조정과 네트워크 팬아웃 비용이 커져 색인 성능이 저하됐다. - 노드 수가 많아질수록 어느 한 노드에서 장애가 발생할 가능성도 증가했다. ## 롤링 재시작과 보안 업데이트의 어려움 - 단일 노드 장애에도 색인 시스템이 크게 영향을 받았기 때문에 안전한 롤링 재시작이 어려웠다. - 200개가 넘는 노드와 수 테라바이트의 데이터를 가진 클러스터를 노드별로 비우고 재시작하는 데 지나치게 오랜 시간이 걸렸다. - 그 결과 오래된 운영체제와 Elasticsearch 버전을 계속 사용해야 했고, 보안 패치와 성능 개선을 적용하지 못했다. - Log4Shell 대응 당시에는 `log4j2.formatMsgNoLookups=true` 설정을 적용하기 위해 전체 검색 시스템을 중단하고 모든 노드를 재시작해야 했다. ## 대형 guild의 인덱스 크기 제한 - 일부 인덱스에는 매우 큰 guild의 메시지가 집중됐다. - Elasticsearch 인덱스는 내부적으로 하나의 Lucene 인덱스이며, 약 20억 개 문서라는 `MAX_DOC` 제한이 있다. - 이 한도에 도달하면 해당 인덱스의 모든 색인 작업이 실패한다. - 당시에는 Safety 팀과 협력해 스팸 목적의 guild를 찾아 삭제하는 방식으로 복구했다. - 그러나 정상적인 대규모 커뮤니티가 20억 개 이상의 메시지를 축적하는 상황도 지원해야 했다. ## Kubernetes와 Elastic Operator 도입 - Discord는 무상태 서비스 운영에서 이미 Kubernetes의 편의성과 비용 최적화 효과를 경험하고 있었다. - 이후 Elasticsearch 같은 상태 저장 서비스에도 Elastic Kubernetes Operator(ECK)를 적용하는 방안을 선택했다. - ECK를 사용하면 다음을 선언적으로 관리할 수 있다. - Elasticsearch 클러스터 토폴로지 - 노드 구성과 설정 - Kubernetes 노드풀 위의 클러스터 배포 - 운영체제 업그레이드를 자동화하고, 안전한 롤링 재시작과 Elasticsearch 업그레이드 도구를 활용할 수 있게 됐다. ## 여러 소형 클러스터를 사용하는 셀 아키텍처 - 기존처럼 200개가 넘는 노드를 가진 거대한 클러스터 하나를 운영하는 대신, 더 많은 수의 작은 Elasticsearch 클러스터를 운영하는 구조를 구상했다. - 작은 클러스터는 다음과 같은 이점을 제공한다. - 장애 범위 축소 - 클러스터 자체의 조정 오버헤드 감소 - 노드 장애가 전체 검색 시스템에 미치는 영향 완화 - 업그레이드와 유지보수의 단순화 - Kubernetes와 ECK를 기반으로 이러한 클러스터들을 표준화하고 운영하려 했다. 대규모 검색 시스템에서는 단순히 노드를 추가하는 것보다 장애 격리와 운영 가능성을 함께 설계하는 것이 중요하다. 특히 벌크 작업을 부분 실패에 강하게 만들고, 클러스터를 작은 단위로 나누며, 롤링 업그레이드가 가능한 플랫폼을 채택하는 것이 장기적인 안정성에 유리하다.

원문 읽기(새 탭에서 열림)

redis쿠버네티스분산 시스템elasticsearch+2

figma·2022년 6월 14일·4분 읽기큐레이션 요약

포스트모템: 20

Figma의 2022년 6월 서비스 장애는 Cluster-Mode Enabled(CME) ElastiCache Redis 노드의 Engine CPU가 100%에 도달하면서 발생했다. AWS는 CME 클러스터에서 높은 Redis Publish/Subscribe 부하를 처리할 때 발생하는 드문 버그를 원인으로 확인했으며, 트래픽을 새 ElastiCache 클러스터로 전환해 서비스를 복구했다. 장애는 총 네 차례 발생했지만 데이터 손실은 없었다. ## 장애 범위와 사용자 영향 - 장애 시간은 2022년 6월 6일 오후 11시 34분부터 7일 오전 10시 43분까지였다. - 총 네 차례의 서비스 중단이 발생했으며, 각 장애는 7분에서 최대 1시간 20분 동안 지속됐다. - 이미 열려 있던 파일은 계속 편집할 수 있었지만 다음 기능을 사용할 수 없었다. - 새 파일 열기 - 다른 사용자와 협업 - 일부 웹 API 기능 - 오프라인 상태에서 변경한 내용은 로컬에 저장됐고, 서비스가 회복될 때 서버에도 저장되어 데이터 손실은 발생하지 않았다. ## ElastiCache와 Redis 구성 - Figma는 AWS의 관리형 Redis 서비스인 ElastiCache를 다음 용도로 사용했다. - 자주 조회되는 데이터의 빠른 처리 - 서비스 간 메시지 전달 - 당시 두 종류의 ElastiCache 인스턴스를 운영했다. - **Cluster-Mode Disabled(CMD)**: 단일 Redis 클러스터 구조 - **Cluster-Mode Enabled(CME)**: 노드를 추가해 수평 확장 가능 - 장애가 발생하기 몇 주 전, Figma는 Redis Publish/Subscribe 트래픽을 CMD에서 CME 인스턴스로 이전했다. - 이전 후 몇 주 동안은 문제가 없었고, 장애 직전 트래픽이나 Redis 사용량에도 뚜렷한 변화가 없었다. ## CPU 100%를 유발한 CME 버그 - 장애의 직접적인 징후는 CME ElastiCache 노드 하나의 Engine CPU 사용률이 100%에 도달한 것이었다. - AWS 조사 결과, CME 클러스터에서 높은 Publish/Subscribe 부하가 발생할 때 Redis 내부의 드문 버그가 이 포화 상태를 유발한 것으로 확인됐다. - ElastiCache 기반 시스템에서는 하부 머신의 CPU 프로파일을 직접 확인할 수 없었기 때문에, 어떤 작업이 CPU를 소모하는지 즉시 파악하기 어려웠다. - Figma는 수년간 Publish/Subscribe를 사용했지만, CME로 이전하기 전까지는 같은 문제가 발생하지 않았다. ## 초기 대응과 클러스터 확장 - Figma는 원인을 용량 부족 또는 장애 난 하드웨어로 추정했다. - 대응을 위해 다음 조치를 동시에 수행했다. - 문제가 있는 노드의 failover 시작 - 더 큰 노드 타입과 더 많은 노드로 구성된 새 ElastiCache 인스턴스 생성 - 기존 노드의 failover가 예상보다 오래 걸리자, 새 클러스터인 V2로 트래픽을 전환해 서비스를 복구했다. - 그러나 이후 같은 CPU 포화 문제가 V2에서도 재발했다. - 결과적으로 클러스터 규모를 키우는 것이 이 버그를 해결하지 못했고, 오히려 상황을 악화시킬 수 있다는 사실이 드러났다. ## 원인 조사 과정 - Figma는 다음과 같은 가능성을 차례로 검토했다. - 정기 백업이나 예기치 않은 스냅샷이 노드를 일시적으로 과부하시켰을 가능성 - Redis 명령어 사용량이 갑자기 증가했을 가능성 - 느린 명령어, 대형 키 등 비정상적인 Redis 사용 - 장애 직전에 실행된 백그라운드 작업 - 백업이나 스냅샷과 관련된 징후는 발견되지 않았다. - Redis 명령어 사용량도 이전 몇 주와 비슷하고 안정적이었다. - 장애가 시작된 뒤에는 많은 명령어의 처리 시간이 길어졌지만, 이는 CPU가 이미 포화된 결과로 판단됐다. - 처리 시간이 긴 Redis 요청을 일부 차단했지만 문제를 해결하지 못했다. - 장애가 트래픽이 감소하던 시점에도 재발했기 때문에, 단순한 피크 트래픽이나 용량 부족만으로는 설명할 수 없었다. ## Failover를 통한 일시적 복구 - 두 번째 장애에서는 문제가 있는 노드의 failover가 정상적으로 완료되어 더 빠르게 서비스를 복구할 수 있었다. - 장애가 반복되는 동안 Figma는 Redis 요청, 백그라운드 작업, 클러스터 구성 등을 계속 비교하며 공통 패턴을 찾았다. - 최종적으로 AWS의 ElastiCache 서비스 팀이 CME 환경의 높은 Publish/Subscribe 부하와 관련된 Redis 버그를 확인했다. - AWS는 이후 CME 클러스터에서 Redis Publish/Subscribe 성능을 개선하는 작업을 진행했다. ## 실용적인 결론 Redis의 Publish/Subscribe를 CME ElastiCache로 이전할 때는 단순히 노드 수나 인스턴스 크기를 늘리는 것만으로 안정성이 보장되지 않는다. 관리형 서비스에서는 하부 시스템의 프로파일링이 제한되므로, CPU 포화·failover 지연·트래픽 우회 전략을 사전에 검증하고, 장애 시 다른 클러스터로 즉시 전환할 수 있는 구조를 마련하는 것이 중요하다.

원문 읽기(새 탭에서 열림)

redisincident-responseaws-elasticachepublish-subscribe+1