IT 지식 저장소

그럼 이제 Zipkin을 활용해서, 저희가 만든 Application의 분산 추적을 하려 합니다. 분산 추적을 통해서 서비스가 어디로 이동하고 있는지, 어떤 이슈가 발생했는지 쉽게 파악 할 수 있습니다. 이런 걸 Console창을 바꿔가며 보려면, 너무 힘들잖아요 😭 #개요 이번 시간에는, Zipkin을 설치했으니 실제로 사용해보려 합니다. Spring Cloud Sleuth를 이용해, Spring Project에서 발생하는 요청을 Zipkin에 연동 될 수 있도록 하고, 실제로 Zipkin을 사용해보려 합니다. 지금까지 잘 따라오셨다면 금방 끝날 수 있는 내용이니 천천히 따라와주세요! #UserService 먼저 Dependency를 추가해줍니다. Sleuth 와 Zipkin의 Dependency 정보..

이번에는 데이터 수집 그리고 추적을 위해서 Zipkin이라는 오픈소스를 사용하려 합니다. 쉽게 말해 분산추적을 위한 라이브러리 입니다. #Zipkin 개요 Twitter에서 사용하는 분산 환경의 Timing 데이터 수집, 추적 시스템 (오픈소스) 분산환경에서의 시스템 병목 현상 파악 Collector, Query Service, DataBasem WebUi로 구성 Span -하나의 요청에 사용되는 작업의 단위 -64 bit uniques ID Trace -트리 구조로 이뤄진 Span Set -하나의 요총에 대한 같은 Trace ID 발급 해당 특징에서 알 수 있듯 Zipkin은 분산환경에서 시스템 병목 현상을 파악합니다. 여기서 분산환경이란, 저희가 구축한 MSA형태의 어플리케이션 처럼 서비스가 분리되어..

바로 저번 포스팅에서 이어서 만들어진 Producer를 TEST하려 합니다. 먼저 모든 Service를 실행한 뒤 Zookeeper Server Kafka Server Kafka Connect를 실행해줍니다. 단, Order Service는 Test를 하기 위해 2개의 Service를 실행합니다. cmd를 통해서 실행 할 수도 있지만, 저는 Duplication을 통해서 Application을 복사하려합니다. 아래의 화면에서 빨간 박스안에 있는 버튼을 누르면 자동으로 Duplication이 됩니다. 복사후 Ok를 눌러줍니다. Order-Service가 정상적으로 2개가 실행 중인지 확인해줍니다. #주문등록 주문 등록을 진행해줍니다. 아래의 커맨드로 토픽에 메시지가 왔는지 확인해줍니다. Kafka 설치폴더..

#개요 이제 고도화 작업은 거의 끝나 갑니다. 이번 시간에는 Order를 위한 Sink Connection을 만들고, 주문 입력 시 Topic에 해당 정보를 전달하고, 다시 해당 정보를 DB에 저장하는 과정을 구현하려합니다. 예전에 언급 드린적있듯이, Kafka를 통해서 어느 포트에서 오든 메시지를 저장하고 하나의 단일 DB에 저장하기 위한 과정을 구현하려 하는 거죠! + 이번 포스팅은 많이 길어질 것 같습니다. 아무래도 마무리 단계이기도 하고 중요한 부분도 있어서 많은 부분을 적어야 할 것 같네요. 지루하시다면 마지막에 최종코드를 첨부할테니 확인해주세요! #OrderController.java(Order-Service) #완성 코드 package com.example.orderservice.contro..

개요 저번 시간에 말씀드린 것 처럼 이번 시간에는 Kafka Connect를 활용해, 단일 DB에 데이터를 적재하는 과정을 거치려 합니다. MariaBD와 Order Kafka Topic, Order Kafka Producer를 조금 수정해야 합니다! #MariaDB 가장 먼저 일단 MariaDB에 접속해줍니다. Windows환경 기준으로 저는 다음과 같이 접속했습니다. // MariaDB 설치 폴더 Bin으로 이동 cd D:\mariadb-10.6.7-winx64\bin // mysql 서버 실행 및 유저 정보 입력 mysql -uroot -p // EnterPassword 출력 시 test1357 입력 or 본인이 설정한 root password로 접속 Enter password: ******** 정..

사이트 규모가 증가함에 따라서 과부하를 처리 하는 방식 중 하나를 로드 밸런싱이라 합니다. 그리고 로드 밸런싱은 N개의 다른포트에 똑같은 서비스 ( ex : 주문 서비스 ) 를 기동시켜 교차하며 서비스를 제공하도록 합니다. 이 방법은 굉장히 효율적으로 과부하에 대비 할 수 있지만 한가지 문제점이 존재합니다. 바로 데이터 동기화의 문제 인데, 만약 H2 DB처럼 각 Port별로 어플리케이션 실행 시 생성되는 DB인 경우에는 어떨까요? #Load Balancer의 동작원리 많이 생략되어 있지만, LoadBalancer에서 어떤 Port로 접속 할지 접속 정보를 가지고 있습니다. 그리고 처음으로 요청이 들어오면, 보시는 것처럼 9091 Port로 요청값을 보냅니다. 그럼 9091Port 에서 H2-DB에는 유..

이번 포스팅은 Test가 주 내용 입니다. 바로 전에 작성한 포스팅을 참고해주세요. 먼저 테스트를 위해서 실행해야할 서비스 목록입니다. Zookeeper - Server Kafka - Server Eureka - Sever( WorkSpace에서 Ecommerce라는 프로젝트) ApiGateway - Service Config - Service Order - Service Catalog - Service #Eureka Server 접속 localhost:8761 로 접속해 Eureka 대쉬보드 확인해볼게요. test에 앞서서 h2-console을 확인하려합니다. 접속하고자 하는 Service에 링크를 클릭해줍니다! 초록색 글씨로 되어있는 부분입니다. #[OrderService]/h2-console 로 접..

이제 끝이 보이고 있습니다. 물론 Back-end의 구현만 살펴보고 있지만, MSA라는 처음 보는 아키텍쳐와 함께 하면서, 여러가지를 배웠던 거 같네요. 이제 데이터 동기화를 위한 Apache Kafka의 활용법을 적용하고, 장애처리, 그리고 마지막으로 모니터링 기능까지 추가하면 끝입니다. 산더미네요... 그리고 클라이맥스로 Docker를 활용해서 모든 서비스를 하나하나 Container화를 구축할 예정이니까요. 이번 시간 부터는 다시 E-Commerce Application 을 고도화 시킬 예정입니다. 실습에 앞서서 만약 구축된 E-Commer Application이 없다면 아래의 파일들을 받아주세요 웬만하면, D: 바로 밑에 두 폴더 모두 위치시켜주시길 바랍니다. 해당 위치가 아닐 경우 Config-..

저번 시간에는 Kafka Source Connect에 대해서 알아봤습니다. Sink 는 Source와 다르게 메시지를 소비하는 역할을 하는데, 사실 저희가 Kafka를 시작하면서 배웠던 Producer와 Consumer의 개념 이랑 비슷합니다. 이제 가지고 있는 메시지를 소비하는 역할를 하는게 Sink라고 생각하시면 될 것 같습니다. #개요 실제로 Kafka Sink Connect를 구축하고, Kafka에서 DB로 저장하는 로직을 구현하려 합니다. #Sink Connect 생성 Sink Connect를 생성하는 방식은 저번에 진행했던 Source Connect의 생성방법과 크게 다르지 않습니다. 먼저 Connect 서버를 실행합니다. (기본적으로 Zookeeper와 Kafka가 실행된 상태에서 실행해주세..