-
질문 & 답변
카테고리
-
세부 분야
풀스택
-
해결 여부
미해결
Database retry 관련
24.04.23 10:52 작성 24.04.23 14:27 수정 조회수 47
0
- 본 강의 영상 학습 관련 문의에 대해 답변을 드립니다. (어떤 챕터 몇분 몇초를 꼭 기재부탁드립니다)
- 이외의 문의등은 평생강의이므로 양해를 부탁드립니다
- 현업과 병행하는 관계로 주말/휴가 제외 최대한 3일내로 답변을 드리려 노력하고 있습니다
- 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
안녕하세요~ 좋은 강의 잘 듣고 있습니다
세션 16. 도커 컴포즈 구축 추가 강의 보다가 질문드립니다.
docker compose는 컨테이너 혹은 컨테이너 내부 프로세스가 실행 가능한 상태가 되기 전 종속 컨테이너가 실행되어 실행 오류가 나는것을 방지하기 위해 health check 기능을 제공하는 것으로 알고 있습니다.
혹시 이 기능을 사용하지 않고 데이터베이스 retry 기능을 로직으로 구현해놓으신 이유가 있으실까요? (기능이 적합하지 않거나 하자가 있거나 등)
풀스택을 위한 도커와 최신 서버 기술(리눅스, nginx, AWS, HTTPS, flask 배포) [풀스택 Part3]
[참고] Reverse Proxy(nginx 기반) + FastAPI + MySQL 도커컴포즈 구축
강의실 바로가기
답변을 작성해보세요.
0
인프런 AI 인턴
2024.04.25
안녕하세요, 인프런 AI 인턴입니다.
질문하신 내용에 대해 답변드립니다.
Docker Compose에서 컨테이너의 readiness를 확인하기 위해 health check 기능을 제공합니다. 이는 compose.yml 파일의 서비스 정의 하위에 healthcheck 섹션을 추가함으로써 사용할 수 있습니다. 컨테이너가 완전히 준비된 상태가 되는 것을 확인하는 데 권장되는 방법입니다. 그러나 healthcheck 구성이 compose.yml에서 생략되는 경우가 흔하기 때문에, Spring Boot는 서비스 준비 상태를 직접 확인합니다. 기본적으로 TCP/IP 연결이 해당 매핑된 포트에 대해 설정될 수 있을 때 컨테이너를 준비된 것으로 간주합니다.
데이터베이스 retry 로직을 직접 구현하는 이유는 다음과 같을 수 있습니다:
보다 세밀한 제어 - 개발자는 health check보다 더 특정한 로직을 구현하여, 예를 들어 일정 시도 횟수 이후에 backoff 전략을 적용하거나 추가적인 로깅, 알림을 포함할 수 있습니다. 이는 서비스의 성격에 맞게 더 세밀하게 오류 처리 논리를 제어할 수 있게 합니다.
환경에 대한 의존성 감소 - Docker Compose의 health check 기능을 사용하는 경우 해당 기능이 환경에서 지원되어야 합니다. 반면, 애플리케이션 수준에서 직접 retry 로직을 구현함으로써, 배포 환경의 변화에 더 강한 유연성을 유지할 수 있습니다.
특정 상황에 대한 처리 - 특정 상황이나 예외에 대한 처리가 필요할 수 있으며, 직접 구현을 통해 이러한 케이스를 보다 쉽게 관리할 수 있습니다.
이러한 이유들은 서비스의 복잡성, 배포 환경, 오류 관리에 대한 선호 등에 따라 다르게 적용될 수 있습니다.
마지막으로, 이 정보 및 관련 정보는 Spring Boot 공식 문서에서 제공되고 있으니 참고하시면 도움이 될 것입니다.
상세 내용은 다음 원본 출처에서 확인하실 수 있습니다: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.docker-compose.readiness
답변 1