집에서 만드는 친환경 클라우드 - 하드웨어와 인프라편

2015-04-07
김언한 기자, unhankim@elec4.co.kr

글 | 허 원 진 아키텍트

작년에 AWS를 통해 IoT 클라우드 환경을 구축해 보고 필자가 원하는 컴퓨팅 환경에 AWS를 이용할 경우 한 달에 400달러가 들어감을 확인했다. 그 후 저렴하면서 전기도 덜 먹는 환경 친화적인 컴퓨팅 환경을 고민했다. 그 고민의 결과물로 ARM 프로세서, 비가상화, 메모리카드 기반의 인스턴스 증가 등을 이용해 컴퓨팅 환경을 설계했다. 그 중 하드웨어 구성과 인프라 소프트웨어 셋팅을 소개한다.

클라우드 구축 결과

먼저 결과물을 보고 이야기하는 것이 나을 것 같다. 인터넷에 떠도는 예쁜 랙에 가지런히 장착한 것들을 보다가, 그림 1에 보이는 필자가 구축한 결과물을 보면 좀 실망했을 것이다. 운동기구 놓았던 자리에 공간을 마련했다. 기가허브, 마이크로서버, ARM 프로세서 4대를 이용해서 컴퓨팅 환경을 구성했다.

가용성은 마이크로서버 N대와 ARM 프로세서 M대로 확보한다. 마이크로프로세서는 2개가 기본으로 운영되고 부하에 따라 4대까지 기동한다. 총비용은 90만원이다.

아키텍처는 그림 2와 같다. 물론 IaaS에서 제공하던 로드밸런스나 가용성 확보를 위한 스케일 매니저는 사용할 수 없으므로 만들어서 구축했다.
마이크로서버를 늘리기 위해서는 USB 메모리를 꼽기만 하면 되고, 마이크로프로세서를 늘리기 위해서는 SD카드만 마이크로세서에 꼽고 전원을 넣으면 컴퓨팅 자원이 늘어난다.

필자가 이런 컴퓨팅 환경이 필요한 이유는 그림 5와 같은 복잡한 사물부터 온도/습도계 같은 단순한 사물까지 센서데이터를 수집하고, 분석하고, 인공지능(AI)이 이를 바탕으로 정보를 만들기 때문이다.

이 컴퓨팅 환경에서 동작하는 AI인 앤젤리아(Angelia)는 각종 센서 데이터를 바탕으로 제목+이미지+요약 형태의 정보를 만들어서 제공한다. 센서데이터에는 앞서 얘기한 자동차나 온도/습도계와 필자가 작성한 블로그도 하나의 센서 데이터다. 필자가 작성한 블로그는 공개된 데이터지만 개인적인 영상이나 소리, 위치 정보까지 중앙집중식 클라우드에 전송되는 것은 프라이버시에 좋은 방법이 아니라고 생각한다.

필자는 집안에 있는 컴퓨팅 자원들을 병렬로 묶어서 컴퓨팅 하는 방법을 연구하고 있다. TV, 냉장고, 세탁기 등의 컴퓨팅 자원을 병렬로 묶는 것이다. 성능과 프라이버시 문제를 동시에 만족할 수 있기 때문이다.

IoT 관련 컴퓨팅이 전에는 필자의 데스크톱 PC에서 돌고 있었다. 앤젤리아가 일을 조금 할 때는 필자가 PC를 쓸수 있지만 분석을 시작하면 PC를 쓸 수가 없었다. 이 컴퓨팅을 AWS에서 운영하면 한 달에 400달러가 소요된다. 운영비용 보다는 도쿄에 있는 AWS를 쓸때 발생하는 지연속도가 가장 큰 문제였다. 100 ms~200 ms 사이로 지연속도가 바뀐다. 중앙에서 실시간으로 분석하여 인포메이션을 만들기에는 너무 큰 지연시간이다. AWS와 같은 IaaS의 선택은 실시간성이 중요한 서비스에는 좋지 않다. 한국에 센터가 생길 때까지 다른 방법을 찾아야한다.

하드웨어 선택과 구성

필자가 설계한 환경은 크게 프로세싱 영역과 데이터 영역으로 나뉜다. 영역을 나눈 이유는 데이터를 처리하는 컴퓨팅 환경과 연산을 하는 컴퓨팅 환경의 특성이 다르기 때문에 효율적으로 역할을 나눈 것이다. 자동차 공장의 외장 조립부와 내장 조립부가 나뉜 것처럼 비슷한 처리를 하는 컴퓨팅 자원을 그룹으로 묶으면 해당 작업에 특화된 구성이 가능하므로 효율이 올라간다.

필자의 하드웨어 선택도 프로세싱 영역과 데이터 영역으로 나뉜다.

우선 프로세싱 영역에서 고민한 사항은 다음과 같다.
1. 저전력: 전기를 적게 먹을수록 불필요한 전기 생산도 없을 것이고 환경에도 좋다.
2. 쉽게 다룰 수 있다: 소프트웨어 선택의 폭이 넓고 쉽게 수정할 수 있는 요소다.
3. 가격이 저렴하다: 여러 대를 운영하므로 소유비용이 저렴해야 한다.
4. 쉽게 늘릴 수 있다: 쉽게 겹겹이 쌓을 수 있고 각종 케이블을 쉽게 연결할 수 있어야한다.

집에 있던 아톰(ATOM) 기반의 울트라북을 우선 고민했다. LCD 케이블을 제거하면 14 W 정도면 돌릴 수 있기 때문이다. IT 제품에서 스크린은 전체 전력의 30% 이상을 차지한다. 따라서 디스플레이의 전원공급을 끊으면 전력을 더 적게 사용한다. x86 기반이라서 소프트웨어의 선택 폭도 넓다. x86은 우리가 일반적으로 쓰는 컴퓨터를 말한다. 문제는 동일한 제품을 여러 개 구입해서 가용성을 늘리기 어렵다는 것이다. 또 여러 개를 원하는 시기에 중고로 구매하기도 어렵다.

그러던 중 떠오른 것이 마이크로프로세서다. 대표적으로는 라즈베리 파이(Raspberry Pi)와 같은 제품이 있다.

이런 오픈 하드웨어를 안 쓰더라도 우리는 이미 많은 마이크로프로세서를 사용하고 있다. 인터넷에 연결되는 기기들은 대부분 마이크로프로세서를 탑재하고 있다. 라즈베리 파이 B+를 사용 하다가 무인자동차의 실시간 처리가 안돼 빠른 마이크로프로세서를 찾다가 작년 6월에 선택한 제품이다.
주요 스펙을 보면, 전기는 라즈베리파이 B+에 비해 4배를 사용하나 연산속도는 16배 정도 빠르다. 내장 메모리도 2G나 된다. 처리해야할 일을 한꺼번에 많이 가져와서 계속 계산을 할 수 있으므로 내장 메모리의 크기는 중요하다. 왜냐면 메모리의 속도에 비해 네트워크나 디스크를 읽는 속도가 느리기 때문이다.

Odroid U3
· 1.7 GHz Exynos4412 Prime
Cortex-A9 Quad-core 프로세서
· 2Gbyte LPDDR2 880 Mega Data Rate
· XUbuntu 13.10 또는 Android 4.x OS
· 크기: 83×48 mm
· 무게: 히트싱크 포함하여 48g
·5V/2A input

옆에 ESC(전자속도제어장치)가 활활탈 때도 위험 신호와 위치 정보를 충실히 전송해준 믿음도 컸다. 산업용 프로세서들은 오픈 하드웨어에 비해 더 가혹한 조건(저온과 고온)에서 운영되도록 설계된다. 하지만 나름 위험한 상황에서 안정적으로 프로세싱을 한 오픈 하드웨어다. ARM 프로세서는 인텔 계열의 저전력 프로세서와 비교하더라도 소모전력 당 연산 능력이 월등하다.

모바일 시대에 ARM이 주목받는 이유가 바로 이것이다. 필자는 모바일뿐만 아니라 클라우드 시대에도 중요한 프로세서가 될 것이라고 생각한다. 저전력에 컴퓨팅 자원을 잘게 쪼갤수록 효율이 높아지기 때문이다. 이 프로세서를 병렬로 연결해서 분산처리하고 하나씩 늘려서 가용성을 확보한다. 다음은 데이터 영역에 대한 고민이다.

우선 NAS(Network-Attached Storage) 구입을 고려했다. 디스크를 4대까지 연결할 수 있는 NAS는 50만 원에서 100만 원 사이로 매우 고가다. 스토리지의 프로세서를 늘리는 것도 필요하지만 일정 프로세서 한계까지는 디스크 용량의 확장도 필요하다. NAS에는 여러 앱을 통해 비디오 스트리밍도 되고 웹하드도 되는 서비스를 제공한다.

필자에게는 이런 앱보다 디스크를 늘릴수 있는 기구와 우분투(Ubuntu)를 설치할 수 있는 프로세서가 필요했다. 대부분의 NAS 운영체제는 펌웨어와 더불어 고립된 환경을 가지고 있기 때문에 마음대로 설정을 바꾸거나 소프트웨어를 설치하기 어렵다. 따라서 NAS들은 클라우드의 스토리지용으로는 부적합하다. 고민하던 중 눈에 들어온 것이 HP의 마이크로서버 시리즈다.

N54L 마이크로서버는 3.5인치 디스크를 4대 꼽을 수 있고 메모리를 8G까지 확장할 수 있다. NAS 제품들은 메모리가 2G 넘게 메모리를 확장할 수 있는 제품이 드물다. Elasticsearch와 같은 NoSQL을 사용하기 위해 최소 4G의 메모리를 달수 있는 제품이 필요했다.

또한 기본적으로 서버의 특성도 필요했다. 전원 스위치는 켤 수만 있고(실수로 전원 스위치를 눌러서 꺼지는 것을 막기 위한 기능), 케이스 안의 USB 슬롯(실수로 운영체제를 담당하는 USB 메모리를 제거해서 운영이 멈추는 상황을 막음) 등

N54L MicroServer
· AMD Turion II Processor Model Neo N54L (2.20 GHz, 15W, 2MB)
· 2×1MB Level 2 cache
· PC3-10600E unbuffered DDR3 ECC operating at 800MHz
· Embedded NC107i PCI Express Gigabit Ethernet Server Adapter
· 4×3.5" SATA

허브는 IPTime의 H5008을 사용했다.

Odroid U3가 기가이더넷을 지원하지 못하지만 필자의 데스크톱과 데이터 스토리지는 기가 인터넷을 지원하고 8개 이상의 포트가 필요했다. 내부망만 기가비트로 운영하더라도 WAN을 담당하는 인터넷 공유기도 기가비트를 사용해야 한다. 속도에 영향을 미친다. 케이블도 Cat.6 이상을 써야 한다. LAN 케이블에는 Cat.5, Cat.6이라는 글자가 쓰여 있다. Cat.5 100 Mbps, Cat.6는 기가용이다.

필자의 데스크톱 PC도 하나의 컴퓨팅 자원으로, 사용하지 않을 경우 WOL(Wake On Lan)으로 깨워서 컴퓨팅 자원으로 활용한다. 컴퓨팅 자원을 사용하지 않으면 전기료를 줄일 수 있으나 필요한 경우에 사용하지 않으면 당연히 기회비용이 발생하기 때문에 필요한 컴퓨팅 자원은 모두 클라우드로 통합해야 한다.

가용성 확보하기

아마존과 MS의 Azure, 구글 앱 엔진(Google App engine)과 같은 IaaS를 사용하게 되면 기본적으로 부하에 대한 모니터링과 가장 기초적인 로드 밸런싱 서비스를 받을 수 있다. AWS와 같은 IaaS 기반 없이 스스로 클라우드를 만들기 위해서는 다음과 같은 추가적인 고려가 필요했다.

1. 로드밸런스/잡 스케줄러
2. 인스턴스 증가

로드밸런스의 경우, AWS의 단순한 로드밸런스(부하에 따른 단순 분배) 만으로는 어차피 한계가 있어서 재구축이 필요했고, 인스턴스 증가는 좀 뼈아픈 문제였다. 인스턴스의 이미지만 형상 관리를 하면 부하에 따라서 그 이미지를 기반하여 가용성을 조절해주기 때문이다. 클라우드는 쉽게 가용성을 확보해야하기 때문에, 이 부분의 고민이 많았다.

필자가 선택한 방법은 메모리에 운영체제를 포함한 이미지를 형상 관리하고 새로운 인스턴스가 필요하면 이 이미지를 복사해 USB 슬롯이나 메모리카드 슬롯에 끼워주는 방법이다. 하드웨어만 있으면 이 방법을 통해 1분이면 새로운 컴퓨팅 자원이 늘어난다. 이러한 쉽고 빠른 컴퓨팅 자원의 증가 방법이 중요한 이유는 우리가 새로 컴퓨터를 조립하고 소프트웨어를 설치하는 시간을 생각해보면 쉽게 알 수 있다. 50년에 한 대 정도 새로 컴퓨터를 장만하여 소프트웨어를 설치하는 시간은 매우 작은 비용이지만, 한 달에 한 번이라고 가정하면 그 비용이 꽤 큰 비용이 된다. 또한 절차가 복잡하게 되면 실수하게 된다.

슬롯에 꽂고 전원과 네트워크만 연결하면 컴퓨팅 자원이 늘어난다. 전원이 인가되어 최초 부팅 시에 로드밸런스에게 자신의 존재를 알린다. 이 내용은 소프트웨어 편에서 다루겠다.

그림 15에서, 1번부터 3번까지의 컴퓨팅 자원은 평소 꺼져 있다가 부하에 따라서 이 순서대로 전원을 공급하고 컴퓨팅 자원에 추가된다. 1번부터 3번까지의 컴퓨팅 자원들은 평소에는 할 일이 없기 때문에 비용을 줄이고 일이 생기면 일을 한다.

인프라 소프트웨어의 설치
이번 클라우드 구축의 목적은 IoT 환경외에 모바일 오피스도 목적이 있다. 전세계 어디든 네트워크가 되는 곳에서 자유롭게 일할 수 있는 환경을 구축하는 것이다.

아래와 같은 순서로 설치했다. 이 소프트웨어를 전부 데이터 스토리지(N54L)에 설치했다. 웹 인터페이스를 제공하는 소프트웨어는 서브 도메인으로 바인딩 했다.

1. SSH(Secure Shell)
2. Transmission
3. Samba
4. GitLab
5. Elasticsearch
6. PostgreSQL

SSH

시큐어 원격 쉘과 SFTP를 사용하기 위해 필요하다. FTPbox와 같은 소프트웨어와 연결하여 자신만의 빠른 드롭박스를 운영할 수 있다.

Transmission
리눅스용 토렌트 프로그램이다. 네트워크가 불안정한 지역에 일정 크기 이상의 바이너리를 배포할 때 토렌트 만큼 적절한 수단이 없다. 웹 인터페이스를 이용해서 어디서든지 제어가 가능하다.

Samba
컴퓨팅 인스턴스를 쉽게 늘리기 위해서는 로컬 데이터를 만들지 않는 구조로 가야한다. 따라서 인스턴스가 만들어내는 SQL, NoSQL 외에 일반 파일 데이터를 읽고 쓸 인터페이스가 필요하다. Samba는 네트워크 디스크를 제공한다.

GitLab
필자는 이슈 트래킹과 형상관리로 레드마인(Redmine)과 SVN(Subversion)을 써왔다. 이참에 한번 확 바꿨다.
GitLab의 이슈 트래커에 타임 트랙킹이 안 되는 점을 제외하고는 만족한다.
코드에 코멘트를 남길 수 있어서 코드리뷰용으로 매우 좋을 것 같다.

Elasticsearch
NoSQL로 몽고DB(MongoDB)를 써왔는데, 한 달 전쯤 짧은 시간 안에 2G정도의 데이터를 넣으니 제대로 안 들어가는 현상을 발견했다. 비슷한 인터페이스의 Elasticsearch로 NoSQL 솔루션을 변경했다. 센서 데이터의 기록용으로 사용한다.

PostgreSQ
필자의 이력 중 절반은 MySQL을 썼다. 나머지는 PostgreSQL을 사용했는데 클러스터링에 매우 강하고 MySQL처럼 DB Connector가 GPL 이슈가 없어서 DB Connector를 같이 배포해도 되기때문에 계속 PostgreSQL를 사용하고 있다. 분석 자료의 기록용으로 사용한다.

전력소모

이번 구축의 목표가 친환경이기 때문에 전력소모도 매우 중요했다. 전력에 대한 걱정에 앞서 개인적으로 사용할 전원 아울렛과 클라우드가 사용할 아웃렛을 분리했다. 거미줄처럼 복잡하게 전기를 연결해 쓰는 것은 위험하기 때문이다.

그림 16에서, 위 아웃렛은 클라우드가 사용하고 아래 아웃렛은 개인적으로 쓰는 PC, 모니터, 가습기, 오디오, 충전기, 노트북 어댑터 등에 사용한다.

최소 전력소모 시나리오는 허브, 스토리지 한 대, 마이크로프로세서 2대가 작동할 때이다. 최대 전력소모 시나리오는 모든 컴퓨팅 자원이 작동할 때이다. 소모 전류의 측정은 가정용 측정기인 SJPM-C16을 사용했다.

물론 테스터가 있다면 테스터를 이용해서 전류와 전압을 곱해도 된다. 최소와 최대 전류 사용량은 표 1과 같다.

전기 소모 대 처리량은 소프트웨어편에서 다루겠다. 데스크톱의 사용 전력은 90 W이기 때문에 이번에 구성한 친환경 클라우드의 2배에 해당하는 전력을 소모한다. 따라서 필자가 데스크톱 PC로 컴퓨팅을 지속적으로 했다면 더낮은 처리량에 전력을 2배 사용하게 된다. 안 쓰는 PC를 서버로 재활용하는 방법은 쓰레기를 줄일 수 있지만 전류소모량 측면에서는 안 좋은 선택이다.

우리가 전기요금을 줄일 수 있는 방법은 저전력 제품을 구매하고 안 쓸 때는 코드를 뽑는 것이다. Odroid U3는 WOL(네트워크 신호로 원격에서 컴퓨터를 켤 수 있다) 기능이 없기 때문에 물리적인 스위치로 전원 제어가 필요했다. 부하가 발생하면 로드밸런스가 이스위치를 이용해서 마이크로프로세서에 전원을 공급한다.

반대로 부하가 줄어들면 전원을 차단한다. 쉽게 말해 이 모듈을 이용해서 컴퓨터의 전기 플러그를 꼽거나 뺀다. 이 방법이 대기전력도 없고 좋지만, 메인 파워(벽에 있는 콘센트에서 나오는 전기)를 스위칭 하는 것은 대단히 위험한 방법이다. 깔끔하게 하우징을 못한 상태에서 습기나 분진이 들어가면 화재가 발생할 수 있기 때문이다. 필자가 권하는 방법은 메인 파워 부분의 스위치가 아니라 어댑터 이후의 스위칭이다.

여러 디스크의 설치도 추가 소비전력을 필요로 한다. 가용성 확보를 위해 3TB 디스크 4대를 준비했으나 사용하지 않는 디스크는 전력소모만 늘리므로 스토리지에 하나만 꼽은 상태이다. 사용량의 70%를 넘길 때마다 하나씩 설치할 예정이다. PC에 안 쓰는 장치들을 뽑아두면 전력소모를 줄일 수 있다. 대표적으로 CD-ROM 드라이브가 있다.

파워로부터 전원 케이블만 빼놓아도 소모전력을 줄일 수 있다.