기본 콘텐츠로 건너뛰기

라벨이 architect인 게시물 표시

요즘은 아키텍트(Architect) 되기가 더욱 힘들어진 거 같아요.

얼마전 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라는