
⚠️ 본문에서는 각 개념에 대한 자세한 내용을 다루지 않고, 어느 정도의 이해도가 있다는 전제로 큰 진행 과정만을 다루고 있습니다.따라서 자세한 내용은 각 내용에 첨부된 글을 참고해 주세요.🙇🏻♂️부족한 내용은 댓글로 남겨주시면 보완하도록 하겠습니다.다루는 내용JIB를 활용한 컨테이너 이미지 빌드/푸시AWS EC2무중단 배포모니터링도메인 등록SSL 인증서이해가 필요한 개념JIBAWS EC2DockerNginxprometheusGrafanaJIB를 활용한 컨테이너 이미지 빌드/푸시일반적으로 도커 허브에 이미지를 빌드하기 위해 Docker, Dockerfile이 필요한데Gradle, Maven에서 Jib plugin을 활용해 간편하게 이미지를 빌드하고 푸시하는 방법을 알아 보려고 합니다.JIB 설정sp..

Prometheus & Grafana모니터링에 대한 부분을 다시 정리해 보려고 한다.서비스를 운영하며 어디에 어떤 문제가 발생했는지 사전 대응하고, 실제 문제 발생 시에도 원인을 빠르게 파악하고 대처하기 위해애플리케이션의 CPU, Memory, Connection, Request 같은 수많은 지표들을 확인하는 것이 필요Spring Actuator애플리케이션이 살아있는지, 로그 정보는 정상 설정 되었는지, 커넥션 풀은 얼마나 사용되고 있는지 등 확인Production-ready Features지표(metric): CPU 사용량추적(trace): 이슈 코드 추적감사(auditing): 고객 로그인, 로그아웃 이력 추적모니터링: 시스템 상태Dependencyimplementation 'org.springfra..

📊 동시성 제어 방식 비교SeriesJava Concurrency ControlDatabase Concurrency ControlRedis Concurrency ControlKafka Concurrency ControlCompare Concurrency Control⚠️ 로컬에서 테스트한 결과이고,서버 환경과 여러 요인들에 의해 결과가 달라질 수 있고, 정확하지 않을 수 있습니다.Case 01한정수량 : 50,000Total User : 296Processes : 8Threads : 37(DB Named 방식은 제외).시간 내에 모든 트래픽을 성공적으로 처리한 방식DB PessimisticRedis IncrKafka + Redis.일부 성공을 하긴 하였지만, 트래픽을 버티지 못하고 성능 문제가 발생한 ..

Transaction Propagation스프링 트랜잭션을 다시 공부하며 영한님의 스프링 DB 2편 - 데이터 접근 활용 기술 강의 내용을 요약해 보았습니다.트랜잭션 전파Spring Transaction Propagation Use transaction twice[출처: https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-2]로그를 보면 트랜잭션1, 2가 같은 conn0 커넥션을 사용 중인데, 이것은 커넥션 풀 때문트랜잭션1은 conn0을 모두 사용 후 커넥션 풀에 반납하고, 이후 트랜잭션2가 conn0을 커넥션 풀에서 획득히카리(HikariCP) 커넥션 풀에서 커넥션을 획득하면 실제 커넥션을 그대로 반환하는 것이 아니라 내부 관리를 위해히카리..

Spring Transaction스프링 트랜잭션을 다시 공부하며 영한님의 스프링 DB 2편 - 데이터 접근 활용 기술 강의 내용을 요약해 보았습니다.추상화org.springframework.transaction.PlatformTransactionManager 인터페이스를 통해 트랜잭션 추상화package org.springframework.transaction;public interface PlatformTransactionManager extends TransactionManager { TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException; void commi..

Spring 공통 예외 처리(ControllerAdvice, ExceptionHandler) @ControllerAdvice, @ExceptionHandler 는 애플리케이션의 모든 컨트롤러에서 발생할 수 있는 예외를 한 곳에서 관리하기 위해 설계된 기능입니다. 예외 발생 시 ResponseEntity 또는 JSON/XML 형태로 클라이언트에게 에러 정보를 제공할 수 있고, 특정 컨트롤러, 패키지에 대한 예외만 처리할 수도 있습니다. . 아래 코드를 보면 bindingResult 를 검증하는 코드와 try-catch 로 예외를 핸들링하는 것을 볼 수 있습니다. 모든 컨트롤러에 아래와 같은 형태로 구현을 하게 되면 컨트롤러에 코드가 거대해지고 코드를 읽기도 어려워질 것 같죠?! 제가 그랬었답니다..😅 @P..

Content type 'application/octet-stream' not supported for bodyType Intro WebClient를 사용하여 아래와 같은 방식으로 API 통신을 하던 중 마주한 예외를 탐구해 보게 되었습니다. Response response = webClient.mutate() .baseUrl(baseUrl).build() .post().uri(uri) .bodyValue(requestBody) .headers(httpHeaders -> httpHeaders.setAll(headers)) .retrieve() .onStatus(HttpStatus::isError, res -> { return Mono.error(new ResponseStatusException(res.s..

Redis로 Session 관리하기 사이드 프로젝트에서 JWT를 쿠키에 저장하는 방식으로 인가를 구현하게 되었습니다. 처음에 각각 명확한 장/단점이 존재하는 쿠키 방식과 세션 방식 중 고민을 많이 했었는데, JWT 정보가 클라이언트 측에 저장되다 보니 쿠키에 저장된 JWT 정보만 탈취하면 너무나도 쉽게 계정을 도용해서 접속할 수 있을 것 같다는 생각이 들었습니다. 사용자가 얼마나 될지 모르겠지만, 그래도 사용자에게 로그인에 대한 찝찝함을 제공하지 않으려면 그래도 안전한 세션 방식을 활용하는 것이 좋을 것 같아서 세션 방식으로 다시 적용하게 되었습니다. (찾다 보니 쿠키, 세션의 장점을 모두 활용하는 방식으로 함께 적용한다고도 합니다.) . 세션 저장소는 in-memory data store(redis)를..