comcast4-lambda-parallelization

AWS 는 많은 서비스를 제공하고 있읍니다. 많은 서비스들을 써봤지만, 제가 가장 좋아하는 써비스는 Lambda 입니다.

Lambda 자체로는 많은 제약이 있읍니다. 가장 큰 두가지의 제약은 시간과 공간입니다. 일단 Lambda 는 15분의 시간 제약이 있읍니다. 15분 넘게 Lambda를 돌릴 수는 없읍니다. 또하나는 공간의 제약입니다. 제 기억으로는 Local Storage 크기가 10G 미만으로 기억합니다.

메모리 크기를 크게 함으로써 Lambda CPU 크기도 커지긴 하지만, Lambda 자체 만으로 엄청난 계산을 하는 것은 불가능 합니다.

Lambda 자체로는 커다란 계산을 할 수는 없지만, Lambda 를 다른 AWS 서비스의 매개체로 사용하게 되면 그 편의성이 크게 드러납니다.

제 경우는 Lambda 를 데이터 프로세싱 자동화에 많이 쓰고 있읍니다. 간단한 데이터 사용가능성 체크, 그리고 EMR 을 가동한다든지, Lambda 를 활용한 자동화는 정말 무궁무진 합니다.

어느날 회사 동료 하나가 그의 Python 코드를 Spark 를 이용해서 병렬 처리를 하려고 하더군요. Spark 는 데이터 프로세싱에는 적합하지만, 병렬 처리에는 문제가 있읍니다. 왜냐하면 Spark 의 Executor는 비싸고 따라서 많은 Executor 를 동시에 돌리면 Master 와의 통신량도 무시할 수가 없읍니다. 저는 그의 코드를 Lambda 를 써서 해결했읍니다. 그가 원하는 Python 코드는 15분안에 도는 것이었고, 100K 이상의 병렬 처리는 Spark는 그리 좋지 않았읍니다. AWS의 SNS 그리고 Lambda 를 써서 그가 돌릴 수도 없었던 그의 코드를 저는 15분 만에 돌아가게 만들었읍니다. 하지만, 이것은 또하나의 문제를 야기하죠. 이렇게 많은 Lambda 들이 동시에 Launch되면 AWS 어카운트 전체에 문제가 발생합니다. 여러분이 모르는 사이에 곳곳에 AWS가 Lambda 를 쓰기 때문입니다. 이것은 제가 다른 방식으로 해결을 했읍니다. Spark 는 정말 MapReduce 를 사장시킨, Hadoop의 데이터 병렬처리의 해결사 이지만, 단순한 Compute 병렬 처리에는 그리 적합치 않습니다. Lambda 를 사용한 병렬처리가 훨씬 유용하죠. 요새는 Ray 같은 것들을 이용하는 것도 좋은 방법입니다.