프록시 계정을 한 명 이상의 사람이나 프로젝트가 사용하게 되면 항상 같은 질문이 등장한다. 팀 전체가 하나의 자격 증명을 공유하는 것을 어떻게 막을 것인가. 어떤 클라이언트가 몇 기가바이트를 소비했는지 어떻게 구분할 것인가. 다른 모든 사람에게 영향을 주지 않으면서 계약직 인력의 접근을 어떻게 차단할 것인가. 이 업계에서는 이런 질문에 대개 “서브유저(sub-users)“라는 표현으로 답하는데, 이 표현은 판매하는 주체에 따라 의미가 달라진다.
여기서는 서브유저가 실제로 무엇인지, 레지덴셜 제품이 무엇을 제공하고 무엇을 제공하지 않는지, 그리고 두 경우 모두에서 세 가지 근본적인 문제를 어떻게 해결할 수 있는지 다룬다.
What sub-users mean in this market
프로바이더가 서브유저 기능을 제공하는 경우, 서브유저란 상위 계정 아래에서 발급되는 보조 프록시 자격 증명 집합이다. 일반적으로 자체 대역폭 한도를 가질 수 있고, 때로는 자체 타겟팅 제한도 가지며, 상위 계정에 영향을 주지 않고 해지할 수 있다. 이는 트래픽 자체에 결부된 접근 제어 기능이다.
팀들이 서브유저를 원하는 이유는 세 가지로 구분되며, 각각 해결책이 다르므로 이를 분리해서 볼 필요가 있다.
격리(Isolation). 서로 다른 사람이나 프로젝트가 하나의 자격 증명을 공유해서는 안 되며, 이는 유출이나 인력 이탈이 발생했을 때 피해 범위를 제한하기 위함이다.
귀속(Attribution). 어떤 클라이언트, 팀, 프로젝트가 대역폭의 어느 부분을 사용했는지 파악해야 하며, 이는 대개 청구나 마진 계산을 위한 것이다.
제한(Limits). 한 프로젝트가 실수나 폭주하는 작업으로 인해 전체 플랜을 소비해버리는 일이 없어야 한다.
What the residential product provides
솔직히 말하면, Shifter의 레지덴셜 프록시에는 서브유저별 프록시 자격 증명이 없다. 인증은 하나의 사용자명과 비밀번호로 이루어지며, 타겟팅과 세션 옵션은 사용자명 안에 표현된다. 이는 게이트웨이 및 인증 문서에 설명되어 있다. 자체 대역폭 한도를 가진 두 번째 프록시 자격 증명을 발급하는 기능은 존재하지 않는다.
실제로 존재하는 것은 두 가지 메커니즘으로 나뉘며, 이 둘을 합치면 위의 세 가지 문제를 모두 다룬다.
Team Workspaces는 계정에 대한 접근을 관리한다. 이메일로 사람을 초대하고 역할을 지정할 수 있는데, Viewer는 멤버십, 트래픽, 인보이스를 읽기 전용으로 볼 수 있고, Billing은 여기에 더해 충전과 구매가 가능하며, Admin은 멤버십과 팀 관리 전반을 담당한다. 역할은 전역이 아니라 워크스페이스별로 범위가 지정되며, 제거는 즉시 이루어져 기존 세션도 종료되고, 한 사람이 여러 워크스페이스에 속하면서 하나의 로그인으로 이들 사이를 전환할 수 있다. 전체 동작 방식은 Team Workspaces 공지에 나와 있다.
세션 식별자는 트래픽의 구분을 담당한다. 모든 요청에 원하는 세션 ID를 붙일 수 있으며, 이것이 별도의 자격 증명 없이도 클라이언트별, 프로젝트별 귀속을 가능하게 만드는 요소다.
기억해야 할 구분은 이것이다. 워크스페이스는 누가 계정을 관리할 수 있는지를 통제하고, 세션 식별자는 트래픽이 무엇을 하고 있는지를 정리한다. 다른 곳에 존재하는 서브유저는 이 둘을 뒤섞어 놓는다.
Solving isolation without sub-users
하나의 자격 증명이 모든 것을 처리하므로, 격리 작업은 그 자격 증명을 어떻게 저장하고 노출하는지의 문제로 옮겨간다.
자격 증명은 코드나 설정, 공유 문서에 두지 말고 시크릿 매니저에 보관하고, 애플리케이션이 런타임에 환경에서 읽어오도록 한다. 사람이 업무를 수행하는 데 프록시 자격 증명이 필요한 것이 아니라 시스템이 필요한 것이다. 테스트가 필요한 엔지니어에게는 값 자체가 아니라 그 값을 사용하는 서비스에 대한 접근 권한을 부여하면 된다.
진짜로 별도의 피해 범위가 필요한 경우, 각자 플랜을 가진 별도의 워크스페이스를 사용하면 실제로 분리된 자격 증명을 얻을 수 있는데, 플랜은 워크스페이스를 넘나들지 않기 때문이다. 이는 서브유저보다 무거운 방법이고 청구가 별도로 이루어진다는 의미이므로, 단순히 정리를 원하는 경우보다는 클라이언트나 사업부가 원래부터 자체 계정을 소유해야 하는 경우에 적합하다.
그리고 필요해지기 전에 로테이션 계획을 세워둔다. 하나의 자격 증명을 공유하기 때문에 이를 로테이션하면 모든 것에 동시에 영향을 미치므로, 이를 하나의 배포처럼 다뤄야 한다. 즉 시크릿 저장소를 업데이트하고, 모든 클라이언트에 순차적으로 적용한 뒤, 기존 값을 무효화한다. 이 순서를 건너뛰면 팀이 자격 증명이 얼마나 많은 곳에 존재하는지 알게 되는 가장 흔한 방식으로 이어지는데, 그 모든 곳에서 동시에 407 오류가 발생하기 시작하기 때문이다.
시스템이 아닌 사람의 경우, 오프보딩은 워크스페이스 역할을 통해 이루어진다. 멤버를 제거하면 열려 있던 세션을 포함해 패널 접근이 즉시 종료된다. 이는 대개 실제로 묻고 싶어 하는 계약직 사례를 다룬다.
Solving attribution without sub-users
이 부분에서 세션 식별자가 작업을 수행하며, 처음부터 의도적으로 구조화해두는 것이 좋다.
세션 ID에 테넌트 정보를 인코딩해서 모든 요청이 누구를 위한 것이었는지 추적 가능하게 만든다. ID는 원하는 어떤 문자열이든 가능하므로, 구조화된 규칙을 정해도 비용이 들지 않으며, 귀속 문제는 자신의 로그를 파싱하는 문제로 바뀐다:
def proxy_for(client, job, country, ttl=600):
sid = f"{client}-{job}" # e.g. acme-prices-0827
user = f"customer-USERNAME-country-{country}-sid-{sid}-ttl-{ttl}"
url = f"http://{user}:PASSWORD@p.shifter.io:443"
return {"http": url, "https": url}그런 다음 요청별 바이트 수를 클라이언트에 대해 기록한다. 프로바이더의 인보이스는 계정 전체에 대한 단일 합계이므로 분할 내역을 알려주지 않기 때문이다. 테넌트별로 응답 크기를 합산하면 청구나 마진 계산에 사용할 수 있는 사용량 수치를 얻을 수 있고, 주기적으로 자신의 합계와 인보이스를 대조하면 정확성을 유지할 수 있다. 재시도, 실패한 요청, 연결 오버헤드가 모두 대역폭을 소비하는데 단순한 본문 크기 계산으로는 이를 놓치기 때문이다. 테넌트별로 지켜봐야 할 지표는 레코드당 바이트 수이며, 이는 프록시 KPI에서 다루고 있고, 귀속을 비용에 관한 논의로 바꿔주는 수치다.
세션은 여기서도 원래 목적을 수행한다. 클라이언트마다 다른 식별자를 사용하면 두 클라이언트의 흐름이 같은 세션에서 충돌하는 것을 막을 수 있는데, 이는 한 번에 하나 이상의 작업이 실행되는 즉시 중요해진다. 관련 동작 방식은 고정 대 로테이팅에서 다룬다.
Solving limits without sub-users
프로바이더 측에는 테넌트별 한도가 없으므로, 한도는 자체 스케줄러 안에 두어야 한다. 사실 원래부터 그곳에 있어야 하는 것이기도 하다. 클라이언트가 어느 정도를 사용할 권리가 있는지는 자신의 시스템이 알고 있고, 프록시는 알지 못한다.
각 테넌트에게 해당 기간의 대역폭 예산을 부여하고, 이미 기록하고 있는 사용량에 대해 이를 강제하여, 예산이 소진되면 공유 할당량을 계속 소비하게 두지 말고 해당 테넌트의 작업을 중단하거나 대기열에 넣는다. 경고는 한도에 도달했을 때가 아니라 그보다 훨씬 전에 보낸다. 여기에 테넌트별 동시성 할당을 더해서 하나의 대형 야간 배치 작업이 시간에 민감한 네 개의 소규모 작업을 굶기지 않도록 하고, 테넌트별 재시도 예산을 더해서 한 클라이언트의 실패하는 타겟이 공유 풀을 넘치게 하지 못하도록 한다. 이러한 억제 논리는 재시도와 백오프와 레이트 리미팅에서 다룬다.
이 모든 것이 자연스럽게 자리할 곳은 이미 모든 요청을 보고 있는 컴포넌트이며, 그래서 테넌트 예산, 동시성 할당, 귀속 정보를 여러 작업에 흩어놓기보다 프록시 매니저에 두는 것이 옳다.
Choosing between one account and many workspaces
이 결정은 보통 보이는 것보다 단순하며, 결국 누가 상업적 관계를 소유하는가로 귀결된다.
서비스를 제공하는 입장이고 벤더가 자신의 공급망에 해당하는 경우에는 논리적 테넌트를 가진 하나의 계정을 운영한다. 대역폭을 구매하는 것은 자신이고, 클라이언트는 프로바이더를 전혀 보지 않으며, 구분은 자신의 코드 안에서의 명명 규칙일 뿐이다. 이는 일반적인 에이전시 형태다.
클라이언트가 자체 플랜과 인보이스를 소유해야 하는 경우에는 클라이언트별로 워크스페이스를 운영하고, 자신의 팀을 Admin으로 추가한다. 청구는 실제로 분리되고, 플랜이 워크스페이스를 넘나들지 않으므로 트래픽이 섞일 수 없으며, 계약이 종료되면 클라이언트가 깔끔하게 인수할 수 있다.
처음부터 테넌트 식별자를 중심으로 설계해두면, 이 둘 사이를 이동하는 일이 재구축이 아니라 설정 변경 수준으로 끝난다.
The bottom line
서브유저는 세 가지 별개의 필요에 대한 하나의 구현 방식일 뿐, 유일한 구현 방식은 아니다. 레지덴셜 제품에는 하나의 프록시 자격 증명만 존재하므로, 격리는 시크릿 관리에서 나오고, 반드시 완전히 분리되어야 하는 경우에는 각자 플랜을 가진 별도의 워크스페이스에서 나온다. 사람에 대한 접근 제어는 즉시 해지가 가능한 워크스페이스 역할에서 나온다. 귀속은 구조화된 세션 식별자와 자체적인 테넌트별 바이트 집계에서 나오는데, 인보이스가 단일 합계이기 때문이다. 그리고 제한은 각 테넌트가 어느 정도를 사용할 권리가 있는지 아는 유일한 곳인 자체 스케줄러의 예산에서 나온다. 처음부터 테넌트 식별자를 중심으로 구축한다면 이 세 가지를 모두 얻을 수 있고, 나중에 수집 코드를 건드리지 않고도 클라이언트를 자체 워크스페이스로 옮길 수 있는 선택권도 유지할 수 있다.
그 아래에 있는 계층이 레지덴셜 프록시다. 국가, 도시, 세션, TTL이 모두 요청 단위로 표현되는 하나의 게이트웨이이며, 이것이 바로 테넌트별 구분을 제품의 제약이 아니라 명명 규칙으로 만드는 요소다. 여기에 GB당 가격 정책이 더해져, 내부적으로 귀속시키는 사용량이 실제 청구되는 단위와 동일하게 측정된다.