Docker
·
☁️
서버 단위의 배포전통적인 방식서버(인스턴스) 내에서 동작, 새로운 배포를 위해 인스턴스 전체에 대해 배포 작업 이뤄짐하나의 서버 인스턴스(물리 서버 or VM)에 애플리케이션 직접 설치되고 실행됨이 서버는 OS, 네트워크 설정, 의존성, 런타임 환경 모두 포함/ 애플리케이션 이 환경 위에서 동작단점복잡한 관리: 업데이트나 설정 변경 복잡확장성 제한: 새로운 서버 인스턴스 준비, 동일한 환경 복제 ⇒ 시간 많이 걸리고 리소스 낭비될 수 있음유연성 부족: 하나의 서버에 여러 애플리케이션 설치 ⇒ 충돌 발생할 수 있음/ 환경 분리 어려움컨테이너 단위의 배포Traditional Deployment: 온프레미스 환경Virtualized Deployment: 온프레미스 환경에서 발전 But, 하드웨어를 가상화 → ..
Spring Validation
·
💻/Spring | SpringBoot
클라이언트 → 서버전달되는 데이터에 대해 유효성 검증 수행유효성 검증 실패 → 에러(`MethodArgumentNotValidException`)를 발생하도록 처리하는 라이브러리전체적인 흐름클라이언트) 데이터 담아서 `@RequestBody`, `@RequestParam`, `@PathVariable Annotation` 이용 → API 호출서버) `@Valid` or `@Validation Annotation` → 데이터 유효성 검증검증 통과서버) 성공 응답(Response) 데이터 전송 → 클라이언트검증 실패`MethodArgumentNotValidException` 에러 발생`@ControllerAdvice @ExceptionHandler` 로 구성한 `GlobalException`에서 해당 에러 ..
Pessimistic Lock(비관적 락) vs. Optimistic Lock(낙관적 락)
·
Computer Science/데이터베이스
두 번의 갱신 분실 문제(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..
Saga & 2PC
·
💻
사가패턴(Saga Pattern)복잡한 트랜잭션 → 서비스 단위로 분산시키기 위해 적합한 패턴트랜잭션 중 오류 발생 → 보상 트랜잭션 ~> 이전 단계 취소 ⇒ 데이터 일관성 보장1) 코레오그래피 기반 사가(Choreography-based Saga)각 서비스가 이벤트 발행하고 구독하여 상호작용(+) 중앙 관리 X 분한된 환경에서 빠르게 대응 O각 서비스가 서로의 상태를 알지 못하는 상황 발생할 수 있음전체 트랜잭션 상태나 흐름 추적 어려움워크플로우의 확장과 변경 어려움새로운 단계 추가 or 기존 워크플로우 변경 → 모든 관련 서비스 수정(-) 복잡한 워크플로우 O → 서비스 간 이벤트 흐름 엉킬 위험 있음다수의 서비스 순차적으로 관여 → 이벤트 여러 단계로 연쇄적으로 전달 ⇒ 이벤트 흐름 복잡예외 처리 ..
Trigger(트리거) & Procedure(프로시저)
·
Computer Science/데이터베이스
Trigger(트리거)트리거를 건다어떤 트랜잭션 일어날 때 반응 → 다른 명령 실행하게 하는 것테이블에 대한 이벤트(INSERT, UPDATE, DELETE)에 반응 → 자동으로 실행DDL, DML, 일부 DB 작업⇒ 데이터 무결성, 특정 작업 자동화ex. 결제 삽입, 업데이트 → 실시간 결제상태/이력 테이블 업데이트Procedure(프로시저)프로시저를 실행한다일련의 쿼리 작업 → 하나의 함수처럼 실행하기 위한 쿼리 집합미리 SQL문 작성, 필요할 때마다 호출읽기 성능 최적화, data 조회ex. 결제 프로시저 정의(결제 승인 → 기록 삽입 → 잔고 갱신 → 알림 전송)⇒ 트랜잭션 실패 → 롤백 ⇒ 데이터무결성
Spring Webflux, WebClient
·
💻/Spring | SpringBoot
Blocking 방식요청한 작업이 끝날 때까지 다른 작업 X 기다림= 하나의 Thread 요청 처리 → 처리함수 실행하면 제어권 함께 넘김⇒ 해당 함수가 끝날 때까지 다른 함수 호출 XNon-Blocking 방식요청한 작업이 수행되는 동안 다른 작업 O= 호출자가 함수 호출 → 제어권을 호출자가 가지고 있음⇒ 다른 작업 수행 ORestTemplateMulti-Thread + Blocking 방식Thread가 다 차는 경우 요청이 Queue에서 대기⇒ 클라이언트 접속 수↑ (동시성 ↑) → CPU, 메모리 충분해도 Thread 부족 → 성능 ↓Thread ↑ → CPU, 메모리 성능 ↓Spring 5.0 이후 → WebClient 사용하는 것이 권장TomactJava 기반의 웹 애플리케이션 서버, Spri..
kimmeoww
'분류 전체보기' 카테고리의 글 목록 (11 Page)