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

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

예를 들어, 그리드가 초당 1,000건의 S3 작업을 처리하도록 설계된 경우, 외부 syslog 서버는 초당 2,000건의 syslog 메시지를 지원할 수 있도록 설계되어야 하며, 초당 1.6MB의 속도로 감사 로그 데이터를 수신(및 일반적으로 저장)할 수 있어야 합니다.

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

S3 작업 중 PUT 작업의 비율을 P로 나타내겠습니다. 여기서 P는 0 ≤ P ≤ 1입니다(즉, PUT 작업이 100%인 경우 P = 1이고, GET 작업이 100%인 경우 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 값을 결정할 수 있다면, 감사 수준을 기본값(Storage 범주를 제외한 모든 범주를 Normal로 설정하고 Storage 범주만 Error로 설정)으로 유지한다는 가정 하에 다음 공식을 사용하여 외부 syslog 서버에서 처리해야 할 감사 로그의 양을 추정할 수 있습니다.

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

제공된 감사 로그 계산 공식은 기본 감사 수준 설정(저장소 범주를 제외한 모든 범주가 '일반'으로 설정되고 저장소 범주는 '오류'로 설정됨)을 기준으로 합니다. 기본값이 아닌 감사 수준 설정에 대한 감사 메시지 발생률 및 평균 크기를 추정하는 자세한 공식은 제공되지 않습니다. 그러나 다음 표를 사용하여 대략적인 발생률을 추정할 수 있습니다. 감사 로그에 제공된 평균 크기 공식을 사용할 수도 있지만, '추가' 감사 메시지는 평균적으로 기본 감사 메시지보다 크기가 작기 때문에 실제보다 과대평가될 가능성이 높다는 점에 유의하시기 바랍니다.

보안 이벤트는 S3 작업과 상관관계가 없으며 일반적으로 로그 및 데이터 양이 매우 적습니다. 따라서 추정 공식은 제공되지 않습니다.

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

예를 들어, 그리드가 초당 1,000건의 S3 작업을 처리하도록 설계된 경우, 외부 syslog 서버는 초당 3,300건의 애플리케이션 로그를 지원하고 초당 약 1.2MB의 속도로 애플리케이션 로그 데이터를 수신(및 저장)할 수 있도록 설계되어야 합니다.

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

P는 S3 작업 중 PUT 작업의 비율을 나타내며, 0 ≤ P ≤ 1입니다(즉, PUT 작업량이 100%인 경우 P = 1이고, GET 작업량이 100%인 경우 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입니다(즉, PUT 작업량이 100%인 경우 P = 1이고, GET 작업량이 100%인 경우 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의 속도로 애플리케이션 데이터를 수신(및 저장)할 수 있어야 합니다.