당신은 주제를 찾고 있습니까 “데브 옵스 – DevOps 는 무엇인가요? 현직 DevOps 엔지니어, AWS Hero 가 이야기하는 DevOps 이 정확한 의미.“? 다음 카테고리의 웹사이트 ppa.maxfit.vn 에서 귀하의 모든 질문에 답변해 드립니다: https://ppa.maxfit.vn/blog. 바로 아래에서 답을 찾을 수 있습니다. 작성자 DevOpsArt 이(가) 작성한 기사에는 조회수 13,132회 및 좋아요 246개 개의 좋아요가 있습니다.
데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다.
데브 옵스 주제에 대한 동영상 보기
여기에서 이 주제에 대한 비디오를 시청하십시오. 주의 깊게 살펴보고 읽고 있는 내용에 대한 피드백을 제공하세요!
d여기에서 DevOps 는 무엇인가요? 현직 DevOps 엔지니어, AWS Hero 가 이야기하는 DevOps 이 정확한 의미. – 데브 옵스 주제에 대한 세부정보를 참조하세요
DevOps 에 의미는 정확히 무엇일까요?
Development + Operation 으로 간단하게 정의할 수 있는 이야기일까요?
개발과 운영을 하면 데브옵스 엔지니어일까요?
DevOps 의 정확한 정의에 대하여 이야기해봅니다.
현직 DevOps 엔지니어, AWS Hero 가 직접 이야기하는
DevOps 의 정의.
본강의는 https://www.inflearn.com 강의,
Infrastructure as Code : Terraform and AWS 강의에 일부분입니다.
모든 강의를 아래 사이트에서 평생 소장할 수 있습니다.
강의링크: https://www.inflearn.com/course/데브옵스-테라폼-aws?inst=3a2e8ca7
데브 옵스 주제에 대한 자세한 내용은 여기를 참조하세요.
데브옵스 DevOps란 무엇일까요? – 네이버 블로그
데브옵스 DevOps는 개발(development)과 운영(operation)을 결합해 탄생한 개발 방법론 입니다. 시스템 개발자와 운영을 담당하는 정보기술 전문가 …
Source: m.blog.naver.com
Date Published: 10/9/2022
View: 9288
데브옵스란? – 브런치
데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 합성어로서, 2009년 처음으로 등장하게 된 단어입니다. 개발과 운영의 경계를 허물고 …
Source: brunch.co.kr
Date Published: 10/6/2022
View: 3486
데브옵스 엔지니어(DevOps Engineer) 역할, 자격증, 로드맵 소개
DevOps 엔지니어는 프로세스, 툴, 방법론을 도입하여 코딩에서 배포, 유지관리 및 업데이트에 이르는 소프트웨어 개발 라이프사이클 전체에 걸쳐 요구 사항 간의 균형 …
Source: www.redhat.com
Date Published: 4/9/2022
View: 6779
DevOps란 무엇입니까? – AWS
DevOps는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합입니다. 기존의 소프트웨어 개발 및 …
Source: aws.amazon.com
Date Published: 12/3/2022
View: 3195
데브옵스(DevOps)란? | NetApp
DevOps는 애플리케이션 개발의 품질과 속도를 개선하고 신규 또는 수정된 소프트웨어 기능이나 제품의 릴리즈 주기 단축을 장려하는 새로운 철학이자 프레임워크입니다.
Source: www.netapp.com
Date Published: 2/18/2022
View: 5549
[주말판] 데브옵스, 왜 소문만 무성하고 실제로는 잘 구현되지 …
2007년 IT 업계에서는 데브옵스(DevOps)라는 움직임이 일어나기 시작했다. 소프트웨어 개발과 IT 운영 사이의 간극을 메워줄 방법론으로서 각광받기 …
Source: m.boannews.com
Date Published: 4/30/2021
View: 4525
[DevOps] 데브옵스란?
데브옵스(DevOps)는 이전에 개발과 운영으로 분리되어 있던 장벽을 무너뜨려 엔지니어에게 두가지의 자질을 모두 요구하며 개발자의 생산성과 안정성을 …
Source: well-made-codestory.tistory.com
Date Published: 7/3/2022
View: 8116
데브옵스(DevOps) vs 데브섹옵스(DevSecOps) | 요즘IT – 위시켓
데브옵스(DevOps)와 데브섹옵스(DevSecOps), 두 가지 방법론은 얼핏 비슷해 보이지만 사실 상당히 다른 접근방식을 취하고 있습니다.
Source: yozm.wishket.com
Date Published: 11/29/2021
View: 3385
데브옵스 가속화를 위한 엔지니어링 성공요소는 무엇인가?
진정한 데브옵스의 철학은 애자일 철학과 마찬가지로 고객 중심의 가치를 빠르면서도 안정적으로 전달하는 것입니다. 단순 자동화 툴 몇 개를 도입하는 …
Source: www.samsungsds.com
Date Published: 8/20/2022
View: 8413
주제와 관련된 이미지 데브 옵스
주제와 관련된 더 많은 사진을 참조하십시오 DevOps 는 무엇인가요? 현직 DevOps 엔지니어, AWS Hero 가 이야기하는 DevOps 이 정확한 의미.. 댓글에서 더 많은 관련 이미지를 보거나 필요한 경우 더 많은 관련 기사를 볼 수 있습니다.
주제에 대한 기사 평가 데브 옵스
- Author: DevOpsArt
- Views: 조회수 13,132회
- Likes: 좋아요 246개
- Date Published: 2020. 9. 21.
- Video Url link: https://www.youtube.com/watch?v=QAj3fsttKM4
위키백과, 우리 모두의 백과사전
데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.
목적 [ 편집 ]
데브옵스의 목적은 전반적인 배포 파이프라인에 걸쳐있다. 여기에는 개선된 배치(deployment) 주기를 포함하며 다음으로 이어질 수 있다:
제품 출시까지 걸리는 기간(time to market) 단축
새로운 판의 더 낮은 실패율
픽스 간 짧아진 리드 타임(상품 생산 시작부터 완성까지 걸리는 시간)
복구 시 더 빠른 평균 시간 (새로운 릴리스의 충돌 및 그 밖에 현재의 시스템를 비활성화하는 상황에서)
단순한 프로세스들은 데브옵스 접근을 사용하여 더 프로그래밍 가능하게 되고 유동적으로 되고 있다.[1] 데브옵스는 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것이 목적이다. 더 가끔씩 자동화가 이러한 목표를 지원한다.
데브옵스 툴체인 [ 편집 ]
계획 – 목적을 수행하기 앞서 방법이나 절차 등을 미리 생각하여 계획. 코드 – 코드 개발 및 검토, 버전 관리 도구, 코드 병합 빌드 – 지속적 통합(CI) 도구, 빌드 상태 테스트 – 테스트 및 결과가 성능을 결정 패키지 – 애플리케이션 디플로이 이전 단계 릴리스 – 변경사항 관리, 릴리스 승인, 릴리스 자동화 구성 – 인프라스트럭처 구성 및 관리, IaC(Infrastructure as Code) 도구 모니터링 – 애플리케이션 성능 모니터링, 최종 사용자 경험.
데브옵스 DevOps란 무엇일까요?
데브옵스 DevOps는 개발(development)과 운영(operation)을 결합해 탄생한 개발 방법론 입니다. 시스템 개발자와 운영을 담당하는 정보기술 전문가 사이의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론인데요.
데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 합성어로서, 2009년 처음으로 등장하게 된 단어입니다. 개발과 운영의 경계를 허물고 하나의 팀으로서 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 뜻합니다.
여태까지는 개발자가 개발을 완료하면 운영자에게 전달해야하는 루트가 있었습니다. 개발을 완료하더라도 운영자를 통해 배포되어야 했고, 운영자는 개발자가 만든 프로그램을 이해하는 시간이 필요했습니다. 이 과정에서 커뮤니케이션에 문제가 생긴다면 시간이 더 걸리게 되겠죠.
데브옵스는 이러한 상황을 타개하고자 나온 새로운 문화, 혹은 환경입니다.
이처럼 데브옵스 적용이 가능한 툴을 묶어 하나의 체인 형식으로 모든 과정인 기획-개발-빌드-테스트-배포-모니터링-산출물-KnowledgeBase을 묶어 사용할 수 있게 되는 것입니다.
DevOps의 등장은 고객뿐 아니라 조직에 있어서도 중요한 국면을 차지합니다. 점점 더 빠른 속도의 개발을 원하는 요즘 시대에 발맞출 수 있는 개발 속도가 가능하기 때문입니다.
따라서 많은 기업들이 DevOps를 적용시키고 있는데요. 단순히 개발 팀과 운영 팀을 통합해 만드는 것은 데브옵스가 아닙니다. 개발에서 운영까지 매끄럽게 진행할 수 있는, 각기 다른 기술을 갖고 있는 이들이 모여서 팀을 이루는 것입니다. 따라서 데브옵스 엔지니어는 개발자가 시스템 관리도 한다 / 운영자가 개발도 한다 로 정의하는 것이 아니고, 운영과 개발 사이에서 지속적 전달과 지속적 통합을 진행할 수 있도록 데브옵스 환경을 조성하는 사람이라고 볼 수 있습니다.
그렇다면 데브옵스를 적용할 경우 장점에 대해 알아보겠습니다.
속도
데브옵스를 적용하면 자연스레 작업 속도가 빨라집니다. 개발과 운영 사이를 왔다갔다하는 커뮤니케이션 작업이 사라지기 때문입니다. 또한 고객의 요구를 더 빠르게 받아들여 개선할 수 있고, 시장 변화에 더 잘 적응할 수 있는 등 더 효율적으로 비즈니스 성과를 만들어낼 수 있습니다.
빠른 배포
속도가 빨라졌기 때문의 프로그램의 배포가 빨라집니다. 배포가 빨라진다는 것은 타사와의 시장 경쟁 구도에서 우위를 차지한다는 것을 뜻합니다.
협업 강화
DevOps는 말 그대로 협업을 중시하는 문화입니다. 따라서 자연히 개발과 운영 간의 협업이 강화되고 협력해 많은 책임을 공유하게 됩니다. 이 책임 공유는 팀을 보다 효율적으로 만들고 프로그램의 품질을 높이는 결과를 가져옵니다.
품질 향상
여러단계를 거치지 않고 내부에서 지속적 전달과 통합을 이뤄내면 버그의 경우도 비교적 빨리 잡아낼 수 있고, 변경사항을 바로바로 적용시킬 수 있어 프로그램의 품질과 완성도를 한단계 높입니다. 또한 모니터링을 통해 실시간으로 성능을 파악할 수 있습니다.
보안
자동화된 규정 준수 정책과 세분화된 제어 및 구성 관리 기술로 보안을 높은 수준으로 유지할 수 있습니다.
이처럼 데브옵스는 개발과 운영을 통합하여 제품 출시 및 조직의 효율성을 끌어올리기 위한 문화라 볼 수 있습니다. 따라서 고객과 회사, 그리고 팀까지 모두에게 이점을 가져다 줄 수 있죠.
그렇다면 DevOps는 어떤 방법으로 이뤄질까요? 대체적으로 다음과 같습니다.
지속적 통합
지속적 전달
마이크로 서비스
코드형 인프라
모니터링 및 로깅
협업
지속적 통합과 지속적 전달 방식으로 소프트웨어를 개발하고, 마이크로 서비스로 단일 애플리케이션을 작은 서비스의 집합으로 구축해 설계합니다. 코드형 인프라는 앞선 개발 기술을 통해 인프라를 프로비저닝하고 관리하는 방식을 뜻합니다. 물론 지표와 로그를 모니터링해 상황을 파악해야겠죠. 그리고 이 모든 과정들을 원할하게 진행하기 위한 협업이 필수입니다.
따라서 데브옵스 엔지니어는 다음와 같은 역량을 가지고 있어야 합니다.
출처 : https://github.com/devJang/developer-roadmap
이처럼 엔지니어 개발자에게는 여러 역량이 요구됩니다.
시스템 관리 및 개발에 대한 지식은 당연히 필요하겠죠. 이를 다 이해할 수 있어야 운영과 개발 양쪽 모두와 함께 소통하며 작업 환경 조성에 일조할 수 있으니까요. 따라서 또 다른 중요한 건 조건은 커뮤니케이션을 원할하게 할 수 있는 인적 관리 역량입니다.
DevOps는 어떤 기술이나 특정한 팀을 만드는 것을 뜻하는 것이 아닙니다. 말 그대로 문화입니다. 이러한 문화가 기업에 자리잡게 된다면 기업의 목표 향상과 그를 위한 프로젝트 달성에 큰 도움이 될 것입니다.
하이프마크에서는 기업의 웹앱로그데이터의 클라우드 적재와 ETL 파이프라인 구성 그 외 클라우드 내 데이터분석 환경 구축 및 분석 시각화 서비스를 함께 제공하고 있습니다.
AWS, GCP등 클라우드 이전 매니지드서비스 및 웹앱로그데이터 태깅 적재 관련 문의사항이 있으시면 하이프마크에 문의 주세요
감사합니다.
데브옵스 엔지니어(DevOps Engineer) 역할, 자격증, 로드맵 소개
DevOps 엔지니어는 프로세스, 툴, 방법론을 도입하여 코딩에서 배포, 유지관리 및 업데이트에 이르는 소프트웨어 개발 라이프사이클 전체에 걸쳐 요구 사항 간의 균형을 맞춥니다.
개발 팀과 IT 운영팀의 기술과 목표는 서로 다를 수 있습니다. 개발자는 애플리케이션에 새로운 기능을 도입하길 원하는 반면, 운영팀은 애플리케이션 출시 후 안정성을 유지하고자 합니다.
결국 DevOps에서는 프로세스의 통일 및 자동화가 핵심이며 DevOps 엔지니어는 코드, 애플리케이션 유지관리, 애플리케이션 관리를 통합하는 데 중요한 역할을 합니다. 이 모든 태스크에는 개발 라이프사이클에 대한 이해뿐 아니라 DevOps 문화와 그 철학, 사례, 툴이 필요합니다.
여러분이 DevOps로 커리어를 전환하거나 회사 내 DevOps 도입을 촉진하기 위한 교육 과정을 원하게 될 수 있습니다. 그렇다면 DevOps 엔지니어가 되려면 어떻게 해야 할까요?
DevOps란 무엇입니까? – Amazon Web Services(AWS)
조직이 소프트웨어 개발과 인프라 관리 프로세스의 자동화 및 간소화를 통해 더 빠르게 혁신할 수 있도록 지원하는 몇 가지 주요 방식이 있습니다. 이러한 방식 대부분은 적절한 도구를 사용해 수행됩니다.
기본 방식 중 하나는 소규모 업데이트를 자주 수행하는 것입니다. 이 방식을 통해 조직은 고객을 위해 더 빠르게 혁신할 수 있습니다. 이러한 업데이트는 기존 릴리스 방식에서 수행되는 낮은 빈도의 업데이트보다 일반적으로 좀 더 증분적인 특성을 갖습니다. 소규모로 자주 업데이트하면 각 배포의 위험이 줄어듭니다. 팀에서 오류의 원인이 되는 최근 배포를 확인할 수 있으므로 더 빠르게 버그를 해결할 수 있습니다. 업데이트 소요 시간과 규모는 다르지만, DevOps 모델을 사용하는 조직은 기존 소프트웨어 개발 방식을 사용하는 조직보다 훨씬 더 자주 업데이트를 배포합니다.
또한, 조직은 마이크로 서비스 아키텍처를 사용하여 애플리케이션의 유연성과 혁신의 속도를 높일 수 있습니다. 마이크로 서비스 아키텍처는 복잡한 대규모 시스템을 간단하고 독립적인 프로젝트로 결합 해제합니다. 애플리케이션은 많은 개별 구성 요소(서비스)로 분할되며, 각 서비스는 단일 목적 또는 기능으로 한정되고 피어 서비스 및 전체 애플리케이션과는 별개로 운영됩니다. 이 아키텍처는 애플리케이션 업데이트를 위한 조정 오버헤드를 줄이고, 각 서비스가 이를 담당하는 작고 민첩한 팀과 연결되면 조직이 좀 더 신속하게 움직일 수 있습니다.
하지만 마이크로 서비스와 릴리스 빈도 증가의 조합은 배포 수를 현저히 늘려 운영 문제로 이어질 수 있습니다. 따라서 지속적 통합 및 지속적 전달과 같은 DevOps 방식을 사용하면, 이러한 문제를 해결하고 조직이 안전하고 안정적인 방식으로 신속하게 업데이트를 제공할 수 있습니다. 코드형 인프라 및 구성 관리와 같은 인프라 자동화 방식은 잦은 변경에 대해 컴퓨팅 리소스를 탄력적이고 대응적으로 유지하는 데 도움이 됩니다. 또한, 모니터링과 로깅의 사용도 엔지니어가 애플리케이션 및 인프라의 성능을 추적하여 문제에 신속하게 대응할 수 있게 하는 데 도움이 됩니다.
이러한 방식들을 함께 사용하면 조직이 더 빠르고 안정적으로 고객에게 업데이트를 제공할 수 있습니다. 다음은 주요 DevOps 방식의 개요입니다.
데브옵스(DevOps)란?
DevOps는 애플리케이션 개발의 품질과 속도를 개선하고 신규 또는 수정된 소프트웨어 기능이나 제품의 릴리즈 주기 단축을 장려하는 새로운 철학이자 프레임워크입니다.
DevOps 사례는 애플리케이션 개발 팀(Dev)과 해당 IT 운영 팀(Ops) 팀 간의 원활하고 지속적인 커뮤니케이션, 협업, 통합, 가시성 및 투명성을 장려합니다.
“Dev”와 “Ops” 간의 이러한 긴밀한 관계는 초기 소프트웨어 계획부터 코딩, 구축, 테스트 및 릴리즈 단계와 구축, 운영 및 지속적인 모니터링에 이르는 DevOps 라이프사이클의 모든 단계에 걸쳐 계속됩니다. 이러한 관계는 추가 개선, 개발, 테스트 및 구축에 대한 지속적인 고객 피드백 루프를 추진하는 원동력이 됩니다. 이러한 노력이 제공하는 결과 중 하나는 필요한 기능 변경 또는 추가 기능을 더 빠르고 지속적으로 릴리즈할 수 있다는 것입니다.
혹자는 DevOps 목표를 문화, 자동화, 측정 및 공유(CAMS)의 네 가지 범주로 그룹화하는데 DevOps 툴을 사용하여 이 모든 영역을 지원할 수 있습니다. 이러한 툴을 사용하면 개발 및 운영 워크플로우의 효율성 및 협업 기능을 개선하여 통합, 개발, 테스트, 구축 또는 모니터링과 관련된 기존의 시간 소모적인 수동 또는 정적 작업을 자동화할 수 있습니다.
[주말판] 데브옵스, 왜 소문만 무성하고 실제로는 잘 구현되지 않는가?
[보안뉴스 문정후 기자] 2007년 IT 업계에서는 데브옵스(DevOps)라는 움직임이 일어나기 시작했다. 소프트웨어 개발과 IT 운영 사이의 간극을 메워줄 방법론으로서 각광받기 시작했으며, 이를 통해 불필요한 비용들이 절감되고 비효율성이 개선될 것이 기대됐다. 당시 기업들의 85%는 새로운 제품과 서비스를 빠르게 개발해 출시하는 것이 가장 중요한 임무라고 느끼고 있었고, 그에 대한 답으로 데브옵스는 매우 적절해 보였다. 데브옵스를 하지 않는 게 이상하게 보일 지경이었다.그리고 15년이 흘렀다. 아직도 데브옵스는 뜨거운 주제이고 많은 기업들이 긍정적으로 보고 있으며 여러 가지 형태의 실험과 시도가 이뤄지고 있다. 하지만 2007년의 분위기는 온데 간데 없다. 2007년 당시의 분위기가 이어졌다면 지금은 온 세계가 데브옵스로 개발을 하고 있어야 하는데, 아직도 데브옵스는 ‘마이너’로 남아 있다. 그 동안 데브옵스가 주는 새로운 어려움들도 발견됐고, 데브옵스를 본격적으로 도입하려다 실패한 사례들도 적잖게 나왔다. 데브옵스 프로젝트의 75%가 실패로 끝났다는 통계도 있을 정도다.그도 그럴 것이 데브옵스란 게 하나의 정해진 규정이나 프레임워크가 아니기 때문이다. 세상에는 다양한 형태의 데브옵스가 있으며, 기업들은 각자의 상황에 맞게, 또한 기술의 발전과 변화에 맞춰서 알맞은 데브옵스의 형태를 갖춰야 하고, 필요한 데브옵스의 요소들을 훈련해서 구축해야 한다. 따라서 데브옵스를 도입한다는 건 말처럼 쉬운 일이 아니다. 그리고 시작과 끝이 딱 정해진 프로젝트도 아니다. 하지만 제대로만 된다면 그 결과는 충분히 긍정적이고 아름다울 수 있다. 데브옵스를 제대로 구축하기 위해 넘어야 할 산을 정리해 보면 다음과 같다.데브옵스를 실제로 적용함에 있어서 가장 간과되는 것 중 하나는 ‘애초에 왜 데브옵스를 정의해야 하는가?’를 규정하는 단계다. 대부분 데브옵스의 일반론적인 장점 한두 가지 숙지하는 것으로 이 과정을 그냥 넘어간다. 그 일반론을 우리 회사의 이야기로 조정하고, 조정된 내용을 전 조직에 알리고 교육시켜야 하는데 이를 전혀 진행하지 않는다. 초반에 이를 짚고 넘어가느냐 아니면 그냥 흐지부지 넘어가느냐에 따라 이 다음의 일들이 전혀 다른 방향으로 전개된다.오늘 날의 관리자들과 결정권자들은 예전보다 훨씬 더 실무에 관여하려는 경향을 가지고 있다. 지시만 내리고 결과만 보고받는 형태의 리더십은 구닥다리가 된 지 오래다. 특히 IT와 관련된 일에 있어서는 더 그렇다. 지금의 업무 환경에 있어서 IT 기술이 얼마나 중요한 역할을 하는지 이해하고 있기 때문이다. 하지만 그렇다고 해서 IT 기술에 대한 깊은 이해가 한 번에 탑재되지는 않는다. 그러므로 데브옵스를 도입하려고 할 때 가장 이 부분을 다뤄야 한다.최첨단 개발론이라는 데브옵스를 우리 회사에 적용했을 때 수익이 100배씩 늘어난다거나 영화에서 보는 것과 같은 최첨단 기술이 당장 책상 위에 올라오지 않는다는 걸 이해시켜야 한다. 관심이 높고 지식이 어설프면 기대치가 높게 설정되곤 하는데, 이걸 반드시 현실적인 수준으로 낮춰줘야 한다. 그래야 같은 곳을 바라보고 함께 달려갈 수 있게 된다.포춘 1000대 기업 중 75%는 사업에 꼭 필요한 애플리케이션들을 메인프레임과 같은 예전 IT 환경에 탑재시켜 운영한다. 하지만 이는 장기적으로 현명한 결정이 될 수 없다. 왜냐하면 보다 현대화 된 인프라를 사용하는 경쟁사들에 비해 확장성이나 유연성이라는 측면에서 떨어질 수밖에 없고, 이러한 차이들이 계속 누적되면 언젠가 뒤쳐질 수밖에 없다. 게다가 오래된 IT 인프라는 유지 비용도 더 높다. 참고로 세계 최대 규모 은행 50개 중 45개에서와 세계 최대 규모 항공사 5개 중 4개, 세계 최대 도소매 기업 10개 중 7개에서 가장 많이 사용되는 언어는 코볼인 것으로 조사되기도 했다.오늘 날의 개발자들은 세이즈(SASE), 도커(Docker), 큐버네티스(Kubernetes) 등과 같이 비교적 새롭고, 최첨단이라고 부를 수 있는 도구 및 작업 환경을 선호한다. 요즘 개발자들에게 익숙한 클라우드 네이티브 도구들 중 기존 IT에서 제대로 작동되는 건 거의 없고, 기존 환경에서는 프로젝트만 새로 하려면 메인프레임부터 새로 보충해야 하나 생각해야 하고, 메인프레임을 더한다는 것과 클릭 몇 번으로 클라우드에서 자리를 늘린다는 것은 그 난이도나 복잡성, 가격의 측면에서 완전히 다른 것이기 때문이다.클라우드 기반 개발 도구들은 빠르게 발전하고 있다. 그리고 그런 도구들을 능숙하게 다룰 줄 아는 개발자들도 점점 많아지고 있으며, 레거시 기술에 머무르는 사람들은 빠르게 도태되고 있다. 데브옵스를 하려고 하면 먼저 지금 보유하고 있는 IT 환경부터 점검해 보자. 사실 메인프레임으로 가득한 온프레미스 환경에서 데브옵스의 잠재력을 온전히 누리기는 힘들고, 차라리 시도도 안 하는 게 더 나을 수 있다.위의 두 가지는 사실 그렇게까지 해결이 힘든 문제는 아니다. 그런데 클라우드 전문가와 데브옵스 엔지니어를 영입하는 건 꽤나 어려울 수 있는 일이다. 심지어 요즘 퇴직과 이직이 크게 유행하고 있기 때문에, 있는 IT 전문가들을 붙잡는 것조차 힘들 수 있다. 이 부분에서 좌절을 경험하는 회사들이 꽤나 많은 것으로 알고 있다.하지만 반대로 생각해보자. 메인프레임 쪽에서 사람을 구하는 건 더 어렵다. 로이터의 보도에 의하면 코볼을 다룰 줄 아는 개발자들의 65%가 45세 이상이라고 한다. 그 중 20%는 심지어 55세 이상이다. 무슨 말인가? 이제 몇 년만 지나면 코볼 전문가를 현장에서 발견한다는 것 자체가 가능성 희박한 일이 된다는 것이다. 2018년 포레스터(Forrester)는 메인프레임 전문가의 23%가 5년 동안 은퇴했고, 63%의 빈 자리가 채워지지 않고 있다는 조사 결과를 발표하기도 했었다.물론 레거시 분야를 공부하려는 사람들은 어느 시대에나 존재한다. 하지만 새로운 기술을 익히려는 사람들보다 그 수가 현저히 적은 것은 사실이다. 레거시 요소들을 계속해서 유지한다는 건 담당자를 구한다는 면에서 리스크가 너무나 높은 방향성이다. 당장 신기술에 익숙한 전문가들을 구하는 게 어렵다고 좌절할 때가 아니다. 예전 기술은 조만간 아예 운영 자체가 불가능하게 된다. 그렇게 됐을 때의 어려움은 지금 신기술 엔지니어를 구하지 못하는 것에 비할 바가 아닐 것이다.그렇기 때문에 데브옵스를 계획하고 있는 기업들이라면 리크루트 역량을 최우선적으로 높여야 한다. 젊은 세대와 이야기하는 법을 익히고 그들의 필요가 무엇인지 이해하려는 노력이 필요하다. 기술자를 회사에 발붙이게 하는 기술과 전략을 관리자와 경영진들은 마련해야 하고, 여러 가지 방법론들에 대하여 연구해야 한다.데브옵스가 너무나 화려하게 등장했고, 그렇기 때문에 요 몇 년간 데브옵스가 준 실망감이 더 커 보이는 게 사실이다. 하지만 데브옵스의 가능성과 잠재력은 분명하다. 실패 사례들 때문에 처음부터 포기할 필요는 없다. 지금의 발전 방향과 속도를 봤을 때 데브옵스는 경쟁에서 우위를 점하는 것이 아니라, 생존 필수 조건으로서 굳어질 가능성이 낮지 않다. 장기적으로 준비하여 서서히, 그러나 탄탄하게 도입할 방안을 마련해야 한다.글 : 팀 존스(Tim Jones), 디렉터, Advanced[국제부 문정후 기자( [email protected] )]www.boannews.com) 무단전재-재배포금지>
데브옵스(DevOps) vs 데브섹옵스(DevSecOps)
본문은 요즘IT와 번역가 윌리(Willy)가 함께 만든 해외 번역 콘텐츠입니다. 이 글을 쓴 Sannan Malik는 다양한 플랫폼에서 개발과 개발자에 관련한 여러 글을 쓰고 있습니다. 이번 글은 데브옵스(DevOps)와 데브섹옵스(DevSecOps)의 차이점을 살펴보고, 어떤 상황에서 써야 하는지 소개하고 있습니다.
이 두 가지 방법론은 얼핏 비슷해 보이지만 사실 상당히 다른 접근방식을 취하고 있습니다. 둘 다 신속한 개발이라는 목표가 있으며, 애플리케이션 라이프사이클 전반에 걸쳐 높은 가시성과 쉬운 제어를 위해 서로 다른 팀을 하나로 모읍니다. 따라서 필요에 따라 선택하여 사용할 수 있습니다. 그렇다면 데브옵스와 데브섹옵스의 차이점은 무엇인지 살펴보도록 하겠습니다.
사진 출처: Eldar Nazarov – Unsplash
보안
데브옵스(DevOps)와 섹옵스(SecOps)의 차이점은 무엇일까요? 추구하는 방향은 조금 다르지만, 둘 다 소프트웨어 개발에 중점을 두고 있습니다. 데브옵스는 소프트웨어 개발에 중점을 두지만, 섹옵스는 보안에 중점을 둡니다. 이 둘 모두 애자일 [1] 개발 방법론의 하나입니다. 또한, 섹옵스는 보안에 민감한 소프트웨어의 개발에 사용합니다. 둘 다 중요하지만, 누군가는 데브옵스가 더 우월하다고 주장할 수도 있습니다.
하지만 데브옵스와 섹옵스의 가장 중요한 차이점 중 하나는 보안 수준입니다. 데브옵스 조직은 보안에 중점을 두고, 별도의 보안팀이 필요합니다. 이 그룹은 사이버 공격 리스크를 최소화하기 위해 다른 보안팀 및 유관 기관과 협력합니다. 또한, 보안을 애플리케이션 개발과 프로그래밍 개발에 통합합니다. 이 두 가지 접근 방식은 장단점이 있으며, 상호 보완적인 관계에 있습니다.
데브섹옵스에서는 개발팀과 운영팀이 긴밀하게 협력하며, 처음부터 보안을 염두에 두고 시작합니다. 이것이 모든 보안 취약점으로부터 안전하다는 것을 보장하지는 않지만, 비교적 경미한 취약점은 다르게 처리됩니다. 성공적인 제품을 만들기 위해서는 두 가지 접근 방식이 유기적으로 이루어져야 합니다. 이 둘을 잘 활용하면 회사에서 목표를 달성하는 데 도움이 됩니다.
하지만 데브옵스와 섹옵스의 차이점은 명확히 구분하기는 쉽지 않습니다. 두 접근 방식 모두 장단점이 있지만, 그 차이점을 무엇인지 먼저 살펴보도록 하겠습니다. 데브옵스는 협업과 커뮤니케이션을 강조하는 반면, 데브섹옵스는 전체 개발 프로세스에 보안을 통합하는 데 중점을 둡니다. 데브섹옵스는 속도와 혁신이 가장 핵심이지만 이를 효과적으로 구현하는 것은 어려울 수 있습니다.
협업
데브옵스와 섹옵스가 말하는 협업이 동일해 보일 수 있지만, 이 둘 사이에는 분명히 차이점이 존재합니다. 결국 여러분이 구현을 위해 선택한 접근 방식이 프로젝트의 성공을 결정합니다. 데브옵스와 섹옵스 방법론 모두 협업을 중요시하지만, 각 팀은 저마다 고유한 목표를 가지고 있습니다. 이러한 협업 과정에서 서로의 목표를 이해하지 못한다면 같은 방향으로 나아갈 수 없습니다.
데브섹옵스를 실천하기 위해서는 조직 차원에서 계획을 세워야 합니다. 보안 전문가는 사용자 디자인, 리스크 모델 및 인수 테스트의 기준을 정의해야 합니다. 다음 단계는 개발입니다. 개발 프로세스 동안 중요한 것은 기존 보안 관행의 성숙도를 평가하는 것입니다. 코드 리뷰 시스템이 있다면 일관성을 유지하는 데 도움이 될 수 있습니다. 자동화를 데브섹옵스에 적용하면 더욱 강력해집니다. 하지만 자동화를 어설프게 구현하면 보안에 문제가 발생할 수 있습니다.
데브옵스와 SRE[2]는 모두 새로운 기술의 채택을 적극 장려합니다. 데브옵스의 접근 방식은 배포 프로세스를 자동화하여 오류를 줄이고 지속적인 피드백을 보장하는 것이 목표입니다. 자동화는 이러한 과정에서 오류로 인한 비용을 줄입니다. SRE는 지루한 수작업을 최대한 줄이거나 없애기 위해 자동화를 적극 사용할 것을 권장합니다. 데브옵스와 SRE 둘 다 소프트웨어 품질을 개선하고, 실패로 인한 비용을 줄이는 것이 목표입니다. 다시 말해 데브옵스와 SRE는 서로에 대한 보완재가 될 수 있습니다.
보안에 대한 데브섹옵스의 방법론이 취하는 접근 방식은 많은 이점을 가져다줍니다. 먼저, 보안 사고의 수를 줄여 전반적인 보안을 향상시킵니다. 그리고 지속적인 모니터링을 통해 리스크 추적 기능을 향상시킵니다. 또한, 협업이 가져다주는 이점을 개발 프로세스를 넘어 확장할 수 있습니다. 데브섹옵스는 소프트웨어의 품질을 개선하고 판매를 촉진시킵니다. 그러나 데브옵스를 본격적으로 시작하기 전에 먼저 주류로 자리 잡아야 합니다.
앞서 언급했듯이 데브옵스와 섹옵스 모두 협업을 매우 중요하게 생각합니다. 데브옵스는 팀워크와 신속한 애플리케이션 개발에 초점을 맞추며, 보안을 위해 정책, 구성, 모니터링 및 규정 준수를 비롯한 많은 전문가의 참여가 필요합니다. 전통적인 데브옵스는 일반적으로 개발 프로세스가 끝날 무렵에서야 보안 문제를 해결하기 때문에, 발견하지 못한 취약점과 테스트하지 못한 많은 코드가 생길 수밖에 없었습니다. 데브섹옵스는 이와는 반대로 개발 라이프사이클 전반에 걸쳐 개발자와 보안 전문가 간의 협업을 강조하며, 애플리케이션이 업데이트되어도 동일한 수준의 보안을 보장합니다.
자동화
데브옵스와 데브섹옵스 사이에는 수많은 차이점이 있지만, 이 둘을 연결하는 몇 가지 공통점이 있습니다. 일반적으로, 데브섹옵스는 보안과 민첩성을 강조함과 동시에 보안 표준 준수를 보장합니다. 이 두 가지 방법론 모두 기업에 많은 이점을 제공합니다. 다음은 두 방법론의 주요한 차이점입니다.
개발 프로젝트에서 보안을 프로세스의 앞으로 당김으로써 얻을 수 있는 가장 큰 이점은 자동화입니다. 최근에 이슈가 된 SolarWinds 및 Codecov 탈취와 같은 사이버 보안 침해는, 보안을 조직의 최우선 과제로 삼지 않아 발생한 사고였습니다. 고맙게도 데브섹옵스 자동화는 개발팀의 부담을 덜어주고 가치 창출에 집중할 수 있게 해줍니다. 다음은 이러한 방법론을 적용할 수 있는 4가지 영역입니다.
코드로서의 인프라(IaaC, Infrastructure as a Code)[3]는 컴퓨팅 장치와 코드 버전 관리를 포함합니다. 반면에 코드로서의 정책[4]은 팀이 모범 사례를 실천하는 데 적용해야 하는 정책에 중점을 둡니다. 궁극적으로 데브옵스와 데브섹옵스의 프로세스는 모두 상호 연관되어 있습니다. 이 두 가지 접근 방식을 결합하면 자율주행 자동차처럼 인프라를 자동으로 유지 관리하고 모니터링을 할 수 있습니다. 자동화는 사람들의 작업량을 줄여주며, 시간과 비용을 절약합니다.
데브옵스와 섹옵스 모두 보안과 애플리케이션 개발에 중요합니다. 두 방법론을 모두 성공적으로 실천하는 회사는 가장 안전한 소프트웨어를 개발할 수 있습니다. 보안 외에도, 이 둘 다 개발 프로세스에 사이버 보안 관제와 모범사례를 통합함으로써 여러분의 비용을 절감해 줄 것입니다. 또한, 자동화 도구를 통해 보안 소프트웨어를 더욱 신속하게 제공할 수 있습니다. 그러나 이 접근 방식이 모두를 위한 것은 아닙니다.
협업과 의사소통의 단절
지금까지 살펴 본바와 같이 데브옵스와 데브섹옵스 방법론은 매우 다른 사고방식을 요구합니다. 전자는 속도와 민첩성을 추구하고, 후자는 효율성에 초점을 맞추고 있습니다. 따라서 데브옵스 팀은 다양한 기술을 가진 사람들로 구성되어야 합니다. 팀원 사이의 단절을 방지하기 위한 가장 좋은 방법은, 개발자와 운영자가 협력하여 팀 간 협업을 개선할 수 있는 권한을 부여하는 것입니다.
두 방법론 모두 협업을 기반으로 하지만 여전히 몇 가지 차이점이 있습니다. 우선, 데브옵스 팀은 규모가 작으며 긴밀하게 협업하는 경향이 있습니다. 하지만 물리적으로 떨어져 있고, 팀 사이에 다양한 갈등이 발생할 수 있습니다. 예를 들어, 운영팀은 SSL 인증서 또는 방화벽 정책을 결정하지만, 개발팀은 기본 SSH[5] 설정을 개선할 책임이 있습니다. 궁극적으로 데브옵스 팀은 이들 사이에서 중재자 역할을 하며 이것이 원활하지 못하면 단절이 발생합니다.
둘째, 데브섹옵스는 애플리케이션 시작 단계부터 보안을 적용할 것을 강조합니다. 문제를 발견한 후 수정하는 것보다 초기 단계에서 문제를 찾아내 수정하는 것이 훨씬 비용 효율적입니다. 이러한 접근 방식의 한 가지 문제점은 기존 데브옵스 프로세스 및 워크플로우와 충돌할 수 있는 것입니다. 여러분이 처한 상황에 맞춰 적용할 수 있으며 회사가 더욱 안전한 제품을 만드는 데 도움이 될 수 있습니다. 궁극적으로 이를 통해 더 나은 팀워크를 구축할 수 있습니다.
데브섹옵스는 또한 보안 정책과 프로세스의 통합을 권장합니다. 자동화된 테스트 도구는 개발 초기 애플리케이션에서 취약점을 발견하는 데 도움을 줍니다. 이를 통해 시간과 비용이 모두 절약할 수 있습니다. 운영 환경에서 발견된 소프트웨어 결함은 수정하는 데 매우 많은 비용이 소요될 수 있습니다. 결함을 조기에 발견하는 것이 회사의 시간과 비용을 절약하는 길입니다. 여기서 제시한 방법론을 적용하면 보안팀과 개발팀을 통합할 수 있고, 조직 내 장벽을 허물 수 있습니다.
데브섹옵스와 애자일 방법론 모두 팀 간의 협업을 장려하는 것에서 출발하기 때문에 최종 목표 또한 많은 공통점이 있습니다. 유기적인 협업은 더 많은 혁신과 더 나은 프로세스로 이어집니다. 또한 직원의 사기를 높이고 이직률을 낮춥니다. 팀 구성원이 조직의 단절을 극복하는 데 도움이 되는 교육 과정을 받는다면, 보다 성공적으로 데브섹옵스를 도입할 수 있을 것입니다.
[1] 짧은 주기의 개발단위를 반복하여 하나의 큰 프로젝트를 완성해 나가는 방식 또는 방법론. [2] 사이트 신뢰성 엔지니어링(SRE)은 IT 운영에 대한 소프트웨어 엔지니어링 접근 방식으로, 소프트웨어를 통해 시스템을 관리하고, 문제를 해결하고, 운영 업무를 자동화한다. [3] 인프라 구성을 코드를 이용해 자동으로 구축, 관리, 모니터링하는 IT 인프라 프로비저닝 방식. [4] 정책 정의 및 할당을 코드로 관리하고, 정의를 업데이트하는 수명 주기를 제어하고, 규정 준수 결과의 유효성 검사를 자동화할 수 있다. [5] SSH(Secure Shell)는 원격지 호스트 컴퓨터에 접속하기 위해 사용되는 인터넷 프로토콜을 말함.<원문>
DevOps vs DevSecOps?
위 번역글의 원 저작권은 Sannan Malik에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.
데브옵스 가속화를 위한 엔지니어링 성공요소는 무엇인가?
클라우드
Andrew Min
많은 조직이 데브옵스를 통해 운영 자동화를 꾀합니다. 자동화는 데브옵스의 중요한 원칙이긴 하나 그것만이 전부는 아닙니다. 진정한 데브옵스의 철학은 애자일 철학과 마찬가지로 고객 중심의 가치를 빠르면서도 안정적으로 전달하는 것입니다. 단순 자동화 툴 몇 개를 도입하는 것으로는 원하는 만큼의 전달 리드타임 단축이나 운영 안정성의 비약적 상승을 기대할 수 없습니다. 데브옵스를 부분적으로 도입하였으나 기대보다 성과가 나지 않는 조직, 또는 데브옵스 도입으로 애자일 가치를 진정으로 향상하고자 하는 조직에게 엔지니어링 관점의 가이드를 제시하고자 합니다.
고객 가치를 MVP(Most Viable Product) 중심으로 신속히 전달하고 지속적으로 개선하는 애자일의 철학이 개발현장에서 많이 확산되고 있습니다. 애자일 문화가 충분하지 않은 조직일지라도 애자일의 기법, 예를 들면 스크럼의 프로세스, 활동 등을 중심으로 활용하는 경우가 많습니다. 애자일이 일정 수준 적용되었다 하더라도 개발된 어플리케이션의 운영과 유지보수 비중이 높아지면 결국 고객 가치의 전달 속도는 떨어지고, 운영 안정성과 품질도 만족스럽지 못하게 됩니다. 어플리케이션이 제공하는 비즈니스 가치의 성장에 따라 운영안정성과 기민성이라는 두 성질은 서로 트레이드오프 관계가 되어 동시 달성이 쉽지 않게 됩니다. 데브옵스는 애자일 기치를 개발에서 운영까지 확장하고 안정성을 더욱 보장하는 것을 목표로 합니다. 데브옵스는 바로 애자일의 운영 확장 버전이라 할 수 있겠습니다. (그림 1)
Agile plan -> code -> build -> test DevOps -> release -> deploy -> operate -> monitor [그림 1] 애자일과 데브옵스의 커버리지
데브옵스의 개념을 CI(Continuous Integration)/CD(Continuous Delivery or Deploy)에 한정해서 정의하거나 배포 자동화 관점에서만 보는 경우가 있습니다. 그러나 필자는 비즈니스 성공이라는 하나의 목표를 달성하기 위해 개발과 운영이 협업하는 철학과 프랙티스(기법, 실천사항)의 모음이라고 정의합니다. 데브옵스의 프로세스는 개발과 운영이 하나의 프로세스로 연계되고 지속적으로 개선하는 순환구조를 갖습니다. 이는 애자일의 적용이 단방향, 단발성이 아니며, 운영 유지보수를 통해 어플리케이션 자체와 프로세스, 도구, 프랙티스 등 관련된 모든 것을 개선해 나갈 수 있다는 철학을 보여줍니다. IBM은 2016년 데브옵스의 방법론인 Garage(그림 2)를 공개하며 애자일의 공통 철학(문화)을 기반으로 개발과 운영이 완전히 통합된 순환적 프로세스를 제시하였습니다.
Co-create -> Co-execute – Co-operate discover, learn, culture, envision, operate, reason, develop [그림 2] IBM Garage
고객가치는 Design Thinking 기법 (혹은 이의 부분집합)을 통해 도출되고 정제됩니다. 이렇게 정제된 요구사항은 애자일 엔지니어링 프랙티스로 개발이 수행되며 코드기반의 검증과 자동화된 배포를 통해 고객에게 전달됩니다. 운영상 필요한 다양한 지표와 고객가치의 정량적 수치는 실시간으로 수집, 측정되어 개선활동이나 문제예방에 활용됩니다. 자가치유가 가능한 장애는 자동화된 워크플로우에 의해 해결되기도 하고 클라우드 네이티브 아키텍처를 통해 조치되기도 합니다. 고객의 피드백과 이해관계자들의 리뷰, 내부 조직의 회고, 포스트 모템(Post-mortem) 활동은 지속적 개선을 위해 데브옵스의 선두 프로세스로 돌아가 순환됩니다.
이제 애자일과 데브옵스의 가치는 조직에서 추구해야 할 핵심 가치로 대두되었습니다. 심지어 어느 산업군에서는 비즈니스의 존망까지도 영향을 받습니다. 이미 데브옵스를 부분적으로 채택한 조직도 전반적으로 확산될 수 있도록 노력을 기울어야 할 것입니다.
필자는 초대형 백엔드(Super Scalable Backend) 시스템을 개발 운영하는 것에 데브옵스가 어떻게 적용되는지 실질적으로 경험하며 배웠습니다. 성공적인 데브옵스 적용을 위해 교과서적, 문화적 접근보다는 엔지니어링 측면을 중심으로 다음과 같은 5개 항목으로 나누어 이야기하고자 합니다.
1. 아키텍처 측면 – 클라우드 네이티브의 수용
클라우드 네이티브가 데브옵스 구현을 가속화하기도 하지만 반대로 클라우드 네이티브를 실현하기 위해 데브옵스가 활용되기도 합니다. 두 개념은 서로 어느 한 편에 속하는 것이 아닙니다. 고객중심의 가치를 최대한 기민하면서도 안정적으로 전달하고자 하는 데브옵스의 철학이 실제로 구현되려면 클라우드 네이티브 없이는 사실상 불가능합니다.
클라우드 네이티브의 용어는 수 년 동안 매우 혼란스럽게 표현되었습니다. 혹자는 워크로드를 단순히 클라우드에 포팅한 것만으로 표현하였고 일부 벤더는 PaaS(Platform as a Service)에만 집중하여 표현하기도 하였습니다. 이는 잘못된 이해이며 클라우드 네이티브와 클라우드 컴퓨팅과는 간극이 있다고 보시면 됩니다. 클라우드 네이티브란 “클라우드의 이득을 최대한 활용”하는 아키텍처이자 클라우드 도입전략으로 정의됩니다. 기민성과 이식성, 실패복구성, 자동 확장성을 극대화하는 컴퓨팅의 철학이며 데브옵스와 SRE(Site Reliability Engineering)철학을 실천하기에 최적의 기술이자 아키텍처입니다.
가트너는 클라우드 네이티브를 달성하기 위한 접근 방법을 2가지로 정의하는데, 필자는 이 구분을 매우 선호합니다. 첫번째는 컨테이너 네이티브이며 두번째는 CSP(Cloud Service Provider) 네이티브입니다. 전자는 컨테이너와 쿠버네티스로 대표되는 CNCF(Cloud Native Computing Foundation)의 주요기술들을 활용하여 달성합니다. 후자는 클라우드 서비스 제공자의 역량을 활용하여 달성되는데 Azure의 앱 서비스나 Function, 컨테이너 앱 혹은 AWS의 Lamda 등의 어플리케이션 호스팅 PaaS(Platform as a Service)가 이에 해당합니다. 컨테이너 네이티브는 철저히 OSS(Open Source Software)기술로 구현되기 때문에 도입을 검토하는 조직의 오픈소스 역량에 따라 신중히 검토되어야 합니다.
필자의 경험상 쿠버네티스를 직접 설치(일명 바닐라), 구성하여 사용하는 것은 쉬운 일이 아닙니다. 더욱이 쿠버네티스의 수많은 에코 시스템들의 OSS를 직접 구성, 운영하는 것도 왠만한 OSS 역량이 성숙되어 있지 않으면 난이도가 매우 높은 일입니다. 조직의 OSS역량이 충분히 확보되었다면 IaaS나 직접 컴퓨팅 환경을 구축하여 쿠버네티스 에코를 구축, 운영할 수 있습니다. AWS의 관리형 컨테이너(EKS)가 나오기 전, 필자의 조직 역시 일부 마이크로 서비스를 대상으로 kops( https://kops.sigs.k8s.io/ )라는 OSS로 쿠버네티스 환경을 VM에 직접 구성하여 운영한 적이 있습니다. 컨트롤 플레인을 관리하고 쿠버네티스의 버전 업그레이드를 감당하면서 최적의 노드 이미지를 유지하며 패치를 해나간다는 것이 당시에는 크나큰 도전이었습니다. kops를 통한 노드 오토 스케일링 구현이 불가능하여 모니터링 환경에 의한 별도의 자동 구성을 해야 한다는 제약사항들도 있었습니다. (현재는 CNCF의 별도 OSS를 통해 구현이 가능합니다). 결론은 역량이 갖춰진 조직에서도 매우 어려움을 겪는다는 것입니다.
반면, 컨테이너 네이티브를 선택한 조직이 이러한 고난이도의 쿠버네티스 관리를 직접 감당할 수 있는 역량을 보유하였다 해도 필요한 Tooling은 신중하게 고려해서 선택해야 합니다. CNCF 랜드 스케이프( https://landscape.cncf.io/ , 그림 3)에서 어느 정도 성숙도가 있는 도구들을 선택해야 하는데, 성숙도는 컨트리뷰터 수, 커밋과 릴리즈 빈도, GitHub의 Star수 등으로 판단할 수 있습니다. 물론 적용하기 전 PoC(Proof of Concept)나 파일럿이 반드시 수행되어야 합니다. OSS를 선택한다면 보안취약성을 포함해 기능오류, 성능이슈, 라이선스 문제 등을 항상 살펴보아야 합니다. 사용할 툴들이 결정되면 직접 설치하는 방식보다 Operator 설치방식을 선택해야 합니다. 대부분 툴은 Operator(https://operatorhub.io/)를 제공하는데 쿠버네티스 환경에서 더 쉽게 구성하고 운영 작업을 통합적으로 수행할 수 있게 해줍니다. 이를 테면, 인메모리 퍼시스턴스를 Redis를 사용한다면 Statefulset으로 직접 설치하는 것이 아니라 Redis Operator ( https://operatorhub.io/operator/redis-operator )를 통해 구성하고 운영 관리하는 것입니다. Operator Hub에서 제공되는 Operator들은 Capability Level을 제공(그림 4)하는데 Seamless Upgrades 수준 이상으로 선택할 것을 권고합니다. 참고로 Capability Level은 https://sdk.operatorframework.io/docs/overview/operator-capabilities/ 에서 확인할 수 있습니다.
[그림 3] 클라우드 네이티브 랜드스케이프level 1 -> level 2-> level3 -> level4 -> level5 basic install / seamless / full lifecycle / deep insights / auto pilot
automated application provisioning and configuration / patch and minor version upgrades supported / app lifecycle, storage lifecycle(backup, failure recovery) / metrics alerts, log processing and workload analysis / horizontal·vertial scalling,auto config turning, abnormal detection, schedulling tuning HELM(level1~2) ANSIBLE(level1~5) GO(level1~5) [그림 4] Operator의 Capability Level과 예시
반면, CSP 네이티브는 상대적으로 OSS 역량이 확보되지 않은 조직에서 활용하기가 쉽습니다. 기민성, 이식성, 실패복구성, 자동확장성을 보장하는 아키텍처를 설계, 운영하는 고민을 하지 않고 오직 어플리케이션 자체에만 집중할 수 있습니다. Java 앱이면 jar 파일까지만 만들어 어플리케이션 PaaS에 배포하면 됩니다. 애저 앱 서비스, 스프링 클라우드, 클라우드 파운드리 등이 그 예입니다.
CSP 네이티브는 매우 쉽게 어플리케이션을 클라우드 네이티브화 할 수 있으므로 시간과 자원 활용성 측면에서 유리합니다. 물론 조직이 기본적인 컨테이너 역량을 보유하고 있다면 관리형 컨테이터 네이티브의 활용을 검토해볼 수 있습니다. CaaS(Container as a Service)로 불리기도 하는 이 접근방식은 쿠버네티스 운영관리의 대부분을 CSP에 맡기고 그 위에서 작동될 자원들만 조직에서 직접 관리할 수 있기 때문에 더 실용적인 클라우드 네이티브 채택 방법으로 알려져 있습니다. Azure의 AKS, AWS의 EKS, GCP의 GKE가 그 대표적인 예입니다. CSP가 제공하는 관리형 쿠버네티스 클러스터를 사용하게 되면 벤더에 덜 종속적이면서도 클라우드 네이티브가 주는 혜택을 가져갈 수 있습니다.
컨테이너 네이티브이든 CSP 네이티브이든 클라우드 네이티브한 어플리케이션을 운영하려면 어플리케이션 자체도 현대화되어야 합니다. 클라우드 네이티브를 어플리케이션 아키텍처로 한정하는 용어인 클라우드 네이티브 어플리케이션 아키텍처를 한 마디로 하면 현대화된 어플리케이션이라할 수 있습니다. 실질적으로 12 요소 앱 원칙( https://12factor.net/ )이나 가트너의 LIFESPAR 원칙(표 1)으로 설계된 어플리케이션을 의미합니다. 이 부분은 다음 기고에서 상세히 설명드릴 기회가 있을 것입니다.
[표 1] 12 요소 앱과 LIFESAR 12요소 앱 LIFESAR · 코드베이스· 명시적 선언된 종속성
· 벡엔드는 리소스로 취급
· 분리된 빌드, 릴리즈, 실행
· Stateless 프로세스
· 포트바인딩
· 동시성
· Graceful 폐기성
· 개발,프로덕션 패리티
· 스트림된 로그
· 어드민 프로세스
· Latency가 있는 것을 인지
· 모든 메트릭은 측정되게
· Failure가 있는 것을 인지
· 이벤트 드리븐 비동기
· 보안
· 동시성(병렬)
· 자동화
· 리소스 소비 인지
[표 1] 12 요소 앱과 LIFESAR기존 레거시 어플리케이션도 고객 가치 중심의 기민성이 우선 시 되어야 한다면 12 요소 앱으로 리팩토링하는 것이 반드시 고려되어야 합니다. 마이크로 서비스 아키텍처로 재설계되면 이상적이겠지만, 기존 모놀리스 어플리케이션도 12요소 앱의 대부분을 적용할 수 있습니다. 미니 서비스 아키텍처는 그런 요건을 위한 현실적인 대안으로 선택될 수 있습니다.
당연한 얘기지만 처음부터 개발될 어플리케이션은 아키텍처를 구상할 때부터 위의 요소가 반드시 반영되어야 합니다. 클라우드 네이티브로 가기 위해선 어플리케이션이 위와 같이 기본적인 현대화가 되어야 합니다. 어플리케이션이 준비가 안되어 있으면 어떠한 방식의 클라우드 네이티브를 도입하더라도 원하는 목표수준 (예: 전달 리드타임, 운영안정성 지표)에 다가갈 수 없습니다.
클라우드 네이티브는 차세대 프로젝트 수행 같은 빅뱅 접근방식으로 달성하기 어렵습니다. 하나씩 실천해 나가는 여정으로 접근하셔야 합니다. 목표와 비전을 정의한 후 한 단계씩 구현해 나가는 것이 중요합니다. 아래는 필자의 경험한 클라우드 네이티브 여정을 위한 순서와 도구들의 예시입니다.
datadog,prometheus,grafana,pagerduty : continuous monitoring
puffet,terraform : infra as code
chef : immutable infrastructure
jenkins blueocean, spinnaker, travis CI : blue green deployment/canary
grizzly,akka,operators : microservice
helm chart : containerzation
kops, eks,iks : orchestration [그림 5] 클라우드 네이티브 여정을 위한 순서 및 도구
2. 개발 및 유지보수 측면 – 애자일 개발 프랙티스의 가속화. 제일 어렵고 여전히 중요한…
말그대로 개발자 전성 시대입니다. 개발자의 역량에 따라 생산성 차이가 수십 배가 난다는 말은 이제 놀랍지도 않습니다. 개발자는 클라우드 네이티브, 애자일/데브옵스, 디지털 트랜스포메이션 모든 영역에서 가장 핵심적인 역할을 하는 자원입니다. 기존 SI산업에서 코더로 평가절하되었던 것과 달리, 현재 개발자들은 완전히 차원이 다른 고도의 역량을 가진 전문직 종사자입니다. 과거에는 분석/설계자의 산출물로 코딩역할만 했다고 하면 지금은 분석부터 기능설계, 비 기능설계(아키텍처), 개발, 테스트, 배포, 운영까지 소프트웨어 개발 대부분의 라이프사이클에 직접적으로 참여하기 때문이죠. 직접적으로 참여한다는 의미는 단순 미팅에 참여하고 보고자료를 작성하는 것이 아니라, 코드 역량, 구현 역량을 보유하고 있다는 것입니다. 일부 아마존 같은 테크 기업들은 개발/구현 중심의 소프트웨어 엔지니어임을 강조하기 위해 SDE(Software Development Engineer, 소프트웨어 개발 엔지니어)라는 표현을 쓰기도 합니다. 좁게 보면 개발자는 SDE만을 말하기도 하지만 큰 범주에서 보면 SDET(Software Development Engineer in Test, 테스트 엔지니어), 데브옵스 엔지니어를 포함하기도 합니다. SDET는 테스트엔지니어링을 코드로, 데브옵스 엔지니어는 인프라를 코드로 작성하고 유지보수합니다.
개발자는 Design Thinking이나 User Story 워크샵에 참석하여 고객 가치로 우선순위화 된 기능을 프로덕트 매니저와 함께 도출하고 이를 실현할 기능 설계와 비 기능 요건을 위한 아키텍처를 잡아야 합니다. 툴과 산출물은 중요하지 않지만 기능과 아키텍처는 직접 구현수준 만큼의 기술적으로 높은 역량을 가지고 있어야 합니다. 개발자는 특정 수준의 커버리지를 갖는 단위테스트 코드를 작성해야 하고 통합테스트 코드 또한 작성해야 합니다. 테스트 주도 개발 프랙티스는 테스트 코드를 먼저 짜고 본 기능을 개발하는 순서가 중요한 게 아니라, 테스트가 가능한 기능 코드를 만들고 테스트 코드를 작성하는 것이 중요하게 여겨져야 합니다. 테스트 코드는 테스트 엔지니어만 만드는 것이 아닙니다. 아래 (그림-6)와 같이 개발자는 단위, 통합테스트 코드를 작성하고 테스트 엔지니어는 시스템 테스트와 인수테스트에만 집중합니다.
SDET client needs/acceptance test
requirement/system test DET design/integration test
develop/unit test [그림 6] SDE와 SDET의 테스트 영역
개발자가 작성하는 테스트 코드는 현대적 개발문화에 있어서 중요한 요소입니다. 아키텍처도 일회성의 비 기능적 요구사항으로 고정되는 것이 아니라 MVP구현 방식처럼 초기의 최소 요건만 가진 아키텍처로 시작하고 끊임없이 개선되고 보완되어야 합니다. 이런 아키텍처의 변경도 테스트코드에 의해 검증되므로 테스트 코드가 있어야 자신감을 갖고 지속적으로 아키텍처의 개선을 시도하고 발전시켜 나갈 수 있습니다. 만약 테스트 코드가 없다면 단순 패키지 구조만 바꾸려 해도 운영 안정성의 불안감이나 부작용 때문에 시도하기조차 어려워집니다. 특히 한창 운영중인 시스템에선 더욱 힘들어집니다. 단위테스트와 통합테스트 코드를 개발자가 다 작성해야 하지만 단위테스트 코드 작성이 더 우선시되어야 합니다. 단위테스트 코드만큼은 개발 공수가 늘어난다 하더라도 초기부터 개발되고 유지보수 되어야 합니다. 단위테스트 코드를 처음 적용할 때는 기능 구현코드 작성보다 더 많은 공수가 소요될 수도 있습니다. 필자의 경험에 의하면 테스트 코드 경험이 없는 개발자가 테스트코드를 작성하는데 기능 코드를 구현하는 만큼 시간이 소요됩니다. 하지만 개발자가 익숙해지고 적응되면 테스트 코드 공수는 개발코드 작성의 20% 이하까지도 내려갑니다. 이런 테스트 코드 작성이 개발문화로 정착되면 테스트 코드만을 통과시키는 최소한의 코드 구현에 집중하고 지속적으로 리팩토링해 나가는 TDD(테스트 주도 개발)에 더 가깝게 다가갈 수 있습니다. TDD는 다양한 애자일 엔지니어링 프랙티스 중 핵심적인 요소입니다.
어떤 조직에서는 테스트 코드를 아웃소싱하기도 하는데 테스트 코드를 테스트주도개발 문화의 산출물로 활용되지 않는 이상 금방 불용되기 일쑤입니다. 테스트 주도 개발문화의 산출물로서 테스트코드가 개발, 유지보수 되어야 합니다. 테스트 엔지니어는 개발자와 협력하여 시스템 간 테스트를 포함하여 성능, Resiliency, 보안 테스트 등을 모두 수행해야 합니다. 인수테스트 역시 테스트 엔지니어의 몫입니다. 테스트 엔지니어와 테스터의 차이는 테스트 코드 작성 여부에 있습니다. 테스트 엔지니어는 API테스트, UI테스트 등의 기능 테스트 뿐 아니라 시스템 테스트를 위한 코드도 작성합니다. 테스트 수행 자체는 CI/CD파이프라인에 의해 수행되고 결과가 수집, 측정되어야 합니다.
개발자는 클라우드 네이티브 어플리케이션 아키텍처를 충분히 고려해야 합니다. 클라우드 네이티브는 “클라우드가 주는 혜택을 최대한 활용하여 구현”이라는 매우 쉬운 정의이지만 그 구현을 위해 체득해야 할 기술들은 결코 쉽지 않습니다. 컨테이너, CI/CD, 마이크로 서비스 아키텍처, 어플리케이션 현대화 등 폭넓은 영역에 대해 구현하는 수준으로 이해와 역량을 갖추어야 합니다. 즉, 개발되어야 할 어플리케이션은 구체적으로 마이크로 서비스나 미니 서비스 아키텍처로 설계되고 각각의 경계를 가지고 있으며 각각의 업무 특성에 맞게 퍼시스턴스가 RDB나 NoSQL로 구현됩니다. 마이크로 서비스 간 통신은 REST API로 구현되며 적절한 캐시능력을 보장하고 수평적 확장력을 위해 Stateless하게 구축됩니다. 대규모의 분산 아키텍처라면 이벤트 기반 기술이나 CQRS(Command Query Responsibility Segregation) 등의 기술로 설계되고 컨테이너 오케스트레이션을 통해 스케줄링이 자동화되도록 어플리케이션을 구성해야 합니다. 거기에 수많은 오픈소스 소프트웨어를 적재 적소에 활용하여 안정성과 생산성을 높이면서도 오픈소스의 취약점이나 라이선스 등을 지속적으로 검토해야 합니다.
개발자가 구현한 기능들은 CI/CD로 각종 점검 자동화, 배포 자동화를 통해 배포될 것이고, 배포되면 모니터링 및 장애대응까지 개발자가 수행해야 합니다. 이렇게 벅찬 업무들을 감당하기 위해서는 “극단적 자동화”를 선택하지 않을 수 없습니다. 예전 SI개발/유지보수에서는 소프트웨어 아키텍트, 인프라 아키텍트, 데이터 아키텍트, 테스터, 어플리케이션 운영자, 시스템 운영자, 데이터베이스 관리자 등이 각각의 조직에서 수행했던 일이므로 여전히 “이렇게 일하는 게 가능해?”라는 질문을 필자는 아직까지 계속 받습니다. 데브옵스가 더 가속화되기 위해 자동화의 중요성이 강조되어야 하는 이유입니다. 자동화에 대해서는 다음 장에서 더 자세히 다루겠습니다.
모든 개발자(SDE, SDET, 데브옵스 엔지니어)는 형상 관리 툴을 통해 코드를 관리하며 모든 브랜치(단위 요구사항이 반영된 논리적 분리 공간)의 작성을 완료 후 코드리뷰를 수행해야 합니다. 개발자간 코드품질과 생산성은 100배까지 차이가 나기도 합니다. 특히 함수형 프로그래밍이 대세로 확산되는 가운데 개발 생산성과 유지보수성의 차이는 전통적인 프로그래밍 방식과 비교하여 비약적으로 차이가 발생하게 되었습니다. 코드리뷰는 함수형 프로그래밍과 같은 선진 기법을 적용할 때 더욱 더 중요하게 작동됩니다. 코드 리뷰를 통해 수십줄의 코드를 단 몇 줄의 코드로 추상화하는 방법을 배우고 코드 품질을 향상시키며 개발자 간 성장과 학습에 대한 동기부여를 자극합니다. 이러한 개발문화의 적용은 결국 어플리케이션의 생산성과 품질에 그대로 녹아들고 선순환적 개선을 가져옵니다.
따라서, 코드리뷰는 개발 라이프사이클 상에서 필수 활동으로 여겨져야 하며 개발 공수에 반드시 포함시켜야 합니다. 정적점검에서 발견되지 않지만 기술부채를 늘일 수 있는 코드 스멜(오류는 아니지만 유지보수성, 생산성을 저하시키는 코드)을 개발자 간 상호 코드 리뷰를 통해 찾아내 코드 기술 부채를 지속적으로 줄여가야 합니다. 각 개발자만의 코드 기술, 팁, 알고리즘 등을 코드리뷰 함으로써 개발 역량 향상과 공유 문화를 실천할 수 있습니다. 트렁크기반 코드관리가 아니라면 반드시 기능 브랜치에서 메인 브랜치로 병합되는 코드들은 코드리뷰와 CI가 수행되어야 합니다.
3. 인프라 자동화 측면 – 자동화 어디까지 해봤니? 완전히 Immutable한 인프라 스트럭처
가장 기본이 되는 CI부터 이야기를 시작합니다. CI는 개발자가 작성한 코드가 문제를 일으키지 않고 통합되는지를 점검합니다. 그리고 작성된 단위/통합테스트 코드가 자동으로 수행되어 커버리지, 성공/실패율, 테스트 추이 등을 리포트로 뽑아 냅니다. 코드 취약점이나 스타일에 대한 기본적인 정적점검을 수행하고 보안점검, 오픈소스 라이선스/취약점 점검 등을 포함시킵니다. 일반적으로 CI의 끝은 패키징입니다. 어플리케이션 패키지를 라이브러리 리파지토리에 배포할 수도 있고 컨테이너로 패키징하여 컨테이너 레지스트리에 배포할 수도 있습니다. 패키징된 아티팩트를 중앙 집중적으로 관리하며 CD 파이프라인에서 쉽게 활용할 수 있기 때문입니다.
아래는 간단한 CI/CD 파이프라인의 예시들을 보여주는데 파이프라인의 스테이지(작업의 집합)는 각 프로젝트 상황에 맞게 구성할 수 있습니다.
build/unit test/static analysis/deploy to registry -> docker registry -> dev deploy/integration test/(decision)/QA deploy/acceptance test/(decision)/prod deploy [그림 7] CI/CD 파이프라인 예시
특히 아래 파이프라인을 보면 Git의 Tag를 구성하여 트리거링하는 예시를 보여주는데, Tag를 버전으로 설정하여 Release Candidate 버전은 테스트계에 배포되도록 하고 Release 버전은 운영계에 배포되도록 파이프라인의 설정을 구성할 수 있습니다.
CI/CD 자동화에서 어려운 부분 중 하나는 Immutable Infra의 철학입니다. “한 번 배포된 인프라는 불변한다”라는 다소 기이한 정의는 IaC(Infra as Code)의 대표적인 특징을 나타냅니다. 코드로 구성된 인프라와 실제 인프라는 완전히 일치해야 하며, 변경사항은 기존 코드를 수정하여 다시 배포해야 한다는 강박적인 철학을 내포합니다. 코드로 인프라를 완전히 관리한다는 것은 인프라의 이력관리와 손쉬운 롤백, 어디서든 재현 가능한 인프라를 구성할 수 있다는 것을 의미합니다. 운영계와 테스트계, 개발계의 각각 다른 환경 때문에 어플리케이션 장애 상황은 매우 흔하게 발생합니다. 개발계에서는 잘되는데 운영에 배포하면 문제가 발생하는 사례입니다. 따라서 인프라 구성 오류에 따른 장애를 막고 재현 가능한 인프라 구성상의 문제점을 쉽게 찾아내기 위해 IaC를 도입해야 합니다. 또한 BCDR(Business Continuity and Disaster Recovery)상황 시 인프라 구성을 빠르게 프로비저닝 하기 위한 자동화의 도구로 활용되기도 합니다.
IaC의 Immutable 인프라 철학은 클라우드 리소스를 프로비저닝할 때보다는 어플리케이션 호스트 환경(어플리케이션이 작동할 VM이나 컨테이너)을 구성할 때 더 잘 맞게 적용됩니다. PaaS성의 클라우드 리소스를 변경할 때마다 기존 리소스를 삭제하고 재생성하면 퍼시스턴스들의 데이터들을 복구해 내는데 불필요한 공수가 들기 때문입니다. 따라서 Stateless한 어플리케이션의 컨테이너를 중심으로 Immutable 인프라 원칙을 적용하는게 일반적입니다. 어플리케이션을 VM에 호스팅할 경우 VM의 모든 구성을 Chef나 Puffet과 같은 도구를 사용하여 완전히 코드화하여 선언하고 이미지로 생성되어야 합니다. 새로운 버전의 어플리케이션 패키지(JVM이면 jar나 war)를 배포하려면 기존 VM을 폐기하고 코드를 재생성해서 만들어진 VM을 재생성하여 교체되어야 합니다. 즉, 코드를 통해 생성된 이미지의 새로운 VM들이 기존 VM을 교체해 나가는 방식입니다. (롤아웃 배포라고 합니다.) 기존 VM과 신규 VM을 동시에 배치해 놓고 검증이 완료되면 앞 단 라우팅을 변경하는 방식이 블루그린 배포이며 배포 안정성을 세밀하게 검증하기 위해 1~2개의 배포를 먼저 실행하는 카나리 배포를 선택할 수도 있습니다. 코드로 작성된 VM의 이미지는 자동 스케일링 확장 시 사용되기도 합니다. Immutable 인프라의 철학을 철저히 따르는 조직은 VM의 수동 변경을 막기 위해 크론잡을 통해 형상 구성 변경을 추적하고 강제로 오버라이드하는 프랙티스를 수행하는 곳도 있습니다. 그만큼 코드와 인프라를 강박적으로 일치시키려는 철학을 실천하고자 하는 것입니다.
어플리케이션 구동을 위해 Kubernetes와 같은 컨테이너 오케스트레이션 툴을 사용한다면 Kubernetes Manifest나 Helm Chart로 더욱 쉽게 Immutable과 선언적 인프라를 관리할 수 있습니다.
IaC는 CD pipeline내 구성이 되지만 클라우드 리소스를 프로비저닝 하는 코드들은 어플리케이션 CD pipeline과 별개의 것으로 구성되는 것이 관리효율성 측면에서 유리합니다. 예를 들면, 컨테이너로 구성된 어플리케이션이 변경되었다고 해서 Kubernetes클러스터 구성이나 PaaS DB가 매번 변경되지는 않을 것이기 때문입니다.
인프라 코드를 Git으로 형상관리할 경우 개발코드와 동일하게 브랜치 전략과 코드 리뷰 등의 개발 프랙티스를 수행해야 합니다. 인프라 코드가 커밋되면 인프라가 바로 적용되도록 GitOps환경을 순수 Git의 기능만으로 구현 가능하며, ArgoCD나 FluxCD와 같은 전문 GitOps툴을 활용할 수도 있습니다.
다음은 어플리케이션의 코드와 테스트, IaC의 리파지토리 구조의 예시를 보여줍니다. 어플리케이션에서 중앙관리를 할 수도, 테스트와 인프라를 분리해서 관리할 수도 있는데, 소규모의 어플리케이션과 MSA환경에서는 하나의 리파지토리에서 관리할 수도 있고, 데브옵스 팀이 분리되어 있는 경우 별개의 리파지토리에서 관리할 수도 있습니다. 각 조직 구성과 어플리케이션 특성에 맞게 리파지토리 전략을 가져가시면 됩니다.
petclinic ->
application <-> (commit) dev
test-auto <-> (commit) test
terraform <-> (commit) devops(infra) petclinic <-> (commit) dev
petclinic-test <-> (commit) test
petclinic-terraform <-> devops(infra) petclinic <-> (commit) dev
test-automation ->
petclinic-test / …-test <-> (commit) test
infra-automation ->
petclinic-terraform / …-test <-> devops(infra) [그림 8] 어플리케이션, 테스트, 인프라 코드 리파지토리 전략
4. 스케일아웃 측면 – 스케일 아웃을 버틸 운영능력을 가지고 있는가?
기존에는 개발조직과 운영조직이 별도로 구성되어 어플리케이션의 개발이 완료되면 운영조직으로 이관하고 운영조직이 안정성을 담보로 변경을 최소화하여 보수적으로 운영하는 것이 흔한 일이었습니다.
데브옵스는 개발과 운영의 벽을 허물라고 하지만 그 벽을 허무는 가장 확실한 방법은 개발이 운영을 하고 운영이 개발을 하는 것입니다. 즉, 하나의 조직에서 개발과 운영을 다 감당한다는 말입니다. 개발조직이 운영까지 맡아서 하는 것은 쉬운 일은 아니지만 개발조직은 개발만 하고 운영은 운영조직에 이관하는 것도 데브옵스의 지속적 개선 순환의 원칙에 맞지 않습니다. 넷플릭스나 마이크로소프트 같은 테크 기업의 개발팀은 소프트웨어 개발 철학을 “You build it, you run it (당신이 개발하고 당신이 운영한다. 혹은 운영하려면 당신이 개발해라)”로 선언합니다. 극단적 자동화를 통해 운영을 효율화하여 데브옵스의 가치를 실현하려면 개발부터 그렇게 구현이 되어야 합니다. 개발할 때 운영의 경험이 없으면 운영 효율화를 위한 방법을 상상해낼 수가 없습니다. 개발자의 역량측면에서도 운영을 경험해보지 않는 개발자는 비 기능적 설계인 아키텍처 역량이 부족해질 수밖에 없습니다. 운영 경험을 통해 어느 부분을 자동화하고 아키텍처를 어떻게 최적화하며 대규모의 트래픽은 어떻게 관리하고 모니터링하는 방법을 체득할 수 있으며, 이 경험으로 운영 효율적인 개발코드를 만들어 낼 수 있는 것입니다. 어플리케이션과 테스트, 인프라 코드 모두 해당되는 이야기입니다.
신규서비스일 경우 개발팀의 전체가 운영으로 모두 이관되지 않더라도 운영팀은 모두 개발팀이었어야 합니다. 개발자, 테스트 엔지니어, 데브옵스 엔지니어 모두 해당되며, 운영역량 없이 개발역량 향상은 달성하기 어렵다는 것을 인지해야 합니다.
운영의 대표적인 업무가 시스템 모니터링과 이상 시 조치하는 일일 텐데 고수준의 자동화를 통해 자가조치적(Autonomous) 모니터링 환경을 구현할 수 있습니다. 쉬운 예로, 오토 스케일링 아웃은 부하가 몰리면 CPU나 메모리 사용량이 증가하고 이에 따라 수평적으로 스케일아웃을 할 수 있도록 구성하는 것입니다. 여기서 더 나아가 사용자 요청이 늘거나 외부 이벤트 (날씨 변화에 따른 트래픽 증가, 특정 시간 트래픽 증가)에 따라 시스템 자원 조율을 자동화할 수 있습니다. 어플리케이션 호스팅 환경이 VM이라면 오토 스케일링 시간은 이미지 프로비저닝으로 인해 최소 수 분 ~ 수 십분까지 소요될 수 있습니다. 컨테이너 환경에서는 이 시간을 수 초로 줄일 수 있기 때문에 컨테이너 환경 채택이 선호되는 이유이기도 합니다.
운영을 위한 자동화 사례는 수도 없이 찾아볼 수가 있는데요. 메시지 큐에서 인바운드와 아웃바운드 메시지 수의 차이가 임계치 이상으로 발생할 때 메시지 클라이언트들을 재 시작하여 자가 조치를 하도록 구성할 수도 있을 것이고, Redis 캐시환경에서 메모리 부족으로 Eviction이 다수 발생할 경우 Expire가 되지 않는 캐시들 중 가장 적게 사용된 데이터들을 선제적으로 지우도록 자동화할 수도 있을 것입니다. (참고적으로 필자가 글로벌 개발팀에서 가장 많이 받아본 모니터링 Slack 메시지는 “복구됨(Recovered)”이었습니다. 수많은 시스템 오류 알람의 90% 이상은 자가 조치되었습니다.)
기존의 모니터링이 특정 상황에 대한 위험 경보나 알림이었다면 이제는 다양한 자동화 도구와 지능적 모니터링 환경을 활용하여 자가 조치적 운영환경을 구성할 수 있습니다. 이 말은 운영 자원을 큰 수준으로 줄여 나갈 수 있다는 의미이며 이것이 메타나 IBM 같은 테크 기업에서 몇 명의 담당자가 수천, 수만 가지의 인프라 환경을 관리할 수 있는 방법이기도 합니다. 선진 기업들은 생각하는 것 이상으로 자동화를 구현한다는 것을 배워야 합니다.
5. 조직적 측면 – 우리는 진정 한 배를 타고 있는가?
본 항목은 엔지니어링 측면은 아니지만 성공적인 데브옵스 도입을 위해 고려해야 할 핵심적인 부분입니다. 애자일팀은 스크럼이나 스쿼드라는 이름으로 개발자(SDE), 테스트 엔지니어(SDET), 데브옵스 엔지니어, 프로덕트 매니저 역할을 가진 팀원들로 구성됩니다. 각각의 역할은 개발팀, 테스트팀, 데브옵스 팀, PM팀 등의 원소속이 있으면서 매트릭스 조직으로 팀이 구성되는 것이 흔한 데요. 원 소속 조직을 운영하는 것은 리소스의 공유정도를 늘리고 각 역할별 전략 공유나 직무 교육, 사례 전파, 일관된 평가체계 등을 유지하는데 유리하기 때문이죠. 이러한 조직 구성은 애자일의 성숙도와 관계없이 대다수 기업에서 유사한 형태로 운영합니다. 그러나 스쿼드 팀이 애자일과 데브옵스의 철학에 맞게 잘 작동되려면 원 소속 여부와 관계없이 팀내 공통의 목표 공유와 평가 설정이 필요합니다.
cross functional common goal squad #1 / squad #2 / squad #3
SDE,SDET,DevOps,Product Owner(or BA) / SDE,SDET,DevOps,Product Owner(or BA) / DevOps,Product Owner(or BA),UX [그림 9] 매트릭스 조직의 스쿼드 팀 구성
키워드에 대한 정보 데브 옵스
다음은 Bing에서 데브 옵스 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.
이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!
사람들이 주제에 대해 자주 검색하는 키워드 DevOps 는 무엇인가요? 현직 DevOps 엔지니어, AWS Hero 가 이야기하는 DevOps 이 정확한 의미.
- awshero
- aws
- cloud
- 클라우드
- 데브옵스
- devops
- 송주영
- terraform
DevOps #는 #무엇인가요? #현직 #DevOps #엔지니어, #AWS #Hero #가 #이야기하는 #DevOps #이 #정확한 #의미.
YouTube에서 데브 옵스 주제의 다른 동영상 보기
주제에 대한 기사를 시청해 주셔서 감사합니다 DevOps 는 무엇인가요? 현직 DevOps 엔지니어, AWS Hero 가 이야기하는 DevOps 이 정확한 의미. | 데브 옵스, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.