[발 번역] 웹 기반의 클라우드 관리와 배포

해당 블로그는 KT UCloud 의 지원을 받고 있습니다.

해당 글은 http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html 의 글을 발 번역 한 것입니다. 아마존 AWS 상에서의 관리에 관심이 있는 분들은 꼭 읽어보시길 강추합니다. Netflix에서 공개하는 툴들을 보면 상당히 좋은 것들이 많습니다.

과거 몇년 동안, Netflix 개발팀은 자체 개발한 툴을 이용하여 아마존 클라우드로 수 백개의 애플리케이션과 서비스를 배포하고 구축했습니다. 이런 툴 중에 하나가 Asgard 이고 Netflix 개발자들이 클라우드를 관리하기 위해서 사용합니다. Asgard를 github에 오픈소스로 공개하고, 아무나 다운로드 받아서 사용할 수 있게 된 것이 매우 기쁩니다. AWS 계정만 있으면 됩니다. Netflix의 다른 오픈소스들과 마찬가지로 asgard 역시 Apache License Version 2.0으로 공개되었습니다. 자유롭게 해당 프로젝트를 포크하고 개선해주길 바랍니다.

해당 블로그의 몇가지 정보들은 아래의 프리젠테이션에서 이미 공개가 되었습니다. Asgard는 Netflix Application Console 또는 NAC의 오리지널 이름입니다.

Visual Language for the Cloud

사용자들이 여러가지 클라우드 엔티티들을 구분하는 것을 돕기 위해서, Asgard 에서는 Tango 라는 오픈 소스 아이콘 셋에 몇개를 추가해서 사용하고 잇습니다. 해당 아이콘들은 사용자들이 이용하고 잇는 것들이 무엇인지 이해하는 것을 돕기 위한 시각 언어를 만드는 것을 돕습니다. Tango 아이콘들은 이미 Jenkins, Ubuntu, Mediawiki, Filezilla, Gimp 등에서 사용되고 있어서 친숙할 것입니다. 다음은 Asgard 클라우드 아이콘 샘플입니다.

Cloud Model

Netflix 의 클라우드 모델은AWS에서 바로 서포트해주지 않는 개념을 포함하고 있습니다. 애플리케이션과 클러스터입니다.

Application

아래는 Netflix 자동 완성 서비스와 같은 Single front-end 어플리케이션을 서비스하기 위해서 필요한 아마존 오브젝트들에 대한 다이어그램입니다.

해당 클라우드 오브젝트들에 대해서 간단하게 요약하면 다음과 같습니다.

하나의 Auto Scaling Group(ASG)는 0개나 그 이상의 Elastic Load Balancers(ELBs) 를 새로운 장비에 추가할 수 있습니다.
하나의 ELB는 user traffic을 장비로 보낼 수 있습니다.(Route)
하나의 ASG는 새로운 장비를 시작하거나 종료할 수 있습니다.(Launches and Terminates)
개별 장비의 시작을 위해서 ASG는 Launch Configuration(실행 설정)을 이용합니다.
Lunch Configuration은 아마존 머신 이미지(AMI) 를 구체적으로 명시하고, 새로운 장비를 시작할 때, 어떤 Security 그룹을 이용할 것인지 명시합니다.
AMI는 각 장비에서 사용할 OS 등과, 사용할 특정 어플리케이션들의 특정 버전들을 포함하고 있습니다.
Security Groups 은 traffic 을 보내는 source 나 port 등을 차단할 수 있습니다.

하나의 어플리케이션을 배포하기 위해서 수 많은 일들에 대해서 파악해야 합니다.

Service-Oricent 설계(Netflix가 가진)에 수 많은 클라우드 객체가 있고, 그들이 사용하는 특정 서비스와 연관된 객체를 모두 찾아내는 것은 매우 중요합니다. Asgrad는 여러 개의 클라우드 객체와 하나의 어플리케이션을 연관시키는 것에 대한 네이밍 규칙과 SimpleDB 안에 어플리케이션 레지스트리를 사용합니다. 각 어플리케이션은 소유주와 이메일 주소를 어플리케이션과 연관된 클라우드 객체의 상태와 존재에 대해 책임이 있는 사람에게 전달하기 위해서 가지고 있습니다.

Asgard는 애플리케이션 이름에 사용되는 문자를 하나의 어플리케이션과 연과되는 이름으로 클라우드 객체의 이름을 구분할 수 있도록 제한하고 있습니다.

다음은 Asgard에서 사용하는 아마존 클라우드의 us-east-1 region에서 동작하는 제품들에 대한 스크린 샷입니다.

하나의 단일 어플리케이션과 이와 연관된 클라우드 객체들에 대한 위한 상세한 스크린샷입니다.

Cluster

Auto Scaling Group의 최상단은 아마존에 의해서 제공되는 개념입니다. Asgards는 Cluster 라고 불리는 객체가 하나 이상의 ASG를 가진다고 가정하고 있습니다. ASG들은 네이밍 규칙으로 연관되어 있습니다. 새로운 ASG가 클러스터 내에 생성될 때, ASG의 이름은 Cluster의 기본 이름에 증가된 버전이 붙어서 만들어지게 됩니다. Cluster는 Asgard 유저에게 배포 후에 재빨리 롤백될 수 있는 기능을 제공합니다.

예제: 배포 도중에, cluster obiwan 은 ASG obiwan-v063 와 obiwan-v064 를 포함하고 있습니다. 여기에 배포 과정의 스크린샷이 있습니다.

이전 ASG는 “동작 안함” 상태로 트래픽을 더 이상 받지 않고 있지만, 새로운 ASG에 장애가 발생한 경우에 이용가능하도록 남아있습니다. 복구시에 트래픽은 ELB로 부터 받게 되고, 이를 위한 Netflix 내부 서비스는 아직 오픈 소스가 아닙니다.

Deployment Methods

Fast Rollback

Asgard의 주요 특징 중 하나는 문제에 대한 첫번째 징조에서 바로 롤백하기 위한 방법으로 새로운 버전의 어플리케이션을 배포하는 중에 클러스터 스크린을 보여주는 것입니다. 해당 방법은 배포 중에 더 많은 장비를 필요로 하지만, 잘못된 배포로 일어나는 서비스의 문제를 많이 줄여줄 수 있습니다.(역자 주: 장비가 2배로 드는 것을 예상할 수 있습니다. 뭐, 그 시간에만 일테니, 클라우드의 장점이 십분 발휘되겠죠.) 아래의 에니메이션 다이어그램은 배포 과정중에 문제가 발생했을 때 클러스터 인터페이스를 이요해서 빠르게 다시 롤백 하는 간단하게 표현한 것입니다.

해당 에니메이션은 다음과 같은 배포 케이스를 보여주고 있습니다.(역자 주: 해당 방법이 장비수는 많이 들지만, 장애 시간을 줄일 수 있는 일반적인 배포 방법입니다.)

새로운 ASG obiwan-v064 생성
obiwan-v064 로 트래픽 전달
obiwan-v063 로의 트래픽 정지
모니터링 결과 점점 상황이 안좋아지는 것을 발견
obiwan-v063 로 다시 트래픽 전달
obiwan-v064 로의 트래픽 정지
로그를 분석해서 잘못된 서버의 문제점을 진단합니다.
obiwan-v064 를 제거합니다.

Rolling Push

Asgard 는 rolling push 라고 불리는 다른 배포 시스템도 제공하고 있습니다. 이것은 일반적인데이터 센터에서의 어플리케이션 서버 클러스터 배포 방식과 비슷합니다. 오직 하나의 ASG가 필요합니다. 이전 장비는 안정적으로, ASG의 모든 장비가 변경되기 전까지, 한 두대씩 순차적으로 제거되거나 새로운 장비로 변경됩니다. Rolling Push는 다음과 같은 경우 유용합니다.

해당 ASG 장비들이 다른 장비들과 중복되지 않아야 하는 분명한 목적으로 서비스되고 있을 경우
특정 어플리케이션의 클러스터링 메카니즘이(예를들어, 카산드라) 클러스터 내의 급속한 증가에 대한 지원이 없을 경우(역자 주: 카산드라의 경우, 장비를 너무 많이 추가하면, 데이터 교환으로 인해서 부하가 발생하게 됩니다.)

Rolling Push의 단점은 다음고 같습니다.

배포하는 것에 오랜 시간이 걸릴 수 있습니다.
배포가 잘못되었을 경우에, 복구에도 오랜 시간이 걸릴 수 있습니다.

Task Automation

배포 프로세스를 자동화 하기 위한 여러개의 일반적인 작업이 Asgard 안에 들어갔습니다. 아래는 14분 동안의 자동화된 Rolling Push 작업을 하는 것을 보여주는 간단한 애니메이션입니다.

Auto Scaling

Netflix는 배포의 중요한 부분으로써 ASG에 집중하고 있습니다. 그래서 Asgard는 ASG의 수정과 필요시 Metrix-Driven 기반의 Auto Scaling을 셋팅하기 위해서 그래픽적인 컨트롤들을 제공합니다.

아마존에서 제공하는 CloudWatch metrics 가 기본적으로는 선택되어 있습니다.( CPUUtilization 이라든지) 그리고, Servo 같은 자바 라이브러리를 이용해서 커스텀 metrics를 어플리케이션에 제공할 수 있습니다.

Why not the AWS Management Console?

AWS Management Console 은 Asgard에서는제공하지 않는, 아마존 계정에 패스워드를 설정하는등의 자신만의 필요성이 있습니다. 그러나 매일매일, 대 규모 작업을 다루는데는 AWS Management Console 은 아직 Nexflix의 클라우드 사용 모델을 충족시키기에는 모자랍니다. 우리가 Asgard를 사용하는 이유는 다음과 같습니다.

아마존 Keys를 숨기자.

Netflix에서는 현재 시스템의 발전과 수정을 포함한 직원 각자의 자유와 책임을 인정합니다. 대부분의 시스템은 아마존 클라우드에서 운영중입니다. 수 백명의 직원들이 각자의 클라우드 어플리케이션을 관리하고 싶기를 원하지만, 직원 모두에게 아마존 계정에 바로 접근할 수 있는 secret key를 바로 주는 것은 선호하지 않습니다. 내부 콘솔을 제공함으로써, 너무 많은 직원들에게 클라우드 패스워드를 알려주지 않고도 아마존 계정에 Asgard 유저가 접근할 수 있도록 허용했습니다. 해당 전략은 개발자를 위해서 수 백개의 IAM( Identity and Access Management ) 을 필요로 하는 상황에서 벗어나게 해주었습니다.

Auto Scaling Groups

Auto Scaling Groups(ASGs) 에 대한 AWS Management Console 지원이 부족했다고 쓴 것처럼, Netflix는 배포의 기본 단위나 어플리케이션 장비의 관리 단위로 써 ASG에 에 크게 의존하고 있습니다. 오픈 소스로 푼 Asgard의 주요 목적중에 하나는 다른 아마존 고객들이 아마존의 Auto Scaling 을 쉽게 사용하도록 돕는 것입니다. ASG는 Netflix에서 신뢰성, 안전성, 비용 절감, 클러스터링, 배포의 간단함, 빠른 롤백을 위해서 큰 부분을 차지하고 있습니다.

Enforce Conventions

성장하는 다른 시스템들 처럼 생성하는 것을 사용자에게 허용해주면, 클라우드는 쉽게 비싸고, 이름이 정해지지 않은, 혼동되는 장소가 되어 버립니다.

Netflix Cloud 아키텍처의 일부는 네이밍 규칙을 통해서 서비스에 연관된 클라우드 오브젝트를 등록하고 있습니다. Asgard는 클라우드를 온전한 상태(감사가 가능하고, 정기적으로 더럽고, 잊어버린 것들을 정리해서)로 유지하기 위해서 이러한 네이밍 규칙을 강제하고 있습니다.

Logging

예전부터, AWS Console 은 계정 사용자의 최근 액션 로그를 보여주지 않았습니다. 이는 문제가 발생했을 때, 누구에게 물어야 할지 결정하는 것을 어렵게 만들었고, 문제와 어떤 작업이 연관이 있는지를 아는 것도 어려게 만들었습니다. 로깅의 부족은 합법적으로 감사가 필요한 중요한 시스템에게는 치명적입니다.

Integrate Systems

자체 콘솔을 가지는 것은 다른 엔지니어링 시스템인 Jekins나 internal Discovery service 등과 통합이 필요할 때, 통합 포인트를 결정하는 것에 자율권을 주었습니다.

Automate Workflow

많은 작업을 안전하고 효율적인 배포 프로세스가 되도록 했씁니다. 확실한 유즈 케이스를 미리 앎으로써, Asgard가 제출한 양식에 따라 필요한 모든 스텝을수행 할 수 있도록 했습니다.

Simplify REST API

다른 시스템에서 필요로 하는 일반적인 Operation들을 위해서 우리가 원하는 기능을 정확하게 수행하며, 사용자가 복잡한 단계를 모르고도 사용할 수 있는 자체 REST API를 만들고, 이를 공유해야 했습니다.

Costs

클라우드 서비스를 이용할 때, 비용을 억제하는 것은 매우 중요합니다. 2012년 6월 5일, 아마존은 계정의 비용을 자주 체크할 수 있는 방법을 제공했습니다. 이것은 이 글을 쓰는 시점에는 Asgard에서는 제공하지 않지만, 클라우드 사용 비용을 정기적으로 체크해야 합니다. 다음 문서를 보시기 바랍니다. http://aws.typepad.com/aws/2012/06/new-programmatic-access-to-aws-billing-data.html

Asgard를 구동하는 것만으로는 어떤 아마존 사용료가 발생하지는 않습니다. 왜냐하면, 아마존은 SimpleDB를 위한 무료 단계가 있고, Security Groups를 만들거나 Launch Configuration, 비어있는 Auto Scaling Groups의 생성에는 비용을 부가하지 않습니다. 그러나 ASG가 하나씩 추가되고, 장비 사용에 따라서 비용 부가가 시작될 것입니다. ELB, RDS 와 또 다른 클라우드 객체를 생성하면 역시 비용이 부가됩니다. 많은 클라우드 객체를 만들기 전에 가격 책정과 익숙해져야 합니다. 그리고, 필요가 없어지면 바로 삭제하는 것을 기억하시기 바랍니다. 아마존 비용 부가는 결국 당신의 책임입니다. 그러니 현명하게 운영하시기 바랍니다. 가격은 다음 페이지를 참고하세요. http://aws.amazon.com/ec2/pricing/

Feature Films

Thor 와 Thor: Tales of Asgard 는 현재 Netflix streaming으로 보실 수 있습니다.

Conclusion

Asgard 는 Netflix에서 수년 동안 어플리케이션 배포와 클라우드 관리를 위한 주요 툴입니다. Asgard를 오픈 소스로 공개하면서 많은 사람들이 아마존 클라우드와 Auto Scaling 등을 Netflix 만큼 큰 스케일로 더 쉽게 이용하기를 바랍니다. 추가적인 정보는 정기적으로 공개될 것이고 GitHub에 참여하기는 분은 환영합니다. Netflix Tech Blog 와 @NetflixOSS 트위터를 팔로우 하시면 Netflix Cloud Platform에 대한 다른 컴포넌트들에 대한 정보도 받으시게 될것 입니다. 혹시나 이런 문제를 푸는 데 관심이 있다면, 적합한 포지션이 있는지 the Netflix jobs page 를 살펴보시길 바랍니다. 우리는 채용중입니다.

Charsyam's Blog

Just another WordPress.com weblog

[발 번역] 웹 기반의 클라우드 관리와 배포

Visual Language for the Cloud