새로운 Elasticsearch 프론티어: Elastic Cloud Enterprise 1.0 GA

우리는 곧 공식 GA로 출시될 Elastic Cloud Enterprise(ECE) 1.0을 최종 점검중입니다. 이 신제품을 사용하면 단일 콘솔 환경에서 원하는 방식으로 Elasticsearch 클러스터 및 Kibana 인스턴스를 프로비저닝, 모니터링 및 조율할 수 있습니다.

(바로 구입을 원하시면 먼저 체험판을 즐겨보십시오. 향후 공개될 웨비나와 제품 데모 역시 마음에 드실겁니다.)

오늘 출시를 앞두고 우리는 제품 아키텍처, 비즈니스 가치, 그리고 대상 고객. 에 대해 이야기했습니다. 이제, 사용자가 ECE와 같은 제품을 어떠한 여정을 통해 채택하는지에 대해 알아보겠습니다.

많은 사용자가 유사한 도입 사례를 공유하고 있습니다. 회사 X의 개발자가 데이터 관련 문제를 만지작거리다가 우연히 Elasticsearch를 발견해서 다운로드하고 테스트 클러스터를 생성하고 일부 데이터를 수집해서 문제 해결에 성공합니다. 그런 다음 동료가 이 얘기를 듣고 데이터를 추가합니다. 이를 지원하려면 클러스터가 커져야 합니다. 조만간 회사 X는 중요 업무용 기능을 지원하는 수십 개의 Elasticsearch 노드를 프로덕션 환경에서 실행합니다.

그리고 그것은 시작에 불과합니다.

회사 X가 은행이라고 가정해 봅시다. 현재 회사 X의 다중 노드의 운영 클러스터는 여러 애플리케이션에 대한 로깅 사용 사례를 지원하고 있지만, 지금 회사 X는 보안 분석 및 트랜잭션 분석을 위한 새로운 애플리케이션을 개발하려고합니다. 뿐만 아니라 마케팅, 인적 자원 및 SRE 팀은 Elastic에 관한 소문을 듣고 비즈니스 문제를 해결하기 위해 Elastic을 체험하거나 적용할 것을 요청했습니다.

이제 점점 흥미로워지고 있습니다. 클러스터 내에서 규모를 관리한다는 어려운 문제에서 자연스럽게 발생하는 여러 사용 사례, 다중 테넌트, 점점 더 늘어나는 데이터와 같은 다채로운 문제들이 나타났습니다.

즉, 이들은 흥미롭지만 상당히 까다로운 문제들입니다. 좀 더 명확한 설명을 위해, 1) 사용자는 누구이며?, 2) 무엇을 하려고 하는가? 라는 두 가지 (무의식적으로 떠오르는) 질문을 중심으로 이 문제를 자세히 살펴봅시다.

1번 질문: 사용자는 ?

사용자가 클러스터의 테넌트(소속 계정)인 경우, 분석 시간, 빠른 대응, 사용자 지정 경험, 기대치의 충족이 중시될 것입니다. 그러나 모든 테넌트가 비슷하다고 가정하는 것은 현명하지 않습니다. 그들은 각각 다른 요구, 습관 및 요구 사항, 마찰과 불만의 잠재적 원인을 가지고 있습니다.

• 서로 다른 액세스 프로필. 테넌트는 서로 다른 사용 사례를 갖게됩니다. 일부는 전체 텍스트 검색을 수행하거나 제안, 권장 사항이 필요할 수 있습니다. 다른 테넌트는 대량 어그리게이션, 로깅 또는 보안 데이터에 대한 스캔 및 스크롤 작업을 수행해야 할 수도 있습니다.

• 서로 다른 SLA. 위험 탐지를 수행하는 보안팀은 분석에 대한 응답 지연을 원하지 않지만, 클러스터에 대한 대량 쿼리는 다른 테넌트에 대한 SLA 기대치에 부정적인 영향을 미칠 수 있습니다.

• 다른 버전. 모든 테넌트가 동일한 버전의 Elastic 제품을 사용하고 있는 것은 아닙니다. 특정 이유로 인해 특정 버전을 사용 중일 수 있으며, 미처 새 버전에 대비하지 못한 채로 부정적인 경험을 하게될 수 있습니다.

추가 작업이나 인프라 부담을 초래할 수 있는 서로 다른 백업 정책과 같은 고려 사항도 있습니다. 또는 일부 테넌트는 다른 테넌트에 묶여있는 클러스터에 1년치 데이터를 쿼리하는 대용량 알림 - Alert를 사용 중일 수 있습니다.

만일 여러분이 Elastic의 모든 마법을 구사해야 하는 프로덕션 팀인 경우 만족스러운 사용자 경험, 프로젝트 또는 부서에 대한 ROI 추가, 문제 해결에 시간을 낭비하지 않는 것을 중요시하게 됩니다. 이러한 관점에서는 또 다른 변수의 집합이 고려됩니다.

• 유지보수를 수행해야 하는 시기. 고전적인 질문입니다. 시스템 및 사용자에게 미치는 영향을 최소화하려면 언제 유지보수를 수행해야 할까요? 시간대와 다양한 사용 패턴에 따라 어떻게 조정해야 할까요?

• 업그레이드. 또 다른 고전적인 질문입니다. 테넌트 하나를 업그레이드하면 업그레이드 할 필요가 없는(또는 할 수 없는) 다른 테넌트의 성능에 영향을 미칠 수 있습니다.

• 하나의 테넌트에 의한 전체 충돌. 내부 고객은 전체 테넌트를 잠그고 큰 쿼리를 실행하는 하나의 테넌트로 인해 액세스 문제를 겪을 수 있습니다.

• 보안 규정 준수. 일부 테넌트는 보안상의 이유로 인해 다른 테넌트와 동일한 클러스터에 데이터를 보관할 수 없습니다.

• 모두에게 사랑받는 Kibana. 현재 Kibana에는 멀티테넌시가 없으므로, 사용자는 여러 개의 Kibana 인스턴스를 다시 생성해야하며, 이에 따른 추가 관리가 필요합니다.

그러면 어떻게 해야 할까요? 

소프트웨어는 잘 작동하고 조직에서 많은 역할을 담당하고 있습니다. 프로덕션 팀은 클러스터 (또는 아마도 자신들의 멘탈)가 무너지기 전에 무엇을 해야 할까요?

왜냐하면 이것이 현실이기 때문입니다...

생각해볼 수 있는 (그리고 결국 어쩔 수 없는) 방안은 클러스터를 분리하는 것입니다. 작은 단위들로 분리하면 논의된 몇 가지 문제가 해결되지만 또 다른 비용을 처리해야 합니다.

구성 관리 또는 튜닝 도구를 사용한 배포 및 프로비저닝, 클러스터마다 다른 (5.x 이전에서는 까다로운) Elastic 버전의 관리, 다른 SLA나 심지어는 다른 유형의 인프라까지도 지원하는 등에 대한 고려가 필요합니다.

연쇄 반응도 일어납니다. 한 테넌트가 고유 클러스터를 보유하고 있다면, 다른 테넌트도 고유 클러스터를 원할 것입니다. 작은 규모에서의 간단한 것을 관리하는 일도 계속해서 늘어나게 되면 복잡해집니다. 곧, 프로덕션 팀은 클러스터를 지원하는 데 당초 설정했던 것보다 더 많은 시간을 할애하는 위험을 감수하게 됩니다.

이제 결론에 도달했습니다. 

이런 문제는 ECE가 밥먹듯이 처리하는 일입니다. 이러한 모든 요구 사항은 단일 콘솔에서 처리하고 간소화할 수 있습니다.

새로운 클러스터를 만들고 필요에 따른 확장 및 축소, 다양한 버전을 호스팅 및 업그레이드하고, Kibana를 활성화하고, X-Pack을 활성화하십시오. 사용자는 API 호출을 클릭하거나 제출하기만 하면 됩니다. 단일 화면에서 전체 배포를 모니터링하여 모든 사람을 만족시키십시오. 그런 다음 다시 프로젝트로 돌아가서 비즈니스를 발전시키십시오.

이제 어떤 누가 Elastic의 가벼운 체험을 원하던, 완전히 준비된 운영 단계의 적용을 원하던, 손쉽게 구성하여 제공할 수 있습니다. 가벼운 POC가 필요하신가요? 새 클러스터를 생성하십시오. 단기적인 환경의 구성이 필요하십니까? 문제없습니다. 보안 계획을 준수하는 하드웨어 요청이 걱정되시나요? 걱정하지 마십시오. (단순히 새 VM이나 테스트용 시스템을 요구하지 않습니다...) 이미 ECE로 처리되었습니다. 프로젝트가 QA 및 사전 운영을 위해 여러 환경이 필요합니까? 좋은 생각입니다.

ECE는 이러한 문제 해결을 위해 설계되었고, 문제를 능숙하게 해결합니다. 우리는 동일한 코드 기반을 토대로 ECE를 통해 Elastic Cloud 서비스를 지원하고 있으며, 이러한 방식으로 수년 동안 수천 개의 클러스터를 수천 차례 관리해 온 바 있습니다. 그리고 결국 가장 중요한 것은 이 제품은 Elastic과의 성장을 기대하는 모든 사람에게 이상적이라는 점입니다. 실제로 저희 최초 고객들 중 한 명은 5개의 운영 클러스터를 보유하고 있으며, 중앙 집중식 관리에서 이 제품이 향후 성장 기대치를 제공할 거라는 가치를 인지합니다.

그러면 이제 제품을 체험해보고, 가이드 문서에서 자세한 내용을 알아보세요.