디지털 Transformation, 데이터센터 & Cloud, 베트남

DevOps

DevOps의 정의 (Wikipedia 참조): 소프트웨어 개발자와 인프라 운영 담당자간에 소프트웨어 배포 프로세스의 자동화및 인프라스트럭처의 원활한 변경을 위해 협업 및 의사소통을 반영한 개발 환경이나 문화를 의미한다. 소프트웨어의 개발, 테스팅 및 배포를 더 빠르고, 자주, 안정적으로 하기 위해 시작되었다.

전통적인 IT 조직은 개발, 운영, 테스팅 조직이 팀으로 나뉘어져 있다. 개발자는 운영에 대한 고민없이 개발이 끝나면 단위 테스팅을 거친 후 운영조직으로 넘기고, 물론 운영조직과 통합 테스팅 과정을 거치기는 하지만 본질적으로 운영은 운영 조직의 몫으로 여기는 경우가 많다. 이런 이유로 대부분의 조직은 개발과 운영 조직의 사이가 대단히 안 좋은 경우가 많다. 하지만, DevOps는 개발, 테스팅, 운영조직간의 의사소통 및 협업을 위한 프로세스와 방법론을 제시하는데 대부분의 경우 개발/운영/테스팅이 함께 어우러져 이루어질 수 있어 효율성이 높아진다. 

DevOps 툴체인

개발,운영,테스팅 조직간의 협업, 즉 기나긴 사이클로 이루어지기 때문에 DevOps가 가능하도록 해주는 하나의 도구는 존재하지 않는다. 여러개의 도구의 집합, 소프트웨어 개발에서 배포 프로세스까지 이어지는 DevOps 툴체인이 필요하다. 

1. Code: 코드 개발 및 리뷰, 버전 콘트롤 도구 등

2. Build: Continuous Integration 도구, Jenkins

3. Test: Continuous Testing 도구, 즉 비즈니스 위험도 등에 대한 피드백 제공

4. Package: Artifact repository, 애플리케이션의 사전 배포 단계

5. Release: 변경 관리, 배포 승인 및 배포 자동화

6. Configure: 인프라 설정 및 관리, Infrastructure as Code 도구, Puppet

7. Monitor: 애플리케이션 성능 모니터링, 즉 최종 사용자 경험 관리

* Docker (containerization) 등

DevOps의 목적은 소프트웨어 배포를 더 빠르고, 자주, 안정적으로 하기 위한 환경을 제공하는 것이다. 배포 매니저는 애플리케이션 배포 자동화 및 Continuous Integration 도구를 통해 진행하는데, Continuous delivery 접근 방식을 택한다. 

Cloud Friendly, Cloud Native 등 친숙하지 않은 개념들을 많이 듣게 됩니다.

Cloud Native Application은 Cloud 환경에 최적화된 애플리케이션이라고 할 수 있는데 이것만 가지고는 어떤 의미인지 이해하기가 어렵습니다.

기업들이 Cloud를 도입하는 이유가 뭘까요? 새로운 기술, 즉 트렌드라서? 분명한 이점이 있기 때문일텐데요, 

가장 대표적으로 IT자원에 대한 자산투자를 하지 않고, 데이터센터 및 서버/운영체제/스토리지/네트웍 등의 자원에 대한 운영인력을 줄이고 컴퓨팅 자원은 필요할 때 즉각적으로 사용하고, 사용량만큼 비용을 지불할 수 있기 때문일 겁니다. Cloud도입 초기에는 인프라(데이터센터, 서버/스토리지/네트웍 등)를 빌려쓰는 IaaS로도 효과를 충분히 볼 수 있었지만, IaaS를 사용해보면 알겠지만 운영체제의 운영, 데이터베이스 운영, 네트웍 및 미들웨어 (Tomcat, Jeus 등) 운영 등 실제 애플리케이션 개발을 위한 플랫폼 운영 관련한 인력이 유지되어야 하고, 플랫폼 소프트웨어 설치/운영/모니터링 등의 업무도 그대로 남게 됨을 알 수 있습니다. 소프트웨어 개발자와 시스템 운영자는 여전히 넘을 수 없는 벽을 사이에 두고 일하게 되고, 개발자가 짠 애플리케이션은 하나의 거대한 단일 애플리케이션 (Monolithic)으로 구성되어 있어, 그중의 일부를 바꾸기 위해서는 전체 애플리케이션을 빌드하고 배포해야 하므로 배포는 자주해서는 안되는 금기시되는, 고객에게 필요한 기능도 쉽게 적용할 수 없는 상황에 처하게 됩니다. 

Cloud에 최적화된 애플리케이션은 바로 위에서 벌어지는 다양한 불합리함을 극복할 수 있게 해주는데, 가장 중요한 factor는 자동화라고 볼 수 있을 것 같습니다. 여기서, DevOps, Continuous Delivery, Micro-service, 그리고 Container 개념이 등장하게 됩니다. 

DevOps는 소프트웨어 개발자와 IT운영자간의 협업을 의미하는데, 소프트웨어 배포(Delivery)나 인프라의 변경 프로세스를 자동화하는 목적으로 합니다. 소프트웨어의 개발, 테스트와 배포를 보다 더 빠르고, 자주, 안정적으로 할 수 있는 하나의 문화라고 볼 수 있을 것 같습니다. 

Continuous Delivery는 단위 애플리케이션이 변경되어 배포되어야 할 때 시스템 정비시간을 기다릴 필요없이 배포할 수 있는 특징을 의미합니다. 배포작업은 모든 개발자 및 시스템 운영자가 부담스러워 하는 작업인데, 위험부담을 줄이고 고객의 피드백을 빠르게 적용하여 경쟁자를 압도할 수 있게 됩니다. 넷플릭스나 Amazon.com이 하루에도 수십/수백번의 배포를 할 수 있는 것도 바로 Continuous Delivery 정책을 사용하기 때문입니다. 

Microservice는 작은 서비스의 결합으로 하나의 애플리케이션을 구성하는 아키텍처 디자인 접근방식입니다. 각 서비스는 HTTP API를 통해 통신하고, 서비스별로 배포, 업그레이드, 스케일 out 및 구동될 수 있고 타 서비스와의 연결고리가 약하게 되어 있기 때문에 사용자에게 영향을 최소화 또는 없게 업데이트할 수 있습니다. 

Container는 하나의 운영체제 (물리적서버 or VM에 무관)에 서로 독립적인 파일시스템과 리소스를 갖고 있는 container로 나뉘어 동작합니다. Container의 생성 및 폐기가 가상머신에 비해 엄청 빠르게 이루어지고, 자원도 거의 사용하지 않아 고집적으로 사용할 수 있습니다. 

바로 이러한 DevOps, CD, MSA, Container 방식으로 개발된 Cloud Native Application의 구동을 가능하게 하려면 PaaS (Platform as a Service)가 필요하게 되는데, 가장 많이 사용하는 플랫폼이 바로 Cloud Foundry 입니다. 

SK주식회사 CloudZ에서는 PaaS 서비스를 제공하고 있습니다.

PaaS (Platform as a Service)란 Cloud 애플리케이션을 쉽고 빠르게 개발하기 위한 SW 개발환경을 서비스로 제공하는 것을 의미합니다.

IaaS가 서버, 네트웍, 스토리지를 서비스로 제공한다고 하면

PaaS는 운영체제, 데이터베이스, 애플리케이션 서버 (WAS), JDK(Jave Development Kit) or .NET 등을 서비스로 제공하는 것을 의미합니다.

고객이 IaaS만을 사용하는 경우에는 고객이 운영체제, 데이터베이스, WAS, JDK / 개발 Framework을 직접 설치하고 운영해야 합니다. 이를 위해 별도의 운영 인력을 보유하거나, MSP (Managed Service Provider)를 통해 서비스를 제공받아야 합니다.

시스템 구축/운영, 미들웨어 구축/운영, 데이터베이스 구축/운영 등 여전히 운영을 위한 인력이 많이 필요하게 되고, 실제 애플리케이션 자체의 운영인력까지 필요하므로 클라우드 도입으로 인한 비용효과를 보기 어렵습니다.

PaaS 서비스는 오픈소스 Cloud Foundry, IBM Bluemix, Pivotal CF 등 3개사가 대표적인데

CloudZ에서는 오픈소스 Cloud Foundry를 통해 미래부가 개발한 PaaS-TA, IBM Bluemix를 PaaS로 사용하고 있습니다. Cloud Foundry는 자동차 엔진에 해당되는 역할을 하는데, 자동차를 이루기 위해서는 기어, 핸들, 속도계 등의 다양한 부가 서비스가 필요합니다. Microservice Architecture로 개발하여 운영되기 위해서는 Database as a Service, API Gateway, Circuit Breaker, Discover 서비스 등이 필요하게 되는데, 이런 다양한 서비스들을 오픈소스 기반으로 개발하여 제공하고 있습니다.

PaaS 도입으로 인한 효과는

첫째, 실행환경 설정 자동화를 통한 서버 구성시간 단축 (Provisioning), 즉 개발환경 구축보다 서비스 개발에 집중

둘째, 빌드/테스트/배포 자동화를 통해 개발 시간 단축, 신속한 배포

셋째, 모듈별 부하량 증감에 따라 자동화된 Auto-scaling 가능, 예) 급여명세 조회 microservice의 부하 증가시 해당 microservice만 늘어나도록 하는 방식

넷째, 기존 서비스 중단 없이 신규 서비스의 무중단 배포 가능, 접속 경로 변경을 통한 신규서비스의 무중단 배포

를 가능하도록 합니다.

Microservice 아키텍처의 개념은, 클라우드 애플리케이션을 기능별로 독립된 모듈화 구조로 설계하는 것을 의미합니다. MSA의 장점은, 전통적인 크고 복잡한 구조를 가진 하나의 서비스 (monolithic architecture)가 아닌, 기능별로 분리하여 여러개의 독립적인 모듈로 구성하여 개발 속도면에서 빠르게 개발 가능하고, 신속하고 빈번한 업데이트와 배포가 가능하다는 장점이 있습니다. (Rapid, frequent, reliable deployment)

또한, 보안성을 높일 수 있다는 장점이 있는데, 보안 취약점에 대한 빠른 대응이 가능하기 때문입니다.

Amazon과 Netflix가 DevOps 기반의 MSA 구조로 되어 있는 대표적인 사례 입니다.

하지만, 모든 애플리케이션이 MSA에 적합한 것은 아닙니다.

1) On-premise/IaaS 상의 애플리케이션

   - 안정적인 백오피스 업무

   - 기록/통계/보고서 중심 업무

   - ERP, 지급관리, 세무관리, 재고관리, 마스터데이터 관리, 회계 시스템 등

2) Cloud Friendly (Container 기반 서비스)

   - 확장 가능한 백오피스 업무
   - 대부분의 기존 Application
     . 빠른 환경 구성 및 표준화

     . 자원부족에 따른 장애 최소화
     . 서비스변경 영향도 최소화

   - Seasonal Effect 존재
   - MIS, CRM, SCM, 웹/커머스, 마케팅, 조달, 분석시스템, 워크포스 관리

3) Cloud Native (MSA)

   - 고객 접점 업무
   - B2C 애플리케이션 (빈번한 배포 필요)

   - 시장반응 분석 및 빠른 수정/배포 (A/B 테스팅 등)
   - 모바일 앱, 소셜커머스, 인터넷 서비스, 위치기반서비스, IoT, 빅데이터, 머신러닝/분석 기반