직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 서버운영14 GitHub 웹훅 IP 추가: 수신 허용목록과 서명 검증을 함께 확인하세요 GitHub 웹훅의 새 IP 범위를 수신 허용목록에 반영하는 일과, 들어온 요청의 서명을 검증하는 일은 따로 확인해야 합니다. 2026년 10월 29일 공지는 정적 허용목록을 관리하는 운영자에게 영향을 줄 수 있는 변경입니다. 다만 최근 배포 알림이 오지 않았다는 사실만으로 이 변경을 장애 원인으로 확정하지는 마세요.GitHub의 웹훅 IP 추가 공지는 Meta API의 hooks 항목에 범위를 추가했다고 알립니다. 정적 목록을 사용한다면 기존 범위와 함께 추가하고, Meta API로 목록을 계속 동기화하고 있다면 이번 추가 때문에 별도 변경할 필요는 없다는 안내예요. github.com의 모든 플랜에 적용된다고 명시하며 Enterprise Cloud도 포함합니다.누락된 알림을 보면 어느 지점부터 확인할.. 2026. 11. 5. 원격 로그는 남는데 docker logs는 짧을 때: dual logging 캐시 확인 원격 저장소에 로그가 남아 있는데 docker logs에서 오래된 기록이 보이지 않으면 dual logging의 로컬 캐시 범위를 확인하세요. 원격 보존 기간과 로컬 조회 캐시는 서로 다른 저장 경로입니다.적용 환경: Docker Engine 컨테이너; 애플리케이션 출력과 실제 컨테이너 로깅 설정을 확인할 권한 필요. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 원격 저장과 로컬 조회는 다름Docker Engine은 로그 읽기를 지원하지 않는 드라이버를 사용할 때 dual logging을 자동으로 활성화합니다. local 드라이버를 캐시로 사용해 최근 로그를 읽게 하지만 이 캐시가 원격 저장소 전체를 조회하는 창은 아닙니다.기본 캐시는 컨테이너당 압.. 2026. 10. 27. S3 파일은 없는데 용량이 남을 때: 미완료 멀티파트 업로드 점검 S3 객체 목록에서 파일을 찾지 못해도 완료하지 않은 멀티파트 업로드의 파트가 남아 있을 수 있습니다. 완료 객체 만료 규칙과 미완료 업로드 중단 규칙을 구분하고, 아직 진행 중인 작업인지 먼저 확인하세요.적용 환경: Amazon S3 일반 목적 버킷의 멀티파트 업로드; 완료 객체 만료와 구분. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 객체와 업로드 파트는 다른 상태대용량 전송을 여러 파트로 나누다가 완료 단계에 이르지 못하면 업로드 상태와 파트가 남을 수 있습니다. 객체 목록만 비교해서 사용량 차이를 전부 삭제 마커 때문이라고 결론 내리면 이 경로를 놓칩니다.운영 점검표에는 버킷, 업로드 식별자, 시작 시각, 전송 애플리케이션, 담당자를 나눠 .. 2026. 10. 27. systemd 설정이 반영되지 않을 때: daemon-reload·reload·restart 구분 systemd 유닛 파일을 수정했다면 daemon-reload로 관리자에게 다시 읽게 해야 합니다. 그러나 이것만으로 실행 중인 서비스가 새 실행 조건으로 바뀌지는 않습니다. 서비스 자체 설정 재읽기와 프로세스 재시작을 구분하세요.적용 환경: systemd 255 공식 문서 기준; 설치 버전과 배포판 정책은 적용 전 확인. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 서로 다른 설정 파일을 같은 방식으로 반영동작대상daemon-reloadsystemd 관리자와 유닛 구성reload서비스 자체의 지원되는 설정 재읽기restart서비스를 중지한 뒤 다시 시작웹 서버 설정과 systemd 서비스 유닛은 담당하는 프로그램이 다릅니다. 변경한 파일이 어느 쪽.. 2026. 10. 26. 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. 이전 1 2 3 다음
