Backing Service란?(개념)

medires

MSA(Microservices Architecture)에서 Backing Service는 매우 중요한 개념 중 하나야. 직무역량 시험이나 실무에서도 자주 등장하는 주제니까, 기초부터 실전까지 차근차근 정리해줄게.

✅ 1. "Backing Service"란?

내 서비스가 필요로 하는 '외부 기능을 대신해주는 서비스'

🔧 쉽게 말하면…

내가 웹사이트나 앱을 만들고 있다고 생각해보세요. 그런데 이 앱이 이메일을 보내고, 파일을 저장하고, 데이터를 저장해야 합니다.

그런데!
❌ 직접 이메일 보내는 코드? 너무 복잡해!
❌ 파일 저장 시스템? 직접 만들기엔 무거워!
❌ DB 서버? 설정하고 유지하려면 시간과 비용이 많이 들어!

👉 그래서 우리는 **이미 잘 만들어진 서비스(Backing Service)**를 '외부에서 빌려와서' 사용하는 것입니다.

✅ 2. 예시로 한눈에 보기

기능내가 할 수 없어서 빌리는 서비스 = Backing Service

사용자 로그인	Keycloak, Auth0
데이터 저장	MySQL, PostgreSQL (RDS)
캐시	Redis, Memcached
메시지 큐	Kafka, RabbitMQ
로그 수집	ELK Stack, Loki
파일 저장	AWS S3, Azure Blob
알림 전송	Firebase, SendGrid

즉, 앱과는 분리되어 있지만, 꼭 필요한 서비스들이에요!

✅ 3. 왜 중요한가요? (실무 포인트)

🔹 분리와 바인딩 (12 Factor App 원칙)

앱과 백엔드 서비스를 느슨하게 연결(loose coupling) 해야 함
주소, 인증 정보 등은 **환경변수(ENV)**로 분리 관리

예: REDIS_URL=redis://10.0.0.3:6379 ← 이걸 코드에 직접 쓰지 말고 ENV로!

✅ 4. 실무 시나리오로 정리해볼게요

🧩 시나리오: 쇼핑몰 웹서비스 운영 중

DB로는 AWS RDS (MySQL) 사용
상품 썸네일 이미지는 S3에 저장
주문 발생 시 메시지는 Kafka로 전달
로그는 Loki로 수집

🟰 이때 이 모든 것들이 Backing Services입니다.
이런 구조를 그림으로 보면 다음과 같아요:

[사용자] ─▶ [웹 서비스] │ ┌──────────┼─────────────┐ ▼ ▼ ▼ [RDS] [S3] [Kafka] │ ▼ [이미지] [메시지 처리 시스템]

✅ 5. 자주 나오는 오해

❌ 오해✅ 정답

Backing Service는 내 앱 코드 안에 들어있다?	❌ 아니다! 외부에 따로 존재하는 리소스다
서비스마다 하나씩 직접 만들어야 한다?	❌ 대부분 클라우드에 이미 준비되어 있음 (RDS, S3, Redis 등)
내 앱과 백엔드 서비스를 완전히 붙여야 한다?	❌ 바인딩은 환경 변수 또는 설정 파일로 해야 한다

✅ 6. 암기 카드 요약

키워드설명

📦 Backing Service	내 앱이 사용하는 외부 리소스 (DB, MQ, Cache 등)
🔧 예시	Redis, Kafka, RDS, S3, Auth0
⚙️ 원칙	앱 코드와 분리, 바인딩은 설정(ENV 등)으로
🧠 기억법	“내가 만들기 힘드니까 대신 해주는 서비스”
🛠️ 실무 팁	클라우드에서는 RDS/S3 같은 관리형 서비스로 제공됨

✅ 1단계: 개념 정리 (입문~중급)

📌 [Backing Service란?]

MSA에서 Backing Service는 어플리케이션이 네트워크를 통해 접근하는 외부 종속 서비스들을 의미해.
대표적인 예는 다음과 같아:

종류예시

데이터 저장소	MySQL, PostgreSQL, MongoDB 등
메시지 브로커	Kafka, RabbitMQ, Amazon SQS 등
캐시 시스템	Redis, Memcached 등
외부 API	결제 API(PayPal, Stripe), 인증 API 등
파일 스토리지	AWS S3, GCP Cloud Storage 등

📌 [12-Factor App에서의 Backing Service]

"Treat backing services as attached resources."

앱은 로컬/외부 백엔드 서비스를 구분하지 않고 동일한 방식으로 접근해야 한다.
서비스는 바인딩만 바꾸면 (예: 환경변수로 접속 정보 제공), 무중단으로 교체 가능해야 한다.

예:

bash

복사편집

DATABASE_URL=postgres://user:pass@dbhost:5432/dbname REDIS_URL=redis://redis-host:6379

✅ 2단계: 실무 적용

📌 [실무에서 Backing Service 활용 방법]

마이크로서비스 간 결합도 낮추기 위해 메시징 큐 사용
DB 연결은 Connection Pool 및 Circuit Breaker 패턴 적용
비동기 처리를 위해 Backing Service로 Event-driven 아키텍처 구축

✅ 3단계: 실전 사례

🎯 [예제 시나리오]

주문(Order) 서비스가 다음 Backing Service들을 사용:

PostgreSQL: 주문 DB 저장소
Kafka: 결제 서비스에 이벤트 전송
Redis: 최근 주문 내역 캐시

🎯 [설계 원칙]

각 서비스는 Backing Service를 외부 종속성으로 바인딩
장애 발생 시 대체 가능하도록 추상화 계층 도입 (예: DAO, Repository Layer)
환경변수 또는 서비스 디스커버리로 위치 정보 주입

✅ 4단계: 직무역량 문제 예시

Q1. MSA 환경에서 Backing Service에 해당하는 것을 모두 고르시오.

a) Redis
b) Kafka
c) Frontend SPA(Vue.js)
d) AWS S3

정답: a, b, d

프론트엔드는 백엔드에서 접근하는 종속 리소스가 아니므로 제외.

Q2. Backing Service를 외부 리소스로 취급할 때 얻을 수 있는 이점 2가지를 설명하시오.

예시 답변:

서비스 간 결합도를 낮추고, 특정 리소스 장애 시 교체가 용이하다.
다양한 환경(로컬, 테스트, 운영)에서 동일한 방식으로 리소스를 바인딩할 수 있다.

✅ 5단계: 고급 트러블슈팅

💥 실전 장애 시나리오

Redis를 Backing Service로 쓰는 주문 API가 캐시 조회 실패로 느려짐

분석 포인트:

Redis 연결 상태 및 timeout 확인
Circuit Breaker 또는 fallback 로직 존재 여부 점검
Redis 서버 장애 시 graceful degradation 정책 설계 여부

필요하다면 실습 예제나 아키텍처 설계 훈련도 이어서 도와줄게.
👉 다음 단계로 실전 설계 예제나 시나리오 기반 문제 학습할까?

🧩 [실전 시나리오 기반 설계 과제]

🧪 시나리오 1: 주문 서비스의 Backing Service 설계

배경:
쇼핑몰의 주문(Order) 마이크로서비스는 다음과 같은 백엔드 리소스를 활용해야 한다.

주문 정보 저장용 DB (PostgreSQL)
결제 완료 후 알림 전송용 메시지 큐 (Kafka)
최근 주문 목록 캐시 (Redis)
이미지 저장용 파일 스토리지 (S3)

🎯 과제:

각 리소스를 어떻게 Backing Service로 추상화할지 아키텍처 다이어그램을 설계하시오.
장애 복구와 환경별 배포를 고려한 Backing Service 구성 전략을 서술하시오.
환경변수를 활용한 설정 예시를 작성하시오.

✅ 예시 해답 요약:

1. 아키텍처 구성 요소 예시:

API Gateway → Order Service
Order Service 내부에:
- Repository Layer (PostgreSQL 접속)
- Kafka Producer (비동기 결제 이벤트 전송)
- Redis Client (주문 캐시)
- S3 Uploader

2. 구성 전략:

모든 Backing Service는 서비스 내부에서 직접 접근하지 않고 인터페이스 레이어를 통해 접근
장애 시 Circuit Breaker / Fallback 적용
DATABASE_URL, REDIS_URL, KAFKA_BOOTSTRAP_SERVERS, S3_BUCKET 등은 환경변수로 주입

3. 설정 예시 (환경 변수):

env

복사편집

DATABASE_URL=postgres://order_user:pass@db:5432/orderdb REDIS_URL=redis://cache:6379 KAFKA_BOOTSTRAP_SERVERS=kafka1:9092,kafka2:9092 S3_BUCKET=order-files

🧠 [문제 1] 장애 대응 설계 문제

문제:
Kafka 브로커가 일시적으로 다운되어 주문 이벤트가 발송되지 못하는 상황이다. 이 때 Order 서비스는 어떻게 동작해야 하는가? 올바른 대응 방식을 모두 고르시오.

a) 주문 저장도 실패시킨다
b) Kafka 전송 실패 시 재시도 로직을 포함한다
c) Kafka 실패 시 Dead Letter Queue로 이벤트를 보낸다
d) Kafka 의존성을 제거하고 S3로 이벤트를 기록한다

정답: b, c

a는 불필요한 Coupling이며, d는 이상적인 설계가 아니다.

🧠 [문제 2] 환경별 Backing Service 분리 설계

문제:
개발(dev), 테스트(test), 운영(prod) 환경에서 각각 다른 Redis 클러스터를 사용해야 한다. 이를 환경별로 안전하게 구성하려면 어떤 방법을 써야 하는가?

a) 코드에 Redis 주소를 하드코딩
b) 환경별 application.yml 또는 .env 파일 관리
c) 클러스터 간 DNS로 분기
d) 서비스 디스커버리로 동적 바인딩

정답: b, d

a는 유지보수 문제, c는 일부 환경에서는 유효하나 권장 방식은 아님.

🧠 [문제 3] Backing Service 교체 설계

문제:
현재 Redis를 사용 중인 캐시 백엔드를 Memcached로 교체하고자 한다. 이때 서비스 코드가 변경되지 않게 하려면 어떤 설계 패턴이 필요한가?

a) 직접 Redis Client를 서비스 로직에 삽입
b) 캐시 인터페이스 계층을 추상화
c) 공통 캐시 Adapter 레이어를 구현
d) DB에 캐시 기능을 직접 추가

정답: b, c

추상화를 통해 종속성을 제거하고 유연한 교체 가능

📘 [추가 실습 제안]

🛠 실습 과제: MSA 환경에서 Backing Service 적용 실습

간단한 Node.js 또는 Spring Boot 마이크로서비스를 작성
Redis와 PostgreSQL을 Backing Service로 연동
.env 파일을 통해 환경에 따라 리소스를 바꾸는 방식 실습
Redis 장애 시 fallback 로직 구현

필요하다면 이 중 한 가지 시나리오를 직접 실습용 코드나 YAML 템플릿으로 구현해줄 수 있어.
👉 특정 기술 스택(Spring, Node.js, Docker 등)으로 실습 예제를 도와줄까?

🧠 [Backing Service] 실무 및 TA 역량평가 예상문제 (10문항)

✅ NO.01 [개념 이해 / 난이도: 하]

다음 중 Backing Service의 정의로 가장 적절한 것은?

① 애플리케이션 내부에서 동작하는 API 서비스
② 사용자의 요청을 직접 처리하는 컨트롤러 서비스
③ 애플리케이션 외부에서 바인딩되어 사용되는 리소스 서비스
④ 컨테이너에 내장된 로그 수집 모듈
⑤ WAS에서 직접 관리하는 세션 캐시

정답: ③
해설: Backing Service는 앱 외부에 존재하며, DB, 캐시, MQ, 로그 수집 등 필요한 기능을 바인딩 형태로 제공한다.

✅ NO.02 [실무 적용 / 난이도: 중]

12 Factor App 원칙에 따라 Backing Service를 올바르게 사용하는 방법은?

① 애플리케이션 코드 내에 DB 접속 정보를 하드코딩한다.
② S3의 접근키를 깃 저장소에 함께 커밋한다.
③ Redis 주소와 인증정보를 환경변수로 분리한다.
④ 외부 서비스가 아닌 내부 모듈로 처리하도록 통합한다.
⑤ 인증 토큰을 서비스별로 고정값으로 설정한다.

정답: ③
해설: 외부 Backing Service는 바인딩된 리소스이므로 접속 정보는 코드가 아닌 환경변수나 설정파일로 관리해야 한다.

✅ NO.03 [구성 비교 / 난이도: 중]

아래 중 Backing Service로 분류되기 어려운 것은?

① PostgreSQL (RDS)
② Kafka 메시지 큐
③ React SPA 프론트엔드
④ Redis 캐시 서버
⑤ S3 오브젝트 스토리지

정답: ③
해설: React SPA는 프론트엔드 코드로, 백엔드 기능을 제공하지 않으며 외부 리소스가 아님.

✅ NO.04 [장애 시나리오 / 난이도: 중상]

다음은 Backing Service 장애 시 조치 방안 중 부적절한 것은?

① Redis 장애 시 애플리케이션이 즉시 종료되도록 구성한다.
② DB 연결 실패 시 일정 횟수 재시도를 구현한다.
③ Kafka 장애 시 메시지를 로컬에 임시 저장하도록 한다.
④ S3 업로드 실패 시 재시도 후 에러 로깅 처리한다.
⑤ 로그 수집기(Loki) 장애 시 서비스 기능은 계속 제공한다.

정답: ①
해설: Backing Service 장애는 일시적일 수 있으며, 앱 전체를 중단시키는 대신 재시도, Graceful Degradation 등이 바람직하다.

✅ NO.05 [클라우드 실무 / 난이도: 중]

클라우드 환경에서 Backing Service로 가장 적합한 관리형 서비스 조합은?

① EC2 + NGINX
② Lambda + API Gateway
③ EKS + RDS + S3 + MSK
④ VPC Peering + NAT Gateway
⑤ VPC + Autoscaling Group

정답: ③
해설: RDS(DB), S3(저장소), MSK(Kafka)는 모두 앱 외부에서 제공되는 Backing Service에 해당한다.

✅ NO.06 [보안 / 난이도: 중상]

백엔드 서비스에서 S3, RDS, Redis 등의 Backing Service를 구성할 때 보안상 유의할 점으로 올바른 것은?

① 애플리케이션 코드에 인증정보를 직접 명시한다.
② 서비스 계정을 IAM Admin 권한으로 구성한다.
③ 접근을 모든 퍼블릭 IP에 허용한다.
④ 서비스 간 통신은 TLS 또는 Private Subnet을 사용한다.
⑤ 접근 제어 없이 open redis 구성을 사용한다.

정답: ④
해설: Backing Service는 인증정보 보호, 접근 제어, TLS 암호화 등을 통해 보안 통신을 유지해야 한다.**

✅ NO.07 [서비스 바인딩 / 난이도: 중]

서비스 바인딩(Service Binding) 시 일반적으로 사용하는 방법은?

① OAuth 연동
② DNS 라운드로빈 설정
③ 서비스 정보 주입을 위한 환경변수 또는 ConfigMap 사용
④ Kafka 토픽 자동 분산
⑤ API Gateway에 TLS 인증서 적용

정답: ③
해설: 앱에서 Backing Service를 사용하기 위한 접근 정보는 환경변수(ENV)**, Kubernetes ConfigMap/Secret 등을 통해 주입된다.

✅ NO.08 [장애 복구 전략 / 난이도: 상]

Redis를 Backing Service로 사용하는 MSA 환경에서 장애 발생 시 가장 적절한 장애 대응 전략은?

① 캐시 장애는 복구될 때까지 서비스 중단
② 캐시 없이 처리가 불가능하도록 강제종료 처리
③ 캐시 미사용 시 디폴트 값 반환 후 로깅
④ 클라이언트가 직접 캐시 재구축
⑤ 서비스 간 캐시 공유를 위해 모든 인스턴스에 파일 시스템 동기화

정답: ③
해설: Redis는 보통 캐시이므로 장애 시에도 서비스 기능이 지속되도록 fallback 처리하는 것이 일반적**이다.

✅ NO.09 [애플리케이션 배포 / 난이도: 중]

다음 중 Backing Service를 고려하여 Helm 차트를 구성할 때 가장 올바른 전략은?

① Redis 주소를 values.yaml 외부에 하드코딩
② DB 주소를 고정 IP로 명시
③ 서비스 간 인증정보를 chart 내부에 포함
④ 외부 서비스 정보를 변수화하고 Secret 또는 ConfigMap으로 분리
⑤ Kafka 토픽을 직접 chart에 명시적으로 생성

정답: ④
해설: Backing Service 관련 설정은 Helm values.yaml에 변수화 후 Kubernetes Secret 또는 ConfigMap으로 주입하여 관리한다.

✅ NO.10 [추상화 설계 / 난이도: 상]

아래 설명 중 Backing Service의 추상화와 가장 거리가 먼 것은?

① 서비스의 실제 위치(IP/PORT)를 ENV로 분리
② 서비스 연결을 Interface로 정의하여 교체 가능하게 함
③ 서비스 로직을 클라이언트 코드에 직접 구현
④ 인증/인증 토큰을 외부 Vault 서비스에서 관리
⑤ 장애 시 fallback을 구현하여 서비스 기능을 유지

정답: ③
해설: 외부 서비스 로직은 클라이언트에 직접 구현하는 것이 아니라 추상화하고, 위치나 보안 정보는 외부에서 관리해야 한다.

📌 총정리 키워드

Backing Service = 외부 리소스 (DB, MQ, Cache, Storage 등)
12 Factor 원칙 = 바인딩은 ENV로 관리
보안 고려 = 인증정보 분리, TLS, 접근제어
장애 대응 = fallback 처리, 재시도, 로깅
실무 구성 = ConfigMap, Secret, Helm values

필요하시면 위 내용을 기반으로 PDF, Word, Markdown, 암기카드, 문제집 템플릿으로도 변환해드릴 수 있어요.
또는 **실전 장애 시나리오 기반 문제(예: Redis 연결 오류 발생 시 재시도/복구 방법)**로 확장해드릴 수도 있습니다.
어떤 형태로 이어서 도와드릴까요?

나의 말:

실전 장애 시나리오 기반 문제(예: Redis 연결 오류 발생 시 재시도/복구 방법)으로 확장해줘

ChatGPT의 말:

좋습니다!
다음은 Backing Service 실전 장애 시나리오 기반 문제집 (TA 실무 역량 평가용) 확장 버전입니다.
문제 유형은 시나리오 기반 객관식 및 단답형 혼합이며, 정답 + 상세 해설도 포함되어 있습니다.

🛠 Backing Service 실전 장애 시나리오 기반 문제집 (10문항)

✅ NO.01 [Redis 연결 오류 / 난이도: 중]

시나리오:
AP 서버가 Redis 캐시를 사용하는 중, 외부 Redis 서버와의 연결이 일시적으로 끊겼다. 해당 장애가 발생하자 앱은 전체 요청에 대해 HTTP 500 오류를 반환하였다.

질문:
가장 적절한 개선 방안은?

① 캐시 의존 로직 제거
② Redis 재시작 시까지 요청 중단
③ 캐시 미사용 시 DB 조회 후 결과 반환
④ 연결 실패 시 서비스 종료

정답: ③
해설: 캐시는 비필수 요소이므로 장애 발생 시 fallback 로직을 통해 DB에서 직접 조회하고, 캐시는 이후 갱신하는 방식이 바람직하다.

✅ NO.02 [Kafka 메시지 누락 / 난이도: 상]

시나리오:
주문 처리 시스템이 Kafka에 메시지를 전송하던 중, Kafka 브로커 장애가 발생해 메시지가 유실되었다. 이후 일부 주문이 처리되지 않아 고객 민원이 발생하였다.

질문:
아래 중 가장 적절한 보완책은?

① Kafka 장애 시 예외를 무시하고 계속 진행
② 메시지 전송 실패 시 로컬 디스크 또는 큐에 임시 저장
③ Kafka 전송 성공 여부와 무관하게 주문 완료 처리
④ 메시지 재전송 로직을 서비스 코드에 직접 구현

정답: ②
해설: Kafka 장애 시에도 업무 처리를 위해 메시지를 로컬 임시 저장하고, 후속 복구 절차에서 재처리하는 전략이 필요하다.

✅ NO.03 [RDS 재시작 후 연결 실패 / 난이도: 중상]

시나리오:
AWS RDS를 사용하던 애플리케이션이 RDS 재시작 이후 연결 실패 상태로 몇 분간 장애가 지속되었다.
확인 결과, 애플리케이션의 DB 연결이 실패 후 바로 종료되는 구조였다.

질문:
장애 최소화를 위한 개선 방안으로 가장 적절한 것은?

① DB 연결 실패 시 즉시 서비스 종료
② DB 장애 시 캐시로 대체
③ DB 연결 실패 시 일정 시간 간격으로 재시도
④ 연결 오류 발생 시 알람만 발생시키고 무시

정답: ③
해설: DB와 같은 필수 Backing Service는 장애 발생 시에도 일정 시간 재시도를 하여 일시적 장애를 흡수해야 한다.

✅ NO.04 [S3 업로드 지연 / 난이도: 중]

시나리오:
상품 이미지 업로드 시 S3에 5~10초 지연이 발생하여 사용자가 기다려야 하는 상황 발생.
프론트엔드에서 업로드 완료까지 Blocking 처리 중이다.

질문:
UX 개선을 위한 적절한 백엔드 처리 방안은?

① 업로드 완료 후 사용자에게 결과 표시
② 이미지 업로드를 백그라운드 작업으로 전환
③ 사용자가 재시도하도록 안내만 제공
④ 이미지 저장을 포기하고 오류를 반환

정답: ②
해설: 이미지 업로드와 같은 작업은 S3 응답에 blocking되지 않도록 비동기 처리하거나 백그라운드 Job Queue로 분리하는 것이 좋다.

✅ NO.05 [로그 수집기(Loki) 장애 / 난이도: 하]

시나리오:
Loki 로그 수집기가 장애로 인해 로그를 수신하지 못하는 상황에서, 애플리케이션이 로그 전송 실패로 예외를 발생시키고 서비스가 종료됨.

질문:
가장 적절한 조치는?

① 로그 전송 실패 시 앱 종료
② 로그 전송을 필수 처리로 간주
③ 로그 실패 시 로컬 저장 후 백업 전송
④ 로그 실패 시 무시하고 서비스 지속

정답: ④
해설: 로그 수집은 비필수 Backing Service이므로, 서비스 가용성에 영향을 주지 않도록 비동기 처리하고 실패를 무시해야 한다.

✅ NO.06 [DB와 Redis 이중 장애 / 난이도: 상]

시나리오:
트래픽 급증 중 DB와 Redis가 동시에 장애 발생. DB는 3분 후 복구, Redis는 10분 후 복구. 해당 시간 동안 서비스는 전체 중단 상태.

질문:
장애 복구 전략으로 가장 적절한 것은?

① 모든 요청 중단 후 복구될 때까지 대기
② 캐시 실패 시 DB fallback 구조 적용
③ 둘 다 실패 시 예외 반환
④ Redis가 복구될 때까지 로직을 대기시킴

정답: ②
해설: Redis 장애 시에도 DB가 가능하다면 fallback 처리하고, 반대의 경우에도 하나의 서비스 실패가 전체 서비스 중단을 초래하지 않도록 구조 설계해야 한다.

✅ NO.07 [Vault 인증 서버 장애 / 난이도: 중상]

시나리오:
애플리케이션이 Redis, DB 등의 Backing Service 연결정보를 HashiCorp Vault에서 주입받도록 구성되어 있음. Vault 인증 토큰이 만료되었지만 앱이 이를 갱신하지 못해 모든 Backing Service 연결에 실패.

질문:
가장 적절한 개선 방안은?

① Vault 연동을 제거
② Vault 갱신 실패 시 앱 종료
③ 인증 토큰 자동 갱신 로직 구현
④ Vault를 직접 앱 내부에 포함

정답: ③
해설: 보안 비밀(Secret)을 Vault 등에서 가져올 경우 토큰 자동 갱신 처리를 하지 않으면 장애 가능성이 있다.

✅ NO.08 [환경변수 오타로 인해 S3 접근 불가 / 난이도: 중]

시나리오:
운영 배포 중 S3_BUCKET_NAME 환경변수 오타(S3_BUCKET_NAM)로 인해 이미지 업로드가 모두 실패. 원인은 배포 후 1시간 뒤 발견됨.

질문:
이와 같은 실수를 방지하기 위한 방안은?

① 환경변수를 앱 내부에서 고정값으로 처리
② ConfigMap 사용을 중단
③ 런타임 환경변수 유효성 검사 로직 구현
④ 모든 환경변수를 Secrets로만 관리

정답: ③
해설: 앱 시작 시 환경변수 존재 및 값 유효성 검사를 하는 초기화 체크 로직을 구현해야 예방 가능.

✅ NO.09 [서비스 메시 구성 시 백엔드 타임아웃 / 난이도: 상]

시나리오:
Istio 기반 서비스 메시 환경에서, Redis 및 DB 등 Backing Service로의 호출이 타임아웃으로 인해 반복 실패. 확인 결과 Envoy 프록시의 타임아웃** 설정이 2초로 너무 짧게 되어 있었음.

질문:
장애 해결을 위한 조치로 가장 적절한 것은?

① 앱 내 타임아웃을 제거
② 백엔드의 처리시간을 프록시에 맞춤
③ 서비스 메시의 타임아웃 값을 재설정
④ 백엔드 호출을 모두 제거

정답: ③
해설: 서비스 메시가 있는 경우에는 Envoy/L7 프록시의 timeout 설정이 실제 요청에 맞게 설정되어야 타임아웃 장애를 방지할 수 있다.

✅ NO.10 [MSA 환경에서 Backing Service 장애 분리 / 난이도: 상]

시나리오:
MSA 환경에서 일부 마이크로서비스가 Kafka 또는 Redis 장애로 인해 전체 서비스가 느려짐. 다른 정상 서비스까지 연쇄적으로 영향을 받음.

질문:
장애 전파 방지를 위한 구조 설계 방식은?

① 모든 서비스 간 직접 연결 구조
② 서킷 브레이커 및 격리 패턴 적용
③ 모든 장애 시 서비스 전체 재시작
④ 리플리케이션을 통해 하나의 Redis만 사용

정답: ②
해설: MSA 환경에서는 Backing Service 장애가 전체에 영향을 미치지 않도록 Circuit Breaker, Bulkhead, Timeout, Retry 등 보호 패턴을 적용해야 한다.

📘 실전 시나리오 핵심 요약

시나리오 유형핵심 대응 전략

Redis 다운	fallback to DB, retry, TTL 조정
Kafka 장애	메시지 보존, 재전송 큐
RDS 재시작	재시도 로직, 커넥션 풀링
로그 수집기 다운	로그 비동기, 실패 무시
Vault 장애	자동 갱신 로직 구현
환경 변수 실수	유효성 검증 및 린트 도구 사용
서비스 메시 타임아웃	프록시 설정 값 조정
MSA 전체 영향	Circuit Breaker, 격리 및 감시 적용

앞서 제공된 Backing Service 실전 장애 시나리오 문제들을 기반으로, 암기와 복습에 최적화된 **[암기카드 및 키워드 요약본]**을 아래와 같이 정리해드립니다.

🧠 Backing Service 실전 장애 대응 – 암기카드 (한줄 요약 카드)

각 카드 한 줄씩 읽으며 빠르게 반복학습할 수 있도록 구성했습니다.

✅ 장애 원인별 대응 암기카드

장애 유형암기 키워드 (핵심 대응 전략)

Redis 연결 오류	✅ 캐시 실패 시 → DB fallback → 캐시 갱신
Kafka 장애 / 메시지 유실	✅ 메시지 전송 실패 시 로컬 큐 저장 → 재전송
RDS 재시작 후 연결 실패	✅ DB 재연결은 "재시도(Retry) 로직"으로 처리
S3 업로드 지연	✅ 업로드는 백그라운드 처리 → 사용자 응답 우선
Loki 로그 수집기 장애	✅ 로그 실패 무시, 앱은 서비스 지속
DB + Redis 이중 장애	✅ 최소 하나로 fallback 처리 → 전체 중단 방지
Vault 인증 토큰 만료	✅ 자동 토큰 갱신 로직 필수
ENV 변수 오타 (S3 예시)	✅ 앱 시작 시 ENV 유효성 검사 필수
Service Mesh 타임아웃	✅ Envoy 프록시 timeout 설정 조정 필요
MSA에서 장애 전파	✅ Circuit Breaker + 격리(Bulkhead)로 연쇄 차단

✅ 키워드 정리 (장애 대응 설계 전략)