웹 커뮤니티를 라이트세일 단일 서버로 운영하다

규모가 커져서 RDS + 라이트세일로 분할해서 운영하고있는데

 

uHap5qn.png

twZf2Mv.png

 

하루에도 몇번씩 사이트가 1분정도까지 뻗어버립니다.

rds 서버 분리전에는 없던 현상인데 이러한 분리 운영이 권장되지 않는건지

아니면 혹시 놓친게 있는지 여쭤봅니다 

감사합니다 

  • profile

    48은 DB 쪽의 특성과는 무관하게, 웹서버(PHP-FPM) 쪽에서 설정해 놓은 제한일 가능성이 높습니다. 웹서버가 48개의 프로세스만 허용하니까 DB 쪽에서 보이는 연결 수는 48개 이상 안 올라가는 거겠지요. 즉, 48은 큰 의미가 없는 숫자이고 그냥 연결 수가 급증한다는 현상만 보면 됩니다.

     

    저렇게 연결 수가 늘어나는 것은 교통정체와 비슷합니다. 앞에 누군가 안 움직이는 녀석이 있으니까 뒤에 차들이 줄을 서는 거지요. 빨리 처리하지 못하는 이유를 찾아야 합니다.

    - 쿼리 자체가 무척 비효율적으로 작성되어서 가끔씩 그 쿼리를 실행할 때마다 저렇게 되는 것일 수도 있습니다. 캐시 덕분에 평소에는 안 보이다가 캐시가 갱신되는 시점에만 저렇게 눈에 띄는 경우가 많습니다.

    - 검색 로봇이나 크롤러, 허락받지 않은 파싱 때문에 갑자기 접속자수가 늘어나서 전체적인 부하가 높아지는 바람에 모든 쿼리가 느려지는 것일 수도 있고요.

    - MySQL과 Aurora의 쿼리 최적화 알고리즘 차이 때문에 똑같은 쿼리라도 소요시간이 크게 달라질 수 있습니다. MySQL 계열의 쿼리 최적화가 은근히 멍청합니다. 뭐 하나만 달라져도 100배, 1000배씩 느려지곤 해요.

    - RDS로 바꾼 것이 문제가 아니고, 비슷한 시기에 변경한 다른 것이 문제일 수도 있습니다.

     

    아무튼 부하가 튀는 문제는 쿼리를 뜯어봐야 합니다. DB 쪽에서 show full processlist 명령으로 어떤 쿼리가 몇 초간 실행중인지 확인할 수 있습니다. 실제 쿼리나 소스를 확인하기 전에는 상품 변경, 업그레이드 등 어떤 행동도 하지 마세요. 정상적인 웹서비스라면 0.1초 이상 걸리는 쿼리가 없어야 합니다.

     

    위의 문제와는 별도로, 라이트세일+RDS는 그다지 성능이 잘 나오는 조합은 아닙니다. 라이트세일도 만성적으로 CPU가 부족하고, RDS도 성능보다는 안정성에 몰빵한 상품인데다가 레이턴시도 극악이니까요. 라이트세일 사양이 부족하다면 EC2로 바꾸고, EC2 안에 DB를 설치해서 사용하는 편이 훨씬 빨라요.

  • profile
    AWS는 다양한 도구들이 있습니다. 저 문제의 경우 RDS의 Performance Insight 를 사용하면 해결할 수 있습니다.
    문제가 되었던 시점의 쿼리, 요청계정, IP, 실행시간(세부 단계로 나눠서) 알려줍니다.
    RDS 수정을 하셔서 Performance Insight 를 사용함으로 바꿔보세요.