展開する > サブグラフをホスティングサービスにデプロイする

サブグラフをホスティングサービスにデプロイする

Reading time: 14 min

Hosted Service でネットワークがサポートされていない場合は、独自の graph-node を実行してインデックスを作成できます。

このページでは、ホスティングサービスにサブグラフをデプロイする方法について説明します。サブグラフを配置するためには、まずGraph CLIをインストールする必要があります。まだサブグラフを作成していない場合は、サブグラフを作成するを参照してください。

ホスティングサービスのアカウントを作成する

⁠このセクションへのリンク

ホスティングサービスを使用する前に、ホスティングサービスのアカウントを作成します。そのためにはGithubアカウントが必要です。アカウントをお持ちでない場合は、まずそれを作成する必要があります。その後、ホスティングサービスに移動し、「'Sign up with Github'」ボタンをクリックして、Github の認証フローを完了させます。

アクセストークンの保存

⁠このセクションへのリンク

アカウントの作成後、dashboardに移動します。ダッシュボードに表示されているアクセストークンをコピーし、graph auth --product hosted-service <ACCESS_TOKEN>を実行します。これでアクセストークンがあなたのコンピュータに保存されます。この作業は 1 回だけ行う必要がありますが、アクセストークンを再生成する場合も同様です。

ホステッドサービスでのサブグラフの作成

⁠このセクションへのリンク

サブグラフをデプロイする前に、グラフエクスプローラーでサブグラフを作成する必要がある。ダッシュボードにアクセスし、「 'Add Subgraph' 」ボタンをクリックして、以下の情報を適宜入力してください。

Image - サブグラフのプレビュー画像やサムネイルとして使用する画像を選択します。

Subgraph Name - サブグラフが作成されるアカウント名と一緒に、デプロイメントや GraphQL エンドポイントで使用されるaccount-name/subgraph-nameのスタイル名も定義します。このフィールドは後で変更できませんこのフィールドは後で変更できません。

Account - サブグラフが作成されるアカウントです。これは個人または組織のアカウントになります。サブグラフは後でアカウント間で移動できません。

Subtitle - サブグラフカードに表示されるテキストです。

Description - サブグラフの説明、サブグラフの詳細ページで表示されます。

GitHub URL - GitHub 上のサブグラフのリポジトリへのリンクです。

Hide - これをオンにすると、Graph Explorer でサブグラフが非表示になります。

新しいサブグラフを保存すると、Graph CLI のインストール方法、新しいサブグラフの足場の生成方法、サブグラフのデプロイ方法についてのヘルプ画面が表示されます。最初の 2 つのステップは、「Define a Subgraph section」で説明しました。

ホステッドサービス上でのサブグラフのデプロイ

⁠このセクションへのリンク

サブグラフのデプロイでは、yarn buildで構築したサブグラフ・ファイルを IPFS にアップロードし、これらのファイルを使用してサブグラフのインデックス作成を開始するようグラフ・エクスプローラーに指示します。

サブグラフのデプロイは、yarn deployを実行して行います。

サブグラフをデプロイした後、Graph Explorer はサブグラフの同期ステータスを表示するように切り替わります。ジェネシスブロックから始めて、履歴ブロックから抽出する必要があるデータの量とイベントの数に応じて、同期には数分から数時間かかる場合があります。

グラフノードが履歴ブロックからすべてのデータを抽出すると、サブグラフのステータスは Synced に切り替わります。これらのブロックがマイニングされると、グラフノードはサブグラフのブロックを検査し続けます。

サブグラフの再デプロイ

⁠このセクションへのリンク

エンティティ・マッピングの問題を修正するなど、サブグラフの定義に変更を加える場合は、上記のyarn deploy コマンドを再度実行して、サブグラフの更新版をデプロイします。サブグラフを更新する際には、グラフ・ノードがサブグラフ全体のインデックスを再作成する必要があります。

以前にデプロイされたサブグラフがまだSyncingの状態にある場合は、新しくデプロイされたバージョンにすぐに置き換えられます。以前にデプロイされたサブグラフがすでに完全に同期されている場合、グラフノードは新しくデプロイされたバージョンを「Pending Version」としてマークし、バックグラウンドで同期を行い、新しいバージョンの同期が終了してから、現在デプロイされているバージョンを新しいバージョンに置き換えます。これにより、新しいバージョンが同期している間も、サブグラフを使って作業することができます。

サブグラフを複数のネットワークにデプロイする

⁠このセクションへのリンク

場合によっては、すべてのコードを複製せずに、同じサブグラフを複数のネットワークに展開する必要があります。これに伴う主な課題は、これらのネットワークのコントラクトアドレスが異なることです。

graph-cliを使用する

⁠このセクションへのリンク

graph build (v0.29.0 から) と graph deploy (v0.32.0 から) は共に、二つの新しいオプションを受け入れるようになりました。

Options:

      ...
      --network <name>          Network configuration to use from the networks config file
      --network-file <path>     Networks config file path (default: "./networks.json")

--network オプションで、json 標準ファイル（デフォルトは networks.json ）からネットワーク設定を指定して、開発中にサブグラフを簡単に更新することが可能です。

Note: init コマンドは提供された情報に基づいて networks.json を自動生成するようになりました。これにより、既存のネットワークを更新したり、追加したりすることができます。

networks.jsonファイルがない場合は、以下の構造で手動で作成する必要があります:

{
    "network1": { // the network name
        "dataSource1": { // the dataSource name
            "address": "0xabc...", // the contract address (optional)
            "startBlock": 123456 // the startBlock (optional)
        },
        "dataSource2": {
            "address": "0x123...",
            "startBlock": 123444
        }
    },
    "network2": {
        "dataSource1": {
            "address": "0x987...",
            "startBlock": 123
        },
        "dataSource2": {
            "address": "0xxyz..",
            "startBlock": 456
        }
    },
    ...
}

Note: 設定ファイルではtemplates（もしあれば）を指定する必要はなく、dataSourcesだけを指定すればよいでしょう。もし、subgraph.yamlファイルで宣言されたtemplatesがあれば、それらのネットワークは自動的に--networkオプションで指定したものに更新されます。

ここで、サブグラフをmainnetとgoerliネットワークにデプロイできるようにしたいと仮定し、これがsubgraph.yamlであるとしましょう:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    source:
      address: '0x123...'
      abi: Gravity
    mapping:
      kind: ethereum/events

ネットワーク設定ファイルはこのようになっているはずです:

{
  "mainnet": {
    "Gravity": {
      "address": "0x123..."
    }
  },
  "goerli": {
    "Gravity": {
      "address": "0xabc..."
    }
  }
}

これで、次のいずれかのコマンドを実行できるようになりました:

# Using default networks.json file
yarn build --network goerli

# Using custom named file
yarn build --network goerli --network-file path/to/config

buildコマンドは、subgraph.yamlをgoerliの設定で更新し、サブグラフをリコンパイルします。subgraph.yamlファイルは、以下のようになります:

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: goerli
    source:
      address: '0xabc...'
      abi: Gravity
    mapping:
      kind: ethereum/events

これでyarn deployの準備が整いました。

Note: 前述のように、graph-cli 0.32.0 からは --network オプションで直接 yarn deploy を実行できるようになりました:

# Using default networks.json file
yarn build --network goerli

# Using custom named file
yarn build --network goerli --network-file path/to/config

subgraph.yamlテンプレートの使用

⁠このセクションへのリンク

古いバージョンのgraph-cliで、コントラクトアドレスのような側面をパラメータ化できるようにする一つの解決策は、Mustache や Handlebars などのテンプレートシステムを使ってその一部を生成することです。

この方法を説明するために、あるサブグラフが異なるコントラクトアドレスを使用してmainnetと Goerliにデプロイされるべきだと仮定してみましょう。その場合、各ネットワークのアドレスを提供する 2 つのconfigファイルを定義することができます。

{
  "network": "mainnet",
  "address": "0x123..."
}

and/と

{
  "network": "goerli",
  "address": "0xabc..."
}

また、マニフェストのネットワーク名とアドレスを変数プレースホルダー{{network}}と{{address}}で置き換え、マニフェストの名前を例えばsubgraph.template.yamlに変更します。

# ...
dataSources:
  - kind: ethereum/contract
    name: Gravity
    network: mainnet
    network: {{network}}
    source:
      address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
      address: '{{address}}'
      abi: Gravity
    mapping:
      kind: ethereum/events

どちらのネットワークにも対応したマニフェストを生成するには、package.jsonにmustacheへの依存関係とともに 2 つのコマンドを追加します:

{
  ...
  "scripts": {
    ...
    "prepare:mainnet": "mustache config/mainnet.json subgraph.template.yaml > subgraph.yaml",
    "prepare:goerli": "mustache config/goerli.json subgraph.template.yaml > subgraph.yaml"
  },
  "devDependencies": {
    ...
    "mustache": "^3.1.0"
  }
}

このサブグラフをmainnetやGoerliにデプロイするには、次の 2 つのコマンドのどちらかを実行するだけです:

# Mainnet:
yarn prepare:mainnet && yarn deploy

# Goerli:
yarn prepare:goerli && yarn deploy

この例は、こちらでご覧いただけます。

注: このアプローチは、より複雑な状況にも適用できます。たとえば、コントラクトアドレスやネットワーク名以外のものを置き換える必要がある場合や、テンプレートからマッピングや ABI を生成する場合にも適用できます。

サブグラフのヘルスチェック

⁠このセクションへのリンク

サブグラフが正常に同期された場合、それはそれが永久に正常に動作し続けることを示す良い兆候です。ただし、ネットワーク上の新しいトリガーにより、サブグラフがテストされていないエラー状態に陥ったり、パフォーマンスの問題やノードオペレーターの問題により遅れが生じたりする可能性があります。

グラフノードは、サブグラフの状態をチェックするためにクエリを実行できる graphql エンドポイントを公開しています。ホステッドサービスでは https://api.thegraph.com/index-node/graphqlで利用できます。ローカルノードでは、デフォルトではポート8030/graphqlで利用できます。このエンドポイントの完全なスキーマはこちらにあります。以下は、サブグラフの現在のバージョンのステータスをチェックするクエリの例です:

{
  indexingStatusForCurrentVersion(subgraphName: "org/subgraph") {
    synced
    health
    fatalError {
      message
      block {
        number
        hash
      }
      handler
    }
    chains {
      chainHeadBlock {
        number
      }
      latestBlock {
        number
      }
    }
  }
}

これにより、chainHeadBlockが得られ、サブグラフのlatestBlockと比較して、遅れているかどうかを確認できます。 syncedは、サブグラフがチェーンに追いついたかどうかを通知します。healthは現在、エラーが発生していない場合はhealthy、サブグラフの進行を停止させるエラーが発生した場合はfailedという値を取ることができます。この場合、このエラーの詳細についてfatalErrorフィールドを確認できます。

ホスティングサービス・サブグラフ・アーカイブポリシー

⁠このセクションへのリンク

ホステッドサービスは、無料の Graph Node Indexer です。開発者は、さまざまなネットワークをインデックス化したサブグラフを配置することができます。サブグラフはインデックス化され、GraphQL を介したクエリで利用できるようになります。

アクティブなサブグラフに対するサービスのパフォーマンスを向上させるために、ホステッドサービスは非アクティブなサブグラフをアーカイブします。

サブグラフが45日以上前にホステッドサービスにデプロイされ、過去45日間に0回のクエリを受けた場合、そのサブグラフは「非アクティブ」と定義されます。

サブグラフが削除される 7 日前に「非アクティブ」と判定されると、開発者にメールで通知されます。サブグラフを「アクティブ」にしたい場合は、サブグラフの Hosted Service graphQL playground でクエリを実行することで可能です。開発者は、アーカイブされたサブグラフが再び必要になった場合、いつでも再デプロイすることができます。

Subgraph Studio・サブグラフ・アーカイブポリシー

⁠このセクションへのリンク

サブグラフの新しいバージョンがデプロイされると、以前のバージョンはアーカイブされます（グラフノードのDBから削除されます）。これは、以前のバージョンがThe Graphの分散型ネットワークに公開されていない場合にのみ発生します。

45日以上クエリがない場合、そのサブグラフのバージョンはアーカイブされます。

このポリシーで影響を受けるすべてのサブグラフには、問題のバージョンを戻すオプションがあります。