반응형
개요
연말을 준비하면서 개인 서버의 서비스들을 정리해보고자 한다.
한 동안 바쁜 일정도 있었지만, 최근 서비스 개발이 없었던 이유 중 가장 큰 것은 모노리틱 구조로 설계한 서버도 한몫을 하고 있다.
이전에 MSA 식으로 개발해 봤던 부분과, 올해 모노리틱으로 설계한 부분의 장단점을 분석하고 다음 시즌에는 보다 길고 탄탄한 서비스를 만드는 방향으로 기획하려 한다.
모노리틱 서비스 구조 문제
모노리틱 서비스를 개발할 때 발생하는 문제점에 대한 고찰
너무 많아지는 의존성
예를 들면, 한 프로젝트 내에서 여러 DataSource를 관리해야 되는 문제가 발생했다.
여러 서비스의 성격이 다르고, 적합한 DataSource가 다르다 보니, 서버에 지속적으로 Data Access Point가 늘어나게 되었다.
현시점 연동 상황...
서비스 1은 사실 레디스가 필요 없지만, 프로젝트가 하나기에 영향을 받는다.
개발 시점에, 여러 인프라를 신경 써야 한다...
실제로 db를 안 쓰더라도, 로컬 개발 시, 개발환경의 모든 인프라를 챙겨서 세팅해야 run이 가능하다.
번거로운 서비스 다운
개인 개발 특성상,
실험적인 서비스 또는 한시적인 기능을 돌릴 때가 있다.
하지만, 모노리틱 구조상, 패키지 구조를 신경을 많이 써야, 스무스한 제거가 가능하다.
(하지만, 그런 한시적, 실험적인 부분에 공들여서 만들 리가 없었다..)
비대해지는 소스
일반적인 문제
소스가 점점 뚱뚱해지면서, 리펙토링 등 대부분의 작업에서 리소스가 추가적으로 투입된다.
단순 빌드시간만 해도 계속 늘어난다...
MSA 구조 문제
이전에 MSA 구조로 개발을 진행했었다.
하지만, 여러 문제점이 발생했으며
모든 문제는 하나의 이유로 귀결된다
-> 1인 개발이기에 투입가능한 리소스(시간+열정)가 부족하다..
인프라 작업 시간
당연하게도 1인 개발에서 서버 인프라 관리는 스스로 해야 한다.
또한 비용 투입 없이 하기에, Cloud 서비스 같은 부분은 불가하다.
이에 인프라 하나 추가할 때 모든 관련 설정을 스스로 해야 하고, 이에 투입되는 비용이 너무 컸다.
반복 작업
개인 개발의 최대 동기는 새로운 걸 해보면서 느끼는 재미이다.
하지만, 여러 이유로 반복적인 작업이 늘어난다.
가령 CI / CD도 프로젝트 생성 시마다 일일이 작업해야 하며, 시스템 간 연동을 위한 코드, ip / port 매핑 작업 등등이 있다.
이에 점점 새로운 시도를 하기 귀찮아지며, 신규 개발에서 멀어져 갔다..
Point to Point 연결, 서비스 의존성
A, B 서비스 간의 변경인데, 연동되어 있던 C에서 문제가 발생
인증 쪽 프로세스 변경이라도 일어나면 머리가 아파옵니다.
앞단 인증 쪽에 role 베이스 인가관리 추가하다가, 엄청 터져나갔던 기억이 있네요...
통합 테스트 환경 구축
모듈 여러 개의 통합 테스트를 진행하려면 띄울 거 다 띄우고 진행해야 합니다.
리소스가 부족한 상황에서 mocking을 통한 test case 작성은, 너무나도 힘들었네요...
Next 설계
MSA 구조 채택
모노리틱으로 구성해 본 결과, 1인 개발은 빠른 치고 빠지기가 가능한 MSA 구조가 적합할 것이라 판단됩니다.
손쉬운 프로젝트 추가/제거 구조 확보
최대한 신규 서비스를 추가하기 쉬운 구조를 확보하고 시작
현 계획은
1. Jenkins Script를 활용하여, CI / CD 구성 간소화
2. Zookeeper를 통한 신규 시스템 연동 과정 단순화
3. 관제 서버를 구현하여, 전체적인 서버들의 상황을 모니터링
정도 있다.
Point to Point -> Event Driven
Kafka를 활용하여, 대부분의 비즈니스를 event driven으로 구성,
서비스의 가용성 및 확장성을 확보
마치며
이번에는 전체적인 서버 아키텍처를 설계하고 시작할 것
지금까지의 경험을 최대한 살려서, 지속 가능한 서버 운영을 목표로 함
반응형