ゼファーネットのロゴ

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

ビッグデータ

Amazon が Amazon EMR を使用して大規模な財務調整プロセスを最適化し、スケーラビリティとパフォーマンスを向上させた方法 |アマゾン ウェブ サービス

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

日付：

閲覧数： 67

アカウント調整は、財務諸表の完全性と正確性を確保するための重要なステップです。具体的には、企業は和解する必要があります。 バランスシート 重大な虚偽記載が含まれる可能性のあるアカウント。会計士は、総勘定元帳の各勘定を調べて、記載されている残高が完全かつ正確であることを確認します。矛盾が見つかった場合、会計士は調査し、適切な是正措置を講じます。

Amazon の FinTech 組織の一環として、当社は Amazon の内部会計チームがアカウント調整を行えるようにするソフトウェア プラットフォームを提供しています。調整プロセスを最適化するために、これらのユーザーはオンデマンドで拡張できる機能と、数 MB から 100 GB 以上までのさまざまなファイル サイズを処理する機能を備えた高パフォーマンスの変換を必要とします。データを単一のマシンに適合させたり、単一のプログラムで適切な時間内に処理したりすることが常に可能であるとは限りません。この計算は、プログラミング ロジックと基礎となる詳細 (データ分散、フォールト トレランス、スケジューリング) を分離できる実用的なサービスを提供するために、十分に高速に実行する必要があります。

分散データ処理ソリューションを使用すると、データセットの要素のグループ全体にわたって同じ機能の複数のマシンまたはスレッドでこれらの同時計算を実現できます。これにより、以下を含む AWS のサービスを活用した調整サービスを再発明することができました。 アマゾンEMR と Apache Spark 分散処理フレームワークを使用します。 パイスパーク。このサービスを使用すると、ユーザーは最大 100 億件のトランザクションを含む 100 GB を超えるファイルを 30 分以内に処理できます。調整サービスはデータ処理の強力な手段となり、ユーザーは次のようなさまざまな操作をシームレスに実行できるようになりました。 枢軸, 登録 (Excel の VLOOKUP 操作と同様)、 算術 操作、および 他には？、膨大なデータセットを調整するための多用途かつ効率的なソリューションを提供します。この機能強化は、分散データ処理ソリューションの導入によって達成されたスケーラビリティと速度の証です。

この投稿では、Amazon EMR を統合して、大量の財務調整プロセスを実行できる可用性とスケーラブルなシステムを構築した方法について説明します。

移行前のアーキテクチャ

次の図は、以前のアーキテクチャを示しています。

私たちの従来のサービスは以下で構築されました Amazon エラスティック コンテナ サービス （Amazon ECS）オン AWSファーゲート。 Python を使用してデータを順次処理しました。ただし、並列処理能力が欠如しているため、より大きなデータセットをサポートするには、クラスター サイズを垂直方向に増やす必要が頻繁にありました。コンテキストとして、5 の操作を含む 50 GB のデータの処理には約 3 時間かかりました。このサービスは、メッセージをポーリングする XNUMX つの ECS インスタンスに水平方向に拡張するように構成されました。 Amazon シンプル キュー サービス (Amazon SQS)、変換リクエストを供給しました。各インスタンスは、水平スケーリングを可能にするために 4 つの vCPU と 30 GB のメモリで構成されました。ただし、プロセスは順番に実行され、データのチャンクを選択するため、パフォーマンス上の容量を拡張できませんでした。 Amazon シンプル ストレージ サービス (Amazon S3) を処理します。たとえば、XNUMX つのファイルを結合する VLOOKUP 操作では、出力を取得するために両方のファイルをメモリ チャンクごとに読み取る必要がありました。データセットを処理するために長時間待機する必要があったため、これはユーザーにとって障害となりました。

再構築と最新化の一環として、次のことを達成したいと考えました。

  • 高可用性 – データ処理クラスターは可用性が高く、スリーナインの可用性 (9%) を提供する必要があります。
  • スループット – サービスは 1,500 日あたり XNUMX 回の実行を処理する必要があります
  • レイテンシ – 100 分以内に 30 GB のデータを処理できる必要があります
  • 不均一性 – クラスターは、数 MB から数百 GB の範囲のファイルを含む、さまざまなワークロードをサポートできる必要があります。
  • クエリの同時実行性 – 実装には、少なくとも 10 度の同時実行をサポートする機能が必要です
  • ジョブの信頼性とデータの一貫性 – サービス レベル アグリーメント (SLA) に違反しないように、ジョブは確実かつ一貫して実行される必要があります。
  • コスト効率が高く拡張性が高い – ワークロードに基づいて拡張可能であり、費用対効果が高くなければなりません
  • セキュリティとコンプライアンス – データの機密性を考慮すると、きめの細かいアクセス制御と適切なセキュリティ実装をサポートする必要があります
  • 監視 – ソリューションは、クラスターとジョブのエンドツーエンドの監視を提供する必要があります

Amazon EMR を選ぶ理由

Amazon EMR は、ペタバイト規模のデータ処理、インタラクティブ分析、機械学習 (ML) のための業界をリードするクラウド ビッグデータ ソリューションです。 Apache Spark, ApacheHive, プレストで。これらのフレームワークと関連するオープンソース プロジェクトを使用すると、分析目的や BI ワークロードのためにデータを処理できます。 Amazon EMR を使用すると、Amazon S3 や他の AWS データストアやデータベースとの間で大量のデータを変換および移動できます。 Amazon DynamoDB.

Amazon EMR の注目すべき利点は、PySpark による並列処理の効果的な使用にあり、従来のシーケンシャル Python コードに比べて大幅な改善が見られます。この革新的なアプローチにより、Apache Spark クラスターのデプロイとスケーリングが合理化され、大規模なデータセットでの効率的な並列化が可能になります。分散コンピューティング インフラストラクチャは、パフォーマンスを向上させるだけでなく、前例のない速度での膨大な量のデータの処理を可能にします。ライブラリを備えた PySpark は、Excel のような操作を容易にします。 データフレーム、DataFrame のより高いレベルの抽象化により、複雑なデータ操作が簡素化され、コードの複雑さが軽減されます。自動クラスタープロビジョニング、動的なリソース割り当て、他の AWS サービスとの統合と組み合わせることで、Amazon EMR は、バッチ処理から ML に至るまでのさまざまなワークロードに適した多用途のソリューションであることがわかります。 PySpark と Amazon EMR に固有の耐障害性により、ノード障害が発生した場合でも堅牢性が向上し、AWS での並列データ処理にとってスケーラブルでコスト効率が高く、パフォーマンスの高い選択肢となります。

Amazon EMR は、その機能を基本を超えて拡張し、多様なニーズに応えるさまざまなデプロイメント オプションを提供します。それかどうか EC2 上の Amazon EMR, EKS上のAmazonEMR, Amazon EMR サーバーレスまたは AWS Outposts 上の Amazon EMR、特定の要件に合わせてアプローチを調整できます。 Spark ジョブ用のサーバーレス環境を求めている方向けに、 AWSグルー も実行可能な選択肢です。 Spark を含むさまざまなオープンソース フレームワークのサポートに加えて、Amazon EMR はデプロイメント モードを柔軟に選択できます。 アマゾン エラスティック コンピューティング クラウド (Amazon EC2) インスタンス タイプ、スケーリング メカニズム、および数多くのコスト削減最適化手法。

Amazon EMR はクラウド内のダイナミックな力として機能し、堅牢なビッグデータ ソリューションを求める組織に比類のない機能を提供します。シームレスな統合、強力な機能、適応性により、AWS 上のデータ分析と ML の複雑さをナビゲートするために不可欠なツールとなっています。

再設計されたアーキテクチャ

次の図は、再設計されたアーキテクチャを示しています。

このソリューションは API コントラクトに基づいて動作し、クライアントは変換構成を送信して、処理する S3 データセットの場所とともに一連の操作を定義できます。リクエストは Amazon SQS を通じてキューに入れられ、Lambda 関数を通じて Amazon EMR に送信されます。このプロセスでは、専用 EMR クラスター上で Spark フレームワークを実装するための Amazon EMR ステップの作成を開始します。 Amazon EMR は、長期実行クラスターの存続期間中に無制限のステップに対応しますが、同時に実行または保留できるステップは 256 のみです。最適な並列化を実現するには、ステップの同時実行数を 10 に設定し、10 個のステップを同時に実行できるようにします。リクエストが失敗した場合、Amazon SQS デッドレターキュー (DLQ) はイベントを保持します。 Spark はリクエストを処理し、Excel のような操作を PySpark コードに変換して、効率的なクエリ プランを実現します。 Resilient DataFrames は、入力、出力、中間データをメモリ内に保存し、処理速度を最適化し、ディスク I/O コストを削減し、ワークロードのパフォーマンスを向上させ、指定された Amazon S3 の場所に最終出力を配信します。

当社は SLA をレイテンシーとスループットの 2 つの次元で定義します。レイテンシは、確定的なデータセット サイズおよびデータセットに対して実行される操作の数に対して 1 つのジョブを実行するのにかかる時間として定義されます。スループットは、1 つのジョブのレイテンシ SLA に違反することなくサービスが実行できる同時ジョブの最大数として定義されます。サービスの全体的なスケーラビリティ SLA は、柔軟なコンピューティング リソースの水平方向のスケーリングと個々のサーバーの垂直方向のスケーリングのバランスによって決まります。

最小限のレイテンシーと高いパフォーマンスで 1,500 日あたり 2 のプロセスを実行する必要があったため、可変ファイル サイズの処理をサポートするためにマネージド スケーリングを有効にした ECXNUMX デプロイメント モードで Amazon EMR を統合することを選択しました。

EMR クラスター構成では、さまざまな選択肢が提供されます。

  • EMR ノードの種類 – プライマリ、コア、またはタスク ノード
  • インスタンス購入オプション – オンデマンドインスタンス、リザーブドインスタンス、またはスポットインスタンス
  • 設定オプション – EMR インスタンス フリートまたは均一インスタンス グループ
  • スケーリングオプション – 自動スケーリング または Amazon EMR マネージドスケーリング

変動するワークロードに基づいて、EMR インスタンス フリートを構成しました (ベスト プラクティスについては、「 信頼性の向上）。また、Amazon EMR マネージド スケーリングを使用してコア ノードとタスク ノードをスケーリングすることも決定しました (スケーリング シナリオについては、「 ノード割り当てシナリオ）。最後に、メモリ最適化を選択しました AWS グラビトン インスタンスは、最大で Spark ワークロードのコストが 30% 削減され、パフォーマンスが最大 15% 向上.

次のコードは、クラスター構成のスナップショットを提供します。

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

性能

Amazon EMR への移行により、最低 273 B から最高 88.5 GB までのさまざまなデータセットを処理できるシステムパフォーマンスを達成することができました。 p99 491秒（約8分）。

次の図は、処理されるさまざまなファイル サイズを示しています。

次の図はレイテンシを示しています。

逐次処理と比較するために、53 万レコードを含む 49 つのデータセットを取得し、他の 26 の Excel に似た操作とともに VLOOKUP 操作を相互に実行しました。従来のサービスでは処理に 5 日かかっていたのに対し、新しいサービスでは 300 分かかりました。この改善は、パフォーマンスの点で以前のアーキテクチャと比べてほぼ XNUMX 倍大きくなります。

考慮事項

このソリューションを検討するときは、次の点に注意してください。

  • 適切なサイズのクラスター – Amazon EMR はサイズ変更可能ですが、クラスターのサイズを適切に調整することが重要です。適切なサイジングにより、クラスターのサイズが小さすぎる場合のクラスターの速度の低下が軽減され、クラスターのサイズが大きすぎる場合のコストの上昇が軽減されます。これらの問題を予測するには、ワークロードに必要なノードの数とタイプを計算します。
  • 並行ステップ – ステップを並行して実行すると、より高度なワークロードを実行し、クラスター リソースの使用率を高め、ワークロードの完了にかかる時間を短縮できます。一度に実行できるステップの数は構成可能で、クラスターの起動時およびクラスターの起動後のいつでも設定できます。複数のジョブが単一の共有クラスターで実行されている場合は、ジョブごとの CPU/メモリ使用量を考慮して最適化する必要があります。
  • ジョブベースの一時的なEMRクラスター – 該当する場合は、ジョブベースの一時 EMR クラスターを使用することをお勧めします。これにより、優れた分離が実現され、各タスクが専用環境内で動作することが検証されます。このアプローチにより、リソースの使用率が最適化され、ジョブ間の干渉が防止され、全体的なパフォーマンスと信頼性が向上します。一時的な性質により効率的なスケーリングが可能になり、多様なデータ処理ニーズに堅牢かつ独立したソリューションが提供されます。
  • EMR サーバーレス – EMR サーバーレスは、クラスターの管理と運用を処理したくない場合に理想的な選択肢です。 EMR サーバーレス内で利用可能なオープンソース フレームワークを使用してアプリケーションを簡単に実行できるため、簡単で手間のかからないエクスペリエンスが提供されます。
  • Amazon EKSのEMR – EKS 上の Amazon EMR は、起動時間の短縮やコンピューティング容量の課題を解決するスケーラビリティの向上など、明確な利点を提供します。これは、特に Graviton およびスポット インスタンスのユーザーにとって有益です。より幅広いコンピューティング タイプを含めることでコスト効率が向上し、カスタマイズされたリソース割り当てが可能になります。さらに、マルチ AZ サポートにより可用性が向上します。これらの魅力的な機能は、さまざまなコンピューティング シナリオにわたってパフォーマンス、コストの最適化、信頼性が向上し、ビッグ データ ワークロードを管理するための堅牢なソリューションを提供します。

まとめ

この投稿では、Amazon がより高いスケーラビリティとパフォーマンスを実現するために、Amazon EMR を使用して大量の財務調整プロセスをどのように最適化したかについて説明しました。追加のリクエストやデータセットを処理するために垂直スケーリングに依存するモノリシック アプリケーションがある場合は、それを Apache Spark などの分散処理フレームワークに移行し、コンピューティングに Amazon EMR などのマネージド サービスを選択すると、ランタイムを短縮して配信を短縮できる可能性があります。 SLA に準拠し、総所有コスト (TCO) の削減にも役立ちます。

この特定のユースケースでは Amazon EMR を採用しているため、データイノベーションの取り組みにおけるさらなる可能性を探ることをお勧めします。独自のユースケースに合わせた最適な AWS サービスを見つけるために、EMR サーバーレスや EKS 上の Amazon EMR などの他の動的 Amazon EMR デプロイメント オプションと併せて AWS Glue を評価することを検討してください。データ イノベーションの取り組みの将来には、さらに探求されるエキサイティングな可能性と進歩が秘められています。

著者について

ジーシャン・ケトラパル Amazon のシニア ソフトウェア開発エンジニアであり、企業の IT 一般管理、財務報告、ガバナンス、リスク、コンプライアンスの管理を担当するクラウド コンピューティング サーバーレス アーキテクチャに基づくフィンテック製品を開発しています。

サクティミシュラ AWS のプリンシパル ソリューション アーキテクトとして、顧客のデータ アーキテクチャの最新化と、データ セキュリティ、アクセシビリティ、ガバナンスなどのエンドツーエンドのデータ戦略の定義を支援しています。 彼は本の著者でもあります AmazonEMRでビッグデータ分析を簡素化。 仕事以外では、サクティは新しいテクノロジーを学び、映画を見たり、家族と一緒に場所を訪れたりすることを楽しんでいます。

スポット画像

最新のインテリジェンス

スポット画像

著作権 @ 2024 Plato Technologies Inc.