- 회사에서 사용하는 서버는 모두 aws를 통해 사용하고 있다. 하지만 규모가 크지 않은 스타트업이기에 서버 컴퓨터의 성능 역시 그리 좋은 편은 아니다(물론 회사 서비스에는 큰 상관이 없음). 운영서버의 경우 t3.large를 개발 서버의 경우 t3a.small을 사용하고 있다.
최근 대표님의 요청으로 묶음배송과 관련된 API를 제작하였고 개발 및 운영 서버 모두에 배포를 한 상태이다. 하지만 실제 서버에서 사용 시 이전에도 서버가 다운되는 일들이 많았기에 현재 회사에서 사용하지 않고 있는 워크스테이션에 해당 기능을 첨부할 계획을 수립하고 있다.
Micro 서비스로?
- 사실 어떤 방식으로 이 서비스를 올려야할 지 아직도 결정짓지 못한 상태이며 단순히 생각나는 것은 이전에 정산자동화 메일 시스템과 같이 새로운 컨테이너로 작동을 시키는게 어떨까 라는 생각을 했다. 하지만 정산자동화는 기존의 Docker Swarm 내부에 설치하는 것이고 워크스테이션은 전혀 다른 서버, container를 사용하는 것. 또한 어떤 프레임워크를 사용할지도 감이 오지 않는 상태이다.
장고... 플라스크... 아니면 그냥 파이썬.... 웹통신으로 주고받을꺼라면 당연히 웹 프레임워크를 사용해야하는건가??? 내부적인 통신
http ~ tcp
- 찾아보니깐 http나 tcp는 그 결이 비슷하다고 한다. (tcp 기반에서 만들어진 것이 http) 예전에 떨어진 정처기에서 나온 OSI 7 Layer를 확인
- TCP UDP의 차이
tcp는 연결지향적으로 서버와 클라이언트가 서로 연결되어 있다. 즉 서버와 통신할 준비를 먼저 확인한 뒤 연결해서 데이터를 주고 받는다. 또한 순서 역시 보장된다.반면 udp의 경우 서버에 데이터 보내고 끝! 서버가 죽었는지 살았는지 신경쓰지도 않고 보내고 걍 끝이며 순서도 보장되지 않는다.
Http와 Socket 차이는?
- 정해진 규칙을 가지고 클라이언트의 요청에 대한 정보를 제공하고 연결을 끊을 것인지, 아니면 규칙 없이 영원히 연결을 유지할지 http는 비연결! (조금만 생각하면 당연한 것)
속도 차이
- 당연히 속도는 socket이 http보다 더 빠름.
- socket
게임, 채팅, 동영상 스트리밍에 적합
접속을 계속 유지해야하기에 서버에 연결될 수 있는 클라이언트 숫자가 한정
- Http
단방향 통신 OSI 7계층에서 어플리케이션 계층에 해당하는 프로토콜
클라이언트의 요청이 있을 때만 데이터의 응답을 전달하고 연결을 끊는다
콘텐츠 위주의 데이터를 주고 받을 때 적합하다. 서버로 요청을 보내고 응답을 기다리는 어플리케이션에 적합
///