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


Archive»


 
 

Zipkin을 이용한 MSA 환경에서 분산 트렌젝션의 추적 #1

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

개념

분산 트렌젝션이랑 여러개의 서비스를 걸쳐서 이루어 지는 트렌젝션을 추적하는 기능을 정의한다.

마이크로 서비스 아키텍쳐 (이하 MSA)와 같은 구조에서는 하나의 HTTP 호출이 내부적으로 여러개의 서비스를 거쳐서 일어나게 되는데, 그러면 어느 구간에서 병목이 생기는지 추적하기가 어려워진다.

아래 그림을 보면 클라이언트가 Service A를 호출하고, Service A 가 Service B,D 를, Service B가 Service C를 호출한다.


이렇게 트렌젝션이 여러 컴포넌트의 조합을 통해서 발생하기 때문에 Jennifer와 같은 전통적인 APM (Application Performance Monitoring) 도구를 이용해서 추적하기가 어렵기 때문에 별도의 분산 로그 추적 시스템이라는 것이 필요하다.

작동 원리

그러면 이러한 분산 로그는 어떻게 수집 및 추적하는 것일까? 통상적으로 Trace와 Span 이라는 개념을 사용한다.



클라이언트가 서버로 호출한 하나의 호출을 Trace라고 했을 때, 서비스 컴포넌트간의 호출을 Span이라고 한다.각 서비스 컴포넌트들은 하나의 클라이언트 호출을 추적하기 위해서 같은 Trace Id를 사용하고, 각 서비스간의 호출은 각각 다른 Span Id를 사용한다. 이렇게 함으로써 전체 트렌젝션 시간을 Trace로 추적이 가능하고, 각 서비스별 구간 시간은 Span으로 추적할 수 있다.

솔루션

이러한 분산 로그 추적을 위한 솔루션 중에 오픈소스로는 트위터에서 개발된 ZipKin(https://zipkin.io/) , Jagger(https://jaeger.readthedocs.io/en/latest/) , Opencensus(https://opencensus.io/) 등이 있는데, 이러한 분산 로그 추적은 구글의 Dapper 논문을 기초로 디자인 되어 개발되었다.

Zipkin

그 중에서, 가장 활성화 되어 있는 오픈소스 중 하나가 Zipkin인데, 오픈 소스 생태계가 활발해서 플러그인이나 부가적인 도구들이 많다.

전체적인 구조는 다음과 같다.


<그림 . Zipkin 아키텍쳐 >


지원 프로토콜

Zipkin으로 추적할 수 있는 분산 트렌젝션은 HTTP를 기본으로 지원하고 , 이외에도 많이 사용되는 리모트 프로토콜인 gRPC를 함께 지원한다.

클라이언트 라이브러리

Zipkin 클라이언트 SDK는 https://zipkin.io/pages/existing_instrumentations 에 있는데, Zipkin에서 공식적으로 지원하는 라이브러는 아래와 같이 C#, Go, Java, Javascript,Ruby,Scala 등이 있다.




이외에도 오픈 소스 커뮤니티에서 지원하는 라이브러리로 파이썬, PHP등 대부분의 언어가 지원이 가능하다.

Zipkin 라이브러리는 수집된 트렌젝션 정보를 zipkin 서버의 collector 모듈로 전송한다. 이 때 다양한 프로토콜을 사용할 수 있는데, 일반적으로 HTTP를 사용하고, 시스템의 규모가 클 경우에는 Kafka 큐를 넣어서 Kafka 프로토콜로 전송이 가능하다.

스토리지

Zipkin 클라이언트 SDK에 의해서 전송된 정보는 스토리지에 저장된다.

사용할 수 있는 스토리지는 다음과 같다

  • In-memory

  • MySQL

  • Cassandra

  • Elastic Search

메모리는 별도의 스토리지 설치가 필요없기 때문에 간단하게 로컬에서 테스트할 수 있는 정도로 사용하는 것이 좋고, MySQL은 소규모 서비스에 적절하다. 실제로 운영환경에 적용하려면 Cassandra나 Elastic Search를 저장소로 사용하는 것이 바람직하다.

대쉬 보드

이렇게 수집된 정보는 대쉬 보드를 이용하여 시각화가 가능하다. Zipkin 서버의 대쉬보드를 사용할 수 있고, Elastic Search 백앤드를 이용한 경우에는 Kibana를 이용하여 시각화가 가능하다.


Spring Sleuth

Zipkin 라이브러리 중에서 주목해서 살펴볼 부분은 Spring / Java 지원인데, Spring에서 Sleuth라는 모듈 이름으로 공식적으로 Zipkin을 지원하기 때문에, Spring (& Springboot) 연동이 매우 쉽다.

자바 애플리케이션에서 Trace 정보와 Span 정보를 넘기는 원리는 다음과 같다.


여러개의 클래스의 메서드들을 거쳐서 트렌젝션이 완성될때, Trace 정보와 Span 정보 Context가 유지가 되어야 하는데, 자바 애플리케이션에서는 쓰레드마다 할당되는 쓰레드의 일종의 전역변수인 Thread Local 변수에 이 Trace와 Span Context 정보를 저장하여 유지한다.


분산 트렌젝션은 HTTP나 gRPC로 들어오기 때문에, Spring Sleuth는 HTTP request가 들어오는 시점과 HTTP request가 다른 서비스로 나가는 부분을 랩핑하여 Trace와 Span Context를 전달한다.

아래 그림과 같이 HTTP로 들어오는 요청의 경우에는 Servlet filter를 이용하여, Trace Id와 Span Id를 받고 (만약에 이 서비스가 맨 처음 호출되는 서비스라서 Trace Id와 Span Id가 없을 경우에는 이를 생성한다.)

, 다른 서비스로 호출을 할 경우에는 RestTemplate 을 랩핑하여, Trace Id와 Span Id와 같은 Context 정보를 실어서 보낸다.



HTTP를 이용한 Trace와 Span 정보는 HTTP Header를 통해서 전달되는데


위의 그림과 같이 x-b3로 시작하는 헤더들과 x-span-name 등을 이용하여 컨택스트를 전달한다.

이렇게 ServletFilter와 RestTemplate을 Spring 프레임웍단에서 랩핑해줌으로써, 개발자는 별도의 트레이스 코드를 넣을 필요 없이 Spring을 이용한다면 분산 트렌젝션을 추적할 수 있도록 해준다.


다음글에서는 실제로 Spring Sleuth와 Zipkin을 이용하여 분산로그를 추적하는 예제를 구현해보도록 하겠다.



CI/CD 레퍼런스 아키텍쳐


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


Continuous Deployment를  구현하기 위해서는 여러가지 프레임웍을 조합할 수 있다. 배포를 위한 Chef,Puppet과 같은 Configuration management tools, 그리고 네트워크, VM등을 코드로 설정하기 위한 Terraform 과 같은 Infrastructure as a code, VM 이미지를 만들기 위한 Packer 등 다양한 솔루션 조합이 가능한데, 이 글에서는 이러한 솔루션을 조합하여 어떻게 Continuous Deployment 파이프라인을 구현할 수 있는지에 대해서 설명하고, 구체적인 솔루션 제안을 통하여 레퍼런스 아키텍쳐를 제안하고자 한다.

1. Terraform + Ansible 기반의 Continuous Delivery

가장 기본적인 조합으로는 Terraform 을 이용해서 코드로 정의된 설정을 이용하여 인프라를 설정한 후에,

VM에, Ansible을 이용하여 애플리케이션 서버등의 소프트웨어를 설치한 후,  애플리케이션 코드를 배포하는 방식이다.

아래 그림은 Terraform으로 먼저 VM 인스턴스 그룹을 만든 후에, Load Balancer에 연결하고, CloudSQL (DB)인스턴스를 배포하는 구조이다.




이후에, 각 VM에 대한 설치는 Ansible을 이용하는 구조이다 Ansible은 Jenkins와 같은 CD 툴에 의해서 코드 변경등이 있으면 호출되서 자동화 될 수 있다.


이러한 구조는 전통적인 Continuous Delivery 기반의 애플리케이션 배포 자동화 구조이다.


2. Packer를 추가한 Foundation Image 사용방식

앞의 구조에서 VM은 애플리케이션 서버를 코드 배포 단계에서 배포할 수 도 있지만 애플리케이션 코드 이외에는 변경이 없기 때문에, Terraform으로 인프라를 배포할때, Packer와 Ansible을 이용하여, 애플리케이션이 설치되어 있는 이미지를 만들어놓고, 이를 이용해서 배포할 수 있다. (이미지를 만드는 과정을 베이킹 = 굽는다. 라고 한다.)

아래 그림을 보면, Terraform에서, Packer를 호출하고, Packer가 VM 이미지를 만드는데, 이 과정에서 Ansible을 이용하여, 애플리케이션 서버를 설치하도록 설정하는 구조를 가지고 있다.



위의 구조에서는 node.js server 애플리케이션 서버를 사용했지만, 실제 인프라를 구축할때는 redis나 웹서버등 다양한 애플리케이션의 설치가 필요하기 때문에, 이 구조를 사용하면 전체 인프라 구축을 코드로 정의하여 자동화를 할 수 있다.

3. Spinnaker를 이용한 Continuous Deployment 구조

코드만 배포하고 업데이트 할 경우, 서버의 패치 적용등의 자동화가 어렵기 때문에, 매번 배포시 마다, VM 설정에서 부터 OS 설치와 패치 그리고 애플리케이션 설치와 코드 배포까지 일원화하여 VM 단위로 배포할 수 있는데, 이를 Continuous Deployment 라고 한다.


솔루션 구성은 2번의 구조와 유사하나, Terraform으로는 VM과 로드밸런서를 제외한 다른 인프라를 설정하고 Spinnaker를 이용하여, 로드밸런서와 VM을 이용한 배포를 실행한다.


Spinnaker로 배포할 수 있는 범위는 방화벽, 로드밸런서, VM 과 같이 워크로드를 받는 부분인데, Spinnaker는 Packer와 Ansible과 협업하여, VM에 모든 스택을 설치하고, 이를 VM 단위로 배포할 수 있도록 해준다. 복잡한 네트워크 설정이나, CloudSQL과 같은 클라우드 전용 서비스는 Spinnaker로 설정이 불가능하기 때문에, 먼저 Terraform으로 기본 인프라를 설정하고, VM관련된 부분만을 Spinnaker를 사용한다.

이렇게 VM전체를 배포하는 전략을 피닉스 서버 아키텍쳐라고 한다. 피닉스 서버 패턴은 http://bcho.tistory.com/1224?category=502863 글을 참고하기 바란다.


Spinnaker를 이용한 배포 전략

Spinnker를 이용하면, VM 기반의 배포뿐 아니라, 다양한 배포 전략을 수행할 있다.



그림 https://sdtimes.com/cloud/google-open-source-platform-spinnaker-1-0/


Blue/Green deployment

블루 그린 배포 전략은 새버전의 서버그룹을 모두 배포 완료한 후에, 로드밸런서에서 트래픽을 구버전에서 새버전으로 일시에 바꾸는 방식이다.

Rolling deployment

롤링 배포는, 새버전의 서버를 만들어가면서 트래픽을 구버전 서버에서 새버전으로 점차적으로 옮겨가는 방식이다. 예를 들어 구서버가 10대가 있을때, 새 서버 1대가 배포되면, 구서버 9대와 새서버 1대로 부하를 옮기고, 새서버 2대가 배포되면 구서버:새서버에 8:2 비율로 부하를 주면서 7:3,6:4,5:5,.... 이런식으로 부하를 옮겨가며 전체 부하를 새 서버로 옮기는 방식이다.


블루 그린 배포 전략은 서버 대수의 2배수의 서버가 필요한 반면, 롤링 배포 방식은 같은 서버의 수 (위의 예의 경우 10대만 있으면 됨)를 가지고 배포를 할 수 있기 때문에 서버 자원이 한정되어 있는 경우에 유리하게 사용할 수 있다.

Canary deployment

카날리 배포를 설명하기 전에 카날리 테스트에 대한 용어를 이해할 필요가 있다.

카날리 테스트는 옛날에 광부들이 광산에서 유독가스가 나오는 것을 알아내기 위해서 가스에 민감한 카나리아를 광산안에서 키웠다고 한다. 카나리아가 죽으면 유독가스가 나온것으로 판단하고 조치를 취했다고 하는데, 이 개념을 개발에서 사용하는것이 카날리 테스트 방식이다.

예를 들어 사용자가 1000명이 접속해 있을때, 일부 사용자에게만 새 버전을 사용하도록 하고, 문제가 없으면 전체 사용자가 새 버전을 사용하도록 하는 방식인데, 안드로이드 앱 배포의 경우에도 10%의 사용자에게만 새 버전을 배포해보고 문제가 없으면 100%에 배포하는 것과 같은 시나리오로 사용된다.


이 개념을 배포에 적용한것이 카날리 배포 방식인데, 일부 서버에만 새 버전을 배포하여 운영한 후에, 문제가 없는 것이 확인되면 전체 서버에 새 버전을 배포하는 방식이다.

Docker를 이용한 배포 효율화

이러한 VM 기반의 Continuous deployment 구조는 피닉스 서버 패턴을 기반으로 하여, 모든 업데이트 추적이 가능하다는 장점을 가지고 있지만, 매번 VM을 베이킹해야 하기 때문에 시간이 많이 걸리고, VM 이미지는 사이즈가 커서 스토리지를 많이 사용한다는 단점이 있다.

이러한 배포 구조와 잘 맞는 것이 Docker (Docker 개념 http://bcho.tistory.com/805 ) 인데, Docker는 컨테이너 기반으로 경량화가 되어 있기 때문에, 이미지 베이킹 시간이 상대적으로 짧고, 이미지 사이즈가 작아서 저장이 용이하며, 이미지를 저장하기 위한 리파지토리와 같은 개념이 잘되어 있다.


Spinnaker의 경우 이런 Docker 기반의 피닉스 서버 패턴 기반의 배포를 지원하는데, 특히 Kubernetes 클러스터를 매우 잘 지원하기 때문에, 오히려 VM 기반의 배포 보다는 Docker + Kubernetes 배포 구조를 선택하는 것이 좋다.


이 경우 인프라 배포에 있어서는 애플리케이션을 서비스하는 VM워크로드는 도커를 사용하되, Redis, RDBMS와 같은 미들웨어 솔루션은 재 배포가 거의 발생하지 않기 때문에, VM에 배포하여 사용하는 것이 성능적으로 더 유리하기 때문에, 도커와 VM 을 하이브리드 구조로 배포하는 방식을 권장한다.


클라우드 전용 배포 솔루션  VS 오픈소스 (Terraform)

앞에서 설명한 아키텍쳐에서 사용한 솔루션은 모두 오픈 소스 기반이다. 클라우드 벤더의 경우에는 구글은 Deployment Manager와, 아마존은 CloudFormation을 이용하여, 코드 기반의 배포 (Terraform과 동일)를 지원하는데, 그렇다면, 클라우드에서 제공하는 전용 솔루션을 쓰는 것이 좋은가? 아니면 오픈소스나 벤더에 종속적이지 않은 솔루션을 사용하는 것이 좋은가

오픈소스의 배포툴의 경우에는 요즘 트랜드가 다른 영역으로 확장을 해가는 추세가 있기 때문에, 코드 기반의 인프라 배포 이외에도 애플리케이션 코드 배포등 점점 더 넓은 영역을 커버할 수 있는 장점이 있고, 오픈 소스 생태계내에서 다른 제품들와 연동이 쉬운점이 있다. 그리고 특정 클라우드 벤더나 인프라에 종속성이 없기 때문에 조금 더 유연하게 사용이 가능하지만, 클라우드 벤더에서 제공되는 새로운 서비스나 기능 변화를 지원하는 것에는 상대적으로 클라우드 벤더에서 제공하는 도구보다 느리다. 예를 들어 구글 클라우드에서 새로운 서비스가 나왔을때, 테라폼에서 이 기능을 지원하는데 까지는 시간이 걸린다는 것이다.


양쪽다 좋은 선택지가 될 수 있기 때문에, 현재 환경에 맞는 솔루션을 선택하는 것을 권장한다.



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/




기존 개발 체계의 문제점

전통적인 개발 운영 체계

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



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


문제점 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


소프트웨어 개발팀의 구조

아키텍쳐 | 2013.11.01 19:31 | Posted by 조대협

서비스 개발팀의 구조

 

시스템 개발 및 운영에 있어서팀의 구조는 매우 중요하다효율적인 의사 소통과 협업은 이 팀 구조에 많은 영향을 받는데지금까지 여러가지 팀 구조에 대한 레퍼런스가 존재해왔다개인적으로 느끼는 생각은사실 정답은 없다는 것이다비지니스나 팀의 특성문화적 특성에 따라서 그 팀 구조는 매우 상이하다지금까지 수천명이 들어가는 은행 차세대 프로젝트에서 부터 4~5명으로 구성된 프로젝트 팀, 50명 규모의 프로젝트 팀등 다양한 팀 구조를 경험하거나 직접 셋업 및 운영해왔다경험상 보면 보편적으로 많이 사용되는 팀 구조 모델이 있기는 마련인데여기서는 지금까지 프로젝트를 해오면서 가장 적절했다고 생각하는 팀 구조에 대해서 소개 하고자 한다. (참고, 이 팀의 구조는 개발과 운영이 분리된 전통적인 서비스 팀 구조이다. http://bcho.tistory.com/721 모델에서 2. 성숙된 팀구조 정도에 해당하며, Devops 기반의 팀 구조에는 해당 하지 않는다.)

  

 

 

Project Unit

Project Unit은 하나의 시스템을 개발하는 최소의 단위이다.

Ÿ   Project Manager : 여러 개의 스크럼 팀을 운영 하면서단일 시스템을 구현을 관리 한다. Product Manager와 협업하여요구 사항을 각 스크럼팀에 분배하고 관리한다.

Ÿ   Product Manager : 고객으로 부터 시스템에 대한 요구 사항을 수집 하고시장을 분석하여 시스템에 대한 요구 사항을 정의하고우선 순위를 정하는 역할을 한다사용자 관점에서 상세한 흐름과 상세한 요구 사항을 정의한다.

Ÿ   Architect : 전체 시스템에 대한 구조를 설계한다필요에 따라서는 기술 선택 및 코드를 통한 프로토타입핑 작업까지 진행한ㄴ다.

Ÿ   Scrum Team

하나의 프로젝트 Unit은 내부의 서브 시스템이나 컴포넌트 단위에 따라서 몇 개의 스크럼팀으로 나뉘어진다하나의 스크럼팀은 Scrum Master를 포함하여 4~7명 정도가 적당하다이 스크럼팀의 운영에는 유연성을 발휘해야 하는데일의 성격이나 팀의 규모에 따라서 한 명의 Scrum Master가 동시에 2~3개의 Scrum Team을 관리할 수 도 있다.

-        Scrum Master : Scrum Master Product manager로 부터 받은 요구 사항을 개발원들에게 나눠주고관리하는 역할을 한다해당 스크럼팀의 구현 Task를 분배하고 관리하는 역할을 한다.

-        Developers : Scrum Master로 부터 받은 Task를 구현한다팀의 형태에 따라서 구현 부분에 대한 단위 테스트 (Unit Test)를 직접 구현한다.

-        QA : 시스템의 특성이나 팀의 구조에 따라서해당 스크럼 팀에서 개발된 코드나 기능에 대한 테스트를 수행한다각 스크럼팀에 테스터를 배치하는 방법도 있지만리소스 상황에 따라서 전체 프로젝트 팀에 대한 공통 QA를 배치해서 운영 할 수 도 있다.

Management board

Ÿ   Program manager : Program manager의 경우에는 하나의 프로젝트 조직을 운영하더라도 필수적으로 필요하다또는 Project Manager Program manager를 겸임할 수 있다.여러개의 프로젝트를 동시에 관리하며개별 Project의 구현 보다는 비지니스 조직과의 커뮤니케이션과 개발 후 서비스에 대한 운영고객 지원판매, UX 등에 대한 전반적인 면을 총 아울러서 관리한다.

Ÿ   Chief Product Manager(Optional-팀규모가 클경우) : 팀 규모가 클 경우개별 Product manager 만으로는 전체 Product의 컨셉이 일관성을 잃을 수 있다그래서 전체 Product 요구 사항에 걸쳐서 전반적인 부분을 관리하는 사람을 Chief Product Manager라고 한다개별 Product manager가 개별 Product에 집중한다면, Chief Product Manager는 이 Product으로 구성된 Portpolio를 관리 하는 역할을 한다.

Ÿ   Enterprise Architect(Optional-팀규모가 클경우) : 시스템의 구조가 커지게 되면 각 개별 프로젝트 팀에 있는 아키텍트로만은 전체 시스템을 그릴 수 없다각 프로젝트 팀의 아키텍트가 건물을 그린다면, Enterprise Architect는 전체 도시를 설계하는 개념으로 보면 된다프로젝트 유닛의 아키텍트가 기술 지향적이고프로토타입핑등 디테일한 설계에 집중한다면, Enterprise Architect는 전체 시스템에 대한 Conceptual한 구조와비지니스간에 연계 역할을 하면서비지니스와 개발간의 기술적인 소통 채널이 된다.

 

* Program manager Project manager의 차이

Project manager는 시스템의 구현 자체에만 포커스를 맞춘다주로 테크니컬한 관점에서 프로젝트의 범위와 스케쥴 그리고 리소스를 관리하는 관점이다.

Program manager는 구현을 포함한 운영 및 비지니스와의 관계까지 전반적인 서비스에 대한 부분을 넓게 아우르며구현이나 테크니컬한 관점 보다는 외부와의 관계비지니스사람에 포커스를 맞추며외부와의 소통정치 그리고 협상(요구사항이나 범위리소스)등에 포커싱이 되어 있다.

Project manager가 구현단계에만 투입 된다고 보면, Program manager는 전체 프로젝트 기획 단계에서 부터, 개발, 개발 종료후의 운영까지 전반적인 과정을 관리 한다.

전체적인 범위로 보자면 Program manager Project manager 보다 더 넓은 범위를 포함한다고 폴 수 있다.

 

Shared Unit

Shared Unit은 개발 기간중에한 팀에 집중되서 사용되지 않고중간중간 필요한 때만 사용되기 때문에자원의 효율성을 위해서전체 팀에 걸쳐서 공통된 조직으로 운용하는 것이 좋으며이를 통해서 전체 팀에 대한 표준화를 지원할 수 있다.

Ÿ   Build : 전체적인 빌드 배포를 담당하는 엔지니어이다. maven 등의 빌드 스크립트와, fabric등의 배포 자동화 툴을 이용하며, Jenkins와 같은 CI도구를 이용한 빌드 환경과 테스트 자동화 환경을 구축한다.

Ÿ   Development environment management : 개발환경에 필요한 전반적인 부분을 관리한다. git와 같은 VCS 툴에서 부터, JIRA와 같은 Task management, 위키와 같은 협업 도구문서 관리 도구등 개발 인프라 관리를 담당하며역할을 확장할 경우, VM 기반의 개발 환경 구축표준 개발 VM 이미지 (Tomcat, MySQL등이 이미 설치되어 있는개발 및 관리. Eclipse와 같은 IDE에 대한 표준화등의 역할을 수행한다조직의 규모에 따라서 Build 엔지니어의 역할을 겸임할 수 도 있다.

필요에 따라 개발 서버 세팅 및 개발 서버에 인스톨되는 각종 서버 소프트웨어에 대한 설정을 관리한다.

Ÿ   Performance Engineering : 스크럼팀의 QA 엔지니어 역할이 단위테스트라면, Performance Engineer는 전체 시스템에 대한 통합 테스트 (Integration Test) System 테스트에 집중한다특히 System Test를 위한 부하테스트 작성 및 장애 테스트의 수행그리고 병목 구간 발견 및 튜닝에 대한 모든 작업을 수행한다성능 테스트에 대한 깊은 이해와 함께튜닝을 위한 지식과 솔루션,애플리케이션에 대한 모든 지식을 겸비해야 한다. (rockstar)

Ÿ   Project Management Office (PMO) : 프로젝트 조직이 거대할 경우전체 프로젝트를 중앙에서 컨트롤 한다각 프로젝트의 진행 상황을 모니터링 하고, Risk에 대한 관리를 진행하며특히 각 릴리즈 일정을 관리한다이 외에도 Staff성 업무를 지원하는데예산 책정 및 관리집행외부 업체와의 아웃소싱,컨설팅제품 구매 계약필요에 따라 법률 검토등의 행정적인 작업을 지원한다.

Operation

시스템 릴리즈 후에, 운영을 담당한다. 보통 운영을 생각하면, 하드웨어나 소프트웨어를 운영하는 시스템 운영만을 생각 하는 경우가 많은데, 서비스를 운영하기 위한 고객 대응까지 포함한 모든 운영을 포함한다.

Technical Operation (시스템 운영)

흔히 Tech Ops 또는 시스템 운영이라고 이야기 하는 분야로, 구현된 하드웨어 및 소프트웨어를 포함한 시스템에 대한 운영을 담당한다.Tech Ops는 시스템의 설치, Configuration, Setup 및 배포와 같이 설치에 대한 전체 프로세스 뿐만 아니라 시스템에 대한 모니터링 및 장애(Incident) 처리까지의 시스템에 대한 기술적인 운영에 대한 전반적인 부분을 담당한다.

-    인프라 엔지니어 : 인프라 엔지니어는 네트워크 장비, 서버 등 하드웨어 장비에 대한 설치,설정 및 운영을 담당한다.

-    솔루션 엔지니어 : 솔루션 엔지니어는, 메세지 큐, MQ, Application Server와 같은 미들웨어에 대한 운영을 한다.

-    DBA(Data Base Administrator) : 다른 미들웨어 시스템도 중요하기는 하지만 데이타베이스의 경우 분야도 비교적 더 넓고, 전문성도 높게 필요하기 때문에 일반적으로 데이타베이스 운영자는 별도로 분리 하는 경우가 많다.

Tech Ops에서는 24시간 7일 운영을 하는 것을 24x7 운영이라고 하고, 운영팀을 지리적으로 분리해서 24x7을 지원하는 것을 FTS (Follow the Sun : 해를 따라서 지원)이라고 한다. A,B,C 8시간씩 시스템을 운영 및 모니터링 해야 하기 때문에, 여러 대륙에 걸쳐서 팀을 셋업한다.

그리고 근무 시간이 끝난 후에,다음 팀에게 운영을 넘기는 것을 hand over라고 하는데, 어떤 장애가 났는지 자세한 장애의 원인과 상태 진행 상황등을 전달해서 지속적인 운영 하는 절차이다. (일종의 수문장 교대식?). 이 과정에서 적절한 프로세스와 hand over에 대한 문서 템플릿을 구축하는 것이 중요하다.

아울러, 장애 대응이 중요한다. 조직이 아주 크다면 모르겠지만 특정 솔루션에 대해서 장애가 났을때, 전문성이 있는 엔지니어가 있는 팀이 운영을 하고 있지 않다면, 장애에 대한 대응이 불가능하다. 그래서, 장애 발생시 문제 해결이 안되면 전문성을 가지고 있는 사람에게 일을 넘길 수 있는 escalation 프로세스가 필요하다.

시스템에 대한 기술적인 운영은 기술적인 전문성을 갖추는 것도 중요하지만, 더 중요한 것은 적절한 프로세스를 갖춰서, 운영 자체가 물이 흐르듯이 잘 흘러가도록 만드는 것이다.

Service Operation (서비스 운영)

서비스 운영은 구축된 서비스에 대한 운영을 담당한다. 시스템에 대한 기술적인면을 배제한 부분을 포함한다.

-    관리자 (Admin) : 서비스에 대한 관리를 한다. 예를 들어 게시판 관리자나, 포탈 시스템의 관리자 등 시스템에 대한 기술적인 운영이 아닌 비지니스 관점의 운영을 담당한다.

-    고객 지원 (Support) : 기술지원이나 고객 불만 접수와 같은 고객 지원 서비스를 담당한다.

이외에도, 유료화 서비스의 경우에는 빌링이나 정산을 하는 팀. 게임에서는 불법 사용자를 처리하는 사람이나, 서비스에 대한 이벤트 마케팅을 하는 것도 운영의 범주로 볼 수 있다.

 


시스템 개발 및 운영에 있어서, 팀의 구조는 매우 중요하다. 효율적인 의사 소통과 협업은 이 팀 구조에 많은 영향을 받는데, 지금까지 여러가지 팀 구조에 대한 레퍼런스가 존재해왔다. 개인적으로 느끼는 생각은, 사실 정답은 없다는 것이다. 비지니스나 팀의 특성, 문화적 특성에 따라서 그 팀 구조는 매우 상이하다. 지금까지 수천명이 들어가는 은행 차세대 프로젝트에서 부터 4~5명으로 구성된 프로젝트 팀, 50명 규모의 프로젝트 팀등 다양한 팀 구조를 경험하거나 직접 셋업 및 운영해왔다. 경험상 보면 보편적으로 많이 사용되는 팀 구조 모델이 있기는 마련인데, 여기서는 지금까지 프로젝트를 해오면서 가장 적절했다고 생각하는 팀 구조에 대해서 소개 하고자 한다.

 


 


'아키텍쳐' 카테고리의 다른 글

MySQL 클러스터링을 위한 Galera Cluster  (3) 2015.11.18
요구 사항 정의 기법  (0) 2013.11.13
소프트웨어 개발팀의 구조  (0) 2013.11.01
Technical Debt  (1) 2013.10.30
License Key Management  (0) 2013.08.01
암호화 알고리즘 속도 비교 (대칭키)  (0) 2013.07.17