데이터 인프라는 K8s에 올라가있는게 좋을까 (진짜모름)

회사에서 쿠버네티스를 만지면서 든 생각이다. 데이터 인프라를 K8s 에 올리는게 과연 좋을까?

아무것도 모르는 사람이 데이터 파이프라인을 구축한다면?

데이터 파이프라인 토이프로젝트로 흔히들 하는 ELK

일반적으로 ELK스택을 구축하는 토이프로젝트를 한다면 어떻게 환경을 구성하는게 나을까?

AWS에서 EC2서버를 4개 띄운다음에, 인바운드-아웃바운드로 포트 뚫어주고, 인스턴스끼리 서로 통신할수 있도록 환경을 만들것같다.

그리고 인스턴스에 Beats(데이터 소스역할), Logstash, ES, Kibana 를 설치하고 연결한 데이터파이프라인을 만들것같다.

 

일반적으로 프로그램은 두가지 방식으로 설치한다

위 상황에서 일반적으로 프로그램을 설치하는 방법은 2가지의 방법으로 나뉘는거같다.

첫번째 방법은 apt-get 같은 패키지명령도구를 사용하는것이다

mac에서 사용하는 Brew

 

두번째 방법은 tar 파일을 다운로드받아서, 직접 압축을 푸는것이다

wget 을 사용해서 tar, tar.gz을 다운받아서 사용한다

 

두가지 방식은 서로 다른 특징을 가지고있다.

 

첫번째 방식은

기존에 프로그램을 적용하기 위한 옵션들이 디폴트로 설정되어있는 경우가 많아서, 빠르게 구축해야할때 편했다. 그리고, 관리해야할 파일의 갯수 자체가 적었던것같다.

근데, 이게 은근히 불편했다. 예를들어 프로그램 전체의 데이터 경로를 /data 처럼 임의로 지정해주고싶은데, 디폴트로 만들어지는 경로가 /Users/get/opt 이런 이상한 경로로 지정되어있으면, 재설정해주지않으면 관리할 포인트가 늘어나게 되더라. 그래서 모든 경로나 옵션같은걸 통합시켜주려고하다보니 일이 한두가지 느는게 아니였다.

 

가장 문제였던점은 사실 프로그램 1개가 설치될때, 관련 파일이 여러곳에 흩뿌려져 설치된다는것이였다. 실행 스크립트는 Users에 있고, 설정파일은 root에 있고, 데이터 로그는 opt/data 이렇게 중구난방으로 설치되어있으면 관리할때 멘붕이었다. 나는 이게 제일 불편했다.

 

그럼에도 가장 좋았던 점은 system daemon으로 등록해야할때 매우 편했다는것이다. 프로그램을 시스템 데몬으로 등록하면 인스턴스를 재부팅할때, 시스템 데몬으로 등록한 프로그램을  자동으로 다시 띄워준다. 나는 시스템 데몬으로 등록할때 너무 편해서 좋았다.

 

 

두번째 방식은

첫번째방식과 정 반대이다. 프로그램을 다운로드받고, 압축파일을 풀고, 관련설정파일을 전부 지정하고, 실행스크립트를 실행하는 방식이다.

프로그램을 띄우기 위한 옵션 하나하나를 전부다 지정해줘야해서, 불편함이 있었지만 관련된 모든 옵션을 손수 하나하나 지정해줄수 있었다. 이게 오히려 처음 설치할땐 불편하지만, 관리할때는 너무 편했다.

물론 단점도 있다. 시스템데몬으로 등록할때 너무 불편했다. 시스템데몬에 등록하기 위해서는 등록스크립트가 필요한데,  스크립트를 못만들어서, 시스템 데몬등록을 포기할때도 많았다. 그래서 어쩔수없이 첫번째 방식으로 진행할때도 있었다. 

 

그럼 도커로 띄우는건 어떨까?

사실 나는 도커를 써본적은없지만, 도커로 띄우는게 매우 좋은것같다.

VM, Container 의 차이점을 설명할때 많이 보이는 그림

 

물론 프로그램을 VM에 설치하는 사람이, 갑자기 Container로 띄울려고 한다면 Docker에 대한 학습이 필요한것은 당연하다. 근데 어느정도의 러닝커브만 감수할수 있다면, 도커로 띄우는게 매우좋다고 생각한다.

 

내가 좋다고 생각하는 이유는 설치-제거 에 대한 부담이, 앞에서 설명한 두가지의 방법보다 줄어들기때문이다.

Dockerfile만들고, 이미지는 Docker-hub에서 다운로드받을거고, 여러개를 띄워야하면 Docker-Compose쓸거고, 컨테이너가 뜨고 죽을때 데이터손실이 걱정된다면 볼륨마운트를 시켜주면 된다. 프로그램 띄울땐 up시켜주면되고, 프로그램 내릴땐 down 시켜주면된다.

 

그럼 도커로 띄우는게 무조건 좋을까?

패키지 매니져와 도커로 띄우는 방법은 성능상에서는 확실히 차이가 있을거다.

 

패키지 매니저로 설치하는 방법은 Host OS에 직접 설치되며, 서비스로 실행되어 OS의 service manager에 의해서 관리된다.

Docker Container로 설치하는 방법은 Container application의 형태로 Docker환경 내에 설치된다. 이는 Host OS와는 분리된 컨테이너에서 실행된다.

 

도커로 띄운다면 다양한 OS, 다양한 시스템 상관없이 동일한 기능을하는 컨테이너를 띄울수 있겠지만, 결국 컨테이너계층때문에 오버헤드가 발생할거기때문에, 적은갯수를 설치할때는 패키지매니져로 설치하는게 오버헤드가 없을것이다.

물론 컨테이너화 성능 오버헤드는 도커쪽에서 최적화되지않을까 싶다.

 

 

그럼 쿠버네티스(Kubernetes, k8s) 로 띄우는건 어떨까?

내가 경험해본 쿠버네티스의 가장 좋은점은 HA와 desired state 라는거다.

우리가 일반적으로 알고있는 VM을 쿠버네티스에서는 Node라고 말하는데, 쿠버네티스는 여러대의 Node를 구성할수 있기떄문에 HA(High Availabilty, 고가용성) 이 유지되는것이다.

 

정확한설명은 아니지만, 프로그램은 쿠버네티스에서 Pod라는 애로 띄워지는데, 만약 Pod에 장애가 일어나서 프로그램이 제 역할을 못하고있으면, 금방 새로운 Pod가 떠서 프로그램 제 역할을 하게한다. 이게 Desire State 라고 생각한다.

 

앞서말한 HA와, desire state때문에 K8s로 프로그램을 띄우는게 매우 좋은것같다. 근데, K8s에 데이터 파이프라인을 띄웠을때 가장 불편했던점은, K8s에 대한 러닝커브 측면이다.

 

쿠버네티스 러닝커브

성능에 대한 고민을 하는게 맞는데, 그것보다 현실적인 고민을 하게 되더라.

내가 데이터파이프라인을 구성할때는 팀에 K8s를 다뤄본사람 아무도없었고, 데이터 파이프라인을 다룰수있는 사람 또한 나밖에 없었다. K8s 자체에 대한 진입장벽이 매우 높다보니, 처음 K8s를 다뤄볼때 너무 어려웠다.

 

K8s 환경을 잘 알아야하고, 기존에 Package manager로 설치한 프로그램, 파일을 다운로드받아서 실행한 프로그램, Docker로 띄운방법을 전부 정리해서 K8s로 띄워야하니까 이것또한 만만치않았다.

지금도 K8s에서 데이터파이프라인작업을 진행하고있지만, Pod-Pod, Pod-Node, Node-Node같은 통신같은 부분은 아직도 이해안가는 부분이 많다.

 

 

데이터파이프라인(어려움) + K8s(더어려움) ⇒ 진짜 미친듯이 어려움

 

이왕 이렇게 된거 K8s에다가 다 올리자

어느정도의 러닝커브가 있지만, K8s에 조금 익숙해진 입장에서는 모든프로그램을 K8s에 올리는건 좋은것같다. (물론 아직 성능에 대한 이슈는 고려하지 않는다)

 

Desire state측면도 좋은것같고… Airflow에서도 KubernetesPodOperator 같은걸 지원하고있고.. Spark를 도입해야할때도 리소스매니져로 Yarn, Mesos에 대한 걱정을 하는것보다 Spark on K8s 의 형태로 올려버리면 고민이 조금 해결되지않을까 하는생각이 있다.

 

물론 아직도 네트워크 통신이나, 쿠버네티스 성능을 100% 사용하는 방법에 대해선 많이 부족하다.

그치만, 좀더 공부해면 잘 쓸수 있을것같다.

 

여담으로, 지금은 Spark on K8s에 대한 고민을 하고있다. 스파크 연산이 파드 내부에서 작동하는거라서 연산할때 어렵다는데, 어떻게 하는게 옳은가에 대한 고민을 하고있다. 회사에서는 '이정도의 데이터셋인데 스파크를 쓰는게 맞나?' 에 대한 고민을 한다는데... 어지럽다...