1. Overview ★★★★ - 리눅스 서버의 성능에 영향을 끼칠 수 있는 부분들을 공부해볼 수 있는 책. 하지만 인프라가 클라우드를 바탕으로 고도로 추상화되고 있는 요즘의 상황을 고려했을 때 로우 레벨 수준의 내용이나 코드를 자세히 다루는 부분들은 일반적인 DevOps나 SE에게는 다소 불필요한 내용 같이 느껴지기도 한다. 2. Personal Impressions 개념 소개 후 저자가 경험한 실제 사례들을 비교적 이해하기 쉽게 설명해주기 때문에 배운 내용의 필요성을 바로 공감할 수 있어서 좋았다. 리눅스에서 성능에 영향을 끼칠 수 있는 부분들에 대해 살펴볼 수 있었다. 메모리나 캐시의 특징, 디스크 IO, 네트워크 IO에 대해 다뤘다. 기본적인 개념 자체를 깔끔히 설명한다. 게다가 커널이 그런 리소스들을 어떻게 관리하는지까지 다뤄준다. 이 책 외에는 이런 내용들을 한 데에 모아 정리된 곳을 찾아보기 힘들다고 생각한다. 개념 소개 후 관련된 실제 사례들을 소개해주어 해당 개념의 필요성을 공감할 수 있었다. 마지막 챕터에서는 앞서 배운 내용들을 바탕으로 실제로 성능 개선을 해나가는 과정이 있는데 전체적인 내용 wrap up 겸 굉장히 좋았다. 개인적으로 실제 사례를 생략한 채 추상적인 얘기만 하거나 이론적인 내용만 다루는 책들을 싫어하는 편인데, 이런 관점에서 이 책은 꽤나 재미있었다. 다만 인프라가 클라우드를 바탕으로 고도로 추상화되고 있는 요즘 시대에 DevOps/SE에게는 이제 그닥 필요하지 않을듯한 내용까지 너무 자세히 다루는 점이 개인적으로는 오히려 좀 아쉬웠다. 예를 들어 로우 레벨의 깊은 코드단까지 살펴보면서 집요하게 설명하는 부분이 좀 불필요하고 지루하게 느껴지기도 했다. 각 장의 요약부분이 사실 굉장히 요약이 잘 되어있는데, 책의 내용이 다소 과하게 자세하고 깊다는 점을 고려했을 때, 요약만 읽어도 큰 문제 없을 듯하고, 그 경우 굉장히 효율적일 수 있겠다는 생각도 들었다. 따라서 책 전체를 읽기는 좀 지루할 것 같다거나 부담스러울 것 같다고 느껴지는 분들은 요약을 읽고 흥미로운 부분만 골라 읽어도 될 것 같다. 책에서 inode나 denti cache, filesystem 관련 metadata 등등 file system에 대한 내용들이 언급되었는데 이 내용들은 계속해서 내가 약한 부분 같아서 언제 한 번 살펴봐야겠다. 3. Summaries Chapter 1. 시스템 구성 정보 확인하기 시스템 구성 정보를 확인해보는 간단한 커맨드들을 소개한 장. cpu 정보는 /proc/cpuinfo 파일을 통해 확인 가능 free 명령어를 통해 시스템에 설치된 메모리의 크기, 사용 중인 메모리 등을 조회할 수 있음. df 명령어를 통해 시스템에 마운트된 블록 디바이스의 정보 확인 가능 /dev/sda - Old-SCSI-based Disk, 요즘의 SATA, SAS와 같은 일반적인 하드디스크 타입의 인터페이스를 이용하는 디스크 일반적으로 서버의 경우 RAID 컨트롤러를 통해 생성된 logical volume으로 존재함. /dev/hda - IDE-based disks /dev/vda - Virtual-hypervisor-based disks 디스크를 사용하려는 쪽과 실제 디스크 사이의 컨트롤러라는 부품이 있음. 이 부품의 타입은 IDE와 SCSI로 나뉨 IDE - 개인용 컴퓨터 SCSI - 서버용 컴퓨터, 더 많은 장치, 더ㅃ 빠른 접근 속도 ethtool을 통해 네트워크 카드의 정보 조회 가능 Chapter 2. top을 통해 살펴보는 프로세스 정보들 top 명령어를 통해 CPU, memory, swap 정보를 조회 가능 VIRT - 프로세스에 할당된 “가상” 메모리 RES - 실제로 메모리에 올려서 사용하고 있는 물리 메모리의 크기 SHR - 다른 프로세스와 공유하고 있는 메모리 VIRT는 엄청 커도 사실 문제 없을 수 있다. 중요한 것은 RES. RES가 너무 높으면 커널의 OOM Killer에 의해 프로세스가 종료당할 수 있다. Memory overcommit - 프로세스가 메모리를 요청할 때 바로 물리 메모리를 할당해주지 않고, 가상으로만 할당해주는 것. 그렇기에 할당된 메모리들의 합은 실제 물리 메모리의 크기를 초과할 수 있다.실제 물리 메모리 공간을 할당 받는 것은 해당 프로세스가 실제로 해당 메모리 공간에 접근하려할 때이다. 프로세스에는 스케쥴링 우선순위라는 것도 존재한다. 커널의 프로세스 스케쥴러는 이 우선순위를 참고해 프로세스들을 스케쥴한다. Chapter 3. Load Average와 시스템 부하 Load Average는 상태별 프로세스들의 개수들을 바탕으로 만들어진 값 프로세스가 갖는 상태의 종류 실행 중인 프로세스 실행 대기 중인 프로세스 IO 작업을 위해 대기 큐에 있는 프로세스 Chapter 4. free 명령이 숨기고 있는 것들 free 아웃풋에서의 buffers - 파일 시스템의 메타데이터 등을 저장하고 있는 블록 디바이스의 블록을 위한 캐시 free 아웃풋에서의 cached - I/O 작업의 효율성을 위해 한 번 읽은 파일의 내용을 저장하는 데에 사용하는 캐시 (Page cache) 여유 메모리가 없는 상황에서 다른 프로세스가 메모리 할당을 필요로 하면 커널은 buffers와 cached 영역의 메모리를 해제해 메모리가 필요한 프로세스에게 할당해준다. Chapter 5. swap, 메모리 증설의 포인트 swap 메모리란? - 물리 메모리가 부족한 경우 프로세스가 사용하는 메모리 중 우선순위가 낮은 영역을 물리 메모리에서 해제하고 디스크로 빼두는 영역. 이때 디스크 I/O는 메모리 I/O에 비해 월등히 느리기 때문에 시스템 전체(혹은 해당 프로세스)에 대한 병목이 될 수 있다. swap 영역이 조금이라도 사용되었다는 것은 어찌됐든 시스템에 물리적 메모리가 부족하다는 것이다. 어떤 프로세스가 swap 영역을 사용 중인지는 smem이라는 툴로 확인 가능. 커널 파라미터를 통해 swap을 사용할지 메모리 영역 중 페이지 캐시로 사용 중인 영역을 해제할지의 비율을 조절 가능 커널 파라미터를 통해 캐시를 더 많이 해제할지, 디렉토리 캐리나 inode 캐시를 더 많이 해제할지의 비율을 조절할 수 있다. Chapter 6. NUMA, 메모리 관리의 새로운 세계 ...

⚠️ 이 글은 기계 번역 위주로 번역되었습니다. 원문은 (en) [Book] System Design Interview Vol. 1를 참고해주세요. 책 개요 ★★★★★ - 대규모 시스템 아키텍처에 대한 궁금증이 있거나 첫 번째 소프트웨어 엔지니어로 취업을 준비하는 학생들에게 강력히 추천합니다. 관련 분야에서 일하고 있는 엔지니어들도 시스템 아키텍처의 전반적인 개념을 리뷰할 수 있습니다! 책에 대한 개인적인 인상 컴퓨터 과학의 기본 개념을 리뷰할 수 있었습니다. 그러나 동시에 조금 지루했습니다. 동일한 시스템과 개념인 알림 시스템, 캐싱, 샤딩 및 메시지 큐가 반복적으로 소개되고 언급되어 다른 상황을 상상할 때 동일한 시스템을 쉽게 이해하고 재사용할 수 있었습니다. ...

⚠️ 이 글은 기계 번역 위주로 번역되었습니다. 원문은 (en) [Book] Learning HTTP/2를 참고해주세요. 요약 ★★★★☆ - 적극 추천합니다! 그러나 다른 책이나 기사로 약간 대체할 수 있습니다. 이 책은 HTTP 프로토콜의 진행 상황에 대한 유용한 실제 사례와 명확한 설명을 제공합니다. 또한 HTTP 2와 HTTP 1을 명확하게 비교합니다. 이 책에 대한 링크는 Learning HTTP/2 입니다 . 감상평 이 책에 HTTP 프로토콜의 역사가 포함되어 있다는 점을 높이 평가합니다. 이와 같은 기술 서적에서 내가 가장 중요하게 생각하는 것은 실제로 역사적 맥락을 포함하는 것입니다. 기술의 사양과 특징은 인터넷에 있는 동영상이나 기사를 통해 알 수 있지만 기술의 역사를 이해하는 것은 책을 통해서만 가능합니다. 여기에는 버전 0.9, 1.0 및 1.1에서 2.0으로 HTTP 프로토콜의 진행 상황이 포함되었습니다. HTTP/2 헤더에 대한 자세한 설명과 관련 예제가 매우 유용하다는 것을 알았습니다. 책은 읽기가 매우 쉬웠습니다. 느린 읽기 속도에도 불구하고 나는 며칠 안에 그것을 끝낼 수 있었습니다. 취업을 준비하는 학생이나 모르거나 무의식적으로 HTTP 2를 사용하는 엔지니어에게 이 책을 적극 추천합니다. 나도 HTTP2에 대해 잘 몰랐지만 이제 이 주제에 대해 어느 정도 자신감을 얻었습니다. 나중에 이 책을 몇 번 더 다시 볼 생각입니다! 이 책을 통해 HTTP 2에 대해 어느 정도 친숙해질 수 있었지만 솔직히 아직 완전히 이해하지는 못했다. 요약 HTTP 프로토콜의 역사 HTTP 0.9의 탄생 제한된 기능을 가진 간단한 프로토콜 GET 방식만 지원 헤더가 포함되어 있지 않습니다. 열악한 기능에도 불구하고 HTTP 0.9가 널리 사용되었습니다. HTTP 1.0의 탄생 HTTP 0.9 이후 몇 년 후에 개발되었습니다. 헤더, 응답 코드, 리디렉션, 오류, 조건부 요청, 콘텐츠 인코딩 및 압축 및 다양한 방법을 포함하여 HTTP0.9에 비해 크게 향상된 기능을 도입했습니다. 연결을 유지할 수 없습니다. 헤더 Host는 필수가 아닌 선택 사항입니다. 제한된 캐싱 기능. HTTP 1.1의 탄생 20년 넘게 웹 커뮤니케이션을 지배했습니다. 지시문을 사용하여 연결을 유지할 수 있습니다 Connection. 헤더 를 도입하면 Host단일 IP 주소로 여러 웹 서비스를 제공하는 가상 호스팅이 가능합니다. 헤더 Upgrade는 더 높은 수준의 프로토콜에 대한 협상을 허용합니다. 향상된 캐싱 기능 HTTP 2.0의 탄생 멀티플렉싱 - 동일한 도메인 이름과 인증서를 사용하여 동일한 대상에 대한 여러 요청에 대해 단일 TCP 연결을 사용할 수 있습니다. 프레이밍 - 전송되는 데이터의 단위. 데이터 전송은 프레임 단위로 발생합니다. 헤더 압축 - HPACK을 사용하여 유사한 헤더를 압축하여 전송을 최적화합니다. HTTP 1에서 HTTP 2로 전환 HTTP 1에서 HTTP 2로 서비스를 전환할 때 HTTP 1의 성능 최적화 팁이 HTTP 2의 성능을 저하시킬 수 있는 특정 경우를 고려해야 합니다. ...

시작하며 얼마 전 리눅스 커널의 동작을 설명하는 책을 읽고나니 살짝 내가 매일 사용하는 리눅스는 어떻게 탄생하게 된 걸지 궁금해졌었다. 회사에서 저녁을 먹고 나오는 길에 우연히 사내 책장에서 “유닉스의 탄생"이라는 책을 발견하게 됐고, 그 책을 읽어봤다. 책에 담긴 내용 간단히 정리 AT&T라는 미국의 회사 내에 존재했던 벨 연구소에서 어떻게 UNIX라는 운영체제가 탄생하게 되었는지 들어볼 수 있었다. 컴퓨터와 운영체제의 역사에 길이 남을 켄 톰슨, 데니스 리치, 더글라스 매클로이 등의 인물들에 대해서도 자연스레 알게 됐다. ...

시작하며 이 책을 읽기 전, 커널이나 운영체제는 나에게 꽤나 안개 같은 존재였다. 나는 클라우드 인프라를 다루는 엔지니어임에도 불구하고 커널이나 운영체제에 대해 제대로 알지 못하는 점이 약간 부끄럽게 느껴져 이 책을 통해 커널이 어떻게 동작하는지 좀 더 알아가고 싶었다. 책에 담긴 내용 간단히 정리 실제로 커널을 빌드하고 설치하는 방법 ftrace, trace32 등의 커널 개발, 디버깅에 도움되는 도구들 사용법 process나 thread 등의 개념이 실제로 구현된 자료구조 인터럽트가 발생하고 감지되어 처리되기까지의 일련의 과정 인터럽트 처리 기법 장단점 장점 실제로 커널을 빌드하고 설치해볼 수 있다! - 이 책을 읽으면서 수차례 커널을 빌드해볼 수 있었다. 만약 이 책이 없었더라면 어떻게 시작해야할지, 가능은 한 걸지 막연한 두려움에 쌓여있었을 수도 있었을 것 같은데 이 책 덕분에 어렵지 않게 직접 커널을 설치해볼 수 있었고, 몇몇 유용한 팁, 코드들을 얻을 수 있었다. 인터럽트가 어떻게 발생해서 어떻게 처리되는지 좀 더 구체적으로 알 수 있다. 여러가지 인터럽트 처리 기법에 대해 배워볼 수 있다. - IRQ 스레드, Soft IRQ, Work Queue등의 개념을 다룬다. 만약 이 책이 없었다면 이런 키워드를 얻는 것 조차 매우 힘들었을 듯하다. 인터넷 강의도 존재하고 저자분 블로그도 존재하는데 커뮤니케이션이 활발해 열심히 학습했다는 전제하에 그래도 모르는 게 있다면 얼마든지 여쭤볼 수 있다. 단점 (너무) 코드 위주의 자세한 내용이 많다. - 이건 단점이라기 보단 내 상황과는 조금 맞지 않았던 점이다. 처음에는 코드까지 까본다는 면이 되게 매력적으로 느껴졌는데 점점 너무나 깊은 심연을 탐구하게 되는 느낌이었달까… 일반적인 개발자, 엔지니어들에게는 다소 과하게 느껴질 만한 깊이인 듯하다. 중반 이후로는 실습이 별로 없고 인터럽트 후반부 처리에 대한 단순 나열이 많다. - 사실 나는 현재 데브옵스 엔지니어일 뿐 본업이 커널 개발자는 아니기에 애초에 이 책의 내용을 완~전히 이해하는 것을 목표로 하진 않았다. 디버깅 실습이 많다고 하니 ‘책을 슥슥 넘기지 말고 실습이라도 무조건 다 따라해보자!‘는 마인드였는데 중반부터는 인터럽트 후반부 처리 기법들이 등장하면서는 실습은 거의 없고, 해당 기법들을 각각 설명해나가는 내용이 주였다. 하지만 이 부분은 거의 나에게는 도움되지 않는 내용이었던 것 같아 결국 아쉽게도 뒷부분은 그냥 슥슥 읽고 넘어가게 됐다. 마치며 이 책은 커널에 대한 두려움을 없애줬고, 실제로 커널을 빌드하고 설치해보는 멋진 경험을 할 수 있게 해줬다. 이 책 덕분에 프로세스는 어떤 자료구조로 구현되어있고 어떻게 처리되는지, fork는 무엇인지, 스레드는 어떻게 구현되어있고 어떻게 처리되는지, 인터럽트는 어떤 흐름으로 발생되고 처리되는지를 한 번 더 공부해볼 수 있었다. 관련된 주제를 다루는 글들이 흔하다면 흔할 수는 있지만, 이 책처럼 자세하게 다뤄주는 경우는 없었기에 중반까지는 이 책을 참 재밌게 읽었던 것 같다. 하지만 인터럽트 후반부 처리 관련된 내용이 나오면서 머리가 어질어질해지고, 나랑은 좀 무관한 내용 같아서 좀 급히 책을 마무리하게 된 경향이 있어서 이 점은 조금 아쉽다. ...

시작하며 Istio in Action을 읽고난 뒤에 리눅스나 커널에 대한 책을 읽어보겠다는 계획을 갖게 되었습니다. 정확히는 DevOps와 SE를 위한 리눅스 커널 이야기라는 책을 읽고싶었습니다. 기존에는 그 책이 사무실에 비치되어있었지만 이번에 사무실을 이사하면서 그 책이 어디갔는지 보이지가 않더라구요. 그래서 그냥 다른 책장에 비치되어있던 이 책을 읽어봤습니다. 다루고 있는 내용은 주로 리눅스 구조라기보다는 전반적인 컴퓨터 구조, 운영체제 같았습니다. 책에 담긴 내용 간단히 정리 커널의 역할, 운영체제의 역할이 무엇인지. 커널과 운영체제 및 드라이버들이 없다면 어떤 불편이 있을지 설명합니다. syscall, interrupt에 대해 이해하기 쉽게 설명하고 어떤 플로우로 동작하는지 설명합니다. CPU, 코어, 하이퍼 스레드에 대해 설명합니다. 메모리와 Virtual Memory, Cache, HDD, SSD의 특징과 어떻게 동작하는지를 설명합니다. fork & execve가 어떻게 동작하는지와 계층적인 리눅스의 프로세스 관계에 대해 설명합니다. 파일 시스템이 무엇인지, 파일 시스템이 없다면 어떠한 불편이 있는지 설명합니다. 장단점 장점 실제 코드와 그것에 대한 수행 결과, 개념을 나타낸 그림 등을 통해 이해를 돕습니다. 단순히 “이런 역할을 하는 녀석입니다.“로 설명이 끝나는 게 아니라 그 녀석이 없으면 어떤 불편이 있는지 예시를 들어줍니다. e.g. 디바이스 드라이버가 없다면 유저들은 작성하는 모든 프로그램에서 디바이스를 어떻게 제어할지를 구현해야할 것이고, 여러 프로세스가 같은 디바이스를 사용하려는 경우 어떻게 해야할 지에 대한 문제가 생길 것이다. e.g. 가상 메모리라는 개념 없이 물리 메모리를 직접 이용한다면 프로세스들이 실제로 자신의 물리메모리 주소를 관리해야하는데 이런 경우 다양한 어려움이 존재할 것이다. (너무 다양해서 이 글에선 생략.) 평소에 궁금했던 개념들, 내가 잘 알고 있는 건지 의문이 들었던 개념들, 이것까지 알아야하나싶은 개념들에 대해 한 번 가볍게 정리해볼 수 있습니다. 예를 들면 Page cache, Hyper thread 이런 개념들은 들어보기만 많이 들어보고 가볍게 알아볼 기회가 없었는데 이번에 가볍게 ‘아~ 이런 거구나~’ 해볼 수 있었습니다. 교수님께 배웠던 Virtual Memory 역할과 흔히 인터넷에서 Virtual memory를 설명하던 내용이 조금 달라서 내가 잘 알고있는 건지 의문이 들었는데 이런 의문도 해소가 됐습니다. 흔히 인터넷에서 봤던 Virtual memory의 역할은 Page라는 개념을 바탕으로 물리 메모리를 프로세스가 안전하고 편리하게 사용할 수 있도록 해주는 것이었습니다. 교수님께 배웠던 Virtual memory는 이뿐만 아니라 메모리를 demading page, swap 같은 응용된 내용도 있었습니다. 그래서 제가 인터넷에서 봤던 내용들이 맞는 건지 교수님께 배웠던 내용이 맞는 건지 궁금했는데 이 책 덕분에 ‘뭐 모두 맞는 내용 같다.‘는 결론을 낼 수 있었습니다. 단점 깊이가 깊진 않습니다. 깊이만 놓고 보면 학부생 수준의 컴퓨터구조, 운영체제 정도인 듯합니다. 번역이 조금 어색한 부분들이 종종 보였습니다. 마치며 ...

시작하며 저번 편에서는 Key-Value DB와 Document DB를 정리해봤고 이번 편에서는 Column Family DB와 GraphDB에 대해 정리해보려한다. Column Family DB나 GraphDB는 실제로 사용해본 적이 한 번도 없어서 어떤 녀석들인지 자세히는 모르지만 책 내용 위주로 정리해보도록 하겠다. Column-Family DB Column-Family DB는 한 Row에 무수히 많은 Column을 Schema가 강제되지 않은 형태로 이용할 수 있는 NoSQL의 한 종류이다. Wide column DB, Wide column store, Columnar DB 등의 다른 다양한 명칭들도 존재는 하지만 책에서는 좀 더 여러 컬럼을 묶어서 생각할 수 있는 점이 강조되는 Colum-Family DB라는 용어를 이용했다고 한다. ...

(도서) “NoSQL 철저 입문” - Key-Value DB, Document DB 시작하며 앞선 글에서는 “NoSQL 철저 입문”이라는 도서에 대한 총평과 NoSQL 데이터베이스들이 공통적으로 갖는 특징에 대해 알아봤다. 이번 글에서는 NoSQL들 중에서도 Key-Value DB와 Document DB이 특히나 서로 유사한 형태를 띄는 것 같아 묶어서 정리해보려한다. 추가적으로 각자의 고유한 특징은 아니더라도 공통적 특징일 수 있는 Master - Slave(read replica) 구조나 Partitioning, Sharding 등등에 대해서도 정리할 예정이다. Key-Value Database 키와 값 뿐인 가장 간단한 형태의 NoSQL 종류이다. 아주 단순한 조회만이 지원된다. 키를 통해서만 조회가 가능하다. 키를 알고 있다면 데이터를 바로 찾을 수 있지만 키가 없다면 풀서치를 해야할 수 있다. Key-Value Database는 간단한 형태의 DB이기 때문에 테이블이나 그래프로 복잡한 관계를 나타내려는 경우에는 부적합하다. 단순 저장과 키를 바탕으로한 조회로 충분한 경우에 가볍게 사용하기 좋다. ...

책을 읽게 된 계기 당근마켓 플랫폼 팀의 서버 엔지니어로 지원하고 면접을 보면서 저장소에 관련한 질문을 많이 받았었다. 저장소는 관계형 데이터베이스나 다양한 NoSQL 데이터베이스들을 의미한다고 할 수 있겠다. 많은 질문들이 나왔고, 당시의 나는 사실 데이터베이스 쪽 지식은 거의 전무했던 것 같아 제대로 대답을 못한 게 많았던 것 같다. 인턴 근무를 하면서는 내가 익숙했던 관계형 데이터베이스가 아닌 NoSQL 특히 Redis나 DynamoDB 등을 주로 사용하는 모습도 많이 보게 되어 NoSQL에 대해 관심이 가게 되었다. ...