하드웨어 요구사항
프로덕션 등급 환경에서 가용성이 높은 인프라를 사용하려면 다음 최소 하드웨어 요구사항을 충족해야 합니다.
다음 동영상에서는 설치를 위한 대략적인 크기 조정 안내를 제공합니다.
설치 토폴로지에 설명된 모든 설치 시나리오에서 다음 표에는 설치 구성요소의 최소 하드웨어 요구사항이 나와 있습니다.
이 표에서 하드 디스크 요구사항은 운영체제에 필요한 하드 디스크 공간에 추가됩니다. 애플리케이션 및 네트워크 트래픽에 따라 설치에 아래에 나열된 것보다 많거나 적은 리소스가 필요할 수 있습니다.
| 설치 구성요소 | RAM | CPU | 최소 하드 디스크 |
|---|---|---|---|
| Cassandra (독립형) | 16GB | 8코어 | 2,000 IOPS를 지원하는 SSD가 있는 250GB 로컬 스토리지 |
| 동일한 머신의 Cassandra/Zookeeper | 16GB | 8코어 | 2,000 IOPS를 지원하는 SSD가 있는 250GB 로컬 스토리지 |
| 동일한 머신의 메시지 프로세서/라우터 | 16GB | 8코어 | 100GB |
| 메시지 프로세서 (독립형) | 16GB | 8코어 | 100GB |
| 라우터 (독립형) | 8GB | 8코어 | 100GB |
| 분석 - 동일한 서버의 Postgres/Qpid | 16GB* | 8코어* | 500GB~1TB** 네트워크 스토리지***(SSD 백엔드 포함, 1,000 IOPS 이상 지원)* |
| 분석 - Postgres 마스터 또는 대기 독립형 | 16GB* | 8코어* | 500GB~1TB** 네트워크 스토리지***(SSD 백엔드 포함, 1,000 IOPS 이상 지원)* |
| 분석 - Qpid (독립형) | 8GB | 4코어 | SSD가 장착된 30GB~50GB 로컬 스토리지
기본 Qpid 큐 크기는 1GB이며 2GB로 늘릴 수 있습니다. 용량이 더 필요하면 Qpid 노드를 추가합니다. |
| OpenLDAP/UI/관리 서버 | 8GB | 4코어 | 60GB |
| UI/관리 서버 | 4GB | 2코어 | 60GB |
| OpenLDAP (독립형) | 4GB | 2코어 | 60GB |
|
* 처리량에 따라 Postgres 시스템 요구사항을 조정합니다.
** Postgres 하드 디스크 값은 Edge에서 캡처한 기본 분석을 기반으로 합니다. 분석 데이터에 커스텀 값을 추가하는 경우 이러한 값은 그에 따라 증가해야 합니다. 다음 수식을 사용하여 필요한 스토리지를 추정합니다. bytes of storage needed = (# bytes of analytics data/request) * (requests/second) * (seconds/hour) * (hours of peak usage/day) * (days/month) * (months of data retention) 예를 들면 다음과 같습니다. (2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention) = 1,194,393,600,000 bytes or 1194.4 GB of storage needed *** 다음과 같은 이유로 PostgreSQL 데이터베이스에는 네트워크 스토리지가 권장됩니다.
|
|||
또한 다음은 수익 창출 서비스를 설치하려는 경우의 하드웨어 요구사항입니다 (올인원 설치에서는 지원되지 않음).
| 수익 창출 구성요소 | RAM | CPU | 하드 디스크 |
|---|---|---|---|
| 관리 서버 (수익 창출 서비스 포함) | 8GB | 4코어 | 60GB |
| 분석 - 동일한 서버의 Postgres/Qpid | 16GB | 8코어 | 500GB~1TB 네트워크 스토리지(SSD 백엔드 권장, 1,000IOPS 이상 지원) 또는 위 표의 규칙 사용 |
| 분석 - Postgres 마스터 또는 대기 독립형 | 16GB | 8코어 | 500GB~1TB 네트워크 스토리지(SSD 백엔드 권장, 1,000IOPS 이상 지원) 또는 위 표의 규칙 사용 |
| 분석 - Qpid (독립형) | 8GB | 4코어 | SSD 또는 빠른 HDD가 장착된 40GB~500GB 로컬 스토리지
250TPS를 초과하는 설치의 경우 1, 000 IOPS를 지원하는 로컬 스토리지가 있는 HDD가 권장됩니다. |
Cassandra 네트워크 대역폭 요구사항
Cassandra는 Gossip 프로토콜을 사용하여 네트워크 토폴로지에 대한 정보를 다른 노드와 교환합니다. 읽기 및 쓰기 작업을 위해 여러 노드와 통신해야 하는 Cassandra의 분산 특성과 Gossip를 함께 사용하면 네트워크를 통해 많은 데이터가 전송됩니다.
Cassandra에는 노드당 1Gbps의 최소 네트워크 대역폭이 필요합니다. 프로덕션 설치 시 더 높은 대역폭이 권장됩니다.
Cassandra의 최대 또는 99번째 백분위수 지연 시간은 100밀리초 미만이어야 합니다.
운영체제 및 서드 파티 소프트웨어 요구사항
이 설치 안내와 제공된 설치 파일은 지원되는 소프트웨어 및 지원되는 버전에 나열된 운영체제 및 서드 파티 소프트웨어에서 테스트되었습니다.
기본 요건: EPEL 저장소 사용 설정
설치를 진행하기 전에 EPEL (Extra Packages for Enterprise Linux) 저장소가 사용 설정되어 있는지 확인합니다. Red Hat, CentOS 또는 Oracle Linux 9.x의 경우 다음 명령어를 사용합니다.
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo rpm -ivh epel-release-latest-9.noarch.rpm
자바
설치하기 전에 각 머신에 지원되는 버전의 Java 17 및 Java 21이 설치되어 있어야 합니다. 지원되는 JDK는 지원되는 소프트웨어 및 지원되는 버전에 나열되어 있습니다.
JAVA_HOME 환경 변수가 설치를 수행하는 사용자의 JDK 루트를 가리키는지 확인합니다.
SELinux
SELinux 설정에 따라 Edge에서 Edge 구성요소를 설치하고 시작하는 데 문제가 발생할 수 있습니다. 필요한 경우 설치 중에 SELinux를 사용 중지하거나 허용 모드로 설정한 후 설치 후에 다시 사용 설정할 수 있습니다. 자세한 내용은 Edge apigee-setup 유틸리티 설치를 참조하세요.
'apigee' 사용자 만들기
설치 절차에서는 'apigee'라는 Unix 시스템 사용자를 만듭니다. Edge 디렉터리와 파일은 Edge 프로세스와 마찬가지로 'apigee'가 소유합니다. 즉, Edge 구성요소는 'apigee' 사용자로 실행됩니다. 필요한 경우 다른 사용자로 구성요소를 실행할 수 있습니다.
설치 디렉터리
기본적으로 설치 프로그램은 모든 파일을 /opt/apigee 디렉터리에 기록합니다. 이 디렉터리 위치는 변경할 수 없습니다. 이 디렉터리는 변경할 수 없지만 /opt/apigee에서 심볼릭 링크 만들기에 설명된 대로 심볼릭 링크를 만들어 /opt/apigee를 다른 위치에 매핑할 수 있습니다.
이 가이드의 안내에서 설치 디렉터리는 /opt/apigee로 표시됩니다.
/opt/apigee에서 심볼릭 링크 만들기
심볼릭 링크를 만들기 전에 먼저 'apigee'라는 사용자와 그룹을 만들어야 합니다. 이는 Edge 설치 프로그램에서 만든 것과 동일한 그룹 및 사용자입니다.
심볼릭 링크를 만들려면 bootstrap_4.54.00.sh 파일을 다운로드하기 전에 다음 단계를 수행합니다. 루트로 다음 단계를 모두 수행해야 합니다.
- 'apigee' 사용자 및 그룹을 만듭니다.
groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
/opt/apigee에서 원하는 설치 루트로 심볼릭 링크를 만듭니다.ln -Ts /srv/myInstallDir /opt/apigee
여기서 /srv/myInstallDir는 Edge 파일의 원하는 위치입니다.
- 설치 루트 및 심볼릭 링크의 소유권을 'apigee' 사용자로 변경합니다.
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
네트워크 설정
Apigee는 설치 전에 네트워크 설정을 확인하는 것을 권장합니다. 설치 프로그램은 모든 머신에 고정 IP 주소가 있다고 가정합니다. 다음 명령어를 사용하여 설정을 검증합니다.
hostname는 머신 이름을 반환합니다.hostname -i은 다른 머신에서 주소를 지정할 수 있는 호스트 이름의 IP 주소를 반환합니다.
운영체제 유형 및 버전에 따라 호스트 이름이 올바르게 설정되지 않은 경우 /etc/hosts 및 /etc/sysconfig/network를 수정해야 할 수 있습니다. 자세한 내용은 특정 운영체제의 문서를 참고하세요.
서버에 인터페이스 카드가 여러 개 있는 경우 'hostname -i' 명령어는 공백으로 구분된 IP 주소 목록을 반환합니다. 기본적으로 Edge 설치 프로그램은 반환된 첫 번째 IP 주소를 사용하며, 이는 모든 상황에서 올바르지 않을 수 있습니다. 또는 설치 구성 파일에서 다음 속성을 설정할 수 있습니다.
ENABLE_DYNAMIC_HOSTIP=y
이 속성을 'y'로 설정하면 설치 프로그램에서 설치의 일부로 사용할 IP 주소를 선택하라는 메시지를 표시합니다. 기본값은 'n'입니다. 자세한 내용은 에지 구성 파일 참조를 확인하세요.
TCP 래퍼
TCP 래퍼는 일부 포트의 통신을 차단할 수 있으며 OpenLDAP, Postgres, Cassandra 설치에 영향을 줄 수 있습니다. 이러한 노드에서 /etc/hosts.allow 및 /etc/hosts.deny를 확인하여 필수 OpenLDAP, Postgres, Cassandra 포트에 포트 제한이 없는지 확인합니다.
iptables
필수 에지 포트에서 노드 간 연결을 방지하는 iptables 정책이 없는지 확인합니다. 필요한 경우 다음 명령어를 사용하여 설치 중에 iptables를 중지할 수 있습니다.
sudo/etc/init.d/iptables stop
디렉터리 액세스
다음 표에는 Edge 프로세스의 특별한 요구사항이 있는 Edge 노드의 디렉터리가 나와 있습니다.
| 서비스 | 디렉터리 | 설명 |
|---|---|---|
| 라우터 | /etc/rc.d/init.d/functions |
Edge 라우터는 Nginx 라우터를 사용하며 보안 프로세스에서 권한을 744로 설정하여 |
| Zookeeper | /dev/random |
Zookeeper 클라이언트 라이브러리에는 난수 생성기 /dev/random에 대한 읽기 액세스 권한이 필요합니다. /dev/random가 읽기에서 차단되면 Zookeeper 서비스가 시작되지 않을 수 있습니다. |
Cassandra
모든 Cassandra 노드는 링에 연결되어야 합니다. Cassandra는 안정성과 내결함성을 보장하기 위해 여러 노드에 데이터 복제본을 저장합니다. 각 Edge 키스페이스의 복제 전략에 따라 복제본이 배치되는 Cassandra 노드가 결정됩니다. 자세한 내용은 Cassandra 복제 계수 및 일관성 수준 정보를 참조하세요.
Cassandra는 사용 가능한 메모리에 따라 Java 힙 크기를 자동으로 조정합니다. 자세한 내용은 성능 저하 또는 높은 메모리 소비가 발생하는 경우 Java 리소스 조정을 참조하세요.
프라이빗 클라우드용 Edge를 설치한 후 /opt/apigee/apigee-cassandra/conf/cassandra.yaml 파일을 검사하여 Cassandra가 올바르게 구성되었는지 확인할 수 있습니다. 예를 들어 프라이빗 클라우드용 Edge 설치 스크립트가 다음 속성을 설정하는지 확인합니다.
cluster_nameinitial_tokenpartitionerseedslisten_addressrpc_addresssnitch
PostgreSQL 데이터베이스
Edge를 설치한 후 시스템에서 사용 가능한 RAM 용량에 따라 다음 PostgreSQL 데이터베이스 설정을 조정할 수 있습니다.
conf_postgresql_shared_buffers = 35% of RAM # min 128kB conf_postgresql_effective_cache_size = 45% of RAM conf_postgresql_work_mem = 512MB # min 64kB
이러한 값을 설정하려면 다음 안내를 따르세요.
- postgresql.properties 파일을 수정합니다.
vi /opt/apigee/customer/application/postgresql.properties
파일이 없으면 만듭니다.
- 위에 나열된 속성을 설정합니다.
- 수정사항을 저장합니다.
- PostgreSQL 데이터베이스를 다시 시작합니다.
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
Rocky 9.X의 언어 구성
Rocky 9.X를 사용하는 경우 시스템 전체 언어 설정에서 시스템이 LANG=en_US.utf8로 구성되어 있는지 확인합니다. 이를 구성하려면 다음 명령어를 실행합니다.
dnf -y -q install langpacks-en localectl set-locale LANG=en_US.utf8 reboot
시스템 한도
Cassandra 및 메시지 프로세서 노드에 다음 시스템 한도를 설정했는지 확인합니다.
- Cassandra 노드에서 아래와 같이
/etc/security/limits.d/90-apigee-edge-limits.conf의 설치 사용자 (기본값은 'apigee')에 대해 소프트 및 하드 memlock, nofile, 주소 공간 (as) 한도를 설정합니다.apigee soft memlock unlimited apigee hard memlock unlimited apigee soft nofile 32768 apigee hard nofile 65536 apigee soft as unlimited apigee hard as unlimited apigee soft nproc 32768 apigee hard nproc 65536
- 메시지 프로세서 노드에서 아래와 같이
/etc/security/limits.d/90-apigee-edge-limits.conf에서 열린 파일 설명자의 최대 개수를 64K로 설정합니다.apigee soft nofile 32768 apigee hard nofile 65536
필요한 경우 이 한도를 늘릴 수 있습니다. 예를 들어 한 번에 많은 수의 임시 파일이 열려 있는 경우입니다.
라우터 또는 메시지 프로세서
system.log에 다음 오류가 표시되면 파일 설명자 한도가 너무 낮게 설정되었을 수 있습니다."java.io.IOException: Too many open files"
다음을 실행하여 사용자 한도를 확인할 수 있습니다.
# su - apigee $ ulimit -n 100000
파일 설명자 한도를
100000로 설정한 후에도 열린 파일 한도에 도달하는 경우 Apigee Edge 지원팀에 티켓을 제출하여 추가 문제 해결을 진행하세요.
네트워크 보안 서비스 (NSS)
네트워크 보안 서비스 (NSS)는 보안 지원 클라이언트 및 서버 애플리케이션 개발을 지원하는 라이브러리 집합입니다. NSS v3.19 이상이 설치되어 있는지 확인해야 합니다.
현재 버전을 확인하려면 다음 단계를 따르세요.
yum info nss
NSS를 업데이트하려면 다음 단계를 따르세요.
yum update nss
NSCD (Name Service Cache Daemon)를 사용할 때 IPv6에서 DNS 조회 사용 중지
NSCD (Name Service Cache Daemon)를 설치하고 사용 설정한 경우 메시지 프로세서는 IPv4용과 IPv6용으로 두 개의 DNS 조회를 수행합니다. NSCD를 사용할 때는 IPv6에서 DNS 조회를 사용 중지해야 합니다.
IPv6에서 DNS 조회를 사용 중지하려면 다음 안내를 따르세요.
- 모든 메시지 프로세서 노드에서
/etc/nscd.conf을 수정합니다. - 다음 속성을 설정합니다.
enable-cache hosts no
RHEL 8 이상에서 IPv6 사용 중지
Google Cloud Platform에서 RHEL 8 이상 버전에 Edge를 설치하는 경우 모든 Qpid 노드에서 IPv6를 사용 중지해야 합니다.
IPv6를 사용 중지하는 방법은 OS 공급업체에서 제공하는 문서를 참고하세요. 예를 들어 Red Hat Enterprise Linux 문서에서 관련 정보를 찾을 수 있습니다.
Amazon Linux 기본 요건
Amazon Linux 2023.9/2023.10/2023.11에서 새로 설치하거나 4.53.01에서 4.54.00으로 업그레이드 (Amazon Linux 2023.9/2023.10/2023.11에서)하기 전에 /etc/yum.repos.d/amazonlinux.repo 파일을 수정합니다. [amazonlinux]가 포함된 섹션에는 패키지가 Amazon이 아닌 apigee-thirdparty에서 다운로드되도록 다음이 포함되어야 합니다.exclude=postgresql18,luajit*
도구
설치 프로그램은 EL5 또는 EL6에서 제공하는 표준 버전의 다음 UNIX 도구를 사용합니다.
|
awk |
expr |
libxslt |
분당 회전수 |
unzip |
|
basename |
grep |
lua-socket |
rpm2cpio |
useradd |
|
bash |
hostname |
ls |
sed |
wc |
|
bc |
id |
net-tools |
sudo |
wget |
|
curl |
libaio |
perl (procps에서) |
tar |
xerces-c |
| cyrus-sasl | libdb4 | pgrep (procps에서) | tr | yum |
|
날짜 |
libdb-cxx |
ps |
uuid |
chkconfig |
| dirname | libibverbs | pwd | uname | |
| 에코 | librdmacm | python |
시간 동기화
Apigee에서는 서버 시간이 동기화되도록 하는 것이 좋습니다. 아직 구성되지 않은 경우 ntpdate 유틸리티 또는 이와 동등한 도구를 사용하여 서버가 시간 동기화되었는지 확인할 수 있습니다. 예를 들어 yum install ntp 또는 이에 상응하는 명령어를 사용하여 유틸리티를 설치할 수 있습니다. 이는 LDAP 설정을 복제하는 데 특히 유용합니다. 서버 시간대를 UTC로 설정해야 합니다.
방화벽 및 가상 호스트
virtual라는 용어는 IT 분야에서 일반적으로 오버로드되므로 프라이빗 클라우드용 Apigee Edge 배포 및 가상 호스트에서도 마찬가지입니다. virtual라는 용어는 주로 두 가지 용도로 사용됩니다.
- 가상 머신 (VM): 필수는 아니지만 일부 배포에서는 VM 기술을 사용하여 Apigee 구성요소에 대해 격리된 서버를 만듭니다. 물리적 호스트와 마찬가지로 VM 호스트에는 네트워크 인터페이스와 방화벽이 있을 수 있습니다.
- 가상 호스트: Apache 가상 호스트와 유사한 웹 엔드포인트입니다.
VM의 라우터는 여러 가상 호스트를 노출할 수 있습니다 (호스트 별칭 또는 인터페이스 포트가 서로 다른 경우).
이름 지정 예시로, 단일 물리적 서버 A에서 'VM1' 및 'VM2'라는 두 개의 VM을 실행할 수 있습니다. 'VM1'이 가상 이더넷 인터페이스를 노출하고, 이 인터페이스가 VM 내에서 'eth0'으로 이름이 지정되고, 가상화 머신 또는 네트워크 DHCP 서버에 의해 IP 주소 111.111.111.111가 할당된다고 가정해 보겠습니다. 그런 다음 VM2가 'eth0'이라는 가상 이더넷 인터페이스를 노출하고 IP 주소 111.111.111.222가 할당된다고 가정해 보겠습니다.
두 VM 각각에서 Apigee 라우터가 실행 중일 수 있습니다. 라우터는 다음 가상 예시와 같이 가상 호스트 엔드포인트를 노출합니다.
VM1의 Apigee 라우터는 eth0 인터페이스 (특정 IP 주소가 있음)에 api.mycompany.com:80, api.mycompany.com:443, test.mycompany.com:80 등 세 개의 가상 호스트를 노출합니다.
VM2의 라우터는 api.mycompany.com:80 (VM1에서 노출한 것과 동일한 이름 및 포트)를 노출합니다.
실제 호스트의 운영체제에 네트워크 방화벽이 있을 수 있습니다. 이 경우 가상화된 인터페이스 (111.111.111.111:{80, 443} 및 111.111.111.222:80)에 노출되는 포트로 향하는 TCP 트래픽을 전달하도록 방화벽을 구성해야 합니다. 또한 각 VM의 운영체제는 eth0 인터페이스에 자체 방화벽을 제공할 수 있으며, 이 방화벽도 포트 80 및 443 트래픽이 연결되도록 허용해야 합니다.
기본 경로는 배포했을 수 있는 여러 API 프록시로 API 호출을 라우팅하는 데 관련된 세 번째 구성요소입니다. API 프록시 번들은 기본 경로가 다른 경우 엔드포인트를 공유할 수 있습니다. 예를 들어 하나의 기본 경로는 http://api.mycompany.com:80/로 정의하고 다른 기본 경로는 http://api.mycompany.com:80/salesdemo로 정의할 수 있습니다.
이 경우 두 IP 주소(VM1의 111.111.111.111 및 VM2의 111.111.111.222) 간에 http://api.mycompany.com:80/ 트래픽을 분할하는 부하 분산기 또는 Traffic Director가 필요합니다. 이 기능은 특정 설치에만 적용되며 로컬 네트워킹 그룹에서 구성합니다.
기본 경로는 API를 배포할 때 설정됩니다. 위의 예시에서 호스트 별칭이 api.mycompany.com이고 포트가 80로 설정된 가상 호스트를 사용하여 mycompany-org 조직에 mycompany 및 testmycompany라는 두 개의 API를 배포할 수 있습니다. 배포에서 기본 경로를 선언하지 않으면 라우터는 수신 요청을 전송할 API를 알 수 없습니다.
하지만 기준 URL이 /salesdemo인 API testmycompany를 배포하면 사용자는 http://api.mycompany.com:80/salesdemo를 사용하여 해당 API에 액세스합니다. 기준 URL이 /인 API mycompany를 배포하면 사용자가 URL http://api.mycompany.com:80/로 API에 액세스합니다.
라이선스
Edge를 설치할 때마다 Apigee에서 가져온 고유한 라이선스 파일이 필요합니다. 관리 서버를 설치할 때 라이선스 파일의 경로(예: /tmp/license.txt)를 제공해야 합니다.
설치 프로그램이 라이선스 파일을 /opt/apigee/customer/conf/license.txt에 복사합니다.
라이선스 파일이 유효하면 관리 서버가 만료 및 허용된 메시지 프로세서 (MP) 수를 검증합니다. 라이선스 설정이 만료된 경우 /opt/apigee/var/log/edge-management-server/logs 위치에서 로그를 찾을 수 있습니다.
이 경우 Apigee Edge 지원팀에 문의하여 마이그레이션 세부정보를 확인할 수 있습니다.
아직 라이선스가 없는 경우 Apigee 영업팀에 문의하세요.