Computer >> 컴퓨터 >  >> 프로그램 작성 >> Redis

"임피던스 불일치 테스트":데이터 플랫폼이 단순합니까 아니면 복잡합니까?

"단순함은 궁극적인 정교함입니다." —레오나르도 다빈치

“대부분의 정보는 관련이 없고 대부분의 노력이 낭비되지만 무엇을 무시해야 하는지는 전문가만이 알고 있습니다. ”—제임스 클리어, 원자 습관

다양한 시스템이 있는 멋진 데이터 파이프라인이 있습니다. 표면적으로는 매우 정교해 보이지만 실제로는 내부적으로 복잡한 혼란입니다. 서로 다른 부분을 연결하기 위해 많은 배관 작업이 필요할 수 있고, 지속적인 모니터링이 필요할 수 있으며, 이를 실행, 디버그 및 관리하기 위해 고유한 전문 지식을 갖춘 대규모 팀이 필요할 수 있습니다. 말할 것도 없이, 더 많은 시스템을 사용할수록 데이터를 복제하는 위치가 더 많아지고 동기화되지 않거나 오래될 가능성이 커집니다. 또한 이러한 각 하위 시스템은 서로 다른 회사에서 독립적으로 개발하기 때문에 업그레이드 또는 버그 수정으로 인해 파이프라인과 데이터 계층이 손상될 수 있습니다.

조심하지 않으면 아래의 3분짜리 동영상과 같이 다음과 같은 상황이 발생할 수 있습니다. 계속 진행하기 전에 시청하는 것이 좋습니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

각 시스템이 표면적으로는 단순해 보이지만 실제로는 다음과 같은 변수를 파이프라인에 가져오고 엄청난 복잡성을 추가할 수 있기 때문에 복잡성이 발생합니다.

  1. 프로토콜 - 시스템은 데이터를 어떻게 전송합니까? (HTTP, TCP, REST, GraphQL, FTP, JDBC)
  2. 데이터 형식 - 시스템이 지원하는 형식은 무엇입니까? (바이너리, CSV, JSON, Avro)
  3. 데이터 스키마 및 발전 - 데이터는 어떻게 저장됩니까? (표, 스트림, 그래프, 문서)
  4. SDK 및 API - 시스템에서 필요한 SDK 및 API를 제공합니까?
  5. ACID 및 BASE—ACID 또는 BASE 일관성을 제공합니까?
  6. 마이그레이션—시스템이 모든 데이터를 시스템 안팎으로 쉽게 마이그레이션할 수 있는 방법을 제공합니까?
  7. 내구성 - 시스템이 내구성에 대해 어떤 보장을 합니까?
  8. 가용성 - 시스템이 가용성에 대해 어떤 보장을 합니까? (99.9%, 99.999%)
  9. 확장성 - 어떻게 확장되나요?
  10. 보안—시스템은 얼마나 안전합니까?
  11. 성능—시스템의 데이터 처리 속도
  12. 호스팅 옵션—호스팅 또는 온프레미스 전용인가요 아니면 혼합인가요?
  13. 클라우드—내 클라우드, 지역 등에서 작동합니까?
  14. 추가 시스템—추가 시스템이 필요합니까? (예:Kafka용 Zookeeper)

데이터 형식, 스키마 및 프로토콜과 같은 변수는 "변환 오버헤드"에 추가됩니다. 성능, 내구성 및 확장성과 같은 다른 변수는 "파이프라인 오버헤드"에 추가됩니다. 종합하면 이러한 분류는 "임피던스 불일치"로 알려진 현상에 기여합니다. 이를 측정할 수 있다면 복잡성을 계산하고 이를 사용하여 시스템을 단순화할 수 있습니다. 잠시 후에 알아보도록 하겠습니다.

이제 귀하의 시스템이 복잡해 보일 수 있지만 실제로는 귀하의 요구에 가장 간단한 시스템이라고 주장할 수 있습니다. 하지만 그것을 어떻게 증명할 수 있습니까?

즉, 데이터 계층이 정말 단순하거나 복잡한지 실제로 어떻게 측정하고 알 수 있습니까? 두 번째로, 더 많은 기능을 추가해도 시스템이 단순하게 유지될지 어떻게 예측할 수 있습니까? 즉, 로드맵에 더 많은 기능을 추가하면 시스템도 더 추가해야 합니까?

여기서 "임피던스 불일치 테스트"가 시작됩니다. 하지만 먼저 임피던스 불일치가 무엇인지 살펴본 다음 테스트 자체에 대해 알아보겠습니다.

임피던스 불일치란 무엇입니까?

이 용어는 전기 임피던스의 불일치를 설명하기 위해 전기 공학에서 유래했으며 에너지가 A 지점에서 B 지점으로 전달될 때 에너지 손실이 발생합니다.

간단히 말해서, 당신이 가진 것이 당신이 필요로 하는 것과 일치하지 않는다는 것을 의미합니다. 사용하려면 현재 가지고 있는 것을 가져와 필요한 것으로 변환한 다음 사용합니다. 따라서 불일치 및 불일치 수정과 관련된 오버헤드가 있습니다.

우리의 경우 데이터가 어떤 형식이나 양으로 있고 사용하기 전에 변환해야 합니다. 변환은 여러 번 발생할 수 있으며 그 사이에 여러 시스템을 사용할 수도 있습니다.

데이터베이스 세계에서 임피던스 불일치는 두 가지 이유로 발생합니다.

  1. 변환 오버헤드:시스템이 데이터를 처리하거나 저장하는 방식은 데이터가 실제로 어떻게 보이는지 또는 데이터에 대해 어떻게 생각하는지와 다릅니다. 예:서버에서 컬렉션, 스트림, 목록, 집합, 배열 등과 같은 다양한 데이터 구조에 데이터를 저장할 수 있는 유연성이 있습니다. 데이터를 자연스럽게 모델링하는 데 도움이 됩니다. 그러나 저장하려면 이 데이터를 RDBMS 또는 JSON 문서 저장소의 테이블에 매핑해야 합니다. 그런 다음 데이터 읽기에 대해 반대 작업을 수행합니다. 객체 지향 언어 모델과 관계형 테이블 모델 간의 특정 불일치를 "객체 관계 임피던스 불일치"라고 합니다.
  2. 파이프라인 오버헤드:서버에서 처리하는 데이터의 양과 데이터 유형은 데이터베이스가 처리할 수 있는 데이터의 양과 다릅니다. 예를 들어, 모바일 장치에서 발생하는 수백만 개의 이벤트를 처리하는 경우 일반적인 RDBMS 또는 문서 저장소는 해당 이벤트를 저장하거나 이러한 이벤트를 쉽게 집계하거나 계산하는 API를 제공하지 못할 수 있습니다. 따라서 이를 처리하려면 Kafka 또는 Redis Streams와 같은 특수 스트림 처리 시스템이 필요하고 이를 저장할 데이터 웨어하우스도 필요합니다.

임피던스 불일치 테스트

테스트의 목표는 전체 플랫폼의 복잡성과 향후 더 많은 기능을 추가함에 따라 복잡성이 증가하거나 축소되는지 여부를 측정하는 것입니다.

테스트 작동 방식은 "임피던스 불일치 점수"(IMS)를 사용하여 "변환 오버헤드"와 "파이프라인 오버헤드"를 간단히 계산하는 것입니다. 이것은 귀하의 시스템이 다른 시스템에 비해 이미 복잡한지, 그리고 시간이 지남에 따라 더 많은 기능을 추가함에 따라 복잡성이 증가하는지 여부를 알려줍니다.

IMS를 계산하는 공식은 다음과 같습니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

공식은 단순히 두 유형의 오버헤드를 더한 다음 기능 수로 나눕니다. 이렇게 하면 총 오버헤드/기능(즉, 복잡성 점수)을 얻을 수 있습니다.

이를 더 잘 이해하기 위해 4개의 다른 간단한 데이터 파이프라인을 비교하고 점수를 계산해 보겠습니다. 그리고 두 번째로, 시간이 지남에 따라 더 많은 기능을 추가할 때 IMS 점수가 어떻게 변하는지 볼 수 있도록 두 단계로 간단한 앱을 빌드한다고 가정해 보겠습니다.

1단계:실시간 대시보드 구축

모바일 장치에서 수백만 건의 버튼 클릭 이벤트가 발생하고 있으며 감소 또는 급증이 있는 경우 경고가 필요하다고 가정해 보겠습니다. 또한 이 모든 것을 더 큰 응용 프로그램의 기능으로 고려하고 있습니다.

사례 1:테이블이 적합하지 않을 수 있지만 이러한 이벤트를 저장하기 위해 방금 RDBMS를 사용했다고 가정해 보겠습니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =1
    1. 이벤트 스트림을 테이블로 변환해야 합니다.
  2. 파이프라인 오버헤드 =1
    1. 파이프라인에 단일 DB가 있습니다.
  3. 기능 수 =1
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

사례 2:Kafka를 사용하여 이러한 이벤트를 처리한 다음 RDBMS에 저장했다고 가정해 보겠습니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =1
    1. Kafka는 클릭 스트림을 쉽게 처리할 수 있습니다. 그러나 RDBMS에 대한 Kafka는 오버헤드입니다.
  2. 파이프라인 오버헤드 =2
    1. 두 시스템(RDBMS 및 Kafka)이 있습니다. Zookeeper는 무시하고 있습니다.
  3. 기능 수 =1
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

사례 3:Kafka를 사용하여 이러한 이벤트를 처리한 다음 KsqlDB에 저장했다고 가정해 보겠습니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =0
    1. Kafka는 클릭 스트림을 쉽게 처리할 수 있습니다.
  2. 파이프라인 오버헤드 =1
    1. 시스템이 하나뿐입니다( Kafka + KSqlDB). Zookeeper는 무시합니다.
  3. 기능 수 =1
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

사례 4:Redis Streams를 사용하여 이러한 이벤트를 처리한 다음 RedisTimeseries에 저장했다고 가정합니다(둘 다 Redis의 일부이며 Redis와 기본적으로 작동함).

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =0
    1. Redis Streams는 클릭 스트림을 쉽게 처리할 수 있습니다.
  2. 파이프라인 오버헤드 =1
    1. 단 하나의 시스템(Redis Streams + RedisTimeSeries)
  3. 기능 수 =1
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

1단계 이후의 결론: 

이 예에서 4개의 시스템을 비교한 결과 "Case 3" 또는 "Case 4"가 IMS가 1인 가장 단순한 것으로 나타났습니다. 이 시점에서 둘 다 동일하지만 더 많은 기능을 추가해도 동일하게 유지됩니다. ?

시스템에 더 많은 기능을 추가하고 IMS가 어떻게 유지되는지 살펴보겠습니다.

2단계:IP 허용 목록으로 실시간 대시보드 구축

동일한 앱을 빌드하지만 허용된 IP 주소에서만 제공되도록 하고 싶다고 가정해 보겠습니다. 이제 새로운 기능을 추가하고 있습니다.

사례 1:테이블이 적합하지 않을 수 있고 IP 허용 목록에 Redis 또는 MemCached를 사용했지만 RDBMS를 사용하여 이러한 이벤트를 저장했다고 가정합니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =1
    1. IP 허용 목록에는 변환이 필요하지 않습니다. 그러나 이벤트 스트림을 테이블로 변환해야 합니다.
  2. 파이프라인 오버헤드 =2
    1. Redis + RDBMS가 있습니다.
  3. 기능 수 =2
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

사례 2:Redis + Kafka + RDBMS를 사용하고 있다고 가정합니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =1
    1. IP 허용 목록에는 변환이 필요하지 않습니다. 또한 Kafka는 스트림을 쉽게 처리할 수 있습니다.
  2. 파이프라인 오버헤드 =3
    1. Redis + Kafka + RDBMS가 있습니다. 참고:Kafka에도 Zookeeper가 필요하다는 점을 무시합니다. 추가하면 숫자가 더 줄어듭니다.
  3. 기능 수 =2
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

사례 3:Redis + Kafka + KsqlDB를 사용하고 있다고 가정합니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =0
    1. IP 허용 목록에는 변환이 필요하지 않습니다. 또한 Kafka와 KsqlDB는 스트림을 쉽게 처리할 수 있습니다.
  2. 파이프라인 오버헤드 =2
    1. Redis +(Kafka + KsqlDB)가 있습니다. 참고:이 경우 동일한 시스템의 Kafka + KsqlDB 부분을 고려합니다.
  3. 기능 수 =2
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

사례 4:Redis + Redis Streams + RedisTimeSeries를 사용하고 있다고 가정합니다.

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?
  1. 변환 오버헤드 =0
    1. IP 허용 목록에는 변환이 필요하지 않습니다. 또한 Redis Streams 및 RedisTimeseries는 스트림 및 알림을 쉽게 처리할 수 있습니다.
  2. 파이프라인 오버헤드 =1
    1. Redis +  Redis Streams + Redis TimeSeries가 있습니다. 참고:이 경우 세 가지 모두 동일한 시스템의 일부입니다.
  3. 기능 수 =2
임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

2단계 이후의 결론: 

추가 기능을 추가했을 때 

  • 사례 1은 1단계에서 2에서 1.5로 떨어졌습니다.
  • 사례 2는 1단계에서 3에서 2로 떨어졌습니다.
  • 사례 3은 1단계에서 1이었고 1로 유지되었습니다.
  • 사례 4는 1단계에서 1이었고 0.5(최상)로 떨어졌습니다.

따라서 우리의 예에서 가장 낮은 IMS 점수 중 하나인 사례 4는 새로운 기능을 추가함에 따라 실제로 더 좋아졌고 결과는 0.5가 되었습니다.

참고:더 많거나 다른 기능을 추가하는 경우 사례 4가 가장 단순하지 않을 수 있습니다. 그러나 그것은 IMS 점수의 개념입니다. 모든 기능을 나열하고 다양한 아키텍처를 비교한 다음 사용 사례에 가장 적합한 아키텍처를 확인하기만 하면 됩니다.

사용을 더욱 간편하게 하기 위해 간단한 스프레드시트로 구현하여 IMS 점수를 계산할 수 있는 계산기를 제공합니다.

IMS 계산기

사용 방법은 다음과 같습니다.

  1. 각 데이터 영역 또는 데이터 파이프라인에 대해 다음을 나열하면 됩니다.
    1. 현재 가지고 있는 기능.
    2. 로드맵에 있는 기능입니다. 이는 데이터 영역이 추가 오버헤드 없이 향후 기능을 계속 지원할 수 있도록 하려는 것이기 때문에 중요합니다.
  2. 그런 다음 각 기능에 대한 변환 오버헤드와 파이프라인 오버헤드를 매핑합니다.
  3. 마지막으로 모든 오버헤드의 합계를 기능의 수로 나눕니다.
  4. 서로 다른 시스템의 파이프라인에 대해 2단계와 3단계를 반복하여 비교 및 ​​대조합니다.

데이터 파이프라인 1

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

데이터 파이프라인 2

임피던스 불일치 테스트 :데이터 플랫폼이 단순합니까 아니면 복잡합니까?

요약

결과에 대해 생각하지 않고 도취되어 복잡한 데이터 계층을 구축하는 것은 매우 쉽습니다. IMS 점수는 당신이 당신의 결정을 의식하도록 돕기 위해 만들어졌습니다.

IMS 점수를 사용하여 사용 사례에 대해 여러 시스템을 쉽게 비교 및 ​​대조하고 기능 집합에 가장 적합한 시스템을 확인할 수 있습니다. 또한 시스템이 기능 확장을 유지하고 가능한 한 단순하게 계속 유지할 수 있는지 확인할 수 있습니다.

항상 기억하십시오:

"단순함은 궁극적인 정교함입니다." — 레오나르도 다빈치

“대부분의 정보는 관련이 없고 대부분의 노력이 낭비되지만 무엇을 무시해야 하는지는 전문가만이 알고 있습니다. ” — James Clear, 원자 습관