서버/인프라 엔지니어를 위한 DevOps를 읽고 정리한 내용입니다.
소프트웨어 개발 프로세스의 변화
종래의 소프트웨어 개발에서는 폭포수 방식을 자주 사용하였지만, 현재는 에자일 방식을 자주 사용한다.
폭포수(waterfall) 방식
: 최초에 요구를 수집하고 그 요구가 올바르다는 것을 전제로 해서 설계, 개발, 테스트와 같은 단계로 분할해서 진행
- 소프트웨어는 최종 테스트가 끝난 단계에서 처음으로 이용 가능해진다.
에자일(Agile) 방식
: 작은 단위로 설계 · 개발 · 테스트를 하고 완료된 것부터 작은 단위로 빈번하게 릴리즈를 하는 방식
- 최초에 요구를 수집하고, 우선순위를 매겨 순위가 높은 것부터 하나씩 설계, 개발, 테스트를 진행
개발과 운영의 대립
: 에자일 개발에 따라 개발 사이클이 빨라져 빈번하게 릴리즈하고 싶지만, 한편으로 운영 담당자는 시스템을 안정적으로 운용하기 위해 변화를 주고 싶지 않은, 서로 다른 대립구조가 문제가 되었다.
그리하여 주목받게 된 것이 DevOps라는 사고 방식이다.
DevOps란?
: 개발자(Dev)와 운영자(Ops)가 상호 협력해가면서 비즈니스의 가치를 실현하는 개념
- 이는 개념이므로 정해진 방법론이 있는 것은 아니다.
'Velocity 2009' 행사에서 존 올스포와 폴 해먼드의 프레젠테이션에서는 개발자와 운영자가 집중해야 하는 것에 대해 조직의 문화와 도구 관점에서 다음과 같이 제시하고 있다.
조직의 문화
- 상호 존중
- 상호 신뢰
- 실패에 대한 건전한 태도
- 상대를 비난하지 않기
도구
- 자동화된 인프라
- 버전 관리 시스템의 공유
- 원스텝 빌드와 배포
- 피처 플래그
- 소프트웨어 내에 새로운 기능을 넣었지만 이를 활성화할지는 설정 파일의 값에 따라 정해지는 방식
- 지표 데이터의 공유
- 서버의 부하나 접속 수와 같은 다양한 수치 데이터
- IRC와 인스턴트 메신저 봇
- 자동으로 IRC나 인스턴스 메신저에 글을 올리는 장치
조직에서의 DevOps 적용과 추진
DevOps뿐만 아니라 뭔가 새로운 것을 조직에 적용할 경우에 가장 먼저 생각해야 할 점은
- 도대체 지금 무엇 때문에 어려움을 겪고 있는가?
- 지금 해결해야 할 과제는 무엇인가?
이다.
방법이나 도구는 솔루션 중 하나에 지나지 않으며, 방법이나 도구의 도입 자체가 목적이 되지 않도록 해야 한다.
DevOps를 적용하는 흐름의 예
- 먼저 비즈니스와 IT의 관계에서 과제를 도출
- 과제에 대해 해결 우선순위를 설정
- 각각의 과제에 대해 향후 모습, 해결했는지를 확인하기 위한 지표 데이터, 달성 목표 시기, 과제 해결을 진척시키기 위한 체제를 정한다.
장기적으로는 아래와 같은 대처를 해야 한다.
- 현재 상황이 어떻게 될지를 지표 데이터를 보면서 확인
- 해결한 과제와 미해결 과제를 명확히 하고, 새로운 과제가 나온 경우에는 이 또한 관리
- 필요에 따라 과제의 우선순위를 정한다.
이렇게 하는 것이 DevOps의 적용 및 추진을 에자일 방식으로 진행하는 것이다.
DevOps에서의 도구 도입
도구 도입의 흐름
- 전체 모습이나 목표를 명확하게 정하자.
- 현재 어떤 상태인지, 목표보다 무엇이 부족한지를 분석하자.
- 도구 도입 계획을 생각해보고 그에 따라 단계적으로 도입하자.
- 도구 도입 후에 애초 생각했던 전체 모습이나 목표에 가까워졌는지, 과제가 없는지를 확인해서 대응하자.
DevOps 실현 후 작업의 수행
커뮤니케이션 도구를 사용해서 관련자 간 커뮤니케이션을 원활히 한다.- 개발 팀이나 운영 팀은
버전 관리 시스템에 시스템 소스코드나 설정 정보를 저장한다. - 다양한 요건이나 과제, 작업이나 오류를
프로젝트 관리 도구로 관리한다. 소프트웨어 테스트를 자동화한다.지속적 통합(CI) 도구를 사용해서 빌드와 테스트를 상시 실시한다.배포 도구를 사용해서 다양한 환경에 소프트웨어를 배치한다.- 개발이나 검증에는
가상화 도구를 사용해서 모두 같은 환경을 이용한다. 프로비저닝 도구나 구성 관리 도구를 사용해서 환경 구축을 자동화한다.모니터링 도구를 사용해서 운영 환경을 모니터링하고 그 결과를 받아서 문제를 발견하거나 프로세스를 개선한다.- 다양한 지표 데이터를 집약한
대시보드를 통해 모두가 정보를 볼 수 있게 한다.
도구 도입 순서
1. 버전 관리 도구
- 언제, 누가, 어떤 변경을 무엇 때문에 했는지를 추적할 수 있도록 해야 한다.
- 릴리즈 시기가 다른 복수의 버전을 병행해서 개발하는 경우도 많아지므로, 브랜치 기능이나 머지 기능을 잘 활용해야 한다.
2. 프로젝트 관리 도구 : GitHub의 Issue나 Readmine
- 빠른 사이클로 이루어지는 개발에서는 매일 새로운 요구와 요청 사항이 나오거나 장애 대응 및 개선 작업을 해야 한다.
- 이러한 내용은 프로젝트로서 항상 일원적으로 관리하고 우선순위 관리나 진척도 확인을 해야 한다.
3. 테스트 자동화 : JUnit이나 PHPUnit과 같은 유닛 테스트 도구나 브라우저 조작을 자동화하는 Selenium 같은 도구
- 가능한 한 개발 초기부터 테스트를 자동화할 것
- 테스트 시행 예상 횟수를 생각하면서 효과가 높은 것부터 대처할 것
4. 지속적 통합 도구 : Jenkins나 CircleCI
- Git과 같은 버전 관리 시스템에서 소스코드를 추출해서 Maven과 같은 빌드 도구로 빌드를 실행하고 자동화된 테스트를 실행
- 팀 전원이 통일된 사용법으로 이용하는 것이 중요 (ex. 빌드에 실패한 경우에는 빌드 실패를 수정하는 코드 이외에는 버전 관리 시스템에 커밋하지 않는다)
- 지속적 통합 도구에서 배포 도구를 호출해서 소프투웨어를 다양한 환경에 배포할 수도 있게 되는 것이 개발팀으로서 우션 목표로 삼아야 할 목표!
- 개선점을 프로세스에 포함시켜 도구 설정을 고치고 새로운 도구를 추가함으로써 속도나 품질을 좀 더 향상해가는 것도 중요!
- 여기까지는
개발 프로세스의 개선이라는 관점에서의 도구
5. 가상 환경 구축 도구
- 어떤 개발자의 개발 환경에서 동작한 코드가 다른 개발자의 환경에서는 동작하지 않는 형태의 문제나, 운영 환경에 배포해보니 동작하지 않는 식의 환경 차이에 따라 발생하는 문제
- 유사시에 수작업으로 환경을 구축함으로써 시간을 낭비하게 되는 문제
를 해결하는데 효과적
6. 프로비저닝 도구
- 환경을 설치 문서에 기반을 두고 수작업으로 구축하려고 하면 상당히 많은 시간이 걸리거나 작업할 때 실수하는 등의 문제를 예방
- 주의! 프로비저닝 도구 도입은 기존 작업 프로세스를 크게 바꾸게 된다. 도입할 때 장단점을 충분히 검토하자.
7. 모니터링 도구
1️⃣단순히 장애가 발생했는지 확인하는 것뿐만 아니라
다양한 데이터를 얻음으로써 2️⃣개발 프로세스의 문제, 3️⃣시스템에 혼재해 있는 과제, 4️⃣인프라 구성의 개선 포인트를 발견하고 5️⃣개발 사이클 전체에 대해 피드백하는 것도 목적 중 하나
- 도입할 때 주의할 점: 무엇을 위해 해당 지표 데이터를 모니터링하는지 사전에 정해두자.
- 다양한 데이터를 얻더라도 이를 이용해서 어떠한 행동으로 이어가지 못한다면 무의미해지기 때문
도구 도입의 올바른 접근 방법
- 도입 이유를 명확히 한다
- 그냥 유행하고 있으니 도구를 도입하겠다는 접근 방식 NO!
- 현재 어떤 과제가 있는지?
- 무엇을 우선 해결해야만 하는지?
- 도구는 사실상 표준인 것을 선택한다.
- 한 번에 많은 도구를 도입하지 말고 교육과 정착을 확인한다.
- 도구를 서서히 도입하면서 자신들의 업무 처리 방식을 조금씩 좋은 쪽으로 바꿔나가는 게 최상
- 유지보수는 스스로
