Cloud & Infra Tech Blog

AWS Summit SEOUL 2026 후기

minseoki — Thu, 21 May 2026 00:18:19 +0900

AWS Summit SEOUL 2026을 다녀왔다.

요즘 관심을 가지고 있던 주제가 마이그레이션, 운영, 그리고 AWS의 생성형 AI 서비스인 Bedrock이었던 만큼, 이번 Summit에서는 해당 내용을 다루는 세션들을 위주로 듣고 오자는 목표를 가지고 참여했다.

이번에 들었던 세션은 다음과 같다.

Amazon Bedrock Knowledge Base와 S3 Vectors로 스트리밍 AI 챗봇 구축하기
VMware 종속을 넘어 자율로, 삼성SDS와 함께하는 AX 전략
2천만 디바이스 요청을 처리하는 API Gateway 마이그레이션 생존기 (LG U+)

Amazon Bedrock Knowledge Base와 S3 Vectors로 스트리밍 AI 챗봇 구축하기..

가장 인상 깊었던 세션은 첫 번째 세션이었다.

현재 진행 중인 팀 프로젝트와도 방향성이 맞닿아 있었기 때문에 개인적으로 가장 많은 인사이트를 얻을 수 있었던 시간이었다.

세션에서는 Bedrock Knowledge Base와 S3 Vectors를 활용해 도서 기반 AI 챗봇을 구축한 사례를 소개했다.
단순히 “챗봇을 만들었다” 수준의 발표가 아니라, 실제 서비스 관점에서 어떤 고민과 선택이 있었는지를 상세하게 다뤘다는 점이 특히 좋았다.

발표에서는 다음과 같은 내용들을 단계별로 설명했다.

소비자 요구사항 분석
Bedrock Knowledge Base의 동작 방식
문장 단위 분할(Chunking)
벡터 변환(Embedding)
기본 청킹(Default Chunking)에서 시맨틱 청킹(Semantic Chunking)으로 개선한 과정

특히 RAG(Retrieval-Augmented Generation)를 실제로 운영 환경에 적용하면서 발생했던 문제들과 그 해결 과정이 굉장히 인상 깊었다.

PoC 단계에서 비용을 고려한 모델 선택 전략, 토큰 사용량 최적화, Guardrail을 통한 제약 설정, 데이터 트래킹 등 단순 기능 구현을 넘어 “서비스 운영” 관점에서 어떤 요소들을 고려해야 하는지까지 다루며 발표가 진행되었다.

무엇보다 좋았던 점은 발표자분이 직접 겪었던 트러블슈팅 경험들을 솔직하게 공유해주셨다는 부분이었다.

Bedrock을 처음 접하거나 실제 프로젝트에 적용해보는 과정에서 충분히 마주칠 수 있는 문제들이 많았고, 현재 진행 중인 프로젝트에서도 충분히 참고할 수 있을 만한 좋은 레퍼런스가 될 것 같다는 생각이 들었다.

VMware 종속을 넘어 자율로, 삼성SDS와 함께하는 AX 전략..

이어서 들었던 삼성SDS 세션 역시 굉장히 흥미로웠다.

세션에서는 Nutanix와 AWS 서비스를 활용해 VMware 환경에서 어떻게 전환(Migration)을 진행했는지 실제 사례 중심으로 설명했다.

단순히 “클라우드로 옮긴다” 수준이 아니라,
왜 전환을 결정했는지, 어떤 구조로 운영했는지, 운영 과정에서 어떤 문제를 겪었는지까지 실제 현업 관점에서 다뤘다는 점이 인상적이었다.

2천만 디바이스 요청을 처리하는 API Gateway 마이그레이션 생존기 (LG U+)..

마지막으로 들었던 LG U+ 세션도 굉장히 재미있게 들었다.

대규모 트래픽 환경에서 API Gateway를 어떻게 마이그레이션했고, 실제 운영 과정에서 어떤 문제를 해결했는지를 중심으로 발표가 진행되었다.

특히 기억에 남았던 부분은 다양한 모델 테스트를 통해 최적의 RAG 패턴을 구축해 나가는 과정이었다.

단순히 성능만 보는 것이 아니라 비용 효율성과 운영 안정성까지 고려하며 최적의 구조를 찾아가는 과정이 인상 깊었다.

또한 “최저 비용으로 운영 혁신을 달성한다”는 관점에서 접근한 내용들이 실제 서비스 운영을 고민하는 입장에서 굉장히 현실적으로 다가왔다.

이번 AWS Summit SEOUL 2026은 단순히 새로운 서비스를 소개하는 행사가 아니라,
실제 기업들이 어떤 방식으로 AWS 서비스를 운영 환경에 적용하고 있는지 생생하게 들을 수 있었던 자리였다.

특히 최근 관심을 가지고 공부하고 있던 분야인:

마이그레이션
운영 자동화
Bedrock
RAG
생성형 AI 서비스 아키텍처

등과 관련된 실제 사례들을 직접 들을 수 있어서 개인적으로 굉장히 의미 있는 시간이었다.

기술 자체도 중요하지만, 결국 실제 서비스에서는 비용, 운영 안정성, 장애 대응, 트래픽, 데이터 관리까지 모두 함께 고려해야 한다는 점을 다시 한번 느낄 수 있었던 경험이었다.

현재 진행 중인 프로젝트에서도 이번 Summit에서 들었던 내용들을 많이 참고하게 될 것 같다.

[Kubernetes] Pod, 리소스, Ingress 정리

minseoki — Sun, 10 May 2026 18:03:00 +0900

Pod란?

한 개 이상의 컨테이너로 구성된 쿠버네티스의 기본 단위
같은 Pod면 IP가 같다
같은 Pod 내 컨테이너들은 포트로 구분한다

Pod도 결국 컨테이너로 구성되어 있으며, 이 컨테이너를 실행하기 위해 docker, containerd, CRI-O 같은 CRI(컨테이너 런타임)가 필요하다.

1. kube-apiserver

내/외부의 모든 요청을 주고받는 서버. contoller나 scheduler,proxy의 주시대상.
호텔지배인.

2. kube-scheduler

생성될 리소스들을 어떤 노드에 '배치'할지 결정(스케쥴링)
호텔 로비 직원

3. kube-controller

다양한 리소스에 대한 여러가지 컨트롤러들이 존재한다.
원하는 상태(Desired state)에 현재 상태(current state)가 수렴하도록 지속적으로 모니터링. 문제가 생기면 고치거나 리소스를 재생성.

ex) 하우스키퍼

4. etcd

클러스터 및 모든 리소스에 대한 정보를 key:value 형태로 저장하는 일종의 데이터베이스.

ex) 장부

모든 노드에 존재하는 컴포넌트

1. kubelet

노드 관리자. 실질적으로 각 노드에 존재하는 리소스 관리

2. kube-proxy

노드 안과 밖을 넘나드는 수직트래픽을 관리.

매니페스트 (yml 파일)

매니페스트란 내가 원하는 상태를 적어둔 명세서다.

vi test-pod.yml

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: public.ecr.aws/docker/library/httpd:latest
    name: test-con

kubectl apply -f test-pod.yml

kubectl apply -f는 docker compose up, docker stack deploy와 비슷하다.
내가 원하는 상태(Desired State)가 미리 정의된 매니페스트 파일을 구성해놓고 apply해서 반영한다. 매니페스트 수정 후 다시 apply하면 바로 변경사항을 반영시킬 수 있다.

kubectl delete -f test-pod.yml

앞으로는 명령어로 직접 리소스를 생성하거나 지우지 말고 매니페스트 파일을 -f 옵션을 통해 apply하거나 delete하도록 하자.

label - 중요

vi labels.yml

apiVersion: v1
kind: Pod
metadata:
  name: test-label-pod
  labels:
    app: my-web
spec:
  containers:
  - image: public.ecr.aws/docker/library/httpd:alpine
    name: test-label-con

label은 여러 개를 쓸 수 있다.

kubectl apply -f labels.yml

생성.

kubectl describe pod test-label-pod

조회.

label은 리소스를 컨트롤(원하는 상태, 현재 상태)하고 찾아가기 위한 용도다.

쿠버네티스의 다양한 리소스들

1. pod

한 개 이상의 컨테이너로 구성된 쿠버네티스의 기본 배포 단위.

2. replicaset

Pod의 복제본 수를 유지해주는 리소스.
지정한 수만큼 Pod가 항상 실행되도록 보장한다.

3. Deployment

ReplicaSet을 관리하며 롤링 업데이트, 롤백 등을 지원하는 리소스.
실무에서 가장 많이 사용한다.

4. namespace

클러스터 내에서 리소스를 논리적으로 분리하는 단위.
팀이나 프로젝트별로 격리된 환경을 만들 수 있다.

5. Service (너무 중요!)

작은 로드밸런서라고도 할 수 있다.
Pod에 접근하기 위한 고정된 엔드포인트를 제공하는 리소스이다.
Pod는 재생성될 때마다 IP가 바뀌기 때문에 Service를 통해 안정적으로 접근한다.
서비스라는 리소스를 생성 시 하나의 접속지점이 생성된다.
이 서비스를 통해 모든 노드에 존재하는 pod에 트래픽을 인가할 수 있다.
인가하는 기준은 labels 를 통해 해당 pod를 특정하면 된다.

서비스는 다양한 종류(type)이 존재한다.

5-1. ClusterIP 타입 (svc의 default 타입)

클러스터 내부에서만 유효한 IP
내부 테스트 용도, 외부로 배포를 안하는 경우. 내부에 존재하는 서비스들끼리만 통신할 때.

vi dep.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-dep
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-web
  template:
    metadata:
      labels:
        app: my-web
    spec:
      containers:
      - image: public.ecr.aws/docker/library/httpd:alpine
        name: my-web-con

kubectl apply -f dep.yml

svc를 연결할 deployment 생성.

vi dep-svc.yml

서비스 매니페스트 정의.

apiVersion: v1
kind: Service
metadata:
  name: svc-myweb
spec:
  selector:
    app: my-web
  ports:
  - port: 80
    targetPort: 80

kubectl apply -f dep-svc.yml

svc 생성.

kubectl describe svc svc-myweb

자세한 정보 확인.

Endpoint에 뜨는 pod들은 건강한 pod만 뜬다.

5-2. NodePort 타입

노드의 포트
서비스를 제공받는 사용자 입장에서 내부로 진입하여 pod에 접근하려면 노드 포트로 진입해야 한다.

mkdir svc
cd svc
vi svc-nodeport.yml

apiVersion: v1
kind: Service
metadata:
  name: svc-dep
spec:
  selector:
    app: mydep
  type: NodePort
  ports:
  - nodePort: 30001
    port: 80
    targetPort: 80

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mydep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mydep
  template:
    metadata:
      labels:
        app: mydep
    spec:
      containers:
      - image: public.ecr.aws/docker/library/httpd:alpine
        name: dep-con

kubectl apply -f svc-nodeport.yml

kubectl describe svc svc-dep

3개의 포트(NodePort, Port, TargetPort)가 각각 어떤 대상인지 구분할 수 있어야 한다.

Port - 서비스 포트
TargetPort - pod
NodePort - Node

외부에서 노드로 통신만 된다면 노드 포트를 통해 pod로 접속 가능하다.

어떤 노드로 들어가는지는 중요하지 않고, NodePort로 접근하면 동일한 공간(오버레이 네트워크가 구성된 pod-network)으로 들어간다는 사실을 인지하자.

pod가 어떤 노드에 존재하는지는 신경 쓸 필요도 없고 중요하지도 않다.
pod가 worker1에 띄워져 있어도 worker2의 노드 포트를 통해 접근 가능하다.

5-3. LoadBalancer 타입

클러스터 관리자의 도움이 필요한 서비스 타입.

쿠버네티스 외부 네트워크 대역의 IP를 자동으로 할당하고 관리해 주는 사설 로드밸런서 관리자가 MetalLB다.

EKS 같은 쿠버네티스 클러스터의 경우 클라우드 서비스 제공자(AWS)가 LB를 제공해줄 수 있지만, 온프레미스에 구성한 클러스터는 그렇지 않다. 따라서 svc를 LoadBalancer 타입으로 만들었을 때 누군가는 LB를 생성하면서 노드 대역대의 IP를 할당해줘야 한다. 그 기능을 활성화하기 위해 MetalLB가 필요하다.

vi config-metal.yml

LB가 생성됐을 때 뿌려줄 IP 범위 설정.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 211.183.3.200-211.183.3.240  # 안겹치게 수정. LB가 부여받을 IP 범위
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system

kubectl apply -f config-metal.yml
vi lb-tom.yml

apiVersion: v1
kind: Service
metadata:
  name: svc-tom
spec:
  selector:
    app: tom
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dep-tom
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tom
  template:
    metadata:
      labels:
        app: tom
    spec:
      containers:
      - image: public.ecr.aws/docker/library/tomcat:10.1.40-jre11
        name: tom-con

svc의 타입으로 LoadBalancer 타입을 지정해준다. nodePort는 삭제한다.

kubectl apply -f lb-tom.yml

생성된 LB는 svc의 포트를 따라간다.

Ingress (제일 중요!)

path 기반 라우팅 (/board로 가면 board 앱으로, /login으로 가면 login 앱으로)
일반적인 svc는 path 기반 라우팅이 불가능하다. (LoadBalancer, NodePort, ClusterIP)

서비스는 한 종류의 라벨만 품을 수 있기 때문에 이런 한계가 발생한다. 합칠 수 없다 = 같은 주소가 될 수 없다.

여러 개의 컨테이너에 각 기능들을 구현하면 path로 라우팅이 가능해야 한다. 일반적인 svc는 path 기반 라우팅이 불가능하기 때문에 Ingress라는 리소스가 필요하다.

Ingress를 구성하면 path 기반 라우팅이 가능하다.

ex) www.naver.com/board 로 오면 svc-board라는 svc로 보내줘.
ex) www.naver.com/login 으로 오면 svc-login이라는 svc로 보내줘.
→ 하나의 접속지점(www.naver.com)을 통해 여러 개의 svc를 구성할 수 있다.

Ingress를 구성하기 위해서는 Ingress Controller가 필요하다.
(AWS EKS에서는 Ingress Controller를 LoadBalancer Controller라고 부른다.)

Ingress Controller 설치

vi deploy.yaml

필요한 부분 수정.
(type 을 NodePort에서 LoadBalancer로 수정한다.)

kubectl apply -f deploy.yaml
kubectl get svc -n ingress-nginx

Ingress 매니페스트 작성

cp ../svc/ip.yml .
vi ip.yml

apiVersion: v1
kind: Service
metadata:
  name: svc-ipnginx
spec:
  selector:
    app: myipnginx
  ports:
  - port: 80
    targetPort: 80

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ip-dep
spec:
  replicas: 2
  selector:
    matchLabels:
      app: myipnginx
  template:
    metadata:
      labels:
        app: myipnginx
    spec:
      containers:
      - image: public.ecr.aws/docker/library/httpd:alpine
        name: ip-con

kubectl apply -f ip.yml
kubectl describe svc svc-ipnginx

서비스가 정상인지 확인.

vi ing-ip.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ing-ip
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: "nginx"
  rules:
    - host: rapa.com
      http:
        paths:
        - path: /httpd
          pathType: Prefix
          backend:
            service:
              name: svc-ipnginx
              port:
                number: 80

annotation : 추가적인 정보. labels와 비슷하지만 주로 부가적인 기능 명시.
ingressClassName : ingress-controller의 종류 중에 nginx 방식을 사용.
rewrite-target: / → 비록 /httpd라는 경로로 들어왔더라도 실제 pod에서는 /라는 경로로 바꿔주는 기능.
host : 영문주소. IP는 안됨. DNS 기능이 필요하다. 인증서가 있다면 https 통신도 가능하다.
path : 한 종류의 앱. pathType: Prefix → /httpd로 접근하는 애들 전부.
서비스의 이름을 마치 주소처럼 사용하고 있다.

kubectl apply -f ing-ip.yml

ingress를 describe 했을 때 endpoint들(pod들)이 잘 떠있는 것만 봐도 ingress-svc-pod가 잘 연결되어 있는 걸 어느정도 확인할 수 있다.

원래는 DNS를 통해서 rapa.com에 해당하는 IP를 매핑시켜줘야 하지만, 미니 DNS인 /etc/hosts 파일을 사용하자.

vi /etc/hosts

Ingress 트래픽 흐름

쿠버네티스에서 외부 사용자가 도메인 이름(rapa.com)을 치고 들어와서 실제 앱(pod)까지 도달하는 ingress 트래픽 흐름.

rapa.com → ingress-controller의 svc External-IP(DNS) → ingress(path 기반 라우팅) → svc → pod

Docker Swarm 에 대해서...

minseoki — Tue, 5 May 2026 17:09:18 +0900

[Docker] Docker Swarm 정리

Docker를 사용하다 보면 단일 서버만으로는 한계가 생긴다. 트래픽이 몰리거나 서버가 죽었을 때 대응이 안 되기 때문이다. 이런 문제를 해결하기 위해 나온 게 바로 Docker Swarm이다.

Docker vs Docker Compose vs Docker Swarm

Docker — 단일 호스트, 단일 컨테이너
Docker Compose — 단일 호스트, 여러 종류의 컨테이너
Docker Swarm — 다수의 호스트(manager + workers)에 여러 종류의 컨테이너

여러 개의 호스트 묶음을 "클러스터" 라고 한다.
docker swarm은 도커에서 만든 컨테이너 오케스트레이션 툴이다.

오케스트레이션이란?

오케스트레이션은 다수의 호스트로 구성된 클러스터에서 다수의 컨테이너를 관리하는 기술이다. (스케일링, 헬스체크, 로드밸런서(트래픽제어))

혼자서 악기 하나를 연주하는 건 쉽지만, 수십 명의 연주자가 합주를 하려면 지휘자가 필요하다.

docker swarm은 그 지휘 역할을 하는 것이다.

클러스터링 : 여러 대의 물리 서버를 하나의 가상 리소스로 통합한다.
스케일링 : 명령 한 줄로 컨테이너 개수를 수십 개로 늘리거나 줄인다.
상태 관리(Self-healing) : 어떤 서버가 죽어서 컨테이너가 꺼지면 살아있는 다른 서버에 자동으로 그 컨테이너를 다시 살려낸다.
로드밸런싱(트래픽제어) : 들어오는 요청을 여러 서버에 떠 있는 컨테이너들에게 골고루 분산한다.

docker swarm 클러스터 구성

실습에서 사용한 클러스터 구성은 아래와 같다.

manager : 211.183.3.100
worker1 : 211.183.3.110
worker2 : 211.183.3.120

manager node 구성

manager 노드는 control plane 역할을 한다. manager에서 아래 명령으로 swarm을 초기화한다.

docker swarm init

초기화 후 출력되는 join 토큰을 파일로 저장해두자.

vi token

manager 노드와 worker1,2 노드가 연결이 되었다.

docker service

다수의 호스트에 한 가지 종류의 컨테이너를 한 개 이상 생성한다. docker run으로 컨테이너를 생성하는 것과 비슷한 개념이다.

docker service create --replicas 2 -p 5858:80 --name myweb oolralra/ipnginx

--replicas : 복제본, 컨테이너를 두 개 띄우겠다는 의미.

ipnginx : 자신(컨테이너)의 IP를 출력하는 이미지.

로드밸런싱이 잘 되고 있다.

docker service ps myweb

따로 컨테이너 배치 제한을 두지 않았기 때문에 현재 총 3개의 노드 중 아무 곳에 배치되었을 것이다.

docker network inspect ingress

docker swarm을 구성하는 순간, 오버레이 네트워크도 함께 구성된다.
오버레이 네트워크에 의해 다른 호스트에 있는 컨테이너들끼리도 서로 통신이 가능하다.

만든 web1과 web2 컨테이너를 하나로 묶어주는, 눈에는 보이지 않는 접속 포인트가 생긴다. (LB와 유사)

docker stack deploy

docker compose와 비슷하다. 컴포즈 파일이 필요하다.
기존의 컴포즈 파일과 거의 문법이 흡사하지만 조금 다른 부분이 있다.

스택이란 여러 종류의 서비스의 묶음이라고 생각하면 된다.

mkdir /swarm
cd /swarm
vi docker-compose.yml

services:
  ip-nginx:
    image: oolralra/ipnginx
    deploy:
      replicas: 2
      placement:
        constraints: [node.role != manager]

노드의 역할이 manager인 경우는 배치하지 않겠다. 워커노드에만 컨테이너를 배치하겠다.

docker stack deploy -c docker-compose.yml ip-stack

docker stack rm ip-stack

스택 삭제 명령어.

visualizer — 컨테이너 시각화

각 호스트의 컨테이너를 시각화하는 컨테이너 이미지 = visualizer

vi visual.yml

services:
  visual:
    image: 61.254.18.30:5000/visualizer
    ports:
    - '5656:8080'
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    deploy:
      placement:
        constraints: [node.role == manager]

docker stack deploy -c visual.yml vis

insecure 설정이 안 되어있으면 해주자.

vi /etc/docker/daemon.json

{
        "insecure-registries": ["211.183.3.100:5000","61.254.18.30:5000"]
}

systemctl restart docker

211.183.3.100:5656으로 접속.

실습 1 — 사설 저장소에서 이미지 가져오기

61.254.18.30:5000/ipnginx:latest 이미지로 컴포즈 파일을 수정해서 replicas 4개로 5959 포트로 publish 해보자.

저장소 수정 후 insecure 설정도 바꿔줘야 한다.

사설 저장소에 이미지가 존재함에도 불구하고 컨테이너가 띄워지지 않는다.
사설 저장소 insecure 설정이 manager 노드에만 되어있는데, 실질적으로 컨테이너 이미지를 땡겨오는 주체는 worker1과 worker2이기 때문이다.
worker1과 worker2에도 insecure 설정을 해주면 된다.

vi /etc/docker/daemon.json

{
        "insecure-registries": ["211.183.3.100:5000","61.254.18.30:5000"]
}

docker stack deploy -c docker-compose.yml pstack

실습 2 — ECR 퍼블릭 갤러리 이미지로 WordPress + MySQL 스택 배포

DB는 manager에 한 개만 띄우고, wordpress는 worker 노드에 2개를 띄워서 12345 포트로 접속 가능하게 해보자.

vi wordpress.yml

services:
  mywp:
    image: public.ecr.aws/docker/library/wordpress:php8.1-apache
    ports: 
    - '12345:80'
    deploy:
      replicas: 2
      placement:
        constraints: [node.role == worker]
    environment:
      WORDPRESS_DB_HOST: dbdb
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: '1234'
      WORDPRESS_DB_NAME: wpdb
    depends_on:
    - dbdb

  dbdb:
    image: public.ecr.aws/docker/library/mysql:8
    deploy:
      placement:
        constraints: [node.role == manager]
    environment:
    - MYSQL_ROOT_PASSWORD=1234
    - MYSQL_USER=wpuser
    - MYSQL_PASSWORD=1234
    - MYSQL_DATABASE=wpdb

잘 접속된다.

[Docker] 기본 명령어와 주요 옵션 정리

minseoki — Tue, 28 Apr 2026 16:26:05 +0900

[Docker] 기본 명령어와 주요 옵션 총정리

도커를 설치하고 나서 가장 먼저 마주치는 것들 — 컨테이너를 어떻게 만들고, 어떻게 관리하는지에 대한 기본 명령어와 자주 쓰는 옵션들을 정리해봤다.

Docker 설치

curl -fsSL https://get.docker.com -o get-docker.sh

도커 공식 홈페이지에서 설치 스크립트를 다운로드한다. 환경에 맞춰서 자동으로 설치해준다.

chmod +x get-docker.sh

+x : 실행 권한 추가

설치 후 ip a 명령으로 docker0 브릿지 IP가 올라와 있는지 확인한다.

IP가 올라와 있다 = 정상적인 상태
IP가 사라진 경우 = 비정상적인 상태 (컨테이너가 통신이 안됨)

비정상 상태라면 아래 명령으로 도커를 재시작하면 된다.

systemctl restart docker

도커 재시작 자동화 스크립트

IP가 사라졌을 때 자동으로 도커를 재시작하는 스크립트를 만들어두면 편하다.

tee /root/check_ip_and_restart_docker.sh<<EOF
#!/bin/bash

if ! ip add | grep -q 172.17; then
    systemctl restart docker
fi
EOF

chmod +x check_ip_and_restart_docker.sh

crontab -e

* * * * * /root/check_ip_and_restart_docker.sh

매분마다 스크립트를 실행하도록 크론탭에 등록한다.

systemctl enable docker

서버 재부팅 시에도 도커가 자동으로 시작되도록 설정.

우분투 IP 설정

vi /etc/netplan/50-cloud-init.yaml

우분투의 IP 설정 파일. IP를 211.183.3.100으로 수정한다.

netplan apply

변경사항 반영. systemctl restart network 와 같은 개념이다.

docker 기본 명령어

docker run

컨테이너를 생성하고 실행하는 명령어.
docker start, docker restart, docker stop 등과 함께 컨테이너 라이프사이클을 관리한다.

docker run nginx

nginx 이미지로 컨테이너를 run(생성 + 동작) 시키는 명령어.

컨테이너 이미지는 여러 개의 layer로 구성되어 있다.

ex) A 이미지 = 1+2+3, B 이미지 = 1+2+5 라면,
A 이미지를 갖고 있는 상태에서 B 이미지를 새로 구성할 때 5라는 레이어만 새로 받고, 1+2는 재활용한다.

AWS에서 AMI로 인스턴스를 만들어도 AMI 자체는 변하지 않는 것처럼, 컨테이너 이미지로 여러 개의 컨테이너를 만들어도 이미지 자체는 변하지 않는다.

docker ps

동작 중인 컨테이너를 조회한다. 컨테이너 ID나 이름으로 특정할 수 있다.

docker run 을 하면 컨테이너가 생성된다. --name 옵션으로 이름을 지정하지 않으면 angry_maxwell 같은 랜덤한 이름이 부여된다.

컨테이너 이미지 태그(tag)의 디폴트 값은 latest다. 태그를 명시하지 않으면 자동으로 latest로 설정된다.

옵션 없이 docker run을 하면 컨테이너 내부로 진입한다.
컨테이너가 잘 동작하려면 반드시 내부에서 foreground 상태인 프로세스가 존재해야 한다.

컨테이너 종류마다 foreground로 동작시키는 명령이 다르다.

자바 컨테이너 : java -jar app.jar
파이썬 컨테이너 : python manage.py runserver
nginx 컨테이너 : nginx -g "daemon off;"

모든 컨테이너 조회 : -a 옵션

컨테이너를 중지하면 docker ps 목록에서 사라진다.

docker ps -a

중지된 컨테이너까지 포함해서 모든 컨테이너를 볼 수 있다.

docker restart <컨테이너명>

중지된 컨테이너를 재시작할 수 있다.

컨테이너에서 나가기

Ctrl + PQ

조용히 나가기
foreground 유지

Ctrl + PQ 로 빠져나와도 컨테이너가 잘 동작 중이다.
-it 옵션을 통해 상호작용을 함으로써 컨테이너가 잘 동작할 수 있다.

Ctrl + d

강제로 나가기
때에 따라서 컨테이너가 중지될 수도 있다.

Ctrl + d 로 빠져나오면 pid = 1 인 프로세스가 중지되기 때문에 컨테이너도 중지된다.

처음에 bash로 직접 컨테이너를 만든 주인(PID 1)이라면 Ctrl + d 로 나가는 순간 주인이 죽어 컨테이너도 함께 종료된다.
그러나 이미 돌아가는 서버에 exec로 나중에 들어간 손님이라면 Ctrl + d 로 나가도 주인(서버 프로세스)이 살아있어 컨테이너는 계속 유지된다.

모든 컨테이너 한 번에 삭제

docker rm -f $(docker ps -qa)

컨테이너의 ID를 변수로 받아와서 삭제한다. (컨테이너 전부 삭제)

docker rm

컨테이너를 삭제한다.

docker rm -f <컨테이너명>

동작 중인 컨테이너는 기본적으로 삭제가 안 되기 때문에 -f 옵션으로 강제 삭제한다.

--name

docker run 시 컨테이너의 이름을 직접 지정할 수 있다.

docker run --name mycon nginx

포어그라운드로 동작 중인 컨테이너에서 Ctrl + C 로 빠져나오면 포어그라운드 프로세스가 중지되면서 컨테이너도 함께 중지된다.

이미지 이름 오른쪽에 컨테이너 실행 시 수행할 command를 명시할 수 있다.

docker run --name mycon nginx /bin/bash

/bin/bash 명령으로는 특정 프로세스가 포어그라운드로 실행되지 않기 때문에 컨테이너는 바로 중지 상태가 된다.

docker run centos:7 sleep 60

sleep 60 이 바로 커맨드다. "컨테이너가 생기자마자 60초 동안 자라"는 명령을 수행한다. 60초가 지나면 업무가 끝났으므로 컨테이너는 종료된다.

도커 컨테이너는 운영체제 전체를 띄우는 게 아니라 딱 하나의 프로세스를 실행하기 위해 만들어진다.
command의 가장 큰 목적은 특정 프로세스를 foreground로 동작시켜 컨테이너 상태(state=up)를 유지하는 것이다.

docker inspect / docker exec

docker inspect ntest

ntest 컨테이너의 자세한 정보를 확인하는 명령. IP 값을 확인한 후 curl을 찍어 nginx가 잘 동작하는지 확인할 수 있다.

docker exec -it ntest bash

-it 옵션 : 실행 중인 컨테이너 안으로 접속한다.

주요 옵션

volume (-v) 매우 중요

컨테이너와 호스트를 마운트하는 개념.

mkdir /shared

마운트할 호스트 디렉토리 생성.

docker run -d --name con -v /shared:/remote nginx:latest

/shared(호스트) 와 /remote(컨테이너) 를 마운트한 컨테이너 생성.

echo vol-test > /shared/test.txt

호스트에 테스트 파일 생성.

docker exec con cat /remote/test.txt

컨테이너 내부에서 마운트된 파일 내용을 확인한다. 컨테이너를 삭제해도 호스트에는 파일이 남는다.

호스트와 컨테이너 양쪽에 파일이 있으면 어떻게 될까?

docker run -d --name vol nginx:latest
docker exec -it vol bash

nginx 컨테이너 내부의 /usr/share/nginx/html 경로에는 기본 파일들이 존재한다.

docker run -d --name vol -v /shared:/usr/share/nginx/html nginx:latest

기존에 파일이 존재하는 디렉토리를 마운트 포인트로 지정하면,
호스트의 파일이 우선순위가 더 높다. 컨테이너에 있던 기존 파일은 무시된다.

publish (-p) 매우 중요

컨테이너를 외부에 노출, 배포(publish)시키는 옵션.
호스트를 외부, 컨테이너를 내부로 생각했을 때 DNAT(포트포워딩) 해주는 개념과 비슷하다.

docker run -d --name pub -p 8080:80 httpd:latest

-p 8080:80 설정을 통해 호스트의 8080 포트로 들어오는 모든 신호를 해당 컨테이너의 80 포트로 전달하도록 규칙을 정해놓는다. 그래서 IP를 따로 지정하지 않아도 된다.

도커를 설치하면 호스트 컴퓨터 안에 docker0 라는 가상 브릿지(Bridge)가 생긴다.
컨테이너를 실행할 때마다 도커는 이 브릿지로부터 172.17.0.x 대역의 내부 IP를 각 컨테이너에 자동으로 할당한다.
그래서 IP를 지정하지 않아도 도커가 알아서 지정해주기 때문에 충돌 없이 사용할 수 있다.

실습 예제 : 댕댕이 템플릿 퍼블리시

호스트의 /host_vol 경로에 무료 템플릿을 넣고 7979번 포트로 퍼블리시해보자.

wget -O dog.zip https://templatemo.com/download/templatemo_074_dog
unzip dog.zip
mkdir /host_vol
cp -r templatemo_074_dog/* /host_vol

docker run -d --name web -v /host_vol:/usr/local/apache2/htdocs -p 7979:80 httpd:latest

-v 와 -p 를 함께 사용해서 호스트의 파일을 컨테이너에 마운트하고 외부에 노출시킨다.

-e : 환경변수 구성

컨테이너 내부에 환경변수를 설정하는 옵션. 항상 키=값 형태로 작성한다.

docker run -d --name envcon -e ENVTEST=contest nginx:latest

docker exec -it envcon bash
echo $ENVTEST
# contest 출력

컨테이너 내부에 진입해서 실제로 환경변수가 구성됐는지 확인한다.

도커로 데이터베이스를 띄울 때 -e 옵션은 필수다.

docker run -d --name mydb mysql:8

환경변수 없이 DB 컨테이너를 생성하면 잘 동작하지 않는다.
데이터베이스 이미지들은 root 패스워드 설정이 안 되어 있기 때문에 컨테이너 생성 단계에서 환경변수로 설정해줘야 한다.

docker run -d --name mydb -e MYSQL_ROOT_PASSWORD=test123 mysql:8

환경변수로 root 암호를 설정하면 정상적으로 동작한다.

-w : 작업 디렉토리

리눅스에서 pwd 명령을 입력한 가장 큰 목적은 내가 현재 어디 경로에 있는지를 확인하고 싶어서였다.
컨테이너에서는 내가 현재 있는 경로를 고정시키기 위한 용도로 쓰인다.

/app 에 myapp.jar 파일을 두고 java -jar ./myapp.jar 명령으로 앱을 실행하려면 반드시 /app 경로에 있어야 한다.
-w 로 작업 디렉토리를 명시해두면 항상 그 경로에서 시작한다.

-w /app

docker run -d --name pwd -w /usr nginx:latest
docker exec -it pwd bash
# 접속하면 바로 /usr 경로에 위치한다

[Docker] Compose 파일 작성법과 주요 옵션 총정리

minseoki — Sun, 26 Apr 2026 21:54:05 +0900

Docker compose

도커(docker run)의 경우에는 단일 컨테이너를 실행한다.
도커 컴포즈는 여러 종류의 컨테이너를 한번에 띄울 수 있다.

ex) 도커로 3tier를 구성한다면, docker run 을 3번 해서 web-was-db 컨테이너를 각각 구성해야 하고 —link도 구성해줘야 한다. 하지만 docker compose의 경우엔 3종류의 컨테이너를 컴포즈 파일 하나에서 동시에 구성이 가능하다.

컨테이너를 띄우는 목적은 뭘까?

서비스를 제공하고 싶기 때문이다. 컨테이너 안에 앱, 애플리케이션이 들어있다. 도커 컴포즈에서는 이런 한 종류의 컨테이너를 service라고 지칭한다.

mkdir /com

cd /com

vi docker-compose.yml

docker-compose.yml 이라는 파일명 = 디폴트값

한 개의 서비스로 구성된 도커 컴포즈 파일 편집

services:
#내가 띄울 다양한 종류의 컨테이너들

  webserver:
  #서비스의 이름. 내가 원하는대로 정하면 됨.
    image: nginx
    ports:
    - '8787:80'
    #publish 기능
    networks:
    - webnet
    # 아직 만들진 않았다. 밑에서 만들예정. 놓여질 네트워크

networks:
  webnet:
  # webnet이라는 이름의 네트워크 생성.

샘플 코드.

docker compose up

잘 동작한다.

docker compose down

도커 컴포즈 삭제

docker compose up -d

docker run 과 비슷하게 -d (detach) 백그라운드로 동작할 수 있다.

볼륨 구성

호스트의 현재 디렉토리에 vtest라는 디렉토리를 구성한 후 간단한 인덱스 파일을 생성하여 컨테이너에 볼륨 구성을 통해 웹루트디렉토리에 넣어주고 싶다.

mkdir ./vtest

경로 생성.

echo compose-volume-test > vtest/index.html

인덱스 파일 생성.

vi docker-compose.yml

services:
#내가 띄울 다양한 종류의 컨테이너들

  webserver:
  #서비스의 이름. 내가 원하는대로 정하면 됨.
    image: nginx
    ports:
    - '8787:80'
    #publish 기능
    networks:
    - webnet
    # 아직 만들진 않았다. 밑에서 만들예정. 놓여질 네트워크
    volumes:
    - ./vtest:/usr/share/nginx/html
    # 호스트의 ./vtest를 컨테이너의 /usr/share/nginx/html에 마운트
networks:
  webnet:
  # webnet이라는 이름의 네트워크 생성.

docker compose up -d

마운트가 잘 되었다.

docker-compose.yml 옵션들에 대해 알아보자.

networks:

네트워크 정의 및 선택

ports:

-p, publish 옵션

volumes:

-v, 호스트와 컨테이너 마운트

command:

CMD

environment:

-e, 환경변수

depends_on:

의존성 설정(컨테이너 띄울 순서)도 가능.

ex) node.js 앱(todo, weather, chat)의 경우 몽고디비가 연동이 안되면 앱 자체가 죽어버린다. node.js 서비스를 정의하면서 몽고디비를 depends_on 으로 걸어줘야 한다.

/com의 ubun 이라는 경로에서 위 명령어를 활용하여 ubuntu:latest를 동작시키는 compose 파일을 만들어 보자.

네트워크 : ubun_net

mkdir ubun

cd ubun/

vi docker-compose.yml

services:
  ubun:
    image: ubuntu:latest
    networks:
    - ubun_net
    command: "sleep infinity"

networks:
  ubun_net:

docker compose up -d

docker compose down

environment:
    - ENV_TEST=test

ubun 서비스에 환경변수 추가.

docker compose up -d

docker exec -it ubun-ubun-1 bash

환경변수가 잘 들어있다.

도커 컴포즈에서는 —link 를 굳이 명시하지 않아도 서비스의 이름으로 찾아갈 수 있다.

실습) wordpress 구성하기!

mysql:8, wordpress:latest를 베이스 이미지로 하여, Dockerfile은 쓰지않고, docker-compose.yml 파일을 구성해보자. publish 포트는 wordpress는 1234로 하고, mysql는 따로 publish 하지 않는다.

mkdir wp

cd wp

vi docker-compose.yml

services:
  wp:
    image: wordpress:latest
    ports:
    - '1234:80'
    environment:
    - WORDPRESS_DB_HOST=dbdb
    - WORDPRESS_DB_NAME=wpdb
    - WORDPRESS_DB_USER=wpuser
    - WORDPRESS_DB_PASSWORD=1234
    networks:
    - wpnet
    depends_on:
    - dbdb

  dbdb:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: '1234'
      MYSQL_USER: 'wpuser'
      MYSQL_PASSWORD: '1234'
      MYSQL_DATABASE: 'wpdb'
    networks:
    - wpnet
networks:
  wpnet:

성공!

기존에 존재하는 네트워크를 사용하고 싶을 때

docker network create mynet --driver=bridge

네트워크 생성.

vi docker-compose.yml

172.19.0.0 대역에 생성됐다.

빌드한 이미지로 서비스 구성

mkdir build

cd build/

vi Dockerfile

FROM httpd:latest

도커 파일 생성.

vi docker-compose.yml

services:
  myweb:
    build: .
    # docker-compose.yml 파일이 있는 경로(.)의 Dockerfile을 빌드

도커 컴포즈 파일 생성.

docker compose up -d

echo build-test > index.html

index.html 파일 생성.

vi Dockerfile

위에서 생성한 index.html 파일을 넣어보자.

FROM httpd:latest
WORKDIR /usr/local/apache2/htdocs
COPY index.html index.html

docker compose up -d

curl localhost:5959

기본 페이지가 뜨고 docker-compose up -d 를 했지만 이미지가 빌드되지 않았다.
이미 빌드를 한 적이 있어서 빌드된 이미지가 존재하면 다시 빌드하지 않는다.

docker compose down

컨테이너 종료.

docker compose up -d --build

—build 옵션을 명시해야 계속 빌드한다.

다시 curl을 찍어보면,

수정한 Dockerfile 대로 다시 빌드가 되었다.

docker compose down

컨테이너 종료.

이번엔 빌드를 하 되, 도커파일을 지정해줘보자.

vi docker-compose.yml

services:
  myweb:
    build: 
    # docker-compose.yml 파일이 있는 경로(.)의 Dockerfile을 빌드
      context: .
      # 디렉토리 지정
      dockerfile: Dockerfile
      # 도커파일의 이름 지정.
    image: myimg:1
    # 빌드해서 나온 이미지의 이름.
    # 단독으로 쓰일때와는 의미가 좀 다르다.

    ports:
    - '5959:80'

context: 도커가 빌드를 시작할 때 참고할 작업 폴더의 위치.

context: . 으로 되어있으면 도커는 현재 폴더에 있는 Dockerfile, 소스코드, package.json 등을 모두 빌드 컨텍스트 라는 임시 공간에 담는다.

위 코드 중 context, build 부분 해석

→ Dockerfile 란 이름의 도커파일로 빌드를 하는데, 지정한 디렉토리(현재 디렉토리)의 모든 내용을 빌드해라.

docker compose scaling

—scaling <서비스명>=<컨테이너개수> 로 서비스를 구성하는 컨테이너의 수를 변경할 수 있다.

docker-compose.yml 파일에 포트 범위를 명시해준다.

하나의 접속 지점을 통해 로드밸런싱이 됐으면 좋겠지만 docker compose 에서는 그게 불가능하다.

서비스를 구성하는 컨테이너마다 호스트의 포트를 1:1 로 맵핑시켜야 한다.

왜?

도커 컴포즈에서 --scale 옵션을 통해 컨테이너 개수를 늘리는 것은 동일한 서비스를 여러 개 복제하여 실행하는 기능에 불과하다. 이 방식은 단순히 물리적인 숫자를 늘려줄 뿐, 외부에서 들어오는 트래픽을 각 컨테이너의 상태나 부하 정도에 맞춰 지능적으로 분산해주는 전문적인 로드밸런싱 기능을 포함하지 않는다.

따라서 여러 개의 컨테이너를 띄우더라도 특정 컨테이너에만 요청이 몰리거나, 장애가 발생한 컨테이너로 접속이 시도되는 등의 한계가 존재한다. 이를 해결하기 위해서는 Nginx나 HAProxy와 같은 별도의 로드밸런서 서비스를 도커 컴포즈 설정에 추가하여 앞단에 배치해야 한다.

전문 로드밸런서는 들어오는 모든 요청을 단일 지점에서 받아 각 컨테이너로 골고루 전달하고, 컨테이너의 생존 여부를 실시간으로 확인하여 정상적인 곳으로만 트래픽을 보내는 가이드 역할을 수행한다. 결과적으로 효율적인 트래픽 분산과 안정적인 서비스 유지를 위해서는 단순한 개수 확장보다는 로드밸런서를 통한 체계적인 관리가 필수적이다.

서버가 죽지 않도록... ELB와 Auto-Scailing 이해하기 (feat. AWS)

minseoki — Tue, 24 Mar 2026 16:06:32 +0900

먼저 ELB와 Auto-Scailing에 대해 알아보자.

ELB (Elastic Load Balancing)

ELB는 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 자동으로 분산시킨다.

단일 가용 영역 또는 여러 가용 영역에서 다양한 대상에 걸쳐 애플리케이션 트래픽의 부하를 분산하여 애플리케이션의 결함 허용 능력을 높인다.

그 중 ALB(Application Load Balancer)의 특징은 OSI 모델의 7계층(애플리케이션 계층)에서 작동하며 HTTP/HTTPS 프로토콜의 헤더 내용을 기반으로 고급 라우팅 결정을 내릴 수 있다.

NLB(Network Load Balancer)는 OSI 모델의 4계층에서 작동하며 초당 수백만 개의 요청을 처리할 수 있는 성능을 제공한다. 또한 가용 여역당 하나의 고정 IP를 가질 수 있다는 큰 특징이 있다.

쉽게 얘기해보면 웹서비스를 운영한다면 ALB를, 게임 서버나 실시간 스트리밍이라면 속도가 생명인 NLB를 사용한다고 볼 수도 있겠다.

Auto-Scailing

Amazon EC2 Auto-Scailing은 애플리케이션의 부하를 처리할 수 있는 정확한 수의 EC2 인스턴스를 유지할 수 있게 도와준다.

지정된 조건에 따라 EC2 인스턴스를 자동으로 시작하거나 종료한다. 이를 통해 수요가 급증할 때는 성능을 유지하고 수요가 적을 때는 비용을 절감한다.

가장 큰 목적은 고가용성(High-Availability)이다.

scale out = 서버의 갯수가 늘어남, scale in = 서버의 갯수가 줄어듬.

scale up = 서버의 리소스가 증가, scale down = 서버의 리소스가 감소.

Auto-Scailing의 구성 순서는 아래와 같다.

ELB를 생성하면서 빈 타겟그룹을 생성한다.
빈 타겟그룹으로 로드밸런서를 생성한다.
Auto-Scailing 그룹을 만든 후, 위에서 만든 빈 타켓그룹에 넣어준다.

간단한 실습을 통해 개념을 익히고 감각을 익혀보자.

Web 서버를 ubuntu 24.04 기반으로 생성하여 Auto-Scailing을 구성해보자.

EC2 인스턴스 개수는 최소 1대 ~ 최대 3대
가용 영역 최소 2개 이상(a, c)으로 하는 Auto-Scailing 가능한 web 서버들을 프라이빗 서브넷에 위치.
stress 패키지가 재부팅 시에도 자동으로 부하가 걸리게끔.
외부(노트북의 브라우저)에서 웹페이지가 보이도록.
ALB의 Listen Port : 88

Web 서버(인스턴스)를 생성할 때 퍼블릭으로 둔 후 필요한 패키지를 설치하고 인스턴스를 이미지 화 하여 프라이빗 서브넷에 인스턴스를 생성하는 방향으로 진행하였다.

먼저 퍼블릭 서브넷에 인스턴스를 하나 만들어서 nginx, stress(cpu 부하용) 패키지를 설치한 후 이미지화 하여 시작 템플릿을 만든다.

apt update -y && apt install -y nginx

echo web_tem > /var/www/html/index.html

systemctl enable --now nginx

stress 패키지 설치 후 cpu에 부하 걸어주기.

apt install -y stress

stress -c 2 -t 1200

t3.micro의 vcpus 갯수가 2개 이상이므로 -c 2, -t초

20분 동안 2 core cpu에 100% 부하를 준다.

tee /etc/systemd/system/stress.service<<EOF
[Unit]
Description=Run stress test on boot
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/stress -c 2 -t 1200
Restart=no

[Install]
WantedBy=multi-user.target
EOF

stress를 데몬화.

systemctl daemon-reload

systemctl enable stress

시스템 반영 후 재부팅 시에도 stress를 주도록 설정한다.

여기까지 했다면 이제 이미지(AMI)를 생성하고 시작 템플릿을 생성해준다.

1. 로드 밸런서 생성

Internet-facing을 선택하고 2개의 가용 영역을 생성해주는데 퍼블릭 서브넷으로 설정을 해준다.

보안 그룹은 22번과 80번 포트가 열린 보안그룹을 선택한다.

여기서 대상 그룹을 생성해줘야 한다.

대상 그룹 생성 탭에 들어가 빈 타겟 그룹을 생성해준 뒤 돌아와서 생성한 대상 그룹을 선택해 준다.

2. Auto-Scailing 그룹 생성

다음으로 Auto-Scailing 그룹을 생성해줘야 한다.

여기서도 2개의 가용 영역을 생성해주는데 서브넷은 프라이빗 서브넷에 위치시킨다. (EC2 인스턴스가 프라이빗 서브넷에 생성되어야 하므로)

기존의 로드 밸런서에 연결하는 설정을 해주고 위에서 만들었던 로드 밸런서 대상 그룹을 선택해준다.

지금부터가 중요하다.

"ELB 상태 확인 켜기"를 체크해주고,

원하는 용량, 최소 용량, 최대 용량을 정의한 뒤 정책 이름을 설정해준다.

목표 CPU 사용률은 70%로 설정한다. 평균 CPU 사용률이 70%를 넘어서면 Auto-Scailing이 인스턴스를 늘려야겠다라고 판단해 새로운 인스턴스를 생성한다. 여기서 새로운 인스턴스는 기존에 생성된 인스턴스 스펙과 동일하게 생성된다. (아까 만든 시작 템플릿을 바탕으로)

이 부분을 체크해주면 CloudWatch에서 지표를 볼 수 있다.

최종적으로 88번 포트로 접속하면 잘 뜨는 것을 확인할 수 있다.

평균 CPU 사용률이 70%가 넘어가면 인스턴스가 최대 3개까지 늘어나도록 설정했다. 필요시 사용률이 줄어들면 인스턴스가 줄어들도록 scale in 정책을 만들 수 있다. 이 부분도 평균 CPU 사용률을 정의해주면 해당 값 이하로 떨어질 경우 Auto-Scailing이 인스턴스 갯수를 줄인다.

CloudWatch 콘솔에 접속해 지표를 보면 CPU 사용률을 확인할 수 있다.

(미처 CloudWatch에서 지표 확인 화면을 캡처하지 못해 비슷한 상황인 다른 사용자의 CloudWatch 이미지를 가져왔다.)

경보 알람이 발생하면 Auto-Scailing이 발생하고 인스턴스가 늘어나고 줄어드는 동작을 진행한다.

Auto-Scailing 흐름을 보면 이런 느낌일 것이다.

지금까지 구성한 실습을 보면 이러하다.

ALB가 퍼블릭 서브넷에 위치하여 외부 손닙을 맞이하는 입구 역할을 하고 EC2는 프라이빗 서브넷에 숨서어 실제 서비스를 제공한다.

외부 사용자는 ALB(88포트)로 들어오고, ALB는 내부망을 통해 EC2(80포트)로 연결을 토스한다. 인스턴스는 공인 IP가 없어도 ALB 덕분에 안전하게 서비스할 수 있다.

시작 템플릿은 서버를 만들 때 필요한 붕어빵 틀이라고 생각하면 편하다

Auto-Scailing 그룹을 생성하고 scale out(확장), scale in(축소) 정책을 생성해 CPU 부하에 따라서 시작 템플릿을 활용해 서버를 자동으로 생성하고 삭제한다.

이 과정에서 궁금증이 생겼다.

"그럼 CPU 사용률이 떨어져 인스턴스가 삭제될 때 해당 인스턴스에 남아있는 사용자는 안 튕기나?"

삭제 결정이 내려진 서버에는 더 이상 새로운 사용자를 보내지 않는다.(배수 상태, Draining) 이미 접속 중인 손님이 볼일을 마칠 때까지 설정된 시간(기본 300초)동안 기다려 준다. 시간이 다 되면 사용자가 남아있더라도 연결을 끊고 서버를 종료한다. (이때 브라우저는 자동으로 다른 살아있는 서버에 재접속을 시도한다.) 그래서 사용자 입장에서는 잠깐의 딜레이가 발생하고 다른 큰 이슈 없이 사용할 수 있게된다.

좋은 인프라륵 구축하는 것도 중요하지만 이 속에서 "사용자가 장애를 느끼지 않게 하는 것"이 가장 큰 핵심인 것 같다. ALB와 Auto-Scailing의 조합은 단순한 자동화를 넘어 서비스의 연속성을 보장하는 강력한 도구인 것 같다.

클라우드 환경에서 DB를 어떻게 안전하고 효율적으로 관리할까? (feat. AWS RDS)

minseoki — Tue, 24 Mar 2026 00:48:10 +0900

우리는 EC2에 MySQL을 깔아서 DB를 사용할 수 있다. 그럼에도 RDS라는 서비스가 존재하며 왜 비싼 RDS를 사용하는지 생각해보았다.

답은 "운영의 자동화" 부분에 있다.

먼저 RDS 서비스가 뭔지 가볍게 살펴보자.

RDS란?

AWS가 제공하는 관계형 데이터베이스 서비스다. 이 서비스는 EC2에 비해서 상대적으로 비싸지만 대부분의 사용자들이 이 서비스를 사용한다.

이 점을 살펴보자.

하드웨어 및 OS 관리

RDS는 서버 장비 교체, OS 보안 패치 등을 알아서 처리한다. (AWS 측에서)

백업 및 복구

특정 시점으로의 복구 (Point-in-Time Recovery)가 클릭 한 번으로 가능하다.

확장성

AWS 콘솔에서 DB 사양을 높이거나 저장 공간을 쉽게 늘리고 줄일 수 있다.

고가용성

Multi-AZ 기능을 통해 데이터 센터 장애가 발생 시 서비스가 중단되지 않도록 해준다.

이렇게 사용자 대신 AWS 측에서 귀찮은 일처리들을 대신 처리해주며 편의성과 고가용성을 강조한다.

실습 과정을 통해 좀 더 깊이있게 다뤄보도록 하자.

RDS는 반드시 서브넷 그룹에 만들어야 한다.

서브넷 그룹이란 두 개 이상의 서브넷 묶음을 말한다. DB를 만들 때는 반드시 두 개 이상의 가용 영역에 걸쳐서 만드는 걸 강제한다. AWS의 고가용성 원칙 때문이다. 만약 한쪽의 가용 영역에만 DB를 두었는데 해당 데이터 센터가 중단되는 상황이 생기면 서비스에 장애가 발생한다. 하지만 서브넷 그룹을 통해 묶어둔다면 메인 DB에 문제가 생겼을 때 AWS가 즉시 다른 가용 영역에 있는 예비 DB로 서비스를 전환해 준다.

이렇게 RDS를 생성할 때 두개의 서브넷을 지정해준다.

만들고자 하는 내용을 도식화 하자면 위와 같다.

RDS를 생성했다면 DB 인스턴스를 생성해줄 차례다.

MySQL을 선택해주고 자격 증명(마스터 사용자 이름, 마스터 암호)설정한다.

연결 설정에서 기존에 만들었던 VPC를 선택하고 DB 서브넷 그룹, VPC 보안 그룹, 데이터베이스 포트(3306), 초기 데이터베이스 이름(testdb) 등 기본 설정을 진행한 뒤 데이터베이스를 생성한다.

참고로 필자는 DB용 서브넷을 인터넷 게이트웨이로 향하는 경로가 없는 프라이빗 서브넷으로 구성했다.

생성된 RDS에 접속하여 show databases; 명령을 입력해 확인해보자.

RDS가 프라이빗 서브넷에 있으므로 직접적인 접근이 불가능하다. 따라서 퍼블릭 서브넷에 bastion 서버를 생성해 RDS에 접근할 수 있도록 한다.

bastion 서버를 생성했다면 접속하여 mysql을 설치한다.

apt update -y && apt install mariadb-client-core -y (mysql 설치 명령)

생성한 RDS 엔드포인트로 접속을 한다. RDS 생성할 때 설정한 마스터 사용자 이름과 마스터 암호를 입력해주어야 한다.

RDS 생성 화면에서는 따로 정책 편집을 하지 못하므로 RDS 생성 후 반드시 보안그룹 정책을 수정해주어야 한다.

VPC 보안그룹으로 이동해서 인바운드 규칙을 편집해준다.(RDS 접근 가능하도록)

테스트용이니 모든 대역에서 접근이 가능하도록 수정해주었다.

실제로는 0.0.0.0/0으로 인바운드 규칙을 열어주는 것은 위험하다. 접근 가능한 것들만 지정해서 DB에 접근할 수 있도록 해줘야 한다.

이제 DB에 접근이 가능해졌으니 다시 접속해보자.

접속 후 show databases; 명령을 쳐보면 아까 RDS 생성 시 설정한 초기 데이터베이스 이름(testdb)이 잘 뜨는 것을 확인할 수 있다.

RDS 서비스를 잘 다룰 수 있다면 엄청난 편의성과 고가용성을 챙겨 인프라 운영 관리 측면에서 매우 이득을 볼 수 있을거라고 생각한다.

RDS는 클릭 몇 번으로 업무를 자동화 해주지만 그 바탕에는 탄탄한 VPC 설계와 서브넷 그룹, 민감한 보안그룹 설정이 이루어져야한다. 이번 실습에서는 0.0.0.0/0으로 모든 대역에서 접근가능하도록 허용하였지만 실무에서는 반드시 특정 IP로 제한하여 영향을 받지 않도록 구성해야 한다.

가상 네트워크 만들기 - AWS VPC 설계 및 프라이빗 서브넷 통신

minseoki — Sun, 22 Mar 2026 21:50:40 +0900

이번 포스팅에서는 AWS VPC와 NAT-Gateway을 실습을 통해 습득한 내용을 포스팅하고자 한다.

(단계적으로 실습을 하며 개념을 익히는 과정에 대해 설명한다.)

학습 및 포스팅 순서는 VPC 생성, Internet-Gateway, Subnet, Route Table 마지막으로 Nat-Gateway를 학습하며 마무리 한다.

VPC (Virtual Private Cloud)

VPC는 AWS 클라우드 내에 논리적으로 격리된 가상 네트워크 공간이다.

독립적인 사설 네트워크로 일반적으로 VPC는 다른 VPC 끼리 통신이 안된다. 디른 VPC끼리 통신이 되게끔 하려면 VPN이나 VPC peering, Transit Gateway 가튼 특수한 방법을 사용하면 된다.

물리적으로는 떨어져있지만 논리적으로는 같은 공간에 있는 것 처럼 구성하는 것이다.

먼저 VPC를 생성해보자.

위와 같이 설정하여 폐쇄된 사설 네트워크를 생성했다. 이 VPC에 속한 서브넷들은 반드시 10.10.0.0/16 대역을 벗어날 수 없다.

VPC를 생성하면 반드시 DNS 설정을 해줘야 한다.

수동으로 VPC를 생성하면 이 옵션이 꺼져 있다. 다른 사람이 읽기 편한 영문 주소(도메인)로 서버에 접속하고, AWS의 다른 서비스(RDS, ALB 등)들과 문제없이 통신하기 위해 반드시 설정해줘야 한다.

VPC를 성공적으로 생성했다면 인터넷 게이트웨이를 설정해보자.

Internet Gateway(IGW - 인터넷 게이트웨이)

VPC와 인터넷 사이의 통로 역할을 하는 관문이다. 이 설정이 있어야 외부(인터넷)와 양방향 통신이 가능해진다.

리소스를 만들 땐 이름만 봐도 어떤 성질이며, 어디에 속해 있는지 알 수 있도록 하는게 좋다.

인터넷 게이트웨이를 생성해주고 아까 생성한 VPC에 연결해준다. 그럼 VPC의 열린문(인터넷 게이트웨이) 설정이 되었다.

다음으로 서브넷을 생성해 보자.

Subnet(서브넷)

VPC를 더 작은 단위로 쪼갠 네트워크이다.

서브넷에는 퍼블릭(Public) 서브넷과 프라이빗(Private) 서브넷이 있다.

퍼블릭 서브넷 (Public Subnet)

VPC 외부와 통신이 되는 서브넷(인바운드-아웃바운드 둘 다 가능)

프라이빗 서브넷 (Private Subnet)

VPC 내부에서만 통신이 가능한 서브넷, 때에 따라서 아웃바운드 가능(NAT-GW)

먼저 퍼블릭 서브넷을 생성해보자.

VPC라는 아파트 단지를 생성했다면 서브넷에서 CIDR을 통해 아파트 동을 지정해주는 개념이라고 이해하면 쉽다.

퍼블릭 서브넷을 생성했다면 반드시 해줘야 하는 설정이 있다.

퍼블릭 IP 자동 부여, 영문 주소 활성화

모든 퍼블릭 서브넷을 만들 땐 항상 이 두 옵션을 체크해줘야 한다.

서브넷 설정 편집에 들어가서 해당 설정을 해주면 된다.

이번엔 프라이빗 서브넷을 생성해보자.

프라이빗 서브넷은 외부에서 찾아오지 못하도록 하는 것이 핵심이라 위에서 해줬던 설정을 안해줘도 된다.

서브넷까지 생성했다면 이번엔 라우팅 테이블을 생성해보자.

Route Table(라우팅 테이블)

라우팅 테이블은 네트워크의 이정표 역할이다. 패킷이 어디로 가야 할지(Next-hop) 경로를 정의한다.

서브넷을 만들면 이 라우팅 테이블이 기본적으로 선택(비명시)된다.

프라이빗 서브넷(내부에서만 통신이 가능)의 라우팅 테이블 정책과 동일하다.

이 기본 정책에서 이름을 바꿔 프라이빗 라우팅 테이블로 사용할 것이다.

서브넷 연결은 이 라우팅 테이블을 선택한 서브넷들을 말한다.

퍼블릭 라우팅 테이블을 생성해보자.

라우팅 테이블을 생성해였다면 라우팅 편집에 들어가 아까 생성한 인터넷 게이트웨이를 추가해 준다.

잘 추가했다면 라우팅 섹션에 표시된다.

이번에 퍼블릭 라우팅 테이블을 퍼블릭 서브넷에 연결해줘야 한다.

이 단계까지 잘 구성했다면 아래와 같은 다이어그램처럼 VPC 구성이 되었을 것이다.

여기까지 구성한 내용으로 Bastion 서버를 통한 프라이빗 서브넷 인스턴스에 ssh로 접근하는 실습을 진행해보았다.

실습 상황은 아래와 같다.

프라이빗 서브넷에 인스턴스를 생성할 때 서브넷 설정 편집은 하지말고 퍼블릭 IP를 억지로 부여받도록 한다.
보안 그룹은 모든 트래픽을 모든 대역에 허용하는 정책을 생성한다.
노트북으로 해당 인스턴스로 통신(ping)이 되는지 확인한다.
인바운드, 아웃바운드를 검증한다.

다이어그램을 구성해보면 이런 흐름이다.

먼저 프라이빗 서브넷은 라우팅 테이블 상에 외부(0.0.0.0/0)로 향하는 트래픽은 발생할 수 없기 때문에 노트북과 직접 통신은 불가능하다.

즉, bastion 서버를 통해 접근해야 한다는 말이다.

기존에 구성했던 VPC를 활용해서 프라이빗 서브넷에 퍼블릭 IP를 달고 있는 인스턴스(A)를 생성한다.

보안 그룹은 모든 트래픽을 모든 대역에 허용하는 정책을 생성한다.

인스턴스를 생성해도 노트북에서는 프라이빗 서브넷으로 접속이 불가능하다.

이번엔 경유해서 접속할 bastion(퍼블릭) 서버를 생성한다.

보안 그룹은 위에서 생성한 보안 그룹을 사용한다.

ssh를 통해 bastion 서버에 접속한다.

여기서 프라이빗 인스턴스에 접속해야 하기 때문에 프라이빗 키가 필요하다. 이 키 값은 내 노트북에 있을 것이고 bastion 서버안에는 없기에 노트북에서 bastion 서버로 scp 명령어를 사용해 전송해준다.

전송이 되었다면 ssh를 통해 bastion 서버에서 프라이빗 인스턴스로 접속해준다.

(전송 과정에서 키 권한이 헐거워서 경고 메시지가 뜰 수도 있다. 그럼 chmod 400 <키파일이름> 을 통해 권한 설정을 변경해준 후 다시 접속한다.)

접속 후 노트북에서 퍼블릭 IP를 강제로 할당받은 프라이빗 서버로 ping을 보내면 실패한다.

인바운드가 들어오고 심지어 응답도 해준다.

근데 왜 통신이 안되고 ping을 보내면 실패할까?

이 그림을 보면 이해가 좀 될 거라 생각한다.

노트북에서 프라이빗 서버로는 icmp 메시지가 잘 도달하지만, 프라이빗 서버가 보낸 icmp 응답 메시지는 노트북에 도달하지 못했다.

그 원인은 프라이빗 인스턴스가 속해있는 서브넷에 외부(0.0.0.0/0)로 빠져나가기 위한 라우팅 정책이 없기 때문이다.

퍼블릭 IP 자체가 외부에서 통용되는 IP라서 당연히 통신이 되는건 맞지만, 결국 라우팅이 안되어있어서 통신이 될 수 없다.

결국 외부로 향하기 위한 라우팅 테이블이 필요한 것이다.

마지막으로 NAT-Gateway에 대해서 살펴보자.

NAT-Gateway

PAT 개념과 비슷하다.

프라이빗 서브넷에 대해 아웃바운드 트래픽만 허용하고 싶을 때 구성한다. 프라이빗 서브넷 대역을 퍼블릭 서브넷 대역으로 NAT 하는 개념이라고 생각하면 된다. (퍼블릭 서브넷에 있으면 라우팅 테이블 정책에 의해 외부로 아웃바운드 통신이 가능하다.)

사실 VPC에 존재하는 리소스들이 통신이 되냐 안되냐의 차이는 기본적으로 공인 IP가 있냐 없냐로 볼 수 있다.

공인 IP를 달고 있는 서버가 IGW를 Next-hop으로 라우팅이 되어있으면(=퍼블릭 서브넷에 있다면) 인바운드, 아웃바운드 통신이 다 된다.

마찬가지로 프라이빗 서브넷에 존재하는 서버가 외부로 통신이 안되는 이유는 공인 IP도 없고 라우팅도 안되어있기 때문이다. 따라서 아웃바운드라도 가능하게 하기 위해 NAT-GW에 EIP(Elastic IP, 탄력적 IP)를 붙여서 PAT를 해준다고 생각하면 좋다.

(깨알 정보, NAT-GW는 AWS에서 과금요소가 많기 때문에 사용하고 끄는게 좋다.)

NAT-GW는 퍼블릭 서브넷에 존재한다.

NAT-GW를 생성할 때 연결 유형을 반드시 퍼블릭으로 해줘야 한다.

생성했다면 라우팅 정책을 추가해줘야 한다. 대상을 0.0.0.0/0으로 하고 NAT-GW를 선택한다.

NAT-GW 설정이 완료되었다.

이제 프라이빗 서브넷에서 아웃바운드가 가능해졌다.

grafana로 서버 모니터링 하기 (feat. telegraf, influxDB, node_expoter, prometheus)

minseoki — Sat, 14 Mar 2026 17:37:43 +0900

이번 포스팅에서는 CentOS 환경에서 VM 템플릿을 활용한 효율적인 인프라 배포부터 시작하여, 현대 모니터링의 표준이라 불리는 두 가지 조합인 [Telegraf + InfluxDB + Grafana] 와 [Prometheus + Node Exporter + Grafana] 시스템을 직접 구축해 보자.

[Telegraf + InfluxDB + Grafana]

1. 수집 - Telegraf

어떤 서버의 어떤 리소스(CPU, RAM, 스토리 입출력... 등 내가 원하는 대부분의 리소스의 상태, 사용량)를 얼마의 간격으로 수집할지 결정.

2. 저장 - InfluxDB

시계열(tme-series) DB, 일정한 시간 간격으로 수집된 데이터를 DB에 저장.

3. 시각화 - Grafana

저장된 데이터를 토대로 그래프를 그리거나 수치를 표현

구성하고자 하는 모니터링 구성 흐름.

모니터링하고자 하는 서버에는 agent가 설치되어있어야 한다.

1. 모니터링 대상 서버에 설치된 Telegraf(agent)가 자료를 수집(input)

2. 수집한 자료를 output을 통해 InfluxDB에 저장시킨다.

3. 저장된 데이터 소스를 Grafana가 가져와서 시각화(Dashboard) 한다.

1. Telegraf

Telegraf 및 InfluxDB 설치를 위한 레포 추가

cat <<EOF | tee /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 0
gpgkey = https://repos.influxdata.com/influxdb.key
EOF

* tea 명령은 cat이랑 결과물은 동일하나 한 번 더 출력해주는 명령이다.

yum install -y telegraf

Telegraf 먼저 설치해준다.

vi /etc/telegraf/telegraf.conf

Telegraf 설정 파일.

"어떻게 수집할지" 와 "어떻게 저장할지"를 설정.

telegraf.conf 에 넣을 내용

[global_tags]

# Configuration for telegraf agent
[agent]
    interval = "10s"
    debug = false
    hostname = "server-hostname"
    round_interval = true
    flush_interval = "10s"
    flush_jitter = "0s"
    collection_jitter = "0s"
    metric_batch_size = 1000
    metric_buffer_limit = 10000
    quiet = false
    logfile = ""
    omit_hostname = false

###############################################################################
#                                  OUTPUTS                                    #
###############################################################################

[[outputs.influxdb]]
    urls = ["http://localhost:8086"] # InfluxDB가 설치된 서버의 IP를
    database = "telegraf" # 데이터베에스 이름, 생성이 되어있지 않으면 자동 생성됨
    timeout = "10s"
    username = "admin" # InfluXDB 기본 계정
    password = "admin"
    retention_policy = ""

###############################################################################
#                                  INPUTS                                     #
###############################################################################

[[inputs.cpu]]
    percpu = true
    totalcpu = true
    collect_cpu_time = false
    report_active = false
[[inputs.disk]]
    ignore_fs = ["tmpfs", "devtmpfs", "devfs"]
[[inputs.diskio]]
[[inputs.mem]]
[[inputs.net]]
[[inputs.system]]
[[inputs.swap]]
[[inputs.netstat]]
[[inputs.processes]]
[[inputs.kernel]]

2. InfluxDB 설치

yum install -y influxdb-1.8.10

InfluxDB를 설치한다.

InfluxDB의 기본 포트는 8086이다.

systemctl enable --now influxdb

실행.

DB로 진입한다.

systemctl enable --now telegraf

Telegraf에서 output 된 자료들이 InfluxDB에 저장되는걸 확인 가능.

3. Grafana

cat <<EOF | tee /etc/yum.repos.d/grafana.repo
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=0
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF

grafana 설치 레포 추가.

yum install -y grafana

grafana를 설치한다.

grafana의 기본 포트는 3000번이다.

systemctl enable --now grafana-server

grafana 서버를 실행시킨다.

웹브라우저를 통해 접속하여 서버에 잘 설치되었는지 확인한다.

3000번 포트를 통해 서비스를 제공하고있다.

위에서 telegraf.conf 파일에 ID 와 Password 설정을 'admin'으로 했기 때문에 입력 후 로그인한다.

다음으로 시각화 할 Datasource 명시(InfluxDB)하고 Datasource의 형태에 맞는 Dashboard를 구성한다.

Dashboard는 보통 타인이 만들어 놓은 걸 import 한다.

Datasource 구성과 시각화

오른쪽에 DATA SOURCES 탭을 눌러 InfluxDB를 선택 후 구성한다.

현재 grafana와 InfluxDB는 같은 서버에 설치했기 때문에 localhost라고 해도 무방하다. 다만 포트는 당연히 InfluxDB의 포트를 명시해야 한다.

telegraf.conf 파일에서 설정했던 값을 입력해준다.

위 단계까지 진행했으면 아래에 Save & test 버튼을 눌러 테스트를 진행한다.

이제 대시보드를 세팅해보자.

다양한 대시보드들이 grafana.com에 존재한다.

ID만 copy 해서 import 해보자.

Import dashboard 를 눌러 대시보드 템플릿 ID인 928을 입력해 import 한다.

현재 대시보드상에 ${DS_INFLUXDB_TELEGRAF} 를 통해 datasource로 접근 가능하도록 환경변수가 구성된 상태지만, 실제 환경변수는 존재하지 않는다. 따라서 대시보드의 설정에서 환경변수를 추가해줘야 한다.

Dashboards 에 들어가 우측 상단에 Edit 버튼을 누르고 들어가 Settings를 눌러 대시보드를 설정한다.

Variables 탭에서 New variable 버튼을 눌러 새로운 환경변수를 등록해준다.

환경변수 이름을 등록해주고, 이 환경변수가 가리키는 대상은 InfluxDB임을 등록해준다.

다 되었으면 우측 상단에 Save dashboard 버튼을 눌러 저장한다.

대시보드를 통해 CPU, RAM, 스토리 입출력 등 내가 원하는 대부분의 리소스의 상태, 사용량 정보를 확인할 수 있게 되었다.

---

[Prometheus + Node Exporter + Grafana]

리눅스 서버의 실시간 상태 정보를 자동으로 수집하고 저장하여 시각화하는 표준 오픈소스 모니터링 시스템 구축.

1. Node Exporter - 수집기 / agent

서버의 CPU 사용률, 남은 RAM 용량, 디스크 읽기/쓰기 속도 같은 로우(Raw) 데이터를 수집해서 9100번 포트에 텍스트 형태로 노출한다.

2. Prometheus - 저장소 / 서버

prometheus.yml 설정 파일에 등록된 대상(Node Exporter)를 주기적으로 방문하여 데이터를 긁어와 시계열 데이터베이스에 저장한다.

3. Grafana - 시각화

Prometheus에 저장된 복잡한 숫자 데이터를 가져와 그래프로 나타낸다.

1. Node Exporter 설치

wget [https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz](https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz)

node exporter 압축 파일을 wget 명령으로 다운로드 한다.

압축을 풀 때와 할 때의 명령어를 간단히 적어주겠다.

tar -xvf

-x : extract(해제), v : 과정출력, -f : 파일

tar -cvf

-c : 압축 생성

tar -xvf node_exporter-1.7.0.linux-amd64.tar.gz

다운로드 받은 node_exporter 파일을 압축 해제한다.

압축 해제 후 node_exporter-1.7.0.linux-amd64 경로로 들어가보면 초록색으로 node_exporter 파일이 생긴걸 볼 수 있다.

./node_exporter

위 명령어로 실행시켜준다.

만약에 프로세스를 종료하고 싶다면, kill이나 pkill을 통해 종료시키면 된다.

pid 값은 그때그때 바뀐다.

curl [http://211.183.3.90:9100/metrics](http://211.183.3.90:9100/metrics)

node exporter 가 잘 동작하는지 확인하려면 curl <주소> 명령을 통해 찍어보면 된다.

2. Prometheus 설치

**wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz**

wget 명령으로 prometheus를 설치해준다.

tar -xvf prometheus-2.45.0.linux-amd64.tar.gz

node exporter와 마찬가지로 tar -xvf 명령으로 압축을 해제한다.

vi prometheus.yml

vi 명령으로 prometheus.yml 파일에 들어가 모니터링 대상인 prometheus를 추가한다.

9100은 node_exporter 포트 번호이고, 9090은 prometheus 포트 번호다.

./prometheus

prometheus를 실행해준다.

웹 브라우저에서 http://211.183.3.90:9090/targets 경로로 접속해 잘 동작하는지 테스트해본다.

3. Grafana

cat <<EOF | tee /etc/yum.repos.d/grafana.repo
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=0
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
EOF

grafana 설치를 위해 레포를 추가한다.

yum install -y grafana

grafana 설치.

**systemctl restart grafana-server**
**systemctl enable grafana-server**

grafana-server 실행.

위에서 했던 설정과 같이 admin 을 통해 접속한다.

위에서는 InfluxDB를 통해 구성했다면, 이번엔 Prometheus를 구성할 것이다.

URL을 입력해주고 Save & test를 눌러 저장한다.

이번엔 dashboard ID 1860을 입력해 import 해줄 것이다.

대시보드가 잘 세팅된 것을 확인할 수 있다.

---

추가로 'Daemon (데몬)' 을 만드는 법을 알아보자.

왜 굳이 데몬으로 만드냐하면,

일반 실행 파일은 실행한 사용자가 터미널 창을 닫거나 로그아웃하면 함께 종료된다. 24시간 모니터링을 해야 하는 Prometheus가 사용자 접속이 끊겼을 경우 모니터링도 함께 종료되면 안되기 때문이다.

데몬으로 만들면 사용자 접속 여부와 상관없이 시스템이 켜져 있는 한 계속 동작한다.

위에서 보면 systemctl enable 명령을 사용했었다. 이 명령은 부팅 시 자동 실행을 설정하는 것이다. 정전이나 점검 등으로 서버가 재부팅되었을 때 일일이 접속해서 ./prometheus를 입력할 필요 없이 OS가 알아서 서비스를 올리게 된다.

일반적인 실행 파일을 데몬으로 만드는 법은 systemd에 등록해주고 daemon reload를 해주면 된다.

node_exporter 와 prometheus를 데몬으로 만들어보자.

먼저 node_exporter를 데몬으로 만들어보자.

cat <<EOF | tee /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/root/node_exporter-1.7.0.linux-amd64/node_exporter
# 실행할 대상 파일.
[Install]
WantedBy=multi-user.target
EOF

systemd에 데몬 파일(/etc/systemd/system/node_exporter.service)을 생성한다.

node_exporter가 데몬의 이름이 될 것이다.

systemctl daemon-reload

변경 사항을 반영하면 정상적으로 작동할 것이다.

prometheus도 데몬으로 만들어보자.

cat <<EOF | tee /etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
Type=simple

ExecStart=/root/prometheus-2.45.0.linux-amd64/prometheus \
    --config.file=/root/prometheus-2.45.0.linux-amd64/prometheus.yml \
    --storage.tsdb.path=/root/prometheus-2.45.0.linux-amd64/data
# 실행파일 및 설정파일도 등록

[Install]
WantedBy=multi-user.target
EOF

추가 후

systemctl daemon-reload
systemctl enable --now prometheus

변경 사항을 반영해주고 enable 시켜준다.

3 Tier Architecture 구성하기 (feat. VMware, xshell, GNS3)

minseoki — Sun, 8 Mar 2026 22:27:29 +0900

3 Tier Architecture 구성

서로 독립적인 서버 구성 시 장점.

확장성이 좋다.
유지보수가 용이하다.
보안성이 증가한다.

연결 흐름

3 Tier Architecture 를 구성하기 위해 VMware로 TOMCAT, DB, WEB 서버 3대를 생성한다.

1. TOMCAT 서버

스펙

CentOS 7 미니멀, 2 core, 2GB, 20GB

IP - 211.183.3.88

자바로 웹 페이지(웹어플리케이션)을 만들었다면, 이런 웹어플리케이션을 배포하는 WAS가 필요하고, 추가적으로 개발환경(JAVA)도 구성이 필요하다.

결론적으로 JAVA + TOMCAT이 필요하다는 말이다.

JAVA = openjdk-11

TOMCAT = tomcat 10 버전

을 사용하기로 한다.

개발환경에 맞는 WAS도 잘 매칭을 시켜주는게 중요하다.

TOMCAT 서버를 생성하고 xshell 로 접속하여 명령어를 수행한다. (앞으로의 과정에서 설명 생략.)

[root@tomcat ~]# yum install -y java-11-openjdk wget unzip

# 자바 설치 및 wget unzip 설치

# 배포판이나 운영체제 버전에 따라서 패키지명이 다를 수 있다.

[root@tomcat ~]# yum search openjdk

# openjdk 문구가 들어간 것들 중에 내가 설치할 수 있는 패키지 검색

내가 사용 중인 버전이다.

톰캣을 웹 페이지에서 다운로드 할 예정이다.

https://tomcat.apache.org/download-10.cgi (톰캣 10 버전 설치 페이지)

wget <링크> 로 다운로드 진행한다.

[root@tomcat ~]# unzip apache* > /dev/null

# apache로 시작하는 모든 파일을 unzip 하고, 압축 풀리는 과정은 생략한다.

[root@tomcat ~]# mv apache-tomcat-10.1.52 tomcat

[root@tomcat ~]# chmod -R 777 tomcat

# 디렉토리 이름 변경 및 권한 부여

startup.sh 는 catalina.sh 를 백그라운드에서 동작시키기 위한 스크립트이다. (.sh = shell script)

shutdown.sh 는 catalina.sh 를 중지시키기 위한 스크립트다.

catalina.sh 를 동작시키면 포어그라운드로 동작하기 때문에 일반적인 환경에서는 startup.sh 나 shutdown.sh 를 쓴다.

실행시키는 방법

1. [root@tomcat tomcat]# sh ./bin/startup.sh

2. [root@tomcat tomcat]# ./bin/startup.sh

2번 명령어로 안되면 1번 명령어로 진행한다.

톰캣이 실행되었다.

현재 tomcat의 설정에 의해 8080 포트로 웹어플리케이션 서버(WAS)가 동작하고 있다.

브라우저에서 잘 돌아가는 모습을 볼 수 있다.

구글에 검색어로 tomcat sample 를 입력하여 들아간 후 sample application 을 다운받을 것이다.

링크 주소를 복사한 후

[root@tomcat tomcat]# wget https://tomcat.apache.org/tomcat-9.0-doc/appdev/sample/sample.war

wget으로 다운로드 한다.

[root@tomcat tomcat]# mv ./sample.war /root/tomcat/webapps

# 다운받은 sample.war 를 webapps 경로로 이동시킨다.

이동하는 과정에서 자동으로 압축이 해제된다.

서버 주소/sample 경로로 접근하면 다운받은 샘플 앱이 보인다.

현재 호스트의 IP를 출력하는 간단한 test.jsp 파일을 만들어준다.

cat <<EOF > test.jsp
<%@ page contentType="text/html; charset=UTF-8"%>
<html>
    	<head><title>hello world</title></head>
    	<body>
    	<h2>
            	TOMCAT TEST<br><br>
            	time : <%= new java.util.Date()%>
            	<%@ page import="java.net.InetAddress" %><br>
            	<%InetAddress inet= InetAddress.getLocalHost();%>
            	WAS ip : <%=inet.getHostAddress()%>
    	</h2>
 
 
    	</body>
</html>
EOF

생성 후 ls 명령어를 입력하면 test.jsp 파일이 생성된 것을 볼 수 있다.

서버 주소:8080/ROOT/test.jsp 가 아닌 서버주소:8080/test.jsp 로 접근 가능하다.

단일 파일들은 ROOT 경로에 위치시켜야 한다.

2. DB 구성

스펙

CentOS 7 미니멀, 2 core, 2GB, 20GB

IP - 211.183.3.6

DB 서버를 생성했다면 mariadb-server 를 설치해준다.

[root@tomdb ~]# yum install -y mariadb-server

[root@tomdb ~]# systemctl enable --now mariadb

[root@tomdb ~]# systemctl restart mariadb && systemctl enable mariadb

# 두 개의 명령을 동시에 실행하고 싶다면 && 기호를 사용하면 된다.

[root@tomdb ~]# mysql_secure_installation

# 암호는 본인이 설정하고 싶은 암호로 설정하고 다른 추가 설정을 물어보는 부분에서는 y, n, y, y 순서대로 입력해 설정을 완료해주면 된다.

[root@tomdb ~]# mysql -u root -p<본인암호>

MariaDB [(none)]> create database tomcatdb;

# 여기서 tomcatdb는 필자가 설정한 DB 이름이므로 본인이 설정한 DB 이름을 입력하면 된다.

MariaDB [(none)]> grant all privileges on tomcatdb.* to tomuser@'%' identified by '암호';

# tomuser 는 사용자 이름부분이다. 필자는 tomuser로 설정했다.

MariaDB [(none)]> grant all privileges on tomcatdb.* to tomuser@'localhost' identified by '1234';

# 경우에 따라서 local 에서 접속이 안되는 경우도 있다. % 안에는 localhost 가 포함이 안될 걸로 간주하는 상황이 생기기도 하기 때문이다.

접속이 안되는 경우 위 명령어로 다시 시도해본다.

후에 exit 명령어로 나간 후 root 가 아닌 사용자 이름으로 다시 DB에 접속해보자.

접속해 보면 tomcatdb가 잘 생성된 걸 볼 수 있다.

다시 tomcat 서버로 돌아와서 mysql 명령을 설치한 다음 접속이 잘 되는지 확인해보자.

[root@tomcat tomcat]# yum install -y mysql

# mysql 명령 설치(클라이언트 역할)

[root@tomcat tomcat]# mysql -u tomuser -p암호 -h DB서버주소

tomcat 서버에서도 잘 보인다.

다음으로 dbtest.jsp 파일을 만들어서 연동이 잘 되는지 테스트 해보자.

dbtest.jsp 파일

cat <<EOF > dbtest.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<%@ page import="java.sql.*"%>
<h1>DB</h2>
<%
        Connection conn=null;
        try{
                String Url="jdbc:mysql://<DB주소>/<DB이름>";
                String Id="<DB유저>";
                String Pass="<유저암호>";

                Class.forName("com.mysql.jdbc.Driver");
                conn=DriverManager.getConnection(Url,Id,Pass);
                out.println("was-db Connection Success!");
        }catch(Exception e) {
                e.printStackTrace(); 
}
%>

EOF

<> 안에는 본인이 설정한 대로 수정하면 된다.

JDBC = JAVA DataBase Connector
자바와 MySQL을 연동하기 위한 라이브러리이다.

[root@tomcat tomcat]# mv ./dbtest.jsp /root/tomcat/webapps/ROOT

# 현재 디렉토리의 dbtest.jsp 파일을 웹앱루트디렉토리로 이동시킨다.

브라우저에서 접속을 해보면 아직 연동이 되지 않았다.

JDBC를 설치해줘야 한다.

https://mvnrepository.com/artifact/mysql/mysql-connector-java/8.0.23

Maven Repository: mysql » mysql-connector-java » 8.0.23

mysql mysql-connector-java 8.0.23 compile Scope:CompileTestProvidedRuntime Format:Groovy LongGroovy ShortKotlin Include backlinks implementation("mysql:mysql-connector-java:8.0.23") libraryDependencies += "mysql" % "mysql-connector-java" % "8.0.23" ivy"mys

mvnrepository.com

# JDBC 라이브러리 설치 경로

마찬가지로 링크 주소를 복사해서 wget <링크 주소> 으로 설치해준다.

다운로드가 잘 되었다.

[root@tomcat tomcat]# mv mysql-connector-java-8.0.23.jar /root/tomcat/lib

# 받은 파일을 라이브러리 디렉토리에 복사한다.

[root@tomcat tomcat]# sh ./bin/shutdown.sh

# 톰캣 중지

[root@tomcat tomcat]# sh ./bin/startup.sh

# 톰캣 시작

다시 브라우저에서 접속해보면 연동이 잘 된 걸 확인할 수 있다.

3. WEB 서버 구축

스펙

CentOS 7 미니멀, 2 core, 2GB, 20GB

IP - 211.183.3.80

여기서 Reverse Proxy 개념이 등장한다.

원래는 client가 직접 WAS 서버(백엔드, tomcat)에 가서 test.jsp 파일을 가져와야 하는데, 외부의 사용자들이 내 백엔드 서버에 접근하는게 보안적으로 좋지 않기 때문에 Reverse Proxy가 WAS를 대리하여 client들에게 test.jsp 파일을 제공하는 구조이다.

웹서버를 설치하고 실행시켜준다.

[root@tomweb ~]# yum install -y httpd

[root@tomweb ~]# systemctl restart httpd

[root@tomweb ~]# systemctl enable httpd

정적인 페이지를 만들어보자

[root@tomweb ~]# echo 'static page' > /var/www/html/index.html

# /var/www/html 경로에 index.html 파일을 만들어 static page 라는 내용을 넣어준다.

정적인 요청은 web 서버가 스스로 처리하고 jsp 파일에 대한 요청을 하면 tomcat 서버가 처리하도록 하고자 한다.

[root@tomweb ~]# vi /etc/httpd/conf/httpd.conf

# Reverse Proxy 파일 설정을 해준다.

위 명령어로 들어가 아래 코드를 56번째 줄 이후에 복붙해준다.

LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

<VirtualHost *:80> # 80번 포트로 들어오는 모든 ip에 대한 설정
    ProxyRequests Off
    ProxyPreserveHost On
    <Proxy *> 
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyPass /jsp http://172.16.101.88:8080/
    ProxyPassReverse /jsp http://172.16.101.88:8080/
</VirtualHost>

누군가가 웹서버의 jsp 경로(http://211.183.3.80:80/jsp)로 요청하면 그 요청을 211.183.3.88:/8080/ 으로 전달해라 라는 코드 내용이다.

[root@tomweb ~]# systemctl restart httpd

# 웹서버를 재실행시킨다.

[root@tomweb ~]# curl 211.183.3.80:80/index.html

# 정적 요청 = 웹서버가 처리한다.

정적인 요청은 웹서버가 처리하고 jsp 파일에 대한 요청은 tomcat 서버가 처리하고 있다.

Reverse Proxy 동작 흐름