[엘라스틱 스택 개발부터 운영까지] 4부. 엘라스틱 운영(4) (2025)

본문 기타 기능

14. 운영 클러스터 구축

14.1 성능과 안정성을 위한 운영 클러스터 고려사항

- 엘라스틱서치는 기본 설정이 아주 잘 잡혀있는 편으로 크게 튜닝을 신경 쓸 필요는 없음

- 빠른 성능을 위해 시스템 리소스를 많이 소비하는 편이므로, 충분한 하드웨어를 확보해주고, 클러스터링과 분산/병렬 처리 개념을 이해해 노드를 구성할 필요가 있음

​

14.1.1 노드 구성 계획

- 노드 구성 시 가장 먼저 확보해야하는 것은 최소 3개의 마스터 노드로, 하나의 마스터 노드가 다운되었을 때 스플릿 브레인없이 서비스가 지속되게 하기 위한 최소한의 구성을 말함

- 마스터 노드는 많은 리소스를 사용하지는 않지만 장애가 발생하면 클러스터 전체에 영향을 미치므로 마스터 전용 노드를 운영하는 방식도 바람직함

- 예상되는 용도와 부하에 따라 데이터 노드를 최소 2대 이상 확보해야 함

- 데이터 노드가 하나일 경우, 복제본인 레플리카를 활용할 수 없으므로 장애 발생 시 정상적인 서비스가 불가능하고 일반적인 상황에서도 성능을 충분히 발휘할 수 없음

- 인덱싱 부하량, 검색 부하량 등을 고려해 인제스트나 코디네이팅 전용 노드를 추가할지 여부를 고려하고 머신러닝 기능을 사용할 경우, 머신러닝 노드를 추가해주어야 함

​

14.1.2 하드웨어 선정

- 엘라스틱서치는 분산/병렬 처리에 특화된 만큼 단일 노드의 하드웨어가 굉장히 좋을 필요는 없음

- 빠른 검색 서능에 초점을 맞춘 제품인 만큼 리소스 사용량이 많아 낮은 사양의 하드웨어는 병목이 되기도 함

- 하드웨어 선택이 사용자의 환경이나 용도에 따라 달라질 수 있는 겠지만 일반적으로 너무 크지도 작지도 않은 중간 크기를 권장함

​

1) 메모리

- 엘라스틱서치에서 가장 먼저 고갈되어 문제가 되는 리소스

- 검색 성능을 위해 샤드 유지, 검색과 집계, 인덱싱, 코디네이팅 등 전반적인 영역에 많은 메모리를 사용하게 됨

- 가장 이상적인 메모리는 64GB로 단일 노드에 대해 충분한 힙 크기를 활용할 수 있는 수준임

​

2) CPU

- 더 크고 많은 코어를 제공하면 더할 나위 없겠지만, 엘라스틱서치가 분산 병렬 처리에 최적화된 제품인 만큼 단일 코어의 성능이 높은 CPU와 코어의 수가 많은 CPU 중 하나를 고르자면 더 많은 코어를 구너장함

- 무거운 집계나 인덱싱을 수행하는 경우, CPU 성능이 병목이 될 수도 있음

​

3) 디스크

- SSD를 권장하는데, 하드디스크를 사용할 경우 RPM이 빠른 제품을 선택해야 함

- 네트워크 저장소는 피해야 함

- 최대한 빠른 디스크 성능을 선택해야 함

- 엘라스틱서치는 많은 요소를 힙 메모리에 로드해 빠른 검색과 집계가 가능하도록 하지만 세그먼트를 읽기 위해 디스크 IO를 상당히 많이 사용함

- RAID의 경우, RAID 0을 이용해 디스크 성능 향상을 도모하는 것은 좋지만 기타 미러링 정책은 선택하지 않는 편이 좋음

- 엘라스틱서치는 분산 검색 엔진으로 의도치 않은 데이터 손실에 대비해 레플리카, 스냅샷 같은 소프트웨어적으로 충분한 대비가 되어 있으므로 오히려 미러링으로 인해 발생할 수 있는 성능 저하나 장애 요인이 더 큰 문제가 될 수 있음

​

4) 하드웨어 통일

- 각 노드들의 하드웨어 성능을 통일하는 것이 중요함

- 엘라스틱서치는 분산 검색 엔진인 만큼 조회 대상 샤드가 위치한 모든 노드에서 처리한 후 코디네이팅 노드에서 결과를 취합해 반환하게 됨

- 검색의 총 실행 시간 : 가장 느린 노드가 코디네이팅 노드로 결과를 전달한 시간 + @

- 하드웨어를 혼합해 사용할 경우, 실시간 인덱싱이나 활발한 검색을 수행하는 핫 노드와 인덱싱을 수행하지 않고 비교적 많은 검색이 일어나지 않아도 되는 웜 노드, 데이터 보관 목적으로 검색을 수행하지 않을 콜드 노드로 구분해 서로 다른 타입의 노드끼리는 동일 인덱스를 공유하지 않게 해야 함

- 데이터 노드가 아닌 마스터 전용 노드, 코디네이팅 노드, 인제스트 노드 등을 데이터 노드에 비해 비교적 메모리나 디스크의 영향을 적게 받음

- 마스터 노드 : 클러스터 전체의 상태를 관리해야 하므로 클러스터의 규모 등을 고려해 적절한 하드웨어를 선택해야 함

- 코디네이팅 노드 : 처리해야할 것으로 예상되는 API 요청량 등을 고려해 적절한 하드웨어를 선택해야 함

- 인제스트 노드 : 인덱싱 요청량과 문서 가공을 위한 파이프라인의 복잡도 등을 고려해 적절한 하드웨어를 선택해야 함

​

5) 스냅샷 처리

- S3와 같이 용량 제한이 없는 클라우드 저장소를 사용한다면 추가적으로 하드웨어에 대해 고민할 필요가 없음

- 직접 디스크를 준비할 경우, 실시간 처리 성능보다 저렴한 비용으로 더 오랜 기간 보관하는 것이 중요하기 때문에 반드시 SSD를 사용할 필요는 없음

- 용량을 기준으로 선정해야 하는데, 주의할 점은 스냅샷 저장소는 반드시 모든 노드에서 접근 가능하도록 네트워크 공유 드라이브를 구성해야 함

- 엘라스틱서치의 데이터가 각 노드에 분산 저장되어 있고, 스냅샷 생성 시 각 노드에서 스냅샷 저장소로 파일 복사가 직접 일어남

​

14.1.3 엘라스틱서치 버전 선정

- 엘라스틱서치는 특별히 안정화된 버전이나 장기간 지원하는 버전을 제공하지 않으므로 기존에 사용하던 다른 클러스터와의 호환성을 고려하거나 낮은 메이저 버전의 백업 데이터를 활용해야 하는 경우 등 특별한 상황이 아니라면 가장 최신 버전을 사용하는 것이 좋음

- 버전의 마지막 자리인 패치 버전이 0인 경우(x.x.0) 다음 패치 버전을 기다리는 것이 좋음

- 메이저나 마이너 버전이 올라간 직후의 버전이기 때문에 새로 추가된 기능들에 버그가 포함될 가능성이 높음

- 서포트 매트릭스를 확인하여 자유롭게 선택하는 것이 좋음

https://www.elastic.co/kr/support/matrix

​

14.2 클라우드 구성

14.2.1 노드 설치

- 로컬 PC에 3개의 엘라스틱서치와 1개의 키바나 프로세스를 실행하여 3개의 노드를 실행함

- 엘라스틱서치 : node1, node2, node3

- 키바나 : kibana

​

① elastic-node 디렉토리 생성

elastic-node 디렉토리를 생성하여 실습할 node1, node2, node3, kibana를 구성함

​

② elasticsearch와 kibana 설치

elastic-node 디렉토리 하위에 elasticsearch 노드 3대와 kibana 노드 1대를 wget 명령어로 다운로드하여 설치함

​

③ 노드 폴더 구조

node1, node2, node3은 완벽하게 같은 구조여야 함

​

④ node1, 2, 3 엘라스틱서치 설정 : elasticsearch.yml

노드 롤(node.roles)은 특별히 선택하지 않았기 때문에 모두 마스터 후보 노드이면서 데이터 노드 역할을 함

​

▶ 클러스터 구성을 위한 엘라스틱서치 설정

​14.2.2 개발 모드와 운영 모드

- 엘라스틱서치는 시작할 때 부트스트랩을 검사함

- 부트스트랩 체크 : 노드의 안정성을 위해 몇가지 검사를 수행하는 것을 의미하는데, 잘못된 시스템 설정으로 인해 의도치 않은 성능 저하가 발생하는 상황을 방지하기 위함

- 개발 모드 : 부트스트랩 체크를 수행하긴 하나 실패했을 경우, 경고 로그만 출력할 뿐 시스템은 정상 작동함

- 운영 모드 : 부트스트랩 체크에 실패하면 로그와 함께 즉시 노드의 실행이 중단됨

- elasticsearch.yml의 network.host 값이 로컬 호스트이면 개발 모드, 그 외이는 운영 모드를 의미함

- 엘라스틱서치는 network.host 설정을 통해 해당 클러스터가 외부 네트워크를 통해 정식으로 운영 모드에 들어섰다고 판단함

​

① network.host 설정

- 엘라스틱서치 설정 파일에서 network.host를 수정하지 않으면 기본적으로 로컬 호스트로 인식함

- network.host 값을 변경하면 운영 모드로 동작함

- _local_ : 로컬 네트워크 별칭

- _site_ : 내부 네트워크 별칭

- _global_ : 외쿠 네트워크 별칭

- 설정된 내부/외부 네트워크가 없을 경우, 정상적으로 바인딩되지 않을 수 있고 명시적으로 바인딩할 IP나 네트워크 어댑터명을 지정해야 할 수도 있음

​

② 엘라스틱서치 로그 : 개발 모드

운영 모드로 사용하기 힘들다는 문구(unsuitable for production use;)가 보이면 개발 모드로 실행된 상태임

​

③ 엘라스틱서치 로그 : 운영 모드

운영 모드로 사용하기 힘들다는 문구가 없으면 운영 모드로 실행된 상태임

​

14.2.3 운영 모드 설정

1) config/jvm.options

- JVM 관련 설정들이 포함된 파일

- 엘라스틱서치를 다운로드하고 압축을 풀면 config 디렉토리가 있고 이 디렉토리 하위에 jvm.options라는 파일이 있음

​

▶ 힙 메모리 설정

- Xms : 최소 힙 크기

- Xmx : 최대 힙 크기

​

① Xms와 Xmx 수치를 동일하게 할당함

- 최소와 최대 힙 크기를 동일하게 할당하지 않으면 힙 메모리 할당량을 확장하는 과정에서 노드가 일시적으로 멈출 수 있음

- 기본값 : 1GB

​

② 힙 크기는 최대 시스템 물리 메모리의 절반으로 함

- 엘라스틱서치는 힙 메모리 외에도 빠른 검색과 인덱싱 성능을 위해 파일 시스템 캐시를 적극적으로 활용함

- 상당한 메모리를 사용하므로 충분한 여유 메모리를 확보하지 않으면 성능상 문제가 될 수 있음

​

③ 힙 크기는 최대 30~31GB 수준을 넘기지 않음

- 자바에는 힙 메모리를 좀 더 빠르고 효율적으로 활용할 수 있도록 Compressed Ordinary Object Pointers 기술이 적용되어 있는데, 시스템마다 차이가 있지만 일반적으로 힙 메모리가 최대 32GB를 넘기면 비활성화 됨

- 충분히 큰 힙 메모리를 할당했음에도 오히려 성능이 급격히 저하되는 현상을 겼을 수 있음

- 물리 메모리에 많은 여유가 있어 충분히 활용할 경우라면 동일 장비에 복수의 노드를 실행하는 방식을 검토하는 것이 좋음

​

▶ 임시 파일과 덤프 파일 경로 설정

① -Djava.io.tmpdir

- 임시 디렉토리 루트 설정

- 운영체제에서 기본적으로 /tmp 임시 디렉토리의 경우, 리눅스에서 주기적으로 정리하고 파일의 소실이 되어 문제가 발생하는 경우가 있어 사용하지 않는 것을 권장함

- 임시 디렉토리의 경우, 리눅스 패키지 매니저를 이용해 설치했을 때는 별도로 설정할 필요가 없지만 아카이브 파일을 해제하고 설치했을 때는 노드를 실행하는 계정에서 읽기/쓰기가 가능한 디렉토리를 확보해 해당 경로를 입력해주어야 함

​

② XX:HeapDumpPath

- 힙 덤프 파일이 생성되면 저장되는 경로

- 힘 덤프 파일이 제대로 설정되어 있지 않으면 OutOfMemory 오류가 발생했을 때 원인 분석을 위한 덤프 파일을 찾는데 문제가 발생할 수 있음

- 아카이브 파일을 해제하고 설치한 후 /config/elasticsearch.yml의 path.data를 별도로 수정하지 않을 경우, 기본적으로 data 디렉토리를 가리킴

- 리눅스 패키지 매니저를 사용해 설치했다면 해당 위치가 조내하지 않으므로 읽기/쓰기가 가능한 디렉토리를 확보해 경로를 수정해주어야 함

- JVM 튜닝이 필요할 정도로 성능이 저하되었다면 샤드 수를 조정하거나 매핑을 개선하는 등 다른 튜닝 방안으로 해결하는 것이 좋고, 그럼에도 성능이 나아지지 않는 다면 노드 추가를 고려해야 함

​

2) config/elasticsearch.yml

메모리 스왑 기능을 비활성화하기 위해 엘라스틱서치 설정 파일인 elasticsearch.yml 파일을 수정해야 함

​

▶ bootstrap.memory_lock

① 기본 설정

② 주석 해제

- 노드 실행 시 시스템의 물리 메모리를 미리 할당받아 스왑 영역을 사용하지 않도록 방어하는 설정을 말함

- 메모리 부족으로 인해 디스크의 스왑 영역을 참조할 경우 심각한 성능 저하가 발생할 수 있기 때문에 필수적으로 설정해주어야 함

- 기본적으로 주석처리되어 있는데 주석을 해제해야 함

- 스왑 영역 사용을 방지하기 위한 목적으로 OS의 스왑 자체를 비활성화해 해결하는 방법도 있음

​

3) /etc/security/limits.conf

- 리눅스의 시스템 수준에서 걸려 있는 제한들을 해제해줄 필요가 있음

- 리눅스 파일에만 있기 때문에 다른 OS에서는 신경쓰지 않아도 됨

​

▶ 리눅스 제한 설정

리눅스 제한 설정은 파일 수정 후 시스템을 리부팅하면 내용이 적용됨

​

① es

엘라스틱서치를 실행하는 사용자 계정명

​

② nofile

- 최대 파일 디스크럽터 수

- 시스템에서 최대로 열 수 있는 파일 수를 제한함

- 엘라스틱서치는 샤드 하나 당 몇 개씩의 파일들을 열어놓고 사용하며 인덱스가 늘어남에 비례해 이 숫자가 증가하기 때문에 운영 초기에는 문제가 없다가도 시간이 지남에 따라 샤드가 늘어나 파일 디스크럽터 수 제한에 의해 문제가 발생하는 경우가 종종 있기 때문에 최소 65535 이상의 값으로 넉넉하게 잡아줌

​

③ nproc

- 최대 프로세스 수를 제한함

- 검색, 인덱싱, 머지 등 많은 작업들을 실행하다 보면 프로세스가 많이 생성되어 별도의 스레드 풀을 통해 처리하는 엘라스틱서치 특성상 넉넉히 잡아주는 것이 좋음

- 설정을 변경하지 않을 경우 기본값 : 1024

​

④ memlock unlimited

- 메모리 내 주소 공간의 최대 크기를 지정함

- 엘라스틱 가이드에 따라 무한대로 잡아줌

​

⑤ hard와 soft

- 프로그램 시작 시 사용하는 기본 한도와 최대 한도

- 대시(-)는 soft와 hard를 동시에 적용함

​

▶ unlimit 전체 항목 보기 : ulimit -a

- 프로세스 리소스 한도 설정을 위한 리눅스 명령어

- max locked memory와 max user processes, open files는 설정한 unlimited와 4096, 65535로 수정됨

- 우분투를 사용한다면 /etc/systemd/system.conf, /etc/systemd/user.conf로 적용해야 하는데, DefaultLimitNOFILE 값을 변경해주면 됨

​

① DefaultLimitNOFILE 값 수정

/etc/systemd/system.conf와 /etc/systemd/user.conf의 DefaultLimitNOFILE 값 변경

​

② ulimit 전체 항목 보기

파일 수정 후, 리부팅한 다음 ulimit -a를 실행함

​

③ 리소스 제한 설정

- limit.conf 파일을 수정하면 변경값이 영구적으로 적용되는데, 영구적으로 적용하는 것말고도 ulimit 명령을 이용해 제한적으로 반영할 수도 있음

- ulimit는 일반 사용자 계정으로 실행할 수 없어 root 계정에서 ulimit 명령을 실행해야 함

- 파라미터 -n : 파일 디스크립터 수

- 파라미터 -u : 최대 프로세스 수

- 파라미터 -l : 메모리 락

​

4) /etc/sysctl.conf

​

- 리눅스에 있는 파일

- 커널 변수값을 수정해 보안이나 성능을 향상하는데 사용함

- 기본적으로 파일 입출력 성능 향상을 위해 파일을 메모리에 매핑하는 mmap 파일 시스템을 사용하는데, 가상 메모리 공간을 사용하므로 충분한 공간을 확보할 필요가 있음

​

① 최대 가상 메모리 개수 변경

- 기존에 설정된 값이 있다면 값을 변경해야 함

- 파일을 수정하고 리부팅하면 영구적으로 적용됨

​

② 최대 가상 메모리 개수 변경(파일 수정 없이 즉시 적용)

​

14.2.4 실행과 구성 확인

① 엘라스틱서치 node1, node2, node3 실행

② node1 엘라스틱서치 로그 : node3 연동

​

③ curl로 클러스터 상태 확인

모든 노드가 정상적으로 실행한 후, curl로 cluster API를 호출하여 클러스터 상태를 확인함

​

④ 클러스터 상태 확인 결과

my-prod-cluster라는 이름으로 클러스터가 생성되고 노드 개수가 3개로 보임

​

⑤ 키바나 설정

- server.host : 키바나의 호스트 주소를 의미함

- 0.0.0.0은 자동으로 외부 IP를 바인딩해주는데, 가상 머신 등에서 실습을 진행하며 호스트 머신의 접근을 원할 경우, 이 설정을 추가해주어야 함

- elasticsearch.hosts : 키바나가 접근할 수 있는 노드 주소

​

⑥ 키바나 접속

localhost:5601로 키바나에 접속할 수 있음

​

14.3 보안 기능 설정

보안 기능이 적용되지 않은 채로 외부망에 공개된 많은 운영 클러스터들이 정보 유출, 데이터 유실 등의 위협을 받고 있음

​

1) 엘라스틱서치의 보안 기능

- 기본적으로 사용자 역할 기반 접근 제어와 노드 간 통신 암호화, HTTP 통신 암호화 등을 포함함

- 유료 서브스크립션을 사용한다면 LDAP, SAML 등과 같이 외부 인증 체계와 연동할 수 있는 방법을 제공하고, 사용자별로 조회할 수 있는 문서나 필드를 제한할 수 있음

- 과거에는 엘라스틱서치의 보안 기능을 사용하려면 기본적으로 로그인이나 역할 기반 접근 제어 기능을 포함하는 유료 서브스크립션을 요구했기 때문에 별동로 보안이 적용된 프록시를 구축하거나 네트워크 정책 등을 이용해 접근을 해야 했음

- 6.8, 7.1 버전부터는 무료로 제공되는 베이직 라이선스에서도 보안 기능을 사용할 수 있게 되어 반드시 활성화해야 함

​

① 사용자 역할 기반 접근 제어

- 사용자 아이디와 비밀번호를 입력해야만 엘라스틱서치에 접근할 수 있게 하는 것을 말함

- 사용자 계정별로 역할을 할당해 수행할 수 있는 작업의 종류를 제한할 수 있음

- 기본적으로 보안 설정이 되어 있지 않은 채 외부망에 공개되어 있는 엘라스틱서치는 별도의 인증 정보 없이 모든 API를 사용할 수 있으므로 손쉽게 데이터가 유출될 수 있을 뿐만 아니라 모든 인덱스를 삭제 당하는 등 공격에 무방비 상태로 남아 있음

​

② 클러스터 내부의 노드 간 통신이나 클러스터 내부와 외부의 HTTP 통신 암호화

각 네트워크 구간에 대한 암호화 통신을 지원하므로 중간에서 패킷을 염탐하거나 탈취하는 데이터 유출 공격을 방지할 수 있음

​

▶ 보안 기능 활성화 : elasticsearch.yml

- 설정 변경만으로는 보안 기능을 사용할 수 없음

- 각 보안 기능별 설정이 완료되지 않으면 정상적으로 동작하지 않음

- 보안 설정 적용 시 전송 계층 보안을 적용하는 과정에서 반드시 한 번 전체 클러스터 재시작이 필요함

- 실제 운영 중인 클러스터라면 서비스가 일시적으로 멈추게 되므로 보안 설정은 초기 구축 시 진행해야 함

​

14.3.1 인증서 생성

- 엘라스틱서치는 자체적으로 elasticsearch-certutil이라는 인증서 생성용 도구를 제공함

- CA 인증서가 필요한데, 노드별로 작업하지 않고 한 번만 생성해야 함

​

1) CA 인증서

① CA 인증서 생성

- CA 인증서를 생성하는 명령을 실행함

- 별도로 발급받은 CA 인증서가 있다면 이 단계는 넘어가도 됨

​

② CA 인증서 이름과 비밀번호 설정

ⓐ CA 인증서 이름

- 파일명은 추후 변경할 수 있으니 자유롭게 설정해도 됨

- 입력하지 않으면 elastic-stack-ca.p12라는 이름의 CA 인증서가 생성됨

​

ⓑ CA 인증서 비밀번호

CA 인증서들을 이용해 스택의 각 노드와 애플리케이션에서 사용될 인증서를 만들어야 하므로 반드시 비밀번호는 기억해두어야 함

​

③ 생성된 CA 인증서 확인

④ 인증서 발급

- 노드별로 인증서를 발급해야 하는데 실습에서는 node1, node2, node3, kibana까지 총 4번 진행해야 함

- 인증서 발급도 엘라스틱서치가 제공하는 인증서 생성 도구를 사용함

- 인증서를 발급받기 위해서는 CA 인증서가 위치한 경로에서 명령을 실행해야 함

​

⑤ 인증서 이름과 비밀번호 설정

ⓐ 인증서 비밀번호

- CA 인증서의 비밀번호를 입력함

- 앞서 CA 인증서를 새로 만들면서 사용했던 비밀번호를 입력함

- 발급받을 인증서의 비밀번호를 설정할지 여부는 선택사항이고, 설정하고 싶지 않을 경우에는 빈 값으로 두고 엔터를 치면 됨

​

ⓑ 인증서 이름

각 엘라틱서치 노드와 키바나에 대해 하나씩 필요하기 때문에 실습에서는 node1.p12, node2.p12, node3.p12, kibana.p12로 설정함

​

⑥ 생성된 4개의 인증서 확인

​

⑦ 인증서와 CA 인증서 각 노드에 복사

- 실습에서는 각 노드 디렉토리와 키바나 디렉토리의 config 디렉토리 하위에 certs 디렉토리를 생성하고 노드별 인증서를 해당 디렉토리로 위치함

- 생성한 CA 인증서도 노드별 인증서와 동일한 디렉토리에 복사해둠

- 키바나에는 CA 인증서를 복사할 필요가 없음

​

공개키 기반 인증에 익숙하지 않는 사용자라면 종종 노드별로 별도의 CA 인증서를 만들고 해당 CA를 기준으로 인증서를 생성하는 실수를 저지르기 쉬운데, 이 경우에는 각 인증서들은 서로 다른 인증서라서 신뢰할 수 없어 정상적으로 인증을 진행하지 못하게 되므로 반드시 동일한 CA를 사용해 인증서를 생성해야 함

​

2) HTTP 암호화 인증서

- 엘라스틱서치는 HTTP 인증을 위한 인증서 생성 도구도 제공함

​

① HTTP 암호화에 사용할 인증서 생성

② CRS 생성 여부 체크

- 인증서 서명 요청(CRS)을 생성할지 여부를 선택함

- 인증 기관을 통해 인증서를 받을 때 필요하고, 직접 생성한 인증서를 사용하기 때문에 N으로 선택함

​

③ CA 인증서 사용 여부 체크

- 기존 CA 인증서를 사용할지 여부 체크

- 기존 CA 인증서를 사용할 경우, CA 인증서의 경로를 입력함

- 경로는 노드의 confing 디렉토리를 기준으로 상대 경로를 적음

- 경로에 문제가 있을 경우, 절대 경로를 확인해주므로 이를 기준으로 정정하면 됨

​

④ CA 인증서 비밀번호 입력

​

⑤ 인증서 유효기간 설정

기본값 : 5년

​

⑥ 노드별 인증서 생성 여부 체크

- 엘라스틱서치 노드별로 별도의 인증서를 생성할지 여부를 선택함

- N을 선택하면 공통으로 사용할 하나의 인증서만 생성됨

- Y를 선택하면 노드별로 인증서를 생성할 경우, 설정들을 노드 수만큼 반복하게 됨

- 조직의 보안 정책에 따라 결정함

​

⑦ 호스트네임 입력

- 인증서를 사용할 호스트 네임을 입력함

- 인증서의 유효성 검사에 사용됨

- N을 누르면 호스트네임을 다시 수정할 수 있음

- 제대로 입력하였으면 Y를 누름

​

⑧ 호스트 IP 입력

- 인증서를 사용할 호스트의 IP를 입력함

- 인증서의 유효성 검사에 사용됨

- 엔터를 누르면 적용되고 값을 잘못 입력하면 N으로 수정할 수 있음

​

⑨ 최종 입력 사항과 변경 여부 체크

입력한 옵션들을 변경하고자 할 경우에는 Y를, 그렇지 않다면 N을 입력함

​

⑩ 인증서에 사용할 암호 입력

공란으로 입력할 경우, 비밀번호가 없는 인증서가 생성됨

​

⑪ 인증서 파일 위치와 이름 지정

​

- 파일이 위치할 경로를 입력할 수 있음

- 특별히 원하는 경로가 없으면 엔터를 눌러 기본 경로에 위치시킴

- HTTP 인증서는 zip 파일 형태로 만들어짐

​

⑫ 만들어진 HTTP 인증서 압축 파일 구조

압축을 해제하면 elasticsearch, kibana 폴더가 보이고 그 아래에 인증서가 보임

생성된 HTTP 보안용 인증서 중 elasticsearch/http.p12 파일은 각 엘라스틱서치 노드 디렉토리의 config/certs 디렉토리 하위로, kibana/elasticsearch-ca.pem 파일은 키바나 디렉토리의 config/certs 디렉토리로 복사해줌

​

⑬ HTTP 인증서를 각 노드에 복사

tree 명령어를 통해 전체 클러스터 내부의 엘라스틱서치 노드와 키바나의 인증서 관련 파일 구조를 확인할 수 있음

​

​

14.3.2 노드 간 통신 암호화

- 클러스터 내 노드 간에 전송되는 데이터를 인증서 기반으로 암호화함으로써 통신 간 데이터 유출이나 클러스터에 임의의 노드가 가입되는 상황을 방지할 수 있음

- 가장 기본적인 보안 기능으로 반드시 활성화해야 함

​

① 각 노드에 노드 간 통신 암호화 설정

- xpack.security.transport.ssl까지는 공통으로 입력하고, enabled에는 전송 계층 보안 활성화여부를 선택함

- verification_mode : 인증서 검증 방식을 선택함

- 강력한 보안을 원할 경우에는 full을 입력하면 인증서 생성 시 등록한 IP, 도메인까지 검증하지만 이 경우 노드를 추가할 때마다 인증서들을 갱신해야 할 수도 있음

- certificate : 기본적인 인증서 검증만 수행하므로 일반적으로 많이 사용됨

- none으로 설정할 경우 인증서 검증을 무시할 수 있지만, 전송 계층 보안을 활성화하는 의미가 없으므로 단순 테스트 목적이 아니라면 사용하지 말아야 함

- keystore와 trustore 경로를 입력하는데, 만들었던 인증서 경로를 입력함

​

② keystore 생성

- create 명령을 사용해 초기화할 경우, 저장소 파일이 생성되며 이후 add, remove 등의 명령으로 설정을 추가/제거할 수 있음

​

③ keystore 생성 확인

config 폴더 하위에 elasticsearch.keystore 파일이 생성됨

​

④ xpack.security.transport.ssl.keystore.security_password 비밀번호 등록

elasticsearch-keystore 명령 : 비밀번호와 같이 민감한 설정들을 파일에 노출하는 대신 키스토어에 안전하게 보관할 수 있게 도와줌

​

⑤ 키스토어 비밀번호와 노드별 인증서 비밀번호 입력

- elasticsearch.yml에서 xpack.security.transport.ssl.keystore.path: certs/node1.p12를 입력했는데 node1.p12 인증서 비밀번호를 입력해면 됨

- node1.p12 인증서 비밀번호를 등록하지 않았으면 공란으로 두고 엔터를 누름

​

⑥ xpack.security.transport.ssl.truststore.security_password 비밀번호 등록

​

⑦ 키스토어 비밀번호와 노드별 인증서 비밀번호 입력

- elasticsearch.yml에서 xpack.security.transport.ssl.truststore.path: certs/node1.p12를 입력했는데 node1.p12 인증서 비밀번호를 입력해면 됨

- node1.p12 인증서 비밀번호를 등록하지 않았으면 공란으로 두고 엔터를 누름

- 키스토어를 생성하고 비밀번호를 저장하는 작업은 반드시 모든 노드에서 진행해야 함

​

14.3.3 HTTP 클라이언트 통신 암호화

키바나와 로그스태시 등 엘라스틱 스택 간의 통신 뿐만 아니라 모든 외부 REST API 요청에 대한 암호화를 제공함

​

① HTTP 암호화 설정

- xpack.security.http.ssl.enabled를 true로 설정하면 HTTPS를 활성화함

- xpack.security.http.ssl.keystore.path : 인증서 경로를 의미함

​

② xpack.security.http.ssl.keystore.security_password 비밀번호 등록

- 각 노드의 비밀번호를 등록하기 위해 elasticsearch-keystore 명령을 이용함

- 등록한 설정은 elasticsearch.yml 파일에 등록된 설정과 동일하고, 보안상의 이유로 일부 설정들은 반드시 키스토어를 통해서만 등록할 수 있음

​

③ 비밀번호 입력

- 키스토어의 비밀번호를 입력

- elasticsearch.yml에서 xpack.security.http.ssl.keystore.path: certs/http.p12를 입력했는데 http.p12 인증서 비밀번호를 입력하면 됨

- 작업은 반드시 노드에서 진행해야 함

- 스펠링이 틀렸거나 인증서 비밀번호가 잘못 입력되었으면 나중에 엘라스틱서치를 실행할 때 실행이 되지 않음

​

④ 키스토어 리스트 확인

각 노드의 키스토어 비밀번호가 잘 저장되어 있는지 확인하는 방법으로 키스토어 비밀번호를 입력해야 함

​

14.3.4 클러스터 시작과 빌트인 사용자 설정

- 설정을 완료했다면 클러스터를 시작해야 하는데, 이미 클러스터가 실행 중이라면 터미널을 종료해 모든 노드를 종료한 후 새로 실행해야 함

- 실행이 정상적으로 되지 않는다면 인증서 생성이나 설정이 잘못된 경우이기 때문에 다시 한번 설정을 확인해봐야 함

- 설정과 실행이 정상적으로 완료되었다면 마지막으로 노드 중 하나에서 초기 계정 설정이나 타 스택과의 연동 편의를 위해 내장되어 있는 빌트인 사용자의 비밀번호를 초기화할 필요가 있음

​

① 엘라스틱서치 실행

실습 기준으로 node1, node2, node3을 실행 시 키스토어 비밀번호를 입력해야 실행이 됨

​

② 사용자 비밀번호 초기화

③ 사용자 비밀번호 초기화 실행 결과

키스토어를 생성할 때 설정한 비밀번호를 입력하고, 계속 진행할지 여부에 y를 입력함

​

④ 계정별 비밀번호 입력

- 계정별 비밀번호를 입력해야 하는데, 비밀번호는 화면에 표시되지 않고 확인을 위해 한번씩 다시 입력해야 함

- 임의로 설정되어 있는 기본 비밀번호를 이용해 동작하기 때문에 한 번실행한 후에는 REST API나 키바나를 통해 적절한 사용자로 인증 후 비밀번호를 변경해야 함

- 빌트인 사용자 : 엘라스틱서치를 포함한 각 스택의 구성요소들에 대한 피요한 최소 권한이 할당되어 있는 계정을 말함

- 기본적인 빌트인 사용자에 대한 정보는 다른 데이터와 동일하게 엘라스틱서치의 .security 인덱스에 저장됨

- 비밀번호 초기화는 반드시 클러스터가 실행된 후 진행해야 하고, 모든 노드를 통틀어 한번만 명령을 실행하면 됨

​

⑤ 인증 정보를 포함한 API 요청

- 빌트인 사용자 설정까지 마쳤다면 초기화한 사용자의 인증 정보를 이용해 엘라스틱서치에 접근할 수 있음

- curl 명령으로 관리자 계정인 elastic으로 연결이 가능한지 테스트함

- -u : 사용자 인증정보 추가

- -I : 응답 헤더만 확인

- -k : 인증서 검증 무시

​

⑤ 인증 정보를 포함한 API 요청 결과

- 첫 라인에 상태 코드로 정상 연결을 의미하는 200이, 인증에 실패했다면 401이 표시됨

- 인증서를 직접 생성했다면 신뢰할 수 없는 인증서이기 때문에 정상적으로 연결이 되지 않을 수 있음

​

14.3.5 키바나와 엘라스틱서치 간 통신 암호화

엘라스틱서치 측에서 SSL과 사용자 인증 등을 활성화했으므로 키바나의 기본적인 설정만으로는 클러스터에 정상적으로 연결할 수 없음

​

▶ 키바나와 엘라스틱서치 간 통신 암호화를 위한 설정

- certificateAuthorities : 엘라스틱서치와 통신하기 위한 CA 인증서 설정, 파일의 절대 경로를 입력

- elasticsearch.hosts : http로 등록했던 호스트들을 https로 변경함

​

14.3.6 키바나와 브라우저 간 통신 암호화

- 엘라스틱서치와 키바나 간의 통신은 암호화했지만 키바나와 브라우저 간의 연결은 암호화되지 않은 HTTP 프로토콜이 이용되고 있음

- 키바나와 브라우저 간의 연결을 HTTPS로 활성화하기 위해 키바나 인증서를 사용함

​

① 키바나와 브라우저 통신 암호화 설정

- server.ssl.enabled를 true로 설정하면 키바나로 들어오는 연결에 대해 SSL 연결을 활성화함

- server.ssl.keystore.path : 인증서 경로, 파일의 절대 경로를 추가함

​

② 키스토어 생성

- 설정 후 인증서의 비밀번호를 등록해야 함

- bin 디렉토리 하위에 kibana-keystore라는 프로그램이 존재함

- create : 키스토어 생성

​

② server.ssl.keystore.password 비밀번호 등록

kibana.yml에서 server.ssl.keystore.path에 등록했던 인증서 비밀번호를 입력함

​

③ 키바나 재시작

설정을 완료했다면 키바나를 재시작함

​

④ 키바나 접속 화면

HTTP가 아닌 https://localhost:5601 주소로 접속할 수 있음

​

ⓐ HTTP로 접속 시

​

ⓑ HTTPS로 접속 시

자체적으로 발급한 인증서이기 때문에 브라우저에 따라 페이지를 신뢰할 수 없는 경고가 뜰 수 있음

​

① 로그인 화면

② 빌트인 사용자 중 슈퍼유저 권한을 가진 elastic 사용자 계정으로 로그인

③ 로그인 후 메인 화면

빌트인 사용자 중 슈퍼유저 권한을 가진 elastic 사용자의 사용자명과 비밀번호를 이용하면 키바나의 모든 기능에 접근할 수 있음

​

14.4 사용자 등록과 관리

엘라스틱 스택의 운영자는 필요에 따라 적절한 조직별 역할을 할당하고 사용자에게 권한을 부여해야 함

​

14.4.1 사용자 역할 정의

- 사용자를 생성하려면 먼저 적합한 권한을 정의해야 함

- 역할과 사용자의 정의가 나뉘어 있는 이유 : 동일한 조직에 속하거나 권한을 부여해야 하는 사용자들을 한 번에 관리할 수 있음

​

1) 사용자 역할 관리

키바나 Management > Security > Roles에서 사용자 역할을 관리할 수 있음

​

새로운 역할 생성을 하려면 Roles에서 [Create role] 버튼을 클릭해야 함

​

새로운 역할을 생성하면 기본적으로 클러스터 수준 권한, Run as 권한, 인덱스 수준 권한, 스페이스에 대한 권한을 설정할 수 있음

- 일반적으로 클러스터와 인덱스 수준 권한이 주로 사용됨

- 클러스터와 인덱스 수준의 권한을 할당하면 엘라스틱서치 API 수준의 접근에 대한 특별한 어려움없이 제한할 수 있음

​

① 클러스터 수준 권한

클러스터 설정 업데이트, 조회, 상태 조회, 스냅샷, ILM 정책 관리 등 인덱스와 직접적인 관련이 없는 권한들을 포함됨

​

② 인덱스 수준 권한

인덱스 생성, 삭제, 검색 API 등에 대한 사용 권한이 포함됨

​

③ Run as 권한

특수한 경우에 대해 시스템적으로 지정한 사용자인 것처럼 접근할 필요가 있을 때 사용됨

​

▶ 계정 역할 설정 실습

- 역할명 설정 : kibana_demo

- 특정 인덱스(kibana_sample_data_)로 시작하는 모든 인덱스에 대한 읽기 권한과 키바나의 시스템 인덱스들에 대한 읽기 권한 부여

- 키바나에 접근하고자 하는 사용자라면 최소한 .kibana 인덱스에 대한 읽기 권한이 필요함

​

2) 스페이스와 UI 접근 권한 설정

- 키바나의 UI에서도 사용자 관리 페이지 같은 권한이 없는 인덱스에 접근하려 한다면 권한이 없다는 오류 메시지가 출력되긴 하지만, 많은 메뉴 중 특정 메뉴만을 노출하고자 할 경우, 스페이스와 UI 접근 권한을 설정할 필요가 있음

- 역할에는 특정 스페이스에 대한 권한만 설정할 수도 있고, 조직별 스페이스를 만들고 스페이스별로 접근 가능한 권한을 통제하는 방법도 가능함

​

14.4.2 사용자 추가와 역할 할당

- Security > Users > Create new user에서 기본적인 정보와 역할(Roles)을 할당해줌

- 사용자는 둘 이상의 역할을 가질 수 있으므로, 여러 조직에 속한 사용자를 관리하거나 공통적인 역할을 할당할 때 유용하게 사용될 수 있음

- 사용자 생성이 끝나면 로그아웃 후 생성한 계정으로 로그인하면 됨

​

▶ 사용자 권한 확인

UI 접근 권한 설정으로 인해 설정한 몇 가지 메뉴만 나타남

​

​