私はアウトソーシングの仕事をしていますが、その主な原則は「たくさん売る、早くやる」という言葉で表現できます。 早くやればやるほど、より多くの利益が得られます。 そして、すべてが松葉杖や鼻水ではなく、許容可能なレベルの品質で機能することが望ましいです。 短期間でプロモーションサービスを開発する必要があったときの私の経験をお話します。
月： AWS の root アカウント、テクノロジースタックの選択に制限なし、バックエンドは XNUMX つ、開発期間は XNUMX か月です。
タスク： ユーザーが XNUMX ～ XNUMX 秒の長さのビデオを XNUMX ～ XNUMX つアップロードし、それらのビデオが元のビデオ シリーズに埋め込まれるプロモーション サービスを実装します。
ソリューション
独自の自転車サービスをこれほど短期間で作成するのは得策ではありません。 さらに、サービスが負荷に対処し、誰もが切望するビデオを受信できるようにするには、インフラストラクチャが必要になります。 そしてできれば飛行機の値札は付けないでください。 したがって、私たちはカスタマイズを最小限に抑えた既製のソリューションにすぐに焦点を当てます。
ビデオを操作するための標準ソリューションは FFmpeg です。FFmpeg は、引数を使用してオーディオのカットやオーバーダビングを可能にするクロスプラットフォームのコンソール ユーティリティです。 あとはラッパーを書いてリリースするだけです。 2 つのビデオをつなぎ合わせるプロトタイプを作成します。そして...楽しい時間が始まります。 このライブラリは .NET Core 2 に基づいており、任意の仮想マシン上で実行できるため、AWS ECXNUMX インスタンスを使用するとすべてが機能します。
隠しテキストいいえ、うまくいきません
.
FFmpeg はタスクを簡素化しますが、実際に機能するソリューションを実現するには、EC2 インスタンスを作成し、ロード バランサーを含むそのためのネットワーク インフラストラクチャを設計する必要があります。 ゼロからデプロイするという単純なタスクは「少し」複雑になり、インフラストラクチャはすぐにお金を要求し始めます。実行時間の金額は XNUMX 時間ごとにクライアントのアカウントから引き落とされます。
当社のサービスには長時間実行プロセスが含まれず、大規模で肥大なリレーショナル データベースも必要とせず、マイクロサービス呼び出しのチェーンを備えたイベントベースのアーキテクチャに完全に適合します。 この解決策は、EC2 を放棄して、AWS Lambda に基づく標準の Image Resizer のような真のサーバーレス アプリケーションを実装できることを示唆しています。
ちなみに、AWS 開発者は明らかに .NET を嫌っていますが、彼らはランタイムとして .NET Core 2.1 をサポートしており、あらゆる開発の機会を提供しています。
そしておまけに、AWS はビデオ ファイルを操作するための別のサービスである AWS Elemental MediaConvert を提供しています。
作業の本質は信じられないほど単純です。送信ビデオへの S3 リンクを取得し、AWS コンソール、.NET SDK、または単に JSON を通じてビデオで実行したいことを記述し、サービスを呼び出します。 それ自体が受信リクエストを処理するためのキューを実装し、結果を S3 自体にアップロードします。そして最も重要なこととして、ステータス変更ごとに CloudWatch イベントを生成します。 これにより、ラムダ トリガーを実装してビデオ処理を完了できるようになります。
最終的なアーキテクチャは次のようになります。
バックエンド全体は XNUMX つのラムダに格納されています。 もう XNUMX つは、垂直ビデオを回転するためのものです。このような作業は XNUMX 回のパスでは実行できないためです。
JS で記述され、pug 経由でコンパイルされた SPA アプリケーションの形式でフロントをパブリック S3 バケットに配置します。 ビデオ自体をダウンロードするには、サーバー コードは必要ありません。S3 が提供する REST エンドポイントを開くだけです。 唯一のことは、ポリシーと CORS を忘れずに構成することです。
落とし穴
- AWS MediaConvert は、何らかの理由で、各ビデオ フラグメントにサウンドを個別に適用するだけですが、スクリーンセーバー全体から陽気な曲が必要です。
- 縦型ビデオは個別に処理する必要があります。 AWS は黒いバーを好まず、ローラーを 90° に置きます。
気軽に楽しめるスケートリンク
ステートレスの美しさにもかかわらず、完成したビデオ シーケンスにオーディオを接着したり追加したりするなど、ビデオに対して何を行う必要があるかを追跡する必要があります。 幸いなことに、MediaConvert はジョブを介したメタデータの受け渡しをサポートしており、いつでも「isMasterSoundJob」形式の単純なフラグを使用して、どの段階でもこのメタデータを解析できます。
サーバーレスでは、プロジェクトのインフラストラクチャを担当する別のチームが不要になることを想定したアプローチである NoOps での作業が完全に可能になります。 したがって、それは小さな問題でした。私たちは、常に何かをしなければならないシステム管理者の参加なしで、AWS にソリューションをデプロイしました。
これらすべてを高速化するために、AWS CloudFormation でデプロイ スクリプトを可能な限り自動化し、ボタン 200 つで VS から直接デプロイできるようにしました。 その結果、XNUMX 行のコードのファイルで既製のソリューションを展開できますが、CloudFormation 構文に慣れていないと衝撃を受ける可能性があります。
合計で
サーバーレスは万能薬ではありません。 しかし、「資源が限られている、短期的、資金が少ない」という XNUMX つの制限がある状況では、生活がはるかに楽になります。
サーバーレスに適したアプリケーションの特徴
- 長時間実行プロセスなし。 API ゲートウェイのハード制限は 29 秒、ラムダのハード制限は 5 分です。
- イベント駆動型アーキテクチャによって記述されます。
- SOA のような疎結合コンポーネントに分割されます。
- あなたの症状に対して多くの作業を必要としません。
- .NET Coreで書かれています。 .NET Framework を使用するには、少なくとも適切なランタイムを備えた Docker が必要です。
サーバーレスアプローチの利点
- インフラストラクチャのコストを削減します。
- ソリューションの提供コストを削減します。
- 自動スケーラビリティ。
- 技術進歩の最先端での開発。
デメリットと具体的な例
- 分散トレースとロギング - AWS X-Ray と AWS CloudWatch によって部分的に解決されました。
- デバッグが不便。
- 無負荷時のコールドスタート。
- AWS のユーザーに敵対的なインターフェースは普遍的な問題です :)
出所： habr.com