직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 AWS29 AWS Budgets 알림이 늦을 때: 예산 한도와 실제 사용 중단을 구분하기 AWS Budgets의 예산 금액은 모든 사용을 그 순간 차단하는 절대 한도가 아닙니다. 비용 반영과 알림 사이에 지연이 있으므로, 초과 원인을 찾을 때 실제 사용·집계·수신 시각을 따로 확인하세요.적용 환경: AWS 비용 예산, 예산 조회 권한이 있는 계정; 조직별 비용 범위는 별도 확인. 자료 확인일: 2026-10-27. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 사용과 비용 반영은 동시가 아니다AWS 문서는 Budgets 정보가 하루 최대 세 번 갱신되고, 보통 이전 갱신 후 8~12시간 간격이라고 설명합니다. 과금 반영까지 지연될 수 있어 알림이 도착하기 전에 추가 사용이 생길 수 있습니다.이 수치를 정확히 8시간마다 보내는 알림 약속으로 읽으면 안 됩니다. 수신한 숫자와 .. 2026. 10. 28. CloudWatch Logs 보존 기간을 줄이기 전: 삭제 시점과 복구 한계 확인 CloudWatch Logs 보존 기간을 줄이는 작업은 표시 옵션 변경이 아니라 오래된 로그의 삭제로 이어질 수 있는 변경입니다. 로그 그룹과 필요한 보존 기간을 확인하고, 이미 삭제된 로그는 기간을 다시 늘려도 돌아오지 않는다는 점부터 검토하세요.적용 환경: Amazon CloudWatch Logs 로그 그룹; 조직의 보존 의무와 별도 백업 여부는 담당자가 확인. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 보존 기준과 삭제 완료 시각을 혼동한 로그 그룹 안의 스트림들은 보존 설정을 공유합니다. 기본적으로 로그는 무기한 보존되며, 보존 설정을 바꾸면 기준을 지난 이벤트는 삭제 대상으로 표시됩니다. 실제 삭제에는 통상 최대 72시간이 걸리며 드물게 .. 2026. 10. 27. S3 파일은 없는데 용량이 남을 때: 미완료 멀티파트 업로드 점검 S3 객체 목록에서 파일을 찾지 못해도 완료하지 않은 멀티파트 업로드의 파트가 남아 있을 수 있습니다. 완료 객체 만료 규칙과 미완료 업로드 중단 규칙을 구분하고, 아직 진행 중인 작업인지 먼저 확인하세요.적용 환경: Amazon S3 일반 목적 버킷의 멀티파트 업로드; 완료 객체 만료와 구분. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 객체와 업로드 파트는 다른 상태대용량 전송을 여러 파트로 나누다가 완료 단계에 이르지 못하면 업로드 상태와 파트가 남을 수 있습니다. 객체 목록만 비교해서 사용량 차이를 전부 삭제 마커 때문이라고 결론 내리면 이 경로를 놓칩니다.운영 점검표에는 버킷, 업로드 식별자, 시작 시각, 전송 애플리케이션, 담당자를 나눠 .. 2026. 10. 27. Lambda 비동기 재시도: 함수 오류와 스로틀링을 구분해야 하는 이유 Lambda의 비동기 재시도 횟수는 모든 재실행을 막는 전역 스위치가 아닙니다. 먼저 비동기 호출인지 확인하고, 함수가 실행된 뒤 실패했는지 아니면 용량 부족으로 실행을 기다렸는지 나누세요.적용 환경: AWS Lambda의 비동기 호출; 동기 호출과 SQS 이벤트 소스 매핑은 별도 경로. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 서로 다른 실패를 같은 횟수로 셉니다함수 오류에는 코드 오류와 타임아웃 등이 포함됩니다. 공식 기본 동작은 함수 오류 후 추가 두 번의 시도입니다. 반면 스로틀링과 시스템 오류는 비동기 큐에서 재시도하며, 기본적으로 최대 6시간까지 이어질 수 있습니다. 실제 설정을 확인하지 않고 기본값을 운영값으로 단정하지 마세요.함수 .. 2026. 10. 26. SQS 작업이 두 번 실행될 때: 수신·처리·삭제 시각과 visibility timeout 점검 SQS에서 같은 작업이 다시 실행되면 visibility timeout부터 무작정 늘리지 마세요. 수신 시각, 업무 처리 완료 시각, 메시지 삭제 결과를 같은 작업 ID로 대조해야 긴 처리와 삭제 실패를 구분할 수 있습니다.적용 환경: Amazon SQS를 직접 소비하는 작업자; Lambda 이벤트 소스 매핑의 별도 설정은 제외. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 처리 성공과 큐에서 삭제는 별개수신한 메시지는 즉시 없어지지 않습니다. 잠시 다른 소비자에게 보이지 않다가, 삭제되지 않은 채 제한 시간이 끝나면 다시 받을 수 있습니다. 처리 성공 로그만 보고 큐의 완료까지 확정하면 이 구간을 놓칩니다.예를 들어 보고서 파일 생성은 끝났지만 삭.. 2026. 10. 26. S3 만료 후 용량이 남는 이유: 삭제 마커와 비현재 버전 구분 버전 관리가 켜진 S3 버킷에서는 현재 객체를 만료시켜도 이전 데이터 버전이 남을 수 있습니다. 목록에서 사라졌다는 사실과 저장 데이터가 영구 삭제됐다는 사실을 구분해야 합니다.적용 환경: Amazon S3 버전 관리 Enabled 버킷; Suspended와 Object Lock은 별도 확인. 공식 문서 확인일: 2026-10-23. 아래 내용은 문서 기반 점검 가이드이며 운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 현재 목록이 전체 저장량은 아닙니다Enabled 버킷의 현재 버전 만료는 삭제 마커를 현재 버전으로 만들고 기존 데이터를 비현재 버전으로 남기는 방식입니다. 비현재 버전도 저장되어 있는 동안 비용 검토 대상입니다. 삭제 마커는 원본 데이터의 영구 삭제 증명이 아닙니다.구분확인할 의.. 2026. 10. 24. 이전 1 2 3 4 5 다음
