시작하기
지금까지 회사를 다니면서 기술에 대한 부채가 조금씩 커지고 있다고 느끼고 있었고, 이 기술에 대한 부채를 줄이기 위해 혼자 공부만 하다가 이번에는 프로젝트를 같이 했던 사수분들과 커피챗을 하기 시작했다. 이 글은 커피챗을 하면서 했던 이야기를 간략하게 기록하는 글이다.
커피챗의 주제 : MSA
최근에 같이 프로젝트를 진행했던 사수 분과 함께 판교에서 커피챗을 했다. 점심 시간에 사수 분과 회사 인근 그래비티 카페를 가서 커피챗을 했다. 이번 커피챗의 주제는 MSA(Microservice Architecture)가 과연 정말로 좋은가? 라는 주제로 커피챗이 시작됐다.
MSA(Microservice Architecture)가 과연 정말로 좋은가?
예전에 프로젝트를 할 때, 총 5개의 모듈이 있었는데 각 모듈들을 MSA로 나눠서 관리를 했었다. 근데, 여기는 조금 특이했던 것이 각 모듈들을 나눠서 1모듈 1DB로 나눠서 총 5개 모듈이 있으면 5개의 DB 서버가 있는 경우였었다. 근데, 이 때 MSA를 하기에는 속도도 그렇고 장점이 거의 없었다.
해당 프로젝트를 진행할 때 적용했던 기술들을 간략하게 나열하면,
1. MSA로 인한 SSO 기능 추가
2. SSO 기능에 따른 Session 값 및 인증키 관리(Redis 사용)
- 미들웨어에서 세팅해주면 되는건데... 고객사 IT에서 할 줄을 몰라서 그냥 코드로 SSO 구현
3. DB 링크 불가 및 Restful API로 DB에서 데이터 가져와야 함
- 프로시저 및 트리거 사용 불가
이렇게 진행을 했었다. 제일 큰 문제는 3번이었다. SSO의 경우에는 레디스를 사용하니 별 문제는 없었는데 DB도 모듈 별처럼 분리가 되는 바람에 다른 모듈에서 데이터를 가져와야 하는 경우가 정말 많다보니 가져오는 속도도 정말 느렸다. 그렇다고 DB 링크도 사용을 못해 데이터를 가져와서 비즈니스 로직에서 가져오고 수정하고 매핑하고 별 로직을 다 태워야 하니 속도가 느릴 수 밖에 없었다. 그래서, 이 MSA는 성능도 제대로 잡지 못한 설계 미스였었다.
사수 분이 개발한 MSA는 일단 DB의 경우에는 1개의 마스터 DB와 2개의 슬레이브 DB로 구성이 되어 있다. 1개의 슬레이브 DB는 단순 Read만 하는 DB고, 다른 하나는 마스터 DB의 백업 용도로 사용을 했다. 그리고 나서, 사용하는 서비스들을 모두 MSA로 나눠 버리는 바람에 설계가 정말로 복잡해지고, MSA를 적용하면 적용할수록 가지가 너무 많이 늘어나서 너무 복잡하고 난해한 구축 결과가 나왔다는 것이었다.
각 서비스 별로 나누다 보면, 결합도는 낮아지거나 각 서비스마다 개별 배포를 할 수 있는 장점이 있겠지만, 이 설계를 할 때 효율적인 사상을 가지고 해야 하는데, 이 사상 없이 그냥 덕지덕지 붙이면 복잡한 결과가 나온다는게 가장 큰 흠이다.
그래서 서로 내렸던 결론은 사상을 가지고 어떻게 MSA를 합치고 조립해서 MSA 장점들을 두루 가지고 있고 복잡하지 않게 MSA를 구축할 것이라는 결론을 내렸다. 근데, 이 말이 제일 어려운 결론이지 않을까 싶다. 이런 사상을 가진 사람들은 거의 경험이 많은 컨설턴트와 각 DBA 등의 기술진들과의 협업을 통해 만들어져야 하는 것이기 때문이다.
MSA 예를 들어서는 로그인, 보안, 인증 이렇게 있으면 이것을 MSA로 3개로 나눌 것이냐. 아니면 로그인과 인증을 묶고 보안을 따로 분리를 할 것이냐에 대한 내용도 나눴었다.
예전에 다뤘던 MSA를 다시 커피챗을 통해 이야기를 하니 조금은 색다로우면서도 재밌었던 커피챗이었다.
최근댓글