728x90
반응형

Dependency Injection (의존성 주입)이란?

Dependency Injection이란?
Dependency Injection이란 객체 또는 구성 요소간의 종속관계를 소스코드로 설정하지 않고 외부의 설정파일을 통해서 주입하도록 하는 디자인 패턴으로 주로 알려져 있는데요 쉽게 이야기하면 한 객체 안에 다른 객체가 사용되면 두 객체 간에 종속관계가 생기는 것이고 다른 객체를 포함한 객체를 생성하려면 포함된 객체가 미리 생성이 되어 있거나 그렇지 않을 경우 자동으로 생성을 해줘야 하는데 이 부분을 따로 코딩하지 않고 외부의 설정 파일을 통해서 설정해둬서 Dependency Injection 기능을 제공하는 프레임워크 (예를 들어 Spring 같은)에서 자동으로 생성하게 하는 기술입니다.

왜 사용하나요?
Dependency Injection을 사용하는 가장 큰 이유는 아래와 같습니다.
1. Loosely coupled: Dependency Injection는 보통 서비스 또는 인터페이스 개념과 같이 사용이 되는데요 한 객체를 다른 객체에 포함할 때 클래스 형태로 포함시키는게 아니라 인터페이스 형식으로 포함을 시키기 때문에 외부 설정파일이나 스프링 프레임워크 같은 경우에는 어노테이션 값의 변화를 통해 다양한 서비스를 사용할 수 있습니다. 위의 설명한 내용에 대해서 아래에 예를 참조하세요.

예1 - 클래스 형태로 포함시키는 경우 (Java)
public class Foo {
    .....
}

public class Poo {
   private Foo foo  = new Foo();
}

예2 - 인터페이스 형태로 포함시키는 경우 (Java)
public Interface FooService {
   .....
}

public class FooServiceImpl implements FooService {
   .....
}

public class Poo {
  private FooService fooServ; 
}

2. Testability: Dependency Injection을 사용하게 되면 위에 설명한 것처럼 객체 간의 관계가 느슨해지기 때문에 유닛 테스트와 같은 테스트를 작성하기가 수월해집니다. 위의 두번 째 예처럼 다른 객체에 포함된 인터페이스 형태의 서비스 같은 경우에 Mock를 하여 유닛테스트를 작성하게 되면 그 서비스와 상관없이 작동가능한 테스트를 만들 수 있습니다.

마지막으로...
Dependency Injection은 단순히 그 의미나 사용 방법을 이해하려고 하기 보다는 왜 사용이 되는지를 파악해야 이해하기가 쉽습니다. 또한 같이 사용되고 있는 서비스의 개념과 왜 서비스의 형태로 사용되어야 하는지 등을 이해해야 좀더 이해하기가 쉬운 기술입니다. 


728x90
반응형

'Web Programming > spring' 카테고리의 다른 글

BeanCreationException  (0) 2018.09.04
스프링 프레임워크 (Spring Framework)란?  (0) 2018.08.29
Spring MVC 프로세스  (0) 2018.08.29
Spring AOP with Annotation  (0) 2018.08.29
Spring AOP with XML  (0) 2018.08.29
728x90
반응형

WebSocket이란?

WebSocket이란?

WebSocket이란 Transport protocol의 일종으로 쉽게 이야기하면 웹버전의 TCP 또는 Socket (소켓)이라고 이해하시면 됩니다.  WebSocket은 서버와 클라이언트 간에 socket connection을 유지해서 언제든 양방향 통신 또는 데이터 전송이 가능하도록 하는 기술이며 2008년에 HTML5에 포함이 되어서 여러 번의 토론을 통해 프로토콜이 제정되었고 2009년 구글 크롬을 시작으로 여러 웹브라우저에서 이 기술을 적용하여서 현재 Real-time web application 구현을 위해 널리 사용되어지고 있습니다. 참고로 Real-time web application이란 서버 쪽 또는 클라이언트 쪽 데이터가 실시간으로 업데이트 되는 웹 어플리케이션을 의미합니다. 

왜 사용하는가요?

WebSocket을 사용하는 이유 또는 사용시 얻을 수 있는 장점에 대해서 이해를 하려면 WebSocket 이전에 사용되었던 기술과 어떤 차별성이 있는지를  이해하는게 중요합니다. 우선 웹어플리케이션에서 기존의 서버와 클라이언트 간의 통신은 대부분 HTTP를 통해 이루어 졌으며 HTTP는 Request/Response 기반의
Stateless protocol입니다. 무슨 말이냐 하면 서버와 클라이언트 간의 Socket connection 같은 영구적인 연결이 되어 있지 않고 클라이언트 쪽에서 (예를 들어 웹브라우저 쪽에서)  필요할 때 Request를 할 때만 서버가 Response를 하는 방식으로 통신이 진행되는 프로토콜이란 뜻입니다. (짧게 이야기하면 클라이언트 쪽에서만 대화를 시작할 수 있는 한 방향 통신입니다.) 그래서 어떤 문제가 생기냐면 서버 쪽 데이터가 업데이트 되더라도  클라이언트 쪽 (예를 들어 웹페이지)에는 화면을 Refresh 하지 않는 한 바뀐 데이터가 업데이트가 되지 않는 문제가 발생합니다. 그렇지만 이런 문제는 일반적은 웹 어플리케이션에서는 기존에 있던 임시 방편인 Long polling 이라던가 Ajax를 사용해도 어느 정도 해결이 가능하지만 데이터의 빠른 업데이트가 아주 중요한 요소 중에 하나인 어플리케이션 (예를 들어 주식 관련 사이트라던가 비디오 채팅 어플리케이션)에서는 실시간 업데이트가 아주 중요하기 때문에 (그리고 기존의 Long Polling 같은 기술은 서버에 많은 부담을 주는 부작용이 있기 때문에) WebSocket이 아주 유용하고 중요한 기술로 사용되고 있습니다.
또한 WebSocket은 Stateful protocol이기 때문에 클라이언트와 한 번 연결이 되면 계속 같은 라인을 사용해서 통신을 하기 때문에 HTTP 사용 시 필요없이 발생되는 HTTP와 TCP 연결 트래픽을 피할 수 있습니다.  마지막으로 WebSocket은 HTTP와 같은 포트 (80)을 사용하기 때문에 (Secure한 채널 같은 경우에는 HTTPS와 같은 443을 이용) 기업용 어플리케이션에 적용할 때 방화벽을 재설정하지 않아도 되는 장점도 있습니다. (대부분의 기업 방화벽은 외부에서의 접속은 HTTP나 HTTPS만을 기본으로 
허용하고 있으며 만약 이외의 포트를 허용해야 할 경우에는 방화벽의 설정을 수정해야 하는데 큰 회사일 수록 방화벽 설정 수정 절차가 복잡하기 때문에 HTTP와 같은 포트를 사용한다는 점이 꽤 큰 장점이 될 수도 있습니다.)

작동 원리 및 그 외의 정보

우선 서버와 클라이언트 간의 WebSocket 연결은 HTTP 프로토콜을 통해 이루어집니다. 만약 연결이 정상적으로 이루어진다면 서버와 클라이언트 간에 WebSocket 연결 (TCP/IP 기반으로 하는)이 이루어지고 일정 시간이 지나면 HTTP 연결은 자동으로 끊어집니다. 
기본적으로 WebSocket API는 아주 간단한 기능들만을 제공하기 때문에 대부분의 경우 SockJS나 Socket.IO 같은 오픈 소스 라이브러리를 많이 사용하고 있으며 메세지 포멧 또한 STOMP 같은 프로토콜을 같이 이용합니다. 마지막으로 스프링 프레임워크도 WebSocket을 간단한 메세지 브로커랑 SockJS 그리고 STOMP와 같이 지원하고 있습니다. 

WebSocket 사용의 어려운 점

WebSocket은 사용시 위에 서술한 것과 같은 장점들을 주지만 그에 못지 않는 비용을 지불해야 합니다. 아래는 WebSocket 사용 시 발생할 수 있는 어려운 점 또는 문제점들입니다. 
1. 프로그램 구현에 보다 많은 복잡성 초래: WebSocket은 HTTP와 달리 Stateful protocol이기 때문에 서버와 클라이언트 간의 연결을 항상 유지해야 하며 만약 바정상적으로 연결이 끊어졌을 때 적절하게 대응해야 합니다. 이는 기존의 HTTP 사용 시와 비교했을 때 코딩의 복잡성을 가중시키는 요인이 될 수 있습니다. 
2. 서버와 클라이언트 간의 Socket 연결을 유지한다는 것 자체가 비용이 드는 일입니다. 특히나 트래픽양이 많은 서버 같은 경우에는 CPU에 큰 부담이 될 수 있습니다. 
3. 오래된 버전의 웹 브라우저에서는 지원하지 않습니다. (물론 SockJS 라이브러리 같은 경우에는 Fallback option을 제공하고 있습니다.) 참고로 인터넷 익스플로어 같은 경우에는 10 버전부터 지원합니다. 
4. 이건 제 개인적인 경험인데 서버와 클라이언트 간의 연결이 끊어졌을 때 생성되는 에러 메세지가 구체적이지 않아서 (예를 들어 여러가지 다른 이유로 연결이 끊어졌는데 에러 메세지가 같은 경우) 디버깅을 하는데 어려움이 많았습니다. 

아무리 좋은 기술이라 할지라도 모든 경우에 유용할 수는 없는 법이기 때문에 프로그램에 꼭 필요한 기술인지 잘 체크하고 수용 여부를 결정하는 것이 바람직합니다. 

대표적인 사용예

1. 페이스북 같은 SNS 어플리케이션
2. LOL 같은 멀티플레이어 게임들
3. 구글 Doc 같이 여러 명이 동시 접속해서 수정할 수 있는 Tool
4. 클릭 동향 분석 데이터 어플 (특정 시간동안 어느 사이트에 주로 접속했는지 등의 정보를 파악하는 어플)
5. 증권 거래 정보 사이트 및 어플
6. 스포츠 업데이트 정보 사이트 및 어플
7. 화상 채팅 어플
8. 위치 기반 어플
9. 온라인 교육 사이트 및 어플

References

https://www.websocket.org/aboutwebsocket.html
http://www.javaworld.com/article/2071232/java-app-dev/9-killer-uses-for-websockets.html
https://en.wikipedia.org/wiki/WebSocket
https://samsaffron.com/archive/2015/12/29/websockets-caution-required
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API


728x90
반응형

'Web Programming' 카테고리의 다른 글

프레임워크와 라이브러리의 차이  (0) 2018.08.29
캐시와 쿠키의 차이  (0) 2018.08.29
SonarQube란?  (0) 2018.08.29
Jenkins 서버란?  (0) 2018.08.29
Apache Kafka (아파치 카프카)란?  (0) 2018.08.29
728x90
반응형

SonarQube란?


소나큐브는 프로젝트의 품질을 관리할 수 있도록 여러가지 모니터링 툴을 제공하는 오슨소스 플랫폼입니다. 보통 소나큐브는 단독으로 사용되기 보다는 지난 번에 포스트한 Jenkins 같은 CI 서버와 연동이 되어서 사용이 되어지고 있으며 Java를 포함한 20가지가 넘는 프로그래밍 언어 (예: C#, C/C++, Javascript 등)로 제작된 프로젝트의 모니터링을 제공합니다. 

아래는 소나큐브의 장점들입니다. 
  1. 오픈소스 프로젝트이기 때문에 라이센스 비용없이 다운받아서 사용 가능
  2. 프로그램 설치 후 사용 가능한 파워풀하고 심플한 Web Monitoring UI (Dashboard) 제공
  3. 테이블과 차트를 이용하여 시간이 지남에 따라 프로젝트가 얼마나 개선되고 있는지 보여줌
  4. 코딩품질 개선을 위한 정보 (소스의 중복이나 복잡도 그리고 유닛 테스트의 커버리지 및 잠재적인 버그의 정보 등)을 프로젝트 단위부터 파일단위까지 제공
 위의 장점들 외에도 더 많은 기능들을 제공하지만 저의 개인적인 경험들로는 위의 부분들이 가장 크게 느껴졌었습니다. 그럼 소나큐브에 대한 간단한 설명을 마치고 다음 번 포스팅에서는 소나큐브의 설치와 Jenkins 서버와의 연동 방법에 대해서 설명하도록 하겠습니다.

Sources:
  • SonarQube's Main Website: http://www.sonarqube.org/
  • 메멘토님의 글: http://dryang.egloos.com/viewer/4005366


728x90
반응형

'Web Programming' 카테고리의 다른 글

프레임워크와 라이브러리의 차이  (0) 2018.08.29
캐시와 쿠키의 차이  (0) 2018.08.29
WebSocket이란?  (0) 2018.08.29
Jenkins 서버란?  (0) 2018.08.29
Apache Kafka (아파치 카프카)란?  (0) 2018.08.29
728x90
반응형

Jenkins 서버란?
젠킨 서버는 Open Source CI (Continuous Integration) Tool로써 여기서 CI 란 팀의 구성원들이 작업한 내용을 정기적으로 통합하는 것을 의미합니다. 말이 약간 어려운데 쉽게 이야기하면 하나의 프로젝트를 여러 명으로 구성된 한 팀이 작업할 때 프로젝트를 리드하는 매니저가 일을 여러가지로 나눠서 팀멤버들한테 분배하고 팀멤버들은 각각 할당된 부분만 작업을 하게 됩니다. 그리고 팀멤버들은 자신이 담당해서 하고 있는 부분의 소스코드를 정기적으로 SVN과 같은 Version Control System에 Submit 하는데 이 각각의 팀멤버들로부터 Submit된 소스코드들을 정기적으로 통합하는 것을 CI라고 하고 이것을 시행해주는 프로그램을 CI tool이라고 합니다.



왜 사용하나요?
Jenkins 서버를 사용하는 이유는 여러 가지인데 제 개인적인 경험으로 봤을 때 가장 큰 이유는 아래와 같습니다.

  1. 프로젝트의 빌드가 정상적으로 되고 있는지 체크할 때
  2. 자동으로 유닛 테스트와 통합 테스트 (integration test)들의 정기적인 실행. 만약 테스트 결과에 문제가 있을 때 이메일을 통해 리포트
  3. SonarQube 같은 코드의 질을 확인할 수 있는 모니터링 시스템과의 연동으로 코드의 질을 조절 


위의 내용을 짧게 이야기하면 Jenkins 서버는 현재 진행 중인 프로젝트가 정상적으로 빌드가 되고 있는지를 정기적으로 체크해서 결과를 팀원들한테 알려주고 문제가 발생했을 때 조기에 알려줄 수 있게 해줌으로써 여러 팀 멤버들이 큰 문제없이 각자의 맡은 부분만을 작업할 수 있도록 도와줍니다. 또한 프로젝트 빌드시 자동으로 유닛 테스트와 통합 테스트를 실행해줘서 잘 못된 점이 있으면 알려주고 또한 현재 얼마만큼의 소스코드를 유닛 테스트가 커버하고 있는지 및 어떤 부분에 문제가 있을 수 있는지 등의 정보도 SonarQube와 같이 연동시 모니터링 할 수 있도록 도와줍니다. 

728x90
반응형

'Web Programming' 카테고리의 다른 글

프레임워크와 라이브러리의 차이  (0) 2018.08.29
캐시와 쿠키의 차이  (0) 2018.08.29
WebSocket이란?  (0) 2018.08.29
SonarQube란?  (0) 2018.08.29
Apache Kafka (아파치 카프카)란?  (0) 2018.08.29
728x90
반응형

Apache Kafka란?

아파치 카프카는 2011년에 링크드인(LinkedIn)이라는 회사에서 자사의 웹사이트 이벤트 체크를 하기 위한 목적으로 만들어진 사내 프로젝트로 시작했다가 2014년에 아파치를 통해 오픈 소스화된 프로젝트로 현재 빅데이터 관련 프로젝트에 가장 널리 사용되고 있는 distributed messaging system입니다. 현재 링크드인을 비롯해서 야후, 트위터, 넷플릭스, 우버 등 실시간으로 대용량의 데이터를 처리해야 하는 어플리케이션을 운영하고 있는 회사에서 메세징 시스템 뿐만아니라 실시간 모니터링, 이벤트 프로세싱등 다양한 용도로 사용되고 있습니다. 그렇다면 아파치 카프카에 어떤 특별한 점이 있길래 이렇게 짧은 시간 안에 수많은 빅데이터 회사에게 널리 사용되게 되었는지 아래의 글에서 확인해보도록 하겠습니다. 

Why Use It? 왜 사용하나요?

  • High-throughput message capacity: 쉽게 이야기해서 단 시간 내에 엄청난 양의 데이터를 컨슈머 쪽으로 전달 가능합니다. 다른 경쟁 제품에 비해 많은 양의 데이터 전송이 가능한 이유는 크게 두 가지 있는데 우선 첫째, 기존의 메세지 시스템이 메세지 브로커 쪽에서 가지고 있던 모든 복잡한 과정 또는 연산들을 제거했고 둘째, 하나의 토픽에 대해 여러 개의 파티션으로 분할 할 수 있도록 해서 컨슈머 쪽에서 분산 처리할 수 있도록 하였습니다. 좀더 자세히 설명하자면 기존의 메세지 시스템들은 (RabbitMQ 같은) 각각의 토픽에 대해 컨슈머들의 인덱스 (데이터를 어디까지 전송받았는지를 알려주는) 정보를 메세지 브로커 쪽에서 관리하였는데 카프카는 이 부분을 컨슈머 쪽으로 책임을 옮겼으며 또한 메세지를 유지하는 방법도 메모리에 잠시 보관하였다가 컨슈머에 전송된 후 삭제하는 방법이 아니라 일반 파일에 Log 형식으로 (데이터가 날짜순으로 저장되고 Append만 가능한 형식) 관리하여 전송 후에 Delete 연산이 필요없는 방식을 사용하고 있습니다. 또한 토픽의 분할 기능을 제공하여 같은 토픽에 대해 여러 개의 컨슈머가 동시에 메세지를 전송 받는 등의 분산 처리를 지원하여 많은 양의 데이터 전송을 가능하게 하고 있습니다.
  • Scalability와 Fault tolerant: 카프카는 클러스터 모드를 지원하고 있으며 위에 언급했던 토픽 파티셔닝 (하나의 토픽을 여러 개의 파티션으로 나눌 수 있는 기능)과 파티션 복제 (Replication) 기능을 통해 확장성과 Fault tolerant (부분적으로 고장나더라도 중요한 기능들은 정상적으로 작동하는 특성)을 제공하고 있습니다.
  • 메세징 시스템 외에 다양한 용도로 사용 가능: 일반적인 메세징 시스템과 달리 카프카는 다양한 용도로 사용 가능하며 자세한 사용 용도에 대해서는 아래의 글을 참조하세요.


Use Cases (카프카의 사용 용도의 예)

  • Messaging System: 가장 일반적으로 많이 사용되고 있는 용도로 메세지 제공자 (Producer 또는 Source)와 수신자 (Consumer 또는 Sink) 사이에서 메세지를 전달해주는 역할을 합니다. 각각의 컨슈머 (또는 컨슈머 그룹)는 전달받기를 원하는 메세지의 토픽에 구독 신청해야 하며 하나의 토픽에 여러 컨슈머가 구독 신청 할 수 있습니다. (이 경우에 메세지는 구독신청한 모든 컨슈머한테 Broadcast 됩니다.)
  • Website Activity Checking 및 Monitoring: 링크드인에서 처음 만들고 사용했던 목적처럼 웹사이트가 정상적으로 돌아가는지 또는 웹사이트 사용 시 유저들의 패턴이 어떻게 되는지 모니터링 또는 웹사이트 이벤트 체킹의 목적으로도 사용 가능하며 (중간에서 메세지를 전달하는 중간자의 역할을 할 수도 있지만 메세지 자체가 디스크에 일정 기간 동안 로깅이 되어 있기 때문에 직접 분석도 가능합니다.)
  • Log Aggregation: 하나의 웹사이트가 여러 대의 서버로 운영되고 있다면 (대부분의 엔터프라이즈 웹사이트들이 그렇듯이) 각각의 서버에 있는 로그를 통합해주는 시스템 구축에도 사용 가능합니다.
  • Stream Processing & Batch Processing: 요즘 빅데이터 쪽에서 가장 핫한 Spark나 Storm같은 Stream Processing (스트림 처리)을 지원하는 플랫폼이나 Hadoop과 같이 Batch Processing (일괄 처리)을 지원하는 플랫폼과 연결햐여 메세지의 변환도 가능합니다.
  • Etc: 그 외에 연결된 DB나 서치 엔진의 일시적 서비스 장애 때문에 다운이 되었을 때 메세지들을 잠시 저장해줄 수 있는 임시 버퍼의 역할도 가능하며 Operational metrics (각각의 토픽에 대해 들어오는 메세지의 수를 정기적으로 체크하여 그 수가 너무 낮거나 높을 때 문제가 있는 확인차 운영팀에 메일등을 통해 알려주는 용도)나 Event sourcing (특정 이벤트들을 시간 순으로 기록하여 나중에 필요할 때 사용하는 용도) 등의 용도로도 사용되고 있습니다.


References

  • http://kafka.apache.org/intro.html
  • http://www.javaworld.com/article/3060078/big-data/big-data-messaging-with-kafka-part-1.html
  • https://www.quora.com/Can-I-use-apache-kafka-for-memory-cache
  • http://events.linuxfoundation.org/sites/events/files/slides/The%20Best%20of%20Apache%20Kafka%20Architecture.pdf
  • https://auriga.com/blog/hands-on-experience-building-architecture-of-highly-available-scale-out-systems-introduction/
  • http://blog.cloudera.com/blog/2014/09/apache-kafka-for-beginners/
  • https://sookocheff.com/post/kafka/kafka-in-a-nutshell/
  • https://www.elastic.co/blog/just-enough-kafka-for-the-elastic-stack-part1


728x90
반응형

'Web Programming' 카테고리의 다른 글

프레임워크와 라이브러리의 차이  (0) 2018.08.29
캐시와 쿠키의 차이  (0) 2018.08.29
WebSocket이란?  (0) 2018.08.29
SonarQube란?  (0) 2018.08.29
Jenkins 서버란?  (0) 2018.08.29

+ Recent posts