h._.yun.log

Running Containers on Amazon Elastic Kubernetes Service(Amazon EKS) - 2

Mon, 10 Nov 2025 15:19:57 GMT

모듈 4 : Amazon EKS 클러스터에 애플리케이션 배포

애플리케이션 배포 방법

Amazon EKS 내에서 애플리케이션 Deployment를 확장 가능한 솔루션으로 만들기 위해선 3단계를 완료해야 한다.
1. 추가 컨테이너 배포를 위해 관리하고 있는 사용할 수 있는 이미지 리포지토리 설정
2. 애플리케이션을 일관되게 배포하고 배포 오류를 줄이며 롤백을 활성화할 수 있는 패키지 관리자 또는 애플리케이션 배포 도구를 선택
3. 지속적 통합(CI) 및 지속적 관리(CD) 파이프라인을 자동화
  Amazon EKS 애플리케이션 배포 자동화를 위한 도구 선택
컨테이너 이미지 리포지토리에는 Amazon Elastic Container Registry(ECR)를, 패키지 관리자에는 Helm을, CI/CD 파이프라인 자동화에는 AWS CodePipeline 또는 ArgoCD 또는 GitOps 을 사용한다.
Amazon ECR 사용
개발자가 코드를 변경후 코드 리포지토리에 올리는 것처럼 컨테이너 이미지를 중앙에서 저장하고 제공 할 수 있는 방법이 필요하다.
컨테이너 이미지는 컨테이너 이미지의 신뢰할 수 있는 정보 소스가 된다. 이는 개발 또는 프로덕션 환경에 컨테이너식 애플리케이션을 배포하는데 중심적인 역할을 제공한다.
이점은 어디서든 동일한 코드를 실행할 수 있으면서도 코드가 모든 대상 환경에서 실행될 것을 확신한다.
- 컨테이너 이미지가 개발자 워크스테이션에서 이미지 레지스트리로 이동, kubelet을 이용해 컨테이너 런타임에게 컨테이너 이미지를 가져오도록 지시하는 과정이다. 최종적으로 Pod에서 컨테이너가 실행된다.
- 이과정이 CI/CD 자동화 파이프라인의 일부분이다.
  컨테이너 이미지 저장
컨테이너 이미지를 레지스터리(ECR)에 저장할 때 퍼블릭과 프라이빗 중에서 선택할 수 있다.
퍼블릭 리포지토리의 기본 목적은 컨테이너 이미지를 누구와도 공유하는 것, 오픈 소스 소프트웨어를 위한 커뮤니티 참여를 높이는 것이 목적이라면 퍼블릭 리포지토리가 좋은 방법이다.
프라이빗 리포지토리는 일반적으로 조직의 보안 및 규정 준수 요구 사항을 충족하기 위한 옵션이 존재한다. 즉, 이미지에 대한 액세스를 권한이 있는 사용자로 제한 할 수 있다.
Helm을 사용하여 애플리케이션 배포
Helm은 kubernetes의 패키지 관리자이다. kubernetes 클러스터에 애플리케이션을 설치하고 관리하는 데 도움이 된다.
일반적인 Helm 작업
애플리케이션 설치*

localhost에 Amazon EKS 차트 리포지토리를 추가한다.
설치할 애플리케이션을 검색한다.
애플리케이션을 설치한다.

** 설치된 애플리케이션 업그레이드 **

업그레이드 실행한다.
필요한 경우 롤백한다.

** 애플리케이션 게시**

새 차트를 생성한다.
샘플 파일을 삭제한다.
새 chart.yaml 파일을 생성한다.
deployment 및 service manifest를 위한 디렉터리를 생성한다.
manifest를 복사한다.
템플릿을 테스트한다.
차트를 배포한다.
Helm 차트

Helm 차트는 애플리케이션을 설명하고, 반복 가능한 애플리케이션 설치 지침을 제공하며, 단일 인증 원본 역할을 수행한다.
차트를 사용하면 애플리케이션을 더 쉽게 설치, 업그레이드 또는 제거할 수 있다.
차트는 파일 자체가 아니라 helm에 애플리케이션 설치 방법을 알려주는 특정 하위 디렉터리와 파일을 포함하는 디렉토리이다.
기본 차트 예시
- charts/ : 차트가 종속된 모든 차트가 포함된 디렉터리
- Chart.yaml : 차트에 대한 정보가 들어있는 yaml 파일
- README.md : 사람이 읽을 수 있는 README 파일(선택사항)
- values.yaml : 차트의 기본 구성 값, templates 디렉터리의 manifest는 이 파일에서 값을 가져오므로 mainfest 템필릿을 지속적으로 업데이트할 필요가 없다.
- templates/ : values의 값과 결하되면 유효한 kubernetes manifest 파일을 생성하는 템플릿의 디렉터리이다.
  Helm 차트 액세스
Helm 차트 패키지는 차트 리포지토리에 저장된다. helm 클라이언트를 다양한 차트 리포지토리에서 검색 및 배포하도록 구성할 수 있다.
- Artifact Hub
  - 개발자가 자시의 차트 리포지토리를 다른 개발자에게 공개할수 있는 퍼블릭 Helm 차트 리포지토리의 중앙 목록이다.
  - 필요한 대부분의 오픈소스 애플리케이션 차트를 이곳에서 검색하고 helm repo add 명령어로 추가하여 사용할 수 있다.
- Amazon ECR
  - 도커 이미지를 저장하는 것처럼 Helm 차트도 OCI(Open Container Initative) 형식으로 저장할 수 있는 프라이빗(Private) 리포지토리입니다.
  - 보안이 중요하고, 컨테이너 이미지와 차트의 버전과 함께 관리하고 싶을 때 사용된다.
- Amazon S3
  - 정적 파일을 호스팅하는 기능을 이용해 전통적인 방식의 Helm 리포지토리를 구축하는 방법이다.
  - index.yaml 파일과 차트 패키지(.tgz)를 S3 버킷에 업로드하여 구성하며, 간단한 프라이빗 리포지토리를 만들 때 여전히 유용한 옵션이다.
    실습 2 : Helm 및 Amazon S3를 사용하여 애플리케이션 배포
Amazon S3를 helm 리포지토리로 구성
S3 Helm 리포지토리에 차트를 패키징 및 로드
Helm를 사용하여 애플리케이션 배포
차트 및 values.yaml 파일 검토

Helm을 설치하고 Amazon S3 버킷을 Helm 리포지토리로 생성
Helm을 설치하고 Amazon S3 버킷을 Helm 리포지토리로 구성한다.
Helm을 사용하여 Kubernetes 애플리케이션을 Helm 차트라는 재사용 가능한 번들로 패키징 할 수 있다. 차트는 Pod, 서비스, 수신 등 앱이 실행하는 데 필요한 모든 리소스를 정의한다.
환경 간 공유 및 재사용을 위해 차트를 Helm 차트 리포지토리에 저장한다. Helm-s3 플러그 인을 사용하면 S3 버킷을 차트 리포지토리로 사용할 수 있다.
Amazon S3를 Helm 리포지토리로 사용하면 다음과 같은 여러 이점이 존재한다.
- Amazon S3는 보안, 내구성 및 확장성이 뛰어난 객체 스토리지를 제공한다. Helm 차트 패키지 저장소로 이상적이다.
- Amazon S3는 차트를 구성하고, 권한을 관리하고, 백업을 생성하는 데 유용하다.
- S3 버킷에 대한 액세스 권한이 있는 모든 환경에서 차트에 액세스할 수 있다.
- S3의 버전 관리 기능은 경시적으로 차트 변경 사항을 추적하는 데 도움이 된다.
bastion server 인스턴스에 접속 후 helm을 설치 : curl -sSL https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
helm 설치 유무 확인 : helm version
helm 플러그인 설치 : helm plugin install https://github.com/hypnoglow/helm-s3.git
호스팅된 Helm 리포지토리를 위한 Amazon S3 버킷이 미리 생성되었으며 해당 이름이 환경 변수로 배스천 호스트에 저장되어 있다. 이 버킷을 Helm 리포지토리로 초기화한다.

echo "Configuring $S3_BUCKET_NAME as a private Helm repository..." helm s3 init s3://$S3_BUCKET_NAME
index.yaml 파일이 포함되어 있는지 확인하여 Helm 리포지토리가 초기화 확인 : aws s3 ls $S3_BUCKET_NAME
버킷을 Helm 클라이언트용 차트 리포지토리로 추가 : helm repo add productcatalog s3://$S3_BUCKET_NAME

제품 카탈로그 차트를 패키징하고 Amazon S3로 푸시
샘플 애플리케이션을 Helm 차트로 패키징하고 앞서 생성한 Amazon S3 리포지토리에 푸시

먼저 GitHub에서 애플리케이션 코드를 복제한다. 해당 코드에는 애플리케이션 배포하는데 필요한 kubernetes 리소스 manifest가 포함되어있다.
Helm CLI를 사용하여 해당 리소스를 단일 helm 차트 아카이브로 패키징한다.
이 후 애플리케이션을 재사용 간으한 형식으로 실행하는 데 필요한 모든 것이 번들로 제공된다.

helm package 명령은 차트 파일을 버전이 지정된 .tgz 파일로 압축한다. 차트 번호는 차트에 포함된 Chart.yaml 파일에서 가져온다.
차트패키징을 할 경우 아래 경우에 유용하게 사용된다.
- S3 버킷과 같은 Helm 차트 리포지토리에서 차트를 공유
- 단일 Helm instal 명령으로 패키징된 차트를 설치
- 환경 간에 업데이트 및 롤백을 관리
helm 리포지토리 목록을 확인해보자. helm repo list
AWS 기반 컨테이너 Github 페이지에서 애플리케이션 Helm 차트를 복제 수행 : git clone https://github.com/aws-containers/eks-app-mesh-polyglot-demo.git
Helm 차트 디렉터리의 구조 및 그 안에 포함된 파일을 확인

cd eks-app-mesh-polyglot-demo/workshop printf "The chart contains the following directory structure and files...\n \n" && tree helm-chart/
- 차트는 디렉터리 내부 파일 모음으로 구성되어 있다.
  - Chart.yaml : 차트에 대한 정보가 들어 있는 YAML 파일
  - productcatalog_workshop-1.0.0.tgz: Kubernetes 클러스터에 적용할 수 있는 버전이 지정된 차트 아카이브
  - security/: Pod 보안 그룹에 대한 매니페스트가 포함된 디렉터리
  - templates/: 값과 결합되면 유효한 Kubernetes 매니페스트 파일을 생성하는 템플릿의 디렉터리
  - templates/NOTES.txt: 선택 사항: 간단한 사용 노트가 포함된 일반 텍스트 파일
  - values.yaml: 기본 구성 값을 정의하는 일련의 YAML 파일
실습에 필요한 모든 이미지는 미리 빌드되어 있다. 공개 ECR에서 가져오는 대신 다음 명령을 실행하여 이미지 경로를 업데이트해야한다.

export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export AWS_REGION=$(aws configure get region) sed -i "s|public.ecr.aws/[^/]*/eks-workshop-demo|${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/eks-workshop-demo|g" ./helm-chart/values.yaml
애플리케이션 Helm 차트를 패키징 : helm package helm-chart/
애플리케이션 Helm 차트가 생성되었는지 확인 : ls -ltr
패키징된 애플리케이션 Helm 차트를 S3 Helm 리포지토리로 푸시 : helm s3 push ./productcatalog_workshop-1.0.0.tgz productcatalog
AWS 콘솔 창에서 확인

Amazon S3 리포지토리에서 Helm 차트를 검색 및 설치
이전 단계에서 Amazon S3에 푸시한 Helm 차트를 배포하여 샘플 애플리케이션을 설치

Helm 명령줄 인터페이스(CLI)를 사용하여 S3 Helm 리포지토리에서 특정 차트 버전을 검색
helm install 명령을 사용하여 EKS 클러스터에 차트를 설치
S3에서 차트 패키지를 가져와 애플리케이션을 배포

이 단계를 완료하면 EKS 클러스터의 Pod에서 실행되는 Frontend, Productcatalog 및 Productdetail 서비스가 포함된 샘플 애플리케이션을 얻게 된다.
S3 버킷에 저장된 Helm 차트의 버전 수를 확인 : helm search repo
리소스를 배포하지 않고 차트 설치를 테스트하기 위해 다음 helm install 명령을 –dry-run 플래그와 함께 입력 : helm install productcatalog s3://$S3_BUCKET_NAME/productcatalog_workshop-1.0.0.tgz --version 1.0.0 --dry-run --debug
- productcatalog: 이 설치에 부여하는 릴리스 이름
- s3://$S3_BUCKET_NAME/productcatalog_workshop-1.0.0.tgz: S3 버킷 리포지토리에서 차트 아카이브의 위치를 지정
- --version 1.0.0: 설치할 차트 버전을 1.0.0으로 고정
- --dry--run: Helm에게 차트를 검증하고 실제로 배포하지 않고 리소스 매니페스트를 생성하도록 지시
- --debug: 설치 프로세스에 대한 자세한 디버깅 정보를 출력
Helm 차트를 설치 : helm install productcatalog s3://$S3_BUCKET_NAME/productcatalog_workshop-1.0.0.tgz --version 1.0.0
차트가 배포한 리소스를 나열 : kubectl get pod,svc,deploy -n workshop -o name 차트는 애플리케이션의 frontend, productcatalog, productdetail 구성 요소를 나타내는 3개의 Pod, 3개의 서비스 및 3개의 배포를 설치

프런트엔드 서비스를 셸 변수에 저장하고 터미널에 출력

FRONTEND_URL=http://$(kubectl get svc -n workshop frontend -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
echo "The URL pointing to the frontend is: $FRONTEND_URL"

출력된 링크 주소를 새 창에서 열면 아래와 같이 나온다.

애플리케이션 Helm 차트 편집 및 재배포
values.yaml 파일을 편집한 다음 Helm 차트 애플리케이션을 업그레이드 한다. 그런 다음 변경 사항을 롤백할 때 어떻게 새 Pod가 배포되고 나중에 종료되는지 관찰한다.
value.yaml 파일을 편집 수행한다. 아래 명령은 values.yaml 파일에서 기존 replicaCount 값을 새 값 3으로 변경한다. 이 새로운 Helm 차트가 배포되면 애플리케이션은 추가 Pod 복제본을 생성한다.
```
cd /home/ssm-user/eks-app-mesh-polyglot-demo/workshop/helm-chart
sed -i "s/replicaCount:.*/replicaCount: 3/g" values.yaml
```
업데이트된 Helm 값을 사용하여 애플리케이션을 구성 : helm upgrade productcatalog /home/ssm-user/eks-app-mesh-polyglot-demo/workshop/helm-chart/버전이 업데이트 된것을 확인 가능하다.
현재 동작하는 파드를 확인해본다. : kubectl get pod -n workshop 각 파드의 수가 3개씩으로 증가한것을 볼 수 있다.
다시 변경 사항을 롤백 하고 이전 차트를 다시 적용한다. : helm rollback productcatalog 1 롤백을 통해서 늘어난 파드가 종료되는 것을 다시 볼 수 있다.

모듈 5 : Amazon EKS를 사용하여 대규모 애플리케이션 관리

Amazon EKS에서 수요에 맞게 크기 조정

수평(리소스 수) 및 수직적(리소스 크기) 조정을 통해서 서버의 확장 또는 축소를 수행했다.
기존 서버의 경우 수평적 크기 조정이 가능한 시스템은 수직적 크기 조정만 가능한 시스템보다 성능이 뛰어난 경우가 많았다.
클라우드 컴퓨팅과 kubernetes에서는 그렇지는 않다. kubernetes에는 수직 및 수평으로 크기를 조정할 수 있는 메커니즘이 존재한다.
수평적으로 확장시키는 방법으로는 Pod의 수를 늘리는 방법이 존재하고, 수직적으로 확장시키는 경우에는 Pod의 크기(할당된 CPU 및 메모리 리소스)를 늘린다.
kubernetes 자동 크기 조정
kubernetes 지표는 수요 변동에 대응하는 자동 크기 조정에 필요한 데이터를 제공한다.
Horizontal Pod Autoscaler(HPA)는 Pod 수를 확장하거나 축소한다. 기본적으로 HPA는 kubernetes 지표 서버의 지표를 사용한다. 이 지표 서버는 CPU 및 RAM과 같은 컴퓨팅 리소스를 모니터링 한다.
Vertical Pod Autoscaler(VPA)는 Pod에 사용 할 수 있는 리소스 수를 조절한다. VPA는 kubernetes 지표 서버 및 Prometheus 지표의 지표를 사용한다.
Cluser Autoscaler(CA)는 클러스터의 현재 상태에 대해 수집한 지표를 기반으로 클러스터의 노드 수를 확장하거나 축소 한다.
karpenter는 CA와 달리 Auto Scaling Group(ASG)에 의존하지 않고 직접 EC2 인스턴스를 프로비저닝한다.
Horizontal Pod Autoscaler(HPA)
컨테이너 사용의 이점 중 하나는 애플리케이션을 빠르게 자동으로 크기 조정할 수 있다는 점이다.
많은 워크로드의 경우 인바운드 연결 요청 또는 작업 대기열 길이와 같은 사용자 정의 지표를 기반으로 애플리케이션 크기 조정을 정의할 수 있는 것이 중요하다.
HPA는 다음을 수행하여 서비스를 개선한다.
- 과도한 수의 Pod로 인해 낭비될 수 있는 하드웨어 리소스를 해제한다.
- 서비스 수준 계약을 달성하기 위해 필요에 따라 성능을 높이거나 낮출 수 있다.
위의 예시는 HPA가 생성될 때 50%의 CPU 비율이 지정되어 있다. CPU 사용량이 할당된 컨테이너 리소스의 50%를 초과하면 HPA는 지정된 최소값(3)에서 구성된 최댓값(10)으로 스케일-아웃 한다.이는 CPU 평균이 목표(50%)보다 낮아질 때까지 스케일-아웃한다. 로드가 감소하면 Amazon EKS는 최종적으로 최소 개수까지 Pod 수를 감소한다.
CPU 비율 이외에도 메모리에 따라 크기를 조정하도록 구성가능하다. CPU 를 memory로 변경하면 된다.
Vertical Pod Autoscaler(VPA)
kubernetes Vertical Pod Autoscaler는 Pod에 예약된 CPU 및 메모리를 자동으로 조정하여 애플리케이션의 크기를 적절히 조정하도록 지원한다. 이를 통해 클러스터 리소스 사용률을 개선하고 다른 Pod를 위한 CPU 및 메모리를 확보 할 수 있다.
아래는 VPA를 사용하는 예이다.
- Pod가 스케줄링 되기를 기다리고 있다. Pod가 실행되지 못하는 이유는 Pod에 수용할 CPU 리소스가 부족하기 때문이다. 현재 노드 0,1은 각각 요청 600m 씩 예약되어있기 때문에 dbAPP 요청을 처리할 수가 없다.
- 여기서 노드 1은 사용량이 200m 이기 때문에 kubernetes VPA는 실제 사용률에 맞춰서 WebApp 리소스 스케줄링을 수행한다. 리소스 스케줄링을 조정하려면 Pod를 제거하고 다시 스케줄링해야한다.
- 이제 dbApp Pod가 노드 1에서 실행 중이다.
  VPA 구성요소
VPA는 kubernetes 클러스터에서 3개의 pod를 배포한다.
- Recommender : 현재 및 과거 리소스 소비를 모니터링하고 컨테이너의 CPU 및 메모리 요청에 대한 권장 값을 제공
- Updater : 올바른 리소스 세트가 있는 관리형 Pod를 확인, 리소스가 잘못 할당된 pod를 종료하여 컨트롤러가 업데이트된 요청으로 다시 생성할 수 있도록 한다.
- Admission Plugin : 방금 생성되었거나 updater의 활동으로 인해 컨트롤러에 의해 다시 생성된 새 Pod에 올바른 리소스 요청을 설정한다.
  VPA 고려 사항
Off(권장 사항 전용)
- 권장되는 Pod 크기만 게시하며 실제로는 아무것도 변경되지 않는다.
- 권장 사항 전용 모드로 시작(kubectl get vpa myvpa --output yaml)
Initial(초기화 전용)
- Pod가 생성될 때만 Pod의 크기를 조정한다.
Auto
- 기존 Pod를 재싲가하여 Pod 크기를 조정한다.
- 자동 모드 사용시 Pod 중단 예산 정의
고려사항
- VPA에서 최소 및 최대 컨테이너 크기 설정
- VPA는 컨트롤러에서 실행되는 Pod를 제거하기도 한다. 이러한 Pod의 경우 자동 모드는 현재 초기화 모드와 동일하다.
- CPU 또는 메모리의 HPA와 함께 VPA를 사용하지 않는 것을 권장한다. 그러나 사용자 정의 및 외부 지표에는 HPA와 함께 VPA를 사용할 수 있다.
- VPA는 대부분의 메모리 부족 이벤트에서 반응하지만 모든 상황에서 그런 것은 아니다.
- VPA 성능은 대규모 클러스터에서 테스트되지 않는다.
- VPA 권장 사항이 사용 가능한 리소스 (예: 노드 크기, 사용 가능한 크기, 사용 가능한 할당량)를 초과하여 Pod가 보류될 수도 있다. 이 문제는 Cluster Autoscaler와 함께 Vertical Pod Autoscaler를 사용하여 부분적으로 해결할 수 있다.
- 동일한 Pod와 일치하는 여러 VPA 리소스에 정의되지 않는 동작이 있다.
  Cluster Autoscaler 및 Amazon EKS
Kubernetes Cluster Autoscaler는 클러스터를 분석하고 노드 수를 자동으로 조정한다.
리소스 부족으로 인해 현재 노드에서 스케줄링할 수 없는 Pod가 있는 경우 Cluster Autoscaler는 더 많은 노드를 추가하도록 요청한다.
만일 많은 시간 동안, 잉여자원의 노드가 있는 경우 Cluster Autoscaler는 노드 그룹을 축소하도록 요청한다.
Amazon EKS에서 Cluster Autoscaler는 EC2 Auto scaling 글부을 사용하여 확장하거나 축소한다.
Karpenter
AWS에서 관리하는 오픈 소스 Cluster Autoscaler이다.
Karpenter는 스케줄링 불가능 Pod를 처리하기 위해 노드를 추가하고, 해당 노드에서 pod를 스케줄링하고, 필요하지 않는 노드를 제거한다.
Karpenter는 kubernetes 프로젝트의 Cluster Autoscaler와 유사하게 작동한다. 하지만, Karpenter는 기존 Auto Scaling 그룹의 다른 노드를 사용하는 대신 적정 규모의 컴퓨팅 리소스를 시작한다. 쉽게 말하자면, Cluster Autoscaler는 사전에 미리 정의 된 그룹(Auto scaling)를 통해서 스케일링을 하는 방식인 반면, Karpenter는 리소스를 분석하고 필요한 만큼만 제공해준다고 생각하면 된다.
하지만, 필요한 조건이 프로비저닝의 제약 조건을 벗어나는 경우 Pod는 스케줄링되지 않는 상태로 유지된다.

Amazon EKS에 지속적 배포

어플리케이션을 배포하기 위해서는 6단계 과정(코딩, 빌드, 테스트, 프로비저닝, 배포, 모니터링)을 거쳐야 한다.

release process (CI/CD)

지속적 통합(CI)를 사용하면 개발자는 Git과 같은 버전 관리 시스템을 사용하여 공유 리포지토리에 커밋하는 경우가 많다. 각 커밋 전 개발자는 통합하기 전에 추가 검증 계층으로 코드에서 로컬 단위 테스트를 실행 할 수 있다.
지속적 통합 서비스는 새로운 코드 변경사항에 대한 단위 테스트를 자동으로 구축하고 실행하여 모든 오류를 즉시 표시한다.
지속적 전달과 지속적 배포 차이
지속적 전달과 지속적 배포의 차이점은 프롣거션 업데이트에 대한 수동 승인의 존재 여부이다.
지속적 배포의 경우 명시적 승인 없이 프로덕션으로 자동 업데이트 된다. 지속적 전달은 전체 소프트웨어 릴리스 프로세스를 자동화한다. 커밋되는 모든 개정 버전은 업데이트를 빌드, 테스트, 단계별로 진행하는 자동화된 흐름을 시작한다. 개발자는 라이브 프롣거션 환경에 배포하는 최종 결정을 수행한다.
CI/CD 도구
kubernetes 환경에서는 DevOps 방법론과 CI/CD 파이프라인을 사용하는 것이 일반적이다.
아래는 일반적으로 사용되는 CI/CD 제품들이다.
AWS 서비스를 사용한 지속적 배포
위 예시는 다른 AWS 서비스와 Amazon EKS를 통합한 예시이다. kubernets와 AWS를 함께 사용하여 컨테이너 기반 애플리케이션용 오나전관리형 지속적 배포 파이프라인을 생성한다.
이 접근 방식에서는 AWS 개발자 도구를 활용하여 소스 코드, 빌드, 파이프라인을 관리한다.

Commit: 개발자가 코드를 Git 리포지토리에 커밋한다.
Build: CodePipeline이 변경을 감지하고 CodeBuild를 실행한다. CodeBuild는 코드를 빌드하고 테스트하며 컨테이너 이미지를 생성한다.
Push to ECR: 빌드된 이미지를 Amazon ECR에 푸시한다.
Deploy: CodeBuild가 kubectl이나 Helm 같은 도구를 사용하여 ECR에 있는 최신 이미지를 참조하도록 Kubernetes 매니페스트를 업데이트하고 EKS 클러스터에 직접 배포를 수행한다.
Result: 업데이트된 애플리케이션이 Amazon EKS에서 실행한다.

Amazon EKS 지속적 배포 파이프라인

이 다이어그램은 애플리케이션 코드의 라이프사이클과 인프라 구성 코드의 라이프사이클을 분리한 이중 파이프라인 모델이다.
이 파이프라인을 통해 애플리케이션 개발자는 애플리케이션이 실행될 인프라에 대한 걱정 없이 코드 작성에 집중할 수 있다.
개발자 파이프라인
1. Commit: 개발자가 애플리케이션 코드를 Git 리포지토리에 푸시
2. Build: AWS CodeBuild가 코드를 가져와 유닛 테스트를 실행하고, Dockerfile을 사용해 컨테이너 이미지를 빌드
3. Push to ECR: 빌드가 성공하면, 생성된 컨테이너 이미지는 버전 태그와 함께 Amazon ECR(Elastic Container Registry)에 저장한다.이로써 애플리케이션의 '실행 파일' 준비는 마쳤다.
DevOps 엔지니어 파이프라인
1. Commit: DevOps 엔지니어가 쿠버네티스 배포 방법을 정의하는 Helm 차트를 Git 리포지토리에 푸시
2. Test Chart: AWS CodeBuild가 차트를 가져와 helm lint (문법 검사), kubeval (쿠버네티스 정책 검사) 등의 테스트를 통해 차트의 정합성을 검증
3. Push to Helm Repo: 테스트를 통과한 Helm 차트는 버전과 함께 S3 버킷을 기반으로 하는 Helm 리포지토리에 패키징되어 저장된다. 이로써 애플리케이션의 인프라 즉, '설치 설명서' 준비가 끝났다.
*통합 배포 파이프라인 *
1. Trigger: AWS CodePipeline이 ECR과 S3 Helm 리포지토리를 감시하다가, 새로운 이미지나 차트가 등록되면 배포 프로세스를 시작한다.
2. Deploy: CodePipeline은 CodeBuild를 실행시킨다. CodeBuild는 S3에서 최신 Helm 차트를, ECR에서 최신 컨테이너 이미지를 가져온다. 그 후 helm upgrade --install 명령을 통해 EKS 클러스터에 애플리케이션을 배포하거나 업그레이드한다. 이 때 Helm 차트는 "이 컨테이너 이미지를 사용해줘"라고 ECR의 이미지 버전을 참조한다.
  GitOps 및 Amazon EKS
  
  GitOps 원칙
모든 것은 소스 제어에 있다. : 인프라 및 애플리케이션 구성이 전적으로 소스제어에서 표현된다. 소스 제어는 원하는 시스템 상태에 대한 단일 정보 소스이다.
명령적이기보다 선언적 : 설치 명령을 실행하는 대신 원하는 인프라 및 애플리케이션 상태를 설명한다. 즉, '어떻게'는 정의하지 않고'무엇을' 원하는지에 대한 최종 결과물 만 정의한다.
승인된 변경 사항을 자동으로 적용 : 원하는 상태로 지속적으로 수렴한다.
일관된 상태를 보장하기 위한 소프트웨어 에이전트 : Argo 또는 Flux와 같은 소프트웨어 에이전트는 클러스터에서 실행중인 애플리케이션의 원하는 상태가 Git 리포지토리에 저장된 것과 일치하는지 확인하기 위해 자동으로 수정 조치를 취할 수 있다.
Push vs. Pull 모델 비교
- 기존 CI/CD (Push 방식): Jenkins나 GitLab CI 같은 CI/CD 서버가 테스트 완료 후 kubectl apply 같은 명령어를 직접 실행하여 변경 사항을 클러스터에 밀어 넣는다(Push). CI/CD 서버가 클러스터에 접근할 수 있는 강력한 권한을 가져야 한다.
- GitOps (Pull 방식): 클러스터 내부에 있는 Argo CD 같은 에이전트가 Git 리포지토리의 변경 사항을 가져와서(Pull) 스스로 상태를 업데이트한다. 외부 시스템이 클러스터에 직접 접근할 필요가 없어 보안적으로 더 안전하다.
  Git
인프라 및 애플리케이션 코드에 대한 전체 변경 내역을 추적한다.
하나의 진입점에서 하나의 파이프라인으로 변경 사항을 강제로 적용하면 변경사항을 제어하기 더 쉽다. 승인된 pull 요청과 필수 보안 테스트를 요구하면 파이프라인이 유일한 통로인 DevSecOps 환경이 조성된다.

GitOps 예시 : Amazon EKS 및 Argo CD
앞의 이중 파이프라인과의 차이점은 명령적이 아닌 선언적이라는 것이다. 일련의 명령을 실행하는 대신 GitOps 환경은 Git 기반 리포지토리에서 애플리케이션 및 지원 코드형 인프라의 원하는 상태를 유지한다.
Amazon EKS 클러스터에서 실행되는 애플리케이션의 상태 또는 Amazon EKS 클러스터의 상태가 Git에서 원하는 상태와 다르다고 가정해본다. 이 상태를 구성 드리프트라 한다.
일반적으로 구성 드리프트를 수정하기 위해서는 수동 작업이 필요하다. 하지만 GitOps 환경에서는 구성 드리프트가 자동으로 수정된다.
이번 예시에서는 Argo를 사용해 Git를 지속적으로 모니터링하여 변경사항을 감지하게 한다. 변경사항이 발견되면 ArgoCD는 Amazon EKS 클러스터에서 kubernets 객체를 업데이트 한다.
ArgoCD는 기존 CI/CD 파이프라인에 비해 몇 가지 이점이 존재한다.
- 보안이 뛰어나다. 클러스터에서 실행되는 kubernetes 컨트롤러(Argo)가 배포를 처리하기 때문이다. 클러스터에 컨트롤러가 있으면 CI 도구에 클러스터 API 자격증명을 제공할 필요가 없다.
- 문제로부터 복구하기 쉽다. 클러스터의 일부 또는 전부에 장애가 발생하여 손상이 일어날 경우 클러스터의 올바른 상태가 Git에 저장되어있기 때문에 기존 파이프라인보다 복구하기 쉽다.
다음은 위 예시의 파이프라인이다.
1. 애플리케이션 개발자는 새 버전의 코드를 Git 리포지토리에 push 하고, 이미지에 태그를 지정한다.
2. 단위 테스트를 실행하는 Jenkins 파이프라인이 트리거되고, 테스트 성공시 자동으로 이미지를 Amazon ECR에 Push하고 kubernets 관리자에게 알린다.
3. 동시에 Jenkins는 이미지 태그를 kubernetes 관리자가 관리하고 있는 매니패스트 리포지토리에 업데이트한다.
4. ArgoCD는 kubenetes 매니패스트 리포지토리를 지속적으로 모니터링하여 변경 사항을 찾는다.
5. 변경 사항이 발견되면 ArgoCD는 kubernets API 서버를 업데이트 한다. 이제 새 버전을 클러스터에 배포하는 프로세스가 시작된다.
기존 CI/CD 파이프라인과 GitOps의 차이점은 배포 단계에 있다. 전통적인 방식이 CI 서버에서 클러스터로 '어떻게' 배포할지 직접 명령(Push) 하는 반면, GitOps는 Git에 '무엇을' 원하는지 최종 상태를 선언하고 클러스터가 이를 스스로 당겨와(Pull) 동기화 한다.

실습 3 : 지속적 배포 및 GitOps

실습 환경
실습 3에서는 2개의 파이프라인을 생성한다. 한 파이프라인은 Git 리포지토리, Jeknins 및 Amazon ECR를 사용하여 컨테이너 이미지를 빌드하고 저장한다. 또 다른 파이프라인은 다른 Git 리포지토리, Argo CD 및 Amazon EKS를 사용하여 컨테이너 이미지를 Amazon EKS 클러스터에 지속적으로 배포한다.
실습에 사용되는 주요 리소스
- AWS CodeCommit : 클라우드에서 자산(문서, 소스 코드, 바이너리 파일 등)을 비공개로 저장하고 관리하는 데 사용할 수 있는 Amazon Web Services(AWS)의 버전 제어 서비스
- Amazon ECR : 안전하고, 확장 가능하며, 신뢰할 수 있는 AWS 관리형 컨테이너 이미지 레지스터리 서비스
- AMazon EKS : AWS에서 자체 kubernets 제어 영역을 설치, 운영, 유지 관리할 필요가 없는 관리형 서비스
  과제 1 : CodeCommit 리포지토리 생성
CodeCommit 을 검색하여 2개의 레포지토리를 생성한다.
- 1번째 리포지토리(AppCodeRepo) : Dockerfile, Jenkinsfile 및 애플리케이션 코드
- 2번째 리포지토리(ManifestRepo) : Argo가 Amazon EKS에 배포하는 Kubernetes 매니패스트 파일 저장

과제 2 : 실습용 배스천 호스트에 연결하고 AWS CodeCommit 및 Amazon ECR 연결을 위한 SSH 키 검토

과제에 미리 생성되어 있는 bastion host 인스턴스에 접속 후 SSH 키 검토 수행 : aws iam list-ssh-public-keys --user-name gitUser

키를 셸 변수에 저장

 KEYID=$(aws iam list-ssh-public-keys --user-name gitUser | jq -r '.[] | .[] | .SSHPublicKeyId')
 echo $KEYID

해당 keyid는 따로 저장해놓자.

퍼블릭 키와 프라이빗 키를 연결하는 SSH 구성 파일 검토 : cat ~/.ssh/config
프라이빗 키 확인 : cat ~/.ssh/id_rsa
- 해당 키 전문도 따로 저장 해놓자.
AWS CodeCommit에 인증할 수 있는지 확인하기 위해 다음 명령을 입력한다. 참고로 환경변수는 미리 설정되어 있다. : ssh git-codecommit.$AWS_REGION.amazonaws.com
ecrUser에 할당된 액세스 키를 확인 : aws iam list-access-keys --user-name ecrUser

과제 3 : 애플리케이션 코드를 검토한 후 AWS CodeCommit 리포지토리에 푸시
코드 검토를 위해 해당 디렉토리로 이동 : cd ~/appcode && ls
- Dockerfile: 샘플 애플리케이션에 대한 컨테이너 이미지를 생성하는 데 사용되는 명령을 나열하는 파일
- Dockerfile-Final: 샘플 애플리케이션에 대한 수정된 컨테이너 이미지를 생성하는 데 사용되는 명령을 나열하는 파일
- Jenkinsfile: 초기 Jenkins 파이프라인의 단계를 정의하는 파일
- Jenkinsfile-Final: 최종 Jenkins 파이프라인의 단계를 정의하는 파일
- src: nginx를 사용하는 샘플 Hello World 애플리케이션의 애플리케이션 파일이 포함된 폴더

Jenkinsfile을 본인의 계정 ID 및 AWS 리전으로 업데이트 수행

sed -i "s|ACCOUNTID|${ACCOUNT_ID}|g" Jenkinsfile
sed -i "s|REGION|${AWS_REGION}|g" Jenkinsfile

실습 Git 구성을 업데이트 진행

git config --global user.email "eks@example.com"
git config --global user.name "ekscourse"
git config --global init.defaultBranch main

appcode 디렉토리에서 로컬 Git 리포지토리로 변환 수행 : cd ~/appcode/ && git init
앞서 과제 2번에서 확인한 SSH 키를 사용하여 코드를 AppCodeRepo 리포지토리의 main 브랜치에 푸쉬
```
git add .
git commit -m "initial commit"
git push --set-upstream ssh://git-codecommit.ap-southeast-2.amazonaws.com/v1/repos/AppCodeRepo main
```
- 레포지토리에 코드가 올라간 것을 콘솔창에서 확인
  과제 4 : Jenkins 서버 구성
이번 과제에서는 Jenkins 자동화 서버에 로그인하고 SSH 및 액세스 키를 사용하여 자격 증명을 생성한다. 또한 AppCodeRepo CodeCommit 리포지토리를 모니터링하고 새 코드가 리포지토리에 커밋될 때마다 새 컨테이너 이미지를 빌드하는 파이프라인을 생성한다.
배스천 호스트 세션에서 Jenkins 자격 증명을 검색
- aws secretsmanager get-secret-value --secret-id JenkinsPassword --query SecretString --output text | tr -d '{}' | tr -d '"' | sed 's/:/: /g' | awk -F, '{print $1"\n"$2}'
실습 지침에 존재하는 탐색 패널에 있는 JenkinsServer 주소를 Url 창에 입력 후 해당 ID/password를 입력
Jenkins 사용자에게 자격 증명을 할당하기 위해서 Manage Jenkins 페이지의 Security 세션에서 Credentials를 선택한다.
- 현재 Jenkins에 저장된 자격 증명은 없다.
Credentials 페이지의 Stores scoped to Jenkins 섹션에서 (global) 을 선택 후 2개의 IAM 자격증명을 사용하여 자격 증명을 구성한다.이러한 액세스 관리 접근 방식은 문제 분리 원칙을 따르며 보안 상태를 개선한다. 프로덕션 환경에서는 Jenkinsfile에 적시 사용자 프로비저닝을 구축하여 파이프라인의 보안을 더욱 강화할 수 있다.
- gitUser
- ecrUser

생성 후

자격증명 구성 후 대시보드로 가서 새로운 파이프라인 구축 수행 : [New item]-[pipeline] 선택 후 생성
파이프라인에 대한 소스 제어 관리(SCM)를 구성하기 위해 Build Triggers 세션에서 Poll SCM 선택 매 2시간마다 새로운 커밋을 확인하는 cronjob을 입력(H/2 * * * *)
Pipeline 섹션의 Definition 드롭다운 목록에서 Pipeline script from SCM을 선택, SCM 드롭다운 목록에서 Git을 선택
pipeline이 성공적으로 빌드된다면 아래 사진과 같이 나온다.
ECR 리포지터리에 가서 생성되어있는지 확인해본다. 성공적으로 Push가 되어있음을 확인했다.

과제 5: Kubernetes 매니페스트 파일을 생성하고 AWS CodeCommit 리포지토리에 Push
manifest 디렉토리 생성 : mkdir ~/manifests && cd ~/manifests

매니패스트 파일 작성

cat << EOF > deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: eks-sample-linux-deployment
namespace: eks-sample-app
labels:
  app: eks-sample-linux-app
spec:
replicas: 3
selector:
  matchLabels:
    app: eks-sample-linux-app
template:
  metadata:
    labels:
      app: eks-sample-linux-app
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - amd64
              - arm64
    containers:
    - name: sample
      image: ACCOUNTID.dkr.ecr.REGION.amazonaws.com/eks-gitops-demo:1.0
      imagePullPolicy: IfNotPresent
      ports:
      - containerPort: 80
        name: http
    nodeSelector:
      kubernetes.io/os: linux
EOF

deployment.yaml 파일을 본인의 계정 ID 및 AWS 리전으로 업데이트

sed -i "s|ACCOUNTID|${ACCOUNT_ID}|g" deployment.yaml
sed -i "s|REGION|${AWS_REGION}|g" deployment.yaml

service.yaml 파일 생성

cat << EOF > service.yaml
apiVersion: v1
kind: Service
metadata:
name: eks-sample-linux-service
namespace: eks-sample-app
labels:
 app: eks-sample-linux-app
spec:
type: LoadBalancer
ports:
 - port: 80
   targetPort: 80
   protocol: TCP
selector:
 app: eks-sample-linux-app
EOF

manifests 디렉터리를 로컬 Git 리포지토리로 변환 수행 : cd ~/manifests && git init

앞서 생성한 SSH 키를 사용하고 애플리케이션 코드를 ManifestRepo CodeCommit 리포지토리의 기본 브랜치로 Push

git add .
git commit -m "initial commit"
git push --set-upstream ssh://git-codecommit.$AWS_REGION.amazonaws.com/v1/repos/ManifestRepo main

과제 6: Argo CD 설치 및 AWS CodeCommit 연결 설정

Argo CD를 설치하기 전에 Argo CD 서비스 및 애플리케이션 프로그램 리소스가 상주할 argocd라는 네임스페이스를 생성 : kubectl create namespace argocd
Argo 설치 : kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/951656f08338a0eaf10c0b1d4022056baf4c635c/manifests/install.yaml
API 서버에 액세스하기 위해 argocd-server를 가리키는 로드 밸런서를 배포하여 Argo CD를 외부화 : kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
패치 후 ArgoCD 서버 서비스의 상태 확인 : kubectl get service argocd-server -n argocd
external-ip 에 있는 DNS 주소를 웹 페이지에 입력 수행
admin 계정의 초기 암호는 자동 생성되어 Argo CD 설치 네임스페이스에 있는 argocd-initial-admin-secret이라는 Secret의 password 필드에 일반 텍스트로 저장되어있다. 관리자의 비밀번호를 찾기 위해 다음 명령을 입력한다. : kubectl get secret argocd-initial-admin-secret -n argocd -o yaml | grep -i password && printf "\n"
해당 값을 디코딩 해야 한다. : echo | base64 --decode && echo
이후 admin/[디코딩 값] 을 입력하면 로그인이 성공한다.
Argo CD Applications 페이지의 왼쪽 탐색 창에서 [Settings] - [Project] 탭에서 새로운 프로젝트로 gitops-project 를 만든다. 설명은 자유롭게 작성
[Settings] - [Repository certificates and known hosts] 탭 선택 후 SSH 호스트를 새로 생성한다. 이 때 cat ~/.ssh/known_hosts 으로 나온 값을 입력한다.
[Settings] - [Repository] 탭에서 레포지토리를 연결한다.
- ssh://@git-codecommit..amazonaws.com/v1/repos/ManifestRepo를 입력합니다. 자리 표시자 값을 GitUserSSHKeyID 값으로 바꾸고, 자리 표시자 값을 이 지침 왼쪽에 있는 AWSRegion 값으로 바꾼다.
다시 생성한 gitops-project 에 들어가서 소스 레포지토리 경로를 추가한다.
목적지도 추가 해준다.
클러스터 리소스와 네임스페이스 리소스도 허용해주는 경로 설정

과제 7: Argo CD 애플리케이션 배포 생성 및 탐색
[Application] 탭에서 새로운 어플리케이션을 생성한다.
General 설정은 다음과 같다.
- PRUNE RESOURCES는 Git 리포지토리에 더 이상 지정되지 않은 리소스를 클러스터에서 제거하는 프로세스를 나타낸다. 이는 더 이상 선언된 구성의 일부가 아닌 리소스를 삭제하여 GitOps 리포지토리에 정의된 원하는 상태를 유지하는 데 도움이 된다.
- SELF HEAL은 자동 조정과 관련이 있다. Argo CD는 Git 리포지토리에서 원하는 상태를 지속적으로 모니터링하고, 클러스터의 실제 상태가 원하는 상태를 벗어나면 자가 복구 메커니즘이 변경 사항을 조정 및 적용하여 클러스터를 지정된 구성으로 되돌리려고 시도한다.
어플리케이션의 소스 경로이다.
어플리케이션의 목적지 경로이다.
생성 결과 사진
Applications 페이지에서 새로 생성된 eks-sample-linux-app을 선택하여 Argo CD 애플리케이션에 배포된 리소스를 탐색한다.
- 위 다이어그램은 Argo CD에서 eks-sample-linux-app 애플리케이션에 배포된 리소스를 보여준다.
eks-sample-linux-app 애플리케이션의 구성요소이다.
- 서비스 유형의 eks-sample-linux-service
  - 엔드포인트 유형의 eks-sample-linux-service
  - EndpointSlice 종류의 eks-sample-linux-service-xxxxx
  - 배포 유형의 eks-sample-linux-deployment
  - ReplicaSet 유형의 eks-sample-linux-deployment-xxxxxxxxxx
    - Pod 유형의 eks-sample-linux-deployment-xxxxxxxxxx-xxxxx(3개의 Pod)
배포된 서비스에 접속하기 위해 DNS 주소를 확인 : kubectl get service -n eks-sample-app
접속 확인 사진
클러스터가 자가 복구를 수행하는지 확인하기 위해 임의로 리소스를 삭제해본다. : cd ~/manifests/ && kubectl delete -f . --ignore-not-found=true
리소스를 삭제했음에도 여전히 서비스가 잘 동작되는 것을 확인할 수 있다. 이는 디플로이먼트가 자가 복구했다는 것을 볼수 있다.

과제 8: CI/CD 파이프라인을 통해 애플리케이션 업데이트

Jenkinsfile 및 애플리케이션 코드 업데이트 수행

cd ~/appcode
cp Jenkinsfile-Final Jenkinsfile
cp Dockerfile-Final Dockerfile
cd ~/appcode/src/
cp v2_index.html index.html

Jenkinsfile을 본인의 계정 ID, AWS 리전 및 SSH 키 ID로 업데이트

KEYID=$(aws iam list-ssh-public-keys --user-name gitUser | jq -r '.[] | .[] | .SSHPublicKeyId')
sed -i "s|ACCOUNTID|${ACCOUNT_ID}|g" Jenkinsfile
sed -i "s|REGION|${AWS_REGION}|g" Jenkinsfile
sed -i "s|KEYID|${KEYID}|g" Jenkinsfile

변경사항을 레포지토리에 업데이트

cd ~/appcode/
git commit -a -m "Updated application to version 2.0"
git push

Jenkins에서 빌드 확인
Amazon ECR에서 업데이트된 이미지 태그 확인
Argo CD에서 업데이트된 애플리케이션 배포 확인
업데이트된 서비스 확인

모듈 6 : Amazon EKS에서 네트워킹 관리

Amazon EKS의 통신

분산 컨테이너 오케스트레이션 시스템용 네트워킹 솔루션을 설계할 때는 3가지 통신라인을 고려해야 한다.
- Pod 내부의 컨테이너 간 통신
- 동일한 노드에 있는 pod 또는 다른 노드에 있는 Pod 간 통신
- 클러스터 외부로부터 수신 연결
  Pod 내부의 컨테이너 간 통신
kubernetes는 아래 측면에서 VM이나 물리적 호스트와 동일한 방식으로 Pod를 처리한다.
- 포트 할당
- 네트워킹
- 이름 지정
- 서비스 선택
- 로드 밸런싱
- 애플리케이션 구성
- 컨테이너화되지 않은 워크로드에서 마이그레이션
Pod는 kuberntes의 기본 빌딩 블록이므로 kubernetes는 네트워크의 IP 주소를 각 애플리케이션 컨테이너가 아니라 Pod에 적용한다.
Pod의 컨테이너는 네트워크 네임스페이스를 공유하며 localhosts(127.0.0.1)를 사용하여 서로 통신 할 수 있다. 쉽게 말해, Pod 안에 있는 여러 컨테이너들은 마치 하나의 컴퓨터(또는 VM) 안에서 실행되는 여러 프로세스처럼 서로를 인식하고 통신할 수 있다.

Kubernetes 호스트 내 통신
동일한 Pod 내의 컨테이너는 공유 네트워크 네임스페이스를 통해 통신한다. Pod 간 통신은 Pod가 네트워크 네임스페이스를 공유하지 않기 때문에 다른 방식으로 동작한다.
각 Pod에 네트워크 네임스페이스가 있을 뿐아니라 호스트 노드에도 네트워크 네임스페이스가 존재한다. 각 네트워크 네임스페이스에는 자체 라우팅 테이블이 있다.
각 Pod 네임스페이스와 호스트 네임스페이스는 한쌍의 Linux 가상 이더넷(veth) 디바이스를 통해 연결된다. 각 veth 상은 기본 호스트 네트워크 네임스페이스와 Pod 네트워크 네임스페이스 간에 터널을 생성한다.
아래 예시는 각 자체 veth가 있는 2개의 Pod를 보여준다. Pod A에는 veth0b가 있고, Pod B에는 veth1b가 있다. 노드 네트워크 네임스페이스에 해당 veth가 표시되어 있다. 즉, 노드의 veth0a는 Pod A의 쌍을 이루는 veth0b로 터널링되고, veth1a는 Pod B의 쌍을 이루는 veth1b로 터널링된다.
동일한 Pod에 있는 컨테이너 간 통신은 해당 컨테이너의 적절한 프로세스에 대한 포트 번호 기반 방향에 의존한다. 각 Pod의 기본 경로는 노드 네트워크 네임 스페이스의 해당 veth로 터널링되는 Pod의 veth를 통해 다른 대상 위치(동일한 클러스터의 다른 Pod 또는 다른 위치)로 향하는 트래픽을 전달한다.
실제로는 노드 라우팅 테이블에 있는 대상 위치 'PodA' 'PodB' 는 실제 Pod의 IP 주소로 나타내며, 대상 veth는 이러한 인위적 이름 대신 CNI(Container Network Interface)에 할당된 이름을 사용한다.
Amazon EKS는 kubernetes 용 VPC CNI 플러그인을 통해 AMazon VPC 네트워킹을 kubernetes에 통합 할 수 있다. 즉, 하나의 메인 IP 주소'와 '여러 개의 보조 IP 주소'가 하나의 동일한 네트워크 카드(ENI)에 함께 할당되고, 이 보조 IP들이 각 Pod에 하나씩 나뉘어 할당되는 방식이 된다.

Amazon EKS 호스트 간의 통신
노드 간 통신을 단순화하기 위해 Amazon EKS는 기본적으로 Amazon VPC CNI를 사용한다. 따라서 모든 Pod에는 Amazon VPC에 할당된 라우팅 가능한 실제 IP 주소가 있으며, 다른 Pod, 노드 또는 AWS 서비스와 통신할 수 있다.
기본적으로 모든 Pod는 Amazon EKS 클러스터의 다른 모든 Pod와 통신 할 수 있다.
서브넷, 라우팅 테이블, 보안 그룹, 네트워크 액세스 제어 목록, VPC 엔드포인트, VPC 피어링, 게이트웨이를 포함하여 Amazon VPC 아키텍처는** Amazon EKS 클러스터에 있는 Pod와의 노드 간 통신**에 영향을 미칠 수 있다.
여기에는 다른 Amazon EKS 클러스터, Amazon ECS, Amazon EC2 등이 포함 될 수 있다.
클러스터 설계는 VPC의 서브넷에서 모든 노드 및 Pod 에 충분한 양의 IP 주소를 확보해야 한다.

Pod 수준 보안 개선

Pod 네트워크 통신 보안
기본적으로 kubernetes는 모든 Pod가 제한 없이 서로 통신할 수 있도록 허용한다.
Kubernetes 네트워크 정책을 사용하면 pod 간 트래픽 흐름에 대한 규칙을 정의 및 적용 할 수 있다.
이는 Pod 레이블, 네임스페이스, IP 주소, IP 블록(CIDR 범위), 포트와 같은 다양한 기준에 따라 수신 및 송신 네트워크 트래픽 규칙을 지정하여 클러스터를 세분화하고 보호할 수 있는 가상 방화벽 역할을 수행한다.
Amazon VPC CNI(Container Networking Interface)는 네트워크 정책을 기본 지원하기 때문에 AWS 에서 kubernetes를 실행 할 때 ** 민감한 워크로드를 격리하고 무단 액세스로 부터 보호** 하는 정책을 생성할 수 있다.

Pod 용 보안 그룹
컨테이너식 애플리케이션은 클러스터 내에서 실행되는 다른 서비스뿐만 아니라 Amaozn RDS 또는 Amazon ElastiCache와 같은 외부 AWS 서비스에 액세스해야 하는 경우가 자주 있다.
AWS에서는 서비스 간 네트워크 수준 액세스 제어가 흔히 ** EC2 보안 그룹**을 통해 수행된다.
VPC CNI 플러그인을 사용하면 Pod용 보안 그룹을 통해 단순화 할 수 있다.
Pod 용 보안 그룹을 사용하면 공유 컴퓨팅 리소스에서 다양한 네트워크 보안 요구 사항이 있는 애플리케이션을 실행하여 컴퓨팅 효율성을 향상 시 킬 수 있다.

서비스를 사용한 로드 밸런싱

Kubernetes 서비스 유형
kubernetes 서비스(Service)는 일관된 접근점(Access Point)을 제공하여, 자주 생성되고 사라지며 IP 주소가 바뀌는 Pod들을 안정적으로 연결해 주는 핵심 구성 요소이다.
서비스를 이용하면 복잡한 IP 주소 대신 DNS으로 통신하여 애플리케이션 구성을 단순화 할 수 있다.
kubernetes는 Pod 상태를 추적하고 적절한 Pod로 트래픽을 전송하기 위해 4가지 유형의 서비스를 사용한다.
- ClusterIP : 클러스터 내부에서만 사용
- NodePort : 정적 포트(NodePort)에 있는 각 노드의 IP에 노출되며 :를 요청하여 클러스터 외부에서 액세스 할 수 있다.
- LoadBalancer : 클러스터 제공업체의 로드 밸런서를 이용해 외부적으로 노출된다. 이를 이용해 자동으로 생성되는 NodePort 및 ClusterIP에 모두 연결된다.
- ExternalName : CNAME 레코드를 해당 외부 DNS 이름 값과 함께 반환하여 내부 클러스터 DNS 이름에 매핑한다.
  ClusterIP 서비스
Cluster 서비스는 클러스터 내에서만 액세스 할 수 있다.

Running Containers on Amazon Elastic Kubernetes Service(Amazon EKS) -1

Tue, 22 Jul 2025 06:29:36 GMT

모듈 1 Kubernetes 의 기본 개념

컨테이너의 이점

이동 가능성
- 컨테이너화 플랫폼을 지원하는 모든 운영 체제(OS)에서 컨테이너를 사용 가능하다.
- 서로 다른 종속성과 서로 다른 라이브러리를 가진 여러 애플리케이션 버전을 동시에 실행할수 있다.
클라우드 배포 가능
- 최신 클라우드 플랫폼에서 실행하기 적합
- EC2, Lambda, EKS, ECS 등 ...
확장성
- 원하는 만큼 컨테이너 수를 확장하거나 축소 가능하다.
지속적 배포
- 지속적 배포는 애플리케이션을 자주 자동 배포하는 방법
- 컨테이너는 자동화된 빌드, 테스트, 배포 파이프라인과 통합된다.
- 개발환경과 프로덕션 환경 간 차이릘 최소화 시킬 수 있다.
마이크로 서비스에 적합
- 컨테이너를 사용하면 컨테이너에 장애가 발생할 경우 해당 컨테이너를 종료하고 특정 서비스에 새 컨테이너를 신속하게 시작할 수 있다.
  컨테이너 오케스트레이션
수백 개의 컨테이너가 있는 전체 프로덕션 환경이 존재한다고 가정해본다. 대규모 컨테이너를 직접 관리하는 것은 매우 복잡하고 어려운 환경이다.
컨테이너 오케스트레이션 도구는 컨테이너의 관리,배포, 크기 조정을 자동화하는데 사용되는 도구이다.
kubernetes는 오픈소스이며, 강력하고 역동적인 커뮤니티의 지원을 받는다는 특징이 존재한다. 약자로 k8s 라고 불리기도한다.
k8s는 리눅스 재단 내의 Cloud Native Computing Foundation(CNCF)에서 관리하고 있다.

Kubernets 내부

PodSpec으로 Pod 정의

Pod: 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위이다. 하나 이상의 컨테이너 그룹으로 구성되며, Pod 안의 컨테이너들은 네트워크와 스토리지 같은 리소스를 공유한다.
Pod를 생성하기 위해서 YAML 형식의 매니페시트 파일을 작성한다. 이 파일은 크게 metadata와 spec 으로 구성된다.
- metedata : Pod의 이름, 레이블 등 Pod를 식별하기 위한 정보를 포함
- spec : Pod의 상세 명세를 정의하는 부분이다. Pod 내에서 실행될 컨테이너의 정보, 사용할 볼륨, 재시작 정책 등이 포함된다.

PodSpec의 예시

apiVersion: v1
kind: Pod
metadata:
name: webapp
labels:
  app.kubernetes.io/name: webapp
spec:
containers:
- name: nginx
  image: nginx:1.25.1
  ports:
  - containerPort: 80

Pod : 통신

각 Pod는 쿠버네티스 클러스터 내에서만 통신할 수 있는 고유한 IP 주소를 할당받는다.
Pod는 영구적인 존재가 아니라, 언제든 장애로 인해 사라지고 새로 생성될 수 있는 휘발성(ephemeral) 자원이다.
Pod가 교체되면 할당되었던 IP 주소도 함께 변경된다. 이러한 이유로 Pod의 IP에 직접 접근하는 대신, '서비스(Service)'라는 오브젝트를 통해 Pod에 안정적으로 접근한다.

서비스(Service)

여러 Pod의 논리적 모음과 여기에 액세스하는 수단이다.
사용 가능한 Pod 세트로 지속적으로 업데이트 되며, 각 Pod IP 주소는 통신의 엔드포인트 역할을 한다.
각 서비스에는 ClusterIP라고 하는 고유한 가상 IP 주소가 할당된다.
클라이언트는 서비스의 가상 ClusterIP 주소에 연결되고, 서비스는 통신 요청을 서비스 뒤에 있는 엔드포인트 Pod 중 하나로 변환된다. 이렇게 하면 다른 Pod의 주소를 직접 추적할 필요가 없다.

Kubernets 내부

제어 영역 및 데이터 영역

쿠버네티스 클러스터는 하나 이상의 노드(Node)로 이루어지며, 노드는 역할에 따라 제어 영역(Control Plane)과 데이터 영역(Worker Nodes)으로 나뉜다.
- 제어 영역(Control-Plane) 구성 요소는 클러스터에 관해 스케쥴링과 같은 전역 결정을 내린다.
- 데이터 영역(Work Node)은 컨테이너 애프릴케이션을 실행하는 노드로 구성된다.
  컨트롤러
컨트롤러는 쿠버네티스의 핵심 원칙을 구현하는 요소이다.
제어 루프 (Control Loop): 컨트롤러는 사용자가 정의한 '원하는 상태(Desired State)'와 클러스터의 '현재 상태(Current State)'를 지속적으로 비교하고 감시한다.
만약 두 상태가 다르다면, 컨트롤러는 현재 상태를 원하는 상태와 일치시키기 위한 작업을 수행합니다. 상태가 동일하다면 아무 작업도 하지 않습니다.
제어 영역의 구성 요소
제어 영역은 클러스터를 관리하기 위한 여러 핵심 컴포넌트로 구성된다.
컨트롤러 관리자
- 핵심 kubernets 제어 루프인 컨트롤러를 실행하고 클러스터 이벤트를 감지하고 이에 대응한다.
클라우드 컨트롤러
- AWS, GCP, Azure 등 특정 클라우드 플랫폼과 상호작용하는 컨트롤러를 실행한다.
- 클라우드의 로드밸런서나 스토리지 같은 자원을 쿠버네티스 오브젝트와 연결하는 역할한다.
스케줄러
- 새로 생성된 Pod를 감시하고, 리소스 현황 등 여러 조건을 고려하여 해당 Pod를 실행할 최적의 워커 노드를 찾아 배정한다.
API 서버
- 제어 영역의 프론트엔드(Front-end) 역할을 하며, 클러스터의 모든 내부/외부 통신을 처리하고 검증하는 중심 허브다.
- kubectl, 워커 노드 등 모든 구성 요소는 API 서버를 통해서만 상호작용한다.
etcd
- 제어 영역의 핵심 구성 요소로, 쿠버네티스 클러스터의 모든 설정 데이터와 상태(어떤 Pod가 어느 노드에 있는지 등)를 저장하는 고가용성 분산 키-값 저장소이다.
  데이터 영역
노드는 kubernetes 런타임 환경을 지원한다.
노드는 Pod를 실행하는 데 필요한 서비스를 포함하고,제어 영역 구성 요소에서 관리된다.
컨테이너 런타임
- 노드는 컨테이너 런타임도 실행한다.
- kubernetes는 Docker 엔진 및 containerd와 같은 인기 있는 런타임을 비롯하여 여러 런타임을 지원한다.
kubelet
- 노드에서 실행되는 기본 에이전트
kube-proxy
- 각 노드에는 Pod 외에 네트워킹에 도움이 되는 kube-proxy가 포함된다.
- 호스트에서 네트워크 규칙을 유지 관리하고, 필요할 수 있는 모든 연결을 전달한다.
  제어 영역과 데이터 영역 간 통신
제어 영역과 데이터 영역이 함께 작동할 때 제어 영역 노드는 컨트롤러와 스케줄러를 사용하여 노드의 상태가 원하는 상태가 되도록 한다.
제어 영역과 노드 간의 통신읜 API 서버를 통해 kubelet으로 전달된다.
kubelet은 Pod에 올바른 컨테이너가 실행되도록 하고 그 컨테이너가 정상 상태가 되도록 한다.
kubelet은 다음 활동을 수행한다.
1. (제어 영역의 API 서버 또는 로컬 구성 파일에 의해) 해당 노드에 할당된 Pod를 감시한다.
2. 필요한 볼륨 탑재
3. Secret 다운로드
4. 컨테이너 런타임을 사용하여 Pod의 컨테이너 실행
5. 요청된 컨테이너 활성 프로브 또는 상태 검사 주기적 실행
6. 노드의 상태를 시스템의 나머지 부분에 다시 보고

Pod 스케쥴링

kubernetes 스케줄러를 사용하여 Pod를 스케쥴링 할 수 있다.
스케줄러는 Pod에 필요한 리소스를 확인하고 그 정보를 사용하여 스케쥴링 결정에 영향을 준다. 스케줄러는 필터를 사용하여 pod 배치에 부적격한 노드를 제외한 다음, 체계에 따라 최종 노드를 결정한다.
필터링 : 리소스 요구사항
리소스 필터를 사용하는 경우 스케줄러는 Pod에 필요한 리소스가 어떤 노드에 있는지 고려한다.
여기에는 CPU, 메모리, 디스크 공간, 사용 가능한 포트 등이 포함된다.
limits 파라미터는 Pod가 실행된 후에 리소스에 대한 한도를 정의한다. 실행 중인 컨테이너는 리소스 사용량을 원래 요청량에서 정의된 한도까지 버스트할 수 있다.
컨테이너가 메모리 한도를 초과하면 해당 컨테이너가 실행중인 노드의 Kubelet이 컨테이너를 종료시킨다.
리소스 요구 사항은 컨테이너 레벨에서 정의되므로 모든 컨테이너에 대해 요청된 리소스의 합계에 따라 Pod의 리소스가 정의된다.
필터링 : 토폴로지 - Taint 및 Toleration
볼륨 및 리소스 제약 조건을 충족한 후에는 스케줄러가 pod 배치를 미세조정하도록 설정된 제약 조건을 고려한다.
사용자는 노드 수준과 Pod 수준에서 스케쥴링 제약 조건을 설정할 수 있다.
Taint 및 Toleration 은 특정 노드에 배치할 수 있는 노드를 제어하기 위해 함께 작동하는 설정
Taint
- Taint는 Pod 배치를 방지하는 노드의 속성
- 테인트된 노드는 해당 Taint를 허용하는 Pod만 수락한다.
- 노드를 테인트하려면 키=값 쌍 ex)spot =true 을 지정한 다음, Taint가 고려되는 경우를 정의하는 작업을 추가한다.
Toleration
- Toleration은 Pod가 테인트된 노드에서 실행될 수 있도록 지정해주는 Pod 속성
- Toleration은 특정 Taint와 일치해야 한다.
  스코어링 : 토폴로지-선호도
경우에 따라 Pod가 특정 노드에서 스케쥴링되도록 해야 할수 있다.
Pod에 특정 하드웨어 리소스가 필요하다고 가정해본다. Pod가 특정 노드 또는 인스턴스 유형에서 실행되도록 하려면 선호도 설정을 사용하면 된다.
선호도 설정은 Taint 및 Toleration과 함께 사용할 경우 올바른 Toleration이 있는 Pod만 노드로 스케쥴링할 수 있도록 한다.
필터링 : 볼륨 요구 사항
스케줄러는 Pod가 요청한 볼륨(PersistentVolume)을 특정 노드에서 사용할 수 있는지 확인한다. 예를 들어, 특정 클라우드 공급자의 스토리지 볼륨은 특정 지역이나 가용 영역(Availability Zone)에 있는 노드에서만 연결할 수 있다.
스케줄러는 이러한 볼륨 토폴로지(topology) 제약 조건을 만족하지 못하는 노드를 필터링 단계에서 제외한다.
Kubectl 유틸리티(데모)

Kubectl 도구
kubectl을 사용하여 제어 영역 노드와 통신할 수 있다.
kubectl은 특정 클러스터에서 kubernetes API 서버와 통신하기 위한 명령줄 인터페이스(CLI)이다.
kubectl은 리소스를 생성하고, 클러스터와 리소스에 대한 세부 정보를 확인하고, 문제 해결 도구에 액세스하는 명령을 제공한다. kubectl [명령] [유형] [이름] [플래그]
- 명령 : 수행할 작업 지정
- 유형 : 리소스 유형 지정
- 이름 : 리소스 이름 지정
- 플래그 : 선택적 플래그 지정
  kubernetes 객체
  
  Namespace
kubernetes의 또 다른 기본 객체는 Namespace이다.
일반적으로 동일한 클러스터 안의 리소스 이름들은 고유해야 한다.
하지만 Namespace에서는 동일한 물리적 클러스터내에 가상 클러스터를 생성할 수 있다. 물리적 클러스터는 서로 다른 Namespace에 있는 동일한 이름의 리소스를 지닐 수 있다.
Namespace는 여러 팀이나 프로젝트에서 동일한 클러스터를 사용하는 경우에 유용하게 사용된다.
ConfigMap 과 Secret
kubernets에서 ConfigMap는 데이터를 키-값 쌍으로 저장하는 API 객체이다.
configMap 데이터는 환경 변수, 명령줄 인수 또는 볼륨의 구성 파일로 사용할 수 있다.
Secret은 민간함 기밀 정보가 포함된 kubernetes 객체이다. 이를 보호하기 위해서는 클러스터에 대한 추가 구성이 필요하다.

모듈 2 : Amazon EKS 기본 사항

Amazon EKS 소개

모듈 1에서 kubernetes가 컨테이너 워크로드를 관리하는데 효과적인 방법임을 알게 되었다. 어렵지는 않지만 kubernetes를 시작하고 실행하는 것은 복잡할 수 있다.
Amazon EKS는 AWS에서 kubernets를 사용하여 컨테이너식 애플리케이션을 배포, 관리, 크기 조정할 수 있는 관리형 kubernetes 제어 영역 서비스다.
Amazon EKS는 kubernets 클러스터를 위한 제어 영역을 생성하고 관리한다. 또한 여러 AWS 가용 영역에 걸쳐 kubernets 관리 인프라를 실행하여 단일 장애 지점을 제거한다.
Amazon EKS는 사용자가 원할 경우 데이터 영역(노드)의 요소를 관리할 수도 있다.
Amazon EKS는 다음과 같은 AWS 서비스와 긴밀하게 통합되어 있다.
- 로드 분산을 위한 Application Load Balancer
- 역할 기반 액세스 제어를 위한 AWS (IAM)
  - Pod 네트워킹을 위한 Amazon VPC

Amazon EKS 제어 영역

Amazon EKS : 관리형 Kubernets 제어 영역

표준 kubernetes 배포에서 사용자는 제어 영역의 모든 요소를 설계, 구현, 유지, 관리 하고 노드를 관리해야 한다. 이 모든 관리는 Pod에서 실행되는 애플리케이션을 생성하고 컨테이너화하는 작업이 추가되게 된다.
Amazon EKS는 각 클러스터의 etcd 지속성 계층과 kubernets API 서버의 가용성과 확장성을 자동으로 관리한다. Amazon EKS를 이용하면 데이터 영역과 Pod를 실행하는 데 온전한 시간을 부여할 수 있다.
Amazon EKS 제어 영역 내부
kubernetes 제어 영역 구성요소 외에도 Amazon EKS 관리형 제어 영역에는 kubernetes 제어 영역에 대한 몇가지 추가 기능이 포함되어있다.
- kubernetes 용 AWS IAM Authenticator
- AWS Fargate 스케줄러
kubernets 데이터 영역을 호스팅하는 방법도 선택가능하다.
- Amazon EC2 인스턴스를 사용하는 self managed 노드
- Amazon EC2 Auto Scaling 그룹을 사용하여 Amazon EC2 인스턴스를 관리하는 Amazon EKS 관리형 그룹
- 노드당 1개의 Pod의 서버리스 호스팅을 위한 AWS Fargate
  가용성 유지 관리
Amazon EKS는 Kubernets 제어 영역을 실행한다. 비정상 제어 영역 노드를 자동으로 탐지하여 교체하므로 kubernetes 실행에 따른 운영 부담이 대폭 제거된다.
Amazon EKS를 시작하려면 노드 클러스터를 프로비저닝해야 한다.
Amazon EKS는 가용성이 높고 안전한 구성으로 kubernetes 제어 영역의 프로비저닝, 크기 조정, 관리를 처리한다. 사용자의 경우 GUI 또는 CLI를 사용하여 Amazon EKS 클러스터에 연결한다. 이후 애플리케이션을 Amazon EKS 클러스터에 배포 할 수 있다.
Amazon EKS 데이터 영역

Amazon EKS 데이터 영역 관리
노드가 많은 복잡한 인프라를 관리하고 자동 크기 조정 및 업데이트를 신경 쓰는 일은 쉽지 않다. 또한 클러스터에 노드를 프로비저닝하는 여러 팀이 있는 경우, 프로비저닝 방식이 각각 달라 이를 표준화 하기 어렵다.
Amazon EKS를 통해 데이터 영역의 일부 또는 전부를 관리하면 인프라를 간소화 하고 표준화를 유지 할수 있다.
데이터 영역 옵션
kubernetes 제어 영역은 Amazon EKS가 전적으로 관리하지만 데이터 영역의 경우 3가지 유형의 노드를 관리할 수 있다.
- 전적으로 사용자가 관리하는 self managed 노드
- Amazon EKS가 부분으로 관리하고 사용자가 리소스에 대한 제어를 할 수 있는 관리형 노드 그룹
- Amazon EKS에서 전적으로 관리하는 Fargate 노드
  관리형 노드 그룹
관리형 노드 그룹은 Amazon EKS API를 사용하여 Amazon EKS 클러스터용 컨테이너를 실행하는 Amazon EC2 인스턴스를 시작하고 관리한다.
특징
- 프로비저닝 지원 : Amazon EKS에 최적화되고 Auto Scaling 그룹이 지원하는 최신 AMI를 사용하여 멀티가용영역 그룹을 한번에 배포 가능
- 관리 지원 : 관리형 노드 그룹의 상태 모니터링을 처리
- 업데이트 지원 : 하나의 명령으로 관리형 노드 그룹을 클러스터에 맞는 최신 AMI 버전으로 업데이트 가능
- 크기 조정 제어 : 관리형 노드 그룹은 노드 크기 조정을 처리한다.
- eksctl와 함께 작용 : eksctl을 사용하여 관리형 노드 그룹을 프로비저닝 할 수 있다.
  AWS Fargate
Amazon EKS가 데이터 영역을 완전히 관리하도록 한다.
AWS Fargate는 kubernetes 데이터 영역의 전체 인프라를 관리하기 때문에 사용자는 Pod 실행에 대해서만 신경 쓰면 된다.
특징
- 네이티브 : AWS Fargate는 네이티브 Kubernetes Pod를 실행한다.
- 적정 규모 : AWS Fargate는 Pod 및 리소스에 필요한 리소스를 동적으로 프로비저닝한다.
- 빠르고 간단함 : AWS Fargate는 빠르게 크기 조정이 가능하다.
- 비용 최적화 : 실행한 Pod 비용만 지불한다.

실습 1 : Kubernetes Pod 배포

실습 1에서는 아래 과제를 수행한다.
1. Kubernetes 애플리케이션을 생성하고 배포한다.
2. 배포, 서비스 및 네임스페이스 리소스를 생성한다.
3. 네임스페이스에서 리소스를 본다.
4. 서비스 및 배포의 세부 정보를 이해한다.
5. Pod의 세부 정보를 이해한다.
6. Pod에서 명령을 실행한다.
7. 애플리케이션을 삭제한다.
실습환경

과제 1 : Kubernetes 애플리케이션 배포
제공되어있는 EC2 인스턴스 중 bastion Host에 접속 수행(Session Manager 이용)
kubectl이 설치되어 있는지 확인 kubectl version --output=yaml
kubectl 이 생성된 것을 확인했기 때문에 생성된 네임스페이스를 보기 위해 아래 명령어를 입력한다. : kubectl get namespaces
현재 workshop 네임스페이스에 배포된 리소스를 보기 위해 다음 명령어를 입력한다. : kubectl get deploy,svc,pod -n workshop
- 실습 예시 페이지에서는 pod 부분이 정상적으로 running되어 있는데 여기서는 이미지를 찾을수 없는 오류(ImagePullBackOff)가 발생했다. 아마 기간이 좀 지난 실습이라서 태그가 삭제되어있을 가능성이 존재한다. 하지만 실습에 지장이 없을 것 같아 그대로 수행한다.
  - 해당 실습에는 3개의 마이크로 서비스로 구성된다.
- 프런트엔드 : 프런트엔드 서비스는 애플리케이션 UI를 표시
- Product Catalog : 카탈로그에 제품을 추가하고 제품 세부 정보를 검색
- Catalog Detail : 공급업체 이름 및 버전 번호를 반환
  - 프런트엔드 마이크로서비스와 백엔드 마이크로서비스 중 하나는 이미 클러스터에 배포되어 있다. 이번 단계에서는 Catalog Detail 마이크로서비스를 배포하고 노출하고자 한다.
- 이 실습에 필요한 모든 이미지는 미리 빌드되어 있다. 공개 ECR에서 가져오는 대신 다음 명령을 실행하여 이미지 경로를 업데이트하면 된다.
```
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws configure set region $(curl -s http://169.254.169.254/latest/meta-data/placement/region)
export AWS_REGION=$(aws configure get region)
```

Catalog Detail 마이크로서비스를 배포하기 위해서 먼저 프런트엔드 배포를 수행하는 매니페스트부터 생성한다.

~~~

cat << EOF > ~/proddetail-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: proddetail namespace: workshop spec: replicas: 1 selector: matchLabels:

app: proddetail

template: metadata:

labels:
  app: proddetail

spec:

containers:
  - name: proddetail
    image: "$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/eks-workshop-demo/catalog_detail:1.0"
    imagePullPolicy: Always
    ports:
      - name: http
        containerPort: 3000
        protocol: TCP
    resources: {}

EOF

-   EOF 라인까지  `~/proddetail-deployment.yaml` 파일로 복사 붙여 넣는다.
-  v1 APIVersion을 참조하여 Kubernetes **deployment** 객체를 생성 한다. deployment는 매니페스트에 정의된 애플리케이션 상태를 유지하려고 시도할 때 Pod를 동적으로 생성 및 삭제를 수행한다.
- metadata 레이블은 배포에 이름을 할당하고 배포가 배포될 네임스페이스를 선택하는 데 사용된다. 네임스페이스를 선택하지 않으면 default에 배포된다.
- kind 레이블은 생성하려는 kubernetes 객체의 선택하고 spec은 레이블은 해당 상태를 정의한다.
- ReplicaSet는 특정 수의 Pod 인스턴스가 항상 실행되고 있는지 확인하는 데 사용된다. 이번 실습에는 1로 설정해 두었는데 이 경우, 한 개의 Pod 인스턴스가 항상 생성되어야 한다. 만약 3으로 값을 변경하게 된다면 복제본 2개가 추가 생성되고 관리된다.
- selector 필드는 Kubernetes에게 ReplicaSet가 획득해야 할 Pod를 알려준다.

cat << EOF > ~/proddetail-service.yaml apiVersion: v1 kind: Service metadata: name: proddetail namespace: workshop labels: app: proddetail annotations: owner: student spec: type: ClusterIP ports:

port: 3000 name: http selector: app: proddetail EOF
- pps/v1 APIVersion을 참조하여 Kubernetes Service 객체를 생성
- 서비스는 Pod를 네트워크 서비스로 노출하는 데 사용
- spec 필드는 서비스 상태를 정의한다. 이번 실습에는 ClusterIP 서비스를 생성한다. 이는 기본 서비스 유형이며 클러스터 내부에서만 액세스할 수 있다.
- NodePort 또는 LoadBalancer 유형으로 설정된 서비스를 이용해야만 클러스터 외부로부터의 요청을 수락할 수 있다. 또한 이 서비스는 포트 3000에서 HTTP 트래픽을 수락하도록 설정한다.

workshop 네임스페이스에 존재하는 frontend 와 prodcatlog 디플로이먼트 컨테이너 이미지를 업데이트 한다.

kubectl set image deployment/frontend frontend=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/eks-workshop-demo/frontend_node:2.0 -n workshop
kubectl set image deployment/prodcatalog prodcatalog=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/eks-workshop-demo/product_catalog:1.0 -n workshop

매니패스트 파일을 클러스터에 적용하기 위해 명령어를 입력한다.

kubectl apply -f ~/proddetail-deployment.yaml
kubectl apply -f ~/proddetail-service.yaml

생성 결과
kubectl get service 명령어를 이용해실행되고 있는 로드밸런서를 확인하고, 이를 이용해 웹 페이지 접근
proddetail 배포 및 서비스에 대한 매니페스트를 생성하고 배포해보았다.

모듈 3 : Amazon EKS 클러스터 구축 및 유지 관리

Amazon EKS 클러스터 생성

클러스터를 생성하기 전 클러스터에 액세스 하는데 사용할 시스템에 필요한 도구
- eksctl : Amazon EKS에서 kubernetes 클러스터를 생성하고 관리하는 간단한 명령줄 유틸리티
- aws CLI
- kubectl
이 때, 클러스터 생성은 Amazon EKS에 의해 관리되는 제어 영역을 배포하는 프로세스를 의미 한다.
eksctl
eksctl은 클러스터 및 노드 생성에 필요한 많은 단계를 자동화 한다.
- 클러스터 및 노드에 대한 AWS IAM 역할을 생성
- CIDR 192.168.0.0/16을 사용하여 전용 VPC를 생성
- 클러스터 및 노드 그룹 생성
- API 엔드포인트에 대한 액세스를 구성
- 클러스터의 kubeconfig 파일을 작성
  노드 배포
Amazon EKS는 다양한 유형의 Amazon Machine Image(AMI)를 지원한다.
Amazon EKS에 최적화된 AMI는 Amazon Linux이다.
HashiCorp Packer로 사용자 정의 Amazon EKS AMI를 구축을 수행할 수도 있다.
Bottlerocket는 Linux 기반 오픈 소스 운영체제이다. 이를 이용해서도 Amazon EKS를 구축 가능하다.
마지막으로 Winodw 운영체제에서도 동작시킬수 있다.
클러스터 생성을 위한 선언적 옵션
Amazon EKS 클러스터 작업을 위한 콘솔 및 명령줄 옵션(AWS CLI, eksctl)외에도 AWS CloudFormation, AMazon EKS Blueprints, 코드형 인프라(IaC)와 같은 선언형 옵션ㅇ르 사용할 수도 있다.
AWS CloudFormation을 사용하면 인프라를 코드로 취급하여 리소스를 스택으로 빠르고 일관성 있게 프로비저닝, 시작, 구성할 수 있다.
EKS Blueprints는 워크로드를 배포 및 운영하는 데 필요한 운영 소프트웨어로 완전히 부트스트래핑된 전체 Amazon EKS 클러스터를 구성하는데 도움이 된다. EKS Blueprints는 AWS CDK를 사용하여 구축되었다.
AWS SDK 및 Terraform, ClusterAPI 등 여러 서드파티 IaC 소프트웨어 도구도 사용할 수 있다.

Introduction to Database Migration

Mon, 07 Jul 2025 04:03:19 GMT

학습 목표

데이터베이스를 AWS로 마이그레이션 하는 단계를 설명
AWS SCT의 기능과 AWS SCT가 어떻게 마이그레이션에 도움이 되는지 설명
AWS DMS의 기능과 AWS DMS가 어떻게 마이그레이션에 도움이 되는지 설명한다.

AWS로 마이그레이션

클라우드 마이그레이션은 더 쉬운 자동화와 탄력성을 제공하여 비용을 절감하는 동시에 공급업체 종속을 줄이면서 라이선스 비용을 절감할 수 있다.

데이터베이스 마이그레이션 이유

데이터베이스 현대화 : 디지털 시대에서 경쟁을 위해 비즈니스 민첩성을 확보할 수 있도록 레거시 데이터베이스 엔진에서 최신 데이터베이스 엔진으로 데이터를 이동
데이터베이스 마이그레이션 : 엔터프라이즈 애플리케이션의 컨텍스트에서 플랫폼 간에 데이터를 이동하는 것
데이터베이스 복제 : 모든 사용자와 동일한 수준의 정보르르 공유하기 위해 한 컴퓨터/서버의 데이터베이스에서 다른 컴퓨터/서버의 데이터베이스로 데이터를 전자적으로 자주 복사

AWS로 마이그레이션의 장점

간편한 사용
- AWS DMS는 드라이버나 애플리케이션을 설치할 필요가 없다.
- 일반적으로 소스 데이터베이스를 변경할 필요도 없다.
최소한의 가동 중지
- 데이터베이스 마이그레이션 과정 중 가동 중지가 거의 없다.
*널리 사용되는 데이터베이스 지원 *
- 널리 사용되는 상용 및 오픈 소스 데이터베이스 엔진으로 데이터를 마이그레이션 할 수 있다.
저렴한 비용
- 마이그레이션 프로세스 중 사용한 컴퓨팅에 대한 비용만 지불
*빠르고 쉬운 설정 *
- AWS Management Console에서 몇분 내로 파라미터를 정의하여 task를 설정할 수 있다.
안전성
- 복원력과 자동 복구력이 뛰어나다.
  AWS로 마이그레이션 방법
AWS DMS와 AWS Schema Conversion Tool(AWS SCT)을 사용하면 데이터베이스를 AWS로 빠르고 안전하게 마이그레션 할 수 있다.
AWS DMS를 이용하면 마이그레이션 중에서도 소스 데이터베이스를 사용하는 애플리케이션의 가동 중지 시간을 최소화 할 수 있다.
동일한 데이터베이스 엔진으로 마이그레이션하거나 엔진을 전홚하여 데이터플랫폼을 현대화 할 수 있다. 또는 데이터를 복제하여 소스 및 타겟 데이터베이스를 동기화하기도 한다.
ex) 온프레미스 Oracle DB → AWS DMS → Amazon RDS for Oracle
마이그레이션에 사용되는 Tool
- AWS DMS
  - 가장 기본적인 수준에서 복제 소프트웨어를 실행하는 AWS 클라우드 서버
  - 소스와 타켓을 연결을 만들어 어디에서 추출하고 어디에 로드할 것인지 AWS DMS에 알린다. 그후 AWS DMS에서 데이터를 이동하는 task를 예약한다.
- AWS SCT
  - 데이터베이스 엔진을 전환하려는 경우 AWS SCT가 기존 데이터베이스 스키마를 타켓 플랫폼을 변환할 수 있다.
  - 스키마에는 테이블, 인덱스, 뷰 및 저장 프로시저와 애플리케이션 코드가 포함되어있다.
데이터베이스를 마이그레이션하기 위해서는 12단계 프로세스를 따라서 동작한다. 크게 스키마 마이그레이션, 데이터 마이그레이션, 교육 및 지원 3 부분으로 나눌 수 있다.

스키마 마이그레이션

1단계 : 마이그레이션 구상 및 평가(AWS SCT)

계획 수립을 수행을 통해 데이터베이스 스키마, 데이터 볼륨, 데이터 유형, 리소스 및 애해 관계자를 기초로 필요한 작업 범위를 이해해야 한다.
이 단계에서 수행해야 할 것은 현재 환경과 알려진 위험을 평가하고 마이그레이션에 대한 비즈니스 사례를 만드는 것이다.
이기종 데이터베이스 마이그레이션을 수행하고자 할 경우, AWS SCT를 활용한다. AWS SCT는 기존 시스템의 물리적 및 논리적 구성 요소를 카탈로그로 작성하여 마이그레이션 프로세스를 지원할 수 있다. 하나 이상의 인기있는 오픈 소스 엔진으로 마이그레이션하는 데 필요한 작업량을 평가한다.
평가 보고서는 자동으로 변환할 수 있는 항목, 수동 수정 적용이 필요한 객체 및 중요한 수정 작업이 필요한 객체를 보여준다.

2단계 : 데이터베이스 스키마 변환 (AWS SCT)

2단계에서는 데이터베이스 객체를 소스 엔진에서 타겟 엔진으로 변환하는 것이다. 여기에는 테이블, 인덱스, 제약 조건, 외래 키, 트리거 및 저장 프로시저 변환이 포함된다. 변환 과정에서도 AWS SCT가 역할을 수행한다.
AWS SCT가 단순(회색), 보통(노란색), 복잡(빨간색) 작업에 대해서 다른 색상으로 변환할수 없는 항목을 표시한다.
소스 데이터베이스 기능에 AWS SCT가 변환할 수 있는 타겟 데이터베이스의 정확히 치환할 수없는 경우 타겟 엔진의 기능을 기반으로 디자인 패턴을 사용하여 객체를 다시 코딩해야 한다.이 프로세스를 지원하기 위해 가장 많이 사용되는 소스 및 타겟 조합에 대한 디자인 패턴이 포함된 마이그레이션 플레이북을 제공한다.
플레이북은 이기종 데이터베이스 마이그레이션을 위한 모범 사례에 중점을 둔 일련의 안내서이다.
- Microsoft SQL Server → Aurora MySQL
- Microsoft SQL Server →Aurora PostgreSQL
- Oracle → Aurora PostgreSQL

3단계 : 애플리케이션 변환 (AWS SCT)

애플리케이션 변환은 Java 또는 C와 같은 언어로 작성된 애플리케이션 코드를 새 타켓 데이터베이스에 이식하는 과정이다.
이 단계가 마이그레이션 프로세스의 가장 복잡한 측면이기도 하다. 오래 전에 더 이상 사용할 수 없는 리소스에 의해 작성된 데이터베이스에 대해 실행되는 애플리케이션이 있을 수 있다. 이러한 애플리케이션은 미션 크리티컬한 경우가 많으며 광범위한 연구 및 테스트 없이는 다시 작성하기가 어려울 수 있다.
AWS SCT를 사용하여 애플리케이션 코드에 포함된 SQL 문을 추출해 타겟 데이터베이스에서 작동하도록 SQL을 변환하고, 변환된 코드로 애플리케이션 프로그램을 다시 빌드할 수 있게 한다.

4단계 : 스크립트 변환 (AWS SCT)

스크립트 변환 단계에서는 추출, 변환 및 로드(ETL) 프로세스, 데이터베이스 유지 관리, 재해 복구 및 기타 프로세스에 사용되는 배치 스크립트를 살펴본다.
이러한 스크립트는 데이터베이스를 사용하는 애플리케이션과 직접적인 관련은 없지만 새 데이터베이스 엔진에서 작동여부를 확인하기 위해 분석이 필요하다.

5단계 : 서드 파티 애플리케이션과의 통합

많은 기업에서도 서드 파티 애플리케이션에 대한 데이터베이스를 지원하거나 서드 파티 애플리케이션 데이터베이스 액세스 하도록 해야한다.
다른 데이터베이스에 액세스 할수 있도록 일부 애플리케이션을 작성할 수 있지만 여전히 애플리케이션을 테스트하고 예상대로 작동하는지 확인해야 한다.

데이터 마이그레이션

6단계 : 데이터 마이그레이션(AWS DMS)

이 단계에서는 소스에서 타켓으로 데이터 레코드를 이동하는 프로세스이다. 흔히 데이터베이스 마이그레이션을 생각할 때 수행되는 과정이다.
대용량 데이터를 처리하고 애플리케이션을 타겟 시스템으로 전환할 수 있을 때까지 소스 시스템과 타겟 시스템은 동기화된 상태로 유지해야 하는 경우 데이터 마이그레이션이 어려울 수 있다.
또한, 타겟 데이터베이스의 유형을 변경하는 경우 타겟 시스템 요구 사항을 준수하기 위해 대부분의 데이터 값(전체는 아님)을 변환해야 한다.
AWS DMS는 전체 로드 마이그레이션, 지속적인 복제 또는 이들 조합의 세 가지 방법 중 한나로 데이터를 이동한다.
- 소스의 기존 데이터가 타겟으로 이전되는 전체 로드 마이레이션 도중 AWS DMS은 소스 데이터 스토어에 있는 테이블의 데이터를 타켓 데이터 스토어에 있는 테이블로 로드한다.
- AWS DMS는 또한 지속적인 복제를 지원하여 타겟을 트랜잭션 활성 소스와 동기화한다.
- 초기 전체 로드를 사용한 다음 지속적 복제를 통해 두 가지 유형의 데이터 전송을 결합하기도 한다.

7단계 : 전체 시스템 기능 테스트

데이터 및 애플리케이션을 타겟 데이터베이스로 마이그레이션한 후 다음 단계는 전체 시스템들이 잘 동작되는지 기능 테스트를 수행한다.
8단계 : 성능 튜닝
애플리케이션에서 기능 테스트의 일부로 충족할 성능 기준을 지정하는 경우가 존재한다.
성능 문제가 발견되면 사용자 대상 애플리케이션부터 SQL 문, 데이터베이스 엔진 및 관련 스토리지 계층에 이르기까지 각 시스템 레벨에서 병목 현상이 있는지 점검을 수행한다.
9단계 : 통합 및 배포 (AWS DMS)
통합 및 배포 단계는 새로운 데이터베이스 시스템으로 전환하는 프로세스이다. 여기에는 일반적으로 애플리케이션이 새 데이터베이스 시스템으로 전환되는 방법을 자세히 설명하는 일련의 단계가 포함된다.
- 통합 : 처음에는 시스템이 원래 데이터베이스와 통신한다. AWS DMS를 사용하여 전체 로드 마이그레이션을 수행한 다음 지속적인 복제를 설정한다.
- 배포 : 데이터가 제대로 전송되고 있는지 확인하고 새 데이터베이스로 애플리케이션을 테스트 했다고 가정하면 새 데이터베이스와 통신하도록 애플리케이션을 변경한다. 이 후 지속적인 복제가 중지된다.

교육 및 지원

10단계 : 교육 및 지식 전달

이기종 마이그레이션을 수행하는 경우 팀원들이 이동하는 엔진에 익숙하지 않을 수 있다. 또한 클라우드 또는 AWS 기술에 익숙하지 않을 수도 있다.
모두가 기술을 잘 알고 있더라도 마이그레이션 하는 과정 중 애플리케이션과 앞으로 작동 방식에 대한 유용한 정보를 발견할 가능성이 존재한다. 또한 마이그레이션 과정 중 테이블, 저장 프로시저 및 애플리케이션 코드를 약간 변경했을 수 있다. 이런 경우 변경 사항이 문서화되어있는지 파악하고 해당 지식을 팀원과 공유해야 한다.
11단계 : 버전 문서화 및 제어
문서화는 시스템을 프로덕션에 투입하기 전에 해야할 가장 중요한 작업 중 하나이다.
AWS에서는 IaC를 지원하고 코드로 모든 클라우드 인프라를 관리하기 위한 서비스와 도구를 제공한다. 완전히 새로운 환경을 만들고 있기 때문에 모든 단계를 문서화할 수 있는 좋은 기회이다.
또는 모든 아티팩트를 코드로 치리하는 것도 고려할 수 있다. 버전 관리 시스템을 사용하고 데이터베이스 또는 서버 인프라의 변경 사항에 대한 코드 검토도 필요하다.
12단계 : 프로덕션 후 지원 계획
마이그레이션된 애플리케이션이 실행되면 몇 가지 지원이 필요하다. AWS를 사용하면 백업과 기타 지원 작업을 자동화 할수 있다.

AWS Cloud Practitioner Essentials

Sun, 06 Jul 2025 15:19:46 GMT

과정 개요

이번 과정에서는 AWS 클라우드 개념, AWS 서비스,보안,아키텍처에 대해 학습하여 AWS 클라우드 지식을 구축한다.

1. AWS WEB Services

Client-Server 모델

클라이언트 : 컴퓨터 서버에 요청을 보내기 위해 상호작용하는 우베 브라우저 또는 데스크톱 에플리케이션
서버 : 일종의 가상 서버인 Amazone Elastic Compute Cloud(Amazon EC2)

클라우드 컴퓨팅

클라우드 컴퓨팅을 위한 배포 모델

클라우드 컴퓨팅 배포 모델에는 클라우드 기반, 온프레미스, 하이브리드 가 존재

클라우드 기반 배포

애플리케이션의 모든 부분을 클라우드에서 실행
기존 애플리케이션을 클라우드로 마이그레이션 수행
클라우드에서 새 애플리케이션을 설계 및 빌드

온프레미스 배포(프라이빗 클라우드)

가상화 및 리소스 관리 도구를 사용하여 리소스를 배포
애플리케이션 관리 및 가상화 기술을 사용하여 리소스 활용도를 높인다.

하이브리드 배포

클라우드 기반 리소스를 온프레미스 인프라에 연결
클라우드 기반 리소스를 레거시 IT 애플리케이션과 통합

클라우드 컴퓨팅의 이점

선행 비용을 가변 비용으로 대체
- 데이터 센터, 물리적 서버 등 미리 서버 구축에 필요한 비용인 선행 비용을 생각하지 않고, 오로지 사용하는 컴퓨팅 리소스 자원인 가변 비용만 생각해도 된다는 장점이 존재한다.
데이터 센터 운영 및 유지 관리에 비용 투자 불필요
- 또한, 클라우드 컴퓨팅을 이용하게 된다면 데이터 센터를 유지 및 관리하는데 드는 인적자원 등을 고려하지 않아도 된다.
용량 추정 불필요
- 클라우드 컴퓨팅을 이용하게 된다면 사용한 컴퓨팅 시간에 대해서만 비용을 지불할 수 있다.
규모의 경제로 얻게 되는 이점
- 매우 많은 고객의 클라우드 사용량이 집계되므로 각자의 종량제 요금이 낮아진다.
속도 및 민첩성 향상
- 클라우드 컴퓨팅의 유연성 덕분에 애플리케이션을 더욱 쉽게 개발하고 배포할 수 있다.
몇 분 안에 전 세계에 배포 가능
- 다른 지역에 위치한 고객도 지연 시간을 최소화하면서 액세스 할 수 있다.

2. 클라우드 컴퓨팅

Amazon Elastic Compute Cloud(Amazon EC2)

물리적 서버가 아닌 인터넷을 통해 가상화된 서버에 엑서스 하는데 사용하는 서비스

Amazon EC2의 장점

몇 분이내로 Amazon EC2 인스턴스를 프로비저닝하고 시작 할 수 있다.
작업 완료 후 인스턴스 종료가 가능하기 때문에, 비용 측면에서 효율적이다.
물리적 호스트 시스템을 소유하지 않아도 실제 가동할 때 무관하다.
여러 가상머신이 기본적인 하드웨어를 공유(멀티 테넌시)하고 서로 격리되어 있어 서로의 존재를 인식하지 못한다.
다양한 운영체제(Windows, Linux, Mac OS)를 선택 할 수 있다.
리소스의 크기 조정이 가능하다.
Amazon EC2 작동방식
1. 시작 : 기본 구성 인스턴스가 포함된 템플릿을 통해 인스턴스를 시작한다.
2. 연결 : 인스턴스 생성 후 사용자가 인스턴스를 사용하기 위해 인스턴스에 연결을 수행한다.
3. 사용 : 인스턴스에 연결되었다면 수행하고자 하는 명령을 통해 소프트웨어 설치, 스토리지 추가 등 작업을 수행할 수 있다.

Amazon EC2 인스턴스 유형

범용 인스턴스

컴퓨팅, 메모리, 네트워킹 리소스를 균형 있게 제공한다. 아래와 같은 다양한 워크로드에 사용 가능하다.
- 애플리케이션 서버
- 게임 서버
- 엔터프라이즈 애플리케이션용 백엔드 서버
- 중소 규모 데이터베이스
  컴퓨팅 최적화 인스턴스
고성능 프로세스를 활용하는 컴퓨팅 집약적인 애플리케이션에 적합, 아래 워크로드에 주로 사용된다.
- 고성능 웹서버
- 컴퓨팅 집약적 애플리케이션 서버
- 게임 전용 서버
- 단일 그룹에서 많은 트랙잭션을 처리해야하는 일괄 처리

메모리 최적화 인스턴스

메모리에서 대규모 데이터 집합을 처리하는 워크로드에 빠른 성능을 제공하기 위해서 설계되었다.
메모리 최적화 인스턴스를 사용하면 많은 메모리가 필요한 워크로드를 실행하고 뛰어난 성능을 얻을 수 있다.
- 고성능 데이터베이스
- 방대한 양의 비정형 데이터의 실시간 처리
  가속 컴퓨팅 인스턴스
하드웨어 가속 또는 보조프로세스를 사용하여 일부 기능을 CPU에서 실행되는 소프트웨어에서보다 더 효율적으로 수행한다. 기능의 예시로 부동 소수점 수 계산, 그래픽 처리, 데이터 패턴 일치 등이 있다.
- 그래픽 애플리케이션
- 게임 스트리밍
- 애플리케이션 스트리밍
  스토리지 최적화 인스턴스
로컬 스토리지의 대규모 데이터 집함에 대한 순차적 읽기 및 쓰기 액세스가 많이 필요한 워크로드를 위해 설계 되었다.
- 분산 파일 시스템
- 데이터 웨어하우징 애프릴케이션
- 고빈도 온라인 트랜잭션 처리(OLTP) 시스템

Amazon EC2 요금

Amazon EC2에서는 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다.

온드맨드 인스턴스

중단할 수 없는 불규칙한 단기 워크로드가 있는 애플리케이션에 적합하다.
인스턴스는 중지될 때까지 계속 실행되며, 사용한 컴퓨팅 시간에 대해서만 비용을 지불한다.
예약 인스턴스
1년 이상 지속되는 온디맨드 인스턴스를 사용하고자 할때 적용되는 결제 할인 옵션이다. 예약 인스턴스는 1년 또는 3년 약정으로 구입할 수 있다.
예약 인스턴스는 약정 기간 종료 시에도 인스턴스를 중단 없이 계속 사용할 수 있다.
EC2 인스턴스 Saving Plans
Amazon EC2를 비롯한 몇몇 컴퓨팅 서비스에 대한 Savings Plans를 제공한다. 약정 기간 동안 EC2 사용량에 유연성이 필요한 경우 유용한 옵션이다.

스팟 인스턴스

시작 및 종료시간이 자유롭거나 중단을 견딜 수 있는 워크로드에 적합하다.
스팟 인스턴스는 미사용 Amazon EC2 컴퓨팅 용량을 사용하며 온디맨드 요금의 최대 90%까지 비용을 절감 할 수 있다.

전용 호스트

사용자 전용의 Amazon EC2 인스턴스 용량을 갖춘 물리적 서버이다.
지금까지 다룬 Amazon EC2 옵션 중에서 가장 많은 비용이 든다.

Amazon EC2 크기 조정

확장성을 위해서는 필요한 리소스만으로 시작하고 확장 및 축소를 통해 수요 변화에 자동으로 대응하도록 아키텍쳐를 설계해야 한다. AWS는 Amazon EC2 Auto Scaling을 통해 자동으로 조정한다.

Amazon EC2 Auto Scaling

변화되는 애플리케이션 수요에 따라 Amazone EC2 인스턴스를 자동으로 추가하거나 제거할 수 있다. 필요에 따라 인스턴스를 자동으로 조정하여 애플리케이션 가용성을 효과적으로 유지할 수 있다.
Auto Scaling에는 2가지 접근 방식이 존재한다.
- 동적 요청 : 수요 변화에 대응한다.
- 예측 조정 : 예측된 수요에 따라 적절한 수의 인스턴스를 자동으로 예약한다.
증감하는 수요를 처리하는 방법
- 수직(vertical) 확장 : 실행중인 인스턴스의 리소스 성능을 추가하거나 줄인다.
- 수평(horizontal) 확장 : 인스턴스 수를 추가하거나 줄인다.

Elastic Load Balancing(ELB)

들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리스소에 자동으로 분산하는 AWS 서비스이다.
로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할을 한다.
즉, 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅 된다. 그런 다음 요청을 처리할 여러 리소스로 분산된다.

메시징 및 대기열

모놀리식 애플리케이션 및 마이크로서비스

데이터베이스, 서버 ,사용자 인터페이스, 비즈니스 로직 등이 밀결합된 애플리케이션을 모놀로식 애플리케이션으로 볼 수 있다.
모놀로식 애플리케이션의 경우 한 구성 요소에서 장애가 발생하면 다른 구성 요소에도 장애가 발생하고, 이는 전체 애플리케이션에 문제가 퍼질 수도 있다.
이 문제점을 해결하는 방식으로 마이크로서비스 접근 방식을 통해 애플리케이션을 설계하면 된다.
마이크로서비스 접근 방식은 애플리케이션 구성요소가 소결합 된다. 이 경우에는 단일 구성요소에 장애가 발생해도 다른 구성 요소들은 서로 통신하기 때문에 계속 작동하여 애플리케이션의 가용성을 확보할 수있다.
애플리케이션 통합을 촉진하는 AWS 서비스로는
- Amazon Simple Notification Service(Amazon SNS)
- Amazon Simple Queue Service(Amazon SQS)
  Amazon Simple Notification Service(Amazon SNS)
Amazon SNS는 게시 및 구독 서비스이다.
Amazon SNS는 알림을 받아 자동으로 작동하는 웹서버나 AWS Lambda 또는 여러 옵션이 될 수 있다.
- 예시로, 커피숍에 모든 '쿠폰,최신메뉴' 등 모든 소식을 하나의 뉴스레터로 모든 손님에게 보냈다.
- 하지만, 손님마다 원하는 정보가 다르다는 걸 알게 되어 여러 주제로 뉴스레터를 분할해서 맞춤형 알림을 전송한다. 이를 통해 사용자는 불필요한 정보 없이 원하는 소식만 정확히 받아 볼수 있게 되었다.

Amazon Simple Queue Service(Amazon SQS)

Amazon SQS는 메시지 대기열 서비스이다.
Amazon SQS를 사용하면 메시지 손실이나 다른 서비스 사용 없이 소프트웨어 구성 요소 간에 메시지를 전송, 저장, 수신할 수 있다.
Amazon SQS에서는 애플리케이션이 메시지를 대기열로 전송하고, 사용자 또는 서비스는 대기열에서 메시지를 검색하여 처리한 후 대기열에서 삭제한다.
추가 컴퓨팅 서비스

서버리스 컴퓨팅
서버리스라는 용어는 코드가 서버에서 실행되지만 이러한 서버를 프로비저닝하거나 관리할 필요가 없다는 뜻이다.
서버리스 컴퓨팅을 사용하면 서버를 유지 및 관리하는데 사용되는 비용을 제품 및 코드 업그레이드에 사용할 수 있다. 또한, 애플리케이션을 자동으로 확장할 수 있는 유연성도 가지고 있다.
AWS Lambda
AWS Lambda는 서버를 프로비저닝하거나 관리할 필요 없이코드를 실행 할 수 있는 서비스이다.
코드를 실행하는 동안에만 요금이 부과되고, 서버를 관리할 필요는 전혀 없다.

AWS Lambda 작동방식

Lamdba 코드 업로드
AWS 서비스, 모바일 어플리케이션 또는 HTTP 엔드포인트와 같은 이벤트 소스에서 트리거되도록 코드를 설정
Lambda는 트리거된 경우에만 코드를 실행
사용한 컴퓨팅 시간에 대한 요금만 지불한

컨테이너

마이크로서비스 외에도 컨테이너식 애플리케이션을 빌드하고 실행할 수 있다.
컨테이너는 애플리케이션의 코드와 종속성을 하나의 객체로 패키징하는 표준 방식을 제공한다.
보안성, 신뢰성, 확장성 요구 사항이 매우 중요한 프로세스 및 워크플로에도 컨테이너를 사용한다.

컴퓨팅 환경이 달라도 애플리케이션 환경이 배포와 상관없이 일관적으로 유지하기 위해서 컨테이너식 접근 방식을 사용한다.
만약 이런 컨테이너식 애플리케이션이 수백 개의 컨테이나가 있는 수십개의 호스트를 관리해야한다고 가정해볼 때, 이를 관리하기 위해서는 많은 시간이 걸릴 것이다.
AWS에서는 컨테이너 오케스트레이션 서비스를 이용해 컨테이너식 애플리케이션을 배포, 관리, 확장하는 데 도움을 줄 수 있다.
- Amazon Elastic Container Service
- Amazon Elastic Kubernetes Service
  Amazon Elastic Container Service(ECS)
Amazon ECS는 AWS에서 컨테이너식 애플리케이션을 실행하고 확장할 수 있는 확장성이 뛰어난 고성능 컨테이너 관리 시스템이다.
Amazon ECS는 Docker 컨테이너를 지원한다. Amazon ECS에서는 API 호출을 사용하여 Docker 지원 애플리케이션을 시작 및 중지할 수 있다.
Amazon Elastic Kubernetes Service(EKS)
Amazon EKS는 AWS에서 Kubernetes를 실행하는데 사용할 수 있는 완전 관리형 서비스이다.
Kubernetes는 컨테이너식 애플리케이션을 대규모로 배포하고 관리하는 데 사용할 수 있는 오픈 소스 소프트웨어이다.

AWS Fargate

AWS Fargate는 컨테이너용 서버러스 컴퓨팅 엔진이다. Amazon ECS와 Amazon EKS에서 작동한다.
AWS Fargate를 사용하는 경우 서버를 프로비저닝하거나 관리할 필요가 없다.

3. 글로벌 인프라 및 신뢰성

AWS 글로벌 인프라

리전 선택

서비스, 데이터 및 애플리케이션에 적합한 리전을 결정할 때 아래 요구사항을 고려해야한다.
- 데이터 거버넌스 및 법적 요구사항 준수
  - 회사와 위치에 따라 특정 영역에서 데이터를 실행해야 할 수 있다. ex)영국 내의 데이터를 보관해야되는 경우 런던 리전을 선택해야 한다.
- 접근성
  - 사용자과 가까운 리전을 선택하면 사용자에게 콘텐츠를 더 빠르게 제공하는데 도움이 된다.
- 리전 내에서 사용 가능한 서비스
  - 경우에 따라 고객에게 제공하려는 기능이 가까운 리전에 존재하지 않을 수도 있다.
- 요금
  - 서비스 비용이 리전마다 다르다.
    가용영역
가용영역 은 리전 내의 단일 데이터 센터 또는 데이터 센터 그룹이다. 가용 영역 간에는 대략 100km 이내에 존재한다. 이는 가용영역 간의 지연시간이 짧은 만큼의 거리지만, 재해 및 데이터센터의 이상이 발생할 경우 영향을 받지 않을 정도의 거리만큼 떨어져 있다.
가용영역이 중요한 이유는 사용자에게 복원력 있는 고가용성 아키텍처를 구축하는 데 핵심적인 역할을 수행하기 때문이다.

엣지 로케이션(Edge Location)

엣지 로케이션은 Amazon CloundFront가 더 빠른 콘텐츠 전송을 위해 고객과 가까운 위치에 콘텐츠 사본을 캐시하는 데 사용하는 사이트이다.
예시로, 회사의 데이터가 브라질 리전에 저장되어있고, 중국에 거주하는 사용자들이 존재한다고 가정한다.
1. 오리진 : 중국에 거주중인 고객들에게 콘텐츠를 제공하기 위해 리전을 중국으로 이전할 필요는 없다.
2. 캐시 : 고객이 브라질에서 데이터를 가져울 필요가 없도록 중국 내 고객과 가까운 엣지 로케이션에 사본을 로컬로 캐시할 수 있다.
3. 고객 : 중국 내 고객이 파일을 요청하면 Amazon CloudFront는 엣지 로케이션의 캐시에서 해당 파일을 검색하여 고객에게 전송한다. 이 파일은 브라질에 존재하는 원본파일이 아닌 중국 근처의 엣지 로케이션에서 가져온 것이라 더 빠르게 전달된다.

AWS 리소스를 프로비저닝하는 방법

AWS 서비스와 상호 작용하는 방법

AWS Management Console

AWS Management Console은 Amazon 서비스 엑세스 및 관리를 위한 웹 기반 인터페이스이다.
Beginnner 들이 일반적으로 AWS 서비스를 이용하기 위해서 사용하는 방법이다.

** AWS Command Line Interface(CLI)**

API 요청을 수행할 떄 시간을 절약하기 위해 사용하기도 한다. 흔히 사용하는 명령 프롬포트 또는 터미널창을 통해 사용된다.

소프트웨어 개발 키트

SDK를 사용하면 프로그램이 언어 또는 플랫폼용으로 설계된 API를 통해 AWS 서비스를 보다 간편하게 사용할수 있다.

Console	CLI	SDK
그래픽 기반 웹페이지	터미널 창	프로그래밍 언어로 호출
### AWS Elastic Beanstalk
- 사용자가 코드 및 구성 설정(용량 조정, 로드 밸런싱, 자동 조정 , etc..)을 제공하면 AWS Elastic Beanstalk이 자동으로 리소스를 구성한다.
### AWS CloudFormation
- 코드형 인프라(IaC)로 , 콘솔 창을 사용하여 개별젹으로 리소스를 프로비저닝하는 대신 코드 줄을 작성하여 환경을 구축 할 수 있다.
- AWS CloudFormation은 리소스를 안전하고 반복 가능한 방식으로 프로비저닝하므로 인프라 구축 시간 단축 및 인적 오류를 발생시키지 않는다는 장점이 있다.

4.네트워킹

AWS와의 연결

Amazon Virtual Private Cloud(Amazon VPC)

Amazon VPC를 사용하여 격리된 공간으로 AWS 클라우드의 리소스를 프로비저닝 할수 있다.
한 VPC 내에 여러 서브넷으로 리소스를 구성할 수 있다. 또한, VPC 끼리는 Site-to-Site-VPN을 통하거나 인터넷을 통해 연결하지 않는다면 서로 존재를 인식하지 못한다.

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

VPC 내의 데이터가 외부 사용자와 트래픽을 송수신하기 위해서는 인터넷 게이트웨이를 VPC와 연결해야 한다.
쉽게 생각하자면, 현관문이라고 생각하면 된다. 우리가 집에서 외부로 나가기 위해서는 일반적으로 현관문을 통해 나가는 것을 비유로 볼수 있다.

가상 프라이빗 게이트웨이(Virtual Private Gateway)

VPC 내의 프라이빗 리소스에 엑세스 하려면 가상 프라이빗 게이트웨이를 사용할 수 있다.
가상 프라이빗 게이트웨이는 보호된 인터넷 트래픽이 VPC로 들어오도록 허용하는 구성요소이다. 즉, 가상 프라이빗 게이트웨이를 사용하면 VPC와 프라이빗 네트워크( ex): 온프레미스 데이터센터) 간에 Virtual Private Network(VPN) 연결을 설정 할 수 있다.

AWS Direct Connect

AWS Direct Connect는 데이터 센터와 VPC 간에 비공개 전용 연결을 설정하는 서비스이다.
쉽게 생각하자면, 주상복합아파트에 거주하는 주민을 생각하면 된다. 단지내에 있는 커뮤니티 시설을 이용하기 위해서 외부에 나간 뒤 커뮤니티 시설을 이용하지 않는다. 바로 커뮤니티 시설과 연결되어있는 엘리베이터를 타고 이동하기만 하면 끝이다. 이 엘리베이터 역할이 Direct Connect로 이해하면 된다.
AWS Direct Connect가 제공하는 프라이빗 연결을 통해 네트워크 비용을 절감하고 네트워크를 통과할 수 있는 대역폭을 늘리는 데 도움을 준다.
서브넷 및 네트워크 엑세스 제어 목록

서브넷
서브넷은 보안 또는 운영 요구사항에 따라 리소스를 그룹화할 수 있는 VPC 내의 섹션이다.
한 VPC 내부의 서브넷들 간에는 서로 통신이 가능하다.
- 퍼블릭 서브넷(Public Subnet) : 누구나 외부에서 엑세스할 수 있는 리소스들이 존재
- 프라이빗 서브넷(Private Subnet) : 주요 정보들이 저장되는 리소스들로 외부에 노출되면 피해를 입을 수 있기에 내부에 저장한다.
  VPC의 네트워크 트래픽
고객이 AWS 클라우드에서 호스팅 되는 애플리케이션에 데이터를 요청하면 이 요청은 패킷으로 전송된다. 패킷은 인터넷이나 네트워크를 통해 전송되는 데이터 단위이다.
패킷은 인터넷 게이트웨이를 통해 VPC로 들어간다. VPC 내부로 들어간 패킷이 서브넷으로 들어가거나 나가려면 패킷의 권한을 확인해야 한다. 패킷의 권한을 확인하는 방법으로 엑세스 제어 리스트(ACL)이 존재한다.

네트워크 ACL

네트워크 ACL은 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽이다.
기본 네트워크 ACL의 경우에는 모든 인바운드 및 아웃바운드 트래픽을 허용해둔 상태이다. 만약, 특정 소스 IP 주소들을 제한하고 싶은 경우 해당 IP 트래픽을 제한(deny)하는 규칙을 추가하면 된다.
반대로 사용자 지정 네트워크 ACL의 경우에는 기본 설정 값이 모든 트래픽이 거부되어있는 상태로 시작된다. 즉, 특정 IP 주소를 허용하는 규칙을 추가하기 전까지 트래픽 전송이 불가한 상태이다.
또한 모든 네트워크 ACL에는 명시적 거부 규칙이 존재한다. 명시적 거부 규칙이란 패킷 목록의 다른 모든 규칙과 일치하지 않는다면 해당 패킷은 거부된다는 것을 말한다. 예시로 사용자 지정 네트워크 ACL 에서 인바운드 트래픽 192.168.0.0/24 주소를 허용한다고 설정 한뒤,추가적으로 172.16.0.0/24 주소에 대해서 허용한다는 규칙을 설정했다. 이 때, 10.0.0.0/24 대역대의 사용자의 경우에는 트래픽을 전송할 수 없다는 것을 의미한다.

Stateless 패킷 필터링

네트워크 ACL은 stateless(무상태) 패킷 필터링을 수행한다. 즉, 패킷의 송수신 과정중에 허용 여부를 판단한 것을 저장하지 않는다. 들어올때 검사하고, 나갈때도 다시 검사한다는 말이다.
패킷에서 Amazon EC2 인스턴스에 대한 권한을 확인하는 VPC 구성 요소는 보안 그룹이다.

보안 그룹(Security Group)

보안 그룹은 Amazon EC2 인스턴스 및 서비스 단에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽이다.
보안 그룹과 ACL은 동일한 역할을 수행하지만, ACL은 서브넷 단위에서 보안 그룹은 서비스 단에서 동작한다는 차이점이 있다.
보안그룹의 기본 설정값은 모든 인바운드 트래픽은 거부하고 아웃바운드 트래픽은 허용해둔다. 이후 사용자 지정 규칙을 지정하여 허용해야 할 트래픽을 추가할 수 있다.
Stateful 패킷 필터링
보안 그룹의 경우에는 Stateful(상태유지) 패킷 필터링을 수행한다. 즉, 들어오는 패킷에 대한 정보들을 기억해둔다.

글로벌 네트워킹

Domain Name System(DNS)

우리가 일반 웹페이지에 접속할 때, 해당 웹 서버의 IP 주소를 기억해서 입력하지는 않고 도메인 이름을 입력한다. DNS는 웹 페이지에 접속하는 도메인 이름을 IP 주소로 변환하는 프로세스이다.
DNS 프로세스는 아래와 같이 수행된다.
1. 브라우저에 도메인 이름을 입력하면 이 요청이 DNS Resolver 로 전송된다.
2. DNS Resolver는 회사 DNS 서버에서 웹 사이트에 해당하는 IP 주소를 요청한다.
3. DNS 서버에서는 웹사이트 주소를 제공하여 응답한다.
  Amazon Route 53
Amazon Route 53은 DNS 웹 서비스이다.
사용자 요청을 AWS에서 실행되는 인프라(예: Amazon EC2 인스턴스 및 로드 밸런서)에 연결한다. 또한 사용자를 AWS 외부의 인프라로 라우팅할 수 있다.
Route 53의 또다른 기능으로 도메인 이름의 DNS 레코드를 관리하는 기능도 존재한다. Route 53에 새 도메인 이름을 등록할 수 있고, 다른 도메인 등록 대행자가 관리하는 기존 도메인 이름 DNS 레코드를 전송할 수도 있다.

Route 53 및 AMazon CloudFront가 콘텐츠를 전송하는 방식은 아래와 같다.

고객이 회사의 웹 사이트로 이동하여 애플리케이션에서 데이터를 요청한다.
이 때, Amazon Route 53은 DNS 확인을 사용하여 웹 페이지의 IP 주소를 식별하여 고객에게 다시 전송한다.
고객의 요청은 Amazon CloudFront를 통해 가장 가까운 엣지 로케이션으로 전송된다.
CloudFront는 수신 패킷을 Amazon EC2 인스턴스로 전송하는 Application Load Balancer에 연결된다.
5. 스토리지 및 데이터베이스

인스턴스 스토어 및 Amazon Elastic Block Store(Amazon EBS)

인스턴스 스토어
- 블록 수준 스토리지 불륨은 물리적 하드 드라이버처럼 동작한다.
- 인스턴스 스토어는 AMazon EC2 인스턴스에 임시 블록 수준 스토리지를 제공한다. 물리적으로 EC2 인스턴스 호스트 컴퓨터에 연결되어 있고, 따라서 인스턴스와 수명이 동일한 디스크 스토리지이다. 따라서 인스턴스가 종료되면 인스턴스 스토어의 데이터도 손실된다.
  Amazon Elastic Block Store(Amazon EBS)
- Amazon Elastic Block Store(Amazon EBS)는 EC2 인스턴스에서 사용할 수 있는 블록 수준 스토리지 볼륨을 제공하는 서비스이다. EC2 인스턴스를 중지 또는 종료하더라도 연결된 EBS 볼륨의 모든 데이터를 사용할 수 있다.
- 일반적으로 EBS 볼륨은 보존해야 하는 데이터를 위한 것이므로 데이터 백업이 중요하다. Amazon EBS 스냅샷을 생성하여 EBS 볼륨을 증분 백업할 수 있다.
  Amazon EBS 스냅샷
- Amazon EBS 스냅샷은 증분 백업이다. 즉, 처음 볼륨을 백업하면 모든 데이터가 복사된다. 그 후 백업에서는 스냅샷 이후 변경된 데이터 블록만 저장된다.
  Amazon Simple Storage Service(Amazon S3)
  
  객체 스토리지
- 객체 스토리지에서 각 객체는 데이터,메타데이터,키로 구성된다.

데이터 : 이미지,동영상,텍스트 문서 저장
메타데이터 : 데이터의 내용, 사용방법, 객체 크기 등에 대한 정보 저장

키 : 고유한 식별자

Amazon Simple Storage Service(Amazon S3)

Amazon Simple Storage Service(Amazon S3)는 객체 수준 스토리지를 제공하는 서비스이다. Amazon S3는 데이터를 버킷에 객체로 저장한다.
Amazon S3는 저장 공간을 무제한으로 제공하고, 각 객체의 최대 파일 크기는 5TB 이다.
Amazon S3 스토리지 클래스
Amazon S3 역시 사용한 만큼 비용을 지불한다. 따라서 비즈니스 요구사항에 따라 다양한 클래스의 S3를 선택할 수 있다.

Storage Class	설명	접근 시간
S3 Standard	자주 액세스하는 데이터 (웹사이트, 동영상)	밀리초
S3 Standard-IA	가끔 액세스하는 데이터 (장기 데이터, 백업)	밀리초
S3 One Zone-IA	중요하지 않은 데이터의 저렴한 저장 (재생성 가능)	밀리초
S3 Intelligent-Tiering	액세스 패턴을 알 수 없거나 자주 변하는 데이터	밀리초
S3 Glacier Instant Retrieval	즉시 접근이 필요한 아카이브 데이터 (분기별 접근)	밀리초
S3 Glacier Flexible Retrieval	일반적인 아카이브 데이터 (감사 자료)	몇 분 ~ 몇 시간
S3 Glacier Deep Archive	거의 접근 없는 데이터의 최저가 보관 (규제 데이터)	몇 시간 이내

Amazon EBS와 Amazon S3 비교

S3의 경우 모든 객체에 URL이 있으며 이미지를 보거나 관리할 수 있는 사람에 대한 액세스 권한을 제어할 수 있다. 리전별로 분산되어 있어서 거의 100%의 내구성을 제공한다. 서버리스라는 이점도 존재한다.
EBS의 경우에는 작은 편집을 다수 수행할 때, 이점을 가진다. 증분 백업이기 때문에 변경된 사항만 추가적으로 저장된다.
즉 완성 객체를 사용하거나 변경 횟수가 적다면 S3를 사용해야 하는 것이 유리하고, 복잡한 읽기, 쓰기, 변경 기능을 수행한다면 EBS가 유리하다.

Amazon Elastic File System(Amazon EFS)

파일 스토리지

파일 스토리지는 여러 클라이언트(ex : 사용자, 애플리케이션, 서버)가 공유 파일 폴더에 저장된 데이터에 액세스할 수 있다.
스토리지 서버가 블록 스토리지를 로컬 파일 시스템과 함께 사용하여 파일을 구성한다.
쉽게 말하자면, 스토리지 서버(컴퓨터)는 똑똑한 관리인(파일 시스템)을 시켜서, 텅 빈 창고(블록 스토리지)를 우리가 보기 편한 파일과 폴더 구조로 깔끔하게 정리해서 사용하는 것이다.
파일 스토리지는 많은 수의 서브시 및 리소스가 동시에 동일한 데이터에 액세스해야 하는 사례가 이상적이다.
- 여러 개발자가 하나의 소프트웨어를 만들 때, 모두가 동일한 소스 코드 파일을 보고 수정하고 테스트해야 하는 상황이 존재한다. 각자의 컴퓨터와 빌드 서버가 중앙 코드 저장소에 동시에 접근한다. 이 때, 파일 스토리지의 역할은 팀의 공용 코드 라이브러리 역할을 수행한다.
** Amazon Elastic File System(Amazon EFS)**은 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용되는 확장 가능한 파일 시스템이다. 파일을 추가 또는 제거하는 경우 Amazon EFS가 자동으로 확장하거나 축소된다.
Amazon EBS vs Amazon EFS
Amazon EBS 볼륨은 단일 가용 영역에 데이터를 저장한다.
Amazon EFS는 리전별 서비스이다. 이 서비스의 경우 여러 가용 영역에 걸쳐 데이터를 저장한다.

Amazon Relational Database Service(Amazon RDS)

관계형 데이터베이스

관계형 데이터베이스에서는 데이터가 다른 데이터 부분관 관련된 방식으로 저장된다.
관계형 데이터베이스는 정형 쿼리 언어(SQL)를 사용하여 데이터를 저장하고 쿼리한다.
Amazon Relational Database Service(Amazon RDS)
Amazon Relational Database Service(Amazon RDS)는 AWS 클라우드에서 관계형 데이터베이스를 실행할 수 있는 서비스이다.
Amazon RDS는 인프라 구축 작업(하드웨어 프로비저닝, 데이터베이스 설정 ,etc..)을 자동화하는 관리형 서비스이다. 또한 AWS Lamdba를 사용하여 서버리스 애플리케이션에서 데이터베이스를 쿼리하는 애플리케이션을 설계할 수도 있다.
데이터베이스는 사용자의 중요 정보들이 저장되기 때문에 안전해야 한다. Amazon RDS는 다양한 보안 옵션을 제공한다. 대부분의 Amazon RDS 데이터베이스 엔진이 저장 시 암호화(데이터가 저장되는 동안 데이터를 보호) 및 전송 중 암호화(데이터를 전송 및 수신하는 동안 데이터를 보호)를 제공한다.
Amazon RDS 데이터베이스 엔진
Amazon RDS가 지원하는 엔진은 다음과 같다.
- Amazon Aurora
- PostgreSQL
- MySQL
- MariaDB
- Oracle Database
- Microsoft SQL Server

Amazon DynamoDB

비관계형 데이터베이스

관계형 데이터베이스와 비관계형 데이터베이스의 차이점은 테이블의 구성이 행과 열인지 아닌지로 구별할 수 있다. 비관계형 데이터베이스는 행과 열이 아닌 구조를 사용하기 때문에 NoSQL 데이터베이스라고도 한다.

관계형 데이터베이스 예시 :

ID	이름	주소	좋아하는 음료	생일
1	John Doe	123 Any Street	미디엄 라떼	(NULL)
2	Mary Major	100 Main Street	(NULL)	1994년 7월 5일

비관계형 데이터베이스 예시 :

키	값
1	이름: John Doe 주소: 123 Any Street 좋아하는 음료: 미디엄 라떼
2	이름: Mary Major 주소: 100 Main Street 생일: 1994년 7월 5일

Amazon DynamoDB

** Amazon DynamoDB** 는 키-값 데이터베이스 서비스이다.
DynamoDB는 서버리스이므로 서버를 프로비저닝 및 관리할 필요가 없다.
데이터베이스 크기가 축소 확장되면 DynamoDB는 용량 변화에 맞춰서 일관된 성능을 유지한다.

Amazon Redshift

실시간 읽기/쓰기 기능의 속도 관리를 위해 대부분의 관리형 데이터베이스는 특정 용량에서 과도하게 기능하는 경향이 있다. 최신 원격 분석과 IoT의 폭발적인 증가 때문에 데이터는 결국 최고 용량의 기존 관계형 데이터베이스로도 감당할 수 없는 양이 될 것이다.
Amazon Redshift는 빅 데이터 분석에 사용할 수 있는 데이터 웨어하우징 서비스
이 서비스는 여러 원본에서 데이터를 수집하여 데이터 간의 관계 및 추세를 파악하는 데 도움이 되는 기능을 제공한다.

AWS Database Migration Service(AWS DMS)

AWS DMS은 (비)관계형 데이터베이스 및 기타 유형의 데이터 저장소를 마이그레이션 할 수 있는 서비스이다.
온프레미스 또는 원본 데이터베이스와 대상 데이터베이스 간에 데이터를 이동 시킬 수 있다. 또한 원본과 대상 데이터베이스의 유형이 동일하지 않아도 동작한다.
마이그레이션 하는동안에도 계속 작동하기 때문에 애플리케이션의 가동 중지 시간을 줄일 수 있다.
사용사례는 다음과 같다.
- 개발 및 테스트 데이터베이스 마이그레이션 : 프로덕션 사용자에게 영향을 주지 않고 개발자가 프로덕션 데이터에서 애플리케이션을 테스트 할 수 있도록 지원
- 데이터베이스 통합 : 여러 데이터베이스를 단일 데이터베이스로 결합
- 연속 복제 : 일회성 마이그레이션을 수행하는 것이 아니라 데이터의 진행 중 복제본을다른 대상 원본으로 전송

6. 보안

AWS 공동 책임 모델

클라우드 리소스를 안전하게 유지할 책임은 누구에게 있을까? → AWS ? 혹은 사용자 ? 답은 둘다 책임이 존재한다. 이를 AWS 공동 책임 모델이라고 한다.
AWS 환경을 단일 객체로 취급하지 않기 때문이다. 클라우드 자체의 보안은 AWS가 책임을 지고, 클라우드 내부의 보안은 사용자가 책임을 진다.

클라우드 내부의 보안

AWS 내에서 생성하고 배치하는 모든 것의 보안을 책임진다.
AWS에 저장하기로 선택하는 콘텐츠, 사용하는 서비스, 콘텐츠에 액세스 할 수 있는 사용자를 포함하여 콘텐츠에 대한 보안 요구사항을 관리하는 책임은 고객에게 있다.

클라우드 자체의 보안

AWS는 인프라의 모든 계층에서 구성 요소를 운영, 관리 및 제어한다.
호스트 운영 체제, 가상화 계층,심지어 데이터 센터의 물리적 보안도 포함된다.
AWS는 AWS 클라우드의 모든 서비스를 실행하는 글로벌 인프라를 보호할 책임이 존재한다.

책임 주체	AWS 환경 구분
고객	고객 데이터
	플랫폼, 애플리케이션, Identity and Access Management(IAM)
	운영 체제, 네트워크/방화벽 구성
	클라이언트 측 데이터 암호화, 서버 측 데이터 암호화, 네트워크 트래픽 보호
Amazon Web Services(AWS)	소프트웨어: 컴퓨팅, 스토리지, 데이터베이스, 네트워킹
	하드웨어: 리전, 가용 영역, 엣지 로케이션

사용자 권한 및 액세스

AWS Identity and Access Management(IAM)

AWS Identity and Access Management(IAM)을 사용하면 AWS 서비스와 리소스에 대한 액세스를 안전하게 관리할 수 있다.
IAM을 통해 회사의 고유한 운영 및 보안 요구사항에 따른 액세스 권한을 다양하게 제공한다.
- IAM 사용자, 그룹 및 역할
- IAM 정책
- 다중 인증(MFA)
  AWS 계정 루트 사용자
AWS 계정을 처음 만들면 루트 사용자를 통해 시작한다.
루트 사용자는 계정의 모든 AWS 서비스 및 리소스에 대한 전체 액세스 권한을 소유한다. 따라서 일상 작업에는 루트 사용자를 사용하는 것을 지양한다.
대신 IAM 사용자를 생성 및 작업을 수행하여 최소 권한의 원칙을 목표로 해야 한다.

IAM 사용자
IAM 사용자는 AWS에서 생성되는 계정이다.
IAM 사용자를 처음 생성하면 해당 사용자와 연결된 권한이 없기 때문에 특정 작업을 수행할 수 있도록 필요한 권한을 부여해야한다.

IAM 정책
IAM 정책은 AWS 서비스 및 리소스에 대한 권한을 허용하거나 거부하는 문서이다.
IAM 정책을 사용하면 사용자가 리소스에 액세스할 수 있는 수준을 지정할 수 있다.
권한을 부여할 때 최소 권한을 부여하는 보안 원칙을 따르자. 해당 정책은 ID가 AWSDOC-EXAMPLE-BUCKET인 Amazon S3 버킷의 객체에 액세스할 수 있는 권한을 허용한다.

IAM 그룹

IAM 그룹은 IAM 사용자의 모임이다.
여러 IAM 사용자를 개별로 IAM 정책을 할당하려면 똑같은 작업을 반복적으로 수행해야되는 번거로움이 존재한다. 그룹에 IAM 정책을 할당하면 해당 그룹의 모든 사용자에게 정책에 지정된 권한이 부여된다.

IAM 역할

IAM 역할은 임시로 권한에 액세스하기 위해 수임할 수 있는 자격 증명이다.
IAM 사용자, 애플리케이션 또는 서비스가 IAM 역할을 수임하려면 먼저 해당 역할로 전환할 수 있는 권한을 부여받아야 한다. IAM 역할을 수임한다는 것은 이전 역할에 지정된 모든 이전 권한을 포기하고 새 역할에 지정된 권한을 수임하는 것이다.

다중 인증(MFA)

신원을 확인하기 위해서 여러 가지 정보를 제공하도록 로그인을 수행한 뒤 본인이 로그인을 했다는 것을 증명하기 위해서 두 번째 인증 형식을 제공하는 것을 다중 인중이라고 말한다.

AWS Organizations

AWS Organizations을 사용하여 중앙 집중식 여러 AWS 계정을 통합하고 관리 할 수 있다.
조직을 생성하면 AWS Organizations가 조직의 모든 계정에 대한 상위 컨테이너 루트를 자동으로 생성한다.
또한, 서비스 제어 정책(SCP)를 사용하여 조직의 계정에 대한 권한을 중앙에서 제어 할 수 있다.

조직 단위(OU)

AWS Organizations에서는 계정을 조직 단위(OU)로 그룹화하여 비슷한 비즈니스 또안 보안 요구 사항이 있는 계정을 쉽게 관리할 수 있다.
OU에 정책을 적용하면 OU 내 모든 계정에 자동으로 정책이 상속된다.

규정 준수

AWS Artifact

AWS 보안 및 규정 준수 보고서 및 일부 온라인 계약에 대한 온디맨스 엑세스를 제공하는 소비스
- AWS Artifact 계약
  - 개별 계정 및 AWS Organization 내 모든 계정에 대한 계약을 검토, 수락 및 관리를 할 수 있다.
- AWS Artifact 보고서
  - 외부 감사 기관이 작성한 규정 보고서를 제공한다.
    서비스 거부 공격
    
    서비스 거부 공격(DoS)
서비스 거부 공격은 사용자들이 웹 사이트 또는 애플리케이션을 이용할 수 없게 만드려는 의도적인 시도이다.
과도한 네트워크 트래픽으로 플러드하게 된다면 애플리케이션을 사용할 수 없게 되면 합법적인 요청을 시도하는 사용자에게 서비스를 거부한다.
분산 서비스 거부 공격
분산 서비스 거부(DDoS) 공격에서는 여러 소스를 사용하여 웹 사이트 또는 애프릴케이션을 사용할 수 없게 만드는 공격을 수행한다.
여러 소스를 사용하여 애플리케이션을 사용할 수 없는 공격을 만든다. 공격자는 한 명일 수도 그룹일 수도 있다.

AWS Shield

AWS Shield는 DDoS 공격으로부터 애플리케이션을 보호하는 서비스이다. 2가지 옵션 Standard, Advanced 를 제공한다.
- Standard
  - DDoS 공격으로부터 보호한다. 모든 AWS 고객을 자동으로 보호하는 무료 서비스이다.
- Advaned
  - 상세한 공격 진단 및 정교한 DDoS 공격을 탐지하고 완화할 수 있는 기능을 제공하는 유료 서비스이다.
  - 또한 복잡한 DDoS 공격을 완화하기 위한 사용자 지정 규칙을 작성하여 AWS Shield를 AWS WAF와 통합할 수 있다.
    추가 보안 서비스
    
    AWS Key Management Service(AWS KMS)
AWS Key Management Service(AWS KMS)를 사용하면 암호화 키를 사용하여 암호화 작업을 수행할 수 있다. 또한 KMS를 이용해 암호화 키를 생성, 관리 및 사용할 수 있다.
AWS WAF
AWS WAF 는 웹 애플리케이션으로 들어오는 네트워크 요청을 모니터링하는 웹 애플리케이션 방화벽이다.
AWS WAF를 이용해 여러 IP 리소스들이 ACL 규칙에서 허용되어있는지 거부되는지 파악하여 특정 IP들만 접근할 수 있도록 한다.

Amazon GuardDuty

** Amazon GuardDuty** 는 AWS 인프라 및 리소스에 대한 지능형 위협 탐지 기능을 제공하는 서비스이다. GuardDuty는 AWS 환경 내의 네트워크 활동 및 계정 동작을 지속적으로 모니터링하여 위협을 식별한다.

7. 모니터링 및 분석

Amazon CloudWatch

다양한 지표를 모니터링 및 관리하고 해당 지표의 데이터를 기반으로 경보 작업을 구성할 수 있는 웹 서비스
CloudWatch는 지표를 사용하여 리소스의 데이터 포인트를 나타낸다.
AWS 서비스는 지표를 CloudWatch로 보내고, CloudWatch가 이러한 지표를 사용하여 시간 경과에 따른 성능이 어떻게 변화했는지 ** 그래프**를 자동으로 생성한다.

CloudWatch 경보

지표 값이 미리 정의된 임계값을 상회 또는 하회할 경우 자동으로 작업을 수행하는 경보를 생성한다.

AWS CloudTrail

AWS CloudTrail은 계정에 대한 API 호출을 기록한다.
기록된 정보에는 API 호출자 ID, API 호출 시간, API 호출자의 소스 IP 주소 등이 포함된다. 쉽게 말하자면 CloudTrail은 데이터 트래픽의 이동 경로를 추적한다고 생각해도 된다.
API 호출을 사용하여 AWS 리소스를 프로비저닝, 관리 및 구성할 수 있다.
CloudTrail Insights
해당 옵션을 사용하면 CloudTrail이 AWS 계정에서 비정상적인 API 호출을 자동으로 감지할 수 있다.

Architecting on AWS 3일차

Sun, 06 Jul 2025 10:53:45 GMT

Module 9 컨테이너

모놀리식 아키텍처와 마이크로 서비스 아키텍처의 비교
- 모놀리식 아키텍처 : 하나의 애프릴케이션 안에 모든 기능이 긴밀하게 연결되어 있다. 한 기능에서 에러 발생시 다른 부분에 영향을 미치기 쉽고 서비스 전반적인 부분에 에러가 생길 수도 있다.
- 마이크로 서비스 : 각 기능을 독립적인 작은 서비스 단위로 나누어 느슨하게 연결 되어있다. 특정 서비스에 문제가 생겨도 다른 서비스에 미치는 영향이 최소화되어 있다.
마이크로 서비스의 등장배경 : 개발팀과 운영팀을 합쳐 빠르고 안정적인 서비스 제공을 목표로 하는 DevOps 문화가 정착하는 과정에서, 이를 기술적으로 뒷받침하기 위한 CI/CD 파이프라인과 IaC가 발전하게되었따. 또한 이러한 자동화된 개발/배포 환경에 장점을 활용하기 위한 적합한 아키텍처 스타일인 마이크로서비스가 함께 부상하게 되었다.

컨테이너

애플리케이션의 코드와 런타임 엔진, 구성 및 종속성을 하나의 표준화 이미지로 패키징화
시스템의 운영체제 커널을 공유, Docker와 같은 플랫폼을 통한 실행 관리
반복 가능, 독립적 환경, VM보다 더 빠른 애플리케이션 가동 속도, 이식성

AWS에서 컨테이너 실행을 위한 서비스

레지스트리 : 컨테이너 이미지를 리포지토리에 Push 저장, 이미지를 Pull하여 컨테이너 배포
컨테이너 호스팅 : 컨테이너를 실행하는 기반 컴퓨팅 리소스, 컨테이너 시작 유형
오케스트레이션 도구 : 컨테이너 애플리케이션의 용량 조정, 네트워킹 및 유지 관리 작업 수행

Amazon ECS & Amazon EKS

실제 현업에서는 수십개 및 수백 개의 컨테이너 들이 존재하기 때문에 이를 개별적으로 관리하는 것이 매우 어렵다. 컨테이너들을 관리하기 위한 도구가 AWS에서는 ECS와 EKS가 존재한다.
Amazon ECS(Elastic Container Service)
컨테이너 구축 및 배포 경험이 없는 사람도 손쉽게 컨테이너 배포 및 운영 가능하다.

Amazon EKS(Elastic Kubernetes Service)

오픈소스 생태계 도구에 익숙한 분, k8s(Kubernetes) 명령어 및 관리 기반 대규모 운영이 가능하다.
k8s controlplane : eks에서는 aws manages
k8s dataplane(k8s worknode) : 실제 컨테이너들이 배포되는 공간

Module 10 네트워킹 2

VPC 엔드포인트

VPC 리스소와 AWS 서비스 엔드포인트와의 연결을 프라이빗 상태로 유지한다.
기존에는 리전 레벌의 서비스들(S3, DynamoDB 등)과 API를 주고 받기 위해서는 인터넷 게이트웨이와 NAT 게이트웨이를 통해서야만 했다. 인터넷을 통해서 통신을 하게 되는 경우 데이터 탈취나 외부 공격에 대한 보안 문제도 발생할 수 있기 때문에 VPC 내부 리소스와 직접적으로 연결시키고자 할 때 사용하는 도구가 VPC 엔드포인트이다.
Gateway Endpoint
S3, DDB 대상으로 추가 비용 없이 사용할 수 있는 가상 라우터
Interface Endpoint
AWS 서비스 대상으로 생성되는 ENI 그리고 프라이빗 링크

VPC 피어링

VPC 간에 1:1로 연결하여 트래픽을 프라이빗으로 라우팅
리전 내, 리전 간 피어링 그리고 교차 계정 피어링을 지원한다. 주의할 점은 CIDR 주소 체계(사설 IP 주소)가 동일하면 연결할 수 없다.

Site-to-Site VPN

VPC의 가상 프라이빗 게이트웨이(VGW)와 온프레미스 네트워크 디바이스 간의 VPN 연결 ex) 웹서버와 백엔드 서버는 aws 서비스를 사용하고, DB 서버를 온프레미스 서버에 두었을 때

AWS Direct Connect

데이터 센터에서 AWS 리소스까지의 프라이빗 광 연결 기반 링크 구축
물리적인 연결 : dedicated connected(고객 라우터와 AWS 라우터의 물리적인 연결을 수행 시키는 것), hosted connection(만약 고객 라우터와 AWS 라우터와 물리적인 연결이 어려울 시 파트너사의 라우터를 이용해 물리적 연결을 수행)
논리적인 연결 : public virtual interface, private virtual interface

Transit Gateway

단일 게이트웨이가 허브의 역할, 여러 VPC와 온프레미스(VPC, Direct Connect)를 연결
리전 간의 transit gateway 피어링 연결이 가능하다.

Module 10 서버리스

서버리스의 서비스의 정의

AWS에서 서비스 제공에 필요한 인프라의 프로비저닝, 용량 조절, 보안, 고가용성을 직접 관리한다.
사용자의 입장에서 기반 인프라가 보이지 않는다. 오직 애플리케이션 관련 작업에서 더 집중해서 수행하면 된다.
컴퓨팅, API 프록시, 스토리지, 인증, 메시징, 오케스트레이션, 분석 등 서비스를 제공

API Gateway

백엔드 서비스의 API 생성 및 배포 관리를 수행하는 관리형 서비스
여러 마이크로 서비스의 통합 Frontend로 구성 가능
Rest ful, Http, WebSocket 프로토콜 지원, 서명을 통한 인증받은 클러이언트에만 접근 부여가 가능

Amazon SQS(Simple Queue Service)

대기열 서비스로 애플리케이션 구성 요소 사이에 배치, 메시지 처리한 소비자가 메시지 삭제
메시지 생산자와 소비자간 일대일 관계
비동기식 느슨한 결합을 통해, 실패한 메시지 처리에 대한 내결함성 제공

Amazon SNS(Simple Notification Service)

하나 주제의 여러 구독자 대상으로 메시지를 전송하는 서비스
주제의 메시지 게시자와 구독자간 일대다 관계
주제에 등록된 메시지는 바로 구독자에게 전송
경보 알림, 푸쉬 알림, 이메일 전송의 용도로 사용된다.

Module 12 엣지 서비스

Route 53

DNS, 도메인 이름 등록 및 상태 확인 기능 제공
지연시간, 상태 확인 및 여러 기준에 따라 요청을 라우팅
리전 수준에서의 장애 조치 지원

Cloudfront

AWS 글로벌 인프라를 이용한 콘텐츠 전송 네트워크 서비스 제공
AWS WAF 및 Shield 지원
정적 콘텐츠 캐싱 및 동적 콘텐츠에 대한 최적화 전송 기능 지원
내장된 보안 기능 지원

AWS Shield

AWS에서 애플리케이션을 보호하는 관리형 DDoS 보호 서비스
Shield Standard(무료 구독 모델) : 인프라 계층의 DDoS를 보호하는 추가 비용 없이 이용 가능
Shield Advanced(유로 구독 모델) : EC2, ELB, Cloudfront, ROute 53 기반 애플리케이션의 DDoS 보호, 지원

AWS WAF(Web Application Firewall)

일반적인 웹 공격 및 봇으로부터 웹 애플리케이션 API를 보호하는 데 도움이 되는 웹 방화벽
웹 ACL은 여러 규칙들로 구성, AWS/마켓플레이스 관리형 규칙 그룹 또는 사용자 규칙을 추가
트래픽 필터링 (CIDR, 국가별), 패턴 일치 (정규식, 문자열, 크기), 논리 연산 (AND,OR,NOT)

AWS Outposts

사무실 또는 데이터센터에 온프레미스에 AWS 서비스를 호스트
AWS Outposts 랙 또는 1U/2U 크기 Outposts 서버 중에서 선택

Architecting on AWS 2일차

Thu, 03 Jul 2025 00:25:05 GMT

Module 5 스토리지

클라우드 환경에서 스토리지 선택 기준

블록 스토리지 : 한 서버 내에서 애플리케이션을 실행하기 위한 디렉토리 역할, 하드 드레이브 처럼 인식
파일 스토리지 : 여러 서버들의 공유 파일로의 사용되는 디렉토리 역할
객체 스토리지 : 다양한 정적 파일을 여러 디바이스에 분산 저장, 메타데이터 및 키와 함께 객체화 하여 저장, 웹 스토리지 형태

구분	블록 스토리지	파일 스토리지	객체 스토리지
데이터 단위	블록 (Block)	파일 (File)	객체 (Object)
구조	주소 기반	계층적 구조 (폴더/파일)	평평한 구조 (Key-Value)
주요 프로토콜	iSCSI, Fibre Channel	NFS, SMB/CIFS	HTTP/HTTPS (REST API)
성능	매우 빠름 (낮은 지연 시간)	빠름	대역폭에 따라 다름
확장성	제한적	보통	매우 뛰어남
핵심 장점	고성능, 직접 제어	쉬운 사용, 데이터 공유	뛰어난 확장성, 메타데이터
대표 서비스	Amazon EBS	Amazon EFS	Amazon S3
## Amazon S3 (Simple Storage Service)

정적 파일을 데이터, 메타데이터, 키의 조합의 객체로서 저장하는 서버리스 객체 스토리지 서비스
사용 예시 : 데이터 백업, 미디어 저장 및 스트리밍, 정적 웹 사이트, 데이터 레이크, 아카이빙
객체들에게 액세스하기 위해서 2가지 정책을 활용한다.
- 버킷 정책 : 버킷과 연결되는 IAM 리소스 기반 정책
- 액세스 포인트 정책 : 버킷을 향하는 별도의 엔드포인트에 연결되는 리소스 기반 정책
버킷에서 객체의 암호화 : S3 관리형 키, KMS 키, 고객 관리형 키

S3 스토리지 클래스
데이터 요청에 자주 사용되는 클래스
- S3 Standard : 자주 액세스하는 데이터, 밀리초 내에 액세스
- S3 Interlligent-Tiering : 액세스 패턴이 바뀌거나 알 수 없는 객체 자동 이동, 밀리초 내에 액세스
- S3 Standard-IA : 자주 액세스하지 않는 데이터, 밀리초 내에 액세스, 최소 30일 유지 필요
- S3 One Zone-IA : 하나의 가용영역에만 저장하고 자주 액세스하지 않는 데이터, 밀리초 내에 액세스, 최소 30일 유지 필요
데이터 복원에 자주 사용되는 클래스
- S3 Glacier Deep Archive : 복원할 가능성이 거의 없는 아카이브 데이터(ex : 탈퇴한 회원의 개인자료를 1년 동안 저장이 필요할 때), 복원 시간 12시간 이내
- S3 Glacier Flexible Retrieval : 복원 필요성을 예측할 수 없는 객체, 복원 시간 몇 분(신속) ~ 몇 시간(일반)
- S3 Glacier Instant Retrieval : 빠르게 복원해야 하는(ex : 보안사고로 발생시 빠르게 복구해야할 경우 ) 아카이브된 데이터

S3 스토리지 추가 기능

버전 관리 : 한 객체의 여러 버전을 보관, 의도치 않는 데이터 유실 및 덮어쓰기/삭제로부터 빠른 복구가 가능, 많은 버전을 소유시에 저장 비용이 증가하기 때문에 버전 수명 주기도 관리해야 한다.
멀티 파트 업로드 : CLI/SDK에서 객체 병렬 업로드, 업로드 일시 중지 및 재개 가능
Transfer Acceleration : 엣지 로케이션과 최적화된 경로로 클라이언트와 버킷의 전송 향상
이벤트 알림 : 버킷에서 이벤트 발생시 알림을 SNS 주제, SQS 대기열, Lambda 함수로 전송

Amazon EFS(Elastic File System)

NFS 프로토콜 사용, EC2 인스턴스, 컨테이너, 람다 함수를 지원, 최소 용량 없는 파일 스토리지
활용 예시 : DevOps, 웹 콘텐츠, 기계 학습, 분석, 검색 인덱스, 마이크로서비스 등 상태 저장 애플리케이션

Amazon FSx

Windows, Lustre, Netapp ONTAP, OpenZFS 파일 서버를 지원하는 공유 파일 스토리지
워크로드 마이그레이션 및 백업, 개발 환경, 기계 학습, 분석, HPC, 미디어 시스템

AWS 데이터 마이그레이션 도구

온라인 이용
- AWS Storgae Gateway : 애플리케이션이 SMB, NFS, iSCSI 프로토콜로 S3 스토리지 액세스
- AWS DataSync : 온프레미스 파일 스토리지와 S3, EFS, FSx와의 주기적인 동기화
- AWS Transfer Family : SFTP, FTP, FTPS 프로토콜로 S3와의 파일 전송
오프라인 이용
- AWS Snow Family : 대량의 디스크가 포함된 어플라이언스 장비

Module 6 데이터베이스

관계형 데이터베이스vs 비관계형(Nosql) 데이터 베이스

관계형 데이터베이스	비관계형 데이터베이스
엄격한 스키마 규칙 및 데이터 품질 적용이 필요	데이터베이스 크기를 수평으로 조정 필요
과도한 읽기/쓰기 용량을 필요로 하지 않는다.	데이터가 기존 스키마에 적합하지 않음
자원 소비가 적다.	읽기/쓰기 속도가 기존 정형 쿼리언어 보다 빠르다.

AWS 관리형 서비스와 비관리형 서비스의 차이(그림 만들기 필!)

Amazon RDS (Relational Database Service)
관계형 데이터베이스를 AWS 관리형 인스턴스로 배포 관리한다.
보안 그룹 지원, 저장 데이터 및 전송 데이터 암호화 가능
인스턴스(컴퓨팅 및 볼륨 스토리지) 용량 조정
2개 이상의 가용 용역에 배포 및 읽기 복제본이 지원된다.

Amazon Aurora

클라우드를 위해 구축한 Mysql, PostgresSQL 호환 관계형 데이터베이스
스토리지를 여러 가용 영역에 걸쳐있는 가상 스토리인 클러스터 볼륨으로 제공한다.
서버리스 V2 모델 지원 : 2GB 메모리에 상응하는 컴퓨팅과 네트워크를 1 ACU로 용량 측정

Amazon DynamoDB

키-값 기반의 비관계형 데이터베이스를 서버리스 완전 관리형으로 제공한다.
일기/쓰기별 처리 용량을 측정하기 위한 용량 유닛을 사용한다.
테이블의 기준 파티션 키 및 용량 관리 옵션 지정 - Provisioned, On-demand 이다.
일반적으로 1초 내에 3개의 가용 영역에 걸쳐서 테이블 데이터를 복제한다.(그림 생성 필!)

DynamoDB 글로벌 테이블

리전 간 복제본이 모두 Active 데이터베이스 역할을 담당하는 기능을 수행한다.
RDS와 Aurora 는 읽기 전용 복제본이 생성되는 것과 달리 DynamoDB는 읽기/쓰기가 가능

데이터베이스 캐시

Client가 데이터베이스에 접근하는 성능을 최대한 높이기 위해 데이터베이스 계층 앞단에 캐시를 추가로 배치 가능하다.
캐시와 데이터베이스와의 동기화 필요 : 레이지 로딩, 라이트 스루 전략 사용

애플리케이션의 데이터베이스 캐시를 고려해야 하는 케이스
- 쿼리 속도가 느리고 비용이 많이 드는 데이터 존재 : 여러 테이블에 걸쳐서 조인을 수행하는 쿼리
- 비교적 정적이면서 액세스 빈도가 높은 데이터 존재 : SNS 서비스의 프로필

Module 7 모니터링 및 크기 조정

AWS 클라우드에서 모니터링해야 할 대상 리소스 리스트
- 배포한 AWS 리소스의 성능 지표
- 로그를 남기는 AWS 리소스
- EC2 위에 배포한 애플리케이션의 로그
- AWS 계정 내의 API 호출과 응답
- VPC 내에 오가는 IP Packet
AWS 클라우드에서의 모니터링 알림 설정
- AWS 리소스의 성능 값에 대한 임계치 설정 후 벗어날 시 수행할 작업 정의
- 여러 리소스에서 발생되는 이벤트를 갭쳐 후 이에 따라 수행할 작업 정의

Cloudwatch

리소스의 성능 지표 및 로그 그리고 지표에 대한 임계치 경보를 설정, 임계치 초과시 수행할 작업을 정의
Cloudwatch Agent를 이용해서 시스템의 어떤 지표를 수집할지 여부를 설정한다.

EventBridge

여러 리소스의 이벤트를 규칙으로 선언하고, 발생시 이에 따른 작업을 대상에게 라우팅

AWS CloudTrail

계정 내 대부분의 AWS 서비스에 대한 API 호출 및 응답을 S3에 로깅
계정 내에 보안 이슈가 발생했을 때 확인을 위해서 사용 가능

VPC 흐름 로그

VPC ENI(Elastic Network Interface)에 송수신되는 IP 트래픽 정보 수집

Elastic Load Balancing

여러 컴퓨팅 리소스 대상으로 자동으로 트래픽 분산 및 상태 확인 수행
가용 영역 수준에서의 고가용성 및 보안 기능 제공

ELB의 구성요소

리스너 : 클라이언트의 요청을 받아주는 역할
대상 그룹 : 클라이언트로 부터 요청을 받았을 때 이를 처리하는 대상이 속해있는 그룹
규칙 : 리스너로부터 들어오는 트래픽을 대상 그룹으로 어떻게 전달할 것 인지

ELB 로드 밸런서 종류 및 기능 비교

웹 애플리케이션을 위한 ELB
- Application Load Balancer : HTTP(s) 기반
- Network Load Balancer : TCP/UDP 기반
보안 솔루션 대상인 ELB
- Gateway Load Balancer : IP/TCP 기반
Auto Scaling을 지원하는 서비스
- EC2 인스턴스의 수량
- DynamoDB 테이블의 읽기/쓰기 용량 유닛
- Aurora Reader Node
- Amazon ECS task 수량
- Lambda 함수 프로비저닝된 동시성

Amazon EC2 Auto Scaling

EC2의 인스턴스의 수량 조절을 자동화
- 상태 확인
- CLoudWatch 경보
- 일정
- 수동 크기 조정
Module 8 자동화

AWS CloudFormation
- infrastructure as a Code : AWS 리소스를 코드 형태로 배포, 업데이트 및 삭제
- IaC 의 예시로 대표적인 것이 terraform, AWS 자체 서비스는 CloudFormation 이 존재한다.
기타 AWS 인프라 배포 및 관리 도구
- AWS Elastic Beanstalk : AWS에서 프로비저닝 및 운영하는 EC2 기반 인프라 제공
- AWS 솔루션 라이브러리 : AWS 아키텍처가 승인한 CloudFormation 기반 아키텍처 레퍼런스
- AWS CDK : Python, JavaScript 등의 프로그래밍 언어로 Cloudformation 템플릿 생성 배포
- Amazon Q Developer : AI 기반의 코드 도우미 및 보안 스캐너
- AWS Systems Manager : EC2 인스턴스의 구성, 운영 및 규정 준수 관리

Architecting on AWS 1일차

Wed, 02 Jul 2025 00:24:24 GMT

Module 1 : Archtecting 기본 사항

AWS 특징

종량제 : 쓴만큼 비용 청구, 초기 리소스에 구현에는 온프레미스 대비 비용절감이 확실하지만 점차 서비스를 구성해 나아가면 온프레미스와 거의 비용이 동일하다.
- tmi : AWS는 Hard Limit이 존재하지 않아서 모니터링으로 비용 관리가 필수적이다!
빠른 리소스 생성 : 민첩성이 증가하여 출시 시간 단축 및 원활한 크기 조정이 가능하다.
관리형 서비스 : 복잡성 및 위험 감소가 가능
공동 책임 모델 : AWS 글로벌 인프라 모델의 특징, AWS 클라우드 자체에 대한 보안은 AWS가 책임지고, AWS 클라우드 내부의 보안은 운영 기업에서 책임져야 한다.

AWS 글로벌 인프라

리전을 선택하는 case : 거버넌스, 지연 시간 요구 정도, 서비스 가용성(리전마다 제공하하는 서비스가 다름), 비용 요인 측면
리전 내의 가용영역의 경우 수십 km 거리를 둔다 → 장애 및 재난에 대응하기 위해서
Local Zone : 최소한의 지연시간을 제공하기 위해서 기존 리전 영역 안에 있는 가용영역과 달리 핵심 인프라 서비스(EC2 , VPC ,EBS ,RDS ,etc.)만 따로 구성해둔 영역이다.

클라우드 운영 최적화 요소 모범 사례

보안 : 모든 계층, 최소 권한의 원칙,MFA(다중 인증)
성능 효율성 : 지연 시간 감소, 서버리스 아키텍처, 모니터링
비용 최적화 : 지출 분석, 비용 효율적인 리소스
운영 우수성 : 코드로 운영 수행, 예상 외의 이벤트 발생 시 대응 테스트
신뢰성 : 장애에서 복구, 복구 절차 테스트, 가용성 향상을 위한 스케일링
지속 가능성 : 영향 파악, 사용률 최대화

AWS 아키텍츠의 역할

계획

비즈니스 책임자와 함꼐 기술분야의 클라우드 전략을 수립 및 솔루션 분석
조사
클라우드 서비스 사양과 워크로드 요구사항을 조사
기존 워크로드 아키텍처를 검토 및 프로토타입 솔루션 설계
구축
마일 스톤, 작업 스트림 및 소유자가 포함된 전환 로드맵 설계
기술 도입 및 마이그레이션을 관리

Well-Architected Framework 을 이용해서 모범 사례 비교 가능

Well-Architected Tool 6개월, 1년마다 지속적으로 검토 수행

Practice 1 : AWS 관리 콘솔 및 AWS CLI 살펴보기 및 사용

AWS 관리 콘솔을 사용하여 Amazon S3 버킷 생성

버킷 생성 생성 완료 모습

S3 콘솔을 사용하여 Amazon S3 버킷에 객체 업로드

AWS CLI를 사용하여 Amazon S3 버킷을 생성한 후 객체 업로드

EC2 인스턴스에 접속 후 터미널창에서 CLI 명령어를 통해 실습을 해본다.
AWS 에 존재하는 S3 bucket 리스트 확인 :aws s3 ls
버킷 추가 : aws s3 mb s3://<버킷 이름>
AWS 버킷에 객체 복사 수행 : aws s3 cp /home/ssm-user/HappyFace.jpg s3://<버킷 이름>
AWS 버킷 내부 파일 리스트 확인 : aws s3 ls s3://<버킷 이름>

Module 2 : 액세스 관리

AWS 계정 루트 사용자
- 단일 계정 내 모든 AWS 서비스에 대한 제한 없는 액세스 권한 보유
- 일반적인 업무에는 사용하는 것은 비추천
- MFA 적용을 통한 인증 강화
AWS IAM(Identity and Access Managemnet) 서비스의 정의
- AWS 계정 내의 인증과 권한 부여를 다루는 보안 서비스
AWS IAM에서 다루는 보안 주체
- IAM 사용자 : AWS 계정 내의 사용자
- 페더레이션 사용자 : AWS 외부에서 인증을 받은 사용자 ex) 온프레미스에서 인증받은 사용자를 AWS에 연계용자를 AWS에 연계
- 애플리케이션 : AWS 리소스에 접근하고자 하는 애플리케이션
- IAM 역할 : 임시 기간으로 인증 및 권한을 부여 받은 보안 주체
  역할 수임

신뢰할 수 있는 엔티티(IAM 사용자, AWS 서비스, 페더레이션 사용자)에서 API 호출을 사용해 역할을 수임한다.API 호출은 AWS Security Token Service(AWS STS) 에 대해 수행한다.
프로덕션 계정(AWS STS)에서 액세스 키 ID,비밀 액세스 키 및 보안 토큰으로 구성된 임시 보안 자격 증명 집합을 반환한다.
임시 보안 자격 증명을 통해서 AWS 리소스에 액세스 한다.
IAM 정책 할당

IAM 사용자 그룹에게 IAM 정책을 연결하여 권한 부여 → IAM 사용자 그룹에 소속된 사용자는 권한을 상속받는다.
- IAM 정책 : 하나 이상의 권한으로 이루어지는 JSON 형태의 문서
AWS Organizations
- 여러 AWS 계정을 하나의 계층화된 조직으로 구성
- 하나 이상의 AWS 계정을 조직 단위(OU)로 그룹화 가능
- 관리 계정(루트)가 전체 조직을 관리하며 통합 결제 처리
- 다중 계정 구조를 생성하는 이유
  - 분류 및 검색을 위해 리소스를 그룹화
  - 논리적 경계를 통해 보안 태세를 개선
  - 무단 액세스가 발생할 경우 잠재적 영향을 제한
  - 다양한 환경에 대한 사용자 액세스를 간편하게 관리

AWS Organization 사용

계정을 조직 단위(OU)단위로 그룹화 하여 계층을 생성
서비스 제어 정책(SCP)을 적용하여 OU에 속한 모든 계정의 최대 권한을 제어한다.

SCP vs 권한 경계

조직용으로 구성되어있는 SCP를 통해 작업을 허용해야 한다.
자격 증명 기반 정책이 작업을 허용해야하며 명시적으로 거부하지 않아야 한다.
마지막으로, 적용되어 있는 권한 경계 작업 내의 작업이 포함되어야 한다.

명시적 허용 vs 명시적 거부

IAM 정책에서는 명시적 허용 또는 명시적 거부 작업이 포함되어야한다.

Module 3 네트워킹

VPC 설계를 위한 구성요소

IP 주소

CIDR 블록을 통해서 IP 범위를 지정한다.
VPC에서 지원하는 CIDR 블록(/16~/28)
VPC
클라우드 네트워크 환경
사용자가 정의한 가상 네트워크 안에 AWS 리소스를 프로비저닝 할 수 있다.
리전 내 어떤 가용 영역에서나 리소스를 호스트 할 수 있다.
서브넷
VPC 내의 IP 주소 범위이다.
인터넷에 연결되어야 하는 리소스는 퍼블릭 서브넷에 사용하고, 인터넷에 연결되지 않은 리소스는 프라입시 서브넷을 사용한다.
각 서브넷 CIDR 블록에 처음 4개(네트워크 주소, VPC 라우터용, DNS 서버, 추후 사용을 위한 예약), 마지막 주소(브로드 캐스트 주소)는 사용할 수 없다.
인터넷 게이트웨이
VPC 내 인스턴스와 외부 인터넷과의 트래픽 허용한다.
VPC 내의 인터넷 게이트웨이를 사용하는 목적
- 인터넷 라우팅이 가능한 트래픽에 대한 라우팅 테이블의 대상을 제공
- NAT를 수행하여 네트워크의 IP 주소를 보호
  라우팅 테이블
VPC가 네트워크 트래픽이 전달되는 위치를 결정하는데 사용되는 규칙을 포함한다.
VPC 내의 각 서브넷은 라우팅 테이블과 연결되어야 한다.

NAT 게이트 웨이

프라이빗 주소가 퍼블릭 IP 주소에 매핑되므로 NAT를 사용하면 프라이빗 IP 주소의 인터넷 연결을 허용할 수 있다.

네트워크 ACL

하나 이상의 서브넷에 송수신되는 트래픽을 제어하는 방화벽 역할을 하는 가상 방화벽이다.
기본적으로 사용자 정의 네트워크 ACL은 규칙을 추가하기 전에는 모든 인바운드 및 아웃바운드 트래픽을 거부한다.

보안 그룹

인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 한다.
보안 그룹은 서브넷 수준이 아닌 인스턴스 수준에서 작동하며 허용 규칙만 지원한다.

Module 4. 컴퓨팅

Amazon EC2 (Elastic Compute Cloud)

Nitro 시스템 하이퍼바이저 기반 가성 서버를 제공하는 컴퓨팅 서비스
온프레미스 서버처럼 다양한 애플리케이션 실행에 사용된다.
EC2 인스턴스 시작시 고려사항
이름 및 태그
애플리케이션 및 OS 이미지
인스턴스 유형 및 크기
키 페어
네트워크 및 보안
스토리지
배치 및 테넌시
스크립트 및 메타 데이터
AWS 리소스 태그
생성한 AWS 리소스에 이름 및 기타 태그를 할당해준다.
리소스를 관리하거나 검색 및 필터링 하는데 사용된다.
태그는 키와 값으로 구성되며, 구성 요소 모두 대소문자 구분이다.
태그는 AWS 사전 정의 태그와 고객 태그로 구분될 수 있다.
- AWS 사전 정의 태그 예시 : aws:ec2spot:fleet-request-id = sfr-1111222-3333-444-555-6666 (스팟 인스턴스 요청을 식별)
- 고객 태그 예시 : example-corp:cost-center = 4000 (내부 비용 코드를 식별)
  Amazon Machine Image (AMI)
인스턴스 볼륨의 템플릿, 시작 권한 및 블록 디바이스 매핑 포함
AMI 자체가 백업 이미지이며, 여러 동일 인스턴스 배포 및 장애 복구용으로 사용

인스턴스 유형 이름

EC2 인스턴스의 Spec으로 컴퓨팅, 메모리, 네트워크 및 내장 스토리지 용량을 정의한다.
인스턴스 패밀리, 세대, 추가 속성 및 인스턴스 크기로 구성된다.
EC2 인스턴스 패밀리
- 범용
- 메모리 최적화
- 스토리지 최적화
- 컴퓨팅 최적화
- 가속 컴퓨팅
  네트워크 및 보안
EC2를 배치할 VPC 그리고 서브넷을 지정해야 한다.
인스턴스 수준의 가상 방화벽인 보안 그룹을 지정한다.

테넌시와 배치 그룹
공유 테넌시, 전용 인스턴스, 전용 호스트
클러스터 배치그룹, 분산형 배치그룹(물리적으로 떯어트린다.) , 파티션 배치그룹

사용자 데이터

EC2 인스턴스 생성시 실행되는 bash 및 powershell 스크립트
인스턴스를 구성 또는 관리하는데 사용하는 인스턴스 메타데이터를 사용자 데이터에 포함
EC2 인스턴스를 부트스트래핑하는데 활용
- bootstraping : ec2 인스턴스가 시작될 떄마다 애플리케이션, 종속성 또는 사용자 지정을 설치하는 것
  - 장점 : 항상 최선 버전 구성이 가능
  - 단점 : user data 스크립트에 시간이 오래걸린다.
- baking : 애플리케이션 아티팩트의 상당 부분을 AMI 내에 임베딩하는 프로세스
  - 장점 : 빠르게 App 배포 할 수 있다.
  - 단점 AMI를 지속적으로 업데이트해야한다.

Amazon EBS (Elastic Block Store)

서버에 Mount 해서 사용하는 블록 스토리지
EC2의 파일 시스템으로서 운영 체제와 애플리케이션 작동 및 데이터를 영구 저장한다.
Amazon EBS 볼륨을 생성할 떄 고려할 부분
- 어떤 가용영역을 사용할 것인지
- SSD, HDD 선택 여부
스냅샷을 통해 볼륨 백업이 가능하다.

AWS Lambda

서버리스, 상태 비저장 컴퓨팅 서비스이다.
애플리케잇녀 코드와 종속성 요소를 함수로 패키징 할 수 있다.
다른 AWS 서비스 및 HTTPs Endpoint에 의한 이벤트 트리거가 필요하다.
웹 애플리케이션, 백엔드, 데이터 처리, IT 자동화 등 다양한 용도로 사용된다.

Architecting on AWS 교육 과정

Tue, 01 Jul 2025 02:15:33 GMT

1일차

Module 1 : 아키텍칭 기본 사항
Task 1 : AWS 관리 콘솔 및 AWS CLI 살펴보기 및 사용
Module 2 : 계정 보안
Module 3 : 네트워킹 1
Module 4 : 컴퓨팅
Task 2 : Amazon VPC 인프라 구축
2일차
Module 5 : 스토리지
Module 6 : 데이터베이스 서비스
Task 3 : Amazon VPC 인프라에 데이터베이스 계층 생성
모듈 7 : 모니터링 및 크기 조정
모듈 8 : 자동화
모듈 9 : 컨테이너
실습 4 : Amazon VPC에서 고가용성 구성
3일차
모듈 10 : 네트워크 2
모듈 11 : 서버리스
실습 5 : 서버리스 아키텍처 구축
모듈 12 : 엣지 서비스
실습 6 : Amazon S3 오리진으로 Amazon CloudFront 배포 구성
모듈 13 : 백업 및 복구
실습 7 : 캡스톤 실습 - AWS 멀티 티어 아키텍처 구축 (시간이 되면)

가상화란?

Thu, 19 Jun 2025 07:16:20 GMT

단일 컴퓨터의 하드웨어 요솔르 일반적으로 가상 머신(VM)이라고 하는 다수의 가상 컴퓨터로 분할 할 수 있는 기술

배경지식

운영체제(OS) : 시스템 하드웨어 자원과 소프트웨어 자원을 운영 관리하는 프로그램 ex) Windows, Linux, MacOS, Android
특권 명령(Privileged instruction) : 시스템 요소들과 소통 할 수 있는 명령 - OS(Kernel)만 가능
- OS는 특권명령 떄문에 하나의 하드웨어 시스템당 하나밖에 돌아갈 수 없다.
- 일반 프로그램은 특권 명령이 필요 없기 때문에 많은 프로그램을 동시에 수행할 수 있다.
가상화가 나타나기 전까지는 하나의 하드웨어 시스템은 하나의 OS만 실행했다. 즉 일반적인 컴퓨터 처럼 OS가 하드웨어에 설치된 상태로만 운영 가능했었다.
가상화의 역사

1세대 : 완전 가상화(Full Emulated)
모든 시스템 요소가 에뮬레이터 안에서 돌아간다.
즉 CPU, 하드 디스크, 메인보드 등 모든 요소를 에뮬레이터로 구현하여 Guest OS(가상화 환경의 OS)와 연동 시킨다.
단점으로는 소프트웨어적으로 구현하다보니 하드웨어의 도움을 받지않아 매우 느리다.
2세대 : Paravirtualization
Guest OS는 하이퍼 바이저와 통신
하이퍼바이저(Hypervsior) : OS와 하드웨어 사이에 존재하는 일종의 가상화 매니저
일부 요소들의 경우에 여전히 에뮬레이터가 필요학 때문에 1세대보다는 빠르지만 여전히 느리다.
3세대 : Hardware Virtual Machine(HVM)
하드웨어에서 직접 가상화를 지원
직접 Guest-OS가 하드웨어 통신을 수행하기 때문에 빠른 속도를 가지고 있다.

가상화와 클라우드

가상화는 클라우드 환경에서 리소스를 작은 단위로 빠르게 구성할 수 있는 원동력이다.
즉, AWS에서 사용자마다 컴퓨터를 할당해 주는 것이 아닌 이미 구축된 가상화 가능한 서버의 한 부분을 할당해 주는 것을 의미한다.

클라우드 컴퓨팅의 용어 및 개념

Thu, 19 Jun 2025 04:57:00 GMT

고가용성/장애 내구성

고가용성
- 장애 상황을 해결하고 서비스를 지속할 수 있는 능력
- 장애 상황의 준비가 되어있는 아키텍쳐가 필요 ex) 자동차를 운전하다 타이어가 터졌을 때, 트렁크에 있는 스페어타이어로 최대한 빨리 교체하고 다시 운행을 시작하는 것
장애 내구성
- 장애 상황에도 서비스를 지속할 수 있는 능력
- 장애 상황에 영향을 받지 않는 아키텍쳐가 필요 ex) 항공기의 경우 엔진이 1~2개 이상이 생긴다고 해도 문제 없이 운항할 수 있다.
장애 내구성을 확보하게 된다면 일반적으로 한개 이상의 예비 인프라가 필요하게 되면서 비용이 증가한다.
고가용성을 확보하기 위해서는 두 개 이상의 인프라를 활용하기 위한 추가적인 아키텍처가 필요하기 때문에 복잡성이 증가한다.
따라서 고가용성/장애 내구성 중 어떤 것을 확보할지 요구사항에 맞춰서 고민해봐야한다.

확장성/탄력성

확장성(Scalable) : 쉽고 빠르게 규모를 늘릴 수 있는 능력
탄력성(Elastic) : 수요에 따라 컴퓨팅 파워/용량을 확장하거나 축소할 수 있는 능력, 불필요한 자원을 사용하지 않고 비용 최적화에 필수적인 능력이다.

긴말한 결합/느슨한 결합

긴밀한 결합 : 다른 주체에 대해서 단단하게 얽힌 상태, 주체끼리 높은 의존성을 가지고 있어 변경이 어렵다.
느슨한 결합 : 다른 요소에 대해 얽히지 않고 연결되어 있는 상태, 주체끼리 낮은 의존성을 가지고 있어 쉽게 변경할 수 있고 유연하다.

가상화

단일 컴퓨터의 하드웨어 요소를 일반적으로 가상 머신(VM)이라고 하는 다수의 가상 컴퓨터로 분할할 수 있도록 해주는 기술

참조

https://www.youtube.com/watch?v=5uhy3fvJfqk&list=PLfth0bK2MgIYuFahPhXTpTomkwVx5Fl-v&index=3

클라우드 컴퓨팅 모델

Thu, 19 Jun 2025 04:16:43 GMT

하나의 애플리케이션을 안정적으로 운영하기 위해서는 컴퓨팅, 스토리지, 네트워킹 등 다양한 IT 자원이 필요하다.
과거에는 이 모든 것을 직접 구축해야 했지만, 이제는 클라우드 컴퓨팅을 통해 빌려 쓰는 시대로 변화했다. 클라우드 컴퓨팅은 제공되는 서비스의 범위와 배포 방식에 따라 여러 모델로 나뉜다.
클라우드 컴퓨팅 모델
클라우드 컴퓨팅 모델은 크게 3가지로 구분된다.
Infrastructure as a Service(IaaS)
- 인프라만 제공한다.
- OS를 직접 설치하고 필요한 소프트웨어를 개발해서 사용
- 즉 가상의 컴퓨터를 하나 임대하는 것과 비슷하다. ex) Amazon EC2

Platform as a Service(PaaS)

인프라 + OS + 기타 프로그램 실행에 필요한 부분(런타임)
바로 코드만 올려서 돌릴 수 있도록 구성 ex) Google App Engine

Software as a Service(SaaS)

서비스 자체를 제공
다른 세팅 없이 서비스만 이용할 수 있다. ex) Gmail, DropBox, Slack, Google Docs

클라우드 컴퓨팅 배포 모델

배포 모델 또한 3개로 구분 할 수 있다.
공개형(퍼블릭 클라우드)
- 모든 부분이 클라우드에서 실행
- 낮은 비용 및 높은 확장성을 가진다.
  온-프레미스(프라이빗 클라우드)
- 모든 부분을 사설 데이터센터에서 실행
- 높은 수준의 커스터마이징 가능
- 초기 비용 및 유지보수 비용이 비싸다.
- 높은 보안성을 가진다.
- 온-프레미스와 프라이빗 클라우드는 혼용되서 사용된다. 온-프레미스가 기업 자체 서버를 의미하기도 하지만 이를 이용해서 클라우드 컴퓨팅 기술(자동화,가상화 등)을 이용할 수 있어 프라이빗 클라우드라고 불리기도 한다.
  혼합형(하이브리드)
- 폐쇄형과 공개형의 혼합
- 폐쇄형에서 공개형으로 전환하는 과도기에 사용된다.
- 혹은 폐쇄형의 백업으로 사용되기도 한다.

출처

https://www.youtube.com/watch?v=F1aCy268JbQ&list=PLfth0bK2MgIYuFahPhXTpTomkwVx5Fl-v&index=2

클라우드 컴퓨팅이란?

Thu, 19 Jun 2025 03:38:54 GMT

클라우드 컴퓨팅은 IT 리소스를 인터넷을 통해 온디맨드로 제공하고 사용한 만큼만 비용을 지불하는 것을 말한다. * 온디맨드 : 수요에 반응
쉽게 말하자면 다른 컴퓨팅 자원을 필요한 만큼 빌려서 사용한다.

Server-Client 구조
- 소수의 유저들만 존재하는 경우에는 단순히 유저들끼리 데이터를 주고받는데 크게 어려움이 존재하지 않는다.
- 하지만, 다수의 유저들끼리 통신을 수행하게 되는 경우 중간에 일부분의 데이터를 유실하거나 조작하게된다면 해당 어플리케이션은 동작하기 어렵기 때문에 이를 해결하는 구조로 Server-Client가 존재한다. 모든 통신을 서버를 거쳐서 수행하기 때문에 기존 유저들끼리 통신하는 것에 비해 훨씬 깔끔한 형태로 구성될 수 있다.
  데이터센터
  - 서버의 수가 늘어남에 따라 기업들은 이런 서버의 증설이 필요했고, 서버를 관리하기 위해 만든 공간이 데이터 센터이다.
  - 데이터 센터 : 어플리케이션의 서버를 호스팅하는 실제 시설
  - 운영에 필요한 인프라
    - 컴퓨팅 시스템 위한 하드웨어
    - 네트워킹 장비
    - 전원공급장치
    - 환경 제어장치
    - 운영 인력
    - 기타 인프라
  - 운영에 비용이 많이 소요된다.
  - 한번 구매하면 수요와 상관없이 계속 보유해야한다.
  - 장애 기기를 교체하는 시간도 오래 걸린다는 단점이 존재한다.
  - 이런 단점을 해결하기 위해 기업들은 온프레미스에서 클라우드로 넘어가기 시작했다.
클라우드 컴퓨팅의 장점
- 자본지출을 운영지출으로 대체할 수 있다.
  - 데이터 센터 구축 비용, 서버 구매 비용을 운영비로 대체할 수 있다.
  - 막대한 초기비용 대신 쓰는 만큼만 비용을 지불하기만 하면 된다.
- 규모의 경제로 얻게 되는 이점 존재
  - 한 개를 사는 것보다 100개를 사게 됨으로 단가가 낮아진다 => 규모의 경제
  - AWS(or GCP, NCP, Azure ..)의 규모의 경제로 인한 이득을 누릴 수 있다.
- 데이터 센터 운영 및 유지 관리에 비용 투자가 불필요하다.
  - 인프라 관리가 아닌 비즈니스에 자원 집중이 가능하다.
- 빠른 확장성
  - 몇 번의 클릭으로 전 세계에 서비스가 가능하다.

참조

https://www.youtube.com/watch?v=U6yEu_oZ4v8&list=PLfth0bK2MgIYuFahPhXTpTomkwVx5Fl-v&index=1

보안 네트워크 구축을 통한 서비스 연결 토폴로지 구축

Thu, 12 Jun 2025 10:25:42 GMT

프로젝트 목표

GN3와 네트워크 관리/보안 도구를 활용한 실시간 위협 탐지-대응 체계 구축
네트워크 기본 설정 -> 보안 구성 -> 자동화 기술 통합 3단계 실습 프로세스 설계

네트워크 구성도

장비 : Cisco 스위치/라우터, 우분투 서버, 칼리 리눅스,클라이언트 장비
연결 : NAT(외부망, 실제 인터넷 연결)
네트워크 토폴로지

기대 효과

네트워크 자동화 능력 숙달
- Netmiko/Python을 이용한 장비 관리
- 한 번에 여러 네트워크 장비의 설정을 변경함으로써 Ops 생산성 향상
실전형 보안 분석 기술력 강화
- '공격 시물레이션 -> 패킷 분석 -> ACL 적용' 의 종합적인 보안 대응 학습
라우팅 프로토콜에 대한 이해 향상

Chap 1 : 서버 설정, 내부망 구축, netmiko를 이용한 자동화 활용

내부 서버 영역 설정

주어진 네트워크 토폴로지에 먼저 ip 값을 할당한다.
이후 내부 서버(192.168.20.2)에 Telnet,SSH,http(s) 기능 활성화를 수행한다.
- 장비에서 원격으로 장비에 접속할 수 있는 '채널' 설정 : line vty 0 4
  - 장비 자체에 저장된 사용자 이름과 비밀번호를 저장 : login local
  - telnet,ssh 활성화 : transport input telnet ssh
- 내부 서버에서 서비스 접속을 위해 유저 이름, 비밀번호 생성 : username hyun privilege 15 secret proj2
- http(s) 기능 활성화
```
ip http server
ip http secure-server
ip http authenication local
```
별도의 웹서버(192.168.20.3)도 파이썬을 이용해 실행 : python3 -m http.server 80
내부망 외부망 연결
RIP 프로토콜을 사용하여 내부망과 외부망을 연결한다.
설정 방법
- 라우터 설정 창에서 router rip 를 통해 RIP 프로토콜 생성
- 자동 축약 사용 X : no auto-summary
- 버전 2 사용 : version 2
- 인접 라우터의 네트워크 주소를 통해 연결 : ex)network 192.168.20.0
  자동화 활용
netmiko는 네트워크 장치에 대한 CLI 연결을 단순화 하기 위한 멀티 벤더 라이브러리다.
네트워크 자동화의 경우에는 show 명령어 실행을 통해 장비의 상태를 확인하거나, 설정 파일 변경 작업을 주로 수행한다.
사용자가 네트워크 장치를 직접 제어하는 것보다 더 쉽게 제어할 수 있게 도와준다.
이번 프로젝트에서는 파이썬 코드를 이용해 간단하게 자동화 작업이 어떻게 동작하는지 배워보고자 한다.
- 먼저 해당 장비에 연결된 IP 상태를 확인
- 이후 loopback 인터페이스 활성화를 위한 설정 추가
- 마지막으로 loopback 인터페이스가 활성화 되어있는지 다시 확인
우분투에 netmiko 라이브러리를 설치 : sudo apt install python3-netmiko
파이썬 코드

Server = { "device_type" : "cisco_ios", "host" : "192.168.20.2", "username" : "hyun", "password" : "proj2", "global_delay_factor" : 2, }

net_connet = ConnectHandler(**Server)

#change setting commands= ["int loopback 0","ip add 1.1.1.1 255.255.255.0"]

with ConnectHandler(**Server) as net_connet: # show ip table print(net_connet.send_command("show ip int br")) print(net_connet.find_prompt()) output = net_connet.send_config_set(commands) print(output) # show ip table print(net_connet.send_command("show ip int br")) print()

net_connet.disconnect()

아래는 실행 결과 사진이다.![](https://velog.velcdn.com/images/archit-security/post/efe3bb72-7066-47b9-b97c-9aa09a7b93fa/image.png)
## Chap 2 : 포트 스캐닝
- 칼리 리눅스에서 nmap 도구를 이용해서 대상 서버의 서비스와 연린 포트를 확인해본다.
- nmap 으로 가장 일반적으로 사용되는 옵션은`-sS` 이다. 이는 TCP 3way handshake를 완료하지 않고 SYN 패킷을 보내고 SYN/ACK를 받으면 해당 포트가 열려있다고 판단하게 된다.
- 과거에는 IDS(Intrusion Detection System)에서 감지하지 못했지만 요즘은 대부분 탐지가능하다.
- 외부 사용자(우분투)에서 내부 서버 네트워크 주소로 포트 스캐닝을 시도해본다. ![](https://velog.velcdn.com/images/archit-security/post/505e2e93-cda1-400a-83b0-a2b9b2f36e54/image.png)
- 내부 네트워크(192.168.20.0/24) 상에서 3개의 장비가 감지되었고 각각 포트가 어떤게 열려있는지 볼 수 있다.
- 각 장비에 대해서 자세하게 확인하고싶다면 `-A` 옵션을 통해서 다시 포트스캐닝을 수행한다.![](https://velog.velcdn.com/images/archit-security/post/9162637a-b529-4e68-a96d-4d76efb85de6/image.png)
  - `A` 옵션을 통해서 열러있는 포트와 서비스 정보를 더 자세하게 확인할 수 있다. 
  - 또한 운영체제 정보 및 장비까지의 패킷 경로 등도 확인할수 있다. 
  - 192.168.20.2 주소의 장비의 경우 22,23,80,443 포트가 열려있으며,Cisco IOS를 사용하는 것을 보아 시스코 라우터 장비인 것을 파악할 수 있다. 또한 해당 장비까지의 거리가 5 hop이 떨어져 있는 것도 파악 가능하다.

## Chap 3 : 무차별 대입공격(Brute force Attack) 및 접속 테스트 
- 무차별 대입 공격은 특정 시스템이나 서비스에 접근하기 위해 사용자 이름, 비밀번호, 또는 암호화 키 등의 가능한 모든 조합을 체계적으로 시도하여 올바른 값을 찾아내는 기법이다.
- 이러한 무차별 대입 공격은 네트워크 보안 평가 및 침투 테스트 과정에서 시스템의 인증 메커니즘의 강도를 평가하고, 취약한 계정을 식별하는 주요 방법 중 하나로 활용된다. 이를 통해 기업이나 조직은 실제로 발생할 수 있는 잠재적인 보안 위험을 미리 파악하고 대응 방안을 마련할 수 있다.
- 무차별 대입 공격은 대상 시스템에 대한 특별한 내부 권한이나 복잡한 기술적 취약점 지식 없이, 네트워크를 통해 접근 가능한 서비스의 로그인 기능을 활용하는 직관적인 공격 기법이다. 이는 원리적으로 가장 이해하기 쉬운 공격 방식 중 하나로 볼 수 있으며, 필요한 권한 또한 일반 사용자 수준의 로그인 시도만 요구한다.
- 이전 단계를 통해 내부 서버에 있는 장비들을 대상으로 medusa 도구를 이용해서 무차별 대입 공격을 수행한다.
- medusa 설치 : `sudo apt isntall medusa`
- 우분투에 미리 다양한 단어를 생성해놓는다.
- 무차별 공격 수행 : `medusa -h 192.168.20.2 -U word.txt -P word.txt -M ssh -t 32 -O successful_logins.txt`
  - h : 타겟 주소
  - M : 서비스 종류
  - U : 아이디 파일
  - P : 비밀번호 파일
  - t : 스레드 종류
  - O : 성공 시 해당 파일에 저장![](https://velog.velcdn.com/images/archit-security/post/5f6f75bc-5cf3-448f-88fd-6cf0f1b3397f/image.png)

- 무차별 대입 공격으로 획득한 정보를 사용하여 장비에 접속을 시도해본다. 
![](https://velog.velcdn.com/images/archit-security/post/c8958be0-9274-4a68-abdb-8a0bc63c4b7a/image.png)

## Chap 4 : 패킷 캡처 및 분석
- 스위치에서 SPAN(Switched Port Analyzer) 설정을 구성한다. 
- SPAN은 특정 포트나 VLAN을 통과하는 네트워크 트래픽의 복사본을 다른 포트(모니터링 포트)로 보내는 기능이다.
- 이를 이용해 네트워크 트래픽을 분석하거나, 침입 탐지 시스템(IDS), 네트워크 성능 모니터링(NPM) 도구, 패킷 스니퍼 등 보안 및 모니터링 장비로 트래픽을 전송하는 데 사용된다.
- 프로젝트에서는 SW-1에서 내부로 들어오는 인터페이스 G0/1에 정보를 복사하여 보낸다.

monitor session 1 source interface Gi0/1 monitor session 1 destination interface Gi0/0

- 스위치 인터페이스 g0/0과 연결되어있는 우분투 도커 컨테이너를 통해 들어오는 10개의 패킷들을 캡처한다. : `tcpdump -i eth0 -c 10 -w output.pcap`
- 위에서 수행했던 무차별 대입공격을 다시 수행해보면 패킷들이 `output.pcap`에 저장되어있는 것을 확인할 수 있다.
- 캡처된 패킷을 `tcpdump -r output.pcap`을 통해 확인해보자.![](https://velog.velcdn.com/images/archit-security/post/509e85ab-bd2c-4dd8-a863-bbc8a293db5e/image.png)
- 외부 공격자(172.16.10.254)에서 내부 서버(192.168.20.2) 22번 포트를 향해 지속적으로 접속을 시도하는 것을 포착할 수 있다.

## Chap 5 : 내부 라우터 보안 강화
- 패킷 캡처를 한 뒤, 해당 패킷을 분석하고나서 지속적으로 내부 서버에 공격이 들어오는 것을 확인했다. 이제 우리는 이에 대한 대비책으로 내부 라우터에 대한 보안을 강화시켜야할 필요가 있다.
- 많이 사용되는 방법이 특정 네트워크 주소를 차단하는 방법이 존재한다. ACL(Access Control List)를 이용해서 외부(공격자)에서 서버로 들어오는 패킷을 차단하고 내 부에서 시작하는 패킷은 허용하도록 설정할 수 있다.
- 라우터 설정 창에서 접속 후 ACL를 생성한다.

ip access-list extended DENYList deny tcp 172.168.10.0 0.0.0.255 any eq 22 log DENY_ssh deny tcp 172.168.10.0 0.0.0.255 any eq telnet log DENY_telnet deny tcp 172.168.10.0 0.0.0.255 any eq www log DENY_http deny tcp 172.168.10.0 0.0.0.255 any eq 443 log DENY_https deny icmp 172.168.10.0 0.0.0.255 any log DENY_icmp permit icmp any any permit tcp any any

```

생성한 ACL 를 인터페이스 적용 시킨다. : ip access-group DENYList in
ACL 설정 전후 네트워크 동작 변화를 확인해보면 공격자가 내부 서버로 들어오는 것을 차단되었다는 것을 볼 수 있다.

이번 프로젝트를 통해서 우리는 장비의 설정 자동화과정을 수행해보았고, 또한 외부로부터 무차별 공격을 받았을 때, 패킷을 캡처하여 패킷 분석을 수행했으며 보안 대책으로 ACL을 적용해보는 과정을 수행해보았다.

OSPF(Open Shortest Path First) 프로토콜 - 4

Sun, 25 May 2025 17:18:31 GMT

Redistribution setting

외부 AS, 혹은 다른 특정 라우팅 프로토콜로 부터 수신된 라우팅 정보를 전달하기 위해 재분배 과정을 하게 된다.
예를 들어, RIP ,EIGRIP,BGP,static 등으로 부터 수신된 라우팅 정보를 인식시키기 위해서는 redistribute 구문을 반드시 사용해야 한다.
재분배된 라우팅 정보는 외부 정보로 인식한다.

OSPF LSA Types 확인

여러 타입의 LSA를 이용해 라우팅 정보를 송수신하여 LSDB를 완성한다. 이를 이용해 네트워크 토폴로지 내부에서 최적의 경로를 계산하고 라우팅 테이블에 저장한다.

Type 1 (Router LSA) : O

OSPF가 동작하는 모든 라우터가 생성하고, 동일 영역의 라우터에게 전달된다. sh ip ospf database router <라우터 ID>// 해당 라우터가 만든 LSA만 보여준다.

Type 2 (Network LSA) : O

다중 접속 네트워크의 DR(designated Router)이 만들며, DR이 동일영역의 라우터에게 전달한다.
DR이 없으면, Type 2도 없다. R4#sh ip ospf database network//DR이 생성

Type 3 (Summary-Network LSA) : O IA

자신이 속한 영역이 아닌 다른 영역의 정보를 요약해서 전달한다.
영역 간의 정보를 나타낸다고 해서 영역 간(Inter-Area) 정보라 표현한다. ABR이 생성, 전달한다. R1#sh ip ospf data summary

Type 4 (Summary-ASBR LSA) : O IA

OSPF 도메인 밖의 외부 정보를 OSPF로 유입시키는 라우터인 ASBR이 어떤 라우터 인지에 관한 정보를 요약해서 전달한다.
ASBR 라우터 정보와 메트릭 값을 현재 area의 ABR이 생성, 광고 한다. R1#sh ip ospf database asbr-summary

Type 5 (AS-External LSA) : O E1, O E2

AS 밖의 네트워크 정보(External LSA)/ASBR에 의해 성성, 전달한다.
Stub 계열의 영역을 제외한 모든 OSPF 영역으로 전달된다. 전체 OSPF 도메인 단위로 관리된다.
Metric-Type
- E2(기본): 외부 메트릭만 비교, 내부 코스트 무시.
- E1: 내부 + 외부 코스트 합산 → 대규모 망에서 좀 더 정밀.

R1# sh ip ospf database external

Type 7 (NSSA-External LSA) : O N1, O N2

AS 밖의 네트워크 정보(External LSA)/ASBR에 의해 성성, 전달한다.
LSA Type 5와 거의 비슷한 정보를 가진다.
stub 영역과 nssa는 AS 밖의 네트워크 정보를 표현하는 type 5의 유입이 금지되어 있다.
- stub 영역는 외부 네트워케이서 들어오는 LSA 정보를 차단해 외부에 대한 라우팅 정보를 받지 않으며, 대신 기본 경로(Deafult Route) 를 자동 생성해 AS 외부로 데이터를 전달할 때 경로로 사용한다.
NSSA 내부에서 생성되는 AS 외부 정보에 대한 전달은 허용된다.
NSSA 내부에서 생성되는 외부 정보와 일반적인 AS 외부 정보인 LSA type 5를 다르게 표현할 필요가 있기 때문에 마련된 틀별한 용도의 LSA가 type 7이다.

1) Stub : E1,E2가 사라지고 기본 경로(Default Route)로 대체된다. : Type 4,5가 차단된다. → 양쪽(R2,R7) ospf 설정에서 area <지역 번호> stub 수행 2) Totally Stub : E1,E2 뿐만 아니라 다른 Area에 속한 경로(IA)도 차단되어 기본경로로 대체 된다. 다시 말해서 같은 지역 외 모든 경로가 기본 경로로 대체된다. : Type 3,4,5가 차단된다. → 양쪽(R2,R7) ospf 설정에서 area <지역 번호> stub no-summary 수행

Stub , Totally Stub은 백본 area 와 ASBR에서는 설정할 수없다. 설정하기 위해서는 NSSA를 사용해야 한다.

3)Not-So-Stubby Area(NSSA) : E1, E2를 차단한다, 스터브 영역의 변형된 형태 이며, 스터브 영역으로부터 외부 네트워크 정보의 유입이 필요한 경우 사용된다. →양쪽(R1,R5) ospf 설정에서 area <지역 번호> nssa 수행 sh ip router ospf//ospf 도메인 내의 모든 라우터가 nssa 외부 네트워크 정보를 LSA 타입 5로 수신한다.

R1#do sh ip ospf //NSSA , LSA Type 7 → Type 5로 변경된 것을 확인 R5의 라우팅 테이블과 데이터베이스를 확인해보면 R1에서 NSSA 설정 이후, E1,E2로 되어 있던 외부 경로가 모두 사라졌기 때문에 이 문제를 해결하기 위해서는 R1(ABR)에 기본 경로(Default Route) 설정area <지역 번호> nssa default-information-originate 을 수행해줘야한다.

4) Totally Not-So-Stubby Area(NSSA) : E1,E2,IA를 모두 차단하고 기본경로로 대체 된다. : Type 3,4,5 차단

ABR에서만 설정해준다. area <지역 번호> nssa no-summary

타입들을 총 정리하면 아래 표와 같다.

AWS를 활용한 보안 클라우드 솔루션 설계 및 구축 - 2

Mon, 19 May 2025 07:52:10 GMT

개요

클라우드 Solution을 AWS로 선택후, 기반 인프라 구축을 수행하기 위해, 가용한 컴퓨터 자원을 외부에서 직접 접근 불가한 내부 네트워크에 배치한다.
모든 리소스는 Bastion Host(점프 서버) 를 제외하고 퍼블릭 인터넷과 차단되어야 하며, 내부 사용자,로드밸런서,테스트 클라이언트만 웹서버에 접근 할 수 있어야 한다.

요구사항

아마존 EC2를 아래 조건에 맞춰 생성해야한다.
반드시 새로 설계한 VPC 위에 클라우드 컴퓨팅 자원을 배치해야 한다.
내부 클라우드 웹 서비스 및 정책 구축 시 아래 해당 사항을 준수해야 한다.
- 이전 프로젝트에서 생성한 IAM 사용자를 통해 로그인을 수행
- EC2의 운영체제의 경우 test Client (Windows Server 2025 내 브라우저 or 외부 웹 브라우저), We b Server (Amazon Linux 2023) 사용
  - 해당 웹서버는 외부에서 직접적으로 접근할 수 없도록 보안 정책 및 배치 적용
  - 웹 서버에서 표출되는 내용은 WAS(wordpress or nextcloud) 솔루션을 사용
  - 각 자원에는 접근이 가능하도록 적절한 보안 그룹을 설정
  - 1개 이상의 로드 밸런서를 통해 내부 자원에 도메인으로 접근 가능하도록 구성
  - 데이터베이스 서버는 직접 설치(EC2) 혹은 RDS 서비스 중 택 1
IAM 로그인
- 관리자 권한에 준하는 사용자를 통해 AWS에 로그인하여 솔루션 설계를 수행한다.
VPC(Virutal Private Cloud)
- AWS의 데이터 센터에 있는 전용 기기에서 서버나 네트워크 장비가 가진 기능을 에뮬레이션비가 가진 기능을 에뮬레이션하는 소프트웨어를 작동시켜, 물리적인 기기를 사용하지 않고 가상의 네트워크를 구축한다.
- VPC 끼리는 독립적이므로 서로 영향을 미치지 않는다.

VPC 생성

VPC 생성 시 관련 리소스를 함께 만들 수도 있다.
VPC의 리소스를 생성하는 과정을 따라가기 위해서 개별적을 생성을 수행해보았다.
VPC 안에는 하나 이상의 서브넷이 반드시 존재해야한다.
- 서브넷은 외부 노출 여부에 따른 역할 구분과 서로 다른 가용영역(Availability Zone)에 배치해 물리적으로 분리된 데이터센터에 리소스를 분산(물리적 이중화) 하기 위해 VPC의 IP 주소 공간을 나누어 구성한다.
내결함성을 높이기 위해 2개의 가용영역을 만들고, 각 가용영역 내부에 public 서브넷과 private 서브넷을 통해 역할 분리를 수행한다. 생성된 VPC 리소스 모습이다.
인터넷 게이트 웨이(Internet gateway) 생성
vpc 안에 생성된 네트워크와 공용 인터넷 사이의 통신을 수행한다. 즉, 인터넷 게이트웨이가 없으면 퍼블릭 IP를 가지고 있어도 VPC 안의 리소스는 공용 인터넷과 직접 통신 불가능하다.
인터넷 게이트웨이를 생성한 뒤, VPC와 연결하는 작업을 진행한다. 연결된 VPC의 상태가 Attached로 변경되었다면 공용 인터넷과 통신이 가능하다.
NAT 게이트웨이 생성
VPC 내부에서 외부로 통신을 수행할 때, Private IP만 포함된 정보를 Public IP로 변환하는 시스템이다.
외부에서 Private Subnet으로 접근하기 위해서 반드시 수행해야한다. 아래 표를 보고 NAT 게이트웨이를 생성한다. NAT게이트웨이까지 연결된 리소스 그림이다.
라우팅 테이블 연결
서브넷, 인터넷 게이트웨이, NAT 게이트 웨이를 생성해 리소스가 공용 인터넷과 통신 할 수 있도록 설정했다.
하지만, 게이트웨이(IGW, NAT GW)로 향하는 기본 경로는 아직 설정하지 않았다.
라우팅 테이블은 0.0.0.0/0 → IGW 또는0.0.0.0/0→ NAT GW 같은 항목을 등록하고, 해당 테이블을 각 서브넷에 연결해야 외부 인터넷 및 다른 네트워크로의 통신이 완전히 활성화 한다.
위 테이블에 맞춰서 라우팅 테이블을 연결해준다. 라우팅 편집으로 인터넷 게이트웨이 또는 NAT 게이트웨이를 추가한다.
서브넷을 연결한다.
보안그룹 생성
VPC 안의 리소스를 보호하기 위해서 외부로부터의 접근 제한이 필요하다. 보안 그룹을 이용해 특정 포트와 특정 IP 주소를 제한하거나 허용할 수 있다.
웹 서버에 사용될 보안 그룹은 2가지로
- 모든 리소스에 접속하는 입구인 점프 서버
- 요청이나 처리를 분산하는 로드 밸런서보안 그룹 생성 후 VPC 내 리소스는 아래와 같다.
참고로 보안그룹과 같은 용도로 네트워크의 ACL(Access Control List)기능도 존재한다. 방화벽을 이용해 특정 포트와 특정 IP 주소를 차단할 수 있다. 보안그룹은 인스턴스 단위로 형성되고 ACL은 서브넷 단위로 생성할 수 있다는 점을 차이점으로 둘 수 있다.

EC2

점프 서버(jump server)

VPC를 만든 뒤 내부 리소스에 초기 설정,운영 작업을 하려면 외부(인터넷)에서 접속이 필요하다.
- 보안상 이 접속은 일부 관리자만 허용되어야 하며, 여러 인스턴스마다 Public IP를 노출하면 관리 누락 및 공격 면 증가 위험이 크다.
- 따라서 Pulbic Subnet 에 EC2 한대를 점프 서버를 준비하고, 해당 서버를 경유해야만 각 리소스에 접속 할 수 있는 방식을 많이 사용 한다.
  키 페어 생성
- Aws 상의 EC2와 같은 인스턴스에 SSH 접속을 하기 위해서 필요한 키 페어를 생성한다.
  EC2 인스턴스 생성
  점프서버를 EC2를 이용해서 생성한다. 기존 EC2 인스턴스 설정 항목 중에 기본 값에서 변경하는 항목만 아래 표에 작성했다.

EC2 인스턴스 SSH 접속 확인

putty, powershell, mobaxterm 등 쉘을 이용해 점프 서버에 접속을 수행할 수 있다. 접속하기 위해서 퍼블릭 IP를 이용해서 접속을 수행한다.

웹 서버 생성

브라우저나 어플리케이션으로부터 요청(request)을 받아 HTML 이나 JSON 등의 응답(response)를 반환하는 역할을 수행한다.
운영 관리자가 점프 서버를 통해 간헐적으로 접속해 설정을 변경하는 것과 달리, 웹 서버는 고개 또는 내부 사용자 등이 24시간 내내 접속을 시도한다.
보안 과 가용성을 동시에 확보하기 위해, 웹 서버는 퍼블릭 네트워크에 직접 노출하지 않고 프라이빗 서브넷에 배치한다. 대신 퍼블릭 서브넷의 로드 밸런서가 외부 요청을 받아 처리하도록 한다.

아래 사진은 웹 서버까지 구축된 리소스 설계도 모습이다.

웹 서버 접속

웹 서버는 외부로부터 접근을 차단해 두었기 때문에, 점프 서벌르 통해서 다단계접속을 수행해야 한다. EC2로의 접근에는 key fair를 이용하기 때문에, 연결을 수행할 key를 미리 복사(./ssh 내부)해 두어야 한다.
단순히 복사를 수행했을 때 해당 공개키의 접근 권한이 과도하게 제공될 가능성이 높기 때문에, 관리자에게만 읽기 권한을 부여하고 나머지는 어떤 권한도 제공하지 않도록 변경해야 한다.
그 후, 웹 서버의 프라이빗 주소를 이용해 ssh 접근을 시도한다.

로드 밸런서

로드 밸런서는 사용자 수가 증가하여 단일 웹 서버로는 요청을 처리하기 어려울 때, 여러 대의 웹 서버를 활용해 성능을 향상시키는 스케일 아웃 방식의 핵심 요소 중 하나이다.
로드 밸런서의 주요 역할은 요청 분산, SSL 처리, 부정 요청 대응이 있다.
- 요청 분산 : 인터넷으로부터 전송된 요청을 여러 웹 서버에 균등하게 분산
- SSL 처리 : HTTPS 통신 시 데이터는 암호화되어 전송되며, 복호화 과정은 많은 리소스를 소모한다. 로드 밸런서는 전용 시스템을 통해서 웹 서버 대신 SSL 처리를 빠르게 수행해 부하를 줄인다.
- 부정 요청 대응 : 웹 서버에서 올바른 요청이 아닌, 예상치 못한 작동을 일으키는 부정한 요청이 들어올 가능성이 존재하는데, 이를 감지하는 역할을 수행한다.
로드밸런서 생성
HTTP나 HTTPS를 이용한 접근을 분산하는 데 최적화 된 로드밸런서 ALB 를 이용한다.
로드 밸런서의 설정 항목에 대한 설명을 아래 표로 작성했다. 주의 할 점은 로드밸런서를 생성하려면 타겟 그룹(Target Group) 을 별도로 만들어야 하고, 그 안에 실제로 트래픽을 분산할 백엔드 인스턴스(또는 IP)를 등록해야 한다.

웹서버 패키지 다운로드

웹 서버는 프라이빗 서브넷에 존재하기 때문에 외부에서 직접적으로 접근이 불가능하다. 따라서, 점프 서버를 통해 접근을 수행해야 한다. 점프 서버에서 RSA 공개키를 이용해 ssh 접속을 시도한다.
웹 서버 구축을 위한 LAMP 다운로드 : sudo dnf install -y httpd php mariadb105-server
서비스 시작 : sudo systemctl enable --now httpd mariadb 이후 WAS 패키지를 wget으로 다운로드 후 unzip을 수행, 소유자를 apache로 변경해줘야 한다.

RDS

RDS 그룹 생성

EC2로 생성한 서버에 이 제품들을 설치해서 데이터베이스 서버로 제공하는 방법도 존재한다. 하지만, 데이터베이스 제품을 설치해야 하는 문제와, EC2의 OS를 관리해야 되는 문제가 발생할 수 있다.
AWS에서는 RDS를 제공하여 사용자는 단지 데이터 관리만 수행하면 된다.
- RDS는 데이터베이스 엔진, 파라미터 그룹, 옵션 그룹, 서브넷 그룹으로 구성된다.
  - 데이터베이스 엔진: 실제로 데이터가 저장되는 데이터베이스의 본체
  - 파라미터 그룹 : 사용하는 언어나 데이터베이스 튜닝을 설정
  - 옵션 그룹 : 데이터베이스 모니터링에 관한 설정 수행
  - 서브넷 그룹 : 데이터베이스 서버를 여러 개의 가용 영역에 분산 배치 할 때 이용하는 설정
파라미터 그룹을 생성
옵션 그룹 생성
서브넷 그룹 생성

데이터 베이스 생성

데이터 베이스는 아래 과정을 통해서 수행한다. 다른 옵션들은 요금이 부과된다 . 우리는 이런 환경이 있는지 확인하는 용도로 사용하기 때문에 프리티어 옵션을 사용한다. 만약 실사용 및 내 결함성을 높이기 위해서는 다중 DB 클러스터를 이용하면 된다. 관리자 사용자 생성 인스턴스 구성웹 서버 인스턴스와 연결
추가 옵션에서 생성한 파라미터 그룹, 옵션 그룹 선택
아래 그림은 RDS까지 추가된 리소스 설계 사진이다.

데이터 베이스 접속

생성된 데이터 베이스 접속은 엔드포인트 주소를 복사하여 아래 명령어로 입력해주면 된다.
mysql -u admin -p -h <엔드포인트 주소>

데이터 베이스 내에 간단하게 데이터베이스와 사용자 계정을 생성한다.

데이터베이스 생성 : CREATE DATABASE projectdb;
사용자 계정 생성 : CREATE USER 'projectuser'@'%' IDENTIFIED BY '1234';
사용자 계정 권한 부여 : GRANT ALL PRIVILEGES ON projectdb.* TO 'projectuser'@'%＇;
권한 적용 : FLUSH PRIVILEGES;

WAS를 실행할 때 부족한 php 패키지를 추가로 설치한다. php-zip ,php-gd,php-mysqli

원격 리소스 종료 및 제거

해당 리소스들을 계속 사용하면 많은 과금이 발생하기 때문에 프로젝트를 사용했다면 종료하거나 삭제해야 한다.

AWS를 활용한 보안 클라우드 솔루션 설계 및 구축 -1

Wed, 14 May 2025 13:42:09 GMT

개요

클라우드 기반 인프라 구축을 위해 AWS를 선택하고, 이에 따른 보안 클라우드 솔루션 설계를 수행하고자 한다.
특히 클라우드 환경에서 발생할 수 있는 비인가 사용자 접근 및 가상 서버 자원 탈취 등의 위협을 사전에 차단하기 위해, IAM(Identity and Access Management)을 중심으로 사용자 및 권한 관리를 철저히 수행한다.

주제

내부 회의 결과, AWS를 클라우드 인프라 플랫폼으로 선정하고 솔루션 설계를 수행
클라우드 리소스 관리 및 운영 과정에서 발생할 수 있는 계정 도용 및 과도한 권한 사용 문제를 예방
IAM을 통해서 root 사용자 사용을 지양하고, 역할 기반 권한 분리를 통해 최소 권한 원칙을 적용
외부에서 AWS Management Console 또는 CLI로 접근할 경우를 대비해 강력한 인증 체계 마련

요구사항

IAM 사용자를 생성한다.
IAM 그룹을 생성하고, 각 그룹에 적절한 권한 정책을 연결한다.
다음 조건을 만족하는 사용자 및 그룹을 생성한다.
- IAM 유저 그룹인 AdminUsers를 생성하시오. 또한 이 그룹에 속한 유저들(admin1, admin2)을 생성하시오.
  - IAM 유저 그룹인 NormalUsers를 생성하시오. 또한 이 그룹에 속한 유저들(nuser1, nuser2)을 생성하시오.
  - 상황 2의 작업은 IAM 유저 중 관리자에 준하는 권한(root 유저의 권한을 대신할 수 있도록 모든 권한을 가지는 유저)을 가진 한 명으로 작업할 수 있도록 해야 한다.

IAM(Identity and Access Management)

AWS의 리소스 접근을 안전하게 관리하는 시스템, 사용자 또는 그룹별 인증 및 접근 허가 기능을 구현한다.
- 인증 : 현재 사용하는 사용자가 누구인지에 대한 정보를 AWS에 전달하는 과정
- 접근 허가 : AWS 사용자가 어떤 기능을 사용할 수 있는 가를 관리하고 허가

IAM 사용자 생성

Root 유저는 모든 리소스에 접근 가능할 수 있는 권한을 가진 계정이므로, 통산적인 작업을 수행하기 위해 일반 사용자를 생성해서 최소 권한을 부여하여 리소스로의 접근에 대한 접근 강화를 수행한다.
사용자 생성 과정

IAM 그룹 생성

그룹이 존재하지 않기 때문에 새로운 그룹을 생성해준다.
리소스의 접근에 대한 권한 정책을 제공해야 한다.
- 관리자에 준하는 사용자의 경우에는 PowerUserAccess 와 IAMFullAccess를 지정해준다.
- 일반 사용자를 위한 그룹은 비교를 위해 권한을 어떤 권한도 제공하지 않았다.
그룹 생성 과정 그룹 생성 후 새로고침을 수행하고 생성된 사용자 그룹을 연결해준다. 위와 같은 방식으로 admin1, admin2, nuser1, nuser2 를 생성했다.

결론

본 프로젝트에서는 인프라 설계의 첫 단계로 AWS IAM을 활용해 관리자(AdminUser)와 일반사용자(NormalUser)의 권한을 명확히 분리하였다.
- Root 계정을 지앙햐고, 관리자 그룹에는 PowerUserAccess 와 IAMFullAccess를 부여해 운영 효율을 확보했다.
- 일반 사용자 그룹에는 최소 권한만 부여함으로써 권한 오남용과 잠재적 보안 사고를 방지했다.

OSPF(Open Shortest Path First) 프로토콜 - 3

Tue, 13 May 2025 15:59:19 GMT

이번에는 OSPF의 타입과 DR(Designate Router)/BDR(Backup DR) 선출 방식 등 ospf를 더 세부적으로 들어가보고자 한다. 이에 따라 먼저 네트워크 토폴로지를 아래와 같이 구축한다.

OSPF 확인명령어

sh ip ospf //OSPF 프로세스에 관한 정보를 보여준다.
sh ip ospf neighbor //근접 라우터의 상태를 확인(Full: 인접 관계가 완전 이뤄짐)
sh ip ospf interface //OSPF에 참여하는 인터페이스의 자세한 정보
sh ip ospf interface brief // 중요 정보만 간결
sh ip ospf database //LSDB 확인, LSA에 관한 요약 정보 제공
sh ip ospf database router-id //라우터 LSA의 상세 정보 확인

OSPF 네트워크 타입

Broadcast : 이더넷(Ethernet)처럼 여러 장치가 동시에 통신할 수 있는 환경, Multicast(224.0.0.5)로 Hello 전송을 가능하다. DR/BDR 선출이 이루어진다.
Point-to-Point : 두 장치간 전용 회선처럼 직결된 구조, 즉, 라우터 간 직접 연결된 일대일 구조이다.
Non-Broadcast : 멀티 액세스는 되지만 멀티캐스트로 전송이 불가한 환경, 인접 라우터는 수동으로 지정이 필요하다. DR/BDR 선출이 이루어진다.

다중 접속 네트웨크인 Broadcast 네트워크는 매체를 공유하는 여러 라우터 사이에서 LSA를 교환함으로써 네트워크가 복잡해진다. DR(Designate Router)/BDR(Backup DR)를 선출함으로써 사용되는 LSA를 줄여준다. DROthers는 오직 DR/BDR과만 인접(Adjacent) 관계를 맺는다. -> 즉, DR/BDR과만 LSA 를 교환한다.

인접 관계

OSPF neighbor 중, DROther들은 서로 인접 관계가 되지 못한다.
DR은 각 neighbor로부터 수신한 LSA 정보를 다른 neighbor로 전달한다.
DROthter : 목적지 주소 mulitcast(224.0.0.6)로 DR/BDR에게 LSA 등 업데이트 패킷을 보낸다.
DROther 라우터들은 목적진가 224.0.0.5 인 패킷만 수신한다.
DR은 목적지 주소 224.0.0.5 로 모든 라우터에게 정보를 보낸다.(Hello 패킷)
DR/BDR은 목적지가 224.0.0.5, 224.0.0.6 인 패킷을 모두 수신한다.
DR에 장애가 발생하면 BDR이 DR이 된다.

DR/BDR 선발

먼저 기본 상태에서 보게 된 경우 R2가 DR로 선점, R3가 BDR로 R1,R4가 DROther로 구성되었다. 이것은 매번 토폴로지를 구성할 때마다 라우터의 역할이 달라진다. 현재 상황은 아래와 같다.

우선권(Priority) 기본 값은 1이다. DR/BDR가 되길 원하는 라우터는 우선권을 높게한다. DROther는 우선권을 0으로 둔다.
R1의 우선권을 높여보았는데도 여전히 Area 0 에서 DROther 이다. →이는 OSPF 가 재설정 될때 까지 기존 역할을 유지하는 비선점(non-preemptive)이다.
재설정 방법은 clear ip ospf process를 입력한다.
R1 (DROther)이 바로 DR이 되는 것이 아닌 기존 BDR이 DR이 된다. 그리고 난 후 BDR을 선발하기 위해 선거가 치러지고 priority가 높은 R1이 BDR이 된다.
DR,BDR은 DROther과 Full 상태를 유지하고 DROther 들은 2-Way 상태를 유지한다.
- Full 상태 : 인접이 완전히 형성된 상태
- 2-way 상태 : 서로간의 존재만 인식하는 상태
DROther로 되게 하는 방법은 priority 0 으로 만들면 된다. : ip ospf priority 0
R3를 DROther로 만들어 본다.

Point - to - Point Type

2way 상태에서 DR/BDR을 선발하는데 많은 시간이 소모 된다.
Point-to-Point 네트워크에서는 DR/BDR을 선출하지 않는다. 인접 라우터가 자신을 포함하여서 2개만 존재하기 때문
실습 네트워크 랩에 있는 area 1 구역을 P2P 관계로 바꿔본다.
- ip ospf network point-to-point
DR/BDR 선출 결과가 존재하지 않는 것을 보아서 P2P인 것을 확인 할 수 있다.
또한 Priority가 0으로 강제 지정하여 DR 선출 대상에서 제외 되었다.

OSPF(Open Shortest Path First) 프로토콜 -2

Fri, 02 May 2025 06:48:32 GMT

OSPF Cost

OSPF 에서 metric은 비용(Cost) 이다.
metric을 확인하기 위해 간단한 네트워크 토폴로지를 생성했다.

cost 확인해보면 FastEthernet과 GigabitEthernet 의 비용이 동일하다.
비용은 Reference Bandwidth / interface's bandwidth 으로 계산된다. 기본 참조 대역폭 (reference bandwidth)은 100 Mbps이다. (10^8 = 100 000 000)
- 비용 계산에 따라
  - FastEhternet은 100 Mbps 의속도를 가지고 있어 Cost 는 1
  - GigabitEthernet은 1000 Mbps 의 속도 -> Cost 는 0.1 이되야하지만 *1로 강제 적용된다. * 이는 OSPF는 정수 단위로만 Cost를 계산하기 때문이고, 1보다 작은 값들은 모두 1로 변환되기 때문이다. FastEhternet과 GigabitEthernet위 비용이 동일한 것을 볼 수 있다.
기본 OSPF 설정에서는 참조 대역폭이 100Mbps 로 고정 되어있기 때문에, Fast Ethernet(100 Mbps)과 Gigabit Ethernet(1,000 Mbps)의 비용(Cost) 이 모두 1로 계산된다. 이로 인해 실제 속도 차이가 있음에도 불구하고 동일한 비용을 가진 경로 로 인식되어, 속도 차이를 전혀 반영하지 못하는 단점 이 발생한다.
즉 경로 선택시 비효율이 발생 할 수 있다. 이를 방지하기 위해 네트워크 환경에 맞춰 참조 대역폭 또는 인터페이스 대역폭을 조정해서 정확한 Cost 계산이 이루어지도록 설정하는 것이 권장된다.
OSPF cost를 변경하기 위한 방법은 3가지 존재한다.
1. interface's bandwidth를 직접 변경
- R1(config-if)#bandwidth < Bandwidth in kilobits >
1. Reference bandwidth 변경(주로 많이 사용됨)
- (config-router)#auto-cost reference-bandwidth < Mbits per second >
- 100000 값으로 변경 후 cost 확인
1. 인터페이스에서 OSPF cost를 수동으로 구성
- (config-if)#ip ospf cost < cost >

OSPF Packet

라우터가 성공적으로 OSPF 인접 라우터가 되도록하는 것이 OSPF 구성 및 문제 해결의 주요 작업이다.
이를 위해, OSPF은 패킷을 전송하는데, 총 5단계로 구성되어 있다.
1. Hello : 인접(Neighbors) 구성 및 유지
- Hello 메시지 전달은 multicast 방식(224.0.0.5)을 사용한다.
1. DataBase Description (DB D) : 데이터베이스 내용 요약 , 각 라우터의 LSDB가 동일한지 확인 하는 데 사용
2. Link-State Request (LS R) : 데이터베이스 상세내용 요청
3. Link-State Update (LS U) : 데이터베이스 업데이트
4. Link-State Acknowledgement (LSAck) : ACK 전송

OSPF(Open Shortest Path First) 프로토콜 -1

Tue, 22 Apr 2025 15:43:34 GMT

최단 경로 우선 프로토콜

동적 라우팅 프로토콜의 한 방식으로, 링크 상태 정보(up/down, bandwidth, ip address, mask 등 속성)를 바탕으로 네트워크의 최단 경로를 계산하는 라우팅 방식이다.
각 라우터는 자신의 링크 상태 정보를 LSA(Link-State Advertisement) 패킷에 담아 이웃(Neighbor) 라우터 에 전파하며, 수신된 LSA 정보는 LSDB(Link-State Database)에 저장된다.
각 라우터는 수신된 정보를 바탕으로 전체 네트워크 지도를 생성하고, 최적 경로를 계산한다.
IGP(Interior Gateway Protocol) 에 속하는 프로토콜로, 하나의 AS(Autonomous System) 내에서 라우팅을 수행한다.
- AS는 동일한 관리 제어하 있는 라우터의 집합

OSPF의 장점

표준 라우팅 프로토콜이기 때문에 대부분의 기업과 네트워크 환경에서 널리 사용된다.
OSPF는 네트워크에 변화가 생기면 해당 정보를 LSA 형태로 이웃 라우터에게 즉시 전파하고, 변경된 정보를 빠르게 반영하여 라우팅 테이블을 갱신한다. 이처럼 빠르게 라우팅 정보를 반영하는 능력을 컨버전스 타임(Convergence Time) 이 짧다고 표현하며, OSPF는 빠른 컨버전스를 지원한다.
링크 상태의 변화시에만 라우팅 정보를 전송하므로, RIP 처럼 주기적으로 전체 정보를 보내는 방식에 비해 네트워크의 리소스의 낭비를 방지할 수 있다.
Area(영역) 개념을 도입하여 네트워크를 여러 개의 논리적 영역으로 나눌 수 있기 때문에, 경로 계산 및 자원 사용을 효율화할 수 있다.
- 소규모 네트워크: 단일 영역(Area 0)으로도 충분히 운영 가능하다.
- 대규모 네트워크: 단일 영역으로 운영할 경우,
  - SPF 알고리즘 수행 시간이 증가하고,
  - LSDB 크기 증가로 인해 라우터 메모리 소모가 커질 수 있다.
  → 이런 문제를 방지하기 위해 여러 영역으로 나누어 관리하면 경로 계산이 더 효율적으로 이뤄지고, 자원 소모도 최소화할 수 있다.
RIP 프로토콜의 경우 홉 카운트가 15로 제한되어 있지만 ,OSPF 에서는 라우팅 거리의 제한이 없어 대규모 네트워크 구성에 적합하다.

OSPF 라우터의 종류

위치에 따른 구분

ABR(Area Border Router) : 2개 이상의 영역(Area)에 인터페이스가 있는 라우터, ABR은 연결된 각 영역에 대한 별도의 LSDB를 관리한다.
ASBR(AS Boundary Router) : AS 경계 라우터, OSPF 네트워크와 다른 라우팅 프로토콜이 설정된 네트워크를 연결하는 라우터
Backbon Routers : 백본 영역에 소속된 라우터, 모든 area 에 연결되어야 하는 특별한 영역
- Backbon 영역과 연결된 라우터는 4개 : R1,R2,R3,R4
- ABR 3개 : R2, R3,R4
- ASBR 1개 : R1

기본 OSPF 구성

OSPF 프로세스 ID는 로컬에서 중요하다. 프로세스 ID가 다른 라우터의 OSPF 인접 라우터가 될 수 있다.
OSPF network 명령을 사용하려면 영역을 지정해야 한다.
아래 실습은 같은 구역(area 0)에서 수행했다.
- 라우팅 ID : R13(1.1.1.1) R14(2.2.2.2) R15(3.3.3.3) R16(4.4.4.4)
- OSPF 설정 방법
  1. ospf 설정 창으로 이동 : (config)#router ospf
  2. router-id 번호 설정 : (config-router)#router-id
  3. 1 만약 ospf가 활성화 된 상태에서 router-id 를 변경하면 프로토콜을 재시작해야한다. : #clear ip ospf process
  4. 네트워크 할당 : (config-router)#network <네트워크 주소> <와일드 카드> area
- 시스코 장비의 경우에는 OSPF 설정 창에서 구성하는 방법 외 인터페이스에서 할당하는 방법이 존재한다.
각 라우터에 위와 같이 ospf 설정을 수행 후 하나의 라우터에서 라우팅 테이블 정보를 확인해본다.
- 여기서 네트워크 주소의 경로가 2가지가 나오는 이유는 다음에 정리해보겠다.
기본 경로 값은 토폴로지 내부에서 다른 경로로 배포해주기 위해서는 외부와 연결된 라우터의 ospf 설정 창에서 (config-router)#default-information originate 를 추가해준다.

OSPF 프로토콜 결과 확인 요약

#show ip protocols 명령을 통해 다음 정보를 확인할 수 있다:
- Router ID
- 등록된 네트워크 주소
- 이웃 라우터 정보(게이트웨이, AD, 마지막 업데이트 시간)
- 최대 경로 개수(ECMP 설정 값)
인터페이스에 OSPF를 활성화 하면 네트워크 주소가 아닌 인터페이스 경로가 나온다.
최대 가능 경로 개수를 변경하거나 distance 값을 변경해서 AD우선순위를 변경 할 수 있다.
- 최대 가능 경로 수 8개로 변경 : (config-router)#maximum-paths 8
- distance 값을 80으로 변경(우선순위가 OSPF를 EIGRP 경로보다 우선 선호) : (config-router)#distance 80

여기까지 OSPF 프로토콜의 기본 개념부터 설정 방법, 라우터 종류, 라우팅 테이블 확인까지 간단하게 정리해 보았다.

참조

OSI 7계층

Mon, 21 Apr 2025 15:53:23 GMT

OSI 7계층이란, 다른 시스템 간의 원활한 통신을 위해 ISO(국제표준화기구)에서 제안한 통신 규약이다.
통신의 접속에서부터 완료까지의 과정을 7단계로 구분하고 정의했다.

응용 계층(Application Layer)

응용 계층에서는 사용자와 직접 상호 작용하는 유일한 계층이다.
단, 응용 계층은 사용자가 사용하는 소프트웨어가 아닌 그 소프트웨어가 *네트워크 통신을 위해 사용하는 * 계층이다!!
웹 브라우저, 이메일 클라이언트 등 응용 프로그램들이 네트워크 서비스를 이용하기 위해서 반드시 사용하는 계층이다.
사용자로부터 입력 받은 데이터를 표현 계층하고, 반대로 수신한 데이터도 표현 계층을 통해 사용자에게 전달한다.
응용 계층 프로토콜에는
- HTTP(s) : 웹 페이지 요청 및 전송
- SMTP : 이메일 전송
- FTP : 파일 전송
- DNS : 도메인 이름을 IP 주소로 변환

표현 계층(Presetnation Layer)

표현 계층은 데이터의 형식을 조정하는 역할을 하며,응용 계층과 세션 계층 사이에서 데이터를 준비하거나 해석하는 기능을 수행한다.
표현 계층은 데이터의 변환, 암호화, 압축을 담당한다.
예를 들어, 장치가 암호화된 연결을 통해 통신하는 경우
- 송신 측에서는 데이터를 암호화하고,
- 수신 측에서는 암호화된 데이터를 복호화하여 응용 계층이 이해할 수 있는 형식으로 변환한다.
또한, 전송 전 데이터를 압축하여 전송량을 줄이고, 전송 속도와 효율을 향상 시킬 수 있다.

세션 계층(Session Layer)

세션 계층은 컴퓨터 간 통신 세션의 설정, 유지, 종료를 담당한다. 여기서, 세션(Seesion)은 두 프로세스 간 통신이 시작되어 종료될 때 까지의 시간을 의미한다.
세션 계층은 통신하는 두 시스템이 서로를 인식하고 동기화된 상태로 메시지를 주고받을 수 있도록 세션을 설정하며, 데이터 전송이 완료되면 불필요한 리소스를 낭비하지 않도록 세션을 종료시킨다.
또한, 통신 도중 오류한 경우 복구 지점을 설정하거나 재전송을 요청할 수 있다.
세션 계층 프로토콜에는 RPC(원격 함수 호출) 이 존재한다.
전송 계층
전송 계층은 종단간(End-to-End) 통신을 담당하며, 송신자와 수신자의 어플리케이션 간 안정적인 데이터 전송을 보장한다.
세션 계층으로부터 받은 데이터를 세그먼트(segment) 라는 단위로 나누어 네트워크 계층으로 전달하고, 수신 측 전송 계층에서는 이 세그먼트를 재조립하여 세션 계층으로 전달한다.
전송 계층은 또한 흐름 제어(Flow Control) ** 및 **오류 제어(Error Control) 기능을 통해 데이터가 과부하 없이, 정확하게 전송되도록 관리한다.
전송 계층은 전송된 데이터가 정상적으로 도착했는지 확인하고, 도착하지 않거나 오류가 발생시 재전송을 요청할 수 있다.
전송 계층의 대표적인 프로토콜에는
- TCP(Transmission Control Protocol) : 연결 기반, 신뢰성 보장
- UDP(User Datagram Protocol) : 비연결형, 실시간성

네트워크 계층(Network Layer)

네트워크 계층은 서로 다른 네트워크 구조 (ex) 이더넷과 와이파이, 또는 IPv4와 IPv6) 를 가진 장치 간에도 데이터 전송을 가능하게 역할을 수행한다. 동일 네트워크 내에서만 통신하는 경우에는 네트워크 계층이 명시적으로 동작하지않아도 되는 경우가 있다.
전송 계층에서 받은 데이터 세그먼트를 패킷(Packet) 이라 불리는 더 작은 단위로 세분화하여 네트워크에 전달한다.
또한, 목적지까지의 최적 경로를 계산하고 선택하는 라우팅(Routing) 기능을 수행하며, 여러 네트워크를 경유할 때 올바르게 데이터가 전달되도록 한다.
네트워크 계층 프로토콜에는
- IP(Internet Protocol) : 데이터 전송을 위한 주소 지정 및 패킨 전달을 담당
- ICMP(Internet Control Message Protocol) : 네트워크 오류 알림 및 진단 기능을 담당
- IPSec(IP Security) : 데이터를 암호화하고 인증하여 보안 통신을 가능하게 하는 프로토콜
  데이터 링크 계층(Data Link Layer)
데이터 링크 계층은 동일한 네트워크(로컬 네트워크) 에 있는 두 장치 간의 데이터 전송을 가능하게 하는 역할을 한다.
데이터 링크 계층은 네트워크에서 패킷을 가져와서 프레임이라 불리는 더 작은 조각으로 세분화 하여 물리 계층에 전달한다.
주소 지정(MAC 주소) 을 통해 장치간 정확한 데이터 전송을 보장하고, 흐름 제어 및 오류 제어 기능을 수행하여 데이터의 신뢰성과 효율성을 높인다.

물리 계층(Physical Layer)
- 물리 계층에는 케이블, 스위치 등 데이터 전송과 관련된 물리적 장비가 포함된다.
- 물리 계층에서는 1과 0의 문자열인 비트 스트림으로 변환되는 계층이다.

Reference

clouldflare, OSI모델이란?, https://www.cloudflare.com/ko-kr/learning/ddos/glossary/open-systems-interconnection-model-osi/
youtube, 이오의 OSI 7계층, https://www.youtube.com/watch?v=wuOzMvNEzAg
+chatgpt

h._.yun.log

Running Containers on Amazon Elastic Kubernetes Service(Amazon EKS) - 2

모듈 4 : Amazon EKS 클러스터에 애플리케이션 배포

애플리케이션 배포 방법

Amazon EKS 애플리케이션 배포 자동화를 위한 도구 선택

Amazon ECR 사용

컨테이너 이미지 저장

Helm을 사용하여 애플리케이션 배포

일반적인 Helm 작업

Helm 차트

Helm 차트 액세스

실습 2 : Helm 및 Amazon S3를 사용하여 애플리케이션 배포

Helm을 설치하고 Amazon S3 버킷을 Helm 리포지토리로 생성

제품 카탈로그 차트를 패키징하고 Amazon S3로 푸시

Amazon S3 리포지토리에서 Helm 차트를 검색 및 설치

애플리케이션 Helm 차트 편집 및 재배포

모듈 5 : Amazon EKS를 사용하여 대규모 애플리케이션 관리

Amazon EKS에서 수요에 맞게 크기 조정

kubernetes 자동 크기 조정

Horizontal Pod Autoscaler(HPA)

Vertical Pod Autoscaler(VPA)

VPA 구성요소

VPA 고려 사항

Cluster Autoscaler 및 Amazon EKS

Karpenter

Amazon EKS에 지속적 배포

release process (CI/CD)

지속적 전달과 지속적 배포 차이

CI/CD 도구

AWS 서비스를 사용한 지속적 배포

Amazon EKS 지속적 배포 파이프라인

GitOps 및 Amazon EKS

GitOps 원칙

Git

GitOps 예시 : Amazon EKS 및 Argo CD

실습 3 : 지속적 배포 및 GitOps

실습 환경

과제 1 : CodeCommit 리포지토리 생성

과제 2 : 실습용 배스천 호스트에 연결하고 AWS CodeCommit 및 Amazon ECR 연결을 위한 SSH 키 검토

과제 3 : 애플리케이션 코드를 검토한 후 AWS CodeCommit 리포지토리에 푸시

과제 4 : Jenkins 서버 구성

과제 5: Kubernetes 매니페스트 파일을 생성하고 AWS CodeCommit 리포지토리에 Push

과제 6: Argo CD 설치 및 AWS CodeCommit 연결 설정

과제 7: Argo CD 애플리케이션 배포 생성 및 탐색

과제 8: CI/CD 파이프라인을 통해 애플리케이션 업데이트

모듈 6 : Amazon EKS에서 네트워킹 관리

Amazon EKS의 통신

Pod 내부의 컨테이너 간 통신

Kubernetes 호스트 내 통신

Amazon EKS 호스트 간의 통신

Pod 수준 보안 개선

Pod 네트워크 통신 보안

Pod 용 보안 그룹

서비스를 사용한 로드 밸런싱

Kubernetes 서비스 유형

ClusterIP 서비스

Running Containers on Amazon Elastic Kubernetes Service(Amazon EKS) -1

모듈 1 Kubernetes 의 기본 개념

컨테이너의 이점

컨테이너 오케스트레이션

Kubernets 내부

PodSpec으로 Pod 정의

Pod : 통신

서비스(Service)

Kubernets 내부

제어 영역 및 데이터 영역

컨트롤러

제어 영역의 구성 요소

데이터 영역

제어 영역과 데이터 영역 간 통신

Pod 스케쥴링

필터링 : 리소스 요구사항

필터링 : 토폴로지 - Taint 및 Toleration

스코어링 : 토폴로지-선호도

필터링 : 볼륨 요구 사항

Kubectl 유틸리티(데모)

Kubectl 도구

kubernetes 객체

Namespace

ConfigMap 과 Secret