aws·2026년 8월 3일·3분 읽기큐레이션 요약

AWS 주간 요약: Bedrock의 GPT 모델 가격 인하, Prometheus 지표를 위한 CloudWatch 관리형 수집기 및 기타 소식 (2026년 8월 3일) | Amazon Web Services

AWS의 이번 주 업데이트는 AI 비용 절감, 관측성 관리 간소화, 멀티클라우드 연결성 강화, 데이터 레이크 기능 확장에 초점을 맞춘다. Amazon Bedrock의 GPT-5.6 모델 가격이 최대 80% 인하됐고, CloudWatch는 관리형 Prometheus 수집기를 제공해 별도 에이전트 운영 부담을 줄인다. 또한 Oracle Cloud와의 전용 연결, IAM Identity Center의 멀티 리전 복제, Apache Iceberg V3의 Variant 데이터 타입 지원도 정식 또는 신규 기능으로 소개됐다. ### Amazon Bedrock GPT-5.6 가격 인하 - 2026년 7월 30일부터 OpenAI GPT-5.6 모델의 온디맨드 추론 가격이 자동으로 인하됐다. - GPT-5.6 Luna: - 입력 토큰 100만 개당 **0.20달러** - 출력 토큰 100만 개당 **1.20달러** - 기존 대비 최대 **80% 인하** - GPT-5.6 Terra는 가격이 **20% 인하**됐다. - 사용자가 별도 설정을 변경하거나 신청할 필요 없이 자동 적용된다. ### CloudWatch 관리형 Prometheus 수집기 - Amazon CloudWatch가 AWS 인프라에서 Prometheus 메트릭을 수집하는 완전 관리형 수집기를 지원한다. - 다음 서비스의 워크로드를 별도 에이전트 관리 없이 모니터링할 수 있다. - Amazon EKS - Amazon EC2 - Amazon ECS - Amazon MSK - Amazon OpenSearch Service - 직접 Prometheus 스크레이핑 인프라를 배포하고 유지하던 조직은 운영 및 업그레이드 부담을 줄일 수 있다. ### AWS와 Oracle Cloud 간 멀티클라우드 연결 - AWS Interconnect와 Oracle Cloud Infrastructure(OCI) 간 연결 기능이 정식 출시됐다. - 퍼블릭 인터넷을 거치지 않고 AWS와 OCI 사이에 전용 프라이빗 연결을 구성할 수 있다. - 멀티클라우드 환경에서 다음 요구사항을 충족하는 데 유리하다. - 네트워크 보안 강화 - 안정적이고 확장 가능한 연결 - 클라우드 간 애플리케이션 연동 - 지연 시간과 네트워크 성능 관리 ### IAM Identity Center 멀티 리전 지원 확대 - IAM Identity Center 디렉터리를 기본 자격 증명 소스로 사용하는 경우에도 멀티 리전 복제가 가능해졌다. - 기본 리전에 장애가 발생하면 추가 리전에 복제된 디렉터리와 권한 정보를 활용해 사용자가 AWS 계정에 계속 접근할 수 있다. - 기존에는 외부 자격 증명 공급자와 연결된 인스턴스에만 제공되던 기능이었다. - 리전 장애에 대비한 인증 가용성과 재해 복구 설계를 강화할 수 있다. ### Apache Iceberg V3의 Variant 데이터 타입 지원 - Amazon S3 Tables가 Apache Iceberg V3에서 도입된 **Variant** 데이터 타입을 지원한다. - Variant는 고정된 스키마를 적용하기 어려운 반정형 데이터를 JSON 블롭보다 효율적으로 저장하고 처리할 수 있도록 설계됐다. - 적용 사례: - IoT 센서 데이터 - 애플리케이션 로그 - 스키마가 자주 바뀌는 이벤트 페이로드 - 데이터 레이크에서 스키마 유연성을 확보하면서도 네이티브 처리 성능을 활용할 수 있다. ### 추가로 소개된 AWS 소식 - AWS CLI를 여러 플랫폼에서 한 줄 명령으로 설치하고 업데이트하는 방법이 공개됐다. - Moonshot AI의 Kimi K3를 SageMaker HyperPod와 Amazon EKS에 배포하는 단계별 가이드가 제공됐다. - Amazon MSK Express 브로커에서 Apache Iceberg 및 Amazon S3 Tables로 Kafka 데이터를 스트리밍하는 방법이 소개됐다. - 해당 데이터 전달 방식은 최대 **초당 10GB** 처리량을 지원한다. ### 예정된 AWS 행사 - AWS Summits가 2026년 하반기에도 개최되며, 클라우드와 AI 관련 기술 세션 및 커뮤니티 교류 기회를 제공한다. - AWS Community Days는 커뮤니티 리더가 콘텐츠를 기획하고 운영하는 지역 행사다. - AWS Builder Center에서는 개발자용 콘텐츠, 솔루션 공유, 온·오프라인 행사 정보를 확인할 수 있다. 실무적으로는 Bedrock 사용 조직이라면 모델 비용 절감 효과를 즉시 검토하고, Prometheus 운영 부담이 큰 팀은 CloudWatch 관리형 수집기로의 전환을 고려할 만하다. 멀티클라우드나 리전 장애 대응이 중요한 환경에서는 AWS Interconnect와 IAM Identity Center 멀티 리전 기능을 재해 복구 설계에 반영하는 것이 유용하다.

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

Apache Kafkaamazon-bedrockapache-icebergamazon-cloudwatch+4

toss·2026년 7월 30일·6분 읽기큐레이션 요약

토스의 디바이스 팜 만들기

네뷸라는 팀별로 흩어져 운영하던 실기기 테스트 환경을 중앙 플랫폼으로 통합해, 누구나 API 호출 한 번으로 실제 스마트폰을 제어할 수 있도록 만든 사내 디바이스 팜입니다. Appium 대신 자체 드라이버를 개발해 속도와 확장성을 높였고, 실시간 미러링·보안·24시간 운영 안정성까지 직접 구축했습니다. 그 결과 15대에서 시작한 팜은 100대를 넘어 수백 대 규모로 확장되며 전사 공용 테스트 인프라로 자리 잡았습니다. ## 팀별 디바이스 팜의 한계 - 각 팀이 맥북이나 맥미니에 5~10대의 기기를 직접 연결하고 관리했습니다. - Appium 설정, 기기 인식, OS 버전 대응, 연결 장애 복구를 팀마다 반복해야 했습니다. - 기기 관리와 테스트, 보안·컴플라이언스까지 개발자가 함께 맡아야 했습니다. - 팀별 자원이 격리되어 회사 전체의 기기를 효율적으로 공유하기 어려웠습니다. - 네뷸라는 이러한 운영 부담을 중앙화하고 전문 플랫폼으로 이전하기 위해 시작됐습니다. - 맥미니 5대와 기기 15대, 개발자 1명으로 시작해 1년간 100대 이상으로 성장했습니다. ## API 한 번으로 실기기 제어 - 사용자는 기기가 어느 호스트에 연결됐는지, ADB나 Xcode를 어떻게 설정했는지 알 필요가 없습니다. - `occupy` API로 조건에 맞는 기기를 점유한 뒤 액션 API를 호출하면 됩니다. - 예를 들어 다음과 같은 흐름으로 기기를 사용할 수 있습니다. - Android 기기 점유 - 좌표 `(540, 1200)` 클릭 - 테스트 종료 후 기기 반환 - 예약, 케이블 연결, 로컬 환경 설정을 숨기고 단순한 인터페이스를 제공하는 것이 네뷸라의 핵심 가치입니다. ## 네뷸라의 4계층 아키텍처 - **클라이언트** - 웹 프런트엔드, SDK·CLI, 직접 API 호출 등 다양한 접근 방식을 제공합니다. - **서버** - 기기 발견·점유·할당·테스트 실행을 관리하는 오케스트레이션 계층입니다. - 테스트 요청은 Kafka로 전달되고 여러 Runner가 분산 처리합니다. - `occupy · assign · release` 기반 분산 락으로 한 기기를 여러 테스트가 동시에 사용하는 문제를 방지합니다. - **에이전트** - iOS용 Mac mini와 Android용 Linux 호스트에서 실행됩니다. - ADB·Xcode로 연결된 기기를 자동 발견하고 서버 요청을 로컬 기기로 전달합니다. - **기기 계층** - 기기마다 controller server와 controller runner가 동작합니다. - 실제 화면 클릭, 텍스트 입력 등의 동작은 이 계층에서 수행됩니다. ## Appium 대신 개발한 Nebula Driver ### 빠른 명령 처리 - Appium과 Android 기기에서 명령 지연을 비교한 결과, 클릭·입력 작업에서 네뷸라가 10배 이상 빠른 경우가 있었습니다. - Appium은 동작 전 화면이 안정될 때까지 기다리는 `waitForIdle`을 사용해 견고성을 높입니다. - 네뷸라는 화면이 진행 중이어도 노드에 바로 명령을 전달하고 즉시 반환하는 속도 우선 방식을 택했습니다. - `waitForIdle`을 끄면 성능 격차가 2~3배 수준으로 줄어들지만, 실시간 조작이 중요한 네뷸라에는 속도 중심 설계가 적합했습니다. ### Stateless 구조 - Appium은 세션 기반이라 세션 생성에 약 15~40초가 걸릴 수 있습니다. - 기기 수가 늘수록 세션 생성 실패와 세션 관리 비용도 증가합니다. - 네뷸라는 기기 컨트롤러를 미리 실행해 두고, 상태 없는 HTTP 호출을 받는 구조를 사용합니다. - 세션 시작 비용과 세션 장애를 줄이고, 대규모 기기 운영에 유리한 구조를 만들었습니다. ### 사내 환경에 맞춘 확장 - 자체 인터페이스를 소유하므로 필요한 기능을 직접 추가할 수 있습니다. - 한글·이모지 입력을 지원하는 자체 IME를 구현했습니다. - 토스 앱 전용 신호 트리거를 추가할 수 있습니다. - 사내 앱센터와 연동해 pre-release 빌드를 기기에 바로 설치할 수 있습니다. - 보안 정책도 드라이버 규격 안에서 강제할 수 있습니다. - Android는 ADB·UiAutomation, iOS는 Swift·XCTest를 기반으로 구현하고, OpenAPI 스펙으로 Go·TypeScript 코드를 자동 생성했습니다. ## 실시간 화면 미러링 - 네뷸라는 정해진 테스트 스텝만 실행하는 도구가 아니라, 사용자가 화면을 보면서 동시에 조작할 수 있어야 했습니다. - 따라서 실시간 조작과 실시간 영상 스트리밍을 Android·iOS 모두에서 해결해야 했습니다. ### Android 미러링 - scrcpy는 Android 화면을 데스크톱 앱에 보여주는 데 적합하지만, 서버를 거쳐 여러 브라우저에 배포하는 구조에는 맞지 않았습니다. - 네뷸라는 scrcpy의 인코딩 방식을 참고하되 자체 미러링 경로를 구현했습니다. - `SurfaceControl`로 가상 디스플레이를 만들고 `MediaCodec`으로 H.264 영상을 인코딩합니다. - 인코딩된 영상은 브로드캐스터를 통해 여러 브라우저 시청자에게 전달됩니다. ### iOS 미러링 - iOS는 Android처럼 화면을 자유롭게 추출하기 어렵고 USB 사용 방식에도 제약이 있습니다. - 기존 QVH·Appium MJPEG 방식은 화면을 보면서 동시에 조작하는 요구를 충족하지 못했습니다. - QuickTime Player의 iOS 화면 캡처 방식과 유사한 경로를 USB 독점 없이 내재화했습니다. - 그 결과 조작과 미러링을 동시에 수행할 수 있게 됐습니다. - Android와 iOS 모두 실시간 H.264·브로드캐스팅 경로로 통일해 브라우저에서 여러 기기를 한 번에 볼 수 있습니다. ## 중앙화로 강화한 보안과 컴플라이언스 - 팀별 운영에서는 개발자가 테스트와 기기 관리, 보안 준수를 모두 책임져야 했습니다. - 네뷸라 팀은 사내 보안팀과 협력해 모바일 기기 팜 운영 기준을 정의했습니다. - 중앙 플랫폼에 보안 정책을 적용해 모든 기기에 동일한 기준을 일괄 반영할 수 있게 했습니다. - 사용자는 보안 요건이 적용된 환경에서 테스트에만 집중할 수 있습니다. ## 24시간 운영을 위한 안정성 ### 하드웨어 운영 - USB 연결 안정성, 케이블·허브 선택, 전원 공급, 서버실 설계를 직접 검증했습니다. - 물리적 장애를 완전히 제거할 수 없기 때문에 사람의 대응 체계와 이중화를 함께 준비하고 있습니다. ### 소프트웨어 운영 - 호스트별 컨트롤러와 미러링 프로세스를 오케스트레이션합니다. - 프로세스가 종료되더라도 자동으로 복구되도록 설계했습니다. - 서버·에이전트·컨트롤러·미러링 구성요소에 무중단 배포를 적용했습니다. - 기기 상태, 프로세스 상태, 서버 성능을 함께 관측하는 모니터링 체계를 구축하고 있습니다. - 여러 팀이 상시 사용하는 공용 인프라이므로 안정성을 핵심 기능으로 취급합니다. ## API 위에 만들어진 테스트 생태계 - 기기 15대에서 100대 이상, 수백 대 규모로 확장 중이며 24시간 운영됩니다. - 웹페이지에서는 미러링 화면을 보며 클릭으로 테스트 스텝을 만들 수 있습니다. - SDK로 E2E 테스트 코드를 작성하고, CLI로 터미널·CI/CD·AI 에이전트에서 기기를 제어할 수 있습니다. - 제품 로그가 기대대로 기록되는지 검수하는 시스템에도 활용됩니다. - AI 에이전트가 API를 호출해 테스트 스텝을 직접 판단하고 실행할 수도 있습니다. - 하나의 공개 API를 기반으로 여러 도구와 활용 사례가 자연스럽게 확장됐습니다. - 사용자 사례에 따르면 Appium 기반 테스트를 이전한 뒤 실행 속도가 크게 향상됐고, 수동 검수 시간이 30~40분에서 10분 이내로 줄었습니다. 네뷸라의 사례는 기기 수를 늘리는 것보다, 복잡한 하드웨어와 운영 문제를 단순한 API 뒤로 숨기는 것이 중요하다는 점을 보여줍니다. 비슷한 플랫폼을 구축한다면 초기부터 기기 점유 모델, 실시간 미러링, 보안 정책, 자동 복구와 무중단 배포를 함께 설계하고, 내부 사용자가 쉽게 확장할 수 있는 단일 API를 중심에 두는 것이 좋습니다.

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

Apache KafkaAndroidiOSopenapi+4

netflix·2026년 7월 14일·4분 읽기큐레이션 요약

대규모 서비스 토폴로지 구축: 아키텍처, 도전 과제, 그리고 얻은 교훈

넷플릭스는 장애 대응과 변경 영향 분석을 위해 실시간 서비스 의존성 지도를 구축했으며, 이를 위해 배치가 아닌 스트리밍 중심 아키텍처를 선택했다. 시스템은 eBPF 네트워크 흐름, IPC 메트릭, 분산 추적 데이터를 물리적으로 분리된 계층에 저장하고, 필요할 때 통합해 제공한다. 대규모 트래픽에서도 안정적으로 동작하기 위해 백프레셔와 분산 집계 파이프라인을 적용했으며, 약간의 지연을 허용하는 대신 데이터 손실과 시스템 장애를 방지했다. ## 실시간 서비스 토폴로지가 필요한 이유 - 기존의 시간별·일별 배치 방식은 데이터가 생성될 때 이미 오래된 상태가 된다. - 장애 대응 시 한 시간 전의 의존성 지도는 현재의 장애 원인과 영향 범위를 정확히 보여주기 어렵다. - 실시간 변경 검증과 장애 분석을 위해 지속적인 데이터 수집과 갱신이 필요하다. - 넷플릭스의 시스템은 일반적으로 수십 분 이내에 토폴로지 정보를 갱신하는 것을 목표로 한다. ## 스트리밍 중심 아키텍처 - 여러 리전의 Kafka 스트림에서 네트워크 흐름 데이터를 지속적으로 수집한다. - IPC 메트릭은 Server-Sent Events(SSE) 형태로 전달하고, 반응형 파이프라인에서 처리한다. - 배치 처리처럼 완전한 스냅샷을 기다리지 않고, 데이터가 도착하는 즉시 토폴로지를 갱신한다. - 대규모 트래픽을 처리하면서도 처리 지연이 누적되지 않도록 스트리밍 처리와 부하 제어를 함께 설계했다. ## 백프레셔를 통한 안정적인 부하 제어 - 단순한 무제한 큐는 트래픽이 급증할 때 메모리를 고갈시키고 인스턴스 장애를 일으킬 수 있다. - 버퍼가 가득 찼을 때 데이터를 버리는 방식은 연결 정보가 사라져 토폴로지가 불완전해진다. - 배치 방식은 데이터를 보존할 수 있지만, 장애가 끝난 뒤에야 결과를 확인하게 될 수 있다. - 백프레셔는 하위 단계의 처리 속도에 맞춰 상위 단계가 자동으로 속도를 줄이는 방식이다. - 그래프 데이터베이스가 느려지면 Stage 2가 Stage 1에 감속을 요청한다. - 감속 신호는 Kafka 소비자까지 전파된다. - Kafka에 데이터가 남아 있으므로 처리 능력이 회복된 뒤 이어서 처리할 수 있다. - GC 일시정지, 외부 저장소 지연, 트래픽 급증 상황에서도 시스템이 중단되거나 데이터를 대량으로 버리지 않고 점진적으로 느려진다. - 실시간성이 몇 초 또는 몇 분 늦어지는 대신, 시간 단위로 오래된 데이터나 누락된 토폴로지를 피할 수 있다. - 반응형 스트림은 전통적인 동기식 처리보다 이해하고 운영하기 어렵지만, 넷플릭스 규모에서는 안정성을 위한 필수 요소로 평가된다. ## 데이터 소스별 물리적 토폴로지 계층 넷플릭스는 서로 다른 특성을 가진 데이터를 하나의 저장소에 억지로 통합하지 않고, 세 개의 계층으로 분리했다. - **네트워크 계층** - eBPF 기반 네트워크 흐름 로그를 그래프 데이터베이스에 저장한다. - 서비스 간 연결을 폭넓게 포착하지만 애플리케이션 수준의 상세한 맥락은 부족하다. - **IPC 계층** - 애플리케이션 메트릭을 별도의 그래프 데이터베이스에 저장한다. - 엔드포인트 정보가 풍부하지만 계측된 서비스만 포함한다. - **트레이싱 계층** - 분산 추적 데이터를 Parquet 기반 컬럼형 저장소에 저장한다. - 실제 요청 경로를 보여주지만 샘플링으로 인해 전체 트래픽을 대표하지 않을 수 있다. - 각 계층을 물리적으로 분리하면 처리량, 쿼리 패턴, 데이터 발전 주기에 맞춰 독립적으로 최적화할 수 있다. - 쿼리 시에는 필요한 저장소에 병렬 질의한 뒤 결과를 병합해 통합된 서비스 뷰를 제공한다. ## 네트워크 중간 장비를 해결하는 분산 집계 파이프라인 네트워크 흐름 로그는 실제 서비스 의존성이 아니라 개별 네트워크 홉만 보여주는 문제가 있다. - 실제 경로가 `App A → 로드 밸런서 → App B`라면 흐름 로그에는 두 개의 별도 연결로 기록된다. - 이 데이터를 그대로 시각화하면 서비스 대신 로드 밸런서, NAT 게이트웨이, API 게이트웨이, 프록시 같은 인프라 컴포넌트가 중심에 나타난다. - 따라서 여러 홉을 분석해 논리적인 `App A → App B` 의존성으로 재구성해야 한다. - 이를 위해 네트워크 계층 수집은 세 단계의 분산 집계 파이프라인으로 구성된다. ### Stage 1: 초기 집계 - 네 개 리전의 Kafka에서 흐름 로그를 소비한다. - 잘못된 흐름 로그를 필터링한다. - 5분 단위 시간 창으로 데이터를 묶는다. - 각 시간 창마다 초기 집계 객체를 생성한다. - 일관성 해싱을 사용해 집계 대상을 분산한다. - 생성된 집계 결과를 SSE를 통해 Stage 2로 스트리밍한다. - 이 단계에서는 중간 장비가 포함된 네트워크 홉을 식별하지만, 최종적인 서비스 간 연결은 아직 확정하지 않는다. ## 대규모 분산 시스템에서 얻은 설계 교훈 - 실시간 처리는 단순히 빠르게 처리하는 문제가 아니라, 느려지는 상황에서도 시스템을 무너지지 않게 만드는 문제다. - 데이터 손실보다 일시적인 지연을 선택하는 것이 서비스 토폴로지와 장애 분석에는 더 적합할 수 있다. - 서로 다른 데이터의 특성이 뚜렷하다면 저장소와 처리 계층을 분리하고, 조회 시 통합하는 편이 확장성과 독립적인 최적화에 유리하다. - 로컬 환경에서 정상 동작하는 구현도 운영 환경에서는 Kafka 지연, 메모리 부족, 트래픽 편중, GC 비용 등으로 쉽게 한계에 도달할 수 있다. - 따라서 대규모 시스템은 초기 설계뿐 아니라 부하 상황에서의 관찰, 병목 측정, 단계별 최적화 방법론이 중요하다. 실용적으로는 스트리밍 파이프라인을 구축할 때 무제한 버퍼나 무조건적인 데이터 삭제보다 백프레셔를 우선 고려하는 것이 좋다. 또한 서로 다른 품질과 용도를 가진 데이터 소스를 하나의 모델로 통합하기보다, 각 소스에 맞는 저장 계층을 유지하고 조회 단계에서 결합하는 방식이 운영 유연성을 높인다.

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

Apache Kafkaebpfgraph-databasedistributed-tracing+4

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

초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기

LINE의 대규모 Kafka 환경에서는 TLS·인증·인가만으로는 브로커에 저장된 평문 데이터를 충분히 보호하기 어렵기 때문에, 프로듀서부터 컨슈머까지 메시지 페이로드를 암호화하는 종단 간 암호화를 도입했다. 레코드 단위 암호화와 DEK-KEK 구조를 결합해 Kafka 표준 확장성을 유지하면서 성능 오버헤드를 줄였고, 공유 KEK·평문 폴백·점진적 배포로 초당 최대 100만 건 규모의 토픽에 무중단 적용했다. ## Kafka 기본 보안 모델의 한계 - TLS/SSL은 프로듀서·컨슈머와 브로커 사이의 전송 구간만 보호한다. - SASL 인증은 클라이언트의 신원을 확인하고, ACL 인가는 토픽 접근 권한을 통제한다. - 그러나 브로커에 저장된 메시지 페이로드 자체는 평문일 수 있다. - 따라서 접근 권한이 우회되거나 브로커 내부 데이터가 노출되면 민감 정보가 보호되지 않는다. - 데이터 생성 시점부터 컨슈머의 복호화 시점까지 암호화 상태를 유지하는 심층 방어 전략이 필요하다. ## 레코드 단위 암호화 - 배치 단위 암호화는 압축 효율과 처리 성능이 좋지만, Kafka 클라이언트 내부 동작을 수정해야 한다. - Kafka의 인터셉터와 같은 공식 확장 포인트는 레코드 단위로 동작한다. - 레코드 단위 암호화는 압축 효율이 낮고 메시지 크기가 다소 증가하지만 다음 장점이 있다. - 표준 Kafka API를 활용할 수 있다. - Kafka 버전 업그레이드 시 호환성과 안정성이 높다. - 기존 프로듀서·컨슈머 클라이언트 코드를 직접 수정하지 않아도 된다. - 이러한 이유로 레코드 단위 암호화를 선택했다. ## DEK-KEK 이중 키 구조 - **DEK(Data Encryption Key)** - 메시지 페이로드 암호화에 사용하는 AES 대칭 키다. - AES-GCM을 사용해 빠른 암·복호화와 무결성 검증을 제공한다. - **KEK(Key Encryption Key)** - DEK를 암호화하는 ECC 기반 비대칭 키 쌍이다. - KMS가 키를 관리하며, 프로듀서는 공개 키를 사용하고 컨슈머는 인가된 비공개 키를 사용한다. - DEK 암호화에는 ECIES와 `secp521r1` 곡선을 사용한다. - 대용량 데이터는 빠른 대칭 키로 처리하고, 짧은 DEK에만 비대칭 암호화를 적용해 성능 부담을 줄인다. - 프로듀서는 페이로드를 한 번만 암호화하므로 컨슈머 수가 늘어도 메시지 크기를 크게 늘리지 않는다. - 공개 키를 이용한 암호화 권한과 비공개 키를 이용한 복호화 권한을 분리해 최소 권한 원칙을 적용한다. ## 암호화 메시지 구조 - **키** - Kafka 파티션을 결정하는 기존 메시지 키를 그대로 유지한다. - **헤더** - 컨슈머가 사용할 KEK ID와 KEK로 암호화된 DEK를 저장한다. - **바디** - DEK로 암호화된 실제 페이로드를 담는다. - 외부 DB나 캐시 없이 메시지 자체에 복호화 메타데이터를 포함해 시스템 의존성을 줄였다. - 컨슈머는 헤더의 KEK ID를 확인한 뒤 DEK를 복호화하고, 복호화한 DEK로 바디의 페이로드를 복호화한다. ## 프로듀서 암호화 처리 - Kafka 인터셉터가 전송 직전 DEK를 생성하고 KEK 공개 키로 암호화한다. - 암호화된 DEK는 메시지 헤더에 삽입한다. - 기존 시리얼라이저를 감싼 래퍼가 직렬화된 페이로드를 DEK로 암호화한다. - 인터셉터와 시리얼라이저가 같은 실행 스레드를 공유한다는 점을 활용해 DEK를 `ThreadLocal`로 전달한다. - 매 메시지마다 DEK를 새로 만들지 않고 일정 시간 캐싱해, 반복적인 비대칭 키 연산을 줄였다. ## 컨슈머 복호화 처리 - 컨슈머는 KMS에서 인가된 KEK 비공개 키를 조회한다. - 디시리얼라이저가 헤더에서 암호화된 DEK를 추출하고 비공개 키로 복호화한다. - 복호화된 DEK로 페이로드를 복호화한 후 기존 역직렬화를 수행한다. - 여러 프로듀서가 생성한 암호화 DEK와 복호화된 DEK의 쌍을 캐싱한다. - 동일한 암호화 DEK가 반복되면 비공개 키 연산을 생략해 컨슈머 성능을 높인다. ## KMS 기반 키 관리 - 토픽 오너가 KEK 키 쌍을 생성하고 KMS에 등록한다. - 프로듀서는 공개 키를, 승인된 컨슈머는 비공개 키를 KMS에서 조회한다. - 신규 컨슈머는 비공개 키 접근 권한을 요청하고 토픽 오너의 승인을 받아야 한다. - KEK의 생성·배포·접근 제어·교체를 KMS를 통해 일관되게 관리한다. ## 공유 KEK로 메시지 크기 제어 - 컨슈머마다 별도의 KEK를 사용하면 컨슈머 수에 비례해 헤더 메타데이터가 증가한다. - 메시지 크기 증가는 배치당 레코드 수 감소, 네트워크 대역폭 증가, CPU·메모리 사용량 증가로 이어진다. - 특히 초당 최대 100만 건의 토픽에서는 컨슈머 추가에 따른 헤더 증가가 큰 성능 문제가 된다. - 여러 컨슈머가 하나의 KEK를 공유하면 헤더에는 하나의 메타데이터만 포함되어 메시지 크기를 일정하게 유지할 수 있다. - 대신 키 격리 수준은 낮아지므로 다음 보완책을 함께 적용한다. - KMS 기반 비공개 키 접근 인가 - 주기적인 KEK 교체 - 토픽 오너 중심의 키 관리 ## 평문 폴백을 이용한 무중단 마이그레이션 - 암호화 도입 과정에서는 기존 평문 메시지와 새로운 암호화 메시지가 함께 존재할 수 있다. - 디시리얼라이저가 헤더의 암호화 메타데이터 유무를 확인해 처리 방식을 결정한다. - 헤더가 있으면 복호화 후 역직렬화한다. - 헤더가 없으면 기존 평문 역직렬화만 수행한다. - 안전한 전환 순서는 다음과 같다. - 평문과 암호화 메시지를 모두 처리할 수 있는 컨슈머를 먼저 배포한다. - 모든 컨슈머가 준비된 뒤 프로듀서 암호화를 활성화한다. - 모니터링을 통해 평문 메시지 비중이 0%가 되었는지 확인한다. - 프로듀서 암호화 비율도 한 번에 100%로 변경하지 않고 점진적으로 높여 성능 저하나 암·복호화 오류에 대응한다. ## 실용적인 결론 Kafka의 TLS·인증·인가를 대체하기보다, DEK-KEK 기반 페이로드 암호화를 추가 보안 계층으로 적용하는 것이 적절하다. 대규모 환경에서는 레코드 단위 암호화, DEK 캐싱, 컨슈머 측 DEK 캐싱, 공유 KEK, 평문 폴백과 점진적 배포를 함께 설계해야 보안성과 성능, 무중단 운영을 동시에 확보할 수 있다.

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

Apache Kafkaend-to-end-encryptionzero-downtime-migrationkey-management-service+3

datadog·2026년 7월 1일·4분 읽기큐레이션 요약

대규모 환경에서 데이터 완전성을 측정하는 방법

고객의 대시보드·알림·AI 에이전트가 올바르게 작동하려면 Datadog에 유입된 모든 텔레메트리 데이터가 완전하게 전달되어야 한다. Datadog은 수백 개의 분산 파이프라인과 고객별 경로를 실시간으로 추적하기 위해 파이프라인을 세그먼트로 나누고, 각 payload의 생성과 확인(acknowledgment)을 비교한다. 이 방식은 중복·순서 뒤바뀜·지연 데이터가 존재하는 환경에서도 세그먼트별 문제 위치와 전체 파이프라인의 완전성을 계산하도록 설계되었다. ## Datadog에서 데이터 완전성의 의미 - 완전한 데이터란 Datadog에 들어온 모든 payload가 고객에게 제공되는 상태다. - 대상 payload에는 다음과 같은 텔레메트리 데이터가 포함된다. - 메트릭 데이터 포인트 - 로그 - 트레이스 - 기타 수집 데이터 - 완전성은 전역 단위가 아니라 **고객별로** 판단해야 한다. - 고객마다 파티셔닝, 격리 전략, 트래픽 패턴이 다르다. - 따라서 동일한 리전에서도 데이터가 통과하는 경로가 매우 다양하다. - 시스템은 데이터가 누락되었는지뿐 아니라 다음도 즉시 설명해야 한다. - 어느 구간에서 문제가 발생했는가 - 어떤 서비스가 비정상인가 - 문제가 고객에게 영향을 주었는가 - 진단 결과는 운영자가 수 초 안에 대응하거나 자동화된 시스템이 조치하는 데 사용된다. ## 워터마크 방식의 한계 - 초기에는 Flink 같은 스트리밍 시스템의 워터마크 방식을 고려했다. - 데이터가 일정 시간 안에 도착한다고 가정하고 워터마크를 전진시킨다. - 특정 임계점을 넘으면 해당 시점까지 데이터가 완전하다고 판단한다. - 그러나 Datadog 환경에서는 고객이 임의로 지연된 데이터를 보낼 수 있다. - 또한 다음과 같은 특수 상황이 워터마크를 신뢰하기 어렵게 만든다. - 파이프라인 내부의 루프 - 트래픽 재생 - 예측하기 어려운 데이터 지연 - 따라서 데이터 도착 시점만으로 전체 파이프라인의 완전성을 판단하는 방식은 필요한 보장을 제공하지 못했다. ## 파이프라인을 세그먼트로 분할 - Datadog은 전체 파이프라인을 여러 개의 작은 세그먼트로 나누어 추적한다. - 예를 들어 다음과 같은 흐름이 있을 수 있다. - intake → Kafka → processing → Kafka → router - 각 서비스 내부와 서비스 간 연결을 별도의 세그먼트로 정의한다. - `intake-in → intake-out` - `intake-out → processing-in` - 각 세그먼트에서 다음을 독립적으로 측정한다. - 세그먼트에 들어온 payload 수 - 세그먼트에서 나간 payload 수 - 이 구조의 장점은 다음과 같다. - 누락이 발생한 위치를 구체적으로 찾을 수 있다. - 개별 세그먼트 결과를 합쳐 end-to-end 완전성을 계산할 수 있다. - 파이프라인에 분기 경로가 추가되거나 제거되어도 전체 시스템을 재정의할 필요가 적다. ## 생성 이벤트와 확인 이벤트로 payload 추적 - payload가 세그먼트에 들어오면 `create` 이벤트를 기록한다. - payload가 세그먼트를 빠져나오면 동일한 식별자에 대한 `acknowledgment` 이벤트를 기록한다. - 두 이벤트의 수를 비교해 세그먼트에서 데이터가 유실되었는지 판단한다. - 재시도와 중복 처리를 위해 모든 payload에 고유 식별자를 부여한다. ### 시간 버킷을 이용한 멱등성 - 분산 시스템에서는 이벤트가 중복되거나 순서가 뒤바뀐 채 도착할 수 있다. - 이를 처리하기 위해 완전성을 payload가 Datadog에 처음 들어온 시점의 **시간 버킷** 단위로 계산한다. - 고객 시스템의 시계가 아니라 Datadog이 관리하는 타임스탬프를 사용한다. - 각 버킷에서 payload의 세그먼트별 상태를 관리한다. - 생성됨 - 확인됨 - 생성 이벤트보다 확인 이벤트가 먼저 도착함 - 같은 버킷에서 동일한 식별자의 `create` 또는 `acknowledgment`가 반복되면 기존 상태를 확인하고 중복 이벤트를 무시한다. - 이 방식은 별도의 분산 조정 없이도 카운트를 멱등적으로 유지한다. ## 세그먼트 비율로 전체 완전성 계산 - 각 세그먼트의 완전성은 다음 비율로 정의된다. `세그먼트 완전성 = 세그먼트를 빠져나간 payload 수 ÷ 세그먼트에 들어온 payload 수` - 순차적으로 연결된 파이프라인에서는 각 세그먼트의 완전성 비율을 곱한다. - 예를 들어 두 세그먼트의 완전성이 각각 98%, 96%라면 전체 완전성은 다음과 같다. `98% × 96% = 94%` ### 병렬 분기 처리 - 병렬 분기를 단순히 하나의 파이프라인으로 취급하면 문제가 생긴다. - 예를 들어 APM 트레이스가 다음 두 서비스로 동시에 전달될 수 있다. - 오류율·요청 수를 계산하는 서비스 - 지연 시간 분포를 계산하는 서비스 - 한 분기가 늦게 처리되면 다른 분기에서 이미 사용 가능한 데이터까지 전체적으로 불완전한 것처럼 보일 수 있다. - Datadog은 병렬 분기를 **데이터 처리량에 비례한 가중 평균**으로 결합한다. - 각 분기의 기여도를 해당 분기가 처리하는 payload 양에 따라 산정한다. - 데이터가 많은 분기는 전체 결과에 더 큰 영향을 준다. - 예시에서는 한 분기가 98%와 96%의 두 세그먼트를 거쳐 94% 완전성을 보이고, 다른 분기는 100%를 처리한다. - 이후 각 분기의 처리량을 기준으로 가중치를 적용해 전체 파이프라인 완전성을 계산한다. ## 실용적인 결론 대규모 분산 수집 시스템에서는 전체 파이프라인을 한 번에 관찰하기보다, payload의 이동을 세그먼트별로 계측하는 편이 문제 위치와 고객 영향을 더 정확히 파악할 수 있다. 특히 고유 식별자, 시간 버킷, 멱등적인 상태 추적을 함께 사용하면 재시도와 지연 데이터가 많은 환경에서도 실시간 완전성 검증이 가능하다.

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

Apache Kafka옵저버빌리티애플리케이션 성능 모니터링분산 시스템+3

aws·2026년 6월 29일·4분 읽기큐레이션 요약

AWS 주간 요약: Amazon Connect Customer를 위한 에이전틱 CX 디자이너, EC2 AMI 워터마크, MySQL을 위한 오픈 거버넌스 등 (2026년 6월 29일) | Amazon Web Services

AWS는 기업이 긴 개발 백로그를 기다리지 않고 AI 기반 고객 경험과 운영 자동화를 구축할 수 있도록 노코드 도구와 AI 보조 기능을 확대하고 있다. 이번 주의 핵심은 Amazon Connect Customer의 Agentic CX Designer와 다양한 서비스의 AI 에이전트·자동화 기능이다. 동시에 EC2 이미지 추적, MySQL 오픈 거버넌스, 자격증 갱신 제도 등 인프라 관리와 개발자 생태계 변화도 소개됐다. ## Amazon Connect Customer의 Agentic CX Designer - 비즈니스 담당자가 직접 AI 기반 고객 경험을 설계하고 배포할 수 있는 노코드 캔버스다. - 음성 및 디지털 채널에서 다음 두 가지 AI 방식을 하나의 관리된 흐름으로 결합한다. - **Agentic AI**: 상황을 판단하고 여러 단계를 수행하는 자율형 AI - **Deterministic AI**: 정해진 규칙과 절차에 따라 일관되게 동작하는 AI - 설계부터 테스트, 시뮬레이션, 운영 배포까지의 과정을 지원해 구축 기간을 수개월에서 수주로 단축하는 것을 목표로 한다. - 프리뷰로 제공되는 **Live Sync**는 사용자가 말하거나 입력하는 내용을 바탕으로 웹·모바일 화면을 실시간으로 변경한다. - 통화 중 고객이 별도 화면을 찾지 않고도 양식을 작성할 수 있다. - 상담 내용에 맞춰 적절한 상품 페이지를 자동으로 표시할 수 있다. - 고객 경험 설계자의 역할이 개발자 중심에서 비즈니스 사용자까지 확대될 수 있다는 점이 핵심이다. ## AWS Lambda MicroVMs - 각 사용자나 작업에 VM 수준의 격리를 제공하는 새로운 서버리스 컴퓨팅 프리미티브다. - Firecracker를 기반으로 하며 빠른 시작과 재개 속도를 제공한다. - 실행 상태를 최대 8시간 동안 일시 중지했다가 다시 재개할 수 있다. - 멀티테넌트 애플리케이션에서 사용자 생성 코드나 AI가 생성한 코드를 실행할 때 유용하다. - 별도의 가상화 인프라를 관리하지 않으면서도 속도, 격리, 상태 보존을 함께 확보하는 것이 목적이다. ## EC2 AMI Watermarks와 이미지 통제 - 프라이빗 AMI에 사용자 정의 식별자를 삽입할 수 있다. - 워터마크는 AMI 복사, 리전 이동, 계정 공유를 거쳐 파생된 AMI에도 자동으로 전달된다. - **Allowed AMIs** 및 **Declarative Policies**와 함께 사용하면 승인된 이미지로만 EC2 인스턴스를 실행하도록 제한할 수 있다. - 모든 AWS 리전에서 추가 비용 없이 제공된다. - 이미지의 출처와 계보를 추적하거나, 조직의 승인 정책을 강제하는 데 활용할 수 있다. ## Outposts 셀프서비스 수명주기 관리 - AWS 콘솔, CLI, API에서 Outposts 관련 작업을 직접 수행할 수 있다. - 지원 범위에는 다음이 포함된다. - 구성 - 견적 산출 - 주문 - 구독 관리 - 갱신 - 폐기 및 해제 - 새로운 견적 도구는 실시간 비용을 수초 내 계산한다. - 주문 전에 계정 및 리전의 제약 조건을 표시해 구성 오류와 주문 지연을 줄인다. ## Kafka·OpenSearch 운영을 돕는 AI 에이전트 - **Amazon MSK AI Agent Skills** - Kiro, Claude Code, Cursor 같은 AI 코딩 도우미에 Amazon MSK 운영 지식을 제공한다. - 문제 해결, 용량 산정, 구성, 모니터링을 안내한다. - 외부 Kafka 클러스터를 MSK Express로 이전하는 작업도 지원한다. - 전문 운영 지식이 필요한 작업을 개발자가 단계적으로 수행할 수 있게 한다. - **Amazon OpenSearch Service AI-assisted migrations** - 셀프 매니지드 Solr, Elasticsearch, OpenSearch를 OpenSearch Serverless 또는 Managed Clusters로 이전하도록 돕는다. - Kiro와 Claude Code를 활용한 에이전트 기반 마이그레이션 경험을 제공한다. - Solr 환경에서는 실시간 트래픽을 캡처하고 재생하는 기능도 추가됐다. - 이전 전후 동작을 검증하고 마이그레이션 위험을 줄이는 데 초점을 둔다. ## GuardDuty의 AI 기반 보안 조사 - 프리뷰 기능으로, 보안 탐지 결과와 계정 활동을 자동 분석한다. - 최근 90일간의 관련 활동과 주변 맥락을 지식 그래프 및 위협 인텔리전스와 함께 검토한다. - 실제 위협과 정상 활동을 구분해 보안팀의 조사 부담을 줄인다. - 각 조사 결과에 다음 정보를 제공한다. - 위협 여부에 대한 처분 평가 - 신뢰도 점수 - MITRE ATT&CK 분류 - 실행 가능한 대응 권고 - 수동 분석에 걸리는 시간을 줄이고, 몇 분 안에 우선순위가 높은 대응 방향을 제시하는 것이 목표다. ## MySQL 오픈 거버넌스 - Oracle은 MySQL 프로젝트에 외부 조직이 공식적으로 참여할 수 있는 커뮤니티 거버넌스 모델을 발표했다. - 새로운 Steering Committee에 Oracle 외부 인사를 위한 4석을 마련한다. - 공개 GitHub 활동을 통해 개발 과정의 투명성과 커뮤니티 참여를 강화한다. - AWS도 위원회 의석을 보유하며, MySQL 업스트림에 수정 사항을 기여해 온 사례와 이번 변화에 대한 지지를 밝혔다. - 기업 사용자는 특정 공급업체에만 의존하지 않고 프로젝트 방향성과 개발 과정에 더 직접적으로 참여할 가능성이 커진다. ## 자격증 갱신과 개발자 지원 - 일부 AWS Associate 및 Professional 자격증은 전체 시험을 다시 치르지 않고도 갱신할 수 있다. - AWS Skill Builder의 지정 교육과 실습 랩을 완료하면 자격증을 1년 추가로 유지할 수 있다. - 현재 오픈 베타로 제공되며, 대상 자격증은 올해 후반 더 확대될 예정이다. - 2026년 All Builders Welcome Grant는 AWS re:Invent 참가 패스, 항공료, 숙박을 지원한다. - 신청 마감일은 7월 14일이며, AWS Summit과 Community Day를 통해 오프라인 네트워킹과 학습 기회도 제공된다. 실무적으로는 비즈니스 팀이 고객 경험을 직접 설계해야 한다면 Agentic CX Designer를 검토하고, 멀티테넌트 코드 실행에는 Lambda MicroVMs, AMI 거버넌스에는 Watermarks와 Allowed AMIs를 함께 검토할 만하다. 운영 측면에서는 MSK·OpenSearch 마이그레이션과 GuardDuty 조사 기능을 활용해 전문 인력 의존도와 수동 분석 시간을 줄일 수 있다.

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

Apache KafkaAWS서버리스aws-lambda+4

datadog·2026년 6월 23일·4분 읽기큐레이션 요약

AI 지원 리팩토링을 활용해 실시간 라우팅 시스템을 마이그레이션한 방법

Datadog은 Stream Router의 기존 FoundationDB 기반 KV 모델이 트랜잭션 크기와 데이터 증가에 따른 한계에 도달하자, 운영 중단 없이 PostgreSQL·DuckDB 기반의 관계형 구조로 전환했습니다. 이 과정에서 Claude와 Cursor를 활용했지만, AI가 자율적으로 코드를 작성한 것이 아니라 사람이 새 스키마와 기존 구현, 실패 테스트를 제공하고 테스트 결과로 검증하는 방식으로 사용했습니다. 핵심 결론은 AI가 대규모 마이그레이션을 크게 가속할 수 있지만, 데이터 모델 설계와 안전성 판단은 여전히 사람의 전문성이 필요하다는 것입니다. ## Stream Router의 역할과 기존 아키텍처 - Datadog은 하루 100조 개가 넘는 이벤트를 처리하며, 각 메트릭 데이터를 올바른 Kafka 클러스터·토픽·파티션으로 라우팅해야 합니다. - Stream Router는 Kafka 메시지를 직접 생산하거나 소비하지 않고, 다른 서비스가 사용할 라우팅 결정을 관리하는 제어 평면 서비스입니다. - 라우팅 정보는 다음과 같은 용도로 사용됩니다. - Producer가 데이터를 기록할 위치 결정 - Querier가 데이터를 읽을 위치 결정 - 시간에 따른 데이터 위치 이력 관리 - 기존 구조는 쓰기와 읽기를 분리한 Eventually Consistent 아키텍처였습니다. - 쓰기 경로: FoundationDB의 키-값 모델 사용 - 읽기 경로: 주기적으로 생성된 스냅샷을 RocksDB와 메모리 데이터베이스에 적재 - Producer와 Querier는 쓰기 경로에 직접 접근하지 않음 ## 설정 파일에서 중앙 제어 평면으로의 발전 - 2016년에는 몇 줄짜리 설정 파일을 모든 서비스에 배포해 라우팅을 관리했습니다. - 인프라와 고객 규모가 커지면서 설정 파일이 수천 줄로 증가했고, 수동 편집과 배포가 운영 부담이 되었습니다. - Stream Router 도입 후에는 다음과 같이 개선되었습니다. - 설정 파일 대신 gRPC API로 라우팅 변경 - 자동화된 오케스트레이션 - 점진적이고 자동화된 롤아웃 - 고가용성과 장애 내성을 고려한 읽기·쓰기 분리 ## KV 모델의 확장 한계 - 라우팅 데이터는 단순한 키-값 목록이 아니라 서로 연결된 관계형 데이터였습니다. - Route는 특정 Kafka Stream을 참조 - Route는 Sharding Strategy를 참조 - Rule은 Route를 참조하고 활성화 시점과 적용 방식을 결정 - 기존 KV 구조에서는 데이터베이스가 제공해야 할 관계 검증을 애플리케이션이 직접 수행해야 했습니다. - 수만 개의 레코드를 Pod 프로세스로 가져옴 - 애플리케이션 내부에서 관계형 데이터베이스처럼 조인과 일관성 검사를 수행 - 데이터와 변경 규모가 커지면서 FoundationDB 트랜잭션 크기 제한에 걸리는 작업이 발생했습니다. - FoundationDB를 PostgreSQL로 단순 교체하는 방안도 해결책이 되지 못했습니다. - 기존 KV 접근 패턴을 그대로 유지하면 수천 번의 순차적인 데이터베이스 왕복이 필요 - 일부 작업은 약 45분이 걸릴 것으로 예상 - 따라서 병목의 원인은 특정 데이터베이스가 아니라, KV에 맞춰진 데이터 모델과 애플리케이션 로직 자체였습니다. ## 관계형 스키마로 재설계 - 팀은 AI를 사용하기 전에 도메인 관계를 직접 분석하고 새 스키마를 설계했습니다. - 관계형 구조에서는 다음 관계를 외래 키로 명시합니다. - Streams와 Sharding Strategies → Routes - Routes → Rules - 기존 애플리케이션 코드가 수동으로 복원하던 관계를 데이터베이스가 직접 표현하고 검증할 수 있게 되었습니다. - 쓰기 경로에는 PostgreSQL을 선택했습니다. - 관계형 의미론 지원 - 트랜잭션 처리 - Datadog의 자체 관리형 PostgreSQL 플랫폼 활용 가능 - 읽기 경로에는 DuckDB를 선택했습니다. - 스냅샷 기반 읽기 계층에 적합한 임베디드 데이터베이스 - 배열 컬럼을 기본 지원 - PostgreSQL과 유사한 SQL 문법 - PostgreSQL과 DuckDB 사이에서 쿼리 로직을 공유할 수 있음 - SQLite도 검토했지만 배열 컬럼을 기본 지원하지 않아 적합하지 않았습니다. ## AI를 활용한 테스트 중심 리팩터링 - Claude와 Cursor는 코드를 독립적으로 생성하도록 맡기지 않았습니다. - 각 메서드마다 사람이 다음 정보를 제공했습니다. - 기존 구현 - 새 데이터베이스 스키마 - 현재 실패하는 테스트 - AI는 이를 바탕으로 첫 번째 구현을 만들었고, 테스트가 코드의 정확성을 검증했습니다. - 이 방식의 장점은 다음과 같습니다. - 전체 마이그레이션을 한 번에 생성하지 않고 메서드 단위로 분할 - 실패 테스트가 요구사항과 오류를 구체적으로 제시 - 생성 코드가 실제 동작과 데이터 관계를 만족하는지 즉시 확인 - 사람이 설계와 판단을 담당하고 AI는 반복적인 변환 작업을 가속 ## 안전한 마이그레이션을 가능하게 한 조건 - 마이그레이션이 성공할 수 있었던 기반은 AI보다 기존 시스템의 구조와 개발 프로세스였습니다. - 특히 저장소 계층이 `Controller`라는 내부 인터페이스 뒤에 모듈화되어 있었습니다. - 이러한 추상화 덕분에 저장 엔진과 구현을 교체하더라도 상위 계층의 변경 범위를 줄일 수 있었습니다. - 글의 제공된 부분은 안전성을 뒷받침한 요소를 설명하는 도중 끝나므로, 이후 테스트 전략이나 실제 전환 절차의 상세 내용은 포함되어 있지 않습니다. 결국 AI는 관계형 스키마를 설계하거나 운영 위험을 판단하는 도구라기보다, 명확한 설계와 테스트가 준비된 상태에서 반복적인 코드 변환을 빠르게 수행하는 도구로 활용하는 것이 적절합니다. 대규모 운영 시스템에서는 먼저 데이터 모델과 인터페이스를 사람이 설계하고, 작은 단위의 실패 테스트를 기준으로 AI 생성 코드를 검증하는 방식을 추천할 수 있습니다.

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

Apache Kafka데이터베이스 설계PostgreSQLgrpc+4

cloudflare·2026년 6월 12일·4분 읽기큐레이션 요약

보안 인사이트 확장: 글로벌 스캔 처리 역량을 10배 향상한 방법

Security Insights는 기존 주 1~2회에 그치던 보안 검사를 모든 계정에 더 자주 적용하기 위해 처리량을 초당 10건에서 100건으로 약 10배 높여야 했다. Cloudflare는 Kafka 소비 병렬화, 느린 작업 분리, Postgres 대량 삽입 최적화, 지역 간 네트워크 지연 분석을 통해 스캔 처리량을 10배 이상 향상시켰다. 그 결과 수백만 고객에게 보안 인사이트를 제공하고 전체 고객의 검사 주기를 두 배로 늘릴 수 있었다. ## 기존 보안 검사 구조와 확장 과제 - 스케줄러가 검사 시점이 된 계정과 Zone을 감지한다. - 검사 작업을 Apache Kafka 메시지로 발행하고, 여러 Go 기반 checker 마이크로서비스가 메시지를 나누어 처리한다. - 각 checker는 특정 자산이나 설정을 검사한 뒤 내부 API로 결과를 전송한다. - API는 결과를 Postgres 데이터베이스에 저장한다. - 기존 시스템은 다음 문제를 겪고 있었다. - 검사가 주 1~2회만 수행되어 위험이 최대 2주간 탐지되지 않을 수 있었다. - 많은 무료 요금제 계정에서 자동 검사가 선택 사항이라 검사 자체가 이뤄지지 않았다. - Kafka backlog 증가, API 타임아웃, 프로세스 충돌이 발생했다. - 모든 계정에 자동 검사를 적용하고 검사 빈도를 높이려면 평균 처리량을 초당 10건에서 100건으로 늘려야 했다. ## Kafka 파티션의 병목 - Kafka는 일반적인 큐와 달리 파티션 내 메시지를 순서대로 소비하고 처리한다. - 하나의 consumer group에서는 파티션당 활성 consumer를 하나만 둘 수 있다. - 따라서: - 처리 시간이 긴 메시지 하나가 뒤따르는 메시지의 처리를 막을 수 있다. - checker별 병렬 소비자 수는 Kafka 파티션 수에 제한된다. - 파티션을 추가하면 확장할 수 있지만, 여러 서비스가 공유하는 Kafka 브로커의 자원 사용량이 증가하므로 최후의 수단으로 남겨두었다. ## 배치 기반 병렬 처리 - 메시지를 하나씩 처리하던 checker를 배치 단위로 소비하도록 변경했다. - 배치 안의 각 메시지는 별도의 Go goroutine에서 동시에 처리했다. - 이 방식의 trade-off는 다음과 같다. - 배치 처리 중 프로세스가 중단되면 이미 처리한 작업을 다시 수행해야 할 수 있다. - 동시에 처리하는 작업이 늘어 메모리 사용량이 증가한다. - 검사 시스템에서는 재처리 비용과 메모리 증가가 감당 가능한 수준이었기 때문에 병렬 처리를 선택했다. ## 느린 작업으로 인한 Head-of-Line Blocking 제거 - 일부 계정이나 Zone은 자산 수가 많아 검사에 수초가 아니라 수분 또는 수시간이 걸릴 수 있었다. - 이런 느린 메시지가 일반 메시지 앞에 있으면 Kafka 소비가 멈춰 빠른 작업까지 지연됐다. - 해결책으로 checker와 consumer group을 두 개의 처리 경로로 분리했다. - **Fast lane**: 빠르게 처리할 수 있는 일반 메시지 담당 - **Slow lane**: 처리 시간이 긴 메시지 전담 - 메시지의 예상 처리 시간을 빠르게 판단하고, fast lane이 느린 메시지를 만나면 건너뛰도록 했다. - 그 결과 느린 작업은 전용 자원을 사용하고, 빠른 작업은 지연 없이 계속 처리할 수 있었다. ## Postgres 대량 저장 최적화 - 기존 API는 인사이트 하나마다 별도의 `INSERT ... ON CONFLICT DO UPDATE` 쿼리를 실행했다. - 한 요청에 최대 50만 개의 인사이트가 포함될 수 있어, 최악의 경우 50만 번의 데이터베이스 왕복과 쿼리 실행이 발생했다. - 처음에는 임시 테이블에 `COPY`하는 Postgres 표준 대량 삽입 방식을 시도했지만, Postgres 시스템 테이블의 bloat가 증가하는 문제가 나타났다. - 최종적으로 입력 규모에 따른 하이브리드 방식을 채택했다. - 작은 데이터셋: `UNNEST`를 사용해 빠르게 삽입 - 큰 데이터셋: `COPY`를 사용해 대량 삽입 - 이 방식은 대규모 데이터에는 수초 수준의 처리 시간을, 소규모 데이터에는 밀리초 수준의 빠른 처리를 제공했다. ## 지역 간 지연으로 발생한 API 타임아웃 - 확장 과정에서 다음 현상이 관찰됐다. - 클라이언트 타임아웃 증가 - checker 처리 시간의 20~90%가 단일 API 호출에 소요 - 대량 검사 시 초기 처리량은 높지만 시간이 지나며 감소 - 원인은 API와 데이터베이스 간 네트워크 지연이었다. - 주 데이터베이스는 미국 오리건주 포틀랜드에 위치했다. - API는 포틀랜드와 네덜란드 암스테르담에서 active-active로 운영됐다. - 포틀랜드 API 호출은 평균 10ms였지만, 암스테르담 인스턴스에서는 거의 3초가 걸렸다. - 암스테르담 API가 데이터베이스 연결을 오래 점유하면서 checker의 클라이언트 연결 풀이 고갈됐다. - 연결을 기다리는 요청이 타임아웃되고, 암스테르담 API에 연결된 Kafka 파티션만 지속적으로 지연됐다. - 결국 API의 단순한 지역 분산이 전체 Kafka 소비 처리량의 불균형과 lag를 유발할 수 있음을 확인했다. ## 실용적인 결론 대규모 이벤트 처리 시스템에서는 소비자 수를 늘리는 것만으로 충분하지 않다. Kafka의 파티션 제약을 고려한 병렬 처리, 느린 작업의 별도 격리, 대량 데이터베이스 작업의 배치화, 데이터베이스와 API 간 지역 지연 관리까지 함께 최적화해야 안정적인 처리량 확장이 가능하다. 특히 분산 배포 환경에서는 평균 latency뿐 아니라 연결 풀 점유 시간과 파티션별 처리 편차까지 함께 측정해야 한다.

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

Apache KafkaPostgreSQL분산 시스템API+4

netflix·2026년 6월 3일·4분 읽기큐레이션 요약

시계열 워크로드를 위한 동적 재파티셔닝

Netflix의 TimeSeries Abstraction은 Cassandra를 이용해 페타바이트 규모의 시계열 데이터를 밀리초 단위로 처리하지만, 시간이 지날수록 커지는 광범위한 파티션이 지연시간과 타임아웃을 유발했다. 기존의 테이블 단위 재파티셔닝은 전체 데이터가 비슷한 문제를 보일 때는 효과적이지만, 일부 ID만 비정상적으로 커지는 경우에는 적합하지 않았다. 이를 해결하기 위해 Netflix는 읽기 경로에서 넓은 파티션을 감지하고, 해당 TimeSeries ID 단위로 비동기 분할한 뒤 읽기 요청을 자동으로 재라우팅하는 동적 파티셔닝 시스템을 구축했다. ## Cassandra와 넓은 파티션의 문제 - Cassandra는 높은 처리량, 낮은 지연시간, 비용 효율성, 운영 성숙도를 이유로 Netflix의 시계열 저장소로 사용된다. - 그러나 이벤트가 시간에 따라 누적되면 하나의 파티션이 지나치게 커질 수 있다. - 일반적인 읽기 지연은 수 밀리초 수준이지만, 넓은 파티션에서는 특히 데이터 끝부분에서 지연시간이 수 초까지 증가한다. - 이로 인해 요청 타임아웃, 높은 CPU 사용률, 가비지 컬렉션 일시정지, 스레드 큐 대기 등이 발생할 수 있다. - 단순히 Cassandra 클러스터를 확장하는 방식은 비용 문제를 해결하지 못하므로 데이터 배치 자체를 개선해야 한다. ## 기존 TimeSeries 파티셔닝 전략 - 데이터를 일정한 시간 단위의 개별 Time Slice로 나누어 파티션 크기를 제한한다. - 시간 기준으로 데이터를 효율적으로 조회하거나 삭제할 수 있으며, 대량의 tombstone을 처리해야 하는 부담도 줄어든다. - 데이터셋 생성 시 사용자가 예상 트래픽과 이벤트 특성을 입력한다. - 프로비저닝 파이프라인은 해당 입력을 바탕으로 Monte Carlo 시뮬레이션을 수행해 인프라와 파티션 설정을 결정한다. ## 사전 설정 방식의 한계 - 초기 단계에서는 실제 운영 트래픽을 정확히 예측하기 어렵다. - 시간이 지나면서 트래픽 패턴, 클라이언트 동작, 제품 요구사항이 변할 수 있다. - 일부 TimeSeries ID만 다른 ID보다 훨씬 많은 이벤트를 받는 데이터 이상치가 존재할 수 있다. - Time Slice마다 다른 파티션 전략을 적용할 수 있지만, 수천 개 데이터셋의 설정을 사람이 직접 조정하는 것은 지속 가능하지 않다. - 따라서 파티션 상태를 관찰하고 자동으로 조정하는 시스템이 필요하다. ## Time Slice 단위 재파티셔닝 - Cassandra의 `nodetool tablehistograms` 등 introspection API를 활용해 파티션 크기 분포를 관찰한다. - 너무 작은 파티션이 많은 과도한 분할(over-partitioning)과 지나치게 큰 파티션을 모두 탐지할 수 있다. - 예를 들어 파티션 크기가 10KB보다 작으면 읽기 증폭과 스레드 큐잉이 커질 수 있다. - 백그라운드 워커가 애플리케이션에 연결된 Time Slice의 파티션 히스토그램을 감시한다. - 파티션 크기가 설정된 목표 밀도에 미달하면 조정 계수를 계산하고, 이후 생성될 Time Slice의 `time_bucket` 간격을 변경한다. - 목표 파티션 크기는 워크로드에 따라 보통 2MiB~10MiB로 설정된다. - 이 방식은 읽기 지연시간과 타임아웃을 줄이는 데 효과가 있었지만, 테이블 전체가 비슷한 문제를 보일 때만 적합하다. - 특정 ID 몇 개만 넓은 경우에는 전체 테이블의 파티션 전략을 바꾸는 것이 불필요하거나 효과적이지 않다. ## 일부 ID만 문제가 될 때의 대응 - **아무것도 하지 않기** - 애플리케이션의 전체 지표에 영향이 없다면 문제를 감수하는 것이 합리적일 수 있다. - **부분 결과 반환** - 요청이 설정된 지연시간 SLO를 넘으면 진행 중인 요청을 중단한다. - 그때까지 수집한 데이터만 반환해, 전체 결과보다 빠른 응답을 우선하는 클라이언트에 적합하다. - **문제 ID 차단** - 테스트나 스팸 데이터처럼 시스템을 불안정하게 만드는 ID를 차단한다. - 다만 정상적이고 중요한 ID가 큰 경우에는 데이터 전체를 처리해야 하므로 이 방법을 사용할 수 없다. ## ID별 동적 파티셔닝 - 동적 파티셔닝은 테이블 전체가 아니라 특정 TimeSeries ID의 넓은 파티션만 자동으로 분할한다. - 비동기 파이프라인은 다음 세 단계로 구성된다. - **감지:** 읽기 경로에서 특정 파티션의 읽기 바이트 수를 추적하고, 임계치를 넘으면 넓은 파티션으로 판단한다. - **계획 및 분할:** 적절한 크기가 되도록 파티션 분할 작업을 계획하고 비동기적으로 실행한다. - **읽기 제공:** 분할이 완료되면 기존 요청 경로를 투명하게 새 파티션으로 재라우팅한다. - 읽기 작업 중 파티션에서 읽은 바이트가 설정된 한도를 초과하면 Kafka로 감지 이벤트를 발행한다. - 이벤트에는 데이터가 속한 Time Slice 테이블, 문제가 된 `time_series_id`, 기존 `time_bucket`, `event_bucket`, 해당 파티션의 쓰기 종료 여부(`immutable`), 버전 등의 정보가 포함된다. - 이 구조를 통해 정상적인 ID에는 영향을 주지 않으면서, 데이터량이 큰 특정 ID만 선택적으로 재구성할 수 있다. ## 실용적인 결론 - 데이터 전체의 분포가 바뀌었다면 Time Slice 단위 자동 재파티셔닝을 적용하는 것이 효율적이다. - 일부 ID만 비대해지는 경우에는 ID별 동적 파티셔닝이 더 적합하다. - 읽기량, 파티션 크기, 지연시간 SLO를 지속적으로 관찰하고 자동화된 감지·분할·재라우팅 체계를 마련하는 것이 핵심이다.

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

Apache Kafka데이터베이스 설계time-series-databaseapache-cassandra+1

netflix·2026년 5월 4일·4분 읽기큐레이션 요약

넷플릭스에서 머신러닝의 민주화: 모델 수명 주기 그래프 구축

Netflix는 ML 자산이 개인화, 스튜디오, 결제, 광고 등 여러 영역으로 확장되면서 모델과 데이터가 각기 다른 시스템에 고립되는 문제를 겪었다. 이를 해결하기 위해 다양한 ML 메타데이터를 통합하는 Metadata Service(MDS)와 Model Lifecycle Graph를 구축했다. MDS는 모델·피처·파이프라인·실험·데이터셋 등의 관계를 연결해 자산의 발견, 계보 추적, 영향 분석, 재사용을 가능하게 하는 기반이다. ## ML 생태계의 확장과 사일로 문제 - Netflix의 ML 활용 영역은 개인화 중심에서 다음과 같이 확대됐다. - 콘텐츠 추천과 사용자 참여 최적화 - 스튜디오의 제작 전후 작업 - 사기 탐지, 결제 라우팅, 정기 결제 최적화 - 광고 타기팅과 실시간 의사결정 - 각 도메인은 서로 다른 기술 스택, 비즈니스 지표, 조직 구조를 사용한다. - 그 결과 모델이 블랙박스처럼 고립되고, 다른 팀이 기존 모델과 데이터를 발견하거나 재사용하기 어려워졌다. - 예를 들어 스튜디오에서 만든 콘텐츠 임베딩은 장면 전환과 콘텐츠 구조를 분석하지만, 광고의 문맥 매칭이나 개인화 추천에도 활용될 수 있다. - 그러나 모델 레지스트리, 파이프라인 오케스트레이터, 실험 플랫폼이 분리되어 있어 다음 질문에 답하기 어렵다. - 어떤 피처와 데이터 소스가 존재하는가? - 특정 모델은 어떤 파이프라인과 데이터로 생성되는가? - 해당 모델을 사용하는 A/B 테스트는 무엇인가? - 피처를 변경하면 어떤 모델이 영향을 받는가? - 각 자산의 담당자는 누구인가? ## 통합 UI보다 어려운 메타데이터 연결 - 문제의 본질은 화면을 하나로 합치는 것이 아니라, ML 라이프사이클의 서로 다른 구성 요소를 연결하는 것이다. - Netflix에는 다음과 같은 시스템이 각각 메타데이터를 생성한다. - 파이프라인 오케스트레이션: 실행 정보, 단계 의존성, 데이터 변환 - 모델 레지스트리: 모델 버전, 아티팩트, 오래된 모델 여부, 배포 이력 - 실험 플랫폼: A/B 테스트와 설정 - 피처 스토어: 피처 정의와 사용처 - AI Dataset 플랫폼: 데이터셋 생성, 관리, 검색, 로딩 - Identity 플랫폼: 사용자, 팀, 조직 정보 - 시스템마다 데이터 형식, 식별자, 개념 모델이 다르기 때문에 이질적인 메타데이터를 하나의 엔터티 모델로 변환하고 관계 그래프로 만드는 작업이 핵심 기술 과제가 됐다. ## Metadata Service와 Model Lifecycle Graph - MDS는 Netflix 전반의 ML 관련 엔터티를 색인하고 서로 연결하는 서비스다. - 모델, 피처, 파이프라인, 실험, 데이터셋 등의 메타데이터를 실시간으로 수집한다. - 다음과 같은 교차 도메인 질의를 지원하는 것을 목표로 한다. - 특정 모델을 실행 중인 실험은 무엇인가? - 특정 피처를 공유하는 모델은 무엇인가? - 모델에 사용된 데이터와 생성 파이프라인은 무엇인가? - MDS의 역할은 다음과 같다. - 여러 시스템에서 이벤트 수집 - 메타데이터에 조직·소유자 등 추가 맥락 결합 - ML 자산 간 관계 추론 및 구체화 - 연결된 그래프 형태로 탐색 가능하게 제공 - 궁극적인 목표는 모든 ML 자산을 팀과 도메인에 관계없이 발견하고, 이해하고, 재사용할 수 있도록 만드는 것이다. ## URI 기반 핵심 추상화 MDS는 시스템 간 일관된 연결을 위해 AI Platform URI를 사용한다. - **Component** - 고유한 URI로 주소 지정할 수 있는 모든 객체다. - 형식은 다음과 같다. ```text aip://<componentType>/<platformId>/<resourceId> ``` - 예: ```text aip://model/registry/ranking-v5 aip://user/identity/alice aip://pipeline/orchestrator/weekly-training ``` - **Entity** - 이름, 설명, 생성일, 소유자 등 추가 속성을 가진 ML 생태계의 구성 요소다. - 모델, 피처, 파이프라인 등이 이에 해당한다. - **Entity Type** - 동일한 데이터 구조와 속성·관계 제약을 공유하는 엔터티 집합이다. - **Domain** - 관련 엔터티 타입을 묶고 해당 ML 자산 범주의 추상 인터페이스를 정의한다. - 예를 들어 Models 도메인은 Model과 Model Instance를, Pipelines 도메인은 Schedule·Request·Execution을 정의한다. - **Provider** - 도메인을 실제로 구현하는 특정 소스 시스템이다. - 하나의 도메인에 여러 Provider를 연결할 수 있어, 모델 레지스트리가 교체되더라도 도메인 인터페이스를 변경하지 않고 확장할 수 있다. - URI는 서비스 간 ML 자산 참조를 단일 문자열로 통일하고, MDS가 이를 풍부한 메타데이터와 연결된 관계로 해석할 수 있게 한다. ## 이벤트에서 엔터티와 그래프로 - MDS는 Kafka와 AWS SNS/SQS를 통해 소스 시스템의 이벤트를 실시간으로 수집한다. - 소스 시스템은 식별자와 이벤트 유형 중심의 얇은 이벤트를 발행한다. - 예시는 다음과 같다. ```json { "event_type": "model_instance_created", "instance_id": "ranking-model-v5-20XX0101" } ``` - 생산 시스템은 복잡한 그래프 로직을 알 필요 없이 간단한 이벤트만 발행하고, MDS가 이를 엔터티로 변환하고 다른 시스템의 정보와 결합한다. - 이후 모델, 파이프라인, 피처, A/B 테스트 등의 관계를 추론해 질의 가능한 Model Lifecycle Graph로 materialize한다. - 이를 통해 모델 생성 이벤트와 실험 설정을 연결하는 것처럼, 서로 다른 시스템에 존재하는 관계도 하나의 그래프에서 탐색할 수 있다. MDS와 Model Lifecycle Graph는 단순한 모델 카탈로그가 아니라, ML 자산의 생성부터 배포·실험·재사용까지를 연결하는 메타데이터 인프라다. 여러 팀이 공통 URI와 엔터티 모델을 사용하도록 만들면 모델의 검색성, 의존성 파악, 변경 영향 분석, 조직 간 재사용이 크게 향상된다.

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

Apache Kafka머신러닝feature-storegraph-database+3

datadog·2026년 4월 7일원문

대규모 자율형 SRE 에이전트를 위한 실환경 평가 플랫폼 구축 방법 (새 탭에서 열림)

Datadog은 자율형 사고 조사 에이전트인 'Bits AI SRE'를 개발하면서, 특정 기능을 개선했을 때 다른 영역에서 예상치 못한 성능 저하(Regression)가 발생하는 문제를 겪었습니다. 이를 해결하기 위해 실제 운영 환경의 사고 맥락을 재현하고 에이전트의 추론 과정을 일관되게 측정할 수 있는 '재현 가능한 평가 플랫폼'을 자체 구축했습니다. 이 플랫폼은 프로덕션 환경의 복잡한 신호를 오프라인에서 재실행 가능한 환경으로 변환함으로써, 에이전트의 품질을 데이터에 기반해 지속적으로 개선할 수 있게 해줍니다. **기존 테스트 방식의 한계와 회귀 문제** * 단순한 단위 테스트나 개별 도구(Tool) 레벨의 테스트는 에이전트가 여러 도구를 체이닝(Chaining)하며 추론하는 복합적인 과정을 검증하는 데 한계가 있었습니다. * 특정 모니터에서 서비스 이름을 추출하는 등의 기능 개선이 실제로는 불필요한 노이즈를 유발하여, 오히려 에이전트의 전체적인 추론 품질을 떨어뜨리는 사례가 발생했습니다. * 실시간 운영 환경에서의 재실행(Live Replay)은 데이터의 만료, 환경의 가변성, 결과 집계의 어려움으로 인해 대규모 평가에 적합하지 않았습니다. **재현 가능한 평가를 위한 '레이블'의 구조** * 플랫폼의 핵심인 '레이블'은 근본 원인을 정의하는 '정답(Ground Truth)'과 사고 당시의 신호를 담은 '월드 스냅샷(World-snapshot)'으로 구성됩니다. * 월드 스냅샷은 원시 데이터를 그대로 저장하는 대신 에이전트가 당시 사용할 수 있었던 텔레메트리 쿼리(지표, 로그, 배포 이벤트 등) 정보를 보존하여 실제 제약 사항을 재현합니다. * Kubernetes 파드 실패부터 Kafka 지연까지, 실제 SRE가 직면하는 다양한 장애 모드와 기술 스택을 포괄하는 광범위한 레이블 세트를 구축하여 평가의 객관성을 확보했습니다. **레이블 생성 및 검증의 자동화 (Agentic Validation)** * 초기 수동 레이블링의 한계를 극복하기 위해, 사용자의 피드백과 Bits AI의 자체 조사 데이터를 결합하여 레이블을 자동 생성하는 파이프라인을 구축했습니다. * 레이블의 양이 급증함에 따라 발생하는 품질 저하 문제를 해결하기 위해, 에이전트가 직접 모호한 신호를 정리하고 관계를 도출하는 '에이전트 기반 검증' 단계를 도입했습니다. * 이 시스템을 통해 레이블 생성 속도를 10배 이상 향상시켰으며, 사람이 최종 검토하기 전 데이터의 정밀도를 높여 평가 신뢰도를 강화했습니다. **대규모 평가 오케스트레이션과 성능 추적** * 다양한 모델 버전과 설정 변경 사항이 기존의 Kafka나 Kubernetes 조사 품질에 영향을 주지 않는지 확인하기 위해 대규모 병렬 평가 시스템을 운영합니다. * 레이블 세트를 세부 카테고리별로 분할(Segmentation)하여 관리함으로써, 어떤 변경이 특정 시나리오에 어떤 영향을 주는지 정밀하게 분석할 수 있습니다. * 모든 평가 결과는 지표화되어 시간에 따른 성능 추이를 추적하고, 버전 간 비교를 용이하게 하여 새로운 기능 배포에 대한 확신을 제공합니다. 복잡한 추론을 수행하는 AI 에이전트 개발 시, 단순히 개별 도구의 정확도에 의존하기보다 실제 운영 데이터의 '쿼리 가능성'과 '맥락'을 보존하는 오프라인 평가 환경을 구축하는 것이 필수적입니다. 이는 사용자 피드백을 제품 개선의 선순환으로 연결하는 핵심 인프라가 됩니다.

Apache Kafka쿠버네티스datadogsre+3

netflix·2026년 4월 4일원문

비디오 검색을 위한 멀티모달 인텔리전스 구현 (새 탭에서 열림)

넷플릭스는 방대한 분량의 원본 영상 데이터에서 창작자가 원하는 특정 순간을 신속하게 찾아낼 수 있도록 여러 전문 AI 모델을 결합한 멀티모달(Multimodal) 검색 시스템을 구축했습니다. 이 시스템은 캐릭터, 환경, 대화 등 서로 다른 모델이 생성한 파편화된 신호들을 하나의 통합된 시간축으로 동기화하여 고차원의 문맥 이해와 실시간 검색을 동시에 실현합니다. 결과적으로 수십억 개의 데이터 포인트 속에서도 창작자의 의도에 부합하는 장면을 지연 시간 없이 정확하게 찾아내는 기술적 해결책을 제시합니다. **비디오 검색의 기술적 복잡성과 한계** * **타임라인 통합의 어려움:** 각 모델은 비디오를 서로 다른 간격으로 분석하여 텍스트 레이블이나 벡터 임베딩 등 상이한 형태의 메타데이터를 생성하므로, 이를 하나의 연대기적 지도로 정렬하는 데 막대한 계산 비용이 발생합니다. * **데이터 규모의 폭발:** 2,000시간 분량의 아카이브는 약 2억 1,600만 프레임에 달하며, 이를 여러 모델로 처리할 경우 수십억 개의 레이블과 벡터 데이터가 생성되어 전통적인 데이터베이스로는 처리가 불가능합니다. * **중복 제거와 하이브리드 스코어링:** 시각적으로 유사한 수천 개의 후보 중 최적의 클립을 제안하기 위해, 단순한 수학적 유사도를 넘어 상징적 텍스트 매칭과 의미론적 벡터 검색을 결합한 정교한 랭킹 엔진이 필요합니다. * **제로 프릭션(Zero-Friction) 검색:** 창작 흐름을 방해하지 않기 위해 수십억 개의 레코드를 탐색하면서도 초 단위 미만의 응답 속도를 유지해야 하는 물리적 제약이 존재합니다. **데이터 수집 및 융합 파이프라인 (Ingestion & Fusion)** * **트랜잭션 영속화 (Transactional Persistence):** 고가용성 파이프라인을 통해 수집된 모델의 원본 주석(Annotation)을 Apache Cassandra에 저장합니다. 이 단계에서는 데이터 무결성과 빠른 쓰기 처리량을 최우선으로 하여 모든 모델 출력을 안전하게 확보합니다. * **오프라인 데이터 융합 (Offline Data Fusion):** Apache Kafka를 통해 비동기적으로 실행되며, 파편화된 모델 데이터를 1초 단위의 '시간 버킷(Temporal Buckets)'으로 정규화합니다. 예를 들어 '조이'라는 캐릭터와 '주방'이라는 배경이 겹치는 구간을 하나의 통합 레코드로 병합하여 복합적인 쿼리가 가능하도록 만듭니다. * **실시간 검색 인덱싱:** 융합된 데이터를 Elasticsearch에 인덱싱합니다. 이때 자산 ID와 시간 버킷을 조합한 복합 키(Composite Key)를 사용하여 업서트(Upsert) 방식으로 데이터를 갱신함으로써 데이터 중복을 방지하고 단일 진실 공급원(Single Source of Truth)을 유지합니다. **효율적인 멀티모달 시스템을 위한 제언** 대규모 영상 자산을 관리하는 시스템에서는 원본 데이터를 실시간으로 검색하는 대신, 데이터를 수집-융합-인덱싱 단계로 분리(Decoupling)하여 처리하는 구조가 필수적입니다. 특히 서로 다른 AI 모델의 출력을 공통된 시간 단위(Time Bucketing)로 정규화하여 저장함으로써, 복잡한 다차원 검색 시 발생하는 계산 부하를 오프라인에서 미리 해결하고 사용자에게는 즉각적인 검색 경험을 제공할 수 있습니다.

Apache Kafka데이터베이스 설계elasticsearchapache-cassandra+4

line·2026년 3월 31일원문

LINE 서비스의 대규모 광고 데이터를 처리하기 위한 Spark on Kubernetes 적용기 (새 탭에서 열림)

LINE 광고 플랫폼(LINE Ads) 팀은 급격히 증가하는 광고 데이터와 연산량을 효율적으로 처리하기 위해 기존 Hadoop 기반의 YARN 환경을 Spark on Kubernetes로 전환했습니다. 기존 구조의 자원 경합 및 인프라 종속성 문제를 해결함으로써, 컴퓨팅과 스토리지를 분리하고 컨테이너 기반의 유연한 운영 환경을 구축하는 데 성공했습니다. 이를 통해 데이터 파이프라인의 확장성을 확보하고 최신 기술 스택을 자유롭게 활용할 수 있는 인프라 독립성을 달성했습니다. **기존 Spark on YARN의 구조적 한계** * **자원 경합 발생:** HDFS 스토리지와 컴퓨팅 자원이 단일 노드에 결합된 구조여서, 대규모 연산 시 HDFS 서비스와 Spark 작업 간의 리소스 간섭이 발생했습니다. * **확장의 비효율성:** 컴퓨팅 자원만 필요한 상황에서도 Hadoop 노드 전체를 증설해야 하므로 운영 비용과 스토리지 낭비가 초래되었습니다. * **환경 종속성:** Hadoop 클러스터의 설정에 묶여 있어 최신 Spark 버전이나 특정 라이브러리, JVM 환경을 자유롭게 변경하기 어려웠습니다. **Spark on Kubernetes의 작동 원리와 장점** * **파드 기반 실행:** Spark 드라이버와 익스큐터를 독립적인 Kubernetes 파드로 실행하며, Kubernetes가 클러스터 매니저 역할을 수행하여 리소스를 할당합니다. * **클러스터 모드 채택:** `spark-submit`을 통해 드라이버 파드를 먼저 생성하고, 드라이버가 직접 익스큐터 파드를 요청 및 관리하는 방식을 통해 운영 권한을 Kubernetes에 위임했습니다. * **완전한 컨테이너화:** 모든 의존성을 Docker 이미지에 포함하여 환경 재현성을 높였으며, CI/CD 파이프라인과의 연동이 쉬워졌습니다. **인프라 독립성 및 운영 효율성 확보** * **스토리지 자유도:** HDFS에 국한되지 않고 S3, GCS 등 다양한 클라우드 네이티브 스토리지를 자유롭게 선택할 수 있는 기반을 마련했습니다. * **오토 스케일링 용이:** 클러스터 오토스케일러를 통해 워크로드에 따라 유연하게 자원을 확장할 수 있으며, 온프레미스 제약에서 벗어났습니다. * **거버넌스 강화:** 네임스페이스와 리소스 쿼터(ResourceQuota)를 활용해 팀별로 자원을 격리하고, RBAC 기반의 세밀한 권한 제어가 가능해졌습니다. **통합 데이터 플랫폼을 위한 레이어 구성** * **배포 레이어:** GitHub Actions와 ArgoCD를 결합하여 코드 기반의 자동 배포 및 실시간 상태 모니터링, 손쉬운 롤백 체계를 구축했습니다. * **컴퓨팅 레이어:** Spark Operator를 도입해 Kubernetes 커스텀 리소스(CRD)로 앱을 관리하며, Apache YuniKorn을 통해 배치 잡 스케줄링을 최적화했습니다. * **관측성 및 로깅:** 파드의 로그를 OpenSearch에 실시간 적재하고, Prometheus 지표를 통해 Spark 애플리케이션의 성능을 정밀하게 모니터링합니다. 대규모 데이터 처리가 필요한 환경에서 인프라 유연성과 운영 자동화를 동시에 달성하고자 한다면 Spark on Kubernetes 도입을 적극 권장합니다. 특히 컴퓨팅과 스토리지를 분리하여 비용을 최적화하고, 다양한 워크로드를 하나의 클러스터에서 통합 운영하려는 조직에 매우 효과적인 솔루션이 될 것입니다.

Apache Kafka데이터베이스 설계머신러닝쿠버네티스+4

line·2026년 3월 20일원문

기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다 (새 탭에서 열림)

사양서나 소스 코드를 참조할 수 없는 블랙박스 상태의 레거시 시스템을 내재화하기 위해, Kafka 생태계를 활용한 자동화된 검증 파이프라인을 구축하여 시스템의 동일성을 증명했습니다. 데이터 발생부터 분석까지 이어지는 검증 루프를 통해 불일치 건수를 0으로 수렴시키는 과정을 거쳤으며, 결과적으로 대규모 커머스 데이터를 안전하고 정밀하게 신규 시스템으로 이관할 수 있었습니다. **통합 커머스 검색의 도메인 구조** * **상품과 카탈로그**: 판매자가 등록한 개별 '상품'들을 동일 모델별로 묶어 최적의 정보를 제공하는 상위 객체인 '카탈로그'로 관리하며, 이는 최저가 산출 및 객단가 지표 제공의 핵심이 됩니다. * **수신 파이프라인**: 대규모 상품 데이터를 내부 표준 형식으로 변환하고 정합성을 검사하여 상품 및 카탈로그 정보에 반영하는 거대 파이프라인으로, 서비스 전체에 막대한 영향력을 미칩니다. **무중단 검증 루프의 설계** * **검증 파이프라인 아키텍처**: 트리거(DB 변경/이벤트) → 실행 및 비교(양쪽 시스템에 동일 입력 주입) → 가공 및 적재(불일치 데이터 저장) → 분석 및 개선(오류 패턴 수정)으로 이어지는 유기적인 루프를 생성했습니다. * **입력과 출력의 정의**: 동일한 ID나 스냅숏을 입력값으로 설정하고, API 응답이나 DB 업데이트 결과를 출력값으로 명확히 정의함으로써 내부 로직이 복잡하더라도 통계적으로 동일함을 증명할 수 있는 환경을 만들었습니다. **조회 로직 검증과 블랙박스 분석** * **CDC와 Kafka 기반 비교**: DB의 바이너리 로그를 실시간 스트리밍하는 CDC(Change Data Capture)를 트리거로 사용하고, Kafka를 통해 검증 로직을 물리적으로 격리하여 서비스 성능에 영향을 주지 않으면서 기존/신규 API 응답을 1:1로 대조했습니다. * **재귀적 필드 비교 및 정렬**: 100개가 넘는 API 응답 필드를 `Map<String, Object>` 구조로 변환해 재귀적으로 탐색했으며, 리스트 내 순서 차이로 인한 노이즈를 제거하기 위해 문자열 정렬 후 2차 비교를 수행하는 유연한 로직을 도입했습니다. * **가시성 확보 및 최적화**: ksqlDB를 활용해 실시간으로 이상 징후를 Slack으로 알리고 OpenSearch로 상세 로그를 분석했으며, 처리율 제한(Rate Limit)을 적용해 동일 패턴의 중복 오류가 분석을 방해하지 않도록 제어했습니다. **상태 변화를 다루는 업데이트 로직 검증** * **실시간 시뮬레이션**: 카탈로그 통계 업데이트 시 CDC 이벤트가 발생하면 검증 모듈이 신규 로직으로 예상 결과값을 즉시 산출하고, 이를 기존 로직이 업데이트한 DB의 실제값과 대조하는 시뮬레이션 방식을 채택했습니다. * **비동기 지연 및 트리거 누락 해결**: 비동기 환경의 시차 문제는 'N회차 재시도 큐' 전략으로 해결하고, 특정 필드 변경 시에만 검증이 작동하도록 필터링하여 리소스를 최적화했습니다. 또한 ETL 배치 검증을 병행하여 실시간 스트림에서 놓칠 수 있는 트리거 누락 결함까지 포착했습니다. **성공적인 시스템 전환을 위한 제언** 복잡한 시스템의 내재화는 단순히 코드를 옮기는 것이 아니라 '기존과 동일하게 작동함'을 객관적으로 입증하는 과정입니다. 데이터 스트림 기반의 자동화된 검증 체계를 구축하면 블랙박스 로직의 베일을 하나씩 벗겨낼 수 있을 뿐만 아니라, 실시간 트래픽 환경에서의 성능 비교 지표까지 확보하여 안정성과 성능이라는 두 마리 토끼를 모두 잡을 수 있습니다.

Apache Kafka데이터베이스 설계PostgreSQLAPI 설계+4

daangn·2026년 2월 27일원문

2조 토큰을 카테고리 분류에 쓰면서 알게된 것들 (새 탭에서 열림)

당근 Taxonomy 팀은 방대한 중고거래 게시글과 서비스 데이터를 효율적으로 분류하기 위해 LLM 기반의 자동화 파이프라인인 'Taxonomy Management System'을 구축했습니다. 이 시스템은 Dataflow를 통한 고병렬 추론과 LLM as a Judge 방식의 평가 체계를 결합하여, 사람이 직접 수행하던 카테고리 관리와 라벨링 비용을 획기적으로 줄이면서도 1만 개 이상의 정교한 카테고리 체계를 안정적으로 운영하고 있습니다. 2조 토큰에 달하는 대규모 데이터를 처리하며 얻은 노하우를 통해, 단순 분류를 넘어 서비스 전반의 공통 데이터 언어를 구축하는 성과를 거두었습니다. **택소노미의 중요성과 자동화의 필요성** * 택소노미는 검색, 추천, 광고 등 서비스 전반에서 데이터를 통일된 방식으로 다루기 위한 계층적 카테고리 체계이자 공통 언어입니다. * 기존의 수동 분류 방식은 도메인 전문가의 리소스가 과도하게 소요되고, 사용자가 입력한 데이터만으로는 정밀한 분류(3-depth 이상)가 어렵다는 한계가 있었습니다. * LLM을 활용해 사용자가 입력하지 않은 세부 카테고리와 속성(브랜드, 색상, 재질 등)을 자동으로 추출하여 데이터의 표현력을 높였습니다. **Dataflow와 BigQuery 중심의 파이프라인 설계** * 초 단위의 응답 시간이 걸리는 LLM 추론을 대규모 배치 및 스트림으로 처리하기 위해 Apache Beam 기반의 Google Cloud Dataflow를 채택하여 병렬 처리 성능을 확보했습니다. * 추론 결과의 원천 데이터(Source of Truth)를 BigQuery에 적재하여 분석과 학습에 즉시 활용하고, 실시간 서비스가 필요한 경우 Kafka를 통해 피처 플랫폼으로 전달합니다. * 택소노미 정의, 파이프라인 설정, 모델 옵션(Gemini, GPT, Claude 등)을 YAML 파일로 관리하여 코드 수정 없이 유연하게 시스템을 운영할 수 있도록 설계했습니다. **LLM을 이용한 택소노미 생성 및 확장 전략** * 기존 1,400개 수준의 카테고리를 LLM 기반의 리서치와 실데이터 분석을 통해 6-depth, 10,000개 이상의 정교한 체계로 확장했습니다. * 신규 카테고리 후보가 발생하면 기존 데이터 할당 테스트와 회귀 평가(Regression)를 거쳐 품질이 검증된 경우에만 정식 택소노미로 편입시킵니다. * 다국어 지원 시 일관성을 유지하기 위해 DFS(깊이 우선 탐색) 방식으로 상위 카테고리의 번역 문맥을 하위 단계 LLM에게 전달하는 방식을 사용했습니다. **추론 전략 최적화와 품질 관리(LLM as a Judge)** * 단일 단계(Single Shot), 계층적(Hierarchical), 토너먼트(Two-stage) 방식 등 택소노미 규모에 맞는 다양한 추론 전략을 모듈화하여 교체 가능하게 구현했습니다. * 분류 결과의 정확도를 측정하기 위해 여러 모델이 투표하여 정답(Ground Truth)을 정하는 'LLM as a Judge' 방식을 도입했습니다. * 카테고리 정확도(Accuracy)뿐만 아니라 다중 라벨인 속성 데이터에 대해서는 정밀도(Precision)와 재현율(Recall) 지표를 상시 모니터링하여 프롬프트와 모델 변경의 효과를 즉각 검증합니다. **실용적인 결론 및 추천** 대규모 서비스에서 카테고리 분류를 자동화하려는 팀은 처음부터 완벽한 모델을 찾기보다, **다양한 LLM 전략을 실험할 수 있는 모듈형 파이프라인**과 **자동화된 평가 체계(LLM as a Judge)**를 먼저 구축하는 것이 중요합니다. 특히 데이터 소스가 다양해질 것에 대비해 이벤트 스트림과 배치 처리를 동시에 지원하는 인프라를 선택하고, 분류 결과가 실제 서비스 피처로 흐를 수 있는 파이프라인 구조를 설계할 것을 권장합니다.

Apache Kafka대규모 언어 모델프롬프트 엔지니어링bigquery+4