24.03.07 09:20 작성
·
205
·
수정됨
0
안녕하세요!
강의 듣다 궁금한 점이 몇 가지 있어 질문 드립니다.
먼저 강의에서는 빅디님께서 각 서버에 설치할 프로그램을 알려주셔서 편하게 설치는 했는데, 어떤 기준으로 설치할 프로그램을 선택하고 각 서버에 설치할 프로그램을 나눠서 아키텍처를 짜셨는지 빅디님의 관점?이 궁금합니다.
예를 들어 postgreSQL는 서버 1에만 설치하고, HBase Region 같은 경우는 서버 세 곳 모두 설치 한 이유와, 다른 RDBMS 중에서도 postgreSQL을 선택한 특별한 이유 같은거요..!
그리고 서비스 중간에 서버를 늘리려고 할 때 추가해야 하는 서버 수는 어떻게 정하나요? 모니터링 하다가 서버 전체 메모리의 몇 퍼센트를 차지하게 되면 서버를 늘려야 한다 이런 기준이 있을까요? 비용은 제외하고 기술적인 부분에서 기준으로 세울만한 건 어떤게 있는지 궁금합니다.
현업에서는 프로젝트 특성마다 다 다르게 설계를 해야 할 테고 3V 관점으로 봐야 한다는 건 알겠는데 조금 더 구체적인 예시가 있으면 이해하는데 도움이 많이 될 것 같습니다!
감사합니다:]
답변 1
1
2024. 03. 07. 19:52
안녕하세요! "dali7711"님!
오늘 날씨가 갑자기 쌀쌀해 졌네요...환절기 감기 조심하세요!
그리고 좋은 질문 감사합니다! ^^*
각 SW의 서버 인스턴스의 설치 기준은 우선 파일럿 환경 기준으로만 설명 드리자면 간단합니다.
개인의 PC환경에서 다양한 빅데이터 에코시스템들을 작동 시키기 위한 최선으로 구성한 것 입니다.
결국 가상서버들의 CPU/Mem의 자원을 분산 시키되, 아키텍처의 정합성은 깨지지 않도록 구성을 한 것 입니다.
예를들어 PostgreSQL은 Cloudera Manager가 사용 하게 되는데, Cloudera Manager가 Server01에 설치 되어 있기 때문에 같은 위치에 구성을 한것이고요, HBase Region 같은 경우 하둡에 의존성을 갖게 되므로 하둡의 워커노드가 3개이면 HBase리전도 3개로 맞춘것 입니다.
또한 질문중 왜? PostgreSQL로 했냐고 물으셨는데요... 이또한 Cloudera Manager에서 기본으로 제공하는 DBMS가 PostgreSQL이기 때문에 설치 구성의 편의성 차원이 이유입니다. 물론 Oracle을 별도로 설치하고 Cloudera Manager와 연결을 할 수 도 있지만, 파일럿 프로젝트의 핵심은 DBMS 기술을 배우는것이 아니니깐요! 물론 실프로젝트에선 Oracle을 많이 연결해 사용합니다. ^^
그런데 실제 환경에서도 이런일들이 비일비재 합니다. 물리적인 자원은 한정되고, 사업은 확장 되면서 구축해야할 시스템은 늘어 나는데, H/W 장비는 지금당장 구매해 들어오기가 어려운 상황들로, 제품에 최적화된 아키텍처 보단, 빡빡한 자원에 맞춰 아키텍처링을 할 수 밖에 없는 상황들 입니다.
강의에선 "dalki7711"님처럼 궁금해 하실 분들이 있으실 것 같아서...
"섹션2 - 빅데이터 실환경의 이해"에서 실제 프로젝트에선 수십대의 서버에 다양한 빅데이터 에코시스템들을 이중화 및 분산구조 등으로 성능/안정성/확장성을 고려해 배치 된다는 것은 간략하게나마 설명 드렸습니다.
이때 어떤 S/W를 사용할 것이냐는 프로젝트의 목적에 따라 비용/성능/안정성/운영 등 많은 것을 고려합니다만, 의외로 현장에선 아키텍트 또는 의사결정권자 등이 경험 했던 제품으로 많이 결정 되곤 합니다.
제가 파일럿 프로젝트 강의에서 Flume, Kafka, Storm, Hbase 등을 선택해 실시간 기능을 구성 했던 것 처럼요~
실전 프로젝트에서 저같은경우는...사업의 요구사항을 최우선으로 하고요, 본인의 경험과 기술 트랜드 그리고 개발자/운영자들의 기술수준 등을 고려해서 아키텍처링을 하는편 입니다.
아 마지막 질문중 서비스 확장에대해 물어 보셨는데요, 대부분의 실운용 시스템엔 자원을 모니터링 하는 툴들이 있게 됩니다. 시스템의 중요도에 따라 리소스의 사용률 임계치 정하는데요...중요도가 높은 시스템일 수로 임계치를 낮게 잡습니다. 예를들의 CPU/Mem 사용률이 피크시간때 80% 이상 넘는 다든지, 일평균 70%를 넘는다든지, 자원의 스파이크가 매우 빈번하게 발생 한다던지 하면 삐요삐요를 알리고, 필요시 서버를 Scale-Out/Up 하게 됩니다. 요즘엔 Cloud Native 환경을 이용해 이러한 임계치를 기준으로 Auto Scale-In/Out를 처리하기도 합니다.
요약하자면 기준은 따로 없고요 시스템의 중요도와 모니터링 결과에 따라 케바케라 보시면 됩니다. ^^
-빅디 드림
2024. 03. 08. 13:29
이해가 쏙쏙 잘됩니다🥹 자세한 설명 감사합니다!