태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

엑기스 | All about Kubernetes

기술이야기/엑.기.스 2019.05.08 13:38

 

 

 

 최근 쿠버네티스(Kubernetes)에 대한 관심이 뜨겁습니다. 아래의 차트를 통해 알 수 있듯이 해외 뿐 아니라 국내에서도 쿠버네티스에 대한 관심이 꾸준하게 증가하고 있습니다.

 

                     <쿠버네티스에 대한 관심도 변화(해외)>                                          <쿠버네티스에 대한 관심도 변화(국내)>

 

 특히, 2018년도에 AWS가 Kubernetes를 지원하는 EKS 서비스를 발표하면서 퍼블릭 클라우드 시장에는 Google GCP의 GKE, Microsoft Azure의 AKS, Amazon AWS의 EKS를 통해 공식적으로 모든 퍼블릭 클라우드에서 쿠버네티스를 이용할 수 있게 되었습니다. 과연 쿠버네티스가 무엇이길래 전 세계적으로 관심이 증가하고, 또, 퍼블릭 클라우드 업체들이 앞 다투어 쿠버네티스 서비스를 지원하는 것일까요?

 

 

 

1. Kubernetes?

 Kubernetes(k8s)란, 2014년 구글에서 공개한 이후 CNCF(Cloud Native Computing Foundation)가 주도하고 있는 오픈소스로서, 컨테이너화 된 애플리케이션을 자동으로 배포, 스케일링 해주는 컨테이너 오케스트레이션(Container Orchestration) 툴입니다. 

 

 쿠버네티스에서 이야기하는 컨테이너는 격리된 공간에서 프로세스가 동작하는 기술을 말합니다. 즉, 애플리케이션 외에 Linux 등의 환경적인 요소들을 하나의 컨테이너로 묶음으로써 다양한 유저환경에서도 애플리케이션이 안정적으로 실행될 수 있게 해주는 기술입니다. 

 

 쿠버네티스는 하나의 Master Node와 여러 대의 Worker노드로 하나의 클러스터를 구성합니다. 그리고 이러한 쿠버네티스 환경에서 수백, 수천 개의 컨테이너들을 자동으로 배포, 스케일링하면서 서비스들을 안정적으로 운영할 수 있게 해주는 역할을 합니다.

<Kubernetes의 Master Node와 Worker Node의 단순 구조도>

 

 

 

2. 쿠버네티스를 좀 더 구체적으로 들여다보기

 쿠버네티스의 기본 기능은 정말 많지만 기능을 설명하기 보다는 Container Orchestration 관점에서 Status management, Scheduling, Rollout/Rollback 이라는 세 가지의 특징을 살펴보고자 합니다. 

 

1) Status management

 먼저 Status management는 노드가 죽거나 컨테이너 응답이 없을 경우 자동으로 복구하는 것을 의미합니다. 예를 들면, 쿠버네티스에서 컨테이너를 관리하는 단위를 Pod라고 하는데, 쿠버네티스는 Pod가 죽게 되면 컨테이너에서 실행 중이던 서비스가 중단되게 됩니다. 따라서, 운영중인 Pod의 장애가 전체 서비스에 영향을 미치는 것을 막고자 쿠버네티스는 ReplicaSet이라는 개념을 통해 Pod의 복사본들을 두어 실행 중인 Pod에 장애가 발생하더라도 즉시 다른 Pod로 대체하여 서비스의 상태를 유지하게 합니다.

 

2) Scheduling

 클러스터의 여러 노드 중 조건에 맞는 노드를 찾아 컨테이너에 배치합니다. 만일, 3대의 Worker Node가 각각 10MB, 100MB, 1GB의 메모리를 가지고 있고, 실행하고자 하는 컨테이너가 500MB의 메모리를 필요로 한다면, 쿠버네티스는 컨테이너를 실행할 수 있는 1GB의 메모리를 가진 노드에 자동으로 배포하여 컨테이너 실행에 장애가 발생하지 않도록 합니다.

 

3) Automatic RollOut and RollBack

 쿠버네티스는 버전 관리를 쉽게 할 수 있게 합니다. 기존의 단일(Monolithic) 서버 환경에서는 서비스에 업데이트가 일어나는 경우 서버 운영자가 운영 중인 서비스를 내리고 다시 버전업 된 서비스를 올리는 동안 유저들이 서비스를 이용할 수 없는 다운 타임이 발생하게 됩니다. 하지만, 쿠버네티스 환경에서 서비스를 운영하게 된다면 Deployment라는 개념을 이용하여 rolling update가 이루어지고, rolling update를 통해 운영 중인 서비스를 중단하지 않고도 서비스의 업데이트가 이루어질 수 있습니다. 물론, 업데이트한 서비스에 문제가 발생한 경우에는 Deployment에 저장되어 있던 이전 버전의 서비스로 다운 타임 없이 복구 시킬 수도 있습니다.

 

 

 

3. Kubernetes는 만병통치약?

 이렇게 완벽한 서비스를 해줄 것 같은 쿠버네티스에도 맹점이 존재합니다. 

 

 첫 번째는 클러스터를 구성하는 노드들의 상태를 서버 운영자가 실시간으로 확인하기 힘들다는 점입니다. 쿠버네티스에 올라가는 모든 서비스는 여러 개의 worker node로 분산되어 실행됩니다. 하지만 하나의 worker node에 장애가 발생한 경우 서버 운영자가 직접 쿠버네티스에 접속하여 노드의 상태를 확인하기 전까지는 노드의 상태를 파악하기가 쉽지 않습니다. 

 

 두 번째는 쿠버네티스에서 운영되는 서비스는 Micro Service로 운영되기 때문에 서비스가 느려지거나 장애가 발생한 경우 연결된 여러 개의 서비스 중에 어떠한 서비스에 문제가 생겼는지 파악하기가 어렵습니다. 만일 많은 사용자들이 동시에 DB에 접근하여 데이터를 입력하는 경우 운영 중인 DB에는 부하가 걸리게 되고 이는 서비스의 속도에 영향을 미치게 됩니다. 하지만 쿠버네티스에서는 모니터링 서비스를 따로 지원하지 않기 때문에 어떤 서비스에서 어떤 문제가 발생했는 알기 어렵습니다.

 

 마지막으로는 하나의 서비스가 쿠버네티스 상에서 실행되는 경우 서비스의 원활한 운영을 위해 장애 예측 및 장애 분석을 위한 툴이 필요하다는 점입니다. 만일, 특정 장애가 특정 시간에 주기적으로 발생하는 경우 지속적으로 원활한 서비스 제공하기 위해 장애를 분석할 수 있는 도구가 필요합니다.

 

<쿠버네티스 상에서의 모니터링 솔루션, InterMax Cloud>


 위와 같은 문제들을 사전에 방지하고 장애를 빠르게 파악하여 고객에게 원활한 서비스를 제공하기 위해서는 Kubernetes Monitoring System이 필요합니다. 특히, InterMax Cloud는 운영 중인 쿠버네티스 서비스를 시각화하여 CPU, Network 등의 운영 중인 시스템 상태를 파악할 수 있게 하고, 장애가 발생한 지점을 빠르게 파악할 수 있게 도와줍니다. 또한, 희소 로그 분석, Anomaly Score 분석 등 다양한 관점에서의 강력한 분석 기능을 통해 서버 운영자가 장애를 예측하고, 대응할 수 있도록 도와줍니다. 이런 강력한 기능들이 있는 InterMax Cloud. 쿠버네티스를 통해 서비스를 운영 중인 기업이라면 한 번쯤 도입을 고려해 봐야 하지 않을까요?









기고 | Cloud개발팀 윤영민

편집 | 사업기획팀 박예영

엑기스 | 양자역학과 양자컴퓨터 이야기

기술이야기/엑.기.스 2019.04.10 14:54


 

 

들어가기에 앞서...

 이 글은 상당 부분을 책 <케네스 포드의 양자물리학 강의>의 내용을 참고 및 재구성했습니다. 양자역학과 양자컴퓨터에 대한 이해에 조금은 보탬이 되었으면 하는 바람으로 작성했으니 재미있게 읽어주시고, 양자역학에 대해 더 자세하게 알고 싶으시다면 책을 읽어보시길 추천드립니다. 

 

 

서론

알베르트 아인슈타인 “신은 주사위 놀이를 하지 않는다.”

닐스 보어 “양자 이론을 생각할 때 머리가 아프지 않은 사람이 있다면, 그 사람은 제대로 이해하지 못한 것이다.”

리처드 파인만 “세상에 양자 이론을 이해하는 사람은 없다고 해도 과언이 아니다.”

에르빈 슈뢰딩거 “나는 그것(양자역학)을 좋아하지 않는다. 내가 그 발전에 기여했다는 것이 유감이다.”

막스 폰 라우에 “그것(드 브로이 물질파 이론)이 사실이라면 나는 물리를 그만두겠다.”

 

 우리는 수 많은 과학자들의 인용구에서부터, 우리가 알던 위대한 과학자들조차 고개를 젓게 만드는 양자이론을 이해하려고 달려들면 분명 골머리를 썩히는 정도로 끝나지 않을 것이라고 예상할 수 있다. 하지만 세상은 이미 현실로 다가오고 있는 양자컴퓨터, 양자통신 등을 맞이할 준비로 분주하며, 양자 물리학의 오묘한 이론들은 이미 주사 터널링 현미경, 마이크로 회로, 레이저 등 현실에서 활용되고 있다. 멀지 않은 미래에 양자 이론이 점철된 세상에 대뜸 직면하기 전에, 머리가 지끈거릴지언정 양자 이론이 건네는 이야기를 귀담아 들어볼 가치는 충분할 것이다.

 

 

가깝고도 먼 상식의 바깥, 아원자 세계

 양자 이론이 초대하는 양자 세계에 발을 들이기 전에, 우리의 드레스 코드를 점검할 필요가 있다. 양자 이론에서 다루는 세상은 우리가 일상에서 보고 듣는 세상의 모습인 거시 세계와는 상당히 다르며, 거시 세계의 관점으로 바로 접근하려고 하면 퇴짜를 맞게 될 것이다. 양자 이론의 연구 영역은 원자조차도 거대해 보이는 아원자 세계를 들여다봐야 하며, 매우 작고(양자 이론), 매우 빠른(상대성 이론) 입자들의 세상이라고 말할 수 있다. 덧붙여 ‘양자’란 어떤 특정한 입자를 가리키는 것이 아니라, 이러한 원자 또는 원자보다도 작은 세상에서 양자 이론의 규칙을 따르는 모든 입자를 지칭한다.

 

 그렇다면 원자보다 작은 세상이란 얼마나 작은 세상인지 상상해보자. 우주의 반지름은 10의 26승 미터쯤 되고, 입자 실험의 최소 탐사 거리는 10의 -18승 미터쯤 된다. 둘 사이의 중간 평균은 10의 4승 미터 즉 10km가 되는데, 누군가의 통근 거리 되는 우리가 사는 세상의 길이라고 볼 수 있다. 따라서 우리가 아원자 세계를 들여다보려는 시도는 우주 바깥에서 우리가 출퇴근을 하는 모습을 관찰하려는 시도 만큼이나 황당한 시도라고 볼 수도 있겠다.

 

 단순히 무지막지하게 작다는 사실만이 우리가 양자 이론의 법칙들을 이해하기 힘들게 하는 게 아니다. 아원자 세계에서는 우리가 알던 직관과 상식이 통하지 않는다. 파동-입자 이중성, 중첩과 얽힘, 배타 원리, 그 밖의 수 많은 아원자 세계의 규칙이 되는 물리학 법칙들이 있다. 우리가 이러한 아원자 세계의 상식으로 움직인다면 차를 타고 다닐 필요 없이 순간 이동을 할 수 있게 되며, 서울에서 아침밥을 먹는 동시에 뉴욕에서도 저녁 식사를 할 수도 있다.

 

 이제 앞서 이야기한 물리학자들이 양자 역학을 대하는 심정이 조금은 이해가 간다. 이렇게 귀신 같은 현상들(물질의 파동성, 확실성이 아닌 확률성을 근간으로 하는 양자)을 기초로 하는 양자 이론은 사실 오랜 역사 동안 실험적 검증에서 실패한 예가 하나도 없다. 즉, 물리학자들이 양자 역학을 힘들어하는 데는 이런 귀신 같은 현상들이 그 근간이 되는 원리가 밝혀진 바가 없는 반면, 아원자 세계의 현상을 설명하는데 있어 단 하나의 흠도 없이 굴러간 성공적인 이론이기 때문이다. 어느 날 외계인이 찾아와 건넨 출처를 알 수 없는 말도 안되는 예언들이 막상 현실에서는 모두 들어맞는 것과 같은 상황에서, 양자물리학자들조차 자연의 이치를 깨우친다기보다 반쯤 해탈한 상태로 그저 받아들일 뿐이다...

 

닐스 보어 “아인슈타인, 신에게 참견하지 말게나.”

-1927년 솔베이 회의 중, 알베르트 아인슈타인이 남긴 말 “신은 주사위 놀이를 하지 않는다.”에 답하며.-

 
 
중첩(Superposition)과 얽힘(Entanglement)

 양자 이론이 이야기하는 세계는 정말 기괴한 현상들 뿐이지만, 조금 더 나아가 보자. 중첩과 얽힘은 양자 이론에서 가장 중요한 개념 중 하나에 속하기도 하지만 역시 가장 이해하거나 받아들이기 어려운 부분이기도 하다. 중첩에 대해 얘기하기에 앞서, 드 브로이의 방정식을 먼저 살펴보자.

왼쪽은 파장(람다), 오른쪽은 플랑크 상수 h와 운동량 p이다. 고전 역학에서는 엮일 일이 없었던 두 개념인 파장()과 운동량(p)이 양자적 연결 고리(플랑크 상수 h)로 이어졌다(=). 따라서 드 브로이 방정식은 파장이 운동량과 연결되어 있음을 시사하는 양자계의 혁명적인 발견이었다. 여기에서 더 나아가면 특정 파장은 특정 운동량을 갖는다는 의미를 찾을 수 있다.

 

 양자 역학에서 파장은 여러 파동들의 중첩으로 생긴 수학적인 확률 함수인 ‘파동함수’로 나타낼 수 있는데, 이 함수의 절대값의 제곱(정확히는 진폭의 복소제곱)은 입자가 특정 위치에서 존재할 확률을 나타낸다.

 

 이제 위의 혼란스러운 수학적인 문구들을 종합해 수소 원자 주위를 도는 전자에게 적용해보자. 전자는 파장을 가지며(사실 모든 물질은 파장을 지닌다) 이는 여러 파동들의 중첩으로 이루어져 있다. 그리고 각각의 파동들마다 특정 운동량을 지니며, 이는 곧 수소 원자핵 주변을 도는 전자가 동시에 두 가지 이상의 운동량을 가진다는 의미가 된다. 이를 중첩이라고 하며, 우리가 확인(관측)하는 순간에는 파동함수의 확률을 통해 이러한 수 많은 운동량 중 어떤 운동량을 가질지 결정이 된다. 한 문장으로 설명하자면 양자의 상태는 우리가 눈으로 확인(관측)하기 전까지 알 수 없으며, 그만큼 하나의 양자는 여러 상태를 동시에 가질 수 있다는 것이 중첩이다.

<중첩을 묘사하는 대표적인 예, 슈뢰딩거의 고양이 역설>

 슈뢰딩거는 양자역학의 비상식적인 면을 비판하기 위해 역설적인 사고 실험을 내놓았지만 아이러니하게도 양자역학을 묘사하는 가장 대표적인 실험이 되었다 - 출처 : IBS(기초과학연구원)

 

 아마 제일 이해할 수 없는 부분은 ‘여러 상태를 동시에 가진다’와 ‘관측하는 순간에 확률에 의해 상태가 결정된다'는 부분일 것이다. 하지만 머릿속으로 중첩된 상태의 전자가 상상되지 않는다고 낙담할 필요는 없다. 당연하게도 우리의 관점으로는 투수가 던진 야구공이 직구와 커브 두 가지 경로로 동시에 다가오고 있는 상황이나, 슈뢰딩거의 고양이의 운명이 상자를 여는 우리의 손에 달려있다는 것을 이해할 수가 없다. 사실 중첩을 완벽히 묘사하는 삽화를 찾을 수 없는 이유도 양자 물리학자들 또한 마찬가지로 중첩 상태를 머릿속에 그릴 수는 없기 때문이다.

 

 양자 얽힘은 중첩과 크게 다르지 않다. 중첩이 공간 상으로 떨어져 있는 둘 이상의 계(system)에 일어난 경우를 얽힘이라 한다. 광자(빛 알갱이)를 쪼개어보자. 쪼개진 광자들은 스핀 up, 스핀 down 두 가지 양자 상태를 가지는 중첩된 상태가 되었으며, 한 쪽이 up이라면 다른 한 쪽은 down을 갖는다. 그리고 광자 한 쪽은 아주 멀리, 다른 은하 건너편까지 보내놓는다. 이때 지구에 남은 광자 한 쪽을 확인(관측)하는 순간 파동 함수는 붕괴되고 확률에 의해 지구에 남은 광자의 양자 상태가 결정되는데, 특이하게도 그 순간 은하 건너편의 광자 한 쪽의 양자 상태도 결정된다. 지구에 남은 광자가 up이라고 확인하는 순간 은하 건너편의 광자는 down이 되고, 그 반대도 마찬가지이다. 

  

 얽힘을 이해하려면 아무리 멀리 있어도 두 입자는 사실 쪼개지기 전이나 쪼개진 후나 ‘하나의 계’를 이룬다는 해석이 필요하다. 사실 시공간의 제한에 항상 갖혀 살던 우리의 관점에서는, 은하 건너편까지 옮겨간 광자와 지구의 광자가 둘이 꼭 붙어있는 것처럼 행동한다는 걸 이해하기란 전혀 모르는 외국어를 듣는 느낌보다도 더 할 것이다. 아인슈타인 또한 양자 얽힘을 “귀신 같은 원격 현상”이라고 표현하며 그의 생애 동안 끝까지 인정하지 않았다. 앞서 언급했듯이, 중첩이나 얽힘 역시 어째서 일어나는 현상인지 까지는 현재 규명해내지 못했으며, 과학계 또한 ‘가정’과 ‘측정 결과’가 잘 맞아 떨어지니 그저 받아들일 수 밖에 없다는 입장이 대부분이다.

 
 
큐비트(Qubit)와 양자컴퓨터(Quantum Computer)
 전자의 중첩을 이해했다면(또는 어쨌든 그렇다 치자고 받아들였다면..) 이제 큐비트라는 것을 설명할 수 있다. 올해 초 CES 2019에서 선보인 IBM의 ‘최초의 상용 양자 컴퓨터’가 화제였다. 아직 갈 길은 멀어 보이지만, 양자 컴퓨터가 드디어 연구실 밖으로 발을 내딛었다는데 의의가 있어 보인다. 왜 사람들은 양자 컴퓨터의 출현을 기다리고 있을까? 양자 컴퓨터라고 해도 현존하는 슈퍼컴퓨터보다 연산이 좀 더 빠른 정도가 아닐까? 양자 컴퓨터의 잠재력을 가늠하려면 우선 양자 컴퓨터가 어떤 것인지 알아봐야 할 것이며, 양자 컴퓨터가 그리는 혁신적인 미래는 큐비트로 실현된다.
 

<세계 최초 상용 양자컴퓨터”라는 타이틀을 걸고 등장한 IBM Q System One - 출처 : IBM>

 

 큐비트란 ‘동시에 두 방향의 스핀을 갖는 전자’다. 또는 연산의 기본 개념인 비트(bit)와 양자(quantum)가 합쳐진 양자 비트(quantum bit)의 줄임말이다. 두 방향의 스핀을 0, 1이라고 본다면 고전적인 비트와 차이점은 무엇일까? 앞서 이야기한 중첩이 다시 등장할 때이다. 비트는 0 또는 1 둘 중 하나일 뿐이지만, 큐비트는 중첩된 두 방향의 스핀을 가지므로 동시에 0과 1 두가지일 수 있다. 그래서 큐비트를 표현할 때는 그림과 같은 구체로 많이 표현되며, 구체 표면을 향하는 벡터 0일 확률과 1일 확률의 혼합으로 나타낸다. 덧붙이자면 꼭 0과 1이 동등한 확률일 필요는 없다. 큐비트는 87%는 0이면서 13%는 1일 수도 있다. 물론 큐비트도 중첩 상태이므로 관찰하는 순간, 0 또는 1로 결정된다.

<큐비트를 표현한 ‘블라흐 구체’ - 출처 : IBM>

 

 이렇게 두 가지 상태가 중첩된 큐비트는 연산에 적용할 때 이론 상 방대한 연산 능력을 보여준다. 고전적인 비트가 논리 게이트를 한 번에 하나씩 통과할 때, 큐비트는 동시에 두 가지 상태가 통과한다. 큐비트 하나는 0과 1 두 가지 상태 뿐이지만, 큐비트를 하나씩 늘려보면 이야기가 달라진다. 두 개의 큐비트를 시뮬레이션 한다면 00, 01, 10, 11 네 가지의 상태를 얻을 수 있으며, 이 네 가지 결과의 가능성들이 두 개의 큐비트에 한데 묶여서 표현된 것이다. 이어서 세 개의 큐비트는 23개, ... N 개의 큐비트는 2N개의 방식으로 혼합될 수 있다. 이론 상의 양자 논리 게이트라면 이 어마어마한 가능성들을 한 번에 읽어낼 것이다. 그러나 엄청난 수의 큐비트를 탑재한 양자 컴퓨터가 실현되기 어려운 이유는 이 논리 게이트가 계를 방해하지 않아야 한다는 조건이 붙기 때문인데, 조금이라도 상호 작용이 발생하는 순간 큐비트의 수 많은 가능성들은 단 하나의 가능성으로 붕괴할 것이다. (관측에 의해 중첩이 사라지고 결과만이 남는 것이다. 상자를 열어 슈뢰딩거의 불쌍한 고양이의 운명을 결정지어버린 것.) 현재도 양자 컴퓨팅 분야의 많은 연구진은 극저온의 매우 민감한 프로세서로 큐비트를 제어하느라 애를 먹고 있다.

 

 다시 큐비트의 이야기로 돌아가서, 이제 이상적인 양자 논리 게이트를 거친 큐비트에서 정보를 추출해보자. 무수한 가능성들은 붕괴되고 평범한 비트와 같은 단 하나의 정보가 추출되어 나온다. 말단에서는 결국 정보를 추출해서 고전적인 비트 형태의 결과물을 얻어야 한다면 양자 컴퓨팅의 이점은 없는 것일까? 아니다. 큐비트는 무수한 가능성들을 거쳐서 하나의 결과를 보여준 것이다. 즉, 중첩되어 있던 방대한 양의 정보가 단 하나의 해답으로 쏟아져 들어간 것이다. 

 

 이러한 특징은 우리가 양자 컴퓨터를 어떻게 활용할 것인가에 대한 통찰력을 선사한다. 예를 들면 도로 교통 상황을 분석하는 문제에서 차량 하나하나의 움직임을 분석하면 교통 상황을 예측할 수 있겠지만, 현재는 알고리즘의 복잡도와 연산 속도라는 한계로 인해 현실적으로 이런 분석은 불가능하다. 하지만 양자 컴퓨터는 수 많은 차량의 가능성(방대한 양의 정보)을 계산해 도로 상황을 예측(단 하나의 해답)을 내 놓을 것이다. 이 외에도 양자 컴퓨터는 날씨 예보, 암호 해독, 신약 개발, 시장 분석, 자연어 분석 등등 수 많은 분야에 활용 될 수 있으며 현재 풀리지 않은 미스터리 같은 문제인 아원자 입자들의 미시적 운동을 분석하는 학문 분야까지 해답을 찾아내 줄 것으로 기대되고 있다.

 
 

마무리

 지금까지 양자 역학 세계의 일부분을 살펴보면서 양자 컴퓨터란 어떤 것인지 까지 간단하게 알아보았다. 양자 이론은 알면 알수록 이해할 수 없지만, 오히려 그렇기 때문에 더욱 더 의문점을 남기며 파고들게 하는 것 같다. 양자 컴퓨터가 아직 얼마 나아가지 못한 듯 보여도, 양자 컴퓨터가 세상을 바꾸는 미래는 반드시 올 것이며, 어쩌면 우리가 생각하는 것보다 빠를 수 있다. 머리가 아파오는 이론이지만 미래에 대비하기 위해서라도 양자 세상을 들여다보면, 생각했던 것보다는 제법 흥미롭다는 것을 발견할 수 있을 것이다.

 

존 휠러 “살날이 얼마 남지 않은 것 같으니, 남은 시간은 양자에 대해 생각하는 게 좋겠다.”

 

 

감사합니다.

 

 

EXEM의 콘텐츠에 대하여 궁금하다면? 여기를 눌러 문의해보세요!


 

 


기고 | AI사업본부 이동하

편집 | 사업기획팀 박예영

엑기스 | AIOps가 뭐지?

기술이야기/엑.기.스 2019.03.07 12:59

 

 

#1. AIOps 용어 등장

 AIOps는 풀어 쓰면 ‘Artificial Intelligence for IT Operations’ 또는 ‘Algorithmic IT Operations’입니다. 2014년 Gartner 보고서에 등장한 용어로, IT 운영에 AI를 도입함으로써 그 운영을 좀 더 지능화, 효율화하는 것을 뜻합니다.

<The History Of AIOps, 출처: Loom Systems>

 

 

#2. AIOps의 등장 배경

 과거에는 ICT 인프라가 모놀리틱 아키텍처로 단순했습니다. 따라서 WAS나 데이터베이스를 잘 모니터링하는 것만으로도 ICT 운영팀 임무를 충분히 달성할 수 있었습니다.

 기술이 발전하면서 SOA(Service Oriented Architecture)가 도입되었고, 근래에는 MSA(Microservices Architecture)가 유행하고 있습니다. 이는 운영/관제 대상 시스템이 다양하게 많아진 것을 의미하고, 메트릭, 로그 등 운영 데이터의 양도 급격히 늘어나게 되었다는 것을 말합니다. 그 만큼 ICT 운영이 어려워진 것이죠. 

 이제는 단순히 여러 관제 도구를 도입하고, 운영 요원을 늘린다고 해서 안정적 서비스 제공이 보장되지 않습니다. ICT 운영에 AI를 도입함으로써 안정적 서비스 보장과 운영 요원 피로도 감소, 운영 비용 절감 등을 꾀하고자 AIOps라는 개념이 등장하였습니다.

 

<AIOps Platform Enabling Continuous ITOM, 출처: Gartner>

 

 

#3. AIOps 시장 전망

 아래 그림에서 알 수 있듯이, 2018년 Gartner는 향후 5~10년 내에 AIOps가 하나의 기술 또는 제품으로서 시장에 자리 잡을 것이라고 예견했습니다.

<Hype Cycle of ICT in India 2018, 출처: Gartner>

 

또한 한국IDC에서도 2019년 국내 ICT 시장에서도 AIOps가 10번 째로 유력한 기술이나 트렌드가 될 것이라고 전망했습니다.

 

 

<한국IDC, 2019년 국내 ICT 시장 10대 전망 발표>

#10 AI기반의 IT 운영(Operations): IT 지출을 축소하고, 기업의 IT 민첩성을 개선하며, 혁신을 가속화할 수 밖에 없게 되면서, 60%의 CIO가 2021년까지 IT 운영, 툴, 프로세스에 있어 데이터 및 AI를 공격적으로 적용하게 될 것이다.

 

시장 측면에서 보면, AIOps 시장 크기는 세계 기준 2017년 약 2조 원에서 2025년 약 24조 원으로 매년 36.2% 성장할 전망입니다. 국내 시장이 세계의 1%라고 가정하면, 2017년 200억 원 시장에서 2025년 2,400억 원 시장으로 성장하는 것이죠.

<Global AIops Platform Market Outlook, 2017 & 2025 ($Billion), 출처: COHERENT MARKET INSIGHTS, 2018>

 

 

#4. 국내외 AIOps 벤더 현황

 해외에는 미국을 비롯한 30여개의 AIOps 벤더가 존재하고, 이 중 BMC, Splunk는 이미 국내에 진출해 있는 상황입니다. 하지만 국내에는 아직 명시적으로 AIOps를 표방하는 벤더는 엑셈 이외에 잘 보이지 않습니다.

 

 - 미국: AppDynamics, BMC, CA, Dynatrace, FixStream, IBM, InfluxData, Loom Systems, Moogsoft, Splunk, VMware 등 20여 벤더

 - 영국: Micro Focus 등

 - 네덜란드: StackState 등

 - 이스라엘: Anodot, VNT Software 등

 - 인도: HCL, VuNet 등

 - 일본: Brains Technology 등

 

 엑셈은 이미 지난 해에 자사의 MaxGauge, InterMax에 AIOps 기능을 탑재하는 형태로 개발을 진행해 왔는데요. 올 해 초에는 국내 모 금융사에 PoC를 성공적으로 마친 상황이고, 이제는 ‘InterMax AIOps’ 이름으로 본격 제품화를 꾀하고 있습니다.

 

 

#5. AIOps 기대 효과

 

<Predict and Prevent Operational Issues with AI, 출처: Splunk>

 

 1) 장애 자동 감지, 자동 복구를 통해 ICT 운영 요원의 피로도를 감소시킨다.

 2) 선제적으로 장애에 대응하게 함으로써 MTTR(Mean-Time-to-Repair)을 획기적으로 줄인다.

 3) MTTR을 줄이는 만큼 고수준의 SLA(Service Level Agreement)를 보장하게 된다.
 4) 이는 이용자의 서비스 이탈을 막고, 고객 신뢰가 높아지는 요인이다.
 5) 공공 기관일 경우, 이미 대국민 서비스가 세계 상위 수준이나 이를 더욱 공고히 할 수 있다.
 6) 해외 AIOps 벤더들이 국내로 진출하는 속도를 저감시킬 수 있다.
 7) 중국, 동남아 등으로 AIOps 제품을 수출함으로써 ICT 한국의 위상을 수성할 수 있다.
 8) 버려지는 운영 데이터를 관련 기업들에 제공, AI 연구에 재사용할 수 있게 된다.
 9) AIOps 구축 사업, 운영 데이터 거래 등이 활성화 되면서 새로운 시장이 창출된다.
 

 ICT 운영 요원은 퇴근을 해도, 휴가를 가도 늘 ICT 인프라가 잘 동작하고 있는지 신경을 써야 하는, 24시간 365일 대기 모드로 있어야 하는 직업입니다. AIOps의 도입으로 이 들의 삶도 좀 더 편안해지지 않을까 싶네요.

 

 



AIOps에 대하여 더 궁금하다면? 여기를 눌러 문의해보세요!




기고 | AI사업본부 최영수 이사

편집 | 사업기획팀 박예영

엑기스 | 클라우드 환경에서의 통합 관제

기술이야기/엑.기.스 2019.02.12 10:06




엑셈에서는 클라우드 환경에 대한 모니터링을 지원하기 위해서 클라우드 기반 대규모 통합 관제 솔루션인 InterMax Cloud(가칭) 버전을 2019년 상반기에 출시 예정입니다. 그래서 이번 엑기스에서는 클라우드 환경에서의 App 통합 관제 및 모니터링에 대하여 다루도록 하겠습니다.



▶ 클라우드 향 Application의 특징 및 통합 모니터링이 갖추어야 할 요건


(1) Auto Scale In / Out 구조

 클라우드는 IT인프라를 가상으로 임대하여 자유롭게 사용할 수 있는 환경이므로, 더 많은 Computing Power가 필요할 때 Scale Up으로 장비의 컴퓨팅 Power를 키우는 방식이 아니라, Scale Out으로 가상머신을 늘리는 방식으로 Computing Power를 확장합니다.

또한, 사용자 서비스 부하가 줄어들면 자동으로 Scale In이 되어서 모니터링 대상이 사라지게 됩니다.


모니터링 제품에서 이러한 Scale In/Out을 모니터링 하기 위해서는 모니터링 대상(Target)을 자동으로 등록하고, 제거하는 기능이 지원되어야 합니다. 


(2) Microservice Architecture
 클라우드 환경은 1개의 큰 서버에 여러 개의 업무를 대량으로 처리하는 Monolithic 시스템으로 구성되기 보다는, Microservice Architecture기반으로 구성하는 것을 권장합니다. Microservice는 작은 서비스 모듈 단위를 API를 통해 호출하여 서비스를 제공하는 형태로 전체 업무를 구성하고 있습니다.

 따라서 모니터링 시스템 구성 시 모니터링할 대상이 많고, Python, Java 등 통일되지 않은 다양한 기술로 이루어져 있으며, 한 서비스가 다른 서비스를 호출하는 등 서비스 간 복잡하게 연계되어 있는 점을 고려해야 합니다. 개별 기술로 이루어진 Micorservice를 통합하여 중앙집중화된 모니터링을 제공해야 하며, 또한 성능이슈의 추적을 위해서 서비스 간의 End to End 연계 추적을 고려해야 합니다.


그리고 전체 관점의 모니터링 뷰 제공을 위해서 Topology 형태의 대시보드를 제공하여 전체 서비스를 통합된 뷰로 모니터링 할 수 있어야 하며, 전체 관점에서 Node → Container → App으로 내려가는 Drill Down을 통한 상세 모니터링을 지원해야 합니다.


-  다수의 모니터링 대상을 전체 관점에서 모니터링 하기 위한 Topology View( 2D )


- Topology View ( 3D )


(3) 클라우드 환경의 다양한 관리 솔루션 연동 지원
 클라우드 환경을 제공하는 Amazon AWS, Microsoft Azure 같은 Public Cloud 서비스나, 기업 내부에서 Private Cloud를 구축하여 사용할 때 많이 사용하는 OpenStack, Kubernetes, OpenShift 같은 제품들은 다수의 가상머신과 컨테이너를 관리하기 위한 자체 관리도구를 제공하고 있습니다. 이러한 자체 관리도구와 긴밀히 연동하여, 서버명, 컨테이너명, 그룹명 등을 자동으로 인식하여 모니터링을 제공하는 것이 필수적으로 필요합니다.
 예를 들어, AWS의 경우, EC2 인스턴스ID 뿐 아니라, Tag Name을 수집하여 모니터링 대상 식별에 활용하고, 같은 서비스(업무)를 수행하는 장비를 자동으로 Grouping하여 모니터링 대상 식별이 용이해야 합니다. Grouping 방식은 Region이나 AZ 기반으로 물리적인 위치에 따라서 Grouping하거나, Auto Scaling 그룹 기반 또는, 특정 Tag Name을 가진 서버들을 대상으로 Grouping을 수행할 수 있습니다.
 Kubernetes의 경우, Pod명을 인식하여 모니터링 대상을 식별하고, Application 명 또는 Deployment 명을 인식하여 모니터링 그룹에 자동으로 활용하는 기능을 제공해야 합니다.


(4) 가상환경 자체 모니터링(Kubernetes 컨테이너, AWS 서비스 등)
 클라우드 환경에 대한 모니터링은 가상환경이라는 새로운 Layer에 대한 모니터링이 추가로 제공되어야 합니다. Kubernetes환경의 경우, Pod 또는 컨테이너라는 모니터링 대상이 물리적인 서버(Node)와 Application 사이에 존재하기 때문에 이러한 가상 계층에 대한 모니터링을 지원해야 합니다. AWS의 경우, AWS의 자원(AWS 서비스)인 EC2, S3, EBS, RDS 등의 서비스에 대한 통합 모니터링을 지원해야 합니다. 물론 AWS 자체적으로 CloudWatch라는 모니터링 도구를 제공하고 있으나, 전체 서비스를 Infra와 Biz를 통합 관제하기 위해서는 AWS CloudWatch에서 수집하는 정보를 선별하여 “통합 클라우드 서비스 모니터링 제품”에서 함께 모니터링 되어야 문제 발생 시 신속하게 대처가 가능합니다.

- Kubernetes Pod 및 컨테이너 계층에 대한 모니터링 대시보드


- Kubernetes Pod 상세 모니터링




클라우드 통합 관제에 대한 대응 전략

 앞서 언급하였듯이 엑셈에서는 클라우드 환경에 대한 모니터링을 지원하기 위해서 클라우드 기반 대규모 통합 관제 솔루션인 InterMax Cloud(가칭) 버전을 2019년 상반기에 출시 예정입니다. InterMax Cloud 버전은 Private Cloud 플랫폼(Kubernetes Pod 및 Docker Container 기반) 환경에서 다양한 계층(Hosts, VM, Pod, Container 등)에 대한 구성(Configuration) 정보에서부터 성능 메트릭(Metric) 정보까지 full stack 모니터링이 가능한 통합 관리 솔루션입니다. 또한 AWS 같은 Public Cloud 환경까지 지원을 확대하여 기업 내의 자체 Infra와 클라우드 환경을 통합 관제하고자 하는 Needs에 대응할 예정입니다.



클라우드 기반 통합 관제에 대하여 더 알고싶으신가요? 여기를 눌러 문의해보세요!




기고 | APM본부 오명훈

편집 | 사업기획팀 박예영

엑기스 | OpenJDK 동향

기술이야기/엑.기.스 2019.01.04 10:42




1. OpenJDK란?

OpenJDK는 Java SE(Standard Edition)의 오픈소스 구현체로, Java가 지금의 오라클에 속하기 전인 2006년 썬 마이크로시스템즈 시절에 시작한 프로젝트입니다. 최초 배포 버전은 JDK 6입니다. 2018년 6월 21일 오라클에서 Java SE에 대한 유료 구독 모델을 발표했고, 대안으로 OpenJDK가 급부상하게 되었습니다. 이에 따라 최근 활발하게 연구가 진행되고 있으며, 다양한 버전의 OpenJDK 구현체들이 나오고 있습니다.

 

2. OpenJDK와 OracleJDK의 차이 

OpenJDK가 처음 나왔을 당시에는 OpenJDK가 OracleJDK보다 성능이나 안정성이 크게 떨어졌지만, 최근에 와서는 일부 OracleJDK에만 들어가는 JRockit 관련 코드, JavaFX, 글꼴관련 렌더링 코드, Applet, Java WebStart구현, Java Plugin 등 몇몇 유틸 기능을 제외하면 큰 차이는 없으며, Java 11부터 공개되는 OpenJDK는 Timezone Updater나 Usage Logger 같은 일부 기능을 제외하면 OracleJDK와 동일한 코드로 빌드됩니다.

 

3. OpenJDK 구현체들

아래는 OpenJDK프로젝트의 몇 가지 구현체들입니다. 대부분 LTS에 초점이 맞춰져 있으며 구현체 별로 주로 자주 사용하는 기능이나 GC(Garbage Collection)에 대한 성능을 개선하고 있습니다. 

LTS : Long Term Support, 장기 지원 버전

 

Zulu

Azul Systems에서 빌드하고 있는 OpenJDK LTS를 지원합니다. 추가로 글꼴 렌더링을 위한 Monotype ™ 글꼴이 포함된 Zulu Commercial Compatibility Kit (CCK)와 확장 암호 길이 정책 파일을 포함하는 Zulu Cryptography Extension Kit를 포함한 추가 패키지를 제공합니다. Windows, MacOS, Linux용 빌드를 제공하고 있습니다.

▶ Amazon Corretto

Java의 아버지 제임스 고슬링이 현재 재직하고 있는 Amazon에서 빌드한 OpenJDK 구현체로 LTS를 지원하며, 무료입니다. Java8 버전은 2023년 6월, Java11 버전은 2024년 6월까지 보안업데이트를 제공할 예정이라고 합니다. Amazon Linux 2, Windows, macOS에서 사용 가능합니다.

▶ RedHat OpenJDK

RedHat Enterprise Linux 사용 고객에게 제공하는 OpenJDK로 LTS를 지원합니다. RedHat OpenJDK 11에는 OpenJDK12에 들어갈 예정인 Shenandoah Garbage Collector가 포함되어 있습니다. 이 Garbage Collector는 Full GC가 일어날 경우 발생하는 Stop the world 시간이 매우 적게 발생하도록 개선한 특징이 있습니다. RHEL과 Windows에서 사용이 가능합니다.

※ Full GC(Garbage Collection) : JVM의 메모리가 더 이상 Stop the world를 발생시키지 않는 Young GC로 해결이 안될 때 전체 메모리를 정리하기 위해 발생하는 GC.

※ Stop the world : 전체 메모리를 정리하기 위해 JVM이 모든 동작을 멈추는 상태

▶ AdoptOpenJDK

대부분의 구현체들이 기업에 의해 빌드되는 반면 AdoptOpenJDK는 커뮤니티에 의해 빌드되고 있는 구현체 입니다. 모든 플랫폼에서 신뢰하며 사용할 수 있는 OpenJDK를 목표로 하고 있으며, Azul Systems, IBM, Microsoft 등에서 후원하고 있습니다. 아직 오라클과 TCK 인증을 받기 위한 계약을 맺지 못했지만, 품질에는 문제가 없으며, 오라클과 이 문제에 대해 지속적인 협력을 할 것이라고 합니다.  최소한 Java8 버전은 2023년 9월, Java11 버전은 2022년 9월까지 LTS를 제공할 예정이고, 모든 플랫폼에서의 동작을 지향하는 만큼 OpenJDK 구현체 중 가장 많은 OS를 지원하고 있습니다. Linux, Windows, macOS, Solaris, AIX에서 사용 가능합니다.

※ TCK인증 : Java 기술을 구현한 VM이 규격에 맞게 구현되었는지 검증하는 테스트 프로그램과 도구인 TCK(Technology Compatibility Kit)를 이용해 검증되었다는 표시

▶ GraalVM

대부분의 구현체들이 LTS에 초점이 맞춰져 있는데 반해 GraalVM은 새로운 시도를 하고 있습니다. 고성능 Polyglot VM으로 Java, Scala, Kotlin, Clojure, C, C++, JavaScript, Python, Ruby, R 등의 언어를 지원하며, Native 컴파일을 통한 성능향상 및 메모리효율을 높일 수 있어, 클라우드 및 컨테이너 환경에서의 유용성으로 주목 받고 있습니다. Linux와 macOS에서 사용 가능합니다.  

※ Polyglot : 여러 언어를 사용하는 것

 
4. GraalVM의 특징

2018년 11월 12일부터 16일까지 벨기에에서 열린 Devoxx 2018 행사에서 GraalVM에 Kotlin coroutine을 이용한 SpringBoot 어플리케이션을 Native로 컴파일해서 6ms만에 부팅한 시연이 있었습니다. 이처럼 놀라운 성능을 보여준 GraalVM에는 어떤 특징이 있는지 몇 가지 살펴보겠습니다.

coroutine : non-blocking 작업을 위한 동시성 기법

 

▶ Polyglot

GraalVM은 많은 프로그래밍 언어를 해석할 수 있는 PolyglotVM 입니다. 그렇기 때문에 자체 제공 API를 통해 Java에서 Python 함수를 호출하거나, C에서 Java코드를 호출 하는 등 다양한 언어를 조합해 오버헤드 없이 사용할 수 있어, 기존에 다른 언어를 사용하기 위해 인터페이스나 API 등을 만들어야하는 제약에서 벗어 날 수 있습니다. 지원하는 언어는 Java, Scala, Kotlin, Clojure, C, C++, JavaScript, Python, Ruby, R 등입니다. 

▶ JVM 기반 언어의 Native 컴파일

Java, Scala, Clojure, Kotlin과 같은 JVM 기반 언어를 VM 위에서 동작하지 않고 실제 장비에서 동작할 수 있도록 기계어로 작성된 Native 실행 파일로 미리 컴파일 할 수 있습니다. 생성된 프로그램은 Java VM에서 동작하는 기존 프로그램에 비해 시작 시간이 빨라지고 실행 중에 사용하는 메모리가 줄어듭니다.

▶ 더 빠른 Java 실행

OracleJDK에 포함된 표준 JIT 컴파일러에서는 할 수 없는 부분 탈출 분석과 같은 강력한 최적화 기능을 제공하는 JIT 컴파일러가 포함되어 있습니다. 이 기술로 Java 어플리케이션을 더 빠르게 실행 할 수 있습니다.

JIT 컴파일러 : Just In Time 컴파일러의 약자로, 바이트코드로 컴파일된 Java 클래스 파일을 실행 시점에 기계어로 번역해 주는 컴파일러

▶ Java Code의 Native 라이브러리화

Java 실행 파일을 Native 실행파일로 컴파일 할 수 있기 때문에 C로 개발된 프로그램에서 호출할 수 있는 Native 라이브러리 형태로도 빌드가 가능합니다. 이를 통해 C에서 Java에서 제공하는 수많은 라이브러리들을 사용하게 할 수 있습니다.

 

5. 마치며

오라클의 Java 구독 모델의 변화로 촉발된 OpenJDK 붐으로 기업과 커뮤니티들이 다양하고 많은 시도를 하고 있습니다. 이 현상이 언제까지 지속될지 모르겠지만, 조금은 정체되어 있던 Java 언어 발전에 긍정적인 영향을 미쳐 급변해가는 기술흐름에 빠르게 따라가는 언어가 될 수 있지 않을까 생각합니다.





OpenJDK에 대하여 더 알고싶으신가요? 여기를 눌러 문의해보세요!




기고 | MFJ-Daemon팀 장
편집 | 사업기획팀 박예영


엑기스| 개발자가 바라본 대시보드

기술이야기/엑.기.스 2018.11.05 17:46

 

고객사 전산실을 방문해 보면, 정말 많은 관제용 모니터들이 각각 다른 영역을 최대한 직관적으로 표현하고 있는 대시보드들을 볼 수 있다.


<그림1 맥스게이지 3D 대시보드 화면, 내용과 무관>


 대시보드를 어떤 용도로 사용할까


대시보드 업무를 약 7여년 정도 개발 및 지원을 하면서 개발자 입장에서 느낀 점은 크게 두 가지이다.


1. 장애의 사전징조를 미리 파악하여 장애 방지 목적

2. 장애 발생 후, 원인규명을 위한 사후분석 목적


 위 두 가지 중요한 포인트에 대하여 각 기업의 입장에서 수많은 질문과 구현 가능 여부 등이 대시보드를 만드는 입장에서 상당히 고민스러운 일이 아닐 수가 없다. 

 그렇다면 해당 기업이 대시보드를 장애 관점에서만 활용하는가?에 대한 의문이 생긴다. 최근 2~3년 정도의 대시보드 개발 요건은 발생한 장애를 쉽게 인지할 수 있도록 데이터를 시각화 하는데 초점을 맞추었다면, 최근의 대시보드 기능상의 개발 요건은 아래와 같다.


1. 무수히 많은 모니터링 대상들의 통합관제 및 통합인증

2. 문제 발생시 one-click으로 대시보드에서 각 모니터링 제품으로 바로 접속

3.해당 기업만의 전용 대시보드 화면 필요


 이제는 대시보드가 단순히 수많은 모니터링 타겟을 화면에 보여주는 단순 기능에서 벗어나서, 연결된 제품과 통합 로그인을 구현해야 하고, 쉬운 진입이 가능해야만 한다. 그리고 각 기업의 업무 환경이 서로 다르기 때문에 보는 관점도 다른 만큼 해당 기업만의 전용 대시보드 화면 개발이라는 새로운 숙제가 나타나기 시작했고, 그 빈도는 과거 2~3년 전보다 강하다.



 어떤 대시보드를 만들어야 할까? 


 Touch Switch가 발명된 이유가 우주탐사를 위해서 로켓을 발사하는 경우 수많은 접점형 스위치를 하나하나 켜 가면서 발사 하는 것이 사실상 불가능해서 만들어졌다고 하는데, 동시 다발적으로 기업 시스템에 문제가 발생한다면, 이것 또한 하나하나 해결하는 것이 사실상 불가능할 수 있을 것이다.

 대시보드가 진화하여 현재 상황만을 보여주는 것만이 아니라, 쉽게 터치만으로 장애 상황에 대해 적절한 조치까지 가능해지는 것이 대시보드의 다음 모습이 될 것이라고 생각된다. 이것이 가능해지려면 상황별로 해결할 수 있는 시나리오가 필요할 것이고, 이것이 모이면 대시보드는 위에서 열거한 대시보드의 활용 영역에 상당한 영향력이 될 수 있을 것이다.



 대시보드를 만드는 개발자의 고민 


 대시보드는 각각의 기업환경에 최적화되기 시작하고 있다. 공장에서 찍어내는 제품에 기능을 부여하여 나만의 특화된 제품을 만들어 사용하듯, 점점 대시보드는 기업의 요구에 부합하기 위하여 쉽게 확장 가능하고, 기업 시스템과 연계 시 제약이 없으며, 빠른 시일 내에 소스코드 수정이 가능하도록 개발이 이루어져야 하고, 그렇게 되도록 고민하여 제품이 진화화고 있다.






기고 | 대시보드팀 박정영

편집 | 사업기획팀 박예영

엑기스 | 새로운 시도, Auto ML

기술이야기/엑.기.스 2018.10.01 14:32


인공지능(Artificial intelligence, AI)의 역할 

 오늘날 인공지능(Artificial intelligence, AI)이라는 용어가 학술적, 기술적 측면을 넘어서 이제 다양한 산업과 비즈니스, 실생활에 영역까지 그 범위가 확대되었고, 많은 사람들이 AI 기술에 빠져 열광하고 있다. 즉 4차 산업혁명 시대의 핵심기술이 AI라는 사실은 누구도 부정하지 않을 것이다. L사의 인공지능 플랫폼은 어떻게 우리 일상생활에서 인공지능을 통한 편리함을 제공받을 수 있는지 보여주고 있다. 예를 들면 “하이 공기청정기 켜줘”라고 말하면 IoT 홈네트워크로 연결된 공기청정기가 작동하기 시작한다.

<그림1 L사 인공지능 플랫폼의 예>

출처 LG전자 공식 블로그


 AI(Artificial intelligence)의 개념부터 다시 정의해 보자. 누군가는 “인공지능이란 이거야!“라고 쉽게 정의할 수도 있다. 실제로 어떤 사람들은 공장에 MRP(자재소요계획), ERP(전사적 자원관리) 등과 같은 IT 프로그램이나 솔루션을 전사적 차원으로 일괄적으로 적용했던 것처럼 인공지능 기술도 가능하지 않겠냐고 반문하시는 분도 있다. 또한 데이터 분석이라는 개념과 경험이 없는 상태에서 인공지능이 단순한 컴퓨터 프로그램 개발 영역인 것처럼 인식하는 경우도 많다.

  ERP(전사적 자원관리)와 같이 업무나 공정 프로세스를 처리하는 소프트웨어는 과거의 데이터가 없어도 현재부터 처리되는 결과를 저장해도 업무를 처리하는 데 문제가 없다. 하지만 인공지능 기술과 같은 데이터 분석은 과거의 데이터가 없으면 시작 자체가 불가능하다.

  인공지능 기술이 로봇을 만드는 것이라고 생각하는 사람도 있다. 로봇의 핵심이 인간과 같이 생각하는 지능이라는 점에서 일부 맞지만, 인공지능 기술이 로봇 기술은 아니다. 최근에는 가상 비서 개념으로 일정을 알려주거나, 내게 필요한 날씨, 뉴스, 쇼핑, 영화, 뮤직 등의 정보를 제공해주는 기능까지 인공지능 기술은 일상생활 속으로 더 정밀한 서비스로 진화하고 있다. 그래서 인공지능 기술이 활용 목적에 따라 전문가가 아닌 사람들이 보기에는 그 정의가 혼란스러울 것이다.

 실제 인공지능 기술이 현장에 적용되는 과정을 살펴보면, 사람들이 하던 일들이 인공지능 기술로 대체되고 있다. 센스나 장비, 기기 등의 현 상태를 모니터링하는 단순한 영역부터, 복잡하고 불확실한 미래상황을 추론하는 영역까지 인공지능 기술이 적용되고 있다. 데이터 과학자의 관점에서 기계학습(machine learning)이나 딥러닝(deep learning) 모두 인간의 지능을 대체한다는 점에서 인공지능(Artificial intelligence, AI)이라고 정의할 수 있으며, 궁극적으로 인공지능이란 데이터를 기반으로 학습된 분석모델을 통하여 위험을 줄이고 효율성을 증대하고 비용을 감소하는 목표를 사람 대신 기계의 판단에 맡기는 것이다.

 “인공지능이 왜 필요한 것인가?”라는 질문의 답은 어찌보면 명백하다. 사람 대신 기계가 일을 대신하는 것이다. 예를 들면 은행에서 자금세탁과 같은 범죄를 찾기 위해 얼마나 많은 사람들이 일일이 거래내역을 살펴보아야 하겠는가? 사람들이 수작업으로 많은 시간과 비용을 들여 불법 자금 내역을 찾는 것이 정말 효율적인 작업인가? 은행에서 어떻게 인공지능이 활용되는 지를 살펴보면, 왜 인공지능이 필요한 지 쉽게 이해할 수 있을 것이다. 매년 은행에서는 잠재적인 자금세탁방지(Anti-money laundering, AML)를 위해 탐지, 조사 및 모니터링 등에 수백만 달러의 예산을 투입하고 있다. 금융 규제 당국에서는 부적절하거나 의심스러운 수많은 자금세탁 경우의 수를 수시로 수작업으로 조사할 수는 없다. 결과적으로, 은행에서 잘 설계된 시스템을 통해 이를 걸러서 조사해야 하며, 조사를 통해 자금세탁이 의심되는 사람과 증거를 찾아 금융 규제당국에 보고하면, 금융 규제당국은 의심스러운 사람을 조사하고 자금세탁에 따른 징벌적 세금을 부과할 것이다. 실제 글로벌은행 C사의 경우, 이와 같은 시스템을 구축하여 잠재적인 자금세탁 혐의자를 찾고, 이상 거래를 모니터링하고 있다.

<그림2 C사 자금세탁방지 고객 세분화 모델링 예>


 자금세탁 뿐만 아니라 금융사기로 인한 손실이 매년 증가하여 2017년 기준, 전 세계적으로 금융사기로 인한 손실이 200억 달러에 이른다고 한다. 그럼에도 불구하고 많은 은행들이 다양하고 새로운 형태의 불법을 저지르는 지능화된 조직이나 기업을 고비용의 구식 규칙 기반 금융사기 시스템과 금융사기 방지 솔루션 공급 업체에서 제공하는 블랙박스 모델로 아직까지도 감사(Audit)하고 있다.

 매번 새로운 규칙을 적용하고 변화에 빠르게 대응하기 위해서는 몸값이 높고 능력이 많은 데이터 분석가와 과학자가 필요하다. 모델 갱신의 시간과 물리적인 한계가 있어 학습을 통한 새로운 규칙을 찾고 적용할 수 있는 새로운 접근이 반드시 필요하다. 분석 전문가의 수작업이 아니더라도 효과적이고, 비용측면에서도 효율적인 방법을 찾아야 하는 시점이다.



Auto machine learning(ML)이라는 새로운 시도와 필요성

 새로운 금융사기 패턴과 복잡한 거래 내역 속에서 사람보다 정확하게 불확실한 정보만으로 빠른 추론을 가능한 시스템이 있을까? 새로운 패턴의 정보에 대해 실시간으로 학습하고 모델을 자동으로 갱신할 수 있는 방법은 없을까? 

 최근 Auto Machine Learning(ML)이라는 새로운 개념이 이슈가 되고 있다. 개념을 살펴보면, 데이터 과학자, 머신러닝 전문가가 아닌 분석 전문 지식이 없는 일반 사용자일 지라도 쉽게 머신러닝 분석을 자동으로 생성하고 활용 가능하게 하는 방법이다. 수집·정제된 데이터만 있다면 자동으로 분석 모델을 학습하고 갱신하여 최적의 분석 알고리즘을 추천받아 업무에 적용할 수 있다. Auto ML 서비스는 버튼 클릭만으로 기계 학습 서비스를 제공받으며, 일반사람들이 전문적으로 알고리즘 구현, 데이터 파이프 라인, 코딩 등을 모르더라도 최적의 분석 모델을 생성할 수 있다. 그래서 처음 이런 서비스나 솔루션을 접한 일부 사람들은 ‘만세!’라며 환호하고 이제 분석을 몰라도 되겠다고 말할 수도 있다. 

 그러나 결론만 먼저 말하면 일부는 맞고 일부는 틀리다. 다만 ‘오호’라는 표현이 가장 적절하다고 생각한다. 왜냐하면 Auto ML 서비스가 없는 이전 보다 확실히 시간적, 비용적 측면에서 효과적이고 효율적이기 때문이다. 사람들이 다 검토해야만 했던 모델 최적화를 기계가 대신해준다는 측면에서만 봐도 정말 ‘오호’라는 말로 표현하는 것이 맞다.


대표적인 Auto ML인 데이터로봇의 기능을 살펴보면 다음과 같다.

 ❑ 데이터 사전 처리 → 30여개 기법 중 최적 모델 선택 → 모델 하이퍼 매개 변수 최적화 후 처리 분석 모델 배포

 ❑ 로지스틱, 랜덤포레스트, 서포트벡터머신, Lasso, 베이지안, 신경망 모델 등 30여개의 분석 모델 중 최적 모델 선정

 ❑ 사람이 아닌 기계를 통한 최적화로 모델 구현 공수 70% 감소 효과

<그림3 대표적인 Auto ML 소프트웨어 'DataRobot'>


 기계학습(machine learning) 이나 딥러닝(deep learning) 프로그램 등의 인공지능을 개발하기 위해서는 절대적으로 인공지능 전문가, 데이터 사이언티스트 확보가 필요하다. 그리고 그 중 가장 어려운 부분인 모델을 배포하고, 자동으로 학습하고 갱신하는 자동화 프로세스를 Auto ML 서비스나 솔루션이 있다면 쉽게 분석모델을 시스템에 적용시킬 수 있다. 굉장히 고무적인 일이기에 분명하다. 왜냐하면 분석가나 데이터 과학자의 경우, 분석 모델을 시스템 적용하는 개발 영역을 분석가가 본인이 직접해본 경험이 거의 전무하고, 분석가의 IT지식으로는 개발자의 역할을 대신할 수 없기 때문이다.

 앞으로는 전체 분석 프로세스의 범위에서 보다 중요하고 집중적인 부분에서 전문 분석가와 데이터 사이언티스트의 역할이 강조될 것이다. 버튼 클릭을 하더라도 원리와 개념을 이해하지 못하는 사람이 한다면, 잘못된 부분을 나중에 판단할 수 있겠는가? 누구도 보장할 수 없다. 그래서 Auto ML 서비스가 있다고 해서 인공지능 전문가, 데이터 사이언티스트가 필요 없다고 단정 지어서는 안 된다. 여기서 접근을 잘해야 하는데, Auto ML 솔루션이나 서비스가 부족한 인공지능 전문가의 수요를 어느 정도 충족시키면서, 잠재적인 머신러닝 개발자의 수를 늘리는 효과를 낼 수 있다는 가능성에 무게를 더 실어주는 것이 맞다고 생각한다. 왜냐하면 전문가는 비록 아니지만, 서비스나 솔루션을 활용하면서 분석의 이해와 원리를 학습함으로써 데이터만 마련한다면 실제 업무에 분석모델을 적용할 수 있기 때문이다. 


 현재 구글과 아마존, 마이크로소프트에서 클라우드에 Auto machine learning(ML) 서비스를 확대하고 위해 지속적인 아키텍처 연구과 테스트가 진행 중이며, 앞으로 많은 기업과 사람들이 인공지능 활용에 적합하지 않다고 여겼던 분야에서 Auto machine learning(ML)을 통해 새로운 비즈니스와 가치 창출을 위해 시도하게 될 것이라고 예상된다. 앞으로 더 인공지능은 빠른 속도로 일상 속 깊숙이 자리 잡게 될 것이다. 머신러닝 모델과 알고리즘을 통해 새로운 비즈니스 가치를 창출하고, 우리 삶이 더욱 편해지는 날이 멀지 않은 것 같다. 




기고 | 빅데이터사업본부 조치선

편집 | 사업기획팀 박예영

엑기스 | 쉽게 이해하는 시계열데이터 비정상탐지

기술이야기/엑.기.스 2018.09.05 13:29


"엑기스"라는 단어, 어떤 느낌이신가요?

무언가 알차게 꽉- 농축되어 있는 그 느낌!

지금부터 엑셈의 기술 스토리, 엑기스를 알차게 전해드립니다!

엑기스 첫 번째 스토리, 지금 시작합니다.


불과 1개월 전만해도 111년만에 한국 사상 최고의 더위가 찾아왔었다.

Figure 1. 정말 너무 더웠다...

<출처 | YTN NEWS(http://www.ytn.co.kr/)>


현재 낮기온은 1개월 전보다 섭씨 10도씨 이상 낮아지고 일교차는 크게는 15도정도 난다.

이런 비정상'스러운' 날씨를 어떻게 발견할 수 있을까? 미리 예측은 할 수 있을까?

웹 어플리케이션을 운영하는데 디도스(DDOS) 공격이 온 것을 빠르게 알아낼 수 있을까?


시계열 데이터


위에 언급한 문제들을 풀기 위한 답은 '데이터'에 있다. 날씨의 경우에는 우리나라의 역사적으로 기록된 기온과 주변 국가, 지구의 기온 변화 등이 모두 데이터로 사용될 수 있다.

또한 DDOS 공격으로부터의 빠른 탐지는 '기존 데이터'를 잘 분석한다면 비정상 움직임을 캐치할 수 있을 것이다. 이처럼 매력적인 시계열 데이터에 대해서 조금 더 알아보자.


시계열 데이터를 다루는 사람들의 관심 있는 주제는 보통 크게 2가지이다.


1.데이터 예측

2.비정상데이터 탐지


오늘 이 글에서 얘기하고자 하는 것은 1번 예측이 아닌 2번 비정상데이터 탐지이다.


비정상데이터


Figure 2 비정상회담과 비정상탐지는 아무 관련이 없고 이 글은 상사가 시킨 글쓰기가 아니다.

<출처 | JTBC 비정상회담 화면 캡쳐(http://tv.jtbc.joins.com/nonsummit)>


시계열 데이터에서 비정상이라고 하면 뭘까? 일반적인 비정상에 대해서 사전을 통해 알아보도록 하자. 

네이x 사전에 의하면 비정상의 사전적 의미는 '정상이 아님'이라고 정의한다.

그렇다면 정상 또 정상이 뭔지 찾아보도록 하자.

Figure 3 정상의 정의

<출처 | 네이버 국어사전(https://ko.dict.naver.com/search.nhn?query=%EC%A0%95%EC%83%81&kind=all)>


그렇다. 우리가 직관적으로 예상할 수 있는 대로 탈 없는 상태이다. 

결국 비정상 데이터라고 하면 '탈이 있는 데이터'이고 우리는 이를 잘 탐지하기만 하면 된다.


흔히 비정상 데이터를 다음의 3가지 경우로 분류한다.


1.평소보다 데이터가 심하게 크거나 작을 경우

2.일시적인 데이터의 패턴 변경

3.데이터의 크기 변경


대부분의 비정상 데이터들은 위의 3가지 분류에 속하게 된다.


어떤 데이터로


데이터분석은 같은 데이터의 모양이라고 하더라도 도메인에 따라서 접근법이 많이 다를 수 있다. 

결국 고객이 무엇을 원하는지 요구사항을 잘 파악하여야 문제를 잘 정의하고 이에 따른 분석방법, 해결책이 나올 수 있다.


필자의 의견인데 좋은 알고리즘과 모델을 찾는 것보다 요구사항을 분석하고 문제를 정의하는 과정이 제일 중요하다고 생각한다.

온천수가 나오는 땅을 찾기 위해 삽질을 해야하는데 이를 은삽으로 팔지, 금삽으로 팔지, 모종삽으로 팔지, 혹은 포크레인 기사를 불러서 땅을 파야할 지 고민하기 전에 우리 집 마당인지 뒷 산인지, 이 땅의 성분 요소는 무엇인지 잘 아는 것이 더 중요하다. 아무리 좋은 삽을 고르더라도 남의 땅을 파면 안되는 것 아닌가?


이 글에서는 서버 위에 가상 쇼핑몰을 만들고 부하를 만들어서 얻어낸 데이터베이스의 Active session data를 가지고 여러가지 시도를 해보도록 하겠다.


가장 쉬운 접근 방법


STL decomposition

STL Decomposition은 시계열 데이터를 Seasonal, Trend and residual로 분해하여 분석하는 알고리즘이다.

Figure 4 Y(t) = S(t) + T(t) + R(t)


STL은 트렌드를 찾아내는 곳에서도 사용될 수 있지만 Residual Graph를 잘 보면 비정상포인트를 찾을 수 있다. 

python에 STL library들이 많기 때문에 구현이 쉽고 데이터의 특성을 확인하기 편하다.


장점

장기적 데이터에서 뚜렷한 주기, 트렌드를 구분 짓고 구현이 쉽다.

단점

데이터가 많이 출렁이거나 등락이 강할 경우에 트렌드함을 가지지 못해 분석 결과를 결론 짓기 애매한 경우가 많다.


Classification and Regression Trees

필자도 학습자이기에 Anomaly detection in time series 이런 식으로 구글링을 해보면, 자주 나오는 것이 CART(Classification and Regression Trees)이다.

정상과 비정상데이터가 레이블링(Labeling)이 되어있는 데이터를 가지고 있을 때 사용할 수 있다. 

최근 캐글(Kaggle)을 통해서 핫해진 xgboost의 경우도 CART의 진보된 버전이다.

Figure 5 CART의 시작


장점

Supervised learning이므로 다른 알고리즘보다 한단계 더 직관적 결과를 얻을 수 있다.

단점

Labeling data가 없으면 분석이 불가능하다.


Moving Average

Moving Average(a.k.a 이동평균선)은 데이터의 추세를 볼 수 있는 가장 고전적이고 쉬운 방법이다. 

간단하게 앞선 특정 기간의 데이터값의 평균값을 데이터로 하여 전 구간의 평균값을 구하는 것이다.

이동평균선을 구하고 각 지점에서의 표준편차값을 이용해 신뢰구간을 그린 다음에 실제 데이터들이 이 신뢰구간을 벗어났다면 비정상이라고 판단할 수 있다.


(빨간 동그라미) 이동평균선을 통해 비정상탐지를 할 때 가장 중요한 점은 '어느 기간의 이동평균'을 잡느냐가 중요하다. 

데이터의 성격에 따라 달라지니 반복된 수행을 통해 최적의 윈도우 사이즈를 찾아야한다.

Figure 6 이동평균선을 이용한 비정상탐지 - 빨간 원


장점

계산이 빠르고 직관적이고 어느 데이터에서든 사용이 가능하다.

단점

많은 테스트가 필요하고 사용자의 경험치가 중요하다. (윈도우 사이즈 결정 시) 추가적으로 비정상 케이스 1번의 경우에만 잘 맞는 경향이 있다.


Prophet

페이스북에서 만든 비정상탐지 알고리즘이다. 이 알고리즘의 가장 큰 장점은 사용하기 쉽다는 점이다. 그 이상은 없는 것 같다.

아주 예쁜 데이터의 경우 잘 들어 맞지만 예측 커브를 아주 예쁘게 그리는 바람에 진폭이 큰 데이터의 경우 정확도가 떨어지는 경향이 많다.


아래 그림에서 보면 회색 밴드를 벗어난 붉은 원으로 표시된 곳이 비정상으로 벗어난 곳이라고 할 수 있다.

Figure 7 Prophet library를 이용한 비정상탐지

장점

구현이 쉽고 Daily, Weekly, Montly 등 장기적 데이터에 적합하다.

단점

Library에 종속되어서 데이터에 따른 디테일한 변경이 쉽지 않다.


조금 더 심도있게


Clustering

K-means Clustering을 이용하여 비정상탐지를 할 수도 있다. 

이 때 주요 개념으로 rolling(혹은 moving) window를 이용하여 클러스터링을 위한 데이터셋을 만들고 이를 K-means를 이용하여 모델을 학습한다.


그리고 새로운 데이터(혹은 기존 데이터)를 분석하여 기존에 가지고 있던 클러스터(군집)에 분류시켜 이상치를 벗어난 데이터들을 발견해낸다.

Figure 8 Clustering을 이용한 비정상탐지


장점

데이터의 크기와 패턴을 고려해 비정상탐지를 하여 비정상 포인트를 포함한 구간을 찾는데 유용하다.

단점

메모리 사용량이 꽤 많고 정확한 지점을 찾기 힘들다.


Neural Networks - LSTM

좋은 연구 과제이다. 정확도 높은 네트워크를 찾는다면 이보다 좋은 모델은 없을 것이다. 

LSTM은 특히 NN에서 time을 고려한 모델인만큼 데이터의 성격에 따라 효과가 클 것이라고 생각한다.


하지만 이 분야는 계속 연구 중이고 데이터 의존성이 크기 때문에 많은 시도와 모델 튜닝이 필요하다.

Figure 9 여러분의 과거 데이터를 봤을 때 새벽 1시에 치킨을 먹는 것은 정상입니다. ???


그래서 뭐가 좋은지?


그래서 어떤 알고리즘을 써야 하는지 알고 싶으면? 정답은 데바데(데이터 바이 데이터, Data by Data). 


그럼 어떤 데이터의 경우 가장 맞는 알고리즘인지 알려면? 

가장 쉬운 알고리즘부터 하나씩 적용해보면서 좋은 결과가 나오는 알고리즘을 택하는 것이다. 


글의 서두에 말한 데이터베이스의 active session 수를 파악하는 데에는 단기적으로는 Moving average가, 장기적으로는 Prophet이 적용가능한 범주에 있었고 결과 또한 좋았던 것 같다.

이래나 저래나 비정상이라고 탐지한 것들이 정확성을 체크하기 위해서는 그 역으로 판단을 해봐야한다. 

메모리 사용에 제한이 없는 report 하기 위한 데이터분석 과정이라면 여러 알고리즘을 사용해서 중복된 포인트들을 찾는 것도 나름의 방법이다.




(급)마무리


시계열 데이터로 미래 예측, 비정상탐지, 인과관계 분석 등을 팀에서 연구하고 있다. 비정상탐지의 경우에는 Moving average를 기반으로 단기적 변화에 대해서 탐지하고 있고 Prophet library에서 아이디어를 발전 시켜서 장기적 비정상을 탐지하고 있다.

우리가 잘 해결한 부분도 있고 부족한 부분도 있지만 문제 해결을 함께 해 나감에 있어 도메인 지식이 있는 동료들과 분석에 함께 아이디어를 내주는 동료들의 도움이 큰 것 같다.

추가로, 비정상탐지 후에 다음 단계가 인과관계 분석, 근본원인 분석인데 서비스 개발이 완료된 후에 공유하도록 하겠다.






기고 | 강남연구소 김정우

편집 | 사업기획팀 박예영


플라밍고 | 빅데이터 성능관리 솔루션, 플라밍고

기술이야기/엑.기.스 2018.08.09 10:20



다양한 빅데이터 분석 환경에서 시스템 운영자 및 분석가는 시스템 성능 관리에 큰 어려움을 겪고 있습니다.

서버 중단 시 인지하기 조차 힘든 Scale Out 및 HA 특성을 가진 빅데이터 분석 환경을 보다 투명하게 관리할 수 있는 통합된 솔루션이 필요하죠. 

바로 엑셈의 Flamingo 입니다! 

빅데이터 성능 관리 솔루션 플라밍고가 업데이트 되었다고 하는데요, 함께 알아봅시다 :)



1. 제품 개요

Flamingo는 빅데이터 플랫폼인 하둡 클러스터의 통합 관리 솔루션으로, 하둡과 에코 시스템의 실시간 서비스 감시 및 주요 성능 지표의 수집, 진단 및 모니터링, 데이터 처리를 위한 워크플로우  작성, 데이터 분석 지원까지 이르는 하둡 시스템의 가용성 및 성능의 관리를 효율적으로 수행할 수 있도록 지원합니다.



2. 제품 특징
2.1 Realtime Monitoring
- Hadoop과 EcoSystem에 최적화된 다양한 성능 지표의 실시간 감시
- 지원 Hadoop Ecosystems
 (1) Hadoop Core Server 
 (2) Apache Spark
 (3) Apache Hive
 (4) HDFS
 (5) Apache Oozie
 (6) Zookeeper
 (7) HBase
 (8) Cluster Servers

2.2 Workflow
- 작성하기 어려운 워크플로우를 간단히 작성하고 손쉽게 테스트할 수 있는 환경 지원
- workflow지원 형식
 (1) Workflow (Designer & Monitoring)
 (2) Apache Oozie workflow (Designer & Manager & Monitoring)

2.3 Data Analysis
- 다양한 빅데이터 환경에서 필요한 정보 도출을 위한 분석 환경 지원
- 지원 방식
 (1) Notebook(R/python 등)
 (2) Hive, HBase Editor
 (3) R-Studio 연계 지원

2.4 Security
- 설정하기 어려운 Hadoop과 Ecosystems의 보안 및 권한레벨까지의 설정까지 쉽게 할 수 있도록 지원
- 지원 Ecosystems 
 (1) HBase
 (2) Hive
 (3) Kafka
 (4) Solr
 (5) NiFi
 (6) Yarn
 (7) HDFS



3. 제품 스펙


구분

내용

비고

OS

Linux Kernel 2.6 이상

CentOS 6 이상

Database

PostgreSQL 9.2 이상

UTF-8 Character Set
Oozie
모니터링은 현재 PostgreSQL만 지원

CPU

8Core 이상

Memory

16G 이상

Java

JDK 1.8 이상

Hortonworks HDP

Hortonworks HDP 2.4 이상

상세 기능 지원 여부는 확인 필요

Cloudera CDH

Cloudera CDH 5.4 이상

상세 기능 지원 여부는 확인 필요

Apache Hadoop

Apache Hadoop 2.3 이상

Web Browser

Internet Explorer 10+, Google Chrome, Safari, Firefox

Chrome 사용을 권장함

제품 권장 해상도

1440 X 900 이상

기타

Jupyter notebookSSL 기능 사용을 위해서는 URL
도메인 및 유료 인증서를 확보한 사이트만 적용 가능

URL 도메인 및 유료 인증서를 확보하지 못한
사이트에서는 HTTP 방식으로만 세팅 가능



4. 업데이트 내용

4.1 Apache oozie 지원 기능 향상

- Apache ecosystem 중 workflow scheduler system인 oozie를 손쉽게 사용할 수 있는 기능 대거 추가

- oozie workflow designer : oozie의 workflow를 GUI 기반으로 손쉽게 만들고 테스트 할 수 있는 디자이너 기능


- oozie coordinator designer : oozie의 coordiantor를 GUI 기반으로 손쉽게 만들고 테스트 할 수 있는 디자이너 기능


- oozie bundle manager : oozie의 bundle을 GUI 기반으로 손쉽게 만들고 테스트 할 수 있는 관리자 기능



4.2 Security 기능 추가

- Hadoop과 Ecosystem들의 보안을 손쉽게 설정하고 권한 레벨까지 설정할 수 있는 기능 추가 (Ranger 기반)

- 지원 Ecosystems 

(1) HBase

(2) Hive

(3) Kafka

(4) Solr

(5) NiFi

(6) Yarn

(7) HDFS


<policy 관리 화면>


<audit 화면>


<보안 관련 세팅 화면>



앞으로도 계속 발전해 나갈 Flamingo 많은 기대와 응원 부탁드립니다.^^

플라밍고 파이팅 :)




기고 | 빅데이터개발팀 한현우

편집 | 사업기획팀 박예영