추상 위키백과/첫 번째 평가 엔진

우리의 첫 번째 평가 엔진을 어디에 어떻게 배포해야하며 어떻게 설계해야합니까?

궁극적으로 위키함수는 상호 운용 가능한 평가 엔진의 건강한 생태계를 유지하는 것을 목표로 합니다. 평가 엔진이 해야 할 일과 해야 할 일에 대해 잘 정의된 설명을 제공할 것이며, 평가 엔진이 다양한 컨텍스트에서 실행되기를 바랍니다 — 모바일 앱 또는 로컬 서버로 실행되는 평가 엔진을 통해 특정 기능을 사용하려는 네이티브 앱에 있는 소형 임베디드 평가 엔진부터 클라우드 또는 분산된 P2P 네트워크에서 실행되는 강력한 평가 엔진에 이르기까지. 위키미디어 재단은 위키미디어 프로젝트가 의존할 기능성을 제공하기 위해 하나 이상의 평가 엔진을 실행해야합니다. 우리는 이것들과 다른 많은 시간에 대해 생각할 것입니다.

지금은 첫 번째 평가 엔진이 어디에 있어야하는지 파악해야합니다. 이 모든 것을 결국 구현하는 것이 좋지만, 우리는 우리의 자원에 대해 현실적이어야하며 먼저 그 중 하나에만 집중해야합니다. 첫 번째 구현을 위해 고려해야 할 세 가지 주요 가능성이 있습니다:

위키람다 확장에 포함됩니다,
독립형 서비스.
우리는 독자의 브라우저에서 모든 것을 평가합니다.

이 평가 엔진을 구현할 델타(δ) 단계 작업을 시작하기 전에 이것을 결정해야합니다. 여기에서는 세 가지 주요 접근 방식의 장단점을 논의하고 접근 방식 내에서 가능한 옵션에 대해서도 논의합니다.

주요 옵션

위키람다 확장기능

위키람다 확장 자체는 위키에서 Z객체를 편집 및 유지 관리하기위한 위키 확장을 제공 할뿐만 아니라 평가 엔진도 포함합니다. 확장은 API를 통해 평가 엔진을 세계 및 내부 사용에 노출합니다.

장점:

위키람다 확장의 배포는 평가 엔진을 위한 보조 스택을 배포 할 필요가 없기 때문에 쉽습니다(지금 이 경로를 사용하지 않더라도 확장에 평가 엔진을 포함하는 것이 합리적입니다. 쉽게 배포할 수 있으므로 사람들이 코드베이스에 더 쉽게 기여할 수 있습니다).
우리는 이미 PHP 코드에서 특정 기능을 가진 객체 생성을 시작했으며 그 위에 계속 구축 할 수 있습니다.
주어진 호출을 평가하는 데 필요한 다른 모든 Z객체에 접근하는 가장 빠르고 쉬운 방법입니다.
확장 기능이 위키에 있는 기여 함수를 호출하여 경험의 일부를 제공하기를 원하기 때문에 즉시 사용 가능하도록 하는 것이 최소한의 오버 헤드로 가장 편리한 솔루션입니다.
API를 제공하기 위해 미디어위키에 이미 존재하는 모든 것을 재사용 할 수 있습니까? 예를 들어, 인증과 토큰 등.

단점:

보안 측면에서 보면 배포시 기본 클러스터에서 실행되므로 위험이 높습니다. 누군가가 임베디드 시스템에서 벗어나면 위키가 각각의 자격 증명에 접근할 수 있으므로 프로덕션 데이터베이스에 직접 접근할 수 있습니다.
보안 측면에서 고의 또는 비 의도적 DOS 공격에 대한 공격 벡터가 될 수도 있습니다. 값비싼 평가가 실행되고 미디어위키의 프로덕션 인스턴스를 잠그기 때문입니다.
모든 평가가 동일한 PHP 코드에 있기 때문에 확장 내에서 평가를 샌드박스화하는 것은 어렵습니다.
미디어위키 내에서 모니터링과 시간, 메모리 제약을 모두 구현해야합니다.

독립형 서비스

함수 호출을 평가하기 위해 REST를 통해 호출 할 수있는 독립형 서비스를 개발합니다. 이 서비스는 외부 및 내부 클라이언트 모두에서 사용됩니다.

장점:

모든 것을 처음부터 개발할 수 있습니다. 미디어위키를 통한 제약이 없으며, 우리가 구축한 스택이 허용하는만큼 서비스가 간결할 수 있습니다.
이 서비스는 전체적으로 샌드박스화, 모니터링, 시간 및 메모리 예산을 설정할 수 있습니다.
평가 엔진 내에서 캐싱에 대한 전체적이고 일관된 접근 방식을 구축 할 수 있습니다.
더 많은 상자에서 더 많은 서비스를 실행하여 쉽게 확장 할 수 있습니다. 단일 서버 호출이 다른 서버를 호출하기로 결정하여 호출의 일부를 병렬화하는 아키텍처도 허용합니다. 여기에서 설명하는 다른 두 가지 접근 방식에서는 구현하기 어렵습니다.

단점:

모든 것을 처음부터 개발해야합니다. 구현 언어와 스택 및 배포 접근 방식과 관련하여 자전거 흘림에 대한 많은 잠재력.
또한 새로운 버그를 도입할 수 있는 더 많은 기회를 의미합니다.
출시를 위해 새로운 프로덕션 강도 서비스를 시작하는 방법을 파악해야합니다(그러나 그때까지는 WMFCloud 또는 기타 인프라에서 실행할 수 있음).
DB에서 많은 것을 읽을 필요가 있으므로 그렇게 빨리 할 수 있어야 합니다. 그러나 읽기 전용 접근 권한입니다.
서비스를 설정해야하므로 확장을 배포하고 작업하려는 모든 사람에게 비용이 발생합니다.

브라우저

기능 평가는 위키미디어 인프라에서 전혀 실행될 필요가 없지만 모두 사용자의 브라우저에서 실행될 수 있습니다.

장점:

배포하기 쉽습니다.
서비스 인프라에 악영향을 미치기 어렵습니다.
독자의 리소스이므로 독자를 위해 리소스를 제한 할 필요가 없습니다.

단점:

독자에 대한 공격을 허용하지 않도록 매우 주의해야합니다.
많은 고객의 경험이 느려져 더 나은 장비를 사용하는 사용자에게만 접근할 수 있게되며 이는 우리의 목표에 위배됩니다.
평가 엔진은 브라우저가 위키에 접근해야하므로 왕복 시간이 길어 DB에서 많은 것을 읽어야 할 수 있습니다.
코드를 서버 측에서 호출 할 방법이 없습니다(브라우저와 백엔드에서 실행될 수 있도록 노드에서 병렬로 개발하지 않는 한, 기본적으로 두 솔루션이 일부 코드를 공유하더라도 두 가지 솔루션을 개발하고 유지하는 것입니다).
캐싱의 기회는 특히 큰 이점이 예상되는 사용자간에 심각하게 제한됩니다.
검색 엔진에 적합하지 않습니다.
더 이상 처리할 수 없습니다({{Str left|{{#lambda:xxx}}|123}}와 같이).

독립형 서비스를 위한 아키텍처

우리는 현재 첫 번째 평가 엔진을 독립형 서비스로 개발하는 쪽으로 기울고 있습니다. 미디어위키의 일부로 배포하는 것은 브라우저에서 실행하는 것처럼 잠재적인 보안 및 성능 위험이 너무 많은 것으로 간주됩니다. 나중에 브라우저에 대한 결정을 다시 검토하기를 바랍니다.

이상적으로 평가 엔진은 여러 번 실행되고 상태 비 저장 서비스로 오케스트레이션 될 수 있습니다. 이 서비스는 '읽기 전용'이며 모듈로 캐싱 및 모니터링입니다.

평가 엔진은 입력으로 Z객체를 수신하고 출력으로 Z객체를 반환하는 HTTP를 통해 API를 노출합니다. 반환된 Z객체는 고정점에 도달할 때까지 들어오는 Z객체를 평가한 결과입니다 이것은 함수 호출에 가장 흥미 롭습니다.

이 서비스는 캐싱의 이점을 크게 누릴 것입니다. 평가 엔진과 관련하여 (적어도) 세 가지 수준의 캐싱이 있습니다:

HTTP 캐시: HTTP 호출 수준에서 전체 API 호출을 평가 엔진에 캐시합니다. 동일한 호출이 이루어지면 동일한 결과가 반환됩니다.
중간 결과 캐시: 평가 엔진이 함수 호출을 평가할 때 캐시에 지정된 함수 호출이 있는지 확인하고 대신 해당 결과를 반환해야합니다. 이것은 병렬로 구동되는 모든 평가 엔진이 동일한 캐시를 사용할 수 있다는 이점이 있습니다.
콘텐츠 캐시: 위키에서 참조를 조회합니다. 특히 공유 캐시가 있는 경우 위키에서 푸시될 수도 있습니다. 이것은 중간 결과 캐시의 일부일 수 있습니다.

결국 우리는 다른 위키미디어 및 외부 서비스(예를 들어, 위키데이터, 날씨 보고서 등)에 대한 REST 호출과 현재 시간 및 임의 값과 같은 변경 사항을 허용해야합니다.

함수가 실행되는 동안 함수가 편집 될 때 경쟁 조건은 어떻습니까?

평가 엔진은 동질적입니까, 아니면 다양합니까? 즉 TPU를 사용할 수 있는 평가 엔진과 그렇지 않은 엔진이 있을 수 있으며 쿼리를 어떻게 라우팅합니까? 간단한 아이디어: 모든 평가 엔진이 모든 프로그래밍 언어를 이해해야하는지 아니면 일부는 파이썬, 다른 자바 스크립트 등을 실행할 수있는 전용 평가 엔진을 사용하여 더 가볍게 만들 수 있습니다.

고려해야 할 몇 가지 기술:

첫 번째 평가 엔진 단계의 초안

다음 단계의 순서가 반드시 주어진 것은 아닙니다. 내장 기능이 먼저 사용되지만 대부분은 서로 독립적입니다.

내장 기능

phabricator:T260321를 참조하세요.

아주 작은 API - 아마도 하나의 평가 방법으로 시작할 수도 있습니다.
캐싱이 없습니다.
phabricator:T261474에서 설명한대로 첫 번째 내장 집합의 일부(또는 전체)를 구현합니다.
함수 호출이 아닌 모든 것은 있는 그대로 반환됩니다(표준화될 수 있음).
예시: "Test"은 "Test"로 평가됩니다.
함수 호출인 모든 것은 고정점까지 평가됩니다.
예시: if(true, "Yes", "No")은 "Yes"로 평가됩니다.
인수가 함수 호출이면 고정 소수점까지 평가됩니다.
예시: head(tail(["1", "2", "3"]))은 "2"로 평가됩니다.

이 모든 것이 이미 위키에 대한 참조를 확인해야합니다. 함수 head는 위키에서 함수이고, 조회해야하며 구현을 수집해야하며 (현재는 내장 구현만 있음) 구현을 선택하고 평가해야합니다. .

구현을 선택하는 첫 번째 버전은 무엇이든 선택하는 것입니다. 나중에 수정해야합니다.

샌드박싱 및 모니터링

샌드박싱에 필요한 모든 단계를 구현하고 평가 엔진 (Phabricator:T261470)을 모니터링합니다.

이 중 많은 부분이 쿠버네티스(Kubernetes)를 통해 제공되어야합니다. 그러나 우리는 "함수가 얼마나 자주 호출 되었습니까?", "캐시 미스가 얼마나 자주 발생 했습니까?" 등과 같은 통계를 유지하고 싶을 것입니다.

중간 캐싱

중간 결과의 캐싱을 도입하세요.

함수 호출을 평가하기 전에 이것이 캐시에 있는지 확인하고 대신 반환하세요.

캐시를 재설정할 수 있습니다.

편집하면 캐시가 무효화됩니다

기존 Z객체를 편집하면 전체 캐시가 무효화됩니다. 우리는 이 행동을 천천히 개선 할 것입니다 (이상적으로 편집은 무효화해야하는 캐시만 무효화하지만 빠르게 복잡해집니다. 나중에 설명하겠습니다.)

중간 캐싱이 필요합니다.

구현 작성

컴포지션(Phabricator:T261468)인 구현을 허용합니다.

자바스크립트 구현

자바 스크립트 구현을 허용합니다.

위키데이터

위키데이터를 호출 할 수 있습니다.

공용

공용의 파일을 호출 할 수 있습니다.

기타 위키미디어

다른 위키미디어 속성을 호출 할 수 있습니다.

웹 호출

일반적으로 웹을 호출 할 수 있습니다.

비 함수적 함수

특히 "현재 시간" 및 "무작위".