일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 제주
- Domain Driven Design
- elasticsearch
- hadoop
- SBT
- hibernate
- hdfs
- Angular2
- Hbase
- Spring XD
- Spring Batch
- design pattern
- Storm
- nginx
- Gradle
- 엘라스틱서치
- Spring Boot
- DDD
- docker
- elastic search
- apache storm
- Spring
- Linux
- scala
- Java
- 도메인주도설계
- intellij
- Clean Code
- 스프링 배치
- spark
- Today
- Total
욱'S 노트
Apache Storm - Running Topologies on a Production Cluster 본문
Apache Storm - Running Topologies on a Production Cluster
devsun 2015. 11. 20. 18:14프로덕션 클러스터에서 토폴로지를 실행하는 것은 로컬 모드와 유사하다. 다음과 같은 스텝을 따른다.
1) 토폴로지를 정의한다.
2) 클러스터에 토폴로지를 서브밋하기 위해 StormSubmitter를 사용한다. StormSubmitter는 토폴로지의 이름, 토폴로지 설정 그리고 토폴로지를 입력받는다. 예제는 다음과 같다.
Config conf = new Config();
conf.setNumWorkers(20);
conf.setMaxSpoutPending(5000);
StormSubmitter.submitTopology("mytopology", conf, topology);
3) 코드와 코드에 모든 디펜던시를 포함한 jar를 만든다. (storm 관련 jars는 워커 노드에 의해 제공되니 제거한다.)
만약 메이븐을 사용한다면 Assembly plugin이 도움이 될 것이다. 다음과 같이 pom.xml에 기술하면 된다.
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>com.path.to.main.Class</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
mvn assembly:assembly를 실행하면 적절히 패키지된 jar를 얻을 수 있다.
4) 스톰 클라이언트를 이용해 topology를 클러스터에 서브밋하자. 각 인자를 사용할수도 있다.
storm jar path/to/allmycode.jar org.me.MyTopology arg1 arg2 arg3
스톰 jar는 클러스터에 submit되고 설정된 StormSubmitter 클래스는 즉시 클러스터와 통신을 할것이다. 예를 들어 스톰 jar 업로드 된 후 MyTopology의 "arg1", "arg2", "arg3"의 인자로 메인 함수를 호출할 것이다.
Common configurations
토폴로지를 설정할 수 있는 다양한 설정들이 존재한다. TOPOLOGY 라는 접두어를 가진 것들은 TOPOLOGY 기반 설정으로 오버라이드될 수 있다. 다음은 토폴로지를 위해 세팅할 수 있는 내용들이다.
- Config.TOPOLOGY_WORKERS: 토폴로지를 실행할때 사용할 워커 프로세스의 수. 예를들어 25로 세팅하면 클러스터내에 25개의 자바 프로세스가 뜬다. 만약 150 parallelism을 수행하면 각 프로세스는 6개의 타스크를 스레드로 수행시킨다.
- Config.TOPOLOGY_ACKER_EXECUTORS: 이 세팅은 투플 트리를 추적하고 분출된 투플이 완전히 수행되었는지를 검사하기 위함이다. Acker는 스톰의 reliability를 위한 필수적인 요소이다. 자세한 내용은 Guaranteeing message processing에서 알아볼 것이다. 세팅을 하지 않거나 null로 세팅을 하면 storm은 acker executor를 수를 토폴로지의 워커 프로세스의 수와 동일하게 할 것이다. 0으로 세팅하면 스톰은 spout에서 분출한 즉시 ack를 수행하여 reliability를 비활성화 할 것이다.
- Config.TOPOLOGY_MAX_SPOUT_PENDING: 이것은 하나의 spout task에서 분출한 투플의 최대 펜딩 숫자이다.(펜딩은 투플이 아직 ack하지 않았거나 실패를 하지 않았다는 것을 의미한다). 큐가 폭발하는 것을 방지하기 위해 꼭 설정할 것을 권고한다.
- Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS: 분출한 투플이 완전히 처리되는데 소요되는 최대 시간이다. 이 시간동안 완전히 처리되지 않았다면 실패로 간주한다. 기본값은 30초이며 대부분의 토폴로지에서 충분하다.
- Config.TOPOLOGY_SERIALIZATIONS: 투플내에 커스텀 타입을 사용하기 위해 이 설정을 이용해서 더 많은 serializer를 등록할 수 있다.
Killing a topology
토폴로지를 중지하기 위해선 단순히 다음을 실행하면 된다.
storm kill {stormname}
토폴로지를 서브밋할때 사용한 이름을 똑같이 입력하자.
스톰은 즉시 토폴로지를 중단시키지 않는다. 대신에 모든 spout들을 비활성화시키고, 스톰은 Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS에 설정된 시간만큼 대기한 다음에 모든 워커를 중단시킨다. 이것은 토폴로지에게 수행중인 투플을 완전히 처리할 수 있도록 충분한 시간을 제공하기 위함이다.
Updating a running topology
실행중인 토폴로지를 업데이트하기 위해 유일한 옵션은 현재 토폴로지를 중단하고 새로운 것을 다시 서브밋하는 것이다.
Monitoring topologies
토폴로지를 모니터링 하기 위한 가장 좋은 방법은 Storm UI를 활용하는 것이다. Storm UI는 task내에서 발생한 에러에 대한 정보를 제공하고 처리량 및 각 수행중인 토폴로지의 컴포넌트에 대한 지연등을 잘 정리된 통계로 제공한다.
또한 클러스터 머신에 대한 worker 로그를 살펴볼 수 있다.
'Programming > Storm' 카테고리의 다른 글
Apache Storm - Trident Tutorial (0) | 2015.12.07 |
---|---|
Apache Storm - Concepts (0) | 2015.11.19 |
Apache Storm - Setting Up a Development Environment (0) | 2015.10.30 |
Apache Storm - Tutorial (0) | 2015.10.29 |
Apache Storm - Setting up a Storm Cluster (0) | 2015.10.27 |