본문 바로가기

직접 만든 소프트웨어, 두 가지 개발 기록

구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다.

MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조

소프트웨어개발156

Docker x509 인증서 오류 해결: unknown authority·사내 CA·프록시 점검 순서 AI로 제작한 개념 일러스트입니다. TLS 오류는 인증서를 검증하는 실행 환경과 신뢰 체인을 나누어 확인합니다.Docker에서 x509: certificate signed by unknown authority 오류가 나타나면 비밀번호부터 바꾸기보다 어느 실행 주체가 TLS 인증서를 검증하지 못하는지 확인하세요. docker pull 단계의 데몬, Docker Desktop의 호스트 환경, 컨테이너 안의 프로그램은 인증서를 신뢰하는 위치가 다를 수 있습니다. 같은 주소가 브라우저에서 열린다는 사실만으로 Docker에서도 신뢰된다고 판단하기는 어렵습니다.1. 오류가 발생한 위치부터 구분하기이미지 다운로드가 실패했는지, 이미 실행된 컨테이너에서 사내 API 호출이 실패했는지 기록합니다. 첫 번째는 레지스트리와.. 2026. 9. 28.
기업용 컨테이너 레지스트리 선택: Amazon ECR·Docker Hub 권한·스캔·비용 비교 AI로 제작한 개념 일러스트입니다. 레지스트리 선택은 저장뿐 아니라 접근 권한과 배포 경로까지 포함합니다.팀의 Docker 이미지를 어디에 보관할지 결정할 때는 저장 공간만 비교하면 부족합니다. CI가 이미지를 올리고 운영 환경이 내려받는 과정에서 인증, 접근 권한, 취약점 검사와 롤백용 이미지 보존이 모두 연결됩니다. AWS 중심 팀은 Amazon ECR, 다양한 환경과 공개 배포를 함께 다루는 팀은 Docker Hub를 후보로 두고 실제 배포 경로를 시험해 보세요.1. 레지스트리는 실행 서버와 역할이 다릅니다컨테이너 레지스트리는 이미지를 저장하고 배포 환경에 전달합니다. 이미지를 보관했다고 웹 서비스가 실행되는 것은 아닙니다. 저장소 이름·태그·다이제스트와 실행 환경의 인증이 맞아야 배포할 수 있습니.. 2026. 9. 28.
ECS Fargate와 EC2 비교: 컨테이너 운영 비용·관리 책임·도입 체크리스트 AI로 제작한 개념 일러스트입니다. Fargate와 EC2 선택에서는 비용과 서버 관리 책임을 함께 비교합니다.ECS에서 컨테이너를 운영하려는데 Fargate와 EC2 중 무엇을 선택해야 할까요? 서버 관리 인력이 적고 표준적인 웹 API를 빠르게 운영하려면 Fargate부터 검증할 수 있습니다. 반대로 특정 하드웨어·커스텀 운영체제·높은 서버 제어권이 필요하면 ECS on EC2가 후보입니다. 어느 쪽이 항상 저렴하다는 결론보다 같은 서비스 수준에서 월간 비용과 운영 책임을 비교하는 것이 먼저입니다.1. ECS와 Fargate는 같은 층의 제품이 아닙니다ECS는 작업과 서비스를 배치하고 유지하는 컨테이너 오케스트레이션 서비스입니다. Fargate와 EC2는 그 작업을 실행할 용량을 제공하는 선택지입니다.. 2026. 9. 28.
DNS_PROBE_FINISHED_NXDOMAIN 해결: 도메인·네임서버·DNS 레코드·캐시 점검 그림: 정확한 호스트 이름부터 네임서버·DNS 응답·캐시를 순서대로 확인하는 NXDOMAIN 진단 흐름입니다. 직접 제작한 개념도입니다.브라우저에 DNS_PROBE_FINISHED_NXDOMAIN이 표시되면 HTTP 서버까지 도달하기 전에 이름 해석이 실패했을 수 있습니다. 서버 재시작보다 주소 오타, 도메인 등록 상태, 네임서버 위임과 요청한 호스트의 레코드를 먼저 확인하세요. 루트 도메인과 www는 서로 다른 이름이므로 한쪽이 열려도 다른 쪽이 자동으로 연결되지는 않습니다.1. NXDOMAIN과 다른 DNS 실패를 구분하기DNS 응답의 NXDOMAIN은 조회한 이름이 존재하지 않는다는 의미입니다. 기존 이름에 요청한 형식의 레코드만 없는 응답(NODATA), DNS 서버 처리 실패(SERVFAIL),.. 2026. 9. 27.
PostgreSQL too many connections 해결: 연결 수 진단·풀 설정·max_connections 점검 그림: 연결 현황을 관찰하고 앱 전체의 풀 예산을 계산한 뒤 누수를 수정·검증하는 흐름입니다. 직접 제작한 개념도입니다.PostgreSQL에서 too many connections 또는 예약된 연결 슬롯 관련 오류가 나오면 새 접속을 받아 줄 여유가 부족할 가능성이 큽니다. 먼저 접속이 어디서 늘어났는지 확인하고, 앱 인스턴스 전체의 풀 크기를 계산하세요. max_connections를 바로 올리면 원인은 남고 메모리·운영 부담만 커질 수 있습니다.1. 오류 발생 위치와 시점을 확인하기앱 로그의 시간·DB 주소·배포 직후 여부를 기록합니다. DB 서버의 슬롯 부족인지, 중간 프록시나 앱 풀의 대기 시간 초과인지 구분해야 합니다. 운영자가 접속할 수 있다면 아래 읽기 전용 쿼리로 설정과 연결 분포를 확인합.. 2026. 9. 27.
관리형 PostgreSQL 선택: 자체 운영·Amazon RDS·Cloud SQL 비교와 비용 체크리스트 그림: 애플리케이션 연결부터 데이터베이스 운영·가용성·복구 시험까지 평가하는 관리형 PostgreSQL 선택 구조입니다. 직접 제작한 개념도입니다.PostgreSQL을 클라우드로 옮길 때 서버 요금만 비교하면 백업 복구, 장애 대응과 업데이트에 드는 일을 놓치기 쉽습니다. 자체 운영은 통제 범위가 넓고, 관리형 서비스는 일부 운영 작업을 서비스 제공자에게 맡길 수 있습니다. Amazon RDS와 Google Cloud SQL을 선택할 때는 기존 클라우드와의 연결, 필요한 확장 기능, 복구 목표와 전체 비용을 같은 조건으로 비교하세요.1. 자체 운영과 관리형 DB의 책임 범위선택장점주의할 점VM·서버 자체 운영OS·설치·확장 구성의 통제 범위가 넓음패치·백업·장애 전환을 직접 운영Amazon RDS for.. 2026. 9. 27.

티스토리툴바