Github
Gamlendar_Selenium
겜린더 게임 수집 파이프라인을 안정화 작업을 하고 있을 때 발생했던 일이었다.
약 2300개의 게임을 수집해 DB에 저장하기
문제
안정화 하고 테스트를 해보는데
분명 수집할 때는 1400개 이상의 게임이 수집되었지만
DB에는 24개의 게임 밖에 저장이 되지 않았다.
왜 그럴까..?
원인
일단 기존 데이터 수집 방식 구조를 알아야 할 필요가 있다.
수집 프로그램은 최초 실행 때 db 인스턴스를 생성한다.
main.py 최초 실행 때 db 인스턴스를 생성하는 걸 볼 수 있다.
이번에 작업하면서
안정화하면서 기능을 하나 추가했었는데
지난번 글에서 언급한 닌텐도 스위치 페이지 난제를 해결하기 위해
스위치에서 수집한 게임이 기존 DB에 수집되어 있는가를 확인하는 검색 작업을 추가하였다.
저번에 언급한 난제
switch/detailScrap.py
db = Database()로 인스턴스를 생성하고 findGame 함수로 검색할 수 있게 만들어뒀었다.
여기서 이제 눈치 빠르신 분들은 어디가 문제인지 눈치채셨을 것 같다.
그렇다 똑같은 Database 인스턴스가 여러 개 생성되었다.
이를 해결하기 위해선 예전에 공부했던 싱글톤 패턴을 이용하면 될 것 같단 생각이 들었다.
해결
싱글톤 패턴??
출처: 위키피디아
짧게 요약하면
싱글톤 패턴은 특정 클래스의 인스턴스를 1개만 생성되는 것을 보장하는 디자인 패턴이다.
장점으로
1. 메모리 낭비를 줄일 수 있다.
한 개의 인스턴스만을 고정 메모리 영역에 생성하기 때문에 메모리 낭비를 방지할 수 있다.
-
속도 측면의 이점
생성된 인스턴스를 사용할 때는 이미 생성된 인스턴스를 활용하여 오버헤드를 줄일 수 있다. -
데이터 공유가 가능하다.
여러 클래스에서 데이터를 공유하며 사용할 수 있다. 하지만 동시성 문제가 발생할 수 있어 설계할 때 유의해야 한다.
왜 나는 싱글톤 패턴을 사용했는가?
1. 데이터 공유
일단 싱글톤 패턴을 사용해야겠다고 생각한 이유는
데이터의 공유가 제일 큰 목적이었다.
물론 그렇게 되면 의존성이 높아질 수 있다는 단점도 있지만
애초에 데이터 공유가 안되면 아예 내가 원하는 대로 작동이 불가능했기 때문에 싱글톤 패턴을 사용하기로 했다.
2. 싱글 스레드로 동작
내가 만든 수집 봇은 싱글 스레드로 동작한다.
싱글톤의 대표적인 문제점 중 하나가 멀티 스레드 환경에서의 동시성 문제인데
내 수집 봇은 애초에 싱글 스레드로 동작했기 때문에 크게 문제가 없을 것 같단 판단이 들었다.
해결한 코드
이런 식으로 중복된 인스턴스를 만들지 못하게 하였다.
하지만 이렇게 했는데도 여전히 1400개에서 24개밖에 올리지 못하는 모습을 보여주었다.
코드와 메모리 주소를 보니깐 인스턴스는 분명 하나인데
인스턴스를 할당할 때마다 init을 하는 것 같았다.
그래서 최초로 초기화하면 그 이후에는 초기화하지 못하게 만들었다.
마무리
싱글톤 패턴은 자바를 공부하면서 대표적인 디자인 패턴으로 공부를 하게 되었는데 이걸 파이썬에 적용해 볼 줄은 몰랐다.
그래도 덕분에 개념을 더 확실하게 잡아갈 수 있었고
이런 상황에서 싱글톤 패턴을 이용해 문제를 해결해야 한다는 생각까지 도달한 모습을 보고 그냥 막 배운 건 아니구나 싶었다.
싱글톤 패턴을 찾아보면서 안티패턴이라고 하던데, 객체지향적인 측면에서 보면 맞는 말이다.
하지만 무작정 안티패턴이라 해서 배척하기보다는, 내 상황과 조건을 확인해보고 필요하면 사용하는 것이 맞다고 보았다.
애초에 멀티 스레드 환경이 아니라 싱글톤 패턴을 사용하기 좋은 조건이 아니었을까 생각한다.
잠깐 언급한 닌텐도 스위치 게임과의 데이터 통합도 잘 해결된 것 같고, 이렇게 수집 봇도 나름의 안정화를 잘 거쳐가고 있는 중이다.
