지난해 Public Cloud 전환 프로젝트를 수행하면서 AWS CDK(Cloud Development Kit)로 인프라를 구축했던 경험을 공유하려고 합니다.IaC(Infrastructure as Code) 개발도구의 선택 과정부터 개발 및 배포파이프라인 구축까지 시행착오를 겪고 고민했던 내용을 전달해 보겠습니다.AWS 리소스를 코드로 생성하는 여러 가지 방법이 있습니다. 몇 가지 주요한 방법은 다음과 같습니다.그 중 기술 요구사항과 운영 유지보수를 고려하여 AWS CDK와 Terraform을 검토하기로 합니다.먼저 고객 담당자에게 워크로드의 Multi Cloud 활용 계획을 확인합니다.Terraform은 다양한 CSP(Cloud Service Provider)를 지원하기 때문에 개발도구 선정에 중요한 요소입니다.CSP별로 지원하는 API는 다르지만 HCL(HashiCorp Configuration Language) 문법을 동일하게 활용해 개발 할 수 있습니다.그리고 개발한 코드를 운영할 주체가 누구인지 확인합니다.AWS CDK는 다양한 언어를 지원하기 때문에 운영자가 친숙한 언어를 선택할 수 있는 장점이 있습니다.Terraform의 HCL 문법은 직관적이고 가독성이 좋지만 언어라고 하기에는 부족하고 Script에 가깝다는 생각이 듭니다.두 가지 개발도구 모두 OSS(Open Source Software)로 구축 할 수 있고Terraform은 엔터프라이즈 버전의 경우 사용자관리, 보안, 거버넌스 등 다양한 기능을 제공하지만 라이선스 비용이 적지는 않습니다.결국 고객사 내부 검토를 거쳐 AWS CDK를 개발도구로 선정합니다.AWS 개발자 문서와 온라인 학습프로그램 Skill Builder로 기본기를 다지고 CDK Workshop 으로 실습을 합니다.다음은 반드시 알아야 할 CDK 개념에 대해 정리했습니다.App은 애플리케이션을 구성하는 최상위 단계의 추상화입니다.애플리케이션은 하나 이상의 Stack으로 구성되며, 각 스택은 다양한 Construct를 포함할 수 있습니다.CDK App을 개발하고 배포하기 위해서는 선택한 언어에 상관없이 Node.js 기반 CLI 도구인 AWS CDK Toolkit을 사용해야 합니다.다음은 CLI를 실행할때 배포되는 과정을 보여줍니다.• None 애플리케이션을 만들고 실행합니다.• None 정의한 애플리케이션 모델을 조사하고 합성(Synthesize)을 합니다.• None AWS CDK에 의해 생성된 AWS CloudFormation 템플릿을 작성하고 배포합니다.결국 CDK는 오랜기간 검증된 CloudFormation을 레버리지하여 개발자에게 친숙한 언어로 추상화된 라이브러리를 제공하는 툴이라고 할 수 있습니다.CDK가 중간에서 컴파일러 역할을 한다고 볼 수도 있구요. 따라서 CloudFormation의 기본적인 개념과 구조에 대한 최소한의 학습은 필요합니다.CDK를 운영할 조직 또는 담당자에게 친숙한 언어가 가장 좋은 선택이라고 생각됩니다.그런데 AWS에서 권고하는 언어는 TypeScript인데요. 저같은

Table of contents1. Karpenter 도입 배경 ∘ Why Karpenter?2. Karpenter 도입 과정 ∘ AWS Fargate 도입 ∘ Pod를 On-Demand와 Spot에 나눠서 스케줄링 하기 (capacity spread) ∘ 깡통 파드(empty pod)로 기본적으로 생성 할 Worker Node 구성 ∘ disruption 정책 (노드 삭제 정책) ∘ 비업무 시간 노드 생성/삭제 스케줄링 ∘ Karpenter 지표 모니터링 ∘ Karpenter 로그 모니터링3. Karpenter를 도입하면서 겪은 이슈들 ∘ Drift — Karpenter의 새로운 Distruption 방법 (v0.33.1 기준) ∘ IMDSv2 ∘ Inferentia 타입의 인스턴스4. Karpenter 도입 후기안녕하세요. 중고나라 DevOps 엔지니어 조상현, 김지헌입니다.확장성과 안정성에 대한 고민을 해결하기 위해 새롭게 도입 했던 AWS Karpenter 에 대해 공유를 해보려 합니다.Karpenter 도입 배경중고나라는 회사의 성장과 함께 기능이 지속적으로 추가되면서 리소스 사용량이 증가하고 있는 상황에 직면하게 되었습니다하지만 기존의 인프라는 느린 Provisioning 속도로 인한 문제를 피하기 위해 CA를 채택하지 않고 더 많은 리소스를 사용하여 안정성을 우선시키고자 했습니다.이러한 결정은 안정성 측면에서는 유리하지만, Worker Node의 확장성이 제한되고 많은 비용이 발생한다는 단점이 있었는데요….Why Karpenter?그럼 기존 CA(Cluster Autoscaler)도 사용을 안했는데 왜 Karpenter를 사용했을까요?이를 알기 위해는 CA와 Karpenter의 워크플로를 알아야합니다CA의 워크플로는 아래와 같습니다.HPA를 통해 Pod가 생성 되고 리소스 상황에 따라 Pod는 적절한 Worker Node에 스케줄링 되지 못하고 Pending 상태에 빠집니다.CA 는 Pending Pod 의 상태를 관찰하다가 Worker Node에 할당을 실패하면 Node Group ASG의 API를 보내 Worker Node 개수를 증가하도록 설정합니다.이를통해 ASG는 새로운 Worker Node를 추가합니다.Worker Node가 생성되면 kube-scheduler가 Pod를 새 Worker Node에 할당합니다.즉 CA와 ASG 사이에는 통신을 해야하고 이에 따라 Provisioning 속도 또한 느려지는 상황이 발생하며 확장성 또한 문제를 유발할 수 있습니다.이렇듯 느린 Provisioning 속도로 인해 CA를 사용하지 않고 있었는데요.이에 반해 Karpenter는 빠른 Provisioning 속도를 제공하고 있습니다Karpenter의 워크플로는 아래와 같습니다.HPA를 통해 Pod가 생성 되고 리소스 상황에 따라 Pod는 적절한 Worker Node에 스케줄링 되지 못하고 Pending 상태에 빠집니다.Karpenter는 Pending Pod 의 상태를 관찰하다가 Worker Node에 할당을 실패하면 EC2 a

안녕하세요. 인프랩 데브옵스 엔지니어 선비입니다.오늘은 AWS CDK에서 Terraform으로 글에서 다룬 AWS CDK/Terraform, 그리고 인프콘 2022에서 발표했던 Terragrunt를 지나서 Pulumi에 정착하게 된 인프랩의 IaC 구축기를 풀어보고자 합니다.이번 Part 1 글에서는 Terragrunt를 두고 또 한 번 새로운 도구로 넘어오게 된 배경과 과정, 그리고 이제는 정착할 수 있을 것이라고 생각하는 이유에 대해 한 번 이야기해보려고 합니다.먼저 이 글을 통해서 IaC를 처음 접하시는 분들을 위해 IaC에 대한 간략한 소개와, 인프랩 데브옵스 팀이 어째서 IaC를 정말 중요하게 생각하고 있는지에 대해 말씀드리겠습니다.IaC는 Infrastructure as Code(코드형 인프라)의 약자로, 코드를 통해서 인프라를 관리하는 것을 의미합니다. IaC는 인프라 관리를 자동화하는 다양한 방법 중에서도 소프트웨어 개발 방법론 등 소프트웨어 개발을 위한 수많은 기술과 도구들을 인프라 관리에 적용할 수 있도록 하므로 특히 강력한 방법이라고 할 수 있습니다.제가 인프랩에 합류한 2021년 9월 당시까지만 하더라도 인프랩의 인프라 구성은 메인 서비스 컨테이너와 Redis 캐시, PostgreSQL 데이터베이스, 람다 함수 몇 가지 정도로 그다지 복잡하지 않았습니다. 또한 변화가 일어나는 경우도 많지 않았기 때문에 이 때의 인프라 구성 작업은 대부분 웹 콘솔에서 수동으로 진행되었고 몇 개의 리소스만 AWS CDK를 이용하여 구성하는 상태였습니다.하지만 2021년 말부터 랠릿이 개발되면서 인프라 구성 업무가 급속도로 늘기 시작했습니다. 그 때는 제가 인프랩에 데브옵스로 합류하면서 팀 내 비효율을 기술로 해결하겠다는 당찬 포부와 함께 2년 내에 만들고자 했던 두 가지에 집중하던 시기였는데요,• 전문 지식이 없이도 팀원들이 고수준의 자동화를 직접 구축할 수 있도록 도와주는 추상화가 잘 된 신뢰할 수 있는 파이프라인 시스템• 팀원들이 방향 설정과 동기 부여에 사용할 만한 모든 데이터를 일관적인 방식으로 수집하고 시각화하는 모니터링 시스템몇 가지 조사를 한 후 단기간 내에는 이러한 목표를 달성하기 어렵다는 결론을 내림과 동시에, 이들을 달성하기 위해서는 첫째로 반드시 개인이 아닌 팀으로서 효율적으로 협업할 수 있어야 하고, 둘째로 내일은 오늘보다 더 효율적으로 일할 수 있게 만드는 환경이 준비되어야 한다는 생각을 하게 되었습니다. 즉, 시행착오를 통해 알아낸 정보를 일시적으로 활용하는 것을 넘어 업무 흐름에 적용함으로써 팀원들의 노력을 차곡차곡 쌓아나갈 수 있는 업무 방식이 기반이 되어야 한다고 생각하였습니다.그리하여 시급한 업무를 진행하는 시간을 빼고는 대부분의 시간과 노력을 업무 방식 개선에 투자하게 되었고, IaC 도입은 가장 핵심적인 업무 방식 개선 방안이었습니다.이 때 생각했던 원하는 수준의 IaC는 다음과 같았습니다.• 특별한 경우를 제외하고는 모든 인프라 구성을 IaC를 이용해서 할 수 있다.• 팀에서 한 번 구축해본 구성의

테라폼을 통해 Ncloud Kubernetes Service (NKS) 클러스터 구축하기네이버 클라우드 플랫폼은 사용자 분들께서 클라우드 리소스를 효율적으로 관리할 수 있도록 콘솔, API, CLI, 테라폼(Terraform) 등 다양한 도구를 제공합니다. 특히 테라폼 프로바이더(Terraform Provider)의 코드를 오픈소스로 관리하여 지속적으로 확장 및 개선하고 있는데요. 사용자 분들께서는 오픈소스 생태계를 통해 직접 기능 개선, 버그 수정 등의 방식으로 기여도 하고 사용자 친화적 기능을 경험할 수 있습니다.네이버 클라우드 플랫폼 컨테이너(Container) 카테고리 대표 서비스 Ncloud Kubernetes Service(이하 ‘NKS’)는 2020년 출시 후 지속 발전하고 있습니다. 최근 2023년 11월에는 Public LB Subnet (Public LoadBalancer Subnet)이 도입되면서 테라폼을 통해 Ncloud Kubernetes Service를 생성하는 방식 또한 변경되었습니다.본 포스팅에서는 어떤 내용이 변경 되었는지 확인하고, 테라폼을 활용하여 클러스터를 생성 및 사용하는 과정을 소개 드리겠습니다. 사용자 여러분께서 새로운 기능과 변경 사항을 잘 이해하고, 서비스를 효과적으로 생성하고 관리하는 데 도움이 되었으면 합니다.이런 분들께 추천해요!네이버 클라우드 플랫폼 쿠버네티스 서비스 Ncloud Kubernetes Service를 제대로 활용해 보고 싶은 분테라폼을 활용하여 Container Service 구축 및 자동화 인프라 운영을 시작해 보고 싶은 분클라우드 서비스에서 코드형 인프라(Infrastructure as Code, IaC)를 활용해 서비스 운영을 고민하시는 분ncloud provider를 통한 kubernetes cluster 생성ncloud provider를 사용하기 위해서는 네이버 클라우드 플랫폼 계정, API 키 준비와 함께 테라폼이 설치되어 있어야 합니다. 본 글은 필요한 사항들이 이미 준비되어 있고, 테라폼 기초 지식을 갖추고 있다는 전제 하에 작성한 점을 참고해 주세요.이 장에서는 ncloud provider를 통해 Kubernetes Cluster를 생성하는 방법을 소개합니다.API 환경 변수 설정ncloud API를 사용하는데 필요한 인증 정보와 엔드포인트 정보를 환경 변수로 설정합니다. NCLOUD_API_GW는 테라폼에서 직접적으로 사용되지 않지만 NKS 클러스터의 kubeconfig 파일을 생성하는데 사용됩니다.export NCLOUD_ACCESS_KEY=ACCESSKEYexport NCLOUD_SECRET_KEY=SECRETKEYexport NCLOUD_API_GW=https://ncloud.apigw.ntruss.comncloud provider 설정테라폼을 사용하여 네이버 클라우드 플랫폼의 리소스를 관리하려면 ncloud provider의 설정이 필요합니다. provider.tf 파일을 생성하여 ncloud provider를 설정합니다.provider "nclo