자꾸 보이는거 같아서 궁금해서 살펴보았더나 재밌는 내용이라 포스팅!! (허태준 님은 순수 오리지날 국산 풀타임 커널 해커이시다!! 아직도 삼성에계시는지 잘모르겠네 ㅡㅡ)
다름아닌, 열라 고자세로 일관하는 공룡같은 리눅스계의 갑(구글신)과,
리눅스 내부 프로젝트간의 갈등이랄까..
간략하게 요약하자면, 태준님은 현재 Control Groups 라는 리눅스 커널의
리소스 관리를 위한 시스템 프로젝트의 메인테이너를 맡고 계시는데,
최근 구글과의 한판 설전은 물론 대립구도를 만들어가는 메일들이 많이 있었다는 것!
이 Control Group 이란 시스템의 프로세스들에 대한 자원들을 각 계층별로 나누고,
그걸 또 그룹화 시켜 관리가 가능하도록 만든 매카니즘인데, 여기서 계층이란
성능에 관련된 Memory, CPU, I/O bandwidth, Throughtput 등등을 말한다.
즉 Cgroup 은 각 프로세스들에게 그룹별로 유연하면서도 확장성 있는 리소스 할당 및 관리에 대한 정책을 적용시키고자 하는 녀석으로써, 리눅스 Resouce 관리를 마치 Unix 따위 애들처럼 분할하여 사용 할 수 있도록 한 획기적인 녀석
이기 때문에,
커널에 이 자원을 관리 할 수 있는 "Controller" 가 포함되었다는 것이지.. (상세문서는 Kernel Documentaion/cgroups/cgoups.txt 참조해라)
이녀석이 문제가 되고 있는 이유는 이 엄청난 확장성과 유연성이라는 장점이 문제가 되는,
전가의 보도 혹은 양날의 검 이랄까...
이게 워낙 유연하고 강력해서 여기저기서 은근히 마구마구 쓰고, 적용시키고 있는 상태인데,
막상 Cgroup 내부적인 프로세스들을 좀 수정하려고 보니 워낙 엮인애들이 많아서,
이 실타래를 쉽게 풀 방법이 구해지지 않는 다는 점이지..
문제를 조금 더 상세히 설명하자면,
이 Cgroup 은 서브시스템 안에서 중복적인 계층(자원) 들을 할당 할 수 있는데,
프로세스들을 계층화 시켜서 가능한 CPU time 만큼 그 제한된 리소스 내에서
충분히 활용 할 수 있도록 해주는 방식의 자원관리가 가능하다는거지...
그런데, 이게 워낙 유연하게 개발되어 있다 보니까,
전혀 다른 프로세스에서도 이 똑같은 정책을 통해 계층을 접근 할 수 있다는 중복성 때문에,
어떤 그룹 계층에 대한 정책이 다른 그룹 다른 프로세스에도 영향을 미칠 수 있다는 거지.
예를 들면, 한 프로세스가 메모리에 대해서 열심히 어떤 작업들을 하고 있는데,
CPU 에 대한 정책을 받지 않은 상태라서 혹은 다른 CPU 정책 그룹에의해 CPU time 제한으로,
막상 본인은 CPU time 을 전혀 얻지 못해버리는 경우도 생긴다는 거야..
이 부분을 수정하려고 보니, 계층 소유권을 갖고있는 각각의 컨트롤러의 허가를 통해야만,
할당 및 통제가 가능하도록 디자인이 되어 있는데도 불구하고, 막상 고치기에 쉽지 않더란 것..
컨트롤러는 겉으로 보기에는 메모리 사용량, I/O Bandwidth, writeback throtting
이 세가지 그룹으로 각각 따로 정책을 갖고 조절되는 것으로 보여지는데,
실제로 까보면 결국 커널이 관리하는 메모리 아래에서 얽히고 섥혀 있다는 거지.
이 세가지 컨트롤러들 모두 메모리 페이지에 연동되어 관리되는데,
만약 할당된 컨트롤러가 메모리 컨트롤러의 관점에서 한개의 그룹으로 묶에있었다면,
그런데 그게 또 I/O bandwidth 에 대해 다른 그룹정책에도 속해 있다면,
이런 얽혀있는 계층간에 대한 추적 및 관리에 드는 비용이 크게 발생하여 잠재적 문제가 생긴다는 거지.
따라서, 이런 내부적 충돌 이슈들을 해소하기 위한 정책을 만드려고 하는데, 어떻게 구분해야 할지,
등등을 정하기가 너무 어렵고 깔끔한 아이디어가 없어 고민중인 상태..
또 다른 CGroup 의 문제로는 가상파일시스템 인터페이스가 너무 저레벨에서 구현되어서,
커널에서 컨트롤 그룹들이 어떻게 수행되고 있는지 너무 상세하게 노출되버리는 점 이라는데,
즉 Cgoup 에대한 관리를 가상의 Filesystem 을 통해 구현하는데, 이게 너무 저레벨 구현이라, ( mount -t proc cgroups /cgroups 로 마운트하면 다 볼 수 있어진다. )
사용자가 증가하면 할수록 이미 존재하는 어플리케이션에 영향을 미치게 될 수 있는 가능성때문에,
수정에 많은 어려움이 생기고 있다는 것이다.. ( Cgroup 에 대한 이해가 필요하다. 이건 레드햇에서 문서가 잘 되어 있단다! )
어쨋든, 많은 사람들의 충분한 고민으로 도출된 결론은 "갈아 엎자! 바꾸자!" 라는게 대세..
대부분 사용자 및 어플리케이션들이 Cgroup 계층간 서브트리들을 위임하기 위한 방법으로,
이 가상파일시스템을 직접 접근하여 파일퍼미션을 통해 위임 및 컨트롤을 하도록 만들었고,
게다가 이 가상파일시스템 으로 구현된 Cgroup 을 LXC(Linux Container) 혹은
Virtualization 에서도 그런식으로 사용되고 있는 상황이라 고치기에 쉽지 않다고 하는것
또한 이로 인한 보안적 이슈가 발생할 수 있어 실제로 DoS (Denial of Service)
공격까지 나오는 등, 상당히 많은 부분에 대한 변화가 필요해 보이는 상태..임은 틀림없단거지..
말 그대로 Cgroup 의 인터페이스가 통째로 바뀌어야만 한다는 것. (이제 CGroup 이 무엇때문에 뭘 바꾸려고 하는건지 이해가 됐길 바란다.)
따라서, CGroup 커뮤니티로부터 Cgroup Interface 는 더 유지보수하기 용이하며,
보안적이면서도 사용하기 쉽도록 고쳐져야 한다는 요구가 매우 강하게 쳐 나왔으며,
원문에서 ABI 를 수정할때의 철칙에 대한 설명을 한 이유가 여기에 있다.
* 해결책과 그것에 대한 불만!
컨트롤 그룹은 이에 대한 목표를 세가지 정도로만 간략히 정리,
이 부분들을 제거하는 방안으로써, 모든 컨트롤러가 프로세스들에 적용될 때,
그것을 관리하는 단일 프로세스를 기반으로 수해이 되도록 만들겠다는 계획이 나왔는데,
뭔가 오인이 있었는지, 이 부분들을 단계적으로 폐기하고 고쳐나가는 것이 아니라
단숨에 고치겠다는 계획으로 보였다는 것...
물론 Cgroup 계층에 대한 허가받지 않은 접근은 강하게 거부하고,
모든 Cgroup Management Task 들을 허가된 하나의 프로세스를 통해 관리하도록 하여,
그 프로세스를 통해 다른 시스템에 제공하는 인터페이스로 만들겠다는 것은,
모든 관리적 차원에서 훌륭한 대안으로 보였다... 하지만!!!
여기서 졸라 공룡같은 구글님아가 딴지를 건다.
구글님의 Tim hockin이라는 사람은 구글의 거대한 클러스터링의 유지 및 관리를
Cgroup 을 적용해 다양한 계층별 리소스 정책을 적용하면서 사용중이였거든...
근데 이 태준님아가 이걸 한개의 프로세스(또는 컨트롤러) 로 싸그리 바꿀거고,
이건 절대 변하지 않을꺼야! 라고 못박아버리니, 빡돈거지... (사실 못박은적은 없다는게 함정! )
졸라 밤새 구축해 놨더니 바꾼다는거잖아 패러다임을...그러면 또 밤새라는건데,
어떻게 바꿀꺼냐는 식으로 좀 물어 봤겠지... 메일링 리스트를 통해..
그랬더니 다른 사람(Lennart) 가 systemd 를 이용하게 될것 같다. 이거 좋다! 라고 얘기한거지..
여기서 이제 이녀석이 멘붕한거! 이 systemd 를 구글은 안써 -_-...
열라 좋은 - 건 아니고 괜춤한데 왜 안쓰는지는 몰라..
이 팀이란 녀석이 말을 안해줘.. 뭔가 다른걸 쓰나봐... 안가르쳐주려고하는 분위기야..
아무튼 팀이 태준님에게 이렇게까지 경고까지 하게 돼:
"나 졸라 멘붕인데, 너 지금 나 야근시키려고 작정한거니? 나 여기서 뼈를 묻어야돼? 이 작업때문에? 넌 지금 리눅스'만' 사용 하는 세계에서 젤 큰(내생각에 불만있어?) 엔터프라이즈의 바이너리 호환성을 송두리째 까고 있는거야~.. 넌 지금 빡치는 소리 하고 있는거라고!! 유남생?"
사실, 팀 생각처럼, 일~이년 안에 Cgroup 의 기능이 변화가 생긴다면,
확실히 맨날 밤새도 모자를 만한 일이 생기게 될 것이긴 한데,
이런 변화들이 급격히 게다가 요구사항에 대한 반영 한번 없이 이루어 질거라는 것은
그의 착각인 것으로 보인다... 말 그대로 멘붕으로 받아들인게지... (내가 봤을땐, systemd 를 사용하지 않는 분명한 특별한 이유가 있을 것인데..)
또한 사실, 커널 ABI 에 대한 고전적이며 전통적인 Rule ( 유지보수등에 대한 철칙 ) 을
Cgroup 에서만 제외 할 수 없었기 때문에,
기존의 인터페이스에 포함되 있는 많은 계층들을 더이상 사용하지 않을 때 까지 는,
계속 지원해줘야하는게 맞고, Cgroup 을 한번에 바꾼다는 말도 없었고,
새로운 컨트롤러를 추가해서 점점 그 컨트롤러로의 권한을 집중시키는 방식으로
개발을 할 텐데도 구글님은 엄청 졸았던 거지.. (근데 아무리 그래도 저딴소리 하면 쓰것어? 하여간 저 그룹들도 정상적이지 않아지고있어)
팀은 계속해서 구글이 다양한 계층들을 얼마나 사용하는지에 대해서 설명 및 의문을 제기해.
기본적으로, 시스템에서의 모든 작업은 그것이 배치작업인지 혹은
I/O bandwidth 보증은 되고 있는지 등에 대한 두개의 속성을 갖고 있어서
2x2 Matrix 같이 자원할당을 비교적 쉽게 표현하여 사용하고 있었는데,
통합된 컨트롤러를 통한 관리를 하게 된다면 이게 불가능 해 질것이라고 주장한거야..
태준님은 이 "팀" 의 딴지를 대수롭지 않게 여기며, 같은 레벨의 계층에서 설정된
세가지 그룹들중, 유요한 정책에 대한 각각 조합을 통해 관리하면 된다고 답했는데,
다시 팀은 그럼, 기존에는 I/O bandwidth 개런티가 없는 프로세스의 경우,
두개의 그룹안에서만 나뉘면 됬었지만, 하나의 그룹안에 있도록 바뀌게 된다면,
이 두개 그룹중 하나가 다른 것보다 멤버가 더 많이 소유하고 있을 경우,
이 큰 그룹은 작은 그룹들보다 훨씬 작은 I/O 대역폭을 사용하게 될 것이라고 반박했다.
이 부분은 systemd 와 cgroup 에 대한 이해가 필요한 부분인데,
내가 대충 쉽게 표현하자면, I/O, CPU, Memory 를 계층으로 봤을때,
특정 프로세스에서 I/O 그룹이 빠진 CPU,Memory 만 그룹이 할당되어 있다고 할 경우,
이 I/O 에 대해서는 systemd 자체에서 관리되는 리소스풀에서 해결이 되야 하므로
오히려 I/O 에 대한 개런티를 갖고있는 그룹보다 해당 그룹의 멤버가 더 많다면,
실제로 그 그룹들은 모두 훨씬 작은 양의 I/O Pool 에서 놀아야만 하지 않느냐는 것.. ( 이녀석이 계속 상세하게 얘기 안해주면서 지말대로 될거라고 주장하는 중이라 이렇게 해석해 보았는데 뭐 ... 아님 말라그래 ㅡ.,ㅡ 샹샹바 )
어쨋든 우리의 호프 태준님은 골머리를 열라 썩고 있다는 점~
User Space 에서 해결을 봐야 하는데,
이 User space 에서 상대적인 워크로드에 대한 대역조절등이 가능할지 좀 헛갈리고 있다는 점~ 우리의 구글신님의 종(Tim) 님께서 실제적으로 도움이 되는 아이디어나 자기들이 CGroup 을 어떻게 쓰고 있는지는 잘 설명해 주지도 않으면서 딴지만 걸고 있다는 점~
이 구글의 팀 형아는 초강수도 하나던지는데, 만약 계속 systemd 를 사용하고,
업스트림에서도 이 Single-agent 방식을 수용한다면, 구글은 그걸 수용하느니, 차라리
자기들의 시스템에 필요한 리소스관리 매카니즘을 새로 하나 만들어버려야 하는것을
선택해야 할것이다는 강수를 두었다는거!!!
근데, 역시 주고받은 메일들을 잘 따라가다 보면 구글에서 systemd 를 쓰지 않으려고
애를 쓰는 합당한 이유가 보여지지 않는 다는 것이다..
실제로 변경되게 될 부분들이 구글이 지금처럼 대립구조를 고수하는 것 보다 더 좋은 결과를
가져올 것임이 틀림 없다고 생각되지만, systemd 라는 것에만 의존하게 되는 것을
반대하는 사람들이 꽤나 크거나 많이 남아 있는 상황이 지속된다면, 그 변화는 별로
달갑지 않는 일이 될 것이나, 여러가지 제안들에 대한 경쟁은,
CGroup Management Daemon 들의 컨셉에 지대한 영향을 미칠것이며, 성취를 이룰 것이다..
SergeHallyn 은 그의 주도로 Cgroup 관리 damon 에 대한 작업이 진행중임을 자백했다.
Lennart 와 Serge 는 여러가지 요구들을 접하게 될 터이나, Init Process 같은 생성자역할의
프로세스는 다른 어떤 프로세스에도 의존되지 않은 일반적 오퍼레이션이 이루어 져야 한다는
입장을 고수했고, 태준님 역시 몇가지 심정의 변화를 통해,
그냥 막무가네로 진행하려던게 아니라는 것을 얘기하였다 :
"넘어야 할 산이 꽤나 높지만, 나는 생겨날 문제를 예측할 수 있는 모든 게이들에게 배울 자세가 되어있다. 타협 가능하니 진정하고 평가해보자"
그러나, 아직 이 많은 시행착오와 논란속에서도 정확히 뭘 개선해야 하고,
어떻게 고쳐야 할지조차 확실하지 않다는 문제가 있다는 점은,
과연 이 문제가 해결가능 할지 가늠 할 수 없게 만들고 있다는 사실...
리눅스 초창기에는 ABI 들의 대부분을 다른 앞서간 Unix 및 Linux 계열에서의 기능 이전등 대부분이었던 터라, 이미 많은 문제들이 해결되어있었거나, 어떻게 진행해야 할지 이미 윤곽이 보이던 상태였지만, 요즘에는 아무리 ABI Guideline 이 있다고 해도, 최선의 design 을 만들어 내는것은 쉽지 않은 현실이 되었다.. 실수는 우연히 나타나기 마련이며, 실수들로부터 더 좋은것을 얻고, 더 좋은 디자인을 만들며, 고통을 겪는 사용자가 나타나지 않도록 나아가야 한다. 이 Control Group 이 겪고 있는 전환에 대한 고통은, 어떻게 앞으로 변화에 대한 핸들링이 필요하는지에 대한, 수 많은 판례를 기록하게 될 것으로 기대된다..
고 조나단아저씨는 기사를 끝맺었다....
무엇보다. 난 이 태준님이 너무 존경스러운데, 역시 Maintainer 의 역할은 단순히
소스를 고치고 리뷰하는 정도에 그치는 것이 아닌, 많은 오픈소스 사용자들과,
그에 따른 기업들, 경우에 따라서는 커널 내부의 프로젝트 팀들간의 커뮤니케이션도
조절해야 하는 막중한 임무를 띈 수장임을 알 수 있게 되어 감동받은 기사랄까..
또한 구글의 저 팀님의 발끈함이 더 즐거웠던 기사!
이 기사는 수요일.. 즉 오늘 공개되어있으... 나의 무식함을 탓할 사람은.. 언제든지 탓해주길 바란다.
