고수님들께 질문이 있습니당.~ㅠ Client(Socket.IO) EC2(Spring) 으로 Notification을 만들었는데. 현재는 EC2가…

고수님들께 질문이 있습니당.~ㅠ

Client(Socket.IO)<-> EC2(Spring) 으로 Notification을 만들었는데.

현재는 EC2가 한대라서 Public DNS (ec2-XX-XX-XX-XX.ap-northeast-1.compute.amazonaws.com)

으로 연결하면 커넥션이 잘 이루어 지는데요

나중에 확장성을 생각해서 ELB쪽으로 연결을 해야 하는데, 커넥션이 안되더라구요.ㅠ

이런 경우 ELB로 커넥션을 하면 자동으로 실제 EC2로 분기 하려면 어떤 세팅방법을 참고 하면 될까요?ㅠ.ㅠ

Client(Socket.IO)에서 EC2를 갯수 만큼 배열에 놓고 랜덤으로 접속하게 하는 방법은 지양 하려구요. 너무 하드코딩 하는방식이고
Auto 스케일링 할때도 문제가 있을것 같아서..

고수님들의 답변 기다리겠습니당.ㅠ.ㅠ

5 thoughts on “고수님들께 질문이 있습니당.~ㅠ Client(Socket.IO) EC2(Spring) 으로 Notification을 만들었는데. 현재는 EC2가…

  1. 태호님이 말씀하신 내용을 힌트삼아서 일단 ELB의 HTTP 대신 TCP 리스너로 변경하여, 접속 및 통신되는것을 확인했습니다.

  2. 아래와 같이 2가지 단점과 , 다른 방안을 제시하고 있는데.. 무슨 얘기를 하는 걸까요?ㅠ
    ========================================================
    I confirm, based on our own tests, that configuring ELB on TCP/SSL, instead oh HTTP/HTTPS, makes the trick with WebSockets. The drawbacks are two:

    1) As already pointed by arturnt, you cannot get stickyness.

    2) You will lose the ability to retrieve the identity of the clients. The originating IP seen by your WebSocket server will be always the ELB one and, differently from the HTTP/HTTPS configuration, no X-Forwarded-For header will be added to the requests.

    **UPDATE on July 2013: Amazon has just added support for Proxy Protocol, which solves drawback number 2 above. With the Proxy Protocol, a header containing the client’s originating IP is added even when ELB works at TCP level, rather than HTTP.

  3. 이때의 stickyness 는, a유저가 1번 서버로 붙었고 이후에도 계속 1번으로 붙어야 하는 필요가 있을 때, 단순 elb의 사용만으로는 불가능하다는 말 같습니다.
    하지만 프록시 프로토콜을 사용하여 tcp 레벨의 stickable 한 커넥션을 할 수 있게 되었다네요. 기능의 가부만 따지자면 별 걱정안하고 사용하셔도 되지 않을까요?

  4. 저는 막상 tcp로 설정하고 실험을 해보니 stickyness가 보장되지 않았습니다;;; 혹시 되시는 분 있나요? 전 spdy용으로 tcp 443으로 설정했었습니다.

Comments are closed.