翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS のサービスを使用してバリューアットリスク (VaR) を計算
<a name="calculate-value-at-risk-var-by-using-aws-services"></a>

*Sumon Samanta (Amazon Web Services)*

## 概要
<a name="calculate-value-at-risk-var-by-using-aws-services-summary"></a>

このパターンは、AWS のサービスを使用してバリューアットリスク (VaR) 計算システムを実装する方法を示します。オンプレミス環境では、ほとんどの VaR システムが大規模な専用インフラストラクチャ、および社内または商用のグリッドスケジューリングソフトウェアを使用してバッチ処理を実行します。このパターンは、AWS クラウドで VaR 処理を行うための、シンプルで信頼性が高く、スケーラブルなアーキテクチャを提示します。ストリーミングサービスとして Amazon Kinesis Data Streams、マネージドキューサービスとして Amazon Simple Queue Service (Amazon SQS)、マネージドキューサービスとして Amazon ElastiCache、注文の処理とリスク計算に AWS Lambda を使用するサーバーレスアーキテクチャを構築しています。

VaR は統計的尺度であり、トレーダーやリスクマネージャーが、一定の信頼水準を超えるとポートフォリオの潜在的な損失を推定するために使用します。ほとんどの VaR システムでは、数学計算や統計計算を多数実行し、その結果を保存しています。これらの計算には大量の計算リソースが必要となるため、VaR バッチ処理はより小さな計算タスクに分割する必要があります。大きなバッチを小さなタスクに分割することは可能です。これらのタスクはほとんど独立している (つまり、あるタスクの計算が他のタスクには依存しない) ためです。 

VaR アーキテクチャのもう1つの重要な要件は、計算のスケーラビリティです。このパターンでは、計算負荷に基づいて自動的にスケールインまたはスケールアウトするサーバーレスアーキテクチャを使用しています。バッチ処理やオンライン計算の需要を予測することは難しいため、サービスレベルアグリーメント (SLA) で定められたスケジュール内でプロセスを完了するには動的なスケーリングが必要です。また、コストが最適化されたアーキテクチャでは各コンピュートリソース上のタスクが完了したら、すぐにそのリソースをスケールダウンできるはずです。 

AWS のサービスは、スケーラブルな計算能力とストレージ容量、コストを最適化した方法で処理できる分析サービス、リスク管理ワークフローを実行するさまざまなタイプのスケジューラーを備えているため、VaR 計算に最適です。また、AWS で使用したコンピューティングとストレージリソースに対してのみ料金を支払います。

## 前提条件と制限事項
<a name="calculate-value-at-risk-var-by-using-aws-services-prereqs"></a>

**前提条件**
+ アクティブな AWS アカウント。
+ 入力ファイルは、ビジネス要件によって異なります。一般的な使用例には以下の入力ファイルが含まれます：
  + マーケットデータファイル (VaR 計算エンジンへの入力)
  + 取引データファイル (取引データがストリーム経由で送られる場合を除く)。
  + 構成データファイル (モデルとその他の静的構成データ)
  + 計算エンジンモデルファイル (定量ライブラリー)
  + 時系列データファイル (過去 5 年間の株価などの履歴データ用)
+ マーケットデータやその他の入力がストリームを通じて受信される場合、Amazon Kinesis Data Streams がセットアップし、ストリームに書き込むように Amazon 識別とアクセス管理 (IAM) の権限が設定されます。 

このパターンでは、取引データを取引システムから Kinesis データストリームに書き込むアーキテクチャを構築します。ストリーミングサービスを使用する代わりに、取引データをスモールバッチファイルに保存できます。それらは Amazon Simple Storage Service (Amazon S3) バケットに保管し、そしてイベントを呼び出してデータの処理を開始します。

**制限事項**
+ Kinesis データストリームの順序付けは各シャードで保証されています。そのため複数のシャードに書き込まれた取引注文が、書き込み操作と同じ順序で配信されることは保証されません。
+ AWS Lambda ランタイムの制限は、現在は 15 分です。詳細については、「[Lambda FAQ](https://aws.amazon.com/lambda/faqs/)」を参照してください。

## アーキテクチャ
<a name="calculate-value-at-risk-var-by-using-aws-services-architecture"></a>

**ターゲットアーキテクチャ**

次のアーキテクチャ図は、リスク評価システムの AWS サービスとワークフローを示しています。

![\[AWS サービスによる VaR 計算システム\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/eb615fc5-3cc3-445a-af2c-8446ee7b5276/images/c60aec03-ff6c-410c-8ee8-f1f6efa22cf7.png)


この図表は、以下を示すものです：

1. 取引は注文管理システムからストリームインされます。

1. *チケットポジションネッティング* Lambda 関数は、注文を処理し、各ティッカーの統合メッセージを Amazon SQS のリスクキューに書き込みます。

1. *リスク計算エンジン* の Lambda 関数は、Amazon SQS からのメッセージを処理し、リスク計算を実行し、Amazon ElastiCache のリスクキャッシュにある VaR 損益 (PnL) 情報を更新します。

1. *ElastiCache データの読み取り*のLambda 関数は、ElastiCache からリスク結果を取得し、データベースと S3 バケットに保管します。

これらの手順の詳細については、「*エピック*」セクションを参照してください。

**自動化とスケール**

AWS Cloud Development Kit (AWS CDK) または AWS CloudFormation テンプレートを使用して、アーキテクチャ全体をデプロイできます。このアーキテクチャは、バッチ処理と日中 (リアルタイム) 処理の両方のサポートができます。

このアーキテクチャにはスケーリングがビルドインされています。Kinesis データストリームに書き込まれて処理を待つ取引が増えたら、追加の Lambda 関数を呼び出してそれらの取引を処理し、処理が完了したらスケールダウンができます。複数の Amazon SQS リスク計算キューによる処理もオプションです。キュー全体で厳密な順序付けや統合が必要な場合、処理を並列化することはできません。ただし、一日の終わりのバッチや日中のミニバッチの場合、Lambda 関数が並行で処理され、最終結果を ElastiCache に保存できます。 

## ツール
<a name="calculate-value-at-risk-var-by-using-aws-services-tools"></a>

**AWS サービス**
+ 「[Amazon Aurora PostgreSQL 互換エディション](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.html)」は、PostgreSQL デプロイのセットアップ、運用、スケーリングに役立つ、フルマネージド型のACID準拠のリレーショナルデータベースエンジンです。このパターンでは、例として MySQL を使用していますが、いずれかの RDBMS システムを使用してデータを保存できます。
+ 「[Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/)」 は、AWS クラウド上でのインメモリ分散キャッシュ環境のセットアップ、管理、スケーリングに役立ちます。
+ 「[Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/introduction.html)」は、データレコードの大量のストリームをリアルタイムで収集し、処理するのに役立ちます。
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。
+ 「[Amazon Simple Queue Service (Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)) 」は、安全で耐久性があり、配信ソフトウェアシステムとコンポーネントを統合および分離できる利用可能なホスト型キューを提供します。
+ 「[Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) 」は、どのようなデータの量であっても、保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。

**コード**

このパターンは、AWS クラウドの VaR システムのアーキテクチャの例を示し、Lambda 関数を VaR 計算に使用する方法を示しています。Lambda 関数を作成するには、「[Lambdaドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/service_code_examples.html)」 のコード例を参照してください。サポートが必要な場合、「[AWS プロフェッショナルサービス](https://pages.awscloud.com/AWS-Professional-Services.html)」 にお問い合わせください。

## ベストプラクティス
<a name="calculate-value-at-risk-var-by-using-aws-services-best-practices"></a>
+ 各 VaR 計算タスクはできるだけ小さく、軽量にして保持します。各コンピュートタスクでさまざまなトレード数を試して、どれが計算時間とコストについて最適化されているかを確認します。
+ 再利用可能なオブジェクトを Amazon ElastiCache に保存します。Apache Arrow などのフレームワークを使用して、シリアル化と逆シリアル化を減らすことができます。
+ Lambda の時間制限を考慮します。計算タスクが 15 分を超える可能性があると思われる場合、Lambda タイムアウトを回避するためにタスクをより小さなタスクに分割してみてください。これが不可能な場合、AWS Fargate、Amazon Elastic Container Service (Amazon ECS)、および Amazon Elastic Kubernetes Service (Amazon EKS) を使用したコンテナオーケストレーションソリューションを検討します。

## エピック
<a name="calculate-value-at-risk-var-by-using-aws-services-epics"></a>

### リスクシステムへのトレードフロー
<a name="trade-flow-to-risk-system"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| トレードの書き込みを開始します。 | 新規取引、決済取引、または一部決済取引は、注文管理システムからリスクストリームに書き込まれます。このパターンでは、マネージドストリーミングサービスとして Amazon Kinesis を使用します。取引注文ティッカーのハッシュは、複数のシャードに取引注文を出すために使用されます。 | Amazon Kinesis | 

### 注文処理のためのLambda 関数を実行
<a name="run-lambda-functions-for-order-processing"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| Lambda でリスク処理を開始します。 | 新しい注文に対して AWS Lambda 関数を実行します。保留中の取引注文の数に基づいて、Lambda は自動的にスケーリングします。各 Lambda インスタンスには 1 つ以上の注文があり、Amazon ElastiCache から各ティッカーの最新の位置を取得します。（ElasticCache からデータを保存および取得するためのキーとして、CUSIP ID、カーブ名、または他の金融デリバティブ商品のインデックス名が使用できます）。ElastiCache では、合計ポジション (数量) とキーと値のペア <*ティッカー*、*ネットポジション* > ここで*ネットポジション*がスケーリングファクターですが、ティッカーごとに 1 回更新されます。  | Amazon Kinesis、AWS Lambda、Amazon ElastiCache | 

### 各ティッカーのメッセージをキューに書き込む
<a name="write-messages-for-each-ticker-into-queue"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| 統合メッセージをリスクキューに書き込みます。 | キューへメッセージを送信します。このパターンでは、Amazon SQS をマネージドキューサービスとして使用します。1 つの Lambda インスタンスでいつでも取引注文のミニバッチを取得できますが、Amazon SQS にはティッカーごとに 1 つのメッセージしか書き込まれません。スケーリングファクターは (*古いネットポジション* \$1 *現在のポジション*) / *古いネットポジション* で計算されます。 | Amazon SQS, AWS Lambda | 

### リスクエンジンを呼び出す
<a name="invoke-risk-engine"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| リスク計算を開始します。 | リスクエンジンラムダの Lambda 関数が呼び出されます。各ポジションは 1 つの Lambda 関数によって処理されます。ただし、最適化のため、各 Lambda 関数は Amazon SQS からの複数のメッセージを処理できます。 | Amazon SQS, AWS Lambda | 

### リスク結果をキャッシュから取得
<a name="retrieve-risk-results-from-cache"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| リスクキャッシュを取得して更新します。 | Lambda は、各ティッカーの現在のネットポジションを ElastiCache から取得します。また、各ティッカーの Var 利益と損失 (PnL) 配列を ElastiCache から取得します。 PnL 配列がすでに存在する場合、Lambda 関数は配列と Var をスケールで更新します。スケールは、ネッティング Lambda 関数によって書き込まれた Amazon SQS メッセージから取得されます。PnL 配列が ElasticCache にない場合、シミュレートされたティッカー価格シリーズデータを使用して新しい PnL と Var が計算されます。 | Amazon SQS, AWS Lambda、Amazon ElastiCache | 

### Elastic Cache のデータを更新してデータベースに保存
<a name="update-data-in-elastic-cache-and-store-in-database"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| リスク結果を保存します。 | ElastiCache で Var と PnL の数値が更新されると、5 分ごとに新しい Lambda 関数が呼び出されます。この関数は、保存されているすべてのデータを ElastiCache から読み取り、Aurora MySQL 互換データベースと S3 バケットに保存します。 | AWS Lambda、Amazon ElastiCache | 

## 関連リソース
<a name="calculate-value-at-risk-var-by-using-aws-services-resources"></a>
+ 「[バーゼル Var フレームワーク](https://www.bis.org/basel_framework/chapter/DIS/50.htm)」