본문 바로가기
오픈소스 읽기 (OLD)/Init 시스템 - Systemd

2. Systemd 기본 개념잡기 (1/2)

by 커널패닉 2021. 3. 16.
반응형

같은 카테고리의 글 보기

www.kernelpanic.kr/category/%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4%20%EC%9D%BD%EA%B8%B0/Init%20%EC%8B%9C%EC%8A%A4%ED%85%9C%20-%20Systemd

 

'오픈소스 읽기/Init 시스템 - Systemd' 카테고리의 글 목록

 

www.kernelpanic.kr

출처: https://insujang.github.io/2018-11-22/systemd-boot-process/

 

2.1 Systemd 특징

Systemd는 최근 가장 보편적으로 사용되고 있는 Init 프로세스이다. 예전에는 Init프로세스로 SysV가 주로 사용되었고, 우분투는 Upstart를 사용했었다. 하지만 SysV와 Upstart는 단점을 가지고 있었고, 오늘날 Systemd로 대체되었다. 그렇다면 Systemd의 무엇이 이와 같은 init의 세대교체를 이뤄냈을까?

systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic. systemd supports SysV and LSB init scripts and works as a replacement for sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage simple network configuration, network time synchronization, log forwarding, and name resolution.

freedesktop.org에서 제공하는 Systemd에 대한 공식 설명이다. 영어기 어렵지는 않지만, 문단이 길기도 하고, 다소 난삽하게 쓰여져 있어서 배경지식이 없으면 읽고 바로 이해하기는 어려울 수 있다. 위 문서는 Systemd의 장점들을 쭉 나열하고 있는데, 요약하면 아래와 같다.

 

1. 적극적인 병렬처리 기능

2. 소켓과 D-Bus 활성화

3. on-demand 데몬 실행

4. 프로세스 트래킹

5. 파일시스템 마운트 및 마운트 관리

6. 의존성 기반의 서비스 컨트롤 로직

7. SysV init 스크립트에 대한 호환성

8. 로깅 데몬 제공

9. 기본적인 시스템 설정 컨트롤 유틸리티 제공

10. 다양한 네트워크 관련 데몬

 

정리하자면 이 문서는 크게 서비스/데몬 관리, 프로세스 관리, 시스템 관리, 제공하는 유틸리티에 대해 설명하고 있다. 이를 정리해보면 다음 표와 같다.

분류 내용
서비스 / 데몬 관리 - 적극적인 병렬처리 기능
- on-demand 데몬 실행
- 의존성 기반의 서비스 컨트롤 로직
프로세스 관리 - 프로세스 트래킹
시스템 관리 - 소켓과 D-Bus 활성화
- 파일시스템 마운트 및 마운트 관리
- 다양한 네트워크 관련 데몬
유틸리티 제공 - 로깅 데몬 제공
- 기본적인 시스템 설정 컨트롤 유틸리티 제공

이번 포스트에서는 각 분류별로 Systemd가 구체적으로 어떤 작업을 수행하는지 살펴본다.

 

2.2 서비스 / 데몬 관리

Init 시스템은 필요한 시스템 서비스들과 데몬을 실행한다. 한번 같이 생각해보자. 아주 단순화해서 마운트 서비스, 네트워크 서비스, 로깅 서비스, 알람 서비스 4개의 서비스를 실행해야 한다고 가정하자. 가장 먼저 마운트 서비스가 실행되어야 하고, 다음으로 네트워크 서비스가, 마지막으로 로깅 서비스와 알람 서비스가 실행되어야 한다. 이러한 서비스를 순차적으로 실행하는 시스템을 어떻게 구현할 수 있을까?

가장 쉽고, 기초적인 방법은 위 4개 서비스를 순차적으로 실행하도록 init 프로세스에 하드코딩하는 방법이 있다. 가장 빨리 구현이 가능하고, (오늘날 프로세스 속도를 생각하면 별 의미가 없겠지만) 오버헤드가 가장 적은 빠른 방법이다. 하지만 이 글을 읽는 여러분은 이 방법을 택하지 않을 것이라 믿는다. 이렇게 코드를 짜면, 서비스를 하나 추가하려고만 해도 새로 컴파일을 해야 한다. 뿐만 아니라 서비스의 개수가 많아지면 코드를 유지보수하기도 점점 어려워진다. 즉 프로그램의 유연성과 유지보수성이 아주 떨어진다.

다음으로 특정 config 파일에 실행되어야할 서비스의 정보를 기록하고, 해당 파일을 읽어서 실행하는 방법이 있다. 이 방법으로 코드의 재컴파일 없이도 자유롭게 서비스를 추가할 수 있다. 다만 서비스의 개수가 많아지면, config 파일을 관리하기 어려워진다. 예를 들어서 로깅 서비스가 실행되려면 반드시 마운트 서비스 로딩이 완료되어 있어야 한다고 하면, config 파일을 항상 마운트 서비스가 완료된 다음에 로깅 서비스가 실행되도록 구성해야 한다. 위에서 예로 든 4개의 서비스를 관리할 때는 문제가 없겠지만, 현실에서는 최소 수십개, 많으면 백개가 넘는 서비스를 이런 방식으로 관리하는 것은 꽤나 골치아픈 일이다. 이 방법이 SysV가 사용한 방법이다.

각 Init 시스템 서비스 관리 방식 예제

마지막으로 각각의 서비스들을 이벤트 방식으로 관리하는 방법이 있다. 이 방법은 각 서비스들이 실행되는 조건(예를 들어서 "로깅서비스가 실행되려면, 마운트 서비스가 완료되어야 한다."와 같은 조건)이 충족될 때, 서비스를 실행한다. 따라서 실행순서가 정해진 config 파일 대신, 각 서비스의 실행 조건을 기록한 여러 파일들의 집합으로 구성된다. 구현하기 어렵기는 하지만, 이 방법은 서비스 개수가 많더라도 새로운 서비스를 추가할 때 사이드 이펙트가 없거나 적다. 또한 조건을 만족한 서비스들을 병렬적으로 처리할 수 있어 속도가 빠르다. Systemd가 바로 이 방법을 사용하고 있다.

순차 실행 방식과 병렬 실행 방식 비교

 

실제로 Systemd의 서비스를 정의하는 파일은 아래와 같이 작성한다. 우선 Systemd 서비스 파일은 ini 파일 작성 문법을 따라간다. ini 문법이 무엇인지 잘 모른다면 ko.wikipedia.org/wiki/INI_%ED%8C%8C%EC%9D%BC 위키를 참조하자. (한국어 위키에는 빠진 내용이 많다. 영어가 자신있다면 영어 위키를 읽는 것을 추천한다.)

각설하고 가장 먼저 나오는 Unit 섹션은 해당 서비스의 메타데이터를 다루고 다른 서비스와의 관계를 정의한다. 다양한 키워드들이 있는데 사용된 키워드 위주로 본다면, Description은 서비스에 대한 설명이고, After는 해당 서비스가 언제 실행될지를 알려준다. 단 After 자체는 단순히 순서적인 정보를 가지고 있을 뿐, 의존성을 의미하지는 않는다. 의존성은 Requires 키워드로 정의할 수 있다.

Service 섹션에서는 해당 서비스가 어떻게 실행될 것인지를 정의할 수 있다. ExecStart는 가장 핵심적인 내용으로 서비스의 실행 경로를 가지고 있다. 이 외에도 서비스 종료 시(크래시 등에 의한 강제 종료 포함) 재시작 여부, 서비스 타임아웃 등을 설정할 수 있다.

마지막으로 Install 섹션에서는 서비스를 등록/해제(enable/disable)할 때 사용할 설정값이다. WantedBy는 해당 서비스가 활성화되어 있어야, 본 서비스를 활성화 할 수 있다는 의미이다. 아마 multi-user.target과 같이 XXX.target이라는 표현에 대해 낯설 수 있다. 이 내용에 대해서는 다음에 시간이 나면 다루도록 하겠다.

[Unit]
Description=logging service
After=network.target
Requires=mount_service

[Service]
ExecStart=/usr/bin/env php /path/to/server.php

[Install]
WantedBy=multi-user.target

이상이 가장 기본적인 Systemd 서비스 파일의 옵션들이고 실제로는 아주 다양한 옵션이 있다. 영어긴 하지만 www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files 포스트가 Systemd 서비스 파일에 대해 자세히 다루고 있다. 좀 더 깊이 있는 정보를 원한다면 읽어보면 도움이 될 것이다.

 

내용이 예상보다 길어져서 프로세스 관리, 시스템 관리, 유틸리티 제공은 다음 포스트에서 다룬다.

 

kernelpanic.kr/18

 

2. Systemd 기본 개념잡기 (2/2)

앞선 글 kernelpanic.kr/17 2. Systemd 기본 개념잡기 (1/2) 2.1 Systemd 특징 Systemd는 최근 가장 보편적으로 사용되고 있는 Init 프로세스이다. 예전에는 Init프로세스로 SysV가 주로 사용되었고, 우분투는 Ups..

www.kernelpanic.kr

 

반응형