True or False True or False

서비스에서 수요성이 있는 정보에 대해서 PUSH를 보내면 사용자가 몰리고 그로인해서 서비스가 전체적으로 느려지는 현상이 발생을 한다.그러면 어떻게 해야지 서비스가 느려지는 상황을 막을 수 있을까? 1. 캐시 사용A. DB Query 관련사용자가 그렇게 많지 않고 질의비용이 그렇게 비싸지 않으면 그냥 나름대로 그렇게 써도 문제가 없을 것 같다.그러나 사용자가 많아질 경우 Connection이 많아지고 그로인해서 CPU 사용률이 갑자기 오르게 될 것이다.그럴 때에는 간단한 질의에 경우에도 느린 결과값을 보여줄 것이고 심할 경우에는 Timeout이 발생할 확률도 크다.그렇기에 Cache를 통해서 DB로 접근할 것들을 우회해서 Cache를 통해서 대응하는 것이 유효한 방법이 되어질 수도 있다. B. View 관..

회사를 다니면서 겪었던 이슈 중 가장 난해했던 이슈였다.문제 발생회사를 옮기고 해당 회사에서 어느정도 도메인 및 서비스에 대해 익어갈 때쯤 겪었던 이슈였는데슬랙에서 보통 에러관련해서 메시지가 전사채널에 오는데 이거하고 관련된 이슈면 대부분 메시지 내용은 아래와 같았다.이미지가 엑박으로 떠요배경 이미지가 삭제가 안되어져요그러면 S3에 들어가 해당 object를 확인해보면 분명히 확장자는 이미지인데 MetaData 에 있는 Content-Type이 이상하게 들어가있었다.application/jsontext/javascript 그렇게 되어지니 CloudFront 를 통해서 Lambda 가 이미지에 대해 변형을 시도할 때 에러가 발생해서 엑박이 뜨거나 다른 외부 API 를 통해서 배경을 삭제하려고 하는데 에러가..

python 3.8 의 생명이 별로 남지않았다. 일전 다른 글에서 적었듯이 회사의 프로젝트 중 python 버전을 3.8로 사용하고 있었다.그래서 해당 기간이 끝나기전에 버전을 올릴 필요가 있었다. 그러면 버전을 왜 올려야하나?솔직히 말하면 지금 잘 돌아가는데 굳이 바꿀 필요가 없을수도 있다.그런데 왜 바꿔야 하는건가? 라는 질문에 내 생각을 나타내면 아래와 같다. 1. 성능적인 이점python 3.9, python 3.10 버전에 대해서는 따로 성능적인 업데이트에 대한 내용이 없다.하지만 3.11 에서는 성능이 전작기준 대비 평균적으로 약 25% 상승이 있었다고 말한다.그렇다면 일단 전체적으로 코드의 큰 변경없이 서비스의 속도가 향상되는 것을 기대할 수 있으니 큰 이점으로 다가온다. 2. 생산성 향상나..

Django의 3.2LTS 버전이 2024년 4월에 끝나게 되었다. 회사 프로젝트가 django 3.2.12 를 사용하고 있었는데 당시 Readme 에 내가 적어놓은 프로젝트 환경이다.굵은 글씨로 업데이트 필요라고 적어놓았는데 django 는 해당하는 시간이 지나고 나서 업데이트가 되었고python 같은 경우는 그래도 지원 종료 시기보다는 그전에 업데이트를 완료했다. 해당 글은 그중에서 django 3.2 에서 4.2 로 변경하면서 겪었던 것들을 적으려고 한다. 겪었던 항목(자잘한 것 제외)1. Django url DeprecatedDjango 4.0 remove feature 여기 글을 보면 알 수 있는데 django.conf.urls.url 이 사라진 것을 알 수 있다. Django 4.0 relea..

뭔가 직업관련된 글을 쓰는 것은 매우 어려운 것 같다.다른 사람들의 블로그를 보거나 혹은 검색해서 들어가게 된 글들의 품질을 봤을 때 매우 뛰어나다. 하지만 나는 그 정도의 글을 쓰는 것은 객곽적으로 생각핬을 때 현재의 나에게서는 불가능이다. 그렇다고 또, 글을 안 쓰자니 나중에 이러한 일이 있었지라는 부분이 사라지기도 하고나를 나타내는 부분이 사라지기도 한다. 그래서 이제부터라도 짧게 글을 쓰려고 한다. 글의 대한 무게감과 다루는 문제의 크기에 상관없이 그냥 글을 쓰려고 하고 또, 매번 아침의 출근을 1시간 정도는 일찍하고 있기에...(8시 출근인데 아침형 인간이 되어서 7시에 회사를 나오는....)그때 남는 시간에 글을 쓰는 시간을 가지려고 한다. 약간 사견으로 기술관련해서 글을 쓰는 것이 대단하다고..

Datadog 으로 모니터링을 하고 있는 어느 날예상치도 못하게 로그인 관련 된 서비스들이 매우 느리다는 것을 알게되었다. 뭔가 기대했던 시간은 p50 기준으로 1,000ms 미만으로 나와야 하는데 해당하는 부분들이 초과하는 경우도 있었고또 외부 소셜 인증의 경우에도 다른 외부 API 와 통신을 한다해도 기대밖의 성능이었다. 그렇게 Datadog 을 통해서 확인을 해보니 서비스 로직에서는 큰 문제는 없었는데 query를 통해서 조회를 할 때 너무 느리게 돌아가는 query 두개가 있었다. 하나는 프로젝트에서 사용하는 라이브러리 중  django-allauth 라는 라이브러리를 소셜 인증을 위해서 사용하는데 버전을 최근에 업데이트 하면서 생긴 것이었고 auth_user 에 username 을 upper 로..

Why? 당초 계획은 FastAPI와 FFmpeg를 이용해서 만들계획은 아니었다. 원래는 Django를 이용한 서버에서 라이브 영상 관리와 라이브 영상을 자르는 것까지 한번에 진행하려고 했었는데 예상치도 못하게 서버의 부하가 매우 심하고 비용이 상승하는 측면이 있었고 회사에서 자체적인 물리 서버가 있었기에 해당하는 서버에 따로 라이브 영상을 자르는 서버를 만들게 되었다. 그리고 그것을 공유하기 위해 이렇게 글을 작성한다. 설계(라이브 영상을 녹화하는 것에 초점) 각각의 항목에 일단 간략하게 설명을 하자면 - FFmpeg Server: IP Cam 을 이용해 실질적으로 라이브(HLS) 파일을 만들어내고 보관한다(Nginx로 정적 파일 서빙) - 메인 서버: FFmpeg Server가 HTTP 통신을 통해 ..

한 줄로 요약을 하면 timeout 을 설정하자. 현재의 상황 현재 회사에서 IP CAM을 이용하여 CCTV 처럼 활용을 하려고 한다. 처음에는 AWS Media Package 를 사용했지만 비용이 상상이상으로 발생해(하루에 약 15만원 부과??) 자체적으로 구현하기로 하고 자체 서버를 구입해서 해결을 하는 중이다. 원래는 EC2로 할까했지만 계산을 해보니 자체서버가 더욱 더 싸게 먹혔다. 현재의 구현방식 FFmpeg 를 이용해서 24시간 돌아가는 실시간 스트리밍을 해야한다.(무중단 필요) 그래서 RTSP => HLS 로 변환작업을 FFmpeg 로 하고 AWS S3로 실시간으로 업로드를 진행한다. AWS S3 주소의 경우에는 백엔드 서버에 보내는 형태로 제공이되어진다. 순서도로 나타내면 1. 업로드 되어..