꾸준히 공부중

[haproxy] 클라이언트 IP 유지하기

시리어스강 — Tue, 29 Jul 2025 20:57:42 +0900

쿠버네티스에 배포한 워크로드에 대한 접근을 사내 L4 장비에 연계하여 하고 있는데, 사내에서 제공되는 L4 장비의 기능에 미흡한 부분도 있고(ex. 요청 실패 시 retry, redispatch 불가) L4 장비에 대한 조작 권한이 없어 로드 밸런서 대상 그룹 변경이 필요할 때(ex. 클러스터 업그레이드) 인프라팀의 지원을 기다려야 하는 상황을 벗어나기 위해 haproxy를 통해 리버스 프록싱을 하는 방안을 마련 중에 있다.

그런데 haproxy를 도입하면서 클라이언트의 IP가 haproxy의 주소로 덮어써지는 문제가 있어서, 이를 해결하기 위한 방안을 공부하며 겸사겸사 포스팅도 해보려고 한다.

클라이언트 IP 변조 확인

테스트

테스트를 위한 트래픽 흐름: client → haproxy → apache → application
- apache 대신 k8s ingress나 istio 등으로 테스트하는게 실제 서비스 환경과 비슷했겠지만, 배보다 배꼽이 더 커질 것 같아서 비교적 간단하게 구성을 했다.

sample

haproxy.cfg

frontend main
        bind *:80
        default_backend app
        mode tcp

backend app
        # apache
        server app1 192.168.64.148:80 check
        mode http

haproxy → apache 호출 시, X-Forwarded-For(XFF) 헤더는 포함되지 않은 것을 확인할 수 있다.

apache → application 호출 시, XFF 헤더에 haproxy의 주소가 세팅. 이로 인해 어플리케이션은 haproxy IP를 클라이언트 IP로 착각하는 상황 발생할 수 있다.

방안 1. XFF header

클라이언트가 요청을 보낼 때, 클라이언트 주소를 XFF 헤더에 저장하여 HTTP 메세지를 릴레이
클라이언트의 HTTP API 호출 방식을 변경해야되므로, 실효성이 있을진 의문

sample

클라이언트 측에서 API 호출 시, XFF 사용

# XFF 헤더에 클라이언트 IP 세팅
$ curl -H "X-Forwarded-For: 192.168.64.146" ubuntu.test.cluster/client-ip

haproxy → apache 호출 시, XFF 헤더에 클라이언트 IP가 세팅

apache → application 호출 시, apache 설정에 따라 XFF 헤더에 클라이언트 IP와 haproxy의 IP가 세팅

방안 2. haproxy forwardfor option

haproxy option forwarfor 사용 시, haproxy가 클라이언트 IP를 XFF 헤더에 삽입
HTTP 헤더를 추가하는 방식이므로, HTTP 모드에서 사용 가능

sample

haproxy.cfg

frontend main
    bind *:80
    default_backend app
    mode tcp

backend app
    option forwardfor ✅
    mode http

haproxy → apache 시, XFF 헤더에 클라이언트 IP가 세팅
- 클라이언트에서 XFF 헤더를 추가할 필요가 없음

apache → application 시, XFF 헤더에 클라이언트 IP와 haproxy의 IP가 세팅

방안 3. haproxy forwarded option

option forwarded 사용 시, haproxy가 forwarded 헤더를 서버로 전송되는 요청에 삽입
- forwarded 헤더는 XFF 헤더의 표준화된 버전이지만, 실제 사용 빈도는 적음
HTTP 헤더를 추가하는 방식이므로, HTTP 모드에서 사용 가능

sample

haproxy.cfg

frontend main
        bind *:80
        default_backend app
        mode tcp


backend app
        option forwarded by-expr src ✅
        mode http

haproxy → apache 호출 시, forwarded 헤더에 by 구문으로 클라이언트 IP가 추가

forwarded 헤더보다는 XFF 헤더를 주로 사용하기 때문에, apache → application 호출 부분은 생략

방안 4. PROXY protocol → 이번 포스팅의 핵심!

Proxy Protocol은 HAProxy Technologies에서 개발한 네트워크 프로토콜로, TCP 연결에 헤더를 추가하여 클라이언트 IP 주소를 보존
단, 이 방법을 사용하려면 발신자와 수신자 모두 이 프로토콜을 지원하고 활성화가 필요
- 이번 테스트에서 사용한 Apache의 경우, Proxy Protocol 모듈 활성화 필요

sample: HTTP

haproxy.cfg
- 서버와 통신 시, proxy protocol을 사용
- HTTP 헤더를 추가하는 방식이 아니므로 backend의 모드는 tcp로 설정

frontend main
        bind *:80
        default_backend app
        mode http


backend app
        server app1 192.168.64.148:80 check send-proxy ✅
        mode tcp ✅

apache conf
- proxy protocol 활성화

LoadModule proxy_protocol_module /home/ubuntu/mod-proxy-protocol/.libs/mod_proxy_protocol.so ✅

...

<VirtualHost *:80>
  ServerName ubuntu.test.local

  ProxyProtocol On ✅
  
  ProxyPass / http://192.168.64.147:8080/
  ProxyPassReverse / http://192.168.64.147:8080/
</VirtualHost>

haproxy → apache 호출 시, HTTP API 호출 이전에 프록시 프로토콜 관련 정보 세팅

apache → application 호출 시, XFF 헤더에 클라이언트 IP를 추가

proxy protocol의 장점 ✅

HTTP 헤더의 값을 추가해서 클라이언트 IP를 보존하는 방식의 문제는 HTTP API를 사용하지 않으면 클라이언트 IP를 보존할 수 없다는 것인데, proxy protocol을 통해 TCP/IP를 활용해 메세지를 전송하는 모든 상위 계층 프로토콜에서도 클라이언트 IP 주소를 보존할 수 있음
HTTP 하위 계층에서 동작하는 방식이므로, HTTPS를 통한 API를 호출할 경우에도 SSL Bridging이 필요없음

sample: HTTPS

haproxy.cfg

frontend tls_main
        bind *:443
        default_backend tls_app
        mode tcp

backend tls_app
        balance roundrobin
        server app1 192.168.64.148:443 check send-proxy ✅
        mode tcp ✅

apache conf

<VirtualHost *:443>
  ServerName ubuntu.test.local

  ProxyProtocol On ✅

  SSLEngine on ✅
  SSLCertificateFile ../certs/server.crt
  SSLCertificateKeyFile ../certs/server.key
  SSLCACertificateFile ../certs/root.pem

  ProxyPass / http://192.168.64.147:8080/
  ProxyPassReverse / http://192.168.64.147:8080/
</VirtualHost>

haproxy → apache 호출 시, TLS 통신 전에 source address와 destination address를 먼저 전달한다.

apache(SSL termination) → application 호출 시, XFF 헤더에 클라이언트 IP 추가

참고 자료 ‍♂️

[linux] 일반 유저로 1024 미만의 포트 사용하기

시리어스강 — Sun, 21 Apr 2024 10:19:16 +0900

지난 글에 이어서 일반 유저로 1024 미만의 포트(== privileged 포트)를 사용하는 것에 대해 정리해보려고 한다. 결과부터 얘기하면 커널 파라미터를 조정하는 방식으로 구성할 예정이다.

안되는거 알아요

1. 기본 설정으로 일반 유저가 privileged 포트를 사용할 경우

먼저 nginx 컨테이너의 포트를 privileged 포트 중 하나에 바인딩하면 어떤 문제가 발생하는지 알아보자. 테스트 환경은 Ubuntu 22.04.4 LTS이다.

먼저 nginx 이미지를 받고

$ podman pull docker.io/ngin

privileged 포트 중 하나인 443 포트에 컨테이너의 80번 포트를 바인딩하면

$ podman run --rm -d --name nginx -p 443:80 docker.io/library/nginx

다음과 같은 메세지와 함께 컨테이너가 뜨지 않는 것을 확인할 수 있다.

Error: rootlessport cannot expose privileged port 443,
you can add 'net.ipv4.ip_unprivileged_port_start=443' to /etc/sysctl.conf (currently 1024), 
or choose a larger port number (>= 1024): listen tcp 0.0.0.0:443: bind: permission denied

에러 메세지를 보면 알 수 있듯이 net.ipv4.ip_unprivileged_port_start 값을 /etc/sysctl.conf에 추가하거나, 1024 이상 포트를 사용해야 한다.

2. 커널 파라미터 조정

커널 라파미터란 커널의 작동 방식을 제어하는 방법으로, 커널 파라미터를 핸들링하기 위해 sysctl 커맨드를 활용하고 설정 값은 /etc/sysctl.conf에서 수정 및 확인할 수 있다.

1024 이상의 포트를 사용하는게 우리의 목적이 아니므로, 에러 메세지에서 나온 것처럼 커널 파라미터(net.ipv4.ip_unprivileged_port_start)를 추가하는 방식으로 문제를 해결해보자.

먼저 privileged 포트가 아닌 포트는 몇 번부터인지 설정하는 net.ipv4.ip_unprivileged_port_start 파라미터부터 확인해보면 1024로 나오는 것을 알 수 있는데, 이는 일반 계정은 1024 포트부터 사용할 수 있다는 뜻이다.

$ sysctl net.ipv4.ip_unprivileged_port_start
net.ipv4.ip_unprivileged_port_start = 1024

해당 커널 파라미터을 어떻게 설정하냐에 따라 일반 유저가 사용할 수 있는 포트의 범위가 정해지는데, 443 포트를 바인딩할 예정이므로 설정 파일(/etc/sysctl.conf)에 443으로 설정하면 된다. 참고로 해당 설정 파일은 기본적으로 root만 수정할 수 있다.

net.ipv4.ip_unprivileged_port_start 파라미터를 이전에 설정했는지 확인한 뒤에, 설정된 값이 없으면 443으로 설정한다. → 당연하지만 기존에 설정된 값이 있으면 그 값을 수정한다.

$ cat /etc/sysctl.conf | grep net.ipv4.ip_unprivileged_port_start

# 아래 커맨드는 root 권한으로 수행해야 한다
$ echo 'net.ipv4.ip_unprivileged_port_start=443' >> /etc/sysctl.conf

그리고 root 권한으로 수정된 커널 파라미터를 로드한다.

$ sysctl -p
net.ipv4.ip_unprivileged_port_start = 443

3. 일반 유저로 privileged 포트 사용하기

이전 단계를 통해 unprivileged 대상이 되는 포트의 시작점이 443으로 바뀐 것을 알 수 있다.

$ sysctl net.ipv4.ip_unprivileged_port_start
net.ipv4.ip_unprivileged_port_start = 443

그러므로 일반 계정이 443 포트를 사용해도 된다는 것을 확인할 수 있다!

당연하지만 설정한 커널 파라미터보다 낮은 포트는 privileged 포트가 되므로, 일반 계정으론 사용할 수 없다.

참고 자료 ‍♂️

[linux] 유저 권한으로 서비스 실행하고 로그아웃에도 서비스 유지하기

시리어스강 — Sat, 20 Apr 2024 14:10:31 +0900

개인 서버라면 root 계정이나 sudo 커맨드를 고민 없이 사용하지만, 실무에서는 서버 관리자가 아니라면 그러기가 쉽지 않다. 그렇다고 매번 서버 관리자에게 작업을 요청할 수 없으니, 유저 권한으로 할 수 있는 것들은 최대한 해야하겠지… ‍↕️

이번 포스팅에서는 유저 권한으로 서비스를 실행하는 방법과 계정 로그아웃 상황에서도 서비스를 유지하는 방법에 대해 정리해본다.

네네, 압니다요

1. 테스트 스크립트 생성

유저 서비스로 등록할 테스트 스크립트(→ 1초 간격으로 현재 시간을 tmp 경로에 남김)는 다음과 같다. 해당 스크립트를 유저의 홈 경로(~/test.sh)에 저장하여 사용할 것이다.

#!/bin/bash

while true; do
  echo `date` >> /tmp/date.log
  sleep 1
done

스크립트 실행을 위해서 실행 권한도 변경해준다.

$ chmod u+x ~/test.sh

2. 서비스 유닛 파일 생성

유저 레벨의 서비스 유닛 파일 경로는 ~/.config/systemd/user에 저장해서 사용한다. 디렉토리가 없다면 생성해서 서비스 유닛 파일을 저장한다.

$ mkdir -p ~/.config/systemd/user

서비스 유닛 파일(~/.config/systemd/user/user-test.service)은 이전 단계에서 생성된 파일을 실행하도록 구성했다.

[Unit]
Description=Test User-Level Service

[Service]
ExecStart=/home/foo/test.sh
Restart=always

[Install]
WantedBy=default.target

3. 서비스 실행

이제 추가한 서비스 유닛 파일을 다음 명령어를 통해 로드하고

$ systemctl --user daemon-reload

서비스를 실행한다!

$ systemctl --user start user-test

서비스의 상태와 실행 결과를 확인하면 문제 없이 잘 수행되는 것을 알 수 있다.

서비스 상태

의도한대로 1초마다 현재 시간을 잘 찍어준다.

4. 유저 로그아웃에도 서비스 유지하기

여기까지 했으면 유저 권한으로 서비스를 잘 실행했을 수도 있다고 볼 수 있지만, 문제는 유저가 로그아웃을 하게되면 서비스가 멈추게 된다. → 이번 포스팅을 작성한 계기이다.

서비스를 실행한 계정에서 로그아웃을 하면, 서비스가 일정 시간이 지난 후에 멈추는 것을 확인할 수 있다.

다시 로그인을 한 뒤 서비스 상태를 확인해보면 inactive로 변경된 것을 볼 수 있다.

서비스를 유저가 로그아웃을 해도 계속 실행되도록 하기 위해서는 아래의 명령어를 사용하면 된다.

$ loginctl enable-linger $USER

그러면 유저의 Linger 속성이 yes로 변경되고, 유저가 로그아웃을 해도 유저 서비스가 유지된다.

참고로, lingersms 남다/계속되다라는 뜻

테스트 결과를 살펴보면, 유저가 로그아웃을 해도 서비스가 유지되고 다시 접속해 서비스 상태를 확인해도 active인 것을 알 수 있다.

[linux] 오프라인 환경(air gap)을 위한 yum repository 구축하기

시리어스강 — Sun, 24 Mar 2024 21:12:55 +0900

컨테이너 기반 서비스 운영 업무를 맡게 되면서 air gap 환경에 OCP와 OKD 설치를 진행하게 되었는데, 설치하는 과정 중에 yum repository를 구축하는 부분이 있어 연습 겸 포스팅을 해보려고 한다.

air gap 환경에선 신경 쓸게 곱절은 늘어나는거 같다

1. 테스트 개요

air gap 환경을 위해 다음와 같은 순서로 테스트 환경을 구축할 것이다. 테스트를 위해 aws를 사용했는데, aws를 사용하지 않을 경우 1, 3번은 다른 방식으로 구성해도 당연히 괜찮다.

aws의 private subnet에 서버/클라이언트용 인스턴스 생성
NAT gateway를 통해 필요한 패키지를 yum repository가 될 인스턴스에 다운로드
NAT gateway를 제거하여 private subnet 내에 있는 인스턴스를 air gap 상태로 변경
이전 단계에서 구성한 yum repository 정보를 클라이언트 인스턴스에 추가
패키지 다운로드

2. 테스트 인스턴스 생성

air gap 환경으로 구축을 위해 private subnet에 서버와 클라이언트가 될 인스턴스를 생성했다. 테스트 인스턴스의 OS는 Amazon Linux를 선택했다.

3. yum repository 구성

yum repository 구축

아파치 웹 서버의 기본 디렉토리인 /var/www/html를 사용해도 되지만, 별도의 디렉토리에 rpm을 다운받아서 사용할 것이다.

$ sudo yum install -y createrepo
$ sudo mkdir -p /app/rpms
$ sudo createrepo /app/rpms

패키지(rpm) 다운로드

샘플로 다운 받을 패키지는 구성한 인스턴스에 없는 htop, tmux, ansible이다.

$ sudo yumdownloader --resolve --downloaddir=/app/rpms htop tmux ansible

repository 업데이트

$ sudo createrepo --update /app/rpms

httpd 설치

클라이언트 인스턴스에서 접속할 수 있도록 웹 서버를 설치한다.

$ sudo yum install -y httpd

참고로 테스트 환경의 아파치 버전은 다음과 같다.

httpd 설정(httpd.conf) 변경

기존에 테스트 환경에 아파치 웹 서버를 사용하고 있다면, 각자의 환경에 맞춰 수정해서 사용하면 된다. 중요한 것은 DocumentRoot를 패키지를 설치한 경로로 설정하는 것이다.

DocumentRoot 수정

# DocumentRoot "/var/www/html"
DocumentRoot "/app/rpms"

Document 속성 추가

<Directory "/app/rpms">
    AllowOverride None
    Options Indexes # 보안 이슈로 사용 주의. 관련 내용은 이후에 나올 "패키지 확인" 부분 참고
    Require all granted
</Directory>

추가 설정 파일 제외

# IncludeOptional conf.d/*.conf

httpd 재기동

$ sudo systemctl restart httpd

패키지 확인

웹 서버로 요청을 보내면 설치한 패키지 리스트들을 볼 수 있다. 참고로 실습 결과를 보여주기 위해 httpd.conf에서 파일 목록 리스트를 노출하도록 설정(Directory - Options Indexes)을 해서 해당 리스트가 보이는거지만, 보안을 위해서는 해당 옵션을 사용하지 않는 것이 좋다.

$ curl localhost:80

4. air gap 환경 구성

변경 전

클라이언트 인스턴스에서 외부 요청을 보낼 경우, 요청이 처리가 되는 것을 확인할 수 있다.

$ curl -I https://google.com

오프라인 환경(air gap) 구축

오프라인 환경 구축을 위해 NAT gateway를 삭제했다.

이후 외부로 요청을 보낼 경우, 정상적으로 처리되지 않고 타임아웃이 발생한다.

당연히 리눅스 패키지도 다운이 안된다.

5. 클라이언트 인스턴스에서 패키지 다운로드

이제 air gap 환경이 구축되었으니, 클라이언트 인스턴스에서 이전 단계에 구축한 yum repository 설정을 추가해 테스트를 진행해보자.

기존 repository 삭제

물론 삭제 대신 백업을 해도 된다.

$ sudo rm /etc/yum.repos.d/*

yum repository 추가

구축한 yum repository를 바라볼 수 있도록 설정을 추가한다.

$ sudo bash -c 'cat <<EOF > /etc/yum.repos.d/air-gap-repo.repo
[air-gap-repo]
name=air-gap-repo
baseurl=http://[repository ip]
gpgcheck=0
enabled=1
EOF'

yum repository 추가 확인

repository가 추가된 것을 확인할 수 있다.

$ yum repolist 
repo id                repo name
air-gap-repo           air-gap-repo ✅

패키지 다운로드

yum repositoy에 받아둔 htop, tmux, ansible을 설치하면 air gap 환경이지만 정상적으로 설치가 되는 것을 볼 수 있다

$ sudo yum install -y htop tmux ansible

당연하지만, 준비되지 않은 패키지(stress)는 설치할 수 없다.

$ sudo yum install -y stress

패키지 설치 확인

패키지가 잘 설치된 것을 확인할 수 있다.

$ yum list --installed | egrep "htop|tmux|ansible"

[container] 리눅스 기능을 활용해 컨테이너 만들어보기

시리어스강 — Fri, 22 Mar 2024 22:51:55 +0900

쿠버네티스 관련 공부를 하며 파드에 대한 기본 요소를 설명한 부분을 봤는데, 꽤나 흥미로운 주제라 이번 기회에 리눅스/컨테이너에 대해 공부하는 겸 리눅스 기능을 활용해 컨테이너를 만들어보려고 한다.

저도 그렇습니다

1. 개요

작업 순서

실습 환경 구축
root 디렉토리 변경
데이터 제공 및 컨테이너 데이터 영속화
프로세스 격리
네트워크 격리
리소스 제한

주사용 기능

chroot

Change Root Directory
현재 실행 중인 프로세스와 차일드 프로세스 그룹에서 루트 디렉토리를 변경한다.
이렇게 수정된 환경에서 실행되는 프로그램은 지정된 디렉토리 트리 밖의 파일들에 일반적으로는 접근이 불가능한다.

mount

파일 시스템을 지정된 위치(마운트 위치)에서 사용 가능하게 만든다.

unshare

새로운 네임스페이스에서 프로그램을 실행한다.

cgroup

Control Groups
프로세스들의 리소스 사용(cpu, memory, disk i/o, network 등)을 제한하고 격리시킨다.

2. 실습 환경 구축

이번 포스팅의 목적은 특정 os에서 발생하는 문제를 트러블 슈팅하는게 아니므로, 실습을 하기 편한 환경을 선택했다.

사족을 달자면, docker container로 실습 환경을 구축하려고 했지만, proc 디렉토리를 마운트할 때 permission 이슈로 실습이 의도된대로 되지 않아 multipass로 vm을 생성했다. 그리고 ubuntu 22.04.6 LTS로 실습을 진행하다가, cgroup 설정 관련 이슈로 20.04를 선택했다.

command

# 20.04.6 LTS
multipass launch 20.04 --name test-instance

3. chroot를 사용해 루트 디렉토리 변경

목표

지정된 디렉토리 밖의 파일에는 접근하지 못하도록 루트 디렉토리를 변경한다.

작업 순서

실행할 프로그램과 프로그램이 실행돼야 하는 파일 시스템의 위치 결정한다.
프로세스가 실행될 환경을 생성한다. → bash 같이 필요한 리눅스 프로그램을 새로운 루트로 불러온다.
실행하고 싶은 프로그램을 chroot 처리된 위치로 복사한다.

command

container=/tmp/container
mkdir -p $container/{bin,lib,proc}

cp /usr/bin/{kill,ps} $container/bin
cp /bin/{bash,ls} $container/bin
cp -r /lib/* $container/lib

sudo mount -t proc proc $container/proc
sudo chroot $container /bin/bash

결과

루트 디렉토리에서에서 ls 명령어를 사용하면, 컨테이너 내에 있는 파일만 노출되는 것을 볼 수 있다.

4. mount를 활용해 데이터 제공 및 컨테이너 데이터 영속화

목표

생성한 컨테이너로 특정 데이터를 가져온다.
컨테이너 데이터를 영속화한다.

command

container=/tmp/container
mkdir -p $container/{bin,lib,proc,data}          # data 디렉토리 추가

cp /usr/bin/{kill,ps} $container/bin
cp /bin/{bash,ls} $container/bin
cp -r /lib/* $container/lib

sudo mount -t proc proc $container/proc
mkdir /tmp/test-data                             # 테스트 데이터 추가
touch /tmp/test-data/{dummy1,dummy2}             # 테스트 데이터 추가
sudo mount --bind /tmp/test-data $container/data # mount
sudo chroot $container /bin/bash

결과

도커 볼륨과 같이 컨테이너 내에 데이터를 제공하거나, 컨테이너 내에 있는 데이터를 영속화할 수 있게 되었다.

✅ 참고: 컨테이너 삭제

컨테이너에 기능을 점진적으로 추가하는 과정에서 컨테이너를 삭제하고 다시 만들게 되는데, 아래와 같이 컨테이너를 삭제하는 스크립트를 만들어서 사용했다.

#!/bin/bash

sudo umount /tmp/container/proc
sudo umount /tmp/container/data
rm -rf /tmp/container
rm -rf /tmp/test-data

5. unshare를 활용해 프로세스 격리

이전 과정을 통해 생성한 컨테이너의 경우, chroot 커맨드를 사용해 루트로 지정된 디렉토리 밖의 디렉토리에 접근 할 수는 없지만 다른 프로세스를 kill 할 수 있다. 이것이 실제 컨테이너라면 전체 클러스터를 중단시킬 수 있는 취약점이 될 수 있다.

취약점 sample

분할된 화면 중 위에 있는 것이 chroot 처리된 프로세스인데, 해당 프로세스에서 외부에 있는 프로세스(아래에 있는 분할 화면인 vi 프로세스)를 kill을 할 수 있다.

목표

컨테이너화된 운영 환경을 구축할 때 우선적으로 해결해야 하는 문제 중 하나가 격리(isolation)이다.
이를 위해 unshare 명령어를 사용해 chroot-bash를 프로세스 공간이 완전히 격리된 터미널에서 실행한다.
즉, 고립된 프로세스를 만든다.

현재 상태

이전에 생성한 컨테이너에서 ps -ax 커맨드를 통해 프로세스를 조회할 경우, 컨테이너 외부의 프로세스를 조회할 수 있는 것을 확인할 수 있다.

command

unshare을 통해 PID 네임스페이스를 만든다.

container=/tmp/container
mkdir -p $container/{bin,lib,proc,data}

cp /usr/bin/{kill,ps} $container/bin
cp /bin/{bash,ls} $container/bin
cp -r /lib/* $container/lib

sudo mount -t proc proc $container/proc
mkdir /tmp/test-data                             
touch /tmp/test-data/{dummy1,dummy2}             
sudo mount --bind /tmp/test-data $container/data 

# unshare 커맨드 추가
sudo unshare -fp --mount-proc=$container/proc chroot /tmp/container /bin/bash

결과

ps -ax 커맨드를 통해 새로운 네임스페이스에서 프로세스가 실행됐음을 확인할 수 있다.

6. unshare를 활용해 네트워크 격리

이전 과정을 통해 프로세스를 다른 프로세스들과 격리했지만, 여전히 같은 네트워크를 사용한다.

현재 상태

컨테이너(위 분할 화면)와 컨테이너 프로세스를 띄운 인스턴스(아래 분할 화면)가 동일한 네트워크 설정을 사용하는 것을 알 수 있다.

목표

unshare 명령어를 통해 네트워크를 격리한다.

command

unshare -n 옵션을 통해 네트워크 네임스페이스를 만든다.

container=/tmp/container
mkdir -p $container/{bin,lib,proc,data}

cp /usr/bin/{kill,ps,ip,curl} $container/bin # ip, curl 커맨드 추가
cp /bin/{bash,ls} $container/bin
cp -r /lib/* $container/lib

sudo mount -t proc proc $container/proc
mkdir /tmp/test-data                             
touch /tmp/test-data/{dummy1,dummy2}             
sudo mount --bind /tmp/test-data $container/data 

# unshare 커맨드의 n 옵션 추가
sudo unshare -fpn --mount-proc=$container/proc chroot /tmp/container /bin/bash

결과

컨테이너 내 별도의 네트워크 네임스페이스가 생성된 것을 확인할 수 있다.

7. cgroup을 활용해 리소스 제한

목표

cgroup를 통해 컨테이너의 리소스를 제한한다.

command

컨테이너 생성

container=/tmp/container
mkdir -p $container/{bin,lib,proc,data}

cp /usr/bin/{kill,ps,ip,curl,stress} $container/bin # stress 커맨드 추가
cp /bin/{bash,ls} $container/bin
cp -r /lib/* $container/lib

sudo mount -t proc proc $container/proc
mkdir /tmp/test-data                             
touch /tmp/test-data/{dummy1,dummy2}             
sudo mount --bind /tmp/test-data $container/data 

sudo unshare -fpn --mount-proc=$container/proc chroot /tmp/container /bin/bash

컨테이너 외부에서 컨테이너의 리소스 제한. 예시에서는 cpu를 100ms(cpu.cfs_period_us) 주기로 30ms(cpu.cfs_quota_us) 동안 실행할 수 있도록 설정했다. 즉, 0.3cpu를 사용한다.

sudo cgcreate -g cpu:container
sudo cgset -r cpu.cfs_quota_us=30000 container # cpu.cfs_period_us=100000
sudo sh -c "echo {컨테이너 bash pid} > /sys/fs/cgroup/cpu/container/tasks"

결과

리소스 제한 전

리소스 제한 후에는 cpu를 적게 사용하는 것을 확인할 수 있다.

참고 자료 ‍♂️

[o11y] OpenTelemetry, Jaeger을 활용해 spring-boot 어플리케이션 분산 추적해보기

시리어스강 — Sun, 28 Jan 2024 22:39:56 +0900

사내에서 어플리케이션 모니터링 관련하여 기존에 사용하던 상용 APM과 별개로, OpenTelemetry(OTel) 기반의 Observability 환경을 준비해보자라는 의견이 있어 개인 공부 겸 포스팅을 해보려고 한다.

Baeldung 글을 참고하여, OTel과 Jaeger를 활용해 어플리케이션을 어떻게 분산 추적(distributed tracing)하는지 아주아주 간단한 예제로 살펴보자

관찰하자

1. 기본 개념

예제를 살펴보기 전에 주로 언급할 개념들에 대해 간단히 살펴보면 다음과 같다. → 각 잡고 보자면 개념만으로도 살펴봐야할 내용들이 많겠지만, 이번 포스팅의 목적은 어플리케이션을 OTel과 Jaeger로 살펴보기 위함이니 간략히 정리했다.

OpenTelemetry(OTel)

OTel은 API, SDK 및 도구 모음으로써, 이를 활용해 소프트웨어의 성능과 동작을 분석하는데 도움이 되는 텔레메트리 데이터(metric, log, trace)를 측정(instrument), 생성(generate), 수집(collect), 내보낼 수(export) 있다.

OTel Collector

OTel의 핵심 구성 요소 중 하나로써, OTel Collectors를 통해 텔레메트리 데이터를 수신, 처리, 내보내는 방법을 벤더사에 구애받지 않고(vendor-agnostic) 구현할 수 있다. 따라서 여러 agent/collector를 실행, 운영, 유지 관리할 필요가 없다.

뒤에서 살펴볼 샘플 어플리케이션에서는 OTel Collector를 통해 Jaeger로 텔레메트리 데이터를 보내지만, 위 그림에서 볼 수 있듯이 프로메테우스나 다른 Observability 백엔드로 데이터를 처리하고 내보낼 수 있다.

분산 추적(Distributed tracing)

분산 추적이란 분산 시스템을 통해 전달되는 데이터 요청을 관찰하는 것이다. 분산 추적을 통해 개발자는 마이크로서비스 전반에서 발생하는 요청 경로를 추적할 수 있다.

Jaeger

분산 추적 가시성 플랫폼(Distributed tracing observability platform) → 개념만 봐서는 쉽게 와닿지 않을 수 있는데, 이후 살펴볼 Jaeger 화면을 보면 어떤 역할을 하는지 쉽게 이해할 수 있다.

트레이스/스팬(trace/span)

트레이스는 어플리케이션을 구성하는 서비스에서 처리하는 단일 요청의 진행 상황을 추적하는 것을 뜻한다. 스팬은 트레이스의 작업 단위인데, 요청이 시스템을 통과할 때 관련된 개별 서비스 또는 구성 요소가 수행하는 작업을 나타낸다. → 개념과 위 그림을 함께 보면 훨씬 이해하기 쉬울 것 같다.

다운스트림/업스트림

어떤 항목이 다른 항목에 가치를 더하거나 의존하는 경우, 이를 다운스트림에 해당한다.

소프트웨어 의존 관계로 예를 들면, 컴포넌트 C는 컴포넌트 A와 B의 기능을 임포트하고 자신의 가치를 추가해 다운스트림 컴포넌트가 된다.

마이크로서비스로 예를 들면, 서비스 A가 서비스 B를 의존하므로 다운스트림이 된다. 이후에 살펴볼 어플리케이션도 이와 동일한 구성으로 되어 있다.

2. 어플리케이션

분산 추적을 위해 어플리케이션은 두 개(업스트림/다운스트림)로 나누어 구성했다. 모든 내용을 열거하기엔 분량이 많아 생략한 내용들도 있으므로, 세부 구현 내용은 github을 참고하면 된다.

build.gradle 설정

dependencyManagement {
    imports {
        mavenBom 'org.springframework.cloud:spring-cloud-dependencies:2021.0.5'
        mavenBom 'org.springframework.cloud:spring-cloud-sleuth-otel-dependencies:1.1.2'
    }
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation ('org.springframework.cloud:spring-cloud-starter-sleuth') {
        exclude group: 'org.springframework.cloud', module: 'spring-cloud-sleuth-brave'
    }
    implementation 'org.springframework.cloud:spring-cloud-sleuth-otel-autoconfigure'
    implementation 'io.opentelemetry:opentelemetry-exporter-otlp:1.23.1'
}

build.gradle 설정은 두 어플리케이션이 동일하다. 특이 사항이라면, spring-cloud-sleuth는 brave라는 분산 추적 라이브러리를 사용하는데 이를 OTel로 대체하기 위해 종속성에서 제외한다.

그리고 spring-boot-starter-actuator 의존성의 경우 프로젝트를 구성하며 헬스 체크를 위해 넣었는데, 제외시켜도 무방하다.

시퀀스 다이어그램

상호 작용 과정을 요약하자면 다음과 같다.

다운스트림 어플리케이션

상품 정보를 불러올 수 있는 API(/product/{id})를 호출하면,

@RestController
@RequestMapping("/product")
public class ProductController {
    ...

    @GetMapping(path = "/{id}")
    public Product product(@PathVariable long id) {
        log.info("getting product and price details with product id = {}", id);
        return productRepository.findProductById(id);
    }
}

가격 정보를 불러 올 수 있는 업스트림 어플리케이션의 API를 호출해서, 데이터를 가지고 오는 형태로 되어 있다.

public class PriceClient {
    private final RestTemplate restTemplate;
    ...

    public Price price(long id) {
        log.info("fetching price details with product id = {}", id);
        String url = String.format("%s/price/%d", baseUrl, id);

        return restTemplate.getForEntity(url, Price.class)
                .getBody();
    }
}

업스트림 어플리케이션

가격 정보를 불러올 수 있는 API(/price/{id})를 제공한다.

@RestController
@RequestMapping("/price")
public class PriceController {
    ...

    @GetMapping(path = "/{id}")
    public Price price(@PathVariable long id) {
        log.info("get price details for product id = {}", id);
        return priceRepository.findPriceById(id);
    }
}

테스트 데이터

호출 데이터의 경우 별도의 DB를 사용하지 않고, repository 빈이 생성된 이후에 특정 데이터를 메모리에 저장해서 사용하는 방식으로 구성되어 있다.

상품과 가격 데이터를 보면 상품 ID와 가격 ID가 동일한 ID를 사용하는데, 업스트림 어플리케이션에서 에러가 발생하는 케이스를 살펴보기 위해, 100005 ID의 상품은 가격 데이터가 빠져있다.

상품 ID	상품명	가격 ID	가격	할인률
100001	apple	100001	12.5	2.5
100002	pears	100002	10.5	2.1
100003	banana	100003	18.5	2.2
100004	mango	100004	18.5	2.2
100005	test	-	-	-

호출 샘플

업스트림 어플리케이션의 포트는 18080으로 설정하고, 다운스트림 어플리케이션의 포트는 18081로 설정해두었다.

정상 요청

에러 요청

3. 어플리케이션 Dockerfile

업스트림 어플리케이션

FROM adoptopenjdk/openjdk11:alpine

ARG APP_JAR=upstream-0.0.1-SNAPSHOT.jar

COPY build/libs/${APP_JAR} /app/${APP_JAR}
WORKDIR /app
ENTRYPOINT ["java", "-jar", "upstream-0.0.1-SNAPSHOT.jar"]

openjdk11 이미지를 기반으로, 빌드된 어플리케이션 jar를 특정 경로로 복사한 뒤 jar를 실행하도록 구성되어 있다. 다운스트림 어플리케이션의 구성도 jar 이름만 다르고, 동일하게 되어있다.

여기까지 준비했다면, 컨테이너 기반으로 서비스를 호출해 볼 수도 있다.

4. Spring Sleuth 구성

Spring Sleuth 설정을 통해 트레이스를 OTel Collector로 내보낼 수 있다.

application.yml

spring:
  sleuth:
    otel:
      config:
        trace-id-ratio-based: 1.0
      exporter:
        otlp:
          endpoint: http://collector:4317

trace-id-ratio-based 은 수집된 스팬의 샘플링 비율을 정의한 속성인데, 1.0으로 설정할 경우 모든 스팬을 내보낸다는 의미이다.

그리고 OTel endpoint로 텔레메트리 데이터를 보내기 위한 설정이 있는데, endpoint의 경로는 이후에 살펴볼 docker-compose 내 설정을 참고하면 된다.

5. OTel Collector 설정

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  jaeger:
    endpoint: jaeger-service:14250
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers:  [ otlp ]
      processors: [ batch ]
      exporters:  [ jaeger ]

exporter의 경우, 예제에서 Jaeger로 분산 추적을 할 예정이므로 Jaeger로 설정한다. endpoint 경로는 이후에 살펴볼 docker-compose 내 설정을 참고하면 된다.

서비스 섹션 내 processors의 batch 옵션은 데이터를 더 잘 압축하고, 데이터 전송에 필요한 발신 연결 수를 줄이는데 활용된다.

receiver는 OTLP를 사용하는데, gRPC 또는 HTTP를 통해 데이터를 수신하는 것으로 보면 된다.

6. docker-compose를 활용한 서비스 구성

서비스 기동은 docker-compose를 활용할 것이다.

docker-compose

version: "3.3"

services:
  upstream-service:
    platform: linux/amd64
    build: upstream/
    ports:
      - "18080:18080"
  downstream-service:
    platform: linux/amd64
    build: downstream/
    ports:
      - "18081:18081"
  collector:
    image: otel/opentelemetry-collector:0.72.0
    command: [ "--config=/etc/otel-collector-config.yml" ]
    volumes:
      - ./otel-config.yml:/etc/otel-collector-config.yml
    ports:
      - "4317:4317"
    depends_on:
      - jaeger-service
  jaeger-service:
    image: jaegertracing/all-in-one:latest
    ports:
      - "16686:16686"
      - "14250"

upstream-service / downsteam-service는 어플리케이션 부분으로, 특이 사항이라면 샘플 코드를 작성한 단말이 애플 Mac M1을 사용해서 docker-compose 내에 platform을 linux/amd64로 설정해두었는데 다른 환경에서 테스트가 필요하다면 이 부분에 대한 수정이 필요할 수 있다!

collector는 이전에 작성한 OTel Collector 설정 파일을 기반으로 OTel Collector를 기동하는 부분이다. ports로 노출한 포트는 receiver가 데이터를 수신할 포트로, 4317의 경우 gRPC이다.

jaeger-service는 Jaeger를 기동하는 부분으로 16886 포트는 Jaeger UI이고, 14250 포트는 데이터를 수집하기 위한 포트이다.

7. 서비스 기동

서비스 기동은 어플리케이션을 빌드한 후 docker-compse up 명령어로 실행하면 된다. github에 올려둔 샘플 코드에서는 startup.sh 스크립트로 한번에 실행할 수 있다.

#!/bin/sh

../gradlew downstream:build upstream:build
docker-compose up --build

서비스 기동 확인

$ docker ps | grep opentelemetry
CONTAINER ID   IMAGE                                                COMMAND                  CREATED   STATUS              PORTS                                                    NAMES
...            opentelemetry-setup-with-jaeger-upstream-service     "java -jar upstream-…"   ...       Up About a minute   0.0.0.0:18080->18080/tcp                                 opentelemetry-setup-with-jaeger-upstream-service-1
...            opentelemetry-setup-with-jaeger-downstream-service   "java -jar downstrea…"   ...       Up About a minute   0.0.0.0:18081->18081/tcp                                 opentelemetry-setup-with-jaeger-downstream-service-1
...            otel/opentelemetry-collector:0.72.0                  "/otelcol --config=/…"   ...       Up About a minute   0.0.0.0:4317->4317/tcp, 55678-55679/tcp                  opentelemetry-setup-with-jaeger-collector-1
...            jaegertracing/all-in-one:latest                      "/go/bin/all-in-one-…"   ...       Up About a minute   .., 0.0.0.0:16686->16686/tcp, 0.0.0.0:50201->14250/tcp   opentelemetry-setup-with-jaeger-jaeger-service-1

8. 분산 추적

이제 모든 준비가 끝났으니 분산 추적을 해보자.

요청 성공

먼저 다운스트림 어플리케이션의 API(ex. http://<server-ip>:18081/product/100003)를 호출하면 아래와 같은 로그를 확인할 수 있다.

opentelemetry-setup-with-jaeger-downstream-service-1  | 2024-01-28 ... INFO [downstream-service,✅232b74791301ad3d39e16851314b57ba, 13a2ebe57954e543] 1 --- [io-18081-exec-5] c.example.controller.ProductController   : getting product and price details with product id = 100003
opentelemetry-setup-with-jaeger-downstream-service-1  | 2024-01-28 ... INFO [downstream-service,✅232b74791301ad3d39e16851314b57ba, 13a2ebe57954e543] 1 --- [io-18081-exec-5] c.example.repository.ProductRepository   : get product from product repo with product id = 100003
opentelemetry-setup-with-jaeger-downstream-service-1  | 2024-01-28 ... INFO [downstream-service,✅232b74791301ad3d39e16851314b57ba, 13a2ebe57954e543] 1 --- [io-18081-exec-5] com.example.api.client.PriceClient       : fetching price details with product id = 100003
opentelemetry-setup-with-jaeger-upstream-service-1    | 2024-01-28 ... INFO [upstream-service,✅232b74791301ad3d39e16851314b57ba, 7a923b69bf0d1e7f] 1 --- [io-18080-exec-3] com.example.controller.PriceController   : get price details for product id = 100003
opentelemetry-setup-with-jaeger-upstream-service-1    | 2024-01-28 ... INFO [upstream-service,✅232b74791301ad3d39e16851314b57ba, 7a923b69bf0d1e7f] 1 --- [io-18080-exec-3] com.example.repository.PriceRepository   : find price from price repo with product id = 100003

로그를 자세히 살펴보면 다운스트림과 업스트림 어플리케이션에서 남기는 로그에 동일한 ID(✅)가 남아있는 것을 볼 수 있는데, 이것이 트레이스 ID이다. 이를 통해, 하나의 호출로 여러 마이크로서비스를 호출하는 환경에서 요청 흐름을 살펴볼 수 있다. 참고로 트레이스 ID 옆에 있는 ID( )는 스팬 ID이다.

이 같은 정보를 확인할 수 있는 이유는 어플리케이션 의존성으로 추가했던 Spring Cloud Sleuth가 API 호출 시, 트레이스 ID 및 스팬 ID를 HTTP 헤더에 추가해주기 때문이다.

Jaeger UI를 통해 내용을 살펴보면, 트레이스 ID가 232b747인 요청에 대한 정보를 확인할 수 있고

특정 트레이스 ID에 대해서 스팬 ID를 포함하여 더 많은 정보를 확인해 볼 수 있다.

요청 실패

성공 요청에 대한 트레이스 모니터링도 해보았으니, 실패 요청에 대한 모니터링도 해보자.

상품 ID가 100005로 상품 정보를 요청할 경우, 가격 정보가 없어 업스트림 어플리케이션에서 404 에러를 내도록 구성 되어있다.

이를 Jaeger UI에서 살펴보면, 빨간색 표시가 뜨면서 에러가 발생했음을 알 수 있다.

스팬 정보에서 HTTP status code도 확인 가능하다.

9. 정리

어플리케이션 개발부터 OTel, Jaeger를 통한 분산 추적까지 해보았는데, 하나의 포스팅에 담기에는 꽤나 많은 양이었던 것 같다. 분량상 설명이 생략된 부분도 있긴 하지만, 그래도 나처럼 어플리케이션을 띄워보면서 이해하는걸 선호하는 분들에게 어떤 식으로든 도움이 되었으면 좋겠다.

많은 내용들이 있었지만, 그 중에서 개인적으로 중요하다고 생각되는 트레이스 데이터의 흐름을 요약하는 걸로 이번 포스팅을 마치겠다.

트레이스 데이터 흐름 요약

1. 유저가 `다운스트림` 어플리케이션의 상품 조회 API를 호출
2. `다운스트림`/`업스트림` 어플리케이션에서 `Collector`로 트레이스 데이터 전송(4317 port)
3. `Collector`는 `Jaeger` 엔드포인트를 통해 트레이스 데이터를 `Jaeger` 백엔드로 전송(14250 port)
4. 로그 및 `Jaeger` UI를 통해 분산 추적

샘플 코드

https://github.com/seriouskang/spring-boot-in-action/tree/main/opentelemetry-setup-with-jaeger

참고 자료 ‍♂️

[회고] 2023년 회고와 2024년의 목표

시리어스강 — Sat, 6 Jan 2024 11:19:16 +0900

지난 해를 돌이켜보며 회고를 해보자라는 계획은 예전부터 해왔지만, 조금 귀찮기도 했고 불편한 상황들은 외면하고 싶은 심정도 있어 각잡고 해본 적은 없었다.

그런데 요즘 가장 즐겨보는 유튜버의 영상을 보고 생각이 바뀌었다. 영상을 요약하자면 “중학교 때까지 성적이 좋지 않던 유도 선수 이원희가 성적을 높일 수 있었던 계기가 본인시합을 돌려보며 자신에 대해서 파악한 것”이라고 한다.

누군가는 회사에선 시키는 일만하고 돈만 벌면 된다고 하지만, 나는 회사에 있는 동안 즐거웠으면 좋겠고 그건 보통 맡은 일을 기술적으로 잘 해냈을 때 만족감이 높았다. 결국 내가 발전하고 행복하기 위해 번거롭더라도 2023년을 돌아보고, 2024년에는 뭘할지 정해보려고 한다.

회고와 목표 요약

2023년에는

2022년에 이어서 유지보수하기 좋은 코드를 작성하기 위한 지식을 실무에서 적극 활용했다.
컴포트존에서 벗어나기 위한 선택을 했고, 회사에서의 역할이 백엔드 개발자에서 SRE 개발자로 바뀌었다.
그에 따라 쿠버네티스와 관련된 업무를 담당하게 되었다.

2024년에는

정기적으로 프로필을 정리해 내 상황에 대한 점검을 해보려고 한다.
쿠버네티스, 퍼블릭 클라우드 그리고 대규모 트래픽 처리와 관련된 학습을 할 것이다.
오프라인 커뮤니티 모임과 행사에 참여하여 인사이트를 얻어보려고 한다.
고민을 통해 해결할 수 있는 문제가 아닌 상황에서는 “그냥 그렇구나”라는 마음가짐을 가질 것이다.

2023년 회고

직장 생활을 하며 무난하게 보낸 해는 거의 없었지만, 2023년에는 부서가 바뀌고 업무도 조정 되면서 유독 많은 일들이 있었다.

유지보수하기 좋은 코드를 작성하기 위한 지식을 실무에 적용

책과 강의로 학습했던 TDD, DDD, 클린 아키텍처 등을 22년부터 23년까지 실무에 적용하며, 유지보수하기 좋은 코드를 작성하는데 필요한 기술들을 적극적으로 활용할 수 있는 시간이었다.

그리고 NEXTSTEP의 TDD, 클린 코드 with Java 강의를 통해 레거시 코드를 어떻게 리팩토링하는지, 깔끔한 코드를 작성하기 위해서는 어떻게 하면 좋을지 코드 리뷰 기반으로 배울 수 있었다. 수업이 있는 8주간 퇴근 이후의 개인 시간과 주말을 대부분 갈아넣었는데, 힘들기보다는 개발에 몰입했던 과정이 정말 즐거웠다.

조금 아쉬운 점이라면 현재는 롤이 변경되어 개발과는 조금 멀어졌으나, 내 베이스는 백엔드 개발이라고 생각하고 다시 개발자의 역할을 해야하는 상황이 온다면 기쁜 마음으로 수행할 것이다.

백엔드 개발에서 SRE로

기존에 있던 부서가 다른 부서로 통합되며, 업무가 백엔드 개발에서 SRE로 변경되었다. 2023년의 주 역할은 부서 내 각 파트의 어플리케이션을 컨테이너 오케스트레이션 플랫폼 위에 얹기 위해 필요한 일들을 수행했다.

예컨대 CI/CD 환경을 구성한다거나, 쿠버네티스 매니페스트 파일을 작성하거나, 컨테이너 오케스트레이션 플랫폼 업그레이드 등을 진행했다. 더불어 사내 DR 시스템을 퍼블릭 클라우드로 이관하는 준비를 하고 있어 그에 대한 PoC도 수행했다.

2023년에는 기존에 하던 업무와 신규 업무를 병행해서 100% 역할이 변경된건 아니지만, 이전부터 일을 해오던 동료 분을 봤을 때는 어플리케이션 개발 외에 필요한 것들은 다 처리하는 것 같다

컴포트존에서 벗어나기

거의 이직에 가까운 역할 변화가 있었는데, 부서가 통합되며 몇가지 선택할 수 있는 옵션 중 하나였기 때문에 결국 내가 선택한 일이다. 그런 선택을 한 이유는 기존에 내가 맡은 업무에서 이미 많은 부분을 리팩토링했고 업무 자체도 익숙해진 상태라, 컴포트존에서 벗어나 새로운 것들을 배워보자라는 생각이었다.

결론적으로는 컴포트존에서 벗어나긴 했지만, 너무 많이 벗어났던 건지 배우는 건 많지만 그만큼 스트레스를 받고 있는건 사실이다

기존에는 요구사항을 받아 어플리케이션을 개발하고 CI만 해두면 그 이후의 과정은 다른 분들이 맡아주셨지만, 이제는 반대로 컨테이너 오케스트레이션과 더불어 웹 서버/로드 밸런서 설정, DNS, 인증서, 서버 계정별 세부 권한 설정 등 이전에는 크게 염두하지 않았던 운영에 필요한 지식이 필요하게 되었다.

최근 백명석님의 글에서 배우는 것과 성과에 대한 내용을 보게 되었는데, 내가 처한 상황이랑 비슷해 많은 공감과 힘을 얻었다.

요약하자면, “새로운 기술을 배울 때는 이전에 익숙한 기술을 사용할 때보다 성과가 떨어질 수 있는데(고통의 계곡), 그 상황에서 빠져나오면 기하급수적으로 성장할 수 있다”는 것이다.

더 큰 성장을 하기 위해 선택한 길이기 때문에, 어느 정도의 압박은 있더라도 고통의 계곡이 새로운 컴포트존이 될 수 있도록 노력해보려고 한다.

쿠버네티스 학습

컨테이너 기반 서비스가 주된 역할 중에 하나이기 때문에, 쿠버네티스에 대한 학습을 했다. 자격증 자체는 실무에서 크게 도움이 되지 않는다는 것은 알고 있지만, 데드라인을 정해 전반적인 개요를 살펴보기엔 자격증을 따는 것(== 사비를 쓰는 것)이 괜찮은 방법이라 생각해서 CKA도 취득했다

퍼블릭 클라우드 PoC를 수행하며 관리형 쿠버네티스 서비스도 사용해보았기 때문에, 아래의 일 정도는 혼자 수행할 수 있게 되었다

- 백엔드 어플리케이션 개발 
- CI 환경 구축: 어플리케이션 빌드 및 이미지 생성
- 온프레미스 혹은 클라우드 환경에 쿠버네티스 사용 환경 구축 ✅
- 쿠버네티스 오브젝트 생성을 위한 매니페스트 작성 ✅
- GitOps 방식을 통한 CD 환경 구축 ✅

블로그 시작

구글링을 하다보면 눈에 띄는 블로거들이 있고 나도 그런 분들처럼 멋진 개발자/엔지니어가 되고 싶다는 생각에, 2023년 3월을 시작으로 블로그를 시작했다.

잘한 점이라면 블로그를 시작할 때 평균 한달에 하나라도 포스팅 하자라는 목표를 지켰고, 아쉬운 점이라면 포스팅할 주제들은 정말 많았는데(실무에서의 이슈, 교육, 읽은 책 등) 조금씩 미루다보니 결국 적다만 글들이 많이 쌓여버렸다.

한해동안 경험으로 배운건, 나중에 하자는 보통 안하게 되더라. 생각날 때 그냥 하자.

2024년 목표

이루기 어려운 목표보다 충분히 실천할 수 있는 정도의 목표를 세워보았다.

정기적으로 프로필 정리하기

회고를 작성한 이유와 동일하게, 앞으로 내가 더 잘하기 위해 프로필도 정기적으로 정리해두려고 한다. 당장의 이직이 목적이 아니라, 내가 어떤 길을 걸어왔는지 봐야 앞으로 가야할 길을 올바르게 정할 수 있을 것이라 생각한다.

귀찮고 번거로운 일들을 부채로 쌓다보면 결국 더 큰 이자로 돌아오게 되니까, 이제라도 원금도 조금씩 갚을 때다. 못해도 분기에 한번은 업데이트하자.

쿠버네티스 심화 학습

2024년에는 상용 컨테이너 오케스트레이션 플랫폼(OCP)과 함께 쿠버네티스를 통해 서비스를 운영할 계획이라고 한다. 단순히 쿠버네티스를 사용하는 정도를 넘어 air gap 환경에서 쿠버네티스 사용 환경 구축부터 운영 상황에서의 트러블 슈팅까지 큰 이슈 없이 잘 해낼 수 있도록, 쿠버네티스의 심연을 들여다보기 위해 노력할 것이다

추가로 지난 사이버 먼데이에 구매한 CKAD도 취득해야지…

퍼블릭 클라우드 학습

사내의 DR 시스템을 퍼블릭 클라우드를 활용해 구축할 계획이 있기 때문에, CSP가 정해지진 않았지만 널리 사용되는 AWS에 대한 학습을 하려고 한다.

지난 PoC를 통해 경험해본 AWS는 생각보다 유저가 직접 핸들링해야 할 부분이 많았고(구성도도 자동으로 그려주는게 아니었다…), 익숙하다면 키워드만 들어도 이해할 수 있는 서비스들도 익숙하지 않으면 전혀 감도 안오는 것들이 부지기수이기 때문에 MSP든 보안/인프라 부서든 원활히 논의를 할 수 있을 정도의 지식은 갖추고 있어야 할 것 같다.

IaC도 까지 학습할 수 있으면 좋겠지만, 그건 일이 어떻게 진행되는지에 따라 정하면 될 것 같다.

대규모 트래픽 처리를 위한 학습

올해 부서 계획에 kafka를 도입하는 것과 이전에 내가 개발하고 유지보수했던 어플리케이션을 고객사 설치형이 아니라 서비스 형태로 본격적으로 제공할 예정이라 대규모 트래픽 처리에 대한 니즈가 있을 것이라 생각한다.

물론 역할이 변경되면서 개발보단 그 외적인 부분에 대한 업무를 수행하게 되겠지만, 그래도 논의를 하거나 의사결정을 해야하는 상황에서 목소리를 내고 싶기 때문에 이와 관련된 학습을 하려고 한다.

지금 당장 구체적인 계획을 세우진 못했지만, 최소 “가상 면접 사례로 배우는 대규모 시스템 설계 기초 1, 2” 정도는 완독해서 내걸로 만들어야지.

오프라인 커뮤니티 모임 / 행사 참여

레퍼런스는 부족한데 선택권이 여러 개인 상황에서 취사선택을 어떻게 할지에 대한 건 늘 고민이다.

예를 들어 온프레미스 환경에 쿠버네티스을 구축하는 것만 하더라도, 관리형 서비스를 사용할지 직접 구축할지 정해야 한다. 그리고 직접 설치한다면 어떤 OS에(CoreOS, RHEL…) 어떻게 쿠버네티스를 구축할지(k3s, k8s…)에 대한 부분도 정해야 한다.

구현을 하고 이후에 리팩토링을 할 수 있는 어플리케이션과 달리 어플리케이션이 기동되는 환경의 경우, 구축이 되고 서비스가 시작되는 순간 달리는 기차가 되어버리기 때문에 바퀴를 갈아끼는건 생각만 해도 골치가 아프다

그러므로 비슷한 일들을 하시는 분들을 만나서 힌트도 얻고, 최근 동향은 어떻게 되는지도 접해봐야지.

“그냥 그렇구나”라는 마인드셋

어느날 자존감 높은 사람이 절대 하지 않는 한 가지라는 쇼츠를 보게 되었다. 내용은 자존감이 높은 사람은 무슨 일이 있을 때 부정적인 생각 없이 “그냥 그렇구나”라고 하고 끝난다는 것인데, 내가 가져야할 마음가짐이라 생각해 기억해두고 있다.

기존 부서도 없어지고 컴포트존에서 꽤나 멀리 떨어져오면서 조금은 불안하고 걱정이 되기는 하지만, 그것들이 해결해줄 수 있는 것들은 거의 없다.

오히려 걱정과 고민 때문에 스트레스를 받아 루틴이 깨지고 이게 다시 불안으로 이어지는 악순환이 반복될 뿐이다. 고민이 아무런 도움이 안되는 상황에서는 “왜 이렇게 되었을까”보다는 “그냥 그렇구나”라는 마인드셋을 가져야지.

[Spring] 어플리케이션 종료 시 들어온 요청은 처리하고 마치기(graceful shutdown)

시리어스강 — Sun, 5 Nov 2023 20:14:32 +0900

최근에 클라이언트 요청이 처리되는 와중에 어플리케이션이 종료될 경우, 그 요청은 어떻게 되는지에 대한 문의가 와서 겸사겸사 graceful shutdown에 대해서 포스팅을 해보려고 한다.

ㅁㅊㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

0. graceful shutdown이란?

서론에서 graceful shutdown이라는 표현을 했는데, 이에 대해서 간략히 설명하자면 다음과 같다.

graceful shutdown이란 질서정연한 방식으로 어플리케이션을 종료하는 절차를 뜻한다.
다시 말해 어플리케이션이 완전히 종료되기 전에 진행 중인 모든 작업을 완료하고, 리소스는 적절하게 해제하고, 데이터 무결성이 유지되도록 필요한 조치를 취하는 행위를 뜻한다.

즉, “클라이언트의 요청을 처리하는 와중에 어플리케이션을 종료시켰을 때 요청을 잘 처리하고 종료하는가?”를 다른 말로 표현하자면 “어플리케이션이 graceful shutdown을 지원하는가?”가 되는 것이다.

1. graceful shutdown 활성화

Spring Boot 2.3부터 graceful shutdown을 지원하고, 이를 활성화하기 위해서는 아래에 해당하는 프로퍼티를 설정한다.

참고로 해당 프로퍼티를 설정하지 않을 경우 기본 값으로 immediate가 세팅되는데, 이는 요청 여부와 상관 없이 서버를 즉시 종료한다는 뜻이다.

server:
  shutdown: graceful

2. 샘플 프로젝트 준비

요청에 대한 처리 시간을 조정하며 테스트를 진행할 예정이기 때문에 Controller와 graceful shutdown와 관련된 프로퍼티를 위해 application.yml 파일을 추가하였다.

Controller

Controller는 아래와 같이 작성했는데, graceful shutdown이 잘 되는지 확인하기 위해 요청을 처리하는데 드는 시간을 일부러 늘렸다.

@Slf4j
@RestController
public class SampleController {
    @GetMapping("/foo")
    public String foo() throws InterruptedException {
        log.info("get request");
        bar();

        return "success";
    }

    private void bar() throws InterruptedException {
        Thread.sleep(60000);
        log.info("end bar method");
    }
}

3. graceful shutdown 활성화 전

graceful shutdown을 활성화 하기 전에 테스트를 수행한 결과는 다음과 같다.

정상 테스트

요청 처리에 드는 시간을 10초로 변경하여 테스트를 수행했고 어플리케이션 프로세스를 죽이지 않았으므로, 요청을 보내고 10초 뒤에 응답을 받았다는걸 알 수 있다.

요청 처리 중 process kill

요청을 처리하는 와중에 프로세스를 죽였을 경우, 응답을 받기 전에 어플리케이션이 종료되어버린다. bar 메소드와 관련된 로그도 남지 않았다.

4. graceful shutdown 활성화 후

정상 테스트

프로세스를 죽이지 않을 경우에는 graceful shutdown을 활성화하기 전과 동일하게 요청/응답이 잘 이뤄짐을 알 수 있다.

요청 처리 중 process kill

요청을 보낸 뒤에 프로세스를 죽일 경우, graceful shutdown이 시작되었다는 로그와 함께 요청이 정상처리 되고 graceful shutdown이 완료되었다는 로그를 남긴다.

graceful shutdown 중 요청

graceful shutdown이 되고 있을 때 요청이 들어오면 어떻게 될까? 정답은 서버에서 요청을 받아주지 않는다.

5. shutdown timeout

timeout

graceful shutdown을 활성화했다고 요청을 처리하기 위해 무한히 기다리는 것은 아니다.

아래의 예시는 요청을 처리하는데 60초의 시간이 들 경우에 graceful shutdown이 어떻게 되는지를 살펴본 결과인데, 하나 이상의 요청이 남아있는 와중에 graceful shutdown이 중단되었다는 로그와 함께 프로세스가 종료되고 정상적으로 응답이 나가지 않았다는 걸 알 수 있다.

timeout 시간 조정

graceful shutdown에 대한 타임아웃은 아래의 프로퍼티로 조절할 수 있는데 기본값은 30초이다.

즉 해당 프로퍼티를 따로 설정하지 않았을 때, 요청이 들어오고 30초 내에 처리가 되지 않을 경우 제대로 요청이 처리가 되지 않은채로 프로세스가 종료된다. → 바로 위의 에러 로그를 보면 타임아웃에 대한 로그도 볼 수 있다

spring:
  lifecycle:
    timeout-per-shutdown-phase: 2m

타임아웃 시간을 2분으로 늘릴 경우, 요청이 정상적으로 처리되는 것을 확인할 수 있다.

물론 클라이언트 요청이 없을 경우, 요청에 대한 대기 시간은 제외하고 어플리케이션이 종료 처리된다.

참고) 프로세스 종료 방식

프로세스를 종료하는 방식에는 여러가지가 있는데, graceful shutdown과 관련된 내용만 간단히 정리하자면 다음과 같다.

SIGKILL(kill -9)

SIGKILL은 프로세스를 즉시 종료시킨다. 그래서 graceful shutdown이 동작하지 않는다.

SIGTERM(kill -15)

SIGKILL과 달리 SIGTERM은 graceful하게 프로세스를 죽이는 방법이다. graceful shutdown이 동작하게 하려면 SIGTERM 방식으로 프로세스를 죽여야 한다. 위의 예시에서는 모두 SIGTERM으로 프로세스를 종료했다.

샘플 코드

graceful-shutdown

참고 ‍♂️

[Spring] 어플리케이션을 종료할 때 특정 작업 수행하기(feat. ApplicationListener)

시리어스강 — Sun, 5 Nov 2023 00:19:21 +0900

최근에 사용자가 로그만 보고 어플리케이션이 언제 종료되었는지 알고 싶다는 요구사항이 있었다.

이처럼 어플리케이션이 시작할 때, 종료될 때, 실패했을 때 등과 같이 어떤 이벤트가 있을 때, 특정 작업을 수행하게 하는건 언제든지 필요할 수 있으므로, 이번 기회를 통해 종료 상황에 특정 작업을 수행하는 샘플 코드를 작성해보려고 한다.

요구사항에 필요한 존재다

1. 샘플 프로젝트 준비

어떤 이벤트가 발생했을 때 특정 작업을 수행하기 위해 ApplicationListener 인터페이스를 사용할 예정이고, 샘플 코드에서는 ShutdownEventListener가 구현체가 될 예정이다. 그리고 어플리케이션을 기동하고 바로 종료되지 않도록 spring-boot-starter-web을 의존성으로 추가했다.

아래에 링크로 달아둔 샘플 코드를 보면 알 수 있겠지만, 크게 복잡할 것 없는 내용이다.

2. 리스너 추가 전

리스너(ShutdownEventListener)가 없는 상황에서 어플리케이션을 종료하면 몇 가지 로그가 남긴하지만, 유저 친화적인 메세지는 남지 않는다.

3. 리스너 추가 후

요구사항대로 유저가 직관적으로 어플리케이션이 종료되었음을 알 수 있도록 리스너를 생성하여 로그 메세지를 출력한다. 단, 어플리케이션이 종료되는 시점에 메세지를 출력해야 하므로 어플리케이션 이벤트는 ContextClosedEvent로 설정한다.

ShutdownEventListener

@Slf4j
@Component
public class ShutdownEventListener implements ApplicationListener<ContextClosedEvent> {
    @Override
    public void onApplicationEvent(ContextClosedEvent event) {
        log.info("application shutdown!");
    }
}

결과

리스너를 추가하여 어플리케이션이 종료되는 시점에 별도의 로그 메세지를 남길 수 있게 되었다.

요구사항은 단순히 로깅을 남기는 것에 그쳤지만, 리스너 메소드에 다른 로직을 넣어서 처리하거나 대상 이벤트 자체를 변경한다면 다양한 상황에 맞춰 특정 작업을 수행할 수 있을 것이다.

샘플 코드

context-closed-event

참고 자료 ‍♂️

spring docs: ContextClosedEvent

[Spring] @SpringBootApplication가 없는 상황에서 @SpringBootTest 수행하기

시리어스강 — Sat, 5 Aug 2023 17:38:45 +0900

회사 동료 분이 스프링 테스트를 하며 오류가 난다고 도움을 요청하셨는데, 살펴보니 크게 두 가지 이슈가 있었고 주요 문제는 @SpringBootApplication 클래스를 포함하지 않는 프로젝트라 @SpringBootTest가 수행이 되지 상황이었다.

이와 관련해서 자료를 찾다보니 마음에 드는 답변은 스프링 테스트 전반에 걸친 내용을 작성한 글 중 일부로 있었고, 간단한 해결 방법들은 지금과 같은 상황에서 좋은 해결책은 아니었다.

그래서 샘플 코드와 함께 내 나름대로의 해결 방식을 정리를 해두려고 한다.

올해 처음으로 회사에서 테스트 코드로 고민하는 분을 봐 반가웠다

1. 프로젝트 준비

에러 재현을 위해 구성한 프로젝트는 다음과 같다. 특이 사항이라면, 어플리케이션을 기동하기 위한 엔트리 포인트가 없다는 것이고 다음으로 SampleService가 의존하고 있는 SampleRepository 구현체가 해당 프로젝트에는 없다는 점이다.

어플리케이션 아키텍처는 아래 그림과 같이 DIP를 적용해, 어플리케이션 레이어의 서비스가 레포지토리 빈을(저수준 모듈) 직접 의존하는 것이 아니라 도메인 레이어의 인터페이스를(고수준 모듈) 의존하도록 구성하였다.

2. 테스트 에러 재현

테스트 코드를 아래와 같이 작성했을 때 문제가 되는 부분은 먼저 서비스에서 의존하고 있는 리포지토리 객체가 없다는 점이고, 다음으로는 @SpringBootApplication 어노테이션을 사용하는 클래스가 없으므로 @SpringBootTest가 사용하는 @SpringBootConfiguration을 찾을 수 없다는 점이다.

@SpringBootTest
class BootApplicationTests {
    @Autowired
    SampleService sampleService;

    @Test
    void di_test() {
        assertThat(sampleService.findContentsById(1L))
                .isEqualTo("hello, 1");
    }
}

에러 메세지

Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test
java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test

3. 해결

@SpringBootConfiguration을 찾을 수 없어서 발생하는 문제는 @SpringBootApplication 어노테이션을 사용하는 클래스가 있을 경우 발생하지 않게 할 수 있고, 실제로 몇몇 블로그나 포스팅에서는 @SpringBootApplication을 생성해서 사용하라는 답변도 있었다.

참고: @SpringBootApplication

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration  
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
    ...
}

하지만, 다른 어플리케이션의 의존성으로 사용하기 위해 만든 프로젝트에서 어플리케이션의 엔트리포인트가 되는 어노테이션을 사용할 필요가 없으므로 다른 방식으로 해결하려고 한다.

테스트 코드

에러 메세지에 친절히 나와있는 것처럼 @SpringBootTest 어노테이션 내에 classes 속성을 활용해, @Configuration 클래스를 지정한다. 참고로, classes 속성은 지정한 클래스를 빈으로 생성한다.

@SpringBootTest(classes = SampleRepositoryConfiguration.class)
class BootApplicationTests {
    @Autowired
    SampleService sampleService;

    @Test
    void di_test() {
        assertThat(sampleService.findContentsById(1L))
                .isEqualTo("hello, 1");
    }
}

configuration

@SpringBootTest의 classes 속성으로 지정한 클래스에서는 서비스에서 의존하고 있는 리포지토리의 구현체를 만들고, @ComponentScan 어노테이션을 활용해 테스트에서 필요한 빈들을 생성하도록 한다.

@Configuration
@ComponentScan(basePackages = "com.example")
public class SampleRepositoryConfiguration {
    @Bean
    public SampleRepository sampleRepository() {
        return id -> "hello, " + id;
    }
}

테스트 결과

테스트를 위한 리포지토리 구현체를 만들어 서비스 빈을 정상적으로 생성하여, 테스트가 통과했다는 것을 확인할 수 있다.

샘플 코드

spring-boot-test-without-spring-boot-application