ZSNET5
Mysql 데이터는 3기가 정도 되고, 부하는 그리 크기 않으나 고객이 빠른 응답속도를 요구합니다.
1. SSD 4개를 RAID-5로 묶고 싱글볼륨으로 잡아서 OS와 DB를 동시에 설치하는 방법
2. SSD 2 + 2개를 각각 RAID-1 으로 잡아 별도의 볼륨으로 설정하고 OS와 DB를 따로 돌리는 방법
3. SSD는 못믿으니 차라리 SAS 15,000RPM으로 가능 방법(RAID는 알아서.. 잘~)
중 어떤 쪽이 퍼포먼스와 안정성, 유지보수 편이성 측면에서 나을런지요..
IDC에 입고시킬 장비이므로 항온항습과 전력에는 문제 없다 판단합니다.
..나는 세상의 중심..
1. RAID5 단일볼륨 구성으로 OS / APP / DB 를 같이 구성하지 마라.
2. OS는 RAID1으로 구성을 추천하며, DB는 데이터의 사용 용도 및 특성에 따라 구성이 달라진다.
3. 기록매체의 종류와 RAID는 의미없다.(깨지고자 한다면 어떠한 경우라도 깨진다.)
4. 백업만이 살길이다.
입니다.
CentOS 에 in box 드라이버로 자동으로 잡혀 올라오니, OS 세팅도 무난하고, 빠른 응답속도도 만족 시킬수 있습니다.
..
O.S 영역은 일반 SAS나 SCSI 혹은 SATA 사용하셔도 될듯 싶습니다. ^^
..
오히려 컨트롤러를 좋은녀석을 쓰심이~
근데 샤시를 4베이짜리 사용할 예정이라 말씀하신 구성으로는 무리가 있습니다.
컨트롤러 좋은녀석은 당연한 거겠지요.
덤으로 sas/sata 라도 끼우셔서 꼭 빽업을 하시길 바랍니다.
Raid 1 이 보통 Read Cache 를 지원하는데 (양쪽 중에 한가한 쪽에서 읽음)
미러링에 스트라이핑 까지 하면 읽기 속도는 매우 빨라 집니다.
보통 DB가 대부분 글쓰기는 뜸하게 일어나고, 대부분 조회 작업인 것을 생각하면 이런 구성이 좋을 것 같네요.
Raid 5 는 개인적으로 비추...
보수적인 관점에서 몇가지 코멘트를 추가해보건데..
1. SSD + RAID 구성은 아직 검증되었다고 보지 않습니다.
기존 모터구동 디스크 기반의 RAID 기술이 메모리 장치인 SSD 에 알고리즘의 변화없이 RAID기술을
적용하는 것은 권장사항은 아닙니다.
2. SSD 특성상 Device Fail 시 복구가 사실상 불가능하므로 복구시 백업에만 의존해야 됩니다.
부분적인 복구 방법이 원천적으로 불가능함
3. MySQL 같은 DBMS 를 일반적인 OLTP (온라인 트랜잭션)로 운용시에 적절한 메모리 캐시와 INDEX 설계를 갖춘다면 스토리지 디바이스에 따른 DB 성능차는 미미합니다.
SSD 디바이스는 대량의 IO 배치에 유용합니다.
SSD의 특성을 잘 모르시는 분들이 그와 비슷한 이야기를 합니다.
오히려 OLTP (특히 DB는 read가 많음)에 SSD가 좋습니다. 그 이유는 SSD가 랜덤액세스에 강하기 때문입니다.
특히 OLTP 엔진을 별도로 가지고 있는 RAID 들하고 물릴 경우 더 좋다고 볼수 있습니다.
그리고, 2번 의견도
결국 RAID 10을 쓰면 모두 해결됩니다. DB가 주로 RAID 10을 사용하는데는 이유가 있기 때문입니다.
1번 의견도 틀렸습니다.
과거의 SSD는 RAID에 최적화되지 않았고 RAID 회사도 SSD에 대비되어 있지 않았습니다.
하지만, 요즘은 그렇지 않습니다. 인텔 SSD는 RAID에 많이 사용되고 있으며, 대부분의 RAID 들은 최소한
인텔 SSD하고는 잘 동작합니다.
Cache Hit ratio가 95%이상이라면 SSD RAID set은 가성비가 안나올거 같은데요.
관리자의 관점에 따라 DB에 SSD가 배치되는경우도 있고
DB에는 SSD안쓰면서 Static Web서비스에 SSD를 배치하는 경우도 있다봐야 하지 않을까요?
DB서버라는 특성을 무시하고 오로지 SSD 물리적 성능만 보시네요.
3번에 대해 기술적으로 따져 보겠습니다.
제가 쓴 조건 "적절한 메모리 캐시와 INDEX 설계" 가 바로 DB서버 본연의 특성인데 그걸 쏙 빼버리셨네요.
적절한 DBMS 파라메터 세팅과 DB설계에 결함이 없다면 BufferCache HIT-RATIO 가 96~99%를 상회하는 것이 정상적입니다.
그러면 실제로 1~4%만 Physical reads 가 발생합니다. Physical reads 도 Sequential 과 Random 으로 구분됩니다.
Full Table Scan같이 Sequential하게 읽어들이는 IO패턴의 경우는 큰 장점이 없으며 나머지 Random Read Access 에서 SSD 의 성능이 드러나게 되는데
일반적인 OLTP 업무DB에서 정상적인 SQL 문장과 INDEX 설계가 되어 있다면 다량의 Random Read Access 는 발생하지 않으며
이것은 곧 튜닝대상으로 수정되어야 하는 것입니다.
위와 같이 OLTP DB의 전체적인 DML성능(I/U/D)을 두고 볼 때 SSD의 강점인 select(Random Access read) 의 수행빈도는 낮으며 따라서 Disk 에 비해 그 성능개선효과가 미미하다는 것입니다.
그리고 한가지 더 첨언하면
"오히려 OLTP (특히 DB는 read가 많음)에 SSD가 좋습니다" 라는 하셨는데요.
OLTP는 말 그대로 online transaction 으로 실시간 트랜잭션(i/u/d)에 주목한 개념이며 select 에 비중을 둔 개념의 DB가 아닙니다.
"오히려 DW어플리케이션 같은 OLAP 업무 DB에 SSD가 좋습니다" 라고 하셔야 됩니다.
"특히 OLTP 엔진을 별도로 가지고 있는 RAID 들하고 물릴 경우 더 좋다고 볼수 있습니다."
설마 RAID 컨트롤러에 OLTP 엔진이 있다고 얘기하신 건가요? 저로서는 처음 듣는 말이라서 이해할 수가 없군요.
메모리 넉넉히 꽂아서 DB와 프로그램 잘 튜닝하시면 충분히 만족할만한 성능을 뽑아낼수있어보입니다.
저도 근래에 SSD를 이용한 DB 성능향상에 관심이 많았었지만 결론은 아직 시기상조라는겁니다.
더더욱 서비스에 투입할 DB는 결국 검증된 SAS로 갈수밖에 없더군요.
아무리 마티즈 가지고 튜닝해봤자, OEM 그대로의 스포츠카가 더 빠릅니다. 일반 하드와 SSD의 비교가 이와 같습니다.
그리고, OLTP 엔진이 RAID에 있는것을 모르신다고요.
예를들어 IBM, Sun, Adaptec의 서버용 RAID제품에 존재합니다. 그리고 일부 블래이드 RAID 제품등에도 존재하고, 대형 제품에도 존재합니다.
DB를 논할때 설계나 처리방법이 중요하지만 이것은 S/W에 국한됩니다, 결국은은 H/W의 환경구성에 많은 영향을 받습니다.
튜닝이 소소한 형태의 I/O 성능 향상이라면, H/W 적인 환경과 엔진의 변혁을 통해서 보다 큰 I/O의 변화를 시도하는것이 현재의 트렌드입니다.
마티즈 사려는 일반 고객에게 그냥 스포츠카 브로셔를 들이미실렵니까?
IBM, Sun, Adaptec의 서버용 RAID제품에 OLTP 알고리즘이 적용된 제품을 소개한
링크를 알려주신다면 변송학님의 댓글을 사실로 인정해드리겠습니다.
그리고, 비용대비 성능 관점이라고 하셨는데,
H/W로 환경 바꾸어 성능 향상 하는것이 , DB 전문 엔지니어 고용하여 성능 향상하는 것보다 비용이 적게듭니다. 오히려 H/W로 성능 향상 한것이 더 빠르고, 더 여러가지 변화에도 쉽게 대처할수 있습니다.
거기에 더해 덤으로 튜닝까지 하면, 몇배의 성능 향상이 되겠지요.
하지만, 매번 튜닝하는데 걸리는 인적 자원에 대한 비용 발생보다는, 아무 환경에서나 간단히 설정만 하면 끝인 환경이 더 비용이 적게드는게 현실입니다.
게다가 db 관리자가 바뀌건, 프로그래머가 바뀌건 영향을 받지 않게 됩니다.
인적 자원=비용 이라는 것을 무시하시나요?
애초에 논의의 쟁점이 된 사항을 잊으셨나요?
'기본적인 DB설계가 있는 DB서버에 있는 DISK 를 SSD 로 교체할 경우에 그 성능향상차가 미미하다'
라고 했습니다. 즉 H/W 저장장치간 성능향상에 대해 저랑 견해차가 있어서
Disk 가 빠르냐? SSD 가 빠르냐? 를 따지고 있는데요.
갑자기 쌩뚱맞게 전문 DB튜너를 투입해야된다는 걸 비교대상으로 삼는 건 완전 논의일탈이 아닌가요?
이건 원래 DB문제가 없다라는 전제에서 벗어난 겁니다.
DB가 멀쩡하다면야 DB전문 엔지니어를 고용할 필요가 없는거지요.
이렇게 말하시면 서로 딴 얘기하는 거 밖에 안됩니다.
OLTP 라는 단어가 들어있는 DataSheet PDF 가 딱 1개밖에 못찾겠네요.
http://www.adaptec.com/nr/pdfs/series6_ds.pdf
그래서 쓰여 있는 내용을 봤는데요.
Ideal for bandwidth intensive storage applications; online transaction processing servers(OTLP)
즉, IO대역폭에 집중적인 OLTP서버에 적합하다는 말인데요.
저게 과연 OLTP 엔진이 RAID에 있는것을 봐야 되는건가요?
제가 보기엔 기술적인 스펙을 엉뚱하게 해석하시는 것으로 보입니다.
SQL 몇줄 변경한 것으로도 H/W 성능 업그레이드한 것보다 수십배의 성능개선이 이루어지는게 바로 데이타베이스입니다. DB를 논할때는 바닥 기초공사에 해당하는 DB설계가 가장 중요시되는게 일반적입니다.
기본적인 DB설계와 H/W 성능, 둘을 놓고 비교할 때 성능관점에서 우선적으로 고려되어야 할 것은
DB 설계부분이어야 하고, H/W 성능산정부분은 후순위라는 겁니다.
db 설계할때 기본적인 설계 상태에서도 h/w 관점에서 성능 향상을 만든다는 것입니다.
게다가, 거기에 더해 소위 말하는 튜닝 , 최적화를 하면 더 배가 되는 것입니다.
h/w 환경이 그 기초중의 기초입니다. 왜 이걸 무시하고, 무조건 db설계 탓을 하느냐가 요지입니다.
제대로 된 h/w 환경이 기본이고, 그다음이 db설계입니다.
왜 이걸 거꾸로 말하느냐? 이것이 의문입니다.
그리고, 소위 말하는 어쩌구 하는 환경들이 다 옛날의 기술하에서 변화된 부분은 반영하지도 않고, 자신만이 옳다고 말하는지 모르겠습니다. IT 기반은 내가 오늘 알고 있는게 내일 의미없는게 되어버리기도 합니다.
예를들어 RAID 이야기할때 하드는 맹목적으로 같은 회사, 같은 모델, 같은 용량을 아직도 믿고 있는 분들이 많습니다. 하지만, 이것이 "하드자체의 결함이나 설계문제(F/W 문제)"가 아니라면, 다 사용가능하다로 바뀐지 오래입니다.
위에 제가 나름 소상히 설명했던 댓글은 전혀 안 보신 것 같네요.
"기본적인 DB설계가 문제없는 상태에서 Disk 와 SSD 성능차이는 미미하다"라는게 바로 요지가 아니었는지요?
이 말은 랜덤I/O를 모르시는것 같습니다.
여기서 말하는 랜덤I/O는 디스크와 SSD에서 발생하는 I/O, 그리고 컨트롤러와 관계된 I/O만
한정하는게 아닙니다. 그리고, 물리적 기반 디스크가 왜 랜덤 i/o 이슈가 더 많은지도 고려되어야 합니다.
단순히 I/O를 시퀀설, 랜덤I/O로 생각하지만, 실제로 랜덤i/O는 중요한 의미가 있습니다.
이것을 I/O관점에서 보게되면, 말씀하신 것 처럼 쉽게 결론이 나오는 것이 아닙니다.
"기본적인 DB설계가 문제없는 상태에서 Disk 와 SSD 성능차이는 미미하다"
-> "어떤 환경에서는 HDD와 SSD가 성능이 비슷할수는 있지만, 다수의 환경에서는 많은 차이가 난다."
이렇게 바껴야 합니다.
대부분의 사람들이 저속i/O의 관점을 고속 I/O에 억지로 맞추려고 합니다. 저속과 고속 I/O는 그 I/O에 대해 고려할때 관점부터 바껴야 하고, OS레벨 애플리케이션 단계부터 고려되어야 합니다.
그래서 저속 I/O보다 고속 I/O가 빠르고, 고속 I/O에서 튜닝까지 들어가면 더 빠르게 되는것입니다.
참고로, 제가 말한 저속 I/O 라는 개념이 단순히 느리다는 개념이 아닙니다. I/O를 논할때 고려되어야 하는 것을 말하는것입니다.
뭔가 기술적인 설명은 하나도 없이 "실제로 랜덤i/O는 중요한 의미가 있습니다." 라고 하셨는데요.
구체적으로 왜 그런건지에 대한 설명은 전혀 없네요.
또
"어떤 환경에서는 HDD와 SSD가 성능이 비슷할수는 있지만, 다수의 환경에서는 많은 차이가 난다."
라고 하셨는데요.
제가 말하는 건 DB서버에 국한해서 말하는건데요. 밑도 끝도 없이 '다수의 환경'이라는 뭉뚱그려서 지칭하면 더 이상 기술적인 논의의 의미가 없을 것 같습니다.
현재 우리는 DB에 대해서 이야기하고 있습니다.
당연히, 이 내용은 DB에 국한해서 이야기하는것 입니다.
그리고, 기술적인 논의?,
현재 IT의 흐름조차도 모르면서, 난 그런거 본적없다시며,
인정하지 않으면서 논의가 될수 있을까요.
"OLTP 엔진"과 RAID에 대해서 인정하지 않으셨습니다.
그런데 실제로 존재합니다.
그리고, 비용 문제도 거론하셨는데,
인건비가 더 무서운 겁니다.
OLTP 엔진과 SSD의 조합, 그 비용 4ch 채널이면, 120 정도면 끝납니다.
하지만, DB 튜닝(재개발) 비용이 더 클겁니다.
그리고, 더 나아가서, 왠만한 DB 들은 이미 어느정도 튜닝은 되어 있는 상황입니다.
히트율 언급하셨죠. 예를들어 95% 히트라고 치면, 나머지 5 %는 어쩌실것인지요.
랜덤 I/O에 대해서 조금이라도 아는 사람이라면, 이 5%가 얼마나 중요한지를 압니다.
왜냐하면, 그 5%가 실제 I/O이기 때문입니다. DB에 국한하면, 디스크 I/O입니다.
디스크 I/O와 히트된 I/O의 차이가 얼마나 큰 딜레이 차이가 있는지 아시나요?
RAID 카드중 잘 설계된 제품은 기본으로 95%의 히트를 전제로 캐시로직을 설계하고, 캐시 사이즈를 결정합니다. 왜 그런지 이해는 하시는지요.
저보고, 그 모든것을 설명하라면, 아마 밤새워도 모자를 겁니다.
더군다나, 대부분의 사람들은 자기 모순에 빠져서 트렌드의 변화를 읽지 못합니다.
예를 하나 들면, 어떤 회사가 있습니다. 과거에 10대의 DB 서버를 돌렸습니다. 그런데, 요즘은 비슷한 등급의 한대의 서버로 돌립니다.
과거에 10대 돌릴때는 그들이 DB 엔지니어가 멍청해서 튜닝을 못했을까요?
지금 한대로 돌아가는 것은 또 왜 그럴까요?
DB 를 논하기 이전에 I/O를 이해한 사람이 DB 서버를 세팅했다는게 차이를 뿐입니다.
물론 저도 그런 정도의 레벨은 아닙니다만, 그런 방법이 현재의 트렌드라고 배웠습니다.
그리고, 실제로 그렇게 돌아가는 사이트들이 증가하고 있습니다.
김현호님이 눈을 돌려서, DB 이전에 I/O라는 개념을 먼저 확립하신다면,
히트 라는 개념보다 더 먼저 생각해야할것도 있고, 그외에 고려해야할 것도 더 많다는 것도 아실겁니다. 거기다가 SSD와 HDD의 컨셉 차이가 무엇인지도 알아야하고,
이런 세팅은 소위말하는 오버헤드가 많은 DB에도 유효합니다.
더군다나, IBM은 SSD를 위해 전용 RAID도 공급하기 시작했습니다. 왜 SSD를 쓸까요.
시퀜설 때문일까요? 그건 디스크로도 커버됩니다.
랜덤 때문입니다. 어떠한 튜닝이로도 극복할수 없는 원론적인 I/O 부분의 이슈를 SSD를 이용해서
극복할수 있기 때문입니다.
김호님은 이런 말을 하셨죠
"SSD 디바이스는 대량의 IO 배치에 유용합니다"
이 말이 얼마나 차이가 있는지 아십니까?
정말로 이런대는 오히려 SAS 하드 씁니다. SSD는 돈낭비일 뿐입니다.
물론 트렌드가 변하면 이 내용도 바뀌게 될겁니다.
하지만, 현재의 트렌드는 이 내용은 전혀 맞지 않는 말입니다.
SSD는 과도한 랜덤I/O를 견디기 위해서 주로 씁니다.
물론 여기에 걸맞는 컨트롤러도 필요합니다.
정확히 말하면, 대량의 랜덤I/O라고 표현할수도 있습니다.
그 이유는 SSD가 가진 하드와의 엄청난 차이 부분 때문입니다.
반대로 SSD가 쓰여서는 안되는 분야들이 있습니다. 이 차이를 모르고 여러군데서 쓰여지고는
있습니다. 하지만, 제대로 적용하지 못한 곳은 오히려 디스크를 사용하여 최적화한 구성보다
성능이 떨어집니다.
결국 I/O 관점 이야기로 다시 돌아가는 것입니다. 써야될곳, 쓰지 말아야할곳이 있습니다.
하지만, 이것도 현재 시점에서 그런것일뿐입니다.
나중에 IT의 기술 트렌드가 바뀌면, 그 내용이 어떻게 달라질지 아무도모릅니다.
그 만큼 기술의 변화가 심합니다.
구체적인 논거는 전혀 없고 뜬 구름 잡는 식의 막연한 주장에는 더 이상 일일히 대응하지 않겠습니다.
여튼 구체적으로 정리해보지요.
<집중해야 될 논의대상>
"기본적인 DB설계가 정상적인 DB서버에서 Disk 를 SSD 로 교체할 경우 그 성능차이가 미미하다"
애시당초 이 부분을 틀렸다고 단정하시면서 저랑 논의가 시작된게 이게 맞죠?
<논의 주제에 벗어난 것들>
1. IT Trends - 현재 SSD가 Disk 를 대체해나가는 과도기상태라는 건 잘 압니다. 자기 모순이니 하는 그런 철학적인 말은 언급하지 않으셔도 됩니다.
2. 인건비 문제 - 정상적인 DB 에서 Disk가 빠르냐? SSD 가 빠르냐? 라는 것으로
H/W 교체비용 대비 성능차를 따지는데 왜 여기서 자꾸 인건비문제가 나오는지요?
3. RAID컨트롤러에 내장된 OLTP엔진 - 위에 제가 쓴 댓글 보셨나요?
문서상으로 확인가능한 내용 딱 1가지만 알려주세요. 그럼 인정하겠습니다.
4. '어떤 회사가 10대 돌리는 DB서버를 지금 DB서버 1대에 몰아돌리더라'
- 이 말이 논의요지와 어떤식으로 구체적으로 어떤 상관성이 있다는 건가요?
<논의 주제 대상>
1. 마냥 Random I/O 가 중요하고 이해가 필요하다는 당위성(?)을 들을려고 변송학님과 이러는게 아닙니다. 논의주제와 관련된 기술적인 내용을 구체적으로 얘기해주세요.저 맨날 서버 수십대 I/O 모니터링하면서 밥 먹고 사는 사람입니다.
2. Physical Reads (random read access)가 최대 5% 발생하는 경우
2-1. DB에서 random read access 가 5%가 특정 시간대에 지속적으로 발생한다는 가정은 이미 "기본적인 DB설계가 정상적인 DB서버"라는 조건의 범주에서 벗어납니다. random read access 는 DB성능저하 주 요인이며, 지속적인 physical reads가 발생하는 건 이미 정상적으로 운용되는 DB가 아닙니다.
2-2. random access read가 disk busy를 90%이상을 점유하는 악성SQL 을 방치한 채 DB서버의 Disk를 SSD로 교체하는 방안에 대해서까지 인정하지 않는게 아니라는 겁니다. 임시땜빵이기는 하지만
2-3. 그렇다면 정상적으로 운영하는 DB, 즉 physcial reads 가 최대 5%까지 발생하더라도 특정 SQL에 의해 집중되지 않으며, 그 발생빈도가 전 로직상에서 잘 분배되어 있는 DB 에서는 Disk 를 SSD 로 변경하더라도 성능개선의 효과는 미미하다라는 말입니다.
일반적인 환경에서 생각하시기에는 조금 무리가 있습니다.
제가 3GB정도(백업이 3GB니까 실 데이터는 좀 더 큽니다만) 밖에 안되는 DB를 굳이 SSD를 쓰면서까지 하려고 했던 이유가 Cache Hit이 비정상적으로 낮은 환경이기 때문입니다. 실제 확인은 해 보면 Cache Hit이 20~30%도 되지 않는 특이한 환경입니다.
그러면서 1분당 접속자 1000명 이상이라 아주 x같습니다. 더군다나 원 개발자가 실력이 그리 좋지 않아(일 수도 있겠지만 특이한 사상을 가지고 있던 사람이라) S/W 환경에서 비정상적인 SQL구문과 비효율적인 인덱스가 상당히 많이 숨어 있습니다.
당연히 재개발 혹은 튜닝을 전제로 해야 하지만, 항상 그렇듯이 이상과 현실은 거리가 있는 관계로 하드웨어쪽 예산이 잡힌 김에(무조건 해야 되는) 생각했던 부분입니다.
변송학님이나 김현호님 두분의 말씀도 일리가 있으십니다만, 저도 나름대로 고민을 하다가 던진 화두입니다.
cache hit 가 20~30% 가 physcial reads 에 기인한 것이라면 ssd 로 성능개선이 되리라 여겨집니다.
하지만 원인이 buffer cache 경합과 같은게 원인이라면 DB 트러블슈팅말고는 대안이 없습니다.
무엇보다 정확한 원인분석이 선행되어야 적절한 해결책을 모색할 수 있을 것으로 보이네요.
oracle 이라면 plan 이나 wait event 분석으로 구체적인 원인분석이 가능합니다만
제가 mysql 에 대해서 지식이 얕은지라 어떤 방식으로 찾아야 할지 모르겠군요.
원인은 아는데, 그 원인을 뜯어고치려면 DB구조를 완전히 다 뜯어발겨야 되니 그게 문제인 거고..
고객사 쪽에서도 재개발 하지 않고 적은 비용과 최소한의 시간을 요구하니까요.
제대로된 개발자 찾아서 재개발 하는데 드는 비용이 그리 만만치는 않지 않습니까?? 게다가 원래 개발자는 지금 행방불명 상태라 답도 안나옵니다.(대국으로 팔려갔다는 소문도~~)
그래서.. 라는 겁니다.
한숨~~~~
서버 환경이 어떤지는 모르겠지만 3GB 정도밖에 안되는 데이터에 장비 업그레이드가 과연 필요한가가 의문입니다.
왜 그러냐면 cache hit율을 말씀하셨는데 이것은 주로 hard parsing할때 주로 볼수 있습니다. 말 그대로 비슷한 literal sql 변수값만 살짝 바껴서 수행되는 sql들인데 이런것이 공유되지 않고 건건이 처리되면 당연히 cache hit율은 낮아지고 db부하는 많아집니다. 그러므로 literal sql을 찾아서 공유할수 있도록 구문을 수정하는게 최선책으로 보입니다. 장비 업그레이드는 일시적이지 만약 사용자가 계속 증가하고 DB가 커진다면 또 언젠가는 동일한 문제가 발생할 것이기 때문입니다.
영세 사업장이다보니 08년도에 서버 한대를 웹+DB+스토리지로 만들어서 사용을 하고 계셨고, 중간에 백업용 NAS한대가 추가되었을 뿐 별다른 고려가 없었던 시스템이었습니다.
솔루션 전체의 업그레이드가 필요한 시점인데, 고성능 서버 한대로 이 모든걸 서비스 하는것 보다는 당연히 별도의 전용 서버를 운영하는게 나은 상황이고... 더불어 웹서버를 로드밸런싱 하자고 된 겁니다.
결국 DB서버 전용으로 서버가 하나 할당되어야 하는 상황이니(기술자 입장에서는 너무도 당연하지만) 기왕에 돈 들어가는거 같은 금액이면 좀 더 빠르고 안전한 길을 찾자는 상황입니다.
김용대님 말씀은 지극히 당연한 부분입니다만, 제 상황은 바로 윗글에 있습니다. 저도 답답하지만 외주 프리랜서 입장에서는 한계가 있습니다.
실험으로 결론을 내는 것도... 음...
대략 8체널로 1체널은 MAXQ 1체널은 비상용 핫스왑레디 하드 나머지 6개 체널은 0+1 정도로 묶어 쓰면
좋지 않을까 생각이 됩니다.
그래도 돈이 꽤 나가는 구성이네요.
전에 어디선가 대리운전인가 퀵서비스 데이터 베이스용 스토리지를 봤는데 24베이 FC던가 PCI-E 인터페이스
외장 스토리지에 SSD를 다 채워서 묶어서 설치 되는 것을 보았습니다.
저렇게 무식하게 하는 이유는 빠른 응답과 하드로 된 것은 퍼포먼스가 만족하지 못해서라는데요.
글쎄요.
저는 아직까지는 SSD를 신용하지는 않는 부류입니다.
그리고, 현재 SSD가 각광받고 있는 것은 랜덤I/O가 중요한 분야에서 입니다.
다만 SSD의 몇가지 단점 때문에 이를 극복하기 위해 여러 기술이 각각의 RAID 회사에서 진행되고 있는것으로 압니다. 모 고수님의 말에 의하면, 이 세가지의 미세한 차이가 엄청난 성능의 차이를 만든다고 합니다.
물론 각각의 쓰이는 분야나 적용 방법의 차이를 이해해야 한다고 합니다.
물론 저도 무지 어려운 분야라고 생각합니다. 때로는 물음표가 100개가 뜬 상태에서 고수가 시키는 대로만 구성해버리는 경우도 있습니다. 그런데 결과는... 예상의 도를 넘는 경우가 종종 있다는 겁니다.
DB로 할당된 메모리가 적은게 아닌가 싶습니다.
뭐 어쨋든,
DB사이즈가 300GB도 아닌데 걍 메모리에 올려버림 되죠
지까짓 SSD라 해봤자... 메모리보단 느리니까요
아래 내용 참고하시면 도움 되실것 같습니다.
http://dev.mysql.com/doc/refman/5.5/en/memory-storage-engine.html
http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-more-memory/
댓글의 댓글이 이젠 달리지 않아 정리해서 씁니다.
그리고, 이젠 더 이 관련 쓰레드를 이어가지 않겠습니다.
그리고, HDD를 단순히 SSD로 교체한다는 의미가 아닙니다.
거기에 맞는 어떤 기술을 사용해야 합니다. 대표적인 경우가 컨트롤러가 될겁니다.
더 나아가서 DB쪽에서도 고려가 된다면, 효과는 더욱 클겁니다.
============
이건 이 쓰레드의 발의자인 이진범씨의 이야기입니다.
여기서 SSD+RAID의 조합은 현재의 상태의 DB를 그대로 사용해도 많은 효과가 있습니다.
복잡하게 DB 튜닝까지 갈 필요도 없습니다.
==============
이 내용을 읽어보세요..
Mysql 데이터는 3기가 정도 되고, 부하는 그리 크기 않으나 고객이 빠른 응답속도를 요구합니다.
1. SSD 4개를 RAID-5로 묶고 싱글볼륨으로 잡아서 OS와 DB를 동시에 설치하는 방법
2. SSD 2 + 2개를 각각 RAID-1 으로 잡아 별도의 볼륨으로 설정하고 OS와 DB를 따로 돌리는 방법
3. SSD는 못믿으니 차라리 SAS 15,000RPM으로 가능 방법(RAID는 알아서.. 잘~)
중 어떤 쪽이 퍼포먼스와 안정성, 유지보수 편이성 측면에서 나을런지요..
IDC에 입고시킬 장비이므로 항온항습과 전력에는 문제 없다 판단합니다.
===
이 시스템은 결국은 DB 설계가 잘못된 케이스라고 볼수 있습니다.
그렇다 하더라도 H/W 관점에서 크게 개선이 가능합니다.
- 각각의 회사에서 공개하는 메뉴얼은 최소한 한번쯤 정독합시다
몰랐던 많은 것들에 대해 아시게 될겁니다.
그리고, H/W를 이해하지 못하면서, S/W 분야의 경험만으로 생각하면,
전제 I/O를 이해 못합니다.
랜덤I/O (디스크에 기반한 랜덤)이 발생하면, 여러분이 생각하는 히트되었을때외
비교 조차 불가능한 정도의 딜레이 타임이 있습니다.
그게 얼마나 차이인지 보고 싶으시면, IOMETER 해서 랜덤 I/O 몇개만 걸어보셔도
아실겁니다. 역시 메뉴얼도 공개되어 있으니 가서 읽어보세요.
증거 내놓으라고 하시면, IOMETER 사용하셔서 직접 보시기 바랍니다. 디스크I/O중
랜덤 I/O가 얼마나 중요한지를 아시게 될겁니다.
DB 단에서 이것을 고려하여 최적화한다고 해도 어쩔수 없이 발생하는 것이 존재합니다.
H/W적 관점은 이 어쩔수 없이 발생하는 것을 어떻게 해보겠다가 주체입니다.
메뉴얼, 기술자료, 다 RAID 회사들이 일부는 공개해놓았습니다. 가서 읽으세요.
LSI, Adaptec, Areca 다 찾아보세요.
장비 회사들은 오히려 메뉴얼이 제대로 공개안되지만, 카드 회사들은 많은 자료가 홈페이지에 있습니다.
- 전체 I/O를 고려하는 설계와 DB 만 보는 시각의 차이가 매우 크다
단적인 예로 옛날에 목매달던 어셈블리 대신 요즘은 C가 쓰입니다. (하드웨어 내부 펌웨어마저도)
무리하게 속도를 위해 어셈블리를 사용하지 않아도 되기 때문입니다.
왜냐면, 기술 발전이 그만큼 되었기 때문입니다.
그래서 C의 최적화만으로 충분한 단계가 되었다는 의미는 h/W로 그것을 보충한다는 뜻입니다.
이로 인해, 유지보수의 비용절감, 에러발생율 감소, 발빠른 시장 대응 등이 가능해졌습니다.
결론적으로 DB도 이와 같습니다.
최적화 최적화를 부르짖지만, 결국은 그런 최적화된 환경내에서도 요즘의 IT 트렌드를 반영하면
더 빨라집니다.
왜, 자기 환경만 고수하는지 이해 불능입니다. 최적화가 잘된 환경도 DB 관점뿐이라면, H/W관점도
같이 곁들이면 더 빨라진다는 가장 단순한 논리를 이해 불능이신건지 모르겠습니다.
최적화된 DB 10대가 결국은 "I/O" 최적화된 1대로 대치하는 시대가 되었다는 의미입니다.
자료 달라고하시면, RAID 회사들의 홈페이지에 자료 널렸습니다. 참고하시길...
그 방법론도 크게 세가지이고, 더 나아가서는 여러 조합까지 있습니다.
- SE vs 오퍼레이터 vs 프로그래머
이 세사람의 관점이 다 다르고, 중요하게 보는 시각도 다릅니다.
하지만, SE는 이 두사람의 영역을 넘나들수 있습니다.
설혹 SE가 프로그래밍을 못한다고 해도... 프로그래머에게 조언할수 있습니다.
하루에 1000 대 이상을 관리하는 오퍼레이터에게도 SE가 조언할수 있습니다.
여러분이 SE를 어떻게 생각할지 모르겠지만 (국내에 제대로된 SE가 점점 없어져감)
SE는 수천대를 한번에 관리하지도 않지만, 수천대의 환경을 고려하고,
프로그래밍쪽의 애플리케이션 단계에서 I/O의 변화를 고려하여 최적화하는 것이 가능합니다.
그리고, 그 원인이 애플리케이션에 있다면, 무슨 부분을 고쳐야할지도 알수 있습니다.
경험적으로 보면, 대부분의 프로그래머가 I/O 트래픽과 관련된 중요한 부분들을 모릅니다.
경험적으로 보면, 대부분의 오퍼레이터가 역시 I/O 트래픽의 중요한 관점을 제한적으로 인식합니다.
더이상 논쟁하면, 감정 싸움이 될것이 뻔하니
이쯤에서 접습니다.
다시한번 말씀드리만, I/O 관점에서 이해하시길 바랍니다.
"난 DB 엔지니어니까 DB 만 생각한다."
이런것은, 결국 제한을 스스로 거는것입니다.
과거의 제가 그런 모습이었습니다.
그리고, 다시 말씀드리지만, 메뉴얼은 한번쯤 정독해보시는게 좋습니다.
게다가, 한 제품이 하나의 메뉴얼이 아닌 여러 메뉴얼이 존재하는 경우도 많다는 것을 잊지마십시오.
비슷해 보이는 메뉴얼 내용들이 일부에서는 각각 다른 부분들을 담고 있는 경우가 있습니다.
이게 메뉴얼을 여러 종류를 읽을때 반드시 고려해야할 사항입니다.
그럼 이 쓰레드는 다시 들어오지 않겠습니다...
ps/ http://kldp.org/node/117438
여길 읽어보시면, 댓글들에서 SE가 무엇인지 아실수 있을겁니다.
인터넷 게시판의 한계상 제대로 의견전달이 안되는게 답답할 뿐입니다.
변송학님이 워낙 단호하게 '틀렸다'라고 지적하길래 내가 모르는 어떤걸 배울 수 있겠구나 싶어서 기술적인 논의를 시작한 것이고
이 글을 끝으로 저도 마무리 지으렵니다.
1. 원 질문내용에 'DB 설계가 잘못된 케이스'라고 유추할 만한 내용은 없습니다.
DB서버 스토리지 구성방식에 대해 질문하신 내용밖에 없습니다.
그래서 전 정상적인 DB운영상태라면 SSD 성능차이가 미미하다 라고 하였습니다.
2. 매뉴얼을 정독하라면서 'RAID 컨트롤러에 내장된 OLTP엔진'이라는 근거는 제시를 못해주시네요.
찾아보라고 해서 구글링해서 나오는 Adaptec RAID 매뉴얼 몇개 읽어봤는데 그런 내용은 하나도 없던데요?
널려있다는 식의 말만 하지 마시고 거기가 어디인지 제발 링크라도 하나 던져주시면 좋겠네요.
3. "H/W를 이해하지 못하면서, S/W 분야의 경험만으로 생각하면 전제 I/O를 이해 못합니다. " 라고 하셨는데요.
"랜덤I/O (디스크에 기반한 랜덤)이 발생하면, 여러분이 생각하는 히트되었을때외 비교 조차 불가능한 정도의 딜레이 타임이 있습니다. "
라는게 바로 핵심이 아닌가요? 제가 정말 이걸 모른다고 보세요?
계속 제가 이 점을 모르는 것으로 간주하는 그 의도를 모르겠네요. 그렇다고 다른 설명이 있는 것도 아니고...
SSD의 physical i/o 중에서 random read access 는 disk 에 비해 20배 정도 성능차가 존재합니다.
하지만 정상적인 로직과 INDEX 설계를 갖춘 DB라면 physcial reads (random access read)가 발생하더라도
disk busy로 인한 io wait시간이 많이 나타나지 않습니다. 즉 SSD 의 장점을 살릴만한 여지가 많지 않으므로
성능차를 기대하기는 어렵다는 겁니다.
물론 SSD 를 쓰면 좋긴 하지요.
그런데 DB서버에서는 기존의 검증된 디스크 기반의 RAID를 SSD로 대체하는 리스크를 감수하고
얻을만한 성능적인 가치는 미미하다는 것이 보수적인 관점입니다. 그 근거는 위에서 다 설명되었고요.
이걸 가지고 무슨 IT 트렌드를 모른다고 하시는데요. 벤더 서버장비들 아직 디스크 잘 달고 나옵니다.
4. I/O 관점에서 이해하라는 '당위성'만을 피력하였는데, SSD 의 random access read 말고 어떤 걸 더 이해해야 하는건지 좀 구체적으로 밝히세요.
저는 I/O 가 발생하는 근원이 DB서버니까 DB 에서 발생하는 physical reads 의 특성을 근거로 설명했습니다.
그런데 변송학님은 'SSD가 random read access 에 강하다'라는 사실이외에 구체적으로 제시한 근거가 없습니다.
전 그래도 'SSD가 random read access 에 강하다'는 H/W 적인 사실을 분명히 인지하고 있으며,
그 내용에 근거해서 DB physical reads I/O특성에 대한 설명을 했습니다.
심지어 변송학님이 DB매커니즘에 대한 이해가 전무해서 기술적 의견교환이 안될 것 같다는 의심이 듭니다.
5. 논의내용과는 전혀 연관없는 SE/OP/PRG 역할에 대해 장황하게 늘어놓으시네요.
그저 '정상적인 OLTP 운영DB에서 스토리지를 SSD로 대체하면 얼마나 빨라질까?' 라는 논의 주제와 관련된 언급만 하세요.
"난 DB 엔지니어니까 DB 만 생각한다." 라는 식의 불필요한 호도를 하려드니까 감정 상한다니 뭐라고 하게 되는 겁니다.
IT트렌드를 모른다라고 하는 것도 그렇습니다.
변송학님이 쓴 글은 생뚱맞는 내용만 장황하게 늘어뜨려 있지 정작 논의주제에 연관된 것은 몇 줄 안됩니다.
DB서버가 뭐하는 서버인지는 알고 하드웨어 접근을 해야될거 같은데 그런거 전혀 모르는 사람이 질문을 올리니까 이렇게 감정상하는 글들이 보이는겁니다.
무식하면 좀 공부좀 하시십쇼 창피합니다.
일반적으로 DB서버는 IO-Bound 서버로 분류됩니다.
즉 DB서버는 IO자원에 집중되는 성격을 띠고 있습니다.
그외 CPU-Bound 서버라고 해서 CPU자원에 집중되는 WEB 이나 WAS 서버가 있습니다.
물론 업무성격에 따라 WEB/WAS 서버도 IO-Bound 가 될수있고 , DB서버도 CPU-Bound가 될수 있습니다.
물론 제가 공부가 부족한 건 인정합니다. 이제 겨우 15년째 전산밥 먹고 살고 있는데 해가 지날수록 공부가 부족하다는건 느끼고 있습니다.
그런데 말입니다.... 중간중간 읽어보시면 왜 SSD를 생각하는지에 대해 댓글이 달려 있는 것을 보실 수 있습니다. 게다가 SSD나 SAS나 별 가격차이가 없으니 [디스크에 돈을 꼴아박는다]라고 보기에도 무리가 있지요.
처음에 올릴때는 SSD의 안정성 측면(개인적으로는 속도보다 안정선이라서)에서 다른 분들의 의견을 듣고자 가볍게 올린 글인데, 이게 어느시점엔가 솜사탕처럼 커져 버린 거지요.
제가 5~6년차 때에는 제가 그래도 이 업계에서 좀 능력이 있다 생각했습니다만, 글쎄요.. 해가 지나갈 수록 아는게 없다고 느껴지기는 합니다.
네.. 무식하니까 공부 해야지요.. 창피한 것도 맞습니다.
지금 상황은 SSD가 아니라 억소리나는 SAN 붙여도 근본적으로 해결 안됩니다. 즉 I/O 문제가 아닙니다.
3기가짜리면 버퍼캐쉬에 다 올려버리면 그만입니다. 캐쉬히트가 20~30이면 수백메가정도로 작게 잡혀있는것 같네요.
메모리를 증설하던지해서 버퍼캐쉬를 3기가 이상잡으면 곧 모두 메모리로 올라올거고 그렇게되면
I/O를 논하는 것 자체가 의미가 없어집니다.
그 이후는 모두 CPU+메모리의 클럭 빨이니까요.
웹에서의 응답속도라면 DB 튜닝가지고만 답은 아닐것 같구요.
WEB서버도 한몫합니다. 잘못된 웹소스!!! 그리고 잘못된 SQL쿼리!!! 도 한몫하지요.
(그러나 DB서버만 언급하셨으니, 그 이외의 요소는 아니라고 보시는것이겠지요?)
굳이 격하게 논하실 필요없이, 3GB정도의 MySQL DB이니, 그냥 15만원 짜리 저용량의 SSD 하나 사셔서,
PC에서 테스트 해보시면 될것입니다. 그 다음에, SSD로 RAID구성을 논하시면 되겠네요.
문제있는 DB는 물리적인 I/O 자체가 좋아도 만족스러운 성능 안나옵니다.
SQL 수정해서 한 블록만 읽으면 될 것을 몇 십 블록, 몇 백 블록, 아니면 그 이상으로 읽어 오는데,
I/O가 좋다고 하더라고 성능 잘 안나오죠.
CPU는 CPU대로, I/O는 I/O 대로 개고생이죠...
20~30분씩 돌던 쿼리가 SQL 튜닝만으로 단 2~3초 만에 결과가 나오면 아마 신세계를 경험하실 껍니다.
싶습니다. DB 쪽의 문제는 어지간 하면 직접 해결 하실수 있는 실력을 보유 하셨지 싶습니다.
제가 보기엔 프로그램상에 하드 코딩 되어 숨어버린 쿼리들을 다 어찌 해결(튜닝) 할 수 없는 입장 이신거
같습니다.
그러한 상황에서 하드웨어를 변경하여 얻을 수 있는 이득을 따져 보고 싶으시다는 내용으로 들립니다.
제일 좋은 방법은 개발 소스가 있으면 하드코딩 된 Query를 확인하고 튜닝을 시도 하시는게 낳은데 그게 여의치 않으신거 같고 그렇다면 김상우님의 글 처럼 테스트 환경을 구축해 보시는 것도 나쁘지 않을 것 으로 생각 듭니다.
테스트 환경을 다 비용을 들여 구매 하시는 것 보다는 회원님들께 도움을 요청 하시어 테스트 목적에 맞는 분들을 찾으시고 도움을 요청 해 보시는것이 더 좋겠습니다.
위 김문형님 말씀대로 하드코딩된 쿼리를 어찌할 수 없는 상황이며, 소스도 없습니다.. 흑흑.
프로그램이 튠이 안되니 차선책으로 DB라도 튠 하려고 하는데 한계가 있어서, 하드웨어쪽도 손대보려고 한 상황이었습니다. 일단 이번 쓰레드는 여기까지만 하고 다른 쓰레드에서 뵙겠습니다.
감사합니다.