테키테크 TEKITECH

[책리뷰] 견고한 데이터 엔지니어링

TEKI — Sun, 27 Aug 2023 23:08:53 +0900

이 책을 보자마자 데이터 엔지니어 필독서로 유명한 「빅데이터를 지탱하는 기술」이라는 책이 떠올랐다. 아직 두 책 모두를 완벽하게 소화하지는 못했지만 그래도 비교해 보니 몇 가지 차이점이 보였다.

1. 「견고한 데이터 엔지니어링」은 「빅데이터를 지탱하는 기술」 보다 더 최신 데이터 엔지니어링에 대한 정보를 담고 있다.
「빅데이터를 지탱하는 기술」의 원서는 2017년에 최초로 발행되었고, 「견고한 데이터 엔지니어링」의 원서는 2022년에 최초로 발행되었다.

2. 「견고한 데이터 엔지니어링」은 「빅데이터를 지탱하는 기술」 보다 두껍다.
「빅데이터를 지탱하는 기술」은 312쪽, 「견고한 데이터 엔지니어링」은 552쪽이다.

3. 「빅데이터를 지탱하는 기술」은 빅데이터를 다루는 특별한 방법에 대한 내용이고, 「견고한 데이터 엔지니어링」은 데이터 엔지니어링 수명 주기에 대한 내용이다.
「빅데이터를 지탱하는 기술」은 기존의 데이터와 구별되는 빅데이터의 특징을 알고, 그것에 맞게 사용할 수 있는 특별한 기술을 설명한다.
반면 「견고한 데이터 엔지니어링」은 데이터의 생성, 저장, 수집, 변환, 서빙 등을 다루는 데이터 엔지니어링 수명 주기를 중점적으로 다룬다.

「빅데이터를 지탱하는 기술」은 얇고, 쉽게 읽히며, 빅데이터의 중요한 컨셉을 이해하기 쉽게 설명해 준다는 점에서 여전히 추천할 만한 책이다. 하지만 앞으로는 실무에서 좀 더 와닿는 내용을 빽빽하게 담고 있는 「견고한 데이터 엔지니어링」을 더 자주, 많이 보게 될 것 같다. 데이터 엔지니어링을 다루는 책은 많지 않다. 그런 중에 이런 보물 같은 책이 나와주어 참 감사하다.

견고한 데이터 엔지니어링 (Fundamentals of Data Engineering) / 한빛미디어

이 책에서는 데이터 엔지니어를 데이터 분석가, 데이터 과학자, MLOps/ML 엔지니어, 그 외 모든 이해관계자를 '지원'하는 역할이라고 정의한다. 실제로 데이터 엔지니어라고 부르는 모든 사람이 똑같은 일을 하고 있지는 않다. 데이터 엔지니어링을 하다 보면 필요에 의해서 이런 일도 하고, 저런 일도 하는 상황이 종종 생기기 때문이다. '지원하는 역할'이라는 의미에서 생각해 보니 오히려 당연한 현상일 수 있겠다고 생각하게 되었다. 앞으로는 좀 더 열린 마음으로 데이터 엔지니어링을 알아가려고 한다.

오라일리 마이크로서비스 아키텍처 구축 전면 개정판

TEKI — Sun, 23 Jul 2023 23:17:53 +0900

서비스를 구축하고 운영하는 실무자라면 대부분 마이크로서비스를 구현하고 운영하는 전반에 대한 여러 가지 고민을 하고 있을 것 같다. 지금 속해있는 팀에서도 니즈를 빠르게 반영해 서비스를 수정하고 확장해 나갈 수 있도록 안정적이고 효율적으로 MSA를 도입하는 일에 관심이 있다.

MSA는 장단점이 명확하다. 즉, MSA의 도입으로 얻을 수 있는 것과 감수해야 할 것이 명확하다는 뜻이다. 마틴 파울러가 "마이크로서비스의 특징을 이해하고 특정한 상황에 적용하는 것이 현명하다"라고 언급[1][2]하기도 했고, 실제로 MSA의 실패 사례도 적지 않은 만큼 이러한 내용을 충분히 이해할 필요가 있는데, 이 책의 저자가 중립적인 입장에서 필요한 내용을 설명해 주고 있어 MSA의 도입을 고민하는 과정에서 도움을 얻을 수 있었다.

이 책은 총 3부에 걸쳐 MSA 구축과 의사결정에 필요한 거의 모든 것에 관해 설명한다. 1부에서는 마이크로서비스의 핵심 아이디어를 설명하고, 2부에서는 개념에서 구현 상세로 넘어가 마이크로서비스를 활용하는 데 도움이 되는 기법과 기술을 살펴본다. 마지막으로 3부에서는 1부, 2부에서 배운 내용을 토대로 사람과 조직의 입장에서 기술을 구현해 내는 과정을 설명한다. 많은 내용이 담겨있어서 앞으로 MSA와 함께하는 시간 동안 두고두고 들여다보며 공부해야 할 책인 것 같다.

마이크로서비스 아키텍처 구축 / 샘 뉴먼 지음 / 한빛미디어 출판

오라일리 개발자를 위한 머신러닝&딥러닝 / 한빛미디어

TEKI — Sun, 23 Apr 2023 08:59:37 +0900

"여러분은 그림 속 의류 아이템을 종류별로 알아볼 수 있습니다. 어떤 것이 셔츠, 코트, 드레스인지 구별할 수 있습니다. 하지만 옷을 한 번도 본 적 없는 사람에게 이를 어떻게 설명할 수 있을까요? 신발은 어떻게 설명할까요? 그림에는 종류가 다른 신발 두 개가 있는데 어떻게 설명해야 할까요? 이는 1장에서 이야기한 규칙 기반 프로그래밍이 실패하는 또 다른 영역입니다. 이따금 규칙으로 무언가를 설명하기가 불가능한 경우가 있습니다.

컴퓨터 비전도 예외가 아닙니다. 하지만 여러분이 이런 아이템을 인식하는 방법을 생각해보죠. 여러 가지 샘플을 보고 사용 방법을 경험하고, 이를 기반으로 사물을 구별합니다. 그렇다면 컴퓨터로 이 과정을 똑같이 해낼 수 있을까요? 네, 할 수 있습니다. (...중략...)

의류 아이템에는 다양한 셔츠, 바지, 드레스, 여러 가지 종류의 신발이 있습니다. 그림에 나타나 있듯이 흑백 이미지이므로 각 사진은 0과 255 사이의 픽셀 값으로 구성됩니다. 덕분에 데이터셋을 쉽게 다룰 수 있습니다."

- ≪개발자를 위한 머신러닝&딥러닝》 중에서

개발자를 위한 머신러닝&딥러닝 / 로런스 오로니 지음 / 한빛미디어

책에서는 컴퓨터 비전에 대해 이처럼 직관적으로 이해하기 쉽게 소개한다. 뉴런부터 Hidden Layer(은닉 층)과 Output Layer(출력 층), Overfitting(과대적합), Hyperparameter Tuning(하이퍼파라미터 튜닝) 등 머신러닝에 필요한 개념과 학습(신경망 훈련)하는 방법까지 알려주면서 어려운 이론적인 내용보다는 바로 이해하고 활용할 수 있도록 파이썬 코드와 함께 설명해준다.

파트 1에서는 컴퓨터 비전 외에도 자연어 처리, 텍스트 생성, 시계열데이터 처리 그리고 CNN과 LSTM, RNN, DNN 등 모델 구축에 대해 다룬다. 그리고 파트 2에서는 텐서플로를 이용해 모델을 사용하는 방법을 상세하게 알려준다. DeepLearning.AI와 코세라에서 텐서플로 교육 과정을 진행했었던 저자 로런스 모로니의 텐서플로우 강의인만큼 알차다. 네이티브 모바일이나 임베디드 시스템에서 실행되는 텐서플로 라이트와 웹에서 사용할 수 있는 TensorFlow.js를 알려주기도 한다.

특히 텐서플로 서빙과 모델 구축과 배포, 데이터 관리를 위한 ETL 프로세스, 텐서플로로 웹/앱 만들기 등 실제 개발 시 필요한 내용을 많이 다루고 있다는 점에서 개발자에게 아주 유용하다.

무엇보다도 수식과 이론을 늘어놓기보다는 코드와 실제 실행 결과를 기반으로 설명해주는 점이 개발자입장에서 읽기가 훨씬 수월하다. 그래서 이 책은 처음부터 끝까지 코드를 베이스로 하는 만큼 모델을 빠르게 구축하여 학습과 추론을 하고 싶은 사람에게 주저 없이 추천하고 싶다. 책의 내용을 하나씩 따라가다 보면 금방 머신러닝을 사용할 수 있을 것이다.

우분투에 docker와 docker-compose 설치하기 (Ubuntu 20.04 ver.)

TEKI — Tue, 4 Apr 2023 18:43:24 +0900

stable 버전 설치. 아래 명령어들을 순서대로 입력.

$ sudo apt update

$ sudo apt-get install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common

$ curl -fsSL  https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

$ sudo add-apt-repository "deb [arch=amd64]  https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

$ sudo apt update

$ sudo apt-get install -y docker.io

$ sudo systemctl enable docker

$ sudo service docker start

$ sudo apt install -y jq

$ VERSION=$(curl --silent https://api.github.com/repos/docker/compose/releases/latest | jq .name -r)

$ DESTINATION=/usr/bin/docker-compose

$ sudo curl -L https://github.com/docker/compose/releases/download/${VERSION}/docker-compose-$(uname -s)-$(uname -m) -o $DESTINATION

$ sudo chmod 755 $DESTINATION

설치 완료. 아래 명령어로 도커 컴포즈가 설치 되었는지 (안되었다면 오류 발생), 어떤 버전을 설치했는지 확인.

$ docker-compose -v
Docker Compose version v2.16.0

이것이 리눅스다 3판 / 우재남 지음 / 한빛미디어

TEKI — Sun, 26 Mar 2023 21:24:15 +0900

<이것이> 시리즈에서 네 번째로 출간되었던 『이것이 리눅스다』의 세 번째 개정판이 출간되었다.

이것이 리눅스다 3판 / 우재남 지음 / 한빛미디어 · 2023년 2월 24일 출판

책에서는 실무와 동일한 환경에서 학습할 수 있도록 노력했는데, VMware 가상머신으로 1대의 컴퓨터에 4대의 서버(Linux 3대, Windows 1대)를 설치하고, 그 환경에서 리눅스 서버 운영의 기본부터 메일 서버, 데이터베이스 서버, 웹 서버, FTP 서버 구축까지 학습할 수 있도록 구성되어 있다.

첫 번째와 두 번째 판에서는 CentOS를 사용해 리눅스 환경을 구축했으나 이제는 CentOS 8부터 Stream 버전만 지원하게 되면서 사실상 RHEL(RedHat Enterprise Linux)를 무료로 사용하지 못하게 되었다. 이러한 상황을 반영한 것인지 이번 3판에서는 Rocky Linux라고 하는 RHEL을 기반으로 한 무료 리눅스 배포판을 사용한다.

학습 로드맵

이전 판과의 또 다른 차이점은 리눅스 가상화 기술에 대한 내용으로, VirtualBox와 도커를 사용한 가상화 기술에 대해 학습한다. 리눅스를 사용하면서 도커를 사용하지 않는 곳이 거의 없는 만큼 도커는 필수적인 기술이기 때문에 리눅스를 학습하면서 도커까지 한 번에 학습할 수 있다는 건 큰 장점이다.

이 책에서는 이런 것들을 배울 수 있습니다.

✔️ 리눅스의 기본 개념과 Rocky Linux

리눅스의 역사와 개념, 그리고 Rocky Linux의 의미를 알려주고, Rocky Linux를 실제로 설치하여 서버를 구축하고, 이를 기반으로 리눅스의 개념을 이해해 본다.

✔️ 리눅스 서버 구축 방법과 필수 개념 및 명령어

네임 버서, 메일 서버, 데이터베이스 서버, 웹 서버, FTP 서버, NFS 서버, Samba 서버, DHCP 서버, 프록시 서버, PXE 서버 등 10가지 서버 구축 방법과 리눅스를 사용하기 위해 알아야 하는 개념과 명령어를 알려준다.

✔️ 리눅스 서버의 보안 (방화벽)

외부의 접근을 선별적으로 차단하여 보안을 유지하는 방화벽에 대해 학습한다. 책에서는 방화벽을 이루는 일반적인 네트워크 구성부터 가상환경에서의 방화벽 구현 방식 등 실무에서 활용 가능한 방화벽 기술에 대해 설명하고 있다.

✔️ VirtualBox와 도커를 사용한 가상화 기술

VirtualBox, 도커 등 리눅스에서 지원하는 가상화 기술의 종류에 대해 알아보고, 실제로 가상 환경을 구축해보는 실습을 통해 리눅스 가상화 기술에 대해 공부한다.

책 들여다보기

이 책은 800페이지가 넘는 아주 두꺼운 책이지만 공부하는데 부담을 덜 수 있도록 로드맵을 꼼꼼하게 제공해주고 있다. 첫째는 앞서 첨부했던 전체 학습 로드맵으로 수많은 분량이지만 어떤 부분을 어디까지 공부해야 할지 알면서 공부할 수 있도록 돕는다.

둘째는 파트 별 가이드이다.

가상머신 생성 및 Rocky Linux 설치
Rocky Linux 기본 개념 및 리눅스 관리자의 기본 역할
네트워크 서버 구축 실무 1
네트워크 서버 구축 실무 2

위와 같이 전체 챕터를 총 4개 파트로 나누고, 파트별 내용을 간략하게 소개해주어 무엇을 공부하는지 확인하면서 학습할 수 있도록 도와준다.

마지막은 챕터별 학습 방향 가이드이다. 각 챕터마다 핵심 개념과 학습 흐름을 보여주어 어떤 내용을 어떤 순서대로 학습할 것인지 먼저 알려주기 때문에 수많은 사진 자료와 실습 내용 사이에서 길을 잃지 않을 수 있다.

이 책은 이런 분들께 더 추천드립니다.

✔️ 리눅스를 사용하고 싶은 초보 리눅스 사용자
✔️ 리눅스를 더 잘 사용하고 싶은 리눅스 실무자
✔️ 실무 환경에서와 같이 리눅스를 사용해보고 싶은 사람 누구나

혼공학습단 9기를 마치며

TEKI — Wed, 22 Feb 2023 19:48:04 +0900

≫ '혼자 공부하는 컴퓨터구조+운영체제' 챕터별 공부한 내용 ≪

새해를 시작하면서 공부하는 습관을 들이고자 혼공학습단 9기에 도전했었다. 일을 하면서 6주 만에 책 한 권을 공부하는 건 쉬운 일은 아니지만 새해 버프를 받았는지 무조건 완주할 거라는 자신감이 있었던 것 같다.

[혼공학습단 9기] 2023년 시작하기

혼공학습단 9기에서는 11개 도서 중 하나를 선택해서 공부할 수 있다. 대상 도서는 한빛미디어의 시리즈로 프로그래밍 언어를 공부하는 도서 5권과 데이터 분석 및 머신러닝 관련 도서 3권, 그리

teki.tistory.com

스터디 교재는 「혼자 공부하는 컴퓨터구조+운영체제」로 선택했고, 1월 2일부터 2월 19일까지 7주간의 여정이었다(쉬는 주 한 주 포함). 스터디 완주 조건은 매주 공부한 내용과 혼공족장님이 내주시는 문제 풀이를 정리해서 블로그에 올린 다음, 혼공족 페이스북에 공유하는 것까지다.
새해 버프를 받았을 땐 완주가 쉬워 보였는데, 막상 공부를 시작해 보니 생각보다 시간이 오래 걸렸다. 그래서 처음에는 선 인증 후 공부를 하는 주간이 반복됐었다.

그래도 매일매일 꾸준히 공부하다 보니 점점 공부 진도가 인증 진도를 따라잡았고, 마지막 주차엔 선 공부 후 인증을 할 수 있었다. 열심히 공부했던 걸 혼공족장님도 알아주셔서 5주 차에는 우수혼공족에 선정해주셨다. 정말 뿌듯했다 :)

+ 6주 차에도 우수혼공족에 선정해주셨다!

한 명 한 명 다 확인하고 멘트를 적어주시는 스윗한 혼공족장님이시다

사실 포기하지 않고 끝까지 공부할 수 있었던 데에는 혼공족장님의 따뜻한 응원이 있었다. (혼공족장님 감사해요♥)

이렇게 마음이 따뜻해지는 댓글들은 아묻따 박제!

이번 혼공학습단을 하면서 매일매일 꾸준히 공부하는 습관이 다시 잡혔다. 그리고 혼공학습단이 끝나고도 꾸준히 공부할 수 있겠다는 자신감도 다시 충전했다. 이 정도면 2023년을 잘 시작한 것 아닐까?

[운영체제] Ch15. 파일 시스템

TEKI — Mon, 20 Feb 2023 22:07:14 +0900

파일 시스템에 대하여

파일과 디렉터리
FAT 파일 시스템과 유닉스 파일 시스템

1. 파일과 디렉터리

파일은 하드 디스크나 SSD와 같은 보조기억장치에 저장된 관련 정보의 집합 즉, 의미 있고 관련 있는 정보를 모은 논리적 단위를 의미한다. 파일을 이루는 정보에는 파일의 이름과 파일을 실행하기 위한 정보, 그리고 속성(attribute) 또는 메타데이터(metadata)라고 부르는 파일 관련 부가 정보도 있다. 속성에는 아래와 같은 것들이 있다.

유형 : 운영체제가 인지하는 파일의 종류(.exe, .com, .bin, .zip, ...)
크기 : 파일의 현재 크기와 허용 가능한 최대 크기
보호 : 파일을 읽고, 쓰고, 실행할 수 있는지에 대한 사용자 권한 정보
날짜 : 생성 날짜, 마지막 접근 날짜, 마지막 수정 날짜 등 시간 정보
생성자 : 파일을 생성한 사용자 정보
소유자 : 파일을 소유한 사용자 정보
위치 : 파일의 보조기억장치상의 현재 위치 정보

이 중에서도 파일의 유형은 확장자라는 것을 통해 파일 이름에서 파일의 정보를 드러낸다.

실행 파일 : (확장자가 없는 경우), .exe, .com, .bin
목적 파일 : .obj, .o
소스 코드 파일 : .c, .cpp, .cc, .java, .asm, .py
워드 프로세서 파일 : .xml, .rtf, .doc, .docx
라이브러리 파일 : .lib, .a, .so, .dll
멀티미디어 파일 : .mpeg, .mov, .mp3, .mp4, .avi
백업/보관 파일 : .rar, .zip, .tar

디렉터리는 파일들을 일목요연하게 관리하기 위해 이용하는 체계로, 윈도우 운영체제에서는 폴더라고도 부른다.

◈ 1단계 디렉터리 (single-level directory)
→ 옛날 운영체제의 형태로, 모든 파일이 하나의 디렉터리 아래에 있는 형태.

◈ 트리 구조 디렉터리 (tree-structured directory)
→ 최근 사용하는 거의 모든 운영체제의 형태로, 디렉터리 안에 또 다른 디렉터리가 존재할 수 있어 트리 구조를 이루는 형태. 이때 최상위 디렉터리는 루트 디렉터리, 하위 디렉터리는 서브 디렉터리 또는 자식 디렉터리라고 부른다.

트리 구조 디렉터리에서 파일의 위치를 특정하기 위해 경로를 사용한다. 이때 두 가지 표현 방법이 있다.

① 절대 경로
: 루트 디렉터리에서 자기 자신까지 이르는 고유한 경로로, 모든 파일이 각자 고유한 절대 경로를 가지고 있다.

② 상대 경로
: '현재' 디렉터리를 기준으로 상대적인 위치를 나타내는 경로이다.

2. FAT 파일 시스템과 유닉스 파일 시스템

공장에서 나온 후 처음 사용하는 새 하드 디스크나 SSD를 사용하려면 파티셔닝(파티션을 나누는 작업)과 포매팅(포맷 작업)을 먼저 해주어야 한다. 파티셔닝이란 하나의 보조 기억 장치에 논리적인 구역을 나누는 것을 의미하고, 포맷팅이란 파일 시스템을 설정하여 어떤 방식으로 파일을 저장하고 관리할 것인지를 결정하고, 새로운 데이터를 쓸 준비를 하는 작업을 의미한다.

파티셔닝과 포맷팅이 끝나면 저장 장치에 파일을 저장할 수 있다. 이때 파일 할당 방법에는 연속 할당과 불연속 할당 방법이 있고, 불연속 할당에는 연결 할당과 색인 할당이 있다.

연속 할당은 가장 단순한 방식으로, 보조기억장치 내 연속적인 블록에 파일을 할당하는 방식이다. 이는 구현은 단순하지만 외부 단편화를 야기한다는 문제가 있다.

연결 할당은 이 문제를 해결할 수 있다. 각 블록 일부에 다음 블록의 주소를 저장하여 각 블록이 다음 블록을 가리키는 '연결 리스트' 형태로 파일을 할당하는 방식이다. 하지만 연결 할당은 반드시 첫 번째 블록부터 하나씩 차례대로 읽어야 한다는 점 때문에 임의 접근(random access) 속도가 매우 느리다는 단점과 하드웨어 고장이나 오류 발생 시 해당 블록 이후 블록은 접근할 수 없다는 단점이 있다.

◈ FAT 파일 시스템

연결 할당 방식을 조금 보완하여 구현한 파일 시스템으로 FAT 파일 시스템이 있다. 이 파일 시스템은 연결 할당 방식의 단점의 근본적인 원인을 블록 안에 다음 블록의 주소를 저장한 점이라고 보고 블록의 주소들을 한데 모아 테이블 형태로 따로 관리한다. 이 테이블을 파일 할당 테이블(FAT: File Allocation Table)이라고 한다.

색인 할당은 파일의 모든 블록 주소를 색인 블록이라는 하나의 블록에 모아 관리하는 방식으로, 연결 할당의 단점을 보완한다. 색인 할당은 색인 블록 안에 파일을 구성하는 데이터 블록 주소가 있기 때문에 색인 블록만 알면 해당 파일 데이터에 접근할 수 있다. 그렇기에 색인 할당을 사용하는 파일 시스템에서는 색인 할당 주소를 디렉터리 엔트리에 파일 이름과 같이 저장하여 사용한다.

◈ 유닉스 파일 시스템

색인 할당을 사용하는 파일 시스템에는 유닉스 파일 시스템이 있다. 유닉스 파일 시스템에서 색인 블록을 i-node(index-node)라고 부른다. i-node는 크기가 유한하기 때문에 몇 가지 규칙을 따른다.(1) 블록 주소 중 열두 개에는 '직접 블록(direct block)' 주소를 저장한다. (2) (1)의 내용으로 충분하지 않은 경우엔 열세 번째 주소에 단일 '간접 블록(single indirect block)' 주소를 저장한다. (3) (2)의 내용으로 충분하지 않은 경우엔 열네 번째 주소에 '이중 간접 블록(double indirect block)' 주소를 저장한다. (4) (3)의 내용으로 충분하지 않은 경우엔 열다섯 번째 주소에 '삼중 간접 블록(triple indirect block)' 주소를 저장한다.

[혼공학습단 9기] 혼공컴운 6주차 미션

TEKI — Sat, 18 Feb 2023 19:06:11 +0900

6주 차 미션!

[미션 1] p. 400의 확인 문제 1번 풀고 인증하기

· ( 최초 적합 ) : 최초로 발견한 적재 가능한 빈 공간에 프로세스를 배치하는 방식
· ( 최악 적합 ) : 프로세스가 적재될 수 있는 가장 큰 공간에 프로세스를 배치하는 방식
· ( 최적 적합 ) : 프로세스가 적재될 수 있는 가장 작은 공간에 프로세스를 배치하는 방식

[미션 2] Ch. 14(14-3) 프로세스가 사용할 수 있는 프레임이 3개 있고, 페이지 참조열이 '2414523423'일 때 FIFO, 최적 페이지, LRU 페이지 교체 알고리즘으로 이 페이지를 참조한다면 몇 번의 페이지 폴트가 발생하는지 풀어보기

FIFO 페이지 교체 알고리즘 - 4번

최적 페이지 교체 알고리즘 - 2번

LRU 페이지 교체 알고리즘 - 4번

공부한 내용

Chapter 14 가상 메모리
→ [운영체제] Ch14. 가상 메모리 할당 방식
Chapter 13 교착 상태
→ [운영체제] Ch15. 파일 시스템

[운영체제] Ch14. 가상 메모리 할당 방식

TEKI — Sat, 18 Feb 2023 16:13:31 +0900

운영체제의 가장 핵심적인 역할 두 가지 중 하나인 메모리 관리에 대하여

스와핑
메모리 할당 방식 3가지: 최초 적합, 최적 적합, 최악 적합
연속 메모리 할당과 외부 단편화 문제
외부 단편화 해결 방안: 압축과 페이징
페이지 교체 알고리즘
스래싱과 프레임 할당

1. 스와핑

입출력장치의 요구로 대기 상태가 된 프로세스, 오랫동안 사용되지 않은 프로세스 등이 메모리 공간을 차지하고 있는 경우가 있다. 이렇게 메모리에 적재된 프로세스 중 현재 실행되지 않는 프로세스를 임시로 보조기억장치 일부 영역으로 쫓아내고, 그 공간에 다른 프로세스를 적재하여 실행하는 방식을 스와핑이라고 한다. 스와핑을 하면 동시에 실행하려는 프로세스들이 필요로 하는 메모리 공간의 총량보다 사용가능한 메모리 용량이 적어도 프로세스들을 동시에 실행할 수 있다.

스와핑하여 확보한 메모리 공간을 스왑 영역이라고 하는데, 유닉스와 리눅스, MacOS에서 'free'나 'top' 명령어를 통해 스왑 영역 정보를 확인할 수 있다.

맥북(M1칩)에서 top 명령어를 실행한 결과

2. 메모리 할당 방식 3가지: 최초 적합, 최적 적합, 최악 적합

메모리 내에 빈 공간이 있다면 프로세스를 할당해주어야 한다. 만약 메모리 안에 빈 공간이 여러 개 있다면 어떻게 할당해주어야 할까? 이때 3가지 방법이 있다.

[1] 최초 적합

운영체제가 메모리 내의 빈 공간을 순서대로 검색하다가 적재할 수 있는 빈 공간을 발견했을 때, 그 공간에 프로세스를 배치하는 방식
검색 리소스를 최소화하고, 결과적으로 빠른 할당이 가능함

[2] 최적 적합

운영체제가 메모리 내의 빈 공간을 전부 검색한 후, 프로세스가 적재될 수 있는 공간 중 가장 작은 공간에 프로세스를 배치하는 방식

[3] 최악 적합

운영체제가 메모리 내의 빈 공간을 전부 검색한 후, 프로세스가 적재될 수 있는 공간 중 가장 큰 공간에 프로세스를 배치하는 방식

3. 연속 메모리 할당과 외부 단편화 문제

앞에서 다루었던 것과 같이 여러 프로세스를 메모리에 연속적으로 배치하는 것을 연속 메모리 할당이라고 한다. 하지만 이는 외부 단편화 문제를 내포하고 있기 때문에 메모리를 효율적으로 사용하지 못하는 방법이다.

외부 단편화 문제란 여러 프로세스를 할당할 충분한 공간이 메모리 안에 남아있음에도 공간이 단편화되어 흩어져있어서 프로세스를 할당하지 못하는 문제를 말한다.

4. 외부 단편화 해결 방안: 압축과 페이징

외부 단편화 문제를 해결하기 위한 방법에는 메모리를 압축하는 방법과 페이징 기법을 사용하는 방법이 있다.

[1] 메모리 압축

압축은 여기저기 흩어져 있는 빈 공간들을 하나로 모으는 방식으로, 메모리 내에 저장된 프로세스를 적당히 재배치하여 빈 공간들을 하나의 큰 공간으로 모으는 것을 메모리 압축이라고 한다.

하지만 압축을 진행하는 동안 시스템이 하던 일을 중단해야 하고, 메모리의 내용을 옮기면서 많은 오버헤드를 야기하며, 효율적인 압축 방식을 결정하기가 어렵다는 단점이 있다.

[2] 페이징

메모리 압축 대신 나온 페이징 기법은 오늘날까지도 사용되는 가상 메모리 기법이다. 페이징은 프로세스의 논리 주소 공간을 페이지라는 일정한 단위로 나누고, 메모리의 물리 주소 공간을 프레임이라는 일정한 단위(페이지와 동일)로 나눈 뒤 페이지를 프레임에 할당하는 가상 메모리 관리 기법이다. 이때 프로세스의 페이지 중 필요한 페이지만 메모리에 적재(프레임에 할당)하면 되기 때문에 보다 효율적이다.

그런데 이렇게 하면 프로세스가 다음에 실행할 명령어 위치(다음 페이지 위치)를 알기 어려워진다. 그러므로 메모리 안에서 물리적 위치는 순서대로가 아니더라도 논리적 주소는 순서대로 배치될 수 있도록 페이지 테이블을 사용한다. 페이지 테이블은 페이지 번호와 프레임 번호를 짝지어주는 일종의 이정표로, CPU가 페이지 번호만 보고 해당 페이지가 적재된 프레임을 찾을 수 있게 되어있다.

한빛미디어-「혼자 공부하는 컴퓨터 구조+운영체제」 p.406

페이징은 외부 단편화 문제는 해결했지만 내부 단편화 문제가 생긴다. 내부 단편화 문제는 페이지 크기로 프로세스를 나눌 때, 페이지 크기보다 작은 크기로 메모리가 단편화되어 남는 현상을 말한다. 유닉스 기반의 OS에서는 아래와 같이 getconf 명령어로 페이지 크기를 확인할 수 있다.

◈ PTBR (Page Table Base Register)
→ 프로세스마다 각자의 프로세스 테이블을 가지고 있고, 각 프로세스의 페이지 테이블은 메모리에 적재되어 있다. PTBR(페이지 테이블 베이스 레지스터)는 각 프로세스의 페이지 테이블이 적재된 주소를 가리키고 있다. 그러나 이렇게 페이지 테이블을 메모리에 두면 메모리 접근 시간이 두 배로 늘어난다는 단점이 있다.

◈ TLB (Translation Lookaside Buffer)
→ CPU 곁에(일반적으로 MMU 내에) TLB라는 페이지 테이블의 캐시 메모리를 두어 페이지 테이블의 일부 내용을 저장한다. (참조 지역성에 근거해 주로 최근에 사용된 페이지 위주로 저장). 논리 주소에 대한 페이지 번호가 TLB에 있으면(TLB 히트) 메모리 접근을 한 번만, 없으면(TLB 미스) PTBR과 같이 메모리 내의 페이지 테이블까지 더해서 메모리 접근을 두 번 하게 된다. 결과적으로 PTBR보다 메모리 접근 시간이 줄어든다는 장점이 있다.

5. 페이지 교체 알고리즘

◈ 요구 페이징
→ 프로세스를 메모리에 적재할 때 처음부터 모든 페이지를 적재하지 않고, 필요한 페이지만 메모리에 적재하는 기법. 아무런 페이지도 메모리에 적재하지 않고 실행부터 할 수도 있는데, 이를 순수 요구 페이징이라고 한다.

◈ 페이지 교체 알고리즘
→ 요구 페이징 기법으로 페이지를 적재하다 보면 언젠가 메모리가 가득 찬다. 그러므로 적재된 페이지를 보조기억장치로 내보내야 하는데, 이를 결정하는 방법이 페이지 교체 알고리즘이다.

① FIFO 페이지 교체 알고리즘

메모리에 가장 먼저 올라온 페이지부터 내쫓는 방식(First In First Out). 구현은 간단하지만, 프로그램 내내 사용될 내용이 가장 먼저 들어왔다고 쫓아내면 안 되는 것처럼 단점이 있다.

② 최적 페이지 교체 알고리즘

CPU에 의해 참조되는 횟수를 고려하여 자주 사용될 페이지를 남기고, 사용 빈도가 낮은 페이지를 내쫒는 방식. 하지만 현실적으로 '앞으로 오랫동안 사용되지 않을 페이지'를 예측하는 것이 어려워 실제로 구현하지는 못하고 대신 다른 페이지 교체 알고리즘의 이론상 성능을 평가하기 위한 용도로 사용된다. (최적 페이지 교체 알고리즘의 페이지 폴트 횟수를 하한선으로 두고, 이와 비교하여 평가)

③ LRU 페이지 교체 알고리즘

최근에 사용되지 않은 페이지는 앞으로도 사용되지 않을 것이라고 가정하여 가장 오랫동안 사용되지 않은 페이지를 내쫓는 방식.

6. 스래싱과 프레임 할당

프로세스가 지나치게 빈번한 페이지 교체로 실제 실행되는 시간보다 페이징에 더 많은 시간을 소요하여 성능이 저해되는 문제를 스래싱(Thrashing)이라고 한다. 스래싱이 발생하는 근본적인 원인은 각 프로세스가 필요로 하는 최소한의 프레임 수가 보장되지 않았기 때문이다. 스래싱 발생 위험을 낮추려면 운영체제는 각 프로세스들이 무리 없이 실행하기 위한 최소한의 프레임 수를 파악하고 프로세스들에 적절한 수만큼 프레임을 할당해 줄 수 있어야 한다.

[1] 프레임 할당 방식 1. 균등 할당
→ 모든 프로세스에 균등하게 프레임을 제공하는 방식. (정적 할당 방식)

[2] 프레임 할당 방식 2. 비례 할당
→ 프로세스 크기에 비례하여 프레임을 제공하는 방식. (정적 할당 방식)

[3] 프레임 할당 방식 3. 작업 집합 모델(Working Set Model)을 사용하는 방식
→ 프로세스를 실행하는 과정에서 프로세스가 일정 기간 동안 참조한 페이지 집합(작업 집합)을 기억하여 그 크기만큼 프레임을 제공하는 방식 (동적 할당 방식)

[4] 프레임 할당 방식 4. 페이지 폴트 빈도(PFF: Page-Fault Frequency)를 사용하는 방식
→ 프로세스를 실행하는 과정에서 페이지 폴트 빈도에 따라 프레임을 제공하는 방식. 페이지 폴트가 너무 높으면 프로세스에 프레임이 너무 적고, 페이지 폴트가 너무 낮으면 프로세스에 프레임이 너무 많다는 가정을 따른다. (동적 할당 방식)

[운영체제] Ch13. 교착 상태(데드락)에 대응하는 방법

TEKI — Thu, 16 Feb 2023 21:04:14 +0900

교착 상태에 대하여

교착 상태(데드락)란? ft.식사하는 철학자 문제
교착 상태 발생 조건 4가지
교착 상태 해결 방법 - 예방, 회피, 회복

1. 교착 상태(데드락)란? ft. 식사하는 철학자 문제

프로세스 실행 과정에서 발생하는 문제 중 교착 상태 또는 데드락(Dead Lock)이라고 불리는 문제가 있다.

◈ 식사하는 철학자 문제

식사하는 철학자 문제는 교착 상태를 설명하기 위한 고전적인 문제이다. 동그란 원탁에는 다섯 명의 철학자가 앉아있고, 모든 철학자의 앞에는 각각 음식 접시가 놓여있다. 그리고 식사를 하기 위한 포크는 철학자 사이에 하나씩 총 5개의 포크가 놓여있다.

https://velog.io/@oeckikek/Deadlock

만약 포크 두 개가 있어야 먹을 수 있는 식사이고, 철학자들은 아래와 같이 식사를 한다고 하자.

① 철학자들은 계속 생각을 하다가 왼쪽 포크가 사용 가능하면 집어든다.
② 철학자들은 계속 생각을 하다가 오른쪽 포크가 사용 가능하면 집어든다.
③ 양쪽 포크를 모두 집어 들면 정해진 시간 동안 식사를 한다.
④ 식사 시간이 끝나면 오른쪽 포크를 내려놓는다.
⑤ 오른쪽 포크를 내려놓았다면 왼쪽 포크도 내려놓는다.
⑥ 다시 ①로 돌아간다.

①번을 모든 철학자가 동시에 실행하여 각자 자신의 왼쪽에 있는 포크를 집어 들었다면, 오른쪽에 포크가 남아있는 철학자는 아무도 남지 않는다. 그러면 모든 철학자는 자신의 오른쪽 철학자가 포크를 내려놓을 때까지 집어든 왼쪽 포크를 내려놓지 않을 것이고, 그렇게 일어나지 않을 사건을 기다리면서 진행이 멈춘 현상을 교착 상태라고 한다.

◈ 교착 상태를 표현하는 자원 할당 그래프

교착 상태는 자원 할당 그래프(resource-allocation graph)를 통해 단순하게 표현할 수 있다.

① 프로세스는 원으로, 자원의 종류는 사각형으로 표현한다.

② 사용할 수 있는 자원의 개수는 사각형 안에 점의 개수로 표현한다.

③ 프로세스가 어떤 자원을 할당받아 사용 중이라면, 자원에서 프로세스를 향해 화살표로 표시한다.

④ 프로세스가 어떤 자원을 기다리고 있다면 프로세스에서 자원으로 화살표로 표시한다.

이 방법으로 '식사하는 철학자 문제'를 표현하면 아래와 같다.

2. 교착 상태 발생 조건 4가지

상호 배제, 점유와 대기, 비선점 및 원형 대기의 4가지 조건이 모두 만족되면 교착 상태가 발생할 가능성이 생긴다.

[1] 상호 배제

공유하는 한 자원을 한 번에 하나의 프로세스만 사용할 수 있었기 때문에 교착 상태가 발생했다고 할 수 있다. 즉, 상호 배제 상황에서 교착 상태가 발생할 수 있다.

[2] 점유와 대기

포크라는 자원을 들고 내려놓지 않은(점유) 상태에서 무작정 기다렸기 때문에 누구도 식사를 이어나갈 수 없었다. 다시 말해 자원을 할당받은 상태에서 다른 자원을 할당받기 기다리는 상태가 교착 상태의 원인이라고 볼 수 있다.

[3] 비선점

만약 철학자 중 누군가가 다른 철학자의 포크를 강제로 빼앗았다면 교착 상태가 발생하지 않을 수 있었을 것이다. 이렇게 자원을 비선점(nonpreemptive)하고 누구도 빼앗지 않았기 때문에 교착 상태가 발생한 것이라고 볼 수 있다.

[4] 원형 대기

프로세스와 프로세스가 요청하거나 할당받은 자원이 원의 형태를 이루었기 때문에 교착 상태가 발생했다고 볼 수 있다. 이렇게 원의 형태로 자원을 대기하는 것을 원형 대기라고 한다.

3. 교착 상태 해결 방법 - 예방, 회피, 회복

[1] 교착 상태 예방

상호 배제, 점유와 대기, 비선점, 원형 대기 중 하나라도 없애서 교착 상태를 예방하는 방법을 생각해 볼 수 있다.

① 우선 상호 배제는 현실적으로 없애기 어렵다.

② 점유와 대기를 없애면 특정 프로세스에 자원을 모두 할당하거나 아예 할당하지 않는 식으로 배분할 수 있는데, 이때 자원 활용률이 낮아질 수 있고, 기아 현상이 발생할 우려가 있다.

③ 만약 비선점 조건을 없애면 이용 중인 프로세스로부터 자원을 빼앗아 교착 상태로부터 벗어날 수 있지만, 자원을 선점한 프로세스가 끝날 때까지 다른 프로세스가 기다려줘야 하는 경우가 있기 때문에 범용성이 떨어진다.

④ 마지막으로 원형 대기 조건을 없애는 방법은 모든 자원에 번호를 붙이고, 오름차순으로 자원을 할당하는 방식처럼 간단하다. 하지만 수많은 자원을 모두 이러한 방식으로 관리하는 것은 간단하지 않고, 자원에 번호를 붙이는 방식에 따라 자원 활용률이 떨어질 수 있다.

결론적으로 교착 상태를 예방하는 간단하고 문제가 없는 좋은 방법은 없다.

[2] 교착 상태 회피

두 번째 방법은 교착 상태를 회피하는 것으로, 무분별한 자원 할당이 문제의 원인으로 보고 자원을 조금씩만 할당하는 방법이다. 교착 상태가 발생하지 않는 수준의 상태를 안전 상태(safe state)라고 하고, 교착 상태가 발생할 수도 있는 상황을 불안전 상태(unsafe state)라고 한다. 이 기준은 안전 순서열(safe sequence)라고 부르는 교착 상태 없이 안전하게 프로세스들에 자원을 할당할 수 있는 순서가 있는지에 따라 판단한다.

[3] 교착 상태 검출 후 회복

만약 이미 교착 상태가 벌어졌다면, 이를 해결하는 방법이 있다.

① 선점을 통한 회복

교착 상태가 해결될 때까지 다른 프로세스로부터 자원을 강제로 빼앗아 한 프로세스씩 자원을 몰아주어(선점) 해결하는 방법이 있다.

② 프로세스 강제 종료를 통한 회복

가장 단순하면서 확실한 방법으로는 교착 상태가 없어질 때까지 교착 상태에 놓인 모든 프로세스 전체 또는 하나씩 강제로 종료하는 방법이다. 단, 전체를 종료할 경우엔 많은 작업 내역을 잃는다는 단점이, 하나씩 종료할 경우엔 교착 상태가 없어졌는지 확인하는 과정에서 오버헤드를 야기한다는 단점이 있다.

③ 타조 알고리즘

교착 상태를 완전히 무시하는 방법으로 타조 알고리즘(orstrich algorithm)이 있다. 문제의 발생 빈도나 심각성에 따라 최대 효율을 추구하는 엔지니어 입장에서는 이 방법이 적합할 때도 많다.

[운영체제] Ch12. 동기화 문제(생산자와 소비자 문제, 임계 구역 문제)과 동기화 도구(뮤텍스 락, 세마포, 모니터)

TEKI — Thu, 16 Feb 2023 00:11:28 +0900

프로세스의 동기화

동기화
'생산자와 소비자 문제'와 '임계 구역 문제'
핵심 동기화 도구: 뮤텍스 락, 세마포, 모니터

1. 동기화

서로 데이터를 주고받으며 동시다발적으로 실행되는 많은 프로세스는 동기화를 통해 일사불란하게 실행될 수 있다. 이때, 동기화 즉, 프로세스 동기화란 프로세스 사이의 수행 시간을 맞추는 것을 의미한다.

[1] 실행 순서 제어를 위한 동기화

프로세스는 올바른 순서대로 실행돼야 한다. 이를테면 특정 조건이 충족되어야 실행 가능한 프로세스의 경우에 해당 조건을 실행시키는 프로세스가 먼저 실행되어야 한다.

[2] 상호 배제를 위한 동기화

서로 다른 두 프로세스가 동시에 접근하면 안 되는 자원에 대해 한 번에 하나의 프로세스만 접근하도록 해야 한다.

2. '생산자와 소비자 문제'와 '임계 구역 문제'

◈ 생산자와 소비자 문제

상호 배제를 위한 동기화와 관련한 고전적이고 유명한 문제로 생산자와 소비자 문제가 있다. 이는 물건을 계속해서 생산하는 프로세스(생산자)와 물건을 계속해서 소비하는 프로세스(소비자)에 대한 문제로, 두 프로세스는 '총합'이라는 데이터를 공유하고 있다. 이는 프로세스가 제대로 동기화되지 않았기 때문에 발생한다. 이를테면 소비자의 작업이 끝나기도 전에 생산자가 총합을 수정하거나, 생산자의 작업이 끝나기도 전에 소비자가 총합을 수정하는 경우를 말한다.

◈ 임계 구역 문제

공유 자원(shared resource)이란, 앞서 말한 생산자와 소비자 문제의 예시에서 '총합'같은 것을 말한다. 또는 전역 변수, 파일, 입출력장치, 보조기억장치 등이 될 수 있다.

공유 자원 중에서 두 개 이상의 프로세스를 동시에 실행했을 때 문제가 발생하는 자원이 있는데, 이러한 자원에 접근하는 코드 영역을 임계 구역(critical section)이라고 한다. 잘못된 실행으로 임계 구역의 코드를 실행해 문제가 생길 수 있는데, 이를 레이스 컨디션(race condition)이라고 한다.

이러한 임계 구역 문제를 해결하는 방법, 즉 상호 배제를 위한 동기화를 위해서 3가지 원칙을 반드시 따라야 한다.

① 상호 배제 (mutual exclusion)
한 프로세스가 임계 구역에 진입했다면, 다른 프로세스는 임계 구역에 들어올 수 없다.

② 진행 (progress)
임계 구역에 어떤 프로세스도 진입하지 않았다면, 임계 구역에 진입하고자 하는 프로세스는 들어갈 수 있어야 한다.

③ 유한 대기 (bounded waiting)
한 프로세스가 임계 구역에 진입하고 싶다면, 그 프로세스는 언젠가는 반드시 임계 구역에 들어올 수 있어야 한다.

3. 핵심 동기화 도구: 뮤텍스 락, 세마포, 모니터

◈ 뮤텍스 락
→ '상호 배제' 원칙을 따르기 위해서는 임계 구역에 프로세스가 있는지 알아야 한다. 이를 위해 탈의실의 자물쇠와 같은 역할을 하는 뮤텍스 락을 사용한다.

뮤텍스 락의 매우 단순한 형태는 하나의 전역 변수(자물쇠 역할)와 두 개의 함수(잠그는 역할, 잠금을 푸는 역할)로 구현할 수 있다.

자물쇠 역할: 프로세스들이 공유하는 전역 변수
잠그는 역할: acquire 함수
잠금을 푸는 역할: release 함수

◈ 세마포
→ 뮤텍스 락은 하나의 자원이 있을 경우에만 적용 가능하다. 만약 자원이 여러 개라면 세마포를 사용한다. 세마포는 철도 신호기에서 유래한 단어로, 멈춤 신호일 경우엔 프로세스가 임계 구역에 들어가지 않고 대기하고, 출발 신호일 경우엔 프로세스가 임계 구역에 들어갈 수 있다.

세마포의 간단한 형태는 하나의 변수와 두 개의 함수로 구현할 수 있다.

사용 가능한 공유 자원의 개수: 전역변수 S
임계 구역 앞에서 멈춤 신호를 주는 신호기 역할: wait 함수
임계 구역 앞에서 출발 신호를 주는 신호기 역할: signal 함수

◈ 모니터
→ 세마포에서 매번 wait과 signal 함수를 명시해야 하는 번거로움과 그로 인한 코드 오류를 방지하기 위해 좀 더 간편한 도구로 개발된 것이 모니터이다. 모니터는 공유 자원과 공유 자원에 접근하기 위한 인터페이스를 묶어 관리하며, 프로세스는 반드시 인터페이스를 통해서만 공유 자원에 접근한다. 이를 위해 프로세스를 큐에 삽입하고, 순서대로 공유 자원을 할당한다.

[운영체제] Ch11. CPU 스케줄링

TEKI — Tue, 14 Feb 2023 20:15:23 +0900

CPU 자원을 분배하는 방법

CPU 스케줄링
CPU 스케줄링 알고리즘

1. CPU 스케줄링

운영체제가 프로세스에 공정하고 합리적으로 CPU 자원을 배분하는 것을 CPU 스케줄링이라고 한다. 이때, 프로세스의 우선순위 즉, 빨리 처리해야 하는 프로세스 순서에 따라 배분을 하게 된다.

◈ 프로세스 우선순위

우선순위가 높은 프로세스에 CPU를 먼저 할당한다. 예를 들어 입출력 작업이 많아 대기 상태에 많이 머무르는 입출력 집중 프로세스는 우선순위가 높다. 반면 CPU 작업이 많은 CPU 집중 프로세스는 대기 상태보다는 실행 상태에 더 많이 머무르므로 우선순위가 낮다. CPU 사용 빈도가 낮은 프로세스를 먼저 할당하여 빨리 완료시킨 후 CPU 사용 빈도가 높은 프로세스를 실행하는 게 더 효율적이기 때문이다. 이렇게 규칙에 따라 프로세스에 우선순위를 부여하여 PCB에 저장하고, 우선순위가 높은 프로세스를 더 빨리, 더 자주 실행한다.

◈ 스케줄링 큐

CPU 사용 우선순위를 포함해 메모리 적재, 입출력 장치 사용 등 자원 배분을 위해 PCB를 매번 조회하여 우선순위를 확인하는 작업은 리소스 낭비가 많다. 따라서 CPU를 사용하고 싶은 프로세스, 메모리에 적재되고 싶은 프로세스, 특정 입출력 장치를 사용하고 싶은 프로세스 등을 줄 세워서 스케줄링 큐로 구현하고 관리한다. (스케줄링 큐는 큐이지만 FIFO이 아니어도 된다). 운영체제가 관리하는 큐에는 CPU를 이용하려는 프로세스의 줄인 준비 큐(Ready Queue), 입출력 장치를 이용하려는 프로세스의 줄인 대기 큐(Waiting Queue) 등이 있다.

◈ 선점형 스케줄링과 비선점형 스케줄링

프로세스가 자원을 사용하고 있는 도중 운영체제가 자원을 강제로 빼앗아 다른 프로세스에 할당할 수 있는지 여부에 따라 선점형 스케줄링과 비선점형 스케줄링으로 나뉜다. 만약 가능하다면 선점형 스케줄링(Preemptive scheduling)이라고 하며, 자원 독점을 막고 골고루 분배할 수 있다는 장점이 있지만 context switching 과정에서 오버헤드가 발생할 위험이 있다. 만약 강제로 빼앗기가 불가능하다면 비선점형 스케줄링(Non-preemptive scheduling)이라고 하며, context switching으로 인한 오버헤드는 적지만 자원 사용이 급한 상황에도 먼저 사용 중인 프로세스가 사용을 종료할 때까지 기다려야 한다는 단점이 있다.

2. CPU 스케줄링 알고리즘

CPU 스케줄링 알고리즘은 운영체제마다 서로 다른 알고리즘을 사용하는 만큼 매우 다양하다. 용어보다는 아이디어에 집중하면서 공부한다.

[1] 선입 선처리 스케줄링

선입 선처리 스케줄링은 FCFS 스테줄링(First Come First Served Scheduling)이라고도 불린다.이는 단순히 준비 큐에 삽입된 순서대로 프로세스를 처리하는 비선점형 스케줄링 방식이다. 자원을 오래 사용하는 프로세스(우선순위가 높은 프로세스)가 와서 자원을 사용하기 시작하면, 사용이 종료될 때까지 기다려야 하는 단점(호위효과: Convoy Effect)이 있다.

[2] 최단 작업 우선 스케줄링

호위효과를 방지하기 위해 자원 사용 시간이 짧은 프로세스를 먼저 실행하는 방식을 최단 작업 우선 스케줄링 혹은 SJF 스케줄링(Shortest Job First Scheduling)이라고 한다.

[3] 라운드 로빈 스케줄링

라운드 로빈 스케줄링(Round Robin Scheduling)은 선입 선처리 스케줄링에 타임 슬라이스(각 프로세스가 자원을 사용할 수 있는 정해진 시간)라는 개념이 더해진 알고리즘이다. 즉, 타임 슬라이스만큼 돌아가면서 자원을 이용하는 선점형 스케줄링 알고리즘이다. 타임 슬라이스 크기가 매우 중요하다.

[4] 최소 잔여 시간 우선 스케줄링

최단 작업 우선 스케줄링과 라운드 로빈을 더하면 최소 잔여 시간 우선 스케줄링 또는 SRT 스케줄링(Shortest Remaining Time Scheduling)이 된다. 즉, 정해진 타임 슬라이스만큼 자원을 사용하되, 다음 순서는 남아있는 작업 시간이 가장 적은 프로세스로 정하는 알고리즘이다.

[5] 우선순위 스케줄링

우선순위 스케줄링(priority scheduling)은 프로세스에 우선순위를 부여하고, 가장 높은 우선순위를 가진 프로세스부터 실행하는 알고리즘이다. 하지만 우선순위가 낮은 프로세스가 준비 큐에 먼저 삽입되었음에도 우선순위가 밀리는 기아 현상(Starvation)이 발생할 수 있다. 이를 방지하기 위해 오래 대기한 프로세스의 우선순위를 점차 높이는 에이징(Aging) 기법이 있다.

[6] 다단계 큐 스케줄링

다단계 큐 스케줄링(miltilevel queue scheduling)에서는 우선순위 순위별로 큐를 따로 두고, 높은 우선순위의 큐부터 처리하는 방식이다. 이때, 큐마다 서로 다른 스케줄링 알고리즘을 적용할 수 있다.

[7] 다단계 피드백 큐 스케줄링

다단계 큐 스케줄링에서 발생하는 기아 현상을 보완하기 위해 나온 것이 다단계 피드백 큐 스케줄링(multilevel feedback queue scheduling)이다. 다단계 큐 스케줄링과 다른 점은 프로세스가 큐 사이를 이동할 수 있다는 것으로, 우선순위가 낮은 큐에서 준비 상태가 된 프로세스가 생기면 우선순위가 높은 큐로 이동할 수 있고, 반대로 CPU를 오래 사용해야 하는 프로세스는 우선순위가 낮은 큐로 이동할 수 있다. 구조는 복잡하지만 가장 일반적인 CPU 스케줄링 알고리즘으로 알려져 있다.

[운영체제] Ch10. 프로세스와 스레드, 멀티프로세스와 멀티스레드

TEKI — Mon, 13 Feb 2023 23:32:36 +0900

우리가 알아야 할 컴퓨터 구조 지식 두 가지

프로세스
프로세스 상태와 프로세스 계층 구조
스레드
멀티프로세스와 멀티스레드

1. 프로세스

지금까지 '실행 중인 프로그램'이라고 표현하던 것을 프로세스라고 부른다. 프로그램이 실행되기 전까지는 보조기억장치에 있는 데이터 덩어리로 있다가 메모리로 옮겨 적재하고 실행하는 순간부터는 프로세스가 된다.

◈ 포그라운드 프로세스(Foreground Process)와 백그라운드 프로세스(Background Process)

사용자가 볼 수 있는 공간에서 실행되는 프로세스를 포그라운드 프로세스라고 하고, 보이지 않는 공간에서 실행되는 프로세스를 백그라운드 프로세스라고 한다. 이러한 백그라운드 프로세스를 유닉스 체계의 운영체제에서는 데몬(Daemon), 윈도우 운영체제에서는 서비스(Service)라고 부른다.

◈ 프로세스 제어 블록 (PCB: Process Control Block)

모든 프로세스는 CPU를 필요로 하지만, 모든 프로세스가 한정된 자원인 CPU를 동시에 사용할 수는 없다. 따라서 프로세스는 돌아가면서 한정된 시간만큼만 CPU를 사용하고, 타이머 인터럽트(한정된 시간의 끝을 알리는 인터럽트)가 발생하면 다음 차례를 기다린다. 운영체제는 이러한 사이클을 관리하는 프로세스 제어 블록을 이용한다.

프로세스 제어 블록은 프로세스와 관련된 정보를 저장하는 자료 구조로, 프로세스 생성 시 만들어지고 실행이 끝나면 폐기된다.

PCB에 담기는 대표적인 정보

① 프로세스 ID (PID: Process ID)
: 특정 프로세스를 식별하기 위한 고유 번호를 저장한다. 같은 프로그램이라도 두 번 실행하면 서로 다른 두 개의 PID가 생성된다.

② 레지스터 값
: 프로세스가 자신의 실행 차례가 돌아왔을 때 이전까지 사용했던 레지스터의 중간값을 복원하여 진행하던 작업을 이어 실행할 수 있도록 프로그램 카운터를 비롯한 레지스터 값을 저장한다.

③ 프로세스 상태
: 현재 프로세스의 상태를 기록한다.

④ CPU 스케줄링 정보
: 프로세스가 언제, 어떤 순서로 CPU를 할당받을지에 대한 정보를 저장한다.

⑤ 메모리 관리 정보
: 베이스 레지스터, 한계 레지스터, 페이지 테이블 정보 등 필요한 정보가 있는데 프로세스마다 메모리에 저장된 위치가 다르므로 프로세스가 어느 주소에 저장되어 있는지에 대한 정보가 있어야 한다.

⑥ 사용한 파일과 입출력장치 목록
: 프로세스가 실행 과정에서 사용한 파일과 입출력장치 정보가 PCB에 기록된다.

◈ 문맥 교환 (Context Switching)

하나의 프로세스 수행을 재개하기 위해 기억해야 할 정보를 문맥(Context)이라고 하고, 이 데이터는 해당 프로세스의 PCB에 표현되어 있다. 프로세스가 CPU를 사용할 수 있는 시간이 다 되거나 예기치 못한 상황으로 인터럽트가 발생하면 운영체제는 해당 프로세스의 PCB에 문맥을 백업하고, 뒤이어 다음 차례인 프로세스의 복구하는 식으로 실행 중인 프로세스를 바꾸는 것을 문맥 교환이라고 한다.

문맥 교환이 빠르게 번갈아가며 수행되기 때문에 여러 프로세스가 동시에 실행되는 것처럼 보이는데, 문맥 교환이 너무 자주 일어나면 오버헤드가 발생할 수 있다.

하나의 프로세스는 사용자 영역에 크게 코드 영역, 데이터 영역, 힙 영역, 스택 영역으로 나뉘어 저장된다.

[1] 코드 영역(Code Segment) 또는 텍스트 영역(Text Segment)

코드 영역 또는 텍스트 영역에는 실행할 수 있는 코드, 즉 기계어로 이루어진 명령어가 저장된다.
쓰기가 금지되어 있는 읽기 전용 (Read-Only) 공간이다. (CPU가 실행할 명령어라 담겨 있기 때문)
프로그램이 실행되는 동안 크기가 변하지 않는다. (정적 할당 영역)

[2] 데이터 영역 (Data Segment)

프로그램이 실행되는 동안 유지할 데이터가 저장되는 공간으로, '전역 변수'가 대표적이다.
프로그램이 실행되는 동안 크기가 변하지 않는다. (정적 할당 영역)

[3] 힙 영역

프로그램을 만드는 사용자가 직접 할당할 수 있는 저장 공간이며, 언젠가는 반환해야 한다.
메모리 공간을 반환하지 않으면 메모리 누수 이슈가 발생하게 된다.
프로그램을 실행하는 동안 크기가 변할 수 있다. (동적 할당 영역)
동적 할당 영역이므로 스택 영역과 반대로 낮은 주소에서 높은 주소로 할당하여 겹치지 않도록 한다.

[4] 스택 영역

데이터를 일시적으로 저장하는 공간으로, 잠깐 쓰다 말 매개 변수, 지역 변수 등이 저장된다.
실시간으로 크기가 변할 수 있다. (동적 할당 영역)
동적 할당 영역이므로 힙 영역과 반대로 높은 주소에서 낮은 주소로 할당하여 겹치지 않도록 한다.

2. 프로세스 상태와 프로세스 계층 구조

프로세스의 상태를 표현하는 방식은 운영체제마다 조금씩 차이가 있지만, 대표적인 상태는 아래와 같다.

[1] 생성 상태
→ 프로세스를 생성 중인 상태로, 막 메모리에 적재되어 PCB를 할당받은 상태.

[2] 준비 상태
→ CPU를 할당받아 실행할 자기 차례를 기다리는 상태

[3] 실행 상태
→ CPU를 할당받아 실행 중인 상태. 할당된 시간을 모두 사용하여 타이머 인터럽트가 발생하면 다시 준비 상태가 되고, 실행 도중 입출력장치를 사용하여 입출력 장치의 작업이 끝날 때까지 기다려야 한다면 대기 상태가 된다.

[4] 대기 상태
→ 프로세스 실행 도중 입출력장치를 사용하면 입출력을 끝날 때(입출력 완료 인터럽트를 받을 때)까지 기다리는 상태. 입출력 작업이 완료되면 해당 프로세스는 다시 준비 상태로 CPU 할당을 기다린다.

[5] 종료 상태
→ 프로세스가 종료된 상태. 프로세스가 종료되면 운영체제는 PCB와 프로세스가 사용한 메모리를 정리한다.

◈ 부모 프로세스(Parent Process)와 자식 프로세스(Child Process)

프로세스가 실행 도중 시스템 호출을 통해 다른 프로세스를 생성할 경우, 기존 프로세스를 부모 프로세스, 새로 만들어진 프로세스를 자식 프로세스라고 한다.

부모 프로세스와 자식 프로세스는 각기 다른 PID를 가진다. 일부 운영체제에서는 자식 프로세스의 PCB에 부모 프로세스의 PID인 PPID(Parent PID)가 기록되기도 한다.

컴퓨터 부팅 시점부터 실행되는 최초의 프로세스와 그 자식 프로세스들을 트리 구조로 나타낸 것을 프로세스 계층 구조라고 한다. 예를 들어 사용자가

① 사용자가 컴퓨터를 켠다.
→ 부팅과 동시에 생성된 최초 프로세스가 실행된다.

② 로그인 창을 통해 성공적으로 로그인한다.
→ 최초 프로세스로부터 로그인 프로세스가 생성되고 이로부터

③ bash 쉘을 켠다.
→ 로그인 프로세스에서 사용자 인터페이스(bash 쉘) 프로세스가 생성된다.

④ bash 쉘에서 Vim 편집기를 실행시킨다.
→ 사용자 인터페이스 프로세스로부터 Vim 프로세스가 생성된다.

와 같은 작업을 했다고 가정할 때 생성되는 프로세스의 계층 구조를 도표로 나타내면 아래와 같다.

3. 스레드

스레드는 실행의 단위로, 더 자세하게 표현하면 프로세스를 구성하는 실행의 흐름 단위를 말한다. 프로세스의 스레드들은 실행에 필요한 최소한의 정보(프로그램 카운터를 포함한 레지스터, 스택)만을 유지한 채 프로세스 자원을 공유하며 실행된다.

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

프로그램을 실행하면서 여러 프로세스가 동시에 실행될 수 있다. 이를 멀티프로세스라고 한다.
스레드는 프로세스를 구성하는 실행 단위라고 볼 수 있고, 여러 스레드로 프로세스를 동시에 실행하는 것을 멀티스레드라고 한다.

[혼공학습단 9기] 혼공컴운 5주차 미션

TEKI — Mon, 13 Feb 2023 00:58:15 +0900

5주 차 미션!

[미션 1] p. 363의 확인 문제 1번 풀고 인증하기

① 뮤텍스 락은 임계 구역을 잠근 뒤 임계 구역에 진입함으로써 상호 배제를 위한 동기화를 이룹니다. (O)

② 세마포는 공유 자원이 여러 개 있는 상황에서도 이용할 수 있습니다. (O)

③ 세마포를 이용해 프로세스 실행 순서 제어를 위한 동기화도 이룰 수 있습니다. (O)

④ 세마포를 이용하면 ~~반드시 바쁜 대기를 해야 합니다.~~ (X)
→ 대기(wait) 또는 가도 좋다는 신호(signal)에 따르게 되고, 대기 상태로 만들 수 있습니다.

[미션 2] Ch.12(12-1) 임계 구역, 상호 배제 개념을 정리하기

공유 자원 중에서 두 개 이상의 프로세스를 동시에 실행했을 때 문제가 발생하는 자원이 있는데, 이러한 자원에 접근하는 코드 영역을 임계 구역(critical section)이라고 한다. 잘못된 실행으로 임계 구역의 코드를 실행해 문제가 생길 수 있는데, 이를 레이스 컨디션(race condition)이라고 한다. 이러한 임계 구역 문제를 해결하는 방법, 즉 상호 배제를 위한 동기화를 위해서 3가지 원칙을 반드시 따라야 한다.

① 상호 배제 (mutual exclusion)
한 프로세스가 임계 구역에 진입했다면, 다른 프로세스는 임계 구역에 들어올 수 없다.

② 진행 (progress)
임계 구역에 어떤 프로세스도 진입하지 않았다면, 임계 구역에 진입하고자 하는 프로세스는 들어갈 수 있어야 한다.

③ 유한 대기 (bounded waiting)
한 프로세스가 임계 구역에 진입하고 싶다면, 그 프로세스는 언젠가는 반드시 임계 구역에 들어올 수 있어야 한다.

공부한 내용

Chapter 12 프로세스 동기화
→ [운영체제] Ch12. 동기화 문제(생산자와 소비자 문제, 임계 구역 문제)과 동기화 도구(뮤텍스 락, 세마포, 모니터)
Chapter 13 교착 상태
→ [운영체제] Ch13. 교착 상태(데드락)에 대응하는 방법

[운영체제] Ch09. 운영체제 이해하기

TEKI — Sun, 12 Feb 2023 21:00:20 +0900

운영체제 이해하기

커널과 이중 모드 및 시스템 호출
운영체제의 핵심 서비스

1. 커널과 이중 모드 및 시스템 호출

운영체제의 핵심 서비스를 담당하는 부분을 커널이라고 한다. 따라서 운영체제가 설치된 모든 기기에는 커널이 있고, 어떤 커널을 사용하는지에 따라 프로그램이 하드웨어를 이용하는 양상 및 컴퓨터 전체의 성능에 차이가 생길 수 있다. 커널에 포함되지 않는 서비스에는 사용자 인터페이스 등이 있다.

운영체제는 하드웨어 자원 관리와 보호를 위해 오직 자신을 통해서만 자원에 접근하도록 한다. 이러한 문지기 역할은 CPU가 명령어를 실행하는 모드를 크게 사용자 모드와 커널 모드로 구분하는 이중 모드로 구현된다.

◈ 사용자 모드
→ 사용자 모드는 운영체제 서비스를 제공받을 수 없는 실행 모드 즉, 커널 영역의 코드를 실행할 수 없는 모드이다.

◈ 커널 모드
→ 운영체제 서비스를 제공받을 수 있는 실행 모드 즉, 커널 영역의 코드를 실행할 수 있는 모드이다.

CPU가 커널 모드로 명령어를 실행하면 자원에 접근하는 명령어를 비롯한 모든 명령어를 실행할 수 있다. 운영체제는 커널 모드로 실행되기 때문에 자원에 접근할 수 있다. 하지만 일반적인 응용 프로그램은 기본적으로 사용자 모드로 실행되므로 자원에 접근할 수 없다. 사용자 모드로 실행되는 프로그램이 자원에 접근하는 운영체제 서비스를 제공받으려면 운영체제에 요청(시스템 호출)을 보내 커널 모드로 전환해야 한다. 일반적으로 응용 프로그램은 실행 과정에서 운영체제 서비스를 매우 빈번하게 이용하므로 그 과정에서 시스템 호출을 빈번하게 발생시킨다.

2. 운영체제의 핵심 서비스

[1] 프로세스

실행 중인 프로그램으로, 일반적으로 하나의 CPU는 한 번에 하나의 프로세스만 실행할 수 있기에 CPU는 프로세스들을 번갈아가면서 조금씩 실행한다.

[2] 자원 접근 및 할당

모든 프로세스는 실행을 위해 자원을 필요로 하며, 운영체제는 프로세스들이 사용할 자원에 접근/조작하여 프로세스에 필요한 자원을 할당해준다.

◈ CPU
→ 하나의 CPU는 한 번에 하나의 프로세스만 실행할 수 있으므로 공정하게 CPU를 할당하기 위해 CPU 스케줄링을 한다.

◈ 메모리
→ 메모리에 적재되는 프로세스들은 크기도, 주소도 모두 가지각색으로 메모리가 부족하거나 메모리 공간이 있음에도 프로세스를 적재하지 못하는 경우가 없도록 운영체제는 메모리를 잘 할당해야 한다.

◈ 입출력장치
→ 입출력장치가 발생시키는 하드웨어 인터럽트를 포함한 인터럽스 서비스 루틴은 운영체제가 제공하는 기능으로 커널 영역에 있다.

[3] 파일 시스템 관리

디렉토리로 묶어 파일을 관리하는 파일 시스템도 운영체제의 핵심 서비스 중 하나이다.

[컴퓨터구조] Ch06. RAM과 캐시메모리, 그리고 주소공간

TEKI — Sun, 12 Feb 2023 20:06:05 +0900

RAM의 용량과 성능
RAM의 종류
메모리의 물리주소와 논리주소
저장 장치 계층 구조
캐시 메모리와 참조 지역성 원리

1. RAM의 용량과 성능

전원을 끄면 저장된 내용이 사라지는 휘발성 저장 장치(Volatile Memory): RAM 등
전원이 꺼져도 저장된 내용이 유지되는 비휘발성 저장 장치(Non-Volatile Memory): 하드 디스크, SSD, CD-ROM, USB 등

보조기억장치는 전원을 꺼도 내용을 유지하지만, CPU가 보조기억장치에 직접 접근하지 못함. 그래서 일반적으로 보조기적장치(비휘발성 저장 장치)에는 보관할 대상을 저장하고, RAM(휘발성 저장 장치)에는 실행할 대상을 저장함.

RAM 용량이 적다면 실행할 프로그램이 저장된 보조기억장치에서 정보를 자주 가져와야 해서 실행시간이 길어질 것이다.
RAM 용량이 크다면 실행할 프로그램이 저장된 보조기억장치에서 많은 정보를 한 번에 가져와 미리 RAM에 저장해 놓을 수 있어 정보를 가져오는 리소스가 줄어드는 만큼 실행 시간을 줄일 수 있지만, 그보다 더 줄일 수는 없다.

2. RAM의 종류

◈ DRAM (Dynamic RAM)
→ 시간이 지나면 저장된 데이터가 점차 사라진다는 특징이 있다. 대신 소비 전력이 비교적 낮고, 저렴하며, 집적도가 높아 대용량 설계가 용이하다는 장점이 있다.

◈ SRAM (Static RAM)
→ 시간이 지나도 데이터가 사라지지 않는다는 점에서 DRAM과 차이가 있으며, 이로인해 데이터를 재활성화할 필요가 없고, DRAM과 비교해 속도가 빠르다는 장점이 있다. 대신 소비 전력이 크고, 비싸며, 집적도가 낮다는 단점이 있다. 그래서 대용량으로 만들어질 필요는 없지만 속도가 빨라야 하는 저장 장치(ex: Cache Memory)에서 사용된다.

◈ SDRAM (Synchronous Dynamic RAM)
→ 클럭 신호와 동기화된, 발전된 형태의 DRAM이다. '클럭 신호와 동기화되었다'는 것은 클럭 타이밍에 맞춰 CPU와 정보를 주고받을 수 있다는 것을 의미한다.

◈ DDR SDRAM (Double Data Rate SDRAM)
→ 가장 흔히 사용되는 RAM으로, 대역폭을 SDRAM보다 두 배 넓혀 속도를 빠르게 만든 SDRAM이다. 대역폭을 두 배 넓혔다는 것은 한 클럭에 두 배 많은 데이터를 전송할 수 있음을 의미한다.

◈ DDR2 SDRAM, DDR3 SDRAM, DDR4 SDRAM
→ DDR2 SDRAM은 DDR SDRAM의 두 배 대역폭을, DDR3 SDRAM은 DDR2 SDRAM의 두 배 대역폭을 가진다. 최근 흔히 사용하는 메모리인 DDR4 SDRAM는 SDRAM보다 16배 넓은 대역폭을 가진다.

https://blog.naver.com/kangyh5/222129548478

3. 메모리의 물리주소와 논리주소

물리 주소: 실제로 정보가 저장된 메모리 하드웨어가 사용하는 주소
논리 주소: CPU와 실행 중인 프로그램이 사용하는 주소로 각 프로그램 당 0번지부터 부여됨

물리 주소와 논리 주소간의 변환은 CPU와 주소 버스 사이에 위치한 메모리 관리 장치(MMU: Memory Management Unit)이라는 하드웨어에 의해 수행됨. MMU는 CPU가 발생시킨 논리 주소에 베이스 레지스터 값을 더하여 논리 주소를 물리 주소로 변환함.
*베이스 레지스터는 프로그램의 가장 작은 물리 주소, 즉 프로그램의 첫 물리 주소를 저장

◈ 메모리 보호 기법

다른 프로그램의 영역을 침범할 수 있는 명령어로부터 프로그램을 보호하기 위해 한계 레지스터를 이용해 논리 주소 범위를 벗어나는 명령어 실행을 방지하여 실행중인 프로그램이 다른 프로그램에 영향을 받지 않도록 한다. 이를 위해 한계 레지스터는 실행 중인 프로그램의 논리 주소의 최대 크기를 저장하고 있으며, 만약 CPU가 한계 레지스터보다 높은 논리 주소에 접근하려고 하면 인터럽트(트랩)를 발생시켜 실행을 중단한다.

4. 저장 장치 계층 구조

컴퓨터가 사용하는 저장 장치들을 'CPU에 얼마나 가까운가'를 기준으로 계층적으로 나타낸 것을 저장 장치 계층 구조라고 하며, 아래와 같이 생겼다.

https://chogyujin.github.io/2019/03/26/2.8-%EC%A0%80%EC%9E%A5-%EC%9E%A5%EC%B9%98%EC%9D%98-%EA%B3%84%EC%B8%B5-%EA%B5%AC%EC%A1%B0/

5. 캐시 메모리와 참조 지역성 원리

캐시 메모리

CPU와 메모리 사이에 위치함
레지스터보다 용량이 크고 메모리보다 빠름
SRAM 기반의 저장 장치
CPU 연산 속도와 메모리 접근 속도의 차이를 줄이기 위해 탄생함
*CPU가 매번 메모리에 왔다 갔다 하는 건 시간이 오래 걸리니, 메모리에서 CPU가 사용할 일부 데이터를 미리 캐시 메모리로 가지고 와서 활용하자는 것

캐시 메모리의 종류

컴퓨터 내부의 여러 캐시 메모리를 CPU(코어)와 가까운 순서대로 L1 캐시, L2 캐시, 그리고 L3 캐시라고 부른다.

① L1 캐시 (Level 1 Cache)
: 계산을 도맡아 수행하는 부품

② L2 캐시 (Level 2 Cache)
: 프로그램을 실행하는데 필요한 값들을 임시로 저장하는 장치로, 하나의 CPU에 각기 다른 이름과 역할을 가진 레지스터가 여럿 존재

③ L3 캐시 (Level 3 Cache)
:제어 신호(Control Signal)를 내보내고 명령어를 해석하는 장치

https://velog.io/@emplam27/CS-%EC%BB%B4%ED%93%A8%ED%84%B0-%EC%8B%9C%EC%8A%A4%ED%85%9C-1.51.7%EC%9E%A5-%EC%BA%90%EC%8B%9C-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C

캐시 메모리는 메모리보다 용량이 적으므로 메모리의 일부만 가져와 저장할 수 있다. 그러므로 자주 사용될 것으로 예측되는 데이터를 중심으로 저장하는데, 이때 예측한 데이터가 실제로 CPU에서 활용될 경우를 캐시 히트라고 하고, 반대의 경우 즉, 예측이 틀려 메모리에서 데이터를 가져와야 하는 경우를 캐시 미스라고 한다. 캐시 히트와 캐시 미스인 모든 경우에 대해 캐시가 히트되는 비율을 캐시 적중률이라 하며, 아래와 같이 계산한다.

캐시 히트 횟수 / (캐시 히트 횟수 + 캐시 미스 횟수)

우리가 사용하는 컴퓨터의 캐시 적중률은 대상 85~95% 이상으로, 100번 중 85~95번 꼴로 캐시 히트를 하는 셈이다. 이렇게 높은 캐시 적중률을 위해 캐시 메모리는 참조 지역성의 원리(locality of reference, principle of locality)라고 하는 원칙에 따라 메모리에서 어떤 데이터를 가져올지 결정한다. 이 원칙은 아래와 같다.

① CPU는 최근에 접근했던 메모리 공간에 다시 접근하려는 경향이 있다. (시간 지역성)
② CPU는 접근한 메모리 공간 근처를 접근하려는 경향이 있다. (공간 지역성)

[컴퓨터구조] Ch05. CPU 제대로 쓰기

TEKI — Fri, 10 Feb 2023 22:04:58 +0900

CPU를 이해하고 제대로 사용하기

빠른 CPU를 위한 설계 기법
명령어 병렬 처리 기법
ISA와 CISC, RISC

1. 빠른 CPU를 위한 설계 기법

CPU 성능을 높이는 방법에는 3가지가 있다.

클럭 속도를 높이는 방법
코어를 늘리는 방법
스레드 수를 늘리는 방법

[1] 클럭 속도를 높이는 방법

"컴퓨터 부품들은 '클럭 신호'에 맞춰 일사불란하게 움직인다."
"CPU는 '명령어 사이클'이라는 정해진 흐름에 맞춰 명령어를 실행한다."

즉, 클럭 속도가 높아지면 CPU는 명령어 사이클을 더 빠르게 반복하고, 다른 부품들도 그에 발맞춰 더 빠르게 작동할 것이다.
실제로 클럭 속도가 높은 CPU는 일반적으로 성능이 좋기 때문에 클럭 속도를 CPU 속도 단위로 간주하기도 한다.

클럭 속도는 헤르츠(㎐)단위로 측정한다.
*1㎐는 1초에 한 번을 의미한다.
*1㎓ = 1,000,000,000㎐

클럭 속도는 일정하지 않다. 그래서 보통 기본 클럭 속도(Base)와 최대 클럭 속도(Max)로 나누어 표기한다.
최대 클럭 속도를 강제로 더 끌어올리는 것을 오버클럭킹(overclocking)이라고 한다.
단, 이때 무조건 CPU가 빨라지는 것은 아니며, 발열 문제가 심각해지기도 한다.

[2] 코어를 늘리는 방법

ALU, 제어장치, 레지스터 등을 포함하는 '코어'는 CPU 내에서 명령어를 실행하는 부품으로, CPU 안에 하나 또는 둘 이상이 있을 수 있다.
코어를 여러 개 포함하고 있는 CPU를 멀티코어(multi-core) CPU 또는 멀티코어 프로세서라고 부른다.

코어의 개수에 따라 듀얼 코어(2개), 쿼드코어(4개), 옥타코어(8개) 등으로 불리는데, 코어의 개수가 증가할수록 CPU의 성능이 더 좋아진다. 하지만 그렇다고 CPU의 연산 속도 증가율이 코어 개수에 비례하지는 않는다.

[3] 스레드 수를 늘리는 방법

스레드의 사전적 의미는 '실행 흐름의 단위'이다.
하지만 실제로 스레드에는 CPU에서 사용되는 하드웨어적 스레드가 있고, 프로그램에서 사용되는 소프트웨어적 스레드가 있으므로 구별하여 이해해야 한다.

◈ 하드웨어적 스레드
→ 하나의 코어가 동시에 처리하는 명령어 단위

여러 스레드를 지원하는 CPU는 하나의 코어로도 여러 개의 명령어를 동시에 실행할 수 있다. 이런 CPU를 멀티스레드(multithread) 프로세서 또는 멀티스레드 CPU라고 한다.

◈ 소프트웨어적 스레드
→ 하나의 프로그램에서 독립적으로 실행되는 단위

소프트웨어적 스레드를 이용하면 하나의 프로그램에서 여러 부분이 동시에 실행될 수 있다. 그리고 한 번에 하나씩 명령어를 처리하는 1코어 1스레드 CPU도 소프트웨어적 스레드를 수십 개 실행할 수 있다.

2. 명령어 병렬 처리 기법

대표적인 명령어 병렬 처리 기법에는 다음과 같은 것들이 있다.

명령어 파이프라이닝
슈퍼스칼라
비순차적 명령어 처리

[1] 명령어 파이프라이닝

명령어 처리 과정을 클럭 단위로 나누어 보면 일반적으로 다음과 같이 나눌 수 있습니다.

각 단계가 겹치지만 않는다면, CPU는 각 단계를 '동시에' 실행할 수 있다.
전체 실행 시간을 비슷한 시간 간격으로 나눈 t1 ~ tn의 시간 동안 여러 개의 명령어를 동시에 실행한다면, 아래와 유사하게 명령어를 처리할 수 있다.

이렇게 명령어들을 명령어 파이프라인에 넣고 동시에 처리하는 기법을 명령어 파이프라이닝이라고 한다.

특정 상황에서는 성능 향상에 실패하는 경우가 있는데, 이러한 상황을 파이프라인 위험이라고 한다. 파이프라인 위험에는 크게 데이터 위험, 제어 위험, 구조적 위험이 있다.

◈ 데이터 위험
→ 명령어 간 데이터 의존성에 의해 발생하는 위험으로, 이전 명령어를 끝까지 실행해야만 비로소 실행할 수 있는 명령어와 같이 의존적인 명령어가 있는 경우에 모든 명령어를 동시에 처리할 수 없기 때문에 발생한다.

◈ 제어 위험
→ 분기 등으로 인한 프로그램 카운터의 갑작스러운 변화에 의해 발생하는 위험으로, 프로그램 카운터가 저장하고 있는 '현재 실행중인 명령어의 다음 주소'가 갑작스러운 변화로 처리 중인 명령어가 쓸모 없어지는 경우 발생한다. 이를 방지하기 위해 '분기 예측'과 같은 기술을 사용할 수 있다.

◈ 구조적 위험
→ 명령어를 겹쳐 실행하는 과정에서 서로 다른 명령어가 동시에 ALU, 레지스터와 같은 CPU 부품을 사용하려고 할 때 발생하는 위험으로, 자원 위험이라고도 한다.

[2] 슈퍼스칼라

명령어 파이프라이닝을 단일 파이프라인이 아닌 둘 이상의 파이프라인으로 구현하여 CPU 내부에 여러 개의 명령어 파이프라인을 포함하는 구조를 슈퍼스칼라(superscalar)라고 한다.

슈퍼스칼라 구조로 명령어 처리가 가능한 CPU를 슈퍼스칼라 프로세서 또는 슈퍼스칼라 CPU라고 한다. 이론적으로 슈퍼스칼라 프로세서는 파이프라인 개수에 비례하여 프로그램 처리 속도가 빨라져야 하지만, 파이프라인이 증가할수록 여러 가지 위험이 증가하기 때문에 파이프라인 개수에 비례하여 성능이 향상되지는 않는다.

[3] 비순차적 명령어 처리

순서를 바꿔도 무방한 명령어를 먼저 실행하여 명령어 파이프라인이 멈추는 것을 방지하는 기법을 비순차적 명령어 처리라고 한다.

3. ISA와 CISC, RISC

명령어 집합 또는 명령어 집합 구조(ISA: Instruction Set Architecture)는 CPU가 이해할 수 있는 명령어들의 모음을 말한다. CPU마다 사용하는 명령어가 조금씩 다르므로 ISA도 다를 수 있다.
*명령어 집합 '구조'인 이유는 CPU가 어떤 명령어를 이해하는지에 따라 컴퓨터 구조 및 설계 방식이 달라지기 때문이다.

개발자들이 주로 사용하는 High-Level Language를 컴퓨터가 이해하는 Low-Level Language로 번역하기 위해서는 어셈블러와 컴파일러가 필요하다. Low-Level Language로 번역된 명령어는 하드웨어로 전달되어야 하는데, 이때 소프트웨어와 하드웨어를 연결해주는 것이 ISA이다.

출처: https://velog.io/@apphia39/%EC%BB%B4%ED%93%A8%ED%84%B0%EA%B5%AC%EC%A1%B0ISA-CISC-vs.-RISC

◈ ISA 명령어의 종류 (대표적으로)

산술 논리 명령어(ADD, SUB)
데이터 전송 명령어(LOAD, STORE)
실행 흐름 제어 명령어(BRANH, CALL, TRAP)
부동 소수점 연산 명령어

CISC(Complex Instruction Set Computer)은 직역하면 '복잡한 명령어 집합을 활용하는 컴퓨터'를 의미한다. CISC는 다양하고 강력한 기능의 명령어 집합을 활용하기 때문에 명령어의 형태와 크기가 다양한 가변 길이 명령어를 활용한다. x86, x86-64가 대표적인 CISC 기반의 ISA이다.

RISC(Reduced Instruction Set Computer)은 CISC에 비해 적은 명령어 집합을 사용한다. RISC는 아래와 같이 CISC의 한계에 대응한 원칙에 의거해 등장했다.

1) 원활한 파이프라이닝을 위해 명령어 길이와 수행 시간이 짧고 규격화 되어있어야 한다.
2) 어차피 자주 쓰이는 명령어만 줄곧 사용되니 자주 쓰이는 기본적인 명령어를 작고 빠르게 만드는 것이 중요하다.

RISC는 CISC와 달리 짧고 규격화된 명령어 즉, 1클럭 내외로 실행되는 명령어를 지향하며, 고정 길이 명령어를 사용한다.

무료로 동영상에 자막 넣는 방법

TEKI — Thu, 9 Feb 2023 23:56:31 +0900

▶ 이 글에서는 맥북에서 동영상에 자막을 넣는 방법을 다루지만, 윈도우 환경에서도 크게 다르지 않습니다.
▶ 이 글에서 사용할 프로그램은 HandBrake이며, 무료입니다.
▶ 이 글에서 사용할 동영상은 Pixabay에서 가져온 동영상입니다.

- 순서 -

1. 동영상 준비하기
2. 자막 파일(srt) 만들기
3. HandBrake 설치하기
4. HandBrake로 동영상에 자막 파일 넣기

1. 동영상 준비하기

이 글에서 사용할 동영상은 Pixabay에서 가져온 동영상으로, Pixabay에서 무료로 사용 가능하도록 공개한 동영상입니다.

2. 자막 파일(srt) 만들기

다음으로 위 파도 영상에 넣을 자막 파일이 필요합니다.
자막 파일에는 .smi, .srt, 그리고 .ass가 있습니다. (자세한 설명은 이 글을 참고해주세요)
이 중에서 srt 자막 파일을 만들어봅시다.
srt 파일을 만드는 방법은 (1)직접 만드는 방법과 (2)프로그램으로 만드는 방법이 있습니다.
이번에는 텍스트 에디터로 직접 만들어보겠습니다.

srt 파일의 형식
srt 파일은 아래와 같은 형식을 갖추고 있습니다.

순번
시작시간 --> 끝나는시간
자막자막자막

[1] 순번 : 순번은 자막의 순서를 명시합니다. 없거나 순서가 틀려도 무관합니다.
[2] 시작시간 : 시작시간은 HH:MM:SS,SSS 의 형태로, 동영상에서 자막이 나타나는 시각을 의미합니다.
[3] 끝나는시간 : 끝나는 시간은 HH:MM:SS,SSS의 형태로, 동영상에서 자막이 사라지는 시각을 의미합니다.
[4] 자막자막자막 : 실제로 보여지는 자막을 의미합니다. 줄바꿈이나 간단한 폰트 설정도 가능합니다.

srt 파일 예시
아래는 이 글에서 사용할 srt 파일의 내용입니다.

0
00:00:00.10 --> 00:00:07.20 
<주말이 짧게 느껴지는 과학적 근거>

1
00:00:08.70 --> 00:00:14.70
평일 : 월화수목금

2
00:00:14.71 --> 00:00:20.70 
평일 : 월화수목금
주말 : 토일

3
00:00:20.80 --> 00:00:28.10
실제로 짧다

4
00:00:28.11 --> 00:00:36.10
- 하상욱 단편 시집 '서울시' 중에서

srt 파일 만들기
텍스트 에디터를 열어 자막 정보를 기입합니다. 그런 다음 확장자를 .srt로 설정하여 저장하면 끝입니다.

3. HandBrake 설치하기

https://handbrake.fr/
위 사이트에 들어가서 HandBrake를 설치합니다.

4. HandBrake로 동영상에 자막 파일 넣기

HandBrake를 실행하면 아래와 같이 파일을 선택하는 창이 뜹니다.

만약 아래와 같이 뜬다면, 왼쪽 상단에 있는 Open Source 버튼을 눌러주면 됩니다.

여기에서 자막을 넣을 동영상 파일을 선택하고, open 버튼을 눌러줍니다.

그럼 아래와 같이 영상이 준비됩니다.

자막을 넣은 동영상을 저장할 이름과 위치는 아래 부분에서 설정해주면 됩니다.

그 다음, Subtitles 메뉴로 이동합니다. 여기에서 자막을 넣어줄겁니다.

아래 빈 공간에서 마우스 우클릭을 하면 몇 가지 항목이 보입니다. 그 중에서 'Add External Subtitles Track...'을 클릭해줍니다.

그런다음 앞서 만든 자막 파일을 찾아 Open 버튼을 눌러 열어줍니다.

그러면 아래와 같이 자막이 등록됩니다.

이제 다음 3가지를 설정해준 후, Start 버튼을 눌러 작업을 시작해줍니다.

Save As 옆 텍스트를 눌러 자막을 넣은 영상을 어떤 이름으로 저장할 지 설정해줍니다.
인코딩과 언어를 설정해줍니다.
자막 파일을 Burned In에 체크해줍니다. (가장 중요한 단계입니다)

위 설정을 마치고 Start 버튼을 누르면 아래 부분에 진행 상황이 나타나며 자막을 합치는 작업이 진행됩니다.

결과물입니다.

*업로드 크기 제한이 있어서 50초로 잘라 업로드했습니다.

혼자 공부하는 데이터 분석 with 파이썬 / 한빛미디어

TEKI — Thu, 9 Feb 2023 09:39:34 +0900

데이터 과학은 데이터 세계와 비즈니스 세계를 잇는 다리입니다.

- Ji Li

위 문장은 책에서 데이터 과학자 Ji Li가 Quora에 올린 글을 번역한 내용 중 일부이다. 이 문장은 '데이터 분석'과 '데이터 과학'의 차이점을 잘 드러낸다. 글의 다음 내용을 더 읽어보면 "데이터 과학을 하려면 프로그래밍, 통계학, 시각화와 더불어 비즈니스 감각을 갖추어야 합니다."라고 말한다. 즉, 데이터 과학은 아주 넓은 범위를 아우른다는 말이다. 반면 데이터 분석은 데이터 과학의 한 부분에 해당한다.

'결과물'을 중점으로 이해해 보면 데이터 과학은 문제 해결을 위한 최선의 솔루션을 만드는 데 초점을 맞춘다면, 데이터 분석은 올바른 의사 결정을 돕기 위한 통찰을 제공하는 데 초점을 맞추고 있다.

이 책에서는 데이터 분석의 의미와 더불어 데이터 분석을 하는 데이터 분석가에 대해 상세하게 설명해주고 있다. 데이터 과학자, 데이터 분석가, 통계학자, 프로그래머 등 여러 이름 사이에서 데이터 분석가의 역할과 역량에 대해 더 자세히 알고 싶다면 책의 1장을 참고해 보길 바란다.

데이터 분석은 아래와 같은 순서를 거쳐 이루어진다.

1. 데이터 수집 단계에서는 공개된 데이터 셋을 다운로드하여 사용하거나 API를 통해 데이터를 얻는 방법, 웹 스크래핑을 통해 올바른 데이터를 수집하는 방법을 알려준다.

2. 데이터 정제 단계에서는 수집된 데이터에 문제가 없는지 확인하고, 분석 결과를 왜곡시키지 않도록 올바르게 정제하는 방법을 알려준다. 대부분 가장 많은 시간이 소요되는 단계이기도 하며, 그만큼 번거롭기도 하고 중요하기도 한 데이터 정제에 대해 공부할 수 있다.

3. 데이터 요약 및 시각화 단계는 준비된 데이터로부터 분석 결과를 도출하고, 미래를 예측하는 단계이다. 그만큼 중요하고 어려운 부분이다. 이 책에서 모든 통계 이론과 시각화 방법을 다루지는 않지만, 데이터로부터 원하던 답을 도출해 나가는 과정을 혼자서도 이해하기 쉽도록 잘 설명해주고 있다.

이 책에서는 구글 코랩에서 파이썬을 사용하여 대부분의 분석을 연습한다. 특히 데이터 분석에 대표적으로 사용하는 파이썬 패키지인 NumPy, Pandas, Matplotlib, SciPy, scikit-learn 등을 주로 사용한다. '혼자 공부하는'이라는 제목처럼 혼자 공부하면서 어렵지 않도록 설명이 자세해서 약 500쪽 가까이 되는 분량에도 공부하는데 부담이 덜했다.

'혼자 공부하는' 시리즈는 한빛미디어에서 <혼공학습단>이라는 스터디 교재로 사용하고 있다. <혼공학습단>은 6주 동안 매주 정해진 분량을 혼자 공부하고 인증하는 방식으로 운영되는데 오롯이 혼자 공부하는 것보다 훨씬 공부가 잘 된다. 교재의 뛰어남보다도 이런 프로그램을 활용할 수 있다는 점이 이 책의 좋은 점인 것 같다.

이 책으로 공부하면서 도움이 될 실습 예제와 용어 노트, 동영상 강의와 질문을 할 수 있는 사이트가 있어 첨부해 두었다.

> 혼자 공부하는 데이터 분석 with 파이썬

[컴퓨터구조] Ch04. CPU의 작동 원리

TEKI — Mon, 6 Feb 2023 21:01:33 +0900

컴퓨터의 네 가지 핵심 부품 중 CPU에 대하여.

ALU와 제어장치, 그리고 레지스터
명령어 사이클
인터럽트

1. ALU와 제어장치, 그리고 레지스터

CPU 내부에 있는 구성 요소 3가지

계산을 담당하는 ALU
명령어를 읽어 들이고 해석하는 제어장치
작은 임시 저장 장치인 레지스터

[1] ALU

◈ 플래그

연산 결과에 대한 추가적인 상태 정보로, 플래그 레지스터에 저장됨
ALU가 내보내는 대표적인 플래그에는 부호 플래그, 제로 플래그, 캐리 플래그, 오버플로우 플래그, 인터럽트 플래그, 슈퍼바이저 플래그, 등이 있음

[2] 제어장치

제어장치: 제어 신호를 내보내고, 명령어를 해석하는 부품
제어 신호: 컴퓨터 부품들을 관리하고 작동시키기 위한 일종의 전기 신호

[3] 레지스터

많은 CPU가 공통으로 포함하고 있는 8개의 레지스터와 그 역할

◈ 프로그램 카운터 (PC: Program Counter) 또는 명령어 포인터 (IP: Instruction Pointer)
: 메모리에서 가져올 명령어의 주소, 즉 메모리에서 읽어 들일 명령어의 주소를 저장

◈ 명령어 레지스터 (IR: Instruction Register)
: 해석할 명령어, 즉 방금 메모리에서 읽어 들인 명령어를 저장하는 레지스터

◈ 메모리 주소 레지스터 (MAR: Memory Address Register)
: 메모리의 주소를 저장하는 레지스터

◈ 메모리 버퍼 레지스터 (MBR: Memory Buffer Register)
: 메모리와 주고받을 값(데이터와 명령어)을 저장하는 레지스터

◈ 플래그 레지스터 (Flag Register)
: ALU 연산 결과 또는 CPU 상태에 대한 부가적인 정보를 저장하는 레지스터

◈ 범용 레지스터 (General Purpose Register)
: 다양하고 일반적인 상황에서 자유롭게 사용할 수 있는 레지스터로, 현대 대다수 CPU에는 모두 범용 레지스터가 있으며 일반적으로 CPU 안에 여러 개의 범용 레지스터를 가지고 있다.

◈ 스택 포인터 (Stack Pointer)
: 스택의 꼭대기를 가리키는 레지스터로 스택 주소 지정 방식에 사용됨

*스택 주소 지정 방식: 스택과 스택 포인터를 이용한 주소 지정 방식

◈ 베이스 레지스터 (Base Register)
: 베이스 레지스터 주소 지정 방식에서 기준 주소의 역할을 하는 레지스터

*베이스 레지스터 주소 지정 방식(base-register addressing mode): 변위 주소 지정 방식 중에서 오퍼랜드와 베이스 레지스터의 값을 더하여 유효 주소를 얻는 방식

*변위 주소 지정 방식(displacement addressing mode): 오퍼랜드 필드의 값(변위)과 특정 레지스터의 값을 더하여 유효 주소를 얻어내는 주소 지정 방식

2. 명령어 사이클

프로그램은 수많은 명령어를 CPU에게 시키면서 실행된다. 이때 프로그램 속 명령어들은 명령어 사이클이라고 하는 일정한 주기에 따라 반복되면서 실행된다. 예를 들어 메모리에 저장된 명령어를 가져와 실행할 때 명령어를 메모리에서 CPU로 가져오는 인출 사이클, 가져온 명령어를 실행하는 실행 사이클, 명령어 실행을 위해 한 번 더 메모리 접근을 하는 간접 사이클 등이 있다.

3. 인터럽트

CPU의 작업을 방해하는 신호를 인터럽트(Interrupt)라고 한다.
인터럽트에는 크게 동기 인터럽트와 비동기 인터럽트가 있다.

◈ 동기 인터럽트 (Synchronous Interrupts) 또는 예외(Exception)

동기 인터럽트는 CPU에 의해 발생하는 인터럽트로, CPU가 실행하는 프로그래밍상의 오류와 같은 상황을 말한다. '예외'라고도 부른다.

◈ 비동기 인터럽트 (Asynchronous Interrupt) 또는 하드웨어 인터럽트 (Hardware Interrupt)

비동기 인터럽트는 주로 입출력장치에 의해 발생하는 인터럽트로, 아래와 같은 케이스가 해당된다

명령받은 입출력 작업을 끝낸 입출력장치가 CPU에 완료를 알리기 위한 신호
입출력장치가 입력을 받아들였을 때 이를 처리하기 위해 CPU에 보내는 입력 알림

CPU가 인터럽트 요청을 수용하려면 플래그 레지스터의 인터럽트 플래그(Interrupt Flag)가 활성화되어 있어야 한다.
만약 인터럽트 플래그가 '불가능'으로 설정되어 있다면 CPU는 인터럽트 요청이 오더라도 무시한다.
만약 인터럽트 플래그가 '가능'으로 설정되어 있다면 CPU는 인터럽트 요청 신호를 받아들이고, 인터럽트를 처리한다.

하드웨어 인터럽트에는 인터럽트 플래그로 막을 수 있는 인터럽트(Maskable Interrupt)와 막을 수 없는 인터럽트(Non Maskable Interrupt)가 있다.

[혼공학습단 9기] 혼공컴운 4주차 미션

TEKI — Sun, 5 Feb 2023 21:23:10 +0900

4주 차 미션!

[미션 1] p. 304의 확인 문제 1번 풀고 인증하기

[미션 2] Ch.11(11-2) 준비 큐에 A, B, C, D 순으로 삽입되었다고 가정했을 때, 선입 선처리 스케줄링 알고리즘을 적용하면 어떤 프로세스 순서대로 CPU를 할당받는지 풀어보기

선입 선처리 스케줄링 알고리즘은 먼저 들어온 프로세스에 먼저 할당하는 방식으로, A-B-C-D 순으로 삽입되면 A-B-C-D 순으로 CPU를 할당받는다.

공부한 내용

Chapter 09 운영체제 시작하기
→ [운영체제] Ch09. 운영체제 이해하기
Chapter 10 프로세스와 스레드
→ [운영체제] Ch10. 프로세스와 스레드, 멀티프로세스와 멀티스레드
Chapter 11 CPU 스케줄링
→ [운영체제] Ch11. CPU 스케줄링

[컴퓨터구조] Ch03. 프로그래밍 언어와 컴퓨터 명령어

TEKI — Sun, 5 Feb 2023 21:07:37 +0900

고급 언어와 저급 언어
컴파일 언어와 인터프리터 언어
연산 코드와 오퍼랜드
명령어의 주소 지정 방식

1. 고급 언어와 저급 언어

고급 언어(High-Level Programming Language) : 사람이 이해하고 작성하기 쉽게 만들어진 언어
저급 언어(Low-Level Programming Language) : 컴퓨터가 직접 이해하고 실행할 수 있는 언어

"고급 언어로 작성된 소스 코드가 실행되려면 저급 언어, 즉 명령어로 변환되어야 한다."

◈ Low-Level Programming Language - 기계어와 어셈블리어

기계어 : 명령어 비트(0과 1)로 이루어진 언어
어셈블리어 : 기계어를 읽기 편한 형태로 번역한 언어

2. 컴파일 언어와 인터프리터 언어

컴파일 언어 : 컴파일 방식 즉, 컴파일러에 의해 소스 코드가 통째로 저급 언어로 변환되어 실행되는 프로그래밍 언어
인터프리터 언어 : 인터프리트 방식 즉, 인터프리터에 의해 소스 코드가 한 줄씩 실행되는 프로그래밍 언어

" 컴파일 언어는 일반적으로 인터프리터 언어에 비해 빠르다. "
" 인터프리터 언어는 소스 코드 내에 오류가 있어도 그 직전 코드까지는 올바르게 수행한다. "
" 하나의 언어가 반드시 컴파일 방식 또는 인터프리트 방식 둘 중 하나로만 작동하는 것은 아니다. "

3. 연산 코드와 오퍼랜드

연산 코드는 '명령어가 수행할 연산'을 의미하고, 오퍼랜드는 '연산에 사용할 데이터'를 의미한다.
예를 들어 '100과 120을 더해라'라는 명령어에서 '더해라'는 연산 코드, '100'와 '120'은 오퍼랜드이다.

◈ 대표적인 연산 코드의 종류 1. 데이터 전송

MOVE : 데이터를 옮겨라
STORE : 메모리에 저장하라
LOAD(FETCH) : 메모리에서 CPU로 데이터를 가져와라
PUSH : 스택에 데이터를 저장하라
POP : 스택의 최상단 데이터를 가져와라

◈ 대표적인 연산 코드의 종류 2. 산술/논리 연산

ADD / SUBTRACT / MULTIPLY / DIVIDE : 덧셈/뺄셈/곱셈/나눗셈을 수행하라
INCREMENT / DECREMENT : 오퍼랜드에 1을 더하라/빼라
AND / OR / NOT
COMPARE : 두 개의 숫자 또는 TRUE/FALSE 값을 비교하라

◈ 대표적인 연산 코드의 종류 3. 제어 흐름 변경

JUMP : 특정 주소로 실행 순서를 옮겨라
CONDITIONAL JUMP : 조건에 부합할 때 특정 주소로 실행 순서를 옮겨라
HALT : 프로그램의 실행을 멈춰라
CALL : 되돌아올 주소를 저장한 채 특정 주소로 실행 순서를 옮겨라
RETURN : CALL을 호출할 때 저장했던 주소로 돌아가라

◈ 대표적인 연산 코드의 종류 4. 입출력 제어

READ(INPUT) : 특정 입출력 장치로부터 데이터를 읽어라
WRITE(OUTPUT) : 특정 입출력 장치로 데이터를 써라
START IO : 입출력 장치를 시작하라
TEST IO : 입출력 장치의 상태를 확인하라

4. 명령어의 주소 지정 방식

n 비트 길이의 명령어에서 연산 코드 필드가 m 비트라면 오퍼랜드 필드에는 최대 (n - m) 비트만큼만 할당할 수 있다.
만약 오퍼랜드 필드 안에 메모리 주소가 담긴다면, 표현할 수 있는 데이터의 크기는 더 커질 수 있다.
또는 오퍼랜드 필드에 메모리 주소가 아닌 레지스터 이름을 명시하더라도 마찬가지이다.

연산의 대상이 되는 데이터가 저장된 위치를 유효 주소라고 한다.
이렇게 오퍼랜드 필드에 데이터가 저장된 위치를 명시할 때, 유효 주소를 찾는 방법을 주소 지정 방식(addressing mode)라고 한다.

◈ 대표적인 주소 지정 방식 1. 즉시 주소 지정 방식

연산에 사용할 데이터를 오퍼랜드 필드에 직접 명시하는 가장 간단한 형태의 주소 지정 방식
표현할 수 있는 데이터의 크기가 작아짐
연산에 사용할 데이터를 메모리나 레지스터로부터 찾는 과정이 없기 때문에 다른 주소 지정 방식들보다 빠름
오퍼랜드 필드에 명시하는 값: 연산에 사용할 데이터

◈ 대표적인 주소 지정 방식 2. 직접 주소 지정 방식

오퍼랜드 필드에 유효 주소를 직접적으로 명시하는 방식
오퍼랜드 필드에서 표현할 수 있는 데이터의 크기가 즉시 주소 지정 방식보다 커짐
유효 주소를 표현할 수 있는 범위가 연산 코드의 비트 수만큼 감소
오퍼랜드 필드에 명시하는 값: 유효 주소(메모리 주소)

◈ 대표적인 주소 지정 방식 3. 간접 주소 지정 방식

유효 주소의 주소를 오퍼랜드 필드에 명시하는 방식
직접 주소 지정 방식보다 표현할 수 있는 유효 주소의 범위가 더 넓어짐
두 번의 메모리 접근이 필요하여 즉시 주소 지정 방식이나 직접 주소 지정 방식보다 느림
오퍼랜드 필드에 명시하는 값: 유효 주소의 주소

◈ 대표적인 주소 지정 방식 4. 레지스터 주소 지정 방식

직접 주소 지정 방식과 유사하게 연산에 사용할 데이터를 저장한 레지스터를 오퍼랜드 필드에 직접 명시하는 방식
메모리(CPU 외부에 있음)보다 레지스터(CPU 내부에 있음)에 접근하는 것이 빠르므로 직접 주소 지정 방식보다 빠름
표현할 수 있는 레지스터 크기에 제한이 생길 수 있다
오퍼랜드 필드에 명시하는 값: 유효 주소(레지스터 이름)

◈ 대표적인 주소 지정 방식 5. 레지스터 간접 주소 지정 방식

연산에 사용할 데이터를 메모리에 저장하고, 그 주소(유효 주소)를 저장한 레지스터를 오퍼랜드 필드에 명시하는 방법
유효 주소를 찾는 과정이 간접 주소 지정 방식과 유사하지만, 메모리에 접근하는 횟수가 한 번으로 줄어 더 빠름
오퍼랜드 필드에 명시하는 값: 유효 주소를 저장한 레지스터

[컴퓨터구조] Ch02. 0과 1, 데이터를 표현하는 방법

TEKI — Sun, 5 Feb 2023 07:50:36 +0900

우리가 알아야 할 컴퓨터 구조 지식 두 가지

컴퓨터가 이해하는 정보의 단위
이진법, 십진법, 십육진법
컴퓨터의 네 가지 핵심 부품: CPU, 메모리, 보조기억장치, 입출력장치

1. 컴퓨터가 이해하는 정보의 단위

컴퓨터의 언어, 0과 1
컴퓨터가 이해하는 가장 작은 정보 단위는 0 또는 1을 나타내는 정보이며, 이를 비트(bit)라고 한다.

◈ 정보의 크기에 따라 표현 가능한 정보의 종류는 달라진다.
→ N비트 정보는 2^N가지 정보를 표현할 수 있다.

1비트 : (0) or (1)
2비트 : (0, 0) or (0, 1) or (1, 0) or (1, 1)
3비트 : (0, 0, 0) or (0, 0, 1) or (0, 1, 0) or (0, 1, 1) or (1, 0, 0) or (1, 0, 1) or (1, 1, 0) or (1, 1, 1)

◈ 정보의 크기가 아주 크면 새로운 단위를 사용한다.

2. 이진법, 십진법, 십육진법

0과 1로 숫자를 표현하는 방법을 이진법이라고 하며, 0부터 9까지 총 10개 숫자로 모든 수를 표현하는 방법을 십진법, 그리고 0부터 9까지에 A부터 F까지를 포함해 총 16개 숫자와 문자로 숫자를 표현하는 방법을 십육진법이라고 한다.

→ 이진수는 숫자 뒤에 아래첨자₍₂₎를 붙이거나 숫자 앞에 0b를 붙여 구분한다. (주로 전자는 수학적 표현으로, 후자는 코드상에서 사용함)
→ 십육진수는 숫자 뒤에 아래첨자₍₁₆₎를 붙이거나 숫자 앞에 0x를 붙여 구분한다. (주로 전자는 수학적 표현으로, 후자는 코드상에서 사용함)

◈ 1의 보수, 2의 보수, 부호 절댓값

-1을 이진수로 표현한다면? 컴퓨터는 0과 1만 이해하므로 -1을 이해할 수 없다.
따라서 음수인 이진수를 표현하는 여러가지 방법이 있다. (출처&더 자세한 설명)

① 1의 보수 표현법 (One's Complement)
보수는 '보충해주는 수'라는 뜻으로, 여기에서는 '어떤 수를 만들기 위해 필요한 수'라는 의미로 사용된다.
다시 말하면 'N의 보수'는 '어떤 수에 대해 N의 제곱수가 되도록 만드는 수'이다.
예를 들어, 10진법에서 3에 대한 10의 보수는 '3에서 10을 만들기 위해 필요한 수'라는 의미, 즉 7을 말한다.

모든 N진법에는 ①N의 보수 표현법과 ②N-1의 보수 표현법 두 가지가 쓰인다.
N진법에서의 N-1의 보수는 (N의 보수 - 1)이 된다.
예를 들어, 10진법에서 9의 보수는 10의 보수 - 1이다. 즉 17에 대한 10의 보수는 83이므로, 17에 대한 9의 보수는 83 - 1인 82가 된다.

② 2의 보수 표현법 (Two's Complement)
음수인 이진수를 표현하는 방법 중 가장 널리 사용되는 방법으로, 2의 보수를 구해 이 값을 음수로 간주하는 방법이다.

③ 부호 절대값 (Sign-Magnitube)
최상위 비트(가장 왼쪽의 비트)를 이용해 부호를 표시하는 방법.
즉, 비트가 0일 때는 양수, 1일 때는 음수라고 약속하여 양수와 음수를 구별하는 방법.
이 때, 최상위 비트를 MSB(Most Significant Bit)라고 함.

[양수] 5(2) = 0000 0000 0000 0000 0000 0000 0000 0101(2)
[음수] -5(2) = 1000 0000 0000 0000 0000 0000 0000 0101(2)

이렇게 표현할 경우, 컴퓨터 입장에서는 연산하기 위해 고려해야 하는 정보가 많다는 단점이 있다.

3. 컴퓨터의 네 가지 핵심 부품: CPU, 메모리, 보조기억장치, 입출력장치

[1] 주기억장치 (Main Memory)

: 현재 실행되는 프로그램의 데이터와 명령어를 저장하는 부품.
가격이 비싸 저장 용량이 작고, 전원이 꺼지면 저장된 내용을 잃어버린다는 단점이 있다.

프로그램이 실행되려면 반드시 메모리에 저장되어 있어야 한다.
데이터와 명령어는 '주소'라는 개념을 사용해 메모리에 저장된 값에 빠르고 효율적으로 접근한다.

주기억장치(메인메모리)에는 크게 RAM(Random Access Memory)와 ROM(Read Only Memory)가 존재
*이 책에서 언급하는 '주기억장치' 또는 '메모리'는 RAM을 의미

[2] 중앙처리장치 (CPU: Central Processing Unit)

: 컴퓨터의 두뇌로, 메모리에 저장된 명령어를 읽어 들이고, 해석하고, 실행하는 부품.

CPU 내부 구성 요소 중 가장 중요한 세 가지

① 산술논리연산장치 (ALU: Arithmetic Logic Unit)
: 계산을 도맡아 수행하는 부품

② 레지스터 (Register)
: 프로그램을 실행하는데 필요한 값들을 임시로 저장하는 장치로, 하나의 CPU에 각기 다른 이름과 역할을 가진 레지스터가 여럿 존재

③ 제어장치 (CU: Control Unit)
:제어 신호(Control Signal)를 내보내고 명령어를 해석하는 장치

[3] 보조기억장치 (Secondary Storage)

: 메인메모리의 단점을 보완하는 저장 용량이 크고, 전원이 꺼져도 내용을 잃지 않는 보조 메모리
예) 하드 디스크, SSD, USB 메모리, DVD, CD-ROM과 같은 저장 장치

"메모리가 현재 실행중인 프로그램을 저장한다면, 보조기억장치는 보관할 프로그램을 저장"

[4] 입출력장치 (I/O Device: Input/Output Device)

: 마이크, 스피커, 프린터, 마우스, 키보드처럼 컴퓨터 외부에 연결되어 컴퓨터 내부와 정보를 교환하는 장치

[5] 메인보드와 시스템 버스

컴퓨터의 핵심 부품은 모두 메인보드(Main Board) 또는 마더보드(Mother Board)라고 부르는 판에 연결된다.

메인보드에 연결된 부품은 버스(Bus)라는 통로를 통해 서로 정보를 주고받으며, 이 중 핵심 부품이 정보를 주고받는 통로는 시스템 버스(System Bus)라고 한다.

시스템 버스는 아래와 같이 세 가지 버스로 구성되어 있다.

주소 버스(Address Bus): 주소를 주고받는 통로
데이터 버스(Data Bus): 명령어와 데이터를 주고받는 통로
제어 버스(Control Bus): 제어 신호를 주고받는 통로

[혼공학습단 9기] 혼공컴운 3주차 미션

TEKI — Sat, 4 Feb 2023 21:04:38 +0900

3주 차 미션!

[미션 1] p. 185의 확인 문제 3번 풀고 인증하기

· 주로 캐시 메모리로 활용됩니다. ( SRAM )
· 주로 주기억장치로 활용됩니다. ( DRAM )
· 대용량화하기 유리합니다. ( DRAM )
· 집적도가 상대적으로 낮습니다. ( SRAM )

주 기억장치의 하나인 RAM에는 DRAM, SRAM, SDRAM, DDR SDRAM 등이 있다.

(1) DRAM은 Dynamic RAM의 준말로, 시간이 지나면 저장된 데이터가 점차 사라지는 특징이 있다. 대신 소비 전력이 비교적 낮고, 저렴하고, 집적도가 높아 대용량 설계가 용이하다는 장점이 있다.

(2) SRAM은 Static RAM의 준말로, 시간이 지나도 저장된 데이터가 사라지지 않는다는 점에서 DRAM과 차이가 있으며, 속도가 빠르다는 장점이 있다. 대신 소비 전력이 크고, 비싸고, 집적도가 낮아 대용량이 아니더라도 속도가 빨라야 하는 저장 장치(ex: cache)에서 사용된다.

(3) SDRAM은 Synchronous Dynamic RAM의 준말로, 클럭 신호와 동기화된, 발전된 형태의 DRAM이다. 즉, 클럭 타이밍에 맞춰 CPU와 정보를 주고받을 수 있는 DRAM이다.

(4) DDR SDRAM은 Double Data Rate SDRAM은 가장 흔히 사용되는 RAM으로, 대역폭을 SDRAM보다 두 배 넓혀 속도를 빠르게 만든 SDRAM이다. 즉, 한 클럭에 두 배 많은 데이터를 전송할 수 있다. DDR2 SDRAM은 DDR SDRAM의 두 배, DDR3 SDRAM은 DDR2 SDRAM의 두 배 대역폭을 가진다. 최근 흔히 사용하는 메모리는 DDR4 SDRAM으로 SDRAM의 16배 넓은 대역폭을 가진다.

[미션 2] p. 205의 확인 문제 1번 풀고 인증하기

[미션 3] Ch. 07(07-1) RAID의 정의와 종류를 간단히 정리해 보기

RAID(Redundant Array of Independent Disks)는 데이터의 안전성 혹은 높은 성능을 위해 여러 개의 물리적 보조기억장치를 마치 하나의 논리적 보조기억장치처럼 사용하는 기술로, 주로 하드 디스크와 SSD를 사용한다.

RAID에는 대표적으로 RAID 0, RAID 1, RAID 2, RAID 3, RAID 4, RAID 5, RAID 6이 있고, 그로부터 파생된 RAID 10, RAID 50 등이 있다. 이 중 RAID 2와 RAID 3은 현재 잘 활용되지 않고, RAID 0, RAID 1, RAID 4, RAID 5, RAID 6이 가장 대중적이다.

RAID 0 : 가장 단순하게 여러 개의 물리적 보조기억장치에 나누어 저장하는 방식
· 장점 : 4TB과 1TB 4개(RAID 0)를 비교하면 RAID 0 방식이 이론적으로 약 4배가량 빠르다.
· 단점 : 한 보조기억장치에 문제가 생기면 다른 보조기억장치의 정보를 읽는 데 문제가 생길 수 있다.

RAID 1 : 원본에 더해 거울처럼 완전한 복사본을 만드는 방식으로, 미러링이라고도 한다.
· 장점: 복구가 매우 간단하다.
· 단점: 쓰기 속도가 RAID 0에 비해 느리고, 사용 가능한 용량이 적다.

RAID 4 : 원본에 더해 오류를 검출하고 복구하기 위한 정보를 저장하는 장치를 두는 방식으로, '오류를 검출하고 복구하기 위한 정보'를 패리티 비트라고 한다.
· 장점 : RAID 1보다 적은 저장 장치로도 데이터를 안전하게 보관할 수 있다.
· 단점 : 새로운 데이터를 저장할 때마다 패리티를 저장하는 장치에 데이터를 쓰면서 병목 현상이 발생한다.

RAID 5 : RAID 4와 유사하나 패리티 정보를 분산하여 저장해서 병목 문제를 해결했다는 차이가 있다.
· 장점: RAID 1보다 적은 저장 장치로도 데이터를 안전하게 보관할 수 있고, RAID 4의 병목 문제가 없다.

RAID 6 : 기본적으로 RAID 5와 유사한 구성이나 서로 다른 두 개의 패리티를 생성한다는 점에서 차이가 있다.
· 장점 : RAID 5보다 안전하다.
· 단점 : 쓰기 속도가 RAID 5보다 느리다.

공부한 내용 (작성중)

Chapter 06 메모리와 캐시 메모리
→ [컴퓨터구조] Ch06. RAM과 캐시메모리, 그리고 주소공간
Chapter 07 보조기억장치
→ [컴퓨터구조] Ch07. 다양한 보조기억장치와 RAID의 종류
Chapter 08 입출력장치
→ [컴퓨터구조] Ch08. 입출력장치와 입출력 방법

[혼공학습단 9기] 혼공컴운 2주차 미션

TEKI — Sun, 15 Jan 2023 00:50:47 +0900

2주 차 미션!

[미션 1] p. 125의 확인 문제 2번 풀고 인증하기

· ( 플래그 레지스터 ) : 연산 결과 혹은 CPU 상태에 대한 부가 정보를 저장하는 레지스터
· ( 프로그램 카운터 ) : 메모리에 가져올 명령어의 주소를 저장하는 레지스터
· ( 범용 레지스터 ) : 데이터와 주소를 모두 저장할 수 있는 레지스터
· ( 명령어 레지스터 ) : 해석할 명령어를 저장하는 레지스터

메모리 주소 레지스터 : 메모리의 주소를 저장하는 레지스터
메모리 버퍼 레지스터 : 메모리와 주고받을 데이터를 저장하는 레지스터
스택 포인터 : 스택 최상단의 위치를 저장
베이스 레지스터 : 기준 주소로서의 역할을 하는 주소를 저장하는 레지스터

[미션 2] p. 155의 확인 문제 4번 풀고 인증하기

[미션 3] Ch.05(05-1) 코어와 스레드, 멀티 코어와 멀티 스레드의 개념을 정리하기

'코어'는 CPU 내에서 ALU, 제어장치, 레지스터 등을 포함하는 물리적 장치로, CPU 안에 하나 또는 둘 이상이 존재할 수 있다. 하나의 CPU에 둘 이상의 코어가 존재하는 경우, 이를 '멀티 코어'라고 한다.

'멀티 스레드'에는 하드웨어적 스레드와 소프트웨어적 스레드가 있는데, 하드웨어적으로는 하나의 코어가 둘 이상의 명령어를 동시에 처리하는 것을 의미하고, 소프트웨어적으로는 하나의 프로그램에서 독립적으로 실행되는 스레드가 둘 이상인 것을 의미한다.

공부한 내용

Chapter 04 CPU의 작동 원리
→ [컴퓨터구조] Ch04. CPU의 작동 원리
Chapter 05 CPU 성능 향상 기법
→ [컴퓨터구조] Ch05. CPU 제대로 쓰기

[컴퓨터구조] Ch01. 컴퓨터 구조

TEKI — Fri, 13 Jan 2023 00:19:20 +0900

우리가 알아야 할 컴퓨터 구조 지식 두 가지

컴퓨터가 이해하는 정보: 데이터와 명령어
컴퓨터의 네 가지 핵심 부품: CPU, 메모리, 보조기억장치, 입출력장치

1. 컴퓨터가 이해하는 정보

컴퓨터의 언어, 0과 1
0과 1로 표현하는 정보 두 가지: 데이터와 명령어

데이터: 숫자, 문자, 이미지, 동영상과 같은 정적인 정보
명령어: 데이터를 움직이고 컴퓨터를 작동시키는 정보

2. 컴퓨터의 네 가지 핵심 부품

컴퓨터는 주기억장치, CPU, 보조기억장치, 입출력장치 등 네 가지 핵심 부품과 이를 연결하는 메인보드 (또는 마더보드), 그리고 메인보드 내에서 정보를 주고받는 데 사용되는 시스템 버스로 이루어져 있다.

출처: https://medium.com/@mitteam2021/computer-motherboard-and-its-components-8606f10dc08f

[1] 주기억장치 (Main Memory)

프로그램이 실행되려면 반드시 메모리에 저장되어 있어야 한다.
데이터와 명령어는 '주소'라는 개념을 사용해 메모리에 저장된 값에 빠르고 효율적으로 접근한다.

주기억장치(메인메모리)에는 크게 RAM(Random Access Memory)와 ROM(Read Only Memory)가 존재
*이 책에서 언급하는 '주기억장치' 또는 '메모리'는 RAM을 의미

[2] 중앙처리장치 (CPU: Central Processing Unit)

: 컴퓨터의 두뇌로, 메모리에 저장된 명령어를 읽어 들이고, 해석하고, 실행하는 부품.

CPU 내부 구성 요소 중 가장 중요한 세 가지

① 산술논리연산장치 (ALU: Arithmetic Logic Unit)
: 계산을 도맡아 수행하는 부품

③ 제어장치 (CU: Control Unit)
:제어 신호(Control Signal)를 내보내고 명령어를 해석하는 장치

[3] 보조기억장치 (Secondary Storage)

"메모리가 현재 실행중인 프로그램을 저장한다면, 보조기억장치는 보관할 프로그램을 저장"

[4] 입출력장치 (I/O Device: Input/Output Device)

: 마이크, 스피커, 프린터, 마우스, 키보드처럼 컴퓨터 외부에 연결되어 컴퓨터 내부와 정보를 교환하는 장치

[5] 메인보드와 시스템 버스

컴퓨터의 핵심 부품은 모두 메인보드(Main Board) 또는 마더보드(Mother Board)라고 부르는 판에 연결된다.

시스템 버스는 아래와 같이 세 가지 버스로 구성되어 있다.

주소 버스(Address Bus): 주소를 주고받는 통로
데이터 버스(Data Bus): 명령어와 데이터를 주고받는 통로
제어 버스(Control Bus): 제어 신호를 주고받는 통로

[혼공학습단 9기] 혼공컴운 1주차 미션

TEKI — Sun, 8 Jan 2023 00:09:13 +0900

1주 차 미션!

[미션 1] p. 51의 확인 문제 3번 풀고 인증하기

"프로그램이 실행되려면 반드시 메모리에 저장되어 있어야 합니다."

컴퓨터가 이해하는 정보는 명령어와 데이터이며, 메모리는 현재 실행되는 프로그램의 명령어와 데이터를 저장하는 부품이다. 메모리에는 RAM(Random Access Memory)와 ROM(Read Only Memory)가 있으며, 보통 메모리라는 용어를 사용할 땐 RAM을 지칭한다.

[미션 2] p. 65의 확인 문제 3번 풀고 인증하기

1101₍₂₎의 음수를 2의 보수 표현법으로 바꾸어 표현하면 0011₍₂₎이다.

2의 보수의 사전적 의미는 '어떤 수를 그보다 큰 2ⁿ에서 뺀 값'이다. 이 값을 구하는 쉬운 방법은 모든 0과 1을 뒤집고, 거기에 1을 더하여 그 결과를 얻는 것이다. 이 방법으로 1101₍₂₎의 2의 보수는 1101₍₂₎ → 0010₍₂₎ → 0011₍₂₎ 와 같이 구할 수 있다.

[미션 3] p. 100의 스택과 큐의 개념을 정리하기

스택과 큐는 데이터를 저장하는 방법과 관련한 개념으로, 자료를 넣고 빼는 순서에 따라 나뉜다. 스택은 LIFO(Last In First Out) 자료 구조로, 데이터를 저장한 순서와 정반대로 데이터를 빼낸다. 큐는 FIFO(First In First Out) 자료 구조로, 데이터를 저장한 순서대로 데이터를 빼낸다.

공부한 내용

Chapter 01 컴퓨터 구조 시작하기
→ [컴퓨터구조] Ch01. 컴퓨터 구조
Chapter 02 데이터
→ [컴퓨터구조] Ch02. 0과 1, 데이터를 표현하는 방법
Chapter 03 명령어
→ [컴퓨터구조] Ch03. 프로그래밍 언어와 컴퓨터 명령어

[혼공학습단 9기] 2023년 시작하기

TEKI — Wed, 4 Jan 2023 22:39:25 +0900

혼공학습단 9기에서는 11개 도서 중 하나를 선택해서 공부할 수 있다. 대상 도서는 한빛미디어의 <혼자 공부하는> 시리즈로 프로그래밍 언어를 공부하는 도서 5권과 데이터 분석 및 머신러닝 관련 도서 3권, 그리고 코딩과 컴퓨터의 기초 관련 도서 3권이 있다.

혼자 공부하는 C언어
혼자 공부하는 자바
혼자 공부하는 파이썬
혼자 공부하는 자바 스크립트
혼자 공부하는 SQL
혼자 공부하는 머신러닝+딥러닝
혼자 공부하는 R 데이터분석
혼자 공부하는 데이터 분석
혼자 공부하는 첫 프로그래밍
혼자 공부하는 얄팍한 코딩 지식
혼자 공부하는 컴퓨터구조+운영체제

이 중에서 혼자 공부하는 컴퓨터구조+운영체제를 선택했는데, 기초부터 다시 공부하면서 초심을 되찾고 싶었다. 사실 컴퓨터 구조는 전부터 어려워하던 과목이어서 버벅대지는 않을까 조금 걱정이 된다..

혼공학습단 9기는 정말 새해를 시작하기에 딱 좋은 일정으로 진행된다. 3주 차까지 진행한 다음에 설 연휴로 한 주를 쉬어가기 때문에 부담이 덜하다.

매주 정해진 커리큘럼을 일주일간 공부한 후, 블로그에 정리한 내용을 올려준 다음 페이스북 그룹에 공유해주면 된다.

리워드도 있다. 책 한 권이 2~3만 원 정도인데 6주 과정을 마치면 한빛미디어의 도서를 구매할 수 있는 마일리지 20,000점을 주고, 그 외에도 상품이 있다. 9기 혼공족이 370여 명이라고 하는데 상품.. 받을 수 있을까?

비즈니스 데이터 과학 - 비즈니스 의사결정을 위한 통계학, 경제학, 인공지능의 만남

TEKI — Fri, 30 Dec 2022 17:33:13 +0900

비즈니스 데이터 과학 비즈니스 의사결정을 위한 통계학, 경제학, 인공지능의 만남
맷 태디 지음 | 이준용 옮김 | 한빛미디어 | 2022년 06월 29일 출간

이 책은

✔️ 예제에서 모든 분석은 R로 수행한다.
R뿐만 아니라 모든 목적에 있어 최적인 언어는 없다고 한다. 프로그래밍 언어를 하나만 배워서 컴퓨팅 기술을 온전히 사용할 수는 없다. 단, 저자는 데이터 과학을 배우는 데 가장 좋은 언어는 R이라고 한다. 분산 컴퓨팅 환경이나 구조화되지 않은 데이터 등에 접근하려면 파이썬, SQL 등 다른 언어가 필요하다는 한계는 있지만 그래도 R은 거의 모든 데이터 형식을 읽을 수 있다는 점에서 그렇다.

✔️ 수학, 프로그래밍, 비즈니스를 배운 다음 데이터 과학에서 필요한 내용을 가르쳐준다.
과학자, 비즈니스 전문가, 엔지니어 등 데이터 과학 기술을 습득하려는 사람들은 각자의 영역에서 수학, 프로그래밍, 비즈니스 등을 이미 배웠다. 이 책에서는 그다음 필요한 데이터 과학 기술을 가르쳐준다. 여기에는 다음의 개념들이 포함된다.

이미 알고 있는 것을 확률이라는 도구로 표현할 때 사용하는 불확실성
입력 또는 공변량 벡터(x)에 대한 함수로 반응 변수(y)를 모델링하거나 예측하는 회귀 모델링
표본 내(IS) 편차보다 중요한 표본 외(OOS) 편차를 고려한, 즉 모델이 새로운 데이터에 얼마나 맞는가를 고려한 고차원 모델 정규화
좋은 확률 모델을 통한 좋은 분류
현실에서 미래 예측을 위한 반사실적 분석과 실험 및 관찰 연구
지도 학습과 비지도 학습에서 차원 축소 방법과 효과 및 해석 방법
언어 토큰(문법적으로 의미 있는 최소 단위) 기반 텍스트 회귀, 텍스트의 주제 기반 토픽 모델링 등 NLP
선형 모델과 같이 모수(parameter)가 있고, 이 모수를 최적화하여 데이터에 모델을 적합하는 모수 분석과 회귀 알고리즘과 같이 x와 y의 관계에 대한 가정이 더 적은 비모수 분석, 그리고 가장 순수한 형태에서 더 많은 데이터를 관찰함으로써 x와 y의 진정한 관계를 학습하는 완전 비모수적 기술

✔️ 수학적이고 조금 어려운 내용이지만 실제 데이터 분석에 필요한 핵심 개념을 공부하고 싶다면 추천한다.
데이터 분석을 전공하지 않으면서 이를 공부하려면 편파적으로만 알기 쉽고, 또 깊이가 부족하다고 느껴지기도 한다. 사실 이 책은 디자인도, 책의 내용도 전공 도서 같은 느낌이어서 거부감이 들었었다. 하지만 하나하나 공부할수록 대충 이해만 하고 넘어갔거나 구글에서 얕게 공부했던 개념들이 새롭게 이해되는 느낌이 들어서 앞으로도 좀 더 이 책을 공부해보려고 한다.

이모티콘 만들기

TEKI — Sun, 27 Nov 2022 22:43:02 +0900

이모티콘은 아주 흔하고, 언제든 손이 닿을 듯 가까운 곳에 있다. 그래서 이모티콘으로 수익을 내보는 일 정도는 나도 해볼 만하다는 생각이 든다. 모두 같은 마음인지 지난해만 해도 이모티콘 제작 관련 도서가 매달 몇 권씩 나오고, 관련 강좌는 수십 개씩 쏟아져 나왔다.

쉽게 버는 돈은 없다. 쉬워 보이는 만큼 빠르게 레드오션이 된 이모티콘 시장에서 이모티콘 등록 승인받는 건 하늘의 별따기고, 등록 후에도 대중의 눈에 띄어 인기를 얻지 못하면 수익률이 이모티콘 제작에 들인 노력에 비해 턱없이 모자란다고 한다.

이런저런 말이 들려오지만 '그래도 나는 이모티콘을 만들고 싶어'라고 생각이 든다면 이미 수많은 자료를 찾아보고 있을 거라고 예상한다. 어느 정도 정보를 수집했다면, 롤모델을 정해 공부하는 것이 필요할 것이다. 이 책을 쓰신 분은 아래와 같이 주로 주인공 한 명의 표정과 액션, 그리고 짧은 멘트를 중심으로 한 이모티콘을 출시했다.

*2022년 11월 27일 기준 카카오톡 이모티콘 중 씨엠제이 작가 검색결과 247개 중 일부

만약 이런 이모티콘을 만들어보고 싶다면 이 책을 읽어보면 도움이 될 것 같다.

국내 최다 이모티콘 승인 작가 씨엠제이가 알려주는 승인율 99.9% 이모티콘 만들기
아이디어만 있으면 그림 못그려도 이모티콘 작가가 될 수 있다!
씨엠제이(최민정) 지음 | 한빛미디어 | 2022년 10월 10일 출간

이 책 한 권에 이모티콘 작가에 도전하기 위해 필요한 핵심 정보를 다 담으려 노력한 것 같다. 책의 앞부분에서는 카카오톡 이모티콘 외에 라인, 네이버OGQ마켓 등 이모티콘을 판매할 수 있는 다양한 플랫폼에 대해 작가 입장에서 등록 난이도와 수익률 등을 알려준다. 그리고 이모티콘을 출시하기까지 어떤 과정을 거쳐야 하고, 어떻게 준비하면 되는지 자세하게 알려준다. 이 부분에서 이모티콘 출시에 이렇게까지 많은 준비과정과 시간이 필요하다는 것을 처음 알게되었다.

그다음부터는 씨엠제이 작가님만의 팁이 더 많이 담겨있다.

독창적인 이모티콘 제작에 한 끗 차이를 만드는 사고방식은 어떤지
그림 하나로 여러마디 말을 대신하기 위해 어떤 감정표현 기법을 사용하는지
소품 사용, 소리와 모션 등을 이용해서 이모티콘의 아쉬운 2%를 채워주는 방법
시간에 따른 이모티콘의 판매량 변화를 파악하고 좀 더 높은 수익률을 만드는 팁
이모티콘 작가의 파일 정리 방법 노하우
승인받지 못한 이모티콘에 해볼 수 있는 심폐소생술

이 외에도 최다 이모티콘 등록 작가의 노하우가 많이 있어서 만약 캐릭터 중심의 이모티콘을 만들어보려는 예비작가라면 이 책에서 이모티콘 승인을 위한 팁을 다양하게 얻어갈 수 있을 것이다.

데이터로 전문가처럼 말하기 - 칼 올친

TEKI — Sun, 2 Oct 2022 08:48:21 +0900

데이터로 전문가처럼 말하기 효율적 의사 전달을 위한 데이터 시각화와 비즈니스 스토리텔링의 기술
칼 올친 지음 / 이한호 옮김 / 한빛미디어 / 2022년 8월 30일 출간

인턴 시절, 존경하던 사수는 수십 장 문서보다도 잘 그린 그림 하나가 중요하다고 가르쳐주셨었다. 엔지니어에게 글 쓰는 능력이 필요한 줄도 모르던 때였다. 그게 커뮤니케이션 스킬이고, 그 중에서도 아주 효율적인 방식을 알려주셨다는건 시간이 좀 더 지나서야 이해할 수 있었다.
이 책은 데이터 기반 커뮤니케이션에 대해 다루고 있다. 그렇기 때문에 이 책이 엔지니어를 위한 책이 아님에도 실무에 도움이 되었던 것 같다.
커뮤니케이션이 필요한 조직에 있다면, 정도는 달라도 분명 이 책에서 얻어가는 것이 있을 거라는 생각이 든다. 책의 뒷부분에서도 경영진, 재무팀, 인사팀, 운영팀, 마케팅팀, 영업팀, 그리고 IT팀까지 7개 조직에서 데이터를 기반으로 한 커뮤니케이션이 왜 필요한지, 그리고 어떻게 하면 효율적인 데이터 전달이 가능한지 얼려주고 있다.
경영진에게는 의사결정의 기초로 삼을 정보가 필요하다. 이 정보는 아주 정확하면서도 간단명료한 커뮤니케이션으로 신속하게 전달할 수 있어야 한다. 반면 재무팀에서는 정확한 정보를 자세히 살펴볼 수 있는 표 형태의 데이터를 원한다. 인사팀에서는 전체 데이터를 기반으로 집단의 평균, 최대, 최소 등 통계적 수치를 사용한다. 이와 동시에 민감한 개인정보를 안전하게 보호할 수 있는 범위 내에서 데이터를 활용하도록 노력을 기울인다. 또 운영팀에서는 조직 내에서 만들어지는 모든 데이터를 적절하게 수집하고 이해하면서 조직을 운영해나가는 것에 반해 마케팅팀에서는 인구 조사 보고서, 구글 애널리틱스, 소셜미디어 등 다양한 소스에서 대량의 데이터를 수집하고 축적하여 고객 및 잠재 고객의 프로필을 만드는 데에 활용한다. 영업팀은 각 고객의 과거와 현재의 기록을 기반으로 영업 진행 상황을 정확하게 분석하고 목표 대비 성과를 평가한다. 마지막으로 IT팀은 앞의 모든 부서에서 데이터를 활용하기 위해 꼭 필요하다.
이렇듯 거의 모든 조직에서 데이터를 원하고 있는데, 이들이 원하는 데이터의 모습에는 차이가 있다. 예를 들어, PR을 할 때에는 시각적 정보로 감각 기억(오감에 의해 1초 만에 얻어진 정보)을 이용해 순간적으로 공감을 얻어내야 한다. 반면, 파이 차트나 꺾은선 차트로 표현한 자료는 재무제표로 사용할 수 없다.
당연한 말이지만 그럼에도 불구하고 데이터 활용이 어려운 이유는 필요한 데이터의 모습이 늘 명확하지는 않기 때문이다. 이 책의 저자인 칼 올친은 어떤 상황에서든 가장 효과적인 데이터 전달 방식을 찾아내려면 세 가지를 알면 된다고 이야기한다.

1. 데이터를 받아들이는 방식을 이해해야 한다.

데이터를 전달하기 전에 데이터를 누가 필요로 하고, 왜 필요로 하는지 먼저 이해해야 한다. 그리고 이를 바탕으로 청자가 데이터를 어떻게 받아들일지 예상 가능한 상태에서 데이터를 전달할 수 있어야 한다. 그렇지 않으면 정보가 전혀 전달되지 않거나 잘못 전달될 수 있기 때문이다.

2. 데이터를 표현하는 방식을 이해해야 한다.

표에는 제목과 행과 열을 나누는 선, 그리고 정보를 담은 다양한 숫자와 글자들이 산재해 있다. 더 깊게 들여다보면 이들의 색상과 폰트, 글자 크기, 자간 등 다양한 디자인적 요소가 포함되어 있다. 또, 숫자를 콤마로 구분해서 표현(1,000,000)하거나 단위를 요약하여 표현(1M)하는 등 다양한 표현 방식을 활용하기도 한다.
또 그래프는 이보다 훨씬 다양한 디자인을 적용해서 시각적 효과를 이끌어낸다. 이 책은 반 이상의 분량을 이렇게 다양한 데이터 표현 방식을 설명하는 데에 할애한다. 그리고 사람의 기억을 감각 기억(오감에 의해 1초 이내로 얻어진 정보), 단기 기억(수 초에서 약 1분까지 지속되는 정보), 그리고 장기 기억(오래 간직해온 기억) 등 세 가지로 분류하고, 이를 기반으로 다양한 표현 방식이 어떻게 작용하는지도 고려해야 한다고 말한다.

3. 데이터의 맥락을 이해해야 한다.

마지막으로 이 모든 행위의 기반이 되는 데이터를 이해해야 한다. 어떤 내용인지 뿐만 아니라 데이터를 활용하려는 목적과 데이터를 전달하는 과정의 맥락을 분명히 알고 있어야 한다. 즉, 데이터가 어디에서 왔는지, 믿을만한 출처인지, 필요한 데이터가 맞는지, 올바른 정보를 전달할 수 있는지 등을 확인할 수 있어야 한다. 그리고 합리적인 방법으로 데이터를 정제하고 집계하여 결과를 신뢰할 수 있어야 한다.

+ 본문 중에서 용어가 통일되지 않는 경우가 있었습니다. 예를 들어 표에서는 '매장'이라고 되어있는데 본문에서는 '매장'과 '상점'을 혼용하고 있는 식입니다. 만약 이 책을 보시게 된다면, 용어 사용에 있어 조금 열린 마음으로 보시면 좋겠습니다.

오늘부터 IT를 시작합니다 / 고코더 지음 / 한빛미디어 출판 / 2022년 출간

TEKI — Wed, 24 Aug 2022 23:04:59 +0900

"오늘부터 IT를 시작합니다." 이 책의 제목이다. 이게 무슨 말일까?

국립국어원에서 제공하는 우리말샘에서는 '아이티(IT)'와 '시작하다'를 다음과 같이 정의한다.

이를 종합해보면 IT를 시작한다는 것은 '정보 통신 기술'의 '처음' 단계를 이루는 것을 의미한다고 볼 수 있다.

그렇다면 정보 통신 기술이란 무엇일까? 초고속 인터넷, 이동 통신, 소프트웨어, 데이터베이스, 멀티미디어 등 정보 통신 기술이라고 하는 이 용어들은 무엇을 의미하는 걸까? 질문이 꼬리를 물기 시작하니 IT를 '시작'하는 일은 점점 미궁으로 빠지는 것 같다.

그럼에도 점점 컴퓨터가 없으면 안 되는 환경으로 바뀌고 있는 만큼 컴퓨터의 'ㅋ'자만 봐도 숨이 턱턱 막히는 사람들도 이젠 IT 지식에 목말라한다. 같은 딜레마에 빠진 사람에게 과연 이 책이 도움이 될지 궁금해졌다.

오늘부터 IT를 시작합니다 비유와 이야기로 풀어낸 비전공자를 위한 필수 IT 교양서
고코더 지음 | 한빛미디어 | 2022년 08월 12일 출간

이 책은 '비전공자를 위한 IT 교양서'라고 소개한다. 그렇다면 1) 너무 무겁지 않되 충분히 깊이 있는 내용이어야 하고, 2) 전공서적처럼 숨 막혀서는 안 된다. 이 관점에서 이 책을 살펴보았다.

1. 너무 무겁지 않되 충분히 깊이 있는 내용

이 책을 읽으면서 컴퓨터공학 또는 그와 관련된 지식을 필요로 하는 전공을 공부하려는 학생에게도 추천하고 싶었다. 또는 그런 공부를 해보면 어떨지 고민 중인 사람에게도 주저 없이 추천해주고 싶었다. 왜냐하면 첫째, 저자는 세상에서 IT가 어떤 쓸모가 있는지 이야기한다. 저자의 이야기를 듣다 보면 인터넷은 왜 끊기는지, 마우스하고 키보드가 있는데 왜 '코딩'이란 걸 또 배워야 하는지, 또 코딩을 배웠는데 왜 카카오톡 같은걸 뚝딱 만들어낼 수 없다는 건지 등등 여러 의문들이 풀린다.

둘째, 개발자들 사이에서 맨날 이야기하는 '프론트엔드', '백엔드', 데이터베이스' 등등 여러 가지 개념들을 일상적인 비유를 들어 설명해준다. 가장 마음에 들었던 점은 단순히 정의만 설명하는 것이 아니라 실제로 가장 기본적이고 중요한 특성을 설명하면서도 전혀 지루하지 않았던 점이다.

2. 교양서적다운 면모

무릇 교양서적이라면 교양을 채워줄 수 있어야 한다. IT로 먹고살면서도 한 번도 생각해보지 않았던 'IT와 환경'이라는 주제를 이 책을 통해 생각해보게 되었다.

하루에 종이컵을 1개 사용하면 연간 4kg의 이산화탄소가 배출된다고 한다.

그 외에도 재미있는 이야기를 많이 들려준다. 이런 이야기들을 통해 IT 세계의 즐거운 문화에 대해 더 많은 사람들이 이해하고 공감할 수 있지 않을까 하는 기대가 생긴다.

핸즈온 데이터 시각화 Hands-On Data Visualization / 잭 도허티, 일리야 일라얀코우 지음 / 한빛미디어 출판 / 2022년 출간

TEKI — Sun, 24 Jul 2022 23:02:21 +0900

빅데이터 시대라는 이름처럼 거의 모든 곳에서 데이터로부터 얻는 인사이트를 중요시하고 있다. 하지만 아무리 좋은 데이터를 많이 가지고 있어도 누군가에게 데이터의 의미와 가치를 제대로 전달하려면 특별한 방법이 필요하다.

데이터를 분석하고 해석하는 일은 항상 해오던 일이었다. 학생 때는 발표 자료나 논문을 위해, 창업에 도전했을 땐 시장성, 고객 반응, 성과 등의 자료로 성공적인 IR을 위한 자료를 완성하기 위해 셀 수 없이 많은 데이터로부터 이야기를 끌어냈었다. 이렇듯 학생, 교육자, 연구원, 직장인, 사업가 등 누구나 해왔던 일이다.

이러한 능력은 '데이터 리터러시'라는 이름을 붙이면서 더 많은 관심이 쏟아지고 있다. 엔지니어로 일하고 있는 지금도 대시보드를 포함해 다양한 데이터 시각화 작업을 하고 있다. 또한 질병과 전쟁 등으로 많은 어려움이 이어지고 있는 근 몇 년간 질병의 확산 추이나 경제 지표 등 다양한 사회적 상황을 데이터에 기반하여 심각성을 강조하고 있기도 하다.

하지만 전달하려는 의미를 직관적으로 시사하면서 시각적으로 매력적인 시각화 자료를 만드는 일은 항상 어렵다. 수많은 데이터 시각화 툴 사이에서 헤매다가 화려하지만 막상 전달하려는 내용은 잘 전해지지 않는 자료를 만드는 일도 있다. 비슷한 고민을 했던 사람이라면 이 책이 가이드라인이 되어줄 것이라고 믿는다.

핸즈온 데이터 시각화 효과적인 데이터 시각화 전략부터 20가지 시각화 도구 사용법까지
잭 도허티, 일리야 일라얀코우 지음 | 김태헌 옮김 | 한빛미디어 | 2022년 07월 04일 출간

이 책은

✔️ 다양한 예시로 센스있는 시각화 아이디어를 얻을 수 있다.

사실 데이터 시각화에서 가장 어려웠던 것은 데이터를 시각화하는 기술보다는 시각화 방법에 대한 아이디어를 내는 것이었는데, 어떤 데이터를 시각화하든 결론은 막대그래프와 파이 차트 둘 중 하나일 정도로 아이디어가 부족했었다.

이 책은 코로플레스 지도 디자인 원칙이라고 하는 데이터 시각화 색상과 색상의 간격에 대한 개념이나 포인트(점)와 폴리곤(선)의 개념 등 효과적인 시각화를 위한 디자인적인 개념을 알려준다. 이에 더해 다양한 시각화 예시를 통해 좋은 예와 나쁜 예를 비교하여 보여주기도 하고, 데이터에 따라 어떤 차이를 보이는지 설명해주기도 하는 등 다채로운 시각화 아이디어를 낼 수 있도록 도와준다.

✔️ 대화형(인터랙티브) 시각화에 대해서 알려준다.

대화형 시각화는 정적 시각화와 다르게 시청자들이 웹 브라우저를 통해 데이터와 직접적으로 상호작용할 수 있다고 한다. 다시 말해 마우스 커서의 움직임이나 클릭, 스크롤 등과 같은 이벤트를 통해 데이터를 정렬하거나 검색하는 등 사용자가 능동적으로 정보를 활용할 수 있는 방식이라는 뜻이다.웹/앱 디자인은 모두 반응형 디자인으로 변화하는 흐름에서 JPG, PNG, 또는 PDF 형식의 정적 시각화 방식을 고수하는 데에는 한계가 있다. 다른 흐름과 같이 시각화 방식도 대화형(인터랙티브) 차트와 지도로 데이터를 단순한 숫자의 나열을 넘어 이야기를 가질 수 있도록 변화하는 추세이며, 이러한 자료가 더 많은 관심과 흥미를 불러일으킬 수 있다. 이 책에서 이러한 대화형 시각화 방식에 대해서 이해하기 쉽게 알려준다.

✔️ 데이터를 기반으로 이야기를 전하고 싶은 모든 사람을 위한 책이다.

이 책에서는 어떤 이야기를 할지 고민하는 단계부터 데이터를 시각화하고 이를 공유하는 다양한 방법을 가르쳐주고 있다. 특히 시각화한 데이터로 효과적인 스토리텔링을 하는 방법도 가이드해주어서 유용했다. 그 외에도 수많은 데이터 시각화 툴과 시각화 방법 가운데 어떤 방식을 택해야 할지, 데이터를 어떻게 이해하고 활용해야 할 지 등을 가이드해준다.

✔️ 예제에서 구글 시트를 주로 사용한다.

예전에는 엑셀로 대부분의 작업을 했다면 이제는 온라인에서 협업이 가능한 구글 시트가 그 자리를 대체하고 있다. 이 책 대부분의 예제에서 구글 시트를 주로 사용하여 데이터를 가공하는 방법부터 이를 공유하여 활용하는 방법 등을 알려주고 있어 실용적인 도움을 받을 수 있다.

책 들여다보기

(이 파트에서 소개드리는 순서는 실제 도서의 페이지 순서와 무관합니다)

예제에서 공공데이터와 구글 시트를 주로 사용한다.

효과적인 데이터 시각화 방식과 디자인에 있어 좋은 예와 나쁜 예를 직관적인 예시와 함께 설명한다.

다양한 실제 사례를 통해 설명하고 있어 다양한 데이터 시각화 아이디어를 얻을 수 있다.

데이터 시각화를 위해 데이터에 대해 이해가 선행되어야 함을 이야기하며 그 방법을 간략하게 소개한다.

지도 디자인과 관련하여서도 다양한 개념을 소개합니다.

자바스크립트를 사용해 대화형 차트를 생성하는 방법을 알려줍니다.

O'Reilly Advancing into Analytics 엑셀, R, 파이썬으로 시작하는 데이터 분석 / 한빛미디어 출판 / 2022년 출간

TEKI — Sun, 29 May 2022 23:32:20 +0900

데이터 분석에 대한 관심이 높아지면서 데이터 분석을 시도하려는 학생 또는 실무자가 늘고 있다. 하지만 여전히 데이터 분석을 어떻게 시작해야 하는지 몰라 헤매는 사람들이 많다. 데이터 분석을 하고자 엑셀 자격증을 따거나 프로그래밍 언어를 공부하는 등의 노력과는 별개로 데이터를 제대로 알아가는 과정은 어렵기만 하다. 데이터 분석의 영역이 ML/DL까지 범위를 넓혀가고 있는 만큼 진입장벽만 높아지는 것 같기도 하다.

이 책이 좋은 점은 엑셀이라는 익숙한 도구로도 데이터 분석을 할 수 있도록 알려주어 진입장벽을 낮춰주었다는 것에 있다. 데이터 분석을 하고자 수학을 다시 공부하기 부담스러워 덮어버린 책이 많은데 이 책은 통계 이론부터 엑셀을 활용해 예시를 들어주기 때문에 훨씬 소화하기가 편하다.

엑셀, R, 파이썬으로 시작하는 데이터 분석 데이터 분석의 기본 개념과 3가지 핵심 도구 사용법
조지 마운트 지음 | 시진 옮김 | 한빛미디어 | 2022년 04월 29일 출간

이 책은

✔️ 엑셀을 다룰 줄 안다면 이해할 수 있다.

'파이썬으로 데이터 분석하기'나 '데이터 분석의 기본 R 배우기'와 같이 데이터 분석을 위해 무언가를 배우라고 하는 강의와 도서가 수없이 많다. 하지만 아주 다양한 분야에서 데이터 분석을 필요로 하는 만큼 데이터 분석을 처음 공부하는 사람들은 프로그래밍 언어보다 엑셀에 더 친숙할 것이라고 생각한다. 이 책에서는 엑셀을 기반으로 프로그래밍 언어를 소개하고 있고, 필요한 내용만 선별해 예시와 함께 알려준다. 따라서 엑셀만 다룰 줄 안다면 이 책을 통해 데이터 분석을 해볼 수 있을 것이다.

✔️ 통계 이론부터 엑셀을 기반으로 설명해준다.

앞쪽에서 먼저 통계 이론을 충분히 설명해주는데, 엑셀의 수식과 차트를 예시로 들어 설명을 해주고 있어서 지루하지 않다. 그리고 더 쉽게 이해할 수 있다. 통계 이론을 충분히 익히고 나면 뒷 부분에서는 엑셀을 기반으로 프로그래밍 언어로 하는 데이터 분석을 설명해주며, 데이터 분석과 시각화 방법에 더불어 ML을 이용한 데이터 분석 기법까지 예제와 함께 다루고 있다.

✔️ 데이터와 더 친해지고 싶은 이들에게 가이드북이 되어줄 것이다.

두껍지 않은 책임에도 정말 많은 내용을 다루고 있으며, 실제로 분석을 수행하려는 입장에서 알아야 할 기본적인 내용들을 꼼꼼하게 알려준다. 데이터의 선별부터 분석 과정과 결과 추론까지 일련의 과정을 설계할 수 있을 뿐만 아니라 프로그래밍 언어와 엑셀로 분석을 수행할 수 있도록 알려주기 때문에 이 책을 통해 공부하면서 바로 분석을 시도해볼 수 있을 것이다. 이를 통해 앞으로 무엇을 더 해야할 지에 대한 지표를 확인할 수 있을 것이다.

O'Reilly 머신러닝 실무 프로젝트 2판 / 한빛미디어 출판 / 2022년 출간

TEKI — Sun, 24 Apr 2022 22:10:09 +0900

머신러닝을 실무에서 활용하기 위해서는 생각보다 많은 기술이 필요하다. 특히 모델을 연구하는 것과 이를 실서비스에 적용하는 것의 간극은 아직은 낯선 개념이기 때문에 머신러닝과 엔지니어링을 균형 있게 이해하는 능력이 중요하다고 생각한다.

머신러닝과 엔지니어링을 다 잘하는 ML 계의 풀 스택 엔지니어도 실제로 존재하지만, 꼭 둘 다 완벽하게 잘해야 하는 건 아니다. 보통은 한 분야의 전문가가 다른 한 분야를 공부하면서 균형을 찾아가는 것 같다.

이 책은 여느 전공 책보다 얇아서 쉽게 다가갈 수 있었던 것 같다. 모든 것을 자세하게 설명해주지는 않지만, 필요한 개념은 빠짐없이 언급한다. 그리고 실무에서 상황에 따라 어떤 고민이 필요한 지 제시해준다. 예를 들어, 'Java로 구현해야 한다'라고 하지 않고, '이러한 상황에는 R을, 저러한 상황에는 Java를 사용한다면 이러저러할 수 있다. 그러니 이거저거에 따라 판단해야 한다'와 같은 식이다.

그래서 빠르게 훑어보면서 생태계를 이해하고, 필요한 부분에서는 다른 자료를 찾아볼 수 있도록 가이드를 제시해주는 식으로 실질적인 도움을 주기 위해 노력한 구성이라고 느꼈다.

덧붙여서 저자는 '어느 정도는 이론을 익힌 소프트웨어 개발자에게 적합한 실무서'라고 했다는 점을 참고하면 좋겠다.

머신러닝 실무 프로젝트 (2판) 실전에 필요한 MLOps, 머신러닝 모델 검증, 슬롯머신 알고리즘, 온라인 광고에서의 머신러닝
아리가 미치아키, 나카야마 신타, 니시바야시 다카시 지음 | 김모세 옮김 | 한빛미디어 | 2022년 03월 10일 출간

이 책은 크게 네 가지 내용을 다룬다.

1. 머신러닝 프로젝트를 시작하는 방법
2. 기존 시스템에 머신러닝을 통합하는 방법
3. 머신러닝에 사용할 데이터를 수집하는 방법
4. 가설을 수립하고 분석하는 방법

전반적인 구성을 보면 <Machine Learning for Work>라는 제목에 굉장히 충실하고 있다. 한달 전(2022년 3월)에 출간된 만큼 내용이 업데이트가 많이 되어있다. 2018년에 출간되었던 1판과 비교하면 모델 학습 결과의 수학적 판단이나 MLOps 환경 구축, 온라인 광고에서의 머신러닝 등에 대한 내용이 새롭게 추가되었다.

↓1판(2018년 출간)과 달라진 점은 더보기를 참고해주세요

※2판에서 추가된 내용

- CHAPTER 6 데이터 변경에 대응하고 장기적으로 머신러닝을 운용하기 위한 MLOps 환경 구축
- CHAPTER 7 머신러닝에 기반한 시행 결과 판단
- CHAPTER 8 수학적 관점(선형 회귀, 로지스틱 회귀, 결정 트리, 랜덤 포레스트, SHAP)에서 머신러닝 모델의 학습 결과를 해석
- CHAPTER 11 온라인 광고 콘텍스트에서 자주 사용되는 슬롯머신 알고리즘을 이용한 강화 학습
- CHAPTER 12 온라인 광고의 구성 방식, 운영 방식, 전환 효과 예측 등 각 단계에 적용할 수 있는 머신러닝의 원칙과 기법들을 설명

※아래 목차 중 2판에서 새롭게 추가된 챕터는 ★로 표시했습니다.

PART1 머신러닝 실무 노하우

CHAPTER 1 머신러닝 프로젝트 처음 시작하기

1.1 머신러닝은 어떻게 사용되는가
1.2 머신러닝 프로젝트 과정
1.3 운용 시스템에서의 머신러닝 문제점 대처 방법
1.4 머신러닝 시스템을 성공적으로 운영하기 위한 조건
1.5 정리

CHAPTER 2 머신러닝으로 할 수 있는 일

2.1 머신러닝 알고리즘 선택 방법
2.2 분류
2.3 회귀
2.4 클러스터링과 차원 축소
2.5 기타
2.6 정리

CHAPTER 3 학습 결과 평가하기

3.1 분류 평가
3.2 회귀 평가
3.3 머신러닝을 통합한 시스템의 A/B 테스트
3.4 정리

CHAPTER 4 기존 시스템에 머신러닝 통합하기

4.1 기존 시스템에 머신러닝을 통합하는 과정
4.2 시스템 설계
4.3 훈련 데이터를 얻기 위한 로그 설계
4.4 정리

CHAPTER 5 학습 리소스 수집하기

5.1 학습 리소스 수집 방법
5.2 공개된 데이터셋이나 모델 활용
5.3 개발자가 직접 훈련 데이터 작성
5.4 동료나 지인에게 데이터 입력 요청
5.5 크라우드소싱 활용
5.6 서비스에 통합해서 사용자가 입력
5.7 정리

★CHAPTER 6 지속적인 머신러닝 활용을 위한 기반 구축하기

6.1 머신러닝 시스템만의 독특한 어려움
6.2 지속적인 학습과 MLOps
6.3 머신러닝 인프라 구축 단계
6.4 지속적인 예측 결과 서빙
6.5 정리

CHAPTER 7 효과 검증: 머신러닝 기반 정책 성과 판단하기

7.1 효과 검증
7.2 인과 효과 추정
7.3 가설 검정 프레임
7.4 A/B 테스트 설계 및 수행
7.5 오프라인 검증
7.6 A/B 테스트를 수행할 수 없을 경우
7.7 정리
7.8 쉬어가기: 무조건 성공하는 A/B 테스트, A/B 테스트 모집단 조작

★CHAPTER 8 머신러닝 모델 해석하기

8.1 구글 콜랩에 설치된 라이브러리 버전 업데이트
8.2 학습용 파일 업로드 및 확인
8.3 선형 회귀 계수를 이용한 원인 해석
8.4 로지스틱 회귀 계수로 원인 해석
8.5 회귀 계수 p값 구하기
8.6 결정 트리를 시각화해 원인 해석
8.7 랜덤 포레스트의 Feature Importance 시각화
8.8 SHAP을 활용한 기여도 시각화
8.9 SHAP을 활용한 직원 만족도 시각화
8.10 정리

PART2 머신러닝 실무 프로젝트

CHAPTER 9 킥스타터 분석하기: 머신러닝을 사용하지 않는 선택지

9.1 킥스타터 API 확인하기
9.2 킥스타터 크롤러 만들기
9.3 JSON 데이터를 CSV로 변환하기
9.4 엑셀로 데이터 살펴보기
9.5 피벗 테이블로 다양하게 파악하기
9.6 목표를 달성했지만 취소된 프로젝트 확인하기
9.7 국가별로 살펴보기
9.8 보고서 작성하기
9.9 이후 작업
9.10 정리

CHAPTER 10 업리프트 모델링을 이용한 마케팅 리소스 효율화

10.1 업리프트 모델링의 사분면
10.2 A/B 테스트 확장을 통한 업리프트 모델링
10.3 업리프트 모델링용 데이터셋 만들기
10.4 두 가지 예측 모델을 이용한 업리프트 모델링
10.5 AUUC로 업리프트 모델링 평가
10.6 실제 문제에 적용
10.7 업리프트 모델링을 서비스에 적용
10.8 정리

★CHAPTER 11 슬롯머신 알고리즘을 활용한 강화 학습 입문

11.1 슬롯머신 알고리즘 용어 정리
11.2 확률분포에 관한 사고
11.3 사후 분포에 관한 사고
11.4 사후 분포의 신뢰 구간 상한을 이용한 구현 사례
11.5 UCB1
11.6 확률적 슬롯머신 알고리즘
11.7 다양한 슬롯머신 알고리즘 비교
11.8 부트스트랩 알고리즘을 이용한 콘텍스트 기반 슬롯머신 구현
11.9 현실 과제
11.10 A/B 테스트, 업리프트 모델링, 슬롯머신 알고리즘의 관계
11.11 정리

★CHAPTER 12 온라인 광고에서의 머신러닝

12.1 온라인 광고 비즈니스
12.2 문제 정식화
12.3 예측의 역할 및 구현
12.4 광고 송출 로그의 특징
12.5 머신러닝 예측 모델 운영
12.6 정리

이 책은

✔️ 서비스에 머신러닝을 무조건 적용하라고 조언하는 책이 아니다.

AI가 해내는 놀라운 일을 보다 보면 마치 AI가 마법처럼 문제를 해결해줄 수 있는 것처럼 생각하는 경우가 있다. 하지만 항상 강조하는 것처럼 머신러닝을 사용하지 않는 것이 더 좋은 경우도 있다. 이 책은 그러한 통찰력을 기를 수 있도록 도와주는 책이다.

✔️ 뭐부터 봐야할 지 모를 때 봐야할 책이다.

머신러닝 강의로 기초 이론을 공부하고, 실무에서 처음 접하는 개념이 있으면 그때그때 공부하는 편이다. 하지만 숲을 보려면 체계적인 자료가 도움이 된다. 두꺼운 전공 서적을 공부하는 것이 부담스럽다면 이 책으로 큰 흐름을 파악한 뒤에 필요한 부분을 더 공부하는 방법을 추천한다. 책이 얇아서 한 손으로 둘둘 말아 들고 출퇴근길에 봐도 된다.

책이 얇아서 한 손으로 둘둘 말아 들고 출퇴근길에 봐도 된다.

✔️ 머신러닝에 관심이 있는 개발자에게 추천한다.

실무에서 필요한 개념만 다루기 때문에 효율적으로 공부할 수 있다. 만약 따로 기초 이론을 공부하지 않았거나 더 깊이 있는 이해가 필요한 경우에는 이 책으로는 부족할 수 있다. 기술 면접 예상 질문과 답변 모음집 공부하듯 모르는 게 무엇인지 이 책을 통해 찾고, 나머지는 다른 루트로 정보를 구했다.

✔️ 실무자 뿐만 아니라 진로를 고민중인 학생과 취준생에게도 추천한다.

최근 데이터 활용 직군에 대한 관심이 늘면서 본인이 하고 싶은 일을 하려면 어떤 직무로 가야 할지에 대한 고민을 많이 하는 것 같다. 가장 흔한 질문 중에는 'AI를 하고 싶은데 무엇을 해야 할까요?'가 있다. 질문을 받는 입장에서는 답변의 범위가 너무 광범위해서 당황스러운 질문이다. 이는 관련 산업에 대한 정보가 부족해서라고 생각한다. 실무에서 머신러닝을 어떤 관점으로 사용하고, 어떤 방법을 사용하고 있는 지 이 책을 통해 먼저 공부해본다면 궁금증을 해결할 수 있을 것 같다. 무엇보다 설명이 어렵지 않아 진입 장벽이 높지 않다는 장점이 있다.

✔️ 레퍼런스가 대부분 일본어 자료이다.

책 특징 상 길게 설명하는 대신 도움이 될만한 논문 등 참고자료를 많이 추천해주는데 그중에 일본어 자료가 많다. 일본어책의 번역본이라서 당연히 감안해야 하는 부분이지만 읽다 보면 조금 아쉽다. 그래도 일본어 자료는 따로 표시를 해주거나 한국어 자료를 추가해주는 등 배려가 엿보인다.

책 구성

책은 크게 두 부분으로 구성된다. [1부 머신러닝 실무 노하우]에서는 머신러닝 알고리즘, 머신러닝 프로젝트 수행 과정 등 머신러닝 프로젝트를 수행하기 위해 알아야 할 기본 지식을 소개한다. [2부 머신러닝 실무 프로젝트]에서는 1부의 내용과 실제 사례를 기반으로 탐색적 분석, 업리프트 모델링, 머신러닝 활용 및 최적화 활용 방안 등을 소개한다.

참고문헌 & Index

레퍼런스가 대부분 일본어 자료이고, 한국어 자료가 있는 경우 첨부해주고 있다. 어떤 느낌인 지 공유해보면 좋을 것 같아서 인덱스와 함께 참고문헌도 첨부하였다.

[Kafka Study] 05. 프로듀서의 내부 동작 원리와 구현 w/실전 카프카 개발부터 운영까지

TEKI — Fri, 8 Apr 2022 23:36:51 +0900

5장과 6장에서는 프로듀서와 컨슈머의 내부 동작과 원리, 그리고 구현 방법을 다룬다. 한 번에 모두 소화하기는 쉽지 않아서 우선 프로듀서 내부 동작 원리를 이해하는 것만을 목표로 5장을 공부해보았다.

프로듀서와 카프카

카프카는 성능 향상을 위해 병렬 처리를 지향한다. 따라서 메시지는 토픽 별로 관리하고, 토픽은 최소 하나 또는 둘 이상의 파티션으로 나누어 구성하며, 각 파티션의 데이터는 용량에 따라 로그 세그먼트로 나누어 저장한다. 반면 프로듀서는 빠르고 안정적인 성능을 위해 배치 처리, 압축 전송 등의 방식으로 트래픽을 최소화하는 것을 추구한다. 따라서 프로듀서는 카프카의 구조를 유지하며 배치 방식으로 전송하기 위해 시리얼라이저와 파티셔너를 추가한 디자인으로 완성되었다.

제가 쉽게 이해하기 위해 그린 그림으로, 사실과 다를 수 있습니다.

3장에서 레코드 구조와 send()메소드 및 재시도 동작 등 전송 방식에 대해서 간단하게 살펴보았다면, 이번 장에서는 실시간 메시징 시스템에서 배치 방식으로 전송하면서 발생하는 처리 지연, 중복 및 손실 등의 이슈에 대해 어떻게 대처하고 있는지 알아보았다.

배치 전송 방식과 개선 전략

프로듀서가 카프카에 레코드를 전송하는 비용을 줄이기 위해 배치 전송을 사용한다고 했다. 하지만 카프카 사용 목적에 따라 전송 효율 높이는 것보다 지연 시간을 최소화하여 실시간으로 메시지를 처리하는 것이 중요한 경우도 있다. 이 경우엔 프로듀서의 버퍼 메모리에서 메시지가 대기하는 최대 시간(linger.ms)을 0으로 설정하는 등 단 건의 메시지도 즉시 전송할 수 있도록 설정해야 한다. 목적에 따라 적절하게 설정하는 것이 중요하다는 점에 유의하면서 배치 전송 방식을 이해해보자.

1. 지연시간 최소화: 라운드 로빈 전략과 스티키 파티셔닝 전략

파티셔너는 카프카의 여러 파티션 중 어느 파티션으로 레코드를 보낼지 결정해준다. 기본적으로 프로듀서는 레코드의 키를 해시 처리해서 레코드를 보낼 파티션을 특정한다. 만약 키값을 사용해서 메시지를 전송하고 있다면, 파티션 수를 늘렸을 때 매핑 테이블이 변경되어 동일한 파티션으로 메시지가 가지 않을 수 있다는 점에 주의해야 한다. 그런데 이 키값은 필수 요소가 아니다. ~~보낼 주소도 없는데 메시지를 어떻게 보내나 싶은데 그게 된다.~~

3장에서 공부한 내용 다시보기 (https://teki.tistory.com/69)

프로듀서 레코드의 키값을 지정해주지 않으면 null로 설정된다. 이렇게 null 값을 갖는 레코드만 모아서 카프카에 전송한다(배치). 레코드를 모으는 방식은 2019년 출시된 아파치 카프카 2.4 버전을 기점으로 전(라운드 로빈)과 후(스티키 파티셔닝) 버전이 서로 다른 전략을 취한다.

[RoundRobinPartitioner]
라운드 로빈 전략을 취하는 경우 파티션마다 메시지를 순서대로 전송할 수 있다는 장점이 있다. 하지만 파티션마다 전송 가능한 레코드가 충분히 모일 때까지 대기해야 한다는 치명적인 단점이 있다. 이를 보완하기 위해 전송을 위한 최소 레코드 수 외에 최대 대기 시간을 설정해서 너무 오래 기다리지 않도록 설정할 수 있지만, 이 경우 압축 효율이 낮아진다는 또 다른 단점이 생긴다. 또한, 대상으로 하는 파티션이 많을수록 프로듀서는 더 많은 연산을 해야 한다는 문제도 고려해야 한다.

[UniforStickyPartitioner]
반면, 스티키 파티셔닝 전략에 따라 수정된 로직은 파티션의 수가 아무리 많아도 하나로 묶어서 전송할 수 있기 때문에 라운드 로빈 방식의 단점이 보완된다. 실제로 컨플루언트의 테스트 결과에 따르면 스티키 파티셔닝 전략을 적용한 결과 약 30% 이상 지연시간이 감소하고, 프로듀서의 CPU 사용률도 줄어들었다.

https://www.confluent.io/blog/apache-kafka-producer-improvements-sticky-partitioner/

2. 압축 전송

(3장에서 건너뛰었던 내용) 앞에서 레코드 key와 value에 대해서 언급했는데, 이 데이터마다 SerDes(Serializer/Deserializer)를 데이터 타입으로 가진다. 여기에는 String, Short, Integer, Long, Double, Bytes 등 기본 텍스트 타입뿐만 아니라 XML, JSON, AVRO, Protobuf 등도 있다.

Serializer and Deserializer (https://www.baeldung.com/kafka-custom-serializer)

이렇게 다양한 형식과 크기의 메시지를 카프카에 저장하기 위한 공간을 계산하려면 네 가지 요소를 고려해야 한다.

평균 메시지 크기 (Average message size)
일일 메시지 전송량 (Messages per day)
최대 저장 기간 (Retention period(days))
리플리케이션 팩터 수

필요한 디스크 공간을 계산하는 식은 아래와 같다.

Average message size × Messages per day × Retention period × Replication Factor

예를 들어,

평균 메시지 크기: 10kb
일일 메시지 전송량: 1,000,000건
최대 저장 기간: 5일
리플리케이션 팩터: 3

라고 할 경우, 필요한 최소 디스크 공간은 10 × 1,000,000 × 5 × 3 = 150,000,000kb 즉 143GB로 산정할 수 있다. (당연히 실제 운영 시에는 재전송, 오류 등을 고려해 좀 더 여유를 두어야 할 것이다). 많은 데이터를 저장할수록 비용이 증가하는 만큼, 메시지 압축이 중요해진다. 또한 프로듀서의 배치 전송과 같은 케이스를 위해서도 카프카에서는 메시지 압축을 지원한다. 메시지 압축을 활용할 수 있는 상황에는..

최소한의 메시지 전송 지연이 허용될 때
디스크 및 네트워크 대역폭 절약을 위해 CPU 리소스를 더 사용할 수 있을 때
데이터 빈도가 높아서 배치 전송이 원활할 때
서버 로그나 XML, JSON 데이터와 같이 압축률이 높은 데이터를 전송할 때

등을 꼽을 수 있다. 카프카 및 클라이언트에서 지원하는 메시지 압축 포맷에는 gzip, snappy, lz4, zstd 등이 있다. 높은 압축률을 선호한다면 gzip이나 zstd를, 낮은 지연시간을 선호한다면 lz4나 snappy를 선택하는 등 특성을 잘 이해하고 필요에 따라 선택하면 된다.

https://developer.ibm.com/articles/benefits-compression-kafka-messaging/

압축 타입은 아래와 같이 compression.type 옵션으로 설정해주는데, 기본값은 '압축하지 않음'을 의미하는 none으로 저장되어 있다고 한다. 브로커에서 메시지 압축이 필요하다면 토픽 생성 시 아래와 같이 포맷 이름을 넣어주면 된다.

# (default) 압축하지 않음.
--config compression.type=none
# 압축 설정 (gzip)
--config compression.type=gzip

카프카 프로듀서(Java 기반)에서 메시지 압축 전송을 하려면 아래와 같이 설정할 수 있다.

kafkaProducerProps.put(“compression.type”, “<compression-type>”);
kafkaProducerProps.put(“linger.ms”, 5); //to make compression more effective

3. 중복 없는 전송

메시지 전송에는 '적어도 한 번 전송(at-least-once)', '최대 한 번 전송(at-most-once)', '정확히 한 번 전송(exactly-once)'등의 방식이 있다. 메시지 일부가 중복되더라도 메시지가 최소한 하나는 있음을 보장하는 방식이 '적어도 한 번 전송' 방식이라면, 메시지가 유실되는 것을 감수하고라도 한 건이라도 중복이 없도록 보장하는 방식이 '최대 한 번 전송' 방식이라고 볼 수 있다. 카프카의 '중복 없는 전송'은 기본적으로 '적어도 한 번 전송' 방식을 기반으로 동작한다.

https://medium.com/sfu-cspmp/in-depth-understanding-of-apache-kafka-in-10-minutes-255da627b9e

enable.idempotence 옵션이 false로 설정되어 있으면 중복 없는 전송이 보장되지 않고 있는 것이다. 중복 없는 메시지 전송이 필요하다면 이 옵션을 true로 바꿔주고, max.in.flight.requests.per.connectiion, acks, retries 등의 옵션을 추가로 설정해주어야 한다. 여기에서 idempotence, 즉 멱등성은 동일한 작업을 여러 번 수행하더라도 결과가 달라지지 않는 것을 의미한다.

4. 정확히 한 번 전송

중복 없는 메시지 전송을 위해 메시지를 비교하는 동작이 이루어지기 때문에 오버헤드가 당연히 존재한다. 하지만 컨플루언트 블로그에 따르면 카프카에서 해당 동작을 적용하면 기존 성능 대비 약 20% 정도만 감소했다고 한다. 따라서 일반적인 상황이라면 '중복 없는 전송'을 하도록 설정하는 것이 좋다. 하지만 반대로 메시지 중복이나 손실이 매우 치명적인 시스템도 있다. 이런 경우에는 '정확히 한 번 전송'이 보장되어야 한다. 정확히 한 번 전송이 성립하려면 중복 없는 전송일 필요가 있기도 하고, 전송에 실패한 메시지들은 한 번 이상 전송해야 하기도 한다. 즉, 중복 없는 전송은 정확히 한 번 전송의 일부 기능이라고 할 수 있다.

이 복잡한 전송 프로세스를 유지하기 위해 카프카는 트랜잭션 API라고 부르는 프로세스를 가진다. 트랜잭션이란 데이터베이스와 같은 시스템에서 이루어지는 논리적인 작업 단위를 말하며, ACID를 성립하는 것을 목표로 한다.

Atomicity: 원자성
Consistency: 일관성
Isolation: 독립성
Durability: 영속성

프로듀서가 카프카로 정확히 한 번 방식으로 메시지를 전송할 때, 메시지는 전체 실행 또는 전체 실패로 처리된다. (트랜잭션의 성질 중 A에 해당하는 원자성). 이를 위해 서버 측에서 트랜잭션 코디네이터Transaction Coordinator가 프로듀서로부터 전송된 메시지를 관리하며, 커밋 또는 중단 등을 표시한다. 그리고 저장된 메시지들이 정상 커밋된 것인지 실패한 것인지 식별하기 위해 컨트롤 메시지라는 타입의 메시지가 추가로 사용된다. 이 컨트롤 메시지는 오직 브로커와 클라이언트 통신에서만 사용되며, 페이로드에 애플리케이션 데이터 즉, 메시지의 밸류를 포함하지 않아 애플리케이션에 노출되지 않는다.

시스템을 기반으로 카프카를 운영하는 아이디어에 대해 생각해보는 흥미로운 시간이었다. 특히, 메시지 전송에서 중복과 유실의 관점에서 이해해보았다는 점이 많은 공부가 되었다. 아쉬운 점은 모르는 게 너무 많다 보니 한 장을 공부하는 데에도 시간이 오래 걸린다. 혼자 했으면 한없이 늘어졌을 텐데 스터디 방에서 꾸준히 공부하시는 분들이 보이니 나도 꾸준히 책을 펼치고 있다. 앞으로는 이론을 중심으로 공부하고, 실습은 좀 더 천천히 해봐야겠다.

※ Kafka Study 순서 ※

01. 카프카 특징과 이용 사례
02. 카프카 기본 개념과 구조
03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본동작과 예제
04. 카프카의 내부 동작 원리와 구현
05. 프로듀서의 내부 동작 원리와 구현
06. 컨슈머의 내부 동작 원리와 구현
07. 카프카 운영과 모니터링
08. 카프카 버전 업그레이드와 확장
09. 카프카 보안
10. 스키마 레지스트리
11. 카프카 커넥트
12. 엔터프라이즈 카프카 아키텍처 구성 사례
13. 카프카의 발전과 미래

※ 참고 자료와 이미지 출처 ※

[1] 실전 카프카 개발부터 운영까지, http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791189909345#N
[2] Apache Kafka Producer Improvements with the Sticky Partitioner, https://www.confluent.io/blog/apache-kafka-producer-improvements-sticky-partitioner/
[3] Message compression in Apache Kafka, https://developer.ibm.com/articles/benefits-compression-kafka-messaging/
[4] 카프카 프로듀서 파티셔너 종류 및 정리(2.5.0 기준), https://blog.voidmainvoid.net/360
[5] JSON Schema Serializer and Deserializer, https://docs.confluent.io/platform/current/schema-registry/serdes-develop/serdes-json.html
[6] Custom Serializers in Apache Kafka, https://www.baeldung.com/kafka-custom-serializer
[7] In-Depth Understanding of Apache Kafka in 10 Minutes, https://medium.com/sfu-cspmp/in-depth-understanding-of-apache-kafka-in-10-minutes-255da627b9e

정원 가꾸기의 즐거움 - 헤르만 헤세

TEKI — Thu, 7 Apr 2022 21:54:42 +0900

정원 가꾸기의 즐거움 헤르만 헤세 산문집
헤르만 헤세 지음 | 반니 | 2019년 12월 30일 출간

취미로 식물을 키운 지 2년이 다 되어간다. 처음 들였던 식물은 물 주기를 잊었거나 물을 너무 많이 줘서 다 죽고 없다. 그래도 미련이 남아 계속 새로운 식물을 들이다 보니 지금은 화분이 열몇 개가 있다. 식물을 키우는 것은 사실 아주 고되다. 분이 조금만 커져도 들기에 버겁도록 무겁고, 예쁜 화분일수록 더하다. 벌레는 끊임없이 꼬이고, 조금만 물 조절을 잘못해도 과습으로 병들어버린다. 그래도 필요한 것만 잘 챙겨주면 하루가 다르게 파릇파릇 자라는 게 뿌듯하다. 그리고 몸이 힘들다 보니 그동안은 어떤 잡념이든 다 비우고 머리를 식힐 수 있다. 그래서인지 식물 그 자체보다도 식물을 가꾸는 시간을 더 좋아한다. 그 시간이 있어서인지 문장 하나하나가 재미있었다. 그런데 이 책은 산문집이고, 나는 그 중 겨우 두 편을 읽었다. 리디 셀렉트에서 서비스 종료가 되었기 때문이라는 핑계는 있다. 오늘 밀리의 서재에서 구독권을 결제했으니 이제 그 핑계는 유효하지 않다. 스물한 편이 남았으니 반년이면 다 읽지 않을까?

나의 정원

"정원을 가꾸는 일은 놀이삼아 하면 즐겁지만, 생활과 의무가 되면 즐거움이 사라져버린다."

정원 가꾸기의 즐거움

"정원을 가꾸는 사람에게 이맘때는 다가올 봄에 해야 할 많은 일에 대해 생각해야 할 시기다."

"하지만 정원에는 아직 눈풀꽃 말고는 모두 죽어 있다. 이곳에서는 봄이 왔다고 저절로 나타나는 게 거의 없다."

"그런데 정원을 가꾸는 사람들에게는 이 시기가 마냥 한가롭지만은 않다. 그들은 여기저기 살피다가 지난겨울에 벌써 처리했어야 할 많은 일을 지금껏 미루고 있었음을 문득 깨닫는다."

"물론 모든 사람이 다 그런 건 아니다. (...중략...) 그런 사람들이라면 도구가 부족하지도 않고, 칼이 녹슬지도 않고, 씨앗 포대가 축축하게 젖어 있지도 않으며, 지하실에 저장해놓은 구근이나 양파가 허술하게 관리되어 썩는 일도 없다. 또한 새해에는 정원을 어떻게 가꿀지 계획도 이미 철저하게 세워놓았고, 필요한 거름도 미리 주문해두었다. 모든 것들이 모범적으로 잘 준비되었다. 찬사와 경탄을 받아 마땅하다. 그들의 정원은 올해에도 열두 달 내내 우리 정원이 부끄러울 정도로 찬란하게 빛날 것이다.
하지만 우리 정원에는 풀 한 포기 자라지 않았다. 우리 같은 게으름뱅이, 아마추어, 몽상가, 잠꾸러기 정원사들은 봄이 온 것에 화들짝 놀라 이웃집 정원을 보며 감탄한다. 우리가 아무것도 모른 채 그저 달콤한 겨울잠에 빠져 있는 동안, 부지런한 이웃들이 벌써 해놓은 모든 일을 보고 당혹스러워한다. 우리는 부끄러워하며 벌떡 일어나 바삐 서두른다. (...중략...) 어쨌거나 마침내 우리도 준비를 마치고 일을 시작한다."

"늘 그렇듯이 처음 며칠 동안은 좋은 예감에 들떠서 즐겁게 일하지만, 또한 힘들다."

화성에 보내는 21542905번째 이름

TEKI — Mon, 4 Apr 2022 22:22:55 +0900

SEND YOUR NAME TO MARS

2026년 7월에 화성으로 출발하는 우주비행선에 나 대신 타고 갈 내 이름

https://mars.nasa.gov/participate/send-your-name/future/certificate/125069369256

아래에서 신청할 수 있다.

Send Your Name to Mars

mars.nasa.gov

아래는 호기심 채우기용 TMI

이름을 어떻게 보내는 건지 찾아보니 이름을 저장한 메모리 칩 3개를 탐사선 옆에 붙여서 보낸다고 한다.

https://mars.nasa.gov/news/8872/nearly-11-million-names-of-earthlings-are-on-mars-perseverance/

2020년 화성탐사선과 함께 보낸 이름

https://mars.nasa.gov/resources/24877/send-your-name-placard-attached-to-perseverance/

칩 정보 요약

https://mars.nasa.gov/news/8872/nearly-11-million-names-of-earthlings-are-on-mars-perseverance/

[Kafka Study] 04. 카프카의 내부 동작 원리와 구현 w/실전 카프카 개발부터 운영까지

TEKI — Mon, 28 Mar 2022 01:20:24 +0900

앞서 카프카의 기본 개념과 구조를 이해하고, 실습 환경을 구축해보았다. 이번 장에서는 카프카 기본 명령어를 사용해 실습을 진행하며 리플리케이션 동작과 리더-팔로워 역할, 리더에포크, 컨트롤러, 로그 및 로그 컴팩션 등 핵심 내부 동작의 원리를 공부해보려고 한다.

카프카 리플리케이션
- 카프카의 기본 도구
- 토픽과 세그먼트, 그리고 리플리케이션
  - [실습 1] kafka-topics.sh 명령어로 토픽 생성
  - [실습 2] 토픽 상세 정보 확인
  - [실습 3] 콘솔 프로듀서를 이용해 토픽에 메시지 전송
  - [실습 4] 세그먼트 파일로 리플리케이션 확인
- 로그 세그먼트 관리 방법
  - [실습 5] 로그 세그먼트 삭제
메세지 일관성 유지 전략
- 1. 리더-팔로워 역할 분리
- 2. ISR과 컨트롤러
  - [실습 6] controlled shutdown 설정
- 3. 하이워터마크(커밋)와 리더에포크
  - [실습 7] 하이워터마크 확인
  - [실습 8] 리더에포크 확인

카프카 리플리케이션

카프카는 대량의 트래픽을 전송하는 환경에서도 높은 안정성과 최소한의 성능 저하를 유지한다. 이러한 카프카의 고가용성을 보장하는 가장 중요한 요소가 카프카의 리플리케이션 동작이다. 카프카 리플리케이션 동작을 이해하기 위해 알아야 하는 핵심 개념을 정리해보면 아래와 같다.

토픽Topic : 카프카에서 메시지 피드를 구분하기 위한 저장소
파티션Partition : 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것
리플리케이션Replication : 각 메시지들(파티션)을 여러 개로 복제해서 카프카 클러스터 내 다른 브로커에 분산시키는 동작
리플리케이션 팩터Replication Factor : 리플리케이션 동작 시 같은 메시지를 가지는 파티션의 총 개수 (= 원본 + 복제본)
최소 리플리케이션 수min.insync.replicas : 프로듀서가 acks 옵션을 all로 설정하여 메시지 전송 시, write 성공 확인을 위해 충족해야 하는 기준 (복제 완료 개수)
오프셋Offset : 파티션의 메시지가 저장되는 위치 (64bit 정수)
세그먼트Segment : 프로듀서가 전송한 메시지가 브로커의 로컬 디스크에 저장된 것
리더Leader : 리플리케이션 팩터 중 실제로 읽기와 쓰기 동작을 담당하는 파티션
팔로워Follower : 리더의 메시지를 복사하여 저장하는 파티션
컨트롤러Controller: ISR 관리와 리더 선출을 담당하는 브로커
ISRInSyncReplica : 동일한 메시지를 갖고 있는 가용한 리더와 팔로워를 묶는 논리적 그룹
커밋Commit : ISR 내에서 모든 팔로워의 복제가 완료됨을 표시하는 동작
하이워터마크High Water Mark : 마지막 커밋 오프셋의 위치
리더에포크Leader Epoch : 컨트롤러가 과거에 선출했던 리더의 수 (32bit 정수)

카프카의 기본 도구

앞에서 카프카 메시징 테스트를 할 때 사용했던 kafka-topics.sh나 kafka-console-producer.sh와 같이 카프카를 사용할 때 주로 사용하는 기본 명령어가 있다. 그 중, 아래 5개가 주로 사용하는 명령어라고 한다.

kafka-topics.sh: 토픽을 생성하거나 토픽 설정 등을 변경하기 위해 사용.
kafka-console-producer.sh: 토픽으로 메시지를 전송하기 위해 사용.
kafka-console-consumer.sh: 토픽에서 메시지를 가져오기 위해 사용.
kadka-reassign-partitions.sh: 토픽의 파티션과 위치 변경 등을 위해 사용.
kafka-dump-log.sh: 파티션에 저장된 로그 파일의 내용을 확인하기 위해 사용.

어떤 명령어가 있는지 궁금해서 bin 디렉토리를 찾아가 보니 뭐가 많이 있었다. 각 명령어는 실습하면서 천천히 알아갈 예정이다.

kafka binary 목록

토픽과 세그먼트, 그리고 리플리케이션

일반적으로 프로듀서와 컨슈머는 카프카의 토픽 중 하나를 특정하여 메시지를 주고받는다. 토픽은 카프카의 기본 도구 중 하나인 kafka-topics.sh 명령어를 이용해서 생성할 수 있고, 토픽 생성 시 파티션의 수와 리플리케이션 팩터 수를 필수로 지정해주어야 한다. 처음에 설정한 파티션과 리플리케이션 팩터 수는 나중에 수정할 수 있지만, 파티션 수의 경우 늘릴 수는 있지만 줄일 수는 없다는 점에 주의해야 한다.

토픽을 생성한 후, 토픽 정보를 조회하여 토픽과 리플리케이션 등의 정보를 모니터링할 수 있다. 실습을 통해 리플리케이션을 기반으로 한 카프카의 장애 대응 로직을 알아보았다.

[실습 1] kafka-topics.sh 명령어로 토픽 생성

kafka-topics.sh는 토픽과 관련된 작업을 할 때 사용한다. 이 명령어를 사용해서 teki-test01라는 이름으로 토픽을 생성해주고, 생성한 토픽 정보를 확인해보았다.

[yt.lim@teki-kafka01 ~]$ /usr/local/kafka/bin/kafka-topics.sh --bootstrap-server teki-kafka01.foo.bar:9092 --create --topic teki-test01 --partitions 1 --replication-factor 3
Created topic teki-test01.
[yt.lim@teki-kafka01 ~]$ /usr/local/kafka/bin/kafka-topics.sh --bootstrap-server teki-kafka01.foo.bar:9092 --describe --topic teki-test01
Topic: teki-test01	PartitionCount: 1	ReplicationFactor: 3	Configs: segment.bytes=1073741824
	Topic: teki-test01	Partition: 0	Leader: 1	Replicas: 1,3,2	Isr: 1,3,2

# 토픽 생성 명령어
--bootstrap-server teki-kafka01.foo.bar:9092 : 토픽을 생성할 호스트 및 포트 지정
--create : 토픽에 대해 수행할 동작이 'create'임
--topic teki-test01 : 토픽의 이름을 지정 (teki-test01)
--partitions 1 : 토픽 내 파티션 개수를 지정 (1개)
--replication-factor 3 : 리플리케이션 팩터 개수를 지정 (3개)

# 토픽 정보 출력 명령어
--bootstrap-server teki-kafka01.foo.bar:9092 : 대상 토픽이 있는 서버의 호스트 및 포트 지정
--describe : 토픽에 대해 수행할 동작이 'describe'임
--topic teki-test01 : 토픽의 이름을 지정 (teki-test01)

[실습 2] 토픽 상세 정보 확인

describe 옵션으로 토픽 정보를 출력해서 파티션 수, 리플리케이션 팩터 수, 파티션 번호, 리더와 팔로워 번호 등을 확인할 수 있다.

kafka-topics.sh 명령어에 describe 옵션을 줘서 확인한 토픽 정보

# 토픽 정보
PartitionCount :1 : 해당 토픽 내에 파티션 개수가 1개임
ReplicationFactor: 3 : 해당 토픽에 리플리케이션 팩터가 3개임
Configs: segment.bytes=1073741824 : 세그먼트 파일 크기를 나타내며, default값이 1073741824(1GB)이다.
Topic: teki-test01 : 토픽 이름
Partition: 0 : 토픽 teki-test01 중 0번 파티션의 정보라는 표시
Leader: 1 : 파티션0의 리더가 브로커 1임을 나타냄
Replicas: 1,3,2 : 리플리케이션들이 브로커 1, 3, 2에 있음을 나타냄
Partition: 0 : 토픽 teki-test01 중 0번 파티션의 정보라는 나타냄
I sr: 1, 3, 2 : 현재 ISR 그룹에 속한 리플리케이션, 즉 현재 정상적으로 동기화되고 있는 리플리케이션을 나타냄.

[실습 3] 콘솔 프로듀서를 이용해 토픽에 메시지 전송

kafka-console-producer.sh 명령어로 CLI 창에서 토픽에 메시지를 전송할 수 있다. 명령어를 실행해주면 아래와 같이 메시지 입력 쉘이 활성화된다. 메시지를 받아서 확인할 필요는 없으니 컨슈머는 따로 띄우지 않고 이대로 테스트 메시지를 보내주었다.

kafka-console-producer.sh로 teki-kafka01 토픽에 메시지 보내기

[실습 4] 세그먼트 파일로 리플리케이션 확인

물리적으로 메시지 데이터는 세그먼트 파일(xxx.log)로 저장된다. 로그 파일이 있는 /data/kafka-logs 디렉토리를 보니 ~~또 뭐가 많다..~~ 컨슈머 그룹 정보를 저장하는 카프카의 내부 토픽(__consumer_offset_xx)과 3장에서 만들었던 teki-overview01 토픽, 그리고 조금 전 만들었던 teki-test01 토픽을 확인할 수 있다.

/data/kafka-logs 확인

토픽 이름 뒤에 붙은 숫자가 뭔지 궁금해서 확인해보니 파티션 번호라고 한다. 다른 브로커에서도 똑같이 저장돼있다.

teki-kafka01~03에서 /data/kafka-logs 목록 확인

토픽은 메시지 데이터를 정해진 크기(log.segment.bytes)로 나누어 저장하며, 각 세그먼트에서 첫 번째 레코드의 오프셋이 해당 세그먼트 파일의 이름이 된다. 이러한 세그먼트는 각각 .log, .index, .timeindex 등 세 가지 파일로 구성된다. 이들은 대용량의 메시지 데이터를 다루는 데 있어 비용을 줄이는 데 도움이 된다. 예를 들어, 대용량 파일에서 특정 오프셋을 찾아서 메시지를 읽어야 할 때 .index 파일을 이용해서 비용을 줄일 수 있다.

teki-test01 토픽의 세그먼트 파일 목록

# 세그먼트 파일 종류
.log : 오프셋, 메시지의 물리적 위치, 메시지 내용 등 저장
.index : 오프셋에 물리적 위치를 매핑한 값
.timeindex : 오프셋에 timestamp를 매핑한 값

https://stackoverflow.com/questions/53744646/what-are-the-different-logs-under-kafka-data-log-dir

kafka-dump-log.sh 명령어를 이용해서 .log 파일을 출력할 수 있다.

[yt.lim@teki-kafka01 ~]$ /usr/local/kafka/bin/kafka-dump-log.sh --print-data-log --files /data/kafka-logs/teki-test01-0/00000000000000000000.log

# 로그 파일 출력
--print-data-log : 로그를 덤프하면서 메시지 내용을 출력
--files /data/kafka-logs/teki-test01-0/00...0.log : 덤프할 로그 파일을 지정. 콤마(,)로 구분해 여러 파일을 한 번에 읽을 수 있다.

직접 출력해보니 아까 보냈던 메시지 "test message"를 확인할 수 있었다.

세그먼트 파일에 저장된 메시지 정보 출력

# 로그 파일 내용
Starting offset: 0  : 시작 오프셋 위치가 0임
baseOffset: 0 lastOffset: 0 count: 1  : 메시지 카운드는 1임
payload: test message  : 아까 보낸 메시지 "test message" 확인

같은 방법으로 다른 카프카 브로커(teki-kafka01~teki-kafka03)에서도 똑같은 데이터가 저장되어 있는 것을 확인할 수 있었다 (리플리케이션).

브로커 3대 모두 같은 데이터를 가지고 있다

로그 세그먼트 관리 방법

앞에서 살펴보았듯 로그는 .log 형태로 저장되는 카프카의 세그먼트 파일을 의미한다. 카프카에 메시지가 들어오면 하나의 로그 세그먼트 파일에 덧붙이다가 segment.bytes에 설정된 크기(default: 1GB)에 도달하면 해당 세그먼트 파일을 close하고, 새로운 로그 세그먼트 파일을 생성한다(롤링Rolling). 하지만 이 파일을 무한히 쌓아둘 수는 없기 때문에 이 책에서는 로그 세그먼트를 관리하는 두 가지 방법을 소개한다.

먼저, 로그 세그먼트를 주기적으로 삭제하는 방법이 있다. 토픽 별로 로그의 보관 주기 또는 기준 크기를 설정해주면 카프카가 주기적으로 삭제 작업을 확인하여 로그 세그먼트를 삭제해준다. 체크 주기는 default 5분으로 설정되어 있고, 브로커 설정 파일(server.properties)에서 log.retension.check.interval.ms값을 바꾸면 주기를 수정할 수 있다.

server.properties 중 Log Retention Policy(기본값)

두 번째 방법은 컴팩션을 이용해 로그를 삭제하지 않는 대신 압축하여 보관하는 방법이다. 컴팩션은 이 로그 세그먼트를 관리하는 카프카의 정책 중 하나로, [실습 4]에서 봤던 __consumer_offset 토픽들이 로그 컴팩션을 사용하고 있다고 한다. 로그 컴팩션은 빠른 장애 복구라는 장점이 있지만, 작업 시 브로커에 입출력 부하가 발생할 수 있기 때문에 무조건 컴팩션을 사용하는 것은 비효율적이라고 한다. 따라서 필요에 따라 로그 관리 방법을 달리하고, 컴팩션 사용 시 반드시 브로커의 리소스 모니터링을 병행해야 한다. 로그 컴팩션은 나중에 더 공부해보기로 했다.

[실습 5] 로그 세그먼트 삭제

로그의 최대 보관 시간 또는 최대 보관 용량을 설정해서 기준치를 넘어가면 삭제 명령을 내리도록 설정할 수 있다. 먼저 실습을 위해 파티션 수 1, 리플리케이션 팩터 3으로 설정한 토픽을 생성해주었다.

[1] 최대 보관 시간 설정: retention.{ms|minutes|hours} 옵션
최대 보관 시간을 설정하면 그보다 오래된 파일을 삭제한다. interval(체크 주기) 값보다 짧게 설정하면 제때 삭제하지 않을 수 있음에 주의한다.

토픽 정보에 retention.ms 정보가 추가되었다

[2] 최대 보관 용량 설정: retention.bytes 옵션
최대 보관 용량을 설정하면 그보다 용량이 커질 때 세그먼트를 삭제한다. 파티션 당 용량을 기준으로 하기 때문에 모든 브로커에 파티션이 총 N개이면 총 retention.bytes*N만큼 용량을 차지한다. 또한, 세그먼트 단위로 파일을 삭제하기 때문에 활성상태인 세그먼트 1개만 남아있는 경우, retention.bytes를 넘어가도 정상적으로 삭제되지 않을 수 있다. 따라서 segment.bytes를 retention.bytes보다 작게 설정해주어야 한다는 점에 주의한다.

[3] 조건 삭제
조건을 걸 땐 --add-config 옵션을 주었다. 반대로 설정한 조건을 삭제하려면 --delete-config 옵션을 주면 된다. 앞에서 걸어준 조건 2개를 모두 삭제해주었다. 정상적으로 삭제되면 Complete 메시지가 출력된다.

콤마로 구분

메시지 일관성 유지 전략

카프카의 가장 큰 장점 중 하나는 고가용성이다. 리플리케이션 동작을 통해 고가용성을 확보했지만, 성능에 크게 영향을 주지 않으면서 안정적으로 리플리케이션하기 위해 여러 전략을 세웠다. 리더-팔로워 구조와 이를 유지하기 위한 ISR 그룹, 그리고 리더 선출을 담당하는 컨트롤러가 있다. 또, 커밋 동작과 커밋 오프셋 위치(하이워터마크), 복구 작업 시 사용하는 리더에포크 등도 메시지 일관성을 위한 전략이다. 브로커에서 카프카 서비스를 종료해 임의로 장애를 일으켜보는 실습을 통해 카프카가 메시지 일관성을 어떻게 유지할 수 있는지 이해해보았다.

1. 리더-팔로워

카프카는 리플리케이션을 하기 때문에 일반적인 상황에서 N개의 파티션이 동일한 메시지를 가지고 있다. 메시지를 전송할 때마다 매번 모든 파티션과 통신하는 것은 매우 비효율적이다. 따라서 카프카는 각 토픽을 중심으로 리플리케이션을 하고 있는 파티션들의 그룹에서 리더를 선발해서 프로듀서와 컨슈머는 리더를 통해서만 읽기/쓰기 작업을 수행하고, 나머지 팔로워들은 리더로부터 읽기 작업만 수행할 수 있도록 했다.

아래 그림은 브로커 4대에 파티션을 분배한 구조를 도식화한 것이다. 만약 리플리케이션 팩터를 1로 설정해서 복제본이 없다면, 왼쪽과 같이 3개 파티션만 존재할 것이다. 리플리케이션 팩터를 3으로 설정한다면, 카프카에는 오른쪽 그림과 같이 9개 파티션이 존재하게 된다. 총 파티션 수는 다르지만, 컨슈머와 프로듀서 사이에서 메시지를 읽고 쓰는 작업을 수행하는 파티션(리더)은 양쪽 모두 3개로 동일하다. 오른쪽의 경우 리더가 메시징 작업을 하는동안 나머지 파티션(팔로워: R1,R2)은 리더로부터 메시지를 읽어온다. 왼쪽 케이스는 브로커에 장애 발생 시 복불복으로 데이터 유실이 생기지만, 오른쪽 케이스는 브로커 중 하나에서 장애가 발생하더라도 다른 브로커에 복제본이 있어 메시지를 보존할 수 있는 걸 그림에서 확인할 수 있다.

https://damdam-kim.tistory.com/17

2. ISR과 컨트롤러

위 그림 중 오른쪽 케이스에서 리더 파티션이 있는 브로커에 장애가 발생했다면, 나머지 두 파티션 중 하나가 리더의 역할을 물려받아야 한다. 하지만 적절한 후보를 리더로 선출하지 않으며 메시지에 누락이 생기거나 또다른 장애가 발생할 수 있다. 그래서 리더와 리더가 될 자격이 있는 후보를 관리하기 위한 논리적인 그룹인 ISRInSyncReplica과 이를 관리하는 컨트롤러의 역할이 팔요해진다.

리플리케이션 팩터 수만큼 파티션을 복제한다고 했다. 이때, 한 파티션에 대한 복제본 중 가용한 파티션은 모두 ISR에 속한다. 즉, ISR에 속한 파티션은 리더이거나 리더가 될 자격이 있는 팔로워이다. 리더가 될 자격이 있다는 것은 리더와 동일한 데이터를 가지고 있음을 보장할 수 있다는 것을 의미한다. 자격을 상실한 파티션은 ISR에서 추방한다.

아래 그림은 장애 발생 시 ISR의 변화를 나타낸다. 만약 팔로워 파티션에 장애가 발생하면 ISR에서 추방한다(붉은색-topic02). 만약 리더 파티션에서 장애가 발생하면 ISR에서 리더를 퇴출하고 그룹 내 팔로워 중 하나를 새로운 리더로 선출한다(푸른색-topic01). 현재 ISR에 대한 정보는 [실습 2]에서와 같이 kafka-topics.sh 명령어에 describe 옵션을 주어 확인할 수 있다.

https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-topic-replication/

만약 ISR를 가진 브로커가 없다면 복구가 불가능한 상황이 되어 서비스 중단이 된다. 이 경우, 카프카는 OSROut-ofSyncReplica를 사용할 수 있다. OSR은 ISR 리스트에 없는 파티션을 리더로 선출할 수 있도록 하는 방식이며, unclean.leader.election.enable 옵션으로 사용여부를 설정할 수 있다. 해당 옵션값이 true로 설정되어 있다면 ISR을 가진 브로커가 없는 경우, ISR이 아닌 파티션 중에서 리더를 선발할 수 있다. 이는 리더가 될 자격을 보장할 수 없는(Unclean) 팔로워를 리더로 선출함으로 인한 데이터 유실 위험을 감수하고 서비스 중단의 위험성을 줄이는 방법이다.

카프카 옵션 중 min.insync.repliacs는 프로듀서가 카프카로 메시지 전송 시 write 성공을 보장할 수 있는 최소 복제본의 수(default: 1)를 의미한다. 즉, 프로듀서는 카프카에 메시지를 전송하고, min.insync.repliacas 이상의 팔로워가 리더로부터 복제를 완료하면 메시지 전송에 성공했다고 판단한다. 따라서 리플리케이션 팩터가 3이었지만 장애 발생으로 ISR에서 리플리케이션을 수행하는 파티션이 2개만 남았다고 해도 최소 복제본 수 1을 충족할 수 있다면 정상적으로 통신이 가능하다. 단, 메시지 전송 성공 확인 이후라도 남은 파티션에 복제가 실패하면 ISR에서 추방될 수 있다.

이런 경우를 방지하기 위해 리플리케이션 팩터 개수와 최소 복제본 수를 같게 설정하고 싶을 수 있다. 만약 위 사진의 topic02와 같은 상황에서 min.insync.replicas를 리플리케이션 팩터와 동일하게 3으로 설정했다면, 아무리 메시지를 전송하고 복제를 시도해도 최대 파티션이 2개를 넘지 못하기 때문에 프로듀서는 메시지 전송에 항상 실패하게 된다. 이렇듯 topic.replication.factor와 min.insync.replicas를 동일하게 설정하면, 장애 발생 시 바로 카프카 브로커 다운으로 이어진다. 따라서 필요에 따라 적정한 값을 설정해주는 것이 중요하겠다. 카프카에서는 topic.replication.factor=3, min.insync.replicas=2를 권장한다고 한다.

이렇게 ISR를 유지하고, 장애 발생 시 팔로워 중 리더를 선출하는 일은 모두 컨트롤러가 담당한다. 카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 하며, ISR의 데이터는 가용성을 보장하기 위해 주키퍼에 저장한다. (주키퍼가 없는 버전에서는?)

[실습 6] controlled shutdown 설정

컨트롤러가 새로운 리더를 선출해야 하는 종료 상황은 크게 두 가지로 분류한다. 하나는 예기치 않은 장애나 실패로 인한 종료 상황이고, 다른 하나는 controlled shutdown이라고 하는 graceful shutdown 또는 안전한 종료에 해당하는 종료 상황이다. controlled shutdown의 경우, 브로커의 모든 로그를 디스크에 동기화한 후 종료한다. 이후 브로커 재시작 시 로그 복구 시간이 짧다는 장점이 있으나 새로운 리더 선출에 따른 downtime이 있는데, kafka 1.0.0 버전에서 6분 30초 걸리던 작업을 kafka 1.1.0 버전에서는 3초로 줄였다고 한다. 이 설정은 server.properties에서 cotrolled.shudown.enable 옵션 (true일 때 controlled) 또는 kafka-config.sh 명령어로 확인할 수 있다.

[yt.lim@teki-kafka01 ~]$ /usr/local/kafka/bin/kafka-configs.sh --bootstrap-server teki-kafka01.foo.bar:9092 --broker 1 --describe --all

# 현재 브로커 설정 확인
--bootstrap-server teki-kafka01.foo.bar:9092 : 대상 브로커가 있는 서버의 호스트 및 포트 지정
--broker 1 : 1번 브로커를 지정하여 조회
--describe --all : 설정 정보 전체를 조회

모든 설정 정보가 다 나와서 그 중 controlled.shutdown 설정만 찾아봤더니 3개나 나왔다.

# controlled.shutdown 관련 브로커 설정 정보
controlled.shutdown.enable=true : 제어된 종료 사용 여부(true: 사용함)
controlled.shutdown.max.retries=3 : 제어된 종료 실패 시 재시도 횟수
controlled.shutdown.retry.backoff.ms=5000 : 제어된 종료 실패로 재시도하기 전, 이전 실패 복구를 위해 대기하는 시간(단위: ms)

3. 하이워터마크(커밋)와 리더에포크

카프카 파티션은 메시지를 저장하고, 그 위치를 오프셋으로 기억한다. 프로듀서가 리더에게 새로운 메시지를 보내고 ISR 내에서 모든 팔로워의 복제가 완료되면, 리더는 내부적으로 모든 리플리케이션 팩터가 전부 메시지를 복제했다는 표시(커밋)을 한다. 컨슈머는 커밋된 메시지만 읽을 수 있다. 단, 프로듀서 설정과 관련된 min.insync.replicas 설정값은 컨슈머에 영향을 주지 않는다.

마지막으로 커밋을 완료한 오프셋 위치를 하이워터마크라고 하며, 각 파티션마다 하이워터마크 정보를 저장하고 있다. 리더가 예상치 못한 장애로 다운되면, 새로운 리더로 선발된 (구)팔로워는 복구 과정에서 자신의 하이워터마크보다 높은 메시지를 삭제한다. 하지만 메시지를 저장하고 하이워터마크를 갱신하는 동작이 동시에 이루어지지 않기 때문에 메시지 손실이 발생할 수 있다. 따라서 리더에포크를 추가로 적용한다.

리더에포크를 적용하면 장애에서 복구된 팔로워가 메시지 삭제 동작을 하기 전에 먼저 리더에포크 요청과 응답 과정을 통해 하이워터마크를 갱신하여 메시지 손실을 방지할 수 있다. 말로는 잘 이해가 되지 않아서 자세한 동작은 실습을 통해 알아보았다.

[실습 7] 하이워터마크 확인

하이워터마크는 로컬 디스크의 replication-offset-checkpoint라는 파일에 저장돼있어 직접 확인할 수 있다. [실습 4]에서 확인한 /data/kafka-logs 하위에 있는 파일 중 replication-offset-checkpoint 파일이 있었다. 사람이 읽을 수 있는 파일이므로 cat으로 확인해보았다.

[yt.lim@teki-kafka01 ~]$ cat /data/kafka-logs/replication-offset-checkpoint
0
52
__consumer_offsets 29 0
__consumer_offsets 43 3
__consumer_offsets 0 0
__consumer_offsets 6 3
...
__consumer_offsets 34 0
__consumer_offsets 9 3
__consumer_offsets 14 0

우선 두 번째 줄은 오프셋 정보가 총 52줄이 있다는 것을 의미한다는 것은 알겠다. 우선 이 중 지금 필요한 줄만 뽑아보았다.

띄어쓰기를 기준으로 왼쪽부터 순서대로 토픽 이름, 파티션 번호, 커밋된 오프셋 번호를 뜻한다고 한다. 현재 teki-test01는 [실습 4]에서 보낸 테스트 메시지 이후 "Hi"라고 한 번 더 보낸 상태이니 커밋된 오프셋 번호가 오프셋이 2가 맞다. 새로 메시지를 보내 정말 변하는지 다시 확인해보았더니 대략 2초정도 후에 커밋이 완료되어 오프셋이 2에서 3으로 바뀌었다.

다른 브로커에도 동시에 변하는지 궁금해서 한 번 더 메시지를 보내보았다.

와..!!

[실습 8] 리더에포크 확인

리더에포크 상태는 리더의 leader-epoch-checkpoint 파일에 저장된다. teki-test01 토픽의 리더인 1번 브로커에 가서 파일을 열어보았다.

# 리더에포크 정보
0 : 파티션 번호
1 : 현재의 리더에포크 번호
0 0 : 첫 번째 0은 리더에포크 번호, 두 번째 0은 최종 커밋 후 새로운 메시지를 전송받게 될 오프셋 번호 (s"${entry.epoch} ${entry.startOffset}")

이렇게 리플리케이션과 장애 복구 과정 등 카프카의 내부 동작 원리를 알아보았다. 카프카 명령어를 사용해보는 실습이 많았는데, 직접 해본 만큼 카프카에 대해 훨씬 많이 알게 된 것 같다. 특히, 카프카를 더 효율적으로 운영하기 위해 고민할 수 있도록 이해의 기반을 다지는 내용이라 더 많은 시간을 투자한 것 같다. 대신 로그 컴팩션은 이번에는 존재만 알고 넘어가고, 다음에 더 자세히 공부해보려고 한다. 임의로 장애 상황을 만들어서 리더에포크 상태 변화를 확인하는 실습은 더 테스트해보고 따로 포스팅하기로 했다. 다음 장에서는 프로듀서에 관해 공부할 예정이다.

※ Kafka Study 순서 ※

01. 카프카 특징과 이용 사례
02. 카프카 기본 개념과 구조
03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본동작과 예제
04. 카프카의 내부 동작 원리와 구현
05. 프로듀서의 내부 동작 원리와 구현
06. 컨슈머의 내부 동작 원리와 구현
07. 카프카 운영과 모니터링
08. 카프카 버전 업그레이드와 확장
09. 카프카 보안
10. 스키마 레지스트리
11. 카프카 커넥트
12. 엔터프라이즈 카프카 아키텍처 구성 사례
13. 카프카의 발전과 미래

※ 참고 자료 ※

[1] 실전 카프카 개발부터 운영까지, http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791189909345#N
[2] 아파치 카프카 애플리케이션 프로그래밍 with 자바, http://www.kyobobook.co.kr/product/detailViewKor.laf?
[3] Kafka 운영자가 말하는 Topic Replication, https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-topic-replication/
[4] Kafka 운영자가 말하는 Producer ACKS, https://www.popit.kr/kafka-%EC%9A%B4%EC%98%81%EC%9E%90%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-producer-acks/
[5] https://github.com/apache/kafka/blob/ba237c5d21abb8b63c5edf53517654a214157582/core/src/main/scala/kafka/server/epoch/LeaderEpochFileCache.scala#L42
[6] what is a role of leader epoch checkpoint in log segment of Kafka partition?, https://stackoverflow.com/questions/50342961/what-is-a-role-of-leader-epoch-checkpoint-in-log-segment-of-kafka-partition
[7] [Kafka] 카프카 튜토리얼_Quick Start, https://soyoung-new-challenge.tistory.com/61
[8] https://docs.confluent.io/platform/current/installation/configuration/topic-configs.html

[9] what are the different logs under kafka data log dir, https://stackoverflow.com/questions/53744646/what-are-the-different-logs-under-kafka-data-log-dir
[10] Kafka retention 옵션 - log 보관 주기 설정, https://deep-dive-dev.tistory.com/63
[11] Kafka Replication, https://damdam-kim.tistory.com/17
[12] [Kafka] acks와 min.insync.replicas, https://songhayoung.github.io/2020/07/13/kafka/acks-replicas/#Introduction
[13] cloudera - ISR management, https://docs.cloudera.com/cdp-private-cloud-base/7.1.6/kafka-performance-tuning/topics/kafka-tune-broker-tuning-isr.html
[14] [kafka] unclean.leader.election.enable 옵션, https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=freepsw&logNo=221028179182
[15] Apache Kafka Supports 200L Partitions Per Cluster, https://www.confluent.io/blog/apache-kafka-supports-200k-partitions-per-cluster/
[16] Kafka Broker Configurations, https://docs.confluent.io/platform/current/installation/configuration/broker-configs.html
[17] Apache Kafka: Topic Partitions, Replicas & ISR, https://blog.knoldus.com/apache-kafka-topic-partitions-replicas-isr/

「시험장에 몰래 가져갈 이경오의 SQL+SQLD 비밀노트」 / 이경오 지음 / 한빛미디어 출판 / 2021년 출간

TEKI — Wed, 23 Mar 2022 23:54:18 +0900

유명한 SQL 책들이 있다. 절판된 후에도 인기가 많아 중고 시장에서 없어서 못 구하는 책도 있다. 그런 네임드 사이에서 이 책은 앞 순번은 아니었던 것 같다. (아니면 나만 몰랐거나) 그래서 이 책을 만나게 해 준 한빛미디어 '나는 리뷰어다' 관계자분들께 감사의 말을 전하고 싶다.

SQL을 공부하는 목적은 여러 가지가 있다. 자격증을 따기 위해, 혹은 실무에서 사용하거나 코딩 테스트를 준비하기 위해서 등등. 이 책은 기초를 다지고, 문제로 연습해보며, 직접 구축하는 방법과 공공데이터 활용 방법까지 다루고 있어서 누구에게나 유용할 것 같다. 특히, 독학으로 DB와 SQL을 공부해보려고 한다면 공부하기 좋은 내용일 것 같다.

책 구성은 오라클 DBMS를 직접 구축해보는 파트와 데이터 모델링에 대한 기본 개념을 다루는 파트, SQL 문법과 활용, 그리고 최적화하는 내용을 다루는 파트로 나뉜다. 또, 챕터마다 연습문제와 해설이 있다 (딱 100문제 있다). 이 글에서는 책 구성과 장단점, 그리고 인덱스를 정리해보았다.

소문난 명강의: 시험장에 몰래 가져갈 이경오의 SQL+SQLD 비밀노트
이경오 지음 | 한빛미디어 | 2021년 10월 10일 출간

이 책은

✔️ 쉽다.

기존에 패스트파이브의 강의를 하시던 분이 같은 주제로 책을 쓰셨다고 한다. 그 내공이 더해져서 군더더기 없이 명료한 설명이 나온 것 같다. 그리고 수많은 그림과 예시를 들어가며 끈질기게 설명해준다. 거기에 주의 사항이나 실무에서 얻은 인사이트를 같이 알려주어서 제대로 공부가 된다.

사실 전공자가 쉽게 느꼈다 해도 비전공자는 다르게 느낄 수 있다. 그래서 다른 독자의 리뷰를 찾아봤는데, 비전공자가 독학으로 충분히 이해할 수 있는 쉬운 책이라는 평이 많은 걸 보면 혼자만의 의견은 아닐 것이다.

✔️ 실무에서 SQL을 다루면서 기초가 부족하다고 느낄 때 공부해보길 추천한다.

책 제목부터 SQLD 자격증 책이라고 홍보해서 시험 준비용 책인 줄 알았다. 그런데 직접 책을 보니 DB를 설계·구축하고, SQL 기초와 성능에 대한 내용을 다룬다. 특히 가장 좋다고 생각한 점은 첫 번째 파트에서 DB를 직접 구축하고, 그 DB를 기반으로 나머지 파트에서 공부하고 실습하는 구성이다. DB를 직접 만들고 부수고 다 해보기 때문에 도움이 된다. 단, 데이터베이스 지식을 깊이 있게 다루지는 않는다.

✔️ 윈도우 환경에서 DB 구축을 가이드한다.

이 책의 최대 장점이자 단점이다! 윈도우를 쓰는 사람이 많기 때문에 누군가에겐 분명 장점일 거다. DB 구축을 혼자서도 충분히 할 수 있을 만큼 많은 이미지를 가지고 자세하게 설명해준다는 점도 그렇다. 하지만 맥이나 리눅스를 주로 사용하는 입장에서 조금 아쉽다. 물론 OS가 달라도 똑같은 오라클 DBMS고, 똑같은 SQL을 쓴다. 이 책에서 쓰는 dbeaver나 SQL Developer는 맥에서도 쓸 수 있다. 다만 처음 구축을 해보는 입장에서 맥이나 리눅스 환경에서 실습해야 한다면, 윈도우 cmd 기준으로 설명하는 부분을 맥 버전으로 알아서 컨버팅해서 이해해야 한다는 점이 좀 번거로울 것 같다.

✔️ 옆에 두고 레퍼런스로 쓰기 좋다.

책 구성이 깔끔해서 필요한 내용을 찾기가 쉽다. 온라인 강의를 기반으로 한 덕분에 이런 구성이 나오지 않았나 싶다. 책을 달달 외울 때까지는 옆에 두고 필요할 때마다 펼쳐보아야겠다. (그래서 시험장에 몰래 들고 갈 책이라고 이름을 지었나?)

✔️ 무료전자책이 있다.

이 책은 전자책이 있지만, 그 외에 무료 ebook 2권을 제공한다. <기본 및 활용 편>과 <시험 직전 비밀노트 편>이 있는데, 아래에 링크를 첨부해놓았다. <기본 및 활용 편>은 실습 환경을 구축하는 챕터 1과 데이터를 준비하는 챕터 2, 그리고 SQL 기본을 다루는 챕터 3을 포함한다(처음 ~ p122). <시험 직전 비밀노트 편>은 SELECT, GROUP BY, JOIN 등을 중심으로 중요한 팁을 모아놓은 파트인데, 이 부분만 따로 뽑아서 만든 책이다(p513 ~ p551). 이래도 괜찮은 건지 걱정이 좀 되지만 공부하는 입장에서는 정말 고마운 서비스이다. 무료 ebook을 본다면 나머지 내용도 공부하고 싶어질 것이라는 확신이라고 봐도 될 것 같다.

[무료전자책] 이경오의 SQL+SQLD 비밀노트 - 기본 및 활용 편

공공 데이터로 SQL 기본부터 실무 활용, 그리고 SQLD 자격증까지 한번에 끝낸다! 이 책은 IT 전공자를 포함한 일반인도 SQL을 더 수월하게 학습을 할 수 있도록 다음과 같이 구성했습니다. ① 손쉬운

digital.kyobobook.co.kr

[무료전자책] 이경오의 SQL+SQLD 비밀노트 - 시험 직전 비밀노트 편

digital.kyobobook.co.kr

책 구성

이 책은 3개 파트로 나뉘어있다. 크게 실습환경을 구축하는 파트 1과 개념을 공부하는 파트 2와 3으로 나눌 수 있다. 파트 1은 앞에서 언급한 것처럼 윈도우 환경에서 진행한다. 실습 데이터는 공공데이터를 사용하는데, 데이터 분석을 공부하려는 사람에게 도움이 될 것 같다. (공공데이터를 제공하는 사이트 더 알아보기) 파트 2에서는 데이터 모델링 기본 개념에 대해 다루고, 파트 3에서는 SQL을 다룬다. 간단하게 이론과 실습으로 구분했다고 보면 된다.

책 들여다보기

그림과 표를 잘 활용하면 백 마디 말보다 낫다. 훌륭한 책이다.

연습 문제는 주관식 또는 객관식 유형으로 총 100문제가 있고, 문제 해설도 성실하게 적혀있다.

Index

책을 레퍼런스로 사용하려면 인덱스가 중요하다. 궁금한 사람이 있다면 도움이 되길 바란다.

[Kafka Study] 03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본 동작과 예제 w/실전 카프카 개발부터 운영까지

TEKI — Mon, 7 Mar 2022 19:50:02 +0900

이번 장에서는 카프카 실습을 위해 인프라 구축을 해본다. 책에서 추천하는 방법은 AWS 환경이고, 온프레미스로 구축하는 방법도 알려준다. 하지만 나는 GCP를 사용하고 있기 때문에 GCP에서 실습을 진행했다. 환경을 구축한 후에는 프로듀서와 컨슈머에서 메시지를 주고받는 동작을 실제로 해보면서 기본 구동 원리를 공부했다.

실습 환경 구성

책에서는 카프카 3대, 주키퍼 3대, 배포용 서버 1대와 DNS 서버 1대로 구축해보는 것을 추천한다. 하지만 테스트용이므로 DNS 서버 구축까지는 안 하고 호스트 파일만 바꿔주기로 했다. 그래서 내가 구축하려는 환경은 아래와 같다. 어느 정도 익숙해지면 DNS 서버 두고 사이즈를 좀 더 키워보고 싶다.

GCP VM 인스턴스 스펙과 예상 비용

책에서 권장하는 주키퍼와 카프카 인스턴스의 최소 사양은 CPU 2, 4GB MEM이다. 그리고 배포용 서버는 그보다 낮아도 된다고 했다. 그래서 e2-medium(CPU 2, 4GB MEM) 6대와 e2-small(CPU 2, 2GB MEM) 1대를 생성하기로 했다. 그리고 리전 별로 비용이 상이한데 그중 가장 저렴한 편인 us-central1(아이오와)로 지정해주었다. OS는 책에서 Amazon Linux2와 가장 유사하다는 CentOS 7을 사용하면 된다고 해서 이걸로 부팅디스크를 만들어주었다.

네트워크 설정

이제 호스트 파일을 수정해야 한다. 책에서 알려준 것과 동일하게 7개 인스턴스의 내부 IP에 인바운드 규칙과 foo.bar 도메인을 매핑하여 7개 인스턴스의 호스트 파일을 모두 수정해주었다. (참고: 카프카에서 internal traffic과 exernal traffic 분리 및 /etc/hosts 파일 설정)

10.128.0.23 teki-ansible01.foo.bar  teki-ansible01
10.128.0.16 teki-kafka01.foo.bar teki-kafka01
10.128.0.17 teki-kafka02.foo.bar teki-kafka02
10.128.0.18 teki-kafka03.foo.bar teki-kafka03
10.128.0.19 teki-zk01.foo.bar teki-zk01
10.128.0.20 teki-zk02.foo.bar teki-zk02
10.128.0.21 teki-zk03.foo.bar teki-zk03

그다음 서로 잘 통신이 되는지 확인해보았다.

ping -c 2 teki-ansible01.foo.bar
ping -c 2 teki-kafka01.foo.bar
ping -c 2 teki-kafka02.foo.bar
ping -c 2 teki-kafka03.foo.bar
ping -c 2 teki-zk01.foo.bar
ping -c 2 teki-zk02.foo.bar
ping -c 2 teki-zk03.foo.bar

실습 소스 코드

이 책에서 실습하는 소스 코드는 깃에 올라가 있다. 코드를 다운로드하자.

$ sudo yum install -y git
$ git clone https://github.com/onlybooks/kafka2

앤서블Ansible 설치

카프카와 주키퍼 서버를 최소 3대씩 운영해야 하기 때문에 배포 자동화 도구가 필요하다. 앤서블은 오픈소스 소프트웨어로서, 다수의 서버를 대상으로 설정 관리, 애플리케이션 배포 등을 코드로 관리할 수 있도록 도움을 주는 도구라고 한다. 앤서블은 사용법이 간단해서 1인 관리자가 많이 사용한다고 한다. teki-ansible01에 앤서블을 설치해주자.

$ sudo yum install epel-release
$ sudo yum install ansible

주키퍼 설치

이제 teki-ansible01에 가서 앤서블로 주키퍼를 설치할 차례다. 깃에서 다운로드한 경로에서 chapter 2에 가면 ansible_playbook 디렉토리가 있다. 예제에서는 peter-xx로 되어있는데 내가 만든 서버는 teki-xx이기 때문에 설정 파일에서 도메인 이름과 서버 이름을 모두 바꿔줘야 한다. hosts 파일과 yaml파일, 그 외 여러 파일에서 peter를 모두 찾아 teki로 바꾸어준다. 그다음 ansible-playbook 명령어와 zookeeper.yml로 hosts 파일에 지정된 서버에 주키퍼를 설치해준다.

# 수정한 hosts 파일
[yt.lim@teki-ansible01 ansible_playbook]$ cat hosts
[zkhosts]
teki-zk01.foo.bar
teki-zk02.foo.bar
teki-zk03.foo.bar

[kafkahosts]
teki-kafka01.foo.bar
teki-kafka02.foo.bar
teki-kafka03.foo.bar

[kerberoshosts]
teki-zk01.foo.bar

# hosts 파일에 지정된 서버에 zookeeper.yml에 정의한 동작(주키퍼 설치)을 수행한다.
[yt.lim@teki-ansible01 ansible_playbook]$ ansible-playbook -i hosts zookeeper.yml

설치 끝.

주키퍼가 잘 올라갔는지 서버에 들어가서 확인해준다.

[yt.lim@teki-zk01 ~]$ sudo systemctl status zookeeper-server
[yt.lim@teki-zk02 ~]$ sudo systemctl status zookeeper-server
[yt.lim@teki-zk03 ~]$ sudo systemctl status zookeeper-server

카프카 설치

카프카도 주키퍼와 같은 방식으로 설치해준다.

# hosts 파일에 지정된 서버에 zookeeper.yml에 정의한 동작(주키퍼 설치)을 수행한다.
[yt.lim@teki-ansible01 ansible_playbook]$ ansible-playbook -i hosts kafka.yml

카프카가 잘 올라갔는지 확인해준다.

[yt.lim@teki-kafka01 ~]$ sudo systemctl status kafka-server
[yt.lim@teki-kafka02 ~]$ sudo systemctl status kafka-server
[yt.lim@teki-kafka03 ~]$ sudo systemctl status kafka-server

설치 끝! ft. Ansible로 주키퍼와 카프카를 설치하면서 헤맸던 기록

메시징 테스트

위에서 구성한 카프카에서 1) 토픽을 생성하고, 2) 콘솔 프로듀서와 콘솔 컨슈머로 메시지를 주고받는 테스트를 해보았다.

1. 토픽 생성

카프카가 설치된 서버에서 카프카가 제공하는 도구 중 kafka-topics.sh 명령어를 이용해 teki-overview01 토픽을 생성했다.

[yt.lim@teki-kafka01 ~]$ /usr/local/kafka/bin/kafka-topics.sh --bootstrap-server teki-kafka01.foo.bar:9092 --create --topic teki-overview01 --partitions 1 --replication-factor 3

성공하면 토픽이 생성되었다는 메시지가 출력된다. 메시지를 보내고 받을 준비가 끝났다.

Created topic teki-overview01.

2. 프로듀서와 컨슈머로 메시지 주고받기

테스트를 위해 같은 서버에서 프로듀서 cmd 창과 컨슈머 cmd 창을 각각 하나씩 열고, 아래 명령어를 실행해주었다.

# 프로듀서
[yt.lim@teki-kafka01 ~]$ /usr/local/kafka/bin/kafka-console-producer.sh --bootstrap-server teki-kafka01.foo.bar:9092 --topic teki-overview01

# 컨슈머
[yt.lim@teki-kafka01 ~]$ /usr/local/kafka/bin/kafka-console-consumer.sh --bootstrap-server teki-kafka01.goo.bar:9092 --topic peter-overview01

프로듀서 창은 메시지를 전송할 수 있는 명령 프롬프트로 바뀐 것을 확인했고, 컨슈머 창은 아직 전송한 메시지가 없으므로 아무것도 출력되지 않는 화면인 걸 확인했다. 이 상태에서 프로듀서에 메시지를 입력해주면 컨슈머에서 메시지를 받아서 출력해준다. 컨슈머를 종료하면 받은 메시지 개수를 알려주기도 한다.

프로듀서 기본 동작과 예제

위 실습에서 프로듀서는 메시지 전송을 담당했다. 실제로 프로듀서는 여러 옵션으로 다양한 메시지 전송 방식을 구현할 수 있다. 프로듀서의 메시지 구조와 전송 로직, 그리고 옵션에 대해 알아보았다.

프로듀서 전체 흐름

프로듀서의 전체 흐름은 아래와 같다. 실제 메시지 데이터인 ProducerRecord, 메시지를 전송하는 프로듀서의 send() 메소드, 그리고 send() 메소드 동작 이후 카프카에 전송되기 전까지 벌어지는 일들에 대해 알아보았다.

https://www.cloudduggu.com/kafka/producers/

Producer Record

프로듀서가 카프카로 전송하는 실제 메시지는 ProducerRecord이다. 이 레코드는 토픽과 파티션, 그리고 키와 밸류로 구성되어 있다.

[1] 토픽 (필수)
프로듀서가 카프카로 레코드를 전송할 때, 카프카의 특정 토픽으로 메시지를 전송한다. 따라서 레코드에는 대상 토픽 정보가 필수적으로 들어있다.

[2] 파티션 (선택)
기본적으로 라운드 로빈 방식으로 파티션을 선택해 레코드를 전달한다. 또는 특정 토픽의 특정 파티션을 지정하여 레코드를 전송할 수 있는데, 이때 '파티션' 값을 레코드에 넣어준다.

[3] 키 (선택)
대상 파티션을 지정할 때, 파티션에 레코드를 정렬할 수 있는 키를 함께 전달할 수 있다.

[4] 밸류 (필수)
메시지의 내용이다. 당연히 필수.

send() 메소드와 배치 전송

레코드는 send() 메소드를 통해 카프카로 전송을 시작하고, 시리얼라이저Serializer와 파티셔너Partitioner를 거쳐 파티션 별로 모여 대기한다. 이후 카프카로 배치 전송을 시도한다. 만약 배치 전송에 실패하면 지정된 재시도 횟수만큼 다시 send() 메소드 실행 전으로 돌려보내는 재시도 동작을 수행하고 성공 시 레코드와 메타데이터를, 실패 시 최종 실패를 전달한다.

프로듀서의 주요 옵션

프로듀서의 주요 옵션은 아래와 같다.

컨슈머 기본 동작과 예제

프로듀서에서 메시지를 전송했다면, 컨슈머에서 메시지를 받을 수 있다. 컨슈머는 내부적으로 컨슈머 그룹Consumer Group, 리밸런싱Rebalancing 등 여러 동작을 수행한다. 프로듀서의 속도와 비슷한 수준으로 컨슈머에서 메시지를 읽고 처리해야 지연이 발생하지 않기 때문에 이러한 동작들이 중요하다고 한다.

컨슈머의 기본 동작

프로듀서가 카프카의 토픽으로 메시지를 전달했다면, 그 메시지들은 브로커의 로컬 디스크에 저장된다. 컨슈머가 가져오는 메시지들은 그 데이터다.

[1] 컨슈머 그룹
카프카의 파티션에 메시지를 요청하는 주체는 컨슈머 그룹이다. 컨슈머 그룹은 하나 이상의 컨슈머들이 모여 있는 그룹을 의미하는데, 모든 컨슈머는 반드시 어떠한 컨슈머 그룹에 속한다. 컨슈머 그룹은 파티션의 리더에게 메시지를 요청하느데, 이때 파티션 수와 컨슈머 그룹 내 컨슈머의 수는 일대일로 매칭되는 것이 이상적이라고 한다. 파티션 수보다 컨슈머 수가 많으면, 노는 컨슈머가 늘어나서 비효율적이기 때문이다.

[2] 리밸런싱
만약 파티션에 메시지를 요청한 컨슈머 그룹 내에서 일부 컨슈머에 장애가 발생했다면, 리밸런싱 동작을 통해 동일한 그룹에 있는 다른 컨슈머가 역할을 대신 수행한다.

컨슈머가 메시지를 가져오는 방법 세 가지

컨슈머가 메시지를 가져오는 방법은 크게 1) 오토 커밋, 2) 동기 가져오기, 3) 비동기 가져오기의 세 가지 방식이 있다.

[1] 오토 커밋
오토 커밋은 오프셋을 주기적으로 커밋해주는 방식이다. 관리자가 오프셋을 따로 관리하지 않아도 되어 편리하기 때문에 컨슈머 애플리케이션들의 기본값으로 가장 많이 사용된다. 메시지 누락이나 중복 등 문제가 생기는 경우가 있지만 일반적인 상황에서는 거의 발생하지 않고 안정적으로 동작한다고 한다.

[2] 동기 가져오기
poll()을 이용해 메시지를 가져와 처리를 완료한 다음 현재 오프셋을 커밋한다. 그만큼 속도는 느리지만, 잘못된 오프셋 커밋으로 인한 메시지 손실은 거의 없다. 하지만 메시지 중복 이슈에서 자유롭지는 않다.

[3] 비동기 가져오기
오프셋 커밋에 실패해도 재시도하지 않기 때문에 메시지 누락 위험은 있지만, 메시지 중복 이슈에서 상대적으로 가장 자유롭다. 이러한 비동기 방식을 보완하기 위해 콜백을 같이 사용하는 경우도 있다.

컨슈머의 주요 옵션

컨슈머의 주요 옵션은 아래와 같다.

※ Kafka Study 순서 ※

01. 카프카 특징과 이용 사례
02. 카프카 기본 개념과 구조
03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본 동작과 예제
04. 카프카의 내부 동작 원리와 구현
05. 프로듀서의 내부 동작 원리와 구현
06. 컨슈머의 내부 동작 원리와 구현
07. 카프카 운영과 모니터링
08. 카프카 버전 업그레이드와 확장
09. 카프카 보안
10. 스키마 레지스트리
11. 카프카 커넥트
12. 엔터프라이즈 카프카 아키텍처 구성 사례
13. 카프카의 발전과 미래

※ 참고 자료와 이미지 출처 ※

Ansible로 주키퍼와 카프카를 설치하면서 헤맸던 기록

TEKI — Fri, 4 Mar 2022 23:26:23 +0900

처음 주키퍼 설치를 시도한 결과

오류 해결 후 설치 성공

1. 첫 번째 오류

앤시블 스크립트는 책<실전 카프카 개발부터 운영까지>에서 제공한 걸 사용했다. 주키퍼를 설치할 서버를 모두 구축하고, rsa 키로 ssh 연결이 잘 되는 걸 확인했는데 아래와 같이 UNREACHABLE! 오류가 생겼다.

[yt.lim@teki-ansible01 ansible_playbook]$ ansible-playbook -i hosts zookeeper.yml

PLAY [zkhosts] ********************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************************************************************************************************************************************************************************
The authenticity of host 'teki-zk01.foo.bar (10.128.0.19)' can't be established.
ECDSA key fingerprint is SHA256:FxmUkVb6V+MZAe3ejfuY3Ct8nKkh14NdGwDSJdSUQNU.
ECDSA key fingerprint is MD5:a5:eb:fa:ba:9f:de:ee:2a:c8:5e:c2:b8:55:48:25:b3.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'teki-zk02.foo.bar (10.128.0.20)' can't be established.
ECDSA key fingerprint is SHA256:vqByGQ5aS473lgjxxTredOfvKREh1mNLxmDrDRsdKeE.
ECDSA key fingerprint is MD5:c8:b3:27:ce:bc:e4:72:8f:61:df:a8:e3:6a:21:0a:d3.
Are you sure you want to continue connecting (yes/no)? The authenticity of host 'teki-zk03.foo.bar (10.128.0.21)' can't be established.
ECDSA key fingerprint is SHA256:9aayJTRBt0DKjcrLoXY9ST7t4kxPdL9oPQuP5Za43qM.
ECDSA key fingerprint is MD5:a4:ca:81:86:26:1a:2a:f1:aa:3d:46:69:d1:79:f5:58.
Are you sure you want to continue connecting (yes/no)? yes
Please type 'yes' or 'no': yes
Please type 'yes' or 'no': yes

오류 메시지를 보면 "Failed to conect to the host via ssh: Host key verification failed."라고 설명한다. host 등록, ssh 키 등록 등 다 해주었고, 테스트까지 했기 때문에 문제가 뭔지 알 수 없었다. 출력 결과를 다시 들여다보니 실행 직후 메시지가 보였다. 서버들이 모두 known hosts에 등록이 안되어있어서 yes라고 입력주어야 했는데, 서버 3개가 동시에 요청을 해서 입력 값이 제대로 들어가지 않은 것 같았다. 단순하게 그냥 두 번, 세 번 시도하면서 다 등록해주니 전부 ok 사인이 났다. 이제 다 해결한 줄 알았다.

두 번

세 번

2. 두 번째 오류

잘 진행하다가 갑자기 주키퍼 서버 호스트를 찾을 수 없다는 오류가 떴다.

fatal: [teki-zk03.foo.bar]: FAILED! => {"changed": false, "msg": "Could not find the requested service zookeeper-server: host"}

데몬 reload를 해봤는데 해결되진 않고, 오류 메시지에 문구가 하나 추가됐다. 로그를 보려면 systemctl status zookeeper-server.service와 journalctl -xe를 확인하라고 한다.

[yt.lim@teki-ansible01 ansible_playbook]$ systemctl daemon-reload
==== AUTHENTICATING FOR org.freedesktop.systemd1.reload-daemon ===
Authentication is required to reload the systemd state.
Authenticating as: root
Password:
==== AUTHENTICATION COMPLETE ===
[yt.lim@teki-ansible01 ansible_playbook]$
[yt.lim@teki-ansible01 ansible_playbook]$
[yt.lim@teki-ansible01 ansible_playbook]$ ansible-playbook -i hosts zookeeper.yml
...

TASK [zookeeper : make sure a service is running] ***************************************************************************************************************************************************************************************************************************************************
fatal: [teki-zk03.foo.bar]: FAILED! => {"changed": false, "msg": "Unable to start service zookeeper-server: Job for zookeeper-server.service failed because the control process exited with error code. See \"systemctl status zookeeper-server.service\" and \"journalctl -xe\" for details.\n"}
fatal: [teki-zk01.foo.bar]: FAILED! => {"changed": false, "msg": "Unable to start service zookeeper-server: Job for zookeeper-server.service failed. See \"systemctl status zookeeper-server.service\" and \"journalctl -xe\" for details.\n"}
fatal: [teki-zk02.foo.bar]: FAILED! => {"changed": false, "msg": "Unable to start service zookeeper-server: Job for zookeeper-server.service failed. See \"systemctl status zookeeper-server.service\" and \"journalctl -xe\" for details.\n"}

PLAY RECAP ******************************************************************************************************************************************************************************************************************************************************************************************
teki-zk01.foo.bar          : ok=17   changed=4    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
teki-zk02.foo.bar          : ok=17   changed=4    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
teki-zk03.foo.bar          : ok=17   changed=4    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

메시지에서 하란대로 로그를 봤더니 pam 인증이 실패했다며 '암호 서비스로 사전 확인 실패'라고 한다. 혹시나 하고 앤시블 스크립트 폴더를 둘러보니 도메인과 호스트 이름이 잘못 설정되어 있었다. 책에서는 peter-zk01 식으로 서버 이름을 설정했는데, 이걸 teki-zk01 와 같이 바꾸었기 때문에 안맞았던 것이다. 호스트 파일과 yml 파일 몇 개 수정하면서 누락된 것들이 있어서 문제가 생겼던 것이다. grep으로 꼼꼼하게 찾아서 다 바꿔주었다.

 3월 04 07:20:00 teki-ansible01 su[19839]: (to root) yt.lim on pts/0
 3월 04 07:20:00 teki-ansible01 su[19839]: pam_unix(su:session): session opened for user root by yt.lim(uid=0)
 3월 04 07:20:09 teki-ansible01 passwd[19851]: pam_pwquality(passwd:chauthtok): pam_get_authtok_verify returned error: 암호 서비스로 사전 확인 실패
 3월 04 07:20:13 teki-ansible01 passwd[19851]: pam_unix(passwd:chauthtok): password changed for root
 3월 04 07:20:23 teki-ansible01 passwd[19855]: pam_unix(passwd:chauthtok): password changed for root

이번엔 진짜 성공! 이렇게 주키퍼 설치는 끝냈다. 카프카 설치도 똑같은 과정이니까 제발 아무 문제 없이 끝나기를 바랬다.

출력 결과 전체

[yt.lim@teki-ansible01 ansible_playbook]$ ansible-playbook -i hosts zookeeper.yml

PLAY [zkhosts] **************************************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk01.foo.bar]
ok: [teki-zk02.foo.bar]
ok: [teki-zk03.foo.bar]

TASK [common : Set timezone to Asia/Seoul] **********************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk03.foo.bar]
ok: [teki-zk01.foo.bar]
ok: [teki-zk02.foo.bar]

TASK [common : install Java and tools] **************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk03.foo.bar]
ok: [teki-zk02.foo.bar]
ok: [teki-zk01.foo.bar]

TASK [common : copy krb5 conf] **********************************************************************************************************************************************************************************************************************************************************************
changed: [teki-zk01.foo.bar]
changed: [teki-zk02.foo.bar]
changed: [teki-zk03.foo.bar]

TASK [add the group zookeeper] **********************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk03.foo.bar]
ok: [teki-zk02.foo.bar]
ok: [teki-zk01.foo.bar]

TASK [add the user zookeeper] ***********************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk03.foo.bar]
ok: [teki-zk02.foo.bar]
ok: [teki-zk01.foo.bar]

TASK [stop zookeeper-server] ************************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk03.foo.bar]
ok: [teki-zk02.foo.bar]
ok: [teki-zk01.foo.bar]

TASK [zookeeper : remove directory zk] **************************************************************************************************************************************************************************************************************************************************************
changed: [teki-zk03.foo.bar]
changed: [teki-zk01.foo.bar]
changed: [teki-zk02.foo.bar]

TASK [make dir zookeeper] ***************************************************************************************************************************************************************************************************************************************************************************
changed: [teki-zk01.foo.bar]
changed: [teki-zk02.foo.bar]
changed: [teki-zk03.foo.bar]

TASK [download zookeeper from web] ******************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk03.foo.bar]
ok: [teki-zk01.foo.bar]
ok: [teki-zk02.foo.bar]

TASK [unarchive zookeeper] **************************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk03.foo.bar]
ok: [teki-zk01.foo.bar]
ok: [teki-zk02.foo.bar]

TASK [setup link zookeeper] *************************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk01.foo.bar]
ok: [teki-zk02.foo.bar]
ok: [teki-zk03.foo.bar]

TASK [copy zookeeper server conf files] *************************************************************************************************************************************************************************************************************************************************************
changed: [teki-zk02.foo.bar]
changed: [teki-zk01.foo.bar]
changed: [teki-zk03.foo.bar]

TASK [zookeeper : create myid] **********************************************************************************************************************************************************************************************************************************************************************
changed: [teki-zk03.foo.bar]
changed: [teki-zk01.foo.bar]
changed: [teki-zk02.foo.bar]

TASK [zookeeper : change file ownership, group and permissions] *************************************************************************************************************************************************************************************************************************************
changed: [teki-zk01.foo.bar]
changed: [teki-zk02.foo.bar]
changed: [teki-zk03.foo.bar]

TASK [copy zookeeper server in systemd] *************************************************************************************************************************************************************************************************************************************************************
ok: [teki-zk01.foo.bar]
ok: [teki-zk02.foo.bar]
ok: [teki-zk03.foo.bar]

TASK [zookeeper : just force systemd to reload configs] *********************************************************************************************************************************************************************************************************************************************
ok: [teki-zk01.foo.bar]
ok: [teki-zk03.foo.bar]
ok: [teki-zk02.foo.bar]

TASK [zookeeper : make sure a service is running] ***************************************************************************************************************************************************************************************************************************************************
changed: [teki-zk01.foo.bar]
changed: [teki-zk02.foo.bar]
changed: [teki-zk03.foo.bar]

PLAY RECAP ******************************************************************************************************************************************************************************************************************************************************************************************
teki-zk01.foo.bar          : ok=18   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
teki-zk02.foo.bar          : ok=18   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
teki-zk03.foo.bar          : ok=18   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

주키퍼 설치 성공!!

3. 끝난 줄 알았지만 세 번째 오류

앞에서 한 번 삽질하고 나니 카프카 때는 별 탈 없이 시원하게 설치를 시작했다. 근데 갑자기 중간에서 또 호스트를 찾을 수 없다며 오류를 띄웠다. 심지어 찜찜하게 failed가 아니라 ignored로 처리되었다. 혹시나 하고 카프카 서버에 가서 확인해보니 설치가 안되어있었다.

# 오류
TASK [stop kafka-server] ****************************************************************************************************************************************************************************************************************************************************************************
fatal: [teki-kafka02.foo.bar]: FAILED! => {"changed": false, "msg": "Could not find the requested service kafka-server: host"}
...ignoring
fatal: [teki-kafka03.foo.bar]: FAILED! => {"changed": false, "msg": "Could not find the requested service kafka-server: host"}
...ignoring
fatal: [teki-kafka01.foo.bar]: FAILED! => {"changed": false, "msg": "Could not find the requested service kafka-server: host"}
...ignoring


# 결과
PLAY RECAP ******************************************************************************************************************************************************************************************************************************************************************************************
teki-kafka01.foo.bar       : ok=15   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=1
teki-kafka02.foo.bar       : ok=15   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=1
teki-kafka03.foo.bar       : ok=15   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

구글링해보니 스택오버플로우에서 데몬 reload를 하니까 된다고 했다. 그러고나서 다시 시도해보니까 해결됐다. 뭔가 앞에서 설정을 바꾸고, 또 주키퍼를 설치하면서 설정이 꼬였던 것 같다.

[yt.lim@teki-ansible01 ansible_playbook]$ systemctl daemon-reload
==== AUTHENTICATING FOR org.freedesktop.systemd1.reload-daemon ===
Authentication is required to reload the systemd state.
Authenticating as: root
Password:
==== AUTHENTICATION COMPLETE ===

카프카 설치 완료

앞으로는 귀찮아도 꼭 다 확인해서 두 번 일하지 말자 ㅠㅠ

[Kafka Study] 02. 카프카 기본 개념과 구조 w/실전 카프카 개발부터 운영까지

TEKI — Fri, 4 Mar 2022 01:57:01 +0900

책에서는 2장에서 실습 환경 구성을 하고, 3장부터 실습을 하면서 카프카 기본 개념을 설명한다. 그런데 환경 구성에 필요한 VM 인스턴스만 7개이다 보니 기본 구조와 용어를 먼저 이해하고 구축해보는 게 더 좋겠다는 생각이 들었다. 그래서 이번에는 용어만 간단하게 정리해보았다.

기본 개념과 구조

스터디하는 책의 2~3장과 데브원영님의 <아파치 카프카 애플리케이션 프로그래밍>을 기반으로 내가 이해한 카프카의 구조를 그려보았다. 전체 구조를 이해하기까지 시간이 많이 걸렸는데, 이렇게 그려놓고 보니 생각보다 간단한 구조인 것 같다.

프로듀서Producer : 카프카에 메시지를 만들어서 전달하는 클라이언트를 총칭
컨슈머Consumer : 카프카로부터 데이터를 받아 소비하는 클라이언트
카프카Kafka 또는 카프카 클러스터Kafka Cluster : 프로듀서와 컨슈머 사이에서 메시지 브로커 역할을 하는 애플리케이션 또는 그 클러스터
주키퍼Zookeeper 또는 주키퍼 앙상블Zookeeper Ensemble : 카프카가 정상적으로 동작할 수 있도록 카프카의 메타데이터 저장, 브로커의 노드 관리 등의 역할을 하는 애플리케이션 또는 그 앙상블
브로커Broker : 카프카 애플리케이션이 설치된 서버 또는 노드
토픽Topic : 카프카에서 메시지 피드를 구분하기 위한 저장소
파티션Partition : 병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것
세그먼트Segment : 프로듀서가 전송한 실제 메시지가 로그 파일 형태로 브로커의 로컬 디스크에 저장된 것
메시지Message 또는 레코드Record : 프로듀서와 컨슈머가 브로커에서 전송하거나 읽어가는 데이터 조각
리플리케이션Replication : 각 메시지들을 여러 개로 복제해서 카프카 클러스터 내 다른 브로커에 분산시키는 동작

하나씩 뜯어보기

카프카의 기본 구조를 가장 간단하게 표현하면 이렇게 생겼다. 원래는 주키퍼도 있어야 하는데, Apache Kafka 2.8.0 이후로 주키퍼에 의존성을 모두 제거했다고 한다. 오늘 기준 가장 최근 릴리즈 버전은 3.1이니 훨씬 안정화되었을 것이다.

하지만 주키퍼에 의존성을 제거했다고 주키퍼가 필요 없어진 것은 아니라고 한다. 카프카를 쓰기 위해 주키퍼까지 공부하고 구성해야 하는 리소스가 줄었다는 의미이고, 주키퍼와 카프카를 분리해서 관리해보는 것도 가능해졌다고 이해하면 되겠다. 주키퍼는 카프카와만 통신하기 때문에 구조는 아래와 같다.

프로듀서Producer와 컨슈머Consumer

카프카는 기본적으로 데이터 버스Data Bus 또는 메시지 버스Message Bus 역할을 한다. 그렇기 때문에 메시지를 만들어서 보내주는 프로듀서와 메시지를 가져가서 소비하는 컨슈머가 있어야 그 메시지를 받아서 저장하고, 다시 전달하는 일을 할 수 있다. 이들은 중앙에 위치한 카프카 애플리케이션의 클라이언트로, 프로듀서 클라이언트와 컨슈머 클라이언트라고도 한다.

프로듀서와 컨슈머는 클라이언트 개수에 따라 1:1, 1:N, N:1, N:N의 관계로 나눌 수 있다. 카프카 에코시스템에서는 클라이언트들과 배치 전송 처리 방식으로 높은 성능을 내기 때문에 주로 N:N 관계에서 필요로 한다. 이러한 구조에서 클라이언트 각각 또는 전부를 통칭해서 '프로듀서'와 '컨슈머'라고 부른다.

가장 헷갈렸던 부분인데, 프로듀서와 컨슈머는 원래 메시지를 전송하거나 전달받는 다른 애플리케이션에 붙는 클라이언트 개념이다. 대부분 자바를 사용하고, (다행히) 파이썬으로도 구현이 가능하다고 한다. 그런데 대규모 아키텍쳐를 구축하면서 매번 프로듀서와 컨슈머 클라이언트를 개발하는건 매우 비효율적이다. 그래서 이를 좀 더 수월하게 개발할 수 있도록 도와주는 도구가 바로 카프카 커넥트Kafka Connect이다. 프로듀서 역할을 하는 소스 커넥터Source Connector와 컨슈머 역할을 하는 싱크 커넥터Sink Connector가 있다.

https://debezium.io/documentation/reference/1.3/architecture.html

카프카Kafka 또는 카프카 클러스터Kafka Cluster

카프카는 분산 처리를 하기 때문에 보통 카프카 노드를 3대 이상 구동한다. 이렇게 분산 처리를 하는 카프카 노드들의 그룹을 카프카 클러스터라고 한다. 그리고 카프카 에코시스템에는 하나 이상의 카프카 클러스터를 구축할 수 있고, 이 클러스터들을 주키퍼 앙상블 하나에 연동하기도 한다. 용어의 의미와는 별개로 일반적으로 말하는 '카프카'는 편의상 카프카 클러스터나 카프카 에코시스템을 통칭해서 사용하는 것 같다. 또 하나 카프카와 혼용하는 용어로는 브로커가 있는데, 이건 브로커 순서에서 다시 보자.

주키퍼Zookeeper 또는 주키퍼 앙상블Zookeeper Ensemble

주키퍼도 카프카처럼 일반적인 운영 환경에서는 여러 노드를 가진 클러스터 구조로 구축한다. 주키퍼는 고가용성을 목적으로 replicated mode를 수행한다는 점에서 카프카 클러스터링과 차이가 있다. 이러한 주키퍼 특유의 클러스터 구조를 주키퍼 앙상블이라고 한다. 그러니까 주키퍼 앙상블과 카프카 클러스터의 구조는 아래처럼 생겼다고 볼 수 있다.

브로커Broker

사실 일반적인 메시징 시스템에서 프로듀서와 컨슈머 사이에는 브로커가 있다. 셀러리Celery 브로커를 예로 들면, Redis나 RabbitMQ같은 서비스를 말한다. 이와 달리, 카프카 에코시스템에서는 카프카가 설치된 서버 또는 노드를 브로커라고 부른다. 일반적으로 하나의 브로커에 카프카를 하나씩 설치해서인지 브로커를 카프카라고 부르는 경우가 있다. 혼동하지 않도록 주의!

카프카의 특징으로 확장성을 꼽는데, 여기에는 브로커가 관련되어 있다. 카프카 클러스터의 리소스가 한계에 도달하면 브로커를 추가해서 시스템을 확장할 수 있다. 운영 중에도 자유롭게 확장할 수 있다는 점이 장점으로 꼽힌다.

이렇게 브로커를 여러 대 붙여서 분산 처리를 한다는 것은 쉽게 이해할 수 있다. 그런데 카프카는 토픽과 파티션, 그리고 세그먼트를 통해 더 높은 성능으로 분산 처리를 하고, 리플리케이션으로 안정성을 확보한다. 각 요소의 관계는 아래와 같다.

(이 그림에서만) 각진 사각형은 물리적 공간, 둥근 사각형은 논리적 공간을 의미한다

토픽Topic

카프카에서 프로듀서와 컨슈머가 메시지를 전달하고 전달받는 대상이 바로 이 토픽이다. 토픽은 카프카에서 메시지를 구분하기 위해 사용하는 논리적 단위로, 실제로 메시지가 저장되는 물리적 공간은 하나 이상의 파티션으로 나뉜다. 카프카는 토픽을 기준으로 메시지를 발행하고 소비하기 때문에 하나의 토픽에 속한 메시지들은 논리적으로 같은 주제 또는 문맥(contect)를 가지도록 설계해야 한다.

파티션Partition

위에 말한 것처럼 토픽에 속한 메시지들이 실제로 저장되는 물리적 공간을 파티션이라고 한다. 파티션은 위 그림에서와 같이 브로커 내부에서 하나 이상의 공간으로 나뉘어있다. 독특한 점은 토픽과 파티션이 1:1 또는 1:N의 관계가 아니라 N:N의 관계로 할당된다는 것이다. 위 그림에서는 표현하기 어려워서 한 토픽 안에 여러 파티션이 있는 1:N의 관계처럼 그렸지만, 실제로는 아래 그림처럼 N:N 관계로 저장된다. 이때, 파티션은 카프카 클러스터의 모든 파티션에 골고루 나뉜다는 점이 중요하다. 리더 파티션과 팔로워 파티션으로 설명하는데, 이건 뒤에서 더 자세히 다루기 때문에 나중에 다시 공부해야겠다.

https://www.slideshare.net/PaoloCastagna1/introduction-to-apache-kafka-confluent-and-why-they-matteR

세그먼트Segment

마지막으로 파티션 내부에 저장되는 메시지의 실체인 세그먼트가 있다. 세그먼트는 어떤 물리적 또는 논리적 공간이 아니라 로컬디스크에 log 파일 형태로 저장된 실제 메시지 데이터를 말한다. 구조를 표현한 그림에서 00000.log, 00001.log 등으로 적어놓은 파일들이 세그먼트를 의미한다.

이렇게 카프카는 토픽과 파티션, 세그먼트를 통해 메시지를 관리한다. 여기에서 카프카의 핵심 개념 중 하나인 리플리케이션을 알아야 한다.

리플리케이션Replication

리플리케이션은 메시지 복제본Replica을 여러 개 생성하고, 이를 카프카 클러스터의 여러 브로커에 분산 저장해서 안정성을 확보하는 중요한 동작이다. 토픽을 만들면서 replication-factor 옵션으로 리플리카의 개수를 지정할 수 있다. 카프카에서는 리플리케이션 팩터를 3으로 설정하도록 권장하고 있고, 운영 시에는 목적에 따라 1개에서 3개까지 설정하는 것이 일반적이라고 한다.

데이터가 일부 유실되어도 무관하고, 데이터의 처리 속도가 중요한 경우: 1~2개
금융 정보와 같이 데이터 유실이 일어나면 안 되는 경우: 3개

카프카는 복제한 모든 데이터를 사용하지 않고, 원본과 리플리케이션을 리더Leader와 팔로워Follower로 구분하여 용도를 달리한다. 일반적인 상황에서 프로듀서와 컨슈머의 모든 읽기/쓰기 요청은 리더가 처리한다. 그동안 팔로워는 리더로부터 리플리케이션만 하다가 리더 또는 리더가 있는 브로커에서 문제가 발생하는 등의 경우에 활용된다. 자세한 내용은 4장에서 더 다룬다고 한다.

이제 카프카를 공부할 준비가 된 것 같다. 다음 장에서는 실습 환경을 구축하고, 예제를 통해서 프로듀서와 컨슈머의 기본 동작을 공부할 것이다.

※ Kafka Study 순서 ※

01. 카프카 특징과 이용 사례
02. 카프카 기본 개념과 구조
03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본 동작과 예제
04. 카프카의 내부 동작 원리와 구현
05. 프로듀서의 내부 동작 원리와 구현
06. 컨슈머의 내부 동작 원리와 구현
07. 카프카 운영과 모니터링
08. 카프카 버전 업그레이드와 확장
09. 카프카 보안
10. 스키마 레지스트리
11. 카프카 커넥트
12. 엔터프라이즈 카프카 아키텍처 구성 사례
13. 카프카의 발전과 미래

※ 참고 자료와 이미지 출처 ※

[1] 실전 카프카 개발부터 운영까지, http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791189909345#N
[2] 아파치 카프카 애플리케이션 프로그래밍 with 자바, http://www.kyobobook.co.kr/product/detailViewKor.laf?
[3] kafka강의2 | Topic이란? Pub/Sub 구조, https://pearlluck.tistory.com/289
[4] 동물원을 탈출한 카프카 - Zookeeper-less Kafka, https://psm1782.medium.com/%EB%8F%99%EB%AC%BC%EC%9B%90%EC%9D%84-%ED%83%88%EC%B6%9C%ED%95%9C-%EC%B9%B4%ED%94%84%EC%B9%B4-zookeeper-less-kafka-a71cba58d5d9
[5] [Kafka] 카프카 커넥트, https://velog.io/@ehdrms2034/Kafka-%EC%B9%B4%ED%94%84%EC%B9%B4-%EC%BB%A4%EB%84%A5%ED%8A%B8
[6] [Apache Zookeeper] 주키퍼의 기본 특징, https://jaemunbro.medium.com/zookeeper-%EC%A3%BC%ED%82%A4%ED%8D%BC%EC%9D%98-%EA%B8%B0%EB%B3%B8-%ED%8A%B9%EC%A7%95-7da2a51351c5
[7] [Kafka 101] 카프카 메시지와 토픽과 파티션 (Kafka Message, Topic and Partition), https://always-kimkim.tistory.com/entry/kaafka101-message-topic-partition
[8] Introduction to apache kafka, confluent and why they matter, https://www.slideshare.net/PaoloCastagna1/introduction-to-apache-kafka-confluent-and-why-they-matteR

EasyOCR 돌려보기

TEKI — Thu, 3 Mar 2022 18:36:18 +0900

MLOps를 하다가 문득 모델에 대해 좀 더 알아야겠다고 생각했다. 개인적으로 궁금하기 때문이기도 하지만 내가 어느 정도 모델을 돌려볼 줄 알아야 모델러와 협업 시 더 효율적으로 일할 수 있을 것 같았기 때문이다. 테스트는 아래 순서로 진행해보았다.

웹에서 모델 테스트해보기
Conda 가상환경 준비
EasyOCR 테스트 코드 작성 및 실행
결과 분석

OCR 중에서 가장 유명한 모델이 EasyOCR이라고 한다. 특히 한글은 좋은 모델이 별로 없는데 EasyOCR은 정확도가 상당히 높은 축에 속한다고 한다. 한국인 Contributer가 열심히 개선해주시고 계셔서 그렇다고 들었다. 사실 Clova OCR같이 기업에서 만든 모델도 성능이 좋은 게 있다고 하는데 유료...라서 이번엔 오픈소스인 EasyOCR을 돌려보았다.

코드와 데이터셋: https://github.com/lagunerio/ML-Practice/tree/main/EasyOCR

GitHub - lagunerio/ML-Practice

Contribute to lagunerio/ML-Practice development by creating an account on GitHub.

github.com

1. 웹에서 모델 테스트해보기

EasyOCR은 Jaided AI에서 만들었는데, 모델을 간단하게 돌려볼 수 있도록 데모 툴을 제공한다. 궁금하니까 한 번 해보자.

https://www.jaided.ai/easyocr/

Jaided AI: EasyOCR demo

EasyOCR is a python module for extracting text from image. It is a general OCR that can read both natural scene text and dense text in document. We are currently supporting 80+ languages and expanding. Supported Languages LanguageCode Name Abazaabq Adyghea

www.jaided.ai

위 사이트로 들어가면 된다. 툴 자체는 굉장히 단순하다. 이미지 파일을 업로드하고, 인식할 언어 코드를 입력해주면 된다. 다만 데모 버전인 만큼 제약이 있다.

업로드 가능한 파일: png, jpg, tiff
파일 크기: 2mb 이하
이미지 픽셀: 1500픽셀 이하

Jaided AI의 EasyOCR 데모 툴 화면 스크린샷을 모델에 돌릴 수 있도록 1024*1024로 조정한 사진

툴을 캡쳐한 위 사진을 모델에 돌려보자. 이미지를 먼저 올려주고, 영어와 한글이 섞여있으니까 Step 2에는 en과 ko를 입력해준다. 그리고 Process 버튼을 누르면 아래와 같이 결과가 나온다. 글자 위치는 잘 인식했지만, OCR 결과는 조금 실망스럽다.

왼쪽 사진은 결과 화면이고, 오른쪽 표는 화면 아래쪽에 출력된 결과를 가져온 것이다

2. Conda 가상 환경 준비

모델마다 요구하는 라이브러리 종류와 버전이 다르므로 conda와 같은 툴로 가상 환경을 구성해서 모델을 돌리는 게 편하다. miniconda를 미리 설치해두어서 easyocr이라는 가상 환경만 새로 만들어주었다. 안정적으로 사용하려면 파이썬 버전을 3 이상으로 설정해야 한다고 알고 있다. 정확하게 버전 몇 이상이어야 하는지는 잘 모르겠다.

$ conda create -n easyocr Python=3.8 -y

그다음 새로 만든 환경에 들어가서,

$ conda activate easyocr

pip로 easyocr를 설치해주었다.

$ pip install easyocr

easyocr은 OpenCV를 사용하는데, 이게 버전이 안 맞아서 Segmentation Fault 오류가 생겼었다. 찾아보니 known issue인 것 같다. 필요한 버전에 맞게 미리 설치해주자.

$ pip install opencv-python-headless==4.5.4.60

참고: https://github.com/JaidedAI/EasyOCR/issues/633

segmentation fault (core dumped) · Issue #633 · JaidedAI/EasyOCR

I get this error out of nowhere for some reason python version is 3.9.4 Fatal Python error: Segmentation fault Current thread 0x00007fdc6aa93b80 (most recent call first): File "/home/linuxbrew...

github.com

준비 끝!

3. EasyOCR 테스트 코드 작성 및 실행

기본 코드는 아래와 같다. 모델을 실제로 돌릴 땐 필요에 맞게 코드를 수정했다.

import easyocr

reader = easyocr.Reader(['en'], gpu=False)
DATAPATH = "/이미지/파일/경로.jpg"
result = reader.readtext(DATAPATH)
print(result)

1. 언어 모델 선택

EasyOCR은 기본적으로 80개가 넘는 언어를 지원한다. 각 언어는 소문자 알파벳과 언더바(_)로 이루어진 코드 이름으로 Reader에게 알려준다.

reader = easyocr.Reader(['en'], gpu=False)	# English
reader = easyocr.Reader(['ko'], gpu=False)	# Korean
reader = easyocr.Reader(['en', 'ko'], gpu=False)	# English and Korean
reader = easyocr.Reader(['en', 'ko', 'es', 'de'], gpu=False)	# English, Korean, Spanish, and German

2. 컴퓨팅 리소스 선택: CPU 또는 GPU

GPU가 없어도 EasyOCR 돌릴 수 있다. 뭘로 할지에 따라 gpu 파라미터를 바꿔주면 된다.

reader = easyocr.Reader(['en'], gpu=False)	# CPU 사용
reader = easyocr.Reader(['en'], gpu=True)	# GPU 사용

3. 데이터셋 준비

다양한 형식으로 글자가 들어가있는 이미지를 준비해보았다.

모두 여러 웹사이트에서 직접 캡쳐한 데이터이다.

4. 사용한 코드

테스트 환경에는 GPU가 없어서 CPU를 사용했고, 영어와 한글을 인식하도록 세팅했다. 또, 결과 분석을 위해 데모 툴에서와 같이 이미지에 인식한 결과(글자)를 써주는 로직을 추가했다.

글자 폰트는 네이버에서 제공하는 나눔고딕체를 사용
폰트 크기는 직접 테스트해본 후 적당한 크기(30)로 설정
모델에서 detect 한 바운딩 박스의 좌상단 좌표를 기준으로 왼쪽으로 10픽셀, 오른쪽으로 10픽셀 이동한 위치에 글자를 입력
글자 색은 눈에 잘 띄도록 붉은색(255,0,0)으로 설정

import os
import easyocr
from PIL import Image, ImageDraw, ImageFont

reader = easyocr.Reader(['en', 'ko'], gpu=False)
DATAPATH = "/이미지파일이/저장된/위치"

font_size = 30
font = ImageFont.truetype("/폰트파일이/있는/위치/NanumGothic.ttf", font_size, encoding="UTF-8")

for image in os.listdir(DATAPATH):
	image_path = os.path.join(DATAPATH, image)
	if os.path.isfile(image_path):
		result = reader.readtext(image_path)
		img = Image.open(image_path)
		for r in result:
			x, y = min(list(_[0] for _ in r[0])), min(list(_[1] for _ in r[0]))
			text_data = r[1]
			d = ImageDraw.Draw(img)
			d.text((x-10,y-10), text_data, font=font, fill=(255,0,0))
		img.save(image_path+"-result.png")

4. 결과 분석

아래와 같이 위 프로그램으로 만든 이미지와 원본 이미지를 비교해보았다.

결과를 보니 한글 모델은 아인슈타인을 '야이숙타인'처럼 읽는 등 이중 모음에 약하긴 하지만 그래도 정확도가 높은 편이다. 특히, 논문 초록이나 위키피디아처럼 줄글로 되어있으면 오타를 충분히 인지할 수 있을 만큼 정확도가 높다. 하지만 따옴표 같은 특수문자는 "를 66으로 읽는 등 거의 인식하지 못하는 것 같다. 영어는 그 수가 많지 않아서 평가하기 어렵지만, 일반적인 글씨는 상당히 잘 인식하는 것 같다.

회사 상표 인식 결과가 가장 정확도가 낮은데, 폰트가 일정하지 않고 디자인 요소가 많다보니 오류가 많다. 글자를 특수문자로 인식하거나, 언어를 잘못 인식하는 경우, 또는 글자를 아예 인식하지 못하는 경우 등 정확도가 많이 떨어진다.

이미지만 보면 Confident Score까지 비교하지 못하기 때문에 찍어서 맞춘 비율이 얼마나 있는지 확인하지 못했다. 다음에 좀 더 상세하게 분석해보아야겠다.

[Kafka Study] 01. 카프카 특징과 이용 사례 w/실전 카프카 개발부터 운영까지

TEKI — Tue, 1 Mar 2022 18:50:23 +0900

"카프카를 공부할 거야"라고 했더니 "갑자기 프란츠 카프카는 왜?"라는 말을 들었다. 그 카프카가 아니라 다른 카프카라고 설명하려는데 말문이 막혔다. 대용량 데이터를 처리할 때 쓰는 건데, 그러니까... 이제부터 공부하려고! 라고 얼버무리고 보니 이 정도로 아는 게 없다는 게 부끄러웠다. 그래서 카프카 스터디를 시작하기에 앞서 카프카가 왜 중요한지 알아보았다. 스터디는 책만 출판사의 <실전 카프카 개발부터 운영까지>를 기반으로 진행하고, 공부하면서 참고한 자료는 하단에 첨부해놓았다.

카프카 Kafka

아파치 카프카는 정말 프란츠 카프카Franz Kafka에서 따온 이름이라고 한다. 아파치 카프카를 만든 제이 크렙스Jay Kreps가 평소에 프란츠 카프카를 존경했다고.. 아무튼, 카프카 소개를 찾아보면 이 세 가지 키워드가 눈에 띈다.

1. 이벤트 기반 Event Driven
2. 대규모 데이터
3. 스트리밍 또는 실시간 처리

이게 왜 그렇게 특별할까?

1. 이벤트 기반 Event-Driven

카프카가 표준화가 되는 과정의 시작점에는 기업들이 이벤트 기반 시스템(EDA)으로 전환하려는 움직임이 있다. 데이터의 절대량이 증가하는 것과 동시에 실시간 데이터 활용에 대한 수요와 데이터에 대한 다양한 요구사항이 증가하면서 많은 기업은 이벤트 기반 시스템으로 전환하고자 했다. 그 과정에서 기업들이 당면한 문제를 해결할 수 있는 답으로 카프카만 한 것이 없었다.

2. 대규모 데이터

카프카는 여러 개의 메시지 큐를 기반으로 한 분산 시스템이다. 또한, 카프카는 배치Batch 전송이 가능하다. 이 두 가지 특성을 모두 가졌기 때문에 카프카는 대규모 데이터를 빠르면서도 안정적으로 처리할 수 있다. 시간이 갈수록 기업에서 하루에 감당해야 하는 데이터는 상상을 초월하는 규모로 커지고 있다. 이를 제시간에 올바르게 처리하려면 기존의 데이터 파이프라인으로는 한계가 많았고, 카프카가 그 대안이 되어주고 있다. 그래서 카프카는 엔터프라이즈급 아키텍처에서 거의 필수 요소로 꼽힌다. 이런 특성을 만들어낸 카프카의 구성 요소(파티션, 세그먼트 등)나 프로듀서Producer와 컨슈머Consumer, 브로커Broker 등의 자세한 구조는 3장에서 설명하고 있어서 3장을 공부할 때 더 자세히 정리해보겠다.

3. 스트리밍 또는 실시간 처리

카프카에는 '실시간 이벤트 데이터 전달', '실시간 스트리밍 데이터 처리' 등 여러 수식어를 붙인다. 표현은 다 달라도 하고자 하는 말은 하나다. 아파치 카프카는 서버 내에서 요청을 실시간으로 빠르게 처리하는 데에 탁월하다는 것이다. 시간이 갈수록 하루에 처리해야 하는 요청이 기하급수적으로 증가하는 상황에서 이러한 실시간 처리 성능이 꼭 필요하기 때문에 카프카는 점점 없어서는 안 되는 서비스로 자리매김하고 있다. 이와 유사한 특성을 가진 서비스에는 Apache Spark, RabbitMQ, AWS Kinesis 등 몇 가지가 더 있다고 하는데(참고), 카프카를 공부한 후에 이들 간에 어떤 차이가 있고, 언제 무엇을 어떻게 써야 할지 알아보아야겠다.

카프카의 탄생

전공 서적을 볼 때면 어떤 것을 공부하든 왜 항상 역사를 제일 먼저 알려주는지 궁금했었다. 'C언어는 1972년 벨 연구소의 데니스 리치가 만들었다'라는 설명과 printf("Hello World!");를 실행하는 것은 전혀 관련이 없어 보였기 때문이다.

이 생각이 바뀐 건 Airflow나 카프카같은 비교적 최근에 등장한 서비스를 찾아보면서부터다. 카프카를 들어본 사람은 대부분 카프카가 링크드인에서 만들었다는 걸 알고 있다. 정확하게는 링크드인에서 근무하던 제이 크렙스Jay Kreps와 준 라오Jun Rao, 네하 나크헤데Neha Narkhede가 데이터 파이프라인 구축/운영의 여러 문제점을 해결하기 위해 카프카를 만들었다고 한다. 예전과 다르게 역사 이야기가 흥미로운 이유는 링크드인은 지금까지도 많은 사람이 사용하고 있는 플랫폼이고, 또 수많은 기업에서 유사한 문제가 일어나기 시작하면서 카프카에 더 많은 관심을 쏟고 있기 때문이다.

좀 더 알아보자면 이 세 창시자는 카프카를 2011년에 아파치 오픈소스로 공개했고, 링크드인에서 이룩한 성공을 발판 삼아 2014년에 Confluent라는 회사를 설립하여 카프카를 발전시키고 있다고 한다. 그래서 현재 카프카는 Apache Kafka와 Confluent Kafka 둘로 나뉘어있으며, 일반적으로 말하는 '카프카'는 아파치 카프카를 의미한다고 한다. 이 두 카프카의 차이점은 '한국 카프카 사용자 그룹'에서 개최한 2021년 제1회 온라인 밋업 'Apache Kafka & Confluent Platform의 새로운 기능 및 로드맵' 발표 영상에서 참고할 수 있다.

사용 사례와 주요 특징

위에서 카프카는 링크드인에서 데이터 파이프라인 구축/운영 중 발생한 문제를 해결하기 위해 만들었다고 했다. 그 문제에는 데이터 파이프라인 확장의 어려움, 이기종간의 호환성, 고성능 시간의 실시간 데이터 처리의 어려움 등이 있는데, 현재까지도 여러 기업에서 유사한 문제를 해결하기 위해 카프카를 사용하고 있다.

유럽의 온라인 쇼핑몰 잘란도Zalando는 2015년부터 연평균 24%의 성장률을 보이며 2020년 기준 실 사용자 3,100만 명, 연간 주문 수 1억 4,500만 건을 기록하였다. 이 과정에서 내부적으로 데이터에 대한 수많은 요구사항과 문제에 대한 해결 방안이 필요했다. 잘란도는 기존 시스템을 데이터의 변화가 스트림으로 컨슈머 측에 전달되는 이벤트 드리븐 시스템으로 전환하기로 했고, 그 과정에서 몇 가지 핵심 과제를 중점적으로 고민했다고 한다.

먼저 인바운드 데이터와 아웃바운드 데이터가 일치해야 한다는 점에 주목했다. 그리고 CRUD 타입 통신 시 발생하는 데이터 정합성 문제와 데이터 수정 순서를 보장해야 하는 문제, 대량 배치 전송을 빠르게 처리하기 어려운 점 등에서 한계를 느끼고 있기도 했다. 잘란도는 카프카 기반의 느슨하게 결합된 이벤트 드리븐 시스템과 애플리케이션을 구축하여 비동기 방식으로 데이터를 처리하였고, 카프카 스트림즈Kafka Streams를 이용해 실시간 도메인 랭킹 시스템을 구축하기도 했다.

성공적으로 카프카를 적용했던 잘란도와 달리 트위터Twitter는 과거에 카프카를 적용했다가 I/O 오퍼레이션 문제와 기능의 불안정성으로 카프카를 포기하고 인하우스 메시지 시스템(이벤트 버스)을 구축했었다고 한다. 하지만 그 이후로 카프카는 고가용성과 높은 처리량, 빠른 응답 시간을 안정적으로 확보하였고, 카프카가 Pub/Sub 모델을 지원하여 수평 확장이 용이해졌다. 그리고 많은 기업에서 카프카를 사용하면서 강력한 커뮤니티가 생성되자 트위터는 2018년 경 내부적으로 카프카 성능 테스트를 수행했고, 카프카의 성능이 이벤트 버스 성능을 넘어서는 것을 확인하였다. 이를 기점으로 트위터는 고객 데이터를 다시 카프카로 옮겼다.

https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story

그 외에도 다양한 분야의 수많은 기업에서 이벤트 기반 시스템으로 전환하면서 카프카를 선택했다. 넷플릭스Netflix는 전 세계 규모의 네트워크 환경에서 데이터를 수집, 통계, 처리, 적재하기 위한 파이프라인을 연결해주는 역할로 카프카를 사용하고 있다. 또 우버Uber는 탑승자와 운전자의 모바일 앱, GPS, 지도 서비스 등의 데이터 프로듀서로부터 이벤트 데이터를 수집하기 위해 카프카를 사용하였다. 머신러닝 분야에서도 모델과 상용 앱에 피처Feature 데이터를 전송하는 플랫폼으로 카프카를 사용하는 사례가 있다. 또 스마트 시티의 IoT 기기들이 이벤트 기반 시스템에서 안정적으로 구동할 수 있도록 카프카를 사용하기도 한다.

https://www.slideshare.net/ConfluentInc/benefits-of-stream-processing-and-apache-kafka-use-cases

이렇게 많은 기업들이 카프카를 선택한 이유를 보면 몇 가지로 축약된다.

1. 높은 처리량과 낮은 지연시간
2. 높은 확장성
3. 고가용성과 내구성(또는 영속성)
4. 개발·운영·관리 편의성

1. 높은 처리량과 낮은 지연시간

카프카는 전통적인 메시징 큐 시스템인 RabbitMQ에 비해 End-to-End 응답 속도는 느리지만, 처리량에서는 몇 배의 성능을 보여준다. 즉, 대용량 데이터를 실시간으로 처리해야 하는 시스템에서는 카프카가 훨씬 나은 선택이다. 아래는 Confluent에서 측정한 카프카와 Pulsar, RabbitMQ의 처리량과 응답 지연 시간 비교 결과이다. 더 자세한 성능 비교 분석 결과는 여기에서 확인할 수 있다.

https://www.confluent.io/blog/kafka-fastest-messaging-system/

2. 높은 확장성

링크드인에서 기존에 사용하던 ActiveMQ는 확장성이 낮아서 링크드인 비즈니스 성장에 따라 급격히 증가하는 스트림 데이터에 대응하기 어려웠다고 한다. 그래서 카프카 개발 초기부터 손쉽게 scale-in, scale-out 할 수 있는 구조로 설계했다고 전해진다. 이 과정은 무중단으로 적용이 가능하다는 장점이 있지만 그만큼 카프카의 여러 옵션에 대해 잘 알아야 하고, 또 더 많은 장애에 대응해야 해서 점점 더 까다로워진다고 한다. 이에 대해서는 8장에서 다룬다고 하니 그때 더 자세히 알아보아야겠다.

3. 고가용성과 내구성(또는 영속성)

대규모 데이터 처리를 실시간으로 운영하는 데에 있어서 고가용성을 갖추는 것은 아주 중요하고, 또 어려운 일이다. 카프카는 클러스터 내에 리플리케이션replication, 즉 복제 기능을 추가하면서 높은 가용성을 확보했다고 한다. 프로듀서로 전달받은 데이터를 여러 브로커 중 한 대에서만 가지고 있지 않고 다른 브로커에도 복제하여 장애 발생 시에도 지속적으로 데이터 처리가 가능하도록 한 것이다.

그리고 카프카에서는 프로듀서의 acks 옵션을 사용하여 카프카로 전송되는 모든 메시지를 로컬 디스크에 안전하게 저장할 수 있다. 이를 통해 컨슈머가 메시지를 가져감과 동시에 메시지가 삭제되었던 기존의 메시징 시스템과 달리 과거의 메시지를 다시 불러올 수 있어 장애나 버그 발생 시 문제가 발생했던 요청들을 복구 및 재처리할 수 있다. 이러한 특징에 대해서는 4장에서 더 자세히 다룬다고 한다.

4. 개발·운영·관리 편의성

카프카는 프로듀서와 컨슈머가 서로 완벽히 분리되어 동작하므로 각각 개발 및 운영이 용이하다고 한다. 또, 카프카 커넥트Kafka Connect와 스키마 레지스트리Schema Registry라는 애플리케이션을 제공하여 개발 편의성을 높여준다고 한다. 카프카 커넥트는 프로듀서와 컨슈머를 따로 개발하는 대신 소스 커넥트Source Connect와 싱크 커넥트Sink Connect를 통해 메시지를 보내고 받을 수 있도록 하는 애플리케이션이고, 스키마 레지스트리는 스키마를 미리 정의하여 데이터 파싱 리소스를 줄일 수 있도록 도와주는 애플리케이션이라고 한다. 자세한 내용은 5,6, 그리고 8장에서 상세하게 다룬다고 한다.

책에서는 2장에서 실습 환경을 구축한다. 그런데 그보다 먼저 기본 용어와 구조를 알아보려고 한다. 그 다음 환경을 구성하고, 실습을 진행할 것이다.

※ Kafka Study 순서 ※

01. 카프카 특징과 이용 사례
02. 카프카 기본 개념과 구조
03. 카프카 실습 환경 구성 및 프로듀서와 컨슈머 기본동작과 예제
04. 카프카의 내부 동작 원리와 구현
05. 프로듀서의 내부 동작 원리와 구현
06. 컨슈머의 내부 동작 원리와 구현
07. 카프카 운영과 모니터링
08. 카프카 버전 업그레이드와 확장
09. 카프카 보안
10. 스키마 레지스트리
11. 카프카 커넥트
12. 엔터프라이즈 카프카 아키텍처 구성 사례
13. 카프카의 발전과 미래

※ 참고 자료와 이미지 출처 ※

[1] 링크드인은 왜 카프카를 만들었나, https://www.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS9400468504
[2] Top 15 Kafka Alternatives Popular In 2021, https://www.spec-india.com/blog/kafka-alternatives
[3] 아파치 카프카 애플리케이션 프로그래밍 with 자바, http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791165920548
[4] Apache Kafka & Confluent Platform의 새로운 기능 및 로드맵, https://www.youtube.com/watch?v=_Kk1r_qFbMQ
[5] Benfits of Stream Processing and Apache Kafka Use Cases, https://www.confluent.io/online-talks/benefits-of-stream-processing-and-apache-kafka-use-cases-on-demand/
[6] Benchmarking Apache Kafka, Apache Pulsar, and RabbitMQ: Which is the Fastest?, https://www.confluent.io/blog/kafka-fastest-messaging-system/
[7] Twitter's Kafka adoption story, https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitters-kafka-adoption-story

「내 문장이 그렇게 이상한가요?」 / 김정선 지음 / 유유 출판 / 2016년 출간

TEKI — Mon, 14 Feb 2022 23:38:02 +0900

내 문장이 그렇게 이상한가요? 내가 쓴 글, 내가 다듬는 법
김정선 지음 | 유유 | 2016년 01월 24일 출간

가볍게 책 한 권 읽어보려고 리디 셀렉트를 열었는데 이 책이 보였다. 리뷰에는 책 내용이 알차다는 평이 많았고, 이북이 보기 어려워서 종이책을 샀다는 사람들도 눈에 띄었다. 궁금해져서 읽어본 책인데 내용이 정말 알찼다.

리포트, 이메일, 블로그 포스팅, 또는 PPT 발표 자료를 제작하면서 맞춤법 검사기는 필수다. 영어는 Grammarly를, 한국어는 나라인포테크의 맞춤법 검사기를 사용한다. 검사기를 오래 사용하다 보면 내가 잘못 쓰는 표현이 어느 정도 정해져 있는 게 보인다. 단골손님인 '어느정도'는 이제는 좀 맞게 쓸 때도 됐건만 여전히 한 번씩 틀리게 적는다. 이처럼 많이 틀리는 표현이나 좋지 않은 표현을 스무 가지도 넘게 알려준다. 그리고 문장 구성을 더 잘하는 방법도 이해하기 쉽도록 예시를 들어가며 설명해준다. 그 무엇보다도 업무 이메일이나 메신저 대화, 또는 문서 작성 등 공적인 자리에서 큰 도움이 될 것 같다. 또, 일상생활에서 문장을 명료하게 쓰면 의사소통이 수월해지고, 말에 품위가 생긴다는 장점이 있으니 한 번 더 읽어보며 익혀야겠다.

대학생 연구/개발 프로젝트 도전하기 - ICT멘토링 (~2022.3.31)

TEKI — Tue, 8 Feb 2022 01:28:08 +0900

2022년 ICT멘토링 신청기간이라고 메일이 왔다. 도전해보고 싶은 개발/연구 프로젝트 주제가 많은데 아쉽게도 멘티에는 대학생만 지원할 수 있다. 대신 나처럼 프로젝트 경험이나 논문 제출, 특허 등록 경험을 쌓고 싶은데 물적/인적 도움을 받고 싶은 대학생들에게 알리고 싶어서 블로그에 소개해본다. 보는 사람은 얼마 없겠지만, 한 명에게라도 도움이 되면 좋겠다.

개발 프로젝트나 논문 제출을 하면서 가장 어려운 두 가지는 '주제 정하기'와 '팀원 구하기'다. 그래서 직접 참여해본 경험을 바탕으로 몇 가지 팁을 자세하게 적어보았다. 기한 내에 신청서 제출이 아닌 멘토와 멘티 매칭이 되어야 참여할 수 있다는 점을 참고해서 신청을 하면 좋겠고, 또 필요한 것들을 정말 아낌없이 지원해주고 있기 때문에 꼭 도전해보면 좋겠다!

ICT?

ICT(Information & Communications Technology)는 정보 통신 기술을 뜻한다. ICT멘토링에서 세분화한 프로젝트의 주제와 기술 분류 항목을 보면 좀 더 이해하기 쉽다.

ICT멘토링 프로젝트가 뭔데?

과학기술정보통신부에서 말하는 이 프로젝트의 목적은 "실무 밀착형 프로젝트 수행을 통한 실무역량 강화 및 실전과 개발이론을 겸비한 문제해결형 인재양성"이다. 이론만 공부해서는 실무에 적응하기 어려우니, 학생들에게 실무 경험을 제공하자는 취지인 것으로 보인다.

실무 경험을 쌓는 것과 관련해서는 이 프로젝트 이름이 'ICT프로젝트'가 아닌 'ICT멘토링'이라는 데에 주목할 필요가 있다. 이 프로젝트에는 꼭 멘토와 멘티가 매칭 되어야 참여할 수 있다. 그리고 멘티에는 대학생만, 멘토에는 실무자만 가능하다. 멘토와 멘티의 참여 자격을 보면 프로젝트가 목적에 굉장히 충실히 하고 있다는 게 느껴진다.

뭐가 좋은데?

프로젝트에서 해주는 지원을 잘 이용한다면 정말 많은 도움을 받을 수 있다. 내가 생각하는 멘티의 이점은 크게 팀원 및 프로젝트 주제 구성, 멘토링, 장비 지원, 오프라인 미팅 공간 지원, 특허/논문 등록 지원, 그리고 블렌디드 러닝이 있다.

1. 우선 가장 어려운 프로젝트 주제 선정과 팀원 모집, 그리고 멘토 매칭을 도와준다. 프로젝트 주제만 있으면, 누구나 그 프로젝트에 참여할 수 있도록 시스템을 갖추고 있어서 함께할 팀원이나 멘토가 없더라도 전혀 문제가 없다. 반대로 프로젝트 주제가 없어도 다른 멘티나 멘토의 프로젝트에 참여할 수 있다.

2. 그리고 프로젝트 주제를 중심으로 멘토와 멘티를 매칭하기 때문에 멘토들은 그 프로젝트 주제에 관련해서 전문가라고 볼 수 있다. 즉 프로젝트를 진행하면서, 그리고 프로젝트 이후로도 큰 도움을 받을 수 있는 소중한 멘토라는 뜻이다. (혹시나 멘토가 불성실할까 걱정할 수 있는데, 일정 횟수만큼 미팅을 하고 보고서를 제출해야 멘토 활동 수당을 지급하기 때문에 걱정하지 않아도 된다.)

3. ICT 프로젝트를 수행하면서 은근히 많은 비용이 들어간다. 단순한 소프트웨어 개발을 하더라도 서버 비용이 필요하고, 앱 개발을 한다면 테스트용 모바일기기가 필요하다. IoT와 같이 하드웨어가 필요한 경우는 물론이다. ICT멘토링에서는 실습 장비와 클라우드 서버 비용을 최대 130만원까지 지원해준다. 또한, 에뮬레이션(스마트폰, 태블릿 등 클라우드 기반 테스팅 툴)과 오프라인 팀 미팅을 위한 미팅 공간과 교통비를 멘티와 멘토 모두에게 지원해준다. 추가로, 소프트웨어 개발의 경우 ICT멘토링에서 GitLab을 제공하는데 이걸 위해서 Git 교육도 해준다. 정말 친절하다!

4. 대학생이 특허를 등록하거나 논문을 제출할 기회는 흔치 않다. 그래서 이 프로젝트의 가장 큰 특징 중 하나로 특허/논문 등록 지원을 꼽는다. 개인적으로는 이 프로젝트의 목표를 특허 등록이나 논문 제출로 설정해도 좋겠다고 생각한다. 논문을 어떻게 쓰는지 zoom으로 가르쳐주고, 검토도 해준다. 또, 특허 등록 비용도 지원해준다. 그 외에도 다양한 성과 등록을 지원해준다. 자세한 항목은 아래에 첨부했다.

이만큼 좋은 경험이 없으니 가능하면 꼭 해보자!

5. 마지막으로 블렌디드 러닝이 있다. 즉, 온라인 교육을 지원해준다. 부족한 부분을 공부하면서 프로젝트를 진행할 수 있도록 도와주려는 취지이다. 2021년 한이음 ICT멘토링에 참여했을 땐, <스파르타 코딩클럽> 수강권을 지원해주었다. 팀원 당 강좌를 1~3개씩 수강할 수 있었는데, 대신 한 강좌를 완주해야 다음 수강신청을 할 수 있는 시스템이서 수강권을 낭비하는 일은 거의 없었던 것 같다. 그렇다고 해도 만약 팀원 5명이 강좌 2개씩을 들었다면 3~400만원이 훌쩍 넘는 비용인데.. 정말 아낌없이 지원해주는 것 같다.

어떤 프로젝트를 해야 할 지 모르겠다면

이미 연구/개발을 하고 싶었던 주제가 있다면 고민 없이 지원하면 된다. 하지만 '프로젝트를 수행해보고 싶지만, 어떤 주제로 해야 할지 모르겠다'는 케이스가 더 많을 것 같다. 이럴 땐, 다른 팀에서 어떤 주제로 연구/개발을 진행했는지 보고 참고하는 것이 도움이 된다. ICT멘토링 사이트 > 참여하기 > 프로젝트 참여하기에는 과거부터 현재까지 진행한 모든 프로젝트를 확인할 수 있다. 그래도 모르겠다면 다른 사람들의 프로젝트에 참여할 수 있다. 이 방법은 뒷부분에 자세하게 적어놓았다.

(좌)올해는 아직 신청중이어서 프로젝트가 많이 없다. (우)과거에 마감한 프로젝트를 참고해보면 좋을 것 같다.

팀원을 구하기가 어렵다면

프로젝트를 하고 싶은 의지와는 별개로 팀원을 찾는 일은 항상 어렵다. 그 점을 배려해서 프로젝트 신청 과정에서 팀원을 모집할 수 있도록 지원한다. ICT멘토링에 지원하려면 최소 3명에서 최대 5명으로 구성된 팀이 필요하다. 하지만 프로젝트를 등록할 때 팀원이 다 없어도 괜찮다. 먼저 프로젝트 수행계획서를 작성해서 프로젝트 등록을 하면, 누구든 그 수행계획서를 보고 팀원으로 신청할 수 있다.

프로젝트 주제 선정이 어렵다면, 멘토가 등록한 프로젝트를 찾아보는 것도 좋은 방법이다. 의외로 많은 멘토님들이 프로젝트를 신청한 후 멘티를 모집하신다. 이런 프로젝트는 실무와 관련된 주제일 확률이 높기 때문에 추천한다.

'멘티를 구합니다'로 필터링해서 검색해보자

참여하고 싶은 프로젝트 상세 페이지에 들어가면 제일 아래에 [프로젝트 신청내역]이 있다. 목록의 오른쪽에 [파트너신청]이라고 적힌 파란색 버튼을 눌러 참여 신청을 할 수 있다. (이 버튼은 로그인을 해야 보인다). 멘토와 멘티 신청 내역은 모두 목록에서 확인이 가능하고, 프로젝트 개설자가 승인 또는 반려를 할 수 있다. 신청서에는 본인이 수행할 수 있는 역할, 지원 동기를 200자 이상씩 필수로 적어야 하는데, 프로젝트 개설자가 이 내용을 보고 승인 또는 반려를 하기 때문에 최대한 성실하게 작성해주자.

오른쪽 파트너신청 버튼은 홈페이지에 로그인을 해야 보인다.

본인 개발 블로그나 Git 등을 공유하는 것도 좋은 방법이다.

프로젝트에 신청하기 전에 프로젝트 상태가 [신청중]인지 확인해야 한다. 인기 있는 주제는 팀원 모집이 빨리 끝나기 때문에 너무 오래 고민하면 신청을 못할 수 있다. 또, 여러 프로젝트에 동시에 신청할 수 있기 때문에 프로젝트 개설자들은 같이 하고 싶은 멘티나 멘토가 나타나면 빨리 승인해주어야 한다. 우리 팀은 망설이는 사이에 좋은 멘토님을 한 분 놓쳐버렸었다ㅠㅠ

프로젝트 현황 페이지에서 신청자 수 확인 버튼을 누르면 프로젝트마다 멘티와 멘토 신청자 수를 확인할 수 있다

한이음, 프로보노, 이브와, 그리고 스마트해상물류

나는 한이음 트랙에 참여했었다. 그 외에도 3개의 트랙이 더 있다. 트랙별로 프로젝트 주제와 참여 방식 및 참여 요건에 차이가 있다. 아예 다른 프로젝트인 줄 알았는데 OT나 공지사항 안내, 오프라인 미팅 장소 선정 등 대부분의 활동을 같이 진행했다. 다만 주제가 다르니 대회나 성과 발표 등을 별개로 진행했다. 마치 수학여행에서 밥은 다 같이 먹지만 사진은 반별로 찍었던 느낌이었다.

내가 참여했던건 순수하게 프로젝트만 진행하는 자율형이지만, 산업체 연계형과 학점 연계형처럼 특수한 유형도 있다. 상세한 규정과 관련해서 참고할 수 있도록 자료를 첨부한다.

2022년 ICT멘토링 모집공고

2월 4일부터 3월 31일까지 참여 대학생을 모집한다. 프로젝트 개설 후 멘토와 멘티 모집이 완료되어야 신청이 된다는 점을 꼭 고려하자. 참고로 팀 구성 완료된 순서로 선착순 70팀에게 스타벅스 3만원 쿠폰을 준다고 하는데 아직 70팀이 안된 것 같다(2월 8일 기준).

ICT멘토링 홈페이지
한이음 ICT멘토링 공지사항
프로젝트 개설 이벤트 공지사항 (스타벅스 3만원 쿠폰)

2022년_ICT멘토링_프로젝트_모집_공고문.pdf

0.28MB

별첨2_22년_ICT멘토링_참여_FAQ.pdf

「리버스 엔지니어링 기드라 실전 가이드」/ 나카지마 쇼타 외 3인 지음 / 한빛미디어 출판 / 2022년 출간

TEKI — Sun, 6 Feb 2022 19:14:05 +0900

리버싱을 시작할 때 가장 어려웠던 건 내가 가진 정보를 어디서부터 어디까지를 어떻게 해석하고 분석해야 하는지 깨닫는 과정이었다. 그런 내가 느꼈던 이 책의 가장 큰 장점은 분석 과정을 그대로 따라만 가면 될 정도로 상세하게 설명해준다는 점이다. 어떤 버튼을 눌러야 하는지부터, 분석 결과와 그에 대한 분석까지 리버싱의 모든 과정을 하나하나 설명해준다 (900페이지에 걸쳐서).

학교에서 리버싱을 공부할 땐 컴퓨터에 용이 아닌 여인의 얼굴이 하나씩 있었던 기억이 난다. 지금은 전공과 다른 직무로 일을 시작해서 기드라를 써볼 일이 없었다. 그래서 이 책을 받고 다시 학생의 마음으로 돌아가서 이번엔 기드라로 리버싱을 공부해보았다.

" 기드라는 미국 국가안보국(NSA)에서 개발 후 2019년에 공개한 오픈소스 소프트웨어 리버스 엔지니어링 도구이며, Windows/MacOS/Linux 등 환경에 상관없이 동작하는 크로스 플랫폼 소프트웨어이다. "

기드라는 NSA에서 개발했다는 이유로 2019년 공개 직후 폭발적인 관심을 받았었다. 그랬던 만큼 취약점 분석이 적극적으로 이루어졌는지, 공개되고 며칠 지나지 않아 취약점이 발견됐었다고 한다. 그 이후로는 IDA Pro와 Ghidro 모두 리버스 엔지니어링 툴로 꾸준히 인기 있는 것 같다.

사실 여느 분야와 마찬가지로 어떤 도구를 사용하느냐보다는 어떤 분석을 하느냐가 더 중요하다. 그리고 개인적으로 도구를 사용하는 방법은 책 보다 구글과 실전으로 익히는 것을 선호한다. 그래서 이 책에 대한 기대는 사실 반반이었는데, 실제로 읽어보니 '기드라 가이드'가 아닌 '정적 분석 실습 가이드'라고 봐도 무방하게 느껴졌다.

리버스 엔지니어링 실무자가 아니다 보니 이 책이 리버싱을 얼마나 깊이 있게 다루는지, 또는 실무에 얼마나 도움이 되는지를 평가하기는 어렵다. 하지만 마치 전공 수업을 듣는 것처럼 이론부터 실습까지 체계적으로 공부할 수 있는 책이었다. 그러니 적어도 나처럼 리버싱을 공부하면서 벽이 느껴졌던 학생에게는 가뭄에 단비 같은 책이지 않을까 생각한다.

리버스 엔지니어링 기드라 실전 가이드 유사 멀웨어로 먹히는 소프트웨어 정적 분석
나카지마 쇼타, 고타케 다이치, 하라 히로아키, 가와바타 고헤이 지음 | 이창선, 임재용 옮김 | 한빛미디어 | 2022년 01월 10일 출간

책 디자인도, 두께도 범상치 않다

이 책은

✔️ 기드로나 IDA Pro 등 리버싱 툴을 한 번이라도 다뤄본 사람에 추천한다.

개인적으로는 리버싱을 공부하면서 분석 경험을 쌓고 싶은데 혼자 공부하기 막막한 사람에게 도움이 많이 될 것 같다고 느꼈다. 책의 앞부분(기초 편)에서 먼저 리버스 엔지니어링과 기드라 기초 지식을 알려주고, 뒷부분(실전 편)에서 실제로 소프트웨어를 분석하는 과정을 순서대로 상세하게 알려주기 때문이다. 실습 가이드인데도 기초 지식을 꼼꼼하게 짚어줘서 이 책과 구글만으로도 공부해볼 수 있겠다고 느꼈다. 전공자나 실무자, 또는 어떤 형태로든 리버스 엔지니어링을 하고 있는 사람이라면 나보다 훨씬 수월하게 실습을 진행할 수 있고, 더 많은 것을 얻어갈 수 있을 것이다.

하지만 운영체제, 어셈블리어, C나 JAVA 등 리버싱에 필요한 기반이 부족한 상태에서 이 책만 보고 기초부터 실습까지 공부해보려 한다면 이 책을 독파하기 쉽지 않을 것 같다. 또한 이 책의 목적이 실습인 만큼, 기드로 사전처럼 사용하기에 편한 구성은 아닐 수 있다.

✔️ 멀웨어 분석 및 해석 방법을 제시해준다.

크랙미와 모의 멀웨어 프로그램부터 멀웨어 패커(BlackBicorn), 멀웨어(Godzilla Loader), 그리고 안드로이드 멀웨어(SafeSpy)까지 다양한 소프트웨어 정적 분석을 실습한다. 실습용 코드부터 실제 코드까지 차례로 분석을 시도해본다는 점이 좋았다.

처음 분석을 시작할 땐 어디부터 보고 어디까지 파악해야 하는지를 아는 것이 가장 어려웠었던 기억이 난다. 이 책에서는 분석 방법부터 해석 방향까지 제시해주기 때문에 혼자서 공부하더라도 막막하지 않을 것 같다. 그만큼 내용이 방대(900페이지가 넘는다)하므로 힘들 수 있지만, 끝까지 해낸다면 리버싱은 웬만큼 할 수 있게 될 거라고 생각한다.

✔️ 그리고 설명이 굉장히 친절하다.

무언가를 배울 때, '너무 당연한 사실이라고 생각해서 그냥 넘어가는 설명'을 가장 싫어한다. 이 책은 그런 면에서 굉장히 친절하다고 느꼈다. 사람에 따라 너무 설명이 장황하다고 느낄 수도 있겠지만, 공부하면서 토씨 하나도 틀림이 없게 하려면 이런 꼼꼼함이 필요하다고 생각한다. 특히, 왜 이렇게 하는지에 대해 납득이 가도록 설명해주어서 읽기가 굉장히 수월하다. 이런 점에서 이 책이 굉장히 마음에 든다. (글 뒷부분에 예시를 첨부해놓았다)

덕분에 이런 일이 없다

✔️ 윈도우와 리눅스 환경에서 진행한다.

이 책에서는 기본적으로 윈도우 x86환경을 사용한다. 리눅스 환경이 필요한 파트도 있는데, WSL(Windows Subsystem for Linux)를 활용하라고 가이드해준다. 물론, 악성코드 분석의 정석은 가상 환경이기 때문에 실습을 위해서는 기본적으로 가상 환경 구축이 필요하다.

✔️ 이클립스를 사용한다.

기드라는 JAVA 기반이기 때문에 스크립트는 JAVA로 개발하는 것이 표준이라고 한다. 따라서 책에서는 스크립트 개발 환경으로 이클립스를 사용한다. 혹시나 이클립스를 다뤄보지 않았더라도 필요한 기능은 모두 상세하게 알려준다. 또한, 기드라에서 제공하는 GhidraDev라는 이클립스용 플러그인을 활용하여 스크립트 디버깅, 클래스 검색 등 보조 기능을 사용하는 방법을 알려준다.

✔️ 부록을 먼저 보자.

뭐든 직접 부딪혀봐야 안다고 생각하는데, 컴퓨터에 관련해서는 특히 더 그렇다. 이론을 아무리 공부해도 코드를 한 줄이라도 직접 써봐야 이해가 되고 재미있다. 이 책의 부록은 기드라 응용(A), 기드라 스크립트(B), 실전 문제 풀이(C) 총 3개 파트로 구성되어 있는데, 이 중 부록 C에서는 crackme 문제를 풀어준다. 원본에는 없었던 것을 번역본에서 추가한 것이라고 하는데, 기드라를 어떻게 사용하는지 알아본다는 생각으로 접근하면 좋을 것 같다. Level 1부터 2까지 푸는 과정을 어떤 버튼을 눌러서 어떤 기능을 수행하는지까지 하나하나 상세하게 알려주고 있기 때문에 참고할 만하다. 책에서는 부록 C가 공부를 마치고 배운 내용을 복습하는 목적이라고 소개했지만, 한 레벨이라도 먼저 깨보고 나서 이 책을 공부하기 시작하면 훨씬 재미있게 시작할 수 있지 않을까 생각한다.

책 구성

이 책의 구성은 아래와 같다. 앞서 언급했던 것처럼 기초 편과 실전 편이 나뉘어 있는 점이 좋다. 기초 편에서 여러 기초 지식을 다루지만 어셈블리어나 C, Java, Go 등 프로그래밍 언어나 컴퓨터 시스템에 관한 기반 지식을 깊게 다루지 않는다. 그리고 실전 편에서는 윈도우 기반 멀웨어를 중심으로 정적 분석을 실습한다. 분석 소프트웨어로는 연습용과 실제 멀웨어를 모두 다루는데, 원서가 20년도에 출간되었던 만큼 최신 트렌드 파악보다는 리버스 엔지니어링 실습과 기드라 사용법을 중심으로 공부하면 좋겠다.

책 들여다보기

앞서 책의 장점으로 상세한 설명을 꼽았었는데, 그 이유를 정리해보았다. 먼저, 화면 캡처나 구조도 등 첨부 자료가 정말 많다. 툴을 처음 다루는 입장에서 이런 자료들은 정말 큰 도움이 된다.

그리고 '당연히 알겠지'하고 그냥 넘어가는 법이 없다. 책 한 권에서 모든 걸 담을 수는 없는데도, 짧게라도 모든 개념을 짚어주려는 노력이 보여서 고마웠다. 예를 들어 AES 암복호화가 필요한 파트에서 당연히 안다고 생각하고 넘어갈 수도 있는 내용이지만, 암호화 알고리즘과 ECB모드, CBC모드에 대해서 먼저 설명해준 다음 스크립트로 암복호화 과정을 보여주면서 분석을 진행한다. 이렇다 보니 실습을 진행하면서 모르는 내용이 나와도 수월하게 따라갈 수 있었다.

실전 편에서는 모든 파트가 분석 리포트를 쓰듯 서론-본론-결론이 명확하다. 서론에서는 분석 대상을 소개하고, 결론에서는 분석에 대한 평가를 덧붙여준다. 이런 구성은 체계적으로 공부하는 데에 큰 도움이 되었다. (과제 할 때 이 책이 있었으면 A+을 받을 수 있었을 텐데)

Index

전문 서적을 볼 때 중요하게 보는 곳 중 하나가 Index이다. 여기에 책에 무엇이 있는지가 전부 드러나 있기 때문이다. 책을 사려고 고민 중인 사람이 있다면, 이게 도움이 되길 바란다.

「회계 무작정 따라하기」/ 권재희 지음 / 길벗 출판 / 2019년 출간

TEKI — Sat, 29 Jan 2022 00:33:11 +0900

회계 무작정 따라하기 숫자가 싫은 당신을 위한 세상에서 제일 쉬운 회계책
권재희 지음 | 길벗 | 2019년 9월 5일 출간

차를 타다 멀미가 나면 꼭 먼 산을 바라보라고 했다. 멀미가 나게 하는 것 중에 가장 제자리에서 가만히 있는 것이 먼 산이기 때문이다. 최근 몇 년간 기업들에 대한 평가와 예측 불가능한 주가 등에 대한 이야기가 조금은 과하게 쏟아져 나왔다. 그 사이에서 멀미를 가라앉히려면 항상 변하지 않고 제 자리를 우직하게 지키는 가장 기본을 봐야겠다고 생각했다. 그래서 회계에 관해 공부해보자 마음먹고 이 책을 처음 열어보았다. 왜 이 책이었냐면, 마치 <비전공자를 위한 이해할 수 있는 IT 지식> 책처럼 '회알못을 위한 이해할 수 있는 회계 지식' 같은 느낌이 들었기 때문이다. 저자는 회계를 하나의 언어라고 표현했는데, 정말로 이 책은 마치 외국어를 가르치듯 회계를 알려주었다. 크게 반을 나눠서 앞부분은 회계에 대한 기본 개념을 다지고 뒷부분은 재무제표를 직접 보면서 어떻게 읽고 이해해야 하는지에 대해 예시를 다양하게 들어 설명해주는데, 이 뒷부분 설명 은근히 재미있다. 그럼에도 불구하고 꼭 문제집에서 쉬운 앞 단원만 풀고 뒤 단원은 새하얗게 간직했는데, 이 책도 그럴 것 같다는 걱정이 든다.. 하지만 생각날 때마다 한 번, 두 번 읽다 보면 언젠가는 이해할 수 있지 않을까?

테키테크 TEKITECH

[책리뷰] 견고한 데이터 엔지니어링

오라일리 마이크로서비스 아키텍처 구축 전면 개정판

추천 시스템 입문 - 한빛미디어

오라일리 개발자를 위한 머신러닝&딥러닝 / 한빛미디어

우분투에 docker와 docker-compose 설치하기 (Ubuntu 20.04 ver.)

이것이 리눅스다 3판 / 우재남 지음 / 한빛미디어

이 책에서는 이런 것들을 배울 수 있습니다.

책 들여다보기

이 책은 이런 분들께 더 추천드립니다.

혼공학습단 9기를 마치며

[운영체제] Ch15. 파일 시스템

1. 파일과 디렉터리

2. FAT 파일 시스템과 유닉스 파일 시스템

[혼공학습단 9기] 혼공컴운 6주차 미션

[운영체제] Ch14. 가상 메모리 할당 방식

1. 스와핑

2. 메모리 할당 방식 3가지: 최초 적합, 최적 적합, 최악 적합

3. 연속 메모리 할당과 외부 단편화 문제

4. 외부 단편화 해결 방안: 압축과 페이징

5. 페이지 교체 알고리즘

6. 스래싱과 프레임 할당

[운영체제] Ch13. 교착 상태(데드락)에 대응하는 방법

1. 교착 상태(데드락)란? ft. 식사하는 철학자 문제

2. 교착 상태 발생 조건 4가지

3. 교착 상태 해결 방법 - 예방, 회피, 회복

[운영체제] Ch12. 동기화 문제(생산자와 소비자 문제, 임계 구역 문제)과 동기화 도구(뮤텍스 락, 세마포, 모니터)

1. 동기화

2. '생산자와 소비자 문제'와 '임계 구역 문제'

3. 핵심 동기화 도구: 뮤텍스 락, 세마포, 모니터

[운영체제] Ch11. CPU 스케줄링

1. CPU 스케줄링

2. CPU 스케줄링 알고리즘

[운영체제] Ch10. 프로세스와 스레드, 멀티프로세스와 멀티스레드

1. 프로세스

2. 프로세스 상태와 프로세스 계층 구조

3. 스레드

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

[혼공학습단 9기] 혼공컴운 5주차 미션

[운영체제] Ch09. 운영체제 이해하기

1. 커널과 이중 모드 및 시스템 호출

2. 운영체제의 핵심 서비스

[컴퓨터구조] Ch06. RAM과 캐시메모리, 그리고 주소공간

1. RAM의 용량과 성능

2. RAM의 종류

3. 메모리의 물리주소와 논리주소

4. 저장 장치 계층 구조

5. 캐시 메모리와 참조 지역성 원리

[컴퓨터구조] Ch05. CPU 제대로 쓰기

1. 빠른 CPU를 위한 설계 기법

2. 명령어 병렬 처리 기법

3. ISA와 CISC, RISC

무료로 동영상에 자막 넣는 방법

- 순서 -

1. 동영상 준비하기

2. 자막 파일(srt) 만들기

3. HandBrake 설치하기

4. HandBrake로 동영상에 자막 파일 넣기

혼자 공부하는 데이터 분석 with 파이썬 / 한빛미디어

[컴퓨터구조] Ch04. CPU의 작동 원리

1. ALU와 제어장치, 그리고 레지스터

2. 명령어 사이클

3. 인터럽트

[혼공학습단 9기] 혼공컴운 4주차 미션

[컴퓨터구조] Ch03. 프로그래밍 언어와 컴퓨터 명령어

1. 고급 언어와 저급 언어

2. 컴파일 언어와 인터프리터 언어

3. 연산 코드와 오퍼랜드

4. 명령어의 주소 지정 방식

[컴퓨터구조] Ch02. 0과 1, 데이터를 표현하는 방법

1. 컴퓨터가 이해하는 정보의 단위

2. 이진법, 십진법, 십육진법

3. 컴퓨터의 네 가지 핵심 부품: CPU, 메모리, 보조기억장치, 입출력장치

[혼공학습단 9기] 혼공컴운 3주차 미션

[혼공학습단 9기] 혼공컴운 2주차 미션

[컴퓨터구조] Ch01. 컴퓨터 구조

1. 컴퓨터가 이해하는 정보

2. 컴퓨터의 네 가지 핵심 부품

[혼공학습단 9기] 혼공컴운 1주차 미션

[혼공학습단 9기] 2023년 시작하기