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 정보..

얼마전에 POST-MAN을 활용하면서, 각종 요청을 하면서 알게된 기능이 있는데 사용 후로는 정말 POST-MAN활용 질이 달라져서, 여러분들에게도 공유하려 합니다. 이런 것을 알게 될때마다 정말 Application에 대한 이해도에 따라 정말 천차만별 일 수도 있겠다는 생각이 많이 듭니다. POST - MAN 활용 시 다음과 같이 URL을 보내고 필요에 따라 Body나 Token값 그리고 Prams를 설정해야 합니다. 하지만 테스트를 지속적으로 해야하는 경우에는, 해당 설정들을 전부 하는 것은 너무 귀찮을 뿐 아니라, 시간도 많이 걸립니다. 그럴때는 Save Button을 적극적으로 활용해줍니다. 최초 Save시에는 아래와 같은 화면이 출력되는데 New Collection을 통해서 Collection을..

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

이 시간 부터는 이제 장애처리에 관련한 내용을 알아보려 합니다. 그 전에 완성된 프로젝트를 공유하도록 하겠습니다. 두 폴더 모두 D: 에 위치시키는 것 을 추천 드립니다. Kafka는 따로 설치해야 합니다. 관련 글을 참고해주세요. -Service가 포함된 WorkSpace- -Service와 관련된 Repo- [MSA] Apache Kafka 설치 Kafka는 MSA와 굉장히 밀접한 기술입니다. 대부분의 MSA 형태의 애플리케이션에는 Kafka가 들어갑니다. 저희가 흔히 쓰는 Spirng-Cloud-Nefilx 오픈소스를 개발한 Nefilx에서도 사용 중 입니다. 이번 포스팅 ggparkitbank.tistory.com [MSA] Apache Kafka - Kafka Connect 개념/ MariaDB..

바로 저번 포스팅에서 이어서 만들어진 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..