[Cloud Z] 클라우드 인프라(IaaS)를 통한 혁신, 그리고 과제

지난 해, 영국이 EU를 탈퇴한다는 브렉시트(Brexit)를 선언했을 때, 증권업계에서는 리스크 계수와 상품 가치를 재평가해야 하는 이슈가 생겼다. 이를 계산하기 위해서는 엄청난 컴퓨팅 리소스가 필요한 상황이었다. 보통 이런 업무는 리스크 관리 시스템이 하는데, 여러 대의 서버를 클러스터로 묶어 운영한다. 

온프레미스 환경에서 서버를 추가 도입하기 위해서는 하드웨어를 발주하고 선정, 데이터센터에 설치, 운영체제 설치, 네트워크 구성/연결, 보안환경 구축 등의 과정이 필요하다. 이 모든 과정에 필요한 시간은 아무리 빨라도 보통 1.5개월 정도가 소요된다. 지금 당장 필요한 리소스임에도 불구하고 적지 않은   준비 기간이 필요한 것이다.

하지만 클라우드 인프라를 사용하고 있었다면 해당 기업은 몇 번의 클릭만으로 10분 안에 이를 해결할 수 있다.

이렇게 IaaS 도입만으로도 충분히 민첩성, 비즈니스 대응 효과를 누릴 수는 있다. 하지만 IaaS를 통한 민첩성은 딱 여기까지만이다. 인프라 구축 다음 단계인 개발환경 구축, 개발/테스트, 변경/배포, 운영/장애 처리에 있어서는 기존 온프레미스 방식과 별다른 차이가 없다. 즉, IaaS를 도입한다고 해서 소프트웨어 개발이나 배치 속도가 빨라지는 것은 아니라는 의미다. 

비즈니스 민첩성은 하드웨어 내지 인프라 도입만을 의미하는 것이 아니며, 소프트웨어 개발/변경/테스트/배포를 포함하여 배치 속도까지 빨라졌을 때 비로소 완성된다.  그렇다면 이 단계에서의 민첩성은 어떻게 향상시킬 수 있을까. 단순히 ‘클라우드를 도입해야 한다’라는 기, 승, 전, 클라우드가 아니라 인프라 구축 이후 단계에서 비즈니스 속도를 높이기 위한 추가적인 ‘무언가’가 필요하다는 결론에 도달하게 된다. 

그림 1│인프라 구축 이후 속도 향상에 필요한 기술과 트렌드

(그림 1)이 바로 클라우드 인프라 구축 이후 단계에서 속도를 향상시키기 위해 필요한 기술과 트렌드다.

그림 2│클라우드 서비스와 사용자 층

(그림 2)에서처럼 IaaS는 인프라 관리자, PaaS는 서비스 개발자, 그리고 SaaS는 서비스 사용자를 위한  것이다.

빠른 배포 및 테스트 수행까지 연결된다. 이것이 PaaS의 본질이고 혁신이라고 할 수 있다. 개발 프로세스가 민첩해져야 할 때, PaaS는 그 효용성이 극대화된다.

속도를 향상시키기 위해 필요한 아키텍처 ‘마이크로서비스’

디자인 및 개발 단계에서는 항상 소프트웨어 아키텍처에 대해 고민하기 마련 인데, 비즈니스 민첩성을 확보하기 위해서는 서비스간 연관관계를 최소화할 수 있는 아키텍처 디자인이 필요하다. 애플리케이션 개발 속도가 더딘 이유 가운데 하나는 복잡한 개발 환경에 있는데, 이는 서비스 개발자가 항상 고민해 오던 문제이며, 좀처럼 해결하기 어려운 문제이기도 하다.

마이크로서비스 아키텍처는 각 서비스와 데이터를 분리해 독립적인 단위로 배포, 수정, 확장할 수 있는 클라우드 네이티브 아키텍처다. 마이크로서비스는 각 서비스간 결합도를 낮춤으로써 독립적인 단위 배포가 가능하기 때문에 배포 시간과 재기동 시간을 드라마틱하게 단축시킬 수 있다. 

또한 자바, 파이썬(Python), Node.js 등 각 서비스마다 서로 다른 최적의 개발 언어 및 환경을 선택할 수 있다는 장점이 있으며, 무엇보다 가장 큰 장점은 자원 확장이 필요한 서비스만 부분적으로 스케일 아웃(scale out)이 가능하다는 점이다. 이를 통해 트랜잭션이 가장 많이 발생하는 서비스의 리소스만 확장할 수 있으며, 장애 발생 시 주변 시스템에 주는 영향도를 최소화할 수 있다는 강점을 가지고 있다.

속도를 향상시키기 위해 필요한 방법론 ‘데브옵스(DevOps)’

기업의 속도를 느리게 하는 요소 가운데 하나는 바로 조직 간 문제다. 개발 과정에서의 속도는 개발 조직과 운영 조직 간의 협업이 중요한데, 이런   협업을 극대화하기 위한 방법론이 바로 데브옵스(DevOps)다.

기존의 개발 프로세스는, 개발 조직에서 코드를 만들고 운영 조직에서 배포 한 후, 장애가 발생한 부분을 개발 조직이 다시 넘겨 받아 수정하는 방식이다.  이런 프로세스를 계속 반복하게 되면, 개발자와 운영자 간 벽으로 인해 생산성이 떨어지고 개발 속도는 느려지게 되며, 결국 개발 주기는 한 없이 길어진다. 

데브옵스는 말 그대로 개발 조직(Development Organization)과 운영 조직(Operation Organization)을 결합해 서로간 벽을 허물어 애플리케이션 개발 속도를 혁신하는 것이다. 단순히 속도의 혁신을 위한 조직간의 물리적인 통합이 아니라, 소프트웨어 개발 프로세스와 인프라 딜리버리의 자동화를     의미하며, 단단한 커뮤니티를 형성하는 기업의 문화이자 방법론이기도 하다.

데브옵스가 클라우드 도입 시 많이 거론되는 이유는 운영 조직이 하던 역할을 클라우드 사업자의 서비스가 대체함으로써 개발 조직이 셀프서비스하는 경우가 증가하기 때문이다. 그렇다고 운영 인력들이 할 일이 없어지는 것이 아니라, 기업의 속도 향상을 위해 필요한 다른 주요 업무에 집중할 수 있는 환경을 만들어 준다는 점에서 기존의 개발 방식과 큰 차이가 있다.

그럼 개발자의 셀프서비스는 어떻게 가능할까. 개발자의 경우, 숙련된 운영 자가 아니기 때문에 자동화 도구가 필요하다. 예를 들어, 운영체제와 WAS를 설치하고, 네트워크를 구성하는 등 운영인력이 기존에 하던 작업들을 개발자 스스로 몇 번의 클릭만으로 해결할 수 있는 자동화 도구가 필요한 것이다. 이러한 서비스를 제공하는 것이 바로 클라우드 플랫폼 서비스(PaaS)다.

PaaS는 IaaS 도입만으로는 얻을 수 없는 비즈니스 민첩성을 갖추기 위한 최선의 선택이며, 데브옵스와 마이크로서비스 아키텍처와 함께 융합됐을 때, 그 효과성은 극대화된다. 단순히 클라우드를 도입한다고 해서 속도가 빨라지는 시대는 지났다. 이제는 어떤 클라우드 서비스를 어떻게 활용하느냐가 관건인 시대이다.

* 인사이트 리포트 파일 다운로드 받기 *

* 클라우드 제트 포탈로 바로가기 *