이 튜토리얼에서는 고객 호스팅 인스턴스에 클러스터링된 Looker 구성을 만드는 데 권장되는 방법을 설명합니다.
개요
고객이 호스팅하는 Looker 배포는 단일 노드 또는 클러스터링된 방식으로 실행할 수 있습니다.
- 기본 구성인 단일 노드 Looker 애플리케이션에는 단일 서버에서 실행되는 Looker 애플리케이션을 구성하는 모든 서비스가 있습니다.
- 클러스터링된 Looker 구성은 데이터베이스 서버, 부하 분산기, Looker 애플리케이션을 실행하는 여러 서버가 포함된 좀 더 복잡한 구성입니다. 클러스터링된 Looker 애플리케이션의 각 노드는 단일 Looker 인스턴스를 실행하는 서버입니다.
조직에서 Looker를 클러스터로 실행하는 두 가지 주요 이유는 다음과 같습니다.
- 부하 분산
- 가용성 및 장애 조치 개선
확장 문제에 따라 클러스터링된 Looker가 솔루션을 제공하지 못할 수도 있습니다. 예를 들어 소수의 대규모 쿼리가 시스템 메모리를 모두 사용하는 경우 Looker 프로세스에 사용할 수 있는 메모리를 늘리는 것이 유일한 해결책입니다.
부하 분산 대안
Looker를 부하 분산하기 전에 Looker를 실행하는 단일 서버의 메모리와 CPU 수를 늘려보세요. Looker가 워크로드에 맞게 크기가 조정되도록 메모리 및 CPU 사용률에 대한 자세한 성능 모니터링을 설정하는 것이 좋습니다.
대용량 쿼리의 경우 성능을 개선하기 위해 더 많은 메모리가 필요합니다. 클러스터링은 많은 사용자가 작은 쿼리를 실행할 때 성능상의 이점이 있습니다.
최대 50명의 사용자가 Looker를 가볍게 사용하는 구성의 경우 Looker는 대규모 AWS EC2 인스턴스(M4.large: 8GB RAM, CPU 코어 2개)에 상응하는 단일 서버를 실행하는 것이 좋습니다. 사용자가 많거나 활성 사용자가 많은 구성의 경우 CPU가 급증하는지 또는 사용자가 애플리케이션 속도가 느린지 확인해야 합니다. 이 경우 Looker를 더 큰 서버로 이동하거나 클러스터링된 Looker 구성을 실행하세요.
가용성/장애 조치 개선
클러스터링된 환경에서 Looker를 실행하면 서비스 중단 시 다운타임을 줄일 수 있습니다. 고가용성은 Looker API가 핵심 비즈니스 시스템에서 사용되거나 Looker가 고객용 제품에 삽입된 경우에 특히 중요합니다.
클러스터링된 Looker 구성에서 프록시 서버 또는 부하 분산기는 하나의 노드가 다운되었다고 판단되면 트래픽의 경로를 다시 변경합니다. Looker는 클러스터에서 나가거나 조인되는 노드를 자동으로 처리합니다.
필수 구성요소
클러스터링된 Looker 구성에는 다음 구성요소가 필요합니다.
- MySQL 애플리케이션 데이터베이스
- Looker 노드(Looker 자바 프로세스를 실행하는 서버)
- 부하 분산기
- 공유 파일 시스템
- Looker 애플리케이션 JAR 파일의 적절한 버전
다음은 구성요소의 상호작용 방식을 보여주는 다이어그램입니다. 대략적으로 부하 분산기는 클러스터링된 Looker 노드 간에 네트워크 트래픽을 분산합니다. 노드는 각각 공유 MySQL 애플리케이션 데이터베이스, 공유 스토리지 디렉터리 및 각 LookML 프로젝트의 Git 서버와 통신합니다.
MySQL 애플리케이션 데이터베이스
Looker는 애플리케이션 데이터베이스(내부 데이터베이스라고도 함)를 사용하여 애플리케이션 데이터를 보관합니다. Looker가 단일 노드 애플리케이션으로 실행되는 경우 일반적으로 메모리 내 HyperSQL 데이터베이스를 사용합니다.
클러스터링된 Looker 구성에서 각 노드의 Looker 인스턴스는 공유 트랜잭션 데이터베이스(공유 애플리케이션 또는 내부 데이터베이스)를 가리켜야 합니다. 클러스터링된 Looker의 애플리케이션 데이터베이스 지원은 다음과 같습니다.
- 클러스터링된 Looker 인스턴스의 애플리케이션 데이터베이스에는 MySQL만 지원됩니다. Amazon Aurora 및 MariaDB는 지원되지 않습니다.
- MySQL 버전 5.7 이상 및 8.0 이상이 지원됩니다.
- Galera와 같은 클러스터링된 데이터베이스는 지원되지 않습니다.
Looker는 해당 데이터베이스의 유지보수 및 백업을 관리하지 않습니다. 하지만 데이터베이스는 거의 모든 Looker 애플리케이션 구성 데이터를 호스팅하므로 고가용성 데이터베이스로 프로비저닝하고 적어도 매일 백업해야 합니다.
Looker 노드
각 노드는 Looker 자바 프로세스가 실행되는 서버입니다. Looker 클러스터의 서버는 서로 그리고 Looker 애플리케이션 데이터베이스에 연결할 수 있어야 합니다. 기본 포트는 이 페이지의 노드가 통신할 포트 열기에 나열되어 있습니다.
부하 분산기
사용 가능한 노드로 부하 또는 리디렉션 요청의 균형을 맞추려면 트래픽을 각 Looker 노드로 전달하기 위해 부하 분산기 또는 프록시 서버(예: NGINX 또는 AWS ELB)가 필요합니다. 부하 분산기가 상태 점검을 처리합니다. 노드에 장애가 발생하면 나머지 정상 노드로 트래픽을 다시 라우팅하도록 부하 분산기를 구성해야 합니다.
부하 분산기를 선택하고 구성할 때 Layer 4로만 작동하도록 구성되었는지 유의하세요. Amazon Classic ELB가 이러한 예시 중 하나입니다. 또한 부하 분산기는 쿼리 종료를 방지하기 위해 긴 제한 시간(3,600초)을 가져야 합니다.
공유 파일 시스템
POSIX 규격 공유 파일 시스템(예: NFS, AWS EFS, Gluster, BeeGFS, Lustre 등)을 사용해야 합니다. Looker는 클러스터의 모든 노드에서 사용하는 다양한 정보를 저장하는 저장소로 공유 파일 시스템을 사용합니다.
Looker 애플리케이션(JAR 실행 파일)
Looker 3.56 이상인 Looker 애플리케이션 JAR 파일을 사용해야 합니다.
이 페이지의 노드에서 Looker 시작에 설명된 대로 클러스터의 각 노드에서 동일한 Looker 출시 및 패치 버전을 실행하는 것이 좋습니다.
클러스터 설정
다음 작업이 필요합니다.
- Looker 설치
- MySQL 애플리케이션 데이터베이스 설정
- 공유 파일 시스템 설정
- SSH 키 저장소 공유(상황에 따라 다름)
- 노드가 통신할 수 있도록 포트 열기
- 노드에서 Looker 시작
Looker 설치
Looker 애플리케이션 JAR 파일 및 고객 호스팅 설치 단계 문서 페이지의 안내에 따라 각 노드에 Looker가 설치되어 있는지 확인합니다.
MySQL 애플리케이션 데이터베이스 설정
클러스터링된 Looker 구성의 경우 애플리케이션 데이터베이스는 MySQL 데이터베이스여야 합니다. 애플리케이션 데이터베이스에 HyperSQL을 사용하는 클러스터링되지 않은 기존 Looker 인스턴스가 있는 경우 애플리케이션 데이터를 HyperSQL 데이터에서 새로 공유된 MySQL 애플리케이션 데이터베이스로 마이그레이션해야 합니다.
Looker를 백업한 후 애플리케이션 데이터베이스를 HyperSQL에서 MySQL로 마이그레이션하는 방법에 대한 자세한 내용은 MySQL로 마이그레이션 문서 페이지를 참조하세요.
공유 파일 시스템 설정
특정 파일 형식(모델 파일, 배포 키, 플러그인, 잠재적으로 애플리케이션 매니페스트 파일)만 공유 파일 시스템에 속합니다. 공유 파일 시스템 설정:
- 공유 파일 시스템을 저장할 서버에서 Looker 사용자 계정에
su할 수 있는 다른 계정에 대한 액세스 권한이 있는지 확인합니다. - 공유 파일 시스템의 서버에서 Looker 사용자 계정에 로그인합니다.
- Looker가 실행 중인 경우 Looker 구성을 종료합니다.
- 이전에 iannounce Linux를 사용하여 클러스터링한 경우 해당 스크립트를 중지하고 크론에서 제거한 후 삭제합니다.
- 네트워크 공유를 만들고 클러스터의 각 노드에 마운트합니다. 각 노드에서 자동으로 마운트되도록 구성되어 있는지, Looker 사용자에게 읽기 및 쓰기 권한이 있는지 확인합니다. 다음 예시에서 네트워크 공유 이름은
/mnt/looker-share입니다. 한 노드에서 배포 키를 복사하고 플러그인과
looker/models및looker/models-user-*디렉터리(모델 파일 저장)를 네트워크 공유로 이동합니다. 예를 들면 다음과 같습니다.mv looker/models /mnt/looker-share/ mv looker/models-user-* /mnt/looker-share/각 노드에 대해
--shared-storage-dir설정을LOOKERARGS에 추가합니다. 이 예시와 같이 네트워크 공유를 지정합니다.--shared-storage-dir /mnt/looker-share설정이 업데이트의 영향을 받지 않도록
LOOKERARGS를$HOME/looker/lookerstart.cfg에 추가해야 합니다.LOOKERARGS가 파일에 나열되지 않은 경우 다른 사용자가$HOME/looker/looker셸 스크립트에 직접 추가했을 수 있습니다.클러스터의 각 노드는 고유한
/log디렉터리 또는 최소한 고유한 로그 파일에 작성해야 합니다.
SSH 키 저장소 공유
- 기존 Looker 구성에서 공유 파일 시스템 클러스터를 만들고
- Looker 4.6 이하에서 생성된 프로젝트가 있는 경우
공유할 SSH 키 저장소를 설정합니다.
공유 파일 서버에서
ssh-share라는 디렉터리를 만듭니다. 예를 들면/mnt/looker-share/ssh-share입니다.ssh-share디렉터리의 소유자가 Looker 사용자이고 권한이 700인지 확인합니다. 또한ssh-share디렉터리 위의 상위 디렉터리(예:/mnt및/mnt/looker-share)는 누구나 쓰기 또는 그룹 쓰기가 허용되지 않아야 합니다.한 노드에서
$HOME/.ssh의 콘텐츠를 새ssh-share디렉터리에 복사합니다. 예를 들면 다음과 같습니다.cp $HOME/.ssh/* /mnt/looker-share/ssh-share각 노드에 대해 기존 SSH 파일을 백업하고
ssh-share디렉터리에 대한 심볼릭 링크를 만듭니다. 예를 들면 다음과 같습니다.cd $HOME mv .ssh .ssh_bak ln -s /mnt/looker-share/ssh-share .ssh모든 노드에 이 단계를 실행해야 합니다.
노드가 통신할 수 있도록 포트 열기
클러스터링된 Looker 노드는 자체 서명 인증서와 애플리케이션 데이터베이스의 보안 비밀 로테이션을 기반으로 하는 추가 인증 스키마를 사용하여 HTTPS를 통해 서로 통신합니다.
클러스터 노드 간에 열려 있어야 하는 기본 포트는 1551과 61616입니다. 이러한 포트는 여기에 나열된 시작 플래그를 사용하여 구성할 수 있습니다. 클러스터 호스트 간에만 트래픽을 허용하도록 이러한 포트에 대한 네트워크 액세스를 제한하는 것이 좋습니다.
노드에서 Looker 시작
필요한 시작 플래그를 사용하여 각 노드에서 서버를 다시 시작합니다.
사용 가능한 시작 플래그
다음 표에는 클러스터를 시작하거나 가입하는 데 필요한 플래그를 비롯하여 사용 가능한 시작 플래그가 나와 있습니다.
| 플래그 | 필수 여부 | 값 | 목적 |
|---|---|---|---|
--clustered |
예 | 이 노드가 클러스터링 모드로 실행 중임을 지정하는 플래그를 추가합니다. | |
-H 또는 --hostname |
예 | 10.10.10.10 |
다른 노드가 이 노드에 연결할 때 사용하는 호스트 이름(예: 노드의 IP 주소 또는 시스템 호스트 이름)입니다. 클러스터의 다른 모든 노드의 호스트 이름과 달라야 합니다. |
-n |
아니요 | 1551 |
노드 간 통신용 포트입니다. 기본값은 1551입니다. 모든 노드는 노드 간 통신에 동일한 포트 번호를 사용해야 합니다. |
-q |
아니요 | 61616 |
클러스터 전체 이벤트를 큐에 추가하는 포트입니다. 기본값은 61616입니다. |
-d |
예 | /path/to/looker-db.yml |
Looker 애플리케이션 데이터베이스에 대한 사용자 인증 정보가 저장된 파일의 경로입니다. |
--shared-storage-dir |
예 | /path/to/mounted/shared/storage |
이 옵션은 looker/model 및 looker/models-user-* 디렉터리가 있는 공유 디렉터리 설정(이 페이지 앞부분)을 가리켜야 합니다. |
LOOKERARGS 및 데이터베이스 사용자 인증 정보 지정 예시
Looker 시작 플래그를 Looker JAR 파일과 동일한 디렉터리에 있는 lookerstart.cfg 파일에 배치합니다.
예를 들어 Looker에 다음과 같이 지시할 수 있습니다.
looker-db.yml이라는 파일을 데이터베이스 사용자 인증 정보에 사용하려면 다음 안내를 따르세요.- 클러스터링된 노드이며
- 클러스터의 다른 노드가 IP 주소 10.10.10.10에서 이 호스트에 연결해야 합니다.
다음을 지정합니다.
LOOKERARGS="-d looker-db.yml --clustered -H 10.10.10.10"
looker-db.yml 파일에는 다음과 같은 데이터베이스 사용자 인증 정보가 포함됩니다.
host: your.db.hostname.com
username: db_user
database: looker
dialect: mysql
port: 3306
password: secretPassword
또한 MySQL 데이터베이스에 SSL 연결이 필요한 경우 looker-db.yml 파일에는 다음도 필요합니다.
ssl: true
디스크의 looker-db.yml 파일에 구성을 저장하지 않으려면 looker-db.yml 파일의 각 줄에 대한 키-값 목록을 포함하도록 환경 변수 LOOKER_DB를 구성하면 됩니다. 예를 들면 다음과 같습니다.
export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"
Git SSH 배포 키 찾기
Looker가 Git SSH 배포 키를 저장하는 위치는 프로젝트가 생성된 출시 버전에 따라 다릅니다.
- Looker 4.8 이전에 만든 프로젝트의 경우 배포 키는 서버의 기본 제공 SSH 디렉터리
~/.ssh에 저장됩니다. - Looker 4.8 이상에서 만든 프로젝트의 경우 배포 키가 Looker에서 제어하는 디렉터리
~/looker/deploy_keys/PROJECT_NAME에 저장됩니다.
Looker 클러스터 수정
Looker 클러스터를 만든 후에는 다른 클러스터링된 노드를 변경하지 않고도 노드를 추가하거나 삭제할 수 있습니다.
클러스터를 새 Looker 출시로 업데이트
업데이트에는 이전 버전의 Looker와 호환되지 않는과 Looker 내부 데이터베이스에 대한 스키마 변경사항이 포함될 수 있습니다. Looker를 업데이트하는 방법에는 두 가지가 있습니다.
더 안전한 방법
- 애플리케이션 데이터베이스의 백업을 만듭니다.
- 모든 클러스터 노드를 중지합니다.
- 각 서버의 JAR 파일을 교체합니다.
- 각 노드를 한 번에 하나씩 시작합니다.
더 빠른 방법
더 빠르지만 완전성이 떨어지는 이 방법을 사용하여 업데이트하려면 다음 안내를 따르세요.
- Looker 애플리케이션 데이터베이스의 복제본을 만듭니다.
- 복제본을 가리키는 새 클러스터를 시작합니다.
- 프록시 서버 또는 부하 분산기를 새 노드로 가리킨 후 이전 노드를 중지할 수 있습니다.