IPFS 게이트웨이의 실용적인 설명

HOME

IPFS 뉴스

IPFS 게이트웨이의 실용적인 설명 – 두번째

이은혜 기자
|
입력 2022-07-05 09:29
|
수정 2022-07-05 09:29

▲IPFS 게이트웨이의 실용적인 설명 – 두번째

IPFS는 파일과 웹사이트를 저장하고 접근하기 위한 P2P 프로토콜이다. 분산 피어 투 피어 프로토콜로서, HTTP 프로토콜과는 근본적으로 다르다. IPFS 게이트웨이의 도움으로 HTTP 프로토콜을 사용하여 IPFS의 이점을 얻을 수 있다.

이 블로그 게시물은 IPFS 게이트웨이에 대한 2부작 시리즈 중 두 번째이다.

일부에서는 대부분 이론적인 내용이었지만 클라이언트-서버 모델의 문제와 IPFS가 피어 투 피어 네트워킹 및 컨텐츠 어드레싱을 통해 이러한 문제에 접근하는 방법을 배웠다. 그런 다음 IPFS와 HTTP(S) 및 IPFS 게이트웨이 간의 관계에 대해 배웠으며 마지막으로 IPFS 게이트웨이에서 이미지를 가져와 IPFS 게이트웨이 확인 스타일에 대해 다뤘다.

이부에서는 실제 응용 프로그램에서 IPFS 게이트웨이를 사용하는 데 필요한 유용한 팁과 요령을 다룰 예정이다.

이 블로그 게시물을 마치면 문제에 직면했을 때 IPFS 게이트웨이를 자신 있게 체계적으로 디버그할 수 있는 지식과 도구를 갖추게 될 것이다.

참고: 블로그에서 가장 널리 사용되는 IPFS 구현, kubo(최근까지 go-ipfs로 알려짐)를 사용한다고 가정한다. 이는 js-ipfs와 같은 다른 구현에서 천둥을 없애기 위한 것이 아니다.

IPFS HTTP 게이트웨이의 일반적인 문제

다양한 커뮤니티 채널에서 IPFS를 사용하는 개발자가 가장 자주 묻는 질문 중 하나는 공용 IPFS 게이트웨이를 통해 CID를 검색할 수 없는 이유 또는 CID가 로딩되는 속도가 느린 이유이다.

예를 들어 로컬 IPFS 노드에 처음 콘텐츠를 업로드할 때 공용 게이트웨이에서 CID를 요청하는데 이때 504 게이트웨이 시간 초과가 발생하는 경우가 드물지 않다.

IPFS 게이트웨이는 친숙한 HTTP 인터페이스를 제공하면서 IPFS의 분산된 측면을 추상화하지만, 그렇다고 복잡성이 사라지는 것은 아니다.

전반적으로 IPFS 게이트웨이에서 CID를 가져오는 문제(느림 또는 시간 초과)에 직면할 경우 일반적으로 다음 중 하나와 관련이 있다.

IPFS 게이트웨이.
CID 제공자, 즉 CID를 고정하는 IPFS 노드에 연결할 수 없거나 중단되었을 수 있다.
사용자(또는 고정 서비스)가 IPFS 네트워크에 CID를 제공하지 않는다. 제공은 지정된 CID의 제공자가 이를 DHT(분산 해시 테이블)에 보급하여 검색하게 만드는 프로세스이다.
클라이언트와 IPFS 게이트웨이 또는 게이트웨이와 공급자 간의 네트워크 지연 시간.

이 모든 요소를 고려할 때, 포괄적인 조언을 하는 것은 어렵다. 여기서 IPFS 게이트웨이에 대한 CID 요청의 수명 주기를 이해하는 것이 유용한데, 이는 디버깅 문제를 신속하게 처리할 수 있다.

IPFS 게이트웨이 요청 수명 주기

CID에 대한 요청이 IPFS 게이트웨이에 도달하면 게이트웨이는 네트워크에서 검색하기 전에 CID가 로컬로 캐시되었는지 확인한다.

CID가 게이트웨이의 캐시에 있는 경우, 게이트웨이는 CID의 내용으로 HTTP 요청에 응답한다.

참고: 여기서 캐시는 HTTP 캐시이거나 IPFS 노드의 로컬 데이터 저장소일 수 있다.

CID가 캐시에 없으면 IPFS 네트워크에서 CID를 검색해야 한다. 이 프로세스는 두 번째 단계이다.

콘텐츠 검색/라우팅: 직접 피어를 요청 및 DHT를 질의문 하여 CID(공급자)를 제공하는 피어의 피어 ID 및 네트워크 주소를 찾는다.
콘텐츠 검색: 공급자 중 하나에 연결하고 CID의 콘텐츠를 가져오고 클라이언트에 응답을 스트리밍한다.

참고: 이것은 게이트웨이가 CID를 제공하는 IPFS 노드와 분리되어 있다고 가정한다. 그러나 많은 경우에 동일하다. 예를 들어 게이트웨이이기도 한 CID를 고정하는 자체 호스트 IPFS 노드를 실행하는 경우 콘텐츠 검색이 즉시 수행된다.

IPFS 콘텐츠 검색 및 검색 디버깅

게이트웨이에서 CID를 검색할 수 없는 이유를 디버깅할 때 가장 유용한 방법은 근본 원인을 좁히는 것이다.

이는 콘텐츠 라우팅 문제 (DHT에서 CID에 대한 공급자 레코드 찾기) 또는 콘텐츠 검색 문제(DHT의 공급자 레코드에서 피어에 연결)일 수 있다.

#kubo 및 IPFS를 사용한 디버깅 확인

실행 중인 kubo(전 go-ipfs)를 실행 중인 경우IPFS 노드를 통해 다음 명령을 실행하여 피어가 CID를 알리고 있는지 확인한다.

ipfs dht findprovs [CID]

DHT를 검색하여 CID 공급자를 찾으면 해당 피어 ID가 반환된다.

12D3KooWChhhfGdB9GJy1GbhghAAKCUR99oCymMEVS4eUcEy67nt 12D3KooWJkNYFckQGPdBF57kVCLdkqZb1ZmZXAphe9MZkSh16UfP QmQzqxhK82kAmKvARFZSkUVS6fo9sySaiogAnx5EnZ6ZmC 12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT

공급자가 반환되지 않은 경우 콘텐츠 게시가 문제의 원인일 수 있다. 콘텐츠 게시가 작동하는 방식과 이러한 문제를 해결하는 방법을 알아보려면 다음 섹션으로 건너뛰어야 한다.

공급자 레코드(피어 ID 목록)가 발견된 경우 다음 명령을 사용하여 해당 피어 중 하나의 네트워크 주소를 가져온다.

ipfs id -f '<addrs>' [PEER_ID]

이 명령의 결과는 다음과 같다:

/ip4/145.40.90.155/tcp/4001/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT /ip4/145.40.90.155/tcp/4002/ws/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT /ip6/2604:1380:45e1:2700::d/tcp/4001/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT /ip6/2604:1380:45e1:2700::d/tcp/4002/ws/p2p/12D3KooWSH5uLrYe7XSFpmnQj1NCsoiGeKSRCV7T5xijpX2Po2aT

반환된 주소에서 CID를 검색할 수 있는지 확인하려면 공용 주소 중 하나와 CID를 복사하여 IPFS에 확인:

IPFS 검사는 피어/노드가 다이얼 가능 여부와 CID를 검색할 수 있는지를 테스트한다.

#pl-diagnose로 디버깅

pl-diagnose은 브라우저에서 직접 위의 많은 단계를 수행할 수 있는 대체 웹 기반 도구이다.

이 경우 공급자에서 CID를 조회하고, 다른 피어가 다중 주소에 연결할 수 있는지, 노드가 CID를 서비스하고 있는지 확인한다.

콘텐츠 게시 수명 주기

이제 콘텐츠 검색에 익숙해졌으므로 검색의 다른 쪽 끝, 즉 콘텐츠 게시에 대해 살펴보겠다. 콘텐츠 게시는 IPFS 네트워크의 피어에서 콘텐츠를 검색할 방법이다.

참고: 게시라는 용어는 실제 내용이 아닌 DHT에 대한 제공자 기록의 개시를 의미하기 때문에 약간 오해의 소지가 있다. 이와 비슷한 예로 광고라는 용어도 있다.

명령을 사용하여 IPFS 노드에 파일을 추가할 때 ipfs add네트워크에서 파일이 게시되고 검색할 수 있는 방식은 다음과 같다.

파일이 블록으로 분할되고 머클 DAG가 생성된다. DAG의 루트 CID를 반환한다.
파일 블록은 모든 피어가 요청할 수 있도록 비트 스와프를 통해 사용할 수 있다.
노드는 공급자 기록(블록의 CID 및 루트 CID 포함)로 알려진 네트워크 주소에 대한 CID 매핑을 DHT에 알린다. 이 프로세스는 노드가 실행되는 동안(피어 이동에 대한 고려) 12시간마다 반복되는 연속 프로세스이다. 공급자 기록의 만료 시간은 24시간이다(공급자 이탈을 고려함).

디버깅 콘텐츠 게시

프로브랩(ProbeLab)에서 수행한 IPFS 네트워크 측정은 콘텐츠 게시가 IPFS에서 병목 현상임을 보여준다. 이 강연에서 이를 개선하기 위한 노력도 있지만, 내용 게시와 관련된 문제를 해결하는 방법을 이해하는 것이 유용하다.

일반적으로 IPFS 노드에 파일을 추가할수록 재제공 실행 시간이 길어진다.

재제공 실행이 24시간(공급자 레코드의 만료 시간)을 초과하면 CID를 검색할 수 없게 된다.

재제공 실행 시간을 확인하려면 다음 명령을 실행해야 한다:

ipfs stats provide

결과는 다음과 같다:

TotalProvides: 7k (7,401)

AvgProvideDuration: 271.271ms

LastReprovideDuration: 13m16.104781s

LastReprovideBatchSize: 1k (1,858)

LastReprovidDuration 값이 24시간 가까이 도달하는 경우 다음 옵션 중 하나를 고려해야 한다:

kubo에서 Accelerated DHT Client 활성화 이 구성은 피어에 대한 더 많은 연결과 더 큰 라우팅 테이블을 유지하고 공급자 레코드의 광고를 일괄 처리하여 콘텐츠 게시 시간을 크게 향상한다. 이는 자원 소비 증가로 인한 비용이라는 점에 유의해야 한다.
재공급자 전략을 all에서 pinned 또는 roots(둘 다 명시적으로 고정된 콘텐츠에 대한 공급자 레코드만 보급함)로 변경.
pinned은 명시적으로 고정되는 내용의 루트 CID와 하위 블록 CID(전체 DAG)를 모두 보급한다.
roots는 고정된 내용의 루트 CID만 보급하여 각 실행의 총제공 수를 줄인다. 이 전략은 가장 효율적이지만 검색 가능성을 루트 CID로만 제한하므로 주의해야 한다. IPFS에 파일 폴더를 추가하는 경우 고정 폴더의 CID만 보급된다(노드에 대한 연결이 설정된 후에도 모든 블록은 Bitswap으로 계속 검색 가능).

재제공 실행을 수동으로 트리거하려면 다음 명령을 실행해야 한다:

ipfs bitswap reprovide

고정, 캐시 및 가비지 수집

기존 IPFS 구현 노드가 네트워크에서 CID를 가져온 후 짧은 시간 동안 CID를 로컬로 유지하는 캐싱 메커니즘을 가지고 있지만 이러한 개체는 주기적으로 쓰레기로 수집될 수 있다.

고정(Pinning)은 기본적으로 로컬 노드에 지정된 CID를 항상 저장하도록 IPFS에 지시할 수 있는 메커니즘이다. 이는 로컬 고정 외에도, CID를 원격 고정 서비스에 고정할 수 있다.

다시 말해, 캐싱은 CID를 노드에 저장하기 위해 의도적으로 선택할 때까지 짧은 시간 동안 노드에 CID를 보관하는 메커니즘이다.

캐싱은 게이트웨이에서 처음으로 CID를 요청하는 데 시간이 걸리는 반면 후속 요청은 훨씬 더 빠른 이유이다.

고정 서비스는 IPFS 노드를 실행하고 파일을 업로드하고 CID를 고정하여 IPFS 네트워크에서 사용할 수 있도록 하는 서비스이다. 예는 다음과 같다.

참고: 피냐타와 같은 일부 고정 서비스는 DHT에 공급자 레코드를 게시하지 않는다. 이러면 직접 피어링을 고려해야 한다.

캐싱에 대해 주의할 점은 종종 다층화된다는 것이다. IPFS 노드에 의해 수행되는 캐싱 외에도 HTTP 캐시 제어 헤더를 기반으로 하는 HTTP 캐싱의 다른 계층을 추가하는 것이 일반적이다. CID는 불변하므로 CDN 또는 에지 캐시를 IPFS 게이트웨이 노드 앞에 배치하는 등 다양한 캐싱 기회가 있다.

가비지 수집은 IPFS 노드가 더 이상 필요하지 않은 데이터를 삭제하여 저장 공간을 확보하는 프로세스이다. 가비지 수집에 대한 자세한 내용은 다음 문서를 참조하면 된다

공용 vs. 전용 vs. 자체 호스팅 게이트웨이

가장 간단한 형태에서 게이트웨이는 CID에 대한 HTTP 요청도 받아들이는 IPFS 노드이다.

그러나 IPFS 게이트웨이의 현실은 서로 다른 IPFS 게이트웨이, 즉 공용, 전용 및 자체 호스팅이 있기 때문에 미묘한 차이를 보인다.

공용 게이트웨이를 사용하면 누구나 HTTP를 사용하여 IPFS 네트워크에서 CID를 가져올 수 있다.

공용 게이트웨이 검사기에서 공용 게이트웨이 운영자를 찾고 사용자의 위치에서 온라인 상태인지 여부와 지연 시간을 확인할 수 있다.

많은 공용 게이트웨이가 SLA 없이 최선의 방법으로 제공된다는 점에 유의해야 한다. 공용 게이트웨이는 악용되기 쉬운데, 이는 그들 중 많은 사람이 요청 제한을 구현하는 이유이다.

인퓨라 및 피냐타와 같은 전용 게이트웨이는 CID 고정을 IPFS 게이트웨이와 결합하고 해당 게이트웨이를 통해 고정된 CID의 가용성을 보장하는 서비스이다.

공개 게이트웨이의 또 다른 독특한 예는 nftstorage.link로, 여러 퍼블릭 게이트웨이에 걸쳐 CID 요청을 레이싱하여 에지에서의 응답 캐싱뿐만 아니라 가장 빠른 응답을 제공한다(소스코드는 깃허브에서 확인할 수 있다).

NFT.Storage Gateway SuperHotperma-cache는 최근 NFT에서 출시한 유료 기능으로 전용 게이트웨이와 유사하다. Cloudflare의 270개 지점 모두에서 CID를 사전 로드하여 사용자에게 가장 가까운 CDN 위치를 통해 초고속 읽기 환경을 제공한다.

마지막으로 자체 호스팅된 게이트웨이는 로컬 시스템이나 클라우드에서 사용자가 호스팅하는 게이트웨이로 구성된 IPFS 노드를 말한다.

세 가지 접근 방식 중에서 선택하는 것은 요구 사항에 따라 다르다. 성능이 중요한 경우 IPFS 노드 및 게이트웨이를 자체 호스팅하거나 전용 게이트웨이를 사용하는 것이 공용 게이트웨이 사용을 보완할 수 있는 합리적인 선택이다.

IPFS 노드/게이트웨이 자체 호스팅 모범 사례

IPFS 게이트웨이로도 구성된 IPFS 노드를 실행하는 경우 CID의 검색 및 검색 가능성을 개선하기 위해 수행할 수 있는 단계가 있다.

CID를 고정하는 고정 서비스를 사용하여 피어링을 설정한다.
노드에 공개적으로 연결할 수 있는지 확인한다.
이를 확인하려면 ipfs id를 실행하고 프로토콜 목록에서 "/ipfs/kad/1.0.0" 값을 확인하거나 ipfs id | grep ipfs∖/kad를 실행하여 확인할 수 있다.
NAT 뒤에 있어 노드에 연결할 수 없는 경우 NAT 구성에서 문서를 확인하면 된다
IPFS 게이트웨이 노드가 역방향 프록시 뒤에 있는 경우 HTTP 캐시 헤더를 클라이언트에 올바르게 반환하는지 확인한다. 특히 Etag, Cache-Control 및 Last-Modified 헤더에 주의하면 된다. 더욱 현명한 HTTP 캐싱 전략을 위해 X-Ipfs-Roots의 CID 목록을 활용하는 것을 고려해야 한다
Cloudflare와 같은 CDN을 IPFS 게이트웨이 앞에 놓는다.
Accelerated DHT Client를 활성화 고려(상충 관계에 대해서는 콘텐츠 게시 섹션 참조).
Speedtest CLI와 같은 도구를 사용하여 인터넷 연결 속도를 테스트하고 모니터링.
iotop 또는 iostat과 같은 도구를 사용하여 디스크 I/O 병목 현상을 일으키는 다른 프로세스가 없는지 확인.

팁: CID를 여러 IPFS 노드에 고정

위에 제시된 원칙을 바탕으로, 노드 및 네트워크 파티션의 장애에 대한 안정적인 가용성과 복원력을 보장하기 위해 CID를 여러 IPFS 노드에 고정하는 것이 합리적이다.

IPFS를 사용하면 일반적으로 CID를 여러 IPFS 노드에 고정하거나 서비스를 고정하여 이중화를 개선할 수 있다.

일반적으로 IPFS 네트워크에서 CID를 고정하는 노드가 많을수록 검색할 수 있는 가능성이 커진다.

쉽게 고정할 수 있도록 많은 IPFS 노드 구현, 클라이언트 라이브러리 및 기존 고정 서비스에서 이미 지원되는 공급업체에 구애받지 않는 고정 서비스 OpenAPI 사양이 있다.

이 원격 고정 API를 사용하면 IPFS에 불변 데이터를 업로드하기 위한 워크플로우 일부로 여러 서비스에 고정을 구현할 수 있다.

IPFS 노드를 실행하지 않는 경우 파일을 한 서비스에 업로드한 다음 반환된 CID를 사용하여 다른 서비스에 고정하는 것으로 시작할 수 있다.

팁: IPFS 게이트웨이로 제어하는 사용자 지정 도메인 사용

다음을 가정해보자. 운영 중단을 겪고 있는 공용 게이트웨이에 절대 URL을 가진 미디어를 포함하는 IPFS에 웹 앱을 배포한다. 예를 들어 웹 앱에서 CID에 대한 절대 경로로 이미지를 표시한다. https://bafybeibml5uieyxa5tufngvg7fggwbvls suntwbxgtskoqynbt7wlchmfm.ipfs.dweb.link.link.link.

다른 게이트웨이를 사용하여 미디어에 연결할 수 있지만 웹 앱의 내용은 변경할 수 없으므로 다운된 IPFS 게이트웨이에 대한 링크가 로드되지 않는다.

이러한 이유로, HTTP 트래픽을 게이트웨이로 라우팅하기 위해 사용자의 제어 범위 내의 도메인을 사용하는 것이 현명하다. 이 접근 방식을 사용하면 추가 성능 최적화를 구현할 수 있는 유연성을 얻을 수 있다.

실제로 인프라 실행 의지에 따라 다음과 같은 몇 가지 접근 방식을 사용하여 이를 구현할 수 있다.

제어 도메인 지정. 예를 들어, *.ipfs.yourdomain.ionginx와 같은 역 프록시를 지정하여 공용 게이트웨이에 대한 요청을 프록시 처리하여 다운타임이 있는 경우 공용 게이트웨이를 전환할 수 있다.
Cloudflare 작업자와 같은 서비스 사용 또는 Fastly Compute@Edge IPFS 게이트웨이에 대한 경량 역방향 프록시를 구현한다.

요약

이 블로그 게시물에서는 IPFS 게이트웨이를 효과적으로 사용하고 문제가 발생할 때 체계적으로 디버깅하는 데 필요한 많은 팁, 요령 및 도구를 다뤘다.

IPFS 게이트웨이의 일반적인 문제부터 시작하여 컨텐츠 검색, 게시, 게이트웨이 요청 라이프사이클, 다양한 종류의 IPFS 게이트웨이, 캐싱, 가비지 수집, 고정 및 IPFS 노드/게이트웨이 자체 호스팅 시 모범 사례에 대해 자세히 설명했다.

다음 단계:

IPFS 문서를 자세히 살펴보기.
IPFS 노드를 설치하고 실행하기.
IPFS 포럼에서 질문하기.
Slack, Discoord 또는 Matrix에서 채팅하기.

더욱 다양한 정보 및 방송 관련 소식은

공식 SNS 채널을 통해 확인 가능합니다.

이은혜 기자 | [email protected]

댓글 [ 0 ]

댓글 서비스는 로그인 이후 사용가능합니다.

회원가입

로그인

최신순