차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판이전 판
다음 판
이전 판
tech:systemd [2017/09/24 00:17] 121.134.164.159tech:systemd [2022/11/11 00:53] (현재) V_L
줄 1: 줄 1:
-{{tag>systemd}}+{{tag>systemd 우분투 리눅스}}
 ====== Systemd ====== ====== Systemd ======
-{{INLINETOC}} 
  
-그런데 왜 upstart라는 init의 대안이 이미 나왔고, 수년 간 검증도 되었데 굳이 또 systemd라는 게 나와서 대체하게 되었을까? 물론 upstart를 밀었던 우분투는 systemd로 전환하고 싶하지 않았는데, 우분투의 부모라고 할 수 있는 데안 커뮤니티에서 systemd로 전환하기로 결정하는 바람에 우분투도 대세를 따랐다. 그럼 upstart는 init의 어떤 점들을 개선려 했으며, 또 systemd는 upstart의 어떤 점이 마음에 들지 않았을까?+init의 가장 큰 단점은 태스크가 직렬로 실행된다는 다. 그래서 I/O가 있는 작업은 많으면 부팅 속도가 느려지게 된다. 그래서 upstart는 이벤트 기반으로 작성되어 비기로 작업을 처리한다. 그리고 sysv 방식의 init에 비해 설정이 간편다.  
  
-init의 가장 큰 단점은 태스크가 병렬로 실행된다는 것이다. 그래서 I/O가 있는 작업은 많으면 부팅 속가 느려게 된다. 그래서 upstart는 이벤트 기반으로 작성되어 비동기로 작업을 처리한다. 그리고 sysv 방식의 init에 비해 설정이 간편하다. 필자가 체감하기에는 systemd도 간편한데, 이 점에서는 의견이 갈리는 듯 하다. +대부분의 리눅스   최신 배포판들은 systemd가 기본은 아닐지언정 설치는 대부분 되어 있을 것이고, 설치가 안되어 더라도 패키지로 설치할 수 있을 것이다. sshd의 예를 보면 기 쉬울 것이다. 우분투 배포판에는  /etc/systemd/system/sshd.service 파일이 음과 같이 작성되어 있다.
  
-그런데 이 upstart가 여러 배포판에 퍼져가던 중에 비판을 받기 시작했다. 그 중에 가장 상세하게 설명이 된 글이 Rethinking PID 1이다. 이 글에서는 먼저 좋은 init 시스템은 다음과 같은 특성을 가져야 한다고 정의했다. 
  
-적게 시작할 것 +   systemctl start sshd.service 
-가능한 한 병렬로 처리할 것 +   systemctl stop sshd.service 
-그런데 upstart는 의존성을 설정할 수 있어서 서비스 간에 의존성이 설정되어 있으면 의존성 순서대로 실행이 된다. 기껏 비동기 로직을 적용했는데 결국 직렬화를 해야 하니 성능상의 이득이 줄어든다. 그리고, 당장 필요하지 않은 서비스도 올려두게 되므로 처음부터 많은 프로세스가 뜨게 된다. 반면, systemd는 많은 서비스가 on-demand로 뜰 수 있다. 예를 들어 sshd는 부팅할 때 띄우지 않고 있다가 22번 포트로 요청이 오면 그 때 띄우는 것이다. 의존성도 이런 식으로 설정된다. 그러니까 부팅 속도도 빠르고, 불필요한 서비스는 올라가지 않아서 시스템 자원도 아낀다. 시스템 자원을 아낀다는 점은 애플리케이션 서버의 프로세스를 관리하는 입장에서도 유익하다+   systemctl restart sshd.service
  
 +systemd에서는 journalctl 명령으로 유닛의 로그들을 확인할 수 있다.
  
-앞으로 대분의 리눅스 배포판이 systemd로 통합될 것이므로 systemd를 미리 배워두면 좋을 것이. 물론 금도 최신 배포판들은 systemd가 본은 아닐지언정 설치는 대부분 되어 있을 것이고, 설치가 안되어 있더라도 패키지로 설치할 수 있을 것이다. sshd의 를 보면 이하기 쉬울 것이다. 우분투 배포판에는  /etc/systemd/system/sshd.service 파일이 다음과 같이 작성되어 있다.+  * -b 옵션을 주어서 마지막 팅 후의 를 확인한
 +  * -f 옵션을 주어서 tail -f 와 같은 기을 할 수도 있다. 
 +  * --since=today 와 같이 사용하여 오늘의 로그를 확인할 수도 있고, 
 +  * -p err 를 사용서 특정 레벨의 로그만 볼 수도 있다. 
 +  * -u <unit name>으로 특정 유닛의 로그만 확인도 가능함.
  
 +이 처럼 이때까지 필요로 해서 다른 도구 및 스크립트등을 사용해서 해야만 했던 작업이 기본 기능으로 포함되어있다.
  
 +=====upstart의 단점 =====
 +좋은 init 시스템은 다음과 같은 특성을 가져야 한다
  
 +  * 적게 시작할 것
 +  * 가능한 한 병렬로 처리할 것
  
-  systemctl start sshd.service +그런데 upstart는 의존성을 설정할 수 있어서 서비스 간에 의존성이 설정되어 있으면 의존성 순서대로 실행이 된다기껏 비동기 로직을 적용했는데 결국 직렬화를 해야 하니 성능상의 이득이 줄어든다그리고, 당장 필요하지 않은 서비스도 올려두게 되므로 처음부터 많은 프로세스가 뜨게 된다
-  systemctl stop sshd.service +
-  systemctl restart sshd.service+
  
 +반면, systemd는 많은 서비스가 on-demand로 뜰 수 있다. 예를 들어 sshd는 부팅할 때 띄우지 않고 있다가 22번 포트로 요청이 오면 그 때 띄우는 것이다. 의존성도 이런 식으로 설정된다. 그러니까 부팅 속도도 빠르고, 불필요한 서비스는 올라가지 않아서 시스템 자원도 아낀다. 시스템 자원을 아낀다는 점은 애플리케이션 서버의 프로세스를 관리하는 입장에서도 유익하다.
 +
 +=====그래서?=====
 +
 +
 +시스템 내부적으로 systemd, upstart, init.d 어느 것을 쓰던지 간에
 +사용자는 공통적으로 ''service'' 스크립트만 사용하면 된다. 
 +
 +=====아날=====
 +  systemd-analyze
 +
 +  Startup finished in 11.025s (userspace)
 +  graphical.target reached after 11.018s in userspace
  
-systemd에서는 journalctl 명령으로 유닛의 로그들을 확인할 수 있습니다. 
  
--b 옵션을 주어서 마지막 부팅 이후의 로그를 확인한다든지, 
--f 옵션을 주어서 tail -f 와 같은 기능을 할 수도 있습니다. 
---since=today 와 같이 사용하여 오늘의 로그를 확인할 수도 있고, 
--p err 를 사용해서 특정 레벨의 로그만 볼 수도 있습니다. 
--u <unit name>으로 특정 유닛의 로그만 확인도 가능합니다. 
  
-이 처럼 이때까지 필요로 해서 다른 도구 및 스크립트등을 사용해서 해야만 했던 작업이 기본 기능으로 포함되어있습니다.