거북이-https://velog.io/@violet_evgadn 이전완료

리눅스 로그 기본

VioletEvgadn — Fri, 14 Apr 2023 21:48:31 +0900

로그

◎ 리눅스 로그

사실 “로그”에 대한 개념을 모르는 사람은 없을 것이다. 자바든 C언어든 프로그래밍 언어를 통해 코딩을 조금이라도 깊게 해 봤다면 로깅에 대한 부분은 무조건 배우기 때문이다.

IT 업계에서 로그를 남기고 확인하는 것은 매우 중요한 일이다.

그를 통해 시스템이 어떻게 동작하는지 파악하여 시스템 동작 상황을 파악할 수 있고 오류가 발생했을 때 어떠한 이유로 오류가 발생했는지도 알 수 있다.

또한 로그를 통해 어떤 사용자가 어떤 작업을 했는지도 파악할 수 있기에 관리자 입장에서는 훗날 고객 응대에도 도움을 줄 수 있는 데이터가 될 수도 있다.

리눅스 로그를 관리 및 모니터링할 수 있는 툴은 매우 많다.

대표적인 리눅스 관리 툴로는 syslog, rsyslog, Logrotate가 존재하며 로그 모니터링 도구로는 Logwatch, Logrobat, Nagios, Logstash, Graybar 등이 존재한다.

로그에 대한 개념과 중요성에 대해 알았으니 리눅스의 로그 파일에 대해 알아보자.

로그 관리 파일들

◎ 시스템 로그 파일 : 리눅스 운영에 관한 로그

/var/log/messages

시스템 표준 메시지가 기록되는 파일이다.

Root 사용자만 열람이 가능하며 시스템에 문제가 생겼을 때 확인해야 하는 로그 파일이다.

이곳에는 syslog.conf에서 로그를 남기지 않도록 설정한 항목을 제외한 모든 항목들을 기록하며 이 때문에 내용이 매우 많으므로 grep 명령어와 결합하여 많이 활용한다.

/var/log/secure

인증을 통해 서버에 접속한 사용자 관련 정보가 기록되는 파일이다.

SSH, 텔넷 등으로 접속하는 경우나 로그인, tcp_wrappers, xinetd 관련 로그가 쌓이며 접속 일시, 사용자명, IP 주소 등이 기록된다.

만약 해킹 등의 보안적 문제가 우려될 경우 확인해야 하는 로그 파일이다.

/var/log/maillog

메일 송/수신 내용이 기록되는 파일로써 sendmail 같은 메일 작업이 기록된다.

/var/log/cron

크론에 관련된 실행 내용이 기록되는 파일이다.

Crontab에 지정된 작업들이 정상 수행되었는지, 정상 수행되었다면 어떤 작업을 수행했는지 등의 cron 실행 관련 정보가 기록되어 있다.

/var/log/boot.log

서비스 데몬들의 부트와 관련된 정보가 기록되는 파일로써 각 데몬들의 시작/종료/실패 내용이 기록된다.

부팅 시 발생하는 메시지와 데몬 정보 뿐 아니라 종료(shutdown) 시 내용도 기록한다.

아래 나올 dmesg와 헷갈릴 수 있는데 dmesg는 "부팅 시의 로그"를 기록한 곳이고 boot.log는 "부팅할 때 사용되는 데몬들의 로그"를 기록한 곳이다.

/var/log/dmesg

부팅 시 시스템 로그가 기록되는 곳으로써 “dmesg” 명령을 입력하면 해당 파일에 기록된 로그 내용을 확인할 수 있다.

보통 커널 부트 메시지 로그라고 한다.

◎ 어플리케이션 로그 : 어플리케이션에서 발생되는 로그

/var/log/httpd/access_log & error_log

Apache 서비스나 Nginx 서비스 데몬의 로그 파일로써 웹 서비스를 운영할 경우 유용하게 활요하는 로그파일들이다.

Aceess_log에는 웹 서비스가 정상적으로 운영 될 경우의 내용이 기록되며 error_log에는 에러 사항 대한 내용이 기록되게 된다.’’

/var/log/xferlog

FTP 데몬으로 파일을 전송한 내용이 기록되며 총 14개의 영역으로 구성되어 있다

/var/log/mariadb

MariaDB 데이터베이스 서버에 대한 로그 파일이다.

◎ 바이너리 로그 : 직접 읽지는 못하고 특정 명령어를 통해 확인할 수 있음

/var/log/wtmp

사용자의 최근 접속 사항이 기록되는 파일이다.

telnet이나 SSH를 통해 들어오는 사용자의 마지막 정보가 기록되는 곳으로 last 명령을 통해 로그 파일 내용을 확인할 수 있다.

/var/log/lastlog

각 사용자의 마지막 로그인 내용이 기록되어 있다. Lastlog 명령을 통해 확인할 수 있다.

이외에도 수많은 로그 파일들이 있지만 너무 많기 때문에 모두 설명하진 않겠다.

사실 위에 나온 로그 파일들의 설명도 그렇게 중요한 것은 아니고 어플리케이션 로그나 시스템 로그 몇 개 정도(cron, messages, secure 등)만 알아도 충분하다고 생각된다.

Cron

VioletEvgadn — Mon, 10 Apr 2023 22:20:22 +0900

Cron

◎ Cron이란?

Cron은 그리스어 "Chronos"의 약자이다.

cron은 유닉스 계열의 잡 스케줄러로써 지정된 스케줄(시간)에 따라 자동으로 테스트(업무)를 실행하는 시스템 프로세스를 말한다.소프트웨어 환경을 설정하고 관리하는 사람들은 주기적으로 특정 작업(보안 작업, 계정 등록 등)을 실행할 수 있도록 스케줄링하기 위하여 cron을 사용한다.

Cron을 사용하는 태스크에는 아래와 같은 것들이 있다.

로그 파일이나 DB 파일의 백업
오래된 파일 삭제
DB 테이블 아카이브(Archive)나 퍼지(Purge)
정규 알림 메시지
캐시 데이터 Clean Up
시스템 유지보수 자동화 등

◎ crontab

Cron Table의 약자로써 crontab 파일에 의해 cron 작업이 주기적으로 실행될 수 있다.

Cron은 Linux 서버가 부팅 될 때 시작되고 init 과정에서 데몬으로 백그라운드 프로세스로써 실행된다.

이후 크론은 사용자의 개입 없이 실행되며 crontab에 명시한 이벤트를 주기적으로 발생시키며 역할을 수행하게 된다.

크론이 참조하는 crontab 파일 위치는 3개이다.

먼저 /etc/crontab이다.

이는 관리자(Root 계정)가 직접 지정한 크론 작업들을 설정하며 임의의 사용자 권한으로도 실행할 수 있다.

여기에는 시스템 관련 작업들을 등록하여 사용한다.

두 번째는 /var/spool/cron이다.

이는 시스템 개별 사용자를 위한 crontab 파일 위치이며 일반적으로 root 계정을 위한 crontab과 서버 계정당 1개씩 crontab 파일을 저장하고 있다.

파일명은 계정명(Username)이며 크론은 파일명을 바탕으로 지정된 크론 작업을 실행할 때 사용할 UID를 결정하게 된다.

이곳에 있는 설정파일들은 crontab 명령으로 관리한다.

마지막은 /etc/cron.d이다.

여기에는 소프트웨어 패키지를 설치할 때 필요한 주기적인 작업들을 등록하는 공간으로 사용된다.

◎ cron의 사용자 제어

/etc/cron.deny와 /etc/cron.allow 설정 파일을 통해 사용자에 대한 crontab 제어를 관리할 수 있다.

/etc/cron.allow 파일이 존재할 경우 해당 파일에 지정된 사용자만 crontab을 등록할 수 있다.

다른 사용자들은 crontab 명령을 수행할 수 없다.

/etc/cron.deny 파일이 있을 경우 파일 내에 지정된 사람들을 제외한 나머지 사용자들에게 crontab 명령을 실행할 수 있는 권한을 준다. /etc/cron.allow 파일이 없을 경우 사용되는 크론 설정 파일이다.

Crontab 사용법

◎ Crontab 문법

위 사진에서 볼 수 있듯 "분, 시, 일, 월, 요일, [사용자명], 실행명령" 순으로 Crontab에 크론 작업을 지정할 수 있다.

차례대로 살펴보자.

먼저 첫번째 필드인 "Minute(분)" 필드이다. 가능한 값은 0 - 59이다.

두 번째 필드인 "Hour(시)" 필드이다. 가능한 값은 0 - 23이다.

세 번째 필드인 "Day(일)" 필드이다. 가능한 값은 1 - 31이다.

네 번째 필드인 "Month(달)"부터 살짝 복잡해진다. 가능한 값은 1 - 12인데 영어로도 입력할 수 있다.

숫자를 jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec으로 대체할 수 있다.

다섯 번째 필드인 "Day(일)"은 조금 더 복잡하다. 가능한 값은 0 - 7이며 영어로도 입력할 수 있다.

숫자와 영어의 의미는 아래와 같다.

0(or 7), sun : 일요일
1, mon : 월요일
2, tue : 화요일
3, wed : 수요일
4, thu : 목요일
5, fri : 금요일
6, sat : 토요일

여섯 번째 필드 "사용자명"은 대괄호([])안에 들어갔음을 볼 수 있다.

이 값은 생략 가능한데 만약 /etc/crontab이나 /etc/cron.d에 저장될 경우 명시해줘야 한다.

즉, 파일명을 통해 크론 동작을 실행할 UID를 알 수 있는 /var/spool/cron에서는 명시하지 않아도 되는 것이다.

마지막 작업 명령은 실행할 명령을 한 줄로 쓰면 된다.

우리가 많이 쓰고 있는 "ls"같은 명령어도 되겠지만 크론 작업을 의미 있게 사용하기 위해선 주로 실행 스크립트를 만들거나 원하는 실행 명령 구문을 만들어야 한다.

◎ /etc/crontab 내 특수 문자 및 문자열

특수문자

* : 모든 값에 매칭
a-b : 범위(a부터 b까지)
, : 특별한 값일 때만 동작
/ : 시작시간 / 단위 순서로 입력

특수 문자열

특수 문자열은 앞 5개 항목(분, 시, 일, 월, 요일)을 1개 문자열로 대체할 수 있는 값이다.

@hourly : 매 시간 한번. 0 * * * *
@midnight, @daily : 매일 한 번. 0 0 * * *
@weekly : 매주 한 번. 0 0 * * 0
@monthly : 매달 한 번. 0 0 1 * *
@annually, @yearly : 매년 한 번. 0 0 1 1 *
@reboot : 리부트 될 때마다 실행

Cron 표현식은 이론만 알고 있다고 이해할 수 있는 영역이 아니기 때문에 아래 예시들을 보 한 번 직접 사용해 보며 느껴보자.

출처 : https://www.ibm.com/docs/ko/urbancode-release/6.1.0?topic=interval-cron-expressions-defining-frequency

◎ crontab 추가/수정

# 크론탭 추가
crontab [-u 사용자명] Cron표현식

# 크론탭 수정
crontab [-u Username] [Option]

Option

-u : 크론을 실행할 사용자명 입력
-l : 사용자의 crontab 내용 리스트화
-r : 사용자의 crontab 모두 삭제
-e : 입력하면 crontab 수정 창에 들어가는데 그 곳에 Cron 표현식을 입력 후 :wq를 통해 crontab 갱신

◎ at

크론은 Cron 표현식에 따라 정해진 주기로 작업을 실행시키는 것이었다.

at은 주기적으로 작업을 실행시키는 것이 아닌 지정된 한 순간에만 실행될 작업을 예약하는 명령어이다.

사용 방법은 아래와 같다.

at [시간]

이때 시간을 "3:00am, 11:00pm" 등 직접 시간을 적어도 되며 "now +1 hours"와 같이 지금부터 1시간 후에 실행시키게 할 수도 있다.

이렇게 at과 시간을 입력하면 이후 "at>" 구문이 출력될 것이다.

"at>" 이후에 실행시키고 싶은 명령들을 모두 입력한 뒤 "Ctrl + D"를 통해 저장한다.

이후 지정한 시간이 된다면 설정했던 명령들이 모두 실행된다.

◎ anacron

cron과 유사하지만 시스템이 꺼져 있을 경우 해당작업이 정해진 시간에 수행되었는지를 확인한 뒤 수행한 적이 없으면 실행시킨다는 차이점이 존재한다.

즉, Cron과 같은 작업 스케줄러이지만 시스템이 계속 켜져있지 않아도 작동하는 것이다.

디스크 쿼터

VioletEvgadn — Mon, 10 Apr 2023 22:19:55 +0900

디스크 쿼터

◎ 디스크 쿼터(Quota)란?

Quota를 직역하면 "한도"라는 의미를 가진다. 즉, 디스크 쿼터란 디스크 한도라는 의미를 가질 것이다.

디스크 쿼터란 파일 시스템 별로 사용자나 그룹에게 특정 기준에 따라 디스크를 할당하는 것을 말한다.

디스크 쿼터를 사용하여 사용자나 그룹별로 디스크 공간 사용을 제한할 수도 있고 파일 시스템 별로 레벨 제한을 걸 수 있어 보안적인 측면으로도 활용할 수도 있다.

이런 측면에서 디스크 쿼터는 파일 서버에 매우 유용한 방식이다.

디스크 쿼터가 필요한 이유에 대해 예시를 하나 들어보자.

서버에는 다수의 유저가 파일을 올리거나 글을 쓸 수 있다. 그런데 만약 어떤 사용자가 1TB 크기의 파일을 서버에 올렸다고 가정하자. 해당 서버를 설정할 때 작은 크기의 파일만 올린다고 가정하여 500 GiB 정도의 스펙만 할당했다면 스펙보다 더욱 큰 파일이 등록되었으므로 시스템이 마비될 것이다.

이런 상황을 방지하기 위해 파일 시스템별로 사용자나 그룹에게 디스크 할당량을 적용한 것이 디스크 쿼터인 것이다.

리눅스에서는 디스크 쿼터에 대한 제한 기준으로 "파일 크기(Blocks)"나 "파일 개수(Inodes)"를 설정한다.

파일 크기의 경우 1사람당 1GiB까지만 올릴 수 있다는 설정이고 파일 개수는 1 사람이 최대 3개 파일만 올릴 수 있다 정도의 설정이다.

◎ 디스크 쿼터 Limit 종류

Hard Limit

Hard Limit은 설정한 Limit을 넘길 경우 바로 사용자는 서버에 Write가 불가능해진다.

사용자는 서버에 Write를 할 수 없기 때문에 파일을 삭제하는 등의 방식을 통해 사용할 수 있는 공간을 늘려야 한다.

Soft Limit

Soft Limit은 설정한 Limit을 넘기더라도 사용자는 계속해서 파일 시스템에 Read/Write가 가능하다.

대신 서버는 사용자에게 경고 메시지를 띄우며 동시에 타이머를 시작한다.

이 타이머를 "Grace Time/period"라고 하는데 이 타이머의 시간이 모두 지난다면 Soft Limit에서 Hard Limit으로 변환된다.

따라서 타이머가 종료되기 전 사용자는 파일 삭제나 파일 요약, 압축 등을 통해 사용할 수 있는 공간을 늘려야 문제없이 서버에 파일을 계속해서 등록할 수 있을 것이다.

Disk Quota 구성

1. 파티션 생성 & 마운팅

사용자에게 할당하고 싶은 만큼의 용량을 가진 파티션을 생성하고 마운팅 시키자.

필자는 /dev/sdg1을 /quota에 마운팅 시켰다.

2. 쿼터를 적용할 사용자 생성

3. /etc/fstab 설정

/etc/fstab에 아래 내용을 추가해준다.

/dev/sdg1  /quota  ext4   defaults,usrjquota=aquota.user,jqfmt=vfsv0 1 2

아마 /dev/sdg1, /quota, ext4, defaults, 1, 2의 의미는 알 것이다.

리눅스 쿼터를 위해 추가로 입력해야 하는 값은 "usrjquota=aquota.user,jqfmt=vfsv0" 문구이다.

3. 파티션 리마운트

mount -o remount /quota

위에서 지정한 마운트 디렉터리로 리마운트 시켜주자.

/etc/fsatb 파일을 수정한 뒤 재부팅이나 리마운트를 해야 설정이 적용되기 때문이다.

4. Quota DB 생성

이젠 디스크 쿼터 설정 정보를 저장할 파일을 만들어야 한다.

이를 위해 입력해야 하는 명령어는 아래와 같다.

# Quota 관련 파일 생성
touch aquota.user

# 관리자만 설정 파일에 접근할 수 있도록 설정
chmod 600 aquota.user

# Quota 지정이 가능한지 확인
quotacheck -augmn

# 디스크 쿼터 On
quotaon -avug

5. 사용자별로 공간(쿼터) 할당

edquota -u [사용자 Username]

필자는 위에서 생성한 "user1"에게 할당할 것이므로 "edquota -u user1"을 입력할 것이다.

Filesystem : 쿼터를 적용할 파티션
blocks : 현재 사용자(user1)가 사용하는 블록(KB)
inodes : 현재 사용자(user1)가 사용하는 파일 개수
soft, hard : Blocks나 Inodes에 대한 소프트 한도와 하드 한도
- blocks 옆에 있는 soft와 hard는 Block에 대한 한도, inodes 옆에 있는 soft와 hard는 Inodes에 대한 한도

필자는 Blocks 중 soft에 10240(10MB), hard에 20480(20MB)을 할당해 보겠다.

이후 "ctrl + X"키를 누른 뒤 "Y"를 통해 저장하고 엔터를 눌러주면 설정 사항이 적용된다.

6. 쿼터 설정을 한 사용자로 로그인 & 확인

이젠 쿼터 설정을 한 사용자로 로그인해 보자.

이후 파일 하나를 만들어준 뒤 "quota" 명령어를 통해 디스크 쿼터 설정이 제대로 적용되었는지 확인해 보자.

정상적으로 적용되었음을 확인할 수 있다.

혹시 모르니 다시 root 계정으로 접속한 뒤 "repquota -a" 명령을 통해 설정이 제대로 적용되었는지 확인해 보자.

성공적으로 적용되었다.

7. 20480(20MB)을 넘기는 파일 저장해 보기

필자는 user1 사용자로 접속한 후 "/boot/initrd.img-5.15.0-58-generic"라는 파일을 복사하여 20MB를 넘기는 파일을 저장해 보겠다.

"Disk quota exceeded". 즉 설정한 디스크 할당량을 넘긴 파일을 저장하려 했으므로 파일을 복사하지 못했음을 확인할 수 있다.

◎ Userquota들의 Gracetime 설정 변경

edquota -ut

기본 설정은 Block & Inode 모두 7일로 되어 있지만 사용자가 원하는 기간으로 재설정할 수 있다.

RAID와 LVM

VioletEvgadn — Mon, 10 Apr 2023 22:14:41 +0900

RAID

◎ RAID란?

RAID는 Redundant Array of Inexpensive Disks의 약자로써 여러 개의 디스크를 하나의 디스크처럼 활용하는 방식이다.

RAID를 활용하면 비용을 절감할 수 있을 뿐 아니라 신뢰성과 성능을 향상할 수도 있다.

RAID는 하드웨어 RAID와 소프트웨어 RAID가 존재한다.

하드웨어 RAID는 여러 개의 하드디스크를 하나의 장비로 묶어 공급하는 것이다. 이 방식은 안정적이기는 하지만 상당히 고가의 장비를 구입해야 한다.

소프트웨어 RAID는 OS에서 지원하는 방식으로 여러 개의 저렴한 디스크를 연결하여 디스크 총량을 늘리는 방식이다.

고가의 하드웨어 RAID의 대안으로 조금의 에러나 디스크 낭비는 허용한다.

◎ RAID 종류

Linear RAID

2개 이상의 하드디스크를 1개의 볼륨으로 사용하는 방식이다.

앞 디스크부터 차례로 저장하는 RAID 방식인데, 단순히 여러 개의 하드디스크를 1개의 볼륨으로 묶었을 뿐 특별한 로직은 존재하지 않는다.

100%의 공간효율성을 보여주는 RAID 방식으로 비용이 저렴하다.

RAID 0

모든 디스크에 데이터가 동시에 저장되는 방식으로 Linear RAID와 같이 100%의 공간효율성을 보이는 RAID 방식이다.

공간효율성이 100%이므로 비용이 저렴하다.

RAID 0는 모든 디스크에 데이터가 동시에 저장되기 때문에 데이터를 저장하는 속도가 빠르다.

하지만 RAID 0는 신뢰성이 낮은데 만약 어떤 디스크에 저장된 데이터가 파괴되거나 변형되었을 경우 원래 데이터로 복원할 방법이 없기 때문이다.

따라서 빠른 성능을 요구하되 데이터가 소실되어도 큰 문제가 되지 않는 자료를 저장할 때 적합한 RAID 방식이다.

RAID 1

미러링(Mirroring)이라고 부르는 방식으로 데이터 손실을 대비하여 여려 디스크에 동일한 데이터를 저장해 놓는 RAID 방식이다.

이를 "결함 허용(Fault-tolerance)"라고 하는데 이 때문에 RAID 1은 신뢰성이 높은 방식이다.

하지만 데이터 저장을 2번 수행하므로 저장 공간이 2배로 필요하며 디스크 비용 또한 2배가 될 것이다.

즉, 공간 효율성이 나빠진다는 것인데 데이터 저장은 Linear RAID 방식과 동일하므로 속도는 변함이 없다.

공간 효율성이 나쁘고 속도는 느리지만 데이터 안정성이 보장되므로 중요한 데이터를 저장하는데 적합한 방식이다.

RAID 5

RAID 1의 데이터 안정성과 RAID 0의 좋은 공간 효율성을 동시에 챙기기 위해 고안된 방식으로 최소 3개의 하드디스크가 필요하다.

RAID 5는 "패리티(Parity)"라는 것을 활용하여 데이터를 복구한다.

짝수 패리티에서는 1의 개수가 짝수개, 홀수 패리티에서는 1의 개수가 홀수 개 되도록 하는 방식으로 새로운 비트 자리를 하나 추가하여 데이터 안정성을 확보하는 방식이다.

예를 들어 2번째 패리티의 데이터가 "1 0"이 저장되어 있다면 짝수 패리티에서 1의 개수가 홀수 개이므로 데이터에 문제가 있다는 것을 파악할 수 있다.

여러 개의 디스크 중 하나는 Parity를 위한 공간이므로 데이터 저장을 위해 "디스크 개수 -1"개의 공간을 활용할 수 있다.

단지 RAID 5 방식 같은 경우 디스크가 2개 이상 고장 날 경우에는 복구가 불가하다는 단점이 존재한다.

RAID 6

RAID 6 방식은 RAID 5 방식을 개선시킨 것이다.

공간 효율성은 RAID 5 방식보다 떨어지지만 2개 이상의 데이터가 동시에 고장나더라도 복구가 가능하도록 만들어주는 방식이다. 이를 위해 RAID 5는 최소 4개의 하드디스크가 필요하다.

성능(속도)과 공간 효율은 RAID 5에 비해 살짝 떨어지지만 데이터의 신뢰도는 더 높은 방식이다.

RAID 1+0

RAID1 방식과 RAID 0 방식을 결합한 방식으로 신뢰성과 성능을 동시에 높인 방식이다.

LVM

◎ LVM이란?

여러 개의 하드디스크를 합쳐 한 개의 파일 시스템으로 활용하는 것을 말한다.

이것만 보자면 RAID와 다른 점이 없어보이지만 LVM만의 특징이 존재하는데, 바로 필요에 따라 합친 하드디스크 용량을 재분할할 수 있다는 것이다.

예를 들어 2TB 하드디스크 2개를 합쳤을 경우 LVM에서는 이를 1TB와 3TB의 논리적 구조로 재분배시킬 수 있는 것이다.

LVM에서 사용되는 용어는 아래와 같다.

Physical Volume : 실제 하드디스크를 통해 설정한 파티션(ex. /dev/sda1, /dev/sdb1 등)
Physical Extents : 실제 데이터가 저장되는 공간. 하드디스크라고 생각하면 된다.
Volume Group : 물리 볼륨을 합쳐 1개의 물리 그룹으로 만드는 것
Logical Volume : Volume Group을 1개 이상으로 나눈 후 나뉜 영역
- ex. 2TB 하드디스크 2개를 1개의 Volume Group으로 묶은 뒤 1TB와 3TB의 Logical Volume으로 재분배가 가능

출처 : https://sgbit.tistory.com/12

Linear RAID 구축

0. 하드디스크 2개 추가 & fdisk를 통해 파티션 설정

1GB 하드디스크 2개를 추가했다.

# /dev/sdb & /dev/sdc 파티션 추가
fdisk /dev/sdb
fdisk /dev/sdc

여기에서 마운팅을 수행하지 말고 바로 RAID 단계로 넘어가야 한다.

RAID에 대해 이해했다면 알 수 있겠지만 RAID는 여러 개의 하드디스크를 1개의 논리적 볼륨 그룹으로 묶는 것을 말한다.

즉, 파티션으로 설정한 /dev/sdb1과 /dev/sdc1을 1개의 볼륨 그룹으로 묶음으로써 Linear RAID를 구축할 수 있는 것이다.

1. 논리 볼륨으로 2개 파티션 묶기

mdadm --create [RAID 이름] --level=[RAID 형태] --raid-devices=[묶을 파티션 개수] [파티션 리스트]

여러 개의 파티션을 1개의 논리적 볼륨으로 묶는 명령어는 위와 같다.

이 때 --level에 입력해 주는 값에 따라 RAID 1 방식으로 묶일 수도 있고 RAID 0 방식으로 묶일 수도 있을 것이다.

우리는 "/dev/sdb1"과 "/dev/sdc1" 총 "2개"의 파티션으로 "/dev/md0"라는 이름의 "Linear RAID"를 만들 것이므로 아래와 같은 명령어를 입력하면 될 것이다.

mdadm --create /dev/md0 --level=linear --raid-devices=2 /dev/sdb1 /dev/sdc1

2. 마운트

mdadm을 통해 RAID 논리 볼륨을 생성했다면 이젠 mkfs를 통해 파일 형식을 설정해 준 뒤 Directory에 마운트 시켜주면 된다.

# 파일 형식 설정
mkfs.ext4 /dev/md0

# Directory 생성 & 마운팅
mkdir /raidLinear
mount /dev/md0 /raidLinear

만약 재부팅 이후에도 이 설정을 유지하고 싶다면 /etc/fstab에 내용을 추가해주면 된다.

3. Linear RAID 생성 결과

가장 마지막 줄을 보면 /dev/md0라는 파일 시스템이 형성되었음을 알 수 있다.

우리는 분명히 1GB짜리 하드디스크 2개만 추가했다. 하지만 /raidLinear와 마운팅된 RAID는 2GB의 크기를 가짐을 알 수 있다.

즉, 우리가 원하는대로 여러 개의 하드디스크를 묶어 1개의 RAID로 만들어졌음을 알 수 있다.

RAID 1, RAID 0, RAID 5 등 또한 유사한 과정으로 수행하되 요구되는 최소 하드디스크가 있을 경우에만 주의해 주면 정상적으로 RAID 시스템을 구축할 수 있다.

◎ 설정한 RAID 정보 보기

mdadm --detail [설정한 RAID 이름]

LVM 파일 만들기

0. 하드디스크 2개 추가 & fdisk를 통해 파티션 설정

위에서 했던 설정과 같으므로 설명은 생략하겠다.

1. 각 파티션에 대한 물리적 볼륨 생성

위에 나온 LVM 이미지를 보면 알 수 있겠지만 LVM 구성에 가장 선행되어야 하는 것은 파티션에 대한 물리적 볼륨을 생성하는 일이다.

그 명령어는 아래와 같다.

pvcreate [파티션 이름]

"pvscan"이나 "pvdisplay" 명령어를 통해 PV(물리적 볼륨)이 제대로 생성되었는지 확인이 가능하다.

2. 볼륨 그룹으로 묶기

pvcreate를 통해 파티션에 해당하는 PV를 생성했다면 이제는 생성한 PV들을 1개의 볼륨 그룹(VG)로 묶어야 한다.

명령어는 아래와 같다.

vgcreate [VG 이름] [PV 리스트]

마찬가지로 "vgscan"이나 "vgdisplay" 명령을 통해 VG가 제대로 생성되었는지 확인할 수 있다.

필자는 "lvmVg"라는 VG를 "/dev/sdd1"과 "/dev/sde1" PV를 통해 만들 것이다.

3. 논리적 볼륨(LV)로 나누기

LVM의 꽃인 단계라고 할 수 있겠다. LVM의 가장 큰 특징은 하드디스크 여러 개를 1개의 VG로 묶은 뒤 이를 관리자 마음대로 재분배할 수 있다는 것이다. 그리고 이 용량 재분배는 1개의 VG를 여러개의 LV로 나눔으로써 수행할 수 있는 것이다.

LV로 나누는 명령어는 아래와 같다.

lvcreate -L [LV 사이즈] -n [LV 이름] [VG 이름]

여기에서 재미있는 것이 있는데 바로 -L 옵션이다.

-L 옵션으로 지정할 경우 우리가 늘 보는 KB, MB, GB, TB로 LV의 사이즈를 정한다.

하지만 만약 -l 옵션으로 지정할 경우 VG 내에서 값으로 준 수치의 %만큼의 사이즈를 가지게 된다.

-l 옵션의 가장 재미있는 값은 "100%FREE"이다.

100%FREE라는 값을 줬을 경우 VG의 남아있는 용량 전체를 LV의 사이즈로 지정할 수 있다.

우리는 1GB짜리 하드디스크 2개를 합쳤으므로 VG는 총 2GB의 크기를 가지고 있을 것이다.

그럼 1.5GB를 "data"라는 LV로, 0.5GB를 "backup"이라는 LV로 만들어보자.

명령어는 아래와 같을 것이다

# data LV 만들기
lvcreate -L 1500M -n data lvmVg

# backup LV 만들기
lvcreate -L 100%FREE -n backup lvmVg

이젠 "lvscan" 명령을 통해 실제 LV 설정이 어떻게 되었는지 확인해 보자

우리는 1GB짜리 하드디스크 2개를 합쳤지만 LVM에 의해 /dev/lvmVg/data에 1.5GB가 할당되었음을 알 수 있다.

4. LV에 파일 시스템 설정 & 마운팅

이 과정은 너무 많이 했으니 명령어만 설명하겠다.

mkfs.ext4 /dev/lvmVg/data
mkdir /data
mount /dev/lvmVg/data /data/

◎ LVM 관련 추가 명령어

# LV가 Clean한지(데이터가 저장되어 있는지) 확인
fsck -y /dev/[VG 이름]/[LV 이름]

# LV에 할당된 공간을 입력한 용량만큼 증가시킴
lvextend -L +[용량] /dev/[VG이름]/[LV 이름]

# VG에서 사용할 수 있는 공간을 확인
vgdisply -v

# LV 삭제
lvremove [LV 이름]

# VG 삭제
vgremove [VG 이름]

# PV 삭제
pvremove [PV 이름]

디스크 관리

VioletEvgadn — Wed, 5 Apr 2023 12:13:32 +0900

리눅스 파티션

◎ 리눅스 파티션이란?

하드 디스크 드라이브의 기억 공간을 별도의 데이터 영역으로 분할하는 것을 말한다.

이렇게 디스크를 분할하는 이유는 디스크의 공간을 나눠 사용 목적과 용도에 따라 고유한 디스크를 사용하기 위함이다.

분할된 디스크 공간은 다른 디스크 공간에 간섭할 수 없기 때문에 디스크 영역에 따라 수행하는 역할을 다르게 한다면 특정 디스크 공간은 안전하게 자신의 역할을 수행할 수 있게 될 것이다. 또한 보호 목적으로도 파티션을 나누어 사용한다.

◎ 리눅스 파티션 종류

Primary Partition(주 영역 파티션)
- 1개의 디스크에 최대 4개의 주영역 파티션을 만들 수 있음
Extend Partition(확장 파티션)
- 1개의 디스크에 하나의 확장 파티션만 만들 수 있음
- 4개의 주 영역 파티션만으로는 안정성 등의 이유로 개수가 부족하다. 따라서 아래에서 설명할 논리 영역 파티션을 활용하는데, 이 논리 영역 파티션을 담을 수 있는 그릇 역할을 하는 것이 확장 파티션이다.
- Primary Partition을 구성하고 남은 공간으로 설정
Logical Partition(논리 영역 파티션)
- 확장 파티션 안에 만들 수 있는 파티션
- 파티션 개수가 15개만 넘지 않으면 자유롭게 생성할 수 있긴 하나 12개 이상의 파티션을 만드는 것은 시스템에 좋지 않으므로 적절히 설정해야 함
- Primary Partition과 달리 명령을 실행시킬 수는 없으 단순히 데이터만 저장할 수 있음

◎ 장치 파일(Device File) 이름 생성 기준

이전에 리눅스에서는 모든 하드웨어를 마운트를 통해 디렉터리 형태로 관리한다고 설명했다.

그렇다면 하드웨어는 어떠한 디렉터리와 대응되는 것일까?

장치 파일은 디스크의 종류에 따라 대응될 디렉터리가 정해져 있다.

예를 들어 IDE 디스크의 경우 /dev/hdX이며 SCSI 디스크의 경우 /dev/sdX와 대응된다.

맨 끝에 붙은 X에는 디스크 개수에 따라 a부터 z까지 붙여준다.

예를 들어 IDE 디스크가 1개 있을 경우 /dev/hda만 존재할 것이고 SCSI 디스크가 2개 있을 경우 /dev/sda와 /dev/sdb로 장치 파일이 구성될 것이다.

이렇게 하드웨어를 장치 파일과 연결시켰다 하더라도 끝이 아니다.

위에서 말했듯 리눅스에선 디스크 파티션을 통해 디스크를 몇 개의 영역으로 나눌 수 있기 때문에 이 파티션 영역을 구분할 수 있어야 한다.

따라서 리눅스 서버는 파티션 영역을 구분하기 위해 정해진 장치 파일 뒤에 숫자를 붙여 파티션 영역을 구분하게 된다.

예를 들어 /dev/hda 디스크를 2개 파티션으로 나눌 경우 /dev/hda1과 /dev/hda2로 나누어 구분하는 것이다.

◎ 파티션 분할이 필요한 디렉터리

루트 파티션(/)
- 핵심 기능들이 보호되도록 다른 파일 시스템과 분리해 놓는 것이 좋음
/boot 파티션
- 리눅스 커널 이미지, 맵, 파일 등 커널이 저장되어 있는 디렉터리
/var 파티션
- /var 파티션은 Spool 디렉터리(메일, 프린트 등)와 로그 파일을 저장함
- /var 파티션에서는 계속해서 정보가 추가되거나 수정사항이 발생하므로 매우 큰 파일이 생길 수 있기 때문에 파티션 분할이 필수적이다.
/home 파티션
- 사용자의 홈 디렉터리를 위한 파티션으로 사용자가 서버에 접근하는 목적에 따라 구분하기 위하여 파티션을 분리하는 것이 좋음
/swap 파티션
- 가상 메모리를 저장하는 파티션
- 보통 RAM 크기의 2배로 사용함
/tmp 파티션
- 사용자 응용 프로그램에서 임시 파일을 저장하는 곳으로 사용되는 파티션
- 매우 큰 임시 파일이 생기거나 보안상 문제가 생길 수 있으므로 별도의 파티션으로 분리하는 것이 좋음

마지막으로 위에 설명한 파티션 분할이 필요한 디렉터리들을 고려하여 디스크 파티션을 구성한 예시 이미지를 확인하자.

◎ 마운트

하드 디스크를 추가하여 사용하기 위해선 마운트 과정이 필수적으로 필요하다.

그렇다면 "마운트"란 무엇일까?

리눅스에서는 하드웨어를 모두 디렉터리 형태로 관리하고 있는데 리눅스에서 하드디스크 파티션, CD/DVD, USB 메모리 등을 사용하기 위해선 특정 디렉터리에 연결을 시켜줘야 한다.

이렇게 물리적 장치를 특정 위치(대부분 디렉터리)에 연결시켜 주는 과정을 마운트라고 한다.

출처 : https://sksstar.tistory.com/7

위 그림을 통해 마운트를 설명한 사이트가 마운트를 가장 이해하기 쉽게 표현했다고 생각해서 가지고 왔다.

만약 필자의 설명이 이해가 되지 않는다면 위 사이트에 들어가 설명을 읽어보자.

물리적 장치 = 기차, 마운트 디렉터리(하드웨어와 연결된 디렉터리) = 서울역, 데이터 = 홍길동이다.

기차는 서울역에 정차했다. 이제 기차는 서울역에서 사람을 태울 수 있는 상태가 되는 것이다.

이때 홍길동이라는 사람이 후다닥 뛰어와서 서울역에 정차한 기차에 탔다. 이럼 결과적으로 "서울역에 정차한 기차는 홍길동을 태웠다"라는 결과로 이어질 것이다.

이를 리눅스의 마운팅 시스템에 비롯해 이해해 보자.

물리적 장치(기차)는 마운팅 디렉터리(서울역)와 연결되었다.(도착했다)

이제 물리적 장치는 마운팅 디렉터리에 저장한 데이터(홍길동)를 가져올 수 있는 상태가 되는 것이다.

이런 상황에서 마운팅 디렉터리에 데이터가 저장된다면 마운팅 디렉터리는 물리적 디스크와 마운팅 되어 있으므로 데이터는 마운팅 디렉터리를 거쳐 하드웨어에 저장되는 것이다.

그렇다면 조금 심화 과정에 들어가 보자. 만약 마운팅이 풀리면 그때 저장된 데이터는 어떻게 될까?

홍길동을 태운 기차가 서울역을 떠나 대전역에 도착했다고 가정해 보자. 그럼 홍길동은 없어진 것일까?

아니다. 홍길동이라는 사람은 여전히 기차 내에 존재하나 서울역에서는 찾지 못하고 대전역에서 찾을 수 있는 것이다.

마운팅 시스템에서도 동일하다.

원래 마운팅 되었던 디렉터리(서울역)와 하드웨어를 언마운트시킨 뒤 새로운 디렉터리(대전역)에 하드웨어를 새로 마운트 시켰다 가정해 보자.

이 과정에서 계속 하드웨어 기기(기차)에는 데이터가 저장되어 있을 것이다. 단지 저장되어 있는 데이터를 실제로 찾기 위해선 이전 마운팅 디렉터리(서울역)가 아닌 새롭게 마운팅 된 디렉터리(대전역)를 뒤져야 하는 것이다.

Virtual Machine에서 하드디스크 추가

1. 원하는 서버 마우스 오른쪽 클릭 > Settings 선택

2. Add > Hard Disk 선택 후 원하는 용량 설정

참고로 필자는 SCSI로 5GB 정도의 하드디스크를 추가했다.

3. 디스크 추가 여부 확인

fdisk -l

리눅스에서 위 명령어를 치면 물리적으로 장착된 디스크 정보를 확인할 수 있다.

현재 필자는 5GB의 SCSI 하드디스크를 달았고 이미 SCSI 하드디스크가 존재하고 있던 상태였기 때문에 /dev/sdb가 추가되어야 할 것이다.

5GB /dev/sdb가 정상적으로 추가되었음을 알 수 있다.

(추가로 /dev/sda, 즉 원래 존재하던 하드 디스크는 3개의 파티션으로 구성되었음을 알 수 있다)

4. 추가한 디스크에 대하여 파티션 설정 모드 진입

fdisk [추가한 디스크 장치명]

3번 과정에서 추가한 하드디스크가 /dev/sdb 장치 파일 이름을 가졌으므로 /dev/sdb를 입력했다.

파티션 설정 모드에서 자주 활용되는 Command는 아래와 같다.

d : Delete Partition. 파티션 삭제
n : Add a New Partition. 파티션 추가
w : 설정한 파티션 값 저장
- 제일 중요한 Command이다.
- w를 입력하지 않고 파티션 설정 모드에서 빠져나온다면 그동안 설정했던 내용들이 모두 적용되지 않고 날아갈 것이다.
p : 현재까지
수행한 파티션 설정 확인

우리는 파티션을 추가할 것이기 때문에 Command에 n을 입력해 보자.

5. 파티션 추가

일단 Command로 n을 입력하여 새로운 파티션을 추가시켰다.

우리가 추가시킬 파티션은 Primary Partition이기 때문에 p를 입력해 준다.

그럼 Partition Number를 지정하는데, 위에서 배웠듯 1개 디스크당 4개의 Primary Partition밖에 생성할 수 없으므로 1-4 중 1개의 값을 선택하도록 나와 있다.

이후 First Sector와 Last Sector는 Primary Partition의 시작 부분과 끝 부분을 의미하는데, 이를 통해 파티션 크기를 지정할 수 있다. 필자는 디폴트 값을 활용하기 위하여 아무 값도 입력하지 않고 엔터를 쳤다.

Last Sector에는 파티션 마지막 값을 입력하지 않고 설정할 파티션 크기를 "+256M" 처럼 입력해도 된다.

설정이 완료되어 p를 입력해 보았다.

/dev/sdb가 /dev/sdb1로 변경됨으로 파티션이 수행되었음을 확인할 수 있다.

이젠 "w"를 입력하여(진짜 중요하다) 설정 사항을 반영한 뒤 파티션 설정 창을 벗어나자.

6. 파티션 시스템 설정

이제 파티션은 생성되었다.

하지만 리눅스에서 파티션을 활용하기 위해선 리눅스 시스템에 맞게 파일 시스템 설정을 수행해야 한다.

파일 시스템 설정 한다는 것에 대한 의미가 어려울 수 있는데, 쉽게 말하자면 생성된 파티션의 포맷을 미리 정해져 있는 규격에 맞춤으로써 실제로 활용할 수 있게 만들어주는 것이다.

파티션을 만드는 것은 내가 가진 땅에서 건물을 지을 부분을 분리해 놓는 작업을 말하며 파티션 시스템 설정은 분리된 땅에 건물을 내가 원하는 목적으로 사용하기 위해 규격에 맞춰 건물을 짓는 작업이라고 할 수 있겠다.

리눅스 파일 시스템에는 여러 가지가 있고 그중 대표적으로 아래 3가지가 존재한다.

FAT32 : 윈도우와 리눅스 범용적으로 사용할 수 있는 파일 시스템. 대용량 NTFS 파일 시스템 이하의 환경에서만 동작 가능
ext : 현재 사용 X
ext2 : 긴 파일의 시스템 이름 지원
ext3 : 보안 부분이 조금 향상된 기본 파일 시스템.
ext4 : 대형 파일 시스템을 지향하는 목적으로 개발된 파일 시스템. ext3 단점을 많이 보완했으며 현재까지 개발 중에 있는 파일 시스템

필자는 ext4 파일 시스템으로 파티션 시스템을 설정하겠다.

mkfs.ext4 [partition_name]

위 사진에서 파티션 이름은 "/dev/sdb1"이므로 이 값을 입력해 주면 될 것이다.

7. 파티션 마운트

파티션 시스템을 설정했다면 이젠 설정이 끝난 하드웨어를 실제로 활용할 수 있도록 파티션을 디렉터리와 마운트 시켜야 한다.

일단 디렉터리를 만들자

# 디렉토리 생성
mkdir /mount_dir

# 디렉토리 권한 수정
chmod 777 /mount_dir

이제 생성한 /mount_dir에 파티션(/dev/sdb1)을 마운트 시키자.

mount 명령어 사용법은 아래와 같다.

mount [하드웨어 기기] [마운팅할 디렉터리]

현재 하드웨어 기기는 디스크 파티션(/dev/sdb1)이며 마운팅 할 디렉터리는 생성한 /mount_dir이므로 아래 사진과 같이 입력하면 될 것이다.

마지막으로 "df -h" 명령어를 통해 리눅스 시스템 전체의 마운트 된 디스크 사용량을 확인해 보자.

빨간색 네모에 쓰여 있는 문구를 통해 마운트가 성공적으로 완료되었음을 확인할 수 있다.

8. 부팅 시 자동 마운트하도록 설정

마지막 과정이다. 이를 수행하기 전 리눅스 서버를 껐다 킨 후 "df -h" 명령어를 입력해 보자.

어라? 설정해 놨던 /dev/sdb1이 없어졌음을 확인할 수 있다.

이전에 Linux 부팅 과정을 설명하며 Kernel 단계 수행 과정에 대해 설명한 적이 있다.

이 중 7번 Init Process를 호출하는 과정이 존재했는데 Init 프로그램은 다양한 Daemon을 생성하고 /etc/fstab 파일에 지정된 모든 Partition을 마운트 시키는 역할을 담당한다고 말했다.

우리는 이 설명을 통해 하드웨어(디스크 파티션)가 마운팅 디렉터리와 마운트 되는 것은 컴퓨터에 물리적으로 저장되어 있는 것이 아니라 /etc/fstab 파일 설정에 따라 OS가 마운팅 시킴으로써 리눅스에서 하드웨어를 사용할 수 있게 한다는 것을 알 수 있다.

하지만 우리가 위에서 지정한 /dev/sdb1은 우리가 임의대로 지정한 디스크 파티션 및 마운트 상태일 뿐 OS 입장에서는 /etc/fstab 파일에 존재하지 않는 설정이므로 부팅 과정에서 자동 마운트가 수행되지 않을 것이다.

따라서 재부팅을 시키면 /dev/sdb1 마운트 설정은 없어지게 되는 것이다.

이렇게 될 경우 시스템을 재부팅시킬 때마다 /dev/sdb1과 /mount_dir을 수동으로 마운트 시켜줘야 한다는 것인데 이는 너무 귀찮다.

따라서 부팅 시 /dev/sdb1도 자동 마운트 되도록 /etc/fstab 파일에 마운트 설정을 추가해 주자.

/etc/fstab 파일을 VI 에디터로 연 다음 아래 문구를 마지막에 추가해 주자

/dev/sdb1 /mount_dir ext4 defaults 1 2

만약 파티션이나 마운팅 디렉터리 이름을 다르게 설정했거나 파티션 시스템 설정이 ext4가 아니면 그에 맞춰 위 문구를 수정하면 된다.

defaults, 1, 2의 의미는 아래에서 자세히 알아보자.

이후 파일 수정을 완료하고 다시 리눅스 서버를 재시작시켜보자.

/dev/sdb1이 정상적으로 마운팅 되었음을 알 수 있다.

기타 내용

◎ UUID

사람보다는 컴퓨터를 위해 만들어진 값으로 디바이스 명이 바뀌더라도 정상 작동하도록 설정하는 값이다.

간단히 컴퓨터 디바이스의 고유 주소값이라 생각하면 편하다.

"blkid"나 "ls -l /dev/disk/by-uuid" 명령을 통해 디스크 파티션들의 UUID를 확인할 수 있다.

◎ /etc/fstab 구성

[디스크 파티션(하드웨어)] [마운팅 디렉터리] [파일시스템 종류] [옵션] [덤프] [파일체크옵션]

디스크 파티션, 마운팅 디렉터리, 파일시스템 종류는 위에서 설명한 그대로이다.

덤프

0 : 백업을 수행하지 X
1 : 백업 가능한 파일 시스템

파일체크옵션

루트 파일 시스템을 점검할 때 사용한다.

0 : 부팅 시 파일 시스템을 점검하지 X
1 : 루트 파일 시스템으로써 부팅 시 파일 시스템 점검을 한다.
- /부분을 체크 후 부팅
2 : 루트 파일시스템 이외의 파일 시스템으로써 부팅 시 파일시스템 점검을 한다.
- /를 제외한 나머지 파티션 체크 후 부팅

옵션

defaults : rw, suid, exec, auto, nouser 옵션을 모두 선택한 것과 같다.
rw : Read & Write 허용
suid : SetUID와 SetGID 사용을 허용
exec : 실행 파일이 실행되는 것을 허용
auto : 부팅 시 자동 마운트. 이 설정 때문에 부팅 과정에서 마운트가 가능해진다.
nouser : 일반 사용자 마운트 불가능. root만 가능
...

리눅스에서의 프로세스 관리

VioletEvgadn — Wed, 5 Apr 2023 10:28:27 +0900

ps

◎ 명령어 ps

ps는 현재 프로세스의 목록 및 상태를 확인하는 명령어이다.

ps는 단독으로 사용하기보다는 옵션, 특히 "-ef"라는 옵션을 붙여 활용하며, 서버 측에서 실행되고 있는 프로세스가 많을 것이기 때문에 grep을 활용하여 프로세스 리스트 중 원하는 프로세스를 찾는 방식으로 많이 활용한다.

ps [Option]

ps 옵션

-a : 데몬 프로세스처럼 터미널에 종속되지 않은 모든 프로세스를 출력
-u : 특정 사용자의 프로세스 정보를 확인할 때 사용. 사용자를 지정하지 않으면 현재 사용자를 기준으로 정보 출력
-x : 로그인 상태에 있는 동안 완료되지 않은 프로세서들을 보여줄 때 사용
- 유닉스 시스템에선 사용자가 로그아웃을 해도 프로세서가 계속 동작하게 할 수 있는데 이러한 터미널이 없음에도 실행되는 프로세서들을 -x 옵션을 통해 확인할 수 있음

-e : 커널 프로세스를 제외한 모든 프로세스를 출력
-f : 풀 포맷으로 모든 정보를 보여줌
- Unix 스타일로 출력해주는 옵션으로 UID, PID, PPID 등이 표시됨

-a, -u, -x와 -e, -f 사이를 띄어놓은 이유가 있는데 ps 명령어는 주로 "ps -aux"나 "ps -ef" 2개 중 1가지 방법으로 활용하기 때문이다. 사실 ps -aux도 거의 안 쓰이고 ps를 사용한다면 대부분 ps -ef로 사용한다.

ps aux : 시스템에 동작중인 모든 프로세스를 소유자 정보와 함께 BSD 포맷으로 출력
ps -ef : 시스템에 동작중인 모든 프로세스를 Full Format으로 자세히 출력

ps -ef 예시

ps -ef만 입력했을 때 내용이 너무 많아 보기 편하게 하기 위하여 "grep /usr/bin"을 통해 /usr/bin을 포함하고 있는 프로세스들만 출력했다.

◎ ps 테이블 항목

ps -aux 테이블 항목

USER : 프로세스 소유자 이름
PID : 프로세스 식별번호(Identifier)
%CPU : CPU 사용 비율의 추정치
%MEM : 메모리 사용 비율의 추정치
VSZ : K 혹은 페이지 단위의 가상 메모리 사용량
RSS : 실제 메모리 사용량
TTY : 프로세스와 연결된 터미널
- TTY 값으로 ?가 들어간 경우 백그라운드 프로세스임을 의미함
STAT : 현재 프로세스 상태 코드
START : 프로세스 시작 시간
TIME : 총 CPU 사용 시간
COMMAND : 프로세스 실행 명령

ps -ef 테이블 항목

UID : 프로세스 소유자 이
PID : 프로세스 식별 번호
PPID : 부모 프로세스의 식별 번호(부모 프로세스 PID)
C : 프로세스 우선 순위
STIME : 프로세스 시작 시간
CMD : 프로세스 실행 명령
TTY, TIME : 위에서 설명

kill

◎ 명령어 kill

명령어 kill은 프로세스를 강제로 종료하기 위해 사용되는 명령어이다.

"kill -l" 명령어를 통해 프로세스 시그널 종류를 출력할 수 있는데 한 번 확인해 보자.

위 시그널을 이해하기 위해선 kill의 사용법에 대해 먼저 알아야 한다.

kill -[시그널 번호] [PID]

위 사진에서 나타난 1부터 64까지의 시그널 번호는 kill 이후 옵션으로 줄 수 있는 값들을 의미하는 것이다.

조금 더 깊이 들어가 보자면 사실 kill 명령어는 프로세스를 강제로 종료하는 명령어가 아니다.

리눅스에서는 kill 명령어를 통해 프로세스를 지정한 뒤 신호(Signal)를 보내 제어할 수 있다.

이때 지정한 프로세스에 보내는 신호는 시그널 번호를 통해 지정할 수 있으며 시그널 번호에 따라 kill 명령어에 대한 프로세스 처리 방법 또한 달라짐을 유추할 수 있다.

추가적으로 만약 "kill -9" 명령어를 사용하고 싶다면 사실 "kill -SIGKILL"으로 시그널 번호가 아닌 시그널 정보를 직접 입력해 줘도 된다. 단지 이는 매우 불편하므로 시그널 번호를 입력하는 것이 거의 규격화된 것이다.

◎ 시그널 번호

대표적인 시그널은 아래와 같다. 하지만 굳이 외울 필요는 없고, 시그널 번호 9(SIGKILL)에 대해서만 잘 외워두자.

1(SIGHUP) : 실행 중인 프로그램이 사용하는 설정 파일을 변경시킨 뒤 변화된 내용을 적용할 때 사용
2(SIGNINT) : 현재 작동 중인 프로세스 동작을 멈출 때 사용
- "CTRL + C"와 동일한 역할 수행
9(SIGKILL) : 프로그램을 강제 종료할 때 사용
15(SIGTERM) : 실행 중인 프로세스를 정상적인 방법으로 종료시키는 신호
- kill 명령에서 신호를 지정하지 않을 경우 시그널 번호가 15로 지정되어 프로그램을 종료함(디폴트 번호)
- kill -9는 컴퓨터 기기의 전원 버튼을 눌러 강제 종료하는 것이고 kill -15는 시작 > 시스템 종료를 눌러 컴퓨터를 원래 방식대로 종료시키는 것으로 생각하면 된다.
20(SIGTSTP) : 실행 중인 프로세스를 중지하는 데 사용하는 신호
- "CTRL + Z"와 동일한 역할 수행
- -2는 "종료"시키는 것이고 -19는 "중지"시키는 것이다. 이는 생각보다 큰 차이인데 for문을 100번 돌리는 명령문에서 50번째에 "kill -2"를 입력하면 해당 프로세스는 종료될 것이지만 "kill -19"를 입력하면 50번째 for문에서 중지되었다가 실행 재개 신호를 주면 51번째 for문부터 계속해서 진행한다.
18(SIGCONT) : 정지된 프로세스를 재실행
- kill -19나 kill -20을 통해 정지된 프로세스를 다시 실행시킴

만약 특정 프로세스를 종료하고 싶을 경우 아래와 같이 명령어를 입력하면 될 것이다.

kill -9 [프로세스 PID]

프로세스 관련 기타 지식

◎ 서비스

서비스란 시스템과는 독자적으로 구동되어 제공하는 프로세스를 말한다.

즉, 처음 Linux를 구동시켰을 때는 없지만 설정이나 프로그램을 통하여 추가적으로 실행될 수 있는 프로세스를 말한다.

서비스는 대표적으로 웹 서버(httpd), DB 서버(mysqld), FTP 서버(vsftpd) 등이 존재한다.

서비스들은 ".service"라는 확장자명을 가졌으며 "/usr/lib/systemd/system" 디렉터리에 위치하고 있다.

가장 유명한 서비스는 아마 "httpd.service"가 아닐까 싶은데, HTTP Protocol을 지원하는 Daemon으로 HTML 파일을 전송할 수 있게 해주는 프로세스이다.

만약 httpd.service가 없다면 HTTP Protocol을 통해 클라이언트에게 HTML 파일을 보내줄 수 없으므로 웹 서버의 역할을 수행하지 못할 것이다. 따라서 리눅스를 웹 서버로 사용하기 위해선 무조건 httpd.service가 존재하고 실행되고 있어야 할 것이다.

서비스를 실행/종료/재시작시키는 방법은 아래와 같다.

# 서비스 시작
systemctl start [서비스이름]

# 서비스 종료
systemctl stop [서비스이름]

# 서비스 재시작
systemctl restart [서비스이름]

◎ 소켓

네트워크에 대해 공부했다면 소켓에 대해서도 이미 알고 있을 것이다.

리눅스에는 접속 대기 상태의 소켓이 이미 존재하고 있으며 항상 외부에서 커넥션 생성 요청이 오기를 기다리고 있을 것이다.

이 상태에서 외부에서 소켓에 서비스를 요청할 경우 systemd가 소켓을 구동한다.

네트워크에 빗대어 생각해 보자면 systemd가 접속 대기 상태의 소켓을 복사하여 새로운 소켓을 만든 뒤 커넥션을 생성하는 것이다.

이후 외부에서 요청이 끝나면 소켓도 종료될 텐데, 네트워크에 대해 공부했다면 알 수 있듯 접속 대기 상태의 소켓은 그대로 남아 있고 복사되어 외부 요청을 처리한 소켓이 종료되는 것이다.

소켓은 ".socket" 확장자명을 가지고 있으며 "/usr/lib/systemd/system" 디렉터리에 저장되어 있다.

◎ 백그라운드 프로세스 확인

현재 실행되고 있는 백그라운드 프로세스들 출력

jobs

백그라운드 프로세스 중 n번째 프로세스를 포그라운드 프로세스로 상태 변경

fg %n

백그라운드 프로세스를 포그라운드로 가지고 와 프로세스가 끝날 때까지 프로세스 수행 내용을 출력시키는 것이다.

포그라운드 프로세스 중 n번째 프로세스를 백그라운드 프로세스로 상태 변경

bg %n

◎ top

프로세스 목록 중 CPU 사용률이 높은 것부터 차례로 출력하는 명령어로 일정 시간마다 목록이 업데이트된다.

PID : 프로세스 식별자
User : 프로세스 소유자의 Username
PR : 우선순위. 20이 가장 높고 -20이 가장 낮다.
NI : 마이너스를 가지는 프로세스는 우선순위가 높음
VIRT : 가상 메모리 사용량(kb). SWAP + RES
RES : 사용된 물리 메모리 사용량(kb)
SHR : 사용된 공유 메모리 사용량(kb)
S : 프로세스 상태 값
- S(Sleeping), R(Running), D(Uniterruptible Sleep), W(Swapped out process), Z(Zombies) 등의 상태가 존재함
  - W의 Swap out은 이전에 프로세스 전이도를 공부하며 배웠다
%CPU : 프로세스가 사용하는 CPU 사용율
%MEM : 프로세스가 사용하는 메모리 사용율
TIME+ : 프로세스가 실행된 시간
COMMAND : 실행된 명령어

Table 외에도 위의 Tasks, %CPU, MiB Mem, MiB Swap을 통해 실행 중인 프로세스 개수, CPU 사용 현황, 메모리 현황 및 스왑메모리 현황을 파악할 수 있다.

임계구역과 교착 상태

VioletEvgadn — Wed, 5 Apr 2023 00:27:36 +0900

동기화 문제

◎ 임계 구역

멀티 스레드에서 발생할 수 있는 동기화 문제에 대해 설명하려면 먼저 임계구역에 대해 공부해야 한다.

임계 구역이란 여러 개의 스레드가 수행되는 멀티 스레드 시스템에서 각 스레드들이 공유하는 데이터를 변경하는 코드 영역을 말한다.

이전에 설명했듯 스레드의 경우 프로세스 내에서 Stack 영역을 제외한 Data, Code, Heap 영역을 공유하고 있다.

이 중 static 변수와 전역 변수는 특정 상황에서 무조건 1개 스레드만 활용한다고 확정할 수 없다.

즉, 스레드끼리 공유하는 Code, Heap 영역의 데이터를 변경하는 코드 영역을 "임계 구역"이라고 하는 것이다.

임계 구역에 대한 문제를 확인할 수 있는 대표적인 코드는 아래와 같다.

static int cnt = 0;

void funcA(){
	cnt++;
}

void funcB(){
	cnt--;
}

이러한 프로그램에서 만약 A 스레드는 funcA만, B 스레드는 funcB만 수행한다고 가정하자.

이 경우 만약 funcA와 funcB가 동시에 실행된다고 가정하자. 이 경우 funcA는 cnt 값을 0에서 1로 변환시킬 텐데 문제는 funcB가 실행될 때도 cnt 값이 0이라는 의미이다.

이 경우 funcA를 통해 cnt 값이 1로 변환되었는데 funcB를 통해서는 cnt 값이 -1로 변환될 것이다. 이 경우 나중에 종료되는 함수가 도출한 상태로 설정되기 때문에 funcA와 funcB가 동시에 수행되었다면 원래 0이 나와야겠으나 -1이나 1이라는 이상한 값이 도출될 수 있는 것이다.

그리고 이러한 임계 구역 때문에 발생하는 문제를 동기화 문제라고 부르는 것이다.

◎ 동기화

동기화의 정의는 여러 프로세스나 스레드가 어떠한 데이터에 대하여 동시 작업을 수행할 경우 작업에 순서를 정해주어 공유하는 데이터의 일관성을 유지하는 것이다.

하나의 자원을 한 순간에 한 프로세스만 이용하도록 제어하는 "프로세스 동기화", 하나의 코드블록이나 메서드를 한 순가에 하나의 스레드만 이용하도록 보장하는 "스레드 동기화"가 존재한다.

동기화 작업은 어떠한 데이터에 대하여 동시 작업이 일어날 경우 작업 순서에 관계없이 원하는 결괏값을 얻기 위하여 수행하는 과정이다.

이를 깊게 생각해 보자면 임계 구역이 존재하여 공유된 자원에 여러 스레드가 접근할 경우 동기화 작업을 통해 스레드 작업 간 순서를 정할 수 있기 때문에 공유된 자원의 일관성을 유지할 수 있다는 것이다.

위 예시를 보자면 funcA를 먼저 수행시키고 funcB를 수행시키는 설정으로 "0 → 1 → 0" 과정을 통해 정상적으로 자원의 일관성을 유지할 수 있는 것이다.

동기화의 가장 큰 목적은 데이터의 일관성을 보장하기 위함이다.

동기화를 통해 임계구역 문제를 해결하고 공유되는 데이터를 관리해 줌으로써 원하는 결괏값이 도출될 수 있는 것이다.

또한 프로세스의 실행 순서를 원하는 대로 제어하거나 Busy wait 같은 비효율성을 제거하기 위해 동기화를 사용하기도 한다. 여기서 Busy wait이란 의미 없는 코드를 반복 수행하며 기다리는 것을 말한다.

◎ 임계구역 문제(동기화 문제) 해결의 3가지 조건

임계구역과 그에 따라 발생하는 문제, 그리고 동기화에 대해서도 알아봤으니 멀티스레드 시스템에서 발생할 수 있는 동기화 문제를 해결할 방법에 대해서 알아보자.

임계구역 문제를 해결하기 위해선 3가지 조건이 필요하다.

상호배제(Mutual Exclusion)
- 임계구역에는 오직 1개의 스레드만 진입 가능함
- 1개 스레드가 임계구역에서 실행 중이라면 다른 스레드는 해당 임계구역에 접근할 수 없음
진행(Progress)
- 임계구역에 프로세스가 존재하지 않을 경우 다른 프로세스가 접근 가능해야 함
- 임계구역에 들어간 프로세스가 없는 상태에서 한 순간에 다수의 프로세스가 임계 구역에 들어가려 할 때 어떤 프로세스가 임계 구역에 들어갈지 유한 시간 내에 결정돼야 함
유한 대기(Bounded Waiting)
- 임계구역으로 진입하기 위해 대기하는 모든 스레드는 유한 시간 내에 해당 임계구역으로 진입 가능해야 함
- 진행은 임계구역 해결을 위해 계속해서 스레드가 임계 구역 코드를 실행시키도록 하는 것을 말하며 유한대기는 이미 임계구역 코드를 실행하고 있는 스레드 외의 나머지 스레드들이 기아 현상이 나타나지 않도록 실행되고 있는 스레드를 제한하는 것을 의미함
  - 기아 : 프로세스나 스레드가 임계 영역 코드를 실행시키기 위하여 무한정으로 기다리는 현상

◎ 임계구역 문제 해결방법

Lock

하나의 스레드가 프로세스나 자원을 활용하고 있다면 이를 잠가 다른 스레드가 접근을 못하게 하는 방식이다.

하지만 Lock 방식은 특정 상황에서 제대로 동작하지 않는다는 단점이 존재한다.

예를 들어 A 함수가 임계 구역 코드에 Lock을 걸기 전 다른 스레드가 임계 구역 함수에 들어오게 된다면 두 개의 스레드가 임계 영역에 동시접근하는 상황이 발생할 수 있다.

Semaphore & Mutex

임계구역 문제 해결방법으로 가장 유명한 방법이자 위에서 설명한 동기화 방법을 통해 문제를 해결하는 방법이다.

세마포어란 동시에 자원을 접근할 수 있도록 허용한 공유 자원의 수를 나타내는 것으로 P, V라고 불리는 2개의 Atomic(분해되지 않는) 함수로 제어되는 정수 변수를 이용한 교착 상태 방법이다.

사실 세마포어와 뮤텍스에 대해서까지 공부하면 리눅스를 공부하기 위해 간단히 OS를 공부한다는 측면과는 달라지는 것 같아 간단히만 설명하고 넘어가겠다.

나중에 네트워크처럼 OS도 필요성을 느낀다면 그때 자세히 다루지 않을까 싶다. 학부생 때도 배웠지만 이 부분이 정말 생각보다 매우 복잡한 과정 및 이론을 가지고 있는데 1학기 중 중간 ~ 기말 내내 다뤘던 부분이라는 것을 알아두면 어느 정도 난이도와 양인지 알 수 있을 것이다.

간단히만 설명하자면 세마포어는 접근제어를 위한 정수형 변수 S값을 감소시키는 P함수(Wait 함수)와 S값을 증가시키는 V함수(Signal)가 존재한다.

이 중 Semaphore는 정수형 변수 상태가 0부터 지정한 정수값 n까지의 값 중 하나를 가질 수 있지만 뮤텍스는 S 상태가 9과 1 두 개뿐인 이진형 세마포어이다.

이 때문에 "세마포어는 뮤텍스가 될 수 있지만 뮤텍스는 세마포어가 될 수 없다"라는 면접관들이 좋아하는 1개 문장이 나오는 것이다.

이렇게 차이가 나는 것은 세마포어는 "여러 프로세스가" 공유된 데이터에 접근하는 것을 막는 것이고 뮤텍스는 "여러 스레드가" 공유된 데이터에 접근하는 것을 막는 것이다.

스레드는 공유된 자원이라면 1개 프로세스 전체에서 공유되고 있는 자원이기 때문에 무조건 2개 이상의 스레드가 동시에 접근하면 안 된다.

하지만 프로세스 같은 경우 다른 프로세스와 독립된 메모리 공간을 가지고 있기 때문에 공유된 자원이라 할지라도 다수의 프로세스에서 동시 접근 가능한 상태도 존재하며 이런 상황에선 2개 이상의 스레드가 들어와도 데이터 안정성을 해치지 않을 수 있기 때문에 꼭 0,1 값만 가지지 않아도 되는 것이다.

단지 Semaphore는 P나 V 연산 중 하나가 생략된다면 상호배제 문제와 대기하는 프로세스들이 교착상태에 빠질 수 있다는 문제가 존재한다.

P 연산이 일단 시작되면 프로세스는 다른 경로를 선택할 수 없기 때문에 만약 S값이 1인 상태로 V 연산이 생략된다면 S는 영원히 1일 것이며 이진 세마포어일 경우 P 연산을 이미 실행하여 기다리고 있는 스레드들은 영구적으로 임계구역에 접근할 수 없을 것이다.

Monitor

한 프로세스 내에 있는 하나의 스레드만 자원에 접근이 가능한 방법으로 하나의 프로세스 내에서 다른 스레드 간 동기화를 할 때 사용한다.

모니터는 개념적으로 이진 세마포어만 가능한데 세마포어와 유사하지만 객체 지향 개념을 넣었기 때문에 제어하기가 더욱 쉽다.

이 부분도 자세히 공부하자면 너무 복잡하기 때문에 이 정도로만 알고 넘어가자.

교착상태(Deadlock)

출처 : https://www.geeksforgeeks.org/introduction-of-deadlock-in-operating-system/

◎ 교착상태란?

교착상태는 "프로세스의 무한 대기 상태"라고 이해하면 편하다.

2개 이상의 작업이 서로 상대방의 작업이 끝나기만을 기다리고 있기 때문에 다음 단계를 진행하지 못하는 상황을 말한다.

위 이미지가 교착상태를 가장 잘 표현한 이미지이다.

Process1(P1)과 Process2(P2)는 실행되기 위해 Resource1(R1)과 Resource2(R2)가 필요하며 P1은 R1만을 가지고 있고 P2는 R2만을 가지고 있는 상황인 것이다.

P1의 경우 P2가 종료되면 R2를 반납할 것이니 이를 가져가 실행하면 되기 때문에 R2 반환을 기다릴 것이다. 하지만 P2 입장에서도 R2를 가지고 있는 현 상태에서 P1이 종료되어 R1이 반납되면 이를 가져가야 실행할 수 있으므로 P1이 종료되기를 기다리는 것이다.

즉, P1은 P2가 종료되기를, P2는 P1이 종료되기를 한없이 기다리며 2개 프로세스 모두 실행되지 못하는 상태가 되는 것이다.

이런 교착 상태는 제한된 자원을 최대한 효율적으로 사용하려다 그 부작용으로 인해 발생하는 문제이다.

이런 교착 상태가 지속된다면 다른 프로세스에도 영향을 끼치기 때문에 1개 프로세스만 고통을 받는 기아(무한 대기) 상태보다 더욱 심각한 문제라고 볼 수 있다.

예를 들어 P3라는 프로세스가 R1, R2, R3 자원을 필요로 한다면 P3까지 이 교착 상태에 추가될 것이기 때문이다.

◎ 교착상태의 4가지 필요조건

교착 상태가 발생하기 위해선 꼭 4가지 필요조건이 성립되어야 한다.

여기에서 중요한 것은 "필요조건"이라는 것이다. 4가지 조건이 충족된다고 해서 무조건 교착 상태가 발생한다고 단정 지을 수는 없으나 만약 교착 상태가 발생했다면 무조건 이 4가지 조건이 충족된 것이다.

상호 배제(Mutual Exclusion)
- 1개 프로세스가 자원을 사용하고 있다면 다른 프로세스는 사용할 수 없음
- 즉, 자원에 대한 공유가 안 되는 것이다.
점유 대기(Hold and wait)
- 프로세스가 할당된 자원을 가지고 있는 상태에서 필요한 다른 자원을 기다림
비선점(No preemption)
- 프로세스가 자원 사용을 끝낼 때까지는 다른 프로세스가 그 자원을 빼앗아 사용할 수 없음
순환대기(Circular wait)
- 프로세스가 요구하는 자원의 방향이 원형을 이룸
- 프로세스는 순환적으로 다음 프로세스가 요구하는 자원을 점유하고 있어야 함

교착 상태를 가장 잘 나타내는 예시는 "식사하는 철학자들 문제"라는 다익스트라가 만든 문제이다.

철학자들은 식사를 하는데 한 철학자가 A 젓가락을 사용하고 있다면 다른 사람들은 누구도 A 젓가락을 사용할 수 없다.(상호 배제) 또한 다른 철학자가 들고 있는 젓가락을 뺏을 수도 없다.(비선점)

이때 철학자들의 젓가락은 철학자의 왼쪽과 오른쪽에 1개씩 놓여 있는데 모든 철학자는 왼쪽 젓가락부터 집을 수 있다.(순환 대기)

조건에 의하여 모든 철학자는 왼쪽 젓가락을 집고 있는 상태가 될 것이고 이젠 오른쪽 젓가락을 집어야 할 텐데 오른쪽 철학자가 이미 자신 기준 오른쪽, 오른쪽 철학자 기준 왼쪽 젓가락을 가지고 있기 때문에 오른쪽 철학자가 젓가락을 내려놓을 때까지 기다린다. 이 상황에서 자신은 왼쪽 젓가락을 내려놓지 않는다.(점유 대기)

결국 이런 상황에선 모든 철학자가 왼쪽 젓가락만 가진 상태에서 오른쪽 젓가락을 기다리고 있는 상태가 되므로 모든 철학자가 식사를 하지 못할 것이다.

◎ 교착상태 처리

교착 상태 방지
- 필요조건 4가지 중 최소 1가지를 미충족 시키도록 만들어 교착 상태를 일어나지 않게 함
- 상호 배타 - 독점적으로 사용할 수 있는 자원 없애기
- 보유 및 대기 - 프로세스 실행에 필요한 자원을 전부 할당하거나 할당하지 않음
- 비선점 - 모든 자원을 다른 프로세스에서 빼앗을 수 있게 만듦
- 환형대기 - 프로세스들을 한 줄로 길게 늘어뜨려 한 방향으로 실행되도록 함
교착 상태 회피
- 교착 상태가 발생하지 않는 범위 내에서만 자원을 할당하고 만약 교착 상태가 발생할 만큼 자원이 할당된다면 대기 시킴
- 할당된 자원의 수를 기준으로 시스템은 안정 상태와 불안정 상태로 나뉘는데, 자원을 많이 할당할수록 교착 상태가 발생활 확률이 커져 불안정 상태로 변한다.
- 프로세스가 자신이 사용할 모든 자원을 미리 선언해야 한다는 점에서 현실과는 맞지 않는 처리 방식이며 자원이 낭비된다는 문제점이 존재
교착 상태 검출 및 복구
- 교착 상태가 발생할 경우 이를 검출하여 복구시키는 방식으로 가장 현실적인 방식
- OS가 타임아웃을 사용하여 교착 상태 발생 여부를 계속 주시하는 방식
- 교착상태 발생 시 교착상태를 유발한 프로세스를 강제 종료
  - 교착상태를 유발한 프로세스 동시 종료
  - 교착상태를 일으킨 프로세스 중 하나를 골라 순서대로 종료
    - 우선순위가 낮은 프로세스 > 작업 시간이 짧은 프로세스 > 자원을 많이 사용하는 프로세스 순으로 먼저 종료시킨다.
교착 상태 무시
- 교착 상태는 드물게 발생하는데 이를 예방, 회피, 탐지 및 복구하기 위해선 비용이 많이 들기 때문에 그냥 무시하는 방식
- 어디까지나 교착 상태 "처리"에 대해 공부하는 것이지 교착 상태 해결법에 대해 공부하는 것이 아님을 기억하자

프로세스와 스레드

VioletEvgadn — Tue, 4 Apr 2023 12:10:56 +0900

리눅스에서의 프로세스 관리법에 대해 알아보기 전 프로세스와 스레드에 대한 개념을 잡고 가는 것이 좋다고 생각했다.

프로세스와 스레드, 그리고 이에 이어지는 멀티스레드와 멀티 프로세스와 임계 지역(Critical Section)과 동기화는 면접에서도 물어볼 만큼 중요한 개념이고 학부생 때도 이에 대해서만 1학기 내내 공부했던 만큼 중요하다고 생각하여 제대로 공부하고 넘어가도록 하겠다.

프로세스

◎ 프로세스란?

프로세스에 대해 알기 위해선 프로그램에 대해 먼저 알아볼 필요가 있다.

"프로그램"이란 "어떤 작업을 위해 실행할 수 있는 파일"이라는 의미이다. 이 말을 조금 더 생각해 보면 실행할 수 있는 파일이라면 그 파일이 어떤 상태이든 모두 프로그램이라고 할 수 있다.

위키피디아에서 설명한 프로세스(Process)란 컴퓨터 프로그램의 인스턴스로써 하나 이상의 스레드를 통해 실행된다고 나와 있다.

프로그램을 실행시키면 OS는 프로그램 실행에 필요한 자원들을 할당할 것이며 해당 자원에 프로그램 실행에 필요한 프로그램 명령어 및 데이터가 적재됨으로써 프로그램 인스턴스가 생성된다.

이렇게 생성된 프로그램 인스턴스를 프로세스라고 하며, 정리하자면 "CPU 자원을 할당받아 실행 중인 프로그램"이라고 할 수 있다.

이 때 할당받는 시스템 자원으로는 CPU 시간, 메모리 영역(Code, Data, Stack, Heap 구조), 운영을 위한 주소 공간 등이 있다.

◎ 프로세스의 분류

먼저 프로세스는 실행 결과 및 과정을 화면에 띄우느냐에 따라 "포그라운드 프로세스(Foreground)"와 "백그라운드 프로세스(Background)"로 나눈다.

포그라운드 프로세스는 명령어를 실행하면 결과가 화면에 나타나며 사용자는 결과를 보고 다음 명령을 입력하는 사용자와 상호작용하며 진행되는 프로세스이다.

백그라운드 프로세스는 실행은 되지만 결과가 화면에는 나타나지 않는 프로세스를 말한다. 따라서 실행 중 사용자와 상호작용하기가 힘들며 백그라운드 프로세스로는 대표적으로 백신이나 데몬이 존재한다.

프로세스는 다른 프로세스를 만들었는지 만들어졌는지에 따라 "부모 프로세스"와 "자식 프로세스"로 나눌 수도 있다.

한 프로세스는 실행되는 도중 fork()라는 시스템 콜을 통해 새로운 프로세스들을 생성할 수 있다.

이 때 fork() 시스템 콜을 통해 다른 프로세스를 생성하는 프로세스를 "부모 프로세스(Parent Process)"라 하며 부모 프로세스에 의하여 생성된 프로세스를 "자식 프로세스(Child Process)"라 한다.

모든 프로세스는 부모 프로세스를 가지고 있으며 부모 프로세스가 중지된다면 자식 프로세스도 자동으로 중지된다는 특징을 가진다.

◎ PCB

프로세스 제어 블록(Process Control Block;PCB)은 특정 프로세스에 대한 정보를 저장하고 있는 OS 커널의 자료 구조이다.

PCB가 필요한 이유는 나중에 설명할 Context Switching(문맥 교환) 때문인데 CPU가 여러 프로세스를 빠르게 번갈아가며 작업하기 위해서는 프로세스에 대한 정보 및 상태를 저장/복원할 필요가 있기 때문이다.

OS마다 PCB가 저장하는 항목이 약간씩 다르지만 일반적으로 아래와 같은 정보를 저장한다.

프로세스 식별자(PID; Process ID)
프로세스 상태(Process State)
프로그램 계수기(Program Counter) : CPU가 다음으로 실행할 명령어를 가리키는 값
CPU 스케줄링 정보 등

◎ 프로세스 메모리 구조

출처 : https://code-lab1.tistory.com/38

Code 영역 : 프로그램을 실행시키는 실행 파일 내의 명령어들이 저장됨
Data 영역 : 전역변수나 static 변수들이 저장됨
Heap 영역 : 동적 할당 된 변수들이 저장됨
- malloc(C언어), new(Java) 등으로 선언된 변수
Stack 영역 : 지역변수, 파라미터(함수에 전달되는 인자)가 저장됨

일단 재미있게 봐야 하는 점이 Stack 영역은 아래에서부터 데이터가 쌓이고 Heap 영역은 위에서부터 데이터가 쌓인다는 점이다. 또한 Code 영역에서 스택 영역으로 갈수록 메모리 주소값이 증가한다.

하나의 프로세스는 위에서 설명한 구조로 독립된 메모리 영역을 할당받는다.

만약 OS에 프로세스가 3개 존재한다면 아래 이미지와 같이 프로세스가 존재하고 있을 것이다.

출처 : https://gmlwjd9405.github.io/2018/09/14/process-vs-thread.html

이 메모리 구조를 외우는 데에 예전에는 애를 먹었는데 원리를 이해하면 왜 이렇게 나누어 놓았는지 조금 이해가 될 것이다.

먼저 코드 영역이다.

이 부분은 실행할 프로그램의 코드 및 매크로 상수가 기계어 형태로 저장되어 있다.

이 부분은 당연히 나뉘어져 있어야 하는데 CPU는 코드 영역에 저장된 다수의 명령어를 차례로 실행함으로써 프로그램을 실행시킬 수 있기 때문이다.

이후 전역 변수 및 static 변수를 저장하는 데이터 영역이다.

데이터 영역을 나눠 놓은 이유를 알기 위해선 전역 변수와 static 변수의 특징을 알아야 한다.

전역 변수는 (자바 기준) 클래스 내에서 유일한 값, static 변수는 전체 프로젝트 내에서 유일한 값으로 프로그램이 실행되기도 전에 지정될 수 있는 값이다.

이를 CS적으로 말하자면 전역 변수와 static 변수는 컴파일될 때부터 어떤 값인지 지정되어 있거나 유추할 수 있는 값이라는 의미이다.

즉, 데이터 영역의 데이터는 프로그램 시작과 동시에 할당될 수 있는 값들이 저장되며 프로그램이 종료할 때 소멸되는 프로그램 수명과 동일한 수명을 가진 변수인 것이다.

하지만 프로그램에는 프로그램 시작과 동시에 할당될 수 있는 값들만 저장되어 있는 것은 아니다.

예를 들어 웹 프로젝트의 경우 URL Parameter에 의하여 고객이 선택하는 값에 따라 다르게 할당되는 값도 존재한다.

이렇게 프로그램 실행 과정에서 값이 정해지는 변수들을 저장하기 위하여 스택 영역과 힙 영역을 준비한 것이다.

그렇다면 이 둘을 왜 나눠 놓은 건지 알아보자.

둘 중 스택(Stack) 영역에 대해 먼저 알아보자.

스택 영역은 함수 안에서 선언되는 지역변수, 매개변수, 리턴값 등이 저장되는 공간이다.

저장되는 값들을 보면 유추할 수 있겠지만 함수가 호출될 때 사용되며 동시에 함수가 종료될 때 사라져야 하는 값들이다.

즉, 데이터 영역이 프로그램 수명과 동일한 수명을 가진 변수를 저장했다면 스택 영역은 호출한 함수의 수명과 동일한 수명을 가진 변수를 저장하는 공간인 것이다.

스택이라는 자료구조 명칭에서도 알 수 있듯 후위선출(LIFO) 메커니즘을 따른다.

재귀함수가 너무 많이 실행될 경우 "Stack Overflow" 에러가 발생하는데 호출된 재귀함수가 종료되기 전까지는 재귀함수를 호출한 부모 함수 또한 Stack 영역에 메모리를 차지하고 있고 이런 재귀함수가 너무 많아지면 모든 재귀함수가 스택 영역에 각자의 재귀 함수 변수들을 저장하고 있기 때문에 결국 스택 영역에 할당된 메모리가 부족해져 생기는 에러이다.

마지막으로 힙(Heap) 영역이다.

힙 영역은 관리가 가능한 데이터 이외의 다른 형태의 데이터를 관리하기 위한 공간으로 동적 메모리 할당 공간이다.

지금까지 배웠던 데이터들은 어찌되었든 사전에 크기가 미리 정해져 있는 데이터였다. 예를 들어 "int a"일 경우 a값이 무엇이 될지는 모르겠으나 a가 4 바이트를 차지한다는 것은 알 수 있다.

하지만 동적 메모리 할당을 할 경우 해당 객체가 몇 바이트를 차지할지 알 수 없다. 예를 들어 String 데이터를 지정할 경우 사용자가 1글자만 입력할지 1024글자를 입력할지 사용자가 직접 입력하기 전까지는 모르는 것이다.

즉, 프로그램이 실행되는 순간 프로그램이 사용할 메모리 크기를 고려하여 메모리 할당이 이뤄질 수 있는 스택이나 데이터 영역과는 다르게 힙 영역의 데이터는 프로그램이 실행되고 객체에 직접 데이터가 주입되기 전까지는 어느 정도의 메모리가 할당되어야 하는지 모르는 것이다.

따라서 힙 영역의 데이터는 런타임에서만 확인할 수 있다.

◎ IPC

위에서 설명했던 것처럼 프로세스는 독립된 메모리를 할당받기 때문에 모든 프로세스는 별도의 주소 공간에서 실행되며 이 때문에 일반적인 방법으로는 한 프로세스가 다른 프로세스의 변수나 자료 구조에 접근할 수 없을 것이다.

하지만 프로세스 간 통신(IPC; Inter-process communication)을 사용한다면 다른 프로세스의 자원에 접근할 수도 있다.

IPC란 OS에서 실행중인 프로세스 간 정보를 주고받는 것을 말하는데 방법을 간단히 말하자면 2개 프로세스 사이에 길을 만들어 만들어진 길을 통해 데이터를 주고받음으로써 프로세스 간 통신이 가능해지는 것이다.

쌍둥이 빌딩은 원래 별개의 건물 2개이기 때문에 한쪽 건물에서 다른 쪽 건물로 이동할 수 없어야 하지만 그 사이를 잇는 다리를 만들어 그 다리를 통해 사람이나 물건이 다른 쪽 건물로 이동할 수 있는 것을 생각하면 된다.

IPC 종류로는 파이프, 소켓, 시그널, 공유 메모리 등을 이용한 통신 방법이 있다.

◎ 프로세스 상태 전이

출처 : https://afteracademy.com/blog/what-is-long-term-short-term-and-medium-term-scheduler/

프로세스 상태

New(생성)
- 프로세스가 막 생성된 상태
Ready(준비)
- 프로세스가 CPU에 할당되어 처리되기를 기다리는 상태
Running(실행)
- 프로세스가 CPU에 할당되어 실제로 명령어들이 실행되는 상태
Block(Wait; 대기/보류)
- 이벤트의 발생으로 프로세스가 특정 동작을 기다리는 상태
- 처리 속도가 느린 I/O 작업 중이거나 외부 사건이 생길 때까지 실행될 수 없는 상태
Blocked Suspended
- 프로세스가 대기 상태에서 기억 장치를 잃은 상태
Suspended Ready
- 프로세스가 기억장치를 제외한 다른 모든 필요한 자원을 보유한 상태
Exit(Terminated; 종료)
- 프로세스의 실행이 완료되어 할당된 CPU를 반납한 상

프로세스 상태 변화

Dispatch(Ready → Running)
- 준비 상태의 프로세스가 CPU를 할당받아 실행 상태로 변함
Timer Run Out(Running → Ready)
- 할당된 시간만큼 CPU를 사용하였기 때문에 준비 상태로 변함
I/O 발생(Running → Block)
- 프로세스가 동작 중 I/O 행위가 필요하여 대기 상태로 이동
Wake up(Block→ Ready)
- I/O 작업이 완료되었거나 자원이 할당되어 다시 준비 상태로 변함
Suspended(Swap-Out; Ready → Suspended Ready)
- 준비 상태에서 기억 장치를 반납
Resume(Swap-In; Suspended Ready → Ready)
- 지연 준비 상태에서 기억 장치를 할당 받아 준비 상태로 변함

프로세스 스케줄링

Long-Term(장기 스케줄러; Job Scheduler)
- 보조기억장치에서 어떤 프로그램을 가져와 커널에 등록하여 준비 상태로 만들지 결정
Middle-Term(중기 스케줄러)
- 메모리에 적재된 프로세스의 수를 동적으로 조절하기 위해 추가된 스케줄러로 Swap-Out 과정을 말함
- 메모리에 너무 많은 프로세스가 적재되어 있을 경우 Context Switching이 너무 많이 발생하여 오버헤드 때문에 시스템 성능이 저하될 수 있다. 따라서 대기 상태의 프로세스 중 일부로부터 메모리를 통째로 빼앗아 메모리의 여유 공간을 마련하는 과정을 말한다. 만약 메모리에 데이터가 저장되어 있다면 디스크 스왑 영역에 저장한다.
Short-Term(단기 스케줄러; CPU Scheduler)
- 준비 상태의 프로세스 중 어떤 프로세스를 실행 상태로 만들지 결정
- 시분할 시스템에서 타이머 인터럽트가 발생하면 단기 스케줄러가 호출됨

스레드

◎ 스레드란?

위키피디아에서 설명하는 스레드는 "프로세스 내에서 실행되는 흐름의 단위"라고 설명하고 있다.

스레드는 프로세스가 할당받은 자원을 이용하여 작업을 처리하는 실행의 단위라고도 말할 수 있다.

사실 스레드에 대해 설명하기보다는 스레드와 프로세스의 차이에 대해 설명하는 것이 이해하기 더 편하다.

위에서 말했듯 프로세스는 OS로부터 자원을 할당받아 4개의 메모리 영역(Code, Data, Stack, Heap 구조)을 구성한 뒤 프로그램을 실행시켰다.

하지만 스레드는 OS로부터 자원을 받는 것이 아닌 프로세스로부터 자원을 받아 실행되는 Task이다.

여기에서 중요한 점이 있는데, 스레드는 프로세스 내에서 Stack 영역만 따로 할당받고 Code, Data, Heap 영역은 프로세스 것과 공유한다는 것이다.

출처 : https://gmlwjd9405.github.io/2018/09/14/process-vs-thread.html

이런 상황이다 보니 프로세스와 큰 차이점이 또 하나 존재한다.

프로세스는 각각이 독립된 메모리에 데이터를 저장하기 때문에 IPC를 사용하지 않을 경우 다른 프로세스의 데이터에 접근할 수 없다.

하지만 스레드는 Stack 영역만 나뉘어져 있을 뿐 Code, Data, Heap 영역은 모두 공유하고 있는 상태이다.

예를 들어 위 이미지에서 Thread1이 Heap 영역에 A라는 동적 객체를 생성했다면 Thread2에서도 A 객체에 접근할 수 있다.

즉, 프로세스 내에 존재하는 자식 스레드들은 서로 주소 공간이나 자원들을 공유하면서 실행될 수 있다는 의미이다.

멀티 프로세스와 멀티 스레드

◎ 문맥 교환(Context Switching)

문맥 교환을 알아보기 전 프로세스 컨텍스트(Context)에 대해서 알아볼 필요가 있다.

프로세스 Context는 프로세스가 현재 어떤 상태에서 수행되고 있는지 파악하기 위해 필요한 정보를 말한다.

프로세스는 CPU를 점유하여 명령을 수행하는데 현재는 멀티태스킹 작업을 수행하기 위해 프로세스가 한 번 CPU를 잡으면 작업이 종료될 때까지 점유하고 있는 것이 아니라 일정 시간 동안 점유한 뒤 다음 프로세스에게 CPU를 넘겨주는 방식으로 프로세스가 실행된다. 이는 아래에서 조금 더 설명하겠다.

이렇다보니 프로세스가 진행되다가 다음 프로세스에게 CPU를 넘겨줄 경우 CPU를 넘겨주기 전까지 진행되었던 프로세스 상태를 저장한 뒤 해당 프로세스가 다시 CPU를 할당받으면 저장한 시점부터 프로세스를 진행해야 한다.

이를 위해 프로세스가 어디까지 명령을 수행하였는지 정확한 시점과 상태를 재현할 수 있는 정보가 필요했고 이 정보가 "프로세스 문맥(Process Context)"인 것이다.

프로세스 문맥은 크게 "하드웨어 문맥", "프로세스 주소공간", "커널상 문맥"으로 나눌 수 있다.

하드웨어 문맥은 CPU 상태를 나타내는 register 값으로 PC(Program Counter)와 각종 레지스터에 저장된 값들을 말한다.

프로세스에 CPU가 할당되었다면 PC가 가리키는 부분부터 명령을 실행하면 되는 것이다.

프로세스 주소 공간은 Code, Data, Stack 영역으로 구성된 프로세스만의 독자적인 주소 공간으로 현재 프로세스가 사용하는 변수나 데이터 등에 대한 정보를 담고 있다.

커널상 문맥은 OS가 해당 프로세스를 어떻게 관리하고 다루는지 파악 가능한 정보를 말한다.

다른 말로 하자면 프로세스 관리를 위한 자료구조인 PCB와 Kernel Stack(커널 내의 주소)를 말한다.

문맥 교환은 이러한 프로세스 문맥(Context)을 교환하는 것을 말한다.

즉, 위에서 말했듯 프로세스는 CPU를 계속 점유하는 것이 아닌 일정 시간 동안 사용하다 다른 프로세스에게 CPU를 건네주는데 이때 프로세스 문맥을 바꾸는 과정이라는 것을 유추할 수 있다.

문맥 교환이란 하나의 프로세스가 CPU를 사용 중인 상태에서 다른 프로세스가 CPU를 사용하도록 하기 위해 이전 프로세스의 상태를 보관한 뒤 새로운 프로세스의 상태를 적재하는 작업을 의미한다.

문맥 교환을 통해 CPU를 사용하고 있던 프로세스의 상태를 위에서 설명한 PCB에 저장한 뒤 다음 프로세스로 CPU 사용권을 넘겨주는 것이다.

문맥 교환은 OS의 CPU 자원을 할당해 주는 스케줄러(Scheduler)에 의해 발생하며 스케줄러가 CPU를 적절하고 효율적으로 사용할 수 있게 해주는 작업을 스케쥴링이라고 한다.

이 CPU 스케쥴링에는 LFU, FIFO 등 여러 방법이 존재하지만 여기까지 공부하기엔 OS에 대하여 깊이 공부를 해야하기 때문에 설명은 생략하겠다.

◎ 멀티 프로세스

멀티 프로세스란 하나의 응용 프로그램을 여러 개의 프로세스로 구성하여 각 프로세스가 1개의 작업(Task)을 처리하도록 하는 것이다.

사실 1개의 CPU는 1개의 명령어밖에 처리할 수 없다. 즉, 1개 CPU 가지고는 음악을 들으며 구글 검색을 수행할 수 없다는 것이다. 하지만 우리는 1개 CPU로도 다수의 작업을 동시에 할 수 있다. 어떻게 할 수 있는 걸까?

CPU는 동시에 여러 개의 작업을 수행하는 것이 아닌 한 번에 한 개의 프로세스만을 처리하되 재빠르게 여러 프로세스들을 번갈아가며 실행함으로써 여러 개의 작업이 수행되는 것처럼 보이게 하는 것이다.

CPU는 상상이상으로 빠르게 동작하기 때문에 프로세스들을 번갈아가며 실행하는 것이 마치 동시에 동작되는 것처럼 보일 뿐인 것이다.

이 과정에서 "문맥 교환(Context Switching)" 작업이 필요하다.

멀티 프로세스는 프로그램을 여러 개의 프로세스로 구성하여 각 프로세스가 1개의 작업을 처리하는 것이므로 위에서 설명한 문맥 교환 작업을 통해 여러 개의 작업을 수행할 수 있을 것이다.

멀티 프로세스 장점

모든 프로세스는 고유한 메모리 공간을 할당받고 IPC를 통해서가 아니라면 다른 프로세스의 데이터에 접근할 수 없다.

따라서 멀티 프로세스 같은 경우 안정성이 좋다.

여러 개의 자식 프로세스 중 하나에 문제가 발생하더라도 이 문제가 다른 자식 프로세스에 영향을 주지 않기 때문이다.

또한 구현이 비교적 간단하다는 장점도 존재한다.

멀티 프로세스 단점

멀티 프로세스에선 스케쥴링에 의한 Context Switching 과정이 많아지는데, 문맥 교환에서도 오버헤드가 발생한다.

문맥 교환 과정에선 캐시 메모리 초기화 등의 무거운 작업이 진행되며 문맥 교환 시간도 오버헤드를 발생시킨다.

또한 프로세스 간 통신을 위해선 IPC라는 어렵고 복잡한 통신 기법을 사용해야 한다.

따라서 다른 프로세스가 실행한 결과물을 사용해야 할 경우 구현 난이도가 갑자기 증가하게 될 것이다.

마지막으로 모든 프로세스는 다른 메모리 영역을 할당받아야 하기 때문에 메모리 사용량이 많을 것이다.

◎ 멀티 스레드

멀티 스레딩은 하나의 응용 프로그램을 여러 개의 스레드로 구성한 뒤 1개의 스레드가 1개의 작업(Task)을 처리하도록 하는 것이다.

윈도우, 리눅스 등 많은 OS에서는 멀티 프로세스도 지원은 하고 있으나 기본적으로 멀티 스레드를 활용하고 있다.

사용자와 상호작용하는 애플리케이션에서 단일 스레드로 네트워크 통신이나 DB 접속 같은 긴 작업(Long-running task)을 처리하면 해당 작업을 수행하는 동안 사용자와 상호작용이 불가능해질 수 있으므로 멀티 스레드를 활용한.

멀티 스레드 장점

스레드는 Stack 영역을 제외한 나머지 데이터들을 다른 스레드와 공유하기 때문에 데이터를 주고받는 것이 매우 편하다.

따라서 스레드 간 데이터를 주고받을 때 시스템 자원 소모가 줄어들 것이다.

또한 프로세스를 생성하여 자원을 할당하는 것보다 이미 자원이 할당된 프로세스가 스레드에 자원을 할당하는 것이 비용이 적게 들기 때문에 자원의 효율성을 극대화시킬 수도 있다.

프로세스를 생성할 때는 자원을 할당하기 위한 시스템 콜이 실행되어야 하는데 멀티 스레드를 사용할 경우 프로세스에 이미 자원이 할당된 상태일 것이기 때문에 사용하는 시스템 콜이 줄어들어 자원을 효율적으로 관리할 수 있다.

또한 프로세스 간 Context Switching 시에는 CPU 레지스터 교환뿐만 아니라 RAM과 CPU 캐시 메모리에 대한 데이터까지 초기화해야 하기 때문에 오버헤드가 더욱 커진다. 멀티스레드 같은 경우 Context Switching 시 Stack 영역만 처리하면 되기 때문에 훨씬 전환 속도가 빠르고 오버헤드가 적은 것이다.

멀티 스레드 단점

일단 멀티스레드는 구현이 어렵고 기능 테스트 및 디버깅 또한 까다롭다.

또한 너무 많은 스레드 사용은 매우 많은 오버헤드를 발생시킬 수 있다.

위에서 말한 스레드가 자원을 공유한다는 점은 단점으로도 다가올 수 있는데, 일단 자식 스레드 중 하나에 문제가 생길 경우 해당 스레드를 포함하고 있는 전체 프로세스에 영향을 줄 수 있다는 단점을 가진다.

또한 자원 공유로 인해 발생하는 "교착상태"나 "동기화" 문제가 발생하지 않도록 주의해야 하며 이 때문에 구현 난이도가 더욱 증가하게 된다.

교착상태나 동기화에 대해선 다음 섹션에서 알아보도록 하자.

이러한 단점에도 멀티 스레드를 주로 활용하는 이유는 "자원의 효율성이 좋다"라는 장점이 단점을 모두 덮을 만큼 좋은 장점이기 때문이다.

SW 패키지 관리 & 압축

VioletEvgadn — Tue, 4 Apr 2023 09:40:29 +0900

SW 패키지 관리

◎ 소프트웨어와 구성을 배포하는 방법

.tar.gz, tgz - Slackware
.rpm - Red Hat, Fedora, SUSE
.deb - Debian, Ubuntu

리눅스 설치 파일 확장자 명은 이 3개 중 한개라고 보면 된다.

일반적으로 리눅스는 설치 패키지 형태에 따라 레드햇 계열과 데비안 계열로 나뉘는데 레드햇 계열은 RPM 형식(.rpm)의 패키지가 배포되며 데비안 계열은 DEB 형식(.deb) 패키지가 배포된다.

하지만 대부분 리눅스는 서로 바이너리 호환이 되며 레드햇 계열에서도 DEB 설치 프로그램을 제공하고 데비안 계열에서도 RPM 설치 프로그램을 제공하므로 큰 문제는 되지 않는다.

tar.gz 파일은 gzip으로 압축된 파일의 tar 저장 파일이라고 말하는데, 단순하게 말하자면 압축 파일이다.

이는 아래에서도 설명할 것이며 일부 프로그램은 압축을 풀어 바로 실행이 가능하지만 대부분 직접 컴파일(Compile)하여야 하기 때문에 설치 프로그램으로썬 좋은 확장자는 아니다.

RPM은 특정 시스템에 최적으로 컴파일 된 소스들을 묶은 뒤 기기에서 그대로 풀어 기기 환경에 최적인 컴파일 소스를 실행할 수 있도록 만든 실행 프로그램이다. 이렇다보니 다양한 시스템에서 활용하기 좋다.

DEB 파일은 32bit와 64bit 파일이 존재하며 주로 우분투에서 많이 활용되는 설치 프로그램 확장자명이다.

◎ Dependency & Meta-package 관리자

설치 프로그램을 통해 SW 패키지를 설치할 떄 문제가 되는 것이 있는데, 바로 "Dependency 문제"이다.

Python을 배워봤다고 가정하고 예시를 들어보겠다.

필자는 "pip install numpy" 명령어를 통해 Numpy 패키지를 설치하고 싶다. 그런데 Python이 깔려 있지 않다면 Numpy 패키지를 설치할 수 있을까?

이처럼 특정 파일이나 패키지를 설치할 떄 어떠한 파일이 미리 설치되어 있어야지만 그에 기반하여 설치 가능한 파일들이 존재한다.

만약 필요한 파일이 사전에 설치되어 있지 않아 새로운 파일을 설치할 수 없다면 Dependency 문제가 발생했다고 말한다.

이러한 Dependency 문제를 해결하기 위해 원하는 파일을 설치하기 전 미리 설치되어야 하는 파일의 존재 여부를 조사하고 없을 경우 자동으로 필요한 파일들을 설치해주는 관리자가 존재하는데 이것이 바로 "Meta-pakcage 관리자"이다.

Meta-package 관리자는 인터넷에서 패키지의 위치를 파악해 다운로드, 인스톨, 패키지 간 의존성을 분석하는데 대표적으로 rpm을 설치할 수 있는 yum과 rpm & deb를 설치할 수 있는 apt-get이 존재한다.

◎ RPM

RPM은 Redhat Package Manger의 약자로써 레드햇에서 사용하는 패키지 관리 도구이다.

CentOS는 레드햇 계열이므로 많이 사용하겠지만 필자가 사용하는 우분투에선 잘 활용하지 않는 명령어이긴 하다.

하지만 알아두면 좋다고 생각하여 간단히 정리하겠다.

RPM을 설명하기에 앞서 RPM의 단점에 대해서 설명하는 것이 좋을 것 같다.

RPM으로 SW를 설치하면 Dependency 문제가 발생할 수 있으며 이 때문에 1개 패키지를 설치하기 위해선 패키지 간 의존성을 모두 파악하여 차근차근 다운로드 해야 한다.

하지만 이런 귀찮은 면이 있더라도 알아둬야 할 필요성은 있는게 yum Repository에 모든 프로그램이 설치되어 있는 것은 아니기 때문이다.

yum 명령어를 통해 SW를 설치할 수 있지만 yum으로 SW를 설치하기 어려운 상황이 있을 수 있고 yum repository에 등록되지 않은 프로그램들도 가끔 있다.

이런 경우 프로그램들을 .rpm 파일로 불러와 다운받아야 하는데 이 때 RPM 명령어를 활용하는 것이다.

rpm 명령어 활용법은 아래와 같다.

명령어 사용법

rpm [옵션] [package_name]

패키지 설치 및 업데이트

rpm -Uvh [package-name]
# U : 없으면 설치하고 있으면 업데이트
# v : 설치과정 확인(Verify)
# h : 진행과정을 화면에 출력

패키지 삭제

rpm -e [package_name]
# e : 패키지를 지움(erase)

패키지 조회

# 설치 패키지 확인
rpm -qa [package_name]

# 설치 파일이 어느 패키지에 포함되어 있는지 확인
rpm -qf [package_name]

# 패키지 내에 포함되어 있는 파일
rpm -ql [package_name]

# 패키지 정보
rpm -qi [package_name]

### Option 설명
# -q : 질문(Question). 패키지 조회 시 무조건 앞에 붙어야 하는 옵션
# -a : 모든 패키지에 대하여 질의 수행
# -f : 파일에 대한 패키지 질의 수행
# -l : 패키지에 포함되어 있는 파일 출력
# -i : 패키지 정보 출력(Information)

◎ apt-get

RPM에 대해서도 알아봤으니 우분투에서 활용하는 Meta-package 관리자인 "apt-get"에 대하여 알아보자.

apt-get에 대해 알아보기 전 apt와 apt-get의 차이점에 대해서 알아보자.

SW를 설치할 때 "apt install"을 활용해도 되고 "apt-get install"을 활용해도 된다. 그렇다면 둘에는 어떤 차이가 있을까?

사실 apt와 apt-get의 내부 동작 과정은 거의 차이가 없다.

오래전부터 존재해왔던 apt-get이다 보니 시간이 지날수록 옵션들이 추가되어 현재는 옵션들이 너무 많아진 상태이다.

이런 문제를 해결하기 위해 자주 사용하는 옵션들을 추출한 뒤 사용자들이 사용할 떄 보기 편하게 만든 것이 apt인 것이다.

apt가 뒤에 만들어졌고 가독성이 증가된 설치 관리자로써 추가적인 정보를 출력해주기도 한다.

apt-get은 많은 옵션들을 가지고 있어 기능 자체는 많으며 오래전부터 존재해왔기 떄문에 안정적이고 호환성이 높다.

따라서 Script를 작성할 때는 호환성이 좋은 apt-get 사용을 추천한다.

하지만 단순 패키지 설치를 위해서라면 apt를 통해 쉽고 가독성이 좋게 설치할 수 있으므로 이를 사용하는 것이 좋을 것이다.

◎ apt-get 동작 방식

apt-get은 위 이미지와 같이 동작한다. 여기에서 중요한 점이 "/etc/apt/sources.list"이다.

apt-get은 인덱스를 가지고 있어 설치할 패키지를 가져 올 수 있는 위치 정보를 담고 있다.

해당 위치에는 여러 가지 패키지(설치 프로그램)가 저장되어 있을 것이며 사용자는 그곳에서 패키지를 다운로드 받은 뒤 실행함으로써 실제 SW를 설치할 수 있는 것이다. 그리고 이 위치 정보를 담고 있는 파일이 바로 "/etc/apt/sources.list"이다.

sources.list를 보면 deb와 deb-src가 존재하는데 이는 Archive 타입을 말한다.

deb는 위에서 말했던 일반적으로 사용되는 데비안 계열로 컴파일된 바이너리 패키지를 말하며 deb-src란 소스 상태의 오리지널 프로그램과 데비안 컨트롤 파일(.dsc)을 말한다.

즉, sources.list를 통해 apt-get이 어디에서 어떻게 패키지를 설치하거나 관리할지 결정하는 것이다.

패키지를 저장하고 있어 apt-get을 통해 다운로드 받을 수 있게 해주는 사이트를 "미러사이트"라고 하며 국내 우분투에서는 카이스트서버, 다음카카오서버, 네오위즈서버가 대표적이다.

◎ apt-get 사용 방법

패키지 인덱스 정보 업데이트
- /etc/apt/sources.list의 URL에 저장된 SW 패키지 정보를 업데이트 하는 과정

sudo apt-get update

패키지 업그레이드 : 설치되어 있는 패키지를 모두 새 버전으로 업데이트

sudo apt-get upgrade

패키지 설치

sudo apt-get install [package_name]

패키지 삭제

sudo apt-get remove [package_name]

# 설정 파일까지 모두 지움
sudo apt-get --purge remove [package_name]

패키지 검색

sudo apt-cache search [package_name]

패키지 정보 보기

sudo apt-cache show [package_name]

파일 압축

◎ 파일 묶기

파일 압축에 앞서 알아야 할 것이 "파일 묶기"라는 개념이다.

리눅스에서는 원칙적으로 파일 압축과 파일 묶기를 별개의 프로그램으로 수행한다.

A, B, C파일을 1개의 압축 파일로 압축시키는 상황을 가정해보자.

윈도우에선 3개 파일을 드래그 한 뒤 "ZIP 파일로 압축하기"를 눌러 압축을 수행할 수 있다.

하지만 이는 윈도우가 GUI를 사용하기 때문에 "3개 파일을 드래그 해서 묶는다"라는 개념을 간단히 생략할 수 있는 것이다.

리눅스는 GUI도 가능하지만 대체로 CUI를 통해 모든 동작을 수행한다.

즉, "드래그를 통해 3개 파일을 1개로 묶는 과정"과 "묶은 파일들을 압축하는 과정"을 별개의 동작으로 수행해야 한다는 것이다.

파일 묶기의 명령어는 "tar"이며 묶인 파일의 확장자 명 또한 ".tar"이다.

tar의 사용법을 알기 위해선 파일 압축까지 공부해야 하므로 파일 압축에 대해 먼저 배워보자.

◎ 파일 압축

리눅스에서 압축파일의 확장자명은 xz, bz2, gz, zip, Z 등 여러개가 존재한다.

이 중 압축률이 좋은 것은 xz와 bz2로써 이 둘을 자주 사용한다.

파일 압축 관련 명령도 존재하기는 하지만 리눅스에선 파일 압축 명령어를 단독으로 사용하기 보다는 tar 명령어를 통해 파일 묶기 및 압축을 동시에 진행하는 경우가 더 많다.

그렇다 하더라도 파일 압축 명령어를 알아놔 손해 볼 일은 없기 때문에 간단히 알아보자.

xz 압축

# 파일 압축
xz [압축할 파일명]

# 파일 압축 풀기
xz -d [압축을 풀 파일명].xz

xz를 통해 압축하면 압축 파일의 확장자명은 xz가 된다.

bz2 압축

# 파일 압축
bzip2 [압축할 파일]

# 압축 풀기
bzip2 -d [압축 풀 파일명].bz2
bunzip2 [압축 풀 파일명].bz2

bzip2를 통해 압축하면 압축 파일 확장자명은 bz2가 된다.

◎ tar 명령어 사용

tar 동작 관련 옵션

c : Create. 파일 묶기 or 압축을 수행
x : Extract. 압축을 해제함
t : List. 압축된 파일 리스트 보기

tar 명령 목적 관련 옵션

f : File. 압축될 파일명 지정
v : Verify. 압축 진행 과정 가시화
J : tar + xz. 파일을 묶고 xz 파일로 압축까지 진행
- 결과물 확장자명 : .tar.xz
z : tar + gzip. 파일을 묶고 gz 파일로 압축까지 진행
- 결과물 확장자명 : .tar.gz
j : tar + bzip2. 파일을 묶고 bz2 파일로 압축까지 진행
- 결과물 확장자명 : .tar.bz2

참고로 위 설명은 c 옵션을 통해 압축을 진행하는 상황에서의 설명이고 만약 x 옵션을 통해 압축을 해제할 경우 반대로 압축 파일의 압축을 해제할 것이다.

또한 tar 같은 경우 다른 Linux 명령처럼 -cvf로도 옵션을 사용할 수 있으나 "tar cvf"처럼 옵션에 "-"를 생략해도 된다.

마지막으로 "vf"는 특수한 경우를 제외하고 무조건 tar 옵션에 붙여주는 것이 좋은데, 진행 과정을 확인함과 동시에 압축 파일명을 지정할 수 있기 때문이다.

tar 명령어 사용법

tar [옵션] [압축하거나 묶은 후의 파일명] [압축하거나 묶을 Target 경로]

tar 명령 사용 예시

일단 현재 디렉토리 및 저장된 파일들의 상황은 아래 이미지와 같다.

1. tar cvf sample.tar ./test2

cvf이므로 압축 파일을 생성하지는 않고 tar의 본래 역할인 파일 묶기만 실행했다.

2. tar cvfz sample.tar.gz ./test2

이번엔 cvfz이기 때문에 tar + gzip을 수행하여 압축을 진행할 것이다.

즉, sample.tar.gz는 f1 ~ f5까지 묶은 뒤 압축을 수행한 파일인 것이다.

3. tar -tvf sample.tar.gz

그렇다면 실제로 f1~f5까지 모든 파일이 묶여 압축되었는지 명령어를 통해 알아보자.

위 사진에서 볼 수 있듯 정상적으로 모든 파일이 묶여 압축되었음을 알 수 있다.

4. tar xvfz sample.tar.gz

마지막으로 압축을 해제해보자. 그 전에 일단 존재하던 test2 디렉터리를 삭제해 놓고 위 명령어를 입력하자.

압축을 해제하자 test2 디렉토리가 생겼고 그 안에는 f1 ~ f5 까지 모든 파일이 존재함을 볼 수 있다.

Virtual Network editor(vmnetcfg)

VioletEvgadn — Mon, 3 Apr 2023 19:55:38 +0900

vmnetcfg 실행

VMWare에서 인터넷 관련 설정을 하고 싶다면 vmnetcfg를 설치해야 한다.

일단 vmetcfg를 설치한 뒤 설정하는 과정에 대해 알아보자.

1. vmnetcfg 설치

https://www.tobias-hartmann.net/2018/12/download-vmnetcfg-exe-fuer-vmware-workstation-15-x-player/

Download vmnetcfg.exe für VMware Workstation 15.x Player

Download vmnetcfg.exe für VMware Workstation 15.x Player. Der Virtual Network Editor für den VMware Player 15.5.X zum herunterladen!

www.tobias-hartmann.net

위 사이트에서 원하는 버전의 vmnetcfg를 설치하면 된다.

필자는 가장 최신 버전인 15.5.7을 설치하도록 하겠다.

2. 압축 풀기 & vmnetcfg.exe 이동시키기

아마 압축을 풀면 "vmnetcfg.exe"라는 실행 파일이 생겼을 것이다.

이 실행 파일을 아무 위치에서나 실행시키는 것은 아니고 반드시 VMWare Player를 설치한 디렉터리로 이동시켜주어야 한다.

필자는 아래 경로가 VMWare Player 설치 디렉토리였지만 이는 유저마다 다르기 때문에 본인 컴퓨터에서 파악한 뒤 그곳으로 옮기도록 하자.

C://Program Files (x86)/VMware/VMware Player

이 위치로 vmnetcfg.exe 실행 파일을 옮겼다면 가상 네트워크 편집기를 사용할 준비가 끝난다.

3. vmnetcfg.exe 파일 실행시키기

이 때 만약 아이피 변경 등 설정을 변경하고 싶다면 실행파일을 "관리자 권한"으로 실행시켜야 한다.

네트워크 연결

0. vmnetcfg.exe > VMnet8의 Subnet Address 확인

"192.168.111.0"이라고 가정하고 아래 과정을 진행하겠다.

◎ 네트워크 설정 파일 파일 수정

다음으로 수행할 것은 네임 서버(Name Server; Domain Name Server)와 현재 기기의 IP 주소를 설정해 주는 과정이다.

현재 기기의 IP 주소를 설정한다는 의미는 정확히 말하자면 고정 IP를 설정해준다라는 의미이다.

고정 IP는 변경되지 않는 공인 IP로써 한 번 부여받으면 IP를 반납하기 전까지 기기는 해당 IP를 할당받는다.

고정 IP를 사용하지 않을 경우 외부에 알린 기기 IP 주소가 변경될 가능성이 있어 사이트의 안정성이 떨어지므로 도메인명에 대응되어야 하는 IP이자 외부 접속이 가능해야 하는 공개용 서버는 고정 IP를 설정하여 활용하는 것이다.

네임 서버를 설정해 준다는 것은 꽤 중요한 과정이다.

이전에 네트워크에 대해 공부했을 때 DNS에 대해 공부한 적이 있었다.

DNS에서는 도메인명에 대응되는 IP 주소를 찾기 위해서 일단 클라이언트 측의 DNS 서버에 조회 목적의 UDP 패킷을 보내는데 이 클라이언트 측 DNS 서버를 설정하는 것이 바로 네임 서버를 설정하는 과정인 것이다.

네임 서버를 설정하지 않으면 도메인 명에 IP 주소를 대응시킬 수 없어 네트워크를 제대로 활용하지 못하는 상태가 된다.

또한 도메인을 DNS에 등록하고 싶을 때도 네임 서버를 지정한 뒤 해당 네임 서버에 연결 설정을 해야 정상적으로 도메인명과 IP 주소가 대응될 수 있다.

인터넷 표준에 의하면 도메인의 안정적인 서비스를 위해 반드시 2개 이상의 네임서버를 등록하도록 되어 있다.

따라서 우리도 2개의 네임서버를 설정할 것이다.

이 과정은 Ubuntu인지, CentOS인지, 그리고 우분투의 경우 몇 버전을 활용하는지 등에 따라 설정 방법이 다양하다.

이 중 Ubuntu 20.04 기준에서의 설정법과 CentOS에서의 설정법에 대해 알아보도록 하겠다.

1-1. Ubuntu 20.04 기준 설정법

1-1-1. /etc/netplan/ 안에 있는 yaml 파일 수정

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp0s3:
      dhcp6: no
      dhcp4: no
      addresses: [192.168.111.10/24]
      gateway4: 192.168.111.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

먼저 /etc/netplan/~.yml 파일은 root 계정만 수정 가능하므로 root 계정으로 로그인하거나 sudo를 통해 수정해야 한다.

그렇다면 이젠 위 내용에 대해 한 줄씩 알아보자.

version과 renderer는 Network 버전 2이며 NetworkManager라는 렌더링 툴을 활용해 네트워크 시스템을 관리한다는 의미인데 큰 의미는 두지 않아도 원래 yaml 파일에 기록되어 있을 것이다.

일단 ethernet은 매우 쉽다. "이더넷을 활용한 통신"에서 사용되는 설정이라는 의미이다.

enp0s3은 기본으로 설정되는 NAT(Network Address Translation; 네트워크 주소 변환)라는 의미이다.

NAT는 IP 패킷의 TCP/UDP 포트 숫자와 소스 및 목적지 IP 주소를 재기록함으로써 라우터를 통해 패킷을 주고받을 수 있게 해주는 기술을 말한다.

음... IP 패킷의 포트 숫자와 IP 주소를 변환함으로써 이더넷 및 TCP/IP 규칙으로 패킷 전달을 가능하게 해주는 기술?

만약 네트워크에 대해 제대로 공부했다면 라우터의 "주소 변환"이 생각날 것이다.

그렇다. NAT는 IPv4의 주소 부족 문제를 해결하기 위한 방법으로 고안된 기술로 비공인 네트워크를 사용하는 망에서 외부 공인 네트워크를 사용할 수 있게 하기 위하여 프라이비트 주소를 퍼블릭 주소로 변환해 주는 기능이다.

즉, 주소 변환 관련 설정인 것이다.

여기에서 활용할 값이 0번 과정에서 조사한 VMnet8의 Subnet Address이다.

이 가상 서버에 할당된 퍼블릭 주소가 조사한 Subnet Address 값이기 때문에 이 값을 기본 NAT(enp0s3)에 설정함으로써 주소 변환이 가능해지는 것이다. 또한 VMnet8의 Subnet mask는 255.255.255.0일 텐데 이는 /24로도 나타낼 수 있다.

이 둘을 결합하면 Subnet Address 중 맨 앞의 24비트(192.168.111) 값은 고정적이어야 하며 호스트 영역의 값 "10"은 아무 값이나 입력해도 된다.(나중에 200이나 211 등으로 값을 변경해도 정상적으로 동작함을 확인할 수 있을 것이다)

이렇게 설정하면 최종적으로 설정한 "192.168.111.10/24"가 이 서버의 고정 IP 주소가 되는 것이다.

gateway4는 사실 필수적인 설정은 아니며 아마 설정하면 오히려 WARNING 문구와 함께 deprecated 되었다는 문구가 뜰 것이다. IPv4 주소로 gateway를 설정하겠다는 의미인데 네트워크에서 배웠듯 게이트웨이란 패킷을 다음 중계기로 보내기 위한 IP 주소이다.

하지만 서버라는 고성능 기기를 상대적으로 저기능의 라우터 역할을 하게 하는 것은 스펙 낭비이기 때문에 서버를 라우터로 활용하는 방법은 잘 사용하지 않는다.

거의 사용하지 않는 설정값으로 호스트 영역에는 아무 값이나 들어가도 되지만 주로 1이나 2 같은 작은 숫자를 넣는다.

마지막으로 네임 서버이다.

위에서 설명했듯 "8.8.8.8, 8.8.4.4" 2개의 네임 서버가 설정되었음을 알 수 있다.

이렇게 2개의 네임 서버를 설정할 경우 별다른 문제가 없다면 첫 번째 네임 서버(8.8.8.8)를 활용하며 이에 문제가 발생했을 경우에만 2번째 네임 서버(8.8.4.4)를 활용한다.

참고로 8.8.8.8와 8.8.4.4는 구글 LLC의 무료 공개 DNS 서버 IP 주소이다.

이 값이 아니라 KT의 DNS 서버 IP 주소인 168.126.63.1과 168.126.63.2를 사용해도 된다.

1-1-2. 변경 사항 적용

netplan apply

1-2. CentOS 기준 설정법

1-2-1. CentOS 네트워크 인터페이스 파일 수정

vi /etc/sysconfig/network-scripts/ifcfg-ens33

...
BOOTPROTO=static # static으로 수정
...
# 아래 내용을 추가함
ONBOOT=yes
IPADDR=192.168.111.10
GATEWAY=192.168.111.1
NETMASK=255.255.255.0

CentOS와 우분투의 설정 방법 중 다른 것은 2개 정도 존재한다.

먼저, 수정하는 파일이 다르며 넷마스크를 /24가 아닌 255.255.255.0으로 32비트 값으로 나타낸다는 점이다.

두 번째로 우분투에선 고정 IP 할당과 네임서버를 1개 파일에서 같이 수정하지만 CentOS에선 각각을 담당하는 파일이 다르므로 총 2개의 파일을 수정해야 한다는 점이다.

이 과정은 기기에 고정 IP를 할당하는 방법으로 넷마스크 표현 방식 및 기록 방식이 달라졌을 뿐 의미는 같다.

1-2-2. 네임 서버 설정

vi /etc/resolv.conf

nameserver 8.8.8.8 prefer
nameserver 8.8.4.4

이 경우 8.8.8.8을 메인 네임 서버로 사용하고 만약 그곳에 문제가 생겼다면 8.8.4.4를 사용하겠다는 의미이다.

1-2-3. 변경 사항 적용

systemctl restart network

2. 네트워크 도구 설치

이 과정부턴 CentOS와 우분투의 실행 과정이 유사하다.

단지 CentOS에선 "yum" 명령어를 통해 설치하지만 우분투에선 "apt-get" 혹은 "apt"를 통해 라이브러리를 설치한다는 점이 다르다.

필자는 우분투를 사용하므로 우분투의 경우를 예시로 설명하겠다.

sudo apt-get install net-tools

3. 네트워크 동작 확인

ifconfig

네트워크 인터페이스를 확인하는 명령어이다.

이는 net-tools를 설치해야 사용할 수 있는 명령어이다.

만약 net-tools를 설치하지 않은 상태에서 네트워크 상황을 확인하고 싶다면 아래 명령어를 통해 확인해 보자.

ping www.naver.com

이전에 ICMP에서 말했듯 서버와 클라이언트는 "PING 메시지"를 통해 연결 상태를 확인할 수 있는데 위 명령어는 네이버와 핑 명령어를 통해 연결 상태를 확인하는 것이다.

아마 네임 서버가 제대로 설정되었다면 네이버의 IP 주소를 받을 수 있을 것이고, 네트워크 설정이 제대로 되었다면 패킷을 정상적으로 목적지 IP(네이버)까지 전달하고 받을 수 있을 것이다.