본문 바로가기
Spring과 의존성 주입 (DI) 의존은 변경에 의해 영향을 받는 관계를 의미한다. DI는 의존하는 객체를 직접 생성하는 대신 의존 객체를 전달받는 방법을 말한다. 의존성 주입 위치별 특징 의존성을 주입하는 방법은 크게 3가지이다. 1. Constructor Injection 클래스를 생성할 때, 모든 의존성 객체를 주입하기 때문에 NPE 문제를 방지할 수 있다. final 인자를 사용할 수 있기 때문에 불변성을 유지할 수 있다. 반면, 여러 객체를 의존하고 있는 경우 의존성 객체를 주입하는 코드가 복잡해지고 이해하기 어려워진다. 그러나 여러 객체를 의존한다는 것은 SRP (단일 책임 원칙)을 위배하는 것이기 때문에 베드스멜인 상황이다. 의도적으로 의존 객체를 줄여야한다는 위기의식을 줄 수 있기 때문에 권장되는 방식이다. 2. Sette..
HTTPS 통신 순서 1. 브라우저는 호스트 주소를 IP로 변환한다. 로컬에 IP 주소가 있으면, 주소 정보를 재사용한다. 만약 없으면 DNS 서버에 질의한다. 2. 주소가 https 스키마로 시작하는 경우, 클라이언트는 서버의 443 포트로 TCP 커넥션을 연다. SSL 트래픽은 바이너리 프로토콜이기 때문에 HTTP와는 다르다. 그래서 80번 포트가 아니라 443 포트로 통신한다. 3. 클라이언트와 서버가 보안 변수를 주고받는 HandShake 시작한다. 3-a. 클라이언트가 서버에 보안 설정을 위한 요청을 보낸다. 이를 Client Hello라고 부른다. 세션키 생성에 사용할 랜덤 스트링, 사용가능한 암호화 기법 등을 전달한다. 3-b. 서버도 보안 설정에 필요한 응답을 내려준다. 이를 Server Hello라고 부른다...
레이어드 아키텍처 레이어드 아키텍처 (n티어 아키텍처)는 일반적으로 많이 사용되는 아키텍처이다. 더 나은 아키텍처 대안을 찾지 못할 때, 쉽게 선택하는 아키텍처 패턴이다. Spring Project에서 각 레이어는 다음과 같은 클래스로 구현된다. Presentation Layer : Controller Business Layer : Service Persistence Layer : Entity Database Layer : Repository 특징 레이어드 아키텍처는 작고 간단한 서비스를 만들 때, 출발점으로 적합한 아키텍처다. 개발자에게 익숙하고, 복잡도도 낮기 때문에 소규모 애플리케이션에 적합하다. 단점 계층형 아키텍처는 영속성 계층을 토대로 만들어지기 때문에, 데이터베이스 주도 설계를 유도한다. 계층형 아키텍처에서 ..
AWS SQS Queue - 표준 VS FIFO 표준 대기열 초당 호출수 제한이 거의 없다. 무제한이다. 표준 대기열도 최대한 메시지가 도착한 순서대로 처리될 수 있도록 메시지를 정렬하고 있다. 그러나 순서가 안맞을 수도 있다. 메시지가 중복으로 발행될 수도 있다. AWS에서는 고가용성을 위해 메시지를 여러 서버에 복제해둔다. 만약 메시지 수신/삭제 요청이 서버에 반영되지 않는 경우, 메시지가 중복으로 발행될 수 있다. 때문에 표준 대기열을 사용하는 경우, 중복 요청이 발생하더라도 문제가 되지 않도록 멱등적으로 기능을 구현해야한다. FIFO 대기열 초당 호출수 제한이 있다. API는 초당 최대 300개까지 호출할 수 있다. 배치 함수는 메시지를 초당 최대 3000개까지 처리할 수 있다. 배치 API도 초당 최대 300개까지 호출할 수 있고, 하나의 A..
ADR: Architecture Decision Record ADR이란? "아키텍처 결정 레코드"는 소프트웨어 아키텍처 의사 결정 과정을 문서로 기록하는 양식을 의미한다. 의사 결정 과정을 문서화한 자료는 지난 히스토리를 쉽게 파악하고 동료들을 설득하는 데에 사용된다. 양식 ADR 포맷 제목 아키텍처 결정을 간략히 기재 상태 제안됨 / 수락됨 / 대체됨 지난 의사 결정이 대체되는 경우, 지난 ADR에 의사결정이 대체되었다는 사실을 기록해둔다. 그리고 수락됨 ADR에는 대체된 ADR 경로를 기록해둔다. 콘텍스트 왜 이렇게 결정할 수 밖에 없었나? 결정 결정. 그리고 그렇게 결정한 합당한 사유 결과 해당 결정이 미치는 영향 컴플라이언스 (옵션) 해당 작업이 반영되었음을 어떻게 확인할 수 있는가 노트 (옵션) 이 결정에 관한 메타데이터 (결정에 참여한 사람) 참고 ht..
분산 시스템을 위한 유일 ID 생성기 설계 가상면접 사례로 배우는 대규모 시스템 설계 기초 책의 7장을 보면, 분산 시스템을 위한 유일 ID 생성기 설계 패턴에 대해 나온다. 최근에 고민했던 것들이 모두 정리되어있어 블로그에도 남겨본다. 이 책에서는 유일 ID 생성 패턴은 크게 4가지이다. 1. 데이터베이스 별로 pk 생성 규칙을 나눠갖기 DB 별로 사용할 수 있는 pk 생성 규칙을 나눠가지는 안이다. 후보1: pk 증분 기준을 각각 다르게 설정하기 예를 들어, pk를 auto_increment를 데이터베이스 별로 증가시키는 기준을 다르게 가져가는 안이 있다. 갈레라 클러스터 처럼 분산 DB 구조에서는 이런 패턴을 사용하고 있다. 그러나 DB 서버를 증설하거나 삭제하는 작업이 쉽지 않다는 단점이 있다. 후보2: pk 시작값을 다르게 설정하기 대신..
UUID와 increment PK는 언제 사용해야할까? 1. 기본키로 UUID를 사용할 때 오는 이점 테이블의 기본키로 UUID를 사용하는 방법은 3가지 이점이 있다. (a) 데이터베이스가 여러 개인 경우, 하나의 ID가 여러 데이터베이스에서도 고유한 값이라고 볼 수 있다. 이러한 전제가 있으면, 서로 다른 테이블에서 관리되던 데이터를 하나의 데이터 소스로 합치기 쉽다. 예를 들어, 뉴스 콘텐츠 테이블이 1개가 있고, 이를 검색 엔진 (ElasticSearch)에 복제하고 있다고 가정해보자. 이후, 잡지 콘텐츠 테이블이 필요하게 되어, 이 정보를 동일한 ElasticSearch에 추가해야하는 상황이 왔다고 상상해보자. 두 테이블이 숫자 기반의 pk를 사용하고 있었다면 두 콘텐츠의 ID가 충돌나는 현상이 발생하게 된다. 이 때문에 두 테이블을 하나의 소스에 합..
Hibernate Query Plan Cache란? JPQL 쿼리 혹은 Criteria 쿼리는 AST(Abstract Syntax Tree)으로 파싱된다. 그래야 하이버네이트가 SQL문을 실행할 수 있다. 이와 같은 쿼리 컴파일 시간을 단축시키기 위해 하이버네이트는 Query Plan Cache를 사용한다. 네이티브 쿼리인 경우, 하이버네이트에서 파라미터와 반환 타입에 대한 정보를 추출하여 ParameterMetadata에 저장한다. 모든 실행마다 하이버네이트는 Cache를 확인하여 Query Plan이 있는지 확인한다. 없는 경우에만 Query Plan을 새로 생성한 후, 향후 재사용을 위해 캐시에 값을 저장한다. Query Plan Cache 설정 Query Plan Cache는 두가지 속성으로 설정할 수 있다. hibernate.query.plan_..

티스토리툴바