소프트웨어공학 설계
3학년 과목으로 객체지향 소프트웨어를 설계하고 구현까지 해가는 것이 수업의 기말과제 였다. 주제는 AI를 활용한 의료 통합 관리 서비스를 만드는 것이 주제였는데, 이는 교수님이 직접 지정해준 주제였다.
이에 대해 우리팀이 정한 주제는 사용자가 본인의 의료정보를 저장하면 그 누적된 의료정보를 바탕으로 LLM API를 통해서 사용자에게 건강 진단 및 추천되는 음식, 운동 예상되는 질병 등의 AI 닥터가 진단을 내려준다는 컨셉의 프로젝트를 진행하기로 하였다.
나의 역할을 프로젝트 리더 였고 그렇기 때문에 요구사항 분석을 진행해 보았다.
FR01~FR15 :로그인 / 회원가입 / CRUD 기능 : 일반적 웹 기능 이지만,
FR16~FR18 : LLM API 호출을 통한 요약 제공 : AI 응답 기능 이다.
즉 외부 API 호출로 이부분이 서비스에서 있어서 제일 메인 서비스이자 주요 서비스 병목으로 의심되었다.
일반 CRUD는 DB 커넥션 풀, slow query, Disk I/O 등이 고려 대상이지만, 일반 CRUD + LLM 의 호출의 경우 Thread & connection의 고갈, Network Latency가 고려대상이다. 이를 동시성 프로그래밍의 관점에서 접근했고, 생길 수 있는 문제에 대해서 분석해보고자 하였다.
기본적인 자원 예상이다. 2GB RAM의 인스턴스가 기준으로 잡은 것이다.
일반적인 CRUD 서비스 기준이다.
주 로직 수행 대상인 DB 가 물리적으로 가까우며 오랜 시간이 걸리지 않고 동기적 작업 수행이지만 스레드 반환이 빨라 작업처리에 병목이라 볼 수 없다.
반면, 외부 API 호출의 경우
해당 작업이 동기적으로 수행될 경우 외부 LLM의 API 응답이 돌아올 때까지 Tomcat의 스레드는 Blocking된다.
또한 외부 API 호출 프로세스의 경우 반드시 트랜잭션에서 분리되어야 한다.
DB 커넥션 점유를 막기 위해서이다.
때문에 비동기 스레드가 도입되어야 한다. 최초 개발 목표인 동시 사용자 200명 까지는 동기적으로 처리 가능하나, 빠른 출시 위해 동기적 처리로 선 출시 후
출시 기간동안 비동기 테스트 서버 개발.동시 접속자 평균 150명 돌파 이후,
즉각 비동기 외부 API 처리 기능 도입.수용가능 유저 500 % 향상 가능하다는 것이 나의 분석이었다.
(물리 서버 확장 이전에 반드시 도입)
여기시 리틀의 법칙이 나오게 되는데
: 시스템 내에 유지되어야 하는 동시 작업 수 (필요한 Async 스레드 개수)
: 목표 처리량 (초당 들어오는 LLM 분석 요청 수, TPS)
: 작업 하나당 걸리는 시간 (LLM 응답 대기 시간, 약 20초)
목표 초당 5건 처리 5x20 = 100, 100개의 Async 스레드 필요하게 된다.
평균 스레드 점유 지표 확인해야하니 Spring actuator 사용을 할 것이다.
주요 수집 지표(Metric)
tomcat.threads.busy : 현재 실제로 요청을 처리 중인 스레드 수
tomcat.threads.current : 현재 생성되어 있는 전체 스레드 수
tomcat.threads.config.max : 설정된 최대 스레드 수
tomcat.threads.config.min : 최소로 유지하는 유휴 스레드 수
이런 식으로 요구사항을 분석해보았다.
단순히 이 서비스를 구현하기 위해서는 ~~ 기능을 구현하고 서비스 시나리오를 생각하기 전에 엔지니어의 기준으로 요구사항을 먼저 분석해야함을 계속 생각하고 있다.
해당 문제는 JAVA의 가상 스레드가 나오면서 훨씬 덜 걱정될 문제가 되었지만 이런 식으로 계속 생각해보는 것이 중요하지 않을까 생각이든다.
