Software Engineering 25

[동시성] 낙관적 락, 비관적 락 그리고 Atomic Update

1. Lost Update현재 재고가 10개인 상품이 있다.사용자 A 주문동시에 사용자 B도 주문이렇게 두 요청이 동시에 실행되면 다음과 같은 문제가 발생할 수 있다.A가 재고 10을 readB도 재고 10을 readA가 9로 updateB도 9로 update결과적으로 재고는 8이어야 하는데, 9가 된다.이 문제를 Lost Update라 한다.여러 트랜잭션이 서로의 변경을 덮어버리는 대표적인 동시성 문제다.2. 비관적 (Pessimistic Lock)이름 그대로 "충돌이 무조건 발생한다"라고 비관적으로 가정하는 것이다.그래서 데이터를 읽는 순간 DB에 락을 건다.락을 건다는 것은 내가 작업하는 동안 다른 트랜잭션은 기다려야 한다.예를 들어 SELECT ... FOR UPDATE가 대표적인 방식이다.1) ..

[Spring HTTP Client] 2. Blocking / Non-blocking, Sync / Async 정리

이전 글에서 RestTemplate, WebClient, RestClient의 차이를 정리했다.https://foreverwon.tistory.com/entry/Spring-HTTP-Client-RestTemplate-vs-WebClient-vs-RestClient그런데 HTTP 클라이언트를 이해하려면 반드시 알아야 하는 개념이 있다.Blocking vs Non-blockingSynchronous vs Asynchronous이 네 가지가 정확히 무엇인지 모르면 WebClient가 고성능인 이유, RestClient가 MVC 환경에 적합한지 이해하기 어렵다.이번 글에서는 이 개념을 정리한다.1. Blocking vs Non-blocking이 개념은 스레드 관점이다.요청을 보냈을 때 현재 스레드가 기다리는가..

클라우드 네이티브란?

클라우드 네이티브는 IaaS, PaaS, SaaS처럼 명확한 서비스 분류가 아니다.종종 기술 이름처럼 오해되지만, 실제로는 설계 철학에 가까운 개념이다.1. 클라우드 네이티브 정의클라우드 환경을 전제로 서비스를 설계하고 운영하는 방식 즉, 처음부터 다음을 가정한다.서버는 언제든지 죽을 수 있다.트래픽은 갑자기 늘 수 있다.배포는 자주 한다.특징자동 확장(Auto Scaling)무중단 배포장애 허용 설계컨테이너 기반 운영운영 자동화→ Docker나 k8s는 클라우드 네이티브를 구현하기 위한 "수단"이지, 그 자체가 클라우드 네이티브는 아니다!2. 클라우드 네이티브 = MSA ?둘은 함께 자주 언급되지만, 같은 개념은 아니다.MSA: 서비스 분리 전략(아키텍처 구조)클라우드 네이티브: 운영 전제와 설계 방식..

클라우드 서비스 모델(IaaS/PaaS/SaaS) 정리

이번 글에서는 클라우드 서비스 모델의 차이에 대해 정리하고자 한다. 1. IaaS, PaaS, SaaS 개념 정리IaaS (Infrastructure as a Service)서버, 네트워크, 스토리지 같은 인프라만 제공그 위의 모든 것은 개발자 책임특징자유도가 가장 높음대신 운영 부담도 가장 큼예AWS EC2GCP Computure EnginePaaS (Platform as a Service)서버와 실행 환경까지 이미 구성된 플랫폼 제공개발자는 코드에 집중 가능특징서버 설정, 런타임 설치 불필요빠른 개발과 배포에 유리예AWS Elastic BeanstalkHerokuGoogle App EngineSaaS (Software as a Service)완성된 소프트웨어를 구독 형태로 사용사용자는 운영이나 배포를..

SaaS란?

정의Software as a Service의 약자로, 설치 없이 인터넷으로 접속해 사용하는 소프트웨어 서비스이다.대표적인 예로는 Slack, notion, Google Docs 등과 같은 서비스가 있으며, Netflix와 같은 구독형 웹 서비스도 SaaS의 특징을 일부 공유한다.특징1) 구독형 모델월/연 단위 결제사용자 수, 기능 단위 요금제지속적인 서비스 운영 전제2) 웹 기반 제공설치 불필요OS 환경에 독립적3) 중앙 관리 & 자동 업데이트모든 사용자가 동일한 최신 버전 사용(사용자는 업데이트 신경 X)운영 측면에서 유지보수 효율 높음4) 멀티 테넌시하나의 시스템을 여러 고객이 공유, 데이터는 논리적으로 분리운영 효율과 확장성 향상* 멀티 테넌시(Multi-Tenancy)- 하나의 애플리케이션을 여러..

[API Design] 멱등성(Idempotent)

외부 API를 수집하여 대규모의 데이터를 저장했던 프로젝트에서 어떻게하면 이 데이터를 최적화해서 중복되지 않게 저장할 수 있을지 고민하다가 '멱등키'라는 것을 알게 되었다. 이 내용을 가지고 프로젝트를 리팩토링할 예정이다.멱등이란?어떤 연산이나 작업을 여러 번 반복해서 수행해도 결과가 최초 한 번 수행했을 때와 동일하게 유지되는 성질이다.HTTP 메서드에서의 멱등메서드멱등성DELETEOGETOPOSTXPUTOPATCHXPUT vs PATCH (PUT은 멱등하고 PATCH는 멱등하지 않은 이유)put 메서드는 '전체 리소스'를 교체하기 때문에 결과가 동일하다.그러나 patch 메서드는 '부분 리소스'를 수정하기 때문에 구현에 따라 멱등일수도 있고 멱등하지 않을수도 있기 때문에 멱등하지 않다.patch 메서..

테스트코드에서 사용하는 @Captor

1. 정의Mockito에서 제공하는 애노테이션으로 모의(Mock) 객체에 전달된 메서드 호출 시 실제 인수(argument)를 캡처하는데 사용내부에서 어떤 값이 전달됐는지 확인하고 싶을 때 사용하는 도구ArgumentCaptor 타입을 사용해서 특정 타입의 인수를 캡처할 수 있음2. Why단순히 verify(mock).method(any())처럼 호출 여부만 검증하면, 전달된 값 자체는 검증할 수 없음예를 들어, WebSocket 이벤트가 정확한 DTO와 watcherCount로 전송되는지 확인하고 싶을 때 필요3. WhenMock 객체가 받는 인자 값을 직접 검증하고 싶을 때특히 서비스에서 DTO를 생성해서 외부로 전송하는 이벤트, 메시지, 로그 등단순 호출 여부 확인이 아닌, 전달된 데이터까지 확인하..

[TDD] 6. Controller 계층 테스트

📚 TDD 1-1. Spring Test 1-2. Spring Test 모듈 2. JUnit 5 3. Spring Data JPA: 데이터 액세스 계층 테스트 4. Mockito 5. Service 계층 테스트1. API 계층 테스트의 목적컨트롤러 테스트는 서버를 띄우지 않고 API Mapping(요청→검증→위임→응답)을 빠르게 테스트하는 도구MockMvc로 성공/실패/예외 흐름을 고정하고, 에러 포맷과 상태 코드를 일관되게 유지하면 회귀와 장애를 줄일 수 있음비즈니스 로직 자체는 검증 X → 서비스 단위 테스트에서 수행목적핵심 확인 포인트대표 테스트요청 처리 정확성라우팅, 파라미터/바디 파싱, 서비스 위임should delegate to service and return 200입력값 검증Bean V..

[TDD] 5. Service 계층 테스트

📚 TDD 1-1. Spring Test 1-2. Spring Test 모듈 2. JUnit 5 3. Spring Data JPA: 데이터 액세스 계층 테스트 4. Mockito 1) 서비스 계층 테스트의 목적서비스 계층이란?정의유스케이스(업무 시나리오)를 수행하는 애플리케이션의 핵심 계층도메인 규칙 조합, 저장소/외부 시스템과 상호작용, 예외와 트랜잭션 경계 관리목표컨트롤러/프레젠테이션 계층에서 입력을 받아 도메인 로직을 실행하고 결과 반환테스트 포인트입력 검증상태 변화(저장/수정/삭제)외부 호출 횟수/순서실패 시 롤백project-root/├─ src/│ ├─ main/java/│ │ ├─ app/service/ # 서비스 유스케이스│ │ ├─ app/domain/ ..

728x90