✔오늘 배운 중요한 🔑 point디자인 패턴은 코드를 구조화하고 유지보수성을 높이며, 재사용성을 극대화하는 데 도움을 준다.디자인 패턴은 단순한 코드 작성법이 아니라 특정한 문제를 해결하기 위한 검증된 방법이다. 따라서 어떤 문제를 해결하기 위해서 해당 패턴이 만들어졌는지를 이해하는것이 중요하다.디자인 패턴을 제대로 사용하기 위해서는 적절한 상황에서 올바른 패턴을 선택하는 능력이 중요하다.🎯 오늘 배운 내용 적절한 패턴 선택객체를 하나만 유지해야 함싱글톤 패턴로깅, 데이터베이스 연결 등객체 생성을 유연하게 관리하고 싶음팩토리 메서드 패턴객체 생성 로직을 숨기고 싶을 때동적으로 알고리즘을 변경하고 싶음전략 패턴런타임에 알고리즘을 선택 가능하게복잡한 서브 시스템을 단순하게 제공하고 싶음퍼사드 패턴여러 클..

시연 영상: https://www.youtube.com/watch?v=AnaaG_2nfmw  배포된 주소: https://hj-chat.com/ HJ CHATskill SPRING BOOT Web Socket Kafka Redishj-chat.com GitHub: https://github.com/kotlin2024/HJCHAT GitHub - kotlin2024/HJCHAT: 실시간 채팅 API실시간 채팅 API. Contribute to kotlin2024/HJCHAT development by creating an account on GitHub.github.com

ec2 인스턴스 접속ssh -i "C:\Users\wnd2g\Desktop\AWS EC2 키페어\HJ-CHAT-BACKEND-SERVER-KEY-PAIR.pem" ubuntu@3.36.182.4 docker-compose 전송scp -i "C:\Users\wnd2g\Desktop\AWS EC2 키페어\HJ-CHAT-BACKEND-SERVER-KEY-PAIR.pem" "C:\Users\wnd2g\IdeaProjects\HJCHAT\docker-compose.yml" ubuntu@3.36.182.4:/home/ubuntu/ dockerfile 전송scp -i "C:\Users\wnd2g\Desktop\AWS EC2 키페어\HJ-CHAT-BACKEND-SERVER-KEY-PAIR.pem" "C:\Users\w..

❎ 문제발생EC2 서버에 내 서버와 KAFKA를 설치하였으나 메모리 용량 부족으로 인해서 실행이 중단되는 문제가 발생하였다.  🆘 해결 과정현재 ec2 인스턴스의 사용가능 메모리는 500mb정도 이지만 KAFKA는 기본적으로 1GB의 힙메모리를 사용한다.ec2 인스턴스를 프리티어가 아닌 더 높은 티어의 인스턴스를 사용하면 해결이 되지만 비용적인 문제가 있기 때문에 EC2의 디스크 공간 일부를 임시 메모리로 사용하는 방법을 선택하였다.대신에 RAM이 아니라 디스크이기 때문에 RAM에 비해서는 많이 느린편이다.  스왑 파일로 문제 해결# 1. 스왑 파일 생성 (예: 1GB)sudo fallocate -l 1G /swapfile# 2. 스왑 파일 권한 설정sudo chmod 600 /swapfile# 3. ..

DOCKER 환경에서 내 Server와 Kafka가 정상적으로 동작한다는것을 확인했으니 CI/CD를 구축하기 전에 EC2 서버에 배포를 먼저 진행해야한다. SSH 접속ssh -i "C:\Users\wnd2g\Desktop\AWS EC2 키페어\HJ-CHAT-BACKEND-SERVER-KEY-PAIR.pem" ubuntu@3.36.182.4 docker 설치sudo apt-get updatesudo apt-get install -y docker.iosudo systemctl start dockersudo systemctl enable docker docker-compose 설치sudo curl -L "https://github.com/docker/compose/releases/download/v2.20.2..

웹소켓에 연결할때 토큰을 검증하고 토큰이 만료되었다면 웹소켓을 연결을 끊고 토큰을 재발급 받은다음 다시 웹소켓에 연결하는 로직은 구현이 되었다.하지만 이미 웹소켓에 연결이 된 상태에서는 accessToken의 만료기간이 끝났음에도 불구하고 메세지를 보낼수가 있는 상황이다. 토큰의 만료시간이 지난것을 볼수 있지만메세지는 여전히 보낼수 있는 상황이다. 이는 웹소켓을 연결하는 순간에는 토큰 검증이 이루어져 연결에 성공하지만  HTTP 통신과 다르게 지속적으로 연결이 되는 상황이기때문에  연결에 성공한 다음부터는 토큰이 만료가 되더라도 서버 입장에서는 알 수 없는것이다.물론 사용자가 메세지를 보낼때 토큰도 같이 보내게 하는 식으로도 구현이 가능하지만, 매세지를 보낼때마다 토큰을 검증하는 것은 속도 저하 문제가 ..