-
질문 & 답변
카테고리
-
세부 분야
풀스택
-
해결 여부
미해결
Database retry 관련
24.04.23 10:52 작성 24.04.23 14:27 수정 조회수 96
0
- 본 강의 영상 학습 관련 문의에 대해 답변을 드립니다. (어떤 챕터 몇분 몇초를 꼭 기재부탁드립니다)
- 이외의 문의등은 평생강의이므로 양해를 부탁드립니다
- 현업과 병행하는 관계로 주말/휴가 제외 최대한 3일내로 답변을 드리려 노력하고 있습니다
- 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
안녕하세요~ 좋은 강의 잘 듣고 있습니다
세션 16. 도커 컴포즈 구축 추가 강의 보다가 질문드립니다.
docker compose는 컨테이너 혹은 컨테이너 내부 프로세스가 실행 가능한 상태가 되기 전 종속 컨테이너가 실행되어 실행 오류가 나는것을 방지하기 위해 health check 기능을 제공하는 것으로 알고 있습니다.
혹시 이 기능을 사용하지 않고 데이터베이스 retry 기능을 로직으로 구현해놓으신 이유가 있으실까요? (기능이 적합하지 않거나 하자가 있거나 등)
풀스택을 위한 도커와 최신 서버 기술(리눅스, nginx, AWS, HTTPS, flask 배포) [풀스택 Part3]
[참고] Reverse Proxy(nginx 기반) + FastAPI + MySQL 도커컴포즈 구축
강의실 바로가기
답변을 작성해보세요.
0
잔재미코딩 DaveLee
지식공유자2024.05.26
안녕하세요. 답변 도우미입니다.
강의를 잘 듣고 계신다니 기쁩니다! 세션 16에 대한 질문에 대해 상세히 답변 드리겠습니다.
docker-compose에서 health check 기능을 통해 컨테이너의 상태를 확인하고 종속 컨테이너의 실행을 제어할 수 있습니다. 이 기능은 컨테이너가 실행 가능한 상태인지 확인하기 위해 매우 유용합니다. 그러나 특정 상황에서는 health check 기능 대신 애플리케이션 로직에서 데이터베이스 retry 기능을 구현하는 것이 더 적합할 수 있습니다.
가볍게 이야기드리면, 도커 자체는 동작 상태 체크가 가능하나, 도커 내의 특정 프로그램이 실제 연결상태가 되었느냐는 체크가 어렵습니다. 이 부분 때문에 retry 기능으로 데이터베이스가 연결가능한 상태가 될때까지 연결시도를 한 것입니다. 이 부분에 대해서 영상에서도 설명드려서, 함께 이해보시면 도움이 되실 것 같습니다. 그 외에 참고할만한 추가적인 이유는 다음과 같습니다:
1. 애플리케이션의 유연성:
- 데이터베이스 연결 시도와 같은 중요한 로직을 애플리케이션 내에서 처리하면, 데이터베이스 연결이 실패할 경우 재시도 로직을 더욱 세밀하게 제어할 수 있습니다. 예를 들어, 재시도 횟수나 재시도 간격을 애플리케이션 요구사항에 맞게 조정할 수 있습니다.
2. 플랫폼 독립성:
- health check는 Docker 환경에 종속적입니다. 하지만 애플리케이션 내에 재시도 로직을 구현하면, Docker를 사용하지 않는 환경에서도 동일한 로직을 사용할 수 있어 플랫폼에 독립적인 코드가 됩니다.
3. 애플리케이션 상태에 대한 세밀한 제어:
- health check는 주로 컨테이너의 외부 상태를 확인합니다. 하지만 애플리케이션 내부에서 재시도 로직을 구현하면 데이터베이스 연결 외에도 다양한 내부 상태를 확인하고 처리할 수 있습니다.
4. 디버깅 및 로깅:
- 애플리케이션 내에서 재시도 로직을 구현하면, 연결 실패 시 원인 분석을 위한 로그를 남길 수 있습니다. 이는 문제 해결에 큰 도움이 됩니다.
결론적으로, Docker의 health check 기능은 컨테이너 상태 확인에 유용하지만, 데이터베이스 연결과 같은 중요한 로직은 애플리케이션 내에서 제어하는 것이 더 유연하고 효과적인 경우가 많습니다. 이러한 이유로 데이터베이스 retry 기능을 애플리케이션 로직으로 구현하는 것이 일반적입니다.
감사합니다.
잔재미코딩 드림
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
답변 2