クイズ: 同期REST連携

동기 연동에서 연결 타임아웃(connect timeout)을 짧게(1~3초) 잡는 이유는?

• 상대 서버가 죽어 있을 때 우리 스레드가 오래 묶이는 것을 막기 위해
• 네트워크 대역폭을 절약하기 위해
• 응답 데이터 크기를 줄이기 위해
• TLS 핸드셰이크를 생략하기 위해

주문 전송 중 타임아웃이 발생했습니다. 이 상황의 본질적 문제는?

• 회선 대역폭이 모자라 전문이 제때 다 나가지 못했다는 뜻이다
• 상대가 요청을 못 받은 것인지, 처리는 했는데 응답만 유실된 것인지 알 수 없다
• 전송 도중 끊겼으므로 요청 데이터가 손상된 채 도착했을 수 있다
• 연결을 오래 붙들고 있는 사이에 인증 토큰이 만료됐을 가능성이 크다

송신 전에 우리 쪽에서 데이터를 검증해야 하는 실무적 이유로 가장 적절하지 않은 것은?

• 왕복 시간과 재작업이 줄어든다
• 상대 시스템 로그에 우리 오류가 쌓이는 것을 막을 수 있다
• 상대 시스템의 응답 속도가 빨라진다
• 대량 배치에서 수천 건이 한꺼번에 실패하는 것을 예방할 수 있다

연동 로그에 추적 ID(trace_id)를 남기고 요청 헤더로도 함께 보내는 이유는?

• 요청별 식별자가 있으면 중복 로그를 걸러 파일 크기를 줄일 수 있어서
• 장애 때 상대 시스템 로그와 대조해 같은 요청을 찾아내기 위해
• 헤더에 실린 값을 키로 삼아 전문을 암호화·복호화하기 위해
• 같은 추적 ID 가 두 번 오면 수신측이 중복으로 보고 막을 수 있어서

주문 10만 건을 상대 시스템에 전송해야 할 때 동기 REST 를 건별로 쓰면 안 되는 이유는?

• REST 규격이 한 번에 보낼 수 있는 전문 크기를 제한하고 있어서
• 건당 100ms 만 걸려도 수 시간이고, 끊기면 어디까지 처리됐는지 알 수 없어서
• JSON 은 같은 데이터를 담을 때 고정길이 파일보다 훨씬 커지기 때문에
• HTTP 는 연결당 처리량 한계가 있어 대량 전송에는 쓰지 않는 것이 원칙이라서

벌크 API(한 요청에 100건)를 설계할 때 정의서에 반드시 명시해야 하는 것은?

• 요청 헤더의 순서와 필수 헤더 목록을 정확히 맞추는 규칙
• 전문 크기를 줄이기 위한 JSON 들여쓰기와 공백 제거 규칙
• 부분 실패 시 전체를 되돌릴지, 성공분은 살리고 실패분만 돌려줄지
• 지원하는 HTTP 버전과 커넥션 재사용 여부