전체 글86 Docker를 활용한 서버 배포 (1) Docker는 컨테이너화 기술을 제공하며, 애플리케이션과 그 실생 환경을 패키징하고 배포할 수 있게 해준다. 이를 통해 일관된 실행 환경과 빠른 배포 및 확장 등이 가능하다. Docker 사용 이유 과거 소프트웨어 개발 주기: 폭포수 모형 과거에는 소프트웨어 개발 주기에서 폭포수 모형을 사용했다. 이 방식은 개발 과정의 한 단계가 끝나야 다음 단계로 넘어갈 수 있는 구조이다. 하지만 다음과 같은 문제점이 있었다:문제가 발생하면 이전 단계로 돌아가는 데 많은 시간과 비용이 소요된다.과정이 병행 수행되지 않아 비효율적이다.배포 후 문제가 발생하면 롤백과 수정을 반복해야 하며, 여러 서버에 수동으로 하나하나 배포해야 했다. 현대 소프트웨어 개발 주기: 애자일 모형 현재는 애자일 모형을 주로 사용한다. 이 방식.. 2024. 12. 18. Redis-Py : ZSet(Sorted Set) 랭킹 구현 활용 ZSET은 Sorted Set으로 세트와 정렬된 목록의 기능을 결합한 Redis의 강력한 데이터 구조이다. 요소를 추가, 제거 또는 업데이트할 수 있으며, 항상 점수 또는 순위로 정렬된 순서를 유지한다. 이러한 특성 덕분에 쉽게 랭킹 시스템 구현이 가능하며 관리가 간편하다. 여기서는 ZSET의 대표적인 함수 몇 가지를 정리하려고 한다. 1. ZINCRBY : 점수 증가 및 감소특정 멤버의 점수를 증가시키거나 감소시키는 데 사용한다. 멤버가 존재하지 않으면 자동으로 추가된다.redis_client.zincrby(key, increment, member)#점수 증가 redis_client.zincrby('ranking', 10, 'player1')#점수 감소redis_client.zincrby('ranki.. 2024. 12. 8. [Django]WebSocket을 활용한 실시간 랭킹 구현 목표실시간 접속자 수를 표시하고 이를 바탕으로 채팅방 랭킹을 제공하고 싶었다. 구현 목표1. 실시간 접소자 표시 : 홈 화면의 각 채팅방마다 접속자 수를 표시2. 접속자 수에 따른 랭킹 제공 : 접속자가 많은 순서대로 랭킹을 실시간으로 표시 홈 화면에서 채팅방 리스트에 실시간으로 채팅방의 접속자 수를 표시하고 또 접속자 수에 따라 랭킹이 기능을 구현하고 싶었다. 하지만 채팅방 접속/퇴장 시마다 서버에 요청을 보내야 했는데, 이는 서버 부화를 유발할 가능성이 있다고 생각했다. 이를 해결하기 위해 WebSocket을 활용해 API 요청을 줄이고 실시간 데이터를 주고받는 방식으로 구현하기로 했다. 구현 방법 1. WebSocket Consumers 구조-myProj -app -consumers -ch.. 2024. 12. 7. [Django] ORM N+1 문제 해결 : 지연로딩 문제 채팅방 리스트를 조회할 때, 채팅방 수에 비례해 쿼리 수도 함께 증가하는 문제가 발생했다. 이로 인해 요청 처리시간도 증가했다. 원인 : N+1 문제 #views.py ...chat_rooms = ChatRoom.objects.all()rooms=[]for room in chat_rooms: data ={ "name": room.name, "id":room.id, "users": room.users.count(), "add_date" : room.add_date, } rooms.append(data) ... 채팅방 목록을 조회하는 코드이다. 여기서 모든 채팅방을 조회하고 반복문을 통해 데이터를 저장하는데 채팅방에 접속한 유저를.. 2024. 12. 1. [Django]데이터베이스 vs Redis: 실시간 접속자 관리 성능 비교와 최적화 문제 채팅 프로젝트를 진행하며 문제가 발생했다. 접속자 API 데이터를 불러오지 못함.기존 접속자는 새로운 사용자가 들어와도 접속자 목록에 반영되지 않음. 실시간 사용자가 많은 경우 채팅방 연결마다 DB 요청이 증가해 병목현상이난 쿼리 처리 속도가 느려질 가능성이 있어 개선할 필요성을 느꼈다.원인기존의 데이터 흐름채팅방 입장 → 사용자 정보 저장 → 웹소켓 접속 → 접속자 리스트 전송 → 데이터 수신 처음엔 데이터베이스에 즉각적으로 저장된 값을 가져오는 방식이 문제라고 생각했으나, 웹소켓 종료 시 사용자 데이터를 제거하는 과정에서 예상치 못한 문제가 있었다. 그리고 React의 안정성을 위한 중복 요청으로 인해 웹소켓이 두 번 연결되며 데이터가 누락되거나 저장되지 않는 경우가 있음을 확인했다.또한, .. 2024. 11. 30. Django와 React 연결 시 발생하는 CORS 문제 해결 방법 문제 Django와 React를 연결하는 도중 아래와 같은 문제가 발생했다.이 문제는 React에서 Django 서버로 요청하는 과정에서 발생한 CORS(Cross-Origin Resource Sharing) 문제다. 이는 프런트엔드와 백엔드의 도메인이 다를 경우 브라우저가 요청을 차단하며 발생한다. 브라우저는 기본적으로 동일 출처 정책(Same-Origin Policy)을 강제하기 때문이다. 동일 출처 정책동일 출처 정책은 보안을 강화하기 위해 클라이언트와 서버 간 출처(origin)가 다르면 요청을 차단하도록 설계된 보안 메커니즘이다. 이는 잠재적인 악성 문서를 격리하여 공격 벡터를 줄이는 데 도움을 준다. 예를 들어:Django 서버: http://127.0.0.1:8000React 클라이언트: h.. 2024. 11. 24. Django - FileField 사용 파일저장 FileField 사용법 채팅 프로젝트를 만들면서 메시지에 포함된 이미지나 다른 파일을 서버에 저장해야 하는 상황이 발생했다.파일 업로드와 관련된 처리를 도와주는 Django 모델 필드로 FileField와 ImageField를 사용하여 파일을 관리하려고 한다. 사용방법serrings.py 설정 #settings.py...MEDIA_URL = '/media/'MEDIA_ROOT = os.path.join(BASE_DIR, 'media')... settings.py에 media파일 경로를 설정해 준다.MEDIA_URL: 업로드된 파일에 접근할 수 있는 URL 경로MEDIA_ROOT: 실제 파일이 서버에 저장되는 위치파일을 저장하면 manage.py와 같은 경로에 media파일이 자동으로 생성된다. 모.. 2024. 11. 20. Django Cache 따닥 중복 요청 방지 문제 게시물이나 댓글을 생성하는 버튼을 화면 전환 전에 여러 번 클릭하면 동일한 요청이 중복으로 발생하는 문제가 나타났다.이로 인해 데이터베이스에는 의도와 상관없이 중복된 값이 저장되었고, 서버로 필요 없는 API 요청이 여러 번 전달되었다. 특히 결제 시스템처럼 중요한 트랜잭션이 처리되는 경우, 동일한 결제가 중복으로 발생할 가능성이 있다. 이는 금전적 손실과 사용자 불만으로 이어질 수 있으며, 심각한 신뢰도 문제 생길 수 있다. 단순히 프런트엔드에서만 처리할 경우, 개발자 도구를 이용한 요청 조작이나 네트워크 지연 등으로 인해 중복 요청이 발생할 수 있다. 이를 방지하기 위해 서버에서도 확실한 검증과 처리가 필요하다. 프런트엔드와 백엔드 모두에서 중복 요청 방지를 구현함으로써 시스템 안정성을 높.. 2024. 11. 18. Celery를 활용한 채팅 서버 자원 최적화[WhoAU] 문제 채팅 서비스를 개발하는 과정에서, 서버가 종료된 후에도 Redis에 기존 WebSocket 연결 정보가 남아 있는 문제가 발생했습니다. 개발 환경에서는 비활성화된 채팅방 데이터를 수동으로 삭제할 수 있었지만, 배포 환경에서는 다음과 같은 문제가 예상됐다. disconnect 함수 미작동 시: 의도치 않게 채팅방 데이터가 남아 있을 가능성.사용하지 않는 데이터 방치: 서버 자원을 지속적으로 점유하며, 비활성화된 채팅방 데이터로 인해 성능 저하 발생.비활성화된 채팅방 관리 문제로 인해 Redis 서버의 저장 공간을 낭비하고, 전체 서버 성능이 저하될 수 있다는 판단 했다.해결 방법 1 cache 사용하기 채팅방 관리를 위해 Redis의 Cache 기능을 사용하여 각 채팅방의 상태(마지막 활동 시간).. 2024. 11. 17. 이전 1 2 3 4 ··· 10 다음
