얼마전 aws위에서 mongodb를 올려서 서비스를 구성한 구성표를 보았다.
이 구성표를 만든 팀은 예전에 내가 도와준다고 했을 때 이미 많은 서비스를 mongodb를 이용해서 서비스 했다고 자만하던 팀이라 그냥 지켜보기로 했던 팀이었다.
2Core/4GB의 mongos 2대가 서비스 헤더, 1대가 관리헤더
2Core/4GB의 mongoc 3대가 metadata, 3대가 로그의 metadata.
4Core/16GB VM을 5대를 올려서 3대를 mongod를 올리고 2대를 서비스로그를 저장하도록 구성 했다.
물론 세세한건 보지 않았지만,
당연히 EBS가 30GB이니 30GB모두 하나의 shard로 하여 1 shard 3 replica 이지 않았을까?
안에서 추가로 쪼개기에는 EBS사이즈가 작으니..
개발 서버 포함 총 15대의 VM으로 구성된 예상비용은 월 약1200달러.
이것을 26대로 늘리고 월 약 1100달러로 줄이는 설계를 보여줬다.
그리고 성능은 기존의 약 6배. 비용으로 환산한다면 월 7200달러 어치의 성능을 1100달러로 보여준 것이다.
AWS HW의 특성상 IOPS성능이 일반 HW보다 1/5 수준으로 떨어지는 것을 어떻게 메꿀 수 있는지가 중요하다. 특히나 EBS가 SSD라고 할지언정 물리적으로 연결되어 있는 디스크가 아닌 이상 Storage Network의 처리 성능이 가장큰 병목이 발생한다. (AWS 및 Storage를 Network로 연결하는 클라우드 아키텍쳐는 모두 같은 문제)
그리고 AWS의 특성상 1vCPU는 1Core가 아니다. 예전에는 1vCPU의 성능 수치가 있었지만 지속적인 하드웨어 추가로 인해 기존 하드웨어와의 CPU모델이 달라져 성능이 다르게 나오고 있어 이 지표는 사라졌다. 1vCPU의 성능이 얼마만큼 나오는지를 이해하여야 한다.
그 다음으로 Virtualization의 성능(Para-virtualization, Full virtualization)에 따른 퍼포먼스 저하가 얼마나 일어나는지, Linux라는 OS를 쓸지 Windows라는 OS를 쓸지 등에 따라서 OS가 Emulate하는 HW의 성능 저하가 얼마나 일어날지에 대한 복합적인 성능 측정 능력도 필요하다. 예를 들어 Windows는 현재 Full Virtualization밖에 지원이 안되기 때문에 모든 HW는 약 4~8%의 성능 손실이 있는 반 면에 호환성이 좋지만, Linux 중에서 Para virtualization을 사용하는 경우(Full도 가능) Hyper visor를 거치지 않고 직접 OS가 HW를 핸들링하면서 성능 저하는 2%미만으로 줄일 수 있으나, OS가 다른 HW로 real-time migration(vMotion, xenMotion등)을 하는 경우 모든 HW의 드라이버를 가지고 있지 않으면 OS기동시 에러가 발생할 수 있는 운영상의 결점을 가지고 있다.
더욱 성능을 향상시키기 위해서는 OS가 data를 encapsulation하여 NIC으로 전송하는 부분에서 최대한의 데이터를 넣기 위한 압축 방식이나 모자라게 던지지 않게 하기 위한 chunk의 단위 설정까지 들어가는 방법도 있지만, 여기까지 하기에는 OS를 설계할 수 있는 레벨을 요하기 때문에 이런게 있다는 얘기만 하고 넘어가겠다.
Mongodb로 올렸을 때 mongos, mongoc, mongod의 각각의 성능면의 특징을 모르면 mongoc에 쓸데없는 고성능 VM을 제공한다거나 하는 설계 미스가 발생한다.
또는 충분한 메모리를 살리지 못하고 shard의 배치 실패를 가져올 수도 있다.
역으로 shard를 너무 오밀조밀하게 넣고 용량을 키웠다가 rebalance시에 발생하는 부하 때문에 서비스가 멈출 수도 있다.
아니면 이번 처럼 PBM(Percona Backup for Mongo)같은 것을 올려서 mongod를 자꾸 죽여서 data fault를 만들 수도 있다.
기본적으로 mongo등의 NoSQL은 대규모 로우데이터의 저장용등의 NoSQL에 맞는 용도로 써야 하는데, RDBMS처럼 설계하고 RDBMS처럼 사용하려고 많은 공수를 버리고, 결국 RDBMS처럼 백업을 걸다가 용량에 못이겨 서버가 터지는 현상도 만들 수 있다.
그리고 위 처럼 용도에 따라 서버를 분리하면 데이터가 들어올 때 3배(아마도 replica 3이라서 1배일 듯), 로그 요청이 들어올 때 2배(아마도 replica 2로 1배 했을 듯). 만약 서버를 잘게 쪼개고 이를 다 통합하고 collection을 나누고 나눈 collection을 shard로 관리하게 되면 데이터가 들어올 때 16배, 이후 로그를 써도 16배의 성능이 나온다.
옛날 RAID의 구조를 모르고 딴지 걸었던 SE도 비슷한 경우였다.
물론 mongos의 병목이 없다는 전제 등이 필요하지만 충분히 병목이 없다는 전제 하의 단순 계산이다.
추가로 redis등을 활용하여 개발의 효율을 높이는 방법(뭔 소린지 모르시는 분들은 나중에 찾아보시면 됩니다)이라던가 서비스 성능을 높이는 방법 등, 알 수록 활용 가치가 높아지는 것들은 무수하게 많다.
(이 이상 깊이 들어가면 글이 너무 길어지고 재미도 없으니 더 깊은 부분까지 원하는 사람들은 개인적인 질문을 받기로 하겠습니다)
같은 AWS라고 하더라도
AWS의 하드웨어적인 architecture와, 그 위에서 돌아가는 실제 SW의 구조, OS의 구조, 그리고 네트워킹 구조를 정확하게 알지 못하면 그만큼의 성능 손실 및 비용 손실로 이루어진다.
하지만, 요즘 같은 클라우드시대가 도래하면서
더욱 경계가 애매해져 버린 이 영역들..
그러다보니 더욱 비용 대비 효율이 떨어지는 구조가 나오고 있다.
물론 AWS를 효율적으로 쓰면
기존 20%밖에 안쓰고 버리는 80%를 절감
할 수 있다.... 고 한다.
하지만, 내가 봐 왔던 어떤 기업도
전통적인 설계 구조 그대로 AWS에 도입을 하지
클라우드 HW architecture를 이해하고 설계하는 사람은 보지 못했다.
(물론 있겠지만)
결론을 말하자면 이제부터 중요해 지는 것은,
단순히 한 분야의 전문가 보다는
가능한 넓은 분야를 깊이 알고 있는 전문가가 필요해졌다.
예전 같이 한 두개만 좀 한다고 전문가 대우를 받기가 어려워 진 것이다.
디지털 수요가 늘어남에 따라
이러한 전문가는 더욱 수요만 늘고 공급은 따라가지 못하고 있다.
이걸 돈으로 때우면서 서비스가 늘어나는 기업들..
아마존은 이걸 이미 알고 노렸던게 아닐까?
댓글
댓글 쓰기