필수 기능

기능

주요 기능의 흐름도

DB 설계
채점
- 무조건 제공 되어야 하는 기능
  - 먼저 들어온 채점이 먼저 실행
  - 채점 서버의 개수에 상관 없이 되도록 순서를 보장
    - 사실 조금 틀려도… 괜찮지 않나…
    - FIFO 큐를 잘 구현하고 싶다면 해당 부분을 깊게 해봐도 괜찮고 아니라면 대략적인 순서를 보장하는 방향으로 선택 가능
- 구현 방식의 차이
  - REST API로 채점이 마무리될 때 까지 기다렸다가 결과를 반환받아 보여줌
    - 로딩 중… 이라는 것을 사용자가 오래 볼 수 있음
    - 구현상으로는 쉽지만 사실 채점에 장애가 생긴다면 골치아픈 구현이 될 수 있음
      - 이런 장애를 해결하기 위한 과정도 학습 가능할 수도 있긴합니다.
  - 채점 큐에 제출을 쌓아두고 소켓으로 채점 정보를 받아와서 결과를 보여줌
    - 즉각적인 반응과 좋은 사용자 경험을 얻을 수 있음
    - 실시간 처리를 경험할 수 있음
- 부담되면 사실 채점되는 척만 해도 괜찮다.
대회 전용 사이트의 분리
- 대회 전용 사이트는 보통 초반에 트래픽이 급격하게 몰리고 이후 점차 줄어드는 형태를 가짐
- 필요한 상황에 대회 전용 서버를 켜서 사용하고 필요가 없을때에는 서버를 제거하는 방식
  - DB 서버도 따로 만든 다음 대회 종료 이후 한번에 메인 DB로 옮기는 작업을 해도 괜찮으려나…?
  - DB 서버는 딱히 분리하지 않아도 감당이 충분히 되려나…?
  - 굳이 DB를 합쳐야하나…? 대회 제출이랑 일반 제출은 사실 따로 존재해도 상관 없는게 아닌가…?
다양한 데이터의 저장
- 일반적으로 DB에 들어가는 정보
- 이미지 파일 ( 문제에 들어가는 이미지 )
  - AWS S3, Object Storage와 같은 저장소를 이용하자
  - DB에 이미지를 바로 넣는건 안좋아 보인다…
- 텍스트 파일 ( 문제 채점에 필요한 테스트 케이스 )
  - 텍스트 사실 디비에 저장해도 괜찮지 않나..?
  - 가벼운 NoSQL이라면..?
모니터링?
- 채점 서버 모니터링
  - 백엔드가 야무지게 관여할 수 있는 분야라고 생각합니다. 모니터링!
  - 쌓여있는 제출의 개수
  - 현재 동작중인 채점 서버 상태
  - 등등..

ssl 적용
CI/CD
로드밸런싱 → 분산시킬 서버 리스트 → 설정파일 직접 수정 말고 사이트에서 수정하면.. 결국이건.. 설정파일을 수정하는건가..?
docker… 열심히 써보기
aws..
소켓..
프론트 → 채점 요청 → 채점 서버 여러개 누가빨리끝날지, 늦게글날지, http 요청 커넥션 개수로는사실…. 잘 모를 가능성이 높지 않나 해서 채점 중계하는 서버랑 채점 서버들 사이에 소켓으로 다 연결해서 끝날거를 실시간으로 받아서 다음 채점을 소켓으로 보내주는 방식은 어떨
부하 테스트..