🧐 Today I Learned (TIL)

• DevOps 개념
• DevOps 엔지니어

---

1. DevOps 개념

1-1. DevOps 정의

'개발 (Dev)' 과 '운영 (Ops)' 의 합성어로 개발과 운영의 경계를 허물고 통합하고자 하는 문화나 철학을 뜻한다.

1-2. DevOps 역사

'DevOps'라는 단어는 2009년 'O'Relly Velocity Conference의 <하루에 10회 이상 배포하기: Flicker에서 Dev와 Ops의 협업>'에서 만들어졌다.

2009년에는 클라우드 서비스가 도입되지 않았던 상황이었다. 그 당시 '서버 장비 구매 > 서버 장비 위에 운영체제 설치 > 서비스를 운영하기 위한 환경 > 서비스 개발 > 개발 결과물 배포 > 운영' 플로우로 서비스가 만들어졌으며 개발팀과 운영팀으로 분리가 되어있었다. 이러한 구조속에서 개발팀과 운영팀은 커뮤니케이션 문제와 수 많은 갈등이 발생했다.

Flickr는 개발팀과 운영팀 사이에서 발생하는 이슈들의 해결책을 공유를 하게 되었고 'Patrick Debois'는 이 해결책을 통해 'DevOpsDays'라는 컨퍼런스를 주최하면서 'DevOps' 단어가 등장하게 되었다.

1-3. DevOps 필요성

소프트웨어 생애주기는 '소프트웨어 설계 > 개발 > 테스트 > 배포 > 운영 > 사용자들에 대한 지원 활동'으로 분리된다. 이러한 생애주기 속에서 규모가 큰 기업에서는 각 단계별로 기능 조직을 운영한다. 하지만 단계별로 분리한 만큼 각 조직간의 의사소통 문제와 병목 구간이 발생하는 문제점이 있다.

'Netflix'에서는 개발자가 소프트웨어의 모든 단계에 참여할 수 있는 'Full-cycle Developer' 모델을 제시했다.

1-4. DevOps 방법

DevOps는 문화이기때문에 방법이 없다. 하지만 '개발과 운영의 벽을 허물어 더 빨리 자주 배포하자'는 목표를 잡고 있다.

• 지속적 통합
• 지속적 배포
• 마이크로서비스
• IaC
• 모니터링과 로깅
• 소통 및 협업

---

2. DevOps 엔지니어

2-1. DevOps vs DevOps 엔지니어

개발자가 개발만이 아니라 운영에도 참여할 수 있는 환경이나 문화를 정착시키는 역할을 수행하는 것이 DevOps 엔지니어이다. DevOps 엔지니어는 개발자가 개발한 결과를 테스트하고 배포하고 로그를 확인할 수 있는 환경을 구축을 하여 개발자가 비즈니스 로직에만 집중할 수 있도록 도와주어야 한다.

DevOps 엔지니어가 맡은 역할이 많기 때문에 걱정할 수 있으나 조직이 성장하면서 업무 도메인이 세분화되기 때문에 부담이 덜어진다. DevOps의 주요 고객은 개발자이며 생산성을 높여주는 서비스를 제공해주어야 한다.

2-2. DevOps 팀 업무 도메인

조직의 규모나 구성에 따라 업무 도메인이 다를 수 있으나 대략 8가지로 나눌 수 있다.

• 네트워크

  • 가상 네트워크 및 물리 네트워크 구성
  • 프록시 / VPN 서버 운영
  • DNS 서버 운영

• 개발 및 배포 플랫폼

  • GitLab, GitHub와 같은 버전 관리 및 개발 협업 플랫폼 운영
  • CI/CD 파이프라인 시스템 구축 및 운영
  • QA 테스트 및 성능 테스트를 위한 환경 제공
  • 패키지 저장소 운영 및 배포 산출물 관리

• 오케스트레이션 플랫폼

  • K8S, ECS, Nomad와 같은 오케스트레이션 시스템 구축 및 운영
  • Airflow, Argo Workflows와 같은 워크 플로우 엔진 구축 및 운영

• 관측 플랫폼

  • 로그, 메트릭, 업타임, APM 정보를 관측할 수 있는 중앙화된 시스템 구축 및 운영
  • 주요 이벤트에 대한 알림 시스템 구축

• 클라우드 플랫폼

  • 개발자들이 활용할 수 있도록 클라우드 환경 운영 (자체 클라우드, 퍼블릭 클라우드 등)

• 보안 플랫 폼

  • LDAP, AD, SAML등을 활용하여 통합된 임직원 계정계 운영
  • 서버 및 데이터베이스 접근제어 시스템 구축 및 운영
  • 네트워크 방화벽 정책 관리

• 데이터 플랫폼

  • MySQL, DynamoDB, Redis와 같은 데이터베이스 구축 및 운영
  • RabbitMQ, Kafka, SQS등과 같은 메시징 서비스 구축 및 운영
  • 데이터 웨어하우스, BI 대시보드 구축 및 운영

• 서비스 운영

  • 개발자들과 협업하여 서비스 공동 운영

2-3. DevOps 팀 핵심 지표

• 장애 복구 시간, MTTR (Mean Time To Recovery)

  • 얼마나 빠르게 장애 상황에서 복구할 수 있는가?
  • 장애 복구 시간이 오래 걸린다면 인프라 자동화나 배포 파이프라인 최적화가 필요함을 알 수 있음

• 변경으로 인한 결함률 (Change Failure Rate)

  • 얼마나 자주 변경 사항으로 인해 장애가 발생하는가?
  • 변경으로 인해 결함이 자주 발생했을 경우 CI 파이프라인(테스트) 과정에 잘못됨을 알 수 있음

• 배포 빈도 (Deployment Frequency)

  • 얼마나 배포를 자주 하는가?
  • 배포 빈도가 낮을 경우 조직 내의 문화나 시스템적인 문제가 발생 했음을 알 수 있음
  • 시스템 자체가 거대하여 많은 시간이 소요된다면 기능을 더 세분화가 필요함을 알 수 있음

• 변경 적용 소요 시간 (Lead Time for Changes)

  • 변경사항을 프로덕션 배포에 걸리는 소요 시간은 얼마인가?

---

📚 참고

• https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249