이 페이지에서는 Looker 아키텍처의 특정 구성요소에 대한 일반적인 권장사항을 살펴보고 배포 내에서 이를 구성하는 방법을 설명합니다.
Looker에는 서버 호스팅, 임시 및 예약 워크로드 제공, 반복 모델 개발 추적 등 다양한 종속 항목이 있습니다. 이러한 종속 항목을 이 페이지에서는 구성요소라고 하며 각 구성요소는 다음 섹션에서 자세히 다룹니다.
호스트 구성
OS 및 배포
Looker는 가장 일반적인 Linux 버전인 RedHat, SUSE, Debian/Ubuntu에서 원활하게 실행됩니다. 특정 환경에서 실행되도록 설계되고 최적화된 이러한 배포 버전의 파생판은 일반적으로 문제가 없습니다. 예를 들어 Linux 또는 Google Cloud의 AWS 배포판은 Looker와 호환됩니다. Debian/Ubuntu는 Looker 커뮤니티에서 가장 널리 사용되는 Linux 버전이며 Looker 지원에 가장 익숙한 버전입니다. Debian/Ubuntu 또는 Debian/Ubuntu에서 파생된 특정 클라우드 제공업체의 운영체제를 사용하는 것이 가장 쉽습니다.
Looker는 Java 가상 머신(JVM)에서 실행됩니다. 배포판을 선택할 때 OpenJDK 11의 버전이 최신 상태인지 확인하세요. 이전 Linux 배포판에서 Looker를 실행할 수 있지만 특정 기능에 필요한 Java 버전 및 라이브러리는 최신 상태여야 합니다. JVM에 권장되는 Looker 라이브러리 및 버전이 모두 포함되어 있지 않으면 Looker가 정상적으로 작동하지 않습니다. Looker에는 Java 핫스팟 168 이상 또는 Java OpenJDK 11.0.12 이상이 필요합니다.
CPU 및 메모리
4x16(CPU 4개 및 RAM 16GB) 노드는 개발 시스템이나 소규모 팀에서 사용하는 기본 테스트 Looker 인스턴스에 충분합니다. 그러나 프로덕션 용도로는 일반적으로 충분하지 않습니다. 사용 경험에 따르면 16x64 노드(CPU 16개 및 RAM 64GB)는 가격과 성능 사이에서 적절한 균형을 이룹니다. 가비지 컬렉션 이벤트는 단일 스레드이고 다른 모든 스레드를 중지하므로 64GB를 초과하는 RAM은 성능에 영향을 줄 수 있습니다.
디스크 스토리지
일반적으로 프로덕션 시스템에 100GB의 디스크 공간이면 충분합니다.
클러스터 고려사항
Looker는 Java JVM에서 실행되며 Java는 64GB보다 큰 메모리를 관리하는 데 문제가 있을 수 있습니다. 일반적으로 용량이 더 필요하면 노드 크기를 16x64 이상으로 늘리는 대신 클러스터에 16x64 노드를 추가해야 합니다. 가용성을 높이기 위해 클러스터링된 아키텍처를 사용하는 것이 좋습니다.
클러스터에서 Looker 노드는 파일 시스템의 특정 부분을 공유해야 합니다. 공유 데이터에는 다음이 포함됩니다.
- LookML 모델
- 개발자 LookML 모델
- Git 서버 연결
파일 시스템은 공유되고 여러 Git 저장소를 호스팅하므로 동시 액세스 및 파일 잠금은 중요합니다. 파일 시스템은 POSIX 규정을 준수해야 합니다. 네트워크 파일 시스템(NFS)은 작동하는 것으로 알려져 있으며 Linux에서 즉시 사용할 수 있습니다. 추가 Linux 인스턴스를 만들고 NFS를 구성하여 디스크를 공유해야 합니다. 기본 NFS는 잠재적으로 단일 장애점이므로 장애 조치 설정 또는 고가용성 설정을 고려하세요.
Looker 메타데이터도 중앙 집중화되어야 하므로 내부 데이터베이스를 MySQL로 마이그레이션해야 합니다. MySQL 서비스 또는 전용 MySQL 배포일 수 있습니다. 이 페이지의 내부(백엔드) 데이터베이스 섹션을 더 자세히 살펴봅니다.
JVM 구성
Looker JVM 설정은 Looker 시작 스크립트 내에 정의됩니다. 업데이트 후 매니페스트 변경사항을 위해 Looker를 다시 시작해야 합니다. 기본 구성은 다음과 같습니다.
java \
-XX:+UseG1GC -XX:MaxGCPauseMillis=2000 \
-Xms$JAVAMEM -Xmx$JAVAMEM \
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-Xloggc:/tmp/gc.log ${JAVAARGS} \
-jar looker.jar start ${LOOKERARGS}
리소스
리소스 설정은 Looker 시작 스크립트에 정의되어 있습니다.
JAVAMEM="2300m" METAMEM="800m"
JVM의 메모리 할당에는 Looker가 실행 중인 운영체제 오버헤드를 고려해야 합니다. 일반적으로 JVM은 총 메모리의 최대 60%에 할당할 수 있지만 머신 크기에 따라 주의사항이 있습니다. 총 메모리가 8GB인 머신의 경우 Java에 4~5GB를, 메타에 800MB를 할당하는 것이 좋습니다. 대형 머신의 경우 운영체제에 더 낮은 메모리 비율을 할당할 수 있습니다. 예를 들어 총 메모리가 60GB인 머신의 경우 Java에 36GB를, 메타에 1GB를 할당하는 것이 좋습니다. Java의 메모리 할당은 일반적으로 머신의 총 메모리와 함께 확장되어야 하지만 메타는 1GB로 충분해야 합니다.
또한 Looker는 렌더링을 위해 Chromium과 같은 다른 프로세스와 시스템 리소스를 공유하므로 Java에 할당되는 메모리 양은 예상 렌더링 로드 및 머신 크기와 관련하여 선택해야 합니다. 렌더링 부하가 낮을 것으로 예상되면 총 메모리의 더 많은 부분을 Java에 할당할 수 있습니다. 예를 들어 총 메모리가 60GB인 머신에서 Java는 일반적인 60% 권장사항보다 높은 46GB에 안전하게 할당할 수 있습니다. 각 배포에 알맞은 정확한 리소스 할당이 다양하므로 60%를 기준으로 사용하고 사용량에 따라 조정합니다.
가비지 컬렉션
Looker는 Java 버전에 제공되는 최신 가비지 수집기를 사용하는 것을 선호합니다. 기본적으로 가비지 컬렉션 제한 시간은 2초이지만 시작 구성에서 다음 옵션을 수정하여 변경할 수 있습니다.
-XX:MaxGCPauseMillis=2000
코어가 여러 개인 더 큰 머신에서 가비지 컬렉션 제한 시간을 줄일 수 있습니다.
로그
기본적으로 Looker 가비지 컬렉션 로그는 /tmp/gc.log에 저장됩니다. 시작 구성에서 다음 옵션을 수정하여 이를 변경할 수 있습니다.
-Xloggc:/tmp/gc.log
JMX
Looker를 관리하려면 리소스 재구성을 위한 모니터링이 필요할 수 있습니다. JMX를 사용하여 JVM 메모리 사용량을 모니터링하는 것이 좋습니다.
Looker 시작 옵션
시작 옵션은 lookerstart.cfg 파일에 저장됩니다. 이 파일은 Looker를 시작하는 셸 스크립트에서 가져온 것입니다.
스레드 풀
Looker는 멀티스레드 애플리케이션으로 여러 스레드 풀을 포함합니다. 이러한 스레드 풀은 코어 웹 서버부터 예약, 렌더링, 외부 데이터베이스 연결과 같은 특별한 하위 서비스에 이르기까지 다양합니다. 비즈니스 워크플로에 따라 이러한 풀을 기본 구성에서 수정해야 할 수 있습니다. 특히 고객 호스팅 인프라 아키텍처 패턴 및 사례 페이지에 언급된 클러스터 토폴로지에 대해서는 특별한 고려사항이 있습니다.
높은 예약 처리량 옵션
스케줄러가 아닌 모든 노드의 경우 lookerstart.cfg의 LOOKERARGS 환경 변수에 --scheduler-threads=0를 추가합니다. 스케줄러 스레드가 없으면 이러한 노드에서 예약된 작업이 실행되지 않습니다.
모든 전용 스케줄러 노드의 경우 lookerstart.cfg의 LOOKERARGS 환경 변수에 --scheduler-threads=<n>를 추가합니다. Looker는 기본적으로 스케줄러 스레드 10개로 시작하지만 <n>개로 늘어날 수 있습니다. <n> 스케줄러 스레드를 사용하면 각 노드가 <n>개의 동시 실행 예약 작업을 실행할 수 있습니다. 일반적으로 <n>을 CPU 수의 2배 미만을 유지하는 것이 좋습니다. 가장 큰 권장 호스트는 CPU 16개와 메모리 64GB가 있는 호스트이므로 스케줄러 스레드의 상한은 32보다 작아야 합니다.
높은 렌더링 처리량 옵션
렌더링되지 않은 모든 노드의 경우 lookerstart.cfg의 LOOKERARGS 환경 변수에 --concurrent-render-jobs=0를 추가합니다. 렌더링 노드가 없으면 이러한 노드에서 렌더링 작업이 실행되지 않습니다.
모든 전용 렌더링 노드의 경우 lookerstart.cfg의 LOOKERARGS 환경 변수에 --concurrent-render-jobs=<n>를 추가합니다. Looker는 기본적으로 렌더링 스레드 2개로 시작하지만 <n>개로 늘어날 수 있습니다. <n>개의 렌더링 스레드를 사용하면 각 노드가 <n>개의 동시 렌더링 작업을 실행할 수 있습니다.
각 렌더링 작업은 상당량의 메모리를 사용할 수 있습니다. 렌더링 작업당 약 2GB의 예산이 책정됩니다. 예를 들어 핵심 Looker 프로세스(자바)에 총 메모리의 60%가 할당되고 남은 메모리의 20%가 운영체제용으로 예약되면 마지막 20%는 렌더링 작업에 사용됩니다. 64GB 머신에서는 12GB가 남으며, 이는 6개의 동시 렌더링 작업용으로 충분합니다. 노드가 렌더링 전용이고 대화형 작업을 처리하는 부하 분산기 풀에 포함되지 않은 경우 더 많은 렌더링 작업을 허용하도록 핵심 Looker 프로세스 메모리를 줄일 수 있습니다. 64GB 머신에서는 Looker 핵심 프로세스에 약 30%(20GB)를 할당할 수 있습니다. 일반적인 OS 사용에 20%를 예약하여 렌더링에 사용할 50%(32GB)가 남게 되므로 16개의 동시 렌더링 작업에 충분합니다.
내부(백엔드) 데이터베이스
Looker 서버는 자체 구성, 데이터베이스 연결, 사용자, 그룹, 역할, 폴더, 사용자 정의 Look 및 대시보드, 내부 데이터베이스의 기타 다양한 데이터에 대한 정보를 유지합니다.
중간 크기의 독립형 Looker 인스턴스의 경우 이 데이터는 Looker 프로세스 자체에 임베딩된 메모리 내 HyperSQL 데이터베이스에 저장됩니다. 이 데이터베이스의 데이터는 <looker install directory>/.db/looker.script 파일에 저장됩니다. 편리하고 가볍지만 이 데이터베이스는 사용량이 많으면 성능 문제가 발생합니다. 따라서 원격 MySQL 데이터베이스로 시작하는 것이 좋습니다. 그렇게 할 수 없는 경우 ~/looker/.db/looker.script 파일이 600MB에 도달하면 원격 MySQL 데이터베이스로 마이그레이션하는 것이 좋습니다. 클러스터는 MySQL 데이터베이스를 사용해야 합니다.
Looker 서버는 MySQL 데이터베이스에 대해 작은 읽기 및 쓰기를 여러 번 수행합니다. 사용자가 Look 또는 Explore를 실행할 때마다 Looker는 데이터베이스를 확인하여 사용자가 아직 로그인되어 있는지, 사용자에게 데이터에 액세스할 수 있는 권한이 있는지, 사용자에게 Look 또는 Explore를 실행할 권한이 있는지 등을 확인합니다. 또한 Looker는 실행된 실제 SQL, 요청이 시작 및 종료된 시간과 같은 데이터를 MySQL 데이터베이스에 작성합니다. 사용자와 Looker 애플리케이션 간의 단일 상호작용으로 인해 MySQL 데이터베이스에 대한 15~20회의 작은 읽기 및 쓰기가 발생할 수 있습니다.
MySQL
MySQL 서버는 버전 8.0.x여야 하며, utf8mb4 인코딩을 사용하도록 구성해야 합니다. InnoDB 스토리지 엔진을 사용해야 합니다. MySQL 설정 안내 및 기존 HyperSQL 데이터베이스에서 MySQL로 데이터를 마이그레이션하는 방법에 대한 안내는 Looker 백엔드 데이터베이스를 MySQL로 마이그레이션 문서 페이지에서 확인할 수 있습니다.
MySQL을 사용하도록 Looker를 구성할 때는 연결 정보가 포함된 YAML 파일을 만들어야 합니다. YAML 파일의 이름을 looker-db.yml로 지정하고 lookerstart.cfg 파일의 LOOKERARGS 섹션에 -d looker-db.yml 설정을 추가합니다.
MariaDB
MySQL은 오픈소스 및 상용 제품으로 모두 사용할 수 있는 이중 라이선스입니다. Oracle은 MySQL을 지속적으로 개선해 왔으며, MySQL은 MariaDB로 포크됩니다. MariaDB 상응하는 MySQL 버전은 Looker에서 작동하는 것으로 알려져 있지만 Looker 엔지니어링팀에서 개발하거나 테스트하지 않습니다. 따라서 기능이 지원되거나 보장되지 않습니다.
Cloud 버전
클라우드 인프라에서 Looker를 호스팅하는 경우 동일한 클라우드 인프라에서 MySQL 데이터베이스를 호스팅하는 것이 논리적입니다. 3대 주요 클라우드 공급업체는 Amazon AWS, Microsoft Azure, Google Cloud입니다. 클라우드 제공업체는 MySQL 데이터베이스의 많은 유지보수 및 구성을 관리하며, 백업 관리 및 신속한 복구 제공과 같은 서비스를 제공합니다. 이러한 제품은 Looker에서 잘 작동하는 것으로 알려져 있습니다.
시스템 활동 쿼리
MySQL 데이터베이스는 사용자가 Looker를 사용하는 방법에 대한 정보를 저장하는 데 사용됩니다. 시스템 활동 모델을 볼 수 있는 권한이 있는 모든 Looker 사용자는 이 데이터를 분석하기 위해 미리 빌드된 여러 Looker 대시보드에 액세스할 수 있습니다. 사용자는 Looker 메타데이터의 Explore에 액세스하여 추가 분석을 빌드할 수도 있습니다. MySQL 데이터베이스는 주로 작고 빠른 '운영' 쿼리에 사용됩니다. 시스템 활동 모델에서 생성된 크고 느린 '분석' 쿼리는 이러한 운영 쿼리와 경합하여 Looker를 느리게 할 수 있습니다.
이러한 경우 MySQL 데이터베이스를 다른 데이터베이스에 복제할 수 있습니다. 자체 관리형 시스템과 특정 클라우드 관리형 시스템 모두 다른 데이터베이스의 복제에 대한 기본 구성을 제공합니다. 복제 구성은 이 문서에서 다루지 않습니다.
시스템 활동 쿼리에 복제본을 사용하려면 looker-db.yml 파일(예: looker-usage-db.yml)의 사본을 만들고 복제본을 가리키도록 수정하고 --internal-analytics-connection-file looker-usage-db.yml 설정을 lookerstart.cfg 파일의 LOOKERARGS 섹션에 추가합니다.
시스템 활동 쿼리는 MySQL 인스턴스 또는 Google BigQuery 데이터베이스를 대상으로 실행할 수 있습니다. 다른 데이터베이스에 대해서는 테스트되지 않습니다.
MySQL 성능 구성
Looker 백엔드 데이터베이스를 MySQL로 마이그레이션하는 데 필요한 설정 외에도 활발하게 활동하는 클러스터는 추가 조정 및 구성을 통해 이점을 누릴 수 있습니다. 이러한 설정은 /etc/my.cnf 파일에서 수행하거나 클라우드 관리형 인스턴스의 경우 Google Cloud 콘솔을 통해 수행할 수 있습니다.
my.cnf 구성 파일은 여러 부분으로 나뉩니다. 이 섹션에서 설명하는 다음 설정 변경은 [mysqld] 부분에서 이루어집니다.
InnoDB 버퍼 풀 크기 설정
InnoDB 버퍼 풀 크기는 InnoDB 데이터 파일의 상태를 메모리에 저장하는 데 사용되는 총 RAM입니다. 서버가 MySQL 전용인 경우 innodb_buffer_pool_size를 총 시스템 메모리의 50~70%로 설정해야 합니다.
데이터베이스의 총 크기가 작으면 InnoDB 버퍼 풀을 메모리의 50% 이상이 아닌 데이터베이스 크기로 설정할 수 있습니다.
이 예시에서는 서버에 64GB의 메모리가 있으므로 InnoDB 버퍼 풀은 32GB~45GB 사이여야 합니다. 일반적으로 클수록 좋습니다.
[mysqld] ... innodb_buffer_pool_size=45G
InnoDB 버퍼 풀 인스턴스 설정
여러 스레드가 큰 버퍼 풀을 검색하려고 시도하면 경합이 발생할 수 있습니다. 이를 방지하기 위해 버퍼 풀은 여러 스레드에서 충돌 없이 액세스할 수 있는 더 작은 단위로 분할됩니다. 기본적으로 버퍼 풀은 8개의 인스턴스로 나뉩니다. 이로 인해 8개의 스레드 병목 현상이 발생할 가능성이 있습니다. 버퍼 풀 인스턴스 수를 늘리면 병목 현상이 발생할 가능성이 줄어듭니다. 각 버퍼 풀이 최소 1GB의 메모리를 가져오도록 innodb_buffer_pool_instances를 설정해야 합니다.
[mysqld] ... innodb_buffer_pool_instances=32
InnoDB 로그 파일 최적화
트랜잭션이 커밋되면 데이터베이스는 실제 파일의 데이터를 업데이트하거나 트랜잭션에 대한 세부 정보를 로그에 저장할 수 있습니다. 데이터 파일이 업데이트되기 전에 데이터베이스가 충돌하면 로그 파일을 '재생'하여 변경사항을 적용할 수 있습니다. 로그 파일에 쓰기는 작은 추가 작업입니다. 커밋 시 로그에 추가한 다음 데이터 파일에 대한 여러 변경 사항을 일괄 처리하고 단일 IO 작업으로 작성하는 것이 효율적입니다. 로그 파일이 채워지면 데이터베이스가 새 트랜잭션 처리를 일시중지하고 변경된 모든 데이터를 디스크에 다시 써야 합니다.
일반적으로 InnoDB 로그 파일은 1시간 분량의 트랜잭션을 포함할 만큼 커야 합니다.
일반적으로 두 개의 InnoDB 로그 파일이 있습니다. InnoDB 버퍼 풀의 약 25%여야 합니다. 32GB 버퍼 풀이 있는 예시 데이터베이스의 경우 InnoDB 로그 파일은 파일당 총 8GB 또는 4GB여야 합니다.
[mysqld] ... innodb_log_file_size=8GB
InnoDB IO 용량 구성
MySQL은 서버에 과부하가 발생하지 않도록 디스크에 기록되는 쓰기 속도를 제한합니다. 기본값은 대부분의 서버에 보수적으로 적용됩니다. 최상의 성능을 위해 sysbench 유틸리티를 사용하여 데이터 디스크에 대한 무작위 쓰기 속도를 측정한 다음 이 값을 사용하여 MySQL이 데이터를 더 빠르게 쓸 수 있도록 IO 용량을 구성합니다.
클라우드 호스팅 시스템에서 클라우드 공급업체는 데이터 스토리지에 사용되는 디스크의 성능을 보고할 수 있어야 합니다. 자체 호스팅 MySQL 서버의 경우 데이터 디스크에 대한 임의 쓰기 속도를 초당 IO 작업 수(IOPS) 단위로 측정합니다. 이를 측정하는 한 가지 방법은 Linux 유틸리티 sysbench입니다. 이 값을 innodb_io_capacity_max에 사용하고, 해당 값의 1/2에서 3/4을 innodb_io_capacity에 사용합니다. 따라서 다음 예시에서는 800 IOPS를 측정한 경우 값을 확인할 수 있습니다.
[mysqld] ... innodb_io_capacity=500 innodb_io_capacity_max=800
InnoDB 스레드 구성
MySQL은 제공 중인 각 클라이언트에 대해 하나 이상의 스레드를 엽니다. 많은 클라이언트가 동시에 연결되는 경우 많은 수의 스레드가 처리될 수 있습니다. 이로 인해 시스템이 처리하는 것보다 스와핑에 더 많은 시간을 할애하게 될 수 있습니다.
이상적인 스레드 수를 결정하려면 벤치마킹을 수행해야 합니다. 테스트하려면 시스템의 CPU(또는 CPU 코어) 수와 CPU 수의 4배 수 사이에 스레드 수를 설정합니다. 16코어 시스템의 경우 이 값은 16~64 사이일 가능성이 높습니다.
[mysqld] ... innodb_thread_concurrency=32
트랜잭션 내구성
트랜잭션 값이 1이면 MySQL이 모든 트랜잭션에 대해 디스크에 쓰도록 합니다. 서버가 충돌되는 경우 트랜잭션은 손실되지 않지만 데이터베이스 성능에 영향을 미칩니다. 이 값을 0 또는 2로 설정하면 성능을 향상시킬 수 있지만 몇 초 분량의 데이터 트랜잭션이 손실될 위험이 있습니다.
[mysqld] ... innodb_flush_log_at_trx_commit=1
플러시 방법 설정
운영체제는 일반적으로 디스크에 대한 쓰기 버퍼링을 수행합니다. MySQL과 OS가 모두 버퍼링되기 때문에 성능 저하가 발생합니다. 플러시 메서드의 버퍼링 레이어를 한 단계 줄이면 성능이 향상될 수 있습니다.
[mysqld] ... innodb_flush_method=O_DIRECT
테이블당 하나의 파일 사용 설정
기본적으로 MySQL은 모든 데이터에 단일 데이터 파일을 사용합니다. innodb_file_per_table 설정은 테이블마다 별도의 파일을 만들어 성능과 데이터 관리를 개선합니다.
[mysqld] ... innodb_file_per_table=ON
메타데이터의 통계 사용 중지
이 설정은 내부 메타데이터 테이블의 통계 수집을 사용 중지하여 읽기 성능을 개선합니다.
[mysqld] ... innodb_stats_on_metadata=OFF
쿼리 캐시 사용 중지
쿼리 캐시는 지원 중단되었으므로 query_cache_size 및 query_cache_type을 0으로 설정하면 사용 중지됩니다.
[mysqld] ... query_cache_size=0 query_cache_type=0
조인 버퍼 확대
join_buffer는 메모리에서 조인을 수행하는 데 사용됩니다. 이를 늘리면 특정 작업을 개선할 수 있습니다.
[mysqld] ... join_buffer_size=512KB
임시 테이블 및 최대 힙 크기 확대
tmp_table_size 및 max_heap_table_size는 디스크에 강제 적용되기 전에 임시 메모리 내 테이블에 적절한 기본값을 설정합니다.
[mysqld ... tmp_table_size=32MB max_heap_table_size=32MB
테이블 열기 캐시 조정
table_open_cache 설정은 열린 테이블의 파일 설명자를 저장하는 캐시의 크기를 결정합니다. table_open_cache_instances 설정은 캐시를 여러 작은 부분으로 나눕니다. table_open_cache에는 스레드 경합이 발생할 가능성이 있으므로 이를 더 작은 부분으로 나누면 동시 실행을 높이는 데 도움이 됩니다.
[mysqld] ... table_open_cache=2048 table_open_cache_instances=16
Git 서비스
Looker는 Git 서비스와 함께 작동하여 LookML 파일의 버전 관리를 제공하도록 설계되었습니다. GitHub, GitLab, Bitbucket을 포함한 주요 Git 호스팅 서비스가 지원됩니다. Git 서비스 제공업체는 코드 변경사항을 볼 수 있는 GUI, pull 요청 및 변경 승인 등의 워크플로우 지원과 같은 부가 가치를 제공합니다. 필요한 경우 Git를 일반 Linux 서버에서 실행할 수 있습니다.
보안 규칙으로 인해 Git 호스팅 서비스가 배포에 적합하지 않은 경우 이러한 서비스 제공업체 중 다수가 자체 환경에서 실행할 수 있는 버전을 제공합니다. 특히 GitLab은 일반적으로 자체 호스팅되며 라이선스 비용이 없는 오픈소스 제품이나 지원되는 라이선스 제품으로 사용할 수 있습니다. GitHub Enterprise는 셀프 호스팅 서비스로 제공되며, 지원되는 상용 제품입니다.
다음 섹션에는 가장 일반적인 서비스 제공업체에 대한 뉘앙스가 나와 있습니다.
GitHub/GitHub Enterprise
Git 연결 설정 및 테스트 문서 페이지에서는 GitHub를 예시로 사용합니다.
GitLab/gitlab.com
GitLab의 상세 설정 단계는 Looker에서 버전 제어를 위해 GitLab 사용 Looker 커뮤니티 게시물을 참조하세요. 저장소가 하위 그룹 내에 포함된 경우 HTTPS 또는 SSH 형식을 사용하여 저장소 URL에 추가할 수 있습니다.
https://gitlab.com/accountname/subgroup/reponame git@gitlab.com:accountname/subgroup/reponame.git
또한 Looker에서 생성된 SSH 키를 GitLab에 저장하는 방법에는 사용자 SSH 키, 저장소 배포 키, 전역 공유 배포 키 등 세 가지가 있습니다. 자세한 내용은 GitLab 문서를 참고하세요.
Google Cloud 소스
Cloud Source Repositories를 사용한 Git 설정 단계는 Look에서 버전 제어를 위해 Cloud Source Repositories 사용 커뮤니티 게시글을 참조하세요.
Bitbucket Cloud
Bitbucket Cloud를 사용한 Git 설정 단계는 Looker에서 버전 제어를 위해 Bitbucket 사용 커뮤니티 게시물을 참조하세요. 2021년 8월부터 Bitbucket Cloud는 배포 웹훅에서 보안 비밀을 지원하지 않습니다.
Bitbucket 서버
Bitbucket 서버에서 pull 요청을 사용하려면 다음 단계를 완료해야 할 수 있습니다.
- pull 요청을 열면 Looker는 URL에 기본 포트 번호(7999)를 자동으로 사용합니다. 커스텀 포트 번호를 사용 중인 경우 URL의 포트 번호를 수동으로 바꿔야 합니다.
- Looker의 프로덕션 브랜치를 저장소의 기본 브랜치와 동기화하려면 프로젝트의 배포 웹훅을 눌러야 합니다.
Phabricator 확산
Phabricator로 Git을 설정하는 단계는 버전 제어를 위한 Phabricator 및 Looker 설정 커뮤니티 게시물을 참조하세요.
네트워크
인바운드 연결
Looker 웹 애플리케이션
기본적으로 Looker는 포트 9999에서 HTTPS 요청을 수신 대기합니다. Looker는 CN이 self-signed.looker.com인 자체 서명 인증서를 사용합니다. 또는 Looker 서버를 다음과 같이 구성할 수 있습니다.
- SSL 종료 부하 분산기/프록시에서
--ssl-provided-externally-by=<s>시작 플래그를 사용하여 HTTP 연결을 수락합니다. 값은 프록시의 IP 주소 또는 프록시의 IP 주소로 로컬로 확인할 수 있는 호스트 이름으로 설정해야 합니다. Looker는 이 IP 주소의 HTTP 연결만 허용합니다. --ssl-keystore=<s>시작 플래그와 함께 고객 제공 SSL 인증서를 사용합니다.
Looker API
Looker API는 포트 19999에서 수신 대기합니다. 설치에 API에 대한 액세스가 필요한 경우 부하 분산기에 필수 전달 규칙이 있어야 합니다. 기본 웹 애플리케이션과 동일한 SSL 고려사항이 적용됩니다. 웹 애플리케이션과 고유 포트를 사용하는 것이 좋습니다.
부하 분산기
부하 분산기는 고객 인증서를 사용하여 포트 443에서 HTTPS 요청을 수락한 후 자체 서명된 인증서 또는 HTTP를 사용하여 포트 9999의 Looker 서버 노드로 요청을 전달하는 데 종종 사용됩니다. 부하 분산기가 Looker 자체 서명 인증서를 사용하는 경우 해당 인증서를 수락하도록 구성해야 합니다.
유휴 연결 및 제한 시간
사용자가 Looker에서 대규모 요청을 시작하면 데이터베이스에서 실행하는 데 많은 비용이 소요될 수 있는 쿼리가 발생할 수 있습니다. 사용자가 노트북의 덮개를 닫거나, 네트워크의 연결을 해제하거나, 브라우저에서 해당 탭을 종료하는 등 어떤 식으로든 해당 요청을 포기하면 Looker는 해당 데이터베이스 쿼리를 알고 종료하려고 합니다.
이러한 상황을 처리하기 위해 클라이언트 웹 애플리케이션에서 데이터베이스 쿼리 실행을 요청하면 브라우저는 Looker 서버에 대한 장기 HTTP 요청을 사용하여 소켓 연결을 엽니다. 이 연결은 열린 상태로 유휴 상태로 유지됩니다. 클라이언트 웹 애플리케이션이 어떤 식으로든 종료되거나 연결이 끊기면 이 소켓의 연결이 끊어집니다. 서버에서 연결이 해제되었음을 확인하고 관련 데이터베이스 쿼리를 모두 취소합니다.
부하 분산기는 종종 이러한 열린 유휴 연결을 감지하고 종료합니다. Looker를 효과적으로 실행하려면 사용자가 실행할 수 있는 가장 긴 쿼리 동안 이 연결이 열린 상태로 유지되도록 부하 분산기를 구성해야 합니다. 제한 시간을 60분 이상으로 설정하는 것이 좋습니다.
아웃바운드 연결
Looker 서버에는 공개 인터넷을 포함한 모든 리소스에 대한 무제한 아웃바운드 액세스가 있을 수 있습니다. 이렇게 하면 Linux 배포용 패키지 저장소에 액세스해야 하는 Chromium 설치와 같은 여러 작업이 간소화됩니다.
다음은 Looker가 수행해야 할 수 있는 아웃바운드 연결입니다.
내부 데이터베이스 연결
기본적으로 MySQL은 포트 3306에서 연결을 수신 대기합니다. Looker 노드는 이 포트에서 MySQL에 대한 연결을 시작할 수 있어야 합니다. 저장소가 호스팅되는 방법에 따라 방화벽을 통과해야 할 수 있습니다.
외부 서비스
Looker 원격 분석 및 라이선스 서버는 공개 인터넷에서 HTTPS를 사용하여 사용 가능합니다. Looker 노드에서 ping.looker.com:443 및 license.looker.com:443으로 전송되는 트래픽을 허용 목록에 추가해야 할 수 있습니다.
데이터 웨어하우스 연결
클라우드 호스팅 데이터베이스는 공개 인터넷을 사용한 연결이 필요할 수 있습니다. 예를 들어 BigQuery를 사용하는 경우 accounts.google.com:443 및 www.googleapis.com:443을 허용 목록에 추가해야 할 수 있습니다. 데이터베이스가 자체 인프라 외부에 있는 경우 네트워크 세부정보는 데이터베이스 호스트에 문의하세요.
SMTP 서비스
기본적으로 Looker는 SendGrid를 사용하여 발신 메일을 보냅니다. 이를 위해서는 smtp.sendgrid.net:587을 허용 목록에 추가해야 할 수 있습니다. 다른 메일 핸들러를 사용하도록 구성에서 SMTP 설정을 변경할 수도 있습니다.
작업 허브, 작업 서버 및 웹훅
많은 스케줄러 대상, 특히 웹훅 및 Looker 관리자 패널에서 사용 설정된 대상에는 HTTPS 요청을 사용하여 데이터 전송이 포함됩니다.
- 웹훅의 경우 이러한 대상은 사용자가 런타임에 지정하며 아웃바운드 연결 방화벽의 목표와 상충될 수 있습니다.
- 작업 허브의 경우 이러한 요청은
actions.looker.com으로 전송됩니다. 자세한 내용은 Looker 작업 허브 구성 문서에서 확인하세요. - 다른 작업 서버의 경우 이러한 요청은 Looker 관리자 패널에서 관리자가 작업 서버 구성에 지정된 도메인으로 전송됩니다.
프록시 서버
공개 인터넷에 직접 연결할 수 없는 경우 lookerstart.cfg에 다음과 같은 줄을 추가하여 Looker는 HTTP(S) 요청에 프록시 서버를 사용하도록 구성할 수 있습니다.
JAVAARGS="-Dhttp.proxyHost=myproxy.example.com -Dhttp.proxyPort=8080 -Dhttp.nonProxyHosts=127.0.0.1|localhost -Dhttps.proxyHost=myproxy.example.com -Dhttps.proxyPort=8080"
노드 간 통신이 HTTPS를 통해 수행되므로 프록시 서버를 사용하고 인스턴스가 클러스터링된 경우 일반적으로 클러스터의 모든 노드에 대한 IP/호스트 이름을 Dhttp.nonProxyHosts 인수에 추가할 수 있다는 점에 유의하세요.
노드 간 통신
내부 호스트 식별자
클러스터 내에서 각 노드는 다른 노드와 통신할 수 있어야 합니다. 이를 허용하도록 각 노드의 호스트 이름이나 IP 주소가 시작 구성에 지정됩니다. 노드가 시작되면 이 값이 MySQL 저장소에 기록됩니다. 그러면 클러스터의 다른 구성원이 해당 값을 참조하여 이 노드와 통신할 수 있습니다. 시작 구성에서 호스트 이름 또는 IP 주소를 지정하려면 lookerstart.cfg의 LOOKERARGS 환경 변수에 -H node1.looker.example.com을 추가합니다.
호스트 이름은 노드별로 고유해야 하므로 lookerstart.cfg 파일은 각 인스턴스에서 고유해야 합니다. 호스트 이름 또는 IP 주소를 하드코딩하는 대신 hostname -I 또는 hostname --fqdn 명령어를 사용하여 런타임에 이를 찾을 수 있습니다. 이를 구현하려면 lookerstart.cfg의 LOOKERARGS 환경 변수에 -H $(hostname -I) 또는 -H $(hostname --fqdn)를 추가합니다.
내부 포트
각각 웹 및 API 서버에 사용되는 포트 9999 및 19999 외에도 클러스터 노드는 포트 1551 및 61616을 사용하는 메시지 브로커 서비스를 통해 서로 통신합니다. 포트 9999와 19999는 최종 사용자 트래픽에 열려 있어야 하며, 1551 및 61616 포트는 클러스터 노드 간에 열려 있어야 합니다.