Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

데이터베이스

"아는 만큼 빨라진다" 마이SQL 성능 튜닝 팁 10가지

마이SQL은 세계에서 가장 광범위하게 사용되는 오픈소스 데이터베이스이며, 전체 데이터베이스의 인기 순위에서는 (근소한 차이로) 2위에 올라 있다. 마이SQL은 효과적인 관계형 데이터베이스 관리 시스템으로 오랫동안 인기 있는 애플리케이션의 중심에 위치해왔다. 그러나 사용하기가 까다로울 수 있고 성능을 개선할 수 있는 여지도 많다. 지난 몇 년 동안 몇 가지 중요한 개발도 이뤄졌다. 여기서는 바론 슈와르츠가 쓴 마이SQL 성능 튜닝 팁의 업데이트 내용을 다룬다.      마이SQL 성능 팁 1. 스키마 설계는 다른 어떤 마이SQL 설정 못지않게 중요  스키마 설계는 데이터베이스에 해야 하는 매우 중요한 일 중 하나다. 교차 관계형 데이터베이스 기술 원칙은 1970년대에 표준형이 나왔다. 마이SQL은 버전 5.6에서 기본 스토리지 엔진을 이노DB(InnoDB)로 전환했으므로 스키마 설계는 더욱 중요해졌다.  이유가 무엇일까? 이노DB에서는 모든 것이 기본 키(primary key)다. 이는 이노DB가 데이터를 정리하는 방식과 관련된다. 이노DB에서 기본 키는 군집화되고 모든 보조 키(secondary key)는 기본 키에 엔트리 포인터를 추가한다. 스키마 설계에서 이 부분을 감안하지 않으면 성능 측면에서 불이익을 받게 된다. 데이터는 B-트리 인덱스를 사용해서 저장되므로 데이터를 순서가 정해진 방식으로(즉, 유사 순차 값) 삽입하면 기본 키의 단편화가 방지되고 따라서 리프 노드를 찾는 데 필요한 I/O 작업이 감소한다.  순차 기본 키가 맞지 않는 경우도 있다. 대표적인 예가 범용 고유 식별자(Universally Unique IDentifier), 줄여서 UUID다. UUID와 기본 키에 대한 더 심층적인 내용은 여기서 볼 수 있다. 대부분 경우에는 순차 기본 키를 사용하는 것이 좋다.    마이SQL 성능 팁 2. 보조 키를 적대시하지 말 것  보조 키는 백그라운드 프로세스에...

mysql 마이SQL 성능 튜닝 2022.11.29

알리바바 앤트그룹, AWS 마켓플레이스에 오픈소스 DB 오션베이스 등록

알리바바의 계열사 앤트 그룹은 도달 범위를 늘리기 위해 AWS 마켓플레이스에 관계형 데이터베이스인 오션베이스(OceanBase)를 등록했다고 밝혔다.    앤트 그룹은 자사의 데이터베이스 서비스를 전 세계 고객들이 이용할 수 있도록 하기 위한 노력으로 목요일에 자사의 오션베이스 클라우드를 AWS 마켓플레이스에 상장했다고 발표했다. 분산 SQL 호환 데이터베이스를 사용하면 AWS 고객이 더 빨리 액세스하고 트랜잭션 및 운영 워크로드를 해결할 수 있다고 회사 측은 밝혔다. 오션베이스는 2017년에 공식 출시됐다. 오라클을 대체하고 알리바바의 금융 서비스 부문인 알리페이의 방대한 트랜잭션 워크로드를 지원하기 위해 2010년 한 프로젝트로 시작했다. 이 데이터베이스는 분석을 위해 나중에 다른 시스템에 복사된 데이터를 수집하는 아키텍처 접근 방식인 하이브리드 트랜잭션 분석 처리(HTAP)를 지원한다. 지난 8월에는 오션베이스 4.0을 발표했다. 복구 시간은 30초에서 8초로 대폭 줄였으며, 데이터 손실률 제로 등의 기능을 제공해 중소기업에 적합하다. 오션베이스는 또한 다른 퍼블릭 클라우드 서비스 제공업체를 곧 지원할 예정이다.  오션베이스의 퍼블릭 클라우드 서비스 부문 총괄 매니저 잉은 보도 자료에서 "클라우드 중립적인 오션베이스는 데이터 집약적인 트랜잭션과 여러 실시간 분석 워크로드를 관리하는 데 있어 오랜 기간 검증된 기능에 대한 액세스를 확대하기 위해 클라우드 공급업체와 계속 협력할 것"이라고 말했다. AWS 마켓플레이스에 오션베이스를 올린 앤트 그룹의 전략은 아파치 도리스와 스타록스 같은 다른 중국 기반 데이터베이스가 북미와 유럽 시장을 공략하는 추세를 따른다. ciokr@idg.co.kr

데이터베이스 관계형 데이터베이스 관계형데이터베이스 2022.10.17

"디지털 퍼스트 시대, 효과적인 데이터 활용 전략은?" 한국IDG, 비즈니스 임팩트 & 데이터 플러스 2022 성료

28일 한국IDG가 '디지털 퍼스트 시대의 데이터 활용 전략'을 주제로 비즈니스 임팩트 & 데이터 플러스 2022(Business Impact & Data + 2022) 컨퍼런스를 온라인으로 개최했다. 이번 행사에서는 전 세계 다양한 기업의 기술 트렌드와 적용 사례를 살펴보고, 국내 기업에서 성공적으로 활용할 수 있는 전략이 소개됐다.   코로나19로 디지털 트랜스포메이션이 가속화되면서 많은 기업이 디지털 우선 접근 방식에 투자하고 있다. IDC는 다양한 산업에 걸쳐 더 많은 데이터를 확보하고 활용하려는 수요가 커질 것으로 전망했다. 이른바 '디지털 퍼스트(digital first)' 시대다.  프루덴셜 파이낸셜(Prudential Financial)의 데이터 품질 디렉터 로라 세바스찬 콜먼은 '디지털 시대의 데이터 리더십'을 주제로 오프닝 기조연설을 시작했다. 콜먼은 많은 기업이 디지털 우선 접근 방식에 투자하고 있으나 단순히 기술만 우선하는 경우가 많다며, 데이터 우선 접근 방식을 채택해야 한다고 지적했다. 데이터는 고객 만족과 신뢰 구축에 중추적인 역할을 한다.  콜먼에 따르면, 데이터 품질 문제로 인한 기업의 손실은 최대 30%로 추산된다. 이런 손실을 최소화하기 위한 방법은 무엇일까? 콜먼은 "디지털로 전환하려면 사고방식의 변화가 필요하듯 고품질 데이터 생성도 마찬가지다. 데이터의 중요성을 인식하고 데이터 생산 프로세스와 라이프 사이클 전반에 걸쳐 적절한 책임을 설정해야 한다. 기업의 의지와 리더십, 데이터를 최우선으로 하는 용기가 필요하다"라고 조언했다.   전문가 세션에서는 본격적으로 기술 트렌드와 활용 전략이 소개됐다. 가장 먼저 EDB 코리아 이강일 지사장은 오픈소스 DBMS 시장 지형을 살폈다. 그에 따르면, 현재 오픈소스 DBMS는 클라우드와 함께 빠르게 성장하며 기존의 상용 DBMS를 대체하고 있다. 특히 비즈니스에 필수적인 OLTP/OLAP에는 오픈소스 DB가 크게 자리 잡았다...

데이터베이스 한국IDG 데이터분석 2022.09.28

"클라우드 쓴다고 해도" DB 설계가 여전히 개발자에 중요한 이유

오늘날 소프트웨어 개발자에게는 많은 선택지가 존재한다. 다양한 툴과 서비스를 활용해 새로운 애플리케이션을 빠르게 만들어 전 세계 고객에게 서비스를 출시하고 이후 확장해서 늘어난 수요에 대응할 수 있다. 마이크로서비스 아키텍처와 애자일 개발은 고객 요구와 비즈니스 요구를 충족해야 할 때 기민하게 움직이면서 새로운 서비스를 가동할 수 있도록 한다.   데이터도 마찬가지다. 개발자는 자신의 애플리케이션에서 생성하는 데이터를 지원해야 하는데, 이는 곧 데이터베이스 구현을 의미한다. 데이터베이스 설계를 적절히 선택하느냐가 애플리케이션에서 큰 차이로 이어질 수 있다. 적절한 설계는 장기적으로 애플리케이션이 가용성과 성능, 확장성을 갖추도록 하는 데 도움이 된다. 그러나 개발자는 데이터베이스를 직접 구현하고 관리하기를 원하지는 않는다. 대다수 기업이 (IDC에 따르면 90%) 현재 데이터베이스와 데이터 워크로드를 클라우드로 옮기는 것도 이 때문이다. 이때 기업은 여러 옵션 중에서 선택할 수 있다. 관리형 서비스, 클라우드 기반 데이터베이스 설치, 서비스형 데이터베이스(DBaaS) 등이 포함된다. 이들 서비스를 제공하는 업체들은 하나 같이 데이터 관리 부담을 덜어주고 새로운 애플리케이션과 업데이트를 더 빠르게 제공해 개발자가 원하는 것을 누릴 수 있다고 주장한다. “스키마리스”, “완전 관리형”과 같은 홍보 문구를 보면 데이터베이스를 그냥 넘겨주면 될 것처럼 안일함에 빠질 정도다. 그러나 클라우드 기반 데이터베이스의 설계와 구현 방법의 선택 측면에서도 개발자의 책임은 전통적인 온프레미스 시스템에 대한 것과 다르지 않다. DBaaS 제품의 기본 설정이 자신의 애플리케이션에 맞을 것이라고 무작정 단정하지 말아야 할 책임도 포함된다.   적절한 데이터베이스 선택하기 따라서 개발자와 애플리케이션 설계자는 애플리케이션 프로젝트의 장기적인 미래를 내다보고 이러한 프로젝트가 갖게 될 기본적인 요구사항을 확실히 파악해야 한다. 가장 먼저 판단해야 할 것은 프로젝...

데이터베이스 2022.07.29

누구나 접근 가능한 클라우드 취약점 데이터베이스, 웹사이트로 공개

클라우드 보안 회사 위즈(Wiz)가 최근 발표한 커뮤니티 기반 웹사이트(cloudvulndb.org) 일반인이 접근할 수 있는 중앙 집중화된 클라우드 취약점 데이터베이스를 제공한다. 이 데이터베이스는 마이터(MITRE)의 CVE 취약점 시스템과 현행 클라우드 보안 문제 책임 분담 모델의 단점을 메우고는 있지만, 전문가들은 성공하려면 추가적이고 폭넓은 업계 차원의 지원이 필요하다고 입을 모은다. 위즈는 현행 시스템에서 놓치기 쉬운 클라우드 취약점의 탐지 및 관리 작업을 간소화하기 위해 계속 노력 중이며 새로운 취약점 데이터베이스 역시 그 같은 노력의 연장 선상에 있다. 예를 들어, 책임 분담 모델에서는 클라우드 서비스 제공업체(CSP)와 사용자가 보안 활동을 분담한다. 즉, CSP는 하드웨어 및 관리 서비스를 포함한 물리적인 보안을 담당하고 사용자는 소프트웨어, ID, 데이터 보호를 책임진다. 그러나 클라우드 취약점 데이터베이스의 필요성을 역설한 위즈 블로그에 따르면, 이 모델은 어느 한 쪽 범주에도 완전히 들어맞지 않는 최신 버그를 해결하기에는 부족하다.     위즈 측은 중앙 취약점 데이터베이스가 CSP 보안 문제의 목록 작성에 도움이 되고 CSP 고객이 각자의 환경에서 문제 탐지 또는 방지를 위해 취할 정확한 조치를 제시할 수 있다고 밝혔다. 위즈 위협 연구원이자 블로그 공동 저자인 아미타이 코헨은 “이 데이터베이스는 오랜 노력의 첫 걸음이다. 우리는 이 웹사이트의 커뮤니티적인 면에 주력하고 있다. 이런 종류의 웹사이트는 사상 최초이며 앞으로 더 많은 기여와 관리자를 추가할 것으로 기대한다. 또한, API나 RSS 피드를 추가하여 타 시스템과 연계하는 등 웹사이트에 더 많은 기능을 추가할 계획이 있다”라고 밝혔다. 보안 애널리스트 등 여러 전문가는 우려를 인식하고 무엇보다 CVE(공통 취약점 및 노출) 시스템의 대안을 요구해 왔다.   CVE 시스템이 클라우드 보안에 부족한 이유 TAG 사이버(TAG Cyber) ...

취약점 데이터베이스 클라우드취약점 2022.07.12

클라우드플레어, 분산 데이터베이스로 톱3 클라우드에 도전

클라우드플레어가 자사의 서버리스 애플리케이션 플랫폼인 워커스(Workers)와 R2 오브젝트 스토리지 서비스를 기반으로 새로운 서버리스 데이터베이스 D1을 출시했다. 클라우드플레이어는 D1 분산 데이터베이스가 클라우드플레어의 엣지에 배치되어 다른 데이터베이스보다 지연도 적고 데이터 전송 비용도 절감할 수 있다고 주장한다.   D1은 사용자의 데이터베이스나 특정 애플리케이션이 구동되는 곳과 가까운 곳에 데이터를 저장해 지연을 줄인다. 컨스텔레이션 리서치의 대표 애널리스트 홀거 뮬러는 “서버리스 데이터베이스를 구축하는 이런 접근법은 데이터가 기능이 실행되는 곳으로 다시 전송되는 AWS 람다의 방식과 극명하게 대조된다”라며, “현재 시장에는 D1과 비교할 만한 서비스가 없지만, 다른 클라우드 서비스 업체도 각사만의 방식으로 D1에 대응할 것으로 보인다”고 말했다. 클라우드플레어 D1의 또 다른 장점은 SQLite API 통합이다. SQLite는 오라클의 MySQL DBMS와 호환된다. 뮬러는 “D1이 SQLite를 지원하기 때문에 개발자는 별도의 학습없이 애플리케이션을 구축할 수 있어 즉각적인 도입이 가능하다”고 평가했다. D1은 이외에도 다른 데이터베이스 서비스 업체로부터 데이터를 가져올 수 있고, 자사의 워커스 플랫폼과 통합되어 있어 풀스택 애플리케이션을 한층 더 쉽게 구축할 수 있다. 또한 클라우드플레어는 데이터 전송 요금을 부과하지 않을 것이라고 밝혔다. 즉 개발자는 부담없이 서비스 간에 데이터를 이전할 수 있다. 이번 발표는 클라우드플레어가 CDN과 DDoS 방어를 넘어 자사의 영역을 확장하기 위한 전략의 일환으로 평가된다. IDC의 리서치 담당 부사장 가산 아브도는 “D1은 클라우드플레어가 CDN을 넘어 인근 시장으로 확장해 전반적인 영역을 확대하려는 전략을 가속화할 수 있다”고 말했다.  컨스텔레이션의 뮬러에 따르면, 클라우드플레어의 최종 목표는 네트워크와 스토리를 포함해 포괄적인 서비스를 갖춘 애플리케이션 플랫폼이 되는 것...

클라우드플레어 서버리스 데이터베이스 2022.05.17

“데이터베이스 주류가 바뀐다” 오픈소스 DBMS 선택 가이드 - Tech Insight

오늘날 기업이 선택할 수 있는 DBMS는 상용 제품부터 오픈소스까지 매우 다양하다. 수백 종의 제품이 시장에서 치열하게 경쟁하고 있다. 그러나 지난 10여 년간 DBMS 시장의 뚜렷한 변화를 꼽는다면 단연 오픈소스의 부상이다. 최근에는 높은 신뢰성과 성능이 필요한 업무에도 오픈소스 DBMS가 속속 도입되고 있다. DBMS 시장의 변화를 살펴 보고 성능과 안정성 등에서 좋은 평가를 받는 대표적인 오픈소스 DBMS '포스트그레SQL'의 장단점을 분석한다. 기업이 오픈소스 DBMS를 선택할 때 가장 중요하게 확인해야 할 사항을 알아보고, 유통, 공공, 금융 등 다양한 업종의 도입 사례를 통해 실무자가 바로 참고할 수 있는 실질적인 비교 기준을 제시한다. 주요 내용 - “느리지만 확실하게” 데이터베이스는 세대교체 중 - “아는 만큼 더 잘 쓴다” 포스트그레SQL의 특징과 장점 - 오픈소스 DBMS 선택 시 핵심 체크리스트 6가지  

오픈소스 DBMS 데이터베이스 2022.05.11

“클라우드 시대 데이터베이스 관리의 해법은 DBaaS” 클라우드 환경의 데이터베이스 운영 실전 가이드 - Tech Dossier

데이터의 폭증과 함께 데이터베이스 환경도 다양화되고 있다. 많은 기업이 데이터베이스 운영을 위한 IT 인프라 구축 전략으로 하이브리드 클라우드를 내세우고 있으며, 데이터베이스 운영을 위한 DBMS 역시 전통적인 엔터프라이즈 DBMS 외에 오픈소스 기반의 다양한 데이터베이스가 기업 환경으로 확산하고 있다. 특히 데이터가 기존 프로덕션 환경 외에도 분석, 개발, 테스트 등에 활용되면서 수많은 복제본이 생성되고 있다. 하지만 전통적인 데이터베이스 관리는 복잡하고 느린 배포, 백업 및 패치의 증가 등으로 새로운 환경을 효율적으로 관리하는 데 한계를 드러내고 있다. 뉴타닉스는 하이브리드 멀티클라우드 환경의 데이터베이스 관리를 위한 해법으로 뉴타닉스 데이터베이스 서비스를 제시한다. 데이터베이스 관리의 현황과 과제를 짚어보고, 뉴타닉스 데이터베이스 서비스의 특징과 주요 기능, 실전 관리 가이드, 주요 사례까지 효율적이고 효과적인 데이터베이스 관리 방안을 알아본다. 주요 내용 - “배포부터 백업까지 모든 것이 시간과 돈” - 하이브리드 멀티클라우드 환경의 데이터베이스 관리 해결사 - 데이터베이스 관리자의 역할 변화 - 주요 데이터베이스 관리 실전 가이드 - 뉴타닉스 데이터베이스 서비스(NDB) 활용 사례 - “최대 291%의 ROI” 데이터베이스를 혁신 엔진으로 전환

데이터베이스 하이브리드클라우드 오픈소스 2022.04.04

"성급하면 결국 골칫거리 된다" 데이터베이스 선택 팁 5가지

데이터베이스 선택은 먼 미래의 애플리케이션과 개발에까지 큰 영향을 미친다. 그런데도 개발자의 데이터베이스 선택은 감정적으로 흐르는 경향이 있고, 오로지 지금의 애플리케이션 요구사항만을 기준으로 데이터베이스를 고르는 경우가 많다.    예를 들어 어떤 데이터베이스에 대한 느낌이 좋다는 이유로 개발자는 단순히 직감을 따르곤 한다. 데이터베이스가 현재와 미래의 애플리케이션에 맞게 효과적으로 작동할지에 대한 분석은 생략한다. 선택할 수 있는 데이터베이스가 너무 많아 비교할 엄두를 내지 못하는 때도 있다. 이럴 때는 사고가 마비되고 결국 현재의 애플리케이션에 필요한 요소를 충족하는 데이터베이스를 선택하게 된다.  문제는 미래의 모든 애플리케이션 요구사항을 미리 알 수 없다는 것이다. 보통 애플리케이션은 처음에는 단순하게 시작했다가 시간이 지날수록 복잡해지기 마련이다. 실제로 많은 개발자가 포스트그레SQL로 시작한다. 반구조적 데이터를 다뤄야 하고 유연한 스키마가 필요해지면 몽고DB를 추가한다. 그런 다음 로그 검색이나 패싯 검색을 하기 위해 일래스틱서치(Elasticsearch)로 눈을 돌린다. 하지만 속도가 매우 빠르지 않다는 것을 발견하고, 레디스(Redis)를 캐시로 덧붙인다. 분석을 해야 할 때가 오면 스노우플레이크(Snowflake)와 같은 데이터 웨어하우스를 불러들인다. 결국 모든 상황이 이내 혼란스럽게 된다. 데이터베이스 난립으로 데이터베이스 간의 데이터 이동과 값비싼 ETL(추출, 변환, 로드) 프로세스가 개발자의 걱정거리가 된다.  이처럼 많은 개발자가 종종 실패의 길로 걸어가지만 필요한 모든 것을 얻을 수 있는 다른 방법도 있다. 모든 요구사항을 충족하는 데이터베이스를 선택하는 방법을 알아보자.    한 치 앞이 아니라 먼 미래를 보라 데이터베이스 마이그레이션과 플랫폼 변경은 간단한 일이 아니다. 데이터베이스를 한 번 선택하면 되돌리기 어렵고 한 아키텍처에 종속될 수 있음을 항상 의식해야 ...

데이터베이스 2022.03.22

“백업 방법 좌우한다” 데이터베이스가 제공되는 방식 3가지

데이터베이스 백업 방법은 데이터베이스 제공 방식과 백업 로지스틱스, 복구 시간 목표(Recovery Time Objective, RTO) 및 복구 시점 목표(Recovery Point Objective, RPO)에 따라 다르다. 데이터베이스의 제공 방식을 중심으로 살펴보자.   데이터베이스가 제공될 수 있는 방식은 크게 3가지가 있다. 사용자 서버에서 소프트웨어로 존재하거나 서비스형 플랫폼(Platform as a Service, PaaS) 및 서버리스 서비스로 제공된다.   전통적인 데이터베이스 소프트웨어 몇 년 전까지만 해도 데이터베이스가 제공되는 방식은 사용자가 제품 라이선스를 구매하고 선택한 서버나 VM에 설치하는 것이 전부였다. 사용자는 서버의 보안 및 관리, 스토리지, 애플리케이션, 데이터베이스 백업을 비롯한 모든 것을 책임져야 했다. 즉, 백업 방식도 사용자가 직접 선택할 수 있었다. 다만, 데이터베이스는 구조화되지 않은 데이터에 맞춰 고안된 방법을 사용해 백업이 쉽지 않은 방식으로 작동하기 때문에 그렇지 않은 경우도 있었다. 전통적인 방식으로 제공되는 데이터베이스에 주로 적용되는 3가지 개념은 다음과 같다.   가변적인 파일 데이터베이스에 있는 데이터는 일반적으로 이를 호스팅하는 서버나 VM의 파일 시스템에서 볼 수 있는 데이터 파일에 저장된다. 이들 파일은 데이터베이스가 업데이트되는 한 계속 변하기 때문에 다른 파일처럼 백업할 수 없다. 즉, 백업이 크게 의미가 없는 것이다.   PIT 백업 및 복구 지원되는 데이터베이스 백업 방식은 대부분 매일 밤 10시와 같은 사본이 만들어진 시점에 데이터베이스 사본을 생성한다. 데이터베이스를 해당 시점으로만 복구할 수 있는 것이다.   특정 시점에서 롤백 데이터베이스 대부분은 더욱 엄격한 RPO를 충족하기 위해 특정 시점을 지정한 최근 시점으로 이동하기 위해 PIT 복구 후 재생할 수 있는 트랜잭션 로그가 있다. 데이터베이스가 충돌해 일관되지 않은 상태가 ...

데이터베이스 백업 2022.01.24

IDG 블로그 | 데이터 마이그레이션을 망치는 방법

냉정하게 말하자면, 대부분 기업의 데이터는 최적의 상태와는 거리가 멀다. 이 말을 확인하고 싶다면? 그저 고객 데이터 기록이 어디에 있는지 물어보라. 서로 다른 부서 네 곳에 물어보면, 네 가지 서로 다른 대답을 듣게 될 것이다.   이 문제는 자연스러운 부산물이다. 20~30년 동안 당시에 인기 있었던 데이터베이스를 사용해 새로운 데이터베이스를 만들어왔기 때문이다. 이들 데이터베이스에는 메인프레임용 데이터베이스, 대규모 관계형 데이터베이스, 오픈소스 SQL, 객체 데이터베이스, 그리고 최근의 특수 목적용 데이터베이스까지 포함된다. 이기종 환경과 복잡성 문제는 테라바이트급 데이터를 클라우드로 이전하려는 기업에는 부정할 수 없는 현실이다. 이런 기업은 클라우드에서 가상 유사한 데이터베이스를 찾아야만 한다. 정확하게 개발업체까지 일치하는 데이터베이스일 수도 있고, 아니면 최소한의 구조 변경과 변환이 필요한 데이터베이스일 수도 있다. 안타까운 것은 이런 접근법은 데이터베이스 사일로 문제를 영속시킨다는 점이다. 오래된 문제이자 현재의 문제를 다음 세대의 IT로 떠넘기는 끝나지 않는 문제의 대표적인 예다. 다음 세대로 떠넘기면 비교적 저렴하게 문제를 해결할 수 있다. 하지만 모든 것을 바로잡는 방법은 그렇게 쉽지도 저렴하지도 않다. 이 때문에 단기적 관점으로 데이터를 퍼블릭 클라우드로 마이그레이션하면, 비용 절감이나 민첩성, 생산성이 좋아지지 않는 경우가 많다. 데이터센터에 있던 문제가 이제는 클라우드에 있는 문제가 되었을 뿐이기 때문이다. 코로나19 팬데믹으로 많은 기업에서 퍼블릭 클라우드의 역할이 더 커졌다. 대부분 기업은 빠르고 저렴하게 클라우드로 이전하고자 한다. 이 때문에 데이터 마이그레이션에도 리프트 앤 시프트 방식을 사용한다. 처음에는 예산 관점에서 좋아 보일 수도 있다. 하지만 장기적인 관점에서 리프트 앤 시프트 방식은 데이터를 두 번 이전해야 한다는 것을 의미한다. 한 번은 잘못된 방식으로 이전하고, 두 번째에야 올바른 방식으로 이전하...

마이그레이션 이기종 복잡성 2021.08.09

IDG 블로그 | “대화가 필요한” 클라우드 데이터베이스와 클라우드 인프라

개발팀과 배치팀 대부분은 이전보다는 클라우드 컴퓨팅 관련 작업을 잘한다. 또한 애자일과 데브옵스/데브섹옵스의 부상으로 운영팀과 개발팀이 좀 더 밀접하게 일할 수 있는 기반이 마련됐다. 이제 개발팀은 운영팀과 함께 일하는 데 부담을 느끼지 않는다.   하지만 이런 체계에도 빈틈은 있다. 말하자면, 클라우드 데이터베이스 설계 담당자는 인프라 아키텍트와 제대로 동기화되지 않은 것으로 보인다. 스토리지와 컴퓨트 등 클라우드 데이터베이스에 중요한 자원을 제공하는 사람인데 말이다. 이런 관계는 결국 나쁜 결과물로 이어진다. 핵심 비즈니스를 처리하는 데이터베이스가 자원이 부족해지고, 누군가의 모니터링 콘솔에 경고 메시지가 나타난 후에나 고쳐진다. 하지만 그러는 동안 데이터베이스를 제 기능을 못하고 중요한 비즈니스 트랜잭션은 타격을 받는다. 확실한 서비스 중단이 발생할 수도 있다. 트랜잭션을 처리 중에 자원이 떨어진 데이터베이스가 아무런 경고도 없이 동작을 멈추는 것이다. 이 사태는 데이터베이스 자체를 붕괴시킬 수 있기 때문에 마지막 백업만이 살 길이 된다. 문제는 클라우드 기반 데이터베이스가 모두 똑같지 않은데, 클라우드 인프라 엔지니어는 똑같다고 생각한다는 것이다. 물론 일부 서버리스 방식 데이터베이스는 필요한 자원을 자동으로 할당하고 담당자는 월말에 사용한 만큼의 비용만 내면 된다. 하지만 대부분 클라우드 데이터베이스는 인프라 담당자가 데이터베이스에 대한 상당한 지식을 갖출 것을 요구한다. 데이터베이스의 수는 물론, 용량, 필요한 스토리지의 종류, 데이터베이스 성장 속도, 데이터 캐시 사용, CPU 종류와 규모 등을 파악해야 한다. 온프레미스 데이터베이스를 구성하고 서버 규모를 잡는 것과 너무 비슷하게 느껴질 것이다. 사실이 그렇다. 인기있는 전통 데이터베이스 중 다수가 여전히 온프레미스와 퍼블릭 클라우드를 구분하지 않는다. 그래서 특정 데이터베이스를 위한 시스템 규모를 설정하고 사용량을 가정하는 과정은 거의 같다. 해법은 모두가 알고 있다. 진짜 ...

데이터베이스 아키텍트 데브옵스 2021.08.04

데이터베이스 보안을 향상시키는 11가지 기술

데이터베이스에는 매우 민감한 내용을 포함한 방대한 양의 개인정보가 저장되므로 책임이 있는 기업이라면 관리에 신경쓸 수밖에 없다. 이제 데이터베이스 개발자는 정교한 도구와 기술을 사용해 정보를 안전하게 지키면서 원하는 작업을 할 수 있다. 비유하자면 살찔 걱정 없이 케이크를 먹을 수 있는 셈이다.   이와 같은 솔루션에는 정교한 수학이 적용된다. 가장 간단한 메커니즘은 현대판 비밀 코드, 즉 고전적인 디코더 휠의 디지털 버전이라고도 할 수 있다. 더 깊은 수학으로 들어가 높은 유연성과 책임성을 제공하는 더 복잡한 확장 형태도 있다. 연구실에서 수십년 전부터 존재했지만 이제서야 신뢰할 만큼의 안정성에 이른 아이디어를 실제로 구현한 버전이 많다. 이 알고리즘들은 비즈니스 관계를 접합하고 정확한, 사기로부터 안전한(fraud-free) 워크플로우를 보장하기 위한 기반이 되고 있다. 이런 접근 방식은 기업에서 고객의 비밀을 보호하면서 더 간편하게 개인화된 서비스를 제공할 수 있게 해준다. 또한 서비스 제공에 지장을 초래하지 않으면서 데이터 흐름에 대한 규정도 더 철저히 준수할 수 있게 해준다. 데이터베이스 신뢰를 간편하게 해주는 11가지 도구와 기술을 소개한다. 1. 기본 암호화(Basic encryption) 가장 간단한 솔루션으로 충분할 때도 있다. 현대 암호화 알고리즘은 하나의 키로 데이터를 잠가 그 키를 소유한 사람만 데이터를 읽을 수 있도록 한다. 많은 데이터베이스가 AES와 같은 표준을 사용해 데이터를 암호화할 수 있다. 이 솔루션은 절도와 같은 하드웨어 분실에 대비한 가장 강력한 보호 수단이다. 올바른 암호화 키가 없으면 데이터를 열어볼 수 없기 때문이다. 그러나 가동 중인 컴퓨터에 공격자가 침입하는 경우, 대칭 암호화 알고리즘이 보호할 수 있는 범위에는 한계가 있다. 데이터베이스의 정상적인 작업을 허용하는 키를 공격자가 찾아낼 수 있기 때문이다. 많은 데이터베이스는 “미사용(at rest)” 상태의 정보를 암호화하는 옵션을 제공한다. ...

데이터베이스 암호화 Basic encryption 2021.07.14

포스트그레SQL의 이점과 과제 핵심 정리

데이터베이스 시장은 오픈소스와 상용 제품으로 계속 분할되는 중이고, 각 진영마다 여러 선택지가 있다. 나온 지 30년이 된 포스트그레SQL은 커뮤니티 주도의 오픈소스 프로젝트로, 여전히 높은 인기를 누리며 전 세계 곳곳에서 규모가 큰 기업의 프로덕션에 사용되고 있다.  예를 들어 얀덱스(Yandex)는 포스트그레SQL에 페타바이트 규모의 데이터를 저장하고, 이를 통해 이메일 서비스를 운영하면서 하루 1억 5,000만 건 이상의 이메일을 처리한다. 오래전부터 포스트그레SQL을 사용해온 깃랩은 초당 18만 1,000건의 트랜잭션을 처리하는 대규모 클러스터를 유지한다. 총소유비용(TCO) 절감을 위해 포스트그레SQL로 전환한 이케아는 테라바이트 규모의 데이터를 실행하는 여러 데이터베이스를 운용하고 있다.    다국적 디지털 기업이 100개국 이상의 현지 법을 준수하도록 돕는 신생 업체인 인컨트리(InCountry)는 포스트그레SQL을 사용해서 서비스형 데이터 레지던시를 위한 글로벌 분산 데이터베이스를 운영한다. 성숙하고 안정적인 데이터베이스 관리 시스템이 필요한, 진보적이고 복잡한 솔루션이다.  당면한 프로젝트에 포스트그레SQL이 적절한 데이터베이스인지 여부를 확인하려면 데이터베이스 환경에서 포스트그레SQL이 위치하는 부분이 어디인지, 그 이점과 과제는 무엇인지를 이해하는 것이 중요하다.    포스트그레SQL의 이점  포스트그레SQL에는 다양한 애플리케이션에 사용하기에 적합한 다음과 같은 여러 특징과 기능이 있다.    코드 품질 : 포스트그레SQL로 들어가는 모든 코드는 여러 전문가의 검토를 거치며, 전체 개발 프로세스가 커뮤니티를 중심으로 진행되므로 버그 보고, 수정, 검증이 매우 신속하게 이뤄진다.    확장성  : 포스트그레SQL은 거의 모든 사용례를 포괄하는 확장 기능을 갖춘 매우 유연한 솔루션이다. 특정 데이터 유형이나 확장된 로깅...

포스트그레SQL 데이터베이스 확장성 2021.05.31

IDG 블로그 | 클라우드 마이그레이션을 위한 데이터베이스 일반화

지난 주 필자는 데이터베이스 일반화(Database Normalization)를 멀티클라우드 아키텍처의 베스트 프랙티스 중 하나로 소개했다. 이번에는 클라우드 마이그레이션에서 이 개념을 살펴보자.   데이터베이스 일반화를 데이터 일반화와 혼동하지 말기 바란다. 데이터 일반화는 리던던시를 줄이고 좀 더 최적화된 구조를 정의하는 작업으로, DBA라면 누구나 알고 있는 과정이다. 30년도 전에 대학에서 가르치던 내용이다. 데이터베이스 일반화는 데이터베이스 자체의 리던던시를 줄여 비즈니스 애플리케이션이나 데이터 과학자, 그리고 이들이 수행하는 데이터 분석의 요구에 부응하는 데 더 중점을 두는 데이터베이스 세트를 만드는 과정이다.  문제는 데이터베이스와 데이터가 클라우드로 이전하면서 지나치게 복잡하고 리던던시로 가득 차 있다는 것이다. 이른바 단일 진실 공급원(single sources of truth)는 찾아보기 어렵다. 또한 클라우드로 데이터를 이전하는 기업 대부분은 그저 데이터베이스를 클라우드로 복제하고자 한다. 이는 큰 실수가 아닐 수 없다. 필자가 아는 한, 예산이란 제한적인 것이고, 데이터를 클라우드 네이티브 및 비 클라우드 네이티브 데이터베이스로 옮기고 결합하는 데는 그저 나쁜 데이터베이스 아키텍처를 클라우드로 밀어내는 것보다 많은 비용이 든다. 하지만 역시 필자가 아는 한, 일단 클라우드로 이전한 후에 문제를 바로잡으려면 훨씬 더 많은 비용이 든다. 만약 이렇게 하지 않으면, 데이터를 두 번 마이그레이션해야 한다. 먼저 리프트 앤 시프트 방식으로 퍼블릭 클라우드로 이전한 다음, 클라우드의 해당 데이터베이스 아키텍처가 최적화되지 않았다는 것을 파악해서 다시 수정해야 하기 때문이다. 최적화되지 않았다는 것은 너무 복잡하거나 리던던시가 많거나 너무 비싼 것을 말한다. 그렇다면 클라우드 마이그레이션에서 데이터베이스 일반화는 어떻게 수행해야 할 것인가? 이상적인 프로세스를 소개한다.   이해관계자의 관심을 확보한다. 우선...

데이터베이스 마이그레이션 일반화 2021.02.17

“대체물에서 그린필드로” 변화하는 포스트그레SQL 시장

포스트그레SQL(PostgreSQL)은 1986년에 나왔지만, 어떻게 된 일인지 해가 갈수록 더 젊어지면서 인기를 끌고 있다. 타임스케일(Timescale)과 같은 신생업체는 오래된 포스트그레SQL을 핵심 요소로 사용해 새로운 데이터베이스 제품을 구축하면서 엔터프라이즈DB(EnterpriseDB) 같은 업체와 함께 포스트그레SQL의 인기를 더욱 높이는 데 일조하고 있다. 사실 엔터프라이즈DB는 얼마 전에 44분기 연속으로 연간 순환 매출 성장을 기록했다. 포스트그레SQL이 11년 동안 엔터프라이즈DB에 돈을 벌어주고 있는 것이다.  이처럼 한결같은 포스트그레SQL이지만 발전은 밋밋하지 않다. 13년째 엔터프라이즈DB CEO를 맡고 있는 에드 보야진은 최근 필자에게 포스트그레SQL 성장의 필수적인 요소에 대해 말했다. 첫 번째는 개발자, 가장 오래된 온프레미스 요구 사항에 맞춰 최적화하는 중에도 클라우드의 새로운 요건을 충족하도록 포스트그레SQL을 발전시키는 개발자들이다.    복고를 향하는 개발자들  지난 몇 년 동안 시장은 NoSQL과 NewSQL을 비롯해 그 외에도 상상할 수 있는 온갖 데이터베이스 형태를 집적거렸다. 또한 자체 관리 데이터센터 호스팅부터 퍼블릭 클라우드에 이르기까지 다양한 변형도 거쳤다.  엔터프라이즈DB는 초기에 애플리케이션이 포스트그레SQL에서 실행되면서 오라클 데이터베이스를 실행 중인 것처럼 인지하도록 하는 호환성 계층으로 오라클에 도전했다. 초창기 엔터프라이즈DB는 그렇게 알려져 있다. 그러나 보야진에 따르면, 기업이 포스트그레SQL을 도입하는 주된 이유는 그게 아니다. 보야진은 엔터프라이즈DB 비즈니스의 약 1/3이 순수한 신규 고객이며, 그 중 절반은 다른 데이터베이스, 주로 오라클에서 마이그레이션하고자 하는 기업이라고 말했다. 나머지 절반은 신규 애플리케이션 분야다.  오라클 대체 솔루션에서 벗어나 새로운 애플리케이션 개발을 향하는 이 변화는 포스트그레SQL의 성장을...

데이터베이스 NoSQL 포스트그레SQL 2021.02.09

“오픈 코어가 아닌 100% 오픈소스로”··· 유가바이트 사례 살펴보기 

‘오픈 코어(Open Core)’ 모델을 채택해 온 오픈소스 소프트웨어 업체들이 많다. 이와 반대로, 오픈소스 분산 SQL 데이터베이스 업계를 선도하는 유가바이트(Yugabyte)는 오픈 코어가 아닌 다른 접근법을 택했다.  오픈소스 기반의 자동화 소프트웨어 회사 셰프(Chef)의 공동창업자 애덤 제이콥은 모든 것을 오픈소스화해야 한다고 주장했다. 유료 ‘엔터프라이즈’ 기능이 가미된 오픈소스 ‘커뮤니티’ 버전이 아닌, 바로 100% 오픈소스다.    이는 비즈니스에 어떤 의미를 가질까? 물론 오픈소스 업체라면 오픈소스 개발자들 사이에서 유명세를 얻고 싶겠지만 한편으론 돌봐야 할 직원들이 있고, 투자를 성공하길 바라는 벤처캐피탈(VC)이 있으며, (이제는 쓸모없지만) 팔로 알토에 있는 사무실 임대료를 매달 내야 하기도 한다. 이런 상황에서 100% 오픈소스 접근법이 실제로 효과 있다는 증거가 있는가?  물론 요점만 말하자면(tl;dr), 모든 코드를 오픈소스화하는 것은 매우 현명한 전략일 수 있다.  소프트웨어를 유효하게 만들기  지난 10년 동안 많은 기업이 오픈소스로 시작했다가 독점 소프트웨어 라이선스로 전환했다. 수익 창출을 위해서다. 하지만 오픈소스 SQL 데이터베이스를 제공하는 유가바이트는 정확히 그 반대였다. 처음에는 오픈소스와 독점 소프트웨어가 혼합된 모델로 시작해 2019년 초에 100% 오픈소스로 전환했다. 이는 멋져 보이기 위해서가 아니었다.   유가바이트(Yugabyte)의 공동창업자이자 CTO 카시크 랑가나단은 “그 이면에는 ‘신중하고 철저한’ 전략이 있었다. 이는 고객이 소프트웨어를 어떻게 평가하는지에 관한 핵심 인사이트를 기반으로 했다”라면서, “기업들은 단순히 소프트웨어를 구매하는 것보다 데이터베이스를 운영하고 프로덕션 환경에서 제대로 실행되도록 하는 데 더 많은 관심을 기울이고 있음을 알았다”라고 말했다.  다시 말해, 그에 따르면 소프트웨어는 중요했...

오픈소스 오픈 코어 유가바이트 2020.12.30

IDG 설문조사

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.