누구나 이해하는 클라우드 인프라 지식 사전 - 인프라가 막막한 백엔드 주니어에게 지도가 되어줄까
“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”
들어가며
기능 개발은 어떻게든 한다.
API를 만들고 쿼리를 짜고 테스트를 붙이는 일은, 막히더라도 결국 길이 보인다.
문제는 그 바깥이었다.
응답이 느려졌다는 얘기가 나오면 어디를 봐야 할지 감이 안 왔다.
로그를 켜보고, 인덱스를 의심하고, 인스턴스를 한 단계 올려보고.
그러다 어쩌다 나아지면 “아마 이게 문제였겠지” 하고 넘어갔다.
왜 나아졌는지는 끝까지 모른 채로.
혼자 공부하는 입장에서 이런 게 제일 답답하다.
물어볼 사수가 있으면 “그건 원래 그래” 한마디로 끝날 일을, 며칠씩 검색하며 파편으로 주워 모은다.
그렇게 모은 지식은 언제나 점이었다. 선으로 이어지지 않았다.
한빛미디어의 누구나 이해하는 클라우드 인프라 지식 사전은 그 점들을 이어보려고 집어 든 책이다.
576페이지, 23장 두께에 겁먹었는데, 서문에서 저자가 먼저 이렇게 말한다.
모든 내용을 세세하게 이해하려고 하기보다는, 우선 한 번 전체를 훑어보는 것만으로도 자신의 시야가 넓어졌음을 느낄 수 있다.
4장 성능 튜닝 - “추측하지 말고 측정해라”
이 책에서 가장 오래 붙잡고 있었던 챕터다.
정확히는, 내가 그동안 뭘 잘못하고 있었는지를 알려준 챕터다.
저자는 성능 튜닝의 원칙을 이렇게 못 박는다.
성능 튜닝 원칙: 추측하지 않고 측정해라
그리고 왜 인터넷의 ‘튜닝 레시피’가 잘 안 먹히는지를 설명한다.
레시피는 특정 상황의 병목을 해결하기 위한 수단인데, 우리는 보통 그 전제를 확인하지 않고 가져다 쓴다.
내 병목과 그 글의 병목이 같은지 모른 채로 커넥션 풀을 늘리고 캐시를 붙이는 것이다.
읽으면서 뼈를 맞았다.
나는 늘 원인을 찾은 게 아니라 증상이 사라질 때까지 뭔가를 바꿔본 것에 가까웠다.
이 챕터가 좋았던 이유는 원칙만 외치고 끝나지 않는다는 점이다.
포화(Saturation) 상태라는 개념을 먼저 잡아준다. 단위 시간당 처리량 대비 리소스 성능이 부족한 상태고,
CPU 사용률·네트워크 IOPS·스토리지 IOPS 같은 곳에서 나타나며,
일련의 처리 중 어딘가가 포화 상태면 그 지점이 전체 성능을 결정하는 병목이 된다.
그리고 실전에서 놓치기 쉬운 함정도 짚는다.
때로는 과부하로 인해 모니터링 자체가 제대로 동작하지 않을 수도 있다.
이건 겪어본 사람만 쓸 수 있는 문장이다.
장애 때 대시보드가 텅 비어 있어서 “다행히 트래픽이 없네”라고 착각했던 기억이 겹쳤다.
부하 테스트 절차도 구체적이다.
시나리오를 만들고, 모니터링을 먼저 붙이고, 부하를 걸고,
시작·종료 일시와 병렬 수, 트래픽양, 메트릭, 로그, 오류를 기록해 두라고 한다.
반복 실행이 전제이니 손으로 적지 말고 셸 스크립트 정도로라도 자동화하라는 조언까지 붙는다.
그리고 마지막에 이 말이 남았다.
데이터를 기반으로 하기 때문에 감이나 재능, 운이 아니라 구조의 이해와 논리적인 사고, 지식 및 경험의 축적으로 결과를 낼 수 있다.
사수 없이 공부하는 사람에게 이건 꽤 큰 위로였다.
성능 튜닝이 감각의 영역이 아니라 절차의 영역이라면, 혼자서도 쌓아 올릴 수 있다는 뜻이니까.
‘사전’이라는 제목에 대하여
한 가지 참고할 점은, 이 책이 실습서가 아니라는 것이다.
Docker 명령어나 Kubernetes 매니페스트를 따라 치면서 배우는 책을 기대한다면 결이 다르다.
개념과 판단 기준을 다루는 책이라, 손을 움직이는 학습은 별도로 병행하는 편이 좋다.
이런 분께 추천합니다
읽으면서 두 부류가 계속 떠올랐다.
첫째, 기능은 만드는데 그 바깥이 막막한 백엔드 주니어.
API도 짜고 쿼리도 짜지만, “응답이 느려요”라는 말 한마디에 어디를 봐야 할지 모르겠는 1~3년 차.
특히 물어볼 사수가 없어서 검색으로 지식을 파편으로 모아온 경우라면, 이 책이 그 파편에 목차를 달아준다.
4장 하나만 제대로 읽어도 “일단 스펙을 올려보자”에서 벗어날 수 있다.
둘째, 이직 면접을 준비하는 주니어~미들 개발자.
23장 ‘취업’이 이 책에서 가장 예상 밖의 챕터였다.
저자는 이렇게 준비하라고 한다.
자신이 속한 시스템의 계층 구조를 떠올리며, 지금 알고 있는 범위의 한 계층 위와 아래까지 이해하려고 노력해 보면 좋다.
구체적으로는 지금 쓰는 기술의 정식 명칭, 버전, 아키텍처상의 역할, 왜 그 아키텍처를 택했는지, 왜 그 제품을 골랐는지, 왜 아직 그대로 쓰는지를 설명할 수 있어야 한다고 한다.
“후배에게 설명한다는 마음으로 정리하라”는 조언이 붙는데, 이게 사실 면접 답변을 만드는 방법 그 자체다.
대체재를 찾아보라는 조언도 좋았다.
PostgreSQL을 쓰고 있다면 MySQL과 뭐가 다른지, Redis와는 어떻게 다른지, NewSQL인 TiDB와는 무엇이 다른지로 시야를 넓혀 가라고 한다.
기술 선택 이유를 묻는 면접 질문에 매번 얼버무렸다면, 이 방식이 답을 만들어 준다.
정리
누구나 이해하는 클라우드 인프라 지식 사전을 한 문장으로 정리하면 이렇다.
“성능도 가용성도 감이 아니라 측정과 기준의 문제다.”
576페이지를 훑고 나서 남은 건 개별 지식이 아니라 어휘였다.
막연하게 “느리다”고 부르던 걸 포화와 병목으로, “안 죽어야 한다”를 가동률과 SLO로,
“장애 보고서”를 포스트모템으로 바꿔 부를 수 있게 됐다.
이름을 붙일 수 있으면 검색할 수 있고, 검색할 수 있으면 혼자서도 배울 수 있다.
다음에 응답이 느려졌다는 얘기가 나오면, 인스턴스 스펙을 올리기 전에 어디가 포화 상태인지부터 측정해 볼 생각이다.
피드백은 언제나 환영합니다.