1. replicaset, replicacontroller
2. deployment
3. namespace

1. Kubernetes controller

ReplicationController왜 필요할까?

1. 고가용성

어플리케이션이 죽을때, 최소로 돌아가는 어플리케이션을 유지할 수 있도록 해준다.

• 단일 파드여도 replication contrller를 사용할수있다.
• 명시한 개수의 컨테이너가 돌아가도록 보장하는것.

2. 로드밸런싱 & 스케일링

• 파드간의 로드밸런싱을 해준다.
• 트래픽이 올라갈때 스케일링을 해준다.

Replicaset vs ReplicaController

Replicaset은 새로 나온 권장되는 기능이다. 이제는 replicaset이 보편적으로 사용되고, 더 이상 controller는 사용되지않는다. 그러나 여기에서는 둘다 다룬다.

ReplicaController

//replica-definition.yml
apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc // user-define
  labels:
      app: myapp
      type: front-end
spec:
  template:
  //여기부터는 pod-definition.yml
    metadata:
      name: myapp-pod
      labels:
          app: myapp
          type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx
  //여기까지
  //몇개의 파드를 유지하고 싶은지 명시.
  replicas: 3

kubectl get replicationcontroller

Replicaset

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
      app: myapp
      type: front-end
spec:
  template:
  //여기부터 pod의 metadata 기재
    metadata:
      name: myapp-pod
      labels:
          app: myapp
          type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx
  replicas: 3
  selector: 
    matchLabels:
      type: front-end

• selector는 replicaset에 있는 옵션으로 이제는 필수적으로 명시해야된다.

kubectl get replicaset

Labels and Selectors

모니터링할 타켓 리소스을 구분할 수 있게해줌

replicas 값을 수정하고싶을때

kubectl replace -f replicaset-definition.yml(filename.yml)
#or
kubectl scale --replicas=6 -f filename.yml
#or
kubectl scale --replicas=6 replicaset(type) myapp-replicaset(name)

2. Kubernetes Deployments

도커 인스턴스들을 중단없이 매끄럽게 업그레이드

• Rolling update:

  한번에 업그레이드하고 싶지않고, 하나씩 점진적으로 업그레이드하고싶을때 사용되는 기법.

  Rolling Update: 새로운 버전의 애플리케이션 컨테이너를 하나씩 점진적으로 배포하면서, 동시에 구버전 컨테이너를 하나씩 제거하는 방식입니다. 이 덕분에 전체 서비스가 중단되는 순간이 없습니다.

• 최근 업데이트에 오류가 발생해서 roll back 하고싶거나

#deployment-definition.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
      app: myapp
      type: front-end
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

kubectl create -f deployment-definition.yml
kubectl get deployments
kubectl get replicaset
kubectl get pods
# etc
kubectl get all

deployment의 특징

• 선언형 업데이트
• replicaSet 관리 -> 롤링 업데이트,버저닝,롤백 지원
• 스케일링

kind를 deployment로 설정 vs replicaset로 설정의 차이가 뭐지?

1. deployment이라는 객체를 따로 생성.

   —> 다른 차이점들을 다음 강의에 알려주시기로… 음..

• Baeldung을 통해 알아본 차이점.

  • https://www.baeldung.com/ops/kubernetes-deployment-vs-replicaset

    Deployments	ReplicaSet
    rolling updates, rollbacks, versioning등 추가기능들을 지원하는 고수준의 추상화 기술	명시된 개수의 파드replicaset을 관리하는 저수준의 추상화 기술.
    (기본 스케일링과 self-healing 지원)
    파드 template을 관리함.
    replicaset을 이용해서, 특정 개수 파드 replica를 유지하도록 함.	명시된 개수의 파드 replicas만 관리.
    자동 롤링 업데이트, 롤백을 통해서,
    다운타임 최소화해준다	수동으로 업데이트 / 롤백 필요
    버저닝 지원 → 롤백이 쉽다.	버저닝 지원 x

deployment의 옵션에는

strategy라는 옵션이 있다. 이 옵션을 통해 recreate, 혹은 rolling update를 설정할수있고, rolling update의 상세사항인, maxsurge등을 설정할수있다.

3. Namespace

클러스터 생성시 자동생성되는 3가지 네임스페이스가있다.

1. Default
2. kube-system
3. kube-public

같은 클러스터를 사용하고 싶지만, 리소스를 구분하고싶을때. namespace를 구분할수있다.

Q. 네임스페이스는 클러스터간에도 같은 네임스페이스를 넣을수있는건지.?

# automatically add DNS service name
mysql.connect("db-service.dev.svc.cluster.local")
#             "servicename.namespace.service.domain(=cluster.local)"

# namespace를 지정하고싶을때. pod-definition.yml
apiVersion: v1
kind: Pod

metadata:
  name: myapp-pod
  **namespace: dev # namespace를 지정할수있음**
  labels:
    app: myapp
    type: front-end
spec:
    containers:
    - name: nginx-container
      image: nginx

create namespace

1. yaml로 생성하는 방법

apiVersion: v1
kind: Namespace
metadata:
    name: dev

1. cmd로 생성하는 방법

kubectl create namespace dev

get pods를 통해 정보 조회 시, 원하는 namespace를 지정하지않으면 default namespace가 조회된다.

• 만약, default namespace를 다른 것(ex. dev)으로 변경하고싶을때?

    kubectl config set-context $(kubectl config current-context) --namespace=dev

#모든 네임스페이스의 파드 조회
kubectl get pods --all-namespaces

create quota

네임스페이스의 쿼타를 yml를 통해 지정가능.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: dev
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 5Gi
    limits.cpu: "10"
    limits.memory: 10Gi. 

1. 전체적인 쿠버네티스의 구조
2. 파드

1. Kubernetes Architecture

구성요소

1. Node : worker machine, minions

• need more than one mode.(if one failed, others are accessible)

2. Cluster : set of nodes.

• if one node fail, still accessible
• group nodes sharing loads

3. Master : watch worker nodes

• orchestration nodes

쿠버네티스를 설치하면, 실제로 구성되어있는 요소들

[1] API server

front end of Kubernetes

[2] etcd

keystore for all data used to manage the cluster

• etcd stores all info on all the nodes in the cluster in a distributed manner.
• is responsible for implementing locks within the cluster to ensure no conflict with master

[3] kubelet

the agent that runs on each node in the cluster.

• agent : 예상된 노드에 컨테이너가 잘 돌아가는지 확인/수행.

[4] Container Runtime

use to run containers = docker.

[5] Controller

brain

• noticing and responding when nodes, containers or endpoints goes down.
• decide to bring up new containers

[6] Scheduler

distributing work or containers across mutliple nodes.

look for new created containers and assign them to nodes.

어떻게 master, worker는 다르게 이루어져있는가?

Docker vs ContainerD 차이

• 히스토리

쿠버네티스 - 도커 런타임만 호환됬었음.


이후, 쿠베 인기급상승.


타 런타임과의 호환을 위해, CRI도입 (OCI 표준으로 구현 시 CRI 를 사용해서 쿠버네티스와 호환해서 사용할수있게됨)

dockershim 으로 계속 도커를 CRI없이도 지원가능하도록 함.(deprecated)

dockershim이 deprecated 되면서 containerD가 나옴.

도커의 구성요소

Run C : Container Run time.

Container D : daemon managing run C. / can working directly with Kubernetes 도커외의 런타임과 직접 사용가능 / CRI Compatible.

dockershim 이제 지원 X

• 도커의 다른 기능이 필요없는 경우, containerD만 설치가능
  • ctr : cmd tools, not user friendly
  • nerdctr : docker-like cli for containerD / new feature not in docker
  • crictr : not for create container , for debug. (pull image, list images, list containers, view logs, also can aware of pods)

2. Pods

일반적인 파드와 컨테이너, 노드의 관계

• 파드: 컨테이너는 1:1이 일반적임.
• 유저 증가로 인해, scale해야할때, 컨테이너를 추가하지 않는다.
  • 대신, 노드안에 Pod를 추가한다 → 더 증가 시, 노드 전체를 추가하기도함.
  • scale up : 파드를 추가 / scale down : 파드를 제거

파드안에 두 개의 컨테이너가 있는 경우

• Helper Containers 이다.
  • helper container는 application container가 생성되면 같이 생성/ 제거 시 같이 제거 된다. (같은 파드이기 때문)
  • 같은 network, storage를 공유한다.

Kubernetes 에서의 pods.

pod가 없고 도커만으로 컨테이너를 런하는경우, 연관된 helper container 관리, scale한 전체 컨테이너의 관리를 직접해줘야한다.

• pod를 통해, 컨테이너 상태 모니터링 할 수 있고, 그에 따른 조치가 가능함.
• 같은 pod에 대해서 같은 네트워크와 스토리지, 생명주기를 부여할수있음.

kubectl run nginx --image [image-name] 

→ pods를 우선 생성하고 nginx image 를 deploy 한다.

kubectl get pods

YAML

기본 yaml.

• apiVersion
• kind
• metadata
• spec

영속성이란?

→ 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지않는 데이터의 특성

부모를 persist할때 그 밑의 자식객체들도 persist되는것

연관관계매핑과는 전혀무관!

그저 편리함제공일뿐

PROPERTY 종류

• ALL:모두적용
• PERSIST:영속 만 적용

고아객체

부모엔티티와 연관관계가 끊어진 자식엔티티를 자동으로 삭제한다.

자식엔티티가 삭제되었을때, persist없어도 삭제쿼리가 나간다.

컬랙션에서 나간 객체는 삭제된다.

MergeSort

• 시간복잡도: O(nlogn)
• 크게 split단계와 merge단계로 나눌 수 있다.
• 재귀를 사용한다.
• merge단계에서는 두개의 리스트의 각각 A[0]과 B[0]을 비교해서 작은 값을 앞으로 보내고, 작은값이 포함되어있던 리스트의 피벗? 비교대상인덱스? 를 다음으로 넘긴다.
  • ex. A[0]과 B[0]중 B가 더 작으면, B[0]을 앞으로 보내고, 다음에는 A[0]과 B[1]을 비교한다.

QuickSort

• 시간복잡도: O(nlogn)
• 피벗을 사용함
• 재귀를 사용한다.
• 맨 앞을 피벗으로 설정해서 작은데이터를 왼쪽, 큰 데이터를 오른쪽으로 넘긴다. 이를 반복한다.

정렬알고리즘 코드 예시

• https://github.com/seoeunbae/Algorithm_2022/tree/main/Algorithm/src/sort

인덱스에서 B-Tree 보다 B+Tree를 주로 사용하는 이유?

→ 인덱스 컬럼은 부등호를 이용한 순차 검색 연산이 자주 발생할 수 있다. 따라서 B+Tree의 Linked list를 이용하면 순차 검색을 효율적으로 할 수 있게 된다.

• B+Tree의 검색 과정은 B-Tree와 동일하다. 반면 B+Tree의 삽입과 삭제 과정은 약간의 차이가 있다. 기본적으로 B+Tree의 삽입과 삭제는 항상 leaf node에서 일어난다.

B+Tree 구조

B+Tree는 오직 leaf node에만 데이터를 저장하고 leaf node가 아닌 node에서는 자식 포인터만 저장한다.

그리고 leaf node끼리는 Linked list로 연결되어있다.

또, B+Tree에서는 반드시 leaf node에만 데이터가 저장되기 때문에 중간 node에서 key를 올바르게 찾아가기 위해서 key가 중복될 수 있다.

장

1. Leaf node를 제외하고 데이터를 저장하지 않기 때문에 메모리를 더 확보할 수 있다. → 하나의 node에 더 많은 포인터를 가질 수 있기 때문에 트리의 높이가 더 낮아짐 → 검색 속도 향상
2. Full Scan 을 하는 경우, leaf node에만 데이터가 저장되있고, leaf node끼리 linkedlist로 연결되어있어서 선형 시간이 소모된다. ↔ B-Tree는 모든 노드를 확인해야함!

단

1. B-Tree의 경우, 최상의 경우 특정 key를 root node에서 찾을 수 있지만 ↔ B+Tree의 경우 반드시 특정 key에 접근하기 위해서 leaf node까지 가야 함

삽입

1) key 의 수가 최대키수 보다 적은 리프노드에 삽입하는 경우

해당 node의 가장 앞이 아닌 곳에 삽입되는 경우는 단순히 삽입해 주면 된다.

→ 하지만, leaf node의 가장 앞에 삽입되는 경우는, 해당 node를 가리키는 부모 node의 포인터의 오른쪽에 위치한 key를 K(삽입되는 애)로 바꿔준다. 그리고 leaf node끼리 Linked list로 이어줘야 하므로 삽입된 key에 Linked list로 연결한다.

2) key 의 수가 최대인 리프노드에 삽입하는 경우

key의 수가 최대이므로 삽입하는 경우 분할을 해주어야 한다. 만약 중간 node에서 분할이 일어나는 경우는 B-Tree와 동일하게 해주면 된다.

leaf node에서 분할이 일어나는 경우는 중간 key를 부모 node로 올려주는데 이때, 오른쪽 node에 중간 key를 붙여 분할한다. 그리고 분할된 두 node를 Linked List로 연결해준다.

삭제

1) 삭제할 key가 리프노드의 가장 앞에 있지 않는 경우

B-Tree와 동일한 방법으로 삭제된다.

2) 삭제할 key가 리프노드의 가장 앞에 위치한 경우

이 경우는 leaf node가 아닌 node에 key가 중복해서 존재한다.  → 따라서 해당 key를 노드보다 오른쪽에 있으면서 가장 작은 값으로 바꿔주어야 한다.

뷰에서도 영속성컨텍스트를 열어놓겠다.

즉, 뷰에서도 지연로딩을 열어놓는다는 뜻이다.

과거OSIV:요청당 트랜잭션

클라에서 요청이 들어오자마자 서블릿필터나 스프링인터셉터에서 트랜잭션을 시작하고 요청이 끝날 때 트랜잭션도 끝내는 것이다.

뷰에서도 지연로딩을 할 수 있게되면서 퍼사드계층없이도 뷰에 독립적인 서비스 계층을 유지할 수 있다.

요청당 트랜잭션의 문제점

(컨트롤러, 뷰)프리젠테이션 계층이 엔티티를 변경할 수 있다.

해결방안

1. 엔티티를 read-only 인터페이스로.
2. 엔티티 래핑하기

엔티티의 getter(읽기전용메소드)만 있는 래퍼클래스를 만든다.

class MemberWrapper{
    private Member member;

    public MemberWrapper(member){
        this.member = member;
    }

    public String getName(){
        member.getName();    
    }
}

1. DTO만 반환하기

전통적인 방법.

→ BUT, 엔티티를 거의 복사한듯 DTO를 하나더 만들어야함.

현재 스프링OSIV: 비즈니즈계층에서만 트랜잭션유지

spring-orm.jar 에서 다양한 osiv클래스를 제공.

1. 클라이언트 요청이 들어오면 서블릿 필터 혹은 스프링 인터셉터에서 영속성 컨텍스트를 생성한다. 단 이때 트랜잭션은 시작하지 않는다.
2. 서비스 계층에서 @Transactional로 트랜잭션을 시작할 때 1번에서 미리 생성해둔 영속성 컨텍스트를 찾아와서 트랜잭션을 시작한다.
3. 서비스 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시한다. 이때 트랜잭션은 끝내지만 영속성 컨텍스트는 종료하지 않는다.
4. 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지한다.
5. 서블릿 필터나 스프링 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료한다. 단 이때 플러시를 호출하지 않고 바로 종료한다.

• 영속성 컨텍스트는 트랜잭션없이(범위 밖에서) 엔티티를 조회만 할 수 있다. 이것을 NonTransactional reads라고한다.

서비스에서 컨트롤러로 요청이 넘어간뒤 변경감지(더티체킹)이 안되는 이유

• 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하려면 영속성 컨텍스트를 플러쉬해야한다. 하지만 트랜잭션을 사용하는 서비스 계층이 끝날 때 트랜잭션이 커밋되면서 이미 플러시해버렸다. 그리고 스프링이 제공하는 osiv 서블릿필터나 osiv스프링인터셉터는 요청이 끝나면 플러시를 호출하지 않고 em.close()로 영속성 컨텍스트만 종료해버리므로 플러시가 일어나지 않는다.

스프링OSIV주의사항

1. memberService의 getMember를 통해 찾아온 Member를 영속성 컨텍스트에 저장한다. (트랜잭션은 시작하지 않았지만 영속성 컨텍스트는 존재하기 때문에 가능하다.)
2. 찾아온 member의 이름을 XXX로 바꿨다.
3. logic() 메소드를 호출하여 트랜잭션이 있는 비즈니스 로직을 실행하였다.
4. 트랜잭션 AOP가 동작하면서 영속성 컨텍스트에 트랜잭션을 시작한다. 그리고 logic() 메소드를 실행한다.
5. logic()메소드가 끝나면 트랜잭션 AOP는 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시한다. 이때 변경 감지가 동작하면서 회원 엔티티의 수정 사항을 데이터베이스에 반영한다.
6. 트랜잭션이 있는 비즈니스로직을 모두 호출하고 나서 엔티티를 변경하면 된다.

단점

• 영속성 컨텍스트와 db커넥션은 1:1로 물고있는 관계이기 때문에 프레젠테이션 로직까지 디비커넥션 리소스를 낭비하게됨.→ 장애로 이어진다.
• osiv를 적용하면 같은 영속성 컨텍스트를 여러 트랜잭션이 공유하기 될 수 있다.
• 프레젠테이션 에서 엔티티를 수정하고 비즈니스 로직수행하면 엔티티가 수정될 수 있다.
• 프레젠테이션 계층에서 렌더링 과정에서 지연 로딩에 의해 SQL이 실행되므로, 성능 튜닝시에 확인해야 할 범위가 넓어진다.

1. 사설 IP과 공인 IP
2. 유동 IP와 고정 IP
3. 서브넷마스크와 CIDR

[IP와서브넷마스크] : https://www.youtube.com/watch?v=gOMljj6K2V0

[얄팍한코딩사전-IP종류] : https://www.youtube.com/watch?v=GK3h936Co-k

IPv4 : 46억개 / 32비트(주소길이)

IPv6 : 2의 128승개 / 128bit

**사설 IP 대역

• 10.0.0.0 ~ 10.255.255.255
• 172.16.0.0 ~ 172.31.255.255
• 192.168.0.0 ~ 192.168.255.255**

사설 IP 컴 → 공인 IP 컴으로는 접근가능

공인 IP → 사설 IP 로는 접근 불가능

즉, 웹 서비스 는 공인ip여야한다.!

사설 ip 로 웹 서비스를 사용하는 법

1. 내부 ip를 포트로 연결하는 방법도 있다.

공인ip에 포트들을 개방해서 내부 사설 ip 마다 포트 하나씩 연결할 수 있다.

그러면 , 외부에서 접근할떄는⇒ 공인ip:포트번호

2. DMZ

공인 ip의 모든 포트를 내부 사설 ip하나에 몰아주기

• 보안상 위험함 , 권장X

고정 IP

서버에 사용 / 비쌈

유동 IP

일반 가정, 기기 에 사용 / 저렴

• DDNS 라는 조치를 취해서 가정에서도
  • 동적DNS : 유동 ip를 감지해서 고정된 도메인에 연결하는 것

서브넷 마스크

네트워크 host ip 의 길이를 알려주기.

앞에서부터 네트워크id의 범위를 알려준다.

ex. 172.100.99.1/24

이면 앞에서부터 24자리수인, 172.100.99까지가 네트워크id이다.

남은 8자리수가 호스트id이다. ex.1

서브넷 마스크 계산 예시

ip : 172.100.99.1

서브넷 : 255.255.255.0

→ ip : 10101100.1100100.1100011.1

→ subnet : 11111111.11111111.11111111.00000000

두개를 AND 연산하면 나오는 값 (⇒ 네트워크 아이디)

→ 172.100.99.0 (⇒ 네트워크 아이디)

서브넷의 1자리 개수 만큼이 네트워크 주소의 범위이다.

즉, 남은 8개만이 호스트 개수이다.

CIDR

ip주소/네트워크범위인 비트자리수

예시

위의 서브넷마스크계산 예시와 동일한 환경인 경우, ?? 에 오는 숫자 값은?

→ 172.100.99.1/??

답 : 24

1. 패키지 매니저 존재하는 이유
2. 데비안계열의 패키지매니저
3. 레드햇계열의 패키지매니저

• https://minhan2.tistory.com/entry/리눅스-패키지-비교aptdpkgyumrpm

패키지매니저의 존재 이유

• 복잡한 패키지들간의 의존관계

• 즉, 수동업데이트와 수동설치를 하는 과정에 나타나는 의존관계 충돌을 근절하기 위해 나타났다.

APT/APT-GET

데비안계열에서 주로 사용 (Ubuntu,…)

dpkg라는 패키지매니저도 존재한다.

dpkg는 해당 패키지만 설치를 진행하고 해당 패키지에 종속되서 설치되야하는 프로그램을 같이 설치해주지는 않는다.

이를 해결하기 위해 나온것이 apt-get이다.

apt-get

dpkg와 달리 종속된 프로그램이 만약 작업환경에 미설치되어있다면 추가 수동설치 필요없이 자동으로 설치해준다.

apt와 apt-get의 차이 (apt, apt-get은 데비안계열에서 사용)

APT는 Advanced Packaging Tool의 약자이다.

apt 와 apt-get는 내부적인 동작 차이는 거의 없기에, 뭘사용해도 상관이 없다.

다만, 좀 더 가독성이 좋고, 메세지 안내가 나오거나(apt),

좀더 세부적인 옵션과 스크립트 작성을 할때 유리한것(apt-get)

script 파일, 예를들어 Dockerfile 등에서 apt를 사용하면,

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

이라는 경고문구가 나온다.

apt 명령어는 사용자와의 상호작용에 중점을 둔 CLI고, script내에서는 사용하기에는 주의가 필요하다는 것이므로, apt-get을 이용해서 사용하면 된다.

YUM과 RPM

레드햇 계열에서 주로 사용 (Centos, Fedora,…)

RPM

기존 수동설치의 방식으로는 (직접 tar,gzip로 묶여있는 패키지 소스파일을 컴파일한 후에 수동 설치) 너무 많은 시간이 들었기 때문에, 레드햇에서 패키지관리프로그램을 개발.

• RPM 패키지는 컴파일되어 설치한 실행파일, 설정파일, 라이브러리 등을 하나로 묶어놓은 파일을 말한다.

단점

• 패키지 사이에 의존하고 있는 패키지까지 자동설치되지는 않는다.
• 인터넷이 연결되어있지않아도 설치가 가능하지만, rpm 확장자로 된 패키지 프로그램이 필요하다.

기본 사용 명령어

• 설치: rpm -Uvh [패키지명]
• 삭제: rpm -e [패키지명]
• 설치확인: rpm -qa [패키지명]
• 상세정보: rpm -qi [패키지명]

YUM

YUM은 RPM 기반의 시스템을 위한 자동 업데이터 및 패키지 설치, 제거 프로그램이다.

RPM과 다르게 인터넷 사용이 필수이기 때문에 패키지간 의존성 문제를 해결할 수 있다. 예를들어 A 패키지를 설치하기전에 필요한 B 패키지까지 모두 한번에 설치가 가능하며, 의존도를 자동으로 찾고 알아서 설치해준다.

• 인터넷에서 바로 설치가 가능하기 때문에 패키지 프로그램이 따로 필요없다.
• 패키지 사이에 의존하고 있는 패키지까지 자동으로 설치가 가능하다

기본 사용 명령어

• 설치: yum install [패키지명]
• 삭제: yum remove [패키지명]
• 업그레이드: yum update [패키지명]
• 목록: yum list [패키지명]
• yum 데이터베이스 동기화 업데이트: yum update

• 파티셔닝(Partitioning)

큰 테이블이나 인덱스를 관리하기 쉬운 크기로 분리하는 방법

• 단점: 파티션 제약이있다.= 테이블과 인덱스를 별도로 파티션 할 수 없다.

1. Horizontal Partitioning

• 데이터 개수를 기준으로 나누어 partitioning 하는 방법이다. sharding이 horizontal partitioning 과 관련있다. 같은 테이블 스키마를 가진 데이터를 데이터베이스 여러개에 분산하여 저장하는 방법을 일컫는 용어이기 때문이다. 때문에 Sharding을 Horizontal Partition`이라고 볼 수도 있다.

2. Vertical Partitioning

• 테이블의 칼럼을 기준으로 데이터를 나눈다.
• 이미 정규화된 데이터를 분리하는 과정으로 생각해야한다.
• 자주 사용하는 칼럼을 분리하여 성능향상을 얻을 수 있다.

3. Sharding

• DBMS 한 개로 처리할 수 있는 데는 한계가 있으므로 데이터베이스 여러 개를 사용*하는 방식으로 데이터 조회 한계를 극복해야 한다. 이를 위해 분산 환경을 고려해 만들어진 데이터베이스를 이용하는 방법도 있지만 범위 검색에 취약하거나 JOIN 연산을 사용할 수 없는 등 기능에 제약이 많다. 따라서 상대적으로 풍부한 기능을 사용하면서 데이터 확장을 꾀할 수 있는 방법은 RDBMS를 샤딩(sharding)하여 사용하는 것이다.*계속 증가하는 데이터에 장애 없이 효과적으로 대응할 수 있어야 하고 서비스마다 다른 데이터 특성과 모델에 어떻게 대처할 것인가가 샤딩 플랫폼의 핵심이다.

궁금증

1. 서로 다른 데이터베이스에 있는 테이블들을 join 할 수 있다고...?? → 같은 데이터베이스엔진이면 가능

2. 내가 찾는 데이터가 몇번샤드에 있는지 찾는거..는..? → 알고리즘에 따라 다르다

3. 샤딩과 horizontal partitioning 의 비교

수평 분할(Horizontal Partitioning)이란 스키마가 같은 데이터를 두 개 이상의 테이블에 나누어 저장하는 디자인을 말한다. 가령 같은 주민 데이터를 처리하기 위해 스키마가 같은 ‘서현동주민 테이블'과 ‘정자동주민 테이블'을 사용하는 것을 말한다. 인덱스의 크기를 줄이고, 작업 동시성을 늘리기 위한 것이다. 보통 수평 분할을 한다고 했을 때는 하나의 데이터베이스 안에서 이루어지는 경우를 지칭한다.

이에 비해, 샤딩은 물리적으로 다른 데이터베이스에 데이터를 수평 분할 방식으로 분산 저장하고 조회하는 방법을 말한다. ‘주민’ 테이블이 여러 DB에 있을 때 서현동 주민에 대한 정보는 A DB에, 정자동 주민에 대한 정보는 DB에 저장되도록 하는 방식이다. 여러 데이터베이스를 대상으로 작업해야 하기 때문에 경우에 따라서는 (JOIN 등) 기능에 제약이 있을 수 있고 일관성(consistency)과 복제(replication) 등에서 불리한 점이 많다. 예전의 샤딩은 애플리케이션 서버 레벨에서 구현하는 경우가 많았지만 최근에는 이를 플랫폼 차원에서 제공한다.

4. 샤딩의 한계

• 두 개 이상의 샤드에 대한 JOIN 연산을 할 수 없다.
• auto increment 등은 샤드 별로 달라질 수 있다.
• last_insert_id() 값은 유효하지 않다.
• shard key column 값은 update하면 안된다.
• 하나의 트랜잭션에서 두 개 이상의 샤드에 접근할 수 없다.

트랜잭션의 격리 수준 이란?

• 트랜잭션이 병렬 처리될 때
  • 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있도록 허용할지 말지 범위를 결정하는 것.

격리수준의 종류

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

READ UNCOMMITTED

• 각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK 여부에 상관 없이 다른 트랜잭션에서 값을 읽을 수 있다.
• 정합성에 문제가 많은 격리 수준이기 때문에 사용하지 않는 것을 권장한다.
• 아래의 그림과 같이 Commit이 되지 않는 상태지만 Update된 값을 다른 트랜잭션에서 읽을 수 있다.

그렇다면 READ UNCOMMITTED는 문제가 없을까?

• DIRTY READ현상 발생
  • 트랜잭션이 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있게 되는 현상

READ COMMITTED

• RDB에서 대부분 기본적으로 사용되고 있는 격리 수준이다.

• Dirty Read 와 같은 현상은 발생하지 않는다.

• 실제 테이블 값을 가져오는 것이 아니라 Undo영역에 백업된 레코드에서 값을 가져온다.

그렇다면 READ COMMITTED는 문제가 없을까?

• 트랜잭션-1이 Commit한 이후 아직 끝나지 않는 트랜잭션-2가 다시 테이블 값을 읽으면 값이 변경됨을 알 수 있다.
• 하나의 트랜잭션내에서 똑같은 SELECT 쿼리를 실행했을 때는 항상 같은 결과를 가져와야 하는 REPEATABLE READ의 정합성에 어긋난다.
• 이러한 문제는 주로 입금, 출금 처리가 진행되는 금전적인 처리에서 주로 발생한다.
  • 데이터의 정합성은 깨지고, 버그는 찾기 어려워 진다.

REPEATABLE READ

• MySQL에서는 트랜잭션마다 트랜잭션 ID를 부여하여 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다.
• Undo 공간에 백업해두고 실제 레코드 값을 변경한다.
  • 백업된 데이터는 불필요하다고 판단하는 시점에 주기적으로 삭제한다.
  • Undo에 백업된 레코드가 많아지면 MySQL 서버의 처리 성능이 떨어질 수 있다.
• 이러한 변경방식은 MVCC(Multi Version Concurrency Control)라고 부른다.

그렇다면 REPEATABLE READ는 문제가 없을까?

• PHANTOM READ
  • 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안 보였다가 하는 현상
  • 이를 방지하기 위해서는 쓰기 잠금을 걸어야 한다.

SERIALIZABLE

• 가장 단순한 격리 수준이지만 가장 엄격한 격리 수준
• 성능 측면에서는 동시 처리성능이 가장 낮다.
• SERIALIZABLE에서는 PHANTOM READ가 발생하지 않는다. 하지만.. 데이터베이스에서 거의 사용되지 않는다.

배경

MySQL 8.0을 기준으로 INSERT 문을 수행할 때 필요한 비용의 비율은 다음과 같다. 괄호 안의 숫자가 비율을 의미

1. Connecting (3)

2. Sending query to server (2)

3. Parsing query (2)

4. Inserting row (1)

5. Inserting index(1)

6. Closing (1)

즉, 서버가 DB에 연결하기 위한 Connecting 비용이 가장 큰 비율을 차지한다. 이처럼 Connection을 생성하는 작업은 비용이 많이 드는 작업이다. 이를 보완할 수 있는 방법이 바로 Connection Pool이다.

커넥션 풀(Connection Pool)이란?

커넥션 풀은 데이터베이스와 연결된 커넥션을 미리 만들어 놓고 이를 pool로 관리하는 것이다. 즉, 필요할 때마다 커넥션 풀의 커넥션을 이용하고 반환하는 기법이다. 이처럼 미리 만들어 놓은 커넥션을 이용하면 Connection에 필요한 비용을 줄일 수 있다. 따라서 DB에 빠르게 접속할 수 있다.

또한 커넥션 풀을 사용하면 커넥션 수를 제한할 수 있어서 과도한 접속으로 인한 서버 자원 고갈을 방지할 수 있으며 DB 접속 모듈을 공통화해 DB 서버의 환경이 바뀔 경우 유지보수를 쉽게 할 수 있다.

HikariCP란?

• 가벼운 용량과 빠른 속도를 가지는 JDBC의 커넥션 풀 프레임워크

• SpringBoot는 커넥션 풀 관리를 위해 HikariCP를 사용한다.

  HikariCP 동작방식

  유휴 스레드 존재

  

위 같이 Thread가 커넥션을 요청했을 때 유휴 커넥션이 존재한다면 해당 커넥션을 반환해준다.

## 유휴 스레드 부재
![](https://velog.velcdn.com/images/seon___/post/c2d043db-fd9c-4cbd-bbca-c7e4477379a7/image.png)

![](https://velog.velcdn.com/images/seon___/post/a871df29-7903-424e-baac-cc7d1a5338ae/image.png)



만약 유휴 커넥션이 존재하지 않는다면, HandOffQueue를 Polling 하면서 다른 Thread가 커넥션을 반납하기를 기다린다.

다른 Thread가 커넥션 풀에 커넥션을 반납하면 커넥션 풀은 HandOffQueue에 반납된 커넥션을 삽입하고 HandOffQueue를 Polling 하던 Thread는 커넥션을 획득하게 된다.

만약 커넥션 풀의 크기가 너무 작다면, 커넥션을 획득하기 위해 대기하고 있는 Thread가 많아지게 될 것이다. 이러한 문제는 커넥션 풀의 크기를 늘려주면 해결할 수 있다. 그렇다면 커넥션 풀의 크기는 어느 정도인 게 좋을까?

커넥션 풀의 크기와 성능

커넥션풀이 너무 크면

• 커넥션 사용 주체인 Thread의 개수 < 커넥션 풀의 크기

  → 유휴 커넥션이 많아, 메모리의 낭비가 발생한다.

Mysql 공식 레퍼런스 피셜

600여 명의 유저를 대응에 15~20개의 커넥션 풀만으로도 충분하다. MySQL은 최대 연결 수(== 커넥션 수)를 무제한으로 설정한 뒤 부하 테스트를 진행하면서 최적화된 값을 찾는 것을 추천한다.

우아한 형제들 블로그 피셜

• Tn = 전체 Thread의 개수
• Cm = 하나의 Task에서 동시에 필요한 Connection 수
• Pool size = 커넥션 풀의 크기

DB와 WAS의 Context Switching 역시 한계가 있기 때문에 Thread Pool의 크기는 Conncetion Pool의 크기를 결정하는데 매우 중요하다.

• → https://wiki.postgresql.org/wiki/Number_Of_Database_Connections

• 위 레퍼런스에서는 유휴 커넥션을 제외하고 계산하고서도 여분의 용량을 추가한 만큼의 커넥션을 마련해야한다고 한다.
• 위키에서는 나와있는 공식이 조정이 필요하다고 함

트랜잭션이란?

[1] : 작업 수행의 논리적 단위 [2] : 원자성을 지켜야하는 동기화되는 하나의 논리블록(ex. 스크립트)의 단위

트랜잭션 필요한 이유

→ 트랜잭션은 DB 서버에 여러 개의 클라이언트가 동시에 엑세스 하거나 응용프로그램이 갱신을 처리하는 과정에서 중단될 수 있는 경우 등, 데이터 부정합을 방지하고자 할 때 사용합니다.

→ 부정합이 발생하지 않으려면, 프로세스를 병렬로 처리하지 않도록 하여 한 번에 하나의 프로세스만 처리하도록 하면 되는데, 이는 효율이 너무 떨어집니다.

→ 즉 , 병렬로 처리할 수 밖에 없는 현실적인 상황으로 인해 부정합을 방지하고자 트랜잭션을 사용한다.

→ 트랜잭션에서 중요한 점 ⇒ 스케줄 관리!!!

→ 스케줄을 잘못 짜면, 데드락에 빠지게 되는데, 이와 연관된 것이 2PL이다.

특성

1. Atomicity (원자성)
   1. All or Nothing, 작업 단위를 일부분만 실행하지 않는다는 것 의미
2. Consistency (일관성)
   1. 트랜잭션이 성공완료되면, 일관적인 DB 상태를 유지
   2. EX) 송금 전후 모두 금액의 데이터타입은 정수형이여야 한다.
3. Isolatioin (격리성)
   1. 트랜잭션끼리 서로 끼어들지 못한다.
4. Durability (지속성)
   1. 커밋하면 현재 상태는 영원히 보장된다.

1. 원자성 보장

• [ 트랜잭션의 원자성 보장 방법 ]

  수행하고 있는 트랜잭션에 의해 변경된 내역을 유지하면서, 이전에 commit된 상태를 임시 영역에 따로 저장함으로써 보장

  → EX) 현재 수행하고 있는 트랜잭션에서 오류가 발생하면 현재 내역을 날려버리고 임시 영역에 저장했던 상태로 rollback 합니다.

• Rollback Segment : 이전 데이터들이 임시로 저장되는 영역

• 데이터베이스 테이블 : 현재 수행하고 있는 트랜잭션에 의해 새롭게 변경되는 내역

• [ save point ]

  트랜잭션의 길이가 긴 경우, 오류가 나면 확실하게 진행된 부분도 다시 작업 수행해야함.

  → 확실한 부분에 대해서는 rollback이 되지 않도록 중간 저장 지점인 save point를 지정할 수 있습니다.

  save point를 지정하면 rollback 할 때 save point 이전은 확실하다 간주하고 그 이후부터 진행하게 됩니다.

2. 일관성 보장

• [ 일관성이란? ]

  트랜잭션에서 일관성은 트랜잭션 수행 전, 후에 데이터 모델의 모든 제약 조건(기본키, 외래키, 도메인, 도메인 제약조건 등)을 만족하는 것을 통해 보장

• 한 쪽의 테이블에만 데이터 변경사항이 이루어지면 안되는 것

• [ 트랜잭션의 일관성 보장 방법 ]

  → 어떤 이벤트와 조건이 *발생했을 때, *트리거( Trigger ) 를 통해 보장

위 코드는, 트리거가 호출되면, 수행할 질의들을 트리거로 생성해서 작성한 코드.

after는 트리거가 실행되기 위한 event를 나타냅니다.

3. 격리성 보장

1) 병행 처리 ( concurrent processing )

CPU가 여러 프로세스를 처리하는 것처럼, 트랜잭션에 정해진 시간을 할당해서 작업을 하다가 부여된 시간이 끝나면 다른 트랜잭션을 실행하는 이런 방식으로 트랜잭션들을 조금씩 처리하는 것을 말합니다.

그런데 이렇게 되면 많은 트랜잭션들이 조금씩 처리되는 과정에서 공통된 데이터를 조작하게 되는데, 이 경우 데이터가 혼란스러워 질 수 있습니다.

<aside>
❗ A 트랜잭션에서 x라는 데이터를 100으로 설정한 후 시간이 만료되어 B 트랜잭션으로 넘어갔다고 가정해보겠습니다. 
B 트랜잭션에서는 x 데이터에 -50 연산을 해서 저장을 했을때, 시간이 만료되어 다시 A 트랜잭션이 실행될 경우 x 데이터의 값은 50이 됩니다.

</aside>

이렇게 트랜잭션이 조금씩 수행될 때, 공통된 데이터가 다른 트랜잭션에 의해 방해되면 안됩니다.

이와 같이 트랜잭션의 간섭이 일어날 경우 갱신분실, 오손판독, 반복불가능, 팬텀문제 등 여러 문제점들이 발생합니다.

2) 트랜잭션의 격리성 보장 방법

1. Lock & Excute unlock
   • 즉, 데이터를 읽거나 쓸 때는 문을 잠궈서 다른 트랜잭션이 접근하지 못하도록 고립성을 보장하고, 수행을 마치면 unlock을 통해 데이터를 다른 트랜잭션이 접근할 수 있도록 허용하는 방식입니다.
   • 트랜잭션에서는 데이터를 읽을 때, 여러 트랜잭션이 읽을 수는 있도록 허용하는 shared_lock을 합니다.
   • 즉, shared_lock은 데이터 쓰기를 허용하지 않고 오직 읽기만 허용합니다.
   • 또한 데이터를 쓸 때는 다른 트랜잭션이 읽을 수도 쓸 수도 없도록 하는 exclusive_lock을 사용합니다.
   • 그리고 읽기, 쓰기 작업이 끝나면 unlock을 통해 다른 트랜잭션이 lock을 할 수 있도록 데이터에 대한 잠금(lock)을 풀어줍니다.

→ 잘못 사용하면 데드락(DEADLOCK)상태에 빠질 수 있다.

1. 2PL 프로토콜 ( 2 Phase Locking Protocol )

   : 데드락 방지를 위해 특정 규칙에 의해서 고립성을 보장해야한다는 프로토콜

   : 여러 트랜잭션이 공유하고 있는 데이터에 동시에 접근할 수 없도록 하기위한 목적을 가진 프로토콜

   • 이름 그대로 2가지 단계의 locking이 존재하는데, 1) growing phase, 2) shrinking phase입니다.

   • 상승 단계란 read_lock , write_lock을 의미하고, 하강 단계란 unlock를 의미합니다.

   • 2PL 프로토콜은 상승 단계와 하강 단계와 섞이면 안된다는 것을 의미합니다.

   • 즉, lock과 unlock이 번갈아 수행되지 않고 lock이 쭉 수행된 후에 unlock이 쭉 수행되어야 한다는 것이 이 프로토콜입니다.

     정리하면 성능을 위해 병행처리를 해야하는데, 트랜잭션의 고립성을 보장하기 위해서는 2PL을 사용해야 한다는 것입니다. ( Serializable Schedule )

   • [ Locking 하는 두가지 방법 ]

     • 보수적 Locking ( conservative locking )
       • 트랜잭션이 시작되면 모든 lock을 얻는 방식으로서, 데드락이 발생하지 않지만 병행성이 좋지 못함
     • 엄격한 Locking ( strict locking )
       • 트랜잭션이 commit을 만날 때까지 lock을 갖고 있다가 commit을 만날때 unlock을 하는 방식으로 데드락이 발생하지만 병행성이 좋음
       • 일반적으로 병행성이 좋은 strict 방식을 사용합니다.

RDB는 일반적으로 잠금 스케줄러를 사용

인덱스에 대해 얘기하기전에...

페이지(Page)란?

책이 페이지로 구성되어 있는 것처럼 SQL 서버도 여러 Page로 구성되어 있으며 크기는 8KB입니다. SQL 서버의 가장 기본적인 단위로 실제로 SQL 서버에 데이터의 접근 시에는 Page 단위로 접근합니다. Page는 대부분 Data로 구성되어 있지만 일부 페이지는 인덱스(데이터 위치), 텍스트/이미지 등등으로도 구성되어 있습니다. 각 페이지는 96바이트의 헤더로 구성되어 있으며, 헤더는 페이지에 대한 시스템 정보를 저장합니다. 추가로 정리해보면 다음과 같습니다.

• 데이터 파일을 구성하는 논리 단위
• SQL Server의 기본 데이터 저장 단위 ( 8KB )
• 데이터를 쓸 때 행이 페이지에 기록됨
• 데이터를 읽을 때 페이지 내의 모든 행이 읽어짐
• 페이지 내의 행이 많을 수록 I/O 효율 증가
• 페이지 번호는 0~n 사이의 순차적인 번호가 존재

데이터를 Insert하게 된다면 페이지에 들어가게 되고, 테이블에 쿼리를 날려 조회하는 것이 아니라 페이지에서 SELECT하는 것으로 생각하면 됩니다.

인덱스란?

인덱스는 데이터베이스의 테이블에 대한 검색 속도를 향상시켜주는 자료구조이다. 데이터베이스와 마찬가지로 인덱스도 디스크 공간에 저장된다.

(DB크기의 10%정도의 추가 공간 필요)

테이블의 특정 칼럼에 인덱스를 생성하면, 해당 칼럼의 데이터를 정렬한 후 별도의 메모리 공간에 데이터의 물리적주소와 함께 저장된다.

인덱스는 책에서의 목차 혹은 색인 이라고 생각하면 된다.

그러므로,

데이터 = 책의 내용

인덱스 = 책의 목차

물리적주소 = 책의 페이지 번호

라고 생각할 수 있다.

인덱스의 장단점

장

• 테이블 검색 속도와 성능이 향상
• 인덱스에 의해 데이터들이 정렬된 형태를 갖는다
  • where 문의 경우, 테이블전체를 조건과 비교해야하는 풀 테이블 스캔 작업
  • ORDER BY 나 MIN/MAX 같은 경우, 이미 정렬되어있는 상태여서 빠르게 수행가능

단

1. 인덱스 관리하기 위한 추가작업이 필요
   1. INSERT : 새로운 데이터에 대한 인덱스 추가하는 작업 필요
   2. DELETE : 삭제하는 데이터의 인덱스를 “사용하지 않음” 처리 작업 수행 이루어짐
   3. UPDATE : 기존의 인덱스를 “사용하지 않음” 처리, 갱신된 데이터에 대한 인덱스 추가하는 작업 이루어짐
2. 추가 저장 공간이 필요
   1. 수정의 경우, 데이터의 인덱스를 제거하는 게 아니라, “사용하지않음” 처리하고 남겨두기 때문에 실제 데이터에 비해 인덱스가 과도하게 커지는 문제점이 발생 할 수 있고, 별도의 메모리 공간에 저장되기 때문에 , 추가저장공간이 많이 필요하게된다.
3. 전체데이터의 10~15% 이상의 데이터를 처리 하거나 , 데이터의 형식(나이,성별과 같이 값의 range가 적은 컬럼인 경우)에 따라 오히려 성능이 낮아질 수 있다.

인덱스 사용하기 좋은 경우

1. 규모가 큰 테이블
2. 데이터의 range가 넓고, 중복이 적은 칼럼
3. 삽입, 수정, 삭제 작업이 자주 발생하지 않는 칼럼
4. WHERE 나 ORDER BY, JOIN 등이 자주 사용되는 칼럼
5. 데이터의 중복도 낮은 칼럼

인덱스의 자료구조

1. 해쉬테이블

   → 해시 테이블을 이용한다면 인덱스는 (key, value) = (컬럼의 값, 데이터의 위치)로 구현하는데, 해시 테이블은 실제로 인덱스에서 잘 사용되지 않는다.

   그 이유는, 해시 테이블은 등호(=) 연산에 최적화되어있기 때문이다. 데이터베이스에선 부등호(<, >) 연산이 자주 사용되는데, 해시 테이블 내의 데이터들은 정렬되어 있지 않으므로 특정 기준보다 크거나 작은 값을 빠른 시간 내에 찾을 수가 없다.

2. B+Tree

   → B+Tree 자료구조

   • 기존의 B-Tree는 어느 한 데이터의 검색은 효율적이지만, 모든 데이터를 한 번 순회하는 데에는 트리의 모든 노드를 방문해야 하므로 비효율적이다. 이러한 B-Tree의 단점을 개선시킨 자료구조가 B+Tree이다.
   • 인덱스 칼럼은 부등호를 이용한 순차 검색연산이 자주 발생할 수 있는데, B+Tree의 LinkedList를 이용하면 순차검색을 효율적으로 할 수 있게 된다.

인덱스의 종류

클러스터형 인덱스 (logN)

• 데이터가 재정렬
• 보조 인덱스보다 검색 속도는 더 빠르다. (단, 입력/수정/삭제 는 더 느림.)
• 인덱싱 처리한 column이 수정될때마다(데이터 하나마다) 재정렬된다.
• pk에 자동적용된다.

보조 인덱스 (non-clustered index) (2logN)

• 데이터 페이지는 그냥 둔 상태에서 별도의 페이지에서 인덱스를 구성 → (자동정렬 되지 않음 EX.책의 색인)

• 클러스터형 인덱스가 더 빠른 이유? / 자료구조가 다른가..?

  • 클러스터는 데이터에 직접 접근 → 원본데이터가 정렬된다.
  • 보조는 별도의 페이지로 접근

CompletableFuture사용 시, 별다른 스레드풀을 명시하지 않으면, ForkJoinPool를 사용한다고 한다.

ForkJoinPool 이란?

• Task를 fork를 통해서 Subtask로 나누고 하나의 스레드에서 모든 것을 처| 리하지 않고 sub로 나눈다.

• Thread pool에서 steal work 알고리즘을 이용해서 균등하게 처리해서
• join을 통해 결과를 생성

그림으로 보면 다음과 같음

다양한 스레드풀 환경설정들

public class Executors {
    // 단일 쓰레드로 구성된 스레드 풀을 생성. 한번에 하나의 작업만 실행
    public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
        return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>(),
                                    threadFactory));
    }
    // 고정된 크기의 쓰레드풀을 생성
    public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());
    }
      // 사용 가능한 쓰레드가 없다면 새로 생성해서 작업을 처리하고, 있다면 재사용. 쓰레드가 일정 시간 사용되지 않으면 회수
    public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
    }
    // 스케줄링 기능을 갖춘 고정 크기의 쓰레드 풀을 생성. 주기적이거나 지연이 발생하는 작업을 실행
    public static ScheduledExecutorService newScheduledThreadPool(
            int corePoolSize, ThreadFactory threadFactory) {
        return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);
    }
    // work steal 알고리즘을 사용하는 ForkJoinPool을 생성
    public static ExecutorService newWorkStealingPool(int parallelism) {
        return new ForkJoinPool
            (parallelism,
             ForkJoinPool.defaultForkJoinWorkerThreadFactory,
             null, true);
    }
}

스레드풀 환경설정요인 상세보기

스레드풀을 어떻게 하면 적합하게 설정을 해줄 수 있는지가 궁금해서 스레드풀executor를 더 알아보고 싶었음.

ThreadPoolExecutor 라이브러리를 타고들어가면 자세한 설명이 있다.

1. corePoolSize : 풀안에서 유지하는 스레드 개수
2. maxiumPoolsize: 가능한 최대 스레드 개수
3. keepAliveTime : 코어보다 스레드수가 많을때, 작업대기시간. 해당 시간동안 놀게되면 종료됨.
4. unit (TimeUnit) : keepAliveTime의 단위. ex.Milliseconds.
5. workQueue (BlockingQueue) : 모든 스레드가 작업 중일때 task를 보관할 큐.

Gateway 패턴 변천사

#1 Monolitic Gateway방식

다른 로직에서 같은 게이트웨이 사용 웹에서 필요한 로직과 앱에서 필요한 로직이 다르지만, 게이트웨이는 모두 가지고 있어야 포워딩이 된다.

이를 해결하기 위해, Backend For Frontend 패턴이 나옴

#2 BFF 패턴 (Backend For Frontend)

관심사의 분리

web용 App용 게이트웨이를 분리.

#3 Ingress/Egress 패턴

요청방향에 맞게 분리하는 패턴.

클러스터에 들어오는 요청 처리 : Ingress Gateway

클러스터에서 나가는 요청 처리 : Egress Gateway

위 패턴들을 활용한 토스의 아키텍쳐

서비스 개발자는 Client목적에 맞는 GW를 사용하여 라우트를 추가해주고, 해당 라우트에 필요한 로직을 넣어 서비스 로의 요청을 완성한다.

mTLS : (보안)인증서 관련 요청

망분리 : 사내

SSR : 서버 사이드 렌더링 관련 요청

Egress GW 로 외부 요청 보냄

[위 아키텍쳐 구현에 토스에서 사용한 스택]

Spring cloud Gateway (Springwebflux, Reactor-Netty ) 사용

Filter 개발에 Kotlin Coroutine사용

Istio의 Ingress/Egress, Envoy필터 사용

Gateway 에서 사용되는 공통 로직의 종류

Request 처리

유저

보안

서비스 안정화

1. Request 처리

게이트웨이에서 처음으로 해줘야하는 일은 데이터 Sanitize이다.

Sanitize란? :클라이언트로부터 올바르지 않은 요청이 올 경우, 이를 지워주거나 올바른 값으로 바꿔주는 것.

(ex. 악의적인 요청이 와도 GW에서 이를 올바른 값으로 변경후 서비스로 넘긴다.)

#1 Trace ID 생성

GW는 서비스의 진입점이라서, MSA내 트랜잭션을 구분할수있는 trace ID을 부여함.

이렇게 생성된 Trace id는 각자의 서비스에서 MDC 컨텍스트에 저장되고,

로그를 남길때 이를 같이 남긴다.

그림같이 트랜잭션별 로그 구분가능

#2 하나의 트랜잭션안에 여러 서비스에서 공통으로 필요한 정보가 있는 경우

[기존방식]

모든 서비스가 공통 API 요청

[GW사용후]

GW단에서 internal Header에 필요공통정보를 넣어서 전파한다.

유저 정보

[기존방식]

유저 정보가 필요할때마다 유저정보조회API사용

[개선 후]

<넷플릭스의 Passport 구조 참고함>

유저 인증시, Passport라는 ID 토큰을 트랜잭션내로 전파함.

passport란? 사용자 기기 정보와 유저 정보를 담은 하나의 토큰이다.

• 인증 과정이 GW에 붙어있음

• passport 토큰을 응답하면, 이를 Serialize해서 서비스에 전파한다.

보안

1. 다양한 인증방식 사용

종단간 암호화를 통해 패킷 분석의 허들을 높여 안전하게 통신한다.

암호화가 애매한 SSR요청을 위해서 JWT인증방식도 사용한다.

위 두 그림은 OAuth / JWT방식또한 인증할때 사용한다는 말.. 특별히 다른 점은 없다

2. 위변조 여부 검증

각 요청이 실제로 위변조 되지않은 토스앱에서 만들어진 요청인지도 검증한다.

요청당 아주짧은유효기간을 가진 키값 + 토스앱에서만 알수있는 정보

를 가지고 요청을 서명하고 이를 GW에 보낸다.

토큰 위변조 감지시, FDS(Fraud Detection System)를 통해 계정을 비활성화하여 사용자 보호함

FDS에 대한 추후 연구 필요

FDS는 유저 행위 분석 기반으로 다양한 룰베이스로 수상한 행동 감지한다.

감지하는 경우 GW로 정보보내, IPS로 차단. → 특정 유저 , 특정 디바이스가 특정 API를 이용하지 못하게 함

3. 인증서 mTLS 인증

Istio 에서 제공하는 mTLS flow위에 레이어를 하나 얹어 사용함

그냥 써도 되지만 코드베이스인 경우에 Auditing, 카나리배포방식사용 등에서 이점이 있다함.

4. OIDC

5. 서킷브레이킹

1. 리액티브란?

| 리액티브란? 즉각적으로 변화하는 데이터에 대해 반응하는 프로그래밍 모델. -> 이 개념은 비동기성과 반응성을 통해 더욱 효율적이고 유연한 애플리케이션을 구축하는 혁신적인 방법 .. 이라고 한다.

2. 리액티브 시스템

위는 리액티브 선언문에 나오는 그림이다.

리액티브는 4가지 설계원칙이 있는하는데 다음과 같다.

1. Responsive (응답성)

• 가능한 한 즉각적으로 응답하는 것을 말합니다. 사용자의 입장에서 가장 중요한 항목이 되겠지요. 소프트웨어는 당연히 사용자가 필요로 할 때 빠르게 응답해야 합니다. 응답성은 Reactive Manifesto의 4가지 속성 중 가장 중요하고, 나머지 아래 3가지 요소는 응답성을 위하여 존재하는 하위 요소입니다.

2. Resilient (탄력성)

• 시스템이 장애에 직면하더라도 응답성을 유지하는 것입니다. Fault Tolerence(장애 허용)와 밀접한 개념이기도 합니다. 부분적인 장애나 고장이 시스템 전체를 망가뜨리지 않습니다. 시스템 고장을 예외가 아닌 시스템 기능의 일부로 받아들입니다.

3. Elastic (유연성)

• 시스템의 작업량이 변하더라도 응답성을 유지하는 것입니다. 리액티브 시스템은 트래픽에 따라 Scale Up과 Scala Down이 쉬워야 합니다. 리액티브 선언의 초기 버전에는 Scalable 이라는 말을 썼지만, 이것은 Scale Up에 해당하는 용어라, Scale Up과 Down을 동시에 표현하는 Elastic 이라는 용어로 바뀌었습니다.

4. Message Driven (메시지 구동)

• 소프트웨어 내부에서 의사소통을 하는 방식이 메시지를 전달하는 방식으로 구성되어 있습니다. 소프트웨어를 구성하는 각 부분들은 비동기적으로 메시지를 주고받습니다. 메시지를 주고받을 때는 보내고 잊는(fire-and-forget) 방식을 이용합니다.

3. 리액티브 프로그래밍

In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change.

변화의 전파와 데이터 흐름과 관련된 선언적 프로그래밍 패러다임이다.

변화의 전파와 데이터 흐름 : 데이터가 변경 될 때마다 이벤트를 발생시켜서 데이터를 계속적으로 전달 선언적 프로그래밍 : 실행할 동작을 구체적으로 명시하는 명령형 프로그래밍과 달리 선언형 프로그래밍은 단순히 목표를 선언

리액티브 프로그래밍을 사용하는 이유

비동기적인 이벤트 처리 리액티브 프로그래밍에서는 이벤트를 비동기적으로 처리하기 때문에, 이벤트가 발생하는 즉시 처리할 수 있습니다. 이는 일반적으로 스레드와 락에 의존하는 전통적인 동기적인 프로그래밍 방식보다 훨씬 효율적이며, 대규모 시스템에서 높은 성능을 보장합니다.

데이터 스트림 처리 리액티브 프로그래밍에서는 데이터 스트림을 다룰 수 있습니다. 이러한 데이터 스트림은 무한하거나 큰 양일 수 있으며, 이벤트가 발생할 때마다 해당 이벤트를 처리하는 콜백 함수를 등록합니다. 이러한 방식은 대규모 데이터 처리에 적합합니다.

반응형 시스템 구현 리액티브 프로그래밍은 반응형 시스템을 구현하는 데 적합합니다. 이는 시스템이 외부 요청에 신속하게 반응하고, 빠른 응답 시간을 제공할 수 있도록 하는 기능입니다.

옵저버 패턴

리액티브 프로그래밍은 옵저버 패턴에 많은 영감을 받았다고 합니다. 옵저버 패턴이란 GoF가 소개한 디자인 패턴 중 하나로 관찰 대상이 되는 객체가 변경되면 대상 객체를 관찰하고 있는 옵저버(Observer)에게 변경사항을 통지(notify) 하는 디자인 패턴을 말합니다. 리액티브 프로그래밍은 옵저버 패턴의 서브젝트와 옵저버의 개념과 유사한 발행자와 구독자를 사용해 데이터를 통지하고 처리합니다. 데이터를 제공하는 측에서 데이터를 소비하는 측으로 통지하는 방식(ex.데이터가 있음을 알리는 방식-지속적으로 확인X)을 일반적으로 푸시 기반 (Push-Based)이라고 부릅니다.

리액티브 개념의 적용 예시

Push 방식 : 데이터의 변화가 발생했을 때 변경이 발행한 곳에서 데이터를 보내주는 방식

• RTC (Real Time Communication)
• Socket
• Push message 등

<->

Pull 방식 : 변경된 데이터가 있는지 요청을 보내 질의하고 변경된 데이터를 가져오는 방식

• 클라이언트 요청 - 서버 응답 방식의 어플리케이션
• Java와 같은 절차지향형 프로그래밍 언어 등
• Long polling

4. 리액티브 스트림즈

[배경] 리액티브 프로그래밍을 구현한 라이브러리들이 정해진 표준없이 구현되기 시작했습니다. 이에 하나의 규칙을 정해서, 여러 리액티브 프로그래밍 구현체들이 상호 변환 가능하도록 만들자는 목소리가 나오기 시작했습니다.

그렇게 만들어진 규칙이 리액티브 스트림즈입니다.

[예시] 리액티브 스트림은 non-blocking(넌블럭킹), backPressure(역압)을 이용하여 리액티브 프로그래밍을 할 때 비동기 데이터 처리의 표준이 되는 스펙입니다.

대표적인 리액티브 스트림즈 표준을 따르는 구현체들은_ RxJava, Reactor, Akka _ 등이 있습니다.

backPressure

백프레셔는 리액티브 스트림에서 발생하는 데이터 처리 속도 조절과 관련된 문제를 해결하기 위한 메커니즘입니다.

과부하 상태의 컴포넌트에서 치명적인 장애가 발생하거나 제어 없이 처리 중인 메시지를 유실해서는 안 됩니다. 컴포넌트는 장애가 발생해선 안 되기 때문에 상위 컴포넌트에 자신이 과부하 상태라는 것을 알려 부하를 줄이도록 해야 합니다.

데이터 생산자와 소비자 간의 처리 속도 차이로 인해 데이터 처리 과정에서 발생하는 문제를 방지하기 위해 사용됩니다.

[백프레셔에 대한 비유] 현실세계의 화장실에서 우리는 물을 사용하기 위해 수도꼭지를 적정량만 틀어 사용합니다. 물이 적절하게 나와야 우리는 그 물들을 받아 처리(사용)할 수 있습니다. 물이 과도하게 나오면 우리의 처리량이 이를 받쳐주지 못하고 나머지 물은 모두 유실될 것입니다. 소프트웨어 세계에서는 이는 곧 장애입니다. 백프레셔는 이런 수도꼭지같은 역할을 수행합니다.

백프레셔는 주로 pull 방식을 채택합니다. 즉, 소비자가 데이터를 필요로 할 때마다 데이터를 요청하여 가져오는 방식입니다. 이를 통해 소비자가 처리할 수 있는 만큼의 데이터만 가져오면서 문제를 방지할 수 있습니다.

비동기데이터흐름에는 push방식을 사용하지만, 수송신 데이 터 처리속도조절에는 pull방식을 사용한다.

🙋🏻 위에서 리액티브 프로그래밍은 Push 방식이라고 하지 않았나요? 리액티브 스트림은 push 방식을 따릅니다. 즉, 데이터 생산자가 데이터를 생성하고 변경되는 즉시 데이터를 소비자에게 푸시(push)하여 전달하는 방식입니다.

리액티브 프로그래밍과 백프레셔는 서로 다른 측면에서 동작하며, 리액티브 스트림은 비동기 데이터 흐름을 기술하고, 백프레셔는 송신자와 수신자 사이의 데이터 처리 속도 조절에 초점을 둡니다.

백프레셔가 없으면 발생하는 일

Subscriber가 처리하는 속도보다 Publisher가 발행하는 속도가 빠른경우, 대기 중인 데이터가 지속적으로 쌓이면서 오버플로가 발생하거나 최악의 경우에는 시스템이 다운되는 사태가 발생할 수 있습니다.

이러한 문제를 해결하기 위해 백프레셔가 필요합니다.

| 예상. publisher가 subscriber의 처리완료여부를 체크 + 완료된 경우, 새로운 처리를 발생시킴.

리액티브 스트림즈의 인터페이스들

• Publisher : 데이터를 생성하고 통지
• Subscriber : 통지된 데이터를 전달받아서 처리
• Subscription : 전달받을 데이터의 갯수를 요청하고 구독을 해지
• Processor : Publisher와 Subscriber의 기능이 모두 있음

리액티브 스트림즈 컴포넌트

리액티브 스트림즈는 4개의 인터페이스인 Publisher(발행자), Subscriber(구독자), Subscription(구독), Processor(프로세서)로 요약이 가능합니다.

발행자(Publisher)는 데이터를 생성하고 통지(발행, 게시, 방출)합니다.

구독자(Subscriber)는 Subscription를 통해 Publisher에게 자신이 처리할 수 있는 만큼의 데이터를 요청하고 처리합니다.

Subscription은 Publisher에 요청할 데이터의 개수를 지정하고 데이터의 구독을 취소하는 역할을 합니다.

Processor 인터페이스는 Subscriber, Publisher 인터페이스를 결합한 것라고 보면 됩니다. 즉 Subscriber로서 다른 Publisher를 구독할 수 있고, Publisher로서 다른 Subscriber가 구독할 수 있습니다.

이때 발행자가 제공할 수 있는 데이터의 양은 무한(unbounded) 하고 오퍼레이션에 따라 순차적(sequential) 처리를 보장합니다.

Reactor란?

스프링 프레임워크는 자바를 기반으로 할 경우 리액티브 스트림즈 구현체인 Reactor를 사용

RxJava

• Block

  호출된 함수가 자신이 할 일을 모두 마칠 때까지 제어권을 계속 가지고서 호출한 함수에게 바로 제어권을 리턴하지않는다. (호출된 함수가 수행을 마칠동안 블록된다.)

• Non-Block

호출된 함수가 자신이 할 일을 마치지 않았더라도 바로 제어권을 리턴하여 호출한 함수가 다른일을 진행할 수 있도록한다.
(수행을 마치든 아니든 블록되지 않는다.)

| 정리해보면서 블로킹/논블로킹은 제어권을 리턴하느냐와 관련있다고 느낌!

Sync vs Async ( 동기 vs 비동기) (= 작업의 완료에 초점)

• Synchronous Synchronous : 동시적인 즉, 호출와 종료의 시점이 동시이다. [특징]

  1. 호출된 함수의 수행결과 및 종료를 
  호출된 함수와 호출한 함수도 함께 신경쓴다.  
  → 이말은, Callback개념이 없다. / 폴링으로 계속 완료 확인을 해줘야한다.

• Asynchronous 호출과 종료의 시점이 동시가 아니어도 됨. 즉, 함수종료시점과 무관하게 호출이 가능. [특징]
  1. 호출된 함수의 수행결과 및 종료를 호출된 함수에서 알린다. → 완료되면 Callback수행해서 완료를 알린다.

관심사의 차이

두 가지 개념의 차이는 관심사 측 어디에 초점을 두느냐의 차이.

동기(Synchronous)와 비동기(Asynchronous)는 작업의 완료에 초점을 두고 있다.

하나의 쓰레드가 다른 쓰레드의 작업 종료일 경우에 작업 시작하면 동기 하나의 쓰레드가 작업이 완료 되던지 말던지 신경쓰지 않고 다른 쓰레드에서 작업 시작을 할 수 있으면 비동기

반면에 블로킹(Blocking)과 논블로킹(NonBlocking)은 호출되는 제어권 리턴되는 시점에 초점을 두고 있다.

호출된 함수가 바로 리턴하지 않고, 제어권을 가지고 있으면서 해당 함수가 종료될 때 제어권을 넘긴다면 블로킹 호출된 함수가 완료되지 않아도 제어권을 바로 호출한 함수에게 넘긴다면 논블로킹

패턴 코드

// 기초 커맨드 클래스는 모든 구상 커맨드에 대한 공통 인터페이스를 정의합니다.
abstract class Command is
    protected field app: Application
    protected field editor: Editor
    protected field backup: text

    constructor Command(app: Application, editor: Editor) is
        this.app = app
        this.editor = editor

    // 편집기의 상태에 대한 백업을 만드세요.
    method saveBackup() is
        backup = editor.text

    // 편집기의 상태를 복원하세요.
    method undo() is
        editor.text = backup

    // 실행 메서드는 모든 구상 커맨드들이 자체 구현을 제공하도록 강제하기 위해
    // 추상으로 선언됩니다. 이 메서드는 커맨드가 편집기의 상태를 변경하는지에 따라
    // 진실 또는 거짓을 반환해야 합니다.
    abstract method execute()


// 구상 커맨드들은 여기에 배치됩니다.
class CopyCommand extends Command is
    // 복사 커맨드는 편집기의 상태를 변경하지 않으므로 기록에 저장되지 않습니다.
    method execute() is
        app.clipboard = editor.getSelection()
        return false

class CutCommand extends Command is
    // cut 커맨드는 편집기의 상태를 변경하므로 기록에 반드시 저장되어야 하며,
    // 메서드가 true를 반환하는 한 저장됩니다.
    method execute() is
        saveBackup()
        app.clipboard = editor.getSelection()
        editor.deleteSelection()
        return true

class PasteCommand extends Command is
    method execute() is
        saveBackup()
        editor.replaceSelection(app.clipboard)
        return true

// 실행취소 작업도 커맨드입니다.
class UndoCommand extends Command is
    method execute() is
        app.undo()
        return false


// 글로벌 커맨드 기록도 스택일 뿐입니다.
class CommandHistory is
    private field history: array of Command

    // 후입 …
    method push(c: Command) is
        // 커맨드를 기록 배열의 끝으로 푸시하세요.

    // … 선출
    method pop():Command is
        // 기록에서 가장 최근 명령을 가져오세요.


// 편집기 클래스에는 실제 텍스트 편집 기능이 있습니다. 이는 수신기의 역할을
// 합니다. 모든 커맨드들은 결국 편집기의 메서드들에 실행을 위임합니다.
class Editor is
    field text: string

    method getSelection() is
        // 선택된 텍스트를 반환하세요.

    method deleteSelection() is
        // 선택된 텍스트를 삭제하세요.

    method replaceSelection(text) is
        // 현재 위치에 클립보드의 내용을 삽입하세요.


// 앱 클래스는 객체 관계들을 설정하며 발신자 역할을 합니다. 이것은 무언가를
// 수행해야 할 때 커맨드 객체를 만들고 실행합니다.
class Application is
    field clipboard: string
    field editors: array of Editors
    field activeEditor: Editor
    field history: CommandHistory

    // 사용자 인터페이스 객체들에 커맨드들을 할당하는 코드는 다음과 같을 수
    // 있습니다.
    method createUI() is
        // …
        copy = function() { executeCommand(
            new CopyCommand(this, activeEditor)) }
        copyButton.setCommand(copy)
        shortcuts.onKeyPress("Ctrl+C", copy)

        cut = function() { executeCommand(
            new CutCommand(this, activeEditor)) }
        cutButton.setCommand(cut)
        shortcuts.onKeyPress("Ctrl+X", cut)

        paste = function() { executeCommand(
            new PasteCommand(this, activeEditor)) }
        pasteButton.setCommand(paste)
        shortcuts.onKeyPress("Ctrl+V", paste)

        undo = function() { executeCommand(
            new UndoCommand(this, activeEditor)) }
        undoButton.setCommand(undo)
        shortcuts.onKeyPress("Ctrl+Z", undo)

    // 커맨드를 실행하여 기록에 추가해야 하는지 확인하세요.
    method executeCommand(command) is
        if (command.execute())
            history.push(command)

    // 기록에서 가장 최근의 커맨드를 가져와서 그의 실행 취소 메서드를 실행하세요.
    // 참고로 우리는 이 커맨드의 클래스를 알지 못한다는 사실에 유념하세요.
    // 하지만 몰라도 상관없는데, 그 이유는 커맨드가 자신의 작업을 실행 취소하는
    // 법을 알기 때문입니다.
    method undo() is
        command = history.pop()
        if (command != null)
            command.undo()

실제 사례

• 스프링의 Command

스프링의 Command는 컨트롤러의 요청을 처리하는 역할을 합니다. Command 인터페이스를 구현한 클래스는 다양한 요청을 처리할 수 있습니다. 예를 들어, SaveUserCommand 클래스는 사용자를 저장하는 요청을 처리하고, DeleteUserCommand 클래스는 사용자를 삭제하는 요청을 처리합니다.

Command는 명령 패턴을 사용하여 구현되었습니다. Command 인터페이스는 요청을 처리하는 알고리즘을 정의하는 추상 메서드 execute()를 제공합니다. 각 Command 구현체는 execute() 메서드를 구현하여 특정 요청을 처리하는 알고리즘을 제공합니다.

• 자바의 Runnable

자바의 Runnable 인터페이스는 스레드를 실행하는 역할을 합니다. Runnable 인터페이스를 구현한 클래스는 스레드에서 실행할 작업을 정의할 수 있습니다. 예를 들어, PrintMessageRunnable 클래스는 콘솔에 메시지를 출력하는 작업을 정의합니다.

Runnable은 명령 패턴을 사용하여 구현되었습니다. Runnable 인터페이스는 스레드에서 실행할 작업을 정의하는 추상 메서드 run()를 제공합니다. 각 Runnable 구현체는 run() 메서드를 구현하여 스레드에서 실행할 작업을 정의합니다.

• 웹 브라우저의 Button

웹 브라우저의 Button은 사용자의 클릭을 처리하는 역할을 합니다. Button은 클릭 이벤트를 발생시킬 때, Command 객체를 전달할 수 있습니다. Command 객체는 클릭 이벤트를 처리하는 역할을 합니다.

웹 브라우저의 Button은 명령 패턴을 사용하여 구현되었습니다. Command 객체는 클릭 이벤트를 처리하는 알고리즘을 정의합니다.

명령 패턴은 다음과 같은 장점이 있습니다.

• 요청을 일관되게 처리할 수 있다.
• 요청을 전달하고 처리하는 방식을 추상화할 수 있다.
• 코드의 재사용성을 높일 수 있다.

명령 패턴은 다양한 프레임워크에서 적용되어, 애플리케이션의 개발과 유지보수를 보다 쉽고 효율적으로 만들어 줍니다.

다음은 명령 패턴이 적용된 프레임워크의 서비스의 예입니다.

• 스프링의 CommandController

스프링의 CommandController는 Command 객체를 사용하여 요청을 처리하는 컨트롤러입니다. CommandController는 Command 객체의 execute() 메서드를 호출하여 요청을 처리합니다.

• 자바의 ExecutorService

자바의 ExecutorService는 스레드를 실행하는 서비스입니다. ExecutorService는 Runnable 객체를 사용하여 스레드를 실행합니다.

• 웹 브라우저의 onClick() 이벤트

웹 브라우저의 Button은 onClick() 이벤트를 발생시킬 수 있습니다. onClick() 이벤트는 Button이 클릭되었을 때 발생합니다. onClick() 이벤트의 핸들러는 Command 객체를 전달받을 수 있습니다.

• 필드로 부모스트레지를 갖는다.

• 세터로 받는 메소드가있다.

• 행위메소드에서 스트레지클래스에 위임한다.

실제 사례

전략 패턴은 알고리즘을 객체로 분리하여 구현하는 디자인 패턴입니다. 이를 통해 애플리케이션의 핵심 기능과 알고리즘을 분리하여, 알고리즘을 변경하거나 확장하기 쉽도록 합니다.

전략 패턴은 다양한 프레임워크에서 적용되고 있습니다. 대표적인 예로는 다음과 같은 것들이 있습니다.

• 스프링의 MessageConverter

스프링의 MessageConverter는 HTTP 요청/응답의 메시지 바디를 변환하는 역할을 합니다. MessageConverter 인터페이스를 구현한 클래스는 다양한 메시지 포맷을 지원합니다. 예를 들어, Jackson2HttpMessageConverter 클래스는 JSON 포맷을 지원하고, XmlHttpMessageConverter 클래스는 XML 포맷을 지원합니다.

MessageConverter는 전략 패턴을 사용하여 구현되었습니다. MessageConverter 인터페이스는 알고리즘을 정의하는 추상 메서드 convert()를 제공합니다. 각 MessageConverter 구현체는 convert() 메서드를 구현하여 특정 메시지 포맷을 변환하는 알고리즘을 제공합니다.

• 스프링의 Logback

스프링의 Logback은 로그를 기록하는 프레임워크입니다. Logback은 다양한 로그 기록 방식을 지원합니다. 예를 들어, ConsoleAppender 클래스는 콘솔에 로그를 기록하고, FileAppender 클래스는 파일에 로그를 기록합니다.

Logback은 전략 패턴을 사용하여 구현되었습니다. Appender 인터페이스는 알고리즘을 정의하는 추상 메서드 append()를 제공합니다. 각 Appender 구현체는 append() 메서드를 구현하여 특정 로그 기록 방식을 구현합니다.

• 자바의 Comparator

자바의 Comparator 인터페이스는 객체를 비교하는 알고리즘을 제공합니다. Comparator 인터페이스를 구현한 클래스는 다양한 기준으로 객체를 비교할 수 있습니다. 예를 들어, NaturalOrderComparator 클래스는 객체의 문자열 표현을 기준으로 비교합니다.

Comparator은 전략 패턴을 사용하여 구현되었습니다. Comparator 인터페이스는 알고리즘을 정의하는 추상 메서드 compare()를 제공합니다. 각 Comparator 구현체는 compare() 메서드를 구현하여 특정 기준으로 객체를 비교하는 알고리즘을 제공합니다.

프록시 클래스는 원래 다운로더와 같은 인터페이스를 구현하고 이 다운로더에 모든 작업을 위임하나, 앱이 같은 비디오를 두 번 이상 요청하면 이미 다운로드한 파일을 추적한 후 캐시 된 결과를 반환한다.

실제사례

제일 유명한 스프링AOP!