동기 통신의 장애 전파 문제를 겪고 설계를 바꾼 경험
저는 통신 설계에서 실패했을 때의 대응을 가장 중요하게 생각합니다. 프로젝트 초반에 서비스 간 호출을 동기로만 구성했는데, 한 서비스가 느려지자 호출한 서비스까지 함께 응답이 지연되는 걸 겪었습니다. 이후 필수적이지 않은 호출은 비동기로 바꾸고, 필수적인 호출에는 타임아웃을 설정해 한 서비스의 문제가 전체로 퍼지지 않도록 했습니다.
면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
저는 통신 설계에서 실패했을 때의 대응을 가장 중요하게 생각합니다. 프로젝트 초반에 서비스 간 호출을 동기로만 구성했는데, 한 서비스가 느려지자 호출한 서비스까지 함께 응답이 지연되는 걸 겪었습니다. 이후 필수적이지 않은 호출은 비동기로 바꾸고, 필수적인 호출에는 타임아웃을 설정해 한 서비스의 문제가 전체로 퍼지지 않도록 했습니다.
규모가 커질수록 서비스 간 호출 경로가 복잡해져서 어디서 문제가 생겼는지 추적하기 어려워진다고 배웠습니다. 저희 프로젝트는 서비스가 세 개뿐이라 크게 체감하진 못했지만, 로그를 요청 단위로 추적할 수 있게 요청마다 고유 식별자를 붙여보는 시도는 해봤습니다. 실제 대규모 환경에서는 이런 추적 체계가 훨씬 더 중요해질 거라고 생각합니다.
서비스마다 API 버전이 달라지면서 한쪽에서 API를 변경했더니 다른 서비스가 갑자기 오류를 내는 일이 있었습니다. 그 이후로는 API 명세를 문서로 미리 공유하고, 변경할 때는 이전 버전과 호환되도록 신경 쓰는 방식으로 바꿨습니다. 완벽하게 지켜지진 않았지만, 최소한 사전에 알리는 절차는 생겼습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.