이 튜토리얼에서는 고객 호스팅 인스턴스에 클러스터링된 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 출시 및 패치 버전을 실행하는 것이 좋습니다.
클러스터 설정
다음 작업이 필요합니다.
- 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입니다.Looker 사용자가
ssh-share디렉터리를 소유하고 권한이 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의 애플리케이션 데이터베이스의 복제본을 만듭니다.
- 복제본에 연결된 새 클러스터를 시작합니다.
- 프록시 서버 또는 부하 분산기가 새 노드를 가리키도록 한 후에 이전 노드를 중지합니다.