Now Loading ...
-
Dockerfile 완벽 가이드: 구조와 모범 사례
Dockerfile 기본 구조
Dockerfile은 Docker 이미지를 생성하기 위한 스크립트입니다. 각 명령어는 새로운 레이어를 생성하며, 이미지의 최종 상태를 결정합니다.
1. 기본 설정 명령어
FROM
FROM node:18-alpine
베이스 이미지 지정
모든 Dockerfile은 FROM으로 시작
가능한 경우 공식 이미지 사용 권장
Alpine 기반 이미지로 크기 최소화 가능
ARG
ARG VERSION=latest
ARG BUILD_ENV=production
빌드 시점 변수 정의
docker build --build-arg 로 외부 주입 가능
ENV와의 주요 차이점:
빌드 시에만 사용 가능
이미지에 저장되지 않음
컨테이너 실행 시 접근 불가
2. 파일 시스템 설정
WORKDIR
WORKDIR /app
작업 디렉토리 설정
절대 경로 사용 권장
존재하지 않는 경우 자동 생성
이후 명령어의 기준 경로가 됨
COPY
# 단일 파일 복사
COPY package.json .
# 여러 파일 복사
COPY ["file1", "file2", "./"]
# .dockerignore 적용
COPY . .
호스트에서 이미지로 파일 복사
상대 경로는 WORKDIR 기준
.dockerignore로 제외 파일 설정 가능
3. 빌드 및 실행 설정
RUN
# 쉘 형식
RUN npm install
# 실행 형식
RUN ["npm", "install"]
# 레이어 최소화를 위한 체이닝
RUN apt-get update && \
apt-get install -y \
package1 \
package2 && \
rm -rf /var/lib/apt/lists/*
새 레이어에서 명령어 실행
이미지 빌드 중 실행
레이어 수 최소화를 위해 명령어 체이닝 권장
ENV
ENV NODE_ENV=production
ENV PATH=$PATH:/usr/local/bin
환경 변수 설정
빌드 시점 및 런타임에서 사용 가능
컨테이너 실행 시에도 유지됨
CMD와 ENTRYPOINT
# CMD 예시
CMD ["npm", "start"]
# ENTRYPOINT 예시
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]
CMD: 기본 실행 명령어 (오버라이드 가능)
ENTRYPOINT: 고정 실행 명령어
보통 둘 중 하나만 사용
ENTRYPOINT + CMD 조합도 가능
Docker Build 명령어 상세 가이드
기본 빌드 명령어
docker build -t my-app:1.0 .
주요 빌드 옵션
옵션
설명
예시
-t, --tag
이미지 태그 지정
docker build -t app:1.0 .
-f, --file
도커파일 경로 지정
docker build -f prod.Dockerfile .
--build-arg
빌드 인자 전달
docker build --build-arg ENV=prod .
-q, --quiet
진행 상황 출력 생략
docker build -q .
빌드 컨텍스트 최적화
.dockerignore 활용
# 빌드에서 제외할 파일
node_modules
*.log
.git
.env*
레이어 캐시 활용
# 효율적인 캐시 활용
COPY package*.json ./
RUN npm install
COPY . .
멀티 스테이지 빌드 예시
# 빌드 스테이지
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
# 실행 스테이지
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY package*.json ./
RUN npm install --production
CMD ["npm", "start"]
모범 사례 및 팁
1. 이미지 크기 최적화
Alpine 기반 이미지 사용
불필요한 패키지 제거
멀티 스테이지 빌드 활용
2. 보안 강화
루트가 아닌 사용자로 실행
최소 권한 원칙 적용
보안 스캔 도구 활용
3. 캐시 최적화
자주 변경되는 레이어는 나중에 배치
의존성 설치는 별도 레이어로 분리
.dockerignore 적극 활용
참고 문헌
Docker 공식 문서: Dockerfile 모범 사례
Docker 빌드 최적화 가이드
컨테이너 보안 가이드라인
-
Introduction
컴퓨터 네트워크
컴퓨터와 프린터, 스마트폰과 같은 기타 장치들이 서로 통신할 수 있도록 연결한 집합이다.
통신을 위해 컴퓨터와 장치는 정보 전송을 지원하는 물리적 매체로 연결되어야한다.
구리 케이블 및 광섬유와 같은 유선 매체와 무선 주파수 매체를 포함하여 물리적 매체에 대한 다양한 기술이 개발되었다.
컴퓨터는 다양한 네트워크 토폴로지로 매체에 연결될 수 있다.
네트워크를 통신하기 위해 컴퓨터는 사용되는 매체와 상관없이 통신 프로토콜이라는 합의된 규칙을 사용한다.
컴퓨터 네트워크에는 개인용 컴퓨터, 서버, 네트워킹 하드웨어 또는 기타 특수 목적 또는 일반 목적을 호스트가 포함될 수 있다.
이들은 네트워크 주소로 식별되며 호스트명을 가질 수 있다.
호스트명은 노드에 대한 기억하기 쉬운 레이블 역할을 하며 초기 할당 후에는 거의 변경되지 않는다.
네트워크 주소는 인터넷 프로토콜과 같은 통신 프로토콜에 의해 노드를 찾고 식별하는 데 사용된다.
네트워크 패킷
대부분의 최신 컴퓨터 네트워크는 패킷 모드 전송을 기반으로 하는 프로토콜을 사용한다.
네트워크 패킷은 교환 네트워크에서 전송되는 형식화된 데이터 단위이다.
패킷은 제어 정보와 사용자 데이터(Payload)의 두 가지 유형의 데이터로 구성된다.
제어 정보는 네트워크가 사용자 데이터를 전달하는 데 필요한 데이터를 제공한다.
예를 들어, 소스 및 대상 네트워크 주소, 오류 감지 코드 및 시퀀싱 정보 등이 있다.
일반적으로 패킷 헤더 및 트레일러에 있으며, 사용자 데이터(Payload)는 그 사이에 있다.
패킷을 사용하면 네트워크가 회선 교환되는 경우보다 전송 매체의 대역폭을 사용자 간에 더 잘 공유할 수 있다.
OSI 7 Layer
Layer
Protocol Data Unit(PDU)
e.g.
Function
Host Layer
7
Application Layer
Data
HTTP, SMTP, SNMP, FTP, TELNET, NFS, NTP
리소스 공유나 원격 파일 접근을 위한 고급 프로토콜
Host Layer
6
Presentation Layer
Data
ASCII, MIDI, MPEG
네트워킹 서비스와 애플리케이션 간 데이터 변환 (문자 인코딩, 데이터 압축, 암호화/복호화)
Host Layer
5
Session Layer
Data
FIFO, NetBIOS, SSL, TLS
통신 세션 관리, 즉 두 노드 간의 여러 번의 왕복 전송 형태로 정보를 지속적으로 교환하는 것
Host Layer
4
Transport Layer
Segment
TCP, UDP, RTP, SCTP
패킷 분할, ACK 및 멀티플렉싱를 포함하여 네트워크의 지점 간 데이터 세그먼트의 안정적인 전송
Media Layer
3
Network Layer
Packet, Datagram
IP, ICMP, IPsec
Addressing, Routing, Traffic Control을 포함한 다중 노드 네트워크 구조화 및 관리
Media Layer
2
Data Link Layer
Frame
Ethernet
물리적 계층으로 연결된 두 노드 간 데이터 프레임 전송
Media Layer
1
Physical Layer
Bit, Symbol
X.25, RS-232
물리적 매체를 통한 원시 비트 스트림의 전송 및 수신
브리지 및 스위치
브리지와 스위치는 통신에 관련된 포트로만 프레임을 전달한다.
브리지는 두 개의 포트만 있지만, 스위치는 일반적으로 수많은 포트를 가지고 있어 장치에 대한 스타 토폴로지를 용이하게 하고 추가 스위치를 계단식으로 연결할 수 있다.
브리지와 스위치는 OSI 모형의 데이터 링크 계층(2 Layer)에서 작동하며 두 개 이상의 네트워크 세그먼트 간의 트래픽을 브리지하여 단일 로컬 네트워크를 형성한다.
브리지와 스위치는 네트워크의 충돌 도메인을 분할하지만 단일 브로드캐스트 도메인을 유지한다. 브리징 및 스위칭을 통한 네트워크 세분화는 크고 혼잡한 네트워크를 더 작고 효율적인 네트워크의 집합으로 분해하는 데 도움이 된다.
라우터
라우터는 패킷에 포함된 주소 지정 또는 라우팅 정보를 처리하여 네트워크 간에 패킷을 전달하는 인터네트워킹 장치이다. 라우팅 정보는 종종 라우팅 테이블과 함께 처리된다.
라우터는 라우팅 테이블을 사용하여 전달할 위치를 결정한다.
방화벽
방화벽은 네트워크 보안 및 엑세스 규칙을 제어하는 네트워크 장치 또는 소프트웨어이다.
방화벽은 내부 네트워크와 인터넷과 같은 잠재적으로 안전하지 않은 외부 네트워크 간의 연결에 삽입된다.
방화벽은 일반적으로 인식되지 않는 소스에서의 엑세스 요청을 거부하고 인식된 소스에서의 작업을 허용하도록 구성된다.
점점 증가하는 사이버 공격 관련 이슈가 발생하는 현 시대에서 방화벽은 네트워크 보안에서 중요한 역할로 여겨지고 있다.
SSL(Secure Socket Layer)/TLS(Transport Layer Security)
SSL은 인증서가 있는 서버를 필요로 한다.
클라이언트가 SSL 보안 서버에 대한 엑세스를 요청하면 서버는 인증서 사본을 클라이언트에 보낸다.
SSL 클라이언트는 전달받은 인증서를 확인 후 검증되면 서버가 인증된다.
클라이언트는 세션에서 사용할 대칭 키 암호를 협상한다.
세션은 SSL 서버와 SSL 클라이언트 간의 매우 안전한 암호화된 터널에서 통신할 수 있게된다.
References
https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%93%A8%ED%84%B0_%EB%A7%9D
https://ko.wikipedia.org/wiki/OSI_%EB%AA%A8%ED%98%95
-
Kubernetes Helm 차트 분석
Helm 개요
Helm은 Kubernetes의 패키지 매니저로서, charts라는 패키지 포맷을 통해 애플리케이션을 관리합니다.
Helm Charts의 이해
기본 개념
Charts: Kubernetes 리소스를 설명하는 파일들의 집합
Release: Kubernetes 클러스터에 배포된 Chart의 인스턴스
Repository: Charts를 저장하고 공유하는 저장소
Charts의 활용 사례
단순 배포:
단일 서비스(예: Memcached) 배포
독립적인 마이크로서비스 구성
복잡한 애플리케이션:
웹 애플리케이션 전체 스택
데이터베이스 + 캐시 + 서버 조합
마이크로서비스 아키텍처
Chart 구조와 기본 명령어
myapp/
Chart.yaml # 메타데이터 파일
values.yaml # 기본 설정값
templates/ # 템플릿 디렉토리
deployment.yaml # 배포 설정
service.yaml # 서비스 설정
ingress.yaml # 인그레스 설정
charts/ # 종속성 차트들
주요 명령어
# Chart 다운로드
helm pull chartrepo/chartname
# Chart 설치
helm install release-name chartrepo/chartname
# 릴리스 목록 조회
helm list
# Chart 업그레이드
helm upgrade release-name chartrepo/chartname
<https://helm.sh/ko/docs/topics/charts/>
## Helm 템플릿 시스템
### 템플릿 기본 사항
Helm의 템플릿 시스템은 Go 템플릿을 기반으로 하며, 강력한 변수 치환과 조건부 로직을 제공합니다.
#### 템플릿 문법 예시
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-config
data:
# 단순 값 참조
database: {{ .Values.database.name }}
# 조건문 사용
{{- if .Values.enableFeature }}
feature.enabled: "true"
{{- end }}
# 반복문 사용
ports: |
{{- range .Values.service.ports }}
- {{ . }}
{{- end }}
로컬 템플릿 테스트
템플릿을 실제 클러스터에 적용하기 전에 로컬에서 테스트할 수 있습니다.
# 기본 템플릿 렌더링
helm template .
# 특정 값 파일 사용
helm template . -f values.dev.yaml
# 특정 템플릿만 렌더링 후 적용
helm template . -s templates/config.yaml --values=dev.yaml | kubectl apply -f -
주의사항
클러스터 상태 의존적인 값들은 로컬에서 테스트할 때 가상(faked) 값으로 대체됩니다
서버 측 유효성 검사는 수행되지 않으므로, 실제 적용 전 주의가 필요합니다
Helm Values 시스템
Values 파일 구조화
values.yaml 파일은 Helm 차트의 기본 설정값을 정의합니다. 환경별로 다른 설정이 필요한 경우 values-{env}.yaml 파일을 사용할 수 있습니다.
# values.yaml 예시
global:
environment: production
application:
name: myapp
replicas: 3
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 200m
memory: 256Mi
autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 80
HPA (Horizontal Pod Autoscaling) 설정
HorizontalPodAutoscaler는 워크로드의 자동 스케일링을 담당하는 Kubernetes 리소스입니다.
# HPA 템플릿 예시
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: {{ .Release.Name }}-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: {{ .Release.Name }}
minReplicas: {{ .Values.autoscaling.minReplicas }}
maxReplicas: {{ .Values.autoscaling.maxReplicas }}
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }}
Ingress 설정
Ingress는 클러스터 외부에서 내부 서비스로의 HTTP/HTTPS 라우팅을 관리합니다.
# Ingress 템플릿 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: {{ .Release.Name }}-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
rules:
- host: {{ .Values.ingress.host }}
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: {{ .Release.Name }}-service
port:
number: 80
Kubernetes 리소스 관리
ReplicaSet 관리
ReplicaSet은 지정된 수의 파드 복제본이 항상 실행되도록 보장하는 Kubernetes 리소스입니다.
ReplicaSet 주요 구성 요소
# ReplicaSet 템플릿 예시
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: {{ .Release.Name }}-replicaset
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Release.Name }}
template:
metadata:
labels:
app: {{ .Release.Name }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
resources:
requests:
cpu: {{ .Values.resources.requests.cpu }}
memory: {{ .Values.resources.requests.memory }}
limits:
cpu: {{ .Values.resources.limits.cpu }}
memory: {{ .Values.resources.limits.memory }}
ReplicaSet 설정 가이드
셀렉터 설정
파드 식별을 위한 레이블 매칭 규칙 정의
적절한 레이블링 전략 수립 필요
레플리카 수 관리
초기 레플리카 수 설정
HPA와 연동 시 고려사항 검토
파드 템플릿 설계
컨테이너 스펙 정의
리소스 요청/제한 설정
헬스 체크 구성
DaemonSet
데몬셋은 모든 노드 또는 일부 노드가 파드의 사본을 실행하도록 한다.
노드가 클러스터에 추가되면 파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지로 수집된다.
데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다.
데몬셋의 일부 대표적인 용도
모든 노드에서 클러스터 스토리지 데몬 실행
모든 노드에서 로그 수집 데몬 실행
모든 노드에서 노드 모니터링 데몬 실행
각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다.
컨테이너 리소스 관리
Kubernetes에서 효율적인 리소스 관리는 안정적인 애플리케이션 운영의 핵심입니다.
리소스 요청과 제한
# 리소스 설정 예시
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
리소스 요청 (Requests)
컨테이너가 필요로 하는 최소 리소스 양
스케줄링 결정에 사용
노드의 리소스 예약에 활용
리소스 제한 (Limits)
컨테이너가 사용할 수 있는 최대 리소스 양
초과 시 컨테이너 제한 또는 재시작
OOM Killer 동작 기준
CPU 리소스 단위 이해
단위
설명
예시
코어
1.0 = 1개 CPU 코어
cpu: "1.0"
밀리코어
1000m = 1개 CPU 코어
cpu: "500m"
백분율
CPU 코어의 백분율
cpu: "0.5" (50%)
CPU 리소스 특징
절대값 기준: 노드 스펙과 무관하게 동일한 컴퓨팅 파워
최소 단위: 1m (0.001) CPU
일반적인 설정:
가벼운 서비스: 100m-250m
중간 규모: 500m-1000m
리소스 집약적: 1000m 이상
메모리 리소스 관리
spec:
containers:
- name: app
resources:
requests:
memory: "128Mi"
limits:
memory: "256Mi"
메모리 단위 체계
단위
설명
사용 예
Ki
킬로바이트 (1024)
memory: "64Ki"
Mi
메가바이트 (1024^2)
memory: "128Mi"
Gi
기가바이트 (1024^3)
memory: "2Gi"
참고: 쿠버네티스에서 CPU 리소스를 1m보다 더 정밀한 단위로 표기할 수 없다. 이 때문에, CPU 단위를 1.0 또는 1000m보다 작은 밀리CPU 형태로 표기하는 것이 유용하다. 예를 들어, 0.005 보다는 5m으로 표기하는 것이 좋다.
메모리 리소스 단위
memory 에 대한 제한 및 요청은 바이트 단위로 측정된다. E, P, T, G, M, k 와 같은 수량 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다.
128974848, 129e6, 129M, 128974848000m, 123Mi
접미사의 대소문자에 유의한다. 400m의 메모리를 요청하면, 이는 0.4 바이트를 요청한 것이다. 이 사람은 아마도 400 메비바이트(mebibytes) (400Mi) 또는 400 메가바이트 (400M) 를 요청하고 싶었을 것이다.
https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/
-
-
네트워크 인프라 구성도 그리기
구성 요소별 핵심 역할
👨💻 사용자 (Client)
웹 브라우저를 통해 서비스에 접속하는 최종 사용자입니다.
🌐 도메인 등록 및 DNS 서버
사용자가 도메인 주소(예: www.your-service.com)를 입력하면, 해당 주소를 클라우드 플랫폼의 서버 IP 주소로 변환하여 연결해주는 역할을 합니다.
☁️ 클라우드 플랫폼
VPC (Virtual Private Cloud): 클라우드 플랫폼 내에 생성된 논리적으로 분리된 가상의 네트워크 공간입니다. 외부로부터 격리되어 있어 보안이 강화됩니다.
로드 밸런서 (Load Balancer): 사용자의 요청(트래픽)을 여러 대의 웹 서버로 자동 분산하여 특정 서버에 과부하가 걸리는 것을 방지합니다. 이를 통해 서비스의 안정성을 높이고, SSL 인증서를 적용하여 HTTPS 통신을 처리합니다.
Public Subnet (외부망): 인터넷과 직접 통신이 가능한 영역입니다.
웹 서버 (Nginx): 프론트엔드 애플리케이션을 사용자에게 제공합니다. 정적 파일을 서빙하고, 사용자의 동적 요청을 내부망에 있는 WAS로 전달하는 리버스 프록시(Reverse Proxy)의 핵심 역할을 수행합니다. Docker 컨테이너로 배포됩니다.
Private Subnet (내부망): 인터넷에서 직접 접근할 수 없는 내부 네트워크 영역으로, 중요한 자원을 배치하여 보안을 강화합니다.
WAS: 백엔드 애플리케이션으로, 실제 비즈니스 로직을 처리하고 데이터베이스와 통신합니다. 웹 서버를 통해서만 요청을 받기 때문에 외부에 직접 노출되지 않아 안전합니다. 마찬가지로 Docker 컨테이너로 배포됩니다.
DB 서버: 서비스의 모든 데이터를 저장하고 관리하는 데이터베이스입니다. 클라우드 플랫폼의 관리형 서비스를 사용하거나, 서버에 Docker 컨테이너로 직접 구축할 수 있습니다. 가장 안쪽의 격리된 네트워크에 위치하며 오직 WAS의 요청에만 응답합니다.
데이터 흐름
DNS 조회: 사용자가 브라우저에 도메인 주소를 입력하면, DNS가 클라우드 플랫폼 로드 밸런서의 IP 주소를 알려줍니다.
요청 전달: 사용자의 요청은 클라우드 플랫폼의 로드 밸런서로 전달됩니다.
트래픽 분산: 로드 밸런서는 받은 요청을 Public Subnet에 있는 여러 웹 서버 중 하나로 전달합니다.
프론트엔드 서빙 및 API 요청: 웹 서버는 프론트 엔드 코드로 만들어진 화면을 사용자에게 보여줍니다. 만약 데이터 처리가 필요하면(예: 로그인, 게시글 조회), 웹 서버는 해당 요청을 Private Subnet에 있는 WAS로 전달합니다.
비즈니스 로직 처리: WAS는 요청을 받아 비즈니스 로직을 수행하고, 필요시 DB 서버에 데이터 조회를 요청합니다.
데이터 응답: DB 서버는 WAS의 요청을 처리한 후 결과를 반환합니다.
API 응답: WAS는 DB에서 받은 데이터를 가공하여 웹 서버로 최종 결과를 전달합니다.
최종 렌더링: 웹 서버는 WAS로부터 받은 데이터를 포함하여 사용자에게 최종 화면을 보여줍니다.
보안/네트워킹 권장 설정
VPC 분리: 퍼블릭 서브넷, 프라이빗 서브넷
SG(Security Group): 최소 포트만 허용
LB→Web Server: 443/80(내부)
Web Server→WAS: 8080(내부)
WAS→DB: 3306(내부)
HTTPS 강제 및 HSTS, 보안 헤더(Content-Security-Policy 등) 적용
DB 프라이빗 접속만 허용, 백업/복제/모니터링
배포 파이프라인(예시)
CI: 테스트 → Docker 이미지 빌드 → 취약점 스캔 → 레지스트리에 push
CD: 서버/쿠버네티스에 배포, 헬스체크 후 트래픽 전환(블루/그린 또는 롤링)
포트/엔드포인트 요약
외부: 443(HTTPS) → LB → Web Server
내부: 8080(WAS), 3306(DB)
관리: SSH는 Bastion Host 또는 SSM 계열 툴로 제한적 허용
운영 모니터링
애플리케이션: Prometheus + Grafana, Spring Actuator
인프라: Cloud Platform Monitoring, 로드밸런서/네트워크 지표, 로그 수집(ELK/EFK)
-
메시지 교환 방식
네트워크로 메시지를 주고받는 방식은 대표적으로 회선 교환 방식과 패킷 교환 방식으로 나눌 수 있다.
각 방식을 사용하는 네트워크를 각각 회선 교환 네트워크, 패킷 교환 네트워크라고 한다.
회선 교환 방식 (Circuit Switching)
회선 교환 방식은 먼저 메시지 전송로인 회선을 설정하고 이를 통해 메시지를 주고 받는 방식이다.
회선 교환 네트워크에서는 호스트들이 메시지를 주고받기 전에 두 호스트를 연결한 후, 연결된 경로로 메세지를 주고 받는다.
회선 교환 방식은 우선 두 호스트 사이에 연결을 확보한 후에 메시지를 주고 받는 특성 덕분에 주어진 시간 동안 전송되는 정보의 양이 비교적 일정하다는 장점이 있다.
회선 교환 네트워크가 올바르게 동작하기 위해서는 호스트 간의 회선을 적절하게 설정해야 한다.
이 역할을 수행하는 회선 교환 네트워크 장비로는 회선 스위치가 있다. 즉, 회선 스위치는 호스트 사이에 일대일 전송로를 확보하는 네트워크 장비이다.
전통적인 전화망이 회선 교환 방식의 대표적인 사례이다.
누군가에게 전화를 걸면 수신자가 전화를 받기 전에 송신자와 수신자 사이에 연결이 설정되어야 하고, 한번 연결이 설정되면 연결된 전송로를 통해서만 통화가 가능해진다.
회선 교환 방식에는 회선의 이용 효율이 낮아질 수 있다는 단점이 존재한다.
가능한 모든 회선에 끊임없이 메시지가 흐르고 있어야만 회선의 이용 효율이 높아진다. 즉, 메시지를 주고 받지 않으면서 회선을 점유하고 있다면 낭비라 여겨진다.
패킷 교환 방식 (Packet Switching)
패킷 교환 방식은 회선 교환 방식의 문제점을 해결한 방식으로, 메시지를 패킷이라는 작은 단위로 쪼개어 전송한다.
패킷은 패킷 교환 네트워크 상에서 송수신되는 메시지의 단위입니다.
패킷 교환 네트워크는 회선 교환 네트워크와는 달리 메시지를 송수신하는 두 호스트가 하나의 전송 경로를 점유하지 않기에 네트워크 이용 효율이 상대적으로 높다.
사전에 설정된 경로만으로 통신하는 회선 교환 방식과는 달리, 패킷 교환 방식은 정해진 경로만으로 메시지를 송수신하지 않는다.
이 과정에서 메시지는 다양한 중간 노드를 거칠 수 있는데, 이때 중간 노드인 패킷 스위치는 패킷이 수신지까지 올바르게 도달할 수 있도록 최적의 경로를 결정하거나 패킷의 송수신지를 식별합니다. 대표적인 패킷 스위치는 네트워크 장비로는 라우터, 스위치가 있다.
패킷을 통해 전송하고자 하는 데이터를 Payload라고 한다.
Payload와 더불어 header라는 정보도 패킷 앞에 포함된다.
때로는 패킷 뒤에 trailer라는 정보가 포함되기도 한다.
헤더와 트레일러는 패킷에 붙는 일종의 부가 정보. 즉, 제어 정보이다.
패킷 교환 네트워크에서 주고 받는 메시지의 단위는 패킷이며, 패킷은 전송하고자 하는 데이터인 페이로드와 부가 정보인 헤더 및 트레일러로 구성된다.
Refenrences
https://hongong.hanbit.co.kr/network-%ED%9A%8C%EC%84%A0-%EA%B5%90%ED%99%98-%EB%B0%A9%EC%8B%9D%EA%B3%BC-%ED%8C%A8%ED%82%B7-%EA%B5%90%ED%99%98-%EB%B0%A9%EC%8B%9D/
-
클라우드 컴퓨팅
서비스 모델
서비스 지향 아키텍쳐가 “모든 것을 서비스로”(everything as a service, EaaS, XaaS, aas)를 지지하지만 클라우드 컴퓨팅 제공자들은 각기 다른 모델에 따라 자신들의 서비스들을 제공하며,
이 모델의 세 가지 NIST 표준 모델은 서비스형 인프라스트럭처(IaaS), 서비스형 플랫폼(PaaS), 서비스형 소프트웨어(SaaS)가 있다. 이 모델들은 추상화를 증가시킨다.
IaaS (Infrastructure as a Service)
국제 인터넷 표준화 기구(IETF)에 따르면 가장 기본적인 클라우드 서비스 모델은 컴퓨팅 인프라스트럭처, 즉 가상 머신과 기타 자원들을 구독자에 대한 서비스로 제공하는 제공자들의 모델이다.
IaaS는 물리적 컴퓨팅 자원, 위치, 데이터 파티셔닝, 확장, 보안, 백업과 같은 인프라스트럭처의 세세한 부분으로부터 사용자를 이끌어내는 온라인 서비스들을 가리킨다.
젠, 버추얼박스, 오라클 VM, KVM, VM웨어 ESX/ESXi, 하이퍼-V
와 같은 하이퍼바이저는 게스트로 가상 머신을 실행한다.
클라우드 운영 체제 내의 하이퍼바이저 풀들은 많은 수의 가상 머신들 및 고객의 다양한 요구에 맞는 서비스의 확장/축소 기능을 지원할 수 있다.
리눅스 컨테이너들은 물리 하드웨어 상에서 직접 구동되는 단일 리눅스 커널의 격리된 파티션에서 실행된다. 리눅스 cgroups와 이름공간들은 컨테이너의 격리, 보안, 관리에 사용되는 기반 리눅스 커널 기술들이다.
컨테이너화는 가상화 보다 더 높은 성능을 제공하는데, 그 이유는 하이퍼바이저 부하가 없기 때문이다. 또, 컨테이너 용량은 컴퓨터 부하와 함께 동적으로 규모를 조절하므로 과도한 공급 문제를 해결하고 사용률 기반의 과금을 가능케 한다.
IaaS 클라우드는 가상 머신 디스크 이미지 라이브러리, 로우(raw) 블록 스토리지, 파일 또는 오브젝트 스토리지, 방화벽, 로드 밸런서, IP 주소, 가상 근거리 통신망, 소프트웨어 번들 과 같은 추가적인 자원들을 종종 제공한다.
IaaS 클라우드 제공자들은 요청이 오면 이러한 자원을 데이터 센터에 설치된 수많은 장비를 통해 제공해준다.
광역 연결의 경우 고객들은 인터넷이나 캐리어 클라우드(전용 가상 근거리 통신망) 중 하나를 사용할 수 있다.
응용 프로그램을 배치시키기 위해 클라우드 사용자들은 운영 체제 이미지와 자신들의 응용 소프트웨어를 클라우드 인프라스트럭처에 설치한다.
이 모델에서 클라우드 사용자는 운영 체제와 응용 소프트웨어의 패치 및 유지보수를 수행한다.
클라우드 제공자들은 일반적으로 IaaS 서비스를 유틸리티 컴퓨팅 기반으로 과금한다: 비용은 할당 및 소비된 자원의 양을 반영한다.
AWS에서 제공하는 EC2 가 대표적인 예이다.
이는 단순히 서버 등의 자원을 제공해 주면서 사용자가 디바이스에 제약없이 데이터에 접근할 수 있도록 해준다.
PaaS(Platform as a Service)
PaaS 벤더들은 응용 프로그램 개발자들에게 개발 환경을 제공한다. 제공자는 일반적으로 개발을 위한 툴킷과 표준, 그리고 배포 및 지불을 위한 채널을 개발한다.
PaaS 모델에서 클라우드 제공자들은 일반적으로 운영 체제, 프로그래밍 언어 실행 환경, 데이터베이스, 웹 서버를 포함한 컴퓨팅 플랫폼을 배급한다.
응용 프로그램 개발자들은 기반 하드웨어 및 소프트웨어 계층을 구매하고 관리하는 비용이나 복잡성 없이도 자신들의 소프트웨어 솔루션을 클라우드 플랫폼에서 개발, 실행할 수 있다.
마이크로소프트 애저, 구글 앱 엔진과 같은 일부 PaaS에서 기반이 되는 컴퓨터, 스토리지 자원은 응용 프로그램 수요에 맞추기 위해 자동으로 규모를 조정하며 이로써 클라우드 사용자는 자원을 수동으로 할당하지 않아도 된다.
사용자(개발자)가 소프트웨어 개발을 할 수 있는 환경을 제공해 주는 PaaS의 예로, 구글의 APP 엔진, Heroku 등이 대표적인 예다.
SaaS (Software as a Service)
SaaS 모델에서 사용자들은 응용 소프트웨어와 데이터베이스에 대한 접근 권한을 가진다. 클라우드 제공자들은 응용 프로그램을 실행하는 인프라스트럭처와 플랫폼을 관리한다.
SaaS는 “주문형 소프트웨어”(on-demand software)를 가리키기도 하며 가격 정책은 일반적으로 종량제(pay-per-use) 기반이거나 구독 비용 기반이다.
SaaS 모델에서 클라우드 제공자들은 클라우드에 응용 소프트웨어를 설치, 운영하며 클라우드 사용자들은 클라우드 클라이언트의 소프트웨어를 접근한다. 클라우드 사용자들은 이러한 응용 프로그램들이 실행하는 클라우드 인프라스트럭처와 플랫폼을 관리하지 않는다.
이로 말미암아 클라우드 사용자 자신의 컴퓨터에 응용 프로그램을 설치하고 실행할 필요가 없으므로 유지보수와 지원이 단순하게 된다.
클라우드 응용 프로그램들은 확장성 관점에서 다른 응용 프로그램들과 차이가 있는데, 확장성은 변화하는 작업 수요를 충족하기 위해 런타임 중에 태스크들을 여러 개의 가상 머신으로 복제함으로써 수행할 수 있다.
로드 밸런서들은 가상 머신들의 집합을 통해 작업을 분산시킨다. 이 과정은 오직 하나의 단일 액세스 포인트를 바라보는 클라우드 사용자에게는 투명하게 보인다.
수많은 클라우드 사용자들을 수용하기 위해 클라우드 애플리케이션들은 멀티테넌트일 수 있으며,
즉 어떠한 머신이라도 하나 이상의 클라우드 사용자 조직에 서비스를 제공할 수 있다는 것을 뜻한다.
SaaS 애플리케이션의 가격 정책 모델은 사용자 당 월별, 연별 고정 수수료인 것이 보통이므로 특정 지점에서 사용자가 추가되거나 제거되면 가격은 조정될 수 있다. 지지자들은 SaaS가 하드웨어 및 소프트웨어 유지보수 및 지원을 클라우드 제공자에게 위탁함으로써 비즈니스에 드는 IT 운영 비용을 줄일 가능성을 제공한다고 주장한다. 즉, 다른 목표를 충족하기 위해 비즈니스가 하드웨어/소프트웨어 및 인력에 드는 IT 운용 비용을 재할당할 수 있게 한다. 게다가 중앙 관리되는 애플리케이션들을 통해 사용자가 새로운 소프트웨어를 설치하지 않고도 업데이트를 출시할 수 있다. SaaS의 단점은 사용자 데이터를 클라우드 제공자의 서버에 저장하는 점에서 비롯된다. 그 결과 데이터에 대해 인증되지 않은 접근이 있을 가능성이 있다. 이러한 이유로 사용자들은 인텔리전트 서드파티 키 관리 시스템을 채택하여 자신들의 데이터의 보안을 지원한다.
SaaS의 경우, 네이버에서 제공하는 네이버 클라우드, 드롭박스, 구글 문서 등을 예로 들 수 있다.
서버리스 컴퓨팅
클라우드 제공자가 서비스 요청의 필요에 따라 가상 머신을 시작하고 중단하는 일을 온전히 관리하며, 시간 당, 가상 머신 당 개념이 아닌 요청 충족에 필요한 자원의 추상적인 측정에 의해 과금된다.
서버리스 컴퓨팅이라는 이름에도 불구하고 실제로 서버 없는 코드의 실행은 수반되지 않는다.
서버리스 컴퓨팅이라는 이름이 붙여진 이유는 시스템을 소유하는 사업체나 사람이 백엔드 코드를 실행하기 위해 서버나 가상 머신을 구매, 임대, 예비할 필요가 없기 때문이다.
배치 모델
폐쇄형 클라우드
폐쇄형 클라우드(private cloud, 프라이빗 클라우드)는 오직 하나의 단체를 위해서만 운영되는 클라우드 인프라스트럭처의 하나로, 내부적으로나 서드파티에 의해 관리를 받거나 내외부적으로 호스팅된다.
폐쇄형 클라우드 프로젝트를 떠맡을 경우 어느 정도 수준의 비즈니스 환경 가상화가 수반될 필요가 있으며 단체가 기존 자원에 대한 결정사항들을 재평가할 필요가 있다.
잘 마쳤을 때 비즈니스를 개선할 수 있지만 프로젝트의 모든 단계가 심각한 취약점 예방을 해야 하는 보안 문제를 일으킨다. 자체 운영 데이터 센터들은 일반적으로 자본 집약적이다. 공간, 하드웨어, 환경 제어의 할당이 필요한 중대한 물리적 발자취가 있다. 이러한 자산들은 주기적으로 갱신되어야 하며, 그 결과 추가적인 자본 비용이 소요된다. 사용자들이 여전히 이것들을 구매, 빌드, 관리해야 하므로 직접 챙겨야 하는 관리가 덜하다는 데에서부터 이점을 얻는 것이 아니기 때문에 비평을 받았다.
공개형 클라우드
공개형 클라우드(public cloud, 퍼블릭 클라우드)는 공개적 이용을 위해 열린 네트워크를 통해 렌더링되는 클라우드이다. 공개형 클라우드 서비스들은 무료일 수 있다.
기술적으로 공개형과 폐쇄형 클라우드 아키텍처 간 차이가 거의 없거나 아예 없을 수 있으나, 통신이 신뢰되지 않은 네트워크 상에서 영향을 받으면서 대중을 위해 서비스 제공자에 의해 이용 가능하게 된 서비스들마다 보안적으로 고려할 사항이 본질적으로 다를 수 있다.
일반적으로, 네이버클라우드플랫폼, 아마존 웹 서비스(AWS), 마이크로소프트, 구글과 같은 공개형 클라우드 서비스 제공자들은 자신들의 데이터 센터를 소유, 운영하고 있으며 접근은 일반적으로 인터넷을 통한다.
AWS와 마이크로소프트는 각각 “AWS Direct Connect”와 “Azure ExpressRoute”라는 직접 연결 서비스들을 제공하며,
이러한 연결은 클라우드 제공자가 제공하는 피어링 포인트에 대한 폐쇄형 연결의 구매나 임대를 고객에게 요구한다.
혼합형 클라우드
혼합형 클라우드(hybrid cloud, 하이브리드 클라우드)는 뚜렷한 실체는 유지하지만 함께 묶여있는 둘 이상의 클라우드(폐쇄형, 커뮤니티, 또는 공개형)의 조합으로, 여러 개의 배치 모델들의 이점을 제공한다.
혼합형 클라우드는 병설(collocation), 매니지드 및 데디케이티드 서비스를 클라우드 자원과 연결하는 기능을 의미할 수도 있다.
가트너는 혼합형 클라우드를 다른 서비스 제공자들로부터 제공되는 폐쇄형, 공개형, 커뮤니티 클라우드 서비스들이 어느 정도 복합된 하나의 클라우드 컴퓨팅 서비스로 정의한다.
혼합형 클라우드 서비스는 격리 부분과 제공자 간 경계를 교차하므로 단순히 폐쇄형, 공개형, 커뮤니티 클라우드 서비스 중 하나의 분류에 집어넣을 수 없다. 다른 클라우드 서비스와의 애그리게이션, 연동, 커스터마이즈를 통해 클라우드 서비스의 용적의 확장을 허용한다.
Reference
https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C_%EC%BB%B4%ED%93%A8%ED%8C%85
Touch background to close