마이크로서비스

25 개의 포스트

toss원문

레거시 결제 원장을 확장 가능한 시스템으로 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 결제 원장의 구조적 한계와 도메인 간 강한 결합을 해결하기 위해 MySQL 기반의 신규 원장 시스템을 구축했습니다. 데이터 불변성을 보장하는 INSERT-only 원칙과 이벤트 기반 아키텍처를 도입하여 복합 결제 지원 등 비즈니스 확장성을 확보했습니다. 이 과정에서 발생한 데이터 불일치와 타임아웃 문제를 해결하며 시스템의 자가 회복 능력을 강화하고 안정적인 운영 환경을 마련했습니다. ### 레거시 원장 시스템의 한계와 과제 - **데이터 구조의 불일치:** 결제수단별로 테이블 구조가 다르고, 동일한 성격의 데이터가 서로 다른 테이블에 저장되어 유지보수와 온보딩에 큰 비용이 발생했습니다. - **도메인 간 강한 결합:** 결제, 정산, 회계 등 여러 서비스가 하나의 원장 테이블과 컬럼을 공유하여, 작은 기능 수정 시에도 전사적인 영향도 분석이 필요했습니다. - **구조적 확장성 부족:** 결제와 결제수단이 1:1 관계로 묶여 있어, 더치페이나 복합 결제(카드+포인트)와 같은 현대적인 결제 시나리오를 지원할 수 없었습니다. ### 신규 원장 설계의 3가지 전략 - **데이터 불변성과 일관성:** 모든 승인 내역을 공통 테이블(`approve`)에 저장하고, 수정 대신 INSERT-only 방식을 채택하여 데이터의 정합성을 높이고 데드락을 방지했습니다. - **이벤트 기반의 도메인 분리:** 각 도메인이 직접 DB를 조회하는 대신 Kafka 이벤트를 구독하여 데이터를 처리하게 함으로써 도메인 간 의존성을 제거했습니다. - **결제와 승인 개념의 분리:** '결제'는 주문의 상태를, '승인'은 실제 결제수단의 실행을 의미하도록 분리하여 하나의 결제에 여러 승인 수단이 연결될 수 있는 유연한 구조를 만들었습니다. ### 무중단 마이그레이션 및 정합성 검증 - **비동기 점진적 적재:** 실서비스 장애를 방지하기 위해 기존 원장에 먼저 저장한 후, 신규 원장에는 별도의 ThreadPool을 통한 비동기 방식으로 데이터를 적재했습니다. - **검증 배치 운영:** 비동기 적재 중 발생할 수 있는 누락을 방지하기 위해, 매 5분마다 Read-Only DB를 기반으로 기존 원장과 신규 원장의 데이터를 비교하고 보정하는 배치를 실행했습니다. - **고성능 이관 작업:** 수억 건의 데이터 이관을 위해 Bulk Insert를 도입하고, 네트워크 지연 최소화를 위해 마이그레이션 서버를 DB와 동일한 가용 영역(AZ)에 배치했습니다. ### 운영 중 장애 대응과 시스템 고도화 - **쿼리 최적화:** 옵티마이저의 판단 오류로 발생한 풀 스캔(Full Scan) 문제를 인덱스 힌트(Index Hint) 추가와 롤백 시스템을 통해 빠르게 해결했습니다. - **타임아웃 및 정합성 관리:** MSA 구조에서 서버 간 타임아웃 설정을 일치시키고, 외부 원천사와의 상태 불일치를 해결하기 위한 망취소(Network Cancellation) 로직을 강화했습니다. - **이벤트 처리의 신뢰성:** 아웃박스(Outbox) 패턴과 로그 기반 복구를 통해 이벤트 누락을 방지하고, 헤더에 멱등키를 포함해 중복 이벤트 처리 문제를 해결했습니다. 신규 시스템으로의 전환은 단순한 DB 교체가 아니라 시스템의 지속 가능성을 확보하는 과정입니다. 초기 설계의 완벽함보다 중요한 것은 운영 중 발생하는 예외 상황에 시스템이 스스로 대응하고 회복할 수 있는 '자가 회복 구조'를 갖추는 것이며, 이를 위해 데이터 보정 배치와 로깅 시스템 같은 안전장치를 반드시 고려해야 합니다.

netflix원문

넷플릭스가 실시간 분산 그래프를 구축한 방법과 이유: 1부 — 인터넷 규모의 데이터 스트림 수집 및 처리 (새 탭에서 열림)

넷플릭스는 비디오 스트리밍을 넘어 광고, 라이브 이벤트, 모바일 게임으로 비즈니스를 확장하면서 발생하는 데이터 파편화 문제를 해결하기 위해 '실시간 분산 그래프(RDG)'를 구축했습니다. 기존 마이크로서비스 아키텍처에서 발생하는 데이터 고립을 극복하고, 다양한 서비스 접점에서 발생하는 사용자 활동을 실시간으로 연결하여 개인화된 경험을 제공하는 것이 핵심 목표입니다. 이를 통해 복잡한 데이터 조인 없이도 수억 개의 노드와 엣지 사이의 관계를 즉각적으로 파악할 수 있는 기술적 기반을 마련했습니다. **데이터 파편화와 비즈니스 환경의 변화** * 스트리밍, 게임, 라이브 스포츠 등 서비스 영역이 넓어지면서 사용자가 여러 기기와 도메인에서 수행하는 활동을 하나의 맥락으로 통합해야 할 필요성이 커짐. * 넷플릭스의 강점인 마이크로서비스 아키텍처(MSA)는 서비스 독립성에는 유리하지만, 데이터가 각 서비스에 고립(Silo)되어 있어 통합적인 데이터 과학 및 엔지니어링 작업에 큰 비용이 발생함. * 기존 데이터 웨어하우스 방식은 데이터가 서로 다른 테이블에 저장되고 처리 주기가 제각각이라, 실시간으로 연관 관계를 분석하는 데 한계가 있음. **그래프 모델 도입의 기술적 이점** * **관계 중심 쿼리:** 테이블 기반 모델에서 필요한 비용 중심적인 조인(Join)이나 수동적인 비정규화 없이도 노드와 엣지 사이를 빠르게 탐색(Hop)할 수 있음. * **유연한 확장성:** 새로운 엔티티나 관계 유형이 추가될 때 대대적인 스키마 변경이나 아키텍처 재설계 없이도 신속하게 데이터 모델을 확장할 수 있음. * **패턴 및 이상 탐지:** 숨겨진 관계, 순환(Cycle) 구조, 그룹화 등을 식별하는 작업을 기존의 포인트 조회 방식보다 훨씬 효율적으로 수행함. **실시간 데이터 수집 및 처리 파이프라인 (RDG 레이어 1)** * 전체 시스템은 수집 및 처리, 저장, 서빙의 3개 레이어로 구성되며, 첫 번째 단계인 수집 레이어는 이기종 업스트림 소스로부터 이벤트를 받아 그래프 데이터를 생성함. * DB의 변경 사항을 추적하는 CDC(Change Data Capture)와 애플리케이션의 실시간 로그 이벤트를 주요 소스로 활용하여 데이터 소외 현상을 방지함. * 수집된 원시 데이터는 스트리밍 처리 엔진을 통해 그래프 스키마에 맞는 노드와 엣지 형태로 변환되며, 대규모 트래픽 환경에서도 실시간성을 유지하도록 설계됨. 복잡하게 얽힌 현대의 서비스 환경에서 데이터 간의 관계를 실시간으로 규명하는 것은 사용자 경험 고도화의 핵심입니다. 넷플릭스의 RDG 사례처럼 파편화된 마이크로서비스의 데이터를 그래프 형태로 통합하는 접근 방식은, 실시간 통찰력이 필요한 대규모 분산 시스템 설계 시 강력한 해결책이 될 수 있습니다.

line원문

Pushsphere: LINE 메신저의 빠르고 신뢰할 수 있는 대량 푸시 알림 비법 (새 탭에서 열림)

LINE은 대규모 푸시 알림 발송 과정에서 발생하는 신뢰성 문제를 해결하기 위해 고성능 게이트웨이 서버인 'Pushsphere'를 개발했습니다. Pushsphere는 복잡한 재시도 로직, 쿼터 관리, 엔드포인트 모니터링을 추적 및 자동화하여 시스템의 복잡성을 낮추고 가용성을 극대화했습니다. 이를 통해 LINE은 대규모 트래픽 상황에서도 안정적인 메시지 전달력을 확보하고 운영 부담을 대폭 줄이는 성과를 거두었습니다. **대규모 푸시 알림 시스템의 도전 과제** * **외부 플랫폼의 불안정성:** APNs나 FCM 같은 외부 푸시 플랫폼은 대규모 환경에서 응답 지연, 갑작스러운 연결 끊김, 특정 인스턴스의 오작동 등 예측 불가능한 문제를 자주 노출합니다. * **단순 재시도의 한계:** 장애 발생 시 단순히 재시도를 반복하면 시스템에 부하를 주는 '재시도 폭풍'이 발생하거나, 서비스 제공자의 쿼터(Quota) 제한(429 Too Many Requests)에 걸려 전체 메시지 전달이 차단될 위험이 있습니다. * **관리 복잡도:** 수백 개 이상의 엔드포인트를 수동으로 관리하며 상태를 추적하고 최적의 서버로 라우팅하는 작업은 매우 높은 운영 비용을 발생시킵니다. **Pushsphere의 핵심 아키텍처 및 구현** * **통합 인터페이스 제공:** iOS와 Android 등 각 플랫폼별로 상이한 API 규격을 단일 인터페이스로 추상화하여, 내부 메시징 서버가 복잡한 플랫폼별 로직 없이도 간편하게 알림을 발송할 수 있도록 설계되었습니다. * **재시도 인식 부하 분산(Retry-aware Load Balancer):** 라운드 로빈 방식을 기반으로 하되, 재시도 시에는 이전에 시도했던 엔드포인트를 자동으로 건너뜁니다. 이를 통해 결함이 있는 특정 노드에서 실패가 반복되는 현상을 원천 차단합니다. * **쿼터 인식 재시도 로직:** 남은 전송 쿼터를 실시간으로 모니터링하여, 한도에 가까워지면 무리한 재시도를 중단함으로써 시스템의 전체적인 안정성을 유지하고 서비스 차단을 방지합니다. **서킷 브레이커를 통한 엔드포인트 회복 탄력성** * **엔드포인트별 독립 감시:** 모든 개별 엔드포인트에 서킷 브레이커를 적용하여 발송 성공/실패 여부를 실시간으로 보고받습니다. * **자동 장애 노드 격리:** 특정 엔드포인트에서 오류가 임계치를 넘으면 서킷이 열리고, 해당 노드는 즉시 활성 풀에서 제거되어 트래픽 유입이 차단됩니다. * **DNS 기반 자동 교체:** 제거된 노드의 빈자리는 DNS 리프레시를 통해 확보된 새로운 후보군 노드로 자동 교체되어, 전체적인 트래픽 처리 용량을 일정하게 유지합니다. **성능 개선 및 운영 결과** * **고성능 비차단 통신:** Armeria 마이크로서비스 프레임워크와 Netty를 기반으로 구축되어, 대량의 요청을 논블로킹(Non-blocking) 방식으로 신속하게 처리합니다. * **운영 효율성 극대화:** 시스템 도입 후 온콜(On-call) 알림 횟수가 연간 30건 이상에서 4건 수준으로 급감했습니다. 더 엄격한 모니터링 기준을 적용했음에도 불구하고 자동화된 장애 대응 덕분에 운영자의 개입이 거의 필요 없는 환경을 구축했습니다. 이 글은 대규모 트래픽을 처리하는 시스템일수록 개별 노드의 상태를 세밀하게 관리하고, 외부 의존성(Third-party API)의 불안정성을 시스템 계층에서 어떻게 추상화하여 방어해야 하는지에 대한 실무적인 통찰을 제공합니다. 특히 Armeria와 Netty를 활용한 고성능 게이트웨이 설계는 유사한 과제를 안고 있는 백엔드 엔지니어들에게 좋은 참조 사례가 될 것입니다.

netflix원문

스케일링 뮤즈: 넷플릭스가 조단위 데이터에서 데이터 기반 창의적 인사이트를 제공하는 방법 | 넷플릭스 기술 블로그 | 넷플릭스 기술 블로그 (새 탭에서 열림)

넷플릭스의 내부 데이터 분석 플랫폼인 'Muse'는 수조 건 규모의 데이터를 분석하여 홍보용 미디어(아트웍, 영상 클립)의 효과를 측정하고 창작 전략을 지원합니다. 급증하는 데이터 규모와 복잡한 다대다(Many-to-Many) 필터링 요구사항을 해결하기 위해, 넷플릭스는 HyperLogLog(HLL) 스케치와 인메모리 기술인 Hollow를 도입하여 데이터 서빙 레이어를 혁신했습니다. 이를 통해 데이터 정확도를 유지하면서도 수조 행의 데이터를 실시간에 가깝게 처리할 수 있는 고성능 OLAP 환경을 구축했습니다. ### 효율적인 고유 사용자 집계를 위한 HLL 스케치 도입 * **근사치 계산을 통한 성능 최적화:** 고유 사용자 수(Distinct Count)를 계산할 때 발생하는 막대한 리소스 소모를 줄이기 위해 Apache Datasketches의 HLL 기술을 도입했습니다. 약 0.8%~2%의 미세한 오차를 허용하는 대신 집계 속도를 비약적으로 높였습니다. * **단계별 스케치 생성:** Druid 데이터 수집 단계에서 '롤업(Rollup)' 기능을 사용해 데이터를 사전 요약하고, Spark ETL 과정에서는 매일 생성되는 HLL 스케치를 기존 데이터와 병합(hll_union)하여 전체 기간의 통계를 관리합니다. * **데이터 규모 축소:** 수개월에서 수년 치의 데이터를 전수 비교하는 대신, 미리 생성된 스케치만 결합하면 되므로 데이터 처리량과 저장 공간을 획기적으로 절감했습니다. ### Hollow를 활용한 인메모리 사전 집계 및 서빙 * **초저지연 조회 구현:** 모든 쿼리를 Druid에서 처리하는 대신, 자주 사용되는 '전체 기간(All-time)' 집계 데이터는 넷플릭스의 오픈소스 기술인 'Hollow'를 통해 인메모리 방식으로 서빙합니다. * **Spark와 마이크로서비스의 연계:** Spark 작업에서 미리 계산된 HLL 스케치 집계 데이터를 Hollow 데이터셋으로 발행하면, Spring Boot 기반의 마이크로서비스가 이를 메모리에 로드하여 밀리초(ms) 단위의 응답 속도를 제공합니다. * **조인(Join) 병목 해결:** 복잡한 시청자 성향(Audience Affinity) 필터링과 같은 다대다 관계 연산을 메모리 내에서 처리함으로써 기존 아키텍처의 한계를 극복했습니다. ### 데이터 검증 및 아키텍처 현대화 * **신뢰성 보장:** 아키텍처 변경 전후의 데이터 정합성을 확인하기 위해 내부 디버깅 도구를 활용하여 사전/사후 데이터를 정밀하게 비교 검증했습니다. * **기술 스택 고도화:** React 프런트엔드와 GraphQL 레이어, 그리고 gRPC 기반의 Spring Boot 마이크로서비스 구조를 통해 확장성 있는 시스템을 구축했습니다. * **분석 역량 강화:** 이를 통해 단순한 대시보드를 넘어 이상치 감지(Outlier Detection), 미디어 간 성과 비교, 고급 필터링 등 사용자들의 고도화된 분석 요구를 수용할 수 있게 되었습니다. 대규모 OLAP 시스템을 설계할 때 모든 데이터를 실시간으로 전수 계산하기보다는, HLL과 같은 확률적 자료구조와 Hollow 기반의 인메모리 캐싱을 적절히 조합하는 것이 성능 최적화의 핵심입니다. 특히 수조 건 규모의 데이터에서는 완벽한 정확도와 성능 사이의 트레이드오프를 전략적으로 선택하는 것이 시스템의 유연성을 결정짓습니다.

airbnb원문

Viaduct, 5년 후: (새 탭에서 열림)

에어비앤비는 자사의 데이터 중심 서비스 메시인 'Viaduct'의 5년간의 운영 성과를 공유하며, 이를 오픈소스로 공개하고 차세대 아키텍처인 'Viaduct Modern'으로의 전환을 발표했습니다. Viaduct는 중앙 집중식 스키마와 서버리스 비즈니스 로직 호스팅, 재진입(Re-entrancy) 구조를 통해 트래픽이 8배 성장하는 과정에서도 운영 효율성과 비용 선형성을 유지해 왔습니다. 이번 개편은 파편화되었던 API를 단순화하고 실행 엔진과 비즈니스 로직 사이의 추상화 경계를 강화하여, 거대해진 코드베이스의 유지보수성과 개발 생산성을 높이는 데 중점을 두었습니다. ### Viaduct의 핵심 설계 원칙 * **중앙 스키마(Central Schema):** 전사의 모든 도메인을 하나의 통합된 그래프로 연결합니다. 개발은 팀별로 분산되어 진행되지만, 사용자는 단일한 접점을 통해 모든 데이터와 기능에 접근할 수 있어 내부 요청의 75%가 Viaduct 내에서 처리됩니다. * **호스팅된 비즈니스 로직(Hosted Business Logic):** GraphQL 서버를 단순한 게이트웨이로 사용하는 대신, 비즈니스 로직을 직접 실행하는 서버리스 플랫폼으로 운영합니다. 이를 통해 개별 마이크로서비스 운영 부담을 줄이고 개발자가 로직에만 집중할 수 있는 환경을 제공합니다. * **재진입성(Re-entrancy):** Viaduct에 호스팅된 로직이 다른 로직을 호출할 때 GraphQL 프래그먼트와 쿼리를 사용하도록 설계되었습니다. 이는 대규모 코드베이스에서 직접적인 코드 의존성을 방지하고 모듈성을 유지하는 핵심 장치입니다. ### Viaduct Modern의 API 단순화 * **Tenant API의 통합:** 과거에는 기능 구현 방식이 복잡하고 파편화되어 있었으나, 이를 '노드 리졸버(Node Resolver)'와 '필드 리졸버(Field Resolver)' 두 가지 메커니즘으로 대폭 통합하여 개발자 경험을 개선했습니다. * **결정 트리 제거:** 구현 방식을 고민해야 했던 복잡한 결정 과정을 없애고, 스키마 자체의 정의에 따라 리졸버 유형이 자연스럽게 결정되도록 설계하여 학습 곡선을 낮췄습니다. ### 테넌트 모듈성과 협업 구조 * **테넌트 모듈(Tenant Module):** 스키마와 구현 코드를 팀별 소유권 단위로 묶어 관리합니다. 팀 간의 직접적인 코드 참조는 지양하고 GraphQL 인터페이스를 통해서만 소통합니다. * **선언적 데이터 의존성:** 예를 들어 '메시징 팀'이 '사용자 팀'의 타입에 새로운 필드를 추가할 때, `@Resolver` 어노테이션에 필요한 데이터 필드(예: 성, 이름)를 선언하기만 하면 됩니다. * **코드 의존성 해소:** 데이터 수요를 선언적으로 명시함으로써, 다른 팀의 내부 로직이나 데이터 소스가 무엇인지 알 필요 없이 독립적으로 기능을 확장할 수 있습니다. ### 프레임워크 계층화 및 유지보수성 * **강력한 추상화 경계:** GraphQL 실행 엔진, 테넌트 API, 애플리케이션 코드 사이의 인터페이스를 명확히 분리했습니다. 과거의 느슨했던 경계를 강화하여 서비스 로직의 중단 없이 엔진 성능을 개선하거나 라이브러리를 업데이트할 수 있는 구조를 갖췄습니다. * **운영 안정성:** 이러한 구조적 개선을 통해 개발자 수와 코드 라인 수가 급격히 증가함에도 불구하고 장애 시간을 절반으로 줄이는 성과를 거두었습니다. Viaduct는 대규모 조직에서 데이터 접근 방식을 통합하고 비즈니스 로직을 효율적으로 관리하려는 팀에게 강력한 모델을 제시합니다. 특히 마이크로서비스의 복잡도를 낮추고 싶은 조직이라면, Viaduct의 재진입 구조와 서버리스 호스팅 개념을 도입하여 개발 민첩성과 시스템 안정성을 동시에 확보하는 방향을 고려해 볼 만합니다.

datadog2분 읽기큐레이션 요약

모놀리스 해체: 대규모

Datadog은 Gartner의 「Observability Platforms」 매직 쿼드런트에서 리더(Leader)로 선정되었다고 소개합니다. 제공된 내용은 선정 소식과 Datadog의 제품 메뉴를 중심으로 구성되어 있어, 평가 기준이나 구체적인 분석 내용은 확인할 수 없습니다. Datadog은 인프라·애플리케이션·로그·보안·사용자 경험·소프트웨어 개발을 아우르는 통합 관측성 플랫폼을 지향합니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog이 Gartner의 「Magic Quadrant for Observability Platforms」에서 리더로 평가되었다는 내용입니다. - 링크에는 2026년 평가 자료로 보이는 리소스가 연결되어 있습니다. - 다만 제공된 본문에는 Gartner의 평가 기준, Datadog의 강점과 약점, 경쟁사 비교 등의 세부 내용은 포함되어 있지 않습니다. ### 인프라 및 클라우드 관측성 - 인프라 모니터링, 메트릭, 컨테이너 및 Kubernetes 모니터링을 제공합니다. - 네트워크, 서버리스, 스토리지, GPU 모니터링 기능을 포함합니다. - 클라우드 비용 관리와 Cloudcraft를 통해 인프라 구성 시각화 및 비용 관리도 지원합니다. ### 애플리케이션 및 데이터 관측성 - APM(Application Performance Monitoring)으로 애플리케이션 성능을 추적합니다. - 서비스 모니터링, 연속 프로파일링, 동적 계측, 에이전트 관측성 기능을 제공합니다. - 데이터베이스, 데이터 스트림, 데이터 품질, 데이터 작업(Job) 모니터링을 지원합니다. ### 로그 및 보안 통합 - 로그 관리와 Observability Pipelines를 통해 로그 수집·처리·전송을 관리합니다. - Sensitive Data Scanner와 Audit Trail로 민감 정보 및 감사 기록을 관리합니다. - 코드 보안, SAST, IAST, IaC 보안, 클라우드 보안, SIEM, 워크로드 보호 등 보안 기능도 플랫폼에 포함합니다. ### 디지털 경험과 소프트웨어 전달 - Browser·Mobile RUM, 세션 리플레이, 신서틱 모니터링으로 실제 사용자 경험을 분석합니다. - 오류 추적, 제품 분석, 실험 기능을 제공합니다. - CI 가시성, 테스트 최적화, 지속적 테스트, 코드 커버리지, 기능 플래그 등 소프트웨어 전달 과정도 관측합니다. ### 서비스 관리와 AI 기능 - 이벤트 관리, 서비스 카탈로그, SLO, 인시던트 대응, 워크플로 자동화를 지원합니다. - Watchdog과 Bits 계열 AI 기능을 통해 이상 탐지, 조사, 대화형 분석 및 자동화를 제공합니다. - GPU 모니터링, AI 에이전트 관측성, MCP 서버 등 AI 시스템 운영을 위한 기능도 강조됩니다. 제공된 자료만 기준으로 보면, 이 글의 핵심은 Datadog이 폭넓은 인프라·애플리케이션·보안·사용자 경험 데이터를 하나의 플랫폼에서 다루며 관측성 시장의 리더로 평가받았다는 점입니다. 다만 실제 도입이나 제품 비교를 위해서는 연결된 Gartner 보고서에서 평가 근거와 제한 사항을 별도로 확인해야 합니다.

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

쿠팡 SCM 워크플로우: 효율적이고 확장 가능한 low-code, no-code 플랫폼 개발 (새 탭에서 열림)

쿠팡 SCM 팀은 복잡한 공급망 관리 과정에서 발생하는 다양한 직군 간의 협업 비용을 줄이고 시스템 확장성을 높이기 위해 'SCM 워크플로우 플랫폼'을 구축했습니다. 이 플랫폼은 Low-code와 No-code 방식을 도입하여 개발자뿐만 아니라 비개발자도 직접 데이터 파이프라인을 설계하고 서비스에 적용할 수 있는 환경을 제공합니다. 이를 통해 요구사항 변화에 민첩하게 대응하며, 데이터 생성부터 프로덕션 연동까지의 전 과정을 효율화하는 것을 목표로 합니다. **No-code 데이터 빌더를 통한 데이터 접근성 혁신** * **다양한 데이터 소스 통합:** Redshift, Hive, Presto, Aurora, MySQL, Elasticsearch, S3 등 산재한 공용 데이터 소스에 대한 접근 및 질의를 코드 없이 수행할 수 있습니다. * **시각적 노드 기반 설계:** 사용자는 데이터 추출, 계산, 연동 등의 과정을 시각적인 '노드'로 생성하고 연결함으로써 직관적인 데이터 워크플로우를 구성할 수 있습니다. * **협업 효율화:** 비즈니스 분석가(BA)나 데이터 사이언티스트가 개발자에게 매번 파이프라인 생성을 요청하던 기존 프로세스를 개선하여, 스스로 데이터를 가공하고 시스템에 반영할 수 있게 함으로써 커뮤니케이션 비용을 획기적으로 낮췄습니다. **Low-code 기반의 서비스 확장 및 운영 효율화** * **도메인 확장성 확보:** 새로운 시스템을 매번 구축하지 않고도 워크플로우 설정을 통해 도메인을 확장할 수 있어, 변화가 빠른 이커머스 환경에 유연하게 대처합니다. * **기존 도구의 복잡성 해소:** Jenkins, Airflow, Notebook 등 파편화된 도구들이 가진 연결성 문제를 단일 플랫폼 안에서 통합하여 관리 편의성을 높였습니다. * **신속한 서비스 론칭:** 간단한 조작만으로 데이터를 시각화하거나 간단한 서비스를 출시할 수 있는 환경을 제공하여 아이디어의 실행 속도를 높였습니다. **실용적인 결론 및 제언** SCM 워크플로우 플랫폼은 데이터 기반 의사결정의 주체를 전 직군으로 확대하는 '데이터 민주화'를 실현하는 도구입니다. 복잡한 MSA(마이크로서비스 아키텍처) 환경에서 데이터 파이프라인 유지보수에 많은 리소스를 소모하고 있는 조직이라면, 이러한 로우코드 기반의 워크플로우 플랫폼을 도입하여 엔지니어링 역량을 핵심 알고리즘 개발에 집중시키고 운영 효율을 극대화할 것을 추천합니다.

datadog원문

Datadog IT 팀이 계정 비활성화와 SaaS 지출 관리를 자동화한 방법 (새 탭에서 열림)

데이터독(Datadog)은 급격히 증가하는 SaaS 라이선스 비용을 최적화하고 보안 리스크를 줄이기 위해 기존의 내부 도구인 'Clarity'를 'Clarity License Manager(CLM)'로 확장했습니다. 이 시스템은 여러 SaaS 애플리케이션의 사용자 활동을 자동으로 모니터링하여 비활성 계정을 식별하고, 사용자 알림 및 자동 비활성화 프로세스를 통해 운영 효율성을 극대화합니다. 결과적으로 데이터독은 불필요한 비용 지출을 막는 동시에, 미사용 계정으로 인한 보안 위협을 효과적으로 제거하고 직원들에게는 원활한 계정 복구 경험을 제공하고 있습니다. ### 기존 라이선스 관리의 문제점 * 과거 IT 지원 팀은 분기별로 수동 감사를 수행하여 라이선스 사용 현황을 파악했으나, 이는 매우 비효율적이고 지루한 작업이었습니다. * IT 직원이 사용자에게 일일이 연락해 계정 유지 여부를 확인해야 했기 때문에 직원들의 업무 흐름을 방해하는 등 사용자 경험이 저하되었습니다. * 실시간 데이터에 기반한 인사이트가 부족하여 소프트웨어 구매 시 데이터에 기반한 의사결정을 내리기 어려웠습니다. ### 자동화된 라이선스 최적화 워크플로우 * 개별 SaaS API와 Google Workspace SAML 감사 로그를 결합하여 사용자 활동 데이터를 유연하고 보안상 안전한 방식으로 수집합니다. * 특정 기간(기본 90일) 동안 앱을 사용하지 않은 사용자에게 Slack과 이메일로 자동 알림을 발송하여 활성 상태 유지에 필요한 구체적인 행동을 안내합니다. * 사용자가 안내된 조치를 취하지 않을 경우 CLM이 해당 SaaS 계정을 자동으로 비활성화하며, 이 데이터는 Amazon RDS(Postgres)에 저장되어 관리됩니다. * 재접속이 필요한 직원을 위해 티켓 시스템(Freshservice)과 연동된 자동 복구 워크플로우를 구축하여, 단 몇 초 만에 이전 권한 그대로 계정을 복구할 수 있게 했습니다. ### 마이크로서비스 및 어댑터 기반 아키텍처 * Python과 AWS Lambda를 기반으로 한 마이크로서비스 구조를 채택하여 SaaS 환경의 확장에 유연하게 대응하고 시스템 회복 탄력성을 높였습니다. * 각 SaaS 애플리케이션의 고유한 로직을 처리하기 위해 '애플리케이션별 어댑터(Adapter)' 패턴을 도입했습니다. * 어댑터는 사용자 조회, 로그인 데이터 획득, 활성화/비활성화 등 공통 인터페이스를 제공하여 메인 마이크로서비스 로직과 개별 앱의 복잡한 API 통신 로직을 분리합니다. * 이러한 설계는 단일 책임 원칙(Single Responsibility)을 준수하며 코드의 재사용성을 높이고, 새로운 SaaS 도구를 시스템에 빠르게 통합할 수 있게 합니다. 기업의 규모가 커질수록 수동 라이선스 관리는 비용 누수와 보안 취약점을 야기하는 큰 부담이 됩니다. Datadog의 CLM 사례처럼 사용자 활동 데이터를 기반으로 비활성 계정을 자동 관리하고, 셀프 서비스 형태의 복구 프로세스를 갖추는 것은 비용 절감과 보안 강화라는 두 마리 토끼를 잡을 수 있는 실무적인 해법이 될 수 있습니다.

airbnb원문

데이터 지향 서비스 메시를 (새 탭에서 열림)

에어비앤비가 도입한 '바이아덕트(Viaduct)'는 거대해진 마이크로서비스 아키텍처(SOA)의 복잡성을 해결하기 위해 제안된 데이터 지향 서비스 메시입니다. 기존의 서비스 메시가 단순히 서비스 간의 원격 프로시저 호출(RPC)을 라우팅하는 데 집중했다면, 바이아덕트는 GraphQL 스키마를 중심에 두어 데이터 소비자가 하위 서비스의 구조를 몰라도 필요한 데이터를 효율적으로 가져올 수 있게 합니다. 이를 통해 서비스 간 의존성 그래프를 단순화하고 시스템 전반의 모듈성과 데이터 민첩성을 획기적으로 향상시켰습니다. **기존 SOA의 복잡성과 데이터 지향 설계의 필요성** - 마이크로서비스의 수가 수천 개로 늘어나면서 서비스 간 의존 관계가 '스파게티 코드'처럼 얽히는 문제가 발생했습니다. - 현재의 SOA는 1970년대 스타일의 프로시저 지향 설계에 머물러 있어, 각 서비스가 단순한 엔드포인트의 집합으로 취급됩니다. - 에어비앤비는 1980년대 객체 지향 언어들이 데이터를 중심으로 로직을 캡슐화했던 것처럼, SOA도 데이터 중심으로 진화해야 한다고 판단했습니다. **GraphQL 기반의 데이터 지향 서비스 메시, Viaduct** - 바이아덕트는 서비스 메시의 핵심을 데이터 중심의 GraphQL 스키마(Type, Query, Mutation)로 정의합니다. - 데이터 소비자(Consumer)는 특정 서비스의 엔드포인트를 직접 호출하는 대신, 필요한 데이터 필드를 쿼리하기만 하면 됩니다. - 서비스 메시는 어떤 서비스가 특정 데이터 요소를 제공하는지 알고 있으며, 소비자를 대신해 이를 결합(Orchestration)하여 전달함으로써 서비스 간 직접적인 의존성을 제거합니다. **중앙 집중형 스키마를 통한 데이터 민첩성 확보** - 바이아덕트는 단일화된 '중앙 스키마(Central Schema)'를 통해 여러 팀이 협업할 수 있는 구조를 제공합니다. - 데이터베이스 스키마 변경이 여러 계층의 마이크로서비스 API에 수동으로 반영되어야 했던 과거와 달리, 중앙 스키마 업데이트만으로 클라이언트까지 변경 사항을 즉시 전파할 수 있습니다. - 이는 대규모 SOA 환경에서 데이터 구조 변경에 소요되는 수 주간의 조율 과정을 획기적으로 단축합니다. **서버리스 기능을 활용한 서비스 단순화** - 클라이언트 요구에 맞춰 데이터를 가공하는 'BFF(Backend-for-Frontend)'나 상태 없는 변환 서비스들을 서버리스 클라우드 함수로 대체합니다. - 바이아덕트 내에서 '파생 필드(Derived fields)' 계산 로직을 서버리스로 실행함으로써, 복잡한 서비스 계층을 줄이고 그래프 구조를 깔끔하게 유지합니다. - 이를 통해 서비스의 개수와 복잡도를 낮추면서도 클라이언트에게 최적화된 데이터를 제공할 수 있습니다. **기술적 특징 및 관찰 가능성** - 바이아덕트는 `graphql-java`를 기반으로 구축되었으며, 세밀한 필드 선택 기능을 지원합니다. - 시스템 안정성을 위해 서킷 브레이킹(Short-circuiting), 소프트 의존성(Soft dependencies), 요청 내 캐싱(Intra-request cache) 등의 기술을 적용했습니다. - 필드 단위의 데이터 관찰 가능성(Data observability)을 제공하여, 어떤 서비스가 어떤 데이터를 소비하는지 정확하게 파악하고 관리할 수 있습니다. 이처럼 거대해진 마이크로서비스 환경에서 운영 효율을 높이려면, 개별 서비스의 엔드포인트 관리에서 벗어나 데이터 중심의 추상화 계층을 구축하는 것이 중요합니다. 에어비앤비의 사례는 GraphQL을 단순한 API 게이트웨이를 넘어 시스템 전체의 의존성을 관리하는 서비스 메시로 확장함으로써 복잡성을 제어할 수 있음을 보여줍니다.

datadog원문

데이터독에서의 Consul (새 탭에서 열림)

Datadog은 지난 18개월간 마이크로서비스 아키텍처의 구성 정보 배포와 서비스 디스커버리를 위해 Consul을 핵심 기술로 활용해 왔습니다. Consul 클러스터의 안정성을 유지하기 위해서는 Raft 합의 알고리즘을 뒷받침할 충분한 CPU 자원 확보와 dnsmasq를 활용한 쿼리 부하 분산이 필수적이며, 모든 변경 사항은 감사 가능한 구조로 관리해야 합니다. **Consul 서버의 CPU 리소스 확보** * Consul 서버는 Raft 프로토콜을 통해 리더를 선출하며, 500ms 동안 리더의 응답이 없으면 새로운 리더 선출 과정(leadership transition)이 시작됩니다. * 빈번한 리더 교체는 시스템 불안정의 신호이므로, 시간당 1회 이상 발생한다면 서버의 CPU 성능을 높여야 합니다. * 에이전트 노드 수에 따른 권장 사양은 300대 기준 m3.large, 500대 기준 c3.xlarge, 800대 기준 c3.2xlarge 수준입니다. **감사 가능한 구성 변경 관리** * Consul의 KV(Key-Value) 스토리지에 데이터를 직접 저장할 경우 변경 이력을 추적하기 어렵다는 위험이 있습니다. * Datadog은 git2consul을 사용하여 Git 저장소의 내용을 Consul에 동기화함으로써, 누가 언제 무엇을 변경했는지에 대한 감사 추적(Audit trail)을 유지합니다. * 이를 통해 클러스터 전체의 구성 변경을 60초 이내에 안전하고 신속하게 수행합니다. **ACL과 Watch를 이용한 부하 및 보안 관리** * ACL(Access Control List) 기능을 활용하여 권한이 있는 프로세스만 데이터를 수정하도록 제한하고, 실수로 인한 데이터 삭제 범위를 국소화해야 합니다. * Consul은 Redis처럼 초당 수십만 건의 읽기/쓰기를 처리하도록 설계되지 않았으므로, 변경 사항을 효율적으로 감지하기 위해 'Watch' 기능을 활용해야 합니다. * 다만 Watch가 예기치 않게 과도하게 실행되는 것을 방지하기 위해 sifter와 같은 도구를 병용하는 것이 좋습니다. **dnsmasq를 통한 DNS 부하 경감** * 서비스 디스커버리를 위해 Consul DNS 인터페이스를 직접 쿼리하면 부하가 집중될 수 있으므로, 각 노드에 dnsmasq를 설치하여 캐시 레이어로 활용해야 합니다. * Consul의 DNS TTL을 짧게(예: 10초) 설정하고, dnsmasq가 먼저 요청을 처리한 뒤 모르는 정보만 Consul에 묻도록 구성합니다. * 매우 높은 트래픽 환경에서는 Consul 데이터를 로컬 호스트 파일로 캐싱하여 dnsmasq에 로드함으로써, Consul 직접 쿼리 수를 초당 400건 수준으로 유지하면서도 전체 DNS 요청은 초당 10만 건 이상 처리할 수 있습니다. **Consul 모니터링 필수 지표** * 리더 선출 상태를 확인하는 `consul.consul.leader.reconcile.count`와 리더 교체 주기를 알 수 있는 `consul.serf.events.consul_new_leader`를 모니터링해야 합니다. * 리더와의 마지막 통신 시간을 나타내는 `consul.raft.leader.lastContact`와 Consul로 직접 들어오는 DNS 쿼리 양도 주요 관찰 대상입니다. * 서버 노드의 CPU와 네트워크 사용량을 실시간으로 추적하여 인프라 병목 현상을 사전에 방지해야 합니다. 성공적인 Consul 운영을 위해서는 단순히 설치하는 것에 그치지 않고, 인프라 규모에 맞는 적절한 CPU 사양 선택과 캐싱 전략을 통한 부하 관리가 선행되어야 합니다. 특히 설정값 관리에 있어서는 git2consul과 ACL을 결합하여 보안과 이력 관리라는 두 마리 토끼를 모두 잡는 방식을 추천합니다.