大負荷設計のFilecoinインデクサーのスケーラブルなソリューション
現在、拡張の道で最も緊急な目標は、増加している流入負荷を処理することです。この記事では、大量に流入するインデックス負荷をインデクサーノードで構成されたインデックスプールに分散させるためのシンプルな戦略について説明します。同時に、このインデックスプールにスケーラビリティを持たせます。
インデクサーの拡張の最終目標は10\^{15}個のインデックスです。これはデータを保存するバイトサイズではなく、インデックスの数を指します。1つのインデックスは、CID識別子とコンテンツ提供者データとの関係を示すマッピング図です。実際のデータ規模はこれをはるかに超えます。現在、私たちは約10\^{12}個のインデックスを処理できており、時間の経過とともに、一連のステップを通じて最終的な拡張目標に向かって進んでいきます。
現在、大部分のインデックス負荷は流入するインデックスデータで構成されています。新たに追加されるデータは、単一のインデクサーが処理できる範囲（速度と数量）を超える可能性があり、急速に増加しています。したがって、現在の拡張の最も緊急な目標は、増加する流入負荷を処理することです。
提案：インデックス流入を処理するシンプルな戦略
データ流入
インデクサーは、ある発行者からの「announce」メッセージを受信し、新しいインデックスデータの広告があることを発表すると、データ流入が発生します。これに応じて、そのインデクサーは発行者からまだ取得していないすべてのインデックスデータを取得します。発行者の数が増えるにつれて、ある時点で単一のインデクサーノードは新しいインデックスデータの発表速度に追いつけなくなり、すべてのデータを保存するための十分なストレージスペースがない可能性があります。
流入負荷の分散
インデクサーの拡張は、流入するインデックス負荷をインデクサーノードで構成されたインデックスプールに分散させるというシンプルな戦略に基づいています。これにより、容量の需要に応じてノードを追加でき、データを移動させて再均衡を図る必要がありません。まず、異なるコンテンツ 発行者 を異なるインデクサーノードに割り当て、各ノードが流入負荷の一部を処理できるようにします。これは、重要なインデックス流入経路の一部ではない独立した軽量サービスであるアサイナサービスを使用して実現されます。
インデクサーが設定されたストレージ制限に達すると、新しいインデックスデータの受け入れを停止し、インデックスプール内の他のインデクサーが完全なインデクサーに割り当てられた発行者からデータの受け入れを再開します。ストレージ容量と流入負荷の配分要求が増加すると、プール内にさらに多くのインデクサーノードが追加されます。
この拡張戦略の3つの主要なコンポーネントは次のとおりです：
アサイナサービス（Assigner Service）：発行者をインデクサーに割り当てます。
インデクサーフリーズモード（Indexer Frozen Mode）：このインデクサーの運用モードでは、新しいコンテンツはインデックスされません。
発行者タスクの移譲：フリーズ中のインデクサーの発行者タスクをアクティブなインデクサーに再割り当てし、フリーズインデクサーが停止した後にインデックスを再開します。
この記事では、これらのコンポーネントを概説します。詳細については、設計文書および設計展示を参照してください。
拡張戦略の利点と欠点
利点：
同期作業の削減：すべてのインデクサーがすべての発行者と同期する必要がありません。
メタデータは複数のインデクサーに再送信されません（これはキーシャーディングと同様です）：メタデータは、提供者のインデクサーでのみ存在します。
インデクサー間でデータを共有しません。それぞれが独自の発行者チェーンを管理します。
提供者を確認するために広告を読む必要はありません（これは提供者シャーディングと同様です）。
インデクサーは異なるストレージ容量を持つことができます。
コンセンサスメカニズムは必要ありません。
流入負荷は再配分可能で、インデクサー間でデータを移動させる必要はありません。
欠点：
不均等な配分：一部の発行者は他の発行者よりも多くのデータをインデックスする可能性があります。
クエリ要求は分散して統合する必要があります：クエリ要求はすべてのインデクサーに繰り返し送信され、応答は顧客に送信される1つに統合されます。
提供者が発行者を変更すると、重複インデックスが発生する可能性があります（これは提供者シャーディングとは異なります）。
インデクサーを追加しても、既存のインデクサーがストレージ容量制限に達するまで効果はありません。
この戦略の全体的な利点は、その実施が比較的簡単であり、混雑した拡張の制限を取り除くことができることです。
アサイナサービス（Assigner Service）
アサイナサービス（AS）は、発行者をその構成インデクサープール内のインデクサーに割り当てる役割を担います。インデクサープールに対して、単一のインスタンスとしてその管理するインデクサーが存在する同じネットワーク上で実行されます。1つのインデクサーは、1つのアサイナサービスのインデクサープールのメンバーとしてのみ機能します。
新しい発行者をインデクサーに割り当てることに加えて、アサイナサービスは、インデクサーノードがフリーズモードに入ったかどうかを検出し、フリーズインデクサーから発行者を非フリーズのインデクサーに再割り当てる責任を負います。インデックスサービスは、gossip pubsubチャネルを介して直接HTTP公告を再発行し、プール内のすべてのインデクサーがこれらの情報を受け取れるようにします。
いくつかの仮定に基づいて、アサイナサービスは単一のプライベートデプロイメントで使用されます：タスクは任意のインデクサーに送信でき、すべてのインデクサーの管理APIはプライベートネットワーク上で実行され（または類似の保護されたネットワーク）、異なる参加者がプール内のノードを追加または削除するための方法やプロトコルは確立されていません。
発行者をインデクサーに割り当てる
インデクサーは、ある発行者からの「announce」メッセージを受信し、新しいインデックスデータの広告があることを発表すると、アサイナサービスはgossip-subおよび直接のHTTPメッセージを監視します。これらのメッセージは主に新しい広告（advertisements）が取得可能であることを発表します。アサイナサービスは、各メッセージから発行者情報を読み取り、発行者が必要なインデクサーに割り当てられているかどうかを判断します。もし割り当てられていなければ、アサイナサービスはタスク量が最も少ないインデクサーを選択し、その発行者をそのインデクサーに割り当てます。タスクが割り当てられた後、インデクサーは発行者からの公告を受け取り、流入データを自ら処理します。
インデックスサービスはオフラインのインデクサーを処理し、その方法はインデクサープール内でのタスクの過剰割り当てを回避します。インデックスサービスは、特定の発行者を特定のインデクサーに割り当てるための設定オプションもサポートしています。
さらなる読み物：
非永続的タスク状態（No Persisted Assignment State）(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#no-persisted-assignment-state)は、インデクサーがいつでも停止または再起動できることを意味します。
インデクサープール（An Indexer Pool）(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#indexer-pool)は、特定のデプロイメント内のインデクサーノードの集合です。
タスク複製（Assignment Replication）(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#replication)は、発行者を複数のインデクサーに割り当てます。
インデクサーフリーズモード
インデクサーは、設定された `FreezeAtPercent(\<``https://pkg.go.dev/github.com/ipni/storetheindex/config#Indexer`(https://pkg.go.dev/github.com/ipni/storetheindex/config#Indexer "https://pkg.go.dev/github.com/ipni/storetheindex/config#Indexer")`>)` の制限に達すると、自動的に「フリーズ」モードに入ります。この運用モードでは、インデクサーは新しいインデックスデータを保存しなくなりますが、インデックスデータの更新や削除は処理します。フリーズされたインデクサーは新しい発行者タスクを受け入れません。その内部では、インデクサーは読み取った各広告チェーンを追跡し、広告（更新および削除タスクに関連する）を取り込むことを目的としています。インデクサーは、インデックスデータに対するクエリに応じ続けます。
インデクサーは、管理（admin）APIを通じて手動でフリーズすることもできます。これは、インデクサーのストレージ容量が増加するまでデータの取り込みを一時的にフリーズするためです（またはアサイナサービスを使用）。このようにして、継続的なインデックス作業は他のインデクサーノードによって代替されることができます。
さらなる読み物：
ディスク使用監視（Disk Usage Monitoring）(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#disk-usage-monitoring)は、各インデクサーが担当します。
フリーズ機能はアサイナサービスに依存しません（Freeze capability does not depend on AS）(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#freeze-independent-of-assigner)。
フリーズ解除機能(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#unfreeze)は、インデクサーがインデックス作業を再開できるようにします。
発行者の移譲
アサイナサービスは定期的にインデクサーを監視し、フリーズされたインデクサーを発見した場合、そのフリーズされたインデクサーが割り当てた発行者を他のインデクサーに再割り当てます。アクティブなインデクサーは、以前のフリーズインデクサーで行われた作業を続行します。移譲の過程で、アクティブなインデクサーはフリーズされたインデクサーから提供者および関連情報を取得します。
アサイナサービスは、どのインデクサーが発行者の移譲作業を受け取るかを決定します。これは新しい発行者を割り当てるロジックと同様です。各発行者の移譲プロセスは個別に行われ、このようにしてフリーズインデクサーのタスクがプール内の利用可能なインデクサーに割り当てられます。
さらなる読み物：
アサイナサービスは不完全な移譲タスクを再開できます(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#resuming-incomplete-handoff)。
発行者データはフリーズされたインデクサーとアクティブなインデクサーの間で分配されます。(https://github.com/ipni/storetheindex/blob/main/doc/scaling-design-for-indest.md#publisher-data-spread-across-frozen-and-active-indexers)
アサイナサービスを持つインデクサープールの設立
ここ(https://github.com/ipni/storetheindex/blob/main/doc/assigner-deployment.md#setting-up-indexer-pool-with-assigner-service)では、アサイナサービスを持つインデクサープールの設立プロセスについて説明しています。以下のステップに要約できます：
インデクサーのデプロイ（Deploy Indexers）(https://github.com/ipni/storetheindex/blob/main/doc/assigner-deployment.md#deploy-indexers)
アサイナサービスのデプロイ（Deploy Assigner Service）(https://github.com/ipni/storetheindex/blob/main/doc/assigner-deployment.md#deploy-assigner-service)
必要に応じて追加のインデクサーをデプロイ（Deploy additional Indexers as needed）(https://github.com/ipni/storetheindex/blob/main/doc/assigner-deployment.md#example-assigner-service-configuration)
ここでは、アサイナサービスの設定テンプレートファイル(https://github.com/ipni/storetheindex/blob/main/doc/assigner-deployment.md#example-assigner-service-configuration)も提供されています。
