Websocket proxy가 필요한 케이스가 생겼다. 일반적으로는 독립된 proxy server를 통해 지원하면 되지만, Servlet단에서 지원을 해야 하는 상황이다. 아래의 그림처럼 제공되는 것이 중간의 Gateway를 통해 Communication이 되어야 하는 상황이다.
가장 편하게 할 수 있는 방법은 jetty-proxy library를 이용하는 방법이다.
이미 구현체가 존재하기 때문에, 필요한 부분만 customizing하여 Servlet으로 등록하면 된다.
Cloud Computing의 발전으로 인해 과거와는 달리 더 이상 많은 인력이 필요없게 되는 것 같다. 구글 트렌드에서 “programmer”와 “software engineer”의 검색량을 2004년 부터 현재까지 추출해보았다.
점점 검색량이 줄어들고 있다. 예전에는 리눅스 전문가, DB 전문가, Backend 전문가, Frontend 전문가 등등이 필요했지만, 이제는 적은 인력으로 충분히 해결 가능하다.
이런 현상이 발생한 이유중에 하나는 “Serverless” 일 것이다. (아직 초창기이긴 하지만…) Serverless는 서버가 없다라는 의미가 아니고, 관리해야 할 Server가 0으로 수렴한다는 의미이다.
즉, 서비스 단위의 코드를 개발하고 배포에 집중하겠다라는 기술이라고 볼 수 있다. 이런 점이 기존의 PaaS와 대비되는 특징이다.
다가올 Serverless의 시대에도 예전의 전문가라는 직종이 남아있을지 의문이다.
우리는 어떤 준비를 해야 할까?
MQTT Broker를 선정시 고려할 사항을 정리합니다. MQTT는 서비스 품질(QoS)에 대해서 3가지 레벨의 신뢰성을 제공합니다. 일반적으로는 QoS 0를 선택하고, Application Level에서 처리하고 있습니다.
MQTT 보안에는 크게 Authentication, Authorization 부분과 Network 그리고 Payload 검증 부분으로 나눠집니다.
MQTT Broker를 사용하는 Subscriber의 Backend server가 같은 기능을 갖는 여러대로 구성되는 Case가 존재합니다. 이럴 경우 Subscriber Server 앞단에 HAProxy를 이용해서 한대의 서버만 message를 받도록 할 것인지, 아니면 Broker에서 제공하는 Exclusive 기능을 이용할 것인지 고려해야 합니다.
그 외에, Integration 부분도 고려해야 합니다.