DevOps를 실행하는 방법

1단계 - 구성 요소 선택

첫 번째 단계는 작게 시작하는 것입니다. 현재 프로덕션에 있는 구성 요소를 선택하세요. 종속성이 적고 인프라가 최소화된 단순한 코드 베이스를 갖춘 구성 요소를 고르는 것이 좋습니다. 구성 요소는 팀의 DevOps 구현에 관한 시험의 장이 되어줄 것입니다.

2단계 - 스크럼과 같은 애자일 방법론의 채택 고려

DevOps는 스크럼과 같은 애자일 작업 방법론과 함께 사용되는 경우가 많습니다. 스크럼과 같은 방법과 관련된 모든 리추얼이나 관행을 채택할 필요는 없습니다. 스크럼에서 일반적으로 채택하기 쉽고 빠르게 가치를 제공하는 세 가지 요소는 백로그, 스프린트 및 스프린트 계획입니다.

DevOps 팀은 스크럼 백로그에서 작업을 추가하고 우선 순위를 지정한 다음 해당 작업의 일부를 특정 작업을 완료하기 위한 고정된 기간인 스프린트로 가져올 수 있습니다. 스프린트 계획은 어떤 작업이 백로그에서 다음 스프린트로 이동하는지 결정하는 과정입니다.

3단계 - GIT 기반 소스 제어 사용

버전 제어는 협업을 강화하고 릴리스 주기를 단축할 수 있는 DevOps 모범 사례입니다. Bitbucket과 같은 도구를 사용하면 개발자가 소프트웨어를 공유하고, 협업하고, 병합 및 백업할 수 있습니다.

브랜치 모델을 선택하세요. 이 문서에서는 개념의 개요를 살펴봅니다. GitHub 흐름은 이해하기 쉽고 구현하기 쉽기 때문에 Git을 처음 접하는 팀에게 좋은 출발점입니다. 트렁크 기반 개발을 선호하는 경우가 많지만, 더 많은 규율이 필요하고 Git을 처음 시도하기가 더 어렵습니다.

4단계 - 소스 제어와 작업 추적 통합

소스 제어 도구를 작업 추적 도구와 통합하세요. 특정 프로젝트와 관련된 모든 것을 한곳에서 볼 수 있으면 개발자와 경영진이 상당한 시간을 절약할 수 있습니다. Git 기반 소스 제어 리포지토리에서 업데이트한 Jira 이슈의 예시는 아래와 같습니다. Jira 이슈에는 소스 제어에서 Jira 이슈에 대해 수행한 작업을 집계하는 개발 섹션이 포함됩니다. 이 이슈에는 브랜치 1개, 커밋 6개, 풀리퀘스트 1개와 빌드 1개가 있었습니다.

5단계 - 테스트 작성

CI/CD 파이프라인에는 다양한 환경에 배포된 코드가 제대로 작동하는지 확인하기 위한 테스트가 필요합니다. 코드에 대한 단위 테스트를 작성하는 것으로 시작하세요. 높은 목표는 90%의 코드 범위이지만, 겨우 시작한 경우라면 비현실적인 목표입니다. 코드 범위의 기준선을 낮게 설정하고 시간이 지나면서 단위 테스트 범위의 기준을 점차 늘리세요. 백로그에 작업 항목을 추가하여 이를 해결할 수 있습니다.

프로덕션 코드에서 발견된 버그를 수정할 때는 테스트 기반 개발을 사용하세요. 버그를 발견하면 버그가 있는 환경에서 장애를 일으키는 유닛 테스트, 통합 테스트 및/또는 시스템 테스트를 작성하세요. 그런 다음 버그를 수정하고 이제 테스트를 통과하는지 관찰하세요. 이 프로세스는 시간이 지남에 따라 코드 범위를 유기적으로 늘려줍니다. 테스트 환경이나 스테이징 환경에서 버그가 발견된 경우 테스트는 코드를 프로덕션으로 승격할 때 코드가 제대로 작동하고 있다는 확신을 줄 것입니다.

처음부터 시작할 때 이 단계는 노동 집약적인 작업이지만 매우 중요합니다. 테스트를 통해, 팀은 최종 사용자에게 코드 변경 사항을 공개하기 전에 코드 변경이 시스템 동작에 미치는 영향을 확인할 수 있습니다.

단위 테스트

단위 테스트로 소스 코드가 올바른지 확인하며 CI/CD 파이프라인의 첫 번째 단계로 실행해야 합니다. 개발자들은 녹색 경로, 문제가 있는 입력, 알려진 코너 케이스에 대한 테스트를 작성해야 합니다. 테스트를 작성할 때 개발자는 입력과 예상 출력을 가정할 수 있습니다.

통합 테스트

통합 테스트는 두 구성 요소가 서로 올바르게 통신하는지 확인합니다. 입력과 예상 출력을 가정하세요. 이 테스트는 어떤 환경에나 배포하기 전 CI/CD 파이프라인의 첫 번째 단계입니다. 일반적으로 이 테스트를 제대로 실행하려면 단위 테스트보다 더 광범위한 가정이 필요합니다.

시스템 테스트

시스템 테스트는 시스템의 엔드투엔드 성능을 검증하고 시스템이 각 환경에서 예상대로 작동하고 있다는 확신을 줍니다. 구성 요소가 받을 수 있는 입력을 가정하고 시스템을 실행하세요. 그런 다음, 시스템이 필요한 값을 반환하고 나머지 시스템을 올바르게 업데이트하는지 확인하세요. 테스트는 각 환경에 배포한 후에 실행해야 합니다.

6단계 - 구성 요소 배포를 위한 CI/CD 프로세스 구축

CI/CD 파이프라인을 구축할 때는 여러 환경에 배포하는 것을 고려하세요. 팀이 단일 환경에만 배포하는 CI/CD 파이프라인을 구축하면 하드 코딩을 하게 됩니다. 인프라와 코드를 위한 CI/CD 파이프라인을 구축하는 것이 중요합니다. 먼저 각 환경에 필요한 인프라를 배포하기 위해 CI/CD 파이프라인을 구축하는 것으로 시작하세요. 그런 다음 코드 배포를 위한 또다른 CI/CD 파이프라인을 구축하세요.

파이프라인 구조

이 파이프라인은 테스트 환경에 배포하기 전에 단위 테스트와 통합 테스트를 실행하는 것으로 시작합니다. 시스템 테스트는 환경에 배포한 후에 실행됩니다.

인프라

환경 간의 인프라 차이로 인해 해당 환경에서 실행하는 소프트웨어를 올바르게 실행하기 어렵게 만듭니다. 소프트웨어가 올바르게 실행되려면 방화벽 규칙, 사용자 권한, 데이터베이스 액세스 및 기타 인프라 수준 구성 요소는 알려진 구성이어야 합니다. 수동 인프라 배포는 올바르게 반복하기 어려울 수 있습니다. 이 프로세스에는 여러 단계가 있기 때문에, 기억에 의존하여 올바른 매개 변수로 각 단계를 올바른 순서로 실행하려고 하면 오류로 이어질 수 있습니다. 이러한 문제와 다른 문제를 완화하려면 가능한 경우 항상 코드로 인프라를 정의해야 합니다.

인프라는 AWS CloudFormation, Terraform, Ansible, Puppet 또는 Chef를 비롯한 다양한 도구를 사용하여 코드로 정의할 수 있습니다.

인프라 배포를 위한 파이프라인을 여러 개 작성하세요. 코드 작성과 마찬가지로, 인프라 배포를 모듈식으로 유지하는 것이 좋습니다. 가능한 경우 필요한 인프라를 분리된 하위 집합으로 나누세요. A, B, C 및 D가 서로 종속할 수 있는 인프라 구성 요소의 추상이라고 가정해 보겠습니다. 예를 들어, A는 EC2 컴퓨터이고 B는 S3 버킷일 수 있습니다. 인프라 구성 요소 A만 구성 요소 B에 종속되는 종속성은 동일한 CI/CD 파이프라인에 함께 보관될 가능성이 높습니다. A, B 및 C가 D에 종속하지만 A, B 및 C는 독립적인 경우의 종속성은 여러 CI/CD 파이프라인으로 나누어야 합니다. 이 경우에는 4개의 독립적인 파이프라인이 있습니다. 이 인스턴스에서는 다른 3개의 구성 요소가 모두 종속하는 D에 대해 파이프라인 1개를 만들고 A, B, C에 대해 1개씩 만들어야 합니다.

코

CI/CD 파이프라인은 코드를 배포하기 위해 구축되었습니다. 이전 작업 덕분에 인프라가 이미 사용 가능하기 때문에, 이러한 파이프라인은 보통 간단하게 구현할 수 있습니다. 여기서 중요한 고려 사항은 테스트, 반복성, 그리고 잘못된 배포에서 복구하는 능력입니다.

반복성은 시스템을 손상시키지 않고 동일한 변경 사항을 반복적으로 배포할 수 있는 능력입니다. 배포는 재입력이 가능하고 멱등성이 있어야 합니다. 배포는 기존 상태에 수정자를 적용하는 대신 시스템 상태를 알려진 구성으로 설정해야 합니다. 첫 번째 배포 이후에 수정자가 제대로 작동하는 데 필요한 시작 상태가 변경되었으므로, 수정자 적용을 반복할 수 없습니다.

반복할 수 없는 업데이트의 간단한 예시는 구성 파일에 데이터를 추가하여 업데이트하는 것입니다. 구성 파일에 행을 추가하거나 그와 비슷한 수정 기법을 사용하지 마세요. 추가를 통해 업데이트하면 구성 파일에 수십 개의 중복 행이 생길 수 있습니다. 그 대신, 구성 파일을 소스 제어의 올바르게 작성된 파일로 대체하세요.

이 원칙은 데이터베이스 업데이트에도 적용해야 합니다. 데이터베이스 업데이트는 문제가 발생할 수 있으며 자세한 사항에 주의를 기울여야 합니다. 데이터베이스 업데이트 프로세스를 반복 가능하고 내결함성 있도록 만드는 것이 중요합니다. 복구가 가능하도록 변경 사항을 적용하기 직전에 백업을 수행하세요.

또다른 고려 사항은 잘못된 배포에서 복구하는 방법입니다. 배포가 실패하고 시스템이 알 수 없는 상태이거나 배포가 성공하면 경보가 트리거되고 문제 티켓이 들어오기 시작합니다. 이 상황을 처리하는 데는 일반적으로 두 가지 방법이 있습니다. 첫 번째 방법은 롤백입니다. 두 번째 방법은 기능 플래그를 사용하고 알려진 양호한 상태로 돌아가기 위해 필요한 플래그를 해제하는 것입니다. 기능 플래그에 관한 자세한 내용은 이 문서의 8단계를 참고하세요.

롤백은 잘못된 배포가 감지된 후 이전에 알려진 양호한 상태를 환경에 배포합니다. 롤백의 경우 처음에 계획이 이루어져 있어야 합니다. 데이터베이스를 다루기 전에 백업을 수행하세요. 이전 버전의 코드를 빨리 배포할 수 있도록 하세요. 테스트 또는 스테이징 환경에서 롤백 프로세스를 정기적으로 테스트하세요.

7단계 - 모니터링, 경보 및 계측 추가

DevOps 팀은 각 환경에서 실행 중인 애플리케이션의 동작을 모니터링해야 합니다. 로그에 오류가 있습니까? API 호출 시간이 초과됩니까? 데이터베이스가 크래시합니까? 시스템의 각 구성 요소에 문제가 있는지 모니터링하세요. 모니터링에서 문제가 감지되면 누군가 문제를 해결할 수 있도록 문제 티켓을 제기하세요. 문제 해결의 일부로, 문제를 발견할 수 있는 추가 테스트를 작성하세요.

버그 수정

문제에 대한 모니터링 및 대응은 프로덕션 소프트웨어 실행의 일부입니다. DevOps 문화를 갖춘 팀은 소프트웨어 운영을 소유하고 사이트 신뢰성 엔지니어(SRE)의 행동을 차용합니다. 문제의 근본 원인 분석을 수행하고 문제를 감지하는 테스트를 작성하고 문제를 해결하고 이제 테스트가 통과하는지 확인하세요. 이 프로세스는 처음에는 많은 작업이 수반되는 경우가 많지만, 기술 부채를 줄이고 운영 애자일이 유지되므로 장기적으로는 이익을 얻을 수 있습니다.

성능 최적화

기본적인 상태 모니터링이 마련되었다면 그 다음 단계에서는 성능 조정이 자주 이루어집니다. 각 시스템이 어떻게 실행되는지 살펴보고 느린 부분을 최적화하세요. Knuth가 언급했듯이 “조기 최적화는 만악의 근원입니다.” 시스템에 있는 모든 것의 성능을 최적화하지 말고 가장 느리고 리소스 사용이 많은 부분만 최적화하세요. 모니터링을 통해 느리고 리소스 사용이 많은 구성 요소를 찾아낼 수 있습니다.

8단계 - 기능 플래그를 사용하여 카나리아 테스트 구현

카나리아 테스트를 사용하려면 테스트 사용자가 포함된 허용 목록을 통해 기능 플래그에 있는 각각의 새 기능을 래핑하세요. 새 기능 코드를 환경에 배포된 후에는 허용 목록에 있는 사용자에 대해서만 실행합니다. 새 기능을 각 환경에 먼저 사용하게 후에 다음 환경으로 넘어가세요. 새 기능을 한 지역에서 사용하는 동안 메트릭, 경보 및 기타 계측에 주의하며 문제의 징후가 있는지 확인하세요. 특히 새로운 문제 티켓이 증가하는지 살펴보세요.

다음 환경에도 적용하기 전에 환경의 문제를 해결하세요. 프로덕션 환경에서 발견되는 문제는 테스트 환경이나 스테이징 환경의 문제와 동일하게 처리해야 합니다. 문제의 근본 원인을 파악한 후에는 테스트를 작성하여 문제를 파악하고 수정 사항을 구현하고 테스트가 통과하는지 확인하고 CI/CD 파이프라인을 통해 수정 사항을 승격하세요. 문제가 감지된 환경에 변경 사항이 완전히 적용되는 동안, 새 테스트는 통과하고 문제 티켓의 개수는 감소할 것입니다.