한 금융 서비스 기업이 신뢰할 수 있는 AI 데이터 전송을 보장합니다

유럽의 한 선도적인 자산운용사는 객체 스토리지만으로는 AI 워크로드의 동시 처리 요구를 감당할 수 없다는 사실을 뼈아픈 경험을 통해 깨달았습니다. 클라이언트의 잘못된 구성으로 서비스 거부 이벤트가 발생한 후, 이 회사는 AI 모델 학습을 위한 안정적이고 확장 가능하며 고성능인 S3 데이터 전송을 보장하기 위해 F5 솔루션을 도입했습니다.

과제

금융 서비스 및 부동산 분야에서 탄탄한 입지를 구축한 한 유럽 자산운용사는 AI에 대규모 투자를 하고 있습니다. 이 회사의 데이터 과학 팀은 S3 호환 오브젝트 스토리지인 Dell Elastic Cloud Storage(ECS)에 저장된 대규모 데이터 세트로 모델을 학습하며, AI 워크로드는 Kubernetes에서 실행됩니다. 문제는 이러한 워크로드와 스토리지를 연결하는 경로에 있었습니다.

오브젝트 스토리지 플랫폼은 트래픽을 제어하기보다 용량을 확장하도록 설계됩니다. 수십 년 동안 애플리케이션은 통제된 네트워크에서 전용 프로토콜을 통해 스토리지에 연결되었기 때문에 파일러나 스토리지 어레이 앞단에서 트래픽을 관리할 필요가 없었습니다. 하지만 S3 스토리지가 이를 바꾸었습니다. 이제 키를 보유한 모든 클라이언트가 HTTP를 통해 오브젝트 스토리지에 액세스할 수 있습니다. 즉, 스토리지 프런트엔드는 웹 서비스처럼 작동하며 동일한 방식으로 장애가 발생할 수 있습니다. 개별 스토리지 노드가 처리할 수 있는 동시 TCP 연결 수에는 현실적인 한계가 있습니다. AI 파이프라인이 학습 데이터를 가져오기 위해 수천 개의 병렬 세션을 열면 이러한 한계에 빠르게 도달할 수 있지만, 스토리지 팀이 문제를 사전에 감지하는 경우는 드뭅니다.

이 금융 서비스 회사에서는 잘못 구성된 클라이언트가 오리진이 처리할 수 있는 수준보다 더 많은 동시 연결을 생성해, 사실상 자사 스토리지에 서비스 거부 상태를 초래했습니다. 그 결과 AI 데이터 수집이 중단되었습니다.

이 사고를 통해 인프라 및 스토리지 팀은 두 가지 사실을 분명히 깨달았습니다.

첫째, 단 하나의 비정상 클라이언트로 인해 공유 데이터 플랫폼 전체가 중단되는 일은 절대 없어야 합니다. 특히 금융 서비스 분야에서 안정성은 선택 사항이 아닙니다. 모델 학습 일정, 분석, 그리고 그에 따른 비즈니스 의사 결정은 모두 데이터 플랫폼이 지속적으로 운영되는 데 달려 있습니다.

둘째, 증가하는 AI 이니셔티브를 지원하기 위해 ECS 노드를 추가하려는 회사의 계획을 고려하면 문제는 더욱 심화될 수밖에 없었습니다. 앞으로 나아가려면 스토리지 경계에서 엔지니어링 원칙을 엄격히 적용하고, S3 트래픽이 스토리지 노드에 도달하기 전에 이를 조정하고 균형 있게 분산하며 보호할 수 있는 제어 지점이 필요했습니다.

솔루션

이 회사는 HAProxy와 Kemp Technologies의 옵션을 비롯한 여러 잠재적 솔루션을 평가했지만, S3 프로토콜에 특화된 애플리케이션 전송 기능이 제한적이라고 판단했습니다.

초기 가치 검증 시연은 결정적인 역할을 했습니다. 이를 통해 F5 솔루션이 ECS와 원활하게 통합되는 동시에 세션 지속성과 같은 S3 프로토콜 관련 과제를 처리할 수 있음을 입증했습니다. 해당 기업과 F5 모두의 기술 파트너인 Dell은 F5 솔루션을 ECS 인프라에 맞게 조정하고 공동 아키텍처를 적극적으로 제안함으로써 중추적인 역할을 수행했습니다.

결국 이 금융 서비스 기업은 F5를 선택하고, BIG-IP Local Traffic Manager (LTM)를 실행하는 F5 rSeries r5600 어플라이언스 4대를 ECS 스토리지 전용 딜리버리 계층으로 구축했습니다.

검증된 참조 설계에 따라 구축함으로써 위험을 줄이고, AI 환경이 성숙해짐에 따라 나아갈 로드맵을 마련했습니다. 그 결과 구현된 이중 데이터 센터 기반의 액티브/액티브 아키텍처는 의도적으로 단순하게 설계되었습니다. 동적 라우팅 메커니즘을 활용하여 DNS에 의존하지 않고도 수평 확장과 고가용성을 제공합니다. 이제 Kubernetes에서 호스팅되는 AI 워크로드의 모든 S3 요청은 스토리지에 도달하기 전에 BIG-IP LTM을 거칩니다. 이 단일 설계 결정으로 기존 장애 원인을 해결하고 성장의 기반을 마련했습니다.

결과

연결 풀링은 동시성 문제를 직접 해결하므로 이 프로젝트의 계기가 된 장애가 다시 발생하지 않습니다. BIG-IP-LTM은 클라이언트 측 TCP 연결의 폭증을 관리하고, 이를 ECS 노드에 대한 더 적고 통제된 서버 측 연결 집합으로 조정합니다. 또한 연결 규칙을 적용하여 잘못 구성되었거나 과도하게 요청하는 단일 클라이언트가 더 이상 스토리지 노드의 리소스를 고갈시키지 못하도록 합니다. 한 클라이언트가 비정상적으로 동작하더라도 모든 팀이 ECS 플랫폼을 계속 사용할 수 있습니다.

측정 가능한 성능 향상 제공

일관된 URL 해싱을 통해 요청이 무작위가 아닌 지능적인 방식으로 분산됩니다. 동일한 객체에 대한 요청은 ECS 클러스터 전반에 걸쳐 예측 가능한 방식으로 전달되므로 캐시 활용률이 향상되고 핫스팟이 방지되며, 스토리지 노드가 추가되어도 처리량이 안정적으로 유지됩니다.

또한 Mongoose 스토리지 성능 테스트 도구를 사용한 내부 성능 테스트 결과, 데이터 경로에 F5 솔루션을 구현한 후 처리된 입출력 성능이 500% 향상된 것으로 나타났습니다. TCP 연결을 최적화하고 서버 측 요청을 다중화하며 동적 라우팅을 활용함으로써, 이 플랫폼은 높은 성능이 요구되는 AI 워크로드의 처리량을 즉각적으로 개선했습니다.

아키텍처 재설계 없이 AI 이니셔티브 확장

이 회사는 AI 도입 확대에 따라 ECS 환경을 확장할 계획입니다. BIG-IP LTM은 단일 가상 주소 뒤에 스토리지 엔드포인트를 추상화하므로, 애플리케이션 구성을 변경하거나 워크로드를 중단하지 않고도 노드를 추가하여 ECS 환경을 확장할 수 있습니다. 이처럼 안정성 문제를 해결한 아키텍처는 향후 성장도 지원합니다.

스토리지를 체계적으로 설계된 서비스로 전환

스토리지 앞단에 전용 애플리케이션 전송 계층을 배치하면 우수한 엔지니어링 관행을 구현할 수 있습니다. 클라이언트가 노드에 직접 접근하는 관리되지 않는 긴밀한 결합 구조 대신, 한곳에서 트래픽을 관찰하고 분산하며 제어할 수 있습니다. 스토리지 아키텍트에게는 예측 가능한 노드 동작과 체계적인 용량 계획을 의미합니다. CIO에게는 AI 데이터 플랫폼이 지점 간 연결을 단순히 모아 놓은 것이 아니라 정교하게 설계된 시스템임을 의미합니다.

AI 데이터 전송 파트너십을 기반으로 구축

F5와 Dell은 바로 이러한 유형의 워크로드를 위해 지속적으로 공동 엔지니어링을 진행하며, AI 파이프라인을 위한 BIG-IP LTM 트래픽 관리와 S3 호환 오브젝트 스토리지를 결합하고 있습니다. 다른 기업이 얻을 수 있는 교훈은 S3 오브젝트 스토리지가 웹 서비스이며, AI 워크로드가 다른 웹 서비스와 마찬가지로 여기에 큰 부하를 준다는 점입니다. 스토리지 앞단에 전용 애플리케이션 전송 컨트롤러를 배치하면 외부에 노출된 오리진을 효과적인 AI 구현에 필요한 복원력 높은 데이터 파이프라인으로 전환할 수 있습니다.