종목토론게시판이 있는 SNS 프로젝트

스프링부트와 자바, 그리고 DB 선정

린예라 2024. 4. 19. 11:12

주식API를 가져올 수 있는 기능 + 게시판 + SNS 이고 대규모 트래픽을 가정한 MSA 프로젝트이다.

현재 시간은 2024년 4월 19일 오전9시이다.

 

자바 스프링 부트 + DB로 프로젝트를 한다.

 

주로 고려한 것은 내가 사용하기에 편한가?+검색자료가 많은가?, 성능적으로 다른 비교군에 비해 우수한가?, 서버인만큼 안정적인가?, 비용이 발생하는가? 등을 고려 하였다.

1.스프링 부트 + 자바 선택

호환되는 스프링부트 버전이있고, 완전 신버전도 아니면서 그 이전버전들에 비해 성능이 향상 되었을 것이 기대되고,버츄얼쓰레드라는 기능이 있는 자바21버전을 선택하고

거기에 맞춰 스프링 부트는 23년 11월말에 출시된, 자바 21 버전과 호환되는 3.2의 비교적 안정화된 버전중에 최신버전을 선택하였다.

 

이 아래의 글은 이런 결정을 하기까지의 나의 기술적 의사결정 과정이다.

 

제법 규모가 큰 프로젝트가 될 것이다.

그렇기에 테스트를 한번에 하려고 하면 매우 힘들어 질 것이다.

부분적으로 기능마다 테스트하고 테스트가 끝난 부분을 하나씩 끼워 맞춰 가는 TDD방식으로 개발해 나가는 데

스프링이 적합하다고 생각 했다. (의존성이 있는 부분의 기능들로 얼마든지 자유롭게 테스트가 가능!)

그리고 스프링에 대한 사용이 미숙하므로 여러가지 설정을 기본적으로 지원하는 스프링 부트를 사용 할 것이다.

그리고 스프링을 배우고 배우고 싶다는 희망도 있다.

 

자바는 여러 버전이 있다.

자바 22버전이 24년 3월19일에 출시되었지만 너무 출시된지 얼마 안되어서, 불안한 느낌이 없지 않아 있다.

왜냐하면 보통 신버전이 출시되면 뭔가 오류나 버그, 각종 호환성 문제가 생길 수 있기 때문이다.

 

하지만 나는 완전 처음부터 작성하는 거기 때문에 호환성을 걱정할 필요는 없다.

 

또한 자바 21버전부터 본격적으로 적용된 버츄얼 쓰레드라고 하는, 경량 쓰레드 라고도 한다던데

경량 프로세스라고 불리는 쓰레드인데 거기서 더 가벼워졌다? 궁금하다. 호기심이 생겼다.

 

내가 앞으로 서버에서 겪게 될 여러가지 성능적인 문제를 해결해 줄 수 있지 않을까? 라는 생각이 들었다.

 

자바21버전의 버츄얼쓰레드보다 자바22버전의 버츄얼쓰레드가 뭔가 더 업그레이드 되었을거 같은데, 관련자료는 일단 잘 찾지 못하겠다. 그런데 자바 22버전은 출시된지 이제 막 한달 된 신버전이다.

 

일반적인 경우에는 sw가 신버전이 출시된 직후에는 이전버전에 비해 불안정한게 맞긴한데.

 

Java의 경우에는 많은 기업과 커뮤니티에 의해 개발되고 유지보수되는 대규모 프로젝트라서 새로운 버전이 출시될 때도 여러 테스트와 검증을 거치며 안정성을 확보한다고 한다.

추가로 표준 프로세스와 엄격한 테스트 절차가 있고, Java Compatibility Kit을 사용하여 자바 구현이 기존 사양과 호환되는지도 검증한다고 한다.

그렇지만 역시 초기버전으로서 불안정성이 있겠지만 다른 소프트웨어의 초기버전에 비해 안정적이라는 이야기겠지.

 

기존 코드랑 호환이 되니까, 내가 막혔을 때 검색해서 찾는 이전버전의 코드들도 도움이 아예 안되는건 아닐거 같아서 21버전이나 22버전을 사용하려고 한다.

 

그리고 일단 위 버전들에 호환되는 스프링 버전을 찾아봐야한다. 22버전이랑 호환되는 스프링부트 버전이 아직은 없는거 같다. 

 

24년 4월 19일 현재  start.spring.io 기준 스프링부트 버전들

 

 

2.DB 선택

MySQL 8.0 + MongoDB + Redis(서브) 이고 MySQL을 중심으로 모노리틱서비스로 개발하고 MSA로 전환하면서 MongoDB와 Redis를 투입하는 방식.

무료이면서 사용이 간편하고, 검색자료가 많은 MySQL와 사용이 간편하고 유연한 데이터 모델링이 가능한 MongoDB를 선택하였고, 부가적으로 필요한 캐쉬서버같은 역할은 Redis를 사용하기로 하였다.

 

1.RDB vs NoSQL

크게 DB의 분류부터 선택해야 한다.

대규모 트래픽의 SNS를 가정하고 있다. 그렇기에 다른 대규포 트래픽의 SNS가 사용하는 DB를 찾아 보았다.

 

세계에서 사용자가 가장 많은 Facebook이랑 인스타그램이 사용하는 DB 모두 NoSQL방식의 DB이다.

하지만 RDB방식의 MySQL 또한 같이 사용한다.

 

NoSQL이 대용량의 데이터처리를 위한 수평적 확장이 용이하다. 즉 분산처리에 용이하다.

그렇지만 트랜잭션의 부분적지원 같이, 데이터의 일관성유지가 RDB에 비해 힘들다는 단점이 있다.

 

내가 만약 금융이나 은행관련 서비스를 만든다고 하면 주저없이 RDB를 골랐을 거다.

그렇지만 RDB는 부분적인 수직적확장이 조금 가능하고, 대규모의 데이터를 처리하는데에 있어서 NoSQL이랑 비교 했을 때 적합해 보이지 않는다.

 

사용자의 계정이나 정보에 관련된 정확도가 중요한 정보들은 RDB방식의 DB에서 관리하고,

그 외의 게시물이나 뉴스피드 같은 것들의 정보는 NoSQL방식의 DB에서 관리해야겠다.

 

그리고 우선은 모노리틱서비스를 만들고 나서 MSA로 전환할 것이기 때문에, 처음은 RDB방식으로 서비스를 만들어야 겠다.

 

2.RDB선택

대표적인 RDB 4개

MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server

Oracle Database와 Microsoft SQL Server는 상용 SW이기 때문에 내가 서비스를 제작한다고 하였을 때 제외 할 것이다.

 

왜냐하면 MySQL과 PostgreSQL은 무료이고, 페이스북의 사례로 MySQL은 대규모 데이터처리에 한계가 있다는 주장이 완전히 사실이 아님이 입증되었기 때문이다.

 

Oracle DB는 여러 기업에서 많이 사용하는 만큼 확장성이 우수하고 대규모데이터처리에 적합하다고는 하지만,

RDB라는 구조적 한계때문에 NoSQL방식의 DB보다 유리할 거 같지 않다. 

만약 이 구조적 한계를 뛰어 넘어 Oracle DB가 NoSQL DB보다 우수했다면 굳이 NoSQL방식의 DB가 나왔을거 같진 않다.

 

나는 NoSQL DB도 함께 사용할 것이기 때문에 성능이 우수하다고는 해도 비용이 발생하는 Oracle Database, Microsoft SQL Server는 제외한다.

 

그럼  MySQL과 PostgreSQL 2개중에 한개를 선택해야 한다.

 

일반적인 성능은 PostgreSQL이 MySQL보다 좋은거 같다.(대규모 데이터처리, 실시간데이터처리, 복잡한 쿼리처리 등에서의 빠른 응답시간) 

대신 MySQL에 비하여 설정이나 관리가 조금 더 복잡해 질 수 있다.

 

그렇지만 MySQL은 PostgreSQL에 비해 사용자가 많아서, 내가 찾고자 하는 관련 소스들이 훨씬 많다. 내가 DB를 어느정도 많이 다뤄본 숙련자 였다면 PostgreSQL을 사용하였을 것이다.

 

하지만 나 같은 경우 검색자료가 보다 더 다양하고 비교적 사용이 간편한 MySQL을 선택하기로 했다.

또한 버전의 경우 8.1이 존재하지만 현재 Innovation Release라는 테스트 버전이라 안정성은 떨어질 수 있다고 생각된다.

계정정보등의 중요한 정보를 저장할 것이기에 무엇보다 신뢰성과 안정성이 중요하다고 생각해서 8.0을 사용하기로 결정했다.

 

3.NoSQL DB선택

대표적인 NoSQL DB 4개

MongoDB, Cassandra, Redis, Amazon DynamoDB

 

Amazon DynamoDB같은 경우는 사용량에 따라서 요금이 부여되는거 같고, 무료로 사용할 수도 있긴하지만 앞의 MonogDB나 Cassandra에 비해 지명도가 떨어지고(즉 검색 자료의 양이 앞의 두개에 비해 많을 거 같지 않다.)

성능적으로 더 우수할거 같지 않기에 제외한다.

 

MSA방식을 채용할 것이기에 Redis는 뭔가 부분적으로 사용 할 수 있을 거 같다. 캐쉬서버 같은걸로 활용한다는걸 들어본거 같기에.....

 

그래서 메인은 MongoDB나 Cassandra중에 하나인데 이거 선택이 너무 어렵다;

MongoDB는 유연한 데이터 모델링으로 사용이 편한거 같고, Cassandra는 정적인 데이터 모델링에 사용이 어렵지만 우수한 대규모처리능력을 가진거 같다.(페이스북에서 사용한다는 것으로 보면 성능 증명은 어느정도 끝낸 셈인거 같다)

 

애초에 카산드라는 페이스북에서 대규모트래픽처리를 위해 자체적으로 개발하고 오픈소스로 공개한 DB인듯 하다.

 

내가 만드려는 기능이 SNS기능이 많으니 카산드라가 보다 적합하지 않을까?

그치만 몽고DB도 뭔가.....

 

일단 내가 초보니까 카산드라에 비해 사용이 편리한 몽고DB를 사용해야겠다.

내가 어느정도 숙련자였다면 SNS서비스를 생각하는 나의 입장에서는 카산드라를 사용했을 것이다.