플랫폼은 왜 계속 다시 설계되어야 할까 - Server Platform Team 이야기
서버 플랫폼 팀이 조직 성장에 맞춰 플랫폼을 계속 재설계하는 이유를 소개했습니다. AI 시대의 분석·개발·운영 변화와 그에 따른 가드레일까지 함께 다뤘습니다.
#SRE#CI/CD
10400
국내 IT 기업 기술 블로그 최신 글
새로운 기술 블로그가 추가되었어요
필터 1
KBO 리그 이닝 교체 때 광고 요청 견뎌내기
KBO 리그 이닝 교체 때 광고 요청 견뎌내기
KBO 리그 이닝 교체 때 몰리는 광고 요청을 분산하기 위해 prefetching과 내부 캐시 구조를 적용했습니다. 그 결과 외부 광고 서버 부하와 지연을 줄이고 버퍼링 지표도 개선했습니다.
#AWS#Kafka
8100
카프카 파티션 개수 산정식 설계 여정
카프카 파티션 개수 산정식 설계 여정
Kafka 파티션 수를 처리량과 컨슈머 catch-up 기준으로 계산하는 산정식을 정리했습니다. 운영 환경 실측값을 반영해 토픽별 초기 파티션 수를 일관되게 정하는 방법을 제안했습니다.
#Kafka#partition
1500
카프카 파티션 개수 산정식 설계 여정
카프카 파티션 수를 정하는 산정식과 기준값을 설계한 과정을 정리했습니다. 프로듀서 처리량, 컨슈머 catch-up, 운영 한도를 함께 고려해 초기 파티션 수 판단 기준을 제안했습니다.
#Kafka#partitions
19300
![[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합](https://flex.team/blog/og/main.jpg)
[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합
테스트 인프라를 프로덕션 구조에 맞춰 variant와 스냅샷 캐시로 분리·재사용하는 방법을 정리했습니다. 경계를 깎아 교체 가능성을 만들면 CI와 개발 이터레이션이 함께 빨라졌습니다.
#MySQL#Kafka
13500
![[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합](https://cdn.sanity.io/images/v31psllp/production/05ffda096002d40620c7bc75e64174185b7d8a1d-1684x1030.png)
[코드가 환경을 모르는 구조 7/7] Variant와 스냅샷 캐시, 그리고 다섯 축의 총합
테스트 인프라에서 variant와 스냅샷 캐시로 프로덕션의 분리를 그대로 재현하는 구조를 설명했습니다. 경계를 명확히 하면 교체 가능성이 높아지고 실험 속도도 빨라진다고 정리했습니다.
#Kotlin#MySQL
5500
쿠팡 파트너스
개발자를 위한 서적을 확인해 보세요
이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
#개발서적#프로그래밍
![[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다](https://cdn.sanity.io/images/v31psllp/production/880cbd1201bc94d8f408147dcd135aef78e683b4-1684x1030.png)
[코드가 환경을 모르는 구조 5/7] Rewrite Host — 공간 축을 교체한다
MSA 환경에서 전체 시스템을 띄우지 않고 수정 중인 서비스만 로컬로 교체하는 Rewrite Host를 소개했습니다. 디버그 헤더로 라우팅을 바꾸고, 응답 헤더로 적용 여부를 알려주는 방식입니다.
#MSA#Spring Cloud Gateway
3800
[코드가 환경을 모르는 구조 4/7] 타임머신 — 시간 축을 교체한다
HR SaaS에서 시간을 비즈니스 입력으로 보고, 요청 헤더와 `Clock` Adapter로 현재 시점을 교체하는 타임머신 구조를 설명했습니다. 비동기 경계 전파와 환경별 활성화, 서드파티 시계 호출의 한계도 함께 다뤘습니다.
#헥사고날 아키텍처#Spring Boot
1600
StarRocks 운영기: Resource Group으로 멀티테넌트 워크로드 격리하기
StarRocks에서 Resource Group으로 멀티테넌트 워크로드를 분류하고 CPU 우선순위를 조절한 운영 경험을 정리했습니다. 서비스 SLA가 필요한 경우에는 exclusive_cpu_cores와 주의점을 함께 적용했습니다.
#Starrocks#Resource Group
5100
45분 배치에서 준실시간으로! 다수 도메인 데이터를 Kafka로 통합한 전환기
상품·쿠폰·증정·프로모션 데이터를 Kafka 기반 준실시간 구조로 전환한 사례입니다.\nRedis Pub/Sub, Aggregation Topic, Shadow Table로 정합성과 안전한 이관을 확보했습니다.
#Kafka#Redis
44000
채널톡 메인 백엔드 서버 CI 개선기
채널톡 메인 백엔드 서버 CI 개선기
채널톡 메인 백엔드 서버의 CI 병목을 단계적으로 분해해 개선한 과정을 정리했습니다. 공유 상태 제거, prepare 분리, 동적 큐와 캐시로 실행 시간을 크게 줄였습니다.
#CI/CD#Java
700
채널톡 메인 백엔드 서버 CI 개선기
AI가 코드를 빠르게 만들수록 CI 병목과 피드백 속도가 더 중요해졌습니다. 채널톡은 공유 상태 제거와 캐시, 동적 큐로 메인 백엔드 CI를 36.6분에서 15분대까지 줄였습니다.
#CI/CD#Java
5300
Apache Flink + RocksDB 튜닝으로 광고 Frequency Capping 실시간 집계를 일주일까지 확장하기
Apache Flink와 RocksDB 튜닝으로 광고 Frequency Capping 실시간 집계를 7일 구간까지 확장한 사례를 다루었습니다. 세 개의 Flink 앱으로 분리해 병목을 각각 해결하고 Redis 단일 조회 구조로 단순화했습니다.
#Apache Flink#RocksDB
11300
주문 트래픽 20배를 견디는 재고 처리 구조 만들기
주문 트래픽 20배를 견디는 재고 처리 구조 만들기
공동구매 트래픽 폭증으로 재고 처리의 lock 경합이 병목이 되자 Redis와 Kafka 중심으로 구조를 재설계했습니다. 재고 경로를 단일화하고 비동기 반영과 fallback을 더해 약 20배 트래픽을 안정적으로 견뎠습니다.
#Redis#Kafka
2400