소개

대부분의 다중 계층 애플리케이션은 더 효과적이고 안정적으로 작동할 수 있도록 확장의 이점을 얻으며, Sandfly도 예외가 아닙니다. 과부하된 노드는 결국 스캔 완료를 방해하거나 범위가 부족한 서버는 서비스 품질 저하 또는 완전한 서비스 손실을 초래할 수 있습니다. Sandfly 사용자가 운영 환경과 기술 요구사항을 수용할 수 있도록 충분히 Sandfly 배포를 범위 지정하고 구축할 것을 강력히 권장합니다. 아래 제공된 정보는 이를 달성하는 데 도움이 될 것입니다.

확장 목표

일반적으로 전체 목표는 서비스나 데이터 손실이 없도록 하는 것입니다. Sandfly는 견고하게 설계되었지만, 노드 리소스 부족으로 인해 큐를 처리하는 노드의 능력이 압도되거나, 서버에 결과 데이터를 처리 및/또는 저장할 충분한 CPU와 RAM이 없거나, 데이터 보존 기간과 관련된 결과의 양으로 인해 컨테이너 파티션이 가득 차는 등의 영향을 미치는 상황이 발생할 수 있습니다. 이러한 경우와 기타 경우들은 아키텍처 선택을 통해 최소화할 수 있습니다.

정량적 관점에서 이것이 의미하는 바는 주로 다음과 같은 다양한 요인에 따라 달라집니다:

• 스캔할 수 있는 활성 호스트가 몇 개나 됩니까?
  • 각 활성 호스트는 본질적으로 처리 및 데이터 저장의 배수입니다.
• 활성화된 스케줄이 몇 개나 존재하며 호스트의 몇 퍼센트가 포함됩니까?
  • 더 많은 스캔이 실행될수록 더 많은 데이터가 생성되고, 처리되고, 저장됩니다.
• 평균적으로 스케줄당 몇 개의 Sandfly가 실행되며 어떤 유형입니까?
  • 일부 Sandfly는 다른 것들보다 실행 시간이 더 오래 걸리거나 더 많은 데이터를 생성합니다.
  • 다양한 유형에 대한 자세한 내용은 Sandfly Types 문서를 참조하세요.
• 스캔되는 호스트가 동일한 네트워크 세그먼트, 공유 스토리지 및/또는 물리적 하드웨어에 있습니까?
  • 공유 리소스, 특히 파일시스템 기반 리소스를 가진 엔드포인트에서 동시에 발생하는 스캔은 공통 구성 요소의 리소스 사용량을 증가시킵니다.
• 스캔되는 호스트가 물리적으로 함께 위치하고 있습니까, 아니면 여러 데이터 센터와 같이 지리적으로 및/또는 서비스 제공업체별로 분산되어 있습니까?
  • 명명된 큐는 이러한 환경에 도움이 되지만 추가 노드가 필요합니다.
  • 자세한 내용은 명명된 큐 문서를 참조하십시오.

이러한 질문에 대한 답변은 확장 계산 및 구성 결정에 사용되어야 합니다.

👍

팁: 보안을 위해 서버에서는 Sandfly 스택만 실행하십시오

스캔된 시스템의 보안과 Sandfly의 안정성 및 확장성을 위해 Sandfly 호스트에서는 Sandfly 스택만 실행하고 다른 애플리케이션은 실행하지 않을 것을 강력히 권장합니다.

서버

Sandfly는 웹 인터페이스, REST API, 데이터베이스를 제공하는 단일 서버를 사용합니다.

성능이 부족한 서버는 데이터베이스 시간 초과 문제가 발생할 수 있습니다. 또는 사용자 인터페이스가 데이터를 로드하는 데 오랜 시간이 걸린다면 리소스가 부족하여 RAM 업그레이드 및/또는 추가 CPU 코어가 필요할 수 있습니다.

서버 리소스 요구사항

Sandfly 스택은 두 개의 Docker 컨테이너로 구성되며, 하나는 API 및 웹 인터페이스용이고 다른 하나는 로컬 데이터베이스용입니다.

절대 최소 서버 시스템 리소스 요구사항:

• 4GB RAM
• 전용 CPU 코어 2개
• 디스크 공간 20GB (호스트 운영 체제(OS) 포함)
  • 더 나은 애플리케이션 성능을 위해 SSD 드라이브를 권장합니다.

각 시스템 리소스는 고유한 환경에 적합한 시기와 장소에서 독립적으로 확장되어야 합니다.

서버 확장

서버를 확장할 때 주요 초점은 데이터베이스가 과부하가 걸리거나 차단 상태로 들어가는 것을 예방하는 것입니다. 대부분의 경우 확장은 호스트 수준에서 수행되므로, 서버를 가상 머신(VM)에서 실행하면 필요가 발생하거나 증가할 때 쉽게 시스템 리소스를 변경할 수 있습니다.

고려해야 할 서버 확장 영역:

• 데이터베이스 성능을 위해
  • 서버 RAM 크기는 results_json GIN 인덱스의 인덱스 크기만큼 커야 하며, 이상적으로는 충분한 여유가 있어야 합니다.
    • 인덱스 크기를 빠르게 확인하는 Shell 명령어:
    • sandfly server

      docker exec -it sandfly-postgres psql -U sandfly -c "SELECT pg_size_pretty (pg_indexes_size('results_json'));"\`

  • 추가 RAM은 일반적으로 데이터를 캐시에 보관하는 데 더 중요하지만, 실제 작업 중에는 CPU가 많이 사용됩니다. 둘 다 모니터링하고 어느 하나가 한계에 도달하면 증설하십시오.
• 들어오는 결과 처리를 위해
  • CPU는 데이터베이스에 저장되기 전에 도착하는 대형 결과 세트를 보유할 충분한 RAM과 함께 중요합니다. 즉, 노드나 스캔되는 호스트 수를 확장하면 Sandfly는 서버에서 증가된 CPU 코어와 RAM이 필요한 지점에 도달할 것입니다.
• 디스크 공간을 위해
  • 파티션 크기 지정은 Docker 데이터가 포함된 위치에 적용됩니다.
    • 기본적으로 그 경로는: /var/lib/docker/
  • 데이터베이스 크기의 대부분은 스캔 결과 데이터에서 나옵니다.
  • 단일 스캔 쌍(Sandfly + os_identify)은 약 2k의 데이터를 생성합니다.
  • 집계된 크기는 다음 두 가지 요인에 따라 크게 달라집니다:
    • 스캔 스케줄, 여기에는 다음이 포함됩니다:
      • 활성화된 스케줄의 실행 빈도
      • 선택된 sandfly의 백분율, 유형 및 수량
      • 스캔당 포함된 활성 호스트의 수량
    • 데이터 보존 기간:
      • 라이선스 및 설정에 따라 1일에서 31일 사이
      • 데이터 삭제는 정의된 기간 이후 모든 스캔 결과에 적용됩니다
  • 어떤 이유로든 그리고/또는 어떤 수준의 세부 사항에서든 더 긴 데이터 보존 기간이 필요한 경우, 사용 가능한 복제/전달 방법 중 하나를 통해 데이터를 외부 데이터 저장소로 분기하는 것을 권장합니다.

서버 스케줄

Sandfly 스케줄은 자동화된 스캔을 구동하므로 데이터 생성의 가장 큰 소스입니다.

확장성과 기능적 인식 모두를 위해 스캔 스케줄은 항상 예정된 시간에 실행됩니다. 따라서 동시에 트리거되는 500개 호스트 스케줄이 두 개 있다면 작업 대기열에 1,000개의 호스트가 들어가게 됩니다. 그러나 호스트는 항상 중복제거됩니다(예: 스케줄 1이 대기열에 호스트 A를 추가한 경우, 스케줄 2가 실행되어 대기열에 호스트 A를 추가하려고 할 때 스케줄 2는 해당 실행에서 호스트 A를 건너뜬니다).

이러한 사항들 때문에 스캔이 완료되지 않을 가능성을 최소화하고 노드에 과부하를 주지 않기 위해 충분한 사전 고려를 통해 스케줄을 계획하는 것이 중요합니다.

노드

Sandfly 노드는 애플리케이션이 SSH를 통해 Linux 호스트에 연결하여 에이전트리스 스캔을 수행하고 결과를 서버로 다시 보고할 수 있게 합니다. 각 노드 컴테이너는 작업 중에 500개의 스캔 스레드 용량을 가지고 있습니다.

노드 리소스 요구사항

스캔 노드는 하나 이상의 Docker 또는 Podman 컴테이너로 구성됩니다. 호스트의 사용 가능한 메모리가 허용하는 경우 단일 시스템 인스턴스에서 여러 노드 컴테이너를 실행할 수 있으며, 대부분의 경우 그렇게 해야 합니다.

최소 노드 시스템 리소스 요구사항:

• 4GB RAM
• 전용 CPU 코어 1개
• 디스크 공간 5GB (호스트 운영 체제(OS) 포함)
  • 최고의 성능을 위해 SSD 드라이브를 권장합니다

이 구성은 예약된 스캔에 포함된 호스트 수량에 따라 최대 3개의 노드 컴테이너를 동시에 실행할 수 있는 용량을 제공합니다.

• 각 컴테이너는 500개의 스캔 스레드를 제공합니다.
• 총 1500개의 스캔 스레드를 제공하며, 이는 호스트 수준 중복성이 필요하지 않은 소규모 배포에 충분합니다.
• 기본 OS를 위해 첫 번째 GB 메모리를 예약한 후, 그 이후는 1GB 메모리당 1개 컴테이너의 비율이 확장 고려에 합리적인 비율입니다. 마지막으로, 가장 큰 단일 패스에서 스캔될 것으로 예상되는 호스트 수량에 15를 곱하여 또한 예약하십시오.

노드 확장

주요 노드 확장 목표는 작업 대기열에 스캔이 추가되는 전체적인 속도가 노드가 대기열을 지우는 능력을 압도하지 않도록 하는 것입니다. 따라서 노드 스레드와 스캔된 호스트의 비율이 1:1일 필요는 없습니다.

사실, 대기열에 800개의 작업이 있지만 노드 용량은 500개 스레드만 사용 가능한 것에는 아무런 문제가 없습니다. 각 작업이 완료되면 다음 대기 중인 작업이 사용 가능하게 되는 다음 노드 스레드에 의해 수행됩니다.

이는 전체 아키텍처에서 고려해야 할 중요한 요소로, 특히 모두 동일한 VM 서버, 공유 스토리지 등에서 실행되는 경우 엔드포인트 호스트와 네트워크에 더 부드럽게 작용할 수 있습니다.

Sandfly 노드는 환경과 기술적 요구사항에 크게 영향을 받는 3가지 다른 방식으로 확장할 수 있습니다:

• 수직 - 노드 확장의 가장 기본적인 형태는 단일 시스템에서 추가 노드 컴테이너가 실행될 수 있도록 더 많은 메모리를 추가하는 것입니다. 수직 확장만 사용하는 것은 가장 중복성이 낮은 형태의 확장이지만, 낮은 영향력 및/또는 소규모 배포에는 일반적으로 충분합니다.
• 수평 - 신뢰성과 중복성을 위해 가급적 다른 인프라에서 2개(또는 적절하게 더 많은) 노드 시스템을 사용할 수 있도록 하는 것을 권장합니다. 어떤 이유로든 노드가 실패하면 나머지 노드가 스캔을 계속할 수 있습니다. 이러한 노드들도 수직 확장 방법의 이점을 눌 수 있습니다. 과도하거나 부족한 아키텍처를 만들지 않도록 위의 사항들을 염두에 두십시오.
• 명명된 큐 - 이 확장 방향은 분산, 분할 및/또는 대규모 환경에 유익합니다. Sandfly는 여러 격리된 네트워크 내에 스캔 노드를 배포하고 중앙 서버와 통신할 수 있는 능력을 가지고 있습니다. 이 구성을 사용하면 여러 클라우드 제공업체, 원격 사무소, 내부 네트워크 및 기타 레이아웃에 Sandfly를 배포하면서 모든 노드를 중앙 지점에서 제어할 수 있습니다.
  • 환경이 이 마지막 아키텍처 계층에 속하는 경우, 각 명명된 큐에 대해 수평 및 수직 확장을 사용하는 것을 권장합니다.

노드 차트

노드 호스트당 개념적 최소 확장 (컴테이너 중복성 없음)

차트 참고사항:

• 중요한 인프라에는 권장되지 않으며, 데이터는 주로 확장 고려 목적으로 제공됩니다.
• 명명된 큐 사용을 고려하지 않습니다.

시작 개념적 최소값 (컴테이너 및 호스트 수준 중복성 모두 제공)

차트 참고사항:

• 여러 노드 중 하나가 실패하는 경우, 나머지 노드가 전체 부하를 유지할 수 있어야 합니다.
• 명명된 큐 사용을 고려하지 않습니다.

측정

마지막으로, 모든 호스트에서 CPU 부하, 메모리 사용량, 디스크 I/O, 네트워크 사용량 등과 같은 시스템 리소스 데이터를 정기적으로 수집하는 시스템 모니터링 도구를 사용하면 확장 능력, 구성 미세 조정, 애플리케이션에 영향을 주는 문제 추적에 도움이 될 것입니다.

모든 호스트에서 문제를 일으킬 수 있는 최대 사용량 리소스에 대한 경고를 받을 수 있는 일반적인 기능 외에도, Sandfly 스캔 시간 초과와 같이 영향이 적은 상황이 발생할 때도 동일한 데이터를 분석할 수 있습니다. 또한 이 데이터는 Sandfly 수량 증가나 추가 스케줄 추가로 인한 변화와 같은 전후 조건을 보는 데 유용한 기준선을 만듭니다.

결론

위의 모범 사례와 확장 정보를 적용하면 Sandfly를 모든 크기의 환경에서 신뢰성 있게 실행되도록 설정할 수 있습니다.

확장 및/또는 아키텍처 구성에 대한 추가 지원이 필요한 경우 Sandfly 담당자에게 연락하십시오.