질문/조언팁/리소스 공유

저희는 푸시앱을 오래전 부터 사용하고 있습니다. 

 

php7.0으로 변경하면서 php-fpm을 처음 도입하면서 curl 비동기 푸시가 잘 안나가는 현상이 발견되어 조치를 했습니다.

1.한번에 나가야하는 푸시의 갯수

2.rss수집으로 인한 자동으로 게시글이 작성되는 게시글 여부 

 

위 조건에 따라 푸시가 안나가는 현상입니다.

 

서버세팅을 해주신 기진곰님 과 이 부분을 검토하다가

 

fpm 설정의 request_terminate_timeout 의 값이 영향을 줄 수 있다고 판단하여 

;request_terminate_timeout 주석 처리하고 테스트하여 해결되는 것을 확인했습니다.

 

 

이때 저것이 원인이라는 것을 찾게된 절차 중

한번에 나가는 푸시수를 분할하여 내보내면 이상 없다.

사람이 작성하는 게시글에서 발생하는 푸시는 이상이 없다. 

 

두가지가 어느정도 단서를 제공해 주었습니다.

 

저의 케이스는 푸시를 받아야할 회원수가 증가하고 + rss수집모듈에서 게시글이 작동될 때는 추가적으로 시간이 조금 더 필요해 생기는 문제였습니다.

 

 

위 방법으로 안된다면 푸시앱모듈의 푸시발송을 분할해서 발송하는 것을 사용해서 한번에 발송하는 푸시량을 작게 줄여 반복 발송하는 방법을 사용하면 될 것입니다. 

 

물론 이것저것 다해서 안된다면 비동기 방식은 포기해야 할 수도 있겠지만요...

 

 

 

 

또 하나 중요한 문제 중의 하나.

 

XE설정중 https 포트 설정이 있습니다. 443 포트는 생략하고 넣지 않는게 일반적입니다.

그런데 XE버그인데 이게 공란이면 curl 작업이 약간 해매다가 진행이됩니다. 

 - 글 작성시 약간 딜레이가 생깁니다. 서버에 요청중이 발생하기도 하구요.

 

443 포트번호를 넣어주면 즉시 작동해서 아주 빠르게 글 작성이 완료됩니다.

 

라이믹스에서 동일한 버그가 있는지는 모르겠네요.

푸시앱 개발자분이 모듈에서 이문제가 발생하지 않도록 고치겠다고는 하셨는데 언제 반영될지는 모르겠네요.

  • profile

    request_terminate_timeout은 원래 기본값이 없습니다. 타임아웃이 전혀 없으면 특정한 상황에서 서버가 불안정해질 수 있기 때문에, 타이트하게 관리하려는 의도로 제가 일부러 추가하는 설정값입니다. 타임아웃을 비롯한 각종 제한을 늘리거나 없애는 것은 서버가 불안정해질 리스크를 감수하겠다는 얘기죠. 이상적이지 않은 방식으로 구현된 프로그램들 때문에 어쩔 수 없이 하게 되는 일종의 필요악이지, 딱히 널리 퍼뜨릴 만한 권장사항은 아닙니다. 타임아웃 없이 오랫동안 실행되는 갯수만큼 실제 유저들에게 제공할 수 있는 pm.max_children이나 아파치 프로세스 갯수가 줄어드니까요.

    푸시앱은 뭐랄까... 동기식이든 비동기식이든 현재로서는 만족스러운 방식이 없습니다. 이런 방식은 도무지 대안이 없는 웹호스팅 환경에서나 최후의 방편으로 쓰고, 조금이라도 규모가 있는 사이트라면 푸시 발송하는 프로세스를 아예 분리해서 크론탭이나 데몬으로 실행할 수 있도록 하면 좋겠어요. 타임아웃 신경쓸 필요 없는 PHP-CLI나 node.js가 최고지만, 정 안되면 웹크론이라도...

    - 글쓰기 요청 도중에는 발송할 푸시 정보를 DB나 Redis 등에 입력만 하고 패스
    - 백그라운드에서 실행되는 별도의 프로세스가 이 정보를 불러와서 실제 푸시 발송 처리

    라이믹스에서는 PHP-CLI 크론탭 사용을 활성화하기 위해 터미널 환경과 퍼미션 등을 체크하고 중복 실행을 방지하는 기능을 기본 제공하고 있습니다. 오래된 알림 정리, 빈 폴더 정리 등 정기적으로 해줘야 하는 관리 작업도 크론탭으로 실행할 수 있도록 예제 스크립트를 넣어놓았고요. XE에서도 얼마든지 비슷한 방식으로 구현할 수 있습니다. 아무쪼록 올해는 고급 개발자분들 위주로라도 크론탭을 활용한 백그라운드 프로세싱 기법이 더 널리 사용되었으면 합니다.^^

  • profile profile

    네. 구독모듈에서는 말씀 하신 방법을 사용하고 있죠. 별도 백그라운드 발송 php에서 발송을 전담하고 글 작성시에는 누구에게 보낼지 등 발송정보만 기록해서 실제 푸시 발송은 백그라운드에서 php 발송프로그램이 합니다. 이것도 크론탭에서 일정시간마다 실행해줘서 타협된 시간 안에 발송이 되도록 해주고 있죠.

    저도 일부러 제한해 놓은 것을 주석하는것이 결국 리소스문제를 막으려고 해 놓은 기본값인데 이것을 주석하는 것은 환영하지는 않지만 현재로서는 대안이 없어 이렇게라도 서비스를 유지해야 해서 선택을 했습니다.

    운영자가 항시 모니터링하면서 문제가 생긴다면 다른 대안을 빨리 찾아야겠죠.

     - 아마도 기본설정을 유지하고 푸시발송 분할을 하여 한버에 처리하는 수량을 줄여주고 반복작업을 하게 하는 것이 대안이 될 수 있을 것 이라 지금 예상하고 있습니다.

    사실 푸시앱의 푸시는 만족할만한 상황은 아니란 것에 많은 동감을 합니다.

    그리고 2번째 문제도 좀 특이한 케이스구요. XE 버그라고 하시는데 저는 개발자가 아니라 잘 모르겠습니다.

  • profile profile
    여러 개로 분할하면 동시에 여러 개의 요청이 들어가니까 더 많은 pm.max_children 또는 아파치 프로세스를 잡아먹게 됩니다. 실제 유저들에게 제공할 수 있는 동접수를 유지하려면 프로세스 수를 늘려 줘야 하고, 그러면 서버가 불안정해질 리스크는 더 높아집니다. 악순환이죠 ㅠㅠ

    XE의 FileHandler::getRemoteResource() 함수를 통하지 않고 curl 함수를 직접 사용하는데 XE가 영향을 줄 것 같지는 않습니다. 포트가 비어 있는 경우 https://도메인.com:/ 이런 이상한 주소로 요청을 넣는 건 아닌지 확인해 볼 필요가 있겠네요. 포트가 없으면 콜론(:)도 없어야 하는데...
  • profile profile

    https 포트 문제는 저도 개발자가 아니고 실제 디버깅은 푸시앱모듈 개발자분이 직접하시고 저에게 전달해 주신 것이라.. 일단 그렇게만 들었습니다. 비어 있으면 기본값 혹은 443 으로 해서 즉시 작동해야 하는데 뭔가 비정삭인 것을 시도하다가 동작이 된다고 하셨던 것 같습니다.

    뭐 일단 현재 증상은 XE 관리자 설정에 443을 넣으면 바로 동작, 공란이면 1-2초 이상한 짓을 합니다.

  • ?

    구독자 수가 적다면 php단에 붙여서 전송해도 크게 문제가 없어 보이지만..
    알림을 보내야 하는 단말기 수가 1000, 10만 100만 이상이 된다면 더욱이 불안정하게 동작되겠죠.

    저런 경우엔 기진곰님이 언급하신 것처럼 nodejs를 사용해서 알림 전파용 서버를 하나 파서 별도로 동작시키는게 젤 좋습니다.
    php에선 당장 주어진 클라이언트 요청에만 열중하게 하고 알림을 보내야 하는 클라이언트들에 대해선 클라이언트 정보와 알림 정보만 node서버에다 던져버리는거죠.

     

    node서버에선 전달받은 클라이언트 데이터에 대해 실시간으로 처리하고, 처리중에 추가로 보내야 할 알림들이 더 온다면 그저 대기열에다 쌓아놓고 대기열이 비어버릴때까지 계속 보내기만 하면 되겠죠. (오직 한 개의 프로세스에서 php로부터 알림 받기와 gcm서버로 알림 보내기를 둘 다!)

    이렇게 구성하면 cron주기를 기다릴 필요 없이 (대기열이 별로 없다면)알림들이 바로바로 전송되고 php에서도 curl의 부담 없이 xe본연의 업무에 충실할 수 있습니다.

    http://blog.hkwon.me/rabbitmq-php-node-jsreul-hwalyonghae-gcm-push-ceorihagi/
    참고하시면 도움이 될 것 같습니다.


서버에 요청 중입니다. 잠시만 기다려 주십시오...