https://www.youtube.com/watch?v=_lceAtDmlto

description: |

1. 이건 꼭 알아야 한다[^1]

[? 질문] 디지털 비즈니스 시대에 속도/민첩성을 얻기 위해, Kubernetes 기반 DevOps 환경을 “직접 다 만들고 운영”하지 않으면서도 어떻게 구축할 수 있는가[^2]
[= 답] AWS 관리형 서비스(Amazon EKS의 관리형 컨트롤 플레인/관리형 노드 그룹, EKS on Fargate, CodePipeline·CodeCommit·CodeBuild·ECR, CloudWatch Container Insights·CloudWatch Logs Insights·X-Ray)를 조합해 클러스터 운영 부담(업그레이드/가용성/노드관리), CI/CD 파이프라인 구성 부담, 관측(메트릭·로그·트레이스) 부담을 줄이고 팀이 애플리케이션/비즈니스 변화에 집중하도록 만든다.[^3]

[? 질문] Kubernetes 도입 시 많은 팀이 실제로 부딪히는 운영상의 “어려움”은 무엇이며, 왜 DevOps 팀이 ‘삼중고’에 빠지는가[^4]
[= 답] 보안, 복잡도, 모니터링, 네트워킹, 스토리지, 로깅, 스케일링, 가용성 같은 운영 과제가 상위 어려움으로 나타나며(2019 CNCF 설문 인용), 팀은 (1) Kubernetes 자체 복잡성 이해, (2) 이를 위한 DevOps 환경 구축, (3) 그 위의 인프라 구성 고민까지 동시에 떠안아 빠른 변화에 집중하지 못하게 된다.[^5]

[? 질문] “쿠버네티스용 DevOps”를 구성할 때 세션이 제시하는 구성 요소(큰 축) 3가지는 무엇인가[^6]
[= 답] (1) 클러스터 매니지먼트(EKS의 관리 범위 확대: 컨트롤 플레인→데이터 플레인), (2) CI/CD 환경(AWS 개발자 도구로 소스~배포 자동화), (3) 모니터링/가시성(메트릭·로그·트레이스를 관리형 서비스로 수집·분석)이다.[^7]

2. 큰 그림[^8]

이 콘텐츠는 AWS Summit Online Korea 2020 세션으로, Kubernetes(쿠버네티스) 기반의 DevOps 환경을 구축할 때 발생하는 운영 복잡성과 도구 조합의 부담을 AWS 관리형 서비스로 어떻게 완화하는지를 단계적으로 설명한다.[^9] 디지털 비즈니스에서 요구되는 빠른 피드백과 실험/출시 속도를 달성하려면 아키텍처·운영 모델·전달 방식이 함께 바뀌어야 하고, 이를 현실적으로 가능하게 하는 접근으로 컨테이너·쿠버네티스 그리고 그 위의 관리형 생태계를 제시한다.[^10]

• 핵심 메시지 1: 민첩성을 위해선 마이크로서비스, 서버리스 운영 모델(직접 관리 인프라 축소), CI/CD 자동화가 필요하지만, 기존 개발/운영 분리 문화로는 대응이 어렵다.[^11]
• 핵심 메시지 2: Kubernetes는 인프라와 애플리케이션 운영을 오브젝트/선언형(IaC 관점)으로 추상화해 DevOps에 맞지만, 프로덕션 적용은 네트워크·스토리지·보안·가용성 등 때문에 매우 어렵다.[^12]
• 핵심 메시지 3: AWS는 EKS(컨트롤 플레인/데이터 플레인 관리), Code*·ECR(CI/CD), CloudWatch·X-Ray(관측) 같은 관리형 서비스 조합으로 “쿠버네티스 운영의 삼중고”를 줄여 팀이 애플리케이션 구축과 비즈니스 가치 전달에 집중하게 한다.[^13]

3. 하나씩 살펴보기[^14]

3.1 세션 소개와 문제 제기: ‘DevOps’를 왜 다시 이야기하는가[^15]

발표자는 AWS 솔루션즈 아키텍트 김광영이라고 자신을 소개하고, 세션 주제가 “AWS 관리형 서비스를 활용하여 Kubernetes를 위한 DevOps 환경 구축”임을 밝힌다.[^16] 본격적인 서비스 설명 전에 “DevOps”라는 큰 맥락을 먼저 짚는다고 말하며, 이는 곧 기술 나열이 아니라 왜 이런 서비스 조합이 필요한지(배경 문제)를 먼저 공유하겠다는 구성이다.[^17]

오늘날 디지털 비즈니스(‘뉴 노멀’로 표현)에서는 속도와 민첩성이 성공 요인이라고 전제한다.[^18] 피드백 수집/분석이 빨라질수록 고객 반응이 빨라지고 비용을 절감할 수 있으며, 새로운 아이디어를 실험하기 쉬워진다고 연결한다.[^19] 또한 아이디어를 시장에 더 빨리 출시하면 성공 확률이 높아진다고 말한다.[^20]

발표자는 이 “민첩성”을 얻기 위한 일이 크게 3가지라고 정리한다.[^21]

1. 아키텍처 패턴을 마이크로서비스로 전환[^22]
2. 직접 관리하는 인프라를 줄이는 서버리스 운영 모델 도입[^23]
3. 마이크로서비스로 파편화된 컴포넌트들의 소프트웨어 딜리버리를 CI/CD로 완전 자동화[^24]

하지만 기존에는 개발팀과 운영팀이 분리되어 일했고, 기존 방식/문화/조직 구조로는 이런 변화에 유연하게 대처하기 어려웠다고 진단한다.[^25] 그 결과 개발과 운영을 하나로 합친 “DevOps” 개념이 등장했다고 설명한다.[^26]

DevOps를 바라보는 관점이 다양하다는 점도 짚는다.[^27]

• 어떤 사람은 DevOps를 문화라고 말하고[^28]
• 어떤 사람은 새로운 개발/운영 메커니즘이라고도 하며[^29]
• 어떤 사람은 DevOps를 단순히 개발+CI/CD 정도로 이해하기도 한다.[^30]

그러나 발표자는 현실의 DevOps는 그보다 훨씬 크다고 강조한다.[^31] CI/CD, 모니터링, 클러스터링(발음이 다소 불명확하나 “monitoring, clustering” 취지), 그리고 이를 위한 모든 인프라—컴퓨팅/네트워킹/보안/스토리지 등—를 모두 포함하는 더 큰 개념이라고 확장한다.[^32]

3.2 IaC의 이상과 현실: “모든 것을 코드로”가 왜 어려운가[^33]

적은 인력으로 인프라를 더 효율적으로 관리하려는 생각에서 **Infrastructure as Code(IaC)**가 등장했다고 말한다.[^34] IaC는 이상적인 인프라 관리 방법이지만, 실제 수행은 매우 어렵다고 곧바로 한계를 제시한다.[^35]

어려운 이유로는 “수많은 툴들, 인프라, 애플리케이션 코드” 등 모든 것을 IaC화해야 한다는 점을 든다.[^36] 즉 단지 서버 몇 대를 코드로 만든다는 수준이 아니라, 운영에 필요한 구성요소 전체가 코드로 관리되어야 하는데 그것이 현실적으로 쉽지 않다는 문제의식이다.[^37]

여기서 발표자는 개발자/운영자들이 바라게 된 이상적인 요구를 “레이어”라는 표현으로 묶는다.[^38]

• 단순히 인프라뿐 아니라 애플리케이션 끝까지 모두 IaC로 추상화해주는 레이어가 있으면 좋겠다[^39]
• AWS 같은 퍼블릭 클라우드뿐 아니라 온프레미스에서도 쓸 수 있는 IaC 가능한 무엇인가가 있으면 좋겠다[^40]
• 그리고 이런 “모던 운영”을 자동화해줄 수 있으면 좋겠다는 필요가 커졌다고 말한다.[^41]

이러한 필요에 의해 주목받은 것이 **컨테이너(Docker)**와 **쿠버네티스(Kubernetes)**라고 연결한다.[^42]

3.3 컨테이너와 쿠버네티스의 부상: DevOps에 최적화된 이유[^43]

발표는 먼저 Docker 컨테이너가 2013년 오픈소스로 출시되었고, 애플리케이션을 손쉽게 컨테이너로 패키징하여 Docker 엔진이 설치된 어느 서버에도 배포할 수 있게 해주는 기술로 소개한다.[^44] 이 점 때문에 Docker는 앞서 말한 CI/CD를 포함한 DevOps 환경에 최적화된 도구였다고 설명한다.[^45]

컨테이너 기술이 폭발적 지지를 받으며 발전했고 프로덕션 환경에 적용되기 시작하자, 다양한 컨테이너 오케스트레이션 툴들이 등장했다.[^46] 그중에서도 운영 자동화와 “오브젝트 개념”을 통해 인프라와 애플리케이션 운영을 IaC로 추상화할 수 있는 Kubernetes가 시장을 이끌게 되었다고 말한다.[^47]

하지만 Kubernetes 같은 컨테이너 오케스트레이션 툴은 네트워크/컴퓨팅/스토리지/보안 등 “모든 영역”을 추상화하는 복잡한 개념을 갖고 있어 프로덕션 적용이 매우 어렵다고 지적한다.[^48] AWS 고객들이 Kubernetes 도입 시 겪는 어려움을 AWS에 지속적으로 이야기해 왔다고도 덧붙인다.[^49]

3.4 CNCF 2019 설문으로 본 ‘쿠버네티스 운영의 고통’[^50]

발표자는 2019년 CNCF(Cloud Native Computing Foundation) 설문 결과를 인용해, 컨테이너를 도입한 많은 고객들이 겪는 어려움이 무엇인지 설명한다.[^51] “개발자 교육” 같은 항목을 제외하고 상위 랭크에 위치한 어려움으로 다음을 열거한다.[^52]

• 보안[^53]
• 전체 시스템 복잡도[^54]
• 모니터링[^55]
• 네트워킹[^56]
• 스토리지[^57]
• 로깅[^58]
• 컨테이너 스케일링과 인프라를 포함한 스케일링[^59]
• 시스템 가용성[^60]

이 설문이 시사하는 바는, DevOps 팀이 Kubernetes 도입에서 “Kubernetes 자체의 복잡성”만 이해하면 되는 게 아니라, **DevOps 환경 구축의 어려움(기초가 되는 거의 모든 인프라 환경 구축)**까지 포괄적으로 고민해야 한다는 점이라고 해석한다.[^61]

발표자는 이를 “삼중고”로 표현한다.[^62]

1. Kubernetes 도입/이해 자체의 부담[^63]
2. 이를 위한 DevOps 환경 구축 부담[^64]
3. 그 외 “모든 인프라 구성”에 대한 고민까지 동시에 발생[^65]

결과적으로 디지털 비즈니스 핵심인 “빠른 변화”에 집중하지 못하게 된다고 결론짓는다.[^66]

[!IMPORTANT] 왜 이 세션이 ‘관리형 서비스’에 집중하는가
쿠버네티스 운영의 어려움은 단일 기술 문제가 아니라 보안/가용성/스케일링/로깅/모니터링 등 운영 전반으로 확산되며, DevOps 팀이 비즈니스 변화 대응 대신 “플랫폼 만들기”에 매몰될 수 있다는 문제의식이 출발점이다.[^67]

3.5 세션의 3가지 범위 선언: (1)클러스터 (2)CI/CD (3)모니터링[^68]

발표자는 이 문제를 해결하기 위해 AWS의 다양한 컨테이너 관련 서비스로 접근한다고 예고하면서, 오늘 다룰 범위를 3가지로 명확히 나눈다.[^69]

1. Amazon EKS로 Kubernetes 클러스터 매니지먼트 하는 방법[^70]
2. Amazon EKS/Kubernetes를 위한 AWS의 CI/CD 환경[^71]
3. Amazon EKS/Kubernetes를 위한 AWS의 모니터링 환경[^72]

이후 전개는 실제로 이 순서를 따른다.[^73]

3.6 (1) 클러스터 매니지먼트: Amazon EKS가 제공하는 것[^74]

3.6.1 EKS의 기본 포지셔닝: 표준 Kubernetes 호환성과 “플레인 바닐라”[^75]

AWS는 관리형 Kubernetes 서비스인 **Amazon Elastic Kubernetes Service(Amazon EKS)**를 제공한다고 소개한다.[^76] EKS는 CNCF 기준에 맞춰 인증된 Kubernetes 서비스이므로, 파트너 및 Kubernetes 생태계의 기존 툴링/플러그인을 사용할 수 있다고 말한다.[^77]

특히 EKS는 AWS가 임의로 수정하지 않은 “플레인(바닐라) 쿠버네티스” 서비스라는 점을 강조한다.[^78] 따라서 표준 Kubernetes에서 실행되는 애플리케이션은 EKS에서도 호환되며, 쉽게 마이그레이션할 수 있다고 연결한다.[^79]

3.6.2 프로덕션 Kubernetes 운영에 필요한 일들(직접 하면 무엇을 해야 하나)[^80]

발표자는 앞서 설문 결과처럼 프로덕션 운영에는 여러 문제가 따라온다고 말하며, 운영자가 해야 할 구체 작업을 나열한다.[^81]

• 적절한 인스턴스 유형 선택[^82]
• 여러 **가용 영역(AZ)**에서 실행[^83]
• 상태 모니터링 후 불량 노드 교체[^84]
• Kubernetes 컨트롤 플레인/데이터 플레인의 확장성과 가용성 관리[^85]
• 최신 버전 사용을 위한 지속적 패치/업그레이드[^86]

이런 작업은 전문지식과 수작업이 많이 필요하며, DevOps 팀이 스토리지/네트워크/컴퓨팅/보안/OS 등 거의 모든 영역의 전문가가 필요한 상황에 직면한다고 설명한다.[^87]

반대로 EKS를 쓰면 AWS가 클러스터의 관리·업그레이드·고가용성(HA)을 관리해 주므로, 팀은 복잡한 운영 오버헤드를 줄일 수 있다고 말한다.[^88]

3.7 EKS의 진화 1: 컨트롤 플레인 관리(“EKS 1st”, 발표 표현 ‘Sites One’)[^89]

발표자는 “가장 먼저 AWS는 Kubernetes 컨트롤 플레인에 관리 기능을 제공했다”고 말하며 이를 내부적으로 “(사이즈 원/사이트 원)”처럼 명칭한다고 언급한다.[^90] 핵심은 EKS의 초창기 가치가 컨트롤 플레인 관리에 있었다는 점이다.[^91]

EKS 정식 릴리즈(2018) 전부터 AWS는 다양한 방식으로 Kubernetes 환경 제공을 지원해 왔다고 말한다.[^92] 예로:

• ECS에서 Docker를 사용하는 방식[^93]
• kubespray, kops, kubeadm 등 오픈소스 도구로 직접 Kubernetes 클러스터를 만들 수 있도록 커뮤니티 협업[^94]

2018년에 Kubernetes 클러스터의 “두뇌” 역할인 컨트롤 플레인을 관리하는 기능을 제공해 고객이 더 쉽게 Kubernetes를 쓰도록 도왔다고 정리한다.[^95]

3.7.1 관리형 컨트롤 플레인의 아키텍처 특징(가용성 설계)[^96]

발표는 EKS 관리형 컨트롤 플레인의 구성을 “간단히” 살펴본다.[^97]

• 고가용성의 싱글 테넌트 아키텍처[^98]
• 모든 컴포넌트는 네이티브 AWS 서비스로 구성[^99]
• **Network Load Balancer(NLB)**로 API Server 앞단을 구성[^100]
• 컨트롤 플레인 API Server는 이중화[^101]
• 클러스터 상태를 저장하는 etcd(발음이 “s2”로 들리나 맥락상 etcd)는 3중화[^102]
• 한 가용 영역에 장애가 나더라도 자동 복구하여 가용성을 유지하도록 설계[^103]

결론적으로 AWS가 관리하기 때문에 사용자는 컨트롤 플레인 구성/관리 오버헤드를 줄일 수 있다고 다시 강조한다.[^104]

3.8 EKS의 진화 2: 데이터 플레인(워커 노드)까지 관리(“EKS 2nd/3rd”, 발표 표현 ‘3 East’)[^105]

컨트롤 플레인 관리로 일부 어려움은 해결됐지만, 데이터 플레인(워커 노드) 관리는 고객이 직접 해야 하는 불편함이 있었다고 말한다.[^106] 그래서 AWS는 고객 피드백을 기반으로 워크로드가 실제 배포되는 데이터 플레인을 관리형으로 제공하는 기능을 출시했으며(작년 KubeCon 즈음 언급), 이를 “(에세이스트/3 이스트)”라고 부른다고 설명한다.[^107]

3.8.1 관리형 워커 노드 그룹(Managed Node Groups)의 의미와 동작[^108]

“가장 큰 변화”로 관리형 워커 노드 기능을 꼽는다.[^109] EKS의 노드 그룹을 사용하면 다음이 가능해진다고 설명한다.[^110]

• EC2 인스턴스나 Auto Scaling Group을 별도 프로비저닝/관리할 필요가 줄어든다.[^111]
• “한 번의 조작”으로 클러스터 노드를 생성/업데이트/종료할 수 있다.[^112]
• 노드는 AWS 계정에서 EKS 최적화 AMI로 실행된다.[^113]
• 업데이트/종료 시 노드를 적절히 “비워”(드레인) 애플리케이션이 지속 사용 가능하도록 돕는다.[^114]
• 관리형 노드는 EKS가 관리하는 EC2 Auto Scaling Group 일부로 프로비저닝된다.[^115]
• 인스턴스와 ASG를 포함한 리소스가 사용자 AWS 계정 내에서 실행된다.[^116]
• 노드 그룹은 여러 가용 영역에서 실행되도록 정의할 수 있다.[^117]

3.8.2 프로비저닝/운영 도구: 콘솔부터 IaC까지[^118]

EKS 클러스터 프로비저닝 방법은 여러 가지가 있다고 하며, 다음 도구들을 나열한다.[^119]

• Amazon EKS 콘솔[^120]
• EKS 공식 CLI 도구(언급상 “eksctl” 취지)[^121]
• AWS CLI / AWS API[^122]
• AWS CloudFormation 등 다양한 IaC 도구[^123]

또한 관리형 노드 그룹으로 시작된 노드는 클러스터 오토스케일러가 자동 검색할 수 있도록 태그가 자동 설정되고, 노드 그룹을 통해 Kubernetes 레이블을 노드에 적용하고 언제든 업데이트할 수 있다고 설명한다.[^124]

[!TIP] 관리형 노드 그룹의 실무적 포인트
노드 생성/업데이트/종료를 “클러스터 관점”에서 일관되게 수행하고, 드레인(노드 비우기) 같은 운영 절차를 서비스가 돕는다는 점이 운영 부담을 크게 낮춘다.[^125]

3.9 완전 관리형 데이터 플레인: EKS on AWS Fargate[^126]

발표는 여기서 한 단계 더 나아가, “완전 관리형 Kubernetes 서비스”로 AWS Fargate for Amazon EKS를 소개한다.[^127] (발표에서는 “aws 파게이트 포 아마존 EKS”) Fargate는 서버리스 방식으로 컨테이너를 실행하는 컴퓨팅 엔진이며, Kubernetes에서도 컨테이너(파드)를 안정적으로 대규모 실행할 수 있게 한다고 설명한다.[^128]

Fargate의 특성으로 “모든 파드가 싱글 버추얼 머신에 배포된다”는 표현을 쓰며, 이 특성상 기본적으로 모든 파드에 대한 강력한 보안 격리가 가능하다고 말한다.[^129] 결과적으로 고객은 DevOps 팀이 애플리케이션 구축에만 집중할 수 있게 된다고 한다.[^130]

아키텍처 관점에서 “고객 계정의 인스턴스에 파드가 배포되지 않고 AWS가 관리하는 Fargate 컴퓨팅에 파드가 배포되므로 고객이 데이터 플레인을 관리할 필요가 없어졌다”고 정리한다.[^131]

3.9.1 사용자 경험 변화(장점): 비용·운영·격리[^132]

EKS on Fargate로 인해 사용자 경험이 어떻게 바뀌는지 항목으로 설명한다.[^133]

• 워커 노드를 관리하지 않으므로 유휴 자원 비용 및 클러스터 오토스케일러를 더 이상 신경 쓸 필요가 줄어든다.[^134]
• 파드 단위로 VM 아이솔레이션이 가능해지고[^135]
• 파드 단위 과금이므로 멀티테넌트 시나리오에서 손쉽게 비용 절감이 가능해진다고 말한다.[^136]

3.9.2 제약 사항(당시 시점): 데몬셋/서비스 타입/스테이트풀 제약[^137]

동시에 “노드가 없는 Fargate 특성상” 제약이 있음을 명확히 말한다.[^138]

• DaemonSet 배포가 불가능[^139]
• (표현상) 애플리케이션 로드 밸런서 외 다른 서비스 타입 로드밸런서 사용이 아직 불가능[^140]
• Privilege 권한이 필요한 것이나 StatefulSet 같은 워크로드는 아직 사용이 불가능하다고 언급한다.[^141]

3.10 워커 노드 구성 옵션의 유연화: 관리형/자가관리/Fargate 조합[^142]

Fargate와 관리형 노드 그룹 옵션이 추가되며 EKS에서 워커 노드 구성이 더 유연해졌다고 정리한다.[^143] 발표는 대표 구성을 3가지 흐름으로 제시한다.[^144]

1. 관리형 워커 노드 또는 자가 관리 워커 노드 사용[^145]
2. 상태 비저장(stateless) 애플리케이션만 있다면 Fargate만 워커로 사용 가능[^146]
3. Fargate의 유연함 + EC2 예약 인스턴스/스팟 같은 비용 최적화를 함께 원하면 Fargate + EC2 워커 노드 혼용도 가능[^147]

이어서 “관리형 노드 그룹으로 구성한 EKS 클러스터 샘플 아키텍처”를 보여준다.[^148]

• EKS가 관리하는 VPC에 싱글 테넌트 EKS 컨트롤 플레인이 있고[^149]
• 고객이 관리하는 VPC에 관리형 워커 노드가 3개 AZ에 배포되어 고가용성을 확보하는 구조라고 설명한다.[^150]
• 이는 eksctl 같은 프로비저닝 도구로 손쉽게 구축할 수 있다고 말한다.[^151]

3.11 (2) Kubernetes에서의 CI/CD: AWS 개발자 도구로 “소스-빌드-테스트-배포” 연결[^152]

이제 발표는 두 번째 축으로 넘어가 “AWS 관련 서비스를 통해 Kubernetes 환경에서 CI/CD 환경을 어떻게 구축하는지”를 다룬다.[^153]

AWS가 엔터프라이즈급 툴셋을 포괄적으로 제공한다고 말하며, CI/CD부터 CloudFormation/SDK 같은 IaC 관련 서비스, ID(식별/접근)·모니터링·트레이싱 서비스까지 DevOps에 필요한 다양한 서비스를 제공해 개발/운영을 빠르고 신속하게 하도록 돕는다고 주장한다.[^154]

3.11.1 소프트웨어 릴리즈 프로세스 4단계 모델[^155]

일반적으로 소프트웨어 릴리즈 프로세스를 소스(Source) → 빌드(Build) → 테스트(Test) → 디플로이(Deploy) 4단계로 정의한다고 소개한다.[^156] 그리고 각 단계에 따라 CI/CD 도구들이 구분되어 사용된다는 맥락을 깐다.[^157]

AWS는 컨테이너 환경에서 “지속적 전달(Continuous Delivery)” 전체 프로세스를 구성할 수 있는 서비스를 제공한다고 말한다.[^158]

3.11.2 CodePipeline으로 EKS 지속 배포 파이프라인 구성(전체 흐름)[^159]

AWS CodePipeline을 사용하면 간단한 설정으로 EKS에 지속적으로 배포할 수 있다고 설명한다.[^160] 발표는 파이프라인을 다음 흐름으로 구체화한다.[^161]

• CodePipeline의 Source 스테이지에서 지정한 저장소 변경을 자동 감지[^162]
• Build 단계에서 지정한 CodeBuild가 컨테이너(도커) 이미지를 빌드[^163]
• 빌드한 이미지를 **Amazon ECR(Elastic Container Registry)**에 푸시[^164]
• 이후 CodeBuild가 kubectl을 이용해 EKS에 파드 배포[^165]

이 다음부터는 각 서비스를 하나씩 소개하며, “무엇을 해주고 왜 편한지”를 설명한다.[^166]

3.12 CI/CD 구성 요소 상세 1: AWS CodePipeline[^167]

CodePipeline은 빠르고 신뢰할 수 있는 애플리케이션 업데이트를 위한 지속적 전달 서비스라고 정의한다.[^168] 릴리즈 프로세스 모델링 및 제어가 가능하고, 코드가 변경될 때마다 빌드/테스트/배포를 실행할 수 있다고 말한다.[^169]

또한 사용자가 많이 쓰는 “Git 같은 타사 도구” 및 다양한 AWS 서비스와 통합할 수 있다고 강조한다.[^170]

3.13 CI/CD 구성 요소 상세 2: AWS CodeCommit[^171]

AWS CodeCommit은 안전한 Git 기반 리포지토리를 호스팅하는 완전 관리형 소스 제어 서비스라고 소개한다.[^172]

팀 협업 관점에서 다음을 지원한다고 말한다.[^173]

• 코드를 쉽게 커밋하고[^174]
• 브랜치/병합으로 팀 프로젝트를 제어[^175]
• Pull Request를 통해 코드 리뷰를 요청하고 공동 작업자가 코드를 토론하는 메커니즘 제공[^176]

접근 방식은 AWS 콘솔뿐 아니라 AWS CLI, AWS SDK로도 사용 가능하다고 말하며,[^177] 클라이언트는 HTTPS 또는 SSH 중 원하는 방법을 사용하면 된다고 설명한다.[^178]

3.14 CI/CD 구성 요소 상세 3: AWS CodeBuild[^179]

AWS CodeBuild는 소스 코드를 컴파일/테스트/패키징하는 완전 관리형 빌드 서비스라고 정의한다.[^180]

발표가 강조하는 운영상 이점은 다음과 같다.[^181]

• 사용자가 “마스터 서버/인스턴스”를 직접 설치·관리할 필요가 없다.[^182]
• 요구에 따라 지속적으로 확장하며 여러 빌드를 동시에 처리할 수 있다.[^183]
• 사용한 컴퓨팅 리소스에 대해서만 분 단위 과금이 된다.[^184]
• 각 빌드는 일관된 불변 환경을 위해 새로운 도커 컨테이너에서 실행된다.[^185]

또한 공식 CodeBuild 이미지는 Docker와 AWS CLI를 포함하고 있으며,[^186] 도커 이미지를 사용해 요구에 맞는 사용자 지정 빌드 환경을 제공할 수 있다고 설명한다.[^187]

3.15 CI/CD 구성 요소 상세 4: Amazon ECR(컨테이너 레지스트리)과 보안 기능[^188]

컨테이너 환경에서는 “싱글 소스(단일 진실 공급원)로서의 컨테이너 이미지 레지스트리”가 매우 중요하다고 전제한다.[^189] 이를 위해 완전 관리형 프라이빗 도커 레지스트리인 Amazon ECR을 소개한다.[^190]

ECR의 특징으로 발표는 다음을 말한다.[^191]

• Docker Registry HTTP API V2 지원[^192]
• 기본적으로 확장 가능하고 고가용성/고내구성 아키텍처[^193]
• DevOps 팀이 레지스트리를 직접 관리하는 오버헤드를 완전히 제거[^194]
• 기본 암호화 제공, IAM 기반 액세스 제어 가능[^195]
• 이미지 수명주기(lifecycle) 관리 가능[^196]
• 다른 AWS 서비스와의 빌트인 통합[^197]
• 이미지 태그 덮어쓰기를 막는 변경 불가능한 태그(Immutable tags) 지원[^198]
• 이미지 스캐닝 기능으로 더 안전하게 이미지 사용 가능[^199]

[!IMPORTANT] 컨테이너 레지스트리 운영의 핵심
파이프라인 자동화의 신뢰성을 위해서는 “어떤 이미지가 배포됐는지”를 확정할 수 있어야 하며(태그 덮어쓰기 방지), 취약점 점검(스캐닝)과 접근 제어(IAM) 같은 통제가 기본 기능으로 결합되어야 한다는 관점을 제시한다.[^200]

3.16 CI/CD 아키텍처 예시: 개발자 커밋부터 파드 배포까지의 명령 흐름[^201]

발표는 앞서 설명한 서비스들을 이용해, 기존에 구성한 EKS 클러스터 아키텍처에 CI/CD 환경을 추가한 예시 흐름을 단계적으로 묘사한다.[^202]

1. 개발자가 Cloud9을 통해 소스 코드를 작성한 뒤 CodeCommit에 커밋한다.[^203]
2. CodePipeline이 저장소 변경을 체크하고 새 빌드를 실행한다.[^204]
3. CodeBuild가 빌드를 수행해 애플리케이션 및 컨테이너 이미지를 빌드하고 ECR에 푸시한다.[^205]
4. 이미지 푸시 후 CodeBuild가 EKS 컨트롤 플레인의 API Server에 “새로운 desired state로 새 버전의 파드를 배포하라”고 명령한다(= kubectl 적용 흐름).[^206]
5. API Server는 데이터 플레인의 각 워커 노드에 새 파드 배포를 지시하고,[^207] 각 워커 노드의 kubelet이 Docker를 통해 ECR에서 이미지를 내려받아 파드를 배포한다.[^208]

이로써 클러스터 매니지먼트와 CI/CD 이야기를 마쳤다고 구획을 나눈다.[^209]

3.17 (3) 모니터링: 마이크로서비스/컨테이너 환경에서 왜 더 중요해지는가[^210]

DevOps를 이야기하면 CI/CD와 개발환경이 떠오르지만, 그에 못지않게 중요한 것이 모니터링이라고 강조하며 세 번째 축으로 넘어간다.[^211]

마이크로서비스 아키텍처로 바뀌면 컴포넌트 수가 많아지고 컴포넌트 간 의존성이 복잡해져 서비스 장애 추적이 매우 어려워진다고 말한다.[^212] 또한 기존 VM 환경에서 컨테이너로 바뀌면서 컨테이너화된 워크로드 상태를 확인하는 것 역시 어려워졌다고 설명한다.[^213]

이런 환경에서 서비스 상태에 대한 “가시성”을 확보하려면 3가지 모니터링 요소를 지속적으로 관찰해야 한다고 정리한다.[^214]

• 첫 번째: 메트릭(Metrics)[^215]
• 두 번째: 로그(Logs)[^216]
• 세 번째: 트레이스(Traces)[^217]

그리고 AWS는 이 3요소를 EKS/Kubernetes 클러스터에서 관찰하기 위한 빌딩 블록을 제공한다고 말한다.[^218] 구체적으로:

• 로그와 메트릭 수집: CloudWatch(및 Container Insights)[^219]
• 애플리케이션 디버깅/트레이싱: AWS X-Ray[^220]

또한 팀마다 컨테이너 플랫폼이 다르거나(관리형/직접관리 혼재), 여러 환경에서 실행되는 서비스를 모니터링하기 위한 일관된 인터페이스가 필요해 DevOps 팀이 어려움을 겪는다고 말한다.[^221] CloudWatch와 X-Ray로 컨테이너 가시성을 확보하면 이런 부담을 줄이고 DevOps 팀이 “본연의 업무(민첩한 환경)”에 집중할 수 있다고 주장한다.[^222]

3.18 CloudWatch Container Insights: 메트릭/로그 수집과 자동 지표 생성[^223]

발표자는 먼저 CloudWatch Container Insights를 설명한다.[^224] 이를 활용하면 “큐레이션된 지표” 및 컨테이너 에코시스템 로그를 간단히 수집하고 쉽게 확인할 수 있다고 말한다.[^225]

수집 대상/특징으로 다음을 언급한다.[^226]

• 각 컨테이너에서 CPU/메모리/네트워크/디스크 같은 컴퓨팅 성능 스펙을 “성능 이벤트”로 수집[^227]
• 모니터링/정보 제공에 사용되는 사용자 지정 지표를 자동 생성할 수 있음[^228]

또한 성능 메트릭은 문제 해결을 간소화하기 위해 EKS(및 관련 리소스) 메타데이터와 함께 CloudWatch로 수집된다고 설명한다.[^229] (발표에서는 로드밸런서, EBS 볼륨 마운트, 태스크/노드 등과 함께라는 취지의 메타데이터 결합을 언급한다.)[^230]

3.19 CloudWatch Logs Insights: 로그에서 지표 추출, 고급 쿼리 분석[^231]

CloudWatch Logs로 수집된 로그에서 자동으로 지표를 추출할 수 있고, Logs Insights에서 고급 쿼리 언어로 추가 분석할 수 있다고 설명한다.[^232]

컨테이너 인사이트를 활용하면 다음 로그들도 수집할 수 있다고 말한다.[^233]

• 애플리케이션 로그[^234]
• 사용자 지정 로그[^235]
• (EC2 기반인 경우) EKS 데이터 플레인 로그, 컨트롤 플레인 로그[^236]

EKS/Kubernetes 클러스터는 “사전 구성된 FluentD/CloudWatch Agent(취지)”를 사용해 로그를 수집한다고 설명한다.[^237] Logs Insights를 사용하면 CloudWatch에 모인 로그 데이터를 대화식으로 검색·분석할 수 있다고 말한다.[^238]

또한 DevOps 팀이 EKS에 FluentD·CloudWatch Agent를 설치해 데이터 플레인 또는 컨트롤 플레인의 로그를 수집하여 문제를 빠르게 특정/조치할 수 있다고 설명한다.[^239]

Logs Insights에는 시작을 돕는 기능으로 다음을 언급한다.[^240]

• 간단하지만 강력한 “특수 쿼리 언어”[^241]
• 샘플 쿼리 제공, 자동 작성 지원, 로그 셰이딩(표현 불명확하나 검색/시각화 보조 기능) 및 검색 기능[^242]
• 여러 AWS 서비스 유형별 샘플 쿼리 포함[^243]

3.20 AWS X-Ray: 마이크로서비스의 엔드-투-엔드 트레이싱과 근본 원인 분석[^244]

마지막 모니터링 구성 요소로 트레이싱 서비스인 AWS X-Ray를 소개한다.[^245]

EKS/Kubernetes 클러스터에 X-Ray 데몬셋/디플로이(발표에서는 “데몬 설치”라고 표현)와 애플리케이션에 X-Ray SDK/디펜던시를 추가하면, X-Ray로 애플리케이션과 기반 서비스가 어떤 성능 문제와 연관이 있는지 “근본 원인”을 찾아 문제를 해결할 수 있다고 설명한다.[^246]

X-Ray는 요청이 애플리케이션을 통과하는 과정에 대해 엔드 투 엔드 뷰를 제공하고, 애플리케이션 구성 요소를 맵 형태로 보여준다고 설명한다.[^247]

또한 단일 애플리케이션부터 수천 개 서비스로 구성된 복잡한 마이크로서비스까지, 개발 중/프로덕션 적용된 애플리케이션 모두를 분석할 수 있다고 말한다.[^248]

3.21 모니터링이 결합된 전체 아키텍처의 상태: “대부분이 관리형”이 주는 효과[^249]

발표는 앞서 설명한 서비스들을 이용해, 기존 EKS 클러스터 아키텍처에 모니터링 환경을 추가했을 때 DevOps 팀이 얻는 효과를 정리한다.[^250]

• Container Insights 기본 지표로 컨테이너 상태를 쉽게 확인[^251]
• CloudWatch Logs로 수집된 로그를 Logs Insights로 분석 가능[^252]
• 애플리케이션 성능 저하를 X-Ray로 분석해 문제 해결 체계를 갖춤[^253]

전체 아키텍처를 보면(예시 기준) “일부 파트에서 관리형 데이터 노드를 사용하는 경우를 제외하면” 대부분 서비스가 AWS 관리형 서비스라고 말한다.[^254] 이 결과 DevOps 팀은 Kubernetes 개발/운영 환경을 효율적으로 관리하고 비즈니스에 집중할 수 있는 아키텍처를 갖게 된다고 결론짓는다.[^255]

3.22 결론/키 테이크어웨이: AWS가 제공하는 ‘광범위한’ 쿠버네티스 DevOps 구성요소[^256]

발표자는 AWS 컨테이너/DevOps 생태계가 풍부하고 광범위하여 요구에 따라 기능을 보호(=보완/선택)할 수 있다고 전제한 뒤, 오늘 세션의 “키 테이크어웨이”를 항목으로 정리한다.[^257]

• AWS는 DevOps와 Kubernetes를 위한 광범위한 서비스를 제공한다.[^258]
• 클러스터 매니지먼트: 관리형 컨트롤 플레인, 관리형 데이터 플레인, **완전 관리형 데이터 플레인(Fargate)**을 제공한다.[^259]
• Kubernetes를 위한 CI/CD: 완전 관리형 개발자 도구로 CodePipeline, CodeBuild, CodeCommit 등을 제공한다.[^260]
• 완전 관리형 컨테이너 이미지 레지스트리로 Amazon ECR을 제공한다.[^261]
• 모니터링: 컨테이너 메트릭/로그 관측을 위한 CloudWatch, 트레이싱을 위한 X-Ray를 제공한다.[^262]

또한 CNCF 설문에서도 2019년 기준으로 “가장 많은 고객들이 AWS 위에서 프로덕션 Kubernetes를 운영”하고 있다고 언급한다.[^263] 고객들이 AWS 컨테이너 서비스를 선호하는 이유로는:

• 컨테이너 애플리케이션 관리에 필요한 가장 광범위한 기능을 제공하고[^264]
• 컨테이너를 실행하는 “가장 쉬운 장소”이기 때문이라고 말한다.[^265]

더 나아가 AWS 컨테이너 서비스는 AWS 클라우드와 긴밀하게 통합되어 IAM 보안, VPC 네트워킹, 로드 밸런싱 이점을 얻으면서 개발자 도구로 DevOps 워크플로를 사용할 수 있다고 말한다.[^266] 보안/규정 준수 측면에서도 고객의 수고와 걱정을 덜어준다고 덧붙인다.[^267]

마지막으로 더 많은 자료/실습을 원하는 사람에게 EKS 워크샵, “메시 워크샵”, AWS DevOps/컨테이너 페이지를 안내하고, 솔루션즈 아키텍트나 어카운트 매니저에게 도움을 요청하라고 말한 뒤 피드백/설문 참여를 부탁하며 마무리한다.[^268]

4. 핵심 통찰[^269]

1. DevOps의 병목은 CI/CD만이 아니라, 플랫폼(인프라·관측·보안·가용성) 운영 부담 전체에서 발생한다는 관점이 세션의 출발점이다.[^270]
2. Kubernetes는 IaC적(선언형/오브젝트) 운영을 가능케 하지만, 그 자체가 “운영 복잡성 덩어리”가 될 수 있어 관리형 레이어가 실무에서 중요해진다.[^271]
3. EKS의 핵심 가치는 “표준 쿠버네티스 호환”을 유지하면서도, 운영자가 부담스러워하는 영역(컨트롤 플레인→노드 관리→서버리스 데이터 플레인)으로 관리 범위를 점진적으로 확대한 데 있다.[^272]
4. CI/CD는 “툴을 나열”하는 것이 아니라, 저장소 변경 감지 → 빌드/테스트 → 이미지 레지스트리 → kubectl 배포로 이어지는 “명령/상태 전파 체계”로 이해해야 한다는 점을 아키텍처 흐름으로 보여준다.[^273]
5. 관측은 메트릭·로그·트레이스 3요소가 함께 있어야 하며, 특히 마이크로서비스/컨테이너 전환은 장애 추적 난이도를 크게 올리므로 일관된 관측 인터페이스가 중요하다는 문제의식이 강조된다.[^274]

• 실행 관점 시사점(세션 내용 기반)
  • EKS 도입 시 “무엇을 직접 운영할지”를 컨트롤 플레인/노드/파드 단위로 나눠 관리형 수준을 선택하라(관리형 노드 그룹 vs Fargate 혼용 포함).[^275]
  • 파이프라인에는 ECR의 immutable tag와 image scanning 같은 통제를 결합해, 배포 신뢰성과 보안을 동시에 확보하라.[^276]
  • 운영 가시성은 CloudWatch(메트릭/로그)와 X-Ray(트레이스)를 함께 설계해, 장애 시 “어디서 느려졌는지”를 엔드투엔드로 추적 가능하게 하라.[^277]

5. 헷갈리는 용어 정리[^278]

DevOps: 개발과 운영을 하나의 흐름으로 통합해, CI/CD뿐 아니라 모니터링·클러스터링 및 컴퓨팅/네트워킹/보안/스토리지 등 인프라 전반을 포함해 효율적으로 운영하려는 더 큰 개념으로 설명됨.[^279]
IaC(Infrastructure as Code): 인프라를 코드로 정의/관리하는 방식. 이상적이나 인프라·도구·애플리케이션까지 모두 코드화하는 실행이 어렵다는 맥락으로 제시됨.[^280]
컨트롤 플레인(Control Plane): Kubernetes 클러스터의 “두뇌”. API Server와 etcd 등으로 구성되며 EKS가 관리형으로 제공(이중화/3중화 등)한다고 설명됨.[^281]
데이터 플레인(Data Plane): 실제 워크로드(파드)가 배포되는 워커 노드 영역. 초기에는 고객 부담이 컸고, 이후 관리형 노드 그룹 및 Fargate로 관리 범위가 확대된 것으로 설명됨.[^282]
관리형 노드 그룹(Managed Node Groups): EKS가 워커 노드의 생성/업데이트/종료와 EKS 최적화 AMI 사용, 드레인 기반 업데이트 등을 지원하는 기능으로 소개됨.[^283]
AWS Fargate for EKS: 노드 관리 없이 파드가 AWS 관리 컴퓨팅에 배포되는 서버리스 실행 방식. 파드 단위 과금/격리 장점과 데몬셋 등 제약을 함께 언급함.[^284]
CI/CD: 소스-빌드-테스트-배포 단계를 자동화하는 전달 방식. CodePipeline/CodeBuild/ECR/kubectl을 통해 EKS에 지속 배포하는 흐름으로 설명됨.[^285]
CloudWatch Container Insights: 컨테이너 지표/로그 수집 및 자동 사용자 지정 지표 생성까지 지원하는 관측 기능으로 소개됨.[^286]
CloudWatch Logs Insights: 수집된 로그를 대화형으로 검색/분석하는 기능. 고급 쿼리 언어 및 샘플 쿼리 제공이 언급됨.[^287]
AWS X-Ray: 요청의 엔드투엔드 트레이싱과 서비스 맵 기반 분석으로 근본 원인 파악을 돕는 서비스로 설명됨.[^288]

---

참고(콘텐츠 정보)[^289]

• 제목: AWS 관리형 서비스를 활용하여 Kubernetes 를 위한 Devops 환경 구축하기 - 김광영, AWS 솔루션즈 아키텍트 (AWS Summit Online Korea 2020)[^290]
• 채널: Amazon Web Services Korea[^291]
• 길이: 28분 29초[^292]
• 링크: https://www.youtube.com/watch?v=_lceAtDmlto[^293]

[^1]: @[00:23]~@[00:37] “aws 관리형 서비스를 활용하여 … 쿠버네티스를 위한 … 환경 구축하기” [^2]: @[00:49]~@[01:06] 디지털 비즈니스에서 속도/민첩성, 빠른 피드백과 비용 절감, 실험 가능성 [^3]: @[05:46]~@[06:03] 세션 범위(클러스터/CI/CD/모니터링) + @[06:14]~@[12:33] EKS 관리 + @[15:20]~@[19:51] Code*·ECR 파이프라인 + @[20:33]~@[24:52] CloudWatch·X-Ray [^4]: @[04:30] 설문 결과 소개 예고 [^5]: @[04:37]~@[05:38] CNCF 2019 설문 상위 어려움(보안/복잡도/모니터링/네트워킹/스토리지/로깅/스케일링/가용성)과 ‘삼중고’ 설명 [^6]: @[05:46] 세 가지 주제 예고 [^7]: @[05:46]~@[06:03] 1) EKS 클러스터 2) CI/CD 3) 모니터링 [^8]: @[00:49]~@[01:34] 민첩성 배경 + @[05:38]~@[06:03] 세션 구성 [^9]: @[05:38]~@[06:03] “aws … 컨테이너 관련 서비스 … 문제 해결” [^10]: @[00:49]~@[01:26] 속도/민첩성과 마이크로서비스·서버리스·CI/CD + @[02:23]~@[03:23] IaC 요구와 컨테이너/쿠버네티스 연결 [^11]: @[01:11]~@[01:26] 민첩성 위한 3가지(마이크로서비스/서버리스/CI-CD) + @[01:34]~@[01:45] 기존 문화/조직의 한계 [^12]: @[03:41]~@[04:18] 쿠버네티스의 운영 자동화/오브젝트/IaC 추상화와 프로덕션 적용 어려움 [^13]: @[05:38]~@[06:03] 해결 접근(클러스터/CI-CD/모니터링) + @[06:14]~@[12:33] EKS 관리 + @[15:20]~@[18:43] Code*·ECR + @[20:33]~@[24:52] CloudWatch·X-Ray + @[25:06]~@[25:14] 비즈니스 집중 [^14]: @[00:40] 이후 DevOps 배경→EKS→CI/CD→모니터링 순 전개 [^15]: @[00:40]~@[02:05] DevOps 배경 설명 [^16]: @[00:23] 발표자 소개 [^17]: @[00:40] “서비스 이야기 전에 DevOps 먼저” [^18]: @[00:49] 속도와 민첩성 [^19]: @[00:57] 피드백 수집/분석 속도와 고객 반응/비용절감/실험 [^20]: @[01:06] 출시가 빠를수록 성공 확률 [^21]: @[01:11] “크게 3가지” [^22]: @[01:16] 마이크로서비스 [^23]: @[01:18] 서버리스 운영 모델 [^24]: @[01:26] CI/CD 통한 완전 자동화 [^25]: @[01:34]~@[01:45] 개발/운영 분리, 문화/조직 구조 한계 [^26]: @[01:45]~@[01:51] DevOps 개념 등장 [^27]: @[01:51]~@[02:05] DevOps에 대한 다양한 표현 [^28]: @[01:51] “문화” [^29]: @[01:57] “새로운 개발 운영 메커니즘” [^30]: @[01:59] “단순히 … CI/CD” [^31]: @[02:05]~@[02:09] “그보다 훨씬 큽니다” [^32]: @[02:09]~@[02:21] CI/CD, 모니터링, 인프라(컴퓨팅/네트워킹/보안/스토리지 등) 포함 [^33]: @[02:23]~@[03:13] IaC와 그 한계, 추상화 레이어 필요 [^34]: @[02:23]~@[02:32] IaC 등장 배경 [^35]: @[02:32]~@[02:40] “이상적이지만 실제 수행 어렵다” [^36]: @[02:40]~@[02:49] 수많은 툴/인프라/애플리케이션 코드 IaC화 어려움 [^37]: @[02:49] 문맥상 전체 코드화의 난이도 강조 [^38]: @[02:49]~@[03:08] 추상화 레이어에 대한 바람 [^39]: @[02:53] 애플리케이션까지 IaC 추상화 [^40]: @[03:00] AWS/온프레미스 모두에서 사용 [^41]: @[03:08]~@[03:13] “모던 운영 자동화” [^42]: @[03:15] 컨테이너/쿠버네티스 주목 [^43]: @[03:23]~@[04:05] Docker와 쿠버네티스 설명 [^44]: @[03:23]~@[03:41] 2013 Docker 오픈소스, 어디든 배포 가능 [^45]: @[03:41] DevOps 환경에 최적화 [^46]: @[03:41]~@[03:56] 프로덕션 적용과 오케스트레이션 툴 등장 [^47]: @[03:56]~@[04:05] 운영 자동화/오브젝트/IaC 추상화로 Kubernetes가 주도 [^48]: @[04:05]~@[04:18] 복잡성으로 프로덕션 적용 어려움 [^49]: @[04:21]~@[04:30] 고객들이 겪는 어려움 공유 [^50]: @[04:30]~@[05:17] CNCF 설문 결과 설명 [^51]: @[04:30]~@[04:43] 설문 소개 [^52]: @[04:43]~@[05:01] 상위 어려움 나열 [^53]: @[04:43] [^54]: @[04:52] [^55]: @[04:52] [^56]: @[04:52]~@[04:58] [^57]: @[04:52]~@[04:58] [^58]: @[04:52]~@[04:58] [^59]: @[04:58] [^60]: @[05:01] [^61]: @[05:01]~@[05:17] DevOps 환경 구축 난이도까지 포함 [^62]: @[05:25]~@[05:38] ‘삼중고’ [^63]: @[05:25] Kubernetes 도입/고민 [^64]: @[05:25] DevOps 환경 구축 [^65]: @[05:25] 인프라 구성 고민 [^66]: @[05:25]~@[05:38] 빠른 변화에 집중 못함 [^67]: @[04:37]~@[05:38] 설문 항목과 삼중고 해석 [^68]: @[05:46]~@[06:03] 세션의 3가지 주제 [^69]: @[05:38]~@[06:03] [^70]: @[05:46] [^71]: @[05:57]~@[06:03] [^72]: @[05:57]~@[06:03] [^73]: @[06:07] 이후 순서 전개 [^74]: @[06:07]~@[07:44] EKS로 클러스터 구성/관리 [^75]: @[06:14]~@[06:54] EKS의 CNCF 인증/표준 호환/플레인 쿠버네티스 [^76]: @[06:14]~@[06:27] EKS 소개 [^77]: @[06:27]~@[06:32] CNCF 인증과 생태계 툴링 [^78]: @[06:38]~@[06:46] “임의로 수정하지 않은” [^79]: @[06:46]~@[06:54] 호환/마이그레이션 [^80]: @[07:00]~@[07:23] 운영 작업 나열 [^81]: @[07:00] [^82]: @[07:03] [^83]: @[07:03] [^84]: @[07:03]~@[07:12] [^85]: @[07:12]~@[07:16] [^86]: @[07:16]~@[07:23] [^87]: @[07:23]~@[07:34] 전문지식/수작업, 거의 모든 영역 전문가 필요 [^88]: @[07:38]~@[07:44] AWS가 관리/업그레이드/고가용성 [^89]: @[07:55]~@[09:28] 컨트롤 플레인 관리 [^90]: @[07:55]~@[08:06] “사이트 원” [^91]: @[07:55] 맥락 [^92]: @[08:06]~@[08:26] 2018 이전부터 지원 [^93]: @[08:15] [^94]: @[08:20]~@[08:26] [^95]: @[08:32]~@[08:43] 2018 컨트롤 플레인 관리 제공 [^96]: @[08:43]~@[09:21] HA 아키텍처 설명 [^97]: @[08:49] [^98]: @[08:49]~@[08:59] [^99]: @[08:59] [^100]: @[08:59]~@[09:05] [^101]: @[09:05] [^102]: @[09:05]~@[09:13] [^103]: @[09:13]~@[09:21] [^104]: @[09:21]~@[09:28] [^105]: @[09:28]~@[11:32] 데이터 플레인 관리 확장 [^106]: @[09:28]~@[09:42] 데이터 플레인 직접 관리 불편 [^107]: @[09:42]~@[10:01] 피드백 기반 출시, 명칭 언급 [^108]: @[10:01]~@[10:50] 관리형 워커 노드 그룹 설명 [^109]: @[10:01]~@[10:05] [^110]: @[10:05]~@[10:20] [^111]: @[10:05]~@[10:14] [^112]: @[10:14]~@[10:20] [^113]: @[10:20]~@[10:26] [^114]: @[10:26]~@[10:35] [^115]: @[10:35]~@[10:43] [^116]: @[10:43]~@[10:50] [^117]: @[10:50]~@[11:01] [^118]: @[11:01]~@[11:22] 프로비저닝 도구들 [^119]: @[11:01] [^120]: @[11:05] [^121]: @[11:10] [^122]: @[11:10]~@[11:17] [^123]: @[11:17] [^124]: @[11:25]~@[11:32] 태그 자동, 레이블 적용/업데이트 [^125]: @[10:26]~@[10:35] 드레인/지속 사용 + @[10:14]~@[10:20] 단일 조작 [^126]: @[11:43]~@[13:17] Fargate for EKS [^127]: @[11:43]~@[11:55] “완전 관리형 … 제공” [^128]: @[11:49]~@[12:06] 서버리스로 컨테이너 실행, 배포/관리/확장 [^129]: @[12:06]~@[12:14] 파드 격리/보안 [^130]: @[12:14]~@[12:20] 애플리케이션 구축 집중 [^131]: @[12:20]~@[12:33] 고객 데이터 플레인 관리 불필요 [^132]: @[12:38]~@[12:54] 사용자 경험 변화 [^133]: @[12:38] [^134]: @[12:38]~@[12:49] [^135]: @[12:49]~@[12:54] [^136]: @[12:54]~@[13:00] [^137]: @[13:00]~@[13:17] 제약 사항 [^138]: @[13:00] [^139]: @[13:00]~@[13:05] [^140]: @[13:05]~@[13:11] [^141]: @[13:11]~@[13:17] [^142]: @[13:19]~@[14:20] 옵션 조합 및 샘플 아키텍처 [^143]: @[13:19]~@[13:27] [^144]: @[13:27]~@[13:56] [^145]: @[13:27]~@[13:33] [^146]: @[13:33]~@[13:40] [^147]: @[13:40]~@[13:56] [^148]: @[13:56]~@[14:14] 샘플 아키텍처 [^149]: @[14:01]~@[14:05] [^150]: @[14:05]~@[14:14] [^151]: @[14:14]~@[14:19] [^152]: @[14:23]~@[15:48] CI/CD로 전환 [^153]: @[14:23] [^154]: @[14:33]~@[14:54] [^155]: @[14:57]~@[15:02] [^156]: @[14:57]~@[15:02] [^157]: @[15:02]~@[15:11] [^158]: @[15:12]~@[15:20] [^159]: @[15:20]~@[15:48] CodePipeline으로 EKS 배포 흐름 [^160]: @[15:20]~@[15:25] [^161]: @[15:27]~@[15:48] [^162]: @[15:27] [^163]: @[15:27]~@[15:37] [^164]: @[15:37]~@[15:43] [^165]: @[15:43]~@[15:48] [^166]: @[15:48]~@[15:52] “좀 더 상세히” [^167]: @[15:52]~@[16:17] CodePipeline 상세 [^168]: @[15:52]~@[15:54] [^169]: @[16:02]~@[16:08] [^170]: @[16:08]~@[16:13] [^171]: @[16:17]~@[16:56] CodeCommit 상세 [^172]: @[16:17]~@[16:25] [^173]: @[16:25]~@[16:33] [^174]: @[16:25]~@[16:31] [^175]: @[16:31] [^176]: @[16:33]~@[16:38] [^177]: @[16:38]~@[16:50] [^178]: @[16:50]~@[16:56] [^179]: @[16:59]~@[17:45] CodeBuild 상세 [^180]: @[17:02]~@[17:08] [^181]: @[17:08]~@[17:33] [^182]: @[17:08]~@[17:14] [^183]: @[17:14]~@[17:23] [^184]: @[17:23]~@[17:28] [^185]: @[17:28]~@[17:33] [^186]: @[17:33]~@[17:38] [^187]: @[17:38]~@[17:45] [^188]: @[17:45]~@[18:43] ECR 상세 [^189]: @[17:50]~@[17:59] [^190]: @[17:45]~@[17:50] [^191]: @[17:59]~@[18:43] [^192]: @[17:59]~@[18:05] [^193]: @[18:05]~@[18:11] [^194]: @[18:11]~@[18:16] [^195]: @[18:18]~@[18:24] [^196]: @[18:24]~@[18:29] [^197]: @[18:29] [^198]: @[18:32]~@[18:37] [^199]: @[18:37]~@[18:43] [^200]: @[18:32]~@[18:43] immutable tag + scanning 언급 [^201]: @[18:47]~@[19:51] CI/CD 결합 아키텍처 예 [^202]: @[18:47]~@[18:55] [^203]: @[18:55]~@[19:07] [^204]: @[19:07]~@[19:09] [^205]: @[19:09]~@[19:20] [^206]: @[19:20]~@[19:31] [^207]: @[19:31]~@[19:37] [^208]: @[19:37]~@[19:51] [^209]: @[19:51]~@[19:56] [^210]: @[19:56]~@[20:43] 모니터링 필요성 [^211]: @[20:04]~@[20:13] [^212]: @[20:13]~@[20:17] [^213]: @[20:17]~@[20:33] [^214]: @[20:33]~@[20:43] [^215]: @[20:41] [^216]: @[20:41] [^217]: @[20:41] [^218]: @[20:43]~@[20:56] [^219]: @[20:50]~@[20:56] [^220]: @[20:56] [^221]: @[21:05]~@[21:25] [^222]: @[21:25]~@[21:37] [^223]: @[21:37]~@[22:07] Container Insights 설명 [^224]: @[21:37]~@[21:43] [^225]: @[21:43]~@[21:52] [^226]: @[21:52]~@[22:07] [^227]: @[21:52]~@[21:58] [^228]: @[21:58]~@[22:07] [^229]: @[22:07]~@[22:19] [^230]: @[22:07]~@[22:19] 메타데이터 결합 언급 [^231]: @[22:19]~@[23:34] Logs Insights 및 로그 수집 [^232]: @[22:19]~@[22:30] [^233]: @[22:30]~@[22:45] [^234]: @[22:30] [^235]: @[22:30] [^236]: @[22:30]~@[22:45] [^237]: @[22:45]~@[22:53] [^238]: @[22:53]~@[23:00] [^239]: @[23:00]~@[23:13] [^240]: @[23:13]~@[23:34] [^241]: @[23:13]~@[23:20] [^242]: @[23:20]~@[23:28] [^243]: @[23:28]~@[23:34] [^244]: @[23:34]~@[24:26] X-Ray 설명 [^245]: @[23:34]~@[23:40] [^246]: @[23:40]~@[24:03] [^247]: @[24:03]~@[24:13] [^248]: @[24:13]~@[24:26] [^249]: @[24:26]~@[25:14] 모니터링 결합 효과 및 ‘대부분 관리형’ [^250]: @[24:26]~@[24:52] [^251]: @[24:36]~@[24:46] [^252]: @[24:36]~@[24:46] [^253]: @[24:46]~@[24:52] [^254]: @[24:54]~@[25:06] [^255]: @[25:06]~@[25:14] [^256]: @[25:29]~@[27:05] 키 테이크어웨이 및 AWS 선호 이유 [^257]: @[25:14]~@[25:31] [^258]: @[25:31]~@[25:35] [^259]: @[25:35]~@[25:49] [^260]: @[25:49]~@[25:53] [^261]: @[25:53]~@[25:59] [^262]: @[25:59]~@[26:10] [^263]: @[26:10]~@[26:22] [^264]: @[26:22]~@[26:37] [^265]: @[26:22]~@[26:37] [^266]: @[26:37]~@[26:54] [^267]: @[26:54]~@[26:59] [^268]: @[27:05]~@[27:43] 자료/워크샵/문의/피드백 안내 [^269]: @[00:49]~@[27:05] 전체 논지 종합 [^270]: @[01:59]~@[02:21] DevOps 범위 확장 + @[20:04]~@[20:43] 관측의 중요성 [^271]: @[03:56]~@[04:18] Kubernetes의 추상화/자동화 vs 복잡성 [^272]: @[07:55]~@[12:33] 컨트롤 플레인→관리형 노드→Fargate [^273]: @[15:20]~@[15:48] 파이프라인 흐름 + @[19:20]~@[19:51] desired state 전파 설명 [^274]: @[20:13]~@[20:43] 마이크로서비스로 인한 추적 난이도 + 3요소 [^275]: @[13:19]~@[13:56] 옵션 조합(관리형/자가관리/Fargate 혼용) [^276]: @[18:32]~@[18:43] immutable tags + scanning [^277]: @[20:33]~@[24:13] CloudWatch(메트릭/로그) + X-Ray(트레이스) [^278]: @[01:45]~@[26:10] 용어들이 반복적으로 등장하는 구간 전반 [^279]: @[01:51]~@[02:21] DevOps 범위 정의 [^280]: @[02:23]~@[02:49] IaC 정의/난이도 [^281]: @[08:32]~@[09:13] 컨트롤 플레인과 구성요소(API Server/etcd) 및 HA [^282]: @[09:28]~@[12:33] 데이터 플레인 관리 진화 [^283]: @[10:01]~@[11:01] 관리형 노드 그룹 동작 [^284]: @[11:43]~@[13:17] Fargate 특징/제약 [^285]: @[14:57]~@[15:48] 릴리즈 4단계와 파이프라인 구성 [^286]: @[21:43]~@[22:07] Container Insights 수집/자동 지표 [^287]: @[22:19]~@[23:34] Logs Insights 분석/쿼리 [^288]: @[23:40]~@[24:13] X-Ray 엔드투엔드 뷰/서비스 맵 [^289]: 사용자 제공 메타데이터(제목/채널/길이/링크) [^290]: 사용자 제공 제목 [^291]: 사용자 제공 채널 [^292]: 사용자 제공 길이 [^293]: 사용자 제공 링크