'SW기술/IT기술동향'에 해당되는 글 7건

엘라스틱 서치(Elastic Search) 란?


아파치(Apache) 루신(Lucene) 을 기반으로 개발된 오픈소스 분산 검색 엔진이다.


<참고> Lucence은 자바로 개발된 오픈소스 정보검색 라이브러리이다. 

          위키피이아 설명 참조: https://en.wikipedia.org/wiki/Apache_Lucene



현재 SoundCloud, Github, Wikemedia 등에서 사용하여 있다.


엘라스틱서치의 특징은 확장성과 분산처리이다. 규모가 수평적으로 늘어나도록 설계되어 있기 때문에 필요할 때 노드를 추가하고 클러스트가 인식할 수있게 하여 확장할 수 있다.


그외 특징으로 

고가용성(High Availability), 멀티 태넌시(Multi-tenancy), 전문검색(Full text search), 문서중심( Documnet oriented), Schema Free, RESTFul API, Apache2 open source license 를 들 수 있다.



엘라스틱서치 공식 홈페이지: https://www.elastic.co/kr/

엘라스틱서치 SeungHyun Eom 발표자료:  https://www.slideshare.net/seunghyuneom/elastic-search-52724188




엘라스틱 서치(Elastic Search) 와 관계형데이터베이스의 용어 비교 


 엘라스틱서치

 관계형 데이터베이스

  Index

   Database 

  Type

   Table 

  Document

   Row

  Filed

   Column

  Mapping

   Schema

  Everyting is indexed

   Index

  Query DSL

   SQL


'SW기술 > IT기술동향' 카테고리의 다른 글

엘라스틱 서치(Elastic Search) 란  (0) 2017.12.28
링크  (0) 2017.09.25
[링크] 데브옵스(DevOps)란  (0) 2017.04.12
Git 사용자를 위한 Best Practices  (0) 2016.03.26
NoSQL  (0) 2012.10.24
빅데이터 와 빅데이터 기술  (0) 2012.10.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

링크

SW기술/IT기술동향 2017.09.25 13:32

https://drive.google.com/open?id=0B7YDoVA1Lq0-OE1WSWw3eDhaTU0

'SW기술 > IT기술동향' 카테고리의 다른 글

엘라스틱 서치(Elastic Search) 란  (0) 2017.12.28
링크  (0) 2017.09.25
[링크] 데브옵스(DevOps)란  (0) 2017.04.12
Git 사용자를 위한 Best Practices  (0) 2016.03.26
NoSQL  (0) 2012.10.24
빅데이터 와 빅데이터 기술  (0) 2012.10.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

[원본링크] https://aws.amazon.com/ko/devops/what-is-devops/

AWS에서 DevOps에 대해 잘 정리된 문서가 있어서 링크 걸어놨습니다.

종종 링크가 사라지는 경우가 있어서 원문까지 찾아 놨어요. 원문이 보기 편하니 원본링크를 클리해서 

데브옵스의 개념을 정리하면 좋을 것 같습니다.


[원문]

데브옵스는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합입니다. 

기존의 소프트웨어 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선할 수 있습니다. 

이러한 빠른 속도를 통해 조직은 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁할 수 있습니다.

데브옵스란 무엇입니까?

데브옵스 모델에서는 개발 팀과 운영 팀이 더 이상 "사일로"에 묶여 있지 않습니다. 때로는 이 두 팀이 단일 팀으로 병합되어 엔지니어가 개발에서 
테스트, 배포, 운영에 이르기까지 전체 애플리케이션 수명 주기에 걸쳐 작업하고 단일 기능에 한정되지 않은 광범위한 기술을 개발합니다. 
품질 보증 팀과 보안 팀 또한 애플리케이션 수명 주기에 걸쳐 개발 및 운영과 좀 더 긴밀하게 통합됩니다.

이러한 팀에서는 데브옵스 방식을 사용하여 속도가 느리고 수동으로 수행되던 프로세스를 자동화합니다. 또한, 애플리케이션을 안정적으로
빠르게 운영하고 개선하는 데 도움이 되는 기술 스택과 도구를 사용합니다. 이러한 도구 덕분에 엔지니어는 이전 같았으면 다른 팀의 도움이
필요했을 코드 배포 또는 인프라 프로비저닝과 같이 작업을 독립적으로 수행할 수 있으며, 따라서 팀의 작업 속도가 더욱 빨라집니다.

속도

작업 속도가 빨라지므로, 고객을 위해 더 빠르게 혁신하고, 시장 변화에 더 잘 적응하고, 좀 더 효율적으로 비즈니스 성과를 창출할 수 있습니다. 데브옵스 모델을 사용하면 개발자와 운영 팀이 이러한 성과를 실현할 수 있습니다. 예를 들어 마이크로 서비스와 지속적 전달을 사용하면 팀에서 서비스를 주도적으로 운영하여 업데이트를 좀 더 빠르게 릴리스할 수 있습니다.

신속한 제공

릴리스의 빈도와 속도를 개선하여 제품을 더 빠르게 혁신하고 향상할 수 있습니다. 새로운 기능의 릴리스와 버그 수정 속도가 빨라질수록 고객의 요구에 더 빠르게 대응하여 경쟁 우위를 강화할 수 있습니다. 지속적 통합과 지속적 전달은 빌드에서 배포까지 소프트웨어 릴리스 프로세스를 자동화하는 방식입니다.


DevOps-What-is_reliability

안정성

최종 사용자에게 지속적으로 긍정적인 경험을 제공하는 한편 더욱 빠르게 안정적으로 제공할 수 있도록, 애플리케이션 업데이트와 인프라 변경의 품질을 보장합니다. 지속적 통합 및 지속적 전달과 같은 방식을 사용하여 각 변경 사항이 제대로 작동하며 안전한지 테스트합니다. 모니터링과 로깅 방식을 통해 실시간으로 성능에 대한 정보를 얻을 수 있습니다.

DevOps-What-is_scale

규모에 따라 인프라와 개발 프로세스를 운영 및 관리합니다. 자동화와 일관성이 지원되므로 위험을 줄이면서 복잡한 시스템 또는 변화하는 시스템을 효율적으로 관리할 수 있습니다. 예를 들어 코드형 인프라를 사용하면 개발, 테스트 및 프로덕션 환경을 반복 가능하고 좀 더 효율적인 방식으로 관리할 수 있습니다.

DevOps-What-is_collaboration

주인 의식과 책임 같은 가치를 강조하는 데브옵스 문화 모델에서 좀 더 효과적인 팀을 구축합니다. 개발자와 운영 팀은 긴밀하게 협력하고, 많은 책임을 공유하며, 워크플로를 결합합니다. 이를 통해 비효율성을 줄이고 시간을 절약합니다(예: 개발자와 운영 팀 간에 인도 기간 단축, 실행되는 환경을 고려한 코드 작성 등).


DevOps-What-is_security

보안

제어를 유지하고 규정을 준수하면서 신속하게 진행할 수 있습니다. 자동화된 규정 준수 정책, 세분화된 제어 및 구성 관리 기술을 사용함으로써, 보안을 그대로 유지하면서 데브옵스 모델을 도입할 수 있습니다. 예를 들어 코드형 인프라와 코드형 정책을 사용하면 규모에 따라 규정 준수를 정의하고 추적할 수 있습니다.

소프트웨어와 인터넷은 쇼핑에서 엔터테인먼트 그리고 뱅킹에 이르기까지 전 세계와 산업을 변화시켰습니다. 이제 소프트웨어는 비즈니스를 지원하는 것에 그치지 않고, 비즈니스의 모든 부분에서 핵심적인 구성 요소가 되었습니다. 기업은 온라인 서비스 또는 애플리케이션으로 제공되는 소프트웨어를 통해 온갖 종류의 디바이스에서 고객과 상호 작용합니다. 또한, 소프트웨어를 사용하여 물류, 통신, 운영 등과 같은 가치 체인의 모든 부분을 혁신함으로써 운영 효율성을 향상합니다. 20세기에 실제 상품을 제조하는 기업이 산업 자동화를 통해 제품의 설계, 생산 및 전달 방법을 혁신한 것과 마찬가지로, 오늘날의 기업은 소프트웨어를 구축하고 제공하는 방법을 혁신해야 합니다.

데브옵스로 전환하기 위해서는 문화와 사고 방식의 변화가 필요합니다. 간단하게 말하자면 데브옵스는 기존에 사일로에 묶여 있던 개발과 운영이라는 두 팀 간의 장벽을 허무는 일입니다. 일부 조직에서는 개발 팀과 운영 팀이 나뉘어 있지 않고 엔지니어가 두 업무를 모두 수행할 수도 있습니다. 데브옵스에서는 두 팀이 함께 작업하여 개발자의 생산성과 운영의 안정성 모두를 최적화합니다. 두 팀은 자주 소통하고, 효율성을 높이고, 고객에게 제공하는 서비스의 품질을 향상하기 위해 최선을 다합니다. 최종 고객의 요구와 자신이 어떻게 이러한 요구를 해결하는 데 공헌할 수 있는지 생각함으로써 일반적으로 명시된 역할 또는 직책의 범위를 넘어 서비스에 대한 완전한 주인의식을 갖습니다. 품질 보증 및 보안 팀도 이 두 팀과 긴밀하게 통합될 수 있습니다. 데브옵스 모델을 사용하는 조직은 어떻게 구성되어 있든, 전체 개발 및 인프라 수명 주기를 스스로의 책임으로 간주하는 팀들로 구성됩니다.

조직이 소프트웨어 개발과 인프라 관리 프로세스의 자동화 및 간소화를 통해 더 빠르게 혁신할 수 있도록 지원하는 몇 가지 주요 방식이 있습니다. 이러한 방식 대부분은 적절한 도구를 사용해 수행됩니다.

기본 방식 중 하나는 소규모 업데이트를 자주 수행하는 것입니다. 이 방식을 통해 조직은 고객을 위해 더 빠르게 혁신할 수 있습니다. 이러한 업데이트는 기존 릴리스 방식에서 수행되는 낮은 빈도의 업데이트보다 일반적으로 좀 더 증분적인 특성을 갖습니다. 소규모로 자주 업데이트하면 각 배포의 위험이 줄어듭니다. 팀에서 오류의 원인이 되는 최근 배포를 확인할 수 있으므로 더 빠르게 버그를 해결할 수 있습니다. 업데이트 소요 시간과 규모는 다르지만, 데브옵스 모델을 사용하는 조직은 기존 소프트웨어 개발 방식을 사용하는 조직보다 훨씬 더 자주 업데이트를 배포합니다.

또한, 조직은 마이크로 서비스 아키텍처를 사용하여 애플리케이션의 유연성과 혁신의 속도를 높일 수 있습니다. 마이크로 서비스 아키텍처는 복잡한 대규모 시스템을 간단하고 독립적인 프로젝트로 결합 해제합니다. 애플리케이션은 많은 개별 구성 요소(서비스)로 분할되며, 각 서비스는 단일 목적 또는 기능으로 한정되고 피어 서비스 및 전체 애플리케이션과는 별개로 운영됩니다. 이 아키텍처는 애플리케이션 업데이트를 위한 조정 오버헤드를 줄이고, 각 서비스가 이를 담당하는 작고 민첩한 팀과 연결되면 조직이 좀 더 신속하게 움직일 수 있습니다.

하지만 마이크로 서비스와 릴리스 빈도 증가의 조합은 배포 수를 현저히 늘려 운영 문제로 이어질 수 있습니다. 따라서 지속적 통합 및 지속적 전달과 같은 데브옵스 방식을 사용하면, 이러한 문제를 해결하고 조직이 안전하고 안정적인 방식으로 신속하게 업데이트를 제공할 수 있습니다. 코드형 인프라 및 구성 관리와 같은 인프라 자동화 방식은 잦은 변경에 대해 컴퓨팅 리소스를 탄력적이고 대응적으로 유지하는 데 도움이 됩니다. 또한, 모니터링과 로깅의 사용도 엔지니어가 애플리케이션 및 인프라의 성능을 추적하여 문제에 신속하게 대응할 수 있게 하는 데 도움이 됩니다.

이러한 방식들을 함께 사용하면 조직이 더 빠르고 더 안정적으로 고객에게 업데이트를 제공할 수 있습니다. 다음은 주요 데브옵스 방식의 개요입니다.


지속적 통합

지속적 통합은 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 소프트웨어 개발 방식입니다. 지속적 통합의 핵심 목표는 버그를 신속하게 찾아 해결하고, 소프트웨어 품질을 개선하고, 새로운 소프트웨어 업데이트를 검증 및 릴리스하는 데 걸리는 시간을 단축하는 것입니다.

지속적 통합에 대해 자세히 알아보기 »


지속적 전달

지속적 전달은 코드 변경이 프로덕션에 릴리스할 수 있도록 자동으로 빌드, 테스트 및 준비되는 소프트웨어 개발 방식입니다. 빌드 단계 이후의 모든 코드 변경 사항을 테스트 환경 및/또는 프로덕션 환경에 배포함으로써 지속적 통합을 확장합니다. 지속적 전달이 적절하게 구현되면, 개발자는 언제나 즉시 배포할 수 있고 표준화된 테스트 프로세스를 통과한 빌드 아티팩트를 보유하게 됩니다.

지속적 전달과 AWS CodePipeline에 대해 자세히 알아보기 »


마이크로 서비스

마이크로 서비스 아키텍처는 단일 애플리케이션을 작은 서비스의 집합으로 구축하는 설계 접근 방식입니다. 각 서비스는 자체 프로세스에서 실행되고, 주로 HTTP 기반 API(애플리케이션 프로그래밍 인터페이스)라는 간편한 메커니즘을 사용하는 잘 정의된 인터페이스를 통해 다른 서비스와 통신합니다. 마이크로 서비스는 비즈니스 기능을 중심으로 구축되며, 각 서비스는 단일 목적으로 한정되어 있습니다. 다양한 프레임워크 또는 프로그래밍 언어를 사용하여 마이크로 서비스를 작성하고, 이를 독립적으로 단일 서비스 또는 서비스 그룹으로 배포할 수 있습니다.

Amazon EC2 Container Service에 대해 자세히 알아보기 »

AWS Lambda에 대해 자세히 알아보기 »


코드형 인프라

코드형 인프라는 버전 관리 및 지속적 통합과 같은 코드와 소프트웨어 개발 기술을 사용하여 인프라를 프로비저닝하고 관리하는 방식입니다. 클라우드의 API 중심 모델을 사용하면 개발자와 시스템 관리자가 수동으로 리소스를 설정 및 구성할 필요 없이 프로그래밍 방식으로 대규모로 인프라와 상호 작용할 수 있습니다. 따라서 엔지니어는 코드 기반 도구를 사용하여 인프라와 인터페이스하고, 애플리케이션 코드를 다루는 방법과 유사한 방식으로 인프라를 다룰 수 있습니다. 인프라가 코드를 통해 정의되므로, 인프라와 서버를 표준화된 패턴을 사용하여 배포하고, 최신 패치와 버전으로 업데이트하거나, 반복 가능한 방식으로 복제할 수 있습니다.

AWS CloudFormation으로 코드형 인프라를 관리하는 방법 알아보기 »

개발자와 시스템 관리자는 코드를 사용하여 운영 체제를 자동화하고 구성, 운영 작업 등을 호스팅합니다. 코드를 사용함으로써 구성 변경을 반복하고 표준화할 수 있습니다. 이에 따라 개발자와 시스템 관리자가 운영 체제, 시스템 애플리케이션 또는 서버 소프트웨어를 수동으로 구성할 필요가 없어집니다.

AWS OpsWorks로 구성을 관리하는 방법 알아보기 »

인프라와 인프라의 구성이 클라우드로 체계화된 조직은 규정 준수를 규모에 따라 동적으로 모니터링하고 적용할 수 있습니다. 따라서 코드를 통해 설명된 인프라는 자동화된 방식으로 추적, 검증 및 재구성할 수 있습니다. 이는 조직이 손쉽게 리소스 변경을 관리하고 보안 조치가 분산 방식으로 적절하게 적용될 수 있게 해줍니다(예: PCI-DSS 또는 HIPAA 규정 준수나 정보 보안). 규정 위반 리소스가 추가 조사를 할 수 있도록 자동으로 플래그가 지정되거나 규정 준수 상태로 자동으로 변경될 수 있으므로 이를 통해 조직 내 팀은 더 빠르게 움직일 수 있습니다.

AWS Config과 Config Rules를 사용하여 인프라에 대한 규정 준수를 모니터링하고 적용하는 방법 알아보기 » 


모니터링 및 로깅

조직은 지표와 로그를 모니터링하여 애플리케이션 및 인프라 성능이 제품의 최종 사용자 경험에 어떤 영향을 미치는지 확인합니다. 조직은 애플리케이션과 인프라에서 생성되는 데이터 및 로그를 캡처하고 분류한 다음 이를 분석함으로써, 변경 또는 업데이트가 사용자에게 어떤 영향을 주는지 이해하고, 문제의 근본 원인 또는 예상치 못한 변경에 대한 통찰력을 확보합니다. 서비스는 연중무휴 24시간 사용할 수 있어야 하고 애플리케이션 및 인프라 업데이트 빈도가 증가함에 따라 적극적인 모니터링이 점점 더 중요해지고 있습니다. 이러한 데이터에 대한 실시간 분석을 수행하거나 알림을 생성하는 것도 조직이 좀 더 능동적으로 서비스를 모니터링하는 데 도움이 됩니다.

Amazon CloudWatch를 사용하여 인프라 지표 및 로그를 모니터링하는 방법 알아보기 »

AWS CloudTrail을 사용하여 AWS API 호출을 기록하고 로깅하는 방법 알아보기 »


커뮤니케이션 및 협업

조직에서 커뮤니케이션과 협업이 증가하는 것도 데브옵스의 주요 문화적 측면 중 하나입니다. 데브옵스 도구 및 소프트웨어 제공 프로세스 자동화를 사용하면 개발 및 운영의 워크플로와 책임을 물리적으로 합침으로써 협업이 이루어집니다. 해당 팀에서는 이 위에 채팅 애플리케이션, 문제 또는 프로젝트 추적 시스템, wiki를 사용하여 커뮤니케이션을 지원하고 정보를 공유하는 강력한 문화적 표준을 확립합니다. 이를 통해 개발자와 운영 그리고 마케팅이나 영업과 같은 다른 팀 간에도 커뮤니케이션이 활발해지면서 조직의 모든 부분에서 목표와 프로젝트에 좀 더 가깝게 다가갈 수 있습니다.

데브옵스 모델이 팀에서 고객을 위해 신속하고 안정적으로 배포하고 혁신하도록 지원하려면 효과적인 도구가 필요합니다. 이러한 도구는 수동 작업을 자동화하고, 팀이 규모에 따라 복잡한 환경을 관리하도록 지원하며, 엔지니어가 데브옵스에서 지원하는 빠른 속도를 관리할 수 있도록 해줍니다. AWS에서는 데브옵스용으로 설계되고 AWS 클라우드에서 사용하도록 구축된 서비스를 제공합니다. 이러한 서비스는 위에 설명된 데브옵스 방식을 사용하는 데 도움이 됩니다.

AWS 데브옵스 서비스에 대해 알아보기 »

AWS 파트너 솔루션에 대해 알아보기 »


'SW기술 > IT기술동향' 카테고리의 다른 글

엘라스틱 서치(Elastic Search) 란  (0) 2017.12.28
링크  (0) 2017.09.25
[링크] 데브옵스(DevOps)란  (0) 2017.04.12
Git 사용자를 위한 Best Practices  (0) 2016.03.26
NoSQL  (0) 2012.10.24
빅데이터 와 빅데이터 기술  (0) 2012.10.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹


[참고 사이트]



1. git - 간편안내서

   https://rogerdudler.github.io/git-guide/index.ko.html


2. 완전 초보를 위한 깃허브

   https://nolboo.github.io/blog/2013/10/06/github-for-beginner/


3. Git 시작하기

   https://git-scm.com/book/ko/v1/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0


4. Git 과 GitHub 사용하기

   http://kr.discovermeteor.com/chapters/github/


5. Visualized Git practices for team: branch, merge, rebase

   http://kentnguyen.com/development/visualized-git-practices-for-team/


6. Git for beginners: The definitive practicalguide

http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide


7. Best Prctice - The Git Development Cycle

   http://ariejan.net/2009/06/08/best-practice-the-git-development-cycle










'SW기술 > IT기술동향' 카테고리의 다른 글

링크  (0) 2017.09.25
[링크] 데브옵스(DevOps)란  (0) 2017.04.12
Git 사용자를 위한 Best Practices  (0) 2016.03.26
NoSQL  (0) 2012.10.24
빅데이터 와 빅데이터 기술  (0) 2012.10.24
클라우드 컴퓨팅  (0) 2012.10.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

NoSQL

SW기술/IT기술동향 2012.10.24 20:51

페이스북이나 트위터와 같은 데이터 조각을 다루는 웹사이트들 그리고 읽기 만큼이나 쓰는 소셜 웹 서비스 데이터 증가로 인해 백엔드 플랫폼 기술의 변화가 요구되고 있다.  대부분 빠른 데이터 접근을 위한 분산 데이터 스토어와 메모리 캐시 같은 방법들이다. 과거의 MVC기반의 백엔드와 확연하게 다르다. 


즉 읽기만큼이나 쓰기가 많아지면서 실제 업데이트 되는 데이터들이 늘어나면서 NoSQL이라 불리는 분산형 데이터 스토어들이 각광 받기 시작했다.


페이스북과 트위터에서 사용하기 시작해서 인기가 높은 카산드라와 Hadoop기반의 HBase와 같은 분산형 데이터 스토어가 오픈소스로 배포되며 소셜 웹 기반 서비스에서 많이 사용되고 있다. 또한 RDB와 중간사이에 CouchDB와 MongoDB같은 것도 있다.


=========================================================================================================


NoSQL 자료를 검색하다 잘 정리된 자료가 있어서 주인장에게 물어보지 않고 그냥 업어왔다.

출처: http://blog.outsider.ne.kr/519 , http://blog.outsider.ne.kr/520 

새로운 자료가 정리되면 곧 내리겠음 ㅠㅠ


웹이 점점 커지고 다양한 요구가 생겨나는 가운데 NoSQL이 커다란 이슈중에 하나로 떠오르고 있습니다. 제가 NoSQL에 대해서 처음 들은 것은 올 초정도로 기억하고 있습니다.

Google Trends에서 NoSQL로 검색한 결과

구글 트랜즈 에서 확인해보아도 NoSQL이라는 단어가 이슈화되기 시작한 것은 2009년 중순정도로 나타나고 있습니다.  위키피디아 에서 확인해 보면 NoSQL이라는 단어는 1998년 Carlo Strozzi이 SQL을 드러내지 않는 경량 데이터베이스로 이름지었고 2009년 초에 Last.fm 의 Johan Oskarsson이 오픈소스 분산데이터베이스에 대한 논의를 위한 이벤트를 원했을 때 Rackspace 의 직원인 Eric Evans가 NoSQL이라는 단어를 다시 소개했다고 합니다. 아틀란타에서 열린 no:sql conference 2009가 NoSQL논의에 큰 영향을 미쳤다고 합니다. (이 컨퍼런스의 모토인 "select fun, profit from real_world where relational=false;"가 상당히 센스넘치는군요)

올해 중에 NoSQL중 하나는 경험해 보자는 생각이었는데 마침 좀 만져볼 기회가 생겨서 좀 만져보고 있습니다. 개념자체가 개발자에게 기존에 익숙한 RDBMS와는 너무 달라서 튜토리얼 보고 단순한 사용정도는 할 수 있겠지만 관련해서 고민해 보려면 NoSQL에 대해서 좀 자세히 알아야 할 필요가 있게 느껴졌습니다. 사실 NoSQL에 대한 지식이 많다보니 고민 자체가 해결책이나 진도나 나가지 않고 계속 빙글빙글 도는 느낌이라 여기저기 자료를 좀 찾아서 정리해 보았습니다.





CAP Theorem
NoSQL에 대해서 이해하려면 먼저 CAP 이론에 대해서 알 필요가 있습니다. CAP이론은 Brewer's CAP Theorem 으로 알려져 있는데 분산 컴퓨팅 시스템에서 보장해야 하는 특징으로 아래 3가지를 정의하고 있습니다.

  • Consistency (일관성) : 모든 노드들은 동시에 같은 데이터를 보아야 합니다.
  • Availability (유효성) : 모든 노드는 항상 읽기와 쓰기를 할 수 있어야 합니다.
  • Partition Tolerance (파티션 허용차) : 시스템은 물리적인 네트워크 파티션을 넘어서도 잘 동작하여야 합니다

CAP 이론에 따르면 위 3가지 중에 동시에 2가지만 보장할수 있고 3개를 모두 보장하는 것이 불가능하다고 나와있습니다. 그래서 데이터를 관리할때 이 3가지 중에 어느 2가지에 중점을 두냐는 것은 아주 중요한 부분입니다. 이 부분을 이해하는데 Nathan Hurst 이 만든 아래의  Visual Guide to NoSQL Systems 는 큰 도움이 됩니다.

사용자 삽입 이미지

기존에 많이 사용하던 RDBMS는 3가지 중 CA에 집중하고 있습니다. 웹이 발전하면서 다양한 요구사항이 생겨나고 엄청난 양의 데이터를 처리해야 하게 되면서 RDBMS가 갖지 못한 P의 특성이 필요해졌고 그러면서 등장한 것이 NoSQL입니다. 좀더 풀어쓰면 데이터베이스에 대한 수평적 확장(Horizontal Scalability 즉 옆에 서버한대 더 배치해서 데이터베이스를 늘리고 싶다는 의미입니다.)에 대한 이슈가 발생했고 확장성이슈를 해결하기 위해서 P를 선택하다 보니 기존에 가지고 있던 C나 A의 특성중 하나를 포기해야 했습니다. 그래서 NoSQL에는 다양한 시도들이 있지만 가장 중요한 이슈는 확장성을 해결하려는 것으로 생각됩니다.

관계형 데이터베이스는 기본적으로 분산형을 고려해서 디자인 되지 않았습니다. 그래서 ACID(원자성, 일관성, 독립성, 지속성) 트랜잭션 같은 추상화와 고레벨 쿼리모델을 풍부하게 제공할 수 있지만 확장성이 좋지 못하기 때문에 모든 NoSQL 데이터베이스는 다양한 방법으로 확장성 이슈를 해결하기 위해 초점을 맞추고 있습니다. 각 NoSQL에는 여러가지 차이점들이 있지만 CAP의 범주에서만 보면 CP를 선택하거나 AP를 선택하게 됩니다.




왜 비관계형이어야 하는가?
NoSQL이 확장성 이슈를 해결하려고 CP나 AP의 특성을 선택했지만 구체적으로 어떤 특징을 선택하고 왜 그래야 했는지 이해할 필요가 있습니다. NoSQL은 많은 제품군들이 있는데 모두 같은 전략으로 접근하고 있지는 않고 각각에 제품에 따라 다양한 접근을 하고 있는데 아래 적힌 내용들은 비관계형으로 가기 위한 여러가지 특성들에 대한 이야기이고 제품군에 따라 아래의 특성들을 선택한 여부는 다른 것으로 보입니다.아래의 내용은 상당부분 VINEET GUPTA가 작성한 NoSql Databases - Part 1 - Landscape 를 참고하였습니다. 잘 정리된 문서라서 참고하시면 도움이 될 것입니다.



관계형 데이터 베이스는 확장하기가 어렵습니다.

Replication - 복제에 의한 확장
Master-Slave 구조에서는 결과를 슬레이브의 갯수만큼 복제해야 하는데 N개의 슬레이브에서 읽을 수 있기 때문에 Read는 빠르지만 Write에서는 병목현상이 발생하게 기 때문에 확장성에 대한 제한을 가지게 됩니다.
다중 마스터구조에서는 마스터를 추가함으로써 쓰기의 성능을 향상시킬 수 있는데 대신에 충돌이 발생할 가능성이 생기게 됩니다.

Partitioning(Sharding) - 분할에 의한 확장
Read만큼 Write도 확장할 수 있지만 애플리케이션레이어에서 파티션된 것을 인지하고 있어야 합니다.RDBMS의 가치는 관계에 있다고 할 수 있는데 파티션을 하면 이 관계가 깨져버리고 각 파티션된 조각간에 조인을 할 수 없기 때문에 관계에 대한 부분은 애플리케이션 레이어에서 책임져야 합니다. 일반적으로  RDBMS에서 수동  Sharding 은 쉽지 않습니다.



필요없는 특성들

UPDATE와 DELETE
Update와 Delete는 전통적으로 정보의 손실이 발생하기 때문에 잘 사용되지 않으며 후에 데이터 검사 및 재활성화를 위해서 기록해둘 필요가 있습니다. 그리고 사용자가 커뮤니티를 탈퇴한다고 그들의 글을 지우지 않듯이 도메인 관점에서는 실제로 삭제되지 않습니다.  이런 접근을 하게 되면 Update / Delete를 모두 Insert로 모델할수 있고 과거 데이터는 버전을 붙혀서 기록할 수 있으며 이 데이터들은 비활성데이터들이 됩니다. 이 INSET-only 시스템에서는 2개의 문제가 있는데 데이터베이스에서 종속(cascade)에 대한 트리거를 이용할 수 없으며 Query가 비활성 데이터를 걸러내야 할 필요가 있습니다.

JOIN
데이터가 많을 때 JOIN은 많은 양의 데이터에 복잡한 연산을 수행해야 하기 때문에 비용이 많이 들며 파티션을 넘어서는 동작되지 않기 때문에 피해야 합니다. 정규화는 일관된 데이터를 가지기 쉽게 하고 스토리지의 양을 줄이기 위해서 하는건데 반정규화(De-normalization)를 하면 JOIN문제를 피할 수 있습니다. 반정규화로 일관성에 대한 책임을 디비에서 애플리케이션으로 이동시킬수 있는데 이는 INSERT-only라면 어렵지 않습니다.

ACID 트랜젝션
Atomic (원자성) : 여러 레코드를 수정할 때 원자성은 필요없으며 단일키 원자성이면 충분합니다.
Consistency (일관성) : 대부분의 시스템은 C보다는 P나 A를 필요로 하기 때문에 엄격한 일관성을 가질 필요는 없고 대신 결과의 일관성(Eventually Consistent )을 가질 수 있습니다.
Isolation (격리성) : 읽기에 최선을 다하는(Read-Committe) 것 이상의 격리성은 필요하지 않으며 단일키 원자성이 더 쉽습니다.
Durability (지속성) : 각 노드가 실패했을때도 이용되기 위해서는 메모리가 데이터를 충분히 보관할 수 있을정도로 저렴해지는 시점까지는 지속성이 필요합니다.

고정된 스키마
RDBMS에서는 데이터를 사용하기 전에 스키마를 정의해야하고 Index등을 정의해야 하는데 현재의 웹환경에서는 빠르게 새로운 피쳐를 추가하고 이미 존재하는 피쳐를 조정하기 위해서는 스키마 수정이 필수적으로 요구됩니다. 하지만 컬럼의 추가/수정/삭제는 row에 lock을 걸고 index의 수정은 테이블에 락을 걸기 때문에 스키마 수정이 어렵습니다.



어떤 특성들은 갖지 않습니다.
계층화 데이터나 그래프를 모델하는 것은 어렵습니다. 또한 빠른 응답을 위해서 디스크를 피하고 메인 메모리에서 데이터를 제공하는 것이 바람직한데 대부분의 관계형 데이터베이스는 디스크기반이기 때문에 쿼리들이 디스크에서 수행됩니다.





기대하는 특성들
NoSQL이 바라는 환경은 서버들이 다른 용량들을 가지고 수업이 퍼져나가는 것으로 이를 노드라고 부릅니다. 

높은 확장성
점진적으로 노드를 추가할 수 있어야 하고 이는 파티셔닝을 통해서 가능합니다. 

높은 Availability
실패의 단일포인트가 없으며 데이터는 복제되기 때문에 어떤 노드가 죽었을때도 데이터는 이용이 가능합니다.

높은 성능
디스크대신 메모리 기반으로 결과는 빠르게 리턴되어야 하며 이는 논블락킹 Write와 낮은 복잡성을 가진 알고리즘을 통해서 이룰수 있습니다.

원자성
각각의 쓰기는 원자성을 가질 필요가 있다.

일관성
강한 일관정은 필요없고 결과적인 일관성만 가지면 된다.(Read-Your-Writes1 일관성)

지속성
데이터는 휘말성 메모리만이 아닌 디스크에서 유지되어야 합니다.

배포의 유연함(Flexibility)
노드의 추가/삭제는 데이터를 분산하고 수동으로 중재할 필요없이 자동적으로 로드되어야 하며 분산 파일 시스템이나 공유스토리지 요구같은 제약이나 특수한 하드웨어같은 것이 필요없어야 합니다. 이기종간의 하드웨어에서 동작가능해야 합니다.

모델링의 유연함(Flexibility)
Key-Value쌍, 계층형 데이터, 그래프등 여러가지 타입의 데이터를 간단하게 모델할 수 있어야 합니다.

쿼리의 유연함(Flexibility)
하나의 호출에서 제공된 키에 대한 값이 묶음을 얻는 다중 GET과 키의 특정 범위에 기반한 데이터를 얻는 범위 쿼리가 필요합니다.



CAP 이론
Consistent - Available : Postgres, MySQL같은 전통적인 RBMS
Consistent - Partition Tolerant : BitTable , Hypertable , HBase , MongoDB , Terrastore , Redis , Scalaris , MemcacheDB , BerkeleyDB 
Available - Partition Tolerant : Amazon Dynamo , Cassandra , CouchDB , Amazon SimpleDB ,Riak 



분산형과 비분산형 
분산형 : Amazon Dynamo, Amazon S3, Scalaris, Voldemort, CouchDB, Riak, MongoDB, BigTable, Cassandra, HyperTable, HBase
비분산형 : Redis, Tokyo Tyrant, MemcacheDB, Amazon SimpleDB

분산형 데이터베이스는 확장성을 위한 Data Partitioning과 Availability를 위한 복제에 대한 책임을 가지고 있고 비 분산형은 클라이언트가 이 책임들을 가지고 있습니다. 주목할만한 분산모델은 Dynamo에서 사용되었지만 Voldemort, Riak, Cassandra에서 이 모델을 카피해서 사용하고 있으며 이질적인 하드웨어간에도 효과적입니다.



데이터 모델의 풍부함(Richness)
Key-Value Store : Amazon Dynamo, Amazon S3, Redis, Scalaris, Voldemort
Document Store :
 Amazon SimpleDB, Apache CouchDB, MongoDB, Riak
Column Store : 
Scssandra, Google BigTable, HBase, Hypertable

이 분류에서 한쪽 끝은 Key-Value Store이고 반대쪽은 가장 부유한 Column Store입니다. 이 두 사이에는 관계형데이터베이스의 사촌정도가 되는 Document Store가 위치하고 있고 Key-Value보다는 풍부하고 이해하기가 쉽습니다.


Disk와 Memory
Memory : Scalaris, Redis
Configurable :
 BigTable, Cassandra, HBase, HyperTable
Disk : CouchDB, MongoDB, Riak, Voldemort

Scalaris는 완전한 메모리 기반이고 Redis는 메모리주도적입니다. Configurable에 분류에 포함된 데이터베이스들은 많은 컨트롤을 제공하기 위해 얼마나 큰 메모리를 얻을 것인지를 설정할 수 있으며 Disk의 범주에 있는 CouchDB, MongoDB, Riak은 on-disk B+ Tree를 사용하며 Voldemort는 BDB와 MySQL을 사용하고 있습니다.






데이터 모델의 방식에 따라 주요한  NoSQL위주로 특징들을 정리했습니다.

Key-Value Store
Key-Value Store는 가장 간단하게 가능한 데이터 모델을 제공합니다. 범위쿼리는 데이터베이스에서 명백하게 지원하지 않는다면 쉽지 않습니다. 그리고 Key-Value Store상에서의 애플리케이션 모델링은 복잡성을 가질 수 있습니다.

Amazon Dynamo 

  • 분산형 Key-Value Store로 값이 시스템에 불투명합니다. 타겟 오브젝트는 보통 1MB 미만으로 Amazon내부에서 사용되고 있고 외부에서는 직접 이용할 수 없습니다.
  • 일관성 해싱을 사용해서 Partitioning을 합니다.
  • 복제 - 데이터는 다중호스트에 복제됩니다.
  • 일관성 - 업데이트는 비동기적으로 복제는 전파하기 때문에 모델은 결국 일관성을 가집니다.



Amazon S3 

  • 분산형 Key-Object Store로 오브젝트는 시스템에 불투명합니다. 각 오브젝트의 사이즈는 1byte ~ 5GB의 범위내에 있으며 오브젝트의 갯수는 제한이 없는 무제한 스토리지 입니다. 오브젝트는 Amazon 데이터센터 내에서 유지가 되며 오브젝트의 위치에 대한 GEO를 결정하며 저장되는 오브젝트가 크면 유용합니다.
  • 일관성 : 새로운 PUT에서 Read Your Write1를 이루고 PUT과 DELETE를 덮어써서 결과적인 일관성을 가집니다.





Document Store
Document Store는 Key-Value Store보다 한걸음 더 나아간 구조입니다. 스키마가 테이블의 형태보다 먼저 정의되어야 하는 관계형 데이터베이스와는 달라서 각 도큐먼트는 다른 스키마를 가질 수 있습니다. 그러면서도 관계형 데이터베이스처럼 레코드간의 관계를 설명하는 것이 가능합니다. 이 먼저 정의해야하는 스키마를 제외하고는 개념적으로 관계형 데이터베이스와 아주 유사합니다.

Amazon SimpleDB 

  • Erlang으로 작성되었습니다.
  • 데이터는 관계된 데이터를 함께 보관하기 위한 컨테이너로써의 도메인과 도메인으로 연결하기 위한 엔티티, 아이템의 프로퍼티로써 속성과 그 값으로 모델되었습니다.
  • 기본적으로 각 아이템은 속성을 언제나 추가/삭제 가능한 Dictionary입니다.
  • 아이템이 추가될 때 속성에 기반하여 인덱스됩니다.
  • 결과적인 일관성을 갖습니다.
  • 파티셔닝 : 도메인 - 아이템 - 어트리뷰트 모델은 각 도메인의 사이즈와 도메딩당 속성의 갯수 및 도메인의 갯수에 대한 제한을 갖는다. 그러므로 확장을 위해서는 데이터를 수동으로 파티션해야 합니다.



Apache CouchDB 

  • Erlang로 작성되었습니다.
  • 데이터와 스토리지 모델 :
    • 레코드는 JSON스트링(도큐먼트)의 형식으로 직렬화됩며 각 도큐먼트는 유니크한 DocId를 같습니다.
    • B+트리 를 사용하면 커밋된 데이터는 결코 덮어써지지 않고 오직 오퍼레이션만 추가합니다.
    • Append only 모델로 Read가 다중버전의 동시성 제어를 사용해서 수행됩니다.
      쓰기는 동시에 작성가능한 Blob외에는 직렬화됩니다.
    • 같은 데이터를 위한 다중 뷰를 가질 수 있습니다.
    • Design Document라고 부르는 도큐먼트의 특별한 타입에서 갑에 키를 매핑하는 Javascript함수를 사용하도록 정의되었습니다.
  • View함수는 View를 쿼리했을 때 실행되며 기본적으로 Map 함수와 Reduce 함수가 존재합니다.
  • 복제 : 다중마스터를 지원하는 마스터 슬레이브를 갖으며 오직 최신 리비전만 복제가 됩니다.
  • 멀티마스터에서의 충돌(Conflict) 핸들링 : 충돌을 탐지하고 winner를 선택하기 위해 결정론적인 알고리즘을 사용하며 여기서 winner는 기대한 것일수도 아닐 수도 있기 때문에 아닐 경우에는 애플리케이션에서 스스로 고쳐야 합니다.
  • Partitioning과 로드 밸런싱 - CouchDB Lounge 에 의해서 제공됩니다.
  • Apache 2.0 라이센스를 따릅니다.



MongoDB 

  • C++로 작성되었습니다.
  • 데이터 모델
    • 컬렉션 - Amazon SimpleDB의 도메인과 유사하며 비슷한 도큐먼트들을 함께 두기 위한 Bucket입니다.
    • Key-Value는 바이너리 직렬화된 JSON(BSON - Binary Serialized JSON )입니다.
    • 한 BSON 객체는 4MB 제한이 있습니다.
    • 큰 객체는 GridFS 를 통해 지원하고 있습니다.
    • 인덱스를 위해서 B-Tree가 사용되며 필드를 파라미터로 받는 db.things.ensureIndex()함수를 사용해서 인덱스에서 필드를 열거합니다.
  • 스토리지
    • in-Place 업데이트입니다.
    • 부분적인 업데이트를 제공하기 때문에 전체 로우를 보내지 않고 값을 업데이트 할 수 있습니다.
    • Forward-only 커서를 지원합니다.
    • 단일 도큐먼트 원자적 업데이트를 지원합니다. 원자적인 배치 업데이트는 db.eval()을 통해서 가능하지만 파티션된 데이터는 지원안할 수도 있습니다.
  • 쿼리
    • 도큐먼트 내부에서 값을 선택하기 위한 Syntax기반의 JSON 스타일을 제공합니다.
    • 상황적인 Operator와 정규식 등을 지원합니다.
    • Forward-only 커서를 지원합니다.
    • 쿼리 옵티마이징은 다중 쿼리플랜을 시도하고 가장 잘 동작하는 것을 선택하는 형식입니다.
  • 배치 오퍼레이션 : 컬렉션에 Map-Reduce를 지원합니다.
  • 복제 : 마스터-슬레이브 보델로 자동적으로 마스터와 슬레이브의 역할을 이해하는 복제쌍(replica pair)입니다.
  • Partitioning
    • 알파스테이지에서 파티셔닝 됩니다.
    • 파편(Shards)는 Chunk라고 불리는 유닛에서 데이터를 다루며 Chunk는 최대 50MB의 컬렉션으루부터 인접하는 범위의 데이터입니다.
    • 데이터는 하나의 Shard에서 Chunk안의 다른 Shard로 마이그레이션 됩니다.
  • AGPL 3.0 라이센스를 따릅니다.





Column Store

BigTable 

  • 구글에서 내부적으로 사용하면 Google App Engine를 통해서 공개됩니다.
    Block를 짓습니다.
    • Google File System 를 사용하여 분산 파일시스템과 Raw 스토리지를 제공합니다. 청크서버가 청크를 저장할 책임을 가지고 있으며 각 청크는 안전을 위해 3개의 머신에 복제가 됩니다. 데이터전송은 클라이언트와 청크서버 사이에서 직접 발생합니다.
    • 스토리지 파일 포맷은 정렬된 스트링 테이블로 SSTable로 불립니다.
    • 스케쥴러는 메선에서 스케쥴 잡으로 제공됩니다.
    • 분산된 Lock과 파일, 네임 매니저로 Chubby 서비스 를 사용한다.

  • 데이터 모델은 Map의 Map인 다차원 Map입니다. 데이터는 테이블로 조직화되고 테이블은 관계된 데이터를 가진 엔티티입니다.
  • Write : Write 요청이 타블렛 서버에 도달했을 때 잘 규격화 되었는지와 권한을 확인하며 유효한 변경은 커밋로그에 작성됩니다.
  • Read : Write요청과 비슷한 확인을 하며 SSTable의 순서와 Memtable의 합쳐진 View에서 실행됩니다.



Cassandra 

  • BigTable의 컬럼패밀리(Column-family) 데이터 모델과 Dynamo의 분산 아키텍쳐를 합쳤습니다.
  • Java로 작성되었습니다.
  • 데이터 모델
    • BigTable같은 키에 의해 인덱스되는 다차원 맵을 사용하며 각 애클리케이션은 BigTable에서 테이블같은 Key-Space를 만듭니다. Key는 레코드를 위한 이름이고 Column은 레코드의 속성이며 타임스템프가 찍힙니다. Column-family는 컴럼의 그룹핑으로 관계형 테이블과 유사하고 Super-Column은 컬림들의 리스트입니다.
    • 소팅은 데이터의 쓰여진 시간으로 정렬되되며 컬럼들은 컬럼의 이름으로 Row내에서 정렬됩니다.
  • Partitioning : Dynamo와 유사하며 순서가 보장된 햄쉬함수를 사용하는 일관된 해시를 사용하고 Dynamo와는 다른 로드밸런싱을 위해소 Chord  접근을 사용합니다.
  • 복제 : Dynamo의 조정자 노트와 선호리스트의 건셉과 같으며 Datacenter aware Rack aware, Rack unaware같은 다양한 보제 정책들을 가지고 있습니다.
  • 퍼시스턴스 : 로컬파일 시스템에 의지하며 스토리지 구조와 접근방식은 BigTable과 유사합니다.
  • Write : Memtable에 대한 업데이트를 따르는 내구성과 복구를 위한 커밋로그를 쓰는 Bigtable의 접근과 유사하며 커밋로그를 위한 각 머신의 전용디스크는 Write를 순차적으로 만들어 쓰루풋을 최대화 합니다.
  • Read : 제공될 노드와 Read-repair를 찾는 Dynamo와 유사한 접근방식을 사용하며 스토리지 레벨에서의 접근은 BigTable과 유사한 Memtable + SSTable 시퀀스로부터 읽습니다.
    라이센스는 Apache 2를 따릅니다.




'SW기술 > IT기술동향' 카테고리의 다른 글

링크  (0) 2017.09.25
[링크] 데브옵스(DevOps)란  (0) 2017.04.12
Git 사용자를 위한 Best Practices  (0) 2016.03.26
NoSQL  (0) 2012.10.24
빅데이터 와 빅데이터 기술  (0) 2012.10.24
클라우드 컴퓨팅  (0) 2012.10.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹


빅데이터란?


말그대로 큰 데이터의 집합체를 의미한다. 하지만 기존에 수집하지 않았던 데이터가 지금은 각종 SNS을 통해 다양한 데이터로 기록되어 지면서 등장한 단어이다.


이러한 다량의 데이터는 기업에서 기존의 분석도구와 관리체계로는 처리를 할 수 없는 데이터들이라는것이 가장 큰 문제이다.


이러한 빅데이터가 생겨난 이유에는 페이북을 비롯한 현실과 가상이 공존하게 되면서 다양한 데이터가 입력이 발생하게 되고 이런 다량의 데이터를 처리할 수 있는 분석 도구나 관리체계가 갖추어져 있지 이러한 데이터를 활용도 못해보고 폐가되는 일들이 많아 졌다. 


이러한 빅데이터를 사전에 처리할 수 있도록 데이터의 가치를 추출하고 결과를 분석하는 기술로 다양한 종류의 대규모 데이터의 생성, 수집, 분서그, 처리를 말하는것으로 다변화된 현대 사회를 더욱 정확하게 예측하여 효율적으로 작동을 하도록 하여 개인화도니 현대 사회 구성원마다 맞춤형 정보를 제공,관리, 분석하는 기술로 

빅데이터를 주목하게 되었다.



빅데이터 기술?


빅데이터기술은 크게 빅데이터 저장기술, 빅데이터 정제기술, 빅데이터 분석/가시화기술, 빅데이터 기반 예측 기술로 나눌 수 있다.


빅데이터 저장 기술은 이미 구글이나 애플, 야후등에 의해 요소기술로서 상당한 완성도에 도달했다. 공개소스로 Hadoop의 HDFS/BBSE, CassanDRA, mongoDB 등이 유명하다. 우리나라 ETRI의 GloryFS등과 같은 많은 솔루션이 존재한다.


빅데이터 정제기술은 빅데이터 자체가 워낙 크기 때문에 원시 데이터를 정제하기 낳고는 사용하기가 어렵다. 기계나 사람이 쏟아내는 데이터는 컴퓨터에 의해 바로 분석이 어렵기 때문이다.  즉 빅데이터의 대부분은 컴퓨터가 바로 처리할 수 없는 데이터, 컴퓨터 입장에서 보면 잘 정돈되지 않은 데이터이다. 이것을 비정형데이터(Unstructured data, Irregular Formatted Data)라고 한다.  이러한 비정형데이터를 분석,가공 가능한 형태로 만들거나 컴퓨터가 바로 처리할 수 없는 데이터를 포함한 정형적데이터를 분석 가공 가능한 형태로 만드는데 방대한 컴퓨팅 능력이 요구된다.  다시말해 정재기술은 "사람이나 기계가 만들어낸 현상을 멍청한 컴퓨터가 이해 할 수 있게 가공 하는것" 이다.


빅데이터 분석/가시화 기술은 대부분 통계학이나 데이터 마이닝이나, OLAP(Online Anaytical Processing)분야의 일이다.  빅데이터의 분석기술은 구글이 제시한 Map-Reduce 프로그래밍 모델이 보급되면서 "유의미한 시간에 대규모 데이터 정제/분석"이 가능해졌다. Map-Reduce는 빅데이터를 나누어 저장하고 있는 수백, 수천대의 서버 각각에서 자기가 저장하고 있는 데이터에 대한 정제/분석을 할 수 있는대로 해서 그 결과값을 모아 최종 정제/분석결과를 내는 방법이다.  




빅데이터기반 예측기술은 모델 단순화나 샘플링 기반의 통계적 예측에 의존하지 않고 고도의 수학적 기반과 전문성을 요구하고 있으며,  네트워크 이론아니 신경망 이론에 가깝다고 볼 수 있다. 수학적 기호나 표상을 사용하는 모델링 자체가 없는 경우도 많고 SVD(Singular Value Decomposition)나 LSA(Latent Semantic Anaysis)처럼 왜 되는지는 모르지만 자꾸 돌리면 잘 맞게되는 경우가 많다.  즉 이말은 누가 빨리 시작해서 많이 해봤느냐가 중요하고 관련기술이나 솔루션도 거의 없다.





'SW기술 > IT기술동향' 카테고리의 다른 글

링크  (0) 2017.09.25
[링크] 데브옵스(DevOps)란  (0) 2017.04.12
Git 사용자를 위한 Best Practices  (0) 2016.03.26
NoSQL  (0) 2012.10.24
빅데이터 와 빅데이터 기술  (0) 2012.10.24
클라우드 컴퓨팅  (0) 2012.10.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

                             


클라우드 컴퓨팅(cloud computing)은 인터넷 기반(cloud)의 컴퓨팅(computing) 기술을 의미한다. 인터넷 상의 유틸리티 데이터 서버에 프로그램을 두고 그때 그때 컴퓨터나 휴대폰 등에 불러와서 사용하는 웹에 기반한 소프트웨어 서비스이다.


역사

클라우드 컴퓨팅의 개념은 1965년 미국의 컴퓨터 학자인 존 매카시가 "컴퓨팅 환경은 공공 시설을 쓰는 것과도 같을 것" 이라는 개념을 제시한데에서 유래하였다. 1993년부터는 이미 클라우드라는 용어가 거대한 규모의 ATM을 지칭하는 데 쓰였다. General Magic라는 회사는 1995년 3월부터 AT&T와 다른 여러 통신사들과 제휴를 맺고 클라우드 컴퓨팅을 서비스를 최초로 시작했다. 하지만 이 시기는 소비자 중심의 웹 기반이 형성되기 전의 일이었기 때문에 클라우드 컴퓨팅 사업은 당연히 실패했다. 그러나 10년이 지난 2005년에서야 클라우드 컴퓨팅이라는 단어가 널리 퍼지기 시작했다. 하지만 2005년 당시에만해도 클라우드 컴퓨팅의 대부분의 내용들은 SaaS에 집중되어 있었다. 2007년까지는 SaaS에 집중되어 있었지만 2008년부터는 더이상 SaaS에만 집중되어있지 않다.


[편집]장점

  • 초기 구입 비용과 비용 지출이 적으며 휴대성이 높다.
  • 컴퓨터 가용율이 높다. 이러한 높은 가용율은 그린 IT 전략과도 일치한다.
  • 다양한 기기를 단말기로 사용하는 것이 가능하며 서비스를 통한 일치된 사용자 환경을 구현할 수 있다.
  • 사용자의 데이터를 신뢰성 높은 서버에 보관함으로써 안전하게 보관 할 수 있다.
  • 전문적인 하드웨어에 대한 지식 없이 쉽게 사용 가능하다.


[편집]단점

  • 서버가 공격당하면 개인정보가 유출될 수 있다.
  • 재해에 서버의 데이터가 손상되면, 미리 백업하지 않은 정보는 되살리지 못하는 경우도 있다.
  • 사용자가 원하는 애플리케이션을 설치하는 데에 제약이 심하거나 새로운 애플리케이션을 지원하지 않는다.
  • 통신환경이 열악하면 서비스받기 힘들다.


[편집]공용 클라우드와 사설 클라우드

공용 클라우드(Public cloud)는 아마존 웹 서비스와 같은 외부 서비스 제공자가 관리하며, 인터넷을 통해 접근하기도 하며, 일반적인 공적업무를 위해 이용된다.


사설 클라우드(Private cloud)는 네트워크 소유자나 데이터 센터에서 가상화의 서비스와 같이 서버, 저장, 네트워크 데이터 그리고 애플리케이션 함께 묶어 둔다. 그래서 회사 내부의 이용자들이 공유할 수 있도록 하는 것이다. 공용 클라우드와 달리, 사설 클라우드는 데이터 저장과 컴퓨팅 전력을 할당할 수 있고, 또 다른 자원을 균일하게 제공할 수 있다. 재무제표와 헬스케어 제공자들은 사설 클라우드를 더 많이 이용하는데 그 이유는 민감한 재무적 자료와 개인적 데이터를 조정해야 하기 때문이다.


From. 위키백과



'SW기술 > IT기술동향' 카테고리의 다른 글

링크  (0) 2017.09.25
[링크] 데브옵스(DevOps)란  (0) 2017.04.12
Git 사용자를 위한 Best Practices  (0) 2016.03.26
NoSQL  (0) 2012.10.24
빅데이터 와 빅데이터 기술  (0) 2012.10.24
클라우드 컴퓨팅  (0) 2012.10.24
블로그 이미지

오픈이지 제로킴

시큐어코딩 교육/컨설팅 전문가 그룹

티스토리 툴바