MariaDB 온라인쇼핑몰 성능이슈 해결과정 3편
Updated:
MariaDB 온라인 쇼핑몰 성능이슈 해결과정 3편
6일차: Galera Cluster node 추가 (2node → 3node)
Galera Cluster Node간 동기화 지연여부 확인 1일차에 Galera Cluster 3-Node(Active-Active-Active) 운영 중 DB Hang원인이 Galera Cluster Node 동기화 지연이라는 기술지원업체의 진단에 따라 2Node로 변경하였다. 하지만 Galera Cluster 동기화 관련 지표를 모니터링 한 결과, 동기화에 따른 부하는 미미함을 확인하였다.
[Note]
grecved(WSREP_RECEIVED_KBYTES) Total size in bytes of all writesets received from other nodes. grplcted(WSREP_REPLICATED_KBYTES) Total size in bytes of all writesets replicated to other nodes.
Galera Cluster Node 추가 토요일 밤12시에 Node 추가(2 → 3) 작업 이후 DB부하 분산문제가 발생(1번 Node부하 집중)하였으며, Connection Pool 부족현상이 발생하였다. 추가된 Node에는 접속권한이 없어 모니터링 하지 못하는 상황에서 결국에는 DB작업시 WAS재기동 하지 않은 사실을 알아 WAS재기동(14시)하여 시스템 정상화됨. Cloud 관리 회사의 기술숙련도가 낮으면 아무리 좋은 Cloud 환경의 장점이라도 퇴색됨을 느꼈다.
8일차: 네이버 배너광고(3차 프로모션) 3차 프로모션 30분전 WAS메모리 부족현상이 발생하여 메모리 증설(8GB → 16GB)하였다. 온-프레미스 환경에서는 할 수 없는 Cloud 환경의 좋은 튜닝 사례이다.
하지만, 메모리 증설 이후 온라인 쇼핑몰 이미지 파일이 표시되지 않는 오류가 40여분간 지속되었다.
이미지 파일에는 광고와 구매버튼이 링크되어 매출에 큰 영향을 줄 수 있는 장애상황이었다.
원인은 WAS 재기동시 스토리지를 Mount하지 않은 것이었다.
재기동하면서 스토리지를 Mount하지 않아 장애가 발생하고 문제해결까지 40분이나 소요된 것은 마지막 프로모션에서 너무나 큰 아쉬움으로 남는다.
3차 프로모션에서 온라인 몰 오픈 이후 일 최대매출(10억)을 달성하였지만 Cloud 관리회사의 실수로 의미가 퇴색되었다.
지금까지 경험상 이정도 튜닝을 하였다면 시스템이 안정화 되는게 보통인데 해당 사이트는 계속 불안정한 상황이 계속되었다.
Cloud 업체 자체의 문제로 파악되는 이슈사항들을 정리하고 철수하기로 하였다.
(4편에 계속~)