NGINX란?웹 서빙, 리버스 프록시, 캐싱, 로드밸런싱 등에 사용된다.간단하게 말하면 클라이언트와 내 서비스 사이의 문지기라고 할 수 있다. 이미지와 같이 NGINX를 통해 외부 주소는 단순하게 유지하고, 내부에서 다양한 분기처리를 할 수 있다.server { listen 443 ssl; server_name inho.com; location /auth/ { proxy_pass http://auth-server:8082; }}설정의미listen 443HTTPS 요청을 받는다server_name inho.com해당 도메인 처리location /auth/auth 경로 요청 처리proxy_pass내부 서버로 전달위와 같이 설정하면사용자 요청GET https://inho.co..

인프라에서 가장 중요한 기초는 네트워크인 것 같다.요청이 어디서와서 어디로 가는지 모른다면 로드밸런싱, NGINX, Kubernetes 전부 흐릿하게 느껴질 것이다.https://dusen0528.tistory.com/162앞 장에서는 서버 프로세스가 포트를 잡고 기다린다는 것을 알 수 있었다.하지만 사용자는 그 포트번호를 외우지 않고 보통 도메인만 입력하는데, 그 사이를 이어주는 규칙에 대해서 알아본다.네트워크 요청 흐름브라우저에서는 inho.com을 입력해도 컴퓨터는 바로 그 이름으로 통신하지 않는다.DNS를 통해서 도메인을 IP 주소로 바꾸고 -> 그 다음 특정 포트로 연결을 열고 -> 그 위에서 HTTP 요청과 응답을 주고 받는다.IP, DNS, PortIP주소는 네트워크에 연결된 장치를 식별하는..

학부, 부트캠프, 회사를 다니며 NGINX, Docker, 로드밸런싱, 분산 환경과 EFK 등 다양한 도구들을 간단히 사용만 했을 뿐 깊게 이해하지 않고 사용하고 있었다.앞으로 인프라 챕터에서는 그동안 애매하게 알았던 개념 등을 확실히 정리하는 스터디가 되었으면 좋겠다.실제 서비스 운영 과정사용자가 브라우저, 앱에 요청을 보냄이 요청은 네트워크를 타고 어떤 서버로 갈지 결정되고 중간 프록시를 거쳐 앱과 데이터 저장소가 차례로 움직인다.요청을 받은 앞단은 어디로 보낼지 판단한다.작은 서비스라면 한 프로세스가 직접 처리할 수도 있지만 보통은 NGINX와 같은 프록시, 로드 밸런서, 쿠버네티스 서비스 등이 앞에 서서 요청의 첫 관문이 된다.실제 일을 하는 애플리케이션 프로세스 또는 컨테이너가 요청을 처리한다...

One-Hot Encoidng단어원-핫 인코딩 표현설명사과[1, 0, 0]첫 번째 자리만 1 (Hot)배[0, 1, 0]두 번째 자리만 1 (Hot)포도[0, 0, 1]세 번째 자리만 1 (Hot)- 원-핫 인코딩은 범주형 변수를 이진 형식으로 변환하는 방법 각 범주에 대해 새로운 열을 생성하여 1은 해당 범주가 존재함, 0은 해당 범주가 존재하지 않음에 해당합니다.왜냐하면 컴퓨터는 사과, 배라는 문자열을 이해할 수 없기 때문입니다.원-핫 인코딩의 가장 큰 문제는 단어 사이의 관계를 알 수 없다는 특징이 있습니다.예: 사과 [1, 0, 0], 배 [0, 1, 0]컴퓨터 입장에서 이 두 벡터는 그냥 완전히 다른 숫자일 뿐입니다. (직교하므로 내적값 0)그래서 워드 임베딩은 단어를 벡터로 표현하는 방법으로..

WebRTC웹에서 실시간 통신을 할 수 있게 해주는 기술브라우저끼리 실시간 통신하며 중간에 누구를 거치지 않는다는 특징이 있음예시로 유튜브의 경우 유튜브 서버에서 우리가 사용하는 단말기로 영상을 보는 구조인데, WebRTC를 쓴다면 상대방 혹은 카메라에서 내폰으로 바로 오는 P2P 방식이다.서버가 중간에 없어서 생기는 문제점서버가 중간에 없으니 보내는 쪽 Sender는 계속 송신하기만 할 뿐, 지금 보내는 영상이 잘 도착하는지 알 수 있는 방법이 없다.그래서 받는 쪽 Receiver는 RTCP라는 별도의 채널로 Receiver Report를 계속 보내줘야한다.네트워크가 막혀서 영상 데이터(패킷) 들이 제대로 못오고 있는 상황에서 받는쪽이 보내는쪽에게 현재 인터넷 상태가 좋지 않다고 증거를 제시하려면 들어..

[ISSUE] WebRTC RTSP 스트림의 동적 해상도 변화에 따른 디코딩 및 송출 장애1. 문제 현상 (Symptom)WebRTC를 통해 중계되는 RTSP 스트림을 입력으로 사용할 때, 초기 연결 시에는 정상 동작하다가 특정 시점 이후 시스템 터미널에 다음과 같은 에러가 반복적으로 발생하며 영상 처리가 불안정해지는 현상이 발견되었습니다.[swscaler @ 0x7f9610619c00] Slice parameters 0, 540 are invalid[h264 @ 0x559e2a3b4c00] corrupted macroblock ...[h264 @ 0x559e2a3b4c00] error while decoding MB ...특히, 입력 스트림이 잠시 끊겼다 재연결되거나 네트워크 환경이 변할 때 해상도가 ..

1. 재인코딩 기반 HLS 변환의 구조적 한계초기 파이프라인은 libx264로 재인코딩한 뒤 HLS 세그먼트를 생성하는 방식이었다. 테스트에는 아래와 같은 명령어를 사용했다.ffmpeg -i input.mp4 \\ -c:v libx264 \\ -preset fast \\ -crf 23 \\ -g 120 \\ -keyint\_min 30 \\ -sc\_threshold 0 \\ -c:a aac -b:a 128k \\ -hls\_time 4 \\ -hls\_list\_size 0 \\ -hls\_flags independent\_segments \\ -hls\_segment\_type mpegts \\ -hls\_segment\_filename seg\_%04d.ts \\ index.m3u8여기서 중요한 옵..

영상 재생 방식 성능 비교 분석테스트 기준: CAM1_20231220002321.mp4 (크기: 928MB) 기준, 5개 영상 동시 재생 테스트1. 변환 방식 비교 (HLS 생성)항목 방법 1 (Codec Copy) 방법 2 (Re-encode)변환 속도(영상 1개당)빠름 (약 12초)느림 (약 75초)세그먼트 크기원본 비트레이트 유지 (29MB)5Mbps 제한 (2.6MB)버퍼링큰 세그먼트로 인해 버퍼링 발생 가능작은 세그먼트로 버퍼링 최소화Seek 정확도GOP 경계 불일치 가능GOP 경계 일치 (정확)권장 사용변환 속도가 중요한 경우버퍼링 최소화가 중요한 경우결론: 버퍼링 최소화를 위해 방법 2 (Re-encode) 선택2. 초기 로딩 속도 비교 (5개 영상 동시 로딩)방식 초기 로딩 시간 비고MP4..

AWS MideaConverter에 대한 자료를 찾아보았다.이전 문서에서 S3 + CloudFront + MideaConverter에 대한 파이프라인을 고려했었는데 비용 측면에서 어려움이 있을거 같아 차선책을 찾는다.https://www.reddit.com/r/aws/comments/18ivn66/what_the_best_design_for_serve_s3_streaming_video/?tl=kohttps://www.reddit.com/r/aws/comments/18ivn66/what_the_best_design_for_serve_s3_streaming_video/?tl=ko이 게시글에서는 교육용 비디오 컨텐츠를 제공하기 위해 S3 + CloudFront 조합을 채택했다.하지만 S3/CloudFront는..

요구사항영상 갯수는 가변미디어 플레이어는 동기화하여 모든 영상을 제어함재생, 정지, 10초 전 후, 처음으로 등...테스트 단계에서는 1G 영상 5개로 진행실제 운영 환경에서는 한번에 8000TB 영상이 저장된 하드디스크를 전달 받아 그 영상들을 선박 정보 등에 따라 선택하여 재생목표 대용량 HLS 기반 멀티스트림을 지연 없이 실시간 동기화 재생할 수 있는 아키텍처 구축시도한 것들CASE 1 : 클라이언트 단에서 직접 브라우저 메모리에 저장후 재생-> 문제없이 잘 되지만 매번 영상을 직접 업로드 해야하고 해당 영상에는 메타데이터 등 다양한 정보들에 따른 View를 반환해야하는데 현실적으로 어려움CASE 2 : EC2 - 서버에 정적 리소스로 매핑-> 용량이 작은 경우에는 상관없지만 1G만 되어도 재생할 ..