작동 중인 비디오 서비스의 신속한 개발을 위한 서버리스 접근 방식

저는 아웃소싱 분야에서 일하는데, 여기서 주된 원칙은 "많이 팔고, 빨리 하세요"라는 문구로 설명할 수 있습니다. 더 빨리할수록 더 많은 수익을 얻을 수 있습니다. 그리고 모든 것이 목발과 콧물이 아닌 허용 가능한 수준의 품질로 작동하는 것이 바람직합니다. 단기간에 프로모션 서비스를 개발해야 했던 경험을 말씀드리겠습니다.

감안할 때 : AWS의 루트 계정, 기술 스택 선택에 대한 제한 없음, 백엔드 XNUMX개, 개발 기간 XNUMX개월.

작업 : 사용자가 XNUMX~XNUMX초 길이의 동영상을 XNUMX~XNUMX개 업로드한 후 원본 동영상 시리즈에 삽입하는 프로모션 서비스를 구현합니다.

결정

그렇게 짧은 시간에 자신만의 자전거 서비스를 작성하는 것은 좋은 생각이 아닙니다. 또한, 서비스가 부하를 감당하고 모두가 원하는 영상을 받을 수 있도록 하기 위해서는 인프라가 필요합니다. 그리고 비행기 가격표가 붙어 있지 않은 것이 바람직합니다. 따라서 우리는 최소한의 맞춤화로 기성 솔루션에 즉시 집중합니다.

비디오 작업을 위한 표준 솔루션은 인수를 통해 오디오를 잘라내고 오버더빙할 수 있는 크로스 플랫폼 콘솔 유틸리티인 FFmpeg입니다. 이제 남은 일은 래퍼를 작성하여 실제로 구현하는 것뿐입니다. 우리는 두 개의 비디오를 하나로 묶는 프로토타입을 작성하고... 재미가 시작됩니다. 라이브러리는 .NET Core 2를 기반으로 하며 모든 가상 머신에서 실행되어야 하므로 AWS EC2 인스턴스를 사용하면 모든 것이 작동합니다.

숨겨진 텍스트아니요, 작동하지 않습니다
.
FFmpeg는 작업을 단순화하지만 실제로 작동하는 솔루션을 위해서는 EC2 인스턴스를 생성하고 로드 밸런서를 포함하여 이에 대한 네트워크 인프라를 설계해야 합니다. 처음부터 배포하는 간단한 작업은 "약간" 더 복잡해지고 인프라는 즉시 돈을 요구하기 시작합니다. 매시간 런타임 금액이 클라이언트 계정에서 인출됩니다.

우리 서비스는 장기 실행 프로세스를 포함하지 않고, 크고 방대한 관계형 데이터베이스를 필요로 하지 않으며, 마이크로서비스 호출 체인이 있는 이벤트 기반 아키텍처에 완벽하게 들어맞습니다. 솔루션은 자체적으로 제안합니다. EC2를 버리고 AWS Lambda 기반의 표준 Image Resizer와 같은 진정한 서버리스 애플리케이션을 구현할 수 있습니다.

그건 그렇고, .NET에 대한 AWS 개발자의 명백한 혐오에도 불구하고 그들은 .NET Core 2.1을 런타임으로 지원하여 광범위한 개발 기회를 제공합니다.

그리고 가장 좋은 점은 AWS가 비디오 파일 작업을 위한 별도의 서비스인 AWS Elemental MediaConvert를 제공한다는 것입니다.

작업의 본질은 놀라울 정도로 간단합니다. 나가는 비디오에 대한 S3 링크를 가져오고, AWS 콘솔, .NET SDK 또는 단순히 JSON을 통해 비디오로 수행하려는 작업을 작성하고 서비스를 호출합니다. 자체적으로 들어오는 요청을 처리하기 위한 대기열을 구현하고 결과를 S3 자체에 업로드하며 가장 중요한 것은 각 상태 변경에 대해 CloudWatch 이벤트를 생성합니다. 이를 통해 비디오 처리를 완료하기 위해 람다 트리거를 구현할 수 있습니다.

최종 아키텍처는 다음과 같습니다.

전체 백엔드는 두 개의 람다에 보관됩니다. 또 다른 하나는 수직 비디오 회전을 위한 것입니다. 왜냐하면 이러한 작업은 한 번에 완료할 수 없기 때문입니다.

우리는 JS로 작성되고 퍼그를 통해 컴파일된 SPA 애플리케이션의 형태로 퍼블릭 S3 버킷에 배치할 것입니다. 비디오 자체를 다운로드하려면 서버 코드가 필요하지 않습니다. S3가 제공하는 REST 엔드포인트만 열면 됩니다. 유일한 것은 정책과 CORS를 구성하는 것을 잊지 않는 것입니다.

주의

• AWS MediaConvert는 알 수 없는 이유로 각 비디오 조각에만 사운드를 개별적으로 적용하지만 전체 화면 보호기에서 쾌활한 노래가 필요합니다.
• 세로형 동영상은 별도로 처리해야 합니다. AWS는 검은색 막대를 좋아하지 않으며 롤러를 90°로 설정합니다.

쉬운 스케이트장

Stateless의 모든 장점에도 불구하고 비디오로 수행해야 할 작업을 추적해야 합니다. 즉, 완성된 비디오 시퀀스에 오디오를 붙이거나 추가하는 것입니다. 다행히 MediaConvert는 작업을 통한 메타데이터 전달을 지원하며 언제든지 "isMasterSoundJob" 형식의 간단한 플래그를 사용하여 모든 단계에서 이 메타데이터를 구문 분석할 수 있습니다.

서버리스를 사용하면 프로젝트 인프라를 담당하는 별도의 팀이 불필요하다고 가정하는 접근 방식인 NoOps 작업을 완벽하게 수행할 수 있습니다. 따라서 이는 작은 문제였습니다. 항상 할 일이 있는 시스템 관리자의 참여 없이 AWS에 솔루션을 배포했습니다.
그리고 이 모든 작업의 ​​속도를 높이기 위해 AWS CloudFormation에서 배포 스크립트를 최대한 자동화합니다. 이를 통해 VS에서 버튼 하나로 직접 배포할 수 있습니다. 결과적으로 200줄의 코드 파일을 사용하면 기성 솔루션을 출시할 수 있습니다. 단, CloudFormation 구문이 익숙하지 않은 경우 충격적일 수 있습니다.

전체로

서버리스는 만병통치약이 아닙니다. 그러나 "제한된 자원, 단기, 적은 돈"이라는 세 가지 제한이 있는 상황에서는 삶이 훨씬 더 쉬워질 것입니다.

서버리스에 적합한 애플리케이션의 특징

• 장기 실행 프로세스 없이. API Gateway 하드 제한은 29초, 람다 하드 제한은 5분입니다.
• 이벤트 중심 아키텍처로 설명됩니다.
• SOA와 같이 느슨하게 결합된 구성 요소로 분해됩니다.
• 귀하의 상태에 따라 많은 작업이 필요하지 않습니다.
• .NET Core로 작성되었습니다. .NET Framework를 사용하려면 적절한 런타임이 포함된 Docker가 최소한 필요합니다.

서버리스 접근 방식의 이점

• 인프라 비용 절감;
• 솔루션 제공 비용을 절감합니다.
• 자동 확장성;
• 기술 진보의 최첨단에서의 발전.

단점, 구체적인 예

• 분산 추적 및 로깅 - AWS X-Ray 및 AWS CloudWatch를 통해 부분적으로 해결되었습니다.
• 불편한 디버깅;
• 부하가 없을 때 콜드 스타트;
• AWS 사용자에게 적대적인 인터페이스는 보편적인 문제입니다 :)

출처 : habr.com