[레포트] Amazon EKS! 효율적 이용을 위한 첫걸음

세션

Agenda

• 디지털 트랜스포메이션
• Kubernetes
• AWS에서 Kubernetes를 사용하는 이점
• Amazon EKS를 위한 CI/CD Tools
• Amazon EKS 효율적 이용
• Amazon EKS Spot Instance 마이그레이션
• Amazon EKS 모니터링 구축 및 알람

디지털 트랜스포메이션

• 많은 기업이 쿠버네티스를 접하는 목적은 디지털 프랜스포메이션 시대가 와서 일수도 있음
• 디지털 트랜스포메이션은 변화, 변신으로 기존에 추구해 온 변화보다 한층 높은 근본적인 변화를 말함
• 또한 단순히 하드웨어를 클라우드 기반으로 바꾸거나, 데이터를 디지털화하는 거에서 끝나지 않고, 조직이 변화하는 요구사항에 새로운 기술, 프로세스를 따라가는 발전임
• 예를 들어 기업에서 아무리 디지털 트랜스포메이션 솔루션을 추구하더라도, 옛날 조직문화를 고수하고 있는 문화가 있다면 생산성은 조금도 개선되지 않을 수 있음
• 디지털 기업은 기존 전통적 기업보다 훨씬 더 높은 수준의 투명성과 상호 작용을 통해 빠른 디지털 작업 속도를 만들어야함
• 혼자 만들 수 없는 시대이기 때문에 디지털 트랜스포메이션을 시작하려면 함께 노력해야 달성할 수 있음
• 그렇기 때문에 새롭고 획기적인 기술과 함께 제공되는 새로운 기회를 최대한 활용해야 함

• 쿠버네티스 서비스가 바로 디지털 트랜스포메이션 기반의 시작
• 기존 시스템 환경에서 컨테이너 기반 환경으로 변경하려는 많은 움직임이 있었으며, 실제로 머신러닝, AI조차도 컨테이너 위에서 트레이닝시키는 모습을 볼 수 있음
• 컨테이너를 기반으로 하는 오픈소스이기 때문에 사용자들이 특정 업체에 종속되지 않고 클라우드의 환경들을 이전할 수 있음
• 두 번째로 디지털 트랜스 포메이션을 실현하러면 IT 서비스 개발과 개선속도가 비즈니스 우위를 확보하기 위한 필수적인 조건이라고 생각
• 쿠버네티스는 CI/CD 구성으로 인프라까지 구축이 되는 DevOps 영역으로, 어떻게 보면 DevOps 영역이 성장하게 된 배경이라고 볼 수 있음
• 정말 잘 구축을 해 놓게 되면 다음 인수인계자가 이어서 개발 및 운영을 진행하기 원활하기 때문임
• 쿠버네티스 오케스트레이션을 사용할 경우 이슈에 이점이 많이 있음
• 부하가 들어올 경우 자동 Scale-out을 하며, 요청이 줄어들 경우 자동 Scale-in도 구축할 수 있음
• 리소스 비용으로만 봤을 때 새로운 기술을 접하는데, 가격이 더 저렴해진다면 변경하지 않을 이유가 없다고 생각
• vCPU, Memory도 더 적게 사용할 뿐만 아니라 라이센스 비용도 저렴하게 검토해 볼 수 있음
• 다만 조직문화를 변경해야 한다는 것과 기존에 해보지 않았던 서비스를 다루어야 한다는 어려움이 따를 수 있음

Kubernetes

• 히나의 물리적 서버에서 여러 개의 Virtual Machine
• 쉽게 가상서버를 구성할 수 있게 된 시대
• 하나의 서버가 꼭 여러 대의 서버인 것 처럼 보이게 만드는 방식임
• 하이퍼바이저에 의해 VMOS가 생성되고, 그 VMOS위에 다른 VMOS와는 독립된 자원을 할당 받아 사용하는 원리임
• 아시다시피 이는 아직도 가장 많이 사용하는 방식이고, 안정적으로 애플리케이션을 운영할 수 있다는 것에 장점이 있음
• 컨테이너는 OS를 공유해서 사용하기 때문에 별도로 OS를 구성할 필요가 없어졌음
• 애플리케이션이 동작에 필요한 Binary와 Library만 있으면 됨
• 즉, 리소스도 가벼워졌기 때문에 똑같은 물리적 자원에서 더 많은 애플리케이션을 기동할 수 있게 되었음
• 그만큼 더 확장성도 좋아지게 됨

• 오케스트레이션이란 여러 개의 컴퓨팅 시스템이나 여러 개의 애플리케이션 시스템 등과 같이 관리해 주는 툴을 말함
• 같은 역할을 하는 도구로서 Docker Swarm, Apache Mesos 등이 대규모 컨테이너의 효율적 제어라는 동일한 목적 아래 발전되어 왔으나, 2022년 현재는 쿠버네티스가 컨테이너 기반 최고의 오케스트레이션 도구로 자리 잡고 있음
• 한정된 적은 양의 컨테이너는 기존에 서버를 관리하는 정도처럼 각자 관리할 수도 있겠지만, 엔터프라이즈 환경에서 수 많은 컨테이너를 제어하는 것은 불가능 함
• 더구나 마이크로서비스 아키텍처로 하나의 서비스가 여러 개의 작은 컨테이너로 동작을 하는 서비스를 구현 했다면 수동으로 장애조치 하는 것도 시간이 오래 걸릴 수 밖에 없을 것
• 마이크로서비스 아키텍처 관련해서 도메인 주도설계에 대해 여기서 다루지는 않지만, 도메인 전문가와 개발자가 함께 의사소통하면서 점점 더 작은 서비스로 개발
  하는 것을 말함
• 그 설계를 위해서 쿠버네티스는 빠질 수 없는 오케스트레이션 도구임

• 쿠버네티스의 기본 사상 3가지
• 쿠버네티스는 원하는 상태를 유지하려는 성격과 중앙제어 방식, 그리고 API 기반 접근제어로 간추려 봤음
• 먼저 원하는 상태를 유지하려는 선언적 방식은 A라는 서비스를 5개의 컨테이너로 유지하는 데 있어 Desire 값을 변경하면 이를 지켜보는 컨트롤 플레인에서 리소스를 배포함
• 쉽게 말해 “나는 회사에 9시까지 출근해서 업무를 시작해” 라고 하는 것과, “스마트홈에게 9시에 근무한다고 설정했을 뿐인데 아침에 일어났더니 알아서 9시에 컴퓨터도 켜주고, 조명도 켜주고, 커피도 내다 주고, 토스트도 구워주는 재택근무 세팅이 자동적으로 수행되었다” 라는 개념이라고 생각
• 스마트홈을 비유했는데, 중앙제어가 바로 이 스마트홈이라고 생각하면 좋을 것 같음
• 스마트홈에서 컴퓨터, 조명, 토스트기, TV 등 모든 것을 컨트롤해 줄 수 있으며, 쿠버네티스에서는 이를 마스터노드라고 명시함
• 마스터노드는 쿠버네티스를 중앙제어 역할을 하는 컨트롤 플레인의 물리적인 리소스로, 관리자는 이 마스터노드를 이용하여 워커노드들을 관리함
• 그렇다면 이 마스터노으데 어떻게 접근할 수 있을까?
• 바로 API 통신으로만 접근이 가능하고, API 통신을 통해 설정값을 변경할 수 있는 명령어가 Kubectl임

• 쿠버네티스 클러스터에서 컨트롤 플레인을 설명
• 오른쪽에 보이는 그림처럼 각각의 컴포넌트들이 역할을 하고 있음
• Etcd는 쿠버네티스의 모든 key-value 값들을 저장하는 분산 데이터 스토리지이고, API Server는 클러스터의 API를 사용할 수 있도록 하는 컨트롤 플레인 컴포넌트임
• 이는 좀 전에 설명했던 kubectl 명령어 처럼 API를 호출해야지만 접근이 가능한데 그 서버 역할을 해주는 컴포넌트임
• API 서버를 통해 달느 컴포넌트 간에 서로 필요한 정보를 주고 받는 원리임
• Scheduler는 자원 할당이 가능한 노드 중 알맞은 노드를 선택해주는 역할을 맡고 있으며, 컨트롤 매니저는 우리가 선언한 값, 즉, 노드 개수, 파드갯수 등을 유지해주며 서비스와 디플로이먼트를 연결해주는 연결고리 역할도 진행해 줌
• 이와 비슷한 기능들, 이 모든 것이 컨트롤 플레인이라고 부르며 마스토노드가 담당하는 역할임

• MSA로 구축하게 되면 각각의 서비스들은 IP와 Port로 서비스를 구성하게 됨
• 각각의 서비스들을 자체 네트워크 통신이 가능하게 만드는 점, 그리고 로드 밸런싱을 하여 부하를 분산시키는 데 목적을 두고 있음
• 또한 개발자들이 계속적인 배포를 지향해 줄 수 있도록 자동화된 롤아웃 배포와 롤백, 이는 운영환경에서 또한 부담가지지 않고 Downtime 없이 배포를 할 수 있는 환경을 만들어줌
• 그리고 컨테이너 자체적으로 장애가 발생했을 때 이를 바로 Terminated 시키고 생성해 주는 복구기능도 가지고 있고 Local 영역을 사용하던, 클라우드 스토리지 영역을 사용하던 스토리지 오케스트레이션도 가능하게끔 해줌

AWS에서 Kubernetes를 사용하는 이점

• Amazon EKS의 이점이라 한다면 가장 먼저 떠오르는 것은 관리형이라는 점
• 오른쪽에 아키텍처를 보면 EKS 컨트롤 플레인이 EKS VPC에 아이콘 하나로 표현되어 있음
• 실제로 이 안에는 최소 2대로 구성된 API Server와 etcd, 컨트롤 플레인에 해당하는 서비스들이 인스턴스로 구성되어 있음
• 실제로 부하를 감지하고 자동확장도 진행하며, 비정상 컨트롤 플레인 인스턴스도 교체됨
• 그리고 우리가 흔히 알고 있는 EKS 화면에 접속하면 보이는 EKS 업그레이드는 이 컨트롤 플레인을 업데이트하는 것을 말함
• 추가적으로 완벽한 업그레이드를 위해서는 워커 노드 그룹도 별도 업그레이드를 해야 함
• 두 번째는 가용성 보장임
• 하나의 리전에는 3~4개의 가용영역이 존재함
• 이는 실제로 데이터 센터와 같은 느낌으로 물리적으로 거리가 떨어진 곳을 네트워크로 묶어 클러스터링을 할 수 있게끔 해줌
• 이처럼 하나의 물리적 데이터 센터가 장애가 발생한다 해도 다른 물리적 데이터 센터로 서비스가 가능한 이점이 있음
• 세 번째로 많은 AWS 서비스와 통합되어 사용한다는 점
• PV, PVC 처럼 볼륨요청을 AWS EBS, EFS 등을 사용할 수가 있고 이미지 보관소는 Amazon ECR을 사용할 수 있고, ingress 처럼 밸런싱 하는 기능을 Application Load Balancer를 통해서 할 수 있음
• 또한 로그인 제한을 IAM User, IAM Role로 제한할 수 있다는 점에서 상호작용이 잘 된다고 생각함

Amazon EKS를 위한 CI/CD Tools

• Amazon EKS를 위한 CI/CD Tools
• 더 빨리, 더 자주 배포하기 위한 CI/CD 환경구성에 대해 이야기
• CI는 Continuous Intergration의 약자로 개발자를 위한 자동화 프로세스를 말함
• CI를 구현한다 함은 개발자가 코딩을 하고, 빌드를 하고, 테스트를 하는 것을 자동화 함으로써 공유 리포지토리에 통합되어 관리되는 것을 말함
• CD는 Continuous Deployment의 약자로 운영자들을 위한 자동화 프로세스를 말함
• 컴퓨팅 리소스는 Amazon EC2에 애플리케이션이 있다면 그 애플리케이션에 배포함을 말함
• 이 환경에서 컨테이너를 위한 CI/CD 환경구성을 한다고 함은 Amazon ECR에 컨테이너 이미지를 저장함으로써 시작됨
• Amazon ECR은 어디서나 애플리케이션 이미지를 안정적으로 배포할 수 있도록 뛰어난 성능 호스팅을 제공하는 완전관리형 컨테이너 레지스트리임
• 추가적으로 HTTPS를 통해 컨테이너 이미지를 전송하고 저장 이미지를 자동으로 암호화함
• 다른 레지스트리 저장소를 사용해도 되지만, 여기서는 Amazon ECR를 예로 듬
• CD 환경에서는 Amazon ECR에 저장된 컨테이너 이미지를 fluxCD, argoCD, Spinnaker, Jenkins X 등과 같은 Code Deploy 제품을 사용해 배포함으로써 Amazon EKS에 지속적인 배포를 할 수 있게끔 구성함
• 먼저 Push방식과 Pull방식의 배포방법이 존재
• Push 방식은 배포툴이 권한을 가지고 배포 환경에 배포하는 것을 말하고, 대부분 이 방식을 사용하는 곳이 많이 있음
• 하지만 배포툴에게 AWS 접근 권한과 인프라 권한을 할당해야하기 때문에 보안적으로 신경써야 하는 부분이 많이 존재함
• 그 보안적 향상을 위해 EKS Cluster 안에 CD Tool을 구성하고 사용자는 CD Tool에 로그인 해서 EKS 구성에 필요한 파일들을 배포하도록 도움
• 쉽게 말해 EKS 구성에 필요한 yaml 파일들을 EKS Cluster 안에 있는 서비스가 배포해 주는데, 이 배포는 EKS 환경이랑 실제 작성한 yaml 파일이랑 같은지 다른지 sync하고, sync를 맞추기 위해 노력한다고 생각하면 좋을 것 같음

Amazon EKS 효율적 이용

• Amazon EKS 효율적 이용의 주제는 쿠버네티스 환경 고도화함에 목적이 있음
• 그 첫 번째 고려되어야 할 부분은 바로 NameSpace임
• NameSpace는 물리적으로 나뉜 워커 노드들을 논리적으로 구분함
• EKS Cluster가 물리적인 Cluster라면, NameSpace는 가상적인 Cluster라고 이해하면 좋을 것
• 가장 기본이 되는 NameSpace 이름은 Default이며, 고려하지 않고 구성을 했을 경우 모든 서비스와 파드들은 Default NameSpace에만 존재하게 됨
• 이 그림에서는 서비스와 파드들만 표현했지만, Deployment, Ingress, replicaset등 여러 오브젝트들이 NameSpace에 종속되게 됨
• 그러면 왜 NameSpace 분리해야 할까?
• EKS Cluster도 결국은 EC2 기반으로 노드가 생기기 때문에 물리적 서버 리소스는 한계가 있음
• 그렇게 때문에 NameSpace를 기반으로 상한값을 설정하여 물리적 서버 리소스를 초과하지 않도록 사전에 제한할 수 있음
• 이 뿐만 아니라 개발계 성격, 검증계 성격, 운영계 성격의 NameSpace를 분리하여 중요도를 나눌 수 있어 NameSpace를 나누는 것이 Amazon EKS 효율적 이용의 첫 걸음이라고 할 수 있음

• 워커 노드를 옮ㄹ겨야 하는 경우도 생각해 볼 수 있음
• 보통 쿠버네티스에서 컨트롤 플레인에 스케줄러라는 것이 있어 새로 생성된 모든 파드 또는 예약되지 않은 다른 파드에 대해 Kube-Scheduler는 실행할 최적의 노드를 선택함
• 쉽게 말하면 우선순위 높은 노드에 파드가 배포되지만, 랜덤하게 배포됨
• 실제로 모든 워커 노드 사양이 똑같다면 실제 랜덤하게 배포되도 문제가 되지 않을 것
• 하지만 비용적인 측면을 고려하게 된다면 라벨링과 노드셀렉터로 그 문제를 조금 완화할 수 있음

Amazon EKS Spot Instance 마이그레이션

• 2022년 기준으로 서울 리전 사용자들이 사용하는 스팟 인스턴스 가격을 가져옴
• large 사이즈로 가격은 비슷하지만 vCPU, Memory 등은 다른 점 참고
• 가장 대중적인 M타입, C타입, R타입
• 한 가지 눈에 띄는 건 R타입이 가장 할인 폭이 높다는 것을 알 수 있음
• 대략적으로 C타입은 1:2, M타입은 1:4, R타입은 1:8 비율로 vCPU Memory가 할당 됨
• 여기서 말하는 R4.large는 2vCPU 에 15.25GB Memory가 할당된 인스턴스임
• 그렇다면 R타입이 가장 좋을까?
• C타입은 컴퓨팅 최적화, M타입은 범용, R타입은 메모리 최적화로 각각의 목적에 맞게 사용하면 됨

• 스팟 인스턴스를 잠깐 설명했는데, 컨테이너화된 애플리케이션은 종종 상태 비저장이고 인스턴스가 유연하기 때문에 스팟 인스턴스와 컨테이너는 훌륭한 조합임
• 여기서 AWS를 사용해야 하는 이유가 한 번 더 크게 언급되었는데, 저렴한 비용에 오토스케일링 그룹을 통해 Scale-in/Scale-out을 진행할 수 있음
• 탄력성과 비용 최적화를 모두 달성하는 방법으로 조금 어렵지만 잘 사용하면 Amazon EKS 효율적 이용에 한 발 더 앞서 나간 것임
• 앞서 설명한 레이블 및 노드셀렉터를 이용해 스팟 전용 워커 노드 그룹을 만들 수 있고, CI/CD 도구를 사용해서 파드 오토스케일러를 구성할 수 있고,
• AWS 가이드를 통해 Cluster Autoscaler를 구성하여 AWS 리소스를 자동적으로 늘리고 줄일 수 있음
• 스팟 인스턴스롤 사용하면 AWS에서 리소스를 회수한다는 게 하나의 걸림돌
• 이를 위해 AWS에서 제공하는 Node Termination Handler를 배포하게 되면 스팟 중단에 대처하도록 준비가 마무리 된 것
• 특정 인스턴스 유형의 사용 가능한 온디맨드 용량이 고갈되면 스팟 인스턴스에 2분 전에 중단 알림이 보내져 정상적으로 Termination이 수행됨
• 이 Handler는 중단 알림을 위해 인스턴스에서 EC2 메타데이터 서비스를 모니터링함
• 노드는 Termination 되기 전에 파드들을 다른 파드로 옮기고 문제 되는 노드는 taint를 걸어 더 잇아 파드가 스케줄링 안 되게 막음
• 이런 원리로 스팟 인스턴스를 활용한 스팟 워커 노드 그룹을 만들어 비용 최적화를 달성할 수 있음

Amazon EKS 모니터링 구축 및 알람

• Amazon EKS 모니터링을 구축하기 위해서는 3가지 방향이 있음
• Application Log를 취합하는 Application Monitoring, 컨테이너 리소스를 모니터링하는 Container insight, Deploy하고 결과를 알려주는 Deploy Notification까지 구축하면 Amazon EKS를 보다 효율적으로 유지보수 할 수 있을 것으로 생각
• Application Monitoring은 AWS 서비스인 OpenSearch를 소개
• VM시절에는 LogStach라는 것을 이용해서 ELK로 유명했던 도구
• 지금은 ELK 중 L의 자리를 FluentD가 대신하여 EFK로 소개되었음
• 작년에 ElasticSearch가 OpenSearch로 이름이 바뀌면서 EFK로 부르기는 어색해짐
• Fluentd가 Application Log를 수집해서 OpenSearch에 보내고 Kibana가 사용자 시각화를 도와줌
• Container insight,는 수집하는 지표에 대해 CloudWatch 화면에서 시각화해서 사용자에게 보여줌
• SNS를 통해 Lambda를 연동하면 Slack이나 기타 SNS 연동이 가능
• Container Metric으로 보이기 때문에 컴퓨팅 리소스 알람 설정하는 것과 같이 경보를 설정할 수도 있음

참고

본 블로그에서 사용한 이미지는 AWS Summit Korea에서 제공된 발표자료와 영상을 사용했습니다.