양 방향 트래픽, 한 박스
환영
대부분의 아키텍처 다이어그램은 트래픽이 한 방향으로만 이동한다고 표시합니다: 클라이언트가 위쪽, 서버가 아래쪽, 화살표가 아래쪽으로指向합니다. 현실은 트래픽이 양쪽 방향으로 이동합니다.
인그레스: 외부 클라이언트가 서비스에 이 경로를 통해 도달합니다. 네트워크의 가장자리에서 역프록시가 TLS를 종료하고 요청을 라우팅하며 액세스 정책을 강제합니다.
에그레스: 서비스가 외부 서비스에 이 경로를 통해 도달합니다. 결제 처리기 API에 호출, 웹훅 대상에 가져오기, 파트너에 대한 요청 보내기 등이 포함됩니다. 일반적으로 허용 목록을 통해 전방 프록시 또는 NAT 게이트웨이로 통과합니다.
많은 아키텍처는 처음에는 양쪽 일을 모두 처리하는 한 박스에서 시작합니다. 일단 문제가 발생하지 않으면, 충분한 내부 서비스가 존재할 때까지 문제가 드러나지 않습니다. 실패 모드는 미묘하며, 중요한 관심사 분리 수업을 가르쳐줍니다.
이 강의를 마치면 이해할 수 있는 내용입니다:
- 인그레스 및 에그레스는 서로 다른 트래픽 패턴을 가지며, 서로 다른 확장 축과 서로 다른 실패 모드를 나타냅니다.
- Hairpin NAT 및 프록시가 자신自身에 연결하려는 시도하는 이유
- 건축적 분기: 한 박스가 두 박스로 변하며 각자가 독점적으로 소유하는 것
- 보안 격리 이점: 각 쪽은 실제로 허용되는 동료에만 강화할 수 있습니다.
- 한 박스 설계가 분리가 필요한 지점을 식별하는 방법
왜 방향이 다른 도구를 요구하는가
두 개의 네트워크 경계에서 다른 작업負荷
인그레스 트래픽 특성:
- 외부 파티가 시작하는 것(인터넷 전체)
- 사용자 기반에 따라 볼륨이 확장됩니다
- TLS 종료, 요청 라우팅, 출처별 제한
- 깊이 있는 방어: DDoS, 방해, 스크레이핑
- 공인 IP가 누구나로부터 연결을 수락해야 합니다
에그레스 트래픽 특성:
- 서비스 자체가 시작하는 것(알고 있는 작은 클라이언트 세트)
- 볼륨은 서비스 간 및 외부-API 호출 패턴에 따라 확장됩니다
- 원본 IP 허용 목록 설정 (파트너들이 신뢰하는 고정 외부 IP가 하나 있음)
- 깊이 있는 방어에 대한 우려: 데이터 유출, 내부 서비스가 외부로 호출되는 경우
- 다른 서비스 외에 연결을 거절해야 합니다
주요 대칭성: 인가(ingress)는 세계에서 트래픽을 받아들입니다. 이그레이스(egress)는 자신의 서비스들만에서 트래픽을 받아들입니다. 두 가지 기능을 모두 가진 머신은 세계에서 인가로부터 트래픽을 받아들일 수 있어야 하며, 이그레이스에서는 자신의 서비스들로부터만 접근할 수 있어야 합니다. 이러한 경우, 하나의 머신에 두 가지 역할을 두면 그 머신은 세계에서 인가로부터 트래픽을 받아들일 수 있어야 하며, 이그레이스에서는 자신의 서비스들로부터만 접근할 수 있어야 합니다. 이러한 경우, 하나의 머신에 두 가지 역할을 두면 그 머신은 세계에서 인가로부터 트래픽을 받아들일 수 있어야 하며, 이그레이스에서는 자신의 서비스들로부터만 접근할 수 있어야 합니다. 이러한 경우, 하나의 머신에 두 가지 역할을 두면 그 머신은 세계에서 인가로부터 트래픽을 받아들일 수 있어야 하며, 이그레이스에서는 자신의 서비스들로부터만 접근할 수 있어야 합니다.
성장 경로: 작은 프로젝트는 외부 IP와 도구 하나로 숨길 수 있으며, 프로젝트가 성장함에 따라 두 역할 간의摩擦(friction)이 증가하고, 한 날 특정 실패 모드(hairpin NAT)가 분리되도록 강요받게 됩니다.
The Bug That Forces the Split
###_SANITIZE_OUTAGE_story
실제 배포 환경에서 발생하는 아키텍처 분기(fork) 그림을 상상해보세요. 아래에 사용된 이름은 실제로 변경되었으며, 실제 세계에서 팀이 겪는 모양과 동일합니다.
한 조직은 203.0.113.5에 단일 프록시 서버를 실행합니다. 이 서버는 인가(port 443 사용자) 및 이그레이스(internal 서비스가 외부로 호출할 때 SOCKS5 port 1080) 모두 처리합니다. 내부 서비스는 SOCKS5 프록시 203.0.113.5:1080를 통해 모든 외부 트래픽을 라우팅합니다.
api.example.com이 있는 서비스가 203.0.113.5 뒤에 위치합니다. api.example.com은 203.0.113.5으로 PUBLIC DNS가 해결됩니다.
다른 내부 서비스가 api.example.com을 호출해야 하는 경우:
1. 내부 서비스는 api.example.com을 203.0.113.5으로 해결합니다
2. 내부 서비스는 SOCKS5 이그레이스 프록시 203.0.113.5:1080로 요청을 전송합니다
3. 프록시는 자신이 아닌 자신에게 연결을 시도합니다 203.0.113.5:443
4. 연결 거절됨. 패킷은 대부분의 네트워크 스택이 거부하는 것처럼 같은 NAT를 выход하고 재입입해야 합니다. 프록시는 자신의 공인 IP를 통해 자신에게 연결할 수 없습니다.
이 헤어핀 NAT는 무엇인가요?: NAT에서 패킷이 나가야 다시 같은 NAT를 통해서 목적지에 도달할 수 있는 패킷입니다. 라우팅 계층의 특별한 헤어핀 지원이 없다면 패킷은 떨어집니다.
왜 늦게 나타나는가
이 프로젝트의 초기 단계에서 모든 내부 서비스는 private hostname (internal-api.local)를 통해 다른 내부 서비스와 통신하거나 자신의 조직의 퍼블릭 서비스에 되돌아가지 않았습니다. 헤어핀 경로는 존재하지 않았습니다.
그런 다음 새로운 기능이 서비스 A가 api.example.com (퍼블릭 호스트명)을 호출해야 함을 요구했습니다. 헤어핀 경로가 활성화되었습니다. 연결 거부. 장애.
해결책은 증상에 패치를 적용했습니다 (리졸버를 통해 api.example.com의 private IP를 대신 퍼블릭 IP를 제공하도록 강제).根本 원인: 단 하나의 박스가 너무 많은 일을 했습니다.
건축적 분기
하나의 박스가 두 개로
정확한 해결책: 프록시를 두 대의 기계로 분리합니다.
인기 서버 (퍼블릭 IP 203.0.113.5):
- Caddy / 역프록시 서버, 포트 80, 443
- 공인 DNS 레코드가 여기로指向
- api.example.com, app.example.com 등 호스트
이그레스 서버 (다른 퍼블릭 IP 203.0.113.99):
- SOCKS5 / 전달 프록시, 포트 1080
- 내부 서브넷 IP만 포함하는 incoming 연결만 허용
- 내부 서비스는 이 주소로 모든 outbound를 라우팅
이것이 구매하는 것:
1. 헤어핀 해결. 내부 서비스가 api.example.com을 호출할 때 outbound으로 203.0.113.99 (이그레스)으로 라우팅되고, 그 다음 정상적으로 203.0.113.5 (인기, 다른 IP)으로 연결됩니다. NAT 루프가 사라진 이유는 두 IP가 서로 다른 기계에 존재하기 때문입니다.
2. 보안 격리. 이그레스 서버의 방화벽은 작은 내부 IP 집합에만 제한을 두고 인기 서버의 방화벽은 세계에 열려 있습니다. 두 개의 별도의 규칙 세트로 각 역할을 명확하게 표현할 수 있습니다.
3. 독립적인 확장. 인기가 사용자에 따라 확장되고 내부 서비스 활동에 따라 이그레스 대역폭이 확장됩니다. 하나도 다른 것을 변경하지 않고 업그레이드할 수 있습니다.
4. 실패 격리. 이그레스가 잘못 구성되어도 공인 사이트가 깨지지 않습니다. 공인 사이트에 대한 DDoS 공격도 이그레스 대역폭을.starve하지 않습니다.
5. 더 명확한 정신 모델. 각 기계는 하나의 작업을 수행합니다. 엔지니어들은 인그레스 문제에 대해 생각하지 않고 이그레스에 대해 생각하지 않고, 그 반대도 마찬가지입니다.
두 축, 두 가지 규모 결정
독립적인 규모 조정
분할 이전에는 두 가지 방향 모두 같은 기계에 성장 압력이 있었지만, 분할 이후에는 각 방향이 자신의 배정에 따라 규모를 조절할 수 있게 되었습니다.
인그레스 규모 결정 : 사용자 수에 따라 조절됩니다. 용량 결정은 외부 대시보드 계층에 위치하며(역방향 프록시 복제본이 더 많거나 더 큰 VM, CDN 앞에 위치), 사용자가 정점에서 계산되는 최대 대역폭 예산과 함께 수행됩니다.
이그레스 규모 결정 : 내부 서비스에서 외부 API 호출량에 따라 조절됩니다. 일반적으로 웹훅 전송, 결제 처리기 호출 또는 세 번째 당사 데이터 가져오기와 같은 요소에 의해 주도됩니다. 내부 호출 패턴에 따라 계산되는 대역폭 예산과 함께 수행됩니다.
실패 격리 : 외부 인그레스에 대한 DDoS 공격이 더 이상 이그레스 대역폭을 소모하지 않습니다(결제 처리기 호출은 여전히 진행됩니다). 내부 외부 호출이 실패하는 것 외에 외부 사이트에 대한 정상적인 접근은 유지됩니다.
다른 SLO : 인그레스 가용성은 사용자에게 중요합니다(외부 사이트 중단이 표시됨); 이그레스 가용성은 운영진에게 중요합니다(배경 실패가 더 오랜 시간 동안 감지될 수 있음). 각 측면은 자신만의 SLO를 가지고 있습니다.
여러 이그레스 서버
이그레스 역할이 독립적인 기계가 되면 다음 명백한 움직임은 여러 이그레스 기계를 로드 밸런서 뒤에 실행하는 것입니다. 각 새로운 내부 서비스는 이그레스 호스트명(로드 밸런스 풀에 대한 해시)을 가리키게 됩니다.
분산 시스템의 일반적인 교훈입니다. 상태가 없는 계층이 있고 자신의 역할이 있는 경우 쉽게 복제될 수 있습니다.
새 파트너 통합
당신의 조직은 인그레스 / 이그레스 분리를 원래 디자인에 따라 실행합니다. 이그레스 서버는 고정된 외부 IP(203.0.113.99)를 가지고 있으며, 이 IP를 결제 처리기, SMS 게이트웨이 및 이메일 제공자와 같은 세 개의 기존 파트너 API에 허용 목록으로 등록했습니다.
제품 팀이 추가할 네 번째 통합: 전 세계 고객 엔드포인트로 호출하는 웹훅 전달 시스템을 원합니다. 예상 트래픽량: 분당 10,000건, 급증 시 30,000건까지.
성장하는 서비스에 대한 네트워크 경계 디자인
통합
너는 인가 및 이그제스가 다른 도구를 필요로 하는 이유, 실질적인 함선 NAT 실패가 실제 부트에 분할을 강요하는 것, 분할이 성공하면 누적되는 독립적인 확장, 보안 격리 및 실패 격리의 이유를 배웠다.
모두 적용
중간 규모의 SaaS 회사가 사용자들을 위해 '앱', 'API', '관리자' 세 가지 제품 하위 도메인을 운영하고 있으며, 추가로 Stripe, Twilio, SendGrid 및 고객 웹훅 시스템을 포함한 네 가지 출입통합이 있습니다. 오늘 모든 것은 한 개의 공인 IP에 위치한 단일 프록시 머신에 있습니다. 그들은 내부 서비스가 api.example.com을 호출할 때 간헐적으로 함선 실패 보고서를 받기 시작했습니다. 영구한 해결책을 디자인하려는 것입니다.
이 과정의 다음 단계
이 과정의 다음 단계
너는 분산 시스템에서 가장 깨끗한 관심사 분리 리팩토링 중 하나를 보았습니다: 하나의 상자가 두 개로 변하고, 각 상자가 명확한 역할을 하며, 시스템이 확장, 보안 및 실패 격리 이점을 누릴 수 있습니다.
다음 강의 (cs_distsys_failure_modes_and_blast_radius) 실패 격리 논리 확장을 수행합니다. 너는 절단 실패 패턴을 식별하고, 시스템 대신 사람을 겨냥하지 않는 비난 없는 행동 사항을 작성할 수 있는 절단 DNS-SERVFAIL 후문을 읽게 됩니다.
동반 학습: geometry_of_ingress_egress_separation은 분리를 이분 그래프로 표현하고, 끊임 없는 꼭짓점, 네트워크 분할 및 그래프 이론이 네트워크 경계에 대해告诉하는 것을 탐구합니다.
잘 했어요. 앞으로 가세요.