0과 1을 공부하다.

[Tech] AI가 해주는 코드리뷰 - CodeRabbit

dev.parkjh — Thu, 8 May 2025 16:25:27 +0900

Introduce

최근에는 1인 프로젝트를 많이 진행하고 있다. 혼자 개발을 하다 보니 코드에서 놓치는 부분이 많다는 것을 실감하게 되었다.

여러 사람과 함께 프로젝트를 진행할 경우, 코드리뷰를 통해 서로의 코드를 교차 검증하고, 클린코드나 컨벤션 같은 사소한 수정은 물론 소프트웨어 결함을 일으킬 수 있는 로직까지 찾아내고 보완할 수 있다.

하지만 1인 개발 환경에서는 이러한 코드리뷰 과정을 거치기 어렵고, 여러 명이 함께 리뷰를 하더라도 시간이 많이 들고 리뷰의 정확도도 떨어질 수 있다.

이러한 한계를 보완하고자, AI가 자동으로 코드리뷰를 수행하는 솔루션인 CodeRabbit 을 직접 경험해보고자 한다.

특징

AI 기반 자동 코드리뷰
- PR(Pull Request) 생성 시, AI가 자동으로 코드 변경 사항을 분석하고 리뷰 제공
코드 요약 및 라인별 피드백
- 변경된 코드를 요약하고, 각 라인에 대해 스타일, 오류 가능성, 성능 개선 등을 지적
다국어 지원
- 사용자의 언어에 따라 영어, 한국어 등으로 리뷰 제공 (초기 언어 감지 기반)
시각적 이해 지원
- 시퀀스 다이어그램 등을 통해 코드 흐름을 시각화
GitHub/GitLab 연동
- 주요 협업 플랫폼과 쉽게 통합 가능
지속적 학습 및 커스터마이징
- 팀 코드 스타일에 맞춰 AI 리뷰 품질 향상 가능

가격

가격은 아래와 같다. Free 플랜은 14일 동안만 무료로 사용 가능하며, Lite 플랜 기준으로는 인당 월 $12 금액이 청구된다.

Log-In

coderabbit (https://www.coderabbit.ai) 홈페이지에서 “Geta a free trial” 을 눌러 로그인을 진행한다.

로그인은 github, gitlab 과 같은 저장소 관리 시스템 계정으로 진행할 수 있다. 호스팅 방식에 따라 SaaS와 Self-Hosted 방식 중 선택하여 진행한다.

Environment configuration

로그인 후 기본적으로 설정해야 하는 항목은 많지 않다. Repositories 에서 자신이 리뷰 받고 싶은 저장소의 설정으로 들어간다.

General - Review Language - Korean 선택하여 언어를 한국어로 설정한다.

실습

코드 리뷰를 테스트하기 위해 간단한 테스트 코드를 커밋한다.

커밋에 사용한 코드는 프로그래머스의 - 완주하지 못한 선수 (https://school.programmers.co.kr/learn/courses/30/lessons/42576) 코딩 테스트 문제이다.

아래 코드 커밋 후 PR(Pull Requests) 을 등록한다.

def solution(participant, completion):
    hashMap = {}
    for person in participant:
        hashMap[person] = hashMap.get(person, 0) + 1
    for person in completion:
        hashMap[person] -= 1
    for key, value in hashMap.items():
        if value > 0:
            return key
            return keyNew # 고의적으로 주입한 unreachable code

몇 분이 흐르고 나면 아래와 같이 리뷰가 등록된다. 컨벤션, 클린코드와 같이 사소한 리뷰부터 결함을 일으킬 수 있는 중대한 로직까지 세세하게 리뷰해 준다. 또한 리뷰에 대해 코멘트를 남기면 몇 분 안에 피드백 코멘트를 남겨준다.

총평

AI 코드리뷰 솔루션은 마치 ChatGPT가 처음 등장했을 때처럼 신선한 충격을 주었다.

실무에서 개발을 하며 느낀 점은, 코드 리뷰는 매우 중요하지만 시간이 오래 걸리고, 때로는 중대한 결함을 발견하지 못하거나 리뷰의 정확성과 일관성이 떨어질 수 있다는 것이다.

물론 다른 기술들과 마찬가지로 AI에 과도하게 의존하거나 맹신해서는 안 되지만, 코드 리뷰 과정에서 사람이 개입하기 전에 AI가 먼저 1차 리뷰를 수행하고, 이후 사람이 이를 검토하는 방식은 여러 측면에서 효율성을 크게 높일 수 있다고 느꼈다.

무엇보다 기존 코드리뷰의 단점인 시간 소요, 정확성 부족, 일관성 문제를 보완함으로써 전반적인 코드 품질 향상을 기대할 수 있다는 점이 가장 인상 깊었다.

Ref

[Tech] 순수 프로그래밍 시간 측정(wakatime)

dev.parkjh — Wed, 7 May 2025 14:23:21 +0900

Introduce

최근 프로그래밍 공부를 하면서 부쩍 이전보다 집중력이 떨어졌음을 느꼈다. 그래서 아이폰의 스크린 타임처럼 수치적으로 내가 얼마나 집중하고 있는지 보여 줄 수 있으면 어느정도 목표치를 갖고 집중할 수 있겠다고 느꼈다. 그래서 알아보던 중 순수 프로그래밍 시간을 측정하는 wakatime 에 대해 알게 되었다.

wakatime은 개발자의 코딩 시간을 자동으로 기록하고 시각화해주는 시간 추적 도구 이다. 동작 방식은 실제로 키보드 입력이나 마우스 활동이 있는 시간만을 기록 한다. 지정한 시간만큼 동작이 없으면 세션 종료로 간주하고 다시 동작이 발생하면 새로운 세션이 시작된다. 설치 방법은 매우 간단하며, 개발자들이 주로 사용하는 다양한 통합개발환경에서 지원한다. 추적된 시간은 Dashboard 에서 시각화하여 확인 할 수 있다.

⚠️ 프로젝트 이름은 기본적으로 루트 폴더명 으로 자동 설정 된다.

Sign Up (회원가입)

wakatime (https://wakatime.com) 사이트 접속 후 이메일 혹은 GitHub 연동 가입한다.

플랜을 선택한다.

현재는 무료 플랜으로 충분하다. 무료 플랜이라도 7일의 통계기간과 1개의 목표를 지정할 수 있다.

로그인 후 Setting - Account - API Key 으로 이동해서 자신의 API Key 를 획득한다.

Implement - VSCode

guide : https://wakatime.com/vs-code

WakaTime plugin for VS Code

An open source VS Code extension for automated programming metrics.

wakatime.com

VSCode - Extensions 에서 wakatime 검색 후 설치한다.

F1 을 눌러 명령 팔레트를 활성화 하고 WakaTime: Api Key 검색 후 이전에 획득한 자신의 API Key 입력한다.

VSCode 하단에서 WakaTime 세션 연결을 확인한다.

Implement - IntelliJ

guide : https://wakatime.com/intellij-idea

WakaTime plugin for IntelliJ IDEA

An open source IntelliJ IDEA extension for automated programming metrics.

wakatime.com

[작성중]

Dashboard 구성

각 Dashboard 가 의미하는 바는 아래와 같다.

Summary (요약 화면)

오늘, 이번 주, 이번 달, 커스텀 기간에 대한 총 통계 ****시간 확인 가능
통계 데이터
- 주간 프로젝트 시간 통계 그래프
- 주간 카테고리 시간 통계 그래프
- 하루 프로젝트 시간 통계 그래프
- 하루 사용 언어 통계 그래프

Editors

VS Code, IntelliJ, PyCharm 등 사용한 개발 도구별 시간 분석

Languages

Python, JavaScript 등 언어별 누적 시간과 비율 제공
일/주/월별 추이 확인 가능

Operating Systems

개발 환경 운영체제를 의미

Machines

여러 컴퓨터에서 작업한 경우 기기명 별로 시간 분류

Today

코딩 시간 일일 평균 통계

Weekdays

사용자의 활동을 유형별로 분류해서 보여주는 통계 지표 (Coding, Debugging, Building 등)

Ref

[Inflearn] 비전공자도 이해할 수 있는 Nginx 입문/실전

dev.parkjh — Tue, 6 May 2025 16:00:49 +0900

inflearn: https://www.inflearn.com/course/비전공자도-이해-nginx-입문-실전/dashboard
수업 자료: https://jscode.notion.site/16011062ff0780aa87a3e879cb3ef482

Preview

내가 Nginx 를 처음으로 접한 경험은 Docker Private Image Registry 를 구성하는 과정에서 HTTPS 인증서 적용을 위해 Nginx를 잠깐 경험해봤다.

실무에서는 주로 아파치(Apache) 를 웹서버로 사용해서 사용할 기회가 없었는데 예제를 통해 잠깐 경험해보니 충분히 공부할 가치가 높다고 생각했다. 백엔드 개발자 입장에서 웹서버 + 리버스 프록시 + 로드밸런서 기능까지 3 in 1 으로 쓸 수 있으니 충분히 가치가 있다고 느꼈다.

해당 인프런 강의를 수강하기 이전에 비전공자도 이해할 수 있는 DB 설계 입문/실전 을 수강한 경험이 있는데 쉽게 풀어서 설명해주는 강사님이 인상 깊어서 강사님의 강의로 선택하게 되었다.

앞선 경험을 통해 이미 Nginx 에 대해 간략하게 알고 있지만 약 3시간 정도 부담되지 않는 시간으로 Nginx의 기능에 대해 경험해보고자 한다.

Introduce

주석 공부법

코드 한 줄마다 어떤 의미를 가지고 있는지 주석을 달면서 학습하는 방법.
시간이 오래걸려 비효율적일 것 같지만 한 줄씩 주석을 달다보면 어느순간부터 코드를 대부분 이해하게 된다.

Nginx 개본 개념

Nginx는 왜 사용해야 할까 ?

현업에서 Nginx를 안 쓰고 있는 기업을 찾기가 어렵다. 현업에서 많이 쓰고 있다는 것은 (백엔드)개발자로 취업을 하기 위해 필수로 알아야 하는 기술임을 뜻한다.

Nginx 는 아래와 같이 다양한 기능을 가지고 있는 S/W 이다. 아래 기능들은 서버스를 운영할 때 필수적으로 사용하게 되는 기능들이다.

정적 컨텐츠 제공
SSL 처리
로드 밸런싱
장애 대응
캐싱
보안 처리 (IP 차단, 요청 수 제한)

Nginx를 배운다는 것은 Nginx의 설정 파일을 내가 구성하고 싶은 대로 응용할 수 있게끔 배워야 한다. 그러려면 자주 쓰이는 Nginx의 문법과 기본적인 파일 구조를 익혀야 한다.

Apache VS Nginx

최근 Nginx 가 Apache 점유율을 뛰어 넘었다. Nginx를 많이 사용하는 가장 큰 이유는 Apache에 비해 훨씬 많은 트래픽을 처리할 수 있는 구조를 가지고 있다. (Nginx가 성능이 더 좋다.)

Nginx 설치 및 실행

⚠️ 필자는 앞서 Docker Container 을 통해 Nginx를 구성하였으나, 본 강의에는 AWS EC2 인스턴스에서 구성하여 진행하였다. 따라서 본 글에서도 동일하게 EC2 인스턴스 환경에서 실습을 진행한다.

Ubuntu 환경에서 Nginx 설치하기

# apt에서 설치 가능한 패키지 리스트(최신 패키지, 버전 등)를 최신화시킨다.
# apt는 리눅스에서 사용되는 소프트웨어 패키지를 설치 및 관리할 수 있게 도와주는 툴이다.
# npm 또는 gradle과 같은 패키지 관리 도구와 비슷하다고 생각하면 된다. 
$ sudo apt update

# nginx 설치에 필요한 라이브러리 설치
$ sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring

# nginx 공식 패키지를 안전하게 설치하기 위한 보안 조치이다. 자세한 코드 의미는 몰라도 된다. 
# 다만, curl, gpg, tee, |, >, /dev/null, echo가 무슨 기능을 하는 명령어인지는 정리해두자. 
$ curl <https://nginx.org/keys/nginx_signing.key> | gpg --dearmor \\
    | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
$ gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg
$ echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \\
<http://nginx.org/packages/ubuntu> `lsb_release -cs` nginx" \\
    | sudo tee /etc/apt/sources.list.d/nginx.list

# nginx 설치
$ sudo apt update
$ sudo apt install nginx

Nginx 실행하기

# nginx 상태 확인
$ sudo systemctl status nginx

# nginx 시작
$ sudo systemctl start nginx

# nginx 상태 확인
$ sudo systemctl status nginx

실행 확인을 위하여 http://{EC2 IP 주소} 로 접속하여 본다.

Nginx 로그 확인하기

로그 파일 위치 : /var/log/nginx
- access.log : Nginx 서버로 접근한 요청에 대한 정보
- error.log : 에러 메세지에 대한 내용

Nginx를 활용해 웹 사이트 배포하기

웹 서버(Web Server)는 사용자의 요청이 들어올 때마다 HTML, CSS, JS, 이미지와 같은 파일들을 제공하는 컴퓨터를 의미한다.
Nginx 는 사용자의 요청이 들어올 때마다 파일(HTML, CSS, JS, 이미지 등)을 제공할 수 있는 기능을 가지고 있다.
Nginx를 활용해 웹 사이트를 배포할 수 있다. 이걸 보고 ‘Nginx’가 웹 서버(Web Server) 역할을 한다’라고 한다.

Nginx 기본 문법 해석

Nginx 설정 파일 위치 : /etc/nginx/nginx.conf
- Nginx 에서 가장 근본이 되는 설정 파일 (루트 설정 파일)
- 전역적으로 설정되어야 하는 내용(워커 프로세스 개수, 로그 저장 위치 등)
기본 웹 서버(Web Server) 설정 파일 : /etc/nginx/conf.d/default.conf

# server : '하나의 웹 사이트에 관련된 설정'을 관리하는 단위 ('server 블럭'이라고 부름)
server {
    # localhost:80으로 들어오는 요청을 이 server 블럭에서 처리하도록 설정
    # (server_name이 일치하는 server 블럭이 없는 경우 첫 번째 정의되어 있는 server 블럭을 기반으로 처리)
    # (아직은 정확히 몰라도 된다. 나중에 '멀티 도메인' 기능을 배우면 쉽게 이해할 수 있다.)
    listen       80;
    server_name  localhost;

    # / 으로 시작하는 모든 경로를 처리 (ex. /index.html)
    location / {
        # /jscode.html로 요청이 들어오면 /usr/share/nginx/html/jscode.html 파일로 응답
        root   /usr/share/nginx/html;
        
        # /로 요청이 들어오면 /usr/share/nginx/html/index.html로 응답
        # 만약 /usr/share/nginx/html/index.html이 없을 경우, /usr/share/nginx/html/index.htm으로 응답
        index  index.html index.htm;
    }

    # Nginx에서 500, 502, 503, 504의 상태 코드가 발생했을 때 /50x.html로 redirect
    error_page   500 502 503 504  /50x.html;
    
    # /50x.html과 완전히 일치하는 경로를 처리
    location = /50x.html {
        # /50x.html로 요청이 들어오면 /usr/share/nginx/html/50x.html 파일로 응답
        root   /usr/share/nginx/html;
    }
}

Nginx 디버깅 절차

# step 1. nginx 실행을 확인하라
$ sudo systemctl status nginx

# step 2. 문법을 점검하라
$ sudo nginx -t

# step 3. 로그를 확인하라
$ tail -f /var/log/nginx/access.log
$ tail -f /var/log/nginx/error.log

# step 4. 문제 해결 후 설정파일을 반영한다.
$ sudo nginx -s reload

[실습 생략]

한 서버에서 다른 도메인을 가진 여러 웹 사이트 배포하기 (멀티도메인)

/etc/nginx/conf.d/default.conf 에 두 개의 서버를 등록하여 멀티 도메인을 적용한다.

server {
        listen 80;
        server_name react.manutd.co.kr;

        location / {
                root /usr/share/nginx/nginx-frontend-react/dist;
                index index.html;
        }

}

server {
        listen 80;
        server_name next.manutd.co.kr;

        location / {
                root /usr/share/nginx/nginx-frontend-next/out;
                index index.html;
        }
}

Nginx를 활용한 HTTPS 적용시키기

HTTPS 를 적용해야 하는 이유

보안적인 이유 (HTTPS는 암호화 통신 프로토콜)
신뢰성 문제 (브라우저 단에서 경고 메세지 발생)

Nginx, Certbot을 활용해 HTTPS 적용하기

Certbot 이란 ? 웹 사이트에서 Let 's Encrypt 인증서 를 발급받고 갱신 및 관리하며 자동으로 사용하는 무료 오픈 소스 소프트웨어 도구

# certbot 설치
$ sudo snap install --classic certbot
$ sudo ln -s /snap/bin/certbot /usr/bin/certbot

# **HTTPS 인증서 발급받기
# 반드시 도메인을 먼저 연결(레코드 등록)한 뒤에 위 명령어를 쳐야 정상 작동한다.** 
# 자동으로 default.conf 파일을 수정하여 반영한다.
$ sudo certbot --nginx -d <도메인 주소>

설정 파일 분리해서 관리하기 (include)

default.conf 파일에서 다음과 같이 include 해서 파일을 분리할 수 있다.

# default.conf
include conf.d/web/react.manutd.conf;
include conf.d/web/next.manutd.conf;
.
.
또는
.
.
include conf.d/web/*.conf;

리버스 프록시(Reverse Proxy)를 활용해 백엔드 서버 배포하기

용어

프록시(Proxy) : 중계(중간에서 연결해주는 것)의 의미
프록시 서버(Proxy Server) : 중간 역할을 해주는 서버
포워드 프록시(Foward Proxy) 서버 : 보내려고 하는 요청을 관리 또는 보안 처리를 위한 용도 (ex. 사내 방화벽)
리버스 프록시(Reverse Proxy) : 들어오는 요청을 관리 또는 보안 처리 하기 위한 용도 (ex. HTTPS 처리, 요청 수 제한, 로드 밸런싱)

리버스 프록시는 들어오는 요청을 관리 또는 보안 처리를 하기 위해 사용한다. (악의적인 행위가 들어오는 것이 예상될 경우 활용한다)

Spring Boot 서버 배포하기

준비사항 : JDK 17 설치

$ sudo apt update && /
sudo apt install openjdk-17-jdk -y

# 설치 확인
$ java -version

spring 빌드 및 실행

$ ./gradlew clean build -x test
$ cd build/libs
$ nohup java -jar nginx-backend-springboot-0.0.1-SNAPSHOT.jar &

# 8080번 포트에서 실행되고 있는 프로세스 조회
$ lsof -i:8080

conf 파일 작성

server {
				listen 80;
        server_name api.manutd.co.kr;
        
        # / 으로 시작하는 모든 경로를 처리
        location / {
				        # 들어온 요청을 전부 <http://localhost:8080>(Spring Boot 서버)로 전달
                proxy_pass <http://localhost:8080>;
        }       
}

HTTPS 적용(DNS A 레코드에 사전 등록되어 있어야 한다.)

$ sudo certbot --nginx -d [api.manutd.co.kr](<http://api.manutd.co.kr>)

IP당 요청 수 제한하기

api.conf 파일 수정

# limit_req_zone : 요청 수를 제한하기 위한 메모리 공간(zone)과 요청 속도(rate)를 정의
# $binary_remote_addr : 요청 수를 제한하는 기준을 클라이언트의 IP로 설정
# zone=mylimit:10m : 메모리 공간(zone)의 이름을 mylimit이라고 지정, 
                     메모리 공간의 크기를 10MB 제한 (약 16만개의 IP 주소를 관리할 수 있음)
# rate=3r/s : 1초에 최대 3개의 요청만 허용
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=3r/s;

server {
				# limit_req_zone에서 정의한 mylimit이라는 조건을 이 server 블럭에 적용
        **limit_req zone=mylimit;**
        # 요청이 제한됐을 때 429(Too Many Requests) 상태 코드를 반환
        **limit_req_status 429;**
        
        server_name api.manutd.co.kr;

        location / {
                proxy_pass <http://localhost:8080>;
        }

.
.
.
(생략)
.
# 설정 파일 재로드
$ sudo nginx -s reload

Nginx를 로드 밸런서(Load Balancer)로 사용하기

로드 밸런서 : 사용자의 요청을 여러 대의 서버로 골고루 전달하기 위한 장치 (트래픽 부하 분산)

8081 포트를 사용하는 spring boot server 추가

$ cd ~/nginx-backend-springboot/build/libs
$ nohup java -jar nginx-backend-springboot-0.0.1-SNAPSHOT.jar --server.port=8081 &
$ lsof -i:8081

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=3r/s;

# 로드 밸런싱 대상 서버들을 upstream이라는 그룹으로 묶음
# upstream 그룹의 이름은 backend라고 지정
**upstream backend {
        server localhost:8080;
        server localhost:8081;
}**

server {
				# limit_req_zone에서 정의한 mylimit이라는 조건을 이 server 블럭에 적용
        **limit_req zone=mylimit;**
        # 요청이 제한됐을 때 429(Too Many Requests) 상태 코드를 반환
        **limit_req_status 429;**
        
        server_name api.manutd.co.kr;

        # upstream 그룹에서 지정한 서버들로 요청이 분산됨
        location / {
                proxy_pass **<http://backend>;**
        }

.
.
.
(생략)
.
# 설정 파일 재로드
$ sudo nginx -s reload

Review

짧은 시간동안 Nginx 를 익히기에 아주 좋은 강의였다. 다만 해당 강의의 특징은 강의명에서도 알 수 있듯이 비전공자도 이해할 수 있는 수준에서 강의를 진행한다는 것이다. 그 말은 즉, 전공자 또는 실무자 입장에서는 다소 강의 내용이 쉬울 수 있다는 것이다. 만약 본인이 비전공자 입장에서 새롭게 배우는 위치라면 해당 강사님의 강의를 적극 추천하지만 전공자 또는 실무라자면 예제 문서를 보고 잠깐 따라해보는 것이 좀 더 효율적이라고 느꼈다.

[Inflearn] 비전공자도 이해할 수 있는 DB 설계 입문/실전

dev.parkjh — Sun, 4 May 2025 16:08:27 +0900

inflearn : https://www.inflearn.com/course/비전공자-db-설계-입문/dashboard
수업 자료: https://jscode.notion.site/d551b000ffac42879d8630cd7edd618f

Preview

회사에서 무작정 DB 설계를 시작했고 학부시절 그리고 자격증 취득 과정에서 배웠던 개념은 머릿속에서 떠난지 오래다. 이미 어느정도 정규화 하는 절차에 대해서 알고 있었지만 개념적인 부분을 공부해서 조금 다듬을 필요가 있었다. 강의시간이 너무 길지도 않고 단순 이론에 치중하지도 않고 실무 위주의 강의를 찾던 중 해당 강의를 찾게 되어 학습하게 되었다.

Introduce

공부는 어렵게 해야 한다.

코딩 공부를 할 때 단순 듣기와 단순 코드 따라치기가 가장 비효율적인 공부 방법이다.
더 최악인 것은 따라치기를 통해 스스로가 이해하고 있는 착각을 불러 일으킨다.
따라서 공부는 어렵게 해야 한다.

효율적인 공부를 하기 위한 방법으로는 아래 방법들이 있다.

요약하기
나만의 말로 바꿔서 글을 쓴다.
남에게 설명을 한다.
그림을 도식화 한다.

위 방법들을 실천하기 위한 가장 좋은 방법은 학습한 내용을 정리하여 “블로그에 업로드” 하는 것이다.

파레토 법칙(Pareto principle)

파레토의 법칙에 따라 공부를 하는 것이 좋다.
파레토 법칙이란 현업에서 자주 사용되는 개념인 20%만 익혀도 80%의 효율을 낸다.
현업에서 사용하는 기술을 우선적으로 공부하고 현업에 돌입하여 필요한 내용만 추가적으로 공부를 하는 것이 효율적이다.

First Word 법칙

직관적으로 이해가 되지 않는 용어를 잘 정리한다.
처음 들어본 용어이거나 낯선 용어는 반드시 기록해둔다. 나중에 사전처럼 꺼내서 읽어본다.

필수 개념

데이터베이스 모델링(Database Modeling) 이란?

데이터를 어떻게 분류해서 저장할 지를 설계하는 행위
데이터베이스 설계라도고함
효율적으로 데이터를 저장하고 가져오기 위한 방법

관계형 데이터베이스 (RDBMS)의 기본 구성

테이블(Table), 컬럼(Column), 로우(Row)의 구성 요소가 있다.

PK(기본키), FK(외래키)

PK(Primary Key, 기본키)
- 특정 데이터를 식별하기 위한 값
- 중복되어서는 안 되며, 비어있어서도 안 된다.
- PK는 값이 변경되는 것을 권장하지 않는다. 따라서 현업에서는 주로 Auto Increment(숫자가 1씩 증가하는 방식)또는 UUID(랜덤값)로 설정을 많이 한다.
FK(Foreign Key, 외래키)
- 다른 테이블의 데이터와 관계를 연결하기 위한 키
- FK는 PK를 저장하는 것이 일반적이다.
- FK는 적절하지 않은 FK를 넣었을 때 에러를 발생시킨다. (참조 무결성)

데이터베이스 네이밍 규칙

테이블명, 컬럼명은 소문자로 작성한다.
snake_case를 사용한다.
축약어를 사용하지 않는다.
SQL 쿼리를 작성할 때는 예약어만 대문자로 표현하라 (SELECT, FROM, AND, OR 등등)
테이블명을 지을 때는 복수형을 사용한다. (user→users, post→posts)(선택사항)

DB 설계 핵심 원칙 및 전체 과정

아래 사항은 현재 시점에서 꼭 공부할 필요는 없다.

기본키, 후보키, 대체키, 슈퍼키
개체-관계 모델
모델링 과정 (개념적 모델링, 논리적 모델링, 물리적 모델링)
이상현상(삭제 이상, 삽입 이상, 수정 이상)
함수 종속성
제1정규형 ~ 5정규형, BCNF 정규형 / 부분적 함수 종속, 이행적 함수 종속

DB 설계 시 꼭 기억해야 할 핵심 원칙 1가지

데이터베이스를 설계할 때의 핵심은 “중복 없애기” 이다.
저장된 데이터들 중에서 모순되는 상황이 생긴 현상을 이상현상(Anomaly)라고 한다.
중복 없애기를 위한 DB 설계 방법이 정규화(Normalization) 이다.

정규화(Normalization)

데이터들 사이에서 발생한 모순의 근본적인 원인은 데이터 중복이다.
이러한 문제를 해결하려면 데이터 중복을 없애면 된다.
DB를 설계하면서 중복을 없애는 과정이 정규화이다.
제1정규형, 제2정규형, 제3정규형 등 모든 정규형은 중복을 없애게 해주는 방법이다.
현업에서는 1,2,3 정규형까지만 주로 적용한다.

DB 설계 전체 과정

저장해야 하는 데이터 파악하기
데이터베이스를 설계하기 전에 어떤 데이터를 저장해야 하는 지 파악해야 한다. 그러려면 대략적인 UI 디자인이 나와 있어야 한다. 또는 요구사항 정의서가 나와 있어야 한다.
그룹핑해서 분류하기ex) 아이디, 패스워드, 이름, 이메일 → 사용자
ex) 게시글 제목, 게시글 내용, 작성자 → 게시글
저장해야 하는 데이터를 묶어서 그룹핑할 수 있는 상위 개념을 찾는다.
6가지 규칙 적용시키면서 테이블 분리해나가기

저장할 데이터 파악하기

요구사항을 보면서 데이터에 어떤 데이터를 저장해두어야 할 지 파악하는게 가장 먼저다.
어떤 데이터를 저장해두어야 하는 지 파악해야, 어떤 방식으로 데이터를 분류해서 저장할 지 결정할 수 있다.

그룹핑해서 분류하기

저장해야 하는 데이터를 묶어서 그룹핑 할 수 있는 상위 개념을 찾아야 한다.
이렇게 그룹핑 된 하나의 그룹을 보고 데이터베이스에서는 엔티티(Entity)라고 한다.
엔티티(Entity)가 데이터베이스의 테이블(Table)이라고 생각해도 된다.

테이블로 나타내기

users (사용자)

id	email	password	name
1	test@mail.com	qwer1234!	jay
2	test1@mail.com	qwer1234!	kim

DB 설계 규칙 6가지

[규칙 1] 한 칸에는 한 가지 정보만 들어가도록 만들어라

DB 테이블을 설계 할 때 ‘한 칸에는 한 가지 정보만 들어가야 한다.’라는 규칙을 지켜야 한다. 규칙을 지키지 않은 사례는 아래와 같다.

users(사용자)

id(PK)	name	email
1	parkjh	parkjh@gmail.com, jhpark@gmail.com
2	parkmj	parkmj@gmail.com, mjpark@gmail.com

데이터를 콤마(,) 로 구분하는 것이 좋지 않은 선택인 이유

데이터를 추가,수정,조회 하는 과정에서 매번 콤마로 분류하는 복잡한 로직이 추가되어야 한다.
중복을 허용하게 될 수도 있다.

한 칸에 2개 이상의 정보가 들어가 있다면 ? → 테이블을 분리한다.

users(사용자)

id(PK)	name
1	parkjh
2	parkmj

emails(이메일)

id(PK)	email	user_id(FK)
1	parkjh@gmail.com	1
2	jhpark@gmail.com	1
3	parkmj@gmail.com	2
4	mjpark@gmail.com	2

이 과정을 보고 데이터베이스 이론에서는 제1정규형 이라고 부른다.

데이터베이스 설계는 처음 딱 고정한 대로 끝까지 가는 것이 아니라 상황에 따라 기획에 따라 변경할 수 있어야 한다.

요약

한 칸에는 한 가지 정보만 들어가야 한다.
한 칸에 두 가지 이상의 정보가 들어가있을 땐 테이블을 분리해서 FK를 활용하면 된다.
특정 테이블에 FK를 도입했을 때 규칙 1이 안 지켜진다면, 다른 테이블로 FK를 옮겨보자.
‘한 가지 정보’의 기준은 절대적이지 않다. 따라서 서비스에 맞게 판단해야 한다.

[규칙 2] 어떤 테이블에 FK를 넣어도 ‘규칙 1’을 지키지 못할 때는 중간 테이블을 하나 더 만들어라

아래 테이블의 규칙 1과 같이 적용하기에는 중복이 명확하게 제거되지 않는다.

students (학생)

id(PK)	name	courses
1	김철수	수학, 과학
2	박민지	국어, 수학
3	조혜진	국어, 과학

courses (수강과목)

id(PK)	name	student_id(FK)
1	수학	1,2
2	과학	1,3
3	국어	2,3

아래와 같이 테이블을 하나 더 추가해서 개선할 수 있다.

students (학생)

id(PK)	name
1	김철수
2	박민지
3	조혜진

courses (수강과목)

id(PK)	name
1	수학
2	과학
3	국어

students_courses → 테이블명을 동사를 생각 하면 좀 더 가독성 생긴다 (course_registrations)

id(PK)	student_id(FK)	course_id(FK)
1	1	1
2	1	2
3	2	1
4	2	3
5	3	2
6	3	3

[규칙 3] 헷갈릴 땐 관계(1:1, 1:N, N:M) 를 파악해봐라

규칙 1과 규칙 2가 헷갈릴 땐 엔티티 간의 관계를 파악한다.

엔티티 관계 파악 방법

엔티티 간에 어울리는 동사 찾기

A(주어)가 B를 ___. (A가 주어)
B(주어)가 A에 의해 ___. (B가 주어)

** 서비스의 관점에서 동사를 떠올려야한다.

1번 과정에서 찾은 동사를 활용해 적절한 단어 (하나의 or 여러개의) 찾기

하나의 A는 (하나의 or 여러 개의) B를 ___. (A의 관점)
하나의 B는 (하나의 or 여러 개의) A에 의해 ___ (B의 관점)

** 문장 처음에 시작하는 ‘하나의’ 라는 말을 반드시 붙어야 헷갈리지 않는다.

** 서비스를 어떻게 기획하냐에 따라 달라질 수 있다. 반드시 자신의 서비스에 대입해서 생각해야 한다.

관계 판단하기

A, B의 관점 전부 다 ‘하나’만 가진다면 → A:B=1:1
A의 관점에서는 ‘여러개’의 B를 가지고, B의 관점에서는 ‘하나’의 A를 가진다면 → A:B=1:N
A의 관점에서는 ‘하나’의 B를 가지고, B의 관점에서는 ‘여러개’의 A를 가진다면 → A:B=N:1
A, B 관점 전부 다 ‘여러개’를 가진다면 → A:B=N:M

아래 테이블을 예시로 관계를 파악해본다.

users(사용자)

id(PK)	name
1	parkjh
2	kimsy

emails(이메일)

id(PK)	email	user_id(FK)
1	parkjh@gmail.com	1
2	jhpark@gmail.com	1
3	kimsy@gmail.com	2
4	sykim@gmail.com	2

엔티티 간에 어울리는 동사 찾기
- 사용자(A)가 이메일(B)을 소유한다.
- 이메일(B)은 사용자(A)에 의해 소유되어 진다.
1번 과정에서 찾은 동사를 활용해 적절한 단어(하나의 or 여러개의) 찾기
- 하나의 사용자(A)는 ‘여러 개’의 이메일(B)을 소유한다.
- 하나의 이메일(B)은 ‘하나’의 사용자(A)에 의해 소유되어진다.
관계 판단하기
- 사용자 : 이메일 = 1 : N

학생, 수강 과목 예제

학생이 수강 과목을 듣는다.
수강 과목이 학생에 의해 들어진다.
한 명의 학생이 여러 개의 수강 과목을 듣는다.(들을 수 있다).
하나의 수강 과목이 여러 명의 학생에 의해 들어진다.
학생 : 수강과목 = N : M

사용자, 프로필 예제

사용자는 프로필을 등록한다.
프로필은 사용자에 의해 등록되어진다.
하나의 사용자는 하나의 프로필을 등록한다.
하나의 프로필은 하나의 사용자에 의해 등록되어진다.
사용자 : 프로필 = 1 : 1

1:1 관계의 특징

아무 테이블에 FK를 넣어도 된다.
합쳐도 되는 지 고려해봐야 한다. (어지간하면 1:1 관계로 분리하지 않는 것을 추천한다.)

1:N 관계의 특징

N 쪽의 테이블에 FK가 들어가야 한다.

N:M 관계의 특징

중간 테이블이 있어야 한다.
중간 테이블에 두 테이블의 FK가 들어가야 한다.
N:M 관계에서 중간 테이블을 추가해 1:N 관계로 바꿔 표현하게 된다.

[규칙 4] 데이터 중복이 발생하는 컬럼이 있는 지 확인해라

데이터 중복이 발생하는지 시뮬레이션을 돌려봐라 → 테이블에 임의의 데이터를 하나씩 넣어보고 분석해본다.
아래 테이블은 작성자에서 중복이 발생함을 확인한다. 사용자 테이블을 하나 만들어 중복을 제거한다.

id(PK)	subject	contents	register
1	test1	hello1	parkjh
2	test2	hello1	parkjh
3	test2	hello2	parkmj

[규칙 5] 가짜 중복과 진짜 중복을 구별해라

가짜 중복과 진짜 중복을 판단하기 위해서는 “실제 서비스에서 A 데이터의 값을 수정하면, B 데이터의 값도 수정해야 하는지 판단”하면 된다.

아래 테이블은 제목, 내용, 작성자 모두 중복이 발생하였다. 하지만 진짜 중복은 작성자 컬럼에서만 발생하였다. 판단 기준에 따르면 작성자가 변경되면 모든 데이터가 변경되어야 한다. 하지만 제목과 내용은 작성자가 변경되어도 다른 데이터를 변경할 필요는 없다.

id(PK)	subject	contents	register
1	test	hello	parkjh
2	test	hello	parkjh
3	test	hello	parkjh

[규칙 6] 숨어있는 중복을 찾아라

아래 테이블은 중복이 없는 것처럼 보이지만 만약 사용자가 게시글의 좋아요를 취소하기 위해 likes 테이블의 해당 로우를 삭제한다면 좋아요 수도 변경되어야 한다. 하지만 만약 좋아요 수가 변경되지 않는다면 여기서 중복이 발생했을 때와 동일한 단점이 존재한다. 이처럼 숨어있는 중복은 주로 집계(합계, 평균, 최대값 등)의 값에서 많이 나타난다.

posts (게시글)

id(PK)	subject	contents	likes	user_id(FK)
1	제목1	내용1	2	1

users (사용자)

id(PK)	name
1	박지후
2	조혜진

likes (좋아요)

id(PK)	user_id	post_id
1	1	1
2	2	1

숨어있는 중복을 제거하기 위해서는 ‘좋아요 수’ 컬럼을 제거하고 ‘likes’ 테이블을 활용해서 ‘좋아요 수’를 카운팅 하는 것이 좋다. 데이터 중복을 허용하면서 나름의 편리함을 가져가는 데이터 역정규화라는 것이 있다. 우선은 고려하지 않는다.

ERD(Entity Relationship Diagram)란 ?

ERD(Entity Relationship Diagram) = 엔티티(테이블) 간의 관계를 표현한 그래프

많은 개발자들이 ERD으로 소통하기 때문에 ERD를 보고 해석할 수 있어야 한다.
하지만 DB 설계를 공부하는 입장에서 현재 꼭 익힐 필요는 없다. 설계에 적응되고 활용하여도 늦지 않다.
또한 만약 혼자 작업하는 프로젝트라면 작성하는 시간을 투자할 바에 그냥 개발하며 유지/보수하는 편이 좀 더 효율적일 수도 있다.

ERD 표기 방법

Tools
- https://www.erdcloud.com
- https://dbdiagram.io/d

DB 설계 및 반영

설계한 모델을 실제 DB에 반영하는 방법은 아래와 같다.

SQL문(DDL) 활용하기
DB 관리툴 (MySQL Workbench, dbeaver) 활용하기
ORM 활용하기(JPA, TypeORM, Sequelize 라이브러리 활용)

공부 순서는 SQL → DB 관리툴 → ORM 을 활용하는 것이 좋다.

데이터 타입 (Data Type)

정수를 저장해야 할 때 INT → 계산에서 쓰는 값인지 아닌지 판별한다.
10억이 넘어가는 정수 : BIGINT
실수를 저장 : DECIMAL
문자를 저장 : VARCHAR(글자수)
6만이 넘어가는 문자를 저장 : LONGTEXT
TimeZone을 고려하지 않고 날짜 데이터만 저장하면 되는 경우 (국내 서비스) : DATETIME
TimeZone을 고려하면서 날짜 데이터를 저장해야 하는 경우 (해외 서비스) : TIMESTAMP
True, False의 형태로 저장하고 싶은 경우: TINYINT(1)
** 현업에서 잘 사용하지 않는 데이터 타입 : CHAR, FLOAT, DOUBLE, TEXT

역정규화

흔히 과도한 정규화는 성능이 저하된다고 한다.
하지만 그래도 되도록이면 정규화를 지키는 것이 좋다.
성능 저하에 대한 논의는 정량화된 데이터를 기반으로 평가해야 한다.

정량화된 데이터를 바탕으로 정규화로 인한 성능 저하가 명백하여 어느정도 중복을 허용해야 하는 상황이 생긴다면 역정규화를 수행한다.

역정규화란 성능을 향상시키기 위해 정규화된 DB를 다시 중복을 허용하는 형태로 변경하는 과정을 뜻하며, 가급적이면 최후의 수단으로 사용하는 것이 좋다. 역정규화는 매우 제한적으로 사용해야 한다. 데이터 중복으로 인한 오류(이상현상)가 발생하지 않도록 많은 노력을 해야 한다.

REVIEW

해당 강의를 처음 듣는 목적은 짧은 러닝 타임 강의를 통해 알고 있던 개념을 정리하고자 했다. 짧은 강의를 통해 알고 있던 개념을 이해하기 쉽게 정리할 수 있어서 좋았으나 좀 더 깊은 지식들을 습득하기에는 한계가 있었다. (1~5 정규화, 역정규화 등) 하지만 본 강의를 통해 후행학습 과제를 정할 수 있게 되었고 실무에서도 보다 자신있게 DB 설계를 할 수 있겠다는 자신감이 생겼다. 해당 강의에 대한 만족도가 높아서 앞으로 다른 개념들도 박재성 강사님을 통해 학습하고자 한다.

[Docker] Docker Private Image Registry

dev.parkjh — Thu, 10 Apr 2025 23:42:43 +0900

개요

도커 이미지를 저장하는 대표적인 저장소로 도커 허브(https://hub.docker.com/) 가 있다. 퍼블릭 저장소를 기본으로 제공하는 Docker Hub는 전 세계적으로 널리 사용되고 있지만, 기업 또는 개인이 자체적인 이미지 저장소로 활용하기 위해서는 Private 환경 구성이 필요한 경우가 많다.

Docker Hub는 무료 플랜 기준으로 Private 저장소를 1개만 제공하며, 추가 Private 저장소 사용이나 기업 단위 관리 기능은 유료 플랜 가입이 필요하다. 또한, 저장 용량이나 이미지 Pull 제한 등 사용 정책이 존재하기 때문에 비용이나 보안 요구 사항에 따라 별도의 Private Registry 구축을 고려하게 된다.

본 글에서는 Docker Image 를 Private 하게 관리하기 위해 Self-Hosted, AWS ECR, NCP Container Registry 을 간단하게 사용해본다.

Test Image 생성

각 Registry 테스트를 위하여 테스트용 이미지를 생성한다. 테스트에 사용하는 이미지는 hashicorp/http-echo (https://hub.docker.com/r/hashicorp/http-echo) 이미지이다. hashicorp/http-echo 는 인수를 입력받은 값을 출력하는 간단한 웹 서버이다.

아래의 Dockerfile을 하나 생성한다.

# Dockerfile

FROM hashicorp/http-echo

CMD ["-listen=:8080", "-text=hello world ver1.0"]

빌드 후 컨테이너를 실행한다.

$ docker build -t my-echo:1.0 .
$ docker run -d --name my-echo-container-v1-0 -p 8080:8080 my-echo:1.0

http://localhost:8080 혹은 http://{HOST_IP}:8080 에 접속하여 정상적으로 적용 되었음을 확인한다.

Self-Hosted

Registry 서비스 구성

docker 에서 registry 를 구성할 수 있도록 Official Image(https://hub.docker.com/_/registry) 를 제공하고 있다.

아래와 같이 run 명령어로 간단하게 실행 하거나 docker-compose.yml 을 작성하여 실행한다.

$ docker run -d --name docker-registry -p 5000:5000 registry:latest

# docker-compose.yml
version: '3.8'
services:
        docker-registry:
                image: registry:latest
                container_name: docker-registry
                restart: on-failure
                ports:
                        - "5000:5000"
                volumes:
									      - ./registry-data:/var/lib/registry

$ docker compose up -d

Image build & push

Docker Image를 빌드하고 푸시하는 가이드는 아래와 같다.

# image build
$ docker build -t {[IMAGE_NAME]:[IMAGE_TAG]} .

# tag (로컬에 있는 이미지를 업로드하기 위한 태그로 변경)
$ docker tag {[IMAGE_NAME]:[IMAGE_TAG]} {HOST_NAME}:5000/{[IMAGE_NAME]:[IMAGE_TAG]}

# push (로컬에 있는 이미지 업로드)
$ docker push {HOST_NAME}:5000/{[IMAGE_NAME]:[IMAGE_TAG]}

# 업로드 이미지 조회
$ curl -XGET localhost:5000/v2/_catalog

Image Pull

$ docker pull {HOST_NAME}:5000/{[IMAGE_NAME]:[IMAGE_TAG]}

만약 위와 같은 절차를 통해 로컬이 아닌 다른 네트워크에서 push 를 시도한다면 http: server gave HTTP response to HTTPS client 오류와 함께 push 되지 않을 것이다. 그 이유는 docker 는 기본적으로 HTTPS가 미적용된 레지스트리는 PUSH가 안된다. Sever에 **HTTPS 인증서(사설 포함)**를 발급 받거나, Client에 insecure-registries 설정해야 한다.

insecure-registries 로 HTTP 허용

pull/push 를 시도하는 클라이언트에서 아래 경로(centos 기준)에 해당 옵션을 추가하고 docker 재시작 한다.

$ vi /etc/docker/daemon.json
.
.
.

{
  "insecure-registries": [
    "{HOST_NAME}:5000"
  ]
}

$ systemctl restart docker

SSL 인증서(사설) 생성

Private Registry 를 HTTPS 적용을 위해 SSL 인증서를 생성하고 Nginx 을 통해 SSL 인증서와 계정 인증을 처리한 뒤, 내부 docker-registry로 요청을 프록시 하도록 구현한다.

ROOT 인증서(CA) 생성

$ mkdir certs & cd $_

# ca.key 생성
$ openssl genrsa -out ./certs/ca.key 2048

# ca.crt 생성
$ openssl req -x509 -new -key ./certs/ca.key -days 1000 -out ./certs/ca.crt

컨테이너 인증서 생성

# domain.key 생성
$ openssl genrsa -out ./certs/domain.key 2048

# domain.csr 생성
$ openssl req -new -key ./certs/domain.key -subj /CN={HOST_IP} -out ./certs/domain.csr

# SAN (Subject Alternative Name) 설정
$ echo subjectAltName=IP:{HOST_IP} > extfile.cnf

# 인증서 서명
$ openssl x509 -req -in ./certs/domain.csr -CA ./certs/ca.crt -CAkey ./certs/ca.key -CAcreateserial -out ./certs/domain.crt -days 10000 -extfile extfile.cnf

Nginx 컨테이너 생성

❓Nginx :가볍고 빠른 웹 서버 + 리버스 프록시 서버 + 로드밸런서

계정 파일 생성(htpasswd)

# htpasswd 설치
$ yum install httpd-tools

# htpasswd 생성
$ mkdir auth && cd $_
$ htpasswd -c htpasswd {USER_NAME}

nginx.conf 생성

$ vim nginx.conf
.
.
.
upstream docker-registry {
    server registry:5000;
}

server {
    listen 443 ssl;
    server_name {HOST_IP};

    ssl_certificate /etc/nginx/certs/domain.crt;
    ssl_certificate_key /etc/nginx/certs/domain.key;

    client_max_body_size 0;
    chunked_transfer_encoding on;

    location /v2/ {
        # 특정 docker client 차단
        if ($http_user_agent ~ "^(docker/1\\.(3|4|5(?!\\.[0-9]-dev))|Go).*$") {
            return 404;
        }

        auth_basic "registry.localhost";
        auth_basic_user_file /etc/nginx/auth/htpasswd;

        add_header 'Docker-Distribution-Api-Version' 'registry/2.0' always;

        proxy_pass <http://docker-registry>;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 900;
    }
}

nginx 컨테이너 실행

아래와 같이 run 명령어로 간단하게 실행 하거나 앞서 작성한 docker-compose.yml 에 추가 작성하여 실행한다.

$ docker run -d --name nginx -p 443:443 --link docker-registry:registry  \\
  -v $(pwd)/nginx.conf:/etc/nginx/conf.d/nginx.conf \\
  -v $(pwd)/certs/:/etc/nginx/certs \\
  -v $(pwd)/auth/:/etc/nginx/auth \\
  nginx:latest

# docker-compose.yml
.
.
.
        nginx:
                image: nginx:latest
                container_name: nginx
                ports:
                        - "443:443"
                restart: always
                depends_on:
                        - docker-registry
                volumes:
                        - ./nginx.conf:/etc/nginx/conf.d/nginx.conf
                        - ./certs/:/etc/nginx/certs
                        - ./auth/:/etc/nginx/auth

인증서 등록 (클라이언트)

# 인증서 복사
$ sudo mkdir -p /etc/docker/certs.d/10.52.254.98/
$ sudo cp domain.crt /etc/docker/certs.d/10.52.254.98/ca.crt

# Docker service 재시작
$ sudo systemctl restart docker

Docker 로그인

$ docker login {HOST_IP}

Cloud - AWS Elastic Container Registry (ECR)

AWS 에서는 Elastic Container Registry (ECR)을 이용하여 private Registry를 관리할 수 있다.

서비스에 관한 자세한 설명은 AWS ECR (https://aws.amazon.com/ko/ecr) 문서를 참고한다.

요금

AWS의 ECR은 저장소 스토리지 요금과 데이터 전송 요금이 합산되어 청구된다. 각 청구되는 기준은 아래와 같다.

저장소 스토리지 요금
- 프라이빗 리포지토리 (Private) : AWS 프리 티어 일부로 매월 500MB 1년간 무료 (초과시 월 0.10 USD / GB)
- 퍼블릭 리포지토리 (Public) : 월 50GB 항상 무료 (초과시 월 0.10 USD / GB)
데이터 전송 요금
- 프라이빗 리포지토리 (Private)
  - 데이터 수신 : 무료
  - 데이터 송신 (동일 리전) : 무료
  - 데이터 송신 (다른 리전 혹은 인터넷) : (월 USD 0.126 / GB)
- 퍼블릭 리포지토리 (Public)
  - 데이터 수신 : 무료
  - 데이터 송신 (동일 리전) : 무료
  - 데이터 송신 (다른 리전 혹은 인터넷) : 익명 사용자 월 500GB 무료, AWS 계정 사용자 월 5TB 무료 (초과시 월 0.09 USD / GB)

Repository 생성

일반 설정 - 리포지토리 이름
일반 설정 - 이미지 태그 변경 가능성
암호화 설정 - 암호화 구성

❗️ AWS Repository 생성에 앞서 IAM 계정을 생성해야 하며, aws cli 설치 및 configure 을 지정해야 한다.

Image build & push

푸시 명령 보기를 통해 아래와 같이 본인의 리포지토리에 맞는 커멘드로 사용할 수 있다.

커멘드 사용에 앞서 aws cli 설치 및 configure 을 지정한다.

# AWS CLI 설치
$ sudo yum install -y awscli

# 인증 정보 입력 (Access Key, Secret Key는 AWS 콘솔 → IAM → 사용자 → 보안 자격 증명 에서 발급 가능)
$ aws configure
.
.
.
AWS Access Key ID [None]: {AWS Access Key}
AWS Secret Access Key [None]: {AWS Secret Key}
Default region name [None]: ap-northeast-2
Default output format [None]: json

각 커멘드 가이드는 아래와 같다.

# docker login
$ aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin {AWS_ID}.dkr.ecr.ap-northeast-2.amazonaws.com

# login check
$ cat ~/.docker/config.json

# image build
$ docker build -t {[IMAGE_NAME]:[IMAGE_TAG]} .

# tag (로컬에 있는 이미지를 ECR 업로드하기 위한 태그로 변경)
$ docker tag {[IMAGE_NAME]:[IMAGE_TAG]} {AWS_ID}.dkr.ecr.ap-northeast-2.amazonaws.com/{[AWS_REPOSITORIES_NAME]:[IMAGE_TAG]}

# push (로컬에 있는 이미지 업로드)
$ docker push {AWS_ID}.dkr.ecr.ap-northeast-2.amazonaws.com/{[AWS_REPOSITORIES_NAME]:[IMAGE_TAG]}

AWS 콘솔에서 push 된 이미지를 확인한다.

Image Pull

docker pull <AWS_ID>.dkr.ecr.ap-northeast-2.amazonaws.com/{[AWS_REPOSITORIES_NAME]:[IMAGE_TAG]}

AWS의 ECR과 관련하여 좀 더 자세한 내용은 본 문서를 참고한다 (https://docs.aws.amazon.com/AmazonECR/latest/userguide/getting-started-cli.html)

Cloud - NCP Container Registry

네이버 클라우드에서는 “Container Registry”를 이용하여 Private Registry 를 관리할 수 있다.

서비스에 관한 자세한 설명은 NCP Container Registry (https://www.ncloud.com/product/containers/containerRegistry#overview) 문서를 참고한다.

요금

네이버 클라우드의 Container Registry 서비스는 기본적으로 무료이다. 다만 Image 를 Object Storage 에 쌓기 때문에 별도의 Object Storage 비용이 청구된다.

하지만 VPC 환경에서 운영할 경우 아래의 금액이 청구된다.

Registry 생성

레지스트리 이름과 버킷을 지정하여 새로운 Container Registry 를 생성한다.

❗️Container Registry 생성에 앞서 이미지 저장을 위해 사전에 Object Storage 버킷을 생성해야 한다.

Image build & push

이용 가이드를 통해 아래와 같이 본인의 레지스트리에 맞는 커멘드로 사용할 수 있다.

각 커멘드 가이드는 아래와 같다.

# docker login
$ docker login {REGISTRIES_NAME}.kr.ncr.ntruss.com
.
.
.
Username: {Access Key ID}
Password:{Secret Key}

# login check
$ cat ~/.docker/config.json

# Image build
$ docker build -t {[IMAGE_NAME]:[IMAGE_TAG]} .

# tag (AWS ECR과 다른 점은 push 할 이미지명이 리포지토리 이름은 아니다.)
$ docker tag {[IMAGE_NAME]:[IMAGE_TAG]} {REGISTRIES_NAME}.kr.ncr.ntruss.com/{[IMAGE_NAME]:[IMAGE_TAG]}

# push
$ docker push {REGISTRIES_NAME}.kr.ncr.ntruss.com/{[IMAGE_NAME]:[IMAGE_TAG]}

네이버 클라우드 콘솔에서 push 된 이미지를 확인한다.

Image Pull

# pull
$ docker pull {REGISTRIES_NAME}.kr.ncr.ntruss.com/{[IMAGE_NAME]:[IMAGE_TAG]}

NCP의 Container Registry 과 관련하여 좀 더 자세한 내용은 본 문서를 참고한다. (https://guide.ncloud-docs.com/docs/containerregistry-overview)

Ref

[Self-Hosted]

[AWS]

[nGrinder] API Performance Testing

dev.parkjh — Sat, 5 Apr 2025 16:11:37 +0900

API Performance Testing

API 성능 테스트(API Performance Testing)는 API가 높은 부하에서도 안정적으로 동작하는지 확인하는 과정이다.
주요 목표는 응답 시간(Response Time), 처리량(Throughput), 동시 사용자 수(Concurrency), 그리고 리소스 사용률(CPU, 메모리 등)을 평가하는 것이다.
주요 테스트 유형으로는 부하 테스트(Load Testing), 스트레스 테스트(Stress Testing), 스파이크 테스트(Spike Testing), 지속 테스트(Soak Testing) 가 있다.

nGrinder

nGrinder는 네이버에서 제공하는 The Grinder 기반의 오픈소스 부하 테스트 도구이며, 분산 환경에서 대규모 부하 테스트를 쉽게 수행할 수 있도록 기능을 제공한다.

구성요소

Controller
- 테스트를 관리하고 실행하는 중앙 역할
- 테스트 스크립트 작성 및 실행 제어
- Agent에게 테스트 명령을 전달하고 결과 수집
Agent
- Controller의 명령을 받아 부하(Load)를 발생시키는 역할
- 여러 Agent를 사용하여 분산 부하 테스트 가능
- 테스트 실행 중 Target Server로 요청을 전송
Target Server
- 테스트 대상 서버(API, 웹 애플리케이션 등)
- Agent에서 보내는 요청을 처리하고 성능을 평가
User
- nGrinder를 사용하는 테스트 관리자(테스터)
- Controller에서 테스트를 설정하고 결과를 분석

Architecture

사용자가 요청 → Controller가 Agent와 Target Server 설정 → Agent가 부하 테스트 실행 → 성능 데이터 수집 및 분석 흐름으로 진행된다.

자세한 내용을 nGrinder Wiki 에서 확인 가능하다. (https://github.com/naver/ngrinder/wiki/Architecture)

설치 및 환경 구성 - nGrinder Docker

nGrinder 를 설치 및 운영할 수 있는 방법은 Controller와 Agent 소스코드(https://github.com/naver/ngrinder)를 내려 받아 직접 설치하는 방법과 Docker Image 를 내려받아 container 를 생성하여 운영하는 방법 두 가지가 있다.

본 글에서는 Controller, Agent Docker Image로 Container 를 생성하여 설치 및 운영하는 방법에 대해 기술한다. 아래 docker-compose.yml 파일은 하나의 Controller 와 하나의 Agent 를 정의하였다.

# docker-compose.yml
version: '3.8'
services:
        ngrinder_controller:
                image: ngrinder/controller
                container_name: ngrinder_controller
                restart: unless-stopped
                ports:
                        - "80:80"
                        - "16001:16001"
                        - "12000-12009:12000-12009"
                volumes:
                        - ~/ngrinder-controller:/opt/ngrinder-controller
        ngrinder_agent:
                image: ngrinder/agent
                container_name: ngrinder_agent_1
                restart: unless-stopped
                depends_on:
                        - ngrinder_controller
                links:
                        - "ngrinder_controller:controller"

Controller 와 Agent 에 설정된 옵션의 의미는 아래와 같다.

controller - ports
- 80 : web service 포트
- 9010 - 9019 : Agent들이 Controller 클러스터로 연결되는 포트
- 16001 : 테스트를 하지 않는 유휴 상태의 Agent가 Controller에게 테스트 가능 메시지를 전달하는 포트
- 12000-12009 : 테스트 실행 및 종료 등 컨트롤러 명령어와 에이전트별 테스트 실행 통계를 초별로 수집하는 포트
agent - links
- ngrinder_controller:controller : Controller Docker 컨테이너 간의 네트워크 연결
controller - volumes
- Docker 컨테이너 내부의 데이터를 유지(영속화, Persistent Storage)

$ docker compose up -d 을 통해 Controller 와 Agent 컨테이너를 실행한다.

컨테이너 실행 후 http://{WEB_URL}:{PORT} 으로 접속하고 초기 ID / PW 는 admin / admin 이다.

Agent Management 탭으로 이동해서 Agent 가 정상적으로 동작하고 있음을 확인한다.

Script 작성 - Groovy

테스트에 사용할 스크립트를 작성한다. 스크립트는 Groovy, Jython으로 작성할 수 있다. Groovy는 자바와 유사하고 Jython은 파이썬과 유사하다. (본 글에서는 Groovy 기준으로 설명)

스크립트 유형 선택 후 파일을 생성하면 Sample Code가 작성되어 있다. 테스트할 API, Request Header, Request Body 등을 스크립트에서 설정할 수 있다.

인증 기능이 없는 스크립트는 예제 파일에서 일부분 수정하여 테스트가 가능하지만 인증 또는 인가 기능이 포함되어 있다면 별도로 해당 로직을 구현해야 한다.

테스트에 사용할 라이브러리와 데이터 파일을 각각 /lib, /resources 에 업로드한다. (/lib 에 추가한 파일은 자동 import)

아래 코드는 스크립트를 생성하면 자동으로 작성되어 있는 샘플 코드이다.

import static net.grinder.script.Grinder.grinder
import static org.junit.Assert.*
import static org.hamcrest.Matchers.*
import net.grinder.script.GTest
import net.grinder.script.Grinder
import net.grinder.scriptengine.groovy.junit.GrinderRunner
import net.grinder.scriptengine.groovy.junit.annotation.BeforeProcess
import net.grinder.scriptengine.groovy.junit.annotation.BeforeThread
// import static net.grinder.util.GrinderUtils.* // You can use this if you're using nGrinder after 3.2.3
import org.junit.Before
import org.junit.BeforeClass
import org.junit.Test
import org.junit.runner.RunWith

import org.ngrinder.http.HTTPRequest
import org.ngrinder.http.HTTPRequestControl
import org.ngrinder.http.HTTPResponse
import org.ngrinder.http.cookie.Cookie
import org.ngrinder.http.cookie.CookieManager

/**
* A simple example using the HTTP plugin that shows the retrieval of a single page via HTTP.
*
* This script is automatically generated by ngrinder.
*
* @author admin
*/
@RunWith(GrinderRunner)
class TestRunner {

	public static GTest test
	public static HTTPRequest request
	public static Map<String, String> headers = [:]
	public static Map<String, Object> params = [:]
	public static List<Cookie> cookies = []

	@BeforeProcess
	public static void beforeProcess() {
		HTTPRequestControl.setConnectionTimeout(300000)
		test = new GTest(1, "Test1")
		request = new HTTPRequest()
		grinder.logger.info("before process.")
	}

	@BeforeThread
	public void beforeThread() {
		test.record(this, "test")
		grinder.statistics.delayReports = true
		grinder.logger.info("before thread.")
	}

	@Before
	public void before() {
		request.setHeaders(headers)
		CookieManager.addCookies(cookies)
		grinder.logger.info("before. init headers and cookies")
	}

	@Test
	public void test() {
		HTTPResponse response = request.GET("http://please_modify_this.com", params)

		if (response.statusCode == 301 || response.statusCode == 302) {
			grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", response.statusCode)
		} else {
			assertThat(response.statusCode, is(200))
		}
	}
}

샘플 코드를 바탕으로 각각의 어노테이션이 의미하는 바는 아래와 같다.

@RunWith() : JUnit 테스트 실행기를 지정하는 역할
@BeforeProcess : 프로세스가 생성될때 실행해야 하는 동작 정의
@AfterProcess : 프로세스가 종료하기 직전에 실행해야 하는 동작 정의
@BeforeThread : 각 쓰레드가 실행된 전에 실행해야 하는 동작 정의
@AfterThread : 각 쓰레드가 종료하기 직전에 실행해야 하는 동작 정의
@Before : 모든 @Test 메소드가 실행되기 전에 실행해야 하는 동작 정의
@After : 모든 @Test 메소드가 종료된 이후 실행해야 하는 동작 정의
@Test : 테스트 동작 정의

작성한 스크립트 파일은 아래 절차를 통해 실행된다.

자세한 내용을 nGrinder Wiki 에서 확인 가능하다. (https://github.com/naver/ngrinder/wiki/Groovy-Script-Structure)

테스트 생성 및 실행

테스트에 적용하는 설정 항목은 아래와 같다.

Agent

테스트를 실행할 가상 사용자(VUser)를 실행하는 물리적 또는 가상 서버
nGrinder에서 부하를 발생시키는 역할을 하며, 여러 개의 Agent 사용 가능함.

Vuser per agent

각 Agent에서 실행할 가상 사용자(Virtual User, VUser)의 수
VUser는 실제 사용자를 시뮬레이션하여 요청을 보냄.
VUser = Agent * (Processes * Threads)
Processes
- Agent에서 실행할 프로세스 수
- 한 개의 Agent 내에서 여러 개의 프로세스를 실행하여 성능 테스트를 병렬로 수행함.
Threads
- 각 프로세스에서 실행할 스레드(쓰레드) 수
- 하나의 프로세스 안에서 여러 개의 스레드를 실행하여 부하를 증가시킬 수 있음.

Script

성능 테스트를 수행할 테스트 스크립트(Groovy, Jython 등)
실제 HTTP 요청을 보내거나, 데이터베이스에 쿼리를 실행하는 등의 테스트 로직을 정의함.

Script Resources

테스트에 필요한 추가적인 파일(JAR, CSV, JSON 등)

Target Host

부하 테스트를 수행할 대상 서버의 URL 또는 IP 주소

Duration

테스트의 실행 시간, 5분으로 설정하면 5분 동안 지속적으로 요청 수행

Run Count

특정 횟수만큼 테스트를 실행, Run Count = 1000이면 총 1000번의 요청 수행

Enable Ramp-Up

VUser가 일정한 간격으로 증가하면서 실행됨.
Initial Count (초기 사용자 수)
- 테스트 시작 시 처음 실행될 VUser 수를 설정함.
- 예: Initial Count = 10 → 처음에 10명의 VUser가 실행됨.
Initial Sleep Time (초기 대기 시간 / ms)
- 테스트가 시작된 후, VUser를 실행하기 전에 대기 시간(밀리초 단위)
- 예: Initial Sleep Time = 5000ms → 테스트 시작 후 5초 대기 후 VUser 실행
Incremental Step (증가 단계)
- 일정한 간격(Interval)마다 몇 명의 VUser를 추가할 것인지 설정함.
- 예: Incremental Step = 5 → 매번 5명의 VUser가 추가됨.
Interval (증가 간격, 초 단위)
- VUser가 증가하는 시간 간격(초 단위)을 설정함.
- 예: Interval = 10이면 10초마다 Incremental Step 만큼 VUser를 추가함.

Performance Report

Total Vusers

실행된 총 가상 사용자(VUser)의 수
부하 테스트에서 최대 동시 실행된 사용자 수를 의

TPS(Transactions Per Second, 초당 트랜잭션 수)

초당 수행된 요청 수(트랜잭션 수)
TPS가 높을수록 더 많은 요청을 처리할 수 있다는 의미 (성능이 좋다.)
일반적으로 Executed Tests / Run time(초)

Peak TPS (최대 TPS, 최고 초당 트랜잭션 수)

테스트 중에서 가장 높은 TPS(초당 요청 수)
부하가 가장 많았을 때 서버가 처리할 수 있는 최대 성능

Mean Test Time (평균 응답 시간, ms)

각 요청(트랜잭션)이 처리되는 데 걸린 평균 시간(밀리초)
클라이언트가 요청을 보낸 후 응답을 받을 때까지의 평균 지연 시간
값이 너무 크면 서버의 응답 속도가 느리다는 뜻

Executed Tests(총 실행된 테스트 수)

테스트 동안 실행된 총 요청(트랜잭션) 개수
모든 VUser가 수행한 테스트의 횟수

Successful Tests(성공한 테스트 수)

총 요청(트랜잭션) 중에서 HTTP 200 등의 정상 응답을 받은 경우 성공으로 카운트

Errors(에러 수)

HTTP 500(서버 오류) 또는 404(찾을 수 없음) 같은 에러 요청(실패한 트랜잭션) 수

Run time (테스트 실행 시간, 초 단위)

테스트가 실행된 총 시간(초 단위)

TPS Graph

X : 시간
Y : TPS

Results analysis

앞선 테스트를 통해 여러 API의 성능 데이터를 수집했다. TPS(초당 트랜잭션 수)와 MTT(평균 테스트 시간)를 통해 대략적인 성능을 짐작할 수 있지만, 이를 전체 API 대비 비교하여 분석하는 것이 중요하다.

API 성능을 평가하는 주요 지표는 다음과 같다:

Throughput (TPS, 초당 트랜잭션 수): 시스템이 처리할 수 있는 최대 요청량을 나타냄.
Latency (MTT, Mean Test Time): 하나의 요청을 처리하는 데 걸리는 평균 시간.

Saturation Point 분석

시스템의 Saturation Point (포화점) 을 파악하기 위해 Enable Ramp-Up 기능을 사용하여 vUser를 점진적으로 증가시키며 테스트를 진행한다. 포화점이란, 요청이 증가하더라도 TPS가 특정 값에 수렴하는 지점을 의미하며, 이를 통해 시스템의 임계점을 판단하고 향후 성능 개선 계획을 수립할 수 있다.

Saturation Point: 요청이 증가해도 TPS가 특정 값으로 수렴하는 지점.

TPS와 MTT를 활용한 성능 평가

TPS가 낮고 MTT가 높은 경우

시스템이 한 번에 많은 요청을 처리하지 못함 → 병목(Bottleneck) 존재 가능성
응답 시간이 길어지고 성능 저하 우려가 있음

TPS가 높고 MTT가 낮은 경우

API가 빠르게 많은 요청을 처리 가능 → 현재 시스템 성능 양호
추가적인 최적화 없이도 현재 부하를 원활히 감당 가능

데이터 기반 성능 평가 (이상치 탐지)

API의 TPS와 MTT 데이터를 활용하여 다음과 같은 통계 지표를 구하여 성능을 평가한다:

중위값 (Median): API 성능의 대표값
사분위수 (Q1, Q3): 데이터의 분포를 분석하기 위한 기준
IQR (Interquartile Range): Q3 - Q1로 계산되며, 데이터의 변동 범위를 나타냄
Lower Outlier (이상치 기준): X < Q1 - 1.5 × IQR

이러한 지표를 통해 API 성능이 전반적으로 균일한지 평가하고, 특정 API가 비정상적으로 낮은 성능을 보이는지를 분석한다.

Future Challenges

본 글을 통해 nGrinder 를 설치하고 테스트 스크립트를 통해 성능 테스트를 진행하였다. 하지만 현재 학습한 내용으로는 웹에 접속하여 수동으로 테스트를 진행해야 하는 번거로움이 존재한다. 향후 업무 효율성 및 성과를 증대 시키기 위해서는 스크립트 일괄 업로드, 테스트 원격 실행, 테스트 결과 원격지 발송 등 자동화를 구현해야 할 것이다. 자동화를 달성하기 위해 아래의 레퍼런스를 참고한다.

스크립트 파일 대량 업로드

최초 스크립트가 세팅된 docker image 를 생성하여 관리한다.
svn 저장소를 이용하여 관리한다.

테스트 원격 실행

nGrinder 에서 제공하고 있는 REST API 를 이용하여 구현한다.
Ref. https://github.com/naver/ngrinder/wiki/REST-API-QuickStart

테스트 결과 원격지 발송

nGrinder 에서 제공하고 있는 Webhook을 이용하여 구현한다.

Ref

[Kube] Kubernetes - Service / Volume (7)

dev.parkjh — Tue, 23 Jul 2024 00:07:07 +0900

본 게시글은 인프런 subicura 강사님의 초보를 위한 쿠버네티스 안내서 강의 수강 후 작성한 내용입니다.

Service

Pod은 자체 IP를 가지고 다른 Pod과 통신할 수 있지만, 쉽게 사라지고 생성되는 특징 때문에 직접 통신하는 방법은 권장하지 않는다.
쿠버네티스는 Pod과 직접 통신하는 방법 대신, 별도의 고정된 IP를 가진 서비스를 만들고 그 서비스를 통해 Pod에 접근하는 방식을 사용한다.
노출 범위에 따라 CluterIP, NodePort, LoadBalancer 타입으로 나눈다.

Service(ClusterIP)

CluterIP는 클러스터 내부에서만 접근할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  selector:
    matchLabels:
      app: counter
      tier: db
  template:
    metadata:
      labels:
        app: counter
        tier: db
    spec:
      containers:
        - name: redis
          image: redis
          ports:
            - containerPort: 6379
              protocol: TCP

---
apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  ports:
    - port: 6379
      protocol: TCP
  selector:
    app: counter
    tier: db

구분자: 하나의 YAML파일에 여러 개의 리소스를 정의할 땐 "---"를 구분자로 사용한다.

CluterIP 서비스 옵션

spec.ports.port	서비스가 생성할 Port
spec.ports.targetPort	서비스가 접근할 Pod의 Port (기본: port랑 동일)
spec.selector	서비스가 접근할 Pod의 label 조건

counter app Pod에서 redis Pod으로 접근이 되는지 테스트 해본다.

$ kubectl apply -f counter-app.yml

# counter app에 접근
$ kubectl get po
$ kubectl exec -it counter-<xxxxx> -- sh

# curl localhost:3000
# curl localhost:3000
# telnet redis 6379
  dbsize
  KEYS *
  GET count
  quit

Service를 통해 Pod과 성공적으로 연결됨을 확인한다.

$ kubectl get endpoints
$ kubectl get ep #줄여서

# redis Endpoint 확인
$ kubectl describe ep/redis

Service(NodePort)

CluterIP는 클러스터 내부에서만 접근할 수 있다.
클러스터 외부(노드)에서 접근할 수 있도록 NodePort 서비스를 사용한다.

apiVersion: v1
kind: Service
metadata:
  name: counter-np
spec:
  type: NodePort
  ports:
    - port: 3000
      protocol: TCP
      nodePort: 31000
  selector:
    app: counter
    tier: app

정의 설명

spec.ports.nodePort

노드에 오픈할 Port (미지정시 30000-32768 중에 자동 할당)

counter app을 해당 노드의 31000으로 오픈한다.

$ kubectl apply -f counter-nodeport.yml

# 서비스 상태 확인
kubectl get svc

minikube ip로 테스트 클러스터의 노드 IP를 구하고 31000으로 접근한다.

 $ curl 192.168.64.4:31000 # 또는 
 <http://192.168.64.4:31000> # 브라우저에서 접근한다.

Service(LoadBalancer) 만들기

NodePort의 단점은 노드가 사라졌을 때 자동으로 다른 노드를 통해 접근이 불가능하다는 점이다.
예를 들어, 3개의 노드가 있다면 3개 중에 아무 노드로 접근해도 NodePort로 연결할 수 있지만 어떤 노드가 살아 있는지는 알 수가 없다.
자동으로 살아 있는 노드에 접근하기 위해 모든 노드를 바라보는 Load Balancer가 필요하다.
브라우저는 NodePort에 직접 요청을 보내는 것이 아니라 Load Balancer에 요청하고 Load Balancer가 알아서 살아 있는 노드에 접근하여 NodePort의 단점을 제거한다.

apiVersion: v1
kind: Service
metadata:
  name: counter-lb
spec:
  type: LoadBalancer
  ports:
    - port: 30000
      targetPort: 3000
      protocol: TCP
  selector:
    app: counter
    tier: app

ingress

Ingress는 클러스터 외부에서 내부 서비스로 HTTP 및 HTTPS 경로를 통해 접근을 제어하는 방법이다.
Ingress는 특정 URL 경로 또는 호스트 이름을 기반으로 트래픽을 라우팅하며, 부하 분산, SSL 종단, 이름 기반 가상 호스팅 등을 제공할 수 있다.
Ingress를 사용하면 여러 서비스에 대한 접근을 하나의 IP 주소와 도메인 이름으로 관리할 수 있다. 이는 특히 여러 서비스를 운영하는 환경에서 매우 유용하다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-v1
spec:
  rules:
    - host: v1.echo.192.168.64.5.sslip.io
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: echo-v1
                port:
                  number: 3000

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-v1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: echo
      tier: app
      version: v1
  template:
    metadata:
      labels:
        app: echo
        tier: app
        version: v1
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v1
          livenessProbe:
            httpGet:
              path: /
              port: 3000

---
apiVersion: v1
kind: Service
metadata:
  name: echo-v1
spec:
  ports:
    - port: 3000
      protocol: TCP
  selector:
    app: echo
    tier: app
    version: v1

Volume (local)

지금까지 만들었던 컨테이너는 Pod을 제거하면 컨테이너 내부에 저장했던 데이터도 모두 사라진다.
MySQL과 같은 데이터베이스는 데이터가 유실되지 않도록 반드시 별도의 저장소에 데이터를 저장하고 컨테이너를 새로 만들 때 이전 데이터를 가져와야 한다.
쿠버네티스는 Volume을 이용하여 컨테이너의 디렉토리를 외부 저장소와 연결하고 다양한 플러그인을 지원하여 흔히 사용하는 대부분의 스토리지를 별도 설정없이 사용할 수 있다.

empty-dir

: 컨테이너 내부 공유

apiVersion: v1
kind: Pod
metadata:
  name: sidecar
spec:
  containers:
    - name: app
      image: busybox
      args:
        - /bin/sh
        - -c
        - >
          while true;
          do
            echo "$(date)\\n" >> /var/log/example.log;
            sleep 1;
          done
      volumeMounts:
        - name: varlog
          mountPath: /var/log
    - name: sidecar
      image: busybox
      args: [/bin/sh, -c, "tail -f /var/log/example.log"]
      volumeMounts:
        - name: varlog
          mountPath: /var/log
  volumes:
    - name: varlog
      emptyDir: {}

hostpath

: 호스트 폴더와 공유

apiVersion: v1
kind: Pod
metadata:
  name: host-log
spec:
  containers:
    - name: log
      image: busybox
      args: ["/bin/sh", "-c", "sleep infinity"]
      volumeMounts:
        - name: varlog
          mountPath: /host/var/log
  volumes:
    - name: varlog
      hostPath:
        path: /var/log

ConfigMap

컨테이너에서 설정 파일을 관리하는 방법은 이미지를 빌드할 때 복사하거나, 컨테이너를 실행할 때 외부 파일을 연결하는 방법이 있다.
쿠버네티스는 ConfigMap으로 설정을 관리한다.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: prometheus
    metrics_path: /prometheus/metrics
    static_configs:
      - targets:
          - localhost:9090

먼저, ConfigMap을 만들고 --from-file 옵션을 이용하여 file을 설정으로 만든다.

# ConfitMap 생성 (configmap == cm)
$ kubectl create cm my-config --from-file=config-file.yml

# ConfitMap 조회
$kubectl get cm

# ConfigMap 내용 상세 조회
$ kubectl describe cm/my-config

생성한 ConfigMap을 /etc/config 디렉토리에 연결한다.

apiVersion: v1
kind: Pod
metadata:
  name: alpine
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep"]
      args: ["100000"]
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: my-config

volume을 연결하여 배포하고 확인한다.

$ kubectl apply -f alpine.yml

# 접속 후 설정 확인
$ kubectl exec -it alpine -- ls /etc/config
$ kubectl exec -it alpine -- cat /etc/config/config-file.yml

Secret

쿠버네티스는 ConfigMap과 유사하지만, 보안 정보를 관리하기 위해 Secret을 별도로 제공한다.
ConfigMap과 차이점은 데이터가 base64로 저장된다는 점이다.

# secret 생성
$ kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

# secret 상세 조회
$ kubectl describe secret/db-user-pass

# -o yaml로 상세 조회
$ kubectl get secret/db-user-pass -o yaml

# 저장된 데이터 base64 decode
$ echo 'MXEydzNlNHI=' | base64 --decode

설정한 Secret을 환경변수로 연결한다.

apiVersion: v1
kind: Pod
metadata:
  name: alpine-env
spec:
  containers:
    - name: alpine
      image: alpine
      command: ["sleep"]
      args: ["100000"]
      env:
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: db-user-pass
              key: username.txt
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-user-pass
              key: password.txt

배포 후 환경변수를 확인한다.

$ kubectl apply -f alpine-env.yml

# env 확인
$ kubectl exec -it alpine-env -- env

참고사이트

[Kube] Kubernetes - Deployment (6)

dev.parkjh — Mon, 22 Jul 2024 23:27:25 +0900

본 게시글은 인프런 subicura 강사님의 초보를 위한 쿠버네티스 안내서 강의 수강 후 작성한 내용입니다.

Deployment (배포)

Deployment는 쿠버네티스에서 가장 널리 사용되는 오브젝트이다.
ReplicaSet을 이용하여 Pod을 업데이트하고 이력을 관리하여 롤백(Rollback)하거나 특정 버전(revision)으로 돌아갈 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v1

# Deployment 생성
kubectl apply -f echo-deployment.yml

# 리소스 확인
kubectl get po,rs,deploy

#---------
NAME                               READY   STATUS    RESTARTS   AGE
pod/echo-deploy-5f9566c4d9-7pmrp   1/1     Running   0          9s
pod/echo-deploy-5f9566c4d9-j97jb   1/1     Running   0          9s
pod/echo-deploy-5f9566c4d9-l47nd   1/1     Running   0          9s
pod/echo-deploy-5f9566c4d9-sxchs   1/1     Running   0          9s

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/echo-deploy-5f9566c4d9   4         4         4       9s

NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/echo-deploy   4/4     4            4           9s
#---------

image: ghcr.io/subicura/echo:v1 을 image: ghcr.io/subicura/echo:v2 으로 변경 후 다시 배포

# Deployment 생성
kubectl apply -f echo-deployment.yml

# 리소스 확인
kubectl get po,rs,deploy

#---------
NAME                               READY   STATUS    RESTARTS   AGE
pod/echo-deploy-54c84dd47b-x44s6   1/1     Running   0          4s
pod/echo-deploy-54c84dd47b-xdx22   1/1     Running   0          6s
pod/echo-deploy-54c84dd47b-xf6sd   1/1     Running   0          6s
pod/echo-deploy-54c84dd47b-xpzx8   1/1     Running   0          4s

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/echo-deploy-54c84dd47b   4         4         4       6s
replicaset.apps/echo-deploy-5f9566c4d9   0         0         0       99s

NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/echo-deploy   4/4     4            4           99s
#---------

Deployment 버전 업데이트 절차

Deployment 새로운 버전을 업데이트하기 위해 레플리카 셋을 이용한다.
1. 버전을 업데이트하면 새로운 ReplicaSet을 생성하고 해당 ReplicaSet이 새로운 버전의 Pod을 생성한다.
2. 새로운 ReplicaSet을 0 -> 1개로 조정하고 정상적으로 Pod이 동작하면 기존 ReplicaSet을 4 -> 3개로 조정한다.
3. 새로운 ReplicaSet을 1 -> 2개로 조정하고 정상적으로 Pod이 동작하면 기존 ReplicaSet을 3 -> 2개로 조정한다.
4. 새로운 ReplicaSet을 2 -> 3개로 조정하고 정상적으로 Pod이 동작하면 기존 ReplicaSet을 2 -> 1개로 조정한다.
5. 최종적으로 새로운 ReplicaSet을 4개로 조정하고 정상적으로 Pod이 동작하면 기존 ReplicaSet을 0개로 조정한다
6. 업데이트 완료

버전관리

Deployment는 변경된 상태를 기록한다.

# 히스토리 확인
$ kubectl rollout history deploy/echo-deploy

# revision 1 히스토리 상세 확인
$ kubectl rollout history deploy/echo-deploy --revision=1

# 바로 전으로 롤백
$ kubectl rollout undo deploy/echo-deploy

# 특정 버전으로 롤백
$ kubectl rollout undo deploy/echo-deploy --to-revision=2

배포 전략 설정

Deployment 다양한 방식의 배포 전략이 있다.
롤링업데이트(RollingUpdate) 방식을 사용할 때 동시에 업데이트하는 Pod의 개수를 변경한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deploy-st
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 3 
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v1
          livenessProbe:
            httpGet:
              path: /
              port: 3000

참고 사이트

https://subicura.com/k8s/guide/deployment.html

[Kube] Kubernetes - Pod (5)

dev.parkjh — Mon, 22 Jul 2024 00:44:31 +0900

본 게시글은 인프런 subicura 강사님의 초보를 위한 쿠버네티스 안내서 강의 수강 후 작성한 내용입니다.

Pod 이란 ?

Pod은 쿠버네티스에서 관리하는 가장 작은 배포 단위
쿠버네티스와 도커의 차이점은 도커는 컨테이너를 만들지만 쿠버네티스는 컨테이너 대신 Pod을 만듬.
Pod은 한개 또는 여러 개의 컨테이너를 포함함.

Pod 생성 맛보기

저장소에 저장된 이미지로 Pod 만들기

# Pod 생성
$ kubectl run echo --image ghcr.io/subicura/echo:v1

# 생성된 Pod 보기
$ kubectl get pod/echo

# Pod의 상세내용 보기
$ kubectl describe pod/echo

# echo의 로그 보기
$ kubectl logs -f echo

# echo 컨테이너 접속
$ kubectl exec -it echo -- sh

# Pod 제거
$ kubectl delete pod/echo

YAML로 Pod 생성하기

apiVersion: v1
kind: Pod
metadata:
  name: echo
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1

version, kind, metadata, spec는 리소스를 정의할 때 반드시 필요한 요소이다.

정의 설명 예

version	오브젝트 버전	v1, app/v1, networking.k8s.io/v1, ...
kind	종류	Pod, ReplicaSet, Deployment, Service, ...
metadata	메타데이터	name과 label, annotation(주석)으로 구성
spec	상세명세	리소스 종류마다 다름

# Pod 생성
$ kubectl apply -f echo-pod.yml

# 생성된 Pod 보기
$ kubectl get pod/echo

# Pod의 상세내용 보기
$ kubectl describe pod/echo

# echo의 로그 보기
$ kubectl logs -f echo

# echo 컨테이너 접속
$ kubectl exec -it echo -- sh

# Pod 제거
$ kubectl delete pod/echo

컨테이너 상태 모니터링

livenessProbe

컨테이너가 정상적으로 동작하는지 체크하고 정상적으로 동작하지 않는다면 컨테이너를 재시작하여 문제를 해결한다.
정상이라는 것은 여러 가지 방식으로 체크할 수 있는데 아래 예시에서는 http get 요청을 보내 확인하는 방법을 사용한다.

apiVersion: v1
kind: Pod
metadata:
  name: echo-lp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /not/exist # 고의적으로 존재하지 않는 path 기입
          port: 8080 # 고의적으로 존재하지 않는 포트 기입
        initialDelaySeconds: 5
        timeoutSeconds: 2 # Default 1
        periodSeconds: 5 # Defaults 10
        failureThreshold: 1 # Defaults 3

# Pod 생성
$ kubectl apply -f echo-pod.yml

# 생성된 Pod 보기
$ kubectl get pod/echo

# ---- 
# 정상적으로 응답하지 않기 때문에 CrashLoopBackOff 상태로 변경된다.
NAME      READY   STATUS             RESTARTS     AGE
echo-lp   0/1     **CrashLoopBackOff**   2 (8s ago)   23s
#-----

# Pod 제거
$ kubectl delete pod/echo

readinessProbe

컨테이너가 준비되었는지 체크하고 정상적으로 준비되지 않았다면 Pod으로 들어오는 요청을 제외한다.
livenessProbe와 차이점은 문제가 있어도 Pod을 재시작하지 않고 요청만 제외한다는 점이다.

apiVersion: v1
kind: Pod
metadata:
  name: echo-rp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      readinessProbe:
        httpGet:
          path: /not/exist # 고의적으로 존재하지 않는 path 기입
          port: 8080 # 고의적으로 존재하지 않는 포트 기입
        initialDelaySeconds: 5
        timeoutSeconds: 2 # Default 1
        periodSeconds: 5 # Defaults 10
        failureThreshold: 1 # Defaults 3

# Pod 생성
$ kubectl apply -f echo-pod.yml

# 생성된 Pod 보기
$ kubectl get pod/echo

# ---- 
# pod을 재시작하지 않고 제외한다. (READY 0)
NAME      READY   STATUS    RESTARTS   AGE
echo-rp   0/1     Running   0          16s
#-----

# Pod 제거
$ kubectl delete pod/echo

livenessProbe + readinessProbe

보통 livenessProbe와 readinessProbe를 같이 적용한다.
상세한 설정은 애플리케이션 환경에 따라 적절하게 조정한다.

apiVersion: v1
kind: Pod
metadata:
  name: echo-health
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /
          port: 3000
      readinessProbe:
        httpGet:
          path: /
          port: 3000

다중 컨테이너

pod은 여러개의 컨테이너를 가질 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: counter
  labels:
    app: counter
spec:
  containers:
    - name: app # app 컨테이너
      image: ghcr.io/subicura/counter:latest
      env:
        - name: REDIS_HOST
          value: "localhost"
    - name: db # DB 컨테이너
      image: redis

# Pod 생성
$ kubectl apply -f echo-pod.yml

# Pod 목록 조회
$ kubectl get pod

# ------
# 2개의 컨테이너가 실행됨.
NAME      READY   STATUS    RESTARTS   AGE
counter   2/2     Running   0          27s
# ------

# Pod 로그 확인
$ kubectl logs counter app
$ kubectl logs counter db

# 컨테이너 접속
$ kubectl exec -it counter -c app -- sh

$ curl localhost:3000 # 1씩 redis에 기록하여 증가함

# redis에 접근하여 데이터 확인
$ telnet localhost 6379 
GET count
quit

# Pod 제거
$ kubectl delete -f echo-pod.yml

ReplicaSet(복제셋)

Pod을 단독으로 만들면 Pod이 어떤 문제(서버가 죽어서 Pod이 사라졌다던가)가 생겼을 때 자동으로 복구되지 않는다.
이러한 Pod을 정해진 수만큼 복제하고 관리하는 것이 ReplicaSet 이다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: echo-rs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
      tier: app
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v1

ReplicaSet은 label을 체크해서 원하는 수의 Pod이 없으면 새로운 Pod을 생성한다. 이를 설정으로 표현하면 다음과 같다.

정의 설명

spec.selector	label 체크 조건
spec.replicas	원하는 Pod의 개수
spec.template	생성할 Pod의 명세

위 예시 코드를 바탕으로 해석하면 app: echo, tier: app이라는 pod이 없으면 template에 정의된 내용을 생성한다.

# ReplicaSet 생성
$ kubectl apply -f echo-rs.yml

# 리소스 확인
$ kubectl get pod,replicaset

# ------
# ReplicaSet과 Pod이 함께 생성됨.
NAME                READY   STATUS    RESTARTS   AGE
pod/echo-rs-hm8tb   1/1     Running   0          57s

NAME                      DESIRED   CURRENT   READY   AGE
replicaset.apps/echo-rs   1         1         1       57s
# ------- 

# 라벨 확인
$ kubectl get pod --show-labels
# --------
NAME            READY   STATUS    RESTARTS   AGE     LABELS
echo-rs-hm8tb   1/1     Running   0          7m25s   app=echo,tier=app
# ---------

# app의 라벨을 제거
$ kubectl label pod/echo-rs-hm8tm app-

$ kubectl get pod --show-labels # 새로운 pod이 생성된다.

스케일 아웃

replicas: 1 을 replicas: 4 으로 변경
레플리카 셋은 label 단위로 확인하기 때문에 label이 겹치지 않게 정의 해야 한다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: echo-rs
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v1

참고 사이트

https://subicura.com/k8s/guide/pod.html#컨테이너-상태-모니터링

[Kube] Kubernetes - kubectl 명령어 (4)

dev.parkjh — Fri, 19 Jul 2024 00:25:56 +0900

본 게시글은 인프런 subicura 강사님의 초보를 위한 쿠버네티스 안내서 강의 수강 후 작성한 내용입니다.

apply

: 원하는 상태를 적용한다. 보통 -f 옵션으로 파일과 함께 사용한다.

$ kubectl apply -f [파일명 또는 URL]

-o : 출력 형태 변경 (wide, yaml, json)
—show-labels: 레이블 확인

get

: 리소스 목록을 보여준다. get pod, service 와 같이 여러 TYPE 입력 가능하다.

$ kubectl get [TYPE]

describe

: 리소스의 상태를 자세하게 보여준다.

$ kubectl describe [TYPE]/[NAME] 또는 [TYPE][NAME]

delete

: 리소스를 제거한다.

$ kubectl delete [TYPE]/[NAME] 또는 [TYPE][NAME]

logs

: 컨테이너 로그 확인

$ kubectl logs [POD_NAME]

-f : 실시간으로 확인
-c : pod에 여러개의 컨테이너가 있는 경우 컨테이너 지정

exec

: 컨테이너에 명령어를 전달. 컨테이너에 접근할 때 주로 사용함.

$ kubectl exec [-it] [POD_NAME] — [COMMAND]

-c : pod에 여러개의 컨테이너가 있는 경우 컨테이너 지정

config

: kubectl 설정 관리. 관리하고 있는 쿠버네티스가 여러개일 때, 현재 컨텍스트를 확인하고 특정 컨텍스트로 변경 할 때

$ kubectl config current-context
$ kubectl config use-context minikube

기타

$ kubectl api-resources # 전체 오브젝트 종류 확인
$ kubectl explain pod # 특정 오브젝트 설명 보기