MANTL은 서로 연동성이 뛰어난 필수 요소들을 제공해 애플리케이션 구성, 배포 유연성을 위해 시작되었습니다. 오늘은 MANTL을 진정한 MANTL이 되게하는, 많은 논의가 진행중인 데이터 관리와 분석 요소에 대해 한 번 살펴보도록 하겠습니다.

1. IT Trend
MANTL을 MANTL답게! ELK로 만들어갑니다.
시스코 SDN 스페셜리스트 Kenneth Owens (케네스 오웬스)
MANTL은 서로 연동성이 뛰어난 필수 요소들을 제공해 애플리케이션 구성, 배포 유연성을 위해 시작되었습니다. 오늘은 MANTL
을 진정한 MANTL이 되게하는, 많은 논의가 진행중인 데이터 관리와 분석 요소에 대해 한 번 살펴보도록 하겠습니다.
ELK 스택은 무엇인가?
흔히들 마이크로 서비스는 종종 상태 정보와 무관하게 구성된다는 착각을 하십니다. 사실 상태 정보와 무관하다는 것은 애플리케이션
이 오류가 발생해서 그냥 재구동 시켜도 서비스에 영향을 받지 않는다 것을 의미하지요
그런데 문제는, 상태 정보와 무관한 애플리케이션은 실제 서비스에서는 큰 의미가 없다는 점입니다. 상태 정보와 상관없는 애플리케이
션들로 이루어진 세상을 한 번 생각해볼까요? 매일 주고 받는 이메일도, 필요한 것을 찾아주는 구글도 그 세계에서는 찾아볼 수 없을
것입니다. ELK스택은 데이터베이스의 유연한 검색을 제공하는 Elasticsearch(이하 ES), 변형, 추출하는 Logstash(이하 LS) 그리고 대쉬보
드에 데이터를 표현하는 어플리케이션 Kibana로 구성되어 있습니다. 사실 ELK는 이 세 요소의 첫 글자들를 모아서 이름이 붙여진 것입
니다. ES는 일반적인 NoSQL 데이터베이스와 동일한 형태를 지니고 있습니다. 쉽게 사용할 수 있고 확장성이 뛰어난 것이 그 특징이지
요. 이러한 ELK 스택은 MANTL 프로젝트의 한 부분입니다. 다른 말로 사용자들은 본인들의 어플리케이션을 위해 확장성이 뛰어나고, 분
산 구조를 지닌 유연한 데이터베이스인ELK를 out-of-box로 사용할 수 있다는 것입니다.
그럼, 아파치 Mesos는 무엇인가?
MANTL은 아파치 Mesos 기반에서 구동됩니다. Mesos는 리소스를 추상화하는 계층입니다. 애플리케이션들은 Mesos 위에서 필요한 리
소스에 대한 정보를 요청하는 것입니다. Mesos 클러스터는 리소스에 대한 관리와 정보에 대한 중개자 역할을 담당하게 되는 것이지요.
이를 통해 확장성과 유연성을 애플리케이션의 장점으로 가지고 갈 수 있습니다. 만약 리소스가 더 필요한 경우에는 클러스터내의 여러
노드를 통해 제공받을 수 있습니다. 이러한 구성으로 운영 중 문제가 발생하면 다른 노드로 이동하여 서비스가 유지될 것입니다. 애플
리케이션 개발자에게는 환경이 되는 리소스에 대한 고민이 더 이상 필요 없게 되는 것입니다.

2. 그럼 MANTL ELK 스택이 일반적인 ELK 스택과 다른 점은 무엇인가요?
기본적으로 Mesos위에서 구동되는 ELK 스택은 일반적인 ELK 스택과 동일한 기능을 제공합니다. 차이점은 Mesos 프레임워크를 기반으
로 한다는 것입니다. Mesos 프레임워크는 Mesos의 핵심 기능을 구현한 것입니다. Mesos 노드들 간의 프로세스 관리, 상태와 연결성에
대한 모니터링을 담당하고 있습니다. ELK의 ES 프레임워크를 예로 한 번 살펴보면, Mesos ES 프레임워크는 확장성이 용이한 ES 클러스
터를 사용자에게 제공합니다. 사용자는 옵션을 통해 ES 리소스에서부터 클러스터의 노드 수까지 쉽게 구성할 수 있습니다. 프레임워크
는 사용자가 입력한 값들을 기준으로 ES 리소스들을 유기적으로 연동하고 ES 클러스터를 구동시킵니다. 정상적으로 서비스가 구동되
어 동작하게 되면 상용 버젼과 같은 기능을 사용할 수 있습니다.
ES 클러스터 내에서 데이터는 복제됩니다. 복제에 대한 내용은 설정 가능하며, 기본적으로 모든 데이터는 다른 물리적인 노드에 복제되
도록 설정됩니다. 이러한 설정은 문제 발생시 유연한 복구 능력을 제공하게 되지요. 예를 들어 9개의 노드를 클러스터로 지니고 있는데,
9개의 장비가 동시에 모두 장애 발생시에는서비스가 이루어질 수 없습니다. 하지만 하나의 노드가 장애가 발생한다면 어떨까요? 프레
임워크는 이러한 문제를 즉각 인지하고 다시 서비스를 재구성합니다. 만약 노드가 장애가 난다면 다른 호스트에 서비스를 재구성하려
고 계속 노력하게 됩니다. 이러한 방식으로 프레임워크는 어플리케이션을 위한 상태정보, 데이터베이스를 가장 안정적으로 유지할 수
있는 기반이 되게 됩니다.
그러나 뭐니뭐니해도 ES 프레임워크의 핵심은 바로 확장성입니다. 모든 데이터가 모든 노드에 복제되기 때문에 ES 클러스터 내의 노드
수를 1에서 49로 늘렸다 다시 3으로 줄이더라도 데이터의 유실이나 서비스 중단을 걱정할 필요가 없답니다. 이 모든 작업이 단 한 번의
API 호출로 이루어질 수 있으니 이전의 복잡하고 예민했던 작업들을 생각해보면 가히 획기적이다!라고 표현할 수 있겠지요?
이러한 프레임워크의 파워는 이전과 다른 데이터베이스 업무 스케줄링을 가능하게 합니다. 데이터베이스가 지나치게 여유롭다고 생각
해볼까요? MANTL이라면 한 번의 API 호출로 쉽게 노드를 줄일 수 있습니다. 그럼 반대의 경우에는 어떨까요? 갑자기 서비스 요청이 증
가하게 됩니다. ES는 폭주하는 서비스 요청을 유지하려고 애를 쓰겠지요. 이러한 경우에도 한 번의 API 호출로 노드를 늘이고 서비스를
분산시킬 수 있는 것입니다.
이제까지 ES를 예를 들어 설명드렸고, LS나 Kibana에도 이러한 서비스 형태는 동일하게 적용됩니다.
LS 프레임워크는 Mesos에 의해서 생성된 메세지들을 ES로 전달되도록 합니다. 기본적으로 설정 파일을 통해 어떤 로그 파일이 어디로
전달될 것인지 정의할 수 있습니다. 이러한 로그들은 LS 프레임워크를 통해 처리되어 ES로 전달, 저장할 수 있게 됩니다. LS 프레임워크
는 기본적으로 다량의 다양한 로그데이터를 수집하고 모니터링 할 수 있습니다. 그래서 별도의 프로그래밍을 통해 logstash와 연동하지
않아도 사용자는 로그에 대한 서비스를 쉽게 사용할 수 있습니다. 그냥 설정파일에 어떤 로그파일을 보낼 것인지만 정의해주면 끝이랍
니다. 참 쉽죠?
[그림1] MESOS ELK 핵심 구성 모듈

3. MANTL상에 있는 ELK는 성능 최적화와 탄력성, 확장성을 제공하기 위한 놀라운 진보라고 할 수 있습니다. 성능 최적화 기능은 MANTL
아키텍처의 유연성을 제공할 것입니다. 만약 추가 리소스가 더이상 요구되지 않는 상태가 된다면 노드의 전원을 내리거나 종료하여 서
비스에 영향을 주지 않고 운영 자원을 절약할 수 있게 합니다.
시스템은 문제가 발생할 때 탄력적으로 운영 가능하게 됩니다. 어떤 하드웨어나 소프트웨어 문제 발생시 ELK를 통해 즉각적으로 인지
하고 신규 인스턴스를 생성하게 됩니다. 이를 통해 100%의 서비스 연속성을 제공할 수 있습니다. 또 서비스가 성공적으로 수행 중인데
사용률이 급증할 경우에는 쉽게 서비스 노드를 확장할 수 있습니다. ES를 통해 데이타는 안전하게 복제 관리되며, 소프트웨어 정의 스
토리지를 통해 하드웨어 3 copy 복제 로 저장됩니다.
이러한 모든 것들이 “왜 ELK인가요?”라는 잘문에 명쾌한 답변이 될 것 같습니다.
ELK 스택은 제반 환경에 대한 유일한 솔루션으로 가시적이고 확장성있는 프레임워크라고 할 수 있습니다. 특히 ES의 경우에는 폭넓은
범주에 충분히 활용 가능한 안전한 데이터베이스입니다. 무엇보다 중요한 것은 각각의 구성 요소들은 문제 발생시 유연하게 관리될 수
있다는 것입니다. MANTL은 가능한 쉽고 간단하게 클러스터를 생성하고 관리하기 위해 개발되었습니다. MANTL은 프로그래밍이 가능
한 인프라 구현을 위한 다양한 툴셋입니다. ELK 스택을 통해 MANTL은 더 완벽한 플랫폼이 될 것입니다.

4. [ 부록] ELK 상세 기술
MANTL ELK 데모
Mesos는 프레임워크를 위한 다양한 인터페이스를 제공하고 있습니다. 이 인터페이스는 작업에 대한 스케줄링과 실행에 대한 인터페이스
들인데요. 스케줄러는 실행하는 노드들에 대한 오케스트레이션과 상태 정보들을 유지하는 일을 담당하게 됩니다. 그리고 클러스터의 리
소스 정보를 제공하기 위해서 최상위의 API를 제공하고 있습니다.
실행자는 주어진 작업을 수행하는 역할을 담당합니다. ELK 스택의 ES, LS 그리고 Kibana를 실제로 수행하는 것이 Executor의 역할입니다. 이
러한 인터페이스는 C++, 자바 그리고 python 을 지원합니다. 새로 나오는 버젼에서는 HTTP 기반의 인터페이스도 제공된다면 훨씬 유용하
지 않을까 생각해봅니다.
[그림1]은 모든 프레임워크 아키텍처를 전체적으로 보여주고 있습니다. LS 프레임워크는 모든 에이전트에 logtash (분홍색)가 동작되어서
각 호스트의 파일 로그를 ES(초록색)에 전송할 수 있게 됩니다. ES프레임워크는 여러 노드들을 기반으로 클러스터로 구성되어있습니다. 프
레임워크는 이 클러스터를 유지하고 상태를 검증하게 됩니다. 만약 에이전트에 의한 ES 작업이 실패로 끝나게 되면, 다른 작업들은 클러스
터내의 다른 노드에서 수행하도록 됩니다. 그리고 신규 노드로 확장한 후 클러스터링 설정도 함께 업데이트되게 됩니다. 이렇게 처리된 내
용들은 여러 곳에서 동작하고 있는 Kibana가 ES 클러스터로 접속하여 화면에 정보들을 보여지게 합니다. MANTL 프로젝트 덕분에 모든 구
성 요소들은 consul DNS 주소를 지니게 되어 Kibana와 LS는 단일 HTTP 정보로 ES와 통신하게 됩니다.
모든 프레임워크는 두 개의 동작 모드를 옵션으로 지니고 있습니다. 기본적으로 Docker 컨테이너 형태로 구성되지요. 컨테이너 기반으로
구성할 때는 더 쉽게 배포하고, 테스트하고 더 간단하게 서비스를 확인해볼 수 있는 장점이 있습니다. 유일한 제약 사항은 바로 Docker와
Mesos라는 것이지요. 또 다른 옵션으로 ‘JAR 모드’를 제공합니다. 자바 코드를 바로 배포 받아서 노드에서 바로 구동할 수 있는대요. 이 모
드를 지원하기 위해서는 모든 노드가 JAVA 8 JRE로 구성되어야 하며 Mesos 바이너리도 사전에 준비가 되어야 합니다. 장점은 바로 Docker
가 아니라는 것이지요.
ELK의 세가지 구성 요소 중에서 ES가 가장 완성도가 높으며, 그 만큼 다소 복잡하게 구성되어있습니다. ES는 클러스터 모드로만 구성이 되
어야 합니다. 그래서 리소스에 대한 검색 기능을 지니고 있습니다. 멀티태넌트, 분산 구조에서 이 검색 기능은 몇 가지 제약사항을 가지게
됩니다. 그럼에도 불구하고 리소스에 대한 검색은 ES 동작의 가장 핵심으로 반듯이 포함되어야 합니다. 이를 위해서 Zen 디스커버리 방식
을 유니캐스트 모드로 사용하고 있습니다. 기본으로 설정 되어있는 멀티캐스트 모드는 클라우드 환경에서 차단되는 경우가 종종 있으니,
설정 시에 꼭 확인이 필요합니다. 스케쥴러는 ES에 다른 노드들의 주소를 제공합니다. 만약 신규 노드가 클러스터에 추가되면 Gossip 프로
토콜을 사용하여 자동 검색하여 추가하게 됩니다. 시스템을 하나의 노드로 축소할 경우에는 ES 설정에 다음과 같은 설정을 적용합니다.
이 설정은 멀티 노드도 확장하는 것을 원하지 않을 경우 사용됩니다.

5. [ 부록] ELK 상세 기술
“`
index.auto_expand_replicas: 0-all
“`
실행자는 자바 클라이언트를 통해 ES를 실행합니다. 이러한 구조로 인해 ES에 대한 제반 프로세스를 직접 제어할 수 있습니다. 스케일을
축소하는 것이 가장 적절한 예시인데요 현재는 특정 ES 버젼에 제한되는 기능입니다. 향후 프레임워크의 버젼에서는 공식적인 ESDocker
이미지나 바이너리를 ES 버젼 업데이트와 프레임워크로 분리할 예정입니다.
모든 프레임워크에 대한 상태는 Zookeeper에 기록됩니다. 스케쥴러가 실패하게 된다면 재기동 된 스케쥴러는 Zoopeeper를 통해 마지
막 상태를 확인하여 작업을 진행할 수 있습니다. 새롭게 실행된 스케쥴러는 상태를 확인하는 메세지를 보내 각 실행자가 정확히 동작하
는지 확인합니다. ES 프레임워크 코드 개발자들은 주요 기능들을 테스트하는데 상당한 노력을 기울였는데요. 프로젝트 Minimesos가 바
로 그러한 노력의 과정입니다. 이를 통해 신규 기능들이 원활하게 적용되어 동작하는 것을 체크하게 되었습니다.
LS 프레임워크는 아키텍처로는 상당히 다른 구성을 지니고 있습니다. LS 실행자는 로그 파일의 변경을 모니터링합니다. 그래서 모니터링
이 필요한 노드에서 각각의 실행자가 설치되어 동작되어야 하지요. 모든 Mesos 에이전트(워커노드)에 logstash 가 동작되어서 그것을 LS
스케쥴러가 모니터링함을 의미하는 것입니다. 만약 logstash가 구동될 여유가 없을 경우에는 시간이 필요합니다. 예를 들면 특정 노드가
대용량 어플리케이션에 의해 리소스가 여유가 없는 경우가 발생합니다. 이런 경우에도 Mesos는 LS를 위한 리소스를 일정 부분 확보하도
록 합니다.
Kibara 프레임워크는 아주 간단합니다. Kibara는 그 자체로 상태 정보를 관리하지 않는 애플리케이션입니다. 그래서 생성, 삭제시 고려해
야할 부분이 거의 없습니다. Kibara는 상용 Kibara에 오케스트레이션과 상태 관리에 대한 기능을 추가한 프레임워크입니다.