본문 바로가기
스타트업/운영

서버개발 기본기, "데이터 다루기" :: 알고 넘어가자.

by 회색연필 2019. 9. 11.

데이터분석 이야기를 하기전에,

데이터엔지니어링 이야기를 좀 하고 넘어가자.

 

데이터분석이 숨은 뜻을 찾아내는 거라면,

데이터엔지니어링이란, 데이터를 보관, 이동, 정리, 변형하는 기술을 말한다.

Hadoop, Oracle 등은 데이터소프트웨어들이지, 엔지니어링 그 자체는 아니다.

 

SI를 하면 대형데이터 다룰 일이 별로 없다.

새로 만드는 시스템은 데이터가 없고,

추가시스템이라면 접근권한이 없기 때문이다.

 

"초기데이터 구축"도 중요하지만, "상용데이터"를 다루는 건 완전히 다르다.

그래서, 3년이나 지나도 "데이터 다루기의 기본"을 모르는 경우가 많다.

정리해보자.

 

지울까 말까

데이터 생성의 주체는 두 개 밖에 없다.

"사람"이거나 "기계"이거나.

여기서 "사람"이란 사용자를 지칭한다.

 

"사용자 데이터"

내 개인 프로필, 내가 쓴 트윗.

그런것들이다.

이 데이터는 돈이랑 동격이다.

가치를 발견 못해서 그렇지,

필요한 사람이라면 비싸게 주고 산다.

지우면 안된다.

 

"시스템 로그"

기계가 만드는 데이터. Log 라고 한다.

로그는 시스템이 어떤 일을 했는지 기록하는거다.

프로그램이 잘 작동하는지 확인하기 위해 남긴다.

옛날에는 지웠다.

요즘에도 지운다.

 

하지만, 막지우면 안된다.

정산을 3개월마다 하면, 3개월 전 로그는 남아있어야 한다.

정산오류가 시스템오류에 기인했는지 파악해야 하기 때문이다.

이거 파악을 못하면, 정산은 계속 틀려지고, 

회계감사는 매우 난감해진다.

 

Error 메시지를 띄우지 않는다고 해서,

정상적으로 작동한다는 뜻은 아니다.

 

"사용자 로그"

사용자행동을 추적하는 로그다.

"A 씨가 B제품을 샀다."

이런거다.

 

이건 지우면 안된다.

시스템이 남기지만, 회사가 필요해서 남기는거다.

역시 돈이 된다.

대신 규제가 있다.

개인정보보호법, 금융법 등.

필요하면 법의 테두리 안에서 활용해야 한다.

 

원본 데이터 보존법칙

"모든 원본 데이터는 변경하지 않는다."

 

"SQL editor로 업데이트 하면 초보자다.

고수는 프로그램 짜서 update 한다."

어휴 ~ 그런 말이 아니다.

 

사람이 만들었던, 시스템이 만들었던, 

"원본"은 절대 변경되지 않아야 한다.

원본으로서의 보존가치 때문이다.

처리해야 할 일이 있다면 사본을 만든다.

사본이 잘못되면, 새로운 사본을 만든다.

 

데이터 다루기 기본 중의 기본이다.

SQL editor로 고쳐보는 건, 학원에서 하는거다.

교육용 데이터니까 하는거다.

 

프로그램으로 쌓인 데이터는 모두 연결되어 있다.

건수나 합계가 맞아야 한다.

사람이 개입하는 순간, 그 정합성이 무너진다.

시간이 지나면 오류가 어디서 시작되었는지도 모른다.

전체 데이터를 신뢰할 수 없게 된다.

데이터도 데이터지만, 그동안의 시간도 아깝다.

한순간의 실수 때문에 거액을 날릴 수 있다.

 

'에이, 딱 그 부분만 고칠건데.'

명심하자.

절대 딱 그 부분만 고쳐지지 않는다.

복잡한 시스템일수록 더욱 그렇다.

통계와 분석이 돌면, 사소한 징후라도 포착이 된다.

 

이런걸 "원본 데이터 보존법칙"이라고 한다.

Raw Data 일수도 있고, Master Data 일수도 있다.

암튼, "기준테이블"은 건드리면 안된다.

그게 사업의 정체성을 결정짓기 때문이다.

 

시간 기록은 필수

서버는 시간이 딱 맞아야 한다.

당연히 로컬시간 기준이다.

1초 단위까지 맞춘다.

 

인터넷이 연결된 시스템이라면 "인터넷시간 동기화"기능을 써라.

보안 때문에 인터넷 연결을 못할 수도 있다.

이 경우라면 스마트폰을 보고 맞춘다.

 

왜 그럴까?

두 대의 시스템이 있다.

같은 웹어플리케이션이 돌고 있다.

서버 A가 내려가고 서버 B가 5분 후에 내려간다.

한쪽에 집중공격이 들어온 케이스다.

Session이 끊기기 전 쉬지않고 트래픽이 들어왔기 때문에

Load Balancer 가 작동하지 않은 거다.

 

유사한 데이터가 1초에 5건씩 생성된다.

사람이 이렇게 할 수는 없다.

어뷰징을 목적으로 프로그램이 도는 거다.

차단을 해야 한다.

 

이쪽에서 던진 데이터가,

저쪽에서 10분 후에 쌓였다.

그렇게 도는 프로그램이란 없다.

중간에 뭐가 잘못되었는지 파악해야 한다.

 

시간을 보면서 이런 추론을 하게 된다.

시간은 데이터검증의 "키"이자,

시스템검증의 "핵심"이다.

 

그러니 아무렇게나 대충 맞출 일이 아니다.

시스템이 2대만 넘어가도 시간을 맞춰준다.

네트워크 내부에 시스템 10대가 넘거간다면

시간 동기화는 완전.완전.완전 필수다.

GMT+9, UTC 확인도 필수다.

 

세번 생각하기

초보자 때 자신있게 Drop table 을 했다.

개발시스템 내부에 있었으며,

"임시" 디스크 영역에 있었으며,

아무도 그 테이블을 만들지 않았다고 했다.

심지어 테이블 내부는 쓰레기 데이터로 가득차 있었다.

 

직접 사람들에게 물어보았다.

개발팀 전부에게 물어보았다.

아무도 몰랐다.

 

"누군가 연습용으로 만들어 놓은 것이다."

100% 그렇게 생각했다.

그래서 자신있게 Drop Table 했다.

 

하루 후에 난리가 났다.

누군가 몰래 만들어 놓은 테이블이었지만, 약 5억원이 들어간 사내시스템이었다.

오픈 초기라 허접한 데이터만 채워져있던거다.

아직 담당자가 없어 관리상태가 엉망이었던거다.

하지만, 5억짜리 시스템이고 현재 운용중인 시스템이란 사실은 변함이 없었다.

 

Drop Table은 실행취소가 되지 않는다.

진짜 5억을 물어내야 할 판이었다.

등에 식은 땀이 흘렀다.

 

이리저리 사람들이 동분서주했다.

다행히 한달전 백업한 게 있었다.

불행히도 하드디스크로 백업한거였다.

복구하느라 꼬박 12시간이 걸렸다.

데이터가 너무 컸기 때문이다.

물리적인 읽고쓰기시간은 어쩔 수가 없다.

 

그 이후로 나는 "서버"에서 Enter를 쉽게 치지 않았다.

빠르게 타이핑을 하지도 않는다.

서버에서 "다라라락" 치지도 않는다.

그런 사람은 아직 사고친 경험이 없는거다.

 

Enter 치기 전에 세번을 생각한다.

작업전 꼭 원본 데이터를 백업한다.

비싸게 배운 교훈이었다.

 

작업시트, 필요할까?

데이터사이즈가 GB 단위를 넘어가면,

읽고 쓰는 물리적 시간이 오래 걸린다.

"롤백하면 되지 뭐."

그 롤백시간이 1시간이 걸리면 불안이 엄습해온다.

 

SSD 를 쓰면 좀 더 빠르긴 하다.

하지만, Update나 Delete 작업은 느리다.

때에 따라서 20분 이상, 재수 나쁘면 1시간 이상 걸린다.

"내가 뭘 잘못했나?"

"이거 멈추고 다시 해야 하나?"

"파일 깨졌으면 어떡하지?"

온갖 불안감이 올라온다.

운영개발 중엔 쉽지 만나는 상황이다.

 

그래서 "사전연습"을 하게 된다.

오류가 나는 순간, 서비스는 멈춰버린다.

고객들이 접속안된다고 난리친다.

앱을 삭제해버리는 고객들도 있다.

 

그래서 무중단으로 작업을 해야 한다.

난이도가 높다.

이럴 땐 "작업시트"를 미리 써본다.

단계별로 롤백계획도 세운다.

이렇게 배포하는 걸 "무중단 배포"라고 한다.

클라우드 상에선 배포방법이 진화되었다.

하지만 기본은 똑같다.

 

1) 에러가 나서 잘못되면 어떻게 이전 단계로 돌아갈 것이냐?

2) 잘못된 배포중에 발생되는 "오류 데이터"를 어떻게 식별하고 처리할 것이냐?

 

1)번도 중요하지만 2)번도 중요하다.

매우 중요하다.

오류데이터를 기반으로 "요금청구서"를 내밀 순 없다.

 

작업시트를 통해 이런 걸 먼저 짚어본다.

데이터는 꼬여도 복구하지 않는다.

저렇게 쌓인 오류데이터는 보통 그대로 둔다.

원본이기 때문이다.

다만 사후 처리를 할 때 제외시킨다.

 

큰 데이터 작업을 할 때는 사전작업, "작업시트"가 필수다.

 

연동데이터, 어떻게 하지

카드사와 제휴를 한다던지.

포인트 제휴를 하는 경우가 있다.

그 데이터가 "돈"일 수도 있고, 아닐 수도 있다.

문제는 데이터가 남의 회사로 넘어가는 순간

통제는 상실된다.

지울수도 없고, 코드를 더할 수도 없다.

 

그래서, 나간데이터, 인입데이터는 "2차 원본 데이터"처럼 취급한다.

처리가 끝나면 지우긴 하지만, 꼭 백업을 한다.

분쟁이 생기면 해결해야 하기 때문이다.

 

작업기록도 남길까?

어떤 작업이 어떻게 작용했는지 아는 건 중요한 경험이다.

10 MB 짜리 데이터 파일을 변경하는데,

2시간 걸린다면 뭔가 프로그램을 잘못 짠거다.

 

그런데 이상없다고 바득바득 우기는 걸 본적이 있다.

열받았다.

그 사람하고는 다시 보지 않는다.

 

작업기록.

특별한 건 아니지만, 기록해두는 게 좋다.

그 때 썼던 명령문은 간단하게 저장해두자.

나중에 버리더라도, 지금은 어딘가에 저장해두자.

 

운영개발을 해보면, 한달 후에 이상증상이 발견된 경우도 많았다.

서너건에 불과하지만, 돈에 관계된 거라면 민감하다.

그 때 어떻게 했더라? 

이렇게 생각하는 일이 없도록 말이다.

 

끝.

반응형

댓글