📍 90DaysOfDevOps - MichaelCade를 공부한 내용
📍 What is DevOps?를 공부하고 정리
DevOps란 무엇인가?
Dev와 Ops의 교집합이다!
여기서 드는 의문점!
- DevOps 영역의 시작과 끝은 어디인가?
- Dev 중 DevOps가 아닌 부분은?
- Ops 중 DevOps가 아닌 부분은?
- 왜 DevOps가 필요한가?
전형적인 소프트웨어 배포 과정
전형적인 소프트웨어 배포 과정은 다음과 같다.
배포 후에도 유저들이 소프트웨어에 접근가능하고 사용할 수 있는지 확인해야 한다.
- 애플리케이션에 문제가 있는가?
- 사용자 경험에 문제가 있는가?
- 높은 사용자 부하를 애플리케이션이 처리할 수 있는가?
초기 배포 후에도 '개선'이 이루어지게 된다.
- 새로운 기능 추가
- 성능 최적화
- 버그 수정
소프트웨어가 개선될 때마다 새로운 버전을 가지게 된다.
소프트웨어는 지속적으로 소프트웨어를 개선시키기 위해 다음 과정을 끊임없이 반복하게 된다.
소프트웨어는 지속적인 전달(Continuous Delivery)을 거친다.
DevOps는 이러한 CD 과정을 빠르고 버그 없이 이루어지도록 돕는다.
DevOps는 빠른 전달과 높은 품질을 보장한다.
DevOps가 해결하고자 하는 문제점
이제 배포 프로세스의 속도를 저하시키는 방해물을 알아보고 해당 방해물을 DevOps가 어떻게 해결하는지 살펴보자.
방해물 1) 개발자와 운영자 사이의 소통 부재와 협업 부재
애플리케이션을 배포하는 과정에서 주요한 두 부분은 애플리케이션 코드 작성과 애플리케이션을 배포하고 동작시키는 것이다.
- 개발자는 애플리케이션의 코드를 작성하지만 애플리케이션을 배포하고 동작시킬 수 없다. 또한 앱이 어디에 배포되는 지를 고려하지 않는다.
- 운영자는 애플리케이션을 배포하고 운영하지만 애플리케이션이 어떻게 동작하는지 모른다.
그래서 배포 가이드는 충분히 문서화되지 않게 되고 운영자는 애플리케이션을 배포하기 위해 더 많은 시간을 낭비하게 된다.
명확히 정의된 자동화 프로세스를 거치지 않고 관료적인 프로세스를 거치게 된다.
방해물 2) 지향점 충돌
개발자와 운영자는 서로 다른 지향점을 가지기 때문에 협업하기 어렵다! 높은 품질의 애플리케이션을 사용자에게 빠르게 전달하자는 공통된 목표와 각자의 지향점이 충돌하게 된다.
- 개발자는 '빠르게' 새로운 기능을 추가하고자 한다.
- 운영자는 '안정적으로' 시스템을 유지하고자 한다.
방해물 3) 보안
보안팀과 운영팀은 보안을 바라보는 관점이 다르다.
- 보안팀은 변화가 있을 때 '보안'에 영향을 주는지를 평가한다.
- 운영팀은 변화가 있을 때 '시스템의 유지성'에 영향을 주는지를 평가한다.
이를 평가하기 위해 길고 관료적인 과정을 거치게 된다.
그러나 DevOps는 프로세스의 속도를 낮추는 방해물들을 제거한다. DevOps에게는 보안 역시 프로세스의 속도를 낮추는 방해물이다.
대신 보안의 중요성을 강조하는 DevSecOps가 등장했다.
방해물 4) 애플리케이션 테스트
애플리케이션을 배포하기 전에 다양한 수준의 테스트를 거치게 된다. 자동화된 테스트에 완전히 의존할 수 없기 때문에 종종 수동 테스트도 진행한다.
애플리케이션 테스트는 배포 과정에서 중요한 부분이지만 이 역시 프로세스의 속도를 낮추는 방해물이다.
방해물 5) 수동 작업
배포 과정에서 수행되는 수동 작업은 프로세스의 속도를 낮추는 방해물이다.
수동 작업의 단점
- 에러의 위험성을 증가시킨다.
- 지식을 공유하기 어렵다.
- 수동 작업은 불투명하다.(누가 무엇을 언제 실행했는지를 추적하기 어렵다.)
- 회복시켜 이전의 상태로 되돌리기 어렵다.
결론
이처럼 배포 과정의 속도를 저하시키는 다양한 방해물들이 존재한다.
DevOps는 다음 방식을 통해 모든 방해물들을 제거하고자 한다.
- Fully Automated
- Streamlined Process
배포 과정에서의 방해물을 해결하는 DevOps의 개념
- DevOps는 하나의 특정한 도구나 개념이 아니라, 문화적 철학과 관행 그리고 도구들의 결합이다.
- DevOps는 소프트웨어를 빠르게, 높은 품질로 배포할 수 있도록 하는 어떠한 것이다.
- DevOps의 중요한 부분은 dev와 ops가 더 자주 협력하도록 하는 것이다.
개별적인 역할인 DevOps
많은 회사들이 DevOps를 각각 다른 방식으로 구현하고 있다.
많은 회사들 사이에서 DevOps가 점차 견고한 형태를 띄게 되면서 DevOps는 실제 역할로 진화했다.
DevOps 역할의 책임
- Fully Automated
- 방해물 없는 Streamlined Process
DevOps 업무
- DevOps 엔지니어로서 배워야할 도구와 개념은 무엇일까?
- DevOps 엔지니어의 역할과 책임은 무엇일까?
- Dev와 Ops로부터 DevOps의 경계선은 어디일까?
Concepts of Software Development
Dev와 관련해서 DevOps 엔지니어는
- 개발자들이 어떻게 일하는지 알아야 한다.
- Git Workflow를 알아야 한다.
- 애플리케이션이 어떻게 구성되어있는지 알아야 한다.(어떻게 다른 서비스, 데이터베이스와 연결되어있는지 구성을 이해해야 한다.)
- 자동화된 테스트의 개념을 알아야 한다.
Operating System & Linux Basic
Ops와 관련해서 DevOps 엔지니어는
- 애플리케이션을 동작시킬 인프라를 준비할 책임이 있다.
- 애플리케이션을 배포하는 서버는 보통 리눅스 서버이다.
- 리눅스의 기초 지식을 알아야 한다.
- 리눅스 명령어를 사용할 수 있어야 한다.
- 리눅스 파일 시스템을 알아야 한다.
Networking & Security
Networking & Security와 관련해서 DevOps 엔지니어는
- 방화벽, 프록시 서버를 다룰 수 있어야 한다.
- 로드 밸런서를 다룰 수 있어야 한다.
- HTTP와 HTTPS를 다룰 수 있어야 한다.
- IP, DNS를 이해하고 있어야 한다.
DevOps 엔지니어는 dev와 ops의 '기본'만 알면 된다.
각 분야별로 전문가들이 존재한다.
DevOps 엔지니어는 기본 개념들을 이해하고 애플리케이션이 동작할 서버를 준비한다.
Containers
오늘날 컨테이너는 소프트웨어 패키징 모델의 표준이 되고 있다.
따라서 DevOps 엔지니어는 가상화와 컨테이너에 대해 이해하고 컨테이너를 다룰 수 있어야 한다.
DevOps 엔지니어들의 한쪽에는 코드를 작성하는 개발자들이, 다른 한 쪽에는 안정적인 시스템을 제공하는 운영자들이 있다.
DevOps 엔지니어는 개발자가 개선한 코드를 빠르게 새로운 버전으로 배포해야 한다. 이것이 DevOps 엔지니어의 기본 역할이자 책임이다.
DevOps 엔지니어는 어떻게 빠르고 효율적인 자동화된 CI/CD를 제공할 수 있을까?
Build Automation & CI/CD
배포 과정에 대해 이해하고 있어야 한다.
- Build Tools & Package Manager
- 점점 많은 회사들에서 컨테이너를 표준으로 채택하고 있기 때문에 docker image가 애플리케이션 위에서 어떻게 동작하는지 인지하고 있어야 한다.
- Artifiact Repository
- 빌드된 도커 이미지는 곧바로 레포지토리에 저장된다.
- dockerhub, nexus와 같은 레포지토리를 생성하고 관리하는 방법도 이해해야 한다.
이는 순차적인 스탭이기 때문에 빌드 자동화 도구(ex. jenkins)를 이용해서 배포 과정을 자동화할 수 있다.
CI/CD 파이프라인은 DevOps 작업과 책임의 중심에 있기 때문에 DevOps 엔지니어는 애플리케이션을 위한 완전한 CI/CD 파이프라인을 구성할 수 있어야 하며 파이프라인은 연속적이어야 한다.
Cloud Providers
오늘날 회사들은 물리적인 인프라를 구성하는 대신에 클라우드에서 가상 인프라를 구성한다. 이는 비용 측면에서 이점을 가지기 때문이다.
따라서, 적어도 하나의 클라우드에 대해 배워야 한다.
Container Ochestration
이제 클라우드 위에서 컨테이너가 어떻게 관리되고 있는지를 알면 된다.
가장 인기 있는 컨테이너 오케스트레이션 도구는 kubernetes이다.
따라서, 쿠버네티스가 어떻게 동작하는지 이해해야 한다. 이로써, 쿠버네티스 클러스터를 관리할 수 있을 뿐만 아니라 클러스터에 애플리케이션을 배포할 수 있다.
Monitoring
수백개의 서버 위에서 수천개의 컨테이너가 실행되고 있다면 개별 애플리케이션의 성능을 어떻게 측정하고 쿠버네티스 클러스터의 문제점을 어떻게 발견할 수 있을까?
DevOps의 책임 중 하나는 실행 중인 애플리케이션와 쿠버네티스 클러스터의 서버가 잘 동작 중인지 모니터링하는 것이다.
Infrastructure as Code
production 환경 이외에도 테스트 환경이나 개발 환경 같이 다양한 환경들이 존재한다. 이 때 각 환경에서 수동으로 인프라를 구축하는 것은 에러 발생률을 높이고 많은 시간을 소모하기 때문에 비효율적이다.
두 가지 유형의 IaC 도구를 조합하여 사용한다면 인프라를 자동으로 구축하고 구축된 인프라 위에서 애플리케이션을 자동으로 배포할 수 있다.
- 인프라 프로비저닝 도구(ex. Terraform)
- 설정 관리 도구(ex. Ansible, Chef, Puppet)
DevOps 엔지니어는 하나 이상의 IaC 도구를 숙지하여 더 효율적이고 투명하고 쉽게 인프라를 구축해야 한다.
Scripting Language
개발과 운영을 위해 자동화된 작업(ex. cronjob)을 수행할 필요가 있다.
따라서, DevOps 엔지니어는 적어도 하나 이상의 스크립트 언어(운영체제에 종속적, ex. bash, powershell) 또는 프로그래밍 언어(운영체제에 독립적, ex. python ruby, go)를 알아야 한다.
파이썬은 오늘날 가장 인기있고 요구되며 배우기 쉬운 언어이다. 파이썬은 데이터베이스와 클라우드를 위한 라이브러리도 제공한다.
Version Control
IaC(Infrastructure as Code) 역시 애플리케이션 코드와 마찬가지로 버전 관리 시스템(ex. gitlab, github)을 사용하여 관리한다.
따라서, DevOps 엔지니어는 git도 알아야 한다.
그래서 무엇을 배워야 할까?
👉 각 카테고리 별로 하나의 도구를 배워라
👉 기왕이면 가장 유명하고 가장 많이 사용되는 도구를 배워라
더하여, DevOps 엔지니어는 각각의 도구들을 익혀야할 뿐만 아니라 이러한 도구들을 '조합'해서 사용할 수 있어야 한다.
DevOps vs SRE
DevOps는 자동화되고 간소화된 배포 프로세스를 구성하기 위해 수행해야 하는 작업이라고 정의할 수 있다.
반면에, SRE(Site Reliablility Engineering)는 배포 프로세스를 정확히 구현하는 방법과 DevOps 원칙을 구현하는 구체적인 방법이라고 정의할 수 있다.
그래서 많은 이들이 SRE가 DevOps 개념의 특정 구현이라고 말한다. 그러나 DevOps는 DevOps 자체 역할로 구현되었다.
정리하자면 SRE와 DevOps는 공통된 지향점을 갖는다.
하지만 역할로 구현된 DevOps는 '실용성'을 지향하기 때문에 빠른 배포에 집중한다.
그러나 SRE는 이름에서 알 수 있듯이 '신뢰성'에 중점을 두고 빠른 변화를 허용하면서 시스템을 안정적으로 유지한다.
SRE에 대해 더 자세히 알고 싶다면 다음 비디오를 참고하자.
