데브옵스의 도입과 활용, 접근법

 

많은 기술 조직이 이제 데브옵스를 중시하고 있다. 대개 상반되는 입장 차이를 통합시키는 것이 중요하다.

- 애자일(Agile) 개발 팀은 빠른 속도로 비즈니스 요구사항을 충족하고, 애플리케이션을 변화시켜야 한다.

- 반면 운영 팀은 시스템 성능을 유지시키고, 컴퓨팅 환경을 안전하게 보호하고, 컴퓨팅 리소스를 관리해야 한다.

애자일 팀은 운영 팀이 느리고 경직되어 있다고 생각한다. 반면 시스템 엔지니어는 애자일 개발자들이 운영과 관련된 필요사항을 지원하지 않고, 무모하게 행동해 애플리케이션 배포가 생산 환경에 문제를 발생시키도록 만든다고 생각한다.

일반적으로는 그럴 수 있다. 그러나 두 팀은 각각 ‘동기 부여 요소’, ‘개념’, ‘도구’가 다르다. 그리고 이런 ‘불일치’ 및 ‘부조화’가 비즈니스 문제를 초래할 수도 있다. 계속 규모가 커지는 신생 창업회사를 예로 들어보자. 개발 속도와 애질리티(민첩성)에 미치는 영향은 최소화 하면서 안정성을 보장해주는 운영 절차를 발전시켜야 한다. 대기업은 신뢰도를 낮추지 않고, 또는 규제를 준수하면서 더 빠르게 고객이 이용하는 애플리케이션과 내부 워크플로를 개선할 방법을 찾아야 한다.

 

 

데브옵스는 이런 문화적 ‘상충’, 운영 원칙들, 애플리케이션을 빠르게 배포하는 동시에 안정적으로 운영하고, 상충과 저하를 줄이는 새로운 베스트 프랙티스를 제시하는 데 목적을 두고 있다. 통상 운영 단계를 자동화하고, 구성을 표준화하는 프랙티스(실천법)를 제시하는 방법으로 문제를 극복하고, 목적을 달성한다.

- 개발 팀의 경우, 코드 개발에서 테스트, 보안 적용, 여러 환경에서의 애플리케이션 운영과 관련된 단계들을 표준화 및 자동화하는 프랙티스들이다.

- 그리고 운영 팀의 경우, 생산 환경의 문제를 더 빨리 해결하고, 여러 도메인을 감시하고, 인프라를 구성 및 배포하는 과정을 자동화 할 수 있도록 도움을 주는 프랙티스이다.

데브옵스 프랙티스는 다음으로 구성되어 있다.

- 버전 관리 및 브랜칭(분기) 전략.
- 지속적인 통합과 딜리버리(CI/CD) 파이프라인.
- 애플리케이션 런타임 환경을 표준화하고 분리하는 콘테이너.
- 인프라 계층을 스크립팅 하는 IaC(Infrastructure as code).
- 데브옵스 파이프라인과 실행 애플리케이션의 상태 모니터링.

애자일 개발의 릴리스 관리 프랙티스

데브옵스는 수십 년 동안 이용된 기본적인 절차로 소프트웨어를 컴퓨팅 환경에 배포하는 도구와 프랙티스에서 시작된다. 이는 여러 개발 활동을 지원할 수 있도록 코드 기반을 분기시키면서 여러 개발 팀의 코드 변경을 관리하는 버전 관리(Version Control)과 여러 환경으로 배포하기 전의 버전 태깅 소프트웨어 릴리스로 구성돼 있다.

중요한 차이점은 데브옵스에는 사용하기 훨씬 쉽고, 애플리케이션 구축과 배포를 자동화하는 다른 기술과 더 효과적으로 통합되는 도구를 사용한다는 것이다. 또한 브랜칭(분기) 및 코드 병합 전략도 훨씬 더 표준화돼 있다. 현대적인 버전 관리 시스템으로 이를 쉽게 관리할 수 있다.

예를 들면, 많은 기업과 기관이 기트허브나 비트버킷과 같은 기트나 기타 버전 관리 도구들을 사용하고 있다. 빈도가 더 많고 복잡한 절차를 관리할 수 있도록 여러 클라이언트 애플리케이션, 통합용 API, 명령줄 도구들을 제공하는 도구들이다. 현재 대부분의 개발자가 최소 하나 이상의 버전 관리 기술을 사용하고 있으며, 따라서 과거처럼 표준을 구현하는 것이 어렵지 않다.

이런 도구들을 사용하는 기업과 기관은 생산과 테스트, 개발 브랜치(분기)를 표준화하고, 새로운 기능이나 생산 패치를 개발하는 절차를 수립하는 기트플로우(Gitflow) 같은 브랜칭 전략을 도입해 활용할 수 있다. 이런 브랜칭 전략은 여러 팀이 여러 개발 필요사항에 대해 협력하고, 검증되고 배포가 가능한 코드만 생산 브랜치에 적용할 수 있도록 도와준다. 이후 버전 태깅을 이용, 소프트웨어 릴리스의 일부인 파일과 소스 코드의 버전을 분류한다.

지속적인 통합 & 배포 및 릴리스 관리 자동화

생산 릴리스 이후 사용자 지원이 필요한 대부분의 조직, 데브옵스 프랙티스 실천이 초기 단계인 조직은 통상 메이저 릴리스와 마이너 릴리스 같은 ‘구성체’를 지원하는 전통적인 릴리스 관리 프랙티스를 활용한다. 사용자를 지원할 필요성이 적은 애플리케이션을 개발하는 더 ‘발전된’ 팀은 지속적으로 코드를 통합하고, 생산 환경에 변경된 코드를 전달하는 과정을 자동화하는 지속적인 배포 방식을 활용할 수도 있다.

또한 더 자주 릴리스를 하기 위해, 코드 확인에서 완전히 검증된 애플리케이션을 대상 컴퓨팅 환경에 배포하는 과정을 자동화 할 수 있는 방법을 모색한다. CI는 모든 소프트웨어 구성요소를 구현해, 배포 가능한 패키지로 통합하는 자동화 프로세스이다. CD도구들은 환경에 특정적인 변수를 관리하고, 애플리케이션을 개발, 테스트, 생산, 기타 컴퓨팅 환경으로 배포하는 과정을 자동화 한다. 이들 도구가 CI/CD 파이프라인을 구성한다.

CI/CD가 효율적인 자동화 프로세스가 되기 위해서는 파이프라인에서 지속적인 테스트가 이뤄져야 한다. 새로운 코드에 결함이나 문제가 없도록 만드는 테스트이다. 지속적인 통합 파이프라인에 단위 테스트를 포함시켜, 코드가 기존 단위 테스트를 훼손하지 않도록 만든다. 기타 코드 수준의 보안 문제와 코드 구조를 조사하는 테스트를 통합 프로세스의 일부로 도입해 활용할 수 있다. 런타임 환경이 필요한 자동화된 기능 및 작업을 지속적인 딜리버리 파이프라인의 일부로 자동화해 포함시키는 경우가 많다.

이런 자동화는 팀원들이 더 자주 안전하게 변화를 추진할 수 있는 행동 변화와 프랙티스 변화를 유도한다. 또한 더 자주 코드를 검사 및 테스트, 더 신속하게 문제점을 파악해 해결하도록 도와준다. 수동 배포는 오류에 취약하지만, 자동화는 이런 오류를 없애 준다. 그리고 팀원들이 사용자에게 새로운 기능을 전달하는 데 초점을 맞추고, 더 자주 배포를 할 수 있도록 도와준다.

마이크로서비스를 견인하는 컨테이너

CI/CD는 애플리케이션 전달을 자동화 시킨다. 그리고 이후의 컨테이너는 애플리케이션 운영 환경을 ‘패키징화’ 한다. 개발자는 호스트의 운영 체제를 공유하지만 분리되어 있는 계층에서 애플리케이션을 실행시키는 컨테이너의 구성 요건, 애플리케이션 요건, 운영 체제를 지정할 수 있다. 도커(Docker)와 쿠버네티스(Kubernetes)는 개발자들이 일관된 방식으로 애플리케이션 환경을 정의하도록 도움을 주는 컨테이너 기술이다.

 

코드를 통합해 배포하는 CI/CD 파이프라인과 각 애플리케이션의 컴퓨팅 니즈(필요사항)을 분리시키는 표준화된 컨테이너를 이용하면 큰 노력 없이 애플리케이션 서비스를 구현할 수 있다. 이렇게 하면, 비즈니스 요구사항을 여러 필요사항에 맞춰 배포, 확장, 활용할 수 있는 마이크로서비스로 전환해 구현할 수 있게 된다.

IAC 프로비저닝과 구성 자동화

코드 통합과 전달 자동화, 애플리케이션 '컨테이너화’는 애플리케이션 딜리버리에 도움을 준다. 그리고 다음 단계의 데브옵스 프랙티스는 인프라 및 클라우드 서비스 자동화 및 표준화에 도움을 준다.

과거에는 인프라 자동화 및 관리가 어려웠다. 운영 담당 엔지니어는 아키텍처를 선택한 후, 요구사항을 기준으로 여러 다양한 인프라 구성요소를 구축하고 구성해야 했다. 이런 아키텍처를 파악할 때 사용하는 구성 및 자산 관리 도구에는 ‘자동’과 ‘수동’ 프로세스를 혼합해 적용해야 했다. 또한 시대에 뒤떨어지거나, 중요한 정보가 누락된 경우가 많았다. 컴퓨터 환경도 경직되어 있었다. 환경 스케일링을 자동화하는 도구가 존재했지만, 특정 인프라에서만 사용 가능한 경우가 많았고, 따라서 이런 자동화를 구현하기 위해 또 다른 전문성이 요구됐다. 또한 스케일 여부 및 방법을 결정할 운영 데이터를 일부만 입수할 수 있었다.

그러나 현대의 클라우드 환경은 엔지니어의 이런 업무를 단순화시키는 사용자 인터페이스를 제공한다. 엔지니어들은 이런 도구를 사용, 가상 사설 네트워크를 구축하고, 보안 그룹을 구성하고, 이후 컴퓨팅 및 스토리지, 기타 필요한 서비스를 런칭할 수 있다.

그러나 데브옵스는 이를 한 단계 더 발전시킨다. 웹 인터페이스와 수동으로 구성한 컴퓨팅 리소스를 사용하는 대신, 코드로 이런 프로세스를 자동화 시킨다. 운영 담당 엔지니어들은 IaC 도구들을 사용해 인프라 셋업 및 관리를 스크립팅으로 구현해 자동화 할 수 있다. 또한 스크립팅에 환경 축소 및 확장을 포함시킬 수 있다. Chef, Puppet, Ansible, Salt는 운영 팀이 IaC 구현에 활용할 수 있는 4개 경쟁 기술들이다.

데브옵스 파이프라인과 애플리케이션 모니터링

생산 프로세스의 품질은 문제 모니터링, 경고, 복구 기능(성능)에 따라 크게 달라진다. 데브옵스 모니터링, 실행 애플리케이션과 서비스에 대한 사용자 경험 모니터링에도 동일한 원칙이 적용된다. 기업과 기관은 자동화와 컨테이너화, 표준화 애플리케이션 배포에 많은 투자를 한다. 그런데 이에 상응하는 정도를 모니터링에도 투자해야 한다.

서비스 수준의 모니터링을 예로 들자. 가장 낮은 수준의 모니터링은 컴퓨팅 리소스에 문제가 있을 때 이를 파악해 대응하는 인프라 모니터링이다. 현재 클라우드 환경은 인프라 문제에 대응할 수 있는 모니터링 및 경고 기능, 탄력적인 클라우드 기능을 제공하고 있다.

다음 계층은 데브옵스 자동화와 관련된 매트릭스를 모니터링 및 포착하는 도구들로 구성되어 있다. 개발자와 배포 가능한 서비스의 수가 증가하면서, 이런 도구들이 점점 더 중요해지고 있다. 이런 도구는 빌드에 문제가 발생했을 때 이를 경고한다. 또한 감사 도구는 문제를 진단할 수 있도록 도와준다.

마지막으로 애플리케이션 업타임과 성능, 기타 런타임 매트릭스를 모니터링 하는 도구들이 있다. 이런 모니터링 도구들은 API를 테스트하고, 단일 엔드포인트나 여러 트랜잭션에서 브라우저 테스트를 실시한다. API나 애플리케이션의 서비스 수준이 허용치 아래로 떨어졌을 때, 개발자에 이를 경고해주는 기능을 하는 모니터링 도구들이다.

데브옵스 프랙티스의 출발점

데브옵스 프랙티스는 많다. 성숙해 통합되기까지 시간이 걸릴 것이다. 이를 도입해 활용하는 순서가 정해져 있지는 않다. 또한 얼마나 자동화에 투자를 해야 할지 추천하기 어렵다.

그렇지만 기업 문화와 사고방식을 데브옵스 원칙에 일치시키는 것이 중요하다. 이후 비즈니스 니즈에 가장 잘 부합하는 프랙티스를 파악해야 한다. 예를 들면, 애플리케이션 성능 문제에 직면한 기업은 모니터링 도구를 가장 먼저 도입, 빠르게 근본 원인을 파악해 해결하는 것이 좋다. 클라우드 마이그레이션을 시작한 기업은 인프라를 코드로 배포하는 프랙티스를 도입할 수 있다. 또 표준 애플리케이션 개발 아키텍처를 구축한 기업은 CI/CD 파이프라인에 투자를 해야 할 것이다.

기술자들은 자동화에는 비용이 발생하고, 지속적인 배포가 필요 없는 조직도 존재한다는 점을 명심해야 한다. 무엇보다 비즈니스 니즈를 부합시키는 것이 베스트 프랙티스이다. 그리고 오류가 많은 반복되는 수동 작업을 중심으로 데브옵스 자동화를 추진할 필요가 있다.

 

 

출처

데브옵스 도입·활용은 이렇게··· 채택해야 할 접근법 5가지