서론
다양한 서비스들이 서버를 점점 분리한다.
트래픽의 이유로, 확장성과 유지보수성의 이유로 등 서비스들이 작게 작게 쪼개지는데 이렇게 작게 쪼개지면서 발생하는 문제점은 어떤게 있을까?
이글에서는 서버의 분리부터 서버를 잘못쪼갤경우 발생되는 문제점은 어떤게 있고
문제점을 깨닫고 통합하는 과정을 간단하게 다루고 공유하려고 한다.
아래의 예제 상황을 통해 시나리오를 구성하려고 한다.
1. 학생, 선생님, 학부모 등의 Actor 가 존재한다.
2. 학생은 신청서를 통해 선생님과 매칭 될 수 있다.
3. 선생님은 학생, 학부모와 달리 지원프로세스 및 심사를 통해 자격을 얻는다.
4. 학생과 선생님이 매칭될경우, 수업을 진행 할 수 있다.
//서버 구성 예시
user : 누구나 가입 할 수 있는 유저를 관리 (학생, 학부모, 자격을 얻지 못한 선생님)
matching : 선생님 관리 및 신청서를 통해 적합한 선생님과 매칭. 선생님 지원서를 통한 심사.
lecture: 수업에 대한 관리 서버본론
3월 대학생들은 "대학교도 입학했겠다. 자취도 하겠다. 알바나 해볼까?"
하고 많은 대학생들이 과외 알바 지원을 하였다.
같은 시각에 3월 모의고사를 보고 학생들이 "나 이러면 안되겠다 .. 응급과외를 통해 내 등급을 올려야겠다." 하고 과외를 신청하기 시작했다.
매칭 서버에서는 매우 바쁘다.
왜냐하면, 학생들의 복잡한 요구사항에 대해 맞는 선생님을 찾아 매칭 시켜줘야하고, 새로 지원한 선생님들을 심사하고, 기존의 있는 선생님들을 관리해주어야 하기 때문이다.
이때 회사에서 한가지 OKR 이 들어온다.
"선생님을 세밀하게 관리하고 지원프로세스를 자동화하자 !!"
매칭 서버에 맞지 않는 책임을 제거하고, 방향성에 유연하게 대응하기 위하여
A 개발자는 매칭서버에서 관리하는 선생님에 대한 데이터 및 로직을 하나의 서버로 분리하기 시작한다.
유저 서버에 통합하지 않고, 선생님 서버로 따로 분리를 한 이유는
1. 생명주기가 다르다.
2. 다른 유저와 달리 주기적으로 관리 및 심사 지원프로세스가 존재한다.
3. 정산 같은 선생님에 특화된 기능이 필요하다. 였다.
이러한 이유로 서버 분리를 진행 하는 도중 문제가 발생하였다.
1. 불필요하게 많은 통신 ( 유저 정보와 선생님 정보 함께 조회 및 관리되어야 하는 지점 생각보다 많음 )
2. 유지보수 및 코드 품질 관리 ( 가장 큰 이유 )2번에 대해서 자세히 얘기해보려고 한다.
말 그대로 유지보수를 위해서 들어가는 리소스가 많이 들어간다는 것인데 어떤 리소스가 들어갈까?
1. 서버를 유지하기 위한 금전적인 리소스
2. 서버를 관리하기 위한 개발자의 리소스
3. 개발자의 코드 및 더 좋은 문제해결을 위한 또다른 개발자의 코드 리뷰 리소스
4. 하나의 추가 기능 개발을 하는데에 드는 리소스 1번은 해당 서버를 유지하기 위한 금전적인 리소스이다.
새로운 도메인을 유지하는데에 필요한 인스턴스는 굉장히 많다.
DB, Application Instance, 부터 시작해서 로드밸런서, 로그관리시스템,
DB 는 Mongo, Mysql 등등 여러가지 데이터베이스를 사용할 수도 있다.
이러한 것들이 dev, stage, prod 각각의 환경마다 필요하다보니 꽤나 큰 금전적인 리소스가 필요하다.
2번은 서버를 관리하기 위한 개발자의 리소스이다.
서버가 여러개로 나눠져있으면 스타트업의 특성상 한명의 개발자가 1~2개 또는 그 이상으로 서버를 담당하게 된다.
즉, 온전히 해당 개발자의 의견에 따라 서버가 운영 및 구성된다.
그러다 보니 한명의 개발자가 퇴사를 하거나 휴가 및 퇴근을 하는 경우, 이슈가 났을 때 대응이 어렵다. 왜냐하면 한번도 보지 못했던 코드이기때문이다.
서버 자체가 나눠져있고 레포 자체가 나눠져있으니 도메인 개발자는 자신이 속한 도메인에만 국한되어 한쪽에서 이슈가 터졌을때 마냥 기다리고만 있는 상황이 벌어지는 것이다.
3번은 2번과 연결되어있다.
2번 같이 레포 자체가 한명의 개발자에 관리되어있고, 언어 자체도 다른 레포가 많기 때문에 코드리뷰 문화가 형성되기 힘들다.
즉 개발자는 자신의 생각에 갇혀 코드를 짜게 되고 서비스도 개발자 자신도 성장하기 힘든 상황에 놓일수 있다.
또한 이러한 것들은 추후 인수인계 및 다른개발자가 코드를 보려고 할때 더 큰 문제로 퍼질수 있다.
4번은 MSA 특성상 여러서버와 유기적으로 통신하기 때문에 하나의 기능이 추가되려면 여러 서버에서 대응을 해주어야한다.
A, B 개발자가 각각 C, D 도메인을 담당하고 있따면 B 개발자는 D 도메인과 관련된 프로젝트를 진행중에 C 에게 요청이 오게 될것이고 C 는 D 개발자에게 의존성이 생길 것이다. 이러한 것들이 병렬적으로 돌아가야하는 프로젝트들에 제동을 걸고 혼란스럽게 운영될 수 있을것이다.
이러한 문제들을 해결할 수 있는 방법은 불필요하게 나눠져있는 서버를 통합하는 것이였다. 도메인은 달라도 레포 및 서버가 통합되어있으면 코드를 볼 수 밖에 없고 관련된 일들은 자신이 직접 처리 할 수 있을 거같다는 생각을 하였기 때문이다. 또한 하나의 서버에 2명의 개발자가 존재하기 때문에 한명이 퇴사 및 부재하더라도 한명의 개발자가 처리 할 수 있을 거라는 생각을 하였다.
서버를 통합하면서 불필요한 통신을 줄일 수 있고, 막대한 서버비용을 줄일 수 있고 생산성을 높일 수 있다.
확장성에 대해서는 쪼개면 쪼갤수록 확장성을 물론 좋아진다. 하지만 현재의 회사상황과 유지보수와 비즈니스 이 관계에 대해서 전반적으로 생각을 해보아야할 것 같다.
이 상황에서는 유저와 선생님을 합쳐도 서비스는 정상적으로 유지되고, 그렇다고 유저 서버의 부하가 못견딜정도가 되는 것도 아니며 추후 확장이 필요한 경우 혹은 서버의 부하가 심할 경우 분리를 결정해도 늦지 않겠다 라는 결론을 내렸다.
(cc.. 매칭은 수업과 합쳐졌다.)
결론
서버를 쪼갤때 데이터의 색깔을 잘 구분해야겠다고 생각하였다.
데이터의 색깔은 결국 의존성으로 결정될 수 있을 거같고, 같은 색깔의 데이터를 찢어놓으면 불필요한 네트워크와 한개만 관리하면 될 서버를 동시에 2개를 관리해야하는 이슈가 생긴다.
서버를 찢을때 정말 찢어야 할까 라는 생각을 앞으로는 많이 할 것 같고
시스템을 설계 할때 의존성 그래프 및 Flow 흐름도를 그리는 이유를 알게 된 것 같다.
