파일·블록·영속 저장
프로그램이 메모리 값을 바꾸면 같은 실행 중에는 보이지만 전원이 꺼지면 사라질 수 있다. 파일 쓰기 함수가 성공해도 데이터가 운영체제의 임시 메모리에만 있고 장치에 아직 기록되지 않았을 수 있다. 반대로 모든 작은 변경을 즉시 영구 장치에 확정하면 속도가 크게 느려질 수 있다.
저장 요청이 끝났다고 데이터가 반드시 남은 것은 아니다
프로그램이 메모리 값을 바꾸면 같은 실행 중에는 보이지만 전원이 꺼지면 사라질 수 있다. 파일 쓰기 함수가 성공해도 데이터가 운영체제의 임시 메모리에만 있고 장치에 아직 기록되지 않았을 수 있다. 반대로 모든 작은 변경을 즉시 영구 장치에 확정하면 속도가 크게 느려질 수 있다.
영속성은 실행과 전원이 끝난 뒤에도 상태가 남는 성질이고, 파일과 블록은 그 상태를 논리 이름과 실제 입출력 묶음으로 조직한다.
솔리드 스테이트 드라이브
솔리드 스테이트 드라이브(Solid-State Drive, SSD)는 반도체 메모리에 데이터를 저장하여 전원이 끊겨도 내용을 유지하는 비휘발성 저장장치다. 기계식 자기 디스크와 달리 회전판과 이동식 헤드가 없지만, 쓰기 단위·지우기 단위·장치 내부 캐시와 제어기 때문에 모든 쓰기가 같은 비용이나 같은 영속성 보장을 갖는 것은 아니다.
먼저 되짚기: 빠른 층과 오래 남는 층은 역할이 다르다
메모리 계층은 속도·용량·가격이 다른 저장공간을 결합했다. 레지스터와 주 메모리는 빠르지만 일반적으로 전원이 끊기면 상태가 사라지는 휘발성 층이고, SSD와 자기 디스크는 더 느린 영속 층을 이룬다. 이번 절은 메모리 상태가 영속 저장으로 내려가는 경로를 본다.
빠른 휘발층에서 오래 남는 저장층으로 내려간다
메모리에서 비휘발 저장까지의 경로를 따라 OS 버퍼와 장치 캐시를 구분한다. 사용자 성공 응답이 어느 단계의 완료를 뜻하는지 정하는 것이 영속성 계약이다.
어느 지점의 완료를 사용자에게 성공으로 알리는지가 영속성 계약이다.
영속성
영속성은 프로세스나 전원이 끝난 뒤에도 상태가 남는 성질이다. “저장되었다”는 말은 어떤 실패 뒤에도 남아야 하는지에 따라 강도가 달라진다. 프로세스 재시작, 운영체제 장애, 갑작스러운 전원 차단 각각에서 보존 범위를 정하고 그에 맞는 확정 절차를 사용해야 한다.
파일과 블록 전에 영속성 경계를 다시 잇는다
영속성은 프로세스나 전원이 끝난 뒤에도 상태가 남는 성질이다. 파일과 블록은 이 영속 상태를 논리 이름과 실제 입출력 묶음으로 조직한다.
논리 파일 변경은 여러 물리 쓰기로 나뉠 수 있다
파일 내용과 메타데이터, 여러 블록이 서로 다른 순서로 기록될 수 있다. 중간 장애 뒤에도 어느 상태로 복구할지 기록순서와 확정점을 정한다.
파일과 블록
파일과 블록은 영속 데이터를 이름 있는 논리 단위와 장치의 입출력 단위로 조직하는 방식이다. 파일은 바이트열에 이름·길이·권한 같은 정보를 붙인 논리 단위다. 블록은 운영체제·장치의 해당 계층이 데이터를 읽고 쓰는 고정 크기 묶음이다. 파일시스템의 블록, 장치가 공개하는 논리 입출력 단위, SSD 내부의 기록·소거 단위가 모두 같은 크기이거나 같은 물리 위치를 뜻하지는 않는다. 파일의 일부 바이트만 바꿔도 해당 바이트가 든 블록을 읽고 수정해 다시 기록할 수 있다.
메모리의 주문 기록이 장치에 남는 경로
쓰기 요청과 비휘발 기록 완료는 서로 다른 지점이다 · 상태 따라가기
애플리케이션의 자료가 메모리에 있어도 비휘발 기록은 미확인이다. 모든 단계에서 파일 기록·영속 확인의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
프로그램이 파일에 쓰는 데이터는 OS의 파일·메모리 버퍼에서 파일 위치를 저장 블록에 대응하고, 장치의 대기열·캐시를 거쳐 비휘발 매체에 기록된다. 각 층이 작은 쓰기를 모을 수 있어 함수 반환만으로 마지막 단계의 완료를 알 수 없다. PS-1은 flush 성공 완료 뒤 전원 차단 복구를 약속하는 유한 교육 모형이다.
이 예의 조건
- 프로그램이 파일에 쓰는 데이터는 OS의 파일·메모리 버퍼에서 파일 위치를 저장 블록에 대응하고, 장치의 대기열·캐시를 거쳐 비휘발 매체에 기록된다. 각 층이 작은 쓰기를 모을 수 있어 함수 반환만으로 마지막 단계의 완료를 알 수 없다. PS-1은 flush 성공 완료 뒤 전원 차단 복구를 약속하는 유한 교육 모형이다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 프로그램 메모리 | 파일 쓰기 요청 |
| OS 파일·메모리 버퍼 | 파일 위치 → 저장 블록 |
| 장치 대기열·캐시 | 실제 매체 기록·완료 확인 |
| 비휘발 저장 | 정한 장애 후에도 복구 |
| 연결 | 원 라벨·방향 |
|---|---|
| 프로그램 메모리 → OS 파일·메모리 버퍼 | 라벨 없는 연결 / 정방향 / 실선 |
| OS 파일·메모리 버퍼 → 장치 대기열·캐시 | 라벨 없는 연결 / 정방향 / 실선 |
| 장치 대기열·캐시 → 비휘발 저장 | 라벨 없는 연결 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 메모리에 기록 애플리케이션의 자료가 메모리에 있어도 비휘발 기록은 미확인이다. |
|
|
| OS 수용 write 반환은 OS의 버퍼 수용과 연결되며 장치 기록 완료와 다르다. |
|
|
| 장치와 비휘발 기록 장치 캐시 뒤 정한 비휘발 기록 조건이 충족돼야 영속 성공을 말한다. |
|
|
쓰기 요청과 비휘발 기록 완료는 서로 다른 지점이다 · 상태 따라가기
애플리케이션의 자료가 메모리에 있어도 비휘발 기록은 미확인이다. 모든 단계에서 파일 기록·영속 확인의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
프로그램이 파일에 쓰는 데이터는 OS의 파일·메모리 버퍼에서 파일 위치를 저장 블록에 대응하고, 장치의 대기열·캐시를 거쳐 비휘발 매체에 기록된다. 각 층이 작은 쓰기를 모을 수 있어 함수 반환만으로 마지막 단계의 완료를 알 수 없다. PS-1은 flush 성공 완료 뒤 전원 차단 복구를 약속하는 유한 교육 모형이다.
이 예의 조건
- 프로그램이 파일에 쓰는 데이터는 OS의 파일·메모리 버퍼에서 파일 위치를 저장 블록에 대응하고, 장치의 대기열·캐시를 거쳐 비휘발 매체에 기록된다. 각 층이 작은 쓰기를 모을 수 있어 함수 반환만으로 마지막 단계의 완료를 알 수 없다. PS-1은 flush 성공 완료 뒤 전원 차단 복구를 약속하는 유한 교육 모형이다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 프로그램 메모리 | 파일 쓰기 요청 |
| OS 파일·메모리 버퍼 | 파일 위치 → 저장 블록 |
| 장치 대기열·캐시 | 실제 매체 기록·완료 확인 |
| 비휘발 저장 | 정한 장애 후에도 복구 |
| 연결 | 원 라벨·방향 |
|---|---|
| 프로그램 메모리 → OS 파일·메모리 버퍼 | 라벨 없는 연결 / 정방향 / 실선 |
| OS 파일·메모리 버퍼 → 장치 대기열·캐시 | 라벨 없는 연결 / 정방향 / 실선 |
| 장치 대기열·캐시 → 비휘발 저장 | 라벨 없는 연결 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 메모리에 기록 애플리케이션의 자료가 메모리에 있어도 비휘발 기록은 미확인이다. |
|
|
| OS 수용 write 반환은 OS의 버퍼 수용과 연결되며 장치 기록 완료와 다르다. |
|
|
| 장치와 비휘발 기록 장치 캐시 뒤 정한 비휘발 기록 조건이 충족돼야 영속 성공을 말한다. |
|
|
각 층은 작은 쓰기를 모아 효율적으로 처리할 수 있다. 따라서 프로그램에 반환된 “쓰기 완료”가 어느 단계의 완료인지 확인해야 한다. 반드시 남아야 하는 지점에서는 운영체제와 장치가 비휘발 매체까지 반영하도록 확정 요청하고, 완료 전에 장애가 나면 어떻게 복구할지 기록 순서를 설계한다.
연속 블록을 차례로 읽는 순차 접근은 다음 위치를 예측해 미리 가져오기 쉽다. 멀리 떨어진 위치를 오가는 임의 접근은 위치 탐색과 캐시 실패가 늘 수 있다. SSD처럼 기계적 이동이 없는 장치에서도 큰 연속 요청과 수많은 작은 요청은 제어·전송 비용이 다르다.
PS-1: ACK 시점과 허용 손실량을 계산한다
ACK(acknowledgement)는 요청을 처리했다고 보내는 확인 응답이다. 여기서는 레코드 한 건마다 보내는 성공 응답을 뜻한다. flush는 버퍼의 내용을 저장 계층으로 내려보내는 요청이며, 호출했다는 사실과 필요한 영속 확정이 끝났다는 사실은 다르다. 아래 교육용 모형에서는 flush가 성공 완료되어야 해당 묶음 전체가 전원 차단 뒤에도 복구된다고 약속한다.
가상 서비스는 기록을 한 건씩 메모리 버퍼에 넣자마자 ACK하고, 10건을 채우면 flush를 시작한다. flush가 끝날 때까지 새 레코드는 받지 않는다. 직전 묶음은 이미 영속 확정됐고, 저장매체 자체는 파손되지 않으며, 현재 묶음은 완료 전이라면 한 건도 남지 않을 수 있다고 가정한다.
| 장애 시점 | 새로 ACK한 수 | 새 묶음에서 복구를 보장한 수 | ACK 기록의 최대 손실 |
|---|---|---|---|
| 직전 flush 완료 직후 | 0 | 0 | 0 |
| 새 레코드 1~9건 접수 뒤 | 1~9 | 0 | 1~9 |
| 열 번째 ACK 뒤, flush 완료 전 | 10 | 0 | 10 |
| 새 묶음 flush 성공 완료 뒤 | 10 | 10 | 0 |
영속 확정이 끝나기 전에 장애가 나면 이미 ACK한 레코드의 최대 손실은 이 조건에서 10건이다. 10건 중 ACK 10건 − 복구 보장 0건 = 최대 손실 10건으로 읽는다. 9건이라는 답은 열 번째 ACK 뒤의 저장 진행 구간을 빠뜨린 것이다. 일부가 실제로 남을 수 있어도 완료 전의 보장으로 세지는 않는다.
반대로 같은 10건 묶음의 영속 확정이 성공한 뒤에만 ACK를 보낸다면, 이미 ACK한 기록의 손실은 이 장애·저장 계약 안에서 0건이다. 아직 응답하지 않은 요청까지 없었다는 뜻은 아니며, 각 요청은 묶음 구성과 영속 완료를 기다리는 지연을 부담한다.
저장 중에도 새 레코드를 계속 받고 먼저 ACK하도록 조건을 바꾸면 10건 상한도 유지되지 않는다. 기존 묶음의 영속 완료 전에 추가 3건을 ACK했고 모두 미확정이라면 최대 13건이 노출된다. 추가 유입·대기열에 제한이 없다면 묶음 크기만으로 전체 손실 상한을 정할 수 없다.
따라서 “write 함수가 성공했다”가 아니라 어느 층까지 반영된 뒤 성공을 반환하는지를 계약한다. 결제 승인처럼 손실 허용도가 낮은 기록과 다시 계산 가능한 캐시는 같은 정책을 쓰지 않는다.
부분 쓰기 복구도 결과를 실제로 비교해 보자. 교육용 상태가 (금액 100, 상태 접수)에서 (금액 120, 상태 확정)으로 바뀌며 두 항목이 서로 다른 블록에 놓였다고 가정한다. 첫 블록만 기록한 뒤 전원이 끊기면 (120, 접수)라는 섞인 상태가 남을 수 있다. 이 사례에서는 변경번호와 변경 후 두 항목 전체를 복구용 기록에 먼저 남기고 영속 확정한 뒤, 그 변경의 완료 표시를 영속 확정하며, 그다음 원래 두 블록을 갱신한다. 복구용 전체 기록과 완료 표시가 온전히 남았는지 판정할 수 있고 기존 상태도 별도로 보존된다는 가정을 둔다.
재시작에서는 완료 표시가 없는 변경을 채택하지 않아 기존 (100, 접수)를 유지한다. 완료 표시가 온전히 있으면 두 블록을 변경 후 전체 기록으로 맞춰 (120, 확정)을 복원한다. 따라서 원래 블록 중 하나만 새 값이어도 완전한 앞 상태 또는 뒤 상태로 맞출 근거가 있다. 완료 표시까지 영속 확정한 뒤 성공 ACK를 보내며, 복구용 기록·완료 표시·각 블록 쓰기 사이에 각각 장애를 넣어 이 두 상태 외의 결과가 없는지 대조한다. 이는 복구 원리를 설명한 유한 교육 모형이며 실제 로그·파일시스템의 원자성 보장은 제품 계약과 별도 검증이 필요하다.
선택의 기준
| 선택 | 이익 | 대가 | 확인할 질문 |
|---|---|---|---|
| 메모리 버퍼 후 일괄 기록 | 빠른 응답·묶음 처리 | 장애 직전 변경 손실 가능 | 얼마만큼 잃어도 되는가 |
| 매번 영속 확정 | 손실 범위 축소 | 지연·입출력 증가 | 어떤 기록만 반드시 즉시 남나 |
| 순차 배치 | 높은 전송 효율 | 원하는 한 항목까지 기다릴 수 있음 | 지연과 처리량 중 무엇이 우선인가 |
| 인덱스 기반 임의 접근 | 특정 항목 빠른 탐색 | 추가 저장·갱신 비용 | 읽기와 쓰기 비율은 어떠한가 |
영속성은 모든 데이터에 똑같이 적용하지 않는다. 다시 계산 가능한 임시 결과와 결제 승인 기록의 손실 허용도는 다르다. 데이터별 복구 목표와 증거 필요성을 정해 확정 빈도와 복제·백업 방법을 선택한다.
실패조건과 방어
버퍼 완료를 영속 완료로 오해하면 전원 장애 때 최근 기록이 사라진다. API의 완료 의미와 장치 확정 경계를 확인한다.
부분 쓰기에서는 여러 블록 중 일부만 새 값이 된다. 이전 또는 이후 중 하나의 완전한 상태로 복구할 기록과 순서를 둔다.
작은 임의 쓰기 남발은 블록 단위 입출력과 부가 기록을 폭증시킨다. 묶음·정렬·로그 구조를 검토하되 허용 지연을 넘지 않는다.
파일 이름만 보호하면 파일 내용이 남아도 권한·경로·메타데이터 손실로 파일을 찾거나 읽지 못할 수 있다. 데이터와 메타데이터를 함께 백업·검증한다.
백업 존재를 복구 성공으로 오해하면 실제 복원과 최신성 확인을 생략하게 된다. 복구 절차를 정기적으로 실행해 시간과 손실 범위를 측정한다.
자체 10점 문제
파일·블록·영속성의 관계와 장애 시 데이터 보존방안을 설명하시오.
요구어는 설명이다. 버퍼→블록→비휘발 매체의 단계와 ACK·복구 경계를 연결한다.
10점 풀이 방향과 모범답안 보기
10점 답안 목차
- 영속성
- 파일과 블록
- OS·장치 버퍼
- flush/확정
- 부분쓰기·복구
- 백업·복원 검증
10점 답안 도식
저장 경로에서 ACK 경계를 선택한다. OS 버퍼 접수 뒤 선행 ACK와 영속 확정 뒤 ACK를 PS-1의 손실·지연 비교로 대조한다.
모범답안 축약본: 쓰기 완료의 지점을 명시한다
문제: 파일·블록·영속성의 관계와 장애 시 데이터 보존방안을 설명하시오. 영속성은 프로세스 종료나 전원 차단 뒤에도 상태가 남는 성질이며 견딜 장애 범위를 명시해야 한다. 파일은 이름·길이·권한을 가진 논리 바이트열이고, 블록은 운영체제·저장장치의 계층별 고정 크기 입출력 묶음이며 실제 매체의 기록·소거 단위와 구별한다. 프로그램의 쓰기는 운영체제 버퍼, 장치 대기열·캐시, SSD나 디스크 매체를 차례로 거칠 수 있으므로 함수 성공이 곧 비휘발 매체 확정을 뜻하지 않는다. 반드시 남아야 하는 기록은 데이터와 메타데이터의 쓰기 순서를 정하고 적절한 확정 요청과 로그·복구 절차를 사용한다. 작은 임의 쓰기는 블록 갱신비용을 키우므로 묶음·순차 처리를 고려하되 허용 손실시간과 지연 요구를 우선한다. 백업 존재만 믿지 말고 권한·경로·메타데이터를 포함해 실제 복원하고 복구시간과 손실범위를 측정한다.
자체 25점 문제
결제 승인기록의 성능과 영속성을 함께 만족하는 저장·복구 절차를 설계하시오.
요구어는 설계다. 성공 ACK의 의미, flush, 부분쓰기, 재시작·복원 증거를 명시한다.
25점 풀이 방향과 모범답안 보기
25점 답안 목차
- 보존해야 할 장애범위
- ACK 의미
- 버퍼·flush 정책
- 파일·블록·메타데이터 순서
- 부분쓰기 복구
- 복구용 전체 기록과 영속 완료 표시
- 백업·복원
- 지연·손실량 검증
25점 답안 도식
영속 확정 성공을 확인한 뒤에만 성공 ACK를 보낸다 · 상태 따라가기
승인 기록을 버퍼·복구용 전체 상태에 모으고 flush를 요청한다. 모든 단계에서 PS1 기록·ACK의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
승인 기록을 버퍼·복구용 기록에 모아 flush를 요청한다. 정한 영속 확정 성공을 확인하면 ACK를 보내고, 완료 전 실패에는 성공을 알리지 않는다. PS-1은 저장 중 새 레코드를 받지 않으며 저장매체 파손을 제외한다. 복구용 전체 기록·완료 표시의 순서와 재시작 비교는 본문 계약을 따른다.
이 예의 조건
- 승인 기록을 버퍼·복구용 기록에 모아 flush를 요청한다. 정한 영속 확정 성공을 확인하면 ACK를 보내고, 완료 전 실패에는 성공을 알리지 않는다. PS-1은 저장 중 새 레코드를 받지 않으며 저장매체 파손을 제외한다. 복구용 전체 기록·완료 표시의 순서와 재시작 비교는 본문 계약을 따른다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 승인 기록 | 원그림의 대상 |
| 버퍼·복구용 기록 | 변경 후 전체 상태 보존 |
| flush 요청 | 호출과 완료는 다름 |
| 영속 확정 성공? | 원그림의 대상 |
| 성공 ACK | 이미 ACK한 기록의 손실 0건 |
| 성공 ACK 보류 | 실패·미완료 상태 확인 |
| 연결 | 원 라벨·방향 |
|---|---|
| 승인 기록 → 버퍼·복구용 기록 | 라벨 없는 연결 / 정방향 / 실선 |
| 버퍼·복구용 기록 → flush 요청 | 라벨 없는 연결 / 정방향 / 실선 |
| flush 요청 → 영속 확정 성공? | 라벨 없는 연결 / 정방향 / 실선 |
| 영속 확정 성공? → 성공 ACK | 성공 / 정방향 / 실선 |
| 영속 확정 성공? → 성공 ACK 보류 | 미완료 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 기록 모아 flush 요청 승인 기록을 버퍼·복구용 전체 상태에 모으고 flush를 요청한다. |
|
|
| 대안 1: 미완료·실패 flush 뒤 영속 확정 판정에서 미완료나 실패인 경우다. |
|
|
| 대안 2: 성공 판정 뒤 ACK flush 뒤 판정 시작점으로 재설정하고 정한 영속 확정 성공을 확인한 경우다. |
|
|
영속 확정 성공을 확인한 뒤에만 성공 ACK를 보낸다 · 상태 따라가기
승인 기록을 버퍼·복구용 전체 상태에 모으고 flush를 요청한다. 모든 단계에서 PS1 기록·ACK의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.
상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.
승인 기록을 버퍼·복구용 기록에 모아 flush를 요청한다. 정한 영속 확정 성공을 확인하면 ACK를 보내고, 완료 전 실패에는 성공을 알리지 않는다. PS-1은 저장 중 새 레코드를 받지 않으며 저장매체 파손을 제외한다. 복구용 전체 기록·완료 표시의 순서와 재시작 비교는 본문 계약을 따른다.
이 예의 조건
- 승인 기록을 버퍼·복구용 기록에 모아 flush를 요청한다. 정한 영속 확정 성공을 확인하면 ACK를 보내고, 완료 전 실패에는 성공을 알리지 않는다. PS-1은 저장 중 새 레코드를 받지 않으며 저장매체 파손을 제외한다. 복구용 전체 기록·완료 표시의 순서와 재시작 비교는 본문 계약을 따른다.
- 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.
관계도의 보충 설명
| 대상 | 원 설명 |
|---|---|
| 승인 기록 | 원그림의 대상 |
| 버퍼·복구용 기록 | 변경 후 전체 상태 보존 |
| flush 요청 | 호출과 완료는 다름 |
| 영속 확정 성공? | 원그림의 대상 |
| 성공 ACK | 이미 ACK한 기록의 손실 0건 |
| 성공 ACK 보류 | 실패·미완료 상태 확인 |
| 연결 | 원 라벨·방향 |
|---|---|
| 승인 기록 → 버퍼·복구용 기록 | 라벨 없는 연결 / 정방향 / 실선 |
| 버퍼·복구용 기록 → flush 요청 | 라벨 없는 연결 / 정방향 / 실선 |
| flush 요청 → 영속 확정 성공? | 라벨 없는 연결 / 정방향 / 실선 |
| 영속 확정 성공? → 성공 ACK | 성공 / 정방향 / 실선 |
| 영속 확정 성공? → 성공 ACK 보류 | 미완료 / 정방향 / 실선 |
| 관찰·상황 | 값·보충 정보 | 변화·이유 |
|---|---|---|
| 기록 모아 flush 요청 승인 기록을 버퍼·복구용 전체 상태에 모으고 flush를 요청한다. |
|
|
| 대안 1: 미완료·실패 flush 뒤 영속 확정 판정에서 미완료나 실패인 경우다. |
|
|
| 대안 2: 성공 판정 뒤 ACK flush 뒤 판정 시작점으로 재설정하고 정한 영속 확정 성공을 확인한 경우다. |
|
|
영속 완료 전 실패에는 성공 ACK를 보내지 않는다. PS-1에서 비교한 선행 ACK 정책과 달리 이 답안은 영속 완료 뒤 응답하는 정책을 선택한다.
25점 모범답안
먼저 결제 승인 ACK가 운영체제 버퍼 완료인지 비휘발 저장 완료인지 계약하고 전원 장애까지 견뎌야 하는 기록은 durable commit 뒤에 성공으로 알린다. 여기서는 저장매체 파손은 제외하고, 영속 확정에 성공한 데이터·복구정보는 전원 차단 뒤에도 남는다는 PS-1의 계약을 사용한다.
PS-1의 10건 묶음은 flush 성공 완료 뒤에만 성공 ACK를 보낸다. 저장 진행 중에는 새 레코드를 받지 않고, 완료 전 장애에는 성공을 알리지 않는다. 먼저 ACK하는 대안은 열 번째 ACK 뒤 장애에서 최대 10건을 잃을 수 있으므로, ACK한 승인 기록의 손실을 허용하지 않는 이 사례에서는 선택하지 않는다. 묶음 대기와 저장 완료 지연은 별도로 측정한다.
여러 블록과 메타데이터가 일부만 기록될 수 있으므로 이전 또는 이후의 완전한 상태로 복구할 기록·순서를 둔다. 저장 시작 전·진행 중·성공 완료 후에 각각 장애를 넣고, ACK 목록과 재시작 후 복구한 기록을 대조한다. 성공 ACK한 기록이 하나라도 사라지면 이 계약을 충족하지 못한 것으로 판정한다.
부분 쓰기에는 앞의 교육용 복구 모형을 적용한다. 변경번호와 변경 후 전체 상태를 먼저 영속 기록하고, 완료 표시를 영속 확정한 뒤 원래 블록을 갱신한다. 완료 표시가 없으면 보존한 이전 상태, 온전한 완료 표시가 있으면 전체 새 상태로 맞춰 섞인 금액·상태를 채택하지 않는다. 완료 표시의 온전함을 판정할 수 있다는 가정과 단일 묶음 처리 조건을 함께 명시하고, 표시 전후 및 각 블록 사이 장애에서 같은 복구 결과를 확인한다.
새 적용 조건: 10건을 기다리는 동안 유입이 멈춘다면? PS-1의 기존 10건 묶음 손실 계산은 그대로 둔다. 실제 서비스에 이 정책을 적용하려면 1~9건만 들어온 뒤 멈출 때의 완료 규칙도 필요하다. 추가 조건으로 첫 미완료 레코드가 들어온 뒤 최대 1초가 지나거나 입력을 정상 종료하면 현재 묶음을 flush한다고 정해 보자. 기록이 3건만 들어와도 이 조건에서 저장을 시작하지만 성공 ACK는 여전히 영속 완료 뒤에 보낸다. 1초는 저장 시작까지의 묶음 대기 상한이며 저장 완료시간까지 보장하는 수치가 아니다. 저유입·정상 종료·flush 실패 각각에서 ACK 시점과 미완료 상태를 따로 검증한다.
백업은 존재 확인으로 끝내지 않고 실제 복원해 복구시간과 손실범위를 측정한다. 다시 계산 가능한 보조데이터에는 다른 묶음정책을 검토할 수 있지만, flush를 늦추거나 저장 중 선행 ACK를 추가하는 변경은 손실 상한과 지연을 다시 검증한다.
출처와 적용 경계
본문은 안정된 영속성·파일·블록 개념과 자체 flush 예를 사용한다. 쓰기 반환이 매체 확정을 뜻하지 않는 Linux의 구체 경계는 write(2) NOTES, 파일 데이터·메타데이터 확정과 별도 디렉터리 확정 필요는 fsync(2) DESCRIPTION에서 확인할 수 있다. 이 Linux 예를 모든 장치나 저장 API의 동일한 보장으로 확대하지 않는다. 실제 파일시스템·SSD의 cache flush·barrier·atomicity 보장은 운영체제와 장치 사양을 확인한다.
30초 정리
- 영속성은 프로세스나 전원이 끝난 뒤에도 상태가 남는 성질이며 어떤 실패까지 견딜지 명시해야 한다.
- 파일은 이름 있는 논리 바이트열, 블록은 실제 입출력 묶음이다.
- 버퍼링과 순차 처리는 성능을 높이지만 최근 손실과 지연의 대가가 있으므로 데이터별 복구 요구로 판단한다.
자기교정과 조건 변경
| 잘못 쓴 답 | 수정 | 복습 |
|---|---|---|
| write 성공이면 전원 장애 뒤에도 반드시 남는다 | 버퍼 접수와 영속 완료가 다르므로 API가 어느 층의 완료를 뜻하는지 확인한다 | 경로 |
| 10건마다 flush하면 어떤 시점에도 최대 9건만 잃는다 | 열 번째 ACK 뒤 영속 완료 전에는 10건 모두 미확정일 수 있다. 저장 중 추가 유입을 막은 PS-1의 최대는 10건이다 | PS-1 |
| 모든 기록은 매번 즉시 flush해야 한다 | 재계산 가능성과 손실 허용도가 다르므로 지연 요구와 함께 정책을 나눈다 | 선택 |
| 파일 내용만 백업하면 항상 복구된다 | 권한·경로·메타데이터도 필요하므로 함께 보존하고 실제 복원한다 | 실패 |
| 부분쓰기는 최신값 일부가 남아도 성공이다 | 중간 상태는 약속한 결과가 아니므로 완전한 이전/이후 상태로 복구할 규칙을 둔다 | 영속성 |
flush를 5건마다 하면? 버퍼에서 먼저 ACK하고 저장 중 추가 유입을 막는 같은 조건이면 다섯 번째 ACK 뒤 영속 완료 전 장애에서 최대 5건을 잃을 수 있다. 4건은 다섯 번째 ACK 이전 구간만 센 값이다.
ACK를 durable commit 뒤에만 주면? 정한 전원 장애·정상 저장매체 계약에서 이미 ACK한 기록의 손실은 0건이다. ACK를 받지 못한 요청의 상태와 응답지연은 별도로 확인한다.
저장 중 새 레코드 3건도 먼저 ACK하면? 10건 묶음이 아직 미확정인 때 추가 3건도 미확정이면 최대 13건이 노출된다. 묶음 크기만이 아니라 미확정 ACK 전체와 추가 유입 제한을 계산한다.