신경망 기반 외관 평가를 위한 서비스 아키텍처의 일반 개요

기입

Привет!

이 기사에서는 신경망을 사용하여 프로젝트를 위한 마이크로서비스 아키텍처를 구축한 경험을 공유하겠습니다.

아키텍처 요구 사항에 대해 이야기하고, 다양한 구조 다이어그램을 살펴보고, 완성된 아키텍처의 각 구성 요소를 분석하고, 솔루션의 기술적 지표도 평가해 보겠습니다.

독서를 즐기십시오!

문제와 해결 방법에 대한 몇 마디

주요 아이디어는 사진을 바탕으로 사람의 매력을 XNUMX점 척도로 평가하는 것입니다.

이 기사에서는 사용된 신경망과 데이터 준비 및 훈련 프로세스를 모두 설명하는 것에서 벗어나겠습니다. 그러나 다음 간행물 중 하나에서 우리는 평가 파이프라인을 심층적인 수준으로 분석하는 것으로 확실히 돌아갈 것입니다.

이제 우리는 최상위 수준의 평가 파이프라인을 살펴보고 전체 프로젝트 아키텍처의 맥락에서 마이크로서비스의 상호 작용에 중점을 둘 것입니다. 

매력도 평가 파이프라인 작업 시 작업은 다음 구성 요소로 분해되었습니다.

1. 사진에서 얼굴 선택
2. 각 사람의 평가
3. 결과 렌더링

첫 번째는 사전 훈련된 힘에 의해 해결됩니다. MTCNN. 두 번째로, 컨볼루셔널 신경망은 다음을 사용하여 PyTorch에서 훈련되었습니다. 레스넷34 – "CPU의 추론 품질/속도" 균형에서

평가 파이프라인의 기능 다이어그램

프로젝트 아키텍처 요구 사항 분석

수명주기에서 ML 모델 배포의 아키텍처 및 자동화에 대한 작업의 프로젝트 단계는 종종 가장 시간과 리소스가 많이 소요되는 단계 중 하나입니다.

ML 프로젝트의 수명 주기

이 프로젝트도 예외는 아닙니다. 평가 파이프라인을 온라인 서비스로 래핑하기로 결정했으며, 이를 위해서는 아키텍처에 몰입해야 했습니다. 다음과 같은 기본 요구 사항이 확인되었습니다.

1. 통합 로그 저장 – 모든 서비스는 한 곳에 로그를 작성해야 하며, 분석하기 편리해야 합니다.
2. 평가 서비스의 수평적 확장 가능성 - 병목 현상이 발생할 가능성이 가장 높음
3. 추론 시간 분배에서 이상값을 방지하려면 각 이미지를 평가하는 데 동일한 양의 프로세서 리소스를 할당해야 합니다.
4. 특정 서비스와 스택 전체의 빠른 (재)배포
5. 필요한 경우 다양한 서비스에서 공통 개체를 사용하는 기능

구조

요구 사항을 분석한 후 마이크로서비스 아키텍처가 거의 완벽하게 적합하다는 것이 분명해졌습니다.

불필요한 골치 아픈 문제를 없애기 위해 Telegram API가 프런트엔드로 선택되었습니다.

먼저 완성된 아키텍처의 구조 다이어그램을 살펴본 다음 각 구성 요소에 대한 설명으로 이동하고 성공적인 이미지 처리 프로세스를 형식화해 보겠습니다.

완성된 아키텍처의 구조 다이어그램

이미지 평가 과정에서 단일 책임을 나타내는 다이어그램의 각 구성 요소에 대해 자세히 설명하겠습니다.

마이크로서비스 “attrai-telegram-bot”

이 마이크로서비스는 Telegram API와의 모든 상호 작용을 캡슐화합니다. 두 가지 주요 시나리오가 있습니다. 사용자 지정 이미지 작업과 평가 파이프라인 결과 작업입니다. 일반적인 용어로 두 시나리오를 모두 살펴보겠습니다.

이미지가 포함된 맞춤 메시지를 받는 경우:

1. 다음 검사로 구성된 필터링이 수행됩니다.
   • 최적의 이미지 크기 가용성
   • 이미 대기열에 있는 사용자 이미지 수
2. 초기 필터링을 통과하면 이미지가 도커 볼륨에 저장됩니다.
3. 작업은 무엇보다도 볼륨에 있는 이미지의 경로를 포함하는 "to_estimate" 대기열에서 생성됩니다.
4. 위 단계가 성공적으로 완료되면 사용자는 대기열의 작업 수를 기준으로 계산된 대략적인 이미지 처리 시간이 포함된 메시지를 받게 됩니다. 오류가 발생하면 무엇이 잘못되었는지에 대한 정보가 포함된 메시지를 보내 사용자에게 명시적으로 알립니다.

또한 셀러리 작업자와 마찬가지로 이 마이크로서비스는 평가 파이프라인을 통과한 작업을 위한 "after_estimate" 대기열을 수신합니다.

"after_estimate"에서 새 작업을 받을 때:

1. 이미지가 성공적으로 처리되면 결과를 사용자에게 전송하고, 그렇지 않으면 오류를 알려줍니다.
2. 평가 파이프라인의 결과인 이미지 제거

평가 마이크로서비스 “attrai-estimator”

이 마이크로서비스는 셀러리 작업자이며 이미지 평가 파이프라인과 관련된 모든 것을 캡슐화합니다. 여기에는 작동하는 알고리즘이 하나만 있습니다. 분석해 보겠습니다.

"to_estimate"로부터 새 작업을 받을 때:

1. 평가 파이프라인을 통해 이미지를 실행해 보겠습니다.
   1. 이미지를 메모리에 로드
   2. 이미지를 필요한 크기로 가져옵니다.
   3. 모든 얼굴 찾기(MTCNN)
   4. 모든 얼굴을 평가합니다. (마지막 단계에서 찾은 얼굴을 일괄 처리하고 ResNet34를 추론합니다.)
   5. 최종 이미지 렌더링
      1. 경계 상자를 그려 봅시다
      2. 평점 그리기
2. 사용자 정의(원본) 이미지 삭제
3. 평가 파이프라인의 출력 저장
4. 위에서 설명한 "attrai-telegram-bot" 마이크로서비스가 수신하는 "after_estimate" 대기열에 작업을 넣습니다.

Graylog(+ mongoDB + Elasticsearch)

그레이로그 중앙화된 로그 관리를 위한 솔루션입니다. 본 프로젝트에서는 의도한 목적에 맞게 사용되었습니다.

선택은 그에게 떨어졌고 평소의 선택은 아닙니다. 고라니 Python에서 작업하는 것이 편리하기 때문에 스택입니다. Graylog에 로그인하기 위해 해야 할 일은 패키지에서 GELFTCPHandler를 추가하는 것뿐입니다. 그레이피 Python 마이크로서비스의 나머지 루트 로거 핸들러에 연결됩니다.

이전에 ELK 스택으로만 작업했던 사람으로서 저는 Graylog로 작업하면서 전반적으로 긍정적인 경험을 했습니다. 실망스러운 유일한 점은 Graylog 웹 인터페이스에 비해 Kibana 기능이 우월하다는 점입니다.

RabbitMQ

RabbitMQ AMQP 프로토콜을 기반으로 하는 메시지 브로커입니다.

이 프로젝트에서는 다음과 같이 사용되었습니다. 가장 안정적이고 시간 테스트를 거친 Celery용 브로커이며 내구성 모드에서 작동했습니다.

Redis

Redis 키-값 데이터 구조로 작동하는 NoSQL DBMS입니다.

때로는 다양한 Python 마이크로서비스에서 특정 데이터 구조를 구현하는 공통 개체를 사용해야 할 때가 있습니다.

예를 들어 Redis는 "telegram_user_id => 대기열의 활성 작업 수" 형식의 해시맵을 저장합니다. 이를 통해 한 사용자의 요청 수를 특정 값으로 제한하여 DoS 공격을 방지할 수 있습니다.

성공적인 이미지 처리 과정을 공식화해보자

1. 사용자가 텔레그램 봇에 이미지를 보냅니다.
2. "attrai-telegram-bot"은 Telegram API로부터 메시지를 수신하여 구문 분석합니다.
3. 이미지가 포함된 작업이 비동기 대기열 "to_estimate"에 추가됩니다.
4. 사용자는 계획된 평가 시간이 포함된 메시지를 받습니다.
5. "attrai-estimator"는 "to_estimate" 대기열에서 작업을 가져와서 파이프라인을 통해 추정치를 실행하고 작업을 "after_estimate" 대기열에 생성합니다.
6. "after_estimate" 대기열을 수신하는 "attrai-telegram-bot"은 결과를 사용자에게 보냅니다.

개발자

마지막으로 아키텍처를 검토한 후 똑같이 흥미로운 부분인 DevOps로 넘어갈 수 있습니다.

도커 스웜

 

도커 스웜  — 기능이 Docker 엔진 내부에 구현되어 즉시 사용할 수 있는 클러스터링 시스템입니다.

"swarm"을 사용하면 클러스터의 모든 노드를 작업자와 관리자의 두 가지 유형으로 나눌 수 있습니다. 첫 번째 유형의 머신에서는 컨테이너 그룹(스택)이 배포되고, 두 번째 유형의 머신은 확장, 균형 조정 및 관리를 담당합니다. 다른 멋진 기능. 관리자도 기본적으로 근로자입니다.

리더 관리자 XNUMX명과 작업자 XNUMX명이 있는 클러스터

가능한 최소 클러스터 크기는 노드 1개이며, 단일 머신은 리더 관리자와 작업자 역할을 동시에 수행합니다. 프로젝트 규모와 내결함성에 대한 최소 요구 사항을 기반으로 이 접근 방식을 사용하기로 결정되었습니다.

앞으로는 XNUMX월 중순에 있었던 첫 번째 제품 인도 이후 이 클러스터 조직과 관련된 문제가 없었다고 말씀드리겠습니다. (그러나 이것이 그러한 조직이 어떤 중대형 조직에서도 허용된다는 의미는 아닙니다. 내결함성 요구 사항이 적용되는 프로젝트).

도커 스택

스웜 모드에서는 스택(도커 서비스 세트) 배포를 담당합니다. 도커 스택

docker-compose 구성을 지원하므로 배포 옵션을 추가로 사용할 수 있습니다.  

예를 들어, 이러한 매개변수를 사용하면 각 평가 마이크로서비스 인스턴스에 대한 리소스가 제한됩니다(N 인스턴스에 N 코어를 할당하고 마이크로서비스 자체에서는 PyTorch에서 사용하는 코어 수를 하나로 제한합니다).

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

Redis, RabbitMQ 및 Graylog는 상태 저장 서비스이며 "attrai-estimator"만큼 쉽게 확장할 수 없다는 점에 유의하는 것이 중요합니다.

질문을 예시합니다. Kubernetes는 왜 안 됩니까?

중소 규모 프로젝트에서 Kubernetes를 사용하는 것은 오버헤드인 것 같습니다. 필요한 모든 기능은 컨테이너 오케스트레이터에게 매우 사용자 친화적이고 진입 장벽도 낮은 Docker Swarm에서 얻을 수 있습니다.

하부 구조

이 모든 것은 다음과 같은 특성을 가진 VDS에 배포되었습니다.

• CPU: 4코어 Intel® Xeon® Gold 5120 CPU @ 2.20GHz
• RAM : 8 GB
• SSD : 160GB

로컬 로드 테스트를 거친 후 사용자가 많이 유입되면 이 머신이면 충분할 것 같았습니다.

하지만 배포 직후 CIS에서 가장 인기 있는 이미지 보드 중 하나(예, 같은 이미지)에 대한 링크를 게시했고 그 후 사람들이 관심을 갖게 되었고 몇 시간 만에 서비스가 수만 개의 이미지를 성공적으로 처리했습니다. 동시에, 피크 순간에는 CPU와 RAM 리소스가 절반도 사용되지 않았습니다.

추가 그래픽

배포 이후 날짜에 따른 고유 사용자 수 및 평가 요청 수

평가 파이프라인 추론 시간 분포

조사 결과

요약하자면, 컨테이너 오케스트레이션에 대한 아키텍처와 접근 방식은 완전히 정당화되었다고 말할 수 있습니다. 심지어 피크 순간에도 처리 시간이 떨어지거나 느려지는 일이 없었습니다. 

프로세스에서 CPU에 대한 신경망의 실시간 추론을 사용하는 중소 규모 프로젝트는 이 기사에서 설명하는 방식을 성공적으로 채택할 수 있다고 생각합니다.

처음에는 기사가 더 길었지만 길게 읽은 내용을 게시하지 않기 위해 이 기사에서 몇 가지 사항을 생략하기로 결정했습니다. 향후 발행물에서 이에 대해 다시 설명하겠습니다.

Telegram - @AttraiBot에서 봇을 찌를 수 있으며, 적어도 2020년 가을 말까지 작동합니다. 원본 이미지나 평가 파이프라인의 결과 등 어떤 사용자 데이터도 저장되지 않으며 모든 것이 처리 후에 폐기됩니다.

출처 : habr.com