라이프

인프라 설계를 할때가 생각이 나서 적어봤는데요. 갑자기 서버들이 자동 재기동 되는 상황이 있었습니다. 이게 왜그런지 여러번 찾아봤는데 자바 서버의 문제였더라구요. 설계를 그렇게 열심히 했는데 문제가 되는걸 보고 적어봅니다.완벽한 설계라는 환상에서 벗어나기우리는 시스템을 설계할 때 항상 '완벽한 가동'을 꿈꿉니다. 모든 로드 밸런서가 제 역할을 수행하고, 데이터베이스 복제는 실시간으로 이루어지며, 네트워크는 절대로 끊기지 않을 것이라는 낙관적인 설계를 아키텍처 다이어그램에 그려 넣습니다. 하지만 실제 운영 환경은 가혹합니다. 예기치 못한 트래픽 폭증, 클라우드 리전의 갑작스러운 중단, 혹은 아주 사소한 코드 한 줄에서 비롯된 메모리 누수는 우리가 세운 정교한 성벽을 한순간에 무너뜨립니다.전통적인 방식은 장..

이전에 고영표 선수 때문에 적었던 글이 있었는데, 거기서는 고영표 선수와 비교해서 적지는 않았던 것 같아서 한번 그 스탯에 대입해서 글 적어볼라고 합니다.구속의 시대를 거스르는 '무브먼트'의 공학현대 야구는 그야말로 '강속구'의 시대입니다. 160km/h를 상회하는 빠른 공이 투수의 가치를 결정짓는 가장 큰 지표가 되었습니다. 하지만 이러한 트렌드 속에서 독보적인 존재감을 드러내는 선수가 있습니다. 바로 KT 위즈의 고영표 선수입니다. 그의 패스트볼 평균 구속은 리그 평균보다 낮지만, 타자들이 느끼는 체감 구위와 지배력은 리그 최정상급입니다. 그동안 우리는 이러한 '구위'를 투수의 컨디션이나 손끝 감각 같은 추상적인 단어로 설명해 왔습니다. 하지만 이제는 인공지능과 데이터 엔지니어링의 발전으로 이를 St..

이것도 책에서 본겁니다. 아니 가끔 복사 붙여넣기 하면 너무 많은거 복붙하면 프리징 현상 뜨지않습니까. 그러다 보니 갑자기 궁금해지기도 했고 책에서 본것도 있어서 한번 적어볼게요.보이지 않는 비용, 데이터 이동의 세금고성능 네트워크 서버를 설계할 때 우리는 흔히 CPU의 클럭 속도나 네트워크 카드의 대역폭(Bandwidth)에 집중합니다. 하지만 초당 수기가바이트(GB/s) 단위의 트래픽을 처리하는 환경에서 진정한 병목은 의외로 '데이터 자체를 옮기는 과정'에서 발생합니다. 디스크에 있는 파일을 네트워크로 전송한다고 가정해 봅시다. 애플리케이션은 단순히 파일을 읽어서 소켓에 쓰는 코드를 실행하지만, 운영체제 내부에서는 이 데이터를 메모리의 이쪽 방에서 저쪽 방으로 옮기기 위해 CPU가 쉴 새 없이 자원을..

아 이것도 참 무서운 주제에요. TCP 소켓이 쭉 올라가서 서버가 정상 동작 못하던 경우가 몇번씩 있었습니다. 대부분은 요청이 너무너무 많아서 였지만, 가끔은 개발이 잘못된 경우도 존재하더라구요. 그래서 엔지니어 단에서 소켓에 대하여 한번 보겠습니다.왜 고성능 서버는 네트워크에서 '침묵'하는가?대규모 인프라를 운영하다 보면 서버의 자원(CPU, RAM)은 충분히 여유가 있음에도 불구하고, 특정 순간에 네트워크 응답이 급격히 느려지거나 패킷이 유실되는 기이한 현상을 마주하게 됩니다. 우리는 흔히 이 문제를 해결하기 위해 애플리케이션 코드를 최적화하거나 서버의 사양을 올리곤 하지만, 진정한 병목은 종종 운영체제의 심장부인 리눅스 네트워크 스택(Networking Stack)에 숨어 있습니다.리눅스 커널은 범..

아 제가 참 싫어합니다 IaC. 인프라를 코드로 구현하고 이걸로 설계한다. 전 그림으로 그려가지고 표현하는걸 좋아하는데 이건 코드로만 구현하니까 글자가 너무많아요. 물론 그림과 표를 기반으로 만드는 거 이기 때문에, 별 상관은 없지만요. 코드와 현실의 괴리, 그리고 IaC의 숙명인프라 운영의 패러다임이 '클릭(ClickOps)'에서 '코드(IaC)'로 변화하면서, 우리는 테라폼(Terraform)과 같은 도구를 통해 수천 개의 리소스를 단 몇 줄의 코드로 관리하게 되었습니다. 하지만 코드를 작성하고 terraform apply를 실행하는 것은 여정의 시작일 뿐입니다. 인프라를 코드로 관리한다는 것은 코드(Desired State)와 실제 리소스(Actual State) 사이의 완벽한 동기화를 유지해야 한..

이건 동료가 저번에 저한테 물어봐서 작성하는 글인데요. Load Average 이게 참 애매하죠. Average 이거 평균 아닙니까. 순간적으로 치고 올라가서 문제가 되더라도, 이전이나 이후가 낮으면 평균적으로 낮게 나오니까요. 그거 때문에 한 번 글 적어봅니다.숫자에 가려진 시스템의 비명리눅스 서버를 운영하며 가장 먼저 확인하는 메트릭 중 하나가 바로 uptime이나 top 명령어 상단에 위치한 Load Average입니다. 대개 우리는 이 수치가 CPU 코어 수보다 낮으면 안정적이고, 높으면 과부하라고 판단합니다. 하지만 현장은 그리 단순하지 않습니다. 때로는 CPU 점유율이 10% 미만인데도 Load Average가 50을 넘어가며 시스템이 버벅대기도 하고, 반대로 점유율이 90%에 달하는데도 Lo..

이건 순수한 팬심 사실 고영표 선수때문에 적는 글이에요. 지금 KBO는 구속 혁명이 생겨나서 구속은 빠른데 제구가 안되는 선수가 참 많아요. 다행히도 좋은 코치들이 많아서 그 구속을 기반으로 제구를 잡아가는 선수가 많습니다. 다만! 고영표 선수는 빠르지 않은 공을 가지고도 100 퀄리티 스타트 하고 그러는거보면 구속이 전부가 아닌가? 생각이 들어서 적어봅니다!강속구가 전부는 아니다야구는 오랫동안 '구속(Velocity)'이라는 단일 지표에 열광해 왔습니다. 하지만 100마일의 강속구가 담장 밖으로 넘어가고, 80마일의 느린 변화구가 삼진을 잡아내는 현상을 구속만으로는 설명할 수 없습니다. 데이터 엔지니어링과 머신러닝의 발전은 이제 '공이 얼마나 빠른가'를 넘어 '공이 얼마나 위력적인가(Nasty)'를 정..

이것도 큰 경험이었어요. 다른 업체 OS 에 뭘 설치할 일이 있었는데, 갑자기 systemd 가 coredump를 떨구면서 죽더라구요? 그때 당시에는 진짜 처음 겪어 보는 일이었는데 다행히도 개발기여서 별 문제 없이 넘어갔습니다. 그래서 한번 주제로 선정해봤어요.범용성이 주는 성능의 함정리눅스 서버를 처음 설치하고 서비스를 올릴 때, 대부분의 엔지니어는 운영체제가 제공하는 기본 설정에 의존합니다. 하지만 초당 수만 건의 동시 접속이 발생하는 고가용성 환경에서 이 '기본값'은 종종 병목 현상의 주범이 됩니다. 리눅스 커널은 워크스테이션부터 슈퍼컴퓨터까지 아우르는 범용적인 목적으로 설계되었기 때문에, 특정 고성능 애플리케이션에는 최적화되어 있지 않기 때문입니다.서버 자원은 여유로운데 응답이 간헐적으로 느려지..

이거 글 참 쓰기 전에 힘들었던 경험이에요. 연결 되면서 로드 밸런싱 하면 참 좋죠. 근데 이 문제가 되는 컨텐츠가 하나 있었는데 이게 1번기 갔다가 20 번기 까지 가서 시스템이 문제가 되었던 거에요. 뭐 애초에 그런거에 대한 처리가 잘 되어있어서 큰 문제는 아닌데, 인터넷 세상에는 이상한게 참 많은거 같습니다.연결성이라는 이름의 양날의 검대규모 인프라를 운영하는 엔지니어에게 가장 등골이 서늘해지는 순간은 언제일까요? 서버 한두 대가 물리적인 결함으로 죽는 것은 이제 자동화된 복구 시스템 안에서 일상적인 이벤트에 불과합니다. 하지만 진짜 공포는 특정 하위 서비스의 아주 작은 지연(Latency)이나 오류가 거대한 파도가 되어 인접한 시스템들을 차례로 집어삼키는 장애 전이(Cascading Failure..

이건 얼마전에 책 읽다가 생각나서 작성하게 되었네요. 신규 도서는 아니었고 옛날 도서였는데, 역시 아직도 배울게 많습니다.유령 같은 장애, 그 뿌리를 찾아서리눅스 시스템과 인프라를 운영하며 우리가 가장 답답함을 느끼는 순간은 애플리케이션 로그와 일반적인 메트릭(CPU, Memory)만으로는 도저히 설명되지 않는 '간헐적인 네트워크 지연'이나 '유령 같은 패킷 유실'을 마주할 때입니다.우리는 그동안 데이터독(Datadog) 에이전트를 심거나 애플리케이션에 SDK를 주입하여 가시성을 확보해 왔습니다. 하지만 이러한 '에이전트 방식'은 필연적으로 리소스 오버헤드를 동반하며, 시스템 콜(System Call) 레벨에서 발생하는 깊은 병목 현상까지는 파헤치지 못합니다. "서버는 정상인데 왜 특정 프로세스만 DNS..