Software Engineer - Jinsu Park

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, 메모리 관리의 새로운 세계 ...

시작하며 서비스를 개발하다보면 외부 서비스에 HTTPS로 요청을 보내는 경우가 생길 수 있다. Istio를 사용하는 경우, Service registry에 등록되어있지 않은 host를 바탕으로한 요청은 기본적으로 Passthrough라고하는 Cluster로 인식되며 Passthrough 클러스터는 단순한 TCP proxy로 동작한다. 즉, 해당 TCP 패킷에 대해 아무런 부가기능을 수행해주지 않고 그냥 패킷을 전달할 뿐이다. 이 경우 L7인 HTTPS를 바탕으로한 요청에 대해 Istio는 L4인 TCP 수준의 메트릭 밖에 기록하지 못하며, TCP 메트릭 또한 정보가 매우 빈약하게 된다. Service registry - Service Mesh가 인지하고 있는 Service 정보를 모아둔 것을 의미 (참고: Istio 공식 문서) ...

⚠️ 이 글은 기계 번역 위주로 번역되었습니다. 원문은 (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의 성능을 저하시킬 수 있는 특정 경우를 고려해야 합니다. ...

시작하며 K8s에서 Istio를 통해 서비스 메쉬를 구현하는 경우, Istio는 알아서 Pod가 사용하는 ServiceAccount에 대한 인증서를 발급해주고 이를 바탕으로 메쉬 내부에서는 mTLS를 이용한 시큐어한 통신이 가능하다. 하지만 메쉬 내부에서 뿐만 아니라 메쉬 외부와도 mTLS로 시큐어하게 통신하고 싶은 경우에는 어떨까? 예를 들어 내 서비스에 VPN 없이 퍼블릭하게 인터넷으로 접근은 가능하지만 해당 서비스를 나만 이용하고 싶은 경우, 내 디바이스에 설치된 인증서를 이용해 내 서버와 mTLS로 통신을 하려면 어떻게 해야할까? 다음 몇 가지 요소들만으로도 Istio를 통해 손쉽게 Ingress gateway단에서 클라이언트(나를 비롯한 유저들)과 mTLS 통신을 지원할 수 있다. ...

시작하며 인증서 방식의 인증 및 암호화는 보안성이 좋고, 경우에 따라 편리하기까지 하다. 경우에 따라인 이유는 인증서 관리가 수작업으로 하기는 참 번거로운 작업이지만 또한 자동화하기 쉬운 작업이기 때문이다. Istio와 같은 서비스 메쉬 솔루션을 이용하면 인증서를 통해 손쉽게 TLS 혹은 mTLS 통신이 가능하다. 회사에서 업무를 보다보면 애플리케이션 컨테이너가 데이터베이스를 이용할 때 mTLS를 통해 인증과 암호화를 하기 위해 initContainer에서 인증서 관련해 별도의 작업을 해줘야하는 경우가 있었다. initContainer 뿐만 아니라 volume과 volumeMount 설정, 데이터베이스 접속을 위한 URL 환경변수 등등 다양한 설정이 복잡해지면서 Helm chart를 수정할 때 실수를 범하게 되는 경우가 종종 있었다. ...

시작하며 쿠버네티스에서 서비스메쉬 솔루션으로 Istio를 운영하다보면 Pod가 종료될 때 커넥션이 비정상적으로 종료되는 경우가 종종 발생할 수 있다. Pod가 종료되는 경우는 kubectl delete를 통해 직접 Pod를 죽이는 경우, 롤링 업데이트나 스케일 인을 진행하는 경우 등 다양하다. 커넥션이 비정상적으로 종료되는 이유는 무엇일까? 다양한 경우의 수가 있을 수 있겠지만 아마 대부분 사이드카로 뜨는 istio-proxy 컨테이너가 애플리케이션 컨테이너보다 먼저 종료되는 것이 원인일 것이라고 생각한다. v1.12 이전의 Istio를 이용하던 사람들은 다음과 같이 istio-proxy 컨테이너에 preStop 설정을 추가해 해당 컨테이너에 커넥션이 모두 종료된 후 istio-proxy 컨테이너가 종료되도록 하곤했다. ...

시작하며 얼마 전 Channel use case 라는 Go에서의 채널 사용에 관한 글을 하나 읽었다. 한 동안 스프링 업무 보느라 잊고 지냈던 Go의 concurrency pattern이나 channel의 쓰임에 대해 다시 한 번 고민해볼 기회가 되었다. 항상 어떤 기술이 왜 좋은지, 언제 써야할지를 많이 고민하는 편이라 그 실제적인 유즈 케이스에도 굉장히 관심이 많은 편이다. 해당 글의 아쉬움은 제목은 use case였음에도 구체적인 use case라기 보다는 코드 예시 같은 느낌이 컸다. 아쉬움이 좀 있었던 터라 개인적으로 지인과 얘기해보며 고민을 좀 더 해보았다. 그 결과 channel을 세마포어처럼 이용해서 동시작업 속도를 조절해야하는 경우에 사용하면 좋을 것 같다는 생각이 들었다. 그리고 그 실제적인 예시로는 게시물의 조회수 관리가 될 것 같다. ...

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

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