과목 데이터의 정합성을 맞춘다.

[3Juhwan]

현재 문제점

현재 방식

• 크롤링한 과목 전체 데이터를 최초 1회 json 형태로 만든다.
• Nginx는 과목 데이터 json을 gzip 압축하여 클라이언트에게 제공한다.

문제점

• 수강신청 기간에 과목 데이터에 변경이 있다. (교수자 추가, 폐강, 신규 개설 등)
• DB에 과목 데이터가 변경되지만, 클라이언트에 제공하는 압축 파일은 변경되지 않고 정합성이 깨진다.
• 수강신청 기간 동안 매일(자정/오전 9시)에 과목 데이터 크롤링 및 수정이 필요하다.
• 인프라가 개선되면 Nginx가 삭제된다.

개선 방안

1. 압축 파일의 버전 관리 + 캐시 무효화 (CloudFront + S3)

구조

• 과목 데이터를 JSON으로 S3에 업로드하고 gzip 압축
• 파일명에 버전 또는 해시를 붙임 → 예: subjects-2024-spring-v3.json.gz
• 클라이언트는 백엔드에서 현재 과목 데이터 버전을 먼저 조회한 뒤, 해당 버전의 정적 파일을 CloudFront에서 다운로드

핵심 아이디어

• 백엔드에서 버전을 관리하고 클라이언트에 알려주면,
• 클라이언트는 항상 정확한 버전의 정적 데이터만 요청하게 됨
• 이후 정합성이 필요한 경우, 백엔드는 "현재 최신 버전은 v4야"라고 알려줌

장점

• S3/CloudFront TTL 무시하고 새 버전 푸시 가능

2. Lambda@Edge 또는 CloudFront Function으로 캐시 무효화 제어

구조

• 정적 gzip 파일을 CloudFront에서 캐시
• 수강신청 중 변경이 발생하면,
  • 백엔드가 S3 업로드 + CloudFront 캐시 무효화 API 호출
  • 또는 CloudFront Function을 통해 If-Modified-Since / ETag 기반 요청 처리

[hyunwoo0081]

S3 를 많이 써본게 아니라, 자세하게 코멘트 달지 못하지만 함 달아보겠습니다.

1. 찾아보니 s3 에 버전 관리 기능이 있다고 합니다. 다만, 프리티어에서 요금이 나오는지는 더 찾아봐야 할 것 같아요.
2. 백엔드 baskets version api 요청 -> baskets.json 요청 순으로 이루어지기 때문에 baskets version api 응답 시간에 의존적일 것 같습니다. 추후에 속도 면에서 한 번 테스트를 해보면 좋을 것 같습니다.

추가 의견

• baskets json 에 과목이 폐강되었는지 여부도 같이 넣으면 좋을 것 같아요.

[Songhyejeong]

과목 데이터를 버전으로 관리하는 방법 좋은 것 같습니당
버전관리는 주기적으로 매일 9시마다 진행, 이후 서비스 운영 중 추가적인 변경이 일어날 경우에는 캐시 무효화를 통해서 정합성을 관리하는 흐름으로 이해하는 것이 맞을까요?

또 궁금한 점이 있숩니다. 과목 데이터의 정합성이 맞지 않아서 생겼던 문제가 사용자에게 변경된 데이터를 주지 않아 신뢰성이 떨어졌다 정도로 파악이 되는데 지난번에 이 문제로 서비스를 잠시 중단했다고 들은 기억이 있어서, 이외의 다른 문제가 있었다면 더 자세한 예시를 알 수 있을까요?

그리고 캐시 무효화의 개념을 처음 접해서 정확하지 않을 수 있을 거 같지만 두 가지 방법의 장단점을 한 번 찾아봤어요.

• 백엔드가 S3 업로드 + CloudFront 캐시 무효화 API 호출

데이터가 변경되는 시점에 캐시 무효화하므로 정합성을 유지하는데에 좋을 것 같다고 생각해요.

• 또는 CloudFront Function을 통해 If-Modified-Since / ETag 기반 요청 처리

이 방법은 1초 미만 단위로 캐시 조정이 불가능하고, 스페이스, 주석과 같이 데이터에 큰 영향이 없는 변경이 있을 경우에도 캐시를 유지하고 싶을 수 있다와 같은 특징이 있었어요.
따라서 과목 데이터의 경우에 변경된 데이터를 반영할 때 실시간성을 고려해야 할지에 따라서 달라질 것 같아요.

[3Juhwan]

@hyunwoo0081

찾아보니 s3 에 버전 관리 기능이 있다고 합니다. 다만, 프리티어에서 요금이 나오는지는 더 찾아봐야 할 것 같아요.

s3 버전 관리 기능을 써본지 좀 돼서 기억이 가물가물하지만, 유용한지는 잘 모르겠어요. git처럼 형상관리를 해준다고 알고 있는데, 파일 네이밍으로 버전 관리하는 게 간편하고 직관적이었던 것 같아서요. 형상관리했을 때, 알게 모르게 용량을 많이 차지했던 기억도 있어요. 위 내용이 정확하진 않지만 s3가 제공하는 기능이 다양하면서 복잡하지 않아서 도입하게 됐을 때 알아보면 좋겠어요.

추가로 아래는 프리티어 S3 요금입니다! 아래 기준을 넘칠 것 같지 않아서 비용 걱정은 안해도 되겠습니다.

• 매달 5GB의 Amazon S3 스토리지(S3 Standard 스토리지 클래스)
• 매달 2만 건의 GET 요청
• 매달 2,000건의 PUT, COPY, POST 또는 LIST 요청
• 매달 100GB의 데이터 송신

출처: aws 문서

백엔드 baskets version api 요청 -> baskets.json 요청 순으로 이루어지기 때문에 baskets version api 응답 시간에 의존적일 것 같습니다. 추후에 속도 면에서 한 번 테스트를 해보면 좋을 것 같습니다.

혹시 subjects를 baskets으로 잘못 말씀한 걸까요?? baskets을 의도한거라면 제가 잘 이해하지 못했네요.
subjects를 의도했다면, 모든 과목 데이터를 크롤링해오는 응답 시간에 의존적이라는 걸로 이해했어요. 이게 생각보다 오래 걸려요. 10초 이내로 걸리는데, 크롤링하고 압축하여 s3로 올리는 과정에서 문제가 있을 수도 있겠어요!

baskets json 에 과목이 폐강되었는지 여부도 같이 넣으면 좋을 것 같아요.

아예 삭제할 생각을 하고 있었는데, 삭제 대신에 폐강 여부를 넣으면 좋겠네요 👍
추가로 기존에 교수가 배정되지 않었는데 배정된 경우에도, 어떠한 표시를 하면 좋을까요? 사용자에게 교수가 배정되었다는 걸 알리면 어떨까 합니다!

[3Juhwan]

@Songhyejeong

버전관리는 주기적으로 매일 9시마다 진행, 이후 서비스 운영 중 추가적인 변경이 일어날 경우에는 캐시 무효화를 통해서 정합성을 관리하는 흐름으로 이해하는 것이 맞을까요?

정확해요 💯 제가 좀더 친절히 코멘트 달껄 그랬네요.
매일 9시에 전체 과목을 크롤링하고 변경된 게 있다면 반영하여 새로운 버전을 s3에 업로드 하는 거예요! 그리고 캐시 무효화로 클라이언트가 새로운 버전을 가져가는 것이지요.

매일 9시로 설정한 이유는, 직원들이 출근해서 수강신청 전에 과목을 업데이트하는 상황을 생각했어요. 직원들이 과목을 업데이트 하는 시점을 확실히 알 수가 없어서, 오전 9시 외 다른 시간에도 크롤링할 수도 있겠어요. 이 정책은 추후 결정하면 되겠어요

또 궁금한 점이 있숩니다. 과목 데이터의 정합성이 맞지 않아서 생겼던 문제가 사용자에게 변경된 데이터를 주지 않아 신뢰성이 떨어졌다 정도로 파악이 되는데 지난번에 이 문제로 서비스를 잠시 중단했다고 들은 기억이 있어서, 이외의 다른 문제가 있었다면 더 자세한 예시를 알 수 있을까요?

지난 하계 수강신청 첫 날에 있던 일을 말씀하신 것 같아요. 그때 문제는 제가 프론트에 전달했던 Subjects.json과 개발 DB에 저장되어 있던 subjects 테이블의 데이터의 정합성이 맞지 않았어요. 근데 운영 DB랑은 Subjects.json이 맞는 상황이었어요. 구체적으로 정합성이 맞지 않았던 이유는, subject_id가 달랐기 때문인데요. 아래 그림이 이해하는 데에 도움이 되면 좋겠네요 😀

운영 DB의 subjects 테이블에서는 지난 1학기 과목도 포함되었기 때문에 하계 수강신청의 subject_id가 1에서 시작하지 않고 2423부터 시작했어요. 제가 전달한 Subjects.json도 2423번 과목부터 있을거예요. 하지만 개발 DB는 지난 1학기 과목이 존재하지 않았기에 subject_id가 1번부터 시작했어요.

dev.allcll.kr에서 클라이언트가 2423번부터 시작하는 과목 데이터를 사용하지만, 개발 DB에는 1번부터 시작하는 과목 데이터를 사용하기에 클라이언트가 2423번 과목과 관련된 api call이 발생해도 개발 DB는 응답할 수 없었어요. (사실 운영 DB는 문제가 없어서 서비스할 수 있었지만, 개발 서버에서 버그가 있기에 서비스하지 않았죠)

실제로 GET pins api는 500을 응답했고, 사용자가 보는 페이지에는 과목명, 학수정보 등에서 undefined가 보였어요. 아래와 같았던 걸로 기억해요.

백엔드가 server-sent event로 여석은 전송하는데, 백엔드가 전달한 여석의 subject_id가 클라이언트(Subject.json)에 없기 때문에 위처럼 보였던 걸로 추정해요.

@hyunwoo0081 @boyekim @Songhyejeong
백엔드가 전달한 여석의 subject_id가 클라이언트쪽에서 갖고 있지 않을 때, 그 여석 정보를 보여줄 것인지 숨길 것인지 고민이 필요하겠어요.