바자 보이스

레거시 시스템 현대화에 관한 이 기사는 제가 최근 소프트웨어 회사를 위한 AWS Data Summit에서 기계 학습 프로젝트의 성공을 보장하기 위해 모범 사례를 활용하여 데이터에서 가치를 창출하는 방법에 대해 발표한 내용의 보조 자료입니다. 원하는 경우 여기 맨 아래로 바로 이동하여 시청할 수 있습니다.

현실을 직시하자: 소프트웨어는 유지 관리하는 것보다 작성하기가 더 쉽습니다. 이것이 바로 우리가 소프트웨어 엔지니어로서 다른 개발자(또는 과거의 자신)가 생각하고 있는 것을 이해하려고 노력하는 대신 그냥 "찢고 다시 시작"하는 것을 선호하는 이유입니다. 우리는 "프로그램은 사람이 읽을 수 있도록 작성되어야 하며, 기계가 실행할 수 있도록 작성되어야 한다"는 사실을 집단적으로 잊어버린 것 같습니다.

당신도 그것이 사실이라는 것을 알고 있습니다. 우리 모두는 프로그램의 핵심을 찾기 위해 스파게티 코드와 얇은 구식 추상화의 캐서롤을 힘들게 추적해야 했지만 접시 바닥에서 엉망진창만 발견했습니다.

"WTF"라고 외치고 이전 개발자를 비난하기는 쉽지만 진실은 더 복잡한 경우가 많습니다. 우리는 미래를 볼 수 없기 때문에 완전히 새로운 시스템을 설계할 때 요구 사항, 기술 또는 비즈니스 목표가 어떻게 성장할지 이해하는 것이 불가능합니다. 결과적으로 시스템에 대한 비즈니스의 의존도와 함께 범위가 증가함에 따라 시스템을 읽을 수 없게 될 수 있습니다. 이는 다소 역설적입니다. 오래되고 유지 관리가 어려운 시스템이 종종 가장 큰 가치를 제공합니다. 회사와 함께 성장했기 때문에 작업하기가 힘들고, 이를 깨뜨리면 재앙이 될 수 있기 때문에 작업하기가 두렵습니다.

여기 제가 여러분을 부르고 있습니다. 어렵고 보람 있는 문제를 좋아한다면… 시도해 보세요. 가지고 있는 가장 오래된 시스템을 유지 관리할 수 있도록 만드세요. 내가 말하는 것, 즉 누구도 "소유"하지 않을 것입니다. 다른 부서에서는 의존하지만 엔지니어들은 싫어하는 것입니다. 먼저 Log4Shell을 패치해야 했던 것입니다. 해. 감히.

나는 최근 Bazaarvoice에서 10년 된 기계 학습 시스템을 업데이트할 기회를 얻었습니다. 표면적으로는 흥미롭지 않게 들렸습니다. 이 제품에는 신경망도 없었습니다! 무슨 상관이야! 음… 그게 중요했어요. 이 시스템은 Bazaarvoice가 받은 거의 모든 사용자 생성 제품 리뷰(월당 거의 900만 건)를 처리하며 기계 학습 모델에 대한 9천만 건의 추론 호출을 통해 이를 수행합니다. 그렇습니다. 9천만 개의 추론이 이루어졌습니다! 규모가 엄청나서, 뛰어들고 싶을 정도였습니다.

이 게시물에서는 재작성 대신 재아키텍처를 통해 이 레거시 시스템을 현대화함으로써 모든 코드를 제거하고 다시 시작하지 않고도 시스템을 확장 가능하고 비용 효율적으로 만들 수 있었던 방법을 공유하겠습니다. 결과 시스템은 서버리스, 컨테이너화 및 유지 관리가 가능하며 호스팅 비용을 거의 80% 절감합니다.

레거시 시스템이란 무엇입니까?

레거시 시스템은 작동 중인 노후화된 컴퓨팅 소프트웨어 및/또는 하드웨어를 의미합니다. 여전히 원래 목적을 달성할 수는 있지만 향후 성장을 위한 확장성은 부족합니다.

오래된 레거시 시스템

먼저, 여기서 우리가 다루고 있는 내용을 살펴보겠습니다. 우리 팀이 업데이트하고 있던 레거시 시스템은 모든 Bazaarvoice에 대한 사용자 생성 콘텐츠를 조정했습니다. 특히 각 콘텐츠가 고객의 웹사이트에 적합한지 여부를 결정합니다.

이는 증오심 표현, 상스러운 언어 또는 권유와 같은 명백한 위반 사항을 제거하여 간단하게 들리지만 실제로는 훨씬 더 미묘합니다. 각 고객은 적절하다고 생각하는 고유한 요구 사항을 가지고 있습니다. 예를 들어, 맥주 브랜드는 술에 대한 논의를 기대하지만 어린이용 브랜드는 그렇지 않을 수도 있습니다. 새로운 클라이언트를 등록할 때 이러한 클라이언트별 옵션을 캡처하고 클라이언트 서비스 팀이 이를 관리 데이터베이스에 인코딩합니다.

약간의 복잡성을 더하기 위해 인간 중재자가 중재할 콘텐츠의 하위 집합도 샘플링합니다. 이를 통해 우리는 모델의 성능을 지속적으로 측정하고 더 많은 모델을 구축할 수 있는 기회를 발견할 수 있습니다.

레거시 시스템의 전체 아키텍처는 다음과 같습니다.

이 시스템에는 몇 가지 심각한 단점이 있습니다. 특히 모든 모델은 단일 EC2 인스턴스에서 호스팅됩니다. 이는 잘못된 엔지니어링 때문이 아니라 원래 프로그래머가 회사가 원하는 규모를 예측할 수 없었기 때문이었습니다. 그 누구도 이만큼 성장할 것이라고는 생각하지 못했습니다.

게다가 이 시스템은 개발자의 거부로 어려움을 겪었습니다. Scala로 작성되었기 때문에 이를 이해하는 엔지니어는 거의 없었습니다. 따라서 아무도 만지려고 하지 않았기 때문에 개선이 간과되는 경우가 많았습니다.

그 결과, 시스템은 계속해서 가동되는 방식으로 성장했습니다. 재설계를 해보니 단일 x1e.8xlarge 인스턴스에서 실행되고 있었습니다. 이 제품에는 거의 테라바이트에 달하는 RAM이 있고 작동 비용은 월 $5,000(예약되지 않음) 정도입니다. 하지만 걱정하지 마십시오. 중복성을 위한 두 번째 제품과 QA를 위한 세 번째 제품을 출시했습니다.

이 시스템은 실행하는 데 비용이 많이 들고 실패할 위험이 높습니다(하나의 잘못된 모델로 인해 전체 서비스가 중단될 수 있음). 더욱이 코드 베이스는 적극적으로 개발되지 않았으므로 최신 데이터 과학 패키지에 비해 상당히 오래되었으며 Scala로 작성된 서비스에 대한 표준 관행을 따르지 않았습니다.

새로운 시스템

이 시스템을 재설계할 때 우리는 확장 가능하게 만드는 명확한 목표를 가지고 있었습니다. 운영 비용 절감은 모델 및 코드 관리를 용이하게 하는 것과 마찬가지로 두 번째 목표였습니다.

우리가 생각해낸 새로운 디자인은 아래와 같습니다.

이 모든 문제를 해결하기 위한 우리의 접근 방식은 각 기계 학습 모델을 격리된 SageMaker 서버리스 엔드포인트에 배치하는 것이었습니다. AWS Lambda 기능과 마찬가지로 서버리스 엔드포인트는 사용하지 않을 때 꺼지므로 자주 사용되지 않는 모델의 런타임 비용이 절약됩니다. 또한 트래픽 증가에 따라 빠르게 확장할 수도 있습니다.

또한 콘텐츠를 적절한 모델로 라우팅하는 단일 마이크로서비스에 클라이언트 옵션을 노출했습니다. 이것은 우리가 작성해야 하는 새 코드의 대부분이었습니다. 유지 관리가 쉽고 데이터 과학자가 새 모델을 더 쉽게 업데이트하고 배포할 수 있는 작은 API였습니다.

이 접근 방식에는 다음과 같은 이점이 있습니다.

• 가치 창출 시간이 6배 이상 단축되었습니다. 특히 기존 모델로의 트래픽 라우팅은 즉각적이며 새 모델 배포는 30분이 아닌 5분 이내에 완료될 수 있습니다.
• 무제한 확장 – 현재 400개의 모델이 있지만 자동으로 조정할 수 있는 콘텐츠의 양을 계속해서 늘리기 위해 수천 개로 확장할 계획입니다.
• 사용하지 않을 때 기능이 꺼지므로 EC2를 사용하지 않고 비용을 82% 절감했으며 활용도가 낮은 최상위 시스템에 대해서는 비용을 지불하지 않습니다.

그러나 단순히 이상적인 아키텍처를 설계하는 것은 레거시 시스템을 재구축할 때 실제로 흥미롭고 어려운 부분이 아닙니다. 레거시 시스템으로 마이그레이션 해야 합니다.

마이그레이션의 첫 번째 과제는 SageMaker Serverless는 물론 SageMaker에서 실행하기 위해 Java WEKA 모델을 마이그레이션하는 방법을 파악하는 것이었습니다.

다행히 SageMaker는 Docker 컨테이너에 모델을 배포하므로 최소한 이전 코드와 일치하도록 Java 및 종속성 버전을 동결할 수 있습니다. 이는 새 시스템에 호스팅된 모델이 기존 시스템과 동일한 결과를 반환하는지 확인하는 데 도움이 됩니다.

컨테이너가 SageMaker와 호환되도록 하려면 몇 가지 특정 HTTP 엔드포인트를 구현하기만 하면 됩니다.

• POST /invocation — 입력을 수락하고 추론을 수행하고 결과를 반환합니다.
• GET /ping — JVM 서버가 정상이면 200을 반환합니다.

(우리는 BYO 다중 모델 컨테이너 및 SageMaker 추론 툴킷과 관련된 모든 허술한 부분을 무시하기로 결정했습니다.)

com.sun.net.httpserver.HttpServer에 대한 몇 가지 간단한 추상화를 수행하면 준비가 완료되었습니다.

그리고 그거 알아? 이것은 실제로 꽤 재미있었습니다. Docker 컨테이너를 가지고 장난을 치고 10년 된 것을 SageMaker Serverless에 강제로 적용하는 것은 약간 땜질하는 분위기였습니다. 우리가 그것을 작동시켰을 때 꽤 흥미로웠습니다. 특히 Maven 대신 새로운 SBT 스택에 구축하기 위해 레거시 시스템 코드를 얻었을 때 더욱 그렇습니다.

새로운 SBT 스택을 사용하면 작업이 쉬워졌으며 컨테이너화를 통해 SageMaker 환경에서 실행하는 동안 적절한 동작을 얻을 수 있었습니다.

새로운 시스템으로 마이그레이션

이제 컨테이너에 모델이 있고 이를 SageMaker에 배포할 수 있습니다. 거의 완료되었습니다. 그렇죠? 좀 빠지는.

새로운 아키텍처로 마이그레이션할 때 어려운 교훈은 마이그레이션을 지원하기 위해 실제 시스템의 3배를 구축해야 한다는 것입니다. 새로운 시스템 외에도 우리는 다음을 구축해야 했습니다.

• 모델의 입력과 출력을 기록하기 위한 기존 시스템의 데이터 캡처 파이프라인입니다. 우리는 이를 사용하여 새 시스템이 동일한 결과를 반환하는지 확인했습니다.
• 결과를 계산하고 이를 기존 시스템의 데이터와 비교하는 새 시스템의 데이터 처리 파이프라인입니다. 여기에는 Datadog을 사용한 대량의 측정이 포함되었으며 불일치가 발견되면 데이터를 재생할 수 있는 기능을 제공해야 했습니다.
• 이전 시스템(단순히 모델을 S3에 업로드함) 사용자에게 영향을 주지 않는 전체 모델 배포 시스템입니다. 우리는 궁극적으로 이를 API로 옮기고 싶다는 것을 알고 있었지만 초기 릴리스에서는 원활하게 수행해야 했습니다.

이 모든 것은 모든 사용자 마이그레이션을 마치면 버릴 수 있다는 것을 알고 있었지만 여전히 코드를 구축하고 새 시스템의 출력이 이전 시스템과 일치하는지 확인해야 했습니다.

이것을 미리 예상하십시오.

마이그레이션 도구와 시스템을 구축하는 데 확실히 이 프로젝트 엔지니어링 시간의 60% 이상이 걸렸지만, 이 역시 즐거운 경험이었습니다. 단위 테스트는 데이터 과학 실험과 비슷해졌습니다. 우리는 출력이 정확히 일치하는지 확인하기 위해 전체 제품군을 작성했습니다. 작업을 훨씬 더 재미있게 만든 것은 다른 사고 방식이었습니다. 원하신다면 일반적인 상자에서 한 걸음 더 나아가십시오.

재구성을 통한 레거시 시스템 현대화

다음에 코드를 작성하여 시스템을 다시 구축하고 싶다면 코드 대신 아키텍처를 마이그레이션해 보시기 바랍니다. 흥미롭고 보람있는 기술적 과제를 발견하게 될 것이며 새 코드의 예상치 못한 극단적인 경우를 디버깅하는 것보다 훨씬 더 즐거운 시간을 보낼 것입니다.

더 자세히 알고 싶으십니까? 아래에서 제가 AWS Data Summit에서 MLOps 측면을 자세히 다룬 강연을 시청해 보세요.