Algorandのための軽量で柔軟なデータ・アクセス
Algorandは、ブロックチェーン・データ・アクセスのための新ツールをリリースしました：Conduit（コンデュイット）です。Conduitはモジュール式のプラグイン・ベースのツールで、サイズを問わずIndexerを強力にアップグレードするものです。Conduitを使用することで、Dappsは手頃なデプロイメントで必要なデータを正確に取得することができます。
便利だけど、かさばる：Indexer
Indexerは、ブロックチェーンからデータを取り出し、データベースに保存し、そのデータを提供するためのAPIを提供する、すぐに使えるオープンソースのツールです。Indexerの存在は、Algorandエコシステムにとって大きな恩恵であり、誰でも簡単にAlgorandブロックチェーンを読むことができるようになりました。
しかし、Indexerには歴史的に1つの大きな欠点がありました。それは、運用コストが高いということです。その理由は主に2つあります：
Indexerを実行するには、ブロックチェーンの開始時からのすべてのブロックを保存するアーカイブ・ノードも実行する必要がある。
Indexerはブロックチェーンの全履歴（ブロック・ゼロ以降の全取引）をPostgresデータベースに収集する。
これらの事実から、Indexerはマルチ・テラバイトのデプロイメントになります。典型的なIndexerは高価なリソースをいくつも必要とし、これらは冗長性、負荷分散、複数の地域をカバーする必要がある本番展開の場合には倍増します。
また、Indexerの規模が大きいと、初期化が遅くなり、インデックスを作成した特定のクエリにしか対応できなくなります。Algorandブロックチェーンが成長するにつれ、小規模なプロジェクトが独自のIndexerを維持することは非現実的になってきました。
その結果、エコシステムはほとんど少数のAPI/データ・プロバイダに依存しています。これらのプロバイダはIndexerを運営し、API呼び出しのためにdappsに課金します。これは、各グループが独自のIndexerを運営するよりも経済的で実用的ですが、他の柔軟性に欠ける点があります。
Dappsには、自分たちでデータ・アクセス基盤を持つというアクセスしやすいオプションが必要です。そのために作られたのがConduitです。
Conduit、その基本
Conduitは、いくつかの大きな利点を持つ新しいソリューションです：
Conduitは、アーカイバルalgodノードを実行する必要がありません。
Conduitは、ユーザーが受信するブロックチェーン・データをフィルタリングできるため、アプリケーションに必要なデータのみを厳密に収集することができます。
Conduitは、データ刈り込み機能を提供しており、刈り込みが有効な場合、ユーザーは古いトランザクションを自動的に削除することができます。
Conduitでは、ユーザーは選択したデータ送信先を使用するカスタム・データ・エクスポータを構築することができます。
Conduitは、拡張可能なプラグイン・アーキテクチャとして設計されています。コミュニティから提供されたプラグインは、誰でも統合することができます。
Conduitでは、Algorandネットワーク上のトランザクションやアカウントのフィルタリング、アグリゲーション、ストレージのための独自のデータ・パイプラインを構成することができます。
Conduitのパイプラインは、インポータ、オプションのプロセッサ、エクスポータのプラグインで構成されています。Conduitのリリースに伴い、以下の注目すべきプラグインが利用可能になりました。
Algod importer - algod REST APIからブロックをフェッチします。
フィルタ・プロセッサ - トランザクション・フィールドに基づいてデータをフィルタリングします。
Postgresエクスポータ - データをPostgresデータベースに書き出します。
ファイル・ライター・エクスポータ - データをファイルに書き込みます。
Conduitパイプラインを構成するには、どのプラグインを使用するかを定義し、必要に応じてプラグインを構成する必要があります。例えば、フィルタ・プロセッサでは、何をフィルタリングするのかの定義が必要です。
これは例で示すのが一番です。基本的なウォークスルーはこちらでご覧ください。
Conduitのフィルター・プロセッサ
フィルター・プロセッサは、Conduitで導入された重要な新機能です。トランザクションの種類、アプリID、アセットID、送信者、受信者、金額など、あらゆるトランザクション・フィールドに基づいてトランザクション・データをフィルタリングすることができます。また、これらのフィルターは組み合わせることもできます。
多くのトランザクションはグループ化されたトランザクションとして送信されるため、フィルター・プロセッサでは、フィルター条件が満たされたときにトランザクション・グループ全体を含めるかどうかをユーザーが選択することができます。
フィルター・プロセッサは、指定されたフィルター条件に一致するトランザクションについては、常にインナー・トランザクションを含めます。
フィルター・プロセッサに関する詳細は、こちらをご覧ください。
Conduitの新しいノード構成：フォロー・モード
Conduitは、ブロックチェーンのデータを追跡し、オフチェーンの世界で利用できるようにするために使用されます。オンチェーンで新しいブロックが作成されるたびに、Conduitは、新しいアカウントの作成、アプリの状態の更新、ボックスの削除など、前のブロック以降のすべての状態の変更について情報を得ます。
ApplyDataと呼ばれるオブジェクトを使用して、いくつかの種類の状態変化を追跡するDappsもありますが、この方法は技術的に制限されています。すべての変更がこのオブジェクトに反映されるわけではなく、ApplyDataは非アーカイブ・ノードで4ラウンドしかキャッシュされないため、ApplyDataの更新処理を15秒以上遅らせると、回復不可能なステート・エラーになります。
古いIndexerアーキテクチャでは、アーカイブのalgodノードへのアクセスを要求することで、これらの課題を解決していました。Indexerは「ローカル台帳」を使ってラウンドからラウンドへの状態変化を追跡することで、不完全なApplyDataオブジェクトを回避していました。この設計の欠点は、高価なアーカイバル・ノードが必要なことです。
Conduitはその代わりに、新しい軽量の「フォロー・モード」構成のノードへのアクセスを必要とし、アーカイブ構成の必要性を置き換えます。Conduitは必要に応じて、このノードのラウンド・アップデートを一時停止したり解除したりすることができます。一時停止機能により、Conduitプロセスはブロックチェーンの状態更新を見逃すことがありません。Conduitはまた、ノードに導入された新しい「状態デルタ」エンドポイントを利用し、大規模なローカル台帳の必要性を排除しています。
フォロー・モードが有効なノードは、一時停止した状態情報に基づく投票が拒否されるため、コンセンサスに参加することはできません。同様に、このようなノードにトランザクションを提出することもできません。一時停止された古い状態の情報に基づく受け入れは、ブロックチェーンの他の部分から無効と判断される可能性があるからです。
拡張可能なツールとしてのConduit
オープンソースの原則と分散化に焦点を当てたConduitのデザインは、カスタムビルドのソリューションを奨励し、Indexerとは一線を画しています。最初のリリースでは、ConduitリポジトリへのPRを通じて、新しいプラグインの提出を奨励しています。私たちは、プラグインのフレームワークがコミュニティの参加を促し、誰もが共有の努力から利益を得ることができるようにすることを目指しています。現在、外部でサポートされているプラグインの長期的な最適な管理方法を特定するために、コミュニティを巻き込んでいます（Discord #conduit channelで会話に参加しましょう！）。
すでにコミュニティメンバー（DiscordのIridium#4127）によるKafkaプラグインの開発を見てきましたが、彼はConduitについて次のように語っています：
「...Conduitでは、対象となる製品（例：Kafka）を選択して、すぐにプラグインを構築し、データを流すことができます。主に、正しいライブラリをインポートして、接続を設定し、ライブラリを使用してシステムにメッセージを送信するだけです。受信はすでにConduitで処理されています。」
デプロイメントを比較する：レガシーIndexerとConduitアーキテクチャの比較
Indexer、レガシー・アーキテクチャ
アーカイバルalgodノードが必要で、1.1TB以上のストレージが必要です。
完全な履歴データを持つPostgresデータベース、または1.5 TBのストレージが必要です。
上記のソース：Howbigisalgorand.com
Conduitアーキテクチャ
「フォロー・モード」が有効なノードが必要で、40GBのストレージが必要です（他の非アーカイブ・ノードと同様）。
Conduitは、Postgresデータベース、または別のデータストアを使用できます。ユーザは完全な履歴データ、またはサブセットを保存することができます。これは、全履歴を保存する場合は最大で1.5TB、数GB程度になる可能性があります。
これらの導入コストは、ユーザーがセルフホストかクラウド・プロバイダを利用しているかによって異なります（プロバイダによって大きく異なります）。しかし、Conduitでバックアップされたデプロイメントでは、ストレージのコストは厳密には少なくなるはずです。
ストレージが主要なコスト要因になる可能性が高く、帯域幅とコンピューティングの要件はどちらのアーキテクチャでも同様であることに注意してください。
Indexerの継続的なサポート
現時点では、旧アーキテクチャ（アーカイブ・ノードを使用）を実行するIndexerの既存リリースのサポートを継続します。もし、ユーザーがIndexerの使用を継続したいが、アーカイブ・ノードの必要性を排除してコストを削減したい場合は、ConduitによってバックアップされたIndexerを実行するオプションがあります。Indexerのインターフェースは変わりません。移行ガイドはこちらをご覧ください。
Conduitはより良いアプリを構築する
Conduitは柔軟で拡張性が高く、開発者がニーズに合ったデータ・ソリューションを構築できるように意図して設計されています。そのため、Conduitには数え切れないほどの用途があります。
Conduitを使用して、ダップレポートの必要性をサポートしたいですか？
Indexer APIを拡張したいですか？
オンチェーン・イベントに基づくイベント駆動型システムを構築したいですか？
CockroachDBを使用してAPIプロバイダ・サービスを拡張したいですか？
S3にすべてをダンプして、それをクエリにしたいですか？
Indexerの硬直性によって課された制限は、もはや適用されません。Conduitはすべてを無料で提供するわけではありませんが、ユーザーが必要とするものを柔軟に構築できるようになっています。
元記事：https://medium.com/algorand/lightweight-and-flexible-data-access-for-algorand-2051763ad8d0