회사 솔루션 구조를 분리한 이유

기존 솔루션의 구조

기존 고객사에 배포했던 솔루션의 구조입니다. 주로 고객사가 대학교였고(간혹 대학원이 있었지만 큰 차이는 없으므로), 고객사들의 종류가 서버를 관리하는 외주 업체가 따로 있는 경우, 학교 전산팀에서 서버를 관리하는 경우, 그리고 외주도 없고 전산팀도 없고 서버도 없는 경우 이렇게 크게 세 가지로 분류됩니다.

분류는 세 가지로 나눠볼 수 있지만 공통적인 특징은 서버를 마음대로 스케일 아웃할 수 없는 환경이었습니다. 당연히 비용적인 문제가 가장 큰 이슈였습니다. 이런 환경이다 보니 최초로 솔루션을 납품할 때 학교에서 줄 수 있는 최고 스펙의 서버를 요청한 후에 그 서버에 모든 서비스를 배포해서 납품을 했었습니다. 당연히 이렇게 배포하다보니 모든 비지니스 로직이 백엔드 서버 한 곳에 집중된 상태였습니다.

처음에는 큰 문제가 되지 않았습니다. 솔루션은 사실 납품한 후에는 학교 전산팀에서 관리하고, 관련 운영 부서에서 솔루션을 운영하므로 크게 운영을 경험을 환경이 아니였습니다. 하지만 더 큰 금액으로 신입생들의 1년을 운영까지 맡긴 학교가 나오면서 해당 구조에서 불편함이 생기기 시작했습니다.

요구사항

추가적인 요구사항까지 개발하기로 약속된 프로젝트였기에 학기 중에도 학교에서는 학기 중에 필요한 이벤트(축제, 교수님과의 면담 등)에 사용할 QR 체크 기능 등을 요구해 왔습니다. 문제가 된 점은 학교라는 조건에서 LMS의 특성이 합쳐지면서 학생들이 어떤 시간에라도 수업을 진행할 수 있으므로, 출석에 관련해서 항상 서버가 대기를 하고 있어야 하는데 새로운 기능 배포를 위해서 서버를 중단하는 경우 출석 데이터에 대해서 신뢰성이 무너질 가능성을 생각하게 되었습니다.

고민하다가 선택한 방법은 여러 컨테이너로 실행 중이던 서비스 중에서 절반만 배포한 후에 나머지 절반을 배포하는 수동으로 실행하는 블루/그린 배포를 진행했습니다. 이 방법은 큰 문제를 일으키지 않았고(매우매우매우 귀찮고 할 때마다 긴장이 된다는 단점을 제외한다면), 덕분에 이 방법으로 한 학기를 무사히 운영할 수 있었습니다.

성적 데이터까지 학교에 전달하고 한 학기를 무사히 마무리한 후에 다음 학교들에 납품할 솔루션의 구조에 대해서 고민하기 시작했습니다.

항상 운영되어야 하는 기능을 분리하자

사실 운영하면서 어느 정도 결심한 바가 있었기 때문에 먼저 항상 운영되어야 하는 기능들에 대해서 분리했습니다. 크게 출석을 담당하는 곳과 과제, 퀴즈들의 점수를 조합하는 부분이었습니다. 다만 과제, 퀴즈 부분은 수정될 요인이 많은 곳이었기 때문에 출석과 묶진 않았습니다. 출석은 정말 한치의 오차도 없어야 했고, 만약 오차가 있더라도 모든 데이터가 있는 DB를 통해 빠르게 피드백할 수 있어야 했기 때문입니다.

출석과 관련된 서버 또한 분리했습니다. 출석 서버에서 데이터를 요청할 경우 항상 운영되고 있어야 했기 때문에 동영상 시청 정보를 수집하고 줌 화상 강의를 수집하는 서버 또한 따로 운영하도록 설계했습니다.

분리해보니

사실 분리하는 것은 장점만 있는 것은 아닙니다. 한 서버에 있어서 편하게 개발할 수 있었던 부분들이 다 분리되었기 때문입니다. 또 저희 팀이 MSA를 지향하거나 선망하기 때문에 한 결정도 아니였습니다. 그저 좀 더 똑같이 운영하는 경우가 왔을 때 부담을 줄이기 위한 결정일 뿐이었습니다. 사실 서버의 수도 많아봐야 2개이기 때문에 쿠버네티스를 운영하긴 적절하지 않아서 컨테이너가 많아봐야 관리 이슈가 생길 수도 있었습니다.

하지만 현재까지의 결론으로는 대만족하고 있습니다. 데이터를 가져오려면 외부 API 통신처럼 가져와야 하는 단점들이 있지만 그럼에도 서비스가 더 탄탄하고 안정적으로 변했다는 느낌을 정말 크게 느끼고 있습니다. 다음에는 속도에 대해서 리뷰해보겠습니다