[저수준의 파일시스템과 블록 디바이스 명령]

lsblk: 모든 블록 디바이스 나열

• (list block)

fdisk, parted: 디스크 파티션 관리

• (fixed disk, parted)

blkid: UUID(Universal Unique Identifier)와 같은 블록 디바이스 식별자 및 속성 표시표시

• (block ID)

file -s: 파일 시스템, 파티션 정보 표시

• (-s옵션은 special)

stat, df -i, ls -i: 아이노드와 관련된 정보 표시 및 목록 출력

• (disk free -inode, list -inode)

[가상 파일시스템]

가상 파일 시스템(VFS: Virtual File System)은 클라이언트(시스템 콜)와 개별 파일시스템 사이에 간접 계층을 도입한다. 이때, 개별 파일시스템은 구체적인 디바이스 or 다른 리소스 유형을 위한 연산을 한다.

1. 로컬 파일시스템: 드라이버를 사용하여 로컬 블록 디바이스(HDD, SSD)에 접근한다. ex) ext3, XFS, FAT, NTFS 파일시스템

2. 인메모리 파일시스템: 메인 메모리(RAM)에 상주한다 (장기 저장 디바이스 지원 X) ex) tmpfs

3. 의사 파일시스템: 커널 인터페이스와 디바이스 추상화에 사용된다 (본질적으로는 인메모리) ex) procfs, sysfs, devfs (process, system, device)

4. 네트워크 파일시스템: 드라이버를 사용한다. 로컬이 아닌 원격으로 연결되어 있다. ex) NFS, Samba, Netware

[파일 관련 시스템 콜]

아이노드: chmod, chown, stat 파일: open, close, seek, truncate, read, write 디렉터리: chdir, getcwd, link, unlink, rename, symlink 파일시스템: mount, flush, chroot 그 외: mmap, poll, sync, flock

[범용 최상위 디렉터리]

우분투 리눅스에서 범용 최상위 디렉터리를 나열하고, 모두 설명해봐

아래의 디렉터리들은 리눅스 시스템의 구성요소를 각각 담당하며, 시스템의 안정성과 성능을 유지하는 데 중요한 역할을 합니다.

/ (root): 전체 파일 시스템의 루트 디렉터리입니다. 모든 파일과 디렉터리의 시작 지점입니다.

/usr (user): 사용자가 설치한 소프트웨어, 라이브러리, 문서 등이 저장되는 디렉터리입니다.

/bin (binaries): 기본적인 시스템 실행 파일이 위치하는 디렉터리입니다. 시스템 부팅 및 복구에 필요한 명령어들이 포함되어 있습니다.

/sbin (system binaries): 시스템 관리자를 위한 실행 파일이 위치하는 디렉터리입니다. 주로 시스템 관리에 필요한 명령어들이 여기에 있습니다.

/boot: 부트 로더와 커널 이미지가 저장되는 디렉터리입니다. 시스템이 부팅될 때 필요한 파일들이 여기에 위치합니다.

/dev (devices): 장치 파일들이 저장되는 디렉터리입니다. 시스템의 하드웨어 디바이스와 관련된 파일들이 있습니다.

/etc (et cetera): 시스템의 설정 파일들이 저장되는 디렉터리입니다. 여러 프로그램의 구성과 관련된 설정 파일들이 위치합니다.

/home: 사용자 홈 디렉터리들이 위치하는 디렉터리입니다. 각 사용자는 자신의 홈 디렉터리에서 개인 파일들을 관리합니다.

/lib (libraries): 실행 파일들이 필요로 하는 라이브러리 파일들이 위치하는 디렉터리입니다. 공유 라이브러리들이 여기에 있습니다.

/media: 외부 장치(USB 드라이브, CD-ROM 등)가 자동으로 마운트되는 디렉터리입니다.

/mnt (mount): 일시적으로 파일 시스템을 마운트할 때 사용하는 디렉터리입니다.

/opt (optional): 여분의 소프트웨어 패키지들이 설치되는 디렉터리입니다. 주로 상용 소프트웨어들이 여기에 설치될 수 있습니다.

/proc (process): 커널 및 현재 실행 중인 프로세스에 대한 가상 파일 시스템입니다. 프로세스와 관련된 정보가 여기에 있습니다.

/run: 시스템 부팅 중 생성되는 일시적인 파일이나 데이터를 저장하는 디렉터리입니다.

/srv (service): 시스템에서 제공하는 서비스들의 데이터가 저장되는 디렉터리입니다.

/sys: 리눅스 커널의 파라미터와 상태에 대한 정보를 제공하는 가상 파일 시스템입니다.

/tmp (temporary): 일시적인 파일들이 저장되는 디렉터리입니다. 시스템 재부팅 시 삭제되는 파일들이 여기에 위치합니다.

/var (variable): 시스템 운영 중에 변경되는 변수 데이터들이 저장되는 디렉터리입니다. 로그 파일, 프로세스가 생성하는 임시 파일 등이 여기에 위치합니다.

[의사 파일시스템]

{procfs 의 프로세스별 정보}

attr: 보안 속성 (디렉터리) cgroup, 제어 그룹 (파일) cmdline: 커맨드라인 (파일) cwd: 현재 작업 디렉터리 (링크) environ: 환경변수 (파일) exe: 프로세스 실행 파일 (링크) fd: 파일 디스크립터 (디렉터리) io: 스토리지 I/O (바이트or문자 읽기/쓰기) (파일) limits: 리소스 한계 (파일) mem: 사용된 메모리 (파일) mounts: 사용된 마운트 (파일) net: 네트워크 통계 (디렉터리) stat: 프로세스 상태 (파일) syscall: 시스템 콜 사용량 (파일) task: 작업별(스레드별 정보) (디렉터리) timers: 타이머 정보 (파일)

{sysfs의 디렉터리}

block/: 발견된 블록 디바이스의 심볼릭 링크다. bus/: 커널에서 지원하는 각 물리 버스 유형마다 1개씩 하위 디렉터리가 있다. class/: 디바이스 클래스를 포함한다.

dev/: (major-ID:minor-ID로 특정 디바이스를 고유하게 식별) dev/block/: (블록 단위로 데이터를 읽고 쓰는 디바이스용) ex. 하드 디스크 dev/char/: (문자 단위로 데이터를 읽고 쓰는 디바이스용) ex. 터미널(입출력 장치)

devices/: 커널은 디바이스를 트리 형태로 표현한 정보를 제공한다 firmware/: 펌웨어 관련 속성을 관리한다 fs/: 일부 파일시스템의 하위 디렉터리를 포함한다 module/: 여기서 커널에 로드된 각 모듈의 하위 디렉터리를 찾을 수 있다

{devfs}

/dev 파일시스템은 특수 파일(특정 디바이스를 나타냄)을 호스팅한다 (=파일을 관리하고 제어한다) (=파일을 읽고 쓴다)

• 물리 디바이스: 하드 디스크 (/dev/sda) , USB 드라이브 (/dev/usb) , CD-ROM (/dev/cdrom)
• 가상 디바이스: 난수 생성기 (/dev/random) , 랜덤 디바이스(/dev/urandom) , 루프백 디바이스 (/dev/loop0) , 쓰기 전용 데이터 싱크 (/dev/null)

​

ls -l: ls(리스트) 명령어, l 플래그(long)

​

ls -lh: l 플래그, h플래그(human-readable)

• ls -h

• ls --human-readable

​

ls -R /etc: R플래그(Recursive)

​

pwd: present working directory

​

cd: change directory

• cd .. (상위 디렉토리로 이동)

​

cat /etc/fstab: 파일 내용 출력 (concatenate 연결하다)

​

less /etc/services: 파일 내용 표시 (파일 내용을 조금씩 보여줘서 텍스트 내용을 쉽게 읽을 수 있다)

• PgUp, PgDn, Space Bar(= PgDn), 방향키 위아래(한 줄 단위)

• Q(파일 읽기 Quit)

​

​

​

[리눅스 파일 관리 도구]

​

touch [파일명]

1) 해당 파일이 비존재하는 경우: 빈 파일을 생성

2) 해당 파일이 존재하는 경우: 파일 내용은 그대로 두고, 타임스탬프만 갱신

​

gedit/nano/vi [파일명]: 편집기로 해당 파일을 열기

​

cp [파일명] [디렉터리명]: 해당 파일의 사본을 해당 디렉터리에 만든다

cp [파일명1] [파일명2]: '파일명1'의 사본을 만들어, '파일명2'라는 이름을 붙인다

​

파일 글로빙: 처리할 파일명에 *(와일드카드 문자)를 적용 (globbing 은 global 에서 파생)

​

mv * [디렉터리명]: 현재 디렉터리의 모든 내용을, 해당 디렉터리 위치로 이동

​

mv file* [디렉터리명]: '파일명'이 'file'로 시작하는 파일들을 옮기고, 나머지는 그대로 둔다.

​

mv file? [디렉터리명]: '파일명'이 'file_'인 파일들에만 명령을 적용 (?는 임의의 문자 하나에 대응)

• '파일명' file 포함.

​

​

​

[키보드 트릭]

​

Shift + Ctrl + C , Shift + Ctrl + V : 복, 붙

​

​

​

[의사 파일 시스템]

​

일반적인 파일은,

시스템 재부팅 후에도 안정적으로 접근할 수 있는 데이터의 집합.

​

리눅스 의사 파일은,

시스템 부팅 중/후에 특정 상태를 보여주고자 OS에서 동적으로 생성하는 데이터를 담은 파일.

​

​

​

[맨 페이지]

​

man [명령어]: 해당 명령의 man page(구조화된 문서)를 보여준다.

• man man (매뉴얼 시스템 자체도, 맨 페이지 파일이 있다)

• 키워드 검색: '/' + [검색 패턴] + Enter + [B키, N키]

*

NAME(명령 간략 소개),

SYNOPSIS(구문 구조),

DESCRIPTION(명령문 인자, 플래그 설명)

EXAMPLES(사용 예시)

등등

​

​

​

[Info] 유용함.

​

Menu 부문에서 밑줄은, 하위 메뉴로 이동(Enter)할 수 있는 링크.

• U키: 한 단계 위(Up)로 올라감

• Q키: Info 화면 종료(Quit)

​

​

[시스템 로그]

​

journalctl: 모든 시스템 로그에 접근

• [ journal(기록 or 기록을 담은 문서) + control ]

​

journalctl | grep [문자열]: journalctl의 출력 -> grep 필터로 연결 -> [문자열]을 담은 줄만 출력

​

journalctl | grep [문자열1] | grep error: 문자열 'error'가 포함된 줄만 출력

​

journalctl | grep [문자열1] | grep -v error: 문자열 'error'가 없는 줄만 출력

​

• |(파이프 문자): 어떤 명령(ex. journalctl)의 출력을 다른 명령(grep)의 입력으로 연결.

• grep 명령을 여러 번 적용 가능.

• -v 플래그: in(v)ert 반전.

[ /etc/vsftpd.conf 파일에서 자주 사용하는 옵션 ]

anonymous_enable: 익명 사용자의 접속 허가 여부를 설정 local_enable: 로컬 사용자의 접속 허가 여부 설정 write_enable: 로컬 사용자가 저장, 삭제, 디렉터리 생성 등의 명령을 실행 여부 설정 (익명 사용자는 해당 없음) anon_upload_enable: anonymous 사용자의 파일 업로드 허가 여부 설정 anon_mkdir_write_enable: anonymous 사용자의 디렉터리 생성 허가 여부 설정 dirlist_enable: 접속한 디렉터리의 파일 리스트를 보여줄지 여부 설정 download_enable: 다운로드의 허가 여부 설정 listen_port: FTP 서비스의 포트 번호 설정 (기본: 21번) deny_file: 업로드 금지 파일 지정 ( ex. deny_file={.mpg, *.mpeg, *.avi} ) hide_file: 보여주지 않을 파일 지정 ( ex. hide_file={.gif, *.jpg, *.png} ) max_clients: FTP 서버의 동시 최대 접속자 수 지정 max_per_ip: 1개의 PC가 동시에 접속할 수 있는 접속자 수 지정

vsftpd 에서 익명으로 접속되는 디렉터리는 /srv/ftp 다.

[ /etc/apache2/apache2.conf (아파치 웹 서버의 주 설정 파일) ]

apache2.conf ---- ports.conf ---- mods-enabled ---- ---- ---- ---- *.load ---- ---- ---- ---- *.conf ---- conf-enabled ---- ---- ---- ---- *.conf ---- sites-enabled ---- ---- ---- ---- *.conf

ServerRoot "/etc/apache2"
-> 웹 서버의 설정 파일, 로그 파일 등이 저장되는 최상위 디렉터리

Listen 80 -> 웹 서버의 포트 번호 (ports.conf 에 있음)

include conf.modules.d/*.conf
-> 설정 파일에 포함될 파일의 경로, 파일 이름이 들어 있다.

User ${APACHE_RUN_USER}
-> 웹 서비스를 작동하는 사용자. envvars 파일에 www-data로 설정되어 있다.

Group ${APACHE_RUN_GROUP}
-> 웹 서비스를 작동하는 그룹. envvars 파일에 www-data로 설정되어 있다.

MaxKeepAliveRequests 100
-> 처리할 수 있는 최대 요청 수

<Directory /var/www/> Option Indexes FollowSymLinks AllowOverride All Require all granted

-> 웹 서버는 디렉터리 단위로 설정한다(접근 권한을 다르게 할 수 있다). 'Option Indexes FollowSymLinks'는 현재 디렉터리에서 DirectoryIndex에 지정된 파일이 없다면, 파일 목록을 대신 출력하라는 뜻이다.

1. DB [DB 이름 조회]: SHOW DATABASES; [사용할 DB 지정]: USE DB이름; [DB 생성]: CREATE DATABASE DB이름; [DB 삭제]: DROP DATABASE DB이름;

2. 테이블 운영 [테이블 이름 조회]: SHOW TABLES; [테이블 구조 조회]: EXPLAIN 테이블이름; DESC 테이블이름; [테이블 생성]: CREATE TABLE 테이블이름 (필드이름1 필드타입1, 필드이름2 필드타입2, ... ...); [테이블 삭제]: DROP TABLE 테이블이름; [테이블 수정]: ALTER TABLE 옵션

3. 레코드 입력/삭제/수정 [레코드 입력]: INSERT INTO 테이블이름 VALUES (값1, 값2, ..., ...); [레코드 삭제]: DELETE FROM 테이블이름 WHERE 조건; [레코드 수정]: UPDATE 테이블이름 SET 필드이름1=수정할값1, 필드이름2=수정할값2, ... WHERE 조건;

4. 테이블 조회 [테이블 조회]: SELECT 필드이름1, 필드이름2, ..., ... FROM 테이블이름 WHERE 조건;

IT 인프라 구성 요소를 나열하고, 요소별로 파일을 읽고 쓰고 실행한다는 관점에서 설명해보겠습니다.

IP 인프라 구성 요소는 조직이 정보 기술 시스템을 구축하고 관리하기 위해 필요합니다.

1. 서버 (Server)

파일 읽기: 서버는 다양한 OS에서 동작하며, 파일을 읽어 서버 설정 및 로그 파일과 같은 정보를 확인합니다. 파일 쓰기: 서버는 사용자 및 애플리케이션 데이터를 저장하고 업데이트하기 위해 파일을 씁니다. 파일 실행: 서버는 실행 파일을 실행하여 서비스를 시작하고 운영합니다.

2. 네트워크 장비 (Networking Equipment)

파일 읽기: 네트워크 장비는 구성 파일을 읽어 네트워크 설정 및 보안 규칙을 확인합니다. 파일 쓰기: 네트워크 장비는 로그 파일과 보안 규칙을 기록하고 업데이트합니다. 파일 실행: 네트워크 장비는 라우팅 및 스위칭을 관리하고, 패킷을 라우팅하거나 필터링하여, 데이터 흐름을 관리합니다.

3. 저장 장치 (Storage Devices)

파일 읽기: 저장장치는 데이터를 읽어옵니다. 파일 시스템을 통해 파일을 읽고 DB 서버 or 웹 서버 에서 데이터를 검색합니다. 파일 쓰기: 저장장치는 데이터를 저장하고 보관하기 위해 파일을 씁니다. 파일 서버, DB 서버, 백업 시스템 등이 이용합니다. 파일 실행: 저장장치는 디스크 드라이브 등의 하드웨어 구성 요소를 통해 데이터를 읽고 쓰며, 파일 시스템을 실행하여 데이터를 관리합니다.

4. 클라이언트 장비 (Client Devices)

파일 읽기: 클라이언트 장비는 파일을 읽어와 사용자에게 데이터를 표시하거나, 애플리케이션 설정을 가져옵니다. 파일 쓰기: 일부 클라이언트 장비는 사용자 데이터를 로컬 디스크에 저장하거나, 원격 서버에 데이터를 업로드합니다. 파일 실행: 클라이언트 장비에서는 응용 프로그램 및 운영체제가 실행됩니다. 사용자는 이를 통해 작업을 수행하고 데이터를 처리합니다.

5. 클라우드 서비스 (Cloud Services)

파일 읽기: 클라우드 서비스는 저장된 데이터 및 설정 파일을 읽어와 사용자에게 서비스를 제공합니다. 파일 쓰기: 클라우드 서비스는 사용자 데이터를 저장하고 백업 파일을 생성하며, 사용자 설정을 업데이트합니다. 파일 실행: 클라우드 서비스는 사용자 요청에 따라 가상 서버 및 컨테이너를 실행하고 애플리케이션을 호스팅합니다.

IT 인프라 구성 요소는 파일을 읽고 쓰며 실행하여 시스템 및 서비스를 관리하고 운영합니다.

조직의 IT 환경을 지원하고 개발, 운영, 모니터링, 보안 등 다양한 업무를 수행하는 데 필수적입니다.

원격 서버와 네트워크로부터 파일을 로컬 시스템으로 가져오는 작업 (파일은 로컬 디렉토리에 저장)

설치

다운로드 한 파일 or 패키지 를 시스템의 특정한 위치에 배치하거나, 구성 파일을 수정하는 것.

마운트

로컬 파일 시스템에 있는 디렉토리를, 다른 디렉토리 or 디바이스 에 연결하는 것.

패킷

데이터를 전송하기 위한 작은 조각. 데이터는 패킷 단위로 나뉘어 네트워크를 통해 전송됌. 각 패킷은 {목적지 주소, 출발지 주소, 데이터 조각, 오류 검사, etc} 의 정보를 포함함.

/ 패킷 기반 통신은 데이터를 효율적으로 전송하고, 오류가 발생할 경우 재전송이 가능하도록 하고, 여러 사용자가 동시에 네트워크를 공유하도록 함. / SSH가 데이터를 암호화함으로써 패킷을 전송하는 동안 데이터의 안전함을 보장함.

소켓

소켓은 파일로 추상화한 것.

소켓은 IP와 port로 바인딩되어 있고, 그것을 시스템에서 개발자가 작성한 앱에 통지를 해주고, 그것을 쓰레드가 받아서 [쓰레드 풀에서 사용하냐 / 이벤트 루프로 던지냐] 에 따라 구조가 나뉜다.

[쓰레드 풀]은 병렬성을 높이지만 동시성이 떨어지고, 동시성을 위해 [이벤트 루프]를 이용한 비동기 형태로 진화가 되어 현대의 아키텍처 모습이 되었다.

{서비스, 소켓}은 서로 통신하기 위한 메커니즘이다. 서비스는 백그라운드에서 실행되는 프로그램이다. 소켓은 서비스에 접근할 수 있는 통로 역할을 한다.

systemd 는 System Daemon 의 약자로, 리눅스 시스템 초기화 및 서비스 관리를 담당하는 일종의 시스템 관리자다. systemd 는 부팅 및 종료 프로세스를 조절하고, 서비스를 시작/중지하고, 서비스 간의 의존성을 관리한다.

systemd 가 서비스를 시작하고 관리하면서 {서비스, 소켓}이 함께 사용되어, 특정 포트로 들어오는 연결을 수신하고, 해당 연결을 서비스에 전달한다.

/lib/systemd/system/ 디렉터리에, {서비스 파일, 소켓 파일} 을 함께 저장함으로써, systemd 는 서비스와 소켓 간의 관계를 관리하고, 소켓으로부터 들어오는 요청을, 적절한 서비스로 라우팅하여 처리한다. systemd 가 시스템 전반에서 일관된 방식으로 서비스를 제어하는 것이다.

1) 서버: 이름으로 역할을 알 수 있다 2) 클라이언트/ 서버 시스템: 서비스 요청 측/ 서비스 제공 측 3) 다양한 서버: 네트워크로 전달되는 서비스의 수만큼 존재한다 4) 서버 소프트웨어: 소프트웨어가 제공하는 기능이 서버 그 자체 5) 구축할 서버의 종류, 서버 소프트웨어 선정: 사용자 or 시스템의 요구를 명확히 한다 6) 서버 운용 기간: 시스템의 수명 중 가장 긴 기간 7) 서버, 네트워크: 클라이언트와 서버가 데이터를 전달하는 대전제

2장 네트워크 기초

1) 네트워크 기술: 데이터를 전달하는 근간 기술 2) 프로토콜: 정해진 규칙을 지킴으로써 통신이 가능해진다 3) OSI 참조 모델: 컴퓨터의 통신 기능을 7 layer로 나눈 것 4) 이더넷, MAC 주소: layer 1, layer2 의 프로토콜에 관해서는 이것만 기억하자 5) 스위칭: 이더넷에서의 데이터 전달 6) IP, IP address: 현재의 네트워크를 지탱하는 핵심 프로토콜 7) 다양한 IP 주소: 어디부터 어디까지, 어떻게 사용해야 하는가는 정해져 있다 8) 라우팅: IP 주소를 기반으로 목적지로 패킷을 전송한다 9) ARP: 수신자의 MAC 주소를 알기 위한 구조 10) TCP, UDP: 트랜스포트층의 프로토콜에는 2가지 중 하나를 사용한다 11) 포트 번호 사용 방법: 컴퓨터의 특정 애플리케이션에 데이터를 전달하는 구조 12) NAT, NAPT: LAN과 인터넷을 연결하는 기기에서 IP 주소를 변환한다

3장 서버

1 어떤 서버를 사용할지 선택한다: '어디에, 어떤' 이라는 관점부터 생각한다 2 온프레미스 타입, 클라우드 타입: 자사에서 설비를 보유하는가, 외부에 맡기는가? 3 클라우드 서비스의 종류: 용도와 목적에 따라 구분해서 사용한다 4 자사, 데이터센터: 자사 운용 시 서버 설치 장소 5 서버 가상화: 장점과 단점 6 가상화 소프트웨어의 종류: 하드웨어 위에서 작동하는 것, OS 위에서 작동하는 것 7 서버 컨테이너화: 컨테이너 타입의 가상화 -> 서버의 처리를 격리 8 서버의 함체 형태: 타워형, 렉마운트형, 블레이드형 9 서버를 구성하는 요소: 가격, 처리 능력, 신뢰성을 고려한다 10 리눅스 계열 서버 OS, 윈도우 계열 서버 OS 11 어플라이언스 서버: 특정 서비스만 제공하는 가벼운 선택지 12 가상 어플라이언스 서버: 가상화의 장점 활용 or 성능 우선

4장 사내 서버

1) 서버 배치: 사내 클라이언트에 서비스 제공 2) DHCP 서버: LAN 안의 PC의 네트워크 설정을 자동화 3) DNS 서버: IP 주소 - 도메인명 상호 변환하는 구조 4) DNS 서버 다중화: 웹서버로의 연결을 보장하기 위해 필수 5) 작업 그룹, 액티브 디렉터리 도메인: 윈도우의 네트워크에서는 이중 어딘가에 소속된다 6) 액티브 디렉토리 도메인 구성의 장점: 윈도우 네트워크 환경을 가진 많은 기업들이 도입하는 이유 7) 파일 서버: 다양한 파일을 모아서, 효율적으로 공유한다 8) SSO 서버: 비밀번호 관리의 고민을 시스템으로 해결한다 9) SIP 서버: IP 전화 시스템에서 통신 상대를 특정하거나 호출한다 10) 프락시 서버: 클아이언트의 대리, 웹사이트와 통신한다 11) 송신 메일 서버: 전자 메일을 수신지 사용자가 이용하는 서버까지 보낸다 12) 수신 메일 서버: 서버에 보관하고 있는 메일을 사용자에게 전달한다 13) Microsoft Exchange Server: 메일 서비스, 그룹웨어 서비스를 제공한다

5장 공개 서버

1) 서버 배치: 인터넷상의 클라이언트에 서비스를 제공한다 2) 온프레미스 환경의 서버를 공개한다: 공개까지의 6단계 3) 클라우드 환경의 서버를 공개한다: 공개까지의 7단계 4) 웹의 3계층 모델: 웹사이트는 3가지 서버로 구성된다 5) HTTP 서버의: 인터넷에서 다양한 정보를 전송한다 6) HTTPS 서버: 정보의 도청/변조/위장/ 을 방지한다 7) 2가지 암호화 기술: SSL/TLS 에서는 2가지를 조합해 사용한다 8) SSL/TLS 로 연결이 되기까지: 디지털 인증서/인증국/암호화 기술/ 관계 9) 애플리케이션 서버: 동적 페이지를 생성하는 웹서비스 시스템의 중심에서 작동한다 10) 데이터베이스 서버: 동적인 웹 콘텐츠 데이터를 관리한다 11) CDN: 안정적이고 빠르게 웹서비스를 제공한다 12) FTP 서버: 파일 배포 or 업로드 구조 를 제공한다 13) VPN 서버: 인터넷을 통한 안전한 통신을 실현한다

6장 서버를 장애로부터 지킨다

1) 서버와 장애는 소꿉친구: 장애 대응을 위한 다양한 기술 2) RAID: 스토리지 드라이브의 고속화와 데이터 보호를 실현한다 3) 티밍: 서버의 통신 내장애성 향상과 대역 확장을 실현한다 4) UPS: 전원 장애로부터 서버를 보호한다 5) 클러스터: 여러 대의 서버로 장애에 대비한다 6) 서버 부하 분산 기술: 여러 서버에 통신을 분배하는 방법들 7) 광역 부하 분산 기술: 지리적으로 멀리 떨어진 곳에 서버를 분산해 재해에 대비한다

7장 서버 보안

1) 인터넷에 숨은 위협과 취약성: 보안 리스크를 올바르게 인식하자 2) 방화벽으로 서버를 보호한다: 인터넷으로부터의 위협에 대항한다 3) 방화벽 선정 방법: 필요한 기능/비용/운용 관리 능력/ 을 고려한다 4) 보안 영역, 서버 배치: 외부 공개 여부에 따라 위치가 달라진다 5) IDS, IPS: 서버로의 부정 침입을 감지하거나 방어한다 6) 차세대 방화벽: 보안 기능을 높여 관리자에게 도움 되는 기능도 제공한다 7) 웹 애플리케이션 방화벽: 웹서비스를 노리는 다양한 공격을 물리친다 8) 메일 보안 대책: 메일 내용까지 포함해 제어할 수 있다

8장 서버 운용 관리

1) 서버 운용 관리에서 수행하는 작업: 관리자는 어떤 일들을 해야 하는가 2) 서버 원격 관리: 온프레미스, 클라우드 대부분 동일하다 3) 업데이트 프로그램 설치: 서버 OS 업데이트는 신중하게 수행한다 4) 업데이트 프로그램 전송 관리: Windows Update 대체 서버를 사내에 준비한다 5) 백업과 복원: 서버의 데이터 소실에 대비한다 6) 명령어로 네트워크 상태를 확인한다: 관리에 사용하는 단골 명령어를 기억하자 7) 명령어로 장애를 확인한다: 네트워크의 어느 부분에 장애가 발생했는지 밝힌다 8) NTP 서버: 서버와 네트워크 기기의 시계를 맞춘다 9) Syslog 서버: 서버 or 네트워크 기기 의 로그를 수집한다 10) SNMP 서버: 서버와 네트워크 기기의 정보를 얻고 설정한다

ㅇ출처: 책 <서버의 기초>, 위키북스 출판

01 웹: 전 세계에 퍼져 있는 하이퍼링크의 그물 02 인터넷 & 웹: 각각 만들어진 것을 융합한다 03 다양한 웹의 용도: 웹 사이트에서 고도의 애플리케이션으로 발전 04 HTML과 웹브라우저: 태그를 사용해 문서에 의미를 부여한다 05 웹서버 & HTTP: 웹을 지탱하느느 기본 구조 06 웹페이지가 표시되는 흐름: URL에 맞춰 HTML이 전송된다 07 정적 페이지 & 동적 페이지: 변하지 않는 페이지 & 변하는 페이지 08 동적 페이지의 구조: 프로그램으로 HTML을 생성한다 09 웹 표준화: W3C를 통해 웹은 표준화되어 있다 10 웹의 설계 사상: 웹 기술에서 권장되는 2가지 사상 (RESTful / 시맨팁 웹)

2. 웹 & 네트워크 기술

01 웹을 실현하는 컴퓨터 네트워크: 인터넷의 개요 02 인터넷의 표준 프로토콜: 프로토콜의 역할 03 TCP/IP: 데이터 전송을 담당하는 프로토콜 04 IP 주소 & 포트 번호: 데이터 도착지를 식별한다 05 URL & 도메인: 사람이 이해할 수 있는 형태로 웹사이트 위치를 나타낸다 06 DNS: 도메인과 IP 주소를 변환한다 07 HTTP: 웹브라우저와 웹서버 사이의 전달

3. HTTP 에서의 전달 구조

01 HTTP 메시지: HTTP 로 전달하는 데이터의 구조 02 TTP 요청 / HTTP 응답: 요청과 응답의 차이 03 HTTP 메서드: 웹서버에 대한 요청의 종류 04 상태 코드: 응답 결과의 종류를 나타내는 숫자 05 메시지 헤더: 헤더 필드에 포함된 상세 정보 06 TCP를 통한 데이터 통신: 데이터가 확실하게 도달하는 구조 07 HTTP/1.1 의 통신: 현재 주류 데이터 통신 방식 08 HTTP/2 통신: 스트림 다중화를 통해 고속화한다 09 HTTP/2 에서의 개선점: 고속화를 위한 다양한 기술 10 HTTPS 의 구조: 암호화를 통해 안정성을 높인다 11 HTTPS 통신: 암호화 방식을 맞춘 뒤 통신을 시작한다 12 스테이트풀 & 스테이트리스: 상태 유지 여부 13 쿠키: 스테이트리스 에서 상태를 유지하는 구조 14 세션: 일련의 처리의 흐름을 관리한다 15 URI: 다양한 리소스를 식별하는 기술 방법

4. 웹의 다양한 데이터 형식

01 HTML: HTML 의 구조와 버전 02 웹페이지에서 사용되는 이미지 형식: 형식별 특징을 바탕으로 구분해서 사용한다 03 XML: 범용성을 높이는 방향으로 진화한 마크업 언어 04 CSS: 형태를 담당하는 스타일 시트 05 스크립트 언어: 동적 처리를 실현하는 프로그래밍 언어 06 DOM: 스크립트에서 HTML을 조작하는 구조 07 JSON: 자바스크립트에서 탄생한 범용 데이터 형식 08 피드: 웹사이트의 업데이트 정보를 전송한다 09 마이크로 포맷: 웹페이지에 상세한 '의미'를 삽입한다 10 음성/동영상 전송: 거대한 데이터를 원활하게 전송하는 기술 11 미디어 타입: 다양해지는 열람 환경들에 대응한다

5. 웹 애플리케이션 기본

01 웹 애플리케이션의 3티어 구조: 3계층으로 나누어 부하를 분산할 수 있다 02 MVC 모델: 애플리케이션 내부 구조를 결정하는 설계 사상 03 프레임워크: 템플릿을 사용한 효율적 개발 04 웹서버: 웹 클라이언트와의 창구를 담당한다 05 웹 클라이언트: 브라우저만은 아니다 06 애플리케이션 서버: 동적 페이지의 핵심을 담당한다 07 데이터베이스 관리 시스템: 웹 애플리케이션 데이터를 축적한다 08 캐시 서버: 통신을 중개해서 서버 붇마을 줄인다 09 Ajax: 체감 응답을 향상시키는 비동기 통신 기술 10 웹 프로그래밍: 클라이언트 사이드 & 서버 사이드 로 나뉜다 11 Wep API: 프로그램이 서비스를 사용하는 창구 12 매시업: 여러 웹서비스를 조합한다 13 CGI: 서버 사이드 스크립트는 기동하는 구조 14 서버 간 연동: 서버 간 통신에 사용되는 프르토콜

6. 웹 보안과 인증

01 웹 시스템 보안: 보안을 이해하기 위한 기본 용어를 익힌다 02 비밀번호 해킹, DoS 공격: 비밀번호 분석과 접근 부하를 통한 공격 기법 03 웹 시스템의 특징을 사용한 공격: 쿠키나 URL의 구조를 사용한 공격 방법 04 웹 애플리케이션의 취약성을 노린 공격: 스크립트를 보내는 공격 방법 05 웹 시스템의 취약성: 보안 구멍을 통한 공격 06 방화벽: 외부로부터의 접근을 제한하는 장치 07 IDS, IPS: 부정 접근을 감지하는 장치 08 WAF: 통신 내용을 보고 공격을 막는 장치 09 암호화: 통신 경로와 저장 데이터 2가지를 암호화한다 10 공개키 인증서: 통신 상대가 실재 존재함과 암호화 통신이 가능함을 증명한다 11 인증: 인증 기능의 아웃소싱화가 진행된다 12 허가: 서비스를 넘나드는 기능 사용을 구현한다 13 캡챠(CAPTCHA): 프로그램을 사용한 부정을 방지한다

7. 웹 시스템 구축과 운용

01 제공할 서비스 검토: 제공할 서비스로부터 필요한 기능을 도출한다 02 사용 언어 & 소프트웨어 검토: 애플리케이션의 특징에 맞게 결정한다 03 네트워크 구성 검토: 역할별로 네트워크를 분할한다 04 서버 구성 검토: 비용과 가용성의 균형을 고려해 구성한다 05 서버 기반 검토: 온프레미스, 임대, 클라우드 06 부하 분산: 접근 부하를 분산하는 설계 07 서버 설계/구축: 하드웨어 구성, OS, 미들웨어 설정과 테스트 08 데이터베이스 설계: 저장해야 할 데이터를 도출해 데이터베이스를 설계한다 09 애플리케이션 설게: 전체 설계에서 모듈 단위 설계로 진행한다 10 백업 운용: 장애를 예측하고, 백업 방법과 빈도를 결정한다 11 로그 운용: 로그는 시스템 상태를 파악할 수 있는 중요한 정보원 12 웹사이트의 성능: 응답 시간으느 만족도를 나타내는 지표 13 취약성 진단: 사소한 취약성의 확인과 대책이 필요하다

ㅇ출처: 책 <웹의 기초>, 출판사 위키북스

RDBMS의 DB와 테이블, 엑셀의 파일과 시트/테이블은 데이터 구조화와 저장을 위한 개념으로 유사

수학에서 파생된 relation 개념

set

• 서로 다른 elements 를 가지는 collection
• 하나의 set 에서 elements 의 순서는 중요하지 않다
  데카르트 곱
  Cartesian product A X B = {(a, b) | a∈A and b∈B}

relation

• 데카르트 곱(Cartesian)의 부분집합(subset )
• tuples 의 집합
  binary relation ⊆ A X B
  n-ary relation ⊆ X₁ x X₂ x X₃ x ... x Xₙ

relational data model

• 용어 정리

domain: set of atomic values domain name: domain 이름 attribute: domain이 relation에서 맡은 역할 이름 tuple: 각 attribute의 값으로 이루어진 리스트. 일부 값은 NULL 일 수 있다 relation: set of tuples (또는 relation state 인 경우도 있음) relation name: relation 의 이름

relation schema

• relation 의 구조를 나타낸다
• relation 이름과 attributes 리스트로 표기된다
• attribute 와 관련된 constraints 도 포함한다
  degree of a relation
• relation schema 에서 attributes 의 수
  relational database
• relational data model 에 기반하여 구조화된 database
• relational database 는 여러 개의 relations 로 구성된다
  relational database schema
• relational schemas set + interity constraints set

relation 의 특징

• relation 은 중복된 tuple 을 가질 수 없다 (relation is set of tuples)

• relation 의 tuple 을 식별하기 위해 attribute 의 부분 집합을 key 로 설정한다

• relation 에서 tuple 의 순서는 중요하지 않다

• 하나의 relation 에서 attribute 의 이름은 중복되면 안 된다

• 하나의 tuple 에서 attribute 의 순서는 중요하지 않다

• attribute 는 atomic 해야 한다 (composite 또는 multivalued attribute 는 허용 안됌)

NULL 의 의미

• 값이 존재하지 않는다
• 값이 존재하지만, 아직 그 값이 무엇인지 알지 못한다
• 해당 사항과 관련이 없다

여러 의미로 사용될 수 있기에 최대한 NULL 을 자제하는 게 좋다

key 설명

슈퍼키(superkey)

• relation 에서 tuples 를 unique 하게 식별할 수 있는 attributes set
  후보키(candidate key)
• key 또는 minimal superkey 라고도 함
• 어느 한 attribute 라도 제거하면, unique 하게 tuples 를 식별할 수 없는 /super key/
  기본키(primary key)
• relation 에서 tuples 를 unique 하게 식별하기 위해 선택된 candidate key
• attribute 수가 적은 걸로 선택하는 게 편함
• 대체로, 이름 밑에 언더바("_")가 있음
  고유키(unique key) 또는 대체키(alternate key)
• 기본키(primary key)로 선택되지 않은, 후보키(candidate key)
  외래키(foreign key)
• 다른 relation 의 PK(Primary Key)를 참조하는 attributes set

constraints 설명

• relational database 의 relations 들이 언제나 항상 지켜줘야 하는 제약 사항
• DB의 일관성을 위해 보장해야함
• 위반하면 주로 error 를 받게 됌

implicit constraints

• relational data model 자체가 가지는 constraints
• relation 은 중복되는 tuple 을 가질 수 없다
• relation 내에서는 같은 이름의 attribute 를 가질 수 없다
  explicit constraints (또는 schema-based constraints)
• 주로 DDL을 통해 schema 에 직접 명시할 수 있는 constraints

explicit constraints 종류

1. domain constraints

• attribute 의 value 는 해당 attribute 의 domain 에 속한 value 여야 한다.

2. key constraints

• 서로 다른 tuples 는 같은 value 의 key 를 가질 수 없다

3. NULL value constraint

• attribute 가 NOT NULL 로 명시됐다면 NULL 을 값으로 가질 수 없다

4. entity integrity constraint

• primary key 는 value 에 NULL 을 가질 수 없다 (여러 tuples 이 NULL 값을 가진다면, 더이상 tuple을 유니크하게 식별하지 못하기 때문)

5. referential integrity constraint

• FK 와 PK 와 도메인이 같아야 하고, PK 에 없는 values 를 FK 가 값으로 가질 수 없다

용어

database (DB)

• 전자적으로(electronically) 저장되고 사용되는 관련 있는(related) 데이터들의 조직화된 집합(organized collection)

DBMS (database management systems)

• 사용자에게 DB를 정의하고 만들고 관리하는 기능을 제공하는 소프트웨어 시스템

• ex) logical data models 임! PostgreSQL, MySQL, ORACLE DATABASE, Microsoft SQL Server

• DB를 정의하다 보면 부가적인 데이터(metadata)가 발생한다

metadate (= catalog) (= data about data)

• database를 정의하거나 기술하는 data
• DBMS를 통해 저장/관리 된다
• ex) 데이터 유형, 구조, 제약 조건, 보안, 저장, 인덱스, 사용자 그룹 등등

DB system

• { database , DBMS , 연관된 applications }

(순수하게 database만을 뜻할 수도 있음)

data models

• DB의 구조(structure)* 를 기술하는데 사용될 수 있는 개념들이 모인 집합
• DB 구조* 를 추상화해서 표현할 수 있는 수단을 제공한다
• data model은 여러 종류가 있고, 추상화 수준과 DB 구조화 방식이 다르다
• DB에서 읽고 쓰기 위한 기본적인 동작들(operations)도 포함한다

* DB 구조: 데이터 유형, 데이터 관계(relations), 제약 사항(constrainst) 등등

conceptual (high-level) data models

• 일반 사용자들이 쉽게 이해할 수 있는 개념들로 이뤄진 모델
• 추상화 수준이 가장 높음
• 비즈니스 요구 사항을 추상화하여 기술할 때 사용
• ex) Entity-Relationship model (ER diagram으로 표현)

logical (representational) data models

• 이해하기 어렵지 않으면서도 디테일하게 DB를 구조화 할 수 있는 개념들을 제공
• 데이터가 컴퓨터에 저장될 때의 구조와 크게 다르지 않게 DB 구조화를 가능하게 함
• 특정 DBMS 또는 storage 에 종속되지 않는 수준에서 DB를 구조화할 수 있는 모델
• ex) relational data model (개발자가 가장 많이 사용), object data model, object-relational data model

physical (low-level) data models

• 컴퓨터에 데이터가 어떻게 파일 형태로 저장되는지를 기술할 수 있는 수단을 제공
• data format, data orderings, access path 등등
• access path: 데이터 검색을 빠르게 하기 위한 구조체 ex) index

데이터베이스의 schema & state

database schema

• data model 을 바탕으로 database 의 구조를 기술한 것
• schema 는 database 를 설계할 때 정해지며, 한번 정해진 후에는 자주 바뀌지 않는다

database state

• database 에 있는 실제 데이터는 자주 바뀔 수 있다
• 특정 시점에 database 에 있는 데이터를 databse state (= snapshot) 라고 한다
• database 에 있는 현재 instances 의 집합

three-schema architecture

• DB system 을 구축하는 architecture 중의 하나
• user application 으로 부터 물리적인 DB를 분리시키는 목적
• 3가지 level이 존재하며, 각각의 level 마다 schema 가 정의되어 있다
• 각 레벨이 독립적이라서 다른 레벨에서의 변화가 상위 레벨에 영향을 주지 않는다
• 대부분의 DBMS 가 3 level 을 완벽하게 or 명시적으로 나누지는 않는다
• 데이터가 존재하는 곳은 internal level 이다
  1) external level(= view level) external schemas (= user views)

  2) conceptual level conceptual schemas

  3) internal level internal schemas

internal schema

물리적으로 데이터가 어떻게 저장되는지를 physical data model 을 통해 표현

datda storage, data structure, access path 등등 실체가 있는 내용 기술

external schema

external views 또는 user views 라고도 함

특정 유저들이 필요로 하는 데이터만 표현

그 외 알려줄 필요가 없는 데이터는 숨김

logical data model 을 통해 표현

conceptual schema

전체 database 에 대한 구조를 기술

물리적인 저장 구조에 관한 내용은 숨김

entities, data types, relationships, user operations, constraints 에 집중

loical data model 을 통해 기술

database language

DDL (Data Definition language)

• conceptual schema 를 정의하기 위해 사용되는 언어
• 간혹, internal schema 까지 정의하는 경우도 있음

SDL (Storage Definition Language)

• internal schema 를 정의하는 용도로 사용되는 언어
• 요즘은 특히 relational DBMS 에서는 SDL 이 거의 없고, 파라미터 등의 설정으로 대체됌

VDL (View Definition language)

• external schemas 를 정의하기 위해 사용되는 언어
• 대부분의 DBMS 에서는 DDL 이 VDL 역할까지 수행

DML (Data Manipulation Language)

• database 에 있는 data 를 활용하기 위한 언어
• data 추가/삭제/수정/검색 등등의 기능을 제공하는 언어

오늘날의 DBMS 는 통합된 언어로 존재한다 (DML, VDL, DDL 이 따로 존재하지 않는다)

ex) relational database language: SQL

동기화(synchronization)를 위한 전략 3가지

스레드 또는 프로세스의 동기화를 위해 자주 사용되는 락 메커니즘

1. 스핀락(spinlock)
2. 뮤텍스(mutext)
3. 세마포(semaphore)

뮤텍스는 != 바이너리 세마포

00:00 오프닝 00:10 race condition, 동기화, 임계 영역 뜻 00:51 mutual exclusion 어떻게 보장할 수 있나? 01:19 spinlock (feat. CPU의 도움) 07:08 spinlock의 단점 07:31 mutex 11:12 mutex가 spinlock 보다 항상 좋은가? 13:05 semaphore 18:03 mutex와 binary semaphore는 같은가? 21:47 참고사항 22:13 클로징

용어 정리

경쟁 조건(race condition)

• 여러 프로세스/스레드 가 동시에 같은 데이터를 조작할 때, 타이밍이나 접근 순서에 따라 결과가 달라질 수 있는 상황

동기화(synchronization)

• 여러 프로세스/스레드 를 동시에 실행해도 공유 데이터의 일관성을 유지하는 것

임계 영역(critical section)

• 공유 데이터의 일관성을 보장하기 위해 [하나의 프로세스/스레드 만 진입해서 실행] (=mutual exclusion) 가능한 영역

어떻게 (mutual exclusion) 을 보장할 수 있을까?

락(lock)을 사용하자!

여러 프로세스/스레드 가 락(lock) 을 획득하기 위해 경합하고, 이긴 것만 임계 영역(critical section)에 들어가서 실행하고, 실행이 끝나면 임계 영역(critical section)을 빠져 나오면서 락(lock)을 반환한다

스핀락(spinlock)

• 락을 가질 수 있을 때 까지 반복해서 시도
• 단점: 기다리는 동안 CPU를 낭비한다

뮤텍스(mutex)

• 락을 가질 수 있을 때 까지 휴식

아래의 두 조건을 만족할 경우, 스핀락(spinlock)이 뮤텍스(mutex)보다 이점이 더 크다.

1) 멀티 코어 환경 이고, 2) critical section 에서의 작업이 컨텍스트 스위칭보다 빨리 끝난다면,

동기화를 모르면 예상치 못한 오류가 발생할 수 있다. 특히 멀티스레딩 기반의 백엔드 API를 만들 때 중요하다.

스레드 뿐만 아니라, 프로세스 끼리도 공유되는 자원에 동시에 접근하고 있다면, 같은 문제가 발생할 수 있다.

00:00 오프닝 00:13 동기화 없으면 생길 수 있는 일 08:32 race condition(경쟁 조건)이란? 08:48 synchronization(동기화)란? 09:02 어떻게 동기화 시킬 것인가? 10:47 critical section(임계 영역)이란? 11:11 critical section 문제를 해결하는 뼈대 11:52 critical section 문제 해결책의 조건 12:58 프로그래밍 할 때 thread safe한지 확인 14:44 클로징

용어

경쟁 조건(race condition)

• 여러 프로세스/스레드가 동시에 같은 데이터를 조작할 때, 타이밍이나 접근 순서에 따라 결과가 달라질 수 있는 상황

동기화(synchronization)

• 여러 프로세스/스레드를 동시에 실행해도 공유 데이터의 일관성을 유지하는 것

임계 영역(critical section)

• 공유 데이터의 일관성을 보장하기 위해 하나의 프로세스/스레드만 진입해서 실행 가능한 영역

critical section problem

해결책이 되기 위한 조건

1. 상호 배제 (mutual exclusion)
2. 진행 (progress)
3. 한정된 대기 (bounded waiting)
   3가지 조건 모두를 만족해야함

프로세스는 특성에 따라 CPU bound나 I/O bound로 구분된다. 각각 프로그램의 스레드 개수를 어떻게 정해야 하는지 다르다.

용어

CPU (Central Processing Unit)

• 프로세스의 명령어를 해석하고 실행하는 장치

I/O (Input/Output)

• 파일을 읽고 쓰는 것
• 네트워크의 어딘가와 데이터를 주고 받는 것
• 입출력 장치와 데이터를 주고 받는 것

버스트(Burst)

• 어떤 현상이 짧은 시간 안에 집중적으로 일어나는 일

CPU 버스트

• 프로세스가 CPU에서 한번에 연속적으로 실행되는 시간

I/O 버스트

• 프로세스가 I/O 작업을 요청하고 결과를 기다리는 시간

프로세스의 인생은, CPU 버스트와 I/O 버스트의 연속

CPU bound 프로세스

• CPU burst가 많은 프로세스

  • ex1) 동영상 편집 프로그램
  • ex2) 머신러닝 프로그램 (I/O 작업이 적고, 연산 작업이 많음)

• 적절한 스레드 수

  • (CPU 수 + 1)

I/O bound 프로세스

• I/O burst가 많은 프로세스

  • ex1) [일반적인] 백엔드 API 서버

    HTTP 요청 -> DB 서버 or 캐시 서버에 데이터를 요청 -> 요청한 데이터를 가공 -> HTTP 응답

  • 적절한 스레드 수
    • 컴퓨터 스펙, 프로그램의 특성 등등 상황을 고려해서 찾아야함

프로세스는 메모리에 올라가서 사용자에 의해 컴퓨터 상에서 실행 중인 프로그램이다. 그 프로세스의 실행 정보 또는 상태(메모리 주소 공간, 프로세스 ID, etc)는 OS에 의해 관리된다.

하지만 실제로 CPU 코어에서 실행되는 것은 스레드다. 따라서 CPU 코어에서 컨텍스트 스위칭이 되는 대상도 언제나 스레드다.

이때 같은 프로세스에 속한 스레드 간에 컨텍스트 스위칭이 발생한다면, '스레드 컨텍스트 스위칭'이라고 부른다.

다른 프로세스에 속한 스레드 간에 컨텍스트 스위칭이 발생한다면, '프로세스 컨텍스트 스위칭'이라고 부른다.

멀티태스킹 방식

CPU 사용 시간을 아주 짧게 쪼개서 time slice 단위로 여러 스레드들이 번갈아 CPU에서 실행될 수 있도록 하는 방식이다 (스레드들은 같은 프로세스 소속일 수도 있고 다른 프로세스 소속일 수도 있다)

time slice가 '고정'값일까?

OS 마다 다르겠지만, 적어도 리눅스에서는 고정이 아니다

time slice가 '고정'값이면 어떤 문제가 생길까?

만약 동시에 실행돼야 하는 스레드 수가 계속 늘어난다면, 스레드가 실행되고 다시 자기 차례가 올 때 까지 기다리는 시간이 점점 더 길어지게 될 것이다 그리고 그만큼 스레드의 응답성도 떨어지게 된다

컨텍스트 스위칭이 많아질수록 그로인한 CPU 오버헤드도 더 많아질 것이다. 그러므로 스레드를 너무 많이 만들면 좋지 않다.

컨텍스트 스위칭(context switching)

• 실행 주체: OS 커널(kernel)

• 실행 이유: 여러 프로세스/스레드 를 동시에 실행시키기 위해 필요함

• 정의: CPU/코어 에서 실행 중이던 프로세스/스레드 가 다른 프로세스/스레드 로 교체되는 것

• 실행 시점:

주어진 time slice(quantum)를 다 사용했거나, I/O 작업을 해야하거나, 다른 리소스를 기다려야 하거나, 등등의 경우에 발생함

컨텍스트 스위칭은 아래와 같은 작업을 수행한다 (넘버는 실행 순서와는 관계 없음)

1. 현재 실행 중인 프로세스 혹은 스레드의 context 백업 (가령, CPU 레지스터 값들, 어디까지 실행됐는지 등)

2. CPU 캐시를 비움(flush)
   (CPU 마다 L1, L2 cache에 대한 동작이 다를 수 있음, 심지어 안 비울 수도 있음)

3. TLB(table lookaside buffer)를 비움

4. MMU(memory management unit)를 변경

프로세스 컨텍스트 스위칭: {1, 2, 3, 4번}을 모두 수행하지만 스레드 컨텍스트 스위칭: {1번}만 수행한다

컨텍스트(context)

• 프로세스/스레드의 상태
• CPU, 메모리 등등

  OS 커널(kernel)

• 각종 리소스를 관리/감독하는 역할

구체적으로 어떤 과정으로 일어나는가?

공통점

• 커널 모드에서 실행
• CPU의 레지스터 상태를 교체

차이점

1. 스레드 컨텍스트 스위칭(같은 프로세스의 스레드들끼리의 스위칭)

   • 메모리 주소 관련 처리를 하지 않음 (*그래서 더 빠름)

2. 프로세스 컨텍스트 스위칭(다른 프로세스끼리의 스위칭)

   • 가상 메모리(virtual memory) 주소 관련 처리를 추가로 수행

가상 메모리(virtual memory)

실제 물리적인 메모리가 커버할 수 있는 용량에 비해 컴퓨터 상에서 실행되는 프로세스들이 사용하는 메모리 총량은 더 많아서 그 물리적인 메모리 용량의 한계를 극복하기 위해 나온 개념

모든 프로세스는 자신 만의 virtual memory 영역을 가지는데, 예를 들어, 프로세스 A와 프로세스 B 모두 각각 가상(virtual) memory 주소 0에서 주소 10000000까지의 범위를 가지지만, 실제 메모리 상에서는 서로 다른 위치에 저장이 됌

예를 들어, 프로세스 A의 가상 메모리 주소 100번에 위치한 데이터와 프로세스 B의 가상 메모리 주소 100번에 위치한 데이터는 다름. 가상 메모리 주소는 둘 다 동일하게 100번이라도 이 주소 100번이 실제 메모리 상에서 맵핑되는 위치는 다르기 때문임

컨텍스트 스위칭이 미치는 간접적인 영향은?

캐시 오염 (cache pollution)

컨텍스트 스위칭(C.S)가 CPU를 잡아먹기 때문에, 너무 자주 발생하면 안 좋음

유저 관점에서 컨텍스트 스위칭은?

순수한 오버헤드 (pure overhead)

입출력 장치와 연관이 있는 I/O(입출력) 작업 시에 컨텍스트 스위칭이 발생하는 이유는, 입출력 장치에서 작업 처리를 하는 동안에는 CPU는 일 없이 기다리고 있어야 하기 때문이다.

기다리는 동안 CPU를 점유하고 있으면 CPU 낭비가 되기 때문에 그렇게 하지 않고 컨텍스트 스위칭이 돼서 다른 프로세스/스레드가 CPU를 사용할 수 있다.

백엔드를 예로 들면, 백엔드에서 가장 많이 사용하는 I/O는 네트워크 I/O이다. 백엔드 서버에서 다른 서버에 데이터를 보내거나 혹은 요청했을 때 그 데이터가 네트워크 공간을 이동하는 동안에는, 혹은 그 데이터가 다른 서버에서 처리되는 동안에는, 백엔드 서버의 CPU가 할 수 있는 일이 아무것도 없다.

이런 상태에서도 네트워크 I/O 작업을 요청한 프로세스/스레드가 CPU를 점유하고 있다면 CPU 낭비가 발생하기 때문에 그렇게 하지 않고 컨텍스트 스위칭을 해줘서 다른 기다리고 있는 프로세스/스레드가 CPU를 사용할 수 있도록 해주는 거다.

어떻게 여러 프로그램이 동시에 실행되는가? (원리)

운영체제 관점에서의 스레드 (!= 유저 관점에서의 스레드)

프로그램(program)

• 컴퓨터가 실행할 수 있는 명령어들의 집합

  프로세스(process)

• 컴퓨터에서 실행 중인 프로그램
• 각각의 프로세스는 [독립된 메모리 공간] 을 할당 받음 -> [독립된 메모리 공간] 에 각각의 프로세스의 명령어들과 데이터를 가짐

  CPU(Central Processing Unit)

• 명령어를 실행하는 연산 장치

  메인 메모리(main memory)

• 프로세스가 CPU에서 실행되기 위해 대기하는 곳
• 물론, 프로세스의 명령어들과 실행중인 데이터가 있기도 함

  I/O(Input/Output)

• 파일을 읽고 쓰는 것
• 네트워크의 어딘가와 데이터를 주고 받는 것
• 입출력 장치와 데이터를 주거나 받는 것

단일 프로세스 시스템

• 한 번에 하나의 프로그램만 실행됌 (초창기의 시스템의 경우)

• 단점: CPU 사용률이 좋지 않음

  멀티프로그래밍(multiprogramming)

• 여러 프로그램을 메모리에 올려놓고 동시에 실행됌

• 장점: CPU 사용률을 극대화시킴

• 단점: CPU 사용 시간이 길어지면, 다른 프로세스는 계속 대기

  멀티태스킹(multitasking)

• 프로세스가 한번 CPU를 사용할 때, 아주 짧은 시간(=quantum)만 실행됌
• 프로세스의 응답 시간 최소화가 목적 (사용자 관점에서는 동시에 실행되는 것처럼 느낌)

• 단점1: 하나의 프로세스가 동시에 여러 작업을 수행하지는 못함 // 프로세스의 컨텍스트 스위칭은 무거운 작업 //

• 단점2: 프로세스 간에 데이터 공유가 까다로움

• 단점3: 새로 등장한 [듀얼 코어] 를 잘 쓰고 싶음

  스레드(thread)

• 프로세스는 1개 이상의 스레드를 가질 수 있다
• CPU에서 실행되는 단위 (=unit of execution)
• 같은 프로세스의 스레드 간에는 컨텍스트 스위칭이 가볍다
• 같은 프로세스의 스레드 간에는 메모리 영역을 공유한다
• 그럼에도 각각의 스레드는 고유한 영역(=스택)이 있다

  멀티스레딩(multithreading)

• 하나의 프로세스가 (스레드로) 동시에 여러 작업을 실행하는데 목적

  멀티프로세싱(multiprocessing)

• 2개 이상의 프로세서 or 코어 를 활용하는 시스템

확장된 멀티태스킹 개념

• 여러 프로세스와 여러 스레드가 아주 짧게 쪼개진 cpu time을 나눠 갖는 것

최적화 문제 (optimization problem)

• 문제를 해결하는 최적의 답(optimal solution)을 찾아야 하는 문제

• 최적해는 하나 이상일 수 있다

• maximum 또는 minimum [value] 를 가지는 {solution} 을 찾는 문제들이 주를 이룬다

  • ex1) 가장 빨리 도착하는 {경로} 의 [소요 시간] 은?
  • ex2) {언제 주식을 사고 팔 때} 가장 [수익] 이 높은가?

DP (Dynamic Programming)

• 최적화 문제를 해결하는 전략 중 하나

• subproblem(s)의 optimal solution(s)을 활용해서, problem의 optimal solution을 찾는 방식

• 겹치는(overlapping) subproblems 은 1번만 계산하고, 그 결과를 저장한 뒤, 재사용한다

DP 의 2가지 접근 방식

[ Top-Down approach ]

• 구조
  • recursive
• subproblem 결과 저장
  • memoization (function call 의 결과를 저장하는 것)
• 언제 선호되는가?
  • subproblems의 일부만 계산해도 최종 optimal solution을 구할 수 있을 때

[ Bottom-Up approach ]

• 구조
  • iterative
• subproblem 결과 저장
  • tabulation (subproblem의 결과부터 테이블에 차근차근 채워넣는 것)
• 언제 선호되는가?
  • 모든 subproblems을 계산해야 최종 optimal solution을 구할 수 있을 때

DP 를 사용한 알고리즘 설계 순서

1. 주어진 문제의 최적해가 구조적으로 어떤 특징을 가지는지 분석한다
2. 재귀적인 형태로 최적해의 value를 정의한다
3. (주로) Bottom-Up 방식으로 최적해의 value를 구한다

(4.) 지금까지 계산된 정보를 바탕으로 최적해를 구한다

• 문제 해결 전략 중 하나

• 어떤 문제를 유사한 형태를 가지는 더 작은 크기의 [서브 문제들]로 나눈 후, 이들을 재귀적으로 같은 방식으로 해결한 뒤, 각 [서브 문제들]을 해결한 결과를 활용하여, [원래 문제]를 해결하는 방식

• 활용 사례: merge(/combine/) sort, quick sort, binary search, etc..

divide and conquer

/divide/ 문제를 작은 크기의 서브 문제들로 나눈다

/conquer/ 서브 문제들을 동일하게 재귀적인 방식으로 해결한다. 만약 더 이상 나눌 수 없다면 직접 해결한다.

/combine/ 서브 문제들의 솔루션을 합쳐서 원래 문제의 솔루션을 만든다.

실행 시간(runnning time): 함수/알고리즘 수행에 필요한 스텝(step) 수

각 라인을 수행하기 위해 필요한 스텝 수는 상수라고 가정하자 N이 작을땐 실행 시간이 의미 없다. N -> ∞ 일 때 실행 시간이 궁금하다.

N -> ∞ 일 때

• N이 커질수록 덜 중요한 것은 제거
• 최고차항만 의미 있다
• 최고차항의 계수는 의미 없다

점근적 분석(Asymptotic analysis) 임의의 함수가 N -> ∞ 일 때 어떤 함수 형태에 근접해지는지 분석

시간 복잡도

• 함수의 실행 시간을 표현하는 것
• 주로 점근적 분석을 통해 실행 시간을 단순하게 표현
• 이때 점근적 표기법으로 표현함

점근적 표기법

Ω (오메가)

하한선(lower bound) 함수 실행 시간은 아무리 빨라도 ~ 이상입니다

O (오)

상한선(upper bound) 함수 실행 시간은 아무리 느려도 ~ 에 비례하는 정도 이하입니다

Θ (세타)

하한선 & 상한선 (tight bound)

실행 시간 case 분류

best(최단) / worst(최장) / average(일반적)

시간 복잡도 시간 비교

O(1) < O(logN) < O(N) < O(N*logN) < O(N²) < O(2^N) < O(N!)

왜 빅오 표기법을 많이 쓸까?

1) 일반적으로 upper bound (최악의 경우)만 알아도 충분하기 때문에 2) 다른 bound를 계산하기 귀찮아서 3) 괜히 tight bound로 말했다가 태클 받기 실어서 4) 주위에서 다들 그렇게 쓰니까 5) 점근적 표기법의 개념을 잘 모르니까 6) 키보드에 Ω 와 Θ 가 없기 때문에

개념

B tree (= BST를 일반화한 tree)

• 자녀 노드의 최대 개수를 늘리기 위해서 부모 노드에 key를 하나 이상 저장한다
• 부모 노드의 key들을 오름차순으로 정렬한다
• 정렬된 순서에 따라 자녀 노드들의 key 값의 범위가 결정된다
  위의 방식을 적용하면 [자녀 노드의 최대 개수]를 입맛에 맞게 결정해서 쓸 수 있다

[자녀 노드의 최대 개수] 는 B tree 를 사용할 때 중요한 파라미터다

M: 각 노드의 최대 자녀 노드 수 M차 B tree: 최대 M개의 자녀 노드를 가지는 B tree

• DB Index 에서 B+Tree를 사용하는 이유

B+Tree, AVL Tree, Red-Black Tree 모두 워스트 케이스에 대한 O(logN)를 보장한다. 같은 시간복잡도를 제공함에도 DB Index에 굳이 B+Tree를 사용하는 이유는 다음과 같다.

DB에서 다루는 데이터는 모두 SSD, HDD 같은 Secondary Storage에 저장된다. (휘발되어서는 안 되는 중요한 데이터이기 때문 + 용량 문제)

Memory 상에 필요한 데이터가 없다면 반드시 Secondary Storage에 접근해서 가져와야 한다. 하지만 Secondary Storage 는 속도가 느린 저장장치이기 때문에 Secondary Storage 에 대한 접근 횟수를 줄이는 것이 성능 향상을 위한 길이다.

BST 기반의 Tree들이 한 노드에 하나의 값만을 갖는 것에 비해 B+Tree는 하나의 노드에 여러 값을 가질 수 있다. 즉, 한 번의 접근으로 더 많은 값들에 대한 조회가 가능하기 때문에 Secondary Storage 접근 횟수를 줄일 수 있다.

또한 데이터 조회 시 Block 단위로 읽어오는 저장장치의 특성 상 연 관된 데이터를 최대한 모아서 저장해놓는 것이 더 효율적이다. B+Tree의 한 노드 안에서는 물리적으로 연속된 공간에 데이터들이 저장되기 때문에 Block 단위의 조회에서 더 많은 유효데이터를 가져올 수 있다.

디스크에서의 데이터 엑세스는 바이트 단위가 아니라 블럭 단위로 수행되기 때문에 랜덤 액세스, 포인터 연산이 굉장히 비싸다.

알고리즘의 시간복잡도는 일반적으로 포인터 연산의 수행속도가 상수시간으로 일정하다는 RAM 환경을 가정하고 이야기하는 것.