여기 분들은 도저히 알아들을 수 없는 얘기들만 하시는데… 허접한 회사의…

여기 분들은 도저히 알아들을 수 없는 얘기들만 하시는데…
허접한 회사의 허접한 실무자가 허접한 질문 하나 드립니다.

현재 API 를 통해 운영되는 서비스가 하나 있습니다.
클라이언트가 리퀘스트() 호출 후 그 결과값을 응답받아야 하는데
그 사이 텀이 상당히 깁니다. 짧게는 몇분에서 길게는 며칠까지.

* 클라이언트
– 현재 1만개 정도
– 사용언어: VB, C#, C++, 자바 등등 다양
* AS-IS
– REST 방식 사용
– 리퀘스트() 후 결과값이 나올 때까지 결과체크() 주기적으로 호출
– 결과체크() 호출을 무한반복한다거나 하는 실수가 잦아 서버 과부하
– 결과체크() 주기를 짧게 잡는 경향들이 있어서 리퀘스트가 점점 많아짐
– 클라이언트들이 리얼타임 응답을 계속 요구함
* TO-BE
– 다양한 언어에서 사용할 수 있는 보편적 기술 사용
– 리얼타임으로 결과값 응답 혹은 푸쉬
– 가급적 서버는 리눅스로 하고 싶지만 윈도우라도 무방
– 클라이언트가 더 늘어날 예정이므로 확장성도 고려

서버자원, 인력 및 시간 투자를 최소화하면서
TO-BE 에 다다를 수 있는 효율적인 방식이 뭐가 있을까요?
도와주세요 뽀빠이 ㅠㅠ

14 thoughts on “여기 분들은 도저히 알아들을 수 없는 얘기들만 하시는데… 허접한 회사의…

  1. 부끄럽습니다만.. 저는 시스템 구성만 공부하고 아직 실제로 구현해본 경험은 없습니다. 경험이 많으신 다른 분이 설명해주실 거라 생각합니다

  2. 간단한 소켓 서버-클라이언트로도 충분히 해결될 수 있을 것 같은데요. 결과 체크를 주기적으로 하는게 아니라 서버 연결을 계속 잡고 있다가 완료된 경우에만 하면…

  3. 김태호님이 생각하시는 “간단한”과 저희쪽에서 생각하는 “간단한”의 간극이 클 듯 하군요 ㅠㅠ 간단한 소켓서버로 저정도의 접속상태를 유지하려면 어떤 기술이 필요할까요? ㅠㅠ

  4. 아… 확장성까지 고려하려면 간단하게는 안될 수도 있겠네요. 그렇지만 일단 거의 오가는 데이터가 없을 경우 많은 접속을 들고 있는 건 단일 서버로도 충분하니까요. 사실 요구사항이 모바일 푸시 서비스와 비슷한 것 같습니다.

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.