데브옵스(DevOps)의 IT운영 방식이든 고전적인 IT 운영 방식이든 운영 팀이 늘 직면하게 되는 간단하지만 반복적인 작업, 간단하지 않으면서도 반복적인 작업, 멀티티어(Multi-tier)로 복잡하게 얽힌 구성에서 순서를 갖고 해야 하는 작업 또는 동시에 진행해야 하는 작업을 쉽게 자동화해 AWS EC2클라우드 상에서 안정적으로 수행할 수 있도록 해 준다. 최소 1분 단위로 체크한 서버의 상태나 쉘스크립트 수행의 결과 값으로 어떠한 연계 대응 작업도 실행해 낼 수 있다.

퍼블릭 클라우드 도입으로 비용 절감. 생산성 향상, 그러나...

요즘 이슈가 되고 있는 퍼블릭 클라우드를 도입할 경우 IT 설비를 구축할 필요가 없다. 물리적인 컴퓨팅 자원을 관리할 필요가 없어 IT 인력도 줄일 수 있다. 또한 컴퓨팅 자원이 필요할 경우 언제든지 추가로 자원을 할당할 수 있어 초기 과잉 투자를 방지할 수 있다.

하지만 개발, 테스트 환경 조성의 편의성, 서버 운영의 탄력성 등으로 IT 운영 인력이 담당해야 할 서버의 숫자는 n대에서 10n대의 단위로 늘어나게 된다. 물리적인 컴퓨팅 자원들은 제작 회사, 디자인, 모델 이름, 설치 위치 등에 따라 IT 운영 인력이 해당 자원을 인지할 수 있는 반면 클라우드 상의 자원들은 10바이트 이상의 문자와 숫자로 이루어진 아이디(ID)로 컴퓨터 화면 상에서만 보이기 때문에 IT 인력이 해당 자원을 구별하고 작업을 진행하는 데 어려움이 많은 것이 사실이다. (인스턴스 i-1234567890에 vol-987654321과 vol-123454323이 /dev/sdf, /dev/sdg 로 장착돼 있고 sg-019283847를 보안 그룹으로 사용하고 있다. 그리고 해당 볼륨의 백업 스냅샷은 snap-3738f8a0, snap-98e364b74 등)

시장 점유율이 세계 최고인 AWS 클라우드를 사용하고 있다 하더라도 개개의 클라우드 자원은 언젠가는 반드시 작동을 멈추게 되어 있다. 또는 적어도 ‘2 주 후에 유지보수 작업을 진행하니 미리 인스턴스를 마이그레이션 하기 권장합니다’ 등의 메시지를 받게 된다.

클라우드 도입으로 IT 생산성을 향상시킬 수 있게 됐지만 장애 대비 활동이나 백업, 업그레이드, 패치 설치 등의 전형적인 IT운영 팀의 제반 업무는 별로 나아진 것이 없다고 해도 과언이 아니다. 오히려 담당해야 할 가상 컴퓨팅 자원의 증가로 인재(Human Error)를 야기할 수 있는 부분이 더 많아졌다고 할 수 있다.

클라우드 자원 관리 위해 지휘 도구는 옵션이 아닌 필수

클라우드 환경이라고 시스템 장애가 없다고 생각하면 안 된다. 어떤 경우에든 장애에 대한 대비는 필요하며, 장애에 대비하지 않을 경우(하드웨어 장애를 제외하고) 시스템 장애를 복구하는 시간 역시 그만큼 늘어날 수밖에 없다.

담당할 컴퓨팅 자원이 늘어난 만큼, 이들 자원을 효과적으로 관리하기 위해서는 반복적인 작업, 특정 패턴이 있는 작업들을 가능한 한 많이 자동화(Automation)해 발생할 수 있는 오류의 확률을 줄이는 것이 중요하다. 자동화된 작업이 많을수록 IT 담당자가 반복적이고 비생산적인 일보다 IT 기획과 같은 보다 생산적인 일에 전념할 수 있다는 것은 IT 종사자라면 누구나 알고 있는 사실이다.

이런 사실을 알고 있음에도 현재 IT 업무의 상당부분이 자동화 되어 있지 않다. IT담당자들은 그 이유로 다음과 같은 세 가지 이유를 들고 있다.

자동화 구현을 위해 가장 많이 쓰이는 도구는 ‘쉘스크립트(Shell Script)’로 약 77%가 쉘스크립트를 사용하고 있는 것으로 조사되고 있다. 자동화를 위해 새로 배울 필요 없이 현재 자신이 이미 잘 알고 있는 도구를 사용하기 때문에 나타나는 현상으로 이는 IT 업무 자동화가 미뤄지는 한 요인이 되고 있다.

가장 많이 사용되는 ‘쉘스크립트’가 자동화 구현에 높은 생산성을 제공하지 못하고 있어 큰 효과를 보지 못한 담당자들이 IT 업무 자동화를 미루고 있다는 것이다.

IT 운영 관리자의 언어 사용

로버스택(robustack)은 아마존(Amazon) EC2 자원의 지휘를 위해 리눅스(Linux)의 Bash 스크립트를 벗어나 어떠한 추가적인 스크립트 기술이나 언어 형식(Ruby, Python, JSON, YAML등)의 사용을 요구하지 않는다. 소프트웨어를 설치하기 위해 소프트웨어 배포자가 제공하지 않는 설치 스크립트를 따로 만들 필요도 없다. 소프트웨어 배포자의 설치 매뉴얼이 제공하는 방법을 그대로 사용하면 된다.

개개의 EC2 자원을 지칭하고 구성하기 위한 템플릿 작성도 필요하지 않다. 그룹 단위의 멀티티어 스택(Multi-tier Stack) 이미지를 선택하고 메뉴 운용 방식에 따라 구성을 완성해 나가는 동안 구성 정보(Configuration)가 자동으로 만들어지고 ‘저장’ 버튼을 통해 로버스택 구성 DB에 기록된다.

이러한 구성 정보는 향후 해당 그룹스택(로버스택 용어, 그룹 단위의 멀티티어 스택 약자)을 다른 곳으로 복제하거나 저장해 놓은 스냅샷에서 복원할 때 사용된다.

로버스택 사용자는 이름이 붙여진 EC2 자원을 선택하고 필요로 하는 작업을 메뉴에서 선택하거나 명령 수행 수준의 리눅스 Bash(Bourne Again Shell) 스크립트를 작성하는 것으로 AWS EC2 전반에 관한 작업을 지휘하고 자동화 할 수 있다. AWS CLI(Command Line Interface) 등도 Bash 스크립트로 당연히 실행된다.

하나의 작업을 수행하고 다음 작업을 위해 대기하고, 동시에 여러 개의 작업을 수행하고, 일정에 맞춰 작업을 할당하고 - 이 모두 로버스택이 손쉬운 클라우드 지휘를 위해 제공하는 프레임워크다.

EC2컴퓨팅 자원을 효과적으로 다루고 있는가

구성 관리(Configuration Management)를 클라우드 지휘 도구라고 일컫는 많은 클라우드 관리 도구들(AWS의 CloudFormation 포함)은 대부분 신뢰성을 기반으로 하지 않는 하드웨어(Commodity Hardware)의 가상 머신(Virtual Machine, AWS EC2에서는 Instance)을 관리하는 도구에서 출발했다고 해도 과언이 아니다.

최근 마이크로 서비스(Micro Service)나 서버리스 아키텍처(Serverless Architecture)가 관심을 모으고 있지만 얼마 전까지만 해도 가상 서버의 변경 배제 업무 배치(Immutable Deployment: 가상 서버를 한번 실제 업무에 배치하면 더 이상 가상 서버를 수정하는 일은 배제하며 변경이 필요할 경우 수정이 적용된 이미지로부터 새롭게 가상 서버를 만들어서 대체한다는 개념, Stateless Deployment 라고도 함)가 가장 이상적인 가상 서버 IT 운영 환경으로 주목을 받고 있었다.

또한 예전의 가상 머신 기술은 지속형 스토리지(Persistent Storage, AWS EC2에서는 EBS 볼륨)를 장착해 운용이 쉽지 않았으며 가상 머신 관리 도구들은 이러한 제한된 기능에 편승해 새 기류에 부합하는 기능(Configuration Management 등)을 속속 출시했다.

하지만 실제 IT 환경에서 변경 배제 업무 배치(Immutable Deployment)를 제대로 구현할 수 있는 분야가 많지 않았고 구현이 가능한 분야라고 하더라도 시간이나 비용면에서 효율적이지 않아 지속형 스토리지 사용은 계속 이어질 수밖에 없었다.

또한 EC2 같은 퍼블릭 클라우드 환경에서 클라우드를 도입하는 사용자들이 Immutable Deployment를 염두에 두고 클라우드를 택하는 것은 아니었다. AWS가 최초는 아니지만 AWS EC2가 EBS(Elastic Block Storage)를 기반으로 하는 인스턴스 타입을 출시하면서 클라우드 상의 가상 머신이 물리적 서버를 대체할 수 있는 획기적인 전기를 마련했고, 이것으로 AWS EC2 비즈니스가 탄력을 받은 것이 사실이다.

지속형 스토리지를 가상 머신의 루트 볼륨으로 활용할 수 있게 됨으로써 변화가 가해지지 않은 가상 머신을 쓰지 않을 때는 강제 종료(Terminate)하는 대신 정지(Stop)시키고 사용하던 데이터를 매번 스냅샷(Snapshot)을 만들었다가 새로 생성해 내는 대신 볼륨을 그냥 다시 붙여서 사용하는 것이 유리하다. 그런데도 앞서 언급한 클라우드 관리 도구들은 가상 머신을 재시작(Restart)할 때 굳이 구성 관리 기능(Configuration Management)에 의존하면서 ‘강제 종료 후 재생성(Re-Launch)’이라는 방식을 고수하고 있는 경우가 많다.

로버스택은 EBS 등의 지속형 스토리지와 컴퓨팅 자원의 재생성(Rebuild)과 수정(Modification) 모두에 관한 지휘를 지원한다. 스팟 인스턴스(Spot Instance)와 같이 AWS 기능만으로는 정지 자체가 불가능한 자원까지 ‘정지 후 재사용’할 수 있는 새로운 지휘 패러다임을 제공한다.
 

워크플로우 기반 프레임워크로 웹 서비스 한계 뛰어넘다

아마존 웹 서비스(Amazon Web Service)만의 특성이 아니라 웹 서비스는 일반적으로 상태가 없는(Stateless) 서비스를 제공한다.

Stateless 형태의 서비스는 여러 가지 디자인 상의 장점이 있지만 정해진 절차에 의해서 시스템 명령을 실행하고 다음 실행으로 넘어가기 위해서는 바로 전 스텝이 완료되기를 기다려야 하는 전형적인 IT 운영 작업 진행과 일괄 작업(Batch Job), 자동화 작업 등의 구현을 까다롭게 한다.

한 예로 서비스 중인 인스턴스에 보안 패치를 적용하는 과정을 보도록 하자.

단순한 절차에 속하는 작업이지만 다음 단계로 진행하기 위해서 작업자는 지속적으로 작업 진행 상황을 확인할 수밖에 없고 만약 여러 인스턴스에 대해 동시에 진행한다면 더욱더 작업에 집중해야 한다. 또한 작업 오류를 만들어 낼 가능성도 배제할 수 없다.

AWS CLI(Command Line Interface)와 Bash Script를 사용해 자동화 스크립트를 작성해서 실행할 수 있지만, 아이디 값을 리턴 받고 실행 완료를 기다리는 내용을 스크립트화 하려면 적잖은 노력이 필요하다. AWS CloudFormation을 사용하기에는 까다로운 작업이고 AWS OpsWorks를 사용하더라도 많은 노력이 필요하다.

로버스택(robustack)에서는 메뉴 운용(Menu Driven) 방식으로 해당 인스턴스를 선택하고 아래와 같이 워크플로우 명령으로 이루어진 순차 작업(Sequence Job)을 만들어 놓았다가 간단하게 클릭해 실행하거나 일정, 트리거 작업에 적용할 수 있다. 순차 작업을 만드는 방법은 아주 간단하다. 순서를 정해서 실행될 객체와 실행할 명령을 메뉴에서 선택하면 된다.

순차 작업 실행 중 하나의 워크플로우 명령이 실패하더라도 전체 진행을 중단시키므로 오류의 파급을 사전에 차단한다. 실패 원인을 바로잡은 후 수정된 부분부터 다시 순차 작업을 실행할 수 있다. 하나의 순차 작업 내에서 워크플로우 명령으로 실행될 객체는 AWS 상의 어느 위치에 있는 자원이라도 상관없다. 예를 들어 시드니 리전(Region)의 서버를 리부트 한 후 리부트가 완료되면 다음 순서로 서울 지역에 있는 서버를 리부트 할 수 있다.

강력한 롤백(Rollback), 복원(Restore), 복제(Clone) 기능

IT 운영 업무의 상당 부분을 차지하는 백업(Backup 또는 Snapshot) 작업은 하드웨어 장애(EBS 볼륨 등)로 인한 데이터 유실, 소프트웨어 장애(업그레이드, 패치 결함)로 인한 오작동, 소프트웨어 장애 원인 분석 테스트 베드 구축, 응용 프로그램 개발이나 테스트 환경 구축 등에 대처하기 위한 필수 불가결한 업무이다.

로버스택은 정기 또는 비정기적으로 실행한 서버의 루트 볼륨이나 일반 볼륨 스냅샷에 대한 정보를 그룹스택 단위로 체계적으로 저장했다가 필요에 따라 원스톱으로 빠르게 롤백, 복원, 복제할 수 있는 편리하고 강력한 기능을 갖추고 있다.

지휘 포털 또는 별도 포털 구축 형태로 이용

로버스택 포털(https://console.robustack.com)에 접속해 종량제 과금 형식(Pay as you go)으로 이용하거나 추가 보안을 위해 사용자 설정 데이터베이스를 고객 권한 하에 두고자 하는 경우 별도의 포털 구축을 의뢰할 수 있다.