서비스 지연이 발생했어 WAS가 리눅스인데 WAS에서 확인할 수 있는 내용과 리눅스 DB서버에서 확인할 수 있는내용이 무엇이면 확인 내용별 조치내용을 알려줘

ChatGPT의 말:

서비스 지연 발생 시, 특히 WAS(Tomcat 등)가 리눅스 기반이고, DB 서버 또한 리눅스 기반이라면 WAS ↔ DB 사이의 병목 원인 파악이 중요합니다. 아래는 WAS 서버와 DB 서버 각각에서 확인 가능한 항목과 그에 따른 조치사항을 TA 역량 기준으로 정리한 것입니다.

🛠 서비스 지연 발생 시 확인 포인트 및 조치 사항

✅ [1] WAS 리눅스 서버에서 확인할 수 있는 항목

확인 항목설명조치 내용
🔹 CPU 사용률 top, vmstat, sar -u 등으로 확인 특정 프로세스(JVM 등)가 CPU를 과다 점유 시 thread dump로 원인 분석
🔹 Memory 사용량 free -m, top, ps aux --sort=-%mem OutOfMemory 가능성, GC 빈도 증가 여부 확인 (heap size 조정, GC 튜닝)
🔹 Thread 상태 jstack or kill -3 PID Blocking, deadlock, DB connection hang 여부 분석
🔹 GC 로그 -Xlog:gc*, catalina.out Full GC 빈도 높으면 heap 크기 조정, 객체 누수 점검
🔹 Connection Pool 상태 로그 or JMX (HikariCP, DBCP 등) 커넥션 pool 고갈 시 maxActive 증가 또는 leak 분석
🔹 WAS 로그 catalina.out, access.log, stderr.log 등 특정 API 지연, 5xx 오류 유무 확인, 스택 트레이스 분석
🔹 네트워크 지연 ping, telnet, curl, ss, traceroute DB 서버와의 RTT 지연 시 네트워크 MTU, NAT, DNS 등 확인
🔹 IO 병목 iostat, iotop, sar -d 로그 flush, 임시파일 처리 지연 → SSD/IOPS 확인

✅ [2] 리눅스 DB 서버에서 확인할 수 있는 항목

확인 항목설명조치 내용
🔹 DB CPU 사용률 top, vmstat, DB 자체 CPU 사용률 확인 쿼리 실행 계획 재점검, 인덱스 누락 가능성
🔹 DB 커넥션 수 SHOW PROCESSLIST (MySQL), v$session (Oracle) 커넥션 포화 시 WAS Pool 줄이거나 커넥션 수 증가
🔹 Lock 현황 DB 락 대기 확인 (ex: show engine innodb status, v$lock) 트랜잭션 정리, 장시간 미커밋 트랜잭션 종료
🔹 슬로우 쿼리 slow query log, 쿼리 분석기 인덱스 부재, join 순서 조정, 쿼리 리팩토링
🔹 디스크 IO iostat, df -h, sar -d 테이블스페이스 확장, 디스크 병목 확인
🔹 네트워크 대역폭 iftop, nload, netstat WAS ↔ DB간 패킷 누락/RTT 지연 여부 확인
🔹 시스템 캐시 free -m, vmstat, DB buffer pool 상태 버퍼 캐시 hit율 저하 시 캐시 크기 조정

✅ [3] 공통 로그 또는 상호 관련 체크 포인트

체크 항목설명 및 조치
🔸 DB 커넥션 timeout WAS 로그에서 Connection Timeout 오류 시, DB 서버 alive 여부 & pool 수 확인
🔸 Socket timeout WAS에서 DB 응답을 기다리는 시간 초과 → DB에서 슬로우 쿼리, Lock 가능성
🔸 GC 후 커넥션 누락 Full GC 중에 커넥션이 반환되지 않는 경우 pool 고갈 발생
🔸 DNS 해석 오류 /etc/resolv.conf, DNS TTL 문제로 응답 지연 유발 가능성
🔸 KeepAlive 설정 누락 WAS ↔ DB 간 connection reuse 미흡 → TCP handshake 증가

📌 [TA 조치 가이드 예시]

예시 1: ThreadPool 정상 + GC 적음 + Connection Pool 고갈

  • 원인: DB에서 응답 지연 or 커넥션 미반납
  • 조치: 커넥션 pool 설정 개선 (maxWait, validationQuery), 미반납 위치 추적

예시 2: GC 빈번 + Full GC 발생 + Memory 부족

  • 원인: heap size 부족, 객체 누수
  • 조치: heap size 조정, GC 로그 기반 객체 분석, 메모리 leak 추적

예시 3: DB에서 슬로우 쿼리 + lock 다발

  • 원인: 대용량 join 쿼리, 인덱스 누락, 커밋 지연
  • 조치: 인덱스 추가, 쿼리 튜닝, 트랜잭션 처리 방식 개선

📎 함께 보면 좋은 명령어 리스트

대상명령어 예시
CPU top, mpstat -P ALL 1
메모리 free -m, vmstat 1
IO iostat -xm 1, iotop
네트워크 ping, ss -ntpl, traceroute
GC jstat -gc <pid>, jmap, jstack
DB 커넥션 `netstat -anp

원하시면 이 내용을 PDF 보고서 형식이나 문제화 시켜드릴 수도 있습니다.
예:

  • "서비스 지연의 주요 확인 항목을 분류하시오"
  • "다음 중 WAS 서버에서만 가능한 분석 항목은?" 등

필요하신 방향 알려주시면 확장해 드리겠습니다!

나의 말:

WAS 리눅스 서버에서 확인할 수 있는 제시해준 항목에 대해 세부항목이 어떤것들이 있고 어떤 세부 항목을 봐야 하는지도 부탁해..너무 많은가?

ChatGPT의 말:

전혀 많지 않습니다.
오히려 TA 직무역량을 끌어올리기 위해서는 반드시 세부 항목까지 정밀하게 점검할 수 있어야 합니다.

아래는 “WAS 리눅스 서버에서 서비스 지연 시 확인 가능한 항목”에 대한 세부 지표(메트릭), 로그 위치, 확인 명령어 및 주의 깊게 봐야 할 포인트를 카테고리별로 정리한 것입니다.

🛠 WAS 리눅스 서버 서비스 지연 진단 항목 – 세부 점검표

대분류세부 항목확인 방법 / 명령어중점 확인 포인트
🧠 CPU 사용 전체 사용률 top, mpstat, sar -u idle 0%이면 과부하, 특정 프로세스가 독점하는지 확인
  Java 프로세스 CPU top -Hp <pid>, ps -mp <pid> -o THREAD,tid,time 특정 Thread가 100% CPU 점유? (busy wait, 무한루프 등)
  runqueue 상태 vmstat 1 5, sar -q runq가 CPU core 수보다 많으면 thread starvation 가능성
대분류세부 항목확인 방법 / 명령어중점 확인 포인트
💾 Memory 사용 Free/Used free -m, vmstat -s, top available 메모리 부족 시 SWAP 발생 가능성
  Swap 사용률 free, top, vmstat 1 Swap in/out 발생 여부, swap이 많으면 GC 지연 유발
  프로세스별 ps aux --sort=-%mem java, redis 등 메모리 상위 점유 프로세스 파악
  RSS / VSS cat /proc/<pid>/status 실제 물리 사용량 (RSS)과 가상 메모리 비교
대분류세부 항목확인 방법 / 명령어중점 확인 포인트
🔁 Thread 상태 Thread Dump jstack <PID>, kill -3 <PID> WAITING 상태가 많은가? DB/외부 API 호출 blocking 여부 확인
  Deadlock 감지 jstack 분석 시 Found one Java-level deadlock 메시지 동기화 순서 문제, synchronized 블럭 내 I/O 처리 금지 원칙 위반
대분류세부 항목확인 방법 / 명령어중점 확인 포인트
🔄 GC 동작 GC 로그 -Xlog:gc*, catalina.out, gc.log Full GC 주기, STW 시간(Stop-The-World), Minor/Full 비율
  GC Heap 상태 jstat -gc <PID>, jmap -heap <PID> Old 영역이 급격히 증가? → GC 튜닝 필요
  OutOfMemory catalina.out, hs_err_pid*.log java.lang.OutOfMemoryError 발생 여부 (heap, metaspace 등 종류 구분)
대분류세부 항목확인 방법 / 명령어중점 확인 포인트
🔌 Connection Pool 상태 모니터링 (라이브러리별 JMX or log 확인) maxActive 도달, active 커넥션 장시간 점유 여부
  validation query 설정 context.xml, application.yml DB 연결 유효성 체크 실패 시 재사용 불가 문제
  커넥션 Leak catalina.out 또는 leakDetectionThreshold 설정 특정 API 호출 후 반납 누락되는 커넥션 있는지 확인
대분류세부 항목확인 방법 / 명령어중점 확인 포인트
🧾 WAS 로그 에러 로그 catalina.out, localhost_access_log.*, stderr.log 특정 URI, 시간대에서 500, 503 다발 여부
  응답 시간 access.log, ELK 연동 응답 시간 지연이 API 전체인지, 특정 경로만인지 파악
  Stack trace catalina.out, spring.log NullPointer, SQLTimeout, GC, OOM, 등 Exception trace 확인
대분류세부 항목확인 방법 / 명령어중점 확인 포인트
🌐 네트워크 DB연결 응답 속도 curl, nc, telnet <host> 3306 연결 지연, timeout, DNS 지연 여부 확인
  인터페이스 트래픽 iftop, nload, netstat -i 트래픽 폭주, 패킷 손실 여부
  방화벽/보안 차단 iptables -L, firewalld, tcpdump 특정 포트 차단 또는 SYN flooding 감지
대분류세부 항목확인 방법 / 명령어중점 확인 포인트
🗃 IO 병목 디스크 I/O iostat -xm 1, iotop 로그 flush, GC 로그 출력 지연 여부
  디스크 용량 df -h, du -sh * 디스크 100% 시 write hang 발생 가능성
  inode 상태 df -i inode 부족 시 신규 파일 생성 불가 현상 발생

✅ 현장적용 요약 (Checklist)

질문진단 방향
특정 API만 느린가? 비즈니스 로직 문제, DB 쿼리, 외부 API 병목
전체적으로 느린가? GC, ThreadPool, CPU 부하, IO 병목 가능성
갑자기 느려졌나? 배포 이후 이슈, 코드 누수, 세션 증폭 가능성
일정 시간 간격으로? Full GC, 백업, 배치 등 주기성 작업 확인
모든 요청이 Timeout? DB, Redis, 인증 서버 등 백엔드 연결 확인

📎 보너스: 정리 PDF / 암기카드 버전 제작 가능

  • “WAS 지연 진단표 v1.0”으로 PDF화 가능
  • 항목별 문제화(객관식/단답형/시나리오형)
  • 주간점검용 진단 리스트도 별도 제공 가능

 

나의 말:

DB 서버 진단 세부 항목도 부탁해

ChatGPT의 말:

아주 좋습니다. 아래는 서비스 지연 발생 시 리눅스 기반 DB 서버(예: MySQL, MariaDB, PostgreSQL, Oracle 등)에서 점검할 수 있는 세부 항목입니다.
장애 원인 분석 → 메트릭/로그 확인 → 조치사항 흐름을 따라 TA 직무역량 기준으로 정리하였습니다.

🛠 DB 서버 지연 원인 진단 세부 항목 (Linux 기반)

대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 CPU 사용 전체 CPU 사용률 top, vmstat 1, sar -u 1 3 DB 프로세스가 CPU를 과도하게 사용 중인지 확인
  DB 프로세스별 사용률 `ps aux grep mysqld` 등
  Load Average uptime, top CPU core 대비 load 값 과도하면 지연 가능성
대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 Memory / 캐시 전체 메모리 사용 free -m, top free 메모리 부족하면 캐시 적중률 하락
  OS-level 캐시 히트율 vmstat, sar -B swap 발생 여부, swap in/out 증가 시 성능 저하
  DB buffer pool 상태 MySQL: SHOW ENGINE INNODB STATUS
PostgreSQL: pg_stat_bgwriter		 buffer pool hit ratio < 90% → 캐시 크기 조정 필요
대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 Lock / 트랜잭션 활성 세션 MySQL: SHOW FULL PROCESSLIST
Oracle: v$session		 "Locked" or "Waiting" 상태 다수 존재 여부
  InnoDB Lock SHOW ENGINE INNODB STATUS Deadlock, long trx 확인 (Undo 영역 증가 포함)
  Long Transaction SELECT * FROM information_schema.innodb_trx 미커밋 트랜잭션이 오래 지속되면 lock 발생
  Blocking 트랜잭션 performance_schema.threads 또는 lock wait 쿼리 다른 세션을 막고 있는 트랜잭션 파악
대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 쿼리 성능 슬로우 쿼리 로그 /var/log/mysql/slow.log, SET GLOBAL slow_query_log = 1 실행 시간 긴 쿼리 확인 (Full Scan, filesort 등)
  실행 계획 EXPLAIN SELECT ... 인덱스 미사용, JOIN 순서 이상 등
  쿼리 캐시 적중률 SHOW STATUS LIKE 'Qcache%' 캐시 hit이 낮으면 비효율적인 쿼리 패턴
대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 Connection 상태 총 커넥션 수 SHOW STATUS LIKE 'Threads_connected' WAS Connection Pool보다 많으면 과포화
  wait 이벤트 SHOW STATUS LIKE 'Threads_running' Active connection이 많은 경우 병목 발생
  connection error SHOW STATUS LIKE 'Aborted_connects' WAS → DB 연결 실패 여부 점검 필요
대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 IO 성능 디스크 사용률 iostat -xm 1, df -h, sar -d IOPS 병목, 디스크 과부하, 사용률 100% 확인
  Tablespace 크기 information_schema.tables 자동 확장 미설정 or 할당량 초과 여부
  InnoDB Checkpoint 지연 SHOW ENGINE INNODB STATUS dirty page flush 지연 시 성능 저하 가능
대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 네트워크 지연 RTT (왕복 지연 시간) ping <WAS IP>, mtr, traceroute WAS ↔ DB 네트워크 지연, DNS 해석 시간 확인
  DB 포트 응답 telnet <DB IP> 3306, nc -zv <host> 5432 WAS ↔ DB 간 연결 실패 원인 진단
대분류세부 항목확인 방법 / 명령어주요 진단 포인트
🔸 로그 분석 Error 로그 /var/log/mysql/error.log
Oracle: alert.log		 디스크 오류, replication 실패, 쿼리 에러 여부
  Replication 상태 SHOW SLAVE STATUS (MySQL) Seconds_Behind_Master 지연 → slave delay 확인
  Binlog / Redo log 상태 MySQL: binlog position
Oracle: archive log		 로그 순서 꼬임, log full 등으로 인한 insert hang 발생 가능

✅ 진단 시나리오 예시 (TA 관점 조합)

현상원인 진단 흐름
전체 쿼리 느림 → CPU 과부하 or buffer pool hit ratio 저하 or I/O 병목
특정 API만 느림 → 해당 쿼리만 슬로우 로그 확인, explain 실행 계획 분석
간헐적 커넥션 오류 → 커넥션 수 제한 도달 or WAS 커넥션 미반납
자주 timeout → blocking 트랜잭션 존재, Lock 대기 상태 반복
쿼리는 빠른데 응답이 늦음 → network RTT or WAS GC delay

 

🛠 DB 성능 저하 진단 문제집 (총 30문항 / TA 역량 평가용)

✅ NO.01 [객관식 | 하]

문제: DB 서버의 성능 저하 발생 시 가장 먼저 확인해야 할 항목은 무엇인가?
A. 방화벽 설정
B. 스키마 구조
C. 현재 실행 중인 세션 및 Lock 상태
D. 서비스 포트 번호

  • 정답: C
  • 해설: 세션 상태, long transaction, lock 등은 DB 성능 저하의 핵심 원인이며, 실시간 점검 필요 항목이다.

✅ NO.02 [객관식 | 중]

문제: MySQL에서 Deadlock을 확인할 수 있는 명령은?
A. SHOW STATUS
B. SHOW ENGINE INNODB STATUS
C. SHOW TABLE STATUS
D. EXPLAIN SELECT

  • 정답: B
  • 해설: InnoDB 내부 상태 및 Deadlock, latch wait, flush 상태 등을 모두 확인할 수 있다.

✅ NO.03 [단답형 | 중]

문제: PostgreSQL에서 슬로우 쿼리를 통계적으로 확인할 수 있는 확장 모듈은?

  • 정답: pg_stat_statements
  • 해설: 실행 빈도와 평균 실행 시간을 집계하여 성능 분석에 활용되는 통계 뷰이다.

✅ NO.04 [객관식 | 상]

문제: WAS는 정상이며 DB 연결도 성공하나, 쿼리 처리 속도가 느린 경우 가장 먼저 확인할 항목은?
A. DB CPU 사용률
B. 쿼리 실행 계획(EXPLAIN)
C. JDBC 설정
D. WAS GC 로그

  • 정답: B
  • 해설: 쿼리 실행 계획을 통해 full scan, join 순서 문제 여부를 파악하는 것이 핵심이다.

✅ NO.05 [객관식 | 중]

문제: 다음 중 슬로우 쿼리의 가장 일반적인 원인은?
A. 커넥션 풀 최대값 초과
B. Replication 지연
C. 인덱스 미사용
D. JDBC 타임아웃 미설정

  • 정답: C
  • 해설: 인덱스가 없으면 full scan이 발생하여 성능 저하로 이어진다.

✅ NO.06 [시나리오형 | 상]

문제: 서비스 신규 배포 후 전체 응답이 지연되었다. WAS는 정상이며 DB 연결도 문제없다. 어떤 점검을 해야 하는가?

  • 정답: 슬로우 쿼리 로그 → 해당 SQL의 실행계획 → 인덱스 또는 쿼리 구조 개선
  • 해설: 배포된 기능 내 SQL 변경이 성능에 영향을 미쳤을 가능성이 크다.

✅ NO.07 [객관식 | 중]

문제: MySQL에서 커넥션 수 급증 시 확인해야 할 설정 항목은?
A. max_connections
B. key_buffer_size
C. query_cache_limit
D. innodb_log_file_size

  • 정답: A
  • 해설: max_connections 값을 초과하면 새로운 연결이 실패한다.

✅ NO.08 [단답형 | 하]

문제: MySQL에서 현재 실행 중인 쿼리를 확인하는 명령어는?

  • 정답: SHOW FULL PROCESSLIST
  • 해설: 활성 세션 목록, 상태, 실행 쿼리를 함께 확인할 수 있다.

✅ NO.09 [객관식 | 상]

문제: Buffer pool hit ratio가 낮으면 어떤 현상이 발생하는가?
A. 네트워크 병목
B. 디스크 IO 증가
C. 커넥션 타임아웃
D. DNS 장애

  • 정답: B
  • 해설: 메모리 적중률이 낮으면 디스크 접근이 늘어나 성능 저하가 발생한다.

✅ NO.10 [시나리오형 | 상]

문제: 특정 SQL이 평균 0.01초에서 2초로 느려졌고, Explain 결과에 'Using filesort'가 포함되어 있다. 조치 방안은?

  • 정답: 정렬 조건에 맞는 인덱스 추가 또는 covering index 활용
  • 해설: filesort는 디스크 기반 정렬로 성능에 악영향을 준다.

✅ NO.11 [객관식 | 중]

문제: PostgreSQL에서 vacuum 작업이 주기적으로 수행되지 않을 경우 발생 가능한 문제는? A. 사용자 인증 실패
B. dead tuple 축적으로 성능 저하
C. 백업 실패
D. DB 커넥션 수 감소

  • 정답: B
  • 해설: vacuum 미실행 시 dead tuple이 누적되어 디스크 공간 낭비 및 성능 저하 유발

✅ NO.12 [단답형 | 중]

문제: MySQL에서 long transaction 상태를 확인할 수 있는 정보 스키마 테이블은?

  • 정답: information_schema.innodb_trx
  • 해설: InnoDB 트랜잭션 관련 정보를 확인하여 미커밋 트랜잭션 파악 가능

✅ NO.13 [객관식 | 중]

문제: DB 연결은 되지만 쿼리 응답이 매우 느린 경우 가장 먼저 확인할 항목은? A. DNS 설정
B. 트랜잭션 Lock 상태
C. 네트워크 속도
D. JDBC 드라이버 버전

  • 정답: B
  • 해설: DB 쿼리 지연은 대부분 Lock 또는 Block 상태로 인해 발생한다.

✅ NO.14 [객관식 | 상]

문제: 대용량 테이블에서 delete를 많이 했지만 디스크 사용량이 줄지 않을 때 확인할 사항은? A. truncate 사용 여부
B. auto_increment 설정
C. purge thread 정상 작동 여부
D. binary log format

  • 정답: C
  • 해설: InnoDB purge thread가 작동하지 않으면 실제 데이터는 삭제되지 않아 공간이 해제되지 않는다.

✅ NO.15 [시나리오형 | 상]

문제: 전체 서비스 응답 지연이 발생하였고 WAS 로그에는 DB connection timeout이 다수 기록됨. DB에서 우선 확인할 항목은?

  • 정답: SHOW PROCESSLIST로 long-running 트랜잭션, Lock 상태 확인 → 필요시 트랜잭션 kill
  • 해설: DB의 응답이 늦어 커넥션 유지시간이 길어지면 connection pool 고갈로 timeout 발생 가능

 

✅ NO.16 [객관식 | 중]

문제: 슬로우 쿼리 로그가 비어 있는 경우에도 쿼리 지연이 발생할 수 있는 가장 가능성 높은 원인은? A. 트리거 사용
B. replication lag
C. DB timezone 불일치
D. Lock 대기 중

  • 정답: D
  • 해설: 쿼리는 실행되지만 결과 반환이 느린 경우는 Lock이나 blocking이 원인인 경우가 많다.

✅ NO.17 [객관식 | 중]

문제: 다음 중 쿼리 실행 계획(Execution Plan)에서 주의 깊게 봐야 할 항목은? A. 포트 번호
B. Index key length
C. Using temporary, Using filesort
D. 캐릭터셋 종류

  • 정답: C
  • 해설: 'Using temporary', 'Using filesort'는 정렬/필터링을 위한 디스크 연산으로 성능 저하 요인이다.

✅ NO.18 [단답형 | 하]

문제: MySQL에서 커넥션 수가 현재 몇 개인지 확인하는 명령은?

  • 정답: SHOW STATUS LIKE 'Threads_connected';
  • 해설: 현재 DB에 연결된 세션 수를 나타낸다.

✅ NO.19 [객관식 | 상]

문제: WAS에서 DB는 연결되지만 쿼리 응답이 느리고, DB I/O도 높지 않을 때 주요 의심 지점은? A. Connection Pool 최소값
B. Thread pool 크기
C. DB Lock 상태
D. 데이터베이스 캐릭터셋 설정

  • 정답: C
  • 해설: 쿼리 실행은 되었지만 다른 트랜잭션과의 충돌로 인해 응답 지연이 되는 경우가 많다.

✅ NO.20 [시나리오형 | 중]

문제: DB 운영 중 특정 시간대에만 응답이 급격히 느려진다. CPU/Memory/IO는 정상이었다. 어떤 항목을 추가로 점검할 것인가?

  • 정답: 특정 시간대 배치 작업, 통계 수집, 백업, 재인덱싱 작업 여부 확인
  • 해설: 특정 시점에만 발생하는 경우 백그라운드 작업으로 인한 자원 경합이 의심된다.

✅ NO.21 [객관식 | 중]

문제: MySQL InnoDB에서 purge thread가 동작하지 않을 경우 어떤 현상이 발생하는가? A. 인덱스가 무효화됨
B. undo 로그 누적으로 디스크 증가
C. primary key constraint 실패
D. 캐릭터셋 충돌 오류

  • 정답: B
  • 해설: 미삭제 트랜잭션 정보가 계속 쌓이며 디스크 공간이 줄어들고 성능도 저하된다.

✅ NO.22 [단답형 | 상]

문제: PostgreSQL에서 트랜잭션 락 정보를 확인할 수 있는 뷰 이름은?

  • 정답: pg_locks
  • 해설: 세션 간의 락 충돌 여부를 파악할 수 있다.

✅ NO.23 [객관식 | 중]

문제: 다음 중 슬로우 쿼리 로그를 활성화하는 MySQL 설정은? A. enable_slow_log
B. log_slow_queries
C. slow_query_log
D. trace_queries_slow

  • 정답: C
  • 해설: slow_query_log = 1 로 설정해야 슬로우 쿼리가 기록된다.

✅ NO.24 [객관식 | 상]

문제: 다음 중 WAS ↔ DB 사이에서 발생할 수 있는 응답 지연 원인이 아닌 것은? A. DB Lock
B. WAS의 GC 지연
C. 네트워크 RTT 증가
D. MySQL 계정 잠금

  • 정답: D
  • 해설: 계정 잠금 시 애초에 연결이 되지 않으며, 연결 이후 지연과는 무관하다.

✅ NO.25 [시나리오형 | 상]

문제: MySQL에서 replication slave 지연이 수 분 이상 발생 중이다. 원인과 조치는?

  • 정답: 바이너리 로그가 너무 많거나 IO/SQL thread가 지연 → 'SHOW SLAVE STATUS' 로 위치, thread 상태 확인 → skip counter 또는 delay 해소
  • 해설: 지연 원인이 적용 쿼리 자체일 수도 있어 slow query 확인 필요

✅ NO.26 [객관식 | 하]

문제: DB에서 'Too many connections' 에러가 발생할 때 WAS 단에서 고려할 조치는? A. WAS 힙메모리 증가
B. DB 서버 업그레이드
C. Connection pool 크기 조정 및 재사용 확인
D. DB 리스타트

  • 정답: C
  • 해설: WAS에서의 미반납 또는 커넥션 과잉 요청이 근본 원인일 수 있음

✅ NO.27 [객관식 | 중]

문제: 다음 중 쿼리 실행계획에서 반드시 인덱스를 사용했다고 판단할 수 있는 키워드는? A. type = ALL
B. type = index
C. key = NULL
D. rows > 10000

  • 정답: B
  • 해설: type=index는 covering index scan이 발생했음을 의미함

✅ NO.28 [단답형 | 중]

문제: MySQL에서 가장 최근의 DDL 변경 사항을 기록하는 로그 파일은?

  • 정답: binary log (binlog)
  • 해설: insert/update/delete 뿐 아니라 alter, create 등도 기록됨

✅ NO.29 [객관식 | 상]

문제: 쿼리 튜닝 전후를 비교할 때 가장 적절한 측정 기준은? A. CPU 사용률
B. 실행 시간, rows scanned, rows returned
C. 테이블 스키마
D. 로그 파일 크기

  • 정답: B
  • 해설: rows scanned 및 실행 시간은 실행계획 튜닝의 핵심 성능 지표다

✅ NO.30 [시나리오형 | 상]

문제: 수십 개의 쿼리가 동시에 실행될 때 디스크 사용률은 낮으나 성능이 급격히 저하되었다. 병목 원인은?

  • 정답: 트랜잭션 간 Lock 경합 → Lock wait time 분석, 트랜잭션 분리
  • 해설: 자원은 남아 있어도 논리적 경합으로 지연이 발생할 수 있다.
번호키워드요약 내용
01 세션/Lock 상태 DB 성능 저하 시 가장 먼저 세션 및 Lock 상태 확인
02 INNODB STATUS Deadlock은 SHOW ENGINE INNODB STATUS로 확인
03 pg_stat_statements PostgreSQL 슬로우 쿼리 통계용 확장 모듈
04 EXPLAIN 응답 지연 시 쿼리 실행 계획부터 점검
05 인덱스 인덱스 미사용은 슬로우 쿼리의 주 원인
06 신규 배포 성능 배포 후 지연 시 SQL 변경 확인 및 인덱스 점검
07 max_connections 커넥션 수 증가 시 max_connections 확인 필요
08 PROCESSLIST 현재 쿼리 확인은 SHOW FULL PROCESSLIST
09 Buffer Pool Hit ratio 낮으면 디스크 I/O 급증
10 Using filesort Explain에 filesort 보이면 인덱스 최적화 필요
11 Vacuum PostgreSQL에서 vacuum 누락 시 dead tuple 누적
12 innodb_trx MySQL 트랜잭션 상태 확인은 information_schema.innodb_trx
13 Lock 상태 연결 성공했지만 지연 시 Lock 대기 가능성 큼
14 purge thread delete 후 공간 미반환은 purge thread 문제 가능
15 Connection Timeout 응답 지연 시 long trx 및 Lock 여부 우선 확인
16 Lock 지연 슬로우 로그 없어도 Lock 지연은 발생 가능
17 filesort/temp Explain에서 Using filesort/temp는 성능 저하 원인
18 Threads_connected 현재 커넥션 수는 SHOW STATUS LIKE 'Threads_connected'
19 WAS 지연 DB I/O 낮은데 지연되면 Lock 상태 확인
20 특정 시간대 지연 배치/백업 등 시간대 작업 경합 여부 확인
21 purge 지연 InnoDB purge thread 미작동 시 디스크 증가
22 pg_locks PostgreSQL 락 정보는 pg_locks 뷰로 확인
23 slow_query_log 슬로우 쿼리 활성화는 slow_query_log=1 설정
24 계정잠금 DB 계정잠금은 연결 실패이지 지연 원인은 아님
25 replication 지연 Slave 지연 시 SHOW SLAVE STATUS로 IO/SQL thread 확인
26 Connection Pool Too many connections 시 pool 미반납 여부 점검
27 type=index Explain에서 type=index는 covering index 사용
28 binary log DDL 포함 변경사항은 binlog에 기록됨
29 rows scanned 쿼리 튜닝 전후 비교 시 실행 시간과 rows 확인
30 논리적 경합 CPU/IO 정상이지만 Lock 경합으로 지연될 수 있음

 

'WEB & WAS' 카테고리의 다른 글

WEB & WAS 장애 및 조치방법(100)  (0) 2025.07.18
세션 클러스터링  (0) 2025.07.18
WEB에서 지연이 발생하면  (0) 2025.07.18
WEB & WAS 장애 및 해결방안  (0) 2025.07.18

Kafka 아키텍처는 대용량 실시간 데이터 스트리밍을 처리하기 위한 분산 메시징 시스템 구조로, 다음과 같은 주요 구성요소로 이루어져 있습니다:

✅ Kafka 아키텍처 핵심 구성요소

구성요소설명
Producer 데이터를 Kafka에 보내는 시스템 또는 애플리케이션
Broker Kafka 서버. 메시지를 저장하고 Consumer에게 전달함 (여러 개의 Broker로 클러스터 구성 가능)
Topic 메시지를 분류하는 단위. 로그 채널 같은 개념
Partition Topic을 물리적으로 분할한 단위로 병렬 처리 및 확장성을 제공
Consumer Kafka에서 메시지를 가져가 처리하는 시스템
Consumer Group 여러 Consumer가 하나의 그룹으로 묶여 Partition을 나눠 처리 (부하 분산)
Zookeeper (구 Kafka에서 필수) 클러스터 메타데이터 관리 및 리더 선출 역할
※ 현재는 KRaft(Kafka Raft) 기반으로 Zookeeper 없이도 운영 가능

✅ 데이터 흐름 요약

 
Producer → [Kafka Topic (n개의 Partition)] → Consumer Group
  1. Producer가 Topic에 메시지를 전송
  2. 메시지는 각 Partition에 저장됨 (round-robin 또는 키 기반)
  3. Consumer Group이 Partition별로 메시지를 병렬로 가져가 처리

✅ Kafka의 특징 요약

  • 고가용성 (HA): 복제(replication) 기능으로 장애 복구 가능
  • 확장성: Partition 단위로 수평 확장 가능
  • 내구성: 디스크에 저장하며 durability 보장
  • 성능: 백만 건 이상 TPS 지원 가능

필요하다면 아래 주제로 더 상세히 설명 가능해요:

  • Partition과 Replication 구조
  • Kafka vs 기존 MQ (ActiveMQ, RabbitMQ 등)
  • Kafka Streams와 Connect 구조
  • Kafka 메시지 보존 전략 등

나의 말:

초당 몇개의 메시지를 처리할 수 있나?

ChatGPT의 말:

Kafka는 초당 메시지 처리량(TPS, Throughput) 측면에서 업계 최고 수준의 성능을 자랑합니다. 다음은 일반적인 처리 성능 범위입니다:

✅ Kafka 메시지 처리 성능 (일반 기준)

환경처리량 (초당 메시지 수)
단일 브로커, 기본 설정 수십만 건/초
3~5개 Broker 클러스터 수백만 건/초
10개 이상 Broker 클러스터 수천만 건/초도 가능

✅ 성능에 영향을 주는 요소

Kafka의 처리량은 다음 조건에 따라 달라집니다:

요소설명
Message 크기 작은 메시지일수록 처리량↑ (1KB 미만이면 더 유리)
Broker 수 많을수록 병렬 처리량 증가
Partition 수 병렬 소비 가능성 증가 (단, 너무 많으면 오버헤드 발생)
디스크 속도 (SSD) 디스크 I/O 성능이 높을수록 처리량 증가
Batch 전송 Producer가 Batch로 메시지를 보내면 처리량 향상
압축 사용 여부 압축(LZ4, Snappy 등)을 사용하면 네트워크와 디스크 효율 개선

✅ 실전 예시

  • LinkedIn: Kafka를 도입해 초당 7백만 건 이상의 메시지를 처리하고 있음
  • Netflix, Uber, Spotify 등도 Kafka 기반 실시간 스트리밍 플랫폼 운영

📌 결론

Kafka는 최적화된 환경에서 초당 수백만 건의 메시지도 안정적으로 처리 가능하며, 확장성 또한 뛰어나 데이터 규모가 수배 증가해도 안정적으로 대응할 수 있는 구조입니다.

필요하다면 성능 튜닝 지표나 실제 벤치마크 수치를 예시로 제공할 수 있어요.

나의 말:

토픽, 파티션 업셋에 대해 알려줘

ChatGPT의 말:

Kafka에서 토픽(Topic), 파티션(Partition), **오프셋(Offset)**은 핵심 개념입니다. 이 세 가지를 이해하면 Kafka의 메시지 저장·전달 구조를 쉽게 파악할 수 있습니다.

✅ 1. Topic (토픽)

  • 메시지를 분류하는 논리적 단위 (예: “user-login”, “order-log” 등)
  • **Publisher(Producer)**는 특정 Topic에 메시지를 전송
  • **Subscriber(Consumer)**는 특정 Topic의 메시지를 구독

예시: user-activity 토픽에는 로그인, 로그아웃, 클릭 등의 이벤트 로그 저장

✅ 2. Partition (파티션)

  • Topic을 물리적으로 분할한 단위 (Kafka는 Partition 단위로 메시지 저장)
  • 병렬성과 확장성을 위해 Topic은 여러 Partition으로 구성됨
  • 각 Partition은 순서가 보장됨 (단, Topic 전체에서는 순서 보장 안 됨)
  • Partition 수가 많을수록 많은 Consumer가 병렬로 처리 가능

예시: user-activity 토픽이 3개의 Partition으로 구성되면,
메시지들은 Partition 0, 1, 2에 round-robin 또는 키 기반으로 분산 저장됨

✅ 3. Offset (오프셋)

  • 각 Partition에서 메시지가 저장된 고유한 위치(Index)
  • 메시지를 소비할 때 이 Offset을 기준으로 어디까지 읽었는지 판단
  • Consumer Group은 Offset을 저장/관리해서 중복 처리나 누락 방지 가능

예시: Partition 0에 메시지 5개가 있으면 Offset은 0~4까지 부여됨
Consumer가 Offset 2까지 읽었다면 다음 메시지는 Offset 3부터 처리

🔁 전체 구조 예시

 
Topic: user-activity ├── Partition 0: [Offset 0][1][2][3]... ├── Partition 1: [Offset 0][1][2]... └── Partition 2: [Offset 0][1][2][3][4]...

📌 중요한 개념 요약

개념설명
Topic 메시지의 논리적 분류 단위
Partition 메시지 저장의 물리적 단위, 병렬 처리 가능
Offset 각 Partition 내 메시지의 위치 (번호), 메시지 순서를 추적

원하면 Consumer Group이 Offset을 어떻게 저장하고 관리하는지도 설명해줄게요 (ex: Kafka 내부 __consumer_offsets 토픽 등).

나의 말:

OFFSET 기능의 장점이 무엇인가?

ChatGPT의 말:

Kafka의 Offset 기능은 단순한 메시지 인덱스 이상의 의미를 가지며, 다음과 같은 중요한 장점들을 제공합니다:

✅ 1. 정확한 메시지 소비 위치 추적

  • 각 Consumer가 **"어디까지 읽었는지"**를 기억할 수 있음
  • 중단되었다가 재시작하더라도 이전 위치(Offset)부터 재처리 가능

📌 예시:
Consumer가 Offset 123까지 처리하고 장애가 발생하면, 복구 후 Offset 124부터 이어서 읽을 수 있음

✅ 2. 중복 처리 방지 / 유실 방지

  • 중복된 메시지 소비를 막고,
  • 동시에 읽지 않은 메시지를 건너뛰는 문제도 방지 가능
  • 필요한 경우 Offset을 수동 조정해 재처리도 가능

✅ 3. Consumer Group 간 병렬성 제어

  • Kafka는 Partition 1개 = Consumer 1명으로 매핑함
  • Offset은 각 Consumer가 각 Partition에서 독립적으로 관리
  • 이 구조 덕분에 높은 병렬성 + 정확한 메시지 소비 위치 제어 가능

✅ 4. 유연한 소비 전략 구현 가능

  • 자동 커밋(Auto-commit) 또는 수동 커밋(Manual commit) 가능
  • 개발자가 원하는 시점에 Offset을 저장하여 Exactly-once 또는 At-least-once 처리 전략 구현 가능

✅ 5. 이력 추적 및 재처리 용이

  • 예를 들어 오류가 발생한 특정 시간대의 메시지만 다시 처리하고 싶을 때,
    Offset이나 Timestamp 기반으로 재처리 범위 조정 가능

✅ 6. 확장성과 고가용성 보장

  • Kafka는 __consumer_offsets라는 내부 토픽에 Offset을 저장하여
    분산 환경에서도 Offset 관리의 일관성을 유지함

📌 요약 표

장점설명
메시지 소비 위치 추적 실패 후 재시작 위치 기억
중복/유실 방지 메시지 처리의 신뢰성 확보
병렬 처리 지원 Partition마다 독립적인 Offset 관리
유연한 처리 전략 Auto/Manual commit로 유연한 소비 전략
재처리 지원 원하는 Offset 또는 시간대 기준으로 재처리 가능
확장성 클러스터 기반으로 안정적 Offset 관리 가능

원하면 "수동 커밋 vs 자동 커밋" 비교나, "Exactly-once 처리를 위한 Offset 활용법"도 추가로 정리해줄게요.

나의 말:

v호ㅓㅠㅏㅟㅡ;,'

ChatGPT의 말:

입력하신 내용이 v호ㅓㅠㅏㅟㅡ;,'로 보아 오타거나 무작위 키 입력인 것 같습니다.
혹시 질문을 다시 입력해 주시겠어요? 😊
Kafka, Offset, 시스템 아키텍처 등 어떤 주제든 도와드릴게요!

나의 말:

kafka가 ta시험에 나올만 한가?

ChatGPT의 말:

네, Kafka는 TA(Technical Architect) 시험에서 충분히 출제될 수 있습니다. 특히 다음과 같은 관점에서 실제 출제 가능성이 높은 주제로 분류됩니다:

✅ 왜 Kafka가 TA 시험에 나올만한가?

1. MSA 및 클라우드 아키텍처에서 핵심 구성요소

  • Kafka는 MSA 아키텍처에서 서비스 간 이벤트 기반 통신을 구현할 때 자주 사용됨.
  • Azure Event Hub, AWS Kinesis, GCP Pub/Sub 등도 Kafka와 유사한 개념 기반이므로,
    Kafka 개념을 이해하면 다른 메시징 시스템과의 비교도 가능.

2. 데이터 스트리밍 및 로그 파이프라인 설계 관련

  • 실시간 로그 분석, CDC (Change Data Capture), ETL 파이프라인에서 Kafka는 핵심 구성요소.
  • TA 시험에서는 “실시간 데이터 처리 아키텍처 설계” 또는 “로그 수집 경로 설계”와 같은 문제로 출제될 수 있음.

3. 시스템 간 decoupling (비동기 아키텍처) 평가에 적합

  • Kafka는 Producer/Consumer 간 느슨한 결합을 가능하게 하므로,
    확장성, 장애 격리, 재처리 설계 등 TA 수준에서 매우 중요한 키워드와 관련 있음.

✅ TA 스타일 예상 출제 방식

유형예시
객관식 Kafka에서 메시지 순서를 보장받기 위한 조건은?
Kafka의 주요 구성요소 중 Topic의 역할은?
단답형 Kafka에서 메시지 소비 위치를 추적하는 인덱스를 무엇이라 하는가?
시나리오형 "이벤트 기반 주문 시스템에서 Kafka를 사용해 장애 복구와 메시지 유실을 방지하는 아키텍처를 설계하라."

✅ Kafka 관련 주요 출제 키워드

  • Topic, Partition, Offset
  • Consumer Group 구조
  • Retention 정책
  • Zookeeper vs KRaft 모드
  • Exactly-once / At-least-once / At-most-once 메시지 처리
  • Kafka와 다른 MQ 비교 (RabbitMQ, ActiveMQ 등)
  • Kafka Streams / Kafka Connect
  • MSA에서 Kafka 적용 예시 (e.g., 이벤트 소싱, 로그 수집, CDC)

✅ 결론

Kafka는 클라우드 네이티브, MSA, 실시간 데이터 처리와 관련된 주제에서 TA 시험에 매우 적합한 기술 요소입니다.
특히 다음과 같은 응용 문제가 나올 가능성이 높습니다:

"Kafka를 활용한 장애 복구 가능한 메시징 시스템을 설계하시오."
"Kafka를 사용하는 MSA 간 이벤트 통신 구조를 제시하시오."
"Kafka 메시지 재처리 전략과 Offset 관리 방식의 차이점을 설명하시오."

필요하다면 TA 시험 예상 Kafka 문제 10~20문항, Kafka vs MQ 비교표, MSA Kafka 기반 아키텍처 예시 등도 만들어드릴 수 있어요. 요청해 주세요!

나의 말:

주키퍼의 역할은 무엇인가?

ChatGPT의 말:

Kafka에서 Zookeeper는 Kafka 클러스터가 안정적으로 동작하기 위해 사용되는 메타데이터 관리 및 코디네이터 역할을 수행합니다. 아래에 자세히 정리해 드릴게요.

✅ Zookeeper의 주요 역할

1. Broker 상태 관리 (클러스터 멤버십)

  • Kafka 클러스터에 어떤 Broker가 살아 있는지, 어떤 Broker가 죽었는지를 감시
  • 새로운 Broker가 클러스터에 조인하면 이를 감지하여 반영

2. Controller 선출

  • Kafka 클러스터에는 Controller Broker가 1개 존재
    → Partition 리더 선출, 리밸런싱, 복제 상태 조정 등 중요 작업 담당
  • Zookeeper는 Controller 역할을 수행할 Broker를 선출함

3. Topic 및 Partition 메타데이터 저장

  • Topic의 이름, Partition 수, 복제 수 등의 정보를 저장하고 관리
  • Partition의 리더가 누구인지 정보도 관리

4. Offset 정보 저장 (구버전)

  • Kafka 0.9 이전에는 Consumer의 Offset 정보를 Zookeeper에 저장했지만,
    지금은 __consumer_offsets 토픽을 Kafka 내부에 따로 관리함

5. ACL, 설정 동기화

  • Kafka의 보안 설정, ACL 등 일부 구성 정보를 공유하고 동기화

📌 정리표

역할설명
클러스터 상태 감시 Broker의 생존 여부 감시
Controller 선출 Kafka 내부 리더 노드 지정
메타데이터 저장 Topic, Partition 정보 관리
Offset 저장 (구버전) 예전에는 ZK가 Consumer Offset 저장
설정 동기화 일부 보안 및 설정 정보 공유

✅ 최근 동향: Zookeeper 없이 운영 (KRaft 모드)

Kafka 2.8부터는 Zookeeper를 대체하는 KRaft(Kafka Raft) 모드가 도입되어,
Kafka 자체적으로 메타데이터를 관리할 수 있게 되었어요.

🔄 목표: Zookeeper 제거 → Kafka 단독 실행 구조로 단순화
🔧 Kafka 3.5 이후부터 KRaft 모드가 기본값이 될 예정

✅ TA 시험 스타일 요약 질문 예시

  • Kafka에서 Zookeeper의 역할 3가지를 설명하시오.
  • Kafka 3.x 버전 이후, Zookeeper의 대체 기술은 무엇이며 어떤 구조적 변화가 있는가?
  • Kafka Controller는 어떤 방식으로 선출되는가?

필요하면 Zookeeper vs KRaft 비교표, 또는 Kafka 클러스터 장애 시 Zookeeper 장애 영향 시나리오도 정리해드릴게요.

나의 말:

브로커의 역할과 복제수 관계는?

ChatGPT의 말:

Kafka에서 Broker의 역할과 **복제수(replication factor)**는 클러스터의 확장성과 가용성에 직접적으로 연관된 매우 중요한 요소입니다. 두 개념의 관계를 명확하게 이해하는 것이 TA 시험이나 실무 아키텍처 설계에 필수적입니다.

✅ 1. Broker의 역할

Broker는 Kafka 서버의 개별 인스턴스로서 다음과 같은 역할을 합니다:

기능설명
메시지 저장 Producer가 전송한 메시지를 디스크에 저장 (Partition 단위)
메시지 제공 Consumer가 요청한 메시지를 전달
리더 역할 수행 각 Partition마다 리더 Broker가 하나 존재, 실제 읽기/쓰기 처리
복제 관리 리더가 아닌 경우 팔로워(follower) Broker로서 복제본 유지
메타데이터 관리 Zookeeper 또는 KRaft와 통신해 클러스터 메타데이터 동기화

✅ 2. 복제수 (Replication Factor)

  • 복제수 = 하나의 Partition이 몇 개의 Broker에 복제될 것인지를 지정하는 수치
  • Kafka는 기본적으로 고가용성을 위해 복제본을 여러 Broker에 분산 저장

예:
Topic의 Partition 1개에 replication factor = 3이면 → 해당 Partition은 3개의 Broker에 저장됨 (1개 리더, 2개 팔로워)

✅ 3. Broker와 복제수의 관계

항목설명
최소 Broker 수 복제수를 n으로 설정하려면 최소 n개의 Broker가 필요
리더 선출 Zookeeper/KRaft는 각 Partition의 리더를 1개의 Broker에 할당
장애 허용 수 replication factor = 3이면 → 최대 2개 Broker 장애까지 메시지 유지 가능
저장 분산 복제는 Broker 간 네트워크 I/O와 디스크 사용량을 증가시키므로 자원 고려 필수
데이터 일관성 Kafka는 **ISR(In-Sync Replica)**라는 동기화된 Broker 집합을 기반으로 복제 상태를 관리

✅ 시각적 구조 예시

 
Kafka 클러스터 (5개의 Broker) Topic: user-events Partition: 0 Replication Factor: 3 → Partition 0이 다음과 같이 복제됨: - Broker 1: 리더 - Broker 2: 팔로워 - Broker 3: 팔로워

✅ 실무 및 TA 시험 포인트

  • replication.factor > broker 수로 설정하면 → Topic 생성 실패
  • 복제수가 많을수록 가용성은 높아지지만, 자원 소모도 증가
  • 리더 Broker가 죽으면 → ISR 중 하나가 새로운 리더로 승격

✅ 정리 요약

개념내용
Broker Kafka 메시지를 저장·관리하는 서버 단위
Replication Factor 하나의 Partition을 몇 개의 Broker에 복제할지 결정
관계 복제수를 늘리면 Broker 수가 늘어나야 하며, 가용성이 향상됨

필요하다면 TA시험 스타일의 복제수-장애-가용성 관계 문제나 ISR 및 리더 선출 시나리오형 문제도 제공해 드릴 수 있어요. 원하시면 요청해 주세요!

나의 말:

producer의 역할?

ChatGPT의 말:

Kafka에서 Producer는 시스템 또는 애플리케이션이 Kafka에 메시지를 보내는 역할을 담당하는 컴포넌트입니다. 실시간 데이터 파이프라인이나 이벤트 기반 시스템에서 매우 중요한 역할을 하며, 다양한 옵션과 전략으로 동작을 제어할 수 있습니다.

✅ Producer의 핵심 역할

기능설명
메시지 전송 Kafka Topic으로 데이터를 전송하는 주체
Partition 결정 메시지를 어느 Partition에 보낼지 결정 (기본 Round-robin 또는 키 기반 해시)
시리얼라이징 전송할 데이터를 Kafka가 이해할 수 있는 바이트 형태로 변환
재시도/확인 설정 메시지 전송 성공 여부 확인, 실패 시 재시도 등 내결함성 확보
배치 처리 성능 향상을 위해 여러 메시지를 묶어 전송 가능 (Batch)

✅ 동작 흐름

  1. Producer는 Kafka 클러스터의 Topic으로 메시지를 전송
  2. Partition을 선택 (직접 지정, 키 기반, Round-robin 등)
  3. Kafka Broker가 해당 Partition에 메시지를 저장
  4. 저장 성공 여부를 ACK(acknowledgement)로 반환

✅ 설정 가능한 주요 옵션

옵션설명
acks 0, 1, all 설정 가능
→ all이면 모든 replica에 저장되어야 성공 처리
retries 실패 시 재전송 횟수 설정
linger.ms 메시지를 일정 시간 모아 배치 전송
compression.type snappy, lz4 등 압축 사용 가능
key.serializer, value.serializer 메시지를 바이트로 변환할 Serializer 지정

✅ Producer의 전략적 기능

  • Exactly-once semantics (EOS) 지원
  • Idempotent producer 설정 가능 → 중복 메시지 방지
  • 키 기반 Partitioning으로 메시지 순서 보장

✅ 예시 코드 (Python)

 
from kafka import KafkaProducer producer = KafkaProducer( bootstrap_servers='localhost:9092', key_serializer=str.encode, value_serializer=str.encode ) producer.send('user-login-events', key='user1', value='login') producer.flush()

✅ TA 시험 관점 핵심 질문 포인트

  • Kafka Producer가 Partition을 결정하는 방법은?
  • acks=all 설정 시 장단점은?
  • Idempotent producer가 필요한 이유는?
  • Producer에서 메시지 순서를 보장받기 위한 조건은?

필요하다면, Consumer 구조, Exactly-once 처리 전략, 또는 MSA에서 Kafka Producer/Consumer 연계 시나리오도 설명해드릴게요.

나의 말:

acks 옵션값에 대해 설명해줘

ChatGPT의 말:

Kafka에서 acks(acknowledgements) 옵션은 Producer가 메시지를 Broker에 전송한 후, 성공 여부를 어떻게 판단할 것인지를 제어하는 매우 중요한 설정입니다. 이 옵션은 **데이터의 내구성(durability)**과 전송 지연(latency) 간의 트레이드오프를 조절합니다.

✅ acks 옵션 값 종류 및 설명

값의미특징
0 확인 안 함 (Fire and Forget) - Producer는 Broker의 응답을 기다리지 않음
- 가장 빠르지만 신뢰성 낮음
- 메시지가 손실될 수 있음
1 리더 Broker 응답만 확인 - 메시지가 리더 파티션에 성공적으로 기록되었는지만 확인
- 성능과 신뢰성 간 균형
- 리더가 장애 발생 시 복제본에 저장되지 않았을 수도 있음
all 또는 -1 모든 ISR(In-Sync Replica)에게 복제된 후 성공 응답 - 가장 높은 내구성 보장
- ISR 복제본 모두에게 반영될 때까지 기다림
- 속도는 느릴 수 있지만 데이터 손실 거의 없음

✅ ISR(In-Sync Replicas)이란?

  • ISR은 리더 Broker와 동기화된 상태인 팔로워 Broker의 집합입니다.
  • acks=all은 메시지가 이 ISR 집합의 모든 Broker에 기록된 경우에만 성공으로 간주합니다.

✅ 예시

 
producer = KafkaProducer( bootstrap_servers='localhost:9092', acks='all', # 가장 안전한 설정 retries=3, value_serializer=str.encode )

✅ 선택 기준 요약

상황추천 acks 값
성능 우선 (로그, 트래픽 많음) 0 또는 1
일반적인 비즈니스 이벤트 처리 1
중요 트랜잭션 처리 (금융, 주문 등) all

✅ TA 시험 스타일 예상 질문

Q1. Kafka에서 acks=all 설정의 장단점을 설명하시오.
Q2. acks=1과 acks=all의 차이점은 무엇인가?
Q3. acks=0 설정 시 장애 발생 시 어떤 문제가 발생할 수 있는가?

필요하다면 acks, idempotent producer, exactly-once 설정을 함께 연계한 고급 시나리오 문제도 제공해 드릴 수 있습니다. 원하시면 말씀 주세요.

나의 말:

consumer와 파티션 관계를 설명해줘

ChatGPT의 말:

Kafka에서 Consumer와 Partition의 관계는 Kafka의 병렬 처리, 확장성, 메시지 순서 보장에 핵심적인 구조입니다. 이 구조를 이해하면 성능 최적화, 부하 분산, 순서 보장 설계에 큰 도움이 됩니다.

✅ 기본 구조 요약

 
Topic → 여러 개의 Partition → 각 Partition은 하나의 Consumer에게만 할당

즉,

  • Partition은 1개의 Consumer에게만 할당될 수 있음
  • Consumer 1명은 여러 Partition을 할당받을 수 있음

✅ Consumer ↔ Partition 관계 정리

조건설명
1 Topic에 4 Partition, Consumer 2명 각 Consumer가 2개 Partition씩 처리 (병렬 소비)
1 Topic에 4 Partition, Consumer 5명 Consumer 1명은 Partition을 할당받지 못함 (Partition 수보다 Consumer 수가 많으면 일부는 idle)
1 Consumer, N Partition 순차 처리되므로 처리 속도는 제한적
Consumer Group 사용 같은 Group 내의 Consumer들은 Partition을 나눠서 병렬로 처리

✅ Consumer Group 구조

  • 같은 Consumer Group에 속한 Consumer들은 Partition을 나눠서 병렬 처리
  • 서로 다른 Group은 독립적으로 같은 메시지를 읽을 수 있음 (→ pub-sub 구조 가능)
 
Topic: user-events (3 Partition) Consumer Group A ├─ Consumer A1 → Partition 0 ├─ Consumer A2 → Partition 1 ├─ Consumer A3 → Partition 2 Consumer Group B ├─ Consumer B1 → Partition 0~2 (전부 혼자 읽음)

✅ Partition 수가 중요한 이유

항목설명
병렬성 향상 Partition 수가 많을수록 Consumer 병렬 처리 가능성 증가
메시지 순서 보장 Partition 내에서는 메시지 순서가 보장됨
→ 특정 키(hash key) 기반으로 같은 Partition에 메시지를 보내면 순서 유지 가능
확장성 제약 Partition 수보다 많은 Consumer는 비효율적 (idle 상태 발생)

✅ 실무/TA 시험 포인트

  • Partition = 병렬 처리 단위, Consumer = 처리 단위
  • Consumer Group은 하나의 Partition을 동시에 2명 이상이 처리하지 않음
  • Topic의 Partition 수는 사전에 잘 계획해야 함 (추가는 가능하나 줄이는 건 어렵고 주의 필요)

✅ 예상 시험 질문 예시

Q1. Kafka에서 하나의 Partition을 동시에 여러 Consumer가 처리할 수 있는가?

❌ 아니다. 한 시점에 하나의 Partition은 한 Consumer만 처리 가능

Q2. Consumer 수가 Partition 수보다 많을 경우, 어떤 일이 발생하는가?

👉 일부 Consumer는 Partition을 할당받지 못하고 idle 상태가 됨

Q3. Consumer Group 간에는 Partition을 공유하는가?

❌ 아니다. Consumer Group 간에는 독립적으로 메시지를 소비한다 (pub-sub 모델)

필요하다면 Consumer Group Rebalancing, Sticky Assignor 전략, 또는 메시지 순서 보장 시나리오 문제도 제공할 수 있습니다. 원하시면 말씀 주세요.

'MSA Outer > Backing Service' 카테고리의 다른 글

Backing Service란?(개념)  (0) 2025.05.09

**Cloud Native(클라우드 네이티브)**는 단순히 클라우드에서 실행되는 애플리케이션을 뜻하는 것이 아니라, 클라우드 환경을 최대한 활용하기 위해 설계된 아키텍처와 개발·운영 방식 전체를 말합니다. 즉, 클라우드의 유연성·탄력성·자동화 역량을 본질적으로 내재화한 방식입니다.

✅ Cloud Native의 핵심 요소 (4대 기둥)

핵심 요소설명
1. 컨테이너(Containerization) 앱과 그 실행환경을 함께 패키징 → 일관된 배포/이식성 보장 (예: Docker)
2. 마이크로서비스(Microservices) 애플리케이션을 작고 독립적인 서비스 단위로 구성하여 빠른 배포와 확장 가능
3. 지속적 통합·배포(CI/CD) 코드 변경을 자동으로 빌드, 테스트, 배포하여 빠른 릴리즈와 품질 보장
4. 동적 오케스트레이션(Orchestration) 컨테이너를 자동으로 배포·스케일·복구 (예: Kubernetes)

✅ 추가적인 중요 개념

개념설명
DevOps/SRE 문화 개발과 운영의 통합 → 자동화/관측성 중심의 운영 체계
불변 인프라(Immutable Infrastructure) 인프라를 수동으로 수정하지 않고, 항상 재생성하여 배포
자기치유(Self-healing) 실패한 서비스나 노드는 자동으로 복구되도록 설계
Observability (관측성) 로그, 메트릭, 트레이싱 등으로 복잡한 시스템 상태를 가시화
서비스 메시(Service Mesh) 마이크로서비스 간 통신을 보안, 가시성, 제어 가능하게 함 (예: Istio, Linkerd)

✅ Cloud Native의 목표

  • 빠르고 안전한 릴리즈
  • 확장성과 장애 복원력 확보
  • 비용 최적화된 자원 활용
  • 고속 변화 대응력 (애자일)

📌 TA 시험 스타일 요약 정리

질문핵심 답변
Cloud Native의 핵심 구성 요소는? 컨테이너, 마이크로서비스, CI/CD, 오케스트레이션
Cloud Native가 전통적 방식보다 가지는 이점은? 빠른 배포, 유연한 확장, 장애 복구, 클라우드 최적화 운영
Kubernetes는 Cloud Native에서 어떤 역할인가? 컨테이너 오케스트레이션을 통해 배포·스케일·복구 자동화

 

☁️ Cloud Native 기반 시스템 설계 시나리오

💡 시나리오 개요

“한 쇼핑몰 플랫폼을 클라우드 네이티브 아키텍처로 재설계하려고 한다. 이 플랫폼은 웹/앱 트래픽이 급증할 수 있고, 이벤트 기반 처리와 비동기 메시징, 고가용성, 장애 복구, 탄력적인 확장이 가능해야 한다.”

✅ 1. 시스템 구성 개요

구성요소기술 스택설명
프론트엔드 SPA (React/Angular), CDN, Azure Front Door 앱/웹 사용자 UI, 캐싱 및 글로벌 라우팅
API Gateway Azure API Management / Kong 인증, 라우팅, 트래픽 제어
백엔드 서비스 Microservices (Spring Boot / Node.js) 주문, 결제, 배송, 상품 등 각각 독립 서비스
메시징 시스템 Kafka / Azure Event Hubs 주문 이벤트, 알림, 재고 변경 등 비동기 처리
DB 계층 PostgreSQL (Azure Database), Redis (캐시), Cosmos DB (NoSQL) 데이터 분류별 최적 DB 구성
Storage Azure Blob Storage 이미지, 로그, 백업 파일 저장
CI/CD GitHub Actions + Azure DevOps 자동 배포 및 테스트
관측성 (Observability) Azure Monitor + Prometheus + Grafana 로그, 지표, 트레이싱
컨테이너 실행환경 Azure Kubernetes Service (AKS) 모든 마이크로서비스는 컨테이너화되어 K8s 상에서 실행됨

✅ 2. 핵심 설계 요소

🔹 마이크로서비스 분리 기준

서비스역할
사용자 서비스 회원가입, 로그인, 인증
상품 서비스 상품 등록, 조회, 검색
주문 서비스 주문 생성, 결제 상태 관리
배송 서비스 송장 등록, 배송 상태 조회
알림 서비스 이메일, 푸시 알림 발송 (비동기 처리)

→ 서비스 간 통신은 REST + Kafka(Event-driven)

🔹 Event-Driven 아키텍처 적용

  • 주문 완료 → Kafka → 배송 서비스 구독 → 배송 예약
  • 상품 품절 → Kafka → 알림 서비스 구독 → 재입고 알림 전송

→ 비동기 메시징으로 서비스간 결합도 낮춤

🔹 Auto Scaling과 장애 복구 구조

  • 각 서비스는 Kubernetes Horizontal Pod Autoscaler (HPA) 적용
  • Kafka, Redis, DB는 Azure Zone Redundancy / Replication 사용
  • API Gateway는 Rate Limiting + Circuit Breaker 패턴 사용
  • 장애 감지 시 AKS 자동 재배포, 롤백

🔹 DevOps / CI-CD 파이프라인

  • PR 병합 → 자동 빌드 + 컨테이너 이미지 생성 → AKS 배포
  • 배포 전 통합 테스트, 보안 스캔 통과 필수

🔹 보안 및 인증

  • API Gateway에서 JWT 인증 처리
  • AKS 내부 네트워크 통신은 mTLS (Service Mesh) 적용
  • DB 접근은 Managed Identity + VNet 통제

✅ 3. 확장성/가용성/복구 전략

목표구현 방식
수평 확장 AKS + HPA, Kafka Partition 수 조정
장애 복구 Kafka ISR 구조, DB 복제, Storage GRS
리전 장애 대비 Azure Traffic Manager + 멀티 리전 배포
배포 무중단성 Blue/Green 또는 Canary Deployment 적용
운영 모니터링 로그/지표/트레이싱 통합 → 알림과 대시보드 구성

✅ 정리 요약

영역요약
아키텍처 스타일 Microservices + Event-Driven + DevOps
클라우드 특징 Auto-Scaling, Self-Healing, Observability
핵심 기술 AKS, Kafka/Event Hubs, API Gateway, Redis, CI/CD
장점 느슨한 결합, 빠른 릴리즈, 확장 용이, 장애 복원력 강화

☁️ Cloud Native 기반 시스템 설계 시나리오 – TA 문제집 (정답/해설 포함)

✅ 문항 1

Q. MSA 아키텍처를 Cloud Native 환경에 배포할 때 가장 적절한 실행 환경은?
A. EC2 위에 Tomcat 직접 실행
B. VM에 Docker Compose 구성
C. Kubernetes 기반의 컨테이너 오케스트레이션
D. AWS Lambda로 전체 서비스 구현

✔ 정답: C
📘 해설: Kubernetes는 Cloud Native 아키텍처에서 마이크로서비스를 자동 배포, 스케일링, 복구할 수 있게 해주는 핵심 플랫폼이다.
난이도: 하

✅ 문항 2

Q. Cloud Native 환경에서 서비스 간 직접 호출로 인해 발생할 수 있는 문제는?
A. 무한 스케일링 가능
B. 서비스 간 결합도 증가
C. 이벤트 로그 누락
D. 컨테이너 리소스 부족

✔ 정답: B
📘 해설: 서비스 간 직접 REST 호출은 높은 결합도를 유발하여 장애 전파, 배포 어려움 등을 초래한다. 이벤트 기반 처리로 대체하는 것이 이상적이다.
난이도: 중

✅ 문항 3

Q. Kafka를 사용하는 이유로 적절하지 않은 것은?
A. 서비스 간 비동기 이벤트 처리
B. 메시지 순서 보장
C. 트랜잭션 DB 락 방지
D. REST API 대체용 동기 호출

✔ 정답: D
📘 해설: Kafka는 비동기 메시지 브로커로, REST와는 반대되는 통신 방식이다. 동기 호출 용도로는 적절하지 않다.
난이도: 하

✅ 문항 4

Q. Cloud Native 설계 시 API Gateway의 주요 역할은?
A. DB 복제
B. 메시지 브로커
C. 서비스 간 직접 통신
D. 인증/인가, 라우팅, Rate-Limiting

✔ 정답: D
📘 해설: API Gateway는 외부 요청의 인증, 라우팅, 트래픽 제어, 로깅 등을 중앙 집중형으로 처리하는 Cloud Native 핵심 구성요소다.
난이도: 하

✅ 문항 5

Q. Kubernetes에서 Pod 장애 발생 시 자동 복구를 담당하는 리소스는?
A. PodPolicy
B. ReplicaSet
C. HPA
D. Node Affinity

✔ 정답: B
📘 해설: ReplicaSet은 지정된 수의 Pod가 항상 실행되도록 보장하며, 장애 발생 시 자동으로 새 Pod를 생성한다.
난이도: 중

✅ 문항 6

Q. Cloud Native에서 무중단 배포 및 복구를 위한 전략은?
A. Rolling Update
B. Blue/Green
C. Canary
D. 모두 해당

✔ 정답: D
📘 해설: 모든 배포 전략은 서비스 중단 없이 변경을 적용하거나 복구할 수 있도록 설계되었다. 상황에 따라 적절한 전략을 선택해야 한다.
난이도: 중

✅ 문항 7

Q. Kafka Topic의 데이터를 실시간으로 검색 시스템에 적재하려 할 때 적절한 Sink Connector는?
A. FileStream
B. JDBC
C. Elasticsearch
D. S3

✔ 정답: C
📘 해설: Elasticsearch Sink Connector는 Kafka Topic의 데이터를 실시간으로 Elasticsearch 인덱스로 전송하여 검색 가능하게 한다.
난이도: 중

✅ 문항 8

Q. Cloud Native CI/CD 구성요소가 아닌 것은?
A. GitHub Actions
B. Jenkins
C. Ansible
D. Prometheus

✔ 정답: D
📘 해설: Prometheus는 모니터링 도구이지 CI/CD 구성 요소는 아니다. Ansible은 배포 자동화에 사용될 수 있다.
난이도: 하

✅ 문항 9

Q. 컨테이너 보안을 위한 필수 조치는?
A. root 권한으로 실행
B. 공개 이미지 사용
C. 이미지 CVE 취약점 스캔
D. 모든 네트워크 허용

✔ 정답: C
📘 해설: 이미지 보안 검사 및 취약점(CVE) 제거는 컨테이너 보안의 핵심이다. 나머지는 보안 위협을 유발할 수 있다.
난이도: 중

✅ 문항 10

Q. 서비스 메시(Service Mesh)의 주요 이점은?
A. DB 처리 속도 향상
B. API Gateway 대체
C. 트래픽 제어, 보안, 관측성 향상
D. 컨테이너 배포 간소화

✔ 정답: C
📘 해설: Service Mesh는 마이크로서비스 간 통신을 통제하고, TLS 암호화 및 분산 트레이싱 등의 기능을 지원한다.
난이도: 중

✅ 문항 11

Q. Kafka에서 메시지 순서를 유지하려면 반드시 지정해야 하는 것은?
A. Consumer Group
B. Topic 이름
C. Key 값
D. Compression Type

✔ 정답: C
📘 해설: Kafka는 Key 값을 기준으로 Partition을 정하므로, 동일 Key는 같은 Partition에 저장되어 순서가 유지된다.
난이도: 중

✅ 문항 12

Q. Kubernetes에서 외부에서 Pod에 접근하려면 사용하는 리소스는?
A. NodePort
B. ConfigMap
C. CronJob
D. PVC

✔ 정답: A
📘 해설: NodePort는 클러스터 외부에서 Pod로 직접 접근할 수 있도록 포트를 개방한다.
난이도: 하

✅ 문항 13

Q. 상태 저장형 데이터베이스를 컨테이너로 배포하는 것이 위험한 이유는?
A. 라이선스 이슈
B. 컨테이너는 네트워크를 사용하지 못함
C. 상태를 저장해야 하며, I/O 부하가 크기 때문
D. K8s에서 지원하지 않음

✔ 정답: C
📘 해설: 상태 저장 DB는 고성능 디스크와 고가용성이 필요하므로, 일반적인 컨테이너 배포 환경에서는 위험하다.
난이도: 중

✅ 문항 14

Q. CI/CD 파이프라인에서 배포 실패 시 자동 롤백을 지원하는 전략은?
A. Blue/Green
B. Helm uninstall
C. Git revert
D. Manual failover

✔ 정답: A
📘 해설: Blue/Green 배포는 실패 시 이전 환경으로 즉시 트래픽을 전환할 수 있는 구조를 제공한다.
난이도: 중

✅ 문항 15

Q. Kafka 메시지를 실시간으로 필터링, 집계, 변환할 수 있는 도구는?
A. Kafka Connect
B. Kafka Streams
C. Kafka Consumer
D. Flink Connect

✔ 정답: B
📘 해설: Kafka Streams는 Kafka 내 메시지를 처리하는 경량 스트림 처리 라이브러리로, 필터, join, groupBy 등을 지원한다.
난이도: 중

✅ 문항 16

Q. Kubernetes 환경에서 컨테이너 간 통신 보안을 위한 리소스는?
A. RBAC
B. NetworkPolicy
C. Service
D. Affinity

✔ 정답: B
📘 해설: NetworkPolicy는 Pod 간 트래픽 허용/차단을 정의해 통신 보안을 강화한다.
난이도: 중

✅ 문항 17

Q. Azure Event Hubs의 Kafka 대비 주요 장점은?
A. Kafka보다 빠름
B. 완전관리형 서비스 + Kafka API 호환
C. REST 기반 API 제공
D. DB 저장 기능 내장

✔ 정답: B
📘 해설: Event Hubs는 Kafka 프로토콜을 지원하며, 인프라 운영이 필요 없는 완전관리형 스트리밍 서비스이다.
난이도: 중

✅ 문항 18

Q. Kafka에서 메시지 재처리를 가능하게 해주는 구조적 요소는?
A. Topic 이름
B. Partition 수
C. Consumer Offset
D. Commit Timeout

✔ 정답: C
📘 해설: Kafka는 Offset 기반 소비 구조이기 때문에, 특정 Offset부터 재처리하거나 롤백할 수 있다.
난이도: 중

✅ 문항 19

Q. Cloud Native 환경에서 로그 수집 및 검색 시스템의 일반적인 구성은?
A. Kafka + Prometheus
B. Fluentd + Elasticsearch + Kibana
C. Redis + Grafana
D. Kafka + PostgreSQL

✔ 정답: B
📘 해설: Fluentd는 로그를 수집하여 Elasticsearch에 저장하고, Kibana로 시각화하는 구조는 표준적인 로그 수집 아키텍처이다.
난이도: 중

✅ 문항 20

Q. 모놀리식 애플리케이션을 컨테이너로 단순히 옮겼을 때 발생할 수 있는 문제는?
A. 확장성 증가
B. 장애 격리 어려움
C. 서버 수 감소
D. 보안 강화

✔ 정답: B
📘 해설: 단일 서비스로 구성된 모놀리식을 컨테이너화하더라도 기능이 나뉘지 않기 때문에, 장애 발생 시 전체가 영향을 받는다.
난이도: 중

 

🧠 Cloud Native 시스템 설계 – 암기카드 요약본

키워드설명 요약
Cloud Native 컨테이너, 마이크로서비스, CI/CD, DevOps, 자동화를 기반으로 한 현대적 시스템 설계 방식
Kubernetes (K8s) 컨테이너 오케스트레이션 플랫폼으로 배포, 스케일링, 복구를 자동화함
MSA 각 기능을 독립 서비스로 분리하여 유연성과 장애 격리성 확보
API Gateway 인증, 라우팅, 로깅, 트래픽 제어 등의 공통 기능을 집중 관리
Kafka 대용량 실시간 이벤트 스트리밍 플랫폼 (Topic-Partition 구조)
Kafka Offset 메시지 재처리를 가능하게 하는 Consumer 측 메시지 위치 정보
Kafka Key 동일 키는 동일 Partition에 저장, 메시지 순서 보장 가능
Kafka Sink Connector Kafka 데이터를 외부 시스템(Elasticsearch 등)으로 전송
Service Mesh 마이크로서비스 간 통신 제어, TLS, 분산 추적, 보안 향상
Helm Kubernetes 애플리케이션을 템플릿 기반으로 관리하는 패키지 매니저
Canary/Blue-Green 배포 점진적 또는 빠른 롤백 가능한 무중단 배포 전략
Prometheus 시계열 기반 모니터링 시스템, K8s와 통합 용이
Grafana Prometheus와 연동하여 시각화 대시보드 구성
Fluentd/Elasticsearch/Kibana(ELK) 로그 수집, 저장, 시각화 구성
CI/CD 파이프라인 코드 변경을 자동 빌드, 테스트, 배포하는 자동화된 워크플로우
RBAC (Role Based Access Control) 사용자 역할 기반 권한 제어 방식
NetworkPolicy K8s Pod 간 네트워크 트래픽 제어 정책
PVC (PersistentVolumeClaim) Pod가 외부 스토리지를 요청하는 방법
StatefulSet 상태 저장 애플리케이션 배포 시 사용되는 K8s 리소스
Event Hubs (Azure) Kafka 호환 가능, 완전관리형 메시지 스트리밍 플랫폼

Disaster Recovery (DR) 설계는 고가용성 아키텍처의 핵심이며, TA 역량 평가와 실전 클라우드/온프레미스 인프라 설계에서 반드시 등장하는 고급 주제입니다.

아래에 DR 개요, 유형별 비교, 설계 기준, 문제, 암기카드/인덱스 요약까지 직무역량 평가/블로그 오픈북용으로 정리해드리겠습니다.

🛡️ Disaster Recovery (DR) 설계

장애·재해 상황에서 서비스 연속성 보장을 위한 설계 전략

✅ 1. DR 설계 목적 및 개요

항목설명
목적 장애/재해 상황에서도 업무 연속성(Business Continuity) 확보
대상 자연재해, 인프라 장애, 데이터 유실, 랜섬웨어, 네트워크 단절
핵심 지표 RTO (Recovery Time Objective)
RPO (Recovery Point Objective)

📌 용어 요약

  • RTO: 장애 발생 → 서비스 복구까지 걸리는 시간
  • RPO: 복구 시점 기준으로 허용 가능한 데이터 손실량

🧱 2. DR 유형별 설계 전략

유형설명RTO/RPO비용예시
Cold Site 예비 센터만 구축, 서비스/데이터는 없음 수일 낮음 장비만 구축
Warm Site 일부 시스템/데이터 미리 배치 수 시간 중간 백업+일부 미운영
Hot Site 모든 시스템/데이터 상시 운영 수 분 높음 실시간 복제
Active-Passive 주 → 예비 노드 전환 중 중간 RDS Multi-AZ
Active-Active 다수 리전/센터 동시에 운영 낮음 매우 높음 GSLB, Aurora Global

🏗️ 3. DR 설계 아키텍처 비교

🔹 Cold Site 구성도

 
[Primary Site] ↑ 백업 주기적 수행 [Secondary Site (장비만 존재)] → 재해 발생 시 설치 + 데이터 복원

🔹 Active-Passive 구성

 
[Active Site] ←→ [Passive Site] (서비스 운영) (데이터 복제, 미운영)

🔹 Active-Active 구성

 
[Region A] ⇄ [Region B] (양쪽 모두 서비스, 트래픽 분산 + 데이터 Sync)

🔐 4. 실무 설계 요소 (클라우드/온프레미스 공통)

항목고려 사항
데이터 복제 실시간 복제(Sync), 비동기 복제(Async)
DNS 이중화 Route53, GSLB, Geo DNS
네트워크 구성 전용선, VPN, VNet Peering, Transit Gateway
스토리지 Blob, Object, NFS 등의 Cross-Region Replication
데이터 무결성 복제 오류 감지 및 검증
Failover 자동화 DB, LB, App 수준 전환 자동화 (ex. Route53 Failover Policy)

☁️ 5. 클라우드별 DR 지원 예시

플랫폼DR 전략 지원
AWS Route53 GSLB, S3 CRR, Aurora Global, CloudEndure
Azure Azure Site Recovery, GRS(GRS+RA), Azure Front Door
GCP Cloud DNS, GCS Multi-Region, Spanner Global

🎓 6. 직무역량 평가 예시 문제

문제 1 [중]

다음 중 Cold Site DR 구성의 특징으로 적절한 것은?

A. 서비스가 실시간으로 두 위치에서 실행된다
B. 재해 발생 시 수분 이내 자동 전환된다
C. 예비 센터에 장비만 배치되고 서비스는 중단 상태이다
D. 실시간 동기 복제를 통해 항상 최신 데이터가 유지된다

정답: C
해설: Cold Site는 가장 저비용 DR 구성으로, 미리 시스템을 구동하지 않음

문제 2 [상]

Active-Active DR 구성의 주요 리스크로 적절한 것은?

A. 데이터 복구 시간이 길다
B. 예비 사이트가 장애 시 사용할 수 없다
C. DNS 장애에 대응하지 못한다
D. 실시간 동기화 중 충돌로 인한 데이터 불일치 가능성

정답: D
해설: Active-Active 구성은 동시 쓰기나 네트워크 분리 시 동기화 충돌 발생 가능

문제 3 [상]

RTO = 1시간, RPO = 0분 기준의 DR 설계로 가장 적합한 것은?

A. Cold Site
B. Warm Site
C. Active-Passive with async replication
D. Active-Active with sync replication

정답: D
해설: 0분 데이터 손실을 허용하지 않기 때문에 Sync 복제가 필수

🧠 암기카드 요약

키워드설명
RTO 복구 시간 목표 (예: 5분, 1시간)
RPO 복구 시점 목표 (데이터 손실 허용 범위)
Cold Site 장비만 존재, 복구 시간 오래 걸림
Warm Site 일부 시스템 사전 배치, 복구 시간 중간
Hot Site 상시 운영, 빠른 전환
Active-Passive 1차 운영, 2차 대기 (Failover 발생 시 전환)
Active-Active 양쪽 운영, GSLB 기반 트래픽 분산
GSLB 지리적 DNS 분산, 리전 단위 장애 회피
CloudEndure AWS 실시간 DR SaaS 도구

📁 블로그 오픈북용 키워드 인덱스

  • Disaster Recovery 설계 유형
  • RTO RPO 정의
  • Cold Site Warm Site Hot Site
  • Active-Active DR 구성
  • Active-Passive DR 설계
  • DR 자동화 전환
  • 클라우드 DR 서비스 비교
  • Route53 Failover / GSLB
  • DR 테스트 절차
  • DR 설계 시 고려할 질문

 

🛡️ DR 설계 시나리오 기반 실전문제 (20문항)

✅ NO.01 [중]

당신의 조직은 AWS 환경에서 2개 리전(A, B)을 운영 중이며, RTO 1시간, RPO 15분이 요구된다. 가장 적절한 DR 구성 방식은?

A. Cold Site
B. Warm Site
C. Active-Passive with Async Replication
D. Active-Active

정답: C
해설: Warm은 느리고, Active-Active는 비용이 크며 Sync는 불필요. Async Passive가 요구 조건 충족.

✅ NO.02 [상]

Active-Active DR 구성을 사용하는 글로벌 서비스에서 리전 간 네트워크 분리(Network Partition)가 발생했다. 이때 가장 우려되는 것은?

A. 데이터 복제 속도 저하
B. 인스턴스 간 부하 불균형
C. 데이터 일관성 충돌
D. 트래픽 증가로 인한 비용 상승

정답: C
해설: Active-Active는 양쪽에서 쓰기 가능하여 동시 쓰기 시 일관성 문제 발생 위험.

✅ NO.03 [중]

Azure 환경에서 Geo-Redundant Storage(GRS)는 어떤 DR 구성에 해당하는가?

A. Cold Site
B. Active-Passive
C. Active-Active
D. Warm Site

정답: B
해설: GRS는 주 리전에서만 사용하고 백업용으로 비동기 복제됨.

✅ NO.04 [하]

Cold Site 구성의 특징으로 가장 적절한 것은?

A. 모든 시스템과 데이터가 실시간으로 동기화되어 있다
B. DR 센터에 인프라만 준비되어 있고 운영은 하지 않는다
C. 장애 발생 시 즉시 자동으로 전환된다
D. 가장 높은 비용이 발생한다

정답: B

✅ NO.05 [상]

주 리전 장애 시 자동으로 리전 간 전환되도록 하기 위해 가장 먼저 고려해야 할 서비스는?

A. 고정 IP 구성
B. Auto Scaling 그룹
C. GSLB 또는 DNS Failover
D. VPC 피어링

정답: C

✅ NO.06 [중]

DR 설계 시 RTO가 짧아야 하는 경우에 적절한 구성은?

A. 매일 백업 후 외부 저장소 이동
B. Cold Site
C. Active-Passive with Sync Replication
D. 수동 DB 복원

정답: C

✅ NO.07 [하]

RPO 0분이 요구되는 서비스에서 반드시 적용해야 하는 복제 방식은?

A. Async
B. Snapshot
C. Tape Backup
D. Sync

정답: D

✅ NO.08 [상]

Kubernetes 클러스터를 멀티 리전 DR 환경으로 구성할 때 가장 중요한 요소는?

A. 동일 CIDR 설정
B. Node 라벨링
C. 클러스터 간 DNS 라우팅 및 상태 모니터링
D. Helm Chart 통일

정답: C

✅ NO.09 [중]

Warm Site의 단점으로 가장 적절한 것은?

A. 운영 비용이 매우 높다
B. 복구 시간이 며칠 걸린다
C. 데이터 일관성 유지가 어렵다
D. 일부 시스템만 구동되므로 전체 성능 테스트가 어렵다

정답: D

✅ NO.10 [중]

다음 중 DR 테스트의 주요 목적이 아닌 것은?

A. 시스템의 가용성을 검증
B. 데이터 일관성 유지 확인
C. 실제 장애 발생 빈도를 예측
D. 복구 절차의 유효성 검증

정답: C

✅ NO.11 [하]

RTO가 24시간, RPO가 12시간인 서비스에 적절한 DR 방식은?

A. 실시간 복제 + Active-Active
B. Cold Site + Tape Backup
C. GSLB 기반 Active-Passive
D. RDS Multi-AZ 구성

정답: B

✅ NO.12 [상]

DR 전환 중 데이터 손실 없이 상태를 유지하기 위한 전략으로 적절하지 않은 것은?

A. 실시간 데이터 복제
B. Sync 복제
C. LAG 기반 전환 지연
D. 재해 발생 후 Tape 복구

정답: D

✅ NO.13 [중]

AWS CloudEndure의 특징으로 적절한 것은?

A. 수동 백업 시스템
B. 인프라 비용이 가장 적게 든다
C. 온프레미스 → 클라우드 실시간 복제 지원
D. GSLB 기능 제공

정답: C

✅ NO.14 [상]

Active-Passive 구성에서 장애 전환이 실패할 가능성이 가장 큰 요소는?

A. Passive 사이트에서 서비스가 이미 동작 중임
B. 네트워크 성능 저하
C. DNS 전환 실패 또는 TTL 지연
D. DB Write Conflict

정답: C

✅ NO.15 [중]

RDS Multi-AZ 구성의 DR 특성으로 적절하지 않은 것은?

A. 자동 장애 전환
B. 동일 리전 내에서만 구성 가능
C. 수동 백업 복구 방식
D. 데이터 손실 없는 복제

정답: C

✅ NO.16 [하]

DR 설계의 주요 목표가 아닌 것은?

A. 서비스 무중단 운영
B. 장애 발생 시 복구 시간 최소화
C. 백업 데이터 압축률 향상
D. 데이터 손실 최소화

정답: C

✅ NO.17 [중]

멀티 리전 DR에서 트래픽 분산을 위해 가장 일반적으로 사용하는 방법은?

A. VPN 라우팅
B. SSH 포트 포워딩
C. 글로벌 DNS(GSLB) 라우팅
D. LB IP 수동 등록

정답: C

✅ NO.18 [중]

DR 테스트 주기가 길어지면 발생할 수 있는 리스크는?

A. 스토리지 비용 증가
B. 전환 속도 향상
C. 복구 스크립트 오류 및 절차 누락
D. RTO 감소

정답: C

✅ NO.19 [상]

Kubernetes에서 멀티 클러스터 기반 DR을 구성할 때 반드시 고려해야 할 요소는?

A. Ingress Controller는 클러스터당 하나만 둔다
B. etcd는 외부 백업이 불필요하다
C. 클러스터 간 인증 통합, 동일 네임스페이스 구조
D. 모두 동일한 kube-proxy 설정 사용

정답: C

✅ NO.20 [중]

DR 설계 시 데이터 무결성을 검증하는 가장 좋은 방법은?

A. 백업 압축 로그 확인
B. 장애 후 운영자 보고
C. 정기적 검증을 위한 체크섬 비교 자동화
D. 백업 용량 증가 모니터링

정답: C

🧠 활용 팁

  • 이 문제들은 모두 RTO/RPO 요구사항 기반 시나리오 판단 능력, DR 구성 비교, 클라우드 서비스 활용도, 장애 전환 절차 설계력을 평가합니다.
  • 실제 시험 대비 시에는 “요구조건 → 복구 방식 도출 → 위험 요소 식별” 흐름으로 사고하는 것이 핵심입니다.

'서버 시스템 > 서버 아키텍처' 카테고리의 다른 글

멀티 존(Multi-Zone) / 멀티 리전(Multi-Region) 고가용성 설계  (0) 2025.09.02
Kubernetes 기반 서버 인프라 구성  (0) 2025.09.02
MSA(Microservice Architecture)의 Inner/Outer Architecture 구조  (0) 2025.09.02
서버 아키텍처 기본 개념 #2  (0) 2025.09.01

멀티 존(Multi-Zone) / 멀티 리전(Multi-Region) 고가용성 설계는 TA(Technical Architect) 직무역량 평가 및 클라우드 인프라 설계/운영 실무에서 고난이도 주제입니다.

아래에 실무+시험+블로그 오픈북용으로 구조화해 정리드립니다.

🌐 멀티 존 / 멀티 리전 고가용성 설계

고가용성(High Availability)을 위해 장애 도메인(Failure Domain)을 분산하여 서비스 중단 없는 운영을 목표로 하는 설계 전략

✅ 1. 기본 개념 요약

용어정의목적
Zone (AZ) 동일 리전 내 독립 전력/네트워크 인프라를 가진 데이터센터 단위 단일 장애 지점(Zone 장애) 회피
Region 지리적으로 물리적으로 격리된 데이터센터 집합 (서울, 도쿄 등) 자연재해/국가 단위 이슈 대응
멀티 AZ 구성 여러 AZ에 인스턴스 또는 서비스 분산 빠른 RTO (수분 내) 보장
멀티 리전 구성 주요 리전 외 예비 리전에 핫/콜드 백업 운영 재해복구(DR), 장거리 이중화

🧱 2. 구성 아키텍처 비교

구분멀티 AZ 구성멀티 리전 구성
구성 범위 단일 리전 내 여러 Zone 복수 리전
장애 범위 AZ 단위 장애 대응 전체 리전 장애 대응
지연 시간 매우 낮음 (ms급) 높음 (수십~수백 ms)
활용 사례 웹/DB 다중화, Auto Scaling DR 구성, 글로벌 서비스
예시 AWS EC2 Multi-AZ, RDS Multi-AZ GCP/Azure Global Load Balancer

🔧 3. 주요 설계 요소

📍 공통 설계 고려사항

  • SPoF 제거: LB, DB, 스토리지, DNS 이중화
  • 데이터 복제 전략: Sync vs Async
  • 장애 전환 절차: 수동/자동 장애 조치(Failover)
  • 트래픽 분산: GSLB(DNS 라우팅), Geo Routing

✅ 멀티 AZ 고가용성 설계

계층구성 전략
Web/WAS 각각 다른 AZ에 인스턴스 다중 배치, Auto Scaling
DB RDS Multi-AZ (Primary + Standby), DB Failover
스토리지 EBS/Elastic File System(Multi-AZ 지원 여부 확인)
LB ELB(Application LB)는 Zone 별로 다중 배치
세션 관리 Redis/Memcached 외부화 또는 Stateless 설계

✅ 멀티 리전 DR 설계

전략설명
Active-Passive Primary에서만 서비스, 장애 시 Secondary로 전환
Active-Active 양쪽 리전 동시에 운영, 트래픽 분산
Cold DR 예비 리전에 인프라만 준비, 서비스는 미실행
Hot DR 모든 인프라/데이터 상시 동기화, 즉시 전환 가능

☁️ 4. 클라우드 서비스별 HA 지원 예시

플랫폼멀티 AZ 지원멀티 리전 DR
AWS RDS Multi-AZ, ALB, Auto Scaling Route53 + S3 Cross-Region Replication, Aurora Global
Azure Availability Zone, Load Balancer Azure Front Door, Geo-Redundant Storage (GRS)
GCP Zonal vs Regional Cluster Cloud DNS, GCS Multi-Region, GKE Multi-Cluster

🎯 5. 직무역량 평가 예상문제

문제 1 [중]

멀티 AZ 고가용성 설계 시 고려해야 할 요소로 적절하지 않은 것은?

A. 웹 서버를 서로 다른 AZ에 배치
B. 세션 데이터를 외부 Redis로 저장
C. 데이터베이스는 단일 AZ에만 배포
D. Auto Scaling 그룹은 모든 AZ에 포함

정답: C
해설: 고가용성을 위해 DB도 Multi-AZ로 구성해야 함.

문제 2 [상]

멀티 리전 Active-Active 구성 시 발생할 수 있는 주요 문제는?

A. 저장소가 이중화되어 장애 전환이 느리다
B. 트래픽 분산이 불가능하다
C. 데이터 동기화 지연 및 일관성 이슈
D. 하나의 DNS만 운영이 가능하다

정답: C
해설: 리전 간 거리로 인한 지연 및 일관성(Consistency) 충돌 위험이 존재함.

문제 3 [상]

Kubernetes 기반 멀티 리전 구성을 위해 반드시 고려해야 할 요소는?

A. 노드 풀 크기
B. 단일 Ingress Controller
C. 클러스터 간 서비스 디스커버리 및 DNS
D. Pod 보안 설정

정답: C
해설: 멀티 클러스터 환경에서는 서비스 간 통신(DNS, Ingress, 인증)이 핵심

🧠 암기카드 요약

키워드설명
AZ (Availability Zone) 하나의 리전 내 데이터센터 단위 장애 도메인
Region 물리적으로 완전 분리된 클라우드 데이터센터 위치
Active-Passive 주 리전만 운영, 예비 리전은 대기 상태
RTO 복구 소요 시간 (Recovery Time Objective)
RPO 허용 가능한 데이터 손실량 (Recovery Point Objective)
GSLB 글로벌 DNS 라우팅으로 리전 간 트래픽 분산
Aurora Global DB 리전 간 DB 실시간 복제 제공

🧩 오픈북용 키워드 인덱스 (Ctrl+F 대비용)

  • Multi-AZ 고가용성 구성 예시
  • Multi-Region DR 전략
  • RTO RPO 정의
  • AWS Cross-Region Replication
  • GSLB DNS 분산
  • Active-Passive DR
  • 멀티리전 장애 복구 절차

 

🌍 멀티 존 / 멀티 리전 고가용성 설계 실전 문제집 (20제)

✅ NO.01 [중]

멀티 AZ 구성이 필요한 이유로 가장 적절한 것은?

A. 비용 절감
B. 전력 효율 향상
C. 장애 도메인 분리
D. 데이터 일관성 보장

정답: C
해설: Availability Zone은 서로 물리적으로 격리된 전원/네트워크 인프라로, 단일 장애 도메인을 분리하는 목적.

✅ NO.02 [하]

AWS에서 고가용성을 위해 서로 다른 AZ에 EC2 인스턴스를 배치하려고 한다. 적절한 방법은?

A. 동일한 VPC와 동일한 Subnet 사용
B. VPC는 공유하고, Subnet은 다른 AZ에 구성
C. 서로 다른 Region 사용
D. 동일한 VPC, 동일한 AZ, 다른 Subnet 사용

정답: B

✅ NO.03 [중]

멀티 리전 구성의 주요 목적은?

A. 데이터 저장 비용 절감
B. 내부 네트워크 지연 최소화
C. 대규모 배포 자동화
D. 지역 단위 재해 대비 및 글로벌 서비스

정답: D

✅ NO.04 [상]

멀티 리전 Active-Active 구성에서 발생할 수 있는 대표적인 문제는?

A. 부하 분산 실패
B. DNS 라우팅 실패
C. 데이터 동기화 충돌
D. 스토리지 용량 초과

정답: C

✅ NO.05 [중]

AWS Route53의 기능 중 리전 간 자동 장애 전환(Failover) 기능을 제공하는 구성은?

A. Geolocation Routing
B. Weighted Routing
C. Failover Routing
D. Multivalue Routing

정답: C

✅ NO.06 [중]

멀티 AZ 구성을 고려할 때, 상태를 저장하는 서비스(예: DB)에 가장 적합한 방식은?

A. Stateless 배포
B. ELB를 사용한 단일 노드 구성
C. Multi-AZ 지원 스토리지 또는 DB 서비스 사용
D. NFS 직접 공유

정답: C

✅ NO.07 [상]

멀티 리전 Active-Passive 구성에서 "전환(Failover) 시간"을 줄이기 위해 가장 필요한 것은?

A. BGP 자동 구성
B. GSLB + 헬스체크 기반 전환
C. VPN 터널 동기화
D. Blob Storage 압축

정답: B

✅ NO.08 [중]

Azure에서 지역 간 고가용성을 위해 사용하는 서비스는?

A. VNet Peering
B. Application Gateway
C. Azure Front Door
D. NAT Gateway

정답: C

✅ NO.09 [하]

멀티 AZ 환경에서 Application Load Balancer(ALB)를 사용하는 경우의 특징은?

A. 단일 AZ에만 동작
B. 수동으로 인스턴스를 연결해야 함
C. 여러 AZ의 인스턴스로 자동 트래픽 분산
D. AZ 간 DNS 라우팅 제공

정답: C

✅ NO.10 [상]

GCP에서 리전 간 데이터 일관성을 보장하며 고가용성을 제공하는 글로벌 데이터베이스 서비스는?

A. Firestore
B. Spanner
C. BigQuery
D. Cloud SQL

정답: B

✅ NO.11 [중]

멀티 리전 구성 시 고려해야 할 필수 요소가 아닌 것은?

A. DNS 기반 트래픽 라우팅
B. 로그 및 모니터링 수집 방식
C. 각 리전의 비용 체계
D. 동일한 MAC 주소 사용

정답: D

✅ NO.12 [하]

멀티 리전 Active-Passive 구성에서 'Passive' 리전의 일반적인 상태는?

A. 사용자 요청을 처리하고 있다
B. 장애 발생 시 자동으로 종료된다
C. 데이터 복제만 수행하고 대기 상태이다
D. DNS 라우팅을 항상 받는다

정답: C

✅ NO.13 [상]

멀티 리전 환경에서 GSLB(Global Server Load Balancing)가 중요한 이유는?

A. 패킷 압축 최적화
B. 클러스터 오토스케일링 제공
C. 사용자 위치 기반 지능형 라우팅 제공
D. 내부 서브넷 연결

정답: C

✅ NO.14 [중]

다음 중 멀티 AZ 구성을 활용하는 대표적인 AWS 서비스는?

A. Amazon Glacier
B. Amazon RDS
C. AWS CodePipeline
D. AWS Lambda@Edge

정답: B

✅ NO.15 [중]

Active-Active 멀티 리전 구성 시 고려해야 할 아키텍처적 요소는? (2개 선택)

A. Conflict-free 데이터 처리
B. 단일 지역 DB만 활용
C. GSLB 기반 트래픽 분산
D. 내부 망 전용 라우팅만 사용

정답: A, C

✅ NO.16 [상]

멀티 리전 구성에서 '데이터 정합성(Consistency)' 문제를 완화하기 위한 기술적 접근으로 적절한 것은?

A. Strong Consistency 기반 DB 사용
B. DNS TTL 최소화
C. 메트릭 수집 주기 조절
D. 메시지 큐 대기 시간 증가

정답: A

✅ NO.17 [하]

멀티 리전 구성의 장점이 아닌 것은?

A. 지리적 분산을 통한 장애 대비
B. 글로벌 사용자 응답 시간 향상
C. 비용 절감
D. 규제 지역 대응

정답: C

✅ NO.18 [상]

멀티 AZ 환경에서 세션 유지를 위한 가장 적절한 방법은?

A. 각 인스턴스 로컬 세션 유지
B. Sticky Session 사용
C. Redis 또는 외부 세션 저장소 사용
D. 스냅샷 기반 공유

정답: C

✅ NO.19 [중]

다음 중 멀티 AZ 설계가 필요한 구성 요소는?

A. 개발자 로컬 IDE
B. 로깅 에이전트
C. 인증 서비스
D. 클라이언트 UI 애플리케이션

정답: C

✅ NO.20 [중]

AWS Aurora Global Database는 어떤 멀티 리전 DR 구조에 적합한가?

A. Cold Site
B. Active-Passive (Cross-Region DR)
C. Active-Active (Multi-Region Write)
D. Warm Site

정답: B

🧠 암기용 핵심 요약

키워드설명
Multi-AZ 단일 리전 내 AZ 분산 구성 (Low latency, 고가용성)
Multi-Region 리전 간 이중화, 글로벌 트래픽 대응, DR
Active-Passive 주 리전에서 운영, 예비 리전 대기
Active-Active 양쪽 리전에서 동시에 운영, 트래픽 분산
Route53 Failover 리전 장애 시 자동 DNS 전환
GSLB Global DNS 기반 지능형 트래픽 라우팅
Aurora Global DB 멀티 리전 DB DR 구성에 적합 (읽기 복제)

'서버 시스템 > 서버 아키텍처' 카테고리의 다른 글

Disaster Recovery (DR) 설계  (0) 2025.09.02
Kubernetes 기반 서버 인프라 구성  (0) 2025.09.02
MSA(Microservice Architecture)의 Inner/Outer Architecture 구조  (0) 2025.09.02
서버 아키텍처 기본 개념 #2  (0) 2025.09.01

Kubernetes 기반 서버 인프라 구성은 최근 TA 역량 시험, Cloud-Native 전환 프로젝트, DevOps 실무에서 핵심 주제로 부상하고 있습니다.
아래에 직무역량 평가 관점으로 체계적으로 정리해드립니다.

🚀 Kubernetes 기반 서버 인프라 구성 (TA 실무/시험 대비)

✅ 1. 개요

항목설명
목적 컨테이너화된 애플리케이션의 자동 배포, 스케일링, 운영
핵심 구성 Control Plane + Worker Node
운영 모델 On-Prem K8s, Managed K8s (EKS/GKE/AKS), Hybrid

🧱 2. 기본 아키텍처 구성도

 
[User] ↓ [Ingress / API Gateway] ↓ [Service] ↓ [Pod (Container)] ↓ [Node (VM/Physical)] ↓ [Kubernetes Cluster] └── Control Plane (API Server, Scheduler, Controller, etcd)

🧠 3. 구성 요소 설명 (TA 시험 스타일 요약)

🔹 Control Plane (마스터 노드)

  • API Server: 클러스터 진입점 (kubectl 요청 처리)
  • etcd: 클러스터 상태 저장 (Key-Value Store)
  • Scheduler: Pod의 노드 배치 결정
  • Controller Manager: 상태 유지 컨트롤러들 실행

🔹 Worker Node

  • kubelet: Node 상태 감시, 컨테이너 실행 지시
  • kube-proxy: 서비스 IP 라우팅
  • Container Runtime: 컨테이너 엔진 (containerd, cri-o 등)

📦 4. 핵심 리소스 구조 (YAML 기반 실무 연계)

리소스역할
Pod 컨테이너 실행 단위 (1+개 컨테이너 포함 가능)
Deployment 애플리케이션 선언적 배포 및 업데이트 관리
Service Stable Endpoint 제공 (ClusterIP, NodePort, LoadBalancer)
Ingress L7 HTTP 라우팅, 도메인 기반 접근
ConfigMap / Secret 설정 및 민감정보 외부화
PersistentVolume / Claim 스토리지 영속성 지원

📡 5. 고가용성 구성 요소

구성요소설명
Multi-Master Control Plane 이중화
Pod ReplicaSet 다중 인스턴스 유지
Liveness/Readiness Probe 헬스체크 기반 Failover
StatefulSet 상태 저장 서비스 이중화 (DB 등)
Volume Plugin CSI 기반 외부 스토리지 연동

☸️ 6. Kubernetes + 인프라 연계 구성

항목설명
API Gateway K8s Ingress Controller 또는 외부 Gateway (e.g., Kong, Istio)
Service Mesh Istio / Linkerd 등 마이크로서비스 통신제어
CI/CD 연계 ArgoCD, Jenkins + Helm 또는 Kustomize 사용
Observability Prometheus, Grafana, Fluentd, Jaeger 등
Security NetworkPolicy, PodSecurity, OPA Gatekeeper, Secrets

🔐 7. 실무 보안 고려사항

  • RBAC 역할 기반 접근 제어
  • Pod 간 통신 제한 (Namespace, NetworkPolicy)
  • 이미지 스캐닝 (Trivy, Clair)
  • Admission Controller 활용

🎓 8. 직무역량 평가 예시 문제

문제 1 [중]

Kubernetes에서 Pod가 재시작 없이 설정만 갱신되도록 하는 리소스는?

A. Deployment
B. Service
C. ConfigMap
D. Secret

정답: C
해설: ConfigMap은 컨테이너 환경 변수나 마운트 설정으로 외부화된 설정을 주입한다.

문제 2 [상]

다음 중 Kubernetes 고가용성 구성에 가장 부적절한 것은?

A. Control Plane을 다중화한다
B. Pod에 Liveness/Readiness Probe를 설정한다
C. StatefulSet을 DB 대신 Web서비스에 적용한다
D. Volume은 CSI 기반으로 마운트한다

정답: C
해설: StatefulSet은 상태가 필요한 서비스(DB)에 적합, Stateless Web서비스는 Deployment로 구성.

문제 3 [상]

다음 YAML 중 nginx를 3개의 Pod로 배포하고 LoadBalancer를 사용하는 설정은?

(객관식 보기로 YAML 제시, Service Type: LoadBalancer 포함 여부 확인)

📌 9. 암기카드 요약 (시험/블로그용)

키워드설명
Deployment 애플리케이션 선언적 배포 리소스
Service Stable Endpoint 제공
Ingress HTTP L7 기반 라우팅
Pod 컨테이너 실행 단위
ConfigMap 설정 외부화 (non-secret)
Secret 민감정보 외부화
StatefulSet 상태 저장 워크로드 관리
Helm 패키지 기반 배포 도구
CSI Container Storage Interface
Liveness/Readiness 헬스 체크 기반 트래픽 제어

📌 Kubernetes 기반 인프라 설계 시 고려할 질문 (TA 관점)

  • Control Plane 이중화는 어떻게 구성할 것인가?
  • 노드 풀은 워크로드 유형별로 분리되어 있는가?
  • 데이터 영속성이 필요한 경우 어떤 스토리지를 어떻게 연결할 것인가?
  • 장애 발생 시 Pod 재시작이 자동으로 수행되는가? (self-healing)
  • 네트워크 접근 제어 정책이 충분히 정의되어 있는가?

☸️ Kubernetes 기반 서버 인프라 구성 실전 문제 (20문항)

✅ NO.01 [하]

Kubernetes 클러스터에서 컨테이너를 실행하는 최소 단위는?

A. Node
B. Deployment
C. Pod
D. Container

정답: C
해설: Pod는 1개 이상의 컨테이너를 포함할 수 있는 K8s의 실행 단위이다.

✅ NO.02 [중]

Kubernetes에서 서비스를 외부로 노출하기 위해 사용하는 리소스는?

A. ReplicaSet
B. Deployment
C. Service (NodePort / LoadBalancer)
D. CronJob

정답: C

✅ NO.03 [중]

Deployment 리소스를 사용하는 주요 목적은?

A. 컨테이너 이미지 압축
B. Pod의 수명 관리 및 롤링 업데이트
C. 로드 밸런싱
D. 영구 저장소 마운트

정답: B

✅ NO.04 [상]

Kubernetes 클러스터의 구성 요소 중 클러스터 상태를 Key-Value 형태로 저장하는 구성요소는?

A. kubelet
B. scheduler
C. controller-manager
D. etcd

정답: D

✅ NO.05 [하]

컨테이너가 정상인지 확인하기 위해 설정하는 Kubernetes Probe는?

A. Readiness & Liveness
B. Affinity
C. Node Taint
D. LimitRange

정답: A

✅ NO.06 [중]

노드에서 Pod를 실행하고 상태를 모니터링하는 에이전트는?

A. kube-proxy
B. kubelet
C. etcd
D. flannel

정답: B

✅ NO.07 [상]

Kubernetes에서 특정 컨테이너에 민감한 정보를 환경변수로 전달할 때 사용하는 리소스는?

A. ConfigMap
B. Secret
C. VolumeMount
D. PersistentVolume

정답: B

✅ NO.08 [중]

하나의 애플리케이션을 여러 개의 인스턴스로 실행하고자 할 때 사용하는 리소스는?

A. Service
B. Pod
C. Deployment
D. Job

정답: C

✅ NO.09 [상]

Kubernetes 클러스터의 각 노드에서 서비스 IP를 클러스터 전체로 라우팅해주는 구성요소는?

A. kube-scheduler
B. kubelet
C. kube-proxy
D. ingress controller

정답: C

✅ NO.10 [상]

Kubernetes에서 영구 데이터를 저장하기 위한 리소스 조합으로 옳은 것은?

A. Deployment + ConfigMap
B. Service + Endpoint
C. PersistentVolume + PersistentVolumeClaim
D. Pod + Secret

정답: C

✅ NO.11 [중]

Ingress Controller의 주요 역할은?

A. DNS 관리
B. L4 트래픽 제어
C. HTTP 라우팅 및 SSL 종단 처리
D. 클러스터 상태 모니터링

정답: C

✅ NO.12 [하]

Kubernetes 클러스터에서 Node를 구성하는 요소가 아닌 것은?

A. kubelet
B. Container Runtime
C. kube-scheduler
D. kube-proxy

정답: C

✅ NO.13 [중]

ConfigMap의 사용 목적은?

A. 보안 자격 증명 저장
B. 로깅 정보 전송
C. 애플리케이션 설정값 외부화
D. 데이터베이스 연결 유지

정답: C

✅ NO.14 [상]

컨테이너가 재시작되지 않으면서 일회성 작업을 수행할 때 사용하는 리소스는?

A. Deployment
B. DaemonSet
C. Job
D. CronJob

정답: C

✅ NO.15 [상]

여러 노드 간에 고가용성을 위해 컨테이너를 균등 분산하려면 어떤 설정이 필요한가?

A. Toleration
B. Anti-Affinity
C. ConfigMap
D. Secret

정답: B

✅ NO.16 [중]

Kubernetes 클러스터에서 Pod 간에 서로 통신하려면 어떤 설정이 필요 없는가?

A. 동일 네임스페이스
B. 네트워크 플러그인(CNI)
C. 서비스(ClusterIP)
D. Container Runtime

정답: D

✅ NO.17 [상]

StatefulSet을 사용하는 주된 목적은 무엇인가?

A. 트래픽 분산
B. 상태 저장 애플리케이션의 고정 ID 및 스토리지 보장
C. 스케줄링 최적화
D. 컨테이너 자원 제한

정답: B

✅ NO.18 [하]

컨테이너 런타임 중 Kubernetes에서 기본으로 권장되는 것은?

A. Docker
B. containerd
C. podman
D. runC

정답: B

✅ NO.19 [중]

Kubernetes에서 Job 리소스를 정기적으로 실행하도록 하기 위해 사용하는 것은?

A. DaemonSet
B. CronJob
C. StatefulSet
D. ReplicaSet

정답: B

✅ NO.20 [상]

Kubernetes의 Horizontal Pod Autoscaler(HPA)는 어떤 리소스를 기준으로 스케일링하는가?

A. Node 수
B. 컨테이너 수
C. CPU/메모리 사용량
D. 네임스페이스 수

정답: C

🧠 핵심 키워드 암기 요약

키워드설명
Pod K8s의 최소 실행 단위
Deployment 애플리케이션 배포/업데이트 관리
Service Pod 집합에 대한 네트워크 접근 제공
Ingress L7 HTTP 기반 라우팅
ConfigMap/Secret 설정값 외부화 / 민감정보 저장
PV/PVC 영구 스토리지 제공 (동적/정적)
StatefulSet 상태 유지 앱 배포 (DB 등)
Job/CronJob 일회성/정기성 작업 실행
kubelet/kube-proxy 노드 상태 감시 / 네트워크 라우팅
HPA 리소스 기반 수평 확장

 

☸️ Kubernetes 기반 인프라 설계 고급 체크리스트

✅ 1. Control Plane 이중화는 어떻게 구성할 것인가?

🔹 목적

Kubernetes Control Plane(API Server, Scheduler, Controller, etcd 등)의 SPoF(Single Point of Failure) 제거

🔹 구성 방식

구성설명
Managed K8s (EKS, GKE, AKS) Control Plane은 기본 이중화 + SLA 보장
Self-Managed K8s (On-prem or Kubeadm) 3개 이상의 Control Plane 노드 구성 + HAProxy or LoadBalancer 프록시 계층 사용 + etcd quorum 유지

🔹 기술 요소

  • etcd 클러스터 (3 or 5개 odd 수)
  • API Server 앞에 외부 L4 Load Balancer (HAProxy, NGINX)
  • VIP + Keepalived 또는 External DNS

🔐 TA 포인트: Control Plane 구성은 항상 etcd 쿼럼 유지와 API Server의 고가용성 확보가 필수

✅ 2. 노드 풀은 워크로드 유형별로 분리되어 있는가?

🔹 목적

리소스 충돌, 보안 격리, Taint 기반 스케줄링 제어

🔹 설계 예시

노드풀용도설정
System Node Pool kube-system, CoreDNS 등 시스템 컴포넌트 전용 taints: CriticalAddonsOnly
General App Node Pool 일반 stateless workload no taints, labels by app-type
GPU Node Pool ML/AI workload용 전용 GPU 노드 taints: gpu=true, nodeSelector
Memory/Storage Intensive Pool DB, Redis, Kafka 등 stateful workload 높은 메모리 or IO 성능 구성

📌 TA 실무 팁: taint, toleration, nodeSelector, affinity 등을 활용해 의도적인 Pod 스케줄링 분리 설계

✅ 3. 데이터 영속성이 필요한 경우 어떤 스토리지를 어떻게 연결할 것인가?

🔹 목적

Pod 재시작, 재스케줄 시에도 데이터 손실 없이 유지할 수 있도록 하기 위함

🔹 구성 방식

구성설명
Static Provisioning 기존 PV를 수동 생성 + PVC로 바인딩
Dynamic Provisioning StorageClass 기반 자동 PV 생성 (권장)
StatefulSet + PVC DB와 같은 Stateful 워크로드에 고정 스토리지 연결 (Stable identity + volumeClaimTemplates)

🔹 스토리지 유형별 예시

환경스토리지설명
AWS EBS, EFS, FSx Block/File 시스템 유형별 선택
Azure Azure Disk, Azure Files 고속 IOPS를 요구하면 Premium Disk
On-Prem Ceph RBD, NFS, iSCSI CSI 드라이버 연동 필수

✅ TA 팁: 스토리지가 multi-attach 가능 여부, ReadWriteOnce vs ReadWriteMany 접근 모드를 정확히 판단

✅ 4. 장애 발생 시 Pod 재시작이 자동으로 수행되는가? (self-healing)

🔹 기본 원리

  • Kubernetes는 Pod 상태를 감시하며 CrashLoopBackOff, NotReady 상태인 경우 자동 재시작
  • Deployment / StatefulSet 리소스는 ReplicaSet으로 구성되어 복구 보장

🔹 강화 요소

기능설명
Liveness Probe 앱의 "죽음" 여부 판단 후 재시작
Readiness Probe 앱이 “응답 가능”한지 판단, 트래픽 제외
Node Failure kube-controller-manager가 노드 상태 불량 시 다른 노드로 Pod 재배치
PodDisruptionBudget (PDB) 유지 최소 개수를 지정해 과도한 재시작 방지

🚨 TA 주의사항: DaemonSet, Job, CronJob 등은 self-healing 메커니즘이 다르므로 리소스 종류에 따라 판단

✅ 5. 네트워크 접근 제어 정책이 충분히 정의되어 있는가?

🔹 목적

기본적으로 K8s는 모든 Pod 간 통신이 허용되므로 보안 정책 수립이 필수

🔹 구성 요소

항목설명
NetworkPolicy Ingress/Egress 트래픽 허용 범위 명시
CNI Plugin Calico, Cilium, Weave 등 → NetworkPolicy 지원 여부 확인
Namespace 기반 격리 default deny 정책 + 필요한 허용만 화이트리스트 설정
RBAC + OPA(Gatekeeper) 정책 미준수 방지 및 감사 로깅 추가

🔹 설계 예시

 
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-app-access spec: podSelector: matchLabels: role: backend ingress: - from: - podSelector: matchLabels: role: frontend

🔐 TA 포인트: 클러스터 내 네임스페이스/레이블 단위로 미세한 ACL 제어를 적용할 수 있어야 함

📌 요약 인덱스 (블로그/오픈북용)

항목요약
Control Plane 이중화 3+ 노드, etcd quorum, HAProxy/VIP 구성
노드 풀 분리 워크로드 유형별 taint/label 기반 분리
스토리지 연동 StatefulSet + PVC + StorageClass
Self-Healing Liveness/Readiness Probe + ReplicaSet
NetworkPolicy Pod/Ns 단위 접근 제어, CNI 플러그인 필요

'서버 시스템 > 서버 아키텍처' 카테고리의 다른 글

Disaster Recovery (DR) 설계  (0) 2025.09.02
멀티 존(Multi-Zone) / 멀티 리전(Multi-Region) 고가용성 설계  (0) 2025.09.02
MSA(Microservice Architecture)의 Inner/Outer Architecture 구조  (0) 2025.09.02
서버 아키텍처 기본 개념 #2  (0) 2025.09.01

MSA(Microservice Architecture)의 Inner/Outer Architecture 구조는 엔터프라이즈급 MSA 설계 시 복잡한 마이크로서비스 간의 의존성과 역할을 정리하고, **서비스 경계(Boundary)**와 **기능 분리(Modularity)**를 명확하게 하기 위해 도입된 개념입니다.

직무역량 평가 및 실무 설계 기준으로 아래와 같이 정리드립니다.

🧭 MSA 아키텍처의 Inner / Outer 구조

✅ 1. 개요 요약

구분설명
Inner Architecture 비즈니스 로직에 집중된 도메인 중심 서비스 계층
Outer Architecture 외부 접점을 담당하는 게이트웨이, 인증, 메시징, 로깅 등 인프라성 기능 계층

→ MSA 환경에서 Inner는 코어 서비스, Outer는 공통 지원 인프라 계층으로 구성

🧱 2. 구조도 예시

 
┌──────────────────── Outer Architecture ─────────────────────┐ │ │ │ API Gateway | 인증/Auth | 모니터링 | 메시지 브로커 | 로깅/분석 시스템 │ └────────────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────── Inner Architecture ─────────────────────────────┐ │ │ │ 상품 서비스 결제 서비스 배송 서비스 회원 서비스 쿠폰 서비스 │ │ (Product MS) (Payment MS) (Delivery MS) (User MS) (Coupon MS) │ └──────────────────────────────────────────────────────────────────────────────┘

🔍 3. 구성 요소 상세 설명

🔹 Outer Architecture (외부 구조)

인프라, 플랫폼 기반 계층

  • API Gateway: 진입점 제어, 라우팅, 인증 위임
  • 인증/인가 시스템 (SSO, OAuth): 서비스 접근 제어
  • Service Registry / Discovery: 서비스 위치 탐색
  • 메시지 브로커 (Kafka, RabbitMQ): 비동기 메시징 지원
  • 로깅 / 모니터링: ELK, Prometheus, Grafana 등
  • CI/CD 및 배포 관리: ArgoCD, Jenkins, Helm 등

Outer는 공통 인프라로서 모든 도메인 서비스와 간접적으로 연결됨

🔹 Inner Architecture (내부 구조)

도메인 중심의 핵심 비즈니스 서비스

  • 각 서비스는 DDD(Domain-Driven Design) 기반으로 설계
  • 비즈니스 단위로 분리되어 있으며 자율성과 독립성 보장
  • DB, Cache, 내부 상태를 서비스 단위로 소유
  • 예: 주문(Order), 결제(Payment), 재고(Inventory), 회원(User) 등

Inner는 도메인 로직 처리와 데이터 소유를 책임지는 코어 레이어

🎯 4. Inner/Outer 분리의 이점

이점설명
관심사 분리 비즈니스 로직과 인프라 기능의 명확한 분리
확장성 Outer 기능을 공통화하여 각 서비스의 중복 제거
유지보수성 향상 Inner는 오직 도메인 로직에 집중 가능
보안 강화 인증/인가, 외부 통신을 Outer에서 통제

📝 5. 직무역량 평가용 예시 문제

문제 [상]

다음 중 MSA 아키텍처에서 Inner/Outer 구조를 적절히 설명한 것은?

A. Inner는 메시징 브로커를 포함하며 Outer는 회원 도메인 로직을 포함한다
B. Inner는 각 도메인 서비스의 비즈니스 로직이며 Outer는 공통 인프라 기능이다
C. Outer는 Product/Order/Delivery 서비스를 포함한다
D. Inner는 CI/CD 파이프라인, Outer는 API Gateway를 담당한다

정답: B
해설: Inner는 도메인 중심, Outer는 인증, 메시징, 모니터링 등 공통 인프라 계층이다.

🧠 암기카드 요약

키워드설명
Inner Architecture 도메인 중심 서비스 계층 (비즈니스 로직, DB 포함)
Outer Architecture API Gateway, 인증, 메시징 등 공통 인프라 계층
관심사 분리 인프라와 도메인을 명확히 구분
API Gateway Outer에 위치, 인증/라우팅 담당
서비스 디스커버리 Outer에서 Inner 연결을 동적으로 수행

📌 실전 설계 팁 (TA/아키텍처 평가 대비)

  • MSA 도입 시 반드시 Inner/Outer 구조로 나누고 설계 의도를 문서화
  • Outer 기능은 독립적으로 장애 분석 및 이중화 설계 필요 (Ex. Redis, Kafka)
  • Inner 간 동기 → 비동기 전환 시 Outer 구성 요소(Kafka 등) 적극 활용

Inner/Outer 구조는 특히 **클라우드 네이티브 환경(Kubernetes, Service Mesh, API Gateway 등)**에서 더 명확히 구분되며, 장애 대응, 확장성, 이중화 측면에서 핵심 개념입니다.

'서버 시스템 > 서버 아키텍처' 카테고리의 다른 글

Disaster Recovery (DR) 설계  (0) 2025.09.02
멀티 존(Multi-Zone) / 멀티 리전(Multi-Region) 고가용성 설계  (0) 2025.09.02
Kubernetes 기반 서버 인프라 구성  (0) 2025.09.02
서버 아키텍처 기본 개념 #2  (0) 2025.09.01

📌 1. 서버 아키텍처 기본 개념

✅ 주요 용어 및 개념

  • 서버 아키텍처: 서버 시스템의 구조적 설계로, 성능, 확장성, 가용성, 보안성 등을 고려한 구성.
  • 단일 서버 (Monolithic) ↔ 분산 서버 (Distributed) ↔ 마이크로서비스 아키텍처 (MSA)
  • 3-Tier 구조: Presentation - Logic - Data 계층 분리 구조
  • Load Balancer, WAS, DB 서버의 역할과 배치 방식
  • Session 관리 방식: Sticky session, Session clustering, Stateless

🏗️ 2. 서버 구성 방식

✅ 주요 유형

구성설명활용 사례
단일 서버 모든 서비스가 하나의 서버에서 구동됨 개발/테스트 환경
이중화 서버 이중화(H/A) 구성으로 가용성 향상 Web/WAS, DB 이중화
분산 서버 기능별로 서버 분리 및 수평 확장 대규모 서비스
클러스터 서버 간 공유 리소스를 기반으로 묶어 관리 DB, WAS, HPC 등

✅ 고려 요소

  • 부하 분산 (L4/L7 Load Balancer)
  • 고가용성 구성 (Active-Standby, Active-Active)
  • 세션 공유 (Redis, Sticky)
  • 장애 전파 최소화 (Circuit Breaker, API Gateway 등)

🔧 3. 실무 설계 요소

✅ 서버 구성도 주요 구성

  • LB ↔ Web ↔ WAS ↔ DB 구성
  • DMZ, Internal, Mgmt Zone 분리
  • MSA 도입 시 API Gateway, BFF 도입

✅ 장애 대응 고려

  • 단일 지점 장애(SPoF) 제거
  • 모니터링 연동 (Zabbix, Prometheus 등)
  • 로그 수집 및 중앙화 (ELK, Fluentd 등)

📊 4. 성능 및 용량 설계

✅ 주요 체크리스트

  • CPU, Memory, IOPS, Network Throughput 요구사항 분석
  • 동시접속자 수 기반 스레드 수 설정
  • 커넥션 풀 크기와 GC 튜닝
  • WAS 단 수평 확장 시 고려 사항

🔐 5. 보안 아키텍처 연계

  • DMZ 구성 및 방화벽 정책
  • 내부망 ↔ 외부망 트래픽 분리
  • 인증/인가 서버 분리 (OAuth, SSO)
  • API 보안 및 인증서 관리

📝 6. 직무역량평가 예시문제

문제 1 [중]

다음 중 서버 아키텍처 구성 시 고려해야 할 요소로 가장 적절하지 않은 것은?
A. 세션 공유 방식
B. 데이터베이스 인덱스 구성
C. 부하 분산 방식
D. 장애 조치(Failover) 방식

정답: B
해설: DB 인덱스 구성은 DB 설계 요소이며 서버 아키텍처 자체 설계 요소는 아님.

문제 2 [상]

다음은 웹 애플리케이션 서버(WAS) 이중화 구성도이다. 이 구성에서 장애 전파를 방지하기 위한 방안으로 적절한 것은?
A. LB에서 IP 해시 기반 라우팅을 적용한다
B. 각 WAS에 별도 세션 클러스터링을 구성한다
C. DB 연결을 단일 포인트로 집중시킨다
D. WAS 간에 Heartbeat 없이 구성한다

정답: B
해설: 세션 클러스터링을 통해 장애 시에도 세션을 다른 노드에서 처리할 수 있다.

문제 3 [중]

MSA 기반의 서버 아키텍처 설계 시 다음 중 필수적으로 포함되어야 할 요소는?
A. SFTP 서버
B. API Gateway
C. Active Directory
D. NTP 서버

정답: B
해설: MSA 구조에서는 API Gateway가 서비스 라우팅과 보안, 로깅의 중심 역할을 한다.

🧠 암기카드 요약 (오픈북/블로그용)

키워드설명
Load Balancer L4/L7 기반 트래픽 분산 장치
Stateless 세션 저장하지 않는 방식, 확장에 유리
Active-Standby 주 서버 장애 시 대기 서버로 전환
Sticky Session 특정 클라이언트를 같은 WAS로 유지
Server Cluster 고가용성, 성능 확보 위한 서버 묶음
API Gateway MSA 서비스 진입점, 인증/라우팅 담당
BFF 프론트 최적화용 백엔드 계층
서버 아키텍처 설계 요소 성능, 확장성, 가용성, 보안성

'서버 시스템 > 서버 아키텍처' 카테고리의 다른 글

Disaster Recovery (DR) 설계  (0) 2025.09.02
멀티 존(Multi-Zone) / 멀티 리전(Multi-Region) 고가용성 설계  (0) 2025.09.02
Kubernetes 기반 서버 인프라 구성  (0) 2025.09.02
MSA(Microservice Architecture)의 Inner/Outer Architecture 구조  (0) 2025.09.02

🧱 컨테이너 스토리지 연동 실무 가이드

📌 1. 개요: 왜 스토리지가 필요한가?

컨테이너는 기본적으로 휘발성(ephemeral) 환경이다.
→ 컨테이너를 재시작하면 데이터가 사라짐.

따라서 데이터 지속성(Persistence) 을 위한 스토리지 연동이 필수!

🐳 2. Docker Volume 연동 실무

✅ 개념 요약

  • Docker Volume은 호스트 OS와 컨테이너 사이의 디스크 공유 방식
  • 컨테이너가 사라져도 데이터는 볼륨에 남아있음
  • docker volume create 명령으로 생성 가능

✅ 실무 명령어 예시

 
# 1. 볼륨 생성 docker volume create myvolume # 2. 볼륨을 사용하는 컨테이너 실행 docker run -d -v myvolume:/app/data --name voltest nginx # 3. 볼륨 경로 확인 docker volume inspect myvolume

✅ 실전 활용 사례

  • MySQL, Redis, Elasticsearch 등의 데이터 디렉터리 보존
  • 로그 저장소, 애플리케이션 데이터 저장소

☸️ 3. Kubernetes PV/PVC 실무

✅ 기본 용어

용어설명
PV (PersistentVolume) 클러스터 내 실제 스토리지 리소스 (관리자가 생성)
PVC (PersistentVolumeClaim) 사용자가 요청하는 스토리지 요구 사항
StorageClass 동적 프로비저닝 시, 스토리지 종류를 정의 (ex. SSD, HDD, NFS 등)

✅ 실무 흐름

  1. StorageClass 정의 (옵션)
  2. PV 생성 (또는 동적 프로비저닝)
  3. PVC 생성
  4. Pod에서 PVC 마운트

✅ YAML 예시: PVC + Pod 연동

 
# 1. PVC 정의 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: standard
 
# 2. Pod에서 PVC 사용 apiVersion: v1 kind: Pod metadata: name: myapp spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: "/usr/share/nginx/html" name: storage volumes: - name: storage persistentVolumeClaim: claimName: my-pvc

✅ StorageClass 예시 (GCE, AWS, NFS 등)

 
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast provisioner: kubernetes.io/aws-ebs parameters: type: gp2

AWS EBS, Azure Disk, GCP PersistentDisk, NFS 등과 연동 가능.

🚨 실무 주의 포인트

  • accessModes 설정 오류로 마운트 충돌 발생 가능
  • 동적 스토리지 사용 시 StorageClass 지정 필수
  • ReadWriteMany는 NFS, CephFS, GlusterFS 등에서만 지원
  • PVC가 Pending 상태면 PV와 매칭이 안된 상태 → 이벤트 로그 확인 필요 (kubectl describe pvc)

🧪 실무 시나리오 예제

[시나리오 1]

Pod를 재시작했더니 DB 데이터가 초기화됨

원인: EmptyDir 볼륨 사용 중 → 휘발성
해결: PVC를 생성하고 Pod에 마운트해야 함

[시나리오 2]

PVC가 계속 Pending 상태

원인:

  • PV와 accessModes 불일치
  • storageClassName 불일치
  • 동적 프로비저닝용 CSI 미설정

조치:

  • kubectl describe pvc로 이벤트 확인
  • StorageClass 존재 여부 및 PV 상태 확인

 

 

📘 컨테이너 스토리지 연동 실무 문제집 (10문항)

✅ 난이도 분류

  • [하] 기초 개념
  • [중] 실무 구성
  • [상] 트러블슈팅/설계 판단

문제 1 [하]

Docker Volume의 주요 특징으로 가장 적절한 것은?
A) 컨테이너가 재시작되면 데이터가 사라진다
B) 호스트와 격리된 메모리 볼륨이다
C) 데이터의 영속성을 제공한다
D) 컨테이너 이미지에 포함된 디렉터리이다

정답: C
해설: Docker Volume은 휘발성인 컨테이너 환경에서 데이터를 영구적으로 보존하는 데 사용된다.

문제 2 [중]

다음 중 Kubernetes PVC(PersistentVolumeClaim)에 대한 설명으로 옳은 것은?
A) PVC는 항상 수동으로 PV를 연결해야 한다
B) PVC는 Pod의 Restart 시 삭제된다
C) PVC는 사용자 입장에서 스토리지를 요청하는 방식이다
D) PVC는 로그 저장용으로만 사용 가능하다

정답: C
해설: PVC는 사용자가 스토리지를 요구할 때 선언적으로 요청하는 객체로, PV와 바인딩된다.

문제 3 [중] (YAML 기반)

다음 YAML 중 PVC를 사용하는 Pod 구성으로 올바른 것은?

A)

 
volumeMounts: - mountPath: "/data" name: myvol volumes: - name: myvol emptyDir: {}

B)

 
volumeMounts: - mountPath: "/data" name: myvol volumes: - name: myvol persistentVolumeClaim: claimName: my-pvc

C)

 
volumeMounts: - mountPath: "/data" claimName: my-pvc volumes: - name: myvol hostPath: path: /mnt/data

D)

 
volumeMounts: - mountPath: "/data" pvc: my-pvc volumes: - name: myvol configMap: name: my-config

정답: B
해설: Pod에서 PVC를 사용할 때는 volumes.persistentVolumeClaim.claimName 형식으로 참조해야 한다.

문제 4 [중]

Kubernetes에서 StorageClass를 지정하지 않은 PVC는 어떻게 처리되는가?
A) 자동으로 삭제된다
B) 아무 스토리지도 매칭되지 않는다
C) 기본 StorageClass가 있다면 그것을 사용한다
D) 클러스터 전체가 에러 상태가 된다

정답: C
해설: default StorageClass가 존재할 경우 자동으로 바인딩된다.

문제 5 [상]

PVC가 Pending 상태로 계속 머무는 가장 일반적인 원인은?
A) Pod가 실행되지 않아서
B) 컨테이너 이미지가 없어서
C) PVC가 잘못된 형식으로 생성되어서
D) PV가 조건에 맞지 않아 바인딩되지 못해서

정답: D
해설: PVC의 용량, accessMode, StorageClass가 PV와 일치하지 않으면 바인딩이 되지 않고 Pending 상태가 지속된다.

문제 6 [상]

다음 중 ReadWriteMany(다중 Pod 쓰기 가능) accessMode를 지원하지 않는 볼륨 유형은?
A) NFS
B) CephFS
C) HostPath
D) Azure Disk

정답: D
해설: Azure Disk는 ReadWriteOnce만 지원한다. RWX를 원하면 Azure Files를 사용해야 한다.

문제 7 [중]

아래 YAML은 어떤 용도로 사용하는가?

 
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: redis-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi

A) Pod의 리소스 제한
B) ConfigMap 생성
C) 로그 수집 경로 설정
D) 스토리지 요청 선언

정답: D
해설: PVC를 정의한 예시로, 1Gi의 스토리지를 요청하고 있다.

문제 8 [하]

Kubernetes에서 Pod가 사용하는 디렉토리를 지속적으로 유지하려면 어떤 리소스를 반드시 생성해야 하는가?
A) ConfigMap
B) Secret
C) PersistentVolumeClaim
D) HorizontalPodAutoscaler

정답: C
해설: Pod가 재시작되어도 데이터를 유지하려면 PVC를 통해 외부 스토리지를 마운트해야 한다.

문제 9 [상]

스토리지 연동 시 다음과 같은 오류가 발생한다:

 
Warning FailedMount Unable to attach or mount volumes: unmounted volumes=[data], unattached volumes=[data]: timed out waiting for the condition

이 문제를 해결하기 위한 첫 번째 조치로 적절한 것은?
A) Pod 삭제
B) PVC 삭제
C) kubectl describe pvc 명령어로 이벤트 로그 확인
D) kubelet 재시작

정답: C
해설: PVC와 PV 간 매칭 실패 혹은 CSI 드라이버 문제일 수 있으므로, PVC 상태를 상세히 확인해야 한다.

문제 10 [중]

Docker Volume을 생성하고 컨테이너에서 사용할 때 올바른 방식은?

 
1) docker volume create myvol 2) docker run -d -v _____________ nginx

빈칸에 들어갈 알맞은 내용은?
A) myvol:/etc/nginx
B) ./data:/app
C) nginx:/data
D) data:myvol

정답: A
해설: 볼륨명:컨테이너 경로 형식으로 -v 옵션을 사용해야 하며, myvol:/etc/nginx가 올바르다.

📘 스토리지 장애 분석 단답형 문제집 (10문항)

문제 1.

Kubernetes Pod가 PVC를 마운트하지 못하고 FailedMount 오류가 발생했다. 가장 먼저 확인해야 할 명령어는?

정답: kubectl describe pvc [PVC명]

문제 2.

iSCSI 기반 스토리지가 정상인데도 Linux 클라이언트에서 마운트 실패가 발생한다. 연결 상태를 확인하는 명령어는?

정답: iscsiadm -m session

문제 3.

Docker 컨테이너에서 볼륨을 마운트했으나 디렉토리가 비어 있다. 가장 먼저 점검해야 할 것은?

정답: 컨테이너 내 경로 지정이 올바른지 확인

문제 4.

RAID 5 구성 중 하나의 디스크에 장애가 발생했다. 시스템은 동작 중이다. 이 상태에서 우선적으로 해야 할 작업은?

정답: 장애 디스크 교체 및 리빌드 시작

문제 5.

NFS 스토리지 연결이 불안정하고 간헐적으로 읽기 지연이 발생한다. 가장 먼저 점검해야 할 것은?

정답: 네트워크 상태 및 MTU 설정 확인

문제 6.

SAN 환경에서 LUN을 바인딩했는데 서버에서 디바이스가 인식되지 않는다. 무엇을 점검해야 하는가?

정답: HBA WWN 등록 여부 및 zoning 상태

문제 7.

스토리지 장애 이후, 일부 Kubernetes Pod가 재시작되지 않고 Terminating 상태로 남아있다. 우선 확인해야 할 리소스는?

정답: VolumeAttachment 상태

문제 8.

스토리지 시스템에서 High Latency 경고가 발생했다. 스토리지 입출력량이 과도한 상황이다. 어떤 리소스를 우선 확인해야 하는가?

정답: 특정 LUN 또는 볼륨의 IOPS

문제 9.

스토리지 연결이 끊어진 후 multipath가 failover 되지 않았다. 가장 가능성 높은 원인은?

정답: multipath 설정 오류 또는 path group 미구성

문제 10.

스토리지 장애가 발생했을 때 재시작 없이 데이터를 최대한 빨리 이전해야 한다. 가장 적절한 기술은?

정답: 스냅샷 복제 또는 LUN 클론

아래는 스토리지 마운트 충돌, 용량 부족, 권한 오류 등 실무에서 자주 발생하는 장애 시나리오 기반 단답형 문제 10제입니다. Kubernetes와 Docker, iSCSI, NFS, PV/PVC 등 다양한 컨테이너 및 서버 환경을 반영했습니다.

📌 장애 분석 시나리오 단답형 문제 (마운트 충돌·용량 부족·권한 오류 포함)

문제 1.

Kubernetes에서 PVC를 마운트하려 했지만, 이미 같은 경로를 다른 컨테이너가 사용 중이라 오류가 발생했다. 이때 발생하는 일반적인 오류 메시지는?

정답: MountVolume.SetUp failed for volume ... already mounted

문제 2.

Linux 서버에서 NFS 볼륨을 마운트했으나, 특정 사용자만 읽기 전용으로 인식된다. 가장 먼저 확인할 파일은?

정답: /etc/exports

문제 3.

Pod가 "VolumeMount" 실패로 CrashLoopBackOff 상태이다. kubectl describe pod 명령어에서 확인할 항목은?

정답: Events 섹션의 마운트 관련 오류 메시지

문제 4.

Docker 컨테이너 실행 시 permission denied 오류가 발생하며 호스트 디렉토리 마운트에 실패한다. 가장 가능성 높은 원인은?

정답: 호스트 디렉토리의 권한 문제 (chmod/chown 필요)

문제 5.

PV가 Bound 상태이나, Pod가 PVC를 제대로 마운트하지 못한다. 가장 먼저 확인해야 할 구성 요소는?

정답: volumeMounts 경로가 Pod 내에서 유효한지 확인

문제 6.

Kubernetes 클러스터에서 특정 노드에만 볼륨이 마운트되지 않는다. 가장 먼저 확인해야 할 것은?

정답: CSI 플러그인 또는 kubelet 로그

문제 7.

스토리지 마운트 이후 몇 시간 뒤 I/O 오류와 함께 Pod가 재시작되었다. 어떤 원인을 의심해야 하는가?

정답: 용량 부족 또는 underlying storage 장애

문제 8.

iSCSI 기반 PV가 간헐적으로 NodePublishVolume 오류를 보인다. 확인할 항목은?

정답: iSCSI target 접속 상태 (iscsiadm -m session)

문제 9.

스토리지 마운트는 성공했으나, df -h 출력 시 볼륨이 100% 사용 중으로 나타난다. 다음으로 확인할 명령어는?

정답: du -sh /* 또는 find / -type f -size +1G

문제 10.

ReadOnlyFilesystem 오류로 인해 Pod에서 파일 생성이 실패한다. 가능한 원인 중 하나는?

정답: 스토리지가 ReadOnly로 remount된 상태 (I/O 오류, 파일시스템 오류 등)

Cloud 인프라 설계 및 가용성 아키텍처 학습은 단순히 서비스 배포가 아닌 **"신뢰성 있는 클라우드 기반 시스템 구축"**을 목표로 해야 하며, 아래와 같이 체계적으로 진행하는 것이 좋습니다.

✅ 1단계: 기본 개념 정리

☁️ 클라우드 인프라 기초

  • IaaS / PaaS / SaaS 구분
  • Public / Private / Hybrid / Multi-Cloud 개념
  • 대표 서비스: AWS / Azure / GCP 구성요소 (EC2, VPC, S3 등)

📌 추천 학습 포인트

  • Cloud VM, Storage, Load Balancer, NAT, DNS, VPC 등 개념과 역할
  • 클라우드의 리소스 구성 단위 (Region, Zone, Resource Group) 이해

✅ 2단계: 아키텍처 설계 원칙 학습

🏗️ 클라우드 인프라 설계 5대 원칙 (예: AWS Well-Architected Framework)

  • 가용성 (Availability) – 다중 AZ 구성, ELB, Auto Scaling
  • 신뢰성 (Reliability) – 실패 복구, 백업, 장애 격리
  • 보안성 (Security) – IAM, 보안그룹, 네트워크 ACL
  • 비용 최적화 (Cost Optimization) – 리소스 효율, 예약 인스턴스
  • 운영 효율성 (Operational Excellence) – 모니터링, 자동화, IaC

📌 학습 방향

  • 클라우드 전용 아키텍처 설계 패턴
  • 모놀리식 → 마이크로서비스 구조로 전환 시 고려사항

✅ 3단계: 사용자 요구 기반 가용성 설계

🧩 핵심 키워드

  • SLA / SLO / SLI
  • RTO / RPO 기반 이중화 구조
  • Single Point of Failure 제거
  • Failover, Load Balancing, DR 설계

예시 시나리오

  • 사용자 요구: "99.99% 가용성, 장애시 5분 내 복구, 1시간 이내 데이터 복구"
  • → 설계 대응:
    • Multi-AZ 배포
    • RDS 복제 및 백업 설정
    • Auto Healing + ELB + ASG

✅ 4단계: 실무 설계 사례 학습

  • Azure 기반 설계 시 Resource Group, Availability Zone, Recovery Vault 설계
  • AWS 기반 설계 시 VPC subnet 구성, Multi-AZ, Route53 설정
  • WAS + DB 이중화 구성 (e.g., Web → App → DB 구조, DR 포함)
  • 장애 복구 시나리오: DB Failover, Web 서비스 롤백, 스토리지 장애 대응

✅ 5단계: 실전 문제 풀이 및 시나리오

  • 장애 대응 기반 문제집 (가용성, 이중화, DR 시나리오 중심)
  • 실무 기반 설계 문서 분석 및 설계도 도식화 훈련
  • 가용성 보장을 위한 테스트 계획 수립 (Chaos Engineering 포함)

📚 참고자료

  • AWS Well-Architected Framework / Azure Architecture Center
  • [KT, LGU+, SKT 사례 기반 클라우드 구축 사례 분석]
  • Kubernetes 기반 HA 구성 사례
  • Terraform / ARM Template 기반 인프라 코드 실습

필요 시 다음 요청 예시

  • “클라우드 가용성 설계 문제집 만들어줘”
  • “RTO/RPO 기반 DR 구성 시나리오 문제 10개”
  • “Azure 기반 다중존 설계 사례 요약해줘”
  • “오픈북용 인프라 키워드 인덱스 정리해줘”

 

☁️ 클라우드 인프라 구성요소 + 가용성 아키텍처 개요

✅ 1. 클라우드 인프라 구성요소

🏢 1.1 리전(Region) / 가용 영역(Availability Zone, AZ)

구성요소설명
Region 전 세계 물리적 데이터센터 집합 (예: korea-central)
Availability Zone (AZ) 리전 내 독립된 전력/네트워크를 가진 데이터센터 (장애 격리 단위)
Multi-AZ 여러 AZ에 자원을 배포하여 장애 발생 시 서비스 지속성 확보

📌 TA 관점: 고가용성 설계를 위해 리전 내 최소 2개 이상의 AZ를 사용해야 함

🌐 1.2 네트워크 구성 요소

요소설명
VPC (Virtual Private Cloud) 사용자 전용 네트워크, 서브넷으로 분리
Subnet (Public/Private) 서비스 목적에 따른 분리: Public은 LB, Private은 DB
NAT Gateway Private Subnet → 외부 인터넷 통신 가능
Internet Gateway (IGW) Public Subnet 인터넷 연결을 위해 사용
Route Table 패킷 전달 경로 정의
Security Group / NSG 인바운드/아웃바운드 트래픽 필터링
Load Balancer (LB) 트래픽 분산, 장애 시 자동 분산 지원 (ALB, NLB 등)

💻 1.3 컴퓨팅/스토리지/데이터베이스

구성요소설명
VM / Instance EC2, Azure VM 등 가상서버
Auto Scaling Group (ASG) 트래픽 증가 시 자동 확장, 실패 시 자동 복구
Object Storage (Blob/S3) 비정형 데이터 저장, 무제한 확장 가능
Block Storage (EBS/Disk) VM에 연결되는 디스크 스토리지
DBaaS (RDS/Azure SQL) 관리형 DB, 자동 백업/이중화 지원
Backup/Recovery Vault 정책 기반 백업 스케줄링 및 복구 기능

🛠 1.4 기타 핵심 인프라 요소

요소설명
IAM 사용자별 권한 제어 (RBAC/ABAC)
Monitoring CloudWatch, Azure Monitor
Bastion Host / Jump Box 보안용 접근 통제 VM
Infrastructure as Code Terraform, ARM Template, Bicep

✅ 2. 가용성(Availability) 아키텍처 개요

📌 2.1 고가용성(HA) 정의

시스템 또는 서비스가 지속적으로 사용 가능하도록 설계하는 것

  • SLA (Service Level Agreement): 제공자 ↔ 사용자 간 보장되는 가용성 수치 (예: 99.9%)
  • SLO / SLI: 내부 운영 기준

🧩 2.2 핵심 설계 요소

요소설명
이중화(Redundancy) 컴퓨팅, DB, 네트워크 구성요소에 대한 이중 구성
Failover 구성 Active-Passive, Active-Active 구성
Auto Healing 장애 발생 시 자동 복구 메커니즘
DR(재해복구) Region/AZ 전체 장애에 대비한 복구 계획 수립
RTO/RPO 설계 복구시간 목표 / 복구시점 목표에 따른 백업정책

🔁 2.3 아키텍처 예시

✅ 웹서비스 고가용성 설계 예

 
[사용자] ↓ [Global DNS (Route53/Azure DNS)] ↓ [Multi-AZ Load Balancer] ↓ [Auto Scaling App 서버 (VM)] ↓ [다중 AZ RDS with Failover] ↓ [Object Storage + Backup Vault]

장애 시 동작:

  • App 서버 인스턴스 장애: Auto Healing 재생성
  • AZ 장애: LB가 다른 AZ로 트래픽 분산
  • DB 장애: RDS Failover to Standby

✅ 3. 사용자 요구 기반 설계 대응 예시

사용자 요구 조건설계 포인트
99.99% 가용성 보장 Multi-AZ + LB + Auto Scaling + DB 이중화
장애 발생 시 10분 내 복구 Auto Healing + Health Probe + 빠른 RTO
1시간 이내 데이터 복구 정기 Snapshot, 백업 정책(RPO ≤ 1hr)
보안 요구 강화 Private Subnet, Bastion, SG/NSG 강화, IAM Least Privilege
비용 고려 Spot Instance, Reserved Instance, 규모에 맞는 ASG 정책

✅ 4. TA 관점 실전 팁

항목체크포인트
SPoF 제거 단일 장애점 분석 및 제거
계층별 이중화 LB/App/DB/Storage/Network 전 계층 고려
Multi-AZ/Multi-Region 재해복구 및 SLA 대응
IaC 도입 아키텍처 재현성 확보
모니터링 + 자동화 장애 예측 및 대응 효율성

필요하시면 다음 자료도 이어서 제공할 수 있습니다:

  • 문제집: 실무 시나리오 기반 고가용성 설계 문제 20~30제
  • 암기카드: 인프라 요소별 키워드 요약
  • 블로그용 키워드 인덱스 요약본
  • Azure 기반 가용성 설계 시나리오
  • RTO/RPO 기반 백업 설계 문제집

📘 실무 시나리오 기반 고가용성 설계 문제집 (30문항)

✅ NO.01

[난이도: 하]
한 웹서비스가 단일 AZ에만 모든 자원을 배치한 경우, 장애 발생 시 가장 취약한 부분은?
A. 네트워크 대역폭
B. Auto Scaling 정책
C. AZ 자체 장애
D. DNS TTL 설정

정답: C
해설: 단일 AZ 구성은 Availability Zone 전체 장애에 매우 취약함.

✅ NO.02

[난이도: 중]
서비스 중인 DB 인스턴스에 대해 RTO 5분, RPO 1시간 요구사항이 주어졌다. 적절한 구성은?
A. DB Snapshot 하루 1회
B. Multi-AZ 구성 + 자동 백업
C. DB Read Replica
D. Single AZ 구성 + RAID

정답: B
해설: Multi-AZ 구성은 장애 시 자동 Failover, 백업은 RPO 보장 목적.

✅ NO.03

[난이도: 중]
고객사 요구로 99.95% SLA를 충족해야 한다. 가장 적절한 구성은?
A. 단일 리전에 2개 인스턴스 구성
B. 서로 다른 AZ에 인스턴스를 분산
C. 단일 VM 고사양 구성
D. CDN 구성

정답: B
해설: SLA 99.95%를 만족하려면 AZ 분산이 필수.

✅ NO.04

[난이도: 상]
다음 중 Auto Scaling Group 설정 오류로 인해 가용성이 낮아질 수 있는 경우는?
A. Health Check Type을 ELB가 아닌 EC2로 설정
B. Launch Template에서 인스턴스 유형 지정
C. Desired Count보다 Min Count가 낮음
D. CloudWatch Metric 설정

정답: A
해설: Health check가 EC2이면 애플리케이션 장애를 감지하지 못함.

✅ NO.05

[난이도: 중]
DB 복구시간 목표(RTO)를 3분으로 설정했을 때 적절한 전략은?
A. 스냅샷 기반 수동 복구
B. 스토리지 계층의 복제
C. Multi-AZ DB 구성
D. DB Dump 수동 적용

정답: C
해설: Multi-AZ는 장애 발생 시 수분 내 자동 Failover가 가능.

✅ NO.06

[난이도: 하]
다중 지역(Multi-Region) 구성을 채택하는 주된 이유는?
A. 비용 절감
B. 장애 시 재해복구
C. 네트워크 성능 향상
D. 데이터 암호화

정답: B
해설: Multi-Region은 대규모 재해 상황 대비용.

✅ NO.07

[난이도: 중]
Azure에서 App Service의 고가용성을 위한 기본 구성 요소는?
A. 수동 백업
B. Traffic Manager와 다중 지역 배포
C. Azure Key Vault
D. Single Region 구성

정답: B
해설: Azure Traffic Manager를 통해 다중 지역 배포로 가용성 확보.

✅ NO.08

[난이도: 상]
웹서버가 5초 이내 응답하지 않으면 LB가 요청을 다른 인스턴스로 분산해야 한다. 설정해야 할 항목은?
A. Sticky Session
B. Listener Timeout
C. Health Check Timeout
D. HTTP Redirect

정답: C
해설: Health Check 응답이 없는 경우 Failover 대상에서 제외됨.

✅ NO.09

[난이도: 중]
RPO를 0분으로 설정하려는 서비스의 적절한 아키텍처는?
A. 정기적 백업 스케줄링
B. 동기식 복제 기반 이중화
C. 비동기식 복제
D. 백업 → S3 업로드

정답: B
해설: RPO = 0은 실시간 동기 복제를 의미함.

✅ NO.10

[난이도: 상]
이중화된 DB 환경에서 비동기식 복제를 사용할 경우 주의해야 할 점은?
A. 쓰기 지연
B. 데이터 손실 가능성
C. 비용 증가
D. 백업 불가

정답: B
해설: 비동기 복제는 장애 발생 시 마지막 복제본과 차이로 인한 데이터 손실 가능성 존재.

✅ NO.11

[난이도: 중]
Auto Scaling이 작동하지 않는 원인이 Health Check 미설정으로 추정된다. 우선 확인해야 할 것은?
A. CPU 사용률
B. LB와 연결 여부
C. Security Group 포트
D. 리전 상태

정답: B
해설: LB 연동 없이 ASG는 인스턴스 상태를 파악할 수 없음.

✅ NO.12

[난이도: 중]
서비스 운영 중 일부 사용자 요청이 지연되고 있다. AZ 단위 장애는 아니며, 한 인스턴스에만 영향이 있다면 적절한 조치는?
A. 전체 서비스 재시작
B. 해당 인스턴스를 Auto Healing으로 교체
C. 리전 재배포
D. DB Failover 수행

정답: B
해설: Auto Healing이 인스턴스 단위 장애에 대응 가능.

✅ NO.13

[난이도: 중]
아래 중 SPoF(Single Point of Failure)를 야기할 수 있는 구성은?
A. 이중화 LB 구성
B. DB Master-Slave 복제
C. 단일 Bastion Host
D. DNS 이중화

정답: C
해설: Bastion Host가 단일일 경우 해당 장비 장애 시 전체 접속 차단됨.

✅ NO.14

[난이도: 하]
가용성(Availability)을 높이기 위한 가장 기본적인 접근은?
A. VM 스펙 업그레이드
B. 멀티 리전 구성
C. 이중화 구성
D. 암호화 정책 강화

정답: C
해설: 이중화는 가용성 확보의 핵심 기법.

✅ NO.15

[난이도: 상]
로드밸런서 구성 시 사용자가 항상 같은 인스턴스에 연결되도록 설정하려면?
A. Health Check
B. Connection Draining
C. Sticky Session
D. SSL Offloading

정답: C
해설: Sticky Session은 사용자 요청을 동일 인스턴스로 라우팅함.

✅ NO.16

[난이도: 중]
DNS 구성 시 트래픽 장애를 최소화하고 빠른 전환을 유도하기 위한 설정은?
A. TTL 값을 높게 설정
B. DNS 레코드를 CNAME으로 구성
C. TTL 값을 짧게 설정
D. DNSSEC 활성화

정답: C
해설: TTL(Time to Live)이 짧아야 장애 시 빠른 IP 갱신 및 전환이 가능.

✅ NO.17

[난이도: 상]
Web + App + DB 3계층 구조에서 App 서버를 무중단으로 교체하려면?
A. 서버를 순차적으로 전원 끄고 교체
B. LB에서 해당 인스턴스를 일시 제외하고 교체
C. DB를 먼저 정지하고 교체
D. App 서버에 SSH 연결하여 직접 교체

정답: B
해설: LB에서 트래픽 분리를 먼저 수행한 뒤 교체해야 무중단 유지 가능.

✅ NO.18

[난이도: 중]
Azure에서 가용성을 위한 배포 전략으로 옳은 것은?
A. Availability Set은 리전 간 배포를 지원한다.
B. Availability Zone은 물리적 장애에 강하다.
C. Resource Group 단위로 고가용성 설정한다.
D. Bastion Host를 각 VM에 설치한다.

정답: B
해설: AZ는 각기 다른 전력, 네트워크를 가진 장애격리 영역이다.

✅ NO.19

[난이도: 중]
다음 중 가용성 높은 아키텍처 설계의 기준 요소가 아닌 것은?
A. 최소 컴퓨팅 자원
B. 단일 장애점 제거
C. RTO/RPO 설정
D. 수평 확장 지원

정답: A
해설: 자원 최소화는 비용 최적화 관점이지 고가용성과 직접 연관은 없다.

✅ NO.20

[난이도: 하]
클라우드 LB에서 기본적으로 수행하는 동작은?
A. 저장소 압축
B. 패킷 캡처
C. 트래픽 분산
D. 사용자 인증

정답: C
해설: LB의 핵심 기능은 트래픽 부하 분산.

✅ NO.21

[난이도: 상]
Auto Scaling 시 VM의 기동 시간이 5분 이상 소요된다. 갑작스런 트래픽 급증 시 대응 방안으로 적절한 것은?
A. On-demand VM 예약
B. Warm Pool 설정
C. Spot Instance 대체
D. VM 스펙 축소

정답: B
해설: Warm Pool은 미리 기동된 인스턴스를 대기 상태로 두어 빠른 확장을 지원함.

✅ NO.22

[난이도: 중]
DB 이중화 구성 시 Failover 후 클라이언트 연결이 안 되는 경우, 가장 먼저 확인할 것은?
A. DB Index
B. 보안 그룹
C. Endpoint 라우팅
D. VM 로그

정답: C
해설: Failover 후 새로운 Primary로의 라우팅이 정상적으로 설정되었는지 확인 필요.

✅ NO.23

[난이도: 중]
웹서비스의 로그 수집이 실패했는데, 로그 수집 에이전트가 단일 서버에만 존재할 경우 가장 큰 문제점은?
A. 로그 형식 불일치
B. 암호화 설정 누락
C. 단일 장애점(SPoF)
D. 로그 레벨 오류

정답: C
해설: 로그 수집 서버의 이중화가 없으면 장애 발생 시 전체 로그 수집 실패.

✅ NO.24

[난이도: 하]
가용성을 높이기 위한 서브넷 구성 전략으로 적절한 것은?
A. 모든 자원을 Public Subnet에 배치
B. 모든 AZ에 동일한 서브넷 구성
C. DB는 Public Subnet에 배치
D. 모든 트래픽을 하나의 NAT Gateway로 전환

정답: B
해설: AZ마다 동일한 구성의 Subnet을 구성하여 장애 발생 시 빠른 전환이 가능.

✅ NO.25

[난이도: 중]
고가용성을 위해 동일 리전 내 서로 다른 AZ에 DB를 배포할 경우 중요한 조건은?
A. 서브넷 IP가 동일해야 함
B. DB 동기화 방식 결정
C. LB가 필요 없음
D. 암호화 설정은 무조건 필요 없음

정답: B
해설: 동기 vs 비동기 복제 여부는 데이터 손실 가능성과 가용성에 영향을 줌.

✅ NO.26

[난이도: 상]
다음 중 고가용성과 재해복구(HA/DR) 모두를 고려한 아키텍처 요소로 옳은 것은?
A. Auto Scaling Group만 구성
B. Multi-AZ 구성
C. Multi-Region + Global DNS 구성
D. 백업을 Local에만 저장

정답: C
해설: DR을 고려하려면 Region 자체 이중화 + DNS 기반 라우팅이 필요함.

✅ NO.27

[난이도: 중]
서비스 구성도에 LB → App → DB 구조에서 LB와 App 사이의 고가용성을 고려할 때 확인할 사항은?
A. DB 스키마
B. TLS 버전
C. Health Check 설정
D. DNS TTL

정답: C
해설: LB가 App 상태를 체크하여 비정상 인스턴스를 자동 제외해야 함.

✅ NO.28

[난이도: 상]
Azure에서 Availability Set과 Availability Zone의 차이는?
A. 둘 다 리전 간 구성
B. 둘 다 동일 장애 도메인
C. Availability Zone은 데이터센터 간 이격
D. Availability Set은 비용이 높음

정답: C
해설: AZ는 물리적으로 다른 전력/네트워크 구조의 DC에 위치함.

✅ NO.29

[난이도: 하]
고가용성 확보를 위한 기본 원칙으로 적절한 것은?
A. 모든 자원은 최소화
B. 암호화를 최대화
C. 수평적 확장성 고려
D. DB 단일 구성

정답: C
해설: 수평적 확장은 서비스 중단 없이 확장이 가능함.

✅ NO.30

[난이도: 중]
가용성을 위한 인프라 설계 시, 정기점검 중에도 서비스가 중단되지 않도록 구성하는 전략은?
A. 점검 시 전체 리소스 종료
B. Blue-Green Deployment
C. Sticky Session 제거
D. DB 단일화

정답: B
해설: Blue-Green 방식은 운영 중인 시스템과 별도로 새 환경을 구성하여 무중단 배포 지원.

 

📒 고가용성 설계 암기카드 요약 (Flashcards)

☁️ 클라우드 인프라 & 가용성 구성 요소

  • Availability Zone (AZ) – 리전 내 독립된 장애격리 단위
  • Multi-AZ 구성 – 가용성 확보 위한 기본 설계 (AZ 간 분산)
  • Multi-Region 구성 – 재해복구 목적의 지역 이중화
  • SPoF (Single Point of Failure) – 단일 장애 지점, 반드시 제거 대상
  • RTO (복구 시간 목표) – 장애 발생 후 복구까지 소요 허용 시간
  • RPO (복구 시점 목표) – 장애 발생 시 복구 가능한 데이터 시점 기준

🛠 고가용성 설계 핵심 기법

  • 이중화 구성 – LB, VM, DB, NAT 등 모든 계층에 이중화 적용
  • Auto Scaling – 수요에 따라 인스턴스 자동 확장/복구
  • Health Check – 비정상 인스턴스 제거를 위한 상태 점검
  • Sticky Session – 사용자를 동일 인스턴스로 지속 연결
  • Blue-Green Deployment – 무중단 배포를 위한 이중 환경 구성
  • Warm Pool – 미리 기동된 인스턴스를 통해 빠른 확장 대응

🔐 네트워크/보안 및 DNS

  • TTL 설정 – DNS 전환 속도에 직접 영향 (짧게 설정 시 빠른 전환 가능)
  • Security Group(NSG) – 네트워크 접근 제어, LB/VM 계층마다 적용
  • Bastion Host 이중화 – 원격 접속 지점의 단일 장애 제거

💽 DB 및 스토리지

  • Multi-AZ DB (동기식 복제) – 장애 시 자동 Failover, RPO ≒ 0
  • Read Replica (비동기식) – 읽기 부하 분산, 일부 데이터 유실 가능
  • Endpoint 기반 Failover – DB 전환 시 클라이언트 라우팅 필수
  • Log Collector 이중화 – 운영/보안 로그 수집 장애 예방

📊 실전 설계 고려 요소

  • 수평 확장성 (Scalability) – 서비스 중단 없이 확장 가능
  • 정기 점검 시 무중단 전략 – Blue-Green 또는 Rolling 배포 방식
  • Health Check → Auto Healing → Replace – 단일 VM 장애 대응 흐름
  • Global DNS + Multi-Region – 지역 장애 시에도 글로벌 트래픽 유지
  • Failover 시 장애 인지 – Health Check or Monitor 기반 알림/대응

🧠 상황별 판단 기준 요약

상황적용 설계 포인트
RPO = 0 요구 동기식 복제 필수
빠른 복구 (RTO ≤ 5분) Auto Healing + Multi-AZ + Warm Pool
인스턴스 응답 없음 Health Check 미반응 → 제거 → 대체
클라이언트 연결 불가 Failover 후 Endpoint 라우팅 확인 필요
점검 중 무중단 필요 Blue-Green Deployment 구성

 

                 [ 사용자 ]
                     │
           ┌──────────────┐
           │ Azure Front Door│
           └────┬──────┬──┘
                ↓      ↓
     ┌────────────┐ ┌────────────┐
     │   Region1  │ │   Region2  │ ← DR 구성
     └────┬──┬────┘ └────┬──┬────┘
                            ↓  ↓            ↓  ↓
                [Zone1][Zone2]   [Zone1][Zone2]
                            ↓      ↓           ↓     ↓
            [App1][App2]      [App3][App4]
                          ↓      ↓           ↓     ↓
             [DB P][DB S]     [DB P][DB S]

 


좋습니다! 아래는 Azure 기반 다중존(Availability Zone, AZ) 설계 사례 요약입니다.
TA(Technical Architect) 관점에서 실무 적용 가능한 구조를 구성도 + 설계 포인트 + 주요 서비스로 정리했으며, 오픈북/블로그용 요약으로도 활용할 수 있게 구성했습니다.

☁️ Azure 기반 다중존 설계 사례 요약

✅ 1. 설계 목적

"AZ 단위 장애에도 중단 없이 서비스를 제공하는 고가용성 인프라 구성"

  • SLA 보장 (예: 99.99%)
  • 자동 복구, 자동 확장, 트래픽 분산
  • RTO/RPO 요건 충족

✅ 2. Azure 다중존 기본 구성도

 

✅ 3. 설계 주요 포인트

🏗️ 1) 네트워크 계층

항목설명
Azure Front Door 글로벌 로드 밸런싱 + HTTPS 오프로드 + Health Probe
Azure Load Balancer (Zonal) 각 AZ 내 VM 간 로드 밸런싱
VNet/Subnet 구성 각 AZ마다 분리된 서브넷 구성 (Zone-aware)
Private Link 사용 권장 내부 서비스 접근용, 보안 강화

💻 2) 컴퓨팅 계층

항목설명
VMSS (Virtual Machine Scale Set) 다중 AZ 배포 + 자동 확장 가능
Azure App Service (Zone-redundant 지원) P3 이상 SKU에서 AZ 배포 가능
Availability Zone-aware 배포 VM 또는 App을 명시적으로 Zone에 배포

📌 권장 구성: 동일 Region 내 Zone1/2/3에 App 배치, Scale Set으로 관리

💾 3) 데이터 계층

항목설명
Azure SQL Database (Zone-redundant) Premium/Business-critical Tier에서 ZRS 제공
Azure Database for PostgreSQL / MySQL (Flexible Server) HA 설정 시 Zone 이중화 구성 가능
Azure Cosmos DB 멀티-AZ, 멀티-Region 활성화 가능
Azure Storage ZRS (Zone Redundant Storage) 블롭, 파일 등 객체 데이터의 자동 3AZ 복제

🔁 4) 복구 및 가용성

항목설명
Azure Site Recovery Region 간 DR 구성용, VM/DB 복제 가능
Azure Backup VM, SQL, Files 등 백업 정책 관리
RTO/RPO 기반 구성 RTO 짧을수록 ZRS + 자동 Failover 필수
Zone-aware Routing 트래픽이 정상 Zone으로 유도되도록 설정 필요

✅ 4. 실제 적용 시나리오

☑️ 시나리오 1: 웹 포탈 서비스 고가용성 구성

  • Front Door → VMSS + LB (Zone 1/2/3) → Azure SQL Zone-redundant
  • 이점: 웹 트래픽을 전 세계에서 수신 가능, AZ 장애 시에도 무중단 서비스 가능

☑️ 시나리오 2: 금융 API 시스템

  • App Service Premium (Zone Enabled)
  • Flexible Server DB (HA on + Zone Redundant)
  • Storage: ZRS + Geo-backup

결과: 금융거래 API의 중단 없이 고가용성 및 데이터 일관성 유지

✅ 5. 고가용성 구성 시 유의사항

고려사항설명
비용 증가 AZ간 트래픽 비용 및 복제 비용 발생
리전마다 AZ 개수 상이 일부 리전은 3개 AZ 미만일 수 있음
Zone-aware 서비스만 사용 일부 구형 서비스는 AZ 미지원
성능 분산 고려 DB Write Master는 단일 Zone일 수 있음 (지연 발생 가능)

✅ 6. 키워드 요약 (Ctrl+F 검색용)

  • Azure Front Door, Zone Redundant, VMSS, ZRS, Flexible Server,
    Site Recovery, Zone-aware, App Service Premium, Global Load Balancing

✅ 7. 요약 정리 (시험/블로그용)

항목적용 사례
네트워크 계층 Azure Front Door + LB (Zonal)
컴퓨팅 계층 VMSS (Zone-aware), App Service Premium
DB 계층 SQL DB ZRS, Flexible Server HA, CosmosDB
스토리지 계층 Azure Storage ZRS
백업/DR Azure Backup + Site Recovery
실전 적용 웹서비스, 금융API, 내부 포털, 운영툴 등

 

📘 Azure 고가용성(HA) 사례 기반 문제집 (총 20문항)

✅ NO.01

[객관식 / 난이도: 하]
Azure Availability Zone의 주된 목적은?
A. 리전 간 데이터 전송
B. 전력/네트워크 분리된 장애 격리
C. 동일 서브넷 내 IP 분산
D. 비용 절감을 위한 자원 축소

정답: B
해설: Availability Zone은 물리적 격리를 통해 고가용성을 보장한다.

✅ NO.02

[단답형 / 난이도: 중]
Azure에서 App Service를 고가용성으로 배포하고자 한다. 어떤 App Service 요금제를 선택해야 하는가?

정답: Premium P1 이상
해설: App Service는 Premium 요금제부터 Zone Redundant 구성을 지원함.

✅ NO.03

[객관식 / 난이도: 중]
Azure에서 다중존 구성을 위해 명시적으로 Zone을 지정하여 배포할 수 있는 리소스는?
A. Azure SQL Database
B. App Service Standard
C. Virtual Machine
D. Storage Account

정답: C
해설: VM은 Zone-aware 리소스로 명시적 Zone 지정 가능함.

✅ NO.04

[시나리오형 / 난이도: 상]
한 금융 서비스가 Azure Region 내 Zone 1에만 App과 DB를 구성하였다. Zone 1에 정전이 발생했다.
이 서비스의 가용성 문제를 해결하기 위한 근본적 조치는?

정답: App과 DB를 다중 Zone에 분산 구성
해설: 단일 Zone 구성은 AZ 장애 시 전체 서비스 중단 유발 → 다중 Zone 분산 필요.

✅ NO.05

[객관식 / 난이도: 중]
Azure SQL Database에서 Zone Redundant 구성을 위해 선택해야 하는 가격 티어는?
A. Basic
B. Standard
C. Premium or Business-critical
D. Free

정답: C
해설: Premium 및 Business-critical 티어에서 ZRS 옵션 제공됨.

✅ NO.06

[객관식 / 난이도: 중]
Azure Storage 계층 중 AZ 장애 시에도 데이터 유실 없이 제공 가능한 계층은?
A. LRS
B. GRS
C. ZRS
D. RA-GRS

정답: C
해설: ZRS는 Zone 간 3중 복제 지원 → AZ 장애에도 데이터 보존 가능.

✅ NO.07

[단답형 / 난이도: 하]
Azure에서 VMSS를 사용하여 고가용성을 구성할 경우, 가용성 설정 옵션 이름은?

정답: Zone Balancing / Zonal Distribution
해설: VMSS는 Zone 간 균등 분산을 통해 고가용성 확보 가능.

✅ NO.08

[객관식 / 난이도: 상]
Azure Front Door의 역할로 올바른 것은?
A. 내부 DB 암호화
B. VM 모니터링
C. 글로벌 트래픽 분산 및 Health Probe
D. 로컬 DNS 구성

정답: C
해설: Azure Front Door는 글로벌 LB + 헬스체크 기능 포함.

✅ NO.09

[시나리오형 / 난이도: 상]
Azure에서 Web App을 Zone 1/2/3에 배포했지만, 특정 Zone의 App이 느려 사용자 응답 시간이 지연되고 있다.
Azure Front Door를 사용하는 경우, 이 문제를 완화할 수 있는 기술은?

정답: Health Probe 기반 트래픽 라우팅
해설: AFD는 Zone 별 상태를 감지하고 비정상 Zone으로의 라우팅을 차단함.

✅ NO.10

[객관식 / 난이도: 중]
Azure VM에 대해 Azure Site Recovery를 구성하면 얻을 수 있는 이점은?
A. 동기식 복제로 실시간 RPO 보장
B. 리전 간 자동 DR 구성
C. 부하 분산 기능
D. 암호화 복제본 생성

정답: B
해설: Site Recovery는 리전 간 재해복구 구성을 자동화함.

✅ NO.11

[객관식 / 난이도: 중]
Azure Flexible Server (PostgreSQL/MySQL)에서 고가용성 구성을 위해 필수 설정은?
A. VNet Integration
B. HA 활성화 + Zone 지정
C. 자동 백업
D. Geo-replication

정답: B
해설: Flexible Server는 Zone 내 이중화 구성을 HA 설정으로 지원함.

✅ NO.12

[단답형 / 난이도: 중]
Azure App Gateway에 연결된 백엔드 VM 중 하나가 비정상일 경우, 사용자를 다른 VM으로 연결하기 위한 설정은?

정답: Health Probe
해설: 백엔드 상태 감지를 위한 헬스 프로브 설정이 필수임.

✅ NO.13

[객관식 / 난이도: 상]
Azure 고가용성 설계 시 고려 대상이 아닌 것은?
A. Zone Redundant Storage
B. Sticky Session
C. Availability Set
D. DNS TTL

정답: B
해설: Sticky Session은 로드 밸런싱 균형을 깨뜨릴 수 있어 HA 설계에서는 비권장.

✅ NO.14

[시나리오형 / 난이도: 상]
App 서비스가 특정 리전에서만 배포되어 있고, 해당 리전 전체 장애 발생 시 백업 리전으로 트래픽을 자동 전환하고 싶다.
적절한 구성은?

정답: Azure Front Door + 다중 리전 App 배포
해설: AFD는 리전 상태에 따라 백업 리전으로 라우팅 가능.

✅ NO.15

[객관식 / 난이도: 중]
Azure Load Balancer는 내부와 외부 모두 가능하다. 내부 LB를 활용하는 대표적 시나리오는?
A. WebApp → DB 연결
B. 사용자 → WebApp 접근
C. Azure Files 백업
D. Blob Storage 마이그레이션

정답: A
해설: 내부 LB는 내부 트래픽 분산용으로 사용됨 (예: App → DB).

✅ NO.16

[단답형 / 난이도: 하]
Azure에서 백업 정책을 통합 관리할 수 있는 리소스 이름은?

정답: Recovery Services Vault
해설: Backup/Restore 정책은 Vault에서 통합 관리됨.

✅ NO.17

[객관식 / 난이도: 중]
Availability Set은 어떤 목적에 가장 적합한가?
A. Region 이중화
B. DR 구성
C. AZ 간 복제
D. VM 간 장애 격리

정답: D
해설: Availability Set은 VM 간 장애 도메인/업데이트 도메인을 분리하여 격리함.

✅ NO.18

[시나리오형 / 난이도: 상]
VMSS로 구성된 App 서버가 트래픽 증가로 인해 확장 중인데, 신규 인스턴스 기동 시간이 3분 이상 걸린다.
이로 인한 응답 지연을 줄이기 위한 Azure 기능은?

정답: Warm Pool
해설: 미리 기동된 인스턴스를 대기시켜 확장 시간 단축 가능.

✅ NO.19

[객관식 / 난이도: 중]
Azure SQL DB 장애 발생 시 자동으로 Standby로 전환되는 기능은?
A. Failover Group
B. Geo-Replication
C. Read Replica
D. Manual Snapshot

정답: A
해설: Failover Group은 자동 장애 전환을 지원함.

✅ NO.20

[단답형 / 난이도: 중]
Azure에서 Zone 장애 발생 시 동일 Region 내 정상 Zone으로 트래픽을 분산하는 구성 요소는?

정답: Azure Load Balancer (Zonal) or App Gateway
해설: LB나 App Gateway는 AZ별 라우팅을 지원하며 헬스 체크 기반 분산 가능.

 

📊 Azure 고가용성 설계 문제 – 3단 구성표 (문제 | 정답 | 해설)

번호문제정답해설
01 Azure Availability Zone의 주된 목적은? B 전력/네트워크가 분리된 장애 격리 단위로 고가용성 보장
02 App Service를 고가용성으로 배포하려면 필요한 요금제는? Premium P1 이상 Premium 요금제부터 Zone Redundant 지원
03 Zone 지정 배포 가능한 리소스는? C VM은 명시적 Zone 지정이 가능함
04 Zone 1에만 App과 DB 구성 → 정전 발생. 해결방안은? 다중 Zone 분산 구성 단일 AZ 구성은 치명적 → AZ 분산 필수
05 Azure SQL ZRS 구성을 위해 선택할 티어는? C Premium, Business-critical에서 ZRS 지원
06 AZ 장애에도 데이터 유실 없는 Storage는? C ZRS는 3개 AZ에 동시 복제
07 VMSS 고가용성 구성 시 사용하는 설정은? Zone Balancing Zone 간 균형 분산 배포 설정 필요
08 Azure Front Door의 기능은? C 글로벌 트래픽 분산 + 헬스체크 기능
09 특정 Zone 지연 발생 시 Front Door의 해결 방법은? Health Probe 기반 트래픽 라우팅 상태 기반으로 비정상 Zone 회피
10 Site Recovery 구성 시 효과는? B 리전 간 자동 복제 및 장애 전환 구성 가능
11 Flexible Server HA 구성 방법은? B HA 설정 + Zone 지정으로 이중화 구성
12 App Gateway 백엔드 VM 감지 설정은? Health Probe 상태 점검 통해 장애 인스턴스 제외
13 HA 설계에서 고려 대상이 아닌 것은? B Sticky Session은 장애 시 분산 불가 위험
14 리전 장애 시 백업 리전 자동 전환을 위한 구성은? AFD + 다중 리전 배포 Front Door로 상태 기반 리전 전환 가능
15 내부 LB 대표 시나리오는? A 내부 트래픽 분산: WebApp → DB
16 Azure 백업 정책 통합 관리 리소스는? Recovery Services Vault 백업 스케줄 및 보존 정책 관리
17 Availability Set 주요 목적은? D 장애/업데이트 도메인 분리로 고가용성 보장
18 VMSS 확장 지연 최소화 위한 기능은? Warm Pool 사전 기동 인스턴스 대기상태 유지
19 SQL DB 자동 장애 전환 기능은? Failover Group 자동 장애 인지 및 전환 지원
20 Zone 장애 발생 시 트래픽 분산 구성 요소는? Azure LB or App Gateway Zone별 라우팅 지원 + 헬스 체크 기반 분산

 

🧠 Azure 고가용성 설계 암기카드 요약 (20개)

  1. Availability Zone (AZ) – 장애 격리된 데이터센터, 전력·네트워크 독립
  2. App Service HA 요금제 – Premium P1 이상부터 Zone Redundant 지원
  3. Zone 지정 배포 리소스 – VM은 Zonal 배포 가능 (Zone-aware)
  4. AZ 단일 구성의 문제 – AZ 장애 시 전체 서비스 중단 → AZ 분산 필요
  5. SQL ZRS 구성 요금제 – Premium, Business-critical만 Zone Redundant 가능
  6. ZRS (Zone-Redundant Storage) – 3개의 AZ에 실시간 동기 복제
  7. VMSS HA 구성 옵션 – Zone Balancing 설정으로 Zone 간 균등 배치
  8. Azure Front Door (AFD) – 글로벌 트래픽 분산 + 헬스체크 + HTTPS 오프로드
  9. AFD 트래픽 회피 기능 – Health Probe 기반으로 비정상 Zone 차단
  10. Site Recovery 목적 – 리전 간 DR(재해복구) 자동 구성
  11. Flexible Server HA 구성 – HA 활성화 + Zone 지정으로 자동 Failover
  12. App Gateway 장애 감지 – Health Probe로 백엔드 VM 상태 확인
  13. Sticky Session 주의 – HA 구조에선 로드밸런싱 효율을 저해할 수 있음
  14. 리전 장애 대비 구성 – Azure Front Door + 다중 리전 배포 조합 필요
  15. 내부 Load Balancer 활용 – App → DB 연결 등 내부 트래픽 분산
  16. Backup 통합 관리 리소스 – Recovery Services Vault 사용
  17. Availability Set 목적 – 장애 도메인/업데이트 도메인 분리
  18. VMSS 확장속도 개선 – Warm Pool로 사전 기동된 인스턴스 유지
  19. SQL DB 자동 Failover – Failover Group으로 장애 시 자동 전환
  20. Zone 장애 시 분산 구성 요소 – Azure Load Balancer 또는 App Gateway
 


아래는 Kubernetes Storage의 구조와 유형을 설명한 후, Azure Landing Zone 관점에서 스토리지 설계 시 고려해야 할 요소를 TA 실무 기준에서 정리한 내용입니다.

📦 1. Kubernetes Storage 설명

✅ 개요

Kubernetes에서 스토리지는 컨테이너와 분리된 외부 저장소로 취급되며, Pod가 재시작되더라도 데이터를 유지하기 위한 목적으로 사용됩니다.

Kubernetes는 스토리지를 다음 세 가지 계층으로 관리합니다:

계층설명
Volume Pod 내에서 사용하는 저장소 공간 (Container 생명주기와 별도)
PersistentVolume(PV) 클러스터에 사전 정의된 스토리지 자원
PersistentVolumeClaim(PVC) 사용자가 요청한 스토리지 명세 (스토리지 크기, 접근모드 등)

✅ Kubernetes Storage 핵심 개념

용어설명
PV (Persistent Volume) 클러스터 관리자가 만든 실제 스토리지 객체. NFS, iSCSI, Azure Disk 등 연결 가능
PVC (Persistent Volume Claim) 개발자가 요청한 요구사항. PVC가 PV에 매칭되어 바인딩됨
StorageClass 어떤 종류의 스토리지를 사용할 것인지 정의 (예: SSD, Azure Disk, Standard HDD 등)
AccessMode ReadWriteOnce, ReadOnlyMany, ReadWriteMany (RWX 등)
VolumeMode Filesystem 또는 Block (특정 DB 등에 사용)
Dynamic Provisioning PVC를 생성하면 자동으로 PV도 함께 생성 (StorageClass 기반)

✅ Kubernetes에서 지원하는 스토리지 유형 예시

유형예시설명
클라우드 스토리지 Azure Disk, AWS EBS, GCE PD 클라우드 네이티브 Block Storage
파일 기반 스토리지 NFS, Azure File, EFS 공유 폴더 형태, ReadWriteMany 지원
로컬 스토리지 HostPath, Local Volume 특정 노드에 종속됨 (고성능 캐시 등)
CSI (Container Storage Interface) Ceph, Portworx, NetApp 등 외부 스토리지 공급자와 통합된 표준 인터페이스

✅ 실무 설계 시 고려사항

  • RWX 접근모드가 필요한 경우 Azure Disk는 불가 → Azure Files, NFS 등 사용
  • DB용 스토리지는 Block 기반 + 고성능 스토리지 클래스 설정
  • 데이터 손실 방지를 위해 Volume은 StatefulSet과 함께 설계
  • 백업 및 복구 연계: VolumeSnapshot / VolumeSnapshotClass 활용

☁️ 2. Kubernetes Storage 설계 – Azure Landing Zone 관점

✅ Landing Zone이란?

Azure Landing Zone은 조직이 클라우드 환경을 일관성 있게 설계하고 배포할 수 있는 아키텍처 템플릿입니다.
스토리지 관점에서는 Kubernetes + Azure의 연결이 아래와 같은 기준으로 정의됩니다.

✅ Azure Landing Zone에서 스토리지 설계 시 고려 포인트

항목설명
StorageClass 표준화 개발팀이 PVC를 생성할 때 사용할 수 있는 StorageClass 미리 정의 (예: azure-disk-premium, azurefile-csi)
Region/Zone 복제 정책 ZRS(Zonal), LRS(Local), GRS(Geo) 등 스토리지 복제 설정 통일
IAM 및 보안 정책 스토리지 계정 키 대신 AAD Pod Identity 또는 CSI Driver + Managed Identity 사용하여 보안 강화
Backup 정책 VolumeSnapshotClass 기반 자동 백업 및 보존 정책 구성
Monitoring/Logging 연계 Azure Monitor + Application Insights 연동하여 Disk IOPS, 사용량, 실패율 등 모니터링
Private Endpoint 적용 스토리지 계정에 Public Access 차단, VNet 통합 필수
Storage KPI 정의 RPO, RTO, IOPS, Throughput 등 스토리지 SLA 기준 명시

✅ 예시: Azure Kubernetes Service + Azure Disk

 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-disk-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  kind: Managed
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
  • 위와 같이 StorageClass를 정의하여 개발자들이 PVC 생성 시 명시적으로 선택하도록 유도
  • Storage KPI, 스냅샷, 가용성 영역은 Landing Zone Policy 또는 Blueprint에 명시

✅ TA 시험 포인트 정리

  • StorageClass와 PVC/PV 구조 명확히 이해
  • CSI vs In-tree Driver 비교 가능
  • Azure Disk와 Azure File의 RWX/RWO 차이 파악
  • VNet Integration + Private Endpoint 보안 설계
  • Landing Zone에서 Storage 전략을 문서화할 수 있어야 함
  • Azure Monitor로 스토리지 성능/오류 추적 구성 가능해야 함

 

StorageClass와 PVC/PV 구조를 설명해줘

ChatGPT의 말:

좋습니다! 아래는 Kubernetes에서 **StorageClass, PersistentVolume(PV), PersistentVolumeClaim(PVC)**의 구조와 동작 원리를 TA 실무 관점에서 정리한 설명입니다.

📘 StorageClass, PV, PVC 구조 설명

✅ 1. 전체 흐름 개요

Kubernetes의 스토리지는 다음과 같은 3단계 구조로 구성됩니다:

 
[StorageClass] ← (정책/유형 정의)
      ↑
[PersistentVolume] ← (관리자 정의 or 자동 생성)
      ↑
[PersistentVolumeClaim] ← (사용자가 요청)
      ↑
[Pod] ← (Volume mount 요청)
 

즉, 사용자는 PVC를 만들고, 그 PVC는 PV에 연결되고, 그 PV는 StorageClass의 정책을 따릅니다.

✅ 2. 구성 요소 설명

📌 A. StorageClass (SC)

스토리지의 **클래스(정책)**를 정의하는 객체.
어떤 종류의 디스크를 만들지, 어떤 프로비저너를 쓸지, 가용성 수준은 어떤지를 정의.

항목설명
provisioner 실제로 스토리지를 프로비저닝할 CSI 드라이버 (예: disk.csi.azure.com)
parameters 디스크 종류 (Premium_LRS, StandardSSD_LRS 등)
volumeBindingMode 즉시 생성(Immediate) or Pod 스케줄링 후 생성(WaitForFirstConsumer)
allowVolumeExpansion 디스크 확장 허용 여부

예시: Azure Disk Premium용 StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-disk-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  kind: Managed
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

 

📌 B. PersistentVolume (PV)

클러스터에 존재하는 실제 스토리지 자원.
관리자 또는 동적 프로비저닝에 의해 생성.

항목설명
capacity 크기 (예: 10Gi)
accessModes RWO / ROX / RWX (읽기쓰기 권한)
volumeMode Filesystem 또는 Block
storageClassName 어떤 StorageClass 정책을 따르는지

📌 C. PersistentVolumeClaim (PVC)

사용자가 요청하는 스토리지 명세.
스토리지 크기, 접근 방식, StorageClass 지정.

항목설명
resources.requests.storage 요청 크기 (예: 5Gi)
accessModes 접근 모드 (예: ReadWriteOnce)
storageClassName 요청할 스토리지 클래스 지정

예시: PVC

 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: azure-disk-premium

📌 D. Pod 내 볼륨 연결

Pod에서는 PVC를 참조하여 실제 디스크를 컨테이너에 mount 합니다.

 
volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: pvc-example

✅ 3. 실무 고려사항

항목고려 포인트
접근 모드 RWX(ReadWriteMany)가 필요한 경우 Azure Disk는 안 됨 → Azure Files, NFS 사용
Pod 스케줄링 연동 WaitForFirstConsumer 모드는 Pod의 노드에 따라 디스크 리전을 자동 선택함
동적 vs 정적 프로비저닝 대부분은 PVC → PV 자동 생성(Dynamic), 하지만 특수 환경에서는 사전 정의 필요
디스크 확장 allowVolumeExpansion: true로 SC에서 지정 필요 + kubectl patch pvc 가능
Snapshot/Backup VolumeSnapshotClass와 연동하여 정기 백업 구성 가능

✅ 요약 (한줄 키워드)

개념키워드 요약
SC 디스크 유형/속성 정의
PV 실제 자원 (동적 or 정적 생성)
PVC 사용자 요청 사양 (크기/접근권한)
Pod PVC를 참조해 mount
AccessMode RWO / RWX 구분 (Azure Disk는 RWO만)
Dynamic Provisioning PVC 생성 시 자동 PV 할당
volumeBindingMode Pod 위치 기반 스토리지 최적화
CSI Driver Azure, AWS 등 클라우드별 스토리지 플러그인

 

📘 [파트1] Kubernetes Storage 개요 문제 (객관식 중심)

📌 문항 1

Kubernetes에서 PersistentVolumeClaim(PVC)의 역할로 올바른 것은?

① 스토리지 공급자 CSI 드라이버를 설정한다
② 사용자가 요구하는 스토리지 사양을 정의한다
③ 특정 Pod에서만 마운트 가능한 로컬 디스크를 생성한다
④ 클러스터 전체 로깅을 담당한다
⑤ 스냅샷 기반 백업을 자동화한다

정답: ②
해설: PVC는 사용자가 요청하는 스토리지 용량, 접근 모드, StorageClass를 지정하는 추상화 객체입니다.

📌 문항 2

다음 중 StorageClass의 주요 속성이 아닌 것은?

① provisioner
② parameters
③ storageCapacity
④ volumeBindingMode
⑤ allowVolumeExpansion

정답: ③
해설: storageCapacity는 실제 PV의 속성이며, StorageClass에는 존재하지 않습니다.

📌 문항 3

PersistentVolume(PV)이 Pod에 마운트되기 위해 반드시 필요한 구성 요소는?

① configMap
② StorageClass
③ PersistentVolumeClaim
④ Ingress
⑤ StatefulSet

정답: ③
해설: Pod은 직접 PV를 참조하지 않고, PVC를 통해 바인딩된 PV를 참조합니다.

📌 문항 4

AccessMode가 ReadWriteMany(RWX)인 스토리지를 사용하려면 적절한 예시는?

① Azure Disk
② AWS EBS
③ HostPath
④ Azure File
⑤ CSI Block Volume

정답: ④
해설: Azure Disk는 RWO 전용이고, Azure File이나 NFS와 같은 공유 파일 기반 스토리지만 RWX 지원함.

📌 문항 5

다음 중 Kubernetes에서 **동적 스토리지 프로비저닝(Dynamic Provisioning)**을 사용하기 위한 필수 조건은?

① PV가 수동으로 먼저 생성되어 있어야 한다
② Pod에 직접 StorageClass를 지정해야 한다
③ PVC에서 StorageClassName을 명시해야 한다
④ VolumeSnapshot이 등록되어 있어야 한다
⑤ CSI 드라이버를 수동 컴파일해야 한다

정답: ③
해설: PVC가 특정 StorageClass를 참조하면, Kubernetes는 해당 SC에 정의된 provisioner로 PV를 자동 생성함.

🧪 [파트2] 장애 대응 기반 실무 시나리오 문제

📌 시나리오 문제 1

상황: 개발팀이 StatefulSet 기반의 Redis 클러스터를 배포하였고, Azure Disk를 StorageClass로 사용하고 있다.
문제: 노드 장애 발생 후, Redis Pod가 새로운 노드에서 계속 Pending 상태로 유지되고 있다.
원인으로 가장 가능성이 높은 것은?

① Azure Disk는 RWX이기 때문에 Pod가 어디서든 마운트 가능
② StatefulSet은 PVC를 자동 삭제하므로 디스크가 사라졌다
③ StorageClass의 volumeBindingMode가 Immediate로 되어 있어 스케줄링이 안 맞는다
④ Redis 이미지에 entrypoint 설정이 누락되었다
⑤ PVC가 동적이 아니라 정적 바인딩이다

정답: ③
해설: Azure Disk는 지역 종속적인 RWO 스토리지이므로 WaitForFirstConsumer 모드를 사용해야 Pod 스케줄링 이후 디스크가 할당된다.

📌 시나리오 문제 2

상황: NFS 기반 RWX 스토리지를 사용하는 Web App에서 자주 디스크 오류가 발생하며, I/O error, stale file handle이 로그에 출력된다.
질문: 이 문제를 해결하기 위한 조치로 가장 먼저 수행해야 할 것은?

① StorageClass를 Block 기반으로 변경한다
② DNS 캐시를 초기화한다
③ NFS 서버의 timeout 설정과 클라이언트의 hard 마운트 옵션을 점검한다
④ 스토리지 계정의 Access Key를 재발급한다
⑤ Web App 이미지를 재빌드한다

정답: ③
해설: stale file handle은 NFS 재연결/타임아웃 문제일 가능성이 높음. 서버/클라이언트 양쪽 timeout 및 마운트 옵션(timeo, soft, hard)을 점검해야 한다.

📌 시나리오 문제 3

상황: 개발팀이 PVC와 VolumeSnapshot을 이용해 디스크 스냅샷을 생성하고 복원하려 했지만, 복원된 볼륨으로 Pod가 시작되지 않는다.
가능한 원인은?

① PVC 이름이 Snapshot과 다르기 때문
② Pod이 Liveness Probe를 사용하지 않아서
③ VolumeSnapshotClass와 StorageClass가 호환되지 않음
④ CSI 드라이버 버전이 너무 높음
⑤ PV 용량이 줄어들었기 때문

정답: ③
해설: VolumeSnapshot은 특정 CSI 드라이버 및 StorageClass와 연동 호환성이 요구되므로, 맞지 않을 경우 복원 불가.

📌 시나리오 문제 4

상황: 특정 Pod가 항상 CrashLoopBackOff 상태이며, 로그에는 /data 경로가 존재하지 않는다고 나온다. 해당 Pod는 PVC를 마운트하여 /data를 사용하도록 되어 있다.
원인으로 가장 적절한 것은?

① PVC가 할당된 PV의 accessMode가 ReadOnlyMany로 설정됨
② StorageClass의 allowVolumeExpansion이 false임
③ PVC가 아직 Bound 상태가 아님
④ initContainer가 실패했기 때문
⑤ Pod가 Deployment로 배포되어 있음

정답: ③
해설: PVC가 Bound되지 않으면 Volume이 마운트되지 않고, /data 경로가 존재하지 않는다는 오류로 이어짐.

📌 시나리오 문제 5

상황: 운영 중인 MySQL StatefulSet에서 Azure Disk를 사용 중이고, 사용자가 디스크 성능이 낮다고 불만을 제기했다.
가장 먼저 점검해야 할 항목은?

① 로그 레벨
② Azure Disk의 SKU (Premium/Standard 여부)
③ Kubernetes 버전
④ RBAC 권한
⑤ Deployment 전략

정답: ②
해설: Azure Disk는 SKU에 따라 IOPS/Throughput이 다르므로, Standard HDD 사용 시 성능 저하가 발생할 수 있음.

아래는 Kubernetes Storage에서 실무에서 자주 사용하는 기법 또는 설정 패턴을 기반으로 한 문제들을 TA 시험 스타일로 추가 구성한 것입니다.
총 10문항이며, 정답과 해설 포함, 전부 실제 현업에서 자주 등장하는 기술을 기반으로 제작되었습니다.

📘 Kubernetes Storage 실무 활용 기반 문제 (10문항)

📌 문항 1

Kubernetes에서 Azure Disk를 사용하는 PVC의 크기를 기존 5Gi에서 10Gi로 확장하고자 한다. 필요한 조건으로 올바르지 않은 것은?

① StorageClass에 allowVolumeExpansion: true가 설정되어야 한다
② PVC의 상태가 Bound 상태여야 한다
③ 디스크를 사용하는 Pod가 반드시 실행 중이어야 한다
④ kubectl edit pvc 또는 kubectl patch pvc 명령으로 확장해야 한다
⑤ CSI 드라이버가 디스크 확장을 지원해야 한다

정답: ③
해설: 디스크 확장은 Pod의 실행 여부와 무관하며, PVC 상태와 StorageClass 설정 및 CSI 지원이 중요 요소입니다.

📌 문항 2

Azure Files를 StorageClass로 사용하는 경우 적합한 활용 시나리오는?

① 로그 파일 저장소로 사용되며 여러 Pod에서 동시에 읽기/쓰기가 필요함
② 데이터베이스의 고속 Random I/O를 요구하는 블록 저장소
③ 특정 노드에만 고정되어야 하는 로컬 디스크
④ 성능보다 저렴한 비용이 우선인 경우로, 백업에만 사용
⑤ 컨테이너 이미지 저장소용으로 활용

정답: ①
해설: Azure Files는 RWX를 지원하므로 여러 Pod가 동시에 접근 가능하여 공유 저장소용으로 이상적입니다.

📌 문항 3

StatefulSet으로 구성된 애플리케이션에서 PVC를 삭제하지 않고 Pod만 재생성할 경우, 예상되는 동작은?

① PV도 함께 삭제되어 데이터가 손실됨
② PVC는 삭제되나 Pod가 새롭게 생성되며 다시 PVC가 자동 생성됨
③ PVC는 그대로 유지되며, Pod가 다시 해당 PVC를 참조함
④ Pod는 PVC를 사용할 수 없어 CrashLoopBackOff 상태가 됨
⑤ Pod는 디스크 없이 시작되며 임시 볼륨을 생성함

정답: ③
해설: StatefulSet은 각 Pod에 고유 PVC를 바인딩하며, Pod만 삭제할 경우 PVC는 남아 있어 데이터 유지됨.

📌 문항 4

Azure Files 기반의 RWX PVC를 사용하는 Pod가 성능 저하를 겪고 있다. 아래 조치 중 가장 효과적인 접근은?

① accessMode를 ReadOnly로 변경
② mount 옵션에 cache=none을 적용
③ Azure Premium File Share SKU로 변경
④ Pod의 restartPolicy를 Always로 변경
⑤ CSI 드라이버를 직접 패치

정답: ③
해설: 기본 Azure Files는 성능이 제한적이므로, Premium File Share로 변경하여 IOPS/Throughput을 향상시킬 수 있음.

📌 문항 5

다음 중 Kubernetes에서 CSI Snapshot을 사용하는 목적으로 틀린 것은?

① PVC 백업 및 복구 시점 저장
② 테스트 환경을 원본과 동일하게 복제
③ Pod 간 볼륨 공유를 위한 용도
④ 데이터 무결성 유지 및 감사 대응
⑤ 자동화된 복원 작업에 활용

정답: ③
해설: Snapshot은 복제용이거나 백업 용도이며, Pod 간 공유 용도는 아님 (RWX 설정된 별도 볼륨 필요).

📌 문항 6

스토리지 사용량을 모니터링하고 경고 알림을 보내기 위해 연동할 수 있는 Azure 서비스는?

① Azure Backup Vault
② Azure Monitor + Prometheus Adapter
③ Azure Load Balancer
④ Azure DNS Private Zone
⑤ Azure Key Vault

정답: ②
해설: 스토리지의 성능/사용량 모니터링은 Azure Monitor, Prometheus, Grafana 등과 연계하여 경고 조건 기반 대응 가능.

📌 문항 7

Kubernetes에서 HostPath를 사용한 스토리지는 주로 어떤 목적에 사용되는가?

① 고가용성 DB의 운영 저장소
② 개발 환경에서 로컬 디스크 기반 로그 저장소
③ RWX 공유 볼륨
④ 클러스터 간 공유 디스크
⑤ CSI 기반의 볼륨 백업 기능

정답: ②
해설: HostPath는 특정 노드의 로컬 디렉토리를 사용하므로, 주로 테스트용 또는 임시 로그 저장소에 사용.

📌 문항 8

Azure에서 동적 PVC 생성을 위한 기본 구성 요소가 아닌 것은?

① StorageClass
② PersistentVolumeClaim
③ provisioner 드라이버
④ VolumeSnapshot
⑤ CSI Controller

정답: ④
해설: Snapshot은 백업을 위한 리소스이며, 동적 생성에는 StorageClass, PVC, provisioner 등이 필요함.

📌 문항 9

스토리지 장애 시 PVC를 새로운 디스크로 교체하려면 어떤 단계가 필요하지 않은가?

① 기존 PVC 삭제
② 새로운 PVC 생성
③ Pod 내 volume 이름 변경
④ 기존 Pod 재시작
⑤ 새로운 PVC가 이전 StorageClass와 동일해야 함

정답: ③
해설: Pod의 volume 이름은 YAML 내에서 고정되어 있어 변경하지 않고 PVC 참조만 바꾸면 됨.

📌 문항 10

다음 중 Pod가 스토리지를 사용하면서 겪을 수 있는 대표적인 운영 이슈가 아닌 것은?

① PVC가 Bound 되지 않음
② 스토리지 IOPS 부족
③ Pod의 volumeMount 경로 오타
④ accessMode 불일치
⑤ Service 이름이 잘못 지정됨

정답: ⑤
해설: 스토리지는 Service 구성과 무관하며, 주로 PVC 상태, mount 설정, 디스크 성능 문제가 연관됩니다.

아래는 Kubernetes Storage 실무 활용 기반 추가 10문항입니다.
이전과 동일하게 문제-정답-해설 구성이며, TA 실무에서 자주 출제되는 패턴으로 제작되었습니다.

📘 Kubernetes Storage 실무 문제 (추가 10문항)

📌 문항 11

Azure Disk를 사용하는 Kubernetes Pod가 재시작될 때 마다 디스크가 새로운 노드로 재마운트 되지 못하는 상황이 반복된다. 이 문제의 가장 유력한 원인은?

① accessMode를 ReadOnly로 설정함
② volumeMode가 Block으로 설정됨
③ 디스크의 Zone이 Pod가 스케줄된 노드와 다름
④ StorageClass가 잘못 지정됨
⑤ Pod에 initContainer가 없음

✅ 정답: ③
📝 해설: Azure Disk는 Zone 단위 리소스이므로, Pod가 다른 Zone 노드에 배치되면 재마운트가 실패할 수 있음.

📌 문항 12

Pod에 PVC가 제대로 바인딩되었지만, 실제 컨테이너 내에 파일이 보이지 않는다. 가장 먼저 점검해야 할 항목은?

① PVC의 size
② volumeMount 경로
③ accessMode
④ StorageClass
⑤ CSI 로그

✅ 정답: ②
📝 해설: PVC가 mount 되었더라도 컨테이너 내에서 volumeMount 경로가 잘못 설정되면 실제 사용 불가능.

📌 문항 13

Kubernetes에서 CSI 기반 Azure Disk의 성능이 급격히 저하될 때, 다음 중 조치로 부적절한 것은?

① 디스크 SKU를 Standard HDD에서 Premium SSD로 변경
② pod affinity를 활용하여 동일 Zone 내 Pod 유치
③ 동일 디스크를 여러 Pod가 공유하도록 RWX 모드 활성화
④ IOPS 향상을 위해 디스크 크기 확장
⑤ ReadOnly 모드로 연결하여 읽기 전용 처리

✅ 정답: ③
📝 해설: Azure Disk는 기본적으로 RWO 전용이며, 여러 Pod가 공유 불가하므로 RWX 목적에 적절하지 않음.

📌 문항 14

다음 중 StatefulSet이 스토리지를 사용할 때 일반 Deployment와 다르게 동작하는 점은?

① Pod 수 증가 시 동일한 PVC를 공유함
② Pod 삭제 시 자동으로 PVC도 삭제됨
③ Pod마다 고유한 PVC를 가진다
④ StorageClass는 필수 항목이다
⑤ Pod는 항상 같은 노드에서 실행된다

✅ 정답: ③
📝 해설: StatefulSet은 각 Pod에 고유 이름의 PVC를 자동 생성하여 영구 저장소 분리를 보장함.

📌 문항 15

Azure Files를 사용하는 StorageClass를 생성할 때, 다음 중 필수 구성 요소는?

① skuname, kind, cache
② location, type, accountType
③ provisioner, parameters, reclaimPolicy
④ nodeSelector, taints, tolerations
⑤ mountOptions, iops, tier

✅ 정답: ③
📝 해설: StorageClass에는 provisioner와 parameters(skuname, kind 등) 및 optional한 reclaimPolicy 등이 필수로 포함됨.

📌 문항 16

Pod의 로그 파일을 보존하기 위한 목적이라면 어떤 스토리지가 가장 적합한가?

① ephemeralVolume
② HostPath
③ Azure Disk
④ Azure Files (RWX)
⑤ EmptyDir

✅ 정답: ④
📝 해설: 로그 파일은 여러 Pod가 접근/기록할 수 있도록 **공유 저장소(RWX)**가 적합하며, Azure Files가 대표적.

📌 문항 17

Pod와 연결된 PVC가 Pending 상태에서 벗어나지 못하는 원인은?

① Pod가 실행 중이 아니어서
② StorageClass의 이름이 오타
③ Pod에서 volumeMount를 설정하지 않음
④ 디스크 크기가 너무 작음
⑤ 노드에 충분한 CPU가 없음

✅ 정답: ②
📝 해설: PVC가 PV와 바인딩되지 않는 가장 흔한 이유는 StorageClass 명 오타, 리소스 미존재 등 설정 오류임.

📌 문항 18

Kubernetes에서 디스크를 Snapshot으로 백업하고, 동일한 내용을 가진 PVC를 새로 만들고자 할 때 필요한 자원은?

① VolumeSnapshot, PVC
② PV, PVC, Secret
③ StorageClass, Service
④ Deployment, ConfigMap
⑤ Node, Toleration

✅ 정답: ①
📝 해설: CSI 기반 VolumeSnapshot은 새 PVC 생성 시 DataSource로 지정하여 기존 디스크 상태 복원 가능.

📌 문항 19

Pod 재시작 시 스토리지 마운트가 실패하며 mount failed 에러가 발생할 경우 우선적으로 점검할 요소는?

① CSI 로그 및 이벤트
② Azure Monitor 경고 알림
③ Storage Account SKU
④ PVC 요청 크기
⑤ Service 이름

✅ 정답: ①
📝 해설: CSI 기반 볼륨 마운트 실패는 kubelet 로그 및 CSI 에러 로그에서 원인을 확인 가능함.

📌 문항 20

Azure Files를 사용하는 경우 파일 시스템 기반 RWX 저장소로 사용하기 위해 권장되는 설정은?

① volumeBindingMode: Immediate
② skuname: Standard_LRS, kind: Fileshare
③ mountOptions: [“nobrl”]
④ parameters: usePrivateEndpoint=true
⑤ provisioner: azure-disk.csi.azure.com

✅ 정답: ③
📝 해설: nobrl 옵션은 파일 잠금 충돌을 줄이기 위해 RWX 공유시 권장 mount 옵션으로 사용됨.

 

스토리지는 시스템 아키텍처에서 매우 중요한 역할을 하며, 각각의 스토리지 유형은 성능, 용도, 비용, 가용성 측면에서 특성이 다릅니다.
아래는 스토리지 종류별 특성과 주요 용도, 그리고 상호 비교표입니다.

📘 스토리지 종류별 용도 및 특성

1. 블록 스토리지 (Block Storage)

  • 대표 기술/서비스: Azure Disk, Amazon EBS, iSCSI, FC(Storage Area Network)
  • 특징:
    • 스토리지를 블록 단위로 관리하며, 로우 레벨 I/O 제어 가능
    • 고성능, 빠른 읽기/쓰기, 저지연
    • 일반적으로 VM, DB, 트랜잭션 시스템에 사용
  • 용도:
    • 고속 데이터베이스
    • VM의 루트 디스크, OS 디스크
    • 로그 저장

2. 파일 스토리지 (File Storage)

  • 대표 기술/서비스: NFS, SMB, Azure Files, Amazon EFS
  • 특징:
    • 파일 단위 접근, 공유 가능 (RWX 지원)
    • 운영체제의 파일 시스템처럼 mount하여 사용
    • 여러 클라이언트에서 동시 접근 가능
  • 용도:
    • 로그 공유
    • 컨테이너 공유 디렉토리 (ex. 여러 Pod가 동일 디렉토리 접근)
    • 사내 문서 저장, 이미지 저장

3. 오브젝트 스토리지 (Object Storage)

  • 대표 기술/서비스: Amazon S3, Azure Blob, Google Cloud Storage
  • 특징:
    • 파일을 오브젝트로 저장 (메타데이터 + 데이터 + 고유 ID)
    • REST API 기반 접근, 글로벌 확장성
    • 버전 관리, 수명주기 관리 용이
  • 용도:
    • 백업/아카이빙
    • 미디어 파일, 로그 수집
    • 웹 콘텐츠 저장 (이미지, 동영상, 정적 파일)

4. 로컬 스토리지 (Local/Host Storage)

  • 대표 기술/서비스: HostPath (Kubernetes), 로컬 디스크
  • 특징:
    • 특정 노드의 디스크를 직접 mount
    • 빠르지만 고가용성 보장 안됨
    • 노드 장애 시 데이터 손실 위험
  • 용도:
    • 테스트 환경
    • 임시 로그 저장
    • 단일 노드 앱

5. 분산 스토리지 (Distributed Storage)

  • 대표 기술/서비스: Ceph, GlusterFS, Longhorn, Portworx
  • 특징:
    • 여러 노드에 데이터 분산 저장
    • 중복성, 확장성, 고가용성 보장
    • 자체적으로 CSI 지원 가능
  • 용도:
    • 쿠버네티스 내 영속 볼륨 제공
    • 대용량 비정형 데이터 처리
    • 멀티AZ 또는 하이브리드 클러스터 환경

📊 스토리지 종류 비교표

구분성능가용성공유 접근주 사용처예시 서비스
블록 스토리지 매우 높음 중 ❌ DB, VM OS, 고속 트랜잭션 Azure Disk, EBS
파일 스토리지 중~높음 중 ⭕ RWX 로그, 문서, 여러 Pod 공유 Azure Files, NFS, EFS
오브젝트 스토리지 중 매우 높음 ⭕ (API) 백업, 정적 자산, 미디어 파일 Azure Blob, Amazon S3
로컬 스토리지 높음 낮음 ❌ 테스트, 단일 노드, 캐시 HostPath, Local SSD
분산 스토리지 높음 매우 높음 ⭕ 쿠버네티스 영속 볼륨, 대용량 데이터 Ceph, Longhorn, Portworx

💡 클라우드/K8s 환경에서 선택 기준

  • 고성능 DB → Block Storage (ex. Azure Disk)
  • Pod 간 공유 저장소 → File Storage (ex. Azure Files RWX)
  • 백업/정적 파일 관리 → Object Storage (ex. Blob, S3)
  • 하이브리드 + 고가용성 → Distributed Storage (ex. Ceph with Rook)
  • 테스트/개발용 임시 디스크 → Local Storage

✅ TA 실무에서의 주요 고려 포인트

항목고려사항
고가용성 Zone/Region 중복 저장, Reclaim Policy
성능 Premium vs Standard, IOPS 측정
보안 Private Endpoint, Access Key, Encryption
자동화 CSI, PVC, VolumeSnapshot, Helm 연동
장애 대응 Pod 재스케줄 시 Volume 재마운트 처리 여부

아래는 Kubernetes + Azure 기반 스토리지 실전 시나리오형 문제 10문항과 장애 대응 중심의 분석 포인트입니다.
TA 실무역량 평가 관점에서 문제-정답-해설 3단 구성으로 제공하며, 실제 Azure 환경과 Kubernetes 연계 사례를 기반으로 제작했습니다.

📘 [Kubernetes + Azure Storage 실무 시나리오 기반 문제 10선]

✅ 문항 1

고객사는 Azure AKS 기반으로 웹 서비스를 운영하고 있으며, 웹 로그 데이터를 공유 스토리지에 저장하도록 구성했다. 최근 로그 데이터가 일부 누락되는 현상이 발생하고 있다. 이 경우 점검할 항목으로 적절하지 않은 것은?

① Azure Files의 RWX 사용 여부
② StorageClass의 mountOptions 설정
③ volumeMount 경로 누락 여부
④ Pod 간 affinity/anti-affinity 설정
⑤ Azure Storage Account의 Premium 설정 여부

정답: ⑤
해설: 로그 누락과는 성능보다 공유 접근(RWX) 및 mount 경로 충돌이 주요 원인일 수 있음. Premium 설정 여부는 성능과는 관련 있지만 직접적인 누락 원인은 아님.

✅ 문항 2

Azure Disk 기반 PVC를 사용하는 앱에서 노드 재시작 후 디스크 마운트가 실패하고 있다. 이 문제의 가능한 주요 원인은?

① ReadOnly 마운트 옵션이 설정됨
② Disk가 다중 Zone에 걸쳐 할당됨
③ VolumeSnapshot이 활성화 상태임
④ Disk와 Pod가 서로 다른 Zone에 존재
⑤ PVC의 accessMode가 RWX임

정답: ④
해설: Azure Disk는 Zone 단위 리소스로, Pod가 다른 Zone으로 스케줄링되면 attach/mount 실패 발생 가능.

✅ 문항 3

AKS 클러스터에 StatefulSet으로 배포된 Redis가 여러 번 재시작되며, 데이터가 유실되는 문제가 발생했다. 가장 가능성 높은 원인은?

① PVC의 reclaimPolicy가 Retain
② volumeMount 설정 누락
③ VolumeSnapshot 정책 없음
④ Pod 재시작 시 PVC가 삭제됨
⑤ Service가 headless로 구성되어 있음

정답: ④
해설: StatefulSet에서 PVC에 volumeClaimTemplates가 없거나 삭제 후 recreate 시 PVC가 제거될 수 있음. 이로 인한 데이터 유실 가능.

✅ 문항 4

AKS에 배포된 컨테이너가 mount failed 에러와 함께 시작하지 못하고 있다. CSI 로그를 확인한 결과, "disk not found" 오류가 발생했다. 가장 가능성 높은 원인은?

① volumeMode가 Block으로 설정됨
② reclaimPolicy가 Retain임
③ StorageClass가 존재하지 않음
④ 사용된 Disk가 삭제됨
⑤ podAffinity 설정이 없음

정답: ④
해설: CSI 로그에 디스크 미존재 오류가 발생한 경우, Azure Disk가 삭제되었거나 연결 실패한 상태일 가능성 높음.

✅ 문항 5

AKS 환경에서 Azure Files를 사용하는 공유 PVC를 구성하고자 한다. 필수 조건이 아닌 것은?

① accessMode: ReadWriteMany
② provisioner: file.csi.azure.com
③ mountOptions: [nobrl]
④ Storage Account Tier: Premium
⑤ VolumeBindingMode: Immediate

정답: ④
해설: Azure Files는 Standard Tier에서도 RWX 지원 가능하며, Premium은 필수는 아님. RWX 구조가 핵심.

✅ 문항 6

운영 중인 AKS에서 백업 솔루션과 연동하여, Redis PVC에 대해 주기적으로 스냅샷을 생성하고 복구 가능하게 구성하고자 한다. 올바른 절차 흐름은?

① PVC 생성 → VolumeSnapshotClass 생성 → VolumeSnapshot 생성
② PV 생성 → PVC 바인딩 → pod 실행
③ Deployment 생성 → VolumeMount 설정 → pod 실행
④ Azure Blob Storage 생성 → ConfigMap에 mount
⑤ Pod에 직접 디스크 mount → VolumeSnapshot 생성

정답: ①
해설: Kubernetes CSI 기반 스냅샷은 VolumeSnapshotClass → VolumeSnapshot → PVC 연결의 흐름을 따름.

✅ 문항 7

Azure Files로 구성된 PVC를 사용하는 Pod가 정상 실행되었으나, 파일시스템 내에서 파일 접근 시 I/O 에러가 간헐적으로 발생한다. 해결책으로 적절한 것은?

① Azure Disk로 변경
② mountOptions: [“nobrl”] 설정
③ reclaimPolicy를 Retain으로 변경
④ VolumeSnapshot 사용
⑤ accessMode를 ReadOnly로 변경

정답: ②
해설: nobrl 옵션은 Azure Files에서 파일 잠금 관련 I/O 에러를 방지하는 대표적 설정임.

✅ 문항 8

Azure Kubernetes 환경에서 오브젝트 스토리지(Azure Blob)를 Pod에서 직접 Mount 형태로 사용하려 한다. 다음 중 적절한 설계 방식은?

① CSI volume으로 Blob 컨테이너 직접 마운트
② Azure Files로 Blob 연결
③ Azure Disk를 Blob에 연결
④ BlobFuse2 CSI 드라이버 사용
⑤ Blob을 Pod의 EmptyDir로 Sync

정답: ④
해설: Azure Blob은 기본적으로 Mount 방식이 아닌 REST API 기반 접근이며, BlobFuse2 CSI 드라이버를 통해 Mount가 가능.

✅ 문항 9

스토리지에 민감한 워크로드가 포함된 AKS 환경에서 모든 볼륨의 스냅샷 및 복구를 자동화하려 한다. 고려해야 할 Kubernetes 리소스는?

① CronJob
② VolumeSnapshot & VolumeSnapshotClass
③ StatefulSet
④ Toleration
⑤ ConfigMap

정답: ②
해설: CSI 기반 VolumeSnapshot 리소스를 통해, 특정 주기로 스냅샷을 생성하고 필요 시 복구 가능.

✅ 문항 10

운영 중인 AKS 클러스터에서, 디스크 사용률이 급격히 증가하며 Pod의 I/O 지연 현상이 발생한다. 적절한 대응 방안은?

① 디스크 크기 확장
② StorageClass 변경
③ accessMode를 ReadOnly로 전환
④ volumeMode를 Block으로 변경
⑤ Pod 수 축소

정답: ①
해설: Azure Disk의 경우 디스크 크기에 따라 IOPS와 Throughput도 자동 증가하므로, 성능 확보를 위해 디스크 확장이 필요.

🔎 Kubernetes + Azure Storage 실무 대응 포인트 요약

항목핵심 고려사항
고가용성 Disk Zone → Node Zone 매칭, CSI 자동 failover
스냅샷 VolumeSnapshot 활용, 백업 정책 자동화
성능 디스크 SKU, 크기 확장 → 성능 향상
공유 저장소 Azure Files(RWX) + nobrl, 또는 BlobFuse2
마운트 이슈 CSI 로그 확인, PVC 상태 확인
삭제 이슈 reclaimPolicy 및 volumeBindingMode 확인

 

아래는 Kubernetes + Azure Storage 환경에서 사용되는 주요 개념과 실무 대응 요소를 요약한 **암기카드(Flashcards)**와 블로그/오픈북용 키워드 인덱스 정리본입니다.
TA 시험 대비 및 실무 대응 학습용으로 활용할 수 있도록 구성했습니다.

🧠 Kubernetes + Azure Storage 암기카드

번호키워드개념 요약
01 PVC (PersistentVolumeClaim) Pod가 요청하는 스토리지의 사양/용량을 정의하는 객체
02 PV (PersistentVolume) 클러스터에서 관리하는 실제 스토리지 리소스
03 StorageClass 스토리지 프로비저닝 및 파라미터를 정의하는 객체
04 accessMode ReadWriteOnce, ReadOnlyMany, ReadWriteMany
05 reclaimPolicy Delete, Retain, Recycle – 볼륨 삭제 정책
06 Azure Disk 단일 Pod용 고성능 블록 스토리지, Zonal 리소스
07 Azure Files RWX 공유 가능한 파일 스토리지
08 VolumeSnapshot CSI 기반 볼륨 스냅샷 기능, 백업/복구에 활용
09 VolumeSnapshotClass 스냅샷 방식 및 CSI 드라이버 정의
10 CSI 드라이버 컨테이너 볼륨 연동을 위한 인터페이스 표준
11 BlobFuse2 Azure Blob Storage를 마운트 가능한 드라이버
12 mountOptions nobrl, dir_mode, file_mode 등 파일시스템 옵션
13 VolumeBindingMode Immediate, WaitForFirstConsumer – 스케줄링 정책
14 StatefulSet 각 Pod에 고유한 스토리지를 할당하는 컨트롤러
15 Azure Monitor 스토리지 IOPS, 처리량, 사용률 모니터링
16 스토리지 장애 대응 Zone 일치, CSI 로그 확인, accessMode/RWX 검토
17 Disk 확장 Azure Disk 확장은 IOPS/Throughput도 향상
18 Retain 정책 삭제된 PVC/PV의 데이터 보존 가능성 있음
19 VNet 연결 App에서 Storage 접근 시 VNet 통합 고려
20 KEDA + PVC Azure Functions나 Event 기반 워크로드와 연계 가능

🔍 Kubernetes + Azure Storage 키워드 인덱스 (오픈북 검색용)

[Ctrl + F]로 빠르게 검색할 수 있도록 주요 키워드 정리

 
StorageClass 정의 PVC와 PV 차이 accessMode 종류 reclaimPolicy 유형 Azure Disk 특성 Azure Files 특징 RWX 설정 VolumeSnapshot 사용법 VolumeSnapshotClass 정의 StatefulSet 스토리지 연동 CSI 마운트 오류 해결 BlobFuse2 마운트 구성 AKS Volume 확장 스토리지 성능 모니터링 nobrl mount option Zone mismatch 대응 Immediate vs WaitForFirstConsumer 스냅샷 자동화 구성 Pod 재시작 시 PVC 유지 AKS 장애 시 디스크 이슈 분석

 

Azure 기반 랜딩존(Landing Zone) 구성 및 시스템 이관(On-Prem → Cloud) 시에는 백업(Backup) 및 복구(Recovery) 전략이 매우 중요합니다.
아래에 TA 시험 및 실무 설계 기준으로 알아야 할 핵심 내용을 요약해드립니다.

📌 1. 랜딩존 환경에서 Backup & Recovery의 중요성

🔹 랜딩존이란?

  • 기업이 Azure로 클라우드 환경을 확장하거나 마이그레이션하기 위한 표준 아키텍처 템플릿
  • 보안, 거버넌스, 네트워크, 리소스 그룹, 정책, 모니터링, 백업 등 기반 구성요소 포함

🔹 Backup & Recovery의 역할

  • 이관 시점: 데이터 이전 중 오류, 재시도 가능성에 대비
  • 운영 시점: SLA 보장, 장애 대응, 데이터 무결성 확보
  • DR 구성: 멀티 리전 복제 또는 스냅샷을 통한 빠른 서비스 복구

📌 2. 주요 백업 시나리오

시나리오설명
시스템 전체 이관 온프레미스 VM → Azure VM으로 이관 시, Recovery Services Vault 이용하여 이전 상태 스냅샷 보관
DB 이관 SQL, Oracle, Altibase 등의 DB는 백업 파일 + Point-In-Time 복구 기능 고려
Kubernetes 마이그레이션 PVC/VolumeSnapshot 활용 + Velero 같은 오픈소스 툴로 전체 상태 백업
파일 공유 Azure Files는 Geo-redundant 저장소(GRS) 설정 + 정기 스냅샷 구성
Blob 백업 Blob Lifecycle Policy, Soft Delete, Immutable Blob 등으로 백업 보존 가능

📌 3. Azure 백업 구성 요소

✅ Azure Backup

  • PaaS 형태의 백업 관리 서비스
  • VM, 파일, SQL DB, SAP HANA, Azure Blobs 등 지원
  • Recovery Services Vault에 모든 백업 메타데이터 저장

✅ Azure Site Recovery (ASR)

  • 장애 대비 목적의 DR 구성 서비스
  • Region 간 VM 복제 및 Failover/Failback 기능
  • 랜딩존 구성에서 DR Zone 연계에 활용

✅ VolumeSnapshot (Kubernetes)

  • CSI 기반 볼륨 스냅샷 기능
  • VolumeSnapshotClass 정의 → VolumeSnapshot 리소스로 백업/복구 가능

✅ Azure Blob Backup

  • Soft Delete / Versioning / Immutable Blob
  • Vault와 연동한 장기 보존도 가능

📌 4. 설계 시 고려사항

고려 요소설명
RTO (Recovery Time Objective) 장애 발생 후 복구 소요 시간 목표 (Ex: 30분 이내)
RPO (Recovery Point Objective) 데이터 손실 허용 범위, 마지막 백업 시점 기준 (Ex: 5분 이내)
백업 빈도 OS별, DB별, 워크로드별 일/시간 단위 자동화
암호화 및 보안 저장소 암호화, 백업 전송 중 암호화, Key Vault 통합
접근 제어 백업/복구 수행 권한은 RBAC + Conditional Access + Locking 사용
보존 주기 단기(730일), 중기(36개월), 장기(7년 이상) 정책 구분 설정
리전 고려 주 리전 장애를 대비한 Geo-Replication, ZRS 또는 GRS 구성

📘 예시 아키텍처 (랜딩존 + 백업 통합)

 
[On-Prem Server] │ │ 백업 → Azure Blob or Recovery Vault ↓ [Azure Landing Zone 구성] ├── Hub Network + Bastion + Firewall ├── Workload Subnet (AKS, VM, DB) ├── Recovery Services Vault (Backup & Snapshot 저장소) └── Site Recovery for DR (Cross-Region Replication)

✅ 실전 TIP (TA 시험/설계 관점)

  • RPO/RTO 값과 워크로드 중요도 매핑할 것
  • VM은 Azure Backup + Azure Site Recovery 동시 구성 가능
  • 스토리지 클래스에 따라 스냅샷 지원 여부 다름 (Premium = 지원, 일부 Standard는 불가)
  • Blob은 Immutable Policy 설정을 통한 랜섬웨어 대응 가능
  • Recovery Vault는 30개 제한 있으므로 리소스 그룹별 적절한 분배 필요

 

📘 RPO/RTO 설계 기반 문제집 (정답+해설 포함)

✅ 문항 1

Azure에서 VM 백업 구성 시, RPO가 1시간이면 어떤 조건을 충족해야 하는가?
A. 백업은 하루 1회 이상 수행하면 충분하다
B. 장애 발생 시 1시간 이내 서비스가 복구되어야 한다
C. 마지막 백업 시점 기준으로 1시간 이내의 데이터만 손실 가능하다
D. Recovery Services Vault는 GRS로 구성되어야 한다
E. VM 재부팅 없이 백업 수행이 가능해야 한다

정답: C
해설:
RPO는 데이터 손실 허용 범위로, “마지막 백업 시점부터 현재까지의 데이터 중 몇 시간분을 잃어도 되는가”를 의미한다.

✅ 문항 2

업무 중요도가 높은 DB 서버의 RTO를 10분으로 설정한 경우, 백업 구성 외에 필수 고려사항은?
A. 백업 데이터의 장기보존 정책
B. 백업 대상 리소스를 GRS로 설정
C. DR 리전에 미리 Standby VM을 띄워둠
D. Soft Delete 활성화
E. 스냅샷 주기를 주 1회로 설정

정답: C
해설:
RTO는 장애 발생 후 서비스 재개까지 소요되는 시간이다. 10분 이내 복구가 필요하다면 미리 DR 환경을 준비해 두는 것이 필수다.

✅ 문항 3

RPO 5분, RTO 30분인 ERP 시스템에 가장 적합한 백업 전략은?
A. 일 1회 백업 + Cold Standby 구성
B. 5분 주기 트랜잭션 로그 백업 + ASR로 Warm Standby
C. 하루 3회 백업 + Blob Lifecycle 관리
D. Storage Snapshot 매일 1회 + Retain 정책
E. VM Level Image Backup 주 1회

정답: B
해설:
5분 이내 데이터 손실(RPO) + 30분 내 서비스 재가동(RTO)을 보장하려면 트랜잭션 백업과 Warm Standby 조합이 적절하다.

✅ 문항 4

On-Prem에서 Azure로 시스템을 마이그레이션하는 경우, 이관 중 백업 전략으로 적절한 것은?
A. 대상 VM만 백업하면 충분하다
B. 이관 후 백업 구성이 필요하므로 미리 구성하지 않아도 된다
C. Recovery Vault를 활용해 이전 VM 상태 백업 유지
D. Blob Storage에 백업된 상태이면 추가 백업은 필요 없다
E. 백업은 오직 시스템 종료 후 수행해야 한다

정답: C
해설:
마이그레이션 중 장애/롤백에 대비해 원본(On-Prem) 및 Azure 대상 VM 모두 백업해 두는 것이 중요하다.

✅ 문항 5

Azure Kubernetes 환경에서 StatefulSet의 PV가 손상되었을 때, RPO 최소화를 위한 조치는?
A. emptyDir로 임시 저장소 활용
B. VolumeSnapshot을 주기적으로 생성
C. StorageClass를 Delete 정책으로 설정
D. mount 옵션을 제거
E. CSI Controller 로그만 모니터링

정답: B
해설:
RPO를 줄이려면 주기적인 Snapshot으로 최신 데이터를 보존해야 한다.

✅ 문항 6 (시나리오형)

회사는 SLA 99.9%를 요구하는 고객 서비스를 Azure에 배포 중이다. RTO는 15분, RPO는 10분이다.
이 요건을 충족하기 위해 구성할 수 있는 백업 전략으로 적절한 것은?
A. Recovery Vault만 구성
B. GRS 설정된 Blob 백업만 구성
C. ASR로 DR 구축 + 10분 주기 백업
D. 스냅샷 주 1회 + Soft Delete 설정
E. RTO가 짧기 때문에 백업은 불필요

정답: C
해설:
재해 대비 시나리오에선 RTO를 위한 Standby 및 ASR, RPO를 위한 빈번한 백업이 모두 필요하다.

✅ 문항 7

다음 중 RTO와 RPO의 정의로 올바른 것은?
A. RTO는 백업이 수행되는 최대 간격이다
B. RPO는 서비스를 재시작할 수 있는 최소 시간이다
C. RTO는 시스템 복구까지 걸리는 시간이다
D. RPO는 서비스 SLA 가용성 기준이다
E. 둘 다 백업 보존 주기를 의미한다

정답: C
해설:
RTO는 서비스가 복구되기까지 걸리는 총 소요 시간을 의미한다. (RPO는 데이터 손실 허용 범위)

✅ 문항 8

RTO는 짧고 RPO는 길게 설정할 수 있는 예시는?
A. 금융거래 시스템
B. 회계 결산 시스템
C. 정기 리포트 생성 시스템
D. 실시간 API Gateway
E. IoT 센서 데이터 수집 플랫폼

정답: B
해설:
복구는 빠르게 되어야 하지만, 데이터가 일정 주기로 생성되는 시스템은 RPO를 길게 설정 가능하다.

✅ 문항 9

Azure에서 Recovery Services Vault를 사용할 때 고려할 사항으로 틀린 것은?
A. 지역별로 Vault는 30개까지만 생성 가능
B. 보존 주기와 암호화는 정책에 따라 설정 가능
C. Vault는 GRS가 기본 구성이다
D. 동일한 Vault에서 VM과 Blob을 동시에 백업할 수 있다
E. Vault는 Key Vault와 연동해 보안 강화 가능

정답: D
해설:
Vault는 VM 백업에 주로 사용되며, Blob Storage 백업은 별도의 방식으로 구성된다.

✅ 문항 10 (시나리오형)

AKS 기반 서비스에서 CSI 기반 PV에 문제가 발생해 복구 시 스냅샷이 존재하지 않았다. 이 문제로부터 얻는 교훈은?
A. Kubernetes는 기본적으로 백업을 보장한다
B. CSI Volume은 자동으로 백업되므로 설정 불필요하다
C. StorageClass에 Retain 설정이 필수다
D. RPO 보장을 위해 Snapshot 정책을 명시적으로 구성해야 한다
E. 볼륨 손실 시 복구가 불가능하므로 이중화는 필요 없다

정답: D
해설:
Kubernetes 환경에서는 수동 혹은 자동 스냅샷 설정 없이는 RPO를 보장할 수 없다.

📌 다음 추천

  • 📄 Word / PDF 다운로드용 문제집
  • 💡 암기카드 요약본 (RPO/RTO 핵심 포인트)
  • 🧪 실습 시나리오 (ASR 구성 / Snapshot 생성 / 복구 테스트)
  • 📘 문제 난이도별 분류 및 실전 CBT 모의시험 버전

요청 시 확장해드릴 수 있습니다. 어떤 형식이 더 필요하신가요? (예: 문서 다운로드, 정답 숨김용, YAML 샘플 등)

나의 말:

Azure Backup 서비스별 지원 Matrix 정리표

ChatGPT의 말:

Azure Backup 서비스는 다양한 리소스 유형에 따라 지원 범위가 다릅니다. 아래에 서비스별 지원 Matrix를 정리해 드립니다. TA 시험 및 실무 설계에 바로 활용할 수 있도록 리소스 유형, 지원 항목, 제한사항을 기준으로 구성하였습니다.

📘 Azure Backup 서비스별 지원 Matrix (정리표)

리소스 유형백업 가능 여부복구 가능 여부백업 방식주요 제한사항
Azure VM (IaaS) ✅ 지원 ✅ 지원 이미지 기반 (Snapshot + Vault) 최대 1일 3회 제한
ASR과 병행 가능
Azure File Share ✅ 지원 ✅ 지원 Snapshot 기반 Soft Delete 사용 권장
GRS 필수 아님
SQL Server (on Azure VM) ✅ 지원 ✅ 지원 애플리케이션 수준 백업 SQL 인증 필요
System databases 백업 불가
SAP HANA (on Azure VM) ✅ 지원 ✅ 지원 인앱 백업 에이전트 방식 SUSE/RedHat VM에서만 지원
Azure Blobs ❌ 직접 백업 불가 ❌ 직접 복구 불가 Lifecycle, Soft Delete, Versioning 활용 별도 Vault 백업 없음
Azure Managed Disks ❌ 직접 백업 불가 ❌ 직접 복구 불가 Snapshot 별도 구성 Snapshot은 자동 보존 아님
Azure Kubernetes (AKS) ❌ 직접 미지원 ❌ 직접 미지원 VolumeSnapshot 사용 (CSI 필요) Velero 등 외부 도구 필요
Azure Database for PostgreSQL / MySQL ✅ 자동 지원 ✅ 자동 지원 내부 스케줄링 백업 보존 주기 변경 불가
Azure Database for SQL (PaaS) ✅ 자동 지원 ✅ 자동 지원 PITR (Point-In-Time Restore) 최대 35일까지 보존
On-Prem 서버 ✅ 지원 ✅ 지원 MARS 에이전트 or DPM 이용 공용 IP 또는 VPN 필요

🔍 백업 유형 정리

백업 방식적용 서비스특징
Vault 기반 백업 Azure VM, File Share, SQL on VM 등 Recovery Services Vault에 메타데이터 저장
Application-aware Backup SQL, SAP HANA 트랜잭션 일관성 보장
Snapshot 기반 File Share, Managed Disk, AKS Volume 빠른 복원, 일정 기간 보존
PaaS 내장 백업 Azure SQL DB, PostgreSQL 자동 백업 주기, 별도 구성 불필요
MARS Agent On-Prem 서버 에이전트 기반 백업, Vault 연동

⚠️ 실무/설계 시 고려사항

  • Vault당 백업 항목 수 제한: Azure에서는 리소스/리전별 제한이 존재하므로 설계 시 고려해야 함
  • Snapshot 기반 백업은 장기보존 비적합
  • AKS 백업은 기본 미지원 → Velero, Kasten, Trilio 같은 서드파티 솔루션 사용
  • Blob은 백업 대신 Soft Delete + Immutable Storage로 보호
  • ASR과 Azure Backup은 동시 적용 가능 (예: VM 단위 DR 및 백업 분리)

🧩 보완 자료 요청 가능

  • 📄 PDF 또는 Word 문서로 출력용 표 제공
  • 🧪 서비스별 실습 예시 (Vault 설정, SQL 백업 구성, Velero AKS 백업 등)
  • 📝 문제집 (Matrix 기반 문항 10제)
  • 📘 암기카드 요약본

원하시는 형식이 있다면 말씀 주세요. 필요한 문제 구성 또는 YAML 예시도 함께 드릴 수 있습니다.

나의 말:

문제집 (Matrix 기반 문항 10제)

ChatGPT의 말:

다음은 **Azure Backup 서비스 지원 Matrix 기반 TA 문제집 (10문항)**입니다.
모든 문항은 정답 + 해설과 함께 제공되며, TA 역량시험에서 자주 나올 수 있는 형태로 구성했습니다.

📘 Azure Backup Matrix 기반 문제집 (10문항)

✅ 문항 1

Azure IaaS VM에 대한 백업 방식으로 적절한 것은?
A. Blob Storage Versioning
B. Azure Snapshot API
C. Recovery Services Vault 기반 이미지 백업
D. Azure SQL 자동 백업 기능
E. MARS Agent 직접 연결

정답: C
해설:
Azure VM은 Vault를 통해 이미지 기반 백업이 가능하며, VM 구성 정보와 데이터까지 포함함.

✅ 문항 2

Azure Blob Storage는 어떤 방식으로 백업/보호되는가?
A. Recovery Vault
B. File Sync
C. Soft Delete 및 Immutable 설정
D. Azure Files 기반 자동 백업
E. Azure Backup Center

정답: C
해설:
Blob은 직접적인 백업 기능이 없어 Soft Delete, Versioning, Immutable Storage로 보호한다.

✅ 문항 3

Azure Files 백업 구성 시 Vault 사용 여부는?
A. 사용할 수 없다
B. 사용은 가능하지만 권장되지 않는다
C. Snapshot 기반으로 Vault에 저장된다
D. Snapshot은 자동 보존되지 않는다
E. 백업 불가능한 리소스이다

정답: C
해설:
Azure Files는 Vault와 연동되며 Snapshot 기반 백업이 가능하다.

✅ 문항 4

On-Premise 서버를 Azure Backup으로 보호하기 위한 필수 구성은?
A. Azure VPN Gateway
B. Azure NetApp Files
C. MARS Agent 설치
D. AKS CSI Driver
E. Key Vault 백업 연동

정답: C
해설:
MARS Agent를 통해 Azure Vault와 연결되어 백업이 가능하다.

✅ 문항 5

AKS 클러스터의 Persistent Volume에 대한 백업 구성으로 옳은 것은?
A. Azure File Sync 자동 백업
B. Azure Vault에서 자동 스냅샷 생성
C. CSI 기반 VolumeSnapshot 수동 구성
D. MARS Agent를 활용한 자동 백업
E. Azure Blob Lifecycle 활용

정답: C
해설:
AKS는 기본 백업이 없으며, CSI 기반 Snapshot을 사용하여 PV 단위 백업을 구성해야 한다.

✅ 문항 6

다음 중 Azure VM 백업의 주요 제한사항으로 옳은 것은?
A. 백업 주기 1시간마다 설정 가능
B. 스냅샷은 최대 7일만 보존 가능
C. Recovery Vault당 100개의 VM만 가능
D. 하루 최대 3회 백업 지원
E. Vault는 GRS 필수

정답: D
해설:
Azure VM은 하루 최대 3회 백업이 가능하며, 더 빈번한 백업은 별도 구성 필요.

✅ 문항 7

Azure SQL PaaS의 백업 정책으로 올바른 설명은?
A. 수동 스냅샷 구성 필요
B. Azure Backup Vault로 구성
C. 기본 7일, 최대 35일 PITR 가능
D. Blob Versioning으로 구성
E. Azure Files와 동일한 정책 적용

정답: C
해설:
Azure SQL은 내장 자동 백업이 존재하며, 최대 35일까지 Point-In-Time Restore를 지원한다.

✅ 문항 8

Azure File Share 백업 시 Soft Delete가 중요한 이유는?
A. 지역간 복제를 위해
B. 백업 보존 비용 절감을 위해
C. Vault 연결이 불가능하므로 대안 필요
D. 사용자 삭제에 대한 복구를 지원
E. 고정된 백업 주기 때문

정답: D
해설:
Soft Delete는 실수로 삭제된 파일을 복구할 수 있는 기능이다.

✅ 문항 9

다음 중 Vault 기반 백업이 아닌 것은?
A. Azure VM
B. Azure File Share
C. SQL Server on Azure VM
D. Blob Storage
E. On-Prem 서버 (MARS Agent)

정답: D
해설:
Blob은 Vault 기반 백업을 직접 지원하지 않음.

✅ 문항 10

Azure에서 SAP HANA 백업을 구성할 때 필요한 전제조건은?
A. Azure NetApp Files 연동
B. 전용 SAP Vault 구성
C. SUSE/RedHat OS 기반의 VM
D. MARS Agent 설치
E. Azure CLI 전용 스크립트 사용

정답: C
해설:
SAP HANA 백업은 SUSE 또는 RedHat 기반 Azure VM에서만 지원된다.

📘 다음 확장 가능 항목

  • 📄 Word/PDF 변환
  • 🎯 난이도 표시 (상/중/하)
  • ✅ 정답 숨김용 연습 버전
  • 💡 실전 CBT용 랜덤 셔플 문제집
  • 🗂️ 암기카드 요약본

요청 주시면 바로 제작해드리겠습니다. 어떤 형식으로 저장해드릴까요?

나의 말:

MARS Agent에 대해 간략히 설명해줘

ChatGPT의 말:

Azure에서 사용하는 **MARS Agent (Microsoft Azure Recovery Services Agent)**는 온프레미스 환경의 서버나 클라이언트를 Azure에 백업하기 위해 설치하는 에이전트 프로그램입니다. 주로 Vault 기반 백업이 직접 지원되지 않는 물리/가상 서버에 사용됩니다.

🧩 MARS Agent 핵심 정리

1. ✅ 주요 역할

  • 온프레미스 시스템 → Azure Vault로 백업
  • 파일/폴더 단위 백업 가능 (디스크 전체 이미지 백업은 불가)
  • Azure Portal을 통해 스케줄 설정, 보존 기간, 암호화 등 관리 가능

2. 🖥️ 적용 대상

적용 가능 대상예시
물리 서버 Windows Server 2012, 2016, 2019 등
가상 서버 Hyper-V, VMware 등
클라이언트 PC Windows 10/11 Pro 등 (보안 백업 목적)

3. ⚙️ 기능 요약

항목내용
백업 범위 파일/폴더 단위
백업 대상 온프레미스 서버/PC
연결 방식 인터넷 통신 (공용망 또는 VPN)
암호화 백업 전 암호화, 키는 로컬에서만 보관
보존 기간 최대 99년 설정 가능
복원 기능 포털 또는 에이전트에서 직접 복원 가능

4. ❗ 제약사항

  • VM 단위 전체 백업은 Azure Backup Vault + VM Extension 필요
  • Linux는 미지원, Windows 기반 서버/클라이언트만 지원
  • DB, 앱 인식 백업 불가 (SQL 등은 별도 Azure Backup Agent 필요)
  • 인터넷 연결 필요 (프록시 설정 가능)

🧠 요약 암기 문장 (TA용)

“MARS Agent는 온프레미스 서버/PC의 파일 단위 백업을 Azure Vault로 수행하는 Windows 전용 에이전트로, 복구 지점 기반 복구 및 강력한 암호화를 지원하지만 전체 VM 백업이나 DB 백업은 지원하지 않는다.”

필요하다면 다음도 도와드릴 수 있어요:

  • ✅ MARS Agent 설치 및 Vault 등록 절차 (화면 캡처 포함)
  • 📄 Word 문서/PDF 출력용 구성
  • 🧪 관련 실전 문제 (예: VPN 경로 차단, 에이전트 복구 실패 등)

진행할까요?

나의 말:

이제 암기카드 요약본 부탁해

ChatGPT의 말:

다음은 Azure Backup + MARS Agent + RPO/RTO 등 백업 및 복구 관련 암기카드 요약본입니다.
TA 오픈북 시험 대비용으로 간결한 한 줄 키워드 요약 + Ctrl+F용 키워드 인덱스 구성입니다.

📘 암기카드 요약본 (한 줄 키워드 위주)

키워드설명 요약
Recovery Services Vault Azure VM/File/SQL 등의 백업 메타데이터 저장소
MARS Agent 온프레미스 Windows 서버/PC → Azure Vault 백업용 에이전트
Vault 기반 백업 Azure VM, SQL on VM, File Share 등 지원, 하루 최대 3회
Soft Delete (Blob) 삭제 방지 기능, Blob은 백업 직접 미지원
Snapshot 기반 백업 AKS PV, File Share 등에 적용, 빠른 복구
Azure SQL 백업 자동 PITR, 최대 35일, Vault 불필요
AKS 백업 CSI Snapshot 사용, Velero 등 서드파티 도구 필요
On-Prem 백업 구성요소 MARS Agent, 인터넷 통신 또는 VPN 필요
SAP HANA 백업 SUSE/RedHat VM에서만 지원, 애플리케이션 인식 백업
Backup Center 백업 정책 및 상태 통합 관리 포털
RPO 데이터 손실 허용 한계 시간, 백업 주기 기준
RTO 복구 완료까지의 최대 시간 허용 범위
Blob Versioning 데이터 보호용, 백업 대체 X
Immutable Blob 변경 불가능한 상태로 보존, 보안 강화
SQL on Azure VM Vault 기반 애플리케이션 백업 필요, SQL 인증 사용
파일 단위 복원 MARS Agent로 개별 파일 복원 가능
DPM / MABS 온프레미스 백업 솔루션, Vault 연동 가능
보존 기간 정책 최대 99년(MARS 기준), Vault 기반 설정
백업 암호화 키 로컬 생성, Azure에 저장되지 않음

🔍 Ctrl+F 검색용 키워드 인덱스

 
Recovery Services Vault, MARS Agent, Azure Backup, Soft Delete, Blob 백업, Snapshot Backup, Azure SQL 백업, AKS 백업, CSI Snapshot, Velero, On-Prem 백업 구성, SAP HANA Backup, Backup Center, RPO, RTO, Immutable Blob, Versioning, SQL 인증 백업, 파일 복원, 보존 정책, 암호화 키

📎 활용 팁

  • TA 시험 중 Backup 구성 설명, DR 설계, 이중화 요소, Vault 보존 정책, AKS Snapshot 구성 등이 키워드로 출제될 수 있습니다.
  • 블로그나 문서에 붙여넣고 Ctrl+F로 “Vault”, “MARS”, “Snapshot” 등의 키워드를 검색해서 빠르게 찾도록 설계되었습니다.

필요 시 아래도 추가 가능:

  • 📝 “Backup 설계 문제집 + 장애 대응 시나리오 문제 10제”
  • 📄 이 카드 내용을 PDF/Word로 변환
  • 📊 서비스별 백업 복구 Flow 도식화

원하시는 방식 알려주시면 바로 제작 도와드릴게요!

나의 말:

장애 대응 시나리오 문제 10제

ChatGPT의 말:

다음은 Backup & Recovery 장애 대응 시나리오 기반 문제 10문항입니다.
모든 문항은 실무 환경에서 발생 가능한 장애, 설정 실수, 복구 지연, RPO/RTO 충돌, 설계 미비점 등을 반영한 TA 직무역량 평가 수준으로 구성되어 있습니다.

📘 장애 대응 시나리오 기반 문제집 (10문항)

✅ 문제 1.

문제: Azure VM 백업을 Recovery Services Vault로 구성했으나, 최근 2일간 백업이 실패하고 있다. 백업 정책은 정상이며, 에이전트 오류는 없다. 가장 먼저 확인해야 할 항목은?

A. NSG 인바운드 포트 설정
B. 백업 Vault의 보존 정책
C. 스토리지 계정 접근 키
D. Managed Identity 권한
E. VM 이름 변경 여부

정답: D
해설:
백업 작업은 Managed Identity를 통해 Vault에 접근하므로, 권한 변경 시 백업 실패 가능.

✅ 문제 2.

문제: AKS 클러스터의 PVC를 백업 중 장애가 발생했다. CSI VolumeSnapshot은 생성되었지만 스냅샷 복원이 실패하고 있다. 가능한 원인은?

A. StorageClass의 reclaimPolicy가 Delete로 설정됨
B. PV가 ReadOnlyMany 타입
C. SnapshotController 미설치
D. PVC Label 누락
E. CSI Driver 업데이트 누락

정답: C
해설:
VolumeSnapshot 기능은 SnapshotController가 클러스터 내에 설치되어야 작동한다.

✅ 문제 3.

문제: 온프레미스 파일 서버에 MARS Agent를 설치해 Vault 백업을 구성했으나, 특정 폴더가 백업되지 않는다. 가장 가능성 높은 원인은?

A. NTFS 파일 권한 오류
B. Azure VPN 게이트웨이 오류
C. 스케줄 충돌
D. 백업 Vault가 GRS로 설정됨
E. 백업 로그가 삭제됨

정답: A
해설:
Agent는 로컬 시스템 권한으로 접근하며, 권한 없는 파일은 건너뛴다.

✅ 문제 4.

문제: RTO 30분, RPO 5분인 업무 시스템에 Azure Backup을 구성했으나, 실 장애 시 복구까지 2시간이 소요되었다. 가장 적절한 조치는?

A. Azure File Sync로 보완
B. 백업 보존 기간 확대
C. Snapshot 주기 단축
D. BCDR 시나리오 수정 및 DR Runbook 구성
E. Azure SQL Auto Backup 활성화

정답: D
해설:
복구 시간 초과는 BCDR 계획과 Runbook 설계가 부실하다는 의미. 설계 재검토가 필요.

✅ 문제 5.

문제: 백업 대상인 Azure File Share가 사용자가 실수로 삭제되었고 Soft Delete 기능이 비활성화 상태였다. 복구 가능한 방법은?

A. Vault 복원
B. Blob Lifecycle 정책 사용
C. Snapshot 복원
D. 복구 불가
E. Storage Account Rollback

정답: D
해설:
Soft Delete가 비활성화된 상태에서는 실수로 삭제된 데이터 복구가 불가능하다.

✅ 문제 6.

문제: Azure Backup Center에서 특정 VM의 복원 시, "Unregistered VM"이라는 오류 메시지가 발생한다. 이 때 가능한 조치는?

A. Vault 재등록
B. VM과 Vault의 지역 재설정
C. 백업 정책 재생성
D. PowerShell 기반 복구
E. Azure CLI로 복구 이력 조회

정답: D
해설:
삭제된 VM에 대해 복구 시, 포털이 인식 못하는 경우 PowerShell 기반 복구가 필요하다.

✅ 문제 7.

문제: SAP HANA가 설치된 Azure VM에서 백업이 지속 실패하고 있다. 가능한 원인은?

A. SUSE가 아닌 Windows 기반
B. Blob 접근 정책 미설정
C. Vault 보존 정책 설정 미흡
D. MARS Agent 설치 오류
E. Network Watcher 비활성화

정답: A
해설:
SAP HANA 백업은 RedHat/SUSE 기반의 VM에서만 지원된다. OS 호환 필수.

✅ 문제 8.

문제: AKS의 PVC 데이터를 복구하였으나, Pod가 PVC를 읽지 못하는 오류가 발생했다. 가장 가능성 높은 원인은?

A. StorageClass가 변경됨
B. PVC에 RWX 타입이 누락됨
C. Snapshot 복구 후 PVC 이름 충돌
D. CSI Plugin이 중복 설치됨
E. Pod의 ServiceAccount 권한 누락

정답: C
해설:
복구 후 PVC 이름이 기존과 충돌하거나 변경되면 Pod에서 자동 연결 실패가 발생할 수 있다.

✅ 문제 9.

문제: Azure Blob에 대한 백업 보호 정책을 구성하려고 한다. 가장 적절한 조합은?

A. Immutable + Snapshot
B. Vault + MARS Agent
C. Azure SQL 백업 적용
D. Soft Delete + MABS
E. NetApp Snapshot

정답: A
해설:
Blob은 Vault로 백업되지 않으므로 Immutable Blob과 Snapshot 설정이 일반적 보호 방식이다.

✅ 문제 10.

문제: 고객사 요구사항으로, RPO 10초, RTO 1분 수준의 백업 복구 구성을 요구하고 있다. Azure Backup의 한계로 적합하지 않은 경우 대안은?

A. Azure Site Recovery
B. Azure Backup Center
C. Soft Delete 주기 조정
D. Blob Versioning 주기 설정
E. Azure SQL LTR Backup

정답: A
해설:
초단위 복구는 Azure Site Recovery처럼 재해복구(DR) 설계 기반 서비스로 대응해야 한다.

필요 시 아래 추가 자료도 제공 가능합니다:

  • 📄 Word/PDF 버전
  • 📊 정답 숨김 연습용
  • 🧠 암기카드 요약
  • 🗂️ 서비스별 장애 대응 매트릭스 도식

원하시면 출력 형식 알려주세요!

나의 말:

암기카드 요약

ChatGPT의 말:

다음은 Backup & Recovery 장애 대응 시나리오 대비용 암기카드 요약본입니다.
TA 직무역량 시험 및 실무 오픈북 블로그용으로 구성하였습니다.

📘 암기카드 요약 (한 줄 핵심 위주)

키워드요약 설명
Managed Identity 권한 오류 백업 실패 시 가장 빈번한 원인, Vault 접근에 사용
SnapshotController 누락 AKS VolumeSnapshot 기능 오류 발생
NTFS 권한 문제 MARS Agent가 특정 폴더 건너뛰는 원인
RTO 초과 시 대응 DR Runbook 설계 및 BCDR 프로세스 보완 필요
Soft Delete 비활성화 Azure File 삭제 시 복구 불가 상태
PowerShell 복구 Unregistered VM 등 포털 복구 오류 시 대안
SAP HANA 백업 조건 RedHat/SUSE 기반 VM에서만 가능
PVC 이름 충돌 복구 후 Pod가 PVC 인식 실패할 수 있음
Blob 백업 방식 Vault 미지원, Snapshot + Immutable Blob으로 보호
초단위 RPO/RTO 대응 Azure Site Recovery 사용 (ASR) 필요

🧠 장애 대응 키워드 인덱스 (Ctrl+F 용)

 
Managed Identity, SnapshotController, NTFS 권한, RTO Runbook, Soft Delete, PowerShell 복구, SAP HANA Backup, PVC 충돌, Blob Snapshot, ASR

📎 활용 팁

  • 시험 시 "복구 실패", "Snapshot 실패", "Vault 복원 안됨" 등의 키워드가 나올 경우 상기 키워드로 빠르게 접근.
  • 실무 대응에서도 장애 Root Cause 파악 시 이 카드 참고.

필요하다면 아래와 같이 변환해드릴 수 있습니다:

  • 📄 Word 또는 PDF 파일
  • 🧪 정답 숨김 연습용 문항
  • 🧩 장애 유형별 대응 전략 도식화
  • 📊 서비스별 백업 지원 Matrix 카드

다음으로 어떤 분야로 확장할까요? (예: DR Runbook, Azure Site Recovery, Hybrid Backup 등)

'Migration & DR > 시스템 이관환경 및 Landing Zone 설계' 카테고리의 다른 글

Azure 랜딩존(Azure Landing Zone) 개념, 문제(클러스터링,스토리지,API Gateway)  (0) 2025.07.18
(gpt)On-Premises DB를 Microsoft Azure로 마이그레이션  (0) 2025.07.18

실무 아키텍처 설계, 장애 대응 시나리오, 튜닝 및 최적화, 그리고 보안 및 이중화 전략까지 포괄해야 합니다. 아래는 시험을 대비한 WEB/WAS 핵심 개념 정리, 시나리오형 문제집, 암기카드, 키워드 인덱스 요약 구성입니다.

📘 1. 핵심 개념 요약 (TA 직무역량 관점)

1.1. WEB/WAS 구조 개요

  • WEB Server: 요청을 정적 리소스(html, css 등)로 처리, WAS로 요청 전달
    • 예: NGINX, Apache
  • WAS: Java Servlet 기반 동적 처리 (Tomcat, JBoss, WebLogic 등)
  • 구성 패턴
    • 단일서버 구성: WEB+WAS 통합 → 빠른 구축, 낮은 확장성
    • 분리 구성: WEB ↔ WAS → 장애 격리, 부하분산 용이

1.2. 주요 아키텍처 설계 고려사항

  • 이중화: L4/L7 로드밸런서, Active-Standby 구성
  • 세션 처리: Sticky Session vs Session Clustering (ex: Redis 기반)
  • Connection Pool: DB와의 연결 성능 및 장애 대응 핵심
  • Reverse Proxy/SSL Offload: NGINX 활용

1.3. 성능 및 보안 튜닝

  • JVM 옵션 설정 (-Xms, -Xmx, GC, Thread)
  • HTTP Keep-Alive, Compression 설정
  • WAS 보안 설정 (context.xml, web.xml, XSS/CSRF 대응)

1.4. 실무 주요 설정 파일

  • server.xml: 포트, 커넥터 설정
  • web.xml: Servlet 매핑 및 보안정책
  • context.xml: DB Connection 설정 및 리소스 관리
  • setenv.sh: JVM 옵션 설정

📚 2. 시나리오 기반 문제집 (20문항)

각 문항은 [문제 - 정답 - 해설] 3단 구성이며 난이도 표시 포함

✅ 예시 문제

문제 1 (난이도: 중)

WAS 서버에서 GC 튜닝 이후 API 응답 시간이 급격히 느려졌다. 가능한 원인으로 적절한 것은?

① GC 로그 미설정으로 모니터링 부재
② Xms, Xmx 설정이 동일하여 Heap 확장이 안됨
③ ThreadPool Core 수 증가
④ ConnectionPool MaxActive 감소
⑤ /dev/random 대기 문제

정답: ②
해설: Xms와 Xmx가 동일하면 메모리 확장에 의한 GC 이슈는 방지되지만, 설정값이 너무 높으면 Full GC 발생 가능성 및 메모리 오버커밋 문제가 발생할 수 있음.

문제 7 (난이도: 상)

WEB-WAS 분리 구성에서 HTTP 499 오류가 빈번하게 발생하고 있다. 가장 먼저 확인할 사항은?

① NGINX의 proxy_read_timeout 설정
② Tomcat의 maxThreads 설정
③ DB의 slow query log
④ session timeout
⑤ HTTP Keepalive 설정

정답: ①
해설: HTTP 499는 클라이언트가 응답을 기다리지 못하고 연결을 종료했을 때 발생. 주로 proxy_read_timeout 설정값보다 백엔드(WAS)의 응답이 늦는 경우 발생.

총 20문항 제공 가능
➡️ 요청 시 전체 문항 생성하여 제공해드릴게요.

🧠 3. 암기카드 요약 (Flashcard형)

개념설명
WEB Server 정적 리소스 처리, WAS로 요청 전달 (NGINX, Apache)
WAS 동적 컨텐츠 처리 (Tomcat, WebLogic 등)
Sticky Session L4/L7 로드밸런서에서 세션을 특정 서버에 고정
GC 튜닝 Full GC 발생 빈도, 메모리 누수 확인
ThreadPool 요청 병렬 처리 수 조절, WAS 성능 영향
server.xml 커넥터 설정, 포트 및 SSL 등
context.xml 리소스 설정(DB Pool 등), JNDI 연동
session clustering Redis, DB로 세션 공유하여 무중단 구성
Connection Pool maxActive, minIdle, validationQuery 설정 중요
499 오류 NGINX에서 클라이언트가 응답 기다리지 못하고 종료한 경우

🔍 4. 블로그용 키워드 인덱스 요약본 (Ctrl+F 검색용)

 
#WEB_WAS_구성 #WEB서버역할 #WAS동작원리 #Tomcat_구성파일 #server.xml_설명 #context.xml_DB설정 #web.xml_보안설정 #JVM옵션 #GC튜닝 #Heap메모리설정 #ThreadPool최적화 #NGINX_설정 #proxy_read_timeout #HTTP_499 #세션클러스터링 #로드밸런싱 #StickySession #Session공유 #ConnectionPool튜닝 #ReverseProxy구성 #WAS_이중화 #WAS_장애대응 #WEB_WAS_분리 #SSL_Offload #오류코드_정리 #WAS장애조치

✍️ 다음 추천 학습 흐름

  1. 기본개념 정리: 위 요약 + 암기카드 암기
  2. 시나리오 문제 풀기: 예상 문제집 20문항
  3. 실제 설정파일 분석: server.xml, web.xml, context.xml, setenv.sh 실습
  4. 장애 사례 스터디: HTTP 5xx, GC Delay, ThreadPool Block 등
  5. 오픈북 블로그 세팅: Ctrl+F 검색용 키워드 준비

 

 

🛠 WEB/WAS 실전 장애 대응 시나리오형 문제집 (총 15문항)

각 문항은 **[난이도 표시 포함]**이며, TA 시점에서 판단력, 원인 분석, 조치 방안까지 평가합니다.

✅ NO.01 - HTTP 499 오류 발생

[난이도: 중]
시나리오: 서비스 로그에서 HTTP 499 오류가 증가하고 있다. 클라이언트는 웹브라우저이며, WAS는 Tomcat, WEB은 NGINX이다.

질문: 가장 먼저 확인해야 할 설정은 무엇이며, 그 이유는?

  • 정답: NGINX의 proxy_read_timeout 설정
  • 해설: HTTP 499는 클라이언트가 응답을 기다리지 못하고 연결을 끊을 때 발생한다. 대부분 NGINX가 설정한 proxy_read_timeout보다 WAS의 응답이 늦을 때 발생하며, 이 경우 WAS 응답 시간이 정상인지 확인 후, NGINX timeout을 늘릴 수 있다.

✅ NO.02 - ThreadPool 고갈로 인한 대기

[난이도: 상]
시나리오: WAS에서 API 요청이 지연되고, maxThreads 도달로 새 요청이 지연되며, JVM은 정상 상태이다.

질문: 조치 순서를 서술하시오.

  • 정답:
    1. threadDump로 스레드 상태 확인
    2. Blocking 요청 여부 확인 (ex: DB lock, 외부 API 대기 등)
    3. maxThreads 조정 또는 작업 분산
  • 해설: 단순히 maxThreads를 올리는 것이 아니라, 대기 스레드의 원인을 분석해야 한다. threadDump 확인은 병목 원인 추적의 기본이다.

✅ NO.03 - Connection Pool 고갈

[난이도: 상]
시나리오: DB 연결 오류가 간헐적으로 발생하며, Cannot get a connection 메시지가 보인다. DB 자체는 정상이다.

질문: 가능한 원인과 대응 방안은?

  • 정답: Connection Pool 고갈로 인해 새 요청을 처리하지 못함 → 원인: 커넥션 미반납, 대기시간 초과 등
    • 대응: maxActive, maxWait, validationQuery 설정 확인, 커넥션 leak 점검
  • 해설: 커넥션 풀은 DB 연결 자원으로, 미반납 시 다음 요청이 대기하게 되고 응답 지연이 발생한다. Validation 쿼리 및 Timeout 설정 확인이 필요하다.

✅ NO.04 - session timeout 오류

[난이도: 중]
시나리오: 로그인을 했지만 일정 시간 후 아무 행동 없이 페이지 이동 시 재로그인이 요구된다.

질문: 점검 항목을 모두 나열하시오.

  • 정답:
    • web.xml의 <session-timeout> 설정 확인
    • NGINX idle timeout 확인
    • 로드밸런서(L7)의 세션 유지 여부 확인
  • 해설: 세션 유지 시간은 클라이언트와 WEB, WAS 각각의 timeout에 따라 종료될 수 있다.

✅ NO.05 - GC로 인한 응답 지연

[난이도: 상]
시나리오: WAS 서버에서 주기적으로 전체 API 응답이 멈추는 현상이 발생한다. 로그에는 Full GC가 확인된다.

질문: GC 튜닝을 위해 확인해야 할 항목은?

  • 정답:
    • -Xmx, -Xms 메모리 설정
    • GC 로그 (-Xlog:gc*) 확보
    • heapDump 분석
    • OldGen 증가속도 확인
  • 해설: Full GC는 Old 영역이 가득 차면 발생하며, 메모리 부족 또는 객체 누수가 원인일 수 있다. GC 로그를 통한 분석이 우선이다.

✅ NO.06 - WAS 종료 없이 포트 미응답

[난이도: 중]
시나리오: WAS 프로세스는 떠 있지만, 8080 포트에서 응답이 없다. netstat에선 포트 LISTEN 중이다.

질문: 추가로 확인할 항목은?

  • 정답:
    • ThreadPool 상태 (maxThreads 도달 여부)
    • Application 내부 Blocking (DB, 외부 API 등)
  • 해설: 프로세스는 살아 있어도 모든 요청을 처리하지 못하고 blocking 상태일 수 있다.

✅ NO.07 - WAR 재배포 이후 장애

[난이도: 하]
시나리오: 신규 WAR 파일 배포 이후 기존 REST API가 404를 발생시킨다.

질문: 우선 확인할 항목은?

  • 정답: web.xml servlet mapping 또는 URL context path 설정
  • 해설: 배포 후 404는 매핑 오류나 context path 오류가 주요 원인이다.

✅ NO.08 - Static 리소스 누락

[난이도: 하]
시나리오: 이미지, JS, CSS 파일이 로드되지 않으며 403 오류 발생

질문: 원인과 조치방안은?

  • 정답: NGINX 또는 Apache의 접근 권한 설정 오류
    • 조치: /static/ 경로 접근 허용, SELinux 또는 권한 확인
  • 해설: 보안 설정으로 인한 차단일 수 있다.

✅ NO.09 - 세션 공유 안됨

[난이도: 상]
시나리오: L7 로드밸런서로 여러 WAS로 부하 분산 시 로그인 후 다른 요청에서 세션이 유지되지 않는다.

질문: 가능한 원인과 해결책은?

  • 정답:
    • Sticky Session 미적용 → 해결: Sticky 설정 적용
    • Session clustering 미구현 → 해결: Redis, DB 등 외부 공유 세션 구현
  • 해설: 세션이 노드 간 공유되지 않으면 로그인 상태가 유지되지 않는다.

✅ NO.10 - JSP 컴파일 지연

[난이도: 중]
시나리오: 신규 배포 후 처음 페이지 접근 시 응답 지연이 발생함

질문: 원인 및 개선방안은?

  • 정답: JSP 최초 접근 시 컴파일 발생 → 개선: 사전 컴파일 또는 첫 접근 자동화 스크립트
  • 해설: JSP는 최초 접근 시 컴파일을 수행하며 지연이 발생할 수 있다.

추가 구성 가능한 문제 항목 (예고)

번호장애 유형난이도
11 Tomcat 재시작 후 bind 오류 중
12 Reverse Proxy 구성 오류 하
13 /dev/random 대기 이슈 상
14 Root Context 충돌 이슈 중
15 XSS 필터 적용 오류 상
 

 

🛠 WEB/WAS 실전 장애 대응 시나리오 문제집 (30문항)

🔹1~10번: 응답 지연 및 오류 코드 중심

✅ NO.01 [중] HTTP 499 오류 발생

시나리오: 클라이언트 로그에 HTTP 499 오류 다수 발생
질문: 가장 먼저 확인할 설정은?

  • 정답: NGINX proxy_read_timeout
  • 해설: 클라이언트가 응답을 기다리지 못해 끊은 경우 발생하며, WAS 지연 시 timeout을 늘려야 한다.

✅ NO.02 [상] ThreadPool 고갈

시나리오: 요청 폭주 시 thread 수가 maxThreads에 도달
질문: 우선적으로 수행할 조치는?

  • 정답: threadDump로 blocking 원인 확인
  • 해설: 단순 thread 수 증가보단 병목 원인 파악이 선행되어야 함

✅ NO.03 [상] Connection Pool 고갈

시나리오: DB 연결 오류 – “cannot get connection” 발생

  • 정답: 커넥션 미반납 여부, maxActive 확인
  • 해설: Connection leak, validation query, timeout 등 점검 필수

✅ NO.04 [중] Session timeout 현상

시나리오: 로그인 후 일정 시간 뒤 세션 만료

  • 정답: web.xml, LB idle timeout 설정 확인
  • 해설: Client ↔ Web ↔ WAS 모든 경로의 timeout 정책 확인

✅ NO.05 [상] Full GC로 인한 멈춤

시나리오: 주기적 WAS 응답 멈춤

  • 정답: GC 로그 확보 후 heap size, 객체 수명 확인
  • 해설: Old 영역 누수, GC 정책 부적절, Memory over allocation 등

✅ NO.06 [중] WAS 프로세스는 살아 있으나 포트 응답 없음

시나리오: netstat에선 LISTEN, 요청 무응답

  • 정답: ThreadPool block 상태 확인
  • 해설: deadlock, 외부 API wait, DB lock 확인 필요

✅ NO.07 [하] WAR 재배포 이후 REST API 404

  • 정답: URL 매핑 또는 context path 오류
  • 해설: web.xml 매핑 확인

✅ NO.08 [하] 정적 리소스 403 오류

  • 정답: 접근 권한 설정, SELinux 확인
  • 해설: OS 또는 NGINX 보안 정책이 차단했을 가능성

✅ NO.09 [상] L7 LB 세션 미유지

  • 정답: Sticky Session 또는 Session Clustering 미구현
  • 해설: Redis, DB 등 외부 세션 공유 구현 고려

✅ NO.10 [중] JSP 초기 진입 지연

  • 정답: 최초 JSP 컴파일
  • 해설: 사전 컴파일로 지연 최소화 가능

🔹11~20번: 설정 오류 및 배포 장애 중심

✅ NO.11 [중] Tomcat 재기동 후 8080 bind 오류

  • 정답: 이전 프로세스 종료 미완 → ps -ef | grep java 확인
  • 해설: OS 포트 점유 상태를 확인해야 함

✅ NO.12 [하] NGINX reverse proxy 설정 오류

  • 정답: proxy_pass 대상 주소 확인
  • 해설: 슬래시 유무, root vs alias 문제

✅ NO.13 [상] /dev/random 대기

  • 정답: Entropy 부족 → /dev/urandom 사용
  • 해설: TLS handshake 지연 원인

✅ NO.14 [중] root context 중복

  • 정답: context.xml의 path 중복 제거
  • 해설: ROOT.war 중복시 충돌 발생

✅ NO.15 [상] web.xml 필터 설정 오류

  • 정답: URL 패턴 잘못 매핑됨
  • 해설: 필터 우선순위, mapping 순서 확인

✅ NO.16 [중] 비정상적인 reload 후 500

  • 정답: server.xml, context.xml 설정 충돌
  • 해설: 자원 중복 또는 오염된 캐시로 인한 문제

✅ NO.17 [상] OutOfMemoryError: Metaspace

  • 정답: JVM 옵션 중 -XX:MaxMetaspaceSize 증가
  • 해설: 클래스 로더 누수 또는 클래스 재정의 가능성

✅ NO.18 [중] PermGen space 오류

  • 정답: Java 7 이전 → -XX:MaxPermSize 조정
  • 해설: Java 8 이후는 Metaspace로 대체됨

✅ NO.19 [중] WAR 안에 libs 충돌

  • 정답: 의존 라이브러리 버전 불일치
  • 해설: ClassLoader 충돌 → NoSuchMethodError 가능

✅ NO.20 [하] 로컬에서는 정상, 서버에서 오류

  • 정답: 환경변수 또는 시스템 속성 누락
  • 해설: -Dspring.profiles.active 누락 등

🔹21~30번: 보안, 인프라 및 외부 연동 장애

✅ NO.21 [중] CSRF 오류 발생

  • 정답: Referer, Origin 헤더 누락
  • 해설: 웹브라우저 외부 접근 시 차단됨

✅ NO.22 [상] 외부 API 호출 시 timeout

  • 정답: 호출 timeout, retry 정책 미적용
  • 해설: Circuit Breaker 적용 검토

✅ NO.23 [중] TLS 인증서 오류

  • 정답: 인증서 만료 또는 신뢰 anchor 없음
  • 해설: SSL chain 누락 가능성

✅ NO.24 [상] JVM CPU 사용률 100%

  • 정답: Infinite Loop, Busy Wait
  • 해설: jstack, jvisualvm 활용

✅ NO.25 [중] NGINX Keepalive 사용 시 문제

  • 정답: Connection 재사용 실패
  • 해설: backend connection pool 부족

✅ NO.26 [상] Tomcat에 사용자 정의 필터 적용 시 모든 요청 실패

  • 정답: filter에서 예외 처리 누락
  • 해설: chain.doFilter 미호출로 chain 중단됨

✅ NO.27 [하] WAS 로그가 생성되지 않음

  • 정답: log4j/logback 설정 경로 오류
  • 해설: log 디렉토리 권한 포함 확인

✅ NO.28 [상] Redis 기반 세션 장애 발생

  • 정답: Redis eviction 정책 및 TTL 설정
  • 해설: 세션 만료 및 메모리 부족 문제 발생 가능

✅ NO.29 [중] gzip 설정 후 페이지 깨짐

  • 정답: 중복 압축 설정
  • 해설: WAS와 WEB 모두 gzip 시 이중 압축

✅ NO.30 [상] multipart 업로드 오류

  • 정답: maxPostSize 설정 부족
  • 해설: 업로드 용량 제한 기본 2MB

📌 다음 제공 가능 항목

  • ✅ [PDF/Word 변환]: 실전 대비 문제집 출력용
  • ✅ [암기카드 요약]: 키워드 중심 1줄 요약
  • ✅ [Ctrl+F용 키워드 인덱스]: 블로그용 검색 최적화
  • ✅ [빈칸형 연습문제/정답 숨김용 버전]

 

🧠 WEB/WAS 실전 장애 대응 암기카드 요약 (30개)

번호키워드암기카드 요약
01 HTTP 499 NGINX의 proxy_read_timeout 설정이 낮으면 WAS 응답 지연 시 499 오류 발생
02 ThreadPool 고갈 maxThreads 도달 시 threadDump로 blocking 원인부터 분석
03 ConnectionPool 고갈 커넥션 미반납, leak 발생 시 DB 연결 오류 발생
04 Session timeout web.xml, LB, NGINX 모두 timeout 설정 확인 필요
05 Full GC 지연 Full GC로 WAS 전체 멈춤 → GC 로그, heapDump 분석 필요
06 프로세스 살아있지만 무응답 포트 LISTEN이어도 blocking thread로 응답 없음 가능
07 WAR 재배포 404 context path 또는 servlet mapping 설정 오류 확인
08 정적 리소스 403 NGINX 권한, SELinux, 파일 권한 설정 확인
09 세션 미유지 Sticky Session 또는 Session clustering 미적용 문제
10 JSP 지연 최초 JSP 접근 시 컴파일 지연 → 사전 컴파일 권장
11 포트 바인딩 실패 이전 WAS 프로세스 종료 안 됨 → ps, lsof로 확인
12 reverse proxy 오류 NGINX proxy_pass 경로 오류 또는 슬래시 누락 문제
13 /dev/random 지연 TLS handshake 지연 → /dev/urandom 사용 권장
14 Root context 충돌 context path 중복 시 충돌 발생 (ex: ROOT.war)
15 web.xml 필터 오류 잘못된 필터 매핑 시 요청 전체 차단 가능
16 Reload 후 500 설정파일 충돌 또는 context 오염 가능성
17 Metaspace OOM -XX:MaxMetaspaceSize 설정 부족 또는 클래스 로더 누수
18 PermGen OOM Java 7 이하에서는 -XX:MaxPermSize로 설정 필요
19 라이브러리 충돌 WAR 내 라이브러리 중복 → NoSuchMethodError 가능
20 로컬만 정상 -Dspring.profiles.active 등 환경변수 누락 의심
21 CSRF 오류 Referer 또는 Origin 헤더 누락 시 필터 통과 실패
22 외부 API timeout Retry, timeout, Circuit Breaker 미구현 시 장애 발생
23 TLS 인증서 오류 인증서 만료 또는 Chain 누락으로 SSL 오류 발생
24 JVM CPU 100% 무한 루프, Busy Wait 발생 → jstack 분석 필요
25 Keepalive 문제 WEB ↔ WAS 간 커넥션 재사용 실패 → connection pool 확인
26 Filter 적용 후 전체 오류 chain.doFilter 호출 누락 시 전체 요청 막힘
27 로그 생성 안됨 log 설정 경로 오류 또는 로그 디렉토리 권한 문제
28 Redis 세션 장애 TTL, eviction 정책 미설정 시 세션 유실 가능
29 gzip 설정 오류 WAS/WEB 모두 gzip 설정 시 이중 압축으로 오류 발생
30 파일 업로드 실패 multipart 설정의 maxPostSize 미조정으로 제한 초과 발생

📌 활용 팁

  • ✅ 오픈북용 블로그: Ctrl+F → 키워드 검색 (gzip, 499, GC, threadpool, redis, upload)
  • ✅ 시험 직전 스캔: 개념-원인-조치 키워드 3단 기억 반복
  • ✅ PDF 카드화 요청 가능: 원하시면 카드 형식으로 PDF 출력도 해드릴게요

'WEB & WAS > 기본 개념' 카테고리의 다른 글

WEB/WAS 실무 심화 핵심 요약  (0) 2025.05.08

GC(Garbage Collection)는 Java 및 기타 고급 언어에서 더 이상 사용되지 않는 객체를 자동으로 메모리에서 정리해주는 기능입니다.
즉, 프로그래머가 직접 free() 같은 메모리 해제를 하지 않아도 되게 만들어주는 자동 메모리 관리 시스템입니다.

아래는 실무, 성능, TA 관점까지 반영하여 설명드립니다.

✅ 1. GC란? (기본 개념)

구분설명
목적 사용되지 않는 객체를 정리해 힙(Heap) 메모리 누수 방지
타이밍 JVM이 메모리 부족 또는 일정 조건에서 자동 수행
대상 더 이상 참조되지 않는 객체(=Unreachable Object)
관리 영역 주로 Heap 메모리 영역을 대상으로 함

✅ 2. GC의 주요 동작 과정

  1. 객체 생성
    • new 연산자 등을 통해 Heap에 객체 생성됨
  2. 객체 참조 확인
    • JVM은 "어떤 객체가 여전히 쓰이는가?"를 **루트(Root Set)**에서 따라가며 확인
    • 참조되지 않는 객체는 Garbage로 간주
  3. GC 수행
    • 참조되지 않는 객체를 정리하여 Heap 공간 회수
  4. GC 로그 출력 (선택적 설정)

✅ 3. GC의 주요 알고리즘 유형

유형특징사용 영역
Serial GC 단일 스레드 GC CPU가 적은 환경, 테스트 환경
Parallel GC 다중 스레드로 GC Throughput 중심 환경
CMS (Concurrent Mark-Sweep) 앱 실행과 GC를 병렬로 수행 GC 지연 최소화 필요할 때
G1 GC Region 기반 정교한 GC, Full GC 방지 대규모 Heap, 최근 JVM 기본값
ZGC / Shenandoah 지연시간 수 밀리초 수준, 대용량 Heap 초지연(low-latency) 시스템

✅ 4. GC의 메모리 영역

JVM의 Heap은 다음과 같이 구분됨:

🔸 Young Generation

  • 새로 생성된 객체가 위치
  • Eden, Survivor(S0/S1) 영역으로 구성
  • Minor GC가 자주 발생

🔸 Old Generation

  • 오래 살아남은 객체
  • 메모리 누수의 주요 원인
  • Major GC 또는 Full GC 대상

✅ 5. 실무에서 중요한 GC 튜닝 포인트

항목설명
-Xms, -Xmx Heap 최소/최대 크기 설정
-Xss 스레드 Stack 크기 (스레드 수에 영향)
-XX:+UseG1GC G1 GC 사용 여부
-XX:+PrintGCDetails GC 상세 로그 출력
GC 로그 분석 도구 GCViewer, GCEasy, VisualVM 등

✅ 6. GC가 성능에 미치는 영향

영향설명
Stop-The-World(STW) GC 중 모든 애플리케이션 스레드 일시 중단 (지연 발생 원인)
GC Pause Time 요청이 밀리거나 응답이 늦어지는 원인
Full GC 응답이 수 초 지연될 수 있어 실무에서는 경계 대상
과도한 객체 생성 GC 부담 증가 → CPU 상승, GC 빈도 증가

✅ 7. 실무 대응 예시

증상원인대응
응답이 수 초간 정지됨 Full GC 객체 수명 관리, G1GC 전환, Heap 증설
GC 로그 없이 OOM 발생 GC 미수행 + 메모리 누수 힙덤프 분석, 참조 해제 여부 확인
CPU 100% 고정 Minor GC 반복 객체 재사용, 힙/GC 전략 변경

✅ 8. GC 튜닝 전략 요약

전략설명
GC 알고리즘 변경 G1GC, ZGC 등으로 전환하여 지연 최소화
객체 생명 주기 관리 불필요한 객체 생성을 피하고, Pool 사용 권장
GC 로그 기반 분석 GC 발생 시간, 멈춤 시간 추적 후 조정
힙 사이즈 조절 여유 있는 힙 설정이 GC 횟수를 줄임

📌 결론 요약

  • GC는 Java의 자동 메모리 회수 시스템
  • JVM이 참조되지 않는 객체를 제거하여 힙 공간을 확보
  • 성능 이슈의 원인이 되기도 하므로 GC 알고리즘 선택과 튜닝이 중요
  • Heap 사용량, 객체 수명, GC 로그 분석이 핵심 진단 도구

🧠 GC 튜닝 암기카드

💡 [카드 1] Minor GC vs Major GC

  • Minor GC: Young 영역에서 발생, 빠르고 자주 일어남
  • Major/Full GC: Old 영역 대상, 정지 시간 길고 성능에 큰 영향

💡 [카드 2] GC 대상

  • GC는 힙(Heap) 메모리만 정리
  • Stack, Metaspace는 별도 관리

💡 [카드 3] G1 GC

  • Region 기반 GC 알고리즘
  • Young/Old 분리 없이 동적 구성
  • Full GC 없이 처리 유도, 대규모 힙에서 성능 우수

💡 [카드 4] Stop-The-World (STW)

  • GC 중 모든 애플리케이션 스레드 일시 정지
  • GC 튜닝 핵심은 STW 최소화

💡 [카드 5] 객체 생존 주기

  • Young → Survivor → Old로 이동
  • Survivor 영역을 넘기면 Old 영역으로 승격(Promotion)

💡 [카드 6] GC 튜닝 주요 옵션

옵션설명
-Xms / -Xmx Heap 최소/최대 크기
-Xss 스레드 Stack 크기
-XX:+UseG1GC G1 GC 활성화
-XX:+PrintGCDetails GC 상세 로그 출력

💡 [카드 7] Full GC 빈도 높을 때 조치

  • 객체 수명 최적화
  • 힙 증설 (-Xmx)
  • G1GC 전환
  • 대용량 객체 캐시 개선

💡 [카드 8] GC 분석 도구

  • jstat, jmap, VisualVM
  • GCEasy.io, GCViewer

💡 [카드 9] OutOfMemoryError (OOM) 원인

  • Old 영역 포화
  • Perm/Metaspace 포화
  • 스레드 과다 생성 (unable to create native thread)

💡 [카드 10] GC와 TPS 관계

  • GC 빈도/지연 증가 → TPS 하락
  • 대기열 증가, 응답지연, 타임아웃 발생 가능

💡 [카드 11] GC 로그에 나타나는 키워드

키워드의미
GC Minor GC
Full GC Major GC
Pause STW 시간
eden, survivor, old 각 힙 영역 사용량 표시

💡 [카드 12] GC 튜닝 전략 요약

  1. G1GC 사용 고려
  2. 객체 재사용, 캐시 최적화
  3. 힙 크기 조정 (Xmx, Xms)
  4. 로그 기반 분석 → OOM/FullGC 원인 파악
  5. STW 시간 줄이기: GC 알고리즘 전환, GC Pause 타이밍 확인

호처리 API가 VM 환경에 있고, DB 서버는 데디케이티드 서버(전용 물리 서버)로 구성되어 있으며, DB는 정상적으로 요청을 처리했지만 API가 응답을 늦게 받는 상황이라면, 주요 원인은 다음과 같은 구간에서 발생할 수 있습니다.

📌 지연 구간별 점검 항목

1. AP(VM) 내부 문제

  • CPU/메모리 자원 부족
    VM의 리소스가 부족하거나 과도한 GC, 다른 프로세스에 의해 리소스 경쟁이 있는 경우.
  • 스레드 풀 부족
    API 서버의 쓰레드 풀이 고갈되어 요청을 처리하지 못하고 대기 상태가 될 수 있음.
  • GC(가비지 컬렉션) 지연
    Java 기반이면 Full GC로 인해 일시 정지 발생 가능.
  • 네트워크 처리 큐 적체
    비동기 큐나 이벤트 루프 내에서 처리가 지연되는 경우.

2. VM ↔ DB 네트워크 구간

  • 네트워크 지연 (Latency)
    VM과 DB 서버 간 네트워크 RTT(Round Trip Time)가 높거나 패킷 재전송이 잦은 경우.
  • 패킷 드롭/재전송
    네트워크 인터페이스 오류, MTU mismatch, switch congestion 등으로 인한 손실.
  • 방화벽/IPS/네트워크 보안 장비 처리 지연
    중간에 보안 장비가 있고 DPI(Deep Packet Inspection) 등의 검사로 인해 처리 지연 가능.

3. DB 처리 완료 후 응답 전달 지연

  • DB 응답은 빠른데 AP가 응답을 읽지 못함
    DB에서는 처리 완료했지만, API 측 소켓 버퍼가 꽉 차거나 리스폰스 처리 로직이 병목되는 경우.
  • JDBC 커넥션 풀 문제
    커넥션 풀에서 커넥션을 반환하지 않거나 오래된 커넥션 재사용으로 인한 지연.

4. AP 로깅/트랜잭션 처리 문제

  • 트랜잭션 커밋 후 로깅 지연
    DB는 응답했지만, API는 로깅/모니터링/후처리 중에 병목 발생.
  • 동기 방식의 로깅/외부 연동 호출
    DB 처리 이후 다른 시스템 호출(log server, audit API 등)이 늦어지는 경우 전체 응답도 지연.

🧪 진단을 위한 로그/모니터링 확인 포인트

  • AP 레벨의 처리 시간 로그
    • DB 요청 전 시간
    • DB 응답 수신 시간
    • 응답 반환까지 시간
      → 이 구간별로 타임스탬프를 로그에 남기면 지연 위치 파악 가능
  • 네트워크 RTT 측정
    • ping, traceroute, mtr, ss, netstat 등으로 VM ↔ DB 간 지연 여부 확인
  • AP의 GC 로그, Thread Dump 분석
    • 처리 지연 시점에 GC 또는 스레드 블로킹 여부 분석
  • JDBC 커넥션 풀 상태
    • 사용 가능한 커넥션 수, 대기 수, 커넥션 생성/소멸 속도

🛠 조치 방안 요약

원인 영역점검 및 조치
AP 리소스 문제 VM 스펙 증설, GC 튜닝, 스레드풀 조정
네트워크 문제 RTT 측정, NIC 상태 확인, 방화벽/라우터 로그 확인
DB 커넥션 문제 커넥션 풀 크기 조정, maxLifetime 설정 확인
처리 로직 병목 후처리 비동기화, 로깅 비동기화, 외부 연동 최적화

필요하다면 예시 로그 분석 패턴이나 AP 처리 흐름 시퀀스 다이어그램도 만들어 드릴 수 있어요. 원하시면 말씀 주세요.

나의 말:

vm에서 성능이 좋은 데디서버로 변경하면 쓰레드풀 부족에 따른 지연현상을 줄일 수있을까?

ChatGPT의 말:

VM에서 성능이 좋은 데디서버(Dedicated Server) 로 API를 이관하면 쓰레드풀 부족에 따른 지연 현상을 줄일 수 있습니다. 다만 조건이 붙습니다.

✅ 가능성이 높은 개선 효과

데디서버로 이관 시 다음과 같은 자원 제약이 해소되기 때문에 쓰레드풀이 여유로워져 지연이 줄어들 가능성이 큽니다.

1. CPU/메모리 리소스 제약 해소

  • VM에서는 CPU와 메모리를 공유하며, 하이퍼바이저나 noisy neighbor로 인한 자원 간섭이 발생할 수 있음.
  • 데디서버는 단독으로 물리 자원을 사용하므로, 스레드 생성/처리 성능이 향상됨.
  • CPU 코어 수가 늘어나면 동시 처리 가능한 스레드 수(병렬성)도 증가.

2. GC 지연 완화 (Java 기반일 경우)

  • Full GC 등으로 인한 Stop-the-world 시간이 짧아짐.
  • Heap 공간을 더 넉넉하게 구성 가능 → GC 발생 빈도 감소.

3. I/O 처리 성능 향상

  • 디스크나 네트워크 대역폭이 물리적으로 확보되어 I/O 병목이 줄어듦.
  • 특히 API 서버가 외부 시스템과 많은 통신을 할 경우, 이점이 큼.

⚠️ 단, 쓰레드풀 “설정값”이 병목 원인이라면 하드웨어 변경만으로는 불충분

아래와 같은 경우는 데디서버로 이관해도 지연이 지속될 수 있습니다:

원인설명
❌ 쓰레드풀 max 값이 너무 작게 설정됨 데디서버로 이관해도 max thread 수가 100으로 고정돼 있으면 성능 개선 제한적
❌ 블로킹 처리/대기 로직이 많음 스레드가 I/O 대기, 동기 연동, 락 대기 등으로 묶여 있음
❌ 스레드풀 고갈 후 큐 처리 정책 미흡 큐가 가득 찬 뒤에 요청을 Drop 하거나 Timeout이 길게 설정되어 있음

🧩 결론

조건데디서버 이관 효과
VM 자원이 병목 원인일 경우 ✅ 지연 현상 완화에 효과적
애플리케이션 설정/구조가 원인일 경우 ⚠️ 추가 조정 필요 (설정, 아키텍처)

✅ 추천 조치 조합

  1. 하드웨어 이관 (데디서버)
    → 기본 성능 한계를 상향 조정
  2. 스레드풀 설정 최적화
    • 최대 동시 처리 수 조정 (corePoolSize, maxPoolSize)
    • 큐 길이 및 정책 조정 (SynchronousQueue, LinkedBlockingQueue 등)
  3. 비동기화/비차단 처리 도입
    • 외부 연동 로직에 Async, Reactive, NIO 방식 적용
  4. 모니터링 도입
    • Thread dump, Prometheus, JVM metrics, APM 도입하여 병목 지점 가시화

원하시면 스레드풀 튜닝 체크리스트나 데디서버 이관 후 해야 할 성능 테스트 절차도 제공해드릴 수 있습니다.

나의 말:

스레드풀 튜닝 체크리스트를 부탁해

ChatGPT의 말:

물론입니다. 아래는 TA/운영 관점에서 스레드풀 튜닝 체크리스트입니다.
특히 Java 기반 API 서버(Spring, Tomcat, Jetty, Undertow 등)을 기준으로 설계되어 있으며, 실제 장애나 지연 이슈 대응 시에도 활용 가능합니다.

✅ 스레드풀 튜닝 체크리스트

🔹 1. 스레드풀 기본 구성 확인

항목점검 내용예시
corePoolSize 최소 스레드 수 설정 CPU 코어 수에 맞게 설정 (예: 8)
maximumPoolSize 최대 스레드 수 설정 병목이 없다면 core * 2 ~ 3
queueCapacity 대기 큐의 길이 큐가 너무 작으면 reject 발생, 너무 크면 응답 지연
keepAliveTime 유휴 스레드 제거 시간 대기 시간 길면 리소스 낭비됨
threadNamePrefix 스레드 이름 접두어 모니터링/분석 편의성을 위해 설정

🔹 2. 스레드풀 유형(정책) 적절성 확인

유형설명권장 상황
FixedThreadPool 고정된 스레드 수, 큐 무제한 요청이 많고, 처리 시간이 짧은 경우
CachedThreadPool 스레드 무제한 생성, 큐 없음 매우 짧고 빠른 작업 처리에 적합 (주의 필요)
ThreadPoolExecutor + 큐 설정 직접 설정하는 방식 실무에서 가장 선호됨
큐: LinkedBlockingQueue FIFO, 제한 가능 일반적인 API 처리에 적합
큐: SynchronousQueue 대기 없음, 요청 수만큼 스레드 필요 지연 민감한 실시간 요청

🔹 3. 리소스 기반 설정 최적화

기준조정 가이드
CPU 코어 수 corePoolSize ≒ 논리 코어 수 (HT 감안)
평균 처리 시간 처리 시간이 길면 maximumPoolSize 및 큐 증가 필요
TPS (초당 트랜잭션 수) TPS x 평균 응답시간 ≒ 적절한 큐 + maxThreads 추정 가능

🔹 4. 모니터링 기반 점검 항목

항목이상 징후점검 방법
active thread 수 maximumPoolSize에 자주 도달 thread dump, JMX, APM 확인
queue size 지속적으로 큐가 가득 차 있음 actuator, micrometer, prometheus
reject count 작업이 거부됨 log.warn(RejectedExecutionException), metric으로 추적
응답 시간 분포 p95, p99에서 급격히 상승 외부 모니터링 (New Relic, Datadog 등)
GC 시간 증가 Full GC 잦음 GC 로그 분석, 힙 프로파일링

🔹 5. 예외 처리 및 비동기 연동 고려

항목설명
비동기 처리 (@Async, CompletableFuture) 블로킹 최소화, 처리 분산
타임아웃 설정 (Future.get(timeout)) 스레드 무한 대기 방지
fallback 처리 (Circuit Breaker 등) 외부 서비스 실패 대비
RejectedExecutionHandler 지정 거부된 요청에 대한 로깅/알림 처리 필요

🔹 6. 환경/인프라와의 연계 고려

연계 요소주의사항
WAS (Tomcat/Jetty 등) Tomcat maxThreads, acceptCount도 별도로 설정 필요
컨테이너 환경 (K8s 등) CPU/Memory limit 설정 확인, CPU throttling 여부 분석
인프라 스펙 변화 (VM → 데디서버 등) 데디서버에서는 더 큰 thread pool 설정 가능

📌 참고 공식 설정 예 (Spring Boot)

 
spring: task: execution: pool: core-size: 16 max-size: 64 queue-capacity: 200 keep-alive: 60s thread-name-prefix: async-task-

📘 추가 팁

  • Thread Dump 분석 도구 추천:
    • VisualVM, jstack, fastthread.io
  • APM 도구 연동 추천:
    • Pinpoint, Elastic APM, New Relic, Prometheus + Grafana

필요하다면 **실제 시스템에 적용하기 위한 계산 방식(스레드 수 추정 공식)**이나 성능 튜닝 보고서 양식도 도와드릴 수 있습니다.

나의 말:

java 플랫폼에서 쓰레드 갯수를 몇개를 뛰울지를 어디서 설정하지?

ChatGPT의 말:

Java 플랫폼에서 "스레드 갯수를 몇 개 띄울지"는 사용하는 환경/프레임워크와 스레드풀 종류에 따라 설정 위치가 달라집니다. 아래에 실무에서 자주 쓰이는 방식별로 어디서 설정하는지 정리해드릴게요.

✅ 1. Java ExecutorService 사용 시 (직접 스레드풀 생성)

 
ExecutorService executor = Executors.newFixedThreadPool(10);
  • Executors.newFixedThreadPool(10)
    → 최대 10개의 스레드만 생성
  • Executors.newCachedThreadPool()
    → 스레드 무제한 생성, 필요 시 늘어나므로 주의 필요

➡ 직접 생성한 경우, newFixedThreadPool(n)의 n 값이 최대 스레드 수입니다.

✅ 2. Spring Boot/Spring Framework에서 @Async 사용 시

application.yml 또는 application.properties에서 설정

 
spring: task: execution: pool: core-size: 10 max-size: 30 queue-capacity: 100 keep-alive: 60s thread-name-prefix: async-thread-

혹은 Java Config로 직접 설정:

 
@Configuration @EnableAsync public class AsyncConfig implements AsyncConfigurer { @Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); // 기본 스레드 수 executor.setMaxPoolSize(30); // 최대 스레드 수 executor.setQueueCapacity(100); // 큐 용량 executor.setThreadNamePrefix("async-thread-"); executor.initialize(); return executor; } }
  • Spring에서 @Async나 TaskExecutor를 쓸 경우 이 설정에 따라 스레드가 생성됩니다.

✅ 3. Tomcat 등의 WAS 설정 (HTTP 요청 처리 스레드)

Spring Boot 내장 톰캣 기준:

 
server: tomcat: threads: min-spare: 10 max: 200

혹은 server.xml 설정 (standalone Tomcat일 경우):

 
<Connector port="8080" maxThreads="200" minSpareThreads="10" ... />
  • maxThreads는 동시 요청을 처리할 수 있는 최대 스레드 수입니다.
  • WAS는 내부적으로 이 스레드풀로 요청을 처리하며, 쓰레드 수가 이 수치를 넘으면 큐에 대기 또는 거부 처리됩니다.

✅ 4. 서블릿 3.0 기반 비동기 요청 (AsyncContext 등)

Java EE나 서블릿 컨테이너 수준의 비동기 처리에서는 별도 ExecutorService를 넘겨서 처리합니다:

 
AsyncContext asyncContext = request.startAsync(); asyncContext.start(() -> { // 백그라운드 작업 });

이때도 별도로 만든 Executor를 등록해두고 사용할 수 있습니다.

✅ 5. Spring WebFlux, Reactor 등 논블로킹 환경

  • WebFlux는 Netty를 사용하며, 내부적으로 EventLoop나 Schedulers.parallel() 등의 스레드풀을 사용
  • 설정은 Reactor에서 직접 조정 가능:
 
Schedulers.newParallel("custom-parallel", 20);

📌 요약

환경설정 위치
ExecutorService 코드 내 newFixedThreadPool(n)
Spring @Async AsyncConfigurer or application.yml
Tomcat (HTTP 처리) server.tomcat.threads.max or server.xml
Spring WebFlux Reactor Schedulers, Netty 설정
사용자 정의 백그라운드 작업 직접 만든 Executor 설정

 

🔹 1. 자바 메모리 구조 요약

Java 프로세스(JVM)는 다음과 같이 메모리를 여러 영역으로 나눠 사용합니다:

메모리 영역설명
Heap 영역 객체가 저장되는 공간 (new로 생성된 모든 인스턴스)
Stack 영역 각 스레드의 로컬 변수, 호출 스택 저장 공간
Perm/MetaSpace 클래스 정의 등 클래스 메타 정보
Thread 영역 각 스레드가 사용할 Stack 메모리를 별도로 할당

🔹 2. 스레드와 힙 메모리의 차이

항목스레드 Stack 영역힙 Heap 영역
위치 스레드별로 독립 JVM 전체에서 공유
크기 -Xss로 설정 (기본 1MB) -Xms, -Xmx로 설정
쓰기 방식 스레드만 접근 가능 모든 스레드가 접근 가능
사용 용도 메서드 호출, 로컬 변수 저장 new 객체, 컬렉션, 데이터 저장

🔸 관계: 스레드 수가 늘면 전체 메모리 사용량도 증가

  1. 스레드는 각자 Stack 메모리를 가짐
    • 예: -Xss512k 일 때, 스레드 1개당 512KB 필요
    • 스레드 1000개면 → 512MB 소모
  2. Stack에서 힙 객체를 참조함
    • 스택에는 로컬 변수들이 저장되며, 이 변수들은 대부분 힙 객체를 참조합니다.
    • 예: String name = "abc";
      → name 변수는 스택에 있지만, "abc" 객체는 힙에 존재
  3. 스레드가 많을수록 힙 접근이 많아짐
    • 동시에 많은 스레드가 힙 객체를 생성/수정하면 GC 부담이 증가하고, 메모리 압박이 커집니다.
  4. 스레드가 많으면 GC 튜닝도 함께 고려해야 함
    • 다중 스레드는 GC Pause, Throughput, Concurrent Mark Sweep 등에 영향을 줍니다.

📌 실무에서 흔히 발생하는 문제

문제원인대응
OutOfMemoryError: unable to create new native thread 스레드 너무 많이 생성됨 → Stack 공간 부족 OS 제한 확인 (ulimit, vm.max_map_count) 및 스레드 수 제한
GC 너무 자주 발생 스레드가 만든 객체가 힙에 남아 많아짐 힙 크기 조절, 객체 재사용, GC 튜닝
TPS 감소, 지연 증가 많은 스레드가 동시에 힙에 접근해 락/GC 병목 발생 비동기화 설계, 스레드 수 제한

✅ 스레드 ↔ 힙 관계 핵심 요약

포인트설명
스레드 Stack은 각자 따로, 힙은 공유 → 동시성 문제 발생 가능
스레드 수가 많으면 전체 메모리 사용량 증가 → Heap 외에도 Stack 사용량 고려
스레드가 만든 객체는 힙에 저장됨 → 많은 스레드는 많은 객체 생성 유도
스레드 수와 GC, 힙 사용량은 밀접한 관계 → 성능 저하, 지연, OOM 등 발생 가능

🛠 실무 팁

  • 스레드 수 + Stack 크기 x 스레드 수 < 시스템 전체 메모리
  • GC 튜닝 시, -XX:+PrintGCDetails, -Xlog:gc 로 분석
  • APM 도구(Pinpoint, VisualVM, New Relic 등)로 스레드 ↔ 힙 사용량 시각화 가능

원하시면 스레드 수, 힙 크기, GC를 통합적으로 조정하는 운영 가이드나 템플릿도 드릴 수 있어요.

나의 말:

pring 또는 WAS 구조 기준으로 최적 스레드 수 계산 공식이나 설정 예제 파일을 부탁해

ChatGPT의 말:

좋습니다. 아래는 Spring 또는 WAS 구조 기준으로 “최적 스레드 수 계산 공식”과 설정 예제를 실무 적용 가능하도록 정리한 자료입니다.
Java API 서버(Tomcat 기반 Spring Boot) 기준으로 작성하며, 병목 제거 및 응답 지연 최소화에 중점을 둡니다.

✅ 1. 최적 스레드 수 계산 공식

🔹 A. 처리량 기반 계산 (단순 추산 공식)

 
최적 스레드 수 = TPS × 평균 응답 시간 (초)

예:
TPS = 200
평균 응답 시간 = 0.3초
→ 최적 스레드 수 = 200 × 0.3 = 60개

✅ 이 수치는 대기 없이 "원활하게 돌아가기 위한 최소 동시 처리 수"입니다.
➕ 여유를 고려해 1.2~1.5배 확대하는 게 일반적입니다.

🔹 B. CPU 기반 계산 (CPU-bound 작업)

 
최적 스레드 수 ≒ CPU 코어 수 + 1

예: 8코어 머신 → 약 9개

→ CPU 바운드 연산이 많을 때 (압축, 계산) 사용
→ 네트워크 I/O가 많다면, 이 수치를 넘어도 됨

🔹 C. IO 대기 기반 (IO-bound 작업)

 
최적 스레드 수 ≒ CPU 코어 수 × (1 + 평균 대기 시간 / 평균 처리 시간)

예:
처리 시간 = 0.05s,
대기 시간(외부 API, DB) = 0.45s
CPU 코어 수 = 8
→ 8 × (1 + 0.45 / 0.05) = 8 × (1 + 9) = 80개

✅ 2. Spring Boot (Tomcat 내장) 설정 예제

🔸 application.yml (내장 Tomcat, 요청 처리 스레드)

 
server: tomcat: threads: min-spare: 20 max: 200 accept-count: 100 # 큐 크기 (max 초과 시 대기열)

관련 설명

항목설명
max 최대 스레드 수 (Tomcat이 동시에 처리할 요청 수)
min-spare 기본 예열된 스레드 수
accept-count 요청 대기열 크기 (max 초과 시 큐)

🔸 Spring 비동기 Task (예: @Async 처리용)

 
spring: task: execution: pool: core-size: 20 max-size: 100 queue-capacity: 200 keep-alive: 60s thread-name-prefix: async-task-

또는 Java 기반 설정:

 
@Bean("asyncExecutor") public Executor asyncExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(20); executor.setMaxPoolSize(100); executor.setQueueCapacity(200); executor.setThreadNamePrefix("async-task-"); executor.initialize(); return executor; }

✅ 3. Standalone Tomcat (server.xml) 예제

 
<Connector port="8080" maxThreads="200" minSpareThreads="20" acceptCount="100" connectionTimeout="20000" redirectPort="8443" />

✅ 4. WAS 구조에서의 연관 고려사항

요소고려 이유
DB Connection Pool 수 Tomcat maxThreads와 비슷하거나 적어야 병목 방지
OS ulimit -n 파일 디스크립터 수 부족 시 커넥션 에러 발생
JVM Heap 크기 스레드 수 증가 → 힙 사용량도 증가 (객체, GC 영향)
-Xss 설정 스레드당 Stack 크기 (기본 1MB) × 스레드 수 = 메모리 사용량에 영향

📌 실무 팁

상황권장
많은 I/O 대기(API, DB, Redis 등) 스레드 수를 늘리는 방향 (max 300~500도 가능)
CPU 연산이 많은 서비스 코어 수 위주 튜닝 (maxThreads = 코어 수 × 1.5 정도)
GC 지연 발생 스레드 수보다는 힙 구조/객체 수명에 초점
TPS 급증 환경 (이벤트몰, 배치시스템) acceptCount, 큐 설정 함께 튜닝

필요하시면 다음 내용도 드릴 수 있습니다:

  • 🧪 스레드 수 튜닝 후 부하 테스트 스크립트 (JMeter, Locust)
  • 📊 JVM/GW 수치 기반 튜닝 보고서 템플릿
  • 🧵 GC / 스레드 덤프 분석 리포트 예시

언제든 요청해 주세요.

jdbc에서 db 커넥션 정보를 2개까지 설정하여 redundancy를 구성하는 것으로 알고 있는데 맞어?

ChatGPT의 말:

꼭 그렇지는 않습니다. JDBC에서 DB 커넥션 정보를 두 개까지 지정하는 것은 일부 드라이버나 특정 벤더에서 지원하는 Failover / Redundancy 옵션 때문이지, JDBC 표준 자체가 무조건 2개를 지원하는 것은 아니에요.

🔹 1. JDBC 표준 vs 벤더 확장 기능

  • JDBC 표준
    • jdbc:mysql://host:port/db 형태로 단일 DB 연결을 전제로 함.
    • 표준 스펙에서는 기본적으로 1개의 DB 주소만 사용.
  • 벤더 확장 기능
    • 일부 DB 드라이버(MySQL, Oracle RAC 등)는 멀티 호스트를 지원해서 2개 이상의 DB 주소를 지정해 자동 Failover 가능.

예시 (MySQL JDBC):

 
jdbc:mysql://db1.example.com:3306,db2.example.com:3306/mydb ?autoReconnect=true &failOverReadOnly=false &retriesAllDown=3

→ 이렇게 하면 db1 연결 실패 시 자동으로 db2로 재연결합니다.

🔹 2. 주요 DB별 Failover 지원 여부

DBMSJDBC에서 다중 커넥션 지원방식
MySQL ✅ 지원 JDBC URL에 호스트 여러 개 지정 가능
MariaDB ✅ 지원 MySQL과 동일
Oracle RAC ✅ 지원 DESCRIPTION_LIST 또는 SCAN IP 사용
PostgreSQL ✅ 지원 호스트 리스트 지정 가능
MSSQL ⚠️ 제한적 AlwaysOn 모드에서만 지원

🔹 3. 주의할 점

  • 2개만 고정 아님 → MySQL은 호스트를 2개뿐 아니라 N개까지 지정 가능
  • Failover ≠ Load Balancing
    • 보통 JDBC 멀티호스트는 장애 조치(Failover) 용도로만 쓰이며,
    • 읽기/쓰기 부하 분산(Read/Write Split)을 위해서는 별도의 로드밸런서나 커넥션 풀 설정 필요
  • 커넥션 풀(HikariCP, DBCP 등)에서 제어 가능
    • Spring Boot/HikariCP 환경에서는 JDBC URL로 2개 이상 지정 가능

🔹 4. 실무 예시 (Spring Boot + HikariCP + MySQL)

 
spring: datasource: url: jdbc:mysql://10.10.10.1:3306,10.10.10.2:3306/mydb?autoReconnect=true&failOverReadOnly=false username: myuser password: mypass hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 30000

🔸 결론

  • JDBC 표준 자체는 단일 DB 커넥션만 다룸.
  • 하지만 MySQL, Oracle RAC 등 드라이버 레벨에서 2개 이상 DB 주소 지정 가능 → Redundancy 구성 가능.
  • 스프링 환경에서 HikariCP 등 커넥션 풀과 함께 설정하면 안정적 Failover 가능.

원하시면 제가 Spring Boot + HikariCP 기반으로
이중화(DB Failover) 구성 예제와 동작 시나리오를 다이어그램으로 그려서 보여드릴 수도 있어요.
그렇게 해드릴까요?

JDBC 드라이버 중 상당수는 2개뿐 아니라 3개 이상까지 DB 호스트를 지정할 수 있습니다.
다만 DBMS별 드라이버 지원 여부와 Failover 동작 방식을 구분해서 봐야 해요.

✅ 1. MySQL / MariaDB의 경우

  • 3개 이상 호스트 지정 가능 ✅
  • 예시:
 
jdbc:mysql://db1.example.com:3306,db2.example.com:3306,db3.example.com:3306/mydb ?autoReconnect=true &failOverReadOnly=false &retriesAllDown=3
  • 동작 방식:
    • db1 → 연결 시도 실패 → db2 → 실패 → db3
    • 순차적으로 시도하는 Failover 방식
  • 로드밸런싱 옵션도 제공:
 
jdbc:mysql:loadbalance://db1,db2,db3/mydb ?loadBalanceStrategy=roundRobin

✅ 2. Oracle RAC / Data Guard

  • 3개 이상 지원 ✅
  • 예시:
 
jdbc:oracle:thin:@(DESCRIPTION= (LOAD_BALANCE=ON) (FAILOVER=ON) (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=db1)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=db2)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=db3)(PORT=1521)) ) (CONNECT_DATA=(SERVICE_NAME=ORCL)) )
  • RAC나 Data Guard 환경에서는 3개 이상 호스트 지정이 흔함.

✅ 3. PostgreSQL

  • 3개 이상 지원 ✅
 
jdbc:postgresql://db1:5432,db2:5432,db3:5432/mydb?targetServerType=primary
  • 여러 호스트를 지정하면 자동 Failover 가능.

✅ 4. MSSQL (SQL Server)

  • AlwaysOn 클러스터를 사용하는 경우 3개 이상 지원 가능 ✅
  • 하지만 기본 단일 인스턴스 모드에서는 1개의 호스트만 권장.

🛠️ 정리

DBMS2개 이상3개 이상동작 방식
MySQL ✅ ✅ 순차 Failover 또는 Load Balancing
MariaDB ✅ ✅ MySQL과 동일
Oracle ✅ ✅ RAC/Data Guard 기반 Failover
PostgreSQL ✅ ✅ 순차 Failover 지원
MSSQL ⚠️ 일부 ✅ (AlwaysOn) 기본 단일 인스턴스는 제한적

🔹 결론

  • MySQL, MariaDB, Oracle, PostgreSQL → 3개 이상 호스트 지정 가능
  • 단순 장애 대비라면 JDBC URL에 , 로 여러 호스트를 나열
  • 로드밸런싱까지 필요하면 별도 옵션(loadbalance, roundRobin) 설정 필요
  • 스프링 환경에서는 HikariCP가 JDBC URL 그대로 인식하므로 설정만 잘하면 Failover 동작함

원하시면 Spring Boot + HikariCP + MySQL 환경에서
"3개 DB 호스트를 지정한 이중화 + 로드밸런싱"을 동시에 구성하는 실제 설정 예제와 동작 시퀀스 다이어그램을 그려드릴 수 있습니다.

실무 환경에서의 적용, 수집 방식, 분석 목적, 보안 고려사항 등을 종합적으로 이해해야 합니다. 아래에 TA(Technical Architect) 엔지니어 관점에서 필요한 내용을 구조화해서 정리해 드릴게요.

🔍 TELEMETRY 개념 정의

Telemetry란, 시스템 또는 장치에서 발생하는 데이터를 원격으로 자동 수집하고 전송하여 모니터링하거나 분석하는 기술입니다.
원래 항공/우주 분야에서 유래했지만, 현재는 IT 인프라, 클라우드, 애플리케이션, 보안 등 전산 전반에 적용됩니다.

🧠 주요 구성 요소

구성 요소설명
수집 대상(Source) 애플리케이션 로그, 인프라 상태, 사용자 행동, 네트워크 트래픽, 시스템 메트릭(CPU, 메모리 등)
수집 Agent Fluentd, Telegraf, Logstash, OpenTelemetry Agent 등
전송 방식 Push 방식, Pull 방식, Event streaming (Kafka), REST API 등
수집 서버(Sink) Elasticsearch, Prometheus, Azure Monitor, Datadog, Splunk 등
가공/분석 실시간 대시보드(Grafana 등), 이상 탐지, 예측 분석, 알람 설정

🧰 활용 분야 및 실무 적용 예시

분야Telemetry 활용
클라우드 모니터링 Azure Monitor, AWS CloudWatch에서 VM/컨테이너 성능 Telemetry 수집
MSA 관측성 확보 Istio, Envoy에서 Distributed Tracing + Metric + Log 통합 수집
CI/CD 배포 검증 배포 후 Telemetry로 사용자 반응, 에러율, 응답시간 추적
보안 관제(SIEM) 사용자 로그인 이상 탐지, 취약점 Telemetry 기반 경고 트리거
IoT/산업 자동화 센서/장비 상태 원격 모니터링 및 자동 경고/제어

🧱 기술 스택 및 표준

계층주요 기술
Agent/SDK OpenTelemetry, Fluentd, Telegraf, Metricbeat
수집/처리 Kafka, Logstash, Promtail, Vector
저장/조회 Elasticsearch, Prometheus, TimescaleDB
시각화 Grafana, Kibana, Azure Dashboard
경고/응답 Alertmanager, PagerDuty, OpsGenie

🛡️ 보안 및 컴플라이언스 고려사항

  • PII(개인 식별 정보) 또는 민감 정보는 수집 제외 또는 익명화 필요
  • 전송 시 TLS 암호화, API Key 인증 필수
  • 저장 기간/보존 정책은 GDPR, ISO 27001 등 준수 필요
  • 외부 솔루션 사용 시 전송 위치 및 리전 규정 검토 필요

📊 직무역량 평가 예상 문제

✅ 객관식 예시

Q. Telemetry 시스템 구성에서 수집된 데이터를 저장하고 시각화하는 구성요소로 가장 적절한 것은?
① SNMP
② LDAP
③ Grafana + Prometheus
④ Redis + NGINX
정답: ③

✅ 시나리오형 예시

문제:
신규 구축된 MSA 환경에서 서비스 간 호출 지연 문제가 발생하고 있습니다. 서비스 호출은 정상적이나 응답 시간이 평균보다 2배 이상 느려졌습니다.

질문:
Telemetry 기반으로 이 문제를 분석하기 위한 구성요소를 기술하고, 우선적으로 수집해야 할 Telemetry 종류 2가지를 기술하시오.

예상 답안 (요약):

  • 구성요소: OpenTelemetry Collector, Jaeger for tracing, Prometheus for metric
  • 우선 수집 대상: 서비스 간 Distributed Trace 정보, Response Time Metric

🧠 암기 카드 (핵심 요약)

  • Telemetry = 원격 데이터 수집 + 전송 + 분석
  • 구성: Source → Agent → Transport → Sink → 시각화/분석
  • 주요 툴: OpenTelemetry, Prometheus, Grafana, ELK
  • Push vs Pull 방식 구분
  • 보안: TLS 암호화, 익명화, 보존 정책 중요
  • MSA: Tracing + Logging + Metric 통합 필수
  • 활용: 성능 모니터링, 보안 탐지, SLA 분석 등

 

📘 TELEMETRY 직무역량 평가 문제집 (30문항)

✅ 객관식 문제 (1~20번)

NO.문제보기정답해설
1 Telemetry의 주요 목적 중 가장 적절한 것은? ① 트래픽 분산
② 시스템 자산 등록
③ 원격 모니터링
④ 스토리지 증설		 ③ Telemetry는 시스템의 상태나 동작 데이터를 수집하여 원격에서 모니터링하고 분석하는 기술이다.
2 Telemetry 시스템에서 로그 수집 Agent로 가장 많이 사용하는 오픈소스는? ① Apache
② Fluentd
③ Redis
④ Postfix		 ② Fluentd는 다양한 로그를 수집하고 전송할 수 있는 로그 수집 Agent로 Telemetry 구성에 자주 사용된다.
3 Prometheus는 어떤 데이터를 수집하는 도구인가? ① 메일
② 이벤트
③ 메트릭
④ 트레이스		 ③ Prometheus는 시계열 메트릭 데이터를 수집하는 데 특화된 오픈소스 도구이다.
4 Telemetry 데이터를 시각화하는 대표적인 도구는? ① Kibana
② Prometheus
③ Kafka
④ rsync		 ① Kibana는 Elasticsearch 데이터를 시각화하는 데 사용되는 도구이다.
5 OpenTelemetry의 주요 수집 데이터 범주가 아닌 것은? ① Logs
② Metrics
③ Traces
④ Images		 ④ OpenTelemetry는 Logs, Metrics, Traces를 중심으로 관측 데이터를 수집한다.
6 Telemetry 구성에서 데이터를 Push 방식으로 보내는 구조의 특징은? ① 데이터 수집 주기를 설정한다
② 서버가 직접 데이터를 가져간다
③ 에이전트가 데이터를 능동적으로 전송한다
④ API가 필요 없다		 ③ Push 방식은 Agent가 데이터를 직접 수집 서버에 전송한다.
7 Pull 방식의 Telemetry 구성 예시는? ① Fluentd → Kafka
② Prometheus → Node Exporter
③ Logstash → Elasticsearch
④ Envoy → Jaeger		 ② Prometheus는 Exporter에게 요청하여 데이터를 수집하는 Pull 방식이다.
8 Telemetry에서 Tracing의 주요 목적은? ① IP 차단
② 저장소 확장
③ 장애 추적
④ 트래픽 예측		 ③ Tracing은 MSA 환경에서 서비스 간 호출을 추적하여 병목 지점을 파악하는 데 사용된다.
9 Telemetry 보안 설정 시 고려해야 할 사항이 아닌 것은? ① TLS 암호화
② API 인증
③ 민감정보 필터링
④ 로그 데이터 압축		 ④ 압축은 저장 효율화 목적이지만, 보안과는 직접 관련이 없다.
10 Telemetry와 관련된 국제 표준 또는 개방형 프로젝트는? ① OpenTelemetry
② SNMPv2
③ GitOps
④ STIX		 ① OpenTelemetry는 CNCF에서 주도하는 관측 데이터 수집 표준 프로젝트이다.
11 다음 중 Telemetry 데이터를 저장하는 시계열 DB는? ① MySQL
② Redis
③ TimescaleDB
④ MongoDB		 ③ TimescaleDB는 PostgreSQL 기반의 시계열 DB이다.
12 Telemetry 데이터를 통해 분석할 수 없는 것은? ① CPU 부하
② 사용자 패턴
③ 서버 자산 목록
④ 트래픽 폭주		 ③ 자산 목록은 별도 CMDB를 통해 관리하며, Telemetry의 목적은 아니다.
13 MSA 환경에서 Telemetry의 필수 구성요소가 아닌 것은? ① Distributed Trace
② 메트릭 수집기
③ 공유 파일 시스템
④ 로그 집계기		 ③ 파일 공유는 Telemetry와 무관한 시스템 구성 요소이다.
14 Jaeger는 어떤 역할을 하는 Telemetry 도구인가? ① 로그 수집
② 보안 모니터링
③ 분산 추적
④ 이벤트 알림		 ③ Jaeger는 OpenTracing을 기반으로 분산 트레이싱 데이터를 수집하고 시각화하는 도구이다.
15 Telemetry의 이상 탐지 기능을 자동화하기 위한 기법은? ① Manual alert
② Static threshold
③ AI/ML 기반 알림
④ 로그 백업		 ③ 최근에는 ML 기반 이상 탐지 기법이 도입되고 있다.
16 Telemetry 수집 방식 중, Kafka를 활용한 방식은 어떤 특징이 있는가? ① Batch 처리만 가능
② REST API 중심
③ 실시간 이벤트 스트리밍
④ 클라이언트 Pull 방식		 ③ Kafka는 실시간으로 대량의 이벤트 데이터를 처리하는 데 최적화되어 있다.
17 Telemetry 도입 시 주로 고려하는 SLA 지표는? ① RPO
② RTO
③ 응답시간, 오류율
④ MTBF		 ③ Telemetry는 서비스의 응답시간, 에러율, 트랜잭션 성능 등을 측정하여 SLA 평가에 활용된다.
18 Azure Monitor는 어떤 유형의 Telemetry 수집 도구인가? ① SaaS 기반 통합 모니터링 플랫폼
② VPN 서비스
③ 네트워크 프로토콜
④ 스토리지 압축 솔루션		 ① Azure Monitor는 클라우드 기반 리소스의 Telemetry를 통합 수집하는 PaaS/SaaS 도구이다.
19 다음 중 Telemetry 수집 대상에 해당하지 않는 것은? ① CPU 사용률
② 로그 메시지
③ 파일 용량
④ 웹 페이지 콘텐츠		 ④ 콘텐츠 자체는 Telemetry 수집 대상이 아니다.
20 다음 중 Telemetry와 보안 로그를 함께 처리하는 시스템은? ① CMDB
② SIEM
③ NAS
④ DNS		 ② SIEM(Security Information and Event Management)은 보안 로그 및 Telemetry 데이터를 통합 분석한다.

✅ 시나리오형 문제 (21~30번)

NO.시나리오 문제정답 요약해설 요약
21 A사는 서비스 배포 후 장애가 자주 발생하며, 원인을 추적하기 어렵다. 이를 개선하기 위해 도입할 수 있는 Telemetry 구성 요소는? Distributed Tracing, Metric 수집기 Tracing을 통해 마이크로서비스 호출 흐름을 추적할 수 있어 장애 원인 분석이 용이하다.
22 CPU 사용률은 30% 수준이나 사용자 응답이 느릴 경우 어떤 Telemetry 데이터를 추가로 수집해야 하는가? Application 응답시간, DB 쿼리 지연 CPU 외에도 App 레벨 메트릭, DB 성능 등이 병목 원인이 될 수 있다.
23 Kafka를 Telemetry 파이프라인에 도입 시 얻을 수 있는 장점 2가지를 설명하시오. 고속 처리, 수평 확장성 Kafka는 대규모 이벤트 스트리밍을 고가용성, 확장 가능한 구조로 처리 가능하다.
24 OpenTelemetry 기반 수집 아키텍처를 구성하시오. App → SDK/Agent → Collector → Backend Collector는 다양한 Signal을 수집하여 Backend로 전송하는 허브 역할이다.
25 외부 파트너에게도 Telemetry 데이터를 제공해야 할 경우 보안적으로 고려할 사항은? 인증/인가 설정, 민감 정보 필터링, TLS 적용 외부 공개 시 암호화 및 권한 제어가 필수적이다.
26 로그 기반 Telemetry만 수집 중인 시스템에서 지연 원인 파악이 어려운 경우, 어떤 데이터를 추가 수집하면 좋은가? 트레이스(Trace) 데이터 로그는 정적인 정보이므로, 흐름을 추적하기 위한 Trace가 필요하다.
27 사용자 접속 증가에 따른 시스템 과부하 징후를 조기 감지하려면 어떤 메트릭 기반 알람이 필요한가? CPU/Memory 사용률, 트래픽 증가율 리소스 사용률 기반의 알람을 통해 선제적 대응 가능하다.
28 Telemetry Agent가 장애로 인해 데이터를 전송하지 못할 경우의 처리 방안은? 로컬 임시 저장 후 재전송(Retry Buffer) 장애 시 데이터를 유실하지 않기 위한 큐/버퍼 설계가 중요하다.
29 MSA 환경에서 서비스 간 호출에 실패율이 증가했다면 어떤 관측 지표를 분석할 것인가? 에러율, 재시도 횟수, 트레이스 에러 노드 각 마이크로서비스 호출 간 연결 실패를 추적해 병목 위치 파악 가능
30 시계열 Telemetry 데이터 저장소 선택 시 고려해야 할 요소 2가지는? 압축 성능, 쿼리 응답 속도 시계열 DB는 저장량이 많고 분석 주기가 짧기 때문에 성능이 핵심이다.

🧠 TELEMETRY 암기카드 요약

키워드설명
Telemetry 원격 시스템 데이터 수집/전송/분석 기술
Push 방식 Agent가 주기적으로 서버로 전송
Pull 방식 서버가 수집 대상을 직접 조회
OpenTelemetry Logs, Metrics, Traces 통합 수집 표준
Prometheus Metric 수집 및 시계열 저장소
Jaeger 분산 Trace 수집 및 시각화 도구
Fluentd 로그 수집 에이전트
Grafana 시각화 도구 (Prometheus/Elasticsearch 등과 연동)
Kafka 실시간 이벤트 스트리밍 플랫폼
SIEM 보안 이벤트 + Telemetry 분석 시스템
TLS 데이터 전송 암호화
Exporter Telemetry 대상에 대한 수집기 (ex. Node Exporter)
Collector 다양한 Signal 수집 후 전송 (OpenTelemetry 구성요소)
Alertmanager Prometheus와 연동된 알림 처리 도구

🔍 블로그용 키워드 인덱스 요약

 
#TELEMETRY #관측성 #OpenTelemetry #TelemetryPush방식 #TelemetryPull방식 #Fluentd #Prometheus #Jaeger #Trace분석 #MSA관측성 #KafkaTelemetry #SIEM #Metric수집 #로그분석 #TLS암호화 #TelemetryAlert #Grafana대시보드 #AzureMonitor #Telemetry시나리오 #Telemetry문제집 #TA역량평가

CI/CD (Continuous Integration / Continuous Deployment) 개념과 실무 활용 능력은 단순한 개념 암기 수준을 넘어서, 아키텍처 구성, 트러블슈팅, 보안/품질 통제, DevOps 문화 이해까지 포함합니다. 아래에 직무역량 평가 대비용으로 구성한 정리와 문제 예시를 함께 제공하겠습니다.

📌 CI/CD 핵심 개념 정리 (TA 직무역량 기준)

1. CI (지속적 통합: Continuous Integration)

  • 개발자들이 변경한 코드를 자주 통합하고 자동 빌드/테스트하는 프로세스
  • 주요 툴: Git, Jenkins, GitHub Actions, GitLab CI, CircleCI
  • 핵심 활동:
    • PR(풀리퀘스트) 발생 시 자동 빌드 및 유닛 테스트 수행
    • 코드 퀄리티 검사 (SonarQube, ESLint 등)
    • 아티팩트 생성 (jar, docker image 등)

2. CD (지속적 배포 or 지속적 전달)

  • 지속적 전달(Delivery): 운영 배포 직전까지 자동화 (staging까지 자동)
  • 지속적 배포(Deployment): 운영 환경까지 자동화 (무중단 배포 포함)
  • 주요 기법:
    • Blue-Green 배포
    • Canary 배포
    • Rolling Update
    • Helm, Kustomize, ArgoCD 등 활용

3. CI/CD 파이프라인 구성 요소

  • Source: Git, SVN
  • Build: Maven, Gradle, npm
  • Test: JUnit, Selenium, JMeter
  • Package: Docker
  • Deploy: Kubernetes, Ansible, Terraform, ArgoCD

📂 실무 중심 체크포인트 (TA 평가 대비)

항목상세
보안 강화 Secrets 관리 (예: GitHub Actions의 Secrets, HashiCorp Vault, Sealed Secrets)
품질 보장 Static Code Analysis, 테스트 커버리지, 보안 스캔(SonarQube, Trivy)
속도 최적화 병렬 빌드, 캐시 사용 (actions/cache), selective job 실행
장애 대응 배포 실패 시 롤백 전략, 상태 확인 프로브 사용, 알림 설정
IaC 연계 Terraform, Ansible과 CI/CD 연계로 환경 자동 구성
GitOps 모델 Git → Source of Truth로 하여 ArgoCD로 배포 동기화

🧠 직무역량 평가 예상문제 (객관식 + 시나리오형 혼합)

✅ 객관식 문제 예시

문항 1) 다음 중 CI/CD 파이프라인에서 Test 단계에 해당하는 작업은?
① Docker 이미지 빌드
② JMeter로 부하 테스트 수행
③ GitHub 커밋
④ Helm으로 배포 수행
→ 정답: ②

문항 2) 다음 중 GitOps 모델에 해당하는 툴은?
① Jenkins
② ArgoCD
③ Terraform
④ Nexus
→ 정답: ②

문항 3) 다음 중 무중단 배포 기법으로 적절한 것은?
① A/B 테스팅
② Blue-Green 배포
③ 패치 릴리즈
④ Build 시 lint 적용
→ 정답: ②

✅ 시나리오 기반 문제 예시

문항 7)
현재 운영 중인 서비스는 Kubernetes 상에서 ArgoCD를 통해 배포되고 있으며, Canary 배포 전략을 사용 중이다. 신규 기능 배포 이후 일부 사용자에게 오류가 발생했다.
가장 적절한 조치 방안은?
→ 정답: Canary 배포 중인 신규 리비전을 롤백하고, 오류 로그를 분석하여 수정한 후 재배포한다.

문항 8)
CI 단계에서 SonarQube 코드 스캔 결과, 심각한 보안 취약점이 발견되어도 배포가 진행되고 있다. 개선을 위한 조치로 적절한 것은?
① 스캔을 제거하고 배포 속도를 높인다.
② 스캔 결과를 단순 보고서로만 활용한다.
③ 빌드 실패 조건에 심각도 기준을 추가한다.
④ 스캔 결과를 저장소에 커밋한다.
→ 정답: ③

🧾 암기카드 요약 (Ctrl+F용 키워드)

  • CI: 지속적 통합, 자동 빌드, 유닛 테스트
  • CD: 지속적 배포, Blue-Green, Canary
  • GitOps: ArgoCD, Declarative 배포
  • 빌드 도구: Maven, Gradle
  • 배포 툴: Helm, Kustomize, ArgoCD
  • 보안 도구: Vault, Sealed Secrets, Trivy
  • 품질 관리: SonarQube, 테스트 커버리지
  • 배포 전략: Rolling, Blue-Green, Canary
  • 장애 대응: 롤백, 알림, 상태 체크(Probe)
  • 속도 최적화: 캐시, 병렬 빌드
  • 연계 자동화: Terraform, Ansible, Docker
  • GitHub Actions 구성요소: Workflow, Job, Step, Runner

📌 보완 학습 추천 

영역내용
GitHub Actions 고급 구성 Matrix 빌드, Environment Protection Rules, Manual Trigger
보안 위협 대응 Supply Chain 공격 대응 방안 (예: SLSA, Sigstore)
멀티 클러스터 배포 K8s 멀티 클러스터 + ArgoCD Sync
GitOps 정책 관리 ArgoCD Sync Policy, Drift 감지, RBAC 설정
실전 장애 조치 배포 실패 시 Previous Revision Rollback, 상태 Probe 설정

 

📘 CI/CD 실무 시나리오 기반 문제집 (총 25문항)

🔹 문항 01 (중)

Q. 개발자가 GitHub에 코드를 Push했는데 Jenkins 빌드가 자동으로 실행되지 않았다.
Webhooks 설정은 되어 있다. 가장 먼저 확인해야 할 사항은?

✅ 정답: GitHub Webhook URL과 Jenkins Job Trigger 설정 일치 여부
💡 해설: Webhook URL 오탈자나, Jenkins Job이 Push 이벤트를 수신하도록 설정되지 않으면 트리거되지 않음.

🔹 문항 02 (하)

Q. Jenkins Pipeline 중 Docker 빌드 단계에서 다음 오류 발생: permission denied while trying to connect to the Docker daemon socket
어떤 설정이 잘못되었는가?

✅ 정답: Jenkins 실행 계정이 docker 그룹에 포함되지 않음
💡 해설: Docker 명령어는 /var/run/docker.sock 접근 권한이 필요함.

🔹 문항 03 (중)

Q. GitHub Actions에서 actions/cache를 사용 중인데도 매번 npm install 시간이 오래 걸린다. 원인으로 가장 적절한 것은?

✅ 정답: cache key 설정이 변경되어 매번 캐시 미스 발생
💡 해설: key 값이 변경되면 기존 캐시를 사용하지 못함. restore-keys도 설정 필요.

🔹 문항 04 (중)

Q. ArgoCD에서 앱이 계속 ‘OutOfSync’ 상태로 표시된다. 가장 가능성 높은 원인은?

✅ 정답: Git 저장소와 K8s 클러스터 상태 불일치
💡 해설: GitOps 방식에서는 Git이 Source of Truth이며, 수동 변경 시 Drift 발생.

🔹 문항 05 (중)

Q. Jenkins 빌드 완료 후 Docker Hub로 푸시가 실패한다. 에러는 unauthorized: authentication required이다. 해결 방안은?

✅ 정답: Docker Hub 로그인 credential 설정 확인
💡 해설: Jenkins에서 Docker push를 위해 credential binding 필요

🔹 문항 06 (중)

Q. Canary 배포 중 신규 버전에 오류가 발견되었다. 즉시 조치로 적절한 것은?

✅ 정답: Canary 트래픽을 0%로 줄이고 이전 버전으로 롤백
💡 해설: Canary는 점진 배포 방식이므로 트래픽 분산 제어 가능

🔹 문항 07 (상)

Q. Jenkins에서 SonarQube 분석 후 코드 품질 게이트에 실패했는데도 파이프라인이 성공으로 종료된다. 원인은?

✅ 정답: sonar.qualitygate.wait=true 설정이 빠졌음
💡 해설: 품질 게이트를 빌드 실패 조건으로 인식하려면 설정 필요

🔹 문항 08 (상)

Q. CI/CD 파이프라인 중, staging 환경 배포는 성공했으나 운영 배포는 무시되었다. GitHub Actions를 사용 중이다. 어떤 설정이 필요할까?

✅ 정답: environment protection rule 설정에서 승인자가 없거나 조건 미충족
💡 해설: 운영 환경은 Manual Approval이나 조건 설정 필요

🔹 문항 09 (중)

Q. Helm 배포 시 다음 오류 발생: Error: UPGRADE FAILED: "my-app" has no deployed releases. 원인은?

✅ 정답: 처음부터 upgrade 명령 사용 (install이 아님)
💡 해설: 처음 설치 시에는 helm install, 이후부터 upgrade 사용

🔹 문항 10 (하)

Q. Kubernetes에서 CI/CD로 배포된 앱이 지속적으로 재시작된다. CrashLoopBackOff 상태가 반복된다. 원인은?

✅ 정답: readinessProbe 설정 실패로 재기동 발생
💡 해설: 준비되지 않은 상태로 트래픽을 받으면 재시작될 수 있음

🔹 문항 11 (중)

Q. GitOps 배포 시 Git에는 배포 YAML이 정상 등록되어 있으나 실제 클러스터에는 적용되지 않는다. 가장 가능성 높은 원인은?

✅ 정답: ArgoCD sync policy가 manual로 설정되어 있음
💡 해설: auto sync를 설정하지 않으면 자동 반영되지 않음

🔹 문항 12 (상)

Q. 빌드 파이프라인에서 SCA(Software Composition Analysis) 결과 보안 이슈가 감지되었으나, 개발자가 무시하고 운영 반영했다. 개선 방안은?

✅ 정답: 보안 등급 기준으로 배포 차단 조건 설정
💡 해설: Trivy, Anchore 등의 취약점 스캔을 Quality Gate로 연동

🔹 문항 13 (중)

Q. Jenkinsfile 내 parallel 블록이 병렬로 수행되지 않고 순차 실행된다. 원인은?

✅ 정답: 해당 agent 설정이 공유 executor 제한
💡 해설: 각 Job 실행 환경이 격리되어야 병렬 처리 가능

🔹 문항 14 (중)

Q. Terraform을 통해 클라우드 리소스를 생성 중인데, 기존 자원 삭제 경고가 나타난다. 주의사항은?

✅ 정답: terraform plan에서 Drift 여부를 검토
💡 해설: 수동 변경 → Terraform이 상태 불일치로 판단하고 삭제 시도

🔹 문항 15 (상)

Q. 동일 서비스에 대해 staging과 production 환경의 인프라 구성이 달라 배포 실패가 자주 발생한다. 개선 방안은?

✅ 정답: 환경별 IaC 코드 및 Manifest를 모듈화하여 통일성 유지
💡 해설: Kustomize, Helm values 파일 등으로 환경별 구성 추상화

🔹 문항 16 (상)

Q. Jenkins 서버의 master 노드 디스크가 가득 차 빌드가 실패했다. 예방 방안은?

✅ 정답: 워크스페이스 정리 및 외부 스토리지로 artifact 분리
💡 해설: 빌드 캐시, 로컬 저장물 등을 주기적으로 정리

🔹 문항 17 (중)

Q. CI 파이프라인에서 테스트 커버리지가 계속 낮게 나와 배포가 차단된다. 해결 방안은?

✅ 정답: 테스트 코드 보강 후 커버리지 리포트 연동 검증
💡 해설: Jacoco, Coverage.py 등을 통해 커버리지 기준 적용 가능

🔹 문항 18 (상)

Q. Helm을 이용한 배포에서 일부 노드에서만 배포 실패가 발생한다. 무엇을 점검해야 할까?

✅ 정답: nodeSelector 또는 taint 설정 불일치
💡 해설: 노드 선택 조건이 일치하지 않으면 배포 불가

🔹 문항 19 (하)

Q. GitHub Actions 실행 중 다음 메시지가 출력됨: job was skipped due to condition. 원인은?

✅ 정답: if 조건이 false로 평가됨
💡 해설: 브랜치 조건이나 변수 조건을 확인

🔹 문항 20 (중)

Q. ArgoCD 배포 후 5분 내 모든 pod가 다시 생성되었다. 가장 가능성 높은 원인은?

✅ 정답: ConfigMap 변경에 따른 rollout 트리거
💡 해설: Deployment에는 ConfigMap 변경을 감지하는 메커니즘이 포함되어야 함

🔹 문항 21 (상)

Q. GitHub Actions 워크플로우가 트리거되지 않는다. 다음 중 가능성 높은 원인은?

✅ 정답: on: 이벤트 설정이 push가 아닌 다른 이벤트로 지정됨
💡 해설: 워크플로우 트리거 조건을 반드시 확인해야 함

🔹 문항 22 (중)

Q. Jenkins 빌드 히스토리를 장기 보관하고 싶다. 적절한 설정은?

✅ 정답: buildDiscarder 설정에서 보관 일수 및 횟수 증가
💡 해설: 기본 설정은 자동 삭제되므로 보관 조건 명시 필요

🔹 문항 23 (상)

Q. GitOps 방식에서 Rollback이 필요한 경우, 가장 바람직한 절차는?

✅ 정답: Git에서 이전 커밋으로 revert 후 ArgoCD가 자동 반영하도록 유도
💡 해설: Git이 Source of Truth이므로 직접 클러스터 변경은 권장하지 않음

🔹 문항 24 (중)

Q. Jenkins slave 노드가 자주 연결 끊김 상태가 된다. 가장 먼저 확인할 것은?

✅ 정답: SSH 연결 설정 및 KeepAlive 옵션
💡 해설: Jenkins와 slave 간 연결은 주로 SSH로 유지됨

🔹 문항 25 (상)

Q. 운영 배포 후 즉시 사용자 장애 신고가 접수됐다. CI/CD 측면에서 가장 먼저 점검할 항목은?

✅ 정답: 최근 배포 내역과 변경된 코드/환경 변수 비교
💡 해설: 코드나 설정이 운영 반영되었는지 확인하는 것이 가장 빠름

🧠 CI/CD 실무 시나리오 암기카드 요약

🧾 키워드📌 요약 설명
Webhook 미작동 GitHub Webhook URL과 Jenkins Job Trigger 설정 확인
Docker socket 에러 Jenkins 계정이 docker 그룹에 포함되어야 함
npm 캐시 미사용 cache key가 변경되면 캐시 미스 발생
ArgoCD OutOfSync Git과 클러스터 간 상태 불일치 발생
Docker push 실패 Jenkins의 Docker Hub 로그인 자격 증명 필요
Canary 오류 조치 트래픽 0%로 줄이고 롤백 수행
품질게이트 무시 sonar.qualitygate.wait=true 설정 누락
운영 자동배포 안됨 GitHub Actions 환경 승인 조건 확인
Helm upgrade 실패 최초 배포는 install 명령 필요
CrashLoopBackOff readinessProbe 실패 시 재시작 발생
GitOps 반영 안됨 ArgoCD auto sync 설정 확인
보안 취약 무시 배포 SCA 결과를 Quality Gate로 연결
Jenkins 병렬 미작동 agent의 executor 제한 확인
Terraform Drift terraform plan으로 삭제 경고 원인 확인
환경 불일치 배포 실패 Helm/Kustomize로 환경 모듈화 필요
디스크 가득참 워크스페이스 정리 및 외부 저장소 분리 필요
커버리지 미달 테스트 코드 보강, 커버리지 기준 적용
노드별 배포 실패 nodeSelector 또는 taint 조건 확인
GitHub Actions skip if 조건 false로 평가됨
ConfigMap 변경 시 재배포 rollout 트리거 연동 필요
워크플로우 미작동 on: 트리거 이벤트 확인
Jenkins 빌드 보관 buildDiscarder 설정 변경
GitOps 롤백 Git revert → ArgoCD auto sync 유도
Jenkins Slave 끊김 SSH keepalive 설정 확인
운영 장애 발생 시 최근 배포 내역 및 환경변수 변경사항 우선 확인

Container Management는 컨테이너 기반 애플리케이션을 효율적으로 배포·운영·스케일링·모니터링·종료하는 전반적인 활동을 의미합니다. 역량향상을 위해 단순 컨테이너 실행을 넘어서 전체 Lifecycle 관리와 운영 자동화, 보안 통제, 리소스 최적화 등을 포괄합니다.

🔷 1. 컨테이너(Container) 개요

  • 컨테이너란?
    • 애플리케이션과 그 실행 환경(Library, Config, Dependency 등)을 패키징한 실행 단위
    • 프로세스 단위로 격리됨 (OS 공유)
    • 빠른 시작, 작은 사이즈, 이식성 강조
    • 예시: Docker, Containerd, Podman
  • 이미지 vs 컨테이너
    • 이미지(Image): 불변의 템플릿, 컨테이너 실행 단위
    • 컨테이너(Container): 이미지 기반으로 실제 실행 중인 인스턴스

🔷 2. Container Management 주요 구성요소

구성요소설명
이미지 관리 버전, 용량, 캐시, 저장소(Registry: ACR, DockerHub 등)
컨테이너 실행/중지 컨테이너 시작, 중단, 재시작, 로그확인 등
오케스트레이션 Kubernetes, Docker Swarm 등
모니터링 로그 수집, 리소스 사용량, 헬스 체크
보안 이미지 서명, 취약점 스캔, 네트워크 격리, Policy 적용
네트워크 컨테이너 간 통신(CNI), 외부 노출(Ingress, LoadBalancer 등)
스토리지 영속 볼륨 (Volume, PV/PVC, NFS, Ceph 등)

🔷 3. 오케스트레이션 도구 (Kubernetes 중심)

✅ Kubernetes가 대표적

  • 자동 복구 (Self-healing): 컨테이너 장애 시 자동 재시작
  • 수평 스케일링: 리소스/트래픽에 따라 Pod 수 자동 조절
  • 롤링 업데이트/롤백
  • 서비스 디스커버리 및 로드밸런싱
  • 네임스페이스 기반 멀티 테넌시
  • Helm / Kustomize: 배포 자동화 템플릿

🔷 4. 실무 관점의 Container Management 포인트 (TA 관점)

관리 포인트체크리스트 예시
리소스 최적화 CPU/MEM Request/Limits 설정, HPA 적용
배포 자동화 GitOps, CI/CD, ArgoCD
보안 강화 PodSecurityPolicy, NetworkPolicy, Runtime 보안(e.g. Falco)
모니터링 및 로깅 Prometheus+Grafana, ELK/EFK Stack
장애 대응 시나리오 Pod CrashLoop, ImagePullBackOff, OOMKilled 분석 등
멀티 클러스터 운영 클러스터 페더레이션, Cluster API
온프레미스 ↔ 클라우드 연동 하이브리드 운영 (예: Azure Arc, Anthos)

🔷 5. Container Lifecycle

 
graph TD; 이미지생성 --> 이미지저장; 이미지저장 --> 컨테이너실행; 컨테이너실행 --> 모니터링; 모니터링 --> 스케일링; 스케일링 --> 업데이트; 업데이트 --> 종료처리; 종료처리 --> 정리및로그보존;

🔷 6. 관련 도구와 기술

  • 런타임: Docker, containerd, CRI-O
  • Registry: DockerHub, Harbor, Azure Container Registry (ACR)
  • CI/CD: GitHub Actions, GitLab, Jenkins, ArgoCD
  • 보안: Trivy, Clair, Prisma Cloud, Falco
  • 네트워크: Calico, Cilium (eBPF 기반)
  • 스토리지: CSI, Ceph, Longhorn, NFS

🔷 7. 요약 암기카드 (한 줄 키워드)

  • 컨테이너는 경량 실행환경 (VM과 다름)
  • 관리 핵심은 Lifecycle + 자동화
  • Kubernetes = 오케스트레이션의 표준
  • 이미지 → 컨테이너 → 배포 → 모니터링 → 종료
  • CI/CD + GitOps + Helm = 자동화 필수
  • 보안은 Image Scanning + 네트워크 격리 + 정책제어
  • HPA/VPA, Node Affinity, Toleration = 리소스 운영기술
  • 장애 분석 시 Pod 상태 (kubectl describe, logs) 중요

추가 요청 가능:

  • ✅ [ ] TA 시험 대비 문제집 (객관식/시나리오 기반)
  • ✅ [ ] Azure ACR + AKS 기반 실무 설계
  • ✅ [ ] Kubernetes 네트워크 or 스토리지 중심 실무 시나리오
  • ✅ [ ] GitOps 기반 Container 관리 전략 (ArgoCD, Flux 등)

 

🧠 [Container Management – 20문항]

(난이도: 상/중/하 표기)

✅ NO.01 (객관식 · 난이도: 하)

컨테이너에 대한 설명으로 옳은 것은?
① VM과 달리 각 컨테이너는 독립된 커널을 사용한다.
② 컨테이너는 완전한 가상화로, 하이퍼바이저 기반으로 동작한다.
③ 컨테이너는 Host OS의 커널을 공유하며, 프로세스 수준에서 격리된다.
④ 컨테이너는 별도 운영체제를 포함하므로 부팅 시간이 오래 걸린다.

정답: ③
해설:
컨테이너는 VM과 달리 Host의 커널을 공유하며 프로세스 단위로 격리되어 경량화된 실행 환경을 제공합니다.

✅ NO.02 (객관식 · 난이도: 중)

다음 중 Kubernetes에서 컨테이너 이미지 배포와 관련된 구성요소는?
① ConfigMap
② Deployment
③ HPA
④ NodePort

정답: ②
해설:
Deployment는 애플리케이션의 선언적 배포를 담당하며, 이미지 버전 관리, 롤링 업데이트 등 기능을 포함합니다.

✅ NO.03 (객관식 · 난이도: 상)

다음 중 Kubernetes에서 컨테이너 장애 복구를 자동으로 수행하는 기능은?
① Liveness Probe
② Horizontal Pod Autoscaler
③ ReplicaSet
④ DaemonSet

정답: ①
해설:
Liveness Probe는 애플리케이션의 상태를 주기적으로 확인해 실패 시 컨테이너를 재시작합니다.

✅ NO.04 (시나리오 · 난이도: 중)

시나리오:
운영 중인 Kubernetes 클러스터에서 특정 애플리케이션의 메모리 사용량이 점점 증가하여 OOMKilled가 발생했다.
Q: 해결을 위한 가장 우선적인 조치는?

① Pod의 수를 늘려 트래픽 분산을 시도한다.
② Resource limits를 제거해 더 많은 메모리를 할당한다.
③ Pod의 메모리 limits 값을 점검하고, 적절히 조정한다.
④ 컨테이너의 로그를 삭제한다.

정답: ③
해설:
메모리 부족(OOMKilled)은 컨테이너에 설정된 limits 값을 초과할 때 발생하므로, 이를 적절히 재조정해야 합니다.

✅ NO.05 (객관식 · 난이도: 중)

컨테이너 이미지 보안 취약점 스캔 도구로 적절한 것은?
① Prometheus
② Trivy
③ Fluentd
④ Istio

정답: ②
해설:
Trivy는 이미지 및 Git 리포지토리의 취약점을 스캔하는 대표적인 보안 도구입니다.

✅ NO.06 (시나리오 · 난이도: 상)

시나리오:
당신의 팀은 Dev 환경에서 Kubernetes에 blue-green deployment 전략을 도입하고자 한다.
Q: 이 전략의 주요 목적은?

① Pod에 부하를 분산시켜 리소스를 효율화
② 업데이트 시 무중단 배포 및 롤백의 용이성 확보
③ 서비스 포트를 자동으로 할당
④ 서비스 간의 DNS 해석 지연을 줄임

정답: ②
해설:
Blue-Green Deployment는 기존 버전과 신규 버전을 동시에 유지하다가 트래픽을 전환함으로써 무중단 배포를 가능하게 합니다.

✅ NO.07 (객관식 · 난이도: 하)

다음 중 Kubernetes에서 영속 데이터를 저장하기 위한 구성 요소는?
① Pod
② Service
③ PersistentVolume
④ ConfigMap

정답: ③
해설:
PersistentVolume(PV)는 컨테이너가 종료되더라도 유지되는 스토리지 볼륨입니다.

✅ NO.08 (객관식 · 난이도: 중)

Kubernetes 네트워크 정책(NetworkPolicy)의 목적은?
① Pod 간의 통신 속도 향상
② 특정 Pod 간 통신 제어 및 격리
③ 클러스터 IP 자동 할당
④ 노드 간 트래픽 암호화

정답: ②
해설:
NetworkPolicy는 Pod 간 네트워크 접근을 제어하여 보안을 강화합니다.

✅ NO.09 (시나리오 · 난이도: 상)

시나리오:
컨테이너가 외부 API 호출 시 간헐적으로 Connection Refused 에러가 발생한다.
Q: 가장 먼저 확인해야 할 사항은?

① 컨테이너의 DNS 캐시 초기화 여부
② 외부 API 서버의 인증서 유효성
③ 컨테이너의 네트워크 정책 및 egress 설정
④ 이미지 레이어의 용량 초과 여부

정답: ③
해설:
NetworkPolicy의 egress 제한 설정으로 인해 외부 통신이 차단될 수 있습니다.

✅ NO.10 (객관식 · 난이도: 중)

컨테이너 기반 DevOps에서 GitOps 도구로 적합한 것은?
① ArgoCD
② Jenkins
③ Terraform
④ Prometheus

정답: ①
해설:
ArgoCD는 Git 저장소 상태를 기준으로 Kubernetes 상태를 자동 동기화하는 GitOps 도구입니다.

(계속됩니다...)
👉 다음 메시지에 11~20번 문제 + 요약/정리 + PDF 변환 안내 포함해드릴게요.
계속 진행할까요?

 

 

✅ NO.11 (객관식 · 난이도: 하)

컨테이너 런타임 중 Kubernetes에서 기본적으로 사용하는 런타임은?
① Docker
② Podman
③ containerd
④ runc

정답: ③
해설:
Kubernetes는 v1.20 이후 Docker 대신 containerd 또는 CRI-O를 기본 런타임으로 사용합니다.

✅ NO.12 (객관식 · 난이도: 중)

Kubernetes의 Init Container에 대한 설명으로 올바른 것은?
① 메인 컨테이너와 동시에 실행된다.
② Init 컨테이너 실패 시 메인 컨테이너가 자동 시작된다.
③ Init 컨테이너는 완료되어야 메인 컨테이너가 시작된다.
④ Init 컨테이너는 Kubernetes 1.20부터 제거되었다.

정답: ③
해설:
Init Container는 메인 컨테이너가 시작되기 전에 실행되며, 준비 작업을 수행하는 데 사용됩니다.

✅ NO.13 (시나리오 · 난이도: 중)

시나리오:
컨테이너에 설정된 readOnlyRootFilesystem: true로 인해 애플리케이션이 로그를 쓰지 못해 장애가 발생했다.
Q: 이 문제 해결을 위한 조치는?

① root 파일 시스템을 RW로 변경하지 않고, /tmp 디렉토리에 로그를 기록하도록 수정한다.
② readOnlyRootFilesystem을 false로 바꾼다.
③ 로그 기능을 제거한다.
④ init 컨테이너를 사용해 log 폴더를 먼저 생성한다.

정답: ①
해설:
보안 강화를 유지하면서도 /tmp, emptyDir 등 쓰기 가능한 마운트를 제공하는 것이 최선의 조치입니다.

✅ NO.14 (객관식 · 난이도: 중)

Kubernetes의 ConfigMap과 Secret의 주요 차이점은?
① ConfigMap은 TLS를 지원하고 Secret은 그렇지 않다.
② Secret은 base64 인코딩으로 민감 정보를 저장한다.
③ ConfigMap은 PersistentVolume에 저장된다.
④ Secret은 Pod 간 공유할 수 없다.

정답: ②
해설:
Secret은 암호, 인증키 등의 민감정보를 base64 인코딩하여 저장하며, ConfigMap은 일반 설정 정보를 저장합니다.

✅ NO.15 (시나리오 · 난이도: 상)

시나리오:
Production 환경에서 Pod가 수시로 CrashLoopBackOff 상태가 발생한다.
kubectl logs 명령으로는 확인되지 않고, describe pod에는 OOMKilled 표시가 있다.
Q: 이 때 취해야 할 적절한 두 가지 조치는?
(복수 정답)

① Pod의 limits.memory 값을 재조정
② HPA를 설정하여 Pod 수 증가
③ 로그 수집기를 재설정
④ Prometheus 등으로 메모리 사용량 분석

정답: ①, ④
해설:
OOMKilled는 메모리 부족 시 발생하므로 리소스 설정과 모니터링 지표 확인이 필요합니다.

✅ NO.16 (객관식 · 난이도: 중)

Pod 간 통신 제어를 위해 Kubernetes에서 사용하는 기능은?
① RBAC
② PSP
③ NetworkPolicy
④ CNI

정답: ③
해설:
NetworkPolicy는 Pod 간 트래픽을 제어해 보안을 강화합니다. CNI는 플러그인 인터페이스일 뿐 정책은 아닙니다.

✅ NO.17 (객관식 · 난이도: 상)

컨테이너 이미지의 용량을 줄이기 위한 방법으로 적절한 것은?
① Scratch 또는 Alpine 기반 이미지 사용
② 다단계 빌드(Multi-stage build) 사용
③ 불필요한 layer 제거
④ 모두 해당

정답: ④
해설:
경량 이미지, 다단계 빌드, 레이어 최적화는 모두 이미지 용량 최적화에 효과적입니다.

✅ NO.18 (시나리오 · 난이도: 상)

시나리오:
Azure ACR에 저장된 컨테이너 이미지를 AKS 클러스터에서 pull 하려 하였으나 ImagePullBackOff 오류가 발생했다.
Q: 가장 가능성 높은 원인과 조치방안은?

① 이미지가 삭제됨 → 재업로드
② ACR 권한 누락 → AKS에 pull permission 부여
③ Pod IP 충돌 → Cluster 재생성
④ 노드 디스크 부족 → 노드 수 증가

정답: ②
해설:
ACR은 프라이빗 Registry로, AKS에서 접근하려면 Managed Identity 또는 imagePullSecrets 설정이 필요합니다.

✅ NO.19 (객관식 · 난이도: 상)

다음 중 GitOps 전략의 핵심이 아닌 것은?
① 선언형 배포 방식
② Git 저장소와 클러스터 상태 동기화
③ 운영자가 수동으로 kubectl apply
④ 자동화된 Sync 및 Drift 감지

정답: ③
해설:
GitOps는 Git 저장소를 단일 진실 소스로 사용하고 자동으로 클러스터와 동기화합니다.

✅ NO.20 (시나리오 · 난이도: 상)

시나리오:
컨테이너 운영 중, 특정 애플리케이션이 외부 DB에 연결 시 DNS 해석 실패 오류가 발생하였다.
다른 애플리케이션은 정상 동작 중이다.
Q: 어떤 조치를 먼저 해야 하는가?

① CoreDNS 로그 확인 및 캐시 초기화
② DB 서버 재부팅
③ 애플리케이션 재배포
④ kube-proxy 설정 확인

정답: ①
해설:
컨테이너 DNS 문제는 CoreDNS의 캐시 문제일 수 있으며, 로그 확인 및 Pod 재시작으로 해결 가능합니다.

📌 전체 요약 정리

분류키워드설명 요약
컨테이너 기초 경량화, OS공유 VM과 달리 커널 공유, 빠른 실행
오케스트레이션 Kubernetes 자동복구, 롤링 업데이트, HPA
리소스 관리 Limits/Requests 설정 미비 시 OOMKilled 등 발생
보안 readOnly FS, Secret, PSP 컨테이너 보안 설정 및 접근 제어
이미지 최적화 Alpine, Multi-stage 이미지 용량 축소
네트워크 NetworkPolicy, CNI Pod 간 통신 제어 및 격리
스토리지 PV/PVC 데이터 영속성 확보
배포 전략 Blue-Green, GitOps 무중단 배포 및 Git 기반 운영
실무장애 대응 CrashLoop, DNS 오류 로그, describe, CoreDNS 분석 등

아래는 Container 환경의 실전 장애 대응 시나리오 기반 문제집입니다. 총 30문항, 모든 문제는 장애 상황 → 원인 분석 → 해결 방법으로 구성되어 있습니다. 실제 장애대응 경험과 Kubernetes 운영 로그 패턴을 반영했습니다.

🧠 [Container 장애 대응 시나리오 문제집 – 30문항]

난이도 구분: 상 / 중 / 하
형식: 시나리오 + 객관식 (4지선다형)
포인트: kubectl, describe, logs, CoreDNS, Volume, OOM, ImagePull, CrashLoopBackOff 등 실전 대응 키워드 다수 포함

✅ NO.01 (CrashLoopBackOff · 중)

Pod가 CrashLoopBackOff 상태를 반복 중이며, 로그엔 “Segmentation fault” 메시지만 남아 있다. 우선적으로 확인해야 할 항목은?
① 컨테이너 이미지 사이즈
② CPU 리밋 초과 여부
③ 실행 파일의 퍼미션 및 진입점 오류 여부
④ 서비스 포트 충돌 여부

정답: ③

✅ NO.02 (OOMKilled · 중)

컨테이너가 자주 OOMKilled된다. kubectl describe pod에서 memory limits는 512Mi로 설정되어 있다. 가장 먼저 할 조치는?
① Limits 제거
② HPA 설정
③ Memory usage 모니터링
④ node 재시작

정답: ③

✅ NO.03 (ImagePullBackOff · 하)

Pod 생성 시 ImagePullBackOff 상태가 계속 발생한다. 가능한 원인은?
① PVC 마운트 실패
② 레지스트리 인증 실패
③ HPA 설정 오류
④ ConfigMap 누락

정답: ②

✅ NO.04 (DNS 이슈 · 상)

Pod 내부에서 외부 도메인(Public API) 호출이 안 되고 Temporary failure in name resolution 에러가 발생한다. 가장 먼저 확인할 대상은?
① kubelet 로그
② CoreDNS Pod 상태
③ /etc/resolv.conf
④ serviceAccount

정답: ②

✅ NO.05 (로그 확인 · 중)

Pod가 실패했을 때, 단순히 kubectl logs 명령어로 아무것도 나오지 않는다. 다음으로 시도할 명령은?
① kubectl get pod -o yaml
② kubectl describe pod
③ docker inspect
④ kubectl rollout restart

정답: ②

✅ NO.06 (Volume 오류 · 중)

컨테이너가 /app/data 디렉토리에 쓰기 시도를 할 때 "Read-only file system" 에러가 발생했다. 가장 가능성 높은 원인은?
① PVC 바인딩 실패
② ConfigMap 오타
③ imagePullPolicy 설정 오류
④ node port 충돌

정답: ①

✅ NO.07 (initContainer 실패 · 중)

애플리케이션 Pod가 뜨지 않고, Init Container에서 실패했다. 문제 원인을 확인할 수 있는 명령은?
① kubectl logs <pod>
② kubectl logs <pod> -c <initContainer>
③ kubectl get svc
④ kubectl port-forward

정답: ②

✅ NO.08 (Pod 네트워크 단절 · 상)

일부 노드에서만 동작하는 Pod들이 외부 통신에 실패하고 있다. 어떤 항목을 가장 먼저 확인할 것인가?
① Ingress 설정
② Pod CIDR 충돌
③ 해당 노드의 CNI 플러그인 상태
④ CoreDNS 설정

정답: ③

✅ NO.09 (Pod Pending 상태 · 하)

Pod가 Pending 상태에서 멈춰있다. 가장 일반적인 원인은?
① 이미지 용량 초과
② 리소스 부족(Node에 CPU/Mem 할당 불가)
③ Deployment YAML 구조 오류
④ NetworkPolicy 충돌

정답: ②

✅ NO.10 (Mount 실패 · 중)

PVC가 Pod에 마운트되지 않고 오류 메시지에 Unable to attach or mount volumes가 표시된다. 가장 가능성 높은 원인은?
① RBAC 정책 미적용
② PVC의 accessMode와 Pod의 사용 방식 불일치
③ ReadinessProbe 실패
④ Secret 누락

정답: ②

 

🧠 [Container 장애 대응 – 키워드 암기카드]

📌 키워드💡 요약 설명
CrashLoopBackOff 앱 오류, 실행 실패 → logs, describe pod 분석
ImagePullBackOff 이미지 이름 오타, private registry 인증 실패
OOMKilled 메모리 limits 초과 → describe, 메모리 조정
DNS 오류 CoreDNS 장애 or 네트워크 격리 → kubectl get pod -n kube-system
Read-only FS 마운트 실패, readOnlyRootFS 설정 확인
PVC Mount 실패 accessMode 불일치, StorageClass 미존재
Pending 상태 Node 자원 부족 (CPU/MEM), PVC 바인딩 실패
Init Container 실패 실행 순서 오류 → logs -c <initContainer> 로 확인
NetworkPolicy Pod 간 통신 차단 이슈 → 정책 해석 필수
Service 불통 ClusterIP, NodePort, Ingress 설정 확인
LivenessProbe 실패 앱 내부 상태 비정상 → 재시작 루프 유발
Volume 데이터 유실 emptyDir, 재시작 시 초기화 주의
Node 문제 해당 Node에서만 오류 → CNI, kubelet 상태 점검
Container 로그 없음 앱 진입점 오류 (Entrypoint, CMD 누락)
CoreDNS Cache 특정 도메인만 오류 → CoreDNS Pod 재시작

🧰 [장애유형별 대응 시나리오 요약표]

장애 유형주요 증상우선 확인 항목조치 방법
CrashLoopBackOff 반복 재시작, 로그 짧음 logs, describe, entrypoint 실행 파일 오류, 디펜던시 누락 확인
ImagePullBackOff 이미지 가져오기 실패 이미지 경로, 비공개 인증 imagePullSecret, ACR 연결 재검토
OOMKilled Pod 강제종료 describe pod, limits 확인 메모리 리밋 상향 / 코드 최적화
Pending 상태 Pod 미스케줄 Node 리소스, PVC 상태 Node 스케일업 / PVC StorageClass 설정
PVC Mount 실패 Pod 시작 안됨 Volume mount logs, accessMode RWX/ROX 모드 일치 확인
ReadinessProbe 실패 LB 연결 안됨 Probe 응답 포맷 앱 로직 / 경로 확인 및 응답 조정
DNS 오류 외부 API 통신 불가 CoreDNS 상태, 네트워크 정책 CoreDNS 재시작, NetworkPolicy 조정
네트워크 단절 특정 Pod 외부통신 불가 CNI 상태, Node별 차이 CNI 재설정, Pod 재배치
initContainer 실패 Main container 미실행 logs -c <init> 준비 작업 실패 → 컨테이너 분리 확인
Service 미연결 클라이언트 요청 실패 서비스 포트, 엔드포인트 ClusterIP/NodePort 확인
Pod 간 통신 안됨 내부 앱 통신 실패 NetworkPolicy 정책 해제 또는 허용 rule 추가
컨테이너 로그 없음 빈 로그, 실행 안됨 ENTRYPOINT/CMD, 이미지 내용 실행 명령어 누락 여부 확인

Service Mesh는 MSA 아키텍처 내 통신, 보안, 가시성, 장애 회복성 등을 고도화하기 위한 핵심 구성요소입니다. 아래 내용을 기반으로 실무 역량을 단계별로 정리해드립니다.

🔹 1. Service Mesh란?

정의
Service Mesh는 마이크로서비스 간의 통신 제어, 보안, 관측, 라우팅, 복구 로직을 표준화된 방식으로 처리하는 인프라 계층입니다. 각 서비스는 본래 비즈니스 로직만을 담당하고, 네트워크 기능은 Sidecar Proxy(예: Envoy)가 담당합니다.

구성

  • Data Plane: 실제 트래픽 처리 담당. 각 서비스 옆에 붙는 **Sidecar Proxy(Envoy)**가 있음.
  • Control Plane: 정책 관리, 서비스 디스커버리, 텔레메트리 수집 등을 수행. 대표적으로 Istio의 Pilot, Mixer, Citadel 등.

🔹 2. 주요 기능 및 실무 적용 포인트

기능설명실무 적용
트래픽 라우팅 Canary, A/B 테스트, 버전 기반 라우팅 등 정밀 제어 Blue/Green 배포, 회귀 테스트
보안(Zero Trust) mTLS, 인증/인가, 정책 기반 접근 제어 내부 통신 암호화, 외부 접근 제한
Telemetry 지표 수집(Prometheus), 로그, 트레이싱(Jaeger) 장애 추적, SLO 관리
Circuit Breaker / Retry 자동 재시도, 타임아웃, 회로 차단 장애 복원력 확보
Rate Limiting / Quota API 요청 제한, Abuse 방지 요금제 구간 처리, 인증 API 보호

🔹 3. 대표 Service Mesh 솔루션

솔루션설명특징
Istio Kubernetes 기반 대표 솔루션 복잡하지만 풍부한 기능
Linkerd CNCF Graduated Mesh 간결, 가벼움, 빠른 배포
Consul Connect HashiCorp 제공 Consul과 연계된 Mesh
Kuma / Kong Mesh Envoy 기반 간편 Mesh 멀티 클러스터 지원
AWS App Mesh AWS 서비스 연동에 최적화 EKS, ECS 통합 운영 가능

🔹 4. 실무 시나리오 기반 예시

✅ 시나리오 1: Canary 배포 시 모니터링 문제

문제: 신규 버전 배포 후 10% 트래픽만 보내고 테스트하고 싶음
Service Mesh 적용:

  • VirtualService에서 weight 설정으로 v1:90%, v2:10% 분산
  • Prometheus + Grafana로 실시간 latency, error rate 확인
    → 오류율이 높으면 v2 트래픽을 즉시 차단하여 롤백

✅ 시나리오 2: 내부 인증 및 mTLS 적용 실패

문제: 팀 간 서비스 호출에서 내부 인증 우회 시도 발견
Service Mesh 적용:

  • PeerAuthentication으로 mTLS 강제
  • AuthorizationPolicy로 경로별 RBAC 설정
    → 조직 간 최소 권한 원칙(Least Privilege) 적용 성공

✅ 시나리오 3: 장애 복구 전략의 일환으로 Circuit Breaker 설정

문제: 외부 DB 연동 API가 지연 → 전체 서비스 지연 전파
Service Mesh 적용:

  • DestinationRule에 outlierDetection 설정
  • 지정 횟수 초과 시 해당 인스턴스 격리
    → 회복 불가능 상태에서도 빠른 Failover 가능

🔹 5. TA 관점 정리: 아키텍처/보안/장애 복구 관점의 핵심 포인트

🧱 아키텍처 설계 관점

  • Sidecar는 CPU/Mem 오버헤드를 고려해 프로파일링 및 HPA 설정 필요
  • 다중 클러스터 또는 멀티테넌시 구성을 위한 Gateway 분리

🔐 보안 관점

  • mTLS 인증서 주기적 롤링 자동화 (e.g., Istio Citadel or CA integration)
  • 정밀한 RBAC 설정을 통한 내부 공격 최소화

🛠 장애 대응 관점

  • 트래픽 분산, 자동 재시도, 시간초과 설정 등 장애 전파 차단 메커니즘
  • Jaeger 기반 분산 트레이싱으로 마이크로서비스 간 호출 병목 탐지

 

🧠 Service Mesh 심화 문제집 – 문제·정답·해설 3단 구성

✅ NO.01 [객관식 / 하]

문제
Service Mesh의 Control Plane에서 주로 수행하는 기능은 무엇인가?

① 로드밸런싱 및 트래픽 암호화
② 서비스 간 통신을 위한 DNS 관리
③ 사이드카 프록시 설정 및 정책 배포
④ 인그레스 컨트롤러 관리

정답: ③
해설: Control Plane은 Sidecar 프록시에 대한 설정과 보안 정책, 트래픽 라우팅 등을 구성하여 분산 적용합니다.

✅ NO.02 [객관식 / 중]

문제
Istio에서 트래픽 분산 비율을 설정하는 리소스는?

① Gateway
② DestinationRule
③ ServiceEntry
④ VirtualService

정답: ④
해설: VirtualService는 트래픽 라우팅 정책을 정의하고, 버전별 분산 설정(weight 조정)도 담당합니다.

✅ NO.03 [단답형 / 중]

문제
Istio에서 mTLS 설정을 적용하는 커스텀 리소스는 무엇인가요? (정확한 객체명)

정답: PeerAuthentication
해설: PeerAuthentication은 서비스 간 통신 보안을 위해 mTLS 정책을 설정하는 리소스입니다.

✅ NO.04 [객관식 / 상]

문제
Envoy Proxy의 역할로 올바른 것은?

① Kubernetes Ingress Controller
② TCP/IP 레벨 트래픽 전송
③ Application Layer 로드밸런싱 및 TLS 종료
④ 컨트롤 플레인 리소스 저장소

정답: ③
해설: Envoy는 애플리케이션 계층의 프록시로, HTTP 로드밸런싱, TLS 종료, 트래픽 제어를 수행합니다.

✅ NO.05 [시나리오형 / 중]

문제
Canary 배포 중 v1에 90%, v2에 10% 트래픽을 전송하고자 한다. 이러한 구성을 위한 리소스는?

① ServiceEntry
② DestinationRule + VirtualService
③ Sidecar + WorkloadEntry
④ Gateway + AuthorizationPolicy

정답: ②
해설: VirtualService에서 트래픽 분산(weight 설정), DestinationRule에서 Subset을 정의해 Canary 전략이 구현됩니다.

✅ NO.06 [객관식 / 중]

문제
Service Mesh가 API Gateway와 중복되는 역할이 아닌 것은?

① 트래픽 라우팅
② 외부 인증 (e.g. OAuth)
③ TLS 종료
④ 서비스 내 동적 재시도

정답: ④
해설: 외부 인증은 API Gateway의 주 역할이며, Service Mesh는 서비스 간 재시도와 Circuit Breaker에 집중합니다.

✅ NO.07 [단답형 / 중]

문제
Istio에서 외부 서비스를 허용할 때 사용하는 리소스는?

정답: ServiceEntry
해설: 기본적으로 Istio는 클러스터 외부 트래픽을 차단하며, ServiceEntry를 통해 외부 서비스 접속을 허용합니다.

✅ NO.08 [객관식 / 상]

문제
아래 중 Circuit Breaker 설정 항목이 아닌 것은?

① maxConnections
② outlierDetection
③ connectionPool
④ allowOrigins

정답: ④
해설: allowOrigins는 CORS 설정에 쓰이며, Circuit Breaker와는 무관합니다.

✅ NO.09 [객관식 / 하]

문제
Sidecar가 배포되는 방식으로 올바른 것은?

① Kubernetes Node에 DaemonSet으로 배포됨
② 각 Pod 내부에 컨테이너로 삽입됨
③ 별도 VM에 공통 프록시로 배포됨
④ Control Plane에 배포되어 모든 Pod를 통제함

정답: ②
해설: Istio 등 Service Mesh는 Sidecar를 각 Pod에 주입하여 네트워크 트래픽을 통제합니다.

✅ NO.10 [객관식 / 중]

문제
Service Mesh가 장애 전파를 막기 위해 사용하는 대표적인 기술은?

① Static Routing
② Token Bucket
③ Circuit Breaker
④ Sticky Session

정답: ③
해설: Circuit Breaker는 비정상 응답이 지속되는 인스턴스를 격리해 장애 전파를 방지합니다.

✅ NO.11 [시나리오형 / 상]

문제
AP 서비스가 DB 호출 시 일부 인스턴스만 장애를 일으킨다. 전체 장애로 확산되는 것을 막고 싶을 때 설정할 수 있는 Envoy의 기능은?

① JWT Auth Filter
② Outlier Detection
③ AuthorizationPolicy
④ Headless Service

정답: ②
해설: Outlier Detection은 지연, 오류 비율이 높은 인스턴스를 자동으로 차단합니다.

✅ NO.12 [객관식 / 중]

문제
Istio Telemetry에 사용되는 도구가 아닌 것은?

① Prometheus
② Grafana
③ Jaeger
④ FluentBit

정답: ④
해설: FluentBit는 로그 수집 도구이며, Istio의 기본 Telemetry에는 포함되지 않습니다.

✅ NO.13 [객관식 / 중]

문제
Istio의 Gateway 리소스는 어떤 역할을 하는가?

① 외부 트래픽 수신 및 라우팅
② 내부 마이크로서비스 간 통신 설정
③ RBAC 정책 적용
④ 트래픽 거부 규칙 관리

정답: ①
해설: Gateway는 외부 트래픽을 수신하여 VirtualService와 연계해 내부로 라우팅합니다.

✅ NO.14 [객관식 / 상]

문제
Istio 인증 체계 중 mTLS를 통해 얻을 수 있는 보안 효과로 적절하지 않은 것은?

① 암호화된 서비스 간 통신
② 사용자 인증 기반 권한 부여
③ 신뢰된 서비스 간 상호 인증
④ 재전송 공격 방지

정답: ②
해설: mTLS는 서비스 간 인증을 다루며, 사용자 인증은 OAuth 등의 별도 메커니즘이 필요합니다.

✅ NO.15 [단답형 / 하]

문제
Envoy Proxy를 통해 트래픽 로그를 수집하는 대표적인 분석 도구는?

정답: Jaeger
해설: Jaeger는 분산 추적 도구로, Envoy에서 생성된 trace 정보를 수집하고 시각화합니다.

✅ NO.16 [객관식 / 상]

문제
Istio Control Plane의 구성 요소 중 정책 적용 및 트래픽 제어를 담당하는 것은?

① Pilot
② Mixer
③ Citadel
④ Galley

정답: ①
해설: Pilot은 Envoy에 라우팅 및 정책 구성을 전달하는 핵심 제어 컴포넌트입니다.

✅ NO.17 [객관식 / 중]

문제
서비스 간 요청 수 증가에 따른 성능 병목을 탐지하기 위한 핵심 요소는?

① Retry Count
② Distributed Tracing
③ Rate Limit
④ HPA Metric

정답: ②
해설: Distributed Tracing(Jaeger 등)은 요청 흐름을 시각화하여 병목 지점을 식별합니다.

✅ NO.18 [객관식 / 상]

문제
Kubernetes 외부 트래픽을 Ingress 없이 서비스로 라우팅하려면 필요한 Istio 리소스는?

① Sidecar
② AuthorizationPolicy
③ Gateway + VirtualService
④ PeerAuthentication

정답: ③
해설: Gateway는 외부 연결을 받고, VirtualService는 해당 트래픽의 내부 라우팅을 정의합니다.

✅ NO.19 [객관식 / 중]

문제
다중 클러스터(Multi-Cluster) 환경에서 Service Mesh를 구성할 때 필요한 조건은?

① 동일한 Kubeconfig
② 동일한 Mesh ID
③ 동일한 Pod CIDR
④ 동일한 RBAC 설정

정답: ②
해설: 동일한 Mesh ID를 사용해야 클러스터 간 서비스들이 같은 메시에 속함을 인식합니다.

✅ NO.20 [시나리오형 / 상]

문제
보안 정책 변경으로 모든 서비스 간 통신을 암호화해야 한다. 단, 일부 레거시 서비스는 TLS를 지원하지 않는다.
이 상황에서 단계적 적용을 위한 구성은?

① 전체 서비스에 PeerAuthentication strict 적용
② Mutual TLS를 permissive 모드로 설정
③ 레거시 서비스 격리 후 인증 제거
④ mTLS는 불가능하므로 Sidecar 제거

정답: ②
해설: permissive 모드는 mTLS와 비암호화 트래픽을 동시에 허용하여 점진적 이전이 가능합니다.

 

🧠 Service Mesh 암기카드 요약본 (20문항 대응)

NO.핵심 키워드암기카드 요약
01 Control Plane Sidecar 설정·정책 배포는 Control Plane이 담당한다.
02 VirtualService 트래픽 비율 조정은 VirtualService의 weight로 설정한다.
03 PeerAuthentication mTLS 설정 시 PeerAuthentication 리소스를 사용한다.
04 Envoy 역할 Envoy는 TLS 종료와 L7 로드밸런싱을 처리하는 프록시다.
05 Canary 배포 VirtualService + DestinationRule 조합으로 버전 분산 배포를 구현한다.
06 API Gateway vs Service Mesh 재시도 등 내부 통신 로직은 Service Mesh 전용이다.
07 ServiceEntry 외부 서비스 접근은 ServiceEntry로 허용한다.
08 Circuit Breaker Circuit Breaker 설정은 outlierDetection, maxConnections 등이다.
09 Sidecar 구조 Sidecar는 각 Pod 내 컨테이너로 주입되어 네트워크 트래픽을 제어한다.
10 장애 복원력 Circuit Breaker는 장애 인스턴스를 격리해 전체 장애 확산을 막는다.
11 Outlier Detection Envoy의 Outlier Detection은 지연 응답 인스턴스를 자동 차단한다.
12 Telemetry 도구 Jaeger, Prometheus, Grafana는 Istio Telemetry의 핵심 도구다.
13 Istio Gateway Gateway는 외부 트래픽을 수신하고 내부로 연결하는 역할이다.
14 mTLS 한계 mTLS는 서비스 간 인증이며 사용자 인증은 OAuth가 담당한다.
15 Jaeger Jaeger는 분산 추적을 위한 트래픽 트레이싱 도구이다.
16 Pilot Pilot은 Envoy에 라우팅/정책을 배포하는 제어 컴포넌트다.
17 Tracing 서비스 병목 탐지는 Distributed Tracing이 필수다.
18 Gateway + VirtualService Istio에서 외부 트래픽 진입은 Gateway + VirtualService가 구성된다.
19 Multi-Cluster 구성 동일한 Mesh ID가 다중 클러스터에서 통합된 메시를 구성한다.
20 permissive mTLS mTLS를 점진 적용하려면 permissive 모드로 설정한다.

'MSA Outer > Service Mesh' 카테고리의 다른 글

Service Mesh vs API Gateway 차이점  (0) 2025.05.09

API Gateway는 클라이언트와 백엔드 서비스 사이의 중간 계층 역할을 수행하는 컴포넌트로, MSA(Microservices Architecture), 클라우드 네이티브 아키텍처, 서버리스 환경 등에서 핵심적인 역할을 합니다.

📌 API Gateway란?

API Gateway는 여러 개의 백엔드 서비스를 대표하여 **단일 진입점(Single Entry Point)**을 제공합니다. 외부 요청은 모두 이 Gateway를 거쳐 내부 서비스로 전달됩니다.

예:

 
Client ─▶ API Gateway ─▶ User Service Product Service Order Service

🎯 주요 기능

기능설명
라우팅(Routing) 요청 URI 또는 메서드 기반으로 내부 마이크로서비스로 전달
인증/인가(Authentication/Authorization) JWT, OAuth2, API Key 등으로 인증/인가 수행
속도 제한(Rate Limiting) 악의적 트래픽 또는 과도한 요청 제어
로드 밸런싱(Load Balancing) 여러 백엔드 인스턴스에 트래픽을 분산
로깅 및 모니터링 요청/응답 기록 및 성능 추적, APM 연동
트랜스포트 보안 TLS 종료, HTTPS 지원
요청 변환 요청/응답 포맷 조작 (예: JSON ↔ XML)
캐싱(Caching) 빈번한 API 응답을 Gateway에서 캐싱
CORS 처리 Cross-Origin Resource Sharing 제어

🏗 아키텍처 예시 (MSA 기반)

 
[Client] ↓ [API Gateway] ├── /user → User Service ├── /order → Order Service └── /product → Product Service

🚀 장점

  • 클라이언트는 여러 서비스 주소를 알 필요 없음 → 단일 엔드포인트 관리
  • 인증, 보안, 로깅, 트래픽 제어 등 공통 기능을 중앙 집중화
  • 백엔드 마이크로서비스는 핵심 로직에 집중 → 관심사 분리

🛑 단점 및 주의점

  • **단일 장애 지점(SPOF)**이 될 수 있음 → HA 구성 필요
  • Gateway 자체의 성능 병목 가능성 → Auto Scaling, 캐싱, Rate Limiting 고려
  • 트래픽이 많은 경우 → L7 프록시 최적화 및 이중화 필요

🔧 대표적인 API Gateway 솔루션

제품/플랫폼특징
NGINX / NGINX Plus 오픈소스 기반, 성능 우수, 다양한 설정 가능
Kong 확장성 뛰어난 오픈소스, 플러그인 기반
AWS API Gateway 서버리스 환경, Lambda와 잘 통합됨
Azure API Management Azure 서비스와 통합, 정책 기반 관리
Spring Cloud Gateway Java/Spring 기반 MSA 환경에 최적화
Ambassador / Gloo Gateway Kubernetes 환경에 특화된 Ingress 기반

📂 실무 시나리오 예 (TA 시험용)

  1. API Gateway 장애 발생 시 조치 방안은?
    • 로깅 시스템을 통해 요청 추적
    • 백엔드 헬스체크 상태 확인
    • Load Balancer 상태 점검 및 이중화 확인
  2. JWT 인증을 Gateway에서 수행하는 이유는?
    • 각 마이크로서비스에서 인증을 반복하지 않기 위해 (중복 제거, 성능 향상)
  3. MSA 환경에서 Rate Limiting이 필요한 이유는?
    • API 오용 또는 DDoS 방어, 백엔드 과부하 방지

📚 관련 개념과 비교

개념설명
Ingress Controller Kubernetes에서 API Gateway 역할 일부 수행
Service Mesh Istio/Linkerd 등 사이드카 기반 통신 제어 (L7 기능 분리)
Load Balancer L4/L7 트래픽 분산, API Gateway와 기능 일부 중첩됨

필요하면 아래 항목도 도와줄 수 있어요:

  • Spring Cloud Gateway 설정 예시
  • AWS API Gateway vs NGINX 비교
  • 실무 시나리오 기반 문제 10~20문항 제작

🧠 API Gateway 암기카드 요약본

🔹 기본 개념

  • 🔑 API Gateway: 클라이언트 요청을 백엔드에 라우팅하고, 인증·속도제한·로깅 등을 처리하는 중간자
  • 🔑 역할: 인증/인가, 라우팅, 캐싱, 트래픽 제어, 응답 변환, CORS 처리
  • 🔑 위치: 클라이언트 ↔ 백엔드 사이 (MSA 앞단)

🔹 기능별 정리

✅ 인증·인가

  • 🔑 JWT 검증 → Gateway에서 서명 키/클레임 검증
  • 🔑 OAuth2 연동 → 인증 서버 리디렉션 경로 주의
  • 🔑 Subscription Key (APIM) → 클라이언트 인증에 사용

✅ 라우팅

  • 🔑 Path/Host/Header 기반 분기
  • 🔑 RewritePath, StripPrefix → URI 변경 필터

✅ 속도 제한 / 보안

  • 🔑 Rate Limiting → 사용자/IP/키 기준 요청수 제한
  • 🔑 Quota → 일정 시간당 총 요청수 제한
  • 🔑 IP Whitelist/Blacklist → 보안 강화
  • 🔑 RemoveResponseHeader → 민감 헤더 제거

✅ 응답 처리

  • 🔑 응답 캐싱 → 동일 요청 결과 재사용
  • 🔑 응답 압축 → gzip 등 클라이언트 Accept-Encoding 필요
  • 🔑 응답 변환 → BodyRewrite(Filter), 헤더 추가/삭제

✅ 모니터링·로깅

  • 🔑 Trace-ID 주입 → X-Request-ID 로깅용
  • 🔑 Azure → App Insights 연동, Spring → Sleuth, Zipkin, ELK

🔹 플랫폼별 특징

🔸 Spring Cloud Gateway

  • 🔑 Java 기반, Netty 내장, Spring 생태계와 연계 우수
  • 🔑 application.yml 기반 설정
  • 🔑 GlobalFilter vs RouteFilter 분리
  • 🔑 커스텀 필터 구현 가능 (@Component)

🔸 Azure API Management

  • 🔑 완전관리형 API Gateway
  • 🔑 Developer Portal + JWT/OAuth2 + 정책 기반 처리
  • 🔑 validate-jwt, set-header, rate-limit-by-key 등 Policy 사용
  • 🔑 하이브리드 게이트웨이 가능 (Self-hosted Gateway)

🔸 Kong / NGINX

  • 🔑 플러그인 구조 + Lua 기반 커스터마이징
  • 🔑 오픈소스 또는 Enterprise 모델 선택
  • 🔑 NGINX는 Reverse Proxy → 라우팅과 보안 기본기 탁월

🔹 실무 이슈 키워드 정리

이슈원인 키워드
🔸 401 Unauthorized JWT 키 불일치
🔸 504 Timeout Gateway Timeout 설정
🔸 429 Too Many Requests Rate Limit 초과
🔸 CORS 오류 Access-Control-Allow-Origin 누락
🔸 리디렉션 실패 PathRewrite 미설정
🔸 쿠키 미전송 Secure + HTTPS 미사용
🔸 응답 누락 LB HealthCheck 실패

 

 

✅ API Gateway 실무 시나리오 기반 문제집 (10문항)

NO.01 – 인증 연계 오류 시나리오

문제:
Spring Cloud Gateway를 사용하는 시스템에서 인증서버(JWT 기반)는 별도로 존재한다. 최근 클라이언트의 요청이 "401 Unauthorized"로 반환되는 현상이 다수 발생하고 있다. 아래 중 가장 먼저 확인해야 할 항목은?

① 인증 서버의 DB 연결 상태
② JWT 토큰의 서명 키(Key) 일치 여부
③ 클라이언트의 요청 헤더 구조
④ 백엔드 서비스의 응답 상태
⑤ 클라이언트의 IP 화이트리스트 설정

정답: ②

해설:
Gateway가 JWT 토큰을 검증할 때 사용하는 서명 키가 인증서버와 일치하지 않으면 모든 요청이 실패하게 된다. 이는 인증서버 변경 후 Gateway 설정이 반영되지 않았을 때 자주 발생한다.

NO.02 – URI 라우팅 오류

문제:
API Gateway에서 /api/v1/user/** 요청을 백엔드의 USER-SERVICE로 라우팅하려 한다. 그러나 요청이 404로 실패하고 있다. 설정에서 가장 의심할 부분은?

① CORS 정책
② LoadBalancer 설정
③ Route Path 설정
④ 요청 본문 크기 제한
⑤ Retry 정책

정답: ③

해설:
Spring Cloud Gateway에서 Path=/api/v1/user/**로 설정되어 있어야 해당 경로의 요청이 올바르게 라우팅된다. 패턴 매칭이 잘못되면 요청이 대상 서비스로 전달되지 않는다.

NO.03 – 요청 시간 초과 문제

문제:
API Gateway를 통해 호출된 일부 API가 5초 이상 지연되며 클라이언트는 504 Gateway Timeout을 겪고 있다. 가장 먼저 점검해야 할 것은?

① 백엔드 서비스의 DB CPU 사용량
② Gateway의 Timeout 설정
③ API의 응답 페이로드 크기
④ 클라이언트의 네트워크 대역폭
⑤ HTTPS 설정

정답: ②

해설:
Spring Cloud Gateway는 기본 Timeout이 설정되어 있으며, 백엔드 서비스가 정상 동작하더라도 Timeout 설정이 짧으면 요청이 끊긴다. 설정은 spring.cloud.gateway.httpclient.connect-timeout 등으로 조정 가능하다.

NO.04 – Rate Limiting 이슈

문제:
외부 파트너 시스템에서 특정 API 호출 시 429 Too Many Requests가 지속적으로 발생하고 있다. 가장 가능성이 높은 원인은?

① 백엔드 서비스 오류
② Gateway의 Rate Limiter 설정
③ DNS 캐시 문제
④ JWT 만료
⑤ 로깅 설정 누락

정답: ②

해설:
API Gateway에 Redis 기반 Rate Limiter를 설정한 경우, 사용자 단위 또는 IP 단위로 초당 요청 수를 제한할 수 있다. 과도한 요청은 자동으로 차단된다.

NO.05 – CORS 정책 실패

문제:
프론트엔드에서 API 호출 시 "CORS policy: No ‘Access-Control-Allow-Origin’ header" 오류가 발생한다. 해결 방법으로 올바른 것은?

① Gateway에서 CORS 필터를 제거한다
② 백엔드 서비스의 포트를 변경한다
③ Gateway에 Global CORS 설정을 추가한다
④ 클라이언트 요청을 HTTPS로 전환한다
⑤ 인증 서버 설정을 변경한다

정답: ③

해설:
Spring Cloud Gateway에 Global CORS 설정을 명시적으로 추가해야 하며, allowedOrigins, allowedHeaders, allowedMethods 등을 포함해야 한다.

NO.06 – JWT 토큰 검증 실패

문제:
Gateway에서 JWT 토큰 검증 시 항상 실패한다. JWT는 HS256 알고리즘으로 서명되어 있다. 아래 중 가장 높은 우선순위로 점검할 항목은?

① JWT 발급자의 이메일 주소
② 백엔드 응답 바디 구조
③ Gateway의 Signing Key 설정
④ HTTP 상태코드 설정
⑤ 클라이언트 버전

정답: ③

해설:
HS256은 대칭키 기반 알고리즘이므로 Gateway와 인증 서버가 동일한 시크릿 키를 사용해야 한다. 키가 불일치할 경우 인증은 항상 실패한다.

NO.07 – 로깅 및 추적

문제:
여러 마이크로서비스 호출 간 트랜잭션 추적이 어려운 상황이다. 아래 기능 중 이를 해결하기 위한 가장 적절한 조치는?

① API Gateway에서 X-Trace-ID 헤더를 강제 주입
② 각 서비스별 DB 로그 활성화
③ API Gateway의 응답 캐싱 비활성화
④ 클라이언트의 디버깅 툴 설치
⑤ JWT 페이로드 내 사용자명 삽입

정답: ①

해설:
추적용 ID(X-Request-ID, X-Trace-ID 등)를 Gateway에서 주입하면 이후 모든 서비스가 해당 요청을 식별 가능하게 된다. 로그 상에서도 연관 추적이 쉬워진다.

NO.08 – 캐싱 설정 문제

문제:
API Gateway의 캐싱 정책이 활성화되어 있지만, 매 요청마다 백엔드까지 호출되는 현상이 있다. 설정상 가장 먼저 확인해야 할 것은?

① 응답 바디 구조
② 캐시 TTL 값
③ 요청 메서드 (GET, POST 등)
④ HTTP 상태코드
⑤ CORS 설정

정답: ③

해설:
대부분의 캐시 시스템은 GET 요청에 대해서만 캐싱이 가능하다. POST, PUT은 상태 변경이 동반되므로 캐시하지 않는다.

NO.09 – 요청 헤더 필터링

문제:
특정 API 호출 시 민감한 내부 헤더(X-Internal-Token)가 외부 클라이언트에도 전달되고 있다. 이를 방지하기 위한 Gateway의 기능은?

① AddHeader
② RewritePath
③ RemoveResponseHeader
④ AddRequestParameter
⑤ Retry

정답: ③

해설:
Spring Cloud Gateway에서는 RemoveResponseHeader 필터를 통해 응답 시 특정 헤더를 제거할 수 있다. 보안 측면에서 필수 설정이다.

NO.10 – 고가용성 이슈

문제:
API Gateway 서버 하나만 운영 중인데, 간헐적으로 접근 불가 문제가 발생한다. 인프라적으로 가장 먼저 취해야 할 조치는?

① TLS 인증서 재발급
② JWT 만료 시간 변경
③ 다중 인스턴스 및 로드밸런서 구성
④ 캐싱 무효화
⑤ 클라이언트 SDK 변경

정답: ③

해설:
단일 인스턴스 구조는 SPOF(Single Point of Failure) 문제가 존재하므로, 다중 인스턴스 + L4 로드밸런서를 통해 이중화해야 한다.

필요하시면 다음과 같이도 확장해드릴 수 있습니다:

  • 20~30문항 문제집으로 확대
  • 문제 난이도 표시 (상/중/하)
  • 실습 기반 설정 파일 예시 (application.yml, Kong 설정 등)
  • Gateway + 인증서버 + 백엔드 연동 시나리오 예시

원하시는 방향 알려주시면 계속 제작해드릴게요.

나의 말:

20~30문제로 확대 해주고 난이도 표시해줘

ChatGPT의 말:

 
저장된 메모리 업데이트됨

좋습니다. 아래는 API Gateway 실무 시나리오 기반 문제 25문항이며, 각 문항마다 난이도(상/중/하) 및 정답과 해설을 포함했습니다.
현업에서 발생 가능한 Spring Cloud Gateway, Kong, AWS API Gateway 환경을 혼합해 구성했습니다.

✅ API Gateway 실무 시나리오 문제집 (25문항, 정답·해설 포함)

NO.난이도주제 요약문제 제목
01 중 인증 연계 오류 JWT 키 불일치
02 하 라우팅 설정 URI 패턴 매칭
03 중 타임아웃 504 오류 원인
04 하 Rate Limiting 429 Too Many Requests
05 하 CORS CORS 오류
06 중 JWT 검증 실패 Signing Key 문제
07 중 트레이싱 Trace-ID 주입
08 하 캐시 캐시가 작동 안함
09 하 응답 헤더 보안 헤더 제거
10 중 고가용성 SPOF 제거

NO.11 – 필터 체이닝 오류

난이도: 중

문제:
Spring Cloud Gateway에서 여러 Custom Filter를 등록했는데, 예상한 순서로 필터가 실행되지 않는다. 해결을 위해 설정해야 하는 것은?

① 필터 이름 순서
② 필터 체인 우선순위
③ 필터 내부 로그 레벨
④ 글로벌 CORS 우선순위
⑤ fallback URL 설정

정답: ②
해설:
Spring Cloud Gateway에서는 필터 우선순위를 명시적으로 지정하지 않으면 의도한 실행 순서가 보장되지 않는다. @Order 또는 GatewayFilterSpec.order()로 순서를 명시해야 한다.

NO.12 – OpenAPI 연동 실패

난이도: 하

문제:
API Gateway를 통해 프록시된 서비스에서 Swagger UI 접속이 실패하고 있다. 가장 가능성 높은 원인은?

① JWT 미사용
② Swagger 경로 라우팅 누락
③ 인증 서버 설정 오류
④ Circuit Breaker 미설정
⑤ 클라이언트 TLS 버전 불일치

정답: ②
해설:
Swagger 문서는 별도의 URI (/swagger-ui/) 경로를 사용하므로, 라우팅 설정에 이 경로를 포함하지 않으면 접근이 불가능하다.

NO.13 – 응답 압축 적용 안됨

난이도: 하

문제:
Gateway에서 gzip 압축 응답을 사용했으나, 실제 클라이언트에서는 압축이 적용되지 않는다. 가장 먼저 확인할 항목은?

① 클라이언트 Accept-Encoding 헤더
② 백엔드의 MIME 타입
③ JWT 암호화 여부
④ Redis TTL
⑤ 요청 Method

정답: ①
해설:
압축은 클라이언트가 Accept-Encoding: gzip 헤더를 포함시켜야 서버(Gateway)가 적용한다.

NO.14 – 쿠키 누락 현상

난이도: 중

문제:
프론트엔드 앱에서 인증 후 세션 쿠키를 발급받았으나, 이후 요청에 쿠키가 포함되지 않는다. 가장 유력한 원인은?

① API Gateway 캐시 설정
② 쿠키 Secure 설정 + HTTPS 미사용
③ DNS TTL 값
④ Signing Key 누락
⑤ Rate Limit 설정

정답: ②
해설:
쿠키가 Secure로 설정되어 있을 경우 HTTPS를 통해서만 전송된다. HTTP로 테스트 시 쿠키가 누락된다.

NO.15 – 클라이언트별 라우팅

난이도: 상

문제:
특정 클라이언트(Android)에서만 특정 백엔드 서비스로 라우팅하고자 한다. 이를 위해 사용할 수 있는 Gateway 설정 항목은?

① AddRequestHeader
② RequestPredicate + Header Match
③ RewritePath
④ AddCookie
⑤ Response Timeout 설정

정답: ②
해설:
Spring Cloud Gateway는 Header=User-Agent, Android 조건을 추가하여 Android 기반 요청만 특정 서비스로 라우팅할 수 있다.

NO.16 – IP 기반 접근제어

난이도: 중

문제:
내부망에서만 접근 가능한 API를 구성 중이다. Gateway에서 외부 접근을 차단하기 위한 설정으로 적절한 것은?

① CORS Deny-All
② IP Whitelist/Blacklist 필터
③ HTTPS 강제화
④ Rate Limiting
⑤ JWT Scope 제한

정답: ②
해설:
Spring Gateway 또는 NGINX에서는 IP 기반으로 화이트리스트/블랙리스트 설정이 가능하다. 민감 API 보호 시 유용하다.

NO.17 – 클러스터 모드 장애

난이도: 상

문제:
API Gateway를 3노드로 구성하고 HAProxy로 부하를 분산하였으나 간헐적으로 요청이 유실된다. 가능성 높은 원인은?

① 세션 쿠키 없음
② Redis Rate Limit 동기화 실패
③ LB의 HealthCheck 설정 누락
④ HTTP/2 비활성화
⑤ 인증서 만료

정답: ③
해설:
로드밸런서가 비정상 노드로 트래픽을 분산하면 유실이 발생할 수 있다. Health Check 설정 필수.

NO.18 – 인증 후 리디렉션 오류

난이도: 중

문제:
OAuth2 인증 후 /login/oauth2/code/...로 리디렉션되지 않고 404 오류가 발생한다. 가장 먼저 확인할 항목은?

① 클라이언트 리다이렉트 URI
② API Gateway PathRewrite
③ 로그인 폼 ID
④ CORS 응답헤더
⑤ JWT Payload 구조

정답: ②
해설:
OAuth 인증 후의 리디렉션 URI는 Gateway가 백엔드로 전달해야 하므로, 해당 경로에 대한 RewritePath 설정이 필요하다.

NO.19 – Multi-Tenant 구조 분기

난이도: 상

문제:
API Gateway에서 다중 고객 도메인별로 서로 다른 백엔드 서비스에 연결되도록 구성하고자 한다. 적절한 기능은?

① Header 기반 필터링
② Host 기반 라우팅
③ JWT Scope 사용
④ Circuit Breaker
⑤ Path Strip

정답: ②
해설:
Host=client1.domain.com → backend-A,
Host=client2.domain.com → backend-B 식으로 호스트 기반 라우팅이 가능하다.

NO.20 – 응답 변환 문제

난이도: 상

문제:
외부 API에서 받은 JSON 응답을 내부 표준 스키마로 변환해야 한다. Gateway 수준에서 처리 가능한 방식은?

① ResponseBodyRewrite Filter
② WebClient 호출 내부 가공
③ AddResponseHeader
④ PathRewrite
⑤ CORS 설정 변경

정답: ①
해설:
Spring Cloud Gateway 3.x 이후로는 응답 본문도 가공 가능한 필터를 정의할 수 있으며, 표준화된 응답 스키마로 변환 가능하다.

**umask**는 Unix/Linux 시스템에서 파일과 디렉터리의 기본 권한을 설정할 때 적용되는 기본 권한 마스크(Default Permission Mask) 를 의미합니다.

아래에 핵심 내용을 정리해 드릴게요.

📌 1️⃣ umask란 무엇인가?

  • umask(User File Creation Mask) 는 사용자가 새 파일이나 디렉터리를 생성할 때, 그 기본 권한에서 제한할 권한을 지정하는 값입니다.
  • 쉽게 말해, 기본 권한에서 umask 값만큼 빼서 실제 권한이 결정됩니다.

📌 2️⃣ 기본 생성 권한

  • 새 파일의 기본 최대 권한은 666 (rw-rw-rw-) 입니다.
    • 이유: 실행 권한은 기본적으로 주어지지 않음.
  • 새 디렉터리의 기본 최대 권한은 777 (rwxrwxrwx) 입니다.
    • 디렉터리는 읽기/쓰기뿐 아니라 실행(탐색) 권한이 필요하기 때문입니다.

📌 3️⃣ 실제 권한 결정 방법

공식:

bash
 
최대 권한 - umask = 실제 권한

예를 들어:

  • umask 가 0022 라면:
    • 파일: 666 - 022 = 644 (rw-r--r--)
    • 디렉터리: 777 - 022 = 755 (rwxr-xr-x)

📌 4️⃣ umask 확인과 설정

  • 현재 umask 값 확인:
  • bash
     
    umask
  • umask 값 임시 변경:→ 새 파일: 666 - 027 = 639 ≈ 640 (rw-r-----)
    → 새 디렉터리: 777 - 027 = 750 (rwxr-x---)
  • bash
     
    umask 027
  • ~/.bashrc 또는 ~/.profile 에 설정하여 영구 적용할 수도 있습니다.

✅ 정리

항목의미
umask 새 파일/디렉터리 생성 시 권한 제한 마스크
기본 최대 권한 파일: 666, 디렉터리: 777
적용 방법 최대 권한에서 umask 값 빼기
사용 예 umask 022 → 파일 644, 디렉터리 755
 

필요하다면 실습 예제나 umask 계산 연습 문제도 만들어 드릴까요?

 

나의 말:

640 rw-r---은 어떻게 계산된거야?
 

ChatGPT의 말:

좋습니다! 640 (rw-r-----) 권한이 어떻게 계산되는지 하나하나 단계별로 설명해드릴게요.

✅ 목표: umask 027일 때 파일의 실제 권한 계산 과정

📌 1. 기본 파일 권한

  • 파일은 기본적으로 최대 권한 666 (rw-rw-rw-) 으로 생성됩니다.
    • 실행 권한은 기본적으로 제외됨.
    • 즉:
       
      rw- rw- rw- 6 6 6

📌 2. umask 027 의 의미

  • 8진수 027 은 다음과 같은 비트 마스크를 의미합니다:
  • diff
     
    0 2 7 --- --- --- 000 010 111
  • 권한으로 보면:
    • Owner: 0 → 제한 없음
    • Group: 2 → 쓰기 금지 (-w-)
    • Others: 7 → 모두 금지 (rwx 제거)

📌 3. 계산: 기본 권한 - umask

항목기본 권한 (666)umask (027)결과 (666 - 027)
Owner 6 (rw-) 0 6 (rw-)
Group 6 (rw-) 2 4 (r--)
Others 6 (rw-) 7 0 (---)
 

🔢 즉:

  • Owner: rw- → 6
  • Group: r-- → 4
  • Others: --- → 0

👉 최종 권한: 640 = rw-r-----

🔁 한눈에 정리

항목8진수이진수권한
기본 권한 666 110 110 110 rw-rw-rw-
umask 027 000 010 111 --- -w- rwx
결과 권한 640 110 100 000 rw-r-----
 

필요하시면 디렉터리(기본 777) 권한 계산도 같이 보여드릴 수 있어요!

 

나의 말:

r이면 4 w이면 2 x이면 1인가?
 

ChatGPT의 말:

맞습니다! 정확하게 이해하고 계십니다. 😊

✅ 퍼미션(권한) 숫자 계산 방식

UNIX/Linux의 파일/디렉터리 권한은 다음처럼 문자 기반과 숫자 기반이 서로 연결되어 있습니다:

권한 문자의미값
r 읽기(Read) 4
w 쓰기(Write) 2
x 실행(Execute) 1
- 없음 0
 

📌 예시: rw-r--r--

대상권한계산 (r=4, w=2, x=1)합계
Owner rw- 4 + 2 + 0 6
Group r-- 4 + 0 + 0 4
Others r-- 4 + 0 + 0 4
 

→ 644

📌 또 다른 예: rwxr-x--x

대상권한계산합계
Owner rwx 4 + 2 + 1 7
Group r-x 4 + 0 + 1 5
Others --x 0 + 0 + 1 1
 

→ 751

✅ 참고: 디렉터리는 x 권한이 매우 중요

  • 디렉터리에서 x 는 탐색(진입) 가능 여부를 의미합니다.
  • r 만 있고 x 가 없으면, 리스트는 볼 수 있어도 내부 파일에 접근할 수 없습니다.

 

✅ 퍼미션 계산 연습 문제 (총 5문항)

🔹 문항 1

다음 권한 문자열의 8진수 숫자 표현은 무엇인가요?

lua
 
rwxr-xr--

✅ 문항 1 정답: rwx r-x r--

→ 7 5 4
→ 754

🔹 문항 2

다음 권한 숫자 640은 권한 문자열로 어떻게 표현되나요?

✅ 문항 2 정답: rw- r-- ---

→ rw-r-----

🔹 문항 3

다음 권한 문자열을 숫자로 표현하세요:

lua
 
rw-rw----

✅ 문항 3 정답: rw- rw- ---

→ 6 6 0
→ 660

🔹 문항 4

다음 숫자 권한 751은 권한 문자열로 어떻게 표현되나요?

✅ 문항 4 정답: rwx r-x --x

→ rwxr-x--x

🔹 문항 5

아래 권한을 가진 디렉터리가 있을 때, 해당 디렉터리에 다른 사용자가 들어갈 수 있는가?

css
 
drwx--x---

✅ 문항 5 정답:

  • --x → "실행권한만 있음"
  • 디렉터리에 x 권한만 있으면 경로로 진입은 가능하지만, 목록은 볼 수 없음
  • 다른 사용자(others)가 --x 있으므로 들어갈 수는 있다

→ 정답: 가능하다

 


권한 숫자 644는 리눅스/유닉스 시스템에서 자주 사용되는 퍼미션 설정 중 하나입니다.
아래에 구조와 의미를 간단하게 정리해드릴게요.

✅ 644 권한의 의미

항목숫자이진수권한 문자의미
Owner 6 110 rw- 읽기 + 쓰기
Group 4 100 r-- 읽기만 가능
Others 4 100 r-- 읽기만 가능
 

🔹 전체 권한 문자열: rw-r--r--

📌 요약

  • **파일 소유자(owner)**는 내용을 읽고 쓸 수 있습니다.
  • **같은 그룹 사용자(group)**는 읽기만 가능합니다.
  • **기타 사용자(others)**도 읽기만 가능합니다.
  • 실행(x) 권한은 없음 → 이 권한은 보통 텍스트 파일 또는 설정 파일에 자주 쓰입니다.

📌 예: chmod 644 myfile.txt

  • myfile.txt 파일에 대해:
    • 소유자: 수정 가능
    • 그룹/기타 사용자: 읽기만 가능
    • 실행은 불가

필요하시면 chmod, chown 등을 활용한 실습 예제나 스크립트 자동 설정 예시도 드릴 수 있어요.

 

✅ 755 권한의 의미

항목숫자이진수권한 문자의미
Owner 7 111 rwx 읽기 + 쓰기 + 실행 가능
Group 5 101 r-x 읽기 + 실행 가능
Others 5 101 r-x 읽기 + 실행 가능
 

🔹 전체 권한 문자열: rwxr-xr-x

📌 요약

  • **소유자(owner)**는 파일을 읽고, 수정하고, 실행할 수 있음
  • **같은 그룹 사용자(group)**와 **기타 사용자(others)**는 읽기 및 실행만 가능, 수정은 불가
  • 실행(x) 권한이 있으므로 이 권한은 스크립트나 실행파일, 디렉터리에 주로 사용됨

📌 예: chmod 755 script.sh 또는 chmod 755 /usr/local/bin/myscript

  • 누구나 실행은 가능하지만, 편집은 소유자만 가능
  • 디렉터리에 적용 시: 누구나 진입 및 탐색 가능하지만, 디렉터리 내 파일 추가/삭제는 소유자만 가능

✅ 사용 예시

사용 대상권한 사용 이유
쉘 스크립트 실행 가능하게 (.sh 파일 등)
바이너리 실행 파일 다수가 실행할 수 있도록
웹 서버 루트 디렉터리 (/var/www/html) 서버가 접근은 가능하지만, 수정은 못 하게
 


아래에 644 vs 755 권한을 명확히 비교한 표와 함께, 이해도를 높이기 위한 실습 문제도 제공해드릴게요.

✅ 644 vs 755 권한 비교표

항목644755
권한 문자열 rw-r--r-- rwxr-xr-x
소유자(owner) 읽기 + 쓰기 읽기 + 쓰기 + 실행
그룹(group) 읽기만 읽기 + 실행
기타 사용자 읽기만 읽기 + 실행
실행 가능 여부 ❌ 실행 불가 (보통 문서) ✅ 실행 가능 (보통 스크립트/디렉터리)
주 용도 설정 파일, 로그, 문서 등 스크립트, 명령어, 디렉터리 등
 

✅ 실습 문제

🔸 문항 1

chmod 644 config.txt 명령을 실행하면 어떤 일이 발생하나요?

① 모든 사용자가 읽고 쓸 수 있다
② 소유자만 읽고 쓸 수 있고, 다른 사용자는 읽기만 가능하다
③ 실행 권한이 생긴다
④ 아무도 접근할 수 없다

✅ 정답: ②

🔸 문항 2

chmod 755 run.sh 명령을 실행하면 어떤 상황에서 적절한가요?

① run.sh를 편집 전용 문서로 설정하고 싶을 때
② run.sh를 누구나 실행 가능한 스크립트로 만들고 싶을 때
③ run.sh 파일을 숨기고 싶을 때
④ run.sh를 삭제 방지하고 싶을 때

✅ 정답: ②

🔸 문항 3

아래 권한을 가진 backup/ 디렉터리에 다른 사용자가 파일을 복사하려면, 추가로 어떤 권한이 필요할까요?

drwxr-xr-x

① group, other에 쓰기(w) 권한
② 실행(x) 권한만 있으면 됨
③ 읽기(r) 권한만 있으면 됨
④ root 계정이면 관계 없음

✅ 정답: ①

디렉터리에 파일을 생성하거나 삭제하려면 해당 디렉터리에 쓰기(w) + 실행(x) 권한이 필요합니다.

필요하시면 chmod, umask, chown 등과 연계한 **실무 예제형 문제집 (10문항/20문항)**도 만들어드릴 수 있어요. 해드릴까요?

 

아래는 실무 기반 리눅스 파일 권한/umask/chmod/chown 관련 문제 10문항과 모범답안입니다.

시험이나 현업에 모두 유용하도록 제작했어요.

✅ 리눅스 파일 권한 실무 문제집 (10문항)

📘 문항 1

다음 중 chmod 755 script.sh 실행 후 script.sh 파일에 대한 권한으로 옳은 것은?

① 소유자만 읽기/쓰기/실행 가능하고 나머지는 접근 불가
② 모든 사용자가 읽기 및 실행 가능하고, 소유자만 쓰기 가능
③ 소유자만 실행 가능하고, 그룹은 쓰기 가능
④ 그룹 사용자만 실행 가능하고 나머지는 불가

✅ 정답: ②

📘 문항 2

디렉터리에 x 권한만 있고 r 권한이 없을 경우 어떤 일이 발생하는가?

① 디렉터리 내용은 보이지만 접근은 불가능하다
② 디렉터리 내 파일 목록은 볼 수 없고, 정확한 경로를 알면 접근은 가능하다
③ 아무 작업도 불가능하다
④ 파일을 새로 생성할 수 있다

✅ 정답: ②

📘 문항 3

chmod 644 report.txt는 어떤 의미인가?

① 모든 사용자에게 쓰기 권한 부여
② 소유자는 읽기/쓰기, 나머지는 읽기만 가능
③ 파일을 실행 가능하게 함
④ 파일을 모두에게 숨김 처리

✅ 정답: ②

📘 문항 4

umask 값이 027일 때, 새 디렉터리를 만들면 기본 권한은?

① 750
② 777
③ 755
④ 700

✅ 정답: ①

777 - 027 = 750 → rwxr-x---

📘 문항 5

파일의 소유자와 소유 그룹을 변경하는 명령어는?

① chmod
② usermod
③ chown
④ passwd

✅ 정답: ③

📘 문항 6

chown user1:devgroup test.sh 명령의 의미로 옳은 것은?

① test.sh 파일을 user1이 삭제하도록 함
② test.sh의 소유자를 user1, 소유 그룹을 devgroup으로 변경
③ user1에게만 실행권한을 줌
④ devgroup만 test.sh 읽기 가능하게 설정

✅ 정답: ②

📘 문항 7

다음 중 권한 600이 의미하는 바는?

① 소유자만 읽기/쓰기 가능, 나머지는 전혀 불가
② 모든 사용자가 읽기 가능
③ 그룹만 쓰기 가능
④ 소유자와 그룹이 읽기만 가능

✅ 정답: ①

📘 문항 8

chmod +x install.sh는 무엇을 의미하는가?

① 실행 권한을 모든 사용자에게 부여
② 소유자에게만 실행 권한 부여
③ 실행 권한을 제거
④ 쓰기 권한을 추가

✅ 정답: ①

+x는 기본적으로 모든 사용자에 대해 실행 권한 추가입니다.

📘 문항 9

파일 생성 시 기본 권한이 rw-rw-rw-로 나오는 경우, 이를 rw-r--r--로 제한하려면 적절한 umask는?

① 000
② 022
③ 002
④ 644

✅ 정답: ②

666 - 022 = 644

📘 문항 10

다음 중 디렉터리 권한 설정에 적절한 것은?

① 설정 파일에 755
② 실행 파일에 644
③ 디렉터리에 755
④ 스크립트 파일에 444

✅ 정답: ③

 

이번엔 Linux의 Sticky Bit 개념을 자세히 설명해드릴게요.

시스템 운영 및 보안 실무에서 중요하게 다뤄지는 개념입니다.

✅ Sticky Bit란?

Sticky Bit 는 공용 디렉터리에서 삭제 제어를 위한 특수 권한입니다.

📌 **"모든 사용자가 쓸 수 있는 디렉터리"에서, 본인이 생성한 파일만 삭제 가능하도록 제한하는 기능입니다.

📍 예시 상황

  • /tmp 디렉터리는 모든 사용자가 읽기/쓰기/실행 가능해야 합니다.
  • 하지만 아무나 남의 파일을 삭제할 수 있으면 보안 문제가 생김.
  • 이때 Sticky Bit을 설정하면, "자기가 만든 파일만 삭제 가능" 하게 됩니다.

✅ 권한에서 Sticky Bit의 표기

설명권한 문자예시
Sticky Bit 미설정 drwxrwxrwx 모두 삭제 가능
Sticky Bit 설정 drwxrwxrwt 자신만 삭제 가능
 

마지막 문자 t가 붙으면 Sticky Bit이 설정된 디렉터리입니다.

✅ 설정 및 확인 방법

1. 설정 명령어

bash
 

chmod +t [디렉터리명]

예시:

bash
 

chmod +t /shared

2. 확인 명령어

bash
 
ls -ld /shared

결과 예:

bash
 

drwxrwxrwt 10 root root 4096 Jun 26 12:00 /tmp

drwxrwxrwt → 맨 끝의 t가 Sticky Bit이 설정되었음을 의미합니다.

✅ 해제 방법

bash
 

chmod -t [디렉터리명]

✅ 실무 예제

디렉터리설명
/tmp 모든 사용자에게 열려 있으나, 자신 파일만 삭제 가능해야 하므로 Sticky Bit 설정되어 있음
/var/spool/mail 사용자 메일 저장 디렉터리도 일반적으로 Sticky Bit 사용
 

✅ 퀴즈 문제 예시

📘 문항

다음 중 Sticky Bit에 대한 설명으로 옳지 않은 것은?

① Sticky Bit이 설정된 디렉터리에서는 사용자가 자신이 만든 파일만 삭제할 수 있다
② Sticky Bit은 파일에 설정해도 동일하게 작동한다
③ Sticky Bit은 보안 강화를 위한 특수 권한이다
④ /tmp 디렉터리는 기본적으로 Sticky Bit이 설정되어 있다

✅ 정답: ②

🔍 Sticky Bit은 디렉터리에서만 의미 있으며, 파일에는 의미가 없습니다.

 

SUID(Set User ID)와 SGID(Set Group ID)는 리눅스/유닉스에서 파일의 실행 권한에 부가적으로 설정할 수 있는 특별 권한입니다. 주로 보안 또는 특정 사용자 권한으로 실행을 제한해야 할 때 사용됩니다.

🔹 SUID (Set User ID)

  • 적용 대상: 실행 파일
  • 기능: 사용자가 파일을 실행할 때, 그 파일의 소유자 권한으로 실행되도록 합니다.
  • 목적: 일반 사용자가 루트 권한이 필요한 작업을 제한적으로 실행할 수 있게 할 때 사용됨.

✅ 예시:

bash
복사편집
$ ls -l /usr/bin/passwd -rwsr-xr-x 1 root root 54256 Jan 1 12:00 /usr/bin/passwd
  • s는 사용자(owner) 권한 자리(rws)에 있음.
  • 이 파일은 일반 사용자도 실행할 수 있는데, 실행 시 root 권한으로 실행됨.
  • /usr/bin/passwd는 사용자 비밀번호를 변경하는데, /etc/shadow 파일을 수정하려면 root 권한이 필요하기 때문에 SUID가 설정돼 있음.

🔹 SGID (Set Group ID)

  • 적용 대상:
    • 파일: 파일을 실행할 때 그 파일의 그룹 권한으로 실행됩니다.
    • 디렉토리: 해당 디렉토리 내에 생성되는 파일이나 디렉토리의 그룹을 고정합니다.
  • 목적:
    • 파일: 특정 그룹 권한을 임시로 부여
    • 디렉토리: 협업 시 파일 그룹을 동일하게 유지

✅ 예시 (디렉토리):

bash
복사편집
$ ls -ld /shared drwxrwsr-x 2 user devteam 4096 Jul 31 10:00 /shared
  • s는 그룹 권한 자리(rws)에 있음.
  • /shared 디렉토리에 파일을 생성하면, 생성한 파일의 그룹이 자동으로 devteam으로 설정됨 → 협업을 위해 유용

🔸 퍼미션 숫자로 나타내기

  • SUID: 4
  • SGID: 2
  • Sticky bit: 1

예: chmod 4755 somefile → SUID 설정
예: chmod 2755 somedir → SGID 설정

🔐 보안 유의사항

  • SUID/SGID 설정은 보안에 민감합니다.
  • SUID가 설정된 루트 소유 파일이 잘못 작성되면 **권한 상승(Privilege Escalation)**의 취약점이 생길 수 있습니다.
  • 필요할 때만 최소한으로 설정하는 것이 좋습니다.

🔸 리눅스 퍼미션 구조 다시 보기

리눅스의 퍼미션(permission)은 4자리 숫자로 설정할 수 있습니다:

bash
 
chmod 4755 파일명

이 숫자는 다음과 같이 구성됩니다:

위치의미
1번째 자리 특수 권한 (SUID/SGID/Sticky bit)
2~4번째 자리 일반 권한 (Owner, Group, Other)
 

🔹 일반 권한: 755

이건 많이 익숙하실 텐데요:

  • 7 → rwx (4 + 2 + 1)
  • 5 → r-x (4 + 0 + 1)
  • 5 → r-x (4 + 0 + 1)

즉,

makefile
 
Owner: rwx Group: r-x Other: r-x

🔹 특수 권한: 앞자리에 들어감

특수 권한숫자의미
SUID 4 실행 시 파일 소유자 권한으로 실행됨
SGID 2 실행 시 파일 그룹 권한으로 실행됨 / 디렉토리에선 그룹 고정
Sticky bit 1 디렉토리에서 본인만 삭제 가능하게 함
 

이 숫자들이 1번째 자리에 들어가면 됩니다.

🔸 예시 1: chmod 4755 somefile

  • 4 → SUID 설정
  • 755 → 일반 권한

전체 퍼미션을 숫자로 표현하면:

 
4 7 5 5 ^ |__ SUID 설정됨

→ 이 파일은:

  • Owner: rwx
  • Group: r-x
  • Other: r-x
  • SUID가 설정되어 있음 → 실행하면 소유자 권한으로 동작

🔸 예시 2: chmod 2755 somedir

  • 2 → SGID 설정
  • 755 → 일반 권한

전체 퍼미션을 숫자로 표현하면:

복사편집
2 7 5 5 ^ |__ SGID 설정됨

→ 이 디렉토리는:

  • SGID가 설정되어 있어서,
  • 디렉토리 내에 생성되는 모든 파일/폴더의 그룹이 상속됨

🔸 시각적으로 보기 (ls -l 결과)

명령어결과 (ls -l 기준)
chmod 4755 file -rwsr-xr-x ← SUID (s가 사용자 위치에 있음)
chmod 2755 dir drwxr-sr-x ← SGID (s가 그룹 위치에 있음)
 

요약하자면:

  • chmod 4755: SUID (4) + 일반 퍼미션(755)
  • chmod 2755: SGID (2) + 일반 퍼미션(755)

필 아래는 리눅스 특수 권한(SUID, SGID, Sticky Bit) 을 주제로 한 실무 기반 문제집 10문항과 해설입니다.
직무역량 평가 및 실무 보안 강화에도 매우 중요합니다.

✅ 리눅스 특수 권한 실무 문제집 (10문항)

📘 문항 1

다음 중 Sticky Bit의 역할으로 옳은 것은?

① 디렉터리 내 파일을 누구나 수정 가능하게 한다
② 디렉터리 내 파일을 누구나 삭제 가능하게 한다
③ 사용자가 생성한 파일만 자신이 삭제 가능하도록 제한한다
④ 파일 실행 시 루트 권한으로 실행되도록 한다

✅ 정답: ③

📘 문항 2

/tmp 디렉터리에 Sticky Bit이 설정되어 있는지 확인하려면 어떤 명령어를 사용해야 하는가?

① chmod +t /tmp
② ls -ld /tmp
③ stat /tmp | grep t
④ getfacl /tmp

✅ 정답: ②

📘 문항 3

chmod +t /data 명령을 수행하면 /data 디렉터리는 어떻게 변경되는가?

① 모든 사용자가 파일을 삭제할 수 있다
② 오직 관리자만 접근 가능하다
③ 각 사용자만 자신의 파일을 삭제할 수 있다
④ 실행 파일처럼 변경된다

✅ 정답: ③

📘 문항 4

특정 실행 파일에 SUID를 설정하면 어떤 효과가 있는가?

① 파일은 오직 소유자만 실행 가능해진다
② 실행한 사용자가 그 파일의 소유자 권한으로 실행된다
③ 파일 실행시 로그가 자동 저장된다
④ 파일은 루트에 의해서만 삭제된다

✅ 정답: ②

📘 문항 5

chmod 4755 myscript.sh 명령을 수행하면 어떤 권한이 설정되는가?

① 일반 권한 755
② SGID 설정됨
③ SUID 설정됨
④ Sticky Bit 설정됨

✅ 정답: ③

4xxx → SUID
2xxx → SGID
1xxx → Sticky Bit

📘 문항 6

SUID가 설정된 파일은 권한에서 어떻게 표시되는가?

① -rwxr-xr-x
② -rwsr-xr-x
③ -rwSr-xr-x
④ -rwx--s--x

✅ 정답: ②

SUID는 소유자의 실행권한 위치에 s로 표시

📘 문항 7

SGID가 설정된 디렉터리의 효과로 옳은 것은?

① 디렉터리 내 파일이 특정 사용자 소유가 된다
② 디렉터리 내 파일의 소유 그룹이 디렉터리와 동일하게 설정된다
③ 모든 사용자는 삭제 불가능하다
④ 파일은 루트 권한으로 실행된다

✅ 정답: ②

📘 문항 8

chmod 2755 /app 실행 후 /app의 권한은 어떻게 표시되는가?

① drwxr-sr-x
② drwxrwxrwx
③ drwxr-xr-x
④ drwxrwsr-x

✅ 정답: ①

📘 문항 9

다음 중 SGID가 설정된 디렉터리 권한에 대한 설명으로 틀린 것은?

① 파일을 생성할 때 자동으로 디렉터리의 그룹 소유를 따라간다
② SGID는 디렉터리에만 설정할 수 있다
③ SGID가 설정되면 실행 권한 위치에 s로 표시된다
④ SGID는 그룹 협업 시 유용하다

✅ 정답: ②

❗ SGID는 파일과 디렉터리 모두에 설정할 수 있습니다.

 

📘 문항 10

chmod 1777 /project 명령이 의미하는 바는?

① 읽기 전용 디렉터리 생성
② Sticky Bit과 모든 사용자에게 전체 권한 부여
③ SUID, SGID 설정
④ 디렉터리 숨김 처리

✅ 정답: ②

1000(Sticky) + 777(모든 권한)

✅ 특수 권한 정리표

특수 권한숫자대상효과
SUID 4 파일 실행 시 소유자 권한으로 실행
SGID 2 파일/디렉터리 파일: 소유 그룹으로 실행
디렉터리: 생성 파일의 그룹 동일화
Sticky Bit 1 디렉터리 사용자 자신만 삭제 가능
 

Azure 랜딩존(Azure Landing Zone)은 기업이 Azure에 안전하고 확장 가능하며 규정에 맞는 환경을 구축하기 위한 기본 설계 템플릿입니다. 즉, 클라우드 운영의 기초 인프라와 거버넌스를 표준화하여, 애플리케이션과 서비스가 안정적으로 배포될 수 있도록 돕는 출발점(starting point) 역할을 합니다.

✅ Azure 랜딩존의 용도

  1. 표준화된 클라우드 환경 구성
    • 네트워크, 보안, ID, 리소스 관리 등에 대한 베이스라인 제공
  2. 멀티 서브스크립션 전략 지원
    • 조직 단위 분리(예: 개발/운영/보안 등) 및 비용 관리
  3. 보안 및 거버넌스 정책 반영
    • Azure Policy, RBAC, Management Group 등을 통한 규정 준수
  4. 자동화된 리소스 배포 기반 제공
    • Bicep, Terraform, ARM Template 등을 통한 IaC 기반 설계 가능
  5. 향후 확장성과 운영 용이성 보장
    • Landing Zone 위에 애플리케이션과 워크로드를 안전하게 확장 가능

⚙️ 랜딩존 구성 요소 (예시)


구성요소 요소 설명
Management Group 계층적 리소스 구조 제공 (정책 적용, 권한 설정 등)
Azure Policy 보안/컴플라이언스 정책 자동 적용
Subscription 구조 역할, 비용, 환경별 분리 (예: Dev/Test/Prod)
Azure AD 통합 계정 및 접근 제어
Networking 허브-스포크 구조, NSG, 방화벽, VPN 등
Monitoring Log Analytics, Azure Monitor, Defender for Cloud
Automation IaC(Terraform, Bicep 등), DevOps 파이프라인 연동
 

⚠️ 설계 시 유의사항

  1. 조직 구조와 거버넌스 매핑
    • 부서/팀별 리소스 요구 사항에 따라 Management Group 및 Subscription 구조 설계
  2. 보안 및 정책 선제적 적용
    • 기본적인 보안 정책(예: HTTPS만 허용, 리소스 위치 제한 등)을 정책으로 설정하여 자동 적용
  3. ID 및 액세스 제어 구조화
    • 최소 권한 원칙(Least Privilege)을 기반으로 RBAC 설계
  4. 하이브리드 환경 연계 고려
    • On-Prem과 연동되는 경우 VPN/ExpressRoute, Azure Arc 활용 계획 포함
  5. 멀티지역/다중 환경 대응
    • DR(재해복구) 설계, 리전 간 데이터 중복 및 성능 고려
  6. 자동화 및 CI/CD 통합
    • 랜딩존 구성도 IaC 및 DevOps 환경과 연계하여 반복 가능한 구조 설계
  7. 운영 관점 가시성 확보
    • 모니터링, 알림, 보안 로그 수집을 위한 Log Analytics, SIEM 연동 고려

🎯 참고: 대표적인 랜딩존 구현 방식

  • Microsoft CAF(Cloud Adoption Framework) 기반 랜딩존
    • Enterprise-Scale Landing Zone 아키텍처 제공
  • Terraform 기반 모듈화된 랜딩존
    • HashiCorp 및 Azure 공동 제공
  • Azure Blueprints 기반 구성
    • 정책, RBAC, 리소스 그룹 템플릿을 묶어 일괄 배포

원하는 경우 아래와 같은 자료도 제공 가능합니다:

  • 랜딩존 아키텍처 다이어그램
  • 실무 구축 체크리스트
  • Terraform 기반 예제 템플릿

필요하시다면 이어서 안내드릴게요.

 
ChatGPT에게 묻기
나의 말:
ta관점에서 시험에 나올만한 내용은 무엇이 있을까?
 
ChatGPT의 말:

Azure 랜딩존 관련 TA(Technical Architect) 관점의 시험 출제 포인트는 단순한 정의보다는 아키텍처 설계 능력, 보안 정책 적용, 하이브리드 연계, 거버넌스 구현 등의 실무 적용 능력을 평가하는 방식으로 출제되는 경향이 큽니다. 아래는 시험에 자주 출제될 수 있는 핵심 주제 및 문제 유형 예시입니다.

🎯 TA 관점 시험 출제 포인트 요약

분류주요 내용출제 방식 예시
1. 랜딩존 개념 이해 정의, 목적, 구성요소 객관식/단답형
2. 거버넌스 Management Group, Policy, Role 구조 시나리오 기반 설계 문제
3. 네트워크 설계 허브-스포크, NSG, 방화벽, ExpressRoute 구성도/트래픽 흐름 문제
4. 보안 및 접근 제어 Azure AD, RBAC, MFA, 정책 자동화 접근제어 분석/보안 정책 적용 문제
5. 구독 및 비용 관리 구독 분리, 태그, 비용 할당 시나리오 기반 비용 최적화 문제
6. IaC 및 자동화 Terraform, Bicep, Blueprint 사용 코드 기반 설계 적용 문제
7. 하이브리드 연계 On-prem 연동, Azure Arc 연계 구성 및 장애 대응 문제
 

✅ 예상 문제 유형 및 예시

✅ [객관식] 개념 확인 문제

문제: 다음 중 Azure 랜딩존의 주요 목적이 아닌 것은?
① 보안 및 거버넌스의 표준화
② 네트워크 연결 최소화
③ 확장 가능한 클라우드 환경 기반 구축
④ 자동화된 리소스 배포 구조 제공
정답: ②

✅ [단답형] 설계 요소 식별

문제: Azure에서 조직별 리소스 정책을 계층적으로 적용하기 위한 구조는 무엇인가요?
정답: Management Group

✅ [시나리오형] 설계 적용 문제

문제:
A사는 Azure로 마이그레이션을 계획 중이며, 다음과 같은 조건을 요구하고 있다.

  • 각 부서는 독립된 구독으로 운영
  • 공통 보안 정책은 중앙에서 통제
  • 자산은 모두 한국 중부 리전에 배포되어야 함
    이 요구사항을 만족시키기 위한 랜딩존 설계 요소를 나열하시오.

해설 포인트:

  • Management Group → 조직 단위 계층 관리
  • Azure Policy → 리전 제한, 보안 설정 자동화
  • RBAC → 권한 분리
  • Subscription 분리 → 부서별 운영/비용 분리

✅ [실무형] 장애/이슈 대응 문제

문제:
Azure 랜딩존 기반 환경에서 개발팀이 VM을 특정 리전에 배포하려고 할 때 다음과 같은 오류가 발생했다.

"This location is not allowed by policy."
이 오류의 원인과 조치 방법을 설명하시오.

정답 요지:

  • 원인: Azure Policy에 의해 특정 리전 외 배포 금지
  • 조치: 정책 조건 수정 또는 예외 설정 필요

✅ [설계 비교형]**

문제: 다음 중 Azure 랜딩존의 구성 방식으로 'BluePrint 기반'과 'Terraform 기반' 설계의 차이점을 기술하시오.
정답 요지:

  • BluePrint: Portal 기반, 정책 + 템플릿 패키징
  • Terraform: 코드 기반, 모듈화 가능, GitOps와 연계 용이

🔍 추가로 출제 가능 주제들

주제출제 포인트
Azure Policy 특정 VM SKU 제한, 리전 제한, 태그 필수 설정 등
Subscription 전략 운영/개발/보안 등 용도별 분리
CI/CD 연동 Azure DevOps를 통한 랜딩존 IaC 배포
Azure Arc 하이브리드 및 멀티클라우드 리소스 통합 관리
Security Center/Defender 보안 위협 탐지 및 대응 체계
모니터링 Log Analytics, Azure Monitor 구성 설계
 

필요하시다면 시험용 예상문제 10~20문항 PDF, 또는 Terraform 기반 랜딩존 템플릿 해설도 제작해 드릴 수 있습니다. 원하시나요?

 
나의 말:
시험용 예상문제 10~20문항 을 해설과 함께 만들어줘 그리고 Terraform 기반 랜딩존 템플릿 해설도 부탁해
 
ChatGPT의 말:

module "landing_zone_network" {
  source            = "./modules/network"
  location          = "koreaCentral"
  resource_group    = "rg-landingzone"
  vnet_name         = "vnet-hub"
  address_space     = ["10.0.0.0/16"]
  subnet_prefixes   = ["10.0.1.0/24", "10.0.2.0/24"]
}

module "landing_zone_policy" {
  source            = "./modules/policy"
  policy_assignment = "only-koreaCentral"
}
좋습니다!
아래는 TA 관점 Azure 랜딩존 관련 시험 예상문제 15문항과 문제별 해설입니다. 이어서 Terraform 기반 랜딩존 템플릿 해설도 제공드리겠습니다.

📘 [시험용 예상문제] Azure 랜딩존 – TA 관점

(객관식 + 단답형 + 시나리오형 혼합 구성)

📌 [문제 1] (객관식)

Azure 랜딩존(Landing Zone)의 목적에 해당하지 않는 것은?
① 클라우드 환경의 표준화
② 리소스의 무제한 사용 허용
③ 보안 및 거버넌스 구현
④ 애플리케이션 배포를 위한 기반 설계

정답: ②
해설: 랜딩존은 표준화된 구조와 보안 거버넌스를 제공하기 위한 출발점이며, 무제한 리소스 사용을 허용하지 않음.

📌 [문제 2] (객관식)

Azure 랜딩존 설계 시 리소스 그룹 간 권한과 정책을 계층적으로 통제하기 위한 구성 요소는?
① Azure VM
② Azure Subscription
③ Azure Management Group
④ Azure Resource Tag

정답: ③
해설: Management Group은 정책, 권한을 상위에서 하위 구독까지 계층적으로 통제할 수 있음.

📌 [문제 3] (단답형)

Azure에서 리소스를 특정 리전에만 배포하도록 제한하기 위한 정책 관리 도구는?
정답: Azure Policy

해설: Azure Policy는 리소스 배포 시 규칙을 적용하여 표준화와 컴플라이언스를 유지함.

📌 [문제 4] (객관식)

Azure 랜딩존에서 역할 기반 접근 제어(RBAC)를 사용하는 이유로 가장 적절한 것은?
① 서버 성능을 개선하기 위해
② 비용을 줄이기 위해
③ 사용자 접근 권한을 제어하기 위해
④ 리전 간 데이터를 자동 동기화하기 위해

정답: ③
해설: RBAC는 리소스에 대한 접근을 최소 권한 원칙으로 제어하기 위한 기능임.

📌 [문제 5] (시나리오형)

상황: 조직은 운영, 개발, 보안 부서별로 Azure 리소스를 분리 운영하고자 한다. 부서별로 비용과 리소스는 독립적으로 관리되어야 하며, 공통된 보안 정책은 모든 리소스에 적용해야 한다.
질문: 이 구조를 구성하기 위한 설계 요소를 두 가지 이상 기술하시오.

모범답안:

  • Subscription: 부서별 리소스 격리 및 비용 분리
  • Management Group: 공통 정책 적용을 위한 계층 구조
  • Azure Policy: 보안 및 컴플라이언스 정책 통제

📌 [문제 6] (객관식)

Azure Policy를 통해 다음과 같은 기능을 수행할 수 없는 것은?
① 특정 지역 외 VM 배포 차단
② 특정 리소스 타입 사용 제한
③ 사용자 그룹 추가
④ 리소스에 태그 자동 부여

정답: ③
해설: 사용자 그룹 추가는 Azure AD에서 수행하며, Policy는 리소스 관리에 초점이 있음.

📌 [문제 7] (단답형)

Azure 랜딩존 설계 시 VPN이나 ExpressRoute 연결 등을 포함하는 핵심 구성 요소는 무엇인가?
정답: Networking (또는 Hub & Spoke Architecture)

📌 [문제 8] (객관식)

Terraform을 사용하는 이유 중 랜딩존 구성에 적합한 설명은?
① GUI로 빠르게 리소스를 배포할 수 있다.
② 반복 배포 및 환경 이식성이 용이하다.
③ 비용 추적 기능을 제공한다.
④ 수동 배포만 가능하다.

정답: ②
해설: Terraform은 코드 기반으로 반복 가능한 환경 배포가 가능하며, GitOps/CI와 연계가 용이하다.

📌 [문제 9] (단답형)

Terraform에서 리소스 구성을 위한 기본 단위는 무엇인가?
정답: module 또는 resource
해설: resource는 단일 리소스, module은 재사용 가능한 리소스 집합을 의미

📌 [문제 10] (객관식)

Azure 랜딩존에서 공통된 태그를 모든 리소스에 자동 부여하고자 할 때 사용하는 기능은?
① Azure Resource Graph
② Azure Monitor
③ Azure Policy
④ Azure Blueprint

정답: ③
해설: Azure Policy에서 ‘태그가 없을 경우 자동 추가’와 같은 정책을 구성 가능

📌 [문제 11] (시나리오형)

상황: 개발팀에서 랜딩존을 구성한 후, VM을 미국 서부 리전에 생성하려 하였으나 다음과 같은 오류가 발생하였다.

pgsql
복사편집
Error: The deployment region 'westus' is not allowed by policy.

질문: 이 오류의 원인과 해결 방안을 설명하시오.

모범답안:

  • 원인: Azure Policy에서 허용된 리전 외 배포가 차단되었기 때문
  • 해결: 정책 수정 혹은 리전 예외 설정을 통해 허용하도록 조치

📌 [문제 12] (객관식)

Azure Blueprint의 가장 핵심적인 기능은 무엇인가?
① Azure 비용 모니터링
② 리소스별 접근 권한 추적
③ 리소스, 정책, 역할 배포의 템플릿화
④ 테넌트 이동 기능 제공

정답: ③
해설: Blueprint는 Policy, Role, Resource Group 등을 패키징하여 일괄 배포 가능

📌 [문제 13] (단답형)

Azure Landing Zone에서 로깅 및 모니터링 구성 시 주로 사용하는 두 가지 핵심 서비스는?
정답: Log Analytics, Azure Monitor

📌 [문제 14] (객관식)

Terraform을 이용한 랜딩존 구성 시 유의해야 할 점으로 가장 적절한 설명은?
① 상태(state)를 수동으로 관리해야 한다
② 리소스 간 의존성은 정의할 수 없다
③ 상태 관리 파일의 버전 충돌 방지를 고려해야 한다
④ 리소스 삭제 시 항상 자동 백업된다

정답: ③
해설: Terraform의 상태 파일(terraform.tfstate)은 버전 충돌을 방지하기 위해 원격 저장소(backends, 예: Azure Storage)를 사용해야 안정적이다.

📌 [문제 15] (시나리오형)

상황: A사는 Terraform으로 랜딩존을 구축한 이후, 동일한 구성을 다른 지역에 복제하려 한다.
질문: 이를 위한 Terraform 기능과 그 이유를 설명하시오.

모범답안:

  • 기능: module
  • 이유: 모듈화된 구성은 파라미터(리전 등)를 다르게 설정하여 재사용 가능하며 유지 관리에 용이

📦 Terraform 기반 랜딩존 템플릿 해설

🌐 기본 구조 예시 (개요)

 

🔍 주요 해설 포인트

항목설명
module 모듈화된 구성으로 네트워크, 정책, 보안 등을 분리하여 관리
backend 설정 terraform.tfstate 파일을 Azure Storage 등에 저장해 협업 충돌 방지
변수 (variables.tf) 위치, 서브넷, NSG 등 파라미터화하여 재사용성 강화
outputs.tf 생성된 리소스 ID, IP 등 출력으로 다음 작업에 연결 가능
provider Azure 클라우드와 연결하기 위한 설정 (azurerm)
locals 반복되는 문자열, 네이밍 규칙 등을 변수로 처리
 

📂 폴더 구조 예시

/terraform-landing-zone
│
├── main.tf
├── variables.tf
├── outputs.tf
├── backend.tf
├── /modules
│   ├── /network
│   ├── /policy
│   └── /rbac
 

 

필요하시면 이 Terraform 템플릿을 압축 파일로 드리거나 PDF 형식 문서로도 정리해 드릴 수 있습니다.
또한, 실제 배포 절차 문서화 또는 Azure DevOps 연동 사례도 안내 가능합니다.

원하시는 형식(예: PDF, Word, 코드 ZIP 등)을 알려주시면 바로 준비해 드리겠습니다.

 
 
 

📘 TA 관점의 핵심 지식 포인트

  • NSG 보안 정책 이해 (Deny 기본, Allow 명시)
  • Application Gateway 리스너 구조 (HTTP/HTTPS만)
  • 스토리지 계정 복제 옵션 (LRS, ZRS, GRS 등)
  • VM Backup 구조 (Backup Center, Azure Monitor 연계)
  • Managed Disk 유형별 성능 차이 (Standard/Premium/Ultra SSD)

🧠 이 수준에 맞춰 새로 구성할 문제 예시

📌 문제 A (시나리오형)

A사는 Azure로 시스템을 이전하면서 아래와 같은 설정을 계획하고 있다.

  • 내부 전용 백엔드 풀을 사용하는 Application Gateway 구성
  • VM의 상태를 실시간으로 모니터링
  • 프리미엄 SSD를 사용하는 트랜잭션 집약 워크로드 운영

질문: 위 요구사항을 충족하기 위한 Azure 서비스 또는 기능을 각각 1개씩 기술하시오.

모범답안:

  • Application Gateway with Private Frontend (또는 Internal Listener)
  • Azure Monitor + VM Insights
  • Premium SSD (P30 이상) Managed Disk

📌 문제 B (객관식)

다음 중 Azure Backup Center에 대한 설명으로 올바른 것은?
① 리소스 그룹 전체 백업은 지원하지 않는다
② 백업 구성은 반드시 CLI로만 설정 가능하다
③ 백업 실패 알림은 Azure Monitor로 통합 가능하다
④ 백업된 데이터는 무조건 30일 후 삭제된다

정답: ③
해설: Azure Monitor 및 Log Analytics를 통한 백업 이벤트 모니터링 및 알림 가능

📌 문제 C (단답형)

Azure Storage의 복제 옵션 중 3개의 복제본을 동일 리전에 다르게 보관하며 Zone 장애를 보호하는 방식은?
정답: ZRS (Zone-redundant storage)

원하신다면 위 문제 스타일로 10~20문항 세트로 더 만들어 드릴 수 있습니다.
원하시면 "계속" 또는 "이와 유사한 문제로 구성해줘"라고 말씀해주세요!

나의 말:

이와 유사한 문제로 구성해줘

ChatGPT의 말:

좋습니다! 앞서 주신 문항 16의 난이도와 문제 구성 방식(복수 보기 중 올바른 기술 판별)을 기준으로, 동일한 수준과 스타일로 Azure 기반 클라우드 설계 및 운영에 필요한 TA 역량 문제 5문항을 아래에 구성하였습니다.
각 문항은 실무 중심의 서비스 이해 + 구성 판단 + 장애 대응 고려 요소가 반영되어 있으며, 모두 정답과 해설 포함입니다.

✅ TA 역량평가 문제 세트 (문항 1~5)

🔹 문항 1

Azure 환경에서 고가용성을 고려한 Application Gateway 구성 시, 다음 설명 중 올바른 것을 고르시오.
① Application Gateway는 Zone Redundant 옵션을 지원하지 않는다.
② 웹방화벽(WAF) 기능은 Application Gateway의 부가 서비스로 수동 설정이 필요하다.
③ Application Gateway는 내부망(Private) 전용으로만 사용할 수 있다.
④ Application Gateway에 구성된 리스너는 특정 포트와 프로토콜에 대해 명시적으로 설정되어야 한다.
⑤ Application Gateway는 VM Scale Set과 연동할 수 없다.

정답: ④
해설:

  • 리스너는 특정 포트 및 프로토콜(HTTP/HTTPS)에 대해 명확히 설정해야 한다.
  • ① X: Zonal 및 Zone-redundant 지원 가능
  • ② X: WAF는 SKU에 따라 자동 포함 가능
  • ③ X: Public/Private 둘 다 지원
  • ⑤ X: 백엔드 풀로 VMSS 사용 가능

🔹 문항 2

Azure Virtual Network 구성 시 유의할 점으로 올바르지 않은 것은?
① 서브넷 간 통신은 기본적으로 허용된다.
② NSG를 통해 서브넷 또는 NIC 수준에서 트래픽을 제어할 수 있다.
③ VNet 간 통신은 기본적으로 허용된다.
④ VNet Peering을 구성하면 라우팅 테이블은 자동으로 생성된다.
⑤ GatewaySubnet은 VPN Gateway 전용 서브넷으로 예약된 이름이다.

정답: ③
해설:

  • VNet 간은 기본적으로 통신 불가하며, VNet Peering 구성 후에 통신이 가능하다.
  • 나머지는 모두 정확한 설명이다.

🔹 문항 3

Azure Policy에 대한 설명으로 올바른 것을 모두 고르시오.
① 특정 태그가 없는 리소스를 생성하지 못하도록 차단할 수 있다.
② VM에 특정 크기의 SKU만 허용하는 정책을 적용할 수 있다.
③ 정책은 Subscription이나 Resource Group에만 할당 가능하다.
④ 정책 위반 사항은 Azure Advisor에서 확인된다.
⑤ 정책은 할당 후에도 진단 로그를 통해 컴플라이언스 상태를 추적할 수 있다.

정답: ①, ②, ⑤
해설:

  • ①: 태그 기반 조건 설정 가능
  • ②: SKU 제한 정책 존재
  • ③: ❌ Management Group 수준에도 할당 가능
  • ④: ❌ Azure Policy 결과는 Policy UI 또는 Log Analytics로 확인
  • ⑤: 진단 로그 및 Log Analytics 연계 가능

🔹 문항 4

다음 중 Azure Virtual Machine 디스크 유형에 대한 설명으로 올바른 것은?
① Standard HDD는 높은 IOPS를 제공하며 DB 워크로드에 적합하다.
② Premium SSD는 Managed Disk가 아닌 경우에만 사용할 수 있다.
③ Ultra SSD는 모든 VM 사이즈에서 지원된다.
④ OS 디스크와 데이터 디스크는 서로 다른 유형으로 구성할 수 있다.
⑤ 모든 디스크는 기본적으로 ZRS(Zone Redundant Storage)로 제공된다.

정답: ④
해설:

  • OS 디스크: 일반적으로 Premium SSD
  • 데이터 디스크: 상황에 따라 HDD, SSD 선택 가능
  • 나머지는 잘못된 설명

🔹 문항 5

Azure에서 백업 구성 시 고려해야 할 사항 중 잘못된 것을 고르시오.
① Azure Backup은 VM, SQL, 파일, Blob 등을 지원한다.
② Recovery Vault는 리소스 그룹 내 위치에 종속되지 않는다.
③ Backup Vault는 Azure Monitor와 통합될 수 없다.
④ VM 백업은 VSS를 활용한 스냅샷 기반이다.
⑤ Backup 정책은 주기 및 보존 기간을 자동화할 수 있다.

정답: ③
해설:

  • Azure Backup Vault는 Azure Monitor와 통합 가능하여 알림, 경고, 로그 확인이 가능하다.

🔚 이어서 제공 가능

필요하시면 아래 항목도 연계해 드릴 수 있습니다:

  • 문제 6~15 추가 제작
  • 분야별(네트워크, 스토리지, 보안, 클러스터링 등) 문제 분류
  • Word / PDF 변환본
  • 암기카드형 요약본 (문제 키워드 중심)
  • 실무 시나리오 기반 문제집 (예: 장애 대응, 이중화 구성 등)

원하시는 형태로 이어서 만들어드릴까요?
예) "PDF로 출력해서 블로그에 올릴 수 있게 정리해줘"
또는 "장애 대응 시나리오형 문제로 5문제만 더 만들어줘" 등 구체적으로 말씀해 주세요.

나의 말:

분야별로 문제를 분류해서 하자.. 일단 클러스터링부터 서비스 이해 + 구성 판단 + 장애 대응 고려 요소가 반영해서 만들어줘

ChatGPT의 말:

 
저장된 메모리 업데이트됨

좋습니다! 아래는 "클러스터링" 분야에 대해 TA(Technical Architect) 실무 기반 역량을 평가할 수 있도록 구성한 문제 세트입니다.
각 문항은 ① 서비스 이해, ② 구성 판단, ③ 장애 대응 고려 요소를 포함하며, 정답과 해설까지 제공됩니다.

📘 TA 역량평가 – 클러스터링 분야 문제 (문항 1~5)

🔹 문항 1. (서비스 이해)

Windows Failover Cluster에서 Quorum 구성의 주요 목적은 무엇인가?

① 장애 발생 시 DNS 재등록을 위함
② 클러스터 서비스의 패치 자동화를 위함
③ 다중 노드 간의 작업 부하 분산을 위함
④ 클러스터 생존성 판단 및 Split-Brain 방지
⑤ Active Directory 역할 통합을 위함

정답: ④
해설: Quorum은 클러스터의 노드 수가 불안정할 경우, 정상 동작 가능한 노드 수 판단 기준 역할을 하며, Split-Brain 방지에 핵심적이다.

🔹 문항 2. (구성 판단)

다음 중 Windows 또는 Linux 환경의 고가용성 클러스터링 구성 시 일반적으로 권장되지 않는 설정은?

① Heartbeat NIC에는 Gateway를 지정하지 않는다.
② Heartbeat NIC에는 DNS 서버 주소를 설정하지 않는다.
③ 클러스터 전용 NIC에는 ICMP Ping 응답을 허용한다.
④ 클러스터 VIP는 모든 노드에서 동시에 활성화되어야 한다.
⑤ 클러스터 전용 네트워크의 Metric 우선순위는 낮게 설정한다.

정답: ④
해설: 클러스터 VIP는 Active-Passive 모델에서 하나의 노드에서만 활성화되어야 하며, Failover 시에만 이전된다.

🔹 문항 3. (장애 대응)

장애 복구 환경에서 Windows Cluster에서 특정 리소스 그룹이 자동으로 Failover 되지 않는 상황이다.
가장 먼저 확인해야 할 항목은?

① NIC의 MAC 주소 변경 여부
② 클러스터 Shared Disk의 포맷 종류
③ 해당 리소스의 “자동 시작” 속성 설정 여부
④ 클러스터 IP의 DNS 등록 여부
⑤ 서버 BIOS의 전원 복구 설정 여부

정답: ③
해설: 리소스 그룹 내 서비스가 자동으로 Failover 되기 위해서는 “자동 시작 설정”이 활성화되어 있어야 한다. 그렇지 않으면 서비스가 수동 전환되거나 Failover 되지 않을 수 있음.

🔹 문항 4. (구성 판단 + 서비스 이해)

Linux Pacemaker/Corosync 기반 클러스터에서 STONITH(Fencing)를 사용하는 주요 이유는?

① 클러스터 로그 수집을 위해
② 동시성 제어를 위하여
③ 특정 노드에서 응답이 없을 때 강제 재부팅하여 클러스터 보호
④ 클러스터 인터페이스의 통계 수집
⑤ Heartbeat 전송속도 개선을 위해

정답: ③
해설: STONITH는 "Shoot The Other Node In The Head"의 약어로, 응답하지 않는 노드가 클러스터 리소스를 손상시키지 않도록 강제 재부팅 또는 전원 차단하는 메커니즘이다.

🔹 문항 5. (장애 대응 + 서비스 이해)

다음은 NFS 서비스가 구성된 고가용성 클러스터의 상태이다.

  • Active 노드의 서비스가 비정상 종료되었으나 노드 자체는 정상
  • Standby 노드는 리소스를 인계받지 않음

이 현상의 원인으로 가장 유력한 것은?

① Standby 노드의 OS 커널 패치 미적용
② 클러스터 스토리지의 Block Size 미일치
③ 서비스에 설정된 클러스터 리소스 모니터링 실패 조건이 없음
④ NFS 마운트 지연으로 인한 패킷 드롭
⑤ 클러스터 DNS 레코드 충돌

정답: ③
해설: 클러스터에서는 서비스 자체가 비정상일 경우에도 리소스 상태를 감지할 모니터링 조건이 설정되어 있지 않으면, Failover가 일어나지 않음. 리소스 상태 모니터는 반드시 구성되어야 함.

📚 클러스터링 분야 – 평가 영역 요약

평가 영역출제 예시설명
서비스 이해 Quorum, STONITH, VIP 구성 클러스터링 기본 메커니즘의 목적 및 구조 이해
구성 판단 NIC 구성, Failover 설정, 리소스 설정 장애 허용 구조를 위한 적절한 설정 여부
장애 대응 Failover 실패, 감시 설정 누락 등 고가용성 유지 실패 시 원인 분석 및 조치

 

좋습니다! 앞서 만든 클러스터링 분야 5문제에 이어, 동일한 TA 역량평가 스타일로 **추가 문제 5문항(문항 6~10)**을 제작하였습니다.
이 문제들도 서비스 이해 + 구성 판단 + 장애 대응 요소를 반영하였습니다.

📘 클러스터링 분야 – 추가 문제 (문항 6~10)

🔹 문항 6. (서비스 이해)

Linux 환경에서 HAProxy + Keepalived를 활용한 클러스터링 구성 시, Keepalived의 주된 역할은 무엇인가?

① 로드밸런싱을 수행한다
② 백엔드 서비스의 상태를 분석한다
③ 가상 IP(VIP)의 장애 전환(Failover)을 담당한다
④ 리눅스 커널을 제어하여 NIC 상태를 모니터링한다
⑤ 애플리케이션 로그를 수집하여 로테이션한다

정답: ③
해설: Keepalived는 VIP를 유지·관리하며 마스터 노드 장애 시 백업 노드로 VIP를 넘기는 역할을 수행한다.

🔹 문항 7. (구성 판단)

다음 중 클러스터링 구성 시 Quorum Disk 방식을 도입해야 유리한 시나리오는?

① 노드가 1개뿐인 개발 테스트 환경
② 클러스터 노드 간 통신이 항상 안정적인 환경
③ 짝수 개의 노드가 물리적으로 멀리 떨어진 경우
④ 클러스터 서비스가 단일 IP로만 동작하는 경우
⑤ 노드 간 네트워크 대역폭이 매우 높을 경우

정답: ③
해설: 노드가 짝수 개인 경우, Quorum Disk 또는 Witness 리소스를 통해 동등 분할(Split Brain) 상황을 방지할 수 있다.

🔹 문항 8. (장애 대응)

Windows Failover Cluster에서 특정 클러스터 리소스가 반복적으로 장애 발생 후 재시작을 시도하지만 실패한다.
이 경우 확인해야 할 설정 항목은?

① Windows Defender의 실시간 감시
② 리소스의 “Failover Retry Count” 및 “Failover Threshold” 값
③ 클러스터 VIP의 TTL 값
④ 해당 리소스의 Run As 권한
⑤ 스토리지 계정 키 만료 여부

정답: ②
해설: Windows Cluster는 설정된 재시도 횟수 및 간격을 초과하면 리소스를 Offline 처리하므로, 해당 설정이 장애 지속 시 재기동을 막고 있을 수 있다.

🔹 문항 9. (서비스 이해 + 구성 판단)

다음 중 Kubernetes 클러스터 환경에서 고가용성을 고려한 Control Plane 구성으로 적절한 것은?

① 하나의 etcd 노드를 운영하고 백업을 자주 수행한다
② Control Plane 노드를 3개 구성하고 etcd를 각각에 내장하여 운영한다
③ Control Plane과 Worker Node를 혼합 구성하여 관리한다
④ Load Balancer를 Worker Node에만 연결한다
⑤ 각 Control Plane 노드에 별도의 kube-apiserver 인스턴스를 직접 설치한다

정답: ②
해설: 고가용성을 고려할 경우 Control Plane은 홀수(일반적으로 3개) 구성하며, 각 노드에 내장된 etcd를 통해 분산 저장소를 구성하는 것이 일반적이다.

🔹 문항 10. (장애 대응)

Kubernetes 클러스터에서 etcd quorum이 상실되었을 경우 예상되는 현상은?

① 전체 Pod가 삭제된다
② kubelet이 재시작된다
③ Control Plane API 호출이 실패한다
④ 모든 서비스가 자동으로 새 노드로 마이그레이션 된다
⑤ Helm으로 배포된 리소스만 영향을 받는다

정답: ③
해설: etcd는 Kubernetes의 상태 저장소이며, Quorum(과반수)의 etcd 노드가 비정상이면 Control Plane이 정상 작동하지 않음 → kubectl 명령어 실패

📚 클러스터링 문제 범위 요약 (6~10)

문항핵심 개념유형
6 Keepalived VIP 전환 원리 서비스 이해
7 Quorum Disk 사용 판단 구성 판단
8 장애 재시도 설정 확인 장애 대응
9 K8s Control Plane 구성 서비스 이해 + 구성 판단
10 etcd Quorum 장애 영향 장애 대응

 

📘 클러스터링 분야 – 추가 문제 세트 (문항 11~20)

🔹 문항 11. (서비스 이해)

다음 중 Kubernetes 환경에서 Control Plane 고가용성(HA)을 구성하기 위한 요소가 아닌 것은?

① etcd 분산 클러스터
② Multi-zone 배포
③ Load Balancer를 통한 API Server 접근 분산
④ 모든 노드에 kubelet 직접 설치
⑤ kube-controller-manager의 다중 인스턴스 구성

정답: ④
해설: kubelet은 Worker Node에서 동작하는 컴포넌트로, Control Plane HA 구성과 직접적인 관련은 없음.

🔹 문항 12. (장애 대응)

Linux HA 클러스터에서 VIP 전환이 실패하고, 두 노드가 모두 VIP를 보유하게 된 경우 발생 가능한 상황은?

① 스토리지 이중화
② 리소스 자동 복구
③ Split-Brain
④ 로그 백업 누락
⑤ 클러스터 Quorum 강화

정답: ③
해설: Split-Brain은 노드 간 통신 장애로 인해 서로를 Fail로 간주하고 VIP를 동시에 보유하는 상태로, 데이터 손상 가능성이 크다.

🔹 문항 13. (구성 판단)

다음 중 Windows Server Failover Cluster(WSFC) 구성 시 필수 요구사항이 아닌 것은?

① 동일 도메인에 가입된 서버
② 공유 디스크 또는 Storage Spaces Direct
③ 클러스터 구성 마법사를 통한 설치
④ 리소스 그룹별 전용 네트워크 구성
⑤ DNS 등록 및 이름 확인 가능 여부

정답: ④
해설: 리소스 그룹별로 전용 네트워크를 구성할 필요는 없으며, 클러스터 전용 Heartbeat 네트워크는 권장사항일 뿐이다.

🔹 문항 14. (서비스 이해)

Pacemaker에서 리소스 리스팅(resource list) 기능을 사용하는 목적은?

① 리소스의 실제 상태 확인
② 리소스를 자동 재배치
③ 클러스터에 등록된 모든 리소스를 나열
④ fencing 설정 내역 확인
⑤ 노드별 자원 할당 변경

정답: ③
해설: pcs resource show, crm_resource 명령 등을 통해 현재 클러스터에 등록된 리소스 목록을 조회할 수 있다.

🔹 문항 15. (장애 대응)

Kubernetes 클러스터에서 Control Plane 노드 3개 중 2개가 장애 날 경우 발생할 수 있는 영향은?

① etcd는 정상이나, DNS가 다운된다
② 전체 서비스는 정상이나 로깅 기능만 제한된다
③ etcd Quorum 부족으로 클러스터 상태 변경 불가
④ kubelet이 자동 복구된다
⑤ 노드 간 통신을 위해 Calico를 재시작해야 한다

정답: ③
해설: etcd는 클러스터 구성원의 과반수 Quorum이 필요하므로, 3개 중 2개가 다운되면 클러스터 상태 변경 불가 (읽기만 가능하거나 완전 불능)

🔹 문항 16. (서비스 이해)

다음 중 클러스터링에서 사용하는 “fencing” 기술의 주요 목적은?

① 로드밸런싱 처리 속도 향상
② 패치 시점 자동 감지
③ 비정상 노드를 강제 종료하여 서비스 보호
④ 방화벽 외부 접근 허용
⑤ 리소스 풀의 메모리 재분배

정답: ③
해설: fencing은 비정상 노드가 리소스를 계속 점유하지 못하도록 강제 차단 또는 재부팅하여 장애 확산을 방지하는 기술이다.

🔹 문항 17. (구성 판단)

Active/Passive 클러스터링 구성 시, 리소스 이전(페일오버)을 제어하는 우선순위 설정은 어느 항목에 지정되는가?

① Storage Class
② DNS 레코드
③ Preferred Owner 설정
④ RunAs 정책
⑤ API Rate Limit 설정

정답: ③
해설: Windows Cluster에서는 Preferred Owner 항목을 통해 특정 리소스를 어떤 노드에서 우선 구동할지 지정 가능하다.

🔹 문항 18. (장애 대응)

Pacemaker에서 특정 리소스가 계속해서 Active 상태로 남아 있는 이유로 가장 가능성 높은 것은?

① 리소스에 대한 location constraint가 설정되어 있음
② 해당 노드에 STONITH가 미설정되어 있음
③ fencing 모듈이 업데이트 되지 않음
④ systemd와의 충돌
⑤ Cluster IP의 DNS TTL 설정 오류

정답: ①
해설: location constraint는 특정 리소스를 특정 노드에서만 실행되도록 제한하므로, failover가 발생하지 않고 고정될 수 있음.

🔹 문항 19. (서비스 이해 + 구성 판단)

Kubernetes에서 클러스터 내 트래픽을 안정적으로 분산시키기 위해 Control Plane 외에 반드시 구성해야 하는 컴포넌트는?

① Load Balancer 또는 Ingress Controller
② Calico 또는 Flannel 등의 CNI
③ CSI 드라이버
④ CoreDNS
⑤ etcd Snapshot

정답: ①
해설: 트래픽 분산은 Ingress Controller 또는 Load Balancer가 수행하며, CNI는 Pod 간 네트워크 연결만 처리함.

🔹 문항 20. (장애 대응)

다음 중 클러스터 VIP가 특정 노드에만 고정되어 Failover 되지 않는 경우, 원인으로 가장 적절한 것은?

① 로컬 DNS 캐시
② VIP에 대한 리소스 리스너가 중복 설정됨
③ 해당 노드의 Routing Table 우선순위
④ VIP 리소스에 Preferred Node Constraint가 설정되어 있음
⑤ 클러스터 Shared Disk의 UUID 충돌

정답: ④
해설: VIP에 Preferred Node가 강제 지정되어 있으면 장애가 발생해도 다른 노드로 이전되지 않음.

✅ 전체 클러스터링 문제 요약 (문항 1~20)

  • 서비스 이해: Quorum, STONITH, VIP, K8s HA, fencing 등
  • 구성 판단: NSG 구성, NIC 설정, preferred owner, resource constraints
  • 장애 대응: Failover 실패, VIP 전환 실패, Split Brain, etcd quorum 상실

 

📘 클러스터링(Clustering) 개념 – TA 실무 관점 요약

✅ 1. 클러스터링의 정의

**클러스터링(Clustering)**은 두 대 이상의 서버(노드)를 논리적으로 하나처럼 묶어, 서비스의 고가용성(HA), 무중단 운영, 부하 분산 등을 구현하는 기술입니다.

✅ 2. 주요 목적과 유형

분류설명
고가용성(HA) 하나의 노드가 장애가 발생해도, 다른 노드가 서비스를 이어받아 중단 없이 운영 가능
부하 분산(Load Balancing) 여러 노드에 트래픽을 나누어 분산 처리 (예: 웹 서버 클러스터)
병렬처리 (HPC) 병렬 계산/과학연산용으로 연산 노드 분산 사용 (TA 시험에는 거의 없음)

✅ 3. 대표 클러스터링 솔루션/방식

환경클러스터링 방식설명
Windows Failover Cluster Quorum 기반, Active/Passive 구성, VIP 자동 전환
Linux Pacemaker + Corosync 리소스 기반 HA 구성, STONITH 등 fencing 포함
Kubernetes etcd 기반 Control Plane etcd quorum 기반 분산 관리, HA load balancer 필요
HAProxy + Keepalived VIP 기반 Active/Passive Web/WAS 단에서 자주 사용되는 구성
DRBD + Pacemaker Block-Level 스토리지 복제 + HA 스토리지 레벨 이중화 + 서비스 연속성

✅ 4. 핵심 구성 요소

요소설명
Quorum 클러스터 노드 간 “다수결”로 정상 상태 판단 (홀수 권장)
VIP (Virtual IP) 서비스 접근을 위한 가상 IP, 장애 시 다른 노드로 전환
STONITH / Fencing 비정상 노드 강제 차단 (재부팅/전원OFF 등)
Preferred Owner / Constraint 리소스 실행 우선순위 지정 또는 특정 노드 고정
Shared Storage 스토리지 자원을 여러 노드가 공동 사용, 장애 조치 시 유지 필요

✅ 5. 장애 유형과 대응 방식

장애 유형영향대응
Split-Brain 두 노드가 모두 마스터로 오인하여 데이터 충돌 Quorum, STONITH 설정으로 방지
VIP 전환 실패 서비스 연결 불가 Health check 및 fencing 연동 여부 확인
etcd Quorum 상실 Kubernetes 전체 API 동작 불가 홀수 구성, 상태 모니터링 필수
Failover 미동작 리소스 비가동 리소스 속성 자동 시작 설정 확인

✅ 6. TA 평가에서 자주 출제되는 포인트

  • Quorum 구성 및 판단 기준
  • VIP 전환 실패 시 원인
  • STONITH 구성 방식 및 필요성
  • 클러스터링 구성에 적절한 네트워크 분리 전략
  • Kubernetes Control Plane 구성 시 etcd 동작 방식
  • Active/Passive 구조 판단 및 설정 항목

이제 이 기반 위에, 스토리지 분야의 TA 문제 20문항을 구성해 드리겠습니다.
클러스터링과 스토리지 장애 대응, 스토리지 이중화 구성, 스토리지 유형 선택 등이 유기적으로 연결되도록 설계할 예정입니다.

아래는 스토리지(Storage) 분야의 TA 역량평가 스타일 문제 20문항 세트입니다.
각 문항은 실무 기반으로 구성되어 있으며, ① 서비스 이해 + ② 구성 판단 + ③ 장애 대응 고려 요소를 포함합니다.
문제 유형은 객관식/단답형/시나리오형 혼합이며, 정답과 해설도 함께 제공합니다.

📘 TA 역량평가 – 스토리지 분야 문제 (1~20)

🔹 문항 1. (서비스 이해)

스토리지 시스템에서 RAID 10 구성의 장점으로 올바른 것은?

① 디스크 공간 활용률이 매우 높다
② 단일 디스크 장애에 대한 복구가 불가능하다
③ 성능과 이중화를 동시에 제공한다
④ 패리티를 통한 복구 시간을 단축한다
⑤ 블록 단위 압축으로 IOPS를 향상시킨다

정답: ③
해설: RAID 10은 미러링(RAID 1) + 스트라이핑(RAID 0)을 결합하여 성능과 이중화를 동시에 만족함.

🔹 문항 2. (구성 판단)

SAN(Storage Area Network) 구성에서 iSCSI 기반 스토리지 연결 시 고려해야 할 항목이 아닌 것은?

① 별도의 전용 네트워크 구성
② Jumbo Frame 설정
③ iSCSI Target 설정
④ 파일시스템 캐시 비활성화
⑤ iSCSI Initiator 활성화

정답: ④
해설: 파일시스템 캐시는 OS의 I/O 처리 방식이며, iSCSI 설정과는 무관하다.

🔹 문항 3. (서비스 이해)

스토리지 계층에서 **블록 스토리지(Block Storage)**의 특징은?

① REST API 기반 접근
② 파일 시스템을 포함하여 NAS처럼 작동함
③ VM 디스크, DB, 트랜잭션 저장에 적합
④ 오브젝트를 메타데이터와 함께 저장함
⑤ 브라우저에서 직접 접근 가능

정답: ③
해설: 블록 스토리지는 고성능 IO가 필요한 VM, DB 등에 사용되며, 파일 시스템은 OS에서 지정함.

🔹 문항 4. (구성 판단)

Azure 또는 AWS에서 스토리지 성능을 보장하려면 어떤 구성 요소가 가장 큰 영향을 미치는가?

① 리소스 그룹 이름
② 인스턴스 태그 개수
③ 디스크 유형 및 사이즈
④ 할당된 퍼블릭 IP 수
⑤ 테넌트 설정

정답: ③
해설: 스토리지 성능은 디스크 유형(예: Standard/Premium SSD)과 크기(IOPS 단위 등)에 따라 결정됨.

🔹 문항 5. (장애 대응)

스토리지 장애 시 OS에서 mount 명령어로 마운트되지 않고 “device busy” 오류가 반복될 때 확인해야 할 요소는?

① /etc/hosts의 DNS 설정
② 해당 디바이스가 열린 프로세스 여부
③ syslog 디스크 용량
④ NIC 상태
⑤ grub 설정

정답: ②
해설: 해당 디바이스가 기존에 열린 파일 핸들 또는 프로세스에 의해 사용 중이면 busy 상태로 마운트 불가.

🔹 문항 6. (서비스 이해)

스토리지 시스템에서 Thin Provisioning의 주된 목적은?

① 스냅샷 성능 향상
② 중복 제거 방식 구현
③ 실제보다 큰 논리 용량 제공
④ 디스크 오류 예측
⑤ RAID5 복구 속도 향상

정답: ③
해설: Thin Provisioning은 실제 물리 공간보다 큰 논리적 용량을 미리 할당해 유연한 공간 관리를 지원함.

🔹 문항 7. (구성 판단)

클러스터 환경에서 스토리지 장애 발생 시 Failover 후에도 마운트가 실패한다면 우선 확인할 설정은?

① Storage Zoning 정보
② 클러스터 Heartbeat 주소
③ VIP TTL 값
④ 마운트 대상 디렉터리 소유권
⑤ UUID 또는 LVM ID 매핑

정답: ⑤
해설: 노드 간 LVM ID 또는 UUID 매핑이 다르면 동일 디스크라도 마운트 실패 가능성이 있음.

🔹 문항 8. (장애 대응)

NAS 장애 발생 후, 공유 디렉터리가 잠시 연결되었다가 다시 끊기는 현상이 반복된다. 우선 점검할 항목은?

① 방화벽 ICMP 설정
② DNS 캐시
③ NFS 서버의 timeout 및 retry 설정
④ Storage Zoning 정책
⑤ 사용자 계정 권한

정답: ③
해설: NFS 연결 지연이나 끊김은 timeo, retry 등의 마운트 옵션 설정과 밀접한 관련이 있음.

🔹 문항 9. (서비스 이해)

스토리지에서 오브젝트 스토리지(Object Storage)의 특징으로 적절한 것은?

① NAS처럼 디렉터리 구조를 사용한다
② iSCSI 프로토콜을 사용한다
③ 정형화된 메타데이터로 관리된다
④ LUN 단위로 할당된다
⑤ VM 부팅 디스크로 사용된다

정답: ③
해설: 오브젝트 스토리지는 메타데이터 기반으로 관리되며, REST API 접근이 가능하다.

🔹 문항 10. (구성 판단)

스토리지 이중화 구성에서 Active-Active와 Active-Passive 구조 비교 시 올바른 설명은?

① Active-Active는 관리 포인트가 적어 운영이 단순하다
② Active-Passive는 두 노드 모두에서 동일 자원을 동시에 접근한다
③ Active-Active는 Failover 시 서비스 중단 없이 부하 분산이 가능하다
④ Active-Passive는 스토리지 용량이 자동으로 증가된다
⑤ 두 구조는 장애 대응 측면에서 동일하게 동작한다

정답: ③
해설: Active-Active는 정상 운영 중 두 노드가 각각 요청을 처리하며, Failover 시 중단 없이 전환 가능

.
모든 문항은 서비스 이해 + 구성 판단 + 장애 대응을 실무 관점에서 반영했습니다.

📘 TA 역량평가 – 스토리지 분야 문제 (11~20)

🔹 문항 11. (서비스 이해)

스토리지 환경에서 Zoning의 주된 목적은?

① 네트워크 대역폭 제어
② 특정 VLAN 분리
③ 스토리지와 호스트 간 경로 제어 및 보안
④ 백업 경로 자동 선택
⑤ DNS 기반 스토리지 연결

정답: ③
해설: SAN 환경에서는 Zoning을 통해 HBA와 스토리지 포트 간 통신을 제어, 보안 및 경로 통제를 수행함.

🔹 문항 12. (구성 판단)

스토리지 가상화 솔루션(SDS, Software Defined Storage) 구성 시 장점이 아닌 것은?

① 스토리지 하드웨어에 종속되지 않는다
② 자동화된 데이터 계층화를 지원할 수 있다
③ 특정 스토리지 벤더의 기능에 의존한다
④ 오픈소스 기반의 확장이 가능하다
⑤ 관리 플랫폼을 통해 통합 운영이 가능하다

정답: ③
해설: SDS는 다양한 하드웨어를 통합 관리하며 벤더 종속성을 줄이는 목적으로 설계됨.

🔹 문항 13. (장애 대응)

iSCSI SAN 구성에서 LUN이 연결되지 않고 multipath -ll 명령어에서 “faulty” 상태로 나타날 경우 우선 확인할 사항은?

① LUN UUID 중복
② iSCSI Session 여부
③ FQDN 오류
④ 인증서 만료
⑤ sysctl.conf 설정 누락

정답: ②
해설: multipath에서 “faulty” 상태는 iSCSI 세션 연결 실패가 원인인 경우가 많음. iscsiadm 등으로 세션 확인 필요.

🔹 문항 14. (서비스 이해)

스토리지 복제(Replication) 기술에서 Async 방식의 특징으로 옳은 것은?

① 실시간 복제를 보장한다
② 대규모 DB 환경에 적합하지 않다
③ 복제 지연이 있을 수 있다
④ 항상 동일 Region 내에서만 지원된다
⑤ 데이터 정합성이 절대 보장된다

정답: ③
해설: Async 복제는 일정 주기 또는 버퍼 기반 전송이므로, 네트워크/부하에 따라 지연 발생 가능성 있음.

🔹 문항 15. (구성 판단)

스토리지를 장애 복구(DR) 구조로 설계할 때 RTO/RPO 측면에서 가장 우선적으로 고려할 항목은?

① 파일 시스템 종류
② 백업 스케줄
③ 데이터 복제 주기 및 스토리지 네트워크 대역폭
④ 사용자 그룹 정책
⑤ 시스템 로그 보존 기간

정답: ③
해설: RTO/RPO는 복제 주기(=RPO 결정 요소), **복구 속도(=RTO)**와 관련된 네트워크 및 성능 요소가 핵심이다.

🔹 문항 16. (장애 대응)

LVM 기반 스토리지를 사용하는 서버에서 lvextend 후 파일 시스템 크기가 반영되지 않는 이유는?

① VG 용량이 부족함
② UUID 충돌
③ 파일 시스템 리사이즈 명령을 실행하지 않음
④ Shared Disk 충돌
⑤ mount 옵션 누락

정답: ③
해설: lvextend는 LVM 영역만 확장할 뿐이며, resize2fs, xfs_growfs 등의 파일 시스템 리사이즈 명령이 별도로 필요하다.

🔹 문항 17. (서비스 이해)

스토리지에서 Snapshot의 특징으로 적절하지 않은 것은?

① 특정 시점의 데이터를 빠르게 복구할 수 있다
② 실제 데이터 없이 메타데이터만 복사되는 방식도 있다
③ Snapshot을 남용하면 성능 저하와 공간 고갈이 발생할 수 있다
④ Snapshot은 백업을 완전히 대체한다
⑤ 삭제되면 복구가 어렵다

정답: ④
해설: Snapshot은 백업을 보완하는 기능이지, 백업을 대체할 수 없다. 스냅샷 자체도 스토리지 장애에 취약할 수 있음.

🔹 문항 18. (구성 판단)

다음 중 스토리지 성능 병목 현상을 해결하는 가장 직접적인 방법은?

① NIC MAC 주소 재설정
② 디스크 IOPS 향상
③ cron 잡 재스케줄
④ CPU 코어 수 증가
⑤ DNS TTL 축소

정답: ②
해설: IOPS는 디스크의 초당 입출력 횟수로, 스토리지 병목 원인일 경우 디스크 성능(또는 병렬 처리)을 개선해야 함.

🔹 문항 19. (장애 대응)

스토리지 마운트 오류가 지속되고 있고, dmesg 로그에 I/O error와 함께 블럭 장치 오류가 반복되는 경우 조치 순서는?

① 디스크 복구 명령(fsck) 실행
② IOPS 측정
③ mount 강제 옵션 추가
④ 해당 디바이스 언마운트 후 포맷
⑤ 커널 재부팅

정답: ①
해설: I/O error는 파일 시스템 손상 또는 디바이스 오류 가능성이 크므로, fsck 등 디스크 검사 및 복구가 우선됨.

🔹 문항 20. (서비스 이해 + 구성 판단)

Object Storage의 특징 중 하나인 "Eventually Consistent" 모델의 의미는?

① 데이터가 즉시 모든 노드에 반영된다
② 항상 정합성이 유지된다
③ 일시적 비정합이 발생할 수 있으나 시간이 지나면 일치한다
④ 읽기 전용 데이터만 보장된다
⑤ 특정 사용자만 접근 가능하다

정답: ③
해설: Eventually Consistent는 글로벌하게 분산된 시스템에서 일시적인 정합성 지연이 있지만 결국 일치함을 의미함.

 

좋습니다! 아래는 스토리지(Storage) 분야에 대해 TA(Technical Architect) 실무 역량 관점에서 정리한 요약본입니다.
이 정리는 TA 시험, 실무 설계, 장애 대응, 블로그 오픈북 정리 등에 바로 활용하실 수 있도록 구조화했습니다.

📘 스토리지 분야 요약 – TA 역량 관점

✅ 1. 스토리지 유형별 개념 및 활용

구분설명주요 용도
Block Storage OS나 DB에서 사용되는 디스크 단위의 스토리지 VM 디스크, DB 저장소 (고속 IOPS)
File Storage (NAS) 파일 단위 공유 저장소, SMB/NFS 등 공유 폴더, 사용자 파일 서버
Object Storage REST API 기반, 메타데이터와 객체 저장 백업, 이미지, 로그, 비정형 데이터
Local Disk 물리 서버 또는 VM 내 로컬 디스크 임시 파일, 캐시 (비이중화)

✅ 2. 스토리지 주요 기술 용어

용어설명
RAID 디스크 이중화 및 성능 확보 구성 (RAID 1/5/10 등)
Zoning SAN 구성에서 HBA 포트 간 연결 제어 (보안, 성능 분리)
Multipathing SAN 구성 시 경로 이중화 (failover 대비)
LVM 논리 볼륨 관리 (디스크 확장, Snapshot 등)
Snapshot 특정 시점의 데이터 상태를 저장 (즉시 복구용)
Thin Provisioning 실제 공간보다 큰 논리 공간 할당 (유동적 운영)
Replication 주/보조 스토리지 간 데이터 복제 (Sync/Async)
SDS (Software Defined Storage) 하드웨어 독립형 스토리지 가상화 관리 솔루션

✅ 3. 클러스터 환경에서의 스토리지 고려 요소

  • Shared Storage 필요 여부: Active/Passive 구조에서는 노드 간 공유 디스크 필요
  • Failover 시 LVM/UUID 일치 여부: 클러스터 노드 간 동일 ID로 인식되어야 정상 마운트
  • VIP와 스토리지 연결: VIP 전환 시 스토리지도 함께 연결될 수 있어야 함
  • Fencing 연동: 스토리지 일관성 보호를 위해 비정상 노드 강제 제거 필요

✅ 4. 장애 유형별 원인과 대응

장애 증상주요 원인조치 방안
mount 실패 + device busy 열린 프로세스 존재 lsof, fuser로 확인 후 종료
NFS 간헐적 연결 끊김 마운트 옵션 문제 timeo, retry, hard/soft 설정 확인
LUN 인식 안됨 zoning/multipath 설정 오류 multipath -ll, iscsiadm 확인
I/O error, 블럭 디바이스 오류 파일 시스템 손상 fsck, xfs_repair 등 복구
용량 부족 → 앱 장애 Thin Provisioning 과잉 할당 모니터링 + 알림 정책 설정 필요
Snapshot 삭제 불가 상호 참조 or 공간 부족 의존 관계 확인, 공간 확보

✅ 5. 클라우드 스토리지 특성 (Azure/AWS 기준)

항목설명
Premium SSD 고성능, 고IOPS 디스크 (DB, 트랜잭션 서버에 적합)
ZRS (Zone-redundant storage) 리전 내 3개 AZ에 복제
LRS (Locally redundant) 동일 데이터센터 내 3중 복제
Blob Tier Hot/Cold/Archive로 구분되는 오브젝트 저장소
Snapshot/Backup VM, 디스크, 파일 수준 스냅샷 가능
Mountable File Share (Azure Files, EFS) NFS/SMB로 마운트 가능한 클라우드 파일 스토리지

✅ 6. 자주 출제되는 TA 시험 포인트

  • RAID 종류 비교 및 상황별 선택 (RAID 1 vs RAID 10 등)
  • iSCSI 구성 시 Initiator/Target 개념 및 설정 순서
  • NAS 마운트 지연 이슈 분석 (mount, timeo, hard/soft)
  • 스토리지 이중화 구성 설계 (Active-Active, Active-Passive 차이)
  • Snapshot의 성능 영향, 복제(Sync/Async)의 차이
  • 장애 상황에서의 I/O error, multipath faulty, device busy 원인 분석
  • 클라우드 디스크 성능 영향 요소 (디스크 타입, 크기, VM 유형 등)

✅ 마무리 요약

  • 블록 vs 파일 vs 오브젝트 스토리지 구분은 매우 중요
  • 스토리지 구성 시 반드시 성능(IOPS), 이중화, 장애 전환(Failover) 고려
  • TA 관점에서는 단순 스토리지 연결보다 "서비스 연속성 관점에서의 설계/복구 능력"이 핵심 평가 포인트


→ 예: API Gateway, Backup & Recovery, 보안 및 인증, Telemetry, Kubernetes Storage 등

📘 API Gateway 개념 정리 – TA 역량 관점

✅ 1. API Gateway란?

API Gateway는 클라이언트의 요청을 받아 백엔드 서비스(Microservice, Function, Application 등)로 라우팅, 인증, 트래픽 제어, 로깅, 보안 등의 기능을 수행하는 중앙 통제 지점입니다.
→ 일종의 Reverse Proxy + 정책 관리자 역할 수행

✅ 2. 주요 기능 정리

기능설명
라우팅(Routing) URI, Method, Header, Query 기반으로 서비스에 트래픽 분배
인증/인가(Authentication/Authorization) JWT, OAuth2.0, API Key 등 기반 사용자 인증
속도제한(Rate Limiting) IP, 사용자별 요청 수 제한으로 오용 방지
로깅 및 모니터링 모든 요청에 대한 로그 기록 및 상태 추적
보안 강화 WAF 연계, CORS 정책, HTTPS 강제, Payload 검사
API 버전 관리 /v1, /v2와 같이 API 변경 이력 관리
변환(Transformation) 요청 또는 응답 포맷 변경 (예: JSON→XML)
캐싱(Caching) 동일한 요청 결과 캐시로 성능 향상

✅ 3. 주요 구성 방식

구성 방식설명
Path-based Routing 경로(URL path) 기준으로 백엔드 라우팅
Host-based Routing 요청 도메인에 따라 라우팅
Filter 기반 구성 요청/응답에 대해 사전/사후 필터 적용 (Spring Cloud Gateway 등)

✅ 4. 대표 API Gateway 제품

제품특징
Kong 플러그인 기반 확장성, 클라우드/온프렘 지원
AWS API Gateway Lambda, EC2 연계, 인증/스테이지 관리
Azure API Management 보안 정책, 스케일아웃, 개발자 포털 제공
NGINX + Lua 경량화된 커스텀 게이트웨이 가능
Spring Cloud Gateway Java 기반 MSA 환경에서 사용 용이

✅ 5. TA 관점 출제 포인트

  • Path vs Host 기반 라우팅 구성 판단
  • Rate Limit 정책 설계
  • API Key/JWT 인증 흐름
  • Filter 체인 동작 순서
  • 장애 발생 시 라우팅 실패 원인 분석
  • API Gateway + Service Mesh 구성 차이
  • 클라우드 기반 API Gateway의 정책 관리 기능

📝 API Gateway 예상문제 20문항 (정답/해설 포함)

📌 문항 1

API Gateway의 주요 목적이 아닌 것은?
① 로드밸런싱
② 보안 정책 적용
③ 데이터베이스 병합
④ 인증 및 인가 처리
⑤ 요청 로깅 및 모니터링

정답: ③
해설: DB 병합은 API Gateway 역할이 아니며, 보통 백엔드 마이크로서비스에서 처리한다.

📌 문항 2

API Gateway에서 Rate Limiting 기능의 주요 목적은?
① 사용자 인증을 위함
② 요청 속도를 높이기 위함
③ 백엔드 과부하 방지 및 트래픽 제어
④ 데이터베이스 이중화
⑤ API 버전 관리 자동화

정답: ③

📌 문항 3

Spring Cloud Gateway에서 Filter가 적용되는 순서는?
① Pre → Global → Route → Post
② Route → Pre → Post
③ Global Filter → Route Filter
④ Pre Filter → Route Filter → Post Filter
⑤ Post Filter → Pre Filter → Global Filter

정답: ④

📌 문항 4

API Gateway에서 JWT 인증을 사용하는 이유는?

① 오브젝트 스토리지 접근용
② 정적 파일 캐싱
③ 무상태 인증 구현
④ 스레드 동기화
⑤ 로그 집계

정답: ③

📌 문항 5

다음 중 Azure API Management의 기능이 아닌 것은?
① 정책 기반 요청 제한
② 개발자 포털 제공
③ API Key 발급
④ 리소스 그룹 생성
⑤ 로깅/분석 연동

정답: ④
해설: 리소스 그룹은 Azure 인프라 레벨 관리 개념이다.

📌 문항 6

API Gateway 장애 시 발생 가능한 문제는?
① DNS 해석 실패
② 모든 요청이 직접 백엔드에 전달
③ 인증 우회 발생
④ 포트 포워딩 중단
⑤ L4 스위칭 실패

정답: ②

📌 문항 7

Path-based Routing 예시로 올바른 것은?
① GET /product/v1/* → product-service
② api.company.com → routing-service
③ X-API-KEY: abc123 → auth-service
④ v1.user.com → user-service
⑤ Header: lang=en → locale-service

정답: ①

📌 문항 8

API Gateway에서 Cache를 사용할 때 고려할 항목이 아닌 것은?
① 응답 코드
② TTL(Time to Live)
③ 요청 ID
④ URL Path
⑤ 사용자 인증 정보

정답: ③
해설: 요청 ID는 고유 식별용으로 캐싱과는 무관함.

📌 문항 9

클라이언트가 여러 API 서버와 직접 통신하지 않고 API Gateway만 통해 통신하도록 하는 이유는?
① 비용 증가 방지
② 로컬 DNS 활용
③ 보안 및 라우팅 통합 관리
④ 브라우저 캐시 최적화
⑤ NAT 테이블 최소화

정답: ③

📌 문항 10

API Gateway에 인증 로직을 위임할 때 얻는 장점은?
① 클라이언트 코드 간소화
② DB 트랜잭션 향상
③ 파일 처리 속도 증가
④ 로드밸런서 간소화
⑤ IP 포워딩 가속화

정답: ①

👉 문항 11~20번은 다음 응답에서 이어서 제공됩니다.
(이후 Word/PDF 문서로 제공 가능, 정답 숨김 버전도 가능)

나의 말:

azure 기반으로 api gate way 를 설명해줘

ChatGPT의 말:

좋습니다. 아래는 Azure 기반 API Gateway, 즉 **Azure API Management (Azure APIM)**에 대한 TA 실무 관점 설명입니다.

📘 Azure API Management (Azure APIM) 개요

✅ 1. 정의

**Azure API Management (APIM)**는 마이크로서비스 아키텍처 및 다양한 백엔드 서비스를 대상으로 API를 안전하게 게이트웨이화하고, 모니터링하며, 배포와 운영을 단순화할 수 있는 PaaS 서비스입니다.

👉 API Gateway + Developer Portal + 정책 엔진 + 인증/인가/로깅 기능을 통합한 API Lifecycle 플랫폼

✅ 2. 주요 구성 요소

구성 요소설명
Gateway API 호출을 수신하고 정책을 적용한 후 백엔드로 전달
Publisher Portal (관리자) API 정의, 정책 설정, 사용자 관리 등 수행
Developer Portal 외부 개발자용: 문서 확인, 테스트, 키 발급
Policies 요청/응답에 적용할 보안, 속도제한, 캐싱 등 처리 규칙
Products API들을 묶어서 제공하는 단위. 요금제와 접근제어 연계 가능

✅ 3. 주요 기능

기능설명
인증 및 보안 OAuth2.0, JWT, API Key 기반 인증. IP 필터링, CORS 등 지원
요청 제한(Rate Limit) 초당 요청 수 제한, 사용자별 제한 등 설정 가능
트래픽 제어 Load balancing, throttling, retry 등 제어 정책 설정
변환 기능 요청/응답 포맷(JSON↔XML), Header/Query 변경
API 버전 관리 v1, v2 등의 버전 구분, 경로 또는 쿼리 기반
로깅 및 모니터링 Azure Monitor, Application Insights 연계 가능
백엔드 추상화 백엔드 URL을 숨기고 단일 Gateway로 통합 제공 가능

✅ 4. 배포 모드 (스케일 모델)

모드특징
Developer 1인 개발용 (비용 없음, SLA 없음)
Basic / Standard / Premium SLA 보장, 확장 가능, VNET 연계 가능 (Premium부터)
Self-hosted Gateway 온프레미스 또는 Kubernetes에 게이트웨이 런타임 설치 가능

✅ 5. 정책(Policies) 예시

 
<policies> <inbound> <rate-limit calls="10" renewal-period="60" /> <validate-jwt header-name="Authorization" ... /> </inbound> <backend> <set-backend-service base-url="https://my-backend.azurewebsites.net" /> </backend> <outbound> <set-header name="X-Powered-By" exists-action="override"> <value>Azure API Gateway</value> </set-header> </outbound> </policies>

👉 XML 기반으로 유연하게 정책 구성 가능

✅ 6. 실무 적용 시나리오 예시

시나리오APIM 적용 방식
서로 다른 백엔드 서비스를 하나의 API 엔드포인트로 통합 다수의 API를 경로 기반으로 묶고, 단일 Gateway 제공
외부 고객에게 API 제공 시 Developer Portal을 통해 API 문서, 테스트, 키 발급 기능 제공
비용 및 부하 제어 Rate Limit 정책 설정 + Azure Monitor로 모니터링
API 인증 일원화 Gateway에서 JWT 또는 OAuth2.0 인증 수행 후 백엔드 전달

✅ 7. TA 시험/실무 평가 포인트

  • Azure APIM 구성 요소 간 역할 구분 가능해야 함
  • 정책(XML Policy) 구성 로직 이해 필수
  • API 버전 관리 및 인증 적용 방식 선택 가능해야 함
  • Failover, 캐싱, 로깅 연계 방식 파악 필요
  • Azure Functions, Logic Apps 등과 연동한 API 구성 경험

다음으로 무엇을 도와드릴까요?

  • 📄 Word/PDF 요약본 출력
  • 🧪 Azure API Gateway 기반 TA 문제 20문항 세트 (이전 일반 문제 이어서 구성 가능)
  • 🎯 실무 시나리오 기반 장애 대응 문제
  • 🧠 암기카드 요약
  • 📚 키워드 인덱스 블로그용 정리

예: “Azure APIM 기반 문제 이어서 만들어줘” 또는 “PDF로 저장해줘” 등 원하시는 방식으로 요청해 주세요.

나의 말:

이어서 문제 만들어줘

ChatGPT의 말:

좋습니다! 이어서 **Azure 기반 API Gateway(Azure API Management)**를 중심으로 한 TA 실무 문제 11번~20번을 제공하겠습니다.
앞서 110번 문제는 API Gateway 전반적인 이해 중심이었다면, 이번 1120번은 Azure APIM 구성 요소, 정책(policy), 인증, 장애 대응 등 실무 중심으로 구성했습니다.

📝 Azure API Management 기반 예상문제 (문항 11~20)

📌 문항 11

Azure APIM의 정책(Policy) 기능 중 rate-limit의 주요 목적은?

① 사용자 인증 수행
② 요청당 응답 크기 제한
③ 요청 횟수 제한 및 트래픽 보호
④ 백엔드 DB 트랜잭션 제어
⑤ API 버전 자동 설정

정답: ③
해설: rate-limit는 일정 시간 내 호출 횟수를 제한하여 서비스 보호 및 오용 방지를 수행함.

📌 문항 12

Azure API Management에서 API 버전 관리 방식으로 가장 적절한 것은?

① JWT Claim을 통한 버전 설정
② 동시 API Key 사용
③ 경로 기반(path) 버전 관리
④ VM 태그 설정
⑤ L7 Load Balancer 사용

정답: ③
해설: APIM은 /v1, /v2 등 경로 기반(path-based) 또는 query string, header 기반 버전 관리를 지원함.

📌 문항 13

Azure APIM에서 요청을 인증하는 정책으로 적절한 것은?

① validate-jwt
② add-header
③ set-body
④ remove-query-param
⑤ rewrite-uri

정답: ①
해설: validate-jwt는 Authorization Header에 담긴 JWT 토큰을 서명 키와 claim 조건을 기준으로 검증함.

📌 문항 14

Azure APIM에서 Developer Portal의 목적은?

① API 요청을 직접 라우팅
② 외부 개발자가 API 사용을 테스트하고 키를 발급받는 포털
③ 백엔드 관리자가 정책을 구성하는 포털
④ IPSec 연결 제어용
⑤ RBAC 정책을 조정하는 콘솔

정답: ②

📌 문항 15

APIM에서 inbound → backend → outbound 순서의 정책 처리 흐름에서 응답 변환 작업을 수행할 위치는?

① inbound
② backend
③ outbound
④ error
⑤ routing

정답: ③
해설: outbound 단계는 백엔드의 응답을 클라이언트로 전달하기 전에 필터링/변환할 수 있는 지점임.

📌 문항 16

다음 중 Azure API Management에서 “Self-hosted Gateway”를 사용하는 주요 이유는?

① 높은 처리량
② Kubernetes 내부에서 API Gateway 사용
③ Developer Portal 제거
④ VPN 우회 설정
⑤ Web App 연동 제한

정답: ②
해설: Self-hosted Gateway는 온프렘 또는 컨테이너 환경(Kubernetes 등)에서 APIM의 Gateway 기능만 배포하여 사용할 수 있음.

📌 문항 17

Azure API Management에서 set-backend-service 정책의 목적은?

① 인증서 무효화
② 요청 거부
③ 백엔드 서비스 URL을 설정하거나 재정의
④ 쿠키 삭제
⑤ 캐시 TTL 설정

정답: ③

📌 문항 18

Azure API Management에서 장애 발생 시 다음 중 가능한 원인이 아닌 것은?

① 정책 구문 오류(XML 형식)
② Backend 서비스 미연결
③ JWT 서명키 변경 누락
④ Azure Front Door 연결 설정 누락
⑤ Redis 클러스터 장애

정답: ⑤
해설: Redis는 APIM과 직접 연동되지 않으며, APIM 장애와는 관련이 없음.

📌 문항 19

API Management에서 요청 헤더를 기반으로 라우팅 정책을 구성하려면 어떤 정책 요소를 사용해야 하는가?

① set-header
② choose
③ validate-parameters
④ rewrite-uri
⑤ cache-lookup

정답: ②
해설: choose 정책은 조건문과 유사하게 작동하여, 헤더/쿼리/경로 조건에 따라 분기 처리를 수행함.

📌 문항 20

Azure API Management를 사용하는 환경에서 백엔드 API가 느린 응답을 반환할 경우 대응 방법으로 가장 적절한 것은?

① CORS 정책 강화
② API Gateway에 LRU 캐시 적용
③ Azure Functions로 자동 우회
④ 요청에 Timeout 정책 설정 및 fallback 구성
⑤ 인증서 키를 재생성

정답: ④
해설: 백엔드 지연 대응을 위해 timeout 및 fallback 정책을 설정하여 지속 가능한 응답을 유도함.

✅ 요약

문항 범위주요 주제
11~13 정책 구성 (rate-limit, validate-jwt 등)
14~16 Developer Portal, Self-hosted Gateway, 흐름 구조
17~19 정책 적용 위치, 조건 분기 처리
20 장애 대응 (timeout, fallback)

📌 이 문제들과 앞서 제공한 1~10번까지 합치면 총 20문항 완성입니다.

다음으로 도와드릴 수 있는 항목:

  • 📄 Word/PDF로 출력
  • 🎯 정답 숨김 연습용 버전 제작
  • 🧠 키워드 암기카드 요약
  • 🧪 실무 시나리오 기반 장애 대응 문제 제작
  • 📚 키워드 인덱스 정리 (블로그용)

예: “PDF로 만들어줘” 또는 “암기카드 만들어줘” 등 요청해주세요.

나의 말:

키워드 암기카드와 인덱스 정리해줘

ChatGPT의 말:

좋습니다! 아래는 **Azure API Gateway (Azure API Management)**에 대한 암기카드(Key-Point Flashcards) 및 키워드 인덱스 정리입니다.
시험 대비 뿐만 아니라 오픈북 블로그 검색용, Ctrl+F 참고서용으로도 바로 활용 가능합니다.

🧠 [암기카드] Azure API Gateway 핵심 키워드

개념설명 요약
API Gateway 역할 인증, 라우팅, 로깅, RateLimit, 변환 등 중앙 관리
Azure APIM 구성요소 Gateway / Publisher Portal / Developer Portal / Products / Policies
Policies XML 기반 요청/응답 처리 규칙. Inbound → Backend → Outbound 순
rate-limit 초당 요청 수 제한. 오용 방지 목적
validate-jwt JWT 토큰 유효성 검증 (Issuer, Audience 등 claim 포함)
Path-based Routing URL 경로 기반 라우팅 (/v1/product → product-api)
Header-based Routing choose 정책으로 조건 분기 가능
Developer Portal 외부 사용자용 테스트/문서/Key 발급 포털
Self-hosted Gateway Kubernetes, 온프렘 환경에서도 APIM 기능 사용 가능
Transformation 요청/응답 포맷 변경 (Header, Body, Query 수정 등)
Caching 응답 캐시 → TTL, 응답코드, 조건 기반 설정
API Versioning Path, Header, Query 기반 버전 분리 관리
set-backend-service 요청을 라우팅할 백엔드 URL 지정
fallback 정책 백엔드 오류 발생 시 대체 응답 제공
Azure Monitor 연계 로그, 성능, 장애 추적 가능 (APIM + App Insight)
Rate Limit 단위 Subscription, User, IP 단위 적용 가능
APIM Tier Developer(비용 無), Basic/Standard/Premium, VNET 통합은 Premium
CORS 설정 Cross-Origin 접근 허용 여부 설정
JWT 기반 인증 장점 무상태 인증 (stateless), API Gateway에서 검증 가능
정책 처리 흐름 inbound → backend → outbound → on-error

📚 [키워드 인덱스형 정리] – 블로그 오픈북 참고용

아래 인덱스는 Ctrl+F 검색 키워드로 바로 찾을 수 있도록 단어 위주로 구성했습니다.

📌 구성요소 키워드

  • Azure API Management
  • API Gateway
  • Publisher Portal
  • Developer Portal
  • Self-hosted Gateway
  • API Product
  • API Versioning

📌 정책 및 인증 키워드

  • Policy
  • validate-jwt
  • rate-limit
  • set-backend-service
  • inbound backend outbound
  • choose
  • rewrite-uri
  • jwt 인증
  • API Key

📌 운영 및 보안 키워드

  • Rate Limiting
  • Fallback
  • Caching
  • Transformation
  • Header Injection
  • CORS
  • Timeout 정책

📌 연계 및 확장 키워드

  • Azure Monitor
  • Application Insights
  • Virtual Network Integration
  • Azure Functions
  • Logic Apps

✅ 활용 팁

  • 위 암기카드는 단답형/객관식 준비에,
  • 아래 인덱스 키워드는 블로그 오픈북 환경에서 Ctrl+F 검색용으로 바로 활용 가능합니다.
  • 필요 시 PDF/Word 요약 정리본, 또는 정답 숨김 연습용 문제집으로 변환해드릴 수 있습니다.

다음으로 도와드릴까요?
예:

  • “정답 숨김용 연습 문제 PDF로 만들어줘”
  • “다음 분야 Telemetry 문제 20개 만들어줘”
  • “API Gateway 실전 시나리오형 문제로 확장해줘”

나의 말:

Azure Monitor Application Insights Virtual Network Integration Azure Functions Logic Apps 를 간략히 설명해줘

ChatGPT의 말:

물론입니다! 아래는 Azure 기반 아키텍처에서 자주 함께 사용되는 5가지 서비스에 대한 간략 정리입니다.
각각의 서비스는 API Gateway, APIM, 또는 마이크로서비스와 유기적으로 통합되며, 실무에서도 자주 연계됩니다.

📘 Azure 핵심 서비스 요약

1️⃣ Azure Monitor

클라우드 및 온프렘 자원의 로그, 성능, 진단 정보를 수집 및 분석하는 통합 모니터링 플랫폼

  • 용도: VM, AKS, APIM, Functions 등에서 수집한 메트릭과 로그를 통합 분석
  • 구성 요소: Metrics, Logs, Alerts, Workbooks, Diagnostic Settings
  • 특징:
    • Azure 리소스에 대한 통합 성능/진단 분석
    • Application Insights, Log Analytics와 연동
    • 자동 경고(Alert) 및 액션 그룹 설정 가능

2️⃣ Application Insights

애플리케이션 수준의 실시간 모니터링 도구 (Azure Monitor의 하위 서비스)

  • 용도: 웹 앱, API, Azure Function 등에서 응답 시간, 트랜잭션 흐름, 오류 추적
  • 주요 기능:
    • Dependency Map: API 호출 간 호출 관계 추적
    • Live Metrics: 실시간 요청/오류 확인
    • Distributed Tracing: 다중 서비스 호출 흐름 시각화
  • 장점: 코드 수정 없이 SDK 또는 자동 수집으로 연동 가능

3️⃣ Virtual Network Integration (VNet Integration)

Azure PaaS 서비스 (App Service, APIM 등)를 사설 가상 네트워크에 연결하기 위한 기능

  • 용도:
    • APIM → 내부 백엔드 서버 통신
    • Functions/App Service → Private DB 접근
  • 연결 방식:
    • Regional VNet Integration: 동일 리전에 존재
    • Gateway-required VNet: VNet Gateway 필요
  • 보안 강화: 인터넷 노출 없이 내부망을 통해만 통신 가능 (Private Link 또는 Service Endpoint와 병행 사용)

4️⃣ Azure Functions

서버리스(Serverless) 환경에서 코드 실행을 위한 이벤트 기반 실행 플랫폼

  • 특징:
    • 트리거 기반 실행: HTTP 호출, 큐/이벤트, 타이머 등
    • 과금: 실행 시간/리소스 기준으로 요금 책정 (초 단위 과금)
    • 무서버 관리: 인프라 관리 불필요
  • API Gateway 연동: Functions를 백엔드로 연결하여 API 처리 가능 (Lightweight Backend 처리에 유용)

5️⃣ Logic Apps

코드 없이 워크플로우(Workflow)를 구성할 수 있는 자동화 플랫폼

  • 용도:
    • 이벤트 기반 자동 처리
    • 외부 SaaS, API, DB, 이메일 등과 연동 및 자동화
  • 특징:
    • 수백 개의 커넥터 제공 (Office365, Twitter, SQL, SAP 등)
    • 조건문, 반복, 병렬 처리 등 복잡한 로직 구성 가능
  • API Gateway 연동: Logic App을 백엔드로 연결하여 외부 API 호출 자동화 가능

✅ 요약 매트릭스

서비스주요 역할연계 대상실무 활용
Azure Monitor 리소스 통합 모니터링 APIM, AKS, VM 등 로그 수집, 알림
Application Insights 앱 성능/오류 추적 API, Web App 응답시간, 오류 분석
VNet Integration PaaS → 내부망 연결 App Service, APIM 보안/내부망 연결
Azure Functions 서버리스 백엔드 APIM, 이벤트 라이트 API 처리
Logic Apps 코드 없는 자동화 외부 시스템 워크플로우 자동화
 

 

🔐 1. NSG (Network Security Group) 보안 정책

🔹 기본 구조

  • NSG는 **서브넷 또는 NIC(네트워크 인터페이스 카드)**에 적용되는 네트워크 트래픽 필터링 장치입니다.
  • 인바운드/아웃바운드 규칙 각각에 대해 설정 가능.
  • 기본 정책은 Deny All이며, 허용(Allow) 정책을 명시적으로 추가해야 통신이 가능합니다.

🔹 동작 원칙

특징설명
기본 설정 모든 인바운드/아웃바운드 트래픽 차단(Deny)
규칙 처리 우선순위(Priority) 값이 낮을수록 먼저 적용
허용 조건 명시적 Allow 룰이 없으면 모든 트래픽은 Deny

TA Tip: NSG 설정 후 외부 접근 불가 → 보안 규칙 우선순위 및 로그 분석 필수

🌐 2. Application Gateway 리스너 구조

🔹 기본 개념

  • **Application Gateway (L7 Load Balancer)**는 HTTP/HTTPS 기반 리스너만 지원합니다.
  • L4 수준의 TCP 리스너는 Azure Load Balancer 사용.

🔹 구성 요소

요소설명
Listener 포트 + 프로토콜(HTTP/HTTPS) 지정
Rules 요청 경로 또는 호스트 헤더 기반 라우팅
Backend Pool VM, Scale Set, App Service 등을 포함 가능
WAF 웹 애플리케이션 방화벽(WAF) 모드로 보안 강화 가능

TA Tip: HTTP 외 프로토콜(FTP, SMTP 등)은 지원 불가 → 다른 서비스 사용 고려

📦 3. 스토리지 계정 복제 옵션 (Replication)

🔹 복제 종류 비교

복제 유형설명가용성/복원력비용
LRS (Locally Redundant Storage) 동일 데이터센터 내 3중 복제 낮음 저렴
ZRS (Zone-Redundant Storage) 다른 AZ (가용성 영역) 간 복제 높음 중간
GRS (Geo-Redundant Storage) 주 지역 + 보조 지역에 복제 매우 높음 높음
GZRS ZRS + GRS 조합 (Zone + Geo) 최고 수준 가장 높음
RA-GRS GRS + 읽기 전용 보조지역 지원 장애 시 활용 가능 높음

TA Tip: BCDR 설계 시 GRS/GZRS 필수 고려. LRS는 내부 테스트용 적합.

💾 4. VM Backup 구조 (Azure Backup Center & Azure Monitor)

🔹 백업 방식

  • Azure Backup Center: 중앙집중형 백업 관리 포털
  • Azure Recovery Services Vault: 백업 데이터 저장소
  • VM 백업은 스냅샷 기반, 애플리케이션 일관성 보장 가능

🔹 연계 모니터링

  • Azure Monitor 및 Log Analytics 연계로 백업 실패, 경고, 성공 이력 실시간 추적 가능
  • Alert Rule을 통해 메일/Teams 등으로 자동 알림

TA Tip: 백업 구성 후 모니터링 연계 없으면 실시간 대응 불가 → Alert Rule 설정 필수

⚙️ 5. Managed Disk 유형별 성능 차이

🔹 디스크 타입 비교

유형IOPSThroughput용도
Standard HDD 낮음 최대 500 IOPS 비용 민감, 아카이브용
Standard SSD 중간 최대 2,000 IOPS 범용 서버 워크로드
Premium SSD 높음 최대 20,000 IOPS 이상 트랜잭션 처리 시스템
Ultra SSD 매우 높음 수십만 IOPS 지원 DBMS, SAP HANA 등 고성능 필요

🔹 특징

  • Premium/Ultra SSD는 성능 크기별로 요금 증가
  • Ultra SSD는 I/O 단위로 성능 조정 가능

TA Tip: 고성능 요구 시스템(PaaS DB, OLTP DB)은 Premium 이상 필수. 비용-성능 밸런스 고려.

'Migration & DR > 시스템 이관환경 및 Landing Zone 설계' 카테고리의 다른 글

Kubernetes Storage 설명과 랜딩존(Backup & Recovery포함)  (0) 2025.08.31
(gpt)On-Premises DB를 Microsoft Azure로 마이그레이션  (0) 2025.07.18

On-Premises DB를 Microsoft Azure로 마이그레이션하는 방법은 여러 가지가 있으며, 사용 환경(데이터베이스 종류, 다운타임 허용 여부, 데이터 크기, 네트워크 상황 등)에 따라 적합한 방법이 달라집니다. 아래에 주요 방법들과 유의사항을 정리하겠습니다.

📦 1. 마이그레이션 방식

1-1. Azure Database Migration Service (DMS)

  • 지원 DB: SQL Server, MySQL, PostgreSQL, Oracle 등
  • 특징:
    • 온라인/오프라인 마이그레이션 지원
    • Schema + 데이터 + 사용자 계정까지 마이그레이션 가능
  • 활용 예시:
    • SQL Server → Azure SQL Managed Instance / Azure SQL Database
    • Oracle → Azure PostgreSQL (이기종 마이그레이션)

1-2. 백업 및 복원 방식

  • 방법:
    • 온프레미스에서 백업 생성 → Azure 스토리지에 업로드 → 복원
  • 활용 예:
    • .bak 파일을 Azure Blob에 업로드 후, RESTORE DATABASE FROM URL로 복원
  • 제한사항: 대용량 데이터는 시간이 오래 걸림

1-3. BACPAC 파일 이용

  • 적용 대상: SQL Server → Azure SQL Database
  • 방법:
    • SSMS 또는 SqlPackage로 .bacpac 생성 후 Azure로 업로드
  • 주의:
    • 데이터 손실 가능성 존재 (트랜잭션 미포함)
    • 대량의 데이터를 가진 DB에는 비효율적

1-4. Transactional Replication

  • 적용 대상: SQL Server
  • 특징:
    • 온프레미스 DB를 퍼블리셔로, Azure DB를 구독자로 설정하여 실시간 동기화
    • Zero Downtime Migration이 가능
  • 제약: 복잡한 설정, 일부 오브젝트는 복제 불가

1-5. 데이터 복제/ETL 방식

  • 도구:
    • SSIS, Azure Data Factory (ADF), Debezium + Kafka, Talend 등
  • 특징:
    • 대규모 데이터 파이프라인, 비정형 또는 이기종 데이터에 적합
    • 점진적 마이그레이션 및 검증 가능

1-6. Log Shipping / Always On

  • 적용 대상: SQL Server
  • 특징:
    • 가용성 그룹 구성을 통해 Azure로 페일오버
    • 매우 낮은 다운타임 실현 가능

⚠️ 2. 유의사항

2-1. 다운타임 요구사항 판단

  • 무중단(Online) or 단기 정지(Offline) 여부에 따라 마이그레이션 도구 선택이 달라집니다.

2-2. 네트워크 대역폭/지연

  • 대용량 데이터 전송 시 Azure ExpressRoute 또는 Azure Data Box 사용 고려
  • VPN 또는 공용망은 속도 저하/보안 위험 존재

2-3. 보안 설정

  • 마이그레이션 전/후 방화벽 설정 및 암호화 적용 필요
  • Azure SQL은 기본적으로 퍼블릭 엔드포인트 차단

2-4. Schema 호환성 검사

  • 이기종 DB (예: Oracle → PostgreSQL) 간에는 스키마/쿼리 문법 차이 존재
  • DMS + SSMA (SQL Server Migration Assistant) 사용 권장

2-5. Application 연계 점검

  • 연결 문자열 변경 필요 (IP → DNS 권장)
  • 기존 쿼리/스토어드 프로시저의 호환성 확인

2-6. 성능 튜닝

  • Azure SQL은 DTU/VCU 기반이므로, 온프레미스보다 성능 차이 가능
  • 인덱스 재구성, 쿼리 리팩토링 필요 가능성

2-7. 권한 및 보안계정 마이그레이션

  • SQL Login, User Mapping, Role 등 사용자 권한 재구성이 필요

🧭 마이그레이션 일반 절차

  1. 평가 (Assessment)
    • 호환성 검사, 용량 산정, 다운타임 허용 여부 결정
  2. 계획 수립 (Planning)
    • 방법론 선정, 네트워크 구성, 보안 설계
  3. 스키마 마이그레이션
    • DMS 또는 SSMA로 스키마 이전
  4. 데이터 마이그레이션
    • 전체 or 증분 방식으로 전송
  5. 애플리케이션 수정
    • 연결 문자열, 인증 방식 변경
  6. 테스트 및 검증
    • 데이터 정합성, 기능 테스트
  7. 최종 전환 및 운영 이관
    • 실제 서비스 전환 후 모니터링

📌 추천 도구 요약표

도구마이그레이션 방식특징
Azure DMS 온라인/오프라인 대부분의 DB 지원, 정합성 우수
BACPAC 오프라인 소형 DB, 간단한 구조에 적합
SSMS 백업 복원 오프라인 SQL Server 한정, 간편
ADF 배치 마이그레이션 이기종, 비정형 데이터에 적합
트랜잭션 복제 온라인 SQL Server 고가용성 마이그레이션
Data Box 오프라인 (물리) 수 TB 이상의 데이터 이전 시
 

필요하다면 SQL Server 기준 실무 마이그레이션 시나리오, 테스트 체크리스트, DMS 실습 가이드도 드릴 수 있습니다. 어떤 DB를 기준으로 설명해 드릴까요?

'Migration & DR > 시스템 이관환경 및 Landing Zone 설계' 카테고리의 다른 글

Kubernetes Storage 설명과 랜딩존(Backup & Recovery포함)  (0) 2025.08.31
Azure 랜딩존(Azure Landing Zone) 개념, 문제(클러스터링,스토리지,API Gateway)  (0) 2025.07.18

WEB과 WAS를 분리한 후 점검해야 할 항목처럼 실무 환경에서 자주 발생하는 인프라 구조 변경 및 연계 점검에 대한 문제

✅ [문제 유형] 구조 변경 후 연계 점검 문제

✅ 문제 1. (객관식)

회사는 기존의 단일 서버에서 WEB과 WAS를 분리하여 각각 별도의 서버로 이전하였다.
이 과정에서 연계 오류를 방지하고 서비스 정상화를 위해 점검해야 할 항목으로 가장 적절하지 않은 것은 무엇인가?

보기
① WAS 서버의 IP를 ERP 연계 서버에 등록했는지 확인한다.
② 응용 프로그램 내에 하드코딩된 IP가 있는지 확인한다.
③ 모니터링 서버에서 새로운 WEB/WAS 모두에 대한 설정이 되어있는지 확인한다.
④ 기존 WEB 서버에서 수행되던 백업 Job을 삭제한다.
⑤ DNS 설정이 새로운 서버 IP로 갱신되었는지 확인한다.

정답: ④
해설: 백업 Job은 오히려 분리된 각 서버의 상태에 따라 새로 구성하거나 이전해야 하며, 무작정 삭제하는 것은 위험하다.

✅ 문제 2. (단답형)

웹 서버와 WAS 서버를 분리한 후, ERP 시스템과의 연동 오류가 발생하였다.
문제 해결을 위해 확인해야 할 설정 또는 구성 항목 3가지를 기술하시오.

예시 정답:

  • ERP 서버에 등록된 WAS 서버의 IP
  • WAS 접속용 도메인의 DNS 등록 여부
  • 응용 프로그램 내 하드코딩된 IP 존재 여부

✅ 문제 3. (시나리오형 복합 문제)

다음은 WEB과 WAS를 분리 구성한 후 발생할 수 있는 문제에 대한 시나리오이다.
상황을 읽고 문제에 답하시오.

[시나리오]
WAS 서버 분리 이후 ERP 연동이 간헐적으로 실패하며, 특정 업무는 정상적으로 수행되고 일부는 연결 실패 로그가 발생한다.
네트워크는 정상이고, ERP 서버에서 해당 WAS IP는 등록되어 있음. 개발자는 애플리케이션에서 ERP 연동 요청이 하드코딩된 IP로 구성되어 있다는 점을 언급하였다.

질문:

  1. 이 문제의 근본 원인을 기술하시오.
  2. 이와 같은 문제를 사전에 방지하기 위해 시스템 구성 시 반드시 지켜야 할 베스트프랙티스를 2가지 기술하시오.

예시 정답:

  1. 응용 프로그램 내 ERP 연동 IP가 하드코딩되어 있어 IP 변경 시 반영이 안됨
    • 연계 대상은 DNS 기반 도메인으로 참조할 것
        - 응용 프로그램에서 IP/PORT 등 환경변수를 외부 설정 파일로 분리할 것

🛠️ 이 유형으로 구성 가능한 문제 세트 예시

세트주제주요 키워드
1 WEB/WAS 분리 후 점검 DNS, 하드코딩, ERP, 모니터링, 백업
2 DMZ에서 내부망 연계 오류 방화벽, 포트, NAT, VPN, 허용 정책
3 DB 서버 이중화 후 장애 VIP, listener, 연결 문자열, replication
4 AP 서버 이관 후 오류 스케줄러, 환경변수, 인증서, 로그 경로
5 인증 서버 분리 및 재구성 SSO, 인증 포털, 연동 토큰, 접속 로그

 

✅ [WEB/WAS 분리 후 점검] 실무형 문제집 (총 15문항)

🔹 문제 1. (객관식)

WEB과 WAS를 분리한 후 ERP 연계가 실패하고 있다. 가장 가능성 높은 원인은?

① ERP 서버의 IP가 변경됨
② ERP 서버의 방화벽 정책이 초기화됨
③ WAS 서버의 IP가 ERP 연계 시스템에 등록되어 있지 않음
④ WEB 서버의 CPU가 과도하게 사용 중임

정답: ③
해설: ERP ↔ WAS 연계 실패는 IP 등록 누락이 대표적인 원인이다.

🔹 문제 2. (단답형)

WAS 서버를 분리한 후 응용 프로그램이 내부 서비스에 접속하지 못한다.
이때 점검해야 할 설정 항목 2가지를 기술하시오.

정답 예시:

  • 응용 프로그램 내 하드코딩된 IP
  • DNS 레코드 (A/AAAA) 등록 여부

🔹 문제 3. (객관식)

WEB과 WAS를 분리한 후 모니터링 시스템이 WAS 서버 상태를 감지하지 못한다. 가장 적절한 조치는?

① WEB 서버에서 모니터링 로그를 수집하게 변경
② 모니터링 설정에 WAS 서버 IP를 수동 등록
③ 모니터링 에이전트를 웹 서버로 이동
④ 모니터링 기능을 종료 후 재시작

정답: ②
해설: 서버 분리 시 IP가 바뀌므로 모니터링 시스템의 대상 IP 갱신 필요

🔹 문제 4. (시나리오형)

분리된 WAS 서버는 정상 구동 중이며, WEB 서버의 특정 기능 호출 시만 504 Gateway Timeout이 발생한다. 가능한 원인 2가지를 쓰시오.

정답 예시:

  • WEB → WAS 간 포트 차단 또는 NAT 누락
  • 리버스 프록시 설정에 타임아웃 값이 과소 설정됨

🔹 문제 5. (객관식)

WAS 서버 분리 후, 서비스 배포 자동화 도구에서 오류가 발생했다. 확인해야 할 항목은?

① Jenkins 빌드 스크립트에 WAS IP 반영 여부
② 개발자의 계정 권한
③ 시스템 시간대(Timezone) 일치 여부
④ CPU 가상화 설정

정답: ①

🔹 문제 6. (객관식)

WEB → WAS 요청 시 403 오류가 발생했다. 가능한 원인은?

① HTTP 프로토콜 미지원
② WAS 서버 방화벽에서 WEB 서버 IP 미허용
③ JVM 버전 불일치
④ DNS TTL이 짧게 설정됨

정답: ②

🔹 문제 7. (단답형)

WAS가 외부 시스템과 통신하는 기능을 포함하고 있다. 분리 구성 시, WAS 서버 측 방화벽에서 반드시 확인해야 할 것은?

정답 예시:

  • 외부 연계 대상 IP/PORT 허용 여부

🔹 문제 8. (객관식)

WEB ↔ WAS 간 통신 시 DNS 이름을 사용하는 이유로 적절한 것은?

① 서버 부하 분산을 위해
② IP 변경 시 서비스 중단을 막기 위해
③ 서버 인증을 위해
④ 패킷 전송 속도 향상을 위해

정답: ②

🔹 문제 9. (시나리오형)

웹 서버는 도메인 기반으로 WAS에 요청하고 있으나, 일부 기능만 502 Bad Gateway를 반환한다. 점검 항목을 2가지 쓰시오.

정답 예시:

  • NGINX 또는 Apache의 upstream 설정
  • WAS 포트별 서비스 바인딩 상태

🔹 문제 10. (객관식)

WAS 서버의 로그 디렉토리를 확인할 수 없다는 개발자의 문의가 있다. 가장 먼저 확인할 항목은?

① logrotate 설정
② 공유 디렉토리 권한 설정
③ 웹서버 버전
④ DNS 캐시 갱신 여부

정답: ②

🔹 문제 11. (단답형)

WEB과 WAS가 다른 서버에 위치한 경우, 개발자가 로컬 경로(/opt/media)를 참조하여 오류가 발생한다. 조치 방안은?

정답 예시:

  • 경로를 네트워크 경로(NFS 또는 SMB)로 변경
  • 상대경로 사용 또는 환경변수로 경로 분리

🔹 문제 12. (객관식)

WEB → WAS 통신에 있어서 TLS 오류가 발생했다. 가장 가능성 높은 원인은?

① HTTP 1.0 사용
② 인증서 루트 체인이 누락됨
③ 서버가 과부하 상태
④ DNS SRV 레코드 설정 누락

정답: ②

🔹 문제 13. (객관식)

WAS 서버를 이중화한 경우, 로드밸런서 설정에서 반드시 필요한 항목은?

① 서비스 로그 위치
② 서버별 세션 공유 방식
③ CPU 온도 설정
④ SSL 암호화 알고리즘

정답: ②
해설: 세션 클러스터링 또는 sticky session 정책이 중요

🔹 문제 14. (단답형)

WEB ↔ WAS 간의 통신이 NAT 환경에서 설정되었을 경우, 점검해야 할 네트워크 구성 항목 2가지는?

정답 예시:

  • SNAT/DNAT 매핑 설정
  • 방화벽 허용 정책

🔹 문제 15. (시나리오형)

WEB → WAS 분리 후, WAS가 응답은 하되 지연이 심해졌다. 가능한 원인과 조치방안을 2가지씩 기술하시오.

정답 예시:

  • 원인:
    • 연결 수 제한 초과
    • WAS GC 튜닝 미흡
  • 조치:
    • WAS의 max thread/connection 조정
    • JVM 메모리 옵션 조정 및 GC 정책 변경

WAS 및 Web 서버 운영 중 발생할 수 있는 실무 장애 상황과 그에 대한 정확한 진단 및 조치 방안을 다양한 유형별로 정리해 드리겠습니다.
 시나리오 + 원인 분석 + 조치 방법입니다.

✅ A. 웹서버(Web Server) 장애 상황

🔹 1. 웹 접속 불가 (80/443 포트 응답 없음)

  • 원인: Nginx/Apache 프로세스 중지, 방화벽 차단, 포트 점유
  • 진단 방법:
  • bash
    복사편집
    systemctl status nginx ss -tulnp | grep :80 sudo ufw status or firewall-cmd --list-all
  • 조치 방안:
    • 웹서버 재기동 (systemctl restart nginx)
    • 방화벽 열기 (firewall-cmd --add-port=80/tcp)
    • 포트 충돌 시 다른 프로세스 제거

🔹 2. 특정 경로 404 오류 (리소스 없음)

  • 원인: 프록시 설정 오타, 파일 경로 오류
  • 조치 방안:
    • /etc/nginx/conf.d/*.conf에서 location 설정 확인
    • 정적 리소스 경로(/var/www/html) 유무 확인

🔹 3. 504 Gateway Timeout

  • 원인: WAS에서 응답 없음 (Deadlock, GC, DB 대기 등)
  • 조치 방안:
    • proxy_read_timeout, proxy_connect_timeout 증가
    • WAS 상태 확인 → 필요 시 재기동
    • APM 또는 GC 로그로 병목 구간 분석

✅ B. WAS (Tomcat 등) 장애 상황

🔹 4. WAS 응답 지연 / 부하 급증

  • 원인: GC 과다, Thread Pool 고갈, DB 커넥션 부족
  • 조치 방안:
    • GC 로그 확인 (-Xlog:gc*)
    • maxThreads, maxConnections 값 증가
    • 커넥션 풀 확인 (HikariCP, DBCP 모니터링)

🔹 5. OutOfMemoryError (OOM)

  • 원인: 힙 사이즈 부족, 메모리 누수
  • 조치 방안:
    • JVM Heap 증가 (-Xmx)
    • Heap dump 후 분석 (jmap -dump, Eclipse MAT)
    • 코드 내 객체 누수 패턴 제거

🔹 6. 세션 유실 (로그인 풀림)

  • 원인: Sticky Session 미설정, 세션 복제 안됨
  • 조치 방안:
    • Nginx에 ip_hash 또는 Cookie 기반 sticky 설정
    • Redis 기반 Session Store 적용 (Spring Session)

🔹 7. WAS 갑작스러운 종료

  • 원인: 로그 디스크 Full, OOM, kill 명령, 파일 핸들 초과
  • 조치 방안:
    • df -h, ulimit -n 확인
    • 로그 파일 순환 설정 (logrotate)
    • 시스템 로그 확인 (dmesg, /var/log/messages)

✅ C. 네트워크 / 로드밸런싱 / 인프라 장애

🔹 8. 클라이언트 간헐적 접속 실패

  • 원인: 로드밸런서 Health check 미설정, WAS 일부 죽음
  • 조치 방안:
    • L4/L7 Health Check 구성
    • 죽은 노드 자동 제외 (active check)

🔹 9. DNS 응답 지연

  • 원인: 내/외부 DNS 장애 또는 지연
  • 조치 방안:
    • /etc/resolv.conf DNS 우선순위 조정
    • IP 직접 호출 테스트 (curl -x IP)
    • DNS 캐시 무효화 (systemd-resolve --flush-caches)

✅ D. 보안/인증 관련 장애

🔹 10. HTTPS 접속 오류 (SSL 인증서 에러)

  • 원인: 인증서 만료, 체인 미완성
  • 조치 방안:
    • openssl x509 -in cert.pem -noout -dates 확인
    • fullchain.pem 재설정
    • LetsEncrypt 자동 갱신(cronjob, certbot 확인)

✅ E. DB 연동 관련 장애

🔹 11. DB 연결 실패 or 지연

  • 원인: DB down, 커넥션 풀 고갈, 방화벽 차단
  • 조치 방안:
    • telnet DB_IP 3306, psql, mysql 접속 확인
    • 커넥션 풀 설정 점검
    • DB slow query 확인 및 튜닝

✅ F. 실무 대응을 위한 체크리스트 (TA 기준)

구분점검 항목
로그 분석 access.log, error.log, catalina.out, GC 로그, dmesg
자원 모니터링 top, iostat, free, df, vmstat, netstat
네트워크 확인 ping, traceroute, ss, netcat, telnet
설정 파일 nginx.conf, server.xml, context.xml, .env
복구 전략 무중단 배포, HA 구성, Redis 세션 백업, DB 이중화
 

✅ 장애별 빠른 대응 템플릿 예시

 
# nginx 지연 시 빠른 점검
systemctl status nginx
cat /var/log/nginx/error.log curl -I http://localhost
# WAS 상태 확인
ps aux | grep tomcat
tail -n 100 /opt/tomcat/logs/catalina.out
# JVM GC 상태
jstat -gcutil <pid> 1000 10
# DB 커넥션 확인
netstat -anp | grep 3306

필

✅ 실전 장애 시나리오 문제집 (세트 1~5)

### ✅ 시나리오 1: 특정 사용자만 로그인 실패

상황
웹 애플리케이션에서 특정 사용자들만 로그인 실패를 반복하고 있습니다. WAS와 DB는 정상 동작 중이고, 일부 사용자에 대해서만 로그인 실패 현상이 발생합니다.

질문

  1. 이 문제의 가능한 원인은 무엇인가요?
  2. 어떤 로그 또는 설정을 점검해야 하나요?
  3. 해결 방안은?

해설 및 답변

  • 원인: 세션 공유 오류, 로드밸런서의 Sticky Session 설정 누락
  • 점검: Nginx 로드밸런서 설정(ip_hash, cookie-based sticky), 세션 스토리지 로그
  • 조치: Sticky Session 활성화 또는 세션 중앙 저장소(Redis 등) 사용

### ✅ 시나리오 2: 504 Gateway Timeout 증가

상황
오후 피크 타임에 504 오류가 대량으로 발생하며, 대부분 특정 API 경로에서 집중됩니다. WAS에 직접 접속하면 응답이 느릴 뿐 실패하지 않습니다.

질문

  1. 어떤 장애유형인가요?
  2. 어떤 설정과 시스템 자원을 확인해야 하나요?
  3. 조치 방안은?

해설 및 답변

  • 원인: WAS에서 지연 발생 → Nginx가 Timeout 초과
  • 점검:
    • Nginx: proxy_read_timeout, proxy_connect_timeout
    • WAS 로그: DB 쿼리, GC 상태
    • DB 슬로우 쿼리
  • 조치:
    • 타임아웃 조정
    • 쿼리 튜닝 / 인덱스 추가
    • GC 튜닝 / Thread 수 조정

### ✅ 시나리오 3: WAS 무한 재시작

상황
Tomcat 기반 WAS가 배포 후 수 초 내에 재시작을 반복하며 정상 서비스가 되지 않고 있습니다.

질문

  1. 장애 원인을 어떻게 추정하나요?
  2. 가장 먼저 확인할 로그는?
  3. 조치 방안은?

해설 및 답변

  • 원인: 환경 변수 누락, spring profile 오타, 포트 충돌, 로그 디렉터리 권한 문제
  • 점검:
    • catalina.out, nohup.out, application.log
    • env 설정 확인
  • 조치:
    • application.yml/profile 확인
    • 로그 디렉토리 쓰기 권한 확인 (chown, chmod)
    • 포트 충돌이면 포트 변경

### ✅ 시나리오 4: Redis 세션 만료로 사용자 로그아웃

상황
Redis를 세션 저장소로 사용하는 WAS에서 대량의 사용자 로그아웃 현상이 발생하고 있습니다. 장애는 오전 4시에 집중 발생합니다.

질문

  1. Redis 설정에서 점검할 항목은?
  2. 이 장애의 발생 원인은?
  3. 해결 방법은?

해설 및 답변

  • 원인: Redis maxmemory-policy가 volatile-lru로 설정되어 세션 정보가 메모리 부족 시 제거됨
  • 점검:
    • redis.conf: maxmemory, maxmemory-policy, TTL 확인
    • 모니터링: Redis 메모리 사용률, key TTL
  • 조치:
    • allkeys-lru → volatile-ttl 또는 세션 전용 Redis 분리
    • 메모리 증설 / 수명 늘리기 / 중요 키는 TTL 설정 금지

### ✅ 시나리오 5: 웹 접속 시 응답 없음 (503)

상황
웹 접속 시 503 오류가 빈번하게 발생합니다. 서버 재시작 후 일정 시간은 정상이나, 이후 장애가 반복됩니다.

질문

  1. 이 현상의 원인은?
  2. Nginx와 WAS 중 어디부터 점검해야 하나요?
  3. 조치 방안은?

해설 및 답변

  • 원인: Nginx upstream 연결 실패 or WAS 프로세스 과부하
  • 점검:
    • Nginx 로그: access.log, error.log
    • WAS: top, jstack, thread dump
  • 조치:
    • WAS 스레드/커넥션 수 조정
    • Nginx max_fails, fail_timeout 조정
    • APM 도입하여 병목 확인

 

✅ 시나리오 6: WAS에서 한 서비스만 응답 지연

상황
전체 웹 서비스는 정상적으로 작동하지만, /api/report 경로에만 지연이 발생합니다. 이 경로는 DB와 연동된 통계를 제공하는 기능입니다.

질문

  1. 이와 같은 지연의 원인 후보를 2가지 이상 제시하시오.
  2. 진단 및 조치를 위한 절차를 설명하시오.

해설 및 답변

  • 원인:
    • 해당 API의 DB 쿼리 성능 저하
    • GC 또는 특정 Thread에서 처리 병목
  • 진단:
    • WAS 로그에서 /api/report 응답시간 추적
    • DB 슬로우 쿼리 로그 확인
    • GC/Thread dump 확인
  • 조치:
    • 쿼리 튜닝 (인덱스 추가, join 최적화)
    • GC 설정 조정
    • 비동기 처리 전환 고려

✅ 시나리오 7: 서비스 중 로그인 상태가 초기화됨

상황
사용자가 로그인 후 5분 이내에 자동 로그아웃되는 현상이 간헐적으로 발생합니다. 로그인 쿠키는 유지되며, WAS는 멀티노드로 구성되어 있습니다.

질문

  1. 문제의 가능성 높은 원인을 기술하시오.
  2. 어떤 설정 또는 구성을 확인해야 하는가?

해설 및 답변

  • 원인:
    • 세션 클러스터링 누락 or 잘못된 Sticky Session 설정
    • Redis의 TTL 설정 과도함
  • 확인 항목:
    • 로드밸런서에 ip_hash or cookie sticky 설정 여부
    • Redis 세션 TTL 설정 확인
    • Spring Session 설정에서 maxInactiveIntervalInSeconds
  • 조치:
    • 세션 공유 방식 전환 (Sticky → 중앙 저장소)
    • TTL 확장 또는 중요 세션은 TTL 제거

✅ 시나리오 8: 갑작스런 트래픽 증가 후 전체 장애

상황
SNS 마케팅 이후 갑작스러운 사용자 증가로 인해 웹 페이지 접속이 불가능한 상황 발생. 웹서버는 살아 있으나 WAS와 DB 모두 과부하 상태입니다.

질문

  1. 해당 장애의 직접적 원인과 근본 원인을 나눠 설명하시오.
  2. 이 상황에서 빠르게 복구하는 방법은?

해설 및 답변

  • 직접 원인: WAS/DB 자원 고갈 (CPU, Thread, Connection Pool)
  • 근본 원인: 적절한 트래픽 예측 및 자원 할당 부재
  • 조치:
    • WAS 수평 확장 (Auto Scaling 또는 수동 증설)
    • nginx rate_limit, fail_timeout으로 순간 폭주 차단
    • CDN 활용하여 정적 리소스 분산
    • DB Connection Pool 증설

✅ 시나리오 9: WAS 시작 안됨, 로그도 없음

상황
WAS 재기동 중인데, 프로세스가 시작되지 않으며 로그 파일에도 아무 메시지가 기록되지 않습니다.

질문

  1. 원인을 확인할 수 있는 방법을 제시하시오.
  2. 이 문제의 조치 방안은?

해설 및 답변

  • 원인:
    • 포트 충돌 (이미 사용 중)
    • 로그 디렉토리 쓰기 권한 없음
    • 환경 변수 누락 (JAVA_HOME 등)
  • 확인 방법:
  • bash
    복사편집
    netstat -tulnp | grep 8080 ls -al /opt/tomcat/logs echo $JAVA_HOME
  • 조치:
    • 포트 변경 또는 충돌 프로세스 종료
    • 로그 경로 소유자/퍼미션 수정
    • .bash_profile에 JAVA_HOME 재정의

✅ 시나리오 10: 정기 배포 후 CSS/JS 깨짐

상황
새 버전 배포 후 일부 사용자에게 CSS가 적용되지 않거나 JS 기능이 작동하지 않는 이슈가 발생함.

질문

  1. 가장 먼저 점검해야 할 항목은?
  2. 가능한 원인 2가지와 조치 방안을 설명하시오.

해설 및 답변

  • 점검 항목:
    • 브라우저 캐시 상태, CDN 캐시, Nginx 캐시 설정
  • 원인 및 조치:
    1. 정적 리소스 캐싱 문제 → 파일명에 hash 추가 (style.abcd123.css)
      • 조치: 정적 자산 버전 관리 적용 (Webpack, Asset Pipeline)
    2. CDN 캐시 미갱신 → 오래된 JS/CSS 제공
      • 조치: CDN purge 실행 또는 캐시 만료 설정 변경 (cache-control)

✅

✅ 실전 장애 시나리오 문제집 (세트 11~15)

✅ 시나리오 11: 로그 파일 폭주로 인한 디스크 FULL

상황
갑작스럽게 서비스 전체가 다운되었으며, WAS 로그 기록도 멈춘 상태입니다. 서버에 접속해 보니 /var 디스크가 100% 사용 중입니다.

질문

  1. 이 문제의 발생 원인과 진단 절차는?
  2. 어떤 조치가 가능한가?
  3. 이 장애를 방지하기 위한 사전 방안은?

해설 및 답변

  • 원인: 로그 파일 과다 발생 (무한 루프, DEBUG 레벨), logrotate 설정 미적용
  • 진단:
    • df -h, du -sh /var/log/* 로 디스크 점유 확인
    • 최근 수정된 로그 탐색: find /var/log -type f -mtime -1
  • 조치:
    • 대용량 로그 삭제 (truncate -s 0 file.log or 백업 후 삭제)
    • 서비스 재시작
  • 예방:
    • logrotate 설정 (/etc/logrotate.d/)
    • 로그 레벨 관리 (INFO 이상 유지)
    • 모니터링 임계치 설정 (디스크 사용률 80% 알람)

✅ 시나리오 12: 정적 파일 응답이 비정상적으로 느림

상황
웹페이지 로딩 속도가 느려졌고, Chrome 개발자 도구에서 CSS/JS 등 정적 파일들이 3~5초 지연되고 있음이 확인됨. API 응답은 빠름.

질문

  1. 이 문제는 Web인가 WAS인가?
  2. 가장 먼저 점검해야 할 설정 항목은?
  3. 조치 방안은?

해설 및 답변

  • 범위: Web Server 문제
  • 점검:
    • nginx.conf의 정적 파일 경로 설정 (e.g. location ~* \.(js|css|jpg|png) 등)
    • 정적 파일이 실제로 NFS 등 외부 스토리지에 있는지
    • 캐시 설정 확인 (expires, cache-control)
  • 조치:
    • 정적 파일을 로컬 경로로 이전 또는 CDN 적용
    • gzip 압축 설정 확인 (gzip on;)
    • 브라우저 캐시 정책 조정 (expires 30d 등)

✅ 시나리오 13: 특정 지역 사용자만 접속 장애

상황
국내 일부 지역(예: 수도권) 사용자만 서비스 접속 지연을 호소. 사내 테스트 및 해외 사용자 접속은 정상.

질문

  1. 이 문제를 지역별로 어떻게 진단할 수 있는가?
  2. 어떤 네트워크 요소를 의심해야 하는가?
  3. 가능한 원인과 조치는?

해설 및 답변

  • 진단:
    • 지역별 접속 테스트 (VPN, 사내 지사)
    • CDN 로그, ISP 분석 (Traceroute 활용)
  • 의심요소:
    • 지역별 DNS 서버 응답 이상
    • 특정 ISP와의 라우팅 문제
  • 조치:
    • CDN 활용 시, 지역 Edge 노드 상태 확인
    • DNS 서비스 상태 점검 (Cloudflare, Route53)
    • 네트워크 업체와 회선 장애 분석 요청

✅ 시나리오 14: API 응답은 정상, 브라우저에선 CORS 오류

상황
브라우저에서 특정 프론트엔드 기능이 동작하지 않고, 콘솔에는 CORS policy: No 'Access-Control-Allow-Origin' 오류가 발생함.

질문

  1. 이 문제는 서버 문제인가, 클라이언트 문제인가?
  2. 어떤 설정을 점검해야 하는가?
  3. 조치 방법은?

해설 및 답변

  • 서버 측 문제 (응답 Header 누락)
  • 점검:
    • Web 서버 or WAS에서 CORS Header 삽입 여부 확인
    • Nginx reverse proxy 경로에 add_header 누락 여부
  • 조치:또는 WAS(Spring 등)에서 CORS 설정 추가
  • nginx
    복사편집
    location /api/ { proxy_pass http://was; add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS'; }

✅ 시나리오 15: 파일 업로드 실패 (413 Request Entity Too Large)

상황
대용량 이미지 업로드 시 413 Request Entity Too Large 오류 발생. 작은 파일은 업로드 정상.

질문

  1. 이 문제는 어디에서 발생하는가?
  2. 해결을 위한 설정 변경 항목은?

해설 및 답변

  • 원인: Web Server에서 허용하는 요청 Body 크기 제한
  • 위치: Nginx or Apache
  • 조치:
    • WAS에도 파일 업로드 제한 설정 확인 (spring.servlet.multipart.max-file-size)
    • 브라우저 사이드에서 FormData 방식 확인
  • nginx
    복사편집
    http { client_max_body_size 20M; }


이번 세트는 보안, 인증서, WAS 성능, 캐시, 스케일링 등 실무에서 놓치기 쉬운 이슈를 중심으로 구성했습니다.

✅ 시나리오 16: SSL 인증서 갱신 후 HTTPS 오류

상황
Let's Encrypt 인증서를 갱신한 후, 일부 브라우저에서 HTTPS 접속 시 "보안 인증서를 신뢰할 수 없음" 오류가 발생합니다. 모바일에서 주로 발생합니다.

질문

  1. 어떤 설정 오류가 의심되나요?
  2. 확인 및 조치 방안을 서술하시오.

해설 및 답변

  • 원인: fullchain.pem 대신 cert.pem만 적용함 → 중간 인증서 누락
  • 확인 방법:
  • bash
    복사편집
    openssl s_client -connect domain.com:443 -showcerts
  • 조치:
    • ssl_certificate에 fullchain.pem 지정
    • Nginx 설정 예시:
    • nginx
      복사편집
      ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem;

✅ 시나리오 17: 갑자기 느려진 WAS 응답, GC 관련

상황
WAS에서 특정 시점부터 전체 응답 속도가 급격히 느려졌습니다. CPU는 100%에 육박하며 GC 로그가 잦아지고 있습니다.

질문

  1. GC 관점에서 어떤 현상이 의심되며, 이를 어떻게 확인하나요?
  2. 근본적인 해결 방법은?

해설 및 답변

  • 의심 현상: Full GC 반복, Old Generation 메모리 부족
  • 확인 방법:
    • -Xlog:gc* 또는 verbose:gc 로그 분석
    • jstat -gcutil <pid> 1000 10
  • 조치:
    • Heap 사이즈 조정 (-Xmx, -Xms)
    • G1GC로 전환 고려
    • 메모리 누수 분석 (jmap, Eclipse MAT)
    • 캐시 객체 TTL 설정

✅ 시나리오 18: Redis 캐시 적용 후 반영이 안됨

상황
Redis 기반 캐시를 도입했으나, 백엔드에서 수정한 데이터가 바로 반영되지 않고, 오래된 데이터가 계속 노출되고 있습니다.

질문

  1. 캐시 시스템에서 자주 발생하는 이 문제의 원인과 진단 절차는?
  2. 실무적으로 어떤 전략을 사용해 해결할 수 있나요?

해설 및 답변

  • 원인:
    • TTL 설정 누락
    • 캐시 삭제/무효화 로직 없음
  • 조치:
    • TTL 설정 적용 (EXPIRE, SETEX)
    • 쓰기 시 cache evict, invalidate
    • 전략 도입:
      • Write-Through (동기 업데이트)
      • Cache-Aside (읽기 시 캐시 확인)
      • TTL + Versioning 조합

✅ 시나리오 19: WAS Auto Scaling 후 세션 오류

상황
AWS ECS에서 Auto Scaling 정책으로 WAS 인스턴스를 자동으로 늘렸으나, 사용자 세션이 초기화되며 로그인 유지가 안 됩니다.

질문

  1. 클라우드 환경에서 이 현상의 원인과 해결책은?
  2. 세션 유지 전략 2가지를 설명하시오.

해설 및 답변

  • 원인: Auto Scaling된 WAS 인스턴스 간 세션 공유 안됨
  • 조치:
    • Sticky Session 설정 (ALB, NLB에서 session cookie)
    • Redis를 세션 저장소로 구성 (Spring Session Redis)
  • 전략:
    1. Sticky Session → 간단하지만 scale-in 시 리스크 존재
    2. 중앙 저장소 방식 → 확장성과 안정성 ↑

✅ 시나리오 20: 배포 후 특정 기능만 실패 (Method Not Allowed)

상황
배포 후, 프론트에서 특정 버튼 클릭 시 405 Method Not Allowed 에러 발생. 백엔드 API는 POST로 설계되었으며, WAS는 Tomcat 기반입니다.

질문

  1. 이 장애는 프론트엔드 문제인가, 백엔드 문제인가?
  2. 원인과 조치 방안을 서술하시오.

해설 및 답변

  • 원인: 웹서버 or 프록시가 POST 요청을 차단하거나, 백엔드에서 Mapping 누락
  • 확인:
    • Nginx 또는 Tomcat의 allowedMethods 설정
    • 프론트에서 잘못된 HTTP Method 요청 확인 (F12 Network 탭)
  • 조치:
    • 프론트가 GET으로 보내고 있는지 확인
    • 백엔드에서 @PostMapping("/submit") 누락 여부 확인
    • Nginx에 limit_except 설정이 있다면 제거


아래는 실전 장애 시나리오 문제집 세트 21~25입니다.
이번에는 보안 위협, 파일시스템 병목, 인증 시스템, 모니터링 누락, 설정 배포 실수 등 운영 현장에서 실제 발생하는 고급 시나리오를 반영했습니다.

 

✅ 시나리오 21: 관리자 페이지에 비정상적 로그인 시도 급증

상황
운영 중인 웹 서비스의 관리자 페이지에 대해 비정상적인 로그인 시도가 수천 건 발생하고 있으며, 관리자 계정 중 일부는 로그인 시도에 실패하고 있습니다.

질문

  1. 이 문제를 보안 관점에서 어떻게 분석하겠는가?
  2. 방어 및 대응 방안은?

해설 및 답변

  • 의심: Brute-force 공격 (무차별 대입), 크리덴셜 스터핑
  • 조치:
    • 웹 방화벽(WAF) 적용, 관리자 페이지에 IP 제한
    • 로그인 실패 횟수 제한 (fail2ban, Spring Security lock 기능)
    • 로그 분석 (/var/log/nginx/access.log, auth.log)
    • 관리자 URL 경로 변경, CAPTCHA 도입
    • OTP, 2FA 적용

✅ 시나리오 22: 파일 업로드 후 바로 다운로드 안됨

상황
사용자가 업로드한 파일을 바로 다운로드하려고 하면 404 오류가 발생하나, 몇 분 뒤에는 정상적으로 다운로드됩니다.

질문

  1. 이 문제는 어떤 시스템 구조에서 발생할 수 있는가?
  2. 해결 방안을 기술하시오.

해설 및 답변

  • 원인: WAS와 파일 스토리지가 분리되어 있고, 동기화 지연 발생 (예: NFS, CDN, Object Storage)
  • 조치:
    • 업로드 → 파일 복사 → 다운로드 노드 반영까지의 동기화 시간 확인
    • 해결 방법:
      • 즉시 다운로드는 동일 노드에서 처리
      • CDN 동기화 시 Delay-aware 처리 로직 추가
      • 업로드 완료 후 응답 전에 동기화 완료 확인

✅ 시나리오 23: 로그인 인증 API만 비정상 트래픽 증가

상황
특정 시간대에 /api/auth/login API에만 트래픽이 집중되면서 서버 CPU가 급상승하고 전체 응답이 지연됩니다.

질문

  1. 어떤 보안/인증 이슈가 의심되는가?
  2. 실무적으로 취할 수 있는 대응 방안은?

해설 및 답변

  • 의심: 인증 API 대상 DoS 공격 또는 로그인 봇 테스트
  • 대응:
    • 인증 API에 레이트 리밋 적용 (limit_req in Nginx, Spring RateLimiter)
    • CAPTCHA, Device Fingerprint 도입
    • 인증 트래픽과 일반 트래픽 분리 (별도 서버/로드밸런싱)
    • JWT 검증 로직 캐싱 (공개키 로딩 최적화)

✅ 시나리오 24: 시스템 CPU 사용률은 낮은데 응답 느림

상황
CPU와 메모리 사용률은 낮은데 전체 요청 응답이 지속적으로 느려짐. 로그상 별다른 에러는 없음.

질문

  1. 이런 현상의 숨은 원인은 무엇일 수 있나?
  2. 점검 순서와 해결 방안을 제시하시오.

해설 및 답변

  • 원인 후보:
    • 파일시스템 I/O 병목
    • 네트워크 MTU 미스매치 또는 DNS 지연
    • 외부 API 연동 지연
  • 점검:
  • bash
    복사편집
    iostat -xz 1 netstat -s dig google.com
  • 조치:
    • 느린 디스크 탐지 후 SSD로 교체
    • DNS 캐싱 적용 (nscd, systemd-resolved)
    • API 응답 타임아웃 설정 강화 및 비동기화

✅ 시나리오 25: 설정 파일 배포 후 전체 장애

상황
웹 서버 설정 변경 후 전체 서비스가 다운됨. 다시 이전 버전으로 롤백하자 정상 동작함. 사전 테스트는 통과했음.

질문

  1. 이런 실무 상황에서 자주 발생하는 원인 유형은?
  2. 설정 변경의 안전성을 높이기 위한 전략은?

해설 및 답변

  • 원인:
    • 설정 구문 오류 (괄호/문법 누락)
    • 설정 reload 후 적용 순서 문제
    • 개발과 운영 환경 차이 (포트, 권한)
  • 조치:
    • 사전 configtest (nginx -t, apachectl configtest)
    • 설정 staging 환경 테스트
    • GitOps 기반 구성 배포 (Ansible, Terraform, ArgoCD)
    • 변경 전 후 비교 자동화 (Diff 툴, 설정 버전 관리)


아래는 이어지는 실전 장애 시나리오 문제집 세트 26~30입니다.
이번 세트는 컨테이너 운영, CI/CD 실수, 인증 토큰 문제, 시간 동기화, 대기열 처리 지연 등 최근 시스템 운영 환경에서 많이 겪는 고급 시나리오로 구성했습니다.

✅ 시나리오 26: 컨테이너 재기동 반복 (CrashLoopBackOff)

상황
Kubernetes 환경에서 일부 WAS Pod가 CrashLoopBackOff 상태에 빠지고, 계속해서 재시작을 반복하고 있음. kubectl logs에는 오류 없이 바로 종료된 로그만 보임.

질문

  1. 원인을 파악하기 위한 우선 점검 항목은?
  2. 조치 방안을 기술하시오.

해설 및 답변

  • 의심 원인:
    • command 또는 ENTRYPOINT가 잘못되어 컨테이너 실행 후 즉시 종료
    • 환경 변수 누락 (DB 주소, 포트 등)
    • ConfigMap 또는 Secret mount 실패
  • 진단:
  • bash
    복사편집
    kubectl describe pod <pod-name> kubectl logs <pod-name> --previous
  • 조치:
    • manifest의 env 설정 확인
    • 시작 명령어 수정 (command, args)
    • readinessProbe 조건 완화 또는 잠시 비활성화

✅ 시나리오 27: CI/CD 자동 배포 후 설정 누락

상황
CI/CD 파이프라인을 통해 자동 배포된 서비스가 설정값 누락으로 동작하지 않음. staging 환경에서는 문제 없었음.

질문

  1. 어떤 운영 상의 실수 또는 설계 미스가 있었는가?
  2. 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • CI/CD에서 환경에 따라 적용되는 .env 또는 application-{profile}.yml 누락
    • Secret, configMap 값이 배포 대상에 매핑되지 않음
  • 조치:
    • 환경 별 config 검증 파이프라인 추가
    • Config schema validation 도입 (ex. Spring Cloud Config, HashiCorp Vault)
    • 배포 전 preflight check 자동화

✅ 시나리오 28: 인증 토큰 만료로 API 연속 실패

상황
외부 인증 서버에서 발급받은 Access Token을 사용하는 API가 특정 시점 이후 401 Unauthorized 응답을 반복적으로 반환하고 있음.

질문

  1. 이 현상이 발생하는 전형적인 원인은?
  2. 실무 대응 방안은?

해설 및 답변

  • 원인:
    • Access Token이 만료됐는데 refresh 로직이 없거나 실패
    • 인증 서버 응답 형식 변경 등으로 토큰 재요청 실패
  • 조치:
    • 토큰 만료 시 자동 refresh 로직 구현 (refresh token, re-login flow)
    • 에러 코드 로깅 강화 (401 vs 403 vs 5XX)
    • CI/CD 파이프라인에 테스트 토큰 유효성 점검 스크립트 포함

✅ 시나리오 29: 시스템 간 시간 차이로 인증 실패

상황
JWT 기반 인증 시스템에서 서버 간 요청 시 지속적으로 Signature Error가 발생. 토큰은 유효하지만 서명 불일치.

질문

  1. 이 장애의 기술적 원인은 무엇인가?
  2. 해결 방안은?

해설 및 답변

  • 원인: 서버 간 시스템 시간이 일치하지 않음 (ex. 1~2분 차이)
  • 조치:
    • 모든 서버에서 NTP 설정 활성화 (chronyd, ntpd, systemd-timesyncd)
    • ntpq -p, timedatectl 명령어로 확인
    • 클라우드 환경에서는 VPC NTP 서버 또는 OS 기본 제공 NTP 서버 사용 권장

✅ 시나리오 30: 백그라운드 대기열(Task Queue) 처리 지연

상황
메일, 알림 발송 등을 처리하는 작업 큐(예: RabbitMQ, Kafka, Celery)의 메시지가 쌓이면서 사용자에게 알림이 지연됨.

질문

  1. 메시지 큐 처리 지연의 일반적인 원인 2가지를 제시하시오.
  2. 모니터링 및 대응 방안은?

해설 및 답변

  • 원인:
    1. Worker 수 부족 → 소비 속도 < 생산 속도
    2. 메시지 처리 중 오류/재시도 → Dead Letter Queue 누적
  • 대응 방안:
    • Worker 수 자동 확장 (Auto Scaling based on queue depth)
    • APM 도구로 처리시간 추적 (Sentry, Datadog)
    • DLQ 모니터링 후 이상 메시지 필터링
    • 큐 상태 대시보드 구성 (Prometheus + Grafana)


이번에는 미들웨어 설정 누락, 파일 잠금 문제, 보안 설정 실수, 로그 유실, API 게이트웨이 이슈 등 고급 장애 원인을 다루었습니다.

✅ 실전 장애 시나리오 문제집 (세트 31~35)

✅ 시나리오 31: Tomcat에서 POST 요청 데이터가 누락됨

상황
클라이언트가 전송한 POST 요청이 일부 WAS(Tomcat) 인스턴스에서만 제대로 수신되지 않고 있음. 특정 파라미터 값이 누락되어 비정상 처리 발생.

질문

  1. 이 현상이 발생할 수 있는 Tomcat의 설정 이슈는 무엇인가?
  2. 진단 및 조치 방안을 설명하시오.

해설 및 답변

  • 원인: maxPostSize 또는 maxParameterCount 제한 초과
  • 진단:
    • server.xml 또는 web.xml에서 관련 파라미터 확인
    • 파라미터 개수/크기 확인 (tcpdump나 APM 활용)
  • 조치:
  • xml
    복사편집
    <Connector port="8080" maxPostSize="2097152" maxParameterCount="10000" />

✅ 시나리오 32: 파일 접근 시 "Device or resource busy"

상황
WAS에서 특정 로그 파일 또는 업로드 파일에 접근하려고 할 때 "device or resource busy" 오류가 발생. 재부팅 전까지 해소되지 않음.

질문

  1. 이 문제는 어떤 상황에서 발생하는가?
  2. 진단 명령어와 해결 방법은?

해설 및 답변

  • 원인:
    • 다른 프로세스가 파일을 열고 있음 (File lock)
    • 로그 로테이션 중 sync 미완료
  • 진단:
  • bash
    복사편집
    lsof | grep <filename> fuser <filename>
  • 조치:
    • 해당 파일을 점유한 프로세스 종료
    • logrotate 설정 확인 (copytruncate 등)
    • 파일을 사용하는 코드 내 동시성 제어 로직 보완

✅ 시나리오 33: CORS 설정 중 Origin을 *으로 허용했지만 쿠키가 안 붙음

상황
API 서버는 CORS를 Access-Control-Allow-Origin: *으로 허용하고 있음에도 불구하고, 클라이언트에서 쿠키(Session ID)가 전송되지 않음.

질문

  1. 이 현상의 원인과 해결 방법은?
  2. CORS 설정 시 주의할 점을 설명하시오.

해설 및 답변

  • 원인:
    • Access-Control-Allow-Credentials: true 사용 시 Origin에 * 사용 불가
  • 조치:
    • CORS 설정을 아래와 같이 변경:
    • http
      복사편집
      Access-Control-Allow-Origin: https://your-domain.com Access-Control-Allow-Credentials: true
  • 주의점:
    • 쿠키/Authorization header를 포함할 경우 Origin은 명시해야 함
    • 프론트엔드 xhr.withCredentials = true 설정 필요

✅ 시나리오 34: 애플리케이션 로그가 저장되지 않음

상황
WAS는 정상 동작 중이나, 배포 이후부터 애플리케이션 로그가 생성되지 않고 있음. 기존 로그 파일도 업데이트되지 않음.

질문

  1. 로그 미생성 원인을 2가지 이상 제시하시오.
  2. 진단 및 조치 방안은?

해설 및 답변

  • 원인:
    1. 로그 디렉터리 권한 없음 (/logs, /var/log/...)
    2. logback/log4j 설정 경로 오류
  • 진단:
    • ls -l로 디렉터리 권한 확인
    • 애플리케이션 로그 설정 확인 (logback.xml, log4j2.xml)
  • 조치:
    • WAS 실행 사용자에게 디렉터리 쓰기 권한 부여
    • 로그 설정 경로 확인 및 로그 백엔드 재시작
    • logger.debug로 로그 활성화 상태 테스트

✅ 시나리오 35: API Gateway를 통한 경로 일부만 실패

상황
API Gateway(AWS API Gateway, Kong 등)를 통해 전달되는 요청 중 /v1/users는 정상 처리되지만, /v1/admin 경로는 502 Bad Gateway 오류 발생.

질문

  1. 이 문제의 원인을 API Gateway, WAS, 보안 설정 관점에서 각각 설명하시오.
  2. 해결 방안은?

해설 및 답변

  • API Gateway:
    • /v1/admin에 대한 라우팅 설정 누락
  • WAS:
    • 요청 경로에 대한 Controller 미구현 or 보안 필터 차단
  • 보안 설정:
    • 인증 헤더 누락 or RBAC(Role-Based Access Control) 거부
  • 조치:
    • API Gateway 라우팅 설정 추가 및 검증
    • WAS 로그에서 /v1/admin 처리 여부 확인
    • 권한 인증 방식 점검 (토큰 포함 여부, 인증 서버 연동 상태 등)

✅ 다음 단계 제안

지금까지 총 35세트의 장애 시나리오 문제집이 완성되었습니다.
이 시나리오들을 다음 형태로 정리해드릴 수 있습니다:

유형제공 내용
📄 PDF 문제집 실전 시나리오 + 해설 포함 인쇄용 정리본
📊 Excel 정리본 시나리오, 원인, 조치 항목별 시트
📘 객관식/단답형 평가 세트 실무 기술 인터뷰 및 테스트용 문제 전환
🧪 실습 기반 버전 각 시나리오에 대한 로그 예시, 진단 명령어 포함
 

PDF나 Excel 버전이 필요하시면 바로 제작해드릴게요.
또는 다음 세트(36~40)도 이어서 원하시나요?

 

나의 말:

다음 세트(36~40)

31~35세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 36~40입니다.
이번 세트는 파일 핸들 누수, API 응답 중단, 웹소켓 장애, 과도한 캐시 적중률, 서비스 리디렉션 실패 등 운영 중 놓치기 쉬운 고급 장애를 다루었습니다.

✅ 실전 장애 시나리오 문제집 (세트 36~40)

✅ 시나리오 36: WAS가 일정 시간 후 무응답 상태로 진입

상황
WAS가 정상적으로 기동되지만, 일정 시간이 지나면 외부 요청에 대해 응답하지 않고 멈춘 듯한 상태가 반복됩니다. 재기동하면 정상으로 돌아오지만 잠시 후 다시 장애 발생.

질문

  1. 이와 같은 증상이 발생하는 자원 누수의 대표적인 예는?
  2. 진단 방법 및 해결 방안은?

해설 및 답변

  • 원인:
    • 파일 핸들 누수 (열린 파일이 닫히지 않음)
    • 커넥션 풀 미반납
  • 진단:
  • bash
    복사편집
    lsof -p <PID> | wc -l cat /proc/<PID>/limits ulimit -n
  • 조치:
    • 코드 내 InputStream, FileWriter 등의 close() 확인
    • 커넥션 풀의 finally { close(); } 로직 점검
    • ulimit -n 증가, 파일 디스크립터 모니터링 도입

✅ 시나리오 37: API는 호출되지만 응답 없이 멈춤

상황
특정 API 호출 시 서버 측에서 로그가 남고, CPU 사용률도 증가하지만 클라이언트로는 응답이 도달하지 않음. HTTP Timeout으로 실패 처리됨.

질문

  1. 이런 상황에서 우선적으로 점검할 서버 내부의 요소는?
  2. 응답이 멈추는 대표적인 이유 2가지와 해결 방안은?

해설 및 답변

  • 점검 대상:
    • Thread Pool 고갈
    • Deadlock 발생
  • 원인:
    1. 비동기 처리 지연으로 응답 완료하지 않음
    2. DB Lock, File Lock, Deadlock 등으로 응답 흐름 차단
  • 조치:
    • jstack, thread dump 분석
    • spring.task.execution.pool.max-size 설정 확인
    • DB에서 Lock 대기 쿼리 확인 (SHOW ENGINE INNODB STATUS)

✅ 시나리오 38: 웹소켓 통신이 끊김/재접속 반복

상황
웹소켓 기반 실시간 서비스에서 클라이언트가 주기적으로 연결이 끊겼다가 재접속되는 현상이 발생. 네트워크는 정상이며 서버 응답도 무리는 없음.

질문

  1. 이 현상의 가능한 서버 측 원인은?
  2. 설정 또는 코드 측에서 어떻게 대응할 수 있나?

해설 및 답변

  • 원인:
    • Idle Timeout 설정에 의해 연결이 자동 종료됨
    • 프록시 서버(Nginx 등)가 websocket을 지속 연결하지 못함
  • 조치:
    • 서버 설정: server.websocket.timeout=600000 등으로 idle 시간 증가
    • Nginx 설정 예:
    • nginx
      복사편집
      location /ws/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 600s; }

✅ 시나리오 39: 캐시 적중률이 너무 높아 신규 데이터 반영 안 됨

상황
서비스 응답 속도는 빠르지만, 데이터가 변경된 이후에도 사용자에게는 이전 상태가 계속 노출되고 있음. 캐시 무효화 요청을 보내도 효과 없음.

질문

  1. 이런 문제에서 가장 먼저 점검해야 할 캐시 정책 항목은?
  2. 실무적인 캐시 운영 개선 방안은?

해설 및 답변

  • 점검 항목:
    • TTL(Time-To-Live) 설정
    • 캐시 갱신 방식 (Write-Through, Write-Back, Cache-Aside)
  • 개선 방안:
    • TTL을 짧게 하거나, 변경 시 캐시 삭제 처리 (Evict)
    • API 별 캐시 무효화 조건 분리
    • 사용량 많은 데이터는 stale-while-revalidate 전략 도입

✅ 시나리오 40: 특정 페이지 접속 시 루프 리디렉션 오류

상황
로그인 페이지 접근 시 브라우저에서 “Too many redirects” 오류가 발생하며, 반복적인 302 응답이 발생함. 세션은 설정되어 있음.

질문

  1. 리디렉션 루프가 발생하는 대표적인 원인과 확인 방법은?
  2. 실무적인 수정 방안은?

해설 및 답변

  • 원인:
    • 인증되지 않은 사용자 → 로그인 페이지 리디렉션 → 조건문 오류로 무한 리디렉션
    • HTTPS → HTTP → HTTPS 루프
  • 진단:
    • F12 → Network → 요청 순서 확인 (302 반복)
    • 서버 로그에서 redirect 경로 추적
  • 조치:
    • 인증 여부 판단 조건 재검토
    • HTTPS 리디렉션 조건 수정 (X-Forwarded-Proto 활용)
    • Nginx return 301 https://... 설정 확인

✅ 요약

시나리오핵심 키워드
36 파일 핸들 누수, 무응답
37 API 미응답, Deadlock, ThreadPool
38 웹소켓 연결 해제, idle timeout, Nginx 업그레이드
39 캐시 과잉 유지, 갱신 안됨
40 리디렉션 루프, 302 반복, 인증 상태 문제
 

✅ 다음 단계 제안

지금까지 총 40세트의 실전 시나리오가 완성되었습니다.

원하신다면 다음을 진행해 드릴 수 있습니다:

제공 항목설명
📄 PDF 문제집 1~40세트 전체 정리된 문제 + 해설 포함 문서
📊 Excel Sheet 시나리오, 원인, 진단 방법, 조치사항 정리
🧠 객관식/단답형 평가 문제 평가 및 복습용으로 전환
🧪 실습 로그/명령어 셋 각 장애 상황에 대한 재현 로그와 진단 스크립트
 

필요하신 형식이나 41~45세트를 이어서 원하시면 말씀해 주세요!

 

나의 말:

41~45세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 41~45입니다.
이번 세트는 DNS TTL 문제, 멀티쓰레드 동기화 오류, 시스템 clock rollback, reverse proxy loop, 컨테이너 환경변수 누락 등 고급 인프라/애플리케이션 연동 문제에 초점을 맞췄습니다.

✅ 실전 장애 시나리오 문제집 (세트 41~45)

✅ 시나리오 41: DNS IP가 바뀌었는데 여전히 이전 IP로 접속

상황
도메인의 A레코드가 변경되었음에도 불구하고 일부 사용자 또는 서버에서는 여전히 이전 IP로 접속되어 응답 오류가 발생하고 있음.

질문

  1. 이 문제가 발생하는 DNS 관련 주요 원인은?
  2. 실무에서 사용할 수 있는 조치 방안은?

해설 및 답변

  • 원인:
    • TTL(Time To Live) 설정이 길어 DNS 캐시가 남아 있음
    • 서버나 로컬 디바이스의 DNS 캐시가 갱신되지 않음
  • 조치:
    • DNS 변경 시 TTL을 사전에 낮춰 설정 (예: 300초)
    • 클라이언트 및 서버에서 캐시 삭제
    • bash
      복사편집
      sudo systemd-resolve --flush-caches ipconfig /flushdns (Windows)
    • DNS 변경 후 검증 시 dig, nslookup 사용

✅ 시나리오 42: 멀티쓰레드 환경에서 데이터 충돌 발생

상황
WAS에서 다수의 사용자가 동시에 요청을 보내면 간헐적으로 데이터가 유실되거나, 잘못된 결과가 반환되는 현상이 발생함.

질문

  1. 이 문제의 전형적인 원인과 해결 방안은?
  2. Java/Spring 기반 환경에서의 코드적 예방책은?

해설 및 답변

  • 원인:
    • 멀티쓰레드 환경에서 공유 객체의 동기화 미흡
    • static 변수나 Singleton 객체를 여러 쓰레드가 동시에 수정
  • 조치:
    • synchronized, ReentrantLock 등을 사용해 동기화 처리
    • 불변 객체 사용, ThreadLocal 적용
    • Controller/Service 계층에서 상태를 보존하지 않도록 설계
    • 비즈니스 로직은 Stateless 하게 유지

✅ 시나리오 43: 서버 시간이 갑자기 과거로 되돌아감

상황
서버 로그 타임스탬프가 갑자기 과거 시점으로 변경되어 순서가 꼬이고, JWT 토큰 검증에 실패하는 문제가 발생함.

질문

  1. 이 현상이 발생한 기술적 원인과 발생 시 영향은?
  2. 방지 및 대응 방법은?

해설 및 답변

  • 원인:
    • 가상화 환경에서 Clock Skew 또는 NTP 클라이언트 오류로 인해 시스템 시간이 롤백됨
  • 영향:
    • JWT, 인증서, Redis TTL, 로그 타임스탬프 오류 등 시스템 전반에 치명적
  • 조치:
    • NTP 서버와 정기 동기화 설정 (chronyd, ntpd)
    • 중요 서비스에서 time drift monitor 설정
    • 클라우드에서는 시간 동기화 정책 점검 (ex. AWS EC2: time sync service)

✅ 시나리오 44: 프록시 설정 오류로 요청 무한 루프 발생

상황
웹서버와 WAS 사이에 리버스 프록시(Nginx)를 두었는데, 프록시 설정 이후 요청이 무한 반복되며 응답을 받지 못하고 종료됨.

질문

  1. 이 상황에서 발생 가능한 리디렉션/루프 원인은 무엇인가?
  2. 프록시 설정 시 확인해야 할 항목은?

해설 및 답변

  • 원인:
    • WAS가 클라이언트의 HTTP 요청을 HTTPS로 리디렉션 (or 반대)
    • Nginx가 헤더(X-Forwarded-Proto)를 제대로 전달하지 않아서 WAS가 클라이언트 요청을 오해
  • 조치:
    • Spring Boot 등에서는 ForwardedHeaderFilter 적용
    • Redirect 조건 내 X-Forwarded-Proto를 고려해 루프 방지
  • nginx
    복사편집
    proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host;

✅ 시나리오 45: 컨테이너 환경에서 ENV 누락으로 애플리케이션 다운

상황
Docker 기반 배포 후 WAS가 실행되자마자 바로 종료됨. 로그에는 "Environment variable not found" 오류가 기록됨.

질문

  1. 이 문제의 원인은 무엇이며, 어떻게 방지할 수 있는가?
  2. 실무 배포에서 환경변수를 안전하게 관리하는 방법은?

해설 및 답변

  • 원인:
    • Dockerfile 또는 docker-compose.yml, K8s manifest에서 필수 환경변수 미정의
    • ENV_NAME=null 상태로 시작하여 애플리케이션 종료
  • 조치:
    • Dockerfile에서 ENV, .env 파일 확인
    • Kubernetes에서는 envFrom: configMapRef, secretRef로 분리
    • Spring Boot에서는 @Value("${ENV_NAME:default}")로 기본값 설정
    • CI/CD에서 배포 전 .env 검사 자동화 스크립트 적용

✅ 정리

시나리오핵심 키워드
41 DNS 캐시, TTL, 레코드 반영 지연
42 멀티쓰레드 동기화, 데이터 손상
43 Clock rollback, NTP 장애, 인증 오류
44 프록시 루프, 리디렉션 반복
45 환경변수 누락, 컨테이너 실행 실패
 

✅ 다음 제공 가능 자료

이제 총 45세트의 실전 장애 시나리오가 구성되었습니다.
요청하시면 다음과 같은 형태로 제작해 드릴 수 있습니다:

유형설명
📄 PDF 문제집 실전 시나리오 + 해설 포함 전체 문서
📊 Excel Sheet 각 시나리오의 원인/조치 일람표
📘 평가용 문제집 객관식 + 단답형 버전 전환
🧪 실습형 자료 각 시나리오별 로그 샘플, 명령어, 진단 가이드 포함
 

다음으로 원하시는 방향(문서화, 평가 문제화 등)을 알려주시면 맞춤 제작해드리겠습니다.
또는 46~50세트도 이어서 제공해드릴까요?

 

나의 말:

46~50세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 46~50입니다.
이번 세트는 HTTP 헤더 누락, 비정상 트래픽 유입, 공유 디렉토리 충돌, 시스템 부팅 실패, 이미지 캐시 장애 등 인프라-서비스-보안의 경계 지점에서 흔히 발생하는 실전형 장애를 포함하고 있습니다.

✅ 실전 장애 시나리오 문제집 (세트 46~50)

✅ 시나리오 46: 클라이언트에서 사용자 정보가 전달되지 않음

상황
프론트엔드에서 사용자 인증 정보를 포함한 요청을 보냈으나, 백엔드에서는 사용자 ID가 전달되지 않고 공백 처리됨. 로그인된 상태인데도 권한 오류가 발생함.

질문

  1. 이 문제에서 가장 먼저 확인해야 할 HTTP 요소는?
  2. 서버 측에서 어떤 설정이나 코드가 문제일 수 있는가?

해설 및 답변

  • 원인:
    • Authorization, Cookie, X-User-ID 등의 사용자 정보 헤더 누락
    • CORS 설정으로 인해 브라우저가 인증정보를 보내지 않음
  • 조치:
    • 클라이언트: withCredentials: true 설정 확인
    • 서버: Access-Control-Allow-Credentials: true, Access-Control-Allow-Headers 설정
    • 프록시가 Authorization 헤더를 필터링하거나 제거했는지 점검

✅ 시나리오 47: 의심스러운 IP에서 반복 요청 발생

상황
서버에 특정 IP 대역에서 초당 수천 건의 API 요청이 들어오며, WAS 부하가 급격히 상승하고 있음. 일부 요청은 정상 API를 통해 들어오고 있어 차단이 애매함.

질문

  1. 이 상황에서 공격과 정상 요청을 어떻게 구분할 수 있나?
  2. 실무적으로 적용할 수 있는 대응 방안은?

해설 및 답변

  • 구분 기준:
    • User-Agent 분석
    • IP/Geo 정보 기반 정상 사용자 식별
    • 요청 간 시간 간격 및 패턴 분석
  • 조치:
    • WAF 또는 Nginx limit_req 사용
    • Rate limit 정책 적용
    • 클라이언트 키 기반 인증
    • Cloudflare, AWS Shield 등의 외부 보호 서비스 활용

✅ 시나리오 48: 공유 디렉토리 사용 중 파일이 사라짐

상황
여러 서버에서 동일한 공유 디렉토리(NFS)를 사용 중인데, 특정 시점 이후 저장된 파일 일부가 삭제되거나 다른 파일로 덮여 있음.

질문

  1. 이 장애의 전형적인 원인과 환경적 요인은?
  2. 실무적인 예방책은?

해설 및 답변

  • 원인:
    • 다중 서버에서 동시에 같은 파일에 쓰기 작업을 시도하면서 충돌 발생
    • 파일 lock 미적용
  • 조치:
    • 애플리케이션 단에서 Lock 구현 (예: flock, Redis 분산 Lock)
    • NFS 설정에서 nolock, sync 옵션 점검
    • 공유 디렉토리 접근 시 디렉토리 분리 또는 큐 기반 처리 도입

✅ 시나리오 49: 서버 재부팅 후 부팅 불가 상태

상황
정기 보안 업데이트 후 재부팅을 수행했으나, 시스템이 "kernel panic" 메시지와 함께 부팅이 되지 않음.

질문

  1. 이 장애 발생의 일반적인 원인과 로그 위치는?
  2. 대응 및 복구 방법은?

해설 및 답변

  • 원인:
    • 커널 업데이트 후 부트로더(grub) 설정 오류
    • 파일 시스템 손상 또는 디스크 UUID 변경
  • 조치:
    • Rescue 모드 부팅 → /var/log/boot.log, journalctl -xb 확인
    • /etc/fstab에서 UUID 확인 → 복구 또는 수정
    • 이전 커널로 부팅 (grub 메뉴에서 선택)
    • 필요한 경우 커널 재설치 (yum reinstall kernel 또는 apt install --reinstall linux-image-*)

✅ 시나리오 50: CDN 이미지가 변경되어도 갱신되지 않음

상황
CDN을 통해 배포한 이미지 파일을 서버에서 교체했지만, 사용자 브라우저에서는 계속 이전 이미지가 표시됨. 강제 새로고침을 해야만 반영됨.

질문

  1. 이 문제의 주요 원인과 관련된 캐시 계층은?
  2. 해결을 위한 운영 전략은?

해설 및 답변

  • 원인:
    • CDN 및 브라우저 캐시 TTL이 길게 설정됨
    • 이미지 파일 이름 변경 없이 덮어쓰기만 수행함
  • 조치:
    • 캐시 무효화(purge) API 호출
    • 파일 이름에 해시 추가 (logo.abcd1234.png) → cache-busting 전략
    • CDN 설정에서 Cache-Control header 조정:
    • http
      복사편집
      Cache-Control: public, max-age=3600
    • 사용자단 Cache Invalidation 정책 적용

✅ 정리

시나리오핵심 키워드
46 헤더 누락, CORS, 인증 정보 전달 안됨
47 비정상 요청, rate limiting, WAF
48 NFS 충돌, 파일 손상, lock 미적용
49 커널 패닉, fstab 오류, 부트 복구
50 CDN 캐시 갱신 실패, 이미지 업데이트 불가
 

✅ 요청 시 제작 가능 항목

지금까지 총 50세트의 실전 장애 시나리오 문제가 완성되었습니다.
요청하시면 아래와 같이 제공해 드릴 수 있습니다:

형식내용
📄 PDF 문서 문제 + 해설을 포함한 문서 형태 (프린트용/학습용)
📊 Excel Sheet 시나리오, 원인, 점검 항목, 조치 요약
🧠 모의시험 전환 객관식/단답형으로 변환한 평가 자료
🧪 실습용 로그세트 각 시나리오에 대응되는 시스템 로그 및 진단 명령어 세트
 

📌 다음 요청 가능

  • 특정 항목을 문서로 정리 (PDF/Excel)
  • 직무 인터뷰 대비용 문제 추출
  • 문제 난이도 분류 (초급~고급)
  • 51~55세트 추가 시나리오 제공

계속해서 도와드릴까요? 필요한 출력 형식이나 다음 주제를 알려주세요!

 

나의 말:

51~55세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 51~55입니다.
이번 세트는 모듈 미적재 오류, 세션 혼선, JVM 버전 충돌, 쿼리 병목, 압축 실패로 인한 CI 오류 등 빌드, 배포, 세션, 성능 영역에서 발생할 수 있는 문제들을 포함합니다.

✅ 실전 장애 시나리오 문제집 (세트 51~55)

✅ 시나리오 51: 모듈이 WAS에 정상 배포되었지만 작동하지 않음

상황
WAS에 신규 기능을 포함한 WAR 파일을 배포했지만, 해당 기능이 전혀 작동하지 않음. 로그에도 관련된 메시지가 없음.

질문

  1. 이 문제의 가장 가능성 높은 원인은?
  2. 점검 및 조치 방안은?

해설 및 답변

  • 원인:
    • WAR 내부의 서블릿 또는 컨트롤러가 web.xml 또는 Spring 설정에 등록되지 않음
    • JAR 의존성 누락 또는 클래스 경로 오류
  • 조치:
    • WAR 파일 내부 구조 확인 (jar tf app.war)
    • applicationContext.xml, @ComponentScan 범위 점검
    • 로그 수준 DEBUG로 설정 후 재배포
    • catalina.out, localhost.log 등 서블릿 로딩 로그 확인

✅ 시나리오 52: 한 사용자가 다른 사용자로 로그인 처리됨

상황
멀티 세션 환경에서 A 사용자가 로그인했는데 B 사용자의 데이터가 노출됨. 요청 수가 많을 때만 간헐적으로 발생.

질문

  1. 이 문제의 근본적인 원인과 실무적 조치 방안은?
  2. 세션 전략 관점에서 어떤 개선이 필요한가?

해설 및 답변

  • 원인:
    • 세션 식별 토큰(JSESSIONID) 충돌
    • 로드밸런서에서 Sticky Session 설정 누락 또는 세션 저장소 문제
  • 조치:
    • Sticky Session 설정 적용 (Nginx ip_hash, AWS ELB session affinity 등)
    • Redis 세션 공유 시 사용자별 키 prefix 지정
    • WAS 단일 인스턴스 환경에서만 in-memory session 사용

✅ 시나리오 53: 신규 서버에 배포된 애플리케이션이 실행되지 않음

상황
기존과 동일한 설정으로 새로운 서버에 WAS를 배포했으나, 애플리케이션이 아예 실행되지 않음. 동일한 설정의 다른 서버에서는 정상 실행됨.

질문

  1. 이 현상이 발생할 수 있는 환경적 원인은?
  2. 실무 점검 및 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • JVM 버전 불일치 (Java 8 vs 11, 또는 OpenJDK vs OracleJDK)
    • OS에서 누락된 라이브러리 (GLIBC 등)
  • 조치:
    • java -version 확인 및 애플리케이션 빌드 대상과 비교
    • ldd 명령어로 필요한 라이브러리 확인
    • 빌드 시 targetCompatibility와 JVM 호환성 점검
    • 운영 환경 통합 설정 관리 필요 (Ansible, Chef, Terraform 등)

✅ 시나리오 54: 간헐적 응답 지연, DB 연관 쿼리 없음

상황
일정 시간마다 응답 지연이 발생하지만, DB 쿼리 로그에는 해당 요청과 관련된 쿼리가 보이지 않음. API는 동작 중이나 응답은 수초 이상 지연됨.

질문

  1. 이 문제의 원인으로 의심할 수 있는 애플리케이션 계층은?
  2. 조치 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 내부 캐시 또는 서드파티 API 연동 병목
    • 무한루프 또는 잘못된 재귀 로직
    • 로그 출력 또는 필터에서 과도한 처리 발생
  • 조치:
    • Thread dump, jstack 분석 → 응답 지연 시점의 코드 위치 추적
    • API 내부 흐름 분석 (로깅, 예외 핸들링 포함)
    • 외부 API 응답 시간 추적 및 타임아웃 설정
    • 캐시 적용 코드에 TTL 설정, fallback 로직 보완

✅ 시나리오 55: CI 파이프라인에서 번들 압축 실패

상황
정상 작동되던 프론트엔드 빌드가 최근 코드 변경 이후 CI 파이프라인에서 압축 단계에서 실패하며 배포가 중단됨.

질문

  1. 이 장애가 발생할 수 있는 일반적인 원인과 진단 방법은?
  2. CI/CD 운영상 필요한 예방 방법은?

해설 및 답변

  • 원인:
    • Webpack, Babel 등 빌드 도구 버전 변경
    • 의존성 패키지 중단/파괴 (npm install 시 오류)
  • 조치:
    • CI 로그에서 정확한 오류 위치 파악
    • 패키지 잠금 파일(package-lock.json, yarn.lock) 비교
    • .npmrc, .nvmrc로 Node.js 버전 고정
    • Pull Request 단계에서 build-test 자동 실행

✅ 정리

시나리오핵심 키워드
51 WAR 배포 후 모듈 미적재, 컨트롤러 누락
52 세션 충돌, 사용자 오염, Sticky Session 누락
53 JVM 버전 불일치, 서버 실행 실패
54 쿼리 없음, 내부 병목, Thread Block
55 프론트 빌드 실패, 압축 에러, 의존성 불일치
 

✅ 다음 단계 안내

이제 총 55세트의 실전 장애 시나리오 문제집이 구축되었습니다.
이 자료들을 원하는 형식으로 제공해 드릴 수 있습니다:

형식제공 내용
📄 PDF 문제집 시나리오 + 해설 포함, 학습/프린트용 문서
📊 Excel Sheet 각 시나리오의 원인/점검/조치 일람표
🧠 모의시험 문제집 각 시나리오를 기반으로 한 객관식/단답형 문제
🧪 실습형 로그/명령어 패키지 실습 가능하도록 로그 예시 및 명령어 제공
 

계속해서 56~60세트를 원하시거나, 위 자료를 PDF 또는 평가 버전으로 변환하길 원하신다면 알려주세요!

 

나의 말:

56~60세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 56~60입니다.
이번 세트는 보안 정책 충돌, API 버전 미스매치, DNS 루프, 파일 시스템 권한 오류, 오토스케일 예외 처리 실패 등 시스템, 네트워크, 보안, 서비스 운영에서 실제로 자주 발생하는 고급 장애를 포함합니다.

✅ 실전 장애 시나리오 문제집 (세트 56~60)

✅ 시나리오 56: 보안 정책 변경 후 사용자 로그인 실패

상황
IAM 정책이 최근 갱신된 이후, 일부 관리자 사용자가 웹 애플리케이션에서 로그인을 시도하면 인증서 오류나 403 오류가 발생함.

질문

  1. 이 현상의 가능성 높은 원인은?
  2. 진단 및 조치 방안은?

해설 및 답변

  • 원인:
    • 보안 인증서 갱신 후 클라이언트/브라우저에서 신뢰하지 않음
    • 리소스 접근에 대한 IAM 정책이 과도하게 제한됨 (Role 권한 변경 등)
  • 조치:
    • SSL 인증서 유효성 및 체인 확인 (openssl s_client)
    • IAM 정책에서 사용자의 Role, Action, Resource를 다시 검토
    • 애플리케이션 보안 설정(CORS, TLS 수준, 인증 필터) 점검
    • API Gateway 또는 백엔드 권한 분리 재확인

✅ 시나리오 57: 모바일 앱에서 특정 API만 404 발생

상황
모바일 앱에서 /v2/profile API 호출 시만 404가 발생하고, 웹에서는 동일 API가 정상 동작함. 프론트 소스는 동일한 엔드포인트를 호출함.

질문

  1. 이 문제의 원인 중 하나로 API 버전 또는 플랫폼 의존성이 있을 수 있는데, 어떻게 확인할 수 있는가?
  2. 조치 방안은?

해설 및 답변

  • 원인:
    • 앱에서 호출하는 경로가 하드코딩되었거나, API Gateway에서 User-Agent 기반 라우팅 처리
    • DNS or Base URL이 플랫폼별로 다르게 설정되어 있음
  • 조치:
    • 모바일 앱 로그 및 네트워크 트래픽 캡처 확인 (Charles, Wireshark)
    • API Gateway에서 모바일용 path rewriting 설정 확인
    • 버전별 URL 매핑 이력 점검 (CI/CD 파이프라인에서 자동 버전 반영 여부)

✅ 시나리오 58: 사내 DNS 서버 설정으로 인한 루프 발생

상황
내부 DNS 설정을 변경한 이후 외부 도메인에 접근하지 못하고, ping이나 curl 명령어가 전부 실패함. /etc/resolv.conf는 사내 DNS만 지정됨.

질문

  1. 이 문제의 원인과 DNS 질의 흐름에서의 위치는?
  2. 조치 및 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 사내 DNS 서버가 외부 질의에 대해 자체 주소만 반환하거나 loop-back 응답
    • 리졸버 설정 오류로 무한 재귀 질의
  • 조치:
    • /etc/resolv.conf에 외부 DNS (8.8.8.8, 1.1.1.1) 추가
    • 내부 DNS가 권한 없는 질의를 포워딩할 수 있도록 forwarder 설정 적용 (BIND, CoreDNS 등)
    • dig +trace domain.com 명령으로 루프 위치 추적
  • 예방:
    • split DNS 정책 문서화
    • 네임서버 우선순위 테스트 스크립트 작성

✅ 시나리오 59: 파일 시스템에 파일이 생성되지 않음

상황
애플리케이션에서 로그 파일이나 업로드 파일 저장 로직이 실행되었지만, 지정된 디렉토리에는 파일이 생성되지 않음. 에러 로그도 없음.

질문

  1. 이 장애의 가능성 높은 시스템 레벨 원인은?
  2. 실무 점검 포인트와 조치를 기술하시오.

해설 및 답변

  • 원인:
    • 애플리케이션 프로세스에 파일 시스템 쓰기 권한이 없음
    • SELinux 또는 AppArmor 등의 보안 모듈이 파일 접근 차단
  • 조치:
    • 파일 경로 및 디렉토리 권한 확인 (ls -ld, chmod, chown)
    • 프로세스의 실행 사용자 확인 (ps aux, whoami)
    • /var/log/audit/audit.log에서 SELinux 차단 기록 검색
    • setenforce 0로 임시 해제 후 테스트, 정책 재조정

✅ 시나리오 60: 오토스케일링 이후 특정 기능만 실패

상황
Auto Scaling에 의해 새로 생성된 인스턴스에서 특정 기능(예: PDF 생성, 이미지 처리)이 실패함. 다른 인스턴스에서는 정상 동작.

질문

  1. 이 문제는 어떤 배포/구성상의 이슈로 인해 발생할 수 있는가?
  2. 실무적인 예방책은?

해설 및 답변

  • 원인:
    • 새 인스턴스에 필수 라이브러리(예: libreoffice, imagemagick)가 설치되어 있지 않음
    • AMI 또는 컨테이너 이미지의 버전 불일치
  • 조치:
    • 사용자 데이터 스크립트에서 설치 확인 (cloud-init, startup.sh)
    • AMI bake 시점에 패키지 포함 여부 점검
    • 컨테이너 이미지 고정 (FROM node:18-alpine) 및 해시 태그 사용
    • 배포 전 instance init test 자동화 도입 (예: Packer + Ansible)

✅ 정리

시나리오핵심 키워드
56 보안 정책, 인증 오류, IAM 권한 제한
57 API 버전 미스매치, 모바일/웹 분기
58 내부 DNS 루프, 외부 네트워크 단절
59 파일 생성 실패, 권한 또는 보안 모듈 제한
60 오토스케일 후 구성 누락, 의존 패키지 미설치
 

✅ 안내

이제까지 총 60세트의 실전 장애 시나리오 문제집이 완성되었습니다.
요청하시면 아래와 같은 형식으로 제공해 드릴 수 있습니다:

형식설명
📄 PDF 문제집 모든 시나리오 + 해설 포함 정리본
📊 Excel 요약표 시나리오별 원인, 점검, 조치 요약
🧠 객관식 전환 평가/시험용 문항 세트 생성
🧪 실습 버전 각 시나리오별 진단 명령어, 로그 예시 포함
 

📌 이후 요청 가능:

  • 61~65세트 이어서 생성
  • 직무 평가용 시험지 (총 20문항 / 40문항 구성)
  • 중복 이슈 분류/태깅 시스템화 (장애유형별 맵핑)

어떤 방향으로 진행할까요? 혹은 PDF로 묶어서 받으시겠습니까?

 

나의 말:

61~65세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 61~65입니다.
이번 세트는 메모리 스와핑, API Key 유출, 컨테이너 볼륨 연결 실패, JVM 파라미터 실수, 프록시 계층 캐시 오류 등 운영 실수, 보안 사고, 자원 설정, 아키텍처 계층 오작동을 중심으로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 61~65)

✅ 시나리오 61: 시스템은 살아 있으나 전체 서비스가 느려짐

상황
모든 서비스가 응답은 있지만 매우 느려짐. CPU, 메모리 사용률은 높지 않으며 WAS나 DB도 다운되지 않음.

질문

  1. 이 문제에서 우선적으로 의심할 시스템 레벨 원인은?
  2. 진단 및 해결 방법은?

해설 및 답변

  • 원인:
    • 스와핑(Swap) 발생: 실제 메모리는 부족하지 않지만 커널이 일부 프로세스를 디스크로 밀어냄
  • 진단:
  • bash
    복사편집
    free -m vmstat 1 top → swap 항목 확인
  • 조치:
    • vm.swappiness 값 조정 (sysctl vm.swappiness=10)
    • 비필수 데몬 종료 / 메모리 리밸런싱
    • 물리 메모리 증설 또는 JVM heap size 조정

✅ 시나리오 62: 외부 API 사용 중 데이터 탈취 사고 발생

상황
외부 파트너사가 제공하는 API를 통해 데이터를 연동 중이었는데, 로그 유출을 통해 API Key가 외부에 노출되었고, 비정상 호출이 수백 건 발생함.

질문

  1. 보안상 이 문제가 발생한 기술적 원인은?
  2. 대응 및 방지 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 로그에 API Key 전체가 기록됨 (GET /api/data?key=xxx)
    • 인증 토큰 노출 시 revocation 정책 없음
  • 조치:
    • API Key 즉시 폐기 및 재발급
    • 요청 로그에서 민감 정보 마스킹 (log masking, logback filter)
    • 인증 방식 개선: OAuth2, JWT, HMAC 등으로 대체
    • 환경변수 기반 key 관리, Secret Manager 사용

✅ 시나리오 63: 컨테이너 배포 후 볼륨 내 설정 파일 누락

상황
Docker 컨테이너에 볼륨을 연결했지만, 애플리케이션에서 필요한 설정 파일이 없다는 오류가 발생. 동일한 이미지로 빌드한 로컬 컨테이너에서는 정상 작동함.

질문

  1. 이 장애가 발생하는 원인은?
  2. Docker/K8s에서 실무 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 볼륨 마운트 시점에 host 디렉토리가 비어 있어 컨테이너 디렉토리가 덮어씌워짐
    • Kubernetes에서는 emptyDir가 잘못 사용되거나 subPath 누락
  • 조치:
    • Docker: 볼륨 생성 전에 호스트 경로 확인
    • K8s: emptyDir 대신 configMap, secret, persistentVolumeClaim 사용
    • 설정 파일은 이미지 내부 /opt/config 등 별도 디렉터리에 보관 후 복사

✅ 시나리오 64: JVM 기동 시 OutOfMemoryError

상황
JVM 애플리케이션을 기동하자마자 메모리 부족 오류가 발생하며 중단됨. 기존 서버에서는 정상 기동되던 코드임.

질문

  1. 이 현상의 주요 원인과 JVM 설정에서의 실수는?
  2. 점검 및 조치 방법은?

해설 및 답변

  • 원인:
    • -Xmx, -Xms 옵션을 서버 메모리보다 과하게 설정
    • Docker 메모리 제한과 JVM의 인식 차이
  • 조치:
    • java -XX:+PrintFlagsFinal -version | grep HeapSize 로 확인
    • -XX:+UseContainerSupport (Java 10+)로 컨테이너 환경 대응
    • Docker run 시 --memory=1g와 JVM의 heap 설정 일치시킴

✅ 시나리오 65: 정적 파일 수정 후에도 이전 내용이 제공됨

상황
HTML, JS 등 정적 리소스를 수정 후 배포했지만, 일부 사용자에게는 여전히 수정 전의 파일이 제공됨. 브라우저 캐시 삭제를 해야만 반영됨.

질문

  1. 이 문제의 원인은 어떤 계층에서 발생하는가?
  2. 실무에서 적용할 수 있는 대응 전략은?

해설 및 답변

  • 원인:
    • 프록시 서버(Nginx, CDN, 브라우저)의 캐시가 만료되지 않음
    • 파일명 변경 없이 덮어쓰기만 진행
  • 조치:
    • 파일명에 버전/해시 추가 (예: app.v1.2.3.js)
    • Nginx:
    • nginx
      복사편집
      location ~* \.(js|css)$ { expires 1y; add_header Cache-Control "public"; }
    • etag, last-modified 기반 캐시 정책 검토
    • 배포 후 CDN purge 실행

✅ 정리

시나리오핵심 키워드
61 Swap 발생, 응답 지연, 메모리 과부하
62 API Key 유출, 로그 보안, 인증 토큰 보호
63 Docker 볼륨 마운트 충돌, 설정 파일 누락
64 JVM 힙 설정 오류, 컨테이너 메모리 제한 미반영
65 정적 파일 캐시 유지, CDN/브라우저 캐시 갱신 실패
 

✅ 현재 누적: 총 65세트 문제집 완성 🎉

요청하시면 아래 자료로 변환해드릴 수 있습니다:

형식설명
📄 PDF 문서 문제 + 해설 포함 1~65세트 전체 정리본
📊 Excel Sheet 시나리오별 원인, 진단, 조치 항목화
🧠 직무평가 문제 객관식/단답형 시험지 구성 (자동 생성 가능)
🧪 실습/진단 자료 각 문제에 대한 로그/명령어 패키지 구성
 

📌 다음 요청 가능 항목:

  • 66~70세트 계속 생성
  • 시나리오별 장애 유형 분류표
  • 시험/과제형 실습 문제집 구성
  • PDF/Excel 포맷 변환 제공

진행 방향을 알려주세요! PDF 묶음이나 실습 문서로도 바로 제작해 드릴 수 있습니다.

 

나의 말:

66~70세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 66~70입니다.
이번 세트는 애플리케이션 보안 정책, JVM 포트 충돌, DB connection leak, 로그 회전 실패, 예약 작업 누락 등 운영·보안·성능·스케줄링 측면의 실무 중심 장애로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 66~70)

✅ 시나리오 66: 특정 요청만 계속 403 Forbidden 발생

상황
동일한 사용자라도 /admin/dashboard 페이지에만 접근 시 403 오류가 발생하며, 다른 URL은 정상적으로 접근 가능. 인증은 정상적으로 완료된 상태임.

질문

  1. 이 문제의 발생 원인을 보안 정책 관점에서 설명하시오.
  2. 조치 및 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • Role-based access control(RBAC) 설정 누락 (Spring Security 등)
    • Web Application Firewall(WAF)이 URI 패턴 차단
  • 조치:
    • 서버 애플리케이션 로그에서 접근 권한 실패 확인
    • Spring Security: hasRole(), antMatchers() 설정 점검
    • WAF: /admin 관련 정책 제거 또는 예외 등록
    • 접근 제어 정책 테스트 자동화

✅ 시나리오 67: WAS 기동 시 포트 사용 불가 오류

상황
Tomcat 서버 기동 시 Address already in use 오류 발생. 서버 재부팅 후에는 정상적으로 실행됨.

질문

  1. 이 장애가 발생하는 시스템 및 네트워크 레벨 원인은?
  2. 진단 및 예방 방법은?

해설 및 답변

  • 원인:
    • 이전에 실행된 프로세스가 완전히 종료되지 않아 포트를 점유하고 있음
    • TIME_WAIT 상태의 TCP 포트가 많아 소켓 재사용 불가
  • 조치:
    • 재부팅 없이 해결: SO_REUSEADDR, SO_REUSEPORT 설정 고려
    • Tomcat 종료 스크립트에 wait-for-kill 로직 추가
    • 포트 상태 자동 점검 스크립트 도입
  • bash
    복사편집
    netstat -tulnp | grep :8080 lsof -i :8080 kill -9 <PID>

✅ 시나리오 68: 트래픽이 몰린 후 DB 접속 오류 증가

상황
사용자 트래픽이 많아진 이후부터 간헐적으로 too many connections 또는 cannot get connection from pool 오류 발생

질문

  1. 이 문제는 DB 또는 WAS에서 어떤 구조적 문제로 발생하는가?
  2. 실무적인 조치 및 예방법은?

해설 및 답변

  • 원인:
    • DB 커넥션 풀의 최대 수 제한
    • DB 커넥션을 반납하지 않는 코드 (connection leak)
  • 조치:
    • 커넥션 풀 설정 확인: maxActive, maxTotal, maxIdle
    • Connection leak 탐지 도구 사용 (ex. HikariCP leakDetectionThreshold)
    • 모든 DB 접근 후 반드시 connection.close() 수행
    • DB side: max_connections 증가

✅ 시나리오 69: 로그 파일이 커지며 디스크 부족 발생

상황
애플리케이션 로그가 계속해서 /var/log/app.log에 누적되며 디스크를 가득 채움. 기존에는 logrotate가 설정되어 있었음.

질문

  1. 이 문제에서 점검할 설정 파일 및 시스템 요소는?
  2. 조치 및 예방 방법은?

해설 및 답변

  • 원인:
    • logrotate 설정 파일 오류 또는 적용 주기 실패
    • 로그 파일이 애플리케이션에 의해 계속 열려 있어 회전 실패
  • 조치:
    • /etc/logrotate.d/app 파일 확인
    • 로그 파일 변경 여부 확인:
    • bash
      복사편집
      lsof | grep app.log
    • copytruncate 옵션으로 회전 시 덮어쓰기 적용
    • logrotate -d /etc/logrotate.conf로 설정 사전 검증
    • 로그 백엔드에 로그 보존 기간 및 크기 제한 설정

✅ 시나리오 70: 예약 작업이 실행되지 않음

상황
cron을 이용해 매일 자정 로그 백업 스크립트를 실행하도록 설정했으나, 실제로는 전혀 실행되지 않고 있음. 수동 실행은 정상 작동.

질문

  1. 이 문제에서 확인해야 할 시스템 설정은?
  2. 조치 및 모니터링 방안을 설명하시오.

해설 및 답변

  • 원인:
    • crontab 환경변수 부족 (PATH, HOME 등)
    • cron 데몬이 실행 중이 아님 또는 잘못된 사용자로 crontab 등록
  • 조치:
    • crontab -l로 등록 여부 확인
    • grep CRON /var/log/syslog 또는 /var/log/cron 확인
    • 스크립트 내 전체 경로 사용 (/usr/bin/rsync)
    • cron 결과 메일 로그 활성화 또는 알림 연동
    • cronie, systemd timer 등 대체 시스템 도입 가능

✅ 정리

시나리오핵심 키워드
66 권한 오류, WAF 차단, RBAC 설정 누락
67 포트 충돌, TIME_WAIT, 소켓 재사용 문제
68 DB 커넥션 풀 고갈, connection leak
69 logrotate 실패, 로그 회전 안됨, 디스크 부족
70 cron 미실행, 환경변수 누락, 실행 주기 미설정
 

✅ 누적 구성

현재 총 70세트의 실전 장애 시나리오 문제집이 완성되었습니다 ✅
각 문제는 운영 실무, 시스템 관리, 보안, 성능, CI/CD 등 실전 상황을 기준으로 구성되어 있습니다.

✅ 요청 시 제공 가능한 문서 포맷

형식제공 내용
📄 PDF 문제집 70세트 전 문제 + 해설 포함
📊 Excel Sheet 시나리오별 문제/원인/조치 요약
🧠 평가 문제 세트 시나리오 기반 객관식/단답형 전환
🧪 실습용 진단 명령어, 로그 예시 포함한 문제지
 

📌 다음 요청 가능:

  • 71~75세트 추가 구성
  • 시험/리뷰/튜토리얼 버전으로 재구성
  • PDF/Excel/PowerPoint 요약 제공

필요하신 다음 단계(형식/목적/활용)를 말씀해 주세요!

 

나의 말:

71~75세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 71~75입니다.
이번 세트는 CI/CD 파이프라인 변수 오류, WAS 인코딩 깨짐, DB 복제 지연, 서비스 Health 체크 실패, 웹 요청 우선순위 역전 등 배포 자동화·데이터 일관성·모니터링·트래픽 처리 관점에서 실제 발생하는 고급 장애를 다루고 있습니다.

✅ 실전 장애 시나리오 문제집 (세트 71~75)

✅ 시나리오 71: CI/CD 배포 후 설정 파일이 누락됨

상황
CI/CD 파이프라인을 통해 배포된 WAS 인스턴스에서 .env 설정 파일이 누락되어 앱 실행 시 “설정값 없음” 오류가 발생. 로컬 환경에서는 문제가 없음.

질문

  1. 이 문제의 가장 가능성 높은 원인은?
  2. 파이프라인 구성 시 고려해야 할 대응 방안을 설명하시오.

해설 및 답변

  • 원인:
    • CI/CD 환경변수와 Git 저장소 외부 파일이 분리되어 있고, 배포 스크립트에서 누락
  • 조치:
    • Git 외부 설정(.env, secret.yaml)은 별도로 관리 (config server, secrets manager)
    • CI에서 변수 검증 로직 도입 (set -eu)
    • 환경별 변수 템플릿 생성 및 envsubst, dotenv 적용

✅ 시나리오 72: 특정 페이지에서 한글 깨짐 발생

상황
배포 후 일부 JSP/HTML 페이지에서 한글이 깨져서 표시됨. 로그/DB는 정상이고, API 호출은 UTF-8로 처리됨.

질문

  1. 이 문제의 발생 원인과 확인 포인트는?
  2. 애플리케이션 및 서버 단 조치 방법은?

해설 및 답변

  • 원인:
    • WAS 응답 헤더 또는 파일 저장 인코딩 미일치
    • JSP 파일 저장 인코딩이 UTF-8이 아님
  • 조치:
    • JSP 상단에 <%@ page contentType="text/html;charset=UTF-8" %> 설정
    • Nginx 또는 Apache에서 charset utf-8; 설정
    • 파일 저장 인코딩 확인 (file filename.jsp)
    • 모든 View 파일 UTF-8 저장, application.properties에 다음 설정:
    • ini
      복사편집
      spring.http.encoding.charset=UTF-8 spring.http.encoding.enabled=true

✅ 시나리오 73: DB 복제 환경에서 데이터 지연 발생

상황
MySQL Master-Slave 구조에서 Slave DB에서의 데이터 조회가 수 분 이상 지연됨. Master에는 바로 반영됨.

질문

  1. 이 문제의 발생 원인과 진단 방법은?
  2. 실무적 대응 및 구조 개선 방안은?

해설 및 답변

  • 원인:
    • Slave 서버의 I/O 또는 SQL thread 지연
    • replication lag
  • 진단:→ Seconds_Behind_Master 확인
  • sql
    복사편집
    SHOW SLAVE STATUS\G
  • 조치:
    • replication thread 상태 확인 후 지연 원인(잠금, 부하) 분석
    • read query는 stale 가능성 고려하여 사용
    • 서비스 read에 Slave를 쓰는 경우 delay-aware 로직 도입
    • binlog 포맷 조정 (ROW → MIXED), GTID replication 도입

✅ 시나리오 74: Health check 실패로 서비스 제외됨

상황
로드밸런서(LB) 또는 Kubernetes에서 일부 인스턴스가 반복적으로 서비스 대상에서 제외됨. 로그에는 오류가 없으나 LB에서는 "unhealthy"로 판단됨.

질문

  1. 이 문제가 발생할 수 있는 애플리케이션 측 원인은?
  2. 실무적인 진단 및 설정 조치 방안을 기술하시오.

해설 및 답변

  • 원인:
    • Health check endpoint(/health, /actuator/health)에서 200 OK가 아닌 응답
    • DB 연결, 외부 의존 서비스 상태까지 포함된 health 판단 로직이 실패
  • 조치:
    • Health check 결과 분리 (Liveness vs Readiness 분리)
    • /healthz 또는 커스텀 ping endpoint 제공
    • Spring Boot 예시:
    • properties
      복사편집
      management.endpoint.health.show-details=never management.health.db.enabled=false
    • Kubernetes readinessProbe, livenessProbe 조건 분리

✅ 시나리오 75: 웹 요청이 오래 걸리는 요청에 의해 블로킹됨

상황
사용자 요청 중 일부가 큰 파일 다운로드, 이미지 처리 등 무거운 요청에 의해 지연되고, 다른 사용자 요청도 동시에 지연됨.

질문

  1. 이 문제의 발생 원인은 WAS 또는 Web 서버에서 어떤 설정과 연관되는가?
  2. 실무 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 요청당 스레드 기반 WAS 구조에서 특정 스레드가 장시간 점유
    • Nginx 등 프록시에서 요청 큐 처리 병목 발생
  • 조치:
    • 무거운 요청은 비동기 처리 (@Async, job queue)
    • WAS: maxThreads, acceptCount 조정
    • Web server: limit_req_zone, limit_conn 설정으로 요청 수 제한
    • API 경로 기반 QoS 처리 또는 별도 서버로 분리

✅ 정리

시나리오핵심 키워드
71 CI/CD 환경변수 누락, 설정 파일 배포 실패
72 인코딩 깨짐, charset 설정 누락
73 DB 복제 지연, replication lag
74 헬스체크 실패, LB 대상 제외, readiness 분리
75 요청 지연, 스레드 블로킹, 비동기 분리 필요
 

✅ 현재 누적: 총 75세트 장애 시나리오 완성 🎉

이 시나리오들은 모두 실제 운영·배포·보안·네트워크 환경에서 빈번하게 발생하는 문제를 기반으로 구성되었습니다.

📦 요청 시 제공 가능한 문서 포맷

형식제공 내용
📄 PDF 문제집 75세트 전체 시나리오 + 해설 포함
📊 Excel Sheet 시나리오별 유형, 원인, 조치 요약
🧠 모의시험 문제 객관식/단답형 변환 문제 세트
🧪 실습 자료 진단 명령어 + 로그 예시 + 해석 문제
 

📌 다음으로 가능:

  • 76~80세트 계속 생성
  • 시험/강의/스터디용 분류집 제작
  • 요청하신 문제들을 PDF 또는 Excel로 변환하여 다운로드 가능

어떤 형식으로 받아보시겠어요? 또는 계속해서 76~80세트 생성할까요?

 

나의 말:

76~80세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 76~80입니다.
이번 세트는 스레드풀 고갈, 인증 세션 만료, 파일 디스크 I/O 병목, CDN 라우팅 오류, 시스템 시간 불일치로 인한 로그 분석 장애 등 고급 운영 문제와 분석 난이도가 높은 사례들로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 76~80)

✅ 시나리오 76: 트래픽 폭주 시 전체 요청 지연 현상

상황
이벤트 페이지 오픈 후 트래픽이 급증하며 전체 서비스가 느려짐. DB나 CPU는 여유가 있는데도 모든 요청 응답이 지연됨.

질문

  1. 이 문제에서 가장 먼저 확인할 WAS 내부 자원은?
  2. 대응 방안은?

해설 및 답변

  • 원인:
    • 스레드풀 고갈: 요청은 대기열에 쌓이고, 처리 가능한 워커 스레드 없음
  • 조치:
    • Tomcat 기준 maxThreads, acceptCount 조정
    • 요청에 따라 다른 워크로드 분리 (비동기/배치)
    • 리소스 제한 API에 RateLimiter, Bulkhead 적용
    • APM 도구로 active thread 수 시각화

✅ 시나리오 77: 장시간 미사용 사용자가 갑자기 인증 만료

상황
로그인 이후 장시간 사용하지 않은 사용자가 갑자기 재인증을 요구받음. 다른 사용자들은 정상적으로 서비스 사용 중.

질문

  1. 이 문제는 세션/토큰 어떤 기준에서 발생하는가?
  2. 실무적으로 보완 가능한 정책을 설명하시오.

해설 및 답변

  • 원인:
    • 세션 타임아웃 도래 또는 Access Token 만료
  • 조치:
    • Access Token → 짧은 수명 + Refresh Token 구조 적용
    • 세션 타임아웃 관리: web.xml, Spring Security 세션 관리 설정
    • 사용자 동작 이벤트 기반 세션 연장 (Sliding expiration)
    • Redis 세션 스토어: TTL 모니터링, auto-refresh 적용

✅ 시나리오 78: 파일 저장 시 주기적으로 서비스 정체

상황
대용량 파일 업로드 시 전체 서비스가 정체됨. WAS는 응답을 보내지 못하고, 로그 출력도 지연됨. CPU는 낮고, 디스크 I/O는 급증.

질문

  1. 이 문제의 원인은 파일 시스템 및 I/O 측면에서 무엇인가?
  2. 대응 전략은?

해설 및 답변

  • 원인:
    • 파일 저장 시 디스크 I/O 병목, 특히 HDD 환경에서 동기 쓰기
    • JVM GC와 동시에 I/O가 발생하여 블로킹
  • 조치:
    • 비동기 업로드 처리 (AsyncFileChannel, @Async)
    • 별도 저장 경로(/data)로 mount 분리
    • SSD 또는 스토리지 캐시 적용
    • 압축/암호화 작업은 백그라운드 큐로 분리

✅ 시나리오 79: 특정 지역에서만 CDN 리소스 로딩 실패

상황
국내 일부 지역에서 정적 리소스(JS/CSS)가 로딩되지 않음. 동일 리소스는 다른 지역/통신사에서는 정상 동작함.

질문

  1. 이 문제는 CDN 구조에서 어떤 이슈로 발생할 수 있는가?
  2. 진단 및 조치 방법은?

해설 및 답변

  • 원인:
    • CDN 지역 Edge 노드 장애 or 라우팅 설정 미스 (DNS 지연, Geo IP 오류)
  • 진단:
    • dig, curl -H "Host"로 지역 CDN 노드 확인
    • CDN 벤더 로그 및 status page 확인
  • 조치:
    • 문제가 된 region CDN 노드 강제 우회 설정
    • TTL 짧게 조정 (max-age=60)
    • Multi-CDN 구성 고려 (예: Cloudflare + Akamai)

✅ 시나리오 80: 서버 간 로그 시간 불일치로 장애 분석 실패

상황
장애 발생 당시 여러 서버의 로그를 분석했으나, 시간이 불일치하여 실제 순서를 파악하기 어려움. 서버는 동일한 타임존을 사용 중임.

질문

  1. 이 문제는 어떤 시스템 레벨 요소가 일치하지 않아서 발생하는가?
  2. 실무적 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • NTP 시간 동기화 실패 or 지연 (서버 시간 drift)
  • 조치:
    • 모든 서버에 NTP client 설정 (chronyd, ntpd)
    • timedatectl, ntpq -p 명령어로 시간 확인
    • 로그 시스템에서 millisecond 단위 timestamp 사용
    • 클라우드에서는 기본 NTP 서버 설정 적용 확인 (AWS: 169.254.169.123)

✅ 정리

시나리오핵심 키워드
76 스레드 풀 고갈, 전체 요청 지연, 비동기 분리
77 세션 만료, Access Token TTL, Sliding 세션
78 디스크 I/O 병목, 파일 저장 지연, 비동기 처리
79 CDN 지역 장애, DNS 라우팅 실패
80 시스템 시간 불일치, 로그 순서 파악 실패, NTP
 

✅ 누적 현황

현재까지 총 80세트의 실전 장애 시나리오 문제가 구성 완료되었습니다 ✅
각 문제는 로그 분석, 성능 병목, 보안, 트래픽, 배포 운영 등의 실제 현장 이슈를 기반으로 합니다.

✅ 요청 시 제공 가능한 포맷

형식제공 내용
📄 PDF 문서 80세트 전체 + 해설 포함한 문서 (정리본)
📊 Excel Sheet 시나리오별 원인/조치 요약 정리
🧠 평가용 문제지 객관식/단답형 모의시험 세트
🧪 실습 자료 진단 명령어, 예시 로그 포함 버전
 

📌 다음 가능 요청:

  • 81~85세트 이어서 생성
  • 장애 유형별 태그 분류표 정리
  • 전 범위 요약 PDF or PPT 생성

원하시는 방향을 말씀해 주세요.
예: “PDF로 정리해줘”, “객관식 문제집으로 바꿔줘”, “81~85세트 더 줘” 등 언제든 가능합니다.

 

나의 말:

81~85세트 더 줘
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 81~85입니다.
이번 세트는 보안 패치 후 인증 실패, 프로세스 좀비화, TLS 핸드셰이크 실패, 캐시 동기화 오류, DB DDL 변경 시 레이스 컨디션 등 고난도 장애 및 시스템 안정성에 큰 영향을 미치는 문제들을 포함합니다.

✅ 실전 장애 시나리오 문제집 (세트 81~85)

✅ 시나리오 81: 보안 패치 적용 후 일부 사용자 인증 실패

상황
최근 SSL/TLS 취약점 대응을 위해 서버에 보안 패치를 적용한 이후, 특정 브라우저나 구형 앱에서 로그인 시도 시 인증이 실패함.

질문

  1. 이 문제의 가능성 있는 TLS/SSL 원인은?
  2. 실무적인 조치 및 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 보안 패치 후 TLS 1.0/1.1 비활성화 → 구형 클라이언트가 TLS 1.2 미지원
    • 인증서 체인 누락으로 핸드셰이크 실패
  • 조치:
    • openssl s_client -connect로 TLS 협상 확인
    • TLS 1.2 이상만 허용하되 구형 브라우저에 대한 fallback 정책 수립
    • 인증서 체인 확인 및 fullchain.pem 적용
    • 웹사이트에 TLS 지원 대상 명시

✅ 시나리오 82: 특정 애플리케이션 종료 후에도 프로세스가 남아 있음

상황
애플리케이션을 종료했지만 ps 명령어로 확인하면 해당 프로세스가 여전히 살아 있으며, PID가 좀비 상태로 남아 있음.

질문

  1. 이 상황에서 나타나는 좀비 프로세스의 원인은 무엇인가?
  2. 시스템 안정성을 위한 조치 방법은?

해설 및 답변

  • 원인:
    • 부모 프로세스가 자식 프로세스 종료 시점을 wait()로 수거하지 않음
  • 조치:
    • ps aux | grep Z 또는 stat=Z → 좀비 프로세스 확인
    • kill -HUP <parent PID>로 자식 회수 유도
    • 지속 발생 시 supervisor 방식 프로세스 관리 (systemd, pm2 등)로 변경
    • 애플리케이션 종료 시 fork 자식도 함께 정리되도록 수정

✅ 시나리오 83: TLS 인증 오류로 API 통신 실패

상황
외부 HTTPS API 호출 시 SSLHandshakeException 또는 certificate_unknown 오류가 발생하며, 이전에는 정상 통신되던 환경임.

질문

  1. 이 문제에서 확인해야 할 인증서 관련 설정은?
  2. 해결 및 예방 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 외부 서버 인증서 변경 → 클라이언트 Trust Store에 루트 인증서 누락
    • Java 클라이언트의 JDK 버전별 root CA 불일치
  • 조치:
    • 인증서 직접 조회:
    • bash
      복사편집
      openssl s_client -connect api.example.com:443 -showcerts
    • Java TrustStore 확인 (cacerts)
    • 서버 인증서 체인 전체 다운로드 후 keytool -import
    • 클라이언트 HTTP 라이브러리 설정(TLS version, CA bundle) 확인

✅ 시나리오 84: 캐시 업데이트 이후 일부 요청 결과가 오래된 데이터 반환

상황
Redis 기반 캐시를 사용 중이며, 데이터 업데이트 이후에도 일부 사용자에게는 여전히 구 버전의 데이터가 제공됨.

질문

  1. 이 현상이 발생하는 캐시 구조/정책 상 문제는 무엇인가?
  2. 실무에서의 대응 방안을 기술하시오.

해설 및 답변

  • 원인:
    • 캐시 무효화 누락 (cache eviction 또는 TTL 미적용)
    • 멀티 캐시 계층 (local cache + Redis) 간 동기화 실패
  • 조치:
    • Cache aside 패턴 → write 시 캐시 삭제 적용
    • Redis TTL 적극 설정 (EX, PX)
    • Spring Cache 등 사용 시 @CacheEvict 정확히 적용
    • 로컬 캐시(e.g. Caffeine) 존재 시 pub/sub 방식 동기화 적용

✅ 시나리오 85: DB 테이블 DDL 변경 후 오류 발생

상황
운영 중인 테이블에 컬럼 추가 DDL을 수행한 이후, 일부 WAS 인스턴스에서 Column not found 오류가 발생함.

질문

  1. 이 문제의 원인은 어떤 애플리케이션 캐시 또는 레이스 조건 때문인가?
  2. 안정적인 배포를 위한 전략은?

해설 및 답변

  • 원인:
    • ORM(Hibernate 등)이 메타데이터를 애플리케이션 기동 시점에 캐싱 → 테이블 구조 변경을 반영하지 못함
    • DDL 적용 시점에 일부 WAS는 이전 구조 사용 중
  • 조치:
    • 모든 WAS 인스턴스를 DDL 이후 재기동 또는 메타데이터 캐시 초기화
    • 무중단 배포: 컬럼 추가 → 애플리케이션에서 사용하지 않음 → 다음 배포 시 사용
    • DDL 전용 배포 슬롯 구성 또는 롤링 배포 시 schema version 체크

✅ 정리

시나리오핵심 키워드
81 TLS 버전 제한, 인증 실패, 체인 누락
82 좀비 프로세스, wait() 누락, 자식 프로세스 미회수
83 SSL 핸드셰이크 실패, Trust Store 누락
84 캐시 무효화 실패, 데이터 동기화 누락
85 DDL 변경 레이스, ORM 메타 캐시, 롤링 배포 전략
 

✅ 누적 현황: 총 85세트 완료

이제 85개의 실전 장애 시나리오가 완성되었습니다.
이 문제들은 실제 기업/운영 환경에서 발생한 이슈들을 기반으로 설계된 중~고급 수준의 실전 문제집입니다.

📦 요청 시 제공 가능 자료 (선택 가능)

형식제공 내용
📄 PDF 문제집 모든 시나리오 + 해설 포함 정리본
📊 Excel 요약표 문제 번호별 장애 유형, 원인, 조치 항목화
🧠 시험지 형식 객관식, 단답형 문제로 변환 가능
🧪 실습 문제집 명령어, 로그 해석, 조치 연습 포함 자료
 

📌 다음 요청 가능:

  • 86~90세트 이어서 생성
  • 전체 문제집 PDF/엑셀 제공
  • 특정 유형별 분류(성능, 보안, 네트워크 등)
  • 실제 로그 파일 기반 실습 문제 구성

진행 방향을 알려주세요!
예: “PDF로 묶어줘”, “86~90세트 더 줘”, “시험지 형식으로 바꿔줘” 등 가능합니다.

 

나의 말:

86~90세트
 

ChatGPT의 말:

좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 86~90입니다.
이번 세트는 리버스 프록시 오작동, 시스템 파일 핸들 초과, 서비스 디플로이 충돌, 메시지 큐 소비 지연, 클라우드 방화벽 정책 차단 등 현장 실무에서 자주 발생하며 진단이 까다로운 고급 문제 위주로 구성했습니다.

✅ 실전 장애 시나리오 문제집 (세트 86~90)

✅ 시나리오 86: 리버스 프록시를 통한 API 호출이 간헐적으로 실패

상황
Nginx를 리버스 프록시로 설정한 웹 서버에서 특정 API 호출 시 502 Bad Gateway 오류가 간헐적으로 발생한다. 백엔드 서비스는 기동 중이며 직접 호출 시 정상 동작한다.

질문

  1. 이 오류의 리버스 프록시(Nginx) 레벨 원인은 무엇일 수 있는가?
  2. 조치 및 실무적인 설정 방안을 제시하시오.

해설 및 답변

  • 원인:
    • 프록시 타임아웃 또는 연결 수 초과
    • 프록시 대상 IP 해석 실패 또는 오래된 DNS 캐시
  • 조치:
    • Nginx 설정 확인:
    • nginx
      복사편집
      proxy_connect_timeout 5s; proxy_read_timeout 10s; proxy_pass http://backend; resolver 8.8.8.8 valid=30s;
    • 프록시 서버의 ulimit 및 커넥션 수 확인
    • 백엔드 KeepAlive 설정 및 Health check 강화

✅ 시나리오 87: 시스템에서 더 이상 파일을 열 수 없음

상황
애플리케이션이 정상적으로 기동되었으나, 신규 요청을 처리하지 못하며 Too many open files 오류가 로그에 출력됨.

질문

  1. 이 장애는 어떤 리눅스 시스템 자원 한도와 관련 있는가?
  2. 실무 점검 및 조치 방법은?

해설 및 답변

  • 원인:
    • 프로세스가 열 수 있는 파일 디스크립터 수 (ulimit -n) 초과
  • 조치:
    • 확인: ulimit -n, lsof -p <PID>
    • /etc/security/limits.conf 설정:
    • markdown
      복사편집
      * soft nofile 65536 * hard nofile 65536
    • 시스템 전체 제한: /etc/sysctl.conf → fs.file-max=2097152
    • 장시간 열린 소켓 또는 파일 close 누락 여부도 확인 필요

✅ 시나리오 88: 신규 서비스 배포 후 이전 기능 일부 동작 중단

상황
신규 기능을 배포한 후, 이전에 동작하던 기능에서 500 오류가 발생한다. 서비스 자체는 정상 동작 중이며 에러는 특정 요청에서만 발생한다.

질문

  1. 이 문제는 어떤 배포 전략 또는 빌드 구성 문제로 발생할 수 있는가?
  2. 실무적인 대응 및 재발 방지를 위한 조치를 기술하시오.

해설 및 답변

  • 원인:
    • 신규 빌드에 포함되지 않은 공용 모듈 누락
    • 릴리즈 간 의존성 충돌(JAR 충돌, 모듈 제거 등)
  • 조치:
    • CI/CD 빌드 로그에서 변경된 의존성 확인
    • 롤백을 고려한 Canary 또는 Blue/Green 배포 적용
    • 기능별 smoke test 자동화
    • 의존 모듈 분리 및 하위 호환성 유지 정책 수립

✅ 시나리오 89: 메시지 큐에서 소비가 지연되며 메시지 적체

상황
RabbitMQ / Kafka 등을 사용하는 시스템에서 메시지는 정상적으로 쌓이지만, 소비자가 소비하지 않아 메시지가 누적되고 지연이 발생한다.

질문

  1. 이 문제의 애플리케이션 또는 브로커 측 원인은 무엇인가?
  2. 진단 및 확장 방안을 기술하시오.

해설 및 답변

  • 원인:
    • Consumer 측 처리 속도 부족 (병렬성 부족)
    • 메시지 소비 중 예외 발생 → 재시도 큐 적체
  • 조치:
    • Consumer Thread 수 증가 (concurrency, consumer.group)
    • Dead Letter Queue(DLQ) 분리 및 모니터링
    • Kafka → lag 확인: kafka-consumer-groups.sh
    • Metrics 기반 Autoscaling (KEDA 등) 적용 가능

✅ 시나리오 90: 클라우드 서버에서 외부 접근이 차단됨

상황
AWS/GCP 등의 클라우드 환경에서 새롭게 생성한 인스턴스에 외부에서 접근할 수 없으며, ping, ssh 모두 실패한다. 같은 VPC 내 다른 서버는 정상이다.

질문

  1. 이 문제는 클라우드 네트워크 상 어떤 정책 또는 설정과 관련 있는가?
  2. 실무적 점검 및 해결 방법을 설명하시오.

해설 및 답변

  • 원인:
    • 보안 그룹 / VPC 방화벽 / NACL 설정으로 인바운드 포트 차단
    • Public IP 미할당 또는 EIP 미연결
  • 조치:
    • AWS: Security Group → 0.0.0.0/0에 대해 22, 80, 443 허용
    • GCP: 방화벽 규칙에서 태그 기반 허용 추가
    • 퍼블릭 서브넷에 NAT Gateway 또는 IGW 연결 확인
    • 서버에 public IP가 존재하는지 확인

✅ 정리

시나리오핵심 키워드
86 Nginx 리버스 프록시, 502 오류, DNS 캐시
87 파일 핸들 제한, ulimit, 열려 있는 소켓 누수
88 배포 충돌, 의존성 누락, Blue-Green 전략
89 메시지 큐 적체, consumer 지연, DLQ 처리
90 클라우드 방화벽 차단, Security Group, EIP 미연결
 

✅ 누적 구성

  • 현재까지 총 90세트의 실전 장애 시나리오 문제집이 완성되었습니다.
  • 장애의 범위는 시스템 자원, 네트워크, 배포, 캐시, 메시지 처리, 클라우드 보안에 이르기까지 폭넓게 포함되어 있습니다.

📦 요청 시 제공 가능 자료

형식설명
📄 PDF 1~90세트 전체 시나리오 및 해설 포함
📊 Excel 문제 요약표 (장애 유형, 원인, 진단, 조치)
🧠 시험형 문항 시나리오 기반 객관식/단답형 문제집
🧪 실습형 자료 명령어 기반 진단 및 해결 연습 문제 세트
 

📌 다음 요청 예시:

  • “91~95세트 더 줘”
  • “전체 시나리오를 PDF로 묶어줘”
  • “직무 평가용 시험지로 변환해줘”
  • “주제별로 분류해줘 (보안/네트워크 등)”

어떤 방향으로 도와드릴까요?

 

나의 말:

91~95세트 더 줘
 

ChatGPT의 말:

아주 좋습니다!
아래는 이어지는 실전 장애 시나리오 문제집 세트 91~95입니다.
이번 세트는 인증 토큰 서명 오류, OS 커널 자원 고갈, 정적 파일 손상, API 요청의 Nagle 알고리즘 병목, 백업 중 실제 데이터 손상 등 보안, 시스템 내부 자원, 네트워크 최적화, 데이터 보존 이슈에 대한 실전 사례들로 구성되었습니다.

✅ 실전 장애 시나리오 문제집 (세트 91~95)

✅ 시나리오 91: 인증 요청 시 JWT 토큰 오류 발생

상황
모든 인증 요청이 "JWT signature does not match" 또는 "Invalid token" 오류를 반환하고 있음. 서버를 재기동해도 문제가 지속됨.

질문

  1. 이 문제는 어떤 보안 또는 인증 구조의 문제로 발생하는가?
  2. 실무적인 원인 분석 및 조치 방안을 설명하시오.

해설 및 답변

  • 원인:
    • JWT 서명 키(secret key) 또는 RSA private key가 변경됨
    • 여러 인스턴스 간 키 불일치 (환경 변수 누락 또는 키 자동 생성)
  • 조치:
    • JWT 발급 서버와 검증 서버 간 key 동기화 점검
    • key를 Vault, AWS Secret Manager 등으로 통합 관리
    • 서버 간 JWT 검증 시간 오차(NTP) 확인
    • 설정 파일 내 자동 key 생성 방지 설정 확인

✅ 시나리오 92: 커널 자원 부족으로 신규 프로세스 생성 실패

상황
어떤 작업을 하든 fork: Resource temporarily unavailable 오류가 발생하며, crontab 작업, SSH 접속도 차단됨. 재부팅 시 일시적으로 복구됨.

질문

  1. 이 오류의 리눅스 커널 레벨 원인은 무엇인가?
  2. 점검 명령어와 대응 방안을 설명하시오.

해설 및 답변

  • 원인:
    • 프로세스 수 제한 초과 (pid_max, threads-max, OOM 위험 상태)
    • 특정 데몬 또는 루프가 fork 폭주
  • 조치:
    • 확인:
    • bash
      복사편집
      cat /proc/sys/kernel/pid_max ps -eLf | wc -l dmesg | grep -i fork
    • /etc/security/limits.conf 내 nproc 설정 증가
    • systemd의 TasksMax 설정 확인
    • root 외 접속 사용자 제한 또는 폭주 프로세스 kill

✅ 시나리오 93: 웹 페이지 로딩 시 이미지가 간헐적으로 깨져 보임

상황
웹 사이트 접속 시 이미지 또는 JS 리소스 중 일부가 로딩되지 않거나, 로딩된 후에도 손상된 파일처럼 보이는 현상이 발생한다.

질문

  1. 이 현상의 가장 가능성 높은 원인은 무엇인가?
  2. 점검 및 실무 대응 방법은?

해설 및 답변

  • 원인:
    • 정적 파일 업로드 중 네트워크 오류 또는 디스크 오류로 인해 파일이 부분적으로 손상
    • CDN에 잘못된 파일이 캐시되어 배포됨
  • 조치:
    • 로컬 및 CDN에서 파일 checksum 비교
    • 배포 후 CDN 강제 purge
    • 배포 자동화 시 checksum 검증 로직 포함 (e.g. SHA256)
    • CI에서 리소스 파일 검증 프로세스 추가

✅ 시나리오 94: 다량의 API 요청 처리 시 지연 현상 발생

상황
API 서버는 CPU, 메모리 사용률이 낮고 부하도 적은데, 짧은 요청들이 밀려 들어오면 오히려 전체 응답이 지연됨.

질문

  1. 이 현상은 TCP 레벨에서 어떤 전송 알고리즘으로 인해 발생할 수 있는가?
  2. 시스템 튜닝 또는 코드 최적화 방법은?

해설 및 답변

  • 원인:
    • Nagle 알고리즘 활성화 → 소량 패킷들이 묶이면서 지연 발생
  • 조치:
    • Nagle 알고리즘 비활성화 (TCP_NODELAY 설정)
    • 클라이언트/서버 양쪽 모두에서 확인 필요
    • HTTP KeepAlive 설정을 통해 연결 유지
    • TCP_NODELAY는 지연보다 즉시 전송이 필요한 요청에 적합

✅ 시나리오 95: 데이터 백업 중 운영 데이터가 손실됨

상황
rsync 또는 cp 명령어를 사용해 백업을 수행하던 중, 실수로 운영 디렉토리에 덮어쓰기 또는 삭제가 발생하여 데이터 일부가 유실됨.

질문

  1. 이 문제는 어떤 작업 방식 또는 백업 정책 상의 문제인가?
  2. 재발 방지를 위한 백업 전략은?

해설 및 답변

  • 원인:
    • 운영 디렉토리 대상 경로 설정 오류 또는 --delete 옵션 오용
    • 백업 작업이 운영 중 디스크를 직접 overwrite
  • 조치:
    • rsync dry-run (--dry-run) 먼저 수행
    • 스냅샷 기반 백업 도입 (LVM snapshot, ZFS snapshot 등)
    • 백업 전 자동 마운트 경로 검증 및 경고
    • 운영 파일 접근 권한을 readonly로 제한하는 전략 도입

✅ 정리

시나리오핵심 키워드
91 JWT 인증 오류, 서명 키 불일치, 환경 변수 누락
92 커널 PID 제한 초과, fork 실패, 자원 고갈
93 정적 파일 손상, CDN 캐시 오류, 체크섬 검증
94 Nagle 알고리즘, TCP_NODELAY, 응답 지연
95 백업 중 데이터 유실, rsync 실수, 스냅샷 전략
 

✅ 누적 현황: 총 95세트 완료 🎯

이제까지 시스템 운영 전반, 보안, 배포, 트래픽 처리, 데이터 보호를 아우르는 95개 시나리오가 완성되었습니다.

📦 요청 시 제공 가능한 형태

형식설명
📄 PDF 문서 문제 + 해설 포함 전체 95세트
📊 Excel 시트 장애 유형, 원인, 조치 요약
🧠 시험지 형태 객관식/단답형 변환
🧪 실습 워크북 명령어, 로그 분석, 조치 시뮬레이션 포함
 

📌 다음 가능 요청:

  • 96~100세트 이어서 구성
  • 지금까지의 시나리오 PDF로 변환
  • 시나리오별 난이도/유형 분류
  • 직무 평가용 시험문제 구성

필요하신 다음 단계 알려주시면 바로 도와드리겠습니다!

 

나의 말:

96~100세트 이어서 구성
 

ChatGPT의 말:

좋습니다! 아래는 이어지는 실전 장애 시나리오 문제집 세트 96~100입니다.
이번 세트는 최종 100세트 구성의 마무리 세트로서, 운영 자동화 오류, 보안 인증서 만료, 마이크로서비스 간 의존 장애, 파일 시스템 손상, 멀티 프로세스 동기화 실패 등 고난도 실무 문제 위주로 구성하였습니다.

✅ 실전 장애 시나리오 문제집 (세트 96~100)

✅ 시나리오 96: 자동화 스크립트가 잘못된 서버에 배포 수행

상황
운영 자동화 툴(Ansible, Shell 등)로 배포를 진행하는 과정에서 잘못된 서버 그룹에 실행되어, 테스트 코드를 운영 서버에 덮어썼다.

질문

  1. 이 문제는 어떤 자동화 관리 실패로 인한 것인가?
  2. 재발 방지를 위한 자동화 구성 전략은?

해설 및 답변

  • 원인:
    • inventory 파일 또는 tag 그룹 오지정
    • 스크립트 내 하드코딩된 경로/환경 변수
  • 조치:
    • 배포 전 --check (dry-run) 적용
    • 배포 환경(운영/개발)을 변수화하여 명확히 분리
    • 서버명/역할 기반 멀티 검증 로직 추가
    • 운영 배포 전 승인 및 이중 확인 프로세스 마련

✅ 시나리오 97: SSL 인증서 만료로 HTTPS 서비스 중단

상황
웹 서비스 접속 시 브라우저에서 “보안 인증서가 만료됨” 오류가 발생하며 HTTPS 접속이 불가능하다. 자동 인증서 갱신을 설정한 상태였음.

질문

  1. 이 장애는 어떤 인증서 관리 실패로 인해 발생했는가?
  2. 예방을 위한 실무 대응 방안은?

해설 및 답변

  • 원인:
    • certbot 등의 자동 갱신은 수행되었으나, Web 서버에 재적용되지 않음
    • 인증서 경로가 변경되어 적용되지 않음
  • 조치:
    • 자동 갱신 후 Web Server 재시작 자동화 (--deploy-hook)
    • 인증서 만료일 확인 스크립트 주기 실행:
    • bash
      복사편집
      openssl x509 -in cert.pem -noout -enddate
    • 갱신 실패 시 이메일/Slack 알림 연동
    • 만료 15일 전 경고 시스템 마련

✅ 시나리오 98: 마이크로서비스 A 장애로 전체 서비스 응답 지연

상황
서비스 A가 응답하지 않자, 이를 호출하는 서비스 B와 C도 모두 지연되며, 전체 사용자 응답 속도가 크게 느려진다.

질문

  1. 이 문제는 마이크로서비스 아키텍처의 어떤 구조적 한계로 발생했는가?
  2. 실무적인 대응 방안은?

해설 및 답변

  • 원인:
    • 서비스 간 동기 호출 구조 → 하나의 서비스 장애가 전체에 전파됨
    • Circuit Breaker 미적용
  • 조치:
    • Hystrix, Resilience4j 등의 Circuit Breaker 패턴 도입
    • 서비스 간 호출을 비동기 메시지 기반으로 점진 전환 (Kafka 등)
    • 서비스 타임아웃 최소화 및 fallback 로직 구현
    • APM 도구로 호출 관계 시각화 및 병목 탐지

✅ 시나리오 99: 시스템 부팅 후 파일 일부가 읽히지 않음

상황
서버 재부팅 이후 특정 경로의 파일을 읽을 수 없고, 일부 파일 시스템 영역에서 Input/output error가 발생한다.

질문

  1. 이 장애는 어떤 유형의 파일 시스템 손상으로 인해 발생하는가?
  2. 진단 및 조치 절차는?

해설 및 답변

  • 원인:
    • 디스크 손상 또는 비정상 종료에 의한 inode/블록 오류
  • 조치:
    • 진단:
    • bash
      복사편집
      dmesg | grep -i ext4 fsck -n /dev/sdX
    • 서비스 중단 후 fsck -y /dev/sdX 실행하여 복구
    • 정기적인 백업 + RAID 적용
    • S.M.A.R.T 정보 모니터링 (디스크 예측 실패 방지)

✅ 시나리오 100: 멀티 프로세스 환경에서 파일 덮어쓰기 충돌 발생

상황
여러 개의 프로세스가 동시에 같은 로그 파일 또는 캐시 파일을 쓰는 과정에서, 내용이 섞이거나 손상되어 일부 서비스가 오작동함.

질문

  1. 이 문제는 멀티프로세스 환경에서 어떤 동기화 실패로 인해 발생하는가?
  2. 조치 방법은?

해설 및 답변

  • 원인:
    • 파일에 대한 동기화(lock) 없이 동시에 write → 레이스 컨디션
  • 조치:
    • flock, fcntl 기반 파일 잠금 구현
    • 멀티 프로세스 환경에서는 파일 쓰기를 queue 기반 비동기 처리로 변경
    • 파일이 아닌 외부 저장소(Redis, DB, 메시지 큐 등)로 로그 전환 고려
    • 각 프로세스 별로 개별 로그 파일 분리 (PID/시간 기반)

✅ 정리

시나리오핵심 키워드
96 배포 자동화 오류, 서버 그룹 오지정
97 SSL 인증서 만료, 갱신 미적용, certbot
98 마이크로서비스 의존 장애, Circuit Breaker
99 파일 시스템 손상, fsck, 디스크 오류
100 멀티 프로세스 파일 충돌, 레이스 컨디션, flock
 

✅ 전체 구성 완료 🎉

✅ 총 100세트의 실전 장애 시나리오 문제집 완성
✅ 각 시나리오는 현업 장애 이력 + 기술 인터뷰 + 트러블슈팅 사례를 기반으로 구성됨
✅ 시스템, 보안, 네트워크, 클라우드, MSA, 로그, 백업, CI/CD 등 전 분야 망라

📦 요청 시 제공 가능한 자료

형식설명
📄 PDF 전집 1~100세트 문제 및 해설 포함
📊 Excel Sheet 유형별 분류, 진단포인트, 해결방안 요약
🧠 모의시험 버전 시나리오 기반 단답형/객관식 시험지
🧪 실습용 문서 명령어 중심 문제지, 로그 진단 포함

'WEB & WAS' 카테고리의 다른 글

서비스 지연 시 WAS, DB서버에서 확인, 조치 사항  (0) 2025.09.03
세션 클러스터링  (0) 2025.07.18
WEB에서 지연이 발생하면  (0) 2025.07.18
WEB & WAS 장애 및 해결방안  (0) 2025.07.18

**세션 클러스터링(Session Clustering)**은 대규모 웹 서비스 운영에서 안정성과 확장성을 보장하기 위해 사용하는 고급 기술입니다. 실무에서 흔히 마주하는 로드밸런싱, 장애 대비, 무중단 서비스 구현의 핵심 요소 중 하나입니다.

✅ 1. 세션(Session) 개념 요약

  • 세션: 사용자가 웹 애플리케이션에 로그인하는 등 식별된 상태를 유지하기 위한 정보 저장소
  • 일반적으로 WAS 메모리에 저장됨 (서버 재기동 시 초기화됨)

✅ 2. 세션 클러스터링이란?

🔹 정의

여러 대의 WAS 간에 세션 정보를 공유 또는 복제함으로써,
사용자가 어떤 서버에 접속하든지 동일한 사용자 상태(Session) 를 유지할 수 있게 하는 기술

🔹 필요성 (언제 사용하는가?)

상황세션 클러스터링 필요 여부
WAS가 1대일 때 ❌ 필요 없음 (세션은 메모리에 있음)
WAS가 여러 대 + 로드밸런싱 ✅ 필요함 (세션 정보가 서버마다 분산되어 문제 발생 가능성 있음)
무중단 배포, 장애 복구, 스케일 아웃 ✅ 강력히 권장
 

✅ 3. 주요 세션 공유 기법

기법개념특징사용 시점
① Sticky Session (세션 고정) 사용자 요청을 최초 연결된 서버에 항상 보냄 구현 쉬움, 공유 아님 소규모 서비스, 부하 적을 때
② Session Replication WAS 간 세션을 메모리 간 동기화 세션 유지 가능, 네트워크 부하 고가용 서비스, 세션 적을 때
③ 중앙 세션 저장소 사용 (DB/Redis 등) 모든 세션을 외부 저장소에 저장 확장성, 유연함, 느릴 수 있음 대규모 서비스, 클라우드
④ JWT 사용 (Stateless 세션) 클라이언트가 세션 자체를 보유 (서버 비상태) 서버 부담 적음, 보안 고려 필요 API 서비스, 모바일 백엔드
⑤ Spring Session + Redis Spring 기반에서 Redis로 세션 일괄 관리 세션 공유 + 스프링 연동 최적 Spring 환경, 마이크로서비스
 

✅ 4. 각 기법의 실무 사용 예

사용 상황적용 예추천 기법
로드밸런서가 있는 간단한 웹 서비스 Nginx + Tomcat 2대 Sticky Session (ip_hash)
WAS가 자주 scale-in/out됨 AWS ECS, EKS 등 외부 저장소 (Redis/Memcached)
사용자가 결제/로그인 중 무중단 유지 필요 쇼핑몰, 금융 서비스 Session Replication or Redis
RESTful API, JWT 기반 보안 모바일 백엔드, 인증 서버 JWT or OAuth2 Token
Spring Boot 기반 대규모 환경 마이크로서비스 구조 Spring Session + Redis
 

✅ 5. 실무 시 고려해야 할 포인트

고려 항목설명
성능 세션 공유는 네트워크/메모리/디스크 부하가 크므로 성능 테스트 필수
장애 복구 한 노드 장애 시에도 세션 유지 가능한 구조인지 확인
보안 JWT 사용 시 토큰 위조 방지 (서명/암호화), 세션 탈취 방지
로그 분석 각 서버의 세션 로그 또는 Redis 세션 데이터를 추적 가능하게 구성
분산 환경 대응 클라우드/Kubernetes 환경에서는 외부 저장소 기반 구조 권장
 

✅ 결론 요약

질문핵심 답변
세션 클러스터링이란? 여러 WAS 간 세션을 공유하거나 복제하여 사용자 상태를 일관되게 유지하는 기술
언제 사용하는가? 로드밸런싱, 무중단 배포, 장애 대비가 필요한 분산 서비스 환경에서
어떤 기법이 있는가? Sticky Session, 세션 복제, 중앙저장소(Redis 등), JWT, Spring Session 등
선택 기준은? 시스템 구조, 서비스 성격, 세션 중요도, 확장성과 성능 요구에 따라

'WEB & WAS' 카테고리의 다른 글

서비스 지연 시 WAS, DB서버에서 확인, 조치 사항  (0) 2025.09.03
WEB & WAS 장애 및 조치방법(100)  (0) 2025.07.18
WEB에서 지연이 발생하면  (0) 2025.07.18
WEB & WAS 장애 및 해결방안  (0) 2025.07.18

✅ 1. 문제 시나리오 요약

  • 사용자는 웹사이트에 접속 시 지연 또는 타임아웃 발생
  • WAS에서 직접 호출(Telnet, curl 등)은 정상 응답
  • → 즉, 웹 서버 ↔ WAS 간 연결 문제가 핵심

✅ 2. 주요 원인과 분석 방법

🔹 (1) proxy_pass 설정 오류

  • 현상: Nginx가 WAS로 요청을 프록시하는 설정에서 오타, 경로 누락
  • 예시:이 설정에서 http://was-server/ 로 끝나지 않으면 리다이렉션이나 경로 해석 문제가 생길 수 있음
  • nginx
    복사편집
    location / { proxy_pass http://was-server; }
  • 조치: proxy_pass의 경로 정확히 지정
    잘못된 예:올바른 예:
  • nginx
    복사편집
    proxy_pass http://was-server/;
  • nginx
    복사편집
    proxy_pass http://was-server;

🔹 (2) keepalive 및 connection 설정 문제

  • 현상: 많은 사용자가 동시에 접속 시 연결 고갈, 연결 대기
  • 원인:
    • worker_connections, keepalive_timeout, keepalive_requests 값 부족
    • upstream keepalive 설정 누락
  • 조치:
  • nginx
    복사편집
    worker_processes auto; events { worker_connections 4096; } http { upstream backend { server 192.168.0.101:8080; keepalive 32; } server { location / { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://backend; } } }

🔹 (3) Nginx ↔ WAS 간 타임아웃 설정 미흡

  • 현상: WAS가 느린 쿼리나 GC 등으로 일시적 지연 시, Nginx가 너무 빨리 timeout 발생시킴
  • 관련 파라미터:
  • nginx
    복사편집
    proxy_connect_timeout 5s; proxy_send_timeout 10s; proxy_read_timeout 30s; send_timeout 10s;
  • 조치:
    • proxy_read_timeout 값을 WAS 평균 응답 시간보다 충분히 여유 있게 설정
    • WAS의 응답 지연이 자주 발생한다면, 애플리케이션 또는 DB 성능도 병행 분석

🔹 (4) DNS 지연 or 내부망 명칭 미해결

  • 현상: proxy_pass에 사용하는 WAS 주소가 내부 DNS에 의존할 경우, 일시적인 DNS 지연
  • 조치:
    • IP로 직접 지정해 테스트
    • /etc/hosts에 정적으로 등록하여 테스트
    • DNS 캐시 조정

🔹 (5) TLS/SSL 핸드쉐이크 지연 (HTTPS 사용 시)

  • 현상: HTTPS 설정 오류 또는 인증서 체인 미완성
  • 조치:
    • 인증서 전체 체인 포함 여부 확인 (fullchain.pem)
    • ssl_session_cache, ssl_buffer_size, ssl_protocols 등 최적화

✅ 3. 실무 대응 흐름 (트러블슈팅 순서)

단계조치내용
1단계 브라우저 → 웹서버 → WAS 흐름대로 각 단 계별 응답 속도 측정 (curl -w, time, 브라우저 F12)
2단계 웹 서버 로그(access.log, error.log)에서 지연 요청의 status, upstream_response_time, request_time 확인
3단계 nginx.conf, sites-enabled 등 설정 점검 (proxy_pass, keepalive, timeout)
4단계 웹서버와 WAS 간 네트워크 연결 검사 (ping, telnet, curl)
5단계 성능 모니터링 도구(예: Netdata, Grafana, ELK)에서 요청 처리 시간 및 병목 확인
6단계 WAS 로그 및 APM(예: Pinpoint, New Relic)에서 응답 지연 원인 분석
 

✅ 4. 예시 명령어로 진단하기

bash
복사편집
# Nginx에서 특정 요청의 응답 속도 분석 (access.log 분석) cat /var/log/nginx/access.log | grep '/api/v1/data' | awk '{print $(NF-1), $NF}' | sort | uniq -c
# WAS 직접 호출 테스트 curl -w "@curl-format.txt" -o /dev/null -s "http://192.168.0.101:8080/api/v1/data"
# curl-format.txt 예시 time_namelookup: %{time_namelookup}\n time_connect: %{time_connect}\n time_starttransfer: %{time_starttransfer}\n total_time: %{time_total}\n

✅ 결론 요약

구분내용
원인 proxy 설정 오류, keepalive 미사용, 타임아웃 설정, WAS 응답 지연
조치 설정 튜닝, 로그 기반 추적, curl 테스트, 네트워크 확인
예방 Nginx-WAS 구성 시 설정 Template 표준화, 모니터링 도입, APM 연결

'WEB & WAS' 카테고리의 다른 글

서비스 지연 시 WAS, DB서버에서 확인, 조치 사항  (0) 2025.09.03
WEB & WAS 장애 및 조치방법(100)  (0) 2025.07.18
세션 클러스터링  (0) 2025.07.18
WEB & WAS 장애 및 해결방안  (0) 2025.07.18

✅ 1. 웹 서버(Web Server) 오류 및 장애 현상

문제현상주요 원인해결 방안
404 Not Found URL 오타, 리소스 없음, 라우팅 미스 리소스 경로 확인, URL 재설정, 리버스 프록시 설정 확인 (예: Nginx location 설정)
403 Forbidden 권한 오류, 접근 제어 정책 위반 파일/디렉토리 퍼미션 확인, SELinux/AppArmor 설정 점검
500 Internal Server Error 애플리케이션 버그, PHP/Python 오류, 설정 파일 오류 웹서버 로그(Nginx: /var/log/nginx/error.log) 확인 후, 코드/설정 수정
504 Gateway Timeout 백엔드(WAS) 응답 지연/실패 WAS 상태 확인, WAS 응답시간 개선 (쿼리 튜닝 등), timeout 값 조정 (proxy_read_timeout)
서비스 간헐적 지연 트래픽 과다, Keepalive 설정 오류 웹서버 connection 설정 조정 (worker_connections, keepalive_timeout)
 

✅ 2. WAS(Web Application Server) 오류 및 장애 현상

문제현상주요 원인해결 방안
응답 없음(Hang) GC 과다, 스레드 풀 고갈, DB 커넥션 풀 고갈 GC 로그 확인, 스레드/커넥션 풀 조정, WAS 재기동
메모리 누수 애플리케이션에서 객체 미해제 Heap dump 분석, 의심 클래스 추적 및 수정
OutOfMemoryError JVM Heap 부족 JVM 옵션 튜닝 (-Xms, -Xmx), 캐시 전략 개선
High CPU 사용률 무한 루프, 동시성 이슈, GC jstack, top, jstat 등으로 스레드 분석
DB 응답 지연 쿼리 성능 이슈, 인덱스 미적용 슬로우 쿼리 로그 확인, 쿼리 튜닝
WAS 재시작 반복 (Crash Loop) 환경 변수 설정 오류, WAR/EAR 배포 실패 배포 프로세스 점검, 로그 분석(catalina.out, nohup.out)
 

✅ 3. Web-WAS 연동 지연/오류 사례

현상원인조치
WAS는 정상인데, 웹에서만 지연 프록시 타임아웃 설정 미스 (proxy_pass, keepalive) 웹서버 타임아웃 설정 확인 및 조정
프록시된 리소스 응답 실패 프록시 설정 오류 (upstream 주소 틀림) nginx.conf 또는 httpd.conf에서 proxy_pass, upstream 설정 검토
SSL 인증서 오류 인증서 만료, 체인 불완전 인증서 재발급 또는 체인 포함 재설정
세션 공유 안됨 (로드밸런싱 이슈) Sticky Session 미설정 ip_hash, route 기반 세션 유지 설정 적용
 

✅ 4. 운영 중 대응 우선순위

단계내용
1단계 모니터링 시스템(Zabbix, Prometheus, ELK 등)에서 알람 감지
2단계 웹/WAS 로그 확인 (시간 동기화가 중요)
3단계 재현 테스트 또는 헬스 체크로 영향 범위 확인
4단계 네트워크, DB, 인프라 자원 (CPU, 메모리, Disk I/O 등) 확인
5단계 롤백 또는 서비스 Graceful Restart (무중단 재기동 고려)
 

✅ 실무에서 반드시 준비해야 할 체크리스트

  • Nginx/Apache, WAS(Tomcat, JBoss 등)별 로그 위치 및 필터링 방법 숙지
  • JVM Heap/GC 튜닝, APM 도구(New Relic, Pinpoint) 사용법
  • 무중단 배포(Zero-downtime deploy) 전략 이해
  • 시스템 리소스 모니터링 도구(top, iostat, netstat, ss 등)
  • 오류 시 시나리오 기반 롤백 계획 및 트래픽 분산 기술 (로드밸런서, Blue-Green 배포)

'WEB & WAS' 카테고리의 다른 글

서비스 지연 시 WAS, DB서버에서 확인, 조치 사항  (0) 2025.09.03
WEB & WAS 장애 및 조치방법(100)  (0) 2025.07.18
세션 클러스터링  (0) 2025.07.18
WEB에서 지연이 발생하면  (0) 2025.07.18

노후 스토리지 교체 방안을 실제 IT 인프라 운영 환경에서 자주 쓰이는 방식 중심으로 구조화해서 정리해 드립니다.

✅ 1️⃣ 사전 복제 기반 이관 (Disk-to-Disk / Block-level Replication)

📌 개념

  • 새로운 스토리지에 사전에 기존 디스크의 블록 데이터를 복제.
  • 스냅샷, 미러링, 복제 소프트웨어(예: EMC SRDF, NetApp SnapMirror, Veritas Volume Replicator 등) 사용.

📌 특징

  • 실시간 또는 일정 간격으로 동기화 가능.
  • 서비스 무중단 또는 최소 다운타임 이관 가능.
  • 장애 복구 계획과 연계할 수 있음.

📌 주의점

  • 네트워크 대역폭 요구.
  • 복제 완료 후 Cutover 시점에 서비스 잠시 중단.

✅ 2️⃣ LVM Mirror 이용한 Online 이관

📌 개념

  • 기존 LV(Logical Volume)에 신규 스토리지를 미러로 추가.
  • 데이터가 동기화되면 기존 스토리지를 미러에서 제거.

📌 특징

  • 운영 중 이관 가능 (Online Migration).
  • Linux LVM, Veritas Volume Manager 등에서 지원.

📌 주의점

  • 디스크 I/O 증가 → 동기화 중 성능 저하 가능.
  • 미러링 해제 후, VG/PV 관리 주의.

✅ 3️⃣ rsync 기반 사전 파일 동기화

📌 개념

  • rsync나 robocopy 같은 파일 레벨 복제 도구 사용.
  • 서비스 운영 중에도 사전 동기화 수행.
  • 최종 Cutover 시 짧은 서비스 중단으로 Delta만 Sync.

📌 특징

  • 단순, 비용 적음.
  • 파일 시스템 기반 데이터에 적합.

📌 주의점

  • 파일락 문제, 오픈 파일은 복제 안 됨 → DB는 불안정.
  • DB 등은 별도 Dump나 Snapshot 필요.

✅ 4️⃣ 스냅샷 + Snapshot Export

📌 개념

  • 스토리지의 Snapshot 기능 사용.
  • 스냅샷 이미지를 새로운 스토리지로 복제(Mirror/SnapMirror 등).

📌 특징

  • 짧은 서비스 중단.
  • 데이터 일관성 보장 가능.

📌 주의점

  • Snapshot 기능 지원 스토리지 필요.
  • Snapshot을 너무 오래 유지하면 성능 저하.

✅ 5️⃣ Tape Backup & Restore

📌 개념

  • Tape Library 등 백업 장비로 전체 백업 → 신규 스토리지에 복구.

📌 특징

  • 저비용. 추가 솔루션 필요 없음.
  • 보관용 또는 Legacy 시스템에 유용.

📌 주의점

  • Offline 시간 길어짐.
  • 복구 속도 느림 → 대용량에는 비권장.

✅ 6️⃣ DB Native Dump & Restore

📌 개념

  • DBMS의 Export/Import, Logical Dump, RMAN 백업 등 활용.
  • 신규 스토리지에 DB 재구성.

📌 특징

  • DB 구조 최적화 기회.
  • 버전 업그레이드 병행 가능.

📌 주의점

  • Dump → Import는 시간이 오래 걸림.
  • 대규모 DB라면 블록 복제나 Snapshot이 더 현실적.

✅ 7️⃣ 클라우드 / SDS로 이관 (현대적 방법)

📌 개념

  • 노후 SAN/NAS 대신 클라우드 블록 스토리지(AWS EBS, Azure Disk)나 SDS(Ceph, vSAN 등)로 전환.

📌 특징

  • 물리 스토리지 유지보수 제거.
  • 탄력적 확장 가능.

📌 주의점

  • 네트워크 지연 발생 가능.
  • 데이터 마이그레이션 계획 철저히.

✅ 📌 요약

방법특징장점단점
Disk-to-Disk 복제 블록단 복제 빠름, 무중단 가능 비용, 네트워크 부하
LVM Mirror 미러 구성 후 Cutover 무중단, 구조적 성능 부하
rsync 파일 기반 복제 간편, 저비용 락 문제
Snapshot 스토리지 스냅샷 활용 정합성 보장 기능 필요
Tape Backup 백업 후 복구 저비용 Offline 길음
DB Dump DB 전용 업그레이드 병행 속도 느림
Cloud/SDS 현대적 방법 유지보수 용이 이전 비용/지연
 

필요하다면 "노후 스토리지 교체 마이그레이션 체크리스트" 형태로 별도 문서 만들어 드릴까요? 🚀📄

 

 

🧱 컨테이너 관리 초급 요약

✅ 1. 컨테이너란?

  • 애플리케이션을 작고, 독립된 단위로 묶는 기술.
  • 내부에 실행파일, 설정파일, 라이브러리까지 포함 → 어디서나 동일하게 실행 가능.
  • 대표 도구: Docker

👉 예: 앱을 설치하려면 이것저것 환경 맞추는 게 힘들지만, Docker는 “앱 통조림”처럼 필요한 걸 다 넣어서 실행하는 방식이야.

✅ 2. 왜 컨테이너 관리가 필요할까?

컨테이너가 많아지면 누가 언제, 어디서 실행되는지 관리하기 어려워짐
→ 그래서 자동으로 관리해주는 시스템이 필요해!

👉 이걸 도와주는 게 바로 컨테이너 오케스트레이션 도구(Kubernetes)

✅ 3. 컨테이너 관리에 필요한 주요 개념

항목설명
이미지(Image) 컨테이너를 만들기 위한 ‘설치 파일 묶음’
컨테이너(Container) 실행 중인 이미지
Pod Kubernetes에서 컨테이너를 담는 최소 단위
노드(Node) 컨테이너를 실행하는 컴퓨터
클러스터(Cluster) 여러 노드가 모인 관리 단위
레이블(Label) 컨테이너에 태그처럼 붙이는 정보 (선택/관리 용이)
 

✅ 4. 대표 도구들

기능도구
컨테이너 실행 Docker
대규모 운영 관리 Kubernetes
이미지 저장소 Docker Hub
로그 및 모니터링 Grafana, Prometheus
보안 검사 Trivy
 

✅ 5. 컨테이너 관리 흐름

plaintext
 

[개발자가 코드 작성]
     ↓
[Docker로 이미지 생성]
     ↓
[이미지를 Docker Hub에 저장]
     ↓
[Kubernetes가 이미지를 가져와 컨테이너 실행]
     ↓
[자동 확장, 복구, 상태 확인 등 관리]

✅ 6. 알아두면 좋은 기초 용어

  • YAML: Kubernetes 설정 파일 작성할 때 쓰는 형식
  • kubectl: 쿠버네티스를 제어하는 명령어 도구
  • Deployment: 컨테이너를 몇 개 실행할지 관리하는 설정

🔁 예시 시나리오 (입문형)

“쇼핑몰 서버를 Docker로 만들고 Kubernetes로 3개 실행되게 설정해요. 하나 죽으면 자동으로 다시 살아나요.”

"쇼핑몰 서버를 Docker로 만들고 Kubernetes로 3개 실행되게 하고, 하나가 죽으면 자동으로 복구되게 하는 실습"을 10% 수준으로 단계별 설명해줄게.
(기초부터 Kubernetes 자동 복구까지 포함)

✅ 목표

  • 쇼핑몰 웹서버를 Docker 컨테이너로 만들고
  • Kubernetes에서 3개 Pod로 실행
  • Pod 하나가 죽으면 자동으로 다시 생성됨

🧱 1단계: Dockerfile로 웹 서버 만들기

Dockerfile
 
 
# 📄 Dockerfile
FROM nginx:latest
COPY ./index.html /usr/share/nginx/html/index.html
 
html
 
 
<!-- 📄 index.html -->
<h1>내 쇼핑몰에 오신 걸 환영합니다!</h1>

✅ 빌드 & 테스트

bash
 
 
docker build -t myshop-web .
docker run -d -p 8080:80 myshop-web

🧱 2단계: Docker Hub에 이미지 올리기 (공개 허용 시)

bash
 
docker tag myshop-web YOUR_DOCKER_ID/myshop-web
docker push YOUR_DOCKER_ID/myshop-web
 

※ Docker Hub 계정이 필요해요.

🧱 3단계: Kubernetes에서 배포

📄 deployment.yaml

yaml
 
 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myshop-web
spec:
  replicas: 3  # 👉 Pod 3개 실행
  selector:
    matchLabels:
      app: myshop-web
  template:
    metadata:
      labels:
        app: myshop-web
    spec:
      containers:
      - name: myshop-web
        image: YOUR_DOCKER_ID/myshop-web  # 👉 본인 Docker Hub 이미지 주소
        ports:
        - containerPort: 80

✅ 배포 명령어

bash
 
 
kubectl apply -f deployment.yaml

✅ 상태 확인

bash
 
kubectl get pods

3개가 떠야 하고, 이름은 myshop-web-XXXX 형식일 거예요.

🧱 4단계: 하나 죽여보기 (자동 복구 테스트)

bash
 
 
kubectl delete pod <pod-name>
 
예시: kubectl delete pod myshop-web-7c58bcdf44-vqf5s

🔁 결과: Pod가 삭제되어도 Kubernetes가 자동으로 다시 생성함

🧱 5단계: 서비스로 외부 노출

📄 service.yaml

yaml
 
 
apiVersion: v1
kind: Service
metadata:
  name: myshop-service
spec:
  selector:
    app: myshop-web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort  # 👉 테스트용 외부 노출

✅ 적용

bash
 
 
kubectl apply -f service.yaml
kubectl get svc
 
EXTERNAL-IP:PORT 정보로 접속하면 브라우저에서 쇼핑몰 화면이 나올 거예요.

✅ 요약

기능구성
쇼핑몰 서버 Nginx + HTML
컨테이너 수 3개 (replicas 설정)
장애 복구 Kubernetes가 자동 재시작
외부 접속 NodePort Service 사용
 

실습 환경 없이 연습만 하고 싶다면 모의 문제나 구성도 설명으로도 도와줄게.
다음은 Helm으로 배포하는 방식도 알려줄까?

 

Service Mesh vs API Gateway 차이점
 

ChatGPT의 말:

Service Mesh와 API Gateway는 모두 마이크로서비스 환경에서 서비스 간 통신을 제어하지만, 목적, 위치, 기능 범위가 다릅니다. 아래에 핵심 차이를 표로 정리하고, 뒤에 사례 기반 비교를 덧붙입니다.

✅ [비교표] Service Mesh vs API Gateway

항목API GatewayService Mesh
📌 주요 목적 클라이언트 ↔ 서비스 간 진입점 제어 서비스 ↔ 서비스 간 통신 제어
🔍 위치 시스템 외부 ↔ 내부 경계 시스템 내부 (서비스 간)
🧩 구성 요소 단일 진입점 (ex: NGINX, Kong, Ambassador) Sidecar proxy + Control Plane (ex: Istio, Envoy)
🎯 기능 인증, 인가, 라우팅, 요청 변환, CORS 등 mTLS, 서비스 디스커버리, 트래픽 제어, 분산 추적
🔄 트래픽 흐름 외부 → 내부 내부 ↔ 내부
🔐 보안 적용 위치 외부 요청에 초점 내부 서비스 간 보안 (mTLS 등)
🛠 대표 도구 Kong, API Gateway, Ambassador, Gloo Istio, Linkerd, Consul, Kuma
 

✅ 사용 시나리오 기반 비교

🔹 예제 1: 모바일 앱에서 쇼핑몰 백엔드 접근

  • API Gateway가 다음을 수행:
    • JWT 인증
    • /products, /users 등 URI 라우팅
    • 외부 요청을 내부 서비스에 전달

🔹 예제 2: 주문 서비스 → 결제 서비스 호출

  • Service Mesh가 다음을 수행:
    • 서비스 디스커버리 (동적 IP 탐지)
    • mTLS 암호화
    • Circuit Breaker, Retry 적용
    • 요청 추적 및 관찰 (Trace ID 전달)

✅ 핵심 요약

역할 분담설명
API Gateway 마이크로서비스 입구를 제어한다. 외부 유저 → 시스템 진입 시 보안·정책 적용
Service Mesh 마이크로서비스 내부 통신을 제어한다. 서비스 간 안전하고 안정적인 연결 유지
 

필요하다면 Istio + Ambassador 조합 아키텍처 예시도 도식으로 제공할 수 있습니다. 그려볼까요?

'MSA Outer > Service Mesh' 카테고리의 다른 글

Service Mesh 개요와 문제  (0) 2025.08.30

+ Recent posts

티스토리툴바