Red Hat IAC & DevOps 세미나, IT시스템 관리작업을 자동화하는 방법

지난 3월27일(수) 코엑스 컨퍼런스룸에서 진행된 IAC(Infrastructure as Code & DevOps 세미나에 다녀 왔습니다. IT시스템 관리를 자동화할 수 있는 솔루션인 Ansible에 대한 내용이었는데요. 작년 11월 Red Hat Forum 2018에서 처음 봤었던 Ansible을 이번 세미나에서 자세히 살펴볼 수 있었습니다. 또한 마이크로서비스를 위해 컨테이너를 활용해 개발을 하시는 개발자 분들이 빠르게 개발환경을 구축하고 개발에 전념할 수 있도록 도와줄 수 있는 DevOps 환경을 위해 Ansible이 어떻게 활용될 수 있는지 알 수 있었네요.

Red Hat과 파트너 오픈나루가 주관하고 총판인 코오롱베니트에서 후원한 이번 세미나에서는 총 7개의 세션이 진행 되었습니다. 





그럼 세션 하나 씩 차근 차근 정리 해 보겠습니다.
 
첫 번째 세션은 이렇게 개괄적인 내용 위주로 진행 되었습니다. 이후 진행된 다양한 세션에서 Ansible이 할 수 일들, 구체적으로 자동화가 되면 반복적인 업무를 어떻게 빨리 처리할 수 있는지, 실제 작동은 어떻게 되는지, 어떤 경우에 도입해서 활용할 수 있는지에 대한 내용이 소개 되었으니 보다 자세한 내용은 이후 개별 세션에서 소개 해 드리겠습니다.
 

1. IT 자동화의 글로벌 동향과 나아갈 방향 자세히 보기

기업에서 업무 생산성을 위한 자동화를 추진할 때 위와 같이 두 가지 관점에서 자동화를 추진하게 됩니다. IT자동화, 비즈니스 자동화 인데요. 먼저 IT자동화를 위해서 기업은 반복적인 작업에 매크로와 쉘, 자동화 툴을 이용하고 비즈니스에는 각종 업무용 애플리케이션에서 제공되는 자동화 기능(Excel의 VBA나 웹브라우저의 반복실행 기능)을 이용합니다.




RPA는 Robotic Process Automation의 약자로 사람이 수작업으로 처리했었던 것들을 단순 반복적인 부분은 로봇(기계)로 자동화 시키고 사람은 좀 더 가치있는 일에 집중할 수 있도록 지원하는 솔루션을 말합니다.

글로벌 시장을 기준으로 2021년에 약 13조원까지 성장할 것으로 예측되는 고성장 분야 중 하나로 이미 시장에 출시된 상용 RPA솔루션도 많이 있는데요. 글로벌 IT기업인 IBM, 업계 1위 유아이패스 부터 LG CNS같은 SI기업과 여러 중소기업들의 솔루션까지 다양합니다. 관련 내용이 담긴 기사는 여기서 확인하실 수 있습니다. 

금융권의 RPA도입 사례에 대한 내용이 궁금하신 분들은 여기서 KPMG의 보고서를 보실 수 있습니다.


이 자동화의 발전단계는 위와 같이 4단계로 구분할 수 있습니다. 먼저 가장 기본적인 자동화 즉, 반복적인 루틴하게 돌아가는 업무 부터 자동화 하는 것입니다. 이후 프로세스 단위의 자동화를 통해 어떤 업무라도 자동화된 프로세스에 태워 보다 효율적으로 업무를 할 수 있게 끔 도와줄 수 있습니다.

다음 단계는 인공지능 인데요. 축적된 자동화 데이터를 기반으로 인공지능이 그저 사람이 시키는 대로 자동화 프로세스를 실행하는 것이 아닌, 점점 프로세스를 개선시켜 나가면서 실행할 수 있습니다. 이전 단계까지는 사람이 만들어 놓은 규칙대로 자동화 프로세스가 진행되고, 각 진행 단계별로 사람이 개입하여 제대로 되고 있는지, 결과물은 잘 나왔는지 판단했어야 하지만 인공지능이 가미되면 그 판단을 기계가 대신하게 해 주어 사람의 업무시간이 더욱 절약될 수 있겠죠.

마지막 단계는 Digital Transformation에서 최종 단계로 많이 언급되는 Intelligent Enterprise 입니다. 기업 전체 프로세스가 인공지능 기반의 자동화로 진행되어 사람은 보다 창의적이고 가치있는 업무에 집중할 수 있게 됩니다. 기계가 분석하여 내놓은 결과물을 바탕으로 새로운 시장 개척 같은 가치있는 일에 시간을 투자하는 것입니다. 이 단계까지 다다르면 사람의 역할은 인공지능을 어떻게 관리하고 적재적소에서 잘 활용할 수 있는지에 집중 될 것입니다.



그렇다면 왜 이러한 자동화 시스템, 솔루션이 필요하게 된 것일까요? 여러 요인이 있겠지만 가장 지대한 영향을 끼친 것은 바로 클라우드 때문일 것입니다. 클라우드 덕분이 자동화의 필요성이 높아졌고, 더불어 자동화 솔루션 역시 보다 고도화 될 수 있었습니다. 

위 장표의 내용 처럼 1980년에와 비교해서 2010년 이후 클라우드가 확산되면서 IT관리자가 관리해야 할 접점이 너무 많이 늘어 났습니다. 단순 물리적 시스템에서 VM기반의 가상화 시스템이 기하급수적으로 늘어나게 되면서 자동화는 반드시 필요한 요소가 되어 버렸죠. 단순히 업무를 자동화시켜 내 일을 편하게 처리한다는 것을 넘어서 이제는 적어도 클라우드 환경에서는 자동화 하지 않으면 업무를 처리할 수 조차 없게 된 것입니다.




더군다나 클라우드를 이용하게 되면서 시스템이 복잡해졌고 관리하는 스킬도 더욱 높은 수준이 필요하게 되었습니다. 이전보다 훨씬 높은 수준의 엔지니어가 필요하게 되었고 관리해야 할 VM은 계속 늘어나서 반복작업이 더 많이 늘어나게 됐죠. 거기에 인프라를 전부 클라우드로 옮기는 것은 드물기 때문에 기존 레거시 시스템과의 통합 이슈 역시 발생합니다. 그러면 기업은 일단 사람을 늘려서 해결하려 할텐데, 이렇게 되면 자연스레 비용문제가 불거져 TCO 이슈가 발생할 수 밖에 없게 됩니다.

이러한 이유 때문에 IT시스템 관리에 자동화가 필요하게 된 것입니다. 



그렇다면 자동화를 어떻게 해야 할까요? 오픈소스 IT자동화 관리 솔루션인 Ansible이 도와줄 수 있습니다. 기존에 관리해야 하는 시스템 마다 각기 다른 형태 작업을(쉘 스크립트, 전용도구, 매크로) 직접 사람이 수작업으로 처리 해 왔다면 Ansible을 이용해 표준화된 환경을 구축하여 관리할 수 있습니다.

여기서 핵심이 되는 것이 바로 IAC(Infrastructure as a Code)입니다. 기존에 처리해 왔던 업무방식을 Code로 작성하고, Ansible에서 이 Code로 시스템환경을 구축, 배포, 관리할 수 있습니다. 개발자는 개발에만 전념하고 표준화된 Code로 재빨리 시스템 개발 환경을 구축하여 운영할 수 있는 것입니다. DevOps가 가능해 진다는 것이죠.



IAC가 그렇게 익숙한 용어는 아닌 것 같습니다. 저는 이번 세미나에서 처음 접했거든요. IAC는 기존에 수작업으로 진행했던 반복적인 업무를 코드로 짜서 자동화 시키는 것입니다. 즉, 작업계획서를 작성하여 이 계획서 대로 단계를 밟아가며 처리했던 업무를 코드화 시켜서 작업이 필요할 때 마다 코드를 실행시키면 됩니다.

이로써 IT인프라 관리 역시 코딩을 통해 자동화할 수 있고, 이게 가능해 지면 팀원들과 코드를 공유하여 유사 업무에 적용하는 등 협업이 가능해 집니다. '나는 서버 10대 배포할테니 너는 개발팀에서 원하는 환경 세팅해줘'가 아니라 나는 개발1팀 환경 구축하고 세팅할테니 너는 개발2팀 환경 세팅해줘'라는 식인 것이죠. 개발환경 요건이 다르더라도 기본적인 인프라는 비슷할테니 이미 코드로 짜 놓은 자동화 코드를 이용하여 운영 환경을 손쉽게 구축하고 관리할 수 있는 것입니다.



IAC를 통해 위와 같이 4가지 혜택을 누릴 수 있습니다. 자동화 시켰으니 작업 공수가 절감됨은 당연한 결과가 되겠죠. 그리고 코딩을 통해 작업 환경을 구축하고 관리하기 때문에 서버 별로 구축할 때 마다 세팅값이 변경되고 오류가 발생해서 고치다가 일부 누락되는 등 문제가 발생할 여지가 줄어들어 작업 품질을 상향 평준화 시킬 수 있습니다.

또한 코드화 된 자동화 덕분에 업무 프로세스를 표준화 시킬 수 있어 담당자가 바뀌더라도, 부재 중이더라도 대체 인력이 쉽게 처리할 수 있습니다. 또한 한번 사용한 코드는 폐기하지 않고 재사용할 수 있기 때문에 작업 환경을 균일하게 가져가고 일부 변경이 필요한 내용만 수정하여 사용하게 되면 운영 환경 배포시간 역시 앞당길 수 있겠죠.

마지막으로 작업 자체를 자동화 시킴으로써 휴먼에러가 발생할 여지를 사전에 차단하고 보안을 강화시킬 수 있습니다.



IAC로 실행되는 작업은 위와 같이 분류할 수 있습니다. 먼저 Bootstrapping 초기 설치 입니다. 초기에 운영 환경을 세팅하기 위해 가상머신 혹은 컨테이너를 활용하여 자원을 할당하고 OS을 배포합니다. 이후 Configuration을 통해 웹서버, DB 등 필요한 서버를 구축하고 설정을 관리합니다. 마지막으로 이렇게 구축 된 환경에서 돌릴 애플리케이션을 배포하고 시스템 모니터링을 통해 Scale Out 스케쥴링을 걸어 시스템을 운영합니다.



즉, IAC를 통해 개발팀에서는 운영환경 구축을 간소화 시켜 개발에만 집중할 수 있게 되고, 시스템 관리자는 반복적인 환경 구축 및 관리, 배포에 대한 업무를 자동화 시킴으로써 보다 효율적으로 업무를 처리할 수 있게 되는 것입니다. Ansible은 위와 같이 각 단계별로 현존하는 대부분의 플랫폼을 지원하기 때문에 IT운영환경 자동화에 최적화 된 도구라고 할 수 있습니다.




위와 같이 Ansible은 기존의 업무 별 작업계획서를 Playbook이라는 형태로 코딩하여 자동화 시키고 필요할 때 실행시킬 수 있게 하나의 서비스로 만들도록 도와줍니다. 그리고 이렇게 만들어진 서비스들을 서로 연결하여 IT운영 환경 구축 프로세스를 만들 수 있습니다. 개발팀에서 신규 애플리케이션 테스트를 위해 이런 저런 개발환경을 구축해 달라고 요청이 오면 미리 만들어진 자동화된 코드들의 집합인 프로세스를 실행시켜 간편하게 환경을 구축하고 개발팀에 전달해 줄 수 있게 되는 것입니다.

여기까지 이번 세션 내용 정리를 마무리 하겠습니다.

 
 
두 번째 세션은 Ansible이 무엇이고 언제 만들어 졌으며 경쟁솔루션 대비 어떤 장점을 가지고 있는지, 구성요소는 무엇인지 살펴봅니다. 자세한 내용을 보시려면 아래 '자세히 보기'를 클릭 해 주세요.
 

실전! 시스템 관리자를 위한 Ansible 자세히 보기

IT환경은 위와 같이 4가지 영역에 있어서 진화 해 왔습니다. 아마 최근 IT인프라 관련 세미나에 참석하셨던 분들은 서두에서 위와 유사한 내용의 장표를 많이 보셨을 텐데요. 간단히 정리하면 개발 프로세스, 즉 프로젝트 방법론은 Waterfall -> Agile -> DevOps로 발전 해 왔습니다.

- Waterfall(워터폴) : 요구분석 -> 설계 -> 디자인 -> 개발 단계로 폭포수 처럼 위에서 아래로 단계적으로 이어지는 모델
- Agile(애자일) :  실제 애플리케이션을 사용할 고객과의 의사소통을 중시하며 일정한 주기를 가지고 프로토타입 위주로 끊임없이 개발하고 테스트하며 요구사항이 추가될 때 마다 반영하는 모델
- DevOps(데브옵스) : 개발팀과 IT인프라팀이 명확하게 나눠져 있지 않고 통합적으로 운영되는 모델, 개발자가 개발 환경을 인프라팀에 요청하고 완성되기를 기다리는 것이 아닌 직접 개발 환경을 가상화, 컨테이너 모델을 토대로 간편하게 구축거나 개발자와 인프라 운영자가 한 팀에서 긴밀하게 협력하는 모델

애플리케이션 아키텍쳐는 Monolithic(단일 모델) -> N-Tier(일대다 모델) -> 마이크로서비스(대다대 모델)로 발전했고요. 개발 환경은 물리서버 -> 가상서버 -> 컨테이너로, 인프라는 데이터센터 -> 호스팅 -> 클라우드로 발전 했습니다. 

이렇게 IT환경이 진화하고 클라우드로 촉발된 관리포인트 증가로 인해 자동화가 필요하게 되었다고 앞 세션에서 설명 드렸는데요. 이 자동화를 도와줄 Ansible을 자세하게 소개 해 드리겠습니다.



Ansible은 IT운영 환경 자동화 엔진으로 2012년에 Python 기반으로 제작되어 탄생 했습니다. 2015년에 Red Hat에 인수되었으나 엔진 자체는 여전히 오픈소스로 제공됩니다. 그럼 Red Hat은 뭐로 장사할까요? 이 Ansible 엔진을 사용자들이 쉽게 사용할 수 있도록 도와주는 UI 및 모니터링 도구인 Ansible Tower를 판매합니다. 자세한 내용은 이후 세션에서 소개 해 드릴게요. 작년 Red Hat Forum 2018에서 처음 접했을 때는 Red Hat에서 만든 솔루션인 줄 알았는데 그게 아니더군요.



IT자동화 도구는 Ansible외에 Puppet, Chef, Salt라는 경쟁 솔루션이 있습니다. 위와 같이 구글 트렌드를 살펴보면 Ansible이 출시된 이후 구글에서의 검색량 증가 추이가 Ansible이 독보적인 것을 보실 수 있습니다. 2015년 12월을 기점으로 쭉 치고 올라가는 것을 확인할 수 있네요.



2005년에 탄생한 Puppet과 2009년에 만들어진 Chef보다 훨씬 늦은 2012년에 출시되었음에도 불구하고 Ansible이 자동화 도구 시장에서 대세가 된 이유는 앞서 출시된 도구들의 단점을 개선하여 만들어졌기 때문입니다. 가장 큰 장점은 바로 에이전트 리스로 구동된다는 것입니다. 



Ansible의 특징은 위와 같이 3가지로 나눌 수 있습니다. 먼저 앞 장표에서 말씀 드렸듯이 에이전트가 필요 없는 아키텍쳐를 가지고 있어 시스템에 주는 부담이 적고 Windows 애플리케이션도 지원합니다. 그리고 Playbook이라는 설정파일을 YAML 형식의 사용하기 쉬운 언어를 사용하기 때문에 전문 개발자가 아니더라도 손쉽게 사용할 수 있습니다. 또한 다양한 사례에 적용할 수 있는 모듈을 지원하며 동시에 다수의 서버에서 실행할 수 있는 강력한 성능을 가지고 있고 Ansible Tower와 연계 해 간편하게 애플리케이션 환경 구축, 배포, 관리를 수행할 수 있습니다.



에이전트리스라는 특징을 설명하기 위해 앞 장표에서 보여 드렸던 경쟁 솔루션인 Puppet, Chef가 사용하는 Pull 방식과 Ansible의 Push 방식을 비교 해 보겠습니다. 먼저 Pull방식은 중앙에 놓여진 서버에서 관리 할 서버 및 클라이언트에 에이전트를 설치하고 데이터를 수집해 오는 방식입니다. 이 때문에 관리포인트가 늘어나는 단점이 있습니다.

Push 방식은 마찬가지로 Ansible이 중앙 서버로써 관리 할 각종 서버에 SSH로 통신하여 원격으로 실행하거나 파일을 연결 된 서버로 밀어넣어 관리하는 개념입니다. 관리포인트는 중앙의 Ansible이 설치 된 서버 하나 입니다.



Ansible은 코어 엔진과 간편한 UI 환경 및 다른 Red Hat 제품들과 연계하여 관리할 수 있는 Ansible Tower로 구성되어 있습니다. 코어 엔진은 오픈소스로 제공되며 Ansible Tower가 Red Hat에서 다른 제품들과 마찬가지로 구독 형태로 판매하고 있습니다. 그리고 Ansible AWX라는 것이 있는데 Ansible Tower의 오픈소스 버전이나 GUI 관리 환경만 제공하기 때문에 기존 Red Hat의 OS나 미들웨어, 클라우드와 통합되지 않는 단점이 있습니다.



Ansible을 사용하면 위와 같이 3가지 효과를 기대할 수 있습니다. 먼저 자동화를 통해 휴먼에러, 작업자의 예기치 못한 실수를 방지하고 작업하는 사람의 능력에 따라 작업 시간과 결과물이 달라지는 인력 의존성에서 벗어날 수 있습니다. 10대의 서버에 작업했는데 장애가 발생했고, 그 장애를 찾기 위해 서버 10대의 설정 하나 하나 뜯어볼 필요가 없다는 것이죠.

그리고 Playbook을 한번 잘 만들어 두면 대량의 대상 서버에 한꺼번에 적용하여 실행시킬 수 있어 작업시간을 단축시킬 수 있습니다. 또한 당야한 오픈소스, 상용화 솔루션과 연결하여 업무 효율성을 증대시킬 수 있습니다.



Ansible의 특징 중 하나는 바로 멱등성 입니다. 용어가 좀 어렵죠? 멱등성은 수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미합니다. 즉, 한번 만들어 둔 설정에 따라 실행을 반복 하더라도 결과값이 달라지면 안되겠죠. 그리고 변경 된 부분이 있다면 그 부분만 업데이트 되어 반영되는 성질을 뜻합니다.

이 멱등성은 Ansible에서 지원하는 다양한 모듈로 구현됩니다. 다양한 환경에 맞는 모듈 중 현재 내 환경에 맞는 모듈을 선택하고 실행하면, 이 멱등성 덕분에 수백 수천번 실행 된 모듈이 여전히 동일한 작업을 안전하게 수행되는 것입니다. 작업자 입장에서는 한번 실행한 모듈을 다른 대상에 적용할 때 어떤 결과값이 나올 지 예상할 수 있으니 혹여 에러가 발생 하더라도 어느 부분에서 에러가 발생한 것인지 쉽게 찾을 수 있습니다. 모듈의 코드가 변경 되었는지, 그렇지 않다면 하드웨어에 문제가 있는 것인지 이원화 해서 살펴보면 될 테니까요.



Ansible의 핵심 구성요소는 위와 같습니다. Ansible 코어 엔진에는 명령을 실행하기 위한 CLI(Command Line Interface)와 재사용 가능한 다양한 모듈, 그리고 추가적인 기능을 붙이기 위한 플러그인으로 이루어져 있습니다. 이 코어 엔진을 Inventory라는 사전에 지정해 둔 대상서버에 어떤 작업을 실행 할 것인지에 대한 내용이 담긴 Playbook을 가져와 실행하는 구조로 되어 있습니다.



사용자는 앞서 소개 해 드린 Ansible의 구성 요소 중 Inventory 파일과 Playbook 파일만 작성하면 됩니다. 말씀 드렸듯이 Inventory 파일에는 작업을 진행할 서버의 위치를 기록하고, Playbook에 어떤 작업을 실행할 지 YAML언어로 직관적으로 기입하여 실행합니다.



Playbook은 위와 같이 실행할 수 있습니다. 파일을 실행하면 Ansible에서 Playbook에 기록된 작업내용을 토대로 Inventory에 지정된 서버에 SSH망을 실행 시킵니다. 이 때 대상 서버에 실행을 위한 별도의 에이전트는 필요 없지만 반드시 Python이 설치 되어 있어야 합니다. YAML파일 실행을 위한 스크립트를 설치해야 하기 때문인데요. Ansible은 Python으로 만들어졌다고 말씀드렸던 것 기억 하시죠?



Playbook 파일의 내용은 위와 같이 되어 있습니다. 누구에게 어떤 내용의 작업을 어떻게 구체적으로 실행할 지에 대한 내용이 기재되어 있는데 내용이 상당히 직관적이고 보기 쉽게 되어 있습니다.(라고 말씀 드리지만.... 저 같은 개발자가 아닌 사람들은 어려운 것이 사실입니다만, 기존의 다른 프로그래밍 언어 보다 보기 쉬운 것은 사실입니다.) 그리고 기재 된 순서대로, 위에서 아래대로 실행됩니다.



Playbook에 대해 소개 해 드리면서 여러번 언급 된 YAML은 '야물'이라고 발음하는 HTML보다 더 구조화 된 텍스트 형식의 포맷, 즉 또다른 HTML과 같은 마크업 언어라고 보시면 됩니다. 최근 들어 많이 사용하는 형태라고 하며 위 장표의 하단을 보시면 같은 내용이지만 '-'표시와 들여쓰기를 이용해 마치 우리가 보고용 문서를 작성 하듯이 만들어 진 것을 보실 수 있습니다. JAVA 이외의 언어를 사용할 때에 이 YAML파일이 거의 기본처럼 사용 된다고 합니다.(만 저는 오늘 처음 봤어요.....)



Ansible의 모듈은 위와 같이 다양한 사례에 2,000개 이상의 모듈이 이미 만들어져 공개되어 있습니다. 또한 Ansible 커뮤니티에서 지속적으로 새로운 모듈이 공개되고 있어 이 수는 계속 증가할 것이라고 하네요. 온프레미스, 가상화, 클라우드 환경 뿐만 아니라 OS와 DB, 네트워크, 스토리지까지 적용하고 싶은 분야에서 내 환경에 맞는 모듈을 선택해 빠르게 자동화 작업을 진행할 수 있습니다.




템플릿을 이용하면 이미 어느 정도 완성된 파일에 변수 값만 지정해서 대상 서버에 갖다 놓고 빠르게 적용하여 활용할 수 있습니다. 이 템플릿은 Python에서 가장 많이 활용되는 템플릿 엔진인 j2(Jinja2)를 활용하기 때문에 Python에 익숙하신 분들은 쉽게 사용하실 수 있을 것 같네요.



구체적으로 Ansible로 위와 같이 설치, 다운로드, 환경설정 파일 배포, 실행 및 기타 작업들을 자동화할 수 있습니다. 잘 활용하면 IT관리자들 업무가 엄청 편해질 수 있을 것 같죠? 잘 활용하면 입니다. Ansible이 자동으로 알아서 해주면 참 좋겠지만, Inventory와 Playbook은 직접 만들어야 합니다. ㅎㅎㅎ

그래도 다른 언어로 자동화 스크립트 만들어 배포하는 것 보다는 나름 직관적이고 쉬운 YAML을 이용하는 것이 더 수월할 것 같습니다. 저도 배워서 해 볼 수 있겠다 싶었으니까요. 데모를 보니까 적어도 복잡한 명령어와 코드 보고 지레 겁부터 먹게 되지는 않더라구요.



세션이 시작되기 전에 5분 남짓 동영상으로 먼저 봤었던 Apache 설치과정 데모의 Playbook과 Inventory 파일 입니다. 위에서 보시는 이 간단한 코드로 채 몇분 안되서 Apache 웹서버가 뚝딱 하고 만들어졌고 보안패치 작업까지 수행하는 것을 볼 수 있었습니다.(녹화해 둔 영상이 있는데, 현장에서 시연된 영상 역시 라이브 데모는 아니고 녹화된 영상을 보여주는 것이어서 필요하신 분은 별도로 요청 해 주시면 관계자 분께 요청하여 보내 드리겠습니다. 제공해 주시기 어렵다고 하면 제가 찍은 영상 보내 드릴게요.)



Ansible을 이용하여 다수의 서버에 동일한 작업을 실행 하다가 어떤 특정 서버에 별도의 다른 명령을 실행해야 할 경우 위와 같이 Ad-hok(애드훅) 기능을 통해 특정 호스트(대상 서버)에만 별도의 명령을 실행시킬 수 있습니다.



정리하면, 기존에 많은 인력들이 반복된 작업을 수작업으로 진행하던 것을 Playbook으로 할 일을 만들고 Inventory로 작업할 대상을 지정하여 실행하는 것 처럼 자동화 시킬 수 있는 솔루션이 바로 Ansible 입니다.



기존의 작업계획서를 Ansible Playbook으로 코딩하고 이를 Ansible Tower라는 UI관리 도구에서 보다 간편하게 적용하고, 실행시키고, 배포할 수 있습니다.


이 Ansible의 자동화 작업을 더 쉽고 빠르게 현업에서 사용할 수 있도록 오픈나루에서 만든 솔루션이 KHAN 입니다. KHAN의 프로비져닝 기능은 Ansible Playbook의 명령을 위와 같이 각 작업 별로 재정의 후 매칭시켰습니다. 이미 KHAN에서 만들어 둔 명령들을 선택해서 Ansible을 통한 자동화 작업을 좀 더 쉽게 실행할 수 있도록 도와줍니다.

여기까지 이번 세션 내용 정리를 마무리 하겠습니다.

 
이번 세션에서는 Ansible을 IAC관점에서 더 깊게 살펴봅니다. 오픈소스 클라우드 플랫폼인 OpenStack에서 Ansible을 어떻게 활용할 수 있는지, 구체적인 IAC사례에 대해 자세히 보시려면 아래 '자세히 보기'를 클릭 해 주세요.
 

IAC on OpenStack(feat. Ansible) 자세히 보기

오픈소스 Ansible 사용자 축제인 Aisible Fest에서 발표된 수치입니다. Ansible은 GitHub에서 31,000개 이상의 스타를 획득했고 금일 기준 2,038개 이상의 모듈과 월 50만회 이상의 다운로드 수를 기록하고 있습니다. 또한 Ansible Galaxy라는 커뮤니티를 통해 다른 사람이 만든 코드를 활용할 수 있는데요. 이 덕분에 사용자들은 처음부터 코드를 만드는 것이 아니기 때문에 보다 쉽게 개발 및 배포가 가능해 질 수 있습니다.



Ansible의 장점은 앞의 두 세션에서도 여러번 말씀 드렸는데, 이 세션에서는 코딩을 아주 잘 할 필요 없이 쉽게 할 수 있다는(YAML 언어로 코딩하기 때문입니다.) 코드 관점의 내용 위주로 진행 되었습니다. 다른 내용은 앞에서 많이 말씀드렸으니 넘어가도록 하죠.



Ansible 아키텍쳐 입니다. 사용자는 Playbook을 만들고, 이 Playbook은 Ansible 코어 엔진을 통해 대상 서버에서 실행됩니다. Inventory에 대상 서버의 위치를 지정한다고 말씀 드렸는데, 예를 들어 200대의 대상 서버 중 10대에만 동일한 내용의 패치를 해야 한다면, 그 10대의 위치만 Inventory 파일에 기록하여 실행시키면 됩니다. 10대의 서버를 각각 패치할 필요가 없다는 거죠. 그리고 모듈을 활용해서 작업의 상세 내용을 정의한 뒤 Playbook 파일을 대상에 놓고 실행하면 끝입니다.

하지만 이 자동화 과정이 장점만 가지고 있는 것은 아닙니다. 자동화는 병렬적으로 작동하기 때문에 즉, 대량의, 100대의 대상에 빠르게 동일한 작업을 진행하기 때문에 만약 잘못된 파라미터 값으로 인해 오류가 발생하면 100대의 서버에 오류가 동시이 발생하게 됩니다.(작업은 간단하지만 큰 오류가 발생할 수 있는 가능성 내포), 과거에는 시퀀셜 작업(한대 한대 각각 작업)이었기 때문에 작업은 복잡했다 하더라도 비교적 작은 오류가 발생됐습니다.

그래도 만약 오류를 발견하면 다시 100대의 빠르게 수정 된 내용을 배포할 수 있긴 하기 때문에 장점이 더 크다고 할 수 있겠습니다. 문제를 해결할 수 있는 방안도 자동화 시킬 수 있기에 이 장점을 어떻게 잘 활용할 수 있는가에 초점을 맞추는 것이 중요할 것 같습니다.



Ansible은 최근의 다른 자동화 도구에서 사용하는 언어와 마찬가지로 선엉형 방식을 취하고 있습니다. 실행이 초점이 맞춰져 있다고 보시면 되는데요. C나 JAVA처럼 메모리에 저장된 명령어를 순차적으로 실행하고 이 때 필요한 데이터를 메모리에 저장하는 명령형 언어와 반대의 성격을 가지고 있습니다. 

명령형 언어는 어떠한 문제 해결 혹은 임무를 수행하기 위해 명령을 내리고, 그 명령을 순차적으로 수행합니다. 목표는 명시하지 않고 어떻게 실행하라고 알고리즘을 명시하는 형태입니다.(How) 반대로 선언형 언어는 임무를 실행하는 것 자체가 중요하기 때문에 목표를 명시하되 어떻게 할 지는 중요하지 않으니 알고리즘을 명시하지 않습니다.(What)



Ansible로 어떤 작업을 할 수 있는지에 대한 구체적인 예시 입니다. 앞 세션에서 언급한 내용인데 이번 세션에서 보다 자세히 소개가 되었네요. 가장 많이 활용하는 것은 프로비저닝과 애플리케이션 배포 입니다. 그리고 이 작업들을 실행할 대상은 위와 같습니다. 



이 Ansible을 Open Stack에 적용하기 위한 내용을 살펴 보기 전에 먼저 Open Stack이란 무엇인지 간단히 짚고 넘어가겠습니다.



Open Stack(오픈스택)은 클라우드 서비스의 IaaS를 오픈소스로 제공하는 프로젝트를 말합니다. IaaS를 구성하는 3요소인 컴퓨팅, 스토리지, 네트워크가 Software Defined 즉, 오픈소스 기반의 Software로 관리되며, 과거에 개별적으로 작동했던 이 요소들을 지금은 API로 호출하여 사용할 수 있는 형태라고 보시면 되겠습니다.



이 Open Stack 환경을 구축함에 있어서 네트워크 환경을 구성할 경우 기존에는 테넌트 별로 설정값을 넣어 네트워크를 생성해야 합니다. 이 때 입력하는 설정값이 잘못됐을 경우 통신 에러가 발생하게 되는 것인데요. 이 작업을 코드화 하여 Playbook에 넣고 Ansible로 자동화할 수 있다면 신속하게 네트워크를 생성할 수 있겠죠.



Security Group 생성 시에도 기존에는 그룹 별 복사가 되지 않아 생성하는 다른 그룹마다 새롭게 규칙을 입력해야 했으나 Ansible을 통해 코드를 복사하고 편집하여 그룹 생성 후 손쉽게 적용시킬 수 있습니다.



Open Stack의 VM 인스턴스를 만들기 위한 템플릿인 Flavor 생성 시에도 기존에는 편집이 불가능하기 때문에 이미 만들어 둔 VM 인스턴스의 스펙을 확인해서 다시 똑같은 스펙의 인스턴스를 만들어야 했지만 Ansible을 이용하면  Flavor 템플릿 코드를 편집하여 쉽게 생성하고 재사용까지 가능해 대량의 인스턴스를 빠르게 생성할 수 있습니다.

Open Stack에서 인스턴스를 생성에 코드를 활용할 수 있는 방법은 Ansible이 유일한 것은 아닙니다. Heat와 Terraform이라는 방식도 있는데요. Ansible과 어떻게 다른지 살펴 보겠습니다.



Heat는 Ansible과 동일하게 YAML로 되어 있고 Open Stack에서 제공하는 모든 기능을 활용할 수 있습니다. 하지만 사용법이 좀 어려운 편입니다. Auto Scaling이나 사용량을 체크하는 미터링같은 기능과 연계해서 사용하기에는 Heat가 적합한 반면, 어렵다고 합니다....



Terraform은 tf라는 전용(자체적인 문법을 가진) 선언형 언어를 사용합니다. 이 Terraform은 Opsn Stack 뿐만 아니라 AWS, Azure를 지원하기 때문에 멀티클라우드 환경에 최적화 되어 있다고 보시면 됩니다.




Ansible은 Open Stack의 리소스를 활용하면서 VM인스턴스의 파라미터 설정, 보안설정, WAS의 연결 변경, 추가 패키지 설정 등 OS와 애플리케이션 제어까지 할 수 있습니다. 이를 통해 효준 OS환경을 설정할 수 있게 됩니다. 

위 3가지 유형은 서로 조합해서 사용할 수 있는데, Heat로 Open Stack 환경의 VM인스턴스를 만들고 Ansible로 Playbook을 호출하여 필요한 환경을 손쉽게 구축하는 것이죠.

이제 이 IAC를 어떻게 적용하면 좋은지에 대해서 좀 더 살펴보도록 하겠습니다.



먼저 VM 인스턴스에 직접 접근하기 보다는 코드를 통해서 관리하는 것이 중요합니다. 하나의 서버에 접속해서 어떤 작업을 하면 그 서버는 다른 서버와 모습이 달라지기 때문에 각각의 서버를 모두 개별적으로 하나씩 컨트롤 해야 하는 불편함이 생길 수 밖에 없습니다. 즉, 인스턴스는 모두 동일한 모습(버전, 커널, 패키지)를 유지한 상태여야 관리가 편하다는 것이고, 이를 위해서 코드를 통해서만 제어해야 하는 것이 중요합니다.



그리고 당연하겠지만 코드에 주석을 달고 문서화 시키는 것은 나중에 다시 살펴볼 때, 다른 사람이 작업할 때 매우 중요합니다.



또한 코드를 작성하다가 해당 언어의 버전이 올라가게 되면 반드시 작성중인 코드에 어떤 버전으로 작성된 것인지 표시해야 합니다. 업그레이드 된 버전의 코드로 작성한 결과물에 뭔가 문제가 생겼을 때 이전 버전으로 롤백해야 하는데, 몇 버전으로 돌아가야 하는지 명확하게 알아야 하기 때문입니다.



그리고, 테스트 역시 매우 중요한 부분인데요. Agile 방법론이 떠오르게 되면서 코딩에 있어서도 분업, 협업이 매우 중요해 졌습니다. 하지만 여러 개발자가 각자 알아서 코딩하다가 이를 Commit하고 배포한 뒤 이를 나중에 합치게 되는 경우가 많은데  각 개발자 별로 코딩한 소스코드에 대한 품질관리가 제대로 되어 있지 않기 때문입니다.

이 때문에 테스트 시나리오가 매우 중요합니다. CI(Continous Integration)을 통해 Commit된 소스코드를 검사하여 새로 작성된 혹은 중간에 수정된 코드가 제대로 작동하는지, 문제 없는지 검증합니다. 이런 일련의 과정을 테스트 시나리오로 구축하여 사람의 간섭을 최소화 하고 미리 만들어진 시나리오 대로 테스트 즉, QA를 거쳐 오류를 최소화 시키는 것이 서비스 안정성을 높이는, 그리고 개발자들의 반복적인 업무를 줄이는 지름길이라고 볼 수 있겠습니다.

여기까지 이번 세션 내용 정리를 마무리 하겠습니다.

 
이번 세션에서는 컨테이너 환경에서 Ansible을 어떻게 활용할 수 있는지에 대한 내용이 소개되었습니다. 컨테이너 관리 측면에서 가장 많이 활용되고 있는 Kubernetes와 이 Kubernetes에 기업에서 필요한 여러가지 기능들을 더한 Red Hat OpenShift, 그리고 이 OpenShift에서 Ansible을 어떻게 활용할 수 있는지에 대한 내용인데요. 자세히 보시려면 아래 '자세히 보기'를 클릭 해 주세요.
 

Ansible을 통한 컨테이너 환경 자동화 (OpenShift, Kubernetes) 자세히 보기

마이크로 서비스 아키텍쳐를 위한 컨테이너 운영환경 중 가장 널리 사용되는 Kubernetes(쿠버네티스)는 수동으로 클러스터를 설치하기 위해서는 각 노드별로 필요한 패키지를 설치해야 하는데요. OS에 필수적인 패키지나 네트워크, API, 컨트롤 매니저 등을 수동으로 설치해야 하며, 만약 이 설치하는 패키지의 버전이 상이할 경우 나중에 장애가 발생 하더라도 어디서 생긴 문제인지를 알기 어려운 단점이 있습니다. 즉, Kubernetes 운영 환경을 수동으로 구축해야 합니다.

하지만 Red Hat의 컨테이너 기반 애플리케이션 배포 및 관리 솔루션인 OpenShift에서 제공하는 설치 패키지를 Ansible Playbook을 통해 이용할 수 있는데요. 이 덕분에 Kubernetes 운영 환경을 자동으로 설치할 수 있습니다. 



Docker(도커)를 시작으로 컨테이너 환경이 보편화 되면서 이 수 많은 컨테이너들을 관리해야 하는 솔루션들도 많이 출시되었습니다. 3년전만 하더라도 Docker Swap이나 Apche VESOS, Kubernetes, CLoud Foundry등이 있었으나 지금은 Kubernetes를 가장 많이 사용하고 있습니다. 보시는 것 처럼 많은 글로벌 IT벤더들이 Kubernetes를 차용하여 자사 클라우드 서비스에서 지원하고 있습니다.



OpenShift는 Kubernetes에서 제공하는 많은 기능을 Red Hat이 개량하여 기업용 버전으로 출시한 것이라고 보시면 됩니다. 기본적으로 Open Shift는 Kubernetes를 포함하고 있고, 기업에 맞는 보안과 확장성 등을 추가한 것이 OpenShift입니다.


 기능표로 살펴보면 위와 같습니다. OpenShift는 Kubernetes의 모든 기능을 포함하면서 기업 IT환경에 필요한 부가적인 요소들을 채워 넣은 것이라고 이해하시면 됩니다. 기능차이 외에도 Kubernetes는 대부분의 Linux OS를 지원하지만 OpenShift는 (당연하게도) RHEL(Red Hat Enterprise Linux)만 지원합니다.



OpenShift는 애플리케이션 빌드, 배포, 운영에 필요한 모든 것을 제공하기 때문에 DevOps 환경을 구축할 수 있습니다. 기업환경에 최적화된 PaaS 플랫폼을 제공하며 이미 시장에서 검증된 Red Hat OS와 Jboss같은 미들웨어와 연계해서 사용할 수 있기 때문에 안정적으로 운영할 수 있습니다.

그렇다면 이 OpenShift에서 Ansible을 활용하려면 어떻게 해야 하는지에 대한 내용을 살펴 보겠습니다.



하이브리드 클라우드 환경에 컨테이너까지 더해지면서 마이크로 서비스가 확산 되었습니다. 이 마이크로 서비스에서 중요한 것이 바로 API인데요. 수 많은 서비스들이 서로 데이터를 주고받기 위해서는 API를 이용해야 하는데, 이 API를 표준화 시킨 것이 Open Service Broket API입니다. 이 프로젝트에 많은 기업들과 함께 Red Hat도 참여하고 있습니다.



그렇다면 이 Servicec Broker는 무엇일까요? 사용자가 이용하려는 Service Catalog에서 선택하면 API가 작동하여 서비스 공급자가 사용자에게 서비스를 제공하는 것이 Service Broker 입니다. 



위와 같이 다양한 서비스 공급자들이 자기들의 서비스를 서로 가져다 이용할 수 있는, 교역을 할 수 있는 것이고, 이 교역을 중간에서 처리 해 주는 것이 Service Broker API 입니다. 현존하는 대부분의 클라우드 서비스에서 별도의 마켓 플레이스를 통해 많은 서비스들을 제공하고 있는 것과 유사한 개념이라고 보시면 됩니다.

이것을 OpenShift에서 구현한 것이 Ansible Service Broker 입니다. 



위와 같이 Ansible Service Broker는 OpenShift의 Service Catalog에서 이용하고 싶은 서비스를 선택합니다. 그러면 Ansible Service Broker에서 Ansible Playbook Bundle에서 제공하는 내용대로 컨테이너를 설치, 삭제, 권한부여 및 회수를 할 수 있는 메타데이터를 보유한 컨테이너 이미지를 생성합니다. 

이 OpenShift Ansible Service Broker를 좀 더 쉽게 활용하기 위해 오픈나루에서 만든 것이 KHAN 입니다.



KHAN을 이용하면 위와 같이 개발환경을 손쉽게 구축할 수 있습니다. 세션중에 전자정부 프레임워크를 이용한 개발환경 구축 데모를 시연했는데요. 먼저 egov-apb 파일을 생성하여(총 6단계를 거쳐 빌드) OpenShift Service Catalog에 등록합니다. 이후 OpenShift Service Catalog에서 egov(APB)을 선택하면 Ansible Service Broker에서 컨테이너 이미지를 가져다가 사전에 정의된 Playbook 내용에 따라 컨테이너 기반의 미들웨어들을 설치합니다. 이후 KHAN APM에서 제대로 작동하는 지 모니터링 할 수 있습니다. KHAN에 대한 자세한 내용은 마지막 세션에서 좀 더 자세히 보여 드리겠습니다.

여기까지 이번 세션 내용 정리를 마무리 하겠습니다.

 
이번 세션에서는 오픈소스 IAM솔루션인 Keycloak을 활용해 마이크로서비스 아키텍처에서 SSO를 구축한 사례에 대해 살펴봅니다. 디에스멘토링 이란 회사에서 Keycloak이란 무엇이고 어떤 장점이 있는지, 기존의 SSO인증과 Keycloak의 인증방식은 어떻게 소개 해 주셨는데요. 자세한 내용을 보시려면 아래 '자세히 보기'를 클릭 해 주세요.
 

데모로 이해하는 마이크로서비스 아키텍쳐 환경에서의 SSO 구축 방안 자세히 보기

앞의 세션들에서 마이크로서비스에 대해 여러번 언급 했었습니다. 이번 세션에서는 이 마이크로서비스가 무엇이고 왜 필요하게 되었는지에 대해 좀 더 자세히 살펴보겠습니다.

먼저 마이크로서비스 아키텍쳐를 이해하기 위해서는 모놀리식 아키텍쳐를 이해해야 합니다. 모놀리식 아키텍쳐는 일체형 구조라고도 말할 수 있는데, 하나의 애플리케이션 전체를 하나의 통합된 패키지로 개발하고 배포하는 구조를 말합니다. 일반적으로 우리가 과거부터 사용해 왔던 수많은 애플리케이션들이 이 모놀리식 아키텍쳐를 따르고 있습니다.

애플리케이션 별로 각각 독립적인 하나의 패키지로 개발되기 때문에 표준화 된 형태로 배포, 테스트, 관리가 가능하다는 장점이 있지만 하나의 코드로 작업되기 때문에 어떤 신규 기능을 구현하기 위해 새로운 언어로 코딩하여 붙이기가 어렵습니다. 이 때문에 확장성이 떨어진다는 구조적 한계를 내포하고 있다고도 볼 수 있죠. 그리고 모놀리식 아키텍쳐는 소수의 개발자가 팀을 이뤄 개발하는 형태에 알맞습니다.



그런데 요즘은 하나의 큰 틀을 두고 수 많은 기능을 대량의 개발자가 각자 개발하여 갖다 붙이는 케이스가 많아졌죠. 기능 추가 뿐만 아니라 기존에 개발된 애플리케이션의 구조를 마이크로서비스로 전환하는 사례도 점점 늘어나고 있습니다.(이커머스 영역이 특히 화두입니다.)대표적인 글로벌 .기업으로는 넷플릭스와 아마존이 유명합니다. 보다 자세한 내용은 여기서 확인하실 수 있습니다.

이 마이크로서비스는 기존에 운영하는 애플리케이션의 병렬확장이 가능합니다. 각 기능별로 구분 된 서비스들이 서로 간섭을 받지 않는 구조이기 때문에 하나의 기능으로 애플리케이션 오픈 후 추가 기능을 개발한 뒤 순차적으로 추가하며 배포할 때 활용합니다. 그래서 특정 기능별로 나눠진 대량의 개발자가 동시에 작업하여 애플리케이션에 그 기능을 추가하는 데에 적합합니다.



이 마이크로서비스를 인증과 인가 영역 즉, SSO(Single Sing On)에 적용하면 어떻게 될까요? 애플리케이션을 서비스하는 데에 있어서 이 서비스를 누구에게 쓸 수 있게 해 줄 것이냐에 대한 문제는 아주 중요합니다. 하지만 기존의 모놀리식 아키텍쳐로 개발된 애플리케이션은 하나의 세션으로 인증과 인가를 해 주면 되었기 때문에 그닥 고민거리가 아니었습니다.

하지만 마이크로서비스는 수많은 독립적인 기능들이 개별적인 인증과 인가를 해줘야 하기 때문에 많이 복잡해 졌습니다. 따라서 내부 사용자든, 외부 사용자든 이 많은 기능들을 사용하기 위해 각각 인증과 인가를 받아야 하는데, 이렇게 되면 계정관리 측면에서 사용자를 통합하여 관리할 수 있는 인터페이스가 필요합니다. 물론 SSO를 통해 통합 로그인으로 해결 할 수 있지만 사용자 권한관리도 매우 중요한 요소라서 마이크로서비스에서는 JWT라는 인증 방식을 사용합니다.

JSON형태로 인증토큰을 만들어 인증서버에 대한 부담을 줄여줍니다. 위와 같이 왼쪽의 기존 토큰 인증 방식은 인증서버에서 사용자에게 인증토큰을 발행하면, 개별 기능들이 사용자가 보유한 인증토큰을 확인하여 인증서버에 적합한 토큰인지 판단을 요청합니다. 그러면 인증 서버는 이 토큰이 내가 사용자에게 발행한 것이 맞다고 확인해 주고, 그제서야 개별 기능들은 사용자에게 기능 사용 인가를 해 주는 형태입니다. 즉, 인증서버가 하는 일이 많습니다.

하지만 JWT는 인증서버에서 발행되는 토큰에 개별 기능들과 사전에 약속 된 인증, 인가 정보를 담아서 사용자에게 전달합니다. 이 사용자는 이미 이 인증 관련 정보를 가지고 있는 토큰을 이용하려는 기능에 전달하고, 이 개별 기능들이 자체적으로 사용자의 토큰을 확인하여 사용 인가를 해 주는 형태입니다. 즉, 인증서버에 개별 기능들이 사용자의 토큰 정보를 검증 해 달라고 요청하지 않기 때문에 인증서버의 부담이 줄어듭니다.


이런 JWT 인증 방식은 마이크로서비스에 최적화 된 인증 방식이라고 할 수 있습니다. 그리고 위 장표와 같이 글로벌 상용 SSO솔루션에서 JWT 인증 방식을 지원합니다. 하지만 글로벌 벤더의 솔루션은 비용이 비싸죠. 마이크로서비스를 주로 활용하는 스타트업에서 이런 글로벌 벤더의 솔루션을 구매해서 사용하기에는 비용 부담이 큰 편입니다.

그래서 오픈소스를 사용해 비용부담을 줄여보자는 니즈가 생기게 되었고, 이에 디에스멘토링은 Red Hat KeyCloak을 선택하게 되었다고 합니다. 


위 장표와 같이 오픈소스 SSO솔루션은 많이 나와 있습니다. 대부분 표준 프로토콜을 지원하며 디에스멘토링 내부적으로 테스트 해 본 결과 Keycloak을 선택하게 되었다고 하네요. 이 Keycloak에 대해서 자세히 살펴 보겠습니다.



Keycloak은 2014년에 탄생한 오픈소스 기반 IAM 솔루션으로 사용버전은 Red Hat SSO라는 이름으로 단독으로 판매되지 않고 Red Hat의 미들웨어인 Jboss EAP에 번들로 판매가 되는 형태입니다. SSO, 표준 프로토콜 지원, 권한관리 등 다양한 기능을 위와 같이 지원합니다.



기본적으로 Red Hat Wildfly에 올라가며 사용자관리가 가능한 인터페이스가 있어서 자체 DBMS(MySQL)에서 사용자 정보를 따로 관리할 수 있으며 Keycloak에서 제공하는 통합 로그인페이지가 있지만 커스터마이징하여 사용할 수 있습니다. 더불어 소셜로그인을 지원하고 있는데 이를 통해 소셜로그인에 대한 계정관리를 할 필요 없이 소셜회사들에게 일임한다고 보시면 됩니다.



Keycloak 사용에 있어 가장 중요한 점은 웹베이스 애플리케이션과 호환이 되어야 사용할 수 있습니다. 이를 위해 Client Adapters가 모듈화되어 컨테이너 엔진에 탑재되어 있으며 개별 애플리케이션과 모듈과의 통신은 사전에 정의된 규약을 활용하여 JSON으로 통신합니다.



Keycloak은 앞서 말씀드린 것 처럼 JWT방식의 인증, 인가를 사용하는데, 일반적인 SSO로 동작되는 예시는 위와 같습니다.

브라우저를 통해 제출된 토큰이 콘텐츠에서 가지고 있는 토큰정보와 맞지 않을 경우 Keycloak 서버에서 사용자에 대한 정보를 다시 해당 사용자에게 전달합니다. 이후 이 사용자가 해당 정보를 입력하면 접속 가능한 토큰을 발행 해 주고, 이 토큰을 활용해 사용자는 콘텐츠에게 인증을 받고 이용할 수 있게 되는 것입니다.




이후 Keycloak에 대한 데모가 시연되었는데요. 이 데모에서 사용자 별 권한이 아닌 그룹별 권한을 설정하여 담당자 입장에서 관리포인트를 줄일 수 있었던 것과 소셜로그인 기능을 확인할 수 있었습니다. 위 페이지는 Keycloak에서 기본적으로 제공하는 통합로그인 페이지로, 말씀드렸듯이 기업 환경에 맞게 커스터마이징 할 수 있습니다.



또한 사용자가 발급받은 토큰을 이용하여 위와 같이 어드민 계정으로 로그인을 하면 각 영역별로 접근했을 때 개별적인 메세지를 출력합니다. 만약 Public계정으로 로그인을 하게 되면 Secured나 Admin에 접근 시 접근할 수 없다는, 허용되지 않은 접근이라는 메세지를 보여주게 됩니다. 또한 자가설정이 가능하여 별도의 기능개발 없이 Keycloak을 통해 개인별 설정을 변경할 수 있습니다.

여기까지 이번 세션 내용 정리를 마무리 하겠습니다.

 
이번 세션에서는 후원사 코오롱베니트에서 Ansible의 도입사례에 대해 소개했습니다. 국내에서 Ansible 구축 경험이 가장 많은 곳이 코오롱베니트라고 하는데요. 자세한 내용을 보시려면 아래 '자세히 보기'를 클릭 해 주세요.
 

Red Hat Ansible 사례 소개 자세히 보기

먼저 코오롱베니트의 오픈소스 사업이 소개되었습니다. 보시는 것 처럼 Red Hat의 다양한 솔루션를 기반으로 DB분야에서 MariaDB, mongoDB, 그리고 실시간 데이터 분석 솔루션으로 핫한 엘라스틱 비즈니스를 하고 있는데요. 오픈소스 사업규모가 어느 정도인지는 모르겠지만 아마 B2B IT총판사업을 하는 기업 중에서는 규모가 가장 클 겁니다. 



그럼 구체적으로 사례 이야기를 해보죠. 위 기업의 경우 계열사의 개발 및 테스트 인프라를 제공하는 데에 있어서 서비스 품질 강화를 목적으로 자동화 환경을 고민하기 시작 했습니다. 통상 그룹사에서는 그룹 내 IT인프라를 총괄하는 IT계열사를 두는데요. 그룹사에서 신규 서비스 개발을 위한 개발환경 구축을 요청받아 처리 해 주는 것인데, 이 작업에 리소스가 많이 투여되고 반복적인 작업이 많다보니 자연스레 자동화를 고민하게 된 것입니다. 그리고 향후 그룹 내 IT인프라의 클라우드 전환 계획도 가지고 있었고요.



좀 더 자세히 D기업의 고민을 살펴보죠. 크게 3가지 정도로 나눌 수 있습니다. 개발환경 자원을 배포 즉 프로비저닝 하는 데에 있어서 불편함이 많이 있었고, 한번 배포한 50대 서버에 업데이트 필요 시 50대 모두 수동으로 개별 업데이트를 진행해야 했기에 반복작업에 시간이 너무 많이 소요 되었습니다. 또한 다수의 VM을 관리하고 있었기에 이 VM들의 정보를 파악하고 관리하는 데에 어려움이 많았습니다. 여기서 지연된 시간은 고스란히 비스니스에 악영향을 끼칠 수 밖에 없었습니다.



Ansible을 도입 함으로써 D사는 인프라 구축을 요청한 곳과 운영하는 부서 사이의 커뮤니케이션이 원활해 졌다고 합니다. 코딩되어 자동으로 배포되는 개발환경이기 때문에 사전에 넘겨 준 작업계획서 및 스펙표에 나와있는 그대로 개발환경을 구축할 수 있기 때문이죠. 사람이 작업 하다가 하나 빼 먹으면 다시 요청하고 처리하고 해야 하는데 그럴 일이 없게 된 것입니다. 오류가 줄었을 뿐만 아니라 작업 시간도 많이 단축되었습니다.

그리고 기업에서 많이 사용하는 솔루션 벤더사(VMware, Cisco)가 Ansible 자동화 모듈을 개발하는데에 기여하고 있기 때문에 Ansible 사용에 있어서 현재 인프라 환경에 쉽게 적용시킬 수 있었습니다. 더불어 에이전트 리스로 운영되기 때문에 서버부하가 거의 없어 관리자 입장에서 부담없이 사용할 수 있었던 점도 크게 작용했고요.



에이전트 리스에 대해 좀 더 살펴보면, puppet, CHEF같은 경쟁 도구 대비 벤더종속성을 감소시킬 수 있다는 장점도 있습니다. 만약 에이전트로 작동하는 구조라면 해당 도구의 에이전트가 현재 운영하는 시스템과의 호환성도 따져봐야 하고, 에이전트 혹은 시스템OS가 업그레이드 될 경우 양쪽 환경을 일치시켜야 합니다.

그런데 자동화 도구의 개발언어가 학습하는 데에 어려운 편이라 이러한 작업마저 쉽지가 않습니다. 어렵게 학습했다 하더라도 본인이 사용하는 데에도 벅차기 때문에 다른 팀원들에게 공유할 엄두조차 내지 못하고 꾸역꾸역 혼자 운영만 간신히 하는 상황이 발생하는 사례도 있다고 합니다.(독박운영이라고 할 수 있겠네요.)

하지만 Ansible은 YAML이라는 비교적 쉬운 언어를 사용하여 쉽게 배우고 사용할 수 있습니다. 에이전트 리스 방식이니 특정 OS에 대한 호환성 여부와 관계 없이 작동되며, 자동화 도구 벤더에 대한 종속성 역시 낮출 수 있습니다.
 

앞서 Ansible 코어 엔진은 오픈소스로 무료라고 말씀 드렸습니다. 무료이긴 하지만 YAML 형식의 Playbook을 만들어 CLI를 기반으로 작업해야 하는 불편함이 있습니다. 관리자라면 CLI(Command Line Interface) 보다는 GUI(Graphic User Interface)가 훨씬 편할 테니까요.(개발자는 다를 수 있겠네요.) 이 Ansible을 보다 편리하게 이용하기 위해 GUI환경을 제공하면서 모니터링 및 라이브러리 제어, 배포, 운영을 통합적으로 할 수 있는 도구가 바로 위 장표의 Ansible Tower 입니다. 



Ansible Tower의 또다른 장점은 바로 보안인데요. Ansible 엔진에서는 로그인할 때 마다 접속 계정 정보를 가지고 있는 YAML파일에 계정 정보가 평문으로 노출됩니다. 이를 Tower에서 한번 로그인 한 접속 정보는 자체적으로 암호화 시켜 저장해 둔 뒤 향후 로그인 될 때 마다 미리 저장해 둔 정보를 활용함으로써 계정 정보가 노출되는 위험을 차단합니다.



Ansible 엔진의 버전이 업그레이드 되면서 이제는 Windows 배포 시에도 많은 도움을 받을 수 있게 됐습니다.  2.3 버전에서는 VMware 모듈을 통해 VM배포 YAML을 실행하고 Windows를 사용자 환경에 배포하기 위한 도구인 Sysprep을 실행합니다. 이후 네트워크 환경 설정을 적용한 YAML을 실행한 뒤 배포해야 합니다. 하지만 2.4 버전부터는 VM배포, Sysprep, AD인증, 네트워크 관련 설정을 하나의 YAML파일로 배포시킬 수 있습니다. 여러번 해야 할 반복 작업을 자동화 시켜 주니 관리자 입장에서 편할 수 밖에 없겠죠.



또한 Windows Update역시 자동화 시킬 수 있습니다. Playbook에 업데이트할 대상을 검색해서 그 대상에 필요한 업데이트 내용을 다운로드 받고 적용한 뒤 Reboot을 식행하여 Update를 완료하는 프로세스를 정의하고 Ansible로 실행시킬 수 있는데요. 여기에서 더 나아가 Ansible Tower를 활용해 사용자 접속 정보가 저장된 Excel파일을 Tower에서 불러와 그룹별로 Windows Update를 수행할 수도 있습니다.



위와 같이 개발팀에서 개발환경을 위해 VM 50개를 생성해 달라는 요청을 내부 전자결재를 통해서 받게 되면 Ansible을 활용해 Windows Server 2012 R2 50개를 동일한 스펙으로 손쉽게 배포할 수 있습니다.

기존에 하나 하나 50개의 서버 스펙대로 VM을 생성하고 설정하고 WIndows Server 2012 R2의 최신 업데이트를 받고 레지스트리를 환경에 맞게 세팅하고 각 VM별로 정보를 다른 별도의 공간에 기록하여 관리할 필요가 없게 되는 것이죠. 이 작업량만 해도 어마어마 할텐데, D사는 Ansible을 통해 이러한 리소스 프로비저닝 작업을 획기적으로 단축할 수 있었습니다.




결과적으로 D기업은 Ansible을 통해 진정한 DevOps 환경을 구현할 수 있었습니다. 개발팀에 요청받은 뒤 환경을 구축하고 다시 전달하는 프로세스가 아니라 개발이 필요한 곳에서 바로 환경을 구축하여 자체적으로 운영하며 테스트 해 볼 수 있도록 지원하게 된 것이죠.

또한 Restful API를 활용하여 그룹차원의 전자결재 시스템 개발환경 구축을 자동화 시키고 자체 관리 도구와 연동시켜 관리 했습니다. 이를 통해 기존에 이메일, 전화 커뮤니케이션에 의해 발생되는 휴먼에러를 줄일 수 있어 그룹사 IT서비스의 전체적인 품질을 향상시키는 데에 크게 일조했다고 합니다. 

다른 자동화 도구 대비 훨씬 늦게(2014년)에 런칭 된 Ansible이지만 그 동안 다른 도구 사용자들이 요구했었던 많은 부분을들 모듈로써 구현해 놓은 상태였고, 이 모듈을 글로벌 IT벤더들이 계속적으로 발전시키고 있기 때문에 Ansible의 성능은 다른 솔루션 대비 훨씬 좋은 경쟁력을 갖출 수 있었던 것이죠.



이번 사례는 L생명보험사의 내용인데요. L생명은 정기점검 자동화, 전쟁같은 긴급재난 시 자동으로 운영 인프라의 일시 정지 및 재가 기능을 시험 해 보고 싶은 니즈가 있었습니다. 또한 자체적으로 추진중인 RPA와 병행해서 종합적인 IT인프라에 대한 서비스 품질을 끌어올리고 싶어 했습니다.



이러한 요구조건을 보다 명확히 하고 Ansible로 어느 정도까지 해결할 수 있을지를 노의하기 위해 Red Hat, 코오롱 베니트, 그리고 파트너사와 함께 워크샵을 가졌습니다. 코오롱 베니트는 고객사에서 어떤 요건을 가지고 있어 자동화를 하고 싶은데, 어떻게 해야 할 지 구체적인 컨설팅이 필요할 때 이런 워크샵을 통해 고객사에 가이드를 제공하고, 관련 내용을 10~20페이지 분량의 보고서를 제공하고 있다고 합니다. 

Ansible Starterkit을 통해 바로 업무에 적용할 수 있는 수준의 Playbook 제작과 Ansible 사용 교육도 지원하여 Ansible 저변 확대를 위해 투자하고 있다는군요.

정리해 보면 Red Hat은 기업들의 다양한 IT인프라 관리업무 자동화에 Ansible을 활용할 수 있는 방안을 소개하고 있습니다. 또한 Ansible Tower를 통해 조직에서 시니어라면 Playbook을 만들고 운영하고 관리하게끔 하고, 주니어라면 이미 만들어진 Playbook을 실행 및 배포만 시키게 하는 업무 프로세스를 정립할 수 있게 도와줍니다.

Red Hat은 Ansible이라는 훌륭한 자동화 엔진을 홍보하면서 '이렇게 좋은 자동화 도구인데, 쓰기 불편하시죠? 좀 더 쉽게 사용할 수 있도록 도와주는 Tower를 써 보세요' 라는 비즈니스 전략을 취하고 있는 것이 아닌가 싶습니다.

여기까지 이번 세션의 정리를 마치겠습니다.

 
이번 세미나의 마지막 세션입니다. 이번 세션에서는 앞의 세션에서 많이 언급했었던 마이크로서비스의 확산에 따른 컨테이너 환경의 모니터링에 대해 다룹니다. 클라우드의 영향으로 인프라 관리의 복잡성 및 관리해야 할 대상이 엄청나게 증가했으며 이런 인프라 관리를 위해 높은 수준의 기술력이 요구된다고 말씀 드렸는데요.

여기에 컨테이너 환경까지 더해셔 관리자가 모니터링해야 할 대상은 더 늘어나게 됐습니다. 그렇다면 이러한 환경을 어떻게 효과적으로 모니터링하고 발생된 이슈를 해결해 나갈 수 있을 지 살펴보겠습니다. 자세히 보시려면 아래의 '자세히 보기'를 클릭 해 주세요.
 

컨테이너 환경에서 모니터링 이슈와 해결 방안 자세히 보기

일반적인 IT인프라 환경에서 발생하는 장애 중 아마 가장 빈번하게 발생되는 것은 휴먼에러 일 것입니다. 동일한 작업이라도 사람이 직접 하다가 실수로 설정값을 누락시키거나 잘못 입력하는 등의 휴먼에러로 인해 장애가 발생하게 되는 경우가 상당히 많은데요. 이런 장애 발생 시 찾아낸 담당자는 본인이 한 실수가 아니라고 할 지라도 이미 발생한 장애결과를 가지고 그 당사자의 잘못이라고 탓한들 장애가 해결되는 것도 아니니 참 난감할 것입니다.

또한 변경 이력관리 역시 매우 중요한데요. 언제 어디서 대체 누가 뭘 손댔길래 문제가 생긴 것인지 빨리 알아야 장애를 신속하게 복구할 수 있을 것이고, 이 역시 대부분 휴먼에러로 귀결 될 확률이 높습니다. 만약 휴먼에러가 아니라면 외부 공격이 들어왔을 가능성이 있는데 이는 더 큰 상황으로 번질 수 있을 테고요.

이런 것들을 효과적으로 모니터링할 수 있는 솔루션이 오픈나루에서 만든 KHAN apm 입니다.


KHAN apm을 살펴보기 전에 먼저 왜 컨테이너 환경에서 자동화가 필요한지 살펴 보겠습니다. 마이크로서비스 구조에서는 개별 기능, 즉 서비스가 계속 늘어나면서 미들웨어의(WAS) 구성이 복잡해질 수록 관리하는 데에 많은 시간이 필요하게 되기 때문에 자동화가 필요할 수 밖에 없습니다. 최초에 설정해 둔 환경에 서비스를 추가하기 위해 옵션 추가 요청을 받게 되면 관리자는 그 때 마다 작업이 늘어나게 되는 구조이기 때문이죠.


더욱이 개발자 입장에서는 시간이 곧 돈이기 때문에 한시라도 빨리 개발환경에서 개발하고 테스트를 진행해야 하는데 인프라 단에서 지원이 늦으면 속이 탈 수 밖에 없습니다. 자동화를 통해 이런 기존 환경에 대한 추가 혹은 변경사항이 접수 되더라도 5분~10분 이내에 빠른 대응이 가능해야 하기에 자동화가 필요한 것입니다.



그렇다면 왜 이런 컨테이너 환경에서 모니터링이 중요할까요? 이 컨테이너를 사용하게 되면 개발자는 용도에 맞는 컨테이너를 배포하고 개발해서 테스트 한 뒤 끝나면 폐기합니다. 기존 VM환경처럼 서버상태를 똑같이 유지하며 변경사항을 업데이트 할 필요가 없습니다. 컨테이너 환경은 Code와 Data가 분리되어 있기 때문이죠.

애플리케이션을 배포할 때에도 기존에는 1.0에서 1.1로 업그레이드 할 때 1.0을 두고 1.1 업그레이드 후 1.2로 다시 업그레이드 할 때 1.1을 유지했어야 했습니다. 하지만 컨테이너에서는 업그레이드 할 때 마다 이전 버전은 폐기하고 그 이미지와 동일한 이미지를 다시 재활용하기 때문에 시스템 관리자가 이전 버전에 접근할 수 조차 없습니다. 이는 곧 작업 효율성은 좋아졌을 지 몰라도 컨테이너 폐기로 인해 데이터가 사라지기 때문에 더욱 더 모니터링의 중요성이 증가했다고 볼 수 있습니다.



컨테이너 환경에서의 모니터링을 위해 많이 활용되는 것이 바로 Prometheus(프로메테우스) 입니다. 여기에 Grapana(그라파나)라는 오픈소스 모니터링 툴을 얹어서 사용하는 것인데요. Prometheus는 글로벌 자작 음악공유 사이트인 SoundCloud에서 만든 오픈소스 모니터링 툴 입니다. Kubernetes 뿐만 아니라 애플리케이션, 서버, OS단까지 다양한 대상에서 데이터를 수집하여 모니터링할 수 있는데 이 수집한 데이터의 시각화를 도와주는 Grapana를 활용해 컨테이너 환경에서의 모니터링 환경을 구축할 수 있습니다.

이 Prometheus는 기본적으로 Pull 방식으로 데이터를 수집합니다. 지정한 대상으로 부터 데이터를 Pulling(가져오기)와서 Parsing(쪼개기)한 뒤 시계열 데이터로 저장합니다. 이 Pull 방식의 경우 데이터를 가져올 대상 서버가 항상 데이터를 제공해 줄 수 있는 상태로 대기하고 있지 않다면 Pull 방식을 이용할 수 없는데요. 이럴 때 Push 방식을 이용할 수도 있습니다. 대상서버에서 데이터를 중앙 Prometheus 서버로 보내는 방식입니다.



Prometheus에서는 저장 된 데이터를 PromQL이라는 Prometheus 전용 Query로 조회합니다. 이 PromQL을 RDBMS에 정규식 형태로 입력하여 조회하면 Premetheus에서 간단한 차트를 그려서 보여주는 형태입니다.



지정된 대상으로 부터 Pull 방식으로 데이터를 가져오는 모습입니다. 데이터를 가져와 파싱해서 시계열 데이터로 저장합니다.



하지만 Prometheus는 데이터를 가져오는 데에 최적화 되어 있지 보여주는 것이 전문인 솔루션은 아닙니다. 간단히 차트로 보여주기는 하지만 수집한 방대한 데이터를 좀 더 시각적으로 보기 쉽게 표현을 해야 모니터링도 수월할 수 있겠죠. 그래서 전용 오픈소스 기반 시각화 도구인 Grapana를 사용합니다.

이 Grapana는 별도의 저장소가 없기 때문에 Prometheus같은 데이터 소스를 기반으로 시각화해 줍니다. 총 55개의 데이터 소스를 지원하며 수많은 Grapana 사용자가 이미 만들어 둔 대시보드가 1,646개나 있기 때문에 원하는 대시보드를 선택하여 데이터만 연결하면 바로 이용할 수 있습니다. 또한 시각화 패널을 48개나 지원하며 자유자재로 커스터마이징할 수 있어 내가 보고싶은 나만의 대시보드를 만들 수 있게 해 줍니다.

Grapana를 통해 컨테이너에서 사용하는 CPU, Memory, Network IO, 각각의 Node 별 CPU, Memory, Disk 등 세부 정보를 모니터링 할 수 있습니다.



위와 같이 48개의 패널을 적절히 배치하여 대시보드를 만들 수 있습니다. 말씀 드렸다 시피 이미 만들어진 수 많은 대시보드가 있기 때문에 처음에 대시보드를 구성할 때의 막막함을 조금은 덜어줄 수 있습니다.(아마 이러한 시각화 도구로 대시보드 만들어 보신 분들은 가장 먼저 하시는 게 샘플을 참고하거나 템플릿을 이용해 수정하는 작업일겁니다.)

Grapana는 실시간으로 동작하며 드래그앤드랍으로 손쉽게 제어가 가능하고 줌인줌아웃을 통해 원하는 부분만 쉽게 모니터링할 수 있습니다. 또한 히드토리 추적이 가능하기 때문에 분석에 용이합니다.



하지만 이 Grapana는 서버 OS 및 Kubernetes 관점, 즉 OS관점의 모니터링 도구 입니다. 하지만 실제로 관리자가 주의깊게 살펴봐야 하는 부분은 애플리케이션 영역입니다. Grapana는 애플리케이션에 대한 정보를 모니터링할 수 없습니다. 애플리케이션의 응답 분포도, 지연 트랜잭션 등을 모니터링할 수 없다는 것이 한계입니다.

또한 오픈소스이기 때문에 지속적으로 발전하는 Grapana 관련 내용을 지속적으로 학습해야 하는 것도 부담이며 커스텀 대시보드를 만드는 것 또한 우리 환경에 맞는 대시보드를 만드는 것은 많은 예시가 있다 하더라도 어려운 작업 입니다. 그리고 장애가 발생했을 때 데이터를 추적하고 분석하기 위해 PromQL을 사용해야 하기에 이 전용 Query를 학습해야 하는 부담도 있습니다.



그래서 나온 것이 KHAN apm 입니다. 한국 환경에 대시보드를 구성했고 HTML5 기반으로 제작된 컨테이너 기반의 애플리케이션 모니터링 도구입니다.



위 장표와 같이 컨테이너 환경의 OS에 직접 접근하지 않고도 OS레벨에서 제공하는 지표들을 수집할 수 있습니다. 이를 애플리케이션에서 장애 발생 시 어디에서 발생한 문제이고 어디서부터 추적하여 분석해야 하는지 도와줍니다. 그럼 데모를 통해 좀 더 자세한 내용을 살펴 보겠습니다.



위와 같이 마이크로서비스 환경에서 장애를 추적할 수 있습니다. 대시보드의 좌측에서 보시는 빨간색 부분을 클릭하게 되면 해당 인스턴스로 접근하게 되는데요.



이후 스레드덤프 요청버튼을 클릭하여 덤프 데이터를 수집하여 로그를 살펴볼 수 있습니다. 우측의 코드 화면에서는 개발자가 남겨놓은 메세지 및 주석까지 추적할 수 있어 어디서 장애가 발생 한 것인지 쉽게 추적할 수 있도록 도와줍니다.

또한 인스턴스의 트래픽이 설정해 둔 특정 임계치에 다다르면 자동으로 덤프 데이터를 추출하게 할 수 있습니다. 그리고 이렇게 수집한 데이터를 전문가가 아니더라도 분석할 수 있게끔 Parsing하여 그리드 형태로 표현합니다. 이를 통해 비전문가도 상세한 분석이 가능하도록 도와주며 해당 쓰레드 덤프가 어떤 Request URI에서 호출됐을 때 생성된 URI까지 매핑하여 알려줍니다. 

이런 부분을 알기 위해서는 원래 3초 단위로 3개의 덤프를 떠서 총 9초 동안 3개의 쓰레드가 동일한 모습을 보이는 지 확인해야 하는데 KHAN apm은 여러번 덤프를 뜰 필요 없이 한번의 데이터 수집으로 문제를 분석할 수 있습니다. 그리고 문제가 있는 쓰레드의 하이퍼링크를 제공하여 클릭하면 바로 그 쓰레드로 이동시켜 적절한 조치를 취할 수 있도록 도와줍니다.



그리고 KHAN은 Auto Scaling 환경에서도 작동 하는데요. AWS, Kubernetes, OpenShift, Apache VESOS환경에서도 사용할 수 있습니다.



OpenShift에서 Auto Scailing 기능을 활용해 서버 부하가 증가될 때 마다 컨테이너 POD이 늘어나는 것인데요. 데모를 통해 확인 해 볼 수 있었습니다. 이 Auto Scailing도 인프라 관리 자동화에 있어 매우 중요한 부분이고 이 기능 때문에 클라우드로의 전환을 고려하는 곳도 상당히 많습니다.(실제 제 지인 회사는 이 Auto Scailing 하나보고 클라우드로 옮겨가려고 검토 중입니다.)



위와 같이 CPU의 사용률이 55%가 넘으면 자동으로 확장 되도록 세팅해 두면 임계값 75%에 도달하는 순간 2개 POD에서 1개 POD이 추가됩니다.(Scale Out) 이를 통해 전체 서비스의 부하를 감소시킬 수 있습니다. 만약 부하가 줄어들면 확장된 컨테이너가 자동으로 1개를 줄여 2개로 돌아갑니다.(Scale In)



KHAN은 위와 같이 복잡한 웹클러스터 아키텍쳐에서도 애플리케이션에 대한 모니터링을 할 수 있습니다. 일반적으로 사용자가 웹 애플리케이션에서 데이터를 조회하기 위해서는 외부 방화벽 -> 웹서버 -> 내부 방화벽을 거쳐서 조회해야 하는데 만약 외부 방화벽이 뚫렸다거나, L4나 웹서버에 문제가 생겼다든지, 내부 방화벽이 뚫린 것인지 등 어느 단계에서 장애가 발생했는지 자세히 알 기 어렵습니다. 단순히 사용자가 서비스를 이용하다가 죽었구나 정도만 알 수 있습니다. 모니터링 툴에 아무런 데이터가 수집되지 않으면 문제를 인지할 수 있지만 이렇게 간헐적인 문제에 대해서는 인지하기 어렵습니다.



KHAN apm은 사용자와 동일한 환경으로 브라우저 단에서 특정 지점의 에이전트가 헬스체크를 주기적으로 수행합니다. 외부 방화벽을 거쳐서 DMZ의 L4에 붙거나 L4를 지나서 내부 WAS에 붙어서 헬스체크를 할 수 있습니다. 이를 통해 어느 단계에서 장애가 발생한 것인지 확실히 알 수 있게 됩니다.



또한 이 헬스체크를 실행하는 주기를 설정할 수 있고 장애 발생 시 자동으로 복구하는 에이전트도 만들 수 있습니다.



만약 실수로 DBMS의 테이블을 삭제하게 될 경우 관리자에게 바로 알림이 가게 되며 이 장애를 자동으로 복구할 수 있는 에이전트를 실행해서 복구할 수 있습니다. 이처럼 애플리케이션을 관리자 입장에서만 살펴보는 것이 아닌 사용자 관점에서 헬스체크를 해서 보다 안정적으로 서비스를 운영할 수 있도록 도와줍니다.



만약 관리자가 KHAN apm을 통해 수집한 데이터 분석이 어려울 경우 Quick Service ON이라는 서비스 버튼을 누르면 해당 데이터가 오픈나루로 전달되어 오픈나루에서 대신 분석하여 결과를 알려줍니다. 기본적으로 셀프서비스를 지향하고 있지만 부득이한 경우 솔루션 개발사에서 분석을 도와줄 수 있다는 것으로 보시면 되겠습니다.

여기까지 3월27일에 진행 된  IAC(Infrastructure as Code & DevOps 세미나에 대한 세션 정리를 마무리 하겠습니다. IT인프라 관리자 입장에서 나날이 발전하는 기술때문에 관리포인트가 늘어나는 것 뿐만 아니라 업무마저 빠르게 증가하는데 이렇게 증가하는 업무가 반복적인 것이 많다면, 그리고 사람의 실수를 줄여 낭비되는 시간을 줄이고 장애 발생을 최소화 하고 싶다면 자동화 도구를 사용하는 것이 좋겠죠.

업계에서 가장 인기있다는 것은 그 만큼 많은 사용자로부터 검증받았다고 봐도 좋을 것입니다. 그런 관점에서 본다면 Ansible이 가져다 줄 효용가치는 매우 높다고 할 수 있겠네요. 자동화 라는 것이 인공지능에 고도의 코딩실력을 겸비한 개발자가 있어야 만 할 수 있는 것이 아니라는 것을 이번 세미나를 통해 어느 정도는 이해할 수 있었던 것 같습니다.



컴퓨터는 사람의 반복적인 일을 줄이고 계산을 빨리 하기 위해 발명 되었습니다. 그런데 지금은 컴퓨터로 처리해야 할 일이 너무 많아진 것이 문제죠. 이 때문에 자동화 도구가 발명 되었는데 이 때문에 일자리가 없어지지는 않을까 하는 우려 역시 증가하고 있는 것이 현실입니다. 즉 큰 변혁의 시기에 놓여져 있는데 이를 거부하고 과거로 회귀할 것인가 받아들이고 다른 생존방법을 찾을 것이냐에 대한 고민의 기로에 서 있는 것 같습니다.

Ansible 같은 이런 자동화 도구를 통해 IT관리자의 업무 생산성은 높이고, 절약된 시간을 보다 가치있는 일 혹은 자기계발에 사용할 수 있다면 참 좋겠죠? 일단 솔루션 들은 그런 방향으로 착착 발전되어 나가는 것 같습니다.

그럼, 이것으로 정리를 마치겠습니다. 끝!