ゼファーネットのロゴ

ゴールドマンサックスがAmazonEMRでApacheFlinkを使用してペルソナタグを作成した方法

日付:

  グローバル投資リサーチ ゴールドマンサックスの(GIR)部門は、株式、債券、通貨、商品市場の企業のクライアントに調査と洞察を提供する責任があります。 GIRチームの長年の目標のXNUMXつは、パーソナライズされたエクスペリエンスと関連するリサーチコンテンツをリサーチユーザーに提供することです。 以前は、さまざまなタイプのクライアントのユーザーエクスペリエンスをカスタマイズするために、GIRは、幅広い基準に基づいてユーザーに提供されるリサーチサイトのいくつかの異なるエディションを提供していました。 ただし、GIRには、個々のユーザーレベルで個人的にキュレートされたコンテンツフローを作成する方法がありませんでした。 この機能を提供するために、GIRは、ユーザーの役職や作業領域などの特性に基づいて、ユーザーごとにユーザーに推奨されるコンテンツをアクティブにフィルタリングするシステムを実装したいと考えていました。 この種のシステムを導入すると、必要な調査コンテンツを見つけるために必要な時間と労力を削減することで、ユーザーエクスペリエンスを向上させ、GIRの調査ユーザーのワークフローを簡素化できます。

これを達成するための最初のステップは、プロファイルと読者数に基づいてGIRの調査ユーザーを直接分類することです。 そのために、GIRはユーザーにペルソナをタグ付けするシステムを作成しました。 各ペルソナは、特定の基準に基づいて、個々のユーザーにタグを付けることができるタイプまたは分類を表します。 たとえば、GIRにはユーザーの役職を分類するための一連のペルソナがあり、「最高投資責任者」のペルソナでタグ付けされたユーザーは、「企業」でタグ付けされたユーザーとは異なる調査コンテンツが強調表示され、異なるサイトエクスペリエンスを持ちます。会計」のペルソナ。 このペルソナタグ付けシステムは、ユーザーのタグ付けに必要なデータ操作を効率的に実行できるだけでなく、ユースケースが出現したときに必要に応じて新しいペルソナを作成することもできます。

この投稿では、GIRがこのシステムをどのように実装したかを見ていきます。 アマゾンEMR.

課題

連絡先の数(つまり、数百万)とGIRの調査データストアで維持される出版物の数の増加を考えると、ユーザーを分類してコンテンツを推奨するためのシステムを作成することは、スケーラビリティの課題です。 新しく作成されたペルソナは、ほぼすべての連絡先に適用される可能性があります。その場合、数百万のデータエントリに対してタグ付け操作を実行する必要があります。 一般に、連絡先の数、連絡先ごとに保存されるデータの複雑さ、およびパーソナライズの基準の量は、増加するだけです。 ワークフローを将来にわたって保証するために、GIRは、ソリューションが予想される頻繁なケースとして大量のデータの処理を処理できるようにする必要がありました。

GIRのビジネス目標は、分類基準のXNUMX種類のワークフロー(アドホックと継続的)をサポートすることです。 アドホック基準により、現在定義基準条件に適合しているユーザーは、必要なペルソナですぐにタグ付けされ、特定の連絡先のXNUMX回限りのタグ付けを容易にすることを目的としています。 一方、継続的な基準は、属性の変更によってユーザーが基準条件に適合する場合に、ユーザーにペルソナを自動的にタグ付けする継続的なプロセスです。 次の図は、目的のパーソナライズフローを示しています。

この投稿の残りの部分では、GIRのアドホックワークフローの設計と実装に焦点を当てます。

AmazonEMRのApacheFlink

GIRのスケーラビリティの要求を満たすために、彼らは次のことを決定しました。 アマゾンEMR ユースケースに最適であり、次のようなオープンソーステクノロジーを使用して大量のデータを処理することを目的としたマネージドビッグデータプラットフォームでした。 ApacheFlink。 GIRは、スケーラビリティの懸念に対処する他のいくつかのオプション(AWS Glueなど)を評価しましたが、GIRは、既存のシステムへの統合が容易で、バッチワークフローとストリーミングワークフローの両方に適応できる可能性があるため、AmazonEMRを選択しました。

ApacheFlink は、継続的なイベントからのデータを効率的に処理するオープンソースのビッグデータ分散ストリームおよびバッチ処理エンジンです。 Flinkは、XNUMX回限りの保証、高スループット、低遅延を提供し、大量のデータストリームの処理に適しています。 また、Flinkは多くの使いやすいAPIを提供し、プログラマーが失敗を心配する必要性を軽減します。 ただし、Flinkに基づくパイプラインの構築と保守には運用上のオーバーヘッドが伴い、物理リソースのプロビジョニングに加えて、かなりの専門知識が必要になります。

Amazon EMRを使用すると、ユーザーはApache Flinkなどのビッグデータ環境を迅速かつコスト効率よく作成、運用、拡張できます。 を使用してコストを最適化できます AmazonEMRマネージドスケーリング ワークロードに基づいてクラスターノードを自動的に増減します。 GIRのユースケースでは、ユーザーはいつでもペルソナタグ付け操作をトリガーできる必要があり、ジョブの完了時間を予測できる必要があります。 このため、GIRは 長時間実行クラスター、これにより、複数のFlinkジョブを同じクラスターに同時に送信できます。

アドホックなペルソナタグ付けインフラストラクチャとワークフロー

次の図は、AWSクラウドでのGIRのアドホックペルソナタグ付けワークフローのアーキテクチャを示しています。

これは大まかな概要であり、コンポーネント間のネットワークとセキュリティの詳細はこの投稿の範囲外です。

大まかに言えば、GIRのワークフローについて次のXNUMXつの部分で説明できます。

  1. FlinkジョブアーティファクトをEMRクラスターにアップロードします。
  2. Flinkジョブをトリガーします。
  3. Flinkジョブ内で、ユーザーデータを変換して保存します。
  4. 継続的な監視。

AmazonEMRコンソールまたはAWSコマンドラインインターフェイス(AWS CLI)を介して、AmazonEMRでFlinkを操作できます。 クラスターを起動した後、GIRはFlink APIを使用して、Flinkアプリケーションと対話し、作業を送信しました。 Flink APIはもう少し多くの機能を提供し、AWSLambdaアプリケーションから呼び出すのがはるかに簡単でした。

セットアップの最終目標は、GIRの内部ユーザーが連絡先データ(このユースケースでは、さまざまなペルソナとの連絡先のタグ付けまたはタグ付け解除)を自由に要求できるパイプラインを作成し、更新された連絡先データをにアップロードして戻すことです。 GIRコンタクトストア。

FlinkジョブアーティファクトをAmazonEMRにアップロードします

GIRには、Flinkジョブのコンテンツを管理するためのGitLabプロジェクトがオンプレミスにあります。 ワークフローの最初の部分をトリガーし、新しいバージョンのFlinkジョブをクラスターにデプロイするために、GitLabパイプラインが実行され、最初にFlinkジョブのJARファイル、プロパティ、および構成ファイルを含む.zipファイルが作成されます。

次の図は、ジョブのアップロードで発生する一連のイベントを示しています。

  1. GitLabパイプラインは、新しいFlinkジョブをアップロードする必要があるときに手動でトリガーされます。 これにより、Flinkジョブを含む.zipファイルがGIRAWSアカウントのAmazonSimple Storage Service(Amazon S3)バケットに転送され、「S3Deploymentartifacts」というラベルが付けられます。
  2. ラムダ関数(「ラムダのアップロード」)は、AmazonS3からの作成イベントに応答してトリガーされます。
  3. この関数は、最初にFlinkジョブJARをAmazon EMR Flinkクラスターにアップロードし、FlinkセッションのアプリケーションIDを取得します。
  4. 最後に、この関数はアプリケーションプロパティファイルを特定のS3バケットにアップロードします(「S3Flinkジョブプロパティ」)。

Flinkジョブをトリガーします

ワークフローのXNUMX番目の部分は、ジョブ要求が生成されたときに、クラスターへの実際のFlinkジョブの送信を処理します。 GIRには、ペルソナタグ付け操作を実行するためのUIを提供するPersonalizationWorkbenchと呼ばれるユーザー向けのWebアプリがあります。 管理者およびゴールドマンサックスの内部ユーザーは、このWebアプリを介して、ペルソナとの連絡先にタグを付けたり、タグを外したりするリクエストを作成できます。 リクエストが送信されると、リクエストの詳細を含むデータファイルが生成されます。

このワークフローの手順は次のとおりです。

  1. Personalization Workstationは、ジョブリクエストの詳細を「S3Flinkdata」というラベルの付いたFlinkDataS3バケットに送信します。
  2. Amazon S3からのcreateイベントに応答して、Lambda関数(「RunLambda」)がトリガーされます。
  3. この関数は、最初に前の手順でアップロードされたジョブプロパティファイルを読み取り、FlinkジョブIDを取得します。
  4. 最後に、関数はAPI呼び出しを行って、必要なFlinkジョブを実行します。

データを処理する

連絡先データはペルソナタグ付けリクエストに従って処理され、変換されたデータはGIR連絡先ストアにアップロードされます。

このワークフローの手順は次のとおりです。

  1. Flinkジョブは、最初に、最初のステップの一部としてアップロードされたアプリケーションプロパティファイルを読み取ります。
  2. 次に、更新する連絡先とペルソナのデータを含むXNUMX番目のワークフローからデータファイルを読み取ります。 次に、ジョブはタグ付けまたはタグ付け解除操作の処理を実行します。
  3. 結果はGIRコンタクトストアにアップロードされます。
  4. 最後に、成功したリクエストと失敗したリクエストの両方がAmazonS3に書き戻されます。

継続的な監視

ワークフロー全体の最後の部分では、GIRのタグ付けワークフローが安定しており、クラスターが正常な状態にあることを確認するために、EMRクラスターを継続的に監視します。 クライアントデータで最高レベルのセキュリティが維持されるようにするために、GIRはAWSリソースへの制約のないSSHアクセスを回避したいと考えていました。 SSH経由でEMRクラスターのプライマリノードに直接アクセスすることを制限されているということは、GIRが最初はEMRプライマリノードログまたはFlinkWebインターフェイスを可視化できないことを意味していました。

デフォルトでは、AmazonEMRはプライマリノードに保存されているログファイルを3分間隔でAmazonS5にアーカイブします。 このパイプラインは、一度に多くのアドホックなペルソナタグ付けリクエストを処理するための中央プラットフォームとして機能するため、GIRは、クラスターの問題を迅速に診断できる適切な継続的監視システムを構築することが重要でした。

これを実現するために、GIRはXNUMXつの監視ソリューションを実装しました。

  • GIRは、ブートストラップアクションを介してEMRクラスターのすべてのノードにAmazonCloudWatchエージェントをインストールしました。 CloudWatchエージェントは、Flinkメトリクスを収集してカスタムメトリクスネームスペースでCloudWatchに発行し、CloudWatchコンソールで表示できます。 GIRは、CPU使用率や実行中のEMRインスタンスの合計など、関連するメトリクスをキャプチャするようにCloudWatchエージェント設定ファイルを設定しました。 その結果、EMRクラスターが作成され、定期的なS3ログフラッシュを待機するよりもはるかに速いレートでメトリクスがCloudWatchに発行されます。
  • また、クラスターのプライマリノードの前にネットワークロードバランサーを配置し、Goldman Sachsオンプレミスネットワークからの接続を確立することで、FlinkUIを読み取り専用モードで有効にしました。 この変更により、GIRは、実行中のEMRクラスターと進行中のジョブの状態を直接可視化できるようになりました。

観察、直面した課題、および学んだ教訓

パーソナライズの取り組みは、GIR内でのAmazonEMRの初めての採用を示しました。 現在までに、GIRの実稼働環境では何百ものパーソナライズ基準が作成されています。 Webアクセスとクリック率の観点から、GIRのパーソナライズされたコンテンツへのサイトのエンゲージメントは、ペルソナタグ付けシステムの実装以来徐々に増加しています。

GIRは、開発中に次のようないくつかの注目すべき課題に直面しました。

制限付きセキュリティグループルール

デフォルトでは、Amazon EMRは、個々のユースケースに必要な入力および出力ルールの特定のカスタム設定を予測できないため、制限の少ないルールを使用してセキュリティグループを作成します。 ただし、クラスター上のパイプラインとデータを保護するには、セキュリティグループルールを適切に管理することが重要です。 GIRは、EMRクラスターノードにカスタム管理されたセキュリティグループを使用し、このより厳しいセキュリティ体制を満たすために、接続に必要なセキュリティグループルールのみを含めました。

カスタムAMI

AmazonEMRにカスタムAmazonLinuxAMIを使用する場合、必要なパッケージを確実に利用できるようにすることには課題がありました。 Goldman Sachs開発SDLCコントロールの一部として、GoldmanSachsが所有するAWSアカウント上のAmazonElastic Compute Cloud(Amazon EC2)インスタンスは、GoldmanSachsが作成した内部AMIを使用する必要があります。 GIRが開発を開始したとき、この制御下で利用可能だった唯一の準拠AMIは、公開されているAmazon Linux 2最小AMIに基づく最小AMIでした(amzn2-ami-minimal*-x86_64-ebs)。 ただし、Amazon EMRは、必要なすべてのパッケージがプリインストールされているため、完全なデフォルトのAmazon 2LinuxAMIを使用することをお勧めします。 これにより、ライブラリが欠落していることを明確に示すことなく、さまざまな起動エラーが発生しました。

GIRはAWSサポートと協力して、最小AMIと完全AMIを比較し、不足している177個のパッケージを個別にインストールすることで問題を特定して解決しました(パッケージの完全なリストについては、付録を参照してください)。 さらに、ゴールドマンサックスの内部AMI作成プロセスによって、さまざまなAMI関連ファイルが読み取り専用のアクセス許可に設定されていました。 これらの権限を完全な読み取り/書き込みアクセスに復元することで、GIRはクラスターを正常に起動できました。

ストールしたFlinkジョブ

GIRの最初の本番環境への展開中に、GIRで、EMRクラスターがサイレントに失敗し、Lambda関数がタイムアウトするという問題が発生しました。 さらにデバッグすると、GIRはこの問題がAkkaに関連していることを発見しました quarantine-after-silence タイムアウト設定。 デフォルトでは48時間に設定されていたため、それ以降はクラスターがそれ以上のジョブを拒否します。 GIRは、次の値を設定することで回避策を見つけました。 akka.jvm-exit-on-fatal-error Flink設定ファイルでfalseに設定します。

まとめ

この投稿では、ゴールドマンサックスのGIRチームが、AmazonEMRでApacheFlinkを使用してシステムをセットアップし、さまざまなペルソナを持つユーザーのタグ付けを実行して、それらのユーザー向けのコンテンツ提供をより適切にキュレートする方法について説明しました。 また、GIRがEMRクラスターのセットアップで直面したいくつかの課題についても説明しました。 これは、GIRのユーザーに、個々のプロファイルと読者層に基づいて完全にパーソナライズされたコンテンツキュレーションを提供するための重要な最初のステップを表しています。

謝辞

著者は、この投稿に関する緊密なコラボレーションとガイダンスについて、AWSおよびGIRチームの次のメンバーに感謝します。

  • GIR、マネージングディレクター、エリザベスバーンズ
  • GIR、マネージングディレクター、Moon Wang
  • GIR副社長、Ankur Gurha
  • Jeremiah O'Connor、ソリューションアーキテクト、AWS
  • Ley Nezifort、アソシエイト、GIR
  • Shruthi Venkatraman、アナリスト、GIR

著者について

バラスブラマニアのサクシベル ニューヨークのゴールドマンサックスの副社長です。 彼は16年以上のテクノロジーリーダーシップの経験があり、多くの全社的な資格、認証、およびパーソナライズプロジェクトに携わっています。 Balaは、グローバル投資調査部門のクライアントアクセスおよびデータエンジニアリング戦略を推進しています。これには、アーキテクチャ、設計、および実践が含まれ、事業部門が情報に基づいた意思決定を行い、価値を推進できるようにします。 彼はイノベーターであり、現実世界の問題を解決する大規模な分散ソフトウェアの開発と提供の専門家であり、広範囲にわたる高度にスケーラブルなプラットフォーム、製品、およびアーキテクチャの構想と実装で成功を収めています。

ビクターガン ニューヨークのゴールドマンサックスのアナリストです。 ビクターは、コーネル大学を卒業した後、2020年にグローバル投資調査部門に加わり、GIRのユーザー資格システムのクラウドインフラストラクチャの開発とプロビジョニングを担当してきました。 彼は、新しいテクノロジーの学習とクラウドシステムの展開の合理化に焦点を当てています。

マンジュラ・ナギネニ ニューヨークを拠点とするAWSのソリューションアーキテクトです。 彼女は主要な金融サービス機関と協力し、AWSクラウドサービスを採用しながら、大規模なアプリケーションを設計および最新化しています。 彼女はビッグデータワークロードをクラウドネイティブに設計することに情熱を注いでいます。 彼女は、金融、製造、電気通信などの複数のドメインにわたるソフトウェア開発、分析、およびアーキテクチャで20年以上のIT経験を持っています。

 
 


付録

GIRは、次のコマンドを実行して、不足しているAMIパッケージをインストールしました。

yum install -y libevent.x86_64 python2-botocore.noarch device-mapper-event-libs.x86_64 bind-license.noarch libwebp.x86_64 sgpio.x86_64 rsync.x86_64 perl-podlators.noarch libbasicobjects.x86_64 langtable.noarch sssd-client.x86_64 perl-Time-Local.noarch dosfstools.x86_64 attr.x86_64 perl-macros.x86_64 hwdata.x86_64 gpm-libs.x86_64 libtirpc.x86_64 device-mapper-persistent-data.x86_64 libconfig.x86_64 setserial.x86_64 rdate.x86_64 bc.x86_64 amazon-ssm-agent.x86_64 virt-what.x86_64 zip.x86_64 lvm2-libs.x86_64 python2-futures.noarch perl-threads.x86_64 dmraid-events.x86_64 bridge-utils.x86_64 mdadm.x86_64 ec2-net-utils.noarch kbd.x86_64 libtiff.x86_64 perl-File-Path.noarch quota-nls.noarch libstoragemgmt-python.noarch man-pages-overrides.x86_64 python2-rsa.noarch perl-Pod-Usage.noarch psacct.x86_64 libnl3-cli.x86_64 libstoragemgmt-python-clibs.x86_64 tcp_wrappers.x86_64 yum-utils.noarch libaio.x86_64 mtr.x86_64 teamd.x86_64 hibagent.noarch perl-PathTools.x86_64 libxml2-python.x86_64 dmraid.x86_64 pm-utils.x86_64 amazon-linux-extras-yum-plugin.noarch strace.x86_64 bzip2.x86_64 perl-libs.x86_64 kbd-legacy.noarch perl-Storable.x86_64 perl-parent.noarch bind-utils.x86_64 libverto-libevent.x86_64 ntsysv.x86_64 yum-langpacks.noarch libjpeg-turbo.x86_64 plymouth-core-libs.x86_64 perl-threads-shared.x86_64 kernel-tools.x86_64 bind-libs-lite.x86_64 screen.x86_64 perl-Text-ParseWords.noarch perl-Encode.x86_64 libcollection.x86_64 xfsdump.x86_64 perl-Getopt-Long.noarch man-pages.noarch pciutils.x86_64 python2-s3transfer.noarch plymouth-scripts.x86_64 device-mapper-event.x86_64 json-c.x86_64 pciutils-libs.x86_64 perl-Exporter.noarch libdwarf.x86_64 libpath_utils.x86_64 perl.x86_64 libpciaccess.x86_64 hunspell-en-US.noarch nfs-utils.x86_64 tcsh.x86_64 libdrm.x86_64 awscli.noarch cryptsetup.x86_64 python-colorama.noarch ec2-hibinit-agent.noarch usermode.x86_64 rpcbind.x86_64 perl-File-Temp.noarch libnl3.x86_64 generic-logos.noarch python-kitchen.noarch words.noarch kbd-misc.noarch python-docutils.noarch hunspell-en.noarch dyninst.x86_64 perl-Filter.x86_64 libnfsidmap.x86_64 kpatch-runtime.noarch python-simplejson.x86_64 time.x86_64 perl-Pod-Escapes.noarch perl-Pod-Perldoc.noarch langtable-data.noarch vim-enhanced.x86_64 bind-libs.x86_64 boost-system.x86_64 jbigkit-libs.x86_64 binutils.x86_64 wget.x86_64 libdaemon.x86_64 ed.x86_64 at.x86_64 libref_array.x86_64 libstoragemgmt.x86_64 libteam.x86_64 hunspell.x86_64 python-daemon.noarch dmidecode.x86_64 perl-Time-HiRes.x86_64 blktrace.x86_64 bash-completion.noarch lvm2.x86_64 mlocate.x86_64 aws-cfn-bootstrap.noarch plymouth.x86_64 parted.x86_64 tcpdump.x86_64 sysstat.x86_64 vim-filesystem.noarch lm_sensors-libs.x86_64 hunspell-en-GB.noarch cyrus-sasl-plain.x86_64 perl-constant.noarch libini_config.x86_64 python-lockfile.noarch perl-Socket.x86_64 nano.x86_64 setuptool.x86_64 traceroute.x86_64 unzip.x86_64 perl-Pod-Simple.noarch langtable-python.noarch jansson.x86_64 pystache.noarch keyutils.x86_64 acpid.x86_64 perl-Carp.noarch GeoIP.x86_64 python2-dateutil.noarch systemtap-runtime.x86_64 scl-utils.x86_64 python2-jmespath.noarch quota.x86_64 perl-HTTP-Tiny.noarch ec2-instance-connect.noarch vim-common.x86_64 libsss_idmap.x86_64 libsss_nss_idmap.x86_64 perl-Scalar-List-Utils.x86_64 gssproxy.x86_64 lsof.x86_64 ethtool.x86_64 boost-date-time.x86_64 python-pillow.x86_64 boost-thread.x86_64 yajl.x86_64

ソース:https://aws.amazon.com/blogs/big-data/how-goldman-sachs-built-persona-tagging-using-apache-flink-on-amazon-emr/

スポット画像

最新のインテリジェンス

スポット画像