[GCP] Streaming 처리
I. 도입
기존에 Batch 데이터만 처리하다 이번 기회에 Streaming 으로 처리해보고자 Pub/Sub에 대해 공부하겠습니다. 여력이 된다면 kafka를 함께 다뤄보면서 오픈소스로 확장시켜보겠습니다. 구글 클라우드 플랫폼에서 Streaming 처리하는 방식을 우선 살펴보겠습니다.
II. 아키텍처
위 사진에서 Ingest, Enrich 영역을 주의 깊게 볼 필요가 있습니다. 현재 포스터에서 시작하고자 하는건 Pub/Sub영역 입니다. 보통 제가 알기론 Pub/Sub에서 데이터를 실시간 수집, Batch 데이터를 함께 처리하게 됩니다. 혹은 Pub/Sub에서 수집한 데이터를 Batch 파일과 엮어서 저장한뒤(Google Cloud Storage)에 PTransform 을 하게 됩니다. 여기서 PTransform은 데이터 형식, 데이터 추가 비즈니스 요소에 맞춰 변형하는것을 의미합니다. 이렇게 가공된 데이터를 적재하여 데이터 레이크 혹은 마켓을 형성하여 최종적으로 분석을 하게 됩니다. 기회가 된다면 분석파트도 다루어 보겠습니다.
III. pubsub vs kafka.
실습을 진행하기에 앞서서 둘의 차이를 확인해보고 가겠습니다.
lll-l. pubsub
pub/sub은 클라우드 기반 대용량 메시지 큐입니다. RabbitMQ, kafka를 클라우드에서 사용할 수 있는 것입니다. pub/sub은 클라우드 서비스로 제공되고 있는 만큼 글로벌 스케일 큐, 구글 자체 광케이블망을 이용해서 빠르게 접근해서 사용할 수 있는 장점이 있습니다.
위 사진을 보면 토폴로지가 1:N의 관계로 형성되어 있습니다. 여기서 Topic 과 Subscription이 존재합니다. 워크플로우는 Message Provider가 Topic으로 메시지를 전송하면 Subscription이 메시지를 받아서 (구독 채널이 설정된 상태) Client에게 전송해주게 됩니다. 이때 Client가 메시지를 전송받았다는 Ack를 전달해주지 않는다면 해당 메시지는 다시 Pub/Sub으로 들어가게 됩니다. 이 Ack(Acknowlegement)통해서 메시지를 전달 보장할 수 있습니다. 메시지의 순서는 보장받지 못합니다. 랜덤한 순서로 전달됩니다. 이유는 Pub/Sub이 분산형으로 예측이 어렵기 때문입니다. (확인시 bcho.tistory.com/1120)
lll-ll. kafka
kaflka가 pub/sub모델의 메시지 큐입니다. 분산환경에 특화되어 설계한다는 특징이 있습니다. 이외에도 fail-over, replication 기능들이 있습니다. pub/sub가 모델이 비슷하기 때문에 publisher, topic, subscribe 개념들이 있다. 또, 순서를 보장한다는 특징이 있습니다.. 메세지가 한번만 쓰여야 하는 특징이 있습니다. 이러한 특징들이 있고 kafka는 이후에 좀 더 다뤄보겠습니다.
llll. Pub/Sub메시지 흐름
Publisher는 생성된 Message를 Topic으로 전송합니다. Message는 Subscriber가 확인할 때까지 Message Storage에 남아있습니다. Subscription은 Subscriber가 선택한 곳으로 push/pull한 Message를 전송 합니다.
llll-ll. Pull(가져오기)/Push(내보내기) 구독 방법
Subscriber 기준으로
Pull방식은 데이터를 요청하여 Pub/Sub이 데이터를 전달해주는 방식(확인시 Ack전송)
Push방식은 Pub/Sub으로부터 데이터를 받는 방식(확인시 Ack전송)
이 두 방식은 데이터를 전달받는데서 일맥상통하지만, 6가지 차이점이 있습니다.
Pull | Push | |
엔드포인트 | 자격을 증명한 인터넷상의 모든 기기입니다. | 자격 증명이 어려운 서비스(구독자)에게 사용할 수 없습니다. |
부하분산 | 여러 구독자가 공유하여 Pull요청을 구성할 수 있습니다. | 엔드포인트가 부하분산기기 될 수 있습니다. |
구성 | X | GCP 콘솔에서 내보내기 엔드포인트를 구성해야합니다. |
흐름관리 | 구독자가 전달 속도를 조절할 수 있습니다. | Cloud Pub/Sub 서버가 자동으로 흐름 제어를 구현합니다. |
지침 | 대량 메시지 메시지 처리의 효율성, 처리량을 중요시 여기는 경우 |
Google Cloud 종속 서비스와의 환경 동일한 webhook에 의한 여러 주제를 처리해야 하는 경우 |
*webhook : 서버에서 어떤 작업이 수행 되었을 때 작업이 수행되었다는 것을 HTTP POST로 알리는 개념입니다. 보통 url(콜백)을 이용합니다. 중요한 이벤트가 발생했을 때에 정보를 수신할 수 있습니다.
IV. 실습
[1]Pub/Sub으로 이동
[2]주제만들기 클릭
[3] test-topic으로 주제를 생성하였습니다.
[4]구독을 생성합니다.
[5] 주제로 이동해서 test-topic을 클릭하고 메시지를 작성합니다. Hello-World 메시지를 작성하고 게시하였습니다.
[6] 게시된 메시지를 확인하기 위해 Cloud-Shell을 켜줍니다. `$gcloud pubsub subscription pull [구독이름]` 을 적어줍니다.
*[참고] gcloud 명령어를 사용하기 위해서는 IAM으로 이동합니다. 그리고 서비스 계정>서비스 계정 만들기를 클릭합니다. credentials(JSON Format)을 다운받아 GOOGLE_APPLICATION_CREDENTIALS를 지정합니다. 이렇게 안해줘도 서비스 계정을 생성할 때 이메일 주소를 project-number-compute@developer.gserviceaccount.com를 주게 되면 Compute Engine 및 Compute Engine을 사용하는 모든 Google Cloud 서비스에 접근할 수 있습니다. 보안에 대한것은 JSON key를 만드는것이 더 유리합니다.