Spring 시니어 시스템 설계 면접
새 면접Q. 월간 10억 건 이상의 주문을 처리하는 이커머스 시스템에서 재고 차감 로직을 설계해야 합니다. 동시성 제어, 성능, 정합성을 모두 고려한 아키텍처를 제시하고, 각 방식의 트레이드오프를 설명해주세요. 특히 낙관적 락, 비관적 락, 분산 락, 이벤트 기반 비동기 처리 방식을 비교 분석해주세요.
재고 차감은 동시성과 정합성이 핵심입니다. 낙관적 락(Version 컬럼)은 충돌이 적은 경우 성능이 우수하나 재시도 로직 필요하며, 비관적 락(SELECT FOR UPDATE)은 정합성은 보장하나 처리량이 제한됩니다. Redis 기반 분산 락(Redisson)은 다중 인스턴스 환경에서 효과적이나 Redis 장애 시 영향이 크며, 이벤트 기반 방식(Kafka + 재고 전용 서비스)은 최종 일관성으로 높은 처리량을 제공하나 복잡도가 증가합니다. 실무에서는 주문 생성 시 Redis 분산 락으로 즉시 검증하고, 비동기로 DB 재고를 차감하며, 정산 시점에 정합성을 재확인하는 하이브리드 방식을 많이 사용합니다.
- • 낙관적 락은 충돌률이 낮을 때 적합하며 @Version과 재시도 로직 구현 필요
- • 비관적 락은 강한 정합성 보장하나 DB 커넥션 점유로 처리량 제한
- • Redis 분산 락(Redisson)은 다중 인스턴스 환경에서 효과적이나 Redis 가용성 의존
- • 이벤트 기반 비동기 처리는 최종 일관성으로 높은 처리량 제공하나 보상 트랜잭션 필요
- • 하이브리드 방식으로 즉시 검증과 비동기 처리를 조합하여 성능과 정합성 균형
Redis 분산 락을 사용할 때 락 타임아웃이 발생하면 어떻게 처리해야 하며, 데드락을 방지하기 위한 전략은 무엇인가요?
Q. 수백 개의 파트너사가 사용하는 Public API를 운영 중입니다. 하위 호환성을 유지하면서 API를 진화시키기 위한 버전 관리 전략을 설계해주세요. URI 버전, 헤더 버전, Content Negotiation 방식의 장단점을 비교하고, Deprecation 정책과 마이그레이션 가이드 제공 방안을 포함해 설명해주세요.
API 버전 관리는 하위 호환성과 진화 가능성의 균형이 중요합니다. URI 버전(/v1/users)은 명확하고 캐싱에 유리하나 URL이 증가하며, 헤더 버전(X-API-Version)은 URI를 깔끔하게 유지하나 가시성이 떨어집니다. Content Negotiation(Accept 헤더)은 RESTful하나 복잡도가 높습니다. 실무에서는 URI 버전을 주로 사용하며, 메이저 변경 시에만 버전을 올리고 마이너 변경은 하위 호환성을 유지합니다. Deprecation 정책은 최소 6개월 사전 공지, Sunset 헤더 제공, 구버전 사용량 모니터링, 마이그레이션 가이드 및 SDK 제공, 단계적 종료(경고→읽기전용→종료)로 구성합니다.
- • URI 버전은 명확하고 캐싱 친화적이나 URL 증가, 헤더 버전은 깔끔하나 가시성 낮음
- • 메이저 변경(Breaking Change)만 버전업하고 마이너 변경은 하위 호환 유지
- • Sunset 헤더와 Deprecation 헤더로 종료 시점 사전 공지
- • 구버전 API 사용량 모니터링 및 파트너사별 마이그레이션 현황 추적
- • 마이그레이션 가이드, SDK, 샌드박스 환경 제공으로 전환 지원
API Gateway를 사용할 때 버전별 라우팅과 트래픽 제어를 어떻게 구현하며, Canary 배포를 통한 점진적 전환 전략은 무엇인가요?
Q. 사용자 수가 1억 명을 넘어서면서 단일 DB로는 처리가 어려워졌습니다. Spring 환경에서 수평 샤딩(Horizontal Sharding)을 구현하기 위한 아키텍처를 설계해주세요. 샤딩 키 선정 기준, 라우팅 전략, 크로스 샤드 쿼리 처리, 리샤딩 전략을 포함해 설명해주세요.
샤딩 키는 데이터 분산의 균등성과 쿼리 패턴을 고려해 선정하며, 사용자 ID나 테넌트 ID가 일반적입니다. 라우팅은 AbstractRoutingDataSource를 확장해 샤딩 키 기반으로 DataSource를 동적 선택하며, ThreadLocal로 컨텍스트를 관리합니다. 크로스 샤드 쿼리는 애플리케이션 레벨에서 병렬 조회 후 머지하거나, 글로벌 DB에 필요한 데이터를 복제하는 방식을 사용합니다. 리샤딩은 Consistent Hashing으로 데이터 이동을 최소화하거나, 더블 라이팅(구/신 샤드 동시 쓰기) 후 마이그레이션하는 방식을 적용하며, 샤드 수를 2의 배수로 설계해 분할을 용이하게 합니다.
- • 샤딩 키는 데이터 균등 분산과 쿼리 패턴을 고려해 선정(사용자 ID, 테넌트 ID 등)
- • AbstractRoutingDataSource 확장으로 동적 DataSource 라우팅 구현
- • 크로스 샤드 쿼리는 애플리케이션 레벨 머지 또는 글로벌 DB 복제로 처리
- • Consistent Hashing으로 리샤딩 시 데이터 이동 최소화
- • 더블 라이팅과 점진적 마이그레이션으로 무중단 리샤딩 구현
샤드 간 트랜잭션이 필요한 경우 어떻게 처리하며, Saga 패턴을 적용할 때 보상 트랜잭션 설계는 어떻게 하나요?
Q. 다층 캐시 아키텍처(로컬 캐시 + Redis)를 설계할 때 고려해야 할 사항들을 설명해주세요. Cache Aside, Write Through, Write Behind 패턴의 차이점과 각 패턴이 적합한 시나리오, 그리고 캐시 무효화 전략(TTL, 이벤트 기반, Cache Stampede 방지)을 구체적으로 설명해주세요.
다층 캐시는 로컬 캐시(Caffeine)로 네트워크 오버헤드를 줄이고 Redis로 인스턴스 간 공유를 구현합니다. Cache Aside는 애플리케이션이 캐시를 직접 관리하며 읽기 중심 워크로드에 적합하고, Write Through는 쓰기 시 캐시와 DB를 동기 업데이트해 일관성이 높으나 지연이 발생하며, Write Behind는 비동기 쓰기로 성능이 우수하나 데이터 유실 위험이 있습니다. 캐시 무효화는 TTL로 자동 만료, 이벤트 발행(Kafka)으로 명시적 무효화, Cache Stampede는 분산 락이나 Probabilistic Early Expiration으로 방지합니다. 로컬 캐시는 Redis Pub/Sub으로 무효화 메시지를 전파합니다.
- • 로컬 캐시(Caffeine)와 Redis 조합으로 성능과 일관성 균형
- • Cache Aside는 읽기 중심, Write Through는 강한 일관성, Write Behind는 쓰기 성능 우선
- • TTL 기반 자동 만료와 이벤트 기반 명시적 무효화 조합
- • Cache Stampede는 분산 락 또는 Probabilistic Early Expiration으로 방지
- • Redis Pub/Sub으로 다중 인스턴스의 로컬 캐시 동기화
캐시와 DB 간 데이터 불일치가 발생했을 때 이를 감지하고 복구하는 방법은 무엇이며, 캐시 워밍 전략은 어떻게 구현하나요?
Q. 마이크로서비스 아키텍처에서 서비스 간 인증/인가를 구현하기 위한 보안 설계를 제시해주세요. API Gateway에서의 인증, 서비스 간 mTLS, Service Mesh를 활용한 Zero Trust 아키텍처, 그리고 토큰 전파(Token Relay) 시 보안 고려사항을 포함해 설명해주세요.
마이크로서비스 보안은 경계 보안과 내부 보안을 모두 고려해야 합니다. API Gateway에서 JWT 검증 및 인증을 수행하고, 내부 서비스로는 토큰을 전파하거나 Gateway에서 신뢰할 수 있는 내부 토큰으로 교환합니다. 서비스 간 통신은 mTLS(Mutual TLS)로 암호화하고 인증서 기반 신원 확인을 수행하며, Istio 같은 Service Mesh는 사이드카 패턴으로 투명하게 mTLS를 적용합니다. Zero Trust는 모든 요청을 검증하며, SPIFFE/SPIRE로 서비스 신원을 관리합니다. 토큰 전파 시에는 민감 정보 제거, 토큰 범위 축소, 짧은 TTL 설정, 서비스별 클레임 필터링을 적용해 최소 권한 원칙을 따릅니다.
- • API Gateway에서 JWT 검증 후 내부 토큰 교환으로 경계 보안 구현
- • mTLS로 서비스 간 통신 암호화 및 상호 인증 수행
- • Service Mesh(Istio)로 사이드카 패턴 기반 투명한 보안 적용
- • Zero Trust 아키텍처는 SPIFFE/SPIRE로 서비스 신원 관리
- • 토큰 전파 시 민감 정보 제거, 범위 축소, 짧은 TTL로 최소 권한 원칙 적용
서비스 메시 없이 Spring Cloud를 사용할 때 Feign Client에서 토큰 전파와 인증을 어떻게 구현하며, Circuit Breaker와 보안을 함께 고려하는 방법은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!