ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Pipe & Filter 아키텍처로 인공지능 데이터 캐싱 시스템 구축하기
    Project/OpenList 2024. 9. 25. 19:56
    반응형

    안녕하세요, Openlist 팀의 백엔드 기술에 관심을 가져주셔서 감사합니다! 🚀

     

    오늘은 복잡하지만 매력적인 Pipe & Filter 아키텍처와 이를 적용한 서버 인스턴스 분리 방식에 대해 이야기해 보려고 합니다. 이 구조는 각각의 서비스가 독립적으로 작동하면서도 서로 연결되어 있는 형태를 취하는데요.

     

    먼저, 우리 팀이 가지고 있던 문제점에 대해서 알려드리겠습니다.

    배경

    서버 측에서는 앱으로부터 지정된 엔드포인트로 요청이 오면, 요청에 포함된 데이터를 가지고 네이버의 생성형 인공지능인 CLOVA Studio API에게 데이터 생성을 요청하고 받은 데이터를 파싱해서 다시 앱 쪽으로 응답을 쏘는 구조였어요.

     

    Openlist 팀의 서버에서 어떻게 CLOVA Studio API 키를 발급받아서 연동했는지는 아래 포스트를 참고해 주세요!

     

     NestJS 서비스에서 CLOVA Studio API 연동 

    고민

    요청 100번으로 테스트해보니 평균적으로 6.3초의 시간이 소요됨.

     

    문제점은 바로 CLOVA Studio에서 데이터를 생성하는 데 걸리는 시간이었습니다. 너무 오래 걸린다는 거죠.

     

    요청 100번으로 테스트해 보니 평균적으로 6.3초의 시간이 소요되더라고요. 😱

     

    저를 포함한 우리 팀 백엔드 개발자들이 6주라는 짧은 시간 안에 인공지능 모델을 최적화시켜 API의 응답 시간을 줄이기엔 너무 촉박했습니다. 그래서 다른 방법을 모색했죠.

    해결

    • 서버에서 미리 모든 카테고리별 인공지능 데이터를 캐싱해 놓기
    • 그리고 지속적으로 피드백을 받아 인공지능 데이터에 순위를 매겨 사용자에게 양질의 데이터만 응답해 주기

    여기서, 지속적인 피드백 방식에 대해서 좀 더 고민했습니다.🤔

     

    하나의 인공지능이 아니라 여러 개의 인공지능을 경쟁시키면 어떨까? 라는 아이디어로 구조를 설계하기 시작했고, 지속적인 피드백이라고 하면 앱에서 추천한 인공지능 항목을 사용자가 선택하는 행위도 포함되어야 한다고 생각했습니다. 그렇다면 앱과 항상 통신하면서 순위를 업데이트해야겠죠.

     

    정리

    1. 우리는 여러 개의 인공지능을 통해 데이터를 생성하고 평가하는 작업을 나누어야 합니다.
    2. 그리고 그 작업은 메인 서버와 동시에 이루어질 수도 있어야 합니다.
    3. 그렇지만, 우리의 메인 서버는 동시 편집을 위한 웹소켓도 동작하고 있기 때문에 캐싱으로 인해 성능에 영향을 주어서는 안 됩니다.
    이 모든 것을 고려해,

    Pipe & Filter 아키텍처를 활용해 생성 서버와 평가 서버 인스턴스를 따로 생성하고, 각각 서버를 돌리며 메인 DB에 데이터를 연동하고, 메시지 브로커 시스템인 Redis pub/sub 구조를 활용해 서버를 연결하는 구조를 설계했습니다.

     

    구조도는 아래와 같습니다.

     

    구조를 이해하기 위해, 먼저 Pipe & Filter 구조가 뭔지 짚고 넘어가겠습니다.

     


     

    Pipe & Filter 구조란? 🤔

     

    'Pipe & Filter'는 서버의 데이터 처리 과정을 여러 단계로 나누어 각 단계에서 데이터를 처리하고 다음 단계로 전달하는 구조를 말합니다. 예를 들어, 로깅, 유효성 검증, 캐싱 등의 작업을 각각 독립된 필터로 만들어 이들을 연결하는 것이죠. 각 필터는 필요할 때 다른 필터를 호출할 수 있으며, 이렇게 필터들이 연결된 체인을 만듭니다.

     

    왜 서버를 두 개나 사용할까요? 🖥️

    여기서 흥미로운 질문이 생깁니다. 왜 하나의 서버로 처리하지 않고 두 개의 서버 인스턴스를 사용하는 걸까요? 이는 각 서버가 독립된 역할을 수행하기 위함입니다.

     

    1️⃣ 첫 번째 서버 인스턴스: GPT를 활용한 데이터 생성

    • 역할: 체크리스트 항목 생성
    • 작업: GPT-4 모델을 통해 체크리스트 항목을 생성하고, 이를 필터링하여 유효한 데이터만을 추출합니다.
    • 저장: 추출된 데이터는 데이터베이스에 저장됩니다.

    2️⃣ 두 번째 서버 인스턴스: Clova Studio AI를 활용한 데이터 평가

    • 역할: 체크리스트 항목 평가
    • 작업: Clova Studio API를 통해 항목을 평가하고, 평가 결과를 점수화하고, 이를 기반으로 리스트를 정렬합니다. 최종적으로 이 데이터는 API를 통해 사용자에게 제공됩니다.

     

    체이닝 구조와 그 구현 🔄

    체이닝 구조는 각 인스턴스 간의 작업을 연결하는 방식입니다. 여기서는 메시지 큐나 이벤트 버스를 사용해 각 인스턴스 간 비동기 통신을 구현할 수 있습니다. 서비스 오케스트레이션을 통해 각 인스턴스의 작업을 조율하거나 RESTful API를 통해 체이닝을 구성할 수도 있죠.

     

    고려해야 할 점들 💡

    이러한 구조를 구현할 때는 분산 트랜잭션 관리, 확장성, 모니터링 및 로깅, 보안 등 여러 요소들을 고려해야 합니다. 특히, 데이터의 보안과 각 단계에서의 오류 처리에 신경을 썼어요.

     

    AI 생성 서버와 AI 평가 서버는 어떻게 NCP에서 인스턴스를 만들고, 코드를 구현했는지 아래 포스팅에 자세히 작성해 두었습니다.

    그리고 물론, 이 모든 과정은 사용자에게 최상의 서비스를 제공하기 위한 것이죠. 이러한 기술적 결정들이 어떻게 실제 서비스에 영향을 미치는지 생각해보는 것은 항상 흥미로운 일입니다. 여러분의 피드백도 기다리고 있겠습니다! 💬🌟

     

    이상으로 'Pipe & Filter' 구조와 서버 인스턴스 분리 방식에 대한 이야기를 마치며, 이 글이 여러분의 프로젝트에 도움이 되기를 바랍니다. 기술은 항상 발전하고 있으니, 더 나은 방법이 있다면 언제든 공유해 주세요! 🌈👩‍💻👨‍💻

     

     

    반응형
Designed by Tistory.