IT 지식 저장소

이제 최종적으로 Application을 배포하려 합니다. 해당 과정만 끝낸다면, 정말로 끝입니다. 지금까지 제작된 Project를 기반으로 모든 서비스를 Container화를 통해서 배포를 하려합니다. 그 전에 짧게 어떤식으로 배포를 진행 할 예정인지 말씀드리려 합니다. 먼저 배포 진행 시 사전에 준비해둬야 하는 것을 말씀드리려 합니다. 일단 배포하려는 프로젝트의 JAR File이 필요합니다. 그리고 Docker를 통해 Build하는 과정이 선행되어야 성공적으로 배포를 성공할 수 있습니다. 그런데 여기서 문제가 하나 나타납니다. Docker Container는 각각의 독립된 컨테이너입니다. Network의 정리를 해주지 않는다면, Network의 연동이나 서버문제나 나타날 수 있습니다. 그렇기에 아래와 ..

이제 정말 마무리 단계입니다. 더 이상의 프로그램 고도화도 없고, 추후에 해당 어플리케이션을 참조해, 새로운 어플리케이션을 만들지 않는한, 코드는 Maintence( 보존 ) 상태로 둘려합니다. 그럼 왜 마무리 단계라는 말을 했냐면, 일단 기본적으로 Application 배포 과정은 어떻게 보면 제작 단계보다 더 복잡합니다. 여러가지를 신경써야 하죠. 일반적으로 가상화 라는 개념에는 두가지 방식이 있는데 OS Virtualization 과 Container Virtualization이 있습니다. OS Virtualization 같은 경우 제가 아주 예전에 포스팅한 기억이 있는데, VMWare를 활용해서 Cent OS를 설치한 일이 있습니다. 이게 바로 OS 가상화에요. 해당 방식은 자유도는 높지만, 컴퓨..

Micrometer를 짧게 설명을 드리면, Application에 모니터링을 하기위한 도구로, 필요한 각종 자료를 수집하는 용도입니다. 네트워크 트래픽이나,사용자의 요청의 횟수,메서드 진입 횟수 등등 말그대로 MS를 모니터링 하기 위한 도구 입니다. #User-Service 늘 그렇듯 Dependency부터 추가하려 합니다. 아래와 같은 Dependency를 추가해주세요. io.micrometer micrometer-registry-prometheus 다음으로는 Application.yml 파일을 수정하려 합니다. management 부분에 가장 하단에 prometheus를 추가해줍니다. management: endpoints: web: exposure: include: refresh,health,bea..

그럼 이제 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에는 유..