[MDD] 11주차 회고

개요

이번주차 부터 다시 인프라 작업에 들어갔다.

개발 서버 겸 데모를 위한 인프라를 구축함과 동시에 여기에 붙일 기본 컴포넌트 개발을 진행했다.

 

NFS보다 나은 방식은 없는가?

파일에 대한 I/O가 필수적으로 발생하는 것이 주요한 기능 중 하나다.

파일 서버를 NFS로 분리하면서 이 부분의 레이턴시가 걱정이다.

 

프로젝트 컴포넌트로 파일이 업로드 된 후, 업로드 완료 사실을 스캔 컴포넌트가 인지해야 한다.

여기서 다음과 같은 방식을 생각했다.

• DB 또는 캐시로 지속적으로 폴링
• MQ를 활용해 업로드 후 구독 컴포넌트로 업로드 사실을 알림

우선 DB 자체의 커넥션을 지속적으로 요청한다는 사실에서 DB를 이용하는 것은 큰 부담이라고 생각했다.

또한, Redis를 별도의 큐 시스템으로 지속적으로 캐시로 사용하고 있는 상황에서 계속 폴링을 거는 것 역시 캐시 시스템에 부하를 줄 수 있을 것 같았다.

 

그러므로 일전에 구축한 Redis Pub/Sub 기반으로 업로드 완료를 알리고자 했다.

 

하지만 아직 스스로 이 부분에 대한 타당성이 납득이 되지 않는다.

그래서 추후에는 이 부분에서 폴링의 부하와 비교-분석해볼 만하다고 생각한다.

 

그렇지만 근본적으로 컴포넌트가 분리되면서 파일을 관리할 볼륨 역시 분리됐다.

 

여기서 압축 파일과 그에 따른 하위 디렉토리를 함께 관리해야 하므로 오브젝트 스토리지는 적절하지 않다고 판단했다.

AWS의 EBS와 같이 추가적으로 마운트할 수 있는 스토리지 역시 고려했으나 이는 한번에 여러 인스턴스에 마운트할 수 없었다.

그래서 여러 인스턴스에 동시에 마운트 할 수 있는 NFS를 사용하기로 결정했다.

 

동일 리전의 네트워크 내에서 NFS를 사용해서 최대한 네트워크 레이턴시를 줄이고는 싶었으나 어쩔 수 없이 물리적인 한계가 존재하는 것은 인정해야 했다.

 

기존 모놀리식 방식에서 도커 볼륨과 같은 방식이 이 부분은 어느정도 해소할 수는 있다고 생각하지만 근본적으로 호스트 시스템의 I/O를 공유하는 것이 또 고민이었다.

 

이런 부분이 트레이드 오프지 않을까 싶다.

 

공통 모듈을 분리하자.

개발을 진행하면서 느낀 점은 분명 공통 모듈로 분리해서 참조할 수 있는 부분이 존재한다는 것이었다.

현재 Gradle로 여러 모듈과 패키지를 관리하면서 Common 패키지를 분리하는게 좋겠다는 판단을 했다.

 

에러 코드나 리스폰스 클래스와 같은 부분부터 DB/Redis 접근을 위한 Repository와 Redis 관련 설정까지 한번에 이관하고자 한다.

여기서 DB 엔터티 클래스를 어떻게 관리할지 고민이다.

 

인증과 같은 부분, 거기서 발생하는 DB 커넥션 등 여러 컴포넌트에서 엔터티를 공유할 수 있음에도 이를 공통 모듈까지 가져가야하나 싶기는 하다.

프로젝트 사이클의 속도

지난 주 팀원에게 휴식과 책임을 함께 부여했다. 나 역시 휴식을 갖고 프로젝트를 한번 정리하고자 했다.

이 부분이 성공적일지는 모르겠지만 당장 팀원의 개발 속도 역시 올라왔다.

 

나 역시 PM을 담당하면서 새롭게 배우는 점이 또 있기는 하다.

회고

본격적으로 인프라 작업에 돌입했다. 이제 진짜 데모가 나올 차례다.

물론 인프라 이후 파이프라인과 통합 후 에러 잡는 문제까지 모두 처리해야 하지만 일차적인 모습이 나올 것 같아서 좋다.