[칼럼] MANTL을 MANTL답게!! ELK를 통해 만들어갑니다

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 클러스터는 리소스에 대한 관리와 정보에 대한 중개자 역할을 담당하게 되는 것이지요. 이를 통해 확장성과 유연성을 애플리케이션의 장점으로 가지고 갈 수 있습니다. 만약 리소스가 더 필요한 경우에는 클러스터 내의 여러 노드를 통해 제공받을 수 있습니다. 이러한 구성으로 운영 중 문제가 발생하면 다른 노드로 이동하여 서비스가 유지될 것입니다. 애플리케이션 개발자에게는 환경이 되는 리소스에 대한 고민이 더 이상 필요 없게 되는 것입니다.

그럼 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와 연동하지 않아도 사용자는 로그에 대한 서비스를 쉽게 사용할 수 있습니다. 그냥 설정파일에 어떤 로그파일을 보낼 것인지만 정의해주면 끝이랍니다. 참 쉽죠?

정리하면...

MANTL상에 있는 ELK는 성능 최적화와 탄력성, 확장성을 제공하기 위한 놀라운 진보라고 할 수 있습니다. 성능 최적화 기능은 MANTL아키텍처의 유연성을 제공할 것입니다. 만약 추가 리소스가 더이상 요구되지 않는 상태가 된다면 노드의 전원을 내리거나 종료하여 서비스에 영향을 주지 않고 운영 자원을 절약할 수 있게 합니다.

시스템은 문제가 발생할 때 탄력적으로 운영 가능하게 됩니다. 어떤 하드웨어나 소프트웨어 문제 발생시 ELK를 통해 즉각적으로 인지하고 신규 인스턴스를 생성하게 됩니다. 이를 통해 100%의 서비스 연속성을 제공할 수 있습니다. 또 서비스가 성공적으로 수행 중인데 사용률이 급증할 경우에는 쉽게 서비스 노드를 확장할 수 있습니다. ES를 통해 데이터는 안전하게 복제 관리되며, 소프트웨어 정의 스토리지를 통해 하드웨어 3 copy 복제로 저장됩니다.

이러한 모든 것들이 “왜 ELK인가요?”라는 잘문에 명쾌한 답변이 될 것 같습니다.

ELK 스택은 제반 환경에 대한 유일한 솔루션으로 가시적이고 확장성있는 프레임워크라고 할 수 있습니다. 특히 ES의 경우에는 폭넓은 범주에 충분히 활용 가능한 안전한 데이터베이스입니다. 무엇보다 중요한 것은 각각의 구성 요소들은 문제 발생시 유연하게 관리될 수 있다는 것입니다. MANTL은 가능한 쉽고 간단하게 클러스터를 생성하고 관리하기 위해 개발되었습니다. MANTL은 프로그래밍이 가능한 인프라 구현을 위한 다양한 툴셋입니다. ELK 스택을 통해 MANTL은 더 완벽한 플랫폼이 될 것입니다.

이 칼럼을 SlideShare에서 다운받으실 수 있습니다!

<<클릭>> MANTL을 MANTL답게! ELK로 만들어갑니다