casaubon

---

FEBRUARY 29, 2008

Azul Means (Big) Blue: There's a new kind of mainframe coming and it isn't from IBM.

By Robert X. Cringely
bob@cringely.com

작금의 PR 만능시대에 인텔 중역들이 마이크로소프트 중역들을 닦달했다는 소문이 있다. 그런데 이번 주, IBM이 신세대 메인프레임 컴퓨터를 발표하였다. IBM 시스템 Z10은 더 작고, 더 빠르며, 더 차갑고, 더 많은 메모리와 용량을 갖고 있다. 사실 모두가 "더(more)"이다. 그런데 이 모든 것이 Z9 머신 본체보다 작은 본체에 다 들어간다. 전통적인 메인프레임보다 초대형 가상화 서버로 더 잘 알려진 Z10의 유일한 문제점은 그 좋다는 퍼포먼스도 무어의 법칙을 쉽사리 따른다는 데에 있다. 앞으로도 계속 퍼포먼스는 빨라질 것이다. 당장 메인프레임 혁명이 일어나고 있긴 한데, 그 주역은 IBM 메인프레임이 아니다. 진짜 혁명가는 리눅스 박스로 이뤄지고 있으며, 그 주체는 Azul Systems이다.

물론 IBM이 새 메인프레임을 발표했다는 사실 자체는 매우 기쁜 소식이다. 85% 더 빨라지고, 85% 더 작아졌으며, 약간 더 저렴해진 Z10은 Z9가 나온지 3년 뒤 나왔고, 무어의 법칙을 보면, 앞으로 나올 자매형 메인프레임이 85%가 아닌, 200% 더 빨라질 것이다. 하지만 별다른 입증 없이, Z10이 인텔 싱글 프로세서 서버 1500대에 맞먹는다면서도, IBM은 무어의 법칙을 말하고 있지 않다.

그렇다면 그 답을 만들어낸 질문은 무엇일까? 계산을 하긴 했나? 1500대의 서버와 맞먹는다고 하면, 그 가격은 2000만 달러에 근접한다. 서버 한 대당 13,333 달러 정도이다. 비용 절감이랄 수 없다. 데이터 센터 공간은 물론 전력 사용량, (어쩌면) 행정비용을 고려한다손 치더라도, 이미 Z9를 쓰고 있고, Z9를 교체할 작정이 아닌 한, Z10은 별 매력이 없다.

따라서 Z10이고 Z9이고, 결국은 모두 메인프레임이라는 얘기다. 물론 예전과 같이 메인프레임을 구매하는 고객이라면 위안이 될 만한 얘기임이 확실하다 하겠다. 하지만 IBM 벤치마크 자체도 좀 의심스럽다.

IBM은 자사 벤치마크를 완전히 설명한 적이 없으며, IBM 메인프레임의 3자 벤치마크 테스트 또한 허용한 바 없다. 따라서 Z10의 성능에 몇 대의 인텔 서버를 갖다 붙이면 될지 정확히 아는 이는 없다.

필자와 같은 칼럼니스트들은 이미 몇 년 전부터 IBM 메인프레임이 한 대의 머신 안에서 4만 대 이상의 SUSE 리눅스 가상머신을 돌린다고 쓴 바 있다. 기억하시는가? 필자는 4만 대의 직렬형 리눅스 가상머신 중 몇 대가 동시에 둠(Doom)을 돌리고 있었는지 궁금해 했었다.

그러나 둠보다 훨씬 더 흥미로운 의문이 있다. 필자는 리눅스가 메인프레인-급 운영체제가 될 만하다고 본다. 그 능력도 엄청나게 개선됐다. 일단은 오픈소스라는 기반덕분이긴 하지만, 여기에 우리가 기뻐하며 구매는 하지만, 거의 쓰지도 않는 멀티-코어 프로세서를 효율적으로 쓸 다중 쓰레드 기술이 가미되었기 때문이기도 하다.

몇 주일 전, 필자는 한 칼럼에서, 반도체 전압 누출에 대해 쓴 적이 있다. 온갖 멀티-코어는 결국, CPU 발열량을 줄이기 위해 클럭 주파수를 낮추면서, 퍼포먼스는 늘리기 위해 등장했다. 벤치마크 프로그램과는 달리, 데스크톱 애플리케이션 대부분은 여전히 단일 프로세서 코어 상에서 돌아가며, 프로세서가 더 있다고 해서 딱히 이 프로세서를 효율적으로 활용하진 않는다.

그런데 이 상황이 바뀌는 중이다. 가령, 다중 프로그램 쓰레드에 최악이라 평가받던 OS가 리눅스였다. (대부분의 상황에서 주먹구구식일 정도로 안 좋았다.) 하지만 그 때는 리눅스 커널이 2.4였다. 현재 커널은 2.6으로 올라갔고, 여기에 NPTL(Native POSIX Thread Library)이 덧붙여졌다. 이 NPTL이 상황을 전부 바꾸고 있다.

NPTL은 그동안 레드핫 리눅스 기업용 버전에 있었지만, 이제는 일반용으로도 나왔다. NPTL이 있으면, 단일 머신 상에서 수 십만 개의 쓰레드가 가능해진다. 데이터 구조용으로 쓰레드를 계산했을 때 문제가 생기곤 했었는데(hash 테이블 업데이트에 1000 개의 쓰레드를 생각해 보시라), 이제는 다른 쓰레드를 기다려야 할 필요가 없는 데이터 구조를 갖게 되었다. 사실, 업데이트를 하기 전에 쓰레드 교체가 되면, 다음 쓰레드가 이를 검출하고, 자기 임무를 수행하게 된다. 따라서 애플리케이션이 이를 활용할 준비가 된다면, 퍼포먼스는 극대화된다.

한 컴퓨터 오타쿠 친구가 이런 말을 한 적이 있다. "내 이메일 애플리케이션이 4-코어 옵테론(Opteron) 서버에서 돌아가는데, 동시 접속이 4000건이 넘더라구. 4천 개의 개별 쓰레드가 CPU 네 개를 갖고 경쟁하는 것이지.("쓰레드"는 여기서 가벼운 프로세스를 가리켜.) 그런데 모니터링을 해 보면, CPU는 항상 5% 이하로만 돌아가. 그럼 계속 시간 잡아 먹는 거지."

메인프레임의 정의를 다시 내려버린 Azul 시스템즈만큼은 아니다. Azul은 다른 어느 회사보다 쓰레드 관리와 프로세스를 동시에 처리하는 모델을 확실히 세워 놓았다고 볼 수 있다. Azul은 멀티-코어 서버 기기를 만드는데, 14u Azul 박스를 당장 구매할 수 있다. 여기에는 프로세서 768개와 768GB의 메모리가 들어가 있다. 프로세서는 아직까지 Azul 고유 디자인이다.

그렇다면 이 서버 기기는 무엇인가? Azul의 경우를 보면, 이 서버는 자바 코-프로세서를 돌린다. 여러 가지 다른 머신상에서 돌아가는 각기 다른 자바 애플리케이션을 연산시키는 프로세서이다.

자바는 그동안 여러 대의 머신이나 여러 개의 프로세서상에서 가상화를 시킬 수 있는, 대규모 애플리케이션 작성용으로 적합한 언어였다. 그러나 자바가 유연하고 우아할수록, 자바의 속도는 빠르지 못했다.

자바의 자동화된 가비지 콜렉션 루틴때문에 프로세서 지연 현상이 생기는데, 이는 자바 최대의 문제였다. Azul은 가비지 콜렉션을 소프트웨어가 아닌 하드웨어로 해결한다. 즉, 가비지가 일으키는 속도 저하를 줄이면서, 퍼포먼스를 올린 것이다.

컴퓨터 언어 오타쿠들이야 자바 퍼포먼스와 C나 C++ 갖고 흉보는 데에 익숙해져 있다. 물론 누군가(라고 쓰고 "Sun"이라 읽는다)는 자바가 C++만큼 빠르다고 주장할지 모르겠다. 간헐적으로 일어나는 가비지 콜렉션때문에 일어나는 지연 현상만 아니라면 그럴 수도 있다. 그런데 이제 Azul은 하드웨어로 그 문제를 해결할뿐 아니라, 멀티-코어 자바 가상머신을 직접 만들어서 실제로 속도를 C++만큼 올렸다.

그런데 말이다. Azul 아키텍쳐를 자바로 국한시켜야 할 이유가 없다. C++로 확장시키지 못할 이유도 없다.

필자가 보기에 제일 흥미로운 부분은 다름 아닌 메인프레임이다. IBM에서 나온 Z10은 여러 가지 다양한 운영체제를 돌리는 작은 서버 1500대만큼이라고 한다. 1500대라고 설명하기는 괜찮겠지만, 유연함이 특별히 있진 않다. Azul의 기기는 가상화된 기기를 별도의 하드웨어 기기로 대체하는 식이 아니다. 오히려 Azul은 필요한 전체 서버의 수를 줄이면서, 자바 프로세싱이 필요한 기존 서버를 돕는다.

Azul에 따르면, 서버를 Azul로 교체하는 것이 아니라 10대1의 비율로 줄이는 것이다. 따라서 블레이드 서버 10대와 Azul 한 대가 블레이드 서버 100대보다 (Azul에 따르면 5배에서 50배까지) 빨리 처리한다. 게다가 Azul 박스는 싸지 않다. CPU 코어당 천 달러에 육박한다. 그러나 블레이드 서버 가격과 비교할 만하며, 유연하지 않은 메인프레임 값에 비하면 싸구려다.

그리고 유연성이 정말 중요하다. Azul은 투명하게, 순간적으로 처리를 돕는다. Azul 기기로부터의 도움을 얻기 위해 자바 애플리케이션을 재작성할 필요도 없다. 네트워크 상에 나타나면, 어떠한 자바 애플리케이션도 도울 수 있다. 쓸 수 있는 코어가 몇 개인가에 따라 돕는 양이 정해질 뿐이다.

이 과정이 데이터 센터에서 어떻게 일어나는지 상상해 보자. 서버들로부터 임무를 부여받는 전통적인 메인프레임과는 달리, Azul 박스는 필요한 모든 서버를 돕기에, 천 대마다 커다란 Azul 박스 한 대씩은 필요할 것이다. 그러나 오버헤드(overhead)를 다이나믹하게 공유하기 때문에 전체 서버 숫자는 줄어든다.

간단히 말해서, 보다 효율적인 컴퓨팅, 그것도 우리가 흔하게 보지 못하는 효율적인 컴퓨팅이다.

Appistry(필자가 Appistry에 대해 썼을 때, 원래 이름은 쯔나미였다. 하지만 불행히도 당시 진짜 쯔나미가 닥쳤다. 불운의 마케팅이 아닐 수 없겠다.)와 같은 경쟁 아키텍쳐도 있다. 하지만 Appistry는 수 백, 수 천 대의 컴퓨터에 일어나는 연산로드(compute load)를 벌여놓는데, Azul은 필요할 때 수 백, 수 천 대의 서버나 서버 이미지를 돕는다.

Bear Stearns가 Azul로 백오피스를 돌리며, Azul로 웹사이트 속도를 올리는 고객도 많다. 대기업이 뭘하는지에 대해 신경쓰는 타입이 아니라서인지, 필자는 Azul식 접근과 전용, 혹은 대여 서버의 데이터센터 활용이 특히 더 흥미롭다. Azul 박스가 네트워크 상에 설치되어 있다면, 필자의 자그마한 애플리케이션은 신비스럽게도 50배 더 빠르게 돌아갈 것 아니겠는가.

Cool.

I, Cringely . The Pulpit . Azul Means (Big) Blue | PBS

__________________
FAQ