태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

척척박사 윤박사가 들려주는 AI| 두 번째, 인공지능의 역사와 비하인드 스토리

 

 

인공지능이라는 개념을 최초로 만들어낸 마빈 리 민스키(Marvin Lee Minsky) 교수는 “인간의 뇌는 다양한 능력을 기반으로 하는 상호작용 요소들의 결합체“를 주장하면서 그의 제자들에게도 그 기능을 강조하였다. 그와 함께 인공지능의 발판을 만든 존 매카시(John McCarthy)는 1956년 다트머스 학회에서 처음으로 ”인공지능(Artificial Intelligence)“이라는 용어를 창안했고, LISP 라는 프로그래밍 언어를 설계하고 구현하였다. 두 거장을 중심으로 MIT에서 인공지능 프로젝트가 시작되었고, 대표적인 제자로는 구글의 레이 커즈와일(Ray Kurzweil)이 있다. 그는 인간의 두뇌와 자연스럽게 하나가 될 것이라는 사이보그 이론을 주장하였다. 관심 있는 연구 분야로 나노로봇, DNA 컴퓨팅, 양자 컴퓨팅, 뇌공학 등의 인공지능 기술을 함께 연구하였다. 그는 인공지능이 인간의 진화와 마찬가지로 복잡한 패턴과 창의적이고 더 고등한 감정들을 표현하는 능력을 강조하였다. 재미있는 사실은 이들은 심리학과 철학 같은 인문학에도 높은 관심을 가지고 있었다.

 

 

 

하지만 이들의 활동에도 인공지능은 1970년대와 1990년대 두 번의 침체기가 있었다. 초기에는 컴퓨팅 기술의 발전으로 극복하였고, 두 번째는 게임 산업과 유비쿼터스 컴퓨팅을 통해 부활하였다. 첫 번째 침체기라 불리우는 1970년대에는 인공지능이 가진 진보적 성향에 대한 대중의 반감과 두려움이 있었다. 특히 “2001년 스페이스 오딧세이”라는 영화에서 보여준 인공지능 시스템은 대중에게 인공지능의 두려움을 보여주기 충분하였다. 인공지능 연구자들은 HAL 9000과 같은 역할의 인공지능 시스템을 만들려는 의지를 가지고 있었다. 하지만 민스키 교수는 오히려 역으로 “왜 우리는 2001년 HAL을 얻지 못했나?” 라는 질문으로 던짐으로써 인공지능이 가진 진보의 방향을 경계하도록 주문하였다. 이는 인공지능 시스템의 방향이 인간윤리를 넘어선 잘못된 방향성을 경계하고, 윤리와 목적성을 명확하게 하는 계기가 되었다.

 

[이미지 출처: laughingsquid.com, reddit.com]

 

 

그리고, 1990년대는 미국에서 인공지능 연구지원이 삭감되면서 많은 인공지능 연구자들이 기계학습(머신러닝), 로봇공학, 컴퓨터 비전 등 구체적인 하위 영역으로 이동하면서 제한적인 연구에 집중하였다. 이 과정에서 인공지능은 침체기를 보이는 듯 했지만 우리의 일상생활에 알게 모르게 조금씩 다가왔고 편리한 기능을 제공하고 있었다. 예를 들면, 세탁기의 퍼지 기능, 냉장고의 스마트 점검, 자동차의 자동 주차나 주행, 카메라의 손떨림 방지 기능, 다촛점 인식, 헬스케어, 스마트 서비스 등과 같은 자동화된 생활형 서비스가 대표적이다.

 

 

 

[이미지 출처: MOTORGRAPH, 녹십자 헬스케어 '워커+디', 미스핏 '샤인'과 조본의 '조본업'(이미지 좌측 상단부터 시계방향 순)] 

 

 

이처럼 두 번의 침체기를 통해 인공지능은 작은 기술과 기능으로 개발되었으며, 현재는 이것들을 연결하고 통합하는 과정을 진행하고 있다. 그러면서 인공지능의 진보적 성향을 점검하고 다듬는 도덕적 역할도 함께 진행하고 있다. 꿈이 현실로 이루어지기 위해 인공지능 연구자들은 각자의 분야에서 기술을 연구하고 이론과 현실의 간격을 조금씩 메우고 있다. 또한 공상과학이라는 테마를 중심으로 미래로의 발전을 지속적으로 이어가고 있다. 필자는 재미있는 인공지능을 이해하고 싶다면, 2001년 스페이스 오딧세이와 함께 메트릭스와 마이너리 리포트라는 영화를 먼저 권하고 싶다. 로봇이 나오고 우주를 돌아다니는 인공지능 기술도 재미있지만, 인공지능이 가진 진보적 경계에 대해서 많은 부분을 함께 고민하고 이해할 수 있는 영화이기 때문이다.

 

다음 시간에는 왓슨의 도전과 시사점이라는 주제로 인공지능이 가진 인간의 언어 처리 방법과 인공지능 플랫폼 설계에 대해 다루고자 한다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

저작자 표시
신고
  • 2월에는 2017.02.22 09:48 신고 ADDR 수정/삭제 답글

    지속해서 인공지능에 대한 여러 이야기 담아주세요~~

척척박사 윤박사가 들려주는 AI| 첫 번째, 인공지능의 현재와 미래

 


최근에 IBM의 왓슨(Waston)과 Google의 알파고(AlphaGO)가 등장하면서 서비스 기술과 산업 활용의 측면에서 인공지능에 대한 관심이 급격히 증가하고 있다. 또한 4차 산업 혁명에서 자동화와의 연결성이 강조되면서 산업 환경의 변화를 주도적으로 수행하는 기술 분야로 인공지능의 역할이 강조되고 있다. 이러한 인공지능 기술은 다양한 분야에서 자동화를 주도하고 있다. 특히 기계는 단순한 움직임에서 벗어나 사람과 같은 지능, 생각, 행동을 수행하는 기계학습 분야를 중심으로 발전하고 있다. 기계학습은 문제를 해결하기 위해 정해진 일련의 절차인 알고리즘(Algorithm)으로 인간과 유사하게 컴퓨터 프로그램으로 구현된 딥러닝(Deep Learning)을 중심으로 확대되고 있다.

 

 

인공지능은 몇 년 전까지만 해도 게임 및 시뮬레이션과 같은 산업분야에서 사람이나 동물 등을 모방하는 동작 처리와 전자상거래에서 서비스 또는 물품 추천을 중심으로 발전하였다. 하지만 게임분야에서 대용량의 3차원 데이터와 영상 처리가 증가하면서 사람 또는 동물의 동작을 모방하여 처리하는데 한계에 이르렀다. 특히, 바둑과 같은 최적의 경로 추적 게임에서 이용자의 다양한 행위에 대한 경우의 수를 실시간으로 학습하고 처리하는 기계학습의 빠른 연산이 필요하였다. 그리고 서비스 추천에서도 다량의 데이터가 수집되고, 사용자의 다변화된 상품 구매 패턴을 학습시키기 위한 대용량 데이터 처리가 문제로 등장하였다. 이러한 상황에서 인공지능은 또 한 번의 침체기를 가지는 듯 했지만, 자연스러운 학습과 최적의 경로를 결정하는 알파고가 등장하면서 딥러닝이 기계학습의 새로운 디딤돌로 등장하게 되었다. 또한 대용량의 데이터 분석 한계성과 반복적인 처리가 많은 사람이나 동물의 동작의 처리에서도 빠른 인지와 자연스러움을 시도하는 수준으로 적용이 가능하게 되었다. 이렇듯 인공지능이 다양한 산업 분야로 적용될 수 있는 환경은 대용량 데이터를 실시간으로 처리하는 빅데이터 기술과 인프라의 자율성이 높은 클라우드 기술이 함께 적용되었기 때문이다.

 

이제 인공지능의 다음 목표는 다양한 산업분야로 확대해 고성능의 분석 기능을 가지고 자기 복제(Self-Organization)가 가능한 전문가 수준의 지능 서비스로 발전시키는 것이다. 또한 자연계에 대한 복잡도를 학습하는 알고리즘과 신경계 알고리즘이 결합되어 자기 복제와 다차원 연산이 강화된 인공지능 학습 모델로 재구성함으로써 산업분야별 최적의 인공지능 모델로 발전하는 것을 목표로 해야 한다. 그리고 여기에는 미래에 인간의 생활을 보조하는 수준에서의 올바른 역할과 제어 기능이 반드시 포함되어야 할 것이다. 인간을 능가하는 지능을 지닌 인공지능이 존재하는 시대가 빠르게 다가오겠지만 인간이 지닌 사랑, 우정, 연민, 공감과 같은 감정의 특이점을 학습시키는 미래 사회의 도덕률 관점에서는 조심스러운 접근과 반영이 필요하다.

 

이후에는 인공지능이 태어나고 성장하면서 다루어진 비하인드 스토리를 시작으로, 산업분야별 인공지능이 적용된 사례와 함께 인공지능의 중심 기술과 발전 방향을 다루고자 한다.

 

 

 

 

 

 

저작자 표시
신고
  • orion 2017.01.25 10:02 신고 ADDR 수정/삭제 답글

    척척박사님의 활약이 기대됩니다!^^

  • 새초롬하게 2017.01.26 10:58 신고 ADDR 수정/삭제 답글

    윤부장님!! 지적인 카리스마 최고~ 세미나 하실 때 꼭 챙겨듣습니다~~

박재호의 IT 이야기| 소프트웨어 개발과 창의력 vol.1 창의력의 본질

 

 

 

 

 

소프트웨어 개발에 창의력이 필요하다는 가정은 거부하기 어려울 것이다. 한번 설계가 끝나고 대량 생산에 들어가는 하드웨어와는 달리 소프트웨어는 요구 사항이 계속해서 변경되는 경향이 있으며 이를 충족하기 위해 사고의 전환이 필요하다. 따라서 소프트웨어 개발을 창의력과 연결시키려는 시도는 자연스럽다. 하지만, 창의력이 무엇인지에 대해 충분히 고민하지 않은 상태에서 무조건적인 자유와 신기술을 소프트웨어 개발의 핵심으로 놓기에는 미심쩍은 구석이 있다. 오늘은 소프트웨어와 연결된 창의력의 본질에 대해 탐험해보자.

 

위키피디아에 따르면 창의력은 독창적이고 가치가 있는 뭔가를 만들어내는 작업과 관련이 있으며, 다음과 같은 특성을 보인다.

 

“문제, 결함, 지식 사이의 간극, 빠진 구성 요소, 부조화 등에 촉각을 곤두 세우며, 어려움을 파악하고, 해법을 찾고, 생각하고, 결함에 대해 가설을 세우고 이런 가설을 다시 실험하고 가능한 경우 변경하고 다시 테스트하는 과정을 거쳐 최종적으로 결과를 알리는 과정이다.”

 

백지에서 출발해 전혀 없는 새로운 물건/사상/개념을 만들어 낸다는 일반적인 상식과 달리 창의력의 특성은 흔히 과학에서 사용하는 ‘가설, 실험, 검증’ 또는 ‘문제 풀이’와 유사하다. 소프트웨어 개발의 목표 중 하나가 바로 고객의 문제 해결이라는 사실을 떠올려보면 연결고리를 찾아낼 수 있다. 따라서, 문제 풀이를 쉽게 만들어주는 여러 가지 프로세스와 도구는 가설, 실험, 검증, 문제 풀이를 위한 수단이며 이를 체계적으로 다룰 수 있는 사람만이 창의력을 발휘할 수 있게 된다. 하지만 창의력을 발휘하기 위해 이렇게 체계적으로 접근해야 한다면 자유를 제한하므로 새로운 뭔가를 추구하는 창의력의 본질이 훼손될지 모른다는 걱정이 들기 시작할 것이다. 설상가상으로 다음과 같은 더 큰 문제가 하나 존재한다.

 

1. 창의력은 기존에 없는 새로운 뭔가를 만들어야 한다.
2. 새로움을 추구하기 위해서는 기존에 존재하는 사항에 대해 잘 알고 있어야 한다.

 

 

1번과 2번의 충돌 또는 모순은 창의력을 발휘하려면 완전한 무에서 시작하는 대신에 어느 정도 기반을 다진 결여의 무에서 시작해야 한다는 사실을 암시한다. 이는 독창성을 강조하는 창의력에 대한 본질을 다시 한번 고민하게 만든다.

 

그렇다면 이런 모순을 어떻게 해소해야 할까? 자니 그로엔이 1990년에 발표한 논문인 ‘호기심이라는 규율’에 제시한 설명을 소개한다.

 

“과학은 단순한 호기심과 창의력이 아니다. 호기심과 창의력을 통제한 형태가 과학이다. … 과학적인 진보를 끌어내는 원동력은 호기심과 규율이라는 기묘한 단짝이다. 끊임없이 ‘왜?’와 ‘어떻게?’를 묻는 호기심과, 과학을 현실로 묶어주는 체계 말이다.”

 

소프트웨어 부문에서도 마찬가지일 것이다. 무조건적인 방법론과 엄격한 관리 체계가 해답은 아니지만 창의력을 빙자한 무질서 역시 해답은 아니다. 소프트웨어 공학도라면 누구나 과학적인 사고 방식으로 고객의 어려움을 해결하기 위한 문제 풀이에 집중해야 마땅하며, 이런 과정에서 사물에 대한 크나큰 호기심과 과거 경험을 토대로 정립된 규율이라는 단짝을 함께 포용해야 한다.

 

하지만 주의 사항이 하나 있다. 여기서 말하는 규율은 상명하복을 무조건적으로 따르는 중앙집중적인 통제가 아니라 개발자들의 자발적인 관리 체계에 가깝다는 사실을 짚고 넘어가겠다. 특히 두뇌 활동을 기반으로 움직이는 조직에서는 자율과 규율이 조화를 이뤄야 제대로 된 ‘창의력’이 발현될 것이다.

 

창의력이 그렇게 쉬운 단어가 아님을 인식했는가? 다음에는 조금 더 구체화해 소프트웨어 설계 과정에서 발현되는 창의력에 대해 살펴보기로 하겠다.

 

 

 

 

 

저작자 표시
신고
  • 지나가다 2016.02.24 13:15 신고 ADDR 수정/삭제 답글

    박상무님의 문필력은 정말 대단하세요~!! 엑셈에서 박상무님의 글 자주 봤으면 좋겠습니다.

  • 나우리너 2016.03.04 13:17 신고 ADDR 수정/삭제 답글

    많은 생각을 하게 합니다.내용 너무 좋습니다.

  • 와룡선생님 2017.02.22 12:30 신고 ADDR 수정/삭제 답글

    창의력을 갈구하는 제게 큰 교훈이 되어 감사의 말씀 올립니다.
    글을 다 읽고 느낀점이라곤 무엇보다도 이러한 글들을 많이 읽고 싶다는 욕구가 강해 졌다는점 입니다.
    앞으로 많은 기고 간절히 부탁드립니다.

[기술기고/인터맥스] 트랜잭션 관리 " Comprehensive visibility of transaction! "

 


# 트랜잭션 관리란?

프로파일링과 call tree에 이어 이번에는 트랜잭션 관리에 대해서 알아 보고자 한다. 트랜잭션 이란 하나의 완결된 요청 처리로서 사용자의 처리요청이 여러 구성요소 및 절차를 거쳐 완료 되는 것이다. 절차 및 구성요소에 대해서 모두 처리 되거나 모두 안되거나 두 가지 경우 밖에는 없다.

일반적으로 시장에 나와 있는 APM툴은 트랜잭션 관리와 관련해서 세가지 정도로 구분 해 볼 수 있다. 트랜잭션에 대해서 WAS쪽에서의 처리만을 관리 하는 툴, 데이터 베이스 처리 상황을 보여 주는 툴, 그리고 WAS와 DB를 동시에 관리하지만 트랜잭션을 보는 시야(visibility)가 단절된 상태로 보여주는 툴들로 구분 할 수 있을 것 같다.

트랜잭션이란 관점에서 보면 WAS와 데이터베이스를 모두 거치는 한 개 단위이므로 APM툴은 트랜잭션이 흘러 가는 구간을 전부 관리 할 수 있어야 한다. 좀 더 구체적으로 보면 HTTP Request, servlet processing, database call 이 주요 트랜잭션 구성 단계로 만일 이런 요소들이 개별 모니터링 된다면 문제 분석 시에 추가적인 노력이 더 필요하게 될 수 밖에 없다.

연구 자료에 의하면 성능문제 해결을 위해서 소요되는 시간의 약80%가 문제지점을 파악하는 데 사용된다고 한다. 그렇다면 툴은 이 시간을 줄일 수 있도록 관련 정보를 즉시 제공 할 수 있어야 한다.



 


<Flow of Transaction>



# 트랜잭션 관리를 위해서는 어떤 정보가 필요할까?

일반적인 경우 was에서 실행 되는 servlet에서는 1개 이상의 database call이 있다. 즉 사용자 요청에 의해서 실행 되는 servlet과 여기에서 요청 하는 database call이 하나의 트랜잭션으로 보여 지는 것이 기본적으로 필요하다.
사용자 요청(트랜잭션이름) + 실행중인 class method + 데이터 베이스 요청(sql실행) + target database + database의 sql 실행 상태, 이런 정보가 항상 동시에 보여 질 수 있어야 detection, alerting, correction의 관리 작업을 원활하게 할 수 있지 않을까 한다.

이런 정보를 바탕으로 관리요소가 was에 있을 경우 was에서 수집된 프로파일데이타,call tree를 활용한 분석으로 진행 되고 데이터베이스에 있을 경우 수집된 세션, sql, 각종 통계정보를 바탕으로 sql 튜닝 등을 진행 해야 한다.

수집되는 정보들은 기본적으로
트랜잭션이름, class method, sql , target database, 데이터베이스 처리 상태가 항상 동시에 보이고,
프로파일링 정보, call tree등이 항상 수집되고,
데이터베이스의 세션, 통계정보, sql 등이 항상 수집 되어야 한다.

이를 바탕으로 was-> 트랜잭션 -> call tree -> java source 로 트랜잭션 분석이 진행 되거나, db-> 세션 -> sql 처럼 데이터베이스 분석을 진행 할 수 있다.

이상 위에서 언급된 내용을 요약하자면, APM툴이 반드시 제공해야 하는 기능은 바로
Comprehensive visibility of transaction!


# InterMax 의 트랜잭션 관리

이제 이를 구체적으로 구현한 InterMax의 화면을 통해서 실제 사용 예를 간단히 보자.
TOP DOWN방식 접근법을 적용한 InterMax에서 상위의 tier들을 함께 보여주는 화면이 아래에 있다. 여기서는 web server, was, database의 개별 요소들의 전체적인 상태를 한 눈에 볼 수 있게 배치 되어 있다.
 

 



예를 들어 실행 되는 트랜잭션이 갑자기 증가하면서 대기 상황이 WAS쪽에서 보일 때 DB쪽에서 LOCK이 발생한 것이 보인다면 원인이 DB쪽임을 즉시 파악 할 수 있을 것이고 DB쪽에서 LOCK을 해소 하면 장애상황도 따라서 해결 될 것이다.

아래는 LOCK으로 인한 트랜잭션 증가 현상을 캡쳐한 화면으로 TREE구조로 LOCK상황을 볼 수 있어 즉시 LOCK HOLDER에 대한 정보를 파악 할 수 있다.

 



 화면 아래에 있는 것이 현재 실행 중인 트랜잭션의 목록이다. 여기서 특징적으로 보이는 점은 바로 트랜잭션, CLASS METHOD, DB INSTANCE, DB SID, SQL TEXT, DB SESSION WAIT 정보가 동시에 표현 된다는 점이다.
이 화면 만으로도 문제 상황에서 WAS쪽인지 DB쪽인지 해당 원인을 기본적으로 파악 할 수 있어 문제 구간을 찾기 위해 관련 담당자들이 모이는 등의 시간을 상당히 줄일 수 있다.

TOP LEVEL 모니터링에서 WAS와 데이터베이스가 동시에 모니터링 되고 트랜잭션은 WAS에서 실행 상태와 데이터베이스에서 SQL 실행 상태가 연결되어 하나의 뷰로 모니터링 된다면 트랜잭션관리라는 목표를 쉽게 달성 할 수 있을 것이다.


 




기고:   박 락 빈  (주) 엑셈 부사장
저작자 표시
신고

[기술기고/인터맥스] 애플리케이션 성능관리의 절대 기준 – 사용자 응답 시간

 



초당 처리 건수(TPS), 일 방문자수 그리고 테스트 툴을 통한 트랜잭션 응답시간등 일반적으로 IT부서에서 사용하는 성능지표들은 실제 애플리케이션 사용자에게는 의미가 없다. 사용자들에게는 자신들이 직접 경험하는 애플리케이션의 빠름/느림이 의미 있을 뿐이다.

물론 사용자들이 받아들일만한 응답시간이 무엇인지에 대해서는 객관적인 기준을 정하기가 쉽지 않지만 성능관리 측면에서는 최소한 사용자 응답시간을 수집/관리 해야 하고 APM툴에서 반드시 제공해야 하는 기능이어야만 한다. 사용자가 불만을 표시하기 전에 대응 할 수 있도록 APM툴에서 도와 줄 수 있어야 한다.

웹 페이지에서 정보를 판단하고 데이터 입력 등 에 사용자가 들이는 시간을 수집 하는 것도 필요하지만 이 부분은 객관적인 방법으로 데이터 수집이 상당히 복잡하고 어려우므로 현실적으로 수집 가능하고 애플리케이션 운영관리자에게 중요한 사용자 응답시간에 대해서만 언급하고자 한다.
 

일반적으로 사용 되는 응답시간 수집 방법

포트 미러링( sniffer ) – 애플리케이션에 부하를 주지 않고도 대부분의 트랜잭션에 대해 응답시간을 측정 할 수 있지만, 실제 클라이언트의 로딩시간( 즉 실제 사용자가 체험하는 응답시간)을 측정 할 수 없고, 포로토콜이 암호화 된 경우 측정이 쉽지 않다. 또한 복잡하게 frameset으로 구성된 경우, ActiveX 같은 경우 측정에 어려움이 있다.

Agent 방식 – 클라이언트 PC에 설치 되어 수집 하므로 PC의 상태 즉 CPU, 메모리, 디스크 등의 성능도 수집 가능 하고 무엇 보다 실제 사용자의 응답시간을 수집 할 수 있다. 단점은 Agent설치및 관리가 쉽지 않고, 모든 PC에 설치 할 수 없고 또한 ActiveX 같은 경우 수집이 어렵다.

로드 테스트 툴 – 동시 실행 등의 테스팅에는 좋으나, 스크립트 생성 및 관리에 전문적인 능력필요 하고 dynamic web content에 대한 처리가 어렵고, 무엇보다 실제 사용자의 응답시간이 아니다.

툴(GUI Robot Tool) – 사전에 정해진 임의의 트랜잭션들을 특정 시간 마다 자동으로 실행 해서 트랜잭션 응답시간을 측정한다. 실제 사용자의 응답시간을 측정 할 수 있다는 장점이 있는 반면 모든 트랜잭션에 대해서 수집 불가하고 샘플링 이므로 다양한 상황 대응이 안 되는 단점이 있다.  또한 외부 망에 있는 사용자의 응답시간 측정에 한계가 있어 시스템 접근 암호가 같이 배포 되어야 하므로 배포와 유지 관리에 비용이 발생한다. 
 

사이트에서 사용자 응답시간을 모니터링 하지 않는 이유

대부분의 사이트에서 실제 사용자 응답시간의 중요성을 알고 있지만, 실제 구축해서 사용하는 경우가 많지 않은 것은 주로 아래와 같은 이유들 때문이다.

- 위에 언급한 어떠한 경우 던지 구축에 시간이 많이 들고 또한 전문가의 도움이 필요하며 유지 관리 또한 복잡하고 어려움이 많다
- 대부분의 응답시간 측정 툴들이 point solution으로 공급 되므로 실제 문제 분석을 위한 다른 툴과의 연계가 쉽지  않고 추가적인 구축 작업이 필요하다.
- 수집되는 데이터가 가능한 모든 경우의 (상시)응답시간이 아닌 부분적이거나 또는 경우에 따라서는 실제 응답시간과 차이가 있을 수 있다.


InterMax의 사용자 응답시간 측정

InterMax에서는 위에 언급한 방식의 단점들을 극복하여 특허 등록된 새로운 방식으로 접근 하였다. 이를 통해 클라이언트에 설치 관리의 부하가 없으면서 화면 rendering시간이 포함된 실제 사용자 응답시간을 수집 하고 있으며 또한 ActiveX에 대해서도 수집할 수 있는 방법을 제공 하고 있다.

사용자 응답시간을 수집하기 위해 추가적인 설치가 없이 한 번의 InterMax 설치로 제공되는 기능이므로 APM관리자가 추가적으로 관리해야 하는 부담이 없다.

InterMax에서 수집하는 응답시간은 아래와 같은 구간별 구조를 가진다. 

 


**참고로 TP에 해당 하는 Tuxedo 모니터링의 경우는 다음 버전에서 제공될 예정 이다.


이를 통해서 InterMax에서는 실제 Client의 IP와 함께 트랜잭션별 실제 사용자 응답시간을 수집하여 APM관리자가 이를 통해 응답시간 저하와 관련된 대응을 할 수 있게 하였다. 이 데이터는 당연히 InterMax에서 수집되는 다른 성능 분석 데이터 즉 트랜잭션, SQL, Call Tree등 과 자연스럽게 연계 되므로 Point Solution의 경우처럼 복잡한 구축과 분석과정이 없어 가볍고 빠르게 APM관리자가 대응 할 수 있게 된다.

아래는 InterMax에서 기본 제공하는 Client Response Time화면으로 이를 통해, Client IP, 트랜잭션명, 응답시간, WAS 처리 시간, DB 처리 시간 등을 한 눈에 파악 할 수 있다.


 








기고:   박 락 빈
  (주) 엑셈 부사장  

저작자 표시
신고

[기술기고/인터맥스] 통합된 알람 관리

 


통합 알람 (alarm)

 APM툴에서 제공되는 핵심적인 기능중의 하나는 실시간으로 발생하는 각종 알람에 대한 설정 기능이 될 것이다. 문제가 되거나 알고 있어야 되는 EVENT에 대한 정의를 등록 하고 발생된 알람이 관련 담당자에게 즉시 통보 되는 시스템은 모든 사이트에서 필수적으로 요구 되는 기능인데, 현실적인 문제는 각각의 툴에서 독자적인 알람을 관리하고 단지 알람의 발생 사실만을 통보하는 방식으로 구축 되어 있다는 점이다.

 일반적으로 관리자가 데이터베이스 또는 WAS등의 각각의 시스템에서 알람 설정을 하고, 알람이 발생하면 사이트의 SMS툴로 전송되어 담당자들에게 통보 되는 방식을 주로 사용 한다. 이 방식의 단점은 WAS담당자 또는 DB담당자에게 알람의 원인을 규명하기 위해서 필요한 모든 정보를 가지고 있지 않은 경우가 있다는 점이다.
 

 




 예를 들어서 WAS담당자에게 Connection Pool이 부족하다는 알람이 오는 경우 원인을 분석하기 위해서는 데이터 베이스 쪽 정보도 같이 있어야 완전한 분석이 가능해 진다. Was쪽 connection pool부족이 db에서 발생된 문제 때문인지를 파악 해야 하기 때문이다. 즉 DB의 active session의 수 와 lock 대기중인 세션의 수 등에 대한 정보가 필요하다. DB에서 계속해서 세션이 묶여 있는 경우( 일을 하거나 대기 중이거나 어떤 경우라도 ) 해당 세션은 다른 트랜잭션에서 사용 할 수 없게 되고 따라서 Connection Pool부족 문제를 발생 하게 된다.

따라서 WAS 쪽 Connection pool의 수를 참조 해서 DB쪽 Active session에 대한 알람 설정이 필요하고 lock 대기에 대한 알람 설정도 마찬가지다.

또 다른 예로는 트랜잭션 elapse time에 대한 알람 설정은 sql elapse time에 대한 모니터링 기준으로 작용 하게 된다.

인터맥스의 통합 알람 구현

WAS또는 DB담당자 상호간의 원활한 협업과 투명한 정보공유를 위해서는 동일한 하나의 작업환경 하에서 동일한 방식 또는 뷰를 사용하면서 협업을 위한 분석 데이터가 충분하게 제공 되는 툴이 필수가 된다. 이는 제대로 된 APM툴이 제공해야 할 환경이 된다. WAS따로 DB따로 되어 있다면 협업을 하기 위한 정보의 투명한 제공에 추가적인 노력과 시간이 필요하게 된다. 애플리케이션이 WAS와 DB를 포괄 하는 것처럼 이를 모니터링 하는 APM툴은 당연히 WAS와 DB에 대한 모니터링 관리 기능을 함께 제공 해야 한다.

InterMax는 기존의 was 모니터링 툴보다 향상된 기능을 제공한다. 국산 툴 중에서 최초로 was와 db에 대한 실시간 모니터링 및 사후 분석기능을 통합하여 제공 한다. 따라서 알람 관리도 was와 DB에 대해서 통합적으로 제공 된다.
 
InterMax에서 제공 되는 통합 알람 기능 중 중요한 기능은 아래와 같다.
- WAS, OS, 데이터베이스(오라클,DB2)에 대한 충분한 알람 설정 기능
- 달력기능 제공
- 알람의 복사 기능

제공 되는 기능은 아래의 화면을 통해서 볼 수 있다.

 


 위 화면에서는 WAS와 DB 에 대한 알람 설정 화면으로, WAS 그룹에 대한 알람 설정과 이를 상속받아서 개별 WAS별로 알람을 설정 할 수 있다.  DB 도 마찬가리고 그룹으로 알람을 설정하고, 개별 DB 에 대한 알람은 그룹설정에서 상속받아 별도로 설정할 수 있다. 
 

 


 위 화면은 달력기능으로 알람 설정을 위한 특정 일자와 시간대를 지정해서 SCHEDULE을 등록 하는 기능으로 WORKING/NON-WORKING으로 구분해서 시스템작업등이 있을 경우 불필요하게 알람이 발생 하는 것을 막을 수도 있다. 


 



기고:   박 락 빈  (주) 엑셈 부사장



저작자 표시
신고

[기술기고/인터맥스] 운영중인 트랜잭션의 성능 분석, ‘상시 프로파일링’

 

# 운영중인 트랜잭션의 성능 분석은 어떻게 하는가

성능 분석은 주어진 일을 달성 하기 위해 소요된 시간으로 이해된다. (일단 필요한 자원사용에 대해서는 잠시 무시 하도록 하자.) 이와 다르게 장애 분석은 주어진 미션을 달성 하지 못할 경우 그 경로와 원인을 파악 하는 것이다.
‘운영중인 트랜잭션의 성능 분석’이란 이 둘을 동시에 지속적으로 수행 하는 것으로 보아야 한다.

지속적으로 성능 분석을 하기 위해서는 관련 데이터 수집이 운영시스템에 부하를 주지 않으면서 일상적으로 이루어 져야 하고 수집된 성능 데이터를 바탕으로 조회와 보고서가 매일 작성 될 수 있어야 한다.

개발중인 프로그램의 성능분석과 대비되는 운영중인 시스템의 성능분석이 가지는 차이점 몇 가지를 나열해 보자,

- 디버깅 툴을 사용 할 수 없다
- Stack trace 또는 profiling을 상시 사용 할 수 없다.
- 고객이 불만을 표하기 전에 문제를 알 수 있는 경우가 드물다
- Exception의 발생이 트랜잭션 성능 분석 과 연결 되지 못하는 경우가 많다.

트랜잭션의 성능 분석이 운영중인 환경 하에서라고 하더라도 개발환경에서 구할 수 있는 데이터 즉 모든 실행 경로를 추적하고 그 수행 시간을 수집함으로써 쉽게 가능해진다. 이 보다 더 트랜잭션의 성능을 알 수 있는 데이터는 없다고 보아야 하기 때문이다. 즉 개발단계에서 사용하는 디버깅툴과 프로파일링에서 제공되는 데이터를 운영상황에서도 제공 받을 수 있다면 트랜잭션의 성능분석을 위한 최선의 환경이라고 할 수 있다.

지금까지 몇몇 was 모니터링 툴에서 부분적인 기능으로 제공되었지만 대부분 부하문제로 운영환경에서는 이런 기능을 상시 사용 할 수 없었다. 그래서 문제가 있거나 오래 수행되는 METHOD를 찾아서 분석 하기 위해서는 먼저 문제가 보고 되고 나서 트랜잭션을 특정한 뒤에 부분적으로 사용하였다.

Stack trace의 경우 thread의 call stack을 텍스트 형태로 나열 하고, 특정한 한 번의 실행에 대한 정보로서 해당 경로에 있는 call stack만 제공 하기 때문에 종합적인 판단을 내리기 위해서는 2차 가공작업을 별도로 수행 해야 하는 번거로움이 발생 한다.


# InterMax에서 수집되는 프로파일링 정보

이제부터는 실제로 운영환경에서 사용가능한 수준의 프로파일링 기능이 제공되는 InterMax를 통해서 프로파일링 기능이 제공되었을 경우 이의 유용성 및 활용예를 살펴 보도록 하자.

"Call tree"

아래 화면은 InterMax에서 제공 하고 있는 call tree화면으로 수집된 프로파일링 데이터를 tree형태로 한 눈에 파악 할 수 있게 한다.

 

기존의 stack trace와 차별 적인 특징은 수집된 method의 사용 내역이 tree형태로 제공된다는 점이다. 따라서 분석을 위해서 마우스 클릭 만으로 모든 call 관계를 파악 할 수 있으며 또한 수행횟수, 수행시간, exception발생여부 등이 개별 실행 뿐만 아니라 summary된 형태로 볼 수 있어 장기 분석도 용이 하게 할 수 있다. 또한 TOP트랜잭션에서 즉시 해당 트랜잭션의 CALL TREE를 조회 할 수 있어 가장 오래 수행 되는 METHOD를 즉시 파악 할 수 있으며 해당 CLASS의 소스를 볼 수 있도록 되어 있다.
성능 분석이 트랜잭션->CALL TREE ->METHOD->CLASS SOURCE로 자연스럽게 흘러 가는 점은 상당한 장점이라 할 것이다.


"Call tree의 활용"

- Method의 elapse time 분석
 위의 화면은 가장 기본적인 call tree의 활용법이 될 만하다. 특정 트랜잭션에서 가장 오래 수행 되는 method를 즉시 파악 할 수 있으며 위의 예에서는 sql 수행이 가장 오래 동안 실행 되어 전체 트랜잭션의 대부분을 차지함을 알 수 있다.

 


- Method에서 thread 생성 여부
  자주 발생 하는 경우는 아니지만 was운영시 트랜잭션에서 다른 트랜잭션을 call 하는 방식으로 업무를 연계하지 않고 직접 thread를 실행해서 문제를 일으키는 경우가 있다면 이를 파악 하기가 쉽지 않았다. 하지만 InterMax에서 제공하는 Method의 속성 정보를 이용 하면 위의 예에서 처럼 thread를 사용하는 트랜잭션을 간단하게 파악 할 수 있다.
InterMax에서 제공하는 method의 속성은 loop, synchronized, new alloc, exit, gc, arraycopy, classloader, thread, reflect, io, net, nio, enumeration, iterator, strbuffer, strtoken, blob, clob, xml 등으로 시스템 운영에 영향을 줄만한 주목해서 보아야 할 대표적인 속성들이다.

 

 

- Commit/rollback의 실제 실행 여부
 간혹 예외 처리가 잘못되어 commit 또는 rollback이 실행 되지 않아 DB에서 LOCK 이 발생 되는 경우가 있다. 개발자가 사용하는 FRAMEWORK에서는 COMMIT을 실행 하는 METHOD가 실행 되었지만 어떤 이유로 실제 JDBC를 통해서는 COMMIT이 실행 되지 않는 경우도 있다.

아래 예제 화면을 통해서 보면 실제로 COMMIT이 JDBC를 통해서 실행 되었는지 아닌 지를 확인 할 수 있다. 이 기능은 DB Lock을 유발하는 트랜잭션을 찾을 때 아주 유용하게 사용 할 수 있다.

 

 

 

- Method의 exception 분석
 운영시스템에서도 끊임없이 exception은 발생하고 이를 log로 남기지만 로그 양이 너무 많아서 분석하기 곤란한 경우가 대부분이다. 따라서 트랜잭션의 성능 분석을 위해서 call tree를 활용 할 경우 method에서 발생되는 exception을 같이 볼 수 있다면 문제 분석에 많은 도움을 받을 수 있다.
InterMax에서는 이를 위해서 아래의 화면에서 보는 바와 같이 call tree에서 exception을 동시에 분석 할 수 있도록 하고 있다.

 





- Dependency 분석
 개발환경에서 method의 사용관계는 쉽게 파악이 되고 이를 바탕으로 class유지 관리를 하고 있지만 소스상에서가 아니라 실제 운영상황에서 사용관계를 파악 하는 기능도 필요 하다. 이를 통해 실제적인 사용통계를 바탕으로 소스의 유지 관리를 좀 더 실질적으로 조절 가능 할 것으로 보인다.
아래는 InterMax에서 제공 되는 화면으로 특정 method을 사용 하는 트랜잭션, class method 그리고 해당 method가 사용하는 method의 call tree를 한 눈에 볼 수 있다.

 

 


 이상으로 운영상황에서 프로파일링 기능이 제공 되었을 때 유용 하게 사용 할 수 있는 call tree와 그 활용에 대한 예를 살펴 보았다. 위의 활용에서 살펴보았듯이 상시 프로파일링 기능은 WAS모니터링에서 트랜잭션의 성능 분석을 위한 필수 기능으로 InterMax 의 특장점이라 할 수 있겠다.                                             <다음호에 계속>





기고:
박 락 빈  (주) 엑셈 부사장  

 

저작자 표시
신고

[기술기고/인터맥스] APM을 말하다

 



APM은 WIKI의 문구를 빌리면 Application Performance management란 애플리케이션 모니터링, 성능관리, 서비스 가용성에 대한 조직내 정책(?)이라고 한다.

Application performance management, or APM, refers to the discipline within systems management that focuses on monitoring and managing the performance and service availability of software applications.

APM can be defined as process and use of related IT tools to detect, diagnose, remedy and report application’s performance to ensure that it meets or exceeds end-users’ and businesses’ expectations. Application performance relates to how fast transactions are completed on behalf of, or information is delivered to the end user by the application via a particular network, application and/or web servicesinfrastructure.

여기서 중요 한 것은 사용자 관점 그리고 비즈니스 관점에서 성능이 평가 되어야 한다는 점이 되겠다.

 

 IT 환경은 on-line ENTRY + BATCH JOB 시대, CLIENT – SERVER 시대를 거쳐 현재의 비즈니스 시대( IT가 아니라 비즈니스다)에 이르렀다.
과거 성능 관리는 BATCH JOB의 SCHEDULING과 시스템의 안정성이 주요 관심사였고 따라서 ON-LINE 시간대 BATCH JOB 최소화, CPU BOUND JOB과 IO BOUND JOB의 조화, 그리고 시스템의 안정성을 위한 주기적인 유지관리 작업이 주된 성능관리였다. 이때 결코 관과 할 수 없는 중요한 관리 포인트가 또 하나 있었는데, 그것은 트랜잭션 처리량과ELAPSE TIME의 체계적 관리이다.
Clinet-server시대가 오면서 성능관리는 데이터 모델링과 이에 따른 SQL 튜닝, 그리고 Client와 Server로 분산하여 데이터 처리 등으로 변하면서 과거 중요한 지표였던 트랜잭션이란 개념이 상대적으로 사라졌다. 

 


하지만 24시간 비즈니스 시대인 현재, 언제 어디서든 트랜잭션을 즉시 처리해야 하는 기업의 환경아래, 성능관리측면에서 다시 트랜잭션의 개념이 명확하게 되 살아나고 있으며, 이전 보다 훨씬 복잡한 시스템을 24시간 모니터링하고 관리해야 하는 필요성이 대두되고 있다.


비즈니스의 핵심이 고객이 원하는 트랜잭션을 지체 없이 실행 할 수 있도록 하는 것이라면, APM은 분명 이 트랜잭션의 가능한 모든 측면을 모니터링하고 성능관리 할 수 있어야 한다.
WAS 중심의 모니터링은 자칫하면 트랜잭션처리에서 한가지 측면만을 보게 될 수 있다. 트랜잭션 처리에 관련 되는 중요 요소들을 좀 더 구체적으로 살펴보아야 한다.

 


트랜잭션 처리의 중요 요소들은 사용자-N/W-WEB SERVER-WAS-TP-DATABASE등이 있을 것이다. 환경에 따라 TP등은 빠지는 등 다를 수 있겠지만, 전체적인 관점에서 틀리지는 않을 것이다.
결과적으로 대부분의 시스템에서 사용자체험, WAS, DB 가 최소한의 APM 성능관리 주요 항목 된다고 할 수 있다.
 

 

가장 기본적인 조건은 당연히 안정적이면서 가벼워야 한다는 점이다. 시스템에 부하를 주지 않는 것이 최선이지만 이것은 현실적으로 불가능 하다. 따라서 여기에도 경제법칙이 적용 되어야 한다. 최소의 부하로 최대한 관련 정보를 수집할 수 있어야 한다. 경제성의 기준치는 사이트 마다 다를 수 있지만 최소/최대의 기본은 반드시 지켜져야 한다.

기능적으로 중요한 몇 가지를 살펴보면,

 

1. 사용자 체험 시간
당연한 것이지만 비즈니스 시스템의 최종평가는 사용자의 것이며 이 중에 편의성 등 과 같은 주관적인 요소가 개입되는 평가는 어렵겠지만 가용성과 체감시간은 객관적으로 수집 ,평가 가능한 요소 이므로 이에 대한 정보를 제공 할 수 있어야 한다.




2. 트레이스 기능 


개발자의 프로그램에 대한 profiling 또는 tracing에 대한 정보를 수집 제공 할 수 있어야 한다. 기본적으로 모든 사용되는 class, method에 대한 사용관계가 call tree형태로 수집되어야 하며, 운영환경에서는 현실적으로 수집의 부하와 데이터 보관의 어려움이 있으므로 최소한 개발된 class에 대해서는 method call tree가 수집 되어야 한다.



3. Change 추적 
 정상운영 되던 시스템에서 장애가 발생 했을 경우 무엇을 가장 먼저 하는 가? 통상적으로는 새로 변경 적용된 것이 있는 지를 빨리 파악 하는 것이다. 그렇다면 APM에서 기본적으로 갖추어야 할 기능은 변경이력 관리이다. 대상은 아주 광범위 한데, 프로그램소스, JAVA설정, WAS설정, OS 환경변수, OS 시스템 설정, DATABASE 설정, DATABASE OBJECT 등이 될 것이다.              
                           

 

 

4. Tier 연계 분석
장애상황분석 또는 예측되는 장애를 방지 하기 위해서는 취약한 곳이 어디에 있는 지 알 수 있어야 한다. WAS가 문제인지 DB가 문제인지 이를 인지하고 해당하는 곳의 무엇이 장애를 유발 했는지 객관적으로 알 수 있는 정보가 제공 되어야 한다. 단지 트랜잭션의 시간을 TIER별로 나누어서 보여주는 것은 단지 현상을 보여주는 것이다. 문제의 원인을 추적 할 수 있는 정보가 없다면 또다시 많은 노력을 들여야만 한다. 반드시 관련 정보를 충분히 제공할 수 있어야 한다.


 

 


 대부분의 운영시스템에는 이미 각각의 TIER에 대한 성능 관리 솔루션이 도입되어 있을 것이다. 또한 이들 각각의 TIER 정보를 종합하는 상위의 관제 솔루션 역시 구축 되어 있는 것이 일반적이다. 이들 관리를 위해서 기업은 많은 예산과 인력을 투여하는 것이 불가피하다.
 하지만 만약 단일 솔루션으로 이들 대부분을 처리 할 수 있다면 어떨까? 최소한 솔루션 통합을 위한 더 이상의 노력은 들이지 않아도 되지 않을까?
트랜잭션과 각 TIER에서 일어 나는 일이 한 곳에서 오해 없이 깔끔하게 제시 되면, WAS 담당자와 DB 담당자가 각자의 데이터를 준비하고 서로에게 제시하는 일은 더 이상 불필요할 것이다. 또한 각 TIER에서 별도로 관리 되는 알람 설정도 한 곳에서 일목요연하게 관리 된다면 각 담당자들의 오해의 소지를 줄이게 될 것이다. 

엑셈은 기존의 틀을 벗어나 APM을 새롭게 정의하여 진정한 APM 통합관리를 위한 단일 솔루션 InterMax를 개발하였다. 앞으로 InterMax 의 진가를 발휘하는 기능들을 소개해 보도록 하겠다.
(다음호에 계속)        
                                          

 


                                           기고:   박 락 빈  (주) 엑셈 부사장  

저작자 표시
신고


티스토리 툴바