파이프라인(Pipeline)이 갖는 가장 큰 의미는 자동화를 통하여 위험요소를 사전에 차단한다는 것이다. 파이프라인을 이용하여 석유나 가스를 옮기는 것을 생각해보자. 우리는 미리 정해진 통로를 이용하여 원하는 위치로 석유를 옮길 수 있다. 또한 이동 중간에 어떠한 불순물이나 위험요소가 들어오지 못하도록 차단할 수 있다.
소프트웨어 서비스(Software Service Application) 를 개발하고 배포하는 과정도 이와 같이 외부의 개입을 최소화하여 정해진 순서대로 흘러가도록 한다면 개발자(생산자)가 만든 결과물이 그대로 소비자에게 전달될 것이다. 중간에 불필요한 간섭이나 개입으로 인한 부작용이 사라지기 때문에 서비스 품질을 유지할 수 있다. 그래서 파이프라인은 지속적 전달(Continuous Delivery)에서 매우 중요한 역할을 하고 있다. 마치 공장 자동화를 하듯이 서비스 개발 및 유통단계를 파이프라인으로 자동화하면 생산 효율성과 품질을 동시에 높일 수 있다는 뜻이다. 다음은 파이프라인의 기대 효과를 설명하고 있다.
먼저, 작업절차를 자동화 할 수 있다. 모든 파이프라인은 일련의 흐름을 갖고 있으며 특별히 제어하지 않는 한 주어진 경로를 따라 내용물을 흘려보낸다. 우리의 서비스 개발도 비슷한 방식으로 자동화할 수 있다. 먼저, 버전 관리 시스템에서 최신 버전을 가져온 다음 테스트 코드를 작성한다. 테스트 코드는 요구사항 분석을 통해 정의한 입력, 출력을 바탕으로 만든다. 테스트 코드를 통과하도록 개발을 수행하고 자동으로 검증을 한다. 검증을 통과했다면 필요하다면 패키지로 만들어서 통합 검사를 수행한다. 통합 검사 후에는 성능 검사1와 기타 필요한 검사들을 수행하도록 한다. 모든 검사를 통과한 다음에는 운영환경에 배포할 수 있도록 저장소에 보관한다.
이 모든 과정이 파이프라인으로 연결되면 사람의 개입없이 항상 일사분란하게 자동실행 될 것이다. 각 진행단계마다 담당자를 찾아헤매며 수많은 사람에게 메일을 보내고 답장을 기다리는 시간이 줄어들 것이다.
다음, 작업절차를 시각화 할 수 있다. 파이프라인은 작업의 절차를 투명하고 간결하게 표현해준다. 모든 과정은 입력과 출력이 있는 작업들의 연결된 흐름으로 표현된다. 따라서 일련의 작업순서(Work Flow)를 파악함으로써 우리가 만들고 있는 서비스가 어떤 과정을 거쳐서 생산되는 지 쉽게 알 수 있다.
다음, 조건을 주어 작업흐름을 제어할 수 있다. 파이프라인의 갈래를 여러 개 두고 서로 의존성이 없는 작업의 경우 동시에 진행하도록 설계할 수 있다.
다음, 결과물인 서비스를 신뢰할 수 있다. 파이프라인이 문제 없이 흐르면 탄탄하고 꼼꼼한 검사를 거친 서비스가 만들어진다. 만약 생산과정 중 서비스 품질에 문제가 발생하면 즉각 알 수 있다. 파이프라인의 검사를 통과하지 못하면 그 위치에서 관리자 및 개발자게에 자동통보하도록 되어 있기 때문이다. 만약 기능 검증이 실패하면 새로운 기능이 포함된 서비스는 기능 검사를 통과하지 못하고 개발자에게 실패 내역을 통보하게 된다. 당연히 기능 검사를 통과하지 못했기 때문에, 이어지는 통합 검사와 성능 검사는 실시하지 않으며, 따라서 사용자에게 오류가 있는 서비스를 배포하는 일은 일어나지 않는다. 따라서 파이프라인을 모두 통과한 서비스에 대해 개발자와 운영자는 자신감을 가질 수 있게된다.
삼성전자의 갤럭시노트7 배터리 문제를 상상해보자. 삼성전자에게 악몽같은 일이었겠지만, 사용자 입장에서도 매우 불안했을 것이다. 그래서 삼성전자는 고객에게 사과하고 제품을 회수했다. 그리고 다음 제품인 갤럭시S8을 생산할 때 배터리 검사를 더욱 꼼꼼하고 철저하게 수행했다. 만약 갤럭시S8을 검사하는 과정에서 배터리가 폭발하는 일이 발생했다면 그 시제품은 폐기하고 다시 설계하는 과정을 거쳤을 것이다. 파이프라인은 전수조사라는 매우 부담되는 작업의 상시화를 가능하게 한다.
어쨌든 고객의 손에 제품이 전달된 이후에는 손쓸 방법이 없으므로 제품출시 전에 꼼꼼하게 검사하는 방법밖에 없다. 서비스 서버(Service Server)도 마찬가지로 접근해야 할 필요가 있다. 생각보다 많은 개발자들이 운영환경에 접속해서 문제를 파악하고 해결하기를 원한다. 이유는 개발단계에서 미처 생각하지 못한 부분들이 운영환경에서 나타나고 그 부분을 가장 빠르게 진단해 볼 수 있는 곳이 운영환경이기 때문이다.
그러나 이것은 이미 고객의 손에서 폭발한 배터리를 두들겨보는 일과 비슷하다. 서비스 서버도 운영환경에 배포하면 고객의 손에 이미 들어간 것이라고 볼 수 있다. 따라서 운영환경 안에 들어가서 기능을 검사하고 성능 및 안정성을 검사하는 것은 매우 초보적인 행동이다. 오히려 일어날 수 있는 모든 가능성을 제조과정에서 점검해 보고 품질에 대한 신뢰가 생긴 이후에 고객에게 전달하는 것이 필요하다. 파이프라인은 이러한 신뢰성 확보를 위한 좋은 전략이 될 수 있다.
그래서 파이프라인의 최종 결과물은 불변의 결과물(Immutable Artifact)이 되어야 한다. 고객에게 전달할 안전한 갤럭시S8은 모든 검사를 마친 후에 예쁘게 봉인된 새제품으로 만들어져서 고객에게 판매해야 하기 때문이다. 만약 고객이 받은 물건에 흠이 있다면 제품 판매처에서 새제품으로 교환해 주어야 한다.
만약 서비스 서버 인스턴스(Server Instance)가 문제가 있다면 즉시 이미지(Machine Image)를 이용하여 새 인스턴스로 교체해 주어야한다. 파이프라인의 핵심은 다음과 같다. 품질경영을 위한 좋은전략이며 소프트웨어라고 해서 차별을 둘 필요는 없다.2
- Stress Test [본문으로]
- 애자일 정신의 중심에는 서비스 품질이있다. 한 번에 모든 것을 완벽하게 처리해서 높은 품질의 소프트웨어를 만드는 것은 불가능하기 때문에 점진적이면서 기민해야하는 것이다. 천리길도 한 걸음부터가야하고 첫 술에 배부를수는 없다. 하지만 민첩함이라는 이름 때문에 무조건 빠른 속도가 핵심이라고 오해하는 경우가 많아서 안타까웠다. [본문으로]
'Sorry Architecture' 카테고리의 다른 글
| Terraform (0) | 2019.02.21 |
|---|---|
| Immutable Infrastructure (0) | 2019.02.21 |
| Circuit Breaker (0) | 2019.02.21 |
| Microservices, and Hangul(한글) (0) | 2019.02.21 |
| PhoenixServer (0) | 2019.02.20 |
