일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- CoffiesVol.02
- LV03
- SQL
- Join
- mysql
- LV02
- Lv.0
- S3
- Java
- Til
- 프로그래머스
- GIT
- spring boot
- 이것이 자바다
- JPA
- LV1
- Redis
- 연습문제
- 일정관리프로젝트
- LV.02
- 코테
- LV01
- CI/CD
- 알고리즘
- 데이터 베이스
- docker
- LV0
- 포트폴리오
- 일정관리 프로젝트
- 디자인 패턴
- Today
- Total
목록포폴 (40)
코드 저장소.

목차1.도입 배경2.문제 분석3.캐시 적용4.느낀점 1.도입 배경CI/CD 파이프라인을 GitHub Actions로 구성한 이후, 커밋이나 PR마다 평균 2~3분의 빌드 시간이 소요되는 문제가 있었습니다.현재 프로젝트는 멀티모듈 Gradle 기반으로 구성되어 있으며, 외부 의존성도 많아 빌드 성능의 손실이 반복되고 있었습니다.단순한 변경 사항이나 테스트 커밋임에도 매번 전체 빌드를 새로 수행해야 했고, 이로 인해 개발 흐름이 끊기거나 PR 리뷰 속도가 느려지는 병목이 발생했습니다.운영 환경 배포를 자동화하기 위해 CI를 구성했지만, 오히려 개발 속도를 방해하는 상황이 생긴 것입니다.2.문제 분석GitHub Actions는 매 빌드마다 새로운 VM 환경에서 실행되기 때문에, 기존에 다운로드된 의존성 파일(..

목차1.기존 구조의 문제점2.문제 분석3.문제 해결4.후기 1.기존 구조의 문제점일정 관리 프로젝트를 라이트세일의 2GB서버에 띄우고 모니터링을 구축을 하기 위해서 도커 컴포즈를 사용해서 띄운 것은 아래와 같습니다.Spring BootNginxRedisKafkaZooKeeperGrafanaPromtailPrometheusLokiKafka Exporter/ Redis Exporter그리고 사진과 같이 모든 서비스를 하나의 서버에 동시에 띄우니 1.53GB까지 올라가더니 모니터링을 켜면 메모리 과부하로 인해서 서버가 다운이 되는 현상이 발생을 했습니다. 2.문제 분석우선은 이러한 문제점에 대한 원인은 아래와 같습니다.모니터링 스택이 가벼운 줄 알았으나, Loki,Grafana,Prometheus 자체가 상당..

목차1.도입: 왜 도입을 했는가?2.아키텍처 개요3.Prometheus로 메트릭 수집4.Loki + Promtail로그 수집5. Grafana로 통합 대시보드 구성6.느낀점 1.도입: 왜 도입을 했는가?일정관리 프로젝트 개발 초기에는 Spring Boot의 MDC(Mapped Diagnostic Context)를 활용해서 requestId, username 등의 식별자를 로그에 포함시키고, 콘솔(logback)을 통해 디버깅을 진행했다.MDC.put("requestId", UUID.randomUUID().toString());MDC.put("username", authentication.getName()); { "timestamp": "%d{yyyy-MM-dd'T'HH:mm:ss.SSSZ}", ..
목차1. 왜 통합 테스트가 필요했는가?2. Testcontainers 기반 인프라3. 테스트4. 회고 1. 왜 통합 테스트가 필요했는가?이번 일정 관리 프로젝트는 기획 단계부터 Kafka, Redis, RDS(MySQL) 등 다양한 외부 시스템과의 연동을 기반으로 설계되었습니다. 특히 Kafka를 통한 이벤트 기반 구조, Redis를 활용한 캐시 및 분산 락 처리, RDS와의 스케줄러 기반 트랜잭션 흐름 등은 단순한 로직 검증을 넘어서, 실제 환경과 유사한 상황에서 전체 동작 흐름을 검증할 필요가 있었습니다. 처음부터 mock/stub 기반 단위 테스트 대신, "외부 시스템을 포함한 통합적인 테스트 환경을 어떻게 구성할 것인가?"가 주요 고민이었습니다. 실제 테스트 중 직면했던 이슈는 다음과 같습니다:K..

목차1. 도입 / 배경2.MobaXterm을 활용한 배포 자동화 & 운영3.후기 1. 도입 / 배경지난글에서는 배포를 할 기본적인 인프라를 세팅을 했고 이번에는 GithubAction을 활용해서 CI/CD를 구축을 하기로 했습니다. CI/CD를 적용을 하게 된 이유는 아래와 같습니다.수동으로 서버를 올리면서 배포를 하면 작업을 하는데 있어서 시간소모가 크다.작업을 하면서 운영을 하기 위해서는 빌드,테스트,배포를 자동화하는 것이 필요.위와 같은 이유로 GithubAction을 사용해서 CI/CD를 구축을 하고자 합니다. 그래서 이번글의 목표는 아래와 같습니다.main 브랜치에 코드가 머지되면 자동으로 빌드/테스트/배포가 이루어지게 만드는 것운영 서버에서는 실제 서비스가 무중단으로 배포/재시작되는 구조로 만..

목차1.Jib이란 무엇인가?2.왜 도입을 했는가?3.프로젝트에 적용4.후기 1.Jib이란 무엇인가?Jib 공식 문서Jib은 구글에서 만든 Java 컨테이너 이미지 빌더다. 간단히 말하면 Dockerfile없이 Gradle이나 Maven 플러그인만으로 Spring Boot프로젝트를 쉽고 빠르게 Docker이미지를 만들 수 있다. 기존 방식 기존의 DockerFile의 경우에는 빌드 → jar 생성 → Dockerfile 작성 → docker build/push 순으로 진행합니다.하지만 이러한 방식은 이미 패키징된 jar 파일을 이미지화 시켰기 때문에 약간의 소스 수정이 일어나더라도 변경된 소스로 인해 dependency들이 포함된 jar 파일 전체가 새로운 이미지로 인식 되어 전체 파일 빌드를 다시 수행하..