대부분의 “빅 데이터 아키텍쳐”

원문 : http://venublog.com/2012/11/30/typical-big-data-architecture/

시간이 없어서 핵심부분만 정리해봅니다. 빅데이터를 4가지 요소로 분해하고 이때 중요한 부분들을 각부분별로 정리한 글입니다. 설한 부분은 한줄로 요약하고 중요한 부분은 원문으로 올렸습니다.(대강번역..).

대부분의 빅데이터 아키텍쳐는 아래와 같습니다. 몇가지 부분이 빠지거나 추가될수는 있지만 대채로 아래와 같다고 볼수 있습니다.(저도 동의함)

“Big” Data Architecture

Big Data Architecture


대채로 4가지 요소의 느슨한 구조를 취하고 있다고 볼수 있습니다.

1. Data Source

다양한 형태의 데이터 소스들

  • Data from SQL, NoSQL stores (MySQL, Oracle, PostgreSQL, MongoDB, etc. – Mostly structured)
  • (Semi/Un)-structured data (CRM, marketing, campaign, spend, revenue, leads,  etc.)
  • Web logs or other log files (weblogs, user clicks, user visits, activity, etc.)

2. Data Transformation

 ETL (Extract, Transform and Load) or import/export tools and/or scripts.

로그관리 툴을 고려할수 도 있다. .

  • ETL, ELTL tools (bash/python/perl/java scripts, Business Objects, SSIS, Kettle, etc.)
  • SQOOP (Data Source to Hadoop data transformation tool, JDBC compatible)
  • Import/Export tool (SQL/NoSQL vendor specific tools)
  • Log Management tools (Splunk, Syslog, Custom log filter scripts, flume, scribe, loggly, etc.)

3. Data Processing or Data Integration

다양한 목적을 위한 데이터 처리 및 병합

  • Hadoop and Ecosystem (Hadoop/HDFS, Map-reduce, HBase, Hive, Impala, Pig etc) – uses HDFS as native storage
  • Data Warehouse and Analytics solution (MySQL, SQL Server, Vertica, Green Plum, Aster Data, Exadata, SAP HANA, IBM Netezza, IBM Pure Data, Tera Data, etc.) – Uses vendor specific storage, optionally uses HDFS, even though with degraded performance.
  • In-memory Analytics (SAS, Kognitio, Druid, etc.). This is an emerging market and trying to take advantage by reading directly from HDFS. We will see lot of in-memory analytics in coming days.

4. Data Consumption

Data consumption components [(ad-hoc) or externally (using APIs)]

사용가능한 형태로 구성

  • Reporting (custom dashboards, micro strategy, pentaho, business objects, cognos, hyperion, tableau,  etc.)
  • Search or Discovery (solr, elastic search, tibco spotfire, datameer etc.)
  • Data Science, Mining and Analysis (mainly for internal data analysis to predict or estimate the overall performance and also drive recommendation using set of algorithms, user defined map-reduce jobs or ad-hoc queries)

4가지 요소의일부로 모니터링 역시 필요하다.(퍼포먼스,오류,등등..)

Advertisements

Big Data Predictions for 2013

Big Data Predictions for 2013

원문: http://java.dzone.com/articles/big-data-predictions-2013 

2013년에 빅데이타 분야에서 어떤 부분들을 주목해야 할지 잠깐 살펴 보도록 하겠습니다. 

Real-Time Hadoop

첫번째 소개할 내용은 ImpalaDrill 등,빅데이터 오픈소스 플랫폼을 리얼타임으로 사용 할 수 있도록 지원 하는 솔루션 입니다. 기존의 빅데이터 기술이 batch system 위주 였다면, 이제 앞에서 언급된 기술들을 바탕으로 기존 빅데이터 기술을 실시간 형태로 진화 할 수 있도록 지원합니다. 유의해야 할점은 앞서 말씀드린 실시간의 범위와 실제 활용할 때 발생하는 제약 사항은 확인 필요 하다고 판단됩니다. 자세한 내용은 구글을 통해 2010년에 오픈된 Dremel paper 를 통해 내용을 확인하실 수 있습니다. 참고로 Impala 블로그에 자세히 나와 있습니다.

Cloud-Based Big Data Solutions

두번째는 빅데이터 솔루션의 클라우드화 입니다. 온라인 마켓의 지존인 아마존은 EMR(Elastic Map Reduce)을 사용 중 입니다. 빅데이터 솔루션 역시 사용한 많큼 지불 한다는 것입니다. 기존 밴더들도 사용한 만큼 지불하는 라이선스 방식으로 전환 중이며, 2013년엔 많은 빅데이터 솔루션이 클라우드 화 되기를 기대해 봅니다.

Big Data Appliances

빅데이터를 플랫폼 구축시 고가의 장비를  활용할 수 있지만, 좀더 저렴한 비용으로 구축 될만한 희소식들이 몇가지 있습니다.  GPUs를 서버에 올려 Virtual OpenCL 과 같은 GPU 가상화 클러스터 솔루션으로 만들수 있습니다. 이러한 솔루션은 home-made 버전으로 이미 존재합니다. 또하나 기대 할 만한 것은 모바일에 사용되는 ARM 프로세서를 서버로 전향 하는 것입니다. Dell,HP등 이 이미 시도를 하고 있습니다. 마지막으로 Parallella는 16코어 수퍼 컴퓨터를 99달러에 제공할 수 있다고 합니다.   2013 supercomputer challenge 에 주목해야할 만한 내용이네요. 로드맵은 64부터 1000개까지 계획중이라고 합니다. 향후에는 저비용의 Parallel Clusters를 기대해 볼수 있겠내요. 하드웨어 제조 비용이 내려 갈수록 당연히 빅데이터 구축에 필요한 서버 장비의 단가를 낮추는 효과를 가져 올 것이며, 기능 역시 업그레이드 됨에 따라 빅데이터 분야의 발전역시 가속화 되리라 예상됩니다.

Distributed Machine Learning

추천시스템으로 유명한 마하웃은  Machine Learning 분야의 훌륭한 오픈소스 플랫폼 이지만 Batch 처리 위주의 Map Reduce가 최선의 선택인지는 의심해 볼 여지가 있습니다. 실제 Daisy에 적용중인 Mahout은 M/R사용시 비효율적인 부분들이 존재 합니다.이러한  부분을 개선한 분산 머신러닝 시스템인Jubatus가 있습니다. 가장 주목할만한 내용은 스트리밍 형태의 머신러닝 기능을 수용할수 있다는군요. 이를 활용하면 실시간 추천이 가능 할 것이라 예상됩니다. 빅데이터 분야가 점점 실시간쪽으로 전환되어 가고 있다는 느낌을 주는 내용입니다.

Easier Big Data Tools

마지막으로 오픈소스로 공개된 빅데이터 플랫폼은 무료라는 장점이 있지만 상용에 비해 사용자 인터페이스가 떨어진다는 단점이 있습니다. 빅데이터의 내용을 분석에 좀더 집중할수 있더록 드래그앤 드랍형태와 같은 기능들을 포함된  빅데이터 오픈 소스 플랫폼들이 나올것이라 예상 하고 있습니다.Radoop(RapidMiner + Mahout), TableauDatameer과 같은 이미 상용화된 툴을 오픈 소스로 만나볼 수 있도록 기대해 봅니다.

맺음말

짧지만 간략한 내용을 읽어보고 느낀점은, Big Data 분야는 정말 끈임없이 빠르게 진화 중 이라는 것 입니다.이제까지 빅 데이터 분야는 대용량 데이타의 분산 처리가 화두였다가 2013년을 기점으로 실시간 분야로 전환하지 않을까 조심스례 추측 해봅니다. 또한 클라우드화 역시 가속화 될 것으로 보입니다.  기술의 발전 방향은 시대가 요구하는 방향으로 점점 맞추어 가고 있으며, 기업들 역시 이러한 흐름을 거스를 수 없고, 그런 기업들에 속한 우리들 역시 기술이 선회하는 방향을 미리 파악하여 대처할 필요가 있다고 생각 됩니다.

Oracle NoSQL Database Overview

오라클은 올해 9월에 NoSQL 제품을 내놓았습니다. 데이터 베이스 분야에서 오랜 기간 동안 제왕의 자리에 있던 오라클이 NoSQL을 만드는 건 그리 어렵지 안을 거라 생각 됩니다. 그래서 몇 가지 주요 특징들을 살펴 보고자 합니다.

우선 태생은 이렇습니다.


Oracle Berkeley DB ->Oracle Berkeley DB Java Edition -> Oracle Berkeley DB Java Edition High Availability(BDB JE/HA) -> Oracle NoSQL Database (BDB JE/HA와 Oracle NoSQL Database에 대한 비교자료가 있으니 참고 하시기 바랍니다. 어떤 블로그 에서는 BDB JE/HA 는 엔진이며 NoSQL은 자동차에 비유를 하기도 했습니다. 관계야 보는 시각에 따라 달라 질 수 있으니…)

간략하게 특징을 요약하면


  • BerkleyDB Java Edition 기반으로 key-value 기반구조 이다(Simple Data Model)
  • single-master 와 multireplicas로 구성 되 있다(High Availability )
  • fail-over 를 지원 하기 위해 PAXOS 기반으로 자동 master선택을 지원한다.(High Availability )
  • 조정 가능한 일관성 정책들을(consistency policies) 지원한다(Predictable behavior)
  • auto-sharding(Scalability)
  • 웹콘솔 기능지원(Administration)

 Oracle에서 언급한 주요 특징은


  • Simple Data Model
  •  Key-value 기반의 구조로 되어있다
  •  Java API 기반의 CRUD를 지원한다
  • Scalability
  • 자동으로 해쉬 기반의 분산 파티셔닝을 지원한다
  • 지능형 NoSQL 데이터베이스 드라이버를 통한 최적의 데이터 액세스를 제공
  • Predictable behavior
  • 조절 가능한 ACID 트랜젝션 에 대해 전체 또는 수행 단위별 지원
  • 지연시간 경계를 통한 B-tree 케싱 과 효과적인 쿼리 디스페칭 기능
  • High Availability 
  • No single point of failure
  • 내장된, 컨피그 가능한 복제기능
  • 단일 또는 다중노드 장애에 대해 탄력적
  • 데이터 센터 복제를 통한 재해 복구
  • Easy Administration
  • 웹콘솔과 커멘드 라인 인터페이스 제공
  • 시스템 및 노드 매니지 먼트 기능 제공
  • 시스템의 토플로지, 상태, 실시간 부하,흐름 및 평균 지연, 이벤트 및 경고 상태 viewing 기능 제공

주목할만한 부분은


Scalability, Predictable behavior, High Availability 이며, 추가적으로 어드민 기능도 보실 수 있습니다.

그럼 그림을 보며 세부 내용을 좀더 살펴 보기로 하겠습니다.

 
그림1) Oracle NoSQL Database Architecture: September 2011

Scalability

전반적인 Architecture를 살펴 보면 해쉬 알고리즘 기반으로 데이터를 분할에 파티션 단위로 쪼겐 후 가용성을 확보하기 위해 Replication 구조를 도입한 케이스라고 볼 수 있습니다.(어디서 많이 보던 구조이네요. 용어들도 비슷하고). Scalability 요소를 들여다 보면 Hash function과 Partition Numbers가 보이며 그 중 가장 핵심적인 부분은 Partition(sharding) 이라고 보여 집니다. 여기서 Partition 개념은 MongoDB에서 보았던 샤딩(sharding)개념과 동일 하며 자동으로 미리 설정된 범위에 따라 추가가 될 수 있는 기능입니다. 설정된 범위에 따라 자동으로 확장 가능 하니 클라우드 환경(scale-out)에서는 필수 기능이 아닌가 싶습니다. 이렇게 분리된 데이터에 대한 접근 관리를 위해 필요로 하는 기능들을 오라클에서 제공하는 클라이언트 드라이버가 어떻게 처리하는 과정을 살펴보도록 하겠습니다.

그림2): Oracle NoSQL Database Processing : September 2011

  1. 어플리케이션에서 클라이언트 드라이버로 데이터를 넘겨준다.
  2. 클라이언트 드라이버에서 “Katana”라는 키를 기반으로 데이터를 분할하여 파티션 넘버를 할당한다.
  3. 클라이언트 드라이버는 Replication 그룹에 파티션에 할당하기 위해 컨설트 한다.
  4. Replication 그룹이 할당되고, 클라이언트 드라이버는 Replication 그룹 상태 테이블(RGST)을 컨설트 한다.
  5. RGST는 각 Replication 노드를 구성하는 Replication 그룹에 대한 정보를 포함한다.
  6. RGST를 기반으로 클라이언트 드라이버는 요청을 보내기위한 적당한 노드를 선택 한다.(요청은 반드시 마스터 노드에게만 전달 해야한다)
  7. 리플리케이션 노드는 명령을 수행한다. putIfAbsent()일 경우 키가 존재하면 단순히 에러만 리턴 하고 , 존재하지 안을 경우는 키를 추가 한 다음(master) 다른 노드들(replica)에게 새로운 key/value값을 전달한다.

처리 과정을 살펴보면 클라이언트 드라이버의 역할은 아주 다양하다는 것을 아실 수 있습니다. 클라이언트 드라이버는 2-6의 과정에 관여를 하고 있으며 “클라이언트 드라이버가 최적화된 기능을 제공하지 않는다면 시스템 전반적으로 영향이 크게 미치지 않을까?” 라고 짐작 하실 수 있을 것 입니다.  

Predictable behavior

이 부분은  consistency policies 위주로 정리해 보았습니다. 대다수의 NoSQL database들은 eventual consistency를 제공 하며, Oracle NoSQL역시 이 기능을 제공합니다. 추가적으로 consistency 정책에 대해 선택옵션 기능을 추가 하였습니다.

그림3): Oracle NoSQL Database Consistency : September 2011

오른쪽으로 가까워 질수록 데이터에 대한 일관성은 보장되며 속도는 떨어질 것으로 예상되며,반면 왼쪽은 일관성이 덜 보장되나 속도는 올라갈 것으로 예상 됩니다 .이러한 기능이 주는 장점은 플랫폼 변경 없이 사용가능, 즉, 신규 개발 시 마다 새로운 플랫폼에 대해 적응할 필요성이 줄어든 다는 점입니다. 그러나 간과해선 안 되는 부분은 어떠한 정책을 선택 하던지 사전에 데이터에 대한 분석이 철저히 이루어져야 할 필요가 있다는 것입니다.

그림4): Oracle NoSQL Database : September 2011

이러한 유동적인 데이터 접근 정책을 DBMS설치 단계가 아닌 코딩 단계에 적용 가능하게 한다는 것 또한 타 NoSQL에 비해 눈 여겨 볼 부분이라고 보여집니다. 이것이 주는 의미는 각 오퍼레이션 별 서로 다른 정책 설정 가능하며, 플랫폼 대한 적용 성 검토 이후 서비스 방향이 변경 됨에 따라 새로 재검토 할 경우 유동적으로 대처 가능하리라 예상됩니다. 이런 4가지 형태의 지원은 CAP 모델에 있어서 C/P 또는 A/P 를 지원 가능 하게 한다고 생각 되며, 데이터에 대한 유연한 형태의 데이터 접근을 보장 하고, 다른 NoSQL이 같지 못한 특징 중에 하나로, 서비스 성격에 맞추어 변경할 필요성이 없어짐으로 인해 개발자의 신규 플랫폼 적응에 대해 부담감을 덜어주는 측면이 존재 한다고 생각 됩니다.

High Availability

고 가용성 측면에서 눈 여겨 볼 부분은 1Master/ 2Replica 부분으로 Master/slave 구조와 유사한 방식이 있습니다. 각각의 기능은 Master는 read/write 가 가능 하며 Replica는 read-only 입니다. Master/Replica를 합하여 Replication group 이라고 부르며 위 그림1)에서는 하나의 Replication 그룹이 데이터 센터 1과 2로 분할되어 있는 구조로 구성 되 있습니다(Replica는 확장가능). 이러한 구성이 주는 장점은 데이터 센터 1이 장애가 날 경우를 대비 해서 구성될 때 효과를 볼 수 있으며, 단점은 공간적으로 분리돼 있을 때 Replication 구조를 유지하기 위한 오버헤드가 발생한다고 볼 수 있겠습니다. 이러한 방식에서 우리는 두 가지 정도에 대해 의문을 가질 수 있습니다. “마스터에 장애가 발생다면? Replica 는 왜 read only일까?” 마스터에 장애가 발생할 경우(“No single point of failure”)에는 Replica set 중에서 마스터를 빠르게 재 선출(Paxos protocol 사용) 함으로서 마스터의 공백으로 인한 write 불가 현상을 커버하고, 다수의 Replica의 read-only 기능은, NoSQL이 같고 있는 장점 중에 하나인, 빠른 데이터 처리를 지원하기 위해서 필수라고 판단 되며(멀티 write는 transection 비용증가) 멀티 액세스를(master/replica set 사용) 가능하게 함으로서 많은 요청에 대비 할 수 있는 이점을 제공 합니다.

또한 Replication 기능에 대해 한가지 알아두어야 할 점은 Read기능은 Replication group(master/replica)을 모두 사용 가능해서 성능 향상에 도움이 되지만 Write기능은 Master에서 각replica에게 복제 되는 과정을 거쳐야 하기 때문에 쓰기 성능에 영향을 줄 수 있습니다.

아래 두 개의 그래프는 Oracle에서 제공한 자료로 Oracle NoSQL Database에 대한 Benchmark 자료를 살펴 보도록 하겠습니다.

차트1) Oracle NoSQL Database : September 2011)

그래프가 표현하는 내용은 데이터 증가에 따라 처리율과 평균 지연시간이 같이 상승 함을 나타내며, 파란색 라인은 왼쪽(초당 처리량)을 보시면 되고 빨간색은 오른쪽(지연시간)을 보시면 됩니다.

차트2) Oracle NoSQL Database : September 2011)

두 번째 그래프에서는 Read와 Update에 대한 지연 율은 데이터가 증가하면서 오히려 더 감소한 후 수평에 가까운 형태를 보입니다. 두 개의 차트를 비교해볼 때 파란색 선은 동일한 패턴을 보이나, 갈색 선은 패턴이 달라진걸 알 수 있습니다. 원인은 Replication에 있다고 판단되며, 쓰기는 Master에서만 가능하나, 읽기는 replica셋에서 가능하기 때문입니다.   시사점


수많은 NoSQL Database가 존재하며 각각 특성도 다양합니다. 그들의 대부분은 누군가의 필요로 인해 만들어 졌으며, 우리는 그러한 제품들이 왜 만들어 지고, 사용 되고 있는지 정확히 알 필요성이 있습니다. 그래야만 우리가 만들어가는 서비스에 효율적인 형태로 사용 할 수 있기 때문입니다. 이렇게 효율적으로 사용 되기 위해서는 –       NoSql 적용 기준 정리 (사전 테스트 환경 제공. 아키텍쳐 검토. ) –       데이터 중요도에 따른 적용 정책 가이드 등에 대한 제도가 정착이 되면 좀더 성공적으로 NoSQL을 도입 할 수 있을 거라 예상 됩니다.

Reference

http://www.oracle.com/technetwork/database/nosqldb/overview/index.html http://www.oracle.com/technetwork/database/berkeleydb/berkeleydb-je-ha-whitepaper-132079.pdf http://www.oracle.com/technetwork/database/nosqldb/learnmore/nosql-database-498041.pdf

Security Considerations in Accessing NoSQL Databases

Posted by Srini Penchikala on Nov 15, 2011
http://www.infoq.com/articles/nosql-data-security-virtual-panel
요약(NoSQL 데이터베이스 접속 시 보안 고려사항)

기존의 RDBMS에 비해 NoSQL은 비교적 신기술에 해당하며, 보안 취약점 역시 RDBMS에 비해 더 많은 검증이 필요한 것이 사실입니다. 아래 언급된 내용 중 NoSQL이 향후3년간 집중과 관심을 받은 만큼 다양한 보안 이슈가 등장할 것으로 예상하고 있습니다. 오픈 소스 형태로 배포된 경우가 많아 취약점 역시 쉽게 노출될 것으로 보이며, 반면 문제점 역시 빠르게 해결 될 것이라 예상됩니다.
전반적인 대화 내용 중, 중요한 내용을 살펴보면, NoSQL 데이터베이스는 보안측면에서 기존 RDBMS와 별 차이는 없지만, 클러스터링 측면에서는 차이가 있는 것으로 판단되며, 각각의 DBMS별로 보안정책도 다르게 적용해야 한다는 사실을 알 수 있습니다. 보안에 대한 표준은 없으나 대부분 어플리케이션(미들웨어)에서 보안관련 내용을 처리 하는게, 보안관련 사항을 적용 하는 일반 적인 방법 이라 할 수 있겠습니다. 보안에 관련된 사항을 살펴보면

공통적으로(RDBMS,NoSQL) 주의해야 할 사항은

1. 부족하거나 잘못된 입력 검증

  • 사용자가 입력한 내용 여과 없이 데이터베이스에게 전달 할 경우 SQL injection 같은 위      험에 노출 될 가능성이 있습니다. 입력된 내용을 어플리케이션 단에서 적절한 검증 또는 권장되는 함수를 통해 데이터베이스로 전달하는 게 중요하다고 판단 됩니다.

2. 어플리케이션 레벨 권한 핸들링 에러
3. 인증 취약, 보안되지 안은 통신

  • 기본적으로 NoSQL의 설치 시 별다른 권한 인증 없이 동작 가능 하도록 디자인된 케이스들을 볼 수 있습니다. 이는 개발 시 편리성을 제공 하기도 하지만, 도메인 또는 자체적으로 별도 어플리케이션을 통하지 않고 접근이 가능한 케이스 일 경우 서비스 오픈 전 반드시 인증부분을 보완하여 적용하는 것은 필수라고 판단 됩니다.

4. 암호화되지 않은 데이터에 대한 불법 접근

  • 데이터 베이스 자체가 암호화하여 저장하는 기능을 가지고 있지 않다면 중요한 내용들은 암호화를 통해 저장하는 게 올바른 선택이라고 생각 됩니다. 최근 주민등록 번호와 같은 개인정보들을 암호화 하여 저장되도록 방침이 정해진 것 역시 이러한 불법 접근에 대해 사전에 대비 하기 위한 것 이라 볼 수 있습니다. 접근 방법이 다양하여, 만약 어떠한 경우에라도 데이터가 노출이 될 경우, 암호화 된 데이터는 쉽게 접근이 불가능 할 것이며, 이는 최후의 보안정책 이라고도 할 수 있습니다.

이러한 공통적인 요소 외에도 NoSQL 제품들의 보안 취약성들이 존재합니다.

NoSQL측면에서 특별히 강조되는 부분을 살펴보면
1. 데이터베이스 종류에 따라 서로 다른 보안이 필요

  • 아래 내용을 에서 Cassandra, MongoDB, CouchDB 는 서로 다른 인증방식을 취하고 있으며 심지어 같은 제품이라 하더라도 버전별 다른 기능을 제공 합니다. 이러한 점에서 각DB별 제공하는 보안기능을 미리 확인한 후 도입여부를 결정하는 것이 적절하다고 판단 됩니다.

2. 대부분의 NoSQL은 injection공격에 노출될 가능성이 있음

  • 일반적으로 NoSQL은 injection공격에 취약하지 않다는 견해가 있는데, 이는 잘못된 견해이며, 어플리케이션 구현단에서 적절히 대처를 해야 합니다. NoSQL injection을 회피하기 위한 방법 중 하나로 권장함수 사용을 권하고 있습니다.

3. NoSQL 향후 3년이내 다양한 이슈 발견예상

  • RDBMS는 오랜기간에 걸처 안정화 됬으나 지금까지도 보완강화를 위해 꾸준히 업데이트 중이며 반면, NoSQL경우 태생자체가 오래 되지 않아 수많은 검증이 필요하다고 판단 됩니다. 이부분은 꾸준히 업데이트를 통해 문제점을 보완해나가야 하며 MongoDB의 상용 버전과 같은 지속적으로 업데이트 가능한 제품을 선택하는 것도 최초 선택 시 중요한 사항이라고 생각 됩니다.

4. 클러스터 보안점 취약

  • 샤딩, 리플리케이션, 클러스터링등 NoSQL자체가 대량의 데이터를 처리하기 위해 디자인된 많큼, 표면적으로 기존 RDBMS와 비교해볼 때 많은 부분이 노출 되 있다고 볼 수 있습니다. 또한 클러스러링 환경 자체가 속도나 퍼포먼스에 치중한 많큼 상대적으로 보안관련 기능이 취약 할 수 있으며, 이러한 특징을 잘 이해 할 필요가 있습니다.

이러한 보안 이슈를 해결하기 위해 일반적으로 권장 되는(표준화된) 방법은 없으며, 주로 미들웨어에 접근에 관리기능을 포함하여 개발이 진행되는 경우가 많습니다. 이럴 때 사용 할 수 있는
대표적인 미들웨어 는(자바 환경 일 경우)


1. JSSA(Java Authentication and Authorization Service)프레임웍
2. 스프링보안 프레임웍,
3. 아파치 Shiro 프레임웍,
4. J2EE프레임웍 등.

등이 존재하며 꼭 위의 프래임웍을 사용하지 않더라도 해당기능을 대치 할 수 있는 기능으로 사용하셔도 무방할 것으로 판단 됩니다.

아래 원문과 번역 내용을 첨부합니다. (번역 미숙으로 원문도 같이 첨부합니다.)

원문
Security Considerations in Accessing NoSQL Databases

NoSQL databases 는 기존의 RDBMS에 비해 semi-structured 또는 unstructured 데이터 저장에 대한 옵션형태의 지원을 제공한다. 비록 NoSQL database기반 개발은 최근 점점 더 많은 주목을 받고 있기는 하나, NoSQL 데이터에 대한 저장이나 접근에 대한 보안은 충분히 강조되고 있지 않다. 이 가상 패널의 토의 기사는 NoSQL 데이터 베이스 사용시 보안에 대한 고려사항 및 최적의 예제에 대해 초점을 맞췄다.

Panelists:
• Ben-Gurion University Team (BGU): The BGU team includes:
o Lior Okman
o Nurit Gal-Oz
o Ehud Gudes
o Yaron Gonen
They have recently published a research paper “Security Issues in NoSQL Databases” in proceedings of the IEEE TrustCom-11. Nov 2011, Changsha, China.
그들은 최근 IEEE TrustCom-11 에서 “Security Issues in NoSQL Databases” 라는 주제로 발표하였다.
• John Heasman: John is General Manager at NGS Secure. His areas of expertise include network and application penetration testing, vulnerability research, black-box testing and source code review.( NGS Secure 의 General Manager .네트워크 어플리케이션 테스트 전문가)
• Emil Eifrem: Emil is the founder of the Neo4j graph database project and CEO of Neo Technology.( Neo4j graph database project 최초 설립자이자 Neo Technology의 CEO)

Questions:
1. NoSQL 데이터베이스 사용시 어플리케이션 개발자가 사전에 알아야 할 필요가 있는 모든 보안상 취악점 은 무었인가?
2. NoSQL 구현 종류에 따라(문서기반,그래프기반 등)어떤 보안상 취약점이 존재 하는가? (Connection Pollution, JSON Injection, Key Brute Force etc.).
3. 인증, 접근, 컨트롤, 암호화 각각 용어들에 해당하는 NoSQL측면의 현재 보안 상태는 무었인가?
4. NoSQL 데이터 베이스 안에 저장된 데이터를 접근하는 어플리케이션에 대해, 보안을 구축 하기위해 어떤 툴과 기술이 아키텍트와 디벨로퍼를 위해 이용 가능한가?
5. 보안적인 측면에서, 기존 RDBMS 와 비교하여 장점과 단점은 무엇인가?
6. NoSQL 데이터 베이스의 보안성 검증을 위한 노력은 일반적인 자동 정적 동적 코드 분석, 침투 테스트, 수동 보안 코드 리뷰를 포함한 기존의 DB, 애플리케이션 개발과 어떻게 다른가?
7.NoSQL 기반의 어플리케이션 설계와 개발 시 보안의 모범사례와 처리하기 까다로운(gotchas) 사례들은 무엇인가?
8.NoSQL 의 보안성 측면에서 신경향은 무엇인가?


InfoQ: NoSQL 데이터베이스 사용시 어플리케이션 개발자가 알아야 할 필요가 있는 모든 보안상 취약점 은 무엇인가?

BGU: 어플리케이션 개발자들이 NoSQL 데이터를 사용하여 저장할 때 사전에 알아둘 필요가 있는 보안성 취약점은 관계형데이터 베이스를 사용할 때와 동일하다: 부족하거나 잘못된 입력 검증, 어플리케이션 래벨 권한 핸들링 에러, 인증 취약, 보안되지 안은 통신, 비 암호화된 데이터에 대한 불법 접근, 등. 최근 대부분 웹 앞단의 소프웨어는 미들웨어를 사용하고, 어플리케이션 레밸 뒤에서 타입에 관계없이 효과적으로 데이터베이스를 숨긴다. 접근 권한은 데이터베이스 레벨에서는 거의 다루지 않는다. 일부 케이스 에서는, 보통 RDBMS는 커낵션 풀링을 사용하기 때문에, 하나의 커낵션에 의해 사용된 특정유저를 구분 할 수 없다. 일부 관계형 데이터 베이스의 ACID기능역시 concurrency를 높이기 위해 또는, 미들웨상의 수평확장을 위해 무시된다. 이런 의미에서, RDBMS와 NoSQL의 차이는 거의 구분할 수 없다.
위의 일반적인 진술에도 불구하고, 세가지 주요 보안 취약점을 정의하면 (NoSQL 데이터 저장 구조를 사용하는 어플리케이션 개발자들이 가리킬만한 ): 웹 어플리케이션과 데이터베이스간 안전하지 않은 연결, DBA와 같은 특별한 권한을 있는 유저들을 위한 부족한 지원, 불충분한 인증 으로 구분할 수 있다.

추가적으로, 취약점이 존재 하는데, NoSQL을 사용하여 데이터를 저장할 때 통합자나 설계자들이 알아야 할 필요가 있다. NoSQL 데이터 저장은 내부적으로 수평 확장능력이 있으며(clustering, sharding, replication) 노드 위장 공격에 취약한 데이터저장부분에 대해 새로운 공격 방법을 제공하게 되었다. 대부분의 클러스터 솔루션은 그와 같은 계산된 행동에 대한 철저한 (보안)메커니즘을 제공하지 않는다.
John: 많은 NoSQL 데이터 베이스들은 복잡한 절차 없이 동작하도록 설계 되었다, 즉 인스톨 이후 거의 또는 전혀 튜닝 작업이 없으며. 인증은 거의 요구되지 않는다. 이는 실험환경하의 새로운 제품에 대한 테스팅을 위해서는 적합하나, 제품으로 출시하기 전에 명확한 대응이 요구 된다. 더욱이 인젝션 공격은 불가능 하다는 오해가 있다. 많은 NoSQL 데이터 베이스는 NoSQL 저장소 안으로 직렬된 객체를 직접 저장하는 인터페이스를 제공하며, 만약 이러한 인터페이스가 사용자에게 직접적으로 노출이 될 경우 악용 될 소지가 있다.
Emil: 특효법은 존제하지 않으나, 데이터는 저장되고, 보호될 필요가 있게 될 것이다 ,일반적으로 데이터의 형상에 따라 취약점의 차이는 거의 없다.(데이터 형태에 가 보안과는 무관하다는 의미)

그러나, 데이터와 함께 동작 시, 그래프 스토어들은 이점을 가지며, 비즈니스 정보를 나타내기 위해 맵리듀스 또는 유사한 프레임웍을 수반하는 어떠한 것도 필요하지 안다. 추가적인 처리를 없이 데이터 베이스 자체가 많은 정보를 포함하고 있다. 그것이 의미하는 바는, 동등한 내용을 처리하기위한 데이타 이동부분이 훨씬 적으며, 따라서 하둡과 비교 할 때 공격대상 표면이 적게 노출 된다는 것이다.(데이터 이동양이 적어 공격 표면이 훨씬적게 노출된다는 의미)

그 말인즉, 데이터를 변화시키는 쓰기 쿼리가 가능 하기 때문에, 유의사항은 요구사항들을 처리하는 그 쿼리들로부터 사용자단 조회에 처리에 대해 주의해야 할 것이다.(쓰기 쿼리에 대해 주의해서 처리하라는 뜻으로 해석됨)
InfoQ: NoSQL 구현 종류에 따라(문서기반, 그래프기반 등)어떤 보안상 취약점이 존재 하는가 ?(Connection Pollution, JSON Injection, Key Brute Force etc.).
BGU: 수십개의 서로 다른 NOSQL 데이터베이스가 존재하지만, 두가지 타입의(문서,컬럼기반) NOSQL 종류를 조사했다. 문서기반 데이터베이스는 MongoDB 와 CouchDB가 있으며 이들인 서로 다른 보안이 필요하다. 따라서 데이타베이스 종류에 따라 보안의 취약점 분류는 간단하지 않다는 걸 알았다.

일반적으로, 일부 소프트웨어는 (“hello world”와 같은 단순한 프로그램을 포함하여) 복잡성이 증가함에 따라, 어플리케이션의 공격 표면은 복잡성과 함께 증가 한다. 네트웍 지향적인 성격의 소프트웨어는 연결 오염이나 중간자(프록시) 공격에 취약하다. 사용자로부터 입력이 있는 일부 소프트 웨어는 이용자로부터의 공격에 취약하다, STMP 소프트웨로(STMP 해더) 부터 RDBMS(SQL injection)또는 NoSQL의 JSON/BSON/JavaScript injection(응용소프트웨어계층의 프로토콜 해더부터 DBMS에 이르기까지) 속임수(조작) 공격들에 취약하다. 이러한 의미에서 데이터 접근 인터페이스가 존재하는 대부분의 NoSQL은 인젝션 공격에 노출 되어있다고 볼 수 있다.
Emil: 우리는(Neo4j graph database) 그러한 어떠한 것들에게도 취약하지 않다: 우리는 JSON 저장소가 아니며, 보안관련 기능이 추가된 이후 취약하지 않다.

그럼에도 불구하고, 그래프 스토어에 접근했다면, 애플리케이션이나 유저에게 도움되지 않는 방향으로 컨텐츠 오류를 유발 할 수 있다. (일반적으로 어렵더라도)만약 파일시스템에 접근 가능 할 경우, 그래프의 부분을 수정하는 것을 포함하여, 직접적인 데이터베이스를 오염시키는 것은 가능하다
InfoQ: 인증, 접근, 컨트롤, 암호화 각각 용어들에 해당하는 NoSQL측면의 현재 보안 상태는 무었인가?
BGU: NoSQL 측면에서, 인증, 권한부여, 암호화를 위한 표준은 없다. 일반적으로, 이러한 것이 필요하다는 이해는 존재하지만, 아직 여기에 대한 최선의 방법이라고 인정할만한 것은 없다. 현장에서 현재 모범 사례는 미들웨어단에 보안이 위치해 포함되었으며, 클러스터 레벨에서는 보안이 무시된다.

특히, 우리의 조사는, Cassandra MongoDB, CouchDB를 위한 권한부여와 인증에 중점을 었는데,카산드라는 두 개의 도구를 복잡한 절차 없이 IAuthenticate 인터페이스와 함깨 노출시킨다. AllowAllAuthenticator능 기본적으로 인증이 불가능하나 반면 SimpleAuthenticator은 패스워드를 평문 저장상테에 따라 평문 또는 순수MD5의 사용이 가능하다. SimpleAuthenticator는 아직 상품으로 준비되었다고 생각되지는 않는다.

2.0버전에 앞서 최근 출시된 몽고에서의 인증은 파편화(shard) 되지 않은 경우만 지원 되며 실제 큰 의미는 없다.

CouchDB는 복잡한 절차 없이 세가지 인증 핸들러를 제공한다: 기본 HTTP인증, 쿠키 기반 그리고 OAuth 프로토콜 기반의 인증.

카산드라에서 권한부여는 컬럼 패밀리 단위로 처리된다. 현재 접근권한셋은 읽기와 쓰기를 포함한다. 카산드라는 두가지 방법의 IAuthority 인터페이스를 제공한다. 첫번째는 방법은 유저와 관계없이 항상 모든 접근을 허락하는 방법 이고, 그리고 두번째는 일반 자바 프로퍼티 파일을 유저이름과 접근권한 메칭을 처리하기 위해 사용한다

몽고디비는 두가지 타입의 유저를 지원한다: 데이터베이스 알갱이단 레벨이세 읽기만 또는 읽기 쓰기를 지원한다. CouchDB는 데이터베이스 알겡이 레벨에서 매우 제한적인 버전의 롤기반 접근 컨트롤을 제공한다.

세 개의 데이터 베이스 모두 데이터는 암호화 되지 않는다. MongoDB 암호화는 클러스터간 네트웍 커뮤니케이션은 가능하나, 클라이언트와는 불가능 하다. couchDB SSL 은 1.1.0버전에서 지원되며 클라이언트와 클러스터간 둘 다 지원 가능 하다.
Emil: 원래 가능하지는 않지만, 이 서비스들은 Neo4j와 쉽게 통합이 가능하다. 액세스 컨트롤은 특히 어떤 애플리케이션에나 자연스러운 부가 기능이며, 또한 권한정보와 함께 엔티티에 대한 주석을 직접 남기는 것이 쉽기 때문이다. 일반적인 경우, 모든 ACL을 그래프 내에서 직접 도메인에 붙이고 인증 체크를 간단하게 만든다.
InfoQ: NoSQL 데이터 베이스 안에 저장된 데이터를 접근하는 그들 어플리케이션에 대해, 보안을 구축 하기위해 어떤 툴과 기술이 아키텍트와 디벨로퍼를 위해 이용 가능한가?
BGU: 관계형 데이터베이스를 위한 가상 개인 데이터 베이스와 같이 보안이 내장되어 제공하는 툴을 찾지 못했습니다. 그러나, 다음과 같이 정의 했습니다. NoSQL에서 새로운 네임스페이스를 쉽게 만든 다는 것이, 그러한 보안에 제공되어 사용되어질 수 있다고. 예를 들어 ,하나의 네임스페이스에는 읽기만 ,또다른 하나의 네임스페이스는 읽기쓰기는 읽기 쓰기를 사용하는 것이다. (네임스페이스 별로 기능을 분리하여 사용하는 것이 보안에 도움이 될 것이라는 의견으로 보임)

대부분 미들웨어 소프트웨어는 인증, 권한 그리고 접근컨트롤을 위한 지원을 포함한다. 자바에서는, JSSA프레임웍, 스프링보안 프레임웍, 아파치 Shiro 프레임웍, J2EE프레임웍, 또는 기타 다른 라이브러리를 사용할 것이다, 추가적으로, NoSQL클러스터안에서, 전송으로 HTTP를 활용하는 ,보안은 역시 프록시서버와 로드벨런서들 통해서 검증할 수 있습니다. NoSQL 데이터 베이스는 보안문제를 풀기 위해 알맞게 디자인된 어플리케이션이 할 수 있는 것 만큼 보안문제에 대처 할 수 있는 기능은 없습니다. 현재 모범 사례는 미들웨어에 보안을 위치시키는 것입니다.
Emil: 임베디드된 데이터베이스로 디플로이 될 때, 보안은 단지 어플리케이션의 일부이며, 따라서, 사내 표준과 부합하여 일관성을 지키기 위해 무엇이든 사용 될 수 있다.

서버 개발자들은 사내 표준과 일관성을 지키기위해 수직적으로 보안 수칙을 시행 할 수 있다.
InfoQ: NoSQL은 보안측면에서 RDBMS와 비교해 봤을 때 장점과 단점은 무엇인가?
BGU: 대부분의 어플리케이션 개발자들이 NoSQL을 사용시 보안 핸들링은 미들웨어에 위치 시키며, NoSQL은 데이터 베이스 내부에 어떠한 보안기능도 필수로 제공하지 않는다. 보안기능이 제공되지 않는다는 점은 관계형 모델에 비해 단점이다. 데이터 베이스에 보안 능력은 일반적으로 필수는 아니다. 내가 보았던 대부분 어플리케이션은 ,(데이터 베이스 안의 보안 레이어는 유틸화 되지 았았으며, 왜냐하면 개발자들은 커낵션 풀을 사용하길 원하기때문데, 그리고 이미연결이 성립된 이후 인증을 다시 사용하길 원하며), 보안을 지원하지 않는다.(오라클은 프록시 인증을 통해 지원된다). NoSQL 솔루션은 일반적으로 클러스터 지향적이며, 그리고 이것은 가용성과 스피드면에서 장점이 존재한다, 그러나 보안에 있어서는 단점이 된다. 문제는 클러스터링 측면에서 NoSQL DB가 충분히 강력하게 성숙되지 못했다는 것이다.

그러나, DBMS 직접 접근하거나 어플리케이션을 통하지 않을 때, RDBMS는 내장된 보안 수단을 이용함으로써 NoSQL에 비해 커다란 장점을 가진다.
John:NoSQL 데이터베이스는 RDBMS에 비해 일반적으로 복잡하지 않다. 복잡하지 않다는 것은 보안에 있어 장점이다. 대부분 RDBMS는 많은 수의 특징들과 더불어 공격자 권한을 상승시키거나 서버를 좀더 위험에 노출시키기 위해 확장된 기능을 사용 할 수 있다.
1)확장된 저장 프로시져 – 이들은 호스트의 파일시스템과 내트웍과 상호작용기능을 제공한다. 스스로 많은 위험이 존재하는 것 뿐만 아니라 (SQL 서버의 xp_cmdshell은 어드민 유저를 시스템 명령어를 수행하기위해 허락한다) 버퍼 오버플로우와 같은 많은 수의 보안 문제를 가지고 있다.
2) 정의 되어 동작하는 저장 프로시져들 – Oracle 과 SQL Server와 같은 RDBMS들은 서로 다른 사용자 권한아래 동작하기위해 표준 저장 SQL을 지원한다. 이것은 리눅스안의 어리석은 프로그램와 유사한 경우이다.저장 프로시져안의 많은 권한 확대 취약점을 가지고 있으며 SQL injection 취약점들로 인해 저장 프로시져안의 SQL injection 으로인해 많은 권한 상승 취약점이 존재한다.

NoSQL 솔루션의 단점중 하나는 Oracle(SQL Server, MySQL , DB2)과 같은 RDBMS와 비교되는 성숙기 이다. RDBMS , 다양한 보안이슈가 논의되어 왔음에도 불구하고, 다양한 타입의. 공격 루트가 수년동 많이 알려져 왔다. 그에 비해 NoSQL은 시작 초기 단계이다. 그리고 전반적으로 새로운 종류의 보안 이슈가 발견될 가능성이 있다.
Emil: 인증이나 권한부여를 지원하는것, 그래프 데이터베이스는 RDBMS/KV stores 보다 명확히 더상위의 기능을 가지고 있다, 왜냐하면 보안 정책들은 데이터와 연관 될 수 있기 때문이다. 유져들은 다양한 그룹에 속할 수 있으며, 다양한 시스템 레벨에 대한 개개인의 접근 권한을 가지고 있다. 통합적인 권한 계산은 LDAP과 같은 트리를 사용하더라도 어렵다. 그러나 그래프 에서는 수월하다.
InfoQ: NoSQL 데이터 베이스의 보안성 검증을 위한 노력은 일반적으로 자동화된 정적과 동적 코드 분석, 침투 테스트, 수동 보안 코드 리뷰를 포함한 기존의 DB, 애플리케이션 개발과 어떻게 다른가?
BGU: 어플리케이션 측면의 차이는 없다. 어플리케이션에게 모든 열린 포트와 제공된 입력은 체크가 필요하다. 차이점은 클러스터 환경 안에 있다. 클러스터 스스로 대표적인 공격들 혹은 다른 클러스터 레벨의 데이터 절도 공격에 대해 취약하지 않다는 것을 확실히 하기 위해서는 더욱 많은 작업이 필요하다.
John: NoSQL 데이터베이스는 상당히 새로운 기술들이다. 새로운 기술들은 여전히 취약점이 존재한다. 만약 당신이 전통적인 RDBMS의 보안을 보았다면, 그들은 매우 얼룩진 보안역사를 가지고 있다. 거의 모든 주요 RDBMS는 한지점에서 다른 지점으로 원격 코드를 실행하는 권한에 대한 심각한 이슈를 가지고 있다. 그 보안 취약의 비율은 일반적으로 감소 되는 동안, 오라클과 같은 일부 는 아직까지 정기적으로 심각한 이슈를 풀기 위해 업데이트 발표 한다

NoSQL 데이터베이스는 자체 보안기능이 일부 존재 하지만, Oracle 과 같은 레밸은 아니며, SQL 서버와 MySQL은 Oracle 과 비슷한 수준이다. Memcached 개발자들은, 예를 들어,임의의 코드실행을 가능하게 했던, 몇몇 정수 오버플로우 이슈를 2009년에 풀었었다. 나는 NoSQL데이타 베이스 안에 넓은 범의의 이슈가 존재 할 것이라 예상하며, 나는 향후 3년 안에 NoSQL 데이터베이스가 인기를 얻은 많큼 그리고 보안연구가들로부터 주목을 받은 많큼 넓은 범위의(많은) 이슈가 발견 될 것이라 예상한다. 대다수의 NoSQL 데이터베이스는 오픈소스 이고 , 그래서 그 코드는 다운로드 되고 분석 될 것이며 이는 이러한 이슈를 해결하는데 확실한 도움이 될 것이다.
Emil: Neo4j에서 그러한 용이함은 아직 없다.
InfoQ: NoSQL 기반의 어플리케이션 설계와 개발시 보안의 모범사례와 처리하기 까다로운(gotchas) 사례들은 무었인가?
John: 직접 NoSQL 형태로 직렬화 하거나 사용자의 입력을 받아 드리는 형태는 어플리케이션을 부주의하게 만들게 되어 “NoSQL injection”에 영향을 받기 쉬운 가능성이 있다. 이것을 피하기 위해서는 생성이나 변경을 위해 지름길을 사용하거나 항상 입력검증을 해야 하는 것 대신 권장되는 함수들이 호출되도록 개발자들은 보장 해야 한다.

MongoDB와 같은 NoSQL 데이터베이스는 복잡한 절차 없이 작업하기 위해 디자인 되었다. 그래서 개발자들은 매우 빠른 작업이 가능합니다. MongoDB 의 기본은 인증이 설정되지 않은 상태 입니다. 반면 이것은 어플리케이션 개발의 초기 상태에 속도를 높이기 위해는 장점 이지만, 이러한 인증 및 권한 부여와 같은 보안 문제가 상용화 이전에 잘 해결되어야 합니다. NoSQL 데이터베이스에 대한 접근 도 재고 되어야 합니다. 멤케시와 같은 (인증요구가 없는) 원격 접속 키벨류 스토어를 대신할만한것을 찾는건은 쉽다.
Emil: 데이터 베이스와 마찬가지로, 어플리케이션은 데이터의 직접적인 접근을 유저와 분리 해야 할것이다. 쿼리 표현으로부터 어떠한 사용자 단의 조회 요청을 데이터베이스형태로 흡수하거나 식별하는 것 노출시키는 것을 피하라
InfoQ: NoSQL 의 보안성 측면에서 새로운 트랜드는 무었인가?
BGU: NoSQL데이타 저장에 있어 보안은 개발자들 사이의 전문 블로그로부터 배울만큼 하나의 주요 관심사 이다. 이 블로그를 읽어보면 개발자들이 실제로 NoSQL데이터베이스 사용을 피한다는 것을 알 수 있다. 따라서 우리는 더 많은 개발자들이 NoSQL 커뮤니티에 합류한 것을 볼 수 있으며, 밴더들은 끊임없이 인증과 권한 같은 기본적인 요구사항을 위한 보안의 필요성을 인지하고 고유의 솔루션을 더 많은 공급을 시도한다.
John: 마이크로소프트는 윈도우와 Azure cloud 에 대한 최근 하둡 적용 의도를 발표했다. iSec Partners로부터 보안 연구가들은 2010년 Black Hat USA 보안 컨퍼런스에 하둡 디자인을 이미 발표 했었으나 마이크로소프트의 이 발표는 추가적인 관심을 모을 것 이다.
Emil: 지난 과거 에는, 기업은 데이터 베이스 접근하기 위해 보안이 적용된 통제된 접근을 해야만 했으나, 오늘날 데이터 스토리지는 퍼시스턴스 레이어를 도메인 기반으로 접근 가능하다. 인증과 접근을 위한 책임은 어플리케이션 래밸에 쌓여 이동 되어지져, 다단계로 관리되는 보안 보다는 단순화된 보안으로 접근 하는게 용이하다. 이러한 방법은 웹 어플리케이션의 RDBMS 접근 시 역시 마찬가지이다. 데이터베이스에 접근하기 위해선 일반적으로 하나의 어플리케이션 계정이 사용된다. 모든 사용자와 퍼미션은 어플리케이션에 따라 다르게 관리된다.

4가지 래벨의 리플리케이션 기술들

요즘 NoSQL부분을 살펴보는 중이라 관련된 데이터도 참고 하고 있는 중 리플리케이션의 정의에 대해 잘나와 있길래 번역 해보았습니다.좀예전꺼인거 같긴한데 개념은 잘잡혀 있네요.. 번역본이 잘이해안가시면 재목을 클릭하시면 원문으로 이동 합니다.번역이 세련되지 못하고 미비한점 양해부탁 드립니다.

4 levels of replication technologies

(http://blog.griddynamics.com/2010/02/4-levels-of-replication-technologies.html)

Replication 은, 퍼포먼스 향상, 장애복구, 백업, 등 다양한 목적으로 정보시스템에 폭넓게 사용 된다. 4가지 형태의 Replication 기술들이 이용 가능 하며, 어떠한 기술을 사용할지에 대한 결정은 복제하고자 시도중인 데이터의 논리적 표현에 달려 있다.

1. Storage-level replication
storage level에서, replication은 바이너리 데이터의 블록에 초점을 맞추고 있다. Replication은 block devices 혹은 file-system 레벨에서 수행될 것이다. 양쪽다, replication은 비정형 바이너리 데이터로 처리된다. storage-level replication의 기술적인 범위는 매우 넓으며, 상품형 레이드 어레이부터 NAS와 같은 네트워크 파일시스템까지 다양하다.

2. Database-level replication
보통 어플리케이션들은 파일을 직접 저장하지 않으며, 대신 Databases를 사용한다, Databases는 정형화 데이터를 기반으로 동작하며, Database-level replication 기술들 역시 정형화된 데이터를 처리한다(RDBMS를 위한 레코드들이나, 객체 형 데이터 베이스를 위한 객체).데이터베이스 replication을 위한 주요 기술은 두 가지가 존재 한다.

2.1 Record-based replication(Database-level)

데이터 베이스는 기능적 적합성을 위해 일부 식별 가능한 데이터조각을 활용한다.(데이터 베이스안의 레코드). 레코드 기반 replication 에서는, 각 시간별로(동일시간의미) 하나의 레코드가 정의 되며, 하나의 변경(a logical change record (LCR)) 이벤트는 싱크 상태를 유지하기 위해 replication 파트너에게 전달 된다.

2.2 Statement-based replication (Database-level)

일반적으로 하나의 Statement은 여러개의 레코드로 정리 될 수 있으며, 이와 같은 경우, 문Statement단위로 전달은 레코드단위로(all modified records) 전달할 때 보다는 replication partner에게 좀더 효율적으로 전달 가능하다. 이것이 statement-based 접근 이다.

모든 주류의 DBMS는 built-in 형태의 replication 을 제공한다. 때로는 replication 타입도 조차도.(레코드 또는 statement 기반) 데이터 베이스 컨트롤을 통해 가능하다. MySQL은 이러한 기능이 가능한 제품중의 하나이다.

3.Message-centric replication

흔히 replication 사용 목적은 데이터를 복제가 아니라, 어플리케이션 상태를 복제 이다. 예를 들어, statement-based replication 을 지원하는 데이터 베이스에서, 어플리케이션 상태가 변경될 때, 변경된 데이터를 복제하는 것 대신 비즈니스의 이벤트들의 흐름을 복제할 수 있다. 이벤트들의 동일한 처리는 같은 상태의 어플리케이션을 만든다 (적어도 동등한 상태의 비즈니스를)

Message-centric replication은 몇 가지 실용적인 이득이 있다. 첫째로, replication 은 항상 서로 다른 데이터베이스간 하나의 비즈니스 트랜잭션 단위로 수행된다. 둘째, replication 은 데이터베이스에서 데이터 구조와 관계없이, 지속적으로 데이터 스키마를 업데이트 할 때 매우 도움이 될 것이다 –스키마들의 차이는 replication 토플리지 안에서 공존 가능 하다.
Message-centric replication은 어플리케이션 로직과 강한 연관성이 있다. 이러한 종류의 replication 을 위한 일반적은 솔루션은 존재하지 않으나, 일반적으로 메시지 큐 미들웨어는 replication 파트너간 메시지 전송을 위해 사용 된다.

4.Application-state replication (grid technologies)
메모리 (프레젠테이션 안으로)부터 데이터베이스로 데이터 변경 (작업)은 매우 비효율적이며, 확실히 주요 병목구간이 될 가능성이 있다. Application-state replication은 어플리케이션 프로세스(그리고 서버)간 메모리 안의 데이터 스트럭처 복제가 이와 같은 문제가 발생된다. 이기술에는 두개로 나누어 분류 할수 있다.

4.1 In-memory data grid
In-memory data grids는 스토리지와 같은 샤드 메모리 서비스를 제공한다(모든 그리드 구성원은 동일한 엑세스가 가능하고 스토리지에대한 보기에 영향을 가지고 있다.) 그리드는 API를 제공 하는데, 샤드 스토리지를 잘 조작하기 위해 어플리케이션이 사용한다. 스토리지는 어플리케이션 래벨의 객채증을 저장하고 한다.(직렬화 형태 안에서) . 후드 아래에서(?), 그리드 미들웨어는 프로세스와 서버를 넘어 저장 컨텐츠에 해당 분산 및 replication 에 대해 책임이 존재한다.

4.2 Transparent application clustering

이러한 접근은 replication 의 디테일한 부분을 가능한 숨기며, 어플리케이션 변경 코드를 최소화를 시도한다. 전형적인 기술적 분류를 위해, 프로세스는 워크 프로세스와 (어플리케이션에서 동작하는) 매니지먼트 프로세스로 분리되어 있다. 가장 간단한 경우는, 이들 두 개의 프로세스가 하나로 합쳐질 수 있는 것이며, 매니지먼트 프로세스는 어떠한 어플리케이션 코드도 동작 하지 않는 것이다. 그들은 워크 프로세스들의 인스턴트 상태의 replication 을 통합한다. 이러한 파라다임을 사용중인 상품을 예로들면, 자바 런타임을 위한 클러스트링 구현, 그리고 GemStone – 스몰톡을 위한 클러스터된 런타임(추후에는 루비와 함깨 지원)이 있다.