DevOps

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 공식 문서) ...

시작하며 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 컨테이너가 종료되도록 하곤했다. ...

시작하며 저는 데브옵스 엔지니어로 현재(2022년 9월)의 회사에 입사한 후, 기존에 막연하게 궁금증을 가져왔던 Istio라는 제품을 주로 담당하게 됐습니다. 공식 문서와 릴리즈 노트 위주로 Istio를 공부하던 중 팀원분께 Istio in Action이라는 책을 추천받게 됐고, 이 책을 통해 조금 두루뭉실했던 이해와 삽질을 바탕으로 했던 판단들이 좀 더 분명해질 수 있었던 것 같습니다. 그 동안은 지루함으로 인해 책을 다소 멀리 하고 짧은 아티클들을 위주로 학습을 해온 반면 올해 제 목표 중 하나는 책을 통해 좀 더 개념을 잘 정리하고 깊이 있게 공부를 해나가는 것이었습니다. 이 책은 그런 저의 목표에 다행히 잘 부합해줬던 것 같고 정말 간단히 리뷰를 해보려합니다. ...

시작하며 데브옵스 엔지니어로 입사한 뒤 주로 맡고 있는 작업은 Istio 관련 작업이다. 평소 참 관심 있었던 분야이기도 하고 istio 뿐만 아니라 네트워크에 대해 개인적으로 정말 공부해보고싶었는데 덕분에 재미있게 공부하고 성장하며 근무하고 있는 것 같다. 😊 근데 요즘 들어 점점 단순히 ‘어떻게 저떻게 하니까 돌아는가네~ 오.. 나 istio 좀 파악한듯?ㅋㅋ’ 수준의 자세로는 트러블슈팅을 하거나 올바르게 설계하기가 쉽지 않은 경우들이 잦아졌다. 따라서 평소 궁금했던 내용 중 하나를 살짝 파헤쳐볼까한다. 나는 주로 istio ingress gateway와 관련된 작업을 많이 했었고 이 경우 Virtual Service는 항상 ingress gateway를 참조하도록 설정해왔다. 근데 istio를 처음 배울 때는 분명 ‘client 측에서 outbound handler 역할을 하는 Envoy 사이드카을 통해 알아서 우리가 의도하는 목적지를 찾아서 요청을 보낸다.’ 이런 식으로 배웠던 것 같은데 ‘왜 나는 Virtual Service를 이용할 때 항상 Gateway를 설정해줘야하는 것이었을까?’하는 궁금증이 생겼다. ...

시작하며 요즘 istio를 공부하던 중 istio가 변화해온 과정에 대해서도 흥미가 생겨 지난 버전들의 릴리즈 노트들도 읽어보고 있습니다. 그러던 중 현 시점(2022년 7월)에는 이미 공식적인 End of Life가 지난 2021년 3월 처음 릴리즈된 istio 1.10의 릴리즈 노트를 보다가 재미있는 점을 하나 발견할 수 있었는데요. 바로 envoy proxy가 eth0에 대한 요청을 넘겨주는 container의 network interface가 lo 에서 eth0 로 변경되었다는 점입니다. 네트워크에 대해, 그 중에서도 특히 네트워크 인터페이스에 대해 잘 몰랐던 때에는 이 변경사항에 그닥 관심이 안 갔을 것 같은데 최근 네트워크 인터페이스에 대해 공부를 해서인지 이 변경사항에 관심이 갔습니다. ...

시작하며 올해에는 많은 변화가 있었다! 💼 데브옵스 엔지니어로 회사를 가게 됐고 아주 만족 중이다! 🏠 회사의 좋은 보상, 복지에 힘입어 생애 첫 자취를 하게 됐다. 💻 네트워크나 리눅스, 보안 등 딥한 영역에 좀 더 관심을 갖게 됐다. 🎸 기타를 꾸준히 다니고 있다. 그런 변화들 속에서 자취방에 인터넷 설치를 하게 됐는데 클로바 AI 스피커를 공짜로 주더라. 본가에 있을 때도 쓰긴 했는데 딱히 관심 없다가 직접 클로바 앱을 깔아서 이것저것 써보니 ‘전보다 재밌네..? ㅎㅎ’ 싶었고, ‘아니 이거 직접 만들지는 못하나’하는 생각이 들던 참에 “스킬 스토어”라는 게 눈에 띄었다. 스킬 스토어에는 개별 개발사들이 개발한 자기네 기능들이 소개되어있었다. ...

시작하며 저번 글(“ArgoCD 선언적으로 이용해나가기 - Helm, App of App”)에서는 Helm과 App of App 패턴을 이용해 ArgoCD를 선언적으로 이용해나가는 방법을 다뤘습니다. 바~로 ArgoCD를 좀 더 선언적으로 이용해나가는 것과 관련된 팁부터 글을 적어나가기는 좀 무리가 있을 것 같아 해당 글에서는 배경지식들에 대한 간략한 정리와 핸즈온 같은 느낌의 내용들도 많이 포함하게 됐던 것 같아요. 이번 글에서는 ArgoCD를 실제로 이용하기 위해 필요할만한 이런 저런 설정들을 어떻게 선언적으로 정의해볼 수 있을지를 소개해보려해요! 그리고 그 예시로 RBAC 설정을 해보겠습니다. 이번 글에서 수행해볼 작업은 Github 계정을 ArgoCD와 연동시켜 역할(Role) 기반으로 ArgoCD의 권한을 제어하는 것이에요. ...