검색 결과가 없습니다

검색어와 일치하는 결과가 없습니다.

원하시는 정보를 찾는 데 도움이 되도록 다음을 시도해 보십시오.

  • 검색에 사용하신 키워드의 철자가 올바른지 확인하십시오.
  • 입력한 키워드에 동의어를 사용하십시오. 예를 들어 “소프트웨어” 대신 “애플리케이션”을 사용해 보십시오.
  • 아래에 표시된 인기 검색어 중 하나를 사용해 보십시오.
  • 새로운 검색을 시작하십시오.
인기 질문

FAQ

모두 열기 모두 닫기

    일반적인 질문

  • Oracle Cloud Infrastructure Streaming(OCI Streaming)이란 무엇입니까?

    Oracle Cloud Infrastructure Streaming 서비스는 거의 실시간으로 소비 및 처리할 수 있는 지속적으로 대용량 데이터 스트림을 위한 완전 관리, 확장 및 내구성이 뛰어난 스토리지 옵션을 제공합니다.

    자세한 내용은 설명서의 다음 주제를 살펴보시기 바랍니다.

  • Streaming 서비스가 이용 가능한 곳은 어디입니까?

    현재 Streaming 서비스가 제공되는 지역 목록은 설명서를 참조하시기 바랍니다.

  • API 엔드포인트란 무엇입니까?

    API 엔드 포인트는 다음과 같이 구성됩니다. https://streaming.$_REGION.oci.oraclecloud.com

    변수의 예 :

    • us-phoenix-1
    • us-ashburn-1
  • OCI Streaming은 무엇을 관리합니까?

    OCI Streaming은 기본 인프라에서 프로비저닝, 배포, 유지 보수, 보안 패치, 복제 및 소비자 그룹에 이르기까지 완벽하게 관리되므로 어플리케이션 개발이 더욱 쉬워집니다.

  • Oracle Cloud Infrastructure Streaming는 어떻게 복원력을 제공합니까?

    OCI Streaming 내에 스트림을 생성하면 Oracle은 3개의 서로 다른 AD(또는 단일 AD 영역의 장애 도메인)에 분산된 3개의 Streaming 노드를 자동으로 생성 및 관리하여 스트림의 가용성과 데이터 내구성을 유지합니다.

  • OCI Streaming으로 무엇을 할 수 있습니까?

    OCI Streaming을 사용하면 거의 실시간으로 데이터를 내보내고 검색할 수 있습니다. 메시징에서 복잡한 데이터 스트림 처리에 이르기까지 거의 무제한의 사용 사례에 활용할 수 있습니다.

    Streaming을 사용할 수 있는 여러 가지 사용 방법 중 몇 가지는 다음과 같습니다.

    • 메시징: 스트리밍을 사용하여 대형 시스템의 구성 요소를 분리합니다. Streaming은 부하 급증 현상을 평탄화할 수 있는 충분한 용량 및 여러 소비자에게 동일한 데이터를 독립적으로 공급할 수 있는 기능을 갖춘 풀/버퍼 기반 커뮤니케이션 모델을 제공합니다. 키 범위 주문과 보장된 내구성으로 다양한 메시징 패턴을 구현할 수 있는 신뢰성 있는 기본 요소를 제공하는 한편, 높은 처리량 잠재성을 통해 이러한 시스템을 원활하게 확장할 수 있습니다.
    • 측정 지표 및 로그 수집: 스트리밍을 기존의 파일 스크래핑 방식의 대안으로 사용하여 중요한 운영 데이터를 인덱싱, 분석 및 시각화에 보다 신속하게 사용할 수 있습니다.
    • 웹/모바일 활동 데이터 수집: 웹사이트 또는 모바일 앱(예: 페이지 보기, 검색 또는 사용자가 수행할 수 있는 기타 작업)의 활동을 캡처하는 데 스트리밍을 사용합니다. 실시간 모니터링 및 분석은 물론 오프라인 처리 및 보고를 위한 데이터 웨어하우징 시스템에도 이 정보를 사용할 수 있습니다.
    • 인프라 및 앱 이벤트 처리: Streaming을 클라우드 구성요소의 통합 진입점으로 사용하여 감사, 회계 및 관련 활동에 대한 수명 주기 이벤트를 보고합니다.
  • OCI Streaming은 어떻게 사용합니까?

    다음을 통해 OCI Streaming 사용을 시작하십시오.

    • OCI Streaming Console 또는 CreateTopic API를 통해 새 스트림 생성
    • 생산자에서 주제로 데이터 내보내기(자세한 설명서 참조)
    • 스트림에서 데이터를 읽고 처리할 수 있는 소비자 구축
  • OCI Streaming의 한계는 무엇입니까?

    전체적으로 액세스할 수 있는 처리량에는 제한이 없습니다. 올바른 수의 파티션을 사용하여 스트림을 미리 설계하기만 하면 됩니다.

    시스템의 한도는 다음과 같습니다.

    • 보존 기간은 최대 7일입니다.
    • 고유한 메시지의 최대 크기는 1MB입니다.
    • 각 파티션은 초당 5회의 읽기 API 호출을 처리할 수 있으며 쓰기 요청 수는 초당 1MB입니다.
    • 각 파티션은 초당 최대 1MB의 데이터 쓰기 속도와 초당 2MB의 읽기 속도를 지원할 수 있습니다.
    • 각 테넌시는 5개의 파티션으로 제한되지만 더 많은 파티션을 요청할 수 있습니다 - 문의하기
  • Oracle Cloud Infrastructure CLI에서 Streaming을 어떻게 사용합니까?

    oci-cli 이진 파일에 포함된 GitHub에서 예제를 사용할 수 있습니다.

  • 파티션에 어떻게 액세스합니까?

    API에서 파티션은 문자열로 표시됩니다.

    파티션이 5개인 스트림을 만드는 경우 "0", "1", "2", "3" 또는 "4" 문자열을 사용하여 스트림에 액세스할 수 있습니다.

    파티션 식별자를 숫자 값으로 표시하지 않습니다.

    오프셋이 조밀하지 않습니다. 메시지 오프셋은 항상 증가하지만 때로는 1만큼 증가하지 않을 수도 있습니다. 향후 오프셋 계산을 위해 이를 사용하지 마십시오.

    예를 들어 동일한 파티션에 있는 두 개의 메시지를 게시하는 경우 첫 번째 메시지는 오프셋 42, 두 번째 메시지는 오프셋 45를 가질 수 있습니다(오프셋 43 및 44가 존재하지 않음).

    주요 컨셉

  • 스트림이란 무엇입니까?

    스트림은 메시지가 포함된 추가 전용 로그 파일로 볼 수 있습니다.

  • 파티션은 무엇입니까?

    스트림은 확장성을 위해 여러 파티션으로 나뉩니다. 파티션을 사용하면 메시지를 여러 노드(또는 브로커)로 분할하여 스트림을 분배할 수 있습니다. 각 파티션을 별도의 컴퓨터에 배치하여 여러 소비자가 주제에서 동시에 읽을 수 있습니다.

  • 메시지는 무엇입니까?

    64비트 인코딩 메시지는 사용자가 주제로 내보내는 메시지입니다.

  • 오프셋이란 무엇입니까?

    파티션 내의 각 메시지에는 오프셋이라는 식별자가 있습니다. 소비자는 특정 오프셋에서 시작해서 메시지를 읽을 수 있으며, 어느 오프셋 지점에서든 읽을 수 있습니다. 또한 소비자가 최신 처리된 오프셋을 커밋하여 중지했다가 다시 시작할 경우 메시지를 표시하거나 누락하지 않고 작업을 재개할 수 있습니다.

  • 키는 무엇입니까?

    키는 관련 메시지를 그룹화하는 데 사용되는 식별자입니다.

    스트림 만들기

  • 새로운 스트림은 어떻게 만듭니까?

    Console 또는 API를 사용하여 새 스트림을 만들 수 있습니다. 여기에서 API를 참조하십시오.

    스트림은 특정 지역 및 테넌시 및 선택적으로 전용 구획을 위해 생성됩니다. 스트림 데이터는 전체 영역에 걸쳐 복제되므로 서비스를 중단하지 않고 AD 손실이나 네트워크 분할을 견딜 수 있으며 리전 내에서 고가용성을 제공합니다.

  • 프로비저닝에 시간이 얼마나 걸립니까?

    프로비저닝 시간은 파티션 수에 따라 다릅니다. 새 파티션을 만드는 데 최대 10초가 걸립니다.

  • 필요한 파티션 수를 어떻게 결정합니까?

    스트림의 파티션 수는 어플리케이션의 예상 처리량에 따라 달라집니다(예상 처리량 = 평균 수신 크기 x 초당 기록된 최대 레코드 수).

  • 스트림에 요청할 수 있는 최소 처리량은 얼마입니까?

    Oracle Cloud Infrastructure 스트림의 처리량은 파티션에 의해 정의됩니다. 파티션은 1MB/sec 데이터 입력과 2MB/sec 데이터 출력을 제공합니다.

  • 파티션에 몇 개의 요청을 보낼 수 있습니까?

    초당 1,000개의 요청을 파티션으로 보낼 수 있습니다.

  • SDK는 어떻게 사용합니까?

    Streaming 서비스의 주요 API 예는 설명서에 안내되어 있습니다.

    예제는 다음 API를 포함합니다.

  • SDK는 어디서 찾을 수 있습니까?
  • 더 많은 언어를 지원할 계획입니까?

    Streaming SDK는 다른 OCI SDK 구현과 동일한 언어를 지원하며 Streaming 서비스에 대해 특별히 지원되는 추가 언어는 없습니다.

  • 스트리밍에 필요한 모든 API 목록을 어디에서 찾을 수 있습니까?

    스트림에 데이터 게시하기

  • 스트림으로 데이터를 내보내려면 어떻게 해야 합니까?

    스트림이 생성되고 활성화되면 메시지를 게시할 수 있습니다. 게시를 위해 Write API (putMessages)를 사용할 수 있습니다. 메시지는 스트림의 파티션에 게시됩니다. 파티션이 두 개 이상 있는 경우 메시지를 게시할 파티션이 메시지 키를 사용하여 계산됩니다.

  • Null 키를 보낼 때 OCI 스트리밍이 데이터를 어떻게 저장합니까?

    키가 null이면 값의 하위 집합을 사용하여 파티션이 계산됩니다. null 키가 있는 메시지의 경우 파티션 스키마가 변경될 수 있으므로 동일한 값의 메시지가 동일한 파티션에 있을 것으로 예상하지 마십시오. null 키를 보내면 메시지가 실제로 임의 파티션에 저장됩니다.

  • OCI Streaming에서 메시지 순서를 어떻게 확인합니까?

    값이 같은 메시지가 동일한 파티션으로 이동하도록 하려면 해당 메시지에 동일한 키를 사용해야 합니다.

  • 메시지가 내구성이 있는지 어떻게 확인합니까?

    OCI Streaming API가 putMessage를 오류 없이 승인하면 메시지에 내구성이 있는 것입니다.

  • OCI Streaming 스트림에서 데이터의 일관성을 어떻게 보장합니까?

    OCI Streaming 선형 읽기 및 파티션 키 쓰기를 보장합니다.

  • 승인된 최댓값보다 많은 데이터를 내보내기하면 어떻게 됩니까?

    클라이언트 요청이 제한을 초과하면 OCI Streaming에서 요청을 거부하고 오류 예외 메시지를 보냅니다.

  • 언제 제한을 받습니까?

    다음 임계 값을 초과하면 제한 메커니즘이 활성화됩니다.

    • GetMessages: 초당 5회 호출 또는 파티션당 2MB/s
    • PutMessages: 파티션당 1MB/s
    • 관리 및 제어 패널 작업 (CreateCursor, listStream 등): 스트림당 초당 호출 5개
  • 메시지를 일괄 처리해야 합니까?

    다음과 같은 이유로 메시지 일괄 처리를 권장합니다.

    • 서비스로 전송되는 Put 요청 수를 줄여 제한 방지
    • 처리량 향상 지원

    메시지 일괄 처리의 크기는 1MB를 초과하지 않아야합니다. 이 한계를 초과하면 조절 메커니즘이 트리거됩니다.

  • 1MB보다 큰 메시지는 어떻게 처리합니까?

    다음 방법 중 하나를 사용할 수 있습니다. 청크화 또는 Object Storage를 통해 메시지 전송

  • 청크화

    큰 페이로드의 경우 Streaming 서비스에서 수용할 수 있는 여러 개의 작은 청크로 분할할 수 있습니다.

    청크는 일반(청크화되지 않은) 메시지가 저장되는 것과 동일한 방식으로 서비스에 저장됩니다. 유일한 차이점은 소비자가 청크를 보관하고 모든 청크를 수집했을 때 이를 실제 메시지로 결합해야 한다는 것입니다.

    파티션의 청크는 일반 메시지와 함께 사용할 수 있습니다.

  • Object Storage

    큰 페이로드는 Object Storage에 저장되고 해당 데이터에 대한 포인터만 전송됩니다. 수신기는 이러한 유형의 포인터 페이로드를 인식하고 Object Storage에서 데이터를 투명하게 읽어 최종 사용자에게 제공합니다.

  • 서비스는 어떤 날짜 형식을 허용합니까?

    일반적인 실수는 잘못된 날짜 형식을 제공하는 것입니다.

    Streaming 서비스는 모든 날짜의 시간대를 포함하여 ISO-8601을 지원합니다.

  • 메시지를 게시하는 동안 Streaming 서비스에서 파티션 번호 및 오프셋을 얻으려면 어떻게 해야 합니까?

    PutMessagesResultsEntry 클래스는 다음과 같은 메서드를 제공합니다.

    • getPartition - 메시지가 게시된 파티션 번호 제공
    • getOffset - 게시된 메시지의 오프셋 제공
  • 메시지를 게시하지 않고 Streaming 서비스에서 파티션 번호 및 오프셋을 얻으려면 어떻게 해야 합니까?

    현재는 메시지를 게시하지 않으면 최근에 게시된 메시지를 볼 수 없습니다.

    그룹 또는 파티션별로 최신 커밋된 오프셋을 볼 수 있는 메커니즘이 있습니다. getGroup 엔드포인트를 살펴보십시오.

    스트림에서 데이터 소비 - 단일 소비자

  • 스트림에서 데이터를 어떻게 읽고 소비할 수 있습니까?

    메시지를 사용하려면 다음이 필요합니다.

    • 커서 만들기
    • 커서를 사용하여 메시지를 읽습니다.
    • 스트림에서 데이터를 사용하는 방법에 대한 단계별 가이드는 기술 문서를 참조하십시오.

  • OCI Streaming Stream에서 데이터를 소비할 수 있는 다른 방법은 무엇입니까?

    OCI Streaming은 두 가지 종류의 소비 API를 제공합니다.

    • 파티션 및 오프셋을 정밀하게 제어하여 데이터를 읽기 위한 로우 레벨 검사
    • 로드 밸런싱, 조정 및 오프셋 추적을 서비스로 오프로드하여 어플리케이션 개발을 단순화하는 소비자 그룹
  • 소비자 그룹은 어떻게 작동합니까?

    소비자들이 그룹의 일부로 메시지를 사용하도록 구성할 수 있습니다. 스트림 파티션은 그룹의 구성원 간에 배포되므로 단일 파티션의 메시지는 단일 소비자에게만 전송됩니다.

    소비자가 그룹에 참여하거나 탈퇴할 때 파티션 할당이 재조정됩니다.

  • 소비자에게 메시지가 중복되지 않도록 하려면 어떻게 해야 합니까?

    소비자 어플리케이션에서 중복 작업을 처리하는 것이 좋습니다.

  • 소비자가 뒤처지는 경우 어떻게 알 수 있습니까?

    메시지의 타임스탬프와 현재 시간 사이의 차이를 사용해서 소비자가 뒤처지는지(소비 속도보다 생산 속도가 더 빠른지) 확인할 수 있습니다. 이 숫자가 증가하면 새 소비자가 생성되어 첫 번째 소비자로부터 파티션을 일부 인수할 수 있습니다.

  • 단일 소비자란 무엇입니까?

    단일 소비자는 하나 이상의 스트림에서 메시지를 읽는 엔터티입니다.

    이 엔터티는 단독으로 존재할 수도 있고 소비자 그룹의 일부로 포함되어 있을 수도 있습니다.

  • 커서란 무엇입니까?

    스트림의 위치에 대한 포인터입니다. 이 위치는 파티션의 특정 오프셋 또는 시간에 대한 포인터이거나 그룹의 현재 위치에 대한 포인터일 수 있습니다.

  • 사용할 수 있는 커서 유형은 어떤 것이 있습니까?

    다음과 같은 커서 유형을 사용할 수 있습니다. TRIM_HORIZON, AT_OFFSET, AFTER_OFFSET, AT_TIME, 및 LATEST. 자세한 내용은 설명서에서 확인할 수 있습니다.

  • 메시지를 사용할 때마다 커서를 재생성해야 합니까?

    아니오, 커서는 루프 외부에 만들어야 합니다. 커서를 작성한 후 GetMessages 방법을 사용하여 메시지 사용을 시작할 수 있습니다. 각 GetMessages 호출은 다음 GetMessages 호출에서 사용할 커서를 반환합니다.

    반환된 커서는 null이 아니며 5분 후에 만료됩니다. 계속 소비하는 한 커서를 다시 만들 필요가 없습니다.

    GetMessages, Commit, Heartbeat 모두 후속 호출에 사용할 새 커서를 반환합니다.

    Java 코드 스니펫은 설명서에서 확인할 수 있습니다.

    몇 가지 오류 사례에서는 새 커서를 만들어야 합니다. 이를 장애 전략의 일부로 처리하는 것을 권장합니다.

  • 테넌트 B에 속한 소비자가 테넌트 A에 속한 스트림의 메시지를 사용할 수 있습니까?

    정책을 활용하면 가능합니다. 테넌트 A는 테넌트 B에 스트림 풀 액세스 권한을 부여하는 정책을 생성해야 합니다.

  • 오프셋을 어떻게 처리합니까?

    그룹 커서를 사용하지 않는 경우 처리된 오프셋 저장은 소비자가 관리해야 합니다.

    그룹 소비자를 사용하는 경우 오류 발생 시 처리된 오프셋을 커밋할 수 있습니다.

    커서를 만들 때 사용하려는 커서의 종류를 지정합니다. 어플리케이션에서 메시지를 소비하기 시작하면 도달하거나 중지한 오프셋을 저장해야 합니다.

    이 시나리오는 스트림당 하나의 파티션만 사용하여 데모 또는 개념 증명을 수행할 때 유용합니다. 다중 파티션이 있는 프로덕션 환경에서는 소비자 그룹을 사용하는 것이 좋습니다.

  • getMessage 호출에서 몇 개의 메시지를 받을 수 있습니까?

    GetMessageRequest 클래스의 getLimit() 메서드는 최대 메시지 수를 반환합니다. 최대 10,000개의 값을 지정할 수 있습니다. 서비스에서는 기본적으로 최대한 많은 메시지를 반환합니다.

    스트림에서 처리량을 초과하지 않도록 평균 메시지 크기를 고려합니다.

    Streaming 서비스 getMessage 배치 크기는 특정 스트림에 게시된 평균 메시지 크기를 기반으로 합니다.

    스트림에서 데이터 소비 - 소비자 그룹

  • 소비자 그룹은 어떻게 작동합니까?

    자세한 설명은 설명서에서 확인할 수 있습니다.

  • 소비자 그룹을 사용해야 하는 이유는 무엇입니까?

    소비자 그룹은 다음과 같은 장점을 제공합니다.

    • 각 인스턴스는 하나 이상의 파티션(자동으로 할당)에서 메시지를 수신하며 다른 인스턴스(다른 파티션에 할당)가 동일한 메시지를 수신하지 않습니다. 이렇게 하면 인스턴스 수를 확장할 수 있습니다(한 인스턴스가 하나의 파티션만 읽음). 이 경우 그룹에 참여하는 새 인스턴스는 파티션에 할당되지 않고 파티션 유휴 상태의 수에 있습니다.
    • 인스턴스가 있다는 것은 다른 소비자 그룹의 게시/구독 패턴 파티션의 메시지를 다른 그룹의 모든 인스턴스로 전송하는 수단이 있다는 것입니다. 동일한 소비자 그룹 내에서 규칙은 첫 번째 이미지에 표시된 것과 동일하지만 다른 그룹 간에 인스턴스는 두 번째 이미지에 표시된 것과 동일한 메시지를 수신합니다. 이 기능은 파티션 내의 메시지가 다양한 방식으로 처리되는 여러 어플리케이션에 관심 있는 경우에 유용합니다. 모든 관련 어플리케이션이 파티션에서 동일한 메시지를 수신하는 것이 목표입니다.
    • 소비자 그룹의 또 다른 장점은 재조정 기능입니다. 인스턴스가 그룹에 참여할 때 사용 가능한 파티션(파티션당 인스턴스 1개 제한에 도달하지 못한 경우)이 충분하면 재조정이 시작됩니다. 파티션은 현재 인스턴스와 새 인스턴스에 재할당됩니다. 이와 마찬가지로, 인스턴스가 그룹을 떠나는 경우에도 파티션이 나머지 인스턴스에 재할당됩니다.
    • 오프셋 커밋은 자동으로 관리됩니다.
  • 인스턴스란 무엇입니까?

    인스턴스는 소비자 그룹의 구성원입니다. 그룹 커서가 생성될 때 정의됩니다.

    파티션 읽기는 소비자 그룹의 인스턴스 사이에서 균형을 이룹니다.

    인스턴스 이름은 오프셋 관리와 관련된 작업을 위해 해당 그룹의 구성원을 식별합니다.

    소비자 그룹의 각 구성원마다 고유한 인스턴스 이름을 사용하는 것이 좋습니다.

  • 인스턴스 이름을 지정하는 가장 좋은 방법이 있습니까?

    가장 좋은 방법은 연결된 유용한 정보 문자열을 사용하는 것입니다.

  • 알아야 둬야 할 시간 제한은 무엇입니까?

    Streaming 서비스의 다음 구성 요소에 시간 제한이 있습니다.

    • 커서: 메시지를 계속 사용하는 한 새 커서를 만들지 않아도 됩니다. 메시지 사용이 5분 이상 중지된 경우 커서를 다시 만들어야 합니다.
    • 인스턴스: 인스턴스가 30초 이상 메시지 사용을 중지하면 소비자 그룹에서 제거되고 해당 파티션이 다른 인스턴스에 다시 할당됩니다(조정이 트리거됨).
  • 인스턴스가 시간 제한에 걸리기 전에 하트비트를 얼마나 오래 기다려야 합니까?

    소비자 그룹 내의 각 인스턴스는 30초 시간 제한 전에 하트비트를 실행해야 합니다. 예를 들어 메시지를 처리하는 데 시간이 너무 오래 걸리는 경우 인스턴스가 하트비트를 보내는 것이 좋습니다.

  • 인스턴스 시간이 초과되면 어떻게 됩니까?

    30초 시간 제한에 도달하면 인스턴스가 소비자 그룹에서 제거되고 해당 파티션이 다른 인스턴스에 재할당됩니다(가능한 경우). 이 이벤트를 재조정이라고합니다.

  • 소비자 그룹 내에서 재조정이란 무엇입니까?

    재조정이란 동일한 소비자 그룹에 속한 인스턴스 그룹이 특정 스트림에 속하는 상호 배타적인 파티션 집합을 소유하도록 조정하는 프로세스입니다.

    소비자 그룹에 대한 재조정 작업이 성공적으로 끝나면 스트림 내의 모든 파티션이 그룹 내의 단일 또는 여러 소비자 인스턴스에 의해 소유됩니다.

  • 유효한 파티션 키를 생성하려면 어떻게 해야 합니까?

    균일한 배분을 위해 메시지 키에 대한 올바른 값을 만들어야 합니다. 이를 위해서는 스트리밍 데이터의 선택성과 카디널리티를 고려해야 합니다.

    • 카디널리티: 특정 사용 사례에 따라 잠재적으로 생성될 수 있는 총 고유 키 수를 고려합니다. 일반적으로 키 카디널리티가 높을수록 분배가 개선됩니다.
    • 선택성: 각 키의 메시지 수를 고려합니다. 선택성이 높으면 키당 더 많은 메시지가 표시되므로 핫스팟이 발생할 수 있습니다.

    낮은 선택성으로 높은 카디널리티를 목표로 하십시오.

  • 메시지가 어떤 파티션으로 전달됩니까?

    Streaming 서비스에서 키는 해시된 다음 파티션을 결정하는 데 사용됩니다. 동일한 키를 가진 메시지는 동일한 파티션으로 이동합니다. 키가 다른 메시지는 다른 파티션이나 같은 파티션으로 이동할 수 있습니다.

  • 메시지가 특정 파티션으로 이동하게 할 수 있습니까?

    제작자로서, 사용자가 메시지의 파티션을 명시적으로 제어할 수 있는 방법은 없습니다.

    데이터가 키와 함께 전송되는 경우 제작자는 데이터를 특정 파티션으로 강제 전송할 수 없습니다.

  • 스레드 간에 StreamClient 인스턴스를 공유할 수 있습니까?

    예, StreamClient는 스레드로부터 안전합니다.

    개체가 상태 비저장 상태인 경우 호출 간에 데이터를 유지할 필요가 없습니다. 수정할 상태가 없으므로 한 스레드는 개체의 작업을 호출하는 다른 스레드의 결과에 영향을 줄 수 없습니다. 이러한 이유로 상태 비 저장 클래스는 본질적으로 스레드로부터 안전합니다.

  • 현재 파티션에 몇 개의 메시지가 있습니까?

    소비자 지연은 스트리밍 서비스에서 아직 구현되지 않았습니다.

    각 메시지에 대해 생성된 오프셋은 각 putMessage 호출이 성공한 후에 반환됩니다.

    메시지 오프셋은 getMessage 호출로 반환되는 모든 메시지에 포함됩니다.

    생성된 오프셋과 사용된 오프셋 사이의 델타를 파티션별로 추적하여 지연 시간을 확인할 수 있습니다.

  • 메시지 소비량이 뒤처지고 있는지 어떻게 알 수 있습니까?

    메시지의 타임스탬프를 사용해 소비자가 뒤처지고 있는지(사용 속도보다 생성 속도가 빠른 경우) 확인할 수 있습니다. 소비자가 뒤처지고 있다면 새 소비자를 생성하여 첫 소비자로부터 파티션을 일부 인수하는 것을 고려하십시오. 단일 파티션에서 뒤처지는 경우에는 복구할 방법이 없습니다.

    다음 옵션을 고려하십시오.

    • 스트림에서 파티션 수를 늘립니다.
    • 핫스팟으로 인해 문제가 발생한 경우 메시지 키 전략을 변경합니다.
    • 메시지 처리 시간을 줄이거나 동시에 요청을 처리합니다.

    지정된 파티션에서 소비할 메시지 수를 확인하려면 커서 유형을 사용하여 마지막에서 두 번째로 게시한 메시지의 오프셋을 가져오고 현재 소비 중인 오프셋을 사용하여 델타를 만듭니다.

    조밀도 오프셋이 없기 때문에 그러나 제작자가 제작을 중단하면 다음에 게시된 메시지의 오프셋을 얻을 수 없으므로 해당 정보만 얻기 위해 대략적인 견적을 낼 수는 없습니다.

  • 소비자 A에 파티션 1에 대한 커서가 있지만 파티션이 30초 시간 제한 전에 새 소비 장치에 재할당되는 경우 예상되는 동작은 무엇입니까?

    재할당은 커밋 및 시간 초과 시에만 발생합니다. commitOnGet=trueprocessing이 30초 이상 걸리는 경우 하트비트를 활용하는 것이 좋습니다.

    사용자 지정 커밋 논리를 작성하는 것은 복잡하며 경쟁 조건과 고려해야 할 사항이 많습니다. 내부 상태가 일부 변경되는 경우가 많고, 클라이언트가 이 상황을 처리해야 합니다.

  • 소비자 그룹의 인스턴스가 비활성화되면 어떻게 됩니까?

    예, StreamClient는 스레드로부터 안전합니다.

    소비자 그룹의 인스턴스는 30초 이상 하트비트를 전송하지 않거나 프로세스가 종료된 경우 비활성 상태로 간주됩니다.

    이 경우 비활성 인스턴스에서 이전에 사용한 파티션을 처리하기 위해 소비자 그룹 내의 균형 조정이 발생합니다.

  • 이전에 비활성 상태였던 소비자 그룹의 인스턴스가 그룹에 다시 참여하면 어떻게 됩니까?

    이러한 인스턴스는 새로운 인스턴스로 간주됩니다. 재조정이 트리거되고 인스턴스에는 메시지 사용을 시작하기 위한 파티션이 할당됩니다.

    Streaming 서비스는 동일한 파티션(종료 전에 할당된 파티션)이 이 인스턴스에 재할당되는지 여부를 보장하지 않습니다.

  • 이전에 비활성화된 소비자 그룹의 인스턴스가 그룹에 다시 참여할 때 중복된 메시지를 사용합니까?

    Streaming 서비스는 소비자 그룹에 '최소 1회' 시맨틱을 제공합니다. 메시지 루프에서 오프셋이 커밋되는 시기를 고려하십시오. 소비자가 메시지 배치를 커밋하기 전에 충돌하는 경우 해당 배치가 다른 소비자에게 제공될 수 있습니다. 파티션이 다른 소비자에게 제공되면 소비자는 최신 커밋된 오프셋을 사용하여 소비를 시작합니다. 소비자는 커밋된 오프셋 이전에 메시지를 받지 않습니다.

  • 오프셋 커밋을 어떻게 처리해야 합니까?

    Streaming 서비스는 getCommitOnGetis가 true로 설정된 경우 소비자 그룹에 대한 오프셋 커밋을 자동으로 처리합니다.

    어플리케이션의 복잡성을 줄이기 위해 이 방법을 사용하는 것이 좋습니다. 즉, 어플리케이션은 커밋 메커니즘을 구현하지 않아야 합니다.

    이 설정을 덮어쓰고 사용자 지정 오프셋 커밋 메커니즘을 구현하려면 소비자 그룹을 만드는 동안 getCommitOnGetto를 false로 설정합니다.

  • CommitOnGet은 어떻게 작동합니까?

    CommitOnGet은 이전 요청의 오프셋이 커밋됨을 의미합니다. 이 기능을 설명하기 위해 다음 예제를 고려하십시오.

    소비자 A:

    • A가 getMessages를 호출하고 오프셋이 1~100인 임의의 파티션에서 메시지를 받습니다.
    • A가 100개의 메시지를 모두 성공적으로 처리
    • A가 getMessages를 호출하면 Streaming 서비스에서 오프셋 100을 커밋하고 오프셋 101~200의 메시지를 반환합니다.
    • A가 15개의 메시지를 처리한 후 30초 이상 예기치 않게 오프라인 상태가 됩니다.

    오케스트레이션 시스템에서 시작하는 새로운 소비자 B:

    • B가 getMessages를 호출하면 Streaming 서비스는 최신 커밋된 오프셋을 사용하고 오프셋이 101~200 인 메시지를 반환합니다.
    • B가 메시지 루프를 계속합니다.

    이 예에서는 메시지가 손실되지 않았지만 오프셋 101–115가 한 번 이상 처리되었으므로 메시지를 두 번 이상 처리할 수 있었다는 뜻이 됩니다.

    이 예에서는 메시지의 일부(15개)가 처리되어 오류 Bevent 후 새 소비자에게 다시 전달될 수 있지만 데이터가 손실되지 않습니다.

  • 다중 파티션 스트림의 단일 파티션에 대한 보존 기간을 초과한 오프셋은 어떻게 업데이트합니까?

    현재로서는 소비자 그룹의 개별 파티션을 업데이트할 수 없습니다.

    updateGroup 호출의 현재 동작은 모든 파티션에 대해 committedOffset을 재설정하는 것이며, 이로 인해 다른 정상 소비자에게 할당된 파티션에 대해 불필요한 이전 메시지 검색이 발생합니다.

  • 하트비트를 보내야 하는 이유는 무엇입니까?

    소비자 그룹에서 메시지를 소비하는 인스턴스는 30초 시간 제한에 도달하기 전에 하트비트를 보내야 합니다. 인스턴스가 하트비트를 보내지 못하면 Streaming 서비스는 인스턴스가 비활성 상태인 것으로 간주하고 해당 파티션의 재할당을 트리거합니다.

  • 이미 커밋된 커서 문자열로 하트비트를 보낼 경우 예상되는 동작은 무엇입니까?

    커밋된 호출에서 검색된 커서는 오프셋이 없어야 합니다. 하트비트가 커서에서 파티션의 시간 제한을 연장합니다.

    빈 커서에 대해 하트비트를 수행하면 아무 작업도 수행되지 않습니다. 이전에 커밋된 커서가 재조정을 트리거할 수 있습니다.

    커서가 커밋된 후 커밋 호출에 의해 반환된 커서가 아닌 커서에 대해 하트비트가 수행되면 포함된 오프셋에 대한 시간 제한을 업데이트합니다.

  • 소비자 장애를 어떻게 복구합니까?

    장애를 복구하려면 마지막으로 처리한 메시지(각 파티션에 대해)의 오프셋을 저장하여, 소비자를 재시작해야 하는 경우 해당 메시지에서 소비를 시작하도록 해야 합니다.

    참고: 커서는 5분 후에 만료되므로 커서를 저장하지 마십시오.

    마지막으로 처리한 메시지의 오프셋을 저장하기 위한 지침은 제공되지 않으므로 원하는 방법(예: 다른 스트림, Kiev, 컴퓨터의 파일 또는 Object Storage)을 사용할 수 있습니다.

    소비자가 다시 시작되면 마지막으로 처리한 메시지의 오프셋을 읽은 다음, 유형 커서를 만들고 AFT_OFFSET이 방금 받은 오프셋을 지정합니다.

    OCI Streaming Stream 관리

  • 나중에 파티션 수를 변경할 수 있습니까?

    최대 처리량보다 약간 높은 파티션을 할당하는 것을 권장합니다. 이렇게 하면 현재 스트림이 생성된 후 파티션 수를 변경하는 것을 지원하지 않으므로 어플리케이션 급증 현상을 관리하는 데 도움이 됩니다.

  • 주제의 내구성을 변경할 수 있습니까?

    기본적으로 데이터는 24시간 동안 저장됩니다. 스트림을 생성하는 동안 최대 7일의 보존 기간을 설정할 수 있습니다. 보존 기간이 정의된 후에는 편집할 수 없습니다.

  • OCI Streaming 스트림의 작동 및 성능을 어떻게 모니터링합니까?

    OCI Streaming 콘솔은 데이터 입력 및 출력의 처리량과 같은 운영 및 성능 측정 지표를 모두 제공합니다. OCI Streaming은 OCI Telemetry와 통합되어 스트림에 대한 원격 측정 측정 지표를 수집, 확인 및 분석할 수 있습니다.

    보안 및 암호화

  • 스트림에 대한 액세스를 어떻게 관리하고 제어합니까?

    동일한 테넌시의 모든 스트림에는 변경 불가능한 고유한 이름이 있습니다. 모든 스트림에는 구획이 할당되어 있습니다. 따라서 Oracle Cloud Infrastructure 액세스 제어 정책의 모든 기능을 사용하여 테넌시, 컴파트먼트 또는 단일 스트림 수준에서 세분화된 규칙을 설명할 수 있습니다.

    액세스 정책은 '허용 위치 ' 형식으로 지정됩니다.

  • OCI Streaming에서 데이터를 내보내거나 사용할 때 어떻게 인증합니까?

    Oracle의 인터넷 API는 Oracle Identity 서비스를 사용합니다. Oracle Identity Service는 브라우저(사용자 이름/비밀번호)와 코드(API Key) 모두에서 사용자를 인증하고 이러한 API에 대한 액세스를 인증할 수 있는 편리한 방법을 제공합니다.

    여기에서 설명서를 확인해보십시오.

  • OCI Streaming의 데이터 보안은 어느 정도입니까?

    OCI Streaming은 기본적으로 안전합니다. 사용자 데이터는 저장 및 이동시 암호화됩니다. 계정 및 데이터 스트림 소유자만 자신이 생성한 스트림 리소스에 액세스할 수 있습니다. OCI Streaming은 데이터에 대한 액세스를 제어하기 위해 사용자 인증을 지원합니다. Oracle Cloud Infrastructure IAM 정책을 사용하여 사용자 및 사용자 그룹에 선택적으로 권한을 부여할 수 있습니다. HTTPS 프로토콜을 사용하여 OCI Streaming에서 SSL 끝점을 통해 데이터를 안전하게 저장하고 가져올 수 있습니다.

  • 데이터를 암호화 할 수 있습니까?

    내보내는 데이터를 소유하며, 데이터를 OSS로 전송하기 전에 암호화할 수 있습니다.

  • OCI Streaming Stream에 데이터를 보내는 시점부터 데이터를 검색하는 시점까지 데이터의 암호화 라이프 사이클을 설명해주시겠습니까?

    수집 (제작자 - Streaming 게이트웨이) SSL(HTTPS)으로 인해 이동 중에 암호화된 데이터

    스트리밍 서비스 내부: 게이트웨이 SSL이 종료되면 스트림당 AES-128 키를 사용하여 도착 시 데이터가 암호화되고 지속성을 위해 스토리지 계층으로 전송됩니다.

    소비 중: 암호화된 데이터는 OSS에서 읽고 게이트웨이 노드에서 암호 해독되어 SSL을 통해 소비자에게 전송됩니다.

    소비 중: 암호화된 데이터는 OCI Streaming에서 읽고 게이트웨이 노드에서 암호 해독되어 SSL을 통해 소비자에게 전송됩니다.

  • OCI Streaming 암호화에는 어떤 암호화 알고리즘이 사용됩니까?

    OCI Streaming은 암호화에 AES-GCM 128 알고리즘을 사용합니다.

    모니터링

  • 어디에서 스트림을 모니터링할 수 있습니까?

    Streaming은 OCI Monitoring 서비스와 완벽하게 통합됩니다. 여기에서 Streaming 측정 지표 설명을 확인할 수 있습니다.

  • Streaming 서비스는 어떤 측정 지표를 내보냅니까?

    Streaming 서비스의 모니터링은 제작자와 소비자에 중점을 둡니다. Streaming 서비스에서 내보내는 측정 지표 목록은 설명서를 참조하십시오.

  • Streaming 서비스 모니터링에서는 어떤 통계가 제공됩니까?

    Console에서 사용 가능한 각 측정 지표은 다음 통계를 제공합니다.

    • 비율, 합계 및 평균
    • 최소, 최대 및 개수
    • P50, P90, P95, P99, P99.9

    이 통계는 4개의 시 구간을 제공

    • 자동
    • 1분
    • 5분
    • 1시간
  • 어떤 측정 지표에 대해 경보를 설정해야 합니까?

    제작자의 경우 다음 측정 지표에 대해 경보를 설정하십시오.

    • Put Messages Latency: 네트워크 문제
    • Put Messages Total Throughput:
      • 총 처리량이 크게 증가하면 파티션당 1MB/s 제한에 도달하고 이벤트가 제한 메커니즘을 트리거한다는 의미일 수 있습니다.
      • 중요한 감소는 클라이언트 제작자가 문제를 겪고 있거나 중단하려고 한다는 의미일 수 있습니다.
    • Put Messages Throttle Records: 메시지를 제한될 때 알림을 받는 것이 중요합니다.
    • Put Messages Failure: Ops 팀이 원인을 조사하기 시작할 수 있도록 Put messages가 실패할 경우 알림을 받는 것이 중요합니다.

    소비자의 경우 다음 측정 지표를 기반으로 동일한 경보를 설정하십시오.

    • Get Messages Latency
    • Get Messages Total Throughput
    • Get Messages Throttled Requests
    • Get Messages Failure
  • 경보를 받으면 어떻게 해야 합니까?

    경보가 트리거되면 담당 팀원이 경보를 조사하고 상황을 평가해야 합니다.

    문제가 고객(제작자 또는 소비자)과 관련된 경우, 팀 구성원이 문제를 해결하거나 Dev 팀과 함께 자세히 조사해야 합니다.

    문제가 서버와 관련된 경우 팀 구성원은 Streaming 서비스 지원에 문의해야 합니다.

  • 스트림이 정상인지를 어떻게 알 수 있습니까?

    정상 스트림은 활성 상태인 스트림입니다. 메시지가 성공적으로 수신되고 성공적으로 소비됩니다.

    서비스에 대한 쓰기는 내구성이 있습니다. 스트림에서 작업을 수행할 수 있고 반응이 성공적이면 스트림이 정상인 것입니다.

    데이터가 수집된 후에는 구성된 보존 기간 동안 소비자가 액세스할 수 있습니다.

    Get Messages API 호출이 높은 수준의 내부 서버 오류를 반환하는 경우 서비스가 정상 상태가 아닙니다.

    정상 스트림에는 다음과 같은 정상 측정 지표이 있습니다.

    • Put Messages Latency가 짧습니다.
    • Put Messages Total Throughput이 파티션당 1MB/s에 가깝습니다.
    • Put Messages Throttled Records가 0에 가깝습니다.
    • Put Messages Failure가 0에 가깝습니다.
    • Get Messages Latency가 짧습니다.
    • Get Messages Total Throughput이 파티션당 2MB/s에 가깝습니다.
    • Get Messages Throttled Requests가 0에 가깝습니다.
    • Get Messages Failure가 0에 가깝습니다.

    오류 유형 및 의미

  • API 오류 목록을 어디에서 찾을 수 있습니까?

    API 오류에 대한 자세한 내용은 설명서에서 확인할 수 있습니다.

  • 부분 장애란 무엇입니까?

    Streaming 서비스는 파티션당 조절로 인한 부분 장애를 지원합니다. 부분 장애의 경우 서비스는 200 상태 코드를 반환하고 응답 페이로드의 오류를 표시합니다.

    전체 요청이 제한되면 429 상태 코드가 표시됩니다.

  • "허용된 파티션 수를 초과했습니다" 오류가 발생하는 이유는 무엇입니까?

    사용 한도를 늘리려면 Oracle Streaming Service에 문의하시기 바랍니다.

    가격 및 청구

  • OCI Streaming 요금은 어떻게 책정됩니까?

    OCI Streaming은 단순한 종량제 요금을 사용합니다. 초기 비용 또는 최소 비용이 없으며 사용하는 리소스에 대해서만 지불합니다.

    • GET/PUT 요청 가격(전송된 데이터의 기가바이트)

    OCI Streaming의 실제 가격은 가격 안내서를 참조하십시오.

    데이터 생산자가 초당 500개의 레코드를 집계하고 각 레코드가 2kB인 시나리오를 생각해 보겠습니다. 고객은 인그레스의 두 배 속도로 데이터를 이그레스/검색하려고 합니다. 또한 고객은 이 데이터를 7일 동안 저장하려고 합니다.

    가격 계산/일 (예시)

    각 레코드 크기 = 4kB(4kB 미만 레코드의 경우 4kB으로 올림)

    • 이 시나리오에서 하루에 생성된 총 데이터 양 = 500 * 4 * 24 * 60 * 60 kB = 172.8GB
    • 검색된 총 데이터 양 = 제작량의 두 배 = 2*172.8GB = 345.6GB
    • PUT 요청 가격/일 = $172.8 * $xx= $A
    • GET 요청 가격/일 = $345.6 * $xx = $B
    • 데이터 스토리지 비용 = $172.8*24*7*$yy = $C
    • 총 청구 금액/일 = $ (A + B + C)

    선택 사항:

    • 데이터 보존 기간 연장은 기본 24시간 보존(시간당 기가바이트 스토리지)을 초과하는 추가 보존 일수에 따라 부과되는 선택적 비용입니다.
  • OCI Streaming은 무료 요금제를 제공합니까?

    OCI Streaming은 무료 요금제를 제공하지 않습니다.