서비스 지향 아키텍처

Elastic Cloud Enterprise는 다음을 가능하게 하는 서비스 지향 아키텍처를 갖추고 있습니다.

• 서로 다른 안정성 및 성능 요구사항에 맞춰 각 서비스를 개별적으로 확장할 수 있습니다.
• API를 통해 서비스에 접근할 수 있습니다.
• 각 서비스를 자체 Docker 컨테이너에 독립적으로 배포할 수 있습니다.

×

ECE의 컨트롤 플레인에는 다음 관리 서비스가 포함됩니다.

ZooKeeper

• ZooKeeper는 분산형 강한 일관성 데이터 저장소입니다.
• Proxy 라우팅 테이블, allocator가 알린 메모리 용량, Admin Console을 통해 커밋된 변경 사항 등 ECE 구성 요소에 필수적인 정보를 보관합니다.
• 서비스 간 통신을 위한 메시지 버스 역할을 합니다.
• STunnel을 사용해 ECE 구성 요소와 통신합니다.
• ECE 설치 상태와 ECE에서 실행 중인 모든 배포의 상태를 저장합니다.

Director

• ZK 데이터 저장소를 관리하고, ZooKeeper와 통신하려는 내부 클라이언트의 CSR(인증서 서명 요청)에 서명합니다.
• ZooKeeper가 통신에 사용하는 stunnel을 유지 관리하고, 새 ZooKeeper 노드가 생성될 때 쿼럼을 구성합니다.

Constructor

• Admin console에서 오는 요청을 모니터링하는 스케줄러처럼 동작합니다.
• 무엇을 변경해야 하는지 판단하고, allocator가 모니터링하는 ZooKeeper 노드에 변경 사항을 기록합니다.
• 클러스터 노드를 allocator에 할당합니다.
• 기반 allocator의 활용도를 극대화해 새 배포를 위해 추가 하드웨어를 투입할 필요를 줄입니다.
• 클러스터 노드와 인스턴스를 서로 다른 가용 영역에 배치해 영역 전체가 다운되더라도 배포가 유지되도록 합니다. 이러한 가용 영역은 ECE 설치 시 지정할 수 있습니다.

Cloud UI 및 API

관리자가 ECE 설치를 관리하고 모니터링할 수 있도록 웹 및 API 접근을 제공합니다.

• 사용자 요청을 처리하며, 요청 URL로 전달된 컨테이너용 배포 ID를 실제 Elasticsearch 클러스터 노드 및 기타 인스턴스로 매핑합니다. 배포 ID와 컨테이너의 연결 정보는 ZooKeeper에 저장되고 proxy가 캐시합니다. ZooKeeper가 다운되더라도 플랫폼은 캐시를 사용해 기존 배포에 대한 요청을 계속 처리할 수 있습니다.
• 고가용성 Elasticsearch 클러스터를 사용하는 경우, 영역의 상태와 가용성을 추적합니다. 영역 중 하나가 다운되면 proxy는 해당 영역으로 요청을 라우팅하지 않습니다.
• 무중단 확장 및 업그레이드를 지원합니다. 업그레이드를 수행하기 전에 스냅샷을 생성하고 데이터를 새 노드로 마이그레이션합니다. 마이그레이션이 완료되면 proxy가 트래픽을 새 노드로 전환하고 기존 노드의 연결을 끊습니다.
• 시스템 가용성을 유지하기 위해 일반적으로 여러 proxy를 로드 밸런서 뒤에 구성합니다.

• Elasticsearch 노드와 Kibana 인스턴스를 호스팅하는 모든 머신에서 실행됩니다.

• 다음과 같은 방식으로 클러스터 노드의 수명 주기를 제어합니다.

  • 요청 시 새 컨테이너를 생성하고 Elasticsearch 노드를 시작
  • 노드가 응답하지 않으면 재시작
  • 더 이상 필요하지 않은 노드는 제거

• 기반 호스트 머신의 메모리 용량을 ZooKeeper에 알려 Constructor가 어디에 배포할지 근거 있는 결정을 내릴 수 있도록 합니다.

서비스는 Docker 컨테이너로 배포되며, 이는 운영 부담을 줄이고 개발 및 스테이징용으로 유사한 환경을 손쉽게 프로비저닝할 수 있게 해줍니다. Docker 컨테이너를 사용하면 다음과 같은 이점이 있습니다.

• 리소스 분할

  각 클러스터 노드는 Docker 컨테이너 안에서 실행되어 모든 노드가 보장된 호스트 리소스 몫에 접근할 수 있도록 합니다. 이를 통해 바쁜 배포 하나가 호스트 전체를 잠식하는 노이지 네이버 효과를 완화합니다. CPU 리소스는 할당된 Elasticsearch 클러스터의 크기에 비례합니다. 예를 들어 RAM 32GB 클러스터는 RAM 16GB 클러스터보다 두 배 많은 CPU 리소스를 할당받습니다.

• 강화된 보안

  어떤 클러스터든 침해될 수 있다는 전제하에 컨테이너에는 플랫폼에 대한 접근 권한이 부여되지 않습니다. 서비스도 마찬가지로, 각 서비스는 자신과 관련된 시스템 상태 부분만 읽거나 쓸 수 있습니다. 일부 서비스가 침해되더라도 공격자는 나머지 서비스의 키를 획득할 수 없으며 플랫폼 전체를 침해하지 못합니다.

• Stunnel을 통한 보안 통신

  모든 서비스나 구성 요소가 TLS를 기본 지원하지는 않기 때문에, Docker 컨테이너는 Stunnel이 제공하는 Transport Layer Security를 통해 서로 안전하게 통신합니다. 컨테이너 간 모든 트래픽을 터널링하면 다른 사람이 기반 클라우드나 네트워크 인프라에 접근하더라도 도청이 불가능합니다.

각 Elastic Cloud Enterprise 서비스는 전용 컨테이너로 실행됩니다. 이 컨테이너들은 각 ECE 호스트에 할당된 역할에 따라 자동으로 배포됩니다. 다음 표는 ECE 호스트의 컨테이너와 각 컨테이너를 포함하는 호스트 역할을 정리한 것입니다.