Systemd – 당신이 알아야 할 것

당신이 바위 아래에서 살고 있지 않거나 더 나쁜 경우, 리눅스 작동 방식에 대해 별로 신경을 쓰지 않는다면, 최근에 대부분의 주요 리눅스 배포판에 의해 채택된 구식 SysV init을 대체하는(상대적으로) 새로운 init 시스템인 systemd에 대해 들어봤을 것입니다.

init 시스템이란 무엇인가?

당신의 리눅스 머신이 시작될 때, 먼저 BIOS 또는 UEFI에서 로드된 일부 “내장” 코드를 실행한 다음, 그 구성에 따라 리눅스 커널을 로드하는 부트 로더가 실행됩니다. 커널은 드라이버를 로드하고 첫 번째 작업으로 init 프로세스를 시작하는데, 이 프로세스는 첫 번째이므로 PID(프로세스 ID) 1이 할당됩니다.

사용자의 관점에서는 네트워킹 및 데이터베이스 등을 시작하는 것처럼 보이지만, 실제로는 다소 복잡한 과정이 배경에서 일어나고 있습니다. 서비스가 시작되고 중지되며 다시 시작되며, 종종 서로 병렬로 실행됩니다. 일부는 다른 것들보다 다른 권한으로 실행되고, 서비스 상태가 보고되고 로그에 기록되며, 시스템의 다양한 부분이 작동하고 사용자 및 환경과 상호 작용할 수 있도록 다수의 다른 작업이 수행됩니다.

그러나 이러한 구현 방식은 결코 균일하지 않으며, 바로 여기에서 모든 것이 공통되고 잘 정의된 것이 멈추게 됩니다.

구식 init 시스템

최근까지 대부분의 주류 리눅스 배포판에서 사용된 init 시스템은 System V init(약칭 SysV init)이었으며, UNIX System V(발음은 “System Five”)라는 이름을 따왔습니다. 이는 최초의 상용 UNIX 시스템입니다. System V OS는 init 프로세스를 실행하는 특정 방식을 가지고 있으며, SysV init은 수년 동안 이에 충실했습니다.

그리고 오랜 세월이 흘렀습니다. UNIX System V는 1983년에 처음 출시되어, SysV init은 리눅스 머신을 시작하는 데 있어 30년이 넘는 접근 방식을 유지해왔습니다.

변화의 필요성

보시다시피, SysV init은 구식이며 교체가 시급한 상태입니다. 그 이유는 다음과 같습니다:

• SysV init은 /sbin/init을 사용하여 init 프로세스를 시작하지만, init 자체는 매우 제한된 역할만 수행합니다. init은 /etc/init.d/rc를 시작하는 것 외에는 별다른 일을 하지 않으며, 이는 /etc/inittab에서 읽은 구성에 따라 실제 init 프로세스의 작업을 수행할 스크립트를 실행하게 됩니다. 이는 명시적으로 패널화하지 않는 한(예: Debian의 startpar), 각 스크립트가 이전 스크립트의 완료를 기다려야 하므로 전체 프로세스가 느려지게 됩니다.
• SysV init은 PID 또는 자신이 (간접적으로) 시작한 프로세스에 접근할 수 없습니다. 그것은 오히려 PIDs를 읽고 이를 우연적이고 복잡한 방식으로 실제 프로세스와 연관시키기만 합니다.
• 특정 프로세스가 시작되는 환경을 수정하려는 시스템 관리자에게 SysV init은 매우 어렵습니다. (이를 달성하기 위해 해당 프로세스를 시작하는 init 스크립트를 수정해야 합니다.)
• SysV는 모든 서비스에 공통적인 기능을 구현하지 않으며, 각 프로세스는 스스로 이를 구현해야 합니다. 예를 들어 “데몬화“하는 것(시스템 데몬이 되는 것)은 복잡하고 긴 과정입니다. 이러한 단계를 한 번에 구현하는 대신, SysV는 각 프로세스가 스스로 이 작업을 수행하도록 요구합니다.
• SysV는 외부 프로그램에 특정 기능을 맡기며, 그 프로그램에 의해 시작된 서비스에 대해 무지합니다.

위의 모든 점과 더불어 SysV의 설계 결함과 구식 시스템 설계는 현대의 init 시스템 구축을 오랜 시일 동안 미뤄왔습니다.

systemd의 등장

시스템 대체 init 시스템을 만들기 위한 시도가 있었고 systemd는 그 중 하나에 불과합니다. Ubuntu는 한때 upstart라는 자체 init 시스템을 실행했으며, Gentoo는 여전히 OpenRC를 사용합니다. 다른 init 시스템으로는 initng, busybox-init, runit 및 Mudur 등이 있습니다.

systemd가 명확한 승자가 된 이유는 대부분의 주요 배포판에서 채택되었기 때문입니다. RHL과 CentOS는 자연스럽게 systemd로 전환하였으며, 페도라는 2011년에 최초로 systemd를 공식적으로 채택한 배포판이었습니다. 그러나 Debian 8이 공식적으로 systemd로 전환하면서 Ubuntu와 그 파생 배포판도 이에 동참하였으므로 systemd는 모든 init 시스템의 지배자가 되었습니다.

systemd의 차별점은 무엇인가?

• systemd는 초기부터 끝까지 init 프로세스를 처리하는 단일 중앙 집중식 방법을 제공하는 것을 목표로 합니다.
• 프로세스와 서비스를 시작하고 중지하며 이에 대한 종속성을 추적합니다. 심지어 다른 프로세스의 종속성 요구에 따라 프로세스를 시작할 수 있습니다.
• 부팅 과정에서 프로세스를 시작하고 중지하는 것 외에도, systemd는 특정 트리거 이벤트에 반응하여 시스템이 활성화되어 있을 때 언제든지 시작할 수 있습니다. 예를 들어 장치가 연결될 때와 같은 상황에서 말이죠.
• 또한 프로세스가 스스로 데몬화할 필요가 없습니다. SysV init과는 달리 systemd는 프로세스가 데몬이 되기 위해 긴 과정을 거치지 않고도 서비스를 처리할 수 있습니다.
• SysV init과는 달리 systemd는 모든 프로세스에 대해 알고 추적하며, PID를 포함하여 시스템 관리자가 프로세스에 대한 정보를 얻는 것이 훨씬 간단해졌습니다.
• systemd는 가상 머신 없이 기본적으로 격리된 서비스 환경인 컨테이너를 지원합니다. 이는 미래에 더욱 안전하고 단순한 시스템 설계로 이어질 큰 잠재력을 가지고 있습니다.

물론 이는 주요 장점 중 일부에 불과합니다. systemd의 장점에 대한 전체 논의는 Debian 8의 “systemd 포지션 성명서”를 읽어야 합니다.

논란

물론 systemd는 모든 사람에게 환영받는 것은 아니었습니다. 사실, 많은 사람들이 systemd를 하나로 통합된 뚱뚱한 시스템이라 비판하며, 어떤 이들은 모든 것이 중앙 집중화된 “윈도우 방식”이라고 비난하기까지 합니다. 많은 사람들은 이것이 “리눅스 방식”이 아니라고 주장하며, 분명히 systemd는 POSIX 표준에 부합하지 않는 것 같습니다. systemd를 툴킷으로 본다면(단순한 바이너리를 넘어서), 확실히 거대합니다.

그럼에도 불구하고 systemd는 분명히 발전의 단계이며, 완벽하지는 않지만, 그에 대한 많은 비판은 원저자인 레너트 포터링(Lennart Poettering)에 의해 해결되었습니다. 분명히 이전의 init 시스템보다 훨씬 필요한 발전이며 한 걸음 전진한 모습입니다. 리눅스의 창시자인 리누스 토발즈는 systemd에 대해 크게 신경 쓰지 않는 것 같으며, 우리는 “창조자”와 논쟁할 처지에 있지 않습니다.

결론

모든 주요 리눅스 배포판에 의해 채택된 systemd는 앞으로도 남아 있을 것입니다. 어떤 시스템 관리자가 어떤 이유로 무엇을 말하든지 간에, systemd는 개인 사용자가 좋아하든 말든 현대 리눅스의 미래입니다. 그리고 그 뚜렷한 장점을 보면 그것은 결코 나쁜 일이 아닙니다.

일반 사용자에게 systemd는 더 빠른 부팅 시간과 아마도 더 신뢰할 수 있는 시스템을 가져다주며, 미래에 이를 채택한 배포판들은 서로 더 “호환적”이 될 수 있습니다. 사용자 측에서는 systemd가 우리의 데스크탑에 가져다주는 더 최신의 현대적인 시스템 설계로부터 확실히 혜택을 받을 것입니다.