BLOG

AWS Graviton2 on Amazon EKS 출시에 따른 다중 아키텍처 앱 고려 사항
작성일: 2020-11-09

Amazon EKS on AWS Graviton2가 정식 출시됨에 따라 오늘 테크 블로그에선 이 서비스가 사용자에게 의미하는 바와 작동 방식에 대해 설명 드리고자 합니다. 2019년 초부터 프리뷰에서 1세대 AWS Graviton를 보여 드렸고 올해 초에 진행된 AWS Graviton2 프리뷰 프로그램에 많은 분들이 참여했습니다. 많은 분들의 피드백과 제안 덕분에 AWS Graviton2 on Amazon EKS가 이제 정식으로 사용 가능할 수 있게(General Availability) 되었고, 이에 감사의 인사를 전합니다. 그럼 먼저 해당 서비스에 대해 자세히 알아보기 전에 컨테이너화된 워크로드, 특히 Amazon EKS를 사용 시 다중 아키텍처가 무엇인지 살펴보겠습니다.

 

 

개발 및 배포 전반에 걸친 다중 아카이브

다중 아키텍처(줄여서 다중 아키텍처)는 두 개 이상의 CPU 아키텍처 제품군을 지원합니다. 앱이 다른 CPU에서 실행 되려면 ARMv8 또는 x86-64와 같은 다른 ISA(Instruction Set Architecture) 구현에서 코드를 사용할 수 있어야 합니다.

 

개발 및 배포 수명주기 전반에 걸쳐 “사용 가능”이 어떻게 표시될까요? 다음 그림은 원칙적으로 이를 설명합니다.

 

왼쪽부터 시작:

  1. Developer(개발자)는 코드 또는 수정 버그에 기능을 추가하고 있습니다. 프로그래밍 언어와 이 에코시스템은 다중 아키텍처를 인식하고 대상 아키텍처에 대한 아티팩트 생성을 지원해야 합니다.
  2. 이 경우 런타임 환경은 아마존 EKS 같은 컨테이너 오케스트레이터이며, 이전 단계에서 개발자가 제공하는 아티팩트를 사용합니다.
  3. 사이클은 런타임에서 운영 통찰력에 따라 결정됩니다. 이는 기능 로드맵 실습을 위한 입력으로 문제 해결 목적 또는 사용 패턴 분석 (잘 사용되지 않는 애플리케이션 경로)을 위한 메트릭, 로그 및 추적일 수 있습니다.

 

다음으로는 개발 및 배포 수명주기의 처음 두 단계를 자세히 살펴보겠습니다.

 

개발자는 코드에 새로운 기능을 추가하거나 버그를 수정합니다. 이때, Linux 기반 Arm 워크 스테이션이나 앞으로 Apple MacBook과 같은 아티팩트를 기본적으로 빌드할 수 있는 편리한 환경이 있거나 크로스 플랫폼 빌드를 사용할 수 있다고 가정합니다. 사용 중인 프로그래밍 언어와 에코 시스템은 다중 아키텍처를 인식해야 합니다. 컨테이너 이미지와 같은 대상 아키텍처에 대한 아티팩트 생성을 지원해야 합니다.

 

다중 아키텍처(GoArm 및 Rust 플랫폼 지원)에 대한 기본 지원과 함께 제공되는 Go나 Rust와 같은 클라우드 네이티브 프로그래밍 언어를 사용하거나 PHP, Python, Ruby 또는 Node.js와 같은 해석된 환경을 사용하는 경우 코드가 준비되면 OCI (Open Container Initiative) 컴플라이언트 컨테이너 이미지를 빌드합니다. Docker의 buildx 와 원격 빌드를 사용하여 이를 수행할 수 있습니다. 이 맥락에서 Travis 지원과 같은 자동화된 빌드 및 테스트 파이프 라인 다중 아키텍처 준비 상태를 확인하고자 합니다.

 

다음으로 컨테이너 이미지를 포함한 아티팩트를 런타임 환경에 대한 devops 핸드 오버 역할을 하는 레지스트리로 푸시합니다. 올해 초 Amazon ECR에 대한 다중 아키텍처 컨테이너 이미지를 소개하면서 라이프사이클 부분도 다루었습니다.

 

마지막 단계는 배포입니다. 런타임 환경(이 경우 Kubernetes와 같은 컨테이너 오케 스트레이터)은 이전 단계에서 개발자가 제공한 아티팩트를 사용합니다. Go로 작성된 Kubernetes는 본질적으로 다중 아키텍처로, 여러 아키텍처에 대해 제어 플레인 구성 요소를 제공합니다. Kubernetes에서, 그리고 Amazon EKS의 확장으로 호출된 작업자 노드 로컬 감독자 kubelet는 표준화된 인터페이스를 통해 컨테이너 런타임에 Amazon ECR과 같은 레지스트리에서 컨테이너 이미지를 가져와서 그에 따라 실행하도록 지시합니다. 이 모든 것은 다중 아치가 활성화되고 자동화됩니다.

 

이제부터는 런타임 환경, 특히 Amazon EKS와 AWS Graviton2의 일반 가용성이 의미하는 바에 집중해보겠습니다.

 

 

정식으로 서비스 이용 가능하다(General Availability)는 것이 무슨 의미인가요?

Kubernetes에는 클러스터 상태가 Kubernetes API 서버를 통해 저장 및 조작되는 제어 영역과 작업자 노드로 구성된 데이터 영역이 있습니다.

 

데이터 영역의 경우에는 자신의 계정 혹은 AWS Fargate, 원한다면 서버리스 데이터 영역에서 작동하는 EC2 기반 관리형 노드 그룹을 사용할 수 있습니다.

 

AWS Graviton2 프로세서는 Arm 기반 EC2 인스턴스를 지원하여 성능과 기능을 크게 향상시키고 비용 절감 효과를 제공합니다. 컨테이너 실행의 주요 목표는 애플리케이션의 비용 효율성을 개선하는 것입니다. 이 모두를 결합하면 뛰어난 가격 대비 성능을 얻을 수 있습니다. 예를 들어, 워크로드의 내부 테스트에 따르면 M5, C5 및 R5 인스턴스에 비해 M6g, C6g 및 R6g 인스턴스의 경우 비용이 20 % 절감되고 성능이 최대 40 % 향상되었습니다.

 

오늘부터 AWS Graviton2의 Amazon EKS는 두 서비스를 지역적으로 모두 사용할 수 있으며 이는 다음을 의미합니다.

 

  • ARMv8.2 아키텍처 (64 비트)를 지원합니다.
  • 종단 간 다중 아키텍처 지원 (자세한 내용은 아래 참조)
  • 이제 혼합 관리 노드 그룹이 지원됩니다.
  • EKS API 및 도구 ( eksctl예 : CoreDNS 또는 kube-proxy포드와 같은 Arm 기반 컨트롤 플레인 구성 요소 시작)는 아키텍처별 구성을 처리합니다 .

 

이제 Amazon EKS 데이터 영역의 AWS Graviton2 EC2 인스턴스에 대해 이해했으므로 어떻게 실제로 작동하는지 살펴 보겠습니다.

 

 

오픈 소스 CMS 배포

이 게시물의 실습 부분에서는 라이프 사이클의 배포 arc에 중점을 두겠습니다. 전제 조건으로 문서에 따라 프로비저닝 된 Graviton2 노드 그룹이 하나 이상 있는 Amazon EKS 클러스터가 필요합니다. 이를 확인하려면 다음 명령을 사용하여 EKS 클러스터의 노드를 살펴보세요. 여기서 arch=arm64(가장 오른쪽) LABELS열에 적어도 하나가 표시되어야 합니다.

 

$ kubectl get nodes —show–labelsNAME                                           STATUS   ROLES    AGE   VERSION               LABELSip–192–168–15–231.eu–west–1.compute.internal   Ready    <none>   11d   v1.15.11–eks–065dce   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/instance–type=m6g.medium,beta.kubernetes.io/os=linux,failure–domain.beta.kubernetes.io/region=eu–west–1,failure–domain.beta.kubernetes.io/zone=eu–west–1a,kubernetes.io/arch=arm64,kubernetes.io/hostname=ip–192–168–15–231.eu–west–1.compute.internal,kubernetes.io/os=linuxip–192–168–33–98.eu–west–1.compute.internal    Ready    <none>   11d   v1.15.11–eks–065dce   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/instance–type=m6g.medium,beta.kubernetes.io/os=linux,failure–domain.beta.kubernetes.io/region=eu–west–1,failure–domain.beta.kubernetes.io/zone=eu–west–1c,kubernetes.io/arch=arm64,kubernetes.io/hostname=ip–192–168–33–98.eu–west–1.compute.internal,kubernetes.io/os=linux

ip–192–168–48–242.eu–west–1.compute.internal   Ready    <none>   11d   v1.15.11–eks–065dce   beta.kubernetes.io/arch=arm64,beta.kubernetes.io/instance–type=m6g.medium,beta.kubernetes.io/os=linux,failure–domain.beta.kubernetes.io/region=eu–west–1,failure–domain.beta.kubernetes.io/zone=eu–west–1c,kubernetes.io/arch=arm64,kubernetes.io/hostname=ip–192–168–48–242.eu–west–1.compute.internal,kubernetes.io/os=linux

 

워크로드 예에서는 Python으로 작성된 오픈 소스 CMS (콘텐츠 관리 시스템)인 Plone을 선택했습니다. 다음 Kubernetes 매니페스트를 사용하여 이름이 plone.yaml인 파일에 저장합니다.

 

apiVersion: apps/v1kind: Deploymentmetadata:  name: plonespec:  replicas: 1  selector:    matchLabels:      app: plone  template:    metadata:      labels:        app: plone    spec:      containers:      – name: main        image: arm64v8/plone:5.2.1        ports:        – containerPort: 8080—apiVersion: v1kind: Servicemetadata:  name: plonespec:  ports:  – port: 80    targetPort: 8080  selector:

    app: plone 

다음으로 kubectl apply -f example.yaml를 사용해 워크로드를 배포하고 모두 실행 중인지 확인합니다.

$ kubectl get deploy,po,svcNAME                          READY   UP–TO–DATE   AVAILABLE   AGEdeployment.extensions/plone   1/1     1            1           1d NAME                         READY   STATUS    RESTARTS   AGEpod/plone–576f69df8b–7xzgn   1/1     Running   0          1d NAME            TYPE        CLUSTER–IP      EXTERNAL–IP   PORT(S)   AGE

service/plone   ClusterIP   10.100.89.103   <none>        80/TCP    1d 

이제 Plone 포드가 실제로 Arm 64비트 애플리케이션으로 실행되는지 살펴보겠습니다.

$ kubectl exec –it \    $(kubectl get pods –l=app=plone –o=jsonpath={.items..metadata.name}) \    cat /proc/versionLinux version 4.14.186–146.268.amzn2.aarch64 (mockbuild@ip–10–0–1–125) (gcc version 7.3.1 20180712 (Red Hat 7.3.1–9) (GCC)) #1 SMP Tue Jul 14 18:17:02 UTC 2020 

aarch64는 포드가 Arm 기반 Linux 환경에서 실행되고 있다는 증거입니다.

마무리를 위해 CMS가 잘 작동하는지 확인하려면 kubectl port-forward svc/plone 8888:80를 실행하고 http://127.0.0.1:8888/를 입력해 브라우저로 이동하면 아래 와 같이 표시됩니다.

 

 

AWS Graviton2에서 실행되는 Amazon EKS에서 Arm기반 컨테이너식 애플리케이션을 성공적으로 시작했습니다. 이제 본격적으로 활용할 수 있게 되었습니다.

 

 

다음 단계

Amazon EKS용 AWS Graviton2를 사용할 수 있게 되었지만 여기서 끝이 아닙니다. 다음은 시작하는 방법에 대한 몇 가지 팁입니다.

 

모든 Graviton 관련 탐색을 위한 시작 장소로 GitHub 리포지토리를 사용하고 있으니 aws / aws-graviton-gettting-started도 한번 확인해보세요.

 

Amazon EKS에서 위의 예를 직접 시도하려면 다음과 같은 구성 파일을 사용하여 공식 CLI 도구 eksctl로 테스트 클러스터를 생성하는 것을 추천드립니다.

 

apiVersion: eksctl.io/v1alpha5kind: ClusterConfigmetadata:  name: al–arm  region: eu–west–1managedNodeGroups:  – name: mng–arm0    instanceType: m6g.medium

    desiredCapacity: 3

 

마지막으로, 컨테이너 로드맵, 특히 AWS Fargate의 Arm 기반 작업 활성화에 대한 793호를 확인하세요. 예상대로 작동하지 않는 것이 있으면 알려주시고 피드백, 의견을 남기거나 GitHub  AWS 컨테이너 로드맵에서 확인해보세요.

원문URL: https://aws.amazon.com/ko/blogs/containers/eks-on-graviton-generally-available/

원문 저자: Michael Hausenblas

Michael은 AWS 컨테이너 서비스 팀의 오픈 소스 Product Developer Advocate입니다. 그는 관측성, 서비스 메쉬, 컨테이너 보안, Kubernetes 및 Arm 기반 시스템을 다룹니다. AWS 이전에 그는 Red Hat, Mespore, MapR에서 응용 연구 부문  PostDoc으로 일했습니다. (트위터 아이디: @mhausenblas)

 

** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.