10 29 그룹 회의

설계 점검(1차)

설계의 문제점 발견
- DNS 서버에서 IP 요청 후 브라우저 혹은 재귀적 DNS에 캐싱되어 TTL 도달 전 까지 추가적인 트래픽이 발생하지 않음
- 트래픽, 요청 URL에 대한 로그 수집이 불가능해짐 (TTL마다 트래픽이 발생하기 때문에 실시간 로그 수집 불가능)
프록시 서버의 필요성
- 네임 서버에서 수집할 수 있는 데이터가 매우 한정적임(위에 설명했듯이 캐싱 문제 때문에)
- 로그 수집을 하기 위해서는 유저 → Client 서버의 요청-응답의 중간 계층이 필요함
문제 해결 방안
- 유저 → Client 사이에 역방향 프록시 서버를 두자!
- 네임 서버에서 클라이언트 서버의 IP를 응답하지 않고 프록시 서버의 IP를 반환
- 유저 요청은 프록시 서버로 오게 되고 여기서 로그를 수집 → 유저 요청의 Host 헤더의 도메인 네임을 기반으로 클라이언트 서버에 라우팅
또 다른 문제점 (고민해야할 문제점
- 아웃 바운드 트래픽이 2번 발생하게 됨 (클라이언트 → 프록시, 프록시 → 유저)
  - 추가적인 네트워크 비용이 발생하게 되며 여러 클라이언트가 서비스를 이용할 경우 부담이 클 것
  - 이 정도의 trade-off는 감내할만한 수준인가?

네임 서버 (AWS EC2 인스턴스)
네임 서버의 도메인과 클라이언트 서버의 도메인
- 네임 서버 - watchducks-ns.site
- 클라이언트 서버 - watchducks-test.shop, watchducks-test.store
클라이언트 서버의 네임 서버 등록
실제 동작 여부 (DNS 요청에 대한 응답으로 A레코드 IP 주소인 192.0.0.1을 반환해야함)
dig 커맨드로 [watchducks-test.shop](http://watchducks-test.shop) 도메인으로 DNS 서버에 요청한 결과
네임 서버의 콘솔 로그
간단히 구상만 해봤는데 예상외로 성공적이어서 놀랐다!
DNS 등록 비용이 3000원 발생했다

렌딩 페이지
- 전체/일간/주간 팀별 트래픽 (막대 그래프)
팀 등록 페이지
보여줄 데이터 (팀 별)
- 요청당 성공률 (도넛 차트) - 실패기준 500
- 분/시간/일/주당 트래픽 (라인 차트)
- 최근 5일 DAU (막대 그래프)
- 상위3개 경로에 대한 평균응답시간 (막대그래프) + 응답시간별 색상 변화
오리 모드
- 노랑 파랑 색상으로 (토글 버튼)