Sawzall

Language for Log Processing

나름 전공 출신이기에 정통파 프로그래머 라는 정체성이 있었고, 학교든 회사에서는 뭐든지 하자 라는 생각으로 여러 언어들을 기회 닿는 대로 배웠더랬다. 오늘은 그 중 추억의 언어인 Sawzall.

Log

구글에 조인하기 전에도 기본적인 데이터들을 꽤 다루어 보았고, 멀티 코어 정도의 병렬화, compiler optimzation 등, 조금 더 나아가서 그래픽 처리장치의 기술들 정도를 다루어 보았더랬다. 기술 보다는 인내심의 영역으로 이해하며, 여전히 하나의 함수 내에서 여러 가지 일들을 하는 게 익숙하던 시절, 빅테크 구글에 조인하면서 이전과는 다른 말로만 듣던 대용량 데이터들을 접하게 되었다. 사용자들의 행동들, 뭔가 printf로 남겨서 확인하던 그런 것들을 로그라는 이름으로 모아서 저장하고 있었고, 이걸 힘 닿는 대로 분석해서 다음 전략들을 짜는 게 시작이었다.

Log 는 통나무, 이걸 결대로 잘라서 하나씩 분석한다는 의미로 해석을 하고 있었고, 영어 책에서만 보던 Saw 를 하고 있는 셈이었다. 이걸 분석하기에 전문화된 언어를 sawzall ( .SZL ) , runtime으로 Sawmill 이 쓰였고, milldump command 는 기도하며 실행시켰던 기억들이 있다.

C 언어에서 debug 혹은 나중에 분석하려고 하는 용도로 printf 를 어디든 집어 넣을 수 있듯이, 이벤트 로그, 메시지 로그, 네트워크 로그 등등 서비스를 가리지 않고 모든 곳에서 로그라는 이름으로 쓰였고, Protocol Buffer 안에 예쁘게 모여서 그걸 기계적으로 읽어 나가며 하고 싶은 분석들을 했었더랬다. 모여서 커 보이는 것도 맞지만, 하나 하나는 대개 사용자 한 명의 소중한 흐름이기도 했으니까.. 꽤 진지하게 다뤘더랬다.

병렬처리의 단위 함수

wikipedia 에는 아래처럼 간단한 예제가 있다. 잘게 잘려진 한 단위의 것의 내부를 훑으면서 필요한 것들을 골라 내는 행동이라 아주 긴 예제를 짜거나 본 적이 있진 않다. 주로 모래바닥에서 진주를 찾는 행동들이기에 각종 condition 에 해당하는지가 중요한 부분들이고, 아닌 것들을 빨리 skip 하게 하는 게, nesting 을 줄이는 게 주요한 습관이었다. 그리고 애증의 키워드인 emit 이 있다.

똑같은 일이 수없이 반복된다면을 가정해서 만드는 로직들이었고, 원하는 것들이 뽑혀 나올 때 쾌감이 있고, 그만큼 의심도 많이 했었다. 잘 모르는 언어를 돌려서 원하는 결과가 나오다니... 이후 MapReduce 를 제대로 공부하면서 더 잘 쓸 수 있다 싶어 졌는데, 제대로 해 보고 싶을 때쯤, 신흥 언어인 golang 과 lingo(Log in go) 라고 불리던 runtime 으로 대체되며 시대의 저편으로 흘러갔다. golang 은 다른 글에서...

데이터 분석 파이프라인을 구동시키면 대개 1000 개 정도의 기계를 동시에 구동시키는 경험들을 하게 된다. 괜히 엔터 한 방에 1000 개의 것들이 위잉 하며 실행되는 상상도 해 보고, master instance 를 계속 refresh 해 보며 기도했던 순간들, 당연하게(?) 한두곳에서 에러 나면 그것 때문에 다시 처음부터 하나씩 해 보았던 것들이 기억이 난다.

비슷한 용어들

미국에서 10년 넘게 살지만, 실제 저 톱질은 여전히 영화에서나 보는 다른 사람들의 일상이다. 한국어로 번역해 보자면 나무꾼에 해당하겠다 싶은데, 계속 업에 있으면서 관련된 제품으로 혹은 서비스들로 용어들이 종종 보이곤 한다. 흠칫 하면서도 낭만이 넘치는 거 같아서 반갑다.

Flume : Hadoop, Mapreduce 에서

Logstash : ELK 의 L

Lumberjack : 수집기

Chainsaw : log4j viewer

Timber : Android log...

...