AWS Innovate Migrate, Modernize, Build 특집 온라인 컨퍼런스 후기

개요

 9월 26일에 진행된 AWS Innovate 온라인 컨퍼런스에 참석한 뒤, 느낀 점과 배운 내용을 정리해보고자 글을 작성했습니다.

 

AWS Innovate - Migrate . Modernize . Build

 

 유튜브 개발바닥 채널에서 해당 컨퍼런스에 대한 정보를 알게 되어 등록 신청을 하였고, 4개의 Track 중 평소 관심있던 주제인 Track 1(클라우드 네이티브 혁신을 위한 현대화 여정)과 Track 2(데이터 현대화와 차세대 소프트웨어 전략) 중, 'VMware 워크로드의 AWS 클라우드 마이그레이션을 위한 완벽 가이드', '제조업의 미래를 만드는 LG그룹의 클라우드 혁신과 Platform Engineering 여정', '미디어 DevOps 혁신을 이끄는 IaC 기반 Amazon EKS 업그레이드' 총 3개의 강연을 선택해 들었습니다.

 

성공적인 클라우드 아키텍처의 3가지 요소

1. Migrate: 클라우드 마이그레이션 - 비용 절감, 시장의 빠른 변화에 대응하기 위함. 
2. Modernize: 앱 현대화 - 단순히 마이그레이션하는 것이 아니라 클라우드에 적합한 애플리케이션으로 아키텍처를 바꾸는 앱 현대화 과정이 필요.
3. Build: 앱 개발 방식의 변화 - 생성형 AI 덕에 클라우드 운영, 서비스 개발, 업무 방식에서 변화 및 생산성 향상되고 있음.

 

VMware 워크로드의 AWS 클라우드 마이그레이션을 위한 완벽 가이드

 기조 연설을 간략히만 들은 후 가장 먼저 들은 강연입니다. VMware에 대한 이해가 부족하여 모든 내용을 이해하진 못했으나 새롭게 알게 된 것이 많고 추후에 실제로 활용할 수 있을만한 내용이라고 생각해 유익하다고 느꼈습니다.

 

요약:

1. VMware가 브로드컴에 인수된 이후 VMware의 판매 구조와 모델이 변경되었고(소켓 단위 영구 라이센스 -> 코어 단위 구독형 라이센스, 단일 제품 구매 가능 -> 여러 제품을 묶음 형태로 구매 가능, 즉 필요 없는 것도 함께 구매해야 함), VMware Cloud on AWS의 판매 및 구독 방식이 변경됨.

 

2. 기업의 구매 비용 부담 증가하여 기존 VMware 유저 73%(Gartner 조사 결과)가 대체제 찾기 시작.

 

3. 사용자의 대처 방법은 크게 수용, 하이퍼바이저 변경, 클라우드로 마이그레이션 3가지로 나뉠 수 있는데, 클라우드로 마이그레이션하는 방법이 워크로드 최적화 및 현대화 측면에서 장점이 있음.

 

4. AWS는 클라우드 마이그레이션을 다양한 측면에서 다양한 방법으로 지원하며, 마이그레이션 전략 중 Rehost가 빠르게 마이그레이션할 수 있기 때문에 가장 많이 사용되는 전략임 -> 빠르게 마이그레이션한 뒤 천천히 최적화하는 과정을 거침.

 

5. AWS MGN 마이그레이션 방식에는 agent 방식과 agentless 방식이 있음 -> agent 방식이 권장됨.

 

6. agent 방식의 동작 과정은 다음과 같음.

    1. MGN에서 서브넷 등 기본 설정 완료하면 복제 데이터가 지속적으로 저장되는 staging area가 구성됨.

    2. agent 설치, 구성, initial sync 후 지속적으로 데이터 복제 수행. (트래픽은 암호화, 압축 됨)

    3. 데이터 복제 단계에서는 언제든 test 또는 cut over 전환 수행 가능 -> 사전 정의된 서브넷에 test or cut over 환경이 구성됨.

 

제조업의 미래를 만드는 LG그룹의 클라우드 혁신과 Platform Engineering 여정

요약:

1. 온프레미스의 3 tier 구조를 그대로 AWS로 마이그레이션하는 경우, 서버 등의 장비 구매기간만 줄어들 뿐 비즈니스에 발 빠르게 대응 불가하며 온프레미스와 클라우드의 큰 차별점이 없었음. 따라서 AWS 서비스 활용 방법 체계화 필요.

 

2. 랜딩존(확장 가능하고 안전한 잘 설계된 다중 계정 AWS 환경)을 고도화하여 Best Practice 기반의 Governance를 자동화하여 적용 가능하게 함.

    - control tower 활용 -> 보안 관련 Guardrail을 개비, Account Factory 활용해 자동화 -> Governance 자동 준수, 프로젝트 초기 구축 생산성 향상.

   

3. 플랫폼 엔지니어링 도입하여 AWS의 장점을 활용할 수 있는 비용 효율적인 아키텍처 손쉽게 적용 가능한 체계 만듦.

    - 개발자 생산성 높이는데 초점 -> “인프라”와 “애플리케이션 개발 및 제공” 단계 사이의 Non functional한 요소(모니터링, 테스팅, CI/CD 파이프라인 등)들을 제공.

    - EX) Internal Developer Platform(IDP)을 통해 개발팀이 플랫폼을 활용해 인프라 및 Non functional 툴을 제공받을 수 있도록 함.

   

    사전 지식: SRE, DevOps, 플랫폼 엔지니어링

- SRE: 여러 프로덕트에서 공통으로 사용되는 Non functional tool들을 제공.

- DevOps: Product 단위로 Non functional tool들을 제공.

- 플랫폼 엔지니어링: 여러 프로덕트에서 사용할 Non functional 요소들을 미리 정의하여 “플랫폼 화”하여 제공하는 개념.

    - 애플리케이션 기능 개발 외의 대부분을 포함.

    - 프로젝트 생산성을 높이고, Non functional 요소들에 대한 높은 전문성 없이도 일정 수준의 품질을 보장하는데 도움을 줌.

4. 디자인, 개발, 인프라 아키텍처 표준화하고 재활용하여 효율성 향상 및 유지보수의 어려움 줄이는 데 중점.

    - 표준화를 통한 개발 착수 기간 단축의 필요성 느꼈고, 디자인, 인프라, 개발 요구사항의 변화 크지 않았기 때문.

    - 표준화된 플랫폼을 도입함으로써 생산성과 효율성 향상.

    - 표준화는 어려운 작업이며 현실성, 적용 난이도 등이 중요 -> IaC와 K8s 등 플랫폼 엔지니어링을 이루는 많은 요소들이 표준 적용을 자동화하여 이에 도움을 줌.

    - 적용 예시:

      1. Figma를 활용해 만든 표준 UI(Design Asset)를 Frontend 표준 언어와 프레임워크를 활용해 CodeAsset을 만들고 쉽게 사용 가능하게 함 -> 공통 Component(Code Asset)들을 재사용함으로써 효율적인 UI 개발 가능.

    2. 개발에 필요한 기능들의 템플릿 코드를 미리 만들고 프로젝트에서 사용 -> 개발 및 운영 효율 향상.

    3. K8s 사용 시에도 다양한 선택지 존재 -> 운영 용이성과 효율성을 고려해 표준 정책(Best Practice) 수립 -> 전체 프로젝트에서 Best Practice를 사용함으로써 일정 품질 유지 및 운영 복잡도 감소.

    4. 이외에도 Ingress나 log, metric 수집 도구, service discovery, CI/CD 등의 요소들도 표준화.

    5. 이러한 표준을 실제로 활용하기 위해 IaC로 자동화하고, IaC 사용 체계도 만들어 사용 - IaC에 대한 CI/CD 파이프라인 구성.

    6. IDP(Internal Developer Platform)를 통해 이러한 표준화된 소스 코드나 인프라를 개발자들이 확인/활용할 수 있게함.

 

5. 성과: 초기 인프라/DevOps Setup 시간 및 디자인/퍼블리싱 시간 감소 + 시스템 간 일관된 품질 보장.

 

미디어 DevOps 혁신을 이끄는 IaC 기반 Amazon EKS 업그레이드

요약:

1. terraform 배포에 atlantis를 도입, GitHub API와 연동해서 GitHub comment를 통한 자동 배포를 구축 및 운영 중.

 

2. K8s는 각 버전이 릴리즈된 후 1년의 패치를 지원 -> 연 1회(1년에 3개의 버전이 릴리즈 되므로) 업그레이드 필요 -> EKS는 2년의 지원 제공(1년의 추가 지원 기간)하지만 추가 지원 기간에는 클러스터에 대한 추가금 발생.

-> 고객과 접해있는 서비스이기 때문에 장애나 서비스 이슈가 생길 수 있는 너무 잦은 업그레이드는 불가능. 따라서 연 1회 업그레이드.

 

3. EKS Upgrade는 두 가지 방법이 있음.

    1. In Place 업그레이드: 기존 EKS Cluster의 노드를 순차적으로 업그레이드.-> 비용 측면에서 장점이 있으나, 버전은 한번에 하나씩 올릴 수 있기 때문에  연 3회의 업그레이드를 모두 해야 하고 업그레이드 도중 문제가 생겨도 이전 버전으로 롤백이 불가능하다는 단점.

    2. Blue/Green 업그레이드: 비용이 상대적으로 비싸지만, Blue가 동작하는 동안 Green 버전의 Cluster를 구축하고 테스트 및 검토 해본 뒤 무중단 버전 전환과 전환 도중 Blue 버전으로의 롤백이 가능함.

 

4. 버전 업그레이드마다 목표 존재.

    v1. 클라우드 마이그레이션과 IaC 도입하였으나 부분적으로 IaC 적용되지 않았고 Dev, Staging, Test 등의 환경마다 인프라 구성이 불일치.

    v2. IaC로 모든 인프라 구축하여 모든 환경에 동일한 인프라 구축, 하지만 상호 의존적인 IaC로 인해 여러 개의 Repository를 사용하여 여러 번의 apply 필요.

    v3. 단 한번의 apply로 EKS Cluser Bootstraping 가능하도록 IaC 재설계.

   

    Ex)

    IaC 구성: Terraform, Helm + K8s Yaml

    - Terraform: 인프라 구성(Common) + 각 앱이 사용할(각 앱에 필요한) 리소스(App)

    - Helm: 플랫폼 구성 리소스(Common) + 각 앱이 사용할(각 앱에 필요한) 리소스(App)

 

   기존 인프라 구축 과정:

    1. Common 리소스(Terraform, Helm)부터 IaC를 이용해 생성.

    2. App이 사용할 인프라(Terraform)를 IaC 이용해 생성 - Helm 차트에서 Annotation inlining으로 참조할 수 있도록.

    3. 서비스 pod를 helm과 argocd 이용해 배포.

   

   버전 업그레이드: Helm Common을 terraform Common에 포함, Helm App은 아직 Terraform App으로 통합하지 못했음 -> App 리소스의 경우 crossplane을 이용해 terraform을 helm chart로 통합 예정(인 듯).

 

5. 4개의 환경에 각각 2개의 EKS Cluster(blue, green)가 존재할 때 pod의 개수가 약 320개이고 인프라까지 포함하면 IaC으로 관리할 자원이 너무 많아 관리와 순서에 따른 IaC 수행, 코드 수정에 어려움이 있었고, 이를 해결하기 위해 crossplane을 사용.

    - atlantis와 같은 자동화 도구도 있긴 하지만 terraform이나 ansible은 기본적으로 코드를 작성하고 사용자가 직접 실행해야 함.

    - crossplane의 경우, 코드를 작성해 K8s에 설정을 추가하는 방식. K8s내에는 이러한 설정을 인식하기 위한 전용 CRD가 있고, 이러한 설정들의 추가와 변경에 따라 인프라를 생성하고 변경하는 방식 -> 클라우드 인프라 프로비저닝을 k8s를 통해 한다는 점에서 기존 방식과 차별화

    - Crossplane의 컨트롤러가 k8s 내에 생성되고 이를 통해 클라우드 인프라를 제어할 수 있게 되어 argocd를 사용하여 K8s와 AWS 리소스를 모두 프로비저닝하도록 통합할 수 있었고, CI/CD 과정을 간소화하고 한눈에 리소스 상태 파악 용이하다는 장점.

 

6. crossplane은 terraform과 달리 plan 기능이 없다는 단점. 따라서 기반이나 DB 인프라는 Terraform 이용. App 관련 리소스는 cross plane을 활용해 helm chart로 관리.

 

후기

 특집 주제 중 특히 Modernize에 대한 이해도를 높이고 인사이트를 많이 얻을 수 있었고, 특히 실제 적용 사례들을 통해 어떤 과정으로 클라우드 활용 최적화, Platform Engineering, IaC와 EKS 업그레이드가 이루어지는지 쉽게 이해할 수 있었습니다. 앞으로도 이러한 컨퍼런스에 참여하여 클라우드에 대한 이해를 높일 수 있는 기회가 있다면 가능한 참가해야겠다고 느꼈습니다.