처음에 mainnet.optimism.io는 도메인 별칭에 불과했습니다. 모든 실제 인프라는 QuickNode에서 처리했습니다. 이를 통해 사용자가 네트워크에 액세스하는 방법에 대한 걱정 없이 핵심 프로토콜 개발에 집중할 수 있습니다. 우리는 성장하면서 단순한 도메인 별칭이 제공할 수 있는 것 이상의 것이 필요하다는 것을 깨달았습니다.

1. 자체 메트릭을 생성하고 이를 경고할 수 있는 기능이 필요했습니다.

2. 어떤 사용자 RPC가 실패했고 그 이유가 무엇인지 정확히 진단하려면 자세한 로그가 필요했습니다.

3. 시퀀서를 보호하기 위해 특정 RPC를 화이트리스트에 추가하는 기능이 필요했습니다.

4. QuickNode에 다운타임이 발생한 경우 자동으로 다른 제공업체로 장애 조치하는 방법이 필요했습니다.

5. 퍼블릭 엔드포인트 호스팅 비용을 줄이고 싶었습니다.

또한 반목표도 있었습니다. 스스로 인프라 공급자가 되지 말라는 것입니다. 퍼블릭 엔드포인트는 매일 약 1억 건의 요청을 봅니다. 많은 요청을 처리하는 것은 어렵고 노드 인프라 실행은 우리의 핵심 비즈니스가 아닙니다. 따라서 퍼블릭 노드를 직접 운영하지 않고도 위의 문제를 해결할 필요가 있었습니다.

우리의 솔루션은 모든 RPC 트래픽을 proxyd. proxyd개별 RPC를 업스트림 인프라 공급자 그룹(구성에서 "백엔드"라고 함)으로 라우팅할 수 있습니다. 그룹의 백엔드 중 하나가 실패하면 proxyd구성 가능한 기간 동안 자동으로 서비스 중단으로 표시하고 다른 공급자로 장애 조치합니다. proxyd또한 RPC 메서드 캐싱을 지원하고 RPC 사용을 분석하기 위해 풍부한 Prometheus 메트릭 세트를 노출합니다.

다음과 같은 TOML 파일을 사용하여 구성됩니다.

[backends] response_timeout_seconds = 5 max_retries = 3 out_of_service_seconds = 30

[backends.infura] rpc_url = "..." ws_url = "..."

[backends.alchemy] rpc_url = "..." ws_url = "..."

[backend_groups] [backend_groups.providers] backends = ["alchemy","infura"]

# Mapping of methods to backend groups. [rpc_method_mappings] eth_getBalance = "providers" 여기서 eth_getBalance호출은 Alchemy로 라우팅됩니다. Alchemy가 실패하면 호출이 30초 동안 Infura로 라우팅됩니다. 그 후 proxyd연금술을 다시 시도합니다.

Kovan을 메인넷에 배포하기 전에 대략 한 달 동안 Kovan을 테스트했습니다 proxyd. 그 과정에서 우리가 배운 가장 흥미로운 것들 중 일부는 다음과 같습니다.

인프라 공급자는 Geth의 표준 RPC 구현에서 벗어난 미묘하고 종종 문서화되지 않은 한계를 가지고 있습니다. 이러한 제한에 도달하면 사용자에게 직접 반환되며 어떤 종류의 경고도 트리거하지 않습니다. 결과적으로 메트릭은 요청된 RPC 메서드뿐만 아니라 업스트림 공급자가 반환한 원시 오류 코드도 추적해야 했습니다. WebSockets 또는 RPC 일괄 처리를 사용하는 애플리케이션은 거의 없습니다. 대부분의 HTTP 요청에는 단일 RPC 호출이 포함됩니다. 이것은 속도 제한을 설계하는 동안 중요한 요소였습니다. dApp을 통한 단일 브라우저 세션 클릭이 분당 수천 건의 HTTP 요청을 시작할 수 있기 때문입니다. 업스트림 오류는 생각보다 많이 발생합니다. 일반적으로 2-3초 내에 해결되지만 그럼에도 불구하고 오류입니다. 결과적으로 proxyd이러한 문제를 사용자에게 숨기기 위해 내부적으로 업스트림 공급자를 다시 시도합니다. 한 번에 3개 제공자에게 데이터를 요청하고 제공자의 2/3가 동의한 데이터를 반환하는 실험을 실행했습니다. 이러지 마. 공급자가 단일 블록에 대한 합의에 도달하는 데 약 10-15초가 걸리며 사용자가 기다리기에는 너무 깁니다. 가장 많이 요청된 RPC 호출 중 일부는 간단하게 캐시할 수 있습니다. eth_chainId우리의 경우 하루에 수백만 번 호출되는 와 같은 것입니다 . 이와 같은 캐싱 방법은 인프라 비용을 매월 수백 달러 절약할 수 있습니다.

💡 그건 그렇고, 프록시는 오픈 소스입니다! https://github.com/ethereum-optimism/optimism/tree/develop/go/proxyd 에서 찾을 수 있습니다 . 퍼블릭 엔드포인트를 실행 중이거나 중복 인프라 공급자에 액세스하는 방법을 원하는 경우 확인하십시오.

파트 3: 결과

현재 우리 proxyd클러스터는 메인넷에 있으며 하루에 약 1억 건의 요청을 처리합니다. 그렇다면 이것이 사용자에게 의미하는 바는 무엇입니까? 그 뜻은:

이 모든 작업의 ​​주요 목표는 가동 시간을 개선하는 것입니다. 퍼블릭 엔드포인트가 다운되면 시퀀서가 아무 작업도 수행하지 않는데도 Optimism 자체가 다운된 것처럼 느껴집니다. 이 작업을 올바르게 수행하면 이러한 변경 사항이 완전히 투명해야 합니다.

이전에는 문제의 전제 조건에 대한 통찰력이 없었습니다. 예를 들어 사용자가 문제를 보고하기 시작한 후에야 Lyra 토큰 출시에 영향을 미치는 문제를 알게 되었습니다. 이상 현상이 발생하면 문제가 발생하기 전에 모니터링할 수 있도록 대기 중인 엔지니어에게 ping을 보내는 모니터링 및 경고가 준비되어 있습니다.

예를 들어, 다음은 사용자가 공급자별 제한(이 경우 eth_getLog요청에 대한 QuickNode의 최대 10,000개 블록)에 직면한 최근에 우리가 경험한 이상 현상입니다.

최선을 다해도 문제가 계속 발생할 수 있습니다. 이런 일이 발생하면 사용자 문제를 가능한 한 빨리 진단할 수 있는 것이 중요합니다. 이것은 모든 RPC 요청에 대한 자세한 오류 정보를 볼 수 있는 능력이 없었기 때문에 어려운 pre-`proxyd`였습니다. 이제 아래와 같은 대시보드가 ​​생겼습니다. 이 대시보드는 사용자가 RPC 및 공급자별로 경험하고 있는 오류 코드를 정확히 보여줍니다.

그런 다음 로깅 도구인 StackDriver로 이동하여 각 오류의 근본 원인을 정확히 확인할 수 있습니다.

이렇게 하면 문제가 발생한 이유에 대한 데이터 수집 프로세스를 단축하고 문제를 더 빨리 해결할 수 있습니다.

https://blog.oplabs.co/reliability-and-hardening/

처음에 mainnet.optimism.io는 도메인 별칭에 불과했습니다. 모든 실제 인프라는 QuickNode에서 처리했습니다. 이를 통해 사용자가 네트워크에 액세스하는 방법에 대한 걱정 없이 핵심 프로토콜 개발에 집중할 수 있습니다. 우리는 성장하면서 단순한 도메인 별칭이 제공할 수 있는 것 이상의 것이 필요하다는 것을 깨달았습니다.

1. 자체 메트릭을 생성하고 이를 경고할 수 있는 기능이 필요했습니다.

2. 어떤 사용자 RPC가 실패했고 그 이유가 무엇인지 정확히 진단하려면 자세한 로그가 필요했습니다.

3. 시퀀서를 보호하기 위해 특정 RPC를 화이트리스트에 추가하는 기능이 필요했습니다.

4. QuickNode에 다운타임이 발생한 경우 자동으로 다른 제공업체로 장애 조치하는 방법이 필요했습니다.

5. 퍼블릭 엔드포인트 호스팅 비용을 줄이고 싶었습니다.

또한 반목표도 있었습니다. 스스로 인프라 공급자가 되지 말라는 것입니다. 퍼블릭 엔드포인트는 매일 약 1억 건의 요청을 봅니다. 많은 요청을 처리하는 것은 어렵고 노드 인프라 실행은 우리의 핵심 비즈니스가 아닙니다. 따라서 퍼블릭 노드를 직접 운영하지 않고도 위의 문제를 해결할 필요가 있었습니다.

우리의 솔루션은 모든 RPC 트래픽을 proxyd. proxyd개별 RPC를 업스트림 인프라 공급자 그룹(구성에서 "백엔드"라고 함)으로 라우팅할 수 있습니다. 그룹의 백엔드 중 하나가 실패하면 proxyd구성 가능한 기간 동안 자동으로 서비스 중단으로 표시하고 다른 공급자로 장애 조치합니다. proxyd또한 RPC 메서드 캐싱을 지원하고 RPC 사용을 분석하기 위해 풍부한 Prometheus 메트릭 세트를 노출합니다.

다음과 같은 TOML 파일을 사용하여 구성됩니다.

[backends] response_timeout_seconds = 5 max_retries = 3 out_of_service_seconds = 30

[backends.infura] rpc_url = "..." ws_url = "..."

[backends.alchemy] rpc_url = "..." ws_url = "..."

[backend_groups] [backend_groups.providers] backends = ["alchemy","infura"]

# Mapping of methods to backend groups. [rpc_method_mappings] eth_getBalance = "providers" 여기서 eth_getBalance호출은 Alchemy로 라우팅됩니다. Alchemy가 실패하면 호출이 30초 동안 Infura로 라우팅됩니다. 그 후 proxyd연금술을 다시 시도합니다.

Kovan을 메인넷에 배포하기 전에 대략 한 달 동안 Kovan을 테스트했습니다 proxyd. 그 과정에서 우리가 배운 가장 흥미로운 것들 중 일부는 다음과 같습니다.

인프라 공급자는 Geth의 표준 RPC 구현에서 벗어난 미묘하고 종종 문서화되지 않은 한계를 가지고 있습니다. 이러한 제한에 도달하면 사용자에게 직접 반환되며 어떤 종류의 경고도 트리거하지 않습니다. 결과적으로 메트릭은 요청된 RPC 메서드뿐만 아니라 업스트림 공급자가 반환한 원시 오류 코드도 추적해야 했습니다. WebSockets 또는 RPC 일괄 처리를 사용하는 애플리케이션은 거의 없습니다. 대부분의 HTTP 요청에는 단일 RPC 호출이 포함됩니다. 이것은 속도 제한을 설계하는 동안 중요한 요소였습니다. dApp을 통한 단일 브라우저 세션 클릭이 분당 수천 건의 HTTP 요청을 시작할 수 있기 때문입니다. 업스트림 오류는 생각보다 많이 발생합니다. 일반적으로 2-3초 내에 해결되지만 그럼에도 불구하고 오류입니다. 결과적으로 proxyd이러한 문제를 사용자에게 숨기기 위해 내부적으로 업스트림 공급자를 다시 시도합니다. 한 번에 3개 제공자에게 데이터를 요청하고 제공자의 2/3가 동의한 데이터를 반환하는 실험을 실행했습니다. 이러지 마. 공급자가 단일 블록에 대한 합의에 도달하는 데 약 10-15초가 걸리며 사용자가 기다리기에는 너무 깁니다. 가장 많이 요청된 RPC 호출 중 일부는 간단하게 캐시할 수 있습니다. eth_chainId우리의 경우 하루에 수백만 번 호출되는 와 같은 것입니다 . 이와 같은 캐싱 방법은 인프라 비용을 매월 수백 달러 절약할 수 있습니다.

💡 그건 그렇고, 프록시는 오픈 소스입니다! https://github.com/ethereum-optimism/optimism/tree/develop/go/proxyd 에서 찾을 수 있습니다 . 퍼블릭 엔드포인트를 실행 중이거나 중복 인프라 공급자에 액세스하는 방법을 원하는 경우 확인하십시오.

파트 3: 결과

현재 우리 proxyd클러스터는 메인넷에 있으며 하루에 약 1억 건의 요청을 처리합니다. 그렇다면 이것이 사용자에게 의미하는 바는 무엇입니까? 그 뜻은:

이 모든 작업의 ​​주요 목표는 가동 시간을 개선하는 것입니다. 퍼블릭 엔드포인트가 다운되면 시퀀서가 아무 작업도 수행하지 않는데도 Optimism 자체가 다운된 것처럼 느껴집니다. 이 작업을 올바르게 수행하면 이러한 변경 사항이 완전히 투명해야 합니다.

이전에는 문제의 전제 조건에 대한 통찰력이 없었습니다. 예를 들어 사용자가 문제를 보고하기 시작한 후에야 Lyra 토큰 출시에 영향을 미치는 문제를 알게 되었습니다. 이상 현상이 발생하면 문제가 발생하기 전에 모니터링할 수 있도록 대기 중인 엔지니어에게 ping을 보내는 모니터링 및 경고가 준비되어 있습니다.

예를 들어, 다음은 사용자가 공급자별 제한(이 경우 eth_getLog요청에 대한 QuickNode의 최대 10,000개 블록)에 직면한 최근에 우리가 경험한 이상 현상입니다.

최선을 다해도 문제가 계속 발생할 수 있습니다. 이런 일이 발생하면 사용자 문제를 가능한 한 빨리 진단할 수 있는 것이 중요합니다. 이것은 모든 RPC 요청에 대한 자세한 오류 정보를 볼 수 있는 능력이 없었기 때문에 어려운 pre-`proxyd`였습니다. 이제 아래와 같은 대시보드가 ​​생겼습니다. 이 대시보드는 사용자가 RPC 및 공급자별로 경험하고 있는 오류 코드를 정확히 보여줍니다.

그런 다음 로깅 도구인 StackDriver로 이동하여 각 오류의 근본 원인을 정확히 확인할 수 있습니다.

이렇게 하면 문제가 발생한 이유에 대한 데이터 수집 프로세스를 단축하고 문제를 더 빨리 해결할 수 있습니다.

https://blog.oplabs.co/reliability-and-hardening/