코딩은 마라톤

🚨발단: 운영 서버 접근 불가 회사에서 일하고 있는데 디코 알림이 울렸다. 알림을 보니 모이삼(https://moisam.kr/) 접근이 되지 않는다는 오류였다..이전에 cert-manager, nginx-ingress 충돌 났을 때랑 동일 증상이라 SSL 인증서 문제인가 했지만.. AWS ACM을 사용 중이었어서 이 경우는 아니었다. AWS에서 확인해 보니 이벤트가 금일 쭉 쌓여 있었고, 모든 내용이 다음과 같았다.service was unable to place a task.Reason: CannotPullContainerError: pull image manifest has been retried 7 time(s):failed to resolve ref .dkr.ecr.ap-northeast-..

요새 AWS로 마이그레이션을 진행하고 있다.마이그레이션을 진행하기 앞서, 배포 과정에서의 문제점을 살펴보고 개선할 수 있는 부분은 개선하고자 했다. 서버 로그를 살피고 있던 도중, 어느샌가 스프링 애플리케이션 초기 실행 시간이 40초에 근접했다.사실 나는 Github Actions가 돌아가는 것이 배포의 시작이자 끝이라 생각했다.하지만 애플리케이션 초기 실행 시간, 그리고 배포된 Docker Image를 Pull 하는 과정에 대해선 간과하고 있었다. 초기 실행 시간을 줄일 순 없을까?배포 과정에서 도커 이미지를 만들고 push, pull 과정에서 개선할 수 없을까?그래서 나는 위 두 가지의 고민을 해결하고자 찾던 도중 "Layered Jar"를 알게 되었다. Layered Jar흔히 `./gradlew..

중간지점 찾기 서비스인 모이삼에서는 중간지점 산출 및 출발지에서 중간지점까지의 상세 경로를 알려준다.https://www.moisam.kr/ 모이삼최적의 중간장소 찾기, 약속장소 추천www.moisam.kr 중간지점은 최대 3개까지 산출되며, 출발지마다 경로를 보여주는 만큼, 응답 데이터의 크기는 중간지점 수와 출발지 수에 비례한다.그래서 모이삼은 응답 시간을 줄이기 위해 응답 데이터 캐싱과 멀티 스레드를 사용해 외부 API에서 경로를 가져오는 등 여러 처리를 진행했다. 위 과정을 통해 비약적으로 속도 개선을 이뤘지만, 응답 데이터의 크기는 줄이지 못했다. 줄일 수 있는 방법을 찾아보던 와중, 응답 데이터를 압축할 수 있는 포맷인 gzip을 알게 되었다. 🏠 gzip이란?gzip은 파일 압축 및 압축 ..

최근 외부 API 장애를 대응하기 위해 Timeout, Retry, Circuit Breaker을 적용했다.특히 Retry, Circuit Breaker는 Resilience4j를 활용해 application.yml에 값을 설정함으로써 개발을 진행했다.하지만 막상 적용해 보니 우여곡절을 겪어, 이번 글에서는 문제점과 해결 과정에 대해 공유하고자 한다.이번에 사용한 Resilience4j dependenciesimplementation 'io.github.resilience4j:resilience4j-spring-boot3'implementation 'org.springframework.boot:spring-boot-starter-aop'1️⃣ configs VS instances// configs 사용 ..

들어가며 엔티티를 설계하다 보면 기계적으로 붙이는 애노테이션이 있다.@Entity@NoArgsConstructor(access = AccessLevel.PROTECTED) 항상 위 2개의 애노테이션을 붙이면서 엔티티 관련 문제가 발생한 적이 없고, 잘 쓰고 있었다. NoArgsConstructor를 사용하는 이유는 JPA에서 엔티티 생성 시 Reflection 방식을 사용하는데 이때 기본 생성자가 필요하기 때문이다. 또한 지연로딩(Lazy Loading)을 사용해 연관된 엔티티를 조회할 때 실제로 사용하기 전까지는 프록시 객체를 사용하는데, 이때 기본 생성자가 private으로 선언되어 있다면 해당 엔티티를 상속한 프록시 객체를 사용할 수 없어 이를 방지하기 위해 public이나 protected를 사용..

SPOT(스팟)의 서비스명이 모이삼으로 변경되었습니다!모이삼도 많은 관심 부탁드려요~! 시작하기 앞서https://developer-anxi.tistory.com/79https://developer-anxi.tistory.com/80 앞선 두 개의 글에서 운영·스테이징 환경으로 분리하는 과정을 알아보았습니다. Git-flow는 분리 이전에도 사용했습니다.하지만 운영, 스테이징으로 분리됨으로써 메인 브랜치(prod, develop)와 보조 브랜치(release)가 추가되었고,develop에서 prod로 작업 커밋을 옮기는 과정 또한 정했어야 하기 때문에 이번에 Git-flow 기반으로 모이삼의 방식을 만들었습니다!모이삼의 Git-flow 전략 Git-flow는 메인 브랜치인 master, develop과 ..

중간 지점 추천 서비스인 SPOT(스팟)은 에러 발생 시, 팀에서 어떤 에러인지 문의가 들어오고 이때 터미널에 들어가 로그를 확인했다.다만, 아직 미흡한 로깅 처리와 에러 추적에 대한 시스템을 마련해두지 않아서 매번 예외 로그만 확인하는데 시간이 꽤 걸렸다. 팀 SPOT은 디스코드를 협업 툴로 사용하고 있고, 디스코드 웹훅을 이용해 에러 발생 시 신속하게 대응할 수 있을 것으로 판단하여 스팟-에러 알림 채널을 만들었다. 웹훅을 어떻게 연동하고 처리하는지 알아보자! 1. 디스코드 웹훅 생성하기 디스코드 알림 채널을 만들고, 서버 설정 -> 연동을 통해 웹훅을 만들 수 있다.웹훅을 만들고 연결할 알림 채널과 이름을 설정하고 웹후크 URL을 복사한다. 웹훅 URL에 요청을 보내 디스코드에 알림을 보내는 방식..

https://developer-anxi.tistory.com/79 [Kubernetes] K3s로 운영·스테이징 환경을 단일 서버에서 분리하기 (1)나는 현재 중간 지점 추천 서비스인 "스팟(SPOT)"을 디벨롭하고 있으며 8월 중에 릴리즈 예정이다.지금은 UI 개선과 API 로직 개선 등 다방면에서 개선하고 있다. SPOT은 릴리즈 전인 지금도 사용할developer-anxi.tistory.com 1부에서는 K3s로 단일서버에서 운영·스테이징 환경으로 분리한 이유를 적어보았다.이번에는 단일서버에서 분리한 방식을 적어보려 한다. 쿠버네티스를 적용한 아키텍처 기존 아키텍처와 바뀐 부분은 쿠버네티스를 적용해서 Ingress 및 운영, 스테이징 네임서버 분리 그리고 스프링 애플리케이션 파드와 레디스 파드를 ..