저렴하면서도 전기를 덜 먹는 환경친화적인 IoT 클라우드 컴퓨팅 환경을 고민했다. 그 고민의 결과물로 ARM 프로세서, 비가상화, 메모리카드 기반의 인스턴스 증가 등을 이용해 컴퓨팅 환경을 디자인했다. 이번에는 그 중 소프트웨어를 다룬다. 이 글을 읽기 위해서는 클라우드에 대한 이해가 필요하다.

전체 클라우드 소프트웨어 아키텍처

모든 인스턴스는 기본적으로 우분투 14.04.1 LTS에서 동작한다. 필자의 데스크톱 PC만 예외다. 그림 1에서 Instance Hive는 늘어난 컴퓨팅 자원을 묶는 가상의 묶음이다.
더 많은 컴퓨팅 자원이 필요한 경우에는 컴퓨팅 인스턴스가 늘어나서 가용성을 확보한다.

클라우드가 되기 위한 조건

날마다 접하는 클라우드라는 용어는 매우 특별해 보인다. 하지만 실체는 과거부터 이어온 네트워크 컴퓨팅 환경의 한 형태일 뿐이다. 클라우드가 되기 위해서는 다음 세 가지를 만족하면 된다.

1. 분산/스케줄링
2. 스케일 매니징
3. 자원의 배포

필자 또한 이 세 가지를 효과적으로 만족시키기 위해 노력했으며, 독자들도 클라우드 컴퓨팅 설계를 한다면 고민할 최우선 과제가 된다. 이 세 가지 소프트웨어 개발에는 ZooKeeper 하나만 썼다. ZooKeeper가 완벽해서가 아니라 그냥 만드는 게 효과적이라고 생각했다. ZooKeeper는 위에 나열한 세 가지와 큰 관련 없는 오픈 소프트웨어다.

하나씩 이야기하기 전에 가상화 이야기부터 하겠다. 조건에 가상화에 대한 언급이 없어서 이상하게 생각한 독자도 있을 것이다. 가상화 솔루션 회사의 클라우드에서의 가치를 살펴보면 여러 가지 내세우는 것이 있지만 클라우드에 있어서 가장 높은 가치는 고립성이다. 우리가 하나의 PC에 여러 네트워크 소프트웨어를 설치하다보면 포트가 충돌한다. 하지만 하나의 PC에 하나의 소프트웨어만 설치한다면 충돌할 수 없다. 또한 네트워크 소프트웨어가 아니어도 여러 개의 소프트웨어를 하나의 머신에 설치하면 의존성이 문제가 된다.

A 소프트웨어는 1.0의 라이브러리가 필요하고 B 소프트웨어는 2.0의 라이브러리가 필요하다면, 우리는 A, B 중 하나의 소프트웨어만 쓸 수 있다. 만약 우리가 물리적인 하나의 PC처럼 컴퓨팅환경을 고립시킬 수 있다면, 이런 고민을 전혀 할 필요가 없다.

이 고민을 풀어주는 것이 가상 머신 솔루션이다. 가상 머신 솔루션을 이용해 클라우드를 구축할 경우 클라우드가 되기 위한 조건에서 3번 자원의 배포가 매우 유연해진다. 하드웨어의 한계(CPU, 메모리, 디스크, 네트워크)만 충분하다면 하나의 물리적인 컴퓨팅 환경을 고립된 여러 개의 컴퓨팅 자원으로 나눌 수 있기 때문이다.

가상화를 사용하지 않는 이유

필자가 이전에 나열한 이점에도 불구하고 가상화를 선택하지 않은 이유는 오버헤드 때문이다. 물리적인 서버에 운영체제(호스트 운영체제)를 설치하고, 다시 이 운영체제 안에 여러 개의 운영체제(슬레이브 운영체제)를 설치하는 구조이기 때문에 오버헤드가 발생한다.

이 오버헤드는 CPU 자원의 낭비를 발생시킨다. 따라서 소모 와트 당 처리량을 높이기 위해서는 제거해야 할 요소가 된다. 하지만 가상화가 없다면 네트워크나 파일과 같은 자원의 충돌 가능성이 있다. 따라서 하나의 인스턴스 자원을 구성하는 소프트웨어들이 이러한 충돌이 없도록 배치하는 노력이 필요하다. 이 노력은 매번 필요한 것이 아니라 기존 인스턴스에 소프트웨어를 추가할 때만 이루어지므로 실제로 클라우드 컴퓨팅 환경을 운영함에 있어서 차지하는 비용은 매우 작다.

CPU에서 가상화를 최적화시킬 수 있는 아키텍처가 도입됐다. 하지만 하드웨어를 최적화해서 얻을 수 있는 효율성 보다는 소프트웨어를 최적화해서 얻을 수 있는 효율성의 범위가 훨씬 높다. 따라서 전 클라우드에는 가상화보다는 도커(Docker) 같은 방법이 더 적절하다고 본다.

분산/스케줄링

분산과 스케줄링은 일을 나누기 위해서 필요하다. 일을 수행하는 Worker를 나누고 일을 수행할 시점을 나눈다. AWS와 같은 이미 준비된 컴퓨팅 자원이 많을 경우에는 스케줄링이 필요 없다. 스케일 매니저를 통해 더 많은 컴퓨팅 자원을 확보한 후에 일을 시키면 되기 때문이다.

그림 3에서 3번의 데스크톱 PC까지 이용해도 처리를 못하는 경우에는 일을 쌓아두어야 한다. 물론 그 전에도 일단 일을 쌓기는 하겠지만 컴퓨팅 능력이 충분하면 쌓이자마자 처리하게 된다. 요청에는 외부에서 들어오는 웹 요청과 센서 데이터와 같은 Outer-request, 그리고 학습과 리포팅을 위해 자체적으로 AI가 만드는 Inner-request가 있다.

이 모든 요청은 ZooKeeper를 거쳐 분산되고 잡큐에 쌓이게 된다(그림 4).

모든 컴퓨팅 인스턴스는 CPU의 사용량이 80%를 안 넘을 경우에는 잡큐에 있는 일을 하나 가져와서 수행한다. 아직 클라우드 환경의 데이터가 부족해서 정확한 이유는 모르겠지만 CPU 사용량을 80%로 유지하는 것이 가장 분당 처리량이 높았다. 여러 분산된 컴퓨팅 자원에 일을 주는 방법은 잡 스케줄러가 push 하는 방식과 컴퓨팅 자원에서 일을 Pull 하는 방식이 있다. 실시간처리의 경우 Push 방식만 가능하지만, 그 외의 경우에는 Pull 방식이 좋다. 왜냐하면 Push 방식의 경우, 일정 주기로 잡 스케줄러가 컴퓨팅 자원의 사용량을 수집하고 평균을 내어 일을 준다.

하지만 이것은 평균값이기 때문에 컴퓨팅 자원의 실시간 사용량과 차이가 있을 수 있다. 따라서 컴퓨팅 자원이 일을 당기는 방식이 더 효과적이다.

스케일 매니징

분산은 이미 확보된 컴퓨팅 자원에 일감을 나눠 주는 것이고, 스케일 매니징은 컴퓨팅 자원의 양을 키우거나 줄이는 것을 뜻한다. 예를 들어, 웹서버를 가정하고 서버가 2대라면 아무리 분산처리를 해도 2대의 서버를 넘는 요청이 들어오면 지연이 길어진다. 따라서 그런 시점에는 분산이 아니라 서버를 늘려주는 것이 필요하다. 역으로 한참 사용자가 많을 때의 처리를 위해서 서버를 4대까지 늘렸으나 새벽에 사용자가 줄어들면 다시 서버를 줄일 필요가 있다. 이 역할이 스케일 매니징이다.

기존 컴퓨팅 자원의 CPU 사용량이 80% 이상 5분간 유지되면, 1번 컴퓨팅자원에 전원을 공급해서 가용성을 늘린다. 다시 모든 컴퓨팅 자원의 평균 CPU 사용량이 80% 이상 5분간 유지되면 2번 자원에 전원을 공급한다. 이런 식으로 3번 데스크톱까지 활용한다(그림 5).

더 많은 컴퓨팅 자원이 필요할 경우, Odroid U3를 하나 사다가 SD카드만 꼽으면 된다. 물론 배송 시간이 걸리므로 평소의 컴퓨팅 처리량을 보고 미리 구입하는 지혜가 필요하다.

스케일 매니징이 가능하려면 평소에 쉽게 컴퓨팅 자원을 늘릴 수 있도록 소프트웨어가 셋팅된 운영체제를 포함한 이미지를 형상관리 해야 한다(그림 6참조. 필자의 IoT 클라우드 환경을 기반으로 시제품을 만들고 있는 곳이 있고, 그쪽의 인스턴스 이미지도 필자가 관리하기 때문에 모자이크 처리했다). 우분투 기반의 경우 16G 정도면 충분하다. 필자처럼 SD카드를 32G로 확장할 경우, 이 형상관리 하는 이미지량이 매우 크다. 따라서 필요 없으면 16G나 8G를 유지하는 것이 좋다. 필자의 인스턴스의 실제 크기는 7.4G 정도다.

어설픈 인스턴스 증가 과정

스케일 매니저에 의해서 스케일이 관리되려면 최소의 셋팅이 된 운영체제 메모리 카드를 컴퓨터에 삽입하는 과정이 필요하다. 이 부분은 크게 두 가지 문제가 있다.

1. 인스턴스 이미지를 수동으로 관리한다.
2. 사람 역할의 스케일 매니징에 중요하다.

이 때문에 메모리 카드를 수동으로 삽입하는 형태가 아닌 네트워크를 통해 부팅이 필요하다. 이 부팅은 WOL(Wake On Lan)은 아니며 머신에 있는 IO 장치 대신에 네트워크를 이용해서 부팅하는 방법이다. 이 방법은 U3에서 실패했다. 인스턴스 증가에서 사람의 개입이 크다면 실수할 확률이 생긴다. 네트워크를 통해 인스턴스를 부팅하고 이미지를 설치하는 방법이 필요하다.

Odroid U3 인스턴스를 최소 2대 운영하는 이유

1. Fail-over
2. 이미지 생성

데이터를 쌓는 일을 제외하고는 모두 Odroid U3로 하고 있는데, 최소 2대를 운영하는 이유는 Fail-over와 이미지 생성 때문이다. 하나의 U3만 운영할 경우 해당 컴퓨팅 자원의 문제가 생기면 다른 U3에 전원을 공급하여 부팅한다.

서비스를 수행할 준비 상태까지 걸리는 시간은 5분 정도다. 따라서 U3를 하나만 운영할 경우에는 컴퓨팅 자원의 문제를 바로 처리 못하고 5분의 서비스 공백이 발생하게 된다.

다음은 이미지 생성 문제다. 필자의 컴퓨팅 환경은 가상화를 안 쓰기 때문에 실행중인 컴퓨팅 자원의 이미지를 복사할 방법이 없다. 따라서 실행중인 하나의 U3에 소프트웨어를 설치하고 테스트한 다음에 셧다운 시키고 SD카드를 복사한다. U3를 강제 셧다운 시키면 최소 컴퓨팅 인스턴스 조건이 2대이기 때문에 다른 U3에 전원을 공급해서 작동시킨다.

이런 식으로 이미지를 뜨는 방법은 좋지 않다. 운영체제를 포함하기 때문에 형상 관리하는 이미지 크기가 크고, 필자가 이미지를 뜨기 위해 셧다운 시켰을 때 1번 U3에 문제가 생기면 5분간 서비스 공백이 생기기 때문이다. 차후에는 도커 같은 기술을 적용할 예정이다. 이번 클라우드 구축을 통해 도커 같은 기술의 필요성을 뼈에 새기고 있다.

자원의 배포

늘린 컴퓨팅 인스턴스가 웹서버라면 웹서버의 셋팅은 그대로지만, 웹 애플리케이션의 내용(HTML, JS, CSS)은 달라질 가능성이 높다. 컴퓨팅 이미지의 관리를 나노세컨드 단위로 할 수 없기 때문에 컴퓨팅 인스턴스를 늘린 후에 그 인스턴스 안에 다시 자원을 배포할 필요가 있다. 처음에는 Ant 스크립트 사용을 고려했다. 하지만 Ant 플러그인 설치와 설치 스크립트가 동적으로 바뀐다는 점 때문에 배포 솔루션을 만들었다. 이름은 거창한데 1시간 밖에 안걸렸다. 배포물을 FTP로 가져오는 구조이다.

U3에 전원이 공급되면, U3는 Starting 상태가 되고 배포 솔루션을 통해 모든 자원을 새로 받으면 Ready 상태가 된다(그림 8). 이 상태가 되면 외부 요청과 내부 요청을 처리한다. 자원을 비교해서 새로운 자원만 받는 형태로 하지 않은 이유는 배포 솔루션을 단순하게 만들 수 있고 Data Provider가 분리됐기 때문에 적은 수의 웹 리소스와 분석 알고리즘만 받으면 되므로 10초면 모두 받을 수 있기 때문이다.

와트(Watt) 당 처리량

부하를 잘 주기 위해서 테스트 노트북의 프로세스를 정리하고 유선으로 연결했다. 최초 시도 시 이 노트북(i7 4500U)으로는 충분한 부하를 줄 수 없어서 i7 계열의 데스톱 PC을 추가해서 분산 부하를 줬다. 와트 당 처리량을 측정하기 때문에 전력 측정과 벤치마킹을 동시에 수행한다.

XeonD와 같은 인텔 저전력 CPU와 비교하는 것이 적절하나 구할 수 없어서 필자가 가지고 있는 x86 프로세서인 i5-3570K와 비교했다. 따라서 이 비교는 적절한 비교가 아니나, 모바일시대에 왜 ARM이 주목을 받았는지와 컴퓨팅 환경 구성에서 강력한 CPU보다는 다수의 저전력 CPU가 효과적이라는 것을 볼 수 있다. 이 비교를 Intel vs. ARM으로 보지 말고 와트당 처리량이 왜 중요한지를 보는 것이 포인트다.

비교 항목은 다음과 같다.

1. 정적 웹 품질 보증 처리량 - 임계점 전에 적정 수준의 응답 속도를 만족하는 샘플의 개수이다. 응답 속도 0ms~250ms 사이에 들어온 샘플만을 카운트한다. jMeter를 사용했다. 많을수록 좋다.
2. 인터넷 사물 연결 수 - 플랫폼(VertX의 Verticle)에 연결할 수 있는 최대 인터넷 사물 수이다. 가상으로 인터넷 사물을 만들어서 플랫폼과 연결하여 센서 데이터를 보낸다. 많을수록 좋다.

이 세 가지의 항목을 와트로 나누어 와트 당 처리량을 비교하게 된다. 와트당 처리량이 높다는 것은 에너지 효율이 높다는 뜻이다.

정적 웹 품질 보증 처리량

와트 당 처리량과 연결 수(인터넷 사물 연결 수)는 ARM이 각각 4배, 7배 정도 높다(표 1, 2).
와트 당 처리량은 저전력 CPU가 매우 높기 때문에 저전력 CPU를 다수로 묶는 컴퓨팅 환경이 고성능 CPU 환경보다 낫다.

친환경 클라우드

현대의 컴퓨팅 환경은 Web Scale IT를 중심으로 설계되고 운영된다. 엄청난 가용성을 바탕으로 최적화 없이도 컴퓨팅이 가능하다. 많은 에너지 사용은 환경 파괴의 주요 원인이다. 따라서 컴퓨팅 환경의 효율화는 비용관리를 넘어서 인류가 지속적으로 공존하기 위한 의무이자 책임이다. 필자는 저전력 CPU와 비가상화 클라우드가 하나의 좋은 방법이라고 생각한다.

필자에 대해서
허원진은 10년 넘게 소프트웨어 엔지니어이자 아키텍트로 일해 왔다. 소프트웨어는 가상머신 개발과 같은 코어부터 앱 개발까지 넓은 스팩트럼을 유지하며 명품 소프트웨어를 만들기 위해 노력하고 있다. 허원진은 인류의 삶을 변화시킬 IoT 파트너를 찾고 있다.

참조/관련 글
- 집에서 만드는 친환경 클라우드 - 하드웨어와 인프라편
- 24시간 안에 AWS를 통한 IoT 클라우드 환경구축하기