JSON-RPC? 까다로운 REST를 이용하세요

헤드라인이 건전한 반응을 불러일으켰다고 확신합니다. “아, 또 시작됐네요...” 하지만 5~10분 동안 여러분의 관심을 사로잡을 수 있도록 하겠습니다. 여러분의 기대를 실망시키지 않도록 노력하겠습니다.

기사의 구조는 다음과 같습니다. 고정 관념이 채택되고 이러한 고정 관념이 나타나는 "특성"이 드러납니다. 이를 통해 프로젝트의 데이터 교환 패러다임 선택을 새로운 각도에서 볼 수 있기를 바랍니다.

RPC가 무엇인지 명확히 하기 위해 표준을 고려해 볼 것을 제안합니다. JSON-RPC 2.0. REST를 사용하면 명확성이 없습니다. 그리고 그래서는 안됩니다. REST에 대해 알아야 할 모든 것 - REST와 구별할 수 없습니다. HTTP.

RPC 요청은 일괄 요청을 허용하므로 더 빠르고 효율적입니다.

요점은 RPC에서는 하나의 요청으로 여러 프로시저를 동시에 호출할 수 있다는 것입니다. 예를 들어 사용자를 생성하고 해당 사용자에게 아바타를 추가한 다음 동일한 요청으로 해당 사용자가 일부 주제를 구독하도록 하세요. 단 한번의 요청으로 얼마나 많은 혜택을 누리시나요!

실제로 백엔드 노드가 하나만 있는 경우 일괄 요청을 사용하면 더 빨라 보일 것입니다. XNUMX개의 REST 요청에는 연결을 설정하기 위해 한 노드에서 XNUMX배 더 많은 리소스가 필요하기 때문입니다.

REST의 경우 첫 번째 요청은 후속 요청이 이루어지도록 사용자 ID를 반환해야 합니다. 이는 또한 전체 결과에 부정적인 영향을 미칩니다.

그러나 이러한 인프라는 사내 솔루션과 엔터프라이즈에서만 찾을 수 있습니다. 최후의 수단으로 소규모 WEB 프로젝트에서. 그러나 본격적인 웹 솔루션, 심지어 HighLoad라고 불리는 솔루션도 구축할 가치가 없습니다. 해당 인프라는 고가용성 및 로드 기준을 충족해야 합니다. 그리고 그림이 바뀌고 있습니다.

동일한 시나리오의 인프라 활동 채널은 녹색으로 표시됩니다. 이제 RPC가 어떻게 작동하는지 확인하십시오. 요청은 밸런서에서 백엔드까지 한쪽 구간에서만 인프라를 사용합니다. REST는 여전히 첫 번째 요청에서 손실을 입지만 전체 인프라를 사용하여 손실된 시간을 보상합니다.

농축에 대한 두 가지 요청이 아니라 예를 들어 XNUMX개 또는 XNUMX개 요청을 대본에 입력하는 것으로 충분하며 "지금 누가 승리합니까?"라는 질문에 대한 대답입니다. 불분명해집니다.

나는 문제를 더욱 폭넓게 살펴볼 것을 제안합니다. 다이어그램은 인프라 채널이 사용되는 방법을 보여 주지만 인프라는 채널로 제한되지 않습니다. 로드가 많은 인프라의 중요한 구성 요소는 캐시입니다. 이제 일종의 사용자 아티팩트를 가져와 보겠습니다. 자꾸. 32번이라고 해보자.

높은 로드 요구 사항을 충족하기 위해 RPC 인프라가 어떻게 크게 개선되었는지 확인하세요. 중요한 것은 REST가 RPC와 달리 HTTP 프로토콜의 모든 기능을 사용한다는 것입니다. 위 다이어그램에서 이 기능은 요청 메서드인 GET을 통해 실현됩니다.

무엇보다도 HTTP 메서드에는 캐싱 전략이 있습니다. 다음 문서에서 찾을 수 있습니다. HTTP. RPC의 경우 멱등성으로 간주되지 않는 POST 요청이 사용됩니다. 즉, 동일한 POST 요청을 반복적으로 반복하면 다른 결과가 반환될 수 있습니다(예를 들어 각 주석이 전송된 후 이 주석의 다른 복사본이 나타납니다)(출처).

결과적으로 RPC는 인프라 캐시를 효과적으로 사용할 수 없습니다. 이로 인해 소프트웨어 캐시를 "가져오기"해야 합니다. 다이어그램은 이 역할의 Redis를 보여줍니다. 그러면 소프트웨어 캐시를 사용하려면 개발자가 코드 계층을 추가하고 아키텍처에 눈에 띄는 변경 사항을 추가해야 합니다.

이제 고려 중인 인프라에서 REST 및 RPC가 얼마나 많은 요청을 "생성"했는지 계산해 보겠습니다.

요청
받은 편지함
백엔드에
DBMS에
소프트 캐시(Redis)
TOTAL

REST
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] 가장 좋은 경우(로컬 캐시를 사용하는 경우) 1개의 요청(32개!), 최악의 경우 XNUMX개의 요청이 수신됩니다.

첫 번째 계획과 비교하면 차이점이 두드러집니다. 이제 REST의 이점이 분명해졌습니다. 하지만 여기서 멈추지 않는 것이 좋습니다. 개발된 인프라에는 CDN이 포함되어 있습니다. 종종 DDoS 및 DoS 공격 대응 문제도 해결합니다. 우리는 다음을 얻습니다:

이것이 바로 RPC의 상황이 정말 나빠지는 부분입니다. RPC는 작업 부하를 CDN에 위임할 수 없습니다. 우리는 공격에 대응하기 위해 시스템에만 의존할 수 있습니다.

여기서 끝내도 되나요? 그리고 다시 말하지만, 아닙니다. 위에서 언급한 것처럼 HTTP 메서드에는 고유한 "마법"이 있습니다. 그리고 GET 방식이 인터넷에서 널리 사용되는 것은 당연한 일입니다. 이 메서드는 콘텐츠에 액세스할 수 있고 제어권이 코드로 전송되기 전에 인프라 요소가 해석할 수 있는 조건을 설정할 수 있습니다. 이 모든 기능을 통해 대규모 요청 흐름을 처리할 수 있는 유연하고 관리 가능한 인프라를 구축할 수 있습니다. 하지만 RPC에서는 이 방법이... 무시됩니다.

그렇다면 일괄 요청(RPC)이 더 빠르다는 통념이 왜 그렇게 끈질기게 존재하는 걸까요? 개인적으로 대부분의 프로젝트는 REST가 그 강점을 보여줄 수 있는 개발 수준에 도달하지 못하는 것 같습니다. 더욱이 그는 소규모 프로젝트에서 자신의 약점을 더 기꺼이 보여줍니다.

REST 또는 RPC의 선택은 프로젝트에서 개인의 의지적인 선택이 아닙니다. 이 선택은 프로젝트의 요구 사항을 충족해야 합니다. 프로젝트가 REST에서 실제로 가능한 모든 것을 짜낼 수 있고 실제로 필요한 경우 REST는 탁월한 선택이 될 것입니다.

그러나 REST의 모든 이점을 얻으려면 인프라를 신속하게 확장하기 위한 프로젝트용 데브옵스 전문가, 인프라를 관리하기 위한 관리자, 웹 서비스의 모든 계층을 설계하기 위한 설계자... 그리고 프로젝트를 위한 데브옵스 전문가를 고용해야 합니다. , 동시에 하루에 마가린 세 팩을 판매합니다... 저는 RPC를 고수하겠습니다. 왜냐면... 이 프로토콜이 더 실용적입니다. 캐시와 인프라 작동 방식에 대한 깊은 지식이 필요하지 않지만 개발자는 필요한 절차에 대한 간단하고 이해하기 쉬운 호출에 집중할 것입니다. 사업은 행복할 것입니다.

RPC 요청은 단일 트랜잭션 내에서 일괄 요청을 실행할 수 있으므로 더 안정적입니다.

RPC의 이러한 속성은 다음과 같은 이유로 확실한 이점을 제공합니다. 데이터베이스의 일관성을 유지하는 것은 쉽습니다. 그러나 REST를 사용하면 점점 더 복잡해집니다. 요청이 서로 다른 백엔드 노드에 일관되지 않게 도착할 수 있습니다.

REST의 이러한 "단점"은 위에서 설명한 장점(모든 인프라 리소스를 효율적으로 사용할 수 있는 능력)의 반대 측면입니다. 인프라가 제대로 설계되지 않은 경우, 특히 프로젝트 아키텍처와 데이터베이스가 제대로 설계되지 않은 경우 이는 정말 큰 고통입니다.

하지만 일괄 요청이 보기만큼 신뢰할 수 있을까요? 사례를 살펴보겠습니다. 사용자를 생성하고 몇 가지 설명으로 프로필을 보강한 다음 그에게 비밀 정보가 포함된 SMS를 보내 등록을 완료합니다. 저것들. 하나의 일괄 요청으로 세 번의 호출이 가능합니다.

다이어그램을 살펴 보겠습니다. 고가용성 요소를 갖춘 인프라를 제공합니다. SMS 게이트웨이에는 두 개의 독립적인 통신 채널이 있습니다. 그런데... 우리는 무엇을 봅니까? SMS를 보낼 때 오류 503이 발생합니다. 서비스를 일시적으로 사용할 수 없습니다. 왜냐하면 SMS 전송은 일괄 요청으로 패키지되므로 전체 요청을 롤백해야 합니다. DBMS의 작업이 취소됩니다. 클라이언트에 오류가 발생했습니다.

다음 시도는 복권입니다. 요청이 동일한 노드에 다시 도달하고 다시 오류를 반환하거나 운이 좋아서 실행될 것입니다. 그러나 가장 중요한 것은 적어도 한 번은 우리 인프라가 이미 헛되이 작동했다는 것입니다. 짐은 있었지만 이익은 없었습니다.

좋아요, 우리가 긴장을 풀고(!) 요청이 부분적으로 성공적으로 완료될 수 있는 옵션을 생각해 봤다고 가정해 보겠습니다. 그리고 일정 시간 간격을 두고 나머지 부분을 다시 완료하려고 노력할 것입니다(어느 것입니까? 전면에서 결정합니까?). 그러나 복권은 동일하게 유지되었습니다. SMS 전송 요청이 다시 실패할 확률은 50/50입니다.

클라이언트 측에서 보면 서비스가 우리가 원하는 만큼 안정적이지 않은 것 같습니다. REST는 어떻습니까?

REST는 HTTP의 마법을 다시 사용하지만 이제는 응답 코드를 사용합니다. SMS 게이트웨이에서 오류 503이 발생하면 백엔드는 이 오류를 밸런서에 브로드캐스트합니다. 밸런서는 이 오류를 수신하고 클라이언트와의 연결을 끊지 않고 요청을 성공적으로 처리하는 다른 노드로 요청을 보냅니다. 저것들. 클라이언트는 예상된 결과를 받고 인프라는 "접근성이 뛰어난"이라는 높은 타이틀을 확인합니다. 사용자는 행복합니다.

그리고 그게 전부가 아닙니다. 밸런서는 단지 503이라는 응답 코드를 수신한 것이 아닙니다. 표준에 따라 응답할 때 "Retry-After" 헤더와 함께 이 코드를 제공하는 것이 좋습니다. 헤더는 지정된 시간 동안 이 경로에서 이 노드를 방해할 가치가 없다는 것을 밸런서에게 분명히 합니다. 그리고 다음 SMS 전송 요청은 SMS 게이트웨이에 문제가 없는 노드로 직접 전송됩니다.

보시다시피 JSON-RPC의 신뢰성은 과대평가되었습니다. 실제로 데이터베이스의 일관성을 구성하는 것이 더 쉽습니다. 그러나 이 경우 시스템 전체의 신뢰성이 희생됩니다.

결론은 앞선 것과 대체로 비슷하다. 인프라가 단순할 때 JSON-RPC의 명확성은 확실히 장점이 됩니다. 프로젝트에 부하가 높은 고가용성이 포함된 경우 REST는 더 복잡하지만 더 정확한 솔루션처럼 보입니다.

REST에 대한 진입 임계값이 더 낮습니다.

RPC에 대한 확립된 고정관념을 폭로하는 위의 분석은 REST로 진입하기 위한 임계값이 의심할 여지 없이 RPC보다 높다는 것을 분명히 보여주었다고 생각합니다. 이는 HTTP가 어떻게 작동하는지에 대한 깊은 이해가 필요하고 WEB 프로젝트에서 사용할 수 있고 사용해야 하는 기존 인프라 요소에 대한 충분한 지식이 필요하기 때문입니다.

그렇다면 왜 많은 사람들은 REST가 더 간단할 것이라고 생각합니까? 내 개인적인 의견은 이러한 명백한 단순성이 REST 자체에서 비롯된다는 것입니다. 저것들. REST는 프로토콜이 아니라 개념입니다. REST에는 표준이 없으며 몇 가지 지침이 있습니다. REST는 HTTP보다 더 복잡하지 않습니다. 명백한 자유와 무정부 상태는 "자유 예술가"를 끌어들입니다.

물론 REST는 HTTP보다 더 복잡하지 않습니다. 그러나 HTTP 자체는 수십 년에 걸쳐 그 가치가 입증된 잘 설계된 프로토콜입니다. HTTP 자체에 대한 깊은 이해가 없으면 REST를 판단할 수 없습니다.

하지만 RPC에 대해서는 가능합니다. 사양을 취하는 것으로 충분합니다. 그래서 당신은 필요합니까? 멍청한 JSON-RPC? 아니면 여전히 까다로운 REST인가요? 당신이 결정합니다.

제가 귀하의 시간을 낭비하지 않았기를 진심으로 바랍니다.

출처 : habr.com