-
Notifications
You must be signed in to change notification settings - Fork 1
[개별 멘토링] 2024.11.23.
-
웹소켓 연결 문제
지난 주부터 나를 괴롭혔던 문제가 드디어 수정됐다!
관련 내용을 Github Wiki에 업로드했으니 확인해보세요😊
-
SSE 사용
(얘도 나중에 Github Wiki에 올라갈 것 같습니다ㅎㅎ!)
정말 단순히 단방향 통신이어도 충분히 가능하지 않냐는 이야기에 제대로 공부도 하지 않고 무작정 적용해보려고 했던 사례이다. 앞으론 이렇게 하면 안되겠다는 걸 뼈저리게 느꼈다…
공부를 제대로 하지 않고 적용한 이유에 대해서.. 약간의 변명을 하자면 다음과 같다.
월요일에 주간 회의를 통해 웹소켓 대신 SSE를 사용해서 소켓과 SSE를 비교해보기로 결정되었다.
웹소켓 연결 문제는 정말 다행스럽게도 마스터 클래스 이전에 원인이 밝혀졌지만.. 코드 수정하는데 걸릴 시간이 문제였다.
정규 장 마감 시간인 15시 30분 이전에 웹소켓 코드를 수정하고, 한투와 웹소켓 연결이 제대로 됐는지 우선 확인을 해야 한다. 확인이 완료되면 해당 데이터를 sse로 전달해봐야 하는데, 이때 필요한 값만 잘 들어가는지, 실시간으로도 잘 동작하는지도 확인해야 했다.
그러나 월요일에는 마스터 클래스가 있기 때문에.. 마스터 클래스가 끝난 후 공부하고 작업한다면 절대로 오늘 내로는 끝내지 못할 거란 생각에 마음이 너무 급해져서 공부를 제대로 하지 않고 사용법만 찾아서 바로 구현을 시작했다.
그래서 데모 발표 당일날, 확인하지 못한 많은 문제들을 만나게 되었다.
-
https 적용을 위해 ssl, nginx 등 사용 시 추가 설정을 해줘야 하는 문제
ssl 적용 후 https로 변경하는 작업은 목요일 발표 준비 시간에 완료되었다.
이미 주식 정규장이 마감된 이후라 배포 서버에서 SSE 연결이 되지 않는 문제를 발견하지 못했다. 아침에 배포 서버를 다시 확인했을 때 연결이 되지 않는다는 걸 확인했고, nginx에 추가 설정이 필요하다는 걸 알게되어서 급하게 추가했다.
-
SSE 스트림 필터링을 하지 않았던 문제
이건 배포 서버만의 문제가 아니라 로컬에서도 동일하게 발생하는 이슈였는데, 로컬에서 제대로 확인을 하지 않았던 문제였다. 세션을 여러 개 켜보긴 했지만 체결이 정말 많이 발생하는 것과, 체결이 거의 일어나지 않는 것으로 확인을 해서 아마 확인을 못했던 것 같다. 또, 이때는 총 몇개의 세션까지 연결이 가능한지를 확인하고 있어서 제대로 보지 못했던 것 같다.
이것도 동일하게 금요일 아침에 팀원들 전부가 배포 서버에 들어가서 확인하다가 해당 이슈가 있다는 것을 알게 되었고, 발표 종료 후 점심시간에 핫픽스로 수정했다.
기존 코드에서는 여러 개의 연결을 하면 연결된 모든 데이터에 대해서 다 전달이 됐는데, 필터를 추가해 종목 코드에 맞는 데이터만 전달할 수 있도록 변경했다.
// 기존 코드 getTradeDataStream(): Observable<SseEvent> { return this.eventSubject.asObservable(); } // 변경 코드 getTradeDataStream(targetStockCode: string): Observable<SseEvent> { return this.eventSubject.pipe( filter((event: SseEvent) => { const parsed = JSON.parse(event.data); return parsed.tradeData.stck_shrn_iscd === targetStockCode; }), map((event: SseEvent) => event), ); }
-
-
새로운 기술을 적용하기 전에 어디까지 학습하고 하시나요?
- 저희 팀은 이번에 SSE라는 걸 적용해보기로 했는데.. 제대로 공부하고 하지 않아서 예상치 못한 상황에 몇번 놓였습니다. 구현에 급급해 이런 학습을 뒤로 미뤄두고 했던 한 주였던 것 같은데, 다들 어떤 식으로 학습하고 적용하시는 지 궁금합니다.
⇒ 학습도 못했고, 팀원과의 공유도 많이 못했다. 구현을 열심히 해야 하는구간이 4, 5주차여서 정상적인 상황이라는 멘토님 말씀. 서로 바쁜데 다른 사람이 뭐했는지 귀기울이기 쉽지 않음. 각자 열심히 해보고, 리팩터링 기간에 쭉 학습하고 공유하는 것도 괜찮은 방법.
학습도 중요하지만, 정상적인 서비스가 돌아가는게 중요하니까…
⇒ 백엔드 3명이 다 경험이 많지 않음. nestJS 쓰는 법도 몰랐을 때 페어프로그래밍하고, 소켓 도입할 때도 다같이 페어프로그래밍 하면서! 다 같이 맞으면서 배운 느낌. 페어 프로그래밍했으니까 서로 뭐하는지는 아는 상태이지만 문서 공유는 X
학습은 더 해야 할 거 같긴한데..ㅎㅎ 남는 기간동안 더 열심히 하지 않을까 싶음
-
코드 리뷰는 어떻게 하는가
-
테스트 코드 작성
- 앞선 주차 때 배포에 여러 가지 문제가 있어서 이번 주 월요일에 들어서야 알파 서버와 배포 서버를 제대로 나눠서 사용할 수 있었습니다. 이때문에 알파 브랜치에 FE 코드가 섞여있는 상태인데 알파 브랜치에 FE 코드가 존재해도 괜찮을까요?
- 현재는 alpha 브랜치에 3주차까지의 프론트 작업물이 모두 머지되어 있는 상태입니다.
- alpha 브랜치의 목적상 로컬에서 API 동작만 확인할 수 있으면 되는데 불필요한 파일들이 섞여있는듯한.. 그런 기분이 들어서 이런 질문을 남겼습니다.
- 새로운 기술을 적용하기 전에 어디까지 학습을 진행하고 구현해야 할까요?
- 위에서 언급했던 것처럼 공부를 거의 하지 않고 구현하면서 많은 문제를 겪었는데요… 사실 이번 주가 특히 바빴다거나.. 그런 이유는 아닙니다. 원래 구현하면서 배워보자는 주의인데, 오늘 데모 발표 전에 여러 이슈를 겪었다보니 어느 정도의 공부는 정말 필요하구나를 뼈저리게 느꼈습니다. 그렇다면 어느 정도 수준까지 공부를 하고, 구현을 시작해야 할지.. 고민이 많이 됩니다. 멘토님께서는 어떤 방식으로 학습하고 계신가요?
- 한투 api와 웹소켓 연결하는 과정에 대한 질문입니다. 세션 당 41건 제한에 대해서 이야기 나눠보고 생각해봤습니다.
- 현재 실시간으로 제공되는 부분
- 메인 페이지 상단 - 주가 지수 4개
- 주식 상세 페이지 - 실시간 체결 정보
- 로그인한 유저의 매수/매도 요청에 대한 체결
- 정말 실시간이 필요한 부분인 매수/매도 요청에 대한 체결을 제외하고는 살짝 실시간성이 떨어져도 괜찮지 않을까 하는 생각이 듭니다. 일단 웹소켓을 사용하지 않고 API를 일정 주기로 호출하는 방식도 괜찮을 것 같은. (물론 이마저도 1계좌당 초당 20건까지의 유량 제한이 있어서 어느 정도 주기로 호출을 해야 할지 테스트가 필요합니다.)
- 현재 실시간으로 제공되는 부분
동료와 공유하거나 의견을 묻고 싶은 부분을 정리해보세요.
피어세션에서 나눈 이야기 중 나의 문제 해결 경험과 관련한 피드백과 새롭게 깨달은 점이 있다면 기록으로 남겨주세요.
- J199_이지호님
-
익명도 토큰을 발급해줘서 나갔다 들어와도 누군지 알 수 있게 해줌
-
토큰 하나에 소켓이 두 개가 되는 문제가 있었음
-
같은 세션 내에서는 탭 두 개를 허용하지 않도록 정책을 수정함
-
(영길님) 데모 때 이런 영상을 받았다.
-
-
질문 남기는거, 답변 남기는거, 따봉 누르기 이런건 api로 만들었고 실시간으로 broadcast해주는건 소켓 쓰는 중.
- 요청을 FE → BE로 보낼 때 어떤 소켓인지 알 수 없는 상태로 보내게 됨. 소켓? 탭? 을 식별하기 어려운 상황이 생김.
-
- J049_김영길님
- 다시보기에 채팅 저장?
- 채팅 포함해서 전부를 저장할지, 질문만 저장할지 고민중. 질문은 일단 DB에 저장 중
- RTMP 쓰는데 빠르면 10초 느리면 15초 정도 딜레이 걸려서 나오는데, 와이파이가 안좋으면 뚝뚝 끊겨서보임.
- 유튜브나 치지직처럼 화질 낮춰서 보내는 방식을 쓸 수 있으면 써봐야할 것 같음
- userid를 탈취하는 걸 막고 싶었음
- userId와 클라이언트 아이디를 미리 저장해서, 다르면 위조된 아이디임을 파악해서 처리하려고 했음
- room에 join할 때 값 저장하고 socket disconnected 될 때 값 지우는 방식으로 했는데, disconnected가 정상적으로 되지 않는 상황이 발생. 다음에 들어온 유저가 정상적으로 들어왔는데도 위조된 유저로 판별이 되는 상황이 생겼음
- 어떤 경우에 disconnected가 정상적으로 되지 않는가?
- 빠르게 앞으로 가기, 뒤로 가기를 연타하다보면 그런 상황이 발생. socket.io가 연결을 복구하려고 시도해서 그런건 아닌지 고민 중.
- 로그인이 있으면 식별이 되니까 괜찮았을텐데 로그인 없는 특징을 살리고 싶어서…
- 어떤 경우에 disconnected가 정상적으로 되지 않는가?
- 빠르게 왔다갔다하면 채팅이 안쳐져서 해결하려고 늦게 주무심 ㅠㅠ
- 다시보기에 채팅 저장?
멘토에게 전달하고 싶은 이야기를 정리해보세요. 개별 멘토링 24시간 전에 멘토가 미리 내용을 보고 올 수 있도록 공유해야 합니다.
개별 멘토링 이후에는 멘토와 나눈 이야기가 휘발되지 않도록 기록해보세요.
- 브랜치로 나누긴 좀 어렵긴 함. develop 잘못 따기만 해도 이슈가 생길 수도 있는 부분이라…
- 어떻게 해보자면 FE를 내린 다음에, back/main 깃 이그노어에 ./FE 넣어서 관리하는 법?
- 실제로도 브랜치 하나로 많이 감, 그리고 그 하나 브랜치를 서버 두 개로 할 수 있도록 하는 편
- 아니면 레포지 자체를 나눠서 작업하던가 (이건 근데
- 서버에 다 올려놓고, 프로젝트마다 다 나눠서 배포하는 편, FE 코드 올라가도 상관은 없을듯. 어차피 백엔드 코드만 빌드해서 올릴 거니까
- 멘토님도 일단 쓰고 봄. 신입 때와 달라졌던 건 문서를 보고 내가 원하는 기술의 스펙이 있나없나는 확인하는 편
- swiper라는 라이브러리를 써 봄. 그런 ui가 필요했어서 커스터마이징 해서 써보려고 했었음. 라이브러리에 대해서 간단하게 공부를 했음. 사용법 전부 익힌건 아니고, 우리와 맞는 기술을 찾고, 그거에 대한 사용법 정도만 간단하게! 내가 원하는 거 찾으면 그거에 대한 react 코드보고, 필요한거만 가져다 쓰고.. 다른데서도 필요한거 가져다가 옵션 넣어서 쓰고.. 기술을 먼저 판단하고, 필요한 소스 꺼내썼는데..
- sse 같은거 nestjs에서 주니까 mdn이랑 nestjs 공식 문서 보고.. 대충 해봐도 됨
- 신규 기술 쓸 때 한번 보고~ 기본 개념 간단히 알고 써보기. 추가해봐야할 기능이 있다면 그거랑 관련된 게 있나 없나만 추가적으로 공부해볼듯. 제공해주는 모든 기술에 대해 알 수 없으니까.. 그걸 다 알 수 있기보다는 필요한 기능만 하나씩 찾아보면서 해도 괜찮음!
- 지식에 대해서 공유해야 할 자리가 있으면 더 공부해보는게 맞긴하지만, 부캠 데모 발표 같은거는 특수한 상황이니까 구현해보면서 삽질도 해보고.. 이것도 괜찮다!
- 기본 개념만 알고, 사용법을 숙지한다음에 써보고, 추가 기능이 필요할 때마다 더 깊게 공부해보고
- 지금 당장은 sse를 쓸 순 있지만 어느 순간에는 소켓으로 바꿔야 하는 상황이 생길 수도 있으니 그냥 소켓을 써도 되지 않을까 했던 생각?
- 지금 상황은 세션 늘릴 수밖에 없을듯.
- 우리는 한세션에 41개만 붙는다는 사실을 인지했으니까, 늘려보는 것도 방법! 다섯명이니까 최소 세션 200개까진 되니까, 최대한 깎아보기.
-
지금 쓰는 방식 + RR 같은거 쓰면서 한번 생각해보기.-
세션마다 할당시간 지정. 3초안에 재요청이 안들어오면, 연결을 끊거나.. 이런 방식레디스같은걸 쓴다거나, 클라에서 요청한 시간을 찍어보기. 그 다음에 어떤 프론트에서 삼성전자에 대한 요청이 들어온적이 없으면 삼성전자에 대한 세션을 끊음.
-
- 국장만 지원하고 있는것처럼, 일부 주식만 제공할 수 있게 해도 괜찮을 거 같음.
- 현실적으로 안되는 문제니까 고민한 과정을 설명하고, 기업단위는 더 많이 제공받는 것 같지만, 개인은 41건까지밖에 지원을 안해줘서 일부 주식으로만 제한했다.
- 국장 순위에서 인기있는거 30개 짤라서 얘네만 하자! 라고 해도 괜찮을 것 같다.
- 다섯개로 늘리나, 하나만 쓰나 전부를 못 담는건 똑같으니 그냥 한세션 유지하는거 그대로 가도 괜찮을 거 같다.
- 대신 사이트에 무슨 주식을 지원하는지만! 다 명시하기.
- 최대한 세션을 재활용하기 위한 방법도 충분히 문제 해결 방안으로 시도해본 거라고 생각.
- 다 했지만, 이런 현실적인 문제에 가로막힌건 어쩔 수 없다고 생각.
-
- 계속 이야기했던 그런 과정 자체가 정말 큰 도움이 됐을 거라 생각! 비슷한 문제로 고민할 때 인사이트를 얻었을 것.
- 현실적인 답을 찾는건 이상한게 전혀 아님. 아쉽긴 하지만 어쩔 수 없는거다라고 생각해도 괜찮다.
- [FE] 프론트엔드 기술스택
- [FE] 라이브러리 없이 차트 구현 이유
- [FE] Canvas API 사용방법
- [FE] 네비게이션 바 애니메이션 구현
- [FE] Socket.io 사용방법
- [FE] Tanstack Router에 대하여...
- [FE] Intl(Internationalization) API
- [FE] React Suspense 적용
- [FE] 한글 입력 방식의 유연성을 높인 검색 시스템 구현하기
- [BE] 백엔드 기술 스택
- [BE] SSE vs Socket.io
- [BE] Redis를 도입하게 된 계기
- [BE] ACG Rule을 활용한 Secure CI CD 파이프라인 구현
- [BE] Nginx 로드밸런싱을 통해 한국 투자 API 소켓 제한 극복
- [BE] 주가 지수 기능 개발 과정
- [BE] 매수 및 매도 기능 개발 과정
- [BE] 실시간 자산 조회 기능 개발 과정
- [BE] 단위 테스트
- [BE] redis를 이용한 한국투자 Open API 세션 관리
- [BE] 데이터베이스 인덱싱
- [FE] React에서의 DOM 요소 접근 (useRef vs getElementById)
- [FE] Outlet을 활용한 공통 레이아웃 관리
- [FE] react hooks가 특정 조건에서 실행되면 안되는 이유 & useQuery에 query function 매개변수가 undefined일 수도 있을 때 어떻게 해결할까
- [FE] cross‐domain 로컬 환경에서 cookie로 인증 처리하기 with vite proxy
- [FE] 크롬&사파리 Composition 차이
- [FE] useEffect 의존성 배열
- [BE] Naver Cloud Platform HTTPS 무응답 현상
- [BE] 한국투자 Open API에서 access token을 발급받지 못하는 문제
- [BE] 한국투자 Open API와 웹소켓 연결이 되지 않던 문제
- [BE] 한국투자 Open API 웹소켓 연결이 중단되는 문제
- [BE] 같은 주식 주문이 동시에 여러 번 체결되는 문제
- [BE] 한국투자 Open API Websocket 세션을 두 개에서 한 개로 변경하기
- [BE] Nginx 로드 밸런싱 중 Socket bad Request 발생하는 현상
- [BE] 매수/매도 체결 로직에 의해 redis pub/sub이 정상적으로 동작하지 않는 문제