전체 글

Redis 동시성 처리동시성 이슈데이터 불일치여러 스레드가 동시에 동일한 데이터를 수정데드락 (Deadlock)두 개 이상의 스레드가 서로의 자원을 기다리다가 멈추는 상태라이브락 (Livelock)스레드가 락을 반복적으로 획득하려다 아무런 진전이 없는 상태경쟁 조건동시에 자원에 접근하여 예상하지 못한 결과가 발생하는 상태=> 동시성 제어(: 멀티스레드 환경에서 일관된 데이터 처리를 보장하는 방법) 필요동시성 제어 기법락(Lock)한 스레드가 자원을 사용하는 동안 다른 스레드가 해당 자원에 접근하지 못하도록 막는 기법Mutex (Mutual Exclusion): 가장 기본적인 락/ 하나의 스레드만 자원에 접근할 수 있도록 보장Reentrant Lock: 동일한 스레드가 여러 번 락을 획득할 수 있는 락세마..

Memcached(멤캐시드)사용이 간편한 고성능 인 메모리 데이터 스토어 장점1밀리 초 미만의 응답 시간서버의 주 메모리에 모든 데이터를 유지PostgreSQL, Cassandra 및 MongoDB와 같은 데이터베이스: 데이터 대부분을 디스크 또는 SSD에 저장인 메모리 데이터 스토어: 반복해서 디스크를 왕복할 필요 X → 더 ↑ 작업 처리 + 더 빠른 응답 지원단순성 및 사용 편의성간단하고 일반적이 되도록 설계되었으므로 애플리케이션 개발에 사용하기에 쉬우면서 강력다수의 오픈 소스 클라이언트를 사용지원되는 언어: Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, Go 등확장성분산 및 다중 스레드 아키텍처를 사용하면 손쉽게 확장여러 노드 간에 데이터를 ..

Kubernetes(쿠버네티스)구글이 컨테이너 운영을 위해 출시한 오픈소스 라이브러리컨테이너 오케스트레이션 플랫폼 여러 IT 자동화 태스크 또는 프로세스를 조정하여 실행하는 것다수의 Docker 컨테이너 관리, 자동으로 배포 및 스케일링, 장애 복구 기능 제공여러 대의 서버(노드)에서 컨테이너 → 클러스터로 묶어 애플리케이션 분산, 필요할 때마다 리소스 할당 → 자동으로 확장 or 축소⇒ Docker: 컨테이너 하나하나 관리/ Kubernetes: 그 컨테이너들 효율적으로 배치하고 관리순서코드 푸시 → CI/CD 파이프라인 트리거(Github Actions)Docker 이미지 빌드 → 이미지 레지스트리에 업로드(Docekr Hub, ECR 등)Kubernetes 클러스터에 배포(kubectl, Helm ..

서버 단위의 배포전통적인 방식서버(인스턴스) 내에서 동작, 새로운 배포를 위해 인스턴스 전체에 대해 배포 작업 이뤄짐하나의 서버 인스턴스(물리 서버 or VM)에 애플리케이션 직접 설치되고 실행됨이 서버는 OS, 네트워크 설정, 의존성, 런타임 환경 모두 포함/ 애플리케이션 이 환경 위에서 동작단점복잡한 관리: 업데이트나 설정 변경 복잡확장성 제한: 새로운 서버 인스턴스 준비, 동일한 환경 복제 ⇒ 시간 많이 걸리고 리소스 낭비될 수 있음유연성 부족: 하나의 서버에 여러 애플리케이션 설치 ⇒ 충돌 발생할 수 있음/ 환경 분리 어려움컨테이너 단위의 배포Traditional Deployment: 온프레미스 환경Virtualized Deployment: 온프레미스 환경에서 발전 But, 하드웨어를 가상화 → ..

클라이언트 → 서버전달되는 데이터에 대해 유효성 검증 수행유효성 검증 실패 → 에러(`MethodArgumentNotValidException`)를 발생하도록 처리하는 라이브러리전체적인 흐름클라이언트) 데이터 담아서 `@RequestBody`, `@RequestParam`, `@PathVariable Annotation` 이용 → API 호출서버) `@Valid` or `@Validation Annotation` → 데이터 유효성 검증검증 통과서버) 성공 응답(Response) 데이터 전송 → 클라이언트검증 실패`MethodArgumentNotValidException` 에러 발생`@ControllerAdvice @ExceptionHandler` 로 구성한 `GlobalException`에서 해당 에러 ..

두 번의 갱신 분실 문제(Second lost updates problem)두 트랜잭션에서 데이터 변경 → 최종적으로 한 트랜잭션의 결과만 남는 것⇒ 해결: 마지막 커밋만 인정 / 최초의 커밋만 인정 / 충돌하는 갱신 내용 병합⇒ JPA에서는 비관적 락/낙관적 락 매커니즘 제공Pessimistic트랜잭션의 충돌이 발생한다고 가정트랜잭션이 시작될 때 데이터베이스에 락 → 다른 트랜잭션 접근 XShared Lock(공유 락, S Lock)특정 Row 읽을(Read) 때 사용여러 트랜잭션이 동시에 한 Row에 S Lock 걸 수 있음하나의 Row를 여러 트랜잭션이 동시에 읽을 수 있음S Lock이 설정된 Row에는 X Lock 사용 XInnoDB에서 일반적인 `SELECT` 쿼리는 Lock 사용 XBut, `..