[DevOps] 개발과 운영

기존 개발 체계의 문제점

전통적인 개발 운영 체계

• 개발팀에 의해서 개발이 끝나면, 시스템은 테스트를 거쳐서 운영팀에 이관되고, 운영팀은 해당 시스템을 배포 및 관리 운영한다.
• 일단 이관된 시스템은, 개발팀이 일체 관여하지 않고, 운영팀에 의해서 현상 유지 된다.

문제점 1.

• 시스템을 운영하다 보면, 반드시 장애가 생기기 마련인데, 문제는 여기부터 시작된다.
• 개발은 “애플리케이션” 을 볼 수 있지만, 아랫단의 “인프라 시스템”을 볼 수 있는 능력이 없다.
• 반대로 운영팀은 “인프라 시스템” 을 잘 알지만, “애플리케이션” 자체에 대해서는 잘 모른다.
• 그러다 보니, 서로 자기 분야의 문제가 아니라고 하면서 서로 책임 미루기를 하게 되고, 문제 해결은 지연된다.

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

  1. Freaking out & find fault 단계 (문제 발견)
     • 문제가 발생했다.
     • 문제의 내용을 먼저 파악한다.
     • 이때 협업은 없다.
     • 단지 자기 분야에서 문제가 어떤 것인지, 한정된 지식으로 현상 자체를 인지하는 수준이 된다.
     • 근본적인 문제에 대한 원인 파악보다는 대충 파악하는 단계 정도의 수준이 된다.
     • 이 단계에서 누가 문제를 파악할지에 대한 owner ship 자체가 정해지지 않는다.
  2. Blaming Covering ass 단계 (욕하기)
     • 그러다가, 어느 정도 문제의 현상 (정확한 원인이 아니라) 정도가 파악되면, 서로 미루기를 한다.
     • “애플리케이션 문제네..”, “데이터 베이스 문제네..” 식으로, 정확한 원인 파악 없이 자기 문제가 아닌 것 처럼, 다른 쪽으로 미루기를 시작하면서, 상대편을 욕하는 단계가 된다.
     • “데이터 베이스 구성을 그렇게 하니까는 그렇지.. 인덱스는 아냐?”. 내지는 “애플리케이션 구조에 맞춰서 배포는 한거야?” 이러면서 문제의 근본적인 원인은 해결되지 않고 시간은 계속 간다.
  3. Whining, Hiding. Hurt Ego 단계 (맘 상처 입기)
     • 계속 해서 문제를 서로에게 넘기다 보면, 문제를 숨기거나 상대방을 헐뜯거나 하면서 결국은 서로 상처를 입게 되고, 점점 커뮤니케이션은 없어지고 관계는 악화되어 간다.
  4. Figuring it out (문제 원인 분석)
     • 결국 문제를 해결해야 하는 시간이 가까워 오면, 문제를 풀긴 풀어야 하니, 어떻게든지 스스로 서로 모여서 문제를 같이 보게 되거나, 상위 메니져를 통해서 강제적으로 같이 모여서 문제에 대한 원인 분석을 해서 결국은 원인을 파악하게 된다.
  5. Fixing things (문제 해결)
     • 그리고, 결과적으로 원인 파악 및 문제가 해결된다.
• 아주 전형적인 개발과 운영간의 장애 처리 프로세스이다.
• 그나마 똑똑한 팀장을 가지고 있는 조직은 장애나 문제가 발생했을 때, “모두 다 모이세요.”해서 초기부터 문제를 같이 보고 해결하거나, 개발팀이나 운영팀 자체가 상대방의 분야를 볼 수 있는 능력을 갖춰서 문제를 해결하는 경우가 많다.
• 예를 들어, 운영팀이 애플리케이션에 대한 장애 대응 능력을 갖거나, 개발자가 OS나, 데이타베이스 또는 미들웨어등에 대한 인프라 운영 능력을 갖는 경우이다.

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

• 개발은 운영으로 이관 후에, 서비스에 대해서 더 이상 관심을 갖지 않는다.
• 고객과의 접점도 거의 없다.

• 그러나 운영은 (단순히 시스템을 운영하는 시스템 운영만이 아닌 실제 서비스 운영을 포함) 계속 해서 사용자와 interaction을 하고, 사용자로부터 끊임 없이 VOC (Voice Of Customer)를 받는다.

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

문제점 3. 변경 요건

• 서비스가 운영 배포된 후에도, 비즈니스 (기획팀)에 의해서, 계속 해서 서비스에 대한 신규 요구 사항은 나오게 되고, 새로운 변경 요건은 신규 개발과, 테스트 배포 그리고 지속적인 운영을 요구 하게 된다.
• 그런데, 근래의 서비스들의 경우에는 빠른 비즈니스 환경 변화에 따라가기 위해서 많은 변경 요구하게 되고, 이는 필연적으로 잦은 변경 배포를 요구 하게 된다.

• 제대로 많은 변경으로 인하여 제대로 테스트 시간을 거치지 못한 애플리케이션의 경우에는 잦은 장애를 유발한다.

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

해결책?

• 서비스 요구 사항의 신속한 반영의 문제
• 고객의 요구 사항에 민감한 소프트웨어 개발

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

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

Devops의 정의

• 이러한 개념들을 적극적으로 적용한 기업들이 Netflix, Flicker와 같은 인터넷 서비스 기업이다.
• 기존 개발 프로세스에 비해서 훨씬 빠르게 고객의 요구 사항을 반영해 내가고 있다.
• Flicker의 경우에는 하루에 10번 정도 Deploy를 한다고 한다.
• 일반적인 인터넷 서비스가 한달에 한번 업데이트 빨라야 일주에 한번인데, 하루에 10번이라면, 경쟁 구조 자체가 틀려진다.
• PuppetLab (Configuration management 자동화툴)에 따르면 Devops를 적용할 경우,경쟁사에 비해서 30배 정도 더 자주 Deployment를 할 수 있으며, Deployment 실패 비율도 50% 이상이나 줄일 수 있다는 것이다.

Devops는 무엇인가?

• 일반적인 Devops의 정의는 “개발과 운영이 분리되면서 오는 문제점을 해결하기 위해서, 개발과 운영을 하나의 조직으로 합쳐서 팀을 운영하는 문화이자 방법론이다”

• 개발 운영뿐만 아니라 테스트까지 하나의 팀에 합치는 것이다.

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

• 즉 Devops란, “엔지니어가, 프로그래밍하고, 빌드하고, 직접 시스템에 배포 및 서비스를 RUN한다.

• 그리고, 사용자와 끊임 없이 Interaction하면서 서비스를 개선해 나가는 일련의 과정이자 문화이다.

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

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

• 그렇다면 Devops의 실체는 무엇일까? Scrum이나 XP와 같은 방법론? 아니면 조직 체계? Devops는 팀운용 방법론이기도 하지만 정확하게 이야기 하면 “문화”이다. 개발 문화.

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

Devops의 특징

1. Cross functional team – 하나의 팀에 각각 다른 역할을 할 수 있는 팀원들로 셋업해서 전체 End 2 End 서비스를 운용할 수 있도록 한다. 그렇다고 만능 개발자로 전체 팀을 채워서 일을 하라는 것이 아니다. 개발자의 커버러지가 넓어지고 협업은 해야 하겠지만, 그렇다고 모든 개발자가 그렇게 수퍼개발자일리는 없고, 엄연하게 다른 역할이 존재 한다. 예를 들어, 테스트 엔지니어, 빌드엔지니어 등.
   • 단, 여기서 Cross functional team이란, 한 팀내에서 서비스의 기획에서부터 운영 그리고 더 나아가서 영업등 해당 서비스에 관련된 모든 것 “ALL!!”을 할 수 있는 구조로 팀을 셋업 하라는 것이다.
2. Widely Shared Metris – 개인적으로 가장 중요하다고 생각하는 항목중의 하나인데, 팀 전체가 기준으로 삼을 수 있는 서비스에 대한 공통적인 지표 (Metric)이 필요하다. 서비스를 개발하고 개선했을 때, 이를 평가하고 현재의 서비스의 진행 상태 (성공 여부, 시스템의 안정성, 사용자의 반응 등)를 인지할 수 있는 기준이 필요하다는 것이다. 예를 들어, 일 방문자수, 평균 체류 시간, 가입자수와 같은 비즈니스 지표에서부터, CPU 사용률, 메모리 사용률, 응답 시간등 기술 지표등이 있다.
   • 기존 개발에서는 요건 받아서 개발하고, 운영으로 던져버렸기 때문에, 사용자들이 서비스에 만족하는지 운영에는 문제가 없는지에 대한 피드백이 전혀 없었다. 이 Metric을 팀 전체에 공유하고 꾸준하게 추적함으로써, 팀 전체가 서비스의 상태를 인지하고, 협업을 통해서 이에 대한 개선 작업을 진행할 수 있게 되는 것이다.

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

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

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

Devops 기반의 팀의 개발 싸이클

1. 사용자의 needs 분석. VoC 수집
2. 사용자 스토리 작성 (요구 사항 작성)
3. 사용자 스토리에 대한 scope 정의 및 우선순위 지정
4. Stakeholder에 대한 리포팅 및 관리 (내부 영업, 보고 등)
5. 다른 프로젝트와 연관성(dependency) 관리
6. 필요의 경우 솔루션 (오픈소스 또는 상용) 평가 및 도입
7. 개발!! (디자인, 빌드, 테스트, 데모.-iterative way)
8. 테스팅. 실 사용자 대상 테스팅 포함
9. 서버에 배포
10. Security 관리, Compliance 관리 (개인 정보 보호, 국가별 법적 사항 확인등)
11. 서비스 운영, 모니터링.
12. 대 고객 지원 (Customer Support) – 추가 하였음

• 이런 프로세스를 한마디로 정리 해보면 결국 Devops 기반의 개발팀의 특징은, 한 팀내에서 모든 개발, 테스트, 배포 운영이 이루어진다는 것이고, 가장 중요한 것은, 운영을 통해서 사용자의 피드백을 접수하고, 이것이 새로운 요구 사항으로 연결되는데, 이 싸이클이 매우 빠르며 연속적이고 서로 연결 되어 있다 라는 것이다.
• 기존 개발팀은 기획팀이 요구사항을 개발팀에 던지고, 개발팀은 개발 내용을 운영에 던지는, waterfall 모델 처럼, 각 팀이 개발 단계별로 자기 역할을 한 후에, 다음 단계로 던지고 잊어 버리는 (fire & forget) 형태라면, Devops 형태의 개발팀은, 던지는 것이 아니라 과정 내내 같이 수행한다.
• 요구 사항을 개발팀에 넘겨도, 개발팀과 계속 협의를 하면서 요구 사항을 구체화 하고, 개선하며, 개발중에 운영인원과 같이 협의 하면서 최적의 구조를 논의 하면서 개발이 진행된다.

Devops 팀의 개발자의 필요 역량

• 코딩능력은 필수
  • Devops 엔지니어는 기본적으로 개발자를 기본으로 하고 있기 때문에, 개발을 위한 기본적인 코딩 능력.
  • 만약에 운영이나 시스템쪽에 치우친 엔지니어라면 자동화를 만들 수 있는 스크립트 작성 능력 등은 필수이다.
• 다른 사람과 잘 협업하고 커뮤니케이션할 수 있는 능력
  • Devops는 앞서 설명한바와 같이 큰 틀에서 협업 문화이다.
  • 시작 자체가 개발과 운영간의 소통 문제를 해결하고자 한것이기 때문에, 다른 팀원의 의견을 존중하고 문제를 함께 해결해나갈 수 있는 오픈 마인드 기반의 커뮤니케이션 능력이 매우 중요하다.
• 프로세스를 이해하고 때로는 그 프로세스를 재 정의할 수 있는 능력
  • 마지막으로, Devops는 언뜻 보기에는 정형화된 프로세스가 없어 보일 수 있지만, 테스트 자동화, 배포, 그리고 요구 사항에 대한 수집 및 정의등은 모두 프로세스이며, 해당 팀의 모델이나 서비스의 성격에 따라서 만들어나가야 한다.
  • 그래서, 프로세스를 이해하고 준수하며, 같이 만들어나갈 수 있는 능력을 가져야 한다.

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

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

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

• 비지니스에 대한 이해
  • 오픈 마인드, 커뮤니케이션 및 협업 능력

• Devops 팀의 엔지니어는 부족한 부분을 메꾸기 위해서 공부는 필수이다.

• 그보다 더 중요한 것은 경험이다.

• 운영은 직접 겪어 보기전에는 알 수 없다.

• 그리고 오픈 마인드 기반으로 커뮤니케이션을 해가면서 문제를 풀고 협업하는 능력은 책이 아니라 직접 겪어야 얻을 수 있는 능력이다.