No Image

개발자를 위한 SSD (Coding for SSD) – Part 3 : 페이지 & 블록 & FTL(Flash Translation Layer)

2016-07-16 KENNETH 0

개발자를 위한 SSD (Coding for SSD) – Part 3 : 페이지 & 블록 & FTL(Flash Translation Layer) 이번 챕터에서는 데이터 쓰기가 Block과 Page 레벨에서 어떻게 처리되는지, 그리고 쓰기 시에 발생하는 “Write Amplication”과 “Wear Leveling”의 기본적인 개념을 살펴보도록 하겠다. 추가로 FTL(Flash Translation Layer)이 무엇인지, 그리고 FTL의 2가지 목적인 논리적 블록 맵핑(Logical Block Mapping, 여기에서는 Hybrid Log Block Mapping 위주로)과 Garbage-collection도 같이 살펴볼 것이다. 3. 기본 오퍼레이션 3.1. 읽기 & 쓰기 & 삭제(Erase) NAND 플래시 메모리의 구성 특성상, 특정 셀을 단독으로 읽고 쓰는 작업은 불가능하다. 메모리는 그룹핑되어 있으며, 아주 특별한 방법으로만 접근할 수 있다. 그래서 NAND 플래시 메모리의 특별한 방법을 숙지하는 것은 SSD의 데이터 구조를 최적화하고 작동 방식을 이해하는데 있어서 꼭 필요한 부분이다. 이번 섹션에서는 SSD의 읽고 쓰기 그리고 삭제(Erase) 오퍼레이션이 실행되는 방법들을 살펴 보도록 하겠다. 읽기는 페이지 사이즈 단위로 실행(Reads are aligned on page size) 한번에 하나의 페이지보다 작은 크기의 데이터를 [ more… ]

No Image

개발자를 위한 SSD (Coding for SSD) – Part 2 : SSD의 아키텍처와 벤치마킹

2016-07-15 KENNETH 1

개발자를 위한 SSD (Coding for SSD) – Part 2 : SSD의 아키텍처와 벤치마킹 이 챕터에서는 NAND 플래시 메모리의 기본적인 내용과 셀 타입 그리고 SSD의 기본적인 내부 아키텍처에 대해서 살펴보고, 추가로 SSD의 벤치마킹 방법과 벤치마킹 결과를 해석하는 부분도 살펴보도록 하겠다. 1. SSD의 구조 1.1. NAND 플래시 메모리 셀 SSD(Solid-State Drive)는 플래시 메모리를 기반으로한 저장 매체이다. 비트들은 Floating-Gate 트랜지스터로 구성된 셀에 저장된다. SSD는 모든 컴포넌트가 전기 장치이며, HDD와 같은 기계 장치를 가지고 있지 않다. Floating-Gate 트랜지스터에 전압이 가해지면서 셀의 비트가 쓰여지거나 읽혀지게 된다. 트랜지스터는 NOR 플래시 메모리와 NAND 플래시 메모리 두 종류가 있는데(여기에서는 NAND의 NOR 플래시 메모리의 차이에 대해서 깊이 있게 살펴보지는 않을 것이다), 이 게시물에서는 많은 제조사들이 채택하고 있는NAND 플래시 메모리에 대해서만 살펴보도록 하겠다. NAND와 NOR 플래시 메모리의 상세한 차이에 대해서 궁금하다면, Lee Hutchinson1의 문서를 살펴보도록 하자. NAND 플래시 메모리 모듈의 중요한 속성은 수명이 제한적(Wearing-off)이라는 것이다. 트랜지스터는 셀에 전자를 저장하면서 쓰기를 [ more… ]

No Image

개발자를 위한 SSD (Coding for SSD) – Part 1 : 목차

2016-07-14 KENNETH 0

개발자를 위한 SSD (Coding for SSD) – Part 1 : 목차 Introduction 현재 개발중인 Key/Value Store 가 SSD를 최적으로 사용하도록 하기 위해서는 SSD의 내부적인 특성이나 작동 방식에 대해서 정확한 이해가 필요했다. 인터넷에는 이미 많은 SSD 관련 자료들이 있지만, 대 부분은 부족하거나 잘못된 정보들이 많으며, 제대로 정리된 문서를 찾기는 쉽지 않았다. 결국 내 프로그램이 SSD를 최적으로 사용하도록 하기 위해서는 상당히 많은 문서들과 벤치마크 자료들을 찾고 살펴 봐야 했다. 내가 알게 된 사실들과 결론이, 다른 사람들에게도 많은 도움이 될 것이라는 생각을 하게 되었고 그래서 이미 온라인에 공개된 많은 정보들을 30 페이지 분량의 실용적인 지식을 담은 글을 쓰게 되었다. 단순히 블로그에 올릴 수 있는 분량이 아니어서, 좀 더 압축할 수 있는 수준으로 내용을 분류하여 5개의 챕터로 분류하였다. 전체 목차는 이 글의 아래에서 확인할 수 있다. “Coding for SSDs”의 요약 정보를 담고 있는 Part 6 는 가장 중요한 부분인데, 이는 아마도 급하게 SSD 관련 [ more… ]

No Image

kakao 기술 블로그가 GitHub Pages로 간 까닭은

2016-07-08 KENNETH 0

kakao 기술 블로그가 GitHub Pages로 간 까닭은 kakao 기술 블로그는 올해 초 Ghost 블로깅 플랫폼을 사용해서 오픈했으나, 최근 GitHub Pages와 Jekyll으로 바뀌었습니다. 이 글에서는 kakao 기술 블로그를 GitHub Pages로 옮기면서 Jekyll에 위해 추가한 기능들 – 태그별 포스트 목록 페이지, 작성자별 포스트 목록 페이지, 사이트맵 – 을 소개합니다.

ADT 활용 예제1: MySQL Shard 데이터 재분배

2016-07-02 KENNETH 0

ADT 활용 예제1: MySQL Shard 데이터 재분배 샤딩의 한계 카카오의 많은 서비스들이 데이터베이스로써 MySQL을 사용합니다. 그리고 서비스 규모가 커지면 대용량 분산을 위해 샤딩을 합니다. 카카오에서 많이 사용하는 샤딩 방법으로 크게 두 가지 방식이 있습니다. range-based sharding modulus-based sharding 그러나 두 방법 모두 한계가 있습니다. Range 방식의 한계 특정 ID값을 기준으로, ID 범위에 따라 샤드를 나누는 방식입니다. ID값이 증가하는 추이를 보고서 새로운 샤드 추가가 쉽다는 장점이 있습니다. 반면에 디스크 사용량이나 쿼리 처리량의 밸런스가 많이 안 맞는 경우가 발생하기도 합니다. 아래 그림과 같이 User ID 기준, Range 방식으로 샤딩을 적용한 어떤 서비스가 있다고 가정하겠습니다. 초창기 샤드는 데이터량이 아주 많고 최근에 추가된 샤드는 다른 쿼리 처리량이 매우 많습니다. 그리고 간혹 초창기 사용자들의 충성도가 높은 서비스의 경우, 초기에 추가한 샤드들도 쿼리량이 적지 않은 경우가 있습니다. Modulus 방식의 한계 [ID값] % [샤드 개수]의 결과 값으로 샤드 위치를 결정하는 방식입니다. Range 방식에 비해 리소스 사용 밸런스가 [ more… ]