.svg)
AI 솔루션 문의하기
많은 기업들이 AI 프로젝트를 시작할 때 모델 개발에만 집중하는 경향이 있습니다. 그러나 실제 서비스 운영 환경은 개발 환경과 완전히 다릅니다. 개발 환경에서는 작은 규모의 데이터로 실험하지만 운영 환경에서는 수백만 건의 거래를 동시에 처리해야 합니다.
또한 개발 단계에서는 모델을 한 번 학습하고 배포하면 되지만 운영 환경에서는 지속적으로 모델을 업데이트해야 합니다. 새로운 데이터 패턴이 나타날 때마다 모델을 재학습하고 배포해야 하는데 이 과정에서 기존 서비스를 중단하지 않으면서도 안정적으로 새로운 모델로 전환해야 합니다.
기업의 AI 시스템은 다양한 보안 위협에 노출됩니다. 악의적인 입력으로 모델을 공격할 수 있고 모델의 학습 데이터를 탈취하려고 할 수도 있습니다. 금융 거래 같은 민감한 영역에서는 높은 수준의 보안과 규제 준수가 필수입니다.
따라서 기업이 AI를 안정적으로 운영하려면 단순히 좋은 모델을 개발하는 것을 넘어 전체적인 인프라를 체계적으로 구축해야 합니다.
모든 기능이 하나의 거대한 응용프로그램으로 구성됩니다. 이 구조에서는 모델을 업데이트하려면 전체 시스템을 재시작해야 하므로 서비스 중단이 불가피합니다.
각 기능이 독립적인 작은 서비스로 분리됩니다. 예를 들어 사기 탐지 모델, 고객 신용도 평가 모델, 거래 위험 평가 모델이 각각 독립적인 서비스로 작동합니다. 이렇게 하면 한 모델을 업데이트해도 다른 모델은 계속 작동할 수 있습니다.
마이크로서비스 구조는 또한 확장성(scalability)을 제공합니다. 특정 모델에 대한 요청이 많아지면 그 모델만 실행하는 서버를 더 추가할 수 있습니다. 반면 모놀리식 구조에서는 전체 시스템을 확장해야 하므로 비효율적이고 비용이 많이 듭니다.
또한 마이크로서비스는 팀의 독립적 작업을 용이하게 합니다. 각 팀이 자신의 모델 서비스를 독립적으로 개발하고 배포할 수 있으므로 팀 간 의존성이 줄어들고 개발 속도가 빨라집니다.
마이크로서비스 구조에서 수십 개 또는 수백 개의 서비스를 관리하려면 각 서비스를 표준화된 방식으로 패키징하고 배포해야 합니다. 이를 위해 컨테이너 기술(Docker)이 사용됩니다.
컨테이너는 애플리케이션, 라이브러리, 필요한 모든 의존성을 하나의 패키지로 묶은 것입니다. 개발자가 자신의 로컬 환경에서 컨테이너로 만든 애플리케이션은 어느 운영 환경에서나 동일하게 작동합니다. 따라서 "개발 환경에서는 잘 작동하는데 운영 환경에서 오류가 난다"는 문제가 해결됩니다.
수십 개의 컨테이너를 수동으로 관리하기는 어려우므로 오케스트레이션 도구(Kubernetes 등)를 사용합니다. 오케스트레이션 도구는 다음과 같은 작업을 자동으로 수행합니다. 컨테이너를 여러 서버에 배포하고 요청량에 따라 자동으로 서버를 추가하거나 제거하며 장애가 발생한 컨테이너를 자동으로 재시작하고 배포된 컨테이너의 상태를 지속적으로 모니터링합니다.
오케스트레이션은 운영 복잡성을 크게 줄이면서도 시스템의 안정성을 높입니다.
마이크로서비스가 많아지면 클라이언트가 각 서비스의 주소와 프로토콜을 일일이 알아야 합니다. 이는 클라이언트를 복잡하게 만들고 서비스 추가나 변경이 어려워집니다.
API 게이트웨이는 모든 클라이언트 요청의 단일 진입점(single entry point)이 되는 서비스입니다. 클라이언트는 게이트웨이에만 요청하고 게이트웨이가 각 요청을 적절한 마이크로서비스로 라우팅합니다.
API 게이트웨이는 여러 부가 기능도 제공합니다. 인증과 인가(누가 어떤 서비스를 사용할 수 있는가)를 중앙에서 관리할 수 있고, 요청 속도 제한(rate limiting)으로 한 사용자가 과도하게 많은 요청을 보내는 것을 방지할 수 있습니다. 또한 요청과 응답을 로깅하여 모든 거래의 감시 추적을 자동으로 수행합니다.
API 게이트웨이를 통한 통합은 시스템의 일관성을 유지하면서 각 마이크로서비스는 독립적으로 발전할 수 있게 합니다.
기존 중앙집중식 데이터베이스에서는 모든 데이터가 하나의 서버에 저장됩니다. 트래픽이 증가하면 이 중앙 서버가 병목이 되어 전체 시스템이 느려집니다.
분산 데이터 아키텍처에서는 데이터가 여러 서버에 분산 저장됩니다. 각 마이크로서비스가 필요한 데이터를 자신의 데이터 저장소에 가지고 있으므로 중앙 데이터베이스에 대한 의존성이 줄어듭니다.
또한 서로 다른 유형의 데이터 저장소를 용도에 맞게 선택할 수 있습니다. 거래 기록처럼 구조화된 데이터는 관계형 데이터베이스에, 비구조화된 텍스트나 이미지 데이터는 문서 저장소나 객체 저장소에 저장합니다. 각 저장소가 자신의 용도에 최적화되어 있으므로 전체 시스템의 성능이 향상됩니다.
그러나 분산 구조는 데이터 일관성을 보장하기 어렵다는 단점이 있습니다. 여러 서버의 데이터가 동기화되지 않을 수 있기 때문입니다. 따라서 최종 일관성(eventual consistency) 원칙을 받아들이고 일시적으로 데이터가 불일치할 수 있지만 결국에는 모든 서버의 데이터가 일치하도록 설계합니다.
거래가 발생하는 순간 즉시 사기 탐지 모델에 데이터를 보내야 하므로 실시간 데이터 처리 파이프라인이 필수적입니다.
메시지 큐(message queue) 시스템은 데이터 생성 시스템과 데이터 처리 시스템 사이에 버퍼 역할을 합니다. 거래 데이터가 발생하면 먼저 메시지 큐에 저장되고 처리 시스템이 큐에서 데이터를 가져가 처리합니다. 이러한 구조는 데이터 생성 시스템의 부하 변동으로부터 처리 시스템을 보호합니다.
스트림 처리 엔진은 들어오는 데이터를 연속으로 처리합니다. 각 거래가 도착하면 즉시 여러 모델에 입력으로 주어지고 실시간으로 사기 여부, 위험도 등이 평가됩니다.
또한 배치 처리도 필요합니다. 실시간 처리는 즉각적인 응답이 필요한 거래에 사용되고 일일 통계 분석이나 모델 성능 평가 같은 작업은 배치 처리로 수행합니다. 실시간과 배치 처리를 함께 사용하면 즉시성과 효율성을 동시에 달성할 수 있습니다.
분산 시스템에서는 각 서버의 로그와 모니터링 데이터가 분산되어 있어 전체 시스템 상태를 파악하기 어렵습니다.
중앙화된 로깅 시스템은 모든 서비스의 로그를 하나의 중앙 저장소로 수집합니다. 개발자나 운영자는 중앙 저장소에서 로그를 검색하여 문제를 빠르게 진단할 수 있습니다. 중앙화된 모니터링은 각 서비스의 성능 지표(응답 시간, 오류율, CPU 사용률 등)를 실시간으로 수집하고 시각화합니다. 만약 특정 서비스의 오류율이 갑자기 증가하면 시스템이 자동으로 경고를 발생시킵니다.
또한 분산 추적(distributed tracing) 기능도 중요합니다. 하나의 거래 요청이 여러 마이크로서비스를 거치면서 어디서 지연되는지를 한눈에 볼 수 있어야 성능 병목을 파악할 수 있습니다.
.svg)
.svg)
