프로젝트에서 보기 →

Amazon EKS의 Devops 환경 고도화를 위한 Gitops 그리고 Progressive Delivery 소개 [AWS Builders Standard Edition]

태그
기술 AWS데브옵스
시작일
종료일
수정일

https://www.youtube.com/watch?v=6uD2YIHETHQ

description.md

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

[? 질문] 프로덕션 환경에서 배포가 자주 실패하고(“내 컴퓨터/개발/QA에서는 되는데 운영에서만 문제”) 개발팀·운영팀이 서로 비난하며, 설정 유실 같은 사고로 시스템이 통제불능이 되는 문제를 어떻게 줄일 수 있는가[^2]
[= 답] GitOps는 “운영의 의도된 상태(Desired State)를 Git에 단일 진실 공급원(Single Source of Truth)으로 선언하고”, 운영 변경을 코드 기반 PR(풀리퀘스트)로만 수행하며, 클러스터에서 **관찰된 상태와 의도된 상태의 차이를 자동으로 수렴(reconcile/sync)**시키는 방식으로 사람의 수작업 변경을 차단해 안정성과 감사 가능성을 높인다.[^3]

[? 질문] GitOps로 “원하는 상태를 반영하는 자동 배포”는 가능해졌는데, 블루/그린·카나리 같은 고급 배포 전략(트래픽 분산, 지표 기반 의사결정, 자동 롤백)을 사람 손을 덜고 더 안전하게 자동화하려면 무엇이 필요한가[^4]
[= 답] Progressive Delivery는 배포를 “제어되고 점진적으로” 수행하면서 자동화된 메트릭 분석을 결합해 프로모션(승격)과 롤백을 자동 유도하는 방법론이며, 이를 위해 Flagger(Flux 생태계)나 Argo Rollouts(Argo 생태계) 같은 컨트롤러/CRD 기반 도구를 사용한다.[^5]

[? 질문] AWS(EKS) 환경에서 GitOps와 Progressive Delivery를 어떤 도구 조합으로 구현할 수 있는가[^6]
[= 답] GitOps CD 도구로는 Flux CD 또는 Argo CD를, Progressive Delivery 도구로는 Flagger 또는 Argo Rollouts를 사용하며, 트래픽 라우팅은 AWS Load Balancer Controller(ALB Ingress) 또는 AWS App Mesh(서비스 메시) 등과 연동해 구현할 수 있다.[^7]

2. 큰 그림[^1]

이 세션은 Amazon EKS 기반 DevOps 환경을 “더 안정적이고 효율적으로” 만들기 위한 두 축, GitOps와 Progressive Delivery를 소개하고, AWS에서 사용할 수 있는 구현 옵션(오픈소스 도구와 AWS 서비스 연계) 및 데모(Argo CD + Argo Rollouts)를 통해 실제 동작을 보여준다.[^8] 또한 전통적 CI/CD 자동화가 애플리케이션에 집중되어 왔던 흐름을 되짚으며, 운영 변경(라이브 시스템 변경)이 장애의 큰 비중을 차지한다는 문제의식을 바탕으로 “운영을 Git과 코드로 통제”하는 접근을 강조한다.[^9]

  • GitOps의 핵심은 Git을 단일 진실 공급원으로 삼아 운영의 Desired State를 선언하고, PR 기반 변경과 자동 동기화를 통해 사람의 수작업 변경을 차단하는 것이다.[^3]
  • GitOps 도구(Flux CD, Argo CD)는 형상(Git)과 클러스터 상태 차이를 감지하고 이를 자동/수동 정책에 따라 Sync하여 일관성을 유지하며, 감사/롤백/코드리뷰 등 Git의 장점을 운영에 가져온다.[^10]
  • Progressive Delivery는 배포 전략(카나리/블루그린/AB/미러링)을 트래픽 라우팅 + 메트릭 분석 + 자동 승격/롤백으로 자동화하는 개념이며, Flagger/Argo Rollouts가 이를 CRD/컨트롤러로 제공한다.[^5]

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

3.1 세션 구성(아젠다): GitOps → Progressive Delivery → 데모[^1]

📸 0:01

발표자는 컨테이너 주제 세 번째 세션으로 “GitOps와 Progressive Delivery”를 다루며, 전체 아젠다를 3단으로 제시한다.[^1]

  1. GitOps가 무엇인지, 왜 써야 하는지, AWS에서 가능한 GitOps 옵션은 무엇인지[^1]
  2. Progressive Delivery 개념과 AWS에서 가능한 옵션[^1]
  3. 마지막으로 데모로 마무리[^1]

이 구성은 “개념(문제의식) → 원리(정의/구성요소) → 도구(Flux/Argo) → 진화 개념(Progressive Delivery) → 도구(Flagger/Rollouts) → AWS 연동 → 실제 시연”의 흐름으로 전개된다.[^1]

3.2 프로덕션 배포에서 흔히 겪는 문제: 실패, 환경 차이, 책임 공방, 설정 유실[^2]

📸 1:10

발표자는 GitOps 설명에 앞서, 실제 프로덕션 운영에서 반복되는 “배포/변경” 문제를 사례처럼 나열한다.[^2]

3.2.1 배포 실패는 빈번하고, 프로덕션 배포는 복잡하다[^2]

  • “운영 배포가 방금 실패했습니다”라는 상황을 제시하며, 프로덕션 환경의 배포는 매우 복잡하고 어렵고, 장애가 빈번하게 발생한다고 말한다.[^2]

3.2.2 ‘내 컴퓨터/개발/QA에서는 됐는데 운영에서만 문제’라는 괴리[^2]

  • 흔한 경험으로 “내 컴퓨터에서는 동작했는데”, “개발/QA에서는 잘 되는데”, “프로덕션에서는 차이가 나 버렸다”를 제시한다.[^2]
  • 이는 동일 코드라도 환경 설정/인프라/네트워크/데이터 조건 등이 달라져 운영에서만 문제가 발생할 수 있음을 암시한다.[^2]

3.2.3 장애 발생 시 개발팀·운영팀 간 비난/추궁으로 문제 확대[^2]

문제가 생기면 “서비스에 갑작스럽게 문제가 생겼다” → “개발팀과 운영팀이 서로를 비난하기 시작”이라는 장면을 묘사한다.[^2]

  • 운영팀의 의심: “혹시 누가 코드로 바꿨어? 언제 뭘 바꿨어?”[^2]
  • 개발팀의 의심: “운영팀이 배포로 작업한 거 아냐?”, “네트워크 변경된 거 아냐?”, “DB 인덱스 건드린 거 아냐?”[^2]
  • 이런 상호 비난이 “문제를 더 키우는 경우도 있다”고 말한다.[^2]

3.2.4 수작업 실수로 서버 설정이 날아가 복구가 어려운 문제[^2]

또 다른 문제로 “배포 작업자의 실수로 서버 설정이 다 날아가 버렸다”를 제시한다.[^2]

  • 담당자는 “우리 서버 환경 문서 다 가지고 있지?”라고 묻지만, 문서화가 잘 되어 있지 않다면 서버 복구가 매우 어렵다고 지적한다.[^2]

3.2.5 결과: 시스템이 ‘통제 불능’이 되는 경험은 누구나 겪는다[^2]

발표자는 이런 문제들로 “갑작스럽게 시스템이 통제 불능이 되는 상황”을 강조하며, 프로덕션을 운영해본 사람이라면 한 번쯤 겪는 일이라고 말한다.[^2]

[!IMPORTANT] 라이브 시스템 변경이 장애의 큰 비중
발표자는 “SRE는 가동 중단의 약 70%가 라이브 시스템의 변경으로 인한 것”을 발견했다고 언급하며, ‘Site Reliability Engineering’ 책 인용처럼 라이브 변경이 운영에서 가장 어렵고 중요한 문제라고 연결한다.[^9]

3.3 GitOps 등장 배경과 정의: 운영을 Git과 코드로 통제하는 방법론[^3]

📸 3:18

3.3.1 GitOps는 무엇인가[^3]

발표자는 GitOps를 “한 문장”으로 다음처럼 정의한다.[^3]

  • [= GitOps는 Git(기술)을 사용하는 운영 방법론]
    즉, Git을 중심에 둔 운영 패러다임이며, 단순 도구가 아니라 운영 방법론임을 강조한다.[^3]

3.3.2 GitOps의 구성 요소(특징) 3가지[^3]

발표자는 GitOps의 “취할(채택할) 기술들”로 3가지를 열거한다.[^3]

  1. Git 저장소 = Desired State를 표현하는 Single Source of Truth[^3]

    • 어떤 시스템의 **의도된 상태(Desired State)**를 Git에 기록하고, Git을 “단 하나의 진실 공급원”으로 둔다.[^3]

  2. 운영 환경의 의도된 모든 작업은 **코드/PR(풀리퀘스트)**로 수행[^3]

    • 운영 변경은 사람의 콘솔 클릭/수작업이 아니라, 코드 변경과 PR 프로세스로 진행된다는 뜻이다.[^3]

  3. 운영 환경에서 Desired State(의도된 상태)와 Observed State(관찰된 상태)의 차이는 동기화 컴포넌트가 자동 수렴[^3]

    • 운영 환경에 배포된 실제 상태(Observed)와 Git에 있는 선언(Desired)이 다르면, 이를 자동으로 reconcile/sync하여 일치시키는 컴포넌트가 존재한다.[^3]

3.3.3 궁극적 목적: 수작업 운영 변경을 완전히 차단[^3]

위 특징들의 목적은 한 문장으로 “사람이 수작업으로 운영 환경을 변경하는 것을 완전히 차단”하겠다는 것이라고 설명한다.[^3]
이는 앞에서 제시한 책임 공방, 문서 부재, 설정 유실 같은 문제를 구조적으로 줄이려는 의도다.[^2][^3]

3.4 전통적 소프트웨어 개발 흐름과 CI/CD의 발전, 그리고 인프라 관리의 ‘수작업’ 문제[^10]

📸 4:18

3.4.1 전통적으로 개발/운영의 3축: SCM(형상) + CI + CD[^10]

발표자는 “전통적으로 애플리케이션 개발에서 가장 큰 축”으로 다음을 든다.[^10]

  • 코드를 변경하기 위한 형상관리(SCM)
  • 빌드/테스트 자동화를 위한 CI 도구
  • 새 버전 배포를 위한 CD 도구[^10]

3.4.2 문제 해결을 위해 자동화(CI/CD)로 발전해 왔다[^10]

앞서 언급한 배포 실패/실수 문제를 줄이기 위해, CI/CD로 과정을 자동화하고 사람의 실수를 줄이는 방향으로 발전해 왔다고 말한다.[^10]

  • 애플리케이션 코드는 CI로 자동화, 컨테이너/아티팩트 제작과 배포도 익숙해졌고 “잘하고 있다”고 평가한다.[^10]

3.4.3 그러나 인프라 관점에서는 여전히 수작업이 흔했다[^10]

온프레미스 경험을 돌아보면, 서버/인프라 관리가 “거의 수작업에 가까운 경우가 많았다”고 지적한다.[^10]

  • 운영자가 직접 반영하거나
  • 이미 만들어진 서버에 계속 패치를 하거나
  • 운영자가 수작업으로 서버를 운영하는 모습이 흔했다는 것이다.[^10]

3.4.4 인프라 자동화를 위해 IaC가 발전: Terraform/CloudFormation/CDK[^10]

이 문제를 해결하기 위해 **IaC(Infrastructure as Code)**가 발전해 왔다고 설명한다.[^10]

  • Terraform
  • AWS CloudFormation
  • AWS CDK
    등을 통해 “예상할 수 있는 형태로” 인프라를 자동 구축하도록 발전했다는 요지다.[^10]

3.4.5 GitOps는 애플리케이션뿐 아니라 인프라에도 적용되는 이점[^11]

발표자는 GitOps가 “어플리케이션에 국한된 이야기만이 아니라는 점”을 강조한다.[^11]
CloudFormation/CDK 같은 IaC도 형상(Git) 기반으로 관리하고, 파이프라인을 통해 반영함으로써 인프라 역시 GitOps적 관리가 가능해진다는 점을 장점으로 든다.[^11]

3.5 AWS에서의 GitOps 옵션(인프라와 애플리케이션) 개요[^12]

📸 10:48

3.5.1 인프라 GitOps: CloudFormation/CDK + CodeCommit/CodePipeline[^12]

발표자는 AWS 인프라 측면에서 다음 흐름을 제시한다.[^12]

  • CloudFormation은 잘 알려진 AWS IaC 도구[^12]
  • 개발자/운영자가 IaC를 더 쉽게 작성하도록 프로그래밍 언어 기반의 CDK를 제공[^12]
  • CDK/CloudFormation으로 인프라를 정의하고
  • 이를 CodeCommit 같은 형상 저장소에 저장[^12]
  • 변경을 CodePipeline으로 반영하면
  • 애플리케이션이 CI/CD로 배포되듯 인프라도 형상 기반으로 관리할 수 있다는 설명이다.[^12]

발표자는 다만, 오늘 세션에서는 인프라 파트를 깊게 다루지 않고 “애플리케이션 GitOps와 Progressive Delivery”에 집중한다고 말하며, 별도 자료(AWS 온라인/다시보기 등) 참고를 권한다.[^13]

3.5.2 애플리케이션 GitOps: Kubernetes 매니페스트 동기화 도구(Flux/Argo CD)[^14]

EKS 또는 AWS 위에 구축된 Kubernetes 클러스터의 매니페스트를 Git과 동기화(reconcile)하는 도구로 Flux CD와 Argo CD를 언급한다.[^14]
이 도구들은 “관찰된 상태와 원하는 상태를 수렴시키는 자동화 툴”이며 Kubernetes 채택 사례에서 널리 사용된다고 한다.[^14]

3.6 왜 GitOps가 배포 문제 해결의 ‘베스트 프랙티스’인가: Git(버전관리)의 장점을 운영에 이식[^15]

📸 7:14

발표자는 GitOps가 복잡한 배포 문제를 해결하는 베스트 프랙티스로 평가되는 이유를 “Git 버전 제어 시스템의 기능”에 근거해 설명한다.[^15]

3.6.1 친숙한 Git 워크플로로 생산성 향상[^15]

  • 개발자/운영자에게 Git은 가장 보편화된 형상 도구이므로, 별도 도구 대신 Git 기반 워크플로로 협업하면 생산성이 높아진다고 말한다.[^15]

3.6.2 Git은 유일한 ‘단일 진실 공급원’이며, 변경 이력/감사가 가능[^16]

발표자는 Git이 “Single Source of Truth”이며, 모든 변경 기록을 남긴다고 강조한다.[^16]

  • 누가 무엇을 언제 왜 변경했는지 추적 가능[^16]
  • 감사 도구이자 보고 도구로도 활용된다는 주장[^16]

3.6.3 코드리뷰(PR) 강제로 휴먼 에러 감소, 변경 통제 강화[^17]

Git의 PR/코드리뷰 메커니즘을 개발/운영 프로세스에 결합하면 다음 효과가 있다고 한다.[^17]

  • 운영에 반영할 인프라/애플리케이션 코드의 휴먼 에러를 더 줄임[^17]
  • 개발팀·운영팀이 “코드 반영에 대한 신뢰성”을 얻음[^17]
  • 코드리뷰뿐 아니라 통합 테스트, 정적 분석 등을 PR 프로세스에 포함하면 더 강력한 통제가 된다고 말한다.[^17]

발표자는 “형상(Git)은 변경을 관리하기에 최적의 장소”라고 재강조한다.[^17]

3.6.4 일관성과 표준화에도 도움: 운영 변경 경로를 Git으로 단일화[^18]

어플리케이션과 인프라의 CI/CD 파이프라인이 모두 PR로만 작동하고, 운영자 작업 역시 Git으로 완전히 관리될 수 있어 조직 운영에 일관성과 표준화 측면에서 도움을 준다고 말한다.[^18]

3.6.5 롤백이 빠르고 정확해진다: 커밋/브랜치 되돌리기[^19]

Git의 롤백 메커니즘과 GitOps를 통합하면 배포 장애에 신속하고 정확하게 대응 가능하다고 설명한다.[^19]

  • 단순히 PR/커밋 또는 브랜치를 되돌리는 것만으로 배포 담당자가 해야 할 일이 끝날 수 있다고 말한다.[^19]
  • 단, 관계형 DB 변경을 포함한 복잡한 배포는 예외가 있을 수 있다고 덧붙인다.[^19]

3.7 GitOps CD 도구(1): Flux CD — 동기화(리컨실리에이션)로 Desired/Observed 수렴[^14]

📸 12:03

3.7.1 Flux CD 개요 및 기본 동작 원리[^14]

Flux CD는 Weaveworks가 개발한 오픈소스 GitOps 도구로 소개되며, “관찰된 상태(Observed)와 의도된 상태(Desired)의 차이”를 리컨실리에이션으로 메꾸는 컴포넌트를 Kubernetes 클러스터에 배포해 자동 반영하게 하는 방식으로 설명된다.[^14]

구조적으로는 다음 흐름이다.[^14]

  • 클러스터에 Flux CD 컴포넌트 설치
  • 컴포넌트가 특정 애플리케이션의 Git 리포지토리를 바라보도록 설정
  • Git에 있는 Desired State를 주기적으로/이벤트 기반으로 가져와
  • 클러스터에 자동 반영하여 Desired/Observed를 일치시키도록 동작[^14]

발표자는 아키텍처 중앙의 Flux 관련 컴포넌트가 “형상 정보를 계속 가져와 자동 배포 역할”을 한다고 이해하면 된다고 말한다.[^14]

3.7.2 Flux v1 vs v2: 단일 컴포넌트에서 기능별 컨트롤러 집합체로 분리[^20]

발표자는 Flux v2를 설명하며 v1과 차이를 “아키텍처 분리”로 강조한다.[^20]

  • v1에서는 Flux의 단일/소수 컴포넌트가 많은 일을 했다면
  • v2에서는 기능들이 분리되어 “특화된 컨트롤러들의 집합체” 형태가 되었다는 설명이다.[^20]
    예시로:
    • 소스 변경 확인하는 소스 컨트롤러
    • Helm 차트 변경 관리하는 헬름 컨트롤러
    • Kustomize 변경 관리하는 커스터마이즈 컨트롤러
      등이 분리되어 있다고 언급한다.[^20]

이 분리 구조의 효과로, 생태계 변화나 새로운 형상/패키지 추가 시 더 유연하고 빠르게 대응할 수 있다고 말한다.[^20]

3.7.3 Flux 컴포넌트는 Kubernetes 확장(컨트롤러 + API/CRD)의 집합[^21]

발표자는 Flux 컴포넌트를 “Kubernetes 확장”으로 규정한다.[^21]

  • 컨트롤러와 API 집합체이며
  • API는 Kubernetes **Custom Resource Definition(CRD)**로 구성
  • 클러스터 사용자 또는 자동화 도구가 이러한 리소스를 만들거나 업데이트할 수 있다고 설명한다.[^21]

이 구조 덕분에 Flux를 손쉽게 확장하거나, 특정 시대를 위한 동작을 독자적으로 커스터마이징 가능하다는 점을 “주목”하라고 한다.[^21]

3.7.4 AWS 서비스와 Flux를 조합한 흐름: CI 파이프라인과 독립적 연동[^22]

발표자는 AWS 서비스와 Flux를 함께 사용하는 아키텍처 예를 든다.[^22]

  • 상단: 기존에 쓰는 CodePipeline 등 CI 파이프라인[^22]
  • 하단: Flux CD를 통해 변경된 이미지/매니페스트를 클러스터에 반영하는 GitOps CD 흐름[^22]

GitOps는 CD(배포)를 CI 파이프라인과 “독립적으로” 구성할 수 있어 어떤 CI 환경과도 손쉽게 통합 가능하다는 점을 강조한다.[^22]

3.7.5 Flux 주요 기능들(트리거, 주기 동기화, 패키지 매니저, 외부 연동)[^23]

발표자는 Flux가 제공하는 다양한 피처로 다음을 언급한다.[^23]

  • 이벤트 트리거 방식 또는 주기적으로 Desired/Observed를 리컨실리에이션[^23]
  • Kustomize, Helm 같은 패키지 매니저 지원[^23]
  • GitHub 등 외부 시스템과 연동(알림/웹훅 등) 기능[^23]

3.7.6 Flux의 자동 이미지 업데이트 기능(레지스트리 감시 → 배포 + 매니페스트 갱신)[^24]

발표자는 Flux 사용 시 “장점으로 느꼈던” 구체 기능을 하나 공유한다.[^24]

  • Flux 컴포넌트가 이미지 레지스트리를 바라보도록 설정
  • 레지스트리에 새 이미지가 푸시되어 태그가 업데이트되면
  • Git의 YAML을 사람이 직접 고치지 않아도 Flux가 자동으로 새 버전 이미지를 클러스터에 배포[^24]
  • 동시에 Git에 기록된 Kubernetes 매니페스트의 이미지 버전도 자동 업데이트해주는 자동화 기능이 있다고 설명한다.[^24]

발표자는 “모든 배포에 적용하긴 어렵겠지만”, 이미지 변경이 빈번한 개발계 등에 적용하면 효율적일 수 있다고 말한다.[^24]

3.7.7 Flux는 UI가 없지만, CRD 기반 설정이므로 다른 워크플로 제공자와 조합 가능[^25]

Flux의 애플리케이션을 바라보는 설정이 Kubernetes CRD로 정의되기 때문에, “UI를 가진 다른 워크플로 프로바이더(예: GitHub Actions, Argo 등)”와 결합해 사용할 수 있다고 말한다.[^25]
즉, Flux 자체가 UI가 강하지 않아도 특정 기능이 필요할 때 다른 도구와 조합해 효율적으로 쓰는 길이 있다는 설명이다.[^25]

3.8 GitOps CD 도구(2): Argo CD — 완성도 높은 Web UI와 멀티 기능[^26]

📸 18:30

3.8.1 Argo CD 개요: Flux와 유사한 GitOps 기능 + 강점은 Web UI 완성도[^26]

발표자는 Argo CD를 Flux와 “굉장히 유사한 기능”을 가진 오픈소스 프로젝트로 소개한다.[^26]
차이점(장점)으로 다음을 든다.[^26]

  • Flux는(당시 맥락에서) UI가 부족한 반면
  • Argo CD는 오픈소스임에도 완성도가 높은 Web UI를 제공
  • 사용자가 더 손쉽게 수행할 수 있는 경험 제공이 큰 장점[^26]

3.8.2 Argo CD의 기본 동작: Git 변경 감지(웹훅/폴링) → Desired 적용[^27]

Argo CD는 설정에 따라 Kubernetes 매니페스트가 있는 Git 리포지토리를 바라보고, PR/변경이 일어나면 웹훅 등으로 전달받아 변경된 Desired State를 클러스터에 배포한다고 설명한다.[^27]

3.8.3 Argo CD 아키텍처 구성요소: API 서버, Repo 서버, App Controller, (UI용) Dex 등[^28]

발표자는 Argo CD가 개발 초기부터 “일종의 MS(마이크로서비스) 아키텍처”로 개발되어 유연한 구조를 가진다고 말한다.[^28] 그리고 구성요소를 다음처럼 설명한다.[^28]

  • Argo CD API Server: Web UI나 CLI에서 오는 요청을 처리하고 다른 도구와 연계[^28]
  • Repo Server: Git에서 Desired State를 가져와 싱크를 맞추기 위한 “임시 저장소” 같은 역할[^28]
  • Application Controller(App Controller): 애플리케이션 상태를 보고 Desired와의 차이를 맞추는(동기화) 역할[^28]
  • Dex Server 등: Web UI 사용 시 인증/연동(SSO 등) 관련 구성으로 언급[^28]

3.8.4 Argo CD 기능: 자동 배포, 패키지 매니저, 멀티클러스터, SSO, 멀티테넌시, 차이 시각화/동기화 정책[^29]

발표자는 Argo CD의 기능을 Flux와 크게 다르지 않다고 하면서도, 다음을 열거한다.[^29]

  • 자동화된 배포 기능[^29]
  • 다양한 패키지 매니저 지원[^29]
  • 멀티플 클러스터 배포 기능[^29]
  • SSO 연동[^29]
  • 멀티 테넌시 지원[^29]
  • 형상(Git)과 클러스터 상태의 차이를 자동 감지해 **시각화(visualization)**하고
  • 그 차이를 수동으로 sync할지 자동으로 할지 등 정책을 설정할 수 있음[^29]

3.9 Progressive Delivery: 점진적·제어된 배포 + 메트릭 분석 + 자동 승격/롤백[^5]

📸 21:48

3.9.1 정의: 위험을 줄이기 위한 점진적 업데이트 프로세스[^5]

발표자는 Progressive Delivery를 다음 요소들의 결합으로 정의한다.[^5]

  • 제어되고 점진적인 방식으로 제품 업데이트
  • 릴리즈 위험 감소
  • 일반적으로 자동화된 매트릭스(메트릭) 분석 결합
  • 업데이트의 자동화된 프로모션(승격)과 롤백을 유도하는 방법론[^5]

발표자는 이 정의를 “읽어드린 것”이라고 말하며, 이어서 자신이 생각하는 가장 큰 특징을 덧붙인다.[^5]

3.9.2 핵심 특징: 배포 전 과정의 ‘완전 자동화’ 지향[^30]

발표자는 Progressive Delivery의 가장 큰 특징을 “배포 전체 자동화”로 강조한다.[^30]

온프레미스에서 블루/그린 배포를 했다고 가정하면, 과거에는 다음을 사람이 수작업으로 수행해야 했다고 예시 든다.[^30]

  • Ingress 업데이트
  • Service 업데이트
  • 온프레미스 로드밸런서 설정 변경
  • NGINX 같은 구성 변경
    즉, 블루/그린이나 카나리 같은 전략을 달성하려면 사람이 손으로 여러 요소를 조작해야 했다.[^30]

Progressive Delivery는 이런 수작업을 메트릭 등 “여러 수단”을 기반으로 하여 배포의 의사결정까지 포함해 “완전 자동화”하겠다는 것으로 이해하면 된다고 말한다.[^30]

3.10 GitOps vs Progressive Delivery: 같은 것처럼 보이지만 범위와 목적이 다르다[^31]

📸 23:15

3.10.1 혼동의 원인: Flux/Argo 생태계에 Progressive Delivery 컴포넌트가 함께 존재[^31]

발표자는 GitOps와 Progressive Delivery를 구분할 필요가 있다고 말한다.[^31]
혼동이 생기는 이유로:

  • Flux를 만든 회사가 Progressive Delivery 도구도 만들었고(Flagger)
  • Argo 쪽도 Argo CD 외에 Argo Rollouts 같은 컴포넌트가 있으며
  • GitOps 컴포넌트와 Progressive Delivery 컴포넌트가 함께 사용되기도 해서
    같은 개념으로 이해하는 고객이 있다고 설명한다.[^31]

3.10.2 구분: GitOps는 ‘Git 기반 운영/배포 방법’, Progressive Delivery는 ‘고급 배포 전략 자동화’[^32]

발표자는 정확한 이해를 위해 다음처럼 구분한다.[^32]

  • GitOps: Git을 활용한 운영(특히 Kubernetes 디플로이먼트를 Git 기반으로 수행하는 운영 방법론) — Desired State를 클러스터에 반영하는 GitOps CD를 의미[^32]
  • Progressive Delivery: GitOps가 다루는 “Desired State 반영”을 포함할 수 있지만 거기서 더 나아가
    • 카나리 배포
    • 블루/그린 배포
    • 메트릭 기반 의사결정
      같은 “고급 기능”을 자동화 제공하는 개념[^32]

3.10.3 ‘Progressive Delivery’라고 부르려면 자동 의사결정(분석/롤백)이 핵심[^33]

발표자는 표를 통해 더 명확히 한다.[^33]

  • 메트릭 기반 의사결정, 롤백, 분석 같은 기능은
    • 서비스 그대로 사용하거나 Kubernetes 기본 매니페스트만으로는 “Manual”로 표기되는 반면[^33]
    • Flagger 같은 Progressive Delivery 컴포넌트에서는 “Automatic/Built-in”으로 제공된다고 설명한다.[^33]

그리고 만약 이런 의사결정(롤백/분석 등)을 사람이 반드시 수작업해야 한다면 “Progressive Delivery라고 말하기 어렵다”는 결론을 말한다.[^33]

3.11 Progressive Delivery 도구(1): Flagger — 트래픽 라우팅 + 메트릭 분석 + 알림 통합[^34]

📸 24:56

3.11.1 Flagger 개요: Flux 팀(Weaveworks) 기반 오픈소스 PD 컴포넌트[^34]

Flagger는 Weaveworks가 개발한 오픈소스 기반의 Progressive Delivery 컴포넌트로 소개된다.[^34]
앞서 정의한 Progressive Delivery 기능들을 제공한다고 한다.[^34]

3.11.2 배포 전략: 카나리, AB 테스트, 블루/그린, 미러링[^34]

Flagger는 트래픽 라우팅 컨트롤러/구성요소를 활용해 다음 전략을 구현한다고 설명한다.[^34]

  • 카나리
  • AB 테스팅
  • 블루/그린
  • 미러링[^34]

3.11.3 트래픽 라우팅 연동 대상: Service Mesh, Ingress(NGINX 등)[^34]

Flagger는 트래픽 라우팅을 위해 Service Mesh나 Ingress 컨트롤러 등을 사용한다고 언급한다.[^34] (발표 흐름상 NGINX 등도 예시로 나온다.)[^34]

3.11.4 릴리즈 분석(Analysis): Prometheus, Datadog, CloudWatch 등 메트릭 쿼리 기반[^34]

릴리즈 분석을 위해:

  • Prometheus 메트릭
  • Datadog
  • CloudWatch
    등을 쿼리(query)하여 메트릭 기반 배포를 할 수 있다고 설명한다.[^34]

3.11.5 알림(Notifications) 통합: Slack/MS Teams/Discord 등[^34]

배포 상태나 이벤트를 사용자에게 알리기 위해:

  • Slack
  • MS Teams
  • Discord
    등과 통합할 수 있다고 말한다.[^34]

3.11.6 CRD 기반: 코드로 설정하므로 다른 솔루션과 결합이 쉽다[^34]

Flagger 역시 Flux와 마찬가지로 CRD 기반으로 설정을 구성할 수 있고, 코드 기반 설정이므로 다른 GitOps/워크플로 솔루션과 쉽게 결합 가능하다고 설명한다.[^34]

3.11.7 Flux + Flagger의 역할 분담 예시[^35]

표 형태로 다음 역할 분담을 설명한다.[^35]

  • Flux(또는 GitOps CD): 애플리케이션 배포 관련 설정(Flagger 관련 오브젝트 포함)을 Git 형상 기반으로 클러스터에 반영[^35]
  • Flagger(PD 컴포넌트): 클러스터에 반영된 CRD 오브젝트를 바탕으로
    • Prometheus 메트릭 수집/분석
    • 카나리/블루그린 배포 자동화 수행
      역할을 한다고 정리한다.[^35]

3.12 Progressive Delivery 도구(2): Argo Rollouts — 트래픽 점진 전환 + KPI 기반 프로모션/롤백[^36]

📸 27:11

3.12.1 Argo Rollouts 개요: Kubernetes 컨트롤러 + CRD 집합체[^36]

Argo Rollouts는 Argo CD 생태계에서 제공하는 Progressive Delivery 도구로, Flagger와 마찬가지로 Kubernetes 컨트롤러 및 CRD 집합체라고 소개된다.[^36]
제공 기능으로:

  • 블루/그린
  • 카나리
  • 인크리멘탈(점진적) 배포
    같은 고급 배포 기능을 Kubernetes에 제공한다고 말한다.[^36]

3.12.2 서비스 메시/Ingress 연동으로 트래픽을 점진적으로 새 버전으로 이동[^36]

Argo Rollouts는 Ingress 컨트롤러 및 서비스 메시와 통합되어 “트래픽 라우팅” 개념으로 업데이트 중 트래픽을 점진적으로 새 버전으로 옮기는 기능을 제공한다고 설명한다.[^36]

3.12.3 메트릭 공급자 분석으로 KPI 확인 → 승격/롤백 자동 수행[^36]

Argo Rollouts는 다양한 공급자의 메트릭을 쿼리하고 분석해 주요 KPI를 확인하여 메트릭 기반 프로모션/롤백을 수행할 수 있는 도구라고 말한다.[^36]

3.12.4 사람 손이 아니라 ‘정의된 정책 + 메트릭’으로 의사결정하는 것의 의미[^37]

발표자는 Argo Rollouts 표/설명을 통해, 단순히 사람이 트래픽을 조절하는 것이 아니라 다음을 가능하게 해주는 도구라고 풀어 말한다.[^37]

  • CI를 통해 “트래픽을 어떻게 반영할지” 정의하거나[^37]
  • 배포 중 트래픽 전환 의사결정을 사람 수작업이 아니라 Prometheus 같은 메트릭 기반으로 수행할 수 있게 한다는 점[^37]

3.13 AWS에서 Progressive Delivery 구현 옵션: ALB Ingress 또는 App Mesh 중심 연동[^38]

📸 29:43

발표자는 “AWS에서 사용할 수 있는 배포 전략” 관점에서, 트래픽 라우팅 레이어에 따라 도구 선택/연동을 설명한다.[^38]

  • **AWS Load Balancer Controller(ALB Ingress)**를 사용 중이면

    • Ingress 기반 트래픽 제어와 Argo Rollouts(또는 관련 통합)를 통해 고급 배포 전략을 구현할 수 있다고 설명한다.[^38]

  • AWS App Mesh를 사용 중이면

    • Flagger를 통해 서비스 메시 기반의 고급 배포 전략을 달성할 수 있다고 말한다.[^38]

또한 특정 AWS 구성요소만이 아니라, 두 오픈소스 도구 모두 Kubernetes 생태계에서 매우 대중적인 구성요소들과 폭넓게 호환된다고 덧붙인다.[^39]

  • 가장 대중적인 Ingress 컨트롤러: NGINX 지원[^39]
  • 가장 대중적인 서비스 메시: Istio 지원[^39]
    → 따라서 “거의 모든 환경에서 Argo Rollouts나 Flagger로 Progressive Delivery 구현이 가능”하다는 결론이다.[^39]

3.14 데모(Argo CD): 앱 등록 → OutOfSync 확인 → 수동 Sync로 배포 반영[^40]

📸 31:00

발표자는 개념/아키텍처 설명만으로 감이 안 올 수 있어 “간단한 데모”를 준비했다고 말한다.[^40]

3.14.1 데모 도구로 Argo CD를 선택한 이유: UI가 있어 보여주기 좋다[^40]

데모 화면은 Argo CD App UI이며, “데모에서 보여드리기에는 UI가 있는 게 좋을 것 같아서 Argo CD를 준비했다”고 설명한다.[^40]

UI에서 보이는 메뉴로:

  • 형상이나 인증서를 관리하는 탭
  • 유저 정보 관리 탭
  • 디플로이먼트 확인 탭
    등이 있음을 언급한다.[^40]

3.14.2 애플리케이션 등록: UI도 가능하지만 CLI로 시연[^40]

발표자는 Argo CD에서 애플리케이션을 등록하는 과정을 설명한다.[^40]

  • 웹 UI로도 등록 가능하고, UI 버튼으로도 앱 등록 가능[^40]
  • 데모에서는 CLI로 앱 등록을 진행한다고 말한다.[^40]

3.14.3 CLI 명령의 의미: Git 리포/경로/대상 클러스터/네임스페이스 지정[^41]

발표자는 미리 준비한 CLI 명령을 실행하며, 명령이 뜻하는 바를 설명한다.[^41]

  • argocd CLI를 이용해 앱을 “생성(create)”한다는 의미[^41]
  • 앱(예: “pc… 데시노드제이스”로 들리는 이름)을 설정 관리 단위로 Argo CD에 등록[^41]
  • 필수 파라미터로:
    • Git 리포지토리 주소(Argo CD가 바라볼 형상 주소)[^41]
    • Kubernetes 매니페스트 파일 경로[^41]
    • 어느 Kubernetes 클러스터에 배포할지(기본 클러스터는 default 서비스로 표현)[^41]
    • 네임스페이스(데시노드제이스 네임스페이스에 등록)[^41]

실행 후 “정상적으로 등록되었다”는 메시지를 확인했다고 말한다.[^41]

3.14.4 등록 직후 상태: OutOfSync(오토 Sync 설정 안 함) → 수동 Sync 필요[^42]

UI로 돌아가 앱을 클릭해 상태를 확인한다.[^42]

  • 현재 상태가 OutOfSync로 표시됨[^42]
  • 이유: 앱 등록 시 “Automatic으로 Synchronize 하겠다”는 설정을 주지 않아, Git의 의도된 상태와 클러스터 상태가 달라서 그렇다고 설명한다.[^42]

따라서:

  • 수동 모드에서는 Sync 버튼을 눌러 Git의 최신 리비전(HEAD)을 반영해야 한다고 말한다.[^42]

3.14.5 수동 Sync 실행 결과: 배포 진행, 헬스 체크 성공 시 하트 표시[^43]

Sync 버튼을 누르면 동기화(배포)가 시작되고, 간단한 디플로이먼트라 금방 반영된다고 설명한다.[^43]

  • 정상 배포 및 헬스 체크 성공한 컴포넌트는 UI에서 “하트 표시”로 보인다고 언급한다.[^43]

3.15 데모(Argo Rollouts): Rollout CRD 스펙으로 카나리 트래픽 가중치 전환(5→10→20→50→80) + 중단(Suspend) + 최종 승격[^44]

📸 34:57

Argo CD 데모 직후, 발표자는 “바로 이어서 Progressive Delivery를 Argo Rollouts로 보여드리겠다”고 전환한다.[^44]

3.15.1 Rollout 오브젝트는 Deployment를 확장한 CRD로 이해하면 된다[^44]

발표자는 Rollout 오브젝트를 설명한다.[^44]

  • “기본적으로 Kubernetes에서 흔히 쓰는 Deployment 오브젝트를 확장해서 구성했다고 생각하면 된다”[^44]
  • 그래서 스펙에:
    • replicas 같은 필드가 보이고
    • 컨테이너 이미지 정보도 보인다고 말한다.[^44]

또한 Rollout에는 추가 커스터마이징 스펙이 있어:

  • 카나리 서비스(canary service) 정의[^44]
  • 스테이블 서비스(stable service) 정의[^44]
  • 트래픽 라우팅을 위한 ALB 관련 정보 입력 부분[^44] 등이 포함된다고 설명한다.[^44]

3.15.2 카나리 전략 정의(코드): 트래픽 가중치를 단계적으로 올린다[^45]

발표자는 Rollout 스펙 하단의 카나리 배포 정의를 보며, 코드로 다음을 정의해 두었다고 설명한다.[^45]

  • 트래픽 가중치를 1초(또는 일정 간격)마다 5 → 10 → 20 → 50 → 80처럼 새 버전(카나리 서비스)으로 전달하도록 설정[^45]
    (발표 중 간격 표현이 “1초마다”와 “10초마다/20초마다”가 섞여 들리지만, 핵심은 “단계적 가중치 증가”를 코드로 정의했다는 점을 시연한다.)[^45][^46]

그리고 데모 앱은 “들어온 트래픽을 그래픽적으로 표현”해, 전환 효과를 화면으로 확인할 수 있게 준비했다고 말한다.[^45]

3.15.3 새 버전 배포 시나리오: 옐로 → 레드로 Git(형상) 변경 후 Argo CD에서 Sync[^46]

발표자는 현재 버전(옐로)에서 새 버전(레드)으로 배포를 수행한다.[^46]

  • “레드 버전으로 형상의 코드를 바꾸고 Pull Request를 생각하고 바로 push”했다고 말한다.[^46]
  • 즉, Argo CD가 바라보는 상태(Git의 Desired)를 바꾼 것[^46]
  • 변경 후 Argo CD UI에서 OutOfSync 상태를 확인하고, Sync로 새 변경(레드 버전)을 배포한다.[^46]

3.15.4 배포 직후 클러스터 상태: 기존 파드 유지 + 카나리 파드 일부 생성[^46]

Sync 이후 화면에서:

  • 기존 버전 파드(옐로)는 그대로 있고[^46]
  • 새 카나리 버전 파드(레드)가 추가로 생성된 것을 확인한다고 말한다.[^46]

아직 트래픽이 100% 넘어가지 않았기 때문에 “하나의 파드만 생성”되어 있다고 설명한다.[^46]
(즉, 카나리 단계에서는 새 버전 리플리카를 제한적으로 두고 트래픽을 점진 전환한다는 시연 맥락이다.)[^46]

3.15.5 ALB에서 트래픽 분산 확인: 설정대로 일정 간격마다 비율이 이동[^47]

발표자는 ALB를 통해 트래픽이 분배되는 상황을 확인해보면, 설정해 놓은 대로 “20초마다” 트래픽이 기존 버전에서 카나리 버전으로 전달되는 것을 확인할 수 있다고 말한다.[^47]
즉, 트래픽 가중치 단계가 시간에 따라 변화하며, 그 변화가 실제 트래픽 분산에 반영되는 것을 보여준다.[^47]

3.15.6 운영 환경에 맞춰 조정 가능: 가중치 단계/간격, 메트릭 분석 기반 배포도 가능[^48]

발표자는 다시 Rollout 스펙을 보며 다음을 말한다.[^48]

  • (데모에서는) 가중치가 5/10/20/50/80로, 일정 간격마다 증가하도록 설정해 둠[^48]
  • 이런 값들은 실제 운영 환경에 맞춰 조정하면 된다[^48]
  • 추가로 “메트릭 기반 분석”을 넣어 Prometheus 메트릭에 기반한 배포를 하는 것도 가능하다고 언급한다.[^48]

3.15.7 Suspend(중단) 단계: 최종 전환을 멈추고 사람의 승인/결정을 기다리게 할 수 있다[^49]

발표자는 데모에서 마지막 단계에 “중단(suspend)” 설정을 해두었다고 말한다.[^49]

  • 이를 정의하면 최종 단계에서 더 이상 자동으로 전환이 진행되지 않고 “중단”되도록 할 수 있음[^49]
  • “트래픽이 안 흘러가는 게 아니라, 트래픽 전환이 멈춘다”는 취지로 설명한다.[^49]

화면에서:

  • 80%까지 카나리로 트래픽을 넘긴 뒤
  • 80에서 더 이상 새 버전으로 전환되지 않는 상태를 확인한다.[^50]

또한 Rollout 오브젝트의 상태가 “아직 패스 체크 완료가 안 됐다”처럼 보이는데, 이는 사용자가 suspend로 멈춰둔 상태이기 때문이라고 설명한다.[^50]

3.15.8 최종 승격: ‘완전히 트래픽 전환’ 버튼으로 새 버전 100% 전환, 구 버전 종료[^51]

발표자는 Argo Rollouts UI(또는 통합 UI)에서 “완전히 트래픽을 전환”하는 버튼을 눌러, 최종적으로 새 버전으로 트래픽을 넘긴다.[^51]

  • 새 버전으로 완전히 전환하기로 결정되면
    • 기존(오리지널) 버전은 termination(종료)되고[^51]
    • 새 버전이 정상 배포 상태로 남으며
    • 카나리 버전이 “스테이블 버전”이 되어 100% 트래픽을 받게 된다는 설명이다.[^51]

화면에서도 트래픽이 레드 버전으로 전달되는 것을 확인했다고 말하며 데모를 마무리한다.[^51]

3.16 마무리: 개념 이해와 설문 참여 요청[^52]

📸 40:27

발표자는 “오랜 시간 GitOps와 Progressive Delivery, 그리고 앞에서 (블루그린/카나리 등) 기본 개념을 들으시느라 수고 많았다”고 마무리 인사를 한다.[^52]
이후 세션 뒤에 제공되는 설문조사 참여를 요청하며, 자신을 AWS Korea의 솔루션 아키텍트 김광영이라고 다시 소개하고 감사 인사를 전한다.[^52]

4. 핵심 통찰[^1]

  1. [h 운영 장애의 상당수는 ‘라이브 시스템 변경’에서 온다] SRE 관점 인용(약 70%)을 통해, 운영 안정화를 위해서는 “변경 관리” 자체를 체계화·자동화해야 한다는 문제의식이 세션 전반을 관통한다.[^9]
  2. [h GitOps의 본질은 ‘Git을 단일 진실로 만들고, 변경 경로를 PR로 강제하는 것’이다] Git을 Desired State의 저장소로 두고, 수작업 변경을 차단하며, 동기화 컴포넌트가 차이를 자동 수렴하는 구조가 핵심이다.[^3]
  3. [h GitOps는 애플리케이션 배포만의 이야기가 아니라 인프라 운영까지 확장된다] CloudFormation/CDK를 Git과 파이프라인으로 운영함으로써 인프라도 형상 기반으로 관리할 수 있다는 점을 분명히 한다.[^12]
  4. [h Git의 장점(이력/감사/리뷰/롤백)이 운영의 신뢰성을 만든다] 누가/언제/왜/무엇을 바꿨는지 추적, 코드리뷰 강제, 커밋 되돌리기 기반 롤백 등은 “책임 공방”을 줄이고 대응을 빠르게 한다.[^16][^19]
  5. [h Progressive Delivery는 ‘점진적 배포’가 아니라 ‘의사결정까지 자동화’가 핵심이다] 트래픽 전환만이 아니라 메트릭 분석 기반 프로모션/롤백이 자동화되어야 Progressive Delivery로 부를 수 있다는 기준을 제시한다.[^33]
  6. [m GitOps와 Progressive Delivery는 상호보완 관계로 함께 쓰인다] GitOps가 “원하는 상태를 선언/반영”하는 기반이라면, Progressive Delivery는 그 위에 고급 배포 전략과 자동 의사결정을 얹는다.[^32]

실행 가능한 시사점(발표 내용 기반):

  • GitOps 도입 시, 운영 변경을 “콘솔/수작업”이 아니라 PR 경로로만 흐르게 만드는 정책 설계가 중요하다.[^3]
  • GitOps CD 도구 선택 시, 팀 역량/선호(UI 필요 여부 등)에 따라 Flux(유연한 컨트롤러 집합, 이미지 자동 업데이트 등) 또는 Argo CD(완성도 높은 UI, 시각화/정책 설정)를 비교한다.[^24][^26]
  • Progressive Delivery 도입 시, 트래픽 라우팅 레이어(ALB Ingress/App Mesh/Istio/NGINX 등)와 메트릭 백엔드(Prometheus/CloudWatch 등) 연동을 먼저 확정하고 Flagger/Argo Rollouts를 선택한다.[^38][^34]
  • 카나리에서는 “가중치 단계/간격”과 “중단(suspend) 지점”을 운영 리스크에 맞게 설계해, 자동화와 사람 승인 지점을 균형 있게 배치한다.[^48][^49]

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

GitOps: Git을 운영의 단일 진실 공급원으로 삼고, 운영 변경을 PR 기반 코드로만 수행하며, 클러스터의 관찰 상태와 Git의 의도 상태 차이를 자동 동기화 컴포넌트가 수렴시키는 운영 방법론.[^3]
Desired State(의도된 상태): Git에 선언된 “시스템이 이렇게 되어야 한다”는 목표 상태.[^3]
Observed State(관찰된 상태): 실제 클러스터/운영 환경에 현재 존재하는 상태.[^3]
Reconciliation/Sync(수렴/동기화): Desired와 Observed의 차이를 감지하고 자동으로 일치시키는 과정.[^3]
CRD(Custom Resource Definition): Kubernetes 기본 리소스(Deployment/Service 등) 외에 사용자 정의 리소스를 API로 확장하는 방식. Flux/Flagger/Argo Rollouts 등이 설정을 CRD로 제공한다고 설명한다.[^21]
Progressive Delivery: 배포를 제어된 점진 방식으로 수행하면서 메트릭 분석을 결합해 자동 승격/롤백을 유도하는 방법론. 블루그린/카나리/AB/미러링 등을 자동화한다.[^5]
Canary 배포: 새 버전에 일부 트래픽만 보내며 점진적으로 비율을 늘려 안정성을 확인하는 배포 전략(데모에서는 5→10→20→50→80 가중치 전환).[^45]
Blue/Green 배포: 두 환경(기존/신규)을 유지하고 트래픽을 전환하는 전략. 온프레미스에서는 Ingress/Service/LB 설정을 사람 손으로 바꿨다고 설명한다.[^30]

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

  • 제목: Amazon EKS의 Devops 환경 고도화를 위한 Gitops 그리고 Progressive Delivery 소개 (AWS Builders Standard Edition)[^1]
  • 채널: Amazon Web Services Korea[^1]
  • 길이: 40분 59초[^1]
  • 링크: https://www.youtube.com/watch?v=6uD2YIHETHQ[^1]

[^1]: @[00:01]~@[00:40] “컨테이너 세 번째 주제… GitOps 그리고 Progressive Delivery… 아젠다… GitOps가 무엇인지… Progressive Delivery… 데모” [^2]: @[01:10] “운영 배포가 방금 실패… 내 컴퓨터/개발/QA에서는… 프로덕션 차이… 개발팀/운영팀 비난… 설정 날아감… 문서화 없으면 복구 어려움… 통제 불능” [^3]: @[03:18]~@[04:02] “GitOps란… Git을 사용하는 운영 방법론… Git 저장소는 Desired State를 표현하는 Single Source of Truth… 모든 작업은 Pull Request… Desired/Observed 차이는 자동 수렴… 수작업 변경 차단” [^4]: @[21:41]~@[22:49] “다음은 Progressive Delivery… 블루그린/카나리 등을 사람이 수작업으로…” [^5]: @[21:48]~@[22:15] “Progressive Delivery는 제어되고 점진적… 자동화된 매트릭스 분석… 자동화된 프로모션과 롤백” [^6]: @[06:15]~@[07:04] “AWS에서… CloudFormation/CDK… CodePipeline… EKS 매니페스트 리컨실… Flux/Argo CD” [^7]: @[29:43]~@[30:27] “AWS에서… ALB… App Mesh… Argo Rollouts/Flagger… NGINX… Istio 지원” [^8]: @[00:28]~@[00:40] “왜 GitOps… AWS 옵션… Progressive Delivery… AWS 옵션… 데모” [^9]: @[02:47]~@[03:04] “SRE는 가동 중단의 약 70%가 라이브 시스템의 변경… 라이브 시스템 변경은 가장 어렵고 중요한 문제” [^10]: @[04:18]~@[05:38] “전통적 개발… SCM/CI/CD… 자동화… 애플리케이션은 잘… 인프라는 수작업… IaC 발전” [^11]: @[05:52]~@[06:00] “GitOps가 해결하는 문제는 애플리케이션에 국한되지 않음… 인프라도 형상 기반 IaC로 관리” [^12]: @[10:48]~@[11:32] “CloudFormation… CDK… CodeCommit… CodePipeline… 인프라를 형상 기반으로 반영” [^13]: @[11:32]~@[11:58] “오늘 세션에서는 자세히 다루지 않고… 더 상세는 다른 자료 참고” [^14]: @[12:03]~@[13:25] “Flux CD… Observed/Desired 차이를 reconciliation… 컴포넌트가 Git을 보고 자동 반영” [^15]: @[07:14]~@[08:04] “Git 워크플로… 개발자/운영자 친숙… 생산성” [^16]: @[08:04]~@[08:22] “Git은 Single Source of Truth… 모든 변경 기록… 누가/무엇/언제/왜… 감사/보고” [^17]: @[08:29]~@[09:04] “Pull Request… 코드 리뷰 강제… 휴먼 에러 감소… 변경 제어… 통합테스트/정적분석 통합” [^18]: @[09:20]~@[09:26] “일관성과 표준화… CI/CD가 PR로만 작동… 운영자 작업도 Git으로 관리” [^19]: @[09:45]~@[10:14] “Git 롤백… 커밋/브랜치 되돌리기… 신속/정확… DB 변경 포함 시 복잡” [^20]: @[13:30]~@[14:25] “Flux v2… 기능 분리… 소스 컨트롤러/헬름 컨트롤러/커스터마이즈 컨트롤러… 유연/빠른 대응” [^21]: @[14:36]~@[15:09] “컴포넌트는 Kubernetes 확장… 컨트롤러+API… CRD… 만들거나 업데이트 가능… 확장/커스터마이징” [^22]: @[15:26]~@[16:02] “AWS 서비스들과 Flux… 위에 CI(CodePipeline)… 아래 Flux CD… CD를 독립 구성… 어떤 CI와도 통합” [^23]: @[16:11]~@[16:42] “이벤트 트리거/주기적 리컨실… Kustomize/Helm… GitHub 연동/웹훅 등” [^24]: @[16:58]~@[17:22] “이미지 레지스트리 감시… 새 이미지 태그 업데이트 시 자동 배포… 매니페스트 이미지 버전도 자동 업데이트” [^25]: @[17:37]~@[18:12] “설정은 Kubernetes 방식(CRD)… UI 없는 Flux를 GitHub Actions/Argo 등과 조합 가능” [^26]: @[18:30]~@[19:07] “Argo CD… Flux와 유사… 장점은 완성도 높은 Web UI” [^27]: @[19:07]~@[19:36] “Argo CD가 Git을 바라보고… 변경 시 웹훅… Desired를 클러스터에 배포” [^28]: @[19:36]~@[20:27] “API 서버/Repo 서버/App Controller/Dex… MS 아키텍처… 임시 저장소… 요청 처리” [^29]: @[20:49]~@[21:32] “자동 배포… 패키지 매니저… 멀티클러스터… SSO… 멀티테넌시… 차이 시각화/수동·자동 sync 설정” [^30]: @[22:24]~@[23:06] “온프레미스 블루그린… Ingress/Service/LB/NGINX 설정을 사람 손으로… Progressive Delivery는 메트릭 등으로 완전 자동화” [^31]: @[23:15]~@[23:52] “GitOps와 Progressive Delivery 혼동… Flux 만든 회사가 PD도… Argo도 Rollouts… 같이 쓰이기도” [^32]: @[24:11]~@[24:33] “GitOps는 Git 기반 운영/배포… Progressive Delivery는 카나리/블루그린/메트릭 기반 의사결정 등 고급 기능 자동화” [^33]: @[28:40]~@[29:43] “표… 메트릭 기반 디시전/롤백/분석… PD 컴포넌트는 Automatic/Built-in… 수작업이면 PD라 하기 어렵다” [^34]: @[24:56]~@[26:12] “Flagger… 카나리/AB/블루그린/미러링… Prometheus/Datadog/CloudWatch… Slack/MS Teams/Discord… CRD 기반” [^35]: @[26:22]~@[27:11] “Flux는 오브젝트를 Git 기반 반영… Flagger는 메트릭 수집/분석 후 카나리/블루그린 자동화” [^36]: @[27:11]~@[27:49] “Argo Rollouts… 컨트롤러+CRD… 서비스 메시/Ingress 통합… 트래픽 점진 이동… KPI 확인 후 프로모션/롤백” [^37]: @[28:04]~@[28:23] “사람이 손으로 트래픽 조절이 아니라… 메트릭 기반 의사결정 제공” [^38]: @[29:43]~@[30:10] “AWS… ALB 컨트롤러 사용 시… Argo Rollouts… App Mesh 사용 시 Flagger” [^39]: @[30:27]~@[31:00] “NGINX, Istio 지원… 거의 모든 환경에서 구현 가능” [^40]: @[31:00]~@[31:59] “감이 안 올 수 있어 데모… Argo CD UI… 탭들… 앱 등록… CLI로 등록” [^41]: @[32:13]~@[33:25] “CLI 명령… repo 주소/매니페스트 경로/클러스터/네임스페이스… 등록 메시지 확인” [^42]: @[33:49]~@[34:22] “OutOfSync… 오토 싱크 설정 안 해서… 수동 Sync 버튼으로 반영” [^43]: @[34:31]~@[34:57] “Sync 시작… 배포 반영… 헬스 체크 성공 시 하트 표시” [^44]: @[34:57]~@[35:55] “이어서 Argo Rollouts… Rollout 오브젝트… Deployment 확장… canary/stable service… ALB 정보” [^45]: @[35:56]~@[36:31] “트래픽 가중치… 5 10 20 50 80… (간격 언급) … 트래픽을 그래픽으로 표현한 데모 앱” [^46]: @[36:47]~@[37:35] “옐로→레드… 형상 코드 변경 push… OutOfSync 확인… Sync… 기존 파드 유지 + 카나리 파드 생성” [^47]: @[37:35]~@[38:03] “ALB 통해 분배… 설정대로 20초마다 기존→카나리로 전달 확인” [^48]: @[38:06]~@[38:32] “운영 환경에 맞춰 설정… 메트릭 분석 넣어 Prometheus 기반 배포 가능” [^49]: @[38:32]~@[38:50] “중단(suspend) 정의… 최종 전환 멈춤… 트래픽 전환이 멈춘다는 의미” [^50]: @[39:18]~@[39:52] “80에서 더 이상 전환되지 않음… 상태가 suspend라 체크 미완료처럼 보임” [^51]: @[39:52]~@[40:19] “완전히 트래픽 전환 버튼… 구 버전 termination… 새 버전으로 트래픽 전달 확인” [^52]: @[40:27]~@[40:51] “데모와 세션 여기까지… 설문 참여 요청… 발표자 소개/감사”

← 프로젝트에서 보기