프로젝트 구조설계 (1)

1-1. 컴포넌트 기반으로 설계

기존의 서버는 대부분 모놀리식 형태로 존재하는 경우가 많다. 하나의 큰 돌로 만들어진 건축물처럼 단일 기능, 역할을 담당하고 잇는 서비스를 모놀리식 이라고 하는 경우가 많다. 반대되는 의미로는 마이크로 가 존재한다.

커다란 하나의 어플리케이션에 사용된 꼬일대로 꼬인 스파게티 코드는 서로 의존성이 강해지고, 이후 겉잡을 수 없이 커져버려 수정하기 어려워 지는 경우가 많다. 따라서 사전에 모듈화 하고, 각 기능들은 서로 의존성을 최소화 하는 것이 굉장히 중요하다.

궁극적인 해결책은 소규모의 소프트웨어를 개발하는 것이다. 스택 전체를 다른 사람들과 파일을 공유하지 않는 Self Contained인 컴포넌트로 나누고, 추론하기 쉽게 극소수의 파일만 구성하는 것이 좋다.(ex. api, service, DAO, TEST...) 이것을 마이크로서비스라고들 부른다.

확장하려면 애플리케이션 전체를 확장해야한다!

MartinFowler.com 블로그 인용

단일암체 애플리케이션도 성공적일 수 있지만, 점점 더 많은 사람들이 불만을 느끼고 있다 - 특히 더 많은 애플리케이션들이 클라우드로 전개될수록. 변화 주기는 다 같이 묶여 있다 - 애플리케이션의 조그마한 부분을 바꾸면 단일암체 전체를 재건하고 재배치하여야 한다. 시간이 흐를수록 좋은 모듈식의 구조를 유지하는것이 힘들어지고, 모듈 하나에만 작용해야 할 변화가 그 모듈 이내에서만 작용하도록 하는것이 힘들어진다. 더 많은 자원을 필요로 하는 부분만 확장하는 것이 아니라, 확장하려면 애플리케이션 전체를 확장해야한다.

당신의 어플리케이션의 설계를 보면 어떤 감이 오는가?

uncle-bob 블로그 인용

...도서관 설계도를 보면, 아마도 커다란 입구, 체크인/체크아웃 구역, 독서실, 소규모 회의실들, 도서관의 모든 책을 수용할 수 있게 책꽂이들을 놓을 만한 공간들이 보일 것이다. 설계도를 보면 도서관이라고 바로 감이 올 것이다.

예시

<좋은예>

<나쁜예>

프로젝트 적용

현재 Express 서버의 경우 단지 Rest api 서버로 활용하고 있는 만큼 단순히 router, handler(controller) 2가지 레이어로 분류해이고, 위의 나쁜예와 유사하게 짜여져 있다. DB 의 경우 sql-server(RDBMS) 로 구성되어있고, DBA가 Stored-Procedure 를 제공해주는 만큼 따로 ORM, JPA 등을 사용하고 있지 않지만, scale-out 과 서버 기능 확장 가능성을 위 사례를 보고 조금 생각해봤다.

• Rest API
  현재와 동일하게 CRUD가 자주 발생하는 서버를 위해 Rest api 모듈로 분리시킨다. 포트의 경우 scale_out이 발생할 것을 대비해 NGINX와 같은 Web Server를 reserve proxy 로 두어 80포트만을 열어두는 것도 고려해볼 사항이라고 생각한다. 추가로 대기 queue를 추가하고, Select(반복) 을 대비한 Caching 기능을 추가하면 좋을 것으로 생각한다.
• Web Socket Streaming Server
  실시간으로 데이터를 전송하는 기능이 대비되어있다. NGINX 를 사용하면 웹 소켓을 사용할 수 없다고하니, 따로 포트를 열어두고 허가와 인증이 된 경우에(?) 브로드캐스팅으로 서로 정보를 조율하는 것이 방법일 것이라 생각한다. 문제는 중복 설비정보 변경은 어떻게 할지가 관건이다.
• Authorization & Authentication
  여러가지 방법들이 있지만 JWT를 이용하는 것이 가장 현실적인 것으로 보이고, 사내 방화벽이 존재하는 만큼 적당한 수준에서 사용하는 것이 좋을 것 같다. 흔히 말하는 오버엔지니어링에 해당하는 기능이다.