Simple is Beautiful.

다양한 종류의 NoSQL에 대해 알아봅니다.

이 글은 다음 글을 발췌 및 번역한 글입니다: do.co/3lFbfMU

1. 소개

대부분의 사람들은 데이터베이스를 생각할 때 행(row)과 열(column)로 구성된 테이블을 포함하는 전통적인 관계형 데이터베이스 모델을 생각합니다. RDBMS는 여전히 인터넷에서 가장 많은 데이터를 처리하지만 개발자들은 관계형 모델의 한계에 대한 해결방법을 찾으려 노력함에 따라 최근 몇 년간 관계형 모델을 대체할 수 있는 데이터 모델이 좀 더 보편화되었습니다. 이러한 비 관계형 데이터 베이스 모델은 NoSQL이라 불리며 각각의 고유한 장점, 단점, 사용 사례를 확인해 보도록 하겠습니다.

이 글에서는 좀 더 일반적으로 사용되는 몇 가지 NoSQL 데이터베이스 모델을 소개합니다. 장점과 단점 중 일부를 평가하고 데이터베이스 관리 시스템의 몇 가지 예시와 각각에 대한 잠재적 사용 사례를 제공합니다.

2. 관계형 데이터베이스와 한계.

데이터베이스는 논리적으로 모델링 된 정보 또는 데이터 클러스터입니다. DBMS는 데이터베이스와 상호작용하는 컴퓨터 프로그램입니다. DBMS를 사용하면 데이터베이스에 대한 액세스를 제어하고 데이터를 쓰고 쿼리를 실행하는 등 데이터 베이스 관리와 관련된 기타 작업을 수행할 수 있습니다. DBMS는 종종 데이터베이스라고 불리지만 정확하 하자면 두 용어는 서로 동등하게 쓰일 수 없습니다. 데이터베이스는 컴퓨터에 저장된 데이터뿐 아니라 모든 데이터의 모음이 될 수 있으며 DBMS는 데이터 베이스와 상호작용할 수 있는 특정 소프트웨어일 뿐입니다.

모든 DBMS는 데이터가 저장되고 액세스 되는 방식을 구조화하는 기본 모델이 있습니다. 관계형 데이터베이스 관리 시스템(RDBMS)은 관계형 데이터 모델을 사용하는 DBMS입니다. 이 모델에서 데이터는 RDBMS의 맥락에 따라 공식적으로 관계(Relation)라고 불리는 테이블로 구성됩니다. RDBMS는 일반적으로 데이터베이스 내 보관된 데이터를 관리하고 액세스 하기 위해 SQL(Structured Query Language)을 사용합니다.

역사적으로 관계형 모델은 데이터 관리에 가장 널리 사용되는 접근 방식이며 오늘날까지 가장 널리 사용되는 DBMS도 관계형 모델을 구현합니다. 하지만 관계형 모델에는 특정 사용 사례에서 문제가 될 수 있는 몇 가지 제약사항이 존재합니다.

예를 들어 관계형 데이터베이스를 수평적으로 확장하는 것은 어려울 수도 있습니다. 수평적 확장은 부하를 분산하고 더 많은 트래픽과 더 빠른 처리를 하기 위해 기존 스택에 더 많은 머신을 추가하는 관행입니다. 이는 일반적으로 RAM 또는 CPU를 더 추가하여 기존 서버의 하드웨어를 업그레이드하는 수직적 확장과 대조되는 경우가 많습니다.

관계형 데이터 베이스를 수평적으로 확장하는 것이 어려운 이유는 관계형 모델이 일관성을 보장하도록 설계되어 있다는 사실과 관련이 있습니다. 즉 동일한 데이터 베이스를 쿼리 하는 클라이언트는 항상 최신의 데이터를 보게 해야 합니다. 여러 시스템에 걸쳐 관계형 데이터 베이스를 수평으로 확장하는 경우 클라이언트가 A노드가 아닌 B노드에 데이터를 쓸 수 있고 처음 쓴 B노드와 다른 노드들이 연결되는 시간이 존재해 변경 사항이 반영되는 업데이트 지연이 발생할 수 있어 일관성을 보장하기 어려워집니다.

RDBMS의 또 다른 제한사항은 관계형 모델이 구조화된 데이터 또는 사전 정의된 데이터 타입과 일치하거나 최소한 미리 결정된 방식으로 구성되어야 데이터를 쉽게 정렬하고 검색할 수 있도록 설계되었다는 것입니다. 하지만 1990년 이후 개인용 컴퓨터의 확산과 인터넷의 부상으로 이메일 메시지, 사진, 비디오 등과 같은 비정형 데이터가 보편화되었습니다.

이러한 제한이 더욱 크게 부각됨에 따라 개발자들은 기존의 관계형 데이터 모델의 대안을 찾기 시작하였으며 이로 인해 NoSQL 데이터베이스의 인기가 높아졌습니다.

3. NoSQL이란?

NoSQL이란 이름 자체에 대해서는 다소 모호한 정의가 있습니다. "NoSQL"은 1998년 Carlo Strozzi가 단순히 데이터 관리에 SQL을 사용하지 않았기 때문에 NoSQL 데이터베이스란 이름으로 만들어졌습니다.

이 용어는 2009년 이후 Johan Oskarsson이 Cassandra와 Voldemort 같은 "오픈소스 분산 및 비 관계형 데이터베이스"의 확산을 논의하기 위해 개발자 모임을 조직하면서 새로운 의미를 갖게 되었습니다. Oskarsson은 모임 이름을 "NoSQL"이라 명명하였으며 그 이후로 이 용어는 관계형 모델을 사용하지 않는 모든 데이터베이스에 대한 포괄적인 용어로 사용되게 되었습니다. 흥미롭게도 Strozzi의 NoSQL 데이터베이스는 실제로 관계형 모델을 사용합니다. 즉 처음의 NoSQL 데이터베이스는 현재의 NoSQL 정의에 맞지 않습니다.

"NoSQL"은 일반적으로 관계형 모델을 사용하지 않는 DBMS를 나타내므로 NoSQL 개념과 관련된 몇 가지 운영 데이터 모델이 있습니다. 다음에는 이러한 데이터 모델을 여러 개 소개합니다만 이는 전체 목록이 아닙니다.

이러한 다양한 기본 데이터 모델이 있음에도 불구하고 대부분의 NoSQL 데이터베이스는 몇 가지 특성을 공유합니다. NoSQL 데이터베이스는 일반적으로 일관성을 희생해 가용성을 최대화하도록 설계되었습니다. 여기서 일관성의 의미는 모든 읽기 작업이 데이터베이스에 기록된 가장 최근 데이터를 반환해야 한다는 생각을 의미합니다. 강력한 일관성을 위해 설계된 분산 데이터베이스에서 드는 한 노드에 기록된 모든 데이터를 다른 모든 노드에서 즉시 사용할 수 있으며 그렇지 않으면 오류가 발생합니다.

반대로 NoSQL 데이터베이스는 주로 최종 일관성을 목표로 합니다. 최종 일관성은 새로 작성된 데이터가 반드시 즉시 사용할 수 있어야 하는 것은 아니지만 결국 데이터베이스의 다른 노드에서 사용할 수 있게 됨(보통 몇 ms내에)을 의미합니다. 이렇게 하면 데이터의 가용성이 향상되는 이점이 있습니다. 작성된 최신 데이터를 즉시 볼 수 없더라고 오류가 발생하지 않고 이전 버전의 데이터를 볼 수 있습니다.

관계형 데이터베이스는 미리 정의된 스키마에 정확하게 맞는 정규화된 데이터를 처리하도록 설계되었습니다. DBMS의 맥락에서 정규화된 데이터는 중복을 제거하는 방식으로 구성된 데이터를 말합니다. 즉, 데이터베이스가 가능한 가장 적은 저장공간을 차지하도록 하는 것을 의미하며 스키마는 데이터베이스의 데이터가 구조화되는 방식에 대한 개요입니다.

NoSQL 데이터베이스는 정규화된 데이터를 저리 할 수 있고 미리 정의된 스키마 내에서 데이터를 정렬하는 것도 가능하지만 각각의 데이터 모델은 일반적으로 관계형 데이터베이스가 강요하는 견고한 구조보다 훨씬 더 큰 유연성을 허용하고 있습니다. 이 때문에 NoSQL 데이터베이스는 반정형, 비정형 데이터를 저장하는데 더 나은 선택으로 유명합니다. 하지만 NoSQL 데이터 베이스에선 사전에 정의된 스키마가 존재하지 않기 때문에 데이터베이스 관리자가 애플리케이션에 가장 적합한 방식으로 데이터를 구성하고 액세스 하는 방법을 정의해야 한다는 점을 염두해 두어야 합니다.

4. 마침.

NoSQL 데이터베이스가 무엇이며 관계형 데이터베이스와 다른 점에 대해 간략하게 파악해 봤습니다. 광범위하게 다음 글부터는 광범위하게 구현된 NoSQL 데이터베이스 모델 중 일부를 살펴보도록 하겠습니다.

SQLite, MySQL, PostgreSql을 비교하고 어떤 경우에 어떤 DB가 더 나은 선택인지에 대해 알아봅니다.

이 글은 다음 글을 발췌 및 번역한 글입니다: do.co/3kD2Ybd

1. 소개.

데이터를 테이블의 행(row)과 열(column)로 구성하는 관계형 데이터 모델은 DB 관리 툴에 있어서 대세를 차지하고 있습니다. 최근 NoSQL과 NewSQL을 포함한 다른 데이터 모델이 있지만 관계형 데이터 베이스 관리 시스템(RDBMS)은 데이터를 저장하고 관리하는 데 있어 여전시 전 세계적으로 대다수를 차지합니다.

앞으로 작성할 글에서는 가장 널리 구현된 세 가지 오픈소스 RDBMS인 SQLite, MySQL 및 PostgreSQL을 비교하고 대조합니다. 특히 각 RDBMS가 제공하는 데이터 타입, 장점과 단점, 최적의 상황에 대해 알아보도록 합니다.

2. PostgreSql

Postgres라고도 불리는 PostgreSql은 "세계에서 가장 진보된 오픈소스 관계형 데이터베이스"라고 자부합니다. 확장성이 뛰어나고 표준을 준수한다는 목표로 만들어졌습니다. PostgreSql은 객체 관계형(object-relational) 데이터베이스입니다. 즉 기본적으로는 관계형 데이터베이스지만 객체 데이터베이스와 연관되는 기능(예를 들면 테이블 상속 및 함수 오버로딩)도 포함하고 있습니다.

Postgres는 동시성(Concurrency)을 특징으로 갖고 있습니다. 동시성은 동시에 여러 작업을 효율적으로 처리할 수 있도록 합니다. ACID 준수라고도 하는 트랜잭션의 원자성(Atomicity), 일관성(Consistencty), 격리성(Isolation), 내구성(Durability)을 보장하는 MVCC(Multiversion Concurrency Control) 덕분에 읽기에 대한 잠금 없이 이를 달성할 수 있습니다.

PostgreSql은 MySQL만큼 널리 사용되지는 않지만 pgAdmin 및 Postbird를 포함하여 PostgreSql 작업을 단순화하도록 설계된 타사 도구 및 라이브러리가 많습니다.

3. PostgreSql의 데이터 타입

PostgreSql은 MySQL과 같이 숫자, 문자열, 날짜와 시간 타입을 지원합니다. 또한 기하학적인 도형, 네트워크 주소, 비트 문자열, 텍스트 검색, JSON 항목과 몇 가지 특이한 데이터 타입을 지원하기도 합니다.

3.1. Numeric 타입.

• bigint: 부호 있는 8바이트 정수.
• bigserial: 자동으로 증가하는 8바이트 정수.
• double precision: 8바이트 double precision 부동 소수점 숫자.
• integer: 부호 있는 4바이트 정수.
• serial: 자동으로 증가하는 4바이트 정수.
• number, decimal: 선택 가능한 precision. 돈의 금액과 같이 정확성이 중요한 경우 사용하도록 권장합니다.
• real: 4바이트 single precision 부동 소수점 숫자.
• smallint: 부호 있는 2바이트 정수.
• smallserial: 자동으로 증가하는 2바이트 정수.

3.2. Character 타입.

• character: 지정된 고정 길이를 가지는 문자열.
• character varying, varchar: 가변이지만 제한된 길이를 갖는 문자열.
• text: 길이에 제한이 없는 문자열.

3.3. Date와 Time 타입.

• date: 일, 월, 년도로 구성된 날짜.
• interval: 시간 간격 범위.
• time, time without time zone: 시간대를 제외한 시간.
• time with time zone: 시간대를 포함한 시간.
• timestamp, timestamp without time zone: 시간대를 제외한 타임스탬프.
• timestamp with time zone: 시간대를 포함한 타임스탬프.

3.4. Geometric 타입

• box: 평면산의 직사각형 상자.
• circle: 평면상의 원.
• line: 평면상의 무한한 선.
• lseg: 평면상의 선분.
• path: 평면상의 기하학적 경로.
• point: 평면상의 기하학적 점.
• polygon: 평면상의 닫힌 기하학적 경로.

3.5. Network address 타입.

• cdir: IPv4 또는 IPv6 네트워크 주소.
• inet: IPv4 또는 IPv6 호스트 주소.
• macaddr: MAC(Media Access Control) 주소.

3.6. Bit string 타입.

• bit: 고정된 길이의 비트 문자열.
• bit varying: 가변 길이의 비트 문자열.

3.7. Text search 타입.

• tsquery: 텍스트 검색 쿼리.
• tsvector: 텍스트 검색 문서(document)

3.8. JSON 타입.

• json: 텍스트 JSON 데이터.
• jsonb: 분해된 이진 JSON 데이터.

3.9. 그 외의 데이터 타입.

• boolean: true 또는 false를 나타내는 논리 값.
• bytea: "byte array"의 약자. 이 타입은 이진 데이터에 사용됩니다.
• money: 통화 금액.
• ph_lsn: 로그 시퀀스 번호.
• txid_snapshot: 사용자 수준의 트랜잭션 ID 스냅샷.
• uuid: 보편적인 고유한 식별자.
• xml: xml 데이터.

4. PostgreSql의 장점.

표준 SQL을 준수합니다. SQLite 또는 MySQL보다 PostgreSql은 표준에 좀 더 가깝게 구현하는 것을 목표로 하고 있습니다. 공식 PostgreSql 문서에 따르면 PostgreSql은 전체 핵심 SQL:2011 규정에 필요한 179개의 기능 중 160개를 지원하며 긴 목록의 선택적 기능도 지원합니다.

오픈소스 및 커뮤니티가 이끄는 데이터베이스입니다. 완전한 오픈소스 프로젝트인 PostgreSql의 소스코드는 대규모 헌신적인 커뮤니티에서 개발되었습니다. Postgres 커뮤니티는 DBMS로 작업하는 방법을 설명하는 공식문서, 위치, 온라인 포럼을 포함한 수많은 리소스를 유지 관리하고 기여합니다.

확장성이 뛰어납니다. 사용자는 카탈로그 기반 작업과 동적 로드 사용을 통해 PostgreSQL을 프로그래밍 방식으로 즉시 확장할 수 있습니다. 공유 라이브러리와 같은 객체 코드 파일을 지정할 수 있고 PostgreSQL은 필요에 따라 이를 로드합니다.

5. PostgreSql의 단점.

메모리 성능이 떨어집니다. 모든 새로운 클라이언트 연결에 대해 PostgresSQL은 새로운 프로세스를 포크(fork)합니다. 각각의 새로운 프로세스에는 약 10MB의 메모리가 할당되므로 많은 연결이 있는 경우 메모리가 빠르게 증가합니다. 따라서 읽기가 많은 간단한 작업의 경우 PostgreSQL은 일반적으로 MySQL과 같은 다른 RDBMS보다 성능이 떨어집니다.

인기도가 떨어집니다. 최근 몇 년 동안 더 널리 사용되고 있지만 PostgreSQL은 역사적으로 보았을 때 인기 측면에서 MySQL에 뒤쳐집니다. 그 결과 PostgreSQL 데이터베이스를 관리하는데 도움이 되는 타사 도구가 여전히 적습니다. 마찬가지로 MySQL은 경험이 있는 사람이 많은 것에 비해 Postgre 데이터베이스 관리 경험이 있는 사람들은 많지 않습니다.

6. PostgreSql를 사용하면 좋은 경우.

데이터 무결성이 중요한 경우 적합합니다. PostgreSQL은 2001년부터 ACID를 완벽히 준수하고 데이터 일관성이 유지되도록 MVCC를 구현하였습니다. 데이터 무결성이 중요한 경우 RDBMS 중 PostgreSQL을 강력하게 추천합니다.

다른 도구들과 통합되어야 하는 경우에 적합합니다. PostgreSQL은 다양한 프로그래밍 언어 및 플랫폼과 호환됩니다. 즉 데이터베이스를 다른 운영체제로 마이그레이션 하거나 특정 도구와 통합이 필요한 경우 다른 DBMS보다 PostgreSQL 데이터 베이스를 사용하는 것이 더 쉽게 작업할 수 있습니다.

복잡한 작업 연산을 수행하는 경우 적합합니다. Postgres는 더 빠른 속도로 쿼리에 응답하기 위해 여러 CPU를 활용할 수 있는 쿼리 계획을 지원합니다. 이는 동시에 여러 사용자에 대한 강력한 지원과 결합되며 데이터웨어 하우스 및 온라인 트랜잭션 처리와 같은 복잡한 작업에 적합한 선택이 될 수 있습니다.

7. PostgreSql를 사용하면 안 되는 경우.

속도에 민감한 경우 적합하지 않습니다. PostgreSQL은 속도를 희생하며 확장성과 호환성을 염두하고 설계되었습니다. 프로젝트에 가능한 가장 빠른 읽기 작업이 필요한 경우 PostgreSQL은 최선의 선택이 아닐 수도 있습니다.

간단한 설정이 필요한 경우 적합하지 않습니다. 광범위한 기능들과 표준 SQL에 대한 강력한 준수로 인해 Postgresql은 간단한 데이터베이스 설정에 대해서도 많은 작업이 필요합니다. 속도가 중요하고 읽기 작업이 많은 경우 일반적으로 MySQL이 더 실용적인 선택이 될 수 있습니다.

간단한 복제(Replication) 작업을 원하는 경우 적합하지 않습니다. PostgreSQL은 복제에 대해 강력한 지원을 제공하지만 여전히 비교적 새로운 기능이며 Primary-Primary 구조와 같은 일부 구성만 가능합니다. 복제는 MySQL에서 더 성숙한 기능이며 많은 사용자들이 특히 필요한 데이터 베이스 및 시스템 관리 경험이 부족한 사용자들은 MySQL의 복제 기능을 구현하는 게 더 쉽다고 생각합니다.

8. 마침.

최근 SQLite, MySQL, PostgreSQL은 세계에서 가장 인기 있는 세 가지 오픈소스 관계형 데이터베이스 관리 시스템입니다. 각각 고유한 기능과 한계가 있으며 특정 시나리오에서 최상의 성능을 보입니다. RDBMS를 설정할 때 사용되는 변수는 상당히 많으며 선택은 가장 빠른 것을 선택하거나 가장 많은 기능을 가진 것을 선택하는 것만큼 간단하지는 않습니다. 다음에 관계형 데이터베이스 솔루션이 필요할 때 이 글이 도움이 되었으면 좋겠습니다.

SQLite, MySQL, PostgreSql을 비교하고 어떤 경우에 어떤 DB가 더 나은 선택인지에 대해 알아봅니다.

이 글은 다음 글을 발췌 및 번역한 글입니다: do.co/3kD2Ybd

1. 소개.

데이터를 테이블의 행(row)과 열(column)로 구성하는 관계형 데이터 모델은 DB 관리 툴에 있어서 대세를 차지하고 있습니다. 최근 NoSQL과 NewSQL을 포함한 다른 데이터 모델이 있지만 관계형 데이터 베이스 관리 시스템(RDBMS)은 데이터를 저장하고 관리하는 데 있어 여전시 전 세계적으로 대다수를 차지합니다.

앞으로 작성할 글에서는 가장 널리 구현된 세 가지 오픈소스 RDBMS인 SQLite, MySQL 및 PostgreSQL을 비교하고 대조합니다. 특히 각 RDBMS가 제공하는 데이터 타입, 장점과 단점, 최적의 상황에 대해 알아보도록 합니다.

2. MySQL

DB-Engines 랭킹에 따르면 MySQL은 2012년 사이트가 데이터베이스의 인기 순위를 집계하기 시작한 이후 가장 있기 있는 오픈소스 RDBMS였습니다. 트위터, 페이스북, 넷플릭스, 스포티파이등을 포함한 세계 최대 웹사이트 및 애플리케이션에서 사용되고 있는 다양한 기능을 가진 제품입니다. 다양한 부분에서 철저한 문서와 대규모 개발자 커뮤니티뿐 아니라 온라인에 MySQL 관련 정보가 풍부하기 때문에 MySQL을 시작하는 것은 비교적 간단합니다.

MySQL은 표준 SQL을 완전히 준수하지 않는 대신 속도와 안정성을 위해 디자인되었습니다. MySQL 개발자는 표준 SQL을 더 가깝게 지키기 위해 지속적으로 노력하고 있지만 여전히 다른 SQL의 구현체보다 뒤처져 있습니다. 그러나 다양한 SQL 모드 및 확장 기능을 제공하며 규정을 지키려 하고 있습니다. SQLite를 사용하는 애플리케이션과 달리 MySQL을 사용하는 애플리케이션은 별도의 데몬 프로세스를 통해 데이터베이스에 액세스 합니다. 서버 프로세스는 데이터 베이스와 다른 응용프로그램 사이에 있기 때문에 데이터베이스에 액세스 할 수 있는 사용자들을 더 잘 제어할 수 있습니다.

MySQL은 기능을 확장하고 더 쉽게 작업을 할 수 있도록 도와주는 다양한 타사 애플리케이션, 도구, 통합 라이브러리에 영향을 주었습니다. 이러한 타사 도구 중 가장 널리 사용되는 것들 중 일부는 phpMyAdmin, DBeaber, HeidiSQL입니다.

3. MySQL의 데이터 타입

MySQL의 데이터 타입은 numeric 타입, date와 time 타입, string 타입의 세 가지 카테고리로 구분할 수 있습니다.

3.1. Numeric 타입.

• tinyint: 매우 작은 정수 값. 부호 있는 범위는 -128~127이고 부호 없는 범위는 0~255입니다.
• smallint: 작은 정수값. 부호 있는 범위는 -32768~32767이고 부호 없는 범위는 0~65535입니다.
• mediumint: 중간 크기의 정수값. 부호 있는 범위는 -8388608~8388607이고 부호 없는 범위는 0~16777215입니다.
• int, integer: 일반적인 정수 값. 부호 있는 범위는 -2147483648~2147483647이고 부호 없는 범위는 0~4294967295입니다.
• bigint: 큰 정수값. 부호 있는 범위는 -9223372036854775808~9223372036854775807이고 부호 없는 범위는 0~18446744073709551615입니다.
• float: 작은(Single-precision) 부동 소수점 숫자.
• double, double precision, real: 일반(Double-precision) 부동 소수점 숫자.
• dec, decimal, fixed, numeric: 고정 소수점 숫자. 데이터 타입에 대한 표시 길이는 열(column)이 작성될 때 정의되며 모든 항목은 해당 길이를 준수합니다.
• bool, boolean: Boolean은 일반적으로 true 또는 false값만 갖습니다.
• bit: 1에서 64까지 값마다 비트수를 지정할 수 있는 비트 값 유형입니다.

3.2. Date와 Time 타입.

• date: YYYY-MM-DD로 표시되는 날짜.
• datetime: 날짜와 시간을 표시하는 타임스탬프. YYYY-MM-DD HH:MM:SS로 표시됩니다.
• timestamp: Unix시(1970-01-01 00:00:00) 이후의 시간을 나타내는 타임스탬프.
• time: HH:MM:SS로 표시되는 시간.
• year: 두 자리 또는 네 자리 형식으로 표현된 연도. 기본값은 네 자리입니다.

3.3. String 타입.

• char: 고정 길이 문자열. 저장 시 지정된 길이에 맞도록 나머지가 공백으로 채워집니다.
• varchar: 가변 길이 문자열.
• binary: char 타입과 유사하지만 지정된 길이에 맞는 이진 문자열이 저장됩니다.
• varbinary: varchar 타입과 유사하지만 가변 길이의 이진 문자열이 저장됩니다.
• blob: 데이터의 최대 길이가 65535인 이진 문자열.
• tinyblob: 데이터의 최대 길이가 255인 이진 문자열.
• mediumblob: 데이터의 최대 길이가 16777215인 이진 문자열.
• longblob: 데이터의 최대 길이가 4294967295인 이진 문자열.
• text: 최대 길이가 65535인 문자열.
• tinytext: 최대 길이가 255인 문자열.
• mediumtext: 최대 길이가 1677215인 문자열.
• longtext: 최대 길이가 4294967295인 문자열.
• enum: 열거형. 테이블을 만들 때 선언된 값 목록 중 단일 값을 가져오는 문자열 개체.
• set: 열거형과 유사하게 0개 이상의 값을 가질 수 있는 문자열 개체. 각 값은 테이블이 생성될 때 지정한 허용 가능한 목록에서 선택되어야 합니다.

4. MySQL의 장점.

인기 있고 사용하기 편한 데이터베이스입니다. 세계에서 가장 인기 있는 데이터베이스 시스템중 하나입니다. MySQL 작업 경험이 있는 데이터베이스 관리자가 부족하지 않습니다. 마찬가지로 MySQL 데이터 베이스를 설치하고 관리하는 방법과 데이터베이스 시작 프로세스를 단순화하는 것을 목표로 하는 여러 가지 타사 도구(예를 들면 phpMyAdmin)에 대한 온라인 설명서가 많습니다. 

보안 수준이 높은 데이터베이스입니다. MySQL은 설치 시 암호 보안 수준을 설정할 수 있고 루트 사용자의 암호를 정의하며 익명 계정을 제거하고 모든 사용자가 접근할 수 있는 기본 테스트 데이터베이스를 제거하여 보안을 향상하는데 도움이 되는 스크립트와 함께 설치됩니다. 또한 SQLite와 달리 MySQL은 사용자 관리를 지원해 사용자 별로 액세스 권한을 부여할 수 있습니다.

속도가 빠른 데이터베이스입니다. MySQL 개발자들은 SQL의 특정 기능을 구현하지 않기로 선택함으로써 속도를 우선순위로 지정할 수 있었습니다. 최근의 벤치마크 테스트에 따르면 PostgreSQL과 같은 몇몇의 RDBMS가 속도 측면에서 MySQL과 비슷할 수 있음을 보여주었지만 MySQL은 여전히 매우 빠른 데이터베이스 솔루션으로 명성을 얻고 있습니다.

복제(Replication) 기능을 지원합니다. MySQL은 안정성(Reliability), 가용성(Availability), 내결함성(Fault-tolerance)을 향상하기 위해 두 개 이상의 호스트에서 정보를 공유하는 방식인 여러 유형의 복제(Replication) 기능을 지원합니다. 이는 데이터베이스 백업 솔루션을 설정하거나 데이터베이스를 수평적으로 확장하는데 유용합니다.

5. MySQL의 단점.

알려진 제한 기능이 있습니다. MySQL은 완전한 SQL의 준수보다는 속도와 사용 편의성을 위해 디자인되었기 때문에 특정 기능을 사용하는데 제한이 있습니다. 예를 들자면 FULL JOIN절에 대한 지원이 없습니다.

라이선스 및 독점 기능에 대한 제약이 존재합니다. MySQL은 GPLv2에 따라 라이선스가 부여된 무료 오픈 소스 커뮤니티 에디션과 독점 라이선스에 따라 출시된 여러 유료 상용 에디션이 있는 이중 라이선스 소프트웨어입니다. 이로 인해 일부 기능 및 플러그인은 독점 라이선스 버전에서만 사용할 수 있습니다.

느린 개발에 대한 불만이 존재합니다. MySQL 프로젝트는 2008년에 Sun Microsystem에, 그리고 2009년에 Oracle corporation에 인수된 이후 커뮤니티에는 더 이상 문제에 대해 신속하게 대응하고 변화를 구현할만한 주체가 사라졌기 때문에 DBMS 개발 프로세스가 크게 느려졌다는 사용자 불만이 존재합니다.

6. MySQL를 사용하면 좋은 경우.

분산 작업이 필요한 경우에 적합합니다. MySQL의 복제 기능 지원은 Primary-Secondary 또는 Primary-Primary 구조와 같은 분산 데이터베이스 설정에 적합한 선택입니다.

웹 사이트 및 웹 애플리케이션에 적합합니다. MySQL은 인터넷을 통해 많은 웹 사이트와 애플리케이션을 지원합니다. 이는 대체로 MySQL 데이터베이스를 설치하고 설정하는 것이 쉽고 속도가 빠르며 장기적으로 봤을 때 확장성이 좋기 때문입니다.

향후 성장이 예상되는 제품에 적합합니다. MySQL의 복제 기능 지원은 수평적 확장에 도움이 될 수 있습니다. 또한 다른 수평적 확장 프로세스인 자동 샤딩(Automatic Sharding)을 지원하는 MySQL Cluster와 같은 상용 MySQL 제품으로 업그레이드하는 것은 어렵지 않습니다.

7. MySQL를 사용하면 안 되는 경우.

SQL 준수가 필요한 경우 적합하지 않습니다. MySQL은 전체 표준 SQL을 구현하려 하지 않기 때문에 모든 SQL을 완전히 준수하지 않습니다. 만약 완전히 또는 거의 완전한 SQL 준수가 필요한 경우보다 완벽하게 SQL과 호환되는 DBMS를 사용하는 것이 좋습니다.

동시성(Cuncurrency)과 대용량 데이터 볼륨이 요구되는 경우 적합하지 않습니다. MySQL은 일반적으로 읽기가 많은 작업에서 잘 수행되지만 동시에 읽기와 쓰기 작업이 일어나는 경우는 문제가 될 수 있습니다. 응용프로그램에 한 번에 많은 사용자가 데이터를 쓰는 경우 PostgreSQL과 같은 다른 RDBMS가 더 나은 선택이 될 수 있습니다.

8. 마침.

이상으로 MySQL의 데이터 타입, 장단점, 사용하면 좋은 경우와 그렇지 않은 경우에 대해 알아보았습니다. 다음 글에선 PostgreSQL에 대해 알아보도록 하겠습니다.

SQLite, MySQL, PostgreSql을 비교하고 어떤 경우에 어떤 DB가 더 나은 선택인지에 대해 알아봅니다.

이 글은 다음 글을 발췌 및 번역한 글입니다: do.co/3kD2Ybd

1. 소개.

데이터를 테이블의 행(row)과 열(column)로 구성하는 관계형 데이터 모델은 DB 관리 툴에 있어서 대세를 차지하고 있습니다. 최근 NoSQL과 NewSQL을 포함한 다른 데이터 모델이 있지만 관계형 데이터 베이스 관리 시스템(RDBMS)은 데이터를 저장하고 관리하는 데 있어 여전시 전 세계적으로 대다수를 차지합니다.

앞으로 작성할 글에서는 가장 널리 구현된 세 가지 오픈소스 RDBMS인 SQLite, MySQL 및 PostgreSQL을 비교하고 대조합니다. 특히 각 RDBMS가 제공하는 데이터 타입, 장점과 단점, 최적의 상황에 대해 알아보도록 합니다.

2. SQLite

SQLite는 낮은 메모리 환경에서도 이식성, 안정성, 강력한 성능으로 잘 알려진 독립형 파일 기반의 오픈소스 RDBMS입니다. 시스템이 충돌하거나 정전이 발생해도 트랜잭션은 ACID를 준수합니다.

SQLite 프로젝트의 웹 사이트에서는 이를 "Serverless" 데이터 베이스라고 설명하고 있습니다. 대부분의 관계형 데이터 베이스 엔진은 다음과 같이 서버 프로세스로 구성됩니다: 프로그램이 요청을 중계하는 프로세스 사이의 통신을 통해 호스트 서버와 통신하는 서버 프로세스.

그러나 SQLite를 사용하면 데이터 베이스에 엑세스 하는 모든 프로세스가 데이터베이스 디스크 파일을 직접 읽고 쓰게 됩니다. 따라서 서버 프로세스를 구성할 필요가 없어지고 SQLite의 설정 과정을 단수화 합니다. 마찬가지로 SQLite 데이터베이스를 사용할 프로그램에는 구성이 필요하지 않게 됩니다. 필요한 것은 단지 디스크에 대한 액세스뿐입니다.

SQLite는 무료이며 오픈소스 소프트웨어이고 이를 사용하는데 특별한 라이선스가 필요하지 않습니다. 하지만 돈을 낸다면 압축 및 암호화에 도움이 되는 몇 가지 확장 기능을 제공합니다. 또한 SQLite는 상업적인 지원 패키지를 연간 요금을 받고 지원해 줍니다.

3. SQLite의 데이터 타입

SQLite는 다음의 스토리지 클래스로 구성된 다양한 데이터 타입을 지원합니다:

• null: NULL값을 포함합니다.
• integer: 부호가 있는 정수로 값의 크기에 따라 1, 2, 4, 6, 8 바이트로 저장됩니다.
• real: 실수 또는 8바이트 부동 소수점 숫자로 저장되는 값.
• txt: 데이터베이스 인코딩을 사용하여 저장된 텍스트 문자열. UTF-8, UTF-16BE, UTF-16LE.
• blob: 입력된 그대로 저장된 데이터의 blob.

SQLite의 문맥에서 "스토리지 클래스"와 "데이터 타입"이라는 용어는 서로 바꿔 사용할 수 있는 것으로 간주됩니다. SQLite의 데이터 타입 및 SQLite 타입 선호도에 대해 자세히 알고 싶다면 해당 주제에 대한 SQLite의 공식 문서를 참고해 주세요.

4. SQLite의 장점.

SQLLite는 이름에서 알 수 있듯이 매우 가볍습니다. 사용하는 공간은 설치된 시스템에 따라 다르지만 600kb 미만의 공간을 차지합니다. 또한 완전히 독립형이므로 SQLite가 작동하기 위해 시스템에 설치해야 하는 외부 종속성이 없습니다.

SQLite는 사용자 진화적인 RDBMS입니다. SQLite는 즉시 사용될 수 있는 "Zero-configuration" 데이터베이스로 설명되곤 합니다. SQLite는 서버 프로세스로 실행되지 않기 때문에 시작, 재시작, 중지의 과전이 없고 관리를 위한 구성 파일이 함께 제공되지 않습니다. 이러한 기능은 SQLite 설치에서 애플리케이션과의 통합까지의 과정을 간소화하는데 도움이 됩니다.

이식성이 뛰어납니다. 데이터를 분리된 파일의 커다란 배치로 저장하는 다른 일반적은 데이터베이스와는 달리 SQLite는 단일 파일에 전체 데이터가 저장됩니다. 이 파일은 디렉터리 계층의 어디에나 위치할 수 있으며 이동식 디스크 또는 파일 전송 프로토콜을 통해 공유할 수 있습니다.

5. SQLite의 단점.

동시성(Concurrency)에 제한이 있습니다. 동시에 여러 프로세스가 SQLite 데이터베이스에 액세스하고 쿼리가 가능하지만 주어진 시간에 하나의 프로세스만이 데이터베이스를 변경할 수 있습니다. 즉 SQLite는 대부분의 다른 임베디드 데이터베이스 관리 시스템보다는 더 큰 동시성을 지원하긴 하지만 MySQL, PostgreSQL과 같은 클라이언트-서버의 구조를 같은 RDBMS만큼은 아닙니다.

사용자 관리가 존재하지 않습니다. 데이터베이스 시스템은 데이터베이스 및 테이블에 대해 사전에 정의된 액세스 권한을 사용자에게 제공합니다. SQLite는 일반 디스크 파일을 직접 읽고 쓰기 때문에 적용 가능한 유일한 액세스 권한은 기본 운영 체제의 일반적인 액세스 권한 뿐입니다. 이로 인해 SQLite는 특별한 액세스 권한이 필요한 응용 프로그램에는 적합하지 않습니다.

SQLite는 다른 RDBMS에 비해 보안이 약합니다. SQLite와 같은 서버리스 데이터베이스보다 서버를 사용하는 것이 클라이언트 애플리케이션의 버그로부터 더 안전할 수 있습니다. 예를 들어 서버를 사용하는 경우 클라이언트의 잘못된 포인터는 서버 메모리의 손상을 일으킬 수 없습니다. 또한 서버는 하나의 영구적인 프로세스이기 때문에 클라이언트-서버 데이터베이스는 서버리스 데이터베이스보다 더 정밀하게 데이터 액세스를 제어할 수 있습니다. 이 말은 서버리스 데이터 베이스보다 더 세밀한 잠금(lock) 기능과 더 나은 동시성(Concurrency)을 제공할 수 있다는 뜻입니다.

6. SQLite를 사용하면 좋은 경우.

임베디드 애플리케이션에 적합합니다. SQLite는 이식성이 필요하고 향후 확장이 필요하지 않은 애플리케이션에 훌륭한 데이터 베이스입니다. 예를 들면 단일 사용자가 사용하는 로컬 애플리케이션이나 모바일 앱, 게임이 있습니다.

SQLite는 디스크 액세스를 대체할 수 있습니다. 애플리케이션이 파일을 디스크에 직접 읽고 써야 하는 경우 SQLite를 사용하는 것이 SQLite에서 제공되는 추가 기능과 SQL이 단순성을 위해 더 유용합니다.

테스트 환경에서 유용합니다. 대부분의 애플리케이션에서 추가 서버 프로세스를 사용하는 DBMS로 테스팅을 진행하는 것이 과할 수 있습니다. SQLite에는 실제 데이터베이스 작업의 오버헤드 없이 빠르게 테스트를 수행하는 데 사용할 수 있는 인메모리 모드가 있으므로 테스트에 이상적입니다.

7. SQLite를 사용하면 안 되는 경우.

많은 데이터 작업이 요구되는 경우 적합하지 않습니다. SQLite는 디스크 드라이브와 파일 시스템이 지원한다면 최대 140TB까지 기술적으로 지원하긴 합니다. 하지만 SQLite 웹사이트는 어떤 DB든 1TB에 근접해지면 중앙 집중형의 클라이언트-서버 데이터베이스에 보관할 것을 권장합니다. 해당 크기 이상의 SQLite 데이터베이스는 관리하기 어려울 수 있기 때문입니다.

높은 볼륨 쓰기가 요구되는 경우 적합하지 않습니다. SQLite는 지정된 시간에 하나의 쓰기 작업만 수행할 수 있으므로 처리량이 크게 제한됩니다. 응용프로그램에 많은 쓰기 작업이 필요하거나 동시에 여러 작성자가 작업을 해야 하는 경우 SQLite는 적합하지 않습니다.

네트워크 액세스가 필요한 경우 적합하지 않습니다. SQLite는 서버리스 데이터베이스이므로 데이터에 대한 직접적인 네트워크 액세스를 제공하지 않습니다. 만약 SQLIte의 데이터가 응용 프로그램과 별도의 컴퓨터에 존재하는 경우 높은 대역폭의 네트워크가 필요합니다. 이는 비싸고 비효율적인 솔루션이며 이러한 경우에는 클라이언트-서버 DBMS가 더 나은 선택이 될 수 있습니다.

8. 마침.

이상으로 SQLite의 데이터 타입, 장단점, 사용하면 좋은 경우와 그렇지 않은 경우에 대해 알아보았습니다. 다음 글에선 MySQL에 대해 알아보도록 하겠습니다.

Loopback4에서 MongoDB에 연결하는 방법에 대해 알아봅니다.

0. 사전 준비

Loopback4 CLI를 미리 준비합니다.

다음 명령어를 통해 lb4 프로젝트를 생성한 뒤 dotenv 패키지를 설치합니다.

> lb4 project-name
> cd project-name
> npm i dotenv

프로젝트 폴더 내 .env 파일을 생성하고 다음 예시에 맞게 MongoDB 접속 정보를 작성합니다.

# MongoDB Connection Info
MONGO_HOST=localhost
MONGO_PORT=27017
MONGO_DB_NAME=admin
MONGO_USER=admin
MONGO_PASS=admin

1. MongoDB Connector 설치.

MongoDB 연결을 위해 커넥터를 먼저 설치합니다. 다음 명령어로 Loopback MongoDB Connector를 설치합니다.

> npm i loopback-connector-mongodb

2. Model 생성.

DB에 사용될 Model을 생성합니다. CLI를 사용하면 간단하게 Model을 생성할 수 있습니다. 다음 명령어를 사용해 Model을 생성합니다. 

> lb4 model

위와 같이 프롬프트를 따라 필요한 필드를 생성하는 작업을 수행하면 ./src/models/user.model.ts 파일이 자동으로 생성됩니다.

3. DataSource 생성.

앞서 생성한 모델을 이용해 DataSource를 생성할 차례입니다. 다음 명령어를 통해 DataSource를 생성합니다.

> lb4 datasource

원하시면 프롬프트에 접속 정보를 입력하셔도 됩니다. 위의 명령을 수행하고 나면 ./src/datasources/db.datasource.ts 파일이 생성되며 전 앞서 설정한 dotenv를 이용해 접속 정보를 설정해 두었습니다.

import {inject, lifeCycleObserver, LifeCycleObserver} from '@loopback/core';
import {juggler} from '@loopback/repository';
import 'dotenv/config';

const config = {
  name: 'db',
  connector: 'mongodb',
  url: '',
  host: process.env.MONGO_HOST,
  port: process.env.MONGO_PORT,
  user: process.env.MONGO_USER,
  password: process.env.MONGO_PASS,
  database: process.env.MONGO_DB_NAME,
  useNewUrlParser: true
};

// Observe application's life cycle to disconnect the datasource when
// application is stopped. This allows the application to be shut down
// gracefully. The `stop()` method is inherited from `juggler.DataSource`.
// Learn more at https://loopback.io/doc/en/lb4/Life-cycle.html
@lifeCycleObserver('datasource')
export class DbDataSource extends juggler.DataSource
  implements LifeCycleObserver {
  static dataSourceName = 'db';
  static readonly defaultConfig = config;

  constructor(
    @inject('datasources.config.db', {optional: true})
    dsConfig: object = config,
  ) {
    super(dsConfig);
  }
}

4. Repository 생성

Repository는 Model과 DataSource를 연결해주는 역할을 합니다. DB에 액세스 하기 위해선 앞서 만든 User 클래스에 대한 Repository를 생성해야 합니다. 다음 명령어를 통해 Repository를 생성합니다.

> lb4 repository

위 명령을 수행하면 자동으로 ./src/repositories/user.repository.ts가 생성됩니다.

5. Controller 생성

이제 우리의 엔드포인트를 생성할 차례가 되었습니다. 다음 명령어를 통해 controller를 생성합니다.

> lb4 controller

이번 예시에는 자동으로 추가해주는 CURD를 사용합니다. 위 명령을 수행하면 ./src/controllers/user.controller.ts가 자동으로 생성됩니다. 

6. 실행 및 테스트

이제 직접 유저를 생성해 봅시다. 다음 명령어를 통해 지금까지 만든 Loopback4 프로젝트를 실행시켜 보세요.

> npm start

이제 localhost:3000/ 으로 이동해 봅시다. 다음과 같은 화면을 확인할 수 있습니다.

Loopback4는 우리가 작성한 controller에 맞게 자동으로 API 스펙과 Explorer를 생성시켜 줍니다. 스펙은 천천히 확인하시고 explorer로 이동해 유저를 하나 생성해 봅시다.

Explorer화면에서 우리의 모든 엔드포인트를 조회할 수 있습니다.

한번 유저를 생성해 봅시다. Post /users를 클릭합니다.

Explorer에서 해당 엔드포인트에 대한 모든 정보를 확인할 수 있습니다. Input예시와 Output예시도 있으며 심지어 직접 테스트해 볼 수도 있습니다. 좌측 상단의 Try it out를 클릭합니다.

RequestBody에 적당한 값을 입력 한 뒤 Execute 버튼을 클릭합니다.

{ "email": "testuser@test.com", "password": "testuserpassword", "rgs_dt": "2020-11-12T06:21:33.035Z", "last_login_dt": "2020-11-12T06:21:33.035Z", "status": "N" }

Execute를 클릭하면 바로 아래에 Response 영역이 생성되며 Curl 명령어 및 응답 결과를 확인할 수 있습니다.

실제 제대로 들어갔는지 이번엔 Get명령을 통해 유저를 불러와 보도록 하겠습니다. Get /users로 이동해 동일하게 Try it out을 클릭해 유저를 조회해 보세요.

생성한 유저 정보를 정상적으로 불러오는 것을 확인할 수 있습니다.

우분투에 Fluentd를 설치하는 방법에 대해 알아봅니다.

0. 사전 준비

Fluentd를 설치할 우분투 환경을 미리 준비합니다. 해당 글에선 우분투 20.04 버전을 기준으로 설명합니다.

1. 설치 전 설정.

Fluentd를 설치하기 전에 이후 단계에서 문제가 발생하지 않도록 환경을 올바르게 설정할 것을 권장합니다. 공식 문서에 따르면 NTP설정, 최대 File Descriptors 숫자 설정, 네트워크 커널 매개 변수 최적화를 먼저 수행할 것을 권고합니다.

먼저 NTP를 설정해줍니다. 정확한 현재 타임 스탬프를 갖도록 노드에 chrony, ntpd 등과 같은 NTP 데몬을 설정하는 것이 좋습니다. 이는 모든 프로덕션 등급 로깅 서비스에 중요합니다. Amazon Web Services 사용자의 경우 AWS에서 호스팅 하는 NTP 서버를 사용하는 것이 좋습니다.

다음은 File Descriptors의 최대치를 늘려줘야 합니다. 만약 td-agent 패키지를 사용하는 경우이 값은 기본적으로 설정되므로 스킵하셔도 됩니다. 이 글은 td-agent를 이용할 것이므로 변경 방법만 설명한 뒤 넘어가도록 하겠습니다. 저와 동일한 방법으로 설치를 원하시는 분은 NTP 설정만 하시고 넘겨주시면 됩니다.

다음 명령어를 통해 현재 시스템의 File Descriptors의 최댓값을 확인해 줍시다. 만약 해당 값이 1024라면 수정이 필요합니다. 

$ ulimit -n

/etc/security/limits.conf 파일을 열고 다음 내용을 추가해 주세요.

$ sudo /etc/security/limits.conf

root soft nofile 65536
root hard nofile 65536
* soft nofile 65536
* hard nofile 65536

저장 후 시스템을 리부팅 시켜줍니다. 만약 systemd에서 fluentd를 실행한다면 LimitNOFILE = 65536 옵션도 사용할 수 있습니다.

Fluentd 인스턴스가 많은 고부하의 환경이라면 네트워크 커널 매개 변수 최적화가 필요합니다. 다음 구성을 /etc/sysctl.conf에 추가합니다.

net.core.somaxconn = 1024
net.core.netdev_max_backlog = 5000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_wmem = 4096 12582912 16777216
net.ipv4.tcp_rmem = 4096 12582912 16777216
net.ipv4.tcp_max_syn_backlog = 8096
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10240 65535

전 개발용으로 사용할 예정이기 때문에 네트워크 커널 매개 변수 최적화 과정도 생략하였습니다. 만약 변경사항을 적용했다면 sysctl -p 명령을 사용하거나 노드를 재부팅해야 합니다.

2. td-agent를 이용한 fluentd 설치.

td-agent는 Treasure Data, Inc.에서 관리하는 안정적인 Fluentd 배포 패키지입니다. Fluentd에서는 설치 프로세스를 자동화하기 위해 쉘 스크립트를 제공해 줍니다. /etc/apt/source.list.d/treasure-data.list에 새  apt 저장소를 등록하고 td-agent deb 설치를 시작해 봅시다.

$ curl -L https://toolbelt.treasuredata.com/sh/install-ubuntu-focal-td-agnet4.sh | sh

뭔가 자동으로 쭉 진행 되고 위처럼 맨 마지막에 Installation complete. Happy Logging!이 찍혔다면 정상적으로 설치가 된 겁니다. 이제 데몬을 실행시켜줍시다.

$ sudo service td-agent start
$ sudo service td-agent status

3. HTTP를 통해 샘플 로그 업로드 해보기.

이제 샘플 로그를 한번 올려보겠습니다. 엔드포인트의 기본 포트는 8888입니다. 다음 명령어를 통해 설정값을 조회할 수 있으며 원하시면 여기서 변경할 수 있습니다.

$ vim /etc/td-agent/td-agent.conf

이제 HTTP 엔드포인트에서 로그를 수신해 stdout으로 라우팅 해보도록 하겠습니다. 다음 명령어를 확인해 주세요. td-agent 로그의 경우 /var/log/td-agent/td-agnet.log를 참고하시면 됩니다.

$ curl -X POST -d 'json={"json":"message"}' http://localhost:8888/debug.test
$ tail -n 1 /var/log/td-agent/td-agent.log

로그를 정상적으로 확인할 수 있습니다.

이 글은 다음 글을 번역한 글입니다: Logstash vs Fluentd — Which one is better!

LogStash와 Fluentd에 대해 알아보며 유사점과 차이점에 대해 알아보고 어떤 로그 수집기가 대상 프로젝트에 더 어울리는지 알아봅니다.

0. 앞선 글.

로그를 수집하고 Elastic stack로 전달하고자 할 때 우리는 일반적으로 ELK - Elastic, Logstash, Kibana를 듣게 됩니다. 이제 ELK는 Elastic stack와 동의어가 되었을 정도입니다. 하지만 기술적으로 그 어디에도 완벽한 솔루션은 존재하지 않습니다.

Fluentd는 Docker나 Kubernetes 환경과 같은 마이크로 서비스의 로깅에 대해 인기를 끌고 있습니다. 이는 Fluientd가 Treasure Data에 의해 구축되었고 CNCF의 일부이기 때문입니다. 따라서 Fluentd는 Kubernetes, Prometheus, OpenTracing과 같은 CNCF 호스팅 프로젝트들과 훨씬 더 어울립니다.

최근 프로젝트에 대해 이 두 로그 수집기에 대해 평가할 일이 있었고 두 분석기에 대한 장단점을 조사한 뒤 어떤 사례에 어떤 로그 분석기가 더 적합한지 결정할 수 있었습니다. 이 비교의 목적은 둘 중 어떤 로그 분석기가 더 우월한지 선택하는 것이 아니라 어떤 사용 사례에 어떤 로그 분석기가 더 적합한지 찾는 것입니다.

1. LogStash와 Fluentd의 비교.

A. 보증

Logstash는 인기 있는 ELK stack의 일부이며 Fluentd는 Treasure Data에 의해 구축되었고 CNCF의 일부입니다. 

Fluentd 역시 Eleastic에 대해 훌륭한 지원을 제공합니다. Kubernetis, OpenTascing, Prometheus와 같은 CNCF 호스팅 프로젝트에서는 Fluentd가 더 좋은 선택이 될 수 있습니다.

B. 코드 언어

Logstash는 호스트에 자바 런타임이 필요한 JRuby입니다. Fluentd는 자바 런타임이 필요하지 않은 CRuby입니다.

Fluentd는 자바 런타임이 필요하지 않다는 이점이 있습니다.

C. 이벤트 라우팅.

Logstash는 if-else 조건에 기반에 이벤트가 라우팅 됩니다. 예를 들자면 다음과 같습니다.

output { if [loglevel] == "ERROR" and [development] == "production" { { ... } }

Fluentd는 태그에 기반해 이벤트가 라우팅 됩니다. 예를 들자면 다음과 같습니다.

<match logtype.error> type ... </match>

이벤트에 태그를 지정하고 각 이벤트 유형에 대해 if-else를 사용하는 것이 더 쉽기 때문에 Fluentd가 더 나은 라우팅 접근 방식을 제공합니다. 만약 로그에 다른 종류의 타입이 많아진다면 Logstash는 관리하기가 쉽지 않을 것입니다.

D. 플러그인

Logstash는 200개 이상의 플러그인이 존재하며 Fluentd는 500개 이상의 플러그인이 존재합니다.

Logstash는 공식 git 저장소에 모든 플러그인을 가지고 있지만 Fluentd에는 아직 플러그인에 대한 중앙 git 저장소가 없습니다.

E. 성능

LogStash는 Fluentd보다 상대적으로 좀 더 많은 메모리를 사용합니다.

Fluentd가 약간 wrt 성능에 대해 약간 더 나은 평가를 받고 있습니다. 하지만 두 로그 수집기 모두 가벼운 수준이며 성능 측면에서 두 로그 수집기 모두 우수합니다.

F. 전송

Logstash는 메모리 상의 큐에 고정된 크기인 20개의 이벤트를 갖고 있으며 재시작 시 지속성을 위해 Redis 또는 Kafka와 같은 외부 큐에 의존합니다. Fluentd는 고도로 구성 가능한 버퍼링 시스템을 보유하고 있으며, 메모리상에 또는 디스크에 끝없는 배열로 구성될 수 있습니다.

OpenStack Summit 2015에서 이 강연에서 논의된 바와 같이, 둘 다 대부분의 사용 사례에서 잘 수행되고 10,000 개 이상의 이벤트를 문제없이 지속적으로 수행할 수 있습니다.

E. 엔터프라이즈급 지원

LogStash와 Fluentd 모두 지원합니다. 

LogStash가 공식적인 Elastic 스택의 일부이므로 LogStash의 지원이 더 낫습니다.

2. 사용 사례.

A. 로그 수집

Fluentd는 Docker에 Fluentd용 로깅 드라이버가 내장되어 있습니다. 즉, Fluentd에 로그를 푸시하기 위해 컨테이너에 추가 에이전트가 필요하지 않습니다. 로그는 STDOUT에서 Fluentd 서비스로 직접 전송되며 추가 로그 파일이나 영구 저장소가 필요하지 않습니다. 단지 docker-compose 파일에 다음과 같은 섹션을 추가해주면 됩니다.

logging: driver: "fluentd" options: fluentd-address: <fluentd IP>:<fluentd service port> tag: testservice.logs

Logstash의 경우 STDOUT의 애플리케이션 로그는 도커 로그에 기록되고 파일에 기록됩니다. 그런 다음 파일의 로그를 filebeat와 같은 플러그인을 통해 읽어서 Logstash로 보내야 합니다.

B. 로그 파싱.

Fluentd에는 json, regex, csv, syslog, apache, nginx 등과 같은 표준 내장 파서와 로그를 파싱 하는 grok과 같은 외부 파서가 있습니다.

Logstash에는 표준 형식 외에도 집계, geoip 등과 같은 필터링 및 구문 분석을 위한 더 많은 플러그인이 있습니다.

C. 메트릭 데이터 수집.

Fluentd는 시스템 / 컨테이너 측정 항목을 수집하는 즉시 사용할 수 있는 기능이 없습니다. 그러나 Prometheus exporter에서 메트릭을 스크랩 할 수 있습니다.
Logstash는 시스템 / 컨테이너 메트릭을 수집하고 이를 Logstash로 전달하는 즉시 사용 가능한 Metricbeat를 지원합니다. 또한 Logstash는 Prometheus exporter에서 메트릭을 스크랩 할 수도 있습니다.

D. 스크랩

Fluentd에는 메트릭, 상태 확인 등과 같이 http 엔드 포인트에서 데이터를 가져올 수있는 http_pull 플러그인이 있습니다.
Logstash에는 http 엔드 포인트에서 데이터를 가져올 수있는 Elastic에서 지원하는 http 플러그인이 있습니다.

3. 그러면 무엇을 이용해야 할까요?

위의 사용 사례를 살펴보면 Fluentd와 Logstash가 특정 요구 사항에 적합하다는 것이 분명합니다. 가장 좋은 점은 둘 다 동일한 환경에서 공존할 수 있으며 특정 사용 사례에 사용할 수 있다는 것입니다.

기존 VM의 모놀리틱 한 애플리케이션의 경우 로그, 메트릭, 상태 등의 수집을 위해 여러 에이전트를 지원하므로 LogStash가 확실한 선택처럼 보입니다. 

Docker 및 Kubernetes에서 호스팅 되는 마이크로 서비스의 경우에는 Fluentd가 기본 제공 로깅 드라이버와 원활한 통합을 고려할 때 훌륭한 선택으로 보입니다. json, nginx, grok 등과 같이 일반적으로 사용되는 모든 파서를 지원하기도 합니다.

ELK-EFK 하이브리드 구조에서는 아래와 같이 두 로그 수집기를 동시에 사용하여 지원할 수 있습니다. 

이 글이 혼란을 줄이고 더 나은 결정을 내리는 데 도움이되기를 바랍니다.

Object storage에 파일 조회하고 업로드하는 방법에 대해 알아봅니다.

0. 사전 준비.

AWS S3든 뭐든 오브젝트 스토리지를 준비합니다. 단, AWS SDK를 사용할 예정이기 때문에 S3 Compatible 한 오브젝트 스토리지를 준비해야 합니다. 

만약 준비된 오브젝트 스토리지가 없다면 다음 글을 참고해 Minio를 준비해 봅시다.

2020/10/21 - [Programming] - [MINIO] 시놀로지 NAS에서 MINIO를 이용해 오브젝트 스토리지 구성하기

2020/10/23 - [Programming] - [Minio] Minio Object Stroage에 Region 지정하기.

IDE는 Visual Studio 2019 CE를 사용하였으며 AST.NET Core 버전은 3.0을 사용했습니다.

1. 솔루션 및 프로젝트 생성.

VS를 열고 새 프로젝트를 생성합니다. C# - ASP.NET Core 웹 애플리케이션을 선택합니다.

프로젝트 탬플릿은 API를 선택합니다. 

디버그를 시작해 시작화면을 확인합니다. 기본적으로 자동 생성되는 컨트롤러인 WeatherForecast 컨트롤러에서 데이터를 보여주고 있을 겁니다.

2. Nuget 패키지 추가하기.

S3 compatible Object Storage를 사용하므로 우선 ASW SDK를 설치해 줍니다. Nuget을 통해 AWSSDK.Core와 AWSSDK.S3를 먼저 설치해 줍니다. 그리고 추후 구현할 파일 리스트 조회를 위해 Json 관련 패키지도 같이 설치해 줍니다.

3. 컨트롤러 추가 및 파일 업로드 구현.

프로젝트를 우클릭해 컨트롤러를 추가합니다. "읽기/쓰기 작업이 포함된 api 컨트롤러 클래스"를 선택하면 기본인 예시 GET/POST/DELETE 메서드가 추가되어 있습니다. 어차피 새로 코딩해야 하니 "API 컨트롤러 클래스 - 비어있음"을 선택해 컨트롤러를 생성해 줍니다.

ASP.NET Core 코드에 대해선 자세히 설명하지 않도록 하겠습니다. 우선 S3 Client를 생성하고 POST로 업로드를 하는 메서드를 만들어보겠습니다.

using Amazon;
using Amazon.S3;
using Amazon.S3.Transfer;
using Microsoft.AspNetCore.Mvc;
using System;
using System.IO;
using System.Linq;
using System.Threading.Tasks;

namespace S3StorageManager.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class S3FileController : ControllerBase
    {
        private const string _storageEndpoint = "https://your.host.here";
        private const string _accessKeyId = "youraccesskeyidhere";
        private const string _secretAccessKey = "yoursecretaccesskeyhere";
        private readonly AmazonS3Config _s3Config = new AmazonS3Config()
        {
            RegionEndpoint = RegionEndpoint.APNortheast2,
            ServiceURL = _storageEndpoint,
            ForcePathStyle = true
        };

        [HttpPost("upload")]
        public async Task<ActionResult> Upload()
        {
            var req = HttpContext.Request;
            var form = req.Form;
            string fileName = form["filename"];
            string bucketName = form["bucketname"];
            try
            {
                using (var client = new AmazonS3Client(_accessKeyId, _secretAccessKey, _s3Config))
                {
                    using (var ms = new MemoryStream())
                    {
                        form.Files.First().CopyTo(ms);
                        var uploadReq = new TransferUtilityUploadRequest();
                        uploadReq.InputStream = ms;
                        uploadReq.Key = fileName;
                        uploadReq.BucketName = bucketName;
                        uploadReq.CannedACL = S3CannedACL.PublicRead;
                        var fileTransferUtil = new TransferUtility(client);
                        await fileTransferUtil.UploadAsync(uploadReq);
                        return Ok();
                    }
                }
            }
            catch(Exception e)
            {
                return StatusCode(500, e.Message);
            }
        }
    }
}

소스코드를 위에서부터 찬찬히 봅시다. 먼저 Endpoint, AccessKeyId, SecretAccessKey를 지정해 줍니다.

그리고 S3 Client를 위한 Config를 생성합니다. _s3Config의 RegionEndpoint는 S3의 Region을 의미합니다. 앞서 지정한 Minio Storage의 Region을 입력해 주세요. ServiceURL은 Endpoint를 의미합니다. 우리는 아마존의 S3 경로를 사용하지 않기 때문에 Minio의 Endpoint값을 입력해 줍니다. ForcePathStyle은 AWS SDK로 Minio를 개발하기 위해 반드시 True값으로 설정되어 있어야 합니다.

POST로 upload요청이 오면 Upload가 호출됩니다. 먼저 요청의 form으로부터 저장될 파일 이름과 버킷 이름을 받아옵니다. 그 후 미리 정의한 키값들과 설정값으로 S3 Client를 만든 뒤 MemoryStream에 form내의 파일을 복사합니다. 그 후 업로드 요청에 파일, 파일 이름, 버킷 이름을 지정한 뒤 UploadAync로 파일 업로드를 시도합니다.

바로 테스트를 시도해 봅시다. 먼저 코드를 실행시킨 뒤 Postman과 같은 프로그램을 이용해서 POST 요청을 날려봅시다.

위와 같이 POST 요청을 준비합니다. 엔드포인트는 호스트, 디버그 포트, 컨트롤러를 이용해 자신의 환경에 맞게 수정해 줍니다. filename은 버킷에 저장될 파일의 이름이고 bucketname은 파일이 저장될 버킷의 이름입니다. file은 아무거나 업로드 할 파일을 골라주세요.

다 작성했다면 Send 버튼을 클릭해 파일 업로드를 시도합니다. 200OK와 함께 업로드에 성공한 것을 확인할 수 있습니다. 만약 HTTPS로 인해 문제가 생긴다면 Postman에서 https를 이용하지 않도록 하는 옵션이 있으니 참고해 주세요. 

이후 브라우저를 통해 정상적으로 업로드 한 파일을 확인할 수 있습니다.

4. 버켓 내 파일 조회하기.

이제 업로드를 하였으니 업로드 한 파일을 조회하는 방법에 대해 알아봅니다. 컨트롤러 클래스에 다음 코드를 추가해 주세요.

// 중간 생략...
using Newtonsoft.Json;
using System.Collections.Generic;
// 중간 생략...
        [HttpGet("GetFileList")]
        public async Task<ActionResult> GetFileList()
        {
            var req = HttpContext.Request;
            var form = req.Form;
            string bucketName = form["bucketname"];
            try
            {
                using (var client = new AmazonS3Client(_accessKeyId, _secretAccessKey, _s3Config))
                {
                    List<Dictionary<string, string>> listS3Objs = new List<Dictionary<string, string>>();
                    var listObjectsResponse = await client.ListObjectsAsync(bucketName);
                    foreach (var obj in listObjectsResponse.S3Objects)
                    {
                        Dictionary<string, string> dicObjInfo = new Dictionary<string, string>();
                        dicObjInfo["Bucket"] = obj.BucketName;
                        dicObjInfo["Key"] = obj.Key;
                        dicObjInfo["Size"] = Convert.ToString(obj.Size);
                        dicObjInfo["Tag"] = obj.ETag;
                        dicObjInfo["Modified"] = obj.LastModified.ToString("yyyyMMddHHmmss");
                        dicObjInfo["Owner"] = Convert.ToString(obj.Owner);
                        dicObjInfo["StorageClass"] = obj.StorageClass;
                        listS3Objs.Add(dicObjInfo);
                    }
                    string jsonResult = JsonConvert.SerializeObject(listS3Objs);
                    return Ok(jsonResult);
                }
            }
            catch (Exception e)
            {
                return StatusCode(500, e.Message);
            }
        }

그다지 어렵지 않습니다. 아까와 같이 S3 클라이언트를 생성하고 bucketName을 이용해 오브젝트 리스트를 가져옵니다. 가져온 정보는 Dictionary를 이용해 구조화하고 List에 넣어둡니다. 그 후 모든 파일을  JSON으로 변경해 리턴하는 게 전부입니다.

만약 버킷 이름이 공백이면 다음과 같은 에러 메시지를 리턴합니다.

BucketName is a required property and must be set before making this call. (Parameter 'ListObjectsRequest.BucketName')

또한 존재하지 않는 버킷 이름을 전송한다면 다음과 같은 에러 메시지를 리턴합니다.

The specified bucket does not exist

이제 테스트를 해봅시다. 다시 Postman을 열고 다음과 같이 GET 요청을 작성합니다.

요청 주소를 자신의 환경에 맞게 수정한 뒤 bucketname을 파일을 업로드한 버킷 이름으로 설정해 준 뒤 Send 버튼을 클릭합니다.

[{"Bucket":"test-0","Key":"uploadtest.txt","Size":"11","Tag":"\"06e0e6637d27b2622ab52022db713ce2\"","Modified":"20201023135946","Owner":"Amazon.S3.Model.Owner","StorageClass":"STANDARD"}]

JSON 포맷으로 결과를 잘 받아오는 걸 확인할 수 있습니다.

Minio Object Stroage에 Region 지정하는 방법에 대해 알아봅니다.

0. 사전 준비.

미리 Minio를 준비합니다. Minio 설치 방법은 다음 글을 참고해 주세요:

2020/10/21 - [Programming] - [MINIO] 시놀로지 NAS에서 MINIO를 이용해 오브젝트 스토리지 구성하기

1. Region? 왜 필요한가.

위의 글과 같이 Minio를 설치해 웹브라우저나 Object Storage Explorer를 사용해 Minio를 사용한다면 별문제 없이 사용할 수 있습니다. 하지만 프로그램을 개발하다 AWS SDK를 사용해 Minio에 접근하려고 한다면 아마 대부분이 "그래서 Region은 뭘 골라야 해?"라는 의문을 가지실 겁니다.

물론 S3Client를 생성할 때 S3 config를 이용해 초기화를 시키면 Endpoint만 바꾼 채 클라이언트를 생성할 수 있습니다. 문제는 이 클라이언트를 이용해 버킷에 접근하다 보면 알려진 호스트가 없다는 에러를 마주하게 될 수 있다는 점입니다.

따라서 이 글에서는 AWS SDK를 이용해 Minio에 접근하는 프로그램을 만들기 전에 우리의 Minio에 Region을 지정하는 방범에 대해 알아보도록 하겠습니다.

2. Minio에 Region 지정하기.

Docker container로 Minio를 사용한다면 Region을 지정하는 방법은 매우매우 간단합니다. 이 글에선 Synology NAS의 Docker를 이용해 Minio를 설치했다는 전제로 설명합니다.

먼저 DSM > Docker > 컨테이너로 이동해 Minio 컨테이너를 잠시 중지시킵니다. 이후 Minio 컨테이너를 클릭 > 편집 > 환경 탭으로 이동합니다. 그리고 "MINIO_REGION" 변수를 추가합니다.

값에는 자신이 원하는 Region값을 넣어줍니다. 제가 넣어준 ap-northeast-2는 서울 지역을 의미합니다. 이제 이 값을 저장한 뒤 Minio 컨테이너를 실행시켜주면 됩니다.

ORA-12516 tns:listener could not find available handler with matching protocol stack. 

ORA-12516  tns:리스너가 프로토콜 스택과 일치하는 처리기를 찾을 수 없습니다.

1. 현상

개발 환경에선 발생하지 않다가 배포 환경에서 프로그램을 올리던 중에 몇몇 프로그램이 시작과 동시에 죽는 문제가 발생했습니다. 로그를 확인해보니 Oracle DB 접속 문제였으며 Oracle 로그를 확인한 결과 ORA-12516 tns:listener could not find available handler with matching protocol stack. 와 같은 에러 로그가 찍혀있었습니다.

2. 원인

가장 대표적인 원인은 오라클 DB에 붙을 수 있는 프로세스 혹은 세션의 개수가 최대치에 도달한 것. 이미 접속되어 있는 것은 잘 동작하지만 새로운 프로그램이 DB에 접속할 때 DB는 이미 자신이 허용할 수 있는 연결의 최대치에 도달했기 때문에 에러를 반환하는 현상입니다.

3. 수정

현재 DB 설정값을 먼저 확인해줍시다. SYSDBA 계정으로 로그인 한 뒤 다음 쿼리를 실행해 주세요.

SELECT RESOURCE_NAME, CURRENT_UTILIZATION, MAX_UTILIZATION, LIMIT_VALUE FROM V$RESOURCE_LIMIT WHERE RESOURCE_NAME IN ('processes', 'sessions');

제 상황의 경우 결과가 모두 LIMIT_VALUE에 근접해 있어 추가적인 프로그램을 실행하면 오라클 에러가 발생하던 상황이었습니다. 따라서 다음 명령어를 통해 processes의 개수와 sessions의 개수를 늘려 주었습니다.

ALTER SYSTEM SET PROCESSES = NNN SCOPE = SPFILE;
ALTER SYSTEM SET SESSIONS = NNN SCOPE = SPFILE;
* NNN에 원하는 수치를 넣으시면 됩니다.

"System SET이(가) 변경되었습니다."라는 메시지를 확인하신 뒤 DB 서비스를 재시작해 줍니다. 이후 정상 동작을 확인하였습니다.