견적 요청의 실제 목적지 추적하기

소개

PARCEL은 가상의 선물 가게입니다. 방문자는 Arc lamp 또는 Clay vase를 살펴보고 배송과 수령을 비교합니다. 수령 견적은 이미 반환되지만 배송은 실패합니다. 새로 실패한 요청을 진입점부터 실제 응답한 서비스까지 추적한 뒤, 수령 기능을 해치지 않고 정확한 배송 가격을 복구하세요.

기본 터미널 사용 능력이면 충분합니다. 짧은 Nginx 설정 파일 두 개를 편집하고 실제 로그를 읽으며 실제 응답을 테스트합니다. 애플리케이션 코딩, SDK, 외부 계정, 구매, 개인 정보는 필요하지 않습니다. 모든 서비스는 하나의 준비된 훈련 인스턴스에서 실행됩니다. 이는 요청 상관관계 학습이며 완전한 분산 추적 플랫폼은 아닙니다.

Website에서 사이트를 보고 견적을 요청합니다. 모든 명령은 Workstation에서 실행하며 시작 위치는 /home/labex/project/parcel입니다. 각 단원은 독립 환경을 가집니다. 포트 8081의 진입점은 각 견적 요청을 백엔드 하나로 전달합니다. 배송 서비스는 8091, 수령 서비스는 8092에서 수신합니다. 포트는 네트워크 서비스를 식별하며 Workstation에서 127.0.0.1은 이 실습 인스턴스를 뜻합니다.

새 요청에 공통 참조 번호 부여하기

이 단계에서는 정상 고객 흐름을 살펴보고 실패를 관찰한 뒤 새 요청을 두 실제 로그에 연결합니다. Website에서 시작하세요.

가게 살펴보기

Two good things 아래의 Arc lamp를 엽니다. 상세 페이지에 $48와 로컬 그림이 표시됩니다. Estimate collection을 선택하고 Arc lamp, Near를 유지한 채 Get estimate를 클릭합니다. $2.00와 HTTP 200이 나와야 합니다. 유지해야 할 정상 기능입니다. PARCEL↗로 홈에 돌아와 Delivery를 열고 Get estimate를 클릭하면 Estimate unavailable, HTTP 404가 표시됩니다.

HTTP는 브라우저의 요청/응답 프로토콜입니다. 200은 성공 응답, 404는 요청을 받은 서비스가 해당 경로를 찾지 못했다는 뜻입니다. 연결 오류는 다릅니다. 사용할 수 있는 서버 응답을 받지 못한 상태입니다. 현재 참조 번호는 not available이므로 고객 응답과 서비스 로그를 쉽게 연결할 수 없습니다.

증거 이해하기

준비된 진입점 로그는 Nginx가 요청마다 생성하는 식별자를 이미 기록합니다. 백엔드는 전달된 식별자를 기록할 수 있습니다. 둘을 연결하면 하나의 실패 요청에 다음 형태의 기록이 생깁니다. 점은 자신의 식별자를 뜻합니다.

entry:    {"id":"...","path":"/api/delivery","status":404,"upstream":"127.0.0.1:8091","upstream_status":"404"}
delivery: {"service":"delivery","id":"...","path":"/v1/shipping","status":404}

진입점 경로는 브라우저가 요청한 경로이고 백엔드 경로는 진입점이 실제 전달한 경로입니다. upstream은 접속한 백엔드 주소, upstream_status는 실제 응답 상태입니다. 같은 식별자가 두 관찰을 연결합니다. 요청이 많을 때 시간만 비교하는 방법은 덜 확실합니다. 요청 본문이나 비밀 정보는 기록하지 않습니다.

식별자 연결하기

Workstation으로 전환합니다. pwd는 현재 디렉터리를, cat은 파일 내용을 출력합니다.

pwd

/home/labex/project/parcel이 나와야 합니다. 다른 곳으로 이동했다면 cd /home/labex/project/parcel을 실행하세요. cd는 현재 디렉터리를 바꿉니다. correlation.conf처럼 /로 시작하지 않는 경로는 이 디렉터리를 기준으로 합니다.

cat correlation.conf

현재 파일에는 주석만 있습니다. Nginx는 준비된 진입점 서버입니다. 설정은 세미콜론으로 끝나는 지시문으로 구성됩니다. 주 서버 설정이 이 작은 파일을 포함하므로 주 설정 골격을 편집하지 않습니다.

헤더는 HTTP 요청이나 응답과 함께 전달되는 이름 있는 값입니다. proxy_set_header는 백엔드로 보낼 헤더를 설정하고 add_header는 고객 응답에 추가합니다. $request_id는 Nginx가 이 요청에 생성한 값입니다. always는 성공뿐 아니라 실패 응답에도 헤더를 포함합니다. 여기서는 공통 이름 X-Request-ID를 사용합니다. 진입점은 방문자의 값을 신뢰하지 않고 자체 식별자를 만듭니다.

cat > correlation.conf는 here-document로 파일을 교체합니다. 마지막 CONF가 혼자 있는 줄까지 블록 전체를 붙여 넣으세요. 'CONF'의 따옴표는 $request_id를 그대로 보존하여 셸이 아닌 Nginx가 해석하도록 합니다.

cat > correlation.conf <<'CONF'
proxy_set_header X-Request-ID $request_id;
add_header X-Request-ID $request_id always;
CONF

저장한 내용을 읽고 제공된 도우미로 적용합니다. bash는 이 셸 스크립트를 실행합니다. 먼저 문법을 검사하고 유효한 경우에만 Nginx를 다시 로드합니다. 경로를 고치거나 가격을 판정하지는 않습니다.

cat correlation.conf

bash reload.sh

설정 검사 성공과 **Configuration accepted. Send a new request to test it.**가 나와야 합니다. 줄 오류가 나오면 철자, 세미콜론, 문자 그대로의 달러 기호를 코드와 비교하고 파일을 다시 작성한 뒤 재시도합니다. 문법 검사가 실패하면 이전 설정이 계속 서비스를 제공합니다. 다시 로드해도 과거 응답은 바뀌지 않으므로 새 요청을 보내야 합니다.

자신의 새 실패 요청 추적하기

Website의 Delivery에서 Get estimate를 다시 클릭합니다. 여전히 실패하지만 Request reference에 32자리 16진수가 표시됩니다. 이 새 값을 정확히 복사하세요. 위 예시의 점이나 스크린샷의 식별자는 사용하지 마세요.

Workstation으로 돌아옵니다. 셸 변수는 나중 명령에서 사용할 값을 저장합니다. 아래의 PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE를 Website에서 복사한 정확한 새 참조 번호로 바꿉니다. 작은따옴표를 유지하고 = 주위에 공백을 넣지 마세요. 따옴표는 값을 그대로 유지합니다. 자리표시자를 바꾸지 않은 채 실행하지 마세요.

REQUEST_ID='PASTE_YOUR_NEW_REQUEST_REFERENCE_HERE'

grep은 일치하는 줄을 출력합니다. -F는 값을 일반 텍스트로 처리하며 큰따옴표는 변수 값을 하나로 유지합니다. 다음 절대 경로는 어느 디렉터리에서도 사용할 수 있습니다.

grep -F "$REQUEST_ID" /var/log/parcel/entry.jsonl

grep -F "$REQUEST_ID" /var/log/parcel/delivery.jsonl

두 기록에 정확히 같은 식별자, 백엔드 경로 /v1/shipping, 상태 404가 있어야 합니다. 배송 요청이 응답하는 백엔드에 도착했음을 증명합니다. 서비스가 멈췄거나 연결이 없는 상황이 아닙니다. 출력이 비면 오래된 번호나 오타인 경우가 많습니다. Website에서 다시 요청하고 새 값을 복사하여 REQUEST_ID를 다시 설정하세요. 응답 헤더만 활성화하면 백엔드 식별자는 여전히 -이므로 두 지시문이 모두 필요합니다.

이 단계의 검사는 새 읽기 전용 요청으로 연결을 확인합니다. 특정 셸 변수, 명령 기록, 복사한 로그 파일은 요구하지 않습니다.

경로를 복구하고 두 견적 유지하기

이 단계에서는 두 로그 기록과 서비스 계약으로 배송을 수정합니다. Workstation에서 시작하세요.

주소와 경로 구분하기

cat으로 라우팅 설정을 읽습니다.

cat routes.conf

location = 블록은 공개 경로 하나와 정확히 일치하며 중괄호는 지시문을 묶습니다. proxy_pass는 Nginx에 전달 대상을 알려 줍니다. http://127.0.0.1:8091/v1/shipping에서 주소와 포트는 서비스를, /v1/shipping은 서비스의 작업을 선택합니다. 어느 부분이든 잘못될 수 있습니다. 이 정확 일치 location에서는 설정한 백엔드 경로가 일치한 공개 경로를 대체하고 쿼리 옵션은 계속 전달됩니다.

준비된 서비스의 계약은 다음과 같습니다.

두 서비스 모두 /health에 응답하지만 정상 상태가 올바른 라우팅을 증명하지는 않습니다. 로그에서는 배송이 8091의 /v1/shipping에 도착했습니다. 배송 담당 서비스이지만 그 경로는 제공하지 않습니다. 계약은 /v1/delivery를 요구합니다. 수령은 주소와 경로가 이미 올바릅니다.

작은 수정 적용하기

수령을 유지하면서 편집 가능한 경로 파일만 교체합니다.

cat > routes.conf <<'CONF'
location = /api/delivery {
    proxy_pass http://127.0.0.1:8091/v1/delivery;
}
location = /api/collection {
    proxy_pass http://127.0.0.1:8092/v1/collection;
}
CONF

bash reload.sh

문법 검사가 실패하면 중괄호와 세미콜론을 비교하고 파일을 다시 작성해 재시도합니다. 준비된 백엔드, 웹사이트, 로그, 주 서버 설정을 편집하지 마세요. 실제 올바른 견적 없이 200만 반환하면 결함을 숨기는 것입니다.

실제 가격과 연결 테스트하기

Website에서 Delivery를 열고 Arc lamp / Near를 다시 요청합니다. $6.00, HTTP 200, 새 참조 번호가 보여야 합니다. Clay vase / Far를 요청하면 $13.00입니다. Collection에서 Arc lamp / Near는 여전히 $2.00, Clay vase / Far는 $4.00여야 합니다. 클릭마다 새 요청이므로 참조 번호도 달라야 합니다. PARCEL↗로 돌아간 상품 페이지에서도 그림과 가격이 정상이어야 합니다.

Workstation으로 돌아옵니다. curl은 HTTP 요청을 보냅니다. -sS는 진행 상황을 숨기고 연결 오류를 표시하며 -i는 응답 헤더를 포함합니다. 작은따옴표는 &를 URL 안에 유지하여 셸이 해석하지 못하게 합니다. ? 뒤의 쿼리 옵션은 상품과 거리를 선택합니다.

curl -sS -i 'http://127.0.0.1:8081/api/delivery?item=vase&zone=far'

HTTP/1.1 200 OK, X-Request-ID 헤더와 함께 "service": "delivery", "amount": 13, "currency": "USD"가 포함된 JSON이 나와야 합니다. JSON은 이름 있는 값의 텍스트 형식입니다. 본문의 request_id는 헤더 값과 같아야 합니다. 헤더 이름의 대소문자가 달라도 의미는 같습니다.

이 응답의 참조 번호로 REQUEST_ID를 다시 설정하고 1단계의 두 grep -F 명령을 반복합니다. 두 로그 모두 200이며 delivery 로그의 경로는 /v1/delivery입니다. 과거 404 기록은 유용한 이력이므로 지우거나 다시 쓰지 마세요.

유지한 기능도 별도로 확인합니다.

curl -sS -i 'http://127.0.0.1:8081/api/collection?item=lamp&zone=near'

200, "service": "collection", "amount": 2가 나와야 합니다. 404도 일반 HTTP 응답이므로 HTTP 오류 상태에서 실패하도록 지정하지 않은 curl은 정상 종료할 수 있습니다. 연결 오류라면 프로세스 불가나 주소 오류를 의심해야 합니다. 위 경로 증거와 혼동하지 말고 마지막 정상 설정을 확인하세요.

최종 검사는 두 작업의 모든 상품/거리 조합을 요청하고 새 식별자를 실제 서비스 로그와 연결하며 전체 고객 사이트를 테스트합니다. 정상 접근 로그만 추가됩니다. 채점은 설정을 다시 로드하거나 파일을 다시 쓰거나 주문을 생성하지 않습니다.

요약

하나의 생성된 참조 번호로 새 요청의 진입점과 백엔드 로그를 연결하고, 응답하는 서비스의 경로 부재와 연결 실패를 구별하여 실제 경로를 수정했습니다. 다양한 비즈니스 결과를 테스트하며 수령 기능도 유지했습니다. 독립 챌린지에서는 같은 주소/경로 및 연결 방법으로 요청을 받는 서비스의 차이를 다룹니다.