brunch

You can make anything
by writing

C.S.Lewis

by 디이프 May 30. 2023

[Resource] 디이프의 자원관리 경험 공유

EDITOR'S NOTE

현재 디이프에서는 다양한 헬스케어 데이터를 식품 데이터와 의미론적으로 연결하는 여러 기술과 데이터 모델링 기술, 데이터베이스를 보유하고 있으며 이를 기반으로 맞춤형 식품추천 서비스를 개발하며, 동시에 위와 같은 필수 자원들을 지속적으로 업데이트해나가고 있습니다.


이 자원을 효율적으로 사용하기 위한 방안으로 설계된 디이프의 Pantry 프로젝트에 대해 조하영 개발자가 프로젝트 관리 경험을 공유해드리도록 하겠습니다. 




앞서 말씀드린 것처럼, 현재 개발된 서비스와 개발 중인 기능에는 위와 같은 자원이 계속해서 사용되고 있습니다. 각각 고유한 기능과 특성이 있기 때문에, 여러 서버에 분배되어 존재하고 있는데요, 이는 곧 개발자들과 데이터 분석가들이 기능을 개발하거나 업데이트하는 과정에서 각 서버에 직접 접근해야 하는 번거로움을 만들었습니다. 이에 따라, 지금까지 만들어진 내부 기술과 데이터를 하나의 서버상에서 접근 및 사용 가능한 방법을 고민하게 되었고, 전체 리소스에 접근 가능한 API를 관리하는 지금의 Pantry 프로젝트를 설계하게 되었습니다.


I. Why Pantry?

왜 프로젝트명을 굳이 “Pantry”라고 지었을까요? Pantry는 보통 부엌 옆이나 근처에 위치해 식품이나 음식, 조리 도구 등을 보관하는 장소를 칭합니다. 엉뚱한 단어를 사용한 것처럼 느껴지시겠지만, 이는 현재 디이프가 가진 자원의 전체적인 특성을 잘 반영하고 있습니다. 식품과 음식에 관련한 다양한 데이터베이스가 Pantry 프로젝트 내에 연결된 상태로 존재하고, 조리 도구 역할을 하는 처리기술을 Pantry를 통해 접근하게 될 테니까요.  


따라서 이러한 Pantry 프로젝트는 현재까지 크게 3가지 역할의 API를 만들었습니다. 


1. 다양한 기준으로 데이터베이스를 조회하는 API

2. 서비스 알고리즘의 입출력을 테스트하는 API

3. 데이터를 전처리하는 API


이 3가지의 API를 우선으로 만든 상태이며, 계속해서 실무자들에게 필요한 API를 추가해나가고 있습니다.


II. Pantry의 구성 및 구조

위와 같은 역할의 API를 만들기 위해서 디이프에서는 python 기반으로 API를 만들 수 있는 FastAPI를 사용하였습니다. 여러 서버의 데이터베이스와 알고리즘 동작에 의존적인 설정을 만들 수 있어야 했고, API에 대한 요구사항을 빠르게 반영하기 위해 개발 속도와 성능 측면에서 탁월하다고 알려진 FastAPI를 적용하게 되었죠. 따라서 아래와 같은 아키텍처에 기반하여 하나의 FastAPI 동작 안에 여러 서버와 기능에 접근하는 API를 구성하게 되었습니다.


하지만 위와 같은 구조의 동작은 단점이 있었습니다. 바로 중앙집중식 형태로 동작하게 된다는 점입니다. 하나의 서버를 기반으로 여러 기능과 데이터를 관리하는 것은 관리자 입장에서 매우 편리하고 단순하며, 자원을 일관성 있게 처리할 수 있다는 장점이 있습니다. 하지만, 하나의 서버에 의존적인 만큼, 해당 서버에 장애가 발생하면 전체 시스템이 영향을 받는다는 단점이 있습니다. 따라서 Pantry도 하나의 서버로 운영 시, 특정 API의 오류가 다른 프로젝트의 API 동작에 영향을 주게 된다는 점과 각 API 구동이 Pantry 프로젝트 서버에 의존적인 문제를 확인할 수 있었습니다.



III. 향후 Pantry는?

따라서 현재와 같은 구조는 앞으로 관리해야 할 프로젝트와 데이터가 지속적으로 추가되는 데에 적합하지 않다는 점을 고려해, 이를 보완한 마이크로서비스식의 구성을 계획하게 되었습니다. 마이크로서비스란 하나의 애플리케이션을 독립적으로 수행 가능한 기능 단위로 분할하여 서비스화하는 방식으로, 분리된 서비스는 다른 서비스에 영향을 주지 않고 개별적으로 확장과 배포가 가능한 구조입니다.


따라서, 서버에 접근해 기능과 데이터를 사용하였던 기존의 API 동작을 각 서버 단에서 처리하도록 서비스화한 뒤, 기존 Pantry 서버에서 라우팅하는 방식을 적용해, API 동작의 독립성 부여와 서버 간의 영향 최소화를 목표하고 있습니다. 또한 이렇게 분산된 서비스를 보다 단순하게 관리하기 위한 Docker Swarm과 같은 오케스트레이션 도구의 도입 또한 고려하고 있습니다.



IV. 앞으로

지금까지 디이프의 자원 관리 방식 중 하나인 Pantry 프로젝트에 대해 간단하게 말씀드렸지만, 아직 찾지 못한 더 나은 관리 방식이 있으리라 생각합니다. 따라서 디이프는 앞으로도 지속적인 의논과 평가를 반복하여 요구사항에 가장 적절한 방안을 계속해서 찾아낼 것이고, 이를 통해 내부 기술과 서비스 개발체계를 견고하게 만들어 나갈 예정입니다.



Reference

https://freeend.tistory.com/115

https://velog.io/@jkim2791/Micro-Service-ArchitectureMSA-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90%EB%9E%80


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari