Sun Developer Network 공식 블로그

듀얼코어의 대중화가 빨라지고 있습니다. 듀얼코어 같은 CMP 시스템에서 개발자들이 알아야할 정보를 제공합니다.
Part 1 : SMP & 확장성 CMT와 SMP의 개념과 그 차이점에 대해서 설명하고 CMT의 확장성에 관해서 개발자들이 이해하기 쉽도록 간단한 법칙과 그래프를 제시합니다.
Part 2 : 개발영역에의 영향력 & 실험 CMT가 어플리케이션 개발자들에게 미칠 수 있는 영향과 그에 따른 확장성에 대한 고려사항을 설명하고 CMT가 기존 상용 소프트웨어들에게 미칠 수 있는 라이센스 문제에 관해 설명합니다.
Part 3 : OS 영역에의 영향력 & 병렬처리 OS의 확장성에 대해 FreeBSD, Solaris, Linux 등 각 OS를 통해 설명하고 병렬처리에 대한 새로운 개념을 제시합니다.

지난달에는 Part 1 : SMP & 확장성에 대해 다루었습니다.
이번달에는 Part 2 : 개발영역에의 영향력 & 실험에 대해 다룹니다.

3. 개발영역에의 영향력

어플리케이션 개발자들에 대한 CMP의 영향력

어플리케이션 개발자들에게 가장 큰 영향은 확장이 필수 요구 조건이라는데에 있습니다. 확장을 위한 최소한의 요건이 1~4개의 프로세서였던것이 오늘날 32개의 프로세서로 증가하였고, 가까운 미래에 또 다시 증가할 것으로 보입니다.

확장가능한 어플리케이션 만들기

확장가능한 코드를 만드는 것은 도전적인 일이지만, 퍼포먼스의 이득이 엄청납니다. 그림4(Part 1 참조)의 Oracle과 DB2 확장 곡선 커브 데이타는 확장성을 최적화한 퍼포먼스 튜닝이 어떠한 결과를 나타내는지 잘 보여줍니다. 암달(Amdahl)의 법칙에 따르면, 소프트웨어의 확장은 워크로드의 시리얼 프렉션이 적으면 적을수록 좋습니다. 많은 상업적인 시스템에서는 시스템상의 많은 동시 사용자들로부터 자연적으로 병렬처리 요구가 발생하게 됩니다.

확장하는데 첫번째로 발생하는 병목현상(이런 병목현상은 큰 시리얼 프렉션때문에 생김)은 일반적으로 공유하는 자원들간의 경합으로부터 발생합니다.

• 네트워크 또는 내부연결. 일정 부분의 시스템간의 내부연결에 대한 대역폭 제한 - 예를들어 웹서버(SQL 트래픽을 위한 1티어 또는 2티어 네트워크)나 SAN상에 네트워크가 진입하는 것.
• CPU/Memory. CPU의 큐 또는 리소스 부족의 결과로 생긴 페이지 폴트에 대한 대기.
• I/O 처리량. 디스크 I/O 오퍼레이션이나 대역폭의 충분치 않은 용량.

더 흥미로운 문제는 고유의 어플리케이션 디자인때문에 생깁니다. 이러한 문제들은 운영 환경이나 어플리케이션안의 직렬화(serial)된 코드들로부터 더욱 명백히 밝혀집니다. 그러한 문제들은 정말 뛰어난 검사 툴 없이는 식별해내기 힘듭니다. 왜냐하면 감지하기 쉬운 과부하가 걸린 리소스(CPU 외부에)가 나타나기 보다 로드가 증가 할 수록 아무일도 하지 않는 리소스의 양이 증가하는걸로 나타나기 때문입니다.

일반적인 예를 들어보겠습니다. 우리는 최근에 큰 온라인 전자상거래 시스템상에서 확장성에 대한 문제를 해결해 달라는 요청을 받았습니다. 어플리케이션은 수천명의 유저들이 웹어플리케이션에 지불 트렌젝션을 요청하는 것으로 구성되어 있었습니다. 로드가 점점 커질 수록 지연속도가 엄청나게 증가 하고 있었습니다. 또한 어플리케이션은 확장성이 좋은것으로 잘 알려진 큰 SMP시스템과 데이타베이스 상에서 운영되고 있었습니다. 그러나 시스템의 어느 부분에서 문제가 생겼는지 알려주는 명확한 표시가 없었습니다. 로드가 증가하자, CPU 리소스는 점점 아무것도 하지 않게 되었습니다. 결과적으로 모든 업데이트 작업의 중심에 하나의 테이블이 있었고, 그 테이블을 위한 락킹(locking) 전략은 워크로드에게 큰 시리얼 프렉션이 되었다는 것이 밝혀졌습니다. 유저 트랜잭션은 단순히 테이블이 업데이트 되는것을 기다리는 것이었습니다. 해결책은 동시에 여러개의 입력을 할 수 있도록 테이블을 없애는 것이었고, 그렇게 하자 시리얼 프랙션이 줄었으며 확장성은 증가하였습니다.

CMP에 있어, 우리는 하나의 어플리케이션 인스턴스안에서 확장성을 제한하는 요인이 무엇이 있을지에 대해 주의를 집중할 필요가 있습니다다. 왜냐하면 우리는 스레드를 대략 수십개 정도로 확장해야 하고, 가까운 미래에는 약 100개정도 까지 확장해야하기 때문입니다.

확장 가능한 로우 레벨 코드의 작성

데이타베이스, 어플리케이션 서버, 트랜잭션 시스템과 같은 많은 미들웨어 어플리케이션들을 확장하기 위해서는 특별한 주의가 요구됩니다. 일반적인 가이드라인으로 따를 만한 공통적인 기술들은 다음과 같습니다.

확장가능한 알고리즘. 많은 알고리즘은 문제의 크기가 증가함에따라 점점 덜 중요해지고 있습니다. 예를들어, 선형 리스트를 이용하여 어떤 객체를 서칭 하는 알고리즘은 리스트가 증가하는 양에 따라 필요한 CPU의 수를 대량 증가시킬것이고, 잠재적으로 초선형 비율에 이를 것입니다. 일반적인 경우, 최적화에 가장 중요한 것은 좋은 알고리즘을 고르는 것입니다.

락킹. 락킹 전략은 확장성에 중요한 영향력을 미칩니다. 동시 수행 작업이 늘어나면, 객체를 고정시키거나 특정 영역이 증가하는것을 막으려고 시도하는 스레드의 수가 증가하게됩니다. 그 결과로 복잡한 경쟁이 일면서 락(lock)은 더욱 “뜨거워” 집니다. 현대의 시스템에서 최적의 접근법은 가능한 객체마다 락을 거는 방법을 사용하는 절제된 락킹을 제공하는 것입니다. 이와는 다른 접근법도 존재하는데 약간의 메모리를 낭비함으로써 코드의 리더사이드(reader-side) 코드를 락-프리(lock-free)하게 만들거나, 라이터-사이드(writer-side) 코드에서의 작업을 증가시키는 방법이 있습니다.

캐시 라인 공유. 멀티프로세서와 CMP 시스템은 다른 파이프라인간의 데이터를 온전히 유지하기 위해 하드웨어 결합 알고리즘을 사용합니다. 이것은 확장성에 중대한 영향을 미칩니다. 예를들면, 하나의 프로세서가 메모리객체를 캐시 안에서 업데이트하려고 하면 그 캐시는 또한 다른 프로세서들로부터 접근되고있기 때문에 지연이 발생할수 있습니다. 또 캐시의 위치는 데이타의 버전이 하나만 존재한다는 것을 보증하는 캐시 결합 하드웨어 프로토콜 때문에 불명확해질 것입니다. CMP시스템에서는 여러개의 스레드가 일반적으로 하나의 첫번째-레벨 캐시에 접근하며, 그러므로 하나의 코어 안에서 접근하게될 데이타를 같은장소에 배치시키는 것이 적절할 수 있습니다.

워커 스레드의 풀. 동시작업에 대한 좋은 접근법은 워커스레드의 풀을 사용하는 것입니다. 일반적인 목적에서 멀티스레드 엔진은 작업 이벤트(work event)들을 모으도록 만드는데 쓰일수 있습니다. 이런 모델을 이용하면, 어플리케이션은 개별적인 일을 엔진에게 주고, 엔진이 그들을 병렬로 처리할 수 있도록 하게 해줍니다. 워커풀은 여러개의 프로세서나 하드웨어 스레드를 통하는 일이 균형을 이룰수 있도록 유연한 메커니즘을 제공합니다. OS는 기반이 되는 하드웨어 구조의 유형들에 맞도록 어플리케이션의 동시작업을 자동적으로 조정할수 있습니다.

메모리 할당. 메모리 할당자는 확장성을 증가시키는데 치명적인 약점을 노출합니다. 거의 모든 코드는 데이타 구조를 할당하고 해제하는것을 필요로 하며, 일반적으로 중앙 시스템이 제공하는 메모리 할당자(malloc)를 이용하합니다. 불행하게도, 확장성이 좋은 메모리 할당자는 소수밖에 존재하지 않습니다. 그 소수 안에는 오픈소스인 Hoard, Solaris10의 libumem slab 할당자(allocator), MicroQuill의 SmartHeap이 포함됩니다. “할당자가 다르면, 할당/해제를 요구할때 조금씩 다른 특성을 가진다” 같은 확장성의 다른 면에 관심을 가지는것은 매우 가치있는 일이 될것입니다.

4. 실험

확장성 실험 수행은 빠르게, 자주

시간이 흐르면서 한 어플리케이션으로부터 확장 이슈를 이끌어내는 가장 효과적인 방법은 확장에 대한 연구를 수행하는 것임을 알게 되었습니다. 최적화로 만들 수 있는 무한한 공간이 주어졌기때문에, 우선순위를 매기는 방법이 최고로 중요한 이슈입니다.

모델링 기술은 수학적으로 반응시간과 복잡한 시스템상에서 발생가능한 확장 병목현상에 대하여 반응시간을 예측할 수 있습니다. 모델링 기술은 트레이드-오프 분석을 만드는 것을 돕기위해 하드웨어의 퍼포먼스를 예측합니다. 하지만 모델링 소프트웨어는 소프트웨어 알고리즘, 코드 패스(code path), 시스템 서비스 지연과 같은 상세한 지식을 요구합니다. 모델을 만들고 모든 가정들을 명백하게 하는데 걸리는 시간은 종종 확장 테스트를 직접 하는것이 더 낳을것이라는 의문을 가지게 만듭니다.

잘 만들어진 확장 실험은 어플리케이션의 퍼포먼스 특징을 이해하는 열쇠가 되며, 적절히 관찰하면, 가장 중요한 이슈를 알기가 쉬워집니다. 확장성 예측과 분석은 개발 싸이클안에서 가능한 한 빨리 수행해야 합니다. 종종 현존하는 구조에 확장성을 향상시키는 것은 더욱 어렵습니다. 확장성을 어플리케이션 구조와 디자인의 한 부분으로서 고려해야 합니다.

확장성 실험에 포함되는 중요 아이템들 :

• 산출량 대 스레드/프로세스의 갯수. 산출량이 증가된 리소스의 양에 근접하게 비례하여 증가하였는가?
• 산출량 대 하나의 트랜잭션당 소비된 리소스(예, CPU,네트워크I/O,디스크I/O). 증가된 작업의 1유닛당 소비된 리소스의 양이 스케일이 증가한만큼 증가하였는가?
• 지연 대 산출량. 트랜잭션의 지연이 시스템 산출량의 증가만큼 증가하였는가? 어떤 시스템이 산출량 확장성을 정비례하게 나타내더라도 트랜잭션 반응 시간이 너무 길다면 실생활에 별로 유용하지 못할 가능성이 있다.
• 통계. 명령의 수와 사이클 두 부분 모두 코드패스길이를 측정하라.

관찰도구는 확장가능한 소프트웨어에 가장 큰 의미를 지닌다

효과적인 관찰도구는 어플리케이션의 확장성을 향상시키는데 가장 중요한 요소입니다. 확장 이슈의 가장 주가되는 원인을 빠르게 확인하는것이 무엇보다 중요하기 때문입니다. 확장 이슈를 찾아보는 가장 큰 목적은 시리얼화 되는 가장 큰 원인을 쉽고 정확하게 알아 내는데에 있습니다.

두개의 고전적인 리소스 기아 현상은 로드가 증가 함에 따라 리소스에 대한 요청들을 수행 하는 것과 로드가 증가함에 따라 idle 타임이 증가 하는 것에 의해 발생합니다. 이상적으로 확장이슈에 대하여 단순히 경쟁의 대상을 알리기보다 원인을 확인하는데 도움을 주어야 합니다. 이것은 어떠한 병목점이 있는지 확인할 수 있을 뿐만 아니라 리소스를 과도하게 쓰고 있는 코드도 확인 할 수 있을 것입니다. 많은 경우에 한번 원인이 확인되면, 올바른 최적화는 더욱 확실해 질것입니다.

다음과 같은것을 할 수 있는 도구를 고려하기 바랍니다 :

• 기다리는 시간의 가장 중요한 원인을 찾아내라. 무엇이 경쟁 리소스이며, 어떤것이 리소스를 사용하며 전반적인 퍼포먼스 경쟁에 어떻게 영향을 미치는가?
• 가장 빈번한 동기화 락을 확인하라. 객체를 락킹하는데 얼마나 많은 월 클락(wall clock)과 CPU 타임이 시리얼화 되며, 어느 코드가 믿을만 한가?
• 확장가능하지 않은 알고리즘을 확인하라. 어플리케이션의 스케일이 증가함에 따라 어떤 함수나 클래스가 더 많은 비용을 요구하는가?
• 문제가 있는 곳을 명백히 규정하라. 이것은 여러분이 즐겨 사용하는 어플리케이션 코드 안에서 발견되거나, 벤더가 공급한 미들웨어나 OS안에서 경쟁점을 잡아내는것에 의해서 발견될 것이다. 심지어는 그 경쟁점이 어떤 벤더 코드안에 있는경우도 있을수 있다. 또 그 코드는 어떻게 그 코드가 불려지는지에 영향을 받을 것이고, 더 상위레벨 코드의 최적화에 영향을 받을수도 있다.

CMT와 소프트웨어 라이센싱

하드웨어 구조가 확장하는 특성에 따른 또 다른 영향은 소프트웨어의 라이센싱입니다. 어플리케이션 개발자들은 소프트웨어의 가격을 결정하기위해 종종 시스템상의 프로세서 갯수를 사용합니다. 프로세서의 갯수는 우선적으로 하드웨어 플랫폼과 매우 밀접한 상관관계를 가지고 있다는 점에서 소프트웨어를 라이센싱하기 편한 측정방법이었습니다. 프로세서의 갯수로 라이센스 비용을 계산하는 방법은 소프트웨어 벤더가 소프트웨어에대하여 대략 비례하는 요금을 부과할 수 있게 해주기 때문입니다.

하지만 이것은 이제는 더 이상 사실이 아닙니다. 첫번째로 CMT 플랫폼에 기반한 OS는 하나의 칩안에 있는 모든 스레들들에 대하여 하나의 가상 프로세서를 보고하며, 이는 로우엔드 시스템에 있어 소프트웨어 라이센스 비용을 매우 비싸게 만듭니다. 소프트웨어 벤더들은 최근의 2코어 CMT 시스템에 먼저 적응하기 위해 고군분투하였지만, 일부는 한 코어당 하나의 라이센스를 적용하기로 했고, 다른 벤더들은 각각의 물리적인 칩(socket)에 대하여 라이센스를 따지기로 하였습니다. 코어마다 라이센스를 따지는 방법은 하드웨어 1달러당의 소프트웨어 라이센스 비용을 부당하게 증가시켰습니다.

단기간으로 볼때, OS벤더들은 시스템상의 코어의 갯수와 물리적인 프로세서의 갯수들을 보고하는 툴을 향상시키고 있습니다. 하지만 더 적절하고 공정한 해결방법에 대한 긴급한 요구가 발생하고 있습니다. 앞으로는 아마도 표준 벤치마크를 사용하는 산출량-기반의 라이센스 요금을 따르게 될 것입니다. 이것은 라이센스 요금을 플랫폼의 실제 프로세싱 파워에 따라 부과할 수 있도록 만들것입니다. 이러한 틀은 우선순위-기반에서의 자원 분할처럼, 프로세서를 서브프로세서로 분할하는 더 발전된 가상화 툴이 사용될 때 소프트웨어 라이센스를 확장시킬것입니다. 이러한 툴은 유틸리티 컴퓨팅이나 서버 고립화처럼 더욱 일상적인것이 되어가고 있으며 더욱 대중화 되고 있습니다. Os벤더들에게 있어서 기회는 어플리케이션에 의한 실제 사용에 기반하여 측정되고, 보고될수 있는 통일화된 계량법을 선택하는 것입니다.