GKE 아키텍처 가이드

 Google Kubernetes Engine을 활용하여 어플리케이션을 개발하고 관리할 때 주로 활용하게 되는 Google Cloud Platform의 서비스와 아키텍처 구성에 대해 개괄적으로 설명합니다.


1. GKE 개요

GKE(Google Kubernetes Engine)는 GCP(Google Cloud Platform) 기반에 컨테이너식 애플리케이션 배포를 위한 관리형 환경입니다. GKE 클러스터는 Kubernetes 명령 및 Resource를 사용하여 응용 프로그램을 배포 및 관리 하고 자동 배포를 위한 배포 정책 설정과 어플리케이션 상태 모니터링 서비스를 제공합니다. 


2. 아키텍처 구성

형상관리, CI/CD, 컨테이너 레지스트리, 런타임 어플리케이션, 데이터베이스, 로깅/모니터링 등을 어플리케이션 라이프사이클 관점에서 구성하는 방법을 정의한다. 
 


3. GKE와 GAE 비교

컨테이너를 실행할 수 있는 서비스를 비교하여 아키텍트가 각자의 환경에 적합한 서비스를 활용할 수 있도록 한다.
GKE(Google Kubernets Engine)는 Kubernetes를 기반으로 하는 컨테이너식 어플리케이션을 관리형 환경이다. 개발자 생산성, 리소스 효율성, 자동화된 작업, 오픈소스 유연성에 혁신을 가져와 제품 출시 시간을 단축해준다. OS 위에 컨테이너가 구동되는 형태로 애플리케이션과 서비스를 손쉽게 배포, 업데이트, 관리할 수 있으며, 컨테이너 복제,  모니터링, 복구를 사용하여 서비스 가용성을 높여 사용자에게 원활한 환경을 제공할 수 있다. 또한, 리소스를 최적화 하여 사용할 수 있으며, 수요에 맞게 확장/축소가 유용하다. GKE를 사용하는 개발자는 서비스를 컨테이너로 구성하고 구동하는 부분만 하면 된다. 
GAE(Google App Engine)은 완전 관리형 서버리스 어플리케이션 플랫폼이다. 기본 인프라를 걱정하지 않고, 어플리케이션을 원할하게 확장할 수 있다. 개발자는 서버 관리와 구성 배포를 고민하지 않고 어플리케이션을 개발하고 사용한 리소스에 대해 비용만 지불하면 된다. 자바, PHP, Node.js, Python, C#, .Net, Ruby, Go 등 일반적인 개발 언어 및 개발자 도구를 지원하여 개발자들의 높은 생산성과 민첩성에 도움이 된다. 어플리케이션 확장, 축소, 패치와 같은 인프라 작업은 Google에서 관리한다.  

구분

Kubernetes Engine

App Engine

 

 

 

Flexible Environment

Standard Environment

지원되는 언어

any

any(Python, Java, PHP, Go, Node.js, Ruby, .NET, Custom Runtimes)

Python, Java, PHP, Go

지원되는 버전

any

any

언어별 지원되는 버전이 고정됨

이용모델

IaaS, PaaS

PaaS

PaaS

Runtime 환경

컨테이너 형태

컨테이너 형태

VM 형태

 

사용자가 만든 docker image를 실행함

소스를 기반으로 플랫폼이 docker image를 생성하여 실행하거나 사용자가 만든 docker image를 실행함

소스를 기반으로 빌드하여 사전 정의된 실행환경(sandbox)의 디렉터리에 배포하여 실행함

어플리케이션 관리

사용자가 로깅, 모니터링, health check, scaling 등 컨테이너 환경을 자유로이 설정할 수 있음

컨테이너에 대한 기본 설정(로깅, 모니터링, health check, scaling 등)은 제공하며, 사용자가 환경변수를 통해 제한적인 설정변경 가능함

컨테이너에 대한 기본 설정(로깅, 모니터링, health check, scaling 등)은 제공하며, 사용자가 환경변수를 통해 제한적인 설정변경 가능함

웹 취약점 점검

미지원

자동으로 웹 어플리케이션 취약점을 점검함

자동으로 웹 어플리케이션 취약점을 점검함

Cluster 자동 확장

수동으로 Cluster 확장

부하에 따라 자동으로 Server 확장됨

부하에 따라 자동으로 Server 확장됨

3'rd party 바이너리 설치

가능

가능

불가

SSH 접속

가능

가능(설정 필요)

불가

Local Disk 쓰기

가능(ephemeral)

가능(ephemeral)

불가

비용

할당된 Cluster의 시간당(CPU, 메모리, 디스크 사용량)

할당된 자원의 시간당 사용량(CPU, 메모리, 디스크 사용량)

일일 무료 사용 후 인스턴스 실행시간

장점

  • On Premise에서 동일한 Kubernetes 환경을 구성할 수 있음
  • 컨테이너 오케스트레이션에 대해 통제 가능(설정 변경 등)
  • 로깅 설정, scaling, 버전 upgrade, 트래픽 분산등을 자동으로 처리하므로 개발자가 컨테이너를 설정할 필요없음
  • 빠르게 Scale Up/Down 가능(Milliseconds)
  • 트래픽이 없는 경우 0으로 Scale되어 비용이 발생하지 않음

적용모델

Container Workload

확장가능한 웹 어플리케이션 및 모바일 backend 어플리케이션, Container Workload

확장가능한 웹 어플리케이션 및 모바일 backend 어플리케이션


4. Kubernetes와 GKE 비교

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

  • 액세스 관리 : Google 계정 및 역할 권한으로 클러스터의 액세스 권한을 관리함
  • 네트워킹 : Google Cloud VPN를 이용해 컨테이너 클러스터에 하이브리드 네트워킹을 구성이 가능함
  • 보안 및 규정 :  Google 보안팀이 Kubernetes Engine을 지원하며 HIPAA 및 PCI DSS 3.1 규정을 모두 준수
  • 통합 로깅 및 모니터링 : Stackdriver Logging과 Stackdriver Monitoring을 사용 설정하면 애플리케이션 실행 상태를 손쉽게 확인이 가능함
  • 자동 업그레이드 : Kubernetes의 최신 출시 버전으로 클러스터를 자동으로 최신 상태로 유지함
  • 자동 복구 : 자동 복구를 사용 설정하면 노드 상태 확인에 실패할 경우 Kubernetes Engine이 실패한 노드의 복구 프로세스를 시작함
  • 완전 관리형 서비스 : Google SRE가 Kubernetes Engine을 완전하게 관리하므로 클러스터의 가용성이 보장되고 최신 상태로 유지됨
  • Private Container Registry : Google Container Registry와 통합하면 손쉽게 Private Docker 이미지를 저장하고 액세스가 가능함
  • 신속한 빌드 : Google Container Builder를 사용하면 인증을 설정할 필요 없이 Kubernetes Engine에서 안정적으로 컨테이너를 배포가 가능함
  • 사용 편의성 : 콘솔 화면 내에 터미널 접속 기능이 있어, 별도의 CLI 설치 작업 없이 손쉽게 사용이 가능함 


댓글

댓글 쓰기

이 블로그의 인기 게시물

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

이미지
텍스트 파일 한 번에 모두 읽기 (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일 전에 고지하고 삭제할 수 있으며 이에 대해 어떠한 책임도 ...
자세한 내용 보기