최근 Apache Zeppelin 프로젝트 최신 버전 빌드에 문제가 생겨서 버그리포트를 기여하였다. 이 과정을 회고한다.

결과

결과 부터 보자면 다음과 같다.

Apache 재단 Jira에 버그 리포팅

결과적으로 배포판이 수정되었다.

처음으로 StackOverflow에 답변

위와 같은 질문이 올라왔고

이렇게 답변을 달아줬다.

결과적으로는 내가 알려준 파일을 지우고 실행하자 잘 된다는 답변이 왔다.

기여 과정

총 3번의 삽질이 있었고, 그 중 맨 마지막에서 빌드 버그를 찾았다.

무엇을 하려고 했었나?

Apache Zeppelin에서 Spark를 Yarn 위에서 실행시키려고 하였다.

삽질 1 : JAVA_HOME관련 에러

Yarn 컨테이너라고 해서 도커 컨테이너를 생각하면 안된다.
파일시스템과 프로그램들이 실행되는 호스트에 종속된다.(너무 불편...)

약간 이런식으로 진행 되는데,

• 제플린 서버에서 실행파일과 관련 파일들, 환경 변수, 쉘 스크립트 들을 압축한다
• 이를 Hadoop hdfs에 업로드 한다.
• 각 노드들은 이를 다운 받아 tmp 디렉토리에 저장하고 각자 실행한다.

근데 문제는 라즈베리파이는 arm, 인텔 pc는 amd 아키텍쳐라는 것이었다. 따라서 JAVA_HOME 경로가 달라서 에러가 났었다.

결과적으로는 소프트 링크로 경로를 통일하여 해결했다.

삽질 2 : 통신 문제

위와 같이 했는데도 실행이 안되었다. 이번에 통신 문제였다.
에러 내용은 RPC 관련해서 응답이 없다는 것이었는데,

이를 해결하기 위해 소스코드를 다운 받아 디버깅 하였다. 다행히 나의 주 언어인 JAVA로 되어있어 편했다.

코드 분석 결과 위와 같은 구조로 되어있었는데, 다양한 인터프리터를 제플린 서버가 실행하고 연결하는 구조였다.

그 중 spark 인터프리터는 위와 같은 구조였는데, 인터프리터가 가능한 포트로 Apache Thrift 서버를 띄우고 이 호스트와 포트를 제플린 서버에 등록하는 방식이었다.(Apache Thrift 서버는 facebook에서 만든 멀티 언어 RPC 서버다)

문제는 뭐였냐면, 아래 코드를 보면 알 수 있다.

이 메서드가 문제였는데, 보면 알겠지만, 가능한 네트워크 인터페이스 중에 루프백(로컬호스트)가 아닌 것 하나를 고르는 메서드 이다. 바로 이 호스트를 가지고 advertise(제플린 서버에 알려주는 것)하는 것이었다.

하지만 나의 인터페이스들 중 맨 마지막인 도커의 가상 네트워크 인터페이스 주소를 골라서 광고를 하는게 문제였다.

결과적으로는 위와 같은 문제였다.

해결한 과정은 위 코드에 보면 랜덤으로 선택하기 전, ZEPPELIN_LOCAL_IP라는 환경변수를 체크하는 것을 볼 수 있는데,
yarn 설정에서 이 환경변수를 불러오도록 설정하고, 각 호스트에 맞는 ip를 환경변수로 등록하여 해결하였다.

삽질 3 : 빌드 오류를 찾아내고 기여하다.

이렇게 까지 했는데, 또 안되었다. 🤣

이 에러에서 jar 파일에 대한 압축 해제가 안된다는 것을 알 수 있었고, yarn 컨테이너에 직접 접근해서 파일을 확인 해 보았다.

이상한 점은 실행하려고 하는 jar파일이 너무 사이즈가 작다는 점과 거의 비슷한 jar파일이 하나 더 있다는 것이었다.(zeppelin은 ._으로 시작하는 jar를 열려고 하였다.)

cat을 통해 출력해보니, 애플과 관련된 글자들이 튀어나왔다.

그래서 빌드하시는 분이 맥을 사용하고, 맥 메타데이터 파일이 같이 딸려 들어간 것이 아닌가 라고 유추하게 되었다. 다른 버전의 릴리즈도 확인 해 보았고, 다른 버전에는 이러한 ._으로 시작하는 파일이 보이지 않았다.

회고

이러한 과정을 통해 버그를 찾게 되었고, Apache 재단에 가입해 jira로 버그를 리포팅 하였다. 또 Stack Overflow에 가서 문제를 겪는 사람에게 ._으로 시작하는 파일을 지우라고 조언을 해 주었다.

결과적으로는 릴리즈가 수정되었다.

사실 오랜시간 삽질을 하는 불쾌한 경험이었지만, 직접 소스코드를 까보고, 디버깅하고, 리눅스 기반으로 파일을 뒤져보고 유추해 보는 등 의미있는 활동도 해 볼 수 있었던거 같다.