Java 주니어 배포·운영 기술면접
새 면접Q. Jenkins나 GitHub Actions 같은 CI/CD 도구를 사용하는 이유와, 수동 배포와 비교했을 때의 장점을 설명해주세요. 또한 CI(Continuous Integration)와 CD(Continuous Deployment)의 차이점도 함께 말씀해주세요.
개발자가 코드를 커밋한 후 프로덕션까지 배포되는 과정에서 자동화가 어떤 이점을 주는지 생각해보세요.
CI/CD 도구는 빌드, 테스트, 배포 과정을 자동화하여 사람의 실수를 줄이고 배포 속도를 높입니다. 수동 배포는 매번 동일한 작업을 반복해야 하고 환경 설정 차이로 인한 오류가 발생할 수 있지만, CI/CD는 일관된 환경에서 자동으로 실행됩니다. CI는 코드 변경사항을 자동으로 빌드하고 테스트하여 통합하는 과정이며, CD는 테스트를 통과한 코드를 자동으로 프로덕션 환경에 배포하는 과정입니다. CI/CD를 통해 개발자는 코드 품질을 유지하면서도 빠른 피드백을 받을 수 있습니다.
- • 빌드/테스트/배포 자동화
- • 수동 배포 대비 일관성과 속도 향상
- • CI는 통합 자동화, CD는 배포 자동화
코드 커밋 후 자동으로 빌드/테스트가 실행되고, 성공 시 개발 서버에 자동 배포되는 파이프라인을 구축할 때 사용합니다.
Jenkins Pipeline을 구성할 때 stage를 어떻게 나누시겠으며, 각 stage에서 실패하면 어떻게 처리해야 할까요?
Q. Docker를 사용하여 Java Spring Boot 애플리케이션을 컨테이너화할 때, Dockerfile을 어떻게 작성하시겠습니까? 베이스 이미지 선택, JAR 파일 복사, 포트 노출 등 주요 단계를 설명하고, 이미지 크기를 줄이기 위한 방법도 함께 말씀해주세요.
멀티 스테이지 빌드를 사용하면 빌드 도구는 최종 이미지에서 제외할 수 있습니다.
Dockerfile은 먼저 openjdk:11-jre-slim 같은 경량 JRE 베이스 이미지를 선택합니다. COPY 명령어로 빌드된 JAR 파일을 컨테이너 내부로 복사하고, EXPOSE 명령어로 애플리케이션이 사용할 포트를 명시합니다. CMD 또는 ENTRYPOINT로 java -jar app.jar 같은 실행 명령을 지정합니다. 이미지 크기를 줄이기 위해서는 멀티 스테이지 빌드를 사용하여 빌드 단계와 실행 단계를 분리하고, 빌드에 필요한 Maven이나 Gradle은 최종 이미지에 포함시키지 않습니다. 또한 alpine 기반 이미지를 사용하거나 불필요한 레이어를 최소화하는 것도 중요합니다.
- • 경량 베이스 이미지 선택
- • JAR 복사 및 포트 노출
- • 멀티 스테이지 빌드로 이미지 크기 최적화
로컬 환경과 프로덕션 환경의 차이를 없애고, 동일한 컨테이너 이미지를 여러 환경에 배포할 때 사용합니다.
Docker 이미지 레이어 캐싱을 활용하여 빌드 속도를 개선하려면 Dockerfile을 어떻게 작성해야 할까요?
Q. 운영 중인 Spring Boot 애플리케이션을 무중단으로 배포해야 합니다. Blue-Green 배포와 Rolling 배포 방식의 차이점을 설명하고, 각각의 장단점과 어떤 상황에 적합한지 말씀해주세요.
두 배포 방식 모두 서비스 중단 없이 배포하지만, 리소스 사용량과 롤백 속도에서 차이가 있습니다.
Blue-Green 배포는 기존 환경(Blue)과 동일한 새 환경(Green)을 구성한 후 트래픽을 한 번에 전환하는 방식입니다. 롤백이 즉시 가능하고 배포 검증이 쉽지만, 두 배의 리소스가 필요합니다. Rolling 배포는 여러 인스턴스를 순차적으로 교체하는 방식으로, 리소스 효율적이지만 배포 중 구버전과 신버전이 공존하며 롤백이 복잡합니다. Blue-Green은 중요한 서비스나 빠른 롤백이 필요한 경우에 적합하고, Rolling은 리소스가 제한적이거나 점진적 배포가 필요한 경우에 적합합니다. 실무에서는 로드밸런서나 Kubernetes 같은 오케스트레이션 도구를 활용하여 구현합니다.
- • Blue-Green은 환경 전환 방식, Rolling은 순차 교체 방식
- • Blue-Green은 빠른 롤백, Rolling은 리소스 효율
- • 서비스 중요도와 리소스 상황에 따라 선택
사용자가 서비스를 이용하는 중에도 새로운 기능을 배포하거나 버그를 수정해야 할 때 사용합니다.
Kubernetes에서 Rolling Update를 수행할 때 maxUnavailable과 maxSurge 파라미터의 역할은 무엇인가요?
Q. 프로덕션 환경에서 Spring Boot 애플리케이션의 상태를 모니터링하기 위해 어떤 지표들을 수집하고 관찰해야 하는지 설명해주세요. CPU, 메모리 외에 애플리케이션 레벨에서 확인해야 할 중요한 메트릭과 로그 관리 방법도 함께 말씀해주세요.
Spring Boot Actuator가 제공하는 health check와 metrics 엔드포인트를 활용할 수 있습니다.
기본적으로 CPU 사용률, 메모리 사용량, 디스크 I/O를 모니터링해야 하며, 애플리케이션 레벨에서는 응답 시간, 처리량(TPS), 에러율을 확인해야 합니다. Spring Boot Actuator를 활성화하여 /actuator/health로 헬스 체크를 하고, /actuator/metrics로 JVM 메모리, 스레드, HTTP 요청 통계 등을 수집할 수 있습니다. 데이터베이스 커넥션 풀 상태와 API 응답 시간도 중요한 지표입니다. 로그는 ELK 스택이나 CloudWatch 같은 중앙 집중식 로그 관리 시스템으로 수집하여 검색과 분석을 용이하게 하며, 에러 로그는 즉시 알림을 받을 수 있도록 설정합니다.
- • CPU/메모리 외에 응답시간, TPS, 에러율 모니터링
- • Spring Boot Actuator로 헬스체크와 메트릭 수집
- • 중앙 집중식 로그 관리 시스템 활용
서비스 장애를 사전에 감지하거나, 장애 발생 시 빠르게 원인을 파악하여 복구할 때 사용합니다.
애플리케이션 응답 시간이 갑자기 느려졌다는 알림을 받았을 때, 어떤 순서로 원인을 파악하시겠습니까?
Q. 새로운 버전을 배포한 후 심각한 버그가 발견되어 긴급하게 이전 버전으로 롤백해야 하는 상황입니다. 롤백을 안전하게 수행하기 위해 어떤 절차를 따라야 하며, 롤백이 어려운 상황을 방지하기 위해 배포 전에 준비해야 할 사항은 무엇인지 설명해주세요.
데이터베이스 스키마 변경이 포함된 배포는 롤백 시 특별한 주의가 필요합니다.
롤백 시에는 먼저 트래픽을 차단하거나 서비스를 점검 모드로 전환하고, 이전 버전의 컨테이너 이미지나 JAR 파일을 재배포합니다. 데이터베이스 마이그레이션이 있었다면 롤백 스크립트를 실행해야 하므로, 배포 전에 반드시 롤백 계획을 수립해야 합니다. 배포 전 준비사항으로는 이전 버전의 이미지를 보관하고, 데이터베이스 백업을 수행하며, 롤백 스크립트를 미리 작성해두는 것이 중요합니다. Blue-Green 배포를 사용하면 트래픽만 전환하여 즉시 롤백할 수 있어 안전합니다. 롤백 후에는 반드시 헬스체크와 주요 기능 테스트를 수행하여 정상 동작을 확인해야 합니다.
- • 트래픽 차단 후 이전 버전 재배포
- • 데이터베이스 변경 시 롤백 스크립트 필요
- • 배포 전 롤백 계획과 백업 준비
프로덕션 배포 후 치명적인 버그가 발견되어 사용자 피해를 최소화하기 위해 즉시 이전 버전으로 되돌려야 할 때 사용합니다.
데이터베이스 컬럼을 삭제하는 마이그레이션을 포함한 배포를 안전하게 하려면 어떤 전략을 사용해야 할까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!