The end is another beginning

  1.  서버리스 서버리스 컴퓨팅은 공급사에서 서버를 관리하여 사용자는 서버 프로비저닝, 설정, 구성을 할 필요가 없고 운영체재 패치를 위해 수 많은 서버들을 롤링 업데이트 하거나 중단 타임을 가질 필요가 없다. 내부적으로 컨테이너 기반으로 되어 있지만 사용자는 이 사실을 인지할 필요가 없다.  2.  이벤트 드리븐 서버리스 컴퓨팅은 함수(코드)를 등록하고 트리거로 호출하면 동작하는 방식이다. 서버리스 컴퓨팅을 호출하는 방식은 주로 HTTP나 Queue, 게시/구독, 데이터 스트림 또는 특정 서비스 폴링 이벤트로 플랫폼 별로 상이하다.  3.  개발 생산성 서버리스 컴퓨팅은 서버 관리가 필요 없어 비즈니스 로직에 집중할 수 있어 생산성이 향상된다. 또한 각 함수 별로 언어가 달라도 동작에 지장이 없어 상황에 맞게 언어를 선택하여 코드를 작성할 수 있다. (Polyglot Programming 이 가능하다.)  4.  자동 확장성 클라우드 환경으로 인해 시스템의 확장이 보다 편리해졌다. 가상머신이나 컨테이너는 Autoscaling 기능 설정을 통해 서비스 부하에 맞춰 자동으로 확장한다. 서버리스 컴퓨팅은 여기에서 더 발전하여 설정 없이 요청 수에 맞춰 자동으로 확장한다.  5.  비용 효율성 서버리스 컴퓨팅은 사용한 만큼 비용이 발생하며 보통 과금은 실행 시간과 요청 횟수로 이루어져 있기에 대기 시간 과금이 없어 자주 사용하지 않는 시스템이라면 가상머신보다 저렴하게 사용할 수 있다. 

  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일 전에 고지하고 삭제할 수 있으며 이에 대해 어떠한 책임도 ...

  서버리스 컴퓨팅에 대한 소개와 도입배경, 현황을 통해 서버리스 컴퓨팅에 대한 정보를 제공한다.  1.  소프트웨어 아키텍처 패러다임 변화 최근 시스템은 서버에서 가상화를 넘어 컨테이너로 진화하고 있고, 모놀리틱 아키텍처가 마이크로서비스 아키텍처로 점점 변화하고 있다. 또한 서버 구동 방식도 사용자의 요청을 응답할 때까지 대기하는 구조에서 이벤트에 의해 동작하는 이벤트 드리븐 방식으로 진화하고 있다. 이 중  어플리케이션 개발 및 운영의 단순화라는 측면 에서 서버리스 컴퓨팅이 새로운 아키텍처 설계 패러다임으로 부각되고 있다. 그림. 클라우드로 인한 기술 패러다임의 변화  On-premise 는 서버를 구매하고 운영체재를 설치하고, 배포환경을 구축하는데 수 개월이 소요된다. 서비스의 수요 예측에 실패하면 새로운 서버를 추가 구매하거나 서버 사양을 높여야 하는데 여기에 소요되는 시간도 수 개월이다. 그래서 이런 상황을 막고자 주로 오버스팩의 사양을 구매하게 되고 이로 인해 낭비되는 자원이 많다.  가상머신은 서버 가상화 기술로 On-premise에 비해 서비스 배포 환경을 구축하는데 소요되는 시간을 수 분내로 줄일 수 있고 인프라 제반 관리에 드는 비용도 줄일 수 있다. 또한 필요에 따라 가상서버 수나 사양을 조절하여 자원 효율성을 증대할 수 있다.  하지만 가상머신은 운영체재 설정, 보안 패치 등의 관리가 필요한데 서버가 늘어날수록 관리가 어렵고 시스템 부하에 따라 자동으로 서버를 추가 및 제거하는 오토스케일링 Auto Scaling  기능으로는 꾸준한 트래픽이 증가하는 서비스는 해결이 되겠지만 불예측적이고 폭발적인 트래픽을 처리하기에는 역부족이다. 트래픽이 몰릴 때 서버가 자동으로 추가되어도 수 분의 시간이 소요되고 트래픽을 감당할 만큼의 서버가 추가되기도 전에 트래픽이 감소할 것이기 때문이다.  컨테이너는 운영체재 가상화 기술로 물리서버나 가상머신을 더 효율적으로 사용할 수 있고...

  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 ...

  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에...

  Microsoft Azure AKS(Azure Kubernetes Service)를 활용하여 어플리케이션을 개발하고 관리할 때 주로 활용하게 되는 Azure Cloud Platform의 서비스와 아키텍처 구성에 대해 개괄적으로 설명합니다. 1.  AKS 개요 AKS(Azure Kubernetes Service)는 Azure Cloud Platform 기반에 컨테이너식 애플리케이션 배포를 위한 관리형 환경입니다. AKS 클러스터는 Kubernetes 명령 및 Resource를 사용하여 응용 프로그램을 배포 및 관리 하고 자동 배포를 위한 배포 정책 설정과 어플리케이션 상태 모니터링 서비스를 제공합니다. 2.  아키텍처 구성 형상관리, CI/CD, 컨테이너 레지스트리, 런타임 어플리케이션, 데이터베이스, 로깅/모니터링 등을 어플리케이션 라이프사이클 관점에서 구성하는 방법을 정의한다.  3.  AKS 기반의 Microservice CI/CD 아키텍처 Container 서비스를 통해 매우 손쉽게 응용 프로그램을 지속적으로 빌드 및 배포할 수 있습니다. AKS(Azure Kubernetes Service)에서 Kubernetes를 사용하여 해당 컨테이너의 배포를 오케스트레이션하는 방식으로 컨테이너를 복제 가능하고 관리 가능한 클러스터를 구성 할 수 있습니다. 4.  AKS vs. ACI vs. Container Services Microsoft Azure에서는 다양한 종류의 Container Service를 제공하고 있습니다. 최종 목적은 컨테이너 서비스에 Microservice 기반 애플리케이션을 개발/배포하기 위한 편리한 환경을 제공하는것이지만 비용/용도/개발환경에 따라 다양한 기능과 기술지원이 필요하기 때문에 사용자가 목적에 맞게 선택 할 수 있도록 다양한 컨테이너 환경을 지원하고 있습니다. AKS(Azure Kubernetes Services) ACI(Azure Container Instances)...