그리드 크기가 초당 바이트로 표현된 처리량에 맞게 조정된 경우 추정 공식을 사용하려면 이 크기를 초당 S3 작업으로 변환해야 합니다. 그리드 처리량을 변환하려면 먼저 평균 개체 크기를 결정해야 합니다. 이는 기존 감사 로그 및 메트릭(있는 경우)의 정보를 사용하거나 StorageGRID 사용할 애플리케이션에 대한 지식을 사용하여 결정할 수 있습니다. 예를 들어, 그리드 크기가 초당 2,000MB의 처리량을 달성하도록 조정되었고 평균 객체 크기가 2MB인 경우 그리드 크기는 초당 1,000개의 S3 작업(2,000MB/2MB)을 처리할 수 있도록 조정된 것입니다.

그리드에서 지원할 것으로 예상되는 초당 S3 작업 수 외에 S3 작업 부하에 대한 정보가 없는 경우, 감사 수준을 기본값(모든 범주가 '일반'으로 설정되고, 저장소는 '오류'로 설정됨)으로 설정했다고 가정하고 다음 공식을 사용하여 외부 syslog 서버가 처리해야 하는 감사 로그 볼륨을 추정할 수 있습니다.

예를 들어, 그리드 크기가 초당 1,000개의 S3 작업에 적합한 경우 외부 시스템 로그 서버는 초당 2,000개의 시스템 로그 메시지를 지원하도록 크기가 조정되어야 하며 초당 1.6MB의 속도로 감사 로그 데이터를 수신(일반적으로 저장)할 수 있어야 합니다.

업무량에 대해 더 많이 알면 더 정확한 추정이 가능합니다. 감사 로그의 경우 가장 중요한 추가 변수는 S3 작업 중 PUT(GETS 대비)의 비율과 다음 S3 필드의 평균 크기(바이트)입니다(표에 사용된 4자리 약어는 감사 로그 필드 이름입니다).

S3 작업 중 PUT인 비율을 나타내기 위해 P를 사용합니다. 여기서 0 ≤ P ≤ 1입니다(따라서 100% PUT 워크로드의 경우 P = 1, 100% GET 워크로드의 경우 P = 0).

S3 계정 이름, S3 버킷, S3 키의 합의 평균 크기를 K로 나타내 보겠습니다. S3 계정 이름이 항상 my-s3-account(13바이트)이고, 버킷의 이름이 /my/application/bucket-12345(28바이트)와 같이 고정 길이이고, 객체의 키가 5733a5d7-f069-41ef-8fbd-13247494c69c(36바이트)와 같이 고정 길이라고 가정합니다. 그러면 K의 값은 90(13+13+28+36)입니다.

P와 K 값을 결정할 수 있다면 다음 공식을 사용하여 외부 시스템 로그 서버가 처리해야 할 감사 로그의 양을 추정할 수 있습니다. 이 때 감사 수준은 기본값(저장소를 제외한 모든 범주는 일반으로 설정, 저장소는 오류로 설정)으로 설정되어 있어야 합니다.

예를 들어, 그리드 크기가 초당 1,000개의 S3 작업에 맞게 조정되고, 작업 부하가 50% PUT이며, S3 계정 이름, 버킷 이름, 객체 이름의 평균 크기가 90바이트인 경우, 외부 syslog 서버는 초당 1,500개의 syslog 메시지를 지원하도록 크기를 조정해야 하며, 초당 약 1MB의 속도로 감사 로그 데이터를 수신(일반적으로 저장)할 수 있어야 합니다.

감사 로그에 제공된 수식은 기본 감사 수준 설정(모든 범주가 '일반'으로 설정되고, '저장소'는 '오류'로 설정됨)을 사용한다고 가정합니다. 기본이 아닌 감사 수준 설정에 대한 감사 메시지의 속도와 평균 크기를 추정하기 위한 자세한 공식은 제공되지 않습니다. 그러나 다음 표를 사용하면 비율을 대략적으로 추정할 수 있습니다. 감사 로그에 대해 제공된 평균 크기 공식을 사용할 수 있지만, "추가" 감사 메시지가 평균적으로 기본 감사 메시지보다 작기 때문에 과대 추정이 발생할 가능성이 있다는 점에 유의하세요.

보안 이벤트는 S3 작업과 연관이 없으며 일반적으로 무시할 수 있는 양의 로그와 데이터를 생성합니다. 이러한 이유로 추정 공식은 제공되지 않습니다.

그리드에서 지원할 것으로 예상되는 초당 S3 작업 수 외에 S3 작업 부하에 대한 정보가 없는 경우 다음 공식을 사용하여 외부 syslog 서버에서 처리해야 하는 애플리케이션 로그 볼륨을 추정할 수 있습니다.

예를 들어, 그리드 크기가 초당 1,000개의 S3 작업에 적합한 경우 외부 시스템 로그 서버는 초당 3,300개의 애플리케이션 로그를 지원하도록 크기가 조정되어야 하며 초당 약 1.2MB의 속도로 애플리케이션 로그 데이터를 수신(및 저장)할 수 있어야 합니다.

업무량에 대해 더 많이 알면 더 정확한 추정이 가능합니다. 애플리케이션 로그의 경우 가장 중요한 추가 변수는 데이터 보호 전략(복제 대 삭제 코딩), PUT(대 GET/기타)인 S3 작업의 비율, 다음 S3 필드의 평균 크기(바이트)입니다(표에 사용된 4자리 약어는 감사 로그 필드 이름입니다).

P는 S3 작업 중 PUT인 비율을 나타내며, 여기서 0 ≤ P ≤ 1입니다(따라서 100% PUT 워크로드의 경우 P = 1, 100% GET 워크로드의 경우 P = 0).

K는 S3 계정 이름, S3 버킷, S3 키의 합의 평균 크기를 나타냅니다. S3 계정 이름이 항상 my-s3-account(13바이트)이고, 버킷의 이름이 /my/application/bucket-12345(28바이트)와 같이 고정 길이이고, 객체의 키가 5733a5d7-f069-41ef-8fbd-13247494c69c(36바이트)와 같이 고정 길이라고 가정합니다. 그러면 K의 값은 90(13+13+28+36)이 됩니다.

P와 K의 값을 결정할 수 있다면 다음 공식을 사용하여 외부 syslog 서버가 처리해야 할 애플리케이션 로그의 볼륨을 추정할 수 있습니다.

예를 들어 그리드 크기가 초당 1,000개의 S3 작업에 맞게 조정되고, 작업 부하가 50% PUT이며, S3 계정 이름, 버킷 이름, 객체 이름의 평균 크기가 90바이트인 경우, 외부 syslog 서버는 초당 1,800개의 애플리케이션 로그를 지원하도록 크기가 조정되어야 하며, 초당 0.5MB의 속도로 애플리케이션 데이터를 수신(일반적으로 저장)하게 됩니다.

P는 S3 작업 중 PUT인 비율을 나타내며, 여기서 0 ≤ P ≤ 1입니다(따라서 100% PUT 워크로드의 경우 P = 1, 100% GET 워크로드의 경우 P = 0).

K는 S3 계정 이름, S3 버킷, S3 키의 합의 평균 크기를 나타냅니다. S3 계정 이름이 항상 my-s3-account(13바이트)이고, 버킷의 이름이 /my/application/bucket-12345(28바이트)와 같이 고정 길이이고, 객체의 키가 5733a5d7-f069-41ef-8fbd-13247494c69c(36바이트)와 같이 고정 길이라고 가정합니다. 그러면 K의 값은 90(13+13+28+36)이 됩니다.

P와 K의 값을 결정할 수 있다면 다음 공식을 사용하여 외부 syslog 서버가 처리해야 할 애플리케이션 로그의 볼륨을 추정할 수 있습니다.

예를 들어 그리드 크기가 초당 1,000개의 S3 작업에 적합하고, 작업 부하가 50% PUT이며, S3 계정 이름, 버킷 이름, 객체 이름의 평균이 90바이트인 경우, 외부 syslog 서버는 초당 2,250개의 애플리케이션 로그를 지원하도록 크기를 조정해야 하며 초당 0.6MB의 속도로 애플리케이션 데이터를 수신(일반적으로 저장)할 수 있어야 합니다.