주로 브레인 분할(Split-brain) 현상이나 STW(Stop-The-World), 네트워크 지연 등으로 인해 발생하는 문제를 해결하기 위해 도입되었습니다.

1. 왜 필요한가요? (문제 상황)

분산 시스템에서는 특정 노드가 죽었는지, 단순히 네트워크가 느린 것인지 완벽하게 구별하기 어렵습니다. 이때 다음과 같은 사고가 발생할 수 있습니다.

1. 노드 A가 잠금(Lock)을 획득하여 공유 파일(Storage)에 접근합니다.

2. 노드 A에 갑자기 긴 GC(Garbage Collection)가 발생하여 일시 정지됩니다.

3. 잠금 서비스(예: ZooKeeper)는 노드 A가 죽었다고 판단하고 잠금을 해제한 뒤, 노드 B에게 잠금을 부여합니다.

4. 노드 B는 데이터를 쓰기 시작합니다.

5. 이때 노드 A의 GC가 끝나고 깨어납니다. A는 자신이 여전히 잠금을 가지고 있다고 착각하고 데이터를 씁니다.

결과적으로 노드 B의 데이터가 노드 A에 의해 덮어씌워져 데이터 오염이 발생합니다.

2. 펜싱 토큰의 작동 원리

펜싱 토큰은 잠금을 획득할 때마다 증가하는 숫자(Sequence Number)를 함께 부여함으로써 이 문제를 해결합니다.

토큰 발행

클라이언트가 잠금을 획득할 때, 잠금 서버는 현재 버전보다 높은 숫자(예: 31)를 토큰으로 발행합니다.

검증 요청

클라이언트가 저장소(Storage)에 데이터를 쓸 때 이 토큰(31)을 함께 보냅니다.

저장소의 거부

저장소는 자신이 마지막으로 처리한 토큰 번호를 기억합니다.

만약 이전에 이미 번호 32를 처리했다면, 번호 31을 가진 요청은 "과거의 요청"으로 간주하여 거부합니다.

3. 주요 구성 요소

• Lock Service 잠금과 함께 단조 증가하는 토큰을 생성합니다.

• Resource (Storage) 가장 최근에 수용한 토큰 번호를 저장하고, 그보다 낮은 번호의 요청은 무시합니다.

• Client 잠금을 획득할 때 받은 토큰을 모든 작업 요청에 포함시킵니다.

4. 요약

펜싱 토큰은 "늦게 온 요청이 시스템의 상태를 되돌리지 못하게 하는 안전장치"입니다.

아무리 노드가 자신이 권한이 있다고 주장해도, 토큰 번호가 낮으면 저장소 수준에서 입구 컷(Fencing)을 당하게 됩니다.

해당 글은 AI와 주고받은 내용을 정리한 메모성 글입니다.

바이브 코딩 (Vibe Coding)

바이브 코딩은 안드레이 카파시(Andrej Karpathy)가 언급하며 대중화한 개념으로, 개발자가 코드를 직접 한 땀 한 땀 타이핑하는 대신, LLM(대형 언어 모델)과 상호작용하며 의도와 흐름을 중심으로 소프트웨어를 구축하는 방식을 뜻합니다.

이제 개발자의 역량은 특정 언어의 문법을 외우고 구현하는 능력보다, 시스템을 추상화하여 AI에게 정확한 맥락을 제공하고 생성된 결과물을 검증하는 시스템 설계 및 검토 역량으로 변화하고 있습니다.

본질

바이브 코딩은 단순히 AI에게 코딩을 시키는 것이 아닙니다. 개발자는 본인이 가지고 있는 도메인 지식과 아키텍처 설계 지식을 AI에게 명확히 전달하는 역량이 중요해졌습니다.

최근 프로덕트 엔지니어와 도메인 지식이 강조되는 이유도 이 때문입니다.

AI의 한계

AI에게 아무리 명확하고 구체적인 요구사항을 전달하더라도 다음과 같은 치명적인 문제에 직면하게 됩니다.

지능의 한계와 환각

LLM은 한 번에 처리할 수 있는 정보량인 컨텍스트 윈도우(Context Window) 범위 내에서만 추론할 수 있습니다.

만약 AI가 참조하고, 기억해야하는 컨텍스트의 크기가 커지고, 그 한계에 도달하게 되면 AI는 컨텍스트의 일부를 유실하는 망각 현상이 발생하게 됩니다.

망각 현상이 발생하게 되면 존재하지 않는 참조와 코드를 만들어내는 환각을 만들어내게 되는데, 이렇듯 구조화되지 않은 코드와 프로젝트 구조는 AI에게 과도한 노이즈를 제공하여 추론 능력을 저하시킵니다.

경제적 효율성의 하락

최근의 AI 에이전트(Claude의 Subagents 등)는 복잡한 문제를 풀기 위해 스스로 코드를 읽고 도구를 사용(Skills)하며 수십 번의 추론 과정을 거칩니다.

위에서 말했듯, 아키텍처가 부재한 프로젝트는 AI가 단 하나의 기능을 수정하기 위해 프로젝트 전체를 훑으며 관계없는 과도한 노이즈까지 컨텍스트로 참조하게 됩니다.

이는 기하급수적인 토큰 비용 상승을 야기하고 개발 생산성보다 AI 유지 비용이 더 커지는 역전 현상을 발생시키게 됩니다.

비결정성(Non-determinism)과 오염

바이브 코딩의 가장 치명적인 단점은 동일한 지시(Prompt)를 내려도 AI가 매번 다른 결과물을 내놓는다는 점입니다.

AI는 주어진 지시사항을 완수하기 위해 가장 확률적으로 높은 빠른 길을 선택합니다.

계층 구조가 모호한 프로젝트에서 AI는 비즈니스 로직(Service) 내부에 DB 스키마 의존성을 심거나 외부 API 호출 코드를 직접 삽입하는 등의 행위를 서슴지 않습니다.

이렇게 무작위적으로 생산되는 코드는 당장 동작하는데 문제가 없을지언정, 장기적으로는 인간도 AI도 이해할 수 없는 거대한 '오염된 코드 덩어리'를 만들어내며 기술적 부채를 통제 불가능한 수준으로 가속화시킵니다.

클린 아키텍처

이러한 AI의 태생적인 한계를 극복할 수 있는 수단으로 Robert C. Martin(엉클 밥)이 제안한 클린 아키텍처가 떠오르고 있습니다.

클린 아키텍처의 핵심은 의존성 규칙(Dependency Rule)으로, 소스 코드의 의존성은 반드시 외부에서 내부로만 향해야 하며, 내부 원(Circle)에 있는 요소는 외부 원에 있는 어떤 것도 알지 못해야 한다는 원칙을 따릅니다.

위에서도 언급했듯이 바이브 코딩은 개발자가 세부 구현보다 의도(Vibe)에 집중하는 방식인데, 이때 클린 아키텍처는 AI에게 사고의 지도와 행동의 제약을 동시에 제공하며, 단순한 코드 정리를 넘어 비결정적인 AI를 통제하는 최적의 시스템이 됩니다.

바이브 코딩과 클린 아키텍처의 시너지

AI 최적화

클린 아키텍처는 UseCase라는 명확한 진입점을 제공하고 AI가 참조해야 할 파일의 범위를 좁혀주므로, 불필요한 토큰 소모를 줄이고 한정된 컨텍스트 내에서 AI의 추론 정확도를 극대화하는 효과를 얻을 수 있습니다.

비결정성 제어

AI는 동일한 지시에도 매번 다른 품질의 코드를 내놓는 비결정성 특징을 가집니다.

클린 아키텍처의 계층 구조는 AI가 편의를 위해 레이어를 침범하지 못하게 제한하기 때문에 결과적으로 코드의 오염과 기술적 부채가 쌓이는 것을 최소화할 수 있습니다.

독립성

클린 아키텍처는 엔티티, 유스케이스, 어댑터 등으로 계층화되어 있어 비즈니스 로직을 외부 도구(프레임워크, 개발 언어 등)로부터 완전히 격리시킬 수 있습니다.

이러한 독립성 때문에 개발자는 언어나 프레임워크에 종속되지 않은 채 프롬프트만으로 동일한 기능을 구현해낼 수 있습니다.

또한, 구조가 명확히 분리되어있어 AI가 생성한 코드가 어느 부분에 위치해야 할지 명확하게 예측할 수 있어 관리가 쉬워집니다.

가상 클린 아키텍처

바이브 코딩으로 진행하는 모든 프로젝트를 당장 클린 아키텍처로 리팩토링할 수는 없습니다. 이때 활용할 수 있는 현실적인 대안이 바로 AI 전용 아키텍처 가이드라인(.md)을 활용한 '가상 클린 아키텍처' 전략입니다.

이는 물리적 폴더 구조를 바꾸지 않고도 AI의 오염을 막는 소프트웨어적 격벽 역할을 합니다.

Claude Code의 /init 과 AI 전용 아키텍처 가이드라인의 차이

Claude Code의 /init 명령어로 생성되는 CLAUDE.md와 혼동될 수 있지만, 두 문서의 목적은 명확히 다릅니다.

CLAUDE.md

이 파일의 본질은 AI가 이 프로젝트에서 어떻게 행동해야 하는가에 대한 운영 매뉴얼에 가깝습니다.

빌드 명령어, 테스트 실행법, 네이밍 컨벤션, 린트 설정 등 작업 환경에 집중하는 내용을 갖고 있습니다.

AI 전용 아키텍처 가이드라인 (설계 원칙)

AI 전용 아키텍처 가이드라인은 이 프로젝트가 어떤 철학으로 설계되었고, 설계해야하는가?에 대한 소프트웨어 설계 원칙을 박아넣는 것입니다.

AI가 편의를 위해 스파게티 코드를 짜려는 본능을 억제하고, 특정 아키텍처(예: 클린 아키텍처)의 설계 지능을 이식하는 역할을 수행합니다.

가상 클린 아키텍처의 한계

문서 하나로 모든 설계 문제를 해결할 수 있다면 좋겠지만, 가상 클린 아키텍처는 어디까지나 임시 방편입니다.

따라서 원본 코드의 상태에 따라 다음과 같은 한계가 발생합니다.

Context 한계와 환각의 상관관계

위에서 말했듯, AI가 한 번에 읽을 수 있는 컨텍스트 윈도우(Context Window)는 한계가 정해져 있습니다.

하나의 파일에 수천 줄의 로직이 뒤섞여 있다면, AI는 가이드라인(.md)을 준수하려고 노력하는 동시에 거대한 원본 코드를 해석하느라 에너지를 소모합니다.

정보 밀도가 한계치에 다다르면 AI는 가이드라인을 무시하거나, 기존 코드의 스파게티 구조를 그대로 복제하는 환각 증상을 보이기 시작합니다.

물리적 격벽 없는 규칙의 허망함

아무리 "도메인과 인프라를 분리하라"고 명시해도, 실제 코드가 하나의 클래스 안에 모든 기능이 다 들어가 있다면 AI는 '가상으로라도' 분리해서 짤 공간을 찾지 못합니다.

결국 기존 코드를 따라가게 되며, 이는 논리적 규칙이 물리적 혼돈을 이기지 못하는 결과를 초래합니다.

그래서?

가상 클린 아키텍처는 시간을 벌어주는 도구이지 최종 목적지가 되어서는 안 됩니다. 가장 현실적인 로드맵은 다음과 같습니다.

• 점진적 격리 새로운 기능을 추가할 때만큼은 가상 아키텍처 가이드를 준수하며 별도의 패키지나 모듈로 분리합니다.

• 보이스카우트 규칙 건드리는 코드 주변부터 조금씩 물리적 격벽을 세워 나갑니다.

• 가이드의 구체화 AI에게 단순히 "클린하게 짜줘"라고 하기보다, "새로운 기능은 반드시 src/features 하위에 UseCase 단위로 작성하라"는 식의 물리적 위치를 지정해 주는 것이 효과적입니다.

결론

바이브 코딩 시대에 클린 아키텍처 구조는 AI의 환각과 오염 리스크를 줄일 수 있는 현 시점에서의 최선의 타협점이라고 생각합니다.

우리는 이제 클린 아키텍처를 단순히 '코드 유지보수가 편한 디자인 패턴'으로 봐서는 안 됩니다. 오히려 AI라는 강력하지만 통제하기 어려운 비결정적(Non-deterministic) 개발 도구를 안전하게 다루기 위한 핵심 방역 체계로 재해석해야 합니다.

클린 아키텍처는 AI에게 전달할 맥락을 도메인 단위로 격리하여 비용을 절감하고, 물리적 계층 분리를 통해 AI의 무분별한 코드 생성을 차단하는 '가이드레일' 역할을 합니다.

결국 바이브 코딩 시대의 경쟁력은 AI에게 얼마나 많은 코드를 맡기느냐가 아니라, AI가 사고를 쳐도 시스템의 핵심(Domain)만큼은 무너지지 않도록 얼마나 견고한 격벽(Architecture)을 설계하느냐에 달려 있습니다.

참고 문서

• The Clean Architecture
• Gemini

토이프로젝트를 진행하던 중 다른 Controller의 API는 정상인데, 특정 Controller의 API만 ClassValidator가 동작을 하지 않는 상황이 발생했습니다.

원인

Barrel Import

Barrel Import 여러 모듈 또는 파일을 index 파일 하나에서 모두 export하고, 외부에서는 하나의 파일만 Import하여 사용하는 패턴

결과적으로 Controller -> DTO -> Barrel Import -> Controller 식으로 의존성이 꼬이면서 순환 참조가 발생했던 케이스였습니다.

문제의 코드

import { GenerateJwtTokenBody, GenerateJwtTokenResponse } from '@app/controllers';

위와 같이 잘못된 Barrel Import로 인해 순환 참조가 발생하게 되면, 자바스크립트 엔진은 모듈이 무한 루프에 빠지는 것을 방지하기 위해 ReferenceError 에러를 발생시키거나 undefined 객체를 응답하게 됩니다.

이렇게 정상적으로 Import가 되지 않은 상황에서 reflect-metadata가 호출되면 reflect는 메타데이터를 정상적으로 읽지 못하게 되고, class-validator, class-transformer, DI 의존성 주입, Swagger 문서 생성 등 다양한 기능들이 동작을 하지 않게 됩니다.

해결 방법

해결 방법은 단순합니다.

Barrel Import로 인해 순환 참조가 발생하게 되었으니, Deep Import 방식으로 파일을 Import하거나, 순환 참조가 발생하지 않게끔 상대 경로로 Import 하면 됩니다.

수정한 코드

import { GenerateJwtTokenBody, GenerateJwtTokenResponse } from './dto';

결론

이와 같이 논리적인 에러는 원인을 파악하기 힘듭니다... Syntactic Error가 최고야...

참고 문서

• NodeJS 문서(Cycles)
• JavaScript MDN(Cyclic_imports)

해당 글은 개인으로 사용하는 미니 PC에 Kubernetes를 설치하고, 기본적인 설정을 다룬 내용을 간략하게 정리한 글입니다.

관련해서 왜 이렇게 설치를 했는지에 대해서는 지속적으로 추가 업데이트 할 예정입니다.

초기 설정

OS 설정

SELinux 설정

쿠버네티스는 기본적으로 SELinux Mode가 permissive로 설정되어 있어야 합니다. ( 관련 문서: installing-kubeadm-kubelet-and-kubectl )

따라서 아래의 명령어를 통해 SELinux 설정을 변경해줍니다.

# Set SELinux in permissive mode (effectively disabling it)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

swapconfig

그리고 kubelet은 스왑 메모리가 감지되면 정상적으로 동작하지 않습니다. ( 관련 문서: install-kubeadm )

따라서 아래 명령어를 통해 스왑 메모리 설정을 비활성화시켜 줍니다.

sudo swapoff -a

ip_forward 설정

net.ipv4.ip_forward 옵션은 리눅스 커널이 IPv4 패킷을 다른 인터페이스로 라우팅할 지에 대한 여부를 설정하는 옵션입니다.

쿠버네티스는 기본적으로 CNI를 통해 Pod / Node간 통신을 처리하는 구조로 되어있기 때문에, 라우팅/포워딩을 할 수 있도록 1로 설정해줍니다.

sudo sysctl -w net.ipv4.ip_forward=1

만약 이 설정을 하지 않을 경우 컨트롤 플레인 초기화 시 아래와 같은 에러가 발생할 수 있습니다.

[ERROR FileContent--proc-sys-net-ipv4-ip_forward]: /proc/sys/net/ipv4/ip_forward contents are not set to 1

firewalld disabled

쿠버네티스는 기본적으로 사용되는 포트가 존재합니다.

이 중 Kubernetes API server 포트와 Kubelet API 포트는 필수적으로 사용되는 포트이기 때문에 OS 방화벽에서 해당 포트들을 허용처리 해주어야 합니다.

쿠버네티스에서 기본적으로 사용되는 포트와 MySQL, Redis 등을 사용할 때 마다 방화벽을 설정하는 것도 좋지만, 이번 글에서는 귀찮으므로 OS 방화벽 설정을 해제하는 방법으로 진행하고자 합니다.

systemctl stop firewalld
systemctl disable firewalld

만약 이러한 설정을 하지 않을 경우 컨트롤 플레인 초기화 시 아래와 같은 에러가 발생할 수 있습니다.

[WARNING Firewalld]: firewalld is active, please ensure ports [6443 10250] are open or your cluster may not function correctly

containerd 설치

쿠버네티스는 기본적으로 Pod에서 컨테이너를 실행시키기 위해 container runtime을 사용합니다.

사용할 수 있는 Container Runtime 목록

• containerd
• CRI-O
• Docker Engine
• Mirantis Container Runtime

그리고 이 글에서는 containerd를 사용하는 방법으로 진행합니다.

dnf Repository 추가

sudo dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

containerd.io 설치

sudo dnf install containerd.io

containerd 설정 변경

containerd는 기본적으로 cri 플러그인이 비활성화된 상태로 설치가 됩니다.

cri는 containerd가 쿠버네티스와 통신하기 위한 규약인데, /etc/containerd/config.toml 설정파일을 열어서 cri를 활성화시켜줍니다.

disabled_plugins = [] # disabled_plugins = ["cri"] 에서 cri를 지워주세요.

그리고 재시작을 해줍니다.

service containerd restart

만약 이러한 설정을 하지 않을 경우 컨트롤 플레인 초기화 시 아래와 같은 에러가 발생할 수 있습니다.

[preflight] WARNING: Couldn't create the interface used for talking to the container runtime: failed to create new CRI runtime service: validate service connection: validate CRI v1 runtime API for endpoint "unix:///var/run/containerd/containerd.sock": rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService

Kubernetes 설치

kubernetes 저장소 추가

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.34/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.34/rpm/repodata/repomd.xml.key
EOF

kubelet, kubeadm, kubectl 설치

dnf install kubelet kubeadm kubectl

컨트롤 플레인 초기화

kubeadm init --apiserver-advertise-address={IP_ADDRESS}

아래와 같이 메세지가 응답되었다면 Kubernetes control-plane 초기 설정에 성공한 것입니다.

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join {IP Address:Port} --token {token값} --discovery-token-ca-cert-hash {hash값}

그러면 안내를 따라서 아래의 명령을 실행해줍니다.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

컨트롤 플레인 노드에서 Pod를 실행할 수 있게 taint 설정

쿠버네티스는 기본적으로 컨트롤 플레인과 워커 노드로 구성됩니다.

기본적으로 컨트롤 플레인 노드는 클러스터의 운영, 관리의 역할을 수행하기 때문에 Pod를 띄울 수 없으며, kubeadm init을 통해 컨트롤 플레인을 구성하고, kubeadm join을 통해 워커 노드를 추가하여 Pod를 띄우는 것이 일반적인 방법입니다.

하지만 지금처럼 쿠버네티스를 단일 서버로 구성하는 경우 컨트롤 플레인 노드에서 Pod를 실행할 수 있게끔 taint를 변경해주어야 합니다.

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Calico 설치

참고 문서: https://kubernetes.io/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

중간 과정 확인

kubectl get pods --all-namespaces

[root@localhost tmp]# kubectl get pods --all-namespaces
NAMESPACE              NAME                                                    READY   STATUS    RESTARTS   AGE
kube-system            calico-kube-controllers-b45f49df6-zq85q                 1/1     Running   0          35m
kube-system            calico-node-6qr5n                                       1/1     Running   0          35m
kube-system            coredns-66bc5c9577-mdvrd                                1/1     Running   0          42m
kube-system            coredns-66bc5c9577-pvwdq                                1/1     Running   0          42m
kube-system            etcd-localhost.localdomain                              1/1     Running   0          42m
kube-system            kube-apiserver-localhost.localdomain                    1/1     Running   0          42m
kube-system            kube-controller-manager-localhost.localdomain           1/1     Running   0          42m
kube-system            kube-proxy-lw4z6                                        1/1     Running   0          42m
kube-system            kube-scheduler-localhost.localdomain                    1/1     Running   0          42m

kubectl get services --all-namespaces

[root@localhost tmp]# kubectl get services --all-namespaces
NAMESPACE              NAME                                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
default                kubernetes                             ClusterIP      10.96.0.1        <none>        443/TCP                      42m
kube-system            kube-dns                               ClusterIP      10.96.0.10       <none>        53/UDP,53/TCP,9153/TCP       42m

helm 설치

sudo dnf install helm

helm Repository 추가

helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/

ingress-nginx 설치

helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

Kubernetes Dashboard 설치

https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/

helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard

아래와 같이 나오면 성공입니다.

Release "kubernetes-dashboard" does not exist. Installing it now.
NAME: kubernetes-dashboard
LAST DEPLOYED: Sat Nov 29 00:13:33 2025
NAMESPACE: kubernetes-dashboard
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
*************************************************************************************************
*** PLEASE BE PATIENT: Kubernetes Dashboard may need a few minutes to get up and become ready ***
*************************************************************************************************

Congratulations! You have just installed Kubernetes Dashboard in your cluster.

To access Dashboard run:
  kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443

NOTE: In case port-forward command does not work, make sure that kong service name is correct.
      Check the services in Kubernetes Dashboard namespace using:
        kubectl -n kubernetes-dashboard get svc

Dashboard will be available at:
  https://localhost:8443

네트워크 설정

대시보드 ingress 추가

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: nginx
  rules:
  - host: {dashboard-host}
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubernetes-dashboard-kong-proxy
            port:
              number: 443

공유기 포트포워딩 설정

접속 테스트

ingress에서 설정한 {dashboard-host} 도메인으로 접속을 했을 때 아래와 같이 나오면 성공입니다.

https://{dashboard-host}

Bearer token 발급

Kubernetes Dashboard에 접속할 때 사용할 수 있는 인증 전략은 여러가지가 있습니다.

그 중 아주 기본적이고 간단하게 접속할 수 있는 Bearer token을 수동으로 발급받아 접속하는 방법으로 설명하려고 합니다.

ServiceAccount 생성

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard

Bearer Token 발급

kubectl -n kubernetes-dashboard create token admin-user

kubectl -n kubernetes-dashboard create token admin-user
{발급된 Bearer Token 어쩌구}

접속

발급된 Bearer Token을 입력 후 접속을 했을 때 아래와 같이 나온다면 성공입니다.

서비스 등록하기

아래처럼 서비스를 활성화 및 시작하여 OS가 재부팅될 때 자동으로 실행되게끔 처리합니다.

sudo systemctl enable containerd
sudo systemctl start containerd

sudo systemctl enable kubelet
sudo systemctl start kubelet

이번에 Kubernetes 스케줄링 관련 공부를 하면서 알게된 내용을 정리하는 글로서, 간략하게만 정리한 내용을 담고 있습니다.

용어 정리

• ActiveQ 스케줄링을 할 수 있는 Pod들이 대기하는 큐 새로 생성된 Pod 또는 BackoffQ 또는 unschedulablePods로 분류되었다가 다시 스케줄링을 할 수 있는 상태가 된 Pod가 이에 해당합니다.
• BackoffQ 이전에 스케줄링을 시도했으나 일시적인 이유로 실패하고, 일정 시간동안 스케줄링을 기다리는 Pod들이 대기하는 큐
• unschedulablePods 스케줄링을 시도했으나, taint 등의 이유로 그 어떤 Node에도 배치할 수 없는 Pod들

kube-scheduler

kube-scheduler는 Pod를 노드에 할당하는 제어 플레인 프로세스입니다.

새로 생성되었지만 Worker Node에 할당되지 않은 Pod들을 감시하고, 이러한 Pod들을 적합한 Worker Node에 배정하는 역할을 수행합니다.

적합한 Worker Node를 찾는 방법 (Scheduling)

Watch

kube-scheduler는 API 서버를 통해 nodeName 필드가 비어있는 Pod가 존재하는지 주기적으로 확인합니다.

이 때 새로 생성된 Pod를 감지하는 경우, 해당 Pod를 ActiveQ에 등록합니다.

Filtering

ActiveQ에 등록된 Pod들의 조건(예: CPU/Memory 요청량, Label, Taint 등)을 충족하는 Worker Node를 선별하는 작업입니다.

Pod가 요구하는 Resource를 충족하는 Worker Node가 존재하지 않는 등의 일시적인 이유로 필터링에 실패한 경우, 해당 Pod는 backoffQ에 등록되고 일정 시간(backoff period) 이후 ActiveQ에 재등록되어 스케줄링을 다시 시도합니다.

만약 taint가 불일치하거나, Affinity 조건 불충족 등의 이유로 실패한 경우, 해당 Pod는 unschedulablePods로 분류되고, 이후 Node가 추가되거나 taint가 변경되는 등의 클러스터 이벤트가 발생했을 때 ActiveQ에 등록되며, 스케줄링을 다시 시도합니다.

Scoring

Filtering을 통과한 Node들을 대상으로 점수를 부여합니다.

Node의 Resuorce 여유량, 해당 노드에 할당된 Pod 갯수 등 다양한 기준으로 점수를 부여합니다.

Binding

kube-scheduler는 가장 높은 점수를 가진 Node에 Pod를 배치하며, 만약 동일한 점수를 가진 Node가 2개 이상인 경우 랜덤으로 Node를 선택하여 Pod를 배치하게 됩니다.

Pod의 nodeName 필드에 선택된 Worker Node의 이름을 기록합니다.

참고 문서

• Kubernetes Scheduler
• Scheduling, Preemption and Eviction

참고! 비슷한 에러로는 [413] Content Too Large가 있습니다. 다만 NodeJS 기준으로 431 에러와 413 에러를 처리하는 레이어가 다릅니다.

웹 서버는 왜 HTTP Header Size를 제한하는걸까?

기본적으로 HTTP Header 명세에서는 Header 크기에 대해 명시가 되어있지 않습니다. 그럼에도 불구하고 웹 서버가 Header 크기를 제한하는 이유는 무엇일까요?

기본적으로 Client와 웹 서버의 연결은 TCP 방식으로 통신이 이루어집니다. Client가 웹 서버로 HTTP 요청 패킷을 보내면 웹 서버는 해당 패킷을 파싱하여 처리를 하게 됩니다.

이 과정에서 파싱된 패킷 데이터는 웹 서버가 처리할 수 있는 구조로 변환되고, 이 요청에 대해 응답을 할 때 까지 파싱된 패킷 데이터는 웹 서버 메모리에 올라가게 되는데요. 이 때 Client가 요청한 데이터의 크기에 제한이 없다면, 매우 큰 헤더의 요청을 받았을 때 서버의 리소스가 고갈되어 처리 성능이 저하되거나 서비스가 불가능한 상태로 확장될 수 있습니다.

웹 서버는 이러한 문제를 방지하고자 기본적으로 적절한 크기로 HTTP Header의 크기를 제한하고 있습니다.

참고! 웹 서버마다 기본으로 설정된 HTTP Header Size가 다릅니다. :)

일반적으로 431 에러가 발생하는 케이스

HTTP/1.x

HTTP/1.x에서 정의된 Header Field 목록은 rfc2616에서 확인할 수 있습니다.

일반적으로 HTTP/1.x에서 웹 사이트를 이용할 때 영향을 주는 대표적인 헤더 필드는 아래와 같습니다.

1. Cookie 크기 증가
2. Referer 길이 증가
3. UserAgent 길이 증가
4. Authorization 헤더의 길이 증가
5. X-Forwarded-For 길이 증가

HTTP/2

HTTP/2로 버전이 올라가면서 변경된 부분은 rfc7540 - HTTP Request/Response Exchange에서 자세히 확인할 수 있습니다.

일반적으로 HTTP/2에서 웹 사이트를 이용할 때 영향을 주는 대표적인 헤더 필드는 아래와 같습니다.

• HTTP/1.x 필드 길이 증가
• Pseudo-Header 길이 증가 (:authority, :path)

Pseudo-Header

Pseudo-Header Fields의 자세한 내용은 아래의 링크에서 확인해주세요. https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.3

HTTP/2에서 Pseudo-Header가 신규로 추가되었는데, 이 헤더는 일반 헤더 블록의 앞에 위치하기 때문에 HTTP Header 크기에 영향을 줍니다.

8.1.2.1. Pseudo-Header Fields All pseudo-header fields MUST appear in the header block before regular header fields.

참고 문서

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/431
• https://datatracker.ietf.org/doc/html/rfc2616
• https://datatracker.ietf.org/doc/html/rfc7540
• https://github.com/nodejs/node/blob/main/src/node_http_parser.cc

지금도 제가 원하는 지역의 아파트 시세나 매물 등을 확인하는 용도로 사용을 하고 있는데요.

관련해서 작업했던 기록을 정리해보려고 합니다.

이 글에서는 네이버 부동산 매물 크롤러를 만들 때 설계한 내용을 정리하는 글입니다.

참고! 네이버는 부동산 매물 관련해서 공식 API를 지원하지 않습니다.

그래서 네이버 부동산 웹 사이트에서 호출하는 API를 기반으로 매물을 조회해서 가지고 와야 합니다.

네이버 부동산 API는 짧은 시간에 대량으로 요청하면 일시적으로 호출이 차단될 수 있으므로 호출량을 적절히 조절하여 호출하는 과정이 필요합니다.

관련해서 발생할 수 있는 법적 문제는 본인 책임입니다.

Github Repository

Repository: 링크

프로젝트에 대한 간단한 설명은 레포지토리 내 readme.md 파일에 기록해두었습니다.

토이 프로젝트의 목적

1. NestJS 프레임워크에 익숙해지기
2. 관심이 생긴 부동산 (언제가 될지는 모르겠지만 내집마련의 꿈)
3. 심심풀이 땅콩

개발 환경

• Node.js (with Typescript, NestJS)
• MySQL (with TypeOrm)
• Redis (with BullJS)
• Docker

네이버 부동산 API 정리

Cluster API

/cluster/ajax/articleList

부동산 지도 화면에서 매물 목록을 누르면 호출되는 API입니다.

지정한 위도, 경도 좌표 범위 내에 존재하는 부동산 매물의 목록을 조회할 수 있습니다.

그 외 Filter 값을 통해 조회할 매물을 필터할 수 있습니다.

호출 예시: https://m.land.naver.com/cluster/ajax/articleList?rletTpCd=APT%3AOPST&tradTpCd=A1%3AB2&z=19&lat=37.5236987&lon=126.8992539&btm=37.522901&lft=126.8958207&top=37.5244964&rgt=126.9026871&spcMin=33&spcMax=900000000&dprcMax=40000&wprcMax=10000&showR0=&totCnt=41

/cluster/ajax/complexList

부동산 지도 화면에서 단지 목록을 누르면 호출되는 API입니다.

지정한 위도, 경도 좌표 범위 내에 존재하는 단지 목록을 조회할 수 있습니다.

호출 시 필요한 QueryString은 /cluster/ajax/articleList와 동일합니다.

호출 예시: https://m.land.naver.com/cluster/ajax/complexList?rletTpCd=APT%3AOPST&tradTpCd=A1%3AB2&z=19&lat=37.5236987&lon=126.8992539&btm=37.522901&lft=126.8958207&top=37.5244964&rgt=126.9026871&spcMin=33&spcMax=900000000&dprcMax=40000&wprcMax=10000&showR0=&totCnt=22&isOnlyIsale=false

위도, 경도 좌표 범위에 대해서

lat는 latitude, lon은 longitude, btm은 bottom, lft는 left, top은 top, rgt는 right의 약자로 위도, 경도의 좌표값을 가지고 있습니다.

위도에 해당하는 필드: lat, top, btm 경도에 해당하는 필드: lon, lft, rgt

위 지도를 기준으로 매물 목록 버튼을 누르면 아래의 QueryString으로 /cluster/ajax/articleList API가 호출됩니다.

QueryString

lat=37.5100191&lon=126.891867&btm=37.5056275&lft=126.8754734&top=37.5144105&rgt=126.9082607

이 때 각 필드의 의미는 아래와 같습니다.

보여지는 지도의 중앙 좌표: lat, lon 보여지는 지도의 상하좌우 끝단의 좌표: top, lft, rgt, btm

따라서 위 지도 기준으로 lat, lon 좌표의 위치는 신도림역이고, lft와 btm 좌표의 위치는 왼쪽 하단의 월드메르디앙 아파트의 위치가 됩니다.

Front API

네이버 부동산 소스 코드를 뜯어보면 아래와 같이 front-api로 명시된 API 목록을 확인할 수 있습니다.

프론트 화면을 구성하기 위해 매물에 대한 추가 정보를 조회하는 API 모음일 것으로 예상하고 있으며, 이 중 몇가지 중요 API를 설명하도록 하겠습니다.

/front-api/v1/article/key

매물과 연관된 Key 정보를 조회할 수 있는 API 입니다.

이 API를 통해서 확인한 데이터는 다른 front-api를 호출할 때 사용됩니다.

요청 예시: https://fin.land.naver.com/front-api/v1/article/key?articleId=2429861377

/front-api/v1/article/basicInfo

매물의 상세 정보를 조회할 수 있습니다.

매물 목록 조회 API를 통해서 알 수 있는 정보보다 더 자세한 매물 정보를 조회할 수 있습니다.

요청 예시: https://fin.land.naver.com/front-api/v1/article/basicInfo?articleId=2429861377&realEstateType=A02&tradeType=A1

/front-api/v1/complex

매물의 단지 정보를 조회할 수 있습니다.

요청 예시: https://fin.land.naver.com/front-api/v1/complex?complexNumber=127997

/front-api/v1/complex/evStaion (네이버에서 오타..낸듯..?)

단지 내 전기차 충전 시설 정보를 조회할 수 있습니다.

요청 예시: https://fin.land.naver.com/front-api/v1/complex/evStaion?complexNumber=3210

/front-api/v1/article/transport

매물 주변의 대중교통 정보를 조회할 수 있습니다.

요청 예시: https://fin.land.naver.com/front-api/v1/article/transport?itemId=2429861377&itemType=article

Rate Limit ?

네이버 부동산 API는 짧은 시간에 많은 요청을 보내면 일정 시간동안 접속이 차단되니 주의하셔야 합니다.

Character Set과 Collation은 MySQL이 Text 데이터를 관리하는 데 있어서 가장 기본적이고 중요한 요소 중 하나입니다.

하지만 많은 사람들이 무심코 넘어가는 이 녀석들. MySQL의 성능과 데이터 저장 방식, 검색 결과 등에 영향을 끼치는 아주아주 중요한 역할을 한다는 것을 알고 계셨나요?

이 글에서는 Character Set과 Collation에 대해서 간단하게 정리를 해보려고 합니다.

Character Set

Character Set은 MySQL이 문자열 데이터를 저장하고 처리할 때 사용하는 문자 집합을 의미합니다.

MySQL에서 지원하는 Character Set 확인하기

아래의 쿼리를 통해서 MySQL에서 사용 가능한 Character Set 목록을 확인할 수 있습니다.

SHOW CHARACTER SET;

Character Set 관련 변수

이 글에서는 MySQL에서 데이터를 액세스하고, Client와 통신할 때 영향을 받는 변수들만 정리합니다.

character_set_database

참고! 여기에서 말 하는 Database는 MySQL의 Schema를 의미합니다.

Database의 기본 Character Set을 정의합니다.

Database를 생성할 때 Character Set을 명시하지 않으면 이 변수에 설정된 Character Set으로 자동 생성됩니다.

만약 이 변수의 값이 설정되지 않았다면 character_set_server 변수 값을 따릅니다.

해당 변수는 추후 deprecated 될 예정이라고 하니 참고하시기 바랍니다.

공식 문서 내용 The global character_set_database and collation_database system variables are deprecated; expect them to be removed in a future version of MySQL.

character_set_client

Client가 MySQL 서버로 데이터(SQL 쿼리, Text 데이터 등)를 전송할 때 사용한 Character Set을 지정할 때 사용합니다.

기본적으로 MySQL 서버는 Client가 전송한 데이터의 Character Set을 알 수가 없습니다. 그렇기 때문에 MySQL 서버는 요청이 들어온 Client의 Session 변수(character_set_client)를 참고하여 Character Set을 유추할 수 있습니다.

그렇기 때문에 Client는 MySQL 서버로 데이터를 전송할 때 character_set_client 세션 변수 값을 변경하여 MySQL 서버에게 '나는 이런 Character Set을 사용하여 데이터를 전송했어'라고 알려주는 과정이 중요합니다.

character_set_connection

Client가 전송한 데이터를 처리할 때 사용할 Character Set을 설정합니다.

Client가 요청한 데이터의 인코딩을 character_set_client → character_set_connection으로 재인코딩하여 처리를 수행합니다.

기본적으로 이 값은 MySQL 서버의 Character Set과 동일하게 맞춰 사용을 합니다.

character_set_results

MySQL 서버가 Client로 결과를 반환할 때 사용하는 Character Set을 설정합니다.

character_set_client 변수가 Client에서 MySQL 서버로 전송할 때 라면, 이 변수는 MySQL 서버에서 Client로 데이터를 전송할 때 사용하는 Character Set을 의미합니다.

문자열 데이터 Type의 길이 측정 방식

문자열 데이터 Type은 최대로 저장할 수 있는 문자열 길이를 Byte로 관리를 합니다.

아래는 주로 사용하는 Type에 대해 정리한 표 입니다.

기본적으로 MySQL은 문자열 데이터를 관리할 때 문자열 길이와 문자열을 조합하여 저장합니다.

예를 들어 Eat라는 문자열을 저장하면 3Eat와 같이 문자열 길이와 데이터가 조합된 형식으로 저장이 되기 때문에 문자열 길이 사이즈를 제외한 Byte만큼 문자열을 저장할 수 있습니다.

그리고 이 제한은 Character Set이 지원하는 문자당 최대 Byte 수에도 영향을 받습니다.

아래는 Character Set이 지원하는 문자당 최대 Byte 수와 한글 문자열을 저장했을 때 실제로 계산되는 길이 Byte를 정리한 표 입니다.

따라서 utf8mb4 기준으로 varchar Type에 저장할 수 있는 문자열은 최대 16,383 글자입니다.

그 근거로 컬럼을 varchar(65535) Type으로 생성하려고 했을 때 utf8mb3와 utf8mb4에서 발생하는 에러 메세지를 출력한 내용입니다.

• ** utf8mb3 **

  [42000][1074] Column length too big for column 'name' (max = 21845); use BLOB or TEXT instead.

  21,845는 varchar Type으로 선언할 수 있는 최대 길이인 65,535에서 3Byte를 나눈 수 입니다.

• ** utf8mb4 **

  [42000][1074] Column length too big for column 'name' (max = 16383); use BLOB or TEXT instead.

  16,383은 varchar Type으로 선언할 수 있는 최대 길이인 65,535에서 4Byte를 나눈 수 입니다.

이는 MySQL이 각 Character Set에서 지원하는 최대 Byte에 해당하는 문자열을 가지고 데이터를 저장하는 최악의 시나리오로 가정을 하고 문자열 길이를 계산하기 때문입니다.

인덱스에도 영향을 끼친다.

길이를 계산할 때 해당 Character Set에서 지원하는 문자당 최대 Byte를 가지고 계산한다고 말씀드렸는데, 이러한 관리 방법은 인덱스 Key 에서도 동일하게 적용이 됩니다.

참고! The index key prefix length limit is 3072 bytes for InnoDB tables that use DYNAMIC or COMPRESSED row format.

The index key prefix length limit is 767 bytes for InnoDB tables that use the REDUNDANT or COMPACT row format.

For example, you might hit this limit with a column prefix index of more than 191 characters on a TEXT or VARCHAR column, assuming a utf8mb4 character set and the maximum of 4 bytes for each character.

Character Set을 utf8mb4로 설정하는 경우 실제 Byte보다 더 긴 길이를 사용하는 것으로 판단하기 때문에 하나의 인덱스 페이지에서 관리할 수 있는 인덱스 엔트리 수가 줄어들게 됩니다.

결국 데이터를 조회할 때 더 많은 인덱스 페이지를 탐색해야하기 때문에 Disk I/O가 증가할 수 있습니다.

Character Set Casting

SubQuery 또는 Join 조건으로 지정된 컬럼들이 서로 다른 Character Set으로 설정이 되어있다면 MySQL은 데이터 비교를 위해 Character Set 변환이 발생할 수 있습니다.

따라서 관계를 맺는 컬럼은 동일한 Character Set을 사용하는 것이 좋습니다.

예시) A 테이블의 code와 B 테이블의 ref_code가 다른 Character Set으로 지정된 상태에서 B.ref_code IN (SELECT code FROM A ...) 와 같이 사용할 경우 Character Set 캐스팅이 발생하면서 조회 비용이 증가할 수 있습니다.

Collation

Collation은 Character Set에 대해서 비교 값이나 정렬 순서를 정의한 규칙을 의미합니다.

지금 이 글을 읽고 계신 분에게 "숫자 1은 숫자 5보다 작은게 맞아?"라고 물어본다면, 여러분은 "숫자 1은 숫자 5보다 작은게 맞지!" 라고 바로 대답을 할 수 있을겁니다.

하지만 "문자열 A는 문자열 B보다 작은게 맞아?"라고 물어본다면 여러분은 바로 대답을 하실 수 있으신가요?

개발을 모르는 일반 사람들은 쉽게 대답을 하지 못할 것이고, Ascii 코드를 아는 사람이라면 A와 B를 Ascii 코드로 치환해서 비교를 할 수도 있고, 이 내용을 알고 계신 분들이라면 "Collation 설정에 따라 다르겠지" 라고 생각하실 수 있을겁니다.

이렇게 문자열에 대한 비교는 주체가 누구냐에 따라 기준이 다르기 때문에 쉽게 비교를 할 수 없는 상황이 펼쳐집니다.

MySQL은 이러한 상황을 방지하기 위해 Collation을 기준으로 문자열을 정렬하거나 비교하게 됩니다.

Collation 이름 규칙

자세한 내용은 MySQL 문서를 참고해주세요.

Bin

바이너리 비교를 수행하는 Collation 입니다.

대소문자를 구분하고, 각 문자의 바이너리 값으로 비교, 정렬을 수행합니다.

utf8mb4_bin 과 같은 이름을 가진 Collation을 의미합니다.

AI (Accent Insensitive)

악센트를 무시하고 비교하는 Collation 입니다.

악센트(예: é, è, ê 등)에 대해서 같은 비교 값을 가지기 때문에 eat와 êat는 같은 문자열로 취급합니다.

한글의 경우 가와 ㄱㅏ를 같은 문자열로 취급합니다.

AS (Accent Sensitive)

악센트를 구분하여 비교하는 Collation 입니다.

악센트(예: é, è, ê 등)에 대해서 다른 비교 값을 가지기 때문에 eat와 êat는 다른 문자열로 취급합니다.

한글의 경우 가와 ㄱㅏ를 다른 문자열로 취급합니다.

CI (Case Insensitive)

대소문자를 구분하지 않고 비교하는 Collation 입니다.

대소문자에 대해서 같은 비교 값을 가지기 때문에 eat와 EAt는 같은 문자열로 취급됩니다.

CS (Case Sensitive)

대소문자를 구분하여 비교하는 Collation 입니다. 대소문자에 대해서 다른 비교 값을 가지기 때문에 eat와 EAt는 다른 문자열로 취급됩니다.

MySQL 기본 Character Set / Collation

MySQL은 버전별로 Default Character Set과 Collation이 다릅니다.

보시다시피 MySQL은 기본적으로 대소문자를 구분하지 않는 Collation을 기본 값으로 사용하고 있습니다.

따라서 대소문자를 구분해야하는 환경에서는 Collation을 꼭! 확인하셔야 합니다.

MySQL에서 지원하는 Collation

# Collation 목록 조회
SHOW COLLATION;

참고 문서

• https://dev.mysql.com/doc/refman/8.0/en/charset.html
• https://dev.mysql.com/doc/refman/8.0/en/charset-collation-names.html
• https://dev.mysql.com/doc/refman/8.0/en/charset-unicode.html
• https://dev.mysql.com/doc/refman/8.0/en/string-type-syntax.html
• https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html
• https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_character_set_database

MySQL 옵티마이저에 대한 내용은 이 글을 확인해주세요.

통계 정보

통계 정보는 MySQL 옵티마이저가 데이터 접근 비용을 정확하게 평가하고 최적의 실행 계획을 선택하는 데 도움을 주는 역할을 합니다.

테이블 통계 정보

mysql.innodb_table_stats

InnoDB 테이블에 대해 테이블 레벨의 통계 정보를 가지고 있습니다.

MySQL 옵티마이저는 Row 수, 테이블의 크기 등을 참고하여 실행 계획을 세울 수 있습니다.

테이블 구조

mysql.innodb_index_stats

InnoDB 테이블에 대해 인덱스 레벨의 통계 정보를 가지고 있습니다.

MySQL 옵티마이저는 인덱스의 크기, 리프 페이지 수 등을 참고하여 실행 계획을 세울 수 있습니다.

테이블 구조

통계 정보 갱신

통계 정보는 ANALYZE TABLE Statement를 통해 갱신할 수 있으며, 관련 옵션에 따라 자동 갱신되는 방식이 달라집니다.

innodb_stats_persistent이 ON 일 때

• 테이블에 컬럼이 추가되거나 삭제된 경우
• 테이블에 인덱스가 추가되거나 삭제된 경우
• 테이블의 레코드가 대량으로 변경(추가, 수정, 삭제)되는 경우 일반적으로 전체 레코드의 10% 정도가 수정되었을 때 갱신되며, innodb_stats_auto_recalc 옵션이 활성화 되어있을 때만 해당됩니다.

참고! SQL 실행 계획이 변경되는 것을 방지하기 위해 innodb_stats_auto_recalc 옵션을 OFF하고, DB 점검하는 시간에 수동으로 Analyze Table 명령으로 관리하는 방법으로 관리하는 곳도 많습니다.

innodb_stats_persistent이 OFF 일 때

• SHOW TABLE STATUS, SHOW INDEX 명령문을 실행했을 경우
• 테이블이 처음 Open 된 경우 (참고 페이지)
• 마지막 통계 업데이트 이후 1/16 정도가 수정됐음이 감지되었을 경우

히스토그램

히스토그램은 MySQL 8.0에서 추가된 기능으로, 특정 테이블 컬럼에 대해서 데이터 분포 정보를 정밀하게 관리를 합니다.

MySQL 옵티마이저는 히스토그램을 참조하여 보다 더 정확한 실행 계획을 세울 수 있습니다.

참고! MySQL 옵티마이저는 Index Dives를 통해 Index로 지정된 컬럼의 데이터 분포를 대략적으로 예측할 수 있습니다.

Index가 걸려있지 않은 컬럼에 히스토그램을 생성하면 정확한 데이터 분포를 알 수 있게 되므로, MySQL 옵티마이저는 효율적으로 실행 계획을 세울 수 있습니다.

히스토그램 확인

생성된 히스토그램은 아래의 SQL 쿼리로 확인 가능합니다.

SELECT * FROM information_schema.COLUMN_STATISTICS;

히스토그램의 단점

히스토그램은 데이터 분포 파악을 위해 테이블의 모든 행을 분석하기 때문에 Full Scan이 발생할 수 밖에 없습니다.

분석 과정에서 CPU 사용량 증가, 디스크 I/O 부하, 쿼리 성능 저하 등이 발생할 수 있기 때문에 사용자가 적은 시간에 수동으로 관리를 해줘야 합니다.

참고 문서

• Real MySQL 8.0 1권: 개발자와 DBA를 위한 MySQL 실전 가이드
• https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-optimizer-statistics.html
• https://dev.mysql.com/doc/refman/8.0/en/innodb-persistent-stats.html
• https://dev.mysql.com/blog-archive/histogram-statistics-in-mysql

MySQL 옵티마이저의 실행 계획에 대한 내용은 이 글을 참고하시면 도움이 됩니다.

EXPLAIN Statement

EXPLAIN Statement는 옵티마이저가 결정한 실행 계획에 대한 정보를 제공합니다.

EXPLAIN Statement를 통해서 사용자의 요구 사항(SQL 명령)을 어떤식으로 처리할지(테이블 조인 순서, 인덱스 사용 유무 등)에 대한 정보를 알 수 있으므로 SQL 최적화를 진행할 때 없어서는 안될 중요한 명령문 중 하나입니다.

MySQL 문서에서 설명하는 EXPLAIN Statement의 사용 방법은 아래와 같습니다.

{EXPLAIN | DESCRIBE | DESC}
    tbl_name [col_name | wild]

{EXPLAIN | DESCRIBE | DESC}
    [explain_type]
    {explainable_stmt | FOR CONNECTION connection_id}

{EXPLAIN | DESCRIBE | DESC} ANALYZE [FORMAT = TREE] select_statement

explain_type

explain_type: {
    FORMAT = format_name
}

format_name: {
    TRADITIONAL
  | JSON
  | TREE
}

explainable_stmt

explainable_stmt: {
    SELECT statement
  | TABLE statement
  | DELETE statement
  | INSERT statement
  | REPLACE statement
  | UPDATE statement
}

EXPLAIN

EXPLAIN은 SQL 명령문을 실제로 실행하지 않고 실행 계획을 확인하는 방법입니다.

EXPLAIN [explainable_stmt]

미리 작성한 SQL 명령의 실행 계획을 확인하는 방법으로, EXPLAIN을 사용할 때 가장 많이 사용하는 방식입니다.

사용 예시는 아래와 같습니다.

EXPLAIN SELECT * FROM [table] WHERE [where]...;

EXPLAIN [FOR CONNECTION connection_id]

현재 연결된 ConnectionID를 전달하여 실행 계획을 확인하는 방법으로, 해당 ConnectionID에서 현재 실행중인 SQL 명령에 대한 실행 계획을 확인할 수 있습니다.

특정 Connection에서 지연이 발생하는 경우 간편하게 실행 계획을 확인할 수 있는 방법 중 하나입니다.

사용 예시는 아래와 같습니다.

EXPLAIN FOR CONNECTION 223;

Format

EXPLAIN 문에서는 TRADITIONAL과 JSON Format만 사용이 가능합니다.

TRADITIONAL

explain_type을 명시하지 않았을 때 사용하는 기본 Format 형식입니다.

응답 구조

[
  {
    "id": 1,
    "select_type": "SIMPLE",
    "table": "naver_land_articles",
    "type": "ref",
    "possible_keys": "naver_land_articles_trad_tp_cd_created_at_index",
    "key": "naver_land_articles_trad_tp_cd_created_at_index",
    "key_len": "1",
    "ref": "const",
    "rows": 33109,
    "Extra": "Using where"
  }
]

JSON

응답 구조

{
  "query_block": {
    "select_id": 1,
    "table": {
      "table_name": "naver_land_articles",
      "access_type": "ref",
      "possible_keys": ["naver_land_articles_trad_tp_cd_created_at_index"],
      "key": "naver_land_articles_trad_tp_cd_created_at_index",
      "key_length": "1",
      "used_key_parts": ["trad_tp_cd"],
      "ref": ["const"],
      "rows": 33106,
      "filtered": 100,
      "attached_condition": "crawler.naver_land_articles.trad_tp_cd <=> 'A1' and crawler.naver_land_articles.trad_tp_cd = 'A1' and crawler.naver_land_articles.region1 in ('경기도','서울')"
    }
  }
}

응답 필드

자세한 응답 필드에 대한 설명은 해당 문서를 참고해주세요.

EXPLAIN ANALYZE [select_statement]

EXPLAIN ANALYZE는 MySQL 8.0.18부터 도입된 기능으로, 쿼리를 실제로 실행하면서 실행 계획과 실행 결과를 확인하는 방법입니다.

EXPLAIN 과는 다르게 구체적인 성능 문제를 진단하는데 사용을 합니다.

요청 SQL문

EXPLAIN ANALYZE SELECT * FROM [table] WHERE [where]...;

Format

EXPLAIN ANALYZE에서는 TREE Format만 사용이 가능합니다.

TREE

응답 구조

-> Sort: orders.created_at DESC  (cost=16.14 rows=43) (actual time=5.157..5.157 rows=0 loops=1)
    -> Filter: (orders.market_code = 'smartstore')  (actual time=5.149..5.149 rows=0 loops=1)
        -> Index lookup on orders using searchRule1 (store_uuid='어쩌구')  (actual time=4.957..5.137 rows=43 loops=1)

참고 문서

• https://dev.mysql.com/doc/refman/8.0/en/explain.html
• https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

통계 정보에 대해서는 이 글을 확인해주세요.

MySQL의 Optimizer

MySQL 옵티마이저는 DB의 성능을 결정짓는 중요한 요소 중 하나로, 사용자가 요청한 SQL 명령을 가장 효율적으로 실행하기 위한 최적의 방법을 찾기 위해 다양한 실행 계획을 세우고 평가합니다.

최적의 실행 계획이 수립되면 쿼리 실행 시간을 단축시키고 시스템 리소스를 절약하는 데 크게 기여합니다.

옵티마이저는 최적의 실행 계획을 평가하기 위해 규칙 기반과 비용 기반 최적화 방식을 사용합니다. 다만 규칙 기반의 최적화는 요즘에는 잘 사용되지 않는 방식이라 해당 글에서 다루지 않습니다.

참고! MySQL 옵티마이저는 모든 상황을 계획하지 않습니다.

그 이유는 실행 계획을 세우는 시간이 길어질 수록 SQL 쿼리 수행 시간에 영향을 끼치기 때문입니다.

MySQL 옵티마이저가 SQL 명령문을 잘 이해하고 최적의 실행 계획을 세울 수 있게 ✨SQL 명령문을 효율적으로 작성하는 것✨이 중요합니다.

Optimizer 동작 제어

다양한 방법을 통해 MySQL 옵티마이저의 동작 방식을 제어할 수 있습니다. 동작 방식 중 자주 사용되는 동작 제어 방식 중 하나인 INDEX 힌트에 대해서

자세한 내용은 문서를 통해 확인할 수 있습니다.

Index 힌트

MySQL 옵티마이저에게 사용하거나 제외할 인덱스 목록을 전달할 수 있습니다.

tbl_name [[AS] alias] [index_hint_list]

index_hint_list:
    index_hint [index_hint] ...

index_hint:
    USE {INDEX|KEY}
      [FOR {JOIN|ORDER BY|GROUP BY}] ([index_list])
  | {IGNORE|FORCE} {INDEX|KEY}
      [FOR {JOIN|ORDER BY|GROUP BY}] (index_list)

index_list:
    index_name [, index_name] ...

USE INDEX

명명된 인덱스 중 하나를 사용하도록 '제안'합니다.

옵티마이저가 명명된 인덱스가 아닌 다른 인덱스가 더 효율적이라고 판단을 하면, 다른 인덱스를 사용하는 방법으로 실행 계획을 수립합니다.

FORCE INDEX

명명된 인덱스 중 하나를 사용하도록 '강제'합니다.

옵티마이저가 명명된 인덱스가 아닌 다른 인덱스가 더 효율적이라 판단을 하더라도 명명된 인덱스 중 하나를 사용하여 실행 계획을 수립합니다.

IGNORE INDEX

명명된 인덱스를 사용하지 않도록 '강제'합니다.

비용 기반 최적화

비용 기반 최적화는 각 실행 계획에 대해 예상 비용을 계산하고, 비용이 적게드는 실행 계획을 선택하는 방식입니다.

옵티마이저는 예상 비용을 계산할 때 통계 정보를 활용하여 실행 계획을 평가합니다.

참고! 통계 정보가 정확하지 않으면 옵티마이저는 실행 계획을 효율적으로 평가할 수 없습니다.

예) 테이블에 100,000건의 데이터가 존재하는데 통계 정보는 갱신되지 않아 10건의 데이터만 있다고 한다면, MySQL 옵티마이저는 Full Scan을 이용하는 방향으로 실행 계획을 세울 수 있습니다.

코스트 모델(Cost Model)

MySQL 옵티마이저가 실행 계획에 대해 예상 비용을 계산할 때 필요한 단위 작업들의 비용을 의미합니다.

MySQL 8.0 기준으로 코스트 모델에서 지원하는 단위 작업은 아래와 같습니다.

engine_cost

레코드를 가진 데이터 페이지를 가져오는데 필요한 비용을 관리합니다.

server_cost

인덱스를 찾고, 레코드를 비교하고, 임시 테이블 처리에 대한 비용을 관리합니다.

참고 문서

• Real MySQL 8.0 1권: 개발자와 DBA를 위한 MySQL 실전 가이드
• https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-optimizer-statistics.html
• https://dev.mysql.com/doc/refman/8.0/en/cost-model.html
• https://dev.mysql.com/doc/refman/8.0/en/switchable-optimizations.html
• https://dev.mysql.com/blog-archive/optimization-to-skip-index-dives-with-force-index/

최종적으로 낙관적 동시성 제어 방식을 활용하여 재고 수량을 초과하여 주문이 되는 문제를 해결하였습니다.

동시성 제어는 순수 MySQL만을 이용해서 제어하는 방법과 Redis 등 Application의 도움을 받아 제어하는 등 다양한 방법과 상황이 존재합니다.

이 글은 MySQL만을 이용해서 동시성을 제어하는 방법에 대해서 정리합니다.

참고! 아래의 예시 플로우차트는... 2018년도에 대충 PPT로 그린 플로우차트입니다. 즉, 레거시한 이미지 입니다...

동시성 제어의 필요성

개발을 하다보면 동시성을 제어해야만 하는 상황이 생깁니다. 대표적으로 상품을 구매했을 때 재고를 차감하는 로직이 그러합니다.

일반적으로 구매자가 상품을 구매하면 아래와 같은 순서로 처리가 이루어집니다.

1. 상품을 구매할 수 있는 상태인지 확인합니다.
2. 구매할 수 있는 상품이라면, 구매자를 주문서 작성 페이지로 이동시킵니다.
3. 구매자가 주문 정보(구매자 정보, 배송지 정보, 할인 수단 등)를 입력 후 결제를 시도합니다.
4. 시스템은 결제 페이지로 넘기기 전에 구매자가 입력한 주문서 정보를 DB에 저장하고, 상품의 재고가 유효한지 확인합니다.
5. 상품의 재고가 유효하면 구매자가 구매한 수량만큼 재고를 차감합니다.
6. 재고 차감이 성공하면 구매자를 결제 페이지(예: PG 화면 등)로 이동시킵니다.
7. 결제가 성공하면 주문이 완료됩니다.

위 과정만 본다면 로직에는 별 문제가 없어보입니다. 하지만 같은 시간에 여러 사용자가 같은 상품을 구매하면 어떻게 될까요?

아래는 재고를 차감하는 로직에 대해서 A, B 사용자가 동시에 요청을 했을 때 발생하는 상황을 나타냅니다.

상품의 재고가 5개만 남아있는 상황에서 A 사용자는 5개, B 사용자는 3개를 구매하기를 원합니다.

이 두 사용자가 같은 시간에 구매를 시도할 경우 A 사용자의 트랜잭션이 재고를 반영하기 전에 B 사용자의 트랜잭션에서 상품의 재고를 조회하기 때문에 A와 B 둘 다 재고가 유효하다고 판단을 하게 됩니다.

따라서 상품의 재고는 실제로 5개밖에 존재하지 않지만 Application 로직의 동시성 문제로 두 사용자 모두 정상적으로 구매가 이루어지게 되며, 상품의 재고는 결과적으로 -3개가 되는 상황이 발생하게 됩니다.

이런식으로 동시성을 제어하지 않은 로직은 의도하지 않은 결과를 초래할 수 있습니다.

동시성 제어 방식

비관적 동시성 제어 (Locking Reads 이용)

비관적 동시성 제어 방식은 MySQL의 잠금을 이용해서 동시성 문제를 해결하는 방법입니다.

잠금이 발생하면 다른 트랜잭션은 잠금이 해제될 때 까지 데이터에 접근할 수가 없으므로 처리량(성능)이 떨어진다는 단점이 있지만, 처리 과정 중 실패나 에러가 발생할 경우 데이터를 Rollback하기가 편하다는 장점이 있습니다.

SELECT ... FOR SHARE

읽기는 허용하되 수정은 불가능하게 하는 잠금 방식입니다.

SELECT ... FOR UPDATE

읽기와 수정 둘 다 불가능하게 하는 잠금 방식입니다.

해당 방식은 UPDATE 쿼리를 날렸을 때와 동일한 잠금 방식입니다.

낙관적 동시성 제어

참고! 일반적으로 MySQL은 트랜잭션과 격리 수준, 그리고 잠금 매커니즘을 사용하여 데이터의 순차성과 일관성을 보장하기 때문에, 동시 다발적으로 UPDATE 쿼리가 실행되어도 문제가 발생하지 않습니다

낙관적 동시성 제어는 MySQL의 잠금을 이용하지 않고, UPDATE 쿼리에 조건을 지정하여 쿼리 성공 유무와 적용된 행의 개수로 동시성을 제어하는 방식으로, 비관적 동시성 제어와 다르게 처리량(성능) 저하가 발생하지 않습니다.

대신 처리 과정에서 실패나 에러가 발생할 경우 데이터를 Rollback 하기가 어렵다는 단점이 있습니다.

아래는 낙관적 동시성 제어에 대한 예시입니다.

1. Update 쿼리 요청을 보냅니다.

    UPDATE TABLE SET stock=stock-3 WHERE stock >= 3; -- 재고가 3개 이상일 때만 차감

2. Application에서 MySQL 서버가 응답한 데이터(쿼리 성공 여부와 적용된 행)를 확인합니다.
3. 만약 쿼리가 성공됐고 적용된 행이 존재할 경우 성공에 관련된 처리를 진행합니다.
4. 만약 쿼리가 실패됐거나, 성공했지만 적용된 행이 존재하지 않을 경우 실패로 간주하고 처리를 합니다.

아래의 글을 참고하시면 이해하시는데 도움이 됩니다.

• Linux에서 Socket과 LocalPort
• PHP-FPM과 LocalPort 문제

Slow Read Attack

참고! TCP Window Size는 패킷을 전송하는 사람이 보낼 수 있는 최대 Size를 의미합니다.

Slow Read 공격은 HTTP 공격의 일종으로 TCP Window Size 등을 조작하여 서버에게 데이터를 천천히 보내고, 응답을 천천히 읽어 TCP 연결을 지연시키는 공격 기법입니다.

공격자는 TCP Window Size 를 작게 조작하고, 데이터 처리율을 감소시킨 상태에서 HTTP 패킷을 송신하여, 웹 서버가 정상적으로 응답하지 못하게 함으로써 Dos 상태를 유발시킵니다.

공격 대상이 된 서버는 공격자와의 데이터 전송이 완료될 때 까지 Connection 자원을 점유하게 되기 때문에, 대량 발생할 경우 Connection 자원이 고갈되어 장애가 발생합니다.

PHP-FPM과 Slow Read Attack

PHP-FPM 특성 상 Slow Read Attack 공격을 받으면 아래의 문제가 발생하게 됩니다.

1. 모든 Worker 프로세스가 해당 공격을 처리하기 위해 사용되면서 정상적인 요청을 처리할 수 없는 상태로 만듭니다.
2. 그리고 외부 서비스와 연결하기 위해 생성된 TCP 소켓으로 인해 LocalPort가 고갈되기 쉽습니다. 이 과정에서 외부 서비스의 Connection도 점유하여 장애를 전파시킬 수 있습니다.

실제 공격이 들어온 사례

``` {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 99.557, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 163.487, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (Android 11; Mobile; rv:68.0) Gecko/68.0 Firefox/82.0"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 78.148, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (Android 11; Mobile; rv:68.0) Gecko/68.0 Firefox/82.0"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 91.221, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (Android 11; Mobile; rv:68.0) Gecko/68.0 Firefox/82.0"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 76.058, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 10_15_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) FxiOS/29.0 Mobile/15E148 Safari/605.1.15"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 85.225, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (iPod; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/86.0.4240.93 Mobile/15E148 Safari/604.1"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 86.266, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (Linux; Android 10; SM-A205U) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.185 Mobile Safari/537.36"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 124.046, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 163.626, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (iPad; CPU OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/86.0.4240.93 Mobile/15E148 Safari/604.1"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 163.414, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/86.0.4240.93 Mobile/15E148 Safari/604.1"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 126.826, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (iPod touch; CPU iPhone 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1"} {"time": "2020-11-08T13:31:48+09:00", "request_host": "http://도메인은비공개.com", "request_uri": "http://도메인은비공개.com/", "body_bytes_sent": 0, "request_time": 163.380, "status": 408, "request": "GET / HTTP/1.1", "request_method": "GET", "referrer": "-", "user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/86.0.4240.93 Mobile/15E148 Safari/604.1"} ...

TCP 통신과 Linux Socket 관련 내용은 여기에서 확인해주세요.

PHP-FPM (PHP FastCGI Process Manager)

CGI (Common Gateway Interface)

웹서버와 외부 프로토콜을 연결시켜주는 표준 프로토콜로서, 기본적으로 Request 요청별로 프로세스를 생성하여 처리하는 방식을 의미합니다.

FastCGI

Request가 발생할 때 마다 프로세스를 생성하여 처리하고, 프로세스를 종료하는 CGI의 단점을 개선한 방식으로, Request 요청을 처리할 프로세스를 미리 만들어두고 재사용하는 방식으로 처리를 합니다.

PHP-FPM

php-fpm은 PHP FastCGI Process Manager의 약자로서, PHP 스크립트를 실행하는 FastCGI 서버로 동작합니다.

php-fpm은 Worker 프로세스를 관리하는 Master 프로세스와 PHP 스크립트를 실행하는 Worker 프로세스로 구분되며, Master 프로세스는 웹 서버(예: Nginx, Apache 등)로부터 FastCGI 요청을 수신받아 Worker 프로세스로 전달하는 역할도 합니다.

참고! php-fpm은 max_children 옵션을 통해 미리 만들어둘 프로세스의 수량을 지정할 수 있습니다. 메모리 누수 등의 문제를 최소화하기 위해 max_requests 옵션도 제공합니다.

그 외 FastCGI 동작에 관련된 많은 설정을 제공하고 있습니다.

PHP-FPM과 LocalPort의 문제

php-fpm은 일반적으로 Server의 역할을 수행하기 때문에 LocalPort를 고갈시키지 않습니다.

하지만 소스 코드 내에 MySQL, Redis 등 외부 서비스로 연결하는 로직이 포함되면 이야기가 달라집니다.

PHP는 MySQL, Redis 등 외부 서비스로 연결하는 과정에서 TCP 소켓을 생성하게 되는데, 이 과정에서 PHP는 커널에게 LocalPort을 요청하게 되고, 이후 외부 서비스와의 연결을 Disconnect하는 과정에서 소켓의 상태를 TIME_WAIT로 변경합니다.

참고! TIME_WAIT 상태를 갖는 소켓은 패킷 유실 등의 처리를 위해 약 1분동안 대기한 다음 연결을 종료하게 됩니다.

여기서 중요한 점은 php-fpm은 Request 단위로 처리를 한다는 점입니다.

만약 1분도 안되는 시간에 트래픽(사용자의 요청)이 급격하게 증가하면 TIME_WAIT 상태를 갖는 소켓으로 인해 리눅스의 LocalPort가 고갈되어 서비스에 장애가 발생할 수 있습니다.

참고! 소켓은 TCP 통신을 위해 생성된 File Descriptor를 의미합니다. 따라서 Process별로 가질 수 있는 File Descriptor 설정에도 영향을 받습니다.

사전 지식

TCP/IP의 4-Tuple

TCP 통신을 위해 사용되는 소켓은 Source IP, Source Port, Destination IP, Destination Port 4개의 Tuple을 기준으로 생성이 됩니다.

예를 들어 MySQL 서버에 연결을 한다고 가정하면, TCP 통신을 위한 소켓의 Header는 아래와 같이 구성됩니다.

Source IP: Client IP
Source Port: Client Port
Destination IP: MySQL 서버 IP
Destination Port: 3306

LocalPort

TCP/IP 프로토콜 스택에서 Port 필드는 16비트의 크기를 가집니다. 하지만 0번 포트는 실제로 사용되지 않기 때문에 1~65535개의 범위를 갖습니다.

따라서 LocalPort는 우리가 일반적으로 알고있는 1~65535까지의 포트를 의미한다고 보시면 됩니다.

Socket

Unix 혹은 Unix 계열의 운영체제(예: 리눅스)에서 Socket은 TCP/UDP 또는 unix 방식 등의 통신을 위해 생성된 File Descriptor를 의미합니다.

그렇기 때문에 File Descriptor 제한에 영향을 받습니다.

TCP 소켓과 LocalPort의 관계

Server

Server는 Client와 통신을 하기 위해 아래의 절차를 거칩니다.

1. socket 생성
2. socket에 IP 주소와 Port를 설정 (bind) 이 단계에서 Server는 생성된 socket에 INADDR_ANY(0.0.0.0)와 지정된 LocalPort 정보를 설정합니다. 만약 bind 하려는 Port가 이미 사용중이라면 에러가 발생합니다.
3. 수신 대기 (listen)
4. 연결 수락 (accept) 이 단계에서 Server는 동시성, 병렬성, 독립성 등의 이유로 해당 Client와 1:1 통신을 위한 Socket을 새로 생성합니다.

Server는 TCP 통신을 위한 소켓 정보(Client 정보와 bind 된 LocalPort)를 이미 알기 때문에 bind 시점에서만 LocalPort를 소비하고, 연결을 수락(accept) 과정에서 생성되는 Socket은 LocalPort를 고갈시키지 않습니다.

Client

Client는 Server와 통신을 하기 위해 아래의 절차를 거칩니다.

1. socket 생성
2. 커널에게 LocalPort를 요청합니다. socket을 생성하는 시점의 Client는 Source Port을 알지 못합니다. 그렇기 때문에 Client는 커널에게 사용 가능한 LocalPort를 요청하여 배정받아야 합니다. 이 단계에서 Client는 LocalPort를 소비하게 됩니다.
3. socket에 Source IP, Port와 Destination IP, Port를 설정합니다.
4. TCP 통신을 시작합니다. (connect)

Client는 Server와의 통신을 위해 고유한 LocalPort를 사용해야 하기 때문에 LocalPort와 Socket은 1:1 관계를 가집니다. 따라서 동시에 통신하는 TCP 소켓이 많아질 수록 소비하는 LocalPort도 많아집니다.

TIME_WAIT

Socket이 TIME_WAIT 상태를 가지면 일정 시간동안 LocalPort를 반환하지 않고 점유하기 때문에 TCP 소켓 생성이 잦은 Client는 LocalPort 고갈 또는 리소스 부족으로 장애가 발생할 수 있습니다.

TCP 통신에서 연결 종료 절차는 아래와 같습니다.

1. 송신자가 수신자에게 FIN 메세지를 보냅니다.
2. 수신자는 송신자에게 ACK 메세지를 보냅니다.
3. 수신자는 송신자에게 FIN 메세지를 보냅니다.
4. 송신자는 수신자에게 ACK 메세지를 보냅니다.

위 4번 단계에서 수신자는 송신자가 보낸 ACK 메세지를 받지 못하는 상황이 생길 수 있습니다.

이러한 문제를 해결하기 위해 송신자의 Socket은 TIME_WAIT 상태를 가지고 일정시간을 대기한 다음에 연결을 종료합니다.

지금까지 개발을 하면서 직접 경험한 내용을 바탕으로 공부하고 알게된 지식을 정리하는 글입니다.

Foreground Thread

MySQL은 프로세스 기반이 아닌 스레드 기반으로 작동하며, 일반적으로 Foreground Thread와 Background Thread로 구분을 합니다. (Background Thread는 이 글에서 다루지 않습니다.)

Client가 MySQL 서버에 연결을 요청하면 MySQL 서버는 해당 요청을 Connection Requests 대기열에 추가를 합니다. 그리고 Receiver Thread는 이러한 요청을 순차적으로 소비하면서 각 Client의 요청을 처리해줄 Thread를 생성합니다.

참고! 과거에는 Thread를 생성하고 삭제할 때 발생하는 비용이 컸기 때문에 이러한 오버헤드를 줄이고 성능을 향상시키기 위해 Thread Cache를 이용하여 Thread를 관리했습니다.

그러나 요즘에는 Thread를 생성하고 삭제할 때 발생하는 비용이 저렴해져 Thread Cache를 레거시로 보고 있습니다.

이렇게 생성된 Thread는 MySQL 앞단에서 Client와 통신을 하기 때문에 Foreground Thread라고 불립니다. 그렇기 때문에 일반적으로 Foreground Thread는 MySQL 서버에 연결된 Client 수 만큼 존재하게 됩니다.

MySQL Connection

MySQL에서 Connection은 Client가 MySQL 서버에 접속해서 데이터를 주고 받는 통신 세션을 의미합니다.

Threads_connected

MySQL 서버에서 현재 연결중인 Connection의 수를 확인하는 방법은 현재 활성화된 Foreground Thread의 갯수를 확인하는 방법입니다.

따라서 아래와 같이 현재 활정화된 Thread의 수를 확인하여 현재 연결중인 Connection의 수를 확인할 수 있습니다.

SHOW STATUS LIKE 'Threads_connected';

max_connections

max_connections는 MySQL 서버에서 동시에 연결할 수 있는 Client의 수를 제한하는 옵션입니다.

참고! max_connections의 최대값은 아래의 요인에 따라 달라질 수 있습니다.

• 특정 플랫폼의 스레드 라이브러리 품질
• 사용 가능한 RAM의 양
• 각 연결에 사용된 RAM의 양
• OS에서 사용가능한 File Descriptor의 Limit
  그리고 AWS RDS의 경우 DBInstanceClassMemory에 비례하여 max_connections의 기본값이 설정됩니다.

MySQL 서버는 위에서 언급한 Receiver Thread에서 연결 요청을 처리하는 과정에서 현재 연결된 connection 수와 max_connections 설정의 값을 참조하여 Thread를 생성할지, 아니면 Too many connections 에러를 응답할 것인지 결정하게 됩니다.

max_connections와 DB 관리자와의 관계

MySQL 서버는 모니터링 및 장애 조치를 위해 CONNECTION_ADMIN 권한을 가진 유저가 접속할 수 있도록 max_connections 값에서 +1 만큼의 여유 Connection을 미리 확보합니다.

그렇기 때문에 Too many connection 에러가 발생하는 상황에서도 CONNECTION_ADMIN 권한을 가진 계정으로 MySQL 서버에 접속을 할 수 있습니다.

만약 Too many connection 에러가 발생하는 상황일 때 MySQL 서버에 접속이 불가능하다면 CONNECTION_ADMIN 권한이 없거나 누군가가 이미 접속을 하고 있다고 볼 수 있습니다.

복제를 위한 내부 세션(Connection)과 max_connections의 관계

MySQL 8.0.18 버전까지는 복제를 위한 내부 세션(Connection)도 max_connections 제한에 포함이 되었습니다. 그렇기 때문에 Too many connections 에러가 발생하는 상황에서 복제 작업이 동작하면, 해당 작업이 실패되는 상황이 발생했습니다.

다행히도 MySQL 8.0.19 버전부터는 복제를 위한 내부 세션(Connection)은 max_connections 제한에 포함되지 않도록 변경되었습니다.

max_connections와 OS File Descriptor

파일 디스크립터(File Descriptor) 유닉스 및 유닉스 계열 운영체제(예: 리눅스)에서 파일이나 입출력 장치를 식별하는데 사용되는 정수(Integer) 값으로, 프로세스가 파일이나 파이프, 소켓 등 다양한 입출력 자원과 상호작용할 수 있게 해주는 역할을 가지고 있습니다.
아래에서 말하는 Open은 운영체제(커널)의 open 함수를 통해 ibd 파일을 열어서 File Descriptor를 반환받는 행위를 말합니다.

MySQL은 세션(Connection)별로 각기 다른 상태(트랜잭션이나 상태, 락, 캐시, user 권한 등)를 가짐으로써 발생되는 문제를 최소화하기 위해서 테이블에 접근할 때 세션(Connection)별로 테이블을 열게끔 설계가 되어있습니다.

Client가 MySQL로 CRUD SQL을 요청하면 Foreground Thread는 해당 요청을 처리하기 위해 관련이 있는 테이블의 ibd 파일을 Open하게 됩니다.

즉, N개의 세션(Connection)들이 동일한 테이블로 CRUD 요청에 해당하는 SQL 명령을 요청하게되면 동일한 ibd 파일을 N번 열게되면서 N개의 File Descriptor가 생성됩니다.

이 과정에서 MySQL 프로세스가 가질 수 있는 File Descriptor의 제한을 초과하게 되면 장애가 발생할 수 있습니다.

MySQL은 이러한 문제를 방지하기 위해서 아래의 설정을 제공하고 있습니다.

• open_files_limit 테이블, 로그 등을 포함하여 MySQL이 동시에 가질 수 있는 File Descriptor의 수를 지정할 수 있습니다.
• table_open_cache 한 번 Open된 테이블의 파일 핸들러를 캐시 레이어에 저장하여, 이후 동일한 테이블에 접근할 때 발생되는 오버헤드(디스크 I/O 등)를 줄임으로써 성능을 향상시킬 수 있습니다. 이 변수는 캐시 레이어에 캐싱할 파일 핸들러의 개수를 설정할 수 있습니다.

참고 문서

• https://dev.mysql.com/blog-archive/mysql-connection-handling-and-scaling/
• https://dev.mysql.com/doc/refman/8.0/en/connection-management.html
• https://dev.mysql.com/doc/refman/8.0/en/table-cache.html
• https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_open_files_limit
• https://man7.org/linux/man-pages/man2/open.2.html

장애 리포팅

2024년 5월 17일 16시 46분. CS팀으로부터 장애 리포팅이 들어옵니다.

"지금 API 호출이 안 되고 있습니다." "504 Gateway Timeout이 발생하고 있어요"

17시 15분까지 미팅이 있었던 저는 30분이 지난 17시 16분에 해당 내용을 식별하게 되었고, TL분께서 저한테 현재 상황을 공유해 주셨습니다.

"현재 모든 고객사의 API 호출이 불가능한 상태이고, Argo에서 각 서비스 Pod의 로그를 확인했을 때 별다른 문제가 확인되지 않습니다. 관련해서 디깅 좀 해주시겠어요?"

해당 내용을 전달받은 저는 AWS 서비스의 상태를 확인하기 시작합니다. 그리고 AWS Aurora MySQL 인스턴스 중 하나의 CPU가 99%까지 올라가 있는 것을 확인하게 됩니다.

그리고 저는 아래의 내용을 채널에 공유하게 됩니다.

"저희 운영 DB가 죽은 것 같습니다."

원인 분석

운영 DB 인스턴스의 장애를 공유하자마자 바로 MySQL에 접속을 시도했습니다. CPU 수치가 최대치에 도달한 걸로 봐서는 Slow Query가 존재할 것이라 생각했기 때문입니다.

하지만 다급했던 저의 마음을 모르는 것인지 야속하게도 MySQL 인스턴스는 Too Many Connections 에러만 응답하기 시작합니다. ( MySQL Connection에 대한 내용은 여기에서 확인해주세요. )

참고! 이 때 발생한 Too many connection 에러는 해당 장애와는 무관했습니다.

서비스 초기 단계여서 사양이 낮은 DB 인스턴스를 사용하게 되었는데, MSA 방식을 "일부" 도입하게 되면서 개발되는 앱의 갯수가 늘어났고, 앱 마다 일정 수의 Connection Pool을 확보하게 되면서 Connection 수치가 max_connections 에 도달해서 발생하던 문제였습니다.

이때 저는 아래의 고민을 하기 시작합니다.

1. MySQL CPU가 최대치로 도달했으니 재부팅을 요청한다.
2. max_connections 값에 대해서 상향 조정을 요청한다.

잠깐의 고민을 마치고 인프라팀 담당자분께 2번 내용으로 요청을 했습니다. 그 이유는 아래와 같습니다.

1. 빠른 서비스 정상화를 위해 재부팅을 하는 것이 맞으나, 재부팅을 한다 하더라도 동일한 증상이 재현될 것이라 생각했습니다.
2. MySQL 서버가 Too many connections 에러를 응답하는 걸로 봐서는 서버가 완전히 다운되지는 않았다는 것 입니다.
3. 장애가 발생하는 상황에서 MySQL의 서버의 상태와 실행중인 쿼리를 살펴보는 것이 원인을 파악하는데 가장 최적의 상황이라고 생각을 했습니다.
4. 실행 중인 RDS 인스턴스에 연결된 DB 파라미터 그룹에서 동적 파라미터로 지정된 값의 변경은 재부팅 없이 적용됩니다.

위 내용들을 근거로 인프라팀 담당자분에게 max_connections 값을 상향해 달라고 요청을 했습니다. 그 후 상향 조정된 값이 적용되자마자 MySQL 인스턴스에 접속하여 ProcessList를 확인했습니다.

SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' ORDER BY TIME;

하지만 예상과는 다르게 조회되는 Slow Query는 존재하지 않았습니다. 당연하게도 RDS 로그 및 이벤트 탭의 slowquery.log 파일에도 기록된 Slow Query는 존재하지 않았습니다.

예상했던 문제가 장애의 원인이 아니라는 것을 확인하자마자 더이상 지연시키지 않고 서비스 정상화를 위해 인프라팀 담당자분에게 인스턴스 재부팅을 요청하게 됩니다. (재부팅 후 DB 인스턴스가 정상화되었으나, 예상했던대로 원인을 해결할 때까지 장애가 지속적으로 발생했습니다.)

원인 분석2

인프라팀에게 DB 인스턴스 재부팅을 요청드린 다음 저는 여러가지 로그 파일들을 확인하기 시작했고, 다음과 같이 이상한 부분을 발견할 수 있었습니다.

1. audit.log의 비정상적인 패턴 audit.log 파일의 파일명은 보통 .1로 끝나는데 1000번대까지 생성이 되어있습니다.

2. general.log.spillover 파일 기록

3. mysql-general.log 파일이 no space left on device 에러로 적재되지 않고 있다는 점

참고! no space left on device 에러는 인스턴스에 저장 공간이 부족할 때 발생하는 에러입니다.

이러한 에러가 발생하고 있는 것이 의심스러워 모니터링 지표를 살펴보기 시작합니다.

Amazon Aurora CloudWatch 지표 설명에서 FreeLocalStorage 항목을 아래와 같이 설명하고 있습니다.

사용 가능한 로컬 스토리지 양입니다.

다른 DB 엔진과 달리 Aurora DB 인스턴스의 경우, 이 지표는 각 DB 인스턴스에 사용 가능한 스토리지 크기를 보고합니다. 이 값은 DB 인스턴스 클래스에 좌우됩니다(요금에 대한 자세한 내용은 Amazon RDS 요금 페이지 참조). DB 인스턴스 클래스를 큰 것으로 선택하면 인스턴스의 여유 스토리지 공간을 늘릴 수 있습니다. (Aurora Serverless v2에는 적용되지 않습니다.)

정리를 하면 어떠한 이유로 DB 인스턴스의 LocalStorage 용량을 고갈시키면서 장애가 발생했고, AWS는 이러한 인스턴스를 FailOver 처리 하면서 다시 정상화되고, 다시 LocalStorage 용량을 고갈시키면서 장애가 발생, 다시 재부팅... 이러한 현상이 며칠동안 지속되고 있었습니다.

제일 먼저 해당 패턴이 언제부터 시작됐는지 식별하기 위해 FreeLocalStorage 지표의 범위를 더욱 늘려서 확인을 합니다.

지표 상으로 해당 장애는 5월 15일 새벽 2시부터 발생하기 시작했다는 것을 알 수 있습니다. 그리고 이를 기반으로 서비스에 영향이 갈만한 부분들을 검토하기 시작합니다.

1. MySQL이 LocalStorage 용량을 어떠한 상황에서 사용하는지. → 각종 Logging과 가상 테이블 및 임시 테이블을 위해 사용됩니다.

2. 5월 13일(월요일)부터 문제가 발생한 시점인 5월 17일(목요일) 사이에 배포된 기능이 있는지. → Jenkins 히스토리와 Argo에서 발견된 배포 기록은 찾을 수 없었기 때문에 서비스 배포의 문제는 아니었습니다.

3. 데이터가 쌓이면서 SQL 실행 동작이 변경되면서 가상 테이블을 사용하는 케이스가 늘었는지. MySQL에 설정된 메모리 용량을 over 하면 디스크에 기록하게 되면서 LocalStorage 용량을 소비할 수 있습니다. 그러나 이 부분에 대해서도 별다른 이상함을 찾지 못했습니다. (이 부분을 확인하기 위해 리서치하고 공부했던 내용은 추후 게시글로 작성할 예정입니다.)

4. 그 외 우리가 모르는 문제가 생겼는지. (AWS 문제 등)

처음으로 돌아가서...

여러가지의 가능성을 열고 살펴봤음에도 별다른 문제를 찾지 못했습니다. 그래서 AWS의 문제일 수 있다는 가정을 가지고 처음으로 되돌아가서 확인하기 시작합니다.

RDS 로그 및 이벤트 탭의 audit.log 파일의 패턴을 보면 파일이 비정상적으로 대량 생성되고 있었습니다.

이 부분에 대해서 AWS Case를 열어볼까 고민하며 리서치를 하던 중 아래의 문서를 발견하게 됩니다. ( Aurora MySQL 데이터베이스 엔진 업데이트 2024-03-15 (버전 3.04.2, MySQL 8.0.28과 호환) )

가용성 향상:

• Aurora 스토리지와 통신하는 구성 요소의 결함으로 인해 Aurora MySQL 작성기 DB 인스턴스가 장애 조치될 수 있는 문제를 수정했습니다. 이 결함은 소프트웨어 업데이트 이후 DB 인스턴스와 기본 스토리지 간의 통신이 중단되어 발생합니다.
• 감사 로깅 스레드로 인해 발생하는 잠금 경합에 따라 CPU 사용률이 높아지고 클라이언트 애플리케이션 제한 시간이 초과될 수 있는 문제를 해결했습니다.

• 일반적인 개선 사항:*
• 다운로드 또는 로테이션 시 로그 파일에 액세스 할 수 없고 경우에 따라 CPU 사용량이 증가할 수 있는 감사 로그 파일 관리 관련 문제를 수정했습니다.

현재 저희가 사용 중인 인스턴스의 엔진 버전은 8.0.mysql_aurora.3.04.1으로 위 문제가 발생할 수 있는 버전이었습니다.

해당 문서의 내용을 토대로 MySQL의 Logging을 전부 비활성화하니 관련 이슈가 더 이상 발생하지 않았습니다.

그리고 이 내용을 공유하면서 장애 관련 조치는 일단락되었습니다. 추후 인프라팀에 Aurora MySQL 엔진 업그레이드를 요청한 다음 로그를 다시 활성화시켜 볼 예정입니다.

읽어주셔서 감사합니다.