Offcanvas

���������

‘장고(Django) 4.0’, 레디스 데이터베이스 캐싱 지원

파이썬 웹 프레임워크의 데이터베이스 캐싱과 폼 커스터마이징을 특징으로 하는 ‘장고(Django) 버전 4.0’이 공개됐다.  개발팀에 따르면 새로운 레디스(Redis) 캐시 백엔드는 레디스 인-메모리 데이터베이스에 캐싱을 기본적으로 지원한다. 단, 이를 사용하려면 로컬 또는 원격 시스템에서 실행되는 레디스 서버, 레디스용 파이썬 바인딩이 필요하다고 개발팀은 전했다.    또 ‘장고 4.0’에서는 더 간편한 커스터마이징을 지원하기 위해 Forms, Formsets, ErrorList는 이제 템플릿 엔진을 사용하여 렌더링한다.  지난 12월 7일(현지 시각) 출시된 ‘장고 4.0’은 파이썬용 pip 패키지 설치 프로그램으로 설치할 수 있다(pip install Django==4.0). 이 밖에 ‘장고 4.0’의 새로운 기능 및 개선사항은 다음과 같다.  • UniqueConstrain()의 *expressions 위치 인수를 사용하면 표현식 및 데이터베이스에 기능적 고유 제약 조건을 생성할 수 있다.  • scrypt 암호 해시는 PBKDF2 알고리즘보다 더 안전하며, 더 권장된다고 개발팀은 밝혔다. 하지만 이를 사용하려면 오픈SSL(OpenSSL) 1.1 및 추가 메모리가 필요하기 때문에 기본값은 아니라고 덧붙였다.  • 파이썬 표준 라이브러리의 zoneinfo는 현재 장고의 기본 시간대 구현이다.  • 이제 admin/base.html 템플릿에 admin 사이트 헤더를 포함하는 새 블록 헤더가 제공된다.  • ModelAdmin.get_formset_kwargs() 메소드를 사용하면 formset 생성자에 전달된 키워드 인수를 커스터마이징 할 수 있다.  • 탐색 사이드바에 빠른 필터 도구 모음이 추가됐다.  • 각 모델의 모델 클래스를 포함하는 상수 변수 모델이 AdminSite.each_context()에 추가됐다.  • Mod...

장고 파이썬 레디스

2021.12.09

파이썬 웹 프레임워크의 데이터베이스 캐싱과 폼 커스터마이징을 특징으로 하는 ‘장고(Django) 버전 4.0’이 공개됐다.  개발팀에 따르면 새로운 레디스(Redis) 캐시 백엔드는 레디스 인-메모리 데이터베이스에 캐싱을 기본적으로 지원한다. 단, 이를 사용하려면 로컬 또는 원격 시스템에서 실행되는 레디스 서버, 레디스용 파이썬 바인딩이 필요하다고 개발팀은 전했다.    또 ‘장고 4.0’에서는 더 간편한 커스터마이징을 지원하기 위해 Forms, Formsets, ErrorList는 이제 템플릿 엔진을 사용하여 렌더링한다.  지난 12월 7일(현지 시각) 출시된 ‘장고 4.0’은 파이썬용 pip 패키지 설치 프로그램으로 설치할 수 있다(pip install Django==4.0). 이 밖에 ‘장고 4.0’의 새로운 기능 및 개선사항은 다음과 같다.  • UniqueConstrain()의 *expressions 위치 인수를 사용하면 표현식 및 데이터베이스에 기능적 고유 제약 조건을 생성할 수 있다.  • scrypt 암호 해시는 PBKDF2 알고리즘보다 더 안전하며, 더 권장된다고 개발팀은 밝혔다. 하지만 이를 사용하려면 오픈SSL(OpenSSL) 1.1 및 추가 메모리가 필요하기 때문에 기본값은 아니라고 덧붙였다.  • 파이썬 표준 라이브러리의 zoneinfo는 현재 장고의 기본 시간대 구현이다.  • 이제 admin/base.html 템플릿에 admin 사이트 헤더를 포함하는 새 블록 헤더가 제공된다.  • ModelAdmin.get_formset_kwargs() 메소드를 사용하면 formset 생성자에 전달된 키워드 인수를 커스터마이징 할 수 있다.  • 탐색 사이드바에 빠른 필터 도구 모음이 추가됐다.  • 각 모델의 모델 클래스를 포함하는 상수 변수 모델이 AdminSite.each_context()에 추가됐다.  • Mod...

2021.12.09

칼럼|데이터베이스의 '주류 교체', 숨막히게 더딜지라도...

데이터베이스의 인기는 몇 년이 아닌 십수 년을 주기로 오르내린다. 미래에 기업 전반에서 대세로 자리잡을 데이터베이스가 지금은 현재 개발자의 눈길을 끄는 단계일 수 있다.  한번 손에 익은 데이터베이스는 여간해선 바꾸기 어렵다. 오라클 데이터베이스가 그렇다. 스택오버플로우가 올해 7만 2,517명의 개발자를 대상으로 실시한 설문조사에 따르면 개발자들은 '가장 두려운'(most dreaded) 데이터베이스로 오라클을 꼽았다. 그럼에도 오라클은 데이터베이스로 수십억 달러의 매출을 끊임없이 달성하고 있다.    하지만 이를 꼭 나쁘게 볼 필요는 없다. 지난해(그리고 2019년, 2018년, 2017년, 2016년에도) 레디스는 개발자들이 '가장 선호하는' 데이터베이스로 꼽혔고, 포스트그레SQL과 몽고 DB가 그 뒤를 이었다. 이는 지난 2017년 데이터베이스 선호 순위와 대체로 같았다. 다만 SQL서버는 그때 이후로 순위가 하락했고 구글의 파이어베이스는 순위가 상승했다. 즉 개발자들의 데이터베이스 선호도는 잘 바뀌지 않는다. 선호도가 자주 변화하는 웹 프레임워크와 비교된다. 가트너의 머브 아드리안은 "레거시 데이터베이스를 존속시키는 가장 큰 힘은 관성"이라고 말한 바 있다. 그런 이유로 새로운 데이터베이스를 구축하는 데는 오랜 시간이 걸리지만 한때 사랑받았던 데이터베이스를 폐기하는 데는 더 오랜 시간이 걸린다. 심지어 개발자가 이직하더라도 기업은 사용하던 데이터베이스를 바꾸지 않곤 한다.  한 걸음 나아가 생각하면 다음과 같은 예측도 가능하다. 현재 개발자들이 선호하는 데이터베이스가 앞으로 10년간 기업 전반에 자리잡게 될 것이라는 예측이다. 많은 것이 변화하지만... 오늘날처럼 선택 가능한 데이터베이스가 많은 시대도 없다. DB-엔진에 따르면 현재 시중에는 373개의 데이터베이스가 있다. 그중 오라클, 마이SQL, 마이크로소프트 SQL 서버처럼 비교적 역사가 오래된 것과 몽고 DB,...

데이터베이스 오라클 레디스 포스트그레SQL 몽고 DB 파이어베이스 DB-엔진 마이 SQL 마이크로소프트 SQL

2021.08.11

데이터베이스의 인기는 몇 년이 아닌 십수 년을 주기로 오르내린다. 미래에 기업 전반에서 대세로 자리잡을 데이터베이스가 지금은 현재 개발자의 눈길을 끄는 단계일 수 있다.  한번 손에 익은 데이터베이스는 여간해선 바꾸기 어렵다. 오라클 데이터베이스가 그렇다. 스택오버플로우가 올해 7만 2,517명의 개발자를 대상으로 실시한 설문조사에 따르면 개발자들은 '가장 두려운'(most dreaded) 데이터베이스로 오라클을 꼽았다. 그럼에도 오라클은 데이터베이스로 수십억 달러의 매출을 끊임없이 달성하고 있다.    하지만 이를 꼭 나쁘게 볼 필요는 없다. 지난해(그리고 2019년, 2018년, 2017년, 2016년에도) 레디스는 개발자들이 '가장 선호하는' 데이터베이스로 꼽혔고, 포스트그레SQL과 몽고 DB가 그 뒤를 이었다. 이는 지난 2017년 데이터베이스 선호 순위와 대체로 같았다. 다만 SQL서버는 그때 이후로 순위가 하락했고 구글의 파이어베이스는 순위가 상승했다. 즉 개발자들의 데이터베이스 선호도는 잘 바뀌지 않는다. 선호도가 자주 변화하는 웹 프레임워크와 비교된다. 가트너의 머브 아드리안은 "레거시 데이터베이스를 존속시키는 가장 큰 힘은 관성"이라고 말한 바 있다. 그런 이유로 새로운 데이터베이스를 구축하는 데는 오랜 시간이 걸리지만 한때 사랑받았던 데이터베이스를 폐기하는 데는 더 오랜 시간이 걸린다. 심지어 개발자가 이직하더라도 기업은 사용하던 데이터베이스를 바꾸지 않곤 한다.  한 걸음 나아가 생각하면 다음과 같은 예측도 가능하다. 현재 개발자들이 선호하는 데이터베이스가 앞으로 10년간 기업 전반에 자리잡게 될 것이라는 예측이다. 많은 것이 변화하지만... 오늘날처럼 선택 가능한 데이터베이스가 많은 시대도 없다. DB-엔진에 따르면 현재 시중에는 373개의 데이터베이스가 있다. 그중 오라클, 마이SQL, 마이크로소프트 SQL 서버처럼 비교적 역사가 오래된 것과 몽고 DB,...

2021.08.11

칼럼 | '나 그냥 코딩하게 해주세요'··· 오픈소스 프로젝트 관리자의 딜레마

오픈소스 프로젝트를 유지한다는 것은 코딩과 전혀 다른 이야기다. 관심사가 코딩인 사람이 프로젝트를 유지해야 하다면 문제가 될 수 있다는 의미다.  레디스(Redis) 설립자인 살바토르 샌필리포에게는 임기 제한이 없었다. 그의 리더 지위에 제동을 건 사람도 없었고, 그가 레디스의 혁신을 지속하는 데 다른 걸림돌이 있지도 않았다. 그러나 2020년 6월 30일 샌필리포는 레디스 직무의 종료를 발표했다. 이 프로젝트의 최고 관리자 역할을 그만두겠다는 것이다.  그는 다음과 같이 말했다. “앞날이 어떨지 정말이지 모르겠다. 이렇다 할 일도 없이 그냥 두리번거리기만 하는 것 같다.”   10년이 넘는 기간 동안 레디스의 간판 역할을 해온 샌필리포는 한계에 도달했다. 그는 휴식이 필요했다. 샌필리포의 이탈이 초래할 영향은 레디스 커뮤니티에 한정될 것이 유력하지만, 좀더 살펴보면 더 넓은 함의를 갖는다.   여기서는 오픈소스 관리자에 대해 이야기할 것이다. 그리고 샌필리포의 사례가 기업에게 어떤 교훈을 주는지 살펴본다.   또 다른 종류의 ‘로우 코드’ 오픈소스 커뮤니티가 어떻게 돌아가는지 아는 사람이라면 아마 이 사실을 알고 있을 것이다. 즉, 관리자는 코드를 많이 쓰지 않는다는 사실이다. 기트허브 오픈소스 가이드에서 보듯이 “수많은 사람이 사용하는 오픈소스 프로젝트를 관리한다면 코드를 작성하는 것보다 문제에 대응하는 데 더 많은 일을 한다.”  코드를 쓰는 대신 기여자가 자신의 코드를 오픈소스 프로젝트에 유용하게 만드는 데 도움을 주거나, 프로세스와 비전을 문서로 정리하거나, 그 밖의 여러 일을 해야 한다. 그리고 코딩을 하는 경우는 그렇게 많지 않다.  OBS 프로젝트의 설립자 겸 관리자인 짐 베일리는 “프로젝트를 관리할 때 골칫거리 가운데 하나는 유입되는 소프트웨어가 그다지 양호하지 않은 경우가 흔하다는 점이다”라고 말했다.  그는 “사람들의 코드를 리뷰하는 것은 매우 어려울 수 ...

레디스 오픈소스 프로젝트 관리자 살바토르 샌필리포 코딩

2020.07.08

오픈소스 프로젝트를 유지한다는 것은 코딩과 전혀 다른 이야기다. 관심사가 코딩인 사람이 프로젝트를 유지해야 하다면 문제가 될 수 있다는 의미다.  레디스(Redis) 설립자인 살바토르 샌필리포에게는 임기 제한이 없었다. 그의 리더 지위에 제동을 건 사람도 없었고, 그가 레디스의 혁신을 지속하는 데 다른 걸림돌이 있지도 않았다. 그러나 2020년 6월 30일 샌필리포는 레디스 직무의 종료를 발표했다. 이 프로젝트의 최고 관리자 역할을 그만두겠다는 것이다.  그는 다음과 같이 말했다. “앞날이 어떨지 정말이지 모르겠다. 이렇다 할 일도 없이 그냥 두리번거리기만 하는 것 같다.”   10년이 넘는 기간 동안 레디스의 간판 역할을 해온 샌필리포는 한계에 도달했다. 그는 휴식이 필요했다. 샌필리포의 이탈이 초래할 영향은 레디스 커뮤니티에 한정될 것이 유력하지만, 좀더 살펴보면 더 넓은 함의를 갖는다.   여기서는 오픈소스 관리자에 대해 이야기할 것이다. 그리고 샌필리포의 사례가 기업에게 어떤 교훈을 주는지 살펴본다.   또 다른 종류의 ‘로우 코드’ 오픈소스 커뮤니티가 어떻게 돌아가는지 아는 사람이라면 아마 이 사실을 알고 있을 것이다. 즉, 관리자는 코드를 많이 쓰지 않는다는 사실이다. 기트허브 오픈소스 가이드에서 보듯이 “수많은 사람이 사용하는 오픈소스 프로젝트를 관리한다면 코드를 작성하는 것보다 문제에 대응하는 데 더 많은 일을 한다.”  코드를 쓰는 대신 기여자가 자신의 코드를 오픈소스 프로젝트에 유용하게 만드는 데 도움을 주거나, 프로세스와 비전을 문서로 정리하거나, 그 밖의 여러 일을 해야 한다. 그리고 코딩을 하는 경우는 그렇게 많지 않다.  OBS 프로젝트의 설립자 겸 관리자인 짐 베일리는 “프로젝트를 관리할 때 골칫거리 가운데 하나는 유입되는 소프트웨어가 그다지 양호하지 않은 경우가 흔하다는 점이다”라고 말했다.  그는 “사람들의 코드를 리뷰하는 것은 매우 어려울 수 ...

2020.07.08

칼럼ㅣ이렇게 많은 ‘데이터베이스’가 필요한가? 

오늘날 데이터를 저장하기 위해 선택할 수 있는 수백 개의 데이터베이스가 있다. 하지만 우리는 더 많은 데이터베이스가 필요하다.  과거에는 약간의 데이터베이스만으로도 세상은 그럭저럭 돌아갔다. 이를테면 오라클(Oracle), 마이크로소프트 SQL 서버(Microsoft SQL Server), 인그레스(Ingres), IBM DB2와 같은 신뢰할 수 있는 관계형 데이터베이스를 예로 들 수 있겠다.  그러나 얼마 지나지 않아 ‘MySQL’과 ‘PostgreSQL’이라는 오픈소스 데이터베이스가 등장하면서 상업용 DB 제품에 도전장을 내밀었다. 그 이후 ‘NoSQL’ 데이터베이스가 출시되면서 대표주자 격인 몽고DB(MongoDB), 레디스(Redis), 아파치 카산드라(Apache Cassandra) 등이 인기를 끌고 있다.    숫자만 놓고 보자면 이 변화를 더 빠르게 체감할 수 있다. DB 엔진(DB-Engines)의 2013년 인기 순위 목록에는 총 109개의 데이터베이스가 있었다. 현재는 어떨까? 올해 목록에는 7년 전보다 3배 이상 늘어난 총 356개의 데이터베이스가 존재한다.  이제 자연스럽게 의문이 들기 마련이다. 데이터베이스의 증가가 좋은 일인가? 무려 365개나 되는 데이터베이스가 정말 필요한가? PostgreSQL(DB엔진 순위 4위)이 계속 사용될 텐데 굳이 Yanza(336위)나 Upscaledb(299위)가 필요한가? 대답은 ‘그렇다’일 가능성이 크다.  “소수만 성공할 것이다” 모두가 동의하는 것은 아니다. 이를테면 몽고DB의 CEO 데브 이티체리아는 한 인터뷰에서 “실제로 성공하는 플랫폼이나 기술은 소수다”라고 의견을 피력했다. 그렇다면 그 ‘소수’는 누구인가? 그는 “레거시 표준이나 관계형 데이터베이스(예: 오라클 또는 오픈소스)를 가진 기업들이 머지않아 ‘최신 표준’을 갖추게 될 것”이라고 전했다. 당연히 이티체리아는 몽고DB를 ‘최신 표준’으로 보고 있으며, 이 ...

데이터베이스 몽고DB 레디스 아파치 카산드라 오라클 마이크로소프트 SQL 서버 인그레스 IBM Db2 관계형 데이터베이스 오픈소스 데이터베이스 MySQL PostgreSQL NoSQL

2020.06.30

오늘날 데이터를 저장하기 위해 선택할 수 있는 수백 개의 데이터베이스가 있다. 하지만 우리는 더 많은 데이터베이스가 필요하다.  과거에는 약간의 데이터베이스만으로도 세상은 그럭저럭 돌아갔다. 이를테면 오라클(Oracle), 마이크로소프트 SQL 서버(Microsoft SQL Server), 인그레스(Ingres), IBM DB2와 같은 신뢰할 수 있는 관계형 데이터베이스를 예로 들 수 있겠다.  그러나 얼마 지나지 않아 ‘MySQL’과 ‘PostgreSQL’이라는 오픈소스 데이터베이스가 등장하면서 상업용 DB 제품에 도전장을 내밀었다. 그 이후 ‘NoSQL’ 데이터베이스가 출시되면서 대표주자 격인 몽고DB(MongoDB), 레디스(Redis), 아파치 카산드라(Apache Cassandra) 등이 인기를 끌고 있다.    숫자만 놓고 보자면 이 변화를 더 빠르게 체감할 수 있다. DB 엔진(DB-Engines)의 2013년 인기 순위 목록에는 총 109개의 데이터베이스가 있었다. 현재는 어떨까? 올해 목록에는 7년 전보다 3배 이상 늘어난 총 356개의 데이터베이스가 존재한다.  이제 자연스럽게 의문이 들기 마련이다. 데이터베이스의 증가가 좋은 일인가? 무려 365개나 되는 데이터베이스가 정말 필요한가? PostgreSQL(DB엔진 순위 4위)이 계속 사용될 텐데 굳이 Yanza(336위)나 Upscaledb(299위)가 필요한가? 대답은 ‘그렇다’일 가능성이 크다.  “소수만 성공할 것이다” 모두가 동의하는 것은 아니다. 이를테면 몽고DB의 CEO 데브 이티체리아는 한 인터뷰에서 “실제로 성공하는 플랫폼이나 기술은 소수다”라고 의견을 피력했다. 그렇다면 그 ‘소수’는 누구인가? 그는 “레거시 표준이나 관계형 데이터베이스(예: 오라클 또는 오픈소스)를 가진 기업들이 머지않아 ‘최신 표준’을 갖추게 될 것”이라고 전했다. 당연히 이티체리아는 몽고DB를 ‘최신 표준’으로 보고 있으며, 이 ...

2020.06.30

클라우드-오픈소스 기업, '배제' 아닌 '공존'에서 답 찾기

마이크로소프트와 레디스랩스가 제휴를 맺고 ‘애저 캐시 포 레디스’에 ‘레디스 엔터프라이즈’를 통합한다. 이번 협력은 오픈소스 기반 서비스 업체와 초대형 클라우드와의 공존을 보여주는 사례라는 점에서 의의가 있다.  NoSQL 스토리지에는 종류가 많다. 이를테면 문서 지향 데이터베이스도 있고 키-값 쌍을 저장하는 것도 있는데, 모두 서로 다른 인덱스와 쿼리를 지원한다. 또한 디스크 기반 시스템도 있고, 메모리에서 작동하도록 설계된 것도 있다. 이를 통해 대량의 데이터를 효율적으로 처리하는 데 집중하거나 속도에 주력하기도 한다. 이처럼 매우 다양한 제품 중에서 하나를 선택하기란 어렵기 마련이다.  그중 가장 인기 있는 인메모리 시스템은 레디스(Redis)다. 이는 리모트 딕셔너리 서버(Remote Dictionary Server)의 약자다. 레디스랩스(RedisLabs)에서 후원하는 오픈소스 레디스 서버에 구축되며, 상용 엔터프라이즈 옵션이 있다.  마이크로소프트는 애저에서 오픈소스 레디스를 자체적으로 구축한 서비스 ‘애저 캐시 포 레디스(Azure Cache for Redis)’를 꽤 오랫동안 제공해왔다. 주로 고성능 캐시로 사용됐다. 그런데 최근 마이크로소프트가 레디스랩스와의 제휴를 발표했다. 즉, 풀 매니지드 레디스 엔터프라이즈가 마이크로소프트 클라우드에 추가된 것이다.     레디스 엔터프라이즈가 추가된 애저 이 새로운 서비스는 기존의 ‘베이직(Basic)’, ‘스탠다드(Standard),’ ‘프리미엄(Premium)’ 서비스에 ‘엔터프라이즈(Enterprise)’와 ‘엔터프라이즈 SSD(Enterprise SSD)’라는 2가지 계층(Tier)을 더한 것으로 생각하면 된다.  마이크로소프트의 ‘애저 캐시 포 레디스’는 대규모 클라우드 네이티브 애플리케이션에 고성능 캐시를 제공하는 것에 주력해 왔다. 컨테이너화된 시스템이나 서버리스 시스템을 구축하는 경우 이벤트 주도 코드 또는 세션 상태에 대한 ...

마이크로소프트 애저 클라우드 레디스랩스 레디스 레디스 엔터프라이즈 오픈소스 NoSQL 스토리지 문서 지향 데이터베이스 인메모리 데이터베이스 닷넷 비주얼 스튜디오

2020.06.24

마이크로소프트와 레디스랩스가 제휴를 맺고 ‘애저 캐시 포 레디스’에 ‘레디스 엔터프라이즈’를 통합한다. 이번 협력은 오픈소스 기반 서비스 업체와 초대형 클라우드와의 공존을 보여주는 사례라는 점에서 의의가 있다.  NoSQL 스토리지에는 종류가 많다. 이를테면 문서 지향 데이터베이스도 있고 키-값 쌍을 저장하는 것도 있는데, 모두 서로 다른 인덱스와 쿼리를 지원한다. 또한 디스크 기반 시스템도 있고, 메모리에서 작동하도록 설계된 것도 있다. 이를 통해 대량의 데이터를 효율적으로 처리하는 데 집중하거나 속도에 주력하기도 한다. 이처럼 매우 다양한 제품 중에서 하나를 선택하기란 어렵기 마련이다.  그중 가장 인기 있는 인메모리 시스템은 레디스(Redis)다. 이는 리모트 딕셔너리 서버(Remote Dictionary Server)의 약자다. 레디스랩스(RedisLabs)에서 후원하는 오픈소스 레디스 서버에 구축되며, 상용 엔터프라이즈 옵션이 있다.  마이크로소프트는 애저에서 오픈소스 레디스를 자체적으로 구축한 서비스 ‘애저 캐시 포 레디스(Azure Cache for Redis)’를 꽤 오랫동안 제공해왔다. 주로 고성능 캐시로 사용됐다. 그런데 최근 마이크로소프트가 레디스랩스와의 제휴를 발표했다. 즉, 풀 매니지드 레디스 엔터프라이즈가 마이크로소프트 클라우드에 추가된 것이다.     레디스 엔터프라이즈가 추가된 애저 이 새로운 서비스는 기존의 ‘베이직(Basic)’, ‘스탠다드(Standard),’ ‘프리미엄(Premium)’ 서비스에 ‘엔터프라이즈(Enterprise)’와 ‘엔터프라이즈 SSD(Enterprise SSD)’라는 2가지 계층(Tier)을 더한 것으로 생각하면 된다.  마이크로소프트의 ‘애저 캐시 포 레디스’는 대규모 클라우드 네이티브 애플리케이션에 고성능 캐시를 제공하는 것에 주력해 왔다. 컨테이너화된 시스템이나 서버리스 시스템을 구축하는 경우 이벤트 주도 코드 또는 세션 상태에 대한 ...

2020.06.24

칼럼 | 레디스가 바꾼 DB 시장, SW 혁신은 '가려운 곳'에서 시작된다

굳이 새 데이터베이스를, 특히 2009년 당시 지배적인 데이터베이스 클래스 관점에서 전혀 무의미했던 인메모리 데이터베이스를 만든 이유가 무엇이었을까? 사실 살바토레 산필리포는 그런 것에는 관심이 없었다. 데이터베이스에 대한 다른 사람의 생각을 바꾸려 한 것이 아니라, 단지 실시간 분석 엔진을 확장해야 했는데 마이SQL은 비용 효율적이지 않았을 뿐이다. 그래서 탄생한 것이 바로 레디스(Redis)였고 이후 데이터베이스 시장은 완전히 바뀌었다.   지난 몇 주 동안 산필리포 같은 오픈소스 프로젝트 설립자와 대화하면서 놀란 점도 이것이었다. 특정한 한 가지 필요(오픈소스 용어로 '가려운 곳(itch)')에 대한 답을 찾고자 시작한 오픈소스 프로젝트가 결과적으로 해당 제품의 범주 자체를 바꿔 놓는 경우가 많다는 사실이다. 그들은 유용한 뭔가를 만들고자 했을 뿐이지만 결과적으로 '혁신적인 뭔가'를 만들어 버렸다. 궁금증이 생겼다. 여러분의 기업이 혁신을 위한 새로운 방법을 찾는 중이라면, 혹시 직원에게 오픈소스에 더 깊이 참여하도록 독려한 적이 있는가?   새로운 것 탐색하기 우리는 레거시 기술의 익숙한 루틴에 머무르는 경우가 있다. 산필리포는 "트위터 대화에서 모든 문제가 해결된 것처럼 보여도, 특정 소프트웨어 영역에서는 새로운 것을 탐색하는 것이 가능하다"라고 말했다. 실제로 관계형 데이터베이스(RDBMS) 시장은 수십 년 동안 정체 상태였다. 새로운 기능이 등장하고 새로운 훌륭한 오픈소스 데이터베이스도 나왔지만(마이SQL, 포스트그레SQL), 여전히 행과 열에 이것저것을 집어넣는 방식이었다. 그것이 데이터를 다루는 '올바른 방법(right way)'이었기 때문이다. 그러나 어쩌면 '올바른' 방법이 아니었을 수도 있다. 대부분은 맞았을 수 있지만 항상 그런 것은 아니었다. 예를 들어 일부 데이터는 관계형 모델에 적합하다. 특히 ERP 시스템과 같은 레코드 시스템이 그렇다. 하지만 세계가 인게이지먼트(engagement) 시스템으로 옮겨가면서 ...

레디스 데이터베이스 오픈소스

2020.05.29

굳이 새 데이터베이스를, 특히 2009년 당시 지배적인 데이터베이스 클래스 관점에서 전혀 무의미했던 인메모리 데이터베이스를 만든 이유가 무엇이었을까? 사실 살바토레 산필리포는 그런 것에는 관심이 없었다. 데이터베이스에 대한 다른 사람의 생각을 바꾸려 한 것이 아니라, 단지 실시간 분석 엔진을 확장해야 했는데 마이SQL은 비용 효율적이지 않았을 뿐이다. 그래서 탄생한 것이 바로 레디스(Redis)였고 이후 데이터베이스 시장은 완전히 바뀌었다.   지난 몇 주 동안 산필리포 같은 오픈소스 프로젝트 설립자와 대화하면서 놀란 점도 이것이었다. 특정한 한 가지 필요(오픈소스 용어로 '가려운 곳(itch)')에 대한 답을 찾고자 시작한 오픈소스 프로젝트가 결과적으로 해당 제품의 범주 자체를 바꿔 놓는 경우가 많다는 사실이다. 그들은 유용한 뭔가를 만들고자 했을 뿐이지만 결과적으로 '혁신적인 뭔가'를 만들어 버렸다. 궁금증이 생겼다. 여러분의 기업이 혁신을 위한 새로운 방법을 찾는 중이라면, 혹시 직원에게 오픈소스에 더 깊이 참여하도록 독려한 적이 있는가?   새로운 것 탐색하기 우리는 레거시 기술의 익숙한 루틴에 머무르는 경우가 있다. 산필리포는 "트위터 대화에서 모든 문제가 해결된 것처럼 보여도, 특정 소프트웨어 영역에서는 새로운 것을 탐색하는 것이 가능하다"라고 말했다. 실제로 관계형 데이터베이스(RDBMS) 시장은 수십 년 동안 정체 상태였다. 새로운 기능이 등장하고 새로운 훌륭한 오픈소스 데이터베이스도 나왔지만(마이SQL, 포스트그레SQL), 여전히 행과 열에 이것저것을 집어넣는 방식이었다. 그것이 데이터를 다루는 '올바른 방법(right way)'이었기 때문이다. 그러나 어쩌면 '올바른' 방법이 아니었을 수도 있다. 대부분은 맞았을 수 있지만 항상 그런 것은 아니었다. 예를 들어 일부 데이터는 관계형 모델에 적합하다. 특히 ERP 시스템과 같은 레코드 시스템이 그렇다. 하지만 세계가 인게이지먼트(engagement) 시스템으로 옮겨가면서 ...

2020.05.29

모바일 앱 개발자 주의 사항 '백엔드 보안 확보'

개발자는 애플리케이션 코드에 보안을 적용하고 애플리케이션에서 데이터를 처리하는 방법을 보호해야 하지만, 이른바 하스피털가운(HospitalGown) 보안 문제가 보여주는 것처럼 백엔드 서버와 데이터 저장소가 어떻게 구성됐는지도 알아야 한다. 애플리케이션 보안은 단순히 개발자의 문제가 아니다. IT인력과 보안팀도 인프라 및 구축 및 보안 제어 이행에서 실행할 역할이 있다. IT관리자가 앱의 백엔드 서버를 위한 보안 기본 사항을 잊으면 개발자의 훌륭한 보안 결정을 갉아먹게 된다. 모바일 보안기업 앱소러티(Appthority)의 연구원들은 최근 (기업 IT에서 제공하고 관리하는 모바일 기기뿐 아니라 BYOD 시나리오의 개인용 장치를 포함하여) 기업 기기에 설치된 앱을 분석하고 백엔드 서버에 보안 통제가 없어서 데이터가 노출되고 있는 1,000개 이상의 앱을 발견했다. 수집된 데이터를 마이닝하고 분석하기 위해 사용자 데이터와 분석 툴을 저장하는 데이터베이스를 관리하는 서버는 방화벽이 없었고 인증이 필요 없었으며 인터넷에서 공개적으로 접근할 수 있었다. 앱소러티의 보안 연구 책임자 세스 하디에 따르면, 앱소러티는 1,000개의 앱이 2만 1,000개 이상의 개방된 엘라스틱서치(Elasticsearch) 서버에 연결돼 있었으며 약 43TB의 데이터가 노출됐다. 노출된 데이터에는 비밀번호, 위치, 이동 및 결제 세부사항, 이메일과 전화번호 등의 기업 프로필 데이터, 유통사 고객 데이터 등의 PII(Personally Identifiable Information)가 포함되어 있었다. 연구원들은 분석 보고서에서 이러한 유형의 정보는 사기 및 크리덴셜 기반 공격에 사용하거나 피싱 등의 2차 공격에 사용할 수 있다. 데이터는 여전히 구멍이 난 서버에 있었고 ‘승인되지 않은 당사자들이 복사하거나 다운로드할 위험에’ 여전히 노출되어 있었기 때문에 사용자가 장치에서 앱을 삭제한다 하더라도 데이터 노출은 끝났지 않았다고 밝혔다. 승인되지...

CSO 카우치DB 엘라스틱서치 MongoDB CouchDB 카우치베이스 농기계 하스피털가운 HospitalGown 앱소러티 레디스 Redis 랜섬웨어 사물인터넷 마이닝 데이터베이스 피싱 개발 MySQL CISO 코드 BYOD 몽고DB 랜섬 마이SQL CouchBase

2017.06.14

개발자는 애플리케이션 코드에 보안을 적용하고 애플리케이션에서 데이터를 처리하는 방법을 보호해야 하지만, 이른바 하스피털가운(HospitalGown) 보안 문제가 보여주는 것처럼 백엔드 서버와 데이터 저장소가 어떻게 구성됐는지도 알아야 한다. 애플리케이션 보안은 단순히 개발자의 문제가 아니다. IT인력과 보안팀도 인프라 및 구축 및 보안 제어 이행에서 실행할 역할이 있다. IT관리자가 앱의 백엔드 서버를 위한 보안 기본 사항을 잊으면 개발자의 훌륭한 보안 결정을 갉아먹게 된다. 모바일 보안기업 앱소러티(Appthority)의 연구원들은 최근 (기업 IT에서 제공하고 관리하는 모바일 기기뿐 아니라 BYOD 시나리오의 개인용 장치를 포함하여) 기업 기기에 설치된 앱을 분석하고 백엔드 서버에 보안 통제가 없어서 데이터가 노출되고 있는 1,000개 이상의 앱을 발견했다. 수집된 데이터를 마이닝하고 분석하기 위해 사용자 데이터와 분석 툴을 저장하는 데이터베이스를 관리하는 서버는 방화벽이 없었고 인증이 필요 없었으며 인터넷에서 공개적으로 접근할 수 있었다. 앱소러티의 보안 연구 책임자 세스 하디에 따르면, 앱소러티는 1,000개의 앱이 2만 1,000개 이상의 개방된 엘라스틱서치(Elasticsearch) 서버에 연결돼 있었으며 약 43TB의 데이터가 노출됐다. 노출된 데이터에는 비밀번호, 위치, 이동 및 결제 세부사항, 이메일과 전화번호 등의 기업 프로필 데이터, 유통사 고객 데이터 등의 PII(Personally Identifiable Information)가 포함되어 있었다. 연구원들은 분석 보고서에서 이러한 유형의 정보는 사기 및 크리덴셜 기반 공격에 사용하거나 피싱 등의 2차 공격에 사용할 수 있다. 데이터는 여전히 구멍이 난 서버에 있었고 ‘승인되지 않은 당사자들이 복사하거나 다운로드할 위험에’ 여전히 노출되어 있었기 때문에 사용자가 장치에서 앱을 삭제한다 하더라도 데이터 노출은 끝났지 않았다고 밝혔다. 승인되지...

2017.06.14

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

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

Copyright © 2022 International Data Group. All rights reserved.

10.5.0.9