[회고] SSAFY 특화 프로젝트 - Stock Of Galaxy

 

🥇 SSAFY 2학기 두 번째 프로젝트(특화 프로젝트) 최우수상 수상

이쁜 우리 서비스

두번째 프로젝트를 마치고 회고하는 글로 경험한 것과 느낀점을 자유롭게 정리하였습니다 :)

우리팀 개발 원칙이자 제 개발 철학인 '일단 바보멍청이 방식으로 개발을 끝내자' 를 알고계시면 글 읽는데 도움이 되실 것 같습니다 ..

(일단 기능이 굴러가게 개발을 빠르게 완료한 뒤에, 최적화 작업을 위한 고민을 해보고 이를 작업해보자! 입니다 ㅎㅎ)

 

나도 참 .....ㅋㅋㅋㅋㅋ 프로젝트 끝난지 3달 반이 지나가는데, 수료하고 리팩토링할 수 있는 부분들 생각해보면서 프로젝트 회고를 간단히라도 남겨놔야겠다 생각이 들어서 더 잊혀지기전에 조금이나마 적어보려합니다 ~

공통프로젝트때도 여러 기술 많이 사용했고, 얻은 게 많았었는데 특화프로젝트때도 !! 얻은 게 많았습니다.

혼자서 고민하고 얻어간 것도 많았을 뿐더러, 인프라 지식이나 모니터링 시스템 (elk, prometheus)와 같은 것들도 직접 작업하진 않았지만, 팀원간 기술 공유를 하거나 이야기를 많이 하면서 직접 개발한 것 못지않게 많이 알 수 있었습니다.

특히 인프라 환경까지 고려해서 혼자 고민 많이 하고 찾아보면서 .... 정말 많이 알게 된 것 같아요. 혼자서도 한 번 구축해볼 예정인데 ... 그럼 ec2비용 폭탄 맞겠다.

 

아쉬웠던 점 .. 그러나 이제는 !!!

특히, 이번 프로젝트는 혼자서 고민한 부분도 많았고 개발 막바지 시점에 최적화를 해보고싶은 부분이 있었는데 시간이 촉박해서 아쉽게 못했었습니다.

그리고 저희 서비스의 목적 중 하나인 실시간성을 보장할 수 있으면서, 트래픽이 몰렸을때 서버를 수평확장시키면서도 서버 자원을 아낄 수 있는 방법에 대해 정말 오랜시간 고민했었는데요.

(프로젝트 기간에는 kubernetes환경임에도 불구하고 바보멍청이 방식으로 단일서버로 한정시켜뒀음 .... 진짜 더 잘 할 수 있는데, 시간도 없고 채용시즌이라 너무 바빴기에 할 수 없어서 너무너무너무 아쉬웠습니다.)

계속 생각하다 최근에야 괜찮은 방법을 떠올리고 구체화시켜서 새롭게 사용해볼 기술이나 리팩토링을 어떤식으로 할지는 다른 게시물에서 다뤄보겠습니당 😃

 

지금은 그냥 간단히 프로젝트 회고 !!!

깃허브 링크

https://github.com/SunYerim/StockOfGalaxy

GitHub - SunYerim/StockOfGalaxy: 🥇 SSAFY 11기 특화 프로젝트 최우수상 - 삼성전자 주식회사 / 과거와 현

 

저희는 우선 '빅데이터 - 분산' 도메인을 선택해서 프로젝트를 진행했었고, 

최종적으로 "과거와 현재의 주식 정보 및 뉴스기사 정보 제공 서비스"를 기획하여 개발했습니다.

뉴스 데이터만 해도 300만건 이상이었으며, 주식 데이터 같은 경우는 실시간으로 제공하는 것에 과거 데이터도 함께 제공하여 50만건 이상의 데이터를 다뤘습니다.

 

저는 평소에 주식에 관심이 있기도 했고, 실시간 데이터를 다뤄보고 싶어서 주식 도메인과, 회원관리 백엔드 개발 부분을 도맡아 했습니다.

실시간 데이터 처리하는 부분 같은 경우도 '한국투자증권 <-> 스프링 서버, 스프링 서버 <-> 서비스 클라이언트' 이런 구조로 작업을 했어야했기에 생각할 부분이 많을 것 같았기도 했습니다.

 

저희는 kubernetes 클러스터 환경으로 서버 구축을 했었으며, MSA구조를 도입하였습니다.

사용자 트래픽이 몰릴 경우 pod이 자동 생성되도록 해뒀지만, 주식 도메인 같은 경우는 단일 서버 환경으로 한정하여 작업을 진행하였습니다... 처음부터 그랬던 건 아니었고요 ...

 

우선은 바보멍청이 방식으로 해보자! 그리고 개발을 마무리짓고 최적화를 해보자. 마음을 먹었는데... 그때는 입사지원도 한참 많이 할 때라 여유도 없었을 뿐더러, 실시간로직 서버를 분리시키고 kafka와 같은 메시지큐를 도입한다고 가정했을때 실시간성 보장을 어떤식으로 해줄지, latency를 어떻게 줄일지, batch처리를 한다고 했을때 완벽히 실시간 정보를 제공하지 못할 거 같은데 어떻게 해야하지 .. 온갖 고민이 들어서 나중에 꼭 혼자서라도 최적화를 하자. 라고 생각했습니다.

 

 

위에 너무 두서없이 적은 것 같은데요 ..... 

그래서 저는 크게 세 가지로 분류해서 작성하고 글을 이만 마무리 짓겠습니다.

 

 

뭘 하고 싶었는데?

1. 하나의 주식서버를 분리하고 싶었습니다.

2. 데이터양이 많다보니 과거 주가 정보 조회할때도 시간이 너무 오래 걸려서 최적화 작업을 하고 싶었습니다.

3. kubernetes 클러스터 환경의 이점을 제대로 활용하고 싶었습니다 ~!!!!! 트래픽 몰리면 서버가 수평확장 되도록요 .... pod 생성되어라.

 

왜?

1. '주식'이라는 게 실시간 데이터 + 기존 데이터를 동시에 제공해줬어야됐는데, 이거를 바보멍청이 방식으로 일단 기능 굴러가게하자! 해서 한 서버에서 모든 걸 처리한다는 게 너무너무너무 ....!!! 아쉽게 느껴졌었습니다.

 

2. 그래서 저는 처음에 실시간 주가 정보 제공만을 담당하는 서버, 그리고 그 외 기능을 담당하는 서버 이렇게 분리시키고자 했습니다.

이렇게 했을때, 전자 같은 경우는 한국투자증권과 websocket통신을 통해 구독하고자하는 종목에 대한 주가정보만 가져오는 역할만 하면 됐고, 그리고 후자 같은 경우는 그 정보를 저희 서비스 클라이언트들에게 제공해주는 역할만 하면 됐으니까요. (크게 보면)

 

3. 그리고 중간에 메시지큐를 놓아서 publish, subscribe하는 방식으로 구상했었습니다. 이렇게되면, 실시간정보를 담당하는 서버는 단일서버로 한정시켜둬도 무관하고, 실시간 정보 외적인 것을 담당하는 서버는 서버 수평확장 되도록 적용하면 되겠다 싶었습니다. 그렇지만, '그럼 그 실시간성 어떻게 보장하지? latency어떻게 줄이지?' 라는 고민이 갑자기 파바바박 들어서 까비 ...

 

4. 데이터 양이 많아서 정보 조회할때 오랜 시간이 걸린다는 건, 서비스를 이용하는 유저 입장에서 너무 치명적인 단점이기 때문에 ...!!

 

5. 이 부분은 gateway에서 캐싱처리를 하고, db인덱싱처리를 해서 최적화작업을 완료했습니다 !!!

 

6. 무엇보다 주어진 환경을 최대한 잘 활용하고 싶었습니다. 사용자 경험을 최적화하는 건 물론 서버 환경도 최적화하고 ....!!!

 

 

그래서 어떻게 할건데?

실시간 정보 담당 서버 -> 단일 서버 환경

실시간 정보 외 담당 서버 -> 분산 서버 환경 (pod 생성되도록)

 

자 .. 서버를 분리하면 현재 로직에서 수정해야될 부분이 몇 가지 있습니다.

 

1. 웹소켓 세션관리

항상 동일한 서버로 연결된다는 보장이 안 되어있죠? 물론 로드밸런싱으로 한 서버에 고정적으로 연결되게 처리할 수 있습니다 .. 그렇지만, 현재 유저서버에서도 redis를 사용하고 있기에, redis 사용해서 웹소켓 세션id를 모든 서버에서 공유할 수 있게끔 처리하고자 합니다.

 

 

2. 서버 분리

위에 기재된 대로 서버를 분리하려합니다.

 

실시간 정보 담당 서버는 단일서버로 한정합니다. 왜냐? 어차피 한국투자증권과 websocket 통신을 해서 원하는 종목의 주가정보를 실시간으로 계속 가져오게 되는데, 이거는 트래픽 증가와 무관하게 그냥 동일한 정보 제공해주면 되는 부분이기 때문에, '주가정보'만 들고있으면 됩니다.

 

실시간 정보 외 담당 서버는 트래픽이 증가함에 따라 pod이 생성되도록합니다. 실시간 정보 담당 서버에서 받은 데이터들을 메시지큐로 publish할텐데요. (이 부분은 아래쪽에, 그리고 다른 글에서 더 자세히)

그렇게되면 해당 메시지를 구독해서 서비스 사용자들에게 제공하면 된답니다 ㅎㅎㅎ

 

 

3. Redis Stream 도입으로 일정부분 고민 해결-!

물론? 아직 직접 작업해보지 않았지만, 실제 운영중인 서비스에서 고민했던 부분이나 도입을 결정 하게된 배경이 비슷하더라구요. 그리고 고민했던 부분을 최대한 해결할 수 있을 것 같았습니다.

기존 Redis pub/sub를 적용한다면, 특성상 구독자가 없으면 메시지를 Publish해도 바로 휘발되는 .. 치명적인 단점이 존재하는데, 그런 부분을 고려하지 않아도 되었고, 무엇보다 이미 redis를 사용하고 있는 상황이었기에 적합하다 생각했습니다. 

 

이전에 Kafka message queue를 사용했었는데, 이와 되게 유사하다 느꼈습니다.

 

물론 redis가 in-memory db라 죽었을 경우 (데이터 휘발 ......까비) fail over하는 과정 .. 그런것들도 고민할 게 많은데 오히려 좋아

 

---

 

너무 우당탕탕 제 머릿속에 있는 거 마구마구 끄집어 내서 두서없이 적었는데 ... 그냥 한 사람의 회고글이자 고민이 가득 담긴 글이었습니다.. !!!!

---

참고

https://dev.gmarket.com/113

Redis Stream 적용기

https://oliveyoung.tech/2024-11-15/inventory-changed-stocks-function-with-redis-stream/

재고의 변동을 시계열 데이터로?! | 올리브영 테크블로그