병목을 좁힌 과정, 설계를 선택한 이유, 검증한 결과로 읽는 백엔드 사례
대표 엔지니어링 사례
여러 게임이 공유하도록 설계한 채팅 서버의 Valkey 쓰기 병목을 채널 단위 샤딩으로 풀어 ACK p95 767.6ms→6.6ms, dev 부하 시험에서 20,002 CCU 900초 유지
단일 노드 → 4-shard cluster
목표 대비 3.3배 동시접속 유지
RDS CPU·IO 포화 3건을 Performance Insights·EXPLAIN으로 원인 쿼리까지 좁혀 해결: 백필 처리량 26배(9.3→247건/분), 2,637만 행 감사 로그의 최장 36분 풀스캔 제거(EXPLAIN rows=3)
26배 · 15,333건 완료, 대기 0건
p99 67.0s→2.99s
2년 넘게 어긋난 게임 서버의 데이터 모듈 fork를 공통 npm 패키지로 정렬(610개 파일·310+ import 마이그레이션)하고, 7개 프로젝트 업그레이드를 GitHub Actions로 자동화(수동 약 3시간→약 15분), 공통 서버 키트의 테스트 job 평균 시간을 61% 단축(15분47초→6분6초)
61% 단축 · CI 전체 약 16분→약 7분
7개 프로젝트 matrix 병렬
전사 AI 코딩 에이전트의 기기 정책 가드·사용량 수집 서버 설계·운영·머지 승인을 맡고 AI 에이전트로 구현: 가드의 정책 배포로 사용량 보고 스위치를 92명에게 켜 보고 중인 기기 87대 모두에서 집행을 확인했고, 수집 서버의 2일 18시간·17시간 40분 무응답 장애 뒤 메모리 상한을 "앱 < 컨테이너 < 호스트" 순서로 다시 잡고 파싱을 스트리밍으로 바꿔 최대 파일 파싱 피크를 640MiB 한도의 67%로 낮췄습니다.
활성 명단 92명 배정 · 보고 중인 온라인 기기 기준
2일 18시간 31분 무응답 후 적용 · 재파싱 루프가 방아쇠였을 가능성은 남음