Qbiq: AWS Lambda 컨테이너 이미지와 분산 ML을 사용하여 구성 최적화

게스트 게시물 저자: Qbiq Team과 AWS Startup Solutions Architect인 Hilal Habashi

부동산 소프트웨어 Startup인 Qbiq system은 인공 지능 기반 공간 계획 설계 엔진을 제공합니다. 이 엔진은 대량의 사용자 지정된 평면도를 생성하고 대안을 비교하여 결과를 최적화합니다. 공간 활용도, 비용, 제작 시간, 효율성 및 기타 여러 요인의 제약 내에서 최상의 레이아웃 설계를 즉시 제안합니다. 이 사소하지 않은 컴퓨팅 집약적 계산은 각 작업 요청을 여러 부분으로 나누어 배후에서 분산된 방식으로 수행됩니다. 좀 더 구체적으로 말하자면, 수신된 각 계획은 하위 계획으로 분류되고 이 각 하위 계획은 기계 학습(ML) 및 비선형 프로그래밍을 사용하여 처리됩니다. 그런 다음에는 먼저 ML 모델을 사용하여 다양한 레이아웃 대안을 인식하고 분석한 다음 2차 방정식을 사용하여 결과를 최적화합니다.

우리 회사는 AWS 서비스의 유연성과 탄력성 때문에 여정을 시작할 때 바로 AWS를 선택했습니다. 이 선택은 파이프라인의 각 단계에 필요한 상당한 컴퓨팅 파워 요구 사항을 고려할 때 완벽하게 맞았습니다. 사실, 주요 워크로드를 제외하고, 계획을 분할하는 전처리 단계에서는 공간 분석 및 기하학적 분석과 대규모 하이퍼 파라미터 검색 기능이 모두 필요한데, 그 자체로도 쉽지 않은 워크로드입니다. 또한 백본 네트워크 범위와 응답 시간, 광범위한 서비스, 사용량에 따라 지불하는 비용 모델도 중요합니다. 이 모든 것은 서비스를 확장하여 최대한 많은 고객에게 제공하는 데 필요한 기능입니다.

회사의 비즈니스 모델을 지원하려면 고객에게 빠르고 안정적인 서비스형 소프트웨어(SaaS) 솔루션을 제공해야 했는데, 이는 처음 시작할 때 염두에 두었던 것과는 사뭇 달랐습니다. 이 글에 나오는 분산 워크로드를 구축하는 과정에서 상당한 어려움을 겪었고, 아키텍처가 크게 변경되는 다른 사례와 마찬가지로, 새로운 기술을 채택하는 것과 엔지니어링 팀을 온보딩하고 교육하여 가능한 최고의 제품을 구축하는 것 사이에서 적절한 중간점을 찾아야 했습니다.

당면 과제

분산 ML 알고리즘 개발

처음에는 Amazon EC2 인스턴스에서 실행되는 클라우드 네이티브 SaaS 솔루션으로 시작했습니다. 제한된 실행 시간(5분 미만)에 대량의 계산을 수행하기 위해 워크로드를 작은 세그먼트로 나누고 분산된 방식으로 하위 작업을 실행해야 했습니다. AWS에서 컴퓨팅을 수평적으로 확장하기 시작하면서 알고리즘을 재작업하고, 공유 스토리지를 사용하여 실행해야 하는 다양한 모델을 저장하고, 시간이 지남에 따라 수신되는 작업 대기열을 구축하는 일도 해야 했지만, Amazon EFS와 Amazon SQS 덕분에 소규모 팀이 거의 작업을 하지 않거나 전혀 하지 않고도 분산 컴퓨팅 요구 사항에 맞는 지원 인프라를 신속하게 구현하고 유지 관리할 수 있었습니다. EFS를 통해 AWS Lambda 컨테이너 간에 스토리지를 공유하고 드라이브를 하위 프로세스를 위한 공유 탑재 스토리지로 사용할 수 있었습니다.

알고리즘 배포 및 유지 관리

전용 도구를 사용하거나 처음부터 자체 배포 스크립트를 작성할 필요 없이 컨테이너 기반 접근 방식으로 알고리즘을 배포하는 것이 중요했습니다. 우리는 기존의 Git-Ops 접근 방식과 호환되고 컨테이너 실행 환경을 추상화할 수 있는 솔루션을 원했습니다. 컨테이너 클러스터를 프로비저닝하거나 관리하는 것에 대한 걱정 없이 수요에 따라 사용 가능한 컴퓨팅 파워를 빠르게 확장하고자 했습니다. AWS Fargate 또는 EC2 기반 솔루션보다는 EFS나 Amazon EBS와 함께 Lambda 컨테이너를 사용하기로 결정했는데, 컨테이너 오케스트레이션 및 관리 작업을 수행할 필요가 없는 종량제 모델을 갖춘 매우 유연하고 확장 가능한 솔루션을 원했기 때문입니다.

로드 시 알고리즘 테스트

로컬에서 실행하든 클라우드에서 실행하든 규모와 관계없이 분산된 태스크 클러스터 전체에서 계산이 올바르게 수행되는지 확인하기 위해 엔드 투 엔드 테스트를 작성해야 했습니다. 실제로 EC2에서 워크로드를 실행하고 오케스트레이션했을 때 분산 소프트웨어 인스턴스를 추가할수록 구성을 유지 관리하고 스택을 전체적으로 테스트하기가 더 어려워진다는 것을 알게 되었습니다. 우리의 전반적인 목표는 상호 코드베이스를 사용하여 설치 스크립트 2세트를 유지하지 않으면서 클라우드 충실도를 높이는 것이었습니다. 또한 방대한 구성 없이 고부하 시나리오에서 제품을 테스트할 수 있기를 원했습니다.

클라우드 아키텍처의 AWS Lambda 컨테이너

최근에 추가된 Lambda의 사용자 지정 컨테이너 이미지 지원은 모든 요구 사항을 충족했습니다. 알고리즘을 작성하고 이를 모든 종속성과 함께 컨테이너 이미지 안에 래핑하는 것은 쉬웠습니다. 그 후에는 볼륨을 탑재하고 컨테이너 이미지에 새 모델 파일을 추가하고 로컬과 클라우드에서 소프트웨어를 테스트해야 했습니다. 컨테이너를 채택하면서 외부 DevOps 도구 대신 신뢰할 수 있는 Git 기반 흐름만 사용하면 되었기 때문에 배포 프로세스가 간소화되었습니다. 결국, 컴퓨팅 리소스 관리를 Lambda의 메모리와 vCPU를 구성하는 간단한 작업으로 축소할 수 있었습니다. 이 작업은 Lambda Power Tuning을 사용하면서 훨씬 더 쉬워졌습니다. 본질적으로 우리 제품의 핵심은 환경의 Lambda에서 실행되는 컨테이너 이미지인데, Lambda 이벤트 소스는 나머지 AWS 서비스와 원활하게 통합되었기 때문에 EC2에서 쉽게 마이그레이션할 수 있었습니다.

개요:

Amazon Elastic Container Registry(Amazon ECR)를 사용하여 기본 이미지 3개를 각각 저장하는 Lambda 함수 3개를 구축했습니다. 프로세스의 각 부분에 해당하는 이 기본 이미지에는 기본 종속성 및 설정이 파일 및 환경 변수로 포함되었습니다. 그런 다음 EFS를 연결하고 각 태스크의 출력을 저장하여 다음 작업에 빠르게 사용할 수 있도록 하고 분산 ML 모델을 Amazon S3에 저장했습니다. 분산 ML 프로세스로 인해 태스크가 훨씬 더 줄어들었기 때문에 모든 컨테이너 기반 워크로드 내에서 탑재하고 액세스할 수 있는 상호 파일 시스템을 갖추는 것이 중요했습니다. 이 설정을 통해 다양한 Lambda 함수 간에 높은 처리량과 낮은 오버헤드로 파일을 공유할 수 있었습니다. 우리는 수신 파일과 함께 작업에 대한 정보가 들어 있는 여러 SQS 대기열을 사용합니다.

이 아키텍처를 사용하면 알고리즘을 실행하는 시간에만 요금이 부과되므로 비용을 절감하면서 EC2 클러스터를 통한 배포와 비슷한 결과를 얻을 수 있으며 전체 배포 시간을 단축할 수 있습니다. 예를 들어 최대 동시 실행 횟수 500회로 5,000개의 Lambda 함수를 호출하여 2분 만에 50개의 결과 배치를 생성할 수 있으므로 결과적으로 배치당 평균 비용은 1 USD입니다. 반면, 500개의 병렬 코어가 있는 EC2 클러스터에서 실행하면 비용이 약 2배 더 많이 들고 클러스터를 프로비저닝해야 합니다. 마지막으로, ML 엔지니어와 데이터 사이언티스트는 클라우드에서 실행되는 비컨테이너식 환경을 위한 고유한 세트를 예전처럼 작성하는 대신 한 세트의 테스트를 사용하여 익숙한 컨테이너 기반 환경 내에서 작업할 수 있습니다.

워크로드 관리

분산 ML 워크로드를 안정적으로 관리하기 위해 그래프 기반 워크플로 관리자를 자체적으로 구현했습니다. 사용자가 보내는 각 작업 요청은 파일이 업로드되고 파일 이름이 주제 이름으로 기록되면서 시작됩니다. 그러면 각 주제 이름에 대한 하위 그래프를 생성하여 그 아래에 여러 노드를 포함할 수 있습니다. 즉, 처리할 계산 태스크당 노드 1개를 포함할 수 있습니다. 작업 하위 그래프의 각 노드에는 내부 상태 표현이 포함됩니다. 하위 그래프의 간선은 입력과 실행할 다음 작업의 함수입니다.

현재 워크로드는 3단계 프로세스입니다. 즉, 각 작업을 분할한 부분의 수에 3을 곱하는 것입니다. 전처리 파이프라인은 작업과 해당 파일을 여러 부분으로 나눕니다. 각 작업에 대해 하위 그래프가 생성되면 워크플로 관리자가 여러 노드가 포함된 시스템에 작업을 로드합니다. 그래프의 간선을 횡단하고 이에 따라 현재 상태 정보를 다음 Lambda 함수에 한 번에 로드하여 병렬로 삽입된 노드의 처리를 시작합니다. 워크플로 관리자는 프로세스의 각 단계와 작업의 부분에 해당하는 노드에 데이터를 기록하고 작업에 필요한 모든 데이터가 처리될 때까지 계속합니다. 마지막으로 결과를 집계하여 고객에게 전달합니다.

워크플로 관리자는 2가지 유형의 POST 요청을 사용하여 REST API를 통해 Lambda 함수와 통신합니다.

1) `RequestRequired`는 대용량 페이로드를 처리할 수 있는 동기식 요청이지만 응답 시간 제한이 30초입니다.

2) 'Event'는 비동기식 요청이며 페이로드가 적은 여러 병렬 작업을 보내는 데 적합합니다.

워크플로 관리자 설계:

워크플로 관리자는 송신기와 소비자라는 2개의 도우미 스레드를 설정합니다. 송신기 스레드는 비동기식 작업 대기열을 확인하고 Lambda 함수로 전송하여 활성화할 작업을 관리하는 역할을 합니다. 파라미터로 동시 활성 작업 수를 제어하여 활성 Lambda의 동시성을 제어할 수 있습니다. Lambda 함수로 처리할 작업이 전송되면 요청에는 응답을 기록할 SQS 대기열 이름이 포함됩니다. 소비자 스레드는 SQS 대기열의 메시지를 소비하고 수신되는 작업 응답을 주제에 따라 배포하는 역할을 합니다.

제한된 작업자 풀을 사용하여 동시성 제한을 초과하지 않으면서 많은 수의 태스크를 배포하므로 수렴하지 않거나 불규칙한 계산 시간이 필요한 노드가 있으면 시스템 성능이 크게 저하될 수 있습니다. 시간이 많이 걸리거나 지나치게 긴 작업을 방지하기 위해 3회 시간 초과 시스템이 사용됩니다. 첫 번째 시간 초과는 Lambda 함수를 설정할 때 구성되는 기본 Lambda 시간 초과입니다. 이 시간 초과는 잠재적으로 절대 도달하지 않아야 하므로 약간 느슨해야 합니다. 두 번째 시간 초과는 각 Lambda 함수 내에 있습니다. 함수 핸들러가 직접적으로 호출되면 추가 스레드가 시작되고 지정된 시간 동안 대기합니다. 시간 초과에 도달하면 Lambda 함수가 시간 초과 오류 응답을 대기열로 다시 보냅니다. 마지막은 Lambda 함수에 구애받지 않는 워크플로 관리자의 주제 시간 초과이며, 이 주제로 마지막 작업 게시가 전송된 이후 일정 시간이 경과하면 트리거됩니다.

빠른 워밍업(시작 시간 단축)으로 고성능을 달성하기 위해 Lambda 함수의 프로비저닝된 동시성 기능을 사용했습니다. 또한 초기화 호출을 사용하여 Lambda 함수를 워밍업하고 데이터를 준비합니다. 또한 여러 Lambda에서 EFS에 저장된 데이터에 병렬로 액세스할 때 초당 높은 MiB를 지원하기 위해 EFS 처리량을 프로비저닝합니다.

결론

Qbiq는 부동산 계획에 최첨단 AI, 생성형 설계 및 최적화 기술을 활용합니다. AWS Lambda 이미지 컨테이너를 사용하면 수백 년의 아키텍처 경험을 바탕으로 수백 개의 클라우드 프로세서로 쉽게 확장하고, 계획 요청을 처리하며, 다양한 레이아웃 대안을 분석하고, 결과를 최적화할 수 있습니다.

당사는 사용률, 비용, 구축 시간, 효율성 등을 고려하여 고객에게 최상의 건축 대안을 제공합니다. Qbiq에 대한 자세한 내용은 당사 웹 사이트 qbiq.ai를 참조하세요.