Week3 멘토링 일지

개별 멘토링 일지

J071

flowchart TB
    %% ===========================================
    %% 클라이언트 그룹 정의
    %% ===========================================
    subgraph ClientGroup["클라이언트 그룹(Mesh)"]
        direction LR
        Client1["클라이언트 1"]
        Client2["클라이언트 2"]
        Client3["클라이언트 3"]
        Client4["클라이언트 4"]

        %% P2P 연결
        Client1 <--> |P2P WebRTC| Client2
        Client1 <--> |P2P WebRTC| Client3
        Client1 <--> |P2P WebRTC| Client4
        Client2 <--> |P2P WebRTC| Client3
        Client2 <--> |P2P WebRTC| Client4
        Client3 <--> |P2P WebRTC| Client4
    end

    %% ===========================================
    %% 시스템 컴포넌트 정의
    %% ===========================================
    
    %% 로드 밸런서
    subgraph LoadBalancer["로드 밸런서"]
        direction TB
        NGINXMain["NGINX"]
    end

    %% 게임 서버
    subgraph GameServer["게임 서버 (NestJS)"]
        direction TB
        GameLogic["게임 로직"]
        WebSocket["WebSocket 핸들러"]
        GameState["게임 상태 관리"]
    end

    %% 시그널링 서버
    subgraph SignalingServer["시그널링 서버 (Express)"]
        direction TB
        SignalingLogic["시그널링 로직"]
        WebRTCHandler["WebRTC 핸들러"]
    end

    %% 음성 처리 서버 클러스터
    subgraph VoiceProcessing["음성 처리 서버 (Express) 클러스터"]
        direction TB
        VoiceServer1["음성 처리 서버 1"]
        VoiceServer2["음성 처리 서버 2"]
        VoiceServer3["음성 처리 서버 3"]
    end

    %% 외부 API
    ClovaAPI["Clova Speech Recognition API"]

    %% 저장소
    subgraph Storage["저장소"]
        direction TB
        Redis[(Redis)]
        MySQL[(MySQL)]
    end

    %% ===========================================
    %% 시스템 연결 정의
    %% ===========================================

    %% 1. 프론트엔드 연결
    ClientGroup <--> |HTTPS| NGINXMain

    %% 2. 로드 밸런서 연결
    NGINXMain <--> |게임 트래픽| GameServer
    NGINXMain <--> |시그널링 트래픽| SignalingServer
    NGINXMain <--> |음성 트래픽| VoiceProcessing

    %% 3. 데이터 저장소 연결
    GameServer <--> Redis
    GameServer <--> MySQL

    %% 4. 서비스 간 연결
    VoiceProcessing <--> |음성 데이터 처리 요청 & 결과| GameServer
    GameServer <--> |게임 데이터| ClientGroup

    %% 5. 외부 API 연결
    VoiceServer1 <--> |음성 인식 요청| ClovaAPI
    VoiceServer2 <--> |음성 인식 요청| ClovaAPI
    VoiceServer3 <--> |음성 인식 요청| ClovaAPI

음성 처리 서버 Clustering 아이디어는 좋음
도커를 사용하는 이유는 동일한 환경을 구성할 수 있다는 점
AWS 기준으로 스펙은 m2(2 Core, 8GB)정도가 표준
Auto-Scaling은 CPU 70~80%를 기준으로 하면 적당함
SlackBot 활용하면 좋음
11/22 개발 완료, 11/26 리팩토링, 11/28 테스트 코드 작성
다음주 팀 멘토링은 28일 예정

J101

아키텍처 고민

src
 ┣ __test__
 ┃ ┗ setup.ts
 ┣ assets
 ┃ ┣ lottie
 ┃ ┃ ┗ 404.json
 ┃ ┗ react.svg
 ┣ components
 ┃ ┣ common // 재사용 가능한 컴포넌트
 ┃ ┃ ┣ NotFound.tsx
 ┃ ┃ ┗ SearchBar.tsx
 ┃ ┗ ui // shadcn/ui 컴포넌트
 ┃ ┃ ┣ alert-dialog.tsx
 ┃ ┃ ┣ badge.tsx
 ┃ ┃ ┣ button.tsx
 ┃ ┃ ┣ card.tsx
 ┃ ┃ ┣ dialog.tsx
 ┃ ┃ ┣ input.tsx
 ┃ ┃ ┣ label.tsx
 ┃ ┃ ┗ slider.tsx
 ┣ config
 ┃ ┗ env.ts
 ┣ constants
 ┃ ┣ audio.ts
 ┃ ┗ rules.ts
 ┣ hooks
 ┃ ┣ useAudioPermission.ts
 ┃ ┣ useBackExit.ts
 ┃ ┣ usePagination.ts
 ┃ ┣ useReconnect.ts
 ┃ ┗ useRoomsSSE.ts
 ┣ lib
 ┃ ┗ utils.ts
 ┣ pages 
 ┃ ┣ GamePage
 ┃ ┃ ┣ GameDialog
 ┃ ┃ ┃ ┗ ExitDialog.tsx
 ┃ ┃ ┣ GameScreen
 ┃ ┃ ┃ ┗ GameScreen.tsx
 ┃ ┃ ┣ PlayerList
 ┃ ┃ ┃ ┣ Player.tsx
 ┃ ┃ ┃ ┣ PlayerList.tsx
 ┃ ┃ ┃ ┗ VolumeBar.tsx
 ┃ ┃ ┗ index.tsx
 ┃ ┗ RoomListPage
 ┃ ┃ ┣ RoomDialog
 ┃ ┃ ┃ ┣ CreateDialog.tsx
 ┃ ┃ ┃ ┗ JoinDialog.tsx
 ┃ ┃ ┣ RoomHeader
 ┃ ┃ ┃ ┗ RoomHeader.tsx
 ┃ ┃ ┣ RoomList
 ┃ ┃ ┃ ┣ GameRoom.tsx
 ┃ ┃ ┃ ┣ Pagination.tsx
 ┃ ┃ ┃ ┗ RoomList.tsx
 ┃ ┃ ┗ index.tsx
 ┣ services
 ┃ ┣ SocketService.ts
 ┃ ┣ gameSocket.ts
 ┃ ┗ signalingSocket.ts
 ┣ stores
 ┃ ┣ queries
 ┃ ┃ ┣ getCurrentRoomQuery.ts
 ┃ ┃ ┗ getRoomsQuery.ts
 ┃ ┗ zustand
 ┃ ┃ ┣ usePeerStore.ts
 ┃ ┃ ┗ useRoomStore.ts
 ┣ types
 ┃ ┣ roomTypes.ts
 ┃ ┣ socketTypes.ts
 ┃ ┗ webrtcTypes.ts
 ┣ utils
 ┃ ┗ playerUtils.ts
 ┣ App.css
 ┣ App.tsx
 ┣ index.css
 ┣ main.tsx
 ┗ vite-env.d.ts

지난 학습스프린트 때 디자인이 비슷해 보여 컴포넌트를 공통화했다가 고통받은 경험이 있어서 현재는 최대한 공통화하지 않고 컴포넌트를 만들고 있습니다. shadcn/ui를 쓰고 있어서 핵심 기능 구현이 어느 정도 완료되면 바꾸는 데 크게 어렵지 않지 않을까 생각 중입니다. (아직 모르는 일이지만,,)

저는 “재사용”을 기준으로 components에 분류하고 있어서 pages를 두고 각 페이지에서만 사용되는 컴포넌트들은 components로 분류하지 않았습니다.

멘토님이 보시기에 이러한 구조가 괜찮은 방식인지, 유지보수 측면에서 어떨지 궁금합니다!

피드백

아토믹 디자인 패턴을 사용한 것 같다.

약간 수정을 한다면 pages를 너무 분리한 것 같다.

pages
 ┃ ┣ GamePage
 ┃ ┃ ┣ GameDialog.tsx
 ┃ ┃ ┣ GameScreen.tsx
 ┃ ┃ ┣ GamePlayer.tsx
 ┃ ┃ ┣ GamePlayerList.tsx
 ┃ ┃ ┣ GameVolumeBar.tsx
 ┃ ┃ ┗ index.tsx

어디까지나 취향이고, 원하는 스타일이 많은 블로그나 검색해 보는 걸 추천

FSD 구조?

J231

Redis adaptor를 활용해서 다중 서버 환경에서의 소켓 정보 공유 방법

socket.io-redis 패키지를 사용하여 Redis를 어댑터로 설정

다중 서버 환경에서는 각 서버가 같은 Redis 인스턴스를 공유하므로, 한 서버에서 발생한 이벤트가 다른 서버의 소켓에도 전달

예를 들어, 두 서버 인스턴스(A, B)가 있고, 같은 Redis를 공유한다고 가정

클라이언트 X는 서버 A에 연결.
클라이언트 Y는 서버 B에 연결.
클라이언트 X가 특정 방에 메시지를 보내면 Redis 어댑터를 통해 서버 B도 해당 메시지를 전달.

Redis 클러스터 고려

대규모 환경에서 Redis 클러스터를 사용해야 할 경우

주의사항

Redis의 가용성: Redis가 단일 장애점(Single Point of Failure)이 되지 않도록 Sentinel 또는 클러스터 설정을 고려.
속도: 메시지가 많아질 경우 Redis 성능을 모니터링하고, 필요하면 샤딩 적용.
보안: Redis 접근 권한 설정 및 TLS 사용 권장.