솔라리스 커널 엔지니어 Andy Tucker 인터뷰

wooil의 이미지

날림 번역입니다. :? 정확한 내용은 원문을 참고하시기 바랍니다.

출처: http://www.osnews.com/story.php?news_id=3830

오늘은 솔라리스 커널 수석 엔지니어(Distinguished Engineer) Andy Tucker를 초대해 인터뷰하는 시간을 마련했다. 솔라리스의 내부 구조와 솔라리스 운영 환경의 경쟁력과 미래에 대해 이야기를 나눴다. 아홉 번째 질문은 썬 마이크로시스템즈의 엔지니어링 팀장(Director of Engineering) Robert O'Dea가 대답했다.

1. Why have the other commercial Unixes all pretty much bitten the dust? Is Solaris that much better, or is it just more important to Sun than HP-UX was to HP, AIX to IBM or IRIX to SGI?

Andy Tucker: 썬이 솔라리스의 성공을 위해 했던 가장 중요한 일은 단지 솔라리스에 전념했다는 것이었다고 생각합니다. 솔라리스 초창기는 대부분의 썬 고객이 SunOS 4.x를 운용하고 있었고 다른 유닉스 회사들은 NT를 바라보기 시작했던 때였습니다. 그래도 썬은 솔라리스에만 초첨을 맞추었습니다.

솔라리스 개발 초기에 썬이 몇 가지 큰 모험을 했다는 것을 알 겁니다. 가장 중요한 것 중 하나는 다중 쓰레딩과 다중 프로세싱 지원을 바닥부터 새로 설계했다는 것입니다. 이 작업은 솔라리스를 거대한 다중 프로세서로 쉽게 확장될 수 있게 했고, 점차 일반화해 가는 다중 쓰레드 워크로드를 처리할 수 있게 했습니다.

2. Do you think that the proprietary, company-supported development effort that you're a part in has any specific benefits over the Linux kernel's Linus-and-his-henchmen method?

Andy Tucker: 썬의 장점은 우리의 노력을 잘 통합하고 썬의 고객의 요구에 초첨을 맞출 수 있다는 것입니다. 리눅스에는 많은 좋은 점이 있습니다. 하지만 분산(decentralized) 개발 모델은 좀 다릅니다. 예를 들어 fair-share CPU 스케쥴러와 네트워크 QoS 지원이 필요한 사람이 있다고 하죠. 그 사람은 각각의 부분을 서로 다른 곳에서 가져와 커널에 집어넣고 그것들이 잘 맞물려 돌아가기를 바래야 합니다. 솔라리스는 이것들을 내장된 통합 구성요소로 갖고 있고 필요할 때 기능을 켜기만 하면 됩니다.

3. Technically-speaking, what do you think of the Linux kernel and the Mach kernel? Also, how FreeBSD 5.x compares to Solaris?

Andy Tucker: 모두 좋은 운영체제라고 생각합니다. Mach는 새로운 지평을 열었습니다. 널리 사용된 첫 번째 마이크로커널 OS였고 몇몇 기본 개념(예: 프로세서 셋)은 솔라리스에도 도입됐습니다. 리눅스는 넓은 개발자 층을 보유하고 있습니다. 결과적으로 거대한 활동과 에너지가 있죠. FreeBSD(와 다른 *BSD)는 BSD 전통의 계승자이고 흥미 있는 많은 아이디어의 근원입니다.

하나하나 비교하고 싶지는 않습니다. OS 개발은 서로 협력하는 작업이라고 생각하기 때문입니다. 우리 모두는 (OS를) 예술의 경지까지 향상시키고 우리의 사용자의 삶을 더 쉽게 만들기 위해 일합니다. 오픈 소스 운영체제는 때때로 새롭고 흥미진진한 아이디어의 근원입니다. 오픈 소스 운영체제 개발자들이 솔라리스를 비슷하게 봐주기를 바랍니다.

4. Solaris has some very complex algorithms. STREAMS, page coloring, and multi-level scheduling are all more complex than what is usually implemented in UNIX kernels. In retrospect, which Solaris features have really paid off, despite their complexity, and which ones have not?

Andy Tucker: 대부분의 현대 운영체제는 페이지 컬러링, 다중 레벨 스케쥴링 알고리듬을 포함합니다. 솔라리스는 이 점에 있어서 매우 독특합니다. 대부분의 경우 우리가 했던 눈에 띄는 작업들은 성과를 거두었습니다. 고객의 요구를 맞추다 보면 복잡함이 필요하기도 합니다. 만약 좀더 간단하고 좋은 방법을 찾는다면 기꺼이 재작성할 수도 있을 것입니다.

한편으로는 성공하지 못한 기능도 있습니다. NIS+가 그 예입니다. 그리고 우리가 잠재적인 기술이라고 생각했던 것들이 실수였음이 드러난 경우도 있습니다. 예를 들면 2-레벨 쓰레드 스케쥴링 모델이 있습니다. 이 모델은 쓰레드 스케쥴링이 사용자 레벨과 커널 양쪽 모두에서 일어납니다. 이 접근 방식은 쓰레드 생성과 컨텍스트 전환 시간(context swith time)의 관점에서 이론적인 장점이 있었지만 너무나 복잡한 것으로 밝혀졌습니다. 특히 전통적인 유닉스 프로세스 시맨틱스(semantics)(예: 시그널)를 다룰 때 그랬습니다. 솔라리스 8에서는 커널 기반 스케쥴링에만 의존하는 쓰레드 라이브러리의 '대체' 버전을 만들었습니다. 이 라이브러리는 간단하고 유지하기 쉬울 뿐만 아니라 거의 대부분의 경우에 더 빨랐습니다. 특히 우리에게 매우 중요한 자바 코드를 빠르게 해주었습니다. 솔라리스 9(와 이후 버전) 단일-레벨 라이브러리로 전환할 계획입니다.

5. What do you think about the Cathedral vs Bazaar idea when applied to OS kernels, where the programming model is rather different than than of regular application programs?

Andy Tucker: 어떤 면에서 보면 성당과 시장의 구분은 조금 인위적입니다. 다른 OS 회사는 어떤지 잘 모르겠습니다만 썬에서는 수백명의 엔지니어가 운영체제의 각 부분을 만들고 있습니다. 이들 중 많은 사람이 실제로 솔라리스 엔지니어링 팀에서 일하는 것은 아닙니다. 서로 다른 하드웨어 플랫폼, 저장 장치, 연구소, 솔라리스를 다루는 다른 제품을 위해 일합니다. 우리는 개발 주기 동안 내부적인 용도로 최신 코드를 계속해서 발표하고 고객의 피드백을 받기 위해 베타 테스트를 합니다. 비록 상용 제품이고 모든 개발자가 썬 직원이지만 우리는 어떤 면에서는 '시장' 방식의 개발을 하고 있다고 볼 수도 있습니다.

이러한 방식의 개발의 어려움은 특히 OS 커널처럼 아주 복잡한 소프트웨어일 경우 변경이 아키텍처적으로 일관성 있고, 잘 통합되어야 하며, 적절한 수준의 품질을 보장해야 한다는 것입니다. 이러한 사실이 거대한 개발자 공동체가 있을 수 없다는 것을 의미하지는 않습니다. 단지 제안된 변경이 문제를 일으키지 않는다는 것을 보장할 어떤 사람이나 사람들이 필요하다는 것을 의미합니다. 리눅스 세계에서는 이 일을 리누스와 그와 함께 일하는 사람들이 맡고 있습니다. 그들은 공식 커널에 들어갈 변경을 검토하죠. 썬에서는 품질, 적합성, 완전성 등을 위해 제안된 변경을 검토하는 선임 엔지니어들이 있습니다.

6. Is OS research dead? In the past, there was a great deal of research about the basics of OS design, like allocators and scalable scheduling. Today, the focus seems to be on application-level advancements like new virtual machines and user-level development frameworks. Have OS kernels pretty much reached the end of their evolution, or do they see kernels continue to evolve, perhaps incorporating some of the research techniques like orthogonal persistence or exokernels?

Andy Tucker: OS 연구의 성격은 시대마다 변해왔습니다. 1980년대와 1990년대 초반에는 많은 '대형 시스템' 연구가 있었습니다. 대학과 산업 연구소 운영체제를 만들면서 연구를 시작했고 운영체제를 새로운 아이디어를 실험할 플랫폼으로 사용했습니다. CMU의 Mach, 버클리의 Sprite, 스탠포드의 V System 등은 기본 OS 구조에 대한 많은 재실험이 있었다는 것을 뜻합니다. 어떻게 하면 처음부터 운영체제를 가장 잘 만들 수 있을까 하는 것이었죠. 결과적으로 분산 시스템, 마이크로커널 등에 관한 연구를 하게 됐구요. 하지만 시스템은 같은 응용 프로그램, 특히 연구자의 데스크탑에서 동작하는 것을 지원하는 데 목적이 있었습니다.

오늘날 제가 본 대부분의 연구는 기존 OS 플랫폼, 대개 리눅스나 *BSD 중 하나에 기반을 두고 있습니다. 초점은 멀티미디어, 이동성 등 새로운 형태의 응용 프로그램에 대한 지원을 개선하는 데 맞춰져 있습니다. 따라서 운영체제의 기본 구조를 보는 사람은 점점 줄어들고 있습니다(예외도 있지만요). 하지만 사용자 관점에서 운영체제를 더 잘 작동하게 하는 데는 관심이 높아지고 있습니다. 기존 OS 플랫폼을 사용하는 것은 OS 연구에 대한 진입 장벽도 제거합니다. OS 부서가 소규모이고 예산이 많지 않은 대학에서도 새 운영체제를 전부 만들지 않고도 흥미로운 연구를 할 수 있습니다.

7. 30 years after UNIX was recoded in C, most people still use C (or in some cases a little bit of C++) for the OS kernel. Is C perfectly adequate, or do they see some of the newer languages (C#, Java, or even modern C++ paradigms) being applied to OS design?

Andy Tucker: 이 분야에서 다양한 실험이 있었습니다. 예를 들면 썬은 C++ (SpringOS)와 자바(JavaOS)로 운영체제를 만들었습니다. 오브젝트 오리엔티드 언어가 고수준 프로그래밍 추상화를 위한 쉬운 개발의 관점에서 보면 장점이 많지만 OS 커널 개발에도 그만한 혜택을 주는 것은 아닙니다. 커널은 하드웨어와 가장 직접적으로 상호 작용하는 소프트웨어이기 때문에 메모리 재활용(garbage collection)과 템플릿 등의 쉬운 개발을 위한 기능보다는 언어와 기계의 명령(instruction) 사이에서 간단하게 사상(map)되는 데서 얻는 이익이 더 큽니다. 언어 의존적이고 광범위한 런타임 지원 요구도 있습니다. 대신 오브젝트 오리엔티드 언어의 개념(예: 다형성)을 빌리거나 비-OO 언어(C)로 그것을 구현하는 방법을 찾기도 합니다.

8. How do you feel Solaris process management technologies like the Fair Share Scheduler will stack up to the Linux O(1) scheduler. Furthermore, has Sun ever attempted to implement an O(1) scheduler for Solaris and if so, what problems/drawbacks they encountered which kept it out of the released kernels.

Andy Tucker: 솔라리스에는 몇 년 간 O(1) 스케쥴러가 실제로 있었습니다. 런 큐 역시 확장성을 극대화하기 위해 CPU마다 있었습니다(The run queues are also per-CPU to maximize scalability). 이것이 비밀은 아니었지만 우리는 기술 자체에 대해서는 많이 이야기하지 않았습니다. 대부분 결과물에 초점을 두었습니다.

'fair-share 스케쥴러'는 솔라리스의 스케쥴링 정책 중 하나입니다. 개별 프로세스에 할당된 우선권을 제어하는 것입니다. ... 중략(무슨 내용인지 제대로 이해하지 못했습니다. :? ) ...

10. What is the future holds for Solaris 10? What enhancements are in-store in the OS and kernel level? Are there any plans to integrate the Gridengine into Solaris rather than being a separate application?

Andy Tucker: 솔라리스 10에는 새로운 기능이 많이 들어갑니다. 하나는 솔라리스 존(Solaris Zones)입니다. FreeBSD(jail)에서 아이디어를 가져와 고객의 요구에 맞게 확장한 것입니다. 이 기능은 관리자가 단일 시스템을 존이라 부르는 여러 개의 분리된 응용 프로그램 환경으로 나눌 수 있게 합니다. 한 존 안에 있는 프로세서는 다른 존 안에 있는 프로세스를 보거나 상호 작용할 수 없습니다. 이것은 많은 응용 프로그램이 같은 시스템에서 서로 충돌하지 않고 운용될 수 있다는 것을 의미합니다. 관리자는 백업, 패치 등을 위해 한 OS의 커널만을 관리하면 됩니다.

우리는 시스템 안정성과 관측성을 향상시키는 방법도 찾고 있습니다. 솔라리스 10에서는 사용자 레벨뿐만 아니라 커널에서 무엇이 진행되고 있는지 추적할 수 있는 도구를 제공할 계획입니다. 자신의 응용 프로그램의 성능이 형편 없이 나오는 이유를 알고 싶은 개발자는 모든 소프트웨어 스택으로부터 정보를 얻을 수 있으며 실제로 무슨 동작이 수행되는지 더 잘 이해할 수 있습니다. 우리는 이 도구들을 내부적으로 사용하면서 솔라리스와 다른 썬 소프트웨어의 성능과 안정성을 개선하고 있습니다.

codebank의 이미지

솔라리스 10이 나온다는 기사인가요?
영어는 통~ 해석이 안되네요...
:D
영어없는 세상에서 살려고 kldp에 왔는데 결국 또 영어를 보게만드시다니... :oops:

------------------------------
좋은 하루 되세요.

cjh의 이미지

8번에서 번역이 없는 부분에 대한 날림 번역입니다. :)

The fair-share scheduler allows the allocation of CPU in the system to be divided among groups of processes according to proportions defined by an administrator. For example, on a system running both a mail server and a web server, the administrator might decide that if the system is busy, 2/3 of the CPU should go to the mail server, and 1/3 should go the web server. Although in the past the fair-share scheduler was available only as a separate product (Solaris Resource Manager), we decided that it was important enough technology for our customers to bundle in the core operating system.

fair-share(공평 분배 정도 될까요?) 스케줄러는 시스템의 CPU 할당을 관리자가 정의한 비율에 맞추어 프로세스의 그룹에 분배할 수 있도록 합니다. 가령 메일 서버와 웹 서버가 동시에 동작하는 시스템에서 관리자는 시스템 부하가 심하다면 CPU의 2/3는 메일 서버로, 1/3은 웹 서버로 가도록 결정할 수 있습니다. 과거에는 fair-share 스케줄러가 별도의 제품으로만 이용할 수 있었습니다만(Solaris Resource Manager), 지금은 우리의 고객을 위해 주 운영 체제 안에 포함시키기에 충분히 중요한 기술이라고 결정하였습니다.

--
익스펙토 페트로눔