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


Archive»


 
 

전 위메프 CTO 김요섭님의 DEVOPS


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


오늘 GSSHOP에서 전 위메프 CTO 인 김요섭님의 DEVOPS에 대한 강의를 들었다.

그간의 경험이나 고민이 묻어나는 꽉 찬 강의 였다고나 할까?




내용을 정리해보면 다음과 같다.

DEVOPS의 발전 단계

DEVOPS는 조직의 성숙도나 역량에 따라서 단계적인 발전 단계를 갖는다.

첫번째 단계는 자동화를 통해서 자동 빌드와 배포 (CI/CD)를 구축하는 단계, 두번째 단계는 운영 환경에서 나온 로그나 각종 지표를 참고로 하여 개발의 요구 사항에 반영 하는 과정, 세번째 단계는 운영 상황에 개발팀이 참여하여 실제 배포나 장애 상황에 대해서 같이 고민하는 과정, 마지막으로 네번째 단계는 개발 단계에서 운영을 고려하여 설계 및 개발을 진행하는 단계이다.


케이스 스터디

DEVOPS에 대해서 고민을 하면서 자체적으로 많은 스터디를 하신 듯한데, 그중에서 케이스 스터디 내용에서 많은 인사이트를 얻을 수 있었다.


페이스북의 사례

  • 하루에 2번 마이너 업데이트, 일주일에 한번 메이져 업데이트

  • 배포는 테스트 환경에서 배포가 완료되면, 내부 사용자가 사용할 수 있는 단계로 배포하는 H1 배포, 다음으로, 실사용자중 1%의 사용자만 사용할 수 있게 하는 H2 배포, 마지막으로 전체 사용자가 사용하는 환경으로 H3 배포
    일반적인 개발환경에서 봤을때, H1은 Pre-production, H2는 AB테스트 환경으로 배포, H3는 운영 환견으로 보면 되겠다.

  • 비트 토렌토를 이용하여 전세계 서버로 배포를 진행하며, 빌드에 15분, 배포에 약 15분이 소요된다. 예전 자료이기 때문에 현재는 훨씬 향상이 되었을듯.

  • IRC를 통해서 배포 상황 및 에러에 대해서 대응을 하고, 개발자가 IRC에서 수분내로 응답 하지 않을 경우에는 그 개발자가 개발한 코드는 빼고 배포한다.

  • 배포 후 모니터링을 시스템 뿐 아니라 페이스북 뿐 아니라 트위터와 같은 외부 SNS를 통해서도 배포 결과에 문제가 없었는지 등을 크롤링해서 모니터링 한다.

  • 배포에 있어서 문화는 문제가 생기면 롤백을 하기 보다는 빠르게 문제를 해결해서 재 배포 하는 방향으로 가고, 개발자에게 카르마(평판)을 부여하여 배포가 실패할때 마다 카르마를 깍고 카르마가 낮은 엔지니어는 릴리즈 엔지니어가 엄격하게 리뷰 한다.


플리커의 사례

  • 하루에 10번 배포를 하는데 이를 소개한 Youtube 영상이 유명하다고 하니 참고할것. 유투브는 못찾았고, 슬라이드 쉐어만 찾았는데, http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

  • 개발 코드, QA 코드, 그리고 인프라 설정 스크립트등을 하나의 SCM으로 합쳐서 모든 팀이 정보를 공유해서 문제를 찾아나갈 수 있도록 했다.


Etsy

  • Change behind flag 라는 기능을 제공해서 특정 기능을 끄거나 킬 수 있도록 했다. 배포 후 문제가 생기면 재 배포를 하는 것이 아니라, 이 플래그를 꺼서 해당 기능을 사용할 수 없게 하고 버그 수정후 빠르게 업데이트를 한다.


넥플릭스

  • 별도로 배포를 진행하는 팀이 존재한다.

  • 3개의 코드 브랜치를 사용 (Test, Release, Prod branch). 각 단계가 끝나면 다음 브랜치로 코드를 이동함.

  • 카날리 분석 (Canary analytics)

    • 예전 광산에서 나쁜 가스나 굉도 붕괴 전조를 알아내기 위해서 카나리아를 갱도속에 넣고 일했던 것에 착안

    • 운영 환경과 같은 환경 (Pre prod)환경을 만들어 놓고, HTTP status code, response time, load avg 등 약1000개의 지표를 모니터링 한 후, 100점 만점에 90점이 넘어야 배포를 승인.

    • 실제로 위메프에서도 이런 방식을 사용하였는데, 전체 노드중 한대의 노드에만 새 버전을 배포한후 뉴렐릭을 통해서 여러 지표를 모니터링 한 후 문제가 없으면 전체 서버에 배포하는 방식을 사용

  • 넥플릭스의 배포방식중 재미있는 점은 클라우드를 활용하기 때문에 기존 인스턴스를 사용하지 않고, 기존 인스턴스는 놔두고, 새로운 버전용 인스턴스를 새로 배포한 후, 문제가 없으면 새로운 인스턴스들로 트래픽을 돌리고 기존 인스턴스를 없애는 방식을 사용함.

  • 넥플릭스도 역시 배포중에 IRC 채널을 이용한 상황 공유


구글

  • SRE (Site Reliability Engineering)팀을 별도 운영, 운영 팀으로 넘기기 전에 문서,코드등을 리뷰 하는 단계의 관문 같은 팀.

  • 개발 완료 후 6개월 정도 개발팀이 운영하고, 운영 메뉴얼등을 첨부하여 SRE팀에 넘기면 SRE팀이 리뷰하고 오케이가 되야 운영팀으로 넘어감.

  • 페이스북의 카르마처럼, 구글은 팀단위로 Reliability budget 이라는 것을 부여 하여, 배포가 실패할때 마다 이 점수를 깎고, 이 점수가 0이 되면 SRE 팀의 리뷰를 다시 받은 후 점수를 다시 확보해서 배포를 하는 구조


참고할만한 내용들

발표 중간 중간에 참고하면 좋은 글과 책에 대한 소개가 있었다.  내용들이 좋은 것 같아서 일단 메모.

Lean Enterprise




린 스타트업과 유사하지만 다르게 일반 기업에 린 방법론을 적용할 수 있는 방법을 가이드 함

http://www.amazon.com/Lean-Enterprise-Performance-Organizations-Innovate/dp/1449368425/ref=sr_1_1?ie=UTF8&qid=1464945431&sr=8-1&keywords=lean+enterprise


The Phoenix project




http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=The+Phoenix+project


IT 소설로, 프로젝트를 진행하면서 겪는 일들을 풀어나감. Devops에 대한 내용도 있었다고 했던가?


기능 ON/OFF 인 Feature toggle 에 대한 마틴파울러 옹의 글

http://martinfowler.com/articles/feature-toggles.html


다양한 팀 모델에 따른 Devops 구조

http://web.devopstopologies.com/


사례를 통해서 볼 수 있는 인사이트

  • 큰 조직의 경우 배포 팀을 가지고 있는 경우가 많고, 이 경우 배포팀은 인프라 측면 뿐 아니라 코드 리뷰가 가능한 수준의 개발 능력까지 가지고 있는 경우가 많다.

  • 각 개발자에게 배포 포인트 (버짓, 카르마)등을 부여하여, 자주 배포가 실패하는 팀이나 사람에게는 엄격한 리뷰를 하도록 한다.

  • 배포 시에는 IRC또는 슬랙에서 상황을 공유하여 바로 대응한다.

  • 배포 실패시 롤백 보다는 빠르게 버그를 수정하며, 특히 기능을 On/Off 할 수 있는 기능을 제공해서, 버그 발생시 그 기능을 꺼 버린다.

  • Devops 모델은 그 팀의 구조에 따라 적절하게 구성할 필요가 있다. (devopstopologies)


김요섭 CTO도 계속 강조했던 내용이자만 DEVOPS는 기본적으로 자동화 도구와 함께 문화의 변경이 필수적으로 필요하다. 이 문화의 변경이 쉽지 않은데, 재미있는 문장을 인용한것이 있어서 메모한다.


“You can’t change culture directly, buy u can change behavior and behavior becomes culture.

“ (직접 문화를 바꿀 수 있지만, 작은 행동 하나하나를 바꾸면, 그 행동이 결국은 문화가 된다.)


시간이 없어서 질문을 하지는 못했지만 작은 토론 이라도 했으면 조금 더 배울 수 있었던 아쉬움이 남는다. 좋은 인사이트를 얻은 것에 대해서 만족하고 서점으로 책사러~~



저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

1편 글 링크 - http://bcho.tistory.com/815

Devops의 정의  

이러한 개념들을 적극적으로 적용한 기업들이 Netflix, Flicker와 같은 인터넷 서비스 기업이다. 기존 개발 프로세스에 비해서 훨씬 빠르게 고객의 요구 사항을 반영해 내가고 있다. Flicker의 경우에는 하루에 10번 정도 [1]Deploy를 한다고 한다. 일반적인 인터넷 서비스가 한달에 한번 업데이트 빨라야 일주에 한번인데, 하루에 10번이라면, 경쟁 구조 자체가 틀려진다.

PuppetLab (Configuration management 자동화툴)의 블로그[2]에 따르면 Devops를 적용할 경우,경쟁사에 비해서 30배 정도 더 자주 Deployment를 할 수 있으며, Deployment 실패 비율도 50% 이상이나 줄일 수 있다는 것이다.

그렇다면 이렇게 장점이 많은 Devops는 무엇인가?

일반적인 Devops의 정의는 개발과 운영이 분리되면서 오는 문제점을 해결하기 위해서, 개발과 운영을 하나의 조직으로 합쳐서 팀을 운영하는 문화이자 방법론이다앞에서도 설명하였듯이, 개발과 운영을 합치는 것이다. 조금 더 정확하게 이야기 하면, 개발 운영 뿐만 아니라 테스트까지 하나의 팀에 합치는 것이다.


[3]

상당 부분의 테스트는 이미 TDD (Test Driven Development), CI (Continuous Integration)를 통해서 개발 과정의 일부로 들어와 있는 경우가 많다.

Devops, “엔지니어가, 프로그래밍하고, 빌드하고, 직접 시스템에 배포 및 서비스를 RUN한다. 그리고, 사용자와 끊임 없이 Interaction하면서 서비스를 개선해 나가는 일련의 과정이자 문화이다.”

Puppet lab Devops Engineer에 대한 정의를 보면 조금 더 이 개념을 확장하고 있는 것을 볼 수 있는데, “사용자와 끊임 없이 Interaction” 하는 부분은 원론적으로 보면 개발자의 역할 보다는 기존에는 마케팅이나 고객 접점에 있는 서비스 기획자의 역할이었다.

“The DevOps engineer encapsulates depth of knowledge and years of hands-on experience,” Kelsey said. “You’re battle tested. This person blends the skills of the business analyst with the technical chops to build the solution - plus they know the business well, and can look at how any issue affects the entire company.” - See more at: http://puppetlabs.com/blog/what-is-a-devops-engineer#sthash.J5yNwCpX.dpuf

큰 의미에서 보면 단순히 개발,운영이라는 기술적인 접근 뿐만 아니라 사용자와의 의사 소통을 통한 서비스의 개선이라는 비즈니스적인 역할까지 확장한 개념이 된다.

기본적인 개념은 이해 했으리라 본다. 그렇다면 Devops의 실체는 무엇일까? Scrum이나 XP와 같은 방법론? 아니면 조직 체계? Devops는 팀운용 방법론이기도 하지만 정확하게 이야기 하면 문화이다. 개발 문화.

하나의 엔지니어가 멀티롤을 하면서 권한이 많아지게 되고, 예전 전통적인 소프트웨어 개발처럼 요구사항을 받아서, 개발하고 운영에 넘기는 개발 라인에 서 있는 하나의 리소스보다는 같이 생각하고 같이 서비스를 개발해야 하는 협업중심의 문화 체계로 바뀌게 되는 것이다. Devops는 하나의 방향을 제시 한다면, 이를 수행하기 위한 구체적인 방법은 팀에서 정의하고 만들어나가야 한다. (매뉴얼이 없다!!)

Devops의 특징

그래도 최소한 Devops를 적용하기 위해서는 어떻게 해야 할까? “팀을 합치고 문화를 바꾸세요.” 이건 너무 추상적이지 않나? 몇가지 제공되는 가이드 들이 있는데, 다음은 영국정부에서 제공하는 “Good Habit for Devops[4]의 내용을 정리한것이다. 기본적인 내용이지만, 참 많은 의미를 담고 있는 내용들이라서 몇번을 다시 생각해봐도 의미가 있는 내용이다.

     Cross functional team 하나의 팀에 각각 다른 역할을 할 수 있는 팀원들로 셋업해서 전체 End 2 End 서비스를 운용할 수 있도록 한다. 앞에서 개발자가 만능이되야 한다고 이야기 했지만, 그렇다고 만능 개발자로 전체 팀을 채워서 일을 하라는 것이 아니다. 개발자의 커버러지가 넓어지고 협업은 해야 하겠지만, 그렇다고 모든 개발자가 그렇게 수퍼개발자일리는 없고, 엄연하게 다른 역할이 존재 한다. 예를 들어, 테스트 엔지니어, 빌드엔지니어등.

단 여기서 Cross functional team이란, 한 팀내에서 서비스의 기획에서부터 운영 그리고 더 나아가서 영업등 해당 서비스에 관련된 모든 것 “ALL!!”을 할 수 있는 구조로 팀을 셋업 하라는 것이다.

     Widely Shared Metris 개인적으로 가장 중요하다고 생각하는 항목중의 하나인데, 팀 전체가 기준으로 삼을 수 있는 서비스에 대한 공통적인 지표 (Metric)이 필요하다. 서비스를 개발하고 개선했을 때, 이를 평가하고 현재의 서비스의 진행 상태 (성공 여부, 시스템의 안정성, 사용자의 반응 등)를 인지할 수 있는 기준이 필요하다는 것이다.

예를 들어, 일 방문자수, 평균 체류 시간, 가입자수와 같은 비즈니스 지표에서부터, CPU 사용률, 메모리 사용률, 응답 시간등 기술 지표등이 있다.

기존 개발에서는 요건 받아서 개발하고, 운영으로 던져버렸기 때문에, 사용자들이 서비스에 만족하는지 운영에는 문제가 없는지에 대한 피드백이 전혀 없었다. Metric을 팀 전체에 공유하고 꾸준하게 추적함으로써, 팀 전체가 서비스의 상태를 인지하고, 협업을 통해서 이에 대한 개선 작업을 진행할 수 있게 되는 것이다.

    대형 TV나 모니터등으로, 기본 서비스 및 시스템 운영 지표에 대해서는 사무실에 붙여 놓는 것도, 나쁘지 않다.

     Automating repetitive tasks 반복적인 작업을 툴을 이용해서 자동화 한다. 일반적으로 우리가 CI (Continuous Integration)이나 CD (Continuous Delivery)등을 이용해서 다루는 빌드, 배포, 테스트 자동화 들이 이에 속한다. 반복적인 작업의 자동화를 통해서 똑똑한 개발 자원들이 반복작업에 투여되는 시간을 줄여서 작업의 효율을 높이고 여기에 더해서 배포나 테스트에 관련된 시간을 줄여서 빠른 서비스 업데이트를 가능하게 하며, 마지막으로 이런 자동화 시스템 구축을 통해서 전체 시스템에 대한 이해도를 높일 수 있다.

     Post mortems 직역하자면 해부? 사후 검증 정도의 의미가 되는데, 장애나 이슈가 있을때, 처리 후에, 그 내용을 전체 팀과 공유해야 한다. 서비스를 운영하는 팀의 문제점은 이슈등에 대한 심각도가 얼마나 높은지를 인지하지 못하는 경우가 많다. 시스템이 정지되었을 때, 비즈니스 적으로 손실이 어떤지,얼마나 심각한 문제를 인지하고 궁극적으로는 원인을 파악함으로써 다음 부터는 같은 이슈가 다시 발생하지 않도록 할 수 있다.

     Regular release 마지막으로 정기 릴리즈이다. 시스템 릴리즈는 많은 협업이 필요한 작업이다. 개발도 끝내야 하고, 테스트, 배포 과정을 거쳐야 하고, 릴리즈가 끝나면 다음 릴리즈를 위한 기능 정의 등의 과정을 거쳐야 한다.  그래서 정기적으로 릴리즈 주기를 설정하면, 전체 협업을 하는 입장에서 언제 어떤 협업을 해야 할지도 명확해지고, 개발이 리듬(?)을 타게 된다.

첨언을 하자면, 짧은 주기의 정기 릴리즈를 통해서, 빠르게 서비스의 기능을 개선하고, 고객의 VoC를 반영해나갈 수 있다.

Devops 기반의 개발팀

Devops 기반의 서비스 팀은 End 2 End 서비스를 커버할 수 있어야 한다.

그리고 Devops는 개발과 운영을 포함한 팀 운영 방법론이라고 소개했었다. 그렇다고 기존 팀 모델에 개발과 운영만 합쳐 놓는다고 모든 문제가 해결 되는 것이 아니다. 다양한 Devops 기반의 팀 모델링이 있게지만, 몇 가지 레퍼런스를 소개하고자 한다.

영국 정부가 운영 하는 https://www.gov.uk/service-manual/the-team 에 역할이 잘 정리되어 있음. Scrum 방법론 기반이 아니라 익숙하지는 않지만, 유사한 팀 모델링. 100% 따라하기 보다는 레퍼런스. 개발뿐만 아니라 전체 비즈니스, 기획적인 면에서 많이 고려가 되어 있으며, 상세한 내용과, R&R, 그리고, Job Description까지 나와 있다. 

사실 디테일 자체는 다를 수 있지만 기본적으로 Devops 기반의 팀의 조직 구조는 대부분 유사하다.



전체 서비스를 관장하는 역할을 갖는 사람이 있다. Service Manager, Program Manager 보통 정의 하는데, 개발,운영뿐만 아니라 전체 서비스 기획, Stake holder등과의 Communication등 전체 프로젝트에 대한 전반적인 내용을 커버 한다.

Product manager가 중요한 역할인데, 서비스를 기획하고 요구 사항을 정의하며, 우선 순위를 메긴다. 기존의 개발 방식에서도 기획이 있었는데, 기존 기획은 요구 사항을 정의하고 개발에 넘기면 끝이었지만, 이러한 팀의 모델링 구조에서는 개발팀과 계속 협업하면서 모자른 요구 사항을 재정의 및 다듬어 나가고, 우선 순위를 끊임 없이 조정해 나간다.

UX Product manager와 아주 밀접한 관계에서, 서비스에 대한 UX 디자인을 프로토타입에서, 개발 단계까지 정의하고, 사용자의 피드백에 따라서, 끊임 없이 UX를 개선해 나간다.

그리고,실제 개발팀을 이끄는 Project Leader Scrum Manager가 있다. 일정관리, 개발 리소스 관리등을 담당한다. 또 전체 시스템에 구조와 틀을 잡는 아키텍트 역할이 있고, (아키텍트의 종류 - http://bcho.tistory.com/668 대규모 팀에서는 아키텍트도 역할을 나눌 필요가 있다.)

필요에 따라서 테스트 엔지니어를 별도로 두기도 하는데, 일반적인 기능 테스트 등은 개발자가 함께 테스트 케이스를 작성해서 자동화 해서 수행하는 경우가 많고, 경우에 따라서는 성능 테스트까지 함께 하는 경우가 있다. 성능 엔지니어링이 복잡한 경우에는 별도의 성능 테스트 엔지니어를 두는 경우도 있다.

빼먹기 쉬운 역할 중에 하나가 Contents Writer/Technical Writer인데, 서비스에 들어가는 컨텐츠에 대한 컨텐츠를 작성하고 리뷰등을 수행한다. 다국어 번역이나, 컨텐츠의 내용이 해당 서비스 국가에 문제가 없는지 까지 검증하는 역할을 한다. 일반적인 웹사이트에서는 웹 컨텐츠, 테크니컬 사이트의 경우에는 샘플 코드나, 가이드등의 작업을 한다.

마지막으로, 서비스 전략/user researcher라는 역할을 들 수 있는데, 이 역할은 Product manager보다 선행해서, 서비스나 제품이 나가야할 방향을 정의한다. 시장 상황을 분석하고, 수익 구조 및 비즈니스 모델을 정의하고, 주요 제품 로드맵을 정의한다. Product manager와 역할이 겹치는 부분이 있지만, Product managerdetail 한 서비스에 대한 기획은 서비스 자체 관점에서 한다면, user researcher는 조금 더 넓은 범위에서 제품의 방향과 비즈니스 및 수익 관점에서 서비스를 바라본다.

Devops 기반의 팀의 개발 싸이클

그렇다면 Devops 기반의 개발팀의 서비스 개발 싸이클은 어떻게 될까?

영국 정부가 운영하는 사이트 https://www.gov.uk/service-manual/the-team 의 가이드를 참고해 보면 다음과 같은 시나리오로 개발을 진행하도록 되어 있다.

     사용자의 needs 분석. VoC 수집

     사용자 스토리 작성 (요구 사항 작성)

     사용자 스토리에 대한 scope 정의 및 우선순위 지정

     Stakeholder에 대한 리포팅 및 관리 (내부 영업, 보고 등)

     다른 프로젝트와 연관성(dependency) 관리

     필요의 경우 솔루션 (오픈소스 또는 상용) 평가 및 도입

     개발!! (디자인, 빌드,테스트, 데모.-iterative way)

     테스팅. 실 사용자 대상 테스팅 포함

     서버에 배포

     Security 관리, Compliance 관리 (개인 정보 보호, 국가별 법적 사항 확인등)

     서비스 운영, 모니터링.

     대 고객 지원 (Customer Support) 추가 하였음

이런 프로세스를 한마디로 정리 해보면 결국 Devops 기반의 개발팀의 특징은, 한 팀내에서 모든 개발,테스트,배포 운영이 이루어진다는 것이고, 가장 중요한 것은, 운영을 통해서 사용자의 피드백을 접수하고, 이것이 새로운 요구 사항으로 연결되는데, 이 싸이클이 매우 빠르며 연속적이고 서로 연결 되어 있다 라는 것이다.



참고 : 개발팀의 성숙도별 개발 모델 http://bcho.tistory.com/721

조금 더 정리해서 말하자면 기존 개발팀은 기획팀이 요구사항을 개발팀에 던지고, 개발팀은 개발 내용을 운영에 던지는, waterfall 모델 처럼, 각 팀이 개발 단계별로 자기 역할을 한 후에, 다음 단계로 던지고 잊어 버리는 (fire & forget)  형태라면, Devops 형태의 개발팀은, 던지는 것이 아니라 과정 내내 같이 수행한다. 요구 사항을 개발팀에 넘겨도, 개발팀과 계속 협의를 하면서 요구 사항을 구체화 하고, 개선하며, 개발중에 운영인원과 같이 협의 하면서 최적의 구조를 논의 하면서 개발이 진행된다.

Devops 팀의 개발자의 필요 역량

그럼 Devops 엔지니어가 되고 싶다면? Puppet의 포스팅을 [5]보면 Devops engineer가 가져야 할 역량에 대해서 잘 설명이 되어 있다.

기본적인 소양으로는

Ÿ   코딩능력은 필수 이며

Devops 엔지니어는 기본적으로 개발자를 기본으로 하고 있기 때문에, 개발을 위한 기본적인 코딩 능력. 만약에 운영이나 시스템쪽에 치우친 엔지니어라면 자동화를 만들 수 있는 스크립트 작성 능력등은 필수이다.

Ÿ   다른 사람과 잘 협업하고 커뮤니케이션할 수 있는 능력

Devops는 앞서 설명한바와 같이 큰 틀에서 협업 문화이다. 시작 자체가 개발과 운영간의 소통 문제를 해결하고자 한것이기 때문에, 다른 팀원의 의견을 존중하고 문제를 함께 해결해나갈 수 있는 오픈 마인드 기반의 커뮤니케이션 능력이 매우 중요하다.

Ÿ   그리고 프로세스를 이해하고 때로는 그 프로세스를 재 정의할 수 있는 능력

마지막으로, Devops는 언뜻 보기에는 정형화된 프로세스가 없어 보일 수 있지만, 테스트 자동화, 배포, 그리고 요구 사항에 대한 수집 및 정의등은 모두 프로세스이며, 해당 팀의 모델이나 서비스의 성격에 따라서 만들어나가야 한다. 그래서, 프로세스를 이해하고 준수하며, 같이 만들어나갈 수 있는 능력을 가져야 한다.

필자의 경험상 위의 3가지는 정말로 중요한 요소인데, 많이 놓치는 부분같다. 특히 프로세스 부분에 대해서는 다들 제각각의 프로세스나 자기 사상으로 프로젝트를 진행해서 생기는 문제가 많아 보인다. 사실 프로세스를 지켜 나가는 건 어떻게 보면 귀찮은 일일 수 도 있지만, 같이 일하는 환경이라면 최소한의 기준은 필요하다고 본다.

이런 기본적인 소양 이외에, 몇가지 역량을 예로 들었다.

Ÿ   오픈소스 제품과 툴에 대한 이해

Ÿ   코딩 능력

Ÿ   인프라 시스템에 대한 이해와 시스템 운영 경험

ŸŸ   자동화된 툴 (컴파일,테스트,배포)에 대한 이해

   비지니스에 대한 이해

   오픈 마인드, 커뮤니케이션 및 협업 능력

그리고, Devops 팀의 엔지니어는 부족한 부분을 메꾸기 위해서 공부는 필수이다. 그 보다 더 중요한 것은 경험이다.. 운영은 직접 겪어 보기전에는 알 수 없다. 그리고 오픈 마인드 기반으로 커뮤니케이션을 해가면서 문제를 풀고 협업하는 능력은 책이 아니라 직접 겪어야 얻을 수 있는 능력이다. 

요즘 같이 비지니스 변화가 심하고 멀티롤 개발자가 필요한 시점에 Devops 를 수행할 수 있는 능력의 개발자의 가치는 점점 높아지고 있다. Mashable에 따르면 가장 빠르게 성장하고 있는 IT Job 중의 하나가 Devops Engineer이다. http://mashable.com/2013/11/13/fastest-growing-jobs/ 

Devops팀을 셋업 할때 주의할점

Devops 팀에 대한 확실한 정의나 가이드는 없다. 그럼에도 불구 하고, 여러 블로그나 몇몇 서적등에서 Devops의 개념에 대해 설명할때, Devops 팀 셋업시 주의할점을 몇가지 드는 것이 있다.

첫번째가 Devops 팀을 만들지 말것.
Devops 팀은 개발과 운영을 합쳐서 같이 운영하는 것이지 이를 위해서 개발과 운영을 모두 할 수 있는 팀을 새로 만들어서 개발팀과 운영팀 내에 배치하게 되면, 오히려 추가적인 burden을 더 넣는 것이다. Devops는 개발과 운영을 하나의 팀으로 합쳐서, 커뮤니케이션에서 오는 부하를 줄이기 위함임을 잊지 말자

Devops 엔지니어를 채용하지 말아라
여기에 대해서는 의견이 분분한 면이 있는데, 내 경우에는 이 의견에 어느정도 공감한다. Devops 엔지니어를 채용해서 팀을 Devops화 시킨다... 이건 한마디로 돈으로 Devops를 사겠다. 즉 돈으로 "문화"를 사겠다는 의미인데, Devops 엔지니어는 Devops 팀에서 일하는 하나의 사람일 뿐이다 Devops를 하려면 전체 조직 문화를 변경 시켜야 한다. 이는 한 두사람의 엔지니어를 채용한다고 되는 일이 아니라. 경영자가 이에 대한 확실한 의지를 가지고 있을때, Devops에 대해서 외부로 부터 가이드나 도움은 받을 수 있겠지만, 어떻게 문화를 바꿀 수 있는지에 대해서 접근하고, 조직 내부에서 부터의 문화 변경을 시도하는 것이 좋다. 경영자가 Devops에 대한 이해가 없고, 단기간내에 성과를 내려고 한다면, 글쎄.. 개인적인 생각으로는 성공하기 쉽지 않으리라 본다. 이미 애자일 방법론을 적용할때, 경영자의 이해와 강력한 스폰서 쉽 그리고 문화의 변경을 기다려 주는 인내가 없는 경우 도입에 실패하는 경우를 숱하게 봤다. 이런 문화적인 변화는 수동적으로 시킨다고 되는것이 아니다. 조직 전체에 공감대가 형성이 되고, 능동적인 자세 아래서, 변화가 가능한 것이다.
재미있는 사례가 있는데, 쿠팡(소셜커머스 업체)가 많은 개발자가 있음에도 불구하고, 1년여간에 걸쳐서 애자일 방법론을 성공적으로 도입한 사례이다. http://blog.naver.com/coupang1104/140200775250
Devops는 아니지만, 문화를 변경한다는 관점에서, 주목해볼만한 사례이다.

Devops 팀에서는 개발자가 개발 및 운영을 다한다? 아니면 별도의 운영자가 있다?
사실 Devops에 대한 개념을 잡는 것중에서 가장 헷갈렸던 부분이 부분인데, 개발팀과 운영팀을 합쳐서 하나의 팀을 만들었다고 하자. 그러면. 개발자가 개발 및 운영을 다하는 것인가? 아니면 그 안에서도 개발과 운영롤을 나눠야 하는 것인가?
사실 내 대답은 "그때 그때 달라요"이다. 팀내에 개발하는 사람이 운영을 다할 수 있으면, 개발자가 운영까지 하는 모델로 가는 것이고, 기존 팀이 개발과 운영으로 갈려 있었다면, 팀내에서도 개발롤과 운영롤로 나누되, 둘간의 협업을 잘 만들어내는 것이 관건이다.
사실 결과적으로는 개발역할과 운영 역할이 팀 내에서도 나눠 질 수 밖에 없다고 본다. 개발자의 역량 한계상, 모든 것을 다할 수는 없고, 각자 선호하는 분야가 있기 때문이다.

Devops의 경우 소규모 스타트업 기업에 유리. 조직이 큰 경우 인내심을 가지고 차근차근 적용해 나가야
소규모 스타트업의 경우 개발과 운영팀을 분리할 규모도 안되서 각각의 엔지니어가 여러 역할을 동시 수행해야 하고, 빠른 개발 주기를 가지고, 개발 문화를 초반 부터 만들어나가야 하는 단계이기 때문에, 매우 적절하다고 볼 수 있다. 그러나 이미 크기가 커버린 일반적인 개발팀의 경우에는 전체 문화를 바꾸는 것 자체가 모험이다. 단기적인 전략보다는 장기적인 전략으로 Devops라는 문화 변경 프로젝트를 바라봐야 할것이며, 또한 그 변화의 기간동안 인내심 있게 이를 지원해줄 조직의 경영층이 필요하다.


한마디로 Devops란 개발과 운영을 합쳐서 하나의 조직내에서 서비스를 독립적으로 개발 및 운영할 수 있는 협업 체계이자 개발 문화라고 정의할 수 있다. 

참고 자료들

l  Atlassian Devops 관련 자료 - https://www.atlassian.com/devops/

l  What is Devops engineer? - http://puppetlabs.com/blog/what-is-a-devops-engineer

l  What is Devops ? http://dev2ops.org/2010/02/what-is-devops/ (개념 정리가 제일 잘되어 있음)

l  Jez Humble의 Continuous Delivery를 번역한 사이트 -   http://cdkr.egloos.com/




저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

기존 개발 체계의 문제점

전통적인 개발 운영 체계

일반적인 개발 운영 체계는 다음과 같다. 개발팀에 의해서 개발이 끝나면, 시스템은 테스트를 거쳐서 운영팀에 이관되고, 운영팀은 해당 시스템을 배포 관리 운영한다.



일단 이관된 시스템은, 개발팀이 일체 관여하지 않고, 운영팀에 의해서 현상 유지 된다.


문제점 1. 누구의 잘못인가? 불행의 시작

시스템을 운영하다 보면, 반드시 장애가 생기기 마련인데, 문제는 여기부터 시작된다. 개발은 애플리케이션 있지만, 아랫단의 인프라 시스템 있는 능력이 없다. 반대로 운영팀은 인프라 시스템 알지만, “애플리케이션자체에 대해서는 모른다.

그러다 보니, 서로 자기 분야의 문제가 아니라고 하면서 서로 책임 미루기를 하게 되고, 문제 해결은 지연된다. 이러한 책임 미루기에 대해서 “Fingerpointyness”라는 말로 표현한 것이 있는데, 정확하게, 누가 어떤 문제를 해결해야 하는지 정의 되지 않은 상황에서, 협업이 없어지고 문제 해결이 엉뚱한 방향으로 가는 현상이다.


[1]

    Freaking out & find fault 단계 (문제 발견)

자아. 문제가 발생했다. 문제의 내용을 먼저 파악한다. 이때 협업은 없다. 단지 자기 분야에서 문제가 어떤 것인지, 한정된 지식으로 현상 자체를 인지하는 수준이 된다. 근본적인 문제에 대한 원인 파악보다는 대충 파악하는 단계 정도의 수준이 된다. 단계에서 누가 문제를 파악할지에 대한 owner ship 자체가 정해지지 않는다.

    Blaming Covering ass 단계 (욕하기)

그러다가, 어느 정도 문제의 현상 (정확한 원인이 아니라) 정도가 파악되면, 서로 미루기를 한다. “애플리케이션 문제네..”, “데이터 베이스 문제네..” 식으로, 정확한 원인 파악 없이 자기 문제가 아닌 처럼, 다른 쪽으로 미루기를 시작하면서, 상대편을 욕하는 단계가 된다. “데이터 베이스 구성을 그렇게 하니까는 그렇지.. 인덱스는 아냐?”. 내지는 애플리케이션 구조에 맞춰서 배포는 한거야?” 이러면서 문제의 근본적인 원인은 해결되지 않고 시간은 계속 간다.

    Whining, Hiding. Hurt Ego 단계 ( 상처 입기)

계속 해서 문제를 서로에게 넘기다 보면, 문제를 숨기거나 상대방을 헐뜯거나 하면서 결국은 서로 상처를 입게 되고, 점점 커뮤니케이션은 없어지고 관계는 악화되어 간다.

    Figuring it out (문제 원인 분석)

결국 문제를 해결해야 하는 시간이 가까워 오면, 문제를 풀긴 풀어야 하니,  어떻게든지 스스로 서로 모여서 문제를 같이 보게 되거나, 상위 메니져를 통해서 강제적으로 같이 모여서 문제에 대한 원인 분석을 해서 결국은 원인을 파악하게 된다.

    Fixing things (문제 해결)

그리고, 결과적으로 원인 파악 문제가 해결된다.

아주 전형적인 개발과 운영간의 장애 처리 프로세스이다. 그나마 똑똑한 팀장을 가지고 있는 조직은 장애나 문제가 발생했을때, “모두 모이세요.”해서 초기부터 문제를 같이 보고 해결하거나, 개발팀이나 운영팀 자체가 상대방의 분야를 있는 능력을 갖춰서 문제를 해결하는 경우가 많다. 예를 들어 운영팀이 애플리케이션에 대한 장애 대응 능력을 갖거나, 개발자가 OS, 데이타베이스 또는 미들웨어등에 대한 인프라 운영 능력을 갖는 경우이다.


문제점 2. 운영 이슈에 대한 전달 문제

다른 문제점을 살펴보자, 앞에서도 언급 했듯이, 개발은 운영으로 이관 후에, 서비스에 대해서 이상 관심을 갖지 않는다. 그리고, 고객과의 접점도 거의 없다. 그러나 운영은 (단순히 시스템을 운영하는 시스템 운영만이 아닌 실제 서비스 운영을 포함) 계속 해서 사용자와 interaction 하고, 사용자로부터 끊임 없이 VOC (Voice Of Customer) 받는다.



서비스를 운영하는 입장에서, 사용자의 의견을 들어서 서비스를 개선하고 싶은 것은 당연한 이치이고, 여러 VOC 모아서 개발팀에 서비스 개선 요청을 하지만, 이미 개발과 운영은 멀어져있는 상태이고, 운영은 명시적으로 개발팀에 요구 사항을 정의할 있는 권한이 없기 때문에 (이러한 권한은 일반적으로 서비스 기획팀에서 갖는다). 이러한 개선 요청 요구 사항은 개발팀 입장에서는 추가적인 일이 되고, 개발팀은 이러한 신규 요구 사항에 대해서 저항하거나 또는 거절하게 된다.


문제점 3. 변경 요건

서비스가 운영 배포된 후에도, 비즈니스 (기획팀) 의해서, 계속 해서 서비스에 대한 신규 요구 사항은 나오게 되고, 새로운 변경 요건은 신규 개발과, 테스트 배포 그리고 지속적인 운영을 요구 하게 된다.



그런데, 근래의 서비스들의 경우에는 빠른 비즈니스 환경 변화에 따라가기 위해서 많은 변경 요구하게 되고, 이는 필연적으로 잦은 변경 배포를 요구 하게 된다. 제대로 많은 변경으로 인하여 제대로 테스트 시간을 거치지 못한 애플리케이션의 경우에는 잦은 장애를 유발한다.

이런 배경으로 인해서 운영팀은 잦은 배포를 꺼려하게 되고, 조금 전통적이고 형식적인 관점에서 주기적인 릴리즈와 테스트를 요구하게 된다. 애플리케이션단에 문제가 있다 하더라도 긴급 배포가 어려운 경우가 많고, 긴급 배포를 했다 하더라도, 개발팀의 실수를 뒷처리 하는 입장으로 인식하기 때문에, 계속 해서 개발팀과 운영팀의 관계는 악화 되어 간다.


그러면 해결책은?

그렇다면 구조적으로 이렇게 개와 고양이처럼 앙숙일 밖에 없는 개발팀과 운영팀과의 관계는 어떻게 해결 것이며, 문제로 인해서 발생하는

         서비스 요구 사항의 신속한 반영의 문제

         고객의 요구 사항에 민감한 소프트웨어 개발

문제들은 어떻게 극복할 있을까?


Solution 1. 협업 하자  - 기획과 개발을 합치자.

답은 간단하다. 기획,개발,운영 모두 사이좋게 지내면 된다. 어떻게 사이좋게? 서로 대화도 많이하고 팀웍을 다지면 된다. 이런 활동의 일환으로 시작된 것이 애자일 방법이다. 기획팀과 개발팀을 하나의 팀으로 합쳐서, 요구 사항 변화에 빠르게 반응할 있는 구조로 바꾸고, Iterative 개발(반복적), Short Release 이용한 잦은 릴리즈를 통해서 비즈니스의 요구 사항을 신속하게 반영하고, 변화에 대응할 있는 구조를 갖추는 것이다.


Solution 2. 개발과 운영을 합쳐 버리자. (Devops)

첫번째 솔루션은 분명히 좋은 방법이긴 하지만, 조금 최적화 시킬 수는 없을까? 애자일 방법론을 적용해도 여전히 운영과 개발은 앙숙인 관계이다. 그렇다면? 기획과 개발을 합쳐 버렸듯이,


좋은 개념을 이제야?

간단하게 개발과 운영을 합쳐 버리면 될텐데, 이걸 이제서야 할까? 결론부터 이야기 하면, 예전에는 어려웠다. 개발과 운영은 영역 자체가 매우 상이하고, 요구 되는 기술 능력도 많이 차이가 나기 때문에, 일반적인 엔지니어가 양쪽을 모두 커버하기가 어려웠다.

또한 기술 자체에 대한 습득 경로가 교육이나 서적으로 제한 되어 있었고, 인터넷을 통해서 요즘 처럼 이렇게 쉽게 정보를 얻기가 어려웠다.


인터넷의 발전

인터넷은 더욱더 발전해서, 내가 필요한 자료는 인터넷에서 찾을 있을뿐만 아니라, 오픈소스 커뮤니티에서 남들이 만든 코드를 보고 배울 있고, YouTube에서 강의를 들을 있으며, Slideshare에서 요약된 PPT 있다. 지식을 습득할 있는 채널이 다양해지고, 쉬워졌다.


오픈 소스의 발전

인터넷이 발전되면서, IT 흐름이 크게 바뀐 것중에 하나는 이상 오라클이나 IBM 같은 대형 벤더 주도의 기술이 아니라 페이스북이나 구글과 같은 거대 B2C 서비스가 IT 흐름을 이끌기 시작했고, 이러한 업체들이 오픈소스를 적극적으로 후원 장려하기 시작했다. 오픈 소스를 통해서 전세계의 개발자들과 함께 이야기를 , 일을 있고 오픈 소스를 잘하면 이런 구글이나 페이스북과 같은 좋은 회사에도 취직할 있다. 그래서 개발자들이 오라클이나 SAP 같은 엔터프라이즈 제품을 공부하지 않고, 오픈소스를 개발하면서 논다(enjoy~)”


오픈소스 Stitching

이렇게 오픈소스가 발전하다 보니, 요즘 개발은 하나의 프로그램 언어로 하나부터 열까지 모두 개발하는 것이 아니라, 여러 오픈소스들을 모아다가 합쳐서, 하나의 서비스를 만드는 형태로 바뀌고 있다

이제 모두 내가 개발할 필요도 없이 찾아서 조합 하면 되고, 문제가 있는 오픈소스는 내가 직접 고치거나, 오픈 소스 개발자들에게 부탁해서 수정을 할 수 있다. 솔루션에 대한 선택 기회가 넓어지고,  코드 자체 개발 뿐만 아니라, 효율적으로 오픈소스 솔루션을 조합 및 구현하는 개발 형태의 중요성이 높아지고 있다.


좋은 도구들

오픈소스의 발전으로 이루어진 혜택중의 하나가, 좋은 툴이 많아 졌다는 것이다. 개발에 관련된 뿐만 아니라, 빌드,배포에 대한 툴과, 모니터링에 대한 툴도 많아졌기 때문에, 운영 업무에 해당 하는 이런 부분을 상당 부분 자동화를 있다.


클라우드의 등장

클라우드 컴퓨팅의 가장 특징 중의 하나는 사용자가 인프라 (서버 설치, 네트워크 케이블 구성) 구성할 필요가 없이, 간단하게 책상 앞에 앉아서 웹사이트를 몇번 클릭 하는 것만으로 지구 반대편의 데이터 센터에 서버, 스토리지 구성, 네트워크 구성이 가능하게 되었다는 것이다.

이상 개발자는 새로운 기술을 익히는 , 책을 뒤져가면서, 새로운 교육을 들어가면서 지식을습득할 필요가 없다. Googling 하면 개발에 대해 필요한 자료를 얻을 있다.

개발을 할때는 필요한 모듈을 오픈 소스를 조합해서 만들 있으며, 여러가지 좋은 도구들을 통해서 빌드나 배포등을 손쉽게 자동화할 있으며, 클라우드를 통해서 개발자도 네트워크, 서버등에 대한 설정들을 있다. 인프라에 대한 지식이 부족하면 이것 또한 인터넷을 검색하면 된다.  결과적으로 개발자가 있는 영역이 더욱 넓어졌다.

바꿔 말하면, 인프라에 대한 전문 지식이 없이도, 인터넷과 오픈 소스 그리고 클라우드의 도움을 받아서, “운영 겸업 있는 환경이 마련 되었다는 것이다.

2편 글 링크 - http://bcho.tistory.com/817


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Continuous Deployment 
(Auto Deployment)


빌드와 테스트까지 자동화 했으면 그 다음 문제는 배포이다.

수동으로 배포하는 경우 한 두개의 서버라면 별 걱정이 없겠지만, 개발,테스트,운영 환경과 같이 여러 환경에 또한 각 환경에 수십대의 서버에 배포를 해야 한다면, 문제는 달라진다. 그래서 요즘에서 CI에 배포의 개념을 더한 CD (Continuous Delivery 또는 Continuous Deployment)라는 개념이 유행하는데, 이는 빌드가 완료된 후, 배포까지 자동화 하는 방법이다.



이런 배포를 지원하는 도구는 여러가지 타입이 있다.

   특정 솔루션에 종속적인 도구

Tomcat이나 WebLogic 같은 WAS의 경우 각 제품에 특화된 배포 도구를 가지고 있다. Tomcat의 경우 Tomcat Client Deployer (http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html#Deploying using the Client Deployer Package ) 와 같은 도구가 있는데, Remote에서 war 파일을 배포해줄 수 있는 도구 이다.

이러한 도구들의 특징은 해당 솔루션에 최적화가 되어 있기 때문에, RunTime Deploy나 기타 해당 솔루션에 특화된 기능을 활용할 수 있기 때문에, 안정적인 배포가 가능하다는 장점을 가지고 있다.

그러나 반대로 솔루션에 관련된 애플리케이션 파일만 배포할 수 있다는 단점을 가지고 있다. 무슨 이야기인가 하면, war 파일 이외에, 다른 디렉토리에 configuration 파일을 배포하고 싶을 경우, 이런 파일들은 배포가 불가능하다는 것이다. 또한 여러개의 인스턴스에 동시 배포를 하고 싶을 때, 인스턴스들이 제품에서 제공하는 클러스터링 기능등을 사용하고 있지 않을 경우, 각 인스턴스들을 일일이 각각 배포해야 하는 단점이 있다. 쉽게 말해서 매우 제품에 종속적이라는 것이다.

   Configuration Management

다음으로는 Puppet이나 Chef와 같은 Configuration Management 도구 기반의 배포 방식이 있다. 이러한 도구들은 원래 태생이 Deployment보다는 초기 솔루션을 설치하거나, 다수의 서버나 솔루션에 대한 Configuration 정보를 중앙 관리하기 위해서이다. 이에 비해서 Deploy 과정은 대부분 파일을 복사하고 서버를 restart 시키는 과정 정도의 단순 작업이기 때문에, 만약에 이러한 Configuration Management 인프라를 갖추고 있거나, 또는 배포 과정이 솔루션의 설정을 포함하여 매우 복잡한 경우 일때는 매우 효율적으로 사용될 수 있으나, 반대로 이러한 인프라가 없는 상태에서 단순한 배포만하고자 할 경우에는 오히려 배보다 배꼽이 커질 수 도 있다.

   Remote Shell 기반의 도구

마지막으로, Remote Shell 기반의 배포 도구가 있다. SSH RSH과 같은 명령을 툴로 실행시켜 주는 도구 인데, 파일 복사에서 부터 커맨드 라인에서 입력하는 명령들을 원격으로 실행시켜 준다.

솔루션에 종속적이지 않으며 또한 자유도가 높으며 사용이 매우 편리하다.

Python 으로 된 도구로는 Python Fabric이라는 도구가 있고, Ruby쪽에서는 Capistrano라는 도구가 있다.

Case Study

필자의 경우 클라우드 프로젝트 이전에만 해도, 환경 자체가 그리 크지 않았기 때문에, 웹로직이나 Tomcat의배포 툴을 사용해서 배포를 진행했었다. 클라우드 환경 기반에서 프로젝트를 진행하고 또한 진행하는 프로젝트의 규모가 커짐에 따라서 이러한 배포 자동화가 꼭 필요하게 되었는데, 이 배포는 Configuration Deployment 두 가지로 나눠서 생각해볼 수 있다.

애플리케이션을 배포하기 전에 먼저 OS Tomcat과 같은 솔루션을 설치 하는 Configuration, 그 다음이 이 환경 위에 애플리케이션을 배포하는 Deployment이다.

Configuration의 경우에는 Puppet이나 Chef를 도입하고 싶었으나, 팀의 규모와 시간 관계상 도입이 어려웠고, 환경의 복잡도가 낮아서 별도의 Configuration management 도구는 도입하지 않기로 결정하였다.

대신 OS Tomcat Pre-install된 표준 VM 이미지를 만들어 놓고, 배포가 필요할때 마다 이 이미지를 Loading한 후에, 애플리케이션을 Deployment 하는 형태를 사용하였다.

이 방식은 표준 이미지를 만들어 놓고 계속 재 사용하기 때문에, 관리가 쉽지만 반대로 Configuration을 변경하고자 할 때, 이미 배포된 이미지들에 대한 Configuration을 일일이 다시 변경해야 하는 단점이 있다. (어느 정도 규모가 되면 Configuration Management 도구로 넘어가는 것이 좋은듯 하다.)

Fabric을 이용한 배포

그러면 Fabric을 이용한 Tomcat 애플리케이션에 대한 간단한 배포 시나리오를 살펴보도록 하자.

구성은 아래와 같다. Load Balancer 아래에 N개의 Tomcat 인스턴스들이 연결되어 있는 구조 이고, 배포는 다음과 같은 순서를 따르도록 한다.

   먼저 배포하고자 하는 Tomcat 인스턴스를 Load Balancer에서 제외한다.

   다음으로 배포하고자 하는 인스턴스를 Stop한다.

   배포하고자 하는 war 파일을 해당 Tomcat 인스턴스에 복사한다.

   그리고 해당 Tomcat 인스턴스를 리스타트한다.

   위의 1)~4) 과정을 다른 인스턴스에도 반복한다.



이 배포 방식은 간단하기는 하지만, 하나의 서비스내에서 배포 과정중에, 배포가 완료된 인스턴스와 배포 예정인 인스턴스에 애플리케이션이 다르기 때문에, 애플리케이션 변경이 많은 경우에는 적용하기가 어렵다 . 대규모 변경이 있는 경우에는 전체 클러스터를 내렸다가 전체 배포 후 서비스를 다시 시작하는 방식을 사용해야 하는데 이 경우에는 배포 중에 서비스에 대한 순간적인 정지가 발생할 수 있다.

무정지 배포 아키텍쳐

이런 문제를 해결 하기 위해서 일부 자바 기반의 application server의 경우 runtime redeployment (시스템을 운영중에, 정지없이 프로그램을 변경하는 행위로, 일부 자바 기반의 application server에서는 WAR와 같은 웹모듈이나, EJB 같은 모듈을 시스템을 무정지 상태로 재 배포 할 수 있는 기능을 제공한다.) 를 제공하는 제품들이 많다. redeployment 의 원리는 새로운 application load하고, classloader reload하는 형식인데, classloader reload이 위험도가 높은 작업이기도 하고, application을 작성할때, redeploy를 고려하지 않은 경우 정상적으로 runtime redeploy가 되지 않는 경우가 많다. 가장 확실한 redeploy 기법은 application server를 정지시킨후, 재배포한후에 restart하는 것이 가장 안정적이다. 이렇게 restart기반으로 redeploy를 할때, 시스템을 정지 상태를 최소화는 구조를 무정지 배포 아키텍쳐라고 하는데, 구조는 다음과 같다.




application server를 두개의 클러스터 그룹으로 나눈후, 각 클러스터 앞에 reverse proxy를 각각 배치 시킨다. 그리고 reverse proxy 앞에는 L4 스위치를 둬서 각 클러스터로 load balancing을 할 수 있도록 한다.

배포를 할 때는 Cluster A 앞에 있는 reverse proxy를 정지 시킨다. 이렇게 하면, 앞단의 L4 로드 밸런서에서 Cluster A request를 보내지는 않으나, Cluster A 자체는 살아 있다. 그 후에 Cluster A의 각 인스턴스에 애플리케이션을 재 배포 한후,Cluster A reverse proxy를 재기동 시킨다. 마찬 가지 방법으로 Cluster B에도 같은 방법으로 redeploy를 수행한다.

이 구조를 택하면 전체 서비스 중지 없이 그리고 애플리케이션 변화에 대해서 일관성 있게 한꺼번에 재 배포가 가능하다.

Fabric을 이용하여 AWS Tomcat war 파일 배포 하기

그러면 실제로 Fabric을 이용해서 어떻게 배포를 할 수 있을까?

다음은 아주 간단한 Fabric을 이용한 배포 스크립트 이다.

순서는 tomcat stop > copy war > start 와 같다. EC2상에서 pem (SSH)를 이용하여, 두대의 Host deploy하는 스크립트이다.

#fabfile.py

from fabric.api import run,env,execute,task

from fabric.operations import local,put

 

def tomcat_cluster():

        env.user ='root'

        env.hosts=['host1.server.com','host2.server.com'] # list of server setting

        env.key_filename='~/pem/pemfile.pem' # pem file

 

def hostname():

        run('uname -a')

 

def start():

        run('/etc/init.d/tomcat6 start')  # tomcat instance stop

 

def stop():

        run('/etc/init.d/tomcat6 stop') # tomcat instance stop

 

def copy():

        put('./dummy.war','/root/war') # file copy

 

def deploy():

        execute(stop)

        execute(copy)

        execute(start)

 

해당 파일을 fabfile.py에 저장후에

%fab tomcat_cluster deploy

명령어로 실행을 하면 아래와 같은 순서로 배포가 진행된다.

host1.stop()

host1.copy()

host1.start()

host2.stop()

host2.copy()

host2.start()

 

위의 예제는 Fabric의 설명을 하기 위한 아주 간단한 예제로, 필요에 따라서 수정해서 사용하기 바란다.

앞의 예제에서는 간단하게 war 파일만을 복사하는 형태로 배포 스크립트를 작성하였지만, maven 설명할때 언급했던 것 처럼, 기타 Configuration 파일을 함께 배포하고, roll back이나 버전 관리가 용이하게하기 위해서 rpm 형태로 배포하는 것을 권장한다. 또한 rpm 파일을 관리하기 위해서 내부적으로 자체 yum repository를 만들어서 관리하는 것이 좋다.

배포에서 고민해야 할것 들

배포주기

근 몇 년전만 해도, 배포는 몇 달간의 개발이 끝나면 테스트를 거쳐서 특정한 날짜를 잡아서 대규모 배포를 형태가 일반적이었다.

그러나 근래에는 전체적인 IT 트렌드가 SNS와 같은 B2C 서비스가 중심이 되면서, 경쟁 서비스에 비해서 좋은 서비스를 빠르게 제공하기 위해서 업데이트 주기가 매우 짧아지고 있다. 이런 이유에서 배포도 자동화가 필요하게 되었고 Continuous Delivery와 같은 개념이 근래에 유행하게 된것일 수도 있는데, SNS 서비스의 경우 빠르면 하루 단위로 배포하는 경우 까지 있다.

배포 주기가 짧은 경우에는 몇 가지 더 고려할 사항이 있는데, 배포는 코드 개발보다는 인프라 관리나 빌드에 관련된 부분이 많다. 그래서 배포의 주체는 이런 운영 주체가 되는 경우가 일반적인데, 배포시 문제가 생기는 경우가 있을 시에는 개발팀의 도움이 필요하고, 배포가 정상적으로 되었을 경우에는 개발팀으로 부터의 확인등이 필요하기 때문에 조직 구조상 운영팀과 개발팀이 분리된 조직에서는 잦은 배포가 여러가지로 어려운점이 많다. 그래서 근래에는 이런 개발과 운영 조직을 합쳐서 개발팀을 운영하는 DevOps (Deveopment + Operation)형태의 조직구조로 전환하여 개발,배포,운영을 통합하여 관리 하는 쪽으로 이동하고 있다.

이 경우 단순히 조직을 합치는 것뿐만 아니라 개발자에게는 인프라나 운영에 대한 이해 능력을 그리고 운영팀에는 개발에 대한 어느정도 선까지의 능력을 요구하게 되고 업무 프로세스등의 변화가 필요하기 때문에 조직을 융합시키는 차원이 아니라 조금 더 높은 수준의 접근이 필요하다.  

수동 배포

운영 환경 배포는 반드시 수동으로 하는 것을 권고한다.

지금까지 자동으로 배포하는 방법을 설명해놓고, 왠 갑자기 수동 배포를 언급하는가 싶을 수도 있을텐데, 이유는 다음과 같다.

배포는 앞서 본 것과 같이 쉘 명령등을 수행해서 여러가지 명령 (Shutdown, Copy, Restart)을 동시에 여러 서버에 수행한다. 즉 중간에 에러가 날 가능성이 매우 높다.

그래서 배포 작업을 수행할때는 반드시 사람이 지켜보면서 배포 스크립트를 수행하는 것이 좋다. 개발환경이나 QA 환경 같은 경우에는 거의 업무 시간에 빌드를 하면서 배포가 수행이 되기 때문에, 배포 오류가 났을 경우에는 사람이 인지하기가 쉽고, 에러가 났을때 서비스에 직접적인 영향을 주지는 않는다. 그래서 개발이나 QA 환경 같은 경우에는 사람이 지켜보지 않고, CI 프로세스의 일부로 빌드 테스트가 끝나면 자동으로 배포를 하도록 해도 된다.

그렇지만 운영 환경의 경우에는 서비스에 직접적인 영향을 주기 때문에, 반드시 사람이 지켜보면서 수동으로 배포를 시작 및 모니터링 하도록 하는 것이 좋다.

배포 roll back

서비스에 대한 배포시, 테스트를 아무리 잘했다하더라도, 에러가 발생할 수 있다.

에러가 발생하였을 때는 이전의 버전으로 신속하게 roll back할 수 가 있어야 하는데, 이렇게 하기 위해서는 애플리케이션의 이전 버전을 반드시 저장하고 있어야 하고, 배포 스크립트 역시 예전 버전을 다시 배포할 수 있는 기능을 구현해야 한다.

릴리즈 노트

마지막으로 배포가 끝나면 반드시 릴리즈 노트를 작성 및 함께 배포하는 것이 좋다.

배포란 개발이나 운영이 주로 주도하는 작업이기 때문에, 비지니스 쪽에서 필요한 기능 변화에 대한 릴리즈 노트의 중요성을 잃어 버리는 경우가 많은데,  서비스가 변경이 되었을때, 어떠한 기능이 추가 되었는지, 그리고 어떠한 버그가 FIX가 되었는지를 사용자에게 알려줄 필요가 있으며, 특히 서비스를 판매나 영업하는 입장에서는 어떤 변화가 있었는지를 확인하는 것이 중요하기 때문에, 이 부분을 반드시 챙기도록 한다.

릴리즈 노트는 배포 되는 대상 (독자)에 따라서 다르게 작성되야 하는데,

내부 릴리즈 노트는 다음과 같은 내용이 포함되는 것을 권고한다.

Ÿ   릴리즈 버전, 날짜 및 빌드 넘버

Ÿ   새로운 기능 및 설명

Ÿ   버그 number 및 버그 수정 내용

또는 JIRA와 같은 Tak Management 도구를 사용하는 경우, JIRA에 등록된 기능이나 Bug 수정 내용을 릴리즈 시기에 자동으로 JIRA로 부터 생성해 낼 수 있다. (JIRA에서 릴리즈 노트 생성하기 https://confluence.atlassian.com/display/JIRA/Creating+Release+Notes)

만약 서비스나 제품 사용자를 대상으로 하는 경우, 위의 릴리즈 노트의 내용을 사용할 수 도 있지만, 조금 더 직관적이고 읽기 쉬운 형태로 릴리즈 노트를 작성하는 것이 좋다.

다음은 몇몇 잘 정의된 릴리즈 노트의 샘플이다.

Ÿ   안드로이드 릴리즈 노트 : http://developer.android.com/sdk/RELEASENOTES.html

Ÿ   Fire Fox 릴리즈 노트 http://www.mozilla.org/en-US/firefox/23.0.1/releasenotes/

Ÿ   Maven 릴리즈 노트 http://maven.apache.org/release-notes-all.html

릴리즈 노트는 청중들에게 이번 릴리즈 기능의 변경 사항을 제대로 알리기 위함이다. JIRA와 같은 시스템의 기능을 이용하건, 아니면 일일이 손으로 새로 쓰건간에 반드시 보는 사람이 어떤 변화가 있었는지 쉽게 이해할 수 있는 형태라야 한다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Flume, Flumed

rsyslog + logwatcher

sentry + https://github.com/kencochrane/raven-java

splunk

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

오랜만의 포스팅입니다. 그간 많이 바뻤습니다.

요즘 시스템 운영쪽에 관심이 많아서 Devops (Development + Operation)쪽을 틈틈이 보고 있습니다. 오늘은 조직의 성숙도별 개발 모델과 함께, CD (Continuous Delivery)와 Devops에 대해서 설명해보고자 합니다.



회사의 규모나 성숙도에 따라서 개발 모델을 크게 다음과 같이 3단계로 나눠볼 수 있습니다.


1. 스타트업


소규모에 처음 서비스 개발을 시작한 스타트업 기업 같은 경우에는 일단 모든 의사 결정이 빠르다. 아이디어가 나오면 별도의 승인이나 분석 없이 바로 개발하고, 개발이 끝나면 바로 배포 한다. 규모가 작고 모든 의사 결정이 팀내에서 이루어지기 때문에 매우 빠르다. 그리고 인력이 적기 때문에, 분석/설계/개발 및 운영이 같은 그룹에서 이루어진다.


2. 성숙된 개발 조직

어느정도 조직이 성숙되고, 인원이 많아지고 이익에 대해서 고민을 하게 되면, 조금더 체계화된 개발 프로세스를 원하게 된다.

한정된 예산으로 서비스를 개발하게 되며, 인원이 많아짐으로써 품질 저하를 막기 위해서 역할이 세분화 되고 체계화 된다.




아마 대부분의 일반적인 서비스 개발 이나 시스템 개발 기업들은 이러한 프로세스를 따를 것이다. 아이디어가 나오면, 발표하고 경영진을 설득하여 예산을 정하고, 요구 사항 분석을 통해서 범위를 정한후, 개발/테스트/수정을 한후, 모든 테스트를 통과하면 릴리즈 일정을 결정하고 산출물을 정리한후, 운영팀으로 이행한다.


체계화 되어 있기는 하지만, 앞서 설명한,Start up에 비해서는 전체적인 프로세스가 느리고, 운영으로 이관후, 자잘한 Fix나 Enhancement가 어렵다. 그리고, 새로운 기능이나 컴포넌트를 개발하려면, 새로운 프로젝트를 시작해서 위와 같은 전과정을 다시금 거쳐야 한다.


3. CD와 Devops기반의 개발 모델

요즘 같이 새로운 서비스가 많이 나오는 시절에, 저런형태의 개발 프로세스는 빠른 기능 추가등이 불가능하고, 운영중의 피드백을 받기 어려워서 SNS와 같은 서비스에는 적절하지가 않다. 

그래서 CD (Continuous Delivery)와 Devops라는 개념을 사용하는데


CD

CD는 Continuous Delivery의 약어로

운영 시스템에 계속해서 Fix나 새로운 기능을 지속적으로 Release를 하는 개념이다.

쉽게 예를 들어보면, 프로젝트 기간이 끝나면 릴리즈를 하는게 아니라, 매일매일 새로운 FIX나 기능이 추가되면 거의 매일 릴리즈를 하는 개념으로 보면 된다.

Face Book의 경우 이런식으로 매일 개발자가 새로운 기능을 운영 환경에 반영 및 추가 하는 것으로 알고 있다.


Devops

Devops는 Netflix에서 주로 시작된 개념으로 개발팀과 운영팀을 하나로 묶어서, 커뮤니케이션에서 오는 장애를 해소하고 빠른 서비스 개발과 반영을 하고자 함에 있다.

보통 개발팀과 운영팀이 나눠져 있는 것이 전통적인 모델인데, 이 경우에는 운영중에 고객의 요구 사항등이 개발쪽에 잘 전달되지 않고, 매일 서비스를 운영하면서 개선 사항이 있더라도 개발팀에 전달되기가 어려운 경우가 많다. 반대로, 개발쪽에서 무엇인가를 수정하면 수정 내용이 운영쪽에 제대로 전달되지 않아서 배포 실수등을 유발하여 시스템 장애를 유발하는 경우가 많다

그래서 Devops는 두팀을 하나로 합침으로써, 서로간의 의사소통을 빠르게 하고, 개발자가 직접 운영환경을 컨트롤함으로써 빠른 피드백을 받고, 빠른 반영을 통해서 서비스의 신속성을 향상 시키는 모델이다.


보통 이런 개념을 채용한 개발 모델은 다음과 같다.


위의 그림은 TDD를 채용한 그림인데, 먼저 테스트 계획서를 작성한후, 개발 및 테스트를 수행한후, 운영환경에 배포하고, 모니터링을 한다. 그리고 바로 신규 기능에 대한 피드백이나 효과를 모니터링해서 다시금 요구 사항을 정의하는 형태를 따른다

이렇게 Devops와 CD를 적용하기 위해서 중요한것은 자동화된 툴셋이 매우 중요하다.

개발 반영시 자동으로 꼼꼼하게 테스트를 할 수 있어야, 운영시 발생하는 장애를 방지할 수 있으며, 위의 전체 프로세스의 주체는 개발자가 되기 때문에, 복잡한 인프라나 미들웨어에 대한 배포를 자동으로 할 수 있어야 한다.

물론 자동화 툴셋은 어디까지나 구현 관점이다. 더 중요한것은 문화적인 차이점을 이해해야 하고, 프로세스의 변화를 인지하고 바꿔야 한다.

기존의 조직처럼 운영과 개발이 나눠져 있는 경우 조직을 합친다는 것은 기존에 가지고 있는 프로세스,  조직 구조를 모두 바꿔야 하는 것을 의미하며, 아울러서 기술셋도 모두 바꿔야 한다.

아울러 예산 집행 방식에 있어서도 기존에는 개발비용과 운영 비용을 나눠서 미리 잡아놓고 집행했기 때문에 초기 투자비와 운영비용(Running Cost또는 Opex), Devops 방식은 있는 인원들이 쭈욱 업그레이드와 운영을 계속해서 나가는 방식이라서 초기 투자비용보다는 운영비용(Running Cost)에 대한 부분이 커진다.


Devops나 CD의 경우에는 분명히 서비스 관점에서 가지는 이득은 매우 많지만, 변화의 폭이 기존 개발 방식에 비해서 매우 크기 때문에, 함부로 달려들 것은 아니라고 본다. 

그러나 스타트 업에서 규모가 커질 경우 위에서 언급한 정형화된 프로세스보다는 CD/Devops기반의 개발 프로세스로 비교적 쉽게 이동할 수 있고 얻는 이득도 많다.

기존의 대기업이나 SI기업의 경우에는 Devops 모델을 도입하기에는 변경되어야 하는 부분이 매우 많기 때문에, 매우 신중한 접근이 요구 된다.


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Ganglia 아키텍쳐

클라우드 컴퓨팅 & NoSQL/운영 & Devops | 2012.12.03 12:44 | Posted by 조대협

RRD 기반의 Monitoring 시스템 Ganglia



주요 특징

- RRD 기반의 스토리지

- 웹 인터페이스 제공

- 클러스터링을 통한 scale out


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

요즘 잘나간다는 SNS 서비스 (텀블러, PInterest)등의 내부 서비스 아키텍쳐나 운영 구조를 공개된 글을 보면 SNS 시스템들의 기술 트렌드를 읽을 수 있다.

 

1. 소규모 조직이다.

얼마전에 FB에 인수된 Instantgram이나 다른 잘나가는 SNS서비스 업체들을 보면 대부분 인력이 20명이내이다.

영업 조직이 있는 솔루션 업체의 경우는 영업이나 Director들을 포함하더라도 40명이 안넘는 것이 대부분이다.

 

이는 빠른 의사 결정을 가능하게 하기 때문에, 상당히 빠른 서비스 개선을 가능하게 한다.

기술적이나 기획적으로 대단한게 아니라, 하나의 기능을 편하게 만들고 사용자 경험에 상당한 노력을 쏟는다.

 

2. 오픈 소스로 치덕치덕. & Don't invent wheel again

이런 서비스들 치고, 대형 벤더 솔루션 쓰는 곳을 못봤다.

- 대부분 오픈 소스를 사용한다.

- 여러가지 언어를 사용한다. 우리가 한국에서 익숙한 자바나 C는 일부에 사용되지 전체를 자바나 C로만 구현하지는 않는다. 오히려 Erlang, Python, Ruby같은 언어들이 급격하게 올라온다.

- 기존의 오픈 소스를 활용을 하지 새롭게 솔루션을 만드는 경우가 없다.

 

3. Devops
Devops는 Development와 Operaion (개발과 운영)을 합친 말로, 이 두팀을 분리하지 않고 개발팀이 개발과 운영을 모두 맏는 개발 운영 모델이다. 요즘 들어 상당히 유행하는데, 운영에서 얻어지는 노하우나 문제를 개발팀에서 처리하는데 비용을 덜고, 고객으로부터의 요청에 빠르게 대응하기 위한 구조로, 운영 팀을 별도로 두지 않는다.

이 것이 가능한것은 클라우드를 사용하면서 하드웨어 인프라에 대한 운영을 클라우드 업체가 담당하기 때문에, 거창한 운영 조직이 필요없고, 클라우드 상에 배포 구조만 잘 잡으면 되기 때문에 가능해진 일이라고 본다.

 

4. Cloud

앞에서도 이야기 했지만, 잘나가는 서비스들은 AWS (Amazon Web Service)를 사용한다.

초기 투자 비용 (Capex)가 들지 않고, 전 세계 커버리지가 가능하며, HA (High Availibility) 구성이 가능하고, 서비스 부하에 따라서 탄력적으로 컴퓨팅 자원을 늘리거나 줄일 수 있기 때문이다.

 

5. 하나씩 차근차근

놀라운 것중 하나는 수백만명을 대상으로 서비스하는 시스템이라도, 처음부터 수백만명을 지원하기 위한 설계를 하는 것이 아니라 기존에 익숙한 기술을 사용하고, 사용자가 늘어감에 따라 아키텍쳐나 기술셋을 점차적으로 바꿔 나가는 구조를 사용한다.

 

주요 아키텍쳐 구조는

앞단에 Nginx나 Apache와 같은 웹서버

중간에 Redis나 memcached 같은 메모리 데이타 그리드

Tomcat,Django와 같은 WAS

Java 뿐만 아니라 Erlang, Python,RoR과 같은 스크립트 언어 또는 분산 처리 언어

MySQL 을 사용할 경우 Sharding, 또는 NoSQL을 백엔드에 사용

이 전체는 AWS 클라우드 위에 Deployment

아키텍쳐는 REST를 사용하는 구조를 갖는다.

필요에 따라 배치 처리나 분석 처리를 위해서 Hadoop등의 분산 처리 프레임웍을 사용

 

 

 

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 

티스토리 툴바