주니어 백엔드 개발자가 반드시 알아야 할 지식 - 4장

• 💡해당 게시글은 최범균님의 ‘주니어 백엔드 개발자가 반드시 알아야 할 지식’을 개인 공부목적으로 메모함

4장에서 다루는 내용

• 외부 연동 문제
• 타임아웃과 재시도
• 동시 요청 제한과 서킷 브레이커
• DB와 외부 연동
• HTTP 커넥션 풀
• 이중화

외부 연동과 장애 전파

외부 연동의 중요성

• 현대 마이크로서비스 환경에서 외부 시스템 연동은 서버 개발의 필수 요소임
• 내부 서비스 간 호출 및 서드파티 API 연동이 복잡해지면서 장애 발생 가능성이 증가함
• 외부 연동 품질에 주의를 기울이지 않을 경우 전체 서비스 가용성에 지대한 영향을 끼침

장애 전파 메커니즘

• 연동된 메타데이터 API 서비스가 느려지면 이를 호출하는 스트리밍 서비스의 스레드 점유 시간이 길어짐
• 톰캣(Tomcat) 스레드 풀(기본 200개)이 급격히 고갈되어 서비스 자체가 마비됨
• 한 지점의 장애가 도미노처럼 번지는 현상을 방어해야 함

타임아웃과 재시도

타임아웃

• 연결 타임아웃 (Connection Timeout)

  • 서버와 네트워크 연결을 맺는 시점에 적용되는 대기 시간
  • 3~5초 범위 설정이 권장되며 초과 시 즉시 에러를 발생시킴

  

• 읽기 타임아웃 (Read Timeout)

  • 연결 성공 후 응답을 기다리는 대기 시간

  • 서비스 특성에 따라 5~30초 정도로 설정하며 유연하게 운용할 수 있음

    

재시도(Retry) 가능 조건과 주의사항

• 재시도 가능 조건
  • 내역 조회 같은 단순 조회 기능
  • 연결 타임아웃 발생 상황
  • 멱등성(Idempotent)을 가진 변경 기능
• 재시도 안티패턴
  • 연동 서버 부하 시 무차별적인 재시도는 장애를 심화 시킴
  • 재시도 간격을 두고 점진적으로 늘려 서버 부하를 분산해야 함
  • 잘못된 파라미터 전달 같은 검증 실패 케이스는 재시도 대상에서 제외해야 함

동시 요청 제한과 서킷 브레이커

동시 요청 제한

• 외부 서비스의 성능 한계를 고려하여 동시에 보낼 수 있는 요청 수를 제한해야 함
• 특정 메타데이터 조회 지연이 전체 스트리밍 시스템의 자원 고갈로 이어지는 것을 방지해야 함
• 요청 한도 초과 시 503 Service Unavailable 응답 등을 통해 빠른 실패를 유도해야 함

서킷 브레이커

• 전기 회로 차단기처럼 장애 상황 감지 시 요청을 즉시 차단하는 패턴임
• 상태 변화
  • 닫힘(Closed)
    • 모든 요청 정상 전달
  • 열림(Open)
    • 장애 임계치 도달 시 요청 차단
    • 요청 차단 시 즉시 에러 응답을 반환함
  • 반열림(Half-Open)
    • 일정 시간 경과 후 일부 요청만 보내 상태 확인
    • 확인 결과에 따라 닫힘 또는 열림 상태로 전환함
• 무의미한 대기 시간을 줄여 가용 리소스를 확보하는 주요 기법임

DB와 외부 연동

외부 연동 지연과 DB 커넥션 점유 문제

• DB 트랜잭션 범위 내에서 외부 연동을 수행할 때 발생하는 리소스 고갈 현상임

• 이슈 예시

  • DB 커넥션 확보 후 예약 데이터를 저장하는 첫 번째 쿼리 실행
  • 이후 외부 채널 매니저 API와 연동하며 긴 응답 대기 발생
  • 응답 성공 후 예약 상태를 업데이트하는 두 번째 쿼리 실행 및 트랜잭션 완료

  • 실제 DB 작업 시간보다 외부 연동 대기 시간 동안 커넥션 점유가 지속됨

    

• 트래픽이 몰리는 상황에서 외부 연동 지연은 전체 시스템 마비의 결정적 원인이 됨

해결 전략 1 - DB 커넥션 획득 전 외부 호출

• DB 커넥션을 점유하기 전에 외부 API 연동을 먼저 수행한 뒤 결과를 가지고 트랜잭션을 시작하는 방식임
• 장점
  • 외부 연동 지연 시간이 길어져도 DB 커넥션 풀 고갈을 원천적으로 방지하여 시스템 가용성을 높임
• 주의사항
  • 외부 연동 호출은 성공했으나 이후 DB 트랜잭션 도중 예외가 발생할 경우 이미 실행된 외부 작업을 수동으로 취소해야 함

해결 전략 2 - DB 커넥션 반납 후 외부 호출

• DB 트랜잭션을 모두 완료하고 커넥션을 반납한 뒤에 마지막 단계에서 외부 API를 호출하는 방식임
• 장점
  • DB 작업의 성공 여부를 확정 지은 후 외부 연동을 진행하므로 불필요한 연동 호출을 줄일 수 있음
• 주의사항
  • 외부 연동 실패 시 이미 커밋된 DB 데이터를 되돌리는 로직이 트랜잭션으로 묶이지 않아 보상 트랜잭션 구현이 필수적임

해결 전략 3 - 데이터 일관성 확보를 위한 후처리

• 보상 트랜잭션
  • 연동 실패 시 DB 데이터를 이전 상태로 되돌리는 전용 API(예 예약 취소 API)를 수동으로 호출함
• 데이터 보정 배치
  • 연동 과정의 누락이나 오류를 대비하여 일정 주기마다 양쪽 시스템의 데이터를 대조하고 일치시키는 프로세스를 구축해야 함
• 상태 관리
  • 외부 연동 성공 여부를 조회하는 전용 API를 활용하여 예약 상태의 최종 정합성을 주기적으로 확인해야 함

HTTP 커넥션 풀 최적화

• HTTP 연결 역시 생성 비용이 크므로 미리 풀(Pool)을 만들어 재사용함

  

• 설정 시 고려 요소

  • 풀 크기
    • 연동 서비스의 처리 능력과 트래픽 양을 고려하여 결정함
  • 대기 시간 한계
    • 커넥션을 확보할 때까지 대기하는 최대 시간 설정임
    • 보통 1~5초 사이의 짧은 시간 설정을 권장함
    • 너무 짧으면(0.1초) 일시적 트래픽 증가에도 에러가 발생하며 너무 길면(10초) 전체 응답 시간이 지연됨
  • Keep-Alive
    • 연결을 유지할 시간을 적절히 설정하여 연결 효율을 높임
    • 서버의 유효 시간보다 짧게 설정하여 끊긴 연결 사용을 방지해야 함

서비스 이중화와 가용성

장애 대응을 위한 이중화

• 외부 인증이나 본인 확인 등 중요 기능은 서비스 이중화를 통해 장애 발생 시 대체 경로를 확보할 수 있음
• 한 곳의 연동 시스템이 마비되어도 다른 채널을 통해 서비스 지속 가능성을 높일 수 있음

이중화 결정 기준

• 해당 기능이 서비스 중단 시 큰 손실을 초래하는 중요 기능인지 판단해야 함
• 이중화 구축 및 유지 비용이 장애 시 손실 비용보다 합리적인지 검토해야 함

배운 점

• 외부 연동은 전체 시스템 장애의 발단이 될 수 있음을 인지함
• 톰캣 스레드 풀 고갈과 장애 전파 메커니즘을 이해함
• 연결 타임아웃과 읽기 타임아웃의 차이와 적절한 설정 범위를 배움
• 멱등성과 재시도 폭풍 방지의 중요성을 파악함
• 벌크헤드 패턴과 서킷 브레이커를 통한 리소스 보호 기법을 익힘
• DB 트랜잭션 내 외부 호출이 커넥션 풀에 미치는 치명적 영향을 이해함
• 커넥션 획득 전후 외부 호출 배치 전략의 중요성을 배움
• HTTP 커넥션 풀 설정 요소와 최적화 방안을 파악함
• 서비스 이중화를 통한 가용성 확보 전략을 배움

적용 방안

• 연동 타임아웃 설정 전수 점검 및 최적화
  • 연결 타임아웃 3~5초 범위 설정
  • 읽기 타임아웃 5~30초 가이드 준수
• 재시도 로직 멱등성 검토 및 백오프 적용
  • 단순 조회 및 연결 실패 케이스 위주 재시도 적용
  • 지수 백오프 등을 활용한 재시도 Storm 방지
• 중요 외부 연동 지점에 서킷 브레이커 도입
  • 장애 임계치 모니터링 및 상태 전이 자동화
  • 빠른 실패 응답을 통한 시스템 자원 보호
• 트랜잭션 범위 내 외부 호출 제거 및 위치 조정
  • DB 커넥션 점유 전후로 외부 API 호출 이동
  • 연동 실패 시 보상 트랜잭션 및 데이터 후보정 배치 구축
• HTTP 커넥션 풀 최적화 및 모니터링
  • 연동 서비스 성능 고려한 풀 크기 설정
  • 서버 Keep-Alive 시간 고려한 유효 시간 설정
• 중요 서비스 이중화 검토
  • 외부 인증과 본인 확인 등 필수 기능 대체 경로 확보
  • 비용 대비 장애 리스크 평가를 통한 우선순위 산정

Reference

• 주니어 백엔드 개발자가 반드시 알아야 할 지식 - 한빛미디어