빅데이터 아키텍처의 몇 가지 핵심 기술

엔터프라이즈 IT 인프라 플랫폼을 재구축하는 것은 복잡한 작업입니다. 플랫폼 변경은 주요 비즈니스 동인의 변화에 ​​의해 촉발되는 경우가 많으며, 이것이 바로 현재 일어나고 있는 일입니다. 간단히 말해서, 거의 30년 동안 엔터프라이즈 IT 기술을 지배해 온 플랫폼은 더 이상 비즈니스를 발전시키는 데 필요한 워크로드 수요를 충족할 수 없습니다.

디지털 혁신의 핵심은 비즈니스에서 가장 가치 있는 것이 된 데이터입니다. 조직은 호환되지 않는 형식, 기존 데이터베이스의 한계, 여러 소스의 데이터를 유연하게 결합할 수 없음으로 인해 소비하는 데이터로 인해 오랫동안 어려움을 겪어 왔습니다. 새로운 기술의 출현은 이 모든 것을 변화시킬 것을 약속합니다.

소프트웨어 배포 모델을 개선하는 것은 데이터 사용에 대한 장벽을 제거하는 주요 측면입니다. "데이터 민첩성"이 향상되려면 더욱 유연한 데이터베이스와 확장성이 뛰어난 실시간 스트리밍 플랫폼이 필요합니다. 실제로 기업에 유연한 실시간 "데이터 패브릭"을 제공하기 위해 결합할 수 있는 기본 기술이 7개 이상 있습니다.

대체되는 기술과 달리 이 7가지 소프트웨어 혁신은 많은 사용자의 요구와 다양한 사용 사례를 충족하도록 확장할 수 있습니다. 기업의 경우 더 빠르고 정보에 기반한 결정을 내리고 더 나은 고객 경험을 창출할 수 있습니다.

1. NoSQL 데이터베이스

RDBMS는 거의 30년 동안 데이터베이스 시장을 장악해 왔습니다. 그러나 데이터 볼륨의 지속적인 증가와 데이터 처리 속도의 가속화로 인해 기존 관계형 데이터베이스는 단점을 드러냈습니다. NoSQL 데이터베이스는 속도와 확장 능력으로 인해 그 자리를 대신하고 있습니다. 문서 데이터베이스의 경우 소프트웨어 엔지니어링 관점에서 더 간단한 모델을 제공합니다. 이 단순한 개발 모델은 시장 출시 시간을 단축하고 기업이 고객 및 내부 사용자 요구 사항에 보다 신속하게 대응할 수 있도록 도와줍니다.

2. 라이브 스트리밍 플랫폼

고객에게 실시간으로 응답하는 것은 고객 경험에 매우 중요합니다. 소비자 대면 산업이 지난 10년 동안 엄청난 혼란을 겪었다는 것은 놀라운 일이 아닙니다. 이는 실시간으로 사용자에게 반응하는 기업의 능력과 관련이 있습니다. 실시간 모델로 전환하려면 이벤트 스트리밍이 필요합니다.

메시지 기반 앱은 수년간 사용되어 왔습니다. 그러나 오늘날의 스트리밍 플랫폼은 그 어느 때보다 훨씬 더 크고 저렴합니다. 최근 스트리밍 기술의 발전으로 비즈니스를 최적화할 수 있는 다양한 새로운 방법이 열렸습니다. 이벤트 스트리밍은 소프트웨어 개발 및 테스트 팀에 실시간 피드백 루프를 제공함으로써 기업이 제품 품질을 개선하고 새로운 소프트웨어를 더 빠르게 개발하는 데 도움이 될 수 있습니다.

3. Docker 및 컨테이너

컨테이너는 개발자와 운영자는 물론 조직 자체에도 큰 이점을 제공합니다. 인프라 격리에 대한 전통적인 접근 방식은 각 워크로드에 별도의 고정 리소스 블록(물리적 서버든 가상 머신이든)을 할당하는 정적 파티셔닝입니다. 정적 파티셔닝을 사용하면 문제 해결이 더 쉬워지지만 실제로 활용도가 낮은 하드웨어로 인해 비용이 많이 듭니다. 예를 들어, 평균적인 웹 서버는 사용 가능한 총 컴퓨팅 성능의 10%만을 사용합니다.

컨테이너 기술의 가장 큰 장점은 새로운 격리 방법을 만들 수 있다는 것입니다. 컨테이너를 가장 잘 아는 사람들은 Ansible, Puppet 또는 Chef와 같은 도구를 사용하여 동일한 이점을 얻을 수 있다고 믿을 수 있지만 실제로 이러한 기술은 매우 상호 보완적입니다. 또한 기업이 아무리 노력해도 이러한 자동화 도구는 다양한 인프라와 하드웨어 설정 간에 워크로드를 자유롭게 이동하는 데 필요한 격리를 달성하지 못합니다. 동일한 컨테이너는 온프레미스 데이터 센터의 베어메탈 하드웨어나 퍼블릭 클라우드의 가상 머신에서 아무런 변경 없이 실행될 수 있습니다. 이것이 진정한 워크로드 이동성입니다.

4. 컨테이너 저장소

컨테이너 저장소는 민첩성에 매우 중요합니다. 컨테이너 이미지를 구축하기 위한 DevOps 프로세스와 이를 저장하기 위한 휴지통이 없으면 각 컨테이너를 실행하기 전에 모든 머신에 구축해야 합니다. 리포지토리를 사용하면 리포지토리를 읽는 머신에서 컨테이너 이미지를 시작할 수 있습니다. 여러 데이터 센터에서 처리할 때 이는 더욱 복잡해집니다. 한 데이터 센터에 컨테이너 이미지를 구축한 경우 이미지를 다른 데이터 센터로 어떻게 이동합니까? 이상적으로는 통합 데이터 플랫폼을 활용하여 기업이 데이터 센터 간에 저장소를 미러링할 수 있는 능력을 갖게 됩니다.

여기서 중요한 세부 사항은 온프레미스와 클라우드 컴퓨팅 간의 미러링 기능이 기업 데이터 센터 간의 미러링 기능과 크게 다를 수 있다는 것입니다. 융합 데이터 플랫폼은 조직에서 데이터 센터 인프라 또는 클라우드 컴퓨팅 인프라를 사용하는지 여부에 관계없이 이러한 기능을 제공함으로써 기업의 이 문제를 해결합니다.

5. 컨테이너 오케스트레이션

각 컨테이너에는 정적 하드웨어 파티션이 아닌 자체 개인 운영 체제가 있는 것으로 보입니다. 가상 머신과 달리 컨테이너에는 컴퓨팅과 메모리의 정적 분할이 필요하지 않습니다. 이를 통해 관리자는 대용량 메모리에 대한 걱정 없이 서버에서 많은 수의 컨테이너를 시작할 수 있습니다. Kubernetes와 같은 컨테이너 오케스트레이션 도구를 사용하면 컨테이너를 시작하고 이동하고 환경 내 다른 곳에서 다시 시작하는 것이 매우 쉬워집니다.

새로운 인프라 구성 요소가 배치된 후 MapR-DB 또는 MongoDB와 같은 문서 데이터베이스, MapR-ES 또는 Apache Kafka(Kubernetes와 같은 오케스트레이션 도구)와 같은 이벤트 스트리밍 플랫폼 및 Docker 컨테이너 구축을 위한 DevOps 프로세스를 구현한 후 소프트웨어를 배포하려면 이러한 컨테이너에 어떤 구성 요소를 배포해야 하는지에 대한 질문을 이해해야 합니다.

6. 마이크로서비스

역사적으로 마이크로서비스의 개념은 새로운 것이 아닙니다. 오늘날 차이점은 활성화 기술(NoSQL 데이터베이스, 이벤트 스트리밍, 컨테이너 오케스트레이션)이 수천 개의 마이크로서비스 생성에 따라 확장될 수 있다는 것입니다. 데이터 스토리지, 이벤트 스트리밍 및 아키텍처 오케스트레이션에 대한 이러한 새로운 접근 방식이 없다면 대규모 마이크로서비스 배포는 불가능합니다. 대량의 데이터, 이벤트, 컨테이너 인스턴스를 관리하는 데 필요한 인프라는 필요한 수준으로 확장되지 않습니다.

마이크로서비스의 핵심은 민첩성 제공입니다. 마이크로서비스는 일반적으로 하나의 기능 또는 작은 기능 세트로 구성됩니다. 기능적 작업 단위가 더 작고 집중적일수록 서비스를 생성, 테스트 및 배포하기가 더 쉽습니다. 이러한 서비스는 분리되어야 합니다. 그렇지 않으면 기업은 민첩성을 갖춘 마이크로서비스의 가능성을 잃게 됩니다. 마이크로서비스는 다른 서비스에 의존할 수 있지만 일반적으로 로드 밸런싱된 REST API 또는 이벤트 스트리밍을 통해 이루어집니다. 이벤트 스트리밍을 사용하면 기업은 요청 및 응답 주제를 사용하여 이벤트 기록을 쉽게 추적할 수 있습니다. 이 접근 방식은 전체 요청 흐름과 요청의 모든 데이터를 언제든지 재생할 수 있으므로 문제 해결에 상당한 이점이 있습니다.

마이크로서비스는 작은 작업을 캡슐화하고 서로 분리되어 있기 때문에 시간이 지남에 따라 아무런 장벽 없이 서비스를 교체하거나 업그레이드할 수 있습니다. 레거시 모드에서 RPC와 같은 긴밀한 결합에 의존하려면 모든 연결을 닫았다가 다시 설정해야 했습니다. 로드 밸런싱은 수동 구성으로 인해 오류가 발생하기 쉽기 때문에 이를 구현하는 데 큰 문제가 됩니다.

7. 서비스로서의 기능

마이크로서비스가 업계를 지배하는 것처럼 서버리스 컴퓨팅, 더 정확하게는 FaaS(Functions as a Service)라고 부르는 기술의 등장도 보게 될 것입니다. FaaS는 경량 프레임워크 덕분에 코드를 경량 프레임워크로 래핑하고, 컨테이너에 구축하고, 요청 시(일종의 트리거 기반) 실행한 다음, 자동으로 로드 밸런싱할 수 있는 방식으로 마이크로서비스를 생성합니다. FaaS의 장점은 개발자가 거의 전적으로 해당 기능에 집중할 수 있다는 것입니다. 따라서 FaaS는 마이크로서비스 접근 방식의 논리적 결론처럼 보입니다.

이벤트 트리거는 FaaS의 핵심 구성 요소입니다. 이것이 없으면 작업을 수행해야 할 때만 함수를 호출하고 리소스를 소비할 수 있습니다. 기능의 자동 호출은 FaaS를 정말 가치있게 만듭니다. 누군가가 사용자 프로필을 읽을 때마다 보안 팀에 알리기 위해 실행해야 하는 기능인 감사 이벤트가 있다고 상상해 보십시오. 보다 구체적으로 특정 유형의 레코드만 필터링할 수 있습니다. 선택 사항일 수도 있지만 결국 완전히 사용자 정의 가능한 비즈니스 기능입니다. FaaS와 같은 배포 모델을 사용하면 이러한 워크플로를 달성하는 것이 매우 간단하다는 점을 기억하는 것이 중요합니다.

이벤트 함께 퍼팅

서비스를 트리거하는 이면의 마법은 실제로 이벤트 스트림의 이벤트입니다. 특정 유형의 이벤트는 다른 이벤트보다 더 자주 트리거로 사용되지만 비즈니스에서 트리거가 되기를 원하는 모든 이벤트는 트리거가 될 수 있습니다. 트리거 이벤트는 문서 업데이트, 새 문서에서 OCR 프로세스를 실행한 다음 OCR 프로세스의 텍스트를 NoSQL 데이터베이스에 추가하는 것일 수 있습니다. 좀 더 흥미롭게 생각해보면, 이미지가 업로드될 때마다 머신러닝 프레임워크를 통해 이미지 인식과 채점을 할 수 있다. 여기에는 근본적인 제한이 없습니다. 트리거 이벤트가 정의되면 일부 이벤트가 발생하고 이벤트가 함수를 트리거하고 함수가 작업을 완료합니다.

FaaS는 마이크로서비스 채택의 다음 단계가 될 것입니다. 그러나 FaaS에 접근할 때 고려해야 할 주요 요소 중 하나가 바로 공급업체 종속성입니다. FaaS는 개발자에게 좋은 특정 스토리지 메커니즘, 특정 하드웨어 인프라 및 오케스트레이션을 숨깁니다. 그러나 이러한 추상화로 인해 호스팅된 FaaS 제품은 IT 업계에서 이제까지 볼 수 없었던 공급업체 종속에 대한 가장 큰 기회 중 하나를 나타냅니다. 이러한 API는 표준화되지 않았기 때문에 퍼블릭 클라우드의 FaaS 제품에서 마이그레이션하는 것은 완료된 작업의 거의 100%를 잃지 않고는 거의 불가능합니다. 융합된 데이터 플랫폼의 이벤트를 활용하여 FaaS를 보다 구조화된 방식으로 접근하면 클라우드 제공업체 간 이동이 더 쉬워질 것입니다.