このガイダンスは、Twitter などのソーシャルメディアウェブサイトにおける、製品やサービスについてのお客様の意見を把握するのに役立ちます。Twitter データを手動で除外する代わりに、Twitter からのデータを利用し、Hugging Face Hub の事前トレーニング済みモデルを使用してツイートを分類する、ほぼリアルタイムのアラートシステムを構築できます。
アーキテクチャ図
ステップ 1
Amazon Elastic Container Service (Amazon ECS) タスクは、 AWS Fargate が管理するサーバーレスインフラストラクチャ上で実行され、Twitter API へのオープン接続を維持します。
ステップ 2
Twitter Bearer トークンは安全に AWS Systems Manager Parameter Store に保存され、コンテナイメージは Amazon Elastic Container Registry (Amazon ECR) でホストされます。
ステップ 3
新しいツイートが届くと、Amazon Simple Queue Service (SQS) キューに入れられます。
ステップ 4
ソリューションのロジックは、AWS Step Functions によって調整された AWS Lambda 関数のマイクロサービスにあります。
ステップ 5
Hugging Face の分類モデルは Amazon SageMaker サーバーレスエンドポイントでホストされています。
ステップ 6
Amazon Comprehend はセンチメント、キーフレーズ、エンティティを抽出します。可能であれば、Amazon Comprehend は位置情報を抽出します。
ステップ 7
Amazon Location Service はロケーション名を座標に変換します。
ステップ 8
ツイートとメタデータは Amazon Simple Storage Service (Amazon S3) に送信され、Amazon Athena は処理されたツイートを標準 SQL でクエリします。
ステップ 9
Amazon Lookout for Metrics は、カテゴリごとのメンション数の異常を検出します。Amazon Simple Notification Service (Amazon SNS) は、異常が検出されるとユーザーにアラートを送信します。
ステップ 10
ビジネスユーザーがインサイトを簡単に視覚化できるように、Amazon QuickSight ダッシュボードを設定することをお勧めします。
Well-Architected Pillars
AWS Well-Architected フレームワークは、クラウドでシステムを構築する際に行う決定の長所と短所を理解するのに役立ちます。フレームワークの 6 つの柱により、信頼性が高く、安全かつ効率的で、費用対効果が高く、持続可能なシステムを設計および運用するためのアーキテクチャのベストプラクティスを学ぶことができます。AWS マネジメントコンソールで無料で提供されている AWS Well-Architected Tool を使用し、各柱の一連の質問に回答することで、これらのベストプラクティスに照らしてワークロードを確認できます。
上記のアーキテクチャ図は、Well-Architected のベストプラクティスを念頭に置いて作成されたソリューションの例です。完全に Well-Architected であるためには、可能な限り多くの Well-Architected ベストプラクティスに従う必要があります。
-
運用上の優秀性
AWS CloudFormation テンプレートを使用して、アーキテクチャに加えられた変更をロールバックできます。Fargate と Lambda でデプロイが失敗した場合は、自動的に以前のバージョンにロールバックできます。
-
セキュリティ
このアーキテクチャをデプロイするには、サービスに対する適切な権限を持つ ID およびアクセス管理 (IAM) ユーザーまたはロールを設定する必要があります。さらに、Amazon S3 に保存されているデータは AWS Key Management Service (AWS KMS) キーで暗号化されます。
-
信頼性
データは、99.999999999% の耐久性を提供するオブジェクトストレージサービスである Amazon S3 に保存されます。データがビジネスクリティカルな場合は、S3 Cross-Region Replication (CRR) を実装して、ディザスタリカバリのために他の AWS リージョンにデータを複製できます。特定のしきい値を超える異常が発生すると、Amazon SNS からアラートが送信されるため、問題を迅速に解決できます。
-
パフォーマンス効率
AWS は、パフォーマンス効率を維持するために、パッチや更新などのマネージドサービスの管理タスクを処理します。Lookout for Metrics や Amazon Location などのサービスは、それぞれ異常の検出とアプリケーションへの位置データの追加を目的として特別に設計されています。
-
コストの最適化
このガイダンスでは、データの大部分が Athena と QuickSight を通じて AWS で直接消費されるため、データ転送料金が削減されます。Amazon SNS を介したデータ転送は、ユーザー定義のしきい値を超える異常が発生した場合にのみ発生します。さらに、このアーキテクチャではサーバーレスサービスを使用しているため、使用したリソースに対してのみ支払いが発生します。
-
持続可能性
サーバーレスサービスは使用状況に応じてスケールするできるため、需要の増加に対応するためにアイドル状態のインフラストラクチャを稼働させる必要はありません。
関連コンテンツ
Twitter、Amazon SageMaker、Hugging Face を使って、ニュースベースのリアルタイムアラートシステムを構築する
免責事項
サンプルコード、ソフトウェアライブラリ、コマンドラインツール、概念の実証、テンプレート、またはその他の関連技術 (私たちの担当者から提供される前述のものを含む) は、AWS カスタマーアグリーメント、またはお客様と AWS との間の関連文書契約 (いずれか該当する方) に基づき、AWS コンテンツとしてお客様に提供されるものです。お客様は、この AWS コンテンツを、お客様の本番アカウント、または本番データもしくはその他の重要なデータで使用すべきではありません。お客様は、サンプルコードなどの AWS コンテンツを、お客様固有の品質管理手法および基準に基づいて、本番グレードでの使用に適したテスト、セキュリティ確保、および最適化を行う責任を負います。AWS コンテンツのデプロイには、Amazon EC2 インスタンスの実行や Amazon S3 ストレージの使用など、AWS の課金対象リソースを作成または使用するための AWS 料金が発生する場合があります。