개략적인 규모 추정(back-of-the-envelope estimation)은 보편적으로 통용되는 성능 수치상에서 사고 실험(thought experiments)을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것 -구글 senior fellow 제프 딘(Jeff Dean)

2의 제곱수

모든 프로그래머가 알아야 하는 응답지연 값

• 메모리는 빠르지만 디스크는 아직도 느리다
• 디스크 탐색은 가능한 한 피하라
• 단순한 압축 알고리즘은 빠르다
• 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라
• 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다

가용성에 관계된 수치들

고가용성(high availability): 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력

SLA(Service Lavel Agreement): 서비스 사업자와 고객 간에 맺어진 합의로, 서비스 사업자가 제공하는 서비스의 가용시간(uptime)이 기술되어 있다.

팁

개략적인 규모 추정과 관계된 면접에서 가장 중요한 것은 문제 해결 능력

• 근사치를 활용한 계산: 면접장에서 정확한 계산을 하기 어려우므로 적절한 근사치를 활용하여 시간 절약
• 가정들은 적어두기
• 단위 꼭 붙이기
• 많이 출제되는 개략적 규모 추정 문제는 QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등 추정하는 것

1. 사용자는 도메인 이름(api.mysite.com)을 이용해 웹사이트에 접속한다. 웹사이트에 접속하기 위해 도메인 이름을 DNS에 질의하여 IP 주소로 변환한다.
2. DNS 조회 결과로 IP 주소를 반환한다.
3. IP 주소로 HTTP 요청이 전달된다.
4. 요청을 받은 웹 서버는 HTML이나 JSON을 응답한다.

데이터베이스

웹/모바일 트래픽 처리 서버(웹 계층)와 데이터베이스 서버(데이터 계층) 분리를 하여 독립적으로 확장 가능

관계형 데이터베이스(RDBMS)

• MySQL, Oracle, PostgreSQL
• 자료를 테이블, 열, 칼럼으로 표현
• 여러 테이블에 있는 데이터를 조인(join)할 수 있음

비관계형 데이터베이스(NoSQL)

• CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB
• 키-값 저장소(key-value store), 그래프 저장소(graph store), 칼럼 저장소(column store), 문서 저장소(document store)
• 조인 연산 지원하지 않음
• 다음과 같은 경우에 사용하는 것이 좋음
  • 아주 낮은 응답 지연시간(latency) 요구하는 경우
  • 다루는 데이터가 비정형 데이터인 경우
  • 데이터(JSON, YAML, XML 등)를 직렬화 혹은 역직렬화 할 수 있기만 하면 되는 경우
  • 아주 많은 양의 데이터를 저장할 필요가 있는 경우

수직적 규모 확장 vs 수평적 규모 확장

수직적 규모 확장(Scale Up)

• 고사양 자원(더 좋은 CPU, 더 많은 RAM 등)을 추가하는 행위
• 서버로 유입되는 트래픽 양이 적을 때 좋은 선택
• 하드웨어의 한계가 있음
• 자동복구(failover) 방안이나 다중화(redundancy) 방안을 제시하지 못해 서버에 장애가 발생하면 웹사이트/앱이 완전히 중단됨

수평적 규모 확장(Scale Out)

• 더 많은 서버를 추가하여 성능을 개선하는 행위
• 대규모 애플리케이션 지원하는데 유리

로드밸런서

로드밸런서는 부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽을 고르게 분산하는 역할을 한다.

사용자는 로드밸런서의 공개 IP 주소로 접속하고, 로드밸런서와 웹서버 간의 통신에는 사설 IP 주소가 이용된다. 사설 IP 주소는 같은 네트워크에 속한 서버 사이의 통신에만 쓰일 수 있는 IP 주소로, 인터넷을 통해서는 접속할 수 없다.

부하 분산 집합에 웹 서버를 추가하면 장애 자동복구(failover) 문제가 해소되고, 웹 계층의 가용성(availability)은 향상된다.

데이터베이스 다중화

주(master) - 부(slave) 관계를 설정하고, 데이터의 원본은 master에, 사본은 slave에 저장한다.

쓰기 연산은 master에서만 지원한다. slave는 master로 부터 사본을 전달 받으며, 읽기 연산만 지원한다. 대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산의 비중보다 높기 때문에 통상적으로 slave의 수가 master의 수보다 많다.

데이터베이스 다중화의 장점

• 더 나은 성능: 쓰기 연산은 master, 읽기 연산은 slave로 전달되기 때문에 병렬로 처리될 수 있는 query의 수가 늘어나 성능이 향상된다.
• 안정성(reliability): 데이터를 지역적으로 떨어진 여러 장소에 다중화시켜 놓으면 자연 재해등의 이유로 데이터베이스 서버의 일부가 파괴되어도 데이터가 보존된다.
• 가용성(availability): 데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터베이스 서버에 장애가 발생해도 다른 서버에서 데이터를 가져와 계속 서비스할 수 있다.

캐시

캐시 계층 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다. 별도의 캐시 계층을 둠으로써 성능이 개선되고, 데이터베이스의 부하를 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능하다.

캐시할 데이터의 종류, 크기, 액세스 패턴에 맞는 캐시 전략을 선택할 수 있다.

캐시 사용 시 유의할 점

• 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 경우 캐시 사용에 유리
• 캐시는 데이터를 휘발성 메모리에 두므로 영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않음
• 적절한 만료(expire) 정책을 설정하는 것이 좋음
• 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부인 일관성(consistency) 고려 필요
• 캐시 서버를 한 대만 두는 경우 단일 장애 지점(Single Point of Failure, SPOF)이 되어버릴 가능성이 있기 떄문에 여러 지역에 걸쳐 캐시 서버 분산시키는 것이 좋음
• 캐시 메머리 과할당(overprovision)을 통해 캐시 메모리가 부족해지는 문제 해결
• 적절한 캐시 데이터 방출(eviction) 정책 필요

콘텐츠 전송 네트워크(CDN)

CDN은 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크이다. 이미지, 비디오, CSS, JavaScript 파일 등을 캐시할 수 있다.

1. 사용자 A가 CDN 서비스 사업자가 제공한 이미지 URL을 통해 이미지에 접근한다.
2. CDN 서버의 캐시에 해당 이미지가 없는 경우, 서버는 원본 서버에 파일을 요청하여 가져온다.
3. 원본 서버가 파일을 CDN 서비스에 반환한다. 이때 응답 헤더에는 캐시될 수 있는 기간인 TTL이 들어있다.
4. CDN 서버는 파일을 캐시하고 사용자 A에게 반환한다. 이미지는 TTL이 끝날 때까지 캐시된다.
5. 사용자 B가 같은 이미지에 대한 액세스 요청을 CDN 서버에 전송한다.
6. 만료되지 않은 이미지에 대한 요청은 캐시를 통해 처리된다.

CDN 사용 시 고려해야 할 사항

• 비용: CDN으로 들어가고 나가는 데이터 전송 양에 따라 요금을 내게 되므로, 자주 사용되지 않는 콘텐츠를 캐싱하는 것은 이득이 크지 않음
• 적절한 만료 시한 설정: 너무 길지도, 짧지도 않은 TTL 설정 필요
• CDN 장애에 대한 대처 방안: CDN 자체가 죽었을 경우, 해당 문제를 감지하여 원본 서버로부터 직접 콘텐츠를 가져오도록 클라이언트 구성 필요
• 콘텐츠 무효화 방법
  • CDN 서비스 사업자가 제공하는 API 이용
  • 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝 이용

무상태(stateless) 웹 계층

상태 정보에 의존적인 아키텍처는 서버에 사용자의 상태 정보가 보관되어 있기 때문에 같은 클라이언트로부터의 요청을 항상 같은 서버로 전송해야 하는 문제점이 발생한다. 대부분의 로드밸런서가 이를 지원하기 위해 고정 세션(sticky session) 기능을 제공하고 있지만, 이는 로드밸런서에 부담을 준다.

무상태 아키텍처는 상태 정보를 공유 저장소에 저장하여 필요한 경우 가져와서 사용한다. 상태 정보는 웹 서버로부터 물리적으로 분리되어 있어 안정적이며, 규모 확장이 쉽다.

상태 정보가 저장되는 공유 저장소르 관계형 데이터베이스일 수도 있고, Memcached/Redis 같은 캐시 시스템일 수도 있고, NoSQL일 수도 있다.

데이터 센터

지리적 라우팅(geoDNS-routing, geo-routing): 장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 안내됨 geoDNS: 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정할 수 있도록 해주는 DNS 서비스

DC1(US-East), DC2(US-West)로 트래픽이 나뉘어 전달된다고 할 때, DC2(US-West)에서 장애가 발생하면 모든 트래픽이 DC1(US-East)로 전송된다.

다중 데이터센터 아키텍처를 만들기 위한 기술적 난제

• 트래픽 우회: 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 함. GeoDNS는 사용자에게서 가장 가까운 데이터 센터로 트래픽을 보냄
• 데이터 동기화(synchronization): 데이터를 여러 데이터 센처에 걸쳐 다중화하는 것 필요
• 테스트와 배포(deployment):자동화된 배포 도구는 모든 데이터 센터에 동일한 서비스가 설치되도록 하는데 중요한 역할

메시지 큐

메시지 큐: 메시지의 무손실(durability, 메시지 큐에 보관된 메시지는 소비자가 꺼낼 때까지 안전하게 보관됨)을 보장하는, 비동기 통신(asynchronous communication)을 지원하는 컴포넌트

메시지 큐를 이용하면 서버 간 느슨한 결합(loosely coupled)이 되어 규모 확장성이 보장되어야 하는 안정적 애플리케이션 구성에 유리하다. 또한 생산자와 소비자는 각기 독립적으로 확장 가능하다.

로그, 메트릭 그리고 자동화

• 로그: 로그를 단일 서비스로 모아주는 도구를 활용해 편리하게 에러 로그 모니터링

• 메트릭: 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악 가능.

  • 호스트 단위 메트릭: CPU, 메모리, 디스크 I/O에 관한 메트릭
  • 종합(aggregated) 메트릭: 데이터베이스 계층의 성능, 캐시 계층의 성능
  • 핵심 비즈니스 메트릭: 일별 능동 사용자(DAU), 수익(revenue), 재방문(retention)

• 자동화: 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구 이용. 지속적 통합(Continuous Integration) 도구를 통해 빌드, 테스트, 배포 등의 절차 자동화 가능

데이터베이스의 규모 확장

수직적 확장(Scale Up)

• 기존 서버에 더 많은, 고성능의 자원(CPU, RAM, 디스크 등)을 증설하는 방법

• 수직적 확장의 단점

  • 데이터베이스 서버 하드웨어에는 한계가 있으므로 무한대로 자원을 증설할 수 없다.

  • SPOF로 인한 위험성이 크다.

  • 고성능 서버로 갈 수록 비용이 많이 든다.

수평적 확장(Scale Out)

• 샤딩(sharding)이라고도 부름

• 더 많은 서버를 추가함으로써 성능 향상

• 샤딩: 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술

• 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복 없음

• 데이터를 고르게 분할할 수 있는 적절한 샤딩 키(sharding key)를 정해 데이터 조회나 변경 처리의 효율을 높임

• 샤딩 도입시 풀어야할 문제

  • 데이터의 재 샤딩(resharding): 데이터가 너무 많아져서 하나의 샤드로 감당하기 어렵거나, 샤드 소진 현상이 발생하면 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치 해야함
  • 유명인사(celebrity) 문제: 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
  • 조인과 비정규화: 하나의 데이터베이스를 여러 샤드로 쪼개면, 여러 샤드에 걸친 데이터를 조인하기 힘들어짐. 데이터베이스 비정규ㄹ화를 통해 하나의 테이블에서 질의가 수행될 수 있도록 하여 해결

Controller -> Facade -> Service -> Repository <- RepositoryImpl

Layered Architecture + Clean Architecture 관점에서 접근하여 단방향 의존성을 지키며 구현했다.

2. 통합 테스트를 어떤 방식으로 구성했나요? 테스트를 통해 확인하고 싶었던 건 무엇이었나요?

Controller, Facade, Service에 대해서 통합 테스트를 진행하였다. 이전 주차에 작성해둔 단위 테스트를 바탕으로 비즈니스 흐름 상 각 단위가 잘 조립되어 작동하는지에 대해 집중하며 통합테스트를 구현하였다.

시간 부족 이슈로 성공하는 케이스에 대해서만 작성한 것이 아쉬움이 남는다. 5주차를 진행하면서 예외 케이스에 대해서 추가로 작성해보는 것도 좋을 것 같다.

3. DB 성능이나 동시성 문제를 어떻게 분석했고, 어떤 해결 방안을 고민했나요?

예상했던 느린 조회 기능

• 인기 상품 조회
• 상품 목록 조회
• 사용자 보유 쿠폰 조회 -> user_id 인덱스 처리
• 주문 시 재고 조회 -> PK로 조회(이미 인덱스)
• 결제 시 잔액 조회 -> user_id 인덱스 처리
• 결제 시 주문 정보 조회 -> PK로 조회(이미 인덱스)

인기 상품 조회의 경우 인덱스를 걸기 전에 full scan을 하고 있었다. (product_id, created_at, sales)로 복합 인덱스를 걸고 성능을 측정한 결과 성능 개선 가능성은 확보되었으나, 실행시간이 줄어들지는 않았다. 조회된 결과를 캐시 테이블에 저장하는 방법을 통해 추가로 성능 최적화를 진행할 수 있을 것이다.

상품 목록 조회의 경우 full scan을 하며 인덱스를 걸 수 없기 때문에 추후 검색 조건을 추가하거나 페이징을 추가해 성능을 향상시킬 수 있을 것이다.

사유에 대해 좀 더 디깅을 해서 보고서를 작성했으면 좋았을 것 같다는 아쉬움이 있다.

4. 이번 과정을 통해 느낀 점은 무엇인가요?

DB 성능을 고민하면서 DB에 대한 개념과 경험이 부족하다고 느꼈다. DB 성능 최적화 과정을 경험한 적이 전무하다보니 시작을 어떻게 해야할지부터 어려웠다. 성능에 대한 고민을 하면서 최적화할 수 있는 방법을 디깅해봐야겠다.

이번주차는 3주차 피드백을 바탕으로 리팩토링 하는데 시간을 많이 쓰면서 4주차 과제에 힘을 좀 덜 들였는데, 5주차부터는 시간 분배를 잘해서 해당 주차 과제에 힘을 써야겠다.

지난주차에 설계한 것을 바탕으로 Clean + Layered Architecture를 적용하여 구현을 하였다. 그런데.. 하나 Pass, 하나 Fail을 받게 되었다. 도메인이 아닌 데이터 중심적인.. 테이블 그 잡채의 구현을 했던 것이다!! Fail 받은 내용 바탕으로 리팩토링 해야지.. 4주차는 모두 Pass 받을거야~!!!!!

Clean + Layered Architecture가 뭔데..?

지금까지 개발하면서 Layered Architecture 말고 다른 방법을 써서 개발해본 적이 없다. 그래서 이번 항해 이커머스 플젝을 진행하면서 클린 아키텍처를 제대로 도입해보기로 했다. 그런데 쉽지만은 않았다.

클린 아키텍처? Facade?

클린 아키텍처 적용은 정말 낯설었다. 일단 interface - application - domain - infrastructure 계층 구조도 익숙치 않았다. 게다가 Repository 구현체 없이 코드를 작성하라는 과제에 맞추어, JPA도 완전히 배제하고 코드를 작성하다보니 시간도 많이 걸리고, 어려웠다. 익숙하지 않았다.

도메인? 엔티티?

DDD는 말만 들어봤지 실제로 해본 적도 없고, 누가 한 것을 본 적도 없다. 그리고 일단 '도메인 = 엔티티' 라고 생각하고 있었다. JPA를 쓰면서 늘 데이터 중심적이 사고를 해왔으니까.

이번 3주차를 진행하기 전에 도메인과 엔티티에 대해서 많이 찾아봤다. 도메인과 엔티티가 같다고 생각했었던 나에게 큰 전환점이 되었다.

공부를 했지만 실제 구현에서 도메인을 제대로 구현하기란 쉽지 않았다. 내 나름대로 객체지향적으로, 책임을 분리하여서 구현했는데 아니었던 것이다.

3주차를 통해 느낀점

이번주차에 Fail을 받으면서 많은 것을 느꼈다. 처음엔 Fail을 받은 것이 마냥 아쉽게만 느껴졌었는데, 내각 항해를 하는 이유는 배움과 성장을 위한 것이라는 생각을 가지고 다시 Fail을 바라보니 다르게 느껴졌다. 오히려 Fail을 받아서 더 배운 것이 있다고 생각이 들었다.

아직 객체지향적으로, 도메인 주도적인 설계를 하는 것이 어렵다. 도메인에 대한 고민과 공부는 지속되어야 할 것 같다.

이번 과제를 하면서 이틀은 밤을 새다시피 했는데, 다음주차 부터는 시간 관리에 좀 더 신경을 써야겠다.

2주차는 이커머스/콘서트 예매 중 하나의 시나리오를 정하고 이를 설계하는 것이다. 우리 팀은 이커머스로 정했고, 학습메이트의 조언에 따라 팀원 모두가 같이 설계를 진행하였다.

설계 과정은 쉬운듯 어려웠다. 팀원이 모두 같이 진행하다보니 내가 미처 생각하지 못했던 부분을 다른 팀원이 의견을 내면서 설계하는 시야가 점점 넓어졌던 것 같다.

나는 프로젝트를 진행하는게 오랜만이라 처음 배우는 것 같은 느낌이 들었다. 내가 설계를 맞게 하고 있는건지, 혹은 이런 상황에 이런 설계가 맞는 것인지 확신이 들지 않았다.

KPT

Keep

항해 과정에 적응해가면서 퇴근 후 시간을 의미없이 흘려보내지 않고, 항해 과제를 진행한 것!!

Problem

여전히 설계에 대한 많은 의심이 남아있다. 구현 하면서 설계를 바꾸게 될 상황도 오게 될 것 같은데 대응을 잘 해야겠다.

Try

아키텍처에 관련된 공부해보기

항해 플러스를 시작하기 전에는 두려움이 많았다. 회사를 다니고 있지만 전형적인 운영 업무만 하다보니 개발은 물론 고급 기술 또한 사용할 기회가 없었다. 사실 이것도 핑계이다. 업무 핑계를 대지 않고 스스로 공부해보면 기회는 얼마든지 있었는데 내가 하지 않았다.

나는 Comfort zone에 있는 것에 굉장한 안정감을 느끼고 벗어나고 싶어하지 않았던 것 같다. 대기업에 다니고 있고 월급이 계속해서 나온다는 것 때문인지 무언가에 열정을 느끼지도 않았고, 도전하려 하지도 않았다.

직장인이 되고 난 후에 내 시간이 부족해지는 것이 싫어서 출퇴근을 빨리 하기로 했다. 그런데 지금 생각해보면 내가 원해서 만든 내 시간을 의미없이 허투루 보냈다. 그렇게 시간이 쌓여서 벌써 물경력 2년차가 되었다.

이제는 이 모든 상황이 더이상 지속되면 안된다고 생각해 항해를 도전하게 되었다.

1주차를 보내고

어? 나 퇴근하고 시간 많네

과제를 하며 1주차를 보내고 나니 퇴근 후의 시간은 많았다는 것을 가장 먼저 느꼈다. 퇴근 하고 저녁을 먹고 쉬다보면 하루가 금방 끝난다고 생각했는데, 그 시간에 과제를 하니 하루가 길게 느껴졌다.

재미있어!!!

회사에서 fade out 예정이고 안정적인 시스템을 운영 업무 하다보니 사실 코드 짤 일이 거의 없다. 1주차를 진행하면서 다시 '개발'을 하면서 새로운 것을 공부하고 그걸 코드로 구현하는 것에 재미를 느꼈다.

J 같은 생활하기

아직은 일주일 계획이 완전히 잡힌 것 같진 않다. 2주차 때는 실제 나의 스케줄을 기록해보고 항해를 하는 동안 고정된 스케줄을 만들자.

TDD는 이런거구나

허재 코치님의 멘토링, TDD에 대해 공부한 것, 과제 진행을 통해 TDD가 뭔지 감(?)을 잡은 것 같다.(아닐 수도..)

아직 동시성에 대한 개념이 부족해

동시성 처리에 대한 개념이 부족하다. 앞으로 남은 과제에서 동시성에 대해 다룰 일이 계속 있을 것 같은데 추가로 공부하자!!!

1. 무엇을 테스트할 것인가

1-1. 구현부가 아닌 설계를 테스트 해야한다

테스트를 위해 원본의 구현과 설계를 고치는 것이 맞는가?

• 테스트를 위해 구현과 설계는 변경될 수 있다.
• 테스트 코드는 보조 수단이 아닌 같은 레벨로 봐야 한다.
• 좋은 디자인으로 구현된 코드는 테스트하기 쉽다.
• 테스트는 구현 설계 Smell을 맡게 해주는 좋은 수단

1-2. 테스트가 가능한 것, 불가능한 것

• Non-Testable: 제어할 수 없는 영역 ⇒ 멱등한 결과를 보장할 수 없음
  • Random, Shuffle, LocalDateTime.now()
  • 외부 세계(HTTP, 외부 저장소)
• Testable: 항상 성공할 수 있는 것, 항상 동일한 결과가 나올 수 있는 것

2. 어떻게 테스트할 것인가

2-1. 테스트가 불가능한 영역을 Boundary Layer로 올려서 테스트

• 배달팁을 계산하는 로직에서 isValid의 LocalDateTime.now() 는 제어할 수 없는 영역이기에 테스트가 어려움

• LocalDateTime.now()를 Boundary Layer로 끌어올려서 테스트가 가능하도록 변경시킴

어디까지가 Boundary Layer인가? ⇒ 한 모듈로서의 의미를 지니는 가장 바깥쪽

2-2. Java, Spring Framework

@SpringBootTest

• 통합 테스트를 지원하는 스프링 부트 테스트 어노테이션

• 모든 빈들을 스캔하고 애플리케이션 Context를 생성하여 테스트 진행

• Spring Context는 느리다 ⇒ 빠른 피드백을 받을 수 없다

• Spring Context의 오용은 언어의 본질을 망각하게 할 수 있다

• Context, Framework에 의존적이지 않은 테스트를 작성하는 것이 중요!

2-3. Test Double

• Test Double이란?
  • 테스트 중인 시스템의 일부분이 완전히 준비되지 않았거나 테스트하기 어려운 상황에서 그 대안으로 사용될 수 있는 '가짜' 컴포넌트
• Test Double의 종류
  • Dummy: 실제로 사용되진 않지만 파라미터 리스트를 채우기 위한 객체
  • Fake: 실제 객체의 간단한 버전. 가벼운 데이터베이스 서버나 간단한 로직을 가진 컴포넌트로 작동
  • Stub: 테스트 중에 호출되면 미리 준비된 응답을 제공. 특정 메서들 호출에 의한 반환값을 설정하거나 외부 서비스, 컴포넌트를 대체하는데 사용
  • Spy: Stub과 유사하지만 호출되었을 때의 정보 기록. 테스트에서 어떤 메서드가 어떻게, 몇 번 호출되었는지 확인 가능
  • Mock: 예상된 호출 명세를 정의하며 테스트에서 이 명세가 충족되지 않으면 테스트 실패
• 대표적인 Test Double에는 Mockito가 있음
• 무엇을 Test Double로 처리해야 할까?
  • Test Double의 남용은 구현 테스트로 유도할 수 있음
  • Boundary Layer로 끌어 올려진 Non-Testable 코드에 대해 Test Double 처리

2-4. Embedded

• Embedded는 제어할 수 없는 영역을 제어가능하도록 만들 수 있음

• 테스트와 Embedded 시스템은 동일한 라이프 사이클을 갖도록 구성해야 함

  테스트 정확도	Local > Embedded
  테스트 피드백 속도	Local < Embedded
  테스트 안정성	Local < Embedded

2-5. EndPoint Test

• MockMvc, REST Assured, WebTestClient
• 엔드 포인트 테스트는 요청과 응답 스펙 검증만으로 제한하는게 좋음

2-6. Spring Cloud Contract

• MSA 환경에서 E2E 테스트를 위해서 만들어진 stub 기반 test 도구
• CDC(Consumer-Driven Contract)를 잘 이뤄질 수 있도록 Contract 공유 메커니즘을 제공

참고

https://www.youtube.com/watch?v=YdtknE_yPk4

https://jwchung.github.io/testing-oh-my

https://jojoldu.tistory.com/674

https://jojoldu.tistory.com/676?category=1036934

https://jojoldu.tistory.com/680?category=1036934

TDD란 Test Driven Development의 약자로, ‘테스트 주도 개발’이라고 한다.

짧은 주기의 반복 테스트를 이용한 소프트웨어 방법론이다.

애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 설계를 중요시 한다.

eXtream Programming(XP) : 고객의 요구 사항에 유연하게 대처하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상하는 방법

TDD 개발 주기

Red-Green-Refactor

• Red: 실패하는 테스트 코드 작성
• Green: 테스트가 통과하는 코드 작성
• Refactor: 중복 코드 제거, 일반화 등 리팩토링 수행

일반적인 개발 방식 vs. TDD 개발 방식

일반적인 개발 방식

• 요구사항 분석 → 설계 → 개발 → 테스트 → 배포
• 고객의 요구사항은 변경될 가능성이 있어 초기에 완벽한 설계 불가능
• 추가적인 요구사항이나 잠재적인 버그 등으로 인해 재설계를 진행하면서 불필요한 코드 발생
• 이는 코드의 재사용성을 떨어트리고, 유지보수를 어렵게 만듦(소스코드 품질 저하)
• 작은 수정에도 모든 기능을 테스트하게 되면서 자체 테스트 비용 증가

TDD 개발 방식

• 테스트 코드 작성 → 개발 → 리팩토링 사이클 반복
• 설계 단계에서 프로그래밍의 목적을 반드시 정의하고, 무엇을 테스트할지 미리 정의해야 함
• 테스트 도중 발생하는 예외 사항(추가 요구사항, 버그 등)을 테스트 케이스에 추가하고 설계 개선
• 위 반복 단계가 진행되면서 자연스럽게 버그가 줄고, 소스코드는 간결해짐(소스코드 품질 향상)
• 지속적인 테스트 코드 작성으로 추가적인 요구사항이 생겨도 재설계 시간이 절약됨

JUnit(Java) 대표적인 TDD Tool로 ‘Java에서 독립된 단위테스트를 지원해주는 프레임워크’이다. 어노테이션 기반으로 테스트를 지원하며, 단정문(Assert)으로 테스트 케이스의 기대값에 대해 수행 결과를 확인한다. c.f.) xUnit 프레임워크: JUnit(Java), CUnit(C), PyUnit(Python) 등

TDD의 장단점

TDD의 장점

1. 디버깅 시간 단축

단위 테스트의 장점이다.

단위 테스트 코드가 없다면 특정 버그가 어디서 발생했는지 찾기 위해 모든 레이어를 디버깅해야 하지만, TDD의 경우 자동화된 단위 테스트를 통해 버그를 쉽게 찾을 수 있다.

2. 코드의 재사용성 증가

Red 단계에서 버그와 같은 예외 사항이 미리 고려되고 테스트가 통과된 코드만 개발 단계에서 사용된다.

불필요하거나 중복이 발생한 코드는 정리되고, 재사용성이 높고 유지보수가 용이한 코드만 남는다.

3. 재설계 시간 단축

테스트 코드를 미리 작성하기 때문에 프로그래밍의 목적을 분명하게 할 수 있다.

테스트 코드를 작성하면서 다양한 예외 사항을 생각해볼 수 있기 때문에 개발을 진행하면서 설계가 변경되는 일을 방지할 수 있다.

4. 빠른 피드백

인수 테스트는 거의 완성된 코드를 가지고 사용자의 관점에서 사용할 수 있는 수준인지를 확인한다. 이 과정에서 문제를 발견해도 정확한 원인 파악이 어렵다.

TDD는 기능 단위로 테스트를 진행하기 때문에 코드가 완성되어 프로그래머의 손을 떠나기 전에 피드백을 받는 것이 가능하다.

5. 불안정성을 제거하여 생산성 향상

켄트 벡은 TDD는 불안함을 지루함으로 바꾸는 마법의 돌이라고 말한 적이 있다.

코드가 지닌 불안정성과 불확실성을 지속적으로 해결하여 생산성을 높인다.

6. 추가 구현 용이

기존 코드에 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다.

하지만 TDD의 경우 자동화된 단위 테스트를 통해 테스트 시간을 단축할 수 있다.

7. 문서 대체 기능

테스트를 작성할 때 어떤 의도를 가지고 테스트 코드를 작성하였는지, 그리고 어떤 결과 값을 기대하는지를 작성하기 때문에 코드를 작성한 사람의 의도를 파악할 수 있다.

TDD의 단점

1. 개발 시간 증가

단기적으로 봤을 때 코드 개발 시간이 증가한다.

개발자에게 테스트 코드 작성이 익숙하지 않을 수도 있고, 기존에 비즈니스 코드만 작성하고 넘어갔을 때에 비해 테스트 코드를 작성하는데 들이는 시간이 많다.

2. 구조에 얽매임

테스트는 테스트일 뿐이고 실제 코드가 더 중요한데, TDD 원칙 때문에 쉽게 넘어가기 못하는 경우가 발생한다.

BDD, DDD

BDD

BDD는 Behevior Driven Development의 약자로 ‘행동 주도 개발’이다.

TDD에서 파생된 개발 방법론으로 사용자 또는 비즈니스 요구사항을 행위와 시나리오를 중심으로 한다.

개발자와 비개발자 모두 이해하기 쉬운 자연어로 표현하여 의사소통을 원활히 하고, 요구사항을 명확하게 전달하고 구현한다.

Given-When-Then 형태로 표현하여 주어진 상황에서 어떤 동작을 하고 기대하는 결과가 나오는지를 명시한다.

Given-When-Then

• Given(주어진 상황): 초기 상태나 전제 조건 기술
• When(행동): 수행할 동작이나 이벤트 기술
• Then(결과): 예상되는 결과나 상태 기술

DDD

DDD는 Domain Driven Design의 약자로 ‘도메인 주도 설계’로, 기존 데이터 중심의 접근법에서 벗어나 도메인 패턴을 중심에 두고 설계하는 방식이다.

보편적인(ubiquitous) 언어를 사용한다. 도메인 전문가와 커뮤니케이션 문제를 없애기 위해 동일한 표현과 단어로 구성된 단일 언어체계를 구축하여 사용한다.

소프트웨어 엔티티와 도메인 컨셉을 가장 가까이 일치시킨다. 도메인 모델부터 코드까지 함께 움직이는 모델을 지향한다.

참고

https://tidyfirst.substack.com/p/tdd-isnt-design

https://f-lab.kr/insight/importance-of-tdd-and-ddd-in-modern-development

https://dhh.dk/2014/tdd-is-dead-long-live-testing.html

컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.

컴포넌트를 변경할 이유가 하나 -> 컴포넌트는 한가지 일만 함

컴포넌트를 변경할 이유가 하나뿐이면 다른 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해 신경쓰지 않아도 됨.

2. 의존성 역전 원칙(Dependency Inversion Principle, DIP)

코드 상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다.

양쪽 코드를 모두 제어할 수 있을 때만 의존성 역전 가능

(서드파티 라이브러리에 의존성이 있으면 라이브러리를 제어할 수 없기 때문에 의존성 역전 불가)

1. 엔티티는 도메인 객체를 표현하고 도메인 코드가 이 엔티티들의 상태를 변경하기 때문에 엔티티를 도메인 계층으로 올림

2. 리포지토리가 도메인 계층의 엔티티에 의존하기 때문에 순환 의존성(circular dependency) 생김

3. 도메인 계층에 리포지토리 인터페이스를 만들고, 실제 리포지토리는 영속성 계층에서 구현

3. 클린 아키텍처

계층 간의 모든 의존성이 안쪽으로 향해야 한다.

도메인 계층이 특정 프레임워크에 특화된 코드를 가질 수 없어 비즈니스 로직에만 집중할 수 있음.

도메인 계층이 외부 계층과 철저히 분리되어야 하므로 엔티티에 대한 모델을 각 계층에서 유지보수 해야함.

도메인 계층은 영속성 계층을 모르기 때문에 도메인 계층에서 사용한 엔티티를 영속성 계층에서 함께 사용 불가. 따라서 각 계층에서 엔티티를 만들어 변환하는 과정 필요.

4. 헥사고날 아키텍처

모든 의존성은 코어를 향함.

헥사고날 아키텍처를 계층으로 구성하면

• 가장 바깥쪽 계층은 애플리케이션과 다른 시스템 간의 번역을 담당하는 어댑터
• 포트와 유스케이스 구현체가 애플리케이션 계층 구성
• 도메인 엔티티가 가장 마지막 계층

포트와 어댑터(port-and-adapters) 아키텍처라고도 불림.

코어와 어댑터 간 통신하기 위해 어플리케이션 코어가 포트 제공.

애플리케이션을 주도하는 어댑터(driving adapter)

포트가 코어에 있는 유스케이스 클래스 중 하나에 의해 구현되고 어댑터에 의해 호출됨

애플리케이션에 주도되는 어댑터(driven adapter)

포트가 어댑터에 의해 구현되고 코어에 의해 호출됨

소프트웨어 설계 패턴 중 하나로, 시스템을 여러 개의 계층으로 분리하여 각 계층이 특정 역할을 수행하도록 하는 방식

특정한 계층에서는 같은 계층에 있는 컴포넌트나 아래에 있는 계층에만 접근 가능

Presentation Layer

사용자의 응답 및 요청 처리하는 계층

Application Layer

비즈니스 로직을 수행하는 계층

Domain Layer

데이터베이스에 요청을 전달(접근)하는 계층.

Database Layer

데이터베이스가 운영되는 계층

2. 계층형 아키텍처의 장점

계층별로 낮은 결합도를 가지고 계층 내에서 높은 응집도를 가지면 유지보수 용이 및 확장성 향상

3. 계층형 아키텍처의 단점

데이터베이스 주도 설계 유도

ORM(Object-Relational Mapping)이 계층형 아키텍처와 결합하면 데이터베이스 주도 설계를 할 가능성이 높아짐. ORM에 의해 관리되는 엔티티는 영속성 계층에 있고 도메인 계층에서 엔티티에 접근하면서 강한 결합이 생김. 이로 인해 도메인 계층에서 도메인 로직 뿐만 아니라 영속성 로직(즉시로딩/지연로딩, 트랜잭셔느 캐시 플러시 등)까지 수행하게 됨.

지름길을 택하기 쉬워짐

마감 기한에 쫓기거나 누군가 한번 지름길을 택하게 되면 이후에는 지름길을 택하는 경우가 많아짐. (지름길: 상위 계층 컴포넌트에 접근해야 하는 경우 해당 컴포넌트를 하위 계층으로 내려버리는 행위 등)

테스트하기 어려워짐

웹 계층에서 도메인 계층을 거치지 않고 바로 영속성 계층에 접근하는 경우 테스트하기 어려워짐.

1. 필드 하나를 조작하더라도 도메인 로직이 웹 계층에 구현되게 되어 책임이 섞이고 핵심 도메인 로직이 퍼져나할 확률이 높아짐.
2. 웹 계층 테스트에서 도메인 계층과 영속성 계층을 모두 mocking 해야하는 문제 발생.

유스케이스를 숨김

도메인 로직이 퍼져나가게 되고, 서비스가 넓어지게 되는 문제가 발생하면 추가 유스케이스가 들어갈 위치를 찾기 어려워짐.

동시 작업이 어려워짐

모든 것이 영속성 계층 위에서 만들어지기 때문에 여러 개발자가 동시에 작업하기 어려움. 서비스가 넓으면 같은 서비스를 여러명이 동시에 작업하면서 병합 충돌(merge conflict) 발생 가능성 높음.

단위 테스트는 최소한의 노력으로 최대한의 이득을 내야 한다.

1. 단위 테스트 현황

단위 테스트가 중요하고, 필수적이라는 인식은 자리 잡았으나, 좋은 단위 테스트를 작성하는 것은 어떤 것인지에 대한 의미는 혼란스러운 상태

2. 단위 테스트의 목표

단위테스트의 목표는 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것.

테스트가 부재하면 처음에는 빠른 시작이 가능하나 이후 시간이 지날 수록 개발 속도가 느려진다. 소프트웨어 엔트로피(software entropy): 개발 속도가 빠르게 감소하는 현상 단위 테스트는 지속성과 확장성이 핵심

2.1 좋은 테스트와 좋지 않은 테스트를 가르는 요인

테스트의 가치와 유지 비용을 모두 고려해야 한다.

• 기반 코드를 리팩토링 할 때 테스트 코드도 리팩토링
• 각 코드 변경 시 테스트 실행
• 테스트가 잘못된 경고를 발생시킬 경우 처리
• 기반 코드가 어떻게 동작하는지 이해하려고 할 때는 테스트를 읽는 데 시간 투자

제품 코드 vs. 테스트 코드

• 코드는 자산이 아니라 책임
• 코드가 많아 진다 = 잠재적인 버그에 노출될 확률 높다 = 프로젝트 유지비가 증가한다
• 테스트 코드도 코드이기에 다른 코드와 마찬가지로 지속적인 리팩토링 필요

3. 테스트 스위트 품질 측정을 위한 커버리지 지표

커버리지는 좋은 부정 지표이지만 나쁜 긍정 지표

3.1 코드 커버리지 지표에 대한 이해

코드 커버리지(테스트 커버리지) = 실행 코드 라인 수 / 전체 라인 수

• 하나 이상의 테스트로 실행된 코드 라인 수와 제품 코드 베이스의 전체 라인 수의 비율

  public boolean isStringLong(String input) {
    if (input.length > 5)
        return true;
    return false;
  }
  

public void Test() { boolean result = isStringLong("abc"); Assertions.assertThat(result).isFalse(); }

이 경우 코드 커버리지는 4/5 = 0.8 = 80%
```java
public boolean isStringLong(String input) {
    return input.length > 5;
}

public void test() {
    boolean result = isStringLong("abc");
    Assertions.assertThat(result).isFalse();
}

위 코드를 리팩토링하여 코드 커버리지를 100%로 만들었다. 하지만 이는 메서드 내의 코드만 바꿨을 뿐 검증하는 결과의 개수는 동일하다. 코드 커버리지는 라인 수만 처리하기 때문에 코드가 작을 수록 유리하다.

3.2 분기 커버리지 지표에 대한 이해

분기 커버리지 = 통과 분기 / 전체 분기 수

• 테스트 스위트 내 하나 이상의 테스트가 통과하는 제어 구조의 수

  public boolean isStringLong(String input) {
    return input.length > 5;
  }
  

public void test() { boolean result = isStringLong("abc"); Assertions.assertThat(result).isFalse(); }

이 경우 분기 커버리지는 1/2 = 50%이다.
코드를 길게 작성하던 짧게 작성하던 분기의 개수는 동일하기에 분기 커버리지는 동일하다.

### 3.3 커버리지 지표에 대한 문제점
#### 테스트 대상 시스템의 모든 가능한 결과를 검증한다고 보장할 수 없다.
```java
public class Example {
    private boolean wasLastStringLong;

    public boolean isStringLong(String input) {
        boolean result = input.length > 5;
        wasLastStringLong = result;
        return result;
    }

    public void test() {
        boolean result = isStringLong("abc");
        Assertions.assertThat(result).isFalse();
    }
}

wasLastStringLong에 result 값을 쓰는 암묵적인 결과를 검증하지 않아도 코드 커버리지 100%와 분기 커버리지 50%의 결과를 보인다.

public void test() {
    boolean result1 = isStringLong("abc");
    boolean result2 = isStringLong("abcdef");
}

test() 메서드를 위와 같이 바꾸면, 코드 커버리지 100%, 분기 커버리지 100%를 나타낸다. 그러나 이 메서드는 아무것도 검증하지 않기 때문에 쓸모가 없는 테스트 코드이다.

외부 라이브러리의 코드 경로를 고려할 수 있는 커버리지 지표는 없다.

public int parse(String input) {
    return Integer.parseInt(input);
}

public void test() {
    int result = parse("5");
    Assertions.assertThat(result).isEqualTo(5);
}

분기 커버리지는 100% 그러나 Integer.parseInt()가 수행하는 코드 경로는 고려되지 않는다.

3.4 특정 커버리지 숫자를 목표로 하기

커버리지 지표는 지표 그 자체로 보는 것이지, 목표로 여겨서는 안된다.

4. 무엇이 성공적인 테스트 스위트를 만드는가?

4.1 개발 주기에 통합되어 있다.

모든 테스트는 개발 주기에 통합 되어야 한다. 이상적으로는 코드가 변경될 때마다 작은 테스트 코드라도 실행해야 한다.

4.2 코드베이스에서 가장 중요한 부분만을 대상으로 한다.

비즈니스 로직(도메인 모델)을 테스트 하는 것에 집중하여 노력을 기울여야 한다.

4.3 최소 유지비로 최대 가치를 끌어낸다.

가치 있는 테스트(+ 가치가 낮은 테스트)를 식별한다. 가치 있는 테스트를 작성한다.

📚 내 생각

단순히 단위 테스트 코드를 작성해야 하고, 단위 테스트를 작성하는 것이 좋다는 것만 알고 있었지 그것이 왜 필요한지, 단위 테스트는 무엇을 검증하는 것인지, 좋은 단위 테스트란 무엇인지 등 단위 테스트의 목표에 대해 생각해보지는 못했었다.

1장의 내용을 통해 단위 테스트의 목표가 무엇인지 알 수 있었고, 지금까지 내가 작성해왔던 단위 테스트, 혹은 통합 테스트가 좋은 테스트 코드였는가에 대한 생각을 해보는 계기가 되었다.

이 책을 읽고 단위 테스트에 대한 이해를 통해 단위 테스트를 작성할 때 애플리케이션의 지속 가능한 성장을 염두에 두고, 최소한의 유지비로 최대한의 가치를 끌어내는 좋은 테스트 코드를 작성하며 나와 애플리케이션이 모두 성장하는 테스트 코드를 작성해야겠다는 생각을 했다.

가용성

• 서비스의 안정성을 측정하는 데 사용되는 지표
• Availability = Available for Use Time / Total Time
• 일정 기간 동안 서비스를 정상적으로 사용할 수 있는 시간 비율
• 고가용성 시스템: 가용성이 높은 시스템

고가용성 확보를 위한 기능

• 복제: 마스터 노드의 데이터를 복제본 노드로 실시간 복사하는 기능
• 자동 페일오버: 마스터 노드에서 발생한 장애를 감지해 레디스로 들어오는 클라이언트 연결을 자동을 ㅗ복제본 노드로 리다이렉션 하는 기능

1. 레디스에서의 복제 구조

• 운영 중인 서비스에서 복제본 노드를 추가하는 이유
  • 서비스를 안정적으로 운영하기 위해서는 마스터 DB가 다운됐을 때 대신 사용할 여분의 복제본 필요
  • 마스터 노드에 접근하는 서비스가 많을 때, 일부 트래픽이 복제본을 바라보게 해 부하 분산
  • 백업을 복제본에서 수행해 백업 작업이 서비스에 미치는 영향도 최소화
• 레디스는 복제본 노드가 기본으로 읽기 전용으로 동작. 모든 데이터 입력은 마스터 노드에서 이루어짐

  복제 구조 구성하기

  REPLICAOF <master-ip> <master-port>

• 한 개의 복제 그룹에서는 항상 한 개의 마스터 노드만 존재
• 복제본 노드에 새로운 복제본 추가 가능

  패스워드 설정

• requirepass 옵션을 이용해 패스워드 설정
• 복제본 노드는 masterpass 옵션에 마스터의 requirepass에 설정된 패스워드 값 입력
• 하나의 복제 그룹에 속한 마스터와 복제본 노드는 같은 패스워드로 설정하는 것이 일반적(다른 패스워드도 가능)

  2. 복제 메커니즘

• 버전 7 이전

  • repl-diskless-sync 옵션 기본값 no(디스크 사용 방식)
  • 디스크 사용하는 방식에서의 복제 연결 메커니즘
    1. REPLICAOF 커맨드로 복제 연결 시도
    2. 마스터 노드에서는 fork로 자식 프로세스를 새로 만든 뒤 RDB 스냅샷 생성
    3. 2번 과정 동안 마스터 노드에서 수행된 모든 데이터셋 변경 작업은 레디스 프로토콜(RESP) 형태로 마스터의 복제 버퍼에 저장
    4. RDB 파일이 생성 완료되면 파일은 복제본 노드로 복사
    5. 복제본에 저장됐던 모든 내용을 삭제한 뒤 RDB 파일을 이용해 데이터 로딩
    6. 복제 과정 동안 버퍼링됐던 복제 버퍼의 데이터를 복제본으로 전달해 수행시킴
  • 복제 속도는 디스크 I/O 처리량에 영향 받음
  • RDB 파일이 생성되는 도중 다른 노드에서 복제 연결 요청이 들어오면 큐에 저장하고 기존 RDB 저장이 완료된 후 여러 복제본이 한 번에 복제 연결 시작

• 버전 7 이후

  • repl-diskless-sync 옵션 기본값 yes(디스크 사용하지 않는 방식)
  • 디스크 사용하지 않는 방식에서의 복제 연결 메커니즘
    1. REPLICAOF 커맨드로 복제 연결 시도
    2. 마스터 노드는 소켓 통신을 이용해 복제본 노드에 바로 연결하며, RDB 파일은 생성됨과 동시에 점진적으로 복제본의 소켓에 전송됨
    3. 2번 과정 동안 마스터 노드에서 수행된 모든 데이터셋 변경 작업은 레디스 프로토콜(RESP) 형태로 마스터의 복제 버퍼에 저장
    4. 소켓에서 읽어온 RDB 파일을 복제본의 디스크에 저장
    5. 복제본에 저장된 모든 데이터를 삭제한 뒤 RDB 파일 내용을 메모리에 로딩
    6. 복제 버퍼의 데이터를 복제본으로 전달해 수행시킴
  • 복제본 노드는 마스터에서 가져온 데이터를 모두 삭제하는 과정을 거치는데, 소켓 통신으로 받아온 RDB 데이터가 정상적인지 미리 확인할 수 없어 삭제 전 자신의 디스크에 데이터를 저장하는 과정을 선행해 데이터의 안정성 확보
  • 디스크의 I/O가 느리고 네트워크가 빠른 경우 디스크를 사용하지 않는 복제 방식을 사용하는 것이 더 빠르게 복제 연결을 완료할 수 있는 방법
  • 하나의 복제본으로 복제 연결이 시작된 경우 복제 과정이 끝나기 전까지 다른 복제본과의 연결 수행 불가. 다른 복제본들은 하나의 복제 연결이 끝날 때까지 큐에서 대기
  • repl-diskless-sync-delay 설정을 통해 설정 시간 만큼 기다린 뒤 복제 연결 시작
  • 네트워크가 유실되어 재동기화를 요청할 경우 마스터에는 한 번에 여러 개의 복제본에서 복제 연결이 들어오는 것이 일반적이기 때문에 repl-diskless-sync-delay 옵션 활성화 하는 것이 좋음

    비동기 방식으로 동작하는 복제 연결

• 정상적으로 복제 연결이 된 상태에서 마스터에서 복제본으로의 데이터 전달은 비동기 방식으로 동작

• 클라이언트는 데이터 입력할 때 마다 복제본에 데이터가 정확하게 전달 되었는지 확인하지 않기 때문에 복제 구조를 사용해도 짧은 지연 시간과 높은 성능 가짐

  복제 ID

• 모든 레디스 인스턴스는 복제 ID(랜덤 스트링) 가짐

• 복제 ID는 오프셋과 쌍으로 존재

• 레디스 내부의 데이터가 수정되는 모든 커맨드를 수행할 때마다 오프셋 증가

• INFO REPLICATION: 복제 연결 상태 확인

• INFO REPLICATION을 통해 확인한 복제본의 replication id는 마스터의 replication id이고, 오프셋은 복제본에서 마지막으로 수행된 마스터의 오프셋

• replication id와 오프셋이 같을 때 두 노드는 정확히 일치된 상태

  부분 재동기화

• 레디스는 부분 재동기화 기능을 사용해 안정적으로 복제 연결 유지

• 마스터는 커넥션 유실을 대비해 백로그 버퍼라는 메모리 공간에 복제본에 전달한 커맨드 데이터 저장

• PSYNC: 복제본이 자신의 replication id와 오프셋을 마스터에 전달해 복제 재연결 시도

• 복제본이 보낸 repliation id가 현재의 마스터와 일치하지 않다면 전체 재동기화 시도

• 복제본은 언제든지 마스터로 승격될 가능성을 갖고 있기 때문에 복제본에 직접 연결된 복제 연결이 따로 없더라도 백로그 버퍼를 해제하지 않음

  Secondary 복제 ID

• 한 개의 복제본 그룹 내의 모든 레디스 노드는 동일한 복제 ID 가짐

• 마스터 노드와의 복제가 끊어짐과 동시에 복제본은 새로운 복제 ID 가짐

• 기존의 복제 ID는 master_replid2에 저장

• 노드 C가 B에 복제 연결이 될 때, 두 노드의 master_replid2가 같기 때문에 C 노드는 B 노드에 부분 재동기화 시도

  레디스가 2개의 복제 ID를 갖는 이유는 마스터로 승격되는 복제본 때문이며, 같은 복제 그룹 내에서 페일오버 이후 승격된 새로운 마스터에 연결된 복제본은 전체 재동기화를 수행할 필요가 없을 수 있음

  읽기 전용 모드로 동작하는 복제본 노드

• replica-read-only

• 복제본에 직접 데이터를 쓸 수 있다하더라도 복제본에 쓰는 내용은 로컬에만 유지되며 다른 복제본으로 전파되지 않음

• 서브 복제보는 항상 최상위 마스터가 중간 복제본으로 보낸 것과 동일한 복제 프로토콜을 전달 받음

  유효하지 않은 복제본 데이터

• 유효하지 않은 데이터: 복제본의 데이터와 마스터의 데이터가 정확하게 일치하지 않는 경우의 데이터

  • 복제본이 마스터와 연결이 끊어진 상태
  • 복제 연결이 시작된 뒤 아직 완료되지 않았을 경우

• replica-serve-stale-data: 복제본의 데이터가 유효하지 않다고 판단될 때 복제본의 동작 방식 제어

  • yes: 유효하지 않다고 판단될 때에도 클라이언트로부터 들어오는 모든 읽기 요청에 데이터 반환
  • no: INFO, CONFIG, PING 등의 일부 기본 커맨드를 제외한 모든 커맨드에 대해 SYNC with master in progress 오류 반환

    백업을 사용하지 않는 경우에서의 데이터 복제

• 레디스에서 복제를 사용하는 경우 마스터와 복제본에서 백업 기능을 사용하는 것이 좋음

• 백업 기능을 사용하지 않으려면 재부팅 후 레디스가 자동으로 재시작되지 않도록 설정하는 것 권장

1. 백업 기능 사용하지 않는 마스터와 복제본 노드
2. 마스터가 장애로 인해 종료되었지만 레디스 프로세스를 자동 재시작하는 시스템에 의해 노드 재부팅. 메모리 노드 초기화
3. 복제본 노드에는 데이터가 존재하지만, 마스터 노드로의 복제 연결 시도
4. 마스터에서 복제본으로 빈 데이터셋 전달

레디스에서 모든 데이터는 메모리에서 관리된다. 메모리에 있던 모든 데이터는 손실될 가능성이 있다. 따라서 레디스를 영구 저장소와 같은 용도로 사용한다면 디스크에 데이터를 주기적으로 백업하는 것이 필요하다.

복제와 백업의 차이

• 복제: 가용성을 위한 것
• 백업: 장애 상황에서 데이터의 복구를 위한 것

레디스 백업 방식

• AOF(Append Only File): 레디스 인스턴스가 처리한 모든 쓰기 작업을 차례대로 기록. 복원 시에는 파일을 다시 읽어가며 데이터 세트 재구성
• RDB(Redis DataBase): 일정 시점에 메모리에 저장된 데이터 전체를 저장(snapshot 방식)

AOF

• 레디스 프로토콜(RESP) 형태로 저장됨
• 레디스에서 실행된 모든 쓰기 작업이 기록됨
• RDB 파일보다 크기가 크고 주기적으로 압축해 재작성해야 하지만, 원하는 시점으로 복구 가능

RDB

• 바이너리 형태로 저장
• 저장되는 시점의 메모리 데이터가 그대로 저장됨
• 시점 단위로 여러 백업본을 저장할 수 있고, AOF 파일보다 복원이 빠르다는 장점이 있지만 특정 시점으로의 복구는 불가능

레디스에서 데이터를 복원할 수 있는 시점은 서버가 재시작될 때뿐!! 레디스 인스턴스 실행 도중에 데이터 파일을 익어올 수 있는 방법은 없음

2. RDB 방식의 데이터 백업

특정 조건에 자동으로 RDB 파일 생성

save <기간(초)> <기간 내 변경된 키의 개수>
dbfilename <RDB 파일 이름>
dir <RDB 파일이 저장될 경로>

• 레디스 설정 파일에서 save 옵션을 사용해 원하는 조건에 RDB 파일을 저장하도록 설정
• 일정한 기간(초) 동안 변경된 키의 개수가 조건에 맞을 때 레디스 서버는 자동으로 RDB 파일 저장
• RBD 파일을 저장하고 싶지 않다면 save ""로 설정해 옵션 비활성화
• CONFIG SET: 실행 중인 레디스 인스턴스에서 설정 변경
• CONFIG REWRITE: 설정 파일 재작성
• 레디스 인스턴스가 실행 중인 상태에서 설정 파일을 변경하는 것은 실행 중인 레디스 인스턴스에는 반영되지 않음
  • CONFIG SET(설정 변경) -> CONFIG REWRITE(설정 파일 재작성) 과정을 거쳐야 함

    수동으로 RBD 파일 생성

• SAVE: 동기 방식으로 파일 저장
• BGSAVE: fork를 호출해 자식 프로세스를 생성하며 생성된 자식 프로세스가 백그라운드에서 RDB 파일을 생성한 뒤 종료
  • 이미 백그라운드로 데이터가 저장되고 있을 때 이 커맨드를 수행하면 에러 반환
  • SCHEDULE 옵션: 이미 파일이 백그라운드에서 저장 중일 때 이 커맨드를 입력받은 레디스는 일단 OK 반환한 뒤, 기존에 진행 중이던 백업이 완료됐을 때 다시 BGSAVE 실행
• LASTSAVE: RDB 파일이 정상적으로 저장됐는지 확인, 마지막으로 RDB 파일이 저장된 시점을 유닉스 타임스탬프로 반환

  복제를 사용할 경우 자동으로 RDB 파일 생성

• REPLICAOF: 복제본에서 이 커맨드를 이용해 복제를 요청하면 마스터 노드에서는 RDB 파일을 새로 생성해 복제본에 전달
• 복제 연결을 처음 시작했을 때뿐만 아니라 이미 복제 연결이 되어 있는 상태에서도 상황에 따라 마스터에서는 언제든지 RDB 파일을 재생성할 수 있음

  3. AOF 방식의 데이터 백업

AOF는 레디스 인스턴스에서 수행된 모든 쓰기 작업의 로그를 차례대로 기록

appendonly yes    // AOF 파일에 주기적으로 데이터 저장
appendfilename "appendonly.aof"
appenddirname "appendonlydir"

• AOF 파일에는 메모리상의 데이터가 변경되는 커맨드만 기록됨
• 항상 AOF 파일이 사용자가 실행한 커맨드를 그대로 저장하는 것은 아님
  • BRPOP -> RPOP
  • INCRBYFLOAT -> 증분 후의 값을 직접 SET
• AOF는 실행되는 커맨드가 파일 뒤쪽에 계속 추가되는 방식으로 동작하기 때문에 인스턴스가 실행되는 시간에 비례해서 파일 크기 계속 증가

  AOF 파일을 재구성하는 방법

• AOF 파일을 이용한 백업 기능을 안정적으로 사용하려면 점점 커지는 파일을 주기적으로 압축시키는 재구성(rewrite) 작업 필요
• 재구성은 레디스 메모리에 있는 데이터를 읽어와서 새로운 파일로 저장하는 형태로 동작
• aof-use-rdb-preamble yes -> RDB 파일 형태로 저장
• AOF 파일을 재구성할 때에도 fork를 이용해 자식 프로세스를 생성하며, 이 자식 프로세스가 AOF 파일을 재구성해 저장
• 버전 7 이전
  • AOF는 하나의 파일로 관리
  • RDB 파일이 저장되는 동안 데이터가 변경된 동일한 로그가 AOF와 인메모리 버퍼에 이중으로 저장됨
  • 하나의 AOF 파일 내에 바이너리 형태와 RESP의 텍스트 형태의 데이터가 함께 저장돼 수동으로 AOF 파일을 처리할 때 관리 복잡
• 버전 7 이후
  • AOF는 기본이 되는 바이너리 형태의 RDB 파일, 증가하는 RESP의 텍스트 형태의 AOF 파일로 나누어 데이터 관리
  • 현재 레디스가 바라보고 있는 파일이 어떤 것인지 나타내는 매니페스트 파일
• AOF 파일 재구성 과정은 모두 순차 입출력만 사용하기 때문에 디스크에 접근하는 모든 과정이 효율적
  • 파일 내에서 직접 데이터를 검색할 필요가 없기 때문에 랜덤 입출력을 고려할 이유 없음

    자동 AOF 재구성

• auto-aof-rewrite-percentage: AOF 파일을 다시 쓰기 위한 시점을 정하기 위한 옵션
• auto-aof-rewrite-min-size: 재구성된 이후의 AOF 파일의 최소 크기 지정 옵션
• 마지막으로 작성된 AOF 파일 크기를 기준으로 재구성하되, 적어도 AOF 파일이 특정 크기 이상일 때에만 재구성을 하도록 지정해 비효율적인 작업을 최소화

  수동 AOF 재구성

• BGREWRITEAOF: 원하는 시점에 직접 AOF 파일 재구성. 자동으로 재구성할 때와 동일하게 동작

  AOF 타임스탬프

• aof-timestamp-enabled 옵션을 활성화 시키면 AOF 데이터가 저장될 때 타임스탬프도 함께 저장됨
• redis-check-aof 프로그램을 사용해 데이터 복구

  AOF 파일 복원

• redis-check-aof 프로그램은 AOF 파일이 손생됐을 때도 사용 가능
• 의도치 않은 서버의 장애 발생 시 AOF 파일 작성 도중 레디스가 중지됐을 가능성 존재

  AOF 파일의 안전성

• 파일 저장 내구성 제어 옵션
  • APPENDFSYNC no: AOF 데이터를 저장할 때 WRITE 시스템 콜 호출. 데이터는 커널 영역에 데이터가 잘 저장되는지만 확인하기 때문에 쓰기 성능 가장 빠름
  • APPENDFSYNC always: AOF 데이터를 저장할 때 항상 WRITE와 FSYNC 시스템 콜 함께 호출. 매번 쓰고자 하는 데이터가 파일에 정확하게 저장되는 것을 기다리기 때문에 쓰기 성능 가장 느림
  • APPENDFSYNC everysec: 데이터를 저장할 때 WRITE 시스템 콜을 호출하며, 1초에 한번씩 FSYNC 시스템 콜을 호출. 성능은 no 옵션을 사용했을 때와 거의 비슷

    4. 백업을 사용할 때 주의할 점

• 인스턴스의 maxmemory 값은 실제 서버 메모리보다 여유를 갖고 설정하는 것이 좋음
• 레디스는 Copy-On-Write(COW) 방식을 이용해 메모리상의 데이터를 하나 더 복사하는 방법을 이용해 백업을 진행하면서도 클라이언트의 요청 사항을 받아 메모리의 데이터를 읽고 수정하는 작업 진행
• maxmemory 값을 너무 크게 설정한 경우(최악의 경우 기존 메모리 용량의 2배 사용), 레디스의 copy-on-write 동작으로 인해 OS 메모리가 가득차 OOM(Out Of Memory) 문제로 서버가 다운될 수 있음
• RDB 스냅샷을 저장하는 도중엔 AOF의 재구성 기능을 사용할 수 없고, AOF 재구성이 진행될 때에는 BGSAVE를 실행할 수 없음

1. 메시징 큐와 이벤트 스트림

메시징 큐

• 생산자(producer): 데이터를 생성
• 소비자(consumer): 데이터를 수신

이벤트 스트림

• 발행자(publisher): 데이터 생성
• 수신자(subscriber): 데이터 조회

메시징 큐 vs. 이벤트 스트림

1. 방향성
   • 메시징 쿠의 생산자는 소비자의 큐로 데이터를 직접 푸시하기 때문에 2개의 서비스에 같은 메시지를 보낼 때 2번 푸시해야 함
   • 이벤트 스트림에서 발행자는 스트림의 특정 저장소에 하나의 메시지를 보낼 수 있고, 메시지를 읽어가고자 하는 수신자들은 스트림에서 같은 메시지를 풀(pull)해 갈 수 있기 때문에 메시지를 복제해서 저장하지 않아도 됨
2. 데이터의 영속성
   • 메시징 큐에서는 소비자가 데이터를 읽어갈 때 큐에서 데이터 삭제
   • 이벤트 스트림에서 구독자가 읽어간 데이터는 바로 삭제되지 않고, 저장소의 설정에 따라 특정 기간 동안 저장됨

메시징 큐는 일대일 상황에서 한 서비스가 다른 서비스에게 동작을 지시할 때 유용 스트림은 다대다 상황에서 유리함

레디스를 메시지 브로커로 사용하기

• 레디스의 pub/sub 기능을 이용해 메시지 브로커 구현
• 레디스 pub/sub
  • 모든 데이터는 한 번 채널 전체에 전파된 뒤 삭제(일회성)
  • 메시지가 잘 전달됐는지 등의 정보 보장 X(fire-and-forget 패턴에 사용됨)
  • c.f) fire-and-forget 패턴: 비동기 프로그래밍에서 사용되는 디자인 패턴으로, 어떤 작업을 실행하고 그 결과에 대한 응답을 기다리지 않고 바로 다음 코드를 실행하는 것
• 레디스의 list와 stream을 이용해 각각 메시징 큐와 이벤트 스트림으로 사용하기 알맞음

2. 레디스의 pub/sub

• 레디스의 pub/sub은 매우 가볍기 때문에 최소한의 메시지 전달 기능만 제공
  • 발행자는 메시지를 채널로 보낼 수 있을 뿐, 어떤 구독자가 메시지를 읽어가는지, 정상적으로 모든 구독자에게 메시지가 전달됐는지 확인할 수 없음
  • 구독자는 메시지를 받을 수 있지만 해당 메시지가 언제 어떤 발행자에 의해 생성되었는지 등 메타데이터는 알 수 없음
  • 한 번 전파된 데이터는 레디스에 저장 X ➡️ 정합성이 중요한 데이터를 전달하기에는 적합하지 않음

클러스터 구조에서의 pub/sub

• 클러스터: 레디스가 자체적으로 제공하는 데이터 분산 형태의 구조
• 메시지를 발행하면 해당 메시지는 클러스터에 속한 모든 노드에 자동으로 전달
• 클러스터는 주로 대규모 서비스에서 데이터를 분산해서 저장하고 처리하기 위해 도입
• 레디스 클러스터 내에서 pub/sub을 사용할 때 메시지가 모든 레디스 노드에 복제되는 방식은 클러스터 환경의 핵심 목표와는 부합하지 않음 ➡️ 불필요한 리소스 사용, 네트워크 부하

  sharded pub/sub

• 각 채널은 슬롯에 매핑
• 클러스터에서 키가 슬롯에 할당되는 것과 동일한 방식으로 채널 할당, 같은 슬롯을 가지고 있는 노드 간에만 pub/sub 메시지 전파
• 클러스터 구조에서 pub/sub 되는 메시지는 모든 노드로 전파되지 않기 때문에 불필요한 복제를 줄여 자원 절약 가능

  3. 레디스의 list를 메시징 큐로 사용하기

list의 EX 기능

• SNS 타임라인의 경우 이미 캐시된(이미 키가 존재하는) 타임라인에만 데이터를 추가할 수 있음(자주 사용하지 않는 사람의 타임라인 캐시 데이터를 관리할 필요가 없음)
• 사용자의 캐시가 이미 존재하는지 유무를 애플리케이션에서 확인하는 불필요한 확인 과정이 없어 성능 향상 가능

  list의 블로킹 기능

• 이벤트 기반(event-driven) 구조: 이벤트 루프를 돌며 신규로 처리할 이벤트가 있는지 체크, 새로운 이벤트가 없을 경우 정해진 시간(polling interval) 동안 대기한 뒤 다시 이벤트 큐에 데이터가 있는지 확인하는 과정 반복(polling)
• 단점: 폴링 프로세스가 진행되는 동안 애플리케이션과 큐의 리소스가 불필요하게 소모, 폴링 인터벌 동안 대기한 뒤 다시 확인하는 과정을 거치기 때문에 이벤트를 즉시 처리할 수 없음
• BRPOP, BLPOP: list에 데이터가 있으면 즉시 반환, 만약 데이터가 없을 경우 기다려서 들어온 값을 반환 or 클라이언트가 설정한 타임아웃 시간 만큼 대기한 후 nil 반환

list를 이용한 원형 큐

• 특정 아이템을 반복 접근해야 하는 클라이언트, 혹은 여러 개의 클라이언트가 병렬적으로 같은 아이템에 접근 해야 하는 클라이언트의 경우 원형 큐(circular queue)를 이용해 아이템 처리
• RPOPPUSH

  4. Stream

레디스의 Stream과 아파치 카프카

• Stream: 대용량, 대규모의 메시징 데이터를 빠르게 처리할 수 있도록 설계됨, 데이터를 계속해서 추가하는 방식으로 저장되는(append-only) 자료 구조
• stream 활용
  • 백엔드 개발자들은 대량의 데이터를 효율적으로 처리하는 플랫폼으로 활용
  • 데이터 엔지니어들은 여러 생산자가 생성한 데이터를 다양한 소비자가 처리할 수 있게 지원하는 데이터 저장소 및 중간 큐잉 시스템으로 활용

스트림이란?

• 연속적인 데이터의 흐름, 일정한 데이터 조각의 연속

  데이터의 저장

  메시지의 저장과 식별

• 카프카
  • 토픽: 각각의 분리된 스트림, 같은 데이터를 관리하는 하나의 그룹
  • 각 메시지는 0부터 시작해 증가하는 시퀀스 넘버로 식별
  • 시퀀스 넘저는 토픽 내의 파티션 안에서만 유니크하게 증가하기 때문에 토픽이 1개 이상의 파티션을 갖는다면 메시지는 하나의 토픽 내에서 유니크하게 식별되지 않음
• 레디스 stream
  • 각 메시지는 시간과 관련된 유니크한 ID를 가지며, 이 값은 중복되지 않음

    스트림 생성과 데이터 입력

• 카프카
  • 각 스트림은 토픽으로 관리됨
  • 생성자는 데이터를 토픽에 푸시, 소비자는 토픽에서 데이터 읽음
  • 토픽 생성 후 프로듀서를 이용해 메시지 보냄
• 레디스 stream
  • 따로 stream을 생성하는 과정 필요 X
  • XADD 커맨드 이용
  • 데이터는 hash 자료 구조처럼 필드-값 쌍으로 저장되므로 각 메시지마다 유동적인 데이터 저장 가능

    데이터의 조회

• 카프카
  • 소비자는 특정 토픽을 실시간으로 리스닝하며, 새롭게 토픽에 저장되는 메시지를 받을 수 있음
• 레디스 stream
  • 실시간으로 처리되는 데이터 리스닝(XREAD)
  • ID를 이용해 필요한 데이터 검색(XRANGE, XREVRANGE)

    소비자와 소비자 그룹

• 팬아웃(fan-out): 같은 데이터를 여러 소비자에게 전달하는 것
• 같은 데이터를 여러 소비자가 나눠서 가져가기 위해서는?
  • 같은 역할을 하는 여러 개의 소비자를 이용해 메시지를 병렬 처리함으로써 서비스의 처리 성능을 높일 수 있음
• 레디스 stream
  • 데이터가 저장될 때마다 고유한 ID(시간)를 부여받아 순서대로 저장됨
  • 소비자에게 데이터가 전달될 때 순서 항상 보장(시간순)
• 카프카
  • 유니크 키는 파티션 내에서만 보장되기 때문에 소비자가 여러 파티션에서 토픽을 읽어갈 때에는 데이터의 순서를 보장할 수 없음
  • 데이터의 정렬이 보장되지 않기 때문에 메시지 순서 보장을 위해 소비자 그룹 사용

    소비자 그룹

• 카프카
  • 소비자 그룹에 여러 소비자 추가 가능
  • 소비자는 토픽 내의 파티션과 일대일로 연결됨
  • 파티션을 이용해 소비자의 부하 분산 관리
• 레디스 stream
  • 레디스 stream은 메시지가 전달되는 순서가 보장되기 때문에 카프카의 소비자 그룹과는 약간 다름
  • 소비자 그룹 내의 한 소비자는 다른 소비자가 아직 읽지 않은 데이터만을 읽어감
  • XGROUP: 소비자 그룹 생성
  • XREADGROUP: 소비자 그룹 이용해 데이터 읽음, 마스터에서만 호출 가능
  • stream의 상태를 나타내는 개념으로 간주
  • stream과 소비자 그룹은 독립적으로 동작 가능
  • 하나의 소비자 그룹에서 여러 개의 stream 리스닝 가능
  • 파티션이라는 분할 없이도 소비자 그룹이라는 개념을 이용해 여러 소비자에게 데이터 분산 가능

    ACK와 보류 리스트

  • 레디스 stream
    • 각 소비자별로 읽어간 메시지에 대한 리스트를 새로 생성하며, 마지막으로 읽어간 데이터의 ID로 last_delivered_id 값 업데이트(중복 전달 방지)
    • 보류 리스트를 이용해 소비자가 처리한 데이터 파악
    • 데이터가 처리됐다는 뜻의 ACK를 보내면 보류 리스트에서 해당 메시지 삭제
  • 카프카
    • 파티션별 오프셋 관리
    • __consumer_offsets: 소비자가 지정된 토픽의 특정 파티션의 메시지를 읽으면 소비자 그룹, 토픽, 파티션 내용이 통합되어 저장됨
    • 오프셋은 소비자가 다음으로 읽어야 할 위치(마지막으로 읽은 위치 X)

      레디스 stream의 메시지 보증 전략

  • at most once: 메시지를 최소 한 번 보내는 것, 메시지를 받자마자 실제 처리하기 전에 먼저 ACK 보냄
  • at least once: 받은 메시지를 모두 처리한 뒤 ACK, 실제로 메시지가 처리됐지만 ACK를 전송하기 전에 소비자가 종료되는 상황 발생 가능
  • exactly once: 모든 메시지가 무조건 한 번씩 전송되는 것 보장, 이미 처리된 메시지인지 아닌지를 확인하는 과정 필요

    메시지의 재할당

• XCLAIM: 메시지의 소유권을 다른 소비자에게 할당, 최소 대기 시간 지정
• 메시지가 보류 상태로 머무른 시간이 최소 대기 시간을 초과한 경우에만 소유권을 변경할 수 있도록 해서 같은 메시지가 2개의 다른 소비자에게 중복으로 할당되는 것 방지

  메시지의 자동 재할당

• XAUTOCLAIM
  • 소비자가 직접 보류했던 메시지 중 하나를 자동으로 가져와서 처리
  • 할당 대기 중인 다음 메시지의 ID를 반환하는 방식으로 동작하기 때문에 반복적 호출 가능
  • 지정한 소비자 그룹에서 최소 대기 시간을 만족하는 보류 중인 메시지가 있다면 지정한 소비자에게 소유권을 재할당하는 방식으로 동작

    메시지의 수동 재할당

• stream 내 각 메시지는 counter 값 가짐
• counter는 XREADGROUP을 이용해 소비자에게 할당하거나 XCLAIM을 이용해 재할당할 경우 1씩 증가
• counter가 특정 값에 도달하면 이 메시지를 특수한 다른 stream으로 보내, 관리자가 추후에 처리할 수 있도록 함 ➡️ dead letter

  stream 상태 확인

• XINFO
  • XINFO consumer: 특정 소비자 그룹에 속한 소비자의 정보
  • XINFO GROUPS: stream에 속한 전체 소비자 그룹 list
  • XINFO STREAM: stream 자체의 정보

캐시란?

캐시란 데이터의 원본보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소

애플리케이션이 다음 조건을 만족시킨다면 캐시를 도입했을 때 성능을 효과적으로 개선할 수 있음

• 원본 데이터 저장소에서 원하는 데이터를 찾기 위해 검색하는 시간이 오래 걸리거나, 매번 계산을 통해 데이터를 가져와야 함
• 캐시에서 데이터를 가져오는 것이 원본 데이터 저장소 데이터를 요청하는 것보다 빨라야 함
• 캐시에 저장된 데이터는 잘 변하지 않는 데이터
• 캐시에 저장된 데이터는 자주 검색되는 데이터

위 조건을 만족하는 이상적인 캐시는 애플리케이션이 직면하게 되는 많은 문제점 해결 가능

• 원본 데이터 저장소 데이터를 가지고 오는 시간을 단축시키기 때문에 애플리케이션의 응답 속도 줄일 수 있음
• 캐시는 데이터의 복제본을 저장하는 저장소이기 때문에 원본 데이터 저장소에서 데이터를 읽는 커넥션을 줄일 수 있음
• 캐시를 적절하게 배치함으로써 애플리케이션의 확장 가능
• 원본 데이터 저장소에서 데이터를 가져올 때 CPU와 메모리 등의 리소스를 많이 사용했다면 캐시를 사용함으로 애플리케이션 자체의 리소스를 줄일 수 있음
  • 같은 값을 도출하기 위해 같은 계산을 할 필요가 없으므로 리소스 최적화
• 중요한 데이터를 캐시에 올려두고 사용할 때 원본 데이터 저장소에 장애가 발생해 접근할 수 없은 상황이 발생하더라도 캐시에서 데이터를 가지고 올 수 있기 때문에 장애 시간을 줄일 수 있음

캐시로서의 레디스

1. 사용이 간단

• 키-값 형태로 저장하므로 데이터 저장 및 반환 간단
• 자체적으로 다양한 자료 구조를 제공해 애플리케이션에서 사용하던 자료 구조 변환 없이 바로 저장

2. 모든 데이터를 메모리에 저장하는 인메모리 데이터 저장소이기 때문에 데이터를 검색하고 반환하는 것이 빠름

• 평균 읽기 및 쓰기 작업 속도가 1ms 미만, 초당 수백만 건의 작업 가능

3. 자체적으로 고가용성 기능을 가지고 있는 솔루션

• 일부 캐싱 전략에서는 캐시에 접근할 수 없게 되면 서비스의 장애로 이어짐 ➡️ 캐시 저장소도 일반적인 데이터 저장소와 같이 안정적으로 운영될 수 있는 조건을 갖추는 것이 좋음
• 레디스의 센티널 또는 클러스터 기능을 사용하면 마스터 노드의 장애를 자동으로 감지해 페일오버를 발생시키기 때문에 운영자의 개입 없이 캐시는 정상으로 유지될 수 있어 가용성 높음

4. 클러스터를 사용하면 캐시의 스케일 아웃 쉽게 처리 가능

• 자체 샤딩 솔루션인 클러스터를 사용하면 수평 확장이 간단해짐

캐싱 전략

읽기 전략 - look aside

• 애플리케이션에서 데이터를 읽어갈 때 주로 사용하는 전략
• 캐시 히트(cache hit): 애플리케이션은 찾고자 하는 데이터가 먼저 캐시에 있는지를 확인한 뒤, 캐시에 데이터가 있으면 캐시에서 데이터를 읽어옴
• 캐시 미스(cache miss): 찾고자 하는 데이터가 캐시에 없음
• 레디스에 문제가 생겨 접근을 할 수 없는 상황이 발생하더라도 바로 서비스 장애로 이어지지 않고 데이터베이스에서 데이터를 가지고 올 수 있음
• 기존에 애플리케이션에서 레디스를 통해 데이터를 가져오는 연결이 매우 많았다면 모든 커넥션에 한꺼번에 원본 데이터베이스로 몰려 많은 부하 발생 ➡️ 원본 데이터베이스의 응답이 느려지거나 리소스를 많이 차지하는 이슈
• lazy loading: 찾고자 하는 데이터가 레디스에 없을 때에만 레디스에 데이터가 저장됨
• 기존 사용 중인 서비스에 처음 레디스를 투입하거나 데이터베이스에만 새로운 데이터를 저장하는 경우 매번 캐시 미스가 일어나 성능 저하 ➡️ 캐시 워밍을 통해 해결
  • 캐시 워밍(cache warming): 미리 데이터베이스에서 캐시로 데이터를 밀어넣어주는 작업

쓰기 전략과 캐시의 일관성

캐시에 원본 데이터와 동일한 값을 갖도록 유지하는 것이 필수적! 캐시 불일치(cache inconsitency): 데이터가 변경될 때 원본 데이터베이스에만 업데이트 되어 캐시에는 변경된 값이 반영되지 않아 데이터 간 불일치가 발생한 것

1. write through

• 데이터베이스에 업데이트할 때마다 매번 캐시에도 데이터를 함께 업데이트 시키는 방식
• 캐시는 항상 최신 데이터를 가지고 있을 수 있다는 장점
• 데이터는 매번 2개의 저장소에 저장되어야 하기 때문에 데이터를 쓸 때마다 시간이 많이 소요될 수 있다는 단점
• 다시 사용되지 않을 데이터가 매번 업데이트 될 수 있기 때문에 데이터를 저장할 때 만료 시간을 사용하는 것이 좋음

2. cache invalidation

• 데이터베이스에 값을 업데이트할 때마다 캐시에서는 데이터를 삭제하는 전략
• 저장소에서 특정 데이털르 삭제하는 것이 새로운 데이터를 저장하는 것보다 훨씬 리소스를 적게 사용

3. write behind(write back)

• 먼저 데이터를 빠르게 접근할 수 있는 캐시에 업데이트한 뒤, 이후에는 건수나 특정 시간 간격 등에 따라 비동기적으로 데이터베이스에 업데이트
• 저장되는 데이터가 실시간으로 정확한 데이터가 아니어도 되는 경우에 사용

캐시에서의 데이터 흐름

캐시는 가득 차지 않게 일정 양의 데이터를 유지해야 하며 계속해서 새로운 데이터가 저장되고 기존 데이터는 삭제될 수 있도록 관리해야 함 ➡️ 적절한 시간의 TTL을 지정하는 것이 좋음

만료 시간

• 초(second) 단위로 표현
• 키에 만료 시간을 설정하면 데이터의 수명을 관리하고 메모리 공간을 효율적으로 사용하는 데 도움을 줌
• 만료 시간 설정
  • EXPIRE 커맨드: 만료 시간 설정(초 단위로 동작)
  • SET 커맨드의 EX 옵션: 데이터의 저장과 동시에 만료 시간을 설정
  • TTL 커맨드: 만료 시간 확인(초 단위로 동작)
  • PTTL, PEXPIRE 커맨드는 밀리세컨드 단위로 동작
  • INCR 커맨드로 데이터를 조작하거나 RENAME을 이용해 키의 이름을 바꾸더라도 설정된 만료 시간은 변경되지 않음
  • 기존 키에 새로운 값을 저장해 키를 덮어 쓸 때에는 이전에 설정한 만료 시간은 유지되지 않고 사라짐

레디스에서 키가 만료되었다고 해도 바로 메모리에서 삭제되는 것은 아님. 만료된 키를 곧바로 삭제하지 않기 때문에 키를 삭제하는 데 들어가는 리소스를 줄일 수 있지만, 그 만큼 메모리를 더 사용할 가능성 존재.

• passive 방식
  • 클라이언트가 키에 접근하고자 할 때 키가 만료되었다면 메모리에서 수동적으로 삭제
• active 방식
  • TTL 값이 있는 키 중 20개를 랜덤하게 뽑아낸 뒤, 만료된 키를 모두 메모리에서 삭제
  • 만약 25% 이상의 키가 삭제되었다면 다시 20개의 키를 랜덤하게 뽑은 뒤 확인하고, 아니라면 뽑아놓은 20개의 키 집합에서 다시 확인

메모리 관리와 maxmemory-policy 설정

Noeviction

• 기본값
• 레디스에 데이터가 가득 차더라도 임의로 데이터를 삭제하지 않고 더 이상 레디스에 데이터를 저장할 수 없다는 에러 반환
• 캐시에 데이터를 저장하지 못해 에러가 발생할 경우 관리자가 데이터를 직접 지워야 함
• 데이터의 관리를 캐시에 맡기지 않고, 애플리케이션 측에서 관리

  LRU(Least-Recently Used) eviction

• 레디스에 데이터가 가득 찼을 때 가장 최근에 사용되지 않은 데이터부터 삭제하는 정책
• 최근에 액세스 되지 않은 데이터는 나중에도 액세스 될 가능성이 낮을 것이라는 가정을 전제
• 근사 알고리즘 이용
• volatile-lru
  • 만료 시간이 설정되어 있는 키에 한해서 LRU 방식으로 키를 삭제
  • 만약 레디스 내부에 저장된 키에 모두 만료 시간이 지정되어 있지 않다면 noeviction 상황과 동일
• allkeys-lru
  • 모든 키에 대해 LRU 알고리즘을 이용해 데이터를 삭제하기 때문에 메모리가 꽉 차있을 때 장애가 발생할 상황 방지

    LFU(Least-Frequently Used) eviction

• 레디스에 데이터가 가득 찼을 때 가장 자주 사용되지 않은 데이터부터 삭제하는 정책
• 자주 사용되지 않은 데이터는 나중에도 액세스될 가능성이 낮을 것이라는 가정 전제
• 근사 알고리즘 이용
• volatile-lfu
  • 만료 시간이 설정되어 있는 키에 한해서 LFU 방식으로 키를 삭제
• allkeys-lfu
  • 모든 키에 대해 LFU 알고리즘을 이용해 데이터 삭제

    RANDOM eviction

• 레디스에 저장된 키 중 하나를 임의로 골라내 삭제
• 삭제될 키 값을 계산하지 않아도 된다는 점에서 부하를 줄여줌
• 랜덤으로 데이터를 삭제하기 때문에 나중에 사용될 수도 있는 데이터를 삭제할 가능성이 높아짐 ➡️ 데이터 저장소에서 다시 데이터를 가지고 와서 캐시에 넣어주는 작업 불필요
• 굳이 레디스의 부하를 줄이기 위한다는 이유로 사용하는 것을 권장하지 않음
• volatile-random: 만료 시간이 설정되어 있는 키에 한해 랜덤하게 키 삭제
• allkeys-random: 모든 키에 대해 랜덤하게 키 삭제

  volatile-ttl

• 만료 시간이 가장 작은 키 삭제
• 근사 알고리즘 이용

캐시 스탬피드 현상

캐시 스탬피드(cache stampede): 캐시 공간은 한정되어 있으므로 저장된 데이터에 만료 시간을 설정하는데, 해당 데이터에 계속 읽기 요청이 들어오고 있을 때 캐시 만료시간이 닥치면 순간적으로 데이터베이스에 그 읽기 요청이 집중되고 그게 다시 레디스에 중복된 쓰기 요청으로 몰리게 됨

• 중복 읽기(duplicate read): 여러 애플리케이션에서 바라보던 키가 만료되어 삭제된다면 이 서버들은 한꺼번에 데이터베이스에 가서 데이터를 읽어옴
• 중복 쓰기(duplicate write): 중복 읽기 이후 각 애플리케이션에서 읽어온 데이터를 레디스에 쓰게 되면 여러 번 반복해서 쓰게 됨

한번 캐시 스탬피드 현상이 발생하면 결과적으로 더 많은 데이터가 이 현상의 영향을 받게 됨 ➡️ 계단식 실패(cascading failure)

계단식 실패를 줄이기 위한 방법

1. 적절한 만료 시간 설정

• 여러 애플리케이션에서 한꺼번에 접근해야 하는 데이터이며, 반복적으로 사용되어야 하는 데이터라면 저장 시점부터 만료 시간을 충분히 길게 설정

2. 선 계산

• 키가 실제로 만료되기 전에 이 값을 미리 갱신해준다면 여러 애플리케이션에서 한꺼번에 데이터베이스에 접근해 데이터를 읽어오는 과정을 줄여 불필요한 프로세스 줄임

3. PER 알고리즘

• PER(Probabilistic Early Recomputation) 알고리즘을 이용하면 캐시 값이 만료되기 전에 언제 데이터베이스에 접근해서 값을 읽어오면 되는지 최적으로 계산할 수 있음
• currentTime - ( timeToCompute * beta * log(rand()) ) > expiry
  • currentTime: 현재 남은 만료 시간
  • timeToCompute: 캐시된 값을 다시 계산하는 데 걸리는 시간
  • beta: 기본적으로 1.0 보다 큰 값으로 설정 가능
  • rand(): 0과 1 사이의 랜덤 값을 반환하는 함수
  • expiry: 키를 재설정할 때 새로 넣어줄 만료 시간
  • currentTime에서 timeToCompute x beta x log(rand())를 빼서 얻은 값이 expiry 보다 크면 조건은 거짓(False)
  • currentTime에서 timeToCompute x beta x log(rand())를 빼서 얻은 값이 expiry 보다 작으면 조건은 참(True)
    • 데이터를 다시 계산하기 위해 데이터베이스로 이동
    • 만료 시간이 가까워질수록 currentTime과 expiry 사이의 차이가 작아지며, rand() 함수가 반환한 무작위 값에 의존하기 때문에 조건이 참이 될 확률 높아짐
  • 데이터를 가져오는 과정에서 GET 대신 이 함수를 사용하는 것은 캐시 스탬피드 현상을 줄이고 성능을 최적화하는데 도움

세션 스토어로서의 레디스

세션이란?

세션(session): 서비스를 사용하는 클라이언트의 상태 정보

세션 스토어가 필요한 이유

• sticky session: 특정 웹 서버에 유저가 몰려 트래픽이 집중되는 상황이 발생하더라도 유저는 다른 서버를 사용할 수 없어, 결국 트래픽을 분산시킬 수 없는 상황
• all-to-all 방법: 유저의 세션 정보를 모든 웹 서버에 복제해서 저장하는 방법
  • 유저를 여러 웹 서버에 분산시킬 수 있지만, 유저의 세션 데이터를 여러 서버로 복사되어 저장되기 때문에 불필요한 저장 공간 차지
  • 하나의 유저는 한 번에 하나의 웹 서버에만 접속하기 때문에 다른 웹 서버에 저장된 유저의 세션 정보는 무의미
  • 데이터를 복제하는 과정에서 불필요한 네트워크 트래픽 다수 발생
• 데이터베이스를 세션 스토어로 이용
  • 세션 스토어의 응답 속도가 느려지면 클라이언트의 응답 속도 저하로 이어짐
• 레디스를 세션 스토어로 이용
  • 레디스를 세션 스토어로 사용하고 서버, 데이터베이스와 분리시켜 놓은 뒤 여러 서버에서 세션 스토어를 바라보도록 구성
  • 유저는 세션 스토어에 구애받지 않고 어떤 웹 서버에 연결되더라도 동일한 세션 데이터 조회 가능 ➡️ 트래픽 효율적 분산, 데이터의 일관성 고려할 필요X
  • 레디스는RDBMS보다 훨씬 빠르고 접근하기 간편하므로 데이터를 가볍게 저장할 수 있음
  • 레디스의 hash 자료 구조는 세션 데이터 저장에 알맞음

    캐시와 세션의 차이

• 캐시에 저장된 데이터는 여러 애플리케이션에서 함께 사용
• 세션 스토어에 저장된 데이터는 여러 사용자 간 공유되지 않으며, 특정 사용자 ID에 한해 유효

레디스 자료 구조에 내장된 함수를 이용해 원하는 기능을 사용하면 데이터를 애플리케이션의 메모리 영역으로 가져간 뒤 가공하는 데에 걸리는 시간을 줄일 수 있기 때문에 애플리케이션에서는 매우 짧은 대기 시간으로 엄청난 양의 작업을 처리할 수 있음

레디스 자료 구조 활용 사례

sorted set을 이용한 실시간 리더보드

• 리더보드는 사용자의 스코어를 기반으로 데이터를 정렬하는 서비스이기 때문에 사용자의 증가에 따라 가공 데이터 증가
• 리더보드는 실시간으로 반영되어야 하는 데이터
• 레디스의 sorted set에서 데이터는 저장될 때부터 정렬되어 들어감
• 유저의 스코어를 sorted set의 가중치로 설정한다면 스코어를 기준으로 유저가 정렬됨 ➡️ 리더보드 데이터를 읽어오기 위해 매번 데이터 정렬할 필요 X
• sorted set은 기본적으로 set이기 때문에 데이터가 중복 저장되지 않으며, 같은 아이템을 저장하고자 할 때 스코어가 다르면 기존 데이터의 스코어만 신규 입력한 스코어로 업데이트 됨

sorted set을 이용한 최근 검색 기록

• RDBMS에서 최근 검색 기록을 가져올 때 검색한 시점을 기준으로 소팅(sorting)을 해야하기 때문에 사용자와 검색 기록이 늘어날 수록 많은 데이터를 테이블에서 관리해야 한다는 문제점 있음
• sorted set은 중복을 허용하지 않으며, 유저가 검색한 시간을 스코어로 사용하면 검색 기록으로 정렬될 수 있음
• sorted set의 음수 인덱스를 사용해서 매번 데이터를 저장할 때 아이템의 개수를 확인하고 삭제해야 하는 번거로움을 줄일 수 있음

sorted set을 이용한 태그 기능

• 포스트 id를 기준으로 하는 set에 태그를 데이터로 넣어 특정 게시물이 어떤 태그와 연관되어 있는지 확인
• 태그를 기준으로 하는 set에 포스트 id를 데이터로 넣어 특정 태그를 포함한 게시물 확인

랜덤 데이터 추출

• RDBMS에서 랜덤 데이터 추출을 사용할 때 ORDER BY RAND() 함수를 사용
• ORDER BY RAND()는 쿼리의 결과값을 랜덤하게 정렬하지만, 조건 절에 맞는 모든 행을 읽은 뒤, 임시 테이블에 넣어 정렬한 다음 랜덤으로 limit에 해당할 때까지 데이터 추출 ➡️ 데이터가 1만건 이상일 경우 부하 매우 많아짐
• 레디스를 사용하면 O(1)의 시간 복잡도를 이용해 랜덤한 데이터 추출 가능
• HRANDFIELD(hash), SRANDMEMBER(set), ZRANDMEMBER(sorted set)

레디스에서의 다양한 카운팅 방법

좋아요 처리하기

• 좋아요를 누를 때마다 RDBMS의 테이블의 특정 행에서 좋아요 개수 데이터를 증가시키는 것은 데이터베이스에 직접적인 영향을 끼침
• 또한 하나의 유저는 같은 댓글에 한 번씩만 좋아요를 누를 수 있음
• 댓글 id을 기준으로 set을 생성한 뒤, 좋아요를 누른 유저의 id를 set에 저장하면 중복 없이 데이터 저장 가능

읽지 않은 메시지 수 카운팅하기

• 채팅 메시지가 도착할 때마다 RDBMS에 업데이트 하는 대신 인메모리 데이터베이스에 일시적으로 저장한 뒤 필요한 시점에 한꺼번에 업데이트하면 부하를 줄이고 성능 향상됨
• 사용자의 id를 키로 하고, 채널의 id를 아이템의 키로 활용해 숫자 형태의 메시지 카운트를 관리

DAU(Daily Active User) 구하기

• DAU는 하루 동안 서비스에 방문한 사용자의 수를 의미하며, 하루에 여러번 방문했다 하더라도 한 번으로 카운팅 됨
• 레디스의 비트맵을 이용해 사용자의 id를 하나의 비트로 표현
• 날짜를 키로 하고 사용자가 방문했으면 해당 사용자의 id에 해당하는 비트를 1로 설정

hyperloglog를 이용한 애플리케이션 미터링

• 클라우드 컴퓨팅의 미터링 솔루션은 사용자의 서비스 사용 내역을 이용하기 때문에 대용량 데이터를 처리할 수 있어야 함
• 미터링 솔루션은 높은 처리량과 낮은 대기 시간을 가져야 함
• 다음 조건을 만족한다면 레디스의 hyperloglog를 사용하는 것을 고려해볼 수 있음
  • 집합 내의 유일한 데이터의 개수를 카운팅해야 함
  • 1% 미만의 오차는 허용 가능함
  • 카운팅할 때 사용한 정확한 데이터를 다시 확인하지 않아도 됨
• 로그 수집, 검색, 조회 서비스에서 각 유저를 구분하는 id를 키로 사용하고 API를 호출할 때마다 저장되는 로그의 식별자를 hyperloglog에 저장

Geospatial Index를 이용한 위치 기반 애플리케이션 개발

위치 데이터란

• 모바일 기기의 확산으로 위치 데이터와 같은 공간 데이터 처리가 점점 중요해지고 있음
• 위치 데이터는 경도와 위도(x, y) 좌표 쌍으로 표현
• 데이터 저장소의 역할
  • 사용자의 현재 위치 파악
  • 사용자의 이동에 따른 실시간 변동 위치 업데이트
  • 사용자의 위치를 기준으로 근처의 장소 검색

레디스에서의 위치 데이터

• geo set
  • 위치 공간 관리에 특화된 데이터 구조로, 각 위치 데이터는 경도와 위도의 쌍으로 저장됨
  • 데이터는 내부적으로 sorted set 구조로 저장됨

레디스의 자료 구조

string

• 최대 512MB의 문자열 데이터 저장 가능
• 이진 데이터를 포함하는 모든 종류의 문자열이 binary-safe하게 처리 ➡️ JPEG 이미지와 같은 바이트 값, HTTP 응답값 등의 다양한 데이터 저장 가능
• 키와 실제 저장되는 아이템이 일대일로 연결

command	설명	옵션
SET	데이터 저장	NX, XX
GET	데이터 조회
INCR	저장된 데이터 1씩 증가
INCRBY	입력한 값 만큼 데이터 증가
DECR	저장된 데이터 1씩 감소
DECRBY	입력한 값 만큼 데이터 감소
MSET	여러 데이터 한번에 저장
MGET	여러 데이터 한번에 조회
## list
- 순서를 가지는 문자열의 목록
- 하나의 list에 최대 42억여개의 아이템 저장 가능
- 스택과 큐로 사용
- LPUSH, RPUSH, LPOP, RPOP ➡️ O(1)
- 인덱스나 데이터를 이용해 list의 중간 데이터에 접근할 때는 ➡️ O(n)

set

• 정렬되지 않은 문자열의 모음
• 교집합, 합집합, 차집합 등의 집합 연산과 관련한 커맨드 제공
• 객체 간의 관계를 계산하거나 유일한 원소를 구해야 할 경우에 사용됨

sortedSet

• 스코어(score) 값에 따라 정렬되는 고유한 문자열의 집합
• 모든 아이템은 스코어-값 쌍을 가지며, 저장될 때부터 스코어 값으로 정렬되어 저장됨
• 같은 스코어를 가진 아이템을 데이터의 사전 순으로 정렬
• list에서 인덱스를 이용해 데이터에 접근하는 것은 O(n)으로 처리되지만, sorted set에서는 O(log(n))으로 처리됨

비트맵

• string 자료구조에 bit 연산을 수행할 수 있도록 확장한 형태
• 저장 공간을 획기적으로 줄일 수 있다는 장점이 있음

Hyperloglog

• 집합의 원소 개수인 카디널리티를 추정할 수 있는 자료 구조
• 대량 데이터에서 중복되지 않는 고유한 값을 집계할 때 유용
• 입력되는 데이터 그 자체를 저장하지 않고 자체적인 방법으로 데이터를 변경해 처리
• 저장되는 데이터 개수에 구애받지 않고 계속 일정한 메모리를 유지할 수 있으며, 중복되지 않는 유일한 원소의 개수 계산 가능
• 최대 12KB 크기
• 카디널리티 추정 오차 0.81%로 비교적 정확하게 데이터 추정 가능

Geospatial

• 경도, 위도 데이터 쌍의 집합
• 내부적으로 데이터는 sorted set으로 저장되며, 하나의 자료 구조 안에 키는 중복되어 저장되지 않음

stream

• 레디스를 메시지 브로커로서 사용할 수 있게 하는 자료 구조
• 카프카에서 영향을 받아 만들어짐
• 소비자 그룹 개념을 도입해 데이터를 분산 처리할 수 있는 시스템
• 데이터를 계속해서 추가하는 방식(append-only)로 저장 ➡️ 실시간 이벤트 or 로그성 데이터의 저장에 사용

레디스에서 키를 관리하는 법

키의 자동 생성과 삭제

1. 키가 존재하지 않을 대 아이템을 넣으면 아이템을 삽입하기 전에 빈 자료 구조 생성
   • 저장하고자 하는 키에 다른 자료 구조가 이미 생성되어 있을 때 아이템을 추가하는 작업은 에러 반환
2. 모든 아이템을 삭제하면 키도 자동으로 삭제됨(stream은 예외)
3. 키가 없는 상태에서 키 삭제, 아이템 삭제, 자료 구조 크기 조회 같은 읽기 전용 커맨드를 수행하면 에러를 반환하는 대신 키가 있으나 아이템이 없는 것 처럼 동작

키와 관련된 커맨드

모놀리틱 아키텍처

전체 애플리케이션을 하나의 통합된 패키지로 개발, 배포하는 방식

• 작은 규모의 프로젝트나 애플리케이션에서 운영 쉬움
• 서비스 규모가 확장되면서 유지보수의 복잡도 증가
• 한 개의 시스템에 문제가 발생하면 전체 시스템의 장애로 이어짐
• 하나의 모듈을 수정하면 전체 애플리케이션 다시 배포해야하며 배포 시간 길어짐
• 요구 사항 변경에 유연하게 대처하기 힘듦
• 하나의 시스템에서 리소스가 부족해 확장이 필요하면 전체 시스템을 확장할 수 밖에 없어 리소스 낭비

  마이크로서비스 아키텍처

독립된 각각의 모듈을 조립해 하나의 서비스를 만드는 아키텍처 기능별로 작게 나뉘어진 서비스가 독립적으로 동작하는 서비스

• 새로운 기능을 추가해 배포하는 것이 비교적 편리해 요구사항에 민첩하게 대처 가능
• 서비스 확장이 필요할 때 원하는 서비스만 업그레이드 가능해 서비스 관리 유연
• 서비스 간의 독립성으로 인해 한 서비스에서의 문제가 다른 서비스에 영향을 주지 않아 운영의 안정성 향상
• 소규모 팀에서는 서비스 분리로 인한 관리의 복잡도와 운영 부담 증가

데이터 저장소 요구 사항의 변화

• 모놀리틱 아키텍처에서는 중앙 집약적인 관계형 데이터베이스(RDBMS)가 표준
• 최근 서비스에서 비정형 데이터(다차원적, 깊은 계층 구조) 증가 ➡️ 관계형 데이터베이스의 정형화된 테이블에서는 관리 어려움
• NoSQL의 경우 개발 팀이 바로 데이터 구조를 바꿀 수 있어 더 빠른 개발 가능

마이크로서비스 아키텍처에서 가장 중요한 것은 각 서비스가 독립적으로 동작할 수 있도록 하나의 서비스가 다른 서비스들과 밀접하게 연관되지 않아야 한다는 것!

• 마이크로서비스 아키텍처의 각각의 서비스는 스스로의 상태를 유지해야 하고, 독립된 데이터 저장소 필요

NoSQL이란?

SQL을 사용하지 않는 데이터 저장소

• 관계가 정의되어 있지 않은 데이터를 저장

NoSQL의 특징

1. 실시간 응답

• 마이크로서비스 내의 저장소에서는 빠른 응답 속도가 중요
• 각각의 개별 서비스가 빠르게 동작하지 않으면 서비스 자체가 병목 현상을 유발할 수 있음

  2. 확장성

• 트랜잭션의 증가에 유연하게 확장

  3. 고가용성

• 장애 상황에서 신속하게 복구되어 항상 사용할 수 있는 상태 유지

  4. 클라우드 네이티브

• 클라우드 제공 업체에서 제공하는 DBaas(DataBase-as-a-service)를 사용하면 직접 설치, 운영할 필요 없이 설치된 상품을 바로 사용 가능

  5. 단순성

• 마이크로서비스 아키텍처 서비스가 세분화 될수록 관리 포인트가 늘어나기 때문에 개발자와 운영자는 데이터 저장소를 간단하게 사용하고 싶어함
• 한 가지의 데이터 모델이 모든 서비스에 최적화되진 않기 때문에 서비스별로 적절한 데이터 모델(멀티 모델 데이터베이스) 사용을 원함

  6. 유연성

• NoSQL은 비정형 데이터를 저장할 수 있는 방법 제공

NoSQL 데이터 저장소 유형

그래프 유형

• 엔티티 간의 관계를 효율적으로 저장하도록 설계됨
• 노드(node), 엣지(edge), 속성(properties)
• 저장되는 속성의 크기가 크거나 혹은 매우 많은 속성을 저장할 때에는 적합하지 않은 경우가 많음
• 추천 서비스, 사기 감지, 소셜미디어, 네트워크 및 IT 운영 등에 필요

칼럼 유형

• 열(column)은 기준으로 저장
• 칼럼 지향적(column-oriented), 와이드 칼럼(wide column)
• 데이터는 하나의 열에 중첩된 키-값 형태로 저장될 수 있기 때문에 기존의 관계형 데이터베이스와 비교했을 때보다 유연한 스키마를 저장할 수 있음
• 대량의 데이터에 대한 집계 쿼리를 다른 유형보다 빠르게 처리 가능
• 기업의 BI 분석을 위한 데이터 웨어하우스, 분석, 보고, 빅데이터 처리에 적합
• Apache Cassandra, HBase 등

문서 유형

• JSON 형태로 데이터 저장 가능
• 스키마가 따로 정해져 있지 않기 때문에 애플리케이션에 맞게 데이터를 그대로 저장할 수 있어 유연성이 큼
• 모든 값은 항상 키와 연결되는 계층적 트리와 같은 구조를 가짐
• 데이터를 저장하거나 검색하는 데 효과적
• MongoDB, CouchDB, AWS의 DocumentDB 등

키-값 유형

• 가장 단순하고 빠름
• 모든 값은 키에 연결되어 있고, 키 자체도 유의미한 데이터
• 데이터 저장이 간단하기 때문에 수평적 확장 쉬움
• 구조의 단순성으로 인해 빠른 데이터 액세스와 처리 속도 보장
• 실시간 서비스(게임, IoT), 로그 남기는 작업, 대규모 세션 실시간 관리 등
• Redis, AWS의 ElastiCache, AWS의 DynamoDB, Oracle NoSQL Database, Memcached 등

레디스란?

Remote dictionary server 고성능 키-값 유형의 인메모리 NoSQL 데이터베이스로, 오픈 소스 기반의 데이터 저장소

레디스의 특징

1. 실시간 응답(빠른 성능)

• 온디스크(disk-based) 데이터베이스: 데이터가 영구적으로 디스크에 저장됨
• 디스크에 저장된 데이터는 페이지 단위로 메모리에 올려 메모리에서 데이터를 찾고, 없는 경우 다른 페이지를 디스크에서 가져와 메모리에 올린 뒤 찾는 과정 반복
• HDD와 SSD와 같은 디스크에 접근하는 속도는 RAM과 같은 메모리에 접근하는 속도보다 현저히 느림
• 디스크에 접근하는 빈도가 증가할 수록 시스템 성능 저하
• 인메모리(in-memory) 데이터베이스: 모든 데이터가 컴퓨터의 메모리에서 관리됨
• 인메모리 데이터베이스는 디스크에 접근하는 과정이 필요 없기 때문에 데이터의 처리 성능이 빠름

2. 단순성

• 키에 매핑되는 값에는 문자열, hash, set 등 다양한 데이터 구조를 저장할 수 있도록 지원
• 문자열, hash, set과 같은 데이터 타입은 프로그래밍의 기본 자료 구조와 밀접한 관련이 있어 추가적인 데이터의 가공 없이 애플리케이션에서 쉽게 사용 가능
• 레디스는 내장된 다양한 자료구조를 통해 임피던스 불일치 해소
  • 임피던스 불일치(impedance mismatches): 기존 관계형 데이터베이스의 테이블과 프로그래밍 언어 간 데이터 구조, 기능의 차이로 인해 발생하는 충돌
• 100개가 넘는 오픈 소스 클라이언트 사용 가능
• Java, Python, PHP, C, C++, JavaScript, Node.js, R, Go를 비롯한 다수의 언어 지원

• 레디스는 싱글 스레드로 동작(메인 스레드 1개 + 별도의 스레드 3개)
• 클라이언트의 커맨드를 처리하는 부분은 이벤트 루프를 이용한 싱글 스레드로 동작
• 최소 하나의 코어만 있어도 레디스를 사용할 수 있기 때문에 배포가 쉽고, CPU가 적은 서버에서도 좋은 성능을 낼 수 있음
• 동기화나 잠금 매커니즘 없이도 안정적이고 빠르게 사용자의 요청 처리 가능
• 싱글 스레드로 동작한다는 것은 한 사용자가 오래 걸리는 커맨드를 수행한다면, 다른 사용자는 그 쿼리가 완료될 때까지 대기해야 한다는 것
• 레디스는 메모리에서 동작하기 때문에 대부분의 커맨드는 빠른 응답 시간을 갖지만 반환이 느린 특정 커맨드 존재

  3. 고가용성

• 자체적으로 HA(High Availability) 기능 제공
• 복제를 통해 데이터를 여러 서버에 분산시킬 수 있음
• 센티널(sentinel)은 장애 상황을 탐지해 자동으로 페일오버(failover) 시켜줌
• 마스터에 장애가 발생하면 복제를 새로운 마스터로 승격시켜 레디스로의 엔드포인트를 변경할 필요 없이 페일오버 완료됨

  4. 확장성

• 데이터는 레디스 클러스터 내에서 자동을 샤딩된 후 저장되며, 여러 개의 복제본이 생성될 수 있음
  • 샤딩(sharding): 각 데이터를 특정 조건에 따라서 서버를 분산 저장하는 기법
• 애플리케이션에서는 대상 데이터가 어떤 샤드에 있는지 신경쓰기 않아도 됨
• 클러스터 구조에서 모든 레디스 인스턴스는 클러스터 버스를 통해 서로 감시 ➡️ 마스터 노드에 문제가 발생하면 자동을 페일오버 시켜 고가용성 유지

  5. 클라우드 네이티브-멀티 클라우드

• 클라우드 네이티브
  • 클라우드 환경에 특화된 애플리케이션의 개발 및 운영 방식
  • 마이크로서비스, 컨테이너, 오케스트레이션, 데브옵스와 같은 현대의 개발 및 운영 패러다임 포용
  • 빠른 배포와 확장성, 높은 복원력을 중심으로 한 애플리케이션 추구
  • 빠른 데이터 액세스 및 처리를 지원하는 구조로 인해, 마이크로서비스 아키텍처와의 연계에서 큰 장점 지님
• 멀티 클라우드
  • 여러 클라우드 제공업체의 서비스를 동시에 혹은 혼합해 활용하는 전략
  • 단일 클라우드 환경의 장애나 제한된 자원에 대한 의존성을 줄이며, 각 클라우드 서비스 제공자의 강점을 활용할 수 있게 해줌
  • 데이터가 특정 지역이나 국가 내에 물리적으로 위치하도록 조절할 수 있어 더 가까운 저장소에서 데이터를 처리하게 되므로 대기 시간을 줄이고 장애 상황에 더욱 강건하게 대응 가능
  • 레디스는 여러 클라우드 환경에 걸쳐 일관된 성능과 기능을 제공함으로써 서비스의 연속성과 데이터의 일관성 보장

마이크로서비스 아키텍처와 레디스

데이터 저장소로서의 레디스

• 마이크로서비스 아키텍처에서 각 서비스별 개별 저장소로 사용
• 설치 간편, 최소한의 리소스로 막대한 처리량, 다양한 자료 구조 제공
• 고가용성을 위해 로드 밸러서나 프록시 등 추가적인 서비스를 설치할 필요가 없음
• 데이터의 영속성을 위해 AOF(Append Only File)와 RDB(Redis DataBase) 형식으로 디스크에 주기적으로 저장 가능
• 레디스에 있는 데이터가 유실되더라고 백업 파일을 통해 복구 가능

  메시지 브로커로서의 레디스

• 마이크로서비스 아키텍처에서 각 서비스를 완전히 분리되어 있는 구조로 동작하기 때문에 서로 다른 서비스 간에 지속적인 통신 필요
• 메시징 큐 혹은 stream과 같은 메시지 브로커를 이용해 서비스 간에 비동기적으로 데이터를 전달
• 레디스의 pub/sub은 메시징 기능으로 빠르게 동작하며 간단하게 사용 가능
  • 1개의 채널에 데이터를 던지면 이 채널을 듣고 있는 모든 소비자는 데이터를 빠르게 가져갈 수 있음
  • pub/sub에서 모든 데이터는 전달된 뒤 삭제되는 일회성
  • fire-and-forget 패턴이 필요한 간단한 알림 서비스에서는 유용
• 레디스의 list 자료 구조는 메시징 큐로 사용하기 알맞음
  • 빠르게 데이터 push/pop 가능
  • 애플리케이션은 매번 list에 데이터가 있는지 확인할 필요 없이 대기하다가 새로운 데이터가 들어오면 읽어갈 수 있는 블로킹 기능 사용 가능
• 레디스의 stream 자료 구조를 이용하면 레디스를 완벽한 스트림 플랫폼으로 사용할 수 있음
  • 데이터는 계속해서 추가되는 방식으로 저장됨(append-only)
  • 카프카처럼 저장되는 데이터를 읽을 수 있는 소비자와 소비자 그룹이 존재해 데이터의 분산 처리 가능하며 저장된 데이터를 시간대별로 검색하는 것도 가능

• 특정 데이터베이스에 종속적인 기능을 지원하는 방법

  • 특정 데이터베이스만 사용하는 함수
  • 특정 데이터베이스만 지원하는 SQL 쿼리 힌트
  • 인라인 뷰(From 절에서 사용하는 서브 쿼리), UNION, INTERSECT
  • 스토어 프로시저
  • 특정 데이터베이스만 지원하는 문법

• 네이티브 SQL을 사용하면 엔티티를 조회할 수 있고 JPA가 지원하는 영속성 컨텍스트의 기능을 그대로 사용할 수 있음

• JDBC API를 직접 사용하면 데이터의 나열을 조회할 뿐

네이티브 SQL 사용

엔티티 조회

• em.createNativeQuery(SQL, 결과 클래스)
• 실제 데이터베이스 SQL 사용
• 위치기반 파라미터만 지원(하이버네이트는 이름 기반 파라미터 사용 가능)
• 조회한 엔티티 영속성 컨텍스트에서 관리됨

값 조회

• em.createNativeQuery(SQL)
• 조회할 값들을 Object[]에 담아서 반환
• 스칼라 값을 조회했으므로 영속성 컨텍스트가 관리 X

결과 매핑 사용

• @SqlResultSetMapping
• @EntityResult
• @FieldResult
• @ColumnResult

Named 네이티브 SQL

• createNamedQuery 사용
• TypeQuery 사용 가능
• @NamedNativeQuery

네이티브 SQL 정리

• 네이티브 SQL도 JPQL을 사용할 때와 마찬가지로 Query, TypeQuery(Named 네이티브 쿼리의 경우에만) 반환
• JPQL API 사용 가능
• 네이티브 SQL은 관리하기 쉽지 않고 자주 사용하면 특정 데이터베이스에 종속적인 쿼리가 증가해서 이식성 떨어짐
• 될 수 있으면 표준 JPQL을 사용하고 기능이 부족하면 차선책으로 JPA 구현체가 제공하는 기능을 사용
• 그래도 안되면 마지막 방법으로 네이티브 SQL 사용

스토어드 프로시저

• proc_multiply: 입력 값을 두 배로 증가
• @NamedStoredProcedureQuery

6. 객체지향 쿼리 심화

벌크 연산

• 벌크 연산: 여러 건을 한 번에 수정하거나 삭제
• executeUpdate(): 벌크 연산으로 영향을 받은 엔티티 건수 반환
• 벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리
• 영속성 컨텍스트에 있는 엔티티의 내용과 데이터베이스에 있는 내용이 다를 수 있음 ➡️ 해결 방법
  • em.refresh()
  • 벌크 연산 먼저 실행
  • 벌크 연산 수행 후 영속성 컨텍스트 초기화

    영속성 컨텍스트와 JPQL

• 조회한 엔티티만 영속성 컨텍스트가 관리
• JPQL로 조회한 엔티티는 영속 상태
• 영속성 컨텍스트에 이미 존재하는 엔티티가 있으면 기존 엔티티 반환
• 영속성 컨텍스트는 영속 상태인 엔티티의 동일성 보장
• em.find()는 영속성 컨텍스트에서 엔티티를 먼저 찾고 없으면 데이터베이스 조회
• JPQL은 항상 데이터베이스에 SQL을 실행해서 결과 조회

JPQL과 플러시 모드

• JPQL은 영속성 컨텍스트에 있는 데이터 고려하지 않고 데이터베이스에서 데이터 조회하므로 JPQL 실행 전에 영속성 컨텍스트의 내용을 데이터베이스에 반영해야 함
• 쿼리에 설정하는 플러시 모드는 엔티티 매니저에 설정하는 플러시 몯보다 우선권 가짐
• JPA 쿼리를 사용할 때 영속성 컨텍스트에는 있지만 아직 데이터베이스에 반영하지 않은 데이터 조회 불가 ➡️ 데이터 무결성에 심각한 피해
• 플러시가 너무 자주 일어나는 상황에 FlushModeType.COMMIT 모드 사용하면 쿼리시 밠생하는 플러시 횟수를 줄여서 성능 최적화

Criteria 기초

• Criteria API는 javax.persistence.criteria 패키지에 있음

  // JPQL
  // select m from Member m
  // where m.username='회원1'
  //order by m.age desc
  

CriteriaBuilder cb = em.getCriteriaBuilder();

CriteriaQuery cq = cb.createQuery(Member.class);

Root m = cq.from(Member.class);

// 검색 조건 정의 Predicate usernameEqual = cb.equal(m.get("username"), "회원1");

// 정렬 조건 정의 javax.persistence.criteria.Order ageDesc = cb.desc(m.get("age"));

// 쿼리 생성 cq.select(m) .where(usernameEqual) .orderBy(ageDesc);

List resultList = em.createQuery(cq).getResultList();

- 쿼리 루트
  - Root< Member > m = cq.from(Member.class); 여기서 m이 쿼리 루트
  - 쿼리 루트는 조회의 시작점
  - Criteria에서 사용되는 특별한 별칭
  - 별칭은 엔티티에만 부여 가능

### Criteria 쿼리 생성
  - CriteriaBuilder.createQuery() 메소드로 Criteria 쿼리 생성
  - Criteria 쿼리 생성 시 파라미터로 쿼리 결과에 대한 반환 타입 지정 가능
  - 반환 타입을 지정할 수 없거나 반환 타입이 둘 이상이면 Object(Object[])로 반환 받음
  - 튜플로도 반환 받을 수 있음

### 조회
  - 조회 대상을 한 건, 여러 건 지정
    - select: 조회 대상 한 건
    - multiselect: 조회 대상 여러 건
 - DISTINCT
    - select, multiselect 다음에 distinct(true) 사용
- NEW, construct()
  -    cb.construct(클래스 타입, ...)
- 튜플
  - 이름 기반이므로 순서 기반의 Object[] 보다 안전
  - tuple.getElements() 같은 메소드를 사용해서 현재 튜플의 별칭과 자바 타입 조회 가능
  - 튜플 사용할 때는 별칭 필수

### 집합
- groupBy
- having

### 정렬
- orderBy
- cb.desc(...), cb.asc(...)

### 조인
- join()
- JoinType 클래스
- fetch(조인대상, JoinType)

### 서브 쿼리
~~~java
/* JPQL
    select m from Member m
    where exists
        (select t from m.team t where t.name='팀A')
*/
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Member> mainQuery = cb.createQuery(Member.class);

// 서브 쿼리에서 사용되는 메인 쿼리의 m
Root<Member> m = mainQuery.from(Member.class);

// 서브 쿼리 생성
Subquery<Team> subQuery = mainQuery.subquery(Team.class);
Root<Member> subM = subQeury.correlate(m);
Join<Member, Team> t = sbuM.join("team");
subQuery.select(t)
    .where(cb.equal(t.get("name"), "팀A"));

// 메인 쿼리 생성
mainQuery.select(m)
    .where(cb.exists(subQuery));

List<Member> resultList = em.createQuery(mainQuery).getResultList();

IN 식

• in(...)

CASE 식

• selectCase()
• when()
• otherwise()

파라미터 정의

...
cq.select(m)
    .where(cb.equal(m.get("username"), cb.parameter(String.class, "usernameParam")));

List<Member> resultList = em.createQuery(cq)
    .setParameter("usernameParam", "회원1")
    .getResultList();

네이티브 함수 호출

• cb.function(...)
• 하이버네이트 구현체는 방언에 사용자정의 SQL 함수를 등록해야 호출할 수 있음

동적 쿼리

• 다양한 검색 조건에 따라 실행 시점에 쿼리를 생성하는 것을 동적 쿼리라 함

  // 검색 조건
  Integer age = 10;
  String username = null;
  String teamName = "팀A";
  

// Criteria 동적 쿼리 생성 CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery cq = cb.createQuery(Member.class);

Root m = cq.from(Member.class); Join<Member, Team> t = m.join("team");

List criteria = new ArrayList();

if (age != null) criteria.add(cb.equal(m.get("age"), cb.parameter(Integer.class, "age"))); if (username != null) criteri.add(cb.equal(m.get("username"), cb.paramter(String.class, "username"))); if (teamName != null) criteria.add(cb.equal(t.get("name"), cb.paramter(String.class, "teamName")));

cq.where(cb.and(criteria.toArray(new Predicate[0])));

TypedQuery query = em.createQuery(cq); if (age != null) query.setParameter("age", age); if (username != null) query.setParameter("username", username); if (teamName ! null) query.setParameter("teamName", teamName);

List resultList = query.getResultList();

### Criteria 메타 모델 API
- m.get("age")에서 age는 문자인데 실수로 잘못 적어도 컴파일 시점에 에러 발견 불가
➡️ 메타 모델 API 사용
- 엔티티 -> 코드 자동 생성기 -> 메타 모델 클래스

## 2. QueryDSL
### QueryDSL 설정
~~~xml
<dependency>
  <groupId>com.mysema.querydsl</groupId>
  <artifactId>querydsl-jpa</artifactId>
  <version>3.6.3</version>
</dependency>

<dependency>
  <groupId>com.mysema.querydsl</groupId>
  <artifactId>querydsl-apt</artifactId>
  <version>3.6.3</version>
  <scope>provided</scope>
</dependency>

• querydsl-jpa: QueryDSL JPA 라이브러리
• querydsl-apt: 쿼리 타입(Q) 생성할 때 필요한 라이브러리

  <build>
  <plugins>
    <plugin>
      <groupId>com.mysema.maven</groupId>
        <artifactId>apt-maven-plugin</artifactId>
        <version>1.1.3</version>
      <executions>
        <execution>
          <goals>
            <goal>process</goal>
          </goals>
          <configuration>
            <outputDirectory>target/generated-sources/java</outputDirectory>
            <processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
  </build>

  시작

  import static jpabook.jpashop.domain.QMember.member
  

public void basic() { EntityManager em = emf.createEntityManager();

JPAQuery query = new JPAQuery(em);
List<Member> members = query.from(member)
                        .where(member.name.eq("회원1"))
                        .orderBy(member.name.desc())
                        .list(member);

### 검색 조건 쿼리
- QueryDSL의 where 절에는 and나 or, between, contains, startsWith 사용 가능

### 결과 조회
- uniqueResult(): 조회 결과가 한 건일 때 사용, 조회 결과가 없으면 null을 반환하고 하나 이상이면 com.mysema.query.NonUniqueResultException 예외 발생
- singleResult(): uniqueResult()와 같지만 결과가 하나 이상이면 처음 데이터 반환
- list(): 결과가 하나 이상일 대 사용, 결과가 없으면 빈 컬렉션 반환

### 페이징과 정렬
- 정렬은 orderBy를 사용하는데 쿼리 타입(Q)이 제공하는 asc(), desc() 사용
- 페이징은 offset과 limit 조합해서 사용
- 페이징은 restrict() 메소드에 com.mysema.query.QueryModifiers를 파라미터로 사용해도 됨
- 실제 페이징 처리를 하려면 검색된 전체 데이터 수를 알아야 하기 때문에 listResults() 사용 
➡️ 전체 데이터 조회를 위한 count 쿼리를 한 번 더 실행하고 SearchResults를 반환하는데 이 객체에서 전체 데이터 수를 조회할 수 있음

### 그룹
- groupBy
- having

### 조인
- innerJoin, join
- leftJoin, rightJoin, fullJoin
- fetch

### 서브 쿼리
- com.mysema.query.jpa.JPASubQuery 생성해서 사용
- 서브 쿼리의 결과가 하나면 unique(), 여러 건이면 list() 사용

### 프로젝션과 결과 반환
- 프로젝션 대상으로 여러 필드 선택하면 com.mysema.query.Tuple 사용
- 쿼리 결과를 엔티티가 아닌 특정 객체로 받고 싶으면 빈 생성 기능 사용
  - 프로퍼티 접근: Projections.bean()
  - 필드 직접 접근: Projections.fields()
  - 생성자 사용: Projections.constructor()
- distinct()

### 수정, 삭제 배치 쿼리
- QueryDSL도 JPQL 배치 쿼리와 같이 영속성 컨텍스트를 무시하고 데이터베이스를 직접 쿼리함
- 수정 배치 쿼리는 com.mysema.query.jpa.impl.JPAUpdateClause 사용
- 삭제 배치 쿼리는 com.mysema.query.jpa.impl.JPADeleteClause 사용

### 동적 쿼리
- com.mysema.query.BooleanBuilder

### 메소드 위임
- 메소드 위임 기능을 사용하면 쿼리 타입에 검색 조건을 직접 정의할 수 있음
~~~java
public class ItemExpression {

    @QueryDelegate(Item.class)
    public static BooleanExpression isExpensive(QItem item, Integer price) {
        return item.price.gt(price);
    }
}

// 쿼리 타입에 생성된 결과
public class QItem extends EntityPathBase<Item> {
    ...
    public com.mysema.query.types.expr.BooleanExpression isExpensive(Integer price) {
        return ItemExpression.isExpensive(this, price);
    }
}