Kubernetes CLI 

K8s의 기본 구성 요소 보기 >>  K8s 1) 쿠버네티스 기본 

Cluster

• 여기에서는 EKS(Elastic Kubernetes Service)을 이용하여 클러스터를 생성 (AKS, GKE 등 대체 가능)
• 사전 구성으로 IAM User 생성 및 AWS CLI에 Credential은 프로그래밍 방식 액세스 설정 필요

설치 및 사용법

eksctl 설치

# 이하 '$' 생략
curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv -v /tmp/eksctl /usr/local/bin

kubectl 설치

#AWS CLI 버전 확인
#kubectl 접근을 위해 AWS CLI 버전 1.21 이상 유효. 1.21 이하면 업데이트 핋요
aws --version 
pip install awscli --upgrade --user

#kubectl 설치
curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/kubectl
chmod +x ./kubectl
mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
kubectl version --client

참조용 Cluster 생성 Flag 매트릭

eksctl create cluster \
		--name eks-an2-cnl-dev \
		--version 1.21 \
		--vpc-private-subnets SUBNET-ID-1,SUBNET-ID-2
		--without-nodegroup
eksctl create nodegroup \
		--cluster eks-an2-cnl-dev \
		--name nodegroup-an2-cnl-dev \
		--node-type t3.micro \
		--nodes 2 \
		--nodes-min 1 \
		--nodes-max 3 \
		#node-private-networking 옵션은 private-subnet 통신 과정에서 유리하게 작용
		--node-private-networking \ 
		--managed=false
        
#그 외 Flag 매트릭
General flags:
  -n, --name string               EKS cluster name (generated if unspecified, e.g. "scrumptious-sculpture-1648975311")
      --tags stringToString       A list of KV pairs used to tag the AWS resources (e.g. "Owner=John Doe,Team=Some Team") (default [])
  -r, --region string             AWS region
      --zones strings             (auto-select if unspecified)
      --version string            Kubernetes version (valid options: 1.12, 1.13, 1.14, 1.15) (default "1.14")
  -f, --config-file string        load configuration from a file (or stdin if set to '-')
      --timeout duration          maximum waiting time for any long-running operation (default 25m0s)
      --install-vpc-controllers   Install VPC controller that's required for Windows workloads
      --managed                   Create EKS-managed nodegroup
      --fargate                   Create a Fargate profile scheduling pods in the default and kube-system namespaces onto Fargate

Initial nodegroup flags:
      --nodegroup-name string          name of the nodegroup (generated if unspecified, e.g. "ng-46273157")
      --without-nodegroup              if set, initial nodegroup will not be created
  -t, --node-type string               node instance type (default "m5.large")
  -N, --nodes int                      total number of nodes (for a static ASG) (default 2)
  -m, --nodes-min int                  minimum nodes in ASG (default 2)
  -M, --nodes-max int                  maximum nodes in ASG (default 2)
      --node-volume-size int           node volume size in GB
      --node-volume-type string        node volume type (valid options: gp2, io1, sc1, st1) (default "gp2")
      --max-pods-per-node int          maximum number of pods per node (set automatically if unspecified)
      --ssh-access                     control SSH access for nodes. Uses ~/.ssh/id_rsa.pub as default key path if enabled
      --ssh-public-key string          SSH public key to use for nodes (import from local path, or use existing EC2 key pair)
      --node-ami string                Advanced use cases only. If 'ssm' is supplied (default) then eksctl will use SSM Parameter; if 'auto' is supplied then eksctl will automatically set the AMI based on version/region/instance type; if static is supplied (deprecated), then static AMIs will be used; if any other value is supplied it will override the AMI to use for the nodes. Use with extreme care.
      --node-ami-family string         Advanced use cases only. If 'AmazonLinux2' is supplied (default), then eksctl will use the official AWS EKS AMIs (Amazon Linux 2); if 'Ubuntu1804' is supplied, then eksctl will use the official Canonical EKS AMIs (Ubuntu 18.04). (default "AmazonLinux2")
  -P, --node-private-networking        whether to make nodegroup networking private
      --node-security-groups strings   Attach additional security groups to nodes, so that it can be used to allow extra ingress/egress access from/to pods
      --node-labels stringToString     Extra labels to add when registering the nodes in the nodegroup, e.g. "partition=backend,nodeclass=hugememory" (default [])
      --node-zones strings             (inherited from the cluster if unspecified)

Cluster and nodegroup add-ons flags:
      --asg-access            enable IAM policy for cluster-autoscaler
      --external-dns-access   enable IAM policy for external-dns
      --full-ecr-access       enable full access to ECR
      --appmesh-access        enable full access to AppMesh
      --alb-ingress-access    enable full access for alb-ingress-controller

VPC networking flags:
      --vpc-cidr ipNet                 global CIDR to use for VPC (default 192.168.0.0/16)
      --vpc-private-subnets strings    re-use private subnets of an existing VPC
      --vpc-public-subnets strings     re-use public subnets of an existing VPC
      --vpc-from-kops-cluster string   re-use VPC from a given kops cluster

Cluster 생성

#yaml 기반
eksctl create cluster -f cluster.yaml

Cluster 삭제

#eksctl로 생성된 클러스터만 eksctl로 삭제 가능
#삭제전 Cluster에서 실행 중인 서비스 조회
kubectl get svc --all -namespaces

#EXTERNAL-IP(LB) 삭제
kubectl delete svc <서비스 이름>

#Cluster 삭제
eksctl delete cluster --name <클러스터 이름>

#수행 LOG 마지막 줄
#2024-05-17 14:43:37 [✔]  all cluster resources were deleted

Pod

• Pod는 대체적으로 container와 1:1 관계 (1:n 관계도 가능)
• container는 Pod로 캡슐화가 되어있다.
• k8s는 container에 직접 배포하지 않기에 캡슐화된 Pod를 배포한다.

Pod생성

kubectl run

kubectl run nginx --image nginx # nginx pod 기본 생성 명령어

#Namespace를 지정한 Pod 생성
kubectl run nginx --image nginx --namespace=<파드 이름>

#yaml 예시
apiVersion:
kind:
metadata:
	namespace:<파드 이름>
spec:

kubectl create

- yaml을 통해서 만드는 방식 (동일 Pod 존재할 경우 에러 발생)

kubectl ceate -f create-nginx.ymal

kubectl apply

- Pod가 없으면 new Pod를 생성, Pod가 존재하면 Update 한다.

kubectl apply -f apply-nginx.yaml

Pod 조회

kubectl get pods

#상세 조회
kubectl decribe pod nginx <오브젝트> <이름>

#nginx 파드의 상세 조회
kubectl describe pod nginx

#yaml 형식 조회
kubectl get pod nginx -o yaml

#조회 결과 output 저장
kubectl get pod nginx -o > output.yaml

#생성하지 않은 채로 output 저장
kubectl run nginx --image nginx --dry-run=client -o > yaml output.yaml

#output 조회
cat output.yaml

Pod 로그 조회

kubectl logs <파드 이름>

#tail -f 조회
kubectl logs -f <파드 이름>

Pod 삭제

kubectl delete <오브젝트> <이름>

#실행중인 nginx Pod 삭제
kubectl delete pod nginx

리소스 확인

Pod requests, limits 값 확인

kubectl get po -o yaml <파드 이름>

Deployment

• 뒤이어 나올 ReplicaSet의 상위개념이라고 볼 수 있다.
• ReplicaSet을 생성하는 Deployment를 정의할 수 있으며, 롤링 업데이트 등 세분화 조작할 수 있는 기능이다.

사용법

Deployment 생성

#create
kubectl create deployment <디플로이먼트 이름> --image=<이미지 이름>

#yaml
kubectl apply -f <YAML 파일>

Deployment 수정

kubectl edit deployment <디플로이먼트 이름>

#Deployment를 추가한 ReplicaSet Pod 설정
kubectl scale --replicas=N deployment <디플로이먼트 이름>

Deployment 업데이트(Roll Out)

- Pod가 실행 중인 상태에서 이미지 버전 변경 배포

- 이전 배포 정보는 스케일 다운, 새 배포는 ReplicaSet을 새로 생성하여 스케일 업

- 스케일 다운과 스케일 업은 부분적으로 동시에 발생

kubectl set image deployment/<디플로이먼트 이름> <컨테이너 이름>=<새 배포 태그>

#예시
kubectl set image deployment/sojuking-deployment nginx=nginx:1.23.4

Deployment Roll Out 조회

#상태 확인
kubectl rollout status deployment <디플로이먼트 이름>

#이력 확인
kubectl rollout history deployment <디플로이먼트 이름>

#리비전별 상세조회 Flag
# --revision=N

Deployment Roll Back

kubectl rollout undo deployment/<디플로이먼트 이름>

#특정 리비전 번호 N으로 롤백
kubectl rollout undo deployment/<디플로이먼트 이름> --to-revision=N

Deployment Scaling

#N개의 복제 파드 조정
kubectl scale deployment/<디플로이먼트 이름> --replicas=N

Deployment 조회

kubectl get deployment

#namespace
kubectl get deployment -n <네임스페이스>

Deployment 삭제

kubectl delete deployment <디플로이먼트 이름>

Set

ReplicaSet

• Pod 개수를 유지하게 하는 가용성을 보증하는 장치
• 예를 들어 Pod의 개수를 5개로 설정하였으면, Node가 다운되어 Pod가 사라져도 자동생성으로 Pod 수를 5개로 유지

사용법

ReplicaSet 생성

#create
kubectl create -f nginx-rs.yaml

#apply
kubectl apply -f nginx-rs.yaml

ReplicaSet 확인

#Cluster에 실행중인 ReplicaSet 조회
kubectl get rs

#ReplicaSet 상세 조회
kubectl describd rs

#yaml 형식 조회
kubectl get rs <레플리카셋 이름> -o=yaml

#Pod의 ReplicaSet 조회
kubectl get pod <파드> -o yaml

#실행 예시
kubectl get pod new-replica-set-a10jr -o yaml

#yaml 예시
apiVersion: app/v1
kind: ReplicaSet
metadata:
    name:
spec:
    template:
        metadata:
            name: <파드 이름>
            labels:
                app:
                type:
        spec:
            containers:
            - name: nginx-controller
              image: nginx
    seletor:
        matchLabels:
            type: <파드 라벨>

ReplicaSet Scaling

#N개의 복제 파드 조정
kubectl scale rs <레플리카셋 이름> --replicas=N

#예시
kubectl scale rs sojuking --replicas=5

ReplicaSet 편집

kubectl edit rs <레플리카셋 이름>

ReplacaSet 리소스 삭제

#리소스만 삭제
kubectl delete rs --cascade=orphan <레플리카셋 이름>

#Pod까지 삭제
kubectl delete rs <레플리카셋 이름>

DaemonSet

• Cluster 내 새로운 Node가 하나 생길 때마다, Pod 복제본이 자동으로 Node에 생성 (자동 배포 기능)
• Cluster 내 모든 Node에는 항상 1개 이상의 Pod 복사본이 존재하도록 보장

ReplacaSet과 마찬가지로 DaemonSet도 kind만 제외하고 정의 내용이 같다.

#yaml 예시
apiVersion: app/v1
kind: DaemonSet
metadata:
    name:
spec:
    template:
        metadata:
            name: <파드 이름>
            labels:
                app:
                type:
        spec:
            containers:
            - name: nginx-controller
              image: nginx
    seletor:
        matchLabels:
            type: <파드 라벨>

StatefulSet

• StatefulSet은 각 파드의 독자성을 유지
• Pod 집합의 Deployment와 Scailing을 관리하며, Pod의 순서 및 고유성을 보장
• 상태가 없는 앱/웹은 Deployment로 배포, 상태가 있는 DB 같은 경우는 StatefulSet으로 배포한다.

 StatefulSet은 Cluster IP가 없는 헤드리스 서비스를 사용해야 한다.

vi soju-sts.yaml

#yaml 예시
apiVersion: app/v1
kind: StatefulSet
metadata:
    name: soju-sts
spec:
  selector:
    matchLabels:
      app: soju-sts
  serviceName: soju-svc-headless #추가된 헤드리스 서비스 이름
  replicas: 2
  template:
    metadata:
      labels:
        app: soju-sts
    spec:
      containers:
      - name: myapp
        image: ghcr.io/fn1vkd2/go-myweb:lupine
        ports:
        - containerPort: 8080

Cluster IP가 없는 Service

vi soju-svc-headless.yaml #StatefulSet에 정의한 헤드리스 서비스의 본체

apiVersion: v1
kind: Service
metadata:
  name: soju-svc-headless
  labels:
    app: soju-svc-headless
spec:
  ports:
  - name: http
    port: 80
  clusterIP: None #헤드리스 서비스 정의( Cluster IP: None)
  selector:
    app: soju-sts #soju-sts.yaml의 label 조회

StatefulSet 생성

kubectl -f soju-sts.yaml -f soju-svc-headless.yaml

StatefulSet 조회

kubectl get sts, svc, ep #sts: statefulSet, svc: service, ep: endpoint

#Controller 뒤의 번호 생성 조회 (고유성)
kubectl get pod -o wide

#network-multitool 이미지 실행
kubectl run nettool --image ghcr.io/fn1vkd2/network-multitool -it --rm

#nettool < Pod 이름 생성
#--image 이미지 지정
#-it Pod를 인터랙티브 모드 실행, 터미널 할당 및 실시간 상호작용 상태
#--rm Pod 종료시 자동 Pod 삭제

#호스트 질의 - 서비스 이름 지정
host soju-svc headless

# StatefulSet + headless >> Pod의 이름으로 통신하여 Pod의 IP 변환
host soju-sts-0.soju-svc-headless
host soju-sts-1.soju-svc-headless

Job

Job

• 프로세스가 종료되면 Container가 다시는 시작되지 않는 배치라 보면 된다.
• 노드에 장애가 발생하면 ReplicaSet의 파드와 같은 방식으로 다른 노드로 재스케줄 기능이 있다.
• 프로세스 오류일 경우 Container를 재실행하도록 할 수 있다.

YAML 리소스 구성

apiVersion: batch/v1 # API 그룹은 batch 버전 v1
kind: Job
metadata:
  name: soju-job
spec:    
  template:
    spec:
      containers:
      - name: soju-job
        image: 2.mi.g
        command: ["Job 끝내고 쐐애주나 마시자!"]
      restartPolicy: Never #Pod의 재시작 정책 설정
      completions: 2 #실행 종료되어야 하는 파드 수 설정 (기본값 1)
      parallelism: 2 #잡 병렬성 관리(기본값 1)
  backoffLimit: 2 #재시도 횟수 설정
  activeDeadlineSeconds: 100 #Pod의 실행시간 설정(넘으면 Pod 종료 시도 및 Job은 Fail)

Job 삭제

#Job을 삭제하면 관련 Pod도 같이 삭제가 된다.
kubectl delete job <잡 이름>

Cronjob

• 반복 작업을 실행하는 데 사용하는 리소스 중 하나, 지정된 시간 또는 간격으로 작업 생성한다.
• Linux의 crontab 기능을 떠올리면 된다.

YAML  리소스 구성

apiVersion: batch/v1 # API 그룹은 batch
kind: CronJob
metadata:
  name: soju-cronjob
spec:
  schedule: "*/1 * * * *"   #매 1분마다 실행
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: soju-cronjob
            image: busybox
            command: ["퇴근하고 쐐애주나 마시자!"]
          restartPolicy: OnFailure
  concurrencyPolicy: Forbid

CronJob 조회

kubectl get cronjobs

CronJob 삭제

kube delete cronjobs <크론잡 이름>

Resource 

• 다수의 컨테이너가 Pod에 있으면 Request와 Limit은 각각의 컨테이너에 개별적으로 할당
• Resource 중 CPU는 Resource Limit 보다 초과로 사용 불가, Memory는 사용 가능하나 Pod 다운 및 OOM 발생

Resource 감시

kubectl top 설치

-top을 사용하기 위하여 명령어로 설치

git clone https://github.com/kodekloudhub/kubernetes-metrics-server.git
cd kubernetes-metrics-server/
kubectl create -f

CPU, Memory 사용율 확인

#node 확인
kubectl top node

#pod 확인
kubectl top pod

Resource 제한

Resource Limit 

-Pod 내 리소스 사용량을 제한

apiVersion: v1
kind: Pod
metadata:
    name:
spec:
    containers:
    - name: sojuking
      image: nginx
      ports:
        - containerPort: 8080
      resources:
        requests: #요구되는 리소스 양
          memory: "2Gi"
          cpu: 2
        limit: #리소스 사용 제한
          memory: "4Gi"
          cpu: 4

Resource Quotas

- K8s 내 배포된 전체 애플리케이션이 소모하는 전체 리소스의 양을 제한

- namespace 레벨에서 적용

apiVersion: v1
kind: ResourceQuota
metadata:
  name: sojuking-quota
spec:
  hard:
    requests.cpu: 2
    requests.memory: 2Gi
    limits.cpu: 10
    limits.memory: 10Gi

krew

• kubectl을 보다 편리하게 사용할 수 있게 해주는 Plugin 관리 도구이다.
• kubectl v1.12 이상의 버전에서 사용 가능하다.
• git 설치가 되어 있어야 한다.

설치법

설치 명령어

(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)

Path 추가

export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

설치 확인

kubectl krew

사용법

Plugin 설치

kubectl krew install NAME <플러그인 이름>

#예시
kubectl krew install sojuking

Plugim 사용

kubectl <플러그인 이름>

Plugin 업데이트

kubectl krew upgrade <플러그인 이름>

#모든 플러그인 업그레이드
kubectl krew upgrade

Plugin 검색

kubectl krew search KEYWORD

#모든 플러그인 목록 확인 (키워드 제거)
kubectl krew search

#설치 플러그인 목록 확인
kubectl krew list

Plugin 삭제

kubectl krew uninstall <플러그인 이름>

Kubernetes

※ Docker 등 Container에 대한 기본 설명은 제외하였습니다.

K8s의 구조

• Master에 API 서버와 상태 저장소를 두고, 각 Node(서버)의 에이전트(Kublet)와 통신하는 구조

K8s의 구조 : Master

• K8s 클러스터 관리하는 역할
• 노드의 상황을 파악
• 컨테이너를 어떤 노드에서 가동할지 선택
• etcd 분산 저장소를 사용하여 클러스터의 정보를 저장

Master

 API Server

• API 서버는 모든 요청을 처리하는 마스터의 핵심
• 모든 컴포넌트들은 API 서버를 통해서 커뮤니케이션함
• 인증 및 인가 기능 보유

Scheduler

• 컨테이너를 어떤 노드에서 가동할지 결정하는 컴포넌트
• 노드들의 정보를 파악하고 컨테이너를 가동할 적합한 노드 선택

Controller Manager

• K8s 클러스터의 상태를 감시
• 시스템의 상태 감시 및 유지
• 요청된 상태와 현재 시스템의 상태의 차이 감시

etcd 

• 분산 key-value 저장소
• 클러스터의 모든 설정, 상태 데이터 저장
• 스케줄러와 컨트롤러 매니저 등이 API 서버를 통해 etcd의 데이터 조회 및 갱신
• 마스터에서 분리하여 독자적으로 분리 가능

K8s의 구조 : Node

• 컨테이너가 가동되는 서버
• 다수의 노드로 클러스터를 구성
• 클라우드의 경우 가상머신이 노드가 됨 ex.) ec2...

Node

Kubelet

• 실제로 컨테이너를 생성하는 주체
• 마스터로부터 생성 요청을 받으면 컨테이너를 생성
• 컨테이너의 상태를 감시하는 역할 수행
• 컨테이너의 상태를 API 서버로 전송

Kube proxy

• 각 노드에서 실행되는 네트워크 프록시
• 노드의 네트워크 규칙을 유지 및 관리
• 내부 네트워크 세션, 클러스터 외부에서 내부로 네트워크 통신

Pod

• 한 개 또는 여러 개의 컨테이너의 묶음

K8s Object

• Container, Network 등 분산에 필요한 필요 요소의 추상화

Object

Replica Set

• Pod를 한 개 이상 복제하여 관리
• Pod를 생성하고 개수 유지를 위해서 ReplicaSet을 사용해야 함

Daemon Set

• 클러스터 전체에 Pod를 띄울 때 사용하는 Controller
• 항상 모든 Node에 특정 Pod가 실행됨
• 새로운 Node가 추가되면 자동으로 Pod 실행됨
• 로그 수집기, 모니터링 에이전트 등 실행하는 용도

Stateful Set

• K8s 대부분의 Object는 Stateless
• StatefulSet은 상태를 유지하는 Pod를 위한 Object
• Volume을 사용해서 데이터 저장, Pod 재기동 시에도 유지 가능
• DB 등을 컨테이너화 할 때 사용 가능

Pod

• K8s에서 배포할 수 있는 가장 작은 단위
• 한 개 이상의 컨테이너와 스토리지, 네트워크 속성을 가짐
• Pod에 속한 컨테이너는 스토리지와 네트워크를 공유하고 서로 localhost로 접근 가능

Service

• 네트워크와 관련된 Object
• Pod 간 연결 및 Pod와 외부 네트워크를 연결
• 여러 개의 Pod에 대한 내부 로드밸런서
• 내부 DNS에 서비스 등록하여 서비스 디스커버리 역할도 함
• Pod에 대한 L4 로드밸런싱 수행
• Cluster IP, Node Port, Load Balancer 등 옵션 지정 가능

Deployment

• K8s에서 실제 배포를 진행하는 기본 단위
• 배포 Revision 관리 및 Roll Back 등 다양한 옵션 제공

Ingress

• 외부 트래픽을 받는 Object
• Http/ Https 등 L7 레벨로 라우팅 규칙, 로드벨런싱 규칙 등도 포함
• Service도 외부로 노출 가능하지만 L4 레벨만 가능

Others

• ConfifMap, Secret : 설정정보 저장 등 Pod 참조
• Job, CronJab : 배치 관리
• Label, Selector : 자원 관리 위해 Labeling

K8s Manifest File

• 선언적 설정을 위한 YAML/JSON 형태의 파일

Manifest File

YAML or JSON

YAML

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.20.1
    ports:
    - containerPort: 80

Json

{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "nginx"
  },
  "spec": {
    "containers": [
      {
        "name": "nginx",
        "image": "nginx:1.20.1",
        "ports": [
          {
            "containerPort": "80"
          }
        ]
      }
    ]
  }
}

apiVersion

• K8s API 버전 정보 기술

kind

• Object의 종류 기술 (Pod, Service...)

metadata.name

• Object 이름을 기술

spec

• Object 상세 정보 기술
• 포트 등 환경 정보 기술

K8s 사용

K8s 사용

유/무료 설치형 배포판

• Red Hat OpenShift
• Pivotal PKS
• Rancher
• Kubeadm

Cloud Managed Kubernetes

• EKS
• GKE
• AKS
• NCloud K8s Service

Catch - Multi thread (feat. ORA-00060)  

서론

위의 사진을 잘 관람한다면 현재의 무한경쟁시대에 돌입하듯 동그란 자원을 서로 못 가져가서 안달이다.

이렇게 서로 잡고 안 놔주니 자원이 교착상태가 일어나게 된다.

그렇담, 치열하게 전투를 할 수밖에 없어진 명백한 사유에 대하여 알아보자.

Reason

위의 그림은 하드웨어 아키텍처를 단순화한 다이어그램이다.

CPU는 두 개의 코어를 나타낸 것이고, 각 CPU는 주어진 시간 내로 하나의 스레드를 실행할 수 있다.

즉, 스레드의 경우 CPU당 스레드가 애플리케이션 내에서 동시에 실행될 수 있음을 의미한다.

그리고 변수를 사용할 때 Main Memory에 도달하기 전 CPU Cache에 우선적으로 들락거려야 한다.

즉, 캐시에 존재하는 데이터를 읽는다는 Sound인데, 아래와 같이 개체와 변수가 컴퓨터의 다양한 메모리 영역에 저장되어 사용하는 경우, 위에서 보았던 피 튀기는 자원무한경쟁의 시대가 개막을 하게 되는 것이다.

Solution

synchronized

하나의 스레드만 이용이 가능한 '임계 영역'을 코드단에서 synchronized를 이용하여 설정을 할 수 있다.

하나의 스레드가 해당 임계 영역에 당도하면 그 스레드는 'Lock'을 수여받는데, 무언가를 수행 중인 스레드가 Lock을 반납해야만 다른 스레드가 임계 영역을 사용할 수 있다. 이를 동기화라고 한다.

메서드 단위, 코드 블록 단위 등 원하는 단위로 나누어 사용이 가능하다.

사용법 외에 스레드 처리에 대한 예시는 굳~이 하지 않겠다.

아래의 예시와 같이 사용법은 간단하다.

    // 1. 메소드 전체를 임계영역화
    public synchronized void batchDosa() {

    }

    // 2. 특정영역만 임계영역화
    public void moDosa() {
        synchronized (){ 
        
        }
    }

Key Point: 임계 영역, Lock

volatile

앞서 데이터 교환이 일어나려면 CPU 메모리의 캐싱된 값을 가져온다고 하였다. 

반면 volatile는 synchronized 와는 다르게 캐싱된 값이 아닌,

항상 최신의 값을 가지도록 메인 메모리의 값을 참조하고 'Lock free'인 관계로 성능면에서 유리한 장점이 있다.

그러나 단지 최신의 값을 가질 뿐이지 모든 동기화를 해결할 수는 없다.

단, 단순한 스레드 간의 통신이나 원자적 연산은 동기화가 잘 될 것이다.

아래의 예시와 같이 사용법은 간단하다.

 // Before
 boolean catchThread = false;
 
 // After
 volatile boolean catchThread = false;

Atomic

이름만 들어도 원자성은 기필코 확보할 것만 같은 이름이다.

앞서 두 개의 경우는 예약어지만, Atomic은 java.util.concurrent.atomic 패키지에 정의된 클래스이다.

synchronized와 유사하지만 Lock이 아닌, 저수준 CPU 연산 기술인 Compare-And-Swap(CAS) 알고리즘을 사용한다.

이는 메인 메모리에 저장된 값과 CPU 캐시에 저장된 값을 비교하고, 두 값이 같은 경우에만 데이터를 수정한다. 

synchronized의 장점인 가시성과 원자성을 챙기면서도 Lock도 없어 성능까지 챙길 수 있는 아주 영특한 녀석이다.

아래의 예시와 같이 사용법은 간단하다.

 // Before
 private boolean soJuNaMaSyo = false;
 
 // After
 private AtomicBoolean soJuNaMaSyo = new AtomicBoolean();

아래의 URL에 Atomic 패키지의 다양한 사용법 및 예제가 있으니, 더 많은 사용법을 원한다면 URL을 참조하면 될 것이다.

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html

결론: 배치도사 무도사

필자는 이렇게 생각한다. 

배치 수행 시 Read시간이 경과되는 Where절이 존재하는 배치는 싱글 스레드로 돌리는 것이 보다 안전하다.

본 바와 같이 동기화를 사용하여 자원동행을 하는 것은 기본. DML별로 디렉터리 or URL로 쪼개서 관리하는 법도 있다.

실시간 배치, 특히 DML에서 C, D가 동시에 존재하는 경우 경합이 될 소지가 높으니 이의 경우에는 D를 제거하고, DB 파티션을 데이터에 맞게 분할을 하여 삭제를 도모하는 것도 있으니 여러 방면으로 골똘히 아이디어를 창출해 보면 좋을 것이다.

[AWS] CloudWatch를 사용한 MSK 모니터링 참조 메트릭

DEFAULT 수준 모니터링

다음 표에 설명된 지표는 DEFAULT 모니터링 수준에서 사용할 수 있습니다. 

이름표시되는 경우 Dimensions설명

PER_BROKER 수준 모니터링

모니터링 수준을 PER_BROKER로 설정하면 모든 DEFAULT 수준 지표 외에 다음 표에 설명된 지표가 표시됩니다. 다음 표의 지표에 해당하는 비용을 지불하지만 DEFAULT 수준 지표는 계속 무료로 제공됩니다. 이 표에 있는 지표의 차원은 클러스터 이름, 브로커 ID입니다.

PER_BROKER 모니터링 수준부터 사용할 수 있는 추가 지표이름표시되는 경우설명

PER_TOPIC_PER_BROKER 수준 모니터링

모니터링 수준을 PER_TOPIC_PER_BROKER로 설정하면 모든 PER_BROKER 및 기본 수준 지표 외에 다음 표에 설명된 지표가 표시됩니다. DEFAULT 수준 지표만 무료입니다. 이 표에 있는 지표의 차원은 클러스터 이름, 브로커 ID, 주제입니다.

Apache Kafka 2.4.1 이상 버전을 사용하는 Amazon MSK 클러스터의 경우 다음 표의 지표는 해당 값이 처음으로 0이 아닌 값이 된 후에만 나타납니다. 예를 들어, BytesInPerSec를 보려면 하나 이상의 생산자가 먼저 클러스터로 데이터를 전송해야 합니다.

PER_TOPIC_PER_BROKER 모니터링 수준부터 사용할 수 있는 추가 지표이름표시되는 경우설명

PER_TOPIC_PER_PARTITION 수준 모니터링

모니터링 수준을 PER_TOPIC_PER_PARTITION로 설정하면 모든 PER_TOPIC_PER_BROKER, PER_BROKER, 기본 수준 지표 외에 다음 표에 설명된 지표가 표시됩니다. DEFAULT 수준 지표만 무료입니다. 이 표의 지표에는 소비자 그룹, 주제, 파티션 등의 차원이 있습니다.

PER_TOPIC_PER_PARTITION 모니터링 수준부터 사용할 수 있는 추가 지표이름표시되는 경우설명

지원되는 버전

Instancea가 수집하는 모든 Kafka 지표는 이용자 그룹 시차 및 소비자/프로듀서 바이트 비율/조절 지표와 별도로 Apache Kafka, Cloudera Kafka및 Confluent Kafka의 모든 버전에 사용할 수 있습니다. 오픈 소스 Apache Kafka에 빌드된 IBM® Event Streams 는 IBM Event Streams 11.0.4 (IBM Event Streams Operator 3.0.5) 이상 버전에서 지원됩니다.

이용자 그룹 지연 지표는 다음 버전에서 사용 가능합니다.

• 0.11.x.x 에서 3.x.x 까지의 Apache Kafka 버전
• 3.x.x 에서 4.1.x 로의 Cloudera Kafka 버전
• 3.3.x 에서 7.x.x까지의 Confluent Kafka 버전.
• 11.0.4 (IBM Event Streams Operator 3.0.5) 이상 버전의 IBM Event Streams 버전

소비자/생성자 바이트 비율/조절 메트릭은 Java Kafka 클라이언트에서만 사용 가능하며 다음과 같습니다.

• 1.1.x 에서 3.x.x 로의 Apache Kafka 버전
• 4.0.x 에서 4.1.x 까지의 Cloudera Kafka 버전
• 4.1.x 에서 7.x.x까지의 Confluent Kafka 버전.
• 11.0.4 (IBM Event Streams Operator v3.0.5) 이상 버전의 IBM Event Streams 버전

 구성

Instancea 에이전트는 실행 중인 Kafka 에이전트를 자동으로 발견하므로 구성이 필요하지 않습니다.

Instana는 주제 이름별로 정렬된 첫 번째 400 주제를 수집합니다.

주제를 필터링하기 위한 요구사항이 있는 경우 에이전트 구성 파일 <agent_install_dir>/etc/instana/configuration.yaml에서 이를 구성할 수 있습니다.

com.instana.plugin.kafka:
  topicsRegex: '<OPTIONAL_REGEX_HERE>'
  brokerPropertiesFilePath: '/path/to/server.properties'
  collectLagData: '' # true or false. The default value is true

• topicsRegex: 이름별로 최대 400개의 주제를 선택하는 선택적 정규식입니다. 값이 비어 있거나 존재하지 않는 경우 Instana는 이름별로 정렬된 처음 400개의 주제를 수집합니다.
• brokerPropertiesFilePath: 에이전트가 브로커 네트워크 및 보안 프로토콜 설정에 대한 정보를 가져오는 데 사용하는 브로커 server.properties 파일의 경로입니다.
• collectLagData: 지연 데이터 콜렉션을 명시적으로 사용/사용 안함으로 설정하는 데 사용되는 플래그입니다 (기본적으로 사용으로 설정됨).

브로커 특성에 대한 경로가 지정되지 않은 경우 에이전트는 다음 위치에서 server.properties 를 찾으려고 시도합니다.

• Kafka 브로커 프로세스 인수
• KAFKA_SERVER_PROPERTIES 환경 변수
• 사전 정의된 경로 사용: Confluent Kafka의 경우 /path_to_kafka_home/config/server.properties 또는 /path_to_kafka_home/etc/kafka/server.properties .

앞에서 언급한 방법으로 server.properties 에 대한 경로를 찾을 수 없는 경우 에이전트는 /opt/kafka/config/server.properties 를 기본 경로로 사용합니다.

 SSL TLS 지원

Kafka 브로커 인스턴스에 SSL 클라이언트 연결이 필요한 경우 <agent_install_dir>/etc/instana/configuration.yaml 를 통해 Instana 에이전트를 구성하여 이용자 지연 메트릭을 수집할 수 있도록 해야 합니다.

com.instana.plugin.kafka:
  ...
  sslTrustStore: '/path/to/truststore.jks'
  sslTrustStorePassword: 'kafkaTsPassword'
  sslKeyStore: '/path/to/sslKeyStoreFile.jks'
  sslKeyStorePassword: 'kafkaKsPassword'

키는 Java키 저장소 형식 (JKS) 이어야 합니다. keytool 을 사용하여 이를 작성할 수 있습니다.

참고: 이를 통해 Instana 에이전트가 SSL을 통해 Kafka 브로커에 연결하고 이용자 그룹 지연 지표를 수집할 수 있습니다.

 Kafka 노드-지표 콜렉션

 구성 데이터

• 버전
• Zookeeper Connect
• 프로세스 ID
• 노드 ID
• 토픽/파티션

 성능 지표

 브로커 트래픽

 브로커 메시지 수신

 요청 생성

 이용자 요청 페치

 팔로워 요청 페치

 평균 유휴 시간

 브로커 실패

 브로커 상태 지표

 파티션

 로그 플러시

 주제

 Kafka 클러스터-지표 콜렉션

• 클러스터 이름
• Zookeeper
• 노드 (이름, 버전)

토픽/파티션

 성능 지표

 평균 요청 대기 시간 대 처리량

 모든 브로커 트래픽

 모든 브로커 실패

 모든 브로커 상태 지표

 평균 유휴 시간 백분율

 로그 플러시

 클러스터 노드

 클러스터 토픽

 이용자 그룹 지연

 이용자

 생산자

Kafka 작업자-메트릭 콜렉션

 구성 데이터

• Version
• 이름
• 브로커 수

 성능 지표

• 커넥터 개수
• 커넥터 시작 실패
• 태스크 시작 실패

 리밸런싱

 Kafka 커넥터-메트릭 콜렉션

• 커넥터 이름
• 커넥터 클래스
• 커넥터 유형
• 커넥터 버전

 커넥터 태스크

 태스크

 태스크 링크 태스크

 Kafka 클러스터 연결 클러스터-메트릭 콜렉션

 구성 데이터

• Version

 작업자

 커넥터

Nested Loop Join

1. 기본 메커니즘

아래는 중첩 루프문(Nested Loop)의 수행 구조이다.

for(i=0; i<100; i++){
    for(j=0; j<100; j++){
    }
}

뒤에서 설명할 Sort Merge Join과 Hash Join도 각각 소트 영역(Sort Area)과 해시 영역(Hash Area)에 가공해 둔 데이터를 이용한다는 점만 다를 뿐 기본적인 조인 프로세싱은 다르지 않다.

단, 기억할 것은, 각 단계를 완료하고 나서 다음 단계로 넘어가는 게 아니라 한 레코드씩 순차적으로 진행한다는 사실이다.

2. NL Join 수행 과정 분석

프로그래밍을 할 줄 아는 분들이면 매커니즘은 자연스럽게 넘어갈 것이라 사료되는데,

아래의 조인문에서 조건절 비교 순서를 분석해 보자.

/*Data ON-AIR 참조*/

select /*+ ordered use_nl(e) */ e.empno, e.ename, d.dname, e.job, e.sal 
from dept d, emp e 
where e.deptno = d.deptno …………… 
① and d.loc = 'SEOUL' …………… 
② and d.gb = '2' …………… 
③ and e.sal >= 1500 …………… 
④ order by sal desc;

인덱스 상황은 다음과 같다.

* pk_dept : dept.deptno 
* dept_loc_idx : dept.loc 
* pk_emp : emp.empno 
* emp_deptno_idx : emp.deptno 
* emp_sal_idx : emp.sal

조건절 비교 순서, 그리고 위 5개 인덱스 중 어떤 것이 사용될지도 함께 고민해 보면 재밌을 것이다.

Execution Plan --------------------------------------------------- 0 
SELECT STATEMENT 1 0 SORT ORDER BY 2 1 NESTED LOOPS 3 2 
TABLE ACCESS BY INDEX ROWID DEPT 4 3 INDEX RANGE SCAN DEPT_LOC_IDX 5 2 
TABLE ACCESS BY INDEX ROWID EMP 6 5 INDEX RANGE SCAN EMP_DEPTNO_IDX

사용되는 인덱스 : dept_loc_idx, emp_deptno_idx

조건절 비교순서 : ② → ③ → ① → ④ 

실행계획을 해석할 때, 형제(Sibling) 노드 간에는 위에서 아래로 읽는다.

부모-자식(Parent-Child) 노드 간에는 안쪽에서 바깥쪽으로, 즉 자식 노드부터 읽는다.

위 실행계획의 실행 순서를 나열하면 다음과 같다.

1. dept_loc_idx 인덱스 범위 스캔(ID = 4)

2. 인덱스 rowid로 dept 테이블 액세스(ID = 3)

3. emp_deptno_idx 인덱스 범위 스캔(ID = 6)

4. 인덱스 rowid로 emp 테이블 액세스(ID = 5)

5. sal 기준 내림차순(desc) 정렬(ID = 1)

아래는 도식화한 NL Join 실행계획이다.

형제 노드 간에는 좌에서 우로 읽고,

부모-자식 노드 간에는 아래에서 위쪽으로, 즉 자식 노드부터 읽는다.

3. NL Join의 특징

- Random 액세스 위주의 조인 방식

- 조인을 한 레코드씩 순차적으로 진행

즉 NL Join은 소량의 데이터나 부분 범위 처리가 가능한 온라인 트랜잭션 환경에 적합한 조인 방식이라고 할 수 있다.

Sort Merge Join

NL Join은 인덱스에 조인 컬럼을 선두로 가지고 있는지가 매우 중요하다.

선두에 조건이 없으면 옵티마이저는 Sort Merge Join이나, Hash Join을 고려하게 된다.

이 중 Sort Merge Join의 Sort는 양쪽 집합을 조인 컬럼 기준으로 정렬함이고, Merge는 정렬된 양쪽 집합을 Merge 함을 의미한다.

1. 기본 메커니즘

아래는 dept 테이블을 기준으로 emp 테이블을 조인할 경우 Sort Merge Join을 이행하라는 힌트의 예제이다.

/*Data ON-AIR 참조*/

select /*+ ordered use_merge(e) */ d.deptno, d.dname, e.empno, e.ename 
from dept d, emp e 
where d.deptno = e.deptno 
Execution Plan ------------------------------------------------------------- 0 
SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=654 Bytes=35K) 1 0 
MERGE JOIN (Cost=11 Card=654 Bytes=35K) 2 1 
SORT (JOIN) (Cost=6 Card=654 Bytes=14K) 3 2 
TABLE ACCESS (FULL) OF 'DEPT' (Cost=2 Card=654 Bytes=14K) 4 1 
SORT (JOIN) (Cost=5 Card=327 Bytes=11K) 5 4 
TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=327 Bytes=11K)

아래는 도식화된 Sort Merge 수행 과정이다.

실제 조인 수행 과정이 NL Join과 크게 다르지 않다. outer 집합과 inner 집합을 미리 정렬해 둔다는 점만 다르다. 다시 말하지만, 양쪽 집합을 먼저 정렬해 두었기 때문에 위와 같은 처리 로직이 가능하다.

2. Sort Merge Join의 특징

- 조인 하기 전에 양쪽 집합을 정렬한다.

- 부분적으로 부분 범위처리가 가능하다.

- 테이블별 검색 조건에 의해 전체 일량이 좌우된다.

- 스캔 위주의 조인 방식이다.

  - >Inner 테이블 반복 엑세스를 하지 않아서 Random 엑세스가 발생되지 않으나, 전혀없지는 않아서 랜덤 엑세스가 많으면 안 쓰는게 낫다.

Hash Join

1. 기본 메커니즘

Hash Join은 NL Join이나 Sort Merge Join이 효과적이지 못한 상황을 해결하고자 나온 조인 방식이다.

Hash Join 힌트를 사용해 보자.

/*Data ON-AIR 참조*/

select /*+ ordered use_hash(e) */ d.deptno, d.dname, e.empno, e.ename 
from dept d, emp e 
where d.deptno = e.deptno 
Execution Plan ------------------------------------------------------------- 0 
SELECT STATEMENT Optimizer=CHOOSE (Cost=5 Card=654 Bytes=35K) 1 0 
HASH JOIN (Cost=5 Card=654 Bytes=35K) 2 1 
TABLE ACCESS (FULL) OF 'DEPT' (Cost=2 Card=654 Bytes=14K) 3 1 
TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=327 Bytes=11K)

Hash Join은 둘 중 작은 집합(Build Input)을 읽어 해시 영역(Hash Area)에 해시 테이블(= 해시 맵)을 생성하고,

반대쪽 큰 집합(Probe Input)을 읽어 해시 테이블을 탐색하면서 조인하는 방식이다.

각 단계별로 살펴보자.

• 1단계 : 두 집합 중 작다고 판단되는 집합을 읽어 해시 함수를 이용하여 해시 버킷으로 구성된 배열인 해시 테이블을 만든다. 해시 함수에서 리턴받은 해시 값이 같은 데이터를 같은 해시 버킷에 체인(연결 리스트)으로 연결한다.
• 2단계 : 해시 테이블 생성을 위해 선택되지 않은 나머지 데이터 집합(Probe Input)을 스캔한다.
• 3단계 : Probe Input에서 읽은 데이터로 해시 테이블을 탐색할 때도 해시 함수를 사용한다. 즉, 해시 함수에서 리턴받은 버킷 주소로 찾아가 해시 체인을 스캔하면서 데이터를 찾는다.

NL Join처럼 조인 과정에서 발생하는 Random 액세스 부하가 없고 Sort Merge Join처럼 조인 전에 미리 양쪽 집합을 정렬하는 부담도 없다. 다만, 해시 테이블을 생성하는 비용이 수반된다. 따라서 Build Input이 작을 때 효과적이다. Build Input이 대용량 테이블이면 디스크에 W/R 하는 과정을 거치기 때문에 성능이 저하된다. Build Input으로 선택된 테이블이 작은 것도 중요하지만  해시 키값으로 사용되는 컬럼에 중복값이 없을 때 효과적이다.

2. Build Input이 가용 메모리 공간을 초과할 때 처리 방식 

 In-Memory Hash Join이 불가능할 때 DBMS는 ‘Grace Hash Join’이라고 알려진 조인 알고리즘을 사용하는데,

두 단계로 나누어 진행된다.

1) 파티션 단계

조인되는 양쪽 집합 모두 조인 칼럼에 해시 함수를 적용하고, 반환된 해시 값에 따라 동적으로 파티셔닝을 실시한다. 독립적으로 처리할 수 있는 여러 개의 작은 서브 집합으로 분할함으로써 파티션 짝(pair)을 생성하는 단계다. 파티션 단계에서 양쪽 집합을 모두 읽어 디스크 상의 Temp 공간에 일단 저장해야 하므로 In-Memory Hash Join보다 성능이 크게 떨어지게 된다.

2) 조인 단계

파티션 단계가 완료되면 각 파티션 짝(pair)에 대해 하나씩 조인을 수행한다. 이때, 각각에 대한 Build Input과 Probe Input은 독립적으로 결정된다. 즉, 파티션하기 전 어느 쪽이 작은 테이블이었는지에 상관없이 각 파티션 짝(pair)별로 작은 쪽 파티션을 Build Input으로 선택해 해시 테이블을 생성한다. 해시 테이블이 생성되고 나면 반대 쪽 파티션 로우를 하나씩 읽으면서 해시 테이블을 탐색하며, 모든 파티션 짝에 대한 처리가 완료될 때까지 이런 과정을 반복한다. Grace Hash Join은 한마디로, 분할 정복(Divide & Conquer) 방식이라고 말할 수 있다. 실제로는 DBMS 벤더마다 조금씩 변형된 형태의 하이브리드(Hybrid) 방식을 사용하지만 두 개의 큰 테이블을 Hash Join하는 기본 알고리즘은 Grace Hash Join에 바탕을 두고 있다.

3. Build Input이 해시 키 값에 중복이 많을 때 발생하는 비효율

앞서 설명하였듯이 해시 알고리즘의 성능은 해시 충돌을 얼마나 최소화할 수 있느냐에 달렸으며, 이를 방지하려면 그만큼 많은 해시 버킷을 할당해야만 한다. DBMS는 가능하면 충분히 많은 개수의 버킷을 할당함으로써 버킷 하나당 하나의 키 값만 갖게 하려고 노력한다. 그런데 해시 버킷을 아무리 많이 할당하더라도 해시 테이블에 저장할 키 컬럼에 중복 값이 많다면 하나의 버킷에 많은 엔트리가 달릴 수 밖에 없다. 그러면 해시 버킷을 아무리 빨리 찾더라도 해시 버킷을 스캔하는 단계에서 많은 시간을 허비하기 때문에 탐색 속도가 현저히 저하된다. Build Input의 해시 키 컬럼에는 중복 값이 (거의) 없어야 Hash Join이 빠르게 수행될 수 있음을 이해할 것이다.

4. Hash Join 사용기준

아래는 Hash Join 성능을 좌우하는 두 가지 포인트이다.

• 한 쪽 테이블이 가용 메모리에 담길 정도로 충분히 작아야 함
• Build Input 해시 키 칼럼에 중복 값이 거의 없어야 함

아래는 Hash Join 이 효과적으로 사용될 경우이다.

• 조인 칼럼에 적당한 인덱스가 없어 NL Join이 비효율적일 때
• 조인 칼럼에 인덱스가 있더라도 NL Join 드라이빙 집합에서 Inner 쪽 집합으로의 조인 액세스량이 많아 Random 액세스 부하가 심할 때
• Sort Merge Join 하기에는 두 테이블이 너무 커 소트 부하가 심할 때
• 수행빈도가 낮고 조인할 때

Hash Join은 앞선 다른 조인과 다르게 영구적이지 못하고 소멸되는 치명적인 단점이 있어 수행빈도가 높은 쿼리에 Hash Join을 많이 사용한다면 CPU/Memory 작별을 고해야 할지 모른다.

즉 'Hash Join'은 수행 빈도가 낮고, 쿼리 수행 시간이 오래 걸리는 대용량 테이블을 조인할 경우에 주로 사용해야 한다. 

도메인 주도 설계 (DDD)

서비스 분리와 도메인 주도 설계

• DDD는 MSA의 서비스를 식별할 수 있는 도구를 제공
• DDD 중 전략적 설계가 MSA의 서비스를 식별하는데 도움

도메인이란?

• 소프트웨어를 개발하는 대상 영역
• 복잡한 비즈니스나 현실세계의 문제

도메인 주도 설계란?

• 복잡한 현실세계의 문제를 해결할 좋은 SW를 만들기 위한 기법
• 도메인 주도 설계는 도메인의 이해를 최우선시 하는 모델링 기법
• 전문가와 개발자의 커뮤니케이션이 중요
• 도메인과 도메인 모델 그리고 코드를 밀접하게 연관 시킴 (언어의 통일)
• 도메인 모델 - 동일한 관점에서 이해할 수 있고, 공유할 수 있도록 단순화 (다이아그램 사용)
• 코드에 도메인의 의미가 녹아 있도록 구현

DDD의 필요성 : Big Ball of Mud

• 요구사항 추출 -> 분석 -> 설계 -> 구현
• 계속되는 추가 요구사항
• 중요한 것과 덜 중요한, 혹은 중요하지 않은 것들이 하나의 큰 덩어리로 얽히게 됨

• 각 클래스(엔티티)의 의미 파악 어려움

DDD의 필요성 : Big Ball of Mud 원인 by Vaughn Vernon

• 조직에서 SW 설계에 충분한 노력을 들이지 않음
• 개발자는 도메인 보다 기술에 너무 몰두, 많은 문제를 기술적으로만 해결하려 함
• 도메인의 이해 없이 개발자 상상의 나래가 표출됨

전략적 설계

마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나눔

전략적 설계의 필요성

• 애자일 프로젝트 관리 시스템을 개발 사례
• 설계 초기에는 핵심이 되는 부분을 설계
• Big Ball of Mud 방지

서브 도메인

• 전체 비즈니스 도메인을 이해 가능한 하위 영역으로 분리 필요
• 전체의 큰 도메인을 분리함
• 핵심 서브 도메인, 지원 서브 도메인 (비즈니스 도메인), 일반 서브 도메인(큰 공수 없는 도메인)으로 분리

바운디드 컨텍스트

• 유비쿼터스 언어로 표현이 됨
• 의미적으로 동일한 맥락의 경계라는 것은 응집도 높은 일을 한다는 것
• 바운디드 컨텍스트 마다 각각 분리된 소프트웨어의 코드 산출

서브도메인과 바운디드 컨텍스트의 관계

• 서브 도메인은 Problem Space
• 바운디드 컨텍스트는 Solution Space
• Problem Space : 해결해야 하는 도메인 -  서브 도메인들의 집합
• Solution Space : 해결책을 실제 구현 - 바운디드 컨텍스트들의 집합
• 보통 하나의 서브도메인은 하나의 바운디드 컨텍스트를 갖는 1:1
• 서브도메인이 하나 이상의 바운디드 컨텍스트가 매핑 가능 (ex). 상품 - 연관상품, 쿠폰, 할인정보 등)

유비쿼터스 언어와 바운디드 컨텍스트의 관계

• 제품 책임자와 도메인 전문가 그리고 개발자 간 언어의 통일이 중요
• SW 개발의 가장 큰 문제 중 하나 (개발언어 x,  사용언어 o)
• 개발자가 아닌 사람도 도메인 모델 및 코드를 보고 이해할 수 있어야 함
• 컨텍스트에 따라 비슷해 보이는 언어들이 실제로는 다를 수 있음
• 각 문맥 별로 상품의 이름을 명확하게 재정의할 필요가 있음

       ex) - 카탈로그 컨텍스트에서의 상품은 Product

             - 재고 컨텍스트에서의 상품은 Stock

             - 주문 컨텍스트에서의 상품은 OrderedItem

결론

개발자가 아닌 사람이 이름만 딱 봐도 무엇인지 알 수 있도록 설계를 하자.