평상시  동접 5~10만 정도에 시간이 나누어  적당하게 처리되는 일이고  트랜잭션 하나당  db 많이 건드리고 요청순서도 보장해야하는 좀 복잡한 일임.

그런데  동접 40만  50만 그리고 마지막 70만 3번에 걸친
이벤트가 발생했음  그리고  90퍼가 15분이내 집중 발생함.

지나서 몇명인지 아는거지 그땐  얼마나 들어올지 예측이 안되는 상황

 접속자 서버는 스케일아웃 대비 되어있어서 
비용만 지불하면 되는 상황인데 

내부 서비스 서버들이 문제였음 
내가 맡은 서비스는  순서도 보장해야 하면서 
디비 많이 건드리는 io가 많이 발생하는 작업임 

단일 생산자-소비자 패턴 구조에서 

N생산자 (1~10개)  - M 소비자 ( 1000개~ 2000개) 
로 개조를 하면서 

생산자 프로세스에서  db 트랜잭션 부분을 전부 
인메모리로 변경함. 

그러자  생산자 속도가 천배정도로 
무지막지 하게 빨라짐 

거기에 마이크로 최적화로  문자열비교 중 패턴 같은 부분 
제거하고 일부 문자 비교로 비교스텝을 줄이니까 3배 빨라지고 


그리고 순서를 보장해야 한다는 점으로 

한 고객은 반드시  같은 생산자에 같은 소비자 프로세스를 
타야하는 상황임 

특정고객이 서비스 엄청 요청하면 해당 프로세스를 공유하는 
다른 고객들이 상대적으로 피해를 보기 때문에 

큐 및 프로세스 배분을 기존 단순 모듈로 방식에서 해시를 추가해서
랜덤하게 배분 하려고 했음 


40만 동접날   프로세스를 엄청 늘렸어도 서버 자원은 
멀쩡했는데  이상하게 버벅거리는 느낌임. 
평상시 120밀리세컨 처리되는게  최대 3000밀리세컨에 
큐도 대기열 1000개를 넘는 요상한 상황 

알고보니  내 쪽이 아니어서 정확히는 모르지만 보안 방화벽이  일일히 트랜잭션마다 간섭하면서  속도를 느리게 하는것임.  

보안쪽 조져서 사후 그쪽 사후처리모드를 추가하라고 했다더라 



50만 동접날  디비도 조졌겠다 원활히 처리되다가 

갑자기 엄청나게 큐가 쌓이는 현상이 발생함. 
어찌어찌  트랜잭션수가 줄어들면서 
결국 겨우 넘겼는데   존나 분석해보니 

트랜잭션 종료시점에  publish로  실시간으로 
어떤 정보를 알려주는 부분이 있는데 
여기도 메모리 큐임. 

그냥 정보만 넘기는 수준이라 단순해서  큐에 쌓일 틈도 없이 처리되는  무지막지한 속도라 별 걱정없이 넘어갔는데 

프로세스 개수를 몇천개로 늘리는 바람에 
여기  10개 큐에 엄청나게 몰리게 되면서 40만에도 버티던 
메모리 큐가 한번 넘치니까  트랜잭션을 못 끝내고 붙잡고 있으면서  시스템 전반적으로 악영향을 끼치는 것 ㅅㅂ


여기서 느낀게  이건  뭔가  프로그램을 짜서 처리하는 느낌보다 

마치  홍수가 나눈데  이걸 이쪽에 물길을 내고 
저쪽에 물길을 내고 이지랄 하는 유량처리 하는 느낌이 드는거


Pub는 그냥 트랜잭션 끝낸뒤에 보내도록 순서 조정하고 
블로킹모드에서  waiting 시간을 줘서 지나면 그냥 씹고 넘어가도록 변경함.  극한 상황인데 뭐 어쩔거임. 
그리고 큐도 몇백개로 늘려버림 



마지막 대망의 70만 날  
이것저것  덕지덕지 발라서 온갖 똥꼬쇼로 처리한 덕분에 

무난하게  대기큐도  100이하로   10초이내로 해소될 정도로 
성능이 잘 나왔음 . 


휴우 안심하고 긴장감이 탁 풀리면서  나름 뿌듯한 
느낌이 들었다.


윗분한테 나중에 들었는데  70만 전날  그냥 돈 쳐벌라서 
그냥 물리적으로 하드웨어 성능 존나 좋은걸로  쳐바른거였더라


내가한 똥꼬쇼는 별 큰 역할은 하지 못함 ㅋㅋ