8. EKS 활용 사례 2 (배포)
Update : 2025.06.03
0. 사전 설정
Deployment에 대한 활용사례를 실습하기 위해, Sample Application을 사전 배포합니다.
cd ~/environment/
#Sample Application 을 Clone 하고, 실행합니다.
git clone https://github.com/aws-samples/eks-workshop-v2.git
kubectl apply -k ~/environment/eks-workshop-v2/manifests/base-application
Sample Application이 정상적으로 동작하는 지 확인합니다.
kubectl get namespaces -l app.kubernetes.io/created-by=eks-workshop
kubectl get deployment -l app.kubernetes.io/created-by=eks-workshop -A
아래와 같은 결과를 확인할 수 있습니다.
$ kubectl get namespaces -l app.kubernetes.io/created-by=eks-workshop
NAME STATUS AGE
assets Active 19s
carts Active 19s
catalog Active 19s
checkout Active 19s
orders Active 18s
other Active 18s
rabbitmq Active 18s
ui Active 18s1. 컨텍스트 설정
1.1 컨텍스트 파일 생성 (eks-deployer.md)
cat <<EOF > eks-deployer.md
사용자가 “application” 또는 “app”이라고 언급할 경우, 이는 ~/environment/eks-workshop-v2/manifests/base-application 경로에 위치한 애플리케이션을 의미합니다.
애플리케이션에 대한 모든 변경 사항은 업데이트를 적용하기 전에 YAML 파일에서 수정되어야 합니다.
업데이트를 적용할 때는 애플리케이션의 최상위 디렉터리에서 kustomize 플래그 -f 를 사용해야 합니다.
애플리케이션 토폴로지 다이어그램을 생성할 때는 Markdown(.md) 파일로 작성하며, 아래와 같은 MkDocs용 mermaid 코드 스니펫을 포함해야 합니다:
\`\`\`mermaid
graph LR
A[Start] --> B{Error?};
B -->|Yes| C[Hmm...];
C --> D[Debug];
D --> B;
B ---->|No| E[Yay!];
\`\`\`
EOF이 파일은 다음과 같은 행동 규칙을 Amazon Q에게 전달합니다:
“application”은
~/environment/eks-workshop-v2/manifests/base-application경로의 앱을 의미함업데이트 전 YAML 파일을 수정해야 함
kustomize 플래그
-f를 루트 디렉터리에 사용다이어그램은
.md파일로,Mermaid형식으로 작성
1.2. Amazon Q CLI 세션 시작
q chat --trust-all-tools1.3. 컨텍스트 프로파일 생성
/profile create eks-deployer1.4 컨텍스트 파일 추가
/context add eks-deployer.md1.5 현재 적용된 컨텍스트 확인
/context show실행 결과는 아래와 같습니다:
[eks-deployer] !> /context show
🌍 global:
.amazonq/rules/**/*.md (2 matches)
README.md
AmazonQ.md
👤 profile (eks-deployer):
eks-deployer.md (1 match)
3 matched files in use:
🌍 /home/ec2-user/.amazonq/rules/markdown.md (~90 tkns)
🌍 /home/ec2-user/.amazonq/rules/aws.md (~70 tkns)
👤 /home/ec2-user/eks-deployer.md (~250 tkns)
Total: ~410 tokens💡 출력 결과에 eks-deployer.md가 포함되어 있으면 컨텍스트 설정이 정상적으로 완료된 것입니다.
2. 애플리케이션 검토 (Review Application)
2.1 어플리케이션 리뷰 (Review Application)
프롬프트:
~/environment/eks-workshop-v2/manifests/base-application 어플리케이션을 설명해줘.설명:
지정된 경로에 있는 애플리케이션이 어떤 구성으로 되어 있는지, 어떤 마이크로서비스로 나뉘는지에 대해 요약 설명을 요청합니다.
실행 결과는 아래와 같습니다:
## EKS Workshop 애플리케이션 설명
~/environment/eks-workshop-v2/manifests/base-application 경로에 위치한 애플리케이션은 마이크로서비스 아키텍처를 기반으로 한 소매 스토어 샘플 애플리케이션입니다.
이 애플리케이션은 EKS(Elastic Kubernetes Service) 워크숍에서 다양한 Kubernetes 기능과 AWS 서비스 통합을 시연하기 위해 설계되었습니다.
### 애플리케이션 구성 요소
1. UI 서비스
• 사용자 인터페이스를 제공하는 Java/Spring Boot 기반 웹 서비스
• 모든 백엔드 서비스와 통신
• Prometheus 모니터링을 위한 메트릭 노출
• 메모리 제한: 1.5Gi, CPU 요청: 250m
2. Catalog 서비스
• 제품 정보와 재고를 관리
• 전용 데이터베이스에 데이터 저장
• 제품 검색 및 브라우징 기능 제공
• 메모리 제한: 512Mi, CPU 요청: 250m
3. Carts 서비스
• 고객 장바구니 관리
• DynamoDB 프로필을 사용하여 데이터 저장
• 장바구니 조작 기능(항목 추가/제거) 제공
• 메모리 제한: 1Gi, CPU 요청: 250m
4. Checkout 서비스
• 결제 프로세스 처리
• Carts, Orders 서비스 및 RabbitMQ와 통신
• 결제 정보 처리
• 메모리 제한: 512Mi, CPU 요청: 250m
5. Orders 서비스
• 고객 주문 관리
• 읽기/쓰기 분리된 전용 데이터베이스 사용
• 주문 상태 업데이트 처리
• 메모리 제한: 1Gi, CPU 요청: 250m
6. Assets 서비스
• UI를 위한 정적 자산 제공
• 이미지 및 기타 미디어 파일 서비스
7. RabbitMQ
• 서비스 간 비동기 통신을 위한 메시지 브로커
• 이벤트 기반 프로세스에 사용
8. 기타 지원 구성 요소
### 기술적 특징
• **컨테이너 이미지**: 모든 서비스는 public.ecr.aws에서 호스팅되는 이미지 사용
• **리소스 관리**: 각 서비스는 정의된 리소스 요청 및 제한 보유
• **보안 기능**:
• 비루트 사용자로 실행 (UID 1000)
• 읽기 전용 루트 파일시스템
• 불필요한 권한 제거
• 안전한 볼륨 마운트
• **모니터링**: Prometheus 메트릭 수집을 위한 어노테이션
• **상태 확인**: 안정성을 위한 liveness 및 readiness 프로브
• **구성 관리**: 서비스 구성을 위한 ConfigMap
• **비밀 관리**: 민감한 데이터는 Kubernetes 시크릿에 저장
### 배포 구조
이 애플리케이션은 Kustomize를 사용하여 배포를 관리합니다. 메인 kustomization.yaml 파일은 다음과 같은 모든 구성 요소를 포함합니다:
yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- rabbitmq
- catalog
- carts
- checkout
- assets
- orders
- ui
- other
각 구성 요소 디렉토리에는 다음과 같은 Kubernetes 매니페스트가 포함되어 있습니다:
• 배포(Deployment) 구성
• 서비스(Service) 정의
• 구성맵(ConfigMap)
• 네임스페이스(Namespace) 선언
• 서비스 계정(ServiceAccount)
### 애플리케이션 흐름
1. 사용자는 UI 서비스와 상호 작용
2. UI는 백엔드 서비스(Catalog, Carts 등)와 통신
3. 결제 시:
• Checkout 서비스는 Carts 서비스로 장바구니 유효성 검사
• Orders 서비스를 통해 주문 생성
• 비동기 처리를 위해 RabbitMQ를 통해 메시지 전송
4. 각 서비스는 데이터 지속성을 위해 자체 데이터베이스와 상호 작용
### 배포 및 업데이트
워크숍 가이드라인에 따르면:
• 모든 애플리케이션 변경은 업데이트를 적용하기 전에 YAML 파일에서 수정해야 함
• 업데이트는 애플리케이션의 최상위 디렉토리에서 kustomize 플래그 -f를 사용하여 적용해야 함
• 이 애플리케이션은 다양한 Kubernetes 기능과 AWS 서비스 통합을 시연하기 위해 설계됨
이 애플리케이션은 클라우드 네이티브 마이크로서비스 아키텍처의 우수한 예시이며, Kubernetes 개념과 AWS 서비스 통합을 학습하기 위한 실용적인 환경을 제공합니다.2.2 애플리케이션 배포 (Deploy Application)
프롬프트:
~/environment/eks-workshop-v2/manifests/base-application 에 있는 Application을 배포해줘.
kustomize option in kubectl 의 kustomize option을 사용해줘.설명:
kubectl apply -k 명령을 사용하여 base-application을 클러스터에 배포합니다.
Q CLI는 kustomize를 이용한 배포를 자동 실행합니다.
실행 결과는 아래와 같습니다:
애플리케이션이 성공적으로 배포되었습니다! kubectl의 kustomize 옵션(-k)을 사용하여 ~/environment/eks-workshop-v2/manifests/base-application 경로에 있는 애플리케이
션을 배포했습니다.
### 배포 결과 요약
1. 배포 명령 실행:
bash
cd ~/environment/eks-workshop-v2/manifests/base-application && kubectl apply -k .
2. 배포된 구성 요소:
• 8개의 네임스페이스 (assets, carts, catalog, checkout, orders, other, rabbitmq, ui)
• 각 서비스별 ServiceAccount
• ConfigMap, Secret 등의 구성 리소스
• 각 마이크로서비스의 Deployment 및 Service
• StatefulSet (catalog-mysql, rabbitmq)
3. 현재 실행 중인 Pod 상태:
• **UI**: ui-8564fc5cfb-gfsdr (Running)
• **Carts**:
• carts-7c95cd549d-4mjjb (Running)
• carts-dynamodb-68bd8f6f6d-hr5jc (Running)
• **Catalog**:
• catalog-6d48d97dff-l6z96 (Running)
• catalog-mysql-0 (Running)
• **Checkout**:
• checkout-7ff8988c8c-hrqtr (Running)
• checkout-redis-7fb554999b-mpr29 (Running)
• **Orders**:
• orders-79bc47b54d-vm9jr (Running)
• orders-mysql-65bd8b5787-s6q65 (Running)
• **RabbitMQ**: rabbitmq-0 (Running)
4. UI 서비스 정보:
• 타입: ClusterIP
• IP: 172.20.211.207
• 포트: 80 (HTTP)
모든 구성 요소가 정상적으로 배포되었으며, 각 마이크로서비스가 해당 네임스페이스에서 실행 중입니다. 애플리케이션의 프론트엔드(UI)는 ClusterIP 서비스로 노출되어 있
으며, 클러스터 내부에서 접근할 수 있습니다.2.3 애플리케이션 준비 상태 확인 (Application Readiness)
프롬프트:
애플리케이션에 속한 모든 파드가 준비(Ready) 상태가 될 때까지 기다립니다.설명:
배포된 파드들이 모두 Ready 상태가 될 때까지 기다립니다. Q CLI가 상태를 추적해 알려줍니다.
실행 결과는 아래와 같습니다:
모든 애플리케이션 파드가 Ready 상태가 되었습니다! 각 네임스페이스의 파드 상태를 확인한 결과는 다음과 같습니다:
### 애플리케이션 파드 상태 요약
| 네임스페이스 | 파드 이름 | 상태 | Ready |
|------------|---------|------|-------|
| assets | assets-69974886bf-b69d4 | Running | 1/1 ✅ |
| carts | carts-7c95cd549d-4mjjb | Running | 1/1 ✅ |
| carts | carts-dynamodb-68bd8f6f6d-hr5jc | Running | 1/1 ✅ |
| catalog | catalog-6d48d97dff-l6z96 | Running | 1/1 ✅ |
| catalog | catalog-mysql-0 | Running | 1/1 ✅ |
| checkout | checkout-7ff8988c8c-hrqtr | Running | 1/1 ✅ |
| checkout | checkout-redis-7fb554999b-mpr29 | Running | 1/1 ✅ |
| orders | orders-79bc47b54d-vm9jr | Running | 1/1 ✅ |
| orders | orders-mysql-65bd8b5787-s6q65 | Running | 1/1 ✅ |
| rabbitmq | rabbitmq-0 | Running | 1/1 ✅ |
| ui | ui-8564fc5cfb-gfsdr | Running | 1/1 ✅ |
모든 컨테이너가 Ready 상태로 확인되었으며, 애플리케이션의 모든 구성 요소가 정상적으로 실행 중입니다. 일부 파드(catalog, orders)에서 이전에 재시작이 있었지만, 현
재는 모두 안정적으로 실행되고 있습니다.
애플리케이션이 완전히 배포되어 사용할 준비가 되었습니다.
2.4 애플리케이션 업데이트 (Update the Application)
프롬프트:
checkout 디플로이먼트를 3개의 레플리카로 업데이트하세요.
적용하기 전에 반드시 YAML 파일을 먼저 수정해야 합니다.설명:
checkout 디플로이먼트의 복제 수(replicas)를 3으로 변경합니다.
YAML 파일 수정 → 적용(kustomize) 순으로 진행됩니다.
실행 결과는 아래와 같습니다:
성공적으로 checkout 디플로이먼트를 3개의 레플리카로 업데이트했습니다!
### 작업 과정 요약:
1. YAML 파일 수정:
• sed 명령어를 사용하여 ~/environment/eks-workshop-v2/manifests/base-application/checkout/deployment.yaml 파일의 replicas 값을 1에서 3으로 변경했습니다.
bash
sed -i 's/replicas: 1/replicas: 3/' ~/environment/eks-workshop-v2/manifests/base-application/checkout/deployment.yaml
2. 변경 사항 확인:
• 파일을 읽어서 replicas 값이 3으로 변경되었는지 확인했습니다.
3. 변경 사항 적용:
• kustomize 옵션을 사용하여 변경 사항을 적용했습니다.
bash
cd ~/environment/eks-workshop-v2/manifests/base-application && kubectl apply -k .
4. 결과 확인:
• checkout 디플로이먼트가 3/3 Ready 상태로 업데이트되었습니다.
• 3개의 checkout 파드가 모두 Running 상태입니다:
• checkout-7ff8988c8c-9jrzd
• checkout-7ff8988c8c-hrqtr (기존 파드)
• checkout-7ff8988c8c-mhxg2
이제 checkout 서비스는 3개의 레플리카로 실행되고 있어 가용성과 확장성이 향상되었습니다. 모든 파드가 정상적으로 실행 중이며, 디플로이먼트가 성공적으로 업데이트되
었습니다.3. 토폴로지 시각화 (Topology Diagram)
프롬프트:
클러스터에서 실행 중인 애플리케이션의 토폴로지 다이어그램을 생성해 주세요.설명:
현재 클러스터에 실행 중인 애플리케이션의 서비스 간 구조를 mermaid 기반 다이어그램으로 생성합니다.
MkDocs 또는 GitBook에서 시각화 가능한 Markdown 코드로 출력됩니다.
클러스터에서 실행 중인 애플리케이션의 토폴로지 다이어그램을 생성하겠습니다.
🛠️ Using tool: fs_write (trusted)
⋮
● Path: ../../tmp/app-topology.md
- 1 : ## EKS Workshop 애플리케이션 토폴로지
+ 1: ## EKS Workshop 애플리케이션 토폴로지 다이어그램
2, 2:
- 3 : 이 문서는 EKS Workshop에서 사용되는 마이크로서비스 기반 소매 애플리케이션의 구조를 설명합니다.
+ 3: 이 다이어그램은 현재 EKS 클러스터에서 실행 중인 마이크로서비스 기반 소매 애플리케이션의 구조를 보여줍니다.
4, 4:
5, 5: ```mermaid
6, 6: graph TD
7, 7: UI[UI 서비스] --> Catalog[Catalog 서비스]
8, 8: UI --> Carts[Carts 서비스]
9, 9: UI --> Checkout[Checkout 서비스]
10, 10: UI --> Orders[Orders 서비스]
11, 11:
12, 12: Checkout --> Orders
13, 13: Checkout --> Carts
14, 14: Checkout --> RabbitMQ[RabbitMQ]
15, 15:
- 16 : Carts --> CartsDB[(Carts DB)]
- 17 : Catalog --> CatalogDB[(Catalog DB)]
- 18 : Orders --> OrdersDB[(Orders DB)]
+ 16: Carts --> CartsDB[(Carts DynamoDB)]
+ 17: Catalog --> CatalogDB[(Catalog MySQL)]
+ 18: Orders --> OrdersDB[(Orders MySQL)]
+ 19: Checkout --> CheckoutRedis[(Checkout Redis)]
19, 20:
20, 21: Assets[Assets 서비스] --> UI
21, 22:
22, 23: subgraph 프론트엔드
23, 24: UI
24, 25: Assets
25, 26: end
26, 27:
27, 28: subgraph 백엔드 서비스
28, 29: Catalog
29, 30: Carts
- 30 : Checkout
+ 31: Checkout["Checkout (3 replicas)"]
31, 32: Orders
32, 33: end
33, 34:
34, 35: subgraph 데이터 저장소
35, 36: CartsDB
36, 37: CatalogDB
37, 38: OrdersDB
+ 39: CheckoutRedis
38, 40: RabbitMQ
39, 41: end
+ 42:
+ 43: classDef frontend fill:#f9f,stroke:#333,stroke-width:2px;
+ 44: classDef backend fill:#bbf,stroke:#333,stroke-width:2px;
+ 45: classDef database fill:#bfb,stroke:#333,stroke-width:2px;
+ 46:
+ 47: class UI,Assets frontend;
+ 48: class Catalog,Carts,Checkout,Orders backend;
+ 49: class CartsDB,CatalogDB,OrdersDB,CheckoutRedis,RabbitMQ database;
+ 50: ```
Replacing: ../../tmp/app-topology.md
⋮
● Completed in 0.0s
🛠️ Using tool: execute_bash (trusted)
⋮
● I will run the following shell command:
glow /tmp/app-topology.md
## EKS Workshop 애플리케이션 토폴로지 다이어그램
이 다이어그램은 현재 EKS 클러스터에서 실행 중인 마이크로서비스 기반 소매
애플리케이션의 구조를 보여줍니다.
graph TD
UI[UI 서비스] --> Catalog[Catalog 서비스]
UI --> Carts[Carts 서비스]
UI --> Checkout[Checkout 서비스]
UI --> Orders[Orders 서비스]
Checkout --> Orders
Checkout --> Carts
Checkout --> RabbitMQ[RabbitMQ]
Carts --> CartsDB[(Carts DynamoDB)]
Catalog --> CatalogDB[(Catalog MySQL)]
Orders --> OrdersDB[(Orders MySQL)]
Checkout --> CheckoutRedis[(Checkout Redis)]
Assets[Assets 서비스] --> UI
subgraph 프론트엔드
UI
Assets
end
subgraph 백엔드 서비스
Catalog
Carts
Checkout["Checkout (3 replicas)"]
Orders
end
subgraph 데이터 저장소
CartsDB
CatalogDB
OrdersDB
CheckoutRedis
RabbitMQ
end
classDef frontend fill:#f9f,stroke:#333,stroke-width:2px;
classDef backend fill:#bbf,stroke:#333,stroke-width:2px;
classDef database fill:#bfb,stroke:#333,stroke-width:2px;
class UI,Assets frontend;
class Catalog,Carts,Checkout,Orders backend;
class CartsDB,CatalogDB,OrdersDB,CheckoutRedis,RabbitMQ database;
⋮
● Completed in 0.16s
## EKS Workshop 애플리케이션 토폴로지 다이어그램
이 다이어그램은 현재 EKS 클러스터에서 실행 중인 마이크로서비스 기반 소매 애플리케이션의 구조를 보여줍니다.
애플리케이션은 다음과 같은 주요 구성 요소로 이루어져 있습니다:
### 프론트엔드 서비스
• **UI 서비스**: 사용자 인터페이스를 제공하는 메인 프론트엔드 서비스
• **Assets 서비스**: UI에 필요한 정적 자산을 제공하는 서비스
### 백엔드 서비스
• **Catalog 서비스**: 제품 카탈로그 정보를 관리
• **Carts 서비스**: 사용자 장바구니를 관리
• **Checkout 서비스**: 결제 프로세스를 처리 (현재 3개의 레플리카로 실행 중)
• **Orders 서비스**: 주문 처리 및 관리
### 데이터 저장소
• **Carts DynamoDB**: 장바구니 데이터 저장
• **Catalog MySQL**: 제품 카탈로그 데이터 저장
• **Orders MySQL**: 주문 데이터 저장
• **Checkout Redis**: 체크아웃 프로세스를 위한 캐싱 및 임시 데이터 저장
• **RabbitMQ**: 서비스 간 비동기 메시지 전달을 위한 메시지 브로커
### 서비스 간 통신 흐름
1. 사용자는 UI 서비스와 상호작용
2. UI 서비스는 필요에 따라 Catalog, Carts, Checkout, Orders 서비스와 통신
3. Checkout 서비스는 주문 처리 과정에서 Orders, Carts 서비스 및 RabbitMQ와 통신
4. 각 서비스는 자체 데이터베이스와 통신하여 데이터를 저장하고 검색
이 애플리케이션은 마이크로서비스 아키텍처의 좋은 예시로, 각 서비스가 독립적으로 배포되고 확장될 수 있습니다. 특히 Checkout 서비스는 3개의 레플리카로 확장되어 높
은 가용성과 부하 분산을 제공합니다./tmp/app-topology.md 파일을 https://mermaid.live/ 에 코드를 붙여 넣습니다.
아래와 같은 토폴로지를 확인할 수 있습니다.
Last updated