Still Running
Field Notes
Explore
글 96개
DevOps, 클라우드(AWS·GCP·Azure), 빅데이터, AI를 다루는 기술 블로그. Kubernetes 운영, 클라우드 인프라 자동화, 데이터 엔지니어링 경험을 기록합니다.
Data Engineering2026.09.27
수량 하나 바꿨는데, 왜 로그는 여러 종류가 필요할까?가상의 재고 수량을 10에서 9로 바꿨다.이 변경을 기록했다면 작업을 취소하거나, 서버 장애 뒤 복구하거나,다른 시스템에 전달할 때도 그 기록을 쓰면 될 것 같다.출발점은 같은 변경이기 때문이다.그런데 취소하려는 쪽에는 이전 상태로 돌아갈 정보가 필요하다.장애 복구 쪽에는 저장하지 못한 변경을 재현할 근거가,외부 프로그램에는 자신이 해석할 수 있는 변경 정보가 필요하다.한쪽에 충분한 기록이 다른 쪽에도 충분하다고 할 수 있을까?“변경을 남긴다”는 말만으로는 무엇을 남겨야 하는지 정해지지 않는다.같은 변경이라도 누가 어떤 상태를 만들려 하느냐에 따라, 필요한 기록은 어떻게 달라질까?MariaDB의 InnoDB와 binlog를 예로 Undo·Redo·Bi..
댓글Data Engineering2026.09.26
집계가 느리면 DB를 하나 더 두는 게 답일까?주문 데이터가 운영 DB에 모두 있다.매출을 알고 싶다면 그곳에서 합계를 구하면 될 것 같다.같은 데이터를 다른 곳에 복사하면 저장 공간도 들고, 변경을 전달하는 일도 생긴다.굳이 나눌 이유가 있을까?그런데 주문 상태를 바로 확인해야 하는 요청과,많은 주문을 모아 계산하는 요청이 같은 자원을 쓴다고 생각해 보자.각각은 필요한 일이지만 한쪽의 넓은 작업이 다른 쪽의 응답에 영향을 줄 수 있다.데이터가 있는 곳과 그 데이터를 분석하기 좋은 곳이 반드시 같지는 않다.분석을 옮기면 끝일까?이번에는 원본과 복사본의 시차, 전달 실패, 추가 운영 비용을 감당해야 한다.함께 두면 자원을 나누고, 따로 두면 상태를 맞춰야 한다.어떤 조건에서 함께 처리하는 비용이, 나눠서 ..
댓글Data Engineering2026.09.25
데이터 파일에 아직 안 썼는데, 저장이 끝났다고 해도 될까?데이터를 안전하게 보관하려면 바꿀 때마다 데이터 파일에 저장하면 될 것 같다.메모리에서 수량을 바꿔도 파일에 남기기 전에 서버가 꺼지면 그 변경을 잃을 수 있기 때문이다.그런데 DB는 변경된 데이터 페이지를 모두 저장하기 전에 작업을 확정할 수 있다.아직 데이터 파일에 반영하지 않았는데,무엇을 근거로 끝났다고 말할 수 있을까?별도의 변경 기록을 먼저 남기는 방법이 있다.하지만 기록도 결국 저장해야 하는 데이터 아닌가?저장할 것을 하나 더 만드는 일이 어떻게 저장 비용과 복구 문제의 해법이 될 수 있을까?장애 뒤 상태를 되살리려면 완성된 상태를 남겨야 할까,그 상태를 다시 만들 근거를 먼저 남겨도 될까?이 질문에서 데이터 파일과 로그의 역할이 갈라..
댓글Data Engineering2026.09.24
재고는 줄었는데 출고 기록은 없다면, 성공한 걸까?가상의 재고 관리 프로그램에서 출고를 기록하는 버튼을 한 번 눌렀다.프로그램은 재고 수량을 줄인 뒤 출고 기록을 추가한다.그런데 두 번째 변경이 실패해 수량만 줄어든 채 남는다면, 출고 기록 작업은 성공한 걸까?두 변경의 순서를 바꾸면 해결될 것 같기도 하다.하지만 기록부터 남긴 다음 수량 수정이 실패하면 반대쪽만 남는다.무엇을 먼저 실행하느냐만으로는 반쪽짜리 결과를 피할 수 없다.문제는 사용자에게 하나인 작업이 DB에는 여러 변경으로 나뉜다는 데 있다.따로 실행되는 변경들의 성공과 실패를 어떻게 하나로 묶을까?트랜잭션(transaction)은 이 경계를 만든다.SQL 한 문장인 statement와는 단위가 다르다.한 문장 또는 여러 문장을 묶고, 작업을..
댓글Data Engineering2026. 9. 27.
수량 하나 바꿨는데, 왜 로그는 여러 종류가 필요할까?가상의 재고 수량을 10에서 9로 바꿨다.이 변경을 기록했다면 작업을 취소하거나, 서버 장애 뒤 복구하거나,다른 시스템에 전달할 때도 그 기록을 쓰면 될 것 같다.출발점은 같은 변경이기 때문이다.그런데 취소하려는 쪽에는 이전 상태로 돌아갈 정보가 필요하다.장애 복구 쪽에는 저장하지 못한 변경을 재현할 근거가,외부 프로그램에는 자신이 해석할 수 있는 변경 정보가 필요하다.한쪽에 충분한 기록이 다른 쪽에도 충분하다고 할 수 있을까?“변경을 남긴다”는 말만으로는 무엇을 남겨야 하는지 정해지지 않는다.같은 변경이라도 누가 어떤 상태를 만들려 하느냐에 따라, 필요한 기록은 어떻게 달라질까?MariaDB의 InnoDB와 binlog를 예로 Undo·Redo·Bi..
Data Engineering2026. 9. 26.
집계가 느리면 DB를 하나 더 두는 게 답일까?주문 데이터가 운영 DB에 모두 있다.매출을 알고 싶다면 그곳에서 합계를 구하면 될 것 같다.같은 데이터를 다른 곳에 복사하면 저장 공간도 들고, 변경을 전달하는 일도 생긴다.굳이 나눌 이유가 있을까?그런데 주문 상태를 바로 확인해야 하는 요청과,많은 주문을 모아 계산하는 요청이 같은 자원을 쓴다고 생각해 보자.각각은 필요한 일이지만 한쪽의 넓은 작업이 다른 쪽의 응답에 영향을 줄 수 있다.데이터가 있는 곳과 그 데이터를 분석하기 좋은 곳이 반드시 같지는 않다.분석을 옮기면 끝일까?이번에는 원본과 복사본의 시차, 전달 실패, 추가 운영 비용을 감당해야 한다.함께 두면 자원을 나누고, 따로 두면 상태를 맞춰야 한다.어떤 조건에서 함께 처리하는 비용이, 나눠서 ..
Data Engineering2026. 9. 25.
데이터 파일에 아직 안 썼는데, 저장이 끝났다고 해도 될까?데이터를 안전하게 보관하려면 바꿀 때마다 데이터 파일에 저장하면 될 것 같다.메모리에서 수량을 바꿔도 파일에 남기기 전에 서버가 꺼지면 그 변경을 잃을 수 있기 때문이다.그런데 DB는 변경된 데이터 페이지를 모두 저장하기 전에 작업을 확정할 수 있다.아직 데이터 파일에 반영하지 않았는데,무엇을 근거로 끝났다고 말할 수 있을까?별도의 변경 기록을 먼저 남기는 방법이 있다.하지만 기록도 결국 저장해야 하는 데이터 아닌가?저장할 것을 하나 더 만드는 일이 어떻게 저장 비용과 복구 문제의 해법이 될 수 있을까?장애 뒤 상태를 되살리려면 완성된 상태를 남겨야 할까,그 상태를 다시 만들 근거를 먼저 남겨도 될까?이 질문에서 데이터 파일과 로그의 역할이 갈라..
Data Engineering2026. 9. 24.
재고는 줄었는데 출고 기록은 없다면, 성공한 걸까?가상의 재고 관리 프로그램에서 출고를 기록하는 버튼을 한 번 눌렀다.프로그램은 재고 수량을 줄인 뒤 출고 기록을 추가한다.그런데 두 번째 변경이 실패해 수량만 줄어든 채 남는다면, 출고 기록 작업은 성공한 걸까?두 변경의 순서를 바꾸면 해결될 것 같기도 하다.하지만 기록부터 남긴 다음 수량 수정이 실패하면 반대쪽만 남는다.무엇을 먼저 실행하느냐만으로는 반쪽짜리 결과를 피할 수 없다.문제는 사용자에게 하나인 작업이 DB에는 여러 변경으로 나뉜다는 데 있다.따로 실행되는 변경들의 성공과 실패를 어떻게 하나로 묶을까?트랜잭션(transaction)은 이 경계를 만든다.SQL 한 문장인 statement와는 단위가 다르다.한 문장 또는 여러 문장을 묶고, 작업을..