DB도 튜닝이 있나? 앱도 튜닝이 있다.

아마 한국 IT 생태계의 고질적인 문제라 봐도 과언이 아니다.

물론 게임같은 경우 최적화 안하면 돌리기도 힘들어 뒤지겠지만 (근데 그래도 개적화하는 게임 몇개씩은 있다.)

앱들, 웹사이트던 응용이던 모바일앱이던 튜닝은 무시할 수가 없다.

뭐.. 이해는 한다. 왜냐면 대부분의 비즈니스 앱들은 DB 처리가 대부분을 차지한다.

쇼핑몰부터 은행까지. 작던 크던 대부분의 앱들은 DB를 타고 데이터를 가져오거나 설정한다.

그래서 DB 튜닝만 해도 최대 몇십배 빨라지는 희한한 앱도 나온다.

하지만 그렇다 보니 앱에 소홀해 하는 경향을 몇몇 체험하고 목격하면서 한번 프로그래머들에게 묻는다.

당신이 만든 앱이 느려지면, 무엇을 먼저 보는가?

아마 절반 이상은 DB 문제라고 할 것이다.

예전 프로젝트에서 DB 인덱스 안걸어서 SELECT 쿼리가 10초 이상 걸리는거 내가 0.3초로 만든 경험이 있어 내가 더이상 뭐라 할 수 없는 부분이 있기도 하다.

하지만 프로그램을 더 많이 타는 프로세스가 있다면 얘기가 달라진다.

비즈니스를 간단하게 예를 들면, 엑셀 업로드 후 해석해서 DB를 넣던 뭘 하던 하는것들.

그리고 특히 웹에서는 세션과 캐시.

메모리를 효율적으로 관리할 수 있는 메모리 키값 기반 DB Redis 를 도입했다면 조금 더 진보했다고 할 수 있지만,

왠만한 비즈니스 프로그램들은 대부분 기본적으로 제공하는 세션과 캐시에만 의존한다.

응용도 마찬가지다.

상당히 안좋은 전략이다.

그렇다고 세션과 캐시를 사용하지 말라는 말을 하고싶었다? 전혀 아니다.

세션과 캐시는 앱에 있어 상당히 중요한 역할을 하고 있는거 설마 내가 모를리가 있겠나?

하지만 최소화해야할 필요는 있다.

아시다시피 세션과 캐시는 메모리를 쓴다. 물론 캐시는 경우에 따라 저장공간을 활용하며, 메모리와 디스크를 오가는 역할을 하는 캐시 시스템도 존재한다.

이유는 간단하다. 필요한 만큼만 쓰고 나머지는 다른 프로세스에 양보하여 최대한의 앱 속도를 내기 위한 전략이다.

특히 메모리가 한정된 임베디드 앱이나 모바일 앱, 그리고 웹 사이트에서는 정말 필요한 전략이다.

자바 및 닷넷 고수들은 항상 이런 말을 한다.

“가비지 컬렉터를 믿지 마라.”

그들은 언젠가 객체 데이터를 날려먹을 수도 있다. 반드시 돌아가는 동안 영구적으로 가지고 있다는 보장이 없다.

그래서 영구적으로 보관하는 DB란 녀석이 있는 것이고, 세션이나 캐시를 효율적으로 관리하는 모듈이 따로 있는 것이다.

특히 세션은 사용자가 사용 안한다고 해서 지워지는것도 아니다. 웹사이트 말이다.

사용자가 언제 사용 안할 지도 모르고 다시 사용할 지도 모른다. 웹 기술의 한계라고는 하지만 그건 어쩔 도리가 없다.

그래서 세션의 경우는 세션 만료 시간이 존재한다.

하지만 그렇다고 해서 세션 만료가 지나거나 사용 안하는 등으로 해서 해당 사용자의 세션을 날리나? 그것도 아니다.

그리고 계속 사용한다고 그걸 계속 보관하는것도 아니다. 언젠가는 Recycle 로 날라갈 지도 모른다.

왜냐? 시스템 메모리 관리를 위해서.

자바던 닷넷이던 웹 서버의 세션 시스템은 은근 복잡하고, 불안정하다. 100% 신뢰가 안되는 시스템이다.

그렇다고 해서 100% 신뢰할 만한 세션 및 캐시 시스템 또한 없다. DB 기반 세션도 마찬가지다.

하지만 대신 DB는 디스크에 보관하기 때문에 데이터 가용성으로 신뢰도가 일반적인 것보다 더 올라간다.

또한, 메모리에 보관시 DB 특성상 리사이클 시스템이 철두철미하여 신뢰도가 한층 더 올라간다.

그래서 Redis 를 세션이나 캐시 용도로 적합하다는 얘기가 나오는 것이다.

그렇다고 해서 기본적으로 제공하는 세션이나 캐시 시스템이 “쓰레기” 냐? 이것도 아니다.

단지, 필요한 데이터만 필요한 공간에 담아서, 나머지는 DB 연동이나 프로그램 연동 등에 맡기고, 처리하는 게 좋은 전략이라는 것이다.

예를 들면, 사용자 로그인 하면 세션에 담을만한 건 사용자의 ID, 이름, 가지고 있는 권한 뿐이다. 전화번호, 이메일을 세션에 담을 이유가 없다. 그들은 세션에 담아서 어따가 쓰나?

이렇게 최소한의 정보만으로 최대한의 다른 메모리 사용을 위해 양보하자는 뜻이다.

특히, 공통코드를 메모리에 담는 비즈니스 앱이 상당히 흔하다. 물론 그렇게 하면 공통코드까지 DB를 안타기 때문에 성능은 올라가는 것은 사실이다.

나쁜 전략은 아니다. 단지 한가지만 지키면 된다.

공통코드 키와 값 외에는 어떤것도 넣지 않는 것을 추천한다.

그리고 변경사항 검색을 위해서라면 그냥 최근 업데이트 날짜를 가져오는 것이 좋다.

그런 다음에 매 요청시마다 날짜만 DB에 왔다갔다하고, DB가 최신이면 최신 공통코드만 가져와 교체하면 메모리 관리 측면에서 이득이다. “동기화” 의 장점을 이용한 것이다.

만약 이것도 지키고 있다면 이미 중급 이상이라 봐도 손색없는 개발자다.

물론 기술보다 업무를 프로그램으로 소화해내는 능력이 좌우하는게 개발자 수준인 거는 한국 사회에서는 부정할 수 없는 현실이다.

하지만 역시.. 개발자는 기술도 당신의 프로그램을 좌우한다.

10년지기 이상 개발자가 떵떵거리며 살 수 있는 이유가 바로 그것이다. 돈 많이달라고 징징해대기만 하는 그런 도둑놈이 아니다.

그런 기본적인 기술을 토대로 업무에 많이 녹아들여 빠르게 만들어내는 개발자야 말로 클라이언트에게 이상적인 개발자 아닌가?

그렇다고 돈 많이 주기 싫다면 걍 노트에 적어서 관리하는 것을 추천한다.

어쨌든 앱 튜닝이라 거창하게 말했지만 게임도 당연히 캐시가 중요하지만 비즈니스 앱 개발자가 많은 관계로 비즈니스 앱을 통해 중점적으로 언급했다.

앱도 군더더기를 줄이고 이 세션과 캐시를 관리만 잘 한다면, 사업자에겐 솔루션이 되며, 개발자에겐 테크닉이 된다.

composite / 2013년 10월 28일 / 미분류
태그:, , , , , ,

답글 남기기

Your email address will not be published / Required fields are marked *