이번 주에는 '인프라'를 구성에 많은 시간을 소요하느라
알고리즘을 많이 풀지 못하였습니다.
그래서 이번주는 인프라에 대해 많이 고민하였기에
그 부분에 대해 작성해보려 합니다.
최종 구성도
일단 이런 식으로 구성을 진행하였습니다.
아직 부족함이 많기에 불필요한 부분도 있을 수 있기에
더 좋은 방향이 있다면 조언 주시면 감사하겠습니다.
먼저 각각에 대한 개념 먼저 잡고 가겠습니다.
개념
🚀 1. Docker(도커)
✔ Docker란?
애플리케이션을 “컨테이너(container)”라는 격리된 환경에서 실행시키는 기술
쉽게 말하면:
- “내 컴퓨터에서는 되는데 서버에서는 안 돼요” 문제를 해결하는 기술.
- OS 환경에 상관없이 똑같이 실행됨 (Windows / Mac / Linux 모두 동일)
- 개발/테스트/배포 환경을 그대로 재현할 수 있음
예:
Java 17 + Spring Boot + Redis + MySQL
→ 이 모든 종속 환경을 “컨테이너 이미지”로 만들어 어디든 실행 가능하게 함.
✔ Docker에서 사용하는 핵심 요소
1) 이미지(Image)
실행에 필요한 코드 + 라이브러리 + 환경이 포함된 패키지
→ ‘실행 파일’ 느낌
→ ‘읽기 전용’ 이므로 스냅숏이라고도 함.
→ 특정 시점의 애플리케이션과 가상환경을 나타냄
2) 컨테이너(Container)
이미지를 실행한 상태
→ ‘프로그램이 실제로 돌아가는 환경
3) Dockerfile
이미지를 만드는 레시피(명세서)
예시:
FROM openjdk:17-jdk
ARG JAR_FILE=build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]
4) Docker Hub / ECR
이미지를 올려두는 저장소
Dokerfile -(Build)→ Image -(Create)→ Container
‘Dokerfile’은 도커 이미지를 빌드하는 방법을 정의하는 스크립트
‘Doker file’을 빌드해서 이미지를 생성
‘이미지’는 특정환경에 대한 정보가 변하지 않고 저장되는 정적인 형태의 파일
‘이미지’를 동적인 형태로 변경한 것이 ‘컨테이너’
즉, 컨테이너를 생성한다는 것은 다른 환경과 분리시킨 환경을 만든다는 말
✔ Docker 초기 세팅 방법
1) Docker Desktop 설치
(Mac, Windows)
2) Dockerfile 생성
Spring Boot 프로젝트 루트에 작성
3) 이미지 빌드
docker build -t myapp .
4) 컨테이너 실행
docker run -p 8080:8080 myapp
이러면 EC2 없이도
로컬에서 Docker 기반 배포 테스트가 가능함.
🚀 2. GitHub Actions (CI/CD)
✔ GitHub Actions란?
"GitHub에 push만 하면 자동으로 빌드·테스트·배포까지 해주는 CI/CD 서비스"
CI = 코드 자동 테스트
CD = 자동 배포
✔ 왜 필요한가?
- 매번 수동으로 EC2 접속해서 배포하면 번거롭고 실수가 생김
- 팀 개발 시 동일한 배포 프로세스를 유지할 수 있음
- 배포를 자동화해서 “사람의 실수”를 없앰
✔ GitHub Actions는 이렇게 동작해
- main/master 브랜치에 push
- GitHub Actions가 Spring Boot 빌드
- Docker 이미지 생성
- 이미지 ECR에 push
- EC2에 SSH 접속
- Docker pull + 재배포
이 과정을. github/workflows/deploy.yml에 설정해서 자동화함.
🚀 3. AWS S3
✔ S3란?
AWS에서 제공하는 “파일 저장소(Object Storage)”
이미지, 로그파일, 데이터 파일 등을 저장할 수 있는 공간.
Spring에서는 보통:
- 사용자 프로필 이미지 저장
- 게시글 이미지/동영상 업로드
- 로그 백업
- 배포용 정적 파일 저장(React 등)
✔ 왜 S3를 쓰는가?
- EC2 서버는 파일 저장하기 적합하지 않음
- S3는 무제한 저장 + 안정적 + 비용 저렴
- URL로 바로 접근 가능
✔ 초기 세팅
- S3 Bucket 생성
- CORS / Public Access 설정
- AWS IAM에서 권한 있는 사용자 생성
- Access Key & Secret Key 발급
- Spring Boot에서 S3 설정(YAML)
- 파일 업로드 코드 작성
🚀 4. AWS EC2
✔ EC2란?
AWS에서 제공하는 “클라우드 컴퓨터”
→ 서버 역할을 하는 가상 머신
너의 Spring Boot + Docker를 실행하는 실제 서버.
✔ 왜 EC2를 쓰는가?
- 배포 후 실제 유저가 접근할 수 있어야 함
- Docker 기반으로 Spring Boot를 띄울 수 있음
- Redis, MySQL도 Docker로 올릴 수 있음
✔ EC2 기본 구성
- Amazon Linux 2023 or Ubuntu 22.04
- Docker 설치
- Docker Compose(선택)
- 8080 포트 오픈
- SSH 접속(PUTTY/XShell/Mac Terminal)
🚀 5. AWS Route 53
✔ Route 53이란?
AWS의 DNS 서비스 (도메인을 관리하는 서비스)
즉,
ec2-3-16-123-11.ap-northeast-2.compute.amazonaws.com
처럼 긴 주소를
➝ api.myservice.com 같은 예쁜 도메인으로 바꿔주는 서비스.
✔ 왜 필요?
- 사용자가 쉽게 접근하도록
- 인증서(HTTPS)와 연동할 수 있음 (ACM + ALB)
✔ Route 53 사용 흐름
- 도메인 구매 (가비아/AWS)
- Route 53 Hosted Zone 생성
- A 레코드 → EC2 IP 연결
- HTTPS 사용 시 ALB/ACM과 연결
🚀 6. AWS ECR (Elastic Container Registry)
✔ ECR이란?
AWS에서 제공하는 Docker 이미지 저장소 (Docker Hub 대체)
너의 Spring Boot Docker 이미지를 저장해 둘 공간.
✔ 왜 ECR을 쓰는가?
- GitHub Actions에서 빌드한 이미지를 저장하기 위함
- EC2에서 pull 해서 실행 가능
- AWS 서비스끼리 연동이 좋음
✔ 사용 흐름
- AWS ECR 리포지토리 생성
- GitHub Actions에서 로그인
- Docker 이미지 push
- EC2에서 pull
- docker run or docker compose
🛠️ 트러블슈팅 & 기술 선정 이유 정리
1️⃣ MySQL 3306 포트 충돌로 Docker 실행 오류 발생
🔍 상황
docker-compose.yml에서 MySQL을 기본 포트인 3306:3306으로 매핑했는데,
로컬 PC에 이미 MySQL이 실행 중이어서 포트 충돌 오류가 발생했다.
✔️ 해결 방법
두 가지 방식으로 문제를 해결할 수 있다.
① Docker 포트 변경
② 로컬 MySQL 서비스 중지
윈도 Win + R → services.msc → MySQL80 → 서비스 중지
👉 개발 환경에서는 포트 변경이 가장 간단하고 안전한 방법이었다.
2️⃣ 왜 Docker Hub 대신 AWS ECR을 선택했는가?
🏁 결론
“AWS 환경에서 배포한다면 Docker Hub는 ECR을 절대 이길 수 없다.”
보안·속도·안정성·연동성을 고려했을 때, 현업에서도 ECR을 표준처럼 사용한다.
🔐 1) 보안성 압도적
- 기본 Private Repository
- IAM으로 접근 제어
- VPC 엔드포인트로 외부 네트워크 차단 가능
- 팀 단위 정책 관리 용이
→ 기업 환경에서 가장 중요하게 보는 요소
🔗 2) AWS 서비스들과 완전한 통합
ECR은 AWS 내부 서비스들과 바로 연동된다.
- EC2 → 자동 인증 후 Pull
- ECS/EKS → 기본 컨테이너 레지스트리
- Lambda 컨테이너 이미지 → ECR만 연동
- GitHub Actions → ECR 로그인 & Push 자동화 쉬움
🚫 반면 Docker Hub는 익명 기준 6시간 100 Pull 제한이 있어
배포 시 장애 발생 가능.
⚡ 3) 훨씬 빠른 이미지 Push/Pull 속도
- AWS 내부 네트워크 전송이라 지연 최소
- 배포 속도 빠르고 안정적
- 요금도 내부 네트워크 기준으로 절약됨
Docker Hub는 외부 네트워크라 느리고 불안정할 수 있음.
💰 4) 비용 예측이 쉽고 안정적
Docker Hub는
- Private repo 제한
- Pull rate 제한
- 팀 요금 증가
문제가 존재한다.
ECR은
- GB 단위 저장 비용만 발생
- 요청량 무제한
- repo 무제한 생성 가능
→ 기업 규모에서 특히 ECR이 훨씬 유리
🔍 5) 취약점 자동 스캔 제공
이미지 Push 시 자동으로 보안 진단 실행
→ Docker Hub는 엔터프라이즈 요금제에서만 제공되는 기능
🧹 6) Lifecycle Policy로 비용 절감
- 오래된 태그 자동 삭제
- 최근 N개 태그만 유지
→ 저장 공간 최적화 가능
Docker Hub에는 제공되지 않는 기능.
3️⃣ 왜 Route53 대신 CloudFlare를 선택했는가?
🏁 결론
CloudFlare는 무료로도 강력한 기능을 제공하며,
개인 프로젝트나 중소 규모 서비스에서는 사실상 “가성비 끝판왕”이다.
☁️ 1) 무료 플랜 수준이 매우 강력함
- DNS 관리 무료
- CDN 무료
- DDoS 보호 기본 제공
- SSL 인증서 자동 적용
- 캐싱 및 최적화 무료
Route53은 모든 기능이 유료 과금이라 비용 부담이 있다.
⚡ 2) 전 세계 CDN으로 응답 속도 향상
CloudFlare는 글로벌 에지 서버를 사용하여
정적 리소스 전달 속도를 크게 높일 수 있다.
Route53은 DNS 서비스가 핵심이라 CDN 기능이 없음.
🔐 3) SSL/TLS 자동 구성
HTTPS를 별도 설정 없이 바로 적용할 수 있어
초기 세팅이 훨씬 빠르고 편리하다.
🛠️ 4) 개발자 친화적인 설정 환경
- DNS 관리 UI 매우 직관적
- 변경 전파 속도 빠름
- CloudFlare Rules / Workers 확장성 좋음
개발자 입장에서 라우팅·보안·속도 개선을 한 번에 해결할 수 있었다.
인프라 구성은 정말 알면 빠르게 구성할 수 있지만
모르면 하나부터 열까지 헤매면서 하는 그런 작업인 것 같다.
기술은 너무 많고 각자 장점과 단점이 명확하다.
어떠한 프로젝트인지에 따라 써야 할 기술들도 다르기에
알야 할 것이 참 많다..
알면 알수록 할게 많아지는 그런 느낌..
그렇지만 이번에 인프라를 구성하면서
나름 어떻게 웹서비스가 돌아가는지에 대해
깊게 이해한 것 같다.
웃고 있는 게 사악하다.
