독자가 글을 읽고 읽기 목록을 저장하는 도서관 앱을 만든다고 가정해 봅시다. 운영팀은 계속 요청을 받는 프로세스와 재시작을 직접 제어해야 합니다. 개별 호출 단위의 관리로는 그 요구를 충족하지 못합니다. 기록 저장만으로 이 방식을 택할 이유가 되지는 않습니다.
어떻게 해결하는가
글 읽기와 도서관 읽기 목록 저장은 대기 중인 프로세스로 들어갑니다. 저장은 외부 저장소에 기록합니다. 반복 저장도 예제의 독자·글 키에 따라 기록 하나만 유지합니다. 다음 저장 실패는 저장소를 바꾸지 않고 실패를 반환합니다. 처리기 재시작은 프로세스만 바꾸고 기록을 유지합니다. 초기화·새로고침은 가상 저장소를 포함한 페이지 메모리 전체를 지웁니다.
프로세스 재시작과 기록 유지
개념 시뮬레이션
상시 서버
공개 글을 읽고 도서관 읽기 목록을 저장하세요. 반복 요청은 민아 / 도서관 읽기 목록을 공유합니다.
01 · 대기 프로세스 · 재시작 경계
GET
브라우저 → 대기 프로세스 → 글 HTML
POST 도서관 읽기 목록
브라우저 → 대기 프로세스 → 외부 저장소 → 확인 응답.
실행 세대: 1 · 이 세대의 호출: 0
실행 환경 담당
제품 팀 / 운영자
용량 비용
유휴 상태에도 확보
복구 책임
감시·재시작·복원
대기
저장소도 페이지 메모리의 모형입니다. 재시작은 유지하고 초기화·새로고침은 지웁니다. 중복 방지는 직접 작성한 앱 로직입니다.
본문 안의 가상 데모입니다. 초기화·새로고침으로 처음 상태로 돌아갑니다.
무엇이라 부르는가
상시 서버는 프로세스가 계속 요청을 기다리도록 운영하는 방식입니다. 재시작할 수 있으므로 이름이 무중단 가용성을 보장하지는 않습니다.
실행 환경 직접 제어, 지속 연결, 프로세스 단위 작업이 중요할 때 대기 프로세스를 검토합니다. 정적 호스팅은 미리 만든 파일을 제공하고 쓰기에는 다른 서비스가 필요합니다. 관리형 함수는 호출 배정을 제공자에게 맡기며 수명 제약도 다를 수 있습니다. 여러 호스팅 방식이 DB를 사용하므로 영속 저장만으로 상시 프로세스를 택하지는 않습니다.
02응용 사례
도서관 예제는 대기 프로세스와 외부 기록 저장소를 나눕니다. 읽기와 저장이 프로세스를 통과합니다. 재시작하면 실행 세대와 호출 수는 바뀌지만 기록은 남습니다. 초기화는 모형 전체를 지웁니다. 실제 운영에는 상태 확인·영속 저장·백업·복구 연습도 필요합니다. 프로세스 재시작 성공은 데이터 복원 가능성의 증거가 아닙니다.
03구현 참고·주의점
패치·감시·용량·복구 담당자를 정합니다. 확보한 용량은 유휴 시간에도 비용을 만들 수 있으므로 작업량과 제공자의 현재 조건을 비교한 뒤 견적을 냅니다. 응답이 유실되면 같은 요청이 재전송될 수 있으므로 중복 처리는 앱 규칙으로 정합니다. 관리형 플랫폼이 서버 업무 일부를 맡아도 앱 동작과 데이터 책임이 없어지지는 않습니다. 예제는 실제 서버나 저장소에 연결되지 않습니다.
이 선택에 관한 이야기
세 언어가 댓글을 공유합니다. 작성하려면 GitHub 로그인이 필요합니다.