본문 바로가기

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

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

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

소프트웨어개발156

Docker exec format error 해결: amd64·arm64·멀티플랫폼 이미지 점검 Mac에서 만든 Docker 이미지를 Linux 서버에 올렸더니 exec format error로 시작하지 않는다면 실행 파일의 CPU 아키텍처부터 확인하세요. Apple Silicon의 arm64와 일반적인 x86 서버의 amd64가 다를 수 있습니다. 다만 같은 오류가 시작 스크립트의 실행 형식에서도 생길 수 있으므로 “무조건 amd64로 설정”하는 해결법으로 끝내면 재발합니다. 이미지 플랫폼 → 실제 실행 파일 → ENTRYPOINT 순서로 점검하는 방법을 정리합니다.1. 오류가 난 실행 파일과 Docker 서버 위치를 확인하기먼저 오류에 나온 경로가 /bin/sh인지, 애플리케이션 바이너리인지, entrypoint.sh인지 기록합니다. Docker 명령을 실행하는 노트북과 실제 Docker 데몬의.. 2026. 10. 1.
Amazon MQ와 자체 RabbitMQ 비교: 메시지 브로커 비용·가용성·운영 책임 작업 큐나 서비스 간 메시지 전달에 RabbitMQ를 쓰려 할 때 Amazon MQ for RabbitMQ로 관리 부담을 줄일지, 직접 운영할지 고민하게 됩니다. 브로커를 관리할 인력이 부족하고 AWS 안의 애플리케이션과 연결하려면 관리형 구성을 먼저 검증할 수 있습니다. 반대로 필요한 버전·플러그인·세부 설정을 직접 통제해야 한다면 자체 운영도 후보입니다. 선택의 핵심은 서버 요금보다 장애 시 누가 무엇을 복구하며 메시지 재처리를 어떻게 다루는지입니다.1. 비교 대상은 RabbitMQ 기반의 같은 작업 흐름입니다이 글은 RabbitMQ 애플리케이션을 Amazon MQ for RabbitMQ와 자체 RabbitMQ에서 운영하는 상황을 비교합니다. Amazon MQ에는 다른 엔진도 있으므로 견적과 문서에서.. 2026. 10. 1.
S3와 Cloudflare R2 비교: 파일 다운로드 비용·S3 호환성·이전 체크리스트 Amazon S3와 Cloudflare R2 중 파일 저장소를 고를 때 저장 용량 단가만 비교하면 결론이 달라질 수 있습니다. 고객이 파일을 얼마나 자주 내려받는지, CDN을 거치는지, AWS 권한·암호화 기능에 얼마나 의존하는지를 함께 봐야 합니다. 외부 다운로드가 많은 서비스라면 R2의 전송료 구조를 검토할 가치가 있고, AWS 안에서 이미 운영 중인 파일 처리 체계가 있다면 S3를 유지하는 비용과 이전 비용을 먼저 비교하는 편이 합리적입니다. 이 글은 일반적인 첨부 파일·이미지·다운로드 서비스의 선택 기준을 정리합니다.1. 저장량과 다운로드량을 먼저 분리하세요저장량은 보관하고 있는 객체의 크기이고, 다운로드량은 이용자에게 전달한 데이터의 합계입니다. 100GB를 저장해도 같은 파일을 여러 번 내려받.. 2026. 10. 1.
PostgreSQL deadlock detected 해결: 40P01·잠금 순서·트랜잭션 재시도 PostgreSQL 로그에 deadlock detected가 나타나면 데이터베이스가 멈춘 것이 아니라 서로의 잠금을 기다리는 트랜잭션 중 하나를 중단해 순환을 끊은 상황입니다. 애플리케이션에는 보통 SQLSTATE 40P01로 전달됩니다. 무작정 max_connections를 올리거나 모든 세션을 종료하기 전에, 어떤 순서로 잠금을 잡았는지와 재시도 범위를 확인하세요. 이 글은 두 세션의 간단한 예와 운영 환경에서 증거를 모으는 방법을 설명합니다.1. 두 트랜잭션이 서로 기다리는 구조테스트 데이터베이스에 accounts(id, balance)라는 테이블과 id 1, 2가 있다고 가정합니다. 세션 A가 1번 행을 수정하고 세션 B가 2번 행을 수정한 뒤, 서로 상대가 잡은 행을 수정하려고 하면 대기 순환이.. 2026. 9. 30.
Kubernetes OOMKilled 해결: 메모리 limit·request·노드 압박 점검 순서 Kubernetes Pod가 반복 재시작되고 상태에 OOMKilled가 보인다면 먼저 '어느 컨테이너가 언제 왜 종료됐는지'를 확인하세요. 메모리 한도를 바로 올리면 잠시 안정될 수 있지만 누수, 동시 요청 증가, 메모리 기반 임시 볼륨 사용 같은 원인을 놓칠 수 있습니다. 이 글은 읽기 전용 명령으로 증거를 모으고, 애플리케이션 사용량과 클러스터 용량을 함께 고려해 수정하는 순서를 설명합니다.1. 종료 원인을 먼저 확정하세요Pod 이름·네임스페이스·컨테이너 이름을 실제 값으로 바꿔 다음 명령을 실행합니다. describe의 Last State, Reason, Exit Code, Events를 읽고 이전 컨테이너 로그를 보관하세요. 여러 컨테이너가 있는 Pod라면 문제가 난 컨테이너를 정확히 지정해야 합.. 2026. 9. 30.
Amazon MSK와 Confluent Cloud 비교: 관리형 Kafka 비용·네트워크·운영 기준 관리형 Kafka를 도입할 때 Amazon MSK와 Confluent Cloud 중 어느 쪽을 고르면 좋을까요? AWS 안에서 기존 네트워크·권한·모니터링을 결합해야 하는 팀은 MSK를 먼저 검토할 수 있습니다. 여러 클라우드와 Kafka 생태계 서비스를 함께 운영하려는 팀은 Confluent Cloud를 후보로 넣을 만합니다. 다만 두 서비스 모두 여러 클러스터 유형이 있어 'MSK 대 Confluent'라는 브랜드 비교만으로 비용이나 기능을 결정하면 안 됩니다.1. 비교할 클러스터 유형부터 정하세요Amazon MSK에는 용량과 브로커 유형을 정하는 Provisioned와 자동 확장을 제공하는 Serverless가 있습니다. MSK Serverless 공식 문서는 자동 용량 관리와 IAM 접근 제어 등.. 2026. 9. 30.

티스토리툴바