adtech_so
171
2019-02-24 23:49:44 작성 2019-02-25 00:20:15 수정됨
2
1760

거대한 기술적 부채를 해결하기 위해서 걸어온 반년간의 이야기 (3-1)


3. 데이터 집계(Spark)


> Spark에 대해서


데이터 집계부분은 1년전 쯤에 Hadoop에서 Spark로 마이그레이션되었고, cluster 도구로서 GCP의 Dataproc을 사용하고 있었습니다.

- https://cloud.google.com/dataproc


Spark는 하나의 master node(cluster manager)와 복수의 worker node로 이루어진 구조이며 데이터를 분산하여 연산하도록 도와주는 플랫폼입니다. 메모리 기반 연산이기때문에 디스크 기반 연산인 Hadoop보다 매우 빠른 특징이 있습니다. Cluster manage로서 Hadoop의 YARN(리소스나 스케줄 관리 등)을 사용하는 것이 일반적이구요. 사용할 수 있는 언어는 Scala, Java, Python이 있으며 저희 서비스는 Scala로 구현되어 있었습니다.

- https://spark.apache.org


아래는 Dataproc을 이용하여 cluster를 생성하고 특정 job을 실행하며 job이 완료되고 난 후 cluster를 삭제하는 흐름을 스크립트로 기재한 내용입니다. cluster의 이름이나 zone, 각 머신의 종류와 디스크 용량 그리고 worker node의 수 등을 지정할 수 있는 옵션들이 용의되어 있습니다. 그리고 이런 cloud 서비스를 이용하기 전에는 대략 어느정도 비용이 소모되는가도 정리하는 것을 추천드립니다. Dataproc의 경우, worker node가 복수로 생성되기 때문에 GCE에 대해서 추가요금이 발생하므로 주의가 필요합니다.

- https://cloud.google.com/dataproc/pricing


gcloud dataproc clusters create ${CLUSTER_NAME} \
	--bucket ${BUCKET_NAME} \
	--zone ${ZONE_NAME} \
	--master-machine-type ${MASTER_MACHINE_TYPE} --master-boot-disk-size ${MASTER_DISK_SIZE} \
	--worker-machine-type ${WORKER_MACHINE_TYPE} --worker-boot-disk-size ${WORKER_DISK_SIZE} --num-workers ${WORKER_NUM} \
	--image-version ${DATAPROC_VERSION} \
	--project ${GCP_PROJECT_NAME}

gcloud dataproc jobs submit spark \
	--cluster ${CLUSTER_NAME} \
	--class ${MAIN_CLASS_NAME} \
	--jars ${JAR_PATH} -- ${PARAMETER1} ${PARAMETER2}

gcloud dataproc cluster delete ${CLUSTER_NAME} --quiet


Dataproc을 통해 실행되고 있거나 완료된 jobs의 정보를 파악할 수 있는 페이지를 제공합니다.

- https://console.cloud.google.com/dataproc/jobs


Dataproc을 사용할 때 주의할 점

- 동명의 cluster가 실행되고 있을 때에 재차 cluster를 생성할 경우에는 오류가 발생합니다. 그렇기 때문에 cluster 생성이나 job에서 오류가 발생했을 시에는 반드시 cluster를 제거해주도록 하여 retry job이 정상적으로 실행될 수 있게 하는 error handling 처리가 필요했습니다.

- GCP에서는 각 서비스마다의 사용량을 제한하고 있으며 초과할 경우에는 더 이상 이용불가능한 상태가 된다는 규칙이 있었습니다. 대규모 기반의 서비스라면 정기적으로 이용량을 확인해주는 작업이 필요하다고 생각합니다.

  - https://console.cloud.google.com/iam-admin/quotas


> 까다로운 고객


대략적으로 Spark의 구조나 Dataproc의 사용법에 대해 이해했다고 생각하여 실제 코드 부분을 읽어보기 시작하였습니다. input / output에 대한 문서가 존재하지 않았기때문에 직접 UML을 그려가면서 코드 리딩을 진행했고, 선임자분에게 비교적 잘 정리된 문서라고 인정받아 README에 링크가 추가되어 약간의 보람을 느꼈습니다.


정리하면서 느꼈던 것이지만 특정 고객에 대해서만 데이터 집계를 따로 하고 있는 점이 이해가 가지않아서 여기저기 조각난 문서들을 찾아본 결과 상당히 무서운(?) 고객이었습니다. 매출 대비 비율로 볼 때 어느정도 상위에 위치한 고객이었지만 부정 데이터에 관해서 자그마한 데이터 불일치가 발생한 경우, 해당달에 관해서는 돈을 한 푼도 지불하지 않은 전례가 있었습니다.


하지만, 위의 처리 때문에 하나의 작업에 대한 의존성이 복잡해지는 문제가 초래되고 있었고 집계된 데이터도 시간단위로 필요한 상황이 아니었기때문에 Spark보다는 Big Query 상에서 상대방의 요구가 있을 때 간단하게 Query로 데이터를 집계하는 편이 모든면에서 월등히 좋다는 의견을 멤버들에게 피력하여 까다로운 고객에 대한 처리를 제거하는데 성공하였습니다.


무조건 기존에 정해져 있는 로직을 신뢰할 것이 아니라 다른 시각으로 바라보고 생각하여 좀 더 간단하고 효율적인 방법이 있다면 자신이 가지고 있는 생각을 주변인들에게 내어보이는 행위도 필요하다는 것을 느꼈습니다.

1
0
  • 댓글 2

  • abilists.com
    739
    2019-02-25 13:06:16

    Spark 사용해보지는 못했는데, Hadoop를 구축하고, Hbase를 통해서 통계관련 프로그램을 개발해봤는데, 이것으로 상용 어플 만들면 좋겠다고 생각한적이 있었네요. 좋은 글 감사합니다.

    0
  • adtech_so
    171
    2019-02-26 20:11:29

    abilists.com Hadoop을 다뤄보셨군요. Spark가 의외로 SQL 지식이랑 함수형 프로그래밍 기초정도 있으면 어느정도 이해는 되더라구요. 한 번 만져보시는걸 추천드립니다.

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.