2018.04.10

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

Isaac Sacolick | InfoWorld

많은 기술 조직이 이제 데브옵스를 중시하고 있다. 대개 상반되는 다음 두 가지 ‘임무'와 문화를 통합시키는 방안으로 간주한다 :

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

2018.04.10

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

Isaac Sacolick | InfoWorld

많은 기술 조직이 이제 데브옵스를 중시하고 있다. 대개 상반되는 다음 두 가지 ‘임무'와 문화를 통합시키는 방안으로 간주한다 :

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

X