EKS 아키텍처 가이드

 Amazon Elastic Container Service for Kubernetes(EKS)를 활용하여 AWS에서 Kubernetes를 사용할 때 활용할 수 있는 AWS 서비스와 아키텍처 구성에 대해 개괄적으로 설명한다.


1. EKS 개요

EKS(Amazon Elastic Container Service for Kubernetes)는 Kubernetes를 사용하여 컨테이너식 애플리케이션을 손쉽게 배포, 관리 및 확장할 수 있게 해주는 서비스이다. EKS는 Kubernetes 커뮤니티의 기존 도구 및 플러그인을 사용할 수 있으며, ECS, ECR, Pipeline 등 Amazon에서 제공하는 각종 서비스와 결합하여 사용도 가능하다. 


2. 아키텍처 구성

AWS Container Service의 전체적인 아키텍쳐이다. 

Control Plane은 컨테이너 클러스터 마스터 역할을 수행하는 곳으로 Amazon ECS, EKS가 있다. DataPlane은 실제로 컨테이너들이 배포되는 곳으로 AWS Fargate, EC2가 있다.  이외에 AWS CodePipeline을 이용해 CI/CD 파이프라인 구성이 가능하며, Registry로 Amazon ECR을 사용하는 것이 가능하다. 또한, RDS, S3, EFS 서비스와의 결합도 가능하다. 


3. EKS vs ECS vs Elastic Beanstalk vs Fargate 비교

컨테이너를 실행할 수 있는 다양한 서비스가 존재하며, 기능 비교를 통해 각자의 환경에 적합한 서비스를 활용할 수 있도록 한다.


EKS(Elastic Container Service for Kubernetes)는 Kubernetes를 사용하는 컨테이너식 어플리케이션 관리형 환경이다. Amazon EKS는 Kubernetes Master를 여러 가용 영역(Availability Zone)에 자동으로 배포함으로 가용성이 높은 아키텍처를 제공하는 클라우드 서비스이다. EKS에서 실행되는 Application은 단일 마스터 혹은 전체 가용 영역의 손실에 대해 복원력을 가지며 마스터에 대한 위험 요소 탐지, 버전 업그레이드를 자동으로 수행한다. 또한 클러스터의 관리, 확장 및 업그레이드와 관련된 작업을 자동화해준다. 뿐만 아니라, AWS의 모든 성능, 확장성, 안정성 및 가용성은 물론 애플리케이션 로드 밸런서, AWS IAM(Identity and Access Management), AWS 프라이빗 링크(PrivateLink), AWS 클라우드 트레일(CloudTrail)을 비롯한 AWS 네트워킹 및 보안 서비스를 사용할 수 있다. 


ECS(Elastic Container Service)는 클러스터에서 Docker 컨테이너를 쉽게 실행, 중지, 관리 해주는 컨테이너 관리 서비스이다. AWS에서 컨테이너식 어플리케이션을 쉽게 실행하고 확장, 축소할 수 있으며 시작유형으로 Fargate, EC2를 선택할 수 있다. 간단한 API 호출을 사용하여 컨테이너 기반 어플리케이션을 시작, 중지할 수 있고 중앙 집중식 서비스를 사용하여 클러스터 상태를 확인할 수 있도록 해준다. 또한, 사용자가 자체 클러스터 관리 및 구성 관리 시스템을 운영하거나 인프라 조정을 신경 쓸 필요 없이 일관된 배포 및 구축 환경을 생성하고, MSA 모델에 정교한 어플리케이션 아키텍처를 구축할 수 있다. 


Elastic Beanstalk는 AWS 환경에서 가장 쉽게 웹 어플리케이션 / 웹 서비스를 배포하고, 확장하고, 관리할 수 있는 완전 관리형 서비스이다.  Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker를 사용하여 Apache, Nginx, Passenger, IIS와 같은 친숙한 서버에서 개발된 웹 애플리케이션 및 서비스를 간편하게 배포하고 조정할 수 있다. 어플리케이션을 업로드만 하면 용량 프로비저닝, 부하분산, 조정, 모니터링, 배포 등을 자동으로 처리해주어 개발자가 어플리케이션을 실행하는데 필요한 인프라에 대한 고민 없이 AWS 클라우드에서 어플리케이션을 신속하게 배포하고 관리할 수 있게 한다.


구분Elastic Container Service for KubernetesElastic Container ServiceElastic Beanstalk
지원되는 언어anyanyDocker, Multi-container Docker, 사전 구성(GO, .Net, Java, Node.js, Ruby, PHP, Python, Tomcat, GlassFlas, Elastic Beanstalk Packer Builder)
지원되는 버전anyany언어별 지원되는 버전이 고정됨
이용모델IaaS, PaaSPaaSPaaS
Runtime 환경docker containerdocker containerVM 형태
사용자가 만든 docker image를 실행함사용자가 만든 docker image를 실행함소스를 기반으로 빌드하여 사전 정의된 실행환경(sandbox)의 디렉터리에 배포하여 실행함
Cluster 자동 확장cluster EC2 node 확장하는 방식으로 지원 가능 Aamazon ECS 콘솔에서 CloudWatch Metric을 이용하여 정책 설정 가능함EC2 node 확장하는 방식으로 지원 가능
배포환경EC2 VM 생성, Fargate 지원 예정EC2 VM 생성, Fargate 지원EC2 VM 생성 
서비스 리전

일부 지역
(버지니아북부, 오레곤, 아일랜드)

19년 1월 서울 지역 추가

오사카를 제외한 전 지역전 지역

타서비스 연계

(CloudWatch, SNS, Lambda등)

CloudWatch 일부 지원(VM), 그 외는 로드맵에 포함(Master node 통합로깅, Container 배포 현황, Alert 기능 등)지원지원
비용시간당 0.20 USD + AWS 리소스 사용량에 따른 비용 지불실제 사용한 AWS 리소스 사용량에 대해서만 비용 지불실제 사용한 AWS 리소스 사용량에 대해서만 비용 지불
장점작업자 노드 클러스터를 프로비저닝, Kubernetes 제어 플레인의 프로비저닝, 확장 및 관리를 처리서비스 스케일링, 태스크 기반 IAM 지원, 애플리케이션 로드 밸런서 지원, 서비스 디스커버리, AWS Batch, Fargate 지원Amazon EC2 인스턴스, 용량 프로비저닝, 로드 밸런싱, Auto Scaling, 모니터링 등 어플리케이션 실행을 위해 필요한 모든 세부 사항을 자동으로 처리

Fargate는 서버 및 클러스터를 관리할 필요없이 컨테이너를 실행할 수 있도록 해주는 컴퓨팅 엔진이다. AWS Fargate를 이용하면 컨테이너 실행을 위해 가상 머신 클러스터를 프로비저닝, 구성, 확장할 필요가 없다. 사용자는 인스턴스 유형을 선택하는 대신 컨테이너, CPU 및 메모리 요구사항, 네트워킹 정의, IAM 정책 설정 등의 작업을 통해 어플리케이션을 정의해주면 된다. 현재는 ECS 배포를 위한 컴퓨팅 엔진으로 사용되지만 EKS 로드맵에 Fargate가 클러스터 옵션으로 추가될 예정이다. 


4. Kubernetes와 EKS 비교

오픈소스 Kubernetes 대비 Amazon EKS가 제공하는 차별적인 기능에 대해 소개한다.

  • 관리형 Kubernetes 제어 플레인 : 높은 가용성을 보장하기 위해 3개 가용 영역에서 Kubernetes 제어 플레인을 실행하고 비정상 Master를 자동으로 감지해서 교체함
  • 각 클러스터의 etcd와 API 서버의 가용성과 확장성을 자동으로 관리함
  • AWS IAM의 상세한 정책 관리 : IAM과 Heptio를 이용해 Kubenretes 마스터에 대한 액세스 권한을 세분화 하여 제어할 수 있음
  • VPC 지원 : EKS는 AWS의 VPC 내의 워커 노드에 배포되므로 VPC의 기능(Route Table, Nat G/W, Security Group, NACL 등)을 사용하여 높은 수준의 보안 설정이 가능함
  • 네트워킹 정책 : Calico와 연동하여 Kubernetes 워크로드에 대한 세분화된 네트워킹 정책을 제공함
  • 로깅 및 모니터링 : AWS Cloudtrail을 사용하여 EKS API에 대한 호출 내역을 확인할 수 있으며, AWS Cloudwatch, ElasticSearch를 사용하여 애플리케이션의 상태 확인이 가능함
  • Private Container Registry : Amazon Elastic Container Registry와 결합하여 손쉽게 Private Docker 이미지를 저장하고 액세스가 가능함
  • 빌드 구성 : AWS Codepipeline를 사용하여 인증을 설정할 필요 없이 Kubernetes Engine에서 안정적으로 컨테이너 배포가 가능함


댓글

댓글 쓰기

이 블로그의 인기 게시물

파일처리(한번에 모두읽기, 라인단위로 읽기, 쓰기, 리스트처리, 특정길이만큼 읽기)

이미지
텍스트 파일 한 번에 모두 읽기 (Utility 타입)   대용량 파일일 때는 메모리가 부족할 수 있으므로 ' 텍스트 파일 라인 단위로 읽어서 처리 ' 방식을 사용 public static String read(String filePath) throws IOException {        StringBuilder  stringBuilder;      FileReader     fileReader     = null ;      BufferedReader bufferedReader = null ;      try {          stringBuilder  = new StringBuilder();          fileReader     = new FileReader(filePath);          bufferedReader = new BufferedReader(fileReader);          String line;          while ((line = bufferedReader.readLine()) != null )            ...
자세한 내용 보기

AWS 가용성,확장성

이미지
1.  개요 On-Premise 환경과 마찬가지로 클라우드 환경 하에서 아키텍처 설계 시 연속성 있는 업무 서비스를 제공하기 위하여 시스템 인프라에 대한 고가용성을 고려하여야 한다. 일반적으로 고가용성 확보는 업무 서비스가 수행되는 인프라 구성요소 별로 존재하는 Single Point of Failure(이하 SPoF)를 제거하여, 특정 구성요소에 대한 장애 시 에도 정상 구성요소를 이용하여 정상적인 서비스가 수행되도록 구성하는 것이다.  그러나, On-Premise 환경에서는 초기 물리 장비 도입부터 고가용성을 고려하여 도입을 수행하고 이를 바탕으로 아키텍처 설계가 수행되지만, 이미 물리적인 인프라 환경이 구축되어있는 클라우드 환경의 경우 개별 구성요소에 대한 가용성은 일정 수준 이상 확보가 되어있다고 할 수 있다. 따라서, 클라우드 환경 내에서의 가용성 확보는 구성요소에 대한 가용성 확보보다는 전체 아키텍처 측면에서의 가용성 확보 설계를 중점적으로 수행하는 것이 바람직하다. 또한 가용성 확보 관점에서 클라우드 환경의 특징 중 하나인 [처리 용량을 자유롭게 확장 가능한 아키텍처]와 [장애 시 자동 복구 가능한 아키텍처]을 고려한 어플리케이션/DBMS 등의 설계를 수행하여야 한다. 본 가이드에서는 클라우드 환경 내의 SPoF 구간에 대하여 살펴보고 이를 해결할 수 있는 방안을 설명한다. 2.  가용성 확보 방안 2.1.  센터 On-Premise 환경에서 센터는 평상 시 서비스를 제공하는 주 센터와 주 센터 전체 장애 또는 주 센터에서 운영중인 주요 장비 장애 시 이를 대신하여 업무 처리를 할 수 있도록 하는 DR 센터로 운영 하는 경우가 일반적이다. 해당 센터 간에는 대부분 네트워크로 연결이 되어있으며, 주 센터에서 생성되고 변경되는 데이터에 대하여 실시간/근실시간 동기화를 수행하여 센터 장애 시에 가용성을 확보하고 있다.  클라우드 환경에서의 센터는 특히 본 가이드의 대상이 되는 AWS의 경우 앞서 설명한 바와 같...
자세한 내용 보기

Serverless computing 도입시 고려사항

이미지
  1.  공급업체 종속성 서버리스 컴퓨팅같은 PaaS 서비스는 공급업체 종속성 Vender Lock-in  을 피할 수 없다. PaaS 서비스를 사용하다가 다른 클라우드 업체나 On-Premise로 이전하는 것은 막대한 비용이 발생한다. 또한 서버리스 컴퓨팅 은 제공하는 업체별로 사용 방법이 다르고 트리거 서비스가 각 공급사 서비스별로 연계되지 않기에 멀티 클라우드 전략이 어렵다. 한 예로 AWS Kinesis 라는 데이터 스트림 서비스는 AWS Lambda 와 연결하여 사용하나 Azure Functions 나 Apache OpenWisky에는 연계할 수 없다. 또한 특정 국가에서는 시스템의 서버가 반드시 해당 국가에 위치해야 하는데 CSP의 데이터 센터는 모든 국가에 위치해있지는 않다. 이런 상황에서는 시스템 수출 시 서버리스 컴퓨팅 뿐만 아니라 다른 PaaS 서비스들도 직접 구현해야 할 상황이 발생할 수 있다. 공급업체 종속성을 피하려면 오픈소스 서버리스 컴퓨팅 플랫폼을 이용 해야 한다.  2.  공급업체 마다 상이한 SLA 서버리스 컴퓨팅의 장점 중 하나는 서버 설정 등의 관리를 공급업체에서 진행하는 것이다.  하지만 공급업체의 실수로 장애가 발생할 수 있다.  한 예로 AWS의 Lambda 서비스 초기엔 잘 사용하던 함수가 몇 시간 동안 동작하지 않은 적이 있었고 AWS의 최초 서비스인 S3도 2017년 2월에 장애가 발생하여 이에 연결된 Lambda가 동작하지 않은 적도 있었다. [1]  이런 상황에 대비가 필요하고 필요에 따라서 보상을 받기 위해 SLA나 이용약관을 확인해야 한다.  AWS Lambda는 SLA가 없어 AWS의 문제로 인해 장애가 발생해도 보상 받을 수 없다.  또한 AWS의 Lambda 서비스 이용 약관에는 “AWS Lambda에 업로드된 고객의 컨텐츠가3개월 간 실행되지 않으면 30일 전에 고지하고 삭제할 수 있으며 이에 대해 어떠한 책임도 ...
자세한 내용 보기