API GW 상용화 서비스 개발 (Agent 편)

1 minute read

방향성

  1. 고객이 설치가 쉬워야 한다.
  2. 고객이 사용이 편리 해야 한다.
  3. 버그는 발생시 고객에게 피해를 최소화 해야 한다.
    • 아래의 방법중 고민을 많이 하였는데 실패가 되는 상황은 버그가 아니더라도 일반적으로 발생되는 상황이지만 중복 발송은 큰 문제가 될 수 있어 실패 처리하는 방향으로 기능 개발
      1. 재발송 처리 (중복 발송)
      2. 실패 처리

구조

현재 대부분의 타사 GW는 소캣 기반으로 되어 있다.
소캣의 장점은 빠르고 신뢰성이 유지되지만 확장 하거나 연동 작업을 할떄 어려운면이 있다.
그래서 OPEN API(HTTP) 기반의 GW를 개발 하였고 HTTP로 통신 하기 떄문에 장단점이 있다.
웹, APP등에서 연동해서 사용이 편리 하지만 현재 고객들은
Agent기반에 연동을 많이 하기 때문에 그런건 소캣 기반으로 하는게 나은거 같기도 해서 아직까지는 애매하다.. 
하지만 미래를 생각하고 Agent를 소캣 GW가 아닌 HTTP 기반의 API로 연동

기능

  1. Send 처리 기능
  2. Report 처리 기능
  3. 로컬 파일 큐 사용 # 메모리로만 데이터 처리 하기에는 사용량 증가와 안정성이 떨어짐
  4. Report expire 기능
  5. Config 파일 암호화 기능
  6. 로그 테이블 사용 기능
  7. 등등

느낀점

확실히 소캣 기반으로 하는게 Agent 개발시에는 편한거 같다.
Report 데이터를 얻기 위해서 Agent에서 Request를 보내야 해서 주기적인 리소스 낭비가 발생 하는거 같다.
하지만 소캣으로 할때 에러가 발생하여 Report를 못받는 상황은 줄어들꺼 같아서 낫긴 하지만 부하가 크다.

고객들이 편하게 설치 편하게 사용 할 수 있는 것을 목표로 개발 하였다.
생각보다 고민할꼐 많았던거 같다.
로그는 어떻게 찍어야지 이해하기 쉬울지 Config는 어떻게 명명해야지 아무나 수정 할 수 있을지 어려운게 많다..

Updated: