GCP 미드레벨 시스템 설계 기술면접
새 면접Q. 일일 1억 건의 요청을 처리하는 RESTful API를 GCP에서 설계한다고 할 때, API Gateway, Cloud Endpoints, Cloud Load Balancing 중 어떤 구성을 선택하고 그 이유는 무엇인가요?
각 서비스의 특징과 트래픽 규모, 비용, 관리 복잡도를 고려해보세요.
1억 건 규모라면 Cloud Load Balancing과 Cloud Run 또는 GKE의 조합을 권장합니다. API Gateway는 1백만 건 이하의 중소규모에 적합하며, 대규모에서는 비용이 급증합니다. Cloud Endpoints는 API 관리 기능이 필요할 때 Load Balancing 위에 추가로 구성할 수 있습니다. Load Balancing은 초당 100만 요청 이상을 처리할 수 있으며, 글로벌 분산과 자동 스케일링이 우수합니다. 또한 Cloud CDN과 통합하여 정적 응답을 캐싱하면 백엔드 부하를 크게 줄일 수 있습니다.
- • 트래픽 규모에 따른 서비스 선택 기준
- • Cloud Load Balancing의 확장성 우위
- • 비용 효율성과 성능의 트레이드오프
- • Cloud CDN을 통한 캐싱 전략
대규모 모바일 앱의 백엔드 API나 IoT 디바이스의 데이터 수집 엔드포인트 설계 시 적용됩니다.
만약 API 버전 관리와 인증/인가가 복잡한 요구사항이 추가된다면 아키텍처를 어떻게 수정하시겠습니까?
Q. 읽기 대 쓰기 비율이 100:1인 전자상거래 상품 카탈로그 시스템을 설계할 때, Cloud SQL, Cloud Spanner, Firestore 중 어떤 것을 선택하고 어떤 캐싱 전략을 적용하시겠습니까?
읽기 집약적인 워크로드의 특성과 각 데이터베이스의 읽기 성능, 캐싱 계층의 필요성을 생각해보세요.
읽기 집약적이고 상품 데이터가 구조화되어 있다면 Cloud SQL(PostgreSQL)과 Memorystore(Redis)의 조합이 적합합니다. Cloud SQL의 읽기 레플리카를 3~5개 구성하고, Memorystore에 상품 상세 정보를 TTL 1시간으로 캐싱합니다. 상품 목록은 Cloud CDN에 캐싱하여 엣지에서 처리하고, 재고와 가격처럼 자주 변경되는 데이터는 짧은 TTL(5분)을 적용합니다. Cloud Spanner는 글로벌 일관성이 필요한 주문 시스템에 적합하지만 상품 카탈로그에는 과도한 비용이 발생하며, Firestore는 문서 기반으로 복잡한 쿼리가 제한적입니다. 캐시 무효화는 Pub/Sub를 통해 상품 업데이트 이벤트를 구독하여 처리합니다.
- • 읽기 레플리카를 통한 읽기 부하 분산
- • Memorystore를 활용한 애플리케이션 레벨 캐싱
- • 데이터 특성에 따른 차등적 TTL 전략
- • Pub/Sub 기반 캐시 무효화 패턴
쿠팡이나 11번가 같은 대규모 전자상거래 플랫폼의 상품 카탈로그 시스템에서 사용됩니다.
캐시 스탬피드 현상이 발생할 수 있는 시나리오와 이를 방지하기 위한 전략은 무엇인가요?
Q. 10개의 마이크로서비스로 구성된 시스템에서 서비스 간 통신을 동기(REST/gRPC)와 비동기(Pub/Sub) 중 어떤 방식으로 설계할지 결정하는 기준과, GCP에서 구현 시 고려사항을 설명해주세요.
각 통신 방식의 장단점과 서비스 간 결합도, 장애 전파, 트랜잭션 요구사항을 고려하세요.
동기 통신은 즉각적인 응답이 필요하거나 트랜잭션 일관성이 중요할 때 사용하며, gRPC with Cloud Run이 효율적입니다. 비동기 통신은 서비스 간 결합도를 낮추고 장애 격리가 필요할 때 Pub/Sub를 사용합니다. 예를 들어 주문 생성 시 결제 서비스는 동기(즉시 승인 필요), 재고 차감과 알림 발송은 비동기로 처리합니다. Cloud Trace와 Cloud Logging을 통해 분산 트랜잭션을 추적하고, Circuit Breaker 패턴을 구현하여 장애 전파를 방지합니다. Pub/Sub는 최소 한 번 전달을 보장하므로 멱등성 처리가 필수이며, Dead Letter Topic을 구성하여 실패한 메시지를 재처리합니다. API 게이트웨이에서는 동기 호출에 타임아웃을 5초 이하로 설정하여 캐스케이딩 실패를 방지합니다.
- • 비즈니스 요구사항에 따른 통신 패턴 선택
- • 동기는 일관성, 비동기는 확장성과 장애 격리
- • 멱등성과 재시도 메커니즘 구현
- • 분산 추적과 Circuit Breaker를 통한 안정성 확보
배달의민족이나 카카오뱅크 같은 대규모 마이크로서비스 아키텍처에서 서비스 간 통신 설계 시 적용됩니다.
Saga 패턴을 사용한 분산 트랜잭션을 GCP에서 구현한다면 어떤 서비스들을 조합하시겠습니까?
Q. 특정 시간대(오후 6~8시)에 트래픽이 평소의 10배로 증가하는 배달 앱 백엔드를 GCP에서 설계할 때, 어떤 오토스케일링 전략과 서비스 구성을 사용하시겠습니까?
예측 가능한 트래픽 패턴에 대한 사전 준비와 비용 최적화를 함께 고려하세요.
Cloud Run 또는 GKE Autopilot을 사용하여 컨테이너 기반으로 구성하고, 예측 가능한 피크 시간 30분 전에 Scheduled Scaling으로 최소 인스턴스 수를 사전에 증가시킵니다. Cloud Run은 동시성 설정을 80으로 조정하고, 최소 인스턴스를 피크 시간에는 20개, 평시에는 2개로 설정합니다. Cloud SQL은 읽기 레플리카를 피크 시간에 자동으로 추가하도록 구성하고, Connection Pooling을 PgBouncer로 관리합니다. Memorystore는 Standard Tier로 고가용성을 확보하고, 피크 시간 전에 워밍업 스크립트로 주요 데이터를 미리 캐싱합니다. Cloud Monitoring의 커스텀 메트릭으로 응답 시간과 에러율을 모니터링하며, 임계값 초과 시 알림을 받습니다.
- • Scheduled Scaling을 통한 사전 대비
- • 최소 인스턴스 수 조정으로 콜드 스타트 방지
- • 데이터베이스 커넥션 풀링과 읽기 레플리카 활용
- • 캐시 워밍업을 통한 피크 시간 대응
배민, 쿠팡이츠 같은 배달 플랫폼에서 저녁 식사 시간대 트래픽 급증 대응에 사용됩니다.
갑작스러운 이벤트로 예상치 못한 트래픽 급증이 발생했을 때 어떻게 대응하시겠습니까?
Q. 사용자별로 개인화된 피드를 제공하는 소셜 미디어 앱에서 효율적인 캐싱 전략을 설계한다면, 어떤 계층에 어떤 방식으로 캐싱을 적용하시겠습니까?
개인화 데이터의 특성상 공유 캐시와 개인 캐시의 차이, 그리고 캐시 계층화를 생각해보세요.
3계층 캐싱 전략을 적용합니다. 첫째, 브라우저/앱 레벨에서 프로필 이미지와 정적 콘텐츠를 Cache-Control 헤더로 캐싱합니다. 둘째, Cloud CDN에서 공개 콘텐츠와 인기 게시물을 캐싱하되, Vary 헤더로 사용자 인증 상태를 구분합니다. 셋째, Memorystore에 사용자별 피드 데이터를 키-값으로 저장하며, 키 형식은 'feed:user_id:page_number'로 구성합니다. 피드는 최신 50개 항목만 캐싱하고 TTL은 5분으로 설정합니다. 새 게시물 작성 시 Pub/Sub로 팔로워들의 피드 캐시를 비동기로 무효화하며, Write-Through 패턴으로 즉시 업데이트합니다. 캐시 히트율은 Cloud Monitoring으로 추적하여 70% 이상 유지합니다.
- • 계층별 캐싱 전략 차별화
- • 개인화 데이터는 Memorystore에 사용자별 키로 관리
- • Write-Through 패턴으로 일관성 유지
- • Pub/Sub 기반 비동기 캐시 무효화
인스타그램, 페이스북 같은 소셜 미디어의 개인화 피드 시스템에서 사용됩니다.
캐시 메모리가 부족할 때 어떤 eviction 정책을 사용하고, GCP에서는 어떻게 구성하나요?
Q. 실시간 로그 분석 시스템을 구축할 때, 초당 10만 건의 이벤트를 수집하여 BigQuery에 저장하고 실시간 대시보드를 제공하는 아키텍처를 설계해주세요. Dataflow와 Pub/Sub를 어떻게 활용하시겠습니까?
스트리밍 데이터의 처리 지연, 배치 처리, 비용 최적화를 모두 고려하세요.
클라이언트에서 Pub/Sub로 로그를 전송하고, Dataflow Streaming 파이프라인으로 실시간 처리합니다. Dataflow에서는 윈도우를 1분 단위로 설정하여 집계하고, 중복 제거를 위해 이벤트 ID 기반 Deduplication을 적용합니다. 처리된 데이터는 BigQuery Streaming Insert로 즉시 적재하되, 비용 절감을 위해 5분마다 배치로 묶어서 삽입합니다. 실시간 대시보드는 BigQuery의 Materialized View로 사전 집계된 데이터를 조회하여 쿼리 성능을 최적화합니다. 원본 로그는 Cloud Storage에 Parquet 형식으로 백업하고, BigQuery External Table로 연결하여 장기 분석에 활용합니다. Dataflow 워커는 n1-standard-2 머신 타입으로 시작하고, 오토스케일링 최대값은 50으로 제한하여 비용을 관리합니다.
- • Pub/Sub와 Dataflow를 통한 스트리밍 처리
- • 윈도우 집계와 중복 제거로 데이터 품질 확보
- • BigQuery Streaming Insert와 배치 처리의 하이브리드
- • Materialized View로 대시보드 성능 최적화
네이버나 카카오의 서비스 로그 분석, 실시간 모니터링 대시보드 구축에 사용됩니다.
Dataflow 파이프라인에서 처리 지연이 발생하여 backlog가 쌓이는 상황을 어떻게 모니터링하고 대응하시겠습니까?
Q. 민감한 개인정보를 처리하는 헬스케어 API를 GCP에서 구축할 때, 네트워크 격리, 인증/인가, 데이터 암호화를 어떻게 설계하시겠습니까?
제로 트러스트 원칙과 GCP의 보안 서비스들을 활용한 다층 방어를 생각해보세요.
VPC 내부에 Private Subnet을 구성하고, Cloud Run 또는 GKE를 내부 전용 로드밸런서로 배치하여 인터넷 직접 노출을 차단합니다. 외부 접근은 Cloud Armor와 Identity-Aware Proxy를 통해서만 허용하며, API 인증은 OAuth 2.0과 JWT를 사용합니다. Cloud KMS로 암호화 키를 관리하고, 데이터베이스의 민감 컬럼은 애플리케이션 레벨에서 암호화합니다. Secret Manager에 API 키와 DB 비밀번호를 저장하고, Workload Identity로 서비스 간 인증을 처리합니다. VPC Service Controls로 데이터 유출을 방지하고, Cloud DLP로 민감 정보를 자동 탐지 및 마스킹합니다. 모든 API 호출은 Cloud Logging으로 감사 로그를 남기고, Security Command Center로 보안 위협을 모니터링합니다.
- • Private Subnet과 내부 로드밸런서로 네트워크 격리
- • IAP와 Cloud Armor를 통한 접근 제어
- • Cloud KMS와 애플리케이션 레벨 암호화
- • VPC Service Controls와 Cloud DLP로 데이터 보호
병원 EMR 시스템, 건강검진 앱, 의료 데이터 플랫폼에서 필수적으로 적용되는 보안 아키텍처입니다.
HIPAA 또는 GDPR 컴플라이언스를 준수하기 위해 추가로 고려해야 할 사항은 무엇인가요?
Q. 글로벌 사용자를 대상으로 하는 게임 리더보드 시스템을 설계할 때, 지연 시간 최소화와 데이터 일관성을 어떻게 균형있게 설계하시겠습니까? GCP의 멀티 리전 서비스를 활용한 아키텍처를 제안해주세요.
글로벌 분산과 강한 일관성의 트레이드오프, 그리고 게임 특성상 허용 가능한 일관성 수준을 고려하세요.
Cloud Spanner를 멀티 리전 구성으로 사용하여 강한 일관성을 유지하면서 글로벌 읽기 성능을 확보합니다. 리더보드 조회는 Stale Read(최대 10초 지연 허용)로 처리하여 성능을 높이고, 점수 업데이트는 Strong Consistency로 처리합니다. 각 리전에 Cloud Run 인스턴스를 배포하고, Global Load Balancing으로 사용자를 가장 가까운 리전으로 라우팅합니다. 실시간 순위는 각 리전의 Memorystore에 캐싱하고, 5분마다 Spanner에서 동기화하여 최신 상태를 유지합니다. 글로벌 Top 100은 Cloud CDN에 1분 TTL로 캐싱하여 읽기 부하를 줄입니다. 리전 간 점수 집계는 Pub/Sub의 멀티 리전 토픽으로 이벤트를 전파하고, Dataflow로 일괄 처리합니다. 장애 발생 시 Traffic Director로 자동으로 다른 리전으로 페일오버합니다.
- • Cloud Spanner의 멀티 리전과 Stale Read 활용
- • 리전별 캐싱과 글로벌 CDN의 조합
- • 읽기는 최종 일관성, 쓰기는 강한 일관성으로 분리
- • Global Load Balancing과 Traffic Director로 고가용성 확보
리그오브레전드, 배틀그라운드 같은 글로벌 게임의 실시간 리더보드 시스템에서 사용됩니다.
특정 리전에서 Spanner 장애가 발생했을 때 사용자 경험을 유지하기 위한 fallback 전략은 무엇인가요?
Q. 월 GCP 비용이 5천만원인 서비스에서 30% 비용 절감 목표가 주어졌을 때, 성능과 가용성을 유지하면서 어떤 영역에서 어떻게 최적화하시겠습니까?
컴퓨팅, 스토리지, 네트워크, 데이터베이스 각 영역의 비용 구조와 최적화 방법을 검토하세요.
먼저 Cost Breakdown 분석으로 비용 상위 5개 서비스를 파악합니다. 컴퓨팅은 Cloud Run의 최소 인스턴스를 줄이고 요청 기반 스케일링으로 전환하며, 개발/스테이징 환경은 야간과 주말에 자동 종료합니다. GKE는 Spot VM과 Preemptible Node를 활용하여 비용을 60% 절감하되, Stateless 워크로드에만 적용합니다. 스토리지는 Cloud Storage의 수명주기 정책으로 30일 이상 된 데이터를 Nearline으로, 90일 이상은 Coldline으로 이동합니다. BigQuery는 파티셔닝과 클러스터링으로 스캔 데이터량을 줄이고, Flat-rate Pricing을 검토합니다. 네트워크는 Cloud CDN과 Memorystore로 외부 트래픽을 줄이고, 리전 간 데이터 전송을 최소화합니다. Committed Use Discounts를 1년 약정으로 구매하여 추가 20% 할인을 받습니다.
- • Cost Breakdown으로 주요 비용 영역 파악
- • Spot VM과 수명주기 정책으로 인프라 비용 절감
- • 쿼리 최적화와 캐싱으로 데이터 처리 비용 감소
- • Committed Use Discounts로 장기 할인 확보
스타트업이나 성장기 기업에서 투자 유치 후 Burn Rate를 줄이기 위한 비용 최적화 프로젝트에서 적용됩니다.
비용 최적화 후 성능 저하나 장애가 발생하지 않도록 어떤 모니터링과 알림을 설정하시겠습니까?
Q. RTO 1시간, RPO 15분 요구사항을 가진 금융 서비스를 GCP에서 운영할 때, 재해 복구 아키텍처를 어떻게 설계하고 정기적으로 어떻게 검증하시겠습니까?
백업 전략, 멀티 리전 구성, 페일오버 자동화, 그리고 DR 훈련의 중요성을 고려하세요.
Primary 리전(서울)과 DR 리전(도쿄)에 동일한 아키텍처를 구성하고, Cloud SQL은 Cross-Region Replica로 15분 간격 복제를 설정합니다. Cloud Storage는 Dual-Region 버킷으로 자동 복제하고, 애플리케이션 코드는 Cloud Source Repository에서 멀티 리전으로 관리합니다. Terraform으로 인프라를 코드화하여 DR 리전에 30분 내 재배포 가능하도록 준비합니다. Global Load Balancing의 Health Check로 Primary 리전 장애를 감지하면 자동으로 DR 리전으로 트래픽을 전환합니다. 데이터베이스는 Point-in-Time Recovery를 활성화하여 15분 단위로 복구 가능합니다. 월 1회 DR 훈련을 실시하여 실제 페일오버를 수행하고, RTO/RPO 목표 달성 여부를 측정합니다. Cloud Monitoring의 Uptime Check와 SLO 모니터링으로 가용성을 추적하고, 장애 시나리오별 Runbook을 문서화합니다.
- • 멀티 리전 구성과 Cross-Region Replica
- • IaC로 빠른 인프라 재구성
- • 자동 페일오버와 Health Check
- • 정기적인 DR 훈련과 RTO/RPO 검증
은행, 증권사, 보험사 등 금융권에서 법적 요구사항을 충족하기 위한 재해 복구 시스템 구축에 필수적입니다.
DR 훈련 중 예상치 못한 문제가 발견되었을 때 어떤 프로세스로 개선하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!