ゼファーネットのロゴ

生成的データ インテリジェンス

ビッグデータ

Amazon Redshift と Amazon API Gateway を使用してサーバーレス分析アプリケーションを構築する

プラトン再発行
プラトン再発行

日付：

閲覧数： 116

サーバーレス アプリケーションは、ビジネス部門とエンジニアリング チームの間で分析を実行する最新の方法です。 ビジネス チームは、Web アプリケーションを介してレポートを簡素化し、それをより多くのユーザーに配布することで、有意義な洞察を得ることができます。

ユースケースには次のものがあります。

  • ダッシュボード – 各コンポーネントが特定のビジネス部門に洞察を提供できるテーブルとグラフで構成される Web ページ。
  • レポートと分析 – 動的入力を使用して大規模な分析クエリをトリガーし、結果を表示またはダウンロードできるアプリケーション。
  • 管理システム – 社内のリソースとシステムの全体像を提供するアプリケーション。
  • ETL ワークフロー – 社内の個人が、動的入力を使用して使いやすい環境で特定の抽出、変換、ロード (ETL) ワークロードをトリガーできる Web ページ。
  • データの抽象化 – 基礎となるデータ構造とインフラストラクチャを切り離してリファクタリングします。
  • 使いやすさ – 各ユーザーをテクニカル プラットフォームにオンボーディングすることなく、分析へのユーザー制御アクセスの大規模なセットを提供するアプリケーション。 クエリの更新は組織化された方法で完了することができ、メンテナンスのオーバーヘッドは最小限に抑えられます。

この投稿では、を使用してサーバーレス分析アプリケーションを構築する方法を学びます。 Amazonレッドシフト データ API と アマゾンAPIゲートウェイ WebSocket および REST API。

Amazon Redshift は AWS によって完全に管理されているため、ハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、構成、障害から回復するためのノードとドライブの監視、またはバックアップなどのデータ ウェアハウス管理タスクについて心配する必要はありません。 の データAPI ドライバーを設定してデータベース接続を管理する必要がないため、Amazon Redshift へのアクセスが簡素化されます。 代わりに、Data API によって提供される安全な API エンドポイントを呼び出すだけで、Amazon Redshift クラスターに対して SQL コマンドを実行できます。 Data API は、データベース接続の管理とデータのバッファリングを処理します。 Data API は非同期であるため、後で結果を取得できます。

API Gateway は、開発者があらゆる規模で API を簡単に公開、維持、監視、保護できるようにするフル マネージド サービスです。 API Gateway を使用すると、リアルタイムの双方向通信アプリケーションを可能にする RESTful API と WebSocket API を作成できます。 API Gateway は、コンテナー化されたサーバーレス ワークロードと Web アプリケーションをサポートします。 API Gateway は、AWS が提供する多くのコンピューティング リソースへのリバース プロキシとして機能します。

イベント駆動型モデル

イベント駆動型アプリケーションは、顧客の間で人気が高まっています。 分析レポート Web アプリケーションは、イベント ドリブン モデルを通じて実装できます。 アプリケーションは、ユーザー アクションや予測できないクエリ イベントなどのイベントに応答して実行されます。 プロデューサ プロセスとコンシューマ プロセスを分離することで、アプリケーションの設計と分離されたプロセスの構築の柔軟性が向上します。 この設計は、Data API と API Gateway WebSocket および REST API を使用して実現できます。

REST API 呼び出しと WebSocket の両方が、クライアントとバックエンド間の通信を確立します。 REST の人気により、WebSocket が存在する理由と、それらがイベント駆動型の設計にどのように貢献するのか疑問に思うかもしれません。

WebSocket とは何ですか? なぜ必要なのですか?

分析 Web ソリューションを構築する場合、単方向通信が一般的です。 従来の環境では、クライアントは REST API 呼び出しを開始してバックエンドでクエリを実行し、クエリが完了するまで同期的または非同期的に待機します。 「待機」の側面は、次の概念を適用するように設計されています。 ポーリング. このコンテキストでのポーリングは、クライアントがバックエンド プロセスがいつ完了するかわからない場合です。 したがって、クライアントは一貫してバックエンドにリクエストを送信し、確認します。

ポーリングの問題は何ですか？ 主な課題は次のとおりです。

  • ネットワーク帯域幅のトラフィックの増加 – 空のチェックを実行する多数のユーザーは、バックエンド リソースに影響を与え、適切にスケーリングされません。
  • 費用の使用 – 空のリクエストは、ビジネスに何の価値ももたらしません。 リソースの不要なコストを支払います。
  • 遅延応答 – ポーリングは時間間隔でスケジュールされます。 これらの間隔の間にクエリが完了した場合、ユーザーは次のチェック後にのみ結果を確認できます。 この遅延はユーザー エクスペリエンスに影響し、場合によっては UI のデッドロックが発生する可能性があります。

投票の詳細については、こちらをご覧ください ポーリングからプッシュへ：Amazon API GatewayRESTAPIとWebSocketを使用してAPIを変換します.

WebSocket は、フロントエンドとバックエンド間の通信を確立する際の REST と比較した別のアプローチです。 WebSocket を使用すると、クライアントとサーバーの間に全二重通信チャネルを作成できます。 この双方向のシナリオでは、クライアントはサーバーに要求を行うことができ、プロセスが完了すると通知されます。 接続は、応答が受信されるまで最小限のネットワーク オーバーヘッドで開いたままになります。

WebSocket を使用して応答データを転送できるのに、なぜ REST が存在するのか不思議に思うかもしれません。 WebSocket は、システム間のリアルタイム メッセージング用に設計された軽量プロトコルです。 このプロトコルは、大規模な分析クエリ データを処理するようには設計されておらず、API ゲートウェイでは、各フレームのペイロードは 最大 32 KB を保持. したがって、REST API は大規模なデータの取得を実行します。

Data API と API Gateway を使用することで、データ分析のニーズに合わせて分離されたイベント駆動型 Web アプリケーションを構築できます。 API Gateway を使用して WebSocket API を作成し、クライアントとバックエンド サービス間の接続を確立できます。 その後、Data API を使用して分析クエリを実行するリクエストを開始できます。 Data API の非同期性により、クエリの完了によりイベントが生成され、WebSocket チャネルを介してクライアントに通知されます。 クライアントは、REST API 呼び出しを介してクエリ結果を取得するか、他のフォローアップ アクションを実行するかを決定できます。 イベント ドリブン アーキテクチャにより、システム コンポーネントにとらわれずに、双方向の相互運用可能なメッセージとデータが可能になります。

ソリューションの概要

この投稿では、バックエンドで Data API を使用してクエリを実行し、API Gateway の WebSocket 機能を使用してユーザーとバックエンドの間に双方向通信チャネルを確立し、次を使用して結果を取得することにより、サーバーレス イベント ドリブン Web アプリケーションを作成する方法を示します。その REST API 機能。 実行時間の長い API 呼び出しを使用してアプリケーションを設計する代わりに、Data API を使用できます。 Data API を使用すると、SQL クエリを非同期で実行できるため、長く永続的なデータベース接続を保持する必要がなくなります。

Web アプリケーションは以下を使用して保護されています アマゾンコグニートこれは、Web アプリを利用する前にユーザーを認証し、アプリケーションから行われたときに REST API 呼び出しを承認するために使用されます。

このソリューションに含まれるその他の関連する AWS サービスには、 AWSラムダ & アマゾンイベントブリッジ. Lambda は、サーバーのプロビジョニングや管理を行わずにコードを実行できる、サーバーレスのイベント駆動型コンピューティング リソースです。 EventBridge は、イベント駆動型アプリケーションの構築を可能にするサーバーレス イベント バスです。

このソリューションは、ブラウザーとバックエンドの間に軽量の WebSocket 接続を作成します。 ユーザーが WebSocket を使用してリクエストをバックエンドに送信すると、クエリが Data API に送信されます。 クエリが完了すると、Data API はイベント通知を EventBridge に送信します。 EventBridge は、データが利用可能であることをシステムに通知し、クライアントに通知します。 その後、クライアントが表示するクエリ結果を取得するために REST API 呼び出しが実行されます。

このソリューションは、 AWS サンプル GitHub リポジトリ この記事の残りの部分で参照します。

次のアーキテクチャ図は、自動的にプロビジョニングできるエンド ツー エンド ソリューションを示しています。 AWS CloudFormation テンプレートは、いくつかのパラメーター変数を使用してシェル スクリプトの一部として実行されます。

アプリケーションは次の手順を実行します (プロセス フロー内の対応する番号付きの手順に注意してください)。

  1. Web アプリケーションがプロビジョニングされている AWS 増幅; ユーザーは、サイトにアクセスするための電子メールとパスワードを提供して、最初にサインアップする必要があります。
  2. ユーザーは、電子メールに送信された PIN を使用して資格情報を確認します。 この手順は、ユーザーがアプリケーションにログインして、アプリケーションの他の機能へのアクセスを続行するために必須です。
  3. ユーザーがサインアップして検証されると、アプリケーションにサインインし、入力パラメーターを使用して Web またはモバイル クライアントからデータを要求できます。 これにより、API Gateway で WebSocket 接続が開始されます。 (フロー 1、2)
  4. 接続リクエストは Lambda 関数によって処理されます。 OnConnectこれは、Data API を使用して Amazon Redshift で非同期データベース クエリを開始します。 SQL クエリは、SQL スクリプトから取得されます。 Amazon シンプル ストレージ サービス (Amazon S3) クライアントからの動的入力。 (フロー 3、4、6、7)
  5. 加えて、 OnConnect Lambda 関数は、接続、ステートメント識別子、およびトピック名を Amazon DynamoDB データベース。 トピック名は、ユーザーが同じ Web ページに複数のレポートを実装したい場合に使用できる追加パラメーターです。 これにより、フロントエンドは応答を正しいレポートにマップできます。 (フロー 3、4、5)
  6. Data API は、手順 2 で説明したクエリを実行します。操作が完了すると、イベント通知が EventBridge に送信されます。 (フロー 8)
  7. EventBridge は、イベント ルールをアクティブにして、そのイベントを別の Lambda 関数にリダイレクトします。 SendMessage. (フロー 9)
  8. 　 SendMessage 関数は、API ゲートウェイ経由で SQL クエリが完了したことをクライアントに通知します。 (フロー 10、11、12)
  9. 通知を受信した後、クライアントは REST API 呼び出し (GET) を実行して結果をフェッチします。 (フロー 13、14、15、16)
  10. 　 GetResult 関数がトリガーされ、SQL クエリの結果を取得してクライアントに返します。
  11. ユーザーは Web ページで結果を表示できるようになりました。
  12. クライアントがブラウザから切断すると、API Gateway は、DynamoDB テーブルから接続情報を自動的に削除します。 onDisconnect 関数。 (フロー 17、18,19、XNUMX)

前提条件

イベント ドリブン Web アプリケーションをデプロイする前に、次のものが揃っていることを確認してください。

  • AWS 環境の Amazon Redshift クラスター – これは、分析クエリを実行するためのバックエンド データ ウェアハウス ソリューションです。 Amazon Redshift クラスターを作成する手順については、次を参照してください。 AmazonRedshiftの使用を開始する.
  • アクセスできる S3 バケット – S3 バケットは、SQL スクリプトを保存できるオブジェクト ストレージ ソリューションになります。 S3 バケットを作成するには、以下を参照してください。 最初の S3 バケットを作成する.

CloudFormation テンプレートをデプロイする

デザインに関連するコードは、次の場所にあります。 GitHubリポジトリ. 内のリポジトリを複製できます AWS クラウド9 AWS アカウントの環境。 AWS Cloud9 環境には AWSコマンドラインインターフェイス (AWS CLI) がインストールされ、CloudFormation テンプレートを実行して AWS インフラストラクチャをセットアップするために使用されます。 jQuery ライブラリがインストールされていることを確認してください。 これを使用して、スクリプトの実行中に JSON 出力を解析します。

完全なアーキテクチャは、XNUMX つの CloudFormation テンプレートを使用してセットアップされます。

  • cognito-setup.yaml – 認証と REST API の保護に使用される、ウェブアプリクライアントへの Amazon Cognito ユーザープールを作成します。
  • バックエンドセットアップ.yaml – 必要なすべての Lambda 関数と WebSocket および Rest API を作成し、API Gateway で構成します
  • webapp-setup.yaml – Amplify を使用して WebSocket および Rest API に接続および通信する Web アプリケーション ホスティングを作成します。

これらの CloudFormation テンプレートは、 スクリプト.sh 必要に応じてすべての依存関係を処理するシェル スクリプト。

独自の DDL SQL スクリプトと独自のクエリ SQL スクリプトをカスタマイズするための汎用テンプレートが提供されています。 従うためのサンプル スクリプトを作成しました。

  1. サンプル DDL スクリプトをダウンロードする それを既存の S3 バケットにアップロードします。
  2. IAM ロールの値を、アクセス許可を持つ Amazon Redshift クラスターの IAM ロールに変更します。 AmazonS3ReadOnlyAccess.

この投稿では、 ニューヨークのタクシーデータ 2015 パブリック S3 バケットからのデータセット。

  1. サンプル クエリ スクリプトをダウンロードする それを既存の S3 バケットにアップロードします。
  2. 変更したサンプル DDL スクリプトとサンプル クエリ スクリプトを、所有している既存の S3 バケットにアップロードし、S3 URI パスを書き留めます。

独自にカスタマイズしたバージョンを実行する場合は、シナリオに合わせて DDL とクエリ スクリプトを変更します。

  1. 編集 　 script.sh ファイルを実行する前に、次のパラメーターの値を設定します。
    • RedshiftClusterEndpoint (aws_redshift_cluster_ep) – Amazon Redshift クラスター エンドポイントは、 AWSマネジメントコンソール
    • DB ユーザー名 (aws_duser_name) – Amazon Redshift データベースのユーザー名
    • DDBTableName (aws_ddbtable_name) – 作成される DynamoDB テーブル名の名前
    • WebsocketEndpointSSMParameterName (aws_wsep_param_name) – WebSocket エンドポイントを格納するパラメーター名 AWS SystemsManagerパラメータストア.
    • RestApiEndpointSSMParameterName (aws_rapiep_param_name) – パラメータ ストアに REST API エンドポイントを格納するパラメータ名。
    • DDLScriptS3Path (aws_ddl_script_path) – アップロードした DDL スクリプトへの S3 URI。
    • QueryScriptS3Path (aws_query_script_path) – アップロードしたクエリ スクリプトへの S3 URI。
    • AWS リージョン (aws_region) – AWS インフラストラクチャがセットアップされているリージョン。
    • CognitoPoolName (aws_user_pool_name) – Amazon Cognito ユーザープールに付ける名前
    • ClientAppName (aws_client_app_name) – Web アプリがユーザーのユーザー認証を処理するように構成するクライアント アプリの名前

デフォルトの許容値は、ダウンロードしたコードの一部として既に提供されています。

  1. 次のコマンドを使用してスクリプトを実行します。
./script.sh

デプロイ中、AWS CloudFormation は Lambda 関数を作成してトリガーします SetupRedshiftLambdaFunction、Amazon Redshift データベース テーブルをセットアップし、テーブルにデータを入力します。 次の図は、このプロセスを示しています。

デモアプリを使用する

シェル スクリプトが完成したら、デモ Web アプリの操作を開始できます。

  1. Amplify コンソールの すべてのアプリケーション ナビゲーション ペインで、 デモアプリ.
  2. 選択する ビルドを実行する.

DemoApp Web アプリケーションは、プロビジョニング、ビルド、デプロイのフェーズを経ます。

  1. 完了したら、提供された URL を使用して Web アプリケーションにアクセスします。

次のスクリーンショットは、Web アプリケーション ページを示しています。 最小限の機能しかありません。サインイン、サインアップ、またはユーザーの確認ができます。

  1. 選択する 登録する.

  1. 電子メールID、電子メールを入力します。
  2. パスワード で、少なくとも XNUMX 文字の長さで、少なくとも XNUMX つの大文字と小文字、少なくとも XNUMX つの数字、および少なくとも XNUMX つの特殊文字を含むパスワードを入力します。
  3. 選択する 入学しよう.

　 デモ アプリへのログインを確認する ページが開きます。

  1. メールアドレスと、指定したメールアドレスに送信された確認コードを入力します。
  2. 選択する 確認します.


ログインページにリダイレクトされます。

  1. 資格情報を使用してサインインします。

にリダイレクトされます demoPage.html ウェブサイトをご覧ください。

  1. 選択する 接続を開く.

これで、ブラウザとバックエンド AWS 環境の間にアクティブな WebSocket 接続が確立されました。

  1. 旅行月、月 (この例では XNUMX 月) を指定し、 送信.

これで、データを照会する月と年が定義されました。 数秒後、WebSocket から配信された出力を確認できます。

追加のクエリにアクティブな WebSocket 接続を引き続き使用できます。別の月を選択して、 送信 再び。

  1. 完了したら、を選択します 接続を閉じる WebSocket 接続を閉じます。

探索目的で、WebSocket 接続がアクティブな間、DynamoDB コンソールの DynamoDB テーブルに移動して、現在保存されているアイテムを表示できます。 WebSocket 接続が閉じられると、DynamoDB に保存されたアイテムは削除されます。

クリーンアップ

リソースをクリーンアップするには、次の手順を実行します。

  1. Amazon S3 コンソールで、サンプル DDL スクリプトとクエリ スクリプトを含む S3 バケットに移動し、バケットからそれらを削除します。
  2. Amazon Redshift コンソールで、Amazon Redshift クラスターに移動し、サンプル DDL スクリプトからコピーしたデータを削除します。
    1. ラン truncate nyc_yellow_taxi;
    2. ラン drop table nyc_yellow_taxi;
  3. AWS CloudFormation コンソールで、CloudFormation スタックに移動して選択します 削除. 次の順序でスタックを削除します。
    1. WebappSetup
    2. BackendSetup
    3. CognitoSetup

このソリューションで作成されたすべてのリソースが削除されます。

監視

イベント ドリブンの Web アプリケーション イベント、ユーザー アクティビティ、および API の使用状況を監視できます。 アマゾンクラウドウォッチ & AWS クラウドトレイル. このソリューションのほとんどの領域では、既にログが有効になっています。 API Gateway ログを表示するには、次のことができます。 CloudWatch Logs をオンにする. Lambda にはデフォルトのロギングとモニタリングが付属しており、 CloudWatch でアクセス.

セキュリティ

開発者中心で費用対効果の高い顧客認証、承認、およびユーザー管理ソリューションである Amazon Cognito を使用して、アプリケーションへのアクセスを保護できます。 簡単にスケーリングできる ID ストアとフェデレーション オプションの両方を提供します。 Amazon Cognito は、ソーシャル ID プロバイダーと SAML または OIDC ベースの ID プロバイダーによるログインをサポートし、さまざまなコンプライアンス基準をサポートしています。 オープン ID 標準 (OAuth2.0、SAML 2.0、および OpenID Connect) で動作します。 API Gateway と統合して、Amazon Cognito クライアントアプリまたは Lambda 関数を使用して REST API 呼び出しを認証および承認することもできます。

考慮事項

このアプリケーションの性質には、Amazon Redshift への SQL クエリを初期化するフロントエンド クライアントが含まれます。 考慮すべき重要なコンポーネントは、SQL インジェクションなど、クライアントが実行できる潜在的な悪意のある活動です。 現在の実装では、それは不可能です。 このソリューションでは、SQL クエリは AWS 環境に事前に存在し、DQL ステートメントです (データや構造を変更しません)。 ただし、ビジネスに合わせてこのアプリケーションを開発する際には、これらのリスク領域を評価する必要があります。

AWS は、クラウド内のワークロードとアプリケーションを保護するのに役立つさまざまなセキュリティ サービスを提供しています。 AWSシールド, AWSネットワークファイアウォール, AWS ウェブ アプリケーション ファイアウォール、 もっと。 詳細と完全なリストについては、次を参照してください。 AWS でのセキュリティ、ID、およびコンプライアンス.

コスト最適化

このソリューションで CloudFormation テンプレートがプロビジョニングする AWS サービスはすべてサーバーレスです。 コストの最適化に関しては、使用した分だけお支払いいただきます。 このモデルでは、手動の介入なしでスケーリングすることもできます。 次のページを確認して、各サービスに関連する価格を確認してください。

まとめ

この投稿では、Amazon Redshift Data API と API Gateway WebSocket および REST API を使用してイベント駆動型アプリケーションを作成する方法を紹介しました。 このソリューションは、イベント ドリブン アーキテクチャでデータ分析 Web アプリケーションを構築し、アプリケーションを分離し、長時間実行されるデータベース クエリ プロセスを最適化し、クライアントとバックエンド間の不要なポーリング リクエストを回避するのに役立ちます。

また、サーバーレス テクノロジー、API Gateway、Lambda、DynamoDB、および EventBridge も使用しました。 このプロセス全体でサーバーを管理またはプロビジョニングする必要はありませんでした。

このイベント駆動型のサーバーレス アーキテクチャは、拡張性とシンプルさを向上させ、新しい機能の保守とリリースを容易にします。 新しいコンポーネントやサードパーティ製品の追加も簡素化されています。

この投稿の手順と、提供されている一般的な CloudFormation テンプレートを使用して、ビジネスに合わせて独自のイベント駆動型アプリケーションをカスタマイズできます。 フィードバックや貢献については、 AWS サンプル GitHub リポジトリ by 問題の作成.

著者について

デビッド・チャン は、グローバル金融サービスの AWS データ アーキテクトです。 彼は、サーバーレス分析インフラストラクチャ、データ管理、ETL、およびビッグ データ システムの設計と実装を専門としています。 彼は、お客様が AWS でデータ プラットフォームを最新化するのを支援しています。 David は、AWS カンファレンス、技術コンテンツ、オープンソース イニシアチブの活発な講演者であり、貢献者でもあります。 余暇には、バレーボール、テニス、重量挙げを楽しんでいます。 気軽に彼とつながろう LinkedIn.

マナッシュ・デブ AWS Directory Service チームのソフトウェア開発マネージャーです。 18 年以上のソフトウェア開発経験を持つ彼の情熱は、AWS ID およびデータ分析の分野で高度にスケーラブルで安全なメンテナンス不要のアプリケーションを設計および提供することです。 彼は他の人をメンタリングおよびコーチングし、触媒および力の乗数として行動し、非常に意欲的なエンジニアリング チームを率いて、大規模な分散システムを構築することが大好きです。

パヴァン クマール ヴァドゥプ ラクシュマン マニキャ は、AW​​S ソリューション アーキテクトであり、お客様が複数の業界にわたって堅牢でスケーラブルなソリューションを設計するのを支援しています。 エンタープライズ アーキテクチャとソフトウェア開発のバックグラウンドを持つ Pavan は、顧客の API セキュリティ、API 管理、マイクロサービス、および地理空間情報システムのユース ケースを処理するソリューションの作成に貢献してきました。 彼は、新しいテクノロジーを学び、これらのソリューションを使用して顧客の問題を解決、自動化、簡素化することに情熱を注いでいます。

スポット画像

最新のインテリジェンス

スポット画像

著作権 @ 2024 Plato Technologies Inc.