[SLASH24]토스뱅크 오픈소스로 Hadoop 클러스터 구축기 정리

배경

• 클러스터를 왜 다시 구축하게 되었는가

• 토스뱅크의 초창기에는 임팔라와 HUE를 통해서 빅데이터를 다루었음
• 인증은 엑티브 디렉토리, 인가는 아파치 센트리를 통해서 제공
• 임팔라가 대화형 쿼리에 장점이 있었지만 모든 문제에 만능은 아니었기에 사용자들이 한계를 느꼈지만 다른 도구들은 보안을 적용하기에 제한이 있었고 

• 그래서 하둡 클러스터 전반적으로 보안을 적용해서 액티브 디렉토리에 케베로스를 추가했고 아파치 레인저를 통해 모든 서비스에 인증 인가가 붙도록 변경함
• 결론적으로 임팔라 뿐만이 아니라 빅데이터 문제를 풀기위해 알맞은 솔루션을 사용자들이 선택하여 사용할 수 있도록 만들었음

오픈소스만을 사용하여 Hadoop 클러스터 구축하기

• 이런 새로운 오픈소스 프로젝트를 배포하고 관리하기 위해서 Apache Bigtop, Ansible, Apache Ambari를 사용해서 빌드와 하둡 클러스터에 설치를 하게 됨

• 빅탑은 하둡 패키지들을 빌드하는데 사용됨 사내 깃 저장소에서 소스를 받아와서 빌드를 하고 사내 레포에 업로드하고 ambari가 설치된 장치들에 패키지를 설치하도록 되어있음
• ambari는 마스터 워커 구조로 되어있고 마스터에서 하둡 컴포넌트 설치, 중지 명령을 내리게되면 워커들이 이 명령들을 수행하는 구조로 되어있음
• Ansible은 호스트를 프로비저닝하는데 사용됨, 커널 파라미터 튜닝, ssh키 셋팅, 시스템 셋팅 데몬 등
• 하지만 왜 직접 빌드해서 사용하는가?
  • 바이너리 파일을 제공하지 않는 경우도 있음
  • 업그레이드를 하긴 어렵고, 패치를 필요한 상황이 있음
  • 복잡한 버전 의존성

오픈소스 따라가며 Hadoop 클러스터 유지보수하기

• 코드만 가져오지 말것→ git 히스토리까지 그대로 가져오기(커밋이 고정된 release tag쪽에서 가져오기)
• 패치가 있지만 업그레이드하기 어려운 경우→특정 패치 버전의 commit hash를 알아서 - cherry-pick 명령어를 통해서 커밋하고 conflict가 생기면 알맞게 해결한 후 특정버전의 패치만 반영
• 하둡에 kerberos인증을 적용하고 프로메테우스 매트릭을 수집할때 인증을 빼고 수집할 수 있는 화이트리스트 기능이 있는데 리소스 매니저와 잡히스토리 서버에는 적용이 되지않는 버그가 있었음→ 이 부분을 먼저 사내에서 수정해서 사용하고 있었는데 upstream에도 반영해서 오픈소스 기여로 후반영하게 됨

오픈소스 기여 사례 공유

• Cloudera HUE
  • 사용자 권한이 아닌 hue 계정의 권한으로 접근하는 문제 발견→ 접속한 사용자의 권한으로 HDFS file browser를 사용할 수 있도록 수정
• Apache Hadoop
  • NameNode audit 로그가 압축되지 않아 디스크를 너무 많이 차지하게 됨
  • log4j rotate 시에 gzip  압축을 사용하도록 개선
  • 로그 롤링은 잘되고있었지만 압축이 되도록 수정
• Apache Spark
  • hadoop auth_to_local이라는 설정이 있음 excutor쪽에서 kerberos의 full principal name이 보존되지 않는 문제가 발생
  • https://issues.apache.org/jira/browse/SPARK-44976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759201#comment-17759201

• 오픈소스에 어떻게 기여하나?
  • 프로젝트마다 나름의 규칙이 있고 공식 문서 및 readme.md 등을 참고하여 기여
  • 보통은 jira 티켓이나 PR리뷰를 통해 기여함
• 오픈 소스 기여시 장점은 바로 리뷰→내부 코드에도 production 수준에 맞는 수준으로 반영하는데 도움이 됨(메인테이너나 리뷰어들에게 피드백을 해줌)

클러스터 전환간 알게된 사실

• 레인저는 중앙에 레인저 어드민이 있어서 운영자가 레인저 정책을 레인저 어드민에 적용하면 각 서비스 플러그인에 이 정책이 옮겨가서 인가가 알맞게 적용되는 방식

• 임팔라로 예를 들어보면 레인저 임팔라 플러그인에 하둡 sql 정책이 적용되게 되고 HDFS를 읽어들일 때는 레인저 HDFS 플러그인을 통해서 HDFS 정책이 적용되게 됨
• 레인저의 한계→ 테이블 레벨까지만 되고 컬럼 레벨까지는 제어가 안됨→ 컬럼 레벨까지 제어하고 싶다면 사용자에게 HDFS 권한을 빼서 Spark를 사용하지 못하게 막고 사용하는 쿼리엔진에서 Ranger를 통해 제어하도록함

요약

• Bigtop + Ambari + Ansible → Hadoop 클러스터 구축 및 운영
• 오픈소스 코드까지 따라가기
• 오픈소스는 꽁짜가 아니다→ 기술을 follow해야하는 인원들이 필요함
• 오픈소스로 주도적인 클러스터 운영

느낀점

• 하둡 에코스스템 내에서 어떻게 인증과 인가를 관리하는지에 대해서 알게되어서 보안이 가장 중요한 금융 도메인에서는 각 사용자들이 데이터를 접근할 때 그리고 데이터를 다룰 때 어떻게 구성해야하는가에 대해서 알게되었다.
• 오픈소스를 사용하는 측면에 대해서는 나름 많은 오픈소스 프로젝트를 구축하고 사용해보면서 체감은 했지만 기여에 대해서 생각해본 적은 거의 없었는데, 최근들어 여러 영상이나 커뮤니티에서 오픈소스 프로젝트에 대한 이야기를 들을 일이 많아졌다. 아래 첨부한 유튜브 영상도 그 내용중에 하나고. 내용은 오픈소스 컨트리뷰터로 활동하면서 개발자로서 성장과 동시에 커리어로도 함께 성장이 이루어졌다는 내용인데. 실제로 내가 직접 사용하는 프로젝트에 기여하고 내가 기여한 프로젝트가 실제로 많은 사람들이 사용하고 교류가 이루어진다면 그것이 커리어와 실력의 향상을 떠나서 뿌듯한 일이 될 것이라는 생각이 든다.

https://youtu.be/QbDpdjSWnmI?si=H3KgsL8CdhL1_DW6

 

• 올해 아주 작은 기여부터 하나씩 시작하는 것을 목표로 이전과 다른 시선으로 오픈소스 프로젝트를 바라보며 내가 기여할 수 있는 방향을 모색해야겠다.