안녕하세요. 보이스루입니다.
“Connected Every Culture” 글로벌 번역 시장을 새롭게 정의 내리고 있는 보이스루 테크 그룹의 이야기를 전하는 Tech Blog입니다.
들어가며
안녕하세요. 보이스루 Data 팀의 Data Engineer 조승현입니다.
보이스루 Data 팀은 서비스에서 발생하는 데이터를 기반으로 유의미한 결과를 도출하여 보이스루가 나아갈 방향에 지표를 제공하고 있습니다.
저는 Data Engineer로서 이러한 데이터들의 수집, 적재 등 전반적인 데이터 파이프라인을 관리하는 역할을 수행하고 있습니다.
지난 1편에서 보이스루가 신중하게 고민했던 BI(Business Intelligence) 도구들을 소개했고,
여러 후보와 이유들을 설명하며 Apache Superset을 선택했다고 알려드렸습니다.
오늘은 그다음 이야기 ‘Apache Superset 배포하기’를 소개하겠습니다.
Apache Superset 배포하기
출처: https://www.startdataengineering.com/post/apache-superset-tutorial/
Apache Superset은 웹 서버, 데이터베이스, 캐시 레이어 등 여러 컴포넌트로 구성되어 있습니다.
설치 및 관리에 꽤 많은 리소스가 소모될 수 있지만, 다행스럽게도 Apache Superset은 Kubernetes(이하 K8S) 환경에 배포할 수 있도록
헬름 차트를 제공하고 있습니다.
*Helm: 헬름은 쿠버네티스 차트를 관리하기 위한 도구이다.
헬름은 charts라는 패키지 포맷을 사용한다.
차트는 쿠버네티스 리소스와 관련된 셋을 설명하는 파일 모음(패키지)이다.
헬름은 패키지 관리 도구고, 차트는 리소스를 하나로 묶은 패키지에 해당한다.
헬름으로 차트를 관리하는 목적은 자칫 번잡해지기 쉬운 매니페스트 파일을 관리하기 쉽게 하기 위한 것이다.
출처: https://github.com/apache/superset/releases
보이스루의 서비스는 대부분 AWS EKS, 즉 K8S에 배포되어 사용자에게 제공되고 있습니다. Apache Superset 또한 제공되는 헬름 차트를 이용해 K8S에 배포하여 기존 인프라를 활용하면서 여러 컴포넌트들을 한눈에 관리할 수 있도록 구성했습니다.
커스터마이징
Apache Superset에서 제공하는 헬름 차트는 매우 유용하지만 그대로 사용하기에 부족한 부분들이 몇 가지 있는데요.
저희는 보이스루에 맞게 4가지 커스터마이징을 진행했습니다.
DataBase
헬름 차트에서 제공되는 컴포넌트들에는 메타 정보를 관리하는 데이터베이스도 포함되어 있습니다.
이렇게 기본으로 제공된 데이터베이스를 그대로 사용하면 헬름 차트를 재배포할때 관련된 메타 정보들이 모두 사라질 위험이 있습니다.
또한, 보이스루에서는 모든 데이터베이스를 AWS의 RDS를 사용하고 있기 때문에
서비스에 사용되는 데이터베이스를 통합적으로 관리할 필요성도 느꼈습니다.
따라서 메타 정보 데이터베이스를 조금 더 안정적으로 유지하고 서비스 데이터베이스들을 통합적으로 관리하기 위해
메타 정보 관리용 데이터베이스는 AWS RDS를 사용하기로 하였습니다.
Apache Superset 헬름 차트는 이러한 컴포넌트 교체도 원활하게 수행할 수 있도록 구성되어 있습니다.
생성한 RDS의 host 값을 values.yaml 파일에 추가하면 됩니다.
## Configuration values for the postgresql dependency.
## ref: https://github.com/kubernetes/charts/blob/master/stable/postgresql/README.md
postgresql:
##
## Use the PostgreSQL chart dependency.
## Set to false if bringing your own PostgreSQL.
enabled: false
##
## The name of an existing secret that contains the postgres password.
existingSecret: superset-postgresql
## Name of the key containing the secret.
existingSecretKey: postgresql-postgres-password
##
## If you are bringing your own PostgreSQL, you should set postgresHost and
## also probably service.port, postgresqlUsername, postgresqlPassword, and postgresqlDatabase
postgresHost: xxxxxx.xxxxxxxxx.ap-northeast-2.rds.amazonaws.com
superset_helm_values_for_db.yaml
OAuth
따로 계정을 생성하지 않아도 회사 계정을 통해 접근할 수 있도록 OAuth를 적용했습니다.
보이스루 회사 계정은 모두 구글 계정을 이용하고 있습니다.
Google Cloud Platform에서 새로운 프로젝트를 생성하고 해당 프로젝트에 OAuth 클라이언트 ID를 생성하면
Apache Superset에 OAuth를 적용할 수 있습니다.
Apache Superset에는 이미 OAuth 기능이 구성되어 있고, superset_config.py에 GCP에서 생성한 OAuth 관련 정보들만 입력해주면 됩니다.
from flask_appbuilder.security.manager import (AUTH_DB, AUTH_OAUTH)
AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
{
"name": "google",
"whitelist": [ "@voithru.com" ],
"icon": "fa-google",
"token_key": "access_token",
"remote_app": {
"client_id": "********************************.apps.googleusercontent.com",
"client_secret": "********************",
"api_base_url": "https://www.googleapis.com/oauth2/v2/",
"client_kwargs": {"scope": "email profile"},
"request_token_url": None,
"access_token_url": "https://accounts.google.com/o/oauth2/token",
"authorize_url": "https://accounts.google.com/o/oauth2/auth",
}
}
]
# Map Authlib roles to superset roles
AUTH_ROLE_ADMIN = "Admin"
AUTH_ROLE_PUBLIC = "Public"
# Will allow user self registration, allowing to create Flask users from Authorized User
AUTH_USER_REGISTRATION = True
# The default user self registration role
AUTH_USER_REGISTRATION_ROLE = "Jamake"
superset_config_for_oauth.py
이처럼 Apache Superset 내부에서 설정 변경이 필요한 경우 superset_config.py에 반영하면 되는데,
K8S에 배포하는 경우 values.yaml에서 configOverrides에 위와 같은 설정값들을 전달해주면 됩니다.
from flask_appbuilder.security.manager import (AUTH_DB, AUTH_OAUTH)
AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
{
"name": "google",
"whitelist": [ "@voithru.com" ],
"icon": "fa-google",
"token_key": "access_token",
"remote_app": {
"client_id": "********************************.apps.googleusercontent.com",
"client_secret": "********************",
"api_base_url": "https://www.googleapis.com/oauth2/v2/",
"client_kwargs": {"scope": "email profile"},
"request_token_url": None,
"access_token_url": "https://accounts.google.com/o/oauth2/token",
"authorize_url": "https://accounts.google.com/o/oauth2/auth",
}
}
]
# Map Authlib roles to superset roles
AUTH_ROLE_ADMIN = 'Admin'
AUTH_ROLE_PUBLIC = 'Public'
# Will allow user self registration, allowing to create Flask users from Authorized User
AUTH_USER_REGISTRATION = True
# The default user self registration role
AUTH_USER_REGISTRATION_ROLE = "Jamake"
superset_config_values_for_oauth.yaml
CDN
Apache Superset은 페이지 요청 시 정적 스크립트 파일들이 굉장히 많이 전달됩니다.
이 때문에 페이지 로딩 속도가 느려지고 서버에 불필요한 부하가 걸리게 되며, 가끔 페이지 로딩 중 오류가 발생하기도 합니다.
이를 막기 위해 AWS에서 제공하는 CDN(Content Delivery Network) 서비스인
CloudFront를 배포된 Apache Superset 앞단에 구성했습니다.
Async Queries
BI에서 사용되는 쿼리들은 대부분 다양한 테이블을 조인하여 쿼리를 수행하기 때문에 시간이 오래 걸리고 무겁습니다.
Data Mart를 생성해서 적용하면 어느 정도 성능 개선을 이뤄낼 수 있지만
짧게는 수분에서 길게는 몇 시간까지 걸리는 쿼리를 사용해야 되는 상황이 발생할 수 있습니다.
이렇게 쿼리 수행 시간이 길어지면 Superset 웹에서 request timeout(30–60 seconds)이 발생할 수 있습니다.
내부에서는 쿼리가 수행되고 있지만, 사용자는 오류 화면을 접하게 됩니다.
출처: https://github.com/apache/superset/issues/18863
이러한 문제를 해결하기 위해 Superset에서는 비동기로 쿼리를 수행할 수 있는 Celery worker를 제공하고 있습니다.
문서에 따르면, celery worker는 하나 또는 수십개를 동시에 실행할 수 있으며 message queue를 celery broker로 구성하여
여러 celery worker들에게 쿼리를 분배할 수 있습니다.
이렇게 수행된 쿼리들은 result backend에 저장된 뒤 superset에 전달됩니다.
Celery worker의 broker나 result backend와 같은 세부 사항을 구성하려면 위에서 Oauth를 적용했던 것처럼
superset_config.py에 해당 내용을 반영하기 위해 values.yaml의 configOverrides에서 아래와 같은 내용을 추가하면 됩니다.
class CeleryConfig(object):
broker_url = "redis://localhost:6379/0"
imports = (
"superset.sql_lab",
"superset.tasks",
)
result_backend = "redis://localhost:6379/0"
worker_log_level = "DEBUG"
worker_prefetch_multiplier = 10
task_acks_late = True
task_annotations = {
"sql_lab.get_sql_results": {
"rate_limit": "100/s",
}
}
CELERY_CONFIG = CeleryConfig
superset_config_for_celery_worker.py
실사용 리뷰
Redash 서비스 종료 이후 보이스루는 Superset을 약 6개월간 사용해왔습니다.
다양한 BI 도구 중 Superset을 선택한 이유(비용, 다양한 기능, 활발한 개발 커뮤니티)는 Superset을 사용하면서 더 크게 와닿았습니다.
Superset의 비용과 다양한 기능은 이미 지난 1편 게시글에서 다뤘던 것처럼 큰 장점으로 다가왔으며,
특히 Slack에서 활발하게 커뮤니케이션이 이루어지는 덕분에 Superset을 배포하거나 사용하면서 겪는 이슈들은
대부분 Slack 채널에서 해결 방법을 찾을 수 있었습니다.
출처: https://join.slack.com/t/apache-superset/shared_invite/zt-16jvzmoi8-sI7jKWp~xc2zYRe~NqiY9Q
배포 이후 알게 된 Superset의 장점은 더 있었습니다. 제공되는 Database Driver가 매우 많다는 것입니다.
보이스루에서 사용 중인 AWS Redshift 이외에도 Big Query, Snowflake 심지어 Google Sheets에도 연결할 수 있었습니다.
덕분에 다양한 데이터 소스로부터 차트를 생성할 수 있었으며 이후 AWS Athena로의 이전도 차질 없이 진행할 수 있게 되었습니다.
출처: https://superset.apache.org/docs/databases/installing-database-drivers
많은 장점으로 인해 유용하게 사용하고 있지만 사용하면서 느낀 단점들도 몇 가지 있었습니다.
먼저 오픈 소스인만큼 배포, 관리부터 이슈 해결까지 모두 개발자의 몫이며 간헐적인 버그도 해결해야 합니다.
물론 위에서 말씀드린 활발한 커뮤니티 덕분에 빠르게 해결할 수 있었지만, 인력도 리소스이기에 관리 인원이 부족한 곳에서는 부담이 될 수 있겠습니다.
마지막으로 유저 권한 관리가 꽤나 복잡합니다.
BI 도구를 사용하다 보면 사용자별로 수정 권한이나 조회 권한을 적절하게 분배해야 하는 상황이 발생합니다.
Superset에서 기본으로 제공되는 권한을 기반으로 커스텀해 필요한 권한을 사용자에게 제공하면 됩니다.
그런데, Superset에서 다루는 권한들은 아래 사진처럼 매우 많고 세분화되어있습니다.
출처: superset roles show
조회 권한을 세밀하게 관리할 수 있다는 장점이 될 수 있겠지만, 그보다 이 부분에 대한 진입 장벽이 너무 높습니다.
Superset 공식 문서에서 자세히 다루고 있지 않아 필요한 권한을 적용하려면
커뮤니티에서 비슷한 사례를 찾아야 하는 등의 많은 시간이 소요됩니다.
이러한 장단점이 있는 Superset이지만 확실한 장점이 크게 다가왔고, 단점들도 대부분 해결할 수 있거나
현재 보이스루 상황에서는 크리티컬하지 않아 지금까지 잘 사용해왔으며 앞으로도 계속 사용할 예정입니다.
활발하게 개발되고 있는 오픈 소스이기 때문에 앞으로의 개선 방향이나 추가되는 기능들에 대한 기대가 큽니다.
마치며
BI 도구로 Apache Superset를 선택하고 보이스루 서비스와 로컬에 맞게 배포하는 과정
그리고 유익한 실사용 리뷰까지 소개해드렸습니다.
보이스루 Data 팀 Data Engineer 조승현 님의 이야기는 여기서 마칩니다.
보이스루의 BI 도구 탐색 여정, 어떠셨나요?
조직을 향한 최적의 기술을 찾으려는 보이스루 Data 팀의 노력이 돋보였습니다.
보이스루와 기술에 관심이 많은 분에게 오래도록 유익한 Tech blog로 남기를 바라겠습니다.
앞으로 전해질 더 많은 이야기를 기대해 주세요.
보이스루팀 드림.
Reference
Welcome | Superset
비즈니스 인텔리전스 — 위키백과, 우리 모두의 백과사전
Apache Superset Tutorial
“Connected Every Culture” 글로벌 번역 시장을 새롭게 정의 내리고 있는 보이스루 테크 그룹의 이야기를 전하는 Tech Blog입니다.
들어가며
안녕하세요. 보이스루 Data 팀의 Data Engineer 조승현입니다.
보이스루 Data 팀은 서비스에서 발생하는 데이터를 기반으로 유의미한 결과를 도출하여 보이스루가 나아갈 방향에 지표를 제공하고 있습니다.
저는 Data Engineer로서 이러한 데이터들의 수집, 적재 등 전반적인 데이터 파이프라인을 관리하는 역할을 수행하고 있습니다.
지난 1편에서 보이스루가 신중하게 고민했던 BI(Business Intelligence) 도구들을 소개했고,
여러 후보와 이유들을 설명하며 Apache Superset을 선택했다고 알려드렸습니다.
오늘은 그다음 이야기 ‘Apache Superset 배포하기’를 소개하겠습니다.
Apache Superset 배포하기
출처: https://www.startdataengineering.com/post/apache-superset-tutorial/
Apache Superset은 웹 서버, 데이터베이스, 캐시 레이어 등 여러 컴포넌트로 구성되어 있습니다.
설치 및 관리에 꽤 많은 리소스가 소모될 수 있지만, 다행스럽게도 Apache Superset은 Kubernetes(이하 K8S) 환경에 배포할 수 있도록
헬름 차트를 제공하고 있습니다.
출처: https://github.com/apache/superset/releases
보이스루의 서비스는 대부분 AWS EKS, 즉 K8S에 배포되어 사용자에게 제공되고 있습니다. Apache Superset 또한 제공되는 헬름 차트를 이용해 K8S에 배포하여 기존 인프라를 활용하면서 여러 컴포넌트들을 한눈에 관리할 수 있도록 구성했습니다.
커스터마이징
Apache Superset에서 제공하는 헬름 차트는 매우 유용하지만 그대로 사용하기에 부족한 부분들이 몇 가지 있는데요.
저희는 보이스루에 맞게 4가지 커스터마이징을 진행했습니다.
DataBase
헬름 차트에서 제공되는 컴포넌트들에는 메타 정보를 관리하는 데이터베이스도 포함되어 있습니다.
이렇게 기본으로 제공된 데이터베이스를 그대로 사용하면 헬름 차트를 재배포할때 관련된 메타 정보들이 모두 사라질 위험이 있습니다.
또한, 보이스루에서는 모든 데이터베이스를 AWS의 RDS를 사용하고 있기 때문에
서비스에 사용되는 데이터베이스를 통합적으로 관리할 필요성도 느꼈습니다.
따라서 메타 정보 데이터베이스를 조금 더 안정적으로 유지하고 서비스 데이터베이스들을 통합적으로 관리하기 위해
메타 정보 관리용 데이터베이스는 AWS RDS를 사용하기로 하였습니다.
Apache Superset 헬름 차트는 이러한 컴포넌트 교체도 원활하게 수행할 수 있도록 구성되어 있습니다.
생성한 RDS의 host 값을 values.yaml 파일에 추가하면 됩니다.
superset_helm_values_for_db.yaml
OAuth
따로 계정을 생성하지 않아도 회사 계정을 통해 접근할 수 있도록 OAuth를 적용했습니다.
보이스루 회사 계정은 모두 구글 계정을 이용하고 있습니다.
Google Cloud Platform에서 새로운 프로젝트를 생성하고 해당 프로젝트에 OAuth 클라이언트 ID를 생성하면
Apache Superset에 OAuth를 적용할 수 있습니다.
Apache Superset에는 이미 OAuth 기능이 구성되어 있고, superset_config.py에 GCP에서 생성한 OAuth 관련 정보들만 입력해주면 됩니다.
superset_config_for_oauth.py
이처럼 Apache Superset 내부에서 설정 변경이 필요한 경우 superset_config.py에 반영하면 되는데,
K8S에 배포하는 경우 values.yaml에서 configOverrides에 위와 같은 설정값들을 전달해주면 됩니다.
superset_config_values_for_oauth.yaml
CDN
Apache Superset은 페이지 요청 시 정적 스크립트 파일들이 굉장히 많이 전달됩니다.
이 때문에 페이지 로딩 속도가 느려지고 서버에 불필요한 부하가 걸리게 되며, 가끔 페이지 로딩 중 오류가 발생하기도 합니다.
이를 막기 위해 AWS에서 제공하는 CDN(Content Delivery Network) 서비스인
CloudFront를 배포된 Apache Superset 앞단에 구성했습니다.
Async Queries
BI에서 사용되는 쿼리들은 대부분 다양한 테이블을 조인하여 쿼리를 수행하기 때문에 시간이 오래 걸리고 무겁습니다.
Data Mart를 생성해서 적용하면 어느 정도 성능 개선을 이뤄낼 수 있지만
짧게는 수분에서 길게는 몇 시간까지 걸리는 쿼리를 사용해야 되는 상황이 발생할 수 있습니다.
이렇게 쿼리 수행 시간이 길어지면 Superset 웹에서 request timeout(30–60 seconds)이 발생할 수 있습니다.
내부에서는 쿼리가 수행되고 있지만, 사용자는 오류 화면을 접하게 됩니다.
출처: https://github.com/apache/superset/issues/18863
이러한 문제를 해결하기 위해 Superset에서는 비동기로 쿼리를 수행할 수 있는 Celery worker를 제공하고 있습니다.
문서에 따르면, celery worker는 하나 또는 수십개를 동시에 실행할 수 있으며 message queue를 celery broker로 구성하여
여러 celery worker들에게 쿼리를 분배할 수 있습니다.
이렇게 수행된 쿼리들은 result backend에 저장된 뒤 superset에 전달됩니다.
Celery worker의 broker나 result backend와 같은 세부 사항을 구성하려면 위에서 Oauth를 적용했던 것처럼
superset_config.py에 해당 내용을 반영하기 위해 values.yaml의 configOverrides에서 아래와 같은 내용을 추가하면 됩니다.
superset_config_for_celery_worker.py
실사용 리뷰
Redash 서비스 종료 이후 보이스루는 Superset을 약 6개월간 사용해왔습니다.
다양한 BI 도구 중 Superset을 선택한 이유(비용, 다양한 기능, 활발한 개발 커뮤니티)는 Superset을 사용하면서 더 크게 와닿았습니다.
Superset의 비용과 다양한 기능은 이미 지난 1편 게시글에서 다뤘던 것처럼 큰 장점으로 다가왔으며,
특히 Slack에서 활발하게 커뮤니케이션이 이루어지는 덕분에 Superset을 배포하거나 사용하면서 겪는 이슈들은
대부분 Slack 채널에서 해결 방법을 찾을 수 있었습니다.
출처: https://join.slack.com/t/apache-superset/shared_invite/zt-16jvzmoi8-sI7jKWp~xc2zYRe~NqiY9Q
배포 이후 알게 된 Superset의 장점은 더 있었습니다. 제공되는 Database Driver가 매우 많다는 것입니다.
보이스루에서 사용 중인 AWS Redshift 이외에도 Big Query, Snowflake 심지어 Google Sheets에도 연결할 수 있었습니다.
덕분에 다양한 데이터 소스로부터 차트를 생성할 수 있었으며 이후 AWS Athena로의 이전도 차질 없이 진행할 수 있게 되었습니다.
많은 장점으로 인해 유용하게 사용하고 있지만 사용하면서 느낀 단점들도 몇 가지 있었습니다.
먼저 오픈 소스인만큼 배포, 관리부터 이슈 해결까지 모두 개발자의 몫이며 간헐적인 버그도 해결해야 합니다.
물론 위에서 말씀드린 활발한 커뮤니티 덕분에 빠르게 해결할 수 있었지만, 인력도 리소스이기에 관리 인원이 부족한 곳에서는 부담이 될 수 있겠습니다.
마지막으로 유저 권한 관리가 꽤나 복잡합니다.
BI 도구를 사용하다 보면 사용자별로 수정 권한이나 조회 권한을 적절하게 분배해야 하는 상황이 발생합니다.
Superset에서 기본으로 제공되는 권한을 기반으로 커스텀해 필요한 권한을 사용자에게 제공하면 됩니다.
그런데, Superset에서 다루는 권한들은 아래 사진처럼 매우 많고 세분화되어있습니다.
출처: superset roles show
조회 권한을 세밀하게 관리할 수 있다는 장점이 될 수 있겠지만, 그보다 이 부분에 대한 진입 장벽이 너무 높습니다.
Superset 공식 문서에서 자세히 다루고 있지 않아 필요한 권한을 적용하려면
커뮤니티에서 비슷한 사례를 찾아야 하는 등의 많은 시간이 소요됩니다.
이러한 장단점이 있는 Superset이지만 확실한 장점이 크게 다가왔고, 단점들도 대부분 해결할 수 있거나
현재 보이스루 상황에서는 크리티컬하지 않아 지금까지 잘 사용해왔으며 앞으로도 계속 사용할 예정입니다.
활발하게 개발되고 있는 오픈 소스이기 때문에 앞으로의 개선 방향이나 추가되는 기능들에 대한 기대가 큽니다.
마치며
BI 도구로 Apache Superset를 선택하고 보이스루 서비스와 로컬에 맞게 배포하는 과정
그리고 유익한 실사용 리뷰까지 소개해드렸습니다.
보이스루 Data 팀 Data Engineer 조승현 님의 이야기는 여기서 마칩니다.
보이스루의 BI 도구 탐색 여정, 어떠셨나요?
조직을 향한 최적의 기술을 찾으려는 보이스루 Data 팀의 노력이 돋보였습니다.
보이스루와 기술에 관심이 많은 분에게 오래도록 유익한 Tech blog로 남기를 바라겠습니다.
앞으로 전해질 더 많은 이야기를 기대해 주세요.
보이스루팀 드림.
Reference