쿼츠 블로그를 위해 대공사

2026-04-08 13:07:41 +09:00
parent 123642831e
commit 1319881195
606 changed files with 50625 additions and 2 deletions
@@ -0,0 +1,12 @@
+
+As-Is
+![[Pasted image 20260227093328.png]]https://wk.wecmms.com
+https://innox.wecmms.com
+
+### EC2기반의 아키텍처에는 다음의 한계들을 가짐
+![[EC2기반 아키텍처의 한계점]]
+
+
+### 한계를 극복하기 위해 나아가야 할 방향
+[[서버리스(Serverless)]] 구성
+: AWS가 제공해주는 [[파게이트(Fargate)]]로 구성한다.
@@ -0,0 +1,28 @@
+---
+id: "AWS ECS 구성하기 20260305"
+created: "2026-03-05 13:29"
+tags:
+---
+### ECS
+![[ECS와 EKS#ECS(Elastic Container Service)]]
+
+
+[[태스크(Task)]] 구성
+1) 고객이 완벽한 물리적인 격리를 원할 경우: 3. ECS 클러스터 만들기부터 진행
+2) 고객이 별도의 물리적인 격리를 원하지 않을 경우: 4. ECS 서비스 만들기부터 진행
+
+## 🔢 목록
+
+#### 1. [[ECS와 EKS]]
+
+#### 2. [[ECS의 구성]]
+
+#### 3. [[ECS 클러스터 만들기]]
+
+#### 4. [[ECS 서비스 만들기]]
+
+만약 [[ECR(Elastic Container Registry)]]에 등록된 컨테이너 이미지가 없다면?
+이미지부터 만들어야 합니다. (도커에 대한 이해가 필요)
+
+#### 5. [[테넌시(Tenancy)]]
+ - [[테넌시 구성 가이드]]
@@ -0,0 +1 @@
+VPC
@@ -0,0 +1 @@
+## 1. 
@@ -0,0 +1,64 @@
+---
+id: 서비스 만들기 20260305
+created: 2026-03-05 08:38
+tags:
+---
+> [!abstract]
+> [[클러스터(Cluster)]] 내부에서 동작하는 서비스를 만듭니다.
+> ECS 서비스는 **"데이터 플레인 위에서 태스크가 잘 돌아가게 감시하는 역할"**을 합니다.
+
+> [!check]
+> - **개수 유지:** "태스크 3개를 항상 띄워줘"라고 설정하면, 하나가 죽었을 때 데이터 플레인(서버) 위에 새로운 태스크를 다시 올립니다.
+>     
+> - **로드 밸런싱:** 들어오는 트래픽을 여러 태스크에 골고루 나눠줍니다.
+>     
+> - **배포 관리:** 새로운 버전의 태스크 정의가 나오면, 기존 태스크를 하나씩 끄고 새 버전으로 교체합니다.
+> 
+
+## 🔢 목록
+
+#### 1. 서비스의 [[태스크(Task)]] 정의
+![[Pasted image 20260305084812.png]]
+만약 정의한 [[태스크(Task)]]가 없다면 태스크부터 정의해야 합니다.
+[[ECS 태스크 만들기]]
+태스크를 기반으로 ECS의 서비스가 가동되어집니다.
+
+> [!question]
+> [[태스크 정의 패밀리]]가 뭐지?
+
+태스크 정의 패밀리를 선택하면 그 패밀리의 최신 버전이 자동으로 태스크 정의 개정에 등록됩니다.
+서비스 이름을 마저 지정합니다.
+
+#### 2. 컴퓨팅 구성 선택
+![[Pasted image 20260305102304.png]]
+클러스터명은 변경할 수 없어서 비활성화 되어있는 것
+[[시작 유형(Launch Type)과 용량 공급자 전략(Capacity Provider Strategy)의 차이]]
+참고해서 설정하면 됩니다.
+
+
+#### 3. 문제 해결 구성 설정
+> [!info] 개발(Dev)이나 스테이징(Staging) 환경에서는 무조건 켜두시고, 운영(Prod) 환경에서는 보안 승인을 받은 사람만 쓸 수 있게 [[IAM(Identity and Access Management)]]으로 꽉 잠가두고 켜두시는 것을 추천
+
+![[Pasted image 20260305104853.png]]
+
+
+#### 4. 배포 구성은 그대로 놔둡니다.
+정확한 사용법을 확인하지 못했음.
+
+
+#### 5. 네트워킹
+[[VPC(Virtual Private Cloud)]]와 [[서브넷(Subnet)]], [[보안 그룹(Security Group)]]을 설정합니다.
+필요한대로, 원하는대로 설정해줍니다.
+
+#### 6. 로드밸런싱 선택
+태스크로의 로드밸런싱이 필요한 경우 체크하고 사용합니다.
+여기서 추가해주지 않으면 중간에 추가할 수 없어서 태스크를 새로 만들어야 합니다.
+![[Pasted image 20260305110136.png]]
+**자동 등록 (Target Group):** 새로운 태스크가 실행되면 ECS 서비스가 알아서 로드 밸런서의 **'대상 그룹(Target Group)'**에 해당 태스크의 IP를 등록해줍니다.**
+로드 밸런싱 사용을 체크하지 않을 경우 자동 등록이 되지 않습니다.
+
+
+서비스를 만들고 나면 서비스 태스크가 정상적으로 실행되기를 기다려야합니다.
+![[Pasted image 20260305110258.png]]
+만약 태스크 실행이 실패하였다면 태스크정보에서 로그 탭을 확인해야 합니다.
+![[Pasted image 20260305111038.png]]
@@ -0,0 +1,24 @@
+---
+id: 클러스터 만들기 20260305
+created: 2026-03-05 08:30
+tags:
+  - cluster
+  - ecs
+---
+> [[!]]
+## 🔢 목록
+
+#### 1. [[클러스터(Cluster)]] 이름을 정한다.
+![[Pasted image 20260305083155.png]]
+#### 2. 인프라를 선택해준다.
+![[Pasted image 20260305083442.png]]
+> [!note]
+> 진정한 [[서버리스(Serverless)]] 환경구축을 위해서는 [[파게이트(Fargate)]]전용으로 해준다.
+> 
+
+#### 3. 나머지는 일단 그대로 둔다.
+모니터링, 암호화, 태그는 우선 그대로 둡니다. (추후 필요할 경우 확인 후 설정 필요)
+
+
+클러스터를 생성하고 서비스를 생성합니다.
+[[ECS 서비스 만들기]]
@@ -0,0 +1,46 @@
+---
+id: ECS 태스크 vs k8s 파드 20260304
+created: 2026-03-04 17:22
+tags:
+  - ecs
+  - container
+---
+## 💡 생각  
+결국 태스크와 파드는 같다고 보면된다. 태스크는 ECS에서 쓰고 파드는 EKS에서 쓴다.
+
+## 🤝 ECS 태스크 vs K8s 포드: 공통점
+
+1. **컨테이너의 집합체:** 두 개념 모두 하나 이상의 컨테이너를 포함할 수 있습니다. (예: 메인 앱 + 로그 수집기)
+    
+2. **네트워크 공유:** 태스크/포드 내의 컨테이너들은 동일한 IP 주소를 공유하며 `localhost`를 통해 서로 통신합니다.
+    
+3. **스토리지 공유:** 태스크/포드 수준에서 정의된 볼륨을 내부 컨테이너들이 함께 마운트해서 쓸 수 있습니다.
+    
+4. **생명 주기:** 태스크나 포드가 죽으면 그 안의 컨테이너들도 운명을 같이 합니다.
+
+
+
+## 🧐 굳이 차이점을 찾자면? (한 끗 차이)
+
+개념은 같지만, 그것을 **관리하는 방식**에서 이름표가 달라집니다.
+
+- **ECS ([[파게이트(Fargate)]] 기준):** AWS가 서버를 대신 관리해주기 때문에, 사용자가 "난 이만큼의 자원이 필요해"라고 **태스크 단위로 주문서**를 써야 합니다. 그래야 AWS가 그에 딱 맞는 가상 머신을 뒤에서 빌려줄 수 있으니까요.
+    
+- **[[쿠버네티스(Kubernetes)]]:** 보통 이미 떠 있는 **노드(Node/서버) 덩어리**가 있고, 파드는 그 안에서 자원을 조금씩 나눠 쓰는 '세입자' 같은 느낌입니다. 그래서 리소스 설정이 '실행 기준'이라기보다 '최대/최소 가이드라인'처럼 느껴질 수 있습니다.
+
+### ECS 태스크 (Task)
+
+ECS는 특히 **Fargate** 모드를 쓸 때, 태스크 전체가 사용할 CPU와 메모리를 **태스크 수준**에서 딱딱하게 결정해야 합니다.
+
+- 예: "이 태스크는 무조건 0.5 vCPU와 1GB 메모리를 점유한다."
+    
+- 이 기준이 틀리면 아예 실행이 안 되거나 설정 오류가 납니다. 그래서 질문자님 말씀처럼 "태스크 = 리소스 기준이 명확히 박힌 단위"라는 인상이 강합니다.
+    
+
+### 쿠버네티스 파드 (Pod)
+
+파드도 YAML 설정(Spec) 안에 각 컨테이너가 사용할 `requests`(최소 보장)와 `limits`(최대 제한)를 적습니다.
+
+- 예: "이 컨테이너는 최소 256MB, 최대 512MB 메모리를 쓴다."
+    
+- **차이점:** 쿠버네티스는 여러 컨테이너의 합산 리소스를 보고 노드(서버)의 남는 자리에 파드를 '스케줄링'하는 데 집중합니다. ECS보다 설정이 좀 더 유연하고 복잡하게 느껴질 수 있습니다.
@@ -0,0 +1,63 @@
+---
+id: ECS 태스크 만들기 20260305
+created: 2026-03-05 08:49
+tags:
+---
+## 💡 생각  
+ECS 클러스터의 서비스가 [[태스크(Task)]]를 실행해서 서비스가 구동될 수 있습니다.
+
+
+## 🔢 목록
+
+#### 1. 태스크 정의하기
+태스크는 Amazon **E**lastic **C**ontainer **S**ervice의 태스크 정의 탭에서 정의 가능합니다.
+![[Pasted image 20260305085256.png]]
+
+#### 2. [[태스크 정의 패밀리]] 이름 지정
+![[Pasted image 20260305085241.png]]
+
+#### 3. 인프라 요구 사항 지정
+![[Pasted image 20260305091259.png]]
+진정한 [[서버리스(Serverless)]] 환경 구축을 위해서는 AWS [[파게이트(Fargate)]]를 선택합니다.
+물론 [[EC2(Elastic Compute Cloud)]]로 지정할수도 있습니다.
+
+#### 4. OS, 아키텍처, 네트워크 모드 지정
+[[ECS 태스크 정의]]
+![[ECS 태스크 정의#📑 개념]]
+![[Pasted image 20260305091749.png]]
+여기서는 기본값으로 설정하고 진행했습니다.
+
+#### 5. 태스크 역할 - 조건부 지정
+[[태스크 역할과 태스크 실행 역할]]
+![[Pasted image 20260305093459.png]]
+> [!note] ecsTaskExecutionRole ?
+> 사실상 default 역할인 **AmazonECSTaskExecutionRolePolicy**가 연결되어있음
+![[Pasted image 20260305094500.png]]
+
+작업 배치 - (선택 사항)
+결함 주입 - 선택 사항
+는 일단 지정하지 않았습니다. (아직 뭔지 모름)
+
+#### 6. 컨테이너 생성 (1)
+컨테이너의 이름과 도커 이미지의 위치를 지정합니다.
+![[Pasted image 20260305094813.png]]
+도커 이미지는 [[ECR(Elastic Container Registry)]]에 저장되어 있는 것을 가져다가 사용할 수 있고 (추천)
+프라이빗 공간의 이미지를 가져다가 쓸 수도 있습니다 (만 추가적인 설정이 필요해 보입니다.)
+
+#### 7. 컨테이너 생성(2)
+컨테이너 포트정보를 입력합니다. [[파게이트(Fargate)]]의 경우 컨테이너 포트가 호스트 포트와 반드시 동일해야합니다. (별도로 맞춰줄 필요 없이 컨테이너 포트만 입력하면 알아서 맞춰집니다.)
+![[Pasted image 20260305100339.png]]
+
+읽기 전용 루트 파일 시스템
+리소스 할당 제한 - 조건부
+두가지는 일단 설정하지 않습니다. (아직 잘 모름)
+
+#### 8. 환경 변수 설정
+필요한 환경 변수가 있을 경우 추가해줍니다.
+![[Pasted image 20260305100917.png]]
+추가예시
+![[Pasted image 20260305101005.png]]
+
+#### 9. 로그 수집 설정
+![[Pasted image 20260305101051.png]]
+별도의 로그 수집 정책이 있을 경우 다른 것으로 지정 가능
@@ -0,0 +1,61 @@
+---
+id: ECS 태스크 정의 20260305
+created: 2026-03-05 09:20
+tags:
+---
+---
+## 📑 개념
+> [!abstract] 
+> **"실제로 어떤 하드웨어 환경에서 돌아갈지"**와 **"비용 청구서가 어떻게 나올지"**를 결정하는 핵심 데이터
+
+## 1. 운영 체제 및 아키텍처 (OS & Architecture)
+
+여기서 가장 중요한 건 **ARM64(AWS Graviton)**를 선택하느냐 아니냐입니다.
+
+- **설정 내용:** `X86_64` (인텔/AMD 계열) vs `ARM64` (AWS Graviton 계열)
+    
+- **무엇이 달라지나:** * **호환성:** 내 도커 이미지를 어떤 CPU용으로 빌드했느냐에 따라 선택해야 합니다. (잘못 선택하면 실행 시 `exec format error`가 나며 죽습니다.)
+    
+    - **성능:** ARM64(Graviton) 기반 인스턴스는 최신 세대 가상 머신을 사용하여 가성비가 매우 좋습니다.
+        
+- **💰 비용 차이:** **매우 중요합니다.** 일반적으로 **ARM64 아키텍처를 선택하면 x86보다 약 20% 정도 저렴**합니다. 똑같은 태스크를 돌려도 아키텍처 설정만 바꾸면 돈을 아낄 수 있습니다. (단, 이미지 빌드도 ARM용으로 해야 함)
+    
+
+---
+
+## 2. 네트워크 모드 (Network Mode)
+
+[[파게이트(Fargate)]]를 사용하신다면 사실상 `awsvpc` 모드로 고정되지만, [[EC2(Elastic Compute Cloud)]] 기반에서는 선택지가 나뉩니다.
+
+- **awsvpc 모드 (Fargate 기본):** * **특징:** 각 태스크가 자신만의 **고유한 Private IP**를 가집니다. 마치 VPC 안에 EC2 인스턴스가 하나 더 들어온 것처럼 행동합니다.
+    
+    - **장점:** 보안 그룹(Security Group)을 태스크 단위로 촘촘하게 걸 수 있습니다. (A 태스크는 DB 접근 가능, B 태스크는 불가 등)
+        
+- **Bridge / Host 모드 (EC2 전용):** * **특징:** 호스트 EC2의 IP와 포트를 공유해서 씁니다.
+    
+- **💰 비용 차이:** 네트워크 모드 자체로 돈을 더 받지는 않지만, `awsvpc` 모드 사용 시 발생하는 **데이터 전송 비용(Data Transfer Out)**이나 가용 영역(AZ) 간 통신 비용이 실질적인 비용 차이를 만듭니다.
+    
+
+---
+
+## 3. 리소스 할당 (CPU & Memory)
+
+[[파게이트(Fargate)]] 비용의 핵심입니다. "사용량만큼 낸다"는 말의 정확한 의미는 **"내가 설정한 CPU/메모리 사양만큼 예약해서 낸다"**입니다.
+
+- **착각하기 쉬운 점:** 태스크가 실제로 CPU를 1%만 쓰고 있어도, 설정(예약)을 1 vCPU로 했다면 **1 vCPU만큼의 비용이 꼬박꼬박 나갑니다.** * **차이:** * **설정값:** 0.25 vCPU / 0.5 GB 로 설정하면 가장 저렴합니다.
+    
+    - **비용 구조:** `(vCPU 가격 * 시간) + (GB당 메모리 가격 * 시간)`.
+        
+    - 따라서 실제 사용량보다 너무 과하게 설정하면 서버리스인데도 돈이 많이 나올 수 있습니다.
+
+## 📝 노트
+> [!note]
+> 무엇을 선택해야 유리할까?
+
+| **설정 항목**   | **추천 선택지** | **비용/효율 영향**                   |
+| ----------- | ---------- | ------------------------------ |
+| **아키텍처**    | **ARM64**  | **약 20% 저렴**하며 성능도 우수 (강력 추천)  |
+| **네트워크 모드** | **awsvpc** | 보안 관리가 쉬워지나, ENI 할당 등 관리 요소 발생 |
+| **CPU/메모리** | **최소 필요량** | 설정한 수치에 비례해서 초 단위로 과금됨         |
+
+---
@@ -0,0 +1,19 @@
+### ECS(Elastic Container Service)
+: AWS가 제공해주는 [[컨테이너 오케스트레이션]] 서비스입니다.
+### EKS(Elastic kubernetes Service)
+: [[쿠버네티스(Kubernetes)]]를 AWS의 다른 서비스들과 연동해서 사용할 수 있게 해주는 AWS 서비스입니다. 
+
+> [!note]
+> 
+> - ECS와 EKS는 둘 다 [[컨테이너 오케스트레이션]]을 지원해주는 서비스입니다.
+> - 컴퓨팅 자원으로 [[파게이트(Fargate)]]를 지정할 수 있습니다.
+> - 표준화된 [[배포 파이프라인(Deployment Pipeline)]]을 사용할 수 있습니다.
+
+ECS와 EKS의 핵심 목표는 ==‘컨테이너 기술의 안정적 운영’==임.
+
+![[ECS와 EKS의 차이점]]
+
+ECS는 AWS기반에서는 비교적 쉽고 빠르게 사용 가능 하지만 다른 환경으로의 이식이 어렵고,
+EKS는 러닝커브가 가파르고 복잡도가 높지만 이식성이 매우 높음.
+
+ECS와 EKS는 모두 [[클러스터(Cluster)]] 형태로 구현됨.
@@ -0,0 +1,32 @@
+---
+id: ECS의 구성 20260304
+created: 2026-03-04 16:57
+tags:
+---
+![[ECS와 EKS#ECS(Elastic Container Service)]]
+
+### ECS는 [[클러스터(Cluster)]] 형태로 구성되어집니다.
+![[Pasted image 20260304165810.png]]
+#### [[클러스터(Cluster)]]
+![[클러스터(Cluster)#📑 개념]]
+
+### ECS Cluster는
+> [!note]
+> 하나의 서버에서 구동중인 [[쿠버네티스(Kubernetes)]] 엔진을 사용하는 것 같은 느낌을 주기위해서 만듭니다.
+
+### Cluster에서 서비스가 동작됩니다.
+![[Pasted image 20260304170925.png]]
+
+### 서비스에는 [[태스크(Task)]]가 동작합니다.
+![[Pasted image 20260304171641.png]]
+> [!note]
+> ECS의 태스크에는 태스크가 실행되기 위해 필요한 정보들, 어떤 컨테이너들을 실행해야하는지 등이 정의되어있음.
+
+![[Pasted image 20260304171851.png]]
+위와같이 태스크가 어떤 구성으로 동작해야하는지가 기록되어있고
+![[Pasted image 20260304171939.png]]
+어떤 컨테이너들이 실행되어야 하는지 기재되어있다.
+
+## 💡 생각  
+즉, 태스크는 쿠버네티스에서 말하는 Pod를 실체화시킨 것
+[[ECS 태스크 vs k8s 파드]]
@@ -0,0 +1,29 @@
+## 📑 개념
+> [!abstract] 
+> AWS에서 사용할 수 있는 [[컨테이너 오케스트레이션]] 엔진
+> 클러스터 형태로 구현해놓았고 그걸 EKS라고 함.
+
+
+## 📝 노트
+> [!note]
+> 
+>EKS Cluster의 구조는 크게 Control Plane과 Data Plane 둘로 나눠집니다.
+> Control Plane은 전체적인 지휘소 역할을 하며 오케스트레이션에 필요한 모듈들이 위치하고, Data Plane은 실제 서비스가 돌아가는 자원들이 위치합니다.
+> 
+> 이미지를 보면 5개의 Node가 보이는데 각 노드들을 컨테이너를 담고 있는 가상서버이며 그 위에 실제 서비스 단위인 컨테이너가 구동됩니다.
+> 
+> 각 노드들에는 core-운, swing-cmms, load-balancer 컨테이너들이 구동되고 있습니다.
+> 
+> 로드밸런서는 앞서봤던 Elastic Load Balancer를 가리키는 포인터 역할의 서비스이며 CoreDNS는 클러스터 내부의 통신을 위해 필요한 필수 서비스입니다
+> 
+> Aws에 구현해놓은 cmms 서비스는 현재 이 다섯개의 컨테이너들로 구성되어서 실행되고 있습니다.
+>
+![[Pasted image 20260227162406.png]]
+
+## EKS Cluster 기반의 아키텍처 구조도
+![[Pasted image 20260227163046.png]]
+## VPC 범위까지 확대
+![[Pasted image 20260227163118.png]]
+## 🔗 지식 연결
+- **태그:** #cluster #container #kubernetes
+- 관련 문서: [[ECS와 EKS의 차이점]] [[쿠버네티스(Kubernetes)]]
@@ -0,0 +1,22 @@
+### CMMS의 SaaS 플랫폼화를 해야합니다.
+
+##### 플랫폼화를 할 경우 장점
+> [!check] 
+> - **운영 효율 극대화 및 비용 최적화**
+> 
+> : 기존 EC2 기반의 1:1 관리 방식에서 벗어나 하나의 클러스터에서 여러 테넌트(고객사)를 관리함으로써 운영 공수를 획기적으로 줄입니다.
+> 
+> - **시장 대응 속도(Time-to-Market) 가속화**
+> 
+> : 새로운 고객사가 추가될 때마다 서버를 새로 구축할 필요가 없습니다. 미리 구성된 멀티 테넌시 환경과 커스텀 라우팅을 통해 클릭 몇 번만으로 신규 고객 전용 환경을 즉시 제공(On-boarding)할 수 있어, 비즈니스 기회를 놓치지 않고 빠르게 시장을 확대할 수 있습니다.
+> 
+> - **서비스 안정성 및 보안성 고도화**
+> 
+> : 파드 자동 복구기능을 통해 장애 발생 상황 대응에 인력의 투입이 필요 없어지도록 해줍니다. (관리 포인트가 줄어듦)
+
+> [!note]
+> 
+> - CMMS의 경우 SaaS 플랫폼화가 이미 진행되어있는 상태
+> - Enterprize 요금제를 요구하는 고객을 위한 '설치형 구독형' 모델 구축을 위한 Cloud Architecture 화를 진행한 것임
+> - 기본형의 SaaS CMMS는 이미 존재함
+
@@ -0,0 +1,8 @@
+## [[EC2(Elastic Compute Cloud)]]
+![[EC2(Elastic Compute Cloud)#📑 개념]]
+
+## [[컨테이너(Container)]]
+![[컨테이너(Container)#📑 개념]]
+
+## [[파게이트(Fargate)]]
+![[파게이트(Fargate)#📑 개념]]
@@ -0,0 +1,33 @@
+---
+id: 시작 유형(Launch Type)과 용량 공급자 전략(Capacity Provider Strategy)의 차이 20260305
+created: 2026-03-05 10:24
+tags:
+  - ecs
+  - fargate
+---
+## 💡 생각  
+그냥 용량 공급자 전략을 써야한다고만 기억하면 됨. (기본값도 용량 공급자 전략으로 되어있음)
+
+> [!note]
+> ECS 서비스에서 **시작 유형(Launch Type)**과 **용량 공급자 전략(Capacity Provider Strategy)**은 "내 컨테이너를 어디에 띄울 것인가"를 결정하는 두 가지 방식입니다.
+> 
+> 과거에는 '시작 유형'만 있었지만, 현재는 더 유연한 관리를 위해 '용량 공급자 전략'을 권장하는 추세입니다. 두 방식의 핵심적인 차이를 정리해 드릴게요.
+
+## 1. 시작 유형 (Launch Type) : "단순한 선택"
+
+가장 직관적인 방식입니다. 태스크를 띄울 인프라를 **딱 하나만** 고정해서 선택하는 것입니다.
+
+- **방식:** "나는 무조건 **Fargate**만 쓸 거야" 혹은 "무조건 **EC2**만 쓸 거야"라고 선언합니다.
+    
+- **특징:** 설정이 매우 간단하지만, 여러 종류의 인프라를 섞어서 쓰는 것이 불가능합니다.
+    
+- **비유:** 식당에 가서 "무조건 소고기 메뉴만 주세요"라고 고정 주문을 하는 것과 같습니다.
+    
+
+## 2. [[용량 공급자 전략 (Capacity Provider Strategy)]] : "유연한 배분"
+> [!note] 하나 이상의 인프라(용량 공급자)를 **어떤 비율로 섞어서 쓸지** 결정하는 고도화된 방식입니다.
+
+![[Pasted image 20260305103056.png]]
+![[용량 공급자 전략 (Capacity Provider Strategy)#💡 왜 '용량 공급자 전략'을 써야 할까요? (핵심 이유)]]
+
+
@@ -0,0 +1,11 @@
+순서
+## 1. [[VPC(Virtual Private Cloud)]] 생성
+
+## 2. VPC에 [[서브넷(Subnet)]] 생성
+: 필요에 따라 퍼블릭,프라이빗 서브넷을 생성하면 됨.
+[[Pod를 Private subnet에 두는 이유]]
+## 3. 라우팅 테이블 생성
+
+## 4. 인터넷 게이트웨이 생성
+
+## 5. EC2 생성
@@ -0,0 +1,29 @@
+To-Be
+![[Pasted image 20260227094154.png]]
+
+EC2기반의 아키텍처를 클라우드 컴퓨팅 환경에 맞게 변경한 아키텍처입니다.
+다른 부분은 모두 동일하고 [[파게이트(Fargate)]]라고 적혀있는 이 부분만 달라진 것을 확인할 수 있습니다.
+[[파게이트(Fargate)의 장점]]
+
+컨테이너 기반의 아키텍처로 변경했을떄의 장점
+[[가용성(Availability)]] [[보안성(Security)]]이 확보되고 프로젝트의 [[생산성(Productivity)]]이 증가되고, 프로젝트의 [[유연성(Flexibility)]]과 [[확장성(Scalability)]]확보에 유리해진다.
+
+각각을 현재 상황에맞게 풀어서 설명해보면
+
+[[가용성(Availability)]]: 초기설정을 잘 해 놓으면 [[컨테이너 오케스트레이션]]에 의해 서비스의 자가복구가 가능하다.
+[[유연성(Flexibility)]]: 로드밸런서가 컨테이너 단위로의 접근이 가능해서 동일한 내부 포트(예: 80)를 사용하는 여러 서비스를 띄워도, 각 컨테이너가 고유 IP를 가지므로 충돌 없이 동적 라우팅이 가능하다.
+[[보안성(Security)]]: [[파게이트(Fargate)]] 이용 시 OS 업데이트, 보안패치 등의 OS/인프라 레벨의 보안을 AWS가 책임져준다.
+[[생산성(Productivity)]]: 서버관리 포인트가 줄어들어서 인프라 관리 등의 인프라 운영에 들어가는 반복적인 공수(Heavy Lifting)를 제거하여, 비즈니스 로직 개발 및 서비스 고도화에 인력을 집중 투입할 수 있다.
+
+## 📝 노트
+> [!note]
+EC2는 가상 컴퓨팅 환경이기 때문에 장애 복구에 많은 시간이 필요하지만 fargate는 컨테이너이므로 수초내에 복구할 수 있습니다.
+> 
+> 컨테이너 자체는 자가복구의 기능이 없지만 뒤에서 설명드릴 ECS나 EKS에서는 가능합니다.
+> 
+> 그리고 로드밸런서가 EC2같은 서버가 아닌 컨테이너를 가리킬 수 있습니다. 그로인해 자주 사용되는 80포트등의 포트들이 중복사용으로 충돌을 일으킬 가능성이 없습니다.
+> 
+> A컨테이너의 80포트, B컨테이너의 80포트 이런식으로 상세하게 설정할 수 있기 떄문입니다.
+> 
+> 그리고 AWS가 보안과 서버인프라 문제를 모두 책임져주기 때문에 생산성 향상이 될 수 있습니다.
+
@@ -0,0 +1,18 @@
+---
+id: "태스크 역할과 태스크 실행 역할 20260305"
+created: "2026-03-05 09:38"
+tags:
+---
+[[태스크 역할(Task Role)]] vs [[태스크 실행 역할(Task Execution Role)]]
+
+|**구분**|**태스크 실행 역할 (Execution Role)**|**태스크 역할 (Task Role)**|
+|---|---|---|
+|**누가 쓰는가?**|**ECS 에이전트 / 인프라**|**내 앱 소스 코드 (Container)**|
+|**언제 쓰는가?**|태스크를 **준비하고 띄울 때**|태스크가 **실행 중일 때**|
+|**필수 여부**|대부분 필수 (이미지 풀, 로그 때문)|선택 (AWS 서비스를 안 쓰면 필요 없음)|
+|**예시 정책**|`AmazonECSTaskExecutionRolePolicy`|`AmazonS3FullAccess`, `AmazonDynamoDBReadOnly` 등|
+### 💡 실무에서는 어떻게 설정하나용?
+
+1. **실행 역할(Execution Role):** AWS에서 기본으로 제공하는 `AmazonECSTaskExecutionRolePolicy`를 연결해 주는 것이 국룰입니다. (이거 안 하면 로그가 안 남거나 이미지를 못 가져와서 태스크가 무한 재시작됩니다.)
+    
+2. **태스크 역할(Task Role):** 기본값은 비어있습니다. 내 앱이 S3나 DynamoDB를 써야 할 일이 생길 때만 필요한 권한을 콕 집어서 추가해 주면 됩니다.
@@ -0,0 +1,47 @@
+---
+id: 테넌시 선택 20260305
+created: 2026-03-05 13:18
+tags:
+  - tenancy
+  - cluster
+  - ecs
+  - ecr
+  - saas
+---
+[[싱글 테넌시(Single-tenancy)]] vs [[멀티 테넌시(Multi-tenancy)]]
+: 결정적인 차이는 **물리적으로 격리되어있는지** 여부
+
+### [[멀티 테넌시(Multi-tenancy)]]
+멀티 테넌시를 선택할 때 가장 중요한 것은 **인프라를 공유한다**는 것입니다.
+순수 멀티 테넌시는 하나의 어플리케이션 인스턴스와 하나의 DB를 여러 고객들이 공유해서 사용합니다.
+
+> [!note] 설정값, 환경변수 등의 차이만으로 고객간의 구분을 하고 모든 인프라는 하나를 공유해서 사용
+
+고객간의 요구사항 편차가 적을 경우에는 효율이 좋음
+편차가 클 경우 대응이 매우 어렵거나 거의 불가능에 가깝습니다. (고객 수가 적으면 되긴 함)
+
+**SaaS 솔루션:** 완전한 멀티 테넌시 (공통 기능 + DB 설정 기반 커스텀)
+즉 SaaS 솔루션은 모든 고객들이 하나의 인프라를 공유해서 사용하는 경우를 의미합니다.
+
+
+> [!warning] 이렇게 되면 고객간의 요구사항 편차가 클 경우 대응이 불가능함
+
+이 문제를 해결하기 위해 하이브리드 방식을 채택합니다.
+**"인프라는 공유하되 애플리케이션은 격리하는 방식"** 같은 경우입니다.
+이를 **가상 싱글 테넌시(Virtual Single Tenancy)** 또는 **격리형 멀티 테넌시**라고 부르기도 합니다.
+
+격리형 테넌시 형태로 엔터프라이즈 솔루션 형태로 구성을 해야함.
+**엔터프라이즈 솔루션:** 고객별 컨테이너/네임스페이스 분리 + 이미지 커스텀
+
+테넌시별로 별도의 컨테이너 이미지를 확보해야함
+코드레벨에서 독립되어지기 때문에 클라우드형 싱글테넌시 구조와 유사한 형태의 서비스가 가능
+
+### 엔터프라이즈 솔루션의 구조도
+(고객사별 독립된 어플리케이션 인스턴스 사용 + 하나의 DB 인프라 사용)
+![[Pasted image 20260305140832.png]]
+VPC레벨까지도 격리를 원하는 고객사의 경우에는 위의 이미지대로 별도의 ECS Cluster를 구성
+그정도까지 아니면 하나의 공용 ECS Cluster에 [[태스크(Task)]]만 별도로 추가
+
+## 🔗 관련 노트
+- [[클러스터(Cluster)]]
+- [[ECR(Elastic Container Registry)]]