블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Site Reliability Engineering(SRE)

#1 SRE/DEVOPS의 개념

조대협 (http://bcho.tistory.com)

배경

Devops는 운영팀과 개발팀을 하나의 팀으로 묶어놓고 전체적인 개발 사이클을 빠르게 하고자 하는 조직 구조이자 문화이다.


이 Devops라는 컨셉이 소개된지는 오래되었지만, Devops의 개념 자체는 명확하지만 이 Devops를 어떻게 실전에 적용할것인 가는 여전히 어려운 문제였다.(예전에 정리한 Devops에 대한 개념들 1 , 2)  예전 직장들에 있을때 Devops의 개념이 소개되었고 좋은 개념이라는 것은 이해하고 있었지만, 여전히 운영팀은 필요하였고, 그 역할이 크게 바뀌지 않았다. 심지어 Devops를 하는 기업들도 보면 기존 개발팀/운영팀이 있는데, 새롭게 Devops팀을 만들거나 또는 운영팀 간판을 Devops팀으로만 바꾸는 웃지 못할 결과들이 있었다.

나중에 위메프에서 CTO를 하셨던 김요섭님의 강의를 들을 수 있는 기회가 있었는데, 그때 구글이나 넷플릭스와 같은 사례에 대해 들을 수 있었지만, 그에 대한 디테일한 프렉틱스는 찾을 수 가 없었다.


여러 고민을 하고 있다가 구글에 입사한 후에, 구글의 Devops에 대해서 알게되었고, 여러 자료를 찾아서 공부하고 나니 어느정도 이해가 되서, 개념을 정리해놓는다.

Devops와 SRE

일반적으로 개발팀은 주어진 시간내에 새로운 기능을 내기 위해서 개발 속도에 무게를 두고, 운영팀의 경우에는 시스템 안정성에 무게를 둔다. 그래서 개발팀이 무리하게 기능을 배포하게 되면 장애로 이어지고, 이러한 장애로 인하여 서로를 욕하는 상황이 만들어져서 팀이 서로 멀어지게된다. 그래서 Devops는 이러한 두팀을 한팀에 묶어 놓고 운영하는 문화이자 일종의 운영 철학이다.

그런데 그러면 운영팀과 개발팀을 묶어놓으면 운영을 하던 사람들은 무엇을 하는가? 요즘은 클라우드가 발전해서 왠만한 부분은 개발자들이 직접 배포하고 운영도 할 수 있지만 시스템이 커지면 여전히 운영의 역할은 필요하다. 그렇다면 Devops 엔지니어라고 이름을 바꾼 Devops 엔지니어들이 하는 일은 무엇인가?


그 해답을 구글의 SRE(Site Reliability Engineering)에서 찾을 수 있었는데, 개발자가 셀프 서비스로 운영을 하려면 그 플랫폼이 자동화되어 있어야 한다. 애플리케이션을  빌드하고 유연하게 배포하고, 이를 모니터링할 수 있는 플랫폼이 필요한데, SRE의 역할은 이러한 플랫폼을 개발하고, 이 플랫폼 위에서 개발자들이 스스로 배포,운영을 하는 것이 목표이다. 물론 완벽한 셀프 서비스는 불가능하다. 여전히 큰 장애 처리나 배포등은 SRE 엔지니어가 관여하지만 많은 부분을 개발팀이 스스로 할 수 있도록 점점 그 비중을 줄여 나간다.


그러면 구글 버전의 Devops인 SRE는 서로 다른것인가? 그 관계는 어떻게 되는가? 이 질문에 대해서는 다음 하나의 문장으로 정리할 수 있다.

“ class SRE implements Devops

Devops가 개발과 운영의 사일로(분단) 현상을 해결하기 위한 방법론이자 하나의 조직문화에 대한 방향성이다. 그렇다면 SRE는 구글이 Devops에 적용하기 위한 구체적인 프렉틱스(실사례)와 가이드로 생각하면 된다. 구글도 다른 기업들과 마찬가지로  회사의 성장과 더블어 2000 년도 즈음에 개발자들이 속도에 무게를 두고 운영팀이 안정성에 무게를 둬서 발생하는 문제에 부딪혔고, 이 문제를 풀고자 하는 시도를 하였는데 이것이 바로 SRE (Site Reliability Engineering)이다. SRE는 크게 3가지 방향으로 이런 문제를 풀려고 했는데,

  • 첫번째는, 가용성에 대한 명확한 정의

  • 두번째는, 가용성 목표 정의

  • 세번째는, 장애 발생에 대한 계획

구글 팀은 이러한 원칙을 개발자/운영자뿐만 아니라 임원들까지 동의를 하였는데, 좀 더 구체적으로 이야기를 하면, 이러한 원칙에 따라 장애에 대한 책임을 모두 공유한다는 컨셉이다. 즉 장애가 나도 특정 사람이나 팀을 지칭해서 비난 하는게 아니라, 공동책임으로 규정하고 다시 장애가 나지 않을 수 있는 방법을 찾는 것이다.

위의 3가지 원칙에 따라서, 가용성을 측정을 위해서 어떤 지표를 사용할지를 명확히 정하고 두번째로는 그 지표에 어느 수준까지 허용을 할것인지를 정해서 그에 따른 의사결정은 하는 구조이다.

SRE는 단순히 구글의 운영팀을 지칭하는 것이 아니라, 문화와 운영 프로세스 팀 구조등 모든 개념을 포함한 포괄적인 개념이다.

What does an SRE Engineer do?

그러면 SRE에서 SRE엔지니어가 하는 일은 무엇일까? 아래 그림과 같이 크게 다섯까지 일을 한다.



<출처. 구글 넥스트 2018 발표 자료>

Metric & Monitoring

첫번째는 모니터링 지표를 정의하고, 이 지표를 모니터링 시스템을 올리는 일이다. 뒤에 설명하겠지만 구글에서는 서비스에 대한 지표를 SLI (Service Level Indictor)라는 것을 정하고, 각 지표에 대한 안정성 목표를 SLO (Service Level Objective)로 정해서 관리한다.

이러한 메트릭은 시스템을 운영하는 사람과 기타 여러 이해 당사자들에게 시스템의 상태를 보여줄 수 있도록 대쉬 보드 형태로 시각화 되어 제공된다.

그리고 마지막으로 할일은 이런 지표들을 분석해서 인사이트를 찾아내는 일이다. 시스템이 안정적인 상황과 또는 장애가 나는 지표는 무엇인지 왜인지? 그리고 이러한 지표를 어떻게 개선할 수 있는지를 고민한다. 기본적으로 SRE에서 가장 중요한점중 하나는 모든것을 데이타화하고, 의사결정을 데이타를 기반으로 한다.

Capacity Planning

두번째는 용량 계획인데, 시스템을 운영하는데 필요한 충분한 하드웨어 리소스(서버, CPU,메모리,디스크,네트워크 등)을 확보하는 작업이다. 비지니스 성장에 의한 일반적인 증설뿐만 아니라 이벤트나 마케팅 행사, 새로운 제품 출시등으로 인한 비정상적인 (스파이크성등) 리소스 요청에 대해서도 유연하게 대응할 수 있어야 한다.

시스템의 자원이란 시스템이 필요한 용량(LOAD), 확보된 리소스 용량 그리고 그 위에서 동작하는 소프트웨어의 최적화, 이 3가지에 대한 함수 관계이다.

즉 필요한 용량에 따라 적절하게 시스템 자원을 확보하는 것뿐만 아니라, 그 위에서 동작하는 소프트웨어 대한 성능 튜닝 역시 중요하다는 이야기다. 소프트웨어의 품질은 필요한 자원을 최소화하여 시스템 용량을 효율적으로 쓰게 해주기도 하지만 한편으로는 안정성을 제공해서 시스템 전체에 대한 안정성에 영향을 준다.

그래서 SRE 엔지니어는 자원 활용의 효율성 측면에서 소프트웨어의 성능을 그리고 안정성 측면에서 소프트웨어의 안정성을 함께 볼 수 있어야 한다.

Change Management

세번째는 한글로 해석하자면 변경 관리라고 해석할 수 있는데, 쉽게 이야기 하면 소프트웨어 배포/업데이트 영역이라고 보면 된다. (물론 설정 변경이나 인프라 구조 변경도 포함이 되지만)

시스템 장애의 원인은 대략 70%가 시스템에 변경을 주는 경우에 발생한다. 그만큼 시스템의 안정성에는 변경 관리가 중요하다는 이야기인데, 이러한 에러의 원인은 대부분 사람이 프로세스에 관여했을때 일어나기 때문에, 되도록이면 사람을 프로세스에서 제외하고 자동화하는 방향으로 개선 작업이 진행된다.

이러한 자동화의 베스트프래틱스는 다음과 같이 3가지 정도가 된다.

  • 점진적인 배포와 변경 (카날리 배포나 롤링 업데이트와 같은 방법)

  • 배포시 장애가 발생하였을 경우 빠르고 정확하게 해당 문제를 찾아낼 수 있도록 할것

  • 마지막으로 문제가 발생하였을때 빠르게 롤백할 수 잇을것

자동화는 전체 릴리스 프로세스 중에 일부분일 뿐이다. 잠재적인 장애를 막기 위해서는 코드 관리, 버전 컨트롤, 테스트 등 전체 릴리즈 프로세스를 제대로 정의 하는 것이 중요하다.

Emergency Response

네번째는 장애 처리이다. 시스템 안정성이란 MTTF(Mean Time to failure:장애가 발생하지 않고 얼마나 오랫동안 시스템이 정상 작동했는가? 일종의 건설현장의 "무사고 연속 몇일"과 같은 개념)와 MTTR(Mean time to recover:장애가 났을때 복구 시간)의 복합 함수와 같은 개념이다.

이 중에서 장애처리에 있어서 중요한 변수는 MTTR인데, 장애 시스템을 가급적 빠르게 정상화해서 MTTR을 줄이는게 목표중의 하나이다.

장애 복구 단계에서 사람이 직접 매뉴얼로 복구를 하게 되면 일반적으로 장애 복구 시간이 더 많이 걸린다. 사람이 컨트롤을 하되 가급적이면 각 단계는 자동화 되는게 좋으며, 사람이 해야 하는 일은 되도록이면 메뉴얼화 되어 있는 것이 좋다. 이것을 “Playbook”이라고 부르는데, 물론 수퍼엔지니어가 있는 경우에 수퍼엔지니어가 기가막히게 시스템 콘솔에 붙어서 장애를 해결할 수 있겠지만 대부분의 엔지니어가 수퍼엔지니어가 아니기 때문에, “Playbook” 기반으로 장애 처리를 할 경우 “Playbook”이 없는 경우에 비해 3배이상 MTTR이 낮다는 게 통계이다.

그리고 "Playbook”이 있다고 하더라도, 엔지니어들 마다 기술 수준이나 숙련도가 다르기 때문에, "Playbook”에 따른 장애 복구 모의 훈련을 지속적으로 해서 프로세스에 익숙해지도록 해야한다.

Culture

마지막으로 문화인데, SRE 엔지니어는 앞에서 설명한 운영에 필요한  작업뿐만 아니라 SRE 문화를 전반적으로 만들고 지켜나가는 작업을 해야 한다. 물론 혼자서는 아니라 전체 조직의 동의와 지원이 필요하고, 특히 경영진으로 부터의 동의와 신뢰가 없다면 절대로 성공할 수 없다.

나중에 설명하겠지만 SRE에는 Error budget 이라는 개념이 있는데, 모든 사람(경영층 포함)해서 이 Error budget에 대해서 동의를 하고 시작한다. Error budget은 특정 시스템이 일정 시간동안 허용되는 장애 시간이다. 예를 들어 일년에 1시간 장애가 허용 된다면 이 시스템의 Error budget는 1시간이고, 장애가 날때 마다 장애시간만큼 그 시간을 Error budget에서 차감한 후에, Error budget이 0이 되면 더 이상 신규 기능을 배포하지 않고 시스템 안정성을 올리는 데 개발의 초점을 맞춘다.

그런데 비지니스 조직에서 신규 기능 출시에 포커스하고 Error budget이 0이 되었는데도 신규 기능 릴리즈를 밀어붙이면 어떻게 될까? 아니면 시스템 운영 조직장이 Error budget이 10시간이나 남았는데도 불구하고 10분 장애가 났는데, 전체 기능 개발을 멈추고 시스템을 장애에 잘 견디게 고도화하라고 하면 어떻게 될까? 이러한 이유로 전체 조직이 SRE 원칙에 동의해야 하고,장애가 났을 때도 서로 욕하지 말고 책임을 나눠 가지는 문화가 필요하다.

이런 문화를 만들기 위해서는 크게 3가지 가이드가 있는데 다음과 같다.

  • 데이타에 기반한 합리적인 의사결정
    모든 의사결정은 데이타 기반으로 되어야 한다. 앞에서도 설명했듯이 이를 지키기 위해서는 임원이나 부서에 상관없이 이 원칙에 동의해야 하고, 이것이 실천되지 않는다면 사실상 SRE를 적용한다는 것은 의미가 없다. 많은 기업들이 모니터링 시스템을 올려서 대쉬 보드를 만드는 것을 봤지만 그건 운영팀만을 위한것이었고, SRE를 하겠다고 표방한 기업이나 팀들 역시 대표가 지시해서. 또는 임원이 지시해서 라는 말 한마디에 모든 의사결정이 무너지는 모습을 봤을 때, 이 원칙을 지키도록 고위 임원 부터 동의하지 않는 다면 SRE 도입 자체가 의미가 없다.

  • 서로 비난하지 않고, 장애 원인을 분석하고 이를 예방하는 포스트포턴 문화
    장애는 여러가지 원인에서 오지만, 그 장애 상황과 사람을 욕해봐야 의미가 없다. 장애는 이미 발생해버린 결과이고, 그 장애의 원인을 잘 분석해서 다음에 그 장애가 발생하지 않도록 하는  것이 중요하다. 보통 장애가 나고나서 회고를 하면 다음에는 프로세스를 개선한다던가. 주의하겠다는 식으로 마무리가 되는 경우가 많은데. 사람이 실수를 하도록 만든 프로세스와 시스템이 잘못된것이다. 사람은 고칠 수 없지만 시스템과 프로세스는 개선할 수 있다. 그리고 모든 개선은 문서화되어야 하고 가능한것들은 앞에서 언급한 Playbook에 반영되어야 한다.

  • 책임을 나눠가지는 문화
    그리고 장애에 대해 책임을 나눠 가지는 문화가 있어야 한다. 예를 들어 장애란 개발팀 입장에서 장애는 코드의 품질이 떨어져씩 때문에 장애가 일어난 것이고, 운영팀입장에서는 운영이 고도화 되지 않아씩 때문이며, 비지니스쪽에서는 무리하게 일정을 잡았기 때문이다.  책임을 나눠 가지는 문화는 누군가를 욕하지 않기 위해서라기 보다는 나의 책임으로 일어난 장애이기 때문에, 장애를 없애기 위한 노력도 나의 역할이 되고 동기가 된다.


지금까지 간단하게 나마 SRE의 개념과 SRE엔지니어가 무슨 일을 하는지에 대해서 설명하였다. 다음은 그러면 SRE 엔지니어들이 어떻게 이런일을 해나갈 수 있는지 How(방법)에 대해서 설명하도록 하겠다. 다음글 https://bcho.tistory.com/1325




Reference


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. scinix 2019.05.11 17:40  댓글주소  수정/삭제  댓글쓰기

    Change Management는 "변화관리"보다는 "변경관리"로 번역하시는 게 맞을 것 같네요. ("What does..." 챕터에 있는 대부분의 내용은 ITMS 운영에서 일반적인 내용인데, 해당 부분은 국내에서는 "변경관리"로 부릅니다. 그리고 "변화관리"는 조금 다른 의미로 쓰입니다.)
    글 뒤 쪽의 "포스트포던"은 아마 포스트모텀(Postmortem; 부검)의 오타가 아닌가 싶네요.

    참고로, 저는 이 주제와 관련해서 다음 팟케스트를 재밌게 들었... 아니, 읽었습니다.
    https://www.gcppodcast.com/post/episode-127-sre-vs-devops-with-liz-fong-jones-and-seth-vargo/

  2. sangikbae 2019.05.13 12:58  댓글주소  수정/삭제  댓글쓰기

    예를 들어 장애란 개발팀 입장에서 장애는 코드의 품질이 떨어져씩 때문에 장애가 일어난 것이고, 운영팀입장에서는 운영이 고도화 되지 않아씩 때문이며, 비지니스쪽에서는 무리하게 일정을 잡았기 때문이다. 책임을 나눠 가지는 문화는 누군가를 욕하지 않기 위해서라기 보다는 나의 책임으로 일어난 장애이기 때문에, 장애를 없애기 위한 노력도 나의 역할이 되고 동기가 된다.

    울림이있네요

  3. 제쉬 2019.05.14 08:04  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다

Spinnaker #1 - 소개


Spinnaker

Spinnaker 는 넷플릭스에서 개발하여 오픈 소스화한 멀티 클라우드를 지원하는 Continuous Delivery Platform 이다. 구글 클라우드, 아마존, 마이크로소프트등 대부분의 메이져 클라우드를 지원하며, Kubernetes 나, OpenStack 과 같은 오픈소스 기반의 클라우드 또는 컨테이너 플랫폼을 동시에 지원한다.

시나리오

Spinnaker 의 특징은 멀티 클라우드 지원성뿐만 아니라, 오케스트레이션 파이프라인 구조를 지원한다 특징인데,  배포 단계는 여러개의 스텝이 복합적으로 수행되는 단계이기 때문에, 복잡한 워크 플로우에 대한


관리가 필요하다.

하나의 배포 시나리오를 통해서 오케스트레이션 파이프라인에 대해서 이해해보도록 하자

  • 코드를 받아서 빌드를 하고,

  • 빌드된 코드를 VM에 배포하여 이미지로 만든 후에, 해당 이미지를 테스트한다.

  • 테스트가 끝나면, Red/Black 배포를 위해서 새버전이 배포된 클러스터를 생성한 후에

  • 새 클러스터에 대한 테스트를 끝내고

  • 새 클러스터가 문제가 없으면 트래픽을 새 클러스터로 라우팅한다.

  • 다음으로는 구버전 클러스터를 없앤다.

각 단계에서 다음 단계로 넘어가기 위해서는 선행 조건이 필요하다. 예를 들어 이미지가 빌드가 제대로 되었는지 안되었는지, 새 클러스터가 제대로 배포가 되었는지 안되었는지에 대한 선/후행 조건의 확인 들이 필요하다.

Spinnaker에서는 이러한 오케스트레이션 파이프라인을 “파이프라인”이라는 개념으로 구현하였다. 파이프라인 흐름에 대한 예를 보면 다음과 같다.


위의 파이프라인은 이미지를 찾아서 Red/Black 배포를 위해서 Production에 새로운 이미지를 배포하고, Smoke 테스트를 진행한 후에, 구 버전을 Scale down 시키고, 소스를 태깅 한다. 이때 구 버전을 Destory 하기 전에, Manual Approval (사람이 메뉴얼로 승인) 을 받고 Destory 하는 흐름으로 되어 있다.


또한  각 단계별로 하위 테스크가 있는 경우가 있다. 예를 들어 새로운 클러스터를 배포하기 위해서는 클라우드 내에 클러스터 그룹을 만들고, 그 안에 VM들을 배포한 후에, VM 배포가 완료되면 앞에 로드 밸런서를 붙이고, Health check를 설정해야 한다. 그리고 설정이 제대로 되었는지 체크를 한다음에 다음 단계로 넘어간다.


이러한 개념을 Spinnaker에서는 Stage / Steps/ Tasks/ Operation 이라는 개념으로 하위 태스크를 구현하였다. 개념을 보면 다음과 같다.



파이프라인 컴포넌트

파이프라인은 워크 플로우 형태로 구성이 가능하다. 아래 그림은 파이프라인을 정의하는 화면의 예시이다.


<그림. 파이프라인 예제>

출처 http://www.tothenew.com/blog/introduction-to-spinnaker-global-continuous-delivery/


파이프라인에서 스테이지별로 수행할 수 있는 테스크를 선택할 수 있다.  샘플로 몇가지 스테이지를 보면 다음과 같다.

  • Bake : VM 이미지를 생성한다.

  • Deploy : VM 이미지 (또는 컨테이너)를 클러스터에 배포한다.

  • Check Preconditions : 다음 단계로 넘어가기전에 조건을 체크한다. 클러스터의 사이즈 (EX. 얼마나 많은 VM이 생성되서 준비가 되었는지)

  • Jenkins : Jenkins Job 을 실행한다.

  • Manual Judgement : 사용자로 부터 입력을 받아서 파이프라인 실행 여부를 결정한다

  • Enable/Disable Server Group : 이미 생성된 Server Group을 Enable 또는  Disable 시킨다

  • Pipeline : 다른 파이프라인을 수행한다.

  • WebHook : HTTP 로 다른 시스템을 호출한다. 통상적으로 HTTP REST API를 호출하는 형


개념 구조


Spinnaker는 리소스를 관리하기 위해서, 리소스에 대한 계층구조를 정의하고 있다.



<그림. Spinnaker의 자료 구조 >

출처 : ttp://www.tothenew.com/blog/introduction-to-spinnaker-global-continuous-delivery/



가장 최상위에는 Project, 다음은 Application 을 가지고 있고, Application 마다 Cluster Service를 가지고 있고, 각 Cluster Service는 Server Group으로 구성된다. 하나하나 개념을 보자면,


Server Group 은, 동일한 서버(같은 VM과 애플리케이션)로 이루어진 서버군이다. Apache 웹서버 그룹이나 이미지 업로드 서버 그룹식으로 그룹을 잡을 수 도 있고, 이미지 서버 그룹 Version 1, 이미지 서버 그룹 Version 2 등으로 버전별로 잡는등 유연하게 서버군집의 구조를 정의할 수 있다.

이러한 서버 그룹은 Cluster 라는 단위로 묶일 수 있다.


아래 예제 그림을 통해서 개념을 좀더 상세하게 살펴보자


위의 그림은 이미지 서비스(Image service)를 제공하는 서비스를 Cluster로 정의한것이다.

위의 구조는 Image Service를 Service Group으로 정의했는데, v1,v2,v3 버전을 가지고 있고 각 버전이 Service Group으로 정의된다 (이런 이유는 멀티 버전을 이용한 카날리 테스트나 Red/Black 배포를 이용하기 위해서 여러 버전을 함께 운용하는 경우가 생긴다.)

그리고, 리전별로 별도의 Image Service를 각각 배포하는 모델이다.

리전과 멀티 클라우드의 개념은 Spinnaker 문서에 나온 자료 구조 이외에, 중요한 자료 구조인데, 리소스를 정의할때 클라우드 계정을 선택함으로써 클라우드를 선택할 수 있고, 서비스의 종류에 따라 리전을 선택하는 경우가 있는데 이 경우 리전별로 리소스를 분류해서 보여준다.


Cluster는 Application 내에서 생성될때 , Service Group을 생성시 입력하는  {Account}-{stack}-{Detail} 을 식별자로하여 Cluster를 식별한다. 같은 식별자를 가진 Service Group을 하나의 Cluster로 묶는다.

아래는 Service Group을 생성하는 화면으로 Account, Stack, Detail을 입력하는 메뉴가 있는 것을 확인할 수 있다.



아래 그림은 myapplication 이라는 이름을 갖는 Application 내에, 각각 MY-GOOGLE-ACCOUNT라는 account를 이용하여, myapplication-nodestack-cluster1과, myapplication-nodestack-cluster2 두개의 클러스터를 생성한 예제이다.





또는 자주 쓰는 구성 방식중 하나는 Red/Black (또는 Blue/Green  이라고도 함) 형태를 위해서 하나의 클러스터에 구버전과 새버전 서버 그룹을 각각 정의해놓고 구성하는 방법이 있다.


Application은 Cluster의 집합이고, Project는 Application의 집합이다.

개발하고 배포하고자 하는 시스템의 구조에 따라서 Project, Application, Cluster를 어떻게 정의할지를 고민하는 것이 중요하다.


예를 들어 하나의 서비스가 여러개의 애플리케이션으로 구성되어 있는 경우, 예를 들어 페이스북 처럼, 페이스북 앱, 웹 그리고 앱 기반 페북 메신져가 있는 경우에는 페이스북이라는 프로젝트 아래, 페이스북 앱 백앤드, 웹 백앤드, 앱 백앤드로 Application을 정의할 수 있고,각각의 Application에는 마이크로 서비스 아키텍쳐 (MSA) 방식으로 각각서 서비스를 Cluster로 정의할 수 있다.

아키텍쳐

마지막으로 Spinnaker의 내부 아키텍쳐를 살펴보도록 하자.

Spinnaker는 MSA (마이크로 서비스 아키텍쳐) 구조로 구성이 되어 있으며, 아래 그림과 같이 약 9 개의 컴포넌트로 구성이 되어 있다.



각 컴포넌트에 대해서 알아보도록 하자


  • Deck : Deck 컴포넌트는 UI 컴포넌트로, Spinnaker의 UI 웹사이트 컴포넌트이다.

  • Gate : Spinnaker는 MSA 구조로, 모든 기능을 API 로 Expose 한다, Gate는 API Gateway로, Spinnaker의 기능을 API로 Expose 하는 역할을 한다.

  • Igor : Spinnaker는 Jenkins CI 툴과 연동이 되는데, Jenkins에서 작업이 끝나면, Spinnaker Pipeline을 Invoke 하는데, 이를 위해서 Jenkins의 작업 상태를 Polling을 통해서 체크한다. Jenkins의 작업을 Polling으로 체크 하는 컴포넌트가 Igor이다.

  • Echo : 외부 통신을 위한 Event Bus로, 장애가 발생하거나 특정 이벤트가 발생했을때, SMS, Email 등으로 notification을 보내기 위한 Connector라고 생각하면 된다

  • Rosco : Rosco는 Bakering 컴포넌트로, Spinnaker는 VM또는 Docker 이미지 형태로 배포하는 구조를 지원하는데, 이를 위해서 VM이나 도커 이미지를 베이커링(굽는) 단계가 필요하다. Spinnaker는 Packer를 기반으로 하여 VM이나 도커 이미지를 베이커링 할 수 있는 기능을 가지고 있으며, Rosco가 이 기능을 담당 한다.

  • Rush : Rush는 Spinnaker에서 사용되는 스크립트를 실행하는 스크립트 엔진이다.

  • Front50 : Front 50은 파이프라인이나 기타 메타 정보를 저장하는 스토리지 컴포넌트이다.

  • Orca : Oraca는 이 모든 컴포넌트를 오케스트레이션하여, 파이프라인을 관리해주는 역할을 한다.

  • CloudDriver : 마지막으로 Cloud Driver는 여러 클라우드 플랫폼에 명령을 내리기 위한 아답터 역할을 한다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 김영욱 2018.02.12 12:39  댓글주소  수정/삭제  댓글쓰기

    Spinnaker에 대해서 잘 정리해주신 좋은 자료네요. 본문 중간에 클러스터 네임에 대해 언급하신 부분이 있는데 {account}-{stack}-{detail}이 아니라 아마도 {application}-{stack}-{detail}일 거에요. Netflix frigga 이름짓기규칙입니다(https://github.com/Netflix/frigga). 클러스터뿐 아니라 LB도 같은 이름규칙을 따라야 application 에서 연결할수 있습니다. 저희는 MILK때부터 비슷한 이름규칙으로 AWS resource를 다루고 있었습니다.

Vagrant를 이용한 개발환경 관리(간단한 VM관리)

ALM | 2013. 10. 24. 00:48 | Posted by 조대협

Vagrant

시작하기

Vagrant는 한마디로 이야기 하면, “간소화된, VM 관리 서비스이다”. 이미 Virtual Machine 환경은 보편화 되서 사용되고 있고, VMWare Oracle Virtual Box등을 이용하면 PC에서도 손쉽게 VM 환경을 구축할 수 있다. 그러나 문제점은, Virtual Box와 같은 Hypervisor가 있다고 해도, VM을 생성하는 것 자체가 번거로운 작업이라는 것이다.

 Hypervisor에서 논리적인 가상 하드웨어 머신을 생성하고 가상머신에 OS를 설치하고, 일일이 설정을 해줘야 한다. 이런 반복적인 작업을 조금더 손쉽게 자동화 할 수 없을까? 하는 아이디어에서 시작한 것이 Vagrant이다.

먼저 이해를 돕기 위해서 예제를 실행해보자.

Vagrant VM 관리도구 이기 때문에, 먼저 Hypervisor 부터 인스톨을 해야 한다.

https://www.virtualbox.org/ 에서 Virtual Box를 다운로드 받아서 설치하자.

다음으로 http://www.vagrantup.com/ 에서 vagrant를 받아서 인스톨한다. 이제 준비가 끝났다.

아래와 같이 vagrant init precise32 http://files.vagrantup.com/precise32.box 를 실행하면, Ubuntu Linux VM의 실행하기 위한 설정들을 자동으로 가지고 온다. 그리고 vagrant up 명령어를 실행하면 해당 설정에 따른 VM 을 자동으로 다운받아서 설치하고 Virtual Box를 통해서 해당 VM을 기동 시킨다. Putty를 이용하여 SSH localhost:2222 번으로 접속 (id:vagrant, passwd:vagrant)를 입력하면, 생성된 VM에 로그인할 수 있다. 또는 간단하게 “vagrant ssh”라고 실행하면, 현재 생성된 VM에 자동으로 SSH로 연결된다.



Vagrant 없이 Virtual Box에서 직접 Ubuntu VM을 설치하려면 VM을 만들고, Ubuntu OS를 설치해야 한다. 그러나 Vagrant가 있으면 이렇게 간단하게 두줄의 명령어로 VM을 만들고 실행시킬 수 있다.

Box 개념 이해하기

앞에서 vagrant init 명령을 실행할때, preceise32.box라는 파일을 지정하였다. box 파일은 VM을 만들기 위한 기본 OS 이미지를 포함한 VM 설정(CPU,메모리 사이즈등)에 대한 기본 템플릿이다. (사이즈가 보통 수백 메가가 나간다.)

http://www.vagrantbox.es/ 에 보면 공개된 box 파일들이 있다. Ubuntu, Debian 등 다양한 Linux OS 버전의 VM 들에 대한 box 파일들이 있다.

Vagrant file

Vagrant init을 하면, 해당 디렉토리에 “Vagrantfile” 이라는 이름으로 생성되는 파일인데, Box VM 생성을 위한 기본 템플릿이라면, Vagrant file은 생성될 VM에 대한 세부 설정을 정의한다. VM을 생성할때, 어떤 box 파일을 사용할 것인지, VM에 대한 하드웨어 설정 예를 들어 CPU,메모리 사이즈,네트워크, 네트워크 포트포워딩 설정등을 여기서 재정의 할 수 있다.

아래는 Oracle Virtual Box실행시 preceise32 box 이미지를

http://files.vagrantup.com/precise32.box 에서 읽어와서, CPU 2, 512M를 가진 “Terry_vargrant0”이라는 VM을 생성하는 Vagrantfile이다. 아래와 같이 파일을 생성한후에, vagrant up 명령을 수행시키면 설정한 정보 대로 VM이 생성된다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

  # config.vm.network :forwarded_port, guest: 80, host: 8080

  # config.vm.network :private_network, ip: "192.168.33.10"

  # config.vm.network :public_network

  # config.ssh.forward_agent = true

  config.vm.provider "virtualbox" do |vm|

        vm.customize [

               "modifyvm",:id,

               "--memory","512",

               "--name","Terry_vagrant0",

               "--cpus","2",

                       ]

  end

end

 

Vagrant + Provisioning

Vagrant를 이용하면, VM을 쉽게 만들 수 있다. 그런데 개발환경을 구축하자면, OS가 인스톨된 VM 뿐만 아니라, 그위에 웹서버,DB등 미들웨어들을 설치해야 하고, 그리고 거기에 맞는 Configuration을 해야 한다. 물론 미리 VM 이미지에 웹서버등을 설치해놓고, 필요에 따라서 vagrant를 이용해서 해당 VM들을 설치해서 사용해야 하지만 그 경우에는 설정마다 매번 다른 VM이미지를 만들어놔야 하기 때문에 번거롭다. 만약에 OS 만 설치된 VM에다가, 설정에 따라서 소프트웨어와 설정을 하는 부분을 분리한다면?

이런 접근을 지원하는 기능이 Vagrant provisioning이라는 기능이 있다. VM을 기동한 후에, vagrantfile에 정의된 provisioning script를 수행해준다. 다음 예제를 보자. 다음 예제는 VM이 기동된 후에, apt-get 명령을 이용해서 apache2 (웹서버)를 자동으로 설치하는 설정이다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

config.vm.provision :shell, :inline => "sudo apt-get install -y apache2"

 

end

위의 예제는 VM이 기동될때 마다 shell 명령어를 수행하도록 한것인데, 명령어말고도 shell스크립트를 수행하게 할 수 도 있고, puppet이나 chef와 같은 configuration management 도구를 이용해서, 제품을 설치하게 할 수 도 있다.

한 가지 주의할점은 Vagrantfile provision 부분에 정의된 명령어는 vagrant up, reload, provision 3개의 명령어가 실행될때 마다 매번 실행된다. up에서도 매번 실행되기 때문에, 스크립트내에, 해당 소프트웨어가 미리 설치되었는지 확인한 후에, 설치가 안되어 있을 경우에만 설치하도록 스크립트를 짜는 것이 좋다.

Provisioning에 대한 자세한 방법은 http://docs.vagrantup.com/v2/provisioning/index.html 를 참고하면 된다.

Vagrant를 이용한 개발 환경 구축

그러면 Vagrant를 이용해서 개발환경을 어떻게 구축할 수 있는지 살펴보도록 하자



크게 그림과 같이 2개의 repository가 필요하다. Box image repository에는 기본 이미지가 인스톨된 box image들을 저장해놓는다.

그리고 svn이나 git와 같은 VCS 툴에 vagrantfile을 저장해놓는다. (아니면 간단하게 웹서버에 저장해놔도 된다.) Vagrantfile에는 box 파일들을 저장해놓은 repository pointing 하도록 하고, 필요에 따라서

1.  Ubuntu + Apache

2.  Ubuntu + MySQL

3.  Ubuntu + Tomcat

와 같이 다양한 설정을 만들어 놓고, 필요에 따라서 Vagrantfile이 받은 후에, 간단하게 “vagrant up” 명령어만 수행하면 간단하게 개발환경에 필요한 VM을 만들어낼 수 있다.

지금까지 간략하게 Vagrant에 개념과 사용법에 대해서 알아보았다.Vagrant는 그외에도, Vagrant는 단일 VM 뿐만 아니라 multi vm을 단일 vagrantfile에서 설정이 가능하고, Oracle Virtual Box뿐만 아니라,VMWare Amazon EC2 클라우드 까지 지원한다. 간단하게는 개발환경에서 부터,응용하면, QA,스테이징,운영환경 배포용으로도 활용할 수 있다.

자세한 내용들은 http://docs.vagrantup.com/ 를 참고하기 바란다

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 지돌스타 2017.01.03 20:56  댓글주소  수정/삭제  댓글쓰기

    많은 도움이 되었습니다. 좋은 글 감사합니다.