새로운 회사를 위한 IT DevOps 프로세스를 설계해야 한다면 더 정확한 예측을 실현하고 애플리케이션 제공을 가속화하기 위해 무엇을 자동화하시겠어요?
모든 챕터 보기
IBM의 자동화 가치 서비스 소프트웨어 담당 부사장인 크리스 패럴은 "많은 기업이 애플리케이션 덕분에 존재하며, 이는 애플리케이션의 성능이 수익 이외의 가장 중요한 측정값이라는 것을 의미합니다."라고 말합니다. "애플리케이션을 제공하는 기업에 있어 속도는 애플리케이션의 품질을 판단하는 척도이자 무기입니다."
퍼렐은 하이퍼 배포 환경에서 조직이 지속적 통합 및 지속적 전달(CI/CD) 달성에 대해 생각하는 방식을 '완전히 바꾸는' 것이 중요하다고 말합니다. "배포가 며칠에 한 번씩 수행되는지를 이야기하는 것이 아니라, 기간당 업데이트 횟수에 대해 이야기해야 합니다." "기간이 짧을수록 더 많이 올라갈 수 있습니다."
IBM의 "Rethink & Automate" 시리즈는 일반적인 비즈니스 및 IT 프로세스를 완전히 새로운 관점에서 접근하고 자동화를 수용하여 재구상하도록 리더들을 초대합니다. 일반적인 DevOps 프로세스는 계획, 코딩, 구축 및 테스트, 릴리스, 배치, 운영 및 모니터링의 8단계로 구성된 순환적인 집합입니다. 8단계 중 하나라도 속도가 느려지면 전체 파이프라인의 속도가 느려집니다.
IBM의 한스 A.T. 데커스(Hans A.T. Dekkers)는 IBM 비즈니스 가치 연구소에서 발표한 논문 '더 스마트한 아키텍처의 속도'에서 "'디지털 태생'이 아닌 기존 대기업의 경우 속도 개선이 더욱 중요할 수 있다."라고 썼습니다. "S&P 500에 속한 기업의 평균 수명이 1960년대에는 60년이었다가 현재는 20으로 줄어들고 이직률이 높아지는 추세가 계속 빨라지는 것을 보면 속도 부족의 영향을 체감할 수 있습니다."
CI/CD를 달성하려면 개발자는 한 번 구축하여 어디에나 배포하고 파이프라인을 지속적으로 관리할 수 있어야 합니다. 퍼렐은 자동화를 사용하여 일반적인 주기를 재설계하는 방법을 다음과 같이 설명하면서, 성과를 보려면 "DevOps에 대한 완전한 헌신과 지속적인 배포에 도달하고 달성하려는 열망"이 필요하다고 지적합니다.
모니터링에서 관측 가능성으로 전환
"뜻밖의 이야기일수도 있겠지만, 제가 IT DevOps 프로세스를 처음부터 다시 설계한다면 마지막 단계인 모니터링에 집중할 겁니다. “기존 모니터링 공간에서 도구를 제거하고 최대한 빨리 관측 가능성으로 전환해야 합니다. 더 많은 워크로드에 관측 가능성을 적용할수록 모든 운영팀 구성원이 개발자 또는 다른 전문가의 도움 없이 문제에서 근본 원인을 빠르고 정확하게 찾아낼 수 있다는 점을 기억하세요."
IT에서 관측 가능성이란 분산 애플리케이션과 애플리케이션이 실행되는 하드웨어 및 네트워크에서 발생하는 성능 데이터의 지속적인 스트림을 집계, 연관 및 분석하기 위한 소프트웨어 도구 및 관행을 의미합니다. 이를 통해 애플리케이션과 네트워크에서 더 효과적으로 문제를 해결하고, 디버깅할 수 있습니다. 관측 가능성은 더 빠르고, 분산되고, 동적인 클라우드 네이티브 애플리케이션 배포의 특성에 더 잘 대응하기 위해 애플리케이션 성능 모니터링(APM)이 자연스럽게 진화한 것입니다.
모니터링 외에도 이미 DevOps 프로세스의 모든 단계에는 프로세스를 가속화, 통합 및 자동화하는 도구가 여럿 있습니다. 퍼렐은 "기존의 모니터링 도구는 특히 수동 설정, 재구성 및/또는 재배치로 인해 작업 속도가 느려지기 때문에 가속화된 파이프라인과 최신 기술 스택에 어려움을 겪고 있습니다."라고 말합니다. 관측 가능성 플랫폼은 이해, 즉 컨텍스트를 통한 가시성을 제공하고 모든 변화에 실시간으로 적응하므로 항상 최신 상태를 유지합니다.
또한 관측 가능성은 애플리케이션 코드, 코드 기반 인프라, 하드웨어 스택 간의 경계가 모호해짐에 따라 애플리케이션과 인프라를 하나로 묶어 주는 역할을 합니다. 퍼렐은 "파이프라인 전반에 걸친 속도의 필요성을 생각하면, 플랫폼은 애플리케이션 코드 자체만큼 유연하고 속도가 빨라야 합니다."라고 말합니다.
더 빠른 속도와 더 뛰어난 결과를 위해 관측 가능성 자동화
"관측 가능성은 절대적으로 꼭 필요하지만, 이 작업은 반드시 자동화되어야 합니다."라고 퍼렐은 말합니다. 분석 엔진이 탑재된 자동화된 관측 가능성 플랫폼을 사용하면 플랫폼 자체에서 문제를 파악하고, 권장 사항을 제시하고, 해결할 수 있습니다. 문제 진단이 자동으로 수행되므로 여기에 시간을 할애할 필요가 없습니다.
IT DevOps 프로세스 전반의 자동화는 속도 외에도 다양한 이점을 제공합니다. 지속적인 피드백을 통해 개발자가 신속하고 단호하게 조치를 취하고 지속적으로 개선할 수 있습니다. 향상된 오류 감지 기능은 오류가 '치명적인' 영향을 미치기 전에 개발자가 문제를 해결할 수 있게 지원합니다. 마지막으로 시스템 통합은 팀 협업을 개선하여 팀 내 모든 IT 및 DevOps 전문가가 동료의 작업 속도를 저하시키지 않으면서 코드를 변경하고, 피드백에 응답하며, 문제를 해결할 수 있도록 지원합니다.
'소프트웨어 제공 속도'라고도 하며, 개발 및 업데이트 속도(및 조직이 DevOps 프로세스에서 개선에 집중해야 하는 속도)를 나타내는 용어
소프트웨어(또는 하나의 업데이트)가 자본을 창출하는 데 걸리는 시간
비즈니스(및 관련 애플리케이션)가 비즈니스 환경의 변화에 효과적으로 대응할 수 있는 정도
DORA 2018 Accelerate: State of DevOps 보고서(ibm.com 외부 링크)에 따르면 '우수한 성과를 올리는 조직'은 코드 배포 빈도가 46배 더 높고, 커밋에서 배포까지 걸리는 시간이 2,555배 더 짧고, 변경 실패율은 7배 더 낮고, 인시던트 복구 속도는 2,604배 더 빠릅니다. 배포 빈도가 높아지면 새로운 소프트웨어의 릴리스가 빨라지고 인시던트 해결 속도가 수천 배 빨라지는 기하급수적인 이점을 누릴 수 있습니다. "제가 가장 좋아하는 상관관계 중 하나는, 더 빠르게 배포하더라도 변경 실패율이 낮아진다는 겁니다."라고 퍼렐은 이야기합니다.
조직이 프로세스의 8단계를 모두 자동화하면 더 높은 품질과 더 나은 고객 만족도를 기대할 수 있습니다. 그러나 퍼렐은 자신이 가장 좋아하는 이점은 속도라고 말합니다. "은행에서 한 가지 사례를 보았습니다. 제품이 실제로 출시되기 전에 아이디어를 얻는 데 약 10~12개월이 걸립니다. 새로운 DevOps 프로세스를 도입한 후로는 그 기간이 2주로 짧아졌습니다."라고 퍼렐이 말합니다. "시장에서의 성공에 대한 절대적이고 직접적인 결과를 볼 수 있습니다."