1~3편에서 “CI 빌드(Gradle)”와 “Docker 이미지 빌드/푸시(DockerHub)”까지 끝냈다.4편은 그 다음 단계인 배포(Deploy), 즉 EC2에서 최신 이미지를 pull 받고 컨테이너를 교체 실행하는 과정을 다룬다.이번 편의 핵심은 3가지다.SSH 없이 GitHub Actions에서 SSM으로 EC2에 명령을 내려 배포하기application.yml을 시크릿으로 만들어 Docker 이미지에 넣는 방식이 왜 위험한지deploy job 전체 구조 (build 성공 후, main 또는 수동 실행에서만 배포)워크플로우에서 deploy job은 이렇게 구성되어 있다.deploy: name: Deploy to EC2 with SSM needs: build # build 작업이 성공해야 실행..
1~2편에서 CI/CD 큰그림과 CI 빌드(JDK/Gradle/Wrapper/캐시)를 정리했다.이번 3편은 그 다음 단계인 “Docker 이미지를 어떻게 만들고(Docker build), 어떤 태그를 붙이고(metadata), 어떻게 올리는지(push)”를 다룬다.이 글에서 다루는 범위는 다음이다.Login to Docker HubDocker metadata (latest + sha 태그 전략)Build and push Docker image (buildx + gha cache-from/cache-to)Dockerfile이 의미하는 것Gradle 캐시 vs Docker 빌드 캐시 차이4편에서는 SSM 배포(EC2에서 deploy.sh 실행), 시크릿 주입(.env), application.yml 시크릿 ..
이 글은 1편에서 잡은 큰그림 중, GitHub Actions의 build job을 “Runner 내부에서 실제로 어떤 일이 벌어지는지” 기준으로 풀어낸다.이번 2편에서 다루는 범위는 아래와 같다.Set up JDK 17Gradle Caching (actions/cache)Grant execute permission for gradlewBuild with Gradle (./gradlew build -x test)(트러블 슈팅) Gradle Wrapper가 왜 필요한지 (gradle-wrapper.jar / gradle-wrapper.properties)(트러블 슈팅) 로컬에서 wrapper 생성하다 터진 오류 + 해결(SDKMAN, zip/unzip, 전역 gradle 버전 문제, JDK toolchai..
CI/CD를 깊게 다룬 계기과거 프로젝트에서는 CI/CD가 너무 어렵게 느껴져서, 제대로 이해하지 못한 채 GPT가 제공한 워크플로우를 그대로 복사·붙여넣기 하며 구축했다. 하지만 이번 프로젝트에서 다시 CI/CD를 설정하려고 하니, 머릿속에 남아 있는 게 거의 없었고 여전히 어렵게 느껴졌다. “또 그냥 복사해서 붙이면 되겠지”라고 넘어가면 결국 같은 상황이 반복될 것 같았다. 그래서 이번에는 CI/CD를 한 번 제대로 해부해보기로 했다. 왜 이런 스텝이 필요한지, 각 설정이 어떤 흐름으로 이어지는지, 실제로 어떤 문제가 생길 수 있는지까지 깊게 분석했다. 그리고 그 과정을 기술 블로그로 정리해두면, 다음에 CI/CD를 다시 구축해야 할 때 이 글을 기반으로 빠르게 복기하면서 더 단단하게 이해할 수 있다..
직접 테이블을 만들고 데이터를 넣어본 다음, mysql.innodb_index_stats 같은 통계를 보면서 “B+Tree가 대충 어떤 모양일까?”를 감으로 잡아본 실험 기록입니다.틀린 부분이나 더 좋은 해석이 있으면 편하게 알려주세요!실험 목표employee 테이블에 500만 건을 넣고,PRIMARY(클러스터 인덱스)와 Secondary 인덱스(department_id)의리프 페이지 수(n_leaf_pages)전체 페이지 수(size)prefix distinct 통계(n_diff_pfxXX)를 비교해서,“왜 PRIMARY는 리프가 많고, Secondary는 리프가 적을까?”를 숫자로 확인해보기1) 테이블 만들기-- 부서 테이블CREATE TABLE department ( department_id IN..
[전제 조건 및 설계 원칙]환경 전제웹 브라우저 기준으로 설명한다.모바일 앱이라면 authorize() 호출 시 카카오톡 앱이 먼저 실행되고,그 안의 WebView에서 kauth.kakao.com 페이지를 띄워 로그인/동의가 진행된다.로그인 시작 방식로그인 버튼 클릭 시, 프론트에서 백엔드를 거치지 않고 바로Kakao.Auth.authorize() 를 호출한다.이 호출은 브라우저를 https://kauth.kakao.com/oauth/authorize 로 이동시킨다.→ 프론트 → (백엔드 패스) → Kakao Auth Server인가 코드 수신 주체redirect_uri 를 프론트 주소로 설정한다.동의 완료 후, Kakao Auth Server는302 Location: {redirect_uri}?code..
1. 시스템 목표"하루에 한 번"과 같이 정해진 알림을 누락 없이 전송한다. (At-least-once Delivery)API 서버 장애, DB 장애, 애플리케이션 장애 등 어떤 상황에서도 작업 유실을 방지한다.장애 복구 시 발생할 수 있는 중복 발송을 최소화하고, 제어(멱등성)할 수 있도록 설계한다.2. 아키텍처 설계[1단계: 생산자 (Scheduler) 영역]별도의 스케줄러 스레드가 알림 발송 시간 10분 전에 User 테이블에서 알람 설정 한 유저 정보를 조회한다.유저 정보를 조회한 스케줄러는 오늘 알림 설정을 on 한 사용자들에 대해서만 quiz_notification_log 테이블을 생성하고 저장한다. (초기 status='PENDING')발송 시간이 되면 메인 스케줄러 스레드는 quiz_not..
0. 들어가며 – “퀴즈 보기, 어디까지 쪼갤 건데?”내 서비스의 하루 학습 경험은 이렇게 생겼다.“키워드 설명을 읽고, 관련 뉴스를 보고, 마지막에 퀴즈 1문제를 푼다.그 퀴즈에는 여러 개의 보기(option) 가 달려 있다.”여기서 자연스럽게 나오는 질문이 있다.“이 보기(option) 를 DB에서 어디까지 테이블로 쪼갤까?”선택지는 크게 둘이었다.quiz_options 라는 테이블을 만들고,quiz_id 기준으로 1:N 로우를 두는 방식보기 전체를 하나의 값 객체(QuizOptions)로 보고,JSON 컬럼에 통째로 박아 넣는 방식나는 2번, 즉QuizOptions 값 객체내부에 ListJPA에서는 AttributeConverter + JSON TEXT 컬럼이 조합을 선택했다.이 글에서는왜 별도 테..
