Go, Vantage point

RHEL9 firewalld (firewall-cmd 명령어 정리)

EVEerNew — Mon, 14 Apr 2025 21:31:57 +0900

RHEL에서는 소프트웨어 형식의 Firewall인 Firewall Demon(firewalld)을 제공한다.

firewalld도 iptables처럼 동작하며, firewall-cmd라는 전용 명령어를 제공한다.

iptables disable 명령어

단, 중복되지 않도록 iptables를 아래 순서대로 정지한 후 사용해야 한다.

systemctl stop iptables

systemctl disable iptables -> 부팅 시, 자동 실행 차단

systemctl mask iptables -> 수동 실행까지 차단

firewalld 설치 확인

firewalld는 RHEL 7버전 이상부터는 기본 설치 되어 있다.

rpm –qa | grep firewalld

firewalld 명령어

시작

systemctl start/enable firewalld

상태 확인

systemctl status firewalld

규칙 확인

firewall-cmd --list-all

기본적으로 ssh와 dhcpv6-client 서비스는 허용되어 있다.

연관된 서비스 출력

firewall-cmd --get-services

해당 서비스가 firewalld에 감지되었다는 의미이므로, firewall 명령어로 간단히 활성화시킬 수 있다.

규칙 추가를 위한 재로딩

firewall-cmd --reload

Firewall zone

zone 확인

firewall-cmd --get-zones

회사 내규에 따라 다르게 설정, 일반적으로는 public zone을 사용한다.

기본 이더넷 인터페이스가 public zone에 배치된 것이 확인된다.

특정 zone의 규칙 확인하기

firewall-cmd --zone=public --list-all

다른 서비스를 대상에 추가하기

http 포트를 열어 보기 위해 httpd를 실행시키자.

httpd 동작만으로는 포트가 차단되어 있어, 연결 되지 않는다.

아래 명령어로 http를 서비스에 추가하면, service list에서 확인된다.

firewall-cmd --add-service=http

http 접속도 성공적으로 이루워진다.

삭제

firewall-cmd --remove-service=http

영구 적용

firewall-cmd --reload를 적용하면 http가 service에서 사라진다.

이처럼 reload를 적용하면 영구추가가 되지 않은 서비스는 목록에서 사라진다.

firewall-cmd --add-service=http --permanent

firewall-cmd --remove-service=http --permanent

pre-defined 서비스 이외의 서비스 추가하기

해당 경로로 이동하면 각 서비스들의 방화벽 설정 파일을 확인할 수 있다.

이 목록들이 firewall-cmd --get-services 에서 확인했던 서비스 목록들이다.

이곳에 필요한 서비스의 xml 설정 파일을 만들어 주면 된다.

간단하게 ssh.xml 파일을 복사해서 생성해주자.

cp ssh.xml sap.xml

vi sap.xml

ssh.xml의 내용

예시 파일

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SAP</short>  
  <description>3rd party service~</description>
  <port protocol="tcp" port="32"/>
</service>

tcp 프로토콜과 32번 포트를 허용하는 SAP 서비스를 만들었다.

이후 firewalld를 재시작해준다.

systemctl restart firewalld

이제 sap를 service로 추가시킬 수 있다.

firewall-cmd --add-service=sap

명령어로 적용하기

프로토콜과 포트 직접 설정

firewall-cmd --add-port=3233/tcp
firewall-cmd --remove-port=3233/tcp

특정 IP reject 하기

firewall-cmd --add-rich-rule='rule family="ipv4" source address="<대상 IP>" reject'

이러면 해당 서버에서는 트래픽이 거절된다.

icmp 트래픽 제한

firewall-add --add-icmp-block-inversion

icmp-block-inversion을 통해 모든 icmp 가 차단된다.

외부로의 트래픽 차단

요즘 업무망에서 많이 차단당하는 GPT를 주소를 확인해 보자.

해당 ip로 나가는 패킷을 아래의 명령어로 drop 할 수 있다.

firewall-cmd --direct --add-rule ipv4 filter OUTPUT -d 172.64.155.209 - j DROP

RHEL 디스크 용량 확장하기

EVEerNew — Sun, 13 Apr 2025 21:35:25 +0900

시작 전에 LVM과 디스크를 추가하는 방법부터 확인하고 오자.

https://everenew.tistory.com/497

LVM의 이해와 RHEL9에서 디스크 추가하기

LVM(Logical Volume Manager)LVM은 물리 스토리지를 가상화하여 여러 개의 물리 디스크를 하나의 용량을 가지는 파일 시스템을 구성/관리할 수 있다.LVM을 크게 분류하면 physical Volume, Volume Group, Logical Volum

everenew.tistory.com

fdisk로 확인하면 현재는 물리 디스크(vmware 환경이라 virtaul disk)가 2개 확인된다.

물리 디스크의 이름은 장착 순서대로 sd뒤에 a, b, c, d... 가 붙는다.

현재 두 개의 물리 디스크가 하나의 볼륨 그룹으로 묶여 있기 때문에, /root 20GB와 /swap 4GB를

sda 14GB와 sdb 10GB 나누어 사용하고 있다.

아직 물리 디스크에는 free공간이 존재하고 운영환경에서 공간이 부족해진다면 LVM을 통해 공간을 확장해 줄 수 있다.

지금은 /의 용량이 가득 찼다고 가정해 보고 /의 용량을 20GB에서 확장시켜 보자.

물리 디스크 추가 때처럼 순서대로 진행한다.

1. 물리 디스크 확장

VMware라면 간단하게 설정에서 용량을 변경해 주자.

2. 파티션 생성

pvs로 확인해 보면 rhelbase라는 volume 그룹이 확장하려는 논리 볼륨의 대상이다.

용량이 남아있는 /dev/sdb를 fdisk를 통해 /dev/sdb2를 생성해 주자.

경고에서 알 수 있듯이 사용 중인 파티셔닝 변경은 지양되므로 우리는 파티션을 하나 더 생성해서 VG에 추가해 줄 것이다.

/dev/sdb2를 4G로 생성해 주고 type도 LVM으로 바꿔주자.

3. 물리 볼륨 생성

물리 볼륨을 추가해 주자.

4. 볼륨 그룹 확장

pv를 볼륨그룹에 추가시켜서 볼륨 그룹의 용량을 확장해 주자.

vgextend <대상 볼륨 그룹> <물리 볼륨>

이제 볼륨 그룹이 24G에서 28G로 확장되었다.

5. 논리 볼륨 확장

이제 추가된 만큼 논리 볼륨을 확장해 주자.

lvextend -L+4G /dev/mapper/rhelbase-root

6. 파일 시스템 확장

xfs_growfs /dev/mapper/rhelbase-root

이제 / 의 크기가 20G에서 24G로 확장된 것이 확인된다.

LVM의 이해와 RHEL9에서 디스크 추가하기

EVEerNew — Sun, 13 Apr 2025 20:26:32 +0900

LVM(Logical Volume Manager)

LVM은 물리 스토리지를 가상화하여 여러 개의 물리 디스크를 하나의 용량을 가지는 파일 시스템을 구성/관리할 수 있다.

LVM을 크게 분류하면 physical Volume, Volume Group, Logical Volume이다.

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index#lvm-architecture_overview-of-logical-volume-management

여러 개의 물리 볼륨을 volume group으로 묶고, 파티션 별로 분배할 수 있다.

이런 시스템의 가장 큰 장점은 용량 부족이 발생하더라도 물리 디스크를 추가하여 volume group의 용량을 확장시켜 줄 수 있다는 것이다.

VM 환경이라면 물리적인 작업 없이도 용량 증설이 가능하기 때문에 큰 장점으로 다가온다.

더 자세한 구조를 살펴보자.

모든 물리 디스크는 파티션을 생성한다.

LVM을 사용하기 위해서는 각 파티션에 대한 물리적 볼륨이 생성되어야 한다.

물리 볼륨을 그룹화하여 볼륨 그룹을 생성할 수 있고, 논리 볼륨이 파일 시스템에 마운트 되는 절차이다.

아래의 명령어로 확인해보자.

fdisk -l

현재는 물리 디스크(vmware 환경이라 virtaul disk)가 2개 확인된다.

물리 디스크의 이름은 장착 순서대로 sd뒤에 a, b, c, d... 가 붙는다.

현재 두 개의 물리 디스크가 하나의 볼륨 그룹으로 묶여 있기 때문에, /root 20GB와 /swap 4GB를

sda 14GB와 sdb 10GB 나누어 사용하고 있다.

이제 해당 구조에서 아래부터 위의 순서대로 용량을 확장해 보자.

1. 물리 디스크 추가

Vmware에서 해당 VM에 3번째 물리 디스크를 만들어서 추가해 보자.

이러면 fdisk 출력 하단에 추가적으로 sdc 물리디스크가 확인된다.

하지만 /dev/sdc1 과 같은 파티션은 확인되지 않는다.

2. 파티션 생성

fdisk /dev/sdc

n (new)

p (primary)

생성된 결과를 보면 파티션의 타입이 Linux이다.

t 커맨드로 파티션의 타입을 LVM으로 바꿔주자.

(자세한 커맨드 정보는 아래와 같다.)

LVM의 헥사코드는 8e이다.

w로 저장해 주자.

물리 디스크에 파티션이 생성된 모습

3. 물리 볼륨 생성

pvcreate /dev/sdc1

pvdisplay로 확인

아직 볼륨 그룹에 할당되지 않아 Allocatable에 no로 확인된다.

vgcreate <생성할 볼륨 그룹 이름> <할당할 물리 볼륨>

4. 논리 볼륨 생성

lvcreate -n <논리 볼륨 이름> --size <사이즈> <볼륨 그룹 이름>

하지만 4GB를 꽉 채워서 할당하면 오류가 발생한다.

볼륨 그룹의 Free Size를 확인해 보면 PE라는 것이 확인되는데, LVM에서 할당할 수 있는 가장 작은 공간 단위를 의미한다.

PE 크기는 4 MiB로 설정되어 있는데, 1023개의 PE만 사용 가능한 것이 확인된다.

따라서 4,092‬MiB만 사용 가능하다.

5. 파일 시스템 할당

lv path인 /dev/rhel_plus_vg/rhel_plus_lv 대상으로 xfs 파일 시스템을 할당해주자.

mkfs.xfs <LV path>

6. 마운트 경로 생성

아직 해당 논리 볼륨은 /dev (장치 디렉토리)에 있다.

이 경로를 폴더를 만들어 마운트 해주자.

mkdir /plus

mount /dev/rhel_plus_vg/rhel_plus_lv /plus

참조

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index#lvm-architecture_overview-of-logical-volume-management

[RHEL9] Lacal & Remote repository 설정하기

EVEerNew — Sat, 5 Apr 2025 22:47:07 +0900

문제 상황

RHEL의 라이선스를 취득하지 않으면 기본 dnf repository를 사용할 수 없으므로 패키지 설치가 불가능하다.

실제 업무에서도 외부 네트워크를 사용할 수 없는 경우가 있으므로 패지기 저장소를 내부에 만들 필요가 있다.

그 두 가지 방법을 알아보자.

1. Local reposiroty

RHEL OS의 ISO 이미지에는 필요한 패키지들이 포함되어 있다.
지금 환경에서 iso이미지는 DVD에 있으므로 /dev/sr0 경로를 마운트 해준다.

# DVD 마운트
mount /dev/sr0 /mnt

repository의 데이터인 AppStream과 BaseOS가 확인된다.

이제 RHEL에서 패키지 저장소 정보를 담는 설정 파일들의 경로인 /etc/yum.repos.d를 확인해 보면 redhat.repo 파일이 확인된다.

라이선스 취득이 없으므로 repository의 데이터가 없다.

local repository를 인식시키기 위해 /etc/yum.repos.d의 하위경로에 아래와 같이 loacl.repo 파일을 생성한다.

[rhel-BaseOS]
name=RHEL_9.5_BaseOS
baseurl=file:///mnt/BaseOS/
gpgcheck=0
Enabled=1

[rhel-AppStream]
name=RHEL_9.5_AppStream
baseurl=file:///mnt/AppStream/
gpgcheck=0
Enabled=1

- gpgcheck는 GPG 서명 검사 여부로, 로컬에서는 0으로 disable

- Enabled를 1로 하여 활성화

이후 메타 데이터 캐시를 재생성해 주면 repo가 인식된다.

sudo dnf clean all
sudo dnf repolist

이후 정상적으로 패키지 설치가 가능해진다.

2. remote repository

모든 서버마다 ISO 이미지를 마운트해서 사용하는 것은 번거로운 작업이 될 수 있다.

따라서 만들어둔 repository를 사설망 내부의 다른 서버들도 사용할 수 있도록 해보자.

# apache 서버를 통해 http로 패키지를 다운로드할 수 있도록 함.

yum install httpd

cd /var/www/html

mkdir repo

#패키지 데이터를 웹 접근이 가능한 경로로 복사해주기.

sudo cp -r /mnt/AppStream /var/www/html/repo/

이제 같은 네트워크의 다른 서버(10.10.20.150)에서 해당 서버의 주소를 repository를 등록해 주자.

vi /etc/yum.repos.d/remote.repo

[remote-repo]
name=RHEL_9.5_remote_repo
baseurl=http://10.10.20.151/repo/AppStream/
gpgcheck=0
Enabled=1

#적용

sudo dnf clean all

이후 아래와 같이 접속 불가 문제가 발생한다면 방화벽으로 인해 해당 포트가 차단되어 있을 수 있다.

sudo systemctl enable --now httpd

sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

위의 커맨드로 방화벽을 해제하면 정상적으로 패키지 설치가 가능해진다.

참조

https://justdaily.tistory.com/4

https://velog.io/@ljk0509/Linux-%EC%82%AC%EC%84%A4-RHEL-Repository-%EB%A7%8C%EB%93%A4%EA%B8%B0

VIP(Virtual IP) 란? (HSRP, Oracle VIP, Load Balancer)

EVEerNew — Wed, 2 Apr 2025 11:32:03 +0900

VIP(Virtual IP)는 가상의 IP로, 여러 자원에 하나의 IP를 할당하는 기술이다.

VIP는 높은 가용성을 보장해야 하는 네트워크 분야에서 이중화를 위해 많이 사용된다.

그 대표적인 예가 Cisco에서 사용되는 HSRP 기술이다.

게이트웨이 다중화 프로토콜 - HSRP(Hot Standby Routing Protocol)

아래의 그림에서 게이트웨이(R1 라우터)가 단 하나만 존재한다면, R1에 장애가 발생했을 때 내부망은 외부망과 통신이 불가능해진다.

게이트웨이를 두 개 (R1과 R2 라우터)를 배치하더라도, 게이트웨이 IP는 하나 밖에 할당할 수 없다.

R1 라우터의 문제가 발생한다면 이를 감지하고, 게이트웨이 IP를 R2 라우터의 IP(이를 Real IP라고 함)로 바꿔주는 수작업이 필요하다.

이를 해결하기 위해 Cisco에서 만든 기술이 HSRP(Hot Standby Routing Protocol)이다.

출처: Cisco Hot Standby Router Protocol (HSRP) Configuration - Study CCNA

HSRP는 두 개의 라우터를 하나의 가상의 IP(VIP)로 묶고, 이 VIP를 호스트의 게이트웨이 주소로 설정해 준다.

이러면 내부 프로토콜에 의해 Active-standby가 결정된다.

이후 active 라우터에 장애가 발생하더라도 standby가 active로 변경되어 트래픽을 전달한다.

특히 클라이언트가 되는 호스트는 게이트웨이 IP의 변경 없이도 정상적으로 네트워크 서비스를 받을 수 있다.

cisco 이외의 장비라면 IETF에서 정의한 게이트웨이 다중화 프로토콜인 VRRP(Virtual Router Redundancy Protocol)를 사용할 수 있다.

RFC 3768 - Virtual Router Redundancy Protocol (VRRP)

RFC 3768: Virtual Router Redundancy Protocol (VRRP)

This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated

datatracker.ietf.org

이처럼 VIP는 여러 개의 자원을 하나의 가상의 IP로 추상화하여 사용할 수 있으므로 이중화 구성에 매우 효과적이다.

따라서 네트워크 장비뿐만 아니라 다양한 장비에서도 활용된다.

Oracle VIP (in RAC)

게이트웨이뿐만 아니라 DB 서버도 가용성을 위해 이중화를 진행한다.

이때의 문제는 위에서와 동일하게 클라이언트가 장애를 감지하고 다른 서버 IP로 변경해야 하는 부분에 있다.

클라이언트 측에서 연결의 timeout이 발생할 때까지 대기 후 다른 서버로 연결을 시도할 수도 있다.

하지만 이는 시간도 오래 걸리고, 정상 서버가 부하로 응답이 느린 상황이라면 이미 생성된 connection process가 또 다른 서버에 띄우는 작업에 의해 부하가 발생한다.

따라서 Oracle에서는 클라이언트와 서버를 VIP로 통신하도록 하고, 해당 서버의 장애를 수초 안에 빠르게 감지하여 다른 서버가 VIP를 가지도록 대처해 주는 기능을 Clusterware에서 제공한다.

단, Oracle RAC는 Active-Standby 형식에서 하나의 VIP가 장애 발생 시 standby 서버로 옮겨지는 failover 방식이 아니다.

Active-Active로 동작하기 때문에 각 서버가 VIP를 가지고, Client들은 해당 VIP 정보들을 가지고 있다.

연결 시, Client는 우선순위에 따라 VIP1에 먼저 접근한다.

이때 서버 A에 문제가 발생 시, VIP1은 빠르게 서버 B로 이동한다.

Client는 VIP1로 서버 B에 접근하지만, 서버B Listener는 VIP2에서의 요청만을 받으므로 VIP1은 바로 거절된다.

클라이언트는 이를 통해 바로 다시 VIP2로 서버B에 연결을 요청할 수 있다.

이 작업을 통해 클라이언트는 장애가 발생했는지 알지 못하고 서비스를 이용할 수 있다.

Load Balancer

클라우드 환경의 Load Balancer들은 VIP의 역할을 수행한다.

클라이언트들은 Load Balancer의 IP를 통해 뒷단에 연결된 서버와 통신을 한다.

뒷단의 서버들에 문제가 발생해도 Load balancer가 정상 서버로 연결을 진행해 주기 때문에 클라이언트들은 내부 서버의 장애를 알 수 없다.

참조

Cisco Hot Standby Router Protocol (HSRP) Configuration - Study CCNA

RAC 환경에서의 vip 역할 : 네이버 블로그

Oracle RAC 개념(Cluster, 구성요소)

Geforce VS Quador (FP64, FP32 ,FP16, BF16)

EVEerNew — Tue, 11 Mar 2025 17:27:02 +0900

NVIDIA의 Geforce와 Quador 계열의 차이를 FP64, FP32 ,FP16, BF16들과 함께 알아보자.

Geforce(지포스)

일반적인 게이머들에게 가장 잘 알려진 개인용 컴퓨터 그래픽 칩셋으로 1999년부터 출시되었다.

Geforce RTX 5090

Quadro(쿼드로)

Geforce와 동일하게 1999년도부터 출시한 전문가의 렌더링 작업용 그래픽 칩셋이다.

그럼에도 불구하고 칩셋은 Geforce와 동일한데, 소프트웨어적인 차이점이 있다.

FP32 vs FP64

두 계열의 차이를 알아보기 전에 FP32와 FP64의 차이를 알아보자.

FP(Floating Point Precision, 부동 소수점 정밀도)는 큰 범위 값을 정의하는 방식이다.

FP16은 반정밀도, FP32는 단정밀도, FP64는 배정밀도로 bit 개수가 더 클수록 더 자세한 소수점을 나타낼 수 있다.

FP32

FP32는 FP16에 비해 정밀도가 우수하고, FP64에 비해서는 크기가 작기 때문에 가장 많이 사용된다.

그만큼 FP64에 비해 정밀도는 떨어지지만 그만큼 메모리 소모가 적어 적절한 trade-off라고 볼 수 있다.

일반적으로 극한의 정밀도가 필요하지 않다면 대부분 사용할 수 있을 만큼 정확하고 빠르다.

따라서 머신러닝, 렌더링(게임)과 시뮬레이션 등에서 사용될 수 있다.

FP64

FP64는 FP32에 비해 구체적인 값을 계산하므로 시간이 오래 걸린다.

대신 그만큼 더 높은 정밀도가 필요한 워크로드에 특화되어 있다.

FP64를 머신러닝에 사용한다면 가중치를 곱하는 행렬곱셈의 크기와 시간이 급등하게 되어, 거의 사용되지 않는다.

FP64는 유체역학과 같은 높은 정밀도가 필요한 과학 계산에 사용된다.

또한 FP64 계산 유닛을 충분히 지원하는 GPU 또한 소수이다.(NVIDIA A100, NVIDIA H100 등)

FP16

FP16은 표현 범위가 적은 만큼 정밀도가 낮다.

대신 가중치 곱이 중요하지 않는 신경망 모델에서는 빠른 속도를 제공할 수 있다.

BF16

BF16는 Google의 AI 연구 그룹인 Google Brain에서 개발한 형식이다.

FP16의 범위 제한은 딥러닝에 적합하지 않으므로 16bit는 크기는 지키고 FP32와 유사한 범위를 가지도록 세팅했다.

FP16에 비해 Exponent bit가 3개 늘리고 Fraction bot를 3개 줄였다.

따라서 FP32와 동일한 Exponent bit를 가지게 되어 비슷한 표현 범위를 가지지만, 정밀도는 더 줄어들게 되었다.

대신 FP32를 BF16으로 쉽게 변환할 수 있어 기존의 FP32를 사용한 모델들도 쉽게 대체할 수 있다.

따라서 대규모 학습 모델에서는 메모리가 적게 사용되는 16bit 표현 형식인 BF16이 사용된다.

단순히 계산하면 32bit로 표현된 값이 16bit로 줄게 되므로 50% 줄일 수 있다.

FP16의 경우 학습보다는 추론 분야에서 많이 사용된다.

결국에는 AI 모델 설계자가 정밀도와 시간 단축 간에 무엇을 선택할지 판단해야 한다.

Geforce VS Quadro

이제 본격적으로 Geforce와 Quadro를 비교해 보자.

기본적으로 동일한 CUDA core 수를 가진다면, Quadro 계열이 2배 이상 더 비싸다.

대신 Quadro 계열은 VRAM이 더 많이 제공된다.

게임

게이밍 성능 FP32 연산이 주를 이룬다. 따라서 동일가격 대비 CUDA core(계산 유닛)가 많은 Geforce 계열이 좋다.

2D 애플리케이션

포토샵과 같은 2D 애플리케이션은 CPU 성능에 의존한다고 한다.

단 블러, 초점 처리와 같은 작업이나 3D 작업에서는 GPU 기능이 사용된다.

이런 작업 또한 대부분 FP32 연산이기 때문에 CUDA core가 많은 Geforce가 유리하다.

3D 애플리케이션

캐드와 같은 3D 애플리케이션도 초정밀도 작업이 아니라면 FP32 연산이다.

따라서 Geforce가 추천된다.

FP64연산

초정밀도가 필요한 작업이라면 FP64 연산이 필요하다.

대부분의 NVIDIA GPU 제품은 FP64 계산을 지원하긴 하지만, FP64 계산에는 GPU가 FP64 연산 유닛이 제공되어야 빠른 계산이 가능하다.

FP64 유닛을 제공하는 대표적인 GPU가 NVIDIA A100, NVIDIA H100, NVIDIA A800, NVIDIA H200이다.

A100의 경우 FP32와 FP64의 비율은 2:1로 알려져 있다.

따라서 Geforce이냐 Quadro 이냐가 중요한 것이 아니라, GPU 제품의 FP64 유닛 수와 비율을 확인하여 결정해야 한다.

딥러닝

딥러닝도 결국 CUDA core 개수가 중요하다.

딥러닝에서는 FP32도 이용되지만, 대규모 학습이라면 BF16으로 메모리를 절약하여 구현하는 추세이다.

NVIDIA는 4x4 크기의 행렬 연산에 최적화된 Tensor Core를 개발해 RTX 카드에 사용한다.

따라서 딥러닝 또한 제품의 연산 속도를 보고 결정하자.

결론

살펴본 것처럼 컴퓨팅 니즈가 가격대비 CUDA Core의 개수가 중요한 상황이기 때문에,

대부분의 상황에서 Geforce 계열이 우위에 있다.

그러므로 Quadro는 더 많은 VRAM과 멀티 디스플레이 지원 등이 필요한 전문 그래픽 작업에서 이용되는 제품군이다.

GPU 제품 별로 다양한 스펙과 기능을 가지므로 계열 별로 비교하기 보다는 필요한 워크로드와 부합하는 GPU 제품을 선택하는 것이 옳을 것이다.

이미지 출처

FP64, FP32, FP16이란 무엇입니까? 부동 소수점 정의하기 | Exxact 블로그

참조

Quadro vs Geforce (쿼드로와 지포스의 차이) :: Steelblue

FP64, FP32, FP16이란 무엇입니까? 부동 소수점 정의하기 | Exxact 블로그

[ML] bf16, fp16, fp32의 차이점

[NVIDIA] CUDA Cores vs Tensor Cores

cuDNN란? (ROCm, HIP API)

EVEerNew — Mon, 10 Mar 2025 16:28:54 +0900

이전글에서는 CUDA에 대해서 살펴보았다.

cuDNN이 무엇인지 알아보자.

cuDNN(CUDA Deep Neural Network)

cuDNN(CUDA Deep Neural Network)은 CUDA 프레임워크에서 딥러닝 가속화를 위한 라이브러리이다.

딥러닝에 많이 사용되는 Tensorflow, PyTorch, Keras와 같은 프레임워크에 활용되고 있다.

tensorflow의 특정 버전이 cuDNN과 CUDA의 특정 버전과 호환되는 것을 확인할 수 있다.

하지만 tensorflow에서 GPU 활용 코드를 작성할 때는 cuDNN 라이브러리를 직접 호출해서 사용하는 코드는 보이지 않는다.

## GPU의 메모리를 제한하는 tensorflow 코드 예시

gpus = tf.config.list_physical_devices('GPU')
if gpus:
  # 텐서플로가 첫 번째 GPU에 1GB 메모리만 할당하도록 제한
  try:
    tf.config.set_logical_device_configuration(
        gpus[0],
        [tf.config.LogicalDeviceConfiguration(memory_limit=1024)])
  except RuntimeError as e:
    # 프로그램 시작시에 가상 장치가 설정되어야만 합니다
    print(e)

즉 tensorflow의 내부 코드상에서 호출하는 것으로 구현되어 있으므로 모델 개발자는 cuDDN과 CUDA에 신경 쓸 필요 없이, tensorflow 코드 자체만 신경 쓰면 된다.

반대로 tensorflow 내부에서 호출하는 것이므로, 변경은 불가능하고 tensorflow와 cuDNN, CUDA의 버전은 반드시 호환되어야 한다.

이전의 개인 경험으로 개발된 후 몇년이 지난 과거의 tensorflow 모델 활용하려 하려면 CUDA의 7 버전을 사용해야 했다.

그런데 최신 GPU에서 지원하는 CUDA 버전이 해당 7버전 이하를 지원하지 않아, 결국 해당 모델을 사용하지 못하였다.

NVIDIA 이외의 벤더들의 GPU는 딥러닝 프레임워크를 어떻게 사용할까?

tensorflow는 CUDA를 통한 GPU 가속을 지원하고 있다.

그런데 CUDA는 NVIDIA의 GPU가 지원하는 프레임워크이다.

그렇다면 AMD의 GPU는 tensorflow와 같은 프레임워크를 사용할 수 없을까?

AMD GPU에서는 ROCm이라는 CUDA의 대체재를 제공한다.

Tensorflow에서도 ROCm을 지원하지만 오직 특정 버전에서만 지원된다.

아무래도 NVIDIA에 비해 AMD는 후속 주자이기 때문에 많은 코드들이 CUDA로 작성되어 왔다.

따라서 호환성을 제공하기 위해 HIP API도 존재한다.

HIP(Heterogeneous-computing Interface for Portability) API

HIP API는 하나의 소스코드를 이기종 시스템(AMD or NVIDIA GPU)에서 동작 가능하도록 하는 C++ runtime API 그리고 kernel language이다.

HIP은 C++ 언어를 통해 AMD의 ROCm back-end와 NVIDIA의 CUDA back-end 응용 커널을 한 번에 빌드 및 실행할 수 있다.

공식 페이지에서는 HIP API는 AMD의 ROCm와 NVIDIA의 CUDA의 성능차이가 거의 없게 만들어 준다.

또한 각 환경에 맞는 성능 튜닝도 가능한다.

HIP은 HIPify와 HIPCC로 구성된다.

HIPify는 CUDA코드를 C++로 변환하는 역할을 담당하고

HIPCC는 C++ 코드를 AMD의 ROCm나 NVIDIA의 CUDA 환경에서 동작 가능하게 컴파일해 준다.

AMD의 설명만 들어보면 완벽히 대체 가능해 보이지만, 조사를 해보니 ML 시장에서 AMD는 여전히 인기 있진 않다.

아무리 이식가능한 HIP가 있다고 해도 기본적으로 NVidia와 AMD GPU의 설계가 다르고 최적화에 차이점이 있기 때문에,

CUDA의 코드가 완벽한 성능으로 이식되긴 힘들다.

참조

Radeon의 숨겨진 힘, ROCm 으로 깨워보자! > 배틀리뷰 - 하드웨어 배틀(Hardware Battle)

[D] CUDA가 ROCm보다 훨씬 빠른 이유는 무엇입니까? : r/머신러닝

What is HIP? — HIP 6.4.0 Documentation

[DL] CUDA, cuDNN이란? - layered architecture for Deep Learning

CUDA Deep Neural Network (cuDNN) | NVIDIA Developer

AI에 GPU가 필요한 이유와 CUDA에 대해서

EVEerNew — Fri, 7 Mar 2025 16:37:36 +0900

그래픽 및 AI 연산에 왜 GPU(Graphics Processing Unit)가 필요한가?

CPU는 박사한명, GPU는 초등학생 백 명에 비유할 수 있다.

단순한 숫자 덧셈 문제 백개가 있다면 초등학생 백 명이 하나씩 문제를 푸는 것이, 박사 한 명이 백개의 문제를 푸는 것보다 더 빠를 것이다.

A + B = C

C + D = E

E + F = G

....

하지만 위에처럼 다음 연산에 이전 연산의 결과가 필요한 경우, 초등학생 수천 명이 있더라도 계산이 빠른 박사님 한 명을 이길 수는 없을 것이다.

이처럼 CPU는 초고성능의 코어 하나로 순차적인 작업에 강점이 있고

GPU는 저성능이지만 수많은 코어로 이루어져, 병렬 처리에 강점이 있다.

그래픽 처리에는 이전 계산 결과 정보가 필요하지 않고, 현재 폴리곤의 정점과 해당 폴리곤이 화면의 어떤 픽셀에 표현되어야 하는지 등을 행렬 연산을 한다.

https://www.macnica.co.jp/en/business/semiconductor/articles/nvidia/136973/

행렬 연산을 해보았다면 알겠지만, 병렬적인 단순 연산이 주를 이룬다.

따라서 CPU보단 GPU를 통해 그래픽 처리를 구현한다.

결과 연산 방식

AI도 수많은 행렬 연산의 결과가 필요하다.

https://wikidocs.net/150781

인공 신경망은 입력값이 가중치(w)화 편향값(bias, b)을 연산하여 출력층을 만들어 낸다. 이 출력 층이 다시 다음 연산의 입력으로 들어간다.

https://wikidocs.net/150781

입력값(x)과 가중치(w)로 결과(y)를 만들어 내는 과정은 이처럼 행렬로 계산된다.

복잡한 모델일 수록 수많은 층(layer)이 존재하며, 학습 과정은 이런 layer 연산들을 수도 없이 반복하므로 GPU 연산이 필수적이다.

그렇다면 CUDA(Compute Unified Device Architecture)란 무엇인가?

CUDA는 GPU에서 수행하는 (병렬 처리) 알고리즘을 C 프로그래밍 언어를 비롯한 산업 표준 언어를 사용하여 작성할 수 있도록 하는 GPGPU 기술 -위키피디아-

엔비디아가 개발한 기술로 NVIDIA GPU에 적용되고 있다.

정확히는 컴퓨터 커널의 실행을 위해 GPU의 가상 명령 집합과 병렬 연산 요소들을 직접 접근할 수 있는 소프트웨어 계층이다.

CUDA 처리 흐름

이미지 출처: https://ko.wikipedia.org/wiki/CUDA

1. 메인 메모리를 GPU 메모리로 복사
2. CPU가 GPU에 프로세스를 지시함
3. GPU가 각 코어에 병렬 수행
4. GPU 메모리로부터의 결과물을 메인 메모리에 복사

CUDA를 통해 개발자들은 CUDA GPU 안 병렬 계산 요소 고유의 명령어 집합과 메모리에 접근할 수 있다.

최신 엔비디아 GPU는 병렬 다수 코어 구조를 가지고 있고, 각 코어는 수천 스레드를 동시에 실행시킬 수 있다.

CUDA를 사용하면 엔비디아의 CPU를 효과적으로 활용할 수 있다.

CUDA core란?

NVIDA GPU에는 3가지 Core가 존재한다.

1. CUDA core

2. Tensor core

3. Ray-Tracing core

CUDA core는 이러한 CUDA 명령어 세트로 액세스 가능한 NVIDIA의 GPU 코어로, GPU의 작업을 처리하는 하드웨어의 요소이다.

따라서 CUDA core가 많을 수록 더 많은 병렬 처리가 가능하고, A100의 경우 6912개의 CUDA core를 가지고 있다.

참조

https://ko.wikipedia.org/wiki/CUDA

https://www.youtube.com/watch?v=ZdITviTD3VM

https://acecloud.ai/resources/blog/nvidia-cuda-cores-explained/

https://wikidocs.net/150781

https://blog.naver.com/n_cloudplatform/221108089772

https://byounghee.me/2023/04/23/gpu-%ec%9a%a9%ec%96%b4%ec%82%ac%ec%a0%84-part2-cuda-tensor-core/

MIG와 vGPU의 차이 (GPU 가상화)

EVEerNew — Thu, 6 Mar 2025 16:02:48 +0900

몇 년 전 대학교 연구실에서 모델 학습에 일반 컴퓨터 GPU와 A100을 써본 경험이 있다.

모델 학습에 파라미터를 조금씩 바꾸어 수십 번을 테스트해 보곤 했는데, 학교의 GPU 클러스터의 자원이 모자라 실행을 위해 몇 시간씩 대기하기도 했다.

그런데 A100이 성능이 훨씬 좋았지만 결국, 학습에 소요되는 시간은 얼추 비슷했던 것 같다.

일반적인 모델 학습이 성능을 100% 끌어내지 못 한듯 하다. (혹은 아래에서 알아볼 MIG 때문일지도 모른다.)

그렇기에 GPU 성능을 끌어낼 수 있도록 코드적인 수정이 필요하거나, 유휴 GPU 자원을 활용하는 방안이 필요하다.

이를 위해 활용되는 MIG와 vGPU 기술에 대해 알아보자.

MIG(Multi-Instance GPU)

MIG는 GPU를 독립적인 여러 인스턴스로 분할하여 사용하는 가상화 기술이다.

NVIDIA의 A100은 Ampere 아키텍처로 설계되어, MIG 가상화를 지원한다.

MIG로 최대 7배 많은 GPU 인스턴스를 제공하기 때문에 자원 활용률이 중요한 CSP에서 특히 활용하기 좋다.

각 인스턴스는 메모리, 캐시, 컴퓨팅 코어가 하드웨어 수준에서 완전 격리/보호된다.

따라서 각 인스턴스 별로 다른 유형의 워크로드를 수행할 수 있다.

또한 각 인스턴스는 필요에 따라 프로비저닝 까지 가능하다.

예를 들어 NVIDIA A100 40GB는 20GB 메모리의 인스턴스 2개를 생성하거나 10GB인 인스턴스 2개와 5GB 인스턴스 4개를 생성할 수 있다.

특히 동적으로 GPU 리스소스를 전환할 수 있으므로 다양한 수요에 대처할 수 있다.

출처: https://blogs.nvidia.co.kr/blog/multi-instance-gpus/

vGPU(Virtual GPU)

vGPU는 방식은 CPU 가상화와 유사하다.

하이퍼바이저들은 VM 별로 CPU 사용 시간을 나누어 제공하는 time-shared 방식으로 vCPU를 제공한다.

이때 GPU 메모리를 작업 전환마다 다시 적제한다면 오버헤드가 굉장히 많이 발생할 것이다.

따라서 GPU 메모리는 각 vGPU마다 전용 구간을 나누어 가지고, 컴퓨팅 리소스는 time-shared 방식으로 시간을 나누어 실행하게 된다.

vGPU 소프트웨어는 하이퍼바이저와 함께 가상화 계층에 설치되어 vCPU처럼 vGPU를 제공한다.

https://www.nvidia.com/ko-kr/data-center/virtualization/it-management/

MIG는 하이퍼바이저 뿐만 아니라 베어메탈 서버에서도 GPU를 나누어 쓸 수 있다.

그러므로 활용성 자체는 MIG가 좋지만, NVIDIA GPU에서만 지원되므로 의존성이 높다.

참조

https://byounghee.me/2023/04/20/gpu-%EC%9A%A9%EC%96%B4%EC%82%AC%EC%A0%84-part1-vgpu-%EC%99%80-mig/

https://blogs.nvidia.co.kr/blog/multi-instance-gpus/

https://www.nvidia.com/ko-kr/data-center/virtualization/it-management/

RDMA와 InfiniBand(인피니밴드)

EVEerNew — Wed, 5 Mar 2025 14:04:54 +0900

RDMA(Remote Direct Memory Access)

일반적인 NIC에서의 데이터 전송 과정은 다음과 같다.

1. user space의 버퍼에서 kernel space의 소켓 버퍼로 데이터를 복사 후, 헤더 추가

2. kernel space에서 NIC 버퍼로 복사 후, 수신 측으로 전송

3. 수신 측이 패킷을 NIC 버퍼에서 kernel space로 복사

4. 데이터가 kernel space에서 user space로 복사

5. 컨텍스트 스위칭이 일어나 사용자 응용 프로그램 호출

이러한 과정은 CPU의 복사 작업과 커널 level로 인터럽트를 하는 등의 작업이 필요하므로 부하를 늘린다.

https://www.fibermall.com/ko/blog/rdma-key-technology-for-arithmetic-networks.htm?srsltid=AfmBOorHc4tEGANb2tADIa16TUM9ltVra8a6OLA0CTxyEDiRRxoiudsI#DMA_in_the_Traditional_Sense

이러한 불필요한 과정을 제거하는 것이 RDMA이다.

OS 영향 없이, 네트워크를 통해 다른 시스템으로 데이터를 빠르게 이동시킬 수 있다.

이를 통해 메모리의 복사와 텍스트 교환 작업이 제거되어 성능 향상을 노릴 수 있다.

RDMA 작업 과정

애플리케이션으로부터의 RDMA 읽기/쓰기 요청은 커널 메모리로의 복사 없이, user space에서 로컬 NIC 버퍼로 그대로 전송된다. NIC의 버퍼 내용은 네트워크를 통해 수신 측의 NIC로 전송된다.

이때 전송되는 RDMA 정보에는 대상의 가상 주소와 메모리 키, 그리고 읽고 쓸 데이터의 길이(DMA Length)가 포함된다.

RDMA Extended Transport Header 출처: https://cloudswit.ch/blogs/roce-or-infiniband-technical-comparison/

이를 통해 원격 애플리케이션의 메모리에서 데이터를 읽거나 쓸 수 있게 된다.

RDMA에서는 커널을 경유하는 오버헤드를 줄이기 위해 로컬 NIC로 데이터를 직접 전송한다.

이를 Kernel Bypass(커널 우회)라고 한다.

https://www.fibermall.com/ko/blog/rdma-key-technology-for-arithmetic-networks.htm?srsltid=AfmBOorHc4tEGANb2tADIa16TUM9ltVra8a6OLA0CTxyEDiRRxoiudsI#DMA_in_the_Traditional_Sense

인피니 밴드(Infini Band, IB)

RDMA를 구현하는 대표적인 기술이 InfiniBand와 RoCEv2이다.

여기서는 Infini Band에 대해서 알아보자.

Infini Band는 PCI(Peripheral Component Interconnect) bus의 병목 문제를 해결하기 위해 Mellanox에 의해 개발되었다.

PCI 버스는 모든 구성요소의 데이터가 동일 버스를 타면서 병목 현상이 발생한다.

PCI Bus / 출처: https://www.fibermall.com/ko/blog/what-is-the-difference-between-infiniband-and-roce.htm?srsltid=AfmBOooBEpRIuMEUt-0p8ydclx0CtHy3FoM6NIzLtSi1PV_5xiVVOpp1

출처: https://www.fibermall.com/ko/blog/what-is-the-difference-between-infiniband-and-roce.htm?srsltid=AfmBOooBEpRIuMEUt-0p8ydclx0CtHy3FoM6NIzLtSi1PV_5xiVVOpp1

인피니밴드에서는 채널 어댑터(CA, 인피티밴드 카드)인 HCA(Host Channel Adapter)와 TCA(Target Channel Adapter)를 사용한다.

실제로 둘은 같은 어댑터이지만 HCA는 서버와 같은 호스트 시스템에 설치되는 어댑터이다.

호스트 측은 RDMA를 통해 CPU 개입 없이 메모리 간의 데이터 직접 전송을 가능하게 한다.

TCA는 스토리지와 네트워크워크 장비에 설치된 어댑터를 의미하며 주로 수신 측을 의미한다.

기존의 PCI Bus는 하나의 채널에 여러 데이터가 이동하면서 트래픽 간섭이 발생한다.

하지만 InfiniBand에서는 CA(Channel Adapter) 간에 point-point와 양방향 통신이 가능하여 더 높은 속도를 제공할 수 있다.

또한 전용 스위치인 infiniband Switch를 거치면서 2&3 Layer를 축약하는 전용 프로토콜을 쓰기 때문에 더 좋은 성능을 낼 수 있다.

https://cloudswit.ch/blogs/roce-or-infiniband-technical-comparison/

InfiniBand는 AI로 인해 GPU 활용도가 높아지고, NVIDIA가 Infiniband의 개발사인 Mellamox를 인수하면서 GPU 인프라 시장에서 거의 필수 요소로 사용되고 있다.

GPU 클러스터에서 InfiniBand는 고용량의 데이터들을 CPU 경유 없이 다른 GPU들에게 전달하는 핵심 네트워크 기술로 사용된다.

아래처럼 각 GPU마다 메모리가 존재하므로 HCA를 연결하여 GPU끼리 연결 시킬 수 있다.

이미지 출처: https://toss.tech/article/30767

InfiniBand의 단점

이런 다양한 장점에도 불구하고 InfiniBand 스위칭 시스템은 이더넷 스위칭 시스템을 대체할 정도로 대중적이지는 않다.

InfiniBand 스위칭 시스템의 관리적 어려움도 크지만 무엇보다 가격으로 인한 확장 비용이 높다.

GPU 별로 InfiniBand 카드(HCA)를 장착하고 특수 케이블과 하드웨어까지 구매해야 한다.

특히 NVIDIA가 InfiniBand와 호환되는 다양한 기술을 활용하여 제품을 출시하므로 GPU 네트워크 분야에서 사실상 독점적인 위치에 올라가 있다.

경쟁사에서는 더 저렴하게 InfiniBand를 대체할 수 있는 RoCEv2 기술을 개발하였지만, 이미 InfiniBand가 시장의 파이를 먹어둔 만큼 전환은 어려워 보인다.

관련 추천 글

https://toss.tech/article/30767

고성능 GPU 클러스터 도입기 #2: 이주하는 데이터

이번 포스트에서는 토스증권에서 어떻게 고성능 GPU 클러스터를 구축했는지 자세히 공유하겠습니다.

toss.tech

참조

https://www.fibermall.com/ko/blog/rdma-key-technology-for-arithmetic-networks.htm?srsltid=AfmBOorHc4tEGANb2tADIa16TUM9ltVra8a6OLA0CTxyEDiRRxoiudsI#DMA_in_the_Traditional_Sense

https://www.fibermall.com/ko/blog/what-is-the-difference-between-infiniband-and-roce.htm?srsltid=AfmBOooBEpRIuMEUt-0p8ydclx0CtHy3FoM6NIzLtSi1PV_5xiVVOpp1

https://www.fibermall.com/ko/blog/what-is-infiniband-network-and-difference-with-ethernet.htm?srsltid=AfmBOoot3BnCe_7_9XgGhL-q5WmRT5qvr4eES5iUXFVVXNO_W3gLO4jI

https://blog.naver.com/skauter/10169437853

https://ten1010.tistory.com/entry/RAX%EB%A5%BC-%EB%8B%B4%EB%8B%B9%ED%95%98%EB%8A%94-%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EC%86%8C%EA%B0%9C%ED%95%98%EB%8A%94-%EA%B8%B0%EC%88%A0-%EC%9D%B8%ED%94%BC%EB%8B%88%EB%B0%B4%EB%93%9CInfiniband

https://cloudswit.ch/blogs/roce-or-infiniband-technical-comparison/

https://toss.tech/article/30767

SR-IOV vs DPDK (+ OVS, PCI Passthrough)

EVEerNew — Tue, 4 Mar 2025 15:23:53 +0900

DPDK 정리글을 읽고 오면 좋습니다.

DPDK의 원리와 커널 우회(Kernel bypass)

DPDK(Data Plane Development Kit)고속 패킷 처리를 위한 데이터 플레인(data plane) 라이브러리와 네트워크 인터페이스 컨트롤러(NIC) 드라이버의 집합이다.운영체제의 도움을 받지 않고 오버헤드 없이 사

everenew.tistory.com

SR-IOV를 알아보기 전에 OVS에 대해서 알아보자.

OVS(OpenvSwitch)

OVS 하이퍼바이저에서 실행되는 멀티 레이어 가상의 스위치이다.

OVS를 통해 다른 VNF끼리의 전송을 간편하게 만들어 준다.

https://www.cisco.com/c/ko_kr/support/docs/routers/enterprise-nfv-infrastructure-software/221679-understand-nfvis-virtual-networks-ovs.html

단 OVS 구현을 위한 패킷 포워딩 모듈은 커널 영역에 구현된다.

따라서 이전의 DPDK 정리글에서도 확인했듯이, 커널 영역으로의 인터럽트를 발생시켜야 하므로 오버헤드가 발생한다.

이를 개선하기 위해서 OVS를 DPDK와 함께 사용하여, 가상 스위치를 user space에서 실행해 성능을 높인다.

https://www.cisco.com/c/ko_kr/support/docs/routers/enterprise-nfv-infrastructure-software/221679-understand-nfvis-virtual-networks-ovs.html

SR-IOV(Single Root I/O Virtualization)

여기서 확인할 수 있는 문제는 하이퍼 바이저나 커널단을 거치면서 오버헤드가 많이 발생한다는 것이다.

따라서 SR-IOV에서는 하이퍼 바이저나 커널단을 거치지 않고 직접 NIC에 접근한다.

출처: https://telcocloudbridge.com/blog/dpdk-vs-sr-iov-for-nfv-why-a-wrong-decision-can-impact-performance/?fbclid=IwAR22Uiqvyg4Dp3Fxz92FG80L__Iw-2tRVSGRH03-PPFHCoTFHbNovz1rJa0

이를 위해서 사용되는 기술이 PCI Passthrough 기술이다.

PCI Passthrough 기능은 아래처럼 하이퍼바이저의 도움 없이도 VM이 물리 디바이스에 접근할 수 있게 해 준다.

https://www.researchgate.net/figure/Passthrough-within-the-hypervisor_fig2_326504242

단, 이런 경우 VM의 vNIC이 NIC와 1:1로 연결되어야 한다. 따라서 VM만큼 물리 NIC이 필요한 문제가 발생한다.

이 또한 가상화로 해결한다.

https://telcocloudbridge.com/blog/dpdk-vs-sr-iov-for-nfv-why-a-wrong-decision-can-impact-performance/?fbclid=IwAR22Uiqvyg4Dp3Fxz92FG80L__Iw-2tRVSGRH03-PPFHCoTFHbNovz1rJa0

SR-IOV는 물리적 네트워크 인터페이스 카드(pNIC)에서 직접 가상 기능(VF)을 생성하여 가상 머신(VM)에 할당한다.

이를 통해 하드웨어 수준에서 패킷 처리를 수행하므로, 낮은 지연 시간과 높은 처리량을 제공한다.

DPDK vs SR-IOV

DPDK는 east-west 트래픽(동일 하이퍼바이저에서 VM 간 통신)에서는 DPDK의 성능이 더 뛰어나다.

서버 내에서 관리되는 트래픽의 경우 NIC까지 액세스 하지 않기 때문에, SR-IOV가 성능향상을 제공할 수 있는 부분이 없다. 오히려 불필요한 NIC 접근으로 비효율성이 발생할 수도 있다.

https://www.cisco.com/c/ko_kr/support/docs/routers/enterprise-nfv-infrastructure-software/221679-understand-nfvis-virtual-networks-ovs.html

반대로 north-south 트래픽(타 서버 간의 통신)에서는 NIC를 반드시 거쳐야 하므로 SR-IOV가 높은 성능을 발휘할 수 있다.

https://www.cisco.com/c/ko_kr/support/docs/routers/enterprise-nfv-infrastructure-software/221679-understand-nfvis-virtual-networks-ovs.html

참조

https://jaeho.tistory.com/entry/DPDK-vs-SRIOV

https://computing-jhson.tistory.com/92

https://www.cisco.com/c/ko_kr/support/docs/routers/enterprise-nfv-infrastructure-software/221679-understand-nfvis-virtual-networks-ovs.html

DPDK의 원리와 커널 우회(Kernel bypass)

EVEerNew — Tue, 4 Mar 2025 11:19:16 +0900

DPDK(Data Plane Development Kit)

고속 패킷 처리를 위한 데이터 플레인(data plane) 라이브러리와 네트워크 인터페이스 컨트롤러(NIC) 드라이버의 집합이다.

운영체제의 도움을 받지 않고 오버헤드 없이 사용자 애플리케이션이 직접 하드웨어를 독점제어할 수 있는 자체 인터페이스를 제공한다.

이는 User mode에서 Kernel 모드로의 system call을 호출로 발생하는 지연을 제거하여 달성 가능하다.

이를 kernel bypass 기술이라고 한다.

Kernel Bypass (커널 우회)

https://blog.cloudflare.com/kernel-bypass/

Kernel bypass

In two previous posts we've discussed how to receive 1M UDP packets per second and how to reduce the round trip time. We did the experiments on Linux and the performance was very good considering it's a general purpose operating system.

blog.cloudflare.com

위의 글을 정리해 보면서 Kernel bypass에 대해서 알아보자.

Vanilla Linux에서는 약 1M pps를 처리할 수 있지만, 최신 네트워크 카드가 더 높은 처리량을 제공하기 때문에 Linux에 의해 제한이 발생할 수 있다.

더 많은 패킷 처리를 위해서는 Linux의 커널 네트워킹 스택을 우회해야 하며 이를 Kernel Bypass라고 한다.

실제로 리눅스가 얼마나 많은 패킷을 처리할 수 있는지 확인해 보자.

https://blog.cloudflare.com/kernel-bypass/

현재 NIC는 12.2M pps처리가 가능하지만, 모든 패킷을 하나의 코어로 보내면 1.4M pps의 처리가 가능하다.

이때 코어 수를 늘려보면 개선될 것이라 생각할 수 있지만, 4개의 코어로 분산하더라도 각 코어 당 약 470K pps만 처리하게 된다.

https://blog.cloudflare.com/kernel-bypass/

코어를 더 추가하더라도 NIC의 성능까지 끌어내긴 힘들어 보인다.

이를 개선하기 위해서 하드웨어에서 빠르게 패킷을 수신하도록 만들어 주는 특수 API 기술이 등장한다.

그 대표적인 예들이 Packet_mmap, PF_RING, DPDK 등이다.

DPDK의 처리 방식

기존의 커널 네트워크 드라이버는 NIC에서 새로운 패킷을 수신하면 인터럽트를 발생시켜서, CPU가 이를 수신하는 방식으로 처리한다.

따라서 패킷 수신이 많아질수록 인터럽트에 의한 오버헤드가 커진다.

DPDK는 Polling방식을 사용한다.

애플리케이션이 NIC의 패킷 버퍼를 감시하여 새로운 패킷을 바로 처리하도록 설정하므로 인터럽트에 의한 오버헤드가 없이 굉장히 빠르게 패킷 처리가 가능해진다.

이를 구현한 것이 Intel의 DPDK 라이브러리 들이고, 해당 라이브러리를 사용해서 고성능의 패킷처리가 가능해진다.

https://www.accton.com/Technology-Brief/intel-dpdk-performance-on-the-sau5081i-server/

초기에는 Intel 프로세서에 최적화되어 있었지만, 현재는 다양한 CPU 아키텍처(ARM 등)에서도 사용 가능하다.

단, NIC의 패킷 버퍼에 직접 접근하기 때문에 호환성 문제가 발생할 수 있다.

참조

https://justgotothedesk.tistory.com/174

https://ko.wikipedia.org/wiki/DPDK

https://namu.wiki/w/Intel%20DPDK

https://blog.cloudflare.com/kernel-bypass/

Kafka와 ZooKeeper의 관계와 필요성 (분산 시스템 코디네이터)

EVEerNew — Thu, 27 Feb 2025 14:13:10 +0900

윈도우에서 kafka를 실행하려면, ZooKeeper를 먼저 동작해야 한다.

왜 그런 작업이 필요한지 알아보자.

Zookper란?

kafka는 분산 시스템으로 동작하기 때문에 관리를 해줄 코디네이션 서비스가 필요하다.

https://www.xenonstack.com/insights/apache-zookeeper

분산 시스템은 서버 간의 정보 공유, 서버 상태 체크, 데이터 락 등의 기능이 필수적으로 필요하다.

Zookeeper는 분산 코디네이션 서비스로 Kafka와 같은 분산 솔루션에 사용된다.

이전 글을 참조해보면 알 수 있지만, 분산 시스템은 가용성을 챙긴 만큼 단점이 존재한다.

https://everenew.tistory.com/483

(알림 시스템으로 알아보는) 분산 시스템의 trade-off (두 장군 문제)

알림 서비스가 분산 시스템을 사용하는 이유 애플리케이션으로 알림을 보내는 대표적인 서비스는 FCM(andriod)과 ARNs(IOS)이 있다.애플리케이션뿐만 아니라 이메일이나 slack 메시지 등 알림 서비스

everenew.tistory.com

단점은 정확히 한번 메시지 전달을 보장하는 것은 불가능하다는 것이다.

이는 상대 노드가 메시지를 수신한 것조차 확인할 수 있는 방법이 없기 때문에 부분 실패(partial Failure)를 발생시킬 수 있다.

따라서 분산 시스템의 코디네이션이 이를 안전하게 처리하는 기능을 제공해야 한다.

Zookeeper 구조

https://ssup2.github.io/theory_analysis/ZooKeeper/

리더로 선출된 서버의 Request Processor가 다른 Follower 서버들이 받는 Client의 write 요청까지 처리하게 된다.

Zab(Zookeeper Atomic Broadcast)는 Request Processor에서 처리된 작업을 모든 Follower 서버에도 전파한다.

각 클라이언트의 상태 정보들은 Zookeeper의 znode라는 in-memory Key-Value 형태로 저장한다.

클라이언트에는 znode의 변화를 감지하는 watcher를 설정하여 변경 내용을 전달 받을 수 있다.

Kafka와의 동작 원리

Kafka는 크게 3가지 구성요소를 가진다.

Producer: 메시지 생산

Consumer: 메시지 소비

Broker: 메시지 전달 및 저장

https://mapr.com/ebooks/streaming-architecture/chapter-04-apache-kafka-overview.html 출처: https://always-kimkim.tistory.com/entry/kafka101-broker [언제나 김김:티스토리]

각각의 Producer와 Consumer는 카프카 외부에서 동작하는 서비스들이므로,

카프카 Brocker가 카프카 시스템의 핵심이다.

이 브로커가 카프카 클러스에서는 여러 개로 존재한다.

여러 개의 브로커 중 하나가 컨트롤러의 역할을 수행한다.

컨트롤러는 각 브로커에게 담당 파트션을 할당하고 다른 브로커들의 정상 동작을 모니터링 기능을 맡는다.

이때 컨트롤러 브로커가 ZooKeeper의 watch 기능을 통해서 다른 브로커를 모니터링한다.

이외의 브로커들도 watch 기능으로 컨트롤 노드의 변경 사항을 확인 가능하다.

Kafka는 왜 Zookeeper 쓰는가?

이번 주제를 찾아보기 시작한 가장 큰 궁금증은 분산 시스템을 구현해야 하는 Kafka는 왜 직접 코디네이터 시스템을 구현하지 않고 zookeeper에게 의존하는지에 대해서이었다.

위에서 살펴보았듯이 zookeeper는 일종의 카프카의 메타데이터 저장소로서 기능했다.

카프카 브로커들의 주요 정보를 주키퍼에 저장해야 했고 이로 인해 주키퍼 클러스터까지 관리하고 운영해야 한다.

이런 의존성은 결국 복잡성을 늘리기 때문에, Kafka 2.8.0 부터는 직접 카프카 내부에 메타데이터를 저장하는 방식으로 변경되었다.

참조

https://cornswrold.tistory.com/523

https://velog.io/@moon_happy/%EC%A3%BC%ED%82%A4%ED%8D%BC%EB%8A%94-%EB%AD%98%EA%B9%8C

https://always-kimkim.tistory.com/entry/kafka101-broker

https://junuuu.tistory.com/812

빌드 도구 비교 (Maven VS Gradle)

EVEerNew — Mon, 24 Feb 2025 13:40:50 +0900

빌드란?

소스코드를 실행가능한 프로그램 파일로 만드는 과정을 의미한다.

이 과정에서는 소스코드의 컴파일과 실행 관련 파일을 패키징하여 배포 가능한 형태로 만든다.

빌드 도구

빌드 과정을 자동화해주는 소프트웨어로 대표적인 빌드 도구가 Maven과 Gradle이다.

이 도구들은 의존 라이브러리들을 대신 다운로드 해주고 컴파일/테스트/빌드의 과정을 진행해 준다.

Maven과 Gradle을 알아보기 전에 이전에 사용되던 빌드 도구도 같이 알아보자.

Make

UNIX 계절에서 사용되는 원조 빌드 툴이다.

Makefile을 통해 빌드 작업을 통일된 구조로 제공하며 C언어 빌드에는 아직도 활용된다.

ANT

Java의 등장으로 C언어 위주의 빌드 툴인 Make를 대체하기 위해 등장했다.

간단하기 때문에 사용에는 쉽지만, 복잡한 처리를 위해서는 스크립트가 방대해짐.

자바 개발 시에 다양한 라이브러리를 관리해야 하지만, 라이브러리 의존 관계를 관리해주지 않아 어려움이 많음.

Maven

ANT의 문제점을 해결하기 위해 등장.

프로젝트 객체 모델(POM)을 도입하여 스크립트 문제 해결.

POM의 메타데이터를 통해 라이브러리 의존 관계를 자동 관리를 지원.
XML를 사용하기 때문에 POM.xml 파일을 사용해 빌드 설정을 관리.

단, 기능이 많아 규칙이 많고 규칙 이외의 작업은 난이도가 높다.

따라서 주로 간단하거나 명확한 구조 그리고 표준화가 요구되는 프로젝트에 적합하다.

Gradle

Maven과 같은 규칙 기반 빌드 도구이지만 XML이 아닌 스크립트 기반 도구

스크립트 언어로는 groovy를 사용.

groovy는 JVM에서 동작하여 java와 문법도 비슷할 뿐만 아니라, java와 호환되는 스크립트 언어이다.

spring boot를 사용하면 많이 확인할 수 있는 build.gradle이 바로 groovy로 작성되는 파일이다.

따라서 빌드 시에 해당 파일이 있는 폴더에 gradle 명령어를 통해 스크립트를 실행하게 된다.

gradle과 maven 두 툴 모두 다중 모듈 빌드를 병렬로 실행 가능하지만, gradle은 업데이트된 태스크에만 작업을 진행하여 빌드 시간을 단축한다.

https://gradle.org/maven-and-gradle/ gradle 공식 사이트의 비교 영상

https://gradle.org/maven-and-gradle/

특히 동일한 입력의 경우 캐시를 사용해서 굉장히 빠른 것을 확인할 수 있다.

Gradle의 성능 뿐만 아니라 구글이 android의 공식 빌드 도구로 Gradle을 선택하기도 했고, C/C++과 python 등의 언어로 빌드 가능하기 때문에 많이 활용되는 빌드 도구이다.

복잡한 처리가 필요한 프로젝트의 경우 Gradle이 적합하지만 goovy 등의 학습이 필요하여 다소 러닝 커브가 있을 수 있따.

참조

https://gradle.org/maven-and-gradle/

https://starrykss.tistory.com/276

https://galid1.tistory.com/647

https://www.elancer.co.kr/blog/detail/270

Git과 GitLab 그리 Harbor의 이해

EVEerNew — Fri, 21 Feb 2025 17:52:55 +0900

Gitlab을 이해하기 위해서는 비슷해보이는 Github과 도대체 어떻게 다른지가 중요했다.

둘이 비슷한 네이밍을 가지길래 같은 회사의 서비스인 줄 알았지만, 사실 Git라는 분산형 버전 관리 시스템을 제공하는 다른 서비스들이다.

Git이란

분산형 버전 관리 시스템으로, 소스코드 파일들을 복사,백업,저장 등의 기능을 제공하여 많은 프로젝트 인원들이 함께 같은 파일을 작업할 수 있다.

자세한 기능과 원리는 inpa님의 게시글을 참조하자.

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-%EA%B0%9C%EB%85%90-%EC%9B%90%EB%A6%AC-%EC%89%BD%EA%B2%8C%EC%9D%B4%ED%95%B4#git_%EC%9D%B4%EB%9E%80_%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80?

[GIT] ⚡️ git 개념 & 원리 (그림으로 알기쉽게 비유 )

Git 이란 무엇인가? Git이란 분산형 버전 관리 시스템(Version Control System) 의 한 종류이며, 빠른 수행 속도에 중점을 둔다. 우리가 레포트를 제출한다고 가정했을때, 처음에 저장했을때 'report.txt'라

inpa.tistory.com

Git을 제공하는 서비스의 대표가 Github와 Gitlab이다.

Github VS Gitlab

Github는 가장 많이 사용되는 서비스로 온라인 Git 저장소를 무료로 지원하기 때문에 개발자들이라면 Git을 Github로 처음 접해보고 애용했을 것이다.

Gitlab도 동일한 기능을 제공하지만 가장 큰 차이점은 CI/CD 기능에 있다.

Github는 서드파티 도구들을 intergation해서 사용하지만, Gitlab은 해당 기능을 자체 내장하여 사용할 수 있다.

개인적으로 느낀 차이점 한가지는 Gibhub은 주로 온라인 저장소를 그대로 사용한다.

반대로 Gitlab을 사용하는 경우는 주로 온라인 경유 없이 서버에서 직접 Git 저장소를 만들고 접속하는 것으로 생각한다.

Gitlab 사용 법을 검색해보면 docker나 linux의 설치 방법이 눈에 뜨고

이번에 Gitlab을 쓰는 이유도 개인 linux VM 서버에 docker 컨테이너를 CI/CD하기 위함이였다.

실제로 gitlab은 기업의 사설망 서버에 세팅되어 사내의 프라이빗한 Git 원격 저장소를 세팅하는 데 많이 이용된다.

Gitlab을 쓰는데 Harbor는 왜 필요한가?

Gitlab을 컨테이너로 구동시켜 사용하려는데 Harbor는 왜 필요한 것일까?

Harbor는 컨테이너 레지스트리로 Docker hub 처럼 온라인으로 제공되는 저장소가 아니라 서버에 직접 설치하여 사용한다.

그 이유는 위에서 Gitlab의 사용 이유에서 알 수 있듯이 외부에 노출 없이 사설망에서만 컨테이너 이미지를 사용하기 위함이다.

유사한 컨테이너 레지스트리로 Nexus3도 존재한다.

Gitlab Runner는 뭘까?

CI/CD 파이프라인을 구성하다보면, 코드를 build 해야 하는 컴퓨팅 자원이 필요하다.

온라인이나 클라우드 서비스의 CI 서비스는 자동으로 자원을 할당해서 빌드를 해주지만, 사설망에 진행하는 서비스라면 이런 자원까지 등록을 해두어야 한다.

Gitlab에서 이 역할을 하는 것이 바로 Gitlab Runner이다.

runner는 작업이 정의된 .gitlab-ci.yml 파일을 통해 빌드/테스트/배포를 진행한다.

runner는 실시간 작 대한 정보를 gitlab서버로 전송해주기 때문에 파이프라인의 개선이 가능하다.

실패 로그등을 분석하여 성공적인 CI/CD 구성이 가능하다.

쿠버네티스 환경이라면 runner는 pod로 동작할 수 있고, docker 환경이라면 컨테이너로 동작한다.

자동이 환경인 클라우드가 아니므로, runner를 생성하면 CI/CD 작업에 사용할 수 있도록 gitlab의 옵션에서 등록하는 작업이 필요하다.

docker에서 구성한 runner

호스트의 외부에서 minikube 컨테이너 접속하기 (iptables)

EVEerNew — Wed, 19 Feb 2025 15:17:16 +0900

문제 상황

VPN으로 접속한 원격지의 Ubuntu Server에서 minikube를 사용한다.

minikube를 docker 컨테이너로 동작하므로 세팅하였으므로, minikube의 IP는 외부에서 접근할 수 없는 사설 대역대 이다.

minikube에서 nodeport로 웹서비스 파드를 열어 주더라도 minikube는 현재 Ubuntu Server에서만 접근 가능하다.

wordpress는 30511번으로 연결

minikube ip에는 로컬 PC가 접근할 수 없음.

따라서 현재 로컬 PC에서도 접근가능하도록 Host VM인 Ubuntu Server에 포트포워딩을 적용해보자.

iptables를 통한 포트 포워딩

리눅스에서는 iptable을 이용하여 네트워크 필터링 및 주소 변환 등이 가능하다.

80번 포트를 목적지로 하는 패킷이 수신되면, 해당 패킷의 목적지를 모두 30511 포트로 변경한다.

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 30511

-t nat

nat 테이블을 사용하는 규칙

-A PREROUTING

패킷이 라우팅되기 전에 적용.

따라서 패킷이 들어오는 즉시 규칙 적용.

-j REDIRECT

패킷이 규칙과 일치할때 목적치 포트를 로컬 머신은 다른 포트로 리다이렉트

하지만 현재는 로컬 PC가 minikube의 ip로 접근 자체가 불가능한 상황이다.

따다서 ubuntu server ip로 도달하는 요청을 minikube의 ip로 변경하는 IP 변경 작업까지 필요하다.

iptables DNAT(Destination Network Address Translation)

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination <target_ip>:<target_port>

이번에는 -j DNAT 옵션을 통해 목적지를 다른 다른 IP로 변경하는 규칙을 적용한다.

최종 명령어

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.49.2:30511

적용 후 iptables -t nat -L로 적용 된것이 확인 되었다.

따라서 이 ubuntu server의 80 포트로 들어온 트래픽은 minikube 컨테이너인 192.168.49.2의 30511포트로 전달된다.

문제점

단 iptables로 DNAT를 수동으로 세팅한다면, minikube 컨테이너 재기동 시 ip가 바뀔 수 있다.

따라서 변치않는 정보로 세팅하는 방법이 필요하고 해당 방법을 좀더 고민해보자.

참조

https://velog.io/@moorekwon/iptables-%EC%82%AC%EC%9A%A9%ED%95%B4-%ED%8F%AC%ED%8A%B8-%ED%8F%AC%EC%9B%8C%EB%94%A9-UnixLinux

(알림 시스템으로 알아보는) 분산 시스템의 trade-off (두 장군 문제)

EVEerNew — Sun, 8 Dec 2024 10:47:47 +0900

알림 서비스가 분산 시스템을 사용하는 이유

애플리케이션으로 알림을 보내는 대표적인 서비스는 FCM(andriod)과 ARNs(IOS)이 있다.

애플리케이션뿐만 아니라 이메일이나 slack 메시지 등 알림 서비스는 다양한 매체에 적용된다.

이러한 알림 서비스에서는 가장 중요한 것이 알림 데이터 손실을 방지하는 것이다.

만약 단일 시스템을 사용한다면 single point of failure(단일 장애지점)이 되기 때문에 리스크가 크다.

따라서 메시지를 보내는 앞단에 메시지 큐(Apache Kafka, RabbitMQ 등)를 적용하게 된다.

이러한 메시지 큐들도 결국 단일 장애지점을 피하기 위해 분산 시스템이 사용된다.

분산시스템의 Trade-off

그런데 여러 서버를 배치하는 분산 시스템에서는 정확히 한번 메시지 전달을 보장하는 것은 불가능하다.

이로 인해 중복전송을 100% 방지하는 것도 불가능하다.

분산시스템은 단일 시스템에 비해 가용성이 높지만, 결국에 모든 기술은 Trade-off를 가진다.

아래의 Delivery semantics(통신 시스템에서 메시지가 수신자에 전달되는 방식의 보장 방식)의 종류를 확인해 보자.

1. At-most-once (최대 1번 전달)

- 전달이 되지 않을 수 있지만, 전달이 되면 중복은 X.

2. At-least-once (최소 1번 전달)

- 메시지가 최소 한 번은 전달, 중복 가능성 있음.

3. Exactly-once (정확히 한번 전달)

주로 1,2번이 가장 많이 사용되지만 엄밀히 말하면 최소 한번 전달(At-least-once) 조차 불가능할 수 있다.

왜냐하면 네트워크 파티션이 발생할 수 있기 때문이다.

네트워크 파티션(Network Partition)은 분산 시스템에서 네트워크 연결의 일시적인 장애로 인해 시스템의 일부 노드들이 서로 통신할 수 없게 되는 상황을 의미한다. 이 상황에서는 문자 그대로처럼 시스템이 여러 부분으로 나뉘게 된다.

극단적으로 이야기하면 사용자와 서버 간의 연결이 끊기면 아무것도 전달할 수 없다.

따라서 최소 한번 전달은 불가능할 수 있다.

이 대표적인 예가 두 명의 장군 문제와 FLP이다.

이해하기 쉬운 두 장군 문제로 설명해 보자.

두 장군 문제( Two Generals Problem )

두 명의 장군이 서로 다른 위치에서, 동시에 공격해야만 공략 가능한 같은 성을 공격하려 하고 있다.

사자를 통해 메시지를 전달해야 하지만 적군의 의해 메시지가 손상되거나 전달되지 않을 수 있다.

A가 B에게 전달한 메시지가 정상 도착해도 B가 전달을 잘 받았는지 알 수 있는 방법이 없기 때문에 결국 공격을 같이 시작할 수 없다.

이처럼 분산 시스템에서는 메시지 전달의 신뢰성을 믿기 어려울 뿐만 아니라, 특히 신뢰하기 어려운 네트워크 환경이라면 더욱 힘들어진다.

분산 시스템이 이를 해결하는 방식

두 장군 문제와 FLP는 시스템의 복잡성의 문제를 말하는 것이 아니라, 분산 시스템에서는 at least once가 불가능하다는 것을 의미한다.

그래도 당연하게 여러 번 시도하는 방식은 단 한 번의 시도가 전달되기 바라는 것보다는 안정적이다.

그런데 경험을 돌이켜 보아도, 우리가 애플리케이션의 동일한 알람을 여러 번 받는 경우는 드물다.

실제로 많이 사용되는 메시지 큐(RabbitMQ 등)들은 at least once를 보장하는 것은 아니라 그런 척을 하는 것이다.

이때 중요한 것이 멱등성이다.

전달되는 메시지가 멱등적인 경우, 예를 들어 게임의 이벤트 알림이 온다고 했을 때 이 알림을 3번 받는다고 해서 이벤트의 정보는 여전히 동일하게 전달된다.

이런 멱등적인 메시지는 여러 번 전달되더라도 상관없기 때문에 단 한 번의 알림보단 여러 번의 알림을 보내게 된다.

따라서 신뢰성과 정확성이 중요한 시스템들은 1번을 보내는 것 대신 10번을 보내더라도(비용은 10배 발생) 최소 한 번은 전달되길 바라는 것이다.

물론 실제로 여러 번 전달되는 것을 방지하기 위해서, 이벤트 ID를 확인하여 중복된 것은 버리고 알림을 발송하거나 애플리케이션 단에서 중복을 배제하도록 처리할 수 있다.

이처럼 분산 시스템은 강력한 장점을 가지는 만큼 이로 인해 전체적인 시스템의 복잡성을 높인다는 것을 이해하자.

참조

가상 면접 사례로 배우는 대규모 시스템 설계 기초(알렉스 쉬 저)

https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

리눅스 쉘 커스텀 명령어 & 명령어 이름 변경

EVEerNew — Tue, 29 Oct 2024 22:03:11 +0900

커스텀 명령어

리눅스 쉘에 커스텀 명령어를 만들어보자.

리눅스 명령어에는 타입이 존재한다.

위와 같이 type 명령어를 통해서 명령어의 타입을 확인할 수 있다.

cd와 같이 기본적인 셀 자체 내장의 명령어는 shell builtin으로으로 출력되지만

외부 명령어인 mv, cp는 명령어 파일이 저장된 위치가 출력된다.

명령어 파일의 디렉터리

모든 것이 파일인 리눅스에서는 명령어도 결국 파일로 이루어진다.

파일을 실행하기 위해서는 경로와 이름을 사용해서 실행한다.

Ex) ./myfile

하지만 환경 변수인 PATH에 경로 정보를 등록하면 파일을 실행하기 위한 경로를 생략할 수 있다.

따라서 경로 지정이 명령어 실행 시 현재 폴더에 해당 파일이 없다면, PATH에 등록된 정보를 통해 실행 가능한 명령어인지 확인하게 된다.

아래가 환경 변수 PATH로 저장된 경로이다.

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

echo $PATH

해당 폴더에 들어가면 실제로 우리가 사용하는 명령어 파일들이 보인다.

따라서 위 경로에 있는 파일은 경로 정보 없이도 명령어로 실행할 수 있다.

이때 명령어를 등록하기 위한 3가지 방법 존재한다.

1. 실행 파일을 PATH 경로 중 하나의 폴더에 삽입

2. 실행 파일의 폴더를 PATH 환경 변수에 등록

3. 실행 파일의 심볼릭 파일 링크를 1 또는 2번을 사용해 위치시킴.

3번 방식이 PATH 환경 변수가 많아지거나 수정이 거의 없기 때문에 주로 사용된다.

이번에는 확실한 확인을 위해 1번을 통해 확인해 보자.

텍스트를 출력하는 실행파일을 환경 변수 폴더에 직접 만들어 보자.

# its my command을 출력하는 파일을 폴더에 생성.

echo 'echo "its my command"' > /usr/local/bin/mycommand

#실행 권한 부여

chmod +x /usr/local/bin/mycommand

정상적으로 mycommand 명령어 호출을 해보면 세팅한 텍스트가 출력이 된다.

만약 다른 폴더에 유지하고 싶다면 아래와 같이 심볼릭 링크를 생성해서 환경 변수 폴더에 넣어주자.

ln -s ./mycommand /usr/bin/mycommand

이렇게 설정한 커스텀 명령어는 다른 폴더에서도 경로 없이 명령어 실행이 된다.

명령어 이름 바꾸기

명령어가 실행되는 방법을 모두 이해했다면 이름을 바꾸는 법은 매우 간단하다.

바로 PATH 경로에 있는 실제 명령어 파일의 이름을 바꾸어 버리면 된다.

아래처럼 간단히 명령어 이름을 바꿀 수 있다.

mv /usr/local/bin/mycommand /usr/local/bin/myecho

이런 직접적인 방식은 해당 명령어를 이미 사용하던 스크립트 등에 영향이 있을 수 있으므로, alias 명령어를 통해 별칭을 만들어 사용하는 것이 적절할 수 있다.

실제 명령어 파일 확인해 보기

실제로 명령어 파일의 데이터를 까보자.

mv 파일을 까보니 텍스트가 다 깨진다.

이 이유는 해당 파일이 ELF 64-bit LSB pie executable 포맷 바이너리로 이미 컴파일된 파일이기 때문이다.

참조

https://apro-developer.tistory.com/85

[Linux] 17. 리눅스 명령어 만들기 (링크 파일, 환경 변수)

리눅스 명령어 만들기 리눅스 명령어의 구분 • 사용자는 리눅스 셸을 통해 명령어를 내려 리눅스 운영체제의 기능을 수행함. • 리눅스 셸의 명령어는 쉽게 내부 명령어와 외부 명령어로 구분

apro-developer.tistory.com

네이버 클라우드로 웹 서버 띄워보기

EVEerNew — Tue, 1 Oct 2024 23:41:37 +0900

네이버 클라우드는 프리티어로 3개월간 사용가능한 10만 원의 크레딧 제공한다.

이 크레딧을 활용해서 웹서버를 띄워보며 AWS와의 차이점을 확인해 보자.

1. VPC 생성

AWS와 동일하게 VPC부터 생성해주어야 한다.

AWS와 다르게 VPC의 IP 범위를 추천해주지 않는 것이 특이하다.

생성 자체도 생각보다 느려서, 거의 몇 분 정도가 소요된다.

2. Subnet 생성

VPC에서는 subnet 안에 리소스를 배치할 수 있으므로 Subnet을 생성해 주자.

서브넷은 AWS와 동일하게 가용 영역 단위이며, 가용 영역은 한국에도 두 곳 밖에 제공되지 않는다.

IP 주소범위는 192.168.0.0/24로 해주자.

특이한 것은 subnet의 용도를 생성 시에 결정할 수 있다.

우리는 일단 public 하게 웹서버를 열어볼 것이므로 일반을 선택하자.

subnet 생성 자체도 조금 느리다.

3. Web server 생성

이제 서브넷이 준비되었으니 서버를 띄워보자.

Server 타입으로는 1년간 무료 사용이 가능한 Micro(g3)를 선택해 주자

현재 활발히 해외 진출 중이라고 하지만, 아직 한국에서만 제공되는 서버가 많아 보인다.

일단 신규 콘솔 화면으로 생성해 보자.

생성에서 확이할 수 있는 특이한 점은 하이퍼바이저의 종류까지 선택이 가능하다는 것이다.

그리고 지원이 종료되는 Centos 후기작인 Rocky가 이미 준비되어 있다.

여기서는 많이 사용해 본 Ubuntu를 선택해 주자.

서버는 무료로 이용 가능한 Micro를 선택한다.

한국 서비스인 만큼 바로 원화로 가격이 확인가능 한 부분이 눈에 띈다.

공인 IP로 바로 접근해 테스트를 할 것이므로 공인 IP를 할당해 주자.

전체적으로 세팅이 없다면 자동으로 기본 값을 채워주는 AWS보다 세부적인 세팅을 물어보는 것이 많다.

하지만 최신 서비스이기 때문에 전체적으로 깔끔한 스타일이라고 생각한다.

이대로 서버를 생성하면 AWS처럼 pem 키를 생성할 수 있다.

AWS Security Group의 경우는 Access Control Group이 대신하고 있다.

기본 ACG를 선택해 주자.

서버 생성도 AWS에 비해면 상당히 느린데, 이 사이에 ACG를 설정해 주자.

4. ACG 설정

현재 ACG를 확인해 보면 Inbound에 22와 3389만 허용되어 있다.

Outbound도 AWS처럼 전부 허용되고 있다.

웹 서버를 테스트하기 위해서 자신의 IP에서만 HTTP 접근이 가능하도록 Inbound를 설정해 주자.

5. 웹 서버 실행

네이버 클라우드는 서버 접근 시, 관리자 번호를 알아야 한다.

접속 콘솔에 이 정보를 입력하면 연결이 된다.

공인 IP를 가졌으므로, 구글에 ping을 해보면 정상적으로 연결이 확인된다.

이제 아래 명령어로 아파치 웹서버를 설치하자.

sudo apt install apache2

이후 service apache2 status로 동작을 확인할 수 있다.

이제 서버 정보에서 공인 IP를 확인하자.

이 공인 IP를 통해,

http://<public-ip>:80으로 접속하며 정상적으로 웹서버가 확인된다.

AWS에서 하던 것처럼 해보니 어려움 없이 간단히 웹 서버를 띄워 볼 수 있었다.

부분 부분은 다르고 AWS에 비해 서비스를 적지만, 확실히 국산 클라우드도 AWS와 유사하게 디자인된 것 같다.

이제 확인이 끝났으므로 서비스 자원을 확실히 반납해 주자.

[프로그래머스] 퍼즐 게임 챌린지 (PCCP 기출문제 2번) (Python)

EVEerNew — Sat, 21 Sep 2024 23:51:15 +0900

문제

https://school.programmers.co.kr/learn/courses/30/lessons/340212

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

풀이

난이도: Lv.2

일단 정답은 문제들 중 최대 diff(난이도) 만큼의 level(숙련도)의 이하일 것이다.

level 최대 diff보다 높아도 이미 모든 문제를 한 번의 시도로 풀 수 있기 때문에 의미가 없다.

따라서 1 ~ max_diff 사이에 정답이 있다.

가장 간단히는 max_diff부터 순서대로 숙련도를 1씩 줄이면서 시간 안에 문제를 풀어보는 브루트 포스 방법을 생각할 수 있다.

하지만 diff는 최대 100,000이고 퍼즐이 최대 300,000 개이므로,

최악의 경우 대략 30,000,000,000 (300억)번의 연산이 발생하므로 시간 초과가 발생한다.

(Python보다 빠른 C++이라도 10억번 이상의 연산은 시간 초과 발생.)

이처럼 시간 복잡도가 극단적인 경우 다른 방법을 생각해야 한다.

특정 구간(여기서는 1~ max_diff)에서 정답을 맞추는 경우는 업다운 게임처럼 가운데 숫자를 확인해서 구간을 반씩 좁혀나가는 이진 탐색이 효과적이다.

이진 탐색은 O(nlogn)의 시간복잡도 이므로 충분히 시간안에 해결가능하다.

왼쪽 끝인 l와 오른 쪽 끝인 r을 설정하고 중간 값으로 시간 안에 풀리는지 확인하도록 구현하자.

코드

HTTP와 Socket의 차이점 (실시간 채팅 서비스로 알아보는)

EVEerNew — Thu, 19 Sep 2024 16:01:03 +0900

실시간 채팅 서비스를 만든다고 가정해 보자.

이런 서비스에서 HTTP를 기반으로 메시지를 주고받는다면 어떻게 될까?

HTTP(7계층)

HTTP의 경우 stateless 서비스이다. (연결성의 보장은 4계층인 TCP의 역할)

따라서 HTTP는 상대의 요청에 의한 Response만 가능하기 때문에 아래와 같이 클라이언트가 주기적으로 서버에 새로운 메시지의 여부를 물어보게 된다.

이러한 과정을 폴링이라고 한다.

이런 과정은 당연히 폴링의 주기에 따라 서버의 부하가 달라진다.

실시간 채팅이라면 연결과 해제가 수도 없이 발생하여 비효율적이다.

이런 문제를 해결하기 위해 롱 폴링 기법 사용된다.

롱 폴링은 연결 후 응답이 오거나 time out까지 연결을 유지할 수 있다.

하지만 채팅이 적다면 time out마다 재연결을 진행해 줘야 하는 비효율성이 존재한다.

또는 재연결시 로드 밸런싱 과정에서 기존 서버와 다른 서버로 접속될 수도 있다.

따라서 실시간 채팅의 경우, 연결이 항시 유지되는 웹소켓이 사용된다.

웹소켓(Web socket, 7계층)

웹소켓도 HTTP처럼 TCP의 소켓을 사용해서 연결하는 7계층 프로토콜이다.

처음에는 HTTP의 핸드셰이크 과정을 동일하게 거쳐 80(or 443) 포트를 사용하고 이후에는 ws(web socket) 프로토콜로 통신한다.

웹소켓은 한쪽에서 중단하지 않는 이상 연결이 유지된다.

더군다나 양방향으로 전달까지 가능하므로 채팅 서비스를 위해서는 안성맞춤이다.

따라서 서버와 클라이언트 간의 실시간 통신이 중요하다면 웹소켓이 사용된다. (실시가 게임에도 사용)

하지만 항상 서버와 연결이 유지되므로 단순히 웹페이지 로드와 API 응답이 필요할 때 사용한다면 비효율적이다.

그러므로 웹 서비스는 기본적으로 HTTP를 사용하게 구현되지만 일부 기능이 web socket으로 서비스되는 것이다.

참조

가상 면접 사례로 배우는 대규모 시스템 설계 기초(알렉스 쉬 저)

URL 링크 단축 사용 이유와 링크 단축기 구현 방식

EVEerNew — Tue, 10 Sep 2024 16:02:43 +0900

URL 링크 단축이란?

아래와 같이 긴 URL은 공유 시, 텍스트 크기가 굉장히 길어지는 단점이 있다.

https://www.google.com/search?q=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&oq=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg90gEINzcxNmowajGoAgCwAgE&sourceid=chrome&ie=UTF-8

링크 단축: Google 검색

www.google.com

이런 URL은 메시지나 SNS 공유를 위해 사용하기에는 불편하고 보기도 좋지 않다.

이를 위해 최근에는 아래와 같이 같은 링크를 단축된 길이의 URL로 변환해서 공유를 하는 경우가 많다.

https://buly.kr/BTO3cyD

링크 단축: Google 검색

www.google.com

이러한 URL 링크 단축은 단축기 서버에서 아래와 같이 응답을 받아 실제 URL로 이동한다.

단축기 서버는 해당 단축 URL과 일치하는 실제 URL을 반환한다.

이때 HPPT 상태코드 301(Permanently Moved)로 반환하면, Location 헤더에 반환된 실제 URL을 캐시한다.

따라서 이후 단축 URL로 접근해도 단축기 서버를 거치지 않고 실제 URL로 바로 접근하게 된다.

그러므로 301의 경우 단축기 서버의 부하를 줄여줄 수 있어 좋다.

반면 302(Found)로 반환하게 되면, 일시적으로만 Location 헤더에 반환된 실제 URL로 이동한다.

따라서 단축 URL로 재접근하면, 다시 단축기 서버로 이동해서 응답을 받아야 한다.

302는 비효율적으로 보이지만 트래픽 분석에는 효과적이다.

홍보 매체에 따라 다른 단축 URL을 사용하면, 어떤 URL로 어떤 사용자가 접근하는지 파악할 수 있기 때문에 마케팅 효과 분석에 사용될 수 있다.

출처: https://vivoldi.com/blog/url-shortener/why-use-long-links-to-be-shortened/

이런 트래픽 분석을 URL 링크 단축 서비스 업체들이 유료로 제공하여 수익을 창출한다.

하지만 단축 URL은 변환될 실제 URL이 감춰지는 장점 때문에, 최근에는 스팸 메시지에 필수로 이용된다...

URL 단축기의 구현

URL 링크 단축이 무엇인지 알았다면, 단축기 서버의 구현 방식을 고려해 보자.

1. 저장소

변환될 실제 URL을 메모리에 테이블 형태로 가지고 있으면 가장 빠르겠지만, URL 단축 서버는 상당한 양의 단축 데이터를 보관해야 하기 때문에 인 메모리 형태로는 힘들다.

따라서 관계형 DB에 PK_id와 함께 실제 URL과 단축 URL이 저장된다.

(ID만 적절히 생성할 수 있다면 NoSQL DB로도 구현이 가능할 거이다.)

2. 단축 변환 방식

긴 문자열 형태와 1:1로 매칭되는 짧은 문자열로 바꾸는 방법에는 해시 함수가 효과적이다.

대표적인 해시함수인 MD5와 SHA-1로 위의 긴 URL을 변환해 보자.

원본 문자열	q=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&oq=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg90gEINzcxNmowajGoAgCwAgE&sourceid=chrome&ie=UTF-8
MD5	c4e6e7d5f20d21a6c28b35f72ae6e6a3
SHA-1	1a5b8f4e54fc0f4e7e7c75052c64d90b8f7d219a

이러한 해시 함수는 역변환을 방지할 수 있지만, 여전히 길이도 길고, 충돌 가능성 또한 가지고 있다.

따라서 URL 단축기 구현에는 base-62 변환이 흔히 사용된다.

62는 [0~9][a~z][A~Z] 숫자와 알파벳 대소문자의 개수인 62개를 사용해, 62진법으로 10진수를 변환하기 때문에 붙여진 이름이다.

원본 문자열	q=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&oq=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg90gEINzcxNmowajGoAgCwAgE&sourceid=chrome&ie=UTF-8
base-62	a7e5KjQIEzy8LpqhIspXozEcXOy2Odjyze5QuBkUOYmp46s0lawi5coaNHSGmKIvU2eZJoLVLJKqRKhYFIXt8J2DaCJSj9JkmnHYhzEtA2q7yZTapG8FocfsNrpFa1LlFKI7tG6FUx17W7VSdGkWhKZfgPGrtWO5OqRHSkf0s7j0lea8vkNXDbzGMKS682E5S3pzWfOWTuTINzXiGdCYnYjF4qLzOEAxSPo

62진수로 변환되고, 역변환도 가능한 만큼 원본 문자열의 길이에 따라 여전히 긴 문자열로 변환된다.

따라서 주로 관계형 DB의 테이블 ID를 base-62 변환하여 단축 URL을 생성하게 된다.

PK_id	단축 URL	실제 URL
10000001	5K1WLnfhB3	https://www.google.com/search?q=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&oq=%EB%A7%81%ED%81%AC+%EB%8B%A8%EC%B6%95&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg90gEINzcxNmowajGoAgCwAgE&sourceid=chrome&ie=UTF-8

이때 단축 서비스가 서버 부하를 고려한 분산 시스템이라면, 테이블 ID 생성이 다른 서버가 생성한 ID와 겹쳐서는 안 된다.

이를 위해 트위터(X)의 스노우 플레이크와 같은 분산 시스템을 위한 ID 생성 기법을 사용할 수 있다.

참조

https://vivoldi.com/blog/url-shortener/why-use-long-links-to-be-shortened/

가상 면접 사례로 배우는 대규모 시스템 설계 기초(알렉스 쉬 저)

Dual stack(IPv4 or IPv6)에서는 어떤 IP가 사용될까?

EVEerNew — Tue, 27 Aug 2024 12:13:02 +0900

저번 게시글에서는 AWS IPv6 전용의 Egress only IGW를 다뤄보았다.

EC2에서는 IPv4와 IPv6가 모두 사용가능한데, 실제 통신에 사용되는 것은 어떤 것일까?

일단 변하지 않는 원리는 하나다.

IPv4 주소는 IPv4로, IPv6 주소는 IPv6로 통신한다.

IPv4와 IPv6는 엄연히 구조가 다른 주소 체계이므로 하나를 안다고 다른 하나를 유추할 수는 없다.

두 가지 주소를 모두 지원한다면 어떤 주소 방식으로 통신할지는 아래의 과정을 따른다.

1. DNS 조회

서버의 IP를 DNS 서버로부터 쿼리한다.

이때 해당 서버가 IPv4 주소만 가진다면 IPv4로, IPv6 주소만 가진다면 IPv6로 통신하게 된다.

(다른 IP 주소를 유추할 수 없으므로 방법이 없다. )

하지만 서버가 IPv4와 IPv6를 모두 지원하는 경우 두 가지 주소를 받아오게 된다.

2. Happy Eyeballs(Fast Fallback) 알고리즘 활용

IPv6가 더 효율적이기 때문에 일반적으로 더 빠른 통신속도를 제공할 수 있다.

하지만 문제는 모든 네트워크 인프라가 아직 IPv6를 제공하지 못한다는 것이다.

만약 경로의 유일한 라우터들이 IPv4만을 제공한다면, IPv6로는 서버에 도달할 수 없다.

따라서 IPv4를 사용해야 하는데, 이때 활용할 수 있는 것이 IETF의 Happy Eyeballs 알고리즘이다.

Happy Eyeballs는 IPv4와 IPv6 연결을 병렬적으로 시도하여, IPv6 연결이 가능하다면 IPv6를 사용한다.

반대로 IPv6 연결이 지연된다면, IPv4 연결로 전환할 수 있다.

물론 Happy Eyeballs가 표준은 아니기 때문에 해당 알고리즘이 구현된 경우에만 사용할 수 있다.

구글 크롬이나 파이어 폭스와 같은 브라우저는 해당 알고리즘을 지원하고 있다.

+ OS의 네트워크 세팅

OS 자체에서도 우선순위를 정할 수 있다.

RedHat 계열에서는 /etc/NetworkManager/NetworkManager.conf 파일에서 아래와 같이 어떤 주소에 우선순위를 높일지 정할 수 있다.

ipv4.dns-priority=200
ipv6.dns-priority=100

반대로 네트워크에 IPv4만을 사용하도록 제한할 수도 있다.

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/setting-a-networkmanager-wide-default-dns-server-priority-value_configuring-the-order-of-dns-servers

22.2. NetworkManager 전체 기본 DNS 서버 우선 순위 값 설정 | Red Hat Product Documentation

페이지 형식 선택 Multi-page Single-page

docs.redhat.com

참조

정보를 찾기 어려워서 GPT 검색 결과를 활용함.

https://en.wikipedia.org/wiki/Happy_Eyeballs

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/using-networkmanager-to-disable-ipv6-for-a-specific-connection_configuring-and-managing-networking#disabling-ipv6-on-a-connection-using-nmcli_using-networkmanager-to-disable-ipv6-for-a-specific-connection

Windows에서 Linux 컨테이너는 어떻게 실행될까? (WSL)

EVEerNew — Sun, 25 Aug 2024 13:59:28 +0900

Docker 컨테이너들의 대부분은 리눅스 컨테이너로 만들어졌다.

하지만 AWS의 ECS(Docker engine base) 세팅에서 알 수 있듯이, Windows OS인 EC2 상에서도 리눅스 컨테이너는 동작할 수 있다.

Windows에서는 리눅스 컨테이너가 어떤식으로 동작하는지 알아보자.

WSL(Windows Subsystem for Linux)

Windows OS를 사용한다면, 리눅스 환경을 위해 타입 1 혹은 2의 하이퍼바이저를 통해 리눅스 가상머신을 실행해야 한다.

하지만 WSL을 사용하면, 별도의 가상머신 없이도 Windows OS에서도 리눅스 환경을 제공받아 리눅스 명령어를 실행할 수 있게 된다.

WSL 1과 2는 구조적 차이가 존재한다.

WSL 1

1버전에서는 Linux 커널 요청인 System call을 translation layer가 Windows NT 커널과 호환되는 호출로 변환해 준다.

변환 과정은 당연하게 오버헤드가 발생하고, Windows NT 커널이 제공할 수 없는 기능(linux 커널에 종속적인 기능)에 대해서는 명령을 변환할 수 없다. 이는 Type2 하이퍼바이저에서 발생하는 문제점과 유사하다.

따라서 WSL2에서는 구조적인 변화가 이루어졌다.

WSL2

문제를 해결하기 위해서 WSL2는 Hyper-V를 통해 리눅스 커널을 가상화한다.

https://www.tenforums.com/virtualization/119469-hypervisor-type-1-type-2-a.html

Hyper-V는 하드웨어 위에 Host OS 없이 하이퍼바이저가 설치되는 Type 1이므로, 변환 과정의 오버헤드가 없이 system call을 제공할 수 있고 리눅스 System call의 모든 호환성을 가진다.

Docker Desktop의 세팅

이처럼 window에서도 Hyper-V를 통해 리눅스 커널 기능을 제공할 수 있으므로 리눅스 컨테이너를 실행할 수 있다.

실제로 windows에 Docker Desktop을 설치하면, WSL2를 사용하도록 세팅할 수 있다.

https://learn.microsoft.com/ko-kr/windows/wsl/tutorials/wsl-containers

Docker Desktop은 레거시로 제공되는 Hyper-V와 새로운 WSL2 중에 어떤 것을 격리 기술로 사용할지 선택할 수 있다.

참조

https://learn.microsoft.com/ko-kr/windows/wsl/tutorials/wsl-containers

https://www.tenforums.com/virtualization/119469-hypervisor-type-1-type-2-a.html

https://dev.to/akionsight/the-underlying-architecture-of-wsl-and-why-is-wsl-2-better-ba0

https://docs.docker.com/desktop/wsl/

https://learn.microsoft.com/ko-kr/windows/wsl/about

https://learn.microsoft.com/ko-kr/windows/wsl/compare-versions

https://mulmandu17.tistory.com/53

[AWS] 왜 IPv6에서는 Egress Only IGW를 사용할까? (Dual Stack)

EVEerNew — Fri, 23 Aug 2024 13:34:21 +0900

IPv6는 NAT GW가 아니라 Egress Only Internet Gateway 서비스로 트래픽을 외부로 보내는 걸까?

이 이유를 IPv4와 IPv6의 특징을 통해 알아보자.

IPv4의 NAT(Network address translation)

한국은 인구 대비 많은 IPv4를 부여받았고, AWS가 많은 공인 IPv4를 사들여서 AWS에서는 공인 IPv4를 쉽게 이용할 수 있다. (국내 IP의 50% 가까이 점유했다는 말이 있다;;)

하지만 IPv4는 이미 전 세계적으로 고갈되고 있고, AWS에서도 이제 EIP와 같은 공인 IPv4 사용에 대한 유료화 정책을 추진하고 있다.

이미 고갈된 상태의 IPv4 체계가 아직까지 잘 사용되는 이유는 NAT의 역할이 크다.

VPC에서를 예를 들면, ALB의 공인 IP 하나만 존재해도 외부에서 접근할 수 있다.

ALB는 대상 자원의 private IPv4로 목적지 IP를 변환하여, private 자원에도 접근을 제공해 준다.

반대로 나갈 때는 NAT GW의 IP 하나만 있다면, private 자원의 IPv4가 NAT GW의 공인 IPv4로 변환되어 외부 인터넷에 접근할 수 있다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/basics.html

따라서 NAT를 통해 공인 IP 몇 개만으로도 수천 개의 private IPv4로 변환할 수 있고, 내부 자원의 IP 노출을 막아 보안적으로도 우수하기 때문에 아직까지 잘 사용되고 있다.

물론 IP 변환 과정에서의 오버헤드는 분명 발생하며, 변환 과정에서 End-to-End 연결이 차단된다.

IPv6는 NAT GW가 필요할까?

IPv6는 128 bit를 사용하여 거의 무제한에 가까운 주소를 제공할 수 있다.

(IPv4 주소공간의 2^96배이다...)

따라서 NAT 없이도 모든 자원에 공인 IPv6를 할당하여 End-to-End 연결을 달성할 수 있다.

하지만 NAT를 사용하지 않는다면, 모든 자원의 주소가 그대로 노출되는 보안 문제가 발생한다.

이러한 이유로 AWS는 Egress Only Internet Gateway를 사용한다.

일반적인 Internet Gateway IPv6와 IPv4모두 사용 가능하지만, Egress Only IGW는 IPv6에서만 사용한다.

Egress Only IGW를 사용하기 위해 라우팅 테이블에서 로컬을 제외한 IPv6의 모든 대상(::/0)을 Egress Only IGW로 보내면된다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/egress-only-internet-gateway-basics.html

Egress Only IGW는 상태 저장방식이기 때문에 내부에서 전달한 트래픽은 다시 들어올 수 있다.

하지만 외부에서 IPv6 주소로 자원에 직접 접근하면 차단된다.

따라서 IPv6 체계를 사용한다면 Egress Only IGW를 NAT GW 대용으로 사용할 수 있다.

반대로 외부에서 서비스에 접근하는 경우는 결국에 진입점이 필요하기 때문에 일반 Internet Gateway를 통해 접근할 수 있는 IPv6 주소를 제공하면 된다.

외부에서 서비스 자원으로 들어오는 정상적인 접근의 경우에는 ALB와 같이 노출된 IPv6에 Internet Gateway를 통해 접근하고, ALB가 내부 자원들에게 트래픽을 전달하는 방식으로 진행된다.

이 과정에서는 부하 분산을 위해 어쩔 수 없이 ALB에서 서비스 자원으로의 주소 변환 과정이 발생한다.

따라서 Egress Only IGW는 NAT GW처럼, 내부에서 외부로 나가는 IPv6 트래픽에만 사용할 수 있다.

듀얼 스택 구조

IPv4의 연결은 IPv4로, IPv6의 연결은 IPv6로 통신이 되기 때문에, VPC에 인터넷 연결이 필요하다면 아래처럼 NAT GW(IPv4만 지원)와 EIGW(IPv6만 지원)가 모두 필요하다.

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/dual-stack-ipv6-architectures-for-aws-and-hybrid-networks/

외부로 나가는 것 뿐만아니라 내부로 들어오는 경우, ELB에도 Dual stack 세팅이 필요하다.

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/dual-stack-ipv6-architectures-for-aws-and-hybrid-networks/

참조

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/dual-stack-ipv6-architectures-for-aws-and-hybrid-networks/

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/egress-only-internet-gateway-basics.html

https://ko.wikipedia.org/wiki/IPv6

http://weekly.tta.or.kr/weekly/files/20093928033914_admin.pdf

[AWS] ECS의 네트워크 모드 (awsvpc, host, bridge)

EVEerNew — Thu, 22 Aug 2024 13:38:04 +0900

ECS의 태스크를 정의할 때 네트워크 모드를 선택하게 된다.

AWS에서는 특별한 이유가 없다면 awsvpc를 권장하는데, 네트워크 모드마다 어떤 식으로 차이점이 있는지 살펴보자.

1. awsvpc 모드

awsvpc는 EC2와 동일한 네트워크 속성을 사용한다. 각 태스크에 ENI를 통해 private IPv4 주소가 부여되기 때문에, EC2에서 사용하던 방식대로 ECS의 각 태스크를 사용할 수 있게 된다.

단, 태스크의 ENI는 조작할 수 없고 태스크 중지 시 자동으로 분리/삭제된다.

이때 ECS 컨테이너 에이전트가 각 태스크에 대한 pause 컨테이너를 생성하기 때문에, 같은 태스크의 컨테이너들은 pasuse 컨테이너를 통해 네트워크 네임스페이스를 공유한다.

따라서 같은 태스크 내의 컨테이너는 동일한 ENI의 IP를 사용할 수 있다.

pasue 컨테이너에 대해서의 아래의 게시글을 참조하자.

https://everenew.tistory.com/382

Kubernetes Namespaces VS Linux Namespaces (Pause 컨테이너)

쿠버네티스 네임스페이스 네임스페이스는 쿠버네티스에서 용도에 따라서 리소스를 논리적으로 구분하기 위해 사용하는 오브젝트이다. 리눅스의 네임스페이스와 같은 이름이기 때문에 동일한

everenew.tistory.com

결과적으로 각 태스크별 ENI가 할당되므로 보안그룹을 통한 네트워크 제한이 편리하다.

또한 아래의 모드 설명을 보면 알 수 있겠지만, Host EC2의 접근이 없도록 Fargate에서는 awsvpc만을 사용할 수 있다.

단, EC2의 유형별로 연결 가능한 ENI 개수에 한계가 있다.

이를 고려하기 싫다면 Fargate를 사용할 수 있지만, 비용 자체는 EC2를 호스트로 ECS를 제공하는 것보다는 비싸다.

2. host 모드

host 모드는 호스트인 EC2 인스턴스와 컨테이너가 연결되어 사용하는 네트워크 모드이다.

host모드를 사용하면 아래의 그림처럼, EC2의 ENI의 IP로 컨테이너가 트래픽을 수신할 수 있다.

아래의 그림에서는 3000번 포트로의 수신된 EC2 트래픽은 포트 바인딩을 통해 해당 컨테이너에게 전달된다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-host.html

단, host 모드를 사용하면 같은 Instance의 컨테이너 간에는 포트 바인딩이 달라야만 한다.

또한 포트 충돌을 관리해주지 않기 때문에 수동으로 관리해야 한다.

컨테이너가 같은 IP를 가지기 때문에 127.0.0.1과 같은 로컬 호스트로 통신할 수 있기 때문에, 네트워크 격리가 이루어지지 않아 보안적으로도 문제가 있다고 한다.

이처럼 호스트 EC2 인스턴스에 대한 접근이 진행되므로 Fargate에서는 사용할 수 없다.

3. bridge 모드

bridge 모드에서는 가상 네트워크 브리지를 통해 중간 계층을 만들어, host 모드에서 발생하는 포트 충돌 문제를 해결할 수 있다.

bridge 모드에서 정적으로 포트를 매핑하면, 이제는 3000번 포트로 수신하는 컨테이너에게 80번 포트에서 listening 하여 트래픽을 전달할 수 있다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-bridge.html

동적 포트 매핑을 사용하면, 임의로 할당된 호스트의 포트를 사용해 컨테이너에게 전달할 수 있다.

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-bridge.html

이를 통해 host 모드에서 발생하는 포트 충돌 문제를 해결할 수 있다.

포트가 임의로 정해지는 경우, ELB로 트래픽 전달을 일일이 세팅하기 힘들 수 있다.

따라서 ELB의 대상그룹에 자동으로 P 주소 및 포트 목록을 업데이트하도록 서비스를 지원하고 있다.

단, 임의의 포트 범위를 사용하므로 포트를 통한 네트워크 제한이 어렵다.

이런 이유로 NACL도 결국 넓은 포트 범위를 열어줘야 하기 때문에 실무에서도 NACL의 세팅하기 어렵다고 한다.

Birdge도 동일하게 EC2 host까지의 세팅이므로 Fargate에서는 사용할 수 없다.

정리

기본적으로 docker는 bridge모드를 통해 네트워크를 제공하므로, docker를 사용해 보았다면 가장 익숙한 모드이다.

host 모드는 이러한 docker의 기본 가상 네트워크 우회해서 제공된다.

결국에는 awsvpc가 AWS의 네트워크 설계에 따라 보안그룹과 같은 서비스를 제대로 활용할 수 있기 때문에, 관리측면에서는 awsvpc를 권장되는 듯하다.

참조

AWS 공식 문서

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/task-networking-awsvpc.html

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-host.html

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/networking-networkmode-bridge.html

스트리밍 서비스는 어떻게 이루어질까? (RTMP, HLS)

EVEerNew — Wed, 21 Aug 2024 14:18:43 +0900

정말 빠르면 1~2초 안에 시청자에게 도달하는 라이브 스트리밍 방송들은 어떻게 이뤄지는 걸까?

이를 네트워크 프로토콜을 중심으로 알아보자.

전체 과정 요약

1. 카메라 데이터의 인코딩

카메라로 촬영한 영상이 해당 플랫폼이 지원하는 코덱으로 변환되어한다.

코덱(codec)은 어떠한 데이터 스트림이나 신호에 대해, 인코딩이나 디코딩, 혹은 둘 다를 할 수 있는 하드웨어나 소프트웨어를 일컫는다. 또, 이를 위한 알고리즘을 가리키는 용어로도 쓰인다.
일반적으로 코덱이라고 하면 영상, 음향 등 미디어 정보를 압축하는 기술을 가리킨다.
- 위키피디아-

코덱을 통해 영상의 데이터 스트림을 디코딩이 가능하게 압축한다.

이때 비손실 코덱의 경우 원본의 정보를 그대로 살려 압축하기 때문에 압축률이 높지 않다.

데이터가 커질수록 네트워크 대역폭 부하와 전송 시간이 길어지기 때문에, 주로 손실 코덱이 사용된다.

애니메이션을 예로 들면, 동일한 배경에서 캐릭터의 표정만 변화하는 경우가 있다.

이럴 경우 모든 프레임을 데이터로 담지 않고, 이전 프레임에서 변화된 내용만을 저장하여 압축률을 최대로 올릴 수 있다.

2. CDN 서버로 전송

스트리밍의 핵심은 낮은 지연시간이다.

따라서 정해진 하나의 메인 서버로 직접 전송하기보다는 지리적으로 가까운 위치에 분산되어 있는 CDN 서버에 전송하게 된다.

시청자 또한 근처의 CDN 서버를 사용해 빠르게 데이터를 다운로드할 수 있다.

이때 사용되는 프로토콜은 일반적으로 인터넷에서 많이 사용되는 HTTP가 아닌 스트리밍 전용 프로토콜을 사용하게 된다.

RTMP(Real-Time Messaging Protocol)

RTMP는 어도비에서 개발한 프로토콜로 일반적으로 서버로 비디오 스트림을 보낼 때 사용된다.

이때 RTMP에서 사용하는 인코딩 방식을 거치기 때문에 RTMP 인코더를 사용해서 인코딩 후 전송하게 된다.

RTMP 인코더라고 다른 코덱을 사용하는 것이 아니라 일반적인 audio(AAC 등)와 video(H.264 등) 코덱을 사용한다.

RTMP는 TCP를 사용하기 때문에 안정적으로 서버와 클라이언트 간의 세션을 유지하면서 데이터 스트림 전송이 가능해진다.

하지만 현재는 브라우저에서 어도비 플레이어가 지원 중단 것에서 알 수 있듯이, 더 이상 시청자에게 까지 전달하는 용도로 RTMP가 사용되지 않는다.

서버에서 시청자에게는 모든 브라우저가 지원하는 HTTP 기반의 스트리밍 프로토콜로 전송하게 된다.

또한 RTMP를 대체할 수 있도록 성능이 개선된 최신 프로토콜인 SRT와 webRTC도 점차 많이 사용되는 추세이다.

3. CDN 서버에서 시청자에게 전송

HLS(HTTP Live Streaming)

HLS는 Apple에서 개발한 HTTP 기반의 스트리밍 프로토콜로, 라이브 콘텐츠를 endpoint 디바이스에서 스트리밍 할 수 있다. HTTP를 사용하는 만큼 다양한 디바이스에서 재생이 가능하며 오픈소스로 제공된다.

CDN 서버에서 각 클라이언트에게 데이터를 전송하기 위해서, 다시 한번 인코딩(H.264 또는 H.265)을 거친다.

이후 각 비디오들을 정해진 초 단위의 세그먼트로 나누고 각 파일의 재생 순서와 정보를 기록한 인덱스 파일을 생성한다.

클라이언트의 디바이스들은 해당 데이터들을 수신하여 순서에 맞게 재생을 하게 된다.

이때 서버는 클라이언트의 네트워크 환경에 따라 적절한 영상 품질을 제공하기 위해 360p, 720p, 1080p 등 다양한 품질로 세그먼트를 준비하여 제공하게 된다.

HLS도 TCP를 사용하기 때문에, 네트워크의 정보를 파악할 수 있고 이에 따라 적응형으로 적절한 품질의 스트리밍을 제공하게 된다.

빠른 전송에는 UDP가 특화되어 있지만, 라이브 스트리밍은 실시간 화상 회의와 다르게 몇 초 정도의 지연은 허용되기 때문에 TCP를 통해 안정적인 연결을 지양하는 것 같다.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

HLS 이외에도 DASH가 HTTP 기반으로 스트림을 제공한다.

HLS는 H.264 또는 H.265 인코딩을 사용해야만 하지만, DASH는 다양한 인코딩 표준을 사용할 수 있다.

특히 Apple의 장치는 HLS만을 허용하기 때문에 DASH가 국제 표준으로 자리 잡고 있다.

참조

https://blog.naver.com/n_cloudplatform/222493527661

[미디어 기술 이해] 6단계로 알아보는 라이브 생방송 송출 원리

최근 ‘라방’ 이라는 단어의 부상과 함께 네이버 쇼핑라이브에서 Live로 쇼핑도 하고, BTS 공연도 생...

blog.naver.com

https://ko.wikipedia.org/wiki/%EC%BD%94%EB%8D%B1

https://growthvalue.tistory.com/178

https://www.cloudflare.com/ko-kr/learning/video/what-is-live-streaming/

https://www.cloudflare.com/ko-kr/learning/video/what-is-http-live-streaming/

https://www.cloudflare.com/ko-kr/learning/video/what-is-mpeg-dash/

https://www.cdnetworks.com/ko/media-delivery-blog/what-is-rtmp-ingest/

리눅스에서의 APT, YUM, DNF의 차이

EVEerNew — Mon, 19 Aug 2024 13:27:49 +0900

리눅스 계열의 OS를 사용하면 apt, yum, dnf와 같은 명령어를 사용해 패키지를 다운로드한다.

이때 각 명령어가 어떻게 다른지 확인해 보자.

리눅스 배포판

일단 리눅스는 각 배포판에 따라서 사용되는 패키지 다운/설치 명령어가 다르다.

대표적으로는 데비안 계열과 레드헷 계열이 있다.

1. 데비안 계열의 경우

데비안 계열의 대표적인 OS가 바로 Ubuntu이다.

Ubuntu에서는 .deb 형식의 컴파일된 바이너리 패키지 포맷을 사용한다.

dpkg

이 .deb 형식의 데비안 패키지 관리 시스템이 dpkg이다.

dpkg는 .deb 패키지의 설치, 삭제, 정보 제공을 위해 사용되는 저레벨 도구이다.

문제는 우리가 사용하는 대부분의 패키지들은 다른 기본 패키지들에게 의존성을 가진다는 것이다.

dpkg로 패키지를 제대로 설치하고 싶다면, 의존성을 가진 패키지들의 .deb을 모두 구해서 우선순위에 따라 순서대로 직접 명령어로 설치를 해주어야 한다.

따라서 고급 도구인 APT가 주로 사용된다.

APT (Advanced Packaging Tool)

APT는 사용해 보면 알겠지만 아래와 같은 단순하 명령어 만으로도, 해당 패키지와 의존성이 있는 모든 .deb 파일을 다운로드하여 순서대로 설치해 준다.

sudo apt-get install <패키지 명>

apt-get을 사용하면, 일단 /etc/apt/sources.list에서 패키지를 가져올 수 있는 위치 정보를 확인한다.

(한국판을 설치하면 kr.archive.ubuntu.com로 설정될 수 있는데, 카카오에서 제공하는 미러서버인 mirror.kakao.com로 바꾸면 더 빠른 속도로 .deb 파일을 다운로드할 수 있다고 한다.)

이후 대상 패키지가 의존성을 가지는 목록을 서버로부터 제공받는다.

아래의 페이지를 확인해 보면 알 수 있듯이, 서버에서 계산을 하는 것이 아니라 패키지 제공자들이 이미 의존성 파일 목록들을 제공하기 때문에 바로 확인이 된다.

https://ubuntu.pkgs.org/20.04/ubuntu-main-amd64/bind9-dnsutils_9.16.1-0ubuntu2_amd64.deb.html

이후 install을 진행하면 해당 .deb 파일들이 자동 다운되면서 설치가 진행된다.

ubnutu를 사용하다 보면 자주 사용되는 apt-get update도 이러한 패키지들과 의존성 목록을 최신 데이터로 유지하기 위해 sources.list를 업데이트하는 명령어이다.

2. 레드햇 계열의 경우

레드햇 계열의 대표적인 OS는 RedHat와 CentOS이다.

레드햇 계열에서는 .rpm 형식의 컴파일된 바이너리 패키지 포맷을 사용한다.

위와 동일하게 rpm이 저수준, yum이 rpm을 활용해 의존성 패키지까지 설치해 주기 때문에 고수준의 패키지 관리 시스템이다.

명령어도 거의 유사하게 사용할 수 있다.

그렇다면 dnf는 무엇일까?

DNF

DNF는 Yum의 낮은 성능, 많은 메모리 사용량, 비효율적인 중복 의존성 해결 메커니즘 등의 문제를 해결하기 위해 개발되었고,Yum과 달리, 외부 라이브러리인 libsolv를 통해 의존성 문제를 처리한다.
- 출처 위키백과-

또한 yum은 python으로 개발되었지만, DNF는 C와 C++로도 작성되었다고 한다.

성능뿐만 아니라 yum에서 발생하는 의존성 문제도 있기 때문에, 이제는 후신인 DNF를 정식으로 사용되는 듯하다.

참조

https://minhan2.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-%ED%8C%A8%ED%82%A4%EC%A7%80-%EB%B9%84%EA%B5%90aptdpkgyumrpm

https://zetawiki.com/wiki//etc/apt/sources.list

https://velog.io/@broccoliindb/apt-get-%EC%99%80-dpkg%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

https://ko.wikipedia.org/wiki/Deb_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D)

https://ko.wikipedia.org/wiki/Dpkg

https://ko.wikipedia.org/wiki/%EC%96%B4%EB%93%9C%EB%B0%B4%EC%8A%A4%ED%8A%B8_%ED%8C%A8%ED%82%A4%EC%A7%95_%ED%88%B4

https://ko.wikipedia.org/wiki/RPM_%ED%8C%A8%ED%82%A4%EC%A7%80_%EB%A7%A4%EB%8B%88%EC%A0%80

https://www.fedoralinux.or.kr/forums/topic/20625

AWS SOA-C02 공부법 및 합격 후기 (SysOps Administrator - Associate)

EVEerNew — Sat, 17 Aug 2024 22:21:14 +0900

취득 목적

AWS SAA 자격증을 취득하고 AWS 프로젝트로 인프라를 설계/구현해 본 것까지는 좋았다.

문제는 구현 후였다.

적절한 모니터링과 문제 상황에 대한 대응이 준비되어 있지 않아서 운영이 되지 않는데, 고가용성과 비용최적화가 무슨 소용일까?

결국 아키텍팅의 기본은 운영에 대한 이해에서 시작한다는 것을 알게 되었다.

하지만 운영을 경험하는 것이 아니라 혼자 공부한다는 것부터가 막막했기 때문에, 운영적인 지식에 도움이 되는 SysOps Administrator 자격증을 준비하게 되었다.

아직 실무 경험이 없기 때문에 Associate로 준비하였고 최종 합격까지 성공해 후기를 남긴다.

공부 방법

자격증 자체만을 목표로 하면 당연히 최신 덤프들을 구해서 외우면 된다.

하지만 개인적인 취득 목적은 운영 지식의 습득이기 때문에 덤프는 어디까지나 외우기보다는 공부용으로만 사용했다.

일단 전반적이 AWS의 이해가 있어야 한다.

SOA를 따려면 적어도 SAA는 취득할 수 있는 기본 지식이 있어야 된다고 생각한다.

본인의 경우 SAA 취득 후, AWS로 인프라를 설계/구현/운영한 경험도 있어서 많이 도움이 됐다.

1. Udemy 강좌 수강

https://www.udemy.com/course/aws-certified-sysops-administrator-associate-korean/

SAA를 취득하기도 했고 이미 대부분의 서비스 알고 있기 때문에, 강의를 듣지는 않고 해당 강좌에서 제공하는 PDF 슬라이드 파일을 통해 공부했다.

덤프를 풀어보면 알겠지만 대부분의 내용이 잘 정리 되어있지만 내용이 많다 보니 당연히 다 외울 수가 없다.

모르는 내용을 위주로

Udemy의 실전 모의고사 기능은 UI 및 환경이 실제 시험과 비슷하기 때문에 해보는 것은 좋지만, 덤프를 풀어보면 알겠지만 실제 시험과는 문제 느낌도 다르고 지엽적이기도 한 것 같다.

Udemy 모의고사는 굳이 신경쓰지 말자.

2. 덤프 풀이

유료 덤프로 다양한 최신 문제를 풀면 가장 좋지만 돈이 없던 관계로 무료 덤프 위주로 공부했다.

여기서 중요한 것이, 덤프를 반복해서 풀면서 외우는 것이 아니라 풀면서 모르는 용어나 서비스가 나오면 정리해 가면서 푼다.

특히 모르는 문제의 정답이 왜 이럴까 고민해보면서, 어떤 상황에서 어떤 솔루션을 제시해야 하는지 정리해 두자.

Sysops는 미묘한 세팅 차이가 다른 솔루션으로 이어지기 때문에 상황마다의 대처를 잘 정리해야 한다.

(예를 들어 특정 오류 메시지가 어떤 의미이고 어떤 세팅을 확인해야 하는지)

무료로 제공되는 덤프는 최신도 아니고 문제양도 많지 않지만, 위의 공부 방식대로 풀었더니 시험 대비와 운영 지식 습득에도 굉장히 도움이 되었다.

아래는 본인이 풀었던 무료 덤프 사이트이다.

각각 200문제 정도는 무료로 제공하기 때문에 시험의 감을 잡고 정리하는데에 굉장히 도움이 된다.

https://www.examtopics.com/exams/amazon/aws-sysops/view/

AWS-SysOps Exam - Free Exam Q&As, Page 1 | ExamTopics

An organization has configured a VPC with an Internet Gateway (IGW). pairs of public and private subnets (each with one subnet per Availability Zone), and an Elastic Load Balancer (ELB) configured to use the public subnets. The application s web tier lever

www.examtopics.com

https://free-braindumps.com/amazon/free-soa-c02-braindumps.html?p=1

Free SOA-C02 Exam braindumps download (SOA-C02 exam dumps Free)

Free SOA-C02 Exam Braindumps Pass your AWS Certified SysOps Administrator - Associate (SOA-C02) exam with these free Actual Questions and Answers Exam Code: SOA-C02 Exam Title: AWS Certified SysOps Administrator - Associate (SOA-C02) Exam Provider: Amazon

free-braindumps.com

(위의 무료 덤프 문제에서도 10문제 정도는 동일한 문제가 나왔던 것 같다.)

3. 실제 예제 문제 풀이

AWS에서 제공하는 실제 예시 문제를 마지막으로 풀어보자.

10문제 밖에 없지만 가장 실제 문제와 비슷하기 때문에 공부가 잘 되었는지 확인하는 용도로 사용하자.

https://d1.awsstatic.com/ko_KR/training-and-certification/docs-sysops-associate/AWS-Certified-SysOps-Administrator-Associate_Sample-Questions.pdf

이 문제들도 제대로 풀기 힘들다면 시험 일정을 미루고 재정비해보자.

원래 Sysops 시험은 실제 AWS console에서 문제 상황을 풀어야 하지만, 현재는 공지 전까지 해당 문제들은 출제되지 않는다. 따라서 정리한 내용을 계속 복습하면서 계속 디테일한 내용까지 파고들면 된다.

시험 응시 및 결과

SAA도 그랬지만 시간이 부족하기보다는 몰라서 못 풀게 된다.

즉, 시간은 넉넉하니 천천히 읽고 답하면 된다.

(본인이 응시할 때는 이상하게 Site-to-Site VPN 관련 문제가 많이 나왔다.)

1000점 중에 720점을 취득하면 되는데, 65 문제에서 중에서 15문제는 새로 만들어져 테스트를 위해서 출제되어서 점수에는 반영되지 않는다. 어려운 문제를 만나도 반영되지 않는 문제일 수 있으므로 맘 편히 보면 된다.

결과적으로는 적당한 점수로 합격했다.

Solution Architecture는 비용 최적화와 같은 솔루션이 중요했다면, Sysops에서 중시하는 것은 자동화와 최소한의 노력으로 효율적인 운영이 가능한 솔류션이다.

운영 지식 습득에는 상당히 도움이 되었지만, 역시 글로 공부하는 것보다는 실제 운영을 하면서 배울 수 있는 다양한 경험과 지식이야 말로 뼈와 살이 되는 것 같다.

[AWS] Gateway LoadBalancer란? (with Network Firewall)

EVEerNew — Thu, 1 Aug 2024 10:40:45 +0900

AWS Network Firewall을 사용하게 되면, VPC 내부에 감시 자원 배치되는 것이 아니라 트래픽을 전송하는 엔드포인트가 배치된다.

이 엔드포인트가 Gateway Load Balancer(GWLB)로 연결된다.

출처: https://aws.amazon.com/ko/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/

따라서 IGW와 연결된 subnet들에는 Endpoint로의 라우팅 경로를 설정해 주게 된다.

이를 통해 IGW의 In/out bound 트래픽은 항상 Gateway Load Balancer로 전송되어 Network Firewall 서비스에서 검사가 수행된다.

이 Gateway Load Balancer란 도대체 뭘까?

Gateway LoadBalancer(GWLB)

출처: https://www.cloudflare.com/ko-kr/learning/ddos/glossary/open-systems-interconnection-model-osi/

Network LoadBalacner는 4 계층인 TCP/UDP까지 검사한다.

따라서 7 계층까지 검사해 처리해야 할 것이 많은 Applcation LoadBalancer에 비해 성능이 우수하다.

반면 Gateway Load balancer는 3 계층인 IP를 검사하기 때문에 오버헤드가 더욱 낮다.

따라서 주로 네트워크 트래픽을 이동시켜, 보안을 위해 검사하는 용도로 많이 사용된다. (Network Firewall처럼)

출처: https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/vpce-gateway-load-balancer.html

이때 기존의 목적지 IP주소가 트래픽 검사를 위한 자원의 주소로 변경하게 되면, 기존의 정보가 손실될 수 있다.

이를 위해 Endpoint에서 캡슐화를 통해 기존의 3 계층 정보를 GWLB의 정보로 감싸서 보존한다.

이후 다시 VPC로 트래픽이 전달되면, 해당 정보를 제거하여 원래 목적지로 정상 전달한다.

AWS의 Network Firewall 뿐만 아니라, 3rd party인 다양한 서비스를 목적지로도 설정할 수 있다.

이처럼 특수한 목적을 위해 사용하는 LB이기 때문에, 다른 ELB들과는 전혀 다른 성격을 가지고 있다.

참조

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/vpce-gateway-load-balancer.html

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/

https://support.bespinglobal.com/ko/support/solutions/articles/73000544791--aws-aws-gateway-load-balancer-gwlb-%EC%9D%98-%EC%9E%91%EB%8F%99-%EB%B0%A9%EC%8B%9D-%EB%B0%8F-%EA%B5%AC%EC%84%B1-%EB%B0%A9%EB%B2%95

AWS의 메타데이터 서버가 링크 로컬 주소를 사용하는 이유 ( 169.254.169.254 주소는?)

EVEerNew — Sat, 27 Jul 2024 19:53:49 +0900

링크 로컬 주소란?

링크 로컬 주소 같은 네트워크와 브로드케스트 도메인에서만 통신이 유효한 네트워크 주소이다.

라우터 외부로 나가면, 더 이상 같은 네트워크가 아니기 때문에 라우터가 패킷을 전송하지 않는다.

외부로는 전달 불가

IPv4에서는 169.254.0.0/16 범위, IPv4에서는 fe80::/10 범위가 링크 로컬 주소로 예약되어 있다.

(IPv4에서 실제로 사용가능한 주소는 169.254.1.0 ~ 169.254.254.255이다.)

이러한 링크 로컬 주소는 일반적으로 DHCP를 통해 주소를 할당받을 수 없을 때 (DHCP 서버가 존재하지 않거나 더 이상 IP 풀이 없을 때), 예약된 링크 로컬의 범위 내에서 랜덤으로 IP를 선택한다.

선택한 IP로 ARP를 날려, 응답이 있다면 다른 IP를 선택하고 응답이 없다면 해당 IP를 사용하게 된다.

AWS 메타데이터 서버

AWS나 GCP와 같은 CSP들은 링크 로컬 주소인 169.254.169.254 주소를 메타데이터의 서버로 사용한다.

처음에는 메타 데이터 서버가 없더라도, 인스턴스(VM)의 시작 시점에서 메타 데이터를 설정해 두면 오프라인에서도 편리하게 메타데이터 사용할 수 있는 것이 아닐까 생각했다.

하지만 인스턴스 내부에 정보가 있다면, 임의로 AWS에서 부여한 값(IAM role이나 EC2 ID)을 바꾼다던지의 보안 문제가 발생할 수 있다고 생각한다. 특히 VM 실행 중에 IAM 프로필을 수정하는 경우 문제가 발생하기 쉽다.

반대로 메타 데이터 서버에서 받아온다면 실행 중과 관계 없이, 서버로부터 현재 값을 확인할 수 있기 때문에 보안적으로도 우수하다.

메타 데이터 서버가 링크 로컬을 사용하는 이유

하지만 메타 데이터 서버 자체의 보안이 허술하다면 모든 중요 데이터가 노출될 수 있다.

따라서 링크 로컬 주소인 169.254.169.254를 사용하여, 해당 네트워크 범위를 벗어난 외부에서는 메타 데이터 서버로 접근할 수 없도록 한다.

(네트워크 관리자가 우회 방법을 마련하지 않는 이상 외부에서의 접근은 애초에 외부의 169.254.169.254로의 경로가 존재할 수 없다.)

외부에서는 접속 불가

메타 데이터 서버로의 경로는 AWS의 백본 네트워크 또는 물리 호스트(GCP는 물리호스트 내에서 응답)로 한정되기 때문에 정보를 빼낼 수 없다. 그렇기에 메타 데이터를 curl 할 때도 특별한 보안을 하지 않고 HTTP로 정보를 얻어오게 된다.

AWS는 공식 정보가 없어서, 정확히 어디서 메타데이터의 응답을 제공하는지는 모르겠다.

(GCP처럼 물리 호스트가 제공하거나 endpoint를 통해 AWS 서버에 접근할 수도 있다.)

추가적으로 현재 AWS는 발전된 보안을 제공하는 IMDSv2를 통해 세션 토큰을 받아, 메타데이터 서버로 접근하도록 권고하고 있다.

참조

https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%B3%E3%82%AF%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9

https://nangman14.tistory.com/49

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

[AWS] VPC의 DNS 서버인 Route 53 Resolver 란?

EVEerNew — Thu, 25 Jul 2024 18:22:28 +0900

Route 53 Resolver를 VPC 내부에서만 사용하는 경우

VPC 내에서는 외부로의 인터넷 접근을 차단해도 VPC의 내부 서비스의 DNS 쿼리 가능하다.

그 이유는 Route 53 Resolver가 VPC 내부에서의 DNS 서비스를 제공하기 때문이다.

Route 53 Resolver는 해당 VPC의 IP 주소에 0.0.0.2를 더한 IP로 정의된다. (VPC + 2라고 표현하는 듯하다.)

10.0.0.0/24라면 10.0.0.2가 해당 VPC의 Route 53 Resolver IP이다.

(이미 예약되어있으므로 다른 자원들 사용할 수 없다.)

IPv6의 경우 fd00:ec2: :253 주소를 사용한다.

VPC의 DNS resolution 기능이 활성화되면, VPC 내부에서 발생하는 DNS 쿼리 요청은 Route 53 Resolver IP를 가진 ENI로 전달된다. 이 Endpoint(일종의 ENI로 유추됨)가 VPC 외부의 AZ에 있는 Route 53 Resolver 서비스와 연결되어 있다.

따라서 Resolver에서쿼리를 진행하여 얻은 DNS 정보를 다시, 동일한 루트를 따라 전달한다.

(아래의 그림에서 빨간 화살표들)

출처: https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/resolver.html

resolver 서비스는 가용성을 위해 아래처럼 AZ에 최소 2개의 Resolver 서버가 동기화를 진행하여 배치되는 것으로 보인다.

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/resolver-availability-scaling.html

Private Hosted Zone은 이러한 VPC 내부에서 쿼리 할 DNS 레코드를 생성해 두는 것이다.

Resolver들은 해당 레코드를 알기 때문에 VPC에서 발생하는 Private 한 DNS 쿼리 요청에 응답할 수 있다.

외부(On-premise 혹은 타 VPC)에서 Route 53 Resolver를 사용하는 경

온프레미스(또는 다른 VPC)와 AWS의 하이브리드 환경에서 온프레미스 자원들이 AWS의 Route53의 Resolver를 사용해야 할 수 있다. (메인 DNS 서비스로 Route53을 사용할 경우)

이런 경우 VPC와 온프레미스 망이 연결되어 있을 것이다.

따라서 특정 subnet에 Route 53 Resolver의 Inbound endpoint를 생성하여 외부 네트워크에서 접글할 수 있도록 만들어 준다.

아래 그림의 빨간 화살표의 a~d 순서로 접근하며, 응답은 역순으로 진행된다.

출처: https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/resolver.html

여기서 VPC + 2인 기존의 Route 53 Resolver Endpoint를 사용할 수는 없을까라는 생각이 들었다.

하지만 기존의 endpoint는 subnet에 속하지 않고 VPC에 배치되어 있다.

따라서 애초에 라우팅 테이블을 수정하여 다른 네트워크로 경로를 만들어 줄 수 없기 때문에, 외부에서는 사용할 수 없다.

그러므로 Inbound endpoint를 추가로 배치하는 방식이 필요하다.

Route 53 Resolver가 외부에서 쿼리를 해와야 하는 경우

반대로 메인 DNS 서비스를 온프레미스나 다른 VPC가 제공할 수 있다.

이런 경우 outbound endpoint가 배치되어, Route 53 Resolver가 외부 DNS resolver에게 쿼리를 할 수 있는 경로를 만들어준다.

아래의 그림처럼 VPC의 EC2에서 시작된 DNS 쿼리가 Route 53 Resolver로 전달된다.

출처: https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/resolver.html

Route 53 Resolver가 모르는 모든 DNS 쿼리를 outbound를 통해 외부에 쿼리 하는 것은 아니고,

Resolver Rule에 설정해 둔 Domain Name에 대해서만 쿼리 하게 된다.

예를 들어 test.mydomain.com에 대한 Resolver Rule이 있을 때,

EC2에서 test.mydomain.com에 대해 쿼리하면, outbound를 통해 외부에 쿼리 하지만

test.example.com에 대해서는 rule에 존재하지 않기 때문에 외부에 쿼리하지 않는다.

(물론 이런 private Domain이 아닌, public Domain은 인터넷을 통해 상위 DNS 서버에는 Route 53 Resolver가 알아서 쿼리해올 것이다.)

참조 및 이미지 출처

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/resolver.html

무엇입니까? Amazon Route 53 Resolver - Amazon Route 53

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/resolver-availability-scaling.html

Route 53 리졸버 가용성 및 규모 조정 - Amazon Route 53

docs.aws.amazon.com

AWS S3의 VPC Gateway endpoint와 interface endpoint의 차이

EVEerNew — Tue, 23 Jul 2024 18:34:51 +0900

VPC Endpoint란?

VPC endpoint는 AWS의 서비스를 public internet을 통하지 않고, AWS 백본 네트워크인 Private Link를 통해 안전하고 빠르게 접근할 수 있는 서비스를 제공한다.

이를 위해서 VPC에는 목표 서비스의 Gateway endpoint 또는 interface endpoint를 배치해야 한다.

S3는 VPC Gateway endpoint를 지원하다가 interface endpoint 서비스가 생기면서 interface endpoint 까지 생성할 수 있게되었다.

일반적으로 DynamoDB와 S3는 Gateway endpoint를 사용하는 것이 권장되는데, 어떤 상황에서 어떤 것이 좋을지 확인하기 위해 두 서비스의 명확한 차이를 알아보자.

Gateway Endpoint

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/gateway-endpoints.html

어디까지나 Gateway이기 때문에 Internet Gateway처럼 서브넷에 배치되지 않고, 서브넷의 라우팅 테이블이 Gateway endpoint를 가리키도록 배치해야 한다. 또한 SG도 별도로 적용할 수 없다.

S3와 DynamoDB만이 해당 서비스를 사용할 수 있다.

AWS는 Longest Prefix Match을 사용하므로, 라우팅 테이블에 0.0.0.0/0으로 Internet Gateway의 경로가 있더라도 Gateway endpoint의 경로가 우선적으로 선택된다. 만약 Gateway endpoint보다 더 정확한 IP 주소의 경로가 있다면 해당 경로가 더 우선시된다.

어디까지나 VPC 내부에서의 접근을 허용하는 용도로 사용된다.

Gateway endpoint의 가장 큰 장점은 배치와 사용 비용이 무료라는 점이다.

Interface Endpoint

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/privatelink-access-aws-services.html

Interface Endpoint는 AWS의 정말 다양한 서비스와의 Private link를 제공한다.

이름에서 알 수 있듯이 ENI가 VPC에 특정 Subnet에 배치되는 형태이다. (ENI에 대한 SG 적용이 필수)

Gateway와 달리 라우팅 테이블 세팅이 별도로 필요하지 않기 때문에, ENI가 배치된 서브넷으로의 접근만 할 수 있으면 된다. 즉 같은 VPC내라면 이용이 가능하다.

이는 AWS의 DNS 서비스 사용하기 때문에 가능한 것이므로, VPC의 DNS resolution 기능이 필수로 켜져있어야 한다.

ENI가 배치되기 때문에 시간당 + 트래픽당 비용이 발생하며, 가용성을 높이기 위해서는 AZ별로 배치해주어야 한다.

이때 명시적인 라우팅 테이블 세팅이 없다면 아래의 그림처럼, 인스턴스들이 라운드 로빈을 통해 Interface Endpoint에 접근한다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/privatelink-access-aws-services.html

이때 타 AZ의 ENI에 접근하면 Cross AZ에 의해 GB당 0.01GB의 비용이 발생한다.

이러한 비용을 감수하더라도 하나의 ENI의 장애 발생을 대비해 트래픽을 제한하지 않을 수 있다.

그렇지 않다면, 같은 AZ의 endpoint를 사용하도록 트래픽을 제한해주어야 한다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/privatelink-access-aws-services.html

이런 경우 가용성은 비교적 떨어질 수 있다.

단, AWS에서의 이중화 배치는 보통 AZ 장애에 대응하기 위함이므로 이러한 세팅이 비용을 절감할 수 있다.

(어차피 AZ-2가 장애가 난다면 AZ-2의 인스턴스들도 다운되므로 AZ-1으로의 접근은 발생하지 않는다.)

이를 위해서 각 AZ에서는 각자의 AZ에 배치된 Subnet만 사용할 수 있도록 라우팅 테이블을 세팅하면 된다.

특히 interface endpoint만 배치하는 subnet을 따로 두어 배치하면, 트래픽 세팅에 편의성을 가져갈 수 있다.

S3를 interface endpoint로 접근하는 경우

여기까지만 보면 관리적으로도 비용적으로도 우수한 Gateway endpoint로 S3를 접근하는 것이 당연히 좋아 보인다.

하지만 S3를 interface endpoint로 접근하는 이유는 따로 있다.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#accessing-s3-interface-endpoints

Onpremiss나 타 cloud와 VPC를 VPN으로 연결하면, Inteface Endpoint를 사용해서 PrivateLink로 S3에 접근할 수 있게 된다.

이때 Inteface Endpoint 자체가 진입점이 되어서, 자신의 private IP로 트래픽을 변경해서 S3로 전달해 줄 수 있다. (일종의 프록시의 역할을 한다.)

반면 Gateway endpoint는 자체에 별도의 라우팅 세팅을 해줄 수 없고, Gateway이기 때문에 타 네트워크의 트래픽을 중계해 줄 수 없다. (프록시를 제공하지 못 한다.)

따라서 하이브리드나 다중 VPC/리전 환경에서는 비용이 발생하더라도 Inteface Endpoint 통해 연결 제한 필요할 수 있다.

참조

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/gateway-endpoints.html

https://docs.aws.amazon.com/ko_kr/vpc/latest/privatelink/privatelink-access-aws-services.html

https://docs.aws.amazon.com/AmazonS3/latest/userguide/privatelink-interface-endpoints.html#accessing-s3-interface-endpoints

https://blog.bespinglobal.com/post/aws-vpc-s3-endpoint-gateway-vs-interface-%EC%B0%A8%EC%9D%B4/

[AWS] 유사 서비스인 SNS와 EventBridge의 핵심 차이

EVEerNew — Tue, 23 Jul 2024 00:18:00 +0900

AWS의 서비스에서 이벤트에 대한 알림을 발송해야 할 때 SNS와 EventBridge를 자주 사용한다.

SNS의 경우(https://docs.aws.amazon.com/ko_kr/sns/latest/dg/welcome.html)

EventBridge의 경우(https://www.megazone.com/techblog_20200309_reducing-custom-code-by-using-advanced-rules-in-amazon-eventbridge/)

두 가지 서비스를 활용하면 이벤트 기반 아키텍처를 설계할 수 있다.

그런데 어떤 상황에서는 EventBridege를 활용해서 알림을 보내기도 하고 SNS로 알림을 보내기도 한다.

이런 상황의 차이는 무엇일까?

대상의 차이

SNS 주제의 구독 대상은 상당히 적다.

AWS의 서비스로는 Kinesis, SQS, Lambda 밖에 지원이 안 되고 있다.

EventBridge 출시 전에는 SNS와 연동된 Lambda를 통해서 다른 서비스와의 연동을 진행했다고 한다.

이러한 Lambda 코드의 관리 또한 문제가 발생할 수 있는 지점이다.

반면 비교적 새로 출시된 서비스인 EventBridge는 대상으로 AWS의 다양한 서비스가 지원된다.

HTTP/S와 같은 경우는 SNS가 지원하기 때문에 특정 엔드포인트로 이벤트 정보를 보내고 싶다면 SNS가 적절할 것이고,

더 다양한 AWS 서비스를 대상으로 전송하고 싶다면 Event Bridge가 적절할 것이다.

Event 생성과 전달 차이

SNS와 EventBridge둘다 SDK를 통해 이벤트 생성을 지원한다.

SNS와는 다르게 EventBridge는 이벤트 버스로 전송을 하고 Rule을 통해 특정 이벤트에 대해서 알림을 전송할 수 있다.

간단히 세팅하고 싶다면 SNS가 좋을 수 있다.

하지만 구독자에게는 특정 이벤트만 전송하기 위해서, 이벤트에 따라 다양한 주제를 생성하고 구독자와 연결해야 한다.

반면, EventBridge는 이벤트 버스로 다양한 이벤트들(EC2의 이벤트까지)을 한 곳으로 수집하고 Rule과 필터링 설정을 통해 특정 이벤트에 따라 조치를 취할 수 있기 때문에 통합적으로 관리할 수 있다.

(SNS는 메시지의 내용에 따른 필터링이 안되기 때문에 Lambda를 통해 코드적으로 필터링을 진행했어야 했다.)

또한 다양한 3rd-party의 이벤트 소스와 연결도 가능하다.

성능 및 결론

살펴본 것과 같이 전체적으로 Serverless, SaaS 형태의 서비스간의 연결은 EventBridge가 적절해 보인다.

반면 EventBridge는 Rule당 대상은 최대 5개 까지만 설정된다. (Fan-Out이 5개...)

지연시간도 1s 이하로 비교적 느리다.

SNS의 경우 주제당 무려 12,500,000개의 구독자를 설정할 수 있다. (Fan-Out이 12,500,000개...)
지연시간 또한 100ms 미만으로 EventBridge에 비해 빠르다.

FIFO와 같은 메시지 순서 정렬 기능 등을 활용(SNS가 대상인 경우에)할 수 있어 쿠버네티스와 같은 인프라에서 대규모의 메시지와 이벤트 처리가 필요한 경우 적절할 것이다.

참조

https://blog.naver.com/sqlpro/223187832290

[번역] SNS 대신 EventBridge를 사용해야 하는 5가지 이유

* 이 글의 원문 출처은 아래와 같으며, Deepl을 통한 기계 번역을 거쳐 일부 내용을 덧붙였습니다. Amazo...

blog.naver.com

https://www.megazone.com/techblog_20200309_reducing-custom-code-by-using-advanced-rules-in-amazon-eventbridge/

[실습예제] Amazon EventBridge의 고급 규칙을 사용하여 사용자 지정 코드 줄이기

오늘 메가존 테크블로그에선 예제를 통해 Amazon EventBridge의 고급 규칙을 사용하여 복잡한 라우팅을 쉽게 처리하고, 애플리케이션 전체에서 사용자 지정 코드의 필요성을 줄여보겠습니다.

www.megazone.com

Hypervisor의 overcommit

EVEerNew — Sat, 20 Jul 2024 21:24:54 +0900

Hypervisor의 OverCommit

가상화의 핵심인 하이퍼바이저는 자원을 극한으로 효율적으로 사용하기 위해 OverCommit 기능을 사용한다.

VM들이 모두 같은 자원량을 나누어 사용한다고 가정해 보자.

이 기능을 사용하면, 하이퍼바이저가 물리 호스트의 자원을 정확히 VM 개수만큼 N등분하지 않고 N개 이상의 VM을 동작시킨다.

사실 모든 VM이 자원을 100% 활용하지 않기 때문에, AWS와 같은 CSP 입장에서는 자원을 1:1 크기로 예약해 두면 유휴 자원이 발생한다. 이러한 자원 낭비를 막고자 물리적인 컴퓨팅 자원보다 VM들에게 더 많은 CPU와 메모리를 프로비저닝 하게 된다. 이를 Overcommit이라고 한다.

CPU overcommit

CPU overcommit은 CPU 자원을 물리 호스트이상으로 VM에게 할당하는 것이다.

CPU는 Memory에 비해 비교적으로 비율이 높아, 1:4로 실제보다 VM에 4배에 가깝게 할당하기도 한다.

Memory처럼 실제 자리를 차지하기보다는 Hypervisor의 스케줄링으로 가상 코어를 돌아가면서 사용하기 때문인 듯하다.

심지어 Openstack의 기본 CPU overcommit ratio는 1:16으로, 실제 자원의 16배로 VM을 할당한다고 한다.

물론 유휴 VM이 얼마나 존재하느냐 따라 달라질 수밖에 없고, 높은 ratio에서 모든 VM에 부하가 발생하면 스케줄링이 점점 늦어지는 문제가 발생할 수 있으므로 각 Cloud 사들은 자신들의 최적의 ratio를 가지고 있다.

Memory overcommit

memory overcommit은 CPU Overcommit에 비해 리스크가 크기 때문에 할당하 ratio가 훨씬 낮다.

OpenStack도 memory overcommit은 기본적으로 1:1.5로 할당한다.

메모리는 Paging 기법을 통해, 디스크의 Swap 영역에 프로세스에 필요한 데이터를 올려두고 사용할 때에만 메모리에 옮겨 사용한다.

이때 메모리에 비해 Swap 영역은 I/O가 굉장히 느리기 때문에 시스템의 병목점이 된다.

특히 프로세스가 많아질수록 사용해야 하는 메모리 페이지가 많아지면서, 각 프로세스가 스케줄링되어 실행될 때 자신의 데이터가 메모리에 없어 Swap 영역에서 옮겨와 사용하는 경우가 많아진다.

문제는 각 프로세스들의 실행 순서마다 다른 데이터를 메모리에서 쫓아내고 자신의 데이터를 옮겨오게 된다.

따라서 실행 시간보다 Swap 영역에서 데이터를 로드하는 시간이 더 오래 걸리면서 심각한 시간 지연이 발생한다.

이를 스레싱(Thrashing)이라고 한다.

아무래도 1:N의 비율이 높아질수록, VM들의 메모리 적재가 많아지면 스레싱이 발생할 위험이 커지기 때문에 메모리의 비율이 비교적 낮은 것으로 보인다.

다행히 Memory Pressure 상황에서는 각 Hypervisor 별로 대처하는 다양한 방법이 존재한다고 한다.

Hypervisor의 Overcommit 기능이 있는 것은 물리 호스트의 자원에는 필연적으로 유휴 자원이 존재하기 때문이다.

특히 AWS EC2의 T시리즈에서는 할당된 자원보다 사용량을 높이는 Burstable인 인스턴스가 있는데, 이러한 유휴 자원을 최대한 사용하려는 목적으로 보인다.

참조

https://velog.io/@sjuhwan/Virtualization-101-3-1-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%98%A4%EB%B2%84%EC%BB%A4%EB%B0%8B%EA%B3%BC-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%97%AC%EC%9C%A0%EA%B3%B5%EA%B0%84-%ED%99%95%EB%B3%B4-%EB%B0%A9%EB%B2%95

Virtualization 101 - (3.1) 메모리 오버커밋과 메모리 여유공간 확보 방법

이번 포스팅에서는 직전의 메모리 가상화 파트에서 다루지 못했던 내용인 메모리 오버커밋과, 가상화 환경에서 메모리 압박(Memory pressure)를 핸들링 하는 방법을 알아본다.

velog.io

https://knight76.tistory.com/entry/openstack-%EC%98%A4%EB%B2%84-%EC%BB%A4%EB%B0%8Bovercommit-%EA%B3%B5%EB%B6%80

[openstack] 오버 커밋(overcommit) 공부

오픈 스택의 overcommit 정보 https://docs.openstack.org/arch-design/design-compute/design-compute-overcommit.html 오픈 스택의 가상화 서버의 overcommit 기본 값은 다음과 같이 되어 있다. 가상 서버를 사용할 때 효율을

knight76.tistory.com

https://brunch.co.kr/@leedongins/83

클라우드와 overcommit

About Infra. | 클라우드 시스템을 만드는 과정에서 클라우드 제공사는 컴퓨팅 노드에 CPU와 RAM을 실제 용량보다 더 크게 할당할 수 있습니다. 이렇게 클라우드 시스템에서 제공하는 프로세서를 virtu

brunch.co.kr

[AWS] CloudWatch가 EC2 Memory 모니터링을 제공하지 않는 이유는? (Hypervisor & OS)

EVEerNew — Sat, 20 Jul 2024 15:42:43 +0900

왜 CloudWatch가 EC2 Memory 모니터링을 제공하지 않을까?

EC2에서 CloudWatch는 CPU와 네트워크 정보는 기본적으로 수집을 제공한다.

반면에 Memory와 Disk 정보에 대해서는 CloudWatch Agent를 OS에 추가로 설치해야만 수집할 수 있다.

CPU까지는 기본적으로 수집할 수 있는데, 왜 Memory는 추가적인 소프트웨어를 설치해야만 수집할 수 있는 것일까?

핵심적인 원인은 Hypervisor Level과 OS Level에서 수집할 수 있는 정보의 차이다.

CPU는 Hypervisor Level

하이퍼바이저는 기본적으로 물리적 Host의 CPU 사용을 VM마다 적절히 분배해야 한다.

Guest OS는 하이퍼바이저에게 제공받는 시간만큼의 CPU를 사용하기 때문에, OS level보단 Hypervisor Level에서의 CPU 모니터링이 정확하고 더 적절할 수밖에 없다. (당연히 OS에서도 가능하다.)

기본적으로 AWS는 자신들의 하이퍼바이저에 Cloud Watch 모니터링을 세팅해둘 수 있으므로, 기본적으로 CPU 모니터링이 가능하다. (Cloud watch가 하이퍼 바이저에게 주기적으로 질의하는지, 하이퍼바이저가 주기적으로 메트릭을 전송하는지는 확실하지 않다.)

하이퍼바이저에 대한 질의는 각 VM의 성능에도 영향을 주지 않으므로, 고객 입장에서도 좋다고 생각한다. (전체적인 물리적 Host의 부하가 심하다면 다를 수 있겠지만)

Memory는 OS Level

반면 메모리는 하이퍼바이저가 모니터링하기 적절하지 않다.

그 이유는 OS는 기본적으로 가상 메모리를 사용하기 때문이다.

OS에서 동작하는 각 프로세스는 자신이 모든 메모리를 사용하는 것처럼 동작한다.

이를 위해 OS가 각 프로세스의 정보를 적절히 메모리에 적재하거나 디스크의 Swap 영역에 배치하는 등의 복잡한 메모리 관리를 진행해야 한다.

이를 Hypervisor가 일일이 추적하는 것은 오버헤드가 많이 발생한다.

반면 이미 VM의 메모리를 관리하고 있는 Geust OS 입장에서는 메모리 사용량 추적은 오버헤드가 거의 없는 쉬운 일이다.

따라서 VM의 OS에 CloudWatch Agent를 설치하여 메트릭 값을 CloudWatch로 주기적으로 보내야 메모리 모니터링이 가능하다.

정리하면 아래의 그림과 같다.

그리고 실제 Hypervisor들은 물리 호스트의 자원보다 더 큰 양의 자원을 VM들에게 배치하고는 한다.

이를 OverCommit 이라고 하는데 다음 글에서는 이에 대해서 알아보자

참조

https://stackoverflow.com/questions/44507609/why-aws-cloudwatch-does-not-have-memory-usage-metric-for-autoscaling-group

Why AWS CloudWatch does not have Memory usage metric for Autoscaling group

I am trying to create a graph for memory usage of an autoscaling group but I discovered that there is no such metric. Although there is Memory usage metric but it is for individual instances. It is

stackoverflow.com

Lambda의 VPC 접근을 위한 Hyperplane ENI

EVEerNew — Fri, 19 Jul 2024 23:31:03 +0900

VPC 세팅이 필요 없는 서버리스

AWS의 서버리스 서비스들은 별도의 VPC를 필요로 하지 않기 때문에, 기존에 VPC 자원들에서 사용해야 하는 보안요소에 신경 쓸 필요가 없다. 접근을 IAM Role 위주로만 관리해 주면 되기 때문에 보안적으로 우수하다고도 볼 수 있다.

특히 Lambda의 경우 서버리스 DB 인 DynamoDB와 연동하게 되면, 복잡한 세팅 없이 서로 Role로 접근하면 되기 때문에 찰덕 궁합이다. 따라서 서버리스는 서버리스와 사용했을 때 장점이 극대화된다고도 볼 수 있다.

Lambda와 VPC 내부 자원의 연결

하지만 RDBS를 사용해오기 때문에 DynamoDB가 아닌 RDS를 Lambda와 연동해야 할 수도 있다.

이럴 때 Lambda는 리전 level의 서비스인데, RDS와 같이 특정 VPC 내부에 배치되는 자원과는 어떻게 연결해야 할까?

사실 VPC가 없어 보이는 기본 Lambda도 기본적으로 인터넷에 액세스 할 수 있는 Lambda 관리형 VPC에서 실행된다.

계정의 VPC에 액세스를 위해서는 함수 생성 시, Advanced settings에서 VPC와 서브넷을 선택할 수 있다.

이후 적절한 보안그룹을 선택하면 된다.

이러한 VPC 내부의 Lambda는 자동으로 AWSLambdaVPCAccessExecutionRole을 통해서 해당 서브넷에 ENI를 생성한다. (이 역할이 삭제되면 ENI를 자동삭제 할 수 없게 되니 주의하자.)

이때 생성되는 ENI가 Hyperplane ENI이다.

Lambda Hyperplane ENI

Lambda는 AWS의 관리형 VPC에서 동작하기 때문에, VPC와 연결을 위한 엔드포인트인 ENI를 서브넷에 배치한다.

기존의 Lambda는 아래처럼 람다 인스턴스(MicroVM)마다 ENI를 매핑했다.

출처: https://aws.amazon.com/ko/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/

그림만 봐도 알 수 있듯이 인스턴스마다 ENI를 배치하기 때문에, 처음 생성 시 Cold start 및 환경 세팅 시간이 오래 걸리게 된다. 또한 ENI가 서브넷의 IP를 할당받기 때문에 빠르게 가용 IP가 부족해질 수 있다.

(Lambda의 인스턴스 Cold start에 대해서는 해당 게시글을 참조)

이러한 문제를 해결하기 위해 Hyperplane ENI가 만들어졌다.

(초평면이라는 뜻이라고 한다.)

이제 각각의 Lambda 인스턴스가 대상 VPC 서브넷에 ENI를 생성하는 것이 아니라, 하나의 Hyperplane ENI만 생성된다.

AWS의 Lambda 관리형 VPC에서 NAT를 통해 Hyperplane ENI로 접근하게 된다.

출처: https://aws.amazon.com/ko/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/

따라서 ENI 생성을 위한 대기 시간을 줄이고 IP까지 절약할 수 있다.

특히 Lambda 뿐만 아니라 동일한 보안 그룹과 서브넷 그룹을 사용하는 다른 함수도 이 Hyperplane ENI를 활용하여 ENI 수를 획기적으로 줄일 수 있게 된다.

Hyperplane ENI는 최대 65,000개의 연결/포트를 지원하기 때문에, 연결이 최대치 이상이라면 추가적인 ENI가 자동으로 배치 조정된다.

단, VPC 내부에서 Lambda를 실행하면 이러한 Hyperplane ENI 준비를 위한 대기 시간이 필요하다.

또한 Lambda 함수가 연속으로 30일 동안 사용되지 않으면, 자동으로 Hyperplane ENI를 회수되며 함수 상태가 유휴 상태로 설정된다. 따라서 유휴 상태에서 함수가 호출되면 활성화까지 시간이 소요된다.

참조 및 출처

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/foundation-networking.html#foundation-nw-eni

VPC를 사용한 프라이빗 네트워킹 - AWS Lambda

VPC에서 아웃바운드 IPv6 트래픽을 허용하려면 함수에 연결된 모든 서브넷이 듀얼 스택 서브넷이어야 합니다. Lambda는 VPC의 IPv6 전용 서브넷을 위한 아웃바운드 IPv6 연결, VPC에 연결되지 않은 함수

docs.aws.amazon.com

https://aws.amazon.com/ko/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/

Announcing improved VPC networking for AWS Lambda functions | Amazon Web Services

September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details. Update – August 5, 2020: We have fully rolled out the changes to the following additional Regions to those mentioned below. These improvements are

aws.amazon.com

[Docker] Host OS와 Container OS가 다른 경우 어떻게 될까?

EVEerNew — Wed, 17 Jul 2024 22:02:01 +0900

Docker를 사용하다 보면, Ubuntu Image위에 세팅을 하여 container Image를 빌드하고는 한다.

그렇다면 이 Image는 하나의 VM처럼 Ubuntu OS를 가상화해 제공해 주는 것일까?

Host OS의 커널을 공유하기 때문에 경량화와 최적화가 가능했는데, 이런 것이 가능할까?

또는 CentOS에 Docker를 설치하고 Ubnutu Image를 실행하면, 동작이 가능한 것일까? (미리 언급하면 가능하다.)

이번에는 이 주제에 대해서 알아보자.

핵심은 Host OS의 커널 공유

출처: https://www.cherryservers.com/blog/a-complete-overview-of-docker-architecture

왼쪽에서 확인할 수 있듯이, Docker는 Host OS위에 Docker engine이 동작하여 Container 들이 이 커널을 공유하는 형태이다.

따라서 container는 일종의 프로세스처럼 취급될 수 있다. 즉 별도의 OS는 없다.

반면 VM은 Hypervisor(타입 1)위에 각각의 VM들의 OS가 동작하는 모습으로, 하드웨어는 공유할지라도 OS Level을 공유하지 않기 때문에 각각의 OS가 필요하고 오버헤드가 심하다.

반면 공유 자원이 Docker비해 적기 때문에 보안적으로는 우수하다.

Host OS와 Container OS가 다른 경우

Container가 OS를 포함하지 않는데, CentOS Host에서 동작하는 Ubuntu Image의 컨테이너들은 도대체 무엇일까?

Docker는 Linux의 LXC(LinuX Containers)라는 격리 기술을 기반으로 만들어졌다. (현재는 자체 기술인 libcontainer로 변경)

태생이 그렇기도 하고, Docker는 기본적 Linux 커널의 격리 기술을 활용하도록 개발되었다.

따라서 대부분의 Linux 파생 OS에서 Docker를 사용할 수 있다.

경우에 따라서는 linux 커널의 버전이 달라 특정 CentOS 버전에서는 docker가 실행이 안되기도 하는 듯하다.

따라서 Window와 같은 타 OS를 사용한다면, Linux 계열 VM을 통해 Docker를 실행해야 한다.

결론적으로 Host OS가 CentOS라도 Linux 커널을 Base로 만들었기 때문에, 또 다른 Linux 계열인 Ubuntu 컨테이너를 동작시키 더라도 Linux 커널을 정상적으로 사용하기 때문에 문제없이 실행이 된다.

이러한 이유로 Window OS Image 같은 것은 존재하지 않을 것이라 생각했는데...

존재한다???

https://hub.docker.com/r/dockurr/windows

hub.docker.com

제작자의 영상을 확인해본 결과, 이런 마법 같은 일이 가능한 것은 정말로 Window container를 실행한 것이 아니라,

Window VM(KVM 활용)을 실행하는 Linux Contianer를 실행한 것이라고 한다. (이게 무슨??)

영상 중에서

하지만 정말 window의 기능을 활용하고 싶다면 실제 VM을 사용하길 권장하고 있다.

동일한 원리로 MacOS Image도 존재는 한다.

Windows Conatiner

윈도우에서 컨테이너를 지원하기 위해, 리눅스의 containerd 기반과 다르게 HCS버전의 Docker Engine을 실행할 수 있다고 한다.

이를 활용하면 Window OS Container도 실행시킬 수 있을까 싶지만, Window OS Image는 Microsoft에서만 제작을 독점하고 있기 때문에 라이선스 보유 필요하고 한다.

https://tech.devsisters.com/posts/start-windows-container-dev

[Windows 컨테이너] 2: Windows 컨테이너 개발 환경 구축하고 테스트하기

Windows 컨테이너를 실제로 개발하기 위하여 개발 환경을 구축하는 방법을 살펴봅니다. 그리고 첫 Windows 컨테이너를 만들어봅니다.

tech.devsisters.com

참조

https://forums.docker.com/t/how-is-this-possible-centos-container-on-ubuntu-newbie-question/21558

How is this possible? CentOS container on Ubuntu (newbie question)

Hi, I’m a newbie to Docker and Linux. Following this training and many others I see that you can run a “centos” container on a Ubuntu Linux OS. How is this possible? The way I am seeing containers would contain applications and its dependencies. Plea

forums.docker.com

https://www.docker.com/blog/lxc-vs-docker/

Linux Containers vs. Docker: Which One Should You Use? | Docker

Explore the key differences between Docker and LXC to determine which containerization technology best suits your project needs.

www.docker.com

[AWS] Lambda의 Cold Start와 Concurrency 문제 해결

EVEerNew — Mon, 15 Jul 2024 20:34:20 +0900

Lamdba의 기반인 Firecracker와 microVM

AWS의 Lambda도 결국에는 컨테이너 기반의 서비스이다.

Docker와 같은 컨테이너 서비스보다 훨씬 빠른 반응 속도를 보이는 것은 AWS가 개발한 Firecracker 기반의 가상화 기술을 활용하기 때문이다.

기존의 다양한 서비스보다는 간단한 게스트 기능만을 제공하기 때문에 보안뿐만 아니라 오버헤드까지 줄였다.

이때 사용되는 것이 경량화 가상 머신인 mircoVM이다.

microVM는 약 5MiB의 메모리와 125밀리 초 안에 실행시킬 수 있다고 공식 문서에서 밝히고 있다.

Cold Start와 Warm Start 그리고 성능 향상

Lambda가 이러한 microVM에서 동작하기 때문에 굉장히 빠르지만, 결국에는 초기에는 사용자 코드를 다운로드하고 수행을 시키기까지의 딜레이가 존재한다.

이러한 딜레이는 함수가 처음 수행되었을 때 가장 크게 발생하고 이를 Cold Start라고 한다.

https://docs.aws.amazon.com/lambda/latest/operatorguide/execution-environments.html

반면, 한번 수행시킨 함수는 재실행시켰을 때 initaliztion 과정이 미리 준비가 되어 있기 때문에 더 빠르게 실행된다.

이러한 수행 방식은 Warm Start라고 한다.

https://docs.aws.amazon.com/lambda/latest/operatorguide/execution-environments.html

여기서 Warm Start는 위의 Cold Start와 다르게 Execute Initialization 부분도 initaliztion에 포함되는 것이 눈에 띈다.

즉, Lambda의 handler 함수 밖에 있는 전역 부분은 Cold Start 시점에서만 진행되고, 이후에는 해당 값이 유지되면서 재사용된다.

따라서 위의 예시 코드처럼, 항상 os.environ['환경변수']를 통해 환경변수를 가져오지 않아도

lambda_handler() 함수 밖에 배치하여 Execute Initialization 시점에 실행되도록 세팅하면 함수의 최적화가 가능하다.

특히 DB 연결을 전역에서 실행하면, 모든 함수 호출이 DB와 Connection을 만들지 않기 때문에 Lambda 함수와 DB 입장에서도 훨씬 나은 최적화가 가능하다.

이를 시각적으로 표현하면 이와 같다.

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-concurrency.html

Lambda의 동시성(concurrency)

문제는 Lambda는 순서대로 하나씩 호출되는 것이 아니라 동시에 여러개가 호출될 수 있다는 것이다.

따라서 특정 시점에 요청이 몰리면 Cold start는 최대 동시 실행 개수 만큼 일어날 수 있다.

초록선 아래에 숫자가 현재 실행되는 함수의 개수이다.

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-concurrency.html

해당 GIF를 확인하면 최대 동시 실행 개수인 6만큼 Cold start가 일어나는 것을 확인할 수 있다.

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-concurrency.html

예약된 동시성(Reserved concurrency)

문제는 계정당 함수 동시성은 동시에 1000개로 한정되어 있다. (요청시 확장은 가능)

함수 종류에 관계 없이 풀이 가득 차면 동시성 문제로 함수 실행자체가 되지 않는다.

다른 기타 함수로 인해 중요 함수가 실행되지 않는다면 심각한 서비스 문제가 될 수 있다.

따라서 AWS는 특정 함수의 동시성 개수를 예약시킬 수 있다.

아래처럼 두개의 함수를 각각 400개씩 예약하여 최소한의 개수가 동시 실행될 수 있도록 보장한다.

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-concurrency.html

프로비저닝된 동시성(Provisionedconcurrency)

이전에는 Cold start를 방지하고자, 요청이 없더라도 일정 주기마다 Fake 호출을 진행했다고 한다.

하지만 이제 AWS에서 프로비저닝된 동시성을 제공한다.

프로비저닝된 동시성을 사용하면, Warm 환경이 유지된다.

따라서 아래 그림처럼 일반 함수는 텀이 지나면 t3시점에서 초기화되지만, 프로비저닝된 동시성은 계속 Warm 환경이 유지된다.

물론 Warm 상태가 지속적으로 유지되므로 비용이 발생하므로 운영 정보를 통해 적절한 세팅 값을 설정해야 한다.

참조

https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/lambda-concurrency.html

Lambda 함수 규모 조정 이행 - AWS Lambda

Lambda 함수 규모 조정 이행 동시성은 AWS Lambda 함수가 동시에 처리하는 전송 중인 요청 수입니다. 각 동시 요청마다 Lambda는 실행 환경의 개별 인스턴스를 프로비저닝합니다. 함수가 요청을 더 많

docs.aws.amazon.com

https://docs.aws.amazon.com/lambda/latest/operatorguide/execution-environments.html

Lambda execution environments - AWS Lambda

Lambda execution environments Cold starts and latency When the Lambda service receives a request to run a function via the Lambda API, the service first prepares an execution environment. During this step, the service downloads the code for the function, w

docs.aws.amazon.com

https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-%EB%9E%8C%EB%8B%A4-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0-Cold-Start-%ED%95%B4%EA%B2%B0#%ED%94%84%EB%A1%9C%EB%B9%84%EC%A0%80%EB%8B%9D%EB%90%9C_%EB%8F%99%EC%8B%9C%EC%84%B1_%EA%B8%B0%EB%8A%A5_%ED%99%9C%EC%84%B1

[AWS] 람다 성능 개선 (Cold Start 해결) 전략 4가지

알다시피, 람다함수가 들어있는 서버리스의 항상 활성화 되어 있지 않다. 그래서 사용자의 요청이 들어왔을때 람다함수를 실행하기 위한 부수적인 준비 세팅이 필요하고 이로인해 대략 수초~수

inpa.tistory.com

https://velog.io/@ayoung0073/OS-Firecracker

[OS] Firecracker

(공부 중) Linux KVM을 사용하여 microVM을 만들고 관리하는 가상 머신 모니터 (VMM)

velog.io

왜 Web server와 WAS의 분리가 필요할까?

EVEerNew — Sun, 14 Jul 2024 22:43:04 +0900

3Tier

기본적으로 3Tier는 Presentation, Application 그리고 Data Tier로 나뉜다.

여기서 웹서비스라면 Presentation Tier는 Web server로, Application Tier는 WAS(Web Application Server)로 대표된다.

https://docs.aws.amazon.com/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/three-tier-architecture-overview.html

Data Tier는 주로 RDBS처럼, 웹 개발 중에 자연스럽게 분리되는데 문제는 Web server와 WAS이다.

검색하는 여러 장점이 있더라도 Web server와 WAS를 굳이 다른 서버로 분리할 필요가 있을까?

WAS의 Nginx나 Apache가 Web server의 역할도 수행해도 문제가 없어 보이기도 한다.

실제로 PHP의 대표적인 웹 서비스 오픈소스인 워드 프레스는 web server와 WAS가 하나로 합쳐진 2 Tier로 서비스를 제공한다. 워드 프레스가 굉장히 인기 있는 웹 서비스 프로젝트인 것을 생각해 보면, 2Tier로도 충분히 웹서비스는 동작시킬 수 있는 것은 확실하다.

왜 Webserver와 WAS가 분리될까?

그럼에도 Web server가 WAS와 분리가 필요한 이유는 3Tier가 웹서비스를 기능별로 분리하기 때문이라 생각한다.

Web server는 접속자 누구에게나 동일한 정적 컨테츠/페이지를 제공하고,

WAS는 접속한 유저에 따라 로직을 수행하여 다른 동적인 컨텐츠/페이지를 제공해야 한다.

물론 WAS도 기능적으로 충분히 정적 컨텐츠를 제공할 수 있다.

하지만, WAS는 동적인 처리를 진행하기 때문에 필연적으로 CPU와 Memory 부하가 커지게 된다.

반면 Web server는 단순히 요청에 따른 콘텐츠만 제공해 주면 되기 때문에, 굉장히 간단히 요청들을 처리할 수 있다.

따라서 CPU와 Memory가 굉장히 적다.

지표로 확인하기

실제로 모니터링 지표를 통해 확인해보았다.

1. Web server(Nginx)

0.25 vCPU, 0.5GB RAM Fargate에 3000명 동시 접속 테스트

메인 페이지의 요청에서, Webserver는 사실상 CPU만을 활용하고 있다.

2. WAS(Apache2 + PHP)

0.25 vCPU, 0.5GB RAM Fargate에 512명 동시 접속 테스트

더 적은 동접자 수에도 WAS는 동적인 페이지의 요청으로 인해 CPU 그리고 Memory를 상당히 많이 사용하고 있다.

Nginx와 Apache2를 비교하는 것은 적절하지 않을 수 있지만, 확실한 것은 Web server와 WAS에게 가해지는 부하가 다르다는 것이다.

이런 상태에서 만약 WAS가 정적 콘텐츠까지 제공한다고 생각해 보자.

WAS로 가해지는 부담은 커지고, 더 쉽게 서버가 다운될 것이다.

하지만 Web server가 분리되면서 WAS는 동적 로직 처리에 집중할 수 있고, 이를 위한 하드웨어 스펙도 적절히 세팅해 줄 수 있을 것이다.

이러한 케이스처럼 Web server와 WAS가 분리되면서 얻을 수 있는 장점이 큰 경우 3Tier전략이 적절할 수 있다.

반면, 정적 콘텐츠가 적거나 S3와 같은 외부 스토리지나 CDN 서비스에서 바로 제공할 수 있다면 2Tier로도 충분히 서비스를 운영할 수 있을 것이다.

전적으로 판단은 워크로드가 어떠냐에 따라 달라질 수 있고, 3Tier만이 정답인 것도 아니다.

AWS ALB의 Path routing 활용하기

EVEerNew — Sat, 13 Jul 2024 16:57:02 +0900

일반적인 3Tier에서의 ALB

AWS에서 3Tier를 구성하는 경우, 일반적으로 ALB를 Presentaion Tier(Web Server)와 Application Tier(WAS) 사이에 하나씩 배치한다.

Interfacing ALB는 Web server에 트래픽을 분산한다.

만약 동적인 페이지가 필요하다면, Internal ALB로 WAS로 다시한번 트래픽을 분산하는 설계이다.

이를 위해서는 모든 동적 페이지 요청과 응답이 Web server를 거치도록 프록시 설정이 되어야 한다.

또한 Internal ALB가 추가로 배치되어 비용이 발생한다.

본인의 토이 프로젝트처럼, 단순히 WAS용 페이지(예를 들면 로그인, 회원가입, 개인정보 페이지)와 Web server용 페이지(메인 정적 페이지)가 따로 있다면 Web server와 중간의 Internal ALB를 거쳐야만 할까?

결국 단순히 Web server가 프록시의 역할만 해주기 위해 거쳐간다면, 불필요한 오버헤드가 발생한다.

우리는 Interfacing ALB라는 Endpoing가 이미 존재하기 때문에, Interfacing ALB가 바로 WAS로 트래픽을 전달해 주면 문제가 해결된다.

이를 위해서 ALB의 Path Routing 기능을 사용하면 된다.

ALB Path Routing

Client가 접근하는 URL Path에 따라서 다른 대상 그룹으로 트래픽을 전달한다.

기본적인 정적 페이지 접근이라면 /* 은 모두 web server로 전송하지만,

/sign*, /myprofile* 과 같은 경로로 접근한다면 바로 WAS로 전달하여 오버헤드를 줄인다.

로드벨런서의 리스너를 확인해 보자.

이곳에서 리스너의 규칙에 경로 패턴을 설정하여, 서로 다른 대상그룹 (Web server와 WAS)으로 전송할 수 있다.

Path 이외에도 헤더나 query string을 활용해 대상을 다르게 지정할 수 있다.

AWS Code Build buildspec , 컨테이너 빌드 및 ECR 전송 (Terraform)

EVEerNew — Sat, 6 Jul 2024 23:15:01 +0900

buildspec.yaml

AWS의 Code build에서는 Buildspec이라는 yaml 파일에 어떻게 빌드를 진행할지 작성해주어야 한다.

Build는 어떤 것을 CI 하느냐에 따라서 빌드 방식이 달라지기 때문에 이러한 빌드 파일작성은 Git Actions에서도 아래처럼 특정 폴더에 build 파일을 작성해 주어야 한다.

git actions의 build yaml

Code build 생성시 별다른 세팅이 없다면, 자동으로 소스 코드의 루트 디렉터리에 존재하는 buildspec.yaml을 사용하게 된다.

buildspec 예시

Code commit 레포지토리의 파일들을 git 레포지토리로 옮겨둔 링크이다.

https://github.com/overnew/AWS_PHP_SDK_CodeBuild_example

GitHub - overnew/AWS_PHP_SDK_CodeBuild_example: apache2, awsphp sdk, docker build, code build example

apache2, awsphp sdk, docker build, code build example - overnew/AWS_PHP_SDK_CodeBuild_example

github.com

env: 환경변수를 정의

phases: CodeBuild가 빌드의 각 단계에서 실행하는 명령

install: 빌드 환경을 위한 라이브러리 명시

pre_build, build, post_build: 빌드를 위한 단계 구분(build하나에 몰아서 해도 상관 x)

commands: 빌드 인스턴스의 OS에 해당하는 명령어를 나열하여 빌드 진행. (AmazonLinux2를 사용)

artifacts: 빌드 결과물을 저장하여, 추후 배포 과정에 활용

해당 코드를 통해 ECR에 빌드한 컨테이너를 저장하고, appspec.yaml을 남겨 code deploy에서 배포 시 활용할 수 있도록 설정하였다.

ECS를 사용하는 인프라이기 때문에 배포시, 새로운 task 정의 개정이 필요했다.

buildspec에서는 단순히 AmazonLinux의 명령어만 쓸 수 있기 때문에 복잡한 문자열작업에는 적합하지 않았다.

따라서 python을 통해 새로운 task 정의를 생성할 수 있도록 세팅하였다.

이처럼 단순 명령어 뿐만 아니라 다양한 작업도 할 수 있으며, 빌드 전 테스팅까지 진행할 수 있다.

레포지토리와 연결이 된 Code build 프로젝트에서 빌드를 진행하면 정상적으로 수행되어, ECR 레포지토리에 저장되는 것을 확인할 수 있다.

ECR에 새로 업로드된 이미지가 확인된다.

이 과정에서 Code build에 적절한 Role (S3, ECR, Code Commit) 설정이 되지 않으면 권한 문제가 발생하기 쉬우니. Code build가 접근하는 서비스에 대해 잘 이해하고 Role 설정을 해주자.

그래도 오류가 발생한다면, code build 생성 시 특권 모드를 활성화해주자.

아래는 위의 Buildspec 파일이 적절히 동작하기 위한 Role의 Json이다.

https://gist.github.com/overnew/85924993690786bd468ff02ce83fbb49

final_role.json

final_role.json. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

Terraform

참조

Docker build 공식 문서

https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/sample-docker-section.html

Docker 샘플에 대한 CodeBuild - AWS CodeBuild

(root directory name)은 업로드하지 말고, (root directory name) 안에 있는 파일만 업로드하십시오. S3 입력 버킷을 사용하고 있는 경우, 파일을 포함하는 ZIP 파일을 생성한 다음, 이를 입력 버킷에 업로드

docs.aws.amazon.com

AWS ECS Fargate 모니터링 (2) - AWS Grafana(SAML)

EVEerNew — Wed, 3 Jul 2024 13:26:21 +0900

이전글에서 AMP를 세팅한데 이어서 AWS Grafana를 통해 시각화를 해보자.

ECS Fargate 실시간 모니터링 구성도

AWS ECS Fargate 모니터링 (1) - Side car (otel), AMP

Fargate를 위한 실시간 모니터링 ECS의 Fargate도 모니터링은 Container insight를 활용하면 Cloud Watch에서도 각 Task의 지표 정보를 수집할 수 있다.하지만 Cloud Watch의 한계로 지표를 확인할 때까지 1분 이

everenew.tistory.com

AWS Grafana

AMP(AWS Managed Service for Prometheus)는 설치형 Prometheus와 다르게 대시보드 자체의 접근을 지원하지 않는다. 따라서 Grafana와 같은 시각화 툴로 모니터링 대시보드를 제공할 필요가 있다.

실제로 Prometheus 자체의 대시보드 보다는 전문 시각화 툴인 Grafana와 같이 사용한다.

여기서 Grafana를 AWS EC2 자체에 띄운다는 가장 간단한 솔루션이 있지만, Grafana만을 위한 VPC에 ALB와 NAT GW를 세팅하는 등의 보안 신경 써야 하는 문제가 많아진다. 무엇보다, 실제 운영 환경이라면 시각화 서버인 Grafana의 가용성을 보장할 수 있도록 Active - standby와 같은 설계까지 진행해야 한다.

따라서 시각화 서버 하나만을 위해 상당한 관리 포인트와 비용이 발생한다.

이럴때 고려할 수 있는 서비스가 AWS의 관리형 서비스이다.

관리형 서비스만이 모든 환경의 정답은 아니지만, AWS Grafana는 등록된 관리자 유저별 월 9 USD와 뷰어 유저별 월 5 USD라는 상당히 저렴한 비용으로 사용할 수 있다.

위에서 설명한 관리포인트를 모두 줄이는 데도 이 가격이면 충분히 도입해볼만 하다.

AWS Grafana 세팅

AWS Grafana는 AWS 계정으로 로그인하거나 SAML 통해 외부 로그인 서비스를 사용할 수 있다.

AWS 계정을 통한 세팅은 편리하지만 클라이언트가 이미 다른 SSO 서비스를 사용해서 이를 SAML으로 연동하는 것으로 해보자.

유명한 업체는 Okta이지만, 연동에 계속 오류가 발생해서 Onelogin으로 진행해 보았다.

인증에서 SAML을 선택해 주자.

연결 서비스는 Prometheus와 SNS(알림용)를 선택해 주자.

생성이 완료되면, SAML 세팅을 진행한다.

SAML(Onelogin) 세팅

1달 무료 이용을 제공하는 Onelogin을 통해 SAML연동을 진행해 보았다.

Applications에서 Add App을 통해 AWS Grafana를 추가한다.

Configuration에 생성한 grafana의 url을 입력한다.

이 세팅은 Onelogin에서 바로 AWS Grafana로 접속하기 위한 용도라서 중요한 세팅은 아니다.

이후 reapply로 적용 해주자.

유저 맵핑을 위해 아래와 같이 세팅한다.

원래는 아래처럼 contain으로 하나의 email에만 Admin role을 적용해야 한다.

본인은 계속 admin 접속이 안되어서 does not eqaul로 세팅했다.

원래는 하나의 email을 대상으로만 admin 제공

세팅을 적용해 주자.

이후 Issuer URL을 선택해 복사한다.

이 URL을 AWS grafana saml 세팅의 메타데이터에 넣어주자.

이때 어설션 속성 매핑을 위와 정확히 동일하게 해 주어야 admin 로그인이 가능하다.

잘 안된다면 app Admin까지 직접 추가해 주자.

AWS Grafana와 AMP 연동

이제 그라파나의 url로 접속하면 saml을 통한 로그인이 가능하다.

Admin role 세팅에 성공해야만 아래와 같이 Admin 메뉴가 확인된다.

Data source에서 Prometheus를 선택해 주자.

이전 글에서 생성해 준 AMP의 쿼리 URL을 복사

*/api/v1/query 부분은 자동 추가되니 제거하고 붙여 넣자!*

AWS 연동에 SigV4 auth를 사용하므로 enable 해주자. 이를 통해 할당된 Role로 AWS 서비스에 연결할 수 있다.

(표시가 안된다면 버전 업이 필요할 수 있다. 세팅 기준은 9.4 버전이다.)

EC2가 아니므로 AWS grafana의 Role을 사용해야 한다.

사실 해당 Role은 생성 시, AMP 연결을 선택하였으므로 생성된 권한이 이미 있다.

이대로 Data source save test를 하면 성공한다.

Grafana 대시보드 세팅

build a dashboard로 연동을 확인해 보자.

ECS Fargate의 Task들의 CPU util이 정상적으로 확인된다.

Import dashboard로 대시보드를 세팅해 보자.

import 방법

https://grafana.com/grafana/dashboards/17419-aws-ecs-fargate-template-for-cloudwatch-exporter/

ecs fargate dashboard

https://ecsworkshop.com/monitoring/amp_amg/visualize_metrics/

해당 dash board는 지표이름이 맞지 않아서 세부 쿼리 세팅을 해주면 된다.

각 클러스터에서 동작하는 태스크 개수를 알기 위해 직접 쿼리를 세팅해 보자.

count(count(ecs_task_cpu_reserved_None{aws_ecs_task_id=~".*", aws_ecs_cluster_name="<클러스터 이름>"}) by (aws_ecs_task_id))

또는

count(count(ecs_task_cpu_utilized_None{TaskId=~".*", ClusterName="app-ecs"}) by (TaskId))

이러면 특정 클러스터에서의 태스크 개수를 셀 수 있다.

이렇게 각 패널을 원하는 대로 세팅해 주면 ECS Fargate 대상으로도 실시간 모니터링이 가능해진다.

참조

https://docs.aws.amazon.com/grafana/latest/userguide/AMG-SAML-providers-onelogin.html

https://onelogin.service-now.com/support?id=kb_article&sys_id=e555e5211bb1b450b9d8cb3f034bcbf1

AWS ECS Fargate 모니터링 (1) - Side car (otel), AMP

EVEerNew — Tue, 2 Jul 2024 22:14:22 +0900

Fargate를 위한 실시간 모니터링

ECS의 Fargate도 모니터링은 Container insight를 활용하면 Cloud Watch에서도 각 Task의 지표 정보를 수집할 수 있다.

하지만 Cloud Watch의 한계로 지표를 확인할 때까지 1분 이상의 지연이 발생한다.

예를 들면 12분 0초의 지표가 13분에야 확인이 된다.

실시간 모니터링이 필요하다면, Container insight와 Cloud watch만으로는 한계가 있다.
만약 EC2 Base의 ECS라면 EC2 자체에 Prometheus Agent를 설치하여 지표를 수집할 수 있지만, Fargate는 OS에 커스텀을 할 수가 없다.

그러므로 Task내에 지표 수집 및 전송을 제공하는 Side Car를 배치하여 실시간 모니터링을 제공해보자.

Side Car인 AWS Distro for OpenTelemetry (otel)

ADOT는 CNCF의 OpenTelemetry의 AWS버전으로, AWS의 다양한 자원의 지표를 AWS 서비스(다른 곳도 가능)로 전송가능하다.

https://aws-otel.github.io/docs/introduction

Introduction | AWS Distro for OpenTelemetry

Welcome to the AWS Distro for OpenTelemetry docs

aws-otel.github.io

지표를 전송할 대상은 AMP(AWS Managed for Prometheus)이다. 지표 데이터라면 Opensearch(AWS의 Elastic Search)보다는 Prometheus가 적절하다.

AWS X-ray 또한 지표 데이터의 수집 및 모니터링을 제공하지만, 지표보다는 트랜잭션 로그 데이터의 수집과 분석에 특화된 듯하다. 따라서 AWS Prometheus와 AWS Grafana를 통해 실시간 모니터링을 제공해 보자.

모니터링 구성도

Task 정의에 otel side car설정

Task 정의에 Application 컨테이너에 추가적으로 아래의 정보로 Side car 컨테이너를 넣어주자.

Otel의 공식 이미지를 사용하는데, NAT GW가 없는 Private 망에서 ECS를 사용한다면 Private Repository에 해당 이미지를 옮겨서 사용하면 된다.

이미지 URL

https://public.ecr.aws/aws-observability/aws-otel-collector:latest

명령어에 아래와 같이 otel이 사용할 기본 config의 위치를 제공해 주자.

실제 config yaml은 다음과 같다.

https://github.com/aws-observability/aws-otel-collector/blob/main/config/ecs/ecs-amp.yaml

확인해 보면 AWS Prometheus의 주소를 환경변수로 요구하고 있다.

AMP를 생성한 후, 해당 엔드포인트 주소를 제공해 주면 된다.

이를 위해서 AMP 세팅이 필요한데 관리형 서비스라 굉장히 편리하게 생성된다.

AMP(AWS Managed Service for Prometheus) 설정

관리형 서비스이기 때문에 지표를 전송과 쿼리 양만큼만 비용을 제공하기 때문에, 테스트로 생성해도 문제는 없을 것이다.

이 데이터만 넣어주면 생성이 된다.

생성된 후, 원격 쓰기 URL을 otel의 amp 엔드포인트 환경 변수로 넣어주면 된다.

Task 실행 결과

세팅이 정상적으로 준비되면 실행시켜 확인해 보자.

side car가 정상적으로 동작한다.

로그에서도 otel이 지표 정보를 보내고 있는 것이 확인된다.

확인 결과 0.25 vCPU, 0.5GB Memory에서 트래픽 부하가 없을 때 2~4% 정도의 사용률을 보인다.

Otel side car는 경량화 수집이기 때문에 Task의 성능에는 부담이 없는 듯하다.

지표 커스텀

내부의 config 정보를 사용할 수도 있지만 직접 커스텀할 수도 있다.

ECS의 컨테이너 환경변수는 Value From으로 Parameter Store에서 정보를 가져오는 기능이 있다.

AOT_CONFIG_CONTENT의 값으로 otel-collector-config로 세팅해 주자.

otel-collector-config라는 파라미터를 Systems Manager의 Parameter store에 세팅해 주자.

config 내용은 아래의 yaml에서 수정해서 넣어주면 된다.

https://github.com/aws-observability/aws-otel-collector/blob/main/config/ecs/ecs-amp.yaml

aws-otel-collector/config/ecs/ecs-amp.yaml at main · aws-observability/aws-otel-collector

AWS Distro for OpenTelemetry Collector (see ADOT Roadmap at https://github.com/orgs/aws-observability/projects/4) - aws-observability/aws-otel-collector

github.com

Task 정의 json

json으로 정의하는 경우 아래와 같이 해주자.

다음글에서는 AWS Grafana와 연동을 진행해보자.

다음글

AWS ECS Fargate 모니터링 (2) - AWS Grafana(SAML)

이전글에서 AMP를 세팅한데 이어서 AWS Grafana를 통해 시각화를 해보자. AWS ECS Fargate 모니터링 (1) - Side car (otel), AMP AWS ECS Fargate 모니터링 (1) - Side car (otel), AMPFargate를 위한 실시간 모니터링 ECS

everenew.tistory.com

참조

Otel ecs Fargate amp 워크샵

https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs/ingest-custom

Otel 공식 ecs Fargate amp 세팅 문서

https://aws-otel.github.io/docs/getting-started/prometheus-remote-write-exporter

AWS ECS Task와 Service 그리고 Auto scaling (Terraform)

EVEerNew — Tue, 2 Jul 2024 13:49:30 +0900

ECS Task란?

ECS의 배포/관리의 최소 단위는 Task이다.

Kubernetes의 배포/관리의 최소 단위인 Pod와 굉장히 유사하다.

Task는 여러 개의 컨테이너로 구성되며, Fargate를 사용하는 경우 실시간 모니터링을 위해 Side car 컨테이너를 같이 배치하기도 한다. 실제로는 여러 개의 컨테이너를 Task나 Pod에 배치하는 것은 권장되지 않고 Side car나 필수 보조 컨테이너를 배치하는 정도로만 사용된다.

처음에는 Task를 그냥 컨테이너로 생각해도 괜찮다고 본다.

ECS Service와 Task Auto Scaling

여러개의 Task를 독립적으로 하나하나 관리하는 것은 어렵다.

ECS도 Kubernetes의 Service(Deployment나 replica set)처럼 여러 개의 Task를 배포/관리할 수 있는 Service 기능을 제공한다.

이 Service에서 정의된 Task의 최소/원하는/최대 개수를 설정하여, 동일한 Task를 필요한 만큼의 동작시킬 수 있다.

여기서 Task의 Auto Scaling이 적용될 수 있다.

컨테이너는 EC2에 비해서는 훨씬 빠른 프로비저닝 시간을 가지므로 더 효과적인 탄력성을 제공할 수 있다.

단순히 대상 추적으로 조정을 하면, 갑작스러운 부하에도 Task가 단순히 하나씩 추가된다.

이러는 경우 AutoScaling을 적용했지만, 모든 Task가 죽어버릴 수 있다.

실제로 Fargate로 태스트 해볼때는 Task의 CPU가 한계를 초과하면 ECS가 자동으로 Task를 죽이고 새로운 Task를 실행시킨다.

결국 트래픽은 어디에서도 처리되지 못하는 상황이 발생한다.

따라서 부하도 별로 적절하게 Task 개수를 추가할 수 있는 단계 조정 정책이 현실적이다.

물론 결국에 단계 조정 정책도 운영 데이터를 통해 최적화해 나가야 한다.

Terraform

terraform에서 이를 적용하려며면, aws_appautoscaling_policy를 활용해야 한다.

Scale in도 이와 유사하게 추가하면 된다.

전체 코드

https://github.com/overnew/Cloud-SIEM-Infra-Terraform/blob/master/ecs/main.tf

Cloud-SIEM-Infra-Terraform/ecs/main.tf at master · overnew/Cloud-SIEM-Infra-Terraform

AWS Web service & SIEM Infra by Terrform. Contribute to overnew/Cloud-SIEM-Infra-Terraform development by creating an account on GitHub.

github.com

결과

30~40%의 평균 CPU에서는 task를 한 개만 추가하지만, 40~50%에서는 두 개 그리고 50% 이상에서는 3개를 동시 추가하여 트래픽에 대해 대응한다.

부하가 없을 때는 최소 Task 개수로 동작한다.

부하가 급증하면 동시에 3개의 Task를 추가해서 대처한다.

4개의 Task로 대처하기 때문에 평균 부하가 감소한다.

부하가 감소되면 Task도 scale in된다.

부하가 종료되면 결국 최소 Task로 돌아오게 된다.

참조

https://www.opsnow.com/ecs-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%97%90-auto-scaling-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0/

ECS 서비스에 Auto Scaling 적용하기 - OpsNow

EC2를 이용하여 서비스의 크기를 조절하기 위해서는 충분한 시간이 필요했습니다. Auto Scaling 기능의 매력은 충분하나, 급변하는 트래픽이나 사용량에 대해서 민첩하게 대응하기는 어렵습니다.

www.opsnow.com

VPC Endpoint로 ECR 연결하기 (Docker hub와 S3의 관계)

EVEerNew — Mon, 1 Jul 2024 23:16:31 +0900

기존에는 VPC Interface Endpoint 중에 ecr.api만 연결해 주면, ECR private link로 연결되는 알았다.

하지만 테스트 결과, NAT Gateway를 VPC에서 빼주면 Fargate가 ECR에서 컨테이너 이미지를 가져오지 못하는 것을 확인했다.

결론을 이야기 하면, ECR 연결을 위해서는 아래의 3가지 Endpoint가 필요하다.

Interface endpoint: ecr.dkr, ecr.api

Gateway endpoint: S3

dkr까진 이해가되도 S3는 굉장히 뜬금없지 않은가?

그 이유를 지금부터 확인해보자.

Docker hub는 S3 저장소를 사용

아래의 Cloud flare(네트워크 전문 회사로 주로 CDN 서비스에서 확인해 본 적 있을 것이다.)의 케이스 스터디 글을 확인해 보자.

https://www.cloudflare.com/case-studies/docker/

Cloudflare & Docker | Case Study

Cloudflare boosts Docker’s cache hit ratio to more than 99%, eliminating two-thirds of S3 egress and cutting costs

www.cloudflare.com

Cloudflare는 Docker의 캐시 적중률을 99% 이상으로 높여서, S3의 송신 발생을 2/3까지 제거했다고 한다.

S3는 무엇이든 저장하는 저장소로는 훌륭할지 몰라도, CDN 서비스가 아니기 때문에 데이터 송신을 제공하면 상당한 비용이 발생한다. Cloud front라도 송신 비용은 S3와 동일하다.

따라서 CDN을 AWS의 Cloud front가 아닌 Cloud flare의 CDN 서버를 통해 제공하여, 훨씬 큰 비용 절감을 가져간 듯하다.

ECR도 S3 저장소를 사용

AWS의 컨테이너 서비스를 사용할 때, Docker hub에서 이미지를 가져올 수도 있지만, public 망으로 요청과 수신이 이뤄지므로 보안적으로는 좋지 않다.

따라서 AWS의 ECR을 사용하게 되는데, 결국 ECR도 크고 많은 컨테이너 이미지들을 독자적인 저장소가 아닌 AWS S3로 저장하게 설계되었다. 따라서 Amazon S3 서버 측 암호화를 사용해 자동으로 암호화도 진행된다.

ECR은 이미지 매니페스트까지만 제공해 주기 때문에 결국 S3에서 실제 이미지 Layer를 받아와야 한다.

단일 VPC라면 S3 Gateway endpoint를 사용하는 것이 좋고, 다중 VPC/계정이라면 Interface endpoint를 배치하여 접근 세팅을 세분화할 수 있다.

실제로 S3가 연결되지 않으면, 아래처럼 연결 오류가 발생한다.

결론

결론적으로 ECR 연결을 위해서는 아래의 3가지 Endpoint가 필요하다.

Interface endpoint: ecr.dkr, ecr.api

Gateway endpoint: S3

(본인은 단일 VPC이므로 Gateway 타입을 선택했다.)

ecr.api의 경우 레지스트리 생성, 이미지 목록 조회와 같은 기능을 위해 사용하고,

ecr.dkr은 Docker 클라이언트와 통신하여 이미지를 푸시(push)하고 풀(pull)하는 데 사용된다.

이렇게 하나의 서비스에서도 종류별로 다르게 제공되다 보니, 비용적으로는 ECR 연결이 부담될 수 있을 것 같다.

참조글

https://iwanhae.tistory.com/3

원리부터 파악하는 컨테이너 이미지 PULL (w/ curl)

시작 전 잡담 - 1 본래 프로젝트 라이프사이클 관점에서의 개발 방법론에 대한 글을 쓰고 싶었지만 현재 진행하고 있는 강의에 대한 홍보글 겸 겸사겸사 적어본다. (많은 관심 부탁드립니다~~) 이

iwanhae.tistory.com

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/privatelink-interface-endpoints.html

Amazon S3용 AWS PrivateLink - Amazon Simple Storage Service

액세스되는 리소스의 AWS 계정 ID를 지정하려면 IAM 정책에서 aws:ResourceAccount 또는 s3:ResourceAccount 키를 사용하면 됩니다. 그러나 일부 AWS 서비스는 AWS 관리형 버킷에 대한 액세스에 의존합니다. 따

docs.aws.amazon.com

[EC2 Ubuntu] AWS PHP SDK 세팅 및 DynamoDB 테스트

EVEerNew — Mon, 20 May 2024 22:46:15 +0900

ubuntu EC2에 apache2와 php를 설치 후, AWS PHP SDK를 세팅해 보자.

sudo su

apt-get update

apt-get install apache2 -y

apt-get install php -y
apt-get install p7zip -y

(현재 최신버전인 php 8.1이 설치됨)

작업 폴더를 이동시키고 진행해 주자.

cd /var/www/html

PHP 의존성 관리 도구인 Composer 설치설치하자.

https://getcomposer.org/download/

Composer

Download Composer Latest: v2.7.6 To quickly install Composer in the current directory, run the following script in your terminal. To automate the installation, use the guide on installing Composer programmatically. php -r "copy('https://getcomposer.org/ins

getcomposer.org

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

php -r "if (hash_file('sha384', 'composer-setup.php') === 'dac665fdc30fdd8ec78b38b9800061b4150413ff2e3b6f88543c636f7cd84f6db9189d43a81e5503cda447da73c7e5b6') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

php composer-setup.php

php -r "unlink('composer-setup.php');"

sudo mv /var/www/html/composer.phar /usr/bin/composer

composer require aws/aws-sdk-php

이렇게 해주어야 /var/www/html 경로에 aws-sdk-php가 설치되어 php 파일들이 이를 참조해 사용할 수 있다.

접속 테스트

ec2의 public ip로 접근해 보자.

touch /var/www/html/test.php

nano /var/www/html/test.php

<?php phpinfo(); ?>

service apache2 restart

php도 정상동작 하고 있다.

DyanmoDB에서 데이터 읽어오기

보안그룹에서 추가적으로 https inbound를 추가해 주자.

이제 이 EC2가 DynamoDB에 접근할 수 있도록 IAM Role을 만들어 주자.

만들어준 역할을 Ec2에 연결한다.

DynamoDB 테이블 세팅

간단히 데이터를 넣어주었다.

테이블 검색 php 코드

<?php
    require 'vendor/autoload.php';  # 설치한 sdk의 사용
    use Aws\DynamoDb\DynamoDbClient;
    
    $dynamodb = new DynamoDbClient([
        'region'  => 'ap-northeast-1',
        'version' => 'latest',
        #'profile' => 'default'  # profile 세팅이 있으면 aws/credential 확인
    ]);
    
    $Table_name = 'user_table';
    $result = $dynamodb->getItem([
        'TableName' =>  $Table_name,
        'Key' => [
            'id' => ['S' => "찾을id"],
        ],
    ]);
?>

해당 코드를 db.php에 세팅하여 실행해 보았다.

ec2에 연결된 권한이 있더라도 credentials을 요구하는 오류가 발생하고 있다.

에러가 난 코드를 확인해 보니 credentials의 확인하는 순서가 적혀있었다.

* Create a default credential provider that first checks for environment

     * variables, then checks for the "default" profile in ~/.aws/credentials,

     * then checks for "profile default" profile in ~/.aws/config (which is

     * the default profile of AWS CLI), then tries to make a GET Request to

     * fetch credentials if Ecs environment variable is presented, and finally

     * checks for EC2 instance profile credentials.

즉, EC2의 instance profile의 credentials가장 마지막에 확인된다.

하지만 어째서인지 instance profile이 제대로 인식이 되지 않는 듯하다.

간단히 해결하고 싶다면 iam user의 key값을 aws/credential에 등록해 주면 되지만, 키가 생성되는 순간 유출될 위험을 동반하기 때문에 EC2의 instance profile로 해결해야 안전하다.

instance profile을 직접 로드해 오는 방식으로 변경해 주었다.

use Aws\Credentials\CredentialProvider;
use Aws\DynamoDb\DynamoDbClien

$provider = CredentialProvider::instanceProfile();   //instanceProfile 직접 로드
$memoizedProvider = CredentialProvider::memoize($provider);

$dynamodb = new DynamoDbClient([
        'region'  => 'ap-northeast-1',
    'version' => 'latest',
    'credentials' => $memoizedProvider
]);

이번에는 오류가 $instance 정보를 불러올 수 없다는 것으로 변경되었다.

여러 세팅을 확인해 본 결과 ec2의 메타데이터를 확인할 수 있는 169.254.169.254로의 질의에 권한이 없었다.

이 문제는 테스트 인스턴스를 생성할 때 메타데이터 버전을 세팅하지 않았기 때문이다.

따라서 직접 curl로 질의해보아도 권한이 거부된다.

IMDS v2를 필수로 선택되어 있다면, get요청 전에 Token을 발급받는 보안 방식을 추가적으로 진행해야 한다. Php SDK가 그 부분까지는 진행해 주지 않기 때문에 권한 문제로 계속 실행이 안되었던 것이다.

이 메타데이터 옵션을 바꾸어주자.

이제 curl로 정상 질의가 된다.

이제 웹 접근이 정상적으로 dynamoDB의 데이터를 가져온다.

참조

https://nowonbun.tistory.com/608

https://bosungtea9416.tistory.com/entry/AWS-EC2-Metadata-%EA%B4%80%EB%A0%A8%ED%95%98%EC%97%AC

https://stackoverflow.com/questions/25806267/need-a-complete-example-for-dynamodb-with-php

CodeDeploy ECS 블루/그린 배포 방식 살펴보기

EVEerNew — Mon, 20 May 2024 00:05:11 +0900

Code deploy의 ECS로 배포는 블루/그린 배포 방식으로 업데이트를 진행해보자.

블루 그린은 한번에 모든 트래픽을 새로운 서버자원으로 이동시키는 무중단 배포 방식이다.

이때 하나의 로드밸런서에서 두 개의 리스너와 대상 그룹을 요구한다.

그 이유를 배포 방식을 통해 알아보자.

배포 원리

배포 이벤트의 순서는 아래와 같다.

install전에는 서비스 중인 Production Listener의 대상 그룹을 Test Listener도 가리키고 있다.

여기서 install 이벤트가 실행되면, 다른 Target group에 업데이트된 task들이 배포된다.

위의 이벤트 소요시간을 확인해보면, 컨테이너를 올리는 작업 및 상태 체크 때문에 다른 이벤트보다 시간이 많이 소요된다.

AllowTestTraffic 이벤트에서는 Test linstener가 새로운 대상 그룹을 가리키게 된다.

AllowTraffic에서는 Production Listener가 새로운 대상 그룹으로 트래픽을 보내게 되면서, 실제 서비스가 진행된다.

time out이 지나거나 이후 기존의 Task를 지우는 작업을 승인하면 최종적으로 아래와 같이 배포가 완료된다.

실제로 배포를 확인해보면 기존의 task들을 종료시킬지 승인해줄 수 있다.

이때 배포 중지하고 롤백과 을 선택할 수도 있다.

다시 업데이트 내역의 배포를 진행하면 역으로 대상 그룹 1에서 새로운 task가 생성되는 방식으로 진행된다.

이때 각각의 이벤트에 람다 함수를 연결하여 알림을 전송하는 등의 커스텀도 할 수 있다.

장점

배포가 완료되어 기존의 task를 지우기까지는 바로 롤백이 가능하므로, 새로운 컨테이너에 문제 발생 시 즉각적인 대처가 가능하며 가장 빠르게 무중단 배포를 할 수 있는 방법이다.

특히 온프레미스 방식에서는 가용할 수 있는 서버 자원의 한계 때문에 블루/그린 배포가 어려웠지만, 클라우드에서는 온디멘드로 자원을 사용할 수 있기 때문에 적용가능한 업데이트 방식이기도 하다.

이외의 배포 전략은 아래를 참조하자.

https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html#deployment-configuration-ecs

Working with deployment configurations in CodeDeploy - AWS CodeDeploy

If you're deploying to instances in multiple Auto Scaling groups, CodeDeploy will deploy to up to half of the instances at a time regardless of the Auto Scaling group they're in. For example, let's assume you have two Auto Scaling groups, ASG1 and ASG2, ea

docs.aws.amazon.com

참조

https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps-ecs.html

Deployments on an Amazon ECS Compute Platform - AWS CodeDeploy

Managing Amazon ECS blue/green deployments with AWS CloudFormation is not available in the Asia Pacific (Osaka) region.

docs.aws.amazon.com

AWS Elastic cache Memcached의 노드간 복제 여부 확인

EVEerNew — Tue, 7 May 2024 21:36:15 +0900

고가용성을 가진 웹서비스 인프라를 만들어보는 중에 Elastic cache를 활용해서 세션 쿠키를 캐싱할 계획이었다.

WAS에 Elastic Cache 사용

Memcached를 선택한 이유는 단순히 세션 쿠키를 저장하고 읽는 것이라면,

단순한 기능을 제공하는 대신 빠른 성능을 보이는 Memcached가 redis보다 좋다고 판단했다.

고가용성을 보장하려면, 두 개 이상의 노드가 동작해야 하기 때문에 memcached 노드를 두 개를 다른 AZ에 배치하였다.

두 개의 노드를 생성함

클러스터라면 노드 간의 동기화가 당연하게 일어날 줄 알았지만,

하나의 노드에서 key 저장 후, 다른 노드에서 키를 확인해 보니 서로 데이터는 독립적으로 처리하는 것이 확인되었다.

데이터 저장

노드마다 저장 정보가 다르다

이처럼 AWS Memcached은 노드 간의 동기화가 제공되지 않는 것이 확인된다.

그럼에도 Memcached 클러스터를 사용할 수 있는 이유는 클라이언트의 정보를 해싱해서 항상 같은 노드로 연결해 주기 때문이다. 이를 통해서 로드 밸런싱을 제공할 수도 있다.

하지만 WAS의 세션 저장 용으로 사용하기에는 치명적인 문제이다.

우리는 로드 밸런싱을 통해 유저가 항상 다른 WAS로 연결될 수 있다.

WAS마다 정해진 Memcached로만 연결된다면, 세션이 연결 끊어지게 된다.

이처럼 가용성을 위해 두 개 이상의 노드를 사용하고 싶다면, 특별한 세팅 혹은 Memcachier나 Redis의 복제기능을 활용해야 할 것이다.

[AWS] Private subnet 자원 접근 시, ELB과 NAT GateWay의 Flow 확인하기

EVEerNew — Fri, 19 Apr 2024 19:45:41 +0900

AWS에서 웹서비스를 생성하던 중에, 의문점이 생겨서 ELB와 NAT GW에 대해 확실히 알게 된 점을 남겨본다.

AWS 공부를 하면 private subnet의 자원들은 외부의 트래픽을 NAT GateWay로 보낸다고 알게 된다.

그러면 ELB를 사용해서 private subnet의 웹 서버에 접속하면 다음과 같은 Flow가 된다고 생각했다.

클라이언트는 ELB의 IP로 요청을 보내고, 이 요청이 EC2 web server에게 전달된다.

여기서 웹 서버가 NAT GW로 응답을 보내면, 결국에 클라이언트의 웹 요청에 대한 응답이 NAT의 public IP로 바뀌어서 나가게 된다.

그렇다면, 클라이언트는 요청을 보낸 IP(ELB IP)와 다른 IP(NAT IP)로부터 응답을 받게 된다.

브라우저가 다른 ip에서 오는 응답을 어떻게 인식하고 수신할 수 있을까?

정말 NAT의 IP로 응답이 오는 것인지 확인하기 위해 ELB의 IP를 확인하고, 웹 요청을 보내서 패킷을 확인해 보았다.

nlb의 ip 확인

웹 요청에 대한 응답

확인해 보면, NLB의 IP로 요청을 보내고 NLB의 IP로 응답을 받는다.

즉, private subnet의 자원에 대한 접근 Flow는 다음과 같다.

private subnet의 자원에대한 접근 Flow

요청의 경우에는 Source IP가 ELB에서 ELB의 private IP로 바뀌게 된다.

따라서 EC2는 public ip가 아닌 ELB의 private IP로부터 요청이 온 것으로 이해하고, 응답을 ELB에게 주게 된다.

여기서 EC2는 VPC의 네트워크 대역대가 아닌 경우에만 NAT GW로 트래픽을 보내기 때문에, NAT가 사용될 일은 없다.

만약 web server가 업데이트와 같이 인터넷으로부터 데이터를 요청해야 한다면, public ip에 대해서 요청을 보내야 한다.

이때는 routing table에 의해 NAT GW로 요청을 전달한다.