읽기 게이트웨이

읽기 게이트웨이는 다운로드만 제공하는 추가 API 프로세스입니다. 주 API(쓰기 서버)와 같은 서버에서 실행되고, 같은 PostgreSQL 데이터베이스와 같은 스토리지 디렉터리를 사용하며, 쓰기 서버 및 다른 게이트웨이와 하나의 다운로드 예산을 공유합니다.

많은 병렬 다운로드를 여러 프로세스로 분산하면서도 전체 다운로드 속도를 직접 정한 하나의 제한 아래로 유지하려면 게이트웨이를 사용하세요. 게이트웨이는 데이터를 복사하지 않습니다. 쓰기 서버가 게시한 파일을 읽으므로 게이트웨이가 뒤처지는 일은 없습니다. 반면 서버나 디스크의 손실로부터 보호해 주지는 않습니다. 이에 대해서는 백업과 미러를 참조하세요.

동작 방식

설치 환경에는 쓰기 서버 하나와 읽기 게이트웨이 최대 15개가 있습니다. 합쳐서 최대 16개의 슬롯입니다. 쓰기 서버는 항상 슬롯 0을 사용합니다. 각 게이트웨이는 1부터 슬롯 수 − 1까지의 슬롯 중 자신의 슬롯을 사용합니다.
모든 프로세스는 하나의 PostgreSQL 데이터베이스와 하나의 스토리지 디렉터리를 사용합니다. 게이트웨이는 스토리지가 존재하고 데이터베이스에 속하는지 확인합니다. 스토리지를 만들지는 않습니다.
모든 프로세스의 전체 다운로드 속도를 하나로 정합니다. 각 프로세스는 같은 고정 몫, 즉 전체를 슬롯 수로 나눈 값(소수점 이하 버림)을 받습니다.
프로세스는 데이터베이스의 리스(lease)로 슬롯을 유지합니다. 리스를 잃으면 새 페이로드 제공을 멈추며 다시 시작해야 합니다. 이렇게 해서 모든 몫의 합이 전체 값을 넘지 않게 합니다.

쓰기 서버는 평소 역할을 유지합니다. 업로드, 콘솔, 백그라운드 정리, 모든 변경을 처리합니다. 게이트웨이는 정리를 실행하지 않습니다.

게이트웨이가 거부하는 요청

게이트웨이는 GET과 HEAD만 받습니다. 무언가를 변경하는 모든 요청은 키에 쓰기 권한이 있어도 헤더 Allow: GET, HEAD와 코드 read_only가 포함된 HTTP 405를 받습니다. 로그인과 직접 가입도 여기에 포함됩니다. 콘솔은 쓰기 서버에만 있으므로 게이트웨이에서는 사용할 수 없습니다.

리포지토리 권한은 쓰기 서버와 마찬가지로 읽을 때마다 확인됩니다. 세션, 개인용 토큰, 서비스 키는 게이트웨이에서 읽기에 사용할 수 있습니다.

요구 사항

같은 서버. 게이트웨이는 쓰기 서버가 게시한 파일을 지연 없이 정확히 볼 수 있어야 합니다. rsync나 다른 비동기 복사를 사용하는 독립 디스크는 맞지 않습니다. 아직 인증된 네트워크 파일 시스템이 없으므로, 게이트웨이는 한 서버의 여러 프로세스용으로만 사용하세요.
같은 서비스 키. 파일 키와 그 ID가 일치하도록 모든 프로세스에 같은 ARKVORY_KEYS_FILE 내용을 제공하세요. 관리형 서비스 키는 데이터베이스에 있으므로 저절로 일치합니다.
자체 포트. 같은 호스트의 모든 프로세스에는 각자의 ARKVORY_PORT가 필요합니다.
파일의 읽기 전용 보기. 가능하면 게이트웨이에는 스토리지 디렉터리를 읽기 전용으로 마운트하세요. HTTP 거부는 운영 체제 권한을 대신하지 않습니다. 게이트웨이도 데이터베이스에는 쓴다는 점에 유의하세요. 리스, 스토리지 진단, 개인용 토큰의 마지막 사용 시각, 읽는 중인 파일을 보호하는 잠금을 씁니다.
데이터베이스 연결. 게이트웨이마다 ARKVORY_DATABASE_POOL_SIZE보다 연결이 세 개 더 필요합니다. PostgreSQL의 max_connections에 포함해 계산하세요.

게이트웨이 실행

설치 프로그램은 API, 워커, 백업 에이전트를 등록합니다. 게이트웨이는 등록하지 않으며 arkvory status도 게이트웨이를 관리하지 않습니다. 게이트웨이는 직접 시작합니다. 설치된 릴리스의 API 프로그램을 인스턴스 하나 더 띄우되, 자체 환경 변수를 주고 직접 사용하는 서비스 관리자 아래에서 실행합니다.

전체 프로세스가 둘이고 전체 속도가 64 MiB/s, 계정 또는 키 하나당 16 MiB/s일 때 모든 프로세스에 같은 설정은 다음과 같습니다.

dotenv

ARKVORY_GATEWAY_SLOTS=2
ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECOND=67108864
ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECOND_PER_PRINCIPAL=16777216

쓰기 서버에는 다음을 추가합니다.

dotenv

ARKVORY_ROLE=api
ARKVORY_GATEWAY_SLOT=0

게이트웨이에는 다음을 추가합니다.

dotenv

ARKVORY_ROLE=reader
ARKVORY_GATEWAY_SLOT=1
ARKVORY_PORT=8081

게이트웨이에는 나머지 API 설정도 필요합니다. 같은 데이터베이스의 ARKVORY_DATABASE_URL, 같은 스토리지로 이어지는 ARKVORY_DATA_DIR(경로는 달라도 되지만 스토리지 식별 정보는 일치해야 합니다), ARKVORY_KEYS_FILE, 그리고 게이트웨이가 다른 컴퓨터에서 접근 가능하다면 HTTPS 설정입니다. 환경 변수를 참조하세요.

변수	규칙
`ARKVORY_GATEWAY_SLOTS`	쓰기 서버를 포함한 프로세스 수, 2–16
`ARKVORY_GATEWAY_SLOT`	이 프로세스의 슬롯, 0부터 슬롯 수 − 1까지. 쓰기 서버는 0이고 게이트웨이는 0이 아닙니다
`ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECOND`	필수. 모든 프로세스의 전체 속도로, 슬롯 수 × 65 536 이상, 최대 초당 1 TiB
`ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECOND_PER_PRINCIPAL`	계정 또는 키 하나의 모든 프로세스에 걸친 전체 속도. `0`은 제한 없음을 뜻합니다. 그 외에는 위와 같은 범위입니다

이 변수 중 하나라도 설정하면 모든 프로세스에 슬롯, 슬롯 수, 전체 속도를 설정하세요. 잘못된 값은 변수 이름을 알려 주는 메시지와 함께 시작 시 프로세스를 중지시킵니다. 공유 다운로드 설정이 없는 게이트웨이는 시작을 거부합니다.

슬롯 수와 속도를 정하세요.
공통 변수 세 개와 쓰기 서버 전용 변수 두 개를 쓰기 서버에 추가하고 쓰기 서버를 다시 시작하세요. 쓰기 서버가 정책을 데이터베이스에 저장합니다.
게이트웨이를 자체 변수와 함께 시작하세요. 숫자가 저장된 정책과 다르면 시작되지 않습니다.
모든 프로세스의 준비 상태를 확인하고 각 프로세스에서 범위 다운로드를 테스트하세요. 게이트웨이 모니터링을 참조하세요.
그런 다음에 게이트웨이를 로드 밸런서에 추가하세요.

몇 가지 규칙이 이 구성을 보호합니다.

게이트웨이는 쓰기 서버가 정책을 저장한 뒤에만 시작할 수 있습니다.
정책이 데이터베이스에 한 번 만들어지면, 이 변수가 없는 쓰기 서버는 시작되지 않습니다. 데이터베이스가 공유 다운로드 설정을 요구한다는 메시지와 함께 중지됩니다.
실행 중인 설치 환경에서는 속도나 슬롯 수를 변경할 수 없습니다. 구성 변경을 참조하세요.

다운로드 예산

각 프로세스는 total / slots(소수점 이하 버림)를 받습니다. 계정 또는 키 하나의 속도에도 같은 계산이 적용됩니다. 예를 들어 64 MiB/s에 슬롯이 2개이면 각 프로세스는 최대 32 MiB/s를 제공하고, 계정 하나는 각 프로세스에서 최대 8 MiB/s를 받습니다.

프로세스는 다른 프로세스의 몫을 사용할 수 없습니다. 두 프로세스 중 하나가 중지되면 전체의 절반만 사용할 수 있습니다. 이렇게 하면 제한이 단순하고 확인 가능합니다.
로컬 설정 ARKVORY_DOWNLOAD_BYTES_PER_SECOND와 ARKVORY_DOWNLOAD_BYTES_PER_SECOND_PER_PRINCIPAL은 몫을 낮출 수는 있지만 높일 수는 없습니다.
게이트웨이는 업로드를 받지 않으므로 업로드 예산은 쓰기 서버에 남습니다.
대기 중인 전송의 대기열과 활성 전송 제한은 각 프로세스에 로컬이므로 모든 프로세스의 용량이 합산됩니다.

이 제한은 약간의 버스트를 허용하는 애플리케이션 페이로드에 적용됩니다. 네트워크 인터페이스에 대한 제한이 아닙니다. 환경 변수를 참조하세요.

리스와 장애

데이터베이스는 슬롯을 10초 동안 예약합니다. 프로세스는 2초마다 이를 갱신하며, 리스를 로컬에서는 최대 8초까지만 신뢰합니다. 시간이 끝난 리스는 늦은 응답이 도착해도 되살아나지 않습니다.

리스 상실. 프로세스가 새 페이로드 제공을 멈추고, 새로 인증된 요청에는 503으로 응답하며, 다시 시작해야 합니다. 끊긴 다운로드는 재시도 또는 범위 요청으로 이어서 받을 수 있습니다. 쓰기 서버에도 적용됩니다.
같은 슬롯의 재시작. 새 프로세스는 마지막 갱신 후 최대 10초, 전체로는 최대 15초까지 기존 예약이 만료되기를 기다립니다. 실행 중인 게이트웨이가 아직 그 슬롯을 갖고 있으면 새 프로세스는 busy와 함께 중지됩니다.
시계. 리스는 일정하게 흐르는 시계에 의존합니다. 데이터베이스 서버 시계의 점프나 가상 머신의 중지가 있으면 프로세스가 리스 기간을 넘겨서 계속 제공할 수 있습니다. 이런 경우에는 교체 프로세스를 시작하기 전에 이전 프로세스를 중지하세요.
데이터베이스 장애. 데이터베이스가 약한 지점입니다. 데이터베이스에 접근할 수 없게 되면 리스가 만료되고 모든 프로세스가 페이로드 제공을 멈춥니다.

네트워크가 끊긴 죽은 프로세스를 서버가 알아챌 수 있는 방법은 TCP keepalive뿐입니다. PostgreSQL에 tcp_keepalives_idle, tcp_keepalives_interval, tcp_keepalives_count를 예를 들어 10초, 5초, 3회로 설정하거나 tcp_user_timeout을 설정하세요. 설정하지 않으면 새 쓰기 서버나 워커가 운영 체제의 긴 기본 타임아웃을 기다릴 수 있습니다.

게이트웨이 모니터링

GET /health/status는 공개되어 있으며 ready, unavailable, draining만 반환합니다. 프로세스가 제공할 수 없을 때(슬롯 또는 리스 상실, 종료 처리 중)는 503입니다. 로드 밸런서에 사용하세요.
GET /health/ready에는 키가 필요합니다. role, writable(게이트웨이에서는 항상 false), slot, slots, active, leaseSeconds가 있는 sharedDownloads, 그리고 로컬 전송 대기열의 숫자를 반환합니다. 슬롯을 잃었으면 503으로 응답합니다. 독립 실행형 설치 환경에서는 sharedDownloads가 null입니다.
GET /health/live는 HTTP 프로세스가 실행 중이라는 것만 보여 줍니다. 게이트웨이가 제공할 수 있는지는 알려 주지 않습니다.
각 프로세스의 GET /health/metrics는 해당 프로세스만 보여 줍니다. 모든 게이트웨이를 수집하고 프로세스 수준의 HTTP 및 전송 메트릭을 사용하세요.

각 프로세스를 따로 확인하세요. 게이트웨이의 writable이 false인 것은 정상입니다. 모니터링을 참조하세요.

요청 라우팅

로드 밸런서는 직접 준비해야 합니다. Arkvory는 로드 밸런서를 제공하지 않습니다.

데이터를 변경하는 모든 요청과 /console/은 쓰기 서버로 보내세요.
바이트 읽기는 쓰기 서버와 게이트웨이에 분산할 수 있습니다. 대상은 /api/v1/repositories/NAME/artifacts/ID/content, .../packages/content, .../asset/content에 대한 GET과 HEAD입니다. 다른 요청은 쓰기 서버에 두세요.
Authorization, Range, If-Range, ETag 헤더를 그대로 전달하세요. 파일 전체를 버퍼링하지 말고 본문을 스트리밍하세요. 클라이언트를 키가 포함된 URL로 리디렉션하지 마세요.
인증된 준비 상태가 ok일 때만 백엔드를 로드 밸런서에 추가하세요.

TypeScript SDK는 같은 주소 뒤에 있는 정상 상태의 다른 백엔드를 통해 중단된 다운로드를 이어서 받을 수 있습니다. 실행 중인 TCP 연결은 서버 사이를 이동하지 않습니다.

구성 변경

설치 환경이 실행 중일 때는 속도나 슬롯 수를 변경할 수 없고, 정책이 존재하는 동안에는 단일 프로세스로 돌아갈 수도 없습니다. 모든 게이트웨이를 중지하더라도 저장된 정책이 제한 없는 시작을 막습니다.

들어오는 트래픽을 중단하세요. 쓰기 서버, 모든 게이트웨이, 워커를 중지하고 실제로 중지되었는지 확인하세요.
데이터베이스의 리스가 만료될 때까지 기다리세요.
백업을 만드세요. 백업을 참조하세요.
Arkvory 데이터베이스의 관리자가 테이블 arkvory_gateway_leases와 arkvory_download_policy의 모든 행을 하나의 트랜잭션으로 삭제합니다. 이 작업은 조정 상태만 초기화하며 카탈로그는 건드리지 않습니다.
새 설정으로 쓰기 서버를 시작한 다음 게이트웨이를 시작하세요.

실행 중일 수 있는 프로세스가 하나라도 있다면 이 작업을 절대 수행하지 마세요.

업데이트에도 같은 주의가 필요합니다. 설치 환경을 업데이트하기 전에 모든 게이트웨이를 중지하고, 업데이트 후 새 릴리스로 시작하세요. 이전 코드로 더 새로운 데이터베이스 스키마를 계속 사용하는 게이트웨이는 스스로 준비되지 않았다고 보고합니다. 정리를 위한 오프라인 복구 도구도 모든 게이트웨이가 중지되어 있어야 합니다. 쓰기 서버의 온라인 정리는 그렇지 않습니다.

게이트웨이 또는 미러

	읽기 게이트웨이	미러
정의	같은 서버와 스토리지의 추가 API 프로세스	데이터 사본이 있는 독립적인 두 번째 설치 환경
데이터	사본 하나를 실시간으로 읽음	지연을 두고 가져온 두 번째 사본
계정과 키	쓰기 서버와 같음	자체 계정과 키
추가 디스크	없음	있음. 리포지토리에 필요한 만큼
필요한 것	같은 데이터베이스와 같은 파일 시스템	원본으로의 HTTPS 링크와 읽기 전용 키
서버나 디스크의 손실로부터 보호	아니요	일부: 원본이 중단된 동안 서비스를 제공하며 미러로 전환할 수 있음
용도	하나의 공유 속도 제한 아래에서 더 많은 병렬 다운로드	두 번째 사이트, 사용자와 더 가까운 사무실, 대기 서버

둘 다 백업을 보완하는 수단이며 백업을 대체하지 않습니다.

제한 사항

모든 프로세스는 서버 하나와 스토리지 디렉터리 하나를 공유해야 합니다. 서로 다른 컴퓨터에는 이를 위해 테스트된 파일 시스템이 필요한데, 아직 테스트된 것이 없습니다.
설치 프로그램 지원, 자동 장애 조치, 내장 로드 밸런서가 없습니다.
데이터베이스 하나와 쓰기 서버 하나는 여전히 단일 장애 지점입니다.
예산은 슬롯마다 고정되며 재분배되지 않고, 우선순위 스케줄링도 없습니다.
실행 중인 설치 환경에서는 정책을 변경할 수 없습니다.

읽기 게이트웨이 ​

동작 방식 ​

게이트웨이가 거부하는 요청 ​

요구 사항 ​

게이트웨이 실행 ​

다운로드 예산 ​

리스와 장애 ​

게이트웨이 모니터링 ​

요청 라우팅 ​

구성 변경 ​

게이트웨이 또는 미러 ​

제한 사항 ​

관련 페이지 ​

읽기 게이트웨이

동작 방식

게이트웨이가 거부하는 요청

요구 사항

게이트웨이 실행

다운로드 예산

리스와 장애

게이트웨이 모니터링

요청 라우팅

구성 변경

게이트웨이 또는 미러

제한 사항

관련 페이지