Zenn
📘

動画配信プラットフォームのデータ移行システムで利用してみたAWSサービスあれこれ

2023/07/11に公開
AWS
S3
#
Step Functions
eventbridge
tech

はじめに

こんにちは、エビリーで動画配信システム『millvi（ミルビィ）』の開発を担当しているukisuと申します。

現在提供されているmillviのサービスは、実は10年以上も前から稼働しており、様々な制約や技術的負債を抱えながら今日までサービスを継続してきました。

そのため、そういった技術的負債を減らし、より大規模・高品質の配信サービスを提供していくために、数年前からmillvi開発チームでは基盤技術を刷新するべくリプレイスを進めてきました。
(以下、移行前バージョンを「v2」、移行後バージョンを「v3」とそれぞれ呼ぶことにします。)

そこで今回は、v2の利用顧客のデータをv3に移行するための移行システムで利用することになったAWSの比較的新しいサービスを紹介していきたいと思います。

Step Functions

Step Functionsは複数の細かなステップを繋ぎ合わせたり、ステップの実行結果に応じて後続処理を分岐できたりと、サーバーレスでマイクロサービスを構築するのに打って付けのサービスです。

移行システム内では、「v2のDBからデータを抽出する処理」「v3のAPIを用いてデータを登録する処理」といったように細かく分割した処理をAWS Lambda関数上に実装し、それらのLambda関数を順番に実行させるようにStep Functionsで繋ぎ込む、というように利用することにしました。

Step Functionsを利用する上で個人的に最も魅力を感じた点は、Step Functionsのステップの順番を変えたいときに、AWSコンソール上でGUI操作で簡単に編集できる点です。
例えば、1つのLambda関数の検証が終わったら、次のLambda関数を追加して検証してみる、といったように柔軟に動作確認を行うことができ、非常に使いやすいです。
step_functions_edit.gif

また、Step FunctionsにはMapという並列同時実行を行うための機能があったのですが、最大40件という制限がありました。
しかし、re:Invent 2022で分散マップという新たな機能が発表され、最大同時実行数が1万件に激増しました。

millviには数十万件のコンテンツを抱えている顧客もおり、そのような大量のデータを移行する際にこの分散マップを利用することで、メモリに制限があるLambda関数でも問題なく実行できます。

EventBridge Pipes

EventBridgeは、AWSを含む様々なサービスやアプリケーション同士を『イベント』を介して連携できるようにする、イベント駆動型アーキテクチャを構築するためのサービスです。

EventBridgeの基本的な利用方法については、他の記事に譲ることとし、ここではStep Functionsの分散マップと同じくre:Invent 2022で発表されたEventBridge Pipesについて紹介していきます。

AWS公式ページには、EventBridge Pipesの特徴として以下のような記載があります。

Amazon EventBridge Pipes は、イベントプロデューサーとコンシューマ間のポイントツーポイント統合を、オプションのトランスフォーム、フィルター、エンリッチステップで作成することができます。
EventBridge Pipes は、イベント駆動型アプリケーションを構築する際に必要な統合コードの記述とメンテナンスの量を削減します。

...？？🤔

おそらくここだけ読んでもイメージしにくい方が大半だと思うので、具体的なユースケースに沿って説明します。

例えば、DynamoDBストリームをイベントソース、Lambda関数をターゲットとするアプリケーションを考えます。
ここでは、当該DynamoDBテーブルのstatusという属性が、PROCESSINGからDONEに変更されたことを条件に何らかの処理をLambda関数で実行することを考えます。

Lambdaと直接連携する場合

EventBridge Pipesを介さずにLambda関数に接続した場合、イベントソースであるDynamoDBからは以下のようなデータがパラメータとして渡されます。

event
{
  "eventID": "2",
  "eventVersion": "1.0",
  "dynamodb": {
    "OldImage": {
      "Status": {
        "S": "PROCESSING"
      },
      "Id": {
        "N": "101"
      }
    },
    "SequenceNumber": "222",
    "Keys": {
      "Id": {
        "N": "101"
      }
    },
    "SizeBytes": 59,
    "NewImage": {
      "Status": {
        "S": "DONE"
      },
      "Id": {
        "N": "101"
      }
    },
    "StreamViewType": "NEW_AND_OLD_IMAGES"
  },
  "awsRegion": "us-west-2",
  "eventName": "MODIFY",
  "eventSourceARN": "arn:aws:dynamodb:us-east-1:111122223333:table/EventSourceTable",
  "eventSource": "aws:dynamodb"
}

ここで問題となるのはLambda関数の実行頻度とコスト管理です。
Lambda関数の課金メトリクスは実行回数と処理時間の2つです。

そのため、アプリケーションの利用が増え、条件に合致しないDynamoDBテーブルの更新が増えるほど、Lambdaの課金額が増えることになってしまいコスト効率が悪化することになります。

こんなときに利用すると嬉しいのが、EventBridge Pipesです。

EventBridge Pipesを介してLambdaと連携する場合

まず、EventBridge Pipesにはイベントソースが発行したイベントを、定義したパターンに合致したものだけフィルタリングすることができます。
パターンを入力する箇所に以下のようなJSONを定義すると、上記の条件に合致するイベントでのみターゲットのLambda関数が実行されます。

pattern
{
  "dynamodb": {
    "OldImage": {
      "Status": {
        "S": ["PROCESSING"]
      }
    },
    "NewImage": {
      "Status": {
        "S": ["DONE"]
      }
    }
  }
}

この機能を使えば、条件に合致しないLambdaの起動を抑えられるだけでなく、EventBridge Pipesの料金はフィルター後のリクエスト数に応じて課金されるため、上手に活用すればコスト効率を大きく高めることができると思います。

S3 Batch Operations

S3 Batch Operationsは、S3に保存されている大量のオブジェクトのコピーやタグの更新、Lambda関数の呼び出しといった操作を一括で行うことができる、S3を扱うエンジニアにとってとても嬉しい機能です。

millviでは顧客がアップロードした動画などのファイルや、ストリーミング用に変換されたファイルがS3に大量に保存されており、v3への移行の際はそれらをv3用のバケットに移行する必要があるため、大変便利です。

また、一括処理と謳っている通り、処理速度も速く、Lambdaを介して他のS3バケットにコピーする操作を行ったところ、500件のオブジェクトが合計約13GBで、30秒もかからずにジョブが完了するという迅速さでした。

まとめ

ここまで、millviの移行システムで利用するAWSの比較的新しいサービスや機能を紹介してきました。

AWSはこれまでも多くのクラウドサービスを提供してきていますが、ビジネス環境やITに関する技術の流行が目まぐるしく変化する今日においても、未だに進化を続けています。

この進化に置いていかれないためにも、こまめにAWSブログを読むなどして、情報をアップデートしていくことが大切だなと感じました。

Discussion