AWS Lambda、Amazon Kinesis、Amazon Athena を使用したブロックチェーン分析ソリューションの構築

ブロックチェーンの利用には、数多くの潜在的な利点があります。ブロックチェーンとは、検証可能かつ変更不能な方法でトランザクションを記録できる分散型データ構造です。ユースケースに応じ、コスト削減、速度や効率性の改善、企業コンプライアンスの強化、回復力やスケーラビリティの向上を実現できる可能性があります。

ブロックチェーンを早期に取り入れた人々は、金融、ヘルスケア、電子政府、非営利組織などの分野で、その革新的な使い道を発見しているところです。ブロックチェーンは、当初は仮想通貨 Bitcoin を支える主要テクノロジーとして開発されたものでした。

ブロックチェーンの使い道については、その設計から実に多くの機会が生じています。基本的には、幾千ものノードで構成されることが多い、大規模な分散型システムです。ブロックチェーンにおいては、ユーザーのアクティビティ、イベント、例外、その他の状態変化を見抜くことが困難な場合があります。しかし、AWS 分析サービスでは、ブロックチェーンアプリケーションを分析できるようにするとともに、その分野に関する重要な情報を提供します。

ウォークスルー

この記事では、以下を実現する方法について説明します。

AWS Blockchain Templates を利用した Ethereum ブロックチェーンのデプロイ
スマートコントラクトのデプロイ
AWS Lambda、Amazon Kinesis、Amazon Athena に基づいたコントラクトの、サーバーレス分析パイプラインの構築

この Ethereum のデプロイやブロックチェーン分析は、幅広いブロックチェーンシナリオでの用途に、容易に適合させることができます。

前提条件

この記事は前提として、AWS と Ethereum に精通しているユーザーを対象としています。次のドキュメントでは、この記事で説明する手順を実行する際に役立つ背景知識を提供しています。

加えて、このブログ記事からさらに多くを学ぶには、Amazon Kinesis、AWS Lambda、Amazon QuickSight、Amazon Athena にも精通していると便利です。詳細は、下記を参照してください。

AWS Lambda を使用したサーバーレスコンピューティングの概要については、Introduction to AWS Lambda – Serverless Compute on Amazon Web Services を参照してください。

ブロックチェーン初級編

この記事で扱うソリューションに進む前に、ブロックチェーンについて、また、このソリューションで使用するブロックチェーンの実装、Ethereum について簡単に説明したいと思います。

簡単に言えば、ブロックチェーンはコンセンサスを得る手法です。ブロックチェーン登場の背景には、脆弱性、悪意のある脅威、過失に対抗すると同時に、Bitcoin ネットワークに金融取引の注文について合意させるという動機がありました。他のブロックチェーン実装は、汎用的な計算の状態について合意を得る目的で使用されています。これは、トランザクションの偽造を電算的に困難なものとするため任意の計算問題を解決する、マイニングと呼ばれるプロセスを通して実現されます。

Ethereum は大手によるブロックチェーン実装です。Bitcoin や初期のブロックチェーンシステムとは異なり、Ethereum は、Ether という独自の仮想通貨はあるものの、ただの仮想通貨プラットフォームではありません。Ethereum は、ブロックチェーン上にチューリング完全である Ethereum 仮想マシン (VM) を構築することにより、ブロックチェーンの概念を拡張しています。これが、ブロックチェーン上で動作するプログラム、スマートコントラクトの開発を可能にしています。スマートコントラクトの魅力は、保険契約のような自然言語の契約を、Ethereum で動作するコードに直すことができるという機能です。これにより、銀行や公証人といった中央権力を介す必要なしに契約上の合意形成が可能となり、市場化の時間短縮やコスト削減が期待できます。

ブロックチェーンソリューションの概要

次に、この記事で述べるソリューションの概要を示します。ソリューションは下記により構成されます。

AWS Blockchain Template を介し Amazon Elastic Container Service (Amazon ECS) 上で稼働する Ethereum ブロックチェーン
さまざまな Ethereum API へのアクセスを提供する Application Load Balancer
スマートコントラクトをブロックチェーンにデプロイする Lambda 関数
スマートコントラクトに対しトランザクションを実行する Lambda 関数
スマートコントラクトのイベントをリッスンし、そのイベントを Amazon Kinesis にプッシュする Lambda 関数
Lambda 関数の間でブロックチェーンの状態を共有するために使用する Amazon DynamoDB テーブル
Amazon Kinesis Data Firehose、Amazon Kinesis Data Analytics、Amazon Kinesis Data Streams、Amazon Athena を使用するブロックチェーン分析パイプライン
Amazon QuickSight を使用して構築した分析ダッシュボード

ソリューションを、次のアーキテクチャ図に示します。

ご覧の通り、ソリューションは大きく 2 つの部分で構成されます。

Amazon Elastic Compute Cloud (Amazon EC2) がホストするブロックチェーンと、そのブロックチェーンに関わる Lambda 関数
ブロックチェーンのデータを消費する Kinesis に基づく分析パイプライン

用意した AWS CloudFormation テンプレートは、Kinesis Data Streams までを含むアーキテクチャ図の左側をデプロイします。この記事で構築していくのは、図の右側になります。

初期リソースの作成

まず、以下の URL で AWS CloudFormation テンプレートをダウンロードします。https://s3.amazonaws.com/blockchainblog/blockchainblogpost.template
AWS CloudFormation を使い、テンプレートを起動します。AWS CloudFormation スタックが、仮想プライベートクラウド (VPC)、2 つのサブネット、ブロックチェーンに関わる Lambda 関数一式をデプロイします。これが、分析パイプライン構築の基礎となります。独自の CIDR ブロックを準備することも、デフォルトのパラメータを使用することもできます。各サブネットには、少なくとも 8 つの IP アドレスが必要です。
AWS Blockchain Templates をデプロイします。AWS Blockchain Templates により、AWS に Ethereum と Hyperledger ブロックチェーンネットワークを効率的にデプロイできるようになります。今回のケースでは、手順 2 で AWS CloudFormation が作成した VPC に、Ethereum ネットワークをデプロイしていきます。
次の AWS CloudFormation テンプレートを起動します。https://aws-blockchain-templates-us-east-1.s3.us-east-1.amazonaws.com/ethereum/templates/latest/ethereum-network.template.yaml このテンプレートには、いくつかのパラメータが必要です。

Initial List of Accounts を、Lambda 関数が使用する次の事前定義済みアカウントに設定します。

0x34db0A1D7FE9D482C389b191e703Bf0182E0baE3,0xB3Bbce5d76aF28EcE4318c28479565F802f96808,0x877108a8825222cf669Ca9bFA3397D6973fE1640,0xb272056E07C94C7E762F642685bE822df6d08D03,0x0c00e92343f7AA255e0BBC17b21a02f188b53D6C,0xaDf205a5fcb846C4f8D5e9f5228196e3c157e8E0,0x1373a92b9BEbBCda6B87a4B5F94137Bc64E47261,0x9038284431F878f17F4387943169d5263eA55650,0xe1cd3399F6b0A1Ef6ac8Cebe228D7609B601ca8a,0x0A67cCC3FD9d664D815D229CEA7EF215d4C00A0a

VPC Network Configuration で以下を設定します。
- VPC ID を 1 つ目の AWS CloudFormation テンプレートで作成した blockchainblog VPC に設定します。
- 使用するサブネットの一覧に、blockchainblog-public サブネットを追加します。
- ALB サブネットの一覧に、blockchainblog-public と blockchainblog-private を追加します。
Security Configuration で以下を設定します。
- 自身の Amazon EC2 キーペアを選択します。
- blockchainblog セキュリティグループを準備します。
- Amazon EC2 ロールに、blockchainblog-ec2-role を準備します。
- Amazon ECS ロールに、blockchainblog-ecs-role を準備します。
- ALB セキュリティグループを blockchainblog セキュリティグループに設定します。

その他のすべての変数は変更を加えないままとし、テンプレートを作成し、すべてのリソースがデプロイされるのを待ちます。これにより、Ethereum ブロックチェーンがデプロイされ、マイニングのプロセスが始まり、Application Load Balancer を介して Web3 API が公開されます。

リソースが作成されたら、スマートコントラクトのデプロイに進みます。

スマートコントラクトのデプロイ

ブロックチェーンを使用するには、そのスマートコントラクトをデプロイします。このスマートコントラクトは複雑ではありません。オークションを行う関数を準備するものです。

オークションコントラクトは公開オークションを意味しており、これにより関係当事者全員を特定できます。オークション対象のアイテムを提供するユーザーがコントラクトをデプロイすると、そのコントラクトを使用して他のユーザーが入札できます。オークションは、事前に定義されたブロック数のマイニングが行われたところで終了とみなされます。オークションが終了すると、落札した以外の応札金が引き出され、資金が入札者に戻されます。オークションを開いたユーザーは、その後で落札金を引き出すことができます。

コントラクトは、落札者が問題なく商品を受け取ることを保証するものではない点にご留意ください。実際、このコントラクトはオークションの対象物とは完全に別です。コントラクトを拡張してこの機能を提供することも可能ですが、この記事で扱う範囲を考慮し、コントラクトは単純な形にしておきます。

オークションコントラクトは、https://s3.amazonaws.com/blockchainblog/Auction.sol にあります。

オークションコントラクトの考察

このオークションコントラクトは、自動的に Lambda 関数によってプルされ、ブロックチェーンにデプロイされます。このコントラクトは、Solidity というドメイン固有言語で書かれています。構文は C 系言語の影響を受けていますが、C とは異なりオブジェクトコードへのコンパイルはしません。その代わり、Ethereum VM で動作するバイトコードにコンパイルします。

このスマートコントラクトには、2 つの機能があります。入札と引き出しです。入札はユーザーがオークションに入札できるように、引き出しはユーザーがオークション終了時にコントラクトから資金を引き出せるようにします。オークション所有者は落札金を得ることが、落札できなかった入札者は資金を取り戻すことができます。データ構造 BidEvent が C 構造体と類似している点と、またこれが Solidity イベントをトリガーする方法である点に注意してください。Solidity イベントはキャプチャされ、分析パイプラインに送られます。

さて、いよいよ事前構築された Lambda 関数を使用して、スマートコントラクトをデプロイし、これに対してトランザクションを実行し、イベントをリッスンします。次の図は Lambda 関数の相互作用を示しています。

DeployContract は、先にデプロイした AWS CloudFormation で作成した Lambda 関数です。この関数は Amazon Simple Storage Service (Amazon S3) バケットから Solidity のソースコードを取得し、solc コンパイラで EVM バイトコードにコンパイルし、ブロックチェーンにデプロイして、コントラクトのブロックチェーンアドレスを DynamoDB テーブルに保存します。この関数は、web3 1.0.0 API を介し Amazon EC2 インスタンスで Ethereum ブロックチェーンとやり取りを行います。この関数のソースコードは、https://s3.amazonaws.com/blockchainblog/DeployContract.zip で確認できます。

AWS CloudFormation テンプレートをデプロイした後、ブロックチェーンにマイニングプロセスを開始する時間をとらせるため、約 5 分待ってからコントラクトをデプロイします。これはほとんど、ブロックチェーンが最初の有向非循環グラフ (DAG) を生成するための時間です。

DeployContract は空のテストイベントでこれを試行することにより、Lambda コンソールで呼び出すことができます。関数を呼び出す前に、ブロックチェーンのアドレスを与えます。これを行うには、AWS Blockchain Template の出力を見つけ、そこから EthJSONRPCURL の値を取得します。その後、BLOCKCHAIN_HOST という環境変数内のこの値を、次の例に示すように、DeployContract 関数に提供します。

では、DeployContract 関数を呼び出します。デプロイされたコントラクトのブロックチェーンアドレスや、コントラクトの JSON ABI など、さまざまな状態が表示されるはずです。関数の実行後、コントラクトはプライベートブロックチェーンにデプロイされ、使用可能になります。関数でエラーが生じる場合、ブロックチェーンがまだ初期化されていないことが原因かもしれません。AWS CloudFormation テンプレートを作成した後、数分待ってから DeployContract を呼び出します。

トランザクションの実行

分析用のトランザクションデータを生成するには、まずトランザクションが必要です。トランザクションを発生させるには、ExecuteTransactions という 2 つ目の Lambda 関数を使用していきます。

スマートコントラクトでは、イベントはファイルの最初に記述されます。イベントは、Solidity の便利なメカニズムであり、ブロックチェーン外のコードのコールバックとして使用できます。最後の Lambda 関数、ListenForTransactions は、コントラクトに対するイベントの発生をリッスンし、そのイベントを分析のため Kinesis に送ります。

Ethereum は現在、Kinesis へのイベントの直接送信をサポートしていません。そのため、ブロックチェーンからイベントをプルするために ListenForTransactions 関数を実行することになります。空のテストイベントで関数を呼び出すことにより、これを手動で行うことができます。ListenForTransactions は、最後に実行されて以降の、ブロックチェーンからのすべてのイベントをプルします。ただし、リアルタイムでブロックチェーンからのトランザクションをプルするには、関数を絶えず実行することになります。次のセクションでは、オプションで、Lambda 関数が期間または時期指定により定期的に実行されるようスケジュールすることができます。再度、ListenForTransactions と ExecuteTransactions の両方に対し DeployContract で、BLOCKCHAIN_HOST 環境変数を介して Ethereum RPC エンドポイントのアドレスを提供します。

オプション: Amazon CloudWatch イベントを使用した ListenForTransactions のスケジュール

ListenForTransactions を継続的に実行するため、Lambda 関数のトリガーとして Amazon CloudWatch Events を使用します。Amazon CloudWatch コンソールで、[トリガー] タブを選択し、新しい Amazon CloudWatch Events トリガーを追加して、スケジュールパターンを rate(5) とします。これで確実に、関数が継続的に実行されるようになるため、すべてのイベントは発生するとすぐに Kinesis に送られることが保証されます。こうすることで、スマートコントラクトに対するイベントを、ほぼリアルタイムで処理できます。ただし、コストを削減したい場合、あるいはリアルタイム分析が主な目的ではない場合には、間隔を開けて ListenForTransactions 関数を実行することもできます。定期的に関数を実行すると、関数が最後に実行されて以降のすべてのイベントを取得します。ただし、イベント発生を待って取得する場合ほどタイムリーではありません。

ListenForTransactions をトリガーするため、CloudWatch イベントを次のように設定します。

ListenForTransactions について Lambda コンソールの [Designer (デザイナー)] セクションで、[CloudWatch Events (CloudWatch イベント)] を選択します。
設定の上でクリックし、CloudWatch イベントの設定をスクロールします。
ルールのドロップダウンメニューで [新規ルールの作成] を選択します。
ルールに名前と説明を付けます。
[スケジュール式] を選択します。
式に rate(5) と入力します。
[トリガーの有効化] を選択します。
[追加] をクリックします。

関数がスケジュールされたら、コントラクトに対しイベントを生成します。空のテストイベントで、ExecuteTransactions を実行できます。分析パイプラインに送るトランザクションをさらに生成するには、これを何度か繰り返します。ExecuteTransactions は、同時に 10 件のトランザクションのバッチを作成します。

Kinesis Data Analytics を使ったトランザクションの分析

Lambda 関数はスマートコントラクトのイベントをリッスンしているので、すべての応札アクティビティは、BlockchainBlogEvents という AWS CloudFormation で準備済みの Kinesis Data Stream に送られます。

ただちにすべてのイベントが Kinesis に行きますが、そこで終わりです。イベントは後の Athena を使用した分析のために保持します。これをするには、Kinesis Data Stream コンソールに移動し、今回のために作られた BlockchainBlog ストリームを選択します。

右上隅の [Firehose への接続] を選択します。これにより、すべてのイベントが Kinesis Data Firehose ストリームに送られ、S3 バケットに配信されます。
配信ストリームに名前を付け、[次へ] を選択しますが、[Record transformation (レコード変換)] は有効にしないでください。
結果を保存する S3 バケットを指定します。後から Athena で使用できるよう必ず行います。

ブロックチェーンからのすべてのイベントが Amazon S3 まで保持されるようになったはずです。

イベントが保持されているので、Kinesis Data Analytics を使用して、Kinesis Data Stream の一連のリアルタイム分析を実行していきます。その後で、Athena を介し Amazon S3 に保存されたデータのバッチ分析を実行します。

まず、Kinesis Data Analytics に注目します。ListenForTransactions Lambda 関数が、オークションのスマートコントラクトに対しトランザクションが実行される都度、ストリームにメッセージを送信します。

メッセージは JSON オブジェクトです。これは、トランザクションを開始した入札者のアドレス、入札の金額、入札したコントラクト、トランザクションを実行した時間、トランザクションが加えられたブロックの情報で構成されます。

Kinesis Data Analytics は、ストリームに入ってくる各メッセージを処理し、ストリーム全体の分析を可能にします。この例では、Kinesis Data Analytics を使用して下記を実行します。

各ブロックに入札されている Ether の数量を、15 秒のスライディングウィンドウで計算します。
15 秒のスライディングウィンドウ中に発生するユニーク入札者数を調べます。

スラインディングウィンドウを 15 秒とするのは、これが Ethereum のブロックタイムであるためです。ブロックタイムは、ブロックチェーンにブロックを 1 つ追加するのにかかる時間の尺度です。スライディングウィンドウを 15 秒に設定することで、マイニングの間に発生しているトランザクションを把握できます。スライディングウィンドウをより長い時間に設定して、オークションアプリケーションとどのように関係しているかを知ることもできます。

リアルタイム分析を開始するには、Kinesis データ分析アプリケーションを作成する必要があります。手順は、次のとおりです。

AWS マネジメントコンソールの Kinesis データ分析アプリケーションコンソールに移動します。
新規で Kinesis データアプリケーションを作成し、適切な名前と説明を付し、ソースとして事前作成済みの Kinesis Data Stream を指定します。
ExecuteTransactions を実行し、トランザクション一式を Kinesis に送信して、自動でスキーマを発見します。
アプリケーションの SQL エディタを開きます。

次に、各ブロックに送られている Ether の数量を調べるため、SQL を Kinesis データ分析アプリケーションに追加します。これには、コントラクトに送信されたすべての入札と、終了したオークションから引き出されたすべての資金が含まれます。

次の SQL をコピーして、Kinesis Data Analytics の SQL エディタに貼り付けてから、これを実行します。

CREATE OR REPLACE STREAM "SPEND_PER_BLOCK_STREAM" (block INTEGER, spend INTEGER);
CREATE OR REPLACE PUMP "STREAM_PUMP" AS INSERT INTO "SPEND_PER_BLOCK_STREAM"

SELECT STREAM "Block", SUM("Amount") AS block_sum
FROM "SOURCE_SQL_STREAM_001"
GROUP BY "Block", STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '15' SECOND);

この単純な SQL の一部により、スマートコントラクトについていくらかの情報を得られます。SPEND_PER_BLOCK_STREAM の出力で、そのブロックにおける、コントラクトからの、ブロック数と資金の量が出ます。この出力により、スマートコントラクトに関連していくらの仮想通貨が使われたのか、またいつ使われたのかが明らかになります。

ExecuteTransactions と ListenForTransactions 関数を実行することで、Kinesis データ分析アプリケーションが処理するデータの存在を確認します。これらの関数は Amazon CloudWatch のイベントで、あるいは手動で実行できます。

それでは、15 秒の時間枠内に入札したユニーク入札者数を検出するため、アプリケーションを変更します。この時間枠は、ブロックチェーンにブロックを 1 つ追加するのに要する時間とほぼ同じです。変更するには、次のコードを Kinesis データ分析アプリケーションに追加します。

CREATE OR REPLACE STREAM DESTINATION_SQL_STREAM (
    NUMBER_OF_DISTINCT_ITEMS BIGINT
);

CREATE OR REPLACE PUMP "STREAM_PUMP" AS 
   INSERT INTO "DESTINATION_SQL_STREAM" 
      SELECT STREAM * 
      FROM TABLE(COUNT_DISTINCT_ITEMS_TUMBLING(
          CURSOR(SELECT STREAM * FROM "SOURCE_SQL_STREAM_001"),
            'Bidder',                                    
            10                                                 
      )
);

このコードの出力結果は、15 秒の時間枠内に生じたユニーク入札者の数です。これは、コントラクトに対し誰がトランザクションを実行しているのかを理解するのに役立ちます。たとえば、入札は多数のブロックチェーンアドレスによるものなのか、入札しているアドレス数は少なくなっているのかなどがわかります。

ようやく最後に、アーキテクチャ図で示したように、Kinesis データ分析アプリケーションへの出力先ストリームを追加できます。結果を保持するため、アプリケーションの出力を Kinesis Data Firehose に送信します。その後、結果データを Athena や他のツールによるバッチ分析に使用できるようになります。出力を送信するには、分析の出力ストリームの出力先を作成し、それを Kinesis Data Firehose で指定します。

このセクションでは、ブロックチェーンのトランザクションで実行可能なリアルタイム分析を説明してきました。次のセクションでは、保存したトランザクションに対する、Athena を使用したバッチ分析の実行を説明します。

Athena を使ったトランザクションの分析

このセクションでは、Athena にテーブルを作成し、バッチ形式のトランザクションデータにクエリできるようにします。

Athena にデータベースを作成し、次にテーブルを作成して、Kinesis Data Firehose に先に示した場所を指定します。設定は、次の例のようになります。

[次へ] を選択し、入力形式として JSON を選択してから、[次へ] をクリックします。
[列] に、各列のデータ型を入力します。[列の一括追加] を選択し、次の列情報をコピーして貼り付けます。

Block int, Blockhash string, Bidder string, Maxbidder string, Contractowner string, Amount int, Auction string, EventTimestamp string

列	説明
Block	このイベントに関連するブロック
Auction	イベントに関連するオークションのスマートコントラクト
ContractOwner	コントラクトの所有者のアドレス
Bidder	入札者のアドレス
BlockHash	ブロックの SHA ハッシュ
Address	トランザクションのアドレス
MaxBidder	現在の落札者のアドレス (現在からイベント生成まで)
Amount	入札総数

[次へ] をクリックし、テーブルを作成します。

Athena を設定した後は、データを調べることができます。まず、オークションを作成したユーザーが自身のオークションに入札しているかどうかを見ます。たいていのオークションでは、一般的にこのような入札は認められませんが、今回のスマートコントラクトでは禁止していません。コントラクトを変更して解決することもできますが、今回は Athena で検知可能かどうかを調べましょう。次のクエリを実行します。

select * from events where contractowner=bidder

ほぼ次のような結果になるはずです。

コントラクトの所有者が自身のコントラクトに入札しているインスタンスが、少なくとも 1 つ確認できるはずです。トランザクションを実行する Lambda 関数は、これをランダムに行う点に留意してください。自身のコントラクトに入札することは、差し支えない場合もありますが、オークションの条件に違反するかもしれません。その場合、この違反は簡単に発見できます。

今回のシナリオは、ブロックチェーンが支えるシステムにおいてコンプライアンス問題を発見し準拠させるための、分析の使用例です。スマートコントラクトに関連する規制やコンプライアンスの問題を発見することは、極めて複雑であることが多いため、多くのブロックチェーンユーザーにとって、コンプライアンスはなお未解決の問題です。分析は、こういった規制の問題について理解し、答えを求めるための、1 つの方法です。

トランザクションの分析に役立つクエリ

このセクションでは、スマートコントラクトの分析に使えるその他のクエリをいくつか紹介します。

ブロックごとのトランザクション数を調べる

SELECT block, COUNT(amount) as transactions FROM events Group By block

このクエリでは、次のような結果が出ます。

各オークションの落札を調べる

SELECT DISTINCT t.auction, t.amount
    FROM events t
        INNER JOIN (SELECT auction, MAX(amount) AS maxamount
                        FROM events
                        GROUP BY auction) q
            ON t.auction = q.auction
                AND t.amount = q.maxamount

このクエリでは、次のような一連の結果が出ます。

この結果は、ブロックチェーンに作成した各オークションと、その最高入札額を示しています。

Amazon QuickSight を使ったクエリの視覚化

プレーンな SQL でデータをクエリするのではなく、グラフィカルに分析を表示した方が便利な場合がよくあります。Amazon QuickSight でこれを実現できます。データソースには Athena が使用可能です。結果として、ほぼ苦労なく、すでに構築済みのものの上にダッシュボードソリューションを構築できます。Amazon QuickSight を使用し、Athena を介して Amazon S3 に保存したデータの可視化を行いましょう。

Amazon QuickSight では、新規のデータソースを作成すること、また先に作成した Athena のデータベースとテーブルを使用することができます。

新規のデータソースを作成するには

Amazon QuickSight コンソールを開き、[New Dataset] を選択します。
データソースの一覧から [Athena] を選択し、データソースに名前を付けます。

先に作成した Athena のデータベースとテーブルを選択します。

データを SPICE にインポートします。SPICE は素早いクエリとデータの可視化を実現する手段で、直接ソースデータに頼る必要がありません。SPICE の詳細については、Amazon QuickSight ドキュメントを参照してください。
[Visualize] を選択して、データの調査を開始します。

Amazon QuickSight を使用すると、シミュレーションしたブロックチェーンユーザーの行動を可視化できます。QuickSight のサイドペインから、測定値として [Amount] を、ディメンションとして [Auction] を選択します。これは、各オークションにいくらの Ether が入札されたかを示すものです。これを行うと、次のような結果が出ます。

数量は、ExecuteTransactions 関数を実行した回数によります。

MaxBidder を見る場合は、円グラフを確認します。グラフから、一番高い入札をもっとも多く行ったのはどのブロックチェーンアドレス（ユーザー）かがわかります。これは、次のようになります。

こういった種類の情報は、ブロックチェーンベースのアプリケーションでは入手困難な場合があります。しかし、Amazon QuickSight では、分析パイプラインにより、情報を簡単に手に入れることができます。

最後に、x 軸に [Eventtimestamp] を、y 軸に [block] を選択し、集計関数 (最小) を使用することで、Amazon QuickSight におけるマイニング時間を見ることができます。これは、次のような棒グラフを作成します。

グラフから、最初はブロック数が約 9,200 であり、安定したレートでマイニングが発生していることがわかります。これは大雑把に、約 15 ～ 20 秒のブロックマイニング時間と一致します。タイムスタンプが Unix 時間である点に注意してください。

このセクションでは、ブロックチェーンとそこにデプロイされたスマートコントラクトの両方の動作を理解するため、ブロックチェーンイベントで実行可能な分析について説明してきました。同じ手法を用いると、独自の分析パイプラインを構築して、ブロックチェーンを基本とする自身のアプリケーションに光を当てる有用な分析を実行することができます。

結論

ブロックチェーンは、大いなる可能性を秘めた先端技術です。AWS 分析サービスは、何千ものノード上で稼働し、何万ものトランザクションを扱うブロックチェーンアプリケーションについて情報を得るための手法を提供します。これにより、開発者はブロックチェーンアプリケーションの複雑性について理解を深め、また、新しいアプリケーションの作成に役立てることが可能になります。さらに、分析の部分はすべてサーバーのプロビジョニングなしで行えますから、インフラストラクチャを管理する必要性を低減できます。これにより、目的のブロックチェーンアプリケーションの構築に集中することができます。

重要: 必ず AWS CloudFormation で作成したスタックを完全に削除してください。また、ブロックチェーンイベントをリッスンする、スケジュール済みの Lambda 関数など、デプロイしたリソースも削除してください。

その他の参考資料

この記事が参考になった場合は、10 visualizatinos to try in Amazon QuickSight with sample data を使用してデータを最適化した Analyze Apache Parquetand や Analyzing Bitcoin Data: AWS CloudFormation Support for AWS Glue もぜひご覧ください。

著者について

Dr.Jonathan Shapiro-Ward は、トロントを拠点とする AWS のソリューションアーキテクトです。カナダ中のお客さまが業界をリードするクラウドソリューションを構築できるよう支援しています。専門は分散型システムとビッグデータで、セントアンドルーズ大学の博士号を取得しています。

Amazon Web Services ブログ