Looker 22.16 문서를 보고 있습니다. 최신 문서는 여기에서 확인할 수 있습니다.

클러스터링 Looker

이 튜토리얼에서는 클러스터링된 Looker 구성을 만들 때 권장되는 방법을 설명합니다.

개요

Looker 애플리케이션은 단일 노드 또는 클러스터링을 실행할 수 있습니다.

기본 구성인 단일 노드 Looker 애플리케이션에는 단일 서버에서 실행되는 Looker 애플리케이션을 구성하는 모든 서비스가 있습니다.
클러스터링된 Looker 구성은 더 복잡한 구성으로, 일반적으로 데이터베이스 서버, 부하 분산기, Looker 애플리케이션을 실행하는 여러 서버가 포함됩니다. 클러스터링된 Looker 애플리케이션의 각 노드는 단일 Looker 인스턴스를 실행하는 서버입니다.

조직이 Looker를 클러스터로 실행하려는 두 가지 주요 이유는 다음과 같습니다.

부하 분산
가용성 및 장애 조치 개선

확장 문제에 따라 클러스터형 Looker가 솔루션을 제공하지 않을 수 있습니다. 예를 들어 소수의 대규모 쿼리가 시스템 메모리를 사용하는 경우 Looker 프로세스에 사용 가능한 메모리를 늘리는 방법밖에 없습니다.

부하 분산 대안

Looker를 부하 분산하기 전에 Looker를 실행하는 단일 서버의 메모리와 CPU 수를 늘리는 것이 좋습니다. Looker에서 워크로드의 크기를 적절하게 조정하도록 메모리 및 CPU 사용률에 대한 자세한 성능 모니터링을 설정할 것을 권장합니다.

대규모 쿼리인 경우 성능 향상을 위해 더 많은 메모리가 필요합니다. 클러스터링은 많은 사용자가 작은 쿼리를 실행할 때 성능 향상 효과를 제공할 수 있습니다.

최대 50명의 사용자가 Looker를 가볍게 사용하는 구성의 경우 Looker는 대규모 AWS EC2 인스턴스 (M4.large: 8GB, CPU 코어 2개)에 상응하는 단일 서버를 실행하는 것이 좋습니다. 사용자가 더 많거나 활성 사용자가 많은 구성의 경우 CPU가 급증하는지 또는 사용자가 애플리케이션 속도 저하를 느끼는지 살펴봅니다. 이 경우 Looker를 더 큰 서버로 이동하거나 클러스터링된 Looker 구성을 실행하세요.

가용성/장애 조치 개선

클러스터링된 환경에서 Looker를 실행하면 서비스 중단 발생 시 다운타임을 완화할 수 있습니다. 고가용성은 Looker API가 핵심 비즈니스 시스템에 사용되거나 Looker가 고객 대면 제품에 내장된 경우에 특히 중요합니다.

클러스터링된 Looker 구성에서는 프록시 서버 또는 부하 분산기가 노드 하나가 다운된 것으로 판단하면 트래픽을 다시 라우팅합니다. Looker는 자동으로 클러스터에서 나가고 클러스터를 조인하는 노드를 처리합니다.

필수 구성요소

클러스터링된 Looker 구성에는 다음 구성요소가 필요합니다.

MySQL 애플리케이션 데이터베이스
Looker 노드 (Looker 자바 프로세스를 실행하는 서버)
부하 분산기
공유 파일 시스템
Looker 애플리케이션 JAR 파일의 올바른 버전

다음 다이어그램은 구성요소가 상호작용하는 방식을 보여줍니다.

MySQL 애플리케이션 데이터베이스

Looker는 애플리케이션 데이터베이스 (내부 데이터베이스라고도 함)를 사용하여 애플리케이션 데이터를 보관합니다. Looker가 단일 노드 애플리케이션으로 실행되는 경우 일반적으로 메모리 내 HyperSQL 데이터베이스를 사용합니다.

클러스터링된 Looker 구성에서 각 노드의 Looker 인스턴스는 공유 트랜잭션 데이터베이스 (공유 애플리케이션 또는 내부 데이터베이스)를 가리켜야 합니다. 클러스터링된 Looker를 위한 애플리케이션 데이터베이스 지원은 다음과 같습니다.

클러스터형 Looker 인스턴스의 애플리케이션 데이터베이스에는 MySQL만 지원됩니다. Amazon Aurora 및 MariDB는 지원되지 않습니다.
MySQL 버전 5.7 이상 및 8.0 이상이 지원됩니다.
Galera와 같은 클러스터링된 데이터베이스는 지원되지 않습니다.

성능 및 중복성을 개선하려면 읽기 복제본 데이터베이스를 사용하는 것이 좋습니다. 읽기 복제본 데이터베이스는 MySQL 데이터베이스일 필요가 없습니다.

Looker는 해당 데이터베이스의 유지보수 및 백업을 관리하지 않습니다. 그러나 데이터베이스는 거의 모든 Looker 애플리케이션 구성 데이터를 호스팅하므로 고가용성 데이터베이스로 프로비저닝되고 적어도 매일 백업되어야 합니다.

Looker 노드

각 노드는 Looker 자바 프로세스가 실행 중인 서버입니다. Looker 클러스터의 서버는 서로와 Looker 애플리케이션 데이터베이스에 연결할 수 있어야 합니다. 기본 포트는 이 페이지의 노드 통신용 포트 열기에 나와 있습니다.

부하 분산기

사용 가능한 노드로 부하 또는 리디렉션 요청의 균형을 맞추려면 각 Looker 노드로 트래픽을 전달하기 위해 부하 분산기 또는 프록시 서버 (예: NGINX 또는 AWS ELB)가 필요합니다. 부하 분산기가 상태 점검을 처리합니다. 노드에 장애가 발생할 경우 나머지 정상 노드로 트래픽을 다시 라우팅하도록 부하 분산기를 구성해야 합니다.

부하 분산기를 선택하고 구성할 때 레이어 4로만 작동하도록 구성할 수 있는지 확인합니다. 이러한 예로 Amazon Classic ELB가 있습니다. 또한 부하 분산기의 제한 시간 (3,600초)이 길어야 쿼리가 중단되지 않습니다.

공유 파일 시스템

POSIX 규격 공유 파일 시스템 (예: NFS, AWS EFS, Gluster, BeeGFS, Lustre 등)을 사용해야 합니다. Looker는 공유 파일 시스템을 클러스터의 모든 노드에서 사용하는 다양한 정보를 위한 저장소로 사용합니다.

Looker Marketplace에서 애플리케이션 및 도구를 설치하려면 공유 (네트워크) 파일 시스템을 사용해야 합니다.

Looker 애플리케이션 (JAR 실행 파일)

Looker 3.56 이상의 Looker 애플리케이션 JAR 파일을 사용해야 합니다.

Looker 6.18부터 Looker JAR 파일이 Looker 핵심 JAR 파일과 Looker 종속 항목 JAR 파일 2개로 분할되었습니다. Looker 6.18 이상으로 설치하거나 업데이트하는 경우 두 JAR 파일을 모두 다운로드해야 합니다.

이 페이지의 노드에서 Looker 시작에 설명된 대로 Looker에서는 클러스터의 각 노드가 동일한 Looker 출시 버전과 패치 버전을 실행할 것을 적극 권장합니다.

클러스터 설정

다음 작업이 필요합니다.

Looker 설치
MySQL 애플리케이션 데이터베이스 설정하기
공유 파일 시스템 설정하기
SSH 키 저장소 공유(상황에 따라 다름)
노드가 통신할 포트를 엽니다.
노드에서 Looker 시작하기

Looker 설치

Looker 애플리케이션 JAR 파일 및 고객 호스팅 설치 단계 문서 페이지의 안내에 따라 각 노드에 Looker가 설치되어 있는지 확인합니다.

MySQL 애플리케이션 데이터베이스 설정

클러스터링된 Looker 구성의 경우 애플리케이션 데이터베이스는 MySQL 데이터베이스여야 합니다. 애플리케이션 데이터베이스에 HyperSQL을 사용하는 클러스터링되지 않은 기존 Looker 인스턴스가 있는 경우 애플리케이션 데이터를 HyperSQL 데이터에서 새 공유 MySQL 애플리케이션 데이터베이스로 이전해야 합니다.

Looker 디렉터리를 백업해야 합니다. 마이그레이션 프로세스는 HyperSQL 데이터베이스에서 MySQL 데이터베이스로만 전환할 수 있으며 그 반대는 아닙니다.

Looker 백업 및 애플리케이션 데이터베이스를 HyperSQL에서 MySQL로 마이그레이션하는 방법에 대한 자세한 내용은 MySQL로 이전 문서 페이지를 참조하세요.

공유 파일 시스템 설정

모델 파일, 배포 키, 플러그인, 애플리케이션 매니페스트 파일 등 특정 파일 형식만 공유 파일 시스템에 속합니다. 공유 파일 시스템을 설정하려면 다음 안내를 따르세요.

공유 파일 시스템을 저장할 서버에서 Looker 사용자 계정에 su할 수 있는 다른 계정에 액세스할 수 있는지 확인합니다.
공유 파일 시스템 서버에서 Looker 사용자 계정에 로그인합니다.
현재 Looker가 실행 중인 경우 Looker 구성을 종료합니다.
이전에 inotify Linux 스크립트를 사용하여 클러스터링한 경우 해당 스크립트를 중지하고 cron에서 삭제한 후 삭제합니다.
네트워크 공유를 만들고 클러스터의 각 노드에 마운트합니다. 각 노드에 자동으로 마운트되도록 구성되어 있는지, 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 이하에서 만든 프로젝트가 있습니다.

다음 절차에서는 Looker 사용자의 $HOME/.ssh directory을 수정해야 합니다. 이 경우 구성에 오류가 있으면 로그인하여 문제를 해결하기 어려울 수 있습니다. 이 단계를 수행하기 전에 Looker 사용자 계정에 su할 수 있는 다른 계정에 액세스할 수 있는지 확인하세요.

공유할 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-*` 디렉터리가 포함된 이 페이지 앞의 공유 디렉터리 설정을 가리켜야 합니다.

--clustered 시작 플래그에는 값이 포함되면 안 됩니다.

`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"

노드에 올바른 IP 주소를 지정해야 합니다.

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 애플리케이션이 실행되는 Linux '사용자' 계정이 소유한 looker-db.yml 파일 권한을 600으로 설정하는 것이 가장 좋습니다. 이 파일은 Git 저장소에 체크인하면 안 됩니다.

디스크의 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 파일을 교체합니다.
각 노드를 한 번에 하나씩 시작합니다.

더 빠른 방법

이 방법을 사용하면 다운타임이 감소하고 복제본 생성과 프록시 서버가 새 노드를 가리키도록 할 때의 변경사항이 사라집니다. 예를 들어 사용자가 전환 중에 사용자를 추가하거나 Look을 만들면 이러한 변경사항이 새 애플리케이션 데이터베이스에 반영되지 않을 수 있습니다.

더 빠르지만 덜 완전한 메서드를 사용하여 업데이트하려면 다음 단계를 따르세요.

Looker 애플리케이션 데이터베이스의 복제본을 만듭니다.
복제본을 가리키는 새 클러스터를 시작합니다.
프록시 서버나 부하 분산기가 새 노드를 가리키도록 한 다음 이전 노드를 중지할 수 있습니다.