Search

'차이점'에 해당되는 글 3건

  1. 2021.09.06 @Bean vs @Component
  2. 2021.03.13 Node.js vs Spring Boot (5)
  3. 2018.06.15 tasklet과 workqueue의 차이점 (1)

@Bean vs @Component

개발/spring 2021. 9. 6. 20:00 Posted by 아는 개발자

Spring IoC 컨테이너 내에서 관리하는 객체들을 Bean 이라고 하고 Bean으로 사용 될 수 있는 객체는 XML이나 코드상에서 지정이 가능하다. 어노테이션을 사용하는 경우 @Bean, @Conponent 같은 어노테이션을 이용해 Spring IoC 컨테이너에 클래스를 객체로 등록할 수 있다. 

 

@Bean 

 

@Bean 어노테이션은 method 레벨 어노테이션으로 개발자가 수정할 수 없는 3rd 라이브러리 객체를 IoC Container에 등록하고 싶을 때 사용한다. 예를 들면 아래 코드처럼 애플리캐이션 전체에서 공통적으로 사용하고 싶은 Kafka 클래스를 만드려는 경우 아래와 같은 코드로 Bean을 등록 할 수 있다. @Bean을 사용할 때는 @Configuration 어노테이션이 추가된 클래스 내부에서 생성 할 수 있다. 

 

@Configuration
public class KafkaConfig {
    ...
    @Bean
    public KafkaTemplate<String, String> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }

 

@Component 

 

@Component는 개발자가 직접 작성한 클래스를 Bean으로 등록할 수 있는 방법이다. 아래 코드처럼 공통적으로 사용하고 싶은 클래스가 있다면 클래스 이름 위에 @Component 어노테이션을 붙여준다. 

 

@Component
class Utils {
   fun print() { }
}

 

차이점

 

@Bean과 @Component를 헷갈릴 수 있는데 Third party 라이브러리를 Bean으로 등록하는 경우에는 @Bean을 사용하고 그렇지 않은 경우에는 @Component로 사용한다고 생각하면 쉽다. 사실 이럴수 밖에 없는 것이 @Component는 클래스 이름 위에서 선언이 가능한데 Third party 라이브러리는 클래스 수정이 불가능하므로 method level 어노테이션인 @Bean을 사용할 수밖에 없다.

728x90

'개발 > spring' 카테고리의 다른 글

IoC container and Bean  (0) 2021.09.06
@Bean vs @Component  (0) 2021.09.06
Node.js vs Spring Boot  (5) 2021.03.13
Spring 테이블 칼럼이 아닌 필드 데이터 받아오기  (0) 2021.03.05

Node.js vs Spring Boot

개발/spring 2021. 3. 13. 22:32 Posted by 아는 개발자

 

현재 서버 애플리케이션 플랫폼의 큰 두 축은 Spring Boot 와 Node.js 인것 같다. 각각의 플랫폼마다 고유한 장점이 있을 텐데 정작 나는 '일하고 있는 곳에서 사용중이다', '요새 이게 트렌드라고 한다'는 이유로 본질을 망각한채 공부만 해왔던 것 같다. 그래서 이번 포스트에서는 spring boot와 nodejs 각각의 장점과 단점을 늦었지만 다뤄 보고자 한다.

 

Node.js

 

Node.js하면 자바스크립트로 짤 수 있는 서버 애플리케이션을 가장 먼저 떠오르는데 사실 Node js는 Non-blocking I/O를 처리하는데 최적화된 플랫폼이다. Non-blocking I/O는 다른 작업이 처리되는 걸 기다리는 도중에 다른 작업을 하는 것을 말하며 이러한 형태는 짧은 시간에 여러 작업을 처리할 수 있어 효율적이다. 다른 언어에서도 이런 형태로 구현은 가능하지만 코드가 너무 지저분해지고 구현이 어려운 단점이 있었는데 Node js에서는 비동기식 함수를 통해 코드 상에서 이 작업을 구현하기 간편하게 만들어줬다. 실제로 최근에 만든 사이드프로젝트에서 Non-blocking I/O를 구현하는게 정말 간편했다. 그리고 내부적으로는 하나의 Thread를 이용해서 구현했기 때문에 메모리를 크게 잡아 먹지도 않아 효율적이다. 똑같은 애플리케이션을 돌려도 다른 프레임워크보다 Node.js가 소모하는 메모리의 크기가 적다.

 

단점은 JavaScript 언어를 사용한다는 점이다. JavaScript가 배우기는 참 쉬워서 적은 시간을 투자하고 금방 숙달을 할 수 있으나 프로젝트 규모가 커지면 커질수록 Type Safe 하지 못하는 점이 한계점으로 작용한다. 언어가 Type Safe 하지 못하면 내가 짠 코드가 별것도 아닌 에러로 런타임에 죽을 수도 있다. 대부분 이 에러는 Java나 C언어 를 사용했다면 빌드 중에 발생하는 컴파일 에러 종류인데 JavaScript는 빌드하는 과정이 없기 때문에 실행 전에 잡아 주질 못한다. 구현하고 서버 실행까지 매우 빠르다고 좋아 할지 모르나 이 사이에 컴파일 오류는 없을 지 꼼꼼히 봐야한다. 그리고 Type Safe하지 못해서 IDE에서 자동 완성이 잘 되지 않는다. 프로젝트가 커지면 커질수록 리팩토링을 하거나 기존 코드를 써먹어서 확장해야 할 때 자동완성 기능이 핵심인데 JavaScript를 쓰면 자동완성이 잘 안돼서 큰 애를 먹게 된다. 프론트엔드 프레임워크 React에서는 TypeScript를 도입해서 어느정도 보완하고 있는데 Node.js에서도 TypeScript를 도입하는 시도가 있다고 들었는데 어느 정도 진행됐는지 모르겠다. 

 

Spring Boot

 

SpringBoot는 Java로 만든 서버 애플리케이션이다. Java는 유구한 역사를 가지고 있고 지금도 많이 사용되는 언어라 스프링부트를 사용하면 Java 언어에서 있는 기능을 그대로 사용할 수 있다. Java를 개발해본 사람들은 쉽게 Spring Boot에 적응 할 수 있다. 그리고 역사가 오래 됐기 때문에 개발하는데 필요한 왠만한 라이브러리는 모두 Spring Boot에 다 있다. 안드로이드 개발자가 사용한 자바 라이브러리들은 모두 Spring에서도 찾을 수 있다고 볼 수 있고 추가로 서버 개발자들이 어려움을 겪는 데이터베이스 관리도 스프링부트에서는 JPA라는 라이브러리를 통해 간소화 해둬서 손쉽게 다룰 수 있다. 그리고 Java이기 때문에 TypeSafe 하다. 리팩토링하거나 확장 할 때 IDE를 이용해서 수정할 점을 빠르게 체크 할 수 있는데 프로젝트 규모가 커지고 안정성이 중요해지는 시점부터는 큰 장점으로 다가온다. 내부적으로는 Multi Threading을 지원하는 구조로 짜여있어서 길고 반복적인 업무를 처리할 때 효율적이다. 많은 양의 컴퓨팅이 필요한 경우 잘 써먹으면 좋다.

 

한번 써보신 분들은 알겠지만 Spring Boot는 러닝 커브가 존재한다. Node.js는 처음 배우는 사람도 하루만에 서버 구동하고 api도 하나 만들 수 있는데 Spring Boot를 공부하면 Service, Controller, Repository 에 대해서 알아야하고 각 컴포넌트는 어떤식으로 채워야하는지 공부가 필요해 해야 할 게 많다. Spring Boot에서는 좋은 구조를 유도하기 위해 이런 형태의 디자인을 권장하는데 초심자한테는 러닝 커브가 좀 있다. 그리고 boilerplate 코드가 많다. 스프링에서 권장하는 구조랑 라이브러리들을 사용하려면 이런 저런 코드를 만들어야 하는데 처음에는 어려우나 숙달되면 귀찮아진다. 그래도 안쓰는 것 보다 낫긴 하지만. 내부적으로는 메모리를 좀 많이 쓴다. Multi thread 환경이기 때문에 여러개의 Thread를 띄우다 보니까 어쩔 수 없이 생긴 문제인 것 같다. 

 

728x90

'개발 > spring' 카테고리의 다른 글

IoC container and Bean  (0) 2021.09.06
@Bean vs @Component  (0) 2021.09.06
Node.js vs Spring Boot  (5) 2021.03.13
Spring 테이블 칼럼이 아닌 필드 데이터 받아오기  (0) 2021.03.05
  1. 지나가는 나그네 2021.03.19 18:50  댓글주소  수정/삭제  댓글쓰기

    Node.js를 프레임워크라고 하지 않습니다. javascript runtime 입니다.
    그래서 spring boot 와 비교하기 위해서는 node 에서 동작하는 다른 프레임워크와 비교해야 합니다.

  2. Werewolf 2021.04.17 11:21  댓글주소  수정/삭제  댓글쓰기

    요즘 많이 쓰이는 대부분의 Node.js 기반 프레임워크는 타입스크립트를 지원하고 있습니다. 이 중에서도 Nest.js 의 경우 프레임워크 자체가 타입스크립트로 개발되었고 스프링과 매우 흡사한 구조를 가지고 있기 때문에 기존의 스프링 개발자 분들이나 혹은 Node.js 개발자 분 중 스프링 프레임워크로 넘어갈 걸 고려하는 개발자 분들에게 매우 좋은 선택인 것 같습니다.

    어떻게 보자면 스프링 프레임워크가 혹독한 다이어트를 거쳐 체중을 감량하고 이벤트 루프 기반 비동기 I/O를 기본으로 지원하도록 변형된 버전을 Nest.js라고 보면 될 것 같습니다. 당근마켓 등 스타트업 몇 곳에서 Nest.js를 활용하고 있고 근래의 Node.js 기반 프레임워크 중에서는 나름 대세(?)라고 해도 과언이 아닐 것 같네요.

tasklet과 workqueue의 차이점

기술/컴퓨터사이언스 2018. 6. 15. 20:04 Posted by 아는 개발자


 커널 내의 코드를 짜다보면은 특정 작업을 다른 CPU에서 처리해야 하기도하고 어떤 작업은 몇미리 후에 처리 할 필요가 있는데 이런 경우 리눅스 커널에서는 tasklet과 workqueue라는 API를 사용해서 간단히 해결 할 수 있다. booklet, piglet 단어처럼 기존보다 작은 단위를 표현 할 때 let을 쓴다는 점으로 추측해볼 때 tasklet은 작은 일을 처리할 때 사용하는것 같고 같은 논리로 workqueue는 접미사로 queue가 있다는 점에서 미루어보아 작업(work)을 queue에 넣어서 처리하는 API인 것 같다. 


tasklet과 workqueue 모두 특정 작업을 미룰 수 있다는 점에선 동일하나 동작하는 매커니즘은 다르다. 먼저 tasklet은 softirq를 이용해서 동작한다. 세부 과정은 이렇다. tasklet이 스케줄 되면 스케줄러는 이 tasklet을 처리할 수 있는 CPU에게 softirq를 날리고 softirq를 받은 CPU는 하던 일을 멈추고 tasklet에서 설정된 작업을 수행한다. interrupt를 받은 상태로 동작하기 때문에 더 우선순위가 높은 interrupt가(ex. HW interrupt) 오지 않는 이상 tasklet의 작업을 모두 수행하기 전까지 다른 프로세스가 끼어들 수 없다. 만약 tasklet에서 처리하는 작업이 길고 남발하면 다른 작업들은 그만큼 뒤로 밀리게 돼 시스템 전반의 성능 저하가 올 수도 있다. 따라서 tasklet을 사용할 때는 가능한 짧게 수행 할 수 있는 작업을 써야한다. 이름을 참 잘지은 것 같다.


workqueue는 일반 프로세스가 스케줄링 되는 것과 비슷한 원리로 동작한다. workqueue를 관리하는 handler는 일반 프로세스처럼 CPU의 스케줄링을 받기 때문에 workqueue는 tasklet과 달리 작업이 끝나지 않았더라도 sleep에 들기도 한다. 작업을 모두 끝내기 전까지 CPU를 독점하는 tasklet에 비해서 처리하는데 시간이 오래 걸리지만(higher latency) 시스템에 무리를 줄 수 있는 요소가 없어 시간을 두고 처리해야하는 작업을 사용할 때 유용하다. 자유도가 더 높은 덕분인지 API의 기능도 tasklet에 비해서 많다.


 

tasklet 

workqueue 

 동작방식

 Interrupt

 Schedule 

 장점

 처리가 빠르다 

 시스템에 무리가 없다 

 단점

 시스템에 무리를 줄 수 있다 

 처리가 느리다 



보다시피 tasklet과 workqueue는 수행하는 일 자체는 동일할 지 모르나 사용하는 상황은 다르다. 짧고 빠르게 수행해야 하는 작업(low latency)일 경우에는 tasklet을 사용해야 하는 반면 긴 시간을 두고 처리해야하는(high latency) 작업인 경우에는 workqueue를 사용하는 것이 좋다. 본인 작업의 성격에 따라서 tasklet과 workqueue를 잘 구분해서 사용하도록 하자.


다음 포스트에서는 tasklet과 workqueue의 사용법에 대해서 다루도록 하겠다.


* tasklet은 버전 2.3에, workqueue는 버전 2.5에 mainline에 포함됐다. 둘다 역사가 오래된 API이다.


* 참고사이트


https://www.ibm.com/developerworks/library/l-tasklets/index.html IBM 블로그에서 정리를 아주 잘해뒀다. 돈내고 읽어야 할 것 같은 글인데.

https://stackoverflow.com/questions/18321858/what-is-the-difference-between-tasklet-and-workqueue

728x90
  1. 1234 2020.04.15 21:55  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 커널을 이제막 공부하고 있는 학생입니다. 블로그에서 게시한글들이 정말 많은 도움이됩니다. 감사합니다. 혹시 근데, 이번 글보면서 궁금한저미 tasklet의 동작방식이 인터럽트라고 하셨는데, 워크큐랑 비슷하게 스케쥴도 사용하지 않나요?? 그 처음엔 인터럽트처럼 tasklet이 수행되다가, 근데 거기서 수행소요시간이 오래걸리면 포기하고, ksoftirqd라는 커널태스크 (우선순위-나이스 밸류19)가 스케쥴링돼서 나중에 tasklet 을 다시 실행하는걸로 알고있는데.. 혹시 그럼 tasklet은 반반이라고보면될까요? 인터럽트 반 스케쥴반..? 워크큐는 스케쥴