개발놀이터

이번 포스팅에서는 JPA의 2차 캐시에 대해서 알아보도록 하겠습니다. JPA에서 우리가 익숙한 것은 1차 캐시입니다. 보통 영속성 컨텍스트로 많이 알려진 1차 캐시는 JPA가 동작하면서 필요한 데이터들을 모아두는 공간입니다. 보통 1차 캐시는 트랜잭션별로 저장하기 때문에 휘발성이 강한 캐시 저장소입니다. 반면 2차 캐시는 1차 캐시와 다르게 글로벌하게 적용되는 캐시입니다. 애플리케이션마다 적용되는 캐시로서 애플리케이션이 종료될 때까지 유지되는 캐시입니다. 그럼 이제 본격적으로 2차 캐시에 대해서 알아볼까요? 2차 캐시 2차 캐시란 무엇인가? 2차 캐시는 앞서 설명했듯이 애플리케이션 단위의 캐시로 애플리케이션이 종료될 때까지 유지됩니다. 이 말은 멀티 스레드 환경에서도 글로벌하게 사용되는 캐시라고 이해할 ..

이번 포스팅에선 JPA가 어떻게 동시성 문제를 컨트롤하는지에 대해서 포스팅해보겠습니다. 개인적으로 동시성 문제는 애플리케이션에서 일어날 수 있는 가장 최악의 버그라고 생각합니다. 그 이유로는 RuntimeException이 발생하지 않는다. 컴파일러도 모른다. 심각한 장애를 야기한다. (재고가 1개 있는데 3명이 1개씩 주문하면 재고가 0이 되면서 결제 로그가 세개 찍힘) 때문에 이러한 동시성 문제에 대해 개발자가 반응하고 테스트 케이스를 통해 동시성 문제를 잡아내야한다고 생각합니다. 물론 쉽지는 않지만요. JPA에선 이러한 동시성 문제를 해결하기 위해 두 가지 Locking 매커니즘을 제공합니다. 이제 본격적으로 시작해보죠! Locking 매커니즘 JPA는 Locking 매커니즘으로 두 가지를 제공하는..

JPA는 자바 진영에서 사용하는 대표적인 ORM 중 하나입니다. JPA로 인해 자바 개발자들이 데이터베이스 중심에서 객체 중심으로 설계 방식을 전환할 수 있었다고 개인적으로 생각하고 있는데요. 저는 여태껏 JPA를 사용하는데에만 집중을 했습니다. 그래서 JPA가 가진 특징들에 대해서는 등한시 한 느낌이 있습니다. 하지만 제 공부 방식은 항상 써보고 익숙해지면 개념을 공부하는 느낌이었어서 지금이라도 주요 개념들에 대해서 공부해보고자 오랜만에 JPA 카테고리에 글을 썼습니다. 이번 포스팅에선 JPA가 트랜잭션을 관리하는 방법과 JPA에서 제공하는 다양한 기능들에 대해서 소개해드리고자합니다. JPA가 트랜잭션을 관리하는 방법 JPA는 트랜잭션을 프록시를 이용해서 관리합니다. 여기까지는 보통 알고 있는 내용일겁..

이번 포스팅에선 도커를 활용해 MySQL 서버를 레플리케이션 (복제) 하여 DB 부하를 줄여보겠습니다. 제 프로젝트 컨셉상 레플리케이션이 필요한 구조이긴 합니다만... 조금 의구심이 들긴 합니다. 데이터베이스 서버를 여러대 두는게 아니고 한 인스턴스에서 MySQL 서버 여러개 둔다고 DB 부하가 줄어들지는 모르겠습니다. 그래도 그냥 새로운거 도전한다고 생각하고 한번 해보도록 하겠습니다. 레플리케이션 레플리케이션이 뭔지 먼저 짚고 넘어가도록 하죠. 데이터베이스 레플리케이션이란, 데이터베이스 클러스터링에서 발전된 형태로서 DB 스토리지와 DB 서버가 하나의 쌍을 이뤄 원래라면 하나의 DB 서버가 부담해야할 부하를 여러대로 나눠 부하를 줄여줌으로써 데이터베이스의 성능이 떨어지지 않게 유지하는 방법입니다. 클러..

프로젝트를 진행하다가 EC2 용량이 꽉차서 조금 당황했습니다. 어라.. 미디움이면 충분하다고 했는데... 네 생각보다 많은 이미지와 꽤 큰 프로젝트 용량 덕분에 용량이 다 차버려서 진행이 안됐습니다. 때문에 구글링한 결과를 공유하려고 합니다. EC2 용량 부족시 해결법 먼저 용량이 얼마나 남았는지를 봅니다. 7.6기가가 꽉 찼네요. EC2 인스턴스에 들어가서 인스턴스 클릭 후 스토리지를 클릭합니다. 볼륨 ID를 클릭해주고 볼륨을 우클릭 후 수정 후 원하는 사이즈로 적습니다. lsblk 명령어를 치면 xva 스토리지는 12기가로 늘어났지만 우리가 사용하는 xvda1 섹션이 아직 7.9기가입니다. 이걸 늘려줘야합니다. 위의 명령어를 치시구요. 이렇게 치면? 짠 Size가 12기가로 늘어났습니다. 여기까지 E..

프로젝트를 구현할 때 어떤 기술을 어떻게 구현했는지도 물론 중요하겠지만 왜 그 기술을 선택했는지에 대한 고찰이 조금 부족했다는 생각이 들었습니다. 물론 사전에 조사는 다 했지만 직접 써보고 단점을 겪어본 것이 아니기 때문에 추상적일 뿐이었습니다. 이번 기회에 정확히 어떤 기술이 어떤 장점과 단점이 있고 내 프로젝트에 어떤 이유때문에 이 기술을 선택하게 되었는지에 대한 정리를 해봤습니다. 기술 선택 이유 제 프로젝트에는 다음과 같은 기술이 선택되었습니다. 캐싱에 Redis 검색엔진에 Elasticsearch 인증에 JWT 동시성 문제 해결에 비관적 락 배포에 docker 자동화에 jenkins 1. 캐싱에 Redis 스프링에서 캐싱을 사용하기 위해서 다양한 방법이 존재합니다. Redis Memcached ..

이전 포스팅과 이어집니다. https://coding-review.tistory.com/414 CI / CD 자동화 (2) : Jenkins 시작하기 앞선 포스팅과 이어지는 내용입니다. https://coding-review.tistory.com/413 CI / CD 자동화 (1) : Jenkins vs Github Action 이전 포스팅을 보고 오시면 더 이해하기 쉽습니다! https://coding-review.tistory.com/410 Docker + Ngin coding-review.tistory.com 이제 본격적으로 파이프라인을 만들어보겠습니다. Github project를 클릭하시고 아래에 자신의 github 리포지토리 주소를 입력합니다. 주의해야하는 점은 맨 마지막에 / (슬래쉬) 반드..

앞선 포스팅과 이어지는 내용입니다. https://coding-review.tistory.com/413 CI / CD 자동화 (1) : Jenkins vs Github Action 이전 포스팅을 보고 오시면 더 이해하기 쉽습니다! https://coding-review.tistory.com/410 Docker + Nginx를 이용해 스프링 프로젝트 무중단 배포하기 : 과정 저번 포스팅에선 docker + nginx를 가지고 무중단 배포 coding-review.tistory.com 저는 EC2 환경에서 Linux 22.04 LTS 버전을 이용해 Jenkins를 구축했습니다. 이 점 참고하시기 바랍니다. Jenkins를 우분투 환경에서 시작하는 방법에는 두가지가 있습니다. 직접 설치 docker를 이용해 ..

이전 포스팅을 보고 오시면 더 이해하기 쉽습니다! https://coding-review.tistory.com/410 Docker + Nginx를 이용해 스프링 프로젝트 무중단 배포하기 : 과정 저번 포스팅에선 docker + nginx를 가지고 무중단 배포를 하는 방법에 대해서 설명한 것이구요. 이번 포스팅에선 전체적인 과정에 대해서 알아보도록 하겠습니다. 이번 포스팅은 아래와 같은 순서 coding-review.tistory.com 이번 포스팅에선 Jenkins를 시작하는 방법에 대해서 포스팅해보도록 하겠습니다. 이전 포스팅에서 블루 그린 배포를 성공적으로 완료했지만 문제가 있었습니다. 그것은 바로 엄청나게 복잡한 배포 과정인데요. 잠깐 이전 포스팅 내용을 정리하자면 우리의 블루 그린 배포는 다음과 ..

기왕 시작한거 끝을 보자는 느낌으로 배포까지 진행하자고 생각했습니다. 또한, 단순히 배포하는 것이 아니라 실제 프로덕트에서 사용중인 무중단 배포를 진행해보고 싶었습니다. 무중단 배포에는 크게 세가지 방법이 있었는데 그 중 블루 그린 배포가 매력적이라고 느껴져 무중단 배포에 블루그린 배포를 진행하였습니다. 1. 기존 프로젝트의 배포 Cafe 24의 웹 호스팅을 이용해 배포 WAR 파일을 이용해 배포 2. 기존 프로젝트에서 배포의 문제점 단일 서버이기 때문에 DB 서버만 키운다던가 하는 유연한 대처가 불가능 가장 큰 문제점은 배포를 하고 나서 정상적으로 배포가 안되는 경우가 많았음 항상 서버를 몇번씩 재시작을 해줘야 정상적으로 서버가 작동되었는데 이 시간이 대략 5분정도 걸렸음 3. ver.2에서 개선한 점..