[レポート] コンテナとサーバーレスアプリケーション向け AWS ストレージ #STG303-R #reinvent

アノテーション テクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

最新のアプリケーションは、アプリケーション アーキテクチャに革命をもたらしました。 開発者は、コンテナを使用して移植性を高めたり、サーバーレス インフラストラクチャでアプリケーションを構築してコンピューティング リソースを最適化したりできるようになりました。 このセッションで、Amazon EFS、Amazon S3、Amazon EBS などのさまざまなストレージ サービスについて学び、最新のアプリケーションに最適なストレージを決定するのに役立ててください。

セッション動画

セッション資料

AWS storage for containers and serverless applications

アジェンダ

• サーバーレス アプリケーションとモダンなアプリケーションの概要
• Amazon EFS によるアプリケーションのモダン化
• イベント駆動型およびサーバーレス アーキテクチャ向けの Amazon S3
• まとめ

サーバーレス アプリケーションとモダンなアプリケーションの概要

はじめに

最初に、アジェンダと概要を確認します。今日このセッションでカバーする内容の、何よりもまず、アプリケーションがモダンなアプリケーションである理由について、お伝えします。（アプリケーションのモダン化） 次に、キーとなるストレージサービスについて説明します。サーバーレスやモダンなアプリケーションをサポートする主要なストレージサービスである Amazon EFS と S3 について具体的に説明します。 最後に、セッションの内容をまとめて、お客様事例を紹介します。 以前はデータセンターに根ざした世界がありました。アプリケーションを設計やデプロイするとき、基本的にコンピュート、ストレージ、ネットワークリソースから構成されるインフラストラクチャスタックの上に配置されていました。それらはすべて、モノリシックなアプリケーションスタックの中で緊密に結びついていました。 現在はマイクロサービスや疎結合なアーキテクチャが主流になりつつあります。これにより、柔軟性と拡張性が向上します。しかし、モダンなアプリケーションも時代遅れになる可能性があるため、継続的なイノベーションやデプロイ、モダン化が重要だということも説明します。 AWS では、Amazon.com の豊かな遺産の恩恵を受けています。そして、現在お客様が利用しているサービスの多くは、そこから生まれています。 例えば、ファイングレインアクセス（きめ細かなアクセス制御）やイベント駆動型プログラミングモデル、プログラムによるガバナンスなど、Amazon.com から得られた知識や技術が利用されています。 最後に、アプリケーションをモダン化する理由を説明します。単純にクールだから、だけでなく、効率やスケーラビリティが向上し、企業のニーズに適応できることが大きな理由です。

アプリケーションをモダン化する理由

みんながやっているからではなく、お客様に利用していただくための利点があります。特に、経済的価値を高めることができます。運用オーバーヘッドを削減し、コストを節約できます。アプリケーションの負担も軽減できます。 データセンターを持つ企業は、未来への計画やインフラストラクチャ設計に課題を抱えています。オーバープロビジョニングとアンダープロビジョニングは常に問題です。過剰にプロビジョニングすると無駄が多くなるし、過小にプロビジョニングすると顧客ニーズに応えられない可能性があります。 アジリティ（俊敏性）が重要になってきます。例えば先日、Amazon.com のブラックフライデーやサイバーマンデーなどの大規模イベントがありました。事前に十分なリソースをすべて用意し、イベントに対応できるようにするのは、無駄が多いです。拡張や収縮の能力、そして環境のニーズに応じてスケールするオンデマンドサービスを提供することが、モダンなアプリケーションインフラストラクチャにおいて、非常に重要になります。インフラストラクチャに焦点を当てる考え方から、アプリケーション自体に焦点を当てるという考え方に移行できます。こうして、製品のインフラストラクチャよりも開発に時間を費やすことができます。

Amazon EFS によるアプリケーションのモダン化

モダンなアプリケーションには耐久性のある共有ストレージが必要

インフラストラクチャをモダナイズする場合、ストレージに関連する非常に重要なコンポーネントがいくつかあります。 第一に、ストレージは利用可能である必要があり、耐久性が高い必要があります。インフラストラクチャをモダン化する場合、ストレージに関して、いくつかの重要なコンポーネントがあります。 現在、すべてのコンピューティングリソースにステートフルアプリケーションが必要なわけではありません。 一方で、ステートレスアプリも多く、データは一時的かもしれないし、寿命が短いかもしれないけど、長時間実行されるアプリケーションでは耐久性のあるストレージインフラストラクチャが必要です。 コンピューティング面では、高スケール性が求められることが多く、数十、数百、数千のコンピューティングノードが存在することがあります。これらのノードは単一のストレージリソースを利用し、リソースを共有する必要があります。さらに、スケーラビリティが非常に重要です。 モダンなアプリケーションを設計する場合、ビッグデータワークロードをサポートするだけでなく、分散システムも考慮しなければなりません。 Kubernetes や ECS プラットフォームのコンテナで実行されるものもあります。 Amazon EFS は、そんなストレージサービスの1つとして紹介されています。EFS は何年も前からあり、開発者がクラウド対応のファイルシステムソリューションを作ろうとしたとき、クラウド時代に適したストレージソリューションが存在することが大切な目標でした。 インフラストラクチャをモダン化する際には、利用可能な耐久性の高いストレージ、分散システムを考慮したコンピューティング、スケーラビリティ、そしてクラウド対応のストレージソリューションといった要素に気をつけるべきです。

AWS 開発者のためのファイルストレージ

オーバープロビジョニングやアンダープロビジョニングが問題となる場合でも、ストレージがアプリケーションやエンドユーザーのニーズに対応できると仮定してみましょう。EFS ファイルシステムでは、データを追加すると容量が拡大し、データを削除すると縮小します。これにより、使用した分だけ課金されるため、コスト効率が良くなります。 耐久性とデータの可用性も重要であり、お客様は S3 の イレブンナイン の耐久性を当然のこととして受け入れるようになりました。可用性の観点からは、リージョン内の複数のアベイラビリティゾーンが非常に重要になります。それに伴い、EFS はこれらの機能を提供しています。 モダン化においても、EFS はコンピューティングの基盤となりうるでしょう。これは、お客様がモノリシックなアーキテクチャからマイクロサービスへ移行し、コンテナサービスやサーバーレス機能を利用し始めるからです。また、Amazon Fargate や Lambda といったプラットフォームも活用されます。 パフォーマンスはアプリケーションにとって重要であり、 EFS チームの開発者は、プラットフォームのスループットと IOPS を向上させながら、 レイテンシを削減するために継続的に最適化することに常に懸命に取り組んできました。 コスト面では、EFSで使用した分だけ支払えば良いと述べましたが、約1年前にインテリジェントな階層化が導入され、ストレージがさらに効率化されました。エンドユーザーであろうとなかろうと、データは自動的に低コストのストレージに移動されます。また、データが再びアクセスされると、自動的にスタンダード層に昇格します。これにより、パフォーマンスとコストのトレードオフを常に最適化しています。 データセンターからクラウドへの移行を考えるお客様にとって、EFS は効率的なストレージソリューションを提供しており、モダンなアプリケーションやコンピューティング環境に適応できるでしょう。

今日のリフト＆シフトでモダン化を加速

ステップ1は、クラウドでデータを取得することです。モノリシックアプリケーションはオンプレミスからクラウドへ移行し、コンピューティングリソースとしてEC2インスタンスを利用します。EFSを使用することで、モダナイズと移行が簡単になります。ECS、EKS、Fargate、Lambdaなどのサーバーレステクノロジーやコンテナ戦略に移行できます。 EFSは素晴らしいソリューションで、継続的なイノベーションと近代化に非常に適しています。アプリケーションをコンテナ化して運用上のオーバーヘッドを減らし、デプロイを簡素化し、効率的なインスタンスサイズとスケーラビリティを実現します。EFSを使用すると、コンテナ間でストレージを永続化し、共有ストレージや永続ストレージが必要なワークロードも移行できます。 EFSは、ファイルベースのワークロードに対応するために設計されており、特にスケーラブルなデジタルエクスペリエンス、機械学習の推論、メディア処理の3つのユースケースで強みを発揮します。コンテナテクノロジー、サーバーレステクノロジー、EFSを組み合わせることで真価を発揮します。 例えば、スケーラブルなデジタルエクスペリエンスは、デジタルコンテンツをエンドユーザーに提供するために作成、編集、変更するものです。これには多層的なWordPressやDroopalなどのデータベースをバックエンドに持つものや、静的なWebサイト、GhostやHugoで作成されたものなどが含まれます。挑戦は、コンテンツをユーザーに届ける方法を見つけることです。インフラストラクチャは、ユーザーが大量に増えることにも対応し、できる限りシームレスに移行できるように構築します。 まとめると、EFSはクラウド移行やモダナイズに優れたストレージソリューションであり、柔軟でスケーラブルなデジタルエクスペリエンス、ML推論、メディア処理などのユースケースで真価を発揮します。ECSやEKSなどのサーバーレステクノロジーやコンテナ戦略と組み合わせて、効果的にデータ管理とアプリケーション運用を行うことができます。

スケーラブルなデジタル エクスペリエンスの構築

管理できるたくさんのインスタンスにユーザーの負荷を分散させることで、アクセス可能なコンテンツが増えます。回復力が高く、異なるAZにデプロイされるインスタンスは、スケーラビリティと柔軟性を提供します。EFS Standard はリージョンをサポートしているため、コンテナインスタンスはすべて簡単にマウントできます。 更新されると、同じファイルシステムにアクセスし、そのファイルシステムを利用します。1つのリージョンで更新を行うだけで、同じファイルシステムにアクセスしているすべてのコンテナが、変更内容を確認できるようになります。このワークロードをサポートするデータベースとしてAurora Serverlessが選ばれました。これにより、インフラストラクチャに悩むことなく完全なプラットフォームが提供されます。 AmazonはECSやEKSを使ったコンテナオーケストレーションを管理しており、Fargateを通じてコンピューティングを管理しています。EFSはすべてのストレージインフラストラクチャを処理し、Auroraがデータベースを処理します。これにより、開発者チームは最適なアプリケーション構築に専念できます。 システムからユーザーにコンテンツを取得する方法として、ECSとEKSがあります。それぞれのプラットフォームについて、少し詳しく説明しましょう。

動的プロビジョニングを使用して Amazon EFS を Amazon EKS ポッドにアタッチする

どのようにコンテナの数がわからないスケーラブルなアプリケーションを採用するか？ EKSでは、バックエンドの永続ストレージにEFSを用いることで、スケーラブルなコンテナ用のストレージが実現されます。このため、コンテナストレージインターフェース(CSI)ドライバが導入されます。永続ボリューム要求を作成することが、EKSでの最初のステップです。 CSIドライバは、EFS上にアクセスポイントを作成し、これを永続ボリュームにマッピングし、顧客に返します。顧客は永続ボリュームをアプリケーション内で使用できます。各アクセスポイントには、一意のIDとルートディレクトリが付与されるため、アプリケーションデータが非公開に保たれます。 これで、Kubernetesベースのアプリケーションを必要なだけスケールすることができますし、必要な数のAZにまたがり、背後の共有ストレージにアクセスできるようになります。 Acquiaという企業は、このようなセットアップを使用して、Webホスティングプラットフォームをモダナイズしている好例です。彼らはEKSをコンピューティングに、EFSを永続ストレージに用いることで、インフラストラクチャのオーバーヘッドと管理のオーバーヘッドを削減し、コスト節約と顧客体験の向上に成功しています。 EKSはオーケストレータであり、コンテナ化されたアプリケーションを実行し、CSIドライバを使ってファイルシステムに接続し、アプリケーションの全体にわたってEFSによって提供されます。ただし、ECSではCSIドライバが不要であり、プロセスが若干異なります。

Amazon EFS を Amazon ECS にアタッチする

EFSとECSはどちらもAmazon製品です。これら2つを統合する外部メカニズムは不要で、直接行える。ECS側で最初にクラスターをセットアップする。種類は問題じゃない。EC2インスタンスかLinux、WindowsのFargateインスタンスでもいい。クラスタ立ち上げ後、セキュリティグループを作成し、インバウンドを許可する。ポート2049で、特定のサブネットに分離もできます。 セキュリティグループ設定後、EFSコンソールで実際のファイルシステムを作成し、ECS Standardリージョナルサービスを立ち上げる。これらを結び付けるためのタスク定義がECSで使われる。タスク定義作成後、それらを結び付ける。ボリュームからEFSのファイルシステムIDやマウントポイントを取得して組み合わせる。UIからもYAML出力からもできます。 例としてAstraZenecaとNvidiaがあり、彼らはリアルタイム計算創薬プロセスを実現したかった。コンテナレベルや個々のタスクレベルで実行し、コンピューティングレイヤーでECSスケーリングし、EFSスケーリングとサポートでストレージを実現した。EFSの使用例には他に機械学習の推論やメディア処理もあります。ECSの代わりにEKSやLambdaを使ってEFS機能を活用する方法もあります。

AWS Lambda の Amazon EFS

お客様がEFSを共有ストレージとして使い、サーバレスアプリを作る理由についてまとめます。 たとえば、なぜお客様はLambda関数に永続的なストレージを必要とするのか疑問に思うかも知れません。この理由にはいくつかのポイントがあります。 まず一つ目、EFSはペタバイト規模のストレージが提供されるため、Lambda関数と直接結びつけることができます。これは大事なことです。なぜなら、Lambda関数内では一定量のスペースが制限されており、それを超えるデータセットを扱うことができません。EFSはその制限を解消し、関数でデータを読み込むために必要なだけのストレージを提供します。 また、関数の状態を保存しておくこともあります。これにより、処理の終わりに状態を保存し、次の処理開始時にその状態を読み込むことができます。その結果、お客様はイベントドリブンインフラストラクチャ上にステートフルなアプリケーションを作ることが可能になります。 さらに、EFSは低レイテンシーを提供し、使った分だけ支払うことができます。これによって、Amazonがインフラコストを処理し、お客様がステートフルなアプリケーションを構築することができます。そして何万回もの関数呼び出しでデータを共有することが可能になります。 このような理由から、お客様はEFSを背後に持つサーバレスアプリケーションを構築しているのです。

柔軟な機械学習の推論

これは、顧客が中国語の標識の画像をアプリケーションに送信し、画像からテキストを抽出して返す例です。これは機械学習の推論の1つの一般的なアプリケーションで、お客様がLambdaでモダナイズしています。推論部分は、機械学習のリアルタイム部分で、履歴データを使ってモデルを構築し、そのモデルを新しいユーザーやイベントに使用します。 まず、構築されたモデルを取得し、EFSにロードします。これは関数に提示されたEFSです。次に、クライアントが画像をアップロードしてユーザーリクエストを発行すると、関数が表示されます。そのアップロードによりLambda関数がトリガーされ、EFSからモデルが読み込まれ、予測が実行されます。テキストを抽出し、ラベルを予測して顧客に返します。 EFSとLambdaは完全にスケーラブルであり、推論のユースケースに非常に魅力的です。必要なだけ大きなモデルを使用できるだけでなく、予測を実行していない場合やモデルを実行していない場合、お金を払う必要はありません。お金を払うのは、実際に使用している場合だけです。 では、これらのモデルを可視化するにはどうすればよいでしょうか？モデルはEFSにあり、EFSにロードする方法を知っていますが、Lambda関数に表示するにはどうすればよいでしょうか？

Amazon EFS を AWS Lambda にアタッチする

LambdaではEFSと異なる方法でセキュリティグループを使用する。まずEFSでファイルシステムを作成する。次に、Lambdaのコンソールでアクセスポイントを作成する。これにより、アプリケーション固有のエントリポイントが提供されることで、ファイルシステムデータにアクセスできます。 アクセスポイントを利用すると、インバウンド接続のIDを強制することで権限エスカレーションを防ぐことができます。これは、サーバーレス関数で特に役立つもので、POSIX IDの第一級の概念がない場合でも適用できます。 次に、Lambdaコンソールを使って関数を作成すると、EFSファイルシステムとセキュリティメカニズムを持つことになる。コンソールから、作成したEFSファイルシステムとアクセスポイントを取り出し、関数に接続する。 これにより、関数が実行されるたびに、バックエンドのストレージにアタッチメントする機能を持つ。ファイルシステムのプロビジョニング、アクセスポイントの作成、関数への接続により、Lambdaの異なる一連の機能をレイテンシが低い理由で解除する。 この機能は、スケーラブルで高性能なストレージを背面に持つ。現在この機能を使用している顧客はAsurionです。

ML 推論: Asurion は、Amazon EFS を使用してリアルタイムの機械学習を強化します

Asurionは家電製品のサービス契約を結び、顧客サービスが重要な役割を果たしています。通話録音をモデル化して、スタッフのフレンドリーさや熱意、顧客サービスの質を確認したかった。ただ、通話録音が大きすぎて、標準の一時ディレクトリに収められなかったり、通話量が1日を通じて変わってしまう問題がありました AsurionはLambdaを使いたかったので、従量制の環境を実現したいと考えていた。そこで、バックエンドにEFSを導入して、高性能ストレージを提供し、Lambda側のストレージ制限を解決した。これにより、求めていた従量制モデルが構築できた。 また、彼らのMLインフラストラクチャは、画像処理にも簡単に拡張できるようになった。このように、AsurionはEFSとLambdaを活用して、通話録音や通話量の問題を解決し、顧客サービスの品質向上に役立てることができた。

サーバーレス: SkyWatch は AWS Lambda と Amazon EFS を使用して衛星画像を処理します

SkyWatchでは、衛星画像が大きく処理が困難で、Lambdaの一時空間に収まらず、処理時間も遅かった。しかし、EFSを導入することで、複数の画像を並行処理できるようになり、処理パスのレイテンシも大幅に短縮できた。EFSの効果で大きなイメージと関数の課題がうまく解決された。 EFSに関するセッションの締めくくりには、コンテナ化されたサーバーレスアプリケーションの開発に関連する3つのカテゴリのユースケースについて説明した。それらはスケーラブルなデジタル体験、機械学習の推論、メディア処理についてだった。 そして、EFSの代わりにS3の使用方法について説明することになった。イベントドリブンアプリケーションに関する話題に移り、Heeki Parkが登場した。彼はAWSのスペシャリストソリューションアーキテクトで、2年半以上サーバーレスアーキテクチャ構築の支援に専念しています。 イベントドリブンアプリケーションについて、ガバナンスやガードレール、セキュリティモデル、開発者ツールチェーンをどう考えるか、そして開発者のエクスペリエンスについて話した。最後に、S3とイベント駆動型アーキテクチャの関連性を説明した。

イベント駆動型およびサーバーレス アーキテクチャ向けの Amazon S3

Amazon S3 でスケーラブルなサーバーレス アプリケーションを構築する

多くのお客様が大規模なアプリケーションを構築する際に、従来のモデルを利用し、リレーショナルデータベースやデータウェアハウスにデータを格納していることが多い。コンピューティングレイヤーをデータに持ち込むことで、例えばJavaベースのアプリケーションでは、ODBCやJDBC接続を用いてリレーショナルデータベースにアクセスし、クエリを実行してデータを抽出し、処理することが一般的だった。 しかし、現在はS3などの環境が存在し、データがS3バケット内に格納されることがあり、またイベントや通知が発生することがあります。例えば、画像処理アプリケーションで新しい画像がバケットに格納された場合、従来ではバッチジョブを一晩かけて処理することが一般的だった。 しかし、イベントや通知をリアルタイムで取得できる仕組みがあれば、すぐに対応することが可能になる。S3バケットにオブジェクトが追加されたことを通知し、「何か処理を行いたいか？」と問いかけられるような仕組みがあると、Lambda関数をトリガーしてすぐに画像処理などの計算を行うことができます。 このようなイベント通知により、お客様はリアルタイムに処理を実行することができるようになる。実際、S3からは毎日約1,310億件のイベントが発生していて、それらに対応するための活動が繰り返されています。 S3イベント通知を活用することで、データ処理をより効率化し、リアルタイムに対応できるようになるため、多くのユースケースで役立つことが期待される。ただし、イベント通知をうまく活用するためには、それに対応する具体的な処理方法を考える必要があります。

Amazon S3 イベント通知

イベント通知では、少なくとも1回イベントが配信されることを考慮しましょう。開発者は重複イベントを処理できるようにする必要があります。例えば、putオブジェクトイベントにネットワークの問題があった場合、ダブル配信されるかもしれない。だから、開発者は、同じイベントが2回実行されても問題ないようにする必要があります。 配送先には、SQS（Simple Queue Service）、SNS（Simple Notification Service）、Lambda関数などがあります。SQSはアプリケーション間の分離メカニズムとして使用され、大量のイベント通知を処理できます。一方、SNSはダウンストリーム通知とファンアウトのメカニズムです。そして、Lambda関数は、イベント通知に対して異なる機能を実行することができるツールです。 このようなシステムの構成方法にはいくつかの方法がありますが、いずれも重複イベントの処理や大量のイベント通知を効率的に扱うことができるようになります。

Amazon S3 イベント通知の設定

S3イベント通知は、バケット内の特定のイベントが発生した際に通知を受け取るのに役立ちます。イベント通知を設定することで、異なるパラメーターに基づいて構成が可能です。 例えば、ある特定のプレフィックスがあるS3バケット内に新しい画像が追加された場合、Lambda関数を呼び出すことができます。このようなイベント通知は、PutEventやPutObjectなど、特定のイベントに関連するものに限定できます。 また、異なる監査機能に対応するため、コピー・削除操作も設定できます。「Lambda関数」を選択し、既存のLambda関数やARN（Amazonリソースネーム）を使用することができます。 さらに、アプリケーションやドキュメントリポジトリにも応用することができます。例えば、英語で書かれた多数のPDFドキュメントを持つ企業が、ビジネスのグローバル化に伴い、ドキュメントを複数の言語に対応させたい場合が考えられます。 このような場合、S3イベント通知を利用して、新しいドキュメントがアップロードされるたびに翻訳サービスを開始し、毎晩翻訳処理を行うことができます。これにより、翌日にはユーザーが必要とする言語のドキュメントを提供できるようになります。 まとめると、S3イベント通知を使用することで、S3バケット内で発生した特定のイベントに基づいて機能を実行し、アプリケーションやドキュメントリポジトリなどの様々な用途に応用することが可能になります。この機能を利用することで、効率的で柔軟なシステムを構築できるので、ぜひ活用してみてください。

ドキュメントをほぼリアルタイムで翻訳

この文章は、Lambda関数を使ってAmazon翻訳サービスをトリガーし、多言語の翻訳をサポートするシステムについて説明しています。翻訳サービスを使ってテキストドキュメントを作成し、それを新しい言語でPDF形式でS3バケットに保存します。このシステムでは、複数の言語でドキュメントをほぼリアルタイムで作成することができます。 また、組織として考えられるシナリオとして、数千件の請求書や顧客への通知を処理することが挙げられます。復元力のあるアーキテクチャを持ち、API制限や障害シナリオを処理できるシステムが求められます。 イベントドリブンアーキテクチャを使用し、キューを活用してLambda関数を使った処理を行います。Amazon S3バッチバケットを使って大量のドキュメントを処理し、翻訳イベントトリガーによってSQSキューを使用してタスクを分散させます。 Amazon翻訳では、API制限に従うためにキューを使って作業を管理し、翻訳関数を実行します。翻訳されたPDFはS3バケットに格納され、一部のメタデータはDynamoDBテーブルに書き込まれます。ダッシュボードを使ってリアルタイムの更新を見ることができます。 失敗したタスクはデッドレターキューに入れられ、後で処理されるか、特定のドキュメントに問題があるかどうか調査できます。組織として実行したいビジネスワークフローは、AWS Step Functionsを使ってステートマシンとしてモデル化されます。 要約すると、このシステムは、Lambda関数とAmazon翻訳サービスを利用して、多言語のドキュメントを効率よく作成し、S3バケットに保存するものです。また、復元力のあるアーキテクチャを持ち、障害シナリオを処理できるように設計されています。さらに、イベントドリブンアーキテクチャを使い、キューを活用してタスクを分散させることで、スムーズに処理が行われます。また、ダッシュボードを使って進捗状況を確認することができ、ビジネスワークフローはAWS Step Functionsを使ってモデル化されています。

スケーラブルなビジネス ワークフローの自動化

それでは、ビジネスタイプのオーケストレーションを行うために使用するのは、Step Functionsについて説明する。例として、S3バケットに何らかのアーティファクトを入れ、Lambda関数を使ってStep Function実行ワークフローをトリガーすることが挙げられる。このケースでは、画像やその他のタイプの画像がアップロードされることになり、ディサイダー関数でその画像を取得後、Amazon Rekognitionサービスが呼び出されるかもしれない。Rekognitionサービスは、いくつかの機械学習モデルを作成して画像のメタデータを抽出し、猫や犬などの動物が写っているか判断することができるので、特定の画像が猫が写っているかどうかを調べることができます。 この決定された関数はイエスかノーの単純な応答を行い、ビジネスロジックに基づいて猫の画像が含まれている場合は一致関数に移動する。猫がいる場合は適切なビジネスロジックが実行され、そうでない場合には他のビジネスロジックが用意されています。また、エンドユーザーに対して、猫が写っている写真がないと返答するかもしれない。 Step Functionsを使えば、選択ロジックや並列ロジックを実行できます。例えば、猫が写っているかの判断を行った後に、メタデータをDynamoDBデータベースに保存したり、小さなサムネイル画像に加工したりすることができます。そして、これらの処理を並行して実行してワークフローを進めることができ、シリアル方式で実行するよりもはるかに迅速に処理できます。 別の例として、コールセンターがあります。サポートコールの経験があるユーザーにアンケートを行ったとしても、Step Functionsの活用によって効率的なオーケストレーションが可能なイメージであります。これによって、ビジネスプロセスをスムーズに運用できるのです。

コール センターの録音の変換

サポートコールでは、通常「お待ちください。この通話はトレーニングとテストの目的で録音されます」というメッセージが流れます。サポートコールを録音しておいて、後で分析することがあります。例えば、録音された通話をAmazon S3に保存したり、AWS Lambda等のサービスを使って処理したりできます。 例として、S3バケットに通話録音がMP3ファイルとして保存されているとします。そして、Lambda関数がトリガーされて、音声ファイルをテキストファイルに変換することができます。この場合、AWS Transcribeサービスを使ってオーディオファイルをテキストドキュメントに変換できます。 トランスクリプションの出力を取得し、別のS3バケットに保存します。そして、その文字起こしにメタデータを添付し、例えば製品情報やユーザーの人口統計情報などを加えます。ここで、顧客が幸せだったのか怒っていたのかを理解しようとすることができます。 そのデータをDynamoDBテーブルに保存することもできます。ビジネスアナリストは、製品ID間で相関関係があるかどうかを調べることができます。例えば、過去30日間に特定の製品に対して500件の否定的なコメントがあったけれども、それ以前の6か月間では否定的ではなかったことが分かります。こうした情報をもとにワークフローや改善策を考えることができます。 要するに、サポート音声通話だけでなく、音声録音から価値を引き出すことがサーバーレスアーキテクチャを活用して可能になります。それにより、ビジネスの効率化や改善が図れるんです。今回はSNSについて話す機会がなかったけど、また別の話題として取り上げることができます。

サーバーレス アーキテクチャの簡素化

このアプリケーション間のシナリオでは、さまざまな処理が実行されており、Lambda関数だけでなく、SQSキューやトピックも含んでいます。サーバーレスアーキテクチャでは、これらの処理を単純化できます。Amazon EventBridgeというサービスが拡張性を高める。 EventBridgeはイベントルーターの役割を果たし、JSONオブジェクトやJSONスキーマを用いてイベントの転送先を制御する。要するに、イベントペイロード内の値に基づいてルーティングやフィルタリングが可能になる。 Amazon EventBridgeを利用することで、拡張性のある方法で処理を実現できます。複数のルールやターゲットを作成し、異なるターゲットに対して効率的にイベントを送信できます。SNSトピックと似た仕組みになっています。 実際には、イベント通知の設定で、EventBridgeセクションに進むことができます。ここで、JSONスキーマを構成し、イベントにプレフィックスを指定すると、それに基づいたターゲットでLambda関数が呼び出される。

多言語対応

できることの1つとして、さきほど話した内容を結びつける例を紹介する。イベントペイロードのサフィックスを調べたい場合があります。例えば、MP3ファイルの場合、音声録音かもしれない。S3バケットに入れたいと思っていて、転写アクションを実行したいと考えています。 その結果をJSONオブジェクトで受け取り、EventBridgeを使って別のイベントを送信する。次に翻訳を行い、他の言語にしたり、理解するために電話をかけたりするかもしれない。感情分析のためにルールベースのフィルタリングを行ってさまざまな活動をすることができます。 S3 Object Lambdaについても話しています。昨年発表され、PDFドキュメントをS3バケットに入れるシナリオを実行できます。Lambda関数を使って5つの言語に翻訳する。リアルタイムで行うので大規模なバッチ処理について心配しなくていい。ただし、ストレージコストが発生することを考慮しなくてはならない。 S3 Object Lambdaを使うと、Lambda関数でGETリクエストやHEADやLISTを呼び出せる。ここで、特定のPDFドキュメントを渡し、リクエストにヘッダーや情報が含まれる。これによって、Lambda関数でイベントペイロードを確認し、エンドユーザー向けの翻訳済みPDFを作成できます。 CSVファイルの例では、フィルタリングや承認チェックが行われるオブジェクトLambda関数を持ち、エンドユーザーが許可された部分だけを返すことができます。画像サイズ変更についても同様のことができます。

サムネイル生成やデータ編集などの作業をインラインで行うことができる方法を紹介します。以前お話ししたアプリを使うと、写真をS3バケットにアップロードし、サムネイル画像を作成するLambda関数を実行できるんです。これはトリガーに基づいて実行されますが、今回はオブジェクトLambdaをインラインで使う方法を紹介します。 データ編集も同じように行えます。例えば、CSVファイルには、個人情報やクレジットカード番号、電話番号、メールアドレスなど、公開したくないデータが含まれていることがあります。セキュリティ担当者は、違反がないかどうか確認するためにデータにアクセスする必要がありますが、そのオペレーターは実際には、個人情報や決済データを見る必要はないんです。そこで、データを編集して機密情報を置き換える方法があります。 基本的なアイデアは、アプリケーションがS3のエンドポイントに直接アクセスする代わりに、オブジェクトLambdaアクセスポイントにアクセスすることです。これは一種のアクセスポイントで、Lambda関数を呼び出すために使われます。これによってオブジェクトLambda関数が使えるようになります。 この手順は、まずS3アクセスポイントを作成し、次にLambda関数を作成するという段階的なプロセスです。開発者はコンソールや開発ツールを使って関数を作成し、環境にデプロイすることができます。その後、S3オブジェクトアクセスポイントを使ってアプリケーションを更新し、リダイレクトしてアクセスポイントを指すようになります。 これらの手順と類似した方法で他のユースケースにも対応できるんです。S3オブジェクトLambdaを活用している顧客がいろいろなケースを実現できるようになります。

Amazon S3 オブジェクト Lambda のユースケース

圧縮や解凍といった処理が重要だということについて話そう。例えば、画像やドキュメントファイルを扱う場合があります。顧客はモバイルデバイスを使用していることが多く、持っていないリージョンでも対応できるようになる。4G接続でデータ量を減らしたい場合もあります。 そんな時に、データをGETで圧縮してワイヤレス接続を介してネットワークで送信できることが重要。オーディオやビデオのトランスコーディングも考慮に入れること。 しかし、必ずしも大きなファイルをインラインで処理する必要はない。小さなオーディオファイルを送信して別のエンコーディングに変換したり、HLSビデオファイルの解像度を下げたりすることもできます。画像に基づいてインラインで実行できます。 カスタム認証や画像サイズの変更、透かしの追加なども行える。実際に、これら機能を利用した顧客もいます。 圧縮や解凍の重要性やそれを最小限に抑える手段、オーディオ/ビデオのトランスコーディングなどを考慮することが、顧客のニーズに応えるためにも有益。また、カスタム認証や画像のサイズ変更、透かしの追加といった機能も実装できるので、多くのユーザーに対応できます。

Amazon S3 オブジェクト Lambda を使用した Ryanair COVID-19 モバイルウォレット

繰り返しになるが、多くの人がパンデミックが進んでいることを喜んでいることを確信しています。2022年には少し楽になっています。航空会社を利用している人たちは、モバイルアプリケーションを使ってチケットを管理しています。ライアンエアーは、お客様がモバイルウォレットでワクチン接種証明書やPCR検査の陰性結果を管理できるようになった。 S3オブジェクトLambdaを使用して、モバイルアプリケーションで表示できるPNGファイルに変換することができます。彼らはもう少しキャッシングの練習をした。変換がすでに行われている場合は、変換済みのファイルを取得する。そうでない場合は、インラインで実行する。

まとめ

ストレージサービスの利用方法についてお伝えしました。 疎結合アプリケーションの構築方法やEFSのオプション、機械学習の推論やメディア処理などについてもお伝えしました。 EventBridgeを使ってイベント通知を行い、拡張性のあるアプリケーションを作成する方法も説明しました。 本セッションはストレージとサーバーレスに関する学習内容が盛りだくさんで、ワークショップや他の学習リソースも紹介しています。組織が構築に取り組んでいる場合は、ストレージ学習プランに参加することができます。また、サーバーレス学習バッジと、Skill Builderという成長する機会も提供しています。 疑問やユースケースについて話し合いたい場合は、事前に連絡してください。皆様からのお問い合わせをお待ちしています。

本セッションの内容に興味を持たれた方は、上部のリンクからセッション動画、セッション資料をご覧ください。