#90DaysOfDevOps - Plan > Code > Build > Testing > Release > Deploy > Operate > Monitor > - Day 5

계획 > 코드 작성 > 빌드 > 테스트 > 릴리즈 > 배포 > 운영 > 모니터링 >

오늘은 데브옵스 환경에서 애플리케이션의 시작부터 끝까지 개별 단계와 continuous cycle에 대해 집중적으로 살펴보겠습니다.

계획

개발팀이 다음 스프린트에서 출시할 기능과 버그 수정을 결정하는 계획 프로세스는 데브옵스 엔지니어가 참여하여, 앞으로 어떤 일이 발생할지 파악하고 개발팀의 결정이나 경로에 영향을 미치고, 그들이 구축한 인프라로 작업하도록 돕거나 그들이 다른 경로를 따를 경우 더 나은 방향으로 안내할 수 있는 기회입니다. 중요한 점은 개발자나 소프트웨어 엔지니어링 팀이 데브옵스 엔지니어의 고객이 되므로, 고객이 나쁜 방향으로 가기 전에 고객과 협력할 수 있는 기회라는 것입니다.

코드 작성

이제 계획 세션을 마치고 코드 작성 단계에 진입합니다. 이 단계에서 당신이 참여할 수 있는 역할 중 하나는 코드를 작성하는 동안 인프라에 대한 이해도를 높여서 어떤 서비스를 사용할 수 있는지, 그 서비스와 어떻게 상호작용할 수 있는지를 더 잘 이해할 수 있도록 돕는 것입니다. 또한, 코드 작성이 완료되면 해당 코드를 리포지토리에 병합하는 일도 중요한 역할입니다.

빌드

여기에서는 자동화 프로세스의 첫 번째로, 코드를 가져와서 사용하는 언어에 따라 변환하거나 컴파일하거나 해당 코드에서 도커 이미지를 생성할 수 있기 때문에, CI 파이프라인을 사용하여 이러한 프로세스를 자동화할 것입니다. 이렇게 함으로써, 코드를 변경하거나 새 코드를 추가할 때마다 일일이 수동으로 작업하는 것이 아니라, 자동화된 프로세스를 통해 더욱 효율적이고 일관성 있는 작업을 수행할 수 있게 됩니다.

테스트

빌드가 완료되면 몇 가지 테스트를 실행합니다. 개발 팀은 보통 어떤 테스트를 작성할지 제안할 수 있지만, 이를 실행해야 합니다. 테스트는 프로덕션에 문제가 발생하지 않도록 최소화하기 위한 시도입니다. 새로운 버그가 발생하지 않도록 보장하는 것은 불가능하지만, 최대한 이전에 작동하던 것이 깨지지 않도록 보장하기 위해 노력합니다.

릴리즈

테스트가 모두 통과되면, 애플리케이션 유형에 따라 릴리스 프로세스가 수행됩니다. 하지만 이 단계는 작업 중인 애플리케이션에 따라 생략될 수도 있습니다. 일반적으로, GitHub 리포지토리나 git 리포지토리에서 가져온 코드나 빌드된 도커 이미지를 프로덕션 서버에 배포하기 위해 레지스트리나 리포지토리에 저장합니다. 이를 통해 배포 프로세스가 진행됩니다.

배포

배포는 모든 개발과정의 최종 단계이기 때문에, 프로덕션 환경에 코드를 적용하는 과정입니다. 이 단계에서 비즈니스에서는 여러분과 소프트웨어 엔지니어링 팀이 지금까지 이 제품에 투자한 모든 시간과 노력의 가치를 실현할 수 있습니다.

운영

한 번 배포가 완료되면, 해당 제품이 운영되기 시작하게 됩니다. 운영에는 고객이 사이트나 애플리케이션을 사용할 때 발생하는 문제를 파악하고, 이에 대한 대처 방안을 마련하는 것이 포함됩니다. 예를 들어, 사이트가 느리게 실행되는 문제가 발생하면, 운영팀은 이유를 파악하고 피크 기간 동안은 서버 수를 늘리고, 사용량이 적은 기간에는 서버 수를 줄이는 자동 확장 기능을 구축할 수 있습니다. 또한, 운영 유형 메트릭 처리와 같은 다양한 작업도 수행됩니다. 가능한 경우에는 이러한 작업을 자동화하는 것이 좋습니다. 그러나, 몇 가지 단계를 수행해야 하는 환경에서는 자동화가 어려울 수도 있습니다. 그런 경우에는 가능한 한 자동화를 시도하면서도, 일부 작업을 수동으로 처리해야 할 수도 있습니다. 그리고, 자동화 프로세스에서는 운영팀이 배포가 발생했음을 알 수 있도록 몇 가지 유형의 알림을 포함하는 것이 좋습니다.

모니터링

위의 모든 부분이 마지막 단계로 이어지는데, 특히 운영 문제 자동 확장 문제 해결과 관련된 모니터링이 필요하기 때문입니다. 문제가 있다는 것을 알려주는 모니터링이 없다면 문제가 있는 것이므로 메모리 사용률 CPU 사용률 디스크 공간, API 엔드포인트, 응답 시간, 엔드포인트가 얼마나 빨리 응답하는지 등을 모니터링할 수 있으며, 이 중 큰 부분은 로그입니다. 개발자는 로그를 통해 프로덕션 시스템에 액세스하지 않고도 무슨 일이 일어나고 있는지 확인할 수 있습니다.

다듬기 & 반복

여태까지 수행한 프로세스를 검토하고 개선할 부분을 찾습니다. 그리고 이를 바탕으로 다시 계획 단계로 돌아가 전체 과정을 재진행합니다. 이는 지속적인 개선과 반복적인 프로세스 개선을 위한 사이클을 형성하며, 더 나은 제품과 높은 품질의 서비스를 제공하기 위한 필수적인 단계입니다.

Continuous

여러 도구들이 지속적인 프로세스를 달성하는 데 도움을 줍니다. 이 모든 코드와 클라우드 인프라 또는 모든 환경을 완전히 자동화하는 것이 궁극적인 목표이며, 이를 지속적 통합/지속적 배포/지속적 배포 또는 줄여서 "CI/CD"로 설명하기도 합니다. 이번에는 90일 후에 CI/CD에 대한 기본 사항을 예제와 함께 배울 수 있는 워크숍을 제공할 예정입니다.

Continuous Delivery

Continuous Delivery = 계획 > 코드 작성 > 빌드 > 테스트

Continuous Integration

이는 위에서 설명한 지속적 배포 단계와 릴리스 단계의 결과를 합친 것입니다. 이 단계는 성공과 실패 모두에 해당하며, 지속적 배포를 통해 피드백을 받거나 지속적 배포로 진행될 수 있습니다.

Continuous Integration = 계획 > 코드 > 빌드 > 테스트 > 릴리즈

Continuous Deployment

성공적인 CI 릴리스 후, CD 단계로 이동합니다.

성공적인 CI 릴리즈 = Continuous Deployment = 배포 > 운영 > 모니터링

위의 세 가지 개념은 데브옵스 라이프사이클의 각 단계를 간단히 정리한 것으로 볼 수 있습니다.

이전에 다룬 Day 3 를 약간 요약했었지만, 이제는 더 이해하기 쉬워진 것 같습니다.

자료

여기까지 왔다면 이 여정이 자신이 찾던 여정인지 아닌지를 판단할 수 있을 것입니다.

Day 6에서 봐요!