카프카 핵심 가이드를 읽고 정리한 내용입니다.

3.1 프로듀서 개요

• 프로듀서로 카프카 메시지를 쓴다 == 프로듀서의 ProducerRecord 전송 API를 호출한다.

1. 프로듀서가 ProducerRecord 객체를 생성
   • 레코드가 저장될 토픽, 벨류 지정은 필수
   • 키, 파티션 지정은 선택
2. 프로듀서가 ProducerRecord를 직렬화
   • 바이트 배열로 전환
3. (파티션을 지정하지 않았다면) 데이터를 Partitioner에게 전달
   • 파티셔너는 (보통) ProducerRecord의 키값을 기준으로 파티션을 결정
4. 토픽 파티션이 결정되면, 프로듀서가 데이터를 같은 토픽 파티션으로 전송할 데이터를 모아 놓은 Record Batch에 추가
5. 별도의 스레드가 레코드 베치를 적절한 카프카 브로커에게 전송
6. 브로커가 데이터를 정상적으로 파티션에 저장하면, 브로커는 프로듀서에게 응답을 보냄
   • 응답 == 토픽, 파티션, 데이터의 파티션 내의 오프셋으로 구성된 RecordMetadata 객체
   • 메시지 저장에 실패하면 응답으로 에러를 전송
     • 프로듀서가 에러를 수신하면, 사용자에게 에러를 리턴하기 전에 몇 번 더 재전송을 시도할 수 있다.

3.2. 프로듀서 생성하기

• 프로듀서를 생성하기 위해선 세 가지 필수값을 제공해야 한다.

  1. bootstrap.servers

• 카프카 클러스터와 첫 연결을 생성하기 위해 제공해야하는 브로커의 host:port 목록
• 프로듀서가 첫 연결을 생성한 후, 추가 정보를 받아오기 때문에 모든 브로커의 주소를 제공할 필요는 없음
  • 다만 브로커에 장애가 발생하더라도 계속해서 클러스터에 연결될 수 있도록, 최소 2개 이상의 브로커를 지정할 것을 권장

    2. key.serializer

• 레코드의 키를 직렬화하기 위해 사용하는 Serializer
• org.apache.kafka.common.Serialization.Serializer 인터페이스를 구현하는 클래스의 이름을 제공해야 한다. (카프카는 자바 App)
  • 기본적으로 여러 구현체를 제공함 (ByteArray, String, Integer, ...)
• 레코드에 키를 사용하지 않더라도 key.serializer는 반드시 설정해야 함

  3. value.serialier

• 레코드의 벨류를 직렬화하기 위해 사용
• 마찬가지로 직렬화 클래스 이름을 제공해야 함

  3.3 카프카로 메시지 전달하기

• 카프카는 여러 방법으로 메시지를 보낼 수 있다.

  1. Fire and Forget

• 클러스터(브로커)에 메시지를 전송하고, 성공·실패 여부는 신경 쓰지 않음
• todo: 이 파트 다시 읽어보기

  2. Synchronous send

• 다음 메시지를 보내기 위해선, 이전 메시지 전송의 성공·실패 여부를 확인해야 함

  3. Asynchronous send

• 기본적으로 프로듀서는 항상 비동기적으로 작동
  • 응답을 받는 시점에 콜백 메서드를 자동으로 호출

3.3.0 GoLang으로 간단히 다뤄보기

• 책은 Java기반인데 나는 Golang으로 해본다.

3.3.1 Synchronous

3.3.2 Asynchronous

카프카 핵심 가이드를 읽고 정리한 내용입니다.

Pub/Sub Pattern

• Publisher가 생성한 데이터(메시지)를 직접 Subscriber에게 전달하지 않는다.
• 대신 어떤 형태로든 메시지를 분류해서 보내고, 수신자는 메시지를 구독한다.
• 대부분의 펍섭 시스템은 중간에 Broker가 존재한다.

  Kafka

• PubSub 기반 분산 커밋 로그 (분산 스트리밍 플랫폼)
  • 마치 RDBMS가 commit log를 사용해서 트랜잭션을 관리하는 것 처럼 작동
  1. 트랜잭션 기록을 보존 (durable)
  2. 시스템 상태를 일관성 있게 복구 가능 (consistency)
  3. 데이터 순서 보장 (deterministic)

• 카프카의 기본 데이터 단위는 Message
  • 단순한 byte 배열 -> 특정한 형식, 의미가 없다
  • 메시지는 key라 불리는 메타 데이터를 포함할 수 있다.
    • 메시지를 저장할 Partition을 결정하기 위해 사용
    • 키 역시 단순히 바이트 배열
• 카프카는 효율성을 위해 메시지를 Batch 단위로 저장
  • 단순히 같은 Topic의 파티션에 쓰여지는 메시지의 집합을 의미함
  • 메시지 쓸 때 마다 생기는 네트워크 비용을 줄이기 위해, 그냥 모아서 전달하는 것
    • latency, throughput 사이의 tradeoff발생

      Topic, Partition

• 메시지는 topic 단위로 분류된다.
• 토픽은 여러 partition으로 나뉘어진다.
  • 토픽에 여러 파티션이 있는 경우, 토픽 안의 메시지 전체에 대해서는 순서 보장이 안 됨
    • 단일 파티션의 경우에만 (구조적으로) 가능
• 파티션 개념을 통해 카프카는 데이터 중복, 확장성을 제공한다.
  • 각 파티션이 서로 다른 서버에 저장될 수 있다.
    • 하나의 토픽이, 하나의 서버의 용량을 넘어가는 성능을 제공할 수 있다.
  • 파티션은 복제 가능하다.
    • 서로 다른 서버들이 동일한 파티션의 복제본을 저장하고 있기 때문에, 한 서버에 장애가 발생해도 다른 서버에서 계속해서 읽고, 쓸 수 있다.

      Producer, Consumer, Consumer Group

• 카프카 클라이언트에 해당
  • 프로듀서, 컨슈머로 구분됨
• 프로듀서
  • aka Publisher, Writer
  • 메시지 생성 주체
    • 메시지는 특정 토픽에 쓰여짐
  • 기본적으로 프로듀서는 토픽에 속한 파티션들 사이에 고르게 나눠서 메시지를 쓴다.
    • 특정 경우에는 partitioner를 통해 특정 파티션을 지정해서 메시지를 쓸 수도 있다.
• 컨슈머
  • aka Subscriber, Reader
  • 메시지 소비 주체
    • 1개 이상의 토픽을 구독해서, 저장된 메시지를 각 파티션에 쓰여진 순서대로 읽음
  • offset을 기록함으로써, 어느 메시지까지 읽었는지 유지
    • 카프카가 메시지를 저장할 때, 각 메시지에 부여하는 메타데이터
    • 지속적으로 증가하는 정수값
    • 파티션의 각 메시지는 고유한 오프셋을 가지며, 앞서 저장된 메시지는 뒤에 오는 메시지보다 반드시 작은 값을 갖는다.
• 컨슈머 그룹
  • 컨슈머는 Consumer Group의 일원으로서 작동
  • 하나 이상의 컨슈머로 구성
  • 컨슈머 그룹은 각 파티션이 하나의 컨슈머에 의해서만 읽히도록 한다
    • 컨슈머와 파티션의 대응 관계를 onwership이라고 한다.
  • 이를 통해
    • 컨슈머를 수평 확장 할 수 있다.
    • 한 컨슈머에 장애가 발생하더라도, 다른 컨슈머가 장애가 난 컨슈머가 읽고 있던 파티션을 재할당받은 뒤 이어서 데이터를 읽을 수 있다.

      Broker, Cluster

• 브로커
  • 하나의 카프카 서버를 Broker라고 부른다.
  • 프로듀셔로부터 메시지를 전달받아 오프셋을 할당한 뒤 디스크 저장소에 쓴다.
  • 컨슈머의 파티션 fetch 요청에 응답하여 메시지를 전달한다.
• 클러스터
  • 브로커는 Cluster의 일부로 작동하도록 설계되었다.
  • 하나의 클러스터 안에 여러 개의 브로커가 포함될 수 있다.
    • 브로커 중 하나가 Cluster Controller 역할을 한다.
      • 작동중인 브로커 중 하나로 자동 선정된다.
      • 파티션을 브로커에 할당해주거나, 장애가 발생한 브로커를 모니터링하는 등의 작업을 수행
  • 파티션은 클러스터 안의 브로커 중 하나가 담당한다.
    • 그 브로커를 Partition Leader라고 부른다.
  • 복제된 파티션이 여러 브로커에 할당될 수도 있다.
    • 복제된 파티션을 가지고 있는 브로커들을 Follower라고 한다.

      카프카의 Replication, Retention

• Replication
  • 파티션의 메시지를 중복 저장함으로써, 리더 브로커에 장애가 발생할 경우 팔로워들 중 하나가 리더 역할을 이어 수행한다.
  • 모든 프로듀서는 리더 브로커에 메시지를 발행해야 하지만, 컨슈머는 리더, 팔로워 상관 없이 한 곳에서 데이터를 읽어올 수 있다.
• Durability Retention
  • 브로커는 토픽에 대해 기본적인 보존 설정이 되어 있다.
    • 특정 기간 동안 메시지를 보존
    • 파티션이 특정 크기에 도달할 때 까지 데이터를 보존

      Kafka의 특징

1. 다중 프로듀서
   • 한 토픽에 대해 여러 프로듀서가 메시지를 생성할 수 있다.
2. 다중 컨슈머
   • 여러 컨슈머가 상호 간섭 없이 어떠한 메시지도 읽을 수 있다.
   • 다른 메시지큐 서비스와 달리, 컨슈머 단위가 아닌 컨슈머 그룹 단위로 메시지가 소비된다.
3. 디스크 기반 보존
   • 메시지를 지속성 있게 저장할 수 있다 -> 즉시 메시지를 읽지 않아도 보존된다.
   • 토픽별로 보존 정책을 지정할 수 있다.
4. 확장성
   • 유연한 확장성 덕분에 어떠한 크기의 데이터도 처리할 수 있다.
   • 클러스터 작동 중에도 시스템 중단 없이 확장 가능하다 (availability)

조회

PostgreSQL은 스키마의 인덱스를 pg_indexes 테이블로 관리한다.

별도로 인덱스 타입을 지정하지 않으면, 기본적으로 B-Tree기반 인덱스를 생성한다.

hash, GIN, GiST, SP-GiST등의 Index가 존재함 (하단에서 이어서 설명)

삭제

DROP INDEX SCHEMA_NAME.INDEX_NAME;

업데이트

데이터가 삭제, 추가되면 인덱스의 정확도가 점점 떨어질 것이다.

변경된 데이터 상황에 맞게 인덱스를 업데이트 해줘야 한다.

// Postgresql 방식
REINDEX INDEX index_name;
// 인덱스의 statistic 정보만 업데이트 -> 인덱스 구조가 변경되는게 아님
ANALYZE table_name(index_name);

참고

데이터 개수가 늘어날 수록 인덱스 생성, 삭제, 업데이트는 비용이 많이 소모된다는 점을 항상 염두해야 한다.

Index 종류

성능 비교

PostgreSQL에서는 \timing과 EXPLAIN ANALYZE를 통해 간단히 실행 시간을 확인할 수 있다.

INDEX 적용 이전

\timing
SELECT * FROM Users WHERE name =

INDEX 적용 후

Index가 사용이 안 돼요

문제없이 인덱스를 만들었는데도 Index를 타지 않는다.

Query Optimizer가 Index를 타는게 오히려 성능이 안 좋다고 판단했기 때문이다.

그럼에도 인덱스를 사용하고 싶으면 PostgreSQL의 경우, Query Optimizer가 Index를 타도록 다음과 같이 힌트를 제공할 수 있다.

// 
SELECT /*+ INDEX(user_name_age_idx) */ * FROM Users WHERE name = 'hi' AND age = 25;

SELECT 절에 /*+ INDEX(인덱스_이름) */형식으로 힌트를 줄 수 있다.

그런데 힌트를 제공한다고 해서 무조건 인덱스를 사용하는건 아니다.

내가 아무리 인덱스 사용하라고 해도, 쿼리 옵티마이저가 성능상 이건 아닌데...하면 인덱스를 사용하지 않는다.

# 프로젝트 init 
go mod init github.com/wonju-dev

# gqlgen 의존성 설정
# gqlgen 이후에 버전을 명시할 수 있음 (생략하면 최신 버전)
go get -d github.com/99designs/gqlgen

# gqlgen 프로젝트 구조 초기화
go run github.com/99designs/gqlgen init

위 명령을 수행하면 다음과 같은 프로젝트가 생성된다.

GraphQL Schema 정의하기

graph/sechema.graphqls에 회원 CRUD와 관련한 GraphQL 스키마를 정의한다.

GrahpQL 문법은 다음에서 설명

type Query {
  getUser(
    input: QgetUserInput
  ): [QgetUserOutput!]!
}

input QgetUserInput {
  id: [ID!]
  name: [String!]
  age: [Int !]
}

type QgetUserOutput {
  status: Boolean!
  result : [User!]
}

type Mutation {
  addUser(
    input: MaddUserInput
  ): MaddUserOutput

  updateUser(
    input: MupdateUserInput
  ): MupdateUserOutput

  deleteUser(
    input: MdeleteUserInput
  ): MdeleteUserOutput
}

input MupdateUserInput {
  id: ID!
  name: String
  age: Int
}
input MdeleteUserInput {
  ids: [ID!]
  names: [String!]
  ages: [Int!]
}

type MupdateUserOutput {
  state: Boolean
  results: User
}

type MdeleteUserOutput {
  state: Boolean
  results: [User]
}

input MaddUserInput {
  name: String!
  age: Int!
}

type MaddUserOutput{
  status: Boolean!
  result: User
}

type User {
  id: ID
  name: String!
  age: Int!
}

그런다음 go run github.com/99designs/gqlgen generate 명령을 수행하면 자동으로 GraphQL 서버를 위한 코드, 파일이 생성된다.

공식문서에 따르면

1. gqlgen은 Schema first approach를 따르기 때문에, GraphQL 쿼리로 API명세를 정의할 수 있다.
2. 위와 같은 접근법을 지원하기 위해, schema.graphql에 정의된 스키마를 토대로 golang의 구조체와 resolver template와 같은 boilerplate를 자동 생성한다.

그래서 우리는 schema.graphqls에 스키마를 정의했고, gqlgen의 도움을 받아 요청을 처리할 로직을 schem.resolver.go에 구현할 것이다.

유저 Create 예제

일반적인 Controller(resolver) - Service 구조를 만들기 위해 의존성을 주입한다.

// graph/resolver.go
package graph

import "github.com/wonju-dev/service/user"

// This file will not be regenerated automatically.
//
// It serves as dependency injection for your app, add any dependencies you require here.

type Resolver struct {
    userService user.UserService
}

Create

// graph/schema.resolvers.go
// AddUser is the resolver for the addUser field.
func (r *mutationResolver) AddUser(ctx context.Context, input *model.MaddUserInput) (*model.MaddUserOutput, error) {
    return r.userService.CreateUser(ctx, input)
}

// userService.go
package user

import (
    "context"
    "github.com/wonju-dev/graph/model"
    "github.com/wonju-dev/repository/User"
)

type UserService struct {
    userRepository User.UserRepository
}

func (userService *UserService) CreateUser(ctx context.Context, input *model.MaddUserInput) (*model.MaddUserOutput, error) {
    err := userService.userRepository.AddUser(input)
    if err != nil {
        return nil, err
    }

    return &model.MaddUserOutput{
        Status: true,
        Result: &model.User{
            Name: input.Name,
            Age:  input.Age,
        },
    }, nil
}

의존성 주입 실패

위 처럼 만든 다음 로컬에서 테스트를 했는데, nil pointer error가 발생한다.

생각해 보니 의존성 관계를 설정만 했지, 실제로 의존성을 주입한 부분이 없다.

당최 gqlgen은 어떻게 자동하는지 모르겠다. gqlgen 내부를 한 번 뜯어보자...

gqlgen 구성, 작동 방식

튜토리얼 강의를 보면 GraphQL 서버를 만든 다음, golang의 표준http라이브러리를 통해 서버를 띄운다.

    ...
    srv := handler.NewDefaultServer(graph.NewExecutableSchema(graph.Config{Resolvers: &graph.Resolver{}}))

    http.Handle("/query", srv)
    ...

기본적으로 GraphQL은 HTTP Protocol을 기반으로 작동한다. 그렇기 때문에, GraphQL 요청을 처리하는 녀석(?)은 단순히 Request Handler와 다르지 않다. 다만 Requset Body 파싱하고, 요청 처리에 사용할 변수를 만들기 위해 조금 복잡할 뿐이다.

gqlgen 작동 방식

1. NewDefaultServer은 http표준인 Handler 인터페이스를 구현한 Server라는 구현체를 반환한다.
   • Server 객체는 다음과 같다.

     Server struct {
       transports []graphql.Transport
       exec       *executor.Executor
     }

   • exec: 실재로 요청을 처리하는 객체
   • 참고: 사실 GraphQL은 POST말고, GET, WebSocket 으로도 요청을 보낼 수 있다. 서로 다른 요청 방식을 표준화 하기 위해 transports가 존재한다.
2. HTTP 요청이 발생하면 Server의 ServeHTTP가 요청을 처리한다.
3. ServeHTTP는
   1. Server의 멤버 변수 배열에서, 요청을 처리할 수 있는 적절한Transport를 찾은 뒤,
   2. 선택된 Transport.Do메서드에 멤버 변수exec을 파라미터로 전달하여 호출한다.
   3. 아래에서 설명될 하위 메서드에서 만든 Response를 전송

    참고
    1. `Transport`는 `Server`객체 생성 시점에 자동으로 등록된다. (`NewDefaultServer`를 사용하는 경우)
    2. `New`를 통해 직접 서버를 만들 수도 있는데, 이 경우에는 직접 `Transport`를 등록해야 한다.
    3. 이번 분석에서는 NewDefaultServer를 통해 자동으로 등록된 `Transport`구현체인 POST만 다룬다. (일반적으로 GraphQL은 POST method로 이용하므로)

    // Transport는 단순히 인터페이스고
    // NewDefaultServer을 사용하는 경우 gqlgen은 자동으로 
    // Transport 구현체(GET, POST, WebSocket, Option, ...)를 등록한다.
    Transport interface {
        Supports(r *http.Request) bool // Transport가 Http Method를 구분할 때 사용
        Do(w http.ResponseWriter, r *http.Request, exec GraphExecutor)
    }

• exec의 타입인 Executor은 다음과 같다.

  type Executor struct {
    es         graphql.ExecutableSchema
    extensions []graphql.HandlerExtension
    ext        extensions
  
    errorPresenter graphql.ErrorPresenterFunc
    recoverFunc    graphql.RecoverFunc
    queryCache     graphql.Cache
  }

  다 필요 없고, 몇 가지 포인트만 짚자면

  1. Executor은 ExecutableSchema을 멤버 변수로 갖는다.
  2. Executor는 GraphExecutor 인터페이스를 구현체이다.
  3. Executor는 Server 객체 생성시에 같이 생성되고, Server에 멤버 변수로 할당된다.

     GraphExecutor interface {
     CreateOperationContext(ctx context.Context, params *RawParams) (*OperationContext, gqlerror.List)
     DispatchOperation(ctx context.Context, rc *OperationContext) (ResponseHandler, context.Context)
     DispatchError(ctx context.Context, list gqlerror.List) *Response
     }

4. (다시 원래 흐름으로 돌아와서)Transport 구현체인 POST의 Do메서드는 대략 다음과 같다.

   func (h POST) Do(w http.ResponseWriter, r *http.Request, exec graphql.GraphExecutor) {
    1. 기본적인 Response Message Header 구성
    2. Request Message Body 검증
        2.1 유효하지 않은 포맷이면 Error를 Dispatch
    3. OperationContext 생성
    4. 요청 처리
    var responses graphql.ResponseHandler
    responses, ctx = exec.DispatchOperation(ctx, rc)
    5. Response Message 생성
    writeJson(w, responses(ctx))
   }

5. Executeor의 DispatchOperation의 메서드는, 자신의 멤버 변수인 ExecutableSchema의 Exec메서드를 통해 최종적으로 요청을 처리한다.
6. ExecutableSchema는 객체는 generated.go의 내용을 토대로 생성되었고, generated.go의 내용에 따라 schema.resolvers.go의 메서드들이 호출된다.

   gqlgen 사용 방법 (의존성 주입)

   앞 선 주제를 통해, gqlgen이 어떻게 작동하는지 파악했다. 이제 적절한 파라미터를 전달해서, 우리가 schema.graphqls에 정의한 내용을 토대로 서버가 작동하도록 해보자.

다시 맨 처음 코드로 돌아와서 GraphQL 서버를 설정하는 코드를 보면

config := graph.Config{Resolvers: &graph.Resolver{}}
executableSchema := graph.NewExecutableSchema(config)
srv := handler.NewDefaultServer(executableSchema)

다음 처럼 분석할 수 있다.

1. &graph.Resolver는 우리가 의존 관계를 설정한 구조체의 객체
   • 여기에 의존성 주입을 하면 된다.
2. config와 executableSchema는 generated.go를 토대로 생성되었고, gqlgen은 executableSchema을 통해 schema.resolvers의 메서드를 사용하게 된다.

따라서 다음과 같이 의존성을 주입하면 된다.

config := graph.Config{
    Resolvers: &graph.Resolver{
        user.UserService{ // Resolver가 사용할 Service
            User.UserRepositoryImpl{ // Service가 사용할 Repository
                // 대충 db config 관련 내용
            },
        },
    },
}
executableSchema := graph.NewExecutableSchema(config)
srv := handler.NewDefaultServer(executableSchema)

참고 Tutorial: Accessing a relational database pgx - PostgreSQL Driver and Toolkit

Connection 생성

기본 개념

Go는 표준화된 방법으로 DB를 사용할 수 있도록 database/sql이라는 표준 라이브러리를 제공한다. 이는 단순히 인터페이스이므로, 실제 구현체를 import해서 사용해야 한다.

공식문서를 살펴보면 다양한 PostgreSQL 드라이버가 있는 것 같은데, 그 중 jackc/pgx을 사용하기로 한다.

드라이버 특화 방식으로 연결하기

드라이버마다 조금씩 연결 방식이 다른데, jackc/pgx는 다음과 같다.

package main

import (
    "context"
    "github.com/jackc/pgx/v4"
    "log"
)

func main() {
    connectionInfo := "postgres://USER_NAME:PASSWORD@RDBMS_URL:PORT_NUM/DATABASE_NAME"
    connection, err := pgx.Connect(context.Background(), connectionInfo)
    if err != nil {
        log.Panic(err)
    }
    defer closeDBConnection(connection, context.Background())

    log.Println("success to establish DB Connection")
}

func closeDBConnection(connection *pgx.Conn, context context.Context) {
    connection.Close(context)
}

표준 방식으로 연결하기

당연히 database/sql을 사용해서 Connection을 만들 수 있다.

package main

import (
    "database/sql"
    _ "github.com/jackc/pgx/v4/stdlib" // 생략하면 안 됨
    "log"
)

func main() {
    connectionInfo := "postgres://USER_NAME:PASSWORD@RDBMS_URL:PORT_NUM/DATABASE_NAME"
    connection, err := sql.Open("pgx", connectionInfo) // takes String
    // sql.OpenDB(driver.Connector) // takes driver.Connector
    if err != nil {
        log.Panic(err)
    }

    defer connection.Close()
    log.Print("success to establish connection")
}

표준 인터페이스에 어떤 RDBMS를 사용할 것인가를 초기화 단계에 알려줘야 한다.

github.com/jackc/pgx의 경우 'postgress'가 아니고, 'pgx'이다.
github.com/lib/pg의 경우에는 'postgress;가 맞다.

특별한 이유가 없으면 표준 인터페이스를 사용하는게 좋을 듯 하다.

참고
1. Connection 정보로 String이 아닌 객체를 넘겨줄 수도 있는데, 정확한 사용법은 RDBMS 드라이버마다 다르다.
2. `os.Getenv`를 사용하여 Credentials들을 은닉화 할 수 있다. (https://go.dev/doc/database/open-handle#:~:text=log.Fatal(err)%0A%7D-,Storing%20database%20credentials,-Avoid%20storing%20database)

Connection Pool

앞서 살펴본 Connection은 사실 Connection Pool이다.

conn, err := sql.Open("pgx", connectionInfo)
stats := conn.Stats(); // sql.DBStats

// DBStats contains database statistics.
type DBStats struct {
    MaxOpenConnections int // Maximum number of open connections to the database.

    // Pool Status
    OpenConnections int // The number of established connections both in use and idle.
    InUse           int // The number of connections currently in use.
    Idle            int // The number of idle connections.

    // Counters
    WaitCount         int64         // The total number of connections waited for.
    WaitDuration      time.Duration // The total time blocked waiting for a new connection.
    MaxIdleClosed     int64         // The total number of connections closed due to SetMaxIdleConns.
    MaxIdleTimeClosed int64         // The total number of connections closed due to SetConnMaxIdleTime.
    MaxLifetimeClosed int64         // The total number of connections closed due to SetConnMaxLifetime.
}

sql.DB 구조체의 메서드를 통해 Conncection (Pool) 관련 설정을 할 수 있다. 참고

Query

INSERT, UPDATE, DELETE

반환값이 없는 작업을 수행할 때는 기본적으로 Exec을 사용한다.

func AddAlbum(alb Album) (int64, error) {
    result, err := db.Exec("INSERT INTO album (title, artist) VALUES (?, ?)", alb.Title, alb.Artist)
    if err != nil {
        return 0, fmt.Errorf("AddAlbum: %v", err)
    }

    // Get the new album's generated ID for the client.
    id, err := result.LastInsertId()
    if err != nil {
        return 0, fmt.Errorf("AddAlbum: %v", err)
    }
    // Return the new album's ID.
    return id, nil
}

RDBMS에 따라 Parameter Placeholde가 ?일 수도 $1일 수도 있다.

PostgreSQL은 $1 형식을 사용한다.

용도에 따라 사용할 수 있는 다양한 Exec 메서드가 존재한다.

SELECT

Single Row

PK로 조회같이 결과 값이 단 건이 경우에는 QueryRow를 사용한다.

func canPurchase(id int, quantity int) (bool, error) {
    var enough bool // 쿼리 결과값을 받을 변수를 선언

    // 쿼리 수행
    // sql.Row Type
    row := db.QueryRow("SELECT (quantity >= ?) from album where id = ?", quantity, id)
    // 결과값을 parsing해서 변수에 할당, 파라미터로 Ref를 전달해야 함
    err := row.Scan(&enough)
    if err != Nil {
        return false, fmt.Errorf("canPurchase %d: unknown album", id)
    }
    return enough, nil
}

QueryRow로 실행시킨 쿼리의 결과값이 여러 건인 경우, Scan을 수행하면 맨 처음 찾은 값만 반환한다.

Multi Row

func albumsByArtist(artist string) ([]Album, error) {
    // sql.Rows Type
    rows, err := db.Query("SELECT * FROM album WHERE artist = ?", artist)
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    // An album slice to hold data from returned rows.
    var albums []Album

    // Loop through rows, using Scan to assign column data to struct fields.
    for rows.Next() {
        var alb Album
        if err := rows.Scan(&alb.ID, &alb.Title, &alb.Artist,
            &alb.Price, &alb.Quantity); err != nil {
            return albums, err
        }
        albums = append(albums, album)
    }
    if err = rows.Err(); err != nil {
        return albums, err
    }
    return albums, nil
}

Single Row랑 크게 다른게 없다.

다만 rows.Close를 호출해서 자원을 반납함을 확인할 수 있는데, 기본적으로 sql.Rows는 rows.Next를 통해 모든 loop을 돌면 묵시적으로 자원을 반납하는데, 에러가 발생하는 경우를 고려해서 defer를 통해 명시적으로 반환하는 것을 권장한다.

Null

특정 컬럼이 Null인 경우를 고려할 수 있다.

var s sql.NullString // NullBool, NullFloat64, NullInt32, NullInt64, NullString, NullTime
err := db.QueryRow("SELECT name FROM customer WHERE id = ?", id).Scan(&s)
if err != nil {
    log.Fatal(err)
}

name := "Valued Customer" // 마치 기본값 처럼 사용할 수 있다.
// Valid(not null)이면
if s.Valid {
    // 조회된 값을 사용
    name = s.String
}

Scan

위에서 살펴본 것처럼, Scan을 사용하면 RDBMS의 데이터 타입을 Golang의 비슷한 데이터타입으로 Convert 해준다.

구체적으로 어떤 값으로 변환되는지, 어떻게 변환하는지는 RDBMS 드라이버에 따라 다르다. (다음을 참고)

Transaction

앞서 다룬 예제에서는 따로 트랜잭션을 설정하지 않았기 때문에, RDBMS의 기본 설정에 따라 Rollback, Commit 될 것이다.

Commit, Rollback

Isolation Level

Trial and Error

PostgreSQL의 array 다루기

PostgreSQL은 array 타입을 지원하는데, Golang에서 이를 다룰 때 단순히 Array(또는 Slice)를 사용하면 된다.

CREATE TABLE Person (
    ...
    hobbies varchar[64] notnull, // {"soccer", "bascketball"} 형식으로 저장한다.
    ...
)

var hobbies []string

row := conn.QueryRow("SELECT hobbies from Person",...)
err := row.Scan(&hobbies) // 알아서 PostgreSQL Array를 Golang Slice로 변환한다.

참고 Introduction to gRPC

gRPC

gRPC는 protocol buffers을 두 가지 용도로 사용한다.

1. Interface Definition Language (IDL)
2. underlying message interchange format.

gRPC에서는, client app이 직접적으로 다른 머신에서 작동 중인 server application의 메서드를 마치 'local object'처럼 호출할 수 있다. 이로써 분산 app, service를 더 쉽게 만들 수 있다.

다른 RPC 시스템 처럼, gRPC도 '서비스를 정의하고', '파라미터와 리턴 타입을 가지고 원격으로 호출할 수 있는 메서드를 식별하자'는 아이디어를 기본으로 한다.

서버는 클라이언트의 요청을 처리하기 위해 이를 위한 인터페이스를 구현하고, gRPC 서버를 가동시킨다.

클라이언트는 stub를 가진다.

stub: 서버의 메서드와 동일한 메서드를 제공하는 것

gRPC 클라이언트와 서버는 다양한 환경에서 작동할 수 있고, gRPC를 지원하는 어떠한 언어로도 작성될 수 있다.

Protocol Buffers

기본적으로 gRPC는 Protocol Buffers를 사용한다.

Protocol Buffers
    - Google’s mature open source mechanism for serializing structured data 

protocol buffers를 사용하려면 우선, proto file로 serialize하고 싶은 데이터의 구조를 정의해야 한다.

proto file
    - 단순히 '.proto' 확장자의 text file을 의미함

Protocol buffer data는 message라는 단위로 조직된다.

message
    - a small logical record of information
    - containing a series of name-value pairs called `fields`.

message는 다음과 같은 구조를 가진다.

// message는 'type key = value' 형태의 field를 가진다
message Person {
  string name = 1; 
  int32 id = 2;
  bool has_ponycopter = 3;
}

message를 통해 데이터 구조를 한 다음, protocol buffer 컴파일러인 protoc을 사용해서 data access classes를 만든다.

원하는 언어로 만들면 된다.

data access class는 각 필드에 접근할 수 있는 accessors를 제공한다.

like name() and set_name(), as well as methods to serialize/parse the whole structure to/from raw bytes. So, for instance, if your chosen language is C++, running the compiler on the example above will generate a class called Person. You can then use this class in your application to populate, serialize, and retrieve Person protocol buffer messages.

You define gRPC services in ordinary proto files, with RPC method parameters and return types specified as protocol buffer messages:

실습

참고 Basics tutorial

1. .proto 확장자 파일을 만들어서 gRPC 통신을 위한 인터페이스를 정의한다. (마치 gqlgen에서 schema.graphql을 정의하는 것과 비슷)

2. 다음 명령을 통해 protoc를 가지고 컴파일 (파일 generate)

   protoc --go_out=. --go_opt=paths=source_relative \
    --go-grpc_out=. --go-grpc_opt=paths=source_relative \
    helloworld/helloworld.proto

참고 GraphQL 개념잡기

GraphQL

SQL은 관계형데이터베이스를 다루는 문법
GraphQL (이하 gql)은 gql을 지원하는 서버에서 데이터를 요청하는 '문법, 형식'

gql은 HTTP Protocol의 POST Method위에서 작동한다. gql문법을 만족하는 데이터를 POST Method의 Body에 담아 서버로 전송하는 것이다.

주로 비교되는 REST API를 지원하는 서버는 여러 Endpoint를 가지고, 각 Endpoint는 한 가지 성격의 작업을 수행하는 반면, gql은 1개의 Endpoint만을 가진다. gql 요청을 받은 서버측에서 요청을 분석한 뒤, 적합한 작업을 선택하여 수행하는 것이다.

REST API 서버는 1(EndPoint):1(Operation) 쌍이 여러개 존재
GraphQL 서버는 1(EndPoint):M(Operation)이 1개 존재

gql 구조

# 기본 형태 (일반 쿼리)
{
    hero {
        name
    }
}

gql은 크게 Query와 Mutation으로 구분된다.

Query(질의)는 Read
Mutation(변조)은 Create, Update, Delete 

단순히 의미를 구체화하기 위해 개념적으로 구분한 것이다.

[query | mutation] {
    ...
}

Query

# 일반쿼리
{
  human(id: "1000") {
    name
    height
  }
}

# 오퍼레이션 네임 쿼리
query HeroNameAndFriends($episode: Episode) {
  hero(episode: $episode) {
    name
    friends {
      name
    }
  }
}

쿼리는 일반 쿼리와 오퍼레이션 네임 쿼리로 구분할 수 있다.

일반 쿼리는 다짜고짜 중괄호로 시작하고, 오퍼레이션 네임 쿼리는 앞에 query가 붙어있다.

일반 쿼리는 Specific한 내용을 담고있는 반면, 오퍼레이션 네임 쿼리는 마치 함수처럼, 변수 개념을 통해 재사용할 수 있다. react apollo client같은 gql을 구현한 클라이언트를 통해 변수에 값을 할당하여 사용한다.

여기서 일반적인 REST API와 프로그래밍 페러다임(?)적으로 차이점이 있는데, REST API는 데이터를 반환하는 쪽에서 어떤 데이터를 조회할지 SQL문을 통해 결정하는데, GQL은 데이터를 요청하는 쪽에서 어떤 데이터를 조회할지 GQL을 통해 결정한다.

SQL은 백엔드 개발자가 작성, 관리
GQL은 프론트엔드 개발자가 작성, 관리

이러한 관계를 통해 프론트엔드가 백엔드 API의 Request, Response에 덜 의존적일 수 있다.

그러나 데이터 스키마에는 여전히 의존적임을 지적함 -> 애초에 극복할 수 있는 문제인가...?

schema/type

의미는 데이터베이스의 스키마와 비슷하나, 형태는 C언어의 헤더 파일과 비슷하다.

type Character {
  name: String!
  appearsIn: [Episode!]!
}

오브젝트 타입 : Character
필드 : name, appearsIn
스칼라 타입 : String, ID, Int 등
느낌표(!) : 필수 값을 의미(non-nullable)
대괄호([, ]) : 배열을 의미(array)

Resolver

SQL만 작성하면 DBMS가 알아서 데이터를 가져오는 것과 달리, GQL은 resolver(이하 리졸버)를 직접 구현함으로써 데이터를 가져오는 구체적인 과정을 명시해야 한다.

gql 쿼리문 파싱은 보통 gql 라이브러리를 사용해서 처리

리졸버를 직접 구현해야하는 부담은 있지만, 데이터 source에 상관 없이 구현 가능하다는 장점이 있다.

리졸버를 통해 데이터를 데이터베이스에서 가져 올 수 있고, 일반 파일에서 가져올 수 있다.
심지어 http, SOAP와 같은 네트워크 프로토콜을 활용해서 원격 데이터를 가져올 수 있다.

Graph의 의미

gql 쿼리에서는 각각의 필드마다 다음 타입을 반환하는 함수가 하나씩 존재 한다. 그리고 그 함수가 바로 리졸버인 것이다.

리졸버는 다음과 같은 특징을 갖는다.

1. 필드가 스칼라 값(문자열이나 숫자와 같은 primitive 타입)인 경우에는 실행 종료
2. 필드의 타입이 스칼라 타입이 아닌 우리가 정의한 타입이라면 해당 타입의 리졸버를 호출

이처럼 리졸버는 필드에 따라 연쇄적으로 호출될 수 있고, 그 과정이 마치 그래프 탐색과 유사하다.

GraphQL 서버 개발하기

gplgen으로-GraphQL-서버-만들기를 참고

참고 Kubernetes for the Absolute Beginners

Docker Container로 띄운 서비스를 어떻게 관리해야 할까?

Traffic에 따라 Scaling up, down을 어떻게 자동화할까?
Container의 상태를 어떻게 추적, 관리할까?
...

Docker Container의 상태를 관리하는 도구가 여러가지가 있다.

Docker swarm: 간단한 설정, 다양한 기능 제공 X
MESOS: 어려운 설정, 다양한 기능 제공 O
Kubernetes: 어려운 설정, 다양한 기능 제공 O

그 중 Kubernetes에 대해 알아보도록 하겠다.

Kubernetes Basics

Kubernetes(이하 k8s)를 사용함으로써 다양한 이점을 얻을 수 있다.

1. HW Failure가 SW Failure에 영향을 주지 않도록 할 수 있다.
2. Load Balancing
3. Container들을 체계적으로 관리할 수 있다.
4. ...

k8s Architecture

k8s의 주요 컨셉을 살펴보자

Node

• k8s가 설치된 물리적(또는 가상) 머신
• k8s에 의해 launch된 container들이 위치하는 곳 == Worker Node
• worker node들을 관리하는 node == master node (아래에서 다룸)

만약 한 개의 Node만 운영하면 어떻게 될까? Node에 장애가 발생하면 서비스가 죽을것이다. 그렇기 때문에 Node는 2개 이상 유지해야 한다.

Cluster

• 여러 Node들로 구성된 일종의 Group

Cluster에 속한 Node들 중 하나가 죽더라도, 다른 Node들은 여전히 살아있으므로 서비스는 계속 작동할 것이다. 그리고 Cluster에 여러 Node를 유지함으로써 Load balancing을 할 수 있을 것이다.

Master Node

• Cluster와, Cluster에 속한 Node들을 관리, 모니터링하는 Node
• Master Node도 Cluster에 속한다.
• Cluster에 속한 다른 Worker Node의 상태를 모니터링하고, Failure가 발생한 Node의 workload를 다른 node로 옮긴다 == Orchestration

k8s Components

• node에 k8s를 설치한다 == k8s를 구성하는 여러 service들을 설치한다.

  API Server

• k8s 기능을 사용하기위한 인터페이스 역할
  • k8s 기능을 사용 == 클러스터와의 interaction

etcd

• 클러스터를 관리하기 위해 필요한 모든 데이터를 저장하기 위한 distributed reliable key value store
  • 클러스터에 존재하는 node 데이터를 ectd에 분산 방식으로 저장한다.
• etcd는 Master node들 사이에서 발생하느 conflict를 예방하기 위한 Lock을 지원한다.

kubelet

• 클러스터에 속한 각 node에서 작동하는 agent
• agent
  • 컨테이너가 node에서 정상적으로 작동하도록 함

    container runtime

• container를 구동시키는 underlying SW
  • Docker, rkt, cri-o 등이 SW에 해당

controller

• k8s의 orchestration의 핵심
  1. node, container, end point의 정상 작동 여부를 확인 -> 새로운 컨테이너 생성 여부를 결정

scheduler

• 여러 node들 사이의 work, container를 분산하는 역할
  • 새로 생성된 컨테이너를 찾으면 특정 node에 할당함

기본 동작 원리

1. Worker Node에는
   1. 컨테이너를 작동시키기 위한 Container Runtime(Ex. Docker)을 가지고 있음
   2. Master Node와 통신하기 위한 Kubelet Agent를 가지고 있음
2. Master Node에는
   1. Master Node가 Master로서의 기능을 지원하기 위한 Kube API Server를 가지고 있음
      • Worker Node의 kubelet Agent와, Master Node의 kube API Server가 서로 통신하는 것
        • Worker Node의 상태를 Master Node로 전송
          • Master Node로 부터 명령을 받아 Worker Node를 조작
   2. Node들의 정보를 저장, 관리하기 위한 etcd를 가지고 있음
   3. Node를 관리하기 위한 Controller, Scheduler를 가지고 있음

      Pods

      k8s는 컨테이너를 workder node에 직접적으로 배포하지 않는다. 대신, container를 pod라 불리는 k8s object 단위로 encapsulate한뒤 배포한다.

      Pod란

• single instance of an application
• smallest object that can be created in k8s

1. 파이썬으로 만든 서버를 Container로 만든 뒤, 이를 Pod로 캡슐화한뒤 Worker Node에 배포한다.
2. 서버를 Scale up해야 하는 상황이라면, 한 Pod에 동일한 Container를 추가하지 않는다.
   • 대신, 동일한 구성의 Pod를 배포하는 단위로 Scaling을 진행한다.
   • Pod를 배포하려는 Node의 capacity를 초과한다면, 새로운 Node를 생성한 뒤 Pod를 배포한다.

3. 파이썬 서버가 아닌, 다른 서비스 Container는 동일한 Pod에 배포할 수 있다.

• 같은 Pod에 배포된 Container들은 저장공간, 네트워크 등의 자원을 공유한다.

파이썬 서버 컨테이너를 일일이 배포하는 방식으로 서비스를 운영해도 문제는 없다. 그런데, 서버 작동을 위한 helper container가 추가되거나, Scaling을 위해 서버 Container가 추가되는 경우에는 관리가 복잡해진다.

• 서버 container - helper container 간 자원 매핑 등
• 서버 container 제거할 때, 연관된 helper container도 같이 제거
• ...

k8s는 Pod Object 단위로 Container들을 관리하도록하여, 위의 불편함을 개선한다.

kubectl로 pod 다루기

# 단순히 Docker container run 하기
docker run container_name

# pod를 생성하여 Docker Container run 하기
kubectl run pod-name --image IMAGE_NAME

# Pods 목록 확인
kubectl get pods

# Pods 목록 확인 + wide
kubectl get pods -o wide

# Pods 디테일 확인
kubectl describe pod pod-name

# Pods 제거
kubectl delete pod pod-name

# cluster 목록 확인
kubectl config get-clusters

# Pod 접속
kubectl -it exec POD_NAME -n NAMESPACE_NAME -- /bin/bash

기본적으로 Docker Image는 Docker hub (public image repository)에서 가져온다.

설정을 통해 이미지를 불러올 주소를 지정할 수 있다.

Pods with YAML based Configuration

k8s은 Pod를 비롯한 Object를 생성하기 위해 YAML을 사용할 수 있다.

기본적으로 4개의 Required Top level Property를 가진다.

# pod-definition.yaml
apiVersion: v1
# Object를 생성하는 k8s API 버전을 지정하는 부분
# 생성하는 Object에 따라 적합한 API 버전을 사용해야 함
kind: Pod
# 생성하려는 Object의 종류를 지정하는 부분
metadata: 
# 생성하는 Object에 대한 정보를 명시하는 부분
# k8s이 제공하는 child만 사용 가능
    name: myapp-pod
    # Object의 이름을 명시
    labels:
        # dictionary 형태로, 원하는 형태의 key, value label을 명시 가능
        # label을 가지고 pod를 필터링, 검색할 때 사용할 수 있음
        app: myapp
        type: front-end

spec: 
# 생성하는 Object에 따라, k8s에 추가로 제공해야 하는 정보를 명시하는 부분
    containers:
        # containers 속성은 list 형식
        - name: nginx-container
          image: nginx

위처럼 yaml형식으로 정의한 내용를 가지고 pod를 생성할 수 있다.

kubectl craete -f pod-definition.yaml
# kubectl apply -f pod-definition.yaml

Replication Controller

여러 개의 Pod을 운영함으로써 High Availability, Load Balancing, Scaling의 이점을 얻을 수 있다.

Replication Controller는 Definition file에 명시한 내용에 따라 Pod을 관리한다.

Pod 개수를 몇 개 유지하라
...

Replication Controller는 같은 Cluster에 위치한 여러 (Worker) Node에 걸쳐 사용된다.

# Replication Controller Definition file
# rc-definition.yaml
apiVersion: v1
kind: ReplicationController
metadata:
    name: myapp-rc
    labels:
        app: myapp
        type: front-end
spec:
    # Replication Controller에서 생성할 Pod들을 정의하기 위한 Template 부분
    template:
        # 위에서 작성한 pod-definition.yaml과 동일한 형식, 내용을 사용한다
        metadata: 
            name: myapp-pod
        labels:
            app: myapp
            type: front-end

        spec: 
            containers:
                - name: nginx-container
                  image: nginx
    # 몇 개의 pod replica를 만들 것인가
    replicas: 3

# Replication Controller, Pod를 생성
kubectl create -f rc-definition.yaml

# Replication Controller 목록 확인
kubectl get replicationcontroller

ReplicaSet

ReplicaSet은 Replication Controller와 동일한 목적을 가지나 차이점이 있다.

# ReplicaSet Definition file
# replicaset-definition.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myrs
  labels:
    app: rs

spec:
  template:
    metadata: 
      name: myapp-pod
      labels:
        app: myapp
        type: front-end

    spec: 
      containers:
        - name: nginx-container
          image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

# ReplicaSet을 생성
kubectl create -f rs-definition.yaml

# ReplicaSet 목록 확인
kubectl get replicaset

selector

ReplicaSet에 Pod definition이 들어있는데, 굳이 selector써서 자기가 만든 Pod들을 구분하려고 하는건가?

Replication Controller는 기본적으로, 자기에 정의된 Pod만을 관리(개수, 상태 등)하는 반면, ReplicaSet은 자기 밖에서 만들어진 Pod도 관리할 수 있기 때문이다.

`Replication Controller`도 `selector`필드를 사용할 수는 있지만 필수는 아님

ReplicaSet은 자기가 만들지는 않았지만, 관리해야할 Pod를 식별할 수 있어야하는데, 이때 selector와 label 필드가 사용되는 것이다.

# ReplicaSet의 selector
spec:
    ...
    # 나는 pod가 어디에서 생성되었는지 상관 없이, label이 'type: front-end'인 pod를 관리할거야
    selector:
        matchLabels:
            type: front-end

# Pod의 label 정보
metadata:
    name: mypod-fe
    labels:
        type: front-end

미리 만들어진 Pod가 3개가 있는데, ReplicaSet의 desired replica가 5라면, ReplicaSet은 2개의 Pod만 생성한다.

Scaling

ReplicaSet을 통해 3개의 Pod를 운영하는 상황에서, Pod를 6개로 늘리고 싶으면 어떻게 할까

여러 방법이 있다.

definition.yaml 수정하고 replace하기

ReplicaSet의 definition file의 replicas필드를 수정하고 replace한다.

kubectl replace -f replicaset-definition.yaml

scale 명령 사용하기

definition file을 전달하기

kubectl scale --replicas=6 -f replicaset-definition.yaml

type, name을 전달하기

kubectl scale --replicas=6 -f replicaset my-replicaset-name

Deployments

Deployment는 말 그대로 배포와 관련한 편의성을 제공하기 위한 k8s Object이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myrs
  labels:
    app: rs

spec:
  template:
    metadata: 
      name: myapp-pod
      labels:
        app: myapp
        type: front-end

    spec: 
      containers:
        - name: nginx-container
          image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

Deployment는 ReplicaSet과 동일한 definition file구조를 가진다.

kubectl create 0f dp-definition.yaml을 통해 Deployment를 생성하면 자동으로 ReplicaSet이 생성되고, ReplicaSet이 생성됨에 따라 자동으로 Pod가 생성된다.

배포와 관련한 편의성

Deployment가 ReplicaSet보다 더 큰 개념인건 알겠는데, 무슨 장점이 있는것일까

Rollout and Versionning

kubectl create dp.yaml을 수행하면 rollout이 트리거된다. 그리고 rollout은 새로운 deployment revision을 생성한다.

새로운 App 버전이 나와서 Container가 변경되면, rollout이 또 트리거되어 새로운 revision이 생성된다.

revision 기록은 계속 누적되고, 이를 통한 버저닝이 가능하다.

# 특정 deployment의 rollout 상태 확인하기
kubectl rollout status deployment/my-deployment-name

# 특정 deployment의 rollout history 확인하기
kubeclt rollout history deployment/my-deployment-name
kube

Deployment Strategy

Deployment에 속한 Pod들을 Update하려고 한다.

1. 기존 Pod delete
2. 신규 Pod create

위와 같은 Recreate전략은 '삭제-생성' 간격동안 서비스를 제공할 수 없다.

Deployment는 대신에 기본값으로 RollingUpdate전략을 사용한다.

RollingUpdate

Recreate전략을 수행할 경우 replicaset은 다음의 흐름으로 작동한다.

1. replicaset의 replicas 값을 0으로 설정 -> pod all delete
2. replicaset의 replicas 값을 5으로 설정 -> pod all create

RollingUpdate전략을 수행할 경우 replicaset은 다음의 흐름으로 작동한다.

1. replicaset-2의 Pod + 1
2. replicaset-1의 Pod -1
3. replicaset-2가 desired state가 될 때 까지 1,2 반복

Rollback

kubectl rollout undo deployment/myapp-deployment

롤백 역시 RollingUpdate기반으로 작동한다.

1. replicaset-1의 Pod + 1 (이전 버전 Pod 생성)
2. replicaset-2의 Pod -1 (현재 버전 Pod 제거)
3. replicaset-1이 desired state가 될 때 까지 1,2 반복

Deployment update

deployment의 definition file을 변경하고 이를 반영하자

apply 명령 사용하기

1. definition file 내용 변경하기 (Ex. replica 개수, pod image 등)
2. kubectl apply -f dp-definition.yaml 수행

그러면 deployment는 기본적으로 rolling update 방식으로 업데이트를 수행할 것이다.

set 명령 사용하기

특정 필드의 값만 지정하여 업데이트 할 수 있다. kubectl set image deployment/my-dp-name nginx-continaer=nginx:1.9.1

변경사항이 definition file에 영구적으로 반영되지 않는 다는 점을 주의해야 한다 (ReplicaSet도 마찬가지)

Services

네트워킹과 관련한 기능을 지원하는 k8s object 세 종류의 타입이 있다.

NodePort

Node에 속한 Pod와 Node의 port를 연결하여 Pod가 accessible하게 만드는 기능

1. TargetPort
   • Service가 요청을 전달하려는 Pod의 포트
2. Port
   • Service의 포트
3. NodePort
   • 외부에서 Pod에 접근하기 위한 Node의 포트

Service는 마치 Node의 가상 서버이다. 클러스터 내부에서 서비스는 고유한 IP(ClusterIP)를 갖는다.

apiVersion: v1
kind: Service
metadata:
    name: myapp-service

spec:ㄹ
    type: NodePort
    ports: # 여러 port를 지정할 수 있다
        - targetPort: 80 # optional: 따로 설정하지 않으면 port과 같은 번호를 사용
          port: 80 # mandatory
          nodePort: 30008 # optional: 따로 설정하지 않으면 30000 ~ 32767값으로 자동 설정
    # 어떤 Pod와 포트를 매핑시킬지 selector를 통해 지정
    selector:
        app: myapp
        type: front-end

## pod-definition.yaml
...
metadat:
    labels:
        app: myapp
        type: front-end
...

# 생성
kubectl create -f service-definition.yaml
# 조회
kubectl get services
# Node의 IP, Port를 통해 Pod에 접근 가능함
curl http://NODE_IP_ADD:NODE_PORT

한 Node에 여러 Pod

한 Node에 여러 Pod이 있는 경우는 어떻게 할까

Pod가 여러 개인 경우에도 별도로 설정 없이, Pod가 1개인 경우처럼 Service의 selector로 Pod의 Label과 매핑하면 알아서 포트 작업을 진행한다.

별도의 설정 없이 Service가 LoadBalancer 기능을 수행한다.

기본 LoadBalance 알고리즘은 'random'
Service definition의 'Algorithm'필드를 통해 방식을 변경할 수 있다.

여러 Node에 여러 Pod

이 경우에도 별다른 설정 없이 없어도, 클러스터 내부의 여러 Node에 걸쳐 작동하는 서비스가 생성되고, 동일한 NodePort를 통해 접근할 수 있게 된다.

ClusterIP

각 계층의 서비스를 여러 Pod들로 지원하는 상황

Pod들은 상태에 따라 계속 생성, 제거를 반복한다. 그런 상황에서 계층간의 연결을 Pod의 IP로 하면 문제가 발생할 것이다.

즉, static한 IP를 가진 클러스터 역할이 필요한데, clusterIP 타입의 서비스로 해결할 수 있다.

apiVersion: v1
kind: Service
metadata:
    name: back-end
spec:
    type: ClusterIP # Service의 기본 type은 ClusterIP
    ports:
        - targetPort: 80 # Pod들의 포트
          port: 80 # Service의 포트
    selector: # Back-end 서버 Pod들의 Label로 식별
        app: myapp
        type: back-end

LoadBalancer

1. 여러 Node에 분산된 Pod들로 구성된 서비스가 존재한다.
2. Node마다 IP 주소가 존재한다.
Q: 사용자는 어떤 IP(Node)로 요청을 보내야 하는가?

apiVersion: v1
kind: Service
metadata:
    name: back-end
spec:
    type: LoadBalancer
    ports:
        - targetPort: 80 # Pod들의 포트
          port: 80 # Service의 포트
          nodePort: 30008 # Node의 포트

클라우드 플랫폼 (Ex. AWS, GCP, ...)에서는 단순히 Service type을 LoadBalancer로 설정하면 알아서 로드밸런싱을 해준다.

on-premise 환경을 직접 구축해야 함

Namespace

참고

참고 Kubernetes for the Absolute Beginners

Container

구체적인 구분이 없다면 Container와 Docker는 동일한 기술을 의미함

1. 사용하려는 컴포넌트가 구동 환경(Ex. OS)과 호환이 되어야 한다.

다음과 같은 경우가 발생할 수 있다.

1. 컴포넌트에 변경이 생기면, 이와 관련된 다른 컴포넌트와의 호환성을 고려해야 한다.
2. 새로운 개발자를 위해 환경을 설정하는 과정이 반복적, 복잡하다.
3. 개발자마다 사용하는 개발 환경이 다를 수 있다.

컴포넌트를 다른 컴포넌트, OS와 독립적으로 관리하기 위해 컨테이너 기술을 사용한다.

컨테이너 기술을 사용함으로써, 컴포넌트들은 각자의 환경, 필요로 하는 라이브러리, 의존성을 사용할 수 있게 된다.

Container란

• 완벽히 독립된 환경을 의미
  • 고유한 프로세스, 서비스를 실행할 수 있음
  • 네트워킹 인터페이스, 저장공간을 가질 수 있음
  • LXC, LXD, LXCFS와 같은 다양한 Container 기술이 존재하나 Docker가 대표적인 기술로 주로 사용된다.
  • 컨테이너는 동일한 OS의 커널을 공유한다

    Docker는 LXC를 기반으로 만들어진 컨테이너 기술
    사용자가 편하게 컨테이너 기술을 사용할 수 있도록 도와주는 것 = Docker

'Docker는 OS kernel을 공유한다'

Docker는 OS kernel을 공유한다의 의미는 크게 두 가지로 풀이될 수 있다.

OS 호환성

Linux환경을 예로 들면,

1. Common Linux Kernel은 하드웨어를 다룰 수 있도록 도와준다.
2. OS(Ex. Ubuntu, Fedora, ...)은 각자만의 유저 인터페이스, 드라이버, 컴파일러, 파일 시스템 등(Set of SW)을 통해 Common Linux Kernel을 Customize한다.

만약 Ubuntu에서 Container를 정의했다면, 그 Container는 Fedora에서도 사용할 수 있다. 즉, 같은 OS Kernel을 사용하는 어떠한 OS 환경에서도 공유할 수 있는 것이다.

그러므로, Ubuntu에서 정의한 컨테이너를 Fedora에서는 실행시킬 수 있는데, Windows에서는 실행시킬 수 없다.

Docker는 OS에 맞게, 필요한 Set of SW만 변경해서 OS 호환성을 지원한다.

VM에 구분되는 Container의 특성

Virtual Machine은 Host OS와는 별도로 각자마다 OS를 가진다. 그렇기 때문에 Container에 비해 상대적으로 Utilazation, Isolation이 높다. 그러나 더 큰 Size를 차지하고, Boot up 시간을 더 요구한다.

Public Docker Registry

Public Docker Registry (Docker hub)를 통해 미리 만들어진 Docker Image를 공유할 수 있다. 단순히 다음 명령을 통해 Docker Container를 구동시킬 수 있다.

docker run IMAGE_NAME

Image, Container

Image는 일종의 Template, Container는 Image에 대한 Instance

직접 Image를 만들어서 public repository에 공유할 수 있다.

Docker 명령

# Repository에서 Image 불러오기
docker pull IMAGE_NAME

# 컨테이너 목록 확인
docker ps

# 컨테이너 접속
docker exec -u root -it COTAINER_ID(or CONTAINER_NAME) bash

# Docker-compose 실행
docker-compose up -d

# Docker-composer 종료

Database, Schema, Table

참고: PostgreSQL | 스키마(Schema) | 데이터베이스, 스키마, 테이블의 관계

psql 명령어 정리

참고: 알아두면 유용한 psql 명령어 정리

# psql 접속
psql
# 특정 유저가, 특정 DB에 접속
psql -U USER_NAME -d DATABASE_NAME
# 외부 스크립트 실행
psql -f SCRIPT_PATH

-U : 유저
-h : 호스트
-p : 포트
-d : Traget DB
# 데이터베이스 목록 조회
\list (\l)
# 데이터베이스 전환
\c DATABASE_NAME
# 유저 목록 조회
\du
# 유저 변경
\c USER_NAME DATABASE_NAME
# 외부 Query Script 실행
\i QUERY_SCRIPT_PATH

# 테이블 describe
\d+ TABLE_NAME

PostgreSQL 특화 쿼리

ON CONFLICT DO UPDATE

ENUM

참고 psql 공식문서

참고 [Golang] Package 1. Go 패키지

패키지

• 코드를 묶는 기본 단위 -> 모든 코드는 반드시 패키지로 묶어야 함.

표준 라이브러리

• Go가 미리 제공하는 라이브러리
• GOROOT/pkg 안에 존재한다.

  GOROOT, GOPATH

  터미널에 go env명령을 치면 여러 정보들이 출력된다.

  GOPATH="/Users/wonju/go"
  ...
  GOROOT="/usr/local/go" // `GOROOT`는 Go 설치 디렉토리를 가리킨다.
  ...

패키지를 import 할 때, Go 컴파일러는 GOROOT, GOPATH 환경변수를 사용하여, 다음과 같은 위치에서 패키지를 찾는다.

1. 표준 패키지는 GOROOT/pkg
2. 사용자 패키지, 3rd Party 패키지는 GOPATH/pkg

GOROOT는 Golang설치시에 자동으로 시스템에 설정되지만, GOPATH는 사용자가 지정해야 한다.

main package, main func

main패키지를 제외한 다른 패키지들은 main함수를 포함하지 않고, main패키지의 의 보조 패키지로 취급된다.

일반적인 패키지는 라이브러리로 사용되는 반면, main패키지는 Go Compiler에 의해 특별하게 인식된다. 컴파일러는 main패키지를 공유 라이브러리가 아닌 실행(executable) 프로그램으로 만든다.

main패키지의 main함수는 프로그램의 Entry Point로 사용된다. 따라서 패키지를 공유 라이브러리로 만들 때에는, main 패키지나 main 함수를 사용해서는 안된다.

Module

참고: [Golang] Module

참고 한 눈에 끝내는 고랭 기초 - 채널

package main

import "fmt"

func main() {
    a := 1
    b := 2
    result := 0

    func() {
        result = a + b
    }()

    fmt.Println(result) // 3
}

클로저를 통해 result == 3임을 알 수 있다. 클로저(익명 함수)도 Goroutine으로 호출할 수 있다.

package main

import "fmt"

func main() {
    a := 1
    b := 2
    result := 0

    go func() {
        result = a + b
    }()

    fmt.Println(result) // 0
}

그런데 결과값이 3이 아닌 0이 나온다. 앞서 살펴봤듯, Goroutine이 종료되기를 기다리지 않기 때문이다.

package main

import "fmt"

func main() {
    a := 1
    b := 2
    result := 0

    go func() {
        result = a + b
    }()

    // s1. 억지로 Goroutine 끝날때 까지 기다리기
       // time.Sleep(time.Duration(1000))

    // s2. fmt.Scanln으로 강제로 block
    // s3. sync.WaitGroup 사용하기

    fmt.Println(result) // 0
}

크게 3가지 방법으로 해결할 수 있을 것 같은데, 생각해 보면 세 방법 모두 Goroutine이 끝나기를 기다리는 것이지, Goroutine의 흐름을 제어하는건 아니다.

Channel은 두 용도로 사용된다.

1. 고루틴 사이에서 값을 주고받는 통로 역할을 하고, 송/수신자가 서로를 기다리는 속성때문에 고루틴의 흐름을 제어함
2. 채널의 데이터를 주고 받을때까지 해당 고루틴을 종료하지 않아 별도의 lock을 하지 않고도 데이터를 동기화함

Channel은 다음과 같이 사용한다.

package main

import (
    "fmt"
)

func main() {
    a := 1
    b := 2
    result := 0

    channel := make(chan int)

    go func() {
        channel <- a + b
    }()

    result = <-channel

    fmt.Println(result)
}

Goroutine에서 채널에 데이터를 <- 키워드로 송신한다. Goroutine에서 받은 데이터를 <- 키워드로 변수에 할당할 수 있다. (꼭 변수에 할당해야 하는건 아니다)

중요한 점은 Goroutine의 종료 시점이다.

package main

import (
    "fmt"
)

func main() {
    defer fmt.Println("main function finished")
    a := 1
    b := 2
    result := 0

    channel := make(chan int)

    go func() {
        defer fmt.Println("Goroutine finished")
        channel <- a + b
    }()

    fmt.Println(result)
}

Goroutine A (main)에서 Goroutine B (익명 함수)에서 송신한 데이터를 사용하지 않고 있다.

// 실행 결과
0
main function finished

Goroutine B는 Goroutine A에서 데이터를 수신할 때 까지 기다린다. 그런데 Goroutine A에서 데이터를 수신하지 않았으므로, Goroutine A가 종료되었음에도 Goroutine B는 종료되지 않는다. 따라서 Goroutine finished는 출력되지 않는 것이다.

Deadlock

다음과 같은 상황이 있다.

package main

import "fmt"

func main() {
    c := make(chan string)

    c <- "Hello goorm!"

    fmt.Println(<-c)
}

메인 함수에서 채널을 통해, 다른 고루틴으로 데이터를 보내려고한다. 그런데 채널을 통해 데이터를 수신하는 고루틴이 없다. 즉, 다른 고루틴에서 데이터를 수신하지 않으므로 메인 함수 고루틴은 종료되지 않고 Deadlock에 빠지게 된다.

이 예제를 통해, 송/수신을 위한 고루틴을 만들고 수신자와 송신자가 1:1 대응하지 않으면 DeadLock에 빠질 수도 있다는 사실을 알 수 있다.

채널 버퍼

그런데 고루틴에서 채널을 통해 송신하는 데이터를, 다른 고루틴에서 항상 수신하도록 하는건 불편하다.

이를 송신자, 수신자가 채널 버퍼를 통해 데이터를 전송하도록 함으로써 해결할 수 있다. 이미지 출처: 한 눈에 끝내는 고랭 기초 - 비동기 채널과 버퍼

package main

import "fmt"

func main() {
    channel := make(chan string) // 채널 생성
    buffer := make(chan string, 1) // 크기가 1인 버퍼 생성

    buffer <- "Hello goorm!"

    fmt.Println(<-buffer) // 정상적으로 출력 후 종료된다.
}

채널 버퍼는 다음의 규칙을 따른다.

1. 송신 루틴은 버퍼가 가득차면 대기한다.
   • 보내고 할 일을 함.
   • 보낸 순간 버퍼가 가득찼으면 대기, 버퍼에 빈 공간이 생기면 하던 일 마저 끝냄.
2. 수신 루틴은 버퍼에 값이 없으면, 버퍼에 값이 들어올 때까지 대기한다.

package main

import (
    "fmt"
    "sync"
)

func main() {
    wg := new(sync.WaitGroup)
    wg.Add(1)
    buffer := make(chan int, 5)

    go produce(buffer)
    go consume(buffer, wg)
    wg.Wait()
}

func produce(buffer chan int) {
    for i := 0; i < 10; i++ {
        buffer <- i
        fmt.Println("produce: ", i)
    }
}

func consume(buffer chan int, wg *sync.WaitGroup) {
    for i := 0; i < 10; i++ {
        num := <-buffer
        fmt.Println("consume: ", num)
    }
    wg.Done()
}

1. produce와 consume은 각각 별도의 고루틴으로 실행된다.
2. produce는, consume 여부와 상관없이 루프를 돌면서 값을 넣는다.
   • 그 과정에서 버퍼가 꽉차면 block
3. consume은 produce 여부와 상관없이 루프를 돌면서 값을 꺼낸다.
   • 그 과정에서 버퍼가 비어있으면 block

그러면 동일한 상황에서, consume하는 데이터의 개수가 더 많으면 어떻게 될까?

package main

import (
    "fmt"
    "sync"
)

func main() {
    wg := new(sync.WaitGroup)
    wg.Add(1)
    buffer := make(chan int, 5)

    go produce(buffer)
    go consume(buffer, wg)
    wg.Wait()
}

func produce(buffer chan int) {
    for i := 0; i < 10; i++ {
        buffer <- i
        fmt.Println("produce: ", i)
    }
}

func consume(buffer chan int, wg *sync.WaitGroup) {
    // 프로듀서는 10개만 생성하는데, 컨슈머는 100개의 데이터를 소비함
    for i := 0; i < 100; i++ {
        num := <-buffer
        fmt.Println("consume: ", num)
    }
    wg.Done()
}

컨슈머는 버퍼가 비어있으면 데이터가 생길 때 까지 기다린다. 그런데 데이터는 10개밖에 생기지 않으므로 결국 consumer는 deadlock에 빠지게 된다.

따라서 송/수신 채널의 개수를 잘 맞춰야한다.

채널 닫기

Deadlock이 발생하는 상황을 정리하자면 다음과 같다.

if Produce 개수 < Consume 개수 {
    Consumer goroutine이 무한 대기
}

package main

import "fmt"

func main() {
    channel := make(chan bool, 2)
    channel <- true
    channel <- true

    fmt.Println(<-channel)
    fmt.Println(<-channel)
    fmt.Println(<-channel) // 비어있는 채널을 읽으면 deadlock 발생
}

위와 같은 상황에서 채널을 닫으면 어떻게 될까

package main

import "fmt"

func main() {
    channel := make(chan string, 2)
    channel <- "hello"
    channel <- "world"

    value, isOpen := <-channel
    fmt.Println(value, isOpen) // hello true
    value, isOpen = <-channel
    fmt.Println(value, isOpen) // world true
    close(channel)
    value, isOpen = <-channel
    fmt.Println(value, isOpen) // "" false
}

1. 채널에 값이 없는 경우, 닫힌 채널에서 값을 읽으면 데드락이 발생하지 않고 빈 값을 반환한다.

      primitive type이면 기본값
    pointer 등이면 nil

   • 닫힌 채널에 값을 읽는 시도는 할 수 있다.

2. 닫힌 채널에 값을 넣으면 panic이 발생한다. (send on closed channel)

   채널 iterate

   무한 루프

   package main
   

import "fmt"

func main() { channel := make(chan string, 2) channel <- "hello" channel <- "world"

for {
    if value, isOpen := <-channel; isOpen {
        fmt.Println(value, isOpen)
    } else {
        break
    }
}

}

isOpen이 false가 되려면, 채널이 close되어야만 한다.
그런데 위 코드는 채널이 닫히지 않았으므로 무한 루프, 즉 Deadlock에 빠지게 된다.

그러므로 채널을 for loop돌려면 close 해야 한다.
``` go
package main

import "fmt"

func main() {
    channel := make(chan string, 2)
    channel <- "hello"
    channel <- "world"

    close(channel)

    for {
        if value, isOpen := <-channel; isOpen {
            fmt.Println(value, isOpen)
        } else {
            break
        }
    }
}

채널 + for range

채널에 for ragne를 도입해서 개선할 수 있다

package main

import "fmt"

func main() {
    channel := make(chan string, 2)
    channel <- "hello"
    channel <- "world"

    close(channel)

    for value := range channel {
        fmt.Println(value)
    }
}

마찬가지로 채널은 close되어야 한다. 채널에 for range를 사용할 경우, isOpen은 사용할 수 없다.

채널 방향

사실 채널은 방향을 정할 수 있다.

방향 = 송신, 수신 여부

기본적으로 채널은 송신, 수신이 가능한데, 목적에 따라 송신만 가능한 채널, 수신만 가능한 채널로 제한할 수 있다.

package main

func main() {
    bidirectionChannel := make(chan int, 2)
    bidirectionChannel <- 100 // 송신 가능
    <- bidirectionChannel // 수신 가능

    transChan := makeTransChan(make(chan int, 2))
    transChan <- 1 // 송신만 가능
    // result := <- transChan: Invalid operation: <- transChan (receive from the send-only type chan<- int)

    receiveChan := makeReceiveChan(make(chan int, 2))
    // receiveChan <- 1: Invalid operation: receiveChan <- 1 (send to the receive-only type <-chan int)
    <- receiveChan // 수신만 가능
}


func TransOnlyChParam(ch <-chan int) {
    fmt.Println(<-ch)
    // ch <- 100: 수신 전용이므로 송신 불가능
}

func makeTransChan(ch chan int) chan<- int {
    return ch
}

func makeReceiveChan(ch chan int) <-chan int {
    ch <- 2
    return ch
}

방향이 생기더라도 채널, 버퍼가 꽉 차거나, 말랐을 때 발생하는 Deadlock문제는 여전히 발생한다.

Select

아래와 같은 코드가 있다.

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan bool)
    ch2 := make(chan bool)

    go func() {
        for {
            time.Sleep(1000 * time.Millisecond)
            ch1 <- true
        }
    }()

    go func() {
        for {
            time.Sleep(500 * time.Millisecond)
            ch2 <- true    
        }
    }()

    go func() {
        for {
            <-ch1
            fmt.Println("ch1 수신")
            <-ch2
            fmt.Println("ch2 수신")
        }
    }()

    time.Sleep(5 * time.Second)
}

두 고루틴(a, b)에서 각각 1초, 0.5초 주기로, 채널에 데이터를 전송한다. 그리고 두 채널에서 전송한 데이터를 고루틴(c)에서 수신한다. 그런데 다음과 같은 조건이 있다.

무조건 ch1를 먼저 수신한 다음에 ch2에서 데이터 수신

ch1에 데이터가 없으면 고루틴(c)이 block되어, ch2에 데이터가 더 빨리 많이 쌓이더라도ch2의 데이터를 사용하지 못하는 상황이 발생한다. (ch2도 결국 1초 주기로 데이터가 순환(?)하는 상황)

이를 Select로 개선할 수 있다.

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan bool)
    ch2 := make(chan bool)

    go func() {
        for {
            time.Sleep(1000 * time.Millisecond)
            ch1 <- true
        }
    }()

    go func() {
        for {
            time.Sleep(500 * time.Millisecond)
            ch2 <- true    
        }
    }()

    go func() {
        for {
            select {
            case dataFromCh1 := <-ch1: // case문에서 변수 선언이 가능하다.
                fmt.Println("ch1 수신", dataFromCh1)
            case <-ch2: // 변수 선언 안 해도 상관 없다.
                fmt.Println("ch2 수신")
            case ch1 <- bool: // case문에서 송신도 가능하다.
            }
        }
    }()

    time.Sleep(5 * time.Second)
}

1. select문을 사용함으로써, ch2는 ch1의 수신 여부와 상관없이 데이터를 사용할 수 있게 된다.
2. ch1, ch2에 데이터가 없다면, 마지막 case문에서 데이터를 송신한다.

   오답 노트

   아래 코드는 Deadlock에 빠진다. 왜 그럴까

   package main
   

import ( "fmt" "sync" )

func main() { channel := make(chan bool) channel <- true

wg := new(sync.WaitGroup)
wg.Add(1)

go func() {
    result := <-channel
    fmt.Println(result)
    wg.Done()
}()

wg.Wait()

}

1. 채널에 데이터를 넣는다. 
2. 채널이 꽉 찼으므로, 메인 고루틴은 block
3. 그런데 WaitGroup, 익명 함수(고루틴)을 실행하지 않은 상태로 block되었으므로 Deadlock에 빠진다.

다음 처럼 해결할 수 있다.
``` go
package main

import (
    "fmt"
    "sync"
)

func main() {
    channel := make(chan bool)
    wg := new(sync.WaitGroup)
    wg.Add(1)
    go func() {
        result := <-channel
        fmt.Println(result)
        wg.Done()
    }()

    channel <- true
    wg.Wait()
}

또는 버퍼를 가득 채우지 않는 방식으로도 해결할 수 있을 것 같다.

package main

import (
    "fmt"
    "sync"
)

func main() {
    channel := make(chan bool, 2)
    channel <- true // 버퍼가 꽉 차지 않았으므로 블록되지 않는다.

    wg := new(sync.WaitGroup)
    wg.Add(1)

    go func() {
        result := <-channel
        fmt.Println(result)
        wg.Done()
    }()

    wg.Wait()
}

이런 상황에서 waitGroup이 없다면, 메인 함수가 익명함수를 기다리지 않고 먼저 종료될 수도 있다.

논리적 가상 스레드

Golang은 Goroutine을 통해 스레드보다 훨씬 가벼운 비동기 동시 처리를 지원한다. 각각의 일에 대해 스레드와 1대 1로 대응하지 않고, 훨씬 적은 스레드를 사용한다.

메모리 측면에서, 스레드가 1MB의 스택을 갖을 때, 고루틴은 훨씬 작은 KB 단위의 스택을 갖고 필요시에 동적으로 증가한다. 또한 Gochannel을 이용해 Goroutine간의 통신도 용이하게 할 수 있다.

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func main() {
    for i := 0; i < 10; i++ {
        go printRandom(i)
    }

    fmt.Scanln()
}

func printRandom(idx int) {
    randomSleepTime := rand.Intn(5)
    time.Sleep(time.Duration(randomSleepTime * 1000))
    fmt.Println(idx)
}

10개의 Goroutine을 띄워서 비동기적으로 index를 출력하는 모습을 확인해보자.

그런데 실행하면 아무것도 출력하지 않고 프로그램이 종료된다. main에서 단순히 Goroutine을 호출시키기만 하고 기다리지 않고 종료되기 때문이다. (마치 JavaScript에서 async를 await하지 않는 것과 동일?)

그래서 일단은 억지로 main이 종료되지 않도록 해보자

``` go
package main

import (
    "fmt"
    "math/rand"
    "time"
)

func main() {
    for i := 0; i < 10; i++ {
        go printRandom(i)
    }

    fmt.Scanln() // 사용자 입력이 들어올 때 까지 block
}

func printRandom(idx int) {
    randomSleepTime := rand.Intn(5)
    time.Sleep(time.Duration(randomSleepTime * 1000))
    fmt.Println(idx)
}

그러면 다음과 같이 비동기적으로 출력됨을 확인할 수 있다.

0
5
7
3
...

근데 딱봐도 fmt.Scanln을 사용해서 억지로 block하는건 아닌거 같다. 다른 방법으로 해결하자.

sync.WaitGroup

sync패키지의 WaitGroup을 사용해서 Goroutine이 완료될 때 까지 기다릴 수 있다.

package sync

import (
    "internal/race"
    "sync/atomic"
    "unsafe"
)

type WaitGroup struct {
    noCopy noCopy

    state atomic.Uint64 // high 32 bits are counter, low 32 bits are waiter count.
    sema  uint32
}

func (wg *WaitGroup) Add(delta int) {...}
func (wg *WaitGroup) Done() {...}
func (wg *WaitGroup) Wait() {...}

Add

Goroutine 추가

Done

Goroutine 제거

Wait

모든 Goroutine이 제거될 때 까지 기다리기

사용법을 보면 바로 이해가 된다.

package main

import (
    "fmt"
    "math/rand"
    "sync"
    "time"
)

func main() {
    wait := new(sync.WaitGroup)
    for i := 0; i < 10; i++ {
        wait.Add(1) // 기다릴 Goroutine 개수++
        go printRandom(i, wait) // waitGroup을 전달
    }
    wait.Wait() // 기다릴 Goroutine 개수가 0이 될 때 까지 block
}

func printRandom(idx int, wait *sync.WaitGroup) {
    defer wait.Done() // 함수가 종료되면 == Goroutine이 작업을 완료하면 기다릴 Goroutine 개수--
    randomSleepTime := rand.Intn(5)
    time.Sleep(time.Duration(randomSleepTime) * time.Second)
    fmt.Println(idx)
}

WaitGroup, Goroutine과 클로저의 관계는 Channel에서 다루겠다.

다중 CPU 환경: runtime Package

Goroutine을 사용해서 간단하게 함수를 비동기로 호출할 수 있다. 그리고 runtime 패키지를 사용하면 다중 CPU를 이용한 병렬처리를 할 수 있다.

package main

import (
    "fmt"
    "runtime"
    "sync"
)

func main() {
    sum := 0
    wait := new(sync.WaitGroup)

    fmt.Println(runtime.NumCPU()) // 실행 환경의 CPU 개수
    runtime.GOMAXPROCS(200)       // 사용할 CPU 개수를 명시적으로 지정 가능
    fmt.Println(runtime.NumCPU()) // 실행 환경의 물리적 CPU 최대 개수로 설정된다.

    for i := 1; i <= 100; i++ {
        wait.Add(1)
        go add(&sum, i, wait)
    }
    wait.Wait()
    fmt.Print("sum: ", sum)
}

func add(sum *int, i int, wait *sync.WaitGroup) {
    defer wait.Done()
    *sum += i
}

Goroutine을 사용해서 1부터 100까지의 합을 구하면 항상 5050이 나오지 않는다. 멀티 코어 CPU가 Goroutine들을 효과적으로 처리하기 때문에, sum에 대해 race condition이 존재하기 때문이다.

runtime.GOMAXPROCS(1) // 단일 CPU 환경에서는 예상대로 race condition이 사라진다.

단일 CPU 환경에서는 예상대로 5050을 확인할 수 있다.

참고

1.5 이전 버전에는, 따로 runtime.GOMAXPROCS를 설정하지 않으면 기본적으로 1개의 CPU 코어만 사용한다.

참고 한 눈에 끝내는 고랭 기초 - 에러 처리의 기본

error interface & errors package

package main

import "fmt"

func main() {
    input := 0
    count, err = fmt.Scanln(&input)
    1
    if err != nil {
        return
    }
    ...
}

// builtin.go

// The error built-in interface type is the conventional interface for
// representing an error condition, with the nil value representing no error.
type error interface {
    Error() string
}

fmt.Scanln 반환하는 에러 객체는 error 인터페이스이다. Go는 error 인터페이스 구현체를 제공하는데, 이것이 erros 패키지의 errorString이다.

// because the former will succeed if err wraps an *fs.PathError.
package errors

// New returns an error that formats as the given text.
// Each call to New returns a distinct error value even if the text is identical.
func New(text string) error {
    return &errorString{text}
}

// errorString is a trivial implementation of error.
type errorString struct {
    s string
}

func (e *errorString) Error() string {
    return e.s
}

그래서 다음의 방법으로 에러를 반환할 수 있다.

package main

import (
    "fmt"
    "errors"
)

func main() {
    var a, b int
    nm err := fmt.Scanln(&a, &b)

    if err != nil {
        panic(err)
    }

    result, err2 := getResult(a, b)

    if err2 != nil {
        panic(err2)
    }
}

func getResult(a int, b int) (int, error) {
    if a == 0 {
        return -1, errors.New("a should not be zero")
    }
    return a + b
}

log package

위 코드처럼 panic을 사용하면 프로그램이 종료된다.

의도에 따라 틀린 방법은 아닌데, 보통은 예외처리를 위해 log 패키지 기능을 사용한다.

package mina

import "log"

func main() {

    log.Print(err) // log.Println(err)
    log.Fatal(err)
    log.Panic(err)
}

크게 3가지 종류의 함수를 제공한다.

Print

시간, 에러 정보를 출력하고 계속 프로그램이 진행된다.

Fatal

시간, 에러 정보를 출력하고 정상적으로 프로그램이 종료된다.

Panic

시간, 에러 정보를 출력하고 Panic을 발생시킨다. defer 구문이 없다면 런타임 패닉이 발생하고 비정상적으로 프로그램이 종료된다.

즉, Panic()을 호출한 것과 동일하다.

package main

import (
    "errors"
    "fmt"
    "log"
)

func main() {
    var input1, input2 int
    _, err1 := fmt.Scanln(&input1, &input2)

    if err1 != nil {
        log.Fatal(err1) // 에러가 있으면 그냥 종료
    }

    defer panicHandler()

    result, err2 := getResult(input1, input2)

    if err2 != nil {
        log.Panic(err2) // 에러가 있으면 Panic호출
    }

    fmt.Println("result is : ", result)
}

func getResult(input1 int, input2 int) (int, error) {
    if input1 == 0 {
        return -1, errors.New("input1 should not be zero")
    }
    return input1 + input2, nil
}

func panicHandler() {
    fmt.Println("handle panic situation")
}

실행 결과는 다음과 같다.

// log.Panic(err2)으로 출력된 에러 메시지
2023/04/22 14:56:21 input1 should not be zero
// defer 구문을 사용해서 main 메서드 종료 전에 호출된 panicHanlder
handle panic situation
// panic을 호출했으므로 에러 메시지가 출력되고 비정상 종료
panic: input1 should not be zero

package study.querydsl.repository;


import com.querydsl.core.BooleanBuilder;
import com.querydsl.core.types.Predicate;
import com.querydsl.jpa.impl.JPAQueryFactory;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import org.springframework.util.StringUtils;
import study.querydsl.dto.MemberSearchCondition;
import study.querydsl.dto.MemberTeamDto;
import study.querydsl.dto.QMemberTeamDto;
import study.querydsl.entity.Member;

import javax.persistence.EntityManager;
import java.util.List;
import java.util.Optional;

import static study.querydsl.entity.QMember.member;
import static study.querydsl.entity.QTeam.team;

@Repository
@RequiredArgsConstructor
public class MemberJpaRepository {

    private EntityManager em;
    private JPAQueryFactory qf;

    public Long save(Member member) {
        em.persist(member);
        return member.getId();
    }

    public Optional<Member> findById(Long id) {
        return Optional.ofNullable(em.find(Member.class, id));
    }

    public Optional<Member> findById_query(Long id) {
        return Optional.ofNullable(qf.selectFrom(member).where(member.id.eq(id)).fetchOne());
    }

    public List<Member> findByUsername(String username) {
        return em.createQuery("SELECT m FROM Member m WHERE m.username = :username", Member.class).setParameter("username", username).getResultList();
    }

    public List<Member> findByUsername_query(String username) {
        return qf.selectFrom(member).where(member.username.eq(username)).fetch();
    }

    public List<Member> findAll() {
        return em.createQuery("SELECT m FROM Member m", Member.class).getResultList();
    }

    public List<Member> findAll_query() {
        return qf.selectFrom(member).fetch();
    }

    public List<MemberTeamDto> searchByBuilder(MemberSearchCondition condition) {
        BooleanBuilder booleanBuilder = new BooleanBuilder();
        if (StringUtils.hasText(condition.getUsername())) {
            booleanBuilder.and(member.username.eq(condition.getUsername()));
        }
        if (StringUtils.hasText(condition.getTeamName())) {
            booleanBuilder.and(team.name.eq(condition.getTeamName()));
        }
        if (condition.getAgeGeo() != null) {
            booleanBuilder.and(member.age.goe(condition.getAgeGeo()));
        }
        if (condition.getAgeLoe() != null) {
            booleanBuilder.and(member.age.loe(condition.getAgeLoe()));
        }
        return qf
                .select(new QMemberTeamDto(
                        member.id.as("memberId"),
                        member.username,
                        member.age,
                        team.id.as("teamId"),
                        team.name.as("teamName")
                ))
                .from(member)
                .leftJoin(member.team, team)
                .where(booleanBuilder)
                .fetch();
    }

    public List<MemberTeamDto> searchMember(MemberSearchCondition condition) {
        return qf
                .select(new QMemberTeamDto(
                        member.id.as("memberId"),
                        member.username,
                        member.age,
                        team.id.as("teamId"),
                        team.name.as("teamName")
                ))
                .from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGeo()),
                        ageLoe(condition.getAgeLoe())
                )
                .fetch();
    }

    private Predicate ageLoe(Integer ageLoe) {
        return member.age.loe(ageLoe);
    }

    private Predicate ageGoe(Integer ageGeo) {
        return member.age.goe(ageGeo);
    }

    private Predicate teamNameEq(String teamName) {
        return StringUtils.hasText(teamName) ? team.name.eq(teamName) : null;
    }

    private Predicate usernameEq(String username) {
        return StringUtils.hasText(username) ? member.username.eq(username) : null;
    }
}

참고: 실행 환경 분리하기

# src/main/resources/application.yml
# 로컬 실행 환경
spring:
    profiles:
        active: local

# src/main/test/resources/application.yml
# 테스트 환경
spring:
    profiles:
        active: test

App을 실행시키면 profile: local로 설정된다. Test 코드를 실행시키면 profile: test로 설정된다.

로컬 환경에서만 작동하는 코드 만들기

@Profile("local")
@Component
@RequiredArgsConstructor
public class InitMember {

    private final InitMemberService initMemberService;

    @PostConstruct
    public void init() {
        initMemberService.init();
    }

    @Component
    static class InitMemberSerivce {
        @PersistenceContext
        private EntityManager em;

        @Transactional
        public void init() {
            // DB에 데이터 넣는 코드
        }
    }
}

Spring Data JPA + QueryDSL

간단한 기능은 JpaRepository로 해결할 수 있는데, 동적 쿼리는 QueryDSL로 해결하는게 좋다.

사용자 정의 레포지토리를 사용해서 JpaRepository와 QueryDSL을 합칠 수 있다.

// MemberRepositoryCustom (interface)
public interface MemberRepositoryCustom {
    List<MemberTeamDto> search(MemberSearchCondition condition);
}

// MemberRepositoryImpl
public class MemberRepositoryImpl implements MemberRepositoryCustom {

    private final JPAQueryFactory qf;

    public MemberRepositoryImpl(EntityManager em) {
        qf = new JPAQueryFactory(em);
    }

    @Override
    public List<MemberTeamDto> search(MemberSearchCondition condition) {
        return qf
            ...
    }
}

// MemberRepository (JpaRepository)
public interface MemberRepository extends JpaRepository<Member, Long>, MemberRepositoryCustom {

    List<Member> findByUsername(String username);
}

만약 MemberRepositoryCustom이 제공하는 기능이 범용적이지 않고 너무 특화(?)된 기능이라면, 사용자 정의 레포지토리가 아닌 별도의 Repository Class로 구현한 뒤, Bean으로 등록해서 DI하는게 좋다.

페이징

Spring Data가 제공하는 Page, Pageable와 QueryDSL을 연동할 수 있다.

// MemberRepositoryCustom
public interface MemberRepositoryCustom {
    List<MemberTeamDto> search(MemberSearchCondition condition);

    Page<MemberTeamDto> searchPage(MemberSearchCondition condition, Pageable pageable);
}
// MemberRepositoryImpl
public class MemberRepositoryImpl implements MemberRepositoryCustom {

    @Override
    public Page<MemberTeamDto> searchPage(MemberSearchCondition condition, Pageable pageable) {
        QueryResults<MemberTeamDto> results = qf
                .select(new QMemberTeamDto(
                        member.id.as("memberId"),
                        member.username,
                        member.age,
                        team.id.as("teamId"),
                        team.name.as("teamName")
                ))
                .from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGeo()),
                        ageLoe(condition.getAgeLoe())
                )
                .offset(pageable.getOffset()) // 시작 페이지 번호
                .limit(pageable.getPageSize()) // 데이터 개수
                .fetchResults();
        List<MemberTeamDto> content = results.getResults();
        long total = results.getTotal();
        return new PageImpl<>(content, pageable, total);
    }

앞서 살펴봤듯이,

1. getResults는 페이징 데이터, 총 개수를 구하기 위해 쿼리가 두 번 발생한다.
2. getResults를 통해 발생한 총 개수 구하는 쿼리는 메인 쿼리의 join, where문을 따라간다.
   • 즉, 단순히 총 개수만 구하는 쿼리인데 불필요한 join, where문이 발생할 수도 있다.
3. getResults는 deprecated

개선

페이징 데이터와 총 개수를 별도로 구하도록 하자.

    @Override
    public Page<MemberTeamDto> searchPage_simple(MemberSearchCondition condition, Pageable pageable) {
        // 첫 번째 쿼리로 데이터만 불러온다.
        List<MemberTeamDto> content = qf
                .select(new QMemberTeamDto(
                        member.id.as("memberId"),
                        member.username,
                        member.age,
                        team.id.as("teamId"),
                        team.name.as("teamName")
                ))
                .from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGeo()),
                        ageLoe(condition.getAgeLoe())
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .fetch();
        // 카운트는 명시적으로 별도의 쿼리를 발생시킨다.
        long total = qf
                .select(member)
                .from(member)
                .leftJoin(member.team, team)
                .where(
                        usernameEq(condition.getUsername()),
                        teamNameEq(condition.getTeamName()),
                        ageGoe(condition.getAgeGeo()),
                        ageLoe(condition.getAgeLoe())
                ).fetchCount();
        return new PageImpl<>(content, pageable, total);
    }

개선2

    ...
    JPAQuery<Member> countQuery = qf
            .select(member)
            .from(member)
            .leftJoin(member.team, team)
            .where(
                    usernameEq(condition.getUsername()),
                    teamNameEq(condition.getTeamName()),
                    ageGoe(condition.getAgeGeo()),
                    ageLoe(condition.getAgeLoe())
            );
    return PageableExecutionUtils.getPage(content, pageable, countQuery::fetchCount);

Spring Data의 최적화를 사용해서, 상황에 따라 CountQuery를 발생시키지 않도록 할 수도 있다.

한 페이지에 보여줄 데이터가 20건인데, 검색 결과가 3건 밖에 없음. 
어차피 1 페이지 밖에 없으니까, 총 페이지 개수를 개산하기 위한 
'총 개수' 쿼리를 날릴 필요 없다. 

기본

List<String> fetch = qf.select(member.username).from(member).fetch();
List<Member> fetch = qf.selectFrom(member).fetch();

프로젝션 대상이 하나인 경우에는 타입을 명확히 지정할 수 있다.

List<Tuple> fetch = qf.select(member.username, member.age).from(member).fetch();

for (Tuple tuple : fetch) {
    String username = tuple.get(member.username);
    Integer age = tuple.get(member.age);
}

프로젝션 대상이 둘 이상인 경우에는 Tuple을 사용해야 한다.

다른 계층에서는 특정 기술(QueryDSL)에 의존적이면 안 된다. 따라서 Tuple을 다른 계층에 넘기지 말고, DTO로 변환해서 전달해야 한다.

DTO

순수 JPA로 DTO를 다루려면 다음과 같을 것이다.

List<MemberDto> memberDtos = em.createQuery(
    "SELECT new 패키지명.MemberDto(m.username, m.age) FROM Member m",
    MemberDto.class
).getResultList();

순수 JPA로 DTO를 다룰 때의 단점

1. DTO의 패키지 명을 반드시 명시해야 한다.
2. 생성자 방식으로만 객체를 만들 수 있다.

QueryDSL에서는 세 가지 방법으로 DTO를 다룰 수 있다.

Projections.bean

List<MemberDto> fetch = qf
        .select(Projections.bean(MemberDto.class, 
                member.username, 
                member.age))
        .from(member)
        .fetch();

1. 기본 생성자로 객체 생성 후, Setter를 통해 값을 할당한다.
2. 따라서 기본 생성자와 Setter가 반드시 있어야 한다.

   Projections.field

   List<MemberDto> fetch = qf
        .select(Projections.fields(MemberDto.class,
                member.username,
                member.age))
        .from(member)
        .fetch();

3. Setter를 사용하지 않고, 필드명을 인식하여 값을 할당한다.
4. 따라서 Member Entity의 필드명과, DTO의 필드명이 일치해야 한다.

   Member Entity의 필드명과, DTO의 필드명이 일치해야 한다.

   만약 Member Entity는 username이라는 필드명을 사용하는데, MemberDto는 name이라는 필드명을 사용하면 name필드에 null이 할당된다.

이렇게 필드명 불일치 문제를 다음과 같이 해결할 수 있다.

List<MemberDto> fetch = qf
        .select(Projections.fields(MemberDto.class,
                member.username.as("name"),
                member.age))
        .from(member)
        .fetch();

SELECT 절 Subquery에 별칭 부여하기

DTO + Projections.field를 사용하려면 DTO 필드명 일치 여부를 주의해야 한다.

따라서 Subquery도 필드명을 일치시켜야 하는데, 다음의 방법으로 할 수 있다.

QMember subMember = new QMember("subMember")

List<MemberDto> fetch = qf
        .select(Projections.fields(MemberDto.class,
                // 위와 동일한 효과
                ExpressionUtils.as(member.username, "username"),
                ExpressionUtils.as( // subquery 결과를 필드로 사용
                    JPAExpressions // subquery 생성 구문
                        .select(subMember.age.max())
                        .from(subMember),
                    "age" // alias
                ))
        .from(member)
        .fetch();

Projections.constructor

List<MemberDto> fetch = qf
        .select(Projections.constructor(MemberDto.class,
                member.username,
                member.age))
        .from(member)
        .fetch();

1. 시그니처가 일치하는 생성자를 통해 객체를 생성한다.

2. 따라서 fields와 달리 필드명은 중요하지 않다.

   @QueryProjection

   DTO를 직접 다루는 방식은 조금 복잡하다. @QueryProjection Annotation으로 개선할 수 있다.

   @Data
   @NoArgsConstructor
   public class MemberDto {
   
    private String username;
    private int age;
   
    @QueryProjection
    public MemberDto(String username, int age) {
        this.username = username;
        this.age = age;
    }
   }

3. 생성자에 @QueryProjection을 붙인다

4. compileQuerydsl로 컴파일 하면 DTO에도 Q-Type이 생성된다.

그런 뒤, 다음과 같이 사용하면 된다.

List<MemberDto> fetch = qf
        .select(new QMemberDto(member.username, member.age))
        .from(member)
        .fetch();

장단점

장점

Projections.consturctor는 컴파일 타임에 문제를 발견할 수 없다.

qf
.select(Projections.constructor(MemberDto.class,
        member.username,
        member.age,
        member.id
))

DTO에 존재하지 않는 member.id를 사용했음에도, 컴파일 타임에 문제를 검출하지 못하고 런타임에 문제가 발생할 수도 있다.

그런데 QueryProjection은 실제 생성자를 사용하는 것이므로, 컴파일 타임에 문제를 발견할 수 있다.

단점

1. Q-Type을 생성, 관리해야 한다.
2. QueryProjection은 QueryDSL의 기술이다.
   • 즉, DTO가 특정 기술에 종속적이게 되는 문제가 발생한다.
   • DTO는 여러 Layer에서 사용하는데, 이는 여러 Layer에서 QueryDSL에 종속적이게 되는 결과로 이어진다.

결론

의존성 문제를 우선한다면 Projection을 사용하자 편의성을 우선한다면 그냥 QueryProjection을 사용하자. 알아서 선택하라는 뜻

동적 쿼리

QueryDSL은 두 가지 방법으로 동적 쿼리를 작성한다.

BooleanBuilder

// 값이 없는 경우(null)에는 WHERE문에서 제외하고 싶은 상황
String username = "username1";
Integer age = 10;

BooleanBuilder booleanBuilder = new BooleanBuilder();
if (username != null) {
    booleanBuilder.and(member.username.eq(username));
}
if (age != null) {
    booleanBuilder.and(member.age.eq(age));
}

List<Member> fetch = qf
        .selectFrom(member)
        .where(booleanBuilder)
        .fetch();

Where 다중 파라미터

// 값이 없는 경우(null)에는 WHERE문에서 제외하고 싶은 상황
String username = "username1";
Integer age = 10;

List<Member> fetch = qf
        .selectFrom(member)
        .where(usernameEq(username), ageEq(age))
        .fetch();

private Predicate ageEq(Integer age) {
    if (age == null) {
        return null;
    }
    return member.age.eq(age);
}

private Predicate usernameEq(String username) {
    if (username == null) {
        return null;
    }
    return member.username.eq(username);
}

1. WHERE의 파라미터가 NULL이면 무시된다는 특징을 활용한 방식
2. 쿼리 재활용, 조립 가능
3. 가독성

조건 조합을 위해, Predicate보다 BooleanExpression을 반환 타입으로 사용하는 것이 좋다.

private BooleanExpression usernameEq(String username) {...}

Where 다중 파라미터 사용 권장

Bulk Operation

Dirty Checking을 사용하지 않고 DB에 직접 쿼리를 날리자. Persistence Context 불일치에 주의해야 한다.

• Bulk Operation 수행 후에 Persistence Context flush, clear 필요

  long count = qf
        .update(member)
        .set(member.username, "older than 30")
        .where(member.age.gt(30))
        .execute();

  SQL Function

  나중에 다루도록 하겠다,,,

스프링 부트 2.6부터 Querydsl 5.0을 사용한다.

buildscript {
    ext {
        queryDslVersion = "5.0.0"
    }
}

plugins {
    ...
    //querydsl 추가
    id "com.ewerk.gradle.plugins.querydsl" version "1.0.10"
}
...
dependencies {
    //querydsl 추가
    implementation "com.querydsl:querydsl-jpa:${queryDslVersion}"
    annotationProcessor "com.querydsl:querydsl-apt:${queryDslVersion}"
    ...
}
...
def querydslDir = "$buildDir/generated/querydsl"
querydsl {
    jpa = true
    querydslSourcesDir = querydslDir
}
sourceSets {
    main.java.srcDir querydslDir
}
configurations {
    querydsl.extendsFrom compileClasspath
}
compileQuerydsl {
    options.annotationProcessorPath = configurations.querydsl
}

compileQuerydsl을 클릭하면 @Entity Annotation이 붙은 Class를 확인하면서 Qxxx라는 이름의 클래스를 생성한다. 즉, Member Entity가 존재하면 QMember라는 클래스가 생기는 것이다. QueryDSL은 Entity를 한 번 감싼(?) Q클래스를 통해 데이터에 접근하는 것이다. querydsl-apt: QClass를 만드는 역할 querydsl-jpa: 쿼리 작성 역할

JPQL vs QueryDSL

유저 이름으로 조회하기

    @Test
    void jqplTest() {
        String query = "SELECT m FROM Member m WHERE m.username = :username";
        Member findMember = em.createQuery(query, Member.class)
                .setParameter("username", "username#1")
                .getSingleResult();
        assertThat(findMember.getUsername()).isEqualTo("username#1");
    }

    @Test
    void queryDslTest() {
        JPAQueryFactory queryFactory = new JPAQueryFactory(em);
        QMember m = new QMember("m");
        Member findMember = queryFactory
                .select(m)
                .from(m)
                .where(m.username.eq("username#1"))
                .fetchOne();
        assertThat(findMember.getUsername()).isEqualTo("username#1");
    }

1. JQPL은 문자열을 다루는 것 과 달리, QueryDSL은 쿼리를 자바 코드를 사용하는 것 처럼 작성한다.
   • 쿼리를 잘못 작성할 걱정이 없다.
   • 파라미터 바인딩을 알아서 해준다.
2. QueryDSL은 컴파일 타임에 쿼리 문법을 검사한다.
   • 런타임에 쿼리 문법 예외가 발생할 일이 없다.

권장

    @Test
    void queryDslTest() {
        JPAQueryFactory queryFactory = new JPAQueryFactory(em);
        QMember m = new QMember("m");
        Member findMember = queryFactory
                .select(m)
                .from(m)
                .where(m.username.eq("username#1"))
                .fetchOne();
        assertThat(findMember.getUsername()).isEqualTo("username#1");
    }

Spring이 주입하는 EntityManager는 Thread Safe하기 때문에, JPAQueryFactory를 필드로 추출해서 사용해도 된다.

    JPAQueryFactory queryFactory = new JPAQueryFactory(em);

    @Test
    void queryDslTest() {
        QMember m = new QMember("m");
        Member findMember = queryFactory
                .select(m)
                .from(m)
                .where(m.username.eq("username#1"))
                .fetchOne();
        assertThat(findMember.getUsername()).isEqualTo("username#1");
    }

기본 문법

Q-Type

QueryDSL은 Q클래스 인스턴스를 통해 데이터에 접근한다.

Q클래스인스턴스는 두 가지 방법으로 사용할 수 있다.

// 1. 별칭 직접 입력
// 입력한 별칭이 SQL문 Table의 별칭으로 사용된다.
// SELECT m1.username FROM Member AS m1
QMember qMember = new QMember("m1");
// 2. 기본 인스턴스 사용
// `Q클래스` 내부적으로 미리 초기화 해놓은 인스턴스를 가지고 있다.
QMember qMember = QMember.member;

2. 기본 인스턴스 사용 사용을 권장한다.

// 1. 기본 사용 
QMember qMember = QMember.member;
// 2. Static Import로 간소화 하기
import static 경로.entity.QMember.*;
QMember member = member; // QMember.member를 간소화

같은 Table을 다룰 때는 Table을 구분해야 하므로, 그때 Alias 방식을 사용한다.

검색 조건 쿼리

qf // queryFactory
.select(member)
.from(member)
.where(
    member.username.eq("a") // username = "a"
    member.username.ne("a") // username != "a"
    member.username.eq("a").not // username != "a"
    member.username.isNotNull() // username is not null

    member.age.in(10, 20) // age IN (10, 20)
    member.age.notIn(10, 20) age NOT IN (10, 20)
    member.age.between(10, 20) age BETWEEN 10 AND 20;

    member.age.goe(30) // age >= 30 (greater or equal)
    member.age.gt(30) // age > 30
    member.age.loe(30) // age <= 30 (less or equal)
    member.age.lt(30) // age < 30

    member.username.like("member%") // like member%
    member.username.contains("member") // like %member%
    member.username.startsWith("member") // like member%
).fetchOne();

검색 조건 쿼리 - And

두 방식으로 And 조건을 설정할 수 있다.

// 1. and() 사용
qf
.select(member)
.from(member)
.where(member.username.eq("a").and(member.age.eq(10)))
// 2. 파라미터로 사용
qf.select(member)
.from(member)
.where(
    member.username.eq("a"),
    member.age.eq(10)
)

2. 파라미터로 사용을 권장함

• 가독성
• 파라미터에 null이 들어가면 알아서 무시함
  • 동적 쿼리 작성할 때 편하다.

결과 조회

// 1. List로 조회
// selectFrom : Entity가 같은 경우 축약 가능 (select + from)
List<Member> members = qf.selectFrom(member).fetch();
// 2. 단건 조회
Member member = qf.selectFrom(member).fetchOne();
// 3. 첫번째 결과만 조회
Member member = qf.selectFrom(member).fetchFirst();
// 4. 복합 결과 (페이징)
// 페이징을 위해 count 개수를 검색하는 쿼리가 발생함 (총 쿼리 2번)
// 최신 버전에서는 deprecated
QueryResults<Member> results = qf.selectFrom(member).fetchResults();
// 5. 데이터 개수 조회 (count)
long total = qf.selectFrom(member).fetchCount();

OrderBy

나이 기준 오름차순, 이름 기준 내림차순, 이름이 null인 경우 뒤에 위치하도록 정렬

List<Member> fetch = qf
    .selectFrom(member)
    .orderBy(member.age.asc(), member.username.desc().nullsLast())
.fetch();

nullsLast: 값이 null인 경우 마지막에 위치 nullsFirst: 값이 null인 경우 앞에 위치

페이징

// 1페이지에서부터 3개 불러오기
List<Member> results = qf
    .selectFrom(member)
    .offset(1).limit(3).fetch();

QueryDSL도 0부터 페이지가 시작한다.

집합

Aggregate Function

List<Tuple> result = qf.select(
        member.count(),
        member.age.sum(),
        member.age.avg(),
        member.age.max(),
        member.age.min()
        )
        .from(member)
        .fetch();
Tuple tuple = result.get(0);
Long count = tuple.get(member.count());
Integer sum = tuple.get(member.age.sum());
Double avg = tuple.get(member.age.avg());
Integer max = tuple.get(member.age.max());
Integer min = tuple.get(member.age.min());

Tuple은 QueryDSL이 제공하는 자료구조이다.

Group By, Having

팀 인원이 10명 이상인 팀의 이름과, 평균 나이

List<Tuple> result = qf
        .select(team.name, member.age.avg())
        .from(member)
        .join(member.team, team)
        .groupBy(team.name)
        .having(team.count().goe(10))
        .fetch();
Tuple team1 = result.get(0);
Tuple team2 = result.get(2);

Join

List<Member> result = qf
        .select(member)
        .from(member)
        // join, innerJoin, leftJoin, rightJoin
        // join을 수행하면 JPA를 따라 Inner Join 발생
        .join(member.team, team) // QTeam.team
        .fetch();

첫 번째 파라미터에 조인 대상을 지정하고, 두 번째 파라미터 alias로 사용할 Q타입을 지정하면 된다.

Join - On

• JPA 2.1부터 On을 사용할 수 있다.

  회원과 팀을 조인하면서, 팀 이름이 A인 팀만 조인, 회원은 모두 조회 (JPQL: SELECT m, t FROM Member m LEFT JOIN m.team t ON t.name = 'A')

  List<Tuple> result = qf
        .selectFrom(member, team)
        .from(member)
        .leftJoin(member.team, team).on(team.name.eq("A"))
        .fetch();

  Outer Join이므로, 팀 A에 속하지 않는 멤버 결과가 포함된다. null에 주의해야 한다.

Inner Join을 사용할 때 필터링 조건을 On에 걸든, Where절에 걸든 결과는 동일하다. 따라서 일관된 스타일을 위해서, Inner Join에서는 익숙한 Where절을 사용하고, Outer Join에 경우에만 On절을 사용하도록 하자.

Join의 대상

join을 사용할 때 두 문법이 있다.

// 1. 일반 조인
qf
.select(member)
.from(member)
.join(member.team, team)
.fetch();
// 2. 조인대상만 사용 + On 절
qf
.select(member)
.from(member)
.join(team).on(member.team.id.eq(team.id))
.fetch()

첫 번째 방식처럼 사용하면 알아서 PK, FK 기준으로 ON절을 구성한다. 즉, SQL ON절에 member.team_id = team.id가 추가된다.

두 번째 방식처럼 사용하면 알아서 PK, FK 기준으로 ON절을 구성하지 않는다. 그러므로 명시적으로 ON절을 설정해 줘야 한다.

연관 관계가 없는 경우

Cross Join (Cartesian Product): N * M

List<Tuple> tuples = qf
        .select(memeber, team)
        .from(member, team)
        .fetch();
// JPQL
SELECT member1, team FROM Member member1, Team team

Theta Join: Caretsian Product에서 특정 조건 (세타 조건)을 만족하는 경우만 반환

유저 이름과 팀 이름이 같은 경우

List<Tuple> result = qf
        .select(member)
        .from(member, team)
        .where(member.username.eq(team.name))
        .fetch();
// JQPL
SELECT member1, team FROM Member member1, Team team WHERE member1.username = team.name

// 그냥 연습용으로 비교
List<Member> members = qf
        .select(member)
        .from(member)
        .where(member.username.eq(member.team.name))
        .fetch();
// JPQL
// 묵시적 JOIN 발생
SELECT member1 FROM Member member1 WHERE member1.username = member1.team.name

Fetch Join

// QueryDSL
List<Member> result = qf
        .select(member)
        .from(member)
        .join(member.team, team).fetchJoin()
        .where(team.name.eq("team1"))
        .fetch();
// JPQL
SELECT m FROM Member m JOIN FETCH m.team t WHERE t.name = "team1"

어떤 Join이든지 fetchJoin()을 같이 사용하면 된다.

fetchJoin을 사용하지 않아도 같은 효과를 낼 수 있다.

// QueryDSL
List<Tuple> team1 = qf
        .select(member, member.team)
        .from(member)
        .join(member.team, team)
        .where(team.name.eq("team1"))
        .fetch();

다만 반환 타입이 Tuple이다.

Subquery

com.querydsl.jpa.JPAExpressions를 사용하여 서브쿼리를 구성할 수 있다.

// 가장 나이가 많은 회원 조회
QMember subQMember = new QMember("sub_member");
List<Member> members = qf
        .selectFrom(member)
        .where(member.age.eq(
            JPAExpressions
                    .select(subQMember.age.max())
                    .from(subQMember)
        ))
        .fetch();

초반부에 다뤘던 것 처럼, 같은 Table(Entity)를 다루므로 Alias를 다르게 해서 구분해야 한다.

// SELECT절 Subquery
QMember subQMember = new QMember("sub_member");
List<Member> members = qf
        .select(
            member,username,
            JPAExpressions
                .select(subQMember.age.avg())
                .from(subQMember))
        .from(member)
        .fetch();

역시나 JPAExpressions도 static import로 분리하여 가독성을 높일 수 있다.

JPA, JPQL이 From절 Subquery를 지원하지 않으므로, QueryDSL도 불가능하다. 다음의 방법으로 해결 할 수 있을 것이다.

1. (가능한 경우) JOIN으로 변경하기
2. 쿼리를 두 번 날려서 변경하기
3. NativeSQL 사용하기

SELECT절 Subquery는 JPA는 불가능한데, Hibernate는 가능해서 QueryDSL도 가능한 것이다.

Case

//Simple CASE Statement
List<String> ages = qf
        .select(member.age
                .when(10).then("ten")
                .when(20).then("twenty")
                .otherwise("??"))
        .from(member)
        .fetch()
// Searched CASE Statement
List<String> ages = qf
        .select(new CaseBuilder()
                .when(member.age.between(0,10)).then("ten")
                .when(member.age.between(11,20)).then("twenty")
                .otherwize("??"))
        .from(member)
        .fetch();

DB에서는 단순히 데이터만 조회하기를 권장한다.

상수, 문자 더하기

// 상수 (Expressions)
List<Tuple> result = qf
                .select(member.username, Expressions.constant("A"))
                .from(member)
                .fetch();
// 문자 더하기 (concat)
List<String> result = qf
                .select(member.username.concat("_").concat(member.age.stringValue()))
                .from(member)
                .fetch();

상수는 JPQL, SQL에는 반영되지 않고, 최종 결과에서만 반영된다. 문자 더하기는 JPQL, SQL에도 반영되서 전달된다.

JpaRepository를 사용하는 상황에서, 다른 종류의 Repository도 같이 사용하고 싶을 수 있다.

다음과 같이 사용할 수 있다.

1. Repository 인터페이스(A) 정의하기

// 순수 JPA로 구현한 Repository도 같이 사용하고 싶은 상황
public interface MemberRepositoryCustom {

    List<Member> findMemberCustom();
}

2. Repository 구현체 만들기 (A의 구현체)

@Repository
@RequiredArgsConstructor
public class MemberRepositoryImpl implements MemberRepositoryCustom{

    private EntityManager em;

    @Override
    public List<Member> findMemberCustom() {
        return em.createQuery(
                "SELECT m FROM Member m",
                Member.class
        ).getResultList();
    }
}

3. 기존 Repository가 상속받도록 하기 (A 상속 받기)

package doodlin.greeting.test;

import org.springframework.data.jpa.repository.JpaRepository;

public interface MemberRepository extends JpaRepository<Member, Long>, MemberRepositoryCustom {
    ...
}

순수 자바 문법 관점에서는 불가능하지만, Spring Data의 도움을 받아서 MemberRepository에서 MemberRepositoryCustom의 구현체MemberRepositoryImpl에 구현된 내용을 사용할 수 있다.

주의사항

1. QueryDSL, JDBC Template을 주로 이러한 방식을 통해 사용한다.

2. 구현체의 이름은 반드시 접미사 Impl로 끝나야 한다.

   • 옵션으로 변경 가능하긴 함
   • 인터페이스 이름은 상관 X

3. 항상 사용자 정의 레포지토리가 필요한 건 아니다.

   • 그냥 별도의 Repository를 만들어서 Bean으로 등록한 뒤 DI해서 사용해도 된다.

   • 순수 Entity만 다루는 Repository와, API 맞춤 Repository는 분리하여 관리하는게 좋다 (유지보수 측면).

     Auditing

     Entity 생성 변경 날짜, 생성 변경 인물을 기록하고 싶다.

순수 JPA

@MappedSuperclass
public class BaseEntity {

    @Column(updatable = false)
    private LocalDateTime createdDate;
    private LocalDateTime updatedDate;

    @PrePersist // @PostPersist
    public void prePersist() {
        LocalDateTime now = LocalDateTime.now();
        createdDate = now;
        updatedDate = now;
    }

    @PreUpdate // @PostUpdate
    public void preUpdate() {
        updatedDate = LocalDateTime.now();
    }
}

// Entity
@Entity
public class Member extends BaseEntity {
    ...
}

Spring Data

설정

@EnableJpaAuditing
@SpringBootApplication
public class DataJpaApplicaton {

    public static void main(String[] args) {...}

    @Bean
    public AuditorAware<String> auditorProvider() {
        return () -> Optional.of(UUID.randomUUID().toString());
    }
}

auditorProvider를 통해 생성자, 변경자 필드에 어떤 값이 들어갈 지 설정할 수 있다. 보통은 Session ID를 넣는다.

Spring 기본 정책상, 생성 당시에 변경 날짜, 변경자도 같이 초기화 하는데, 옵션을 통해 null이 들어가도록 할 수 있다.

  @EnableJpaAuditing(modifyOnCreate = false) // (권장 X).

BaseEntity

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
public class BaseEntity {

    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createdDate;

    @LastModifiedDate
    private LocalDateTime lastModifiedDate;

    @CreatedBy
    @Column(updatable = false)
    private String createdBy;

    @LastModifiedBy
    private String lastModifiedBy;
}

@EntityListeners(AuditingEntityListener.class)을 별도의 XML로 분리해서 글로벌 설정으로 만들 수 있다.

권장 Tip

생성 날짜는 보통 모든 Entity에 사용되는데, 생성자는 특정 Entity에만 사용된다. 그러므로 보통 다음과 같이 사용한다.

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
public class BaseTimeEntity {

    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createdDate;

    @LastModifiedDate
    private LocalDateTime lastModifiedDate;
}

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
public class BaseEntity {

    @CreatedBy
    @Column(updatable = false)
    private String createdBy;

    @LastModifiedBy
    private String lastModifiedBy;
}

Entity에 따라 원하는 baseEntity를 상속받도록 한다.

Web+ : 도메인 클래스 컨버터

참고: Spring Boot REST API Domain Class Converter

ID로 유저 찾기 API

위 요구사항은 아마 아래처럼 구현할 것이다.

@RestController
@RequiredArgsConstructor
public class MemberController {

    private MemberRepository memberRepositry;

    @GetMapping("/api/members/{id}")
    public MemberDto findMember(@PathVariable("id") int id) {
        return new MemberDto(memberRepositry.findById(id));
    }
}

Spring Data JPA를 사용하면 다음 처럼 구현할 수 있다.

@RestController
@RequiredArgsConstructor
public class MemberController {

    private MemberRepository memberRepositry;

    @GetMapping("/api/members/{id}")
    public MemberDto findMember(@PathVariable("id") Member member) {
        return new MemberDto(member);
    }
}

Spring Data JPA가 메서드 시그니처를 보고, DomainNameConverter가 작동해서 Entity를 조회한 뒤 반환하는 것이다. DomainNameConverter는 내부적으로 Repository를 사용한다.

주의사항

트랜잭션 범위 밖에서 조회가 발생했으므로, 조회한 값을 변경해서는 안 된다. 즉, 조회 용도로만 사용해야 한다.

Web+ : 페이징과 정렬

Spring Data가 제공하는 페이징, 정렬 기능을 Spirng MVC에서 편리하게 사용할 수 있다.

@RestController
@RequiredArgsConstructor
public class MemberController {

    // findAll(Pageable): JpaRepository의 부모 인터페이스에 정의된 메서드
    @GetMapping("/api/members")
    public Page<MemberDto> list(Pageable pageable) {
        Page<Member> page = memberRepository.findAll(pageable);
        return page.map((m)->new MemberDto(m));
    }
}

페이징 조건을 알아서 Pageable의 구현체 PageRequest로 만들어준다.

다음과 같이 사용 가능하다.

.../api/members -> 모든 멤버 조회
.../api/members?page=0 -> 'page = 0'에 해당하는 멤버 조회 (기본 20, 최대 2000)
.../api/members?page=1&size=3 -> 'page = 1'에 해당하는 멤버 3명 조회
.../api/members?page=1&size=3&sort=id,desc -> 정렬 기준, 방향 지정 가능

커스터마이징

글로벌 설정으로 페이지 사이즈를 지정할 수 있다.

spring:
    data:
        web:
            pageable:
                default-page-size: 10
                max-page-size: 100
                one-indexed-parameter: true 
                # page 시작 번호를 1로 만들기 (한계 존재)

또는 @PageableDefault Annotation으로 지정 가능하다. (글로벌 설정에 앞선다.)

@RestController
@RequiredArgsConstructor
public class MemberController {

    // findAll(Pageable): JpaRepository의 부모 인터페이스에 정의된 메서드
    @GetMapping("/api/members")
    public Page<MemberDto> list(@PageableDefault(size = 5, sort = "id") Pageable pageable) {
        Page<Member> page = memberRepository.findAll(pageable);
        return page.map((m)->new MemberDto(m));
    }
}

@Qualifier

페이징 정보가 여러 건인 경우, @Qualifier를 사용해서 페이징 정보를 추가할 수 있다.

.../api/members?member_page=0&order_page=1

@RestController
@RequiredArgsConstructor
public class MemberController {

    // findAll(Pageable): JpaRepository의 부모 인터페이스에 정의된 메서드
    @GetMapping("/api/members")
    public Page<MemberDto> list(
        @Qualifier("member") Pageable memberPageable,
        @Qualifier("order") Pageable orderPageable
    ) {
        Page<Member> page = memberRepository.findAll(pageable);
        return page.map((m)->new MemberDto(m));
    }
}

JpaRepository 구현체

JpaRepository를 상속받은 인터페이스를 정의하면 Spring Data JPA가 알아서 구현체를 만들어준다.

그 구현체는 바로 SimpleJpaRepository이다.

@Repository
@Transactional(readOnly = true)
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {

    ...
}

1. @Repository가 붙이있으므로 Spring Bean으로 등록될 뿐만 아니라, Jpa Exception을 Spring의 Excepiton으로 변환한다.

2. @Transactional(readOnly = true)이므로, 메서드에 따로 @Transactional이 붙어있지 않는 이상, 트랜잭션이 종료되어도 flush를 수행하지 않는다(약간의 성능 이점).

3. save메서드는 새로운 Entity이면 persist, 아니면 merge를 수행한다.

   • 데이터 변경 목적으로 merge를 사용하면 안된다.
   • Dirty Checking을 통해 데이터를 변경해야 한다.

새로운 Entity 구분

3. save메서드는 새로운 Entity이면 persist, 아니면 merge를 수행한다.

    @Transactional
    @Override
    public <S extends T> S save(S entity) {

        Assert.notNull(entity, "Entity must not be null.");

        if (entityInformation.isNew(entity)) {
            em.persist(entity);
            return entity;
        } else {
            return em.merge(entity);
        }
    }

새로운 Entity인걸 어떻게 구분하는 것일까?

// EntityInformation인터페이스 구현체인 AbstractEntityInformation
public boolean isNew(T entity) {
        ID id = getId(entity);
        Class<ID> idType = getIdType();

        // 식별자 타입이 객체일 때, id가 null이면 새로운 Entity
        if (!idType.isPrimitive()) {
            return id == null; 
        }

        // 식별자 타입이 숫자형 Primitive type일 때, id가 0이면 새로운 Entity
        if (id instanceof Number) {
            return ((Number) id).longValue() == 0L;
        }

        throw new IllegalArgumentException(String.format("Unsupported primitive id type %s", idType));
    }

문제 상황

@GeneratedValue를 사용할 때, persist가 호출될 때 Id에 값이 자동 할당된다.

다음과 같은 Item Entity가 있다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Item {

    @Id
    private String id

    public Item(String id) {
        this.id = id;
    }
}

Q: @GeneratedValue을 사용하지 않고, 직접 Id를 할당한 뒤, save를 호출하면 persist될까 아니면 merge될까?

@SpringBootTest
public class MyTest {

    @Autowired
    ItemRepository itemRepositry; // JpaRepository를 상속받은 Repositry

    @Test
    void test() {
        Item item = new Item("A")
        itemRepositry.save(item);
    }
}

id를 em.persist를 통해서가 아닌, 그 전에 강제로 할당했다. 그러므로 save()의 로직에 따라 새로운 Entity로 인식하지 못하고 merge를 수행한다.

merge를 실행했더니 다음과 같은 쿼리가 발생한다.

1. SELECT 쿼리
2. INSERT 쿼리

merge는 기본적으로 값을 업데이트 하는 작업을 수행한다 (정확히는 detached된 entity를 다시 persist). 이를 위해 값을 변경할 데이터를 SELECT쿼리로 불러오는 것이다.

값 변경을 위해서는 Dirty Checking을, 값 저장을 위해선 Persist를 사용해야 한다. Merge는 지양해야 한다.

그런데 위 상황처럼 어쩔 수 없이 ID를 직접 할당해야 하는 상황에서는 어떻게 할까?

Persistable

public interface Persistable<ID> {
    @Nullable
    ID getId();
    boolean isNew();
}
// Entity
@Entity
@EntityListeners(AuditingEntityListener.class)
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Item implements Persistable<String> {

    @Id
    private String id;

    @CreatedDate
    private LocalDateTime createdDate;

    public Item (String id) {
        this.id = id;
    }

    @Override
    public String getId() {
        return id;
    }

    // Entity가 새로 만들어졌음을 증명하는 조건을 직접 정의
    @Override
    public boolean isNew() {
        return createdDate == null;
    }
}

Entity가 Persistable를 구현하도록 하면, Entity 마다 isNew조건을 직접 정의할 수 있다.

생성 날짜는 JPA가 persist할 때 자동으로 설정하므로, 보통은 생성 날짜를 기준으로 isNew를 판단하도록 한다.

보통은 BaseEntity를 만들어서 Entity가 상속 받도록 한다. 참고

Projections

Spring Data는 필요한 데이터만 뽑아서 조회할 수 있도록 한다.

Interface Based

Close Projection

// 뽑아올 데이터만 getter를 만들어 준다.
public interface UsernameOnly {
    String getUsername();
}

// 반환형으로 사용하면 된다.
// repository
List<UsernameOnly> members = findByUsername("username");

실제로도 username만 조회하는 SELECT 쿼리가 발생한다.

Spring Data JPA가 인터페이스를 보고 Proxy 기술을 통해 구현체를 만드는 것이다.

Open Projection

Close Projection이 SQL 상으로 정확히 필요한 데이터만 불러오는 것과 달리, @Value + SpEL을 사용하면 더 확장성(?) 있는 조회가 가능하다.

public interface UsernameAndAge {

    @Value("#{target.username + ' ' + target.age}")
    String getUsername();
}

List<UsernameAndAge> members = findByUsername("username");

위 방식을 사용하면 모든 필드를 다루는 SELECT 쿼리가 발생하고, Data JPA Level에서 @Value에 명시된 필드만 가지고 원하는 형태로 값을 반환한다.

Class Based

클래스 기반으로도 만들 수 있다.

public class UsernameOnlyDto {

    private final String username;

    public UsernameOnlyDto(String username) {
        this.username = username;
    }

    public String getUsername() {
        return username;
    }
}

List<UsernameOnlyDto> members = findByUsername("username");

1. *필드명이 아닌 생성자의 파라미터 이름을 기준으로 SQL 쿼리가 발생한다. *
2. 인터페이스 방식이 Proxy 객체를 생성하는 것과 달리, 클래스 방식은 클래스의 객체를 사용한다.

3. Generic

   사용하는 쿼리는 같은데, 원하는 필드만 다를 경우 Generic을 이용할 수 있다.

   // repository
   <T> List<T> findByUsername(@Param("username") String username, Class<T> type)
   

// Class List members = findByUsername("username", UsernameOnlyDto.class); // Interface List members = findByUsername("username", UsernameAndAge.class);

## Nested Close Projection
Entity가 중첩된 상황에서 Projection을 사용하면
``` java
public interface NestedClosedProj {

    String getUsername();
    TeamInfo getTeam();

    interface TeamInfo() {
        String getName();
    }
}

List<NestedClosedProj> members = findByUsername("username", NestedClosedProj.class)

다음과 같은 SQL 쿼리가 발생한다.

SELECT
    u.username
    t.teamId,
    t.teamName,
    t.created_date
    t.updated_date
FROM member AS m LEFT OUTER JOIN ...

** Root에 대해서만 최적화가 발생하고, 이하의 Entity에 대해선 전체를 조회한다는 한계가 있다. ** 조회 대상이 단순한 경우에는 사용해도 괜찮은데, 복잡한 경우에는 QueryDSL로 해결 권장

Native Query

가급적 Native Query는 피하는게 좋다. 사용할 경우에는 Projection와 같이 사용하는게 좋다.

public interface MemberRepository extends JpaRepository<Member, Long> {

    @Query(
        value = "SELECT * from Member WHERE username = ?", 
        nativeQuery = true
    )
    Member findByNative(String username);
}

// 사용
Member member = findByNatvie("name#1");

주의사항

1. 반환 타입

   • Object[]
   • Tuple
   • DTO (Spring Data의 Projection)

2. Sort가 정상적으로 작동 안 할 수 있음

   • 코드 레벨에서 직접 정렬 권장

3. 컴파일 타임에 SQL 문법 확인 불가능

4. 동적 쿼리 불가능

   • Hibernate에서 가능하긴 함
   • MyBatis 또는 Spring JDBC Template 사용

Native Query + Interface Projection

public interface MemberProjection {
    Long getId();
    String getUsername();
    String getTeamName();
}

// Native Query에 Paging Projection을 사용할 수 있다.
@Query(
    value = "SELECT m.member_id AS id, m.username, t.name AS teamName FROM Member AS m LEFT JOIN Team AS t",
    countQuery = "SELECT COUNT(*) FROM Member",
    nativeQuery = true
)
Page<MemberProjection> findByNavtiveProjection(Pageable pageable);

// 사용
Page<MemberProjection> result = findByNavtiveProjection(PageResult.of(0, 10));

Spring Boot를 사용하지 않는 상황이면 다음과 같이 설정해야 한다.

@SpringBootApplication
@EnableJpaRepositories(basePackages = "Data jpa인터페이스가 위치한 패키지 경로명")
public class Appliction {
    ...
}

스프링 부트를 사용하면 따로 설정하지 않아도 된다.

맛보기

import com.example.demo.entity.Member;
import org.springframework.data.jpa.repository.JpaRepository;

public interface MemberRepository extends JpaRepository<Member, Long> {
}

인터페이스를 정의해 놓고, 이를 사용하면 마치 구현체를 사용하는 것 처럼 사용할 수 있다.

Spring Data JPA가 Proxy 기술을 사용해서 자동으로 구현체를 만든뒤 주입하는 것이다.

@Repository를 붙이지 않아도 Spring Data JPA가 알아서 처리해준다.

참고

@Repository는 단순히 Component Scan의 대상으로 등록하는 작업 뿐만 아니라, JPA 예외를 Spring의 공통 예외로 변환하는 작업도 수행한다.

JpaRepository

Spring Data의 인터페이스
    PagingAndSortingRepository
    CrudRepository
    Repository

Spring Data JPA의 인터페이스
    JpaRepository

JpaRepository는 Spring Data가 제공하는 인터페이스의 JPA 특화 버전이다.

1. 기본적인 메서드를 제공한다.
2. 쿼리 메서드 기능을 통해 도메인 특화된 메서드를 손쉽게 사용할 수 있다.

   쿼리 메서드

   도메인 특화된 메서드를 손쉽게 사용하게 하는 기능

1. 메서드 이름으로 쿼리 생성

이름이 일치하고, 특정 나이 이상인 멤버 조회

순수 JPA (JQPL)은 다음과 같을 것이다.

public List<Member> findByUsernameAndAgeGreaterThan(String username, int age) {
    return em.createQuery(
        "SELECT m FROM Member m WHERE m.username = :username AND m.age > :age",
        Member.class
    ).setParameter("username", username)
    .setParameter("age", age)
    .getResultList();
}

Spring Data JPA는 다음처럼 해결 할 수 있다.

public interface MemberRepository extends JpaRepository<Member, Long> {

    public List<Member> findByUsernameAndAgeGreaterThan(String username, int age);
}

어떠한 구현체도 만들지 않고, 단순히 메서드를 선언했는데 실제로 작동한다.

자세한 사용법은 다음을 참고

쿼리를 직접 작성하지 않아도 되는 장점이 있으나, 다음과 같은 단점도 존재한다.

1. 파라미터 개수에 따라 메서드 이름이 너무 길어진다.
2. 모든 종류의 쿼리를 만들지는 못한다.
3. Entity 필드명이 변경되면 Repository 메서드 이름도 변경해야 한다.

2. 메서드 이름으로 NamedQuery 호출

참고: Named Query

NamedQuery를 EntityManager의 createNamedQuery를 사용하여 사용할 수도 있으나, Spring Data JPA를 사용하면 더 편리하게 사용할 수 있다.

// Member Entity
@Entity
@NamedQuery(
    name = "Member.findByUsername"
    query = "SELECT M From Member AS m WHERE m.username = :username"
)
public class Member {...}


// repository
public interface MemberRepository extends JpaRepository<Member, Long> {
    @Query(name = "Member.findByUsername")
    List<Member> findByUsername(@Param("username") String username);
}

createNamedQuery을 사용하지 않고, Spring Data JPA에서도 NamedQuery를 사용할 수 있다. @Query를 사용해서 어떤 NamedQuery를 사용할 지 명시하고, @Param을 사용해서 파라미터를 바인딩 한다.

Spring Data JPA의 NamedQuery는 다음의 관례를 따라 실행된다.

1. @Query의 name에 명시된 NamedQuery를 찾아서 실행
2. @Query가 없는 경우, Repositry의 대상.메서드_이름으로 된 NamedQuery를 찾아서 실행
3. NamedQuery가 없는 경우, 메서드 이름으로 쿼리를 생성

3. @Query을 사용해서 쿼리 직접 정의

@Query에 JPQL를 직접 사용할 수 있다.

public interface MemberRepository extends JpaRepository<Member, Long> {

    @Query("SELECT m FROM Member m WHERE m.username = :username")
    public List<Member> findByUsername(@Param("username") String username);
}

NamedQuery와 @Query + JPQL은 크게 다르지 않다.

둘 다 App Loading 시점에 JPQL을 SQL로 미리 파싱하기 때문에, 그 과정에서 SQL 문법 오류를 확인할 수 있다는 장점이 있다.

실무에서는 NamedQuery보다 @Query + JPQL을 더 많이 사용한다고 한다.

@Query로 값, DTO 조회하기

@Query를 사용해서 Entity뿐만 아니라 단순 값도 조회할 수 있다.

@Query("SELECT m FROM Member m")
List<Member> findAll();

@Query("SELECT m.username FROM Member m")
List<String> findAllNames();

DTO도 가능하다.

// DTO
@Data
@AllArgsConstructor
public class MemberDto {
    private Long id;
    private String username;
    private String teamName;
}

// Repository
@Query(
    "SELECT new 패키지명.MemberDto(m.id, m.username, t.teamName) " + 
    "FROM Member m JOIN FETCH m.team t"
)
List<MemberDto> findMemberDto();

파라미터 바인딩

JQPL은 위치 기반, 이름 기반 파라미터 바인딩을 지원한다.

@Query("SELECT m FROM Member m WHER m.username = :name")
public List<Member> findByUsername(@Param("username") String name);

// Collection기반 IN도 지원한다.
@Query("SELECT m FROM Member m WHER m.username IN :username")
public List<Member> findByUsernames(@Param("username") Collection<String> names);

반환 타입

Spring Data JPA는 다양한 반환 타입을 지원한다.

// Collection
List<Member> findByUsername(String name);
// 단 건
Member findByUsername(String name);
// Optional
Optional<Member> findByUsername(String name);

그 외에도 primitive type, Interator, Stream, Page등 다양한 반환 타입을 지원한다.

주의사항

1. Collection을 사용했는데 조회 결과가 0건이면, null이 아닌 size == 0인 Collection을 반환한다.
2. 단 건을 사용했는데 조회 결과가 0건이면, null을 반환한다.
   • 순수 JPA는 NoResultException이 발생한다.
   • Spring Data JPA는 이를 try-catch로 감싼뒤 null을 반환한다.
3. 단 건을 사용했는데 조회 결과가 여러 건이면, IncorrectResultSizeDataAccessException이 발생한다.
   • JPA의 NonUniqueResultException이 먼저 발생하고, Spring Data JPA가 이를 Spring Exception으로 변환해서 던진다.

페이징, 정렬

순수 JPA

public List<Member> findByAge(int age, int offeset, int limit) {
    return em.createQuery(
        "SELECT m FROM Member m WHERE m.age = :age ORDER BY m.username DESC",
        Member.class
    ).setParameter("age", age)
    .setFirstResult(offset)
    .setMaxResult(limit)
    .getResultList();
}

요청 페이지 번호에 따라 offset을 계산해야 한다.

Spring Data

Spring Data는 정렬, 페이징을 추상화하여 제공한다.

org.springframework.data.domian.Sort
org.springframework.data.domian.Pageable
org.springframework.data.domain.Page  
org.springframework.data.domain.Slice
...

public interface MemberRepository extends JpaRepositry<Member, Long> {

    Page<Member> findByAge(int age, Pageable pageable);
}

위 처럼 인터페이스를 정의하고, 아래 처럼 사용하면 된다.

// PageRequest: 페이징 조건
// Pageable 인터페이스 구현체
// 0번째 페이지 부터, 3개를 가져오는데, 다음의 Sort조건을 사용
PageRequest pageRequest = PageRequest.of(0, 3, Sort.of(Sort.Direction.DESC, "username"))

Page<Member> page = memberRepository.findByAge(10, pageRequest);

// 페이징 쿼리 결과
List<Member> content = page.getContent();
// 총 검색 개수
long totalElements = page.getTotalElements();
// 현재 페이지 번호
int pageNumber = page.getNumber()
// 총 페이지 개수
int totalPageNumber = page.getTotalPages();
// 첫 번째 페이지인가?
boolean isFirst = page.isFirst();
// 다음 페이지가 있는가?
boolean hasNext = page.hasNext();

Page, Slice

PageRequest pageRequest = PageRequest.of(0, 3, Sort.of(Sort.Direction.DESC, "username"))

Page<Member> page = memberRepository.findByAge(10, pageRequest);
// findByAge가 Page가 아닌 Slice를 반환해야 함
Slice<Member> slice = memberRepository.findByAge(10, pageRequest);

Spring Data는 페이지 번호가 0번 부터 시작한다.

Page는 PageRequest에 따라 페이징 쿼리를 날리고, 총 개수를 구하는 쿼리 또한 알아서 날린다.

Page는 Request에 따라 3개의 데이터를 가져오는 반면, Slice는 추가로 한 개를 더 가져온다.

현재 보여줄 데이터 개수 + 총 데이터 개수를 다루는 Page와 달리, Slice는 '더보기' 버튼을 눌렀을 때 동적으로 데이터를 Loading하는 기법에서 사용한다. 그렇기 때문에 Slice는 getTotalElements와 같은 메서드를 지원하지 않는다.

PageRequest pageRequest = PageRequest.of(0, 3, Sort.of(Sort.Direction.DESC, "username"))

List<Member> members = memberRepository.findByAge(10, pageRequest);

Page, Slice 기능이 필요 없으면 그냥 Collection으로 받으면 된다.

countQuery

반환 타입에 따라 총 개수 쿼리를 날릴지가 결정된다.

Page는 자동 발생
Slice는 발생 X

총 개수 쿼리 JOIN이 들어갈 경우, 데이터 개수가 많아질 수록 성능적인 부담이 생긴다. 총 개수 쿼리는 실제 데이터를 불러올 필요가 없다. 그러므로 데이터 조회 쿼리와 총 개수 쿼리를 따로 관리할 필요가 있다.

다음과 같이 분리할 수 있다.

@Query(
    value = "SELECT m FROM Member m LEFT JOIN m.team t",
    countQuery = "SELECT COUNT(m.username) FROM Member m")
Page<Member> findByAge(int age, Pageable pageable);

DTO로 감싸기

Page결과도 DTO로 변환하여 전달해야 한다.

Page<Member> page = memberRepository.findByAge(age, pageRequest);

Page<MemberDto> maped = page.map(p -> new MemberDTO(...));

Page가 extends하는 Streamable을 통해 람다 비스무리한 방법을 사용할 수 있다.

Bulk Operation

JPA는 명식적 Update를 사용하지 않고, Dirty Checking을 통해 Update하기를 권장한다.

모든 직원의 나이를 n씩 올려라

그런데 위와 같은 작업은 모든 Employee를 불러와서 Dirty Checking으로 하나씩 Update 쿼리를 날릴 필요 없이, Bulk 연산으로 처리하는게 더 효율적이다.

순수 JPA

// 반환값: Update 영향 받은 row 개수
public int bulkAgePlus(int age) {
    return em.createQuery(
        "Update Member m " +
        "SET m.age = m.age + :age" 
    ).setParameter("age", age)
    .executeUpdate();
}

Spring Data

public interface memberRepository extends JpaRepository<Member, Long> {

    @Modifying
    @Query("Update Member m SET m.age = m.age + :age")
    public int bulkAgePlus(@Param("age") int age);
}

@Modifying을 사용하지 않으면 executeUpdate대신에 getResultList, getSingleList가 호출되어서 예외가 발생한다.

주의사항: PC-DB 불일치

Bulk 연산은 Persistence Context를 무시하고 연산을 수행한다. 즉, Persistence Context와 DB간 데이터 불일치가 발생할 수 있다.

memberRepository.save(new Member("name#1", 30));
// PC에는 30살로 저장

memberRepository.bulkAgePlus(20);
// Bulk 연산은 PC를 무시하고 바로 DB에 반영
// DB는 50살, PC는 30인 상황

// PC에서 Entity를 찾아옴
Member member = memberRepository.findByName("name#1").get(0);

sout(member.getAge()); // 30

따라서 관습적으로 Bulk 연산을 수행하고 나서 PC를 clear해줘야 한다.

memberRepository.save(new Member("name#1", 30));
// PC에는 30살로 저장

memberRepository.bulkAgePlus(20);

// 혹시 모를 아직 DB에 반영 안된 변경사항 전달
em.flush();
// PC 비우기
em.clear();

Spring Data JPA는 간편한 방법을 제공한다.

public interface memberRepository extends JpaRepository<Member, Long> {

    @Modifying(clearAutomatically = true)
    @Query("Update Member m SET m.age = m.age + :age")
    public int bulkAgePlus(@Param("age") int age);
}

@Modifying(clearAutomatically = true)로 설정하면 쿼리 발생 이후 자동으로 PC를 clear한다.

Entity Graph

Spring Data JPA의 findAll을 사용하려고 하는데, 연관관계가 Lazy Loading으로 설정되어 있다.

@Query를 사용해서 명시적으로 FETCH JOIN을 사용할 수 있으나, 이러면 Spring Data JPA의 장점을 살리지 못한다.

그러므로 @EntityGraph를 사용한다.

@EntityGraph

@Override
@EntityGraph(attributePaths = {"team"})
List<Member> findAll();

@EntityGraph는 이미 존재하는 JQPL에 FETCH JOIN을 추가하는 용도로 사용할 수 있다.

@Query("SELECT m FROM Member m")
@EntityGraph(attributePaths = {"team"})
List<Member> findMemberEntityGraph();

쿼리 메서드 - 메서드 이름으로 쿼리 생성 기능에도 사용할 수 있다.

@EntityGraph(attributePaths = {"team"})
List<Member> findByUsername(@Param("username") String username);

@NamedEntityGraph

JPA 표준 스펙에 정의된 @NamedEntityGraph를 사용하면, FETCH JOIN으로 불러올 Entity를 미리 정의해 놓을 수 있다. (마치 @NamedQuery 처럼)

// Entity
@Entitty
@NamedEntityGraph(
    name = "Member.all",
    attributeNodes = @NamedAttributeNode("team")
)
public class Member {...}

// Repository
@EntityGraph("Member.all")
List<Member> findByUsername(@Param("username") String username);

참고

1. FETCH JOIN은 기본적으로 LEFT OUTER JOIN을 발생시킨다. RIGHT JOIN FETCH 처럼 Join 방향을 지정할 수도 있다.
2. 간단한 관계에서만 @EntityGraph를 사용하고, 복잡한 관계에서는 @Query에 명시적으로 FETCH JOIN을 사용한다.

JPA Hint

SQL이 아닌, JPA 구현체에게 제공하는 힌트를 의미함

예시: readOnly

1. JPA는 dirty checking을 위해, snapshot을 저장해 놓고 있음
2. 어떤 비즈니스 로직에서 데이터를 조회하는데, 그 데이터에 변경이 일어나지 않을 것이 확실함
3. 성능 최적화를 위해, 변경이 일어나지 않을 것이 확실한 경우에는 snapshot을 메모리에 저장하지 말도록 하고 싶음

@QueryHints(value = @QueryHint(name = "org.hibernate.readOnly", value = "true"))
Member findReadOnlyByUsername(String username);

주의사항

1. readOnly로 읽은 데이터를 변경하면 dirty checking이 발생하지 않음
2. 모든 ReadOnly Operation에 위 내용을 전부 적용하는 건 생산성 측면에서 좋지 못함. 다음 경우에만 적용하길 권장
   • 엄청 성능이 중요한 API
   • 성능 개선이 확실한 상황

JPA Lock

Spring Data JPA에서 Lock을 제공한다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
public List<Member> findLockByUsername(String username);

다음과 같은 SQL이 발생한다.

SELECT ...
FROM ...
WHERE member.username = ? FOR UPDATE

Lock에 대한 내용은 따로 다루겠다.