안녕하세요. 엔지엠소프트웨어입니다. 장비(Equipment)의 센서(제조에서 Parameter라고 부릅니다^^) 데이타를 실시간으로 수집하기 위해 [ 인플럭스디비(InfluxDB) ]를 사용합니다. 아직 테스트용 장비(Equipment) 또는 설비(Facility)가 없다보니 실시간으로 데이타를 넣어주는 유틸리티를 하나 만들어야 했습니다. 물론, 엔지엠 매크로를 이용해서 주기적으로 데이타를 만들어서 밀어넣어줘도 됩니다. 하지만, 개발자다보니... 랜덤하게 여러 설비의 시뮬레이션 데이타를 넣어주는건 코딩이 훨씬 편합니다-_-;

 

Backend는 Java Spring boot로 되어 있고 실행중입니다. Frontend는 React로 되어 있지만, 자바 스프링의 와르(war)에 같이 배포되어 있습니다. 그래서, war가 웹서버(Linux Tomcat)에 실행중이기 때문에 스프링의 스케줄러를 이용해서 데이타를 넣어주도록 하겠습니다. 스프링 프로젝트를 열면, 매인 진입점에 아래와 같이 스케줄러 사용 어노테이션을 달아줍니다.

• @EnableScheduling

/**
 * NGMsoftware RPA
 */
@EnableScheduling
@SpringBootApplication
public class OptimaApplication {

	/**
	 * NGM Editor Enterprise V6
	 * 
	 * @author 소심비형
	 * @param args (자동 실행, 복구, 관리자 권한 실행 옵션 처리)
	 * @version 6.4.7
	 * no @return
	 */
	 public static void main(String[] args) {
		SpringApplication.run(OptimaApplication.class, args);
	}

 

실제로 스케줄러로 실행될 메소드에 아래 어노테이션을 달아주면 끝입니다. 내부 로직은 개발하면 되고요~ 참고로, 위에서 언급했듯이 인플럭스 디비에 시뮬레이션에 사용할 가상 파라메터 데이타를 랜덤하게 밀어 넣어야 해서 InfluxDBTemplate를 사용해서 Insert하고 있습니다. 스프링이다보니 new를 사용하면 안됩니다. @Autowired 어노테이션을 사용해서 자바 스프링이 실행될 때 인젝션이 발생할 수 있도록 해줘야 합니다.

• @Scheduled(fixedDelay = 1000)

	@Autowired
	private InfluxDBTemplate<Point> influxDBTemplate;

	@Scheduled(fixedDelay = 1000)
	public void insertInflux() {

 

스케쥴링의 옵션에 대해 알아볼까요? 위에서 fixedDelay 옵션을 사용했습니다. 이 옵션을 사용하면 해당 메소드가 바로 실행되고, 메소드의 태스크(Task)가 완료된 후 설정한 값(1000은 1초)만큼 쉬고, 다시 메소드가 실행됩니다. 스케쥴링을 1초마다 하라고 되어 있지만, 실제로는 1초마다 실행되지는 않습니다. 메소드의 처리가 다 끝나고 1초후에 실행된다는 의미입니다. 만약, 메소드의 처리 시간이 10초라면 1초 간격으로 10개의 스레드가 생성되는게 아닙니다.

 

fixedRate 옵션도 fixedDelay와 동일하게 Millisecond로 값을 하나 받습니다. 다만, fixedDelay는 함수가 종료된 시점부터 계산되는 반면에 이 옵션은 시작 시점부터 시간을 계산합니다. 미묘하지만 차이가 있습니다. 그리고, 가장 큰 차이점은 fixedRate는 메소드의 작업 시간과 관계없이 주어진 간격대로만 실행한다는 점입니다. 그래서, 작업시간이 오래 걸리는 메소드에 짧은 fixedRate를 설정한다면~ 메모리가 증가하거나 어플리케이션이 죽을수도 있습니다.

 

이외에도 크론(Cron)이 있습니다. 크론은 이미 엔지엠 매크로 에디터에도 있는 기능이므로 대부분은 알고 있을겁니다. 개발자면 당연히 알고 있을테고요. 아무튼, 별도의 크론잡을 리눅스에 등록하는건 아니구요. 스프링의 스케줄러에서 크론을 등록해서 주기적으로 실행됩니다. 크론도 fixedRate와 동일하게 중복 처리되므로 잘 계산해서 작성하셔야 합니다. 이런 멀티 스레딩 환경에서는 의도하지 않은 동작들이 발생할 수 있습니다. 예를 들어 5분동안 A데이타베이스에서 읽어온 값을 B데이타베이스에 저장하고, A데이타베이스에서 삭제한다고 가정 해봅시다. 이 때 5분을 초과한다면 A데이타베이스에서 지우기전에 다른 스케줄러가 데이타를 읽어올겁니다. 그러면, B데이타베이스에 중복된 데이타가 쌓이게 되고 이건 우리가 원한 스마트한 동작이 아닙니다.

 

일반적으로 퍼포먼스냐 안정적으로 동기화해서 돌릴것이냐가 문제입니다. 시스템을 분석하고, 설계하는 시점부터 데이타의 무결성, 안정성, 가시성등등을... 잘 고려해서 어플리케이션을 만들어야 합니다. 이미 프로젝트가 시작되었다면~ 개발자들은 피곤해질겁니다. 분명히 중간에 내용이 바뀔것이고, 여러가지 테스트로인해 문제가 발견되면 전체적인 구조를 뜯어고쳐야 할수도 있기 때문입니다. 관리자로 있으면서 이런 고민들이 많아집니다. 머리도 아프고요. 다양한 경험들이 도움이 되기도 하지만, 어쩔때는 쉽게 풀수 있는 상황들도 어렵게 만들기도 합니다. 그래서~ 문제 해결을 위해 대화를 자주 해야 합니다^^

 

개발자에게 후원하기

 

추천, 구독, 홍보 꼭~ 부탁드립니다.

여러분의 후원이 빠른 귀농을 가능하게 해줍니다~ 답답한 도시를 벗어나 귀농하고 싶은 개발자~

감사합니다~

추천0 비추천0