suyeonme

Kustomize, ArgoCD에 대해서 알아보기

suyeonme — Sun, 29 Sep 2024 15:04:47 +0900

ArgoCD란?

GitOps 방식으로 어플리케이션의 상태를 관리하고 배포하는 도구로, 코드 변환에 따라 자동으로 쿠버네티스 리소스를 관리한다.

예를 들어, git commit hash 또는 git tag가 변경된 경우 자동(또는 수동)으로 이를 감지하고 배포하게 된다.

Kustomize란?

Kubernetes 리소스를 템플릿 없이 선언적으로 관리할 수 있게 해주는 도구이다. ArgoCD와 Kustomize를 함께 사용해서 쿠버네티스 리소스 정의 파일을 렌더링하고 손쉽게 클러스터에 배포할 수 있다.

1) Application 리소스 정의

ArgoCD가 어떤 Git 레포지토리와 브랜치를 추적하고, 어떤 Kustomize를 사용하고 어플리케이션을 어떤 네임스페이스에 배포할지 정의해야한다.

apiVersion: argoproj.io/v1alpha1
kind: Application # 어플리케이션 정의
metadata:
  name: [어플리케이션 이름]
  namespace: argocd
spec:
  project: default
  source:
    repoURL: [레포지토리 주소]
    targetRevision: HEAD
    path: [Kustomize 설정 파일이 위치한 경로]
    kustomize:
      namePrefix: [이름에 사용할 prefix]
  destination:
    server: [Kubernetes API 서버]
    namespace: [리소스가 배포될 네임스페이스]
  syncPolicy:
    automated:
      prune: true # 필요없는 리소스 제거
      selfHeal: true

2) Kustomize 설정 정의 (Kustomization.yaml)

ArgoCD가 지정된 경로에서 Kustomize로 어플리케이션 리소스를 생성하는 파일

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: [모든 리소스를 배포할 네임스페이스]

# 리소스 파일 목록
resources:
- deployment-front.yaml
- deployment-server.yaml
...

# 도커 이미지를 새버전으로 치환
images:
- name: [이미지 이름]
  newName: [이미지 이름]
  newTag: 2.0.0
  ...

3) 리소스별 설정

# Service 정의
apiVersion: v1
kind: Service
...

# Gateway 정의
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
...

# VirtualService 정의
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
...

deployment

파일에 정의된대로 어플리케이션의 인스턴스를 생성한다.

Gateway

Istio의 리소스로, 클러스터 외부의 트래픽을 수신한다. (트래픽을 적절한 서비스로 라우팅)
HTTP, HTTPS, TCP 트래픽을 관리하며, 특정 port를 리스닝해서 트래픽을 적적한 서비스로 라우팅

VirtualService

Istio의 리소스로, 트래픽 라우팅 규칙을 정의한다.
Gateway와 함께 사용되며 트래픽이 클러스터 내부로 들어온 후, 어떤 서비스로 라우팅될지 결정한다.

Istio란?
MSA를 관리하고 보호하기위한 오픈소스 Service Mesh 플랫폼 마이크로 서비스간의 통신을 제어/추적/보안/인증등의 기능을 제공해서 어플리케이션의 가용성/안정성/보안을 강화한다.

Service(SVC)

Kubernetes 리소스로 Pod의 고정 네트워크 엔드포인트를 제공한다. (로드밸런싱, 서비스 디스커버리 지원)

gRPC, gRPC-gateway란?

suyeonme — Fri, 19 Jul 2024 22:00:29 +0900

gRPC란?

gRPC (gRPC Remote Procedure Call)는 Google에서 개발한 언어에 상관없이 사용할 수 있는 고성능 PRC 프레임워크이다. 특히 마이크로서비스 아키텍처에서 많이 사용된다.

https://grpc.io/img/landing-2.svg

gRPC 특징

HTTP/2 기반으로 동작한다. HTTP/2의 멀티플렉싱 기능을 통해 하나의 커넥션에서 동시에 여러 요청과 응답을 처리할 수 있다. 따라서 네트워크 성능이 향상되고, 지연 시간이 줄어든다.
Protocol Buffer(Protobuf)를 데이터 직렬화 포맷으로 사용한다. Protobuf는 데이터 구조를 컴팩트하게 직렬화하며, JSON보다 더 빠르고 효율적인 직렬화와 역직렬화를 제공한다. (전송속도 향상 및 대역폭 절약)
다양한 언어 지원
클라이언트와 서버 간의 양방향 스트리밍을 지원한다. 따라서 실시간 데이터 전송에 유용하다.

HTTP/2의 특징

Binary Protocol을 사용해서 데이터를 전송한다. 따라서 데이터의 직렬화와 파싱이 효율적이다.
Multiplexing: 하나의 TCP 연결에서 여러 요청과 응답을 동시에 처리할 수 있다. 따라서 네트워크 효율성을 향상시키고 요청 및 응답간의 지연시간을 줄인다.
HPACK: HPACK이라는 헤더 압축 알고리즘을 사용해서 요청과 응답 헤더를 압축한다. 헤더의 중복을 줄이고 전송 데이터의 크기를 줄여 네트워크 대역폭을 절약한다.
Server Push: 서버가 클라이언트의 요청을 예상하고 필요한 리소스를 클라이언트에게 미리 전송할 수 있다.

RPC(Remote Procedure Call)란?

RPC는 네트워크를 통해 다른 컴퓨터에서 프로시저(함수)를 호출할 수 있게 해주는 프로토콜로, 분산 시스템에서 서로 다른 프로세스 간에 통신을 가능하게 해준다.

마이크로서비스 아키텍처의 경우, 각 서버는 다양한 언어로 개발될 수 있다. PRC를 사용하면 언어에 상관없이 원격에 있는 프로시저를 로컬 메서드처럼 호출할 수 있다.

gRPC 구성요소

Stub

gRPC의 클라이언트와 서버 간의 인터페이스를 정의하고 구현하는 역할을 한다.

클라이언트 Stub: 클라이언트에서 원격 프로시저를 호출하는 데 사용되는 객체이다. 해당 stub으로 서버의 메서드를 로컬 메서드처럼 호출할 수 있다.
서버 Stub: 서버 측에서 클라이언트의 요청을 처리하는 데 사용되는 객체입니다. 해당 stub으로 클라이언트의 요청을 수신하고, 적절한 로직을 수행하여 응답을 클라이언트에게 반환합니다.

Protocol Buffer(Protobuf)

데이터 구조를 정의(Interface Definition Language, IDL)하고, 이 구조에 따라 데이터를 직렬화하고 역직렬화한다. Protobuf는 다양한 프로그래밍 언어와 플랫폼에서 사용될 수 있는 데이터를 정의하는 방법을 제공한다.

Protobuf는 protoc(Protobuf 컴파일러)를 이용해서 .proto 파일을 기반으로 다양한 프로그래밍 언어에 맞는 소스 코드를 자동으로 생성한다.

직렬화: 바이트 스트림으로 변환
역직렬화: 바이트 스트림을 원래 구조로 복원
.proto 파일: 데이터 구조와 메시지 형식을 정의

# proto file
syntax = "proto3";

// 메시지 정의
message Person {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

// RPC 서비스 정의
service ExampleService {
  rpc GetPerson (PersonRequest) returns (Person);
}

// 요청 메시지 정의
message PersonRequest {
  int32 id = 1;
}

gRPC-gateway란?

gRPC 서버와 HTTP/JSON API 간의 브릿지 역할을 하는 도구이다. Protocol Buffers 문서를 기반으로 gRPC 서버에서 정의된 메서드를 HTTP/JSON API로 자동 변환하여, RESTful API와 gRPC를 동시에 제공한다.

클라이언트가 RESTful(HTTP/JSON) API로 서버에 요청하면 gRPC-gateway가 해당 요청을 gRPC로 변환한다. 따라서 gRPC 서버와 REST 클라이언트간의 통신이 가능해진다. -> gRPC는 Protocol Buffer를 사용해서 데이터를 직렬화하기 때문에 직접 HTTP/JSON 요청을 보낼 수 없기때문!

[Python] 의존성 충돌과 가상환경(venv)

suyeonme — Sun, 14 Jul 2024 18:24:55 +0900

의존성 충돌

하나의 컴퓨터에서 Python으로 개발된 여러 개의 프로젝트 돌리는 경우, 의존성이 충돌할 수 있다.

프로젝트 1: package v3.x 사용
프로젝트 2: Django v4 사용

이유

두 개의 프로젝트가 동일한 컴퓨터에 설치된 하나의 파이썬 실행 환경(runtime)을 사용하므로, 파이썬 패키지를 서로 공유하게 되기 때문에 의존성이 충돌할 수 있다.

pip 패키지 매니저의 동작 방식

파이썬은 기본적으로 패키지 설치시 pip을 사용하는데 시스템 전역으로 패키지를 설치한다.

pip으로 패키지 설치시, 컴퓨터의 site-packages 디렉터리에 안에 설치된다.
npm이나 maven의 경우, 패키지 매니저가 프로젝트별로 패키지 설치를 지원 (의존성이 충돌하지않음)

pip 명령어

pip -V

pip install [pacakge]
pip install [pacakge]==2.28.0 # 특정 버전 설치
pip show requests # 설치된 패키지 확인
pip uninstall [pacakge]
pip list # 컴퓨터에 설치된 전체 패키지 확인

requirements.txt

프로젝트에서 개발하기 위해서 필요한 모든 패키지의 목록을 저장한 파일이다.

# 현재 가상 환경에서 설치된 패키지 목록을 requirements.txt 파일로 저장
pip freeze > requirements.txt

# 의존성 다운로드
pip install -r requirements.txt

가상환경(venv)

프로젝트별로 독립적인 Python 실행 환경을 생성하여, 각 프로젝트마다 필요한 패키지들을 격리된 상태에서 관리할 수 있게한다.

venv 내장 모듈을 통해서 쉽게 가상 환경을 만들 수 있으며, 이를 통해 프로젝트 간 의존성 충돌 문제를 예방할 수 있다.

가상환경을 사용하지 않는다면?

컴퓨터 내의 모든 프로젝트에서 하나의 파이썬 실행 환경을 사용하면서 동일한 경로에 패키지를 설치하고 서로 공유한다. 따라서 하나의 프로젝트에서 설치한 패키지의 버전이 다른 프로젝트에서 설치한 동일 패키지의 다른 버전과 충돌할 수 있다.

가상환경 사용하기

가상 환경이 활성화된 상태에서 패키지를 설치하면, .venv 디렉터리 내부에 해당 패키지가 설치된다. 따라서 다른 파이썬 프로젝트에 영향을 미치지않는다.

cd [directory]

# 가상환경 생성
python -m venv .venv
# 가상환경 활성화
source .venv/bin/activate
# 가상환경 비활성화
deactivate

# gitignore에 가상환경 파일 추가해서 사용!

데이터 파이프라인이란?

suyeonme — Fri, 12 Jul 2024 10:54:04 +0900

데이터 파이프라인

Raw 데이터를 정보(information)로 변환하기 위해 데이터 처리 단계를 거치는 시스템을 의미한다.

https://www.altexsoft.com/media/2020/03/etl_pipeline.png

일반적으로 아래의 과정으로 나타낼 수 있다.

데이터 수집(Ingestion): 다양한 형식의 raw 데이터를 수집하고 파이프라인으로 가져오는 단계
데이터 처리(Processing): 수집된 데이터를 정제, 변환, 집계, 필터링등 필요한 형태로 가공하는 단계로, ETL(Extract, Transform, Load) 또는 ELT(Extract, Load, Transform)등의 과정을 포함한다.
데이터 저장(Storage): 처리된 데이터를 저장하는 단계로, 데이터베이스, 데이터 웨어하우스, 데이터 레이크등의 저장소에 저장한다.
데이터 분석(Analysis): 저장된 데이터를 분석하여 인사이트를 도출하는 단계로, 데이터 시각화도구, 통계 분석, 머신러닝등을 사용한다.
데이터 소비(Consumption): 분석된 데이터를 사용자나 시스템이 최정적으로 활용하는 단계로, 보고서, 대시보드, 애플리케이션, API등을 통해서 데이터를 제공한다.

데이터 파이프라인 관리 도구

데이터 파이프라인을 효율적으로 관리하는데 사용되는 주요 도구들을 정리해봤다.

CDC, Change Data Capture

데이터베이스에서 발생하는 변경사항을 캡쳐해서 다른 시스템에 실시간으로 적용하는 기술로, 데이터를 실시간으로 동기화하는데 사용된다.

데이터베이스의 변경사항을 실시간으로 분석 시스템으로 전송, 실시간 데이터 스트리밍
Kafka 기반의 Debezium, DMS(Amazon Database Migration Service), Oracle GoldenGate등

Airflow (Apache)

복잡한 데이터 파이프라인을 정의하고, 스케줄링하며, 모니터링할 수 있는 워크플로우 관리 플랫폼이다.

DAG(Directed Acyclic Graph)를 사용하여 작업의 의존성을 정의한다.

데이터 파이프라인의 오케스트레이션, 스케줄링 및 모니터링
ETL(Extract, Transform, Load) 파이프라인 관리, 데이터 처리 워크플로우 자동화

DAG(Directed Acyclic Graph)란?

DAG is a collection of all the tasks you want to run, organized in a way that reflects their relationships and dependencies.

Airflow의 DAG

Google BigQuery

Google Cloud Platform에서 제공하는 데이터 웨어하우스(Data Warehouse)로, 대규모 데이터 분석과 실시간 데이터 쿼리에 최적화되어있다.

데이터 웨어하우스(Data Warehouse)란?

다양한 소스에서 수집한 대량의 데이터를 저장하고 분석하는 데 최적화된 중앙 저장소이다. 주로 데이터 분석 분야에서 많이 사용된다.

실시간 데이터 분석, SQL 지원, 분산 처리 아키텍쳐로 높은 성능 제공, 데이터 로딩 및 내보내기(CSV, JSON등)

Superset (Apache)

다양한 데이터 소스에서 데이터를 가져와 시각화 대시보드를 만들고 공유해주는 데이터 시각화 도구이다.

데이터 분석 결과 시각화

https://superset.apache.org/

Spark (Apache)

대규모 데이터를 효율적으로 처리하고 다양한 데이터 소스와 통합할 수 있는 기능을 제공하는, 빅 데이터 처리를 위한 분산 처리 프레임워크이다. 메모리 내에서 데이터를 처리하여 디스크 기반 처리보다 빠르다.

대규모 로그 파일, 이벤트 데이터, 데이터 웨어하우스 데이터 등을 분산 처리하여 집계 및 분석 (웹 로그 분석, 대규모 트랜잭션 데이터 처리), 실시간 데이터 처리, 머신러닝

Celery

분산 작업 큐 시스템으로, 비동기 작업을 예약하고, 큐에 넣고, 작업을 처리한다. 주로 백엔드에서 긴 시간 동안 실행되는 작업을 비동기적으로 처리할 때 사용한다.

데이터 파이프라인의 특정 작업을 병렬로 실행, 데이터 갱신

각 도구가 사용되는 흐름은 아래와 같이 생각해볼 수 있다.

운영 데이터베이스에 데이터 저장
운영 데이터베이스의 변경사항을 CDC로 캡쳐
CDC로 캡쳐한 데이터를 Airflow가 BigQuery에 적재
BigQuery의 데이터를 Superset으로 시각화 및 분석

Makefile이란?

suyeonme — Sun, 7 Jul 2024 22:57:08 +0900

Makefile이란?

Makefile은 make라는 빌드 자동화 도구에서 사용하는 파일로, 프로젝트를 빌드, 테스트, 배포하는 작업을 자동화하는 데 사용되는 파일이다. Python, C언어, Java등 다양한 언어에서 사용한다.

최근에 프론트엔드는 Next.js, 서버는 Python으로 구성된 모노레포 프로젝트를 보다가 Makefile을 발견했다.

Makefile은 Java에서는 Maven이나 Gradle, Javascript에서는 NPM script등의 빌드 도구로 대체할 수 있다.

Makefile 구성

Target: 빌드할 파일 또는 수행할 작업의 이름
Dependency: 타겟이 의존하는 파일이나 타겟, 종속성이 변경되면 타겟을 다시 빌드함
Command: 타겟을 빌드하기 위해 수행할 명령
.PHONY: make 명령이 실행되는 디렉토리에 Makefile의 target과 같은 이름의 파일이 존재할 경우에 충돌이 발생하는데 .PHONY에 명시하여 회피할 수 있다.

예를 들어, 코드를 포매팅하고 싶다면 make format을 입력하면 된다.

# 변수 정의
VENV = venv
PYTHON = $(VENV)/bin/python
PIP = $(VENV)/bin/pip
BLACK = $(VENV)/bin/black
FLAKE8 = $(VENV)/bin/flake8
PYTEST = $(VENV)/bin/pytest

# 기본 타겟
.PHONY: all
all: install lint test

# 가상 환경 설정
.PHONY: venv
venv:
    python3 -m venv $(VENV)

# 패키지 설치
.PHONY: install
install: venv
    $(PIP) install -r requirements.txt

# 코드 포매팅
.PHONY: format
format: venv
    $(BLACK) .

# 린트 검사
.PHONY: lint
lint: venv
    $(FLAKE8) .

# 테스트 실행
.PHONY: test
test: venv
    $(PYTEST)

Makefile.venv

Makefile.venv 파일은 Python 프로젝트에서 가상 환경(virtual environment)을 설정하고 관리하는 Makefile이다. 따라서 Makefile.venv를 만들면 따로 가상환경을 만들지않아도 된다.

.gitignore에 등록해서 사용하면 된다!

# 가상 환경 생성 및 패키지 설치
make -f Makefile.venv
# 가상 환경 활성화
source .venv/bin/activate
# 패키지 업데이트
make -f Makefile.venv update
# 가상 환경 삭제
make -f Makefile.venv clean

.envrc 파일로 환경변수 자동으로 설정하기

suyeonme — Sun, 7 Jul 2024 22:29:18 +0900

.envrc 파일이란?

.envrc 파일은 direnv와 함께 사용되며, 특정 디렉터리에 진입할 때 자동으로 환경 변수를 설정할 수 있도록 한다.

사용예시

.env.sample

프로젝트에 필요한 환경변수를 .env.sample 파일에 작성해서 예시 코드를 제공한다.

SENTRY_DNS=http://sentry.dom/your-url
SLACK_BOT_TOKEN=your-slack-url

.envrc

루트에 .envrc 파일을 만들고, .env.sample 파일을 참고해서 환경변수를 정의한다.

direnv

vscode를 사용중이라면, direnv 플러그인을 설치한다.

vscode 플러그인

플러그인 설치 후, 환경변수를 로딩할 프로젝트에서 아래 명령어를 입력하면, 해당 프로젝트 진입시 자동으로 프로젝트의 환경변수를 불러와서 설정해준다!

direnv allow

[독서] 가상면접 사례로 배우는 대규모 시스템 설계 기초 - 사용자 수에 따른 규모 확장성

suyeonme — Sat, 22 Jun 2024 08:54:47 +0900

확장가능한 아키텍쳐

수직적 규모 확장(Scale up) vs 수평적 규모 확장(Scale out)

수직적 규모 확장(Scale up)의 문제점

한대의 서버에 CPU나 메모리를 무한대로 증설할 방법은 없기에 한계가 있다.
장애에 대한 자동복구(failover)나 다중화(re-dundancy)방안을 제시하지않는다. 따라서 서버에 장애가 발생하면 어플리케이션은 중단된다.

로드 밸런서

역할

트래픽 분산: 클라이언트 요청을 여러 서버에 분산시켜 각 서버의 부하를 줄인다.
고가용성: 서버 장애 시에도 서비스를 지속할 수 있도록 Health Check 및 Fail Over를 수행한다.
성능 향상: 서버 간의 트래픽을 균등하게 분배하여 응답 시간을 줄이고 성능을 최적화한다.

종류

소프트웨어 로드 밸런서: NGINX, Apache Traffic Server등
클라우드 기반 로드 밸런서: AWS Elastic Load Balancing (ELB), Google Cloud Load Balancing, Azure Load Balancer등

데이터베이스 다중화

서버 사이에 master와 slave 관계를 설정하고 데이터 원본을 master 서버에, 사본은 slave 서버에 저장하는 방식이다.

master 서버: 데이터 원본 저장, 쓰기 연산(write)
slave 서버: 데이터 사본 저장, 읽기 연산(read)

장점

데이터 변경 연산은 master 서버, 읽기 연산은 slave 서버로 분산된다. 따라서 병렬로 처리될 수 있는 query의 수가 늘어나서 성능이 좋아진다.
데이터를 지역적으로 떨어진 장소에 다중화 시킴으로써 자연재해등의 이유로 데이터베이스 서버의 일부가 파괴되어도 데이터를 보존할 수 있다.
데이터를 여러 지역에 복제함으로써 데이터베이스 서버에 장애가 발생해도 다른 서버에 있는 데이터로 서비스를 유지할 수 있다.

예시

slave 서버가 1대인데 다운된 경우, 읽기 연산은 한시적으로 master 서버로 전달된다. 또한 즉시 새로운 slave 서버가 장애 서버를 대체한다. slave 서버가 여러대인 경우, 읽기 연산은 나머지 slave 서버로 분산될 것이며 새로운 slave 서버가 장애 서버를 대체한다.
master 서버가 다운되면, 한대의 slave 서버만 있는 경우 해당 slave 서버가 새로운 master 서버가 된다. 모든 데이터베이스 연산은 일시적으로 새로운 master 서버에서 처리된다. 그리고 새로운 slave 서버가 추가된다.

캐시

응답 시간은 캐시를 붙이고 정적 콘텐츠를 CDN으로 옮기면 개선할 수 있다.

캐시는 비싼 연산 결과 또는 자주 참조되는 데이터를 메모리안에 두고 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다. 대표적으로 Redis가 있다. 애플리케이션의 성능은 데이터베이스를 얼마나 자주 호출하느냐에 크게 좌우되는데 캐시는 그런 문제를 완화할 수 있다.

캐시 계층(cache tier)

캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 빠르다. 별도의 캐시 계층을 두면 성능이 개선될 뿐아니라 데이터베이스의 부하를 줄일 수 있고 캐시 계층의 규모를 독립적으로 확장할 수 있다.

읽기 주도형 캐시 전략(read-through caching strategy)

읽기 주도형 캐시 전략은 다음의 순서로 진행된다.

요청을 받은 웹서버는 캐시에 응답이 저장되어있는지 본다.
만일 저장되어있다면 해당 데이터를 클라이언트에 반환한다.
없는 경우라면 데이터베이스 query를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환한다.

캐시 사용시 유의할 점

데이터갱신은 자주 일어나지 않지만 참조가 빈번하게 일어나는 경우 캐시가 적합하다.
캐시는 데이터를 휘발성 메모리에 저장하므로 영구적으로 보관할 데이터는 캐시에 저장하면 안된다.
만료된 데이터는 캐시에서 삭제해야한다. 따라서 만료기한을 적절하게 설정해야한다.
저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지않는 경우 일관성이 깨질 수 있다.
캐시 서버를 한대만 두는 경우, 장애 발생시 해당 서버는 단일 장애 지점(Single point of failure, SPOF)가 될 수 있다. 따라서 여러 지역에 걸쳐 캐시 서버를 분산해야한다.
적절한 캐시 데이터 방출 정책을 적용해야한다.

단일 장애 지점(Single point of failure, SPOF)

어떤 특정 지점에서의 장애가 전체 시스템의 동작을 중단 시키는 경우이다.

캐시 데이터 방출 정책

캐시가 꽉 찼는데 추가로 캐시에 데이터를 넣어야하는 경우 기존 데이터를 내보내는 정책이다. 대표적으로 LRU(Least recently used) -- 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 알고리즘-- 이나 LFU(Least frequently used) --사용된 빈도가 가장 낮은 데이터를 내보내는 알고리즘이 있다.

CDN

CDN은 정적 컨텐츠를 전송하는데 사용되는 지리적으로 분산된 서버의 네트워크이다. 이미지, 비디오, CSS, Javascript 파일등을 캐시할 수 있다. 사용자가 웹사이트를 방문하면 사용자에게 가장 가까운 CDN 서버가 정적 컨텐츠를 전달한다.

무상태(Stateless) 계층

상태 웹 계층

웹 계층을 수평적으로 확장하기위해서 상태 정보(사용자의 세션)를 웹계층에서 제거해야한다. 상태정보를 관계형 데이터베이스나 NoSQL 같은 저장소에 보관하고 필요할 때 가져오도록 하는 것이다. 상태정보가 웹서버에서 제거되었으므로, 트래픽 양에 따라 웹서버를 넣거나 빼기만하면 자동적으로 규모를 확장 할 수 있다.

상태 정보 의존적인 아키텍쳐

상태 정보를 보관하는 서버는 클라이언트 정보를 요청 사이에서 공유한다. 따라서 같은 클라이언트의 요청은 항상 같은 서버로 전송되어야한다. 대부분의 로드밸런서는 고정 세션(sticky session) 기능으로 이를 지원하는데, 이는 로드밸런서에 부담을 준다.

메세지큐

메세지큐는 데이터의 무손실을 보장하고 비동기 통신을 지원하는 컴포넌트이다. 메세지큐를 이용하면 서비스 또는 서버간의 결합이 느슨해져서 규모 확장성이 보장되어야하는 안정적 애플리케이션을 구성하기좋다.

기본 아키텍쳐

Producer/Publisher: 메세지를 만들어 메제시큐에 publish한다. 생산자는 소비자 프로세스가 다운되어도 메세지를 발행할 수 있다.
Consumer/Subscriber: 메세지를 받아 그에 맞는 동작을 수행한다. 소비자는 생산자 서비스가 가용가능한 상태가 아니여도 메세지를 수신할 수 있다.

예시

사진 보정 애플리케이션을 만든다고 가정해보자. 보정은 시간이 오래 걸릴 수 있으므로 비동기로 처리하면 편리하다. 메세지큐를 이용해서 다음과 같이 구상할 수 있다.

웹서버는 사진 보정 작업을 메세지 큐에 넣는다.
사진 보정 작업 프로세스는 이 작업을 메세지큐에서 꺼내어 비동기적으로 완료한다.

데이터베이스의 규모 확장

Sharding

데이터베이스의 수평적 확장은 sharding이라고 부르는데, 더 많은 서버를 추가함으로써 성능을 향상시킬 수 있다. 샤딩은 대규모 데이터베이스를 Shard라고 부르는 작은 단위로 분할하는 기술을 말한다.

Sharding Key(Partition Key)

샤딩 전략을 구현할 때 가장 중요한 것은 샤딩키를 어떻게 정하느냐이다. 샤딩 키는 데이터가 어떻게 분산될지 정하는 하나 이상의 컬럼으로 구성된다. 샤딩 키를 정할 때 데이터를 고르게 분할할 수 있도록 하는 것이 가장 중요하다.

고려사항

샤드 소진(Shard exhaustion) 현상이 발생하면, 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치해야한다.
유명인사(Celebrity)/핫스팟 키(Hotspot key) 문제 발생시, 유명인사 각각에 샤드 하나씩을 할당하거나 더 잘게 쪼개야한다.
여러샤드에 걸친 데이터를 조인하기가 힘든 경우, 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 한다.

샤드 소진(Shard exhaustion)

데이터가 너무 많아서 하나의 샤드로는 감당불가한 경우, 또는 샤드간 데이터 분포가 균등하지못해서 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빠르게 진행되는 경우를 의미한다.

유명인사(Celebrity)/핫스팟 키(Hotspot key) 문제

특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제이다.

[Nestjs, Axios] Access Token과 Refresh Token으로 인증 구현하기(클라이언트, 서버)

suyeonme — Tue, 18 Jun 2024 12:32:22 +0900

인증 과정

서버: 로그인 성공시, 서버에서 refresh token은 httpOnly 헤더에, access token은 클라이언트에 전송합니다.
클라이언트: access token을 로컬스토리지에 저장합니다. 이후 요청시 헤더에 access token을 추가해서 요청을 보냅니다.
클라이언트: access token의 기간이 만료되었다면(서버의 응답이 401인 경우) refresh token 갱신 요청을 보냅니다.
서버: refresh token을 검증한 뒤, access token, refresh token을 갱신합니다. 갱신된 access token을 클라이언트에 전송합니다.
클라이언트: 갱신된 access token을 로컬스토리지에 저장합니다.

유효기간 및 저장 위치

Access Token: 30분~1시간, 클라이언트에서 헤더에 추가해서 요청
Refresh Token: 1주~2주, 서버에서 httpOnly 헤더에 추가

서버 코드

서버는 Next.js로 구성된 프로젝트이다.

쿠키를 다루기위해서 먼저 라이브러리를 설치해야한다. (공식문서 참고)

$ pnpm i cookie-parser
$ pnpm i -D @types/cookie-parser

이후 main.ts에 쿠키 라이브러리를 적용한다. 나의 경우 CORS 에러가 발생하지않도록 CORS 관련된 설정도 함께 적용했다.

app.use(cookieParser());

app.enableCors({
  origin: process.env.CORS_ORIGIN ? [process.env.CORS_ORIGIN] : [],
  methods: 'GET,HEAD,PUT,PATCH,POST,DELETE,OPTIONS',
  credentials: true, 
  allowedHeaders: 'Content-Type, Accept, Authorization',
});

refresh token은 서버에서 httpOnly 쿠키에 저장하므로 클라이언트에 보내지않아야한다. 따라서 응답 데이터에서 refresh token은 제외하고 access token을 보내도록 코드를 작성했다.

@Controller('auth')
@UseInterceptors(ClassSerializerInterceptor)
export class AuthController {
    constructor(private authService: AuthService) {}
    
    @UseGuards(LocalAuthGuard)
    @Post('/signin')
    async login(
        @Request() _req: Req,
        @Body() signinUserDto: SigninUserDto,
        @Res({ passthrough: true }) res: Response,
    ) {
        const { user, accessToken } = await this.authService.signin(signinUserDto);

        res.cookie('refreshToken', user.refreshToken, {
            httpOnly: true,
            secure: true, // Ensure secure for HTTPS
            sameSite: 'strict', // Prevent CSRF attack
            maxAge: REFRESH_TOKEN_COOKIE_MAX_AGE, // 7 days
        });

        const copied: Omit<User, 'password' | 'refreshToken'> = { ...user };

        /**@description @Exclude() 항목이 인터셉터에서 제거되지않으므로 수동으로 제거  */
        if ('password' in copied && 'refreshToken' in copied) {
            delete copied.password;
            delete copied.refreshToken;
        }

        return { ...copied, accessToken };
    }
}

httpOnly

JavaScript로 접근할 수 없는 쿠키로, 클라이언트와 서버 간의 HTTP 요청을 통해서만 전송될 수 있다.
클라이언트측 스크립트는 쿠키에 접근이 불가하므로, XSS(Cross-Site Scripting) 공격으로부터 쿠키를 보호하는 데 유용하다.

sameSite

strict: 쿠키는 동일한 사이트에서만 전송된다. 즉, 사용자가 사이트에서 탐색할 때만 쿠키가 전송된다. 다른 사이트에서 요청이 발생하면 쿠키는 전송되지 않는다.
위와 같은 이유로 CSRF(Cross-Site Request Forgery) 공격을 방지하는 데 도움이 된다.

응답데이터에서 refresh token 제거하기

아래와 같이 entity를 바로 반환하는 경우, Controller에 적용한 ClassSerializerInterceptor에 의해서 @Exclude() 필드가 정상적으로 제외된다.

// user.entity.ts
@Entity()
export class User {
    @PrimaryGeneratedColumn()
    id: number;

    @Column()
    email: string;

    @Column()
    @Exclude()
    password: string;

    @Column()
    username: string;

    @Column({ type: 'varchar', nullable: true })
    @Exclude()
    refreshToken: string | null;
}

하지만 아래와 같이 바로 entity를 반환하지 않는 경우, @Exclude() 필드가 정상적으로 필터링되지 않았다. 따라서 수동으로 제외시켰다.

    @UseGuards(LocalAuthGuard)
    @Post('/signin')
    async login(
        @Request() _req: Req,
        @Body() signinUserDto: SigninUserDto,
        @Res({ passthrough: true }) res: Response,
    ) {
    	// Service에서 Entity를 바로 반환하지 않음
        const { user, accessToken } = await this.authService.signin(signinUserDto);
        ...
        const copied: Omit<User, 'password' | 'refreshToken'> = { ...user };

        /**@description @Exclude() 항목이 인터셉터에서 제거되지않으므로 수동으로 제거  */
        if ('password' in copied && 'refreshToken' in copied) {
            delete copied.password;
            delete copied.refreshToken;
        }

        return { ...copied, accessToken };
    }

클라이언트 코드

React 프로젝트 기준 axios의 인터셉터를 이용해서 인증 로직을 구현하였다.

axios/axios.config.ts

axios의 요청, 응답 인터셉터를 다루는 로직을 별도의 모듈로 분리했다.

// axios.config.ts

export const createBaseAPI = (
  baseUrl: string,
  options: AxiosRequestConfig = {}
) => {
  return axios.create({
    baseURL: baseUrl,
    timeout: REQUEST_TIMEOUT,
    withCredentials: true,
    headers: {
      "Content-Type": "application/json",
    },
    ...options,
  });
};

/**
 * @description 요청 인터셉터, 액세스토큰을 헤더에 추가합니다.
 */
export const addRequestInterceptors = (
  instance: ReturnType<typeof axios.create>
) => {
  instance.interceptors.request.use(
    (config) => {
      const accessToken = localStorage.getItem(ACCESS_TOKEN_KEY);
      if (accessToken) {
        config.headers["Authorization"] = `Bearer ${accessToken}`;
      }
      return config;
    },
    (error) => Promise.reject(error)
  );
};

/**
 * @description
 * - 응답 인터셉터, 액세스토큰이 만료되었을 경우, 리프레시 토큰을 사용하여 재발급합니다.
 * - 에러 발생시 에러 로그를 출력합니다.
 */
export const addResponseInterceptors = (
  instance: ReturnType<typeof axios.create>
) => {
  instance.interceptors.response.use(
    (response) => {
      const accessToken = response.data.data[ACCESS_TOKEN_KEY];
      if (accessToken) {
        localStorage.setItem(ACCESS_TOKEN_KEY, accessToken);
      }
      return response;
    },
    async (error) => {
      if (config.nodeEnv === "development") {
        // 에러 로깅
        errorMessageLogger(error);
      }

      // 액세스토큰 만료시 리프레시 토큰 재발급
      const originalRequest = error.config as AxiosRequestConfig & {
        _retry?: boolean;
      };

      if (error?.response?.status === 401 && !originalRequest?._retry) {
        originalRequest._retry = true;
        try {
          const { data } = await instance.get("/auth/refresh");
          const accessToken = data[ACCESS_TOKEN_KEY];

          localStorage.setItem(ACCESS_TOKEN_KEY, accessToken);
          axios.defaults.headers.common[
            "Authorization"
          ] = `Bearer ${accessToken}`;

          return instance(originalRequest);
        } catch (refreshError) {
          return Promise.reject(refreshError);
        }
      }

      return Promise.reject(error);
    }
  );
};

axios/baseInstance.ts

/**
 * @description 일반적인 API 요청시 사용하는 axios 인스턴스입니다.
 */
const baseInstance = createBaseAPI(APP_SERVER_BASE_URL);

addRequestInterceptors(baseInstance);
addResponseInterceptors(baseInstance);

export default baseInstance;

인스턴스를 사용하는 곳에서는 다음과 같이 사용하면 된다.

  const handleSubmit = async (event: React.FormEvent<HTMLFormElement>) => {
    try {
      const response = await signin(form);
      const { data } = response;

      if (data.statusCode === 201) {
        handleResetForm();
        router.push("/");
      } else {
        console.error(data.message);
      }
    } catch (error) {
      /**@todo 에러 메세지 출력 */
    }
  }

[Git] 모노레포 환경에서 Husky로 Git Hook 설정하기(Commit전 console.log 제거)

suyeonme — Thu, 16 May 2024 17:12:46 +0900

Commit 대상 파일에 console.log가 포함되어있는 경우, commit 막기

Git flow 전략을 사용해서 브랜치를 관리하는 경우, master 브랜치는 곧 배포 브랜치입니다. 따라서 브랜치에 작업물을 Commit하는 경우, console이 포함되어있다면 Github Hook을 이용하여 commit을 못하도록 막을 수 있습니다.

보편적으로 운영환경에서는 console을 제거합니다. 이유는 다음과 같습니다.

console에는 민감정보를 포함할 수 있습니다.
console로 번들사이즈가 늘어납니다.

스크립트 작성하기

(1) 스크립트 파일 생성 및 작성

저의 경우, script/check-console.sh 파일을 생성했습니다. 해당 스크립트는 husky가 설치된 루트에 위치시킵니다.

아래는 기본적으로 메세지를 띄우는 스크립트입니다.

#!/usr/bin/env sh

# 커밋 대상 파일에 console.log가 포함되어있는지 확인
if git diff --cached --name-only --diff-filter=ACMRT | xargs grep -i 'console\.log' --with-filename --line-number; then
  echo "COMMIT REJECTED!  Please remove console."
  exit 1
fi

텍스트에 색상을 입히고 싶은 경우, 다음과 같이 스크립트를 작성합니다.

#!/usr/bin/env sh

red='\033[0;31m'
green='\033[0;32m'
yellow='\033[0;33m'
no_color='\033[0m'

# 커밋 대상 파일에 console.log가 포함되어있는지 확인
if git diff --cached --name-only | xargs grep -i 'console\.log' --with-filename --line-number;
then
    echo -e "\n${red}COMMIT REJECTED!  Please remove console."
    exit 1;
fi
echo -e "${green}SUCCESS! No console is found."
exit 0;

(2) pre-commit 파일에 스크립트 추가

.husky/pre-commit 파일에 작성한 스크립트를 추가합니다.

#!/usr/bin/env sh

# Check console.log is included in staged files
sh scripts/check-console.sh

저의 경우, 모노레포로 구성된 프로젝트라서 아래와 같이 작성해주었습니다.

#!/usr/bin/env sh

# 현재 스크립트 파일이 위치한 디렉토리를 기준으로 .husky.sh 파일을 실행
. "$(dirname -- "$0")/_/husky.sh"

cd packages/backend

# Check console.log is included in staged files
sh scripts/check-console.sh

(3) 테스트

소스코드에 console.log 추가 후, commit을 시도합니다.

COMMIT REJECTED! 부분은 소스코드에 console을 추가한 경우입니다.
SUCCESS! 부분은 소스코드에 console이 포함되지않은 경우입니다.

[Git] 모노레포 환경에서 Husky로 Git Hook 설정하기(commitlint)

suyeonme — Thu, 16 May 2024 14:18:52 +0900

commitlint로 Commit 컨벤션 적용하기

규모가 큰 팀에서 협업시, 커밋 컨벤션을 따르면 커밋의 일관성을 지킬 수 있다. 대표적으로 다음과 같은 커밋 컨벤션을 사용한다.

feat(AppController): Format response
feat: Format response

lintcommit을 이용해서 작성한 commit이 컨벤션을 지켰는지 검사해보자!

(1) 라이브러리 설치

# husky 설치
pnpm add --save-dev husky
pnpm exec husky init

# commitlint 패키지 다운로드
pnpm install --save-dev @commitlint/config-conventional @commitlint/cli

# commitlint.config.js 파일 생성
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

commitlint.config.js에서 SyntaxError: Unexpected token 'export'에러가 나는경우, 아래와 같이 수정한다.

# 수정 전
export default { extends: ['@commitlint/config-conventional'] };

# 수정 후
module.exports = { extends: ["@commitlint/config-conventional"] };

(2) commit-msg 훅 스크립트 작성

아래 명령어는 .husky/commit-msg 파일을 추가한 뒤, commitlint 패키지를 실행한다.

# commit-msg 훅 스크립트 작성
echo "pnpm dlx commitlint --edit \$1" > .husky/commit-msg

(3) 작성한 훅이 정상적으로 동작하는지 확인

아래 명령어는 최근 두 커밋 메세지를 검사한다.

pnpm exec commitlint --from HEAD~1 --to HEAD --verbose

이전에 작성한 커밋이 있다면 해당 커밋이 출력된다.

최근 커밋 출력

(4) 변경 사항을 add한 뒤, 커밋 메세지 작성

컨벤션에 맞지않는 커밋을 작성한 경우

Commit 실패

컨벤션에 맞는 커밋을 작성한 경우

Commit 성공

모노레포에서 적용하는 경우

나의 경우, 아래의 디렉터리 구조를 가진 모노레포에 적용하였다. commitlint.config.js는 husky가 설치된 디렉터리에 추가한다.

만약 전체 워크스페이스에 Git hook을 적용해야한다면 루트에 husky를 적용해야한다. 이 경우 config-pnpm-scopes를 참고해볼 수 있을 것 같다.

.
├── packages/
│   ├── frontend
│   └── backend/
│       ├── src
│       ├── .eslintrc.js
│       ├── .prettierrc
│       ├── .commitlint.config.js 
│       └── package.json <--- Husky 설치!
├── package.json
├── pnpm-workspace.yaml
└── pnpm-workspace.lock.yaml
└── .git

동일하게 commit-msg를 적용한 뒤, 커밋을 시도하자 Please add rules to your commitlint.config.js 에러가 발생했다.

commitlint 에러 발생

이 경우, commit-msg 파일에서 git이 설치된 경로를 잡아주면 정상적으로 동작한다.

#!/usr/bin/env sh

. "$(dirname -- "$0")/_/husky.sh"

cd packages/backend # 추가!

pnpm dlx commitlint --edit $1