들어가기 전

• 시니어가 배우는 속도와 우리가 배우는 속도가 다른 이유는 지금 나와있는 기술은 아저씨들이 이미 해왔던 기술이니까 익숙한데 우리들은 그렇지 않음. 레거시 코드들을 직접 봐야 이해가 되는 상황이니깐.

• 구글을 검색창에 쳤을 때.

  1. DNS에 요청해서(DNS는 통신사가 관리함) 해당하는 IP를 받는다.

     DNS에서 못찾으면 다른 DNS에서 찾아본다.

     실제로 DNS에 IP를 바꾸려고 하면 며칠이 걸린다.

  2. IP를 통해 HTTP 프로토콜을 사용해서 HTTP 요청 메시지를 만들고 TCP 프로토콜을 사용해서 해당 IP의 서버에 요청함

• WEB VS WAS (Web Application Server)

  • http// .. ../java/subject.html을 입력했을 때(단순히 html 파일 가져오기)

    • 클라이언트가 (apache, nginx…)웹서버에 request를 보낸다.
    • 웹서버는 슬래시, 슬래시 거쳐서 subject.html 위치까지 간다.(web server는 그냥 request 주는애)
      • 여기서 WAS의 등장 배경은 페이지를 그냥 만들어놓고 주는게 아니라 동적으로 주기전에 만들어주자는 매커니즘이 생겼기 때문.
    • view에서 (JSON, HTML) 보내줌

  • WAS 진화과정

    1. WAS(Java, Python) 안에 Web Server와 Web Container 두개가 있었다.
    2. WAS가 Web Server와 분리되었다.
       • 복잡성에 문제가 생겼다.
    3. 때문에 WAS는 MVC Framework로 만들어졌다.
       • http// .. ../java/subject을 입력했을 때(MVC Framework로 동작시키기)
         • → 이걸 Restful하다라고 표현.
       • 웹서버는 요청이 들어왔을 때 도큐먼드로 가는지 프레임워크가 들어간 하드위치로 가는지 정한다.

  • 유저가 서버에 요청했을 때.

    • 웹서버가 받고 웹 콘테이너로 전달
    • (java는 인터프리터처럼 동작하지 않기 때문에 tomcat을 통해서 동작함)
    • 그래서 DB에서 가져오는 데이터를 웹컨테이너(JSP, Servlet같은 다이내믹 프로새싱을 함)에 전달

  • 비즈니스 모델을 굉장히 많이 쌓았을 때

    • 리팩토링: 레이어드 아키텍처 기반으로 비즈니스 모델안에서 라이브러리를 때내는(레이어분리) 일을 하는것. 그래서 일정수준 코드가 많이 생길때까지 리펙토링을 하지 말라는 것이다.

    • 리펙토링하기 전은 우리가 시퀀스와 마이크로 함수를 굉장히 많이 냈을 때인데

    • 리펙토링 한 후에는 비즈니스 모델에 세줄 이상 나오지 않는다.

  • 근데 키오스크, 자동차 프로그램 등 불특정 다수의 기기가 라우터에 들어가게 됨.

    • → 뒷단에 처리할게 많아짐

    • 그래서

      • 캐시라는 서버를 따로 두었다. CDN이라고 불림.
      • middleware도 사용한다.
        - 서버 뒷단에 middleware(Go)가 굉장히 많은데 이게 필터링을 어떻게 해야하나, 서버가 죽었는지 어떻게 해야하는가에서 파생된 서버들이다.

    • 서버 사이에 구간이 많은데 연결이 되는 지점에서 항상 에러가 나타난다. 저 구간마다 에러를 어떻게 해결해야하는가를 필드에서 가장 많이 고민한다.

      • 예: 은행에 동시에 100만원을 요청하면 한놈만 줘야한다.그러면 어떻게 해야하는가.
        • → 트랜젝션
          • 트렌젝션은 작업의 안정성을 보장해주는것.
          • 때문에 하나의 인출만 작동하도록 로직을 짜야한다.
          • 그렇다면 데드락을 관리해야한다.
            • 데드락을 어떻게 관리할까..

💡 이호준 멘토 어록

• 사람이 죽을 지언정 서버는 살려야하고 서버가 죽을지언정 로그를 남겨야하고 개발자는 죽지않는 서버를 만들어내야한다.
• 디자인패턴을 내가 내 코드를 적용할 수 없다는걸 알았을때가 내가 디자인패턴을 가장 잘 알때이다.
• 아무리 해도 개발로 풀 수 없는 문제를 발견했을 때가 가장 개발을 잘할 때이다.

• 변화(추가)가 생길 때 가장 해서는 안될 일 : 에디터만 보고 코드 먼저 수정하기
  • 내 편의를 위해 코드만 변경을 해놓으면 어떤 비즈니스 로직을 추가할 때마다 지뢰처럼 작동한다.
  • 시퀀스부터 건드리자.

API 정의 문서

개발이 진행되기 전에 이문서가 나왔으면 서버에 요청하면 이런게 나와야 한다.
아무리 뒷단에서 뭐가 바뀌던 저런 결과가 나온다.
왜 이제껏 프론트, 백 같이 협업했을 때 잘안된 이유는 이렇게 프로토콜,
즉 보내는걸 정의 안해놓고 개발하니까 그렇다.

💡 어제 벤치마킹할 때 프론트에 줘야할 것을 정의했는데 그게 이 API 정의 문서라고 보면된다.

시퀀스는 모델에 모여있어야한다. 한 시퀀스에 두개가 있어야한다.

Task

• 이어서 API 정의 문서와 서버 하나의 시퀀스 다이어그램 만들기

ERD

어제까지 정했던 ERD이다.

우리는 Global AD Management Platform Server의 시퀀스 다이어그램과 API 정의 문서를 작성할 예정이다.

Sequence Diagram

• Global AD Management Platform Server의 시퀀스 다이어그램

→ 광고 CRUD

→ 광고주에게 해당 광고 Report 생성 후 제공

API 정의 문서(Global AD Management Platform Server)

• 고민했던 점: 멘토님께 피드백을 받았는데 ERD 작성 부문에서 문제가 있음을 알게 되었다.

  

  • Log Data는 유저에게 제공하는 데이터도 아니고(유저한테 제공된다면 History Data가 맞는 단어) 집계를 해서 광고주에게 보여주거나 서비스 개선에 사용하는 데이터다. 때문에 이 테이블에 인덱싱(PK)을 해버린다면 데이터를 삽입할 때 해당 위치를 찾는 O(logn) 시간복잡도가 일어나기 때문에 시간이 오래걸린다.
  • 해결방법으로 PK를 삭제하면 된다. 데이터베이스는 무조건 키를 가져야한다고 생각했지만 그렇지 않아도 된다는걸 알게되었다.