Docker
·
☁️
서버 단위의 배포전통적인 방식서버(인스턴스) 내에서 동작, 새로운 배포를 위해 인스턴스 전체에 대해 배포 작업 이뤄짐하나의 서버 인스턴스(물리 서버 or VM)에 애플리케이션 직접 설치되고 실행됨이 서버는 OS, 네트워크 설정, 의존성, 런타임 환경 모두 포함/ 애플리케이션 이 환경 위에서 동작단점복잡한 관리: 업데이트나 설정 변경 복잡확장성 제한: 새로운 서버 인스턴스 준비, 동일한 환경 복제 ⇒ 시간 많이 걸리고 리소스 낭비될 수 있음유연성 부족: 하나의 서버에 여러 애플리케이션 설치 ⇒ 충돌 발생할 수 있음/ 환경 분리 어려움컨테이너 단위의 배포Traditional Deployment: 온프레미스 환경Virtualized Deployment: 온프레미스 환경에서 발전 But, 하드웨어를 가상화 → ..
[PlantiFy] 숲 꾸미기 서비스(Item Service) - 서비스 개요 / JPA N+1 문제 및 해결
·
💻/프로젝트
숲 꾸미기 서비스 개요아이템을 캐시로 구매 -> 보유 -> 실제 공간에 배치ex. 싸이월드 미니룸ERD 설계Item (상점 아이템) └─ MyItem (사용자가 보유한 아이템) └─ UsingItem (공간에 배치된 아이템)Item - 상점에 존재하는 아이템상점에서 판매되는 원본 아이템가격, 이미지, 카테고리 등 변하지 않는 정보 관리주요 필드Item- itemId (PK)- name- price- imageUri- category- createdAt- updatedAt 특징사용자와 직접적인 관계 X여러 사용자가 동일한 Item을 여러 개 구매 가능읽기 중심(Read-heavy) 엔티티MyItem - 사용자가 소유한 아이템특정 사용자가 얼마나 많은 아이템을 보유하고 있는지 표현Item과 User..
Pessimistic Lock(비관적 락) vs. Optimistic Lock(낙관적 락)
·
📓/데이터베이스
두 번의 갱신 분실 문제(Second lost updates problem)두 트랜잭션에서 데이터 변경 → 최종적으로 한 트랜잭션의 결과만 남는 것⇒ 해결: 마지막 커밋만 인정 / 최초의 커밋만 인정 / 충돌하는 갱신 내용 병합⇒ JPA에서는 비관적 락/낙관적 락 매커니즘 제공Pessimistic Lock(비관적 락)트랜잭션의 충돌이 발생한다고 가정트랜잭션이 시작될 때 데이터베이스에 락 → 다른 트랜잭션 접근 XShared Lock(공유 락, S Lock)특정 Row 읽을(Read) 때 사용여러 트랜잭션이 동시에 한 Row에 S Lock 걸 수 있음하나의 Row를 여러 트랜잭션이 동시에 읽을 수 있음S Lock이 설정된 Row에는 X Lock 사용 XInnoDB에서 일반적인 `SELECT` 쿼리는 Loc..
사가 패턴 - 코레오그래피 기반 사가 / 오케스트레이션 기반 사가 & 2PC
·
💻/BE
사가패턴(Saga Pattern) 복잡한 트랜잭션 → 서비스 단위로 분산시키기 위해 적합한 패턴트랜잭션 중 오류 발생 → 보상 트랜잭션 ~> 이전 단계 취소 ⇒ 데이터 일관성 보장 1) 코레오그래피 기반 사가(Choreography-based Saga)각 서비스가 이벤트 발행하고 구독하여 상호작용(+) 중앙 관리 X 분한된 환경에서 빠르게 대응 O각 서비스가 서로의 상태를 알지 못하는 상황 발생할 수 있음전체 트랜잭션 상태나 흐름 추적 어려움워크플로우의 확장과 변경 어려움새로운 단계 추가 or 기존 워크플로우 변경 → 모든 관련 서비스 수정(-) 복잡한 워크플로우 O → 서비스 간 이벤트 흐름 엉킬 위험 있음다수의 서비스 순차적으로 관여 → 이벤트 여러 단계로 연쇄적으로 전달 ⇒ 이벤트 흐름 복잡예외 처..
Trigger(트리거) & Procedure(프로시저)
·
📓/데이터베이스
Trigger(트리거)트리거를 건다어떤 트랜잭션 일어날 때 반응 → 다른 명령 실행하게 하는 것테이블에 대한 이벤트(INSERT, UPDATE, DELETE)에 반응 → 자동으로 실행DDL, DML, 일부 DB 작업⇒ 데이터 무결성, 특정 작업 자동화ex. 결제 삽입, 업데이트 → 실시간 결제상태/이력 테이블 업데이트Procedure(프로시저)프로시저를 실행한다일련의 쿼리 작업 → 하나의 함수처럼 실행하기 위한 쿼리 집합미리 SQL문 작성, 필요할 때마다 호출읽기 성능 최적화, data 조회ex. 결제 프로시저 정의(결제 승인 → 기록 삽입 → 잔고 갱신 → 알림 전송)⇒ 트랜잭션 실패 → 롤백 ⇒ 데이터무결성
Spring Webflux, WebClient
·
💻/BE
Blocking 방식요청한 작업이 끝날 때까지 다른 작업 X 기다림= 하나의 Thread 요청 처리 → 처리함수 실행하면 제어권 함께 넘김⇒ 해당 함수가 끝날 때까지 다른 함수 호출 XNon-Blocking 방식요청한 작업이 수행되는 동안 다른 작업 O= 호출자가 함수 호출 → 제어권을 호출자가 가지고 있음⇒ 다른 작업 수행 ORestTemplateMulti-Thread + Blocking 방식Thread가 다 차는 경우 요청이 Queue에서 대기⇒ 클라이언트 접속 수↑ (동시성 ↑) → CPU, 메모리 충분해도 Thread 부족 → 성능 ↓Thread ↑ → CPU, 메모리 성능 ↓Spring 5.0 이후 → WebClient 사용하는 것이 권장TomactJava 기반의 웹 애플리케이션 서버, Spri..
aeongg
빙글빙글 돌아가는 Debug 하루