기본 콘텐츠로 건너뛰기

라떼는 DAS, SAN, NAS란게 있었단다..




요즘 AI, AI만 이야기 하고 있잖아요? 
저도 AI를 활용한 여러가지 비즈니스를 준비는 하고 있지만, 

오히려 이렇게 AI도배된 시기에 역행하는 라떼는 코너를 한 번 만들어보고 싶었습니다.
요즘 IT에 들어온 사람들은 모두 클라우드 환경이 기본이다보니 
실제로 디스크를 본 적도 없는 사람도 있고 하더라구요.. 

아마 이젠 쓸모 없는 내용이 될 수도 있겠지만,
기록을 위해 남기는 것이니 흥미가 있는 분들만 들어주시면 됩니다,.

2000년대까지만 해도 데이터센터를 회사마다 작게는 1/4랙이나 1U단위에서 많게는 Cage라고 해서 24랙 정도 까지 직접 계약을 했었기 때문에 데이터센터를 관리하는 일이 참 많았었죠.

 그 때는 고객들이 인터넷상에 서비스를 올리고자 하는데 서버구성까지 맡기는 경우가 많았습니다.  그래서 많은 서버나 장비들을 만져보고 테스트도 했었지요.

 그 때 당시엔 하드 용량도 20GB나 80GB가 주력 이다보니 온라인 게임이 급격하게 성장했던 시기에 너무 데이터 저장 공간이 부족했죠.

데이터센터를 못가보신 분들도 많겠지만 이 때는 개발자도 데이터센터 달려가서 작업하던 때도 많았죠.. 
서버 랙을 열어보면 서버만 있는것도 아니고 별의 별 짓을 다해놓곤 하는데요.. 
랙 안에 자기 작업 공간처럼 황당하게 꾸민 경우도 있었는데 그 때는 사진을 안찍어놨네요.. 

랙 안에서 가장 신기한게 디스크들이 아주 많은 케이스였는데요.. 

 이 때 DAS나 SAN, NAS를 효율적으로 사용해서 데이터 관리를 했습니다.
 요즘 클라우드 시대에는 HDD, SSD를 쓸거냐 S3를 쓸거냐 정도인데요.. 
 이들도 하드웨어는 SAN이나 NAS를 쓸 겁니다. 그게 서비스로 올라와서 저렇게 불리는 거죠.

 요즘 세대에서는 개발자라고 들어왔지만 이 개념을 정확하게 몰라서 개발 피씨에서는 잘되던게 서버에만 올리면 안되요 하면서 premium ssd로 변경해서 요금 폭탄을 맞곤 하죠. 
 Aws에서 프리미엄 ssd보다 더 폭탄인게 있죠. instance store 서비스가 있는데.. 




이건 인스턴스에 붙어있는 로컬 HDD를 사용하기 때문에 속도가 충분히 나오죠. 보통 여기까진 안찾지만 확장 불가능한 설계에서 디스크io를 올리려면 별 수 없이 써야만 하죠.
참고로 instance store는 부르는게 값이다보니 pricing calculator엔 없습니다. 
직접 전화로 신청해야 해요.. 




아뭏든... 

 우선 디스크 제품들의 하드웨어적인 구성 차이를 알려드리겠습니다.

 일반적인 물리 서버에 용량이 부족할 때 붙이는게 DAS즉 direct attached storage가 되죠. 다이렉트로 scsi 케이블로 연결하기 때문에 서버에 로컬로 붙이는 것과 같은 성능과 특성을 가지고 있습니다. 두꺼운 케이블이 특징이지요... 




 속도가 가장 빠른 대신 다른 서버들과 쉐어가 안되죠.
 하지만 이게 발전되면서 OS를 탑재 가능한 das server라는게 나오면서 서버 따로 디스크 어레이 따로 살 필요 없이 한 대로 용량 큰 서버를 쓸 수 있게 되었습니다.
 하지만 이렇게 붙이면 다른 서버도 용량이 부족할 때마다 das를 붙이기엔 인클로저 비용이 너무 들어서 여러 서버들이 쉐어 하는 방식을 생각했죠.
 이게 NAS, network attached storage 가 나왔습니다. 전용 OS가 들어 있어 네트워크 프로토콜과 디스크 컨트롤러가 최대한 디스크 쉐어를 잘하기 위해서 만들었데, 속도가 너무 느리더랍니다. 
NAS는 OS가 네트워크 파일 전송 프로토콜로 주고 받아야 하기 때문에 NFS라는 파일 시스템 포맷을 쓰고, 이들은 파일 단위로 주고 받아야 하기 때문에 오브젝트 중심이라 오브젝트 파일 시스템이라고 합니다. 
파일을 전송에만 쓰고, 기본적으로 많은 경로를 거쳐 주고받다보니 너무 느려서 여러 서버가 로컬처럼 나눠쓸 수 있는 구조가 필요했죠. 
그래서 SAN을 도입합니다. SAN은 Storage Area Network라고 하여 스토리지 전용 네트워크 상에 올리는 스토리지를 이야기 합니다 때문에 전용 네트워크 장치와 스토리지 장비를 같이 세트로 준비하게 되구요, 
이 전용 네트워크 장비로 iSCSI방식이나 Infiniband방식으로 나뉩니다. 
SAN으로 100GB짜리 디스크 100장을 넣은 스토리지를 구성하면 이 네트워크를 연결한 서버들은 자기가 마음대로 할당할 영역을 나누는데요.. 어떤 서버에는 50GB만, 또 어떤 서버는 1TB를 넣어줄 수 있죠.. 
위의 DAS로는 할 수 없었던 로컬 스토리지를 SAN은 자유롭게 쪼개주고 받고 할 수 있네요.. 
NAS는 여러 서버가 동일 파일이나 디렉토리를 쉐어할 수 있지만, SAN은 쉐어는 안되고 하나의 스토리지를 잘게 쪼개서 여러 서버가 자기네 로컬 스토리지 처럼 쓸 수 있고, 이게 바로 SCSI나 Fiber Channer로 연결하기 때문에 속도는 로컬보다 빠르기도 합니다. 

그런데 가장 큰 문제가 있지요.. 
돈이 수억 깨진다는 이야기 입니다 
광섬유를 이용한 SAN전용 네트워크 장비만 거의 3000만원을 웃돌고 거기에 SAN용 스토리지는 더 비쌉니다 .
그래서 정말 돈을 쳐바르더라도 속도와 안전성이 중요한 경우 외에는 쓸 수가 없었죠.. 
참고로 DAS는 케이블이 몇 만원 정도로 생각보다 비싸지 거의 디스크 가격 정도 입니다. 

NAS도 요즘은 너무 저렴해서 개인 NAS많이 쓰고 있죠?
SAN만 미치도록 비쌌지만, 워낙 데이터 보완 기능이 강력하다보니 2000년대의 금융이나 대기업에선 필수였고, 지금도 사용하는 곳들이 꽤 남아있습니다. 

쓰임새를 보면 금융이나 대기업, 국가 프로젝트에는 SAN이 많았고, 
중소기업이나 개인들의 개별 파일 쉐어는 NAS를.. 
그리고 중소 기업에서는 서버에 DAS를 붙여 거기서 다시 NAS를 올려 쉐어하기도 했습니다. 

이제는 클라우드화 되어 내부가 어떻든 파일 단위 공유하는 NAS방식은 Object Storage라고 하고, SAN이든 DAS든 로컬 스토리지 처럼 인식되면 Block Storage라고 하지요.. 
우리 때 처럼 DAS, NAS, SAN을 만지고 다니는 사람들은 기본 구조를 알기 때문에 클라우드 인프라에 문제가 생겨도 구조를 아니까 뭐때문에 안되겠네 하는 이야기를 할 수가 있지요. 
이건 SAN보다는 Ethernet을 이용한 ZFS일지도 몰라 라던가 하면서 성능을 짐작하기도 합니다. 

이렇게 디스크를 수십장 넣은 디스크어레이는 raid구성이 꼭 필요한데요.. 
초기에는 디스크가 비싸서 용량을 최대한 사용하려는 RAID5가 주류였고, 
디스크가 2장 밖에 없다거나 OS용 디스크면 RAID1이 주류 였죠. 
 
그러다가 디스크가 저렴해지는 시대가 오면서 
RAID5를 쓸바엔 RAID10을 써도 예산에 문제가 없어지면서 RAID10이 기본이 되었지요. 
RAID5로 10GB짜리 디스크 6장을 묶게 되면 50GB짜리 디스크 하나만 나옵니다. 
이걸 RAID10을 쓰게 되면 30GB로 용량은 줄어들지만 RAID5일때 읽기가 5배 쓰기가 1배였던게, 
RAID01이 되면 읽기쓰기 모두 3배가 됩니다. 
검색엔진등 읽기 전용이라면 RAID5가 아직도 좋지만
온라인 게임등의 OLTP가 주류인 경우는 쓰기에 병목이 자주 발생하기 때문에 RAID10만한게 없죠. 

그런데!

2000년대 보드에는 RAID를 10으로 잡아주는 보드는 나중에 나오고 초창기에는 RAID 1로 묶은 뒤에 RAID 0으로 다시 묶는 경우가 많았습니다. 
디스크가 24장인 경우 RAID10으로 전체를 묶을 때 
2장씩 RAID1로 묶고 그 뒤에 12셋트를 RAID 0 으로 묶는게 보통이죠. 
저의 경우는 이걸 4세트씩 RAID 0 으로 묶어 볼륨을 세 개로 하는데요.. 이게 안전한 구성이구요.. 
통으로 묶으면 안정성은 떨어지지만 속도는 좋아지지요.. 

이 때 누가 RAID 0으로 12장씩 두 묶음을 한 뒤에 RAID 1로 묶은 것을 봤는데.. 
제가 혼을 냈습니다. 
왜 이렇게 하면 안될까요? 

RAID 0 은 stripe라고 해서 디스크를 직렬로 엮어서 데이터를 저장하는 방식입니다. 
만약 12장을 RAID 0 으로 묶었다가 중간에 데이터가 하나 날라가면 그 12장 세트는 못쓰게 됩니다. 
RAID 1로 그걸 미러했으니 괜찮지 않나요? 라고 하시겠죠?

망가진 디스크를 다시 교체를 했을 때 리빌딩이라고 하는 복구 조치를 취하는데요.. 
RAID 0 으로 12개를 처음에 묶은 구성에서는 우선 12개를 모두 포맷후 하나의 디스크로 재구성을 합니다. 
그리고 미러가된 12개에서 데이터를 모두 복제해 와야 하지요. 
RAID 1로 처음 12셋을 만든 경우는 
망가진 디스크를 교체하면 그 디스크만 포맷후 재구성하면 되고 나머지 11개의 디스크는 그대로 사용하면 됩니다. 

2000년대에는 디스크 하나 RAID로 재구성하는데 보통 6시간 전후로 걸렸는데요.. 
RAID 0으로 된 12세트를 재구성하면 72시간이 필요하게 되는거지요.. 
그리고 RAID 재구성중에는 OS기동 조차 안됩니다. 이건 펌웨어에서 진행 되니까요.. 

구성 하나 잘못했다고 디스크를 다시 넣고 리빌드 하는데 72시간 서비스를 뻗게 만들 수도 있죠.. 

How Swap이면 되지 않느냐? 
라는 것도 있죠? 

SAS디스크면 How Swap도 지원되는게 나중에 나왔습니다. 
하지만 가성비 때문에 SATA를 SAS컨트롤러에 꽂는 경우가 많은데 그러면 전원을 내려야 하지요.. 

지금은 VM생성시 디스크 타입을 고르고 이중화를 로컬 이중화를 하거나 리전 또는 Geo Redundancy를 하거나 하잖아요?
예전엔 그런게 있을리가 없으니 모든 구성을 손으로 했었지요. 
Local 이중화는 RAID인거고, 
Region 이중화는 iSCSI등으로 SAN스토리지를 쓰고, 
Geo Redundancy 는 DR구성후 CDP솔루션을 사용하곤 했죠. 

요즘은 그런거 하나도 몰라도 마우스 클릭만으로 다되는게 참 편하네요.. 
그래도 개발환경에서 클라우드로 올리면 성능저하가 생길때 가서 봐주면서 느끼는건데요.. 
이런 기초 지식이 없는 상태에서 만들다보니 IOPS나 TPMC가 안맞아서 처음부터 다시 짜지 않는한 성능 개선이 안되는걸 자주 봅니다. 
그걸 해결하려고 Premium SSD를 쓰면서 엄청나게 인프라 비용이 올라가기도 하는데, 어짜피 개발자가 이렇게 써야만 해요 하면 사장은 인프라에 문외한이라서 그런가 보다 하잖아요.. 
그런데에 제가 들어가면 다 들통나서 개발자들이 전원 사표 공격을 하게 되는거죠.. 

그러니 개발을 하시더라도 가급적 이런 기본적인 것들을 배우는게 자기 능력을 훨씬 키우는 거라는 것도 알아두시기 바랍니다. 
과학도 기초과학이 튼튼한 국가를 못이기듯, 
IT도 Abstract Layer라고 불리는 하드웨어의 물리적 구조를 잘 아는 사람을 이길 순 없죠. 

암튼.. 그냥 또 잘난척 해봤습니다. 


giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...