파일·블록·영속 저장
프로그램이 메모리 값을 바꾸면 같은 실행 중에는 보이지만 전원이 꺼지면 사라질 수 있다. 파일 쓰기 함수가 성공해도 데이터가 운영체제의 임시 메모리에만 있고 장치에 아직 기록되지 않았을 수 있다. 반대로 모든 작은 변경을 즉시 영구 장치에 확정하면 속도가 크게 느려질 수 있다.
저장 요청이 끝났다고 데이터가 반드시 남은 것은 아니다
프로그램이 메모리 값을 바꾸면 같은 실행 중에는 보이지만, 전원이 꺼지면 사라질 수 있다. 파일 쓰기 함수가 성공해도 데이터가 운영체제의 임시 메모리에만 있고 장치에는 아직 기록되지 않았을 수 있다. 반대로 모든 작은 변경을 즉시 영구 장치에 확정하면 속도가 크게 느려질 수 있다.
이 사이에서 균형을 잡으려면 영속성과 파일, 블록을 함께 알아야 한다. 영속성은 실행과 전원이 끝난 뒤에도 상태가 남는 성질이고, 파일과 블록은 그 상태를 논리 이름과 실제 입출력 묶음으로 조직한다.
솔리드 스테이트 드라이브
솔리드 스테이트 드라이브(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의 버퍼 수용과 연결되며 장치 기록 완료와 다르다. |
|
|
| 장치와 비휘발 기록 장치 캐시 뒤 정한 비휘발 기록 조건이 충족돼야 영속 성공을 말한다. |
|
|
그림은 프로그램 메모리의 파일 쓰기 요청이 OS 파일·메모리 버퍼에서 저장 블록에 대응되고, 장치 대기열·캐시를 거쳐 비휘발 저장에 기록되는 경로다. 각 층은 작은 쓰기를 모아 효율적으로 처리할 수 있다. 따라서 프로그램에 반환된 “쓰기 완료”가 어느 단계의 완료인지 확인해야 한다. 반드시 남아야 하는 지점에서는 운영체제와 장치가 비휘발 매체까지 반영하도록 확정을 요청하고, 완료 전에 장애가 나면 어떻게 복구할지 기록 순서를 설계한다.
읽는 방식도 비용을 바꾼다. 연속 블록을 차례로 읽는 순차 접근은 다음 위치를 예측해 미리 가져오기 쉽다. 반면 멀리 떨어진 위치를 오가는 임의 접근은 위치 탐색과 캐시 실패가 늘 수 있다. SSD처럼 기계적 이동이 없는 장치에서도 큰 연속 요청과 수많은 작은 요청은 제어·전송 비용이 다르다.
PS-1: ACK 시점과 허용 손실량을 계산한다
ACK(acknowledgement)는 요청을 처리했다고 보내는 확인 응답이다. 여기서는 레코드 한 건마다 보내는 성공 응답을 뜻한다. flush는 버퍼의 내용을 저장 계층으로 내려보내는 요청이며, 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 뒤 판정 시작점으로 재설정하고 정한 영속 확정 성공을 확인한 경우다. |
|
|
그림은 승인 기록을 버퍼와 복구용 기록에 모아 flush를 요청하고, 영속 확정이 성공했을 때만 성공 ACK를 보내는 흐름이다. 확정이 끝나지 않았으면 성공 ACK를 보류하고 실패·미완료 상태를 확인한다. 즉 이 답안은 PS-1에서 비교한 선행 ACK 정책과 달리, 영속 완료 뒤에 응답하는 정책을 고른다.
25점 모범답안
먼저 결제 승인 ACK가 운영체제 버퍼에 들어간 완료인지, 비휘발 저장까지 끝난 완료인지 정한다. 전원 장애까지 견뎌야 하는 기록은 영속 확정이 끝난 뒤에 성공으로 알린다. 여기서는 저장매체 파손을 제외하고, 영속 확정에 성공한 데이터와 복구정보는 전원 차단 뒤에도 남는다는 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를 영속 확정 뒤에만 준다면, 정한 전원 장애와 정상 저장매체 조건에서 이미 ACK한 기록의 손실은 0건이다. ACK를 받지 못한 요청의 상태와 응답지연은 따로 확인한다.
저장 중에 새 레코드 3건도 먼저 ACK한다면, 10건 묶음이 아직 미확정일 때 추가 3건도 미확정이므로 최대 13건이 노출된다. 그래서 묶음 크기만 보지 말고 미확정 ACK 전체와 추가 유입 제한을 함께 계산한다.