전 위메프 CTO 김요섭님의 DEVOPS에 대해서

전 위메프 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.

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

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