기술 구조를 언급할 때, 최근 IT 업계의 가장 큰 화두인 클라우드를 언급하지 않을 수 없다. 클라우드에 있어 가상화는 반드시 필요한 기능이며, 가상화의 전제 조건은 자원의 공유에 있다. 리눅스원 플랫폼은 ‘Shared All’ 사상에서 출발한다. 서버 아키텍처가 CPU, Memory 및 I/O에 대한 자원 공유 기반에서 설계되었고, 이러한 자원 공유를 통하여 가상화를 실현한다. 리눅스원의 가상화 기술은 40년전에 최초로 메모리 가상화를 적용한 DAT (Dynamic Address Translation, 프로세스의 가상 주소 공간 (Virtual Address Space)을 Real Memory에 맵핑하기 위한 기술)에서 출발하여 현존하는 범용 서버 중에서 가장 뛰어난 가상화 기능을 가지고 있다. 반면, 대부분의 분산 플랫폼은 ‘Shared Nothing’ 사상에서 출발을 하였고 이를 자원 공유환경으로 구현하기 위한 다양한 기술들이 최근에 대두되고 있다. 이러한 이유로 리눅스원은 내장 디스크를 가지고 있지 않다. 아마도 인프라 운영 경험이 많은 시스템 관리자라면, 내장 디스크가 가지고 있는 단점이 얼마나 비 효율적인지 이해할 것이라고 본다.
리눅스원의 1차 하이퍼바이저인 PR/SM (Processor Resource/System Manager)은 IBM POWER 서버가 유닉스 시장에서 선두를 달릴 수 있게 한 PowerVM의 모태가 된 기술로서, 리눅스원의 모든 서버 자원을 마이크로 레벨에서 처리한다. 다른 리눅스 서버의 하이퍼바이저와 달리 리눅스원의 2차 하이퍼바이저인 z/VM 또는 KVM이 성능적 저하 없이 운영될 수 있는 이유도 PR/SM이 하드웨어 레벨에서 모든 가상화된 서버 자원을 관리하기 때문이다.
프로세서 관점에서 보면, 리눅스원은 5.0 GHz (Emperor 기준)으로서 현존하는 범용 서버중 가장 빠른 Clock Speed를 가지고 있다. 2000년대 이후의 워크로드 특성을 보면, C 언어 및 Java, C++ 등의 오브젝트 기반의 언어가 주류를 이루고 있어 높은 수준의 Clock Speed를 요구한다. 아울러, Cache Size 역시 중요한 프로세서 설계 기술 중의 하나인데, 리눅스원은 L1 ~ L4까지의 대용량 Cache를 제공함으로써 Cache Missing을 최소화할 수 있다. 또한, 리눅스원의 프로세서 내부 (In-Chip)에는 데이터 암호화 및 압축을 위한 Co-Processor가 내장되어 있다. 특히, 데이터 암호화 프로세서 (CPACF, CP Assist for Cryptographic Function)는 고객정보암호화를 위한 암복호화 알고리즘을 내장 마이크로 코드를 통하여 수행할 수 있어 일반 코어의 성능 및 용량에 영향을 주지 않아 매우 효율적이다. CPACF를 사용하기 위한 C 및 Java Runtime Library 및 API가 제공된다.
확장성 부분에서는, 리눅스원 Emperor 기준으로, 단위 코어의 용량이 1,695 Mips이다. 이 용량이 어느 정도인지 가늠이 되지를 않는다면, 국내 굴지의 카드사가 2000년도 사용했던 전체 용량이 1,000 Mips가 안되었던 점과 비교한다면 이해가 쉬울 것이다. 따라서, 리눅스원은 다른 어떠한 분산 서버보다도 적은 수의 코어로 동일한 워크로드를 처리할 수 있다. 필자의 경험 및 IBM 고객 사례로 볼 때, DBMS 워크로드의 경우 하이엔드 유닉스 대비 약 3~4, x86 서버 기준으로 약 10~12배의 코어 수 절감이 가능하며, 이는 코어 기반의 상용 소프트웨어에 대한 라이센스 및 유지 보수 비용을 크게 절감할 수 있다. 아울러, 이러한 코어가 141개까지 단일 서버에 장착이 가능하며, 약 8,000개의 가상 서버를 안정적으로 수용하기 위하여 메모리는 10TB까지 확장이 가능하다. 따라서, 수직적 확장성 (Scale-Up) 및 수평적 확장성 (Scale-Out)을 동시에 지원함으로써 워크로드에 대한 제약 없이 탑재가 가능한 것이다.
I/O 관점에서 보면, 리눅스원은 I/O 전용 프로세서 (SAP, System Assist Processor)가 내부에 장착되어 있기 때문에, 다른 분산 플랫폼의 코어가 연산 및 I/O 처리를 모두 수행함으로써 발생하는 Context Switching 등의 오버헤드를 제거함으로써, 안정적인 성능 및 가상화 기술과 연동하여 높은 자원 활용률을 제공한다. 최근, 기존 분산 서버에서는 이러한 제약을 극복하기 어플라이언스 형태로 서버와 스토리지를 함께 일체형으로 제공하는 추세를 볼 수 있는데, 이것이 과연 리눅스 기반의 오픈 테크놀로지를 통하여 업체 종속성을 탈피하려 하는 현 시점의 트렌드에 부합하는 것인지는 의문이다. 리눅스원은 SVC (SAN Volume Controller)를 지원하는 스토리지라면 어떠한 분산 환경에서의 스토리지도 지원한다. 즉, 고객에게 고객의 환경 및 요건에 맞는 최상의 인프라 구조를 구성할 수 있도록 모든 문을 오픈하고 있는 것이다.
리눅스원은 네트워크, 스토리지 I/O, 외장형 암호화 카드 등 모든 어댑터를 단일 채널서브시스템 (CSS, Channel Sub System)에 의하여 관리함으로써, 리눅스 커널에 존재하는 I/O 드라이버의 크기를 최소화한다. I/O 드라이버의 크기가 작기 때문에 다른 리눅스 서버보다 Memory Resident Module의 크기가 작아지게 되어 메모리 사용량이 감소하게 된다. 아울러, 리눅스 배포자 관점에서 보면 I/O 드라이버 관련 문제 분석 및 해결이 용이하게 된다.
데이터 센터 운영 관점에서 데이터센터 비용의 효율성을 고려하지 않을 수 없다. 데이터 센터 비용은 크게 상면비용, 전력비용, 공조비용 등으로 나누어 볼 수 있는데, 위에서 언급한 바와 같이 리눅스원의 단일 코어 성능과 확장성으로 인한 통합 능력은 매우 높다 따라서 고객의 상면 비용을 크게 줄일 수 있으며, 기본적으로 리눅스원은 저전력 구조로 설계되어 있다. 따라서 발열량도 매우 적다. 리눅스원은 서버 구성에 따른 예상 전력 소비량을 추정할 수 있는 툴을 제공한다.
마지막으로 플랫폼 기술 구조에서 반드시 언급해야 할 부분은 이러한 기술 요소들이 균형 있게 설계되어야 한다는 점이다. 리눅스원은 2000년 최초로 메인프레임 기술 위에서 리눅스를 탑재한 이후, x86의 리눅스와 거의 같은 역사를 가지고 발전해 오면서, 고객의 핵심 업무를 수용해 오고 있다. 이것이 가능한 이유는, 첫째 리눅스원 플랫폼의 설계 사상은 시장의 변화와 함께 진화해 왔고, 둘째, 반세기가 넘는 시간 속에서 각각의 플랫폼 요소 기술이 균형 있게 설계되었으며, 셋째, 리눅스 커뮤니티와의 끊임 없는 협업 속에서 범용 서버로서의 통합적 검증 테스트를 수행한다는 점이다. 단일 기술 요소를 통하여 특정 영역에 특화된 서버를 만드는 것은 어려운 일이 아니다. 예를 들면, 단순한 워크로드의 성능에 초점을 맞추어 프로세서 성능 만을 높이기 위한 기술은 그리 어렵지 않다. 그러나, 프로세서 성능도 향상시키면서 대용량의 Cache 및 암복호화 프로세서를 함께 내장하고 동시에 I/O 자원의 공유의 균형 있는 설계 및 구현은 상당히 어렵다. 위에서 살펴본 바와 같이 리눅스원은 범용서버로서 이러한 균형된 설계를 꾸준히 이어왔고 이를 고객으로부터 검증 받은 엔터프라이즈 컴퓨팅을 위한 리눅스 전용서버이다.
기고자: 정승건 실장, 한국 IBM LinuxONE 테크니컬 팀 리더
