Still Running
Field Notes
Explore
글 99개
DevOps, 클라우드(AWS·GCP·Azure), 빅데이터, AI를 다루는 기술 블로그. Kubernetes 운영, 클라우드 인프라 자동화, 데이터 엔지니어링 경험을 기록합니다.
Artificial Intelligence2026.09.30
GPU 한 장을 여러 작업이 나눠 쓸 때, 무엇을 함께 쓰고 무엇을 따로 나눠야 할까?GPU 공유가 필요한 장면을 떠올려 보자.개발자 네 명이 각자의 주피터 노트북에서 작은 모델을 시험한다.한 사람의 작업은 10초 계산한 뒤 몇 분 동안 멈춰 있고, 다른 사람의 작업도 GPU 전체를 다 사용하지 않는다.네 사람에게 GPU를 한 장씩 주면 편하지만 대부분의 시간에는 비싼 장비가 놀게 된다.반대로 네 작업을 GPU 한 장에 무작정 몰아넣으면 다른 문제가 생긴다.한 작업이 GPU 메모리를 많이 차지해 이웃 작업이 메모리 부족으로 실패할 수 있고,오래 걸리는 계산 하나가 다른 사용자의 응답을 늦출 수도 있다.이때 선택할 수 있는 대표적인 방법이 시간 분할(Time Slicing)·MPS·MIG·vGPU다.네 방..
댓글Data Engineering2026.09.29
원본도 복제본도 살아 있다. 그런데 왜 서로 다른 값을 보여줄까?주문의 배송지를 A에서 B로 바꾼 뒤 장애가 났다고 하자.서버를 다시 띄우고 원본 DB를 확인했더니 B가 남아 있다.변경은 살아 있다.그런데 복제본에서는 A가 보인다.분석 화면도 그대로다.원본이 복구됐으니 잠시 기다리면 될까, 아니면 중간에서 변경을 잃은 걸까?배송지 하나를 두고도 확인할 곳이 여러 군데다.원본에 B가 남는 일, 다른 서버가 B를 받아들이는 일, 분석 화면에 B를 보여주는 일은 각각 따로 진행되기 때문이다.어디까지 확인해야, 데이터가 돌아왔다고 말할 수 있을까?이제 이 변경 한 건을 따라가 보자.배송지 사례는 차이를 설명하기 위한 가상 상황이다.DB 장애 복구는 어디까지 되살리는가?장애 직전, 메모리의 페이지에는 B가 있었지..
댓글Data Engineering2026.09.28
재고는 하나인데 두 요청이 동시에 주문하면, 트랜잭션만으로 막을 수 있을까?재고가 하나 남아 있다.두 요청이 거의 동시에 그 값을 읽고 각자 주문을 받아도 된다고 판단하는 상황을 생각해 보자.각 주문은 주문 기록을 만들고 재고를 수정한다.이 변경들을 트랜잭션으로 묶어 함께 확정하거나 취소하도록 했다.이제 안심해도 될까?각 작업이 반쪽만 저장되는 문제는 다루었지만, 두 요청이 같은 재고를 보고 내린 판단까지 조정했다고 말할 수 있는지는 별개의 문제다.변경을 함께 확정하는 것만으로, 그 변경을 결정한 판단까지 올바르게 만들 수 있을까?트랜잭션의 보장을 나누어 보자.무엇을 함께 확정하는지, 동시에 실행되는 작업이 서로를 어떻게 보는지, 성공한 변경이 어떤 장애에서 남는지는 서로 다른 질문이다.이 글은 “트랜잭..
댓글Data Engineering2026.09.27
수량 하나 바꿨는데, 왜 로그는 여러 종류가 필요할까?가상의 재고 수량을 10에서 9로 바꿨다.이 변경을 기록했다면 작업을 취소하거나, 서버 장애 뒤 복구하거나,다른 시스템에 전달할 때도 그 기록을 쓰면 될 것 같다.출발점은 같은 변경이기 때문이다.그런데 취소하려는 쪽에는 이전 상태로 돌아갈 정보가 필요하다.장애 복구 쪽에는 저장하지 못한 변경을 재현할 근거가,외부 프로그램에는 자신이 해석할 수 있는 변경 정보가 필요하다.한쪽에 충분한 기록이 다른 쪽에도 충분하다고 할 수 있을까?“변경을 남긴다”는 말만으로는 무엇을 남겨야 하는지 정해지지 않는다.같은 변경이라도 누가 어떤 상태를 만들려 하느냐에 따라, 필요한 기록은 어떻게 달라질까?MariaDB의 InnoDB와 binlog를 예로 Undo·Redo·Bi..
댓글Artificial Intelligence2026. 9. 30.
GPU 한 장을 여러 작업이 나눠 쓸 때, 무엇을 함께 쓰고 무엇을 따로 나눠야 할까?GPU 공유가 필요한 장면을 떠올려 보자.개발자 네 명이 각자의 주피터 노트북에서 작은 모델을 시험한다.한 사람의 작업은 10초 계산한 뒤 몇 분 동안 멈춰 있고, 다른 사람의 작업도 GPU 전체를 다 사용하지 않는다.네 사람에게 GPU를 한 장씩 주면 편하지만 대부분의 시간에는 비싼 장비가 놀게 된다.반대로 네 작업을 GPU 한 장에 무작정 몰아넣으면 다른 문제가 생긴다.한 작업이 GPU 메모리를 많이 차지해 이웃 작업이 메모리 부족으로 실패할 수 있고,오래 걸리는 계산 하나가 다른 사용자의 응답을 늦출 수도 있다.이때 선택할 수 있는 대표적인 방법이 시간 분할(Time Slicing)·MPS·MIG·vGPU다.네 방..
Data Engineering2026. 9. 29.
원본도 복제본도 살아 있다. 그런데 왜 서로 다른 값을 보여줄까?주문의 배송지를 A에서 B로 바꾼 뒤 장애가 났다고 하자.서버를 다시 띄우고 원본 DB를 확인했더니 B가 남아 있다.변경은 살아 있다.그런데 복제본에서는 A가 보인다.분석 화면도 그대로다.원본이 복구됐으니 잠시 기다리면 될까, 아니면 중간에서 변경을 잃은 걸까?배송지 하나를 두고도 확인할 곳이 여러 군데다.원본에 B가 남는 일, 다른 서버가 B를 받아들이는 일, 분석 화면에 B를 보여주는 일은 각각 따로 진행되기 때문이다.어디까지 확인해야, 데이터가 돌아왔다고 말할 수 있을까?이제 이 변경 한 건을 따라가 보자.배송지 사례는 차이를 설명하기 위한 가상 상황이다.DB 장애 복구는 어디까지 되살리는가?장애 직전, 메모리의 페이지에는 B가 있었지..
Data Engineering2026. 9. 28.
재고는 하나인데 두 요청이 동시에 주문하면, 트랜잭션만으로 막을 수 있을까?재고가 하나 남아 있다.두 요청이 거의 동시에 그 값을 읽고 각자 주문을 받아도 된다고 판단하는 상황을 생각해 보자.각 주문은 주문 기록을 만들고 재고를 수정한다.이 변경들을 트랜잭션으로 묶어 함께 확정하거나 취소하도록 했다.이제 안심해도 될까?각 작업이 반쪽만 저장되는 문제는 다루었지만, 두 요청이 같은 재고를 보고 내린 판단까지 조정했다고 말할 수 있는지는 별개의 문제다.변경을 함께 확정하는 것만으로, 그 변경을 결정한 판단까지 올바르게 만들 수 있을까?트랜잭션의 보장을 나누어 보자.무엇을 함께 확정하는지, 동시에 실행되는 작업이 서로를 어떻게 보는지, 성공한 변경이 어떤 장애에서 남는지는 서로 다른 질문이다.이 글은 “트랜잭..
Data Engineering2026. 9. 27.
수량 하나 바꿨는데, 왜 로그는 여러 종류가 필요할까?가상의 재고 수량을 10에서 9로 바꿨다.이 변경을 기록했다면 작업을 취소하거나, 서버 장애 뒤 복구하거나,다른 시스템에 전달할 때도 그 기록을 쓰면 될 것 같다.출발점은 같은 변경이기 때문이다.그런데 취소하려는 쪽에는 이전 상태로 돌아갈 정보가 필요하다.장애 복구 쪽에는 저장하지 못한 변경을 재현할 근거가,외부 프로그램에는 자신이 해석할 수 있는 변경 정보가 필요하다.한쪽에 충분한 기록이 다른 쪽에도 충분하다고 할 수 있을까?“변경을 남긴다”는 말만으로는 무엇을 남겨야 하는지 정해지지 않는다.같은 변경이라도 누가 어떤 상태를 만들려 하느냐에 따라, 필요한 기록은 어떻게 달라질까?MariaDB의 InnoDB와 binlog를 예로 Undo·Redo·Bi..