클라이언트 상호작용 레이어  1. 사용자/클라이언트:최종 사용자가 브라우저를 통해 시스템에 접근합니다.  2. 브라우저 통신:사용자 요청과 응답이 브라우저를 통해 전달되어 백엔드 인프라와 상호작용합니다. AWS 인프라 퍼블릭 서브넷:  1. 인터넷 게이트웨이:퍼블릭-facing 자원과 인터넷 간의 통신을 제공합니다.  2. 애플리케이션 로드 밸런서(ALB):들어오는 트래픽을 적절한 백엔드 서비스로 분산시켜 확장성과 장애 허용성을 보장합니다.  3. 배스천 호스트:개인 서브넷 자원에 SSH로 안전하게 접근할 수 있도록 지원합니다. 프라이빗 서브넷-1 (서비스 계층):  1. 모니터링 및 시각화 스택:Kibana, Logstash, Grafana, prometeus로그 집계, 성능 모니터링, 실시간 시각화를..

해당 시퀸스 다이어그램은 1대1 매칭 후 매칭된 두 유저에게 1대1 채팅방에 자동 생성된 후 Client A가 채팅 메세지를 보낸후 Client B에게 전달되는 과정을 간략하게 표현한 다이어그램입니다.   다이어그램 순서 설명 1. 매칭 요청(Client A → Main Server):Client A가 Main Server로 매칭을 요청합니다.Main Server는 매칭 서버로 사용자 정보를 전달합니다. 2. 매칭 성공 알림(Matching Server → Main Server):Matching Server는 매칭 성공 여부를 판단한 후 Main Server로 알림을 보냅니다.이 과정에서 매칭 결과는 MySQL에 저장됩니다.  3. RabbitMQ를 통한 이벤트 전달:Matching Server가 매칭 ..

현제 구현한 1대1 채팅 기능이 어떻게 작동이 되는지 시퀸스 다이어그램을 통해 알려드리겠습니다. 왜 기능을 구현할때 시퀸스 다이어그램으로 정리하는 이유가 무엇인가요?시퀀스 다이어그램을 그려야 하는 이유는 시스템 설계와 기능 구현 과정에서의 명확한 이해와 커뮤니케이션을 돕기 위해서입니다. 이를 구체적으로 살펴보면 다음과 같습니다: 1. 기능의 흐름을 시각화 시퀀스 다이어그램은 사용자와 시스템 간의 상호작용, 또는 시스템 내부의 컴포넌트 간 데이터 흐름을 시간 순서에 따라 시각적으로 표현합니다.이를 통해 기능의 동작 방식을 한눈에 파악할 수 있어 설계 과정에서 누락된 부분이나 비효율적인 흐름을 사전에 발견할 수 있습니다. 2. 명확한 요구사항 분석 시퀀스 다이어그램은 요구사항을 기능적으로 상세히 표현하기에 ..

Direct Exchange 사용 메세지 라우팅의 간결성정확한 라우팅 Direct Exchange는 라우팅 키(Routing key)를 기반으로 메세지를 특정 큐로 직접 전달합니다. 특히 사용자가 특정 채팅방(큐)에만 메세지를 보내야 할 경우 적합합니다. 다른 라우팅 방식과 비교했을땐?Fanout Exchange: 메시지를 모든 큐에 브로드캐스트함 → 1:1 채팅에서는 과도한 자원 낭비.Topic Exchange: 패턴 매칭을 통한 라우팅 → 복잡성이 증가할 수 있음. 성능 효율성으로는 어떤 이점이 있나요?낮은 오버헤드메시지가 라우팅 키로 정확히 하나의 큐로만 전달되므로 라우팅 오버헤드가 적습니다. 메시지를 복사하거나 불필요한 큐로 보내는 작업이 없기 때문에 메시지 처리 속도가 빨라집니다.1:1 채팅에서..

1대1 매칭서비스가 성사 된 이후 그 둘에 대해서만 채팅이 가능하게 하는 서비스 구현 계획을 세우고 있습니다.  이에 대한 연관관계는?1대1 매칭 서비스가 성사된 이후 1대1 채팅 서비스를 구현할 때 필요한 주요 연관관계는 사용자와 채팅 세션 또는 채팅 메세지 간의 관계가 있습니다.  엔티티 구조사용자(Users)1대1 매칭(Matching) 각 사용자는 1대1 매칭 엔티티를 통해 매칭 관계를 설정합니다. 1대1 매칭(Matchings)일대다(User와 연관): 두 명의 사용자(user_id_1, user_id_2)를 연결하여 매칭을 성사시킵니다.1대1 채팅세션(chatrooms): 매칭이 완료된 후 채팅 세션을 생성하여 두 사용자가 연결될 수 있도록 합니다. 1대1 채팅 세션(chatrooms)필드: ..

일단 시작하기 전에 인프라 설계도 부터 보여드리고 시작하겠습니다.  로컬로 빼놓은 젠킨스 -> 비용 절감 효과를 보기위해 로컬로 옮김EC2-ECS 구조 -> 카프카 컨테이너 분리, 오토 스케일링을 통해 자동으로 컨테이너 수 조절 -> 서버의 부하를 줄임 기존 EC2-ECS 구조입니다. 전에F fargate-ecs 구조에서 EC2-ECS 구조로 변경되었지만 사실 Fargate-ECS와 EC2-ECS 두 구조를 실행하여 어느게 더 효율적일지 비교을 해볼 예정입니다. 일단 처음으로 ECS에 배포를 해봐서 상당히 난항을 겪었습니다. 포멧 도 arm64 기준으로 해야 했지만 linus x86/64로 설정 해놓는 바람에 포멧팅 오류뜨게 되었습니다.exec /usr/local/openjdk-17/bin/java: e..

소모임 랭킹 조회 시스템 어뷰징 방지를 위해 set을 활용해 유저id 하나당 gatheringId 값마다 하나씩 조회수를 올릴수 있습니다. 허나 이 사실을 모르고 연속적으로 어뷰징을 할 경우도 있을 수도 있어 RedisLimiter를 두어 제한된 시간동안 일정이상의 조회를 못하게 방지하는 로직을 구현하여 서버의 부하를 막고자 시작하였습니다. 일단 RedisLimiter의 이점을 이러합니다. 서버 부하 방지 및 안정성 확보이유: 많은 사용자가 동시에 소모임 단건 조회를 반복적으로 요청할 경우, 서버는 과부하 상태에 놓일 수 있습니다. 특히, 악의적인 요청(어뷰징)이나 봇 트래픽이 있을 경우, 서버 성능이 급격히 저하될 위험이 있습니다.RedisLimiter 적용 이점: Redis를 활용한 레이트 리미터는 ..

테스트 설명전에 제가 왜 소모임 다건 목록 조회 부분에 왜 Redis를 사용했는지 설명드리겠습니다. 총 4가지로 설명드리겠습니다. 1. 고속 데이터 조회 및 응답 속도 개선이유: 소모임 목록을 여러 사용자가 빈번하게 조회할 경우, 데이터베이스에 직접 접근하여 조회할 때마다 시간이 많이 소요되고, 서버에 과부하가 발생할 수 있습니다.Redis 사용 목적: Redis는 인메모리 데이터 저장소로, 데이터베이스보다 훨씬 빠르게 데이터를 읽어올 수 있습니다. Redis에 소모임 목록 데이터를 캐시하면 데이터베이스를 거치지 않고 빠르게 응답을 반환할 수 있어 사용자 경험이 개선됩니다.2. 데이터베이스 부하 경감이유: 소모임 목록은 많은 사용자가 동시에 조회하는 가능성이 높고, 지속적인 데이터베이스 조회는 서버 부하..

지금 인프라 구축 과정에서 상당한 난항을 겪고 있는데 원래 fargate-ECS로 사용할 예정이였지만 뜻밖의 kafka 도입으로 인해 EC2-ECS 방식으로 바꿔야 할듯 하다. 일단은 Jenkins는 로컬로 이미 빼놓은 상태라 그대로 사용할듯 싶고, 문제는 기존 jar 파일을 image화 시켜서 레지스트리로 넘겨야 한다.    도커 데몬에 접근할려고 하니 접근 권한이 없다고 하여 해당 명령어를 통해 접근 권한을 받았다.docker exec -u root -it c899fde9ff16 bash 다만 터미널을 통해 젠킨스 서버를 접속할때 가능한 명령어라 디렉토리 구조를 바꿔야 할때 조금의 난항이 있었다. (내가 설정을 못한 것 일수도 있고) 그렇게 하여 도커에 있는 젠킨스 서버에 도커 데몬을 접속을 해야하는..

우리가 하고자 하는 프로젝트를 누군가에게 보여주기 위해서는 "배포"라는 것이 필요하였습니다. 그래서 인프라에서 어떤 소스들을 활용할지에 대한 논의가 필요했습니다. CI/CD일단은 CI/CD를 4개로 추려봤습니다.Jenkins특징: 가장 널리 사용되는 오픈소스 CI/CD 도구. 플러그인을 통해 다양한 기능과 서비스와 연동 가능.장점: 커스터마이징 가능, 대규모 커뮤니티, 다양한 플러그인.단점: 설정이 복잡할 수 있고, 유지 관리가 필요함. GitLab CI/CD특징: GitLab 플랫폼에 내장된 CI/CD 도구. Git 리포지토리와 통합되어 있어 사용이 편리함.장점: Git과 긴밀한 통합, 클라우드 및 자체 호스팅 지원, 깃 기반 워크플로우와 자연스러운 연동.단점: 특정한 사용자 정의가 복잡할 수 있음. ..