Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

클라우드옵스

글로벌 칼럼 | 클라우드 컴퓨팅의 3가지 성공과 3가지 실패

클라우드 컴퓨팅은 이른바 “좋은 놈, 나쁜 놈, 이상한 놈”의 시대를 겪고 있다. 보안과 민첩성은 확실한 성공에 가깝지만, 비용과 복잡성은 심각한 단점이다. 필자는 종종 2008년도 발표자료를 살펴보며 클라우드 컴퓨팅이 약속한 것을 다시 검토하곤 한다. 필자는 1999년부터 이런저런 식으로 클라우드 컴퓨팅 분야에서 일했으며, 그동안 많은 변화를 목격했다. 그리고 가장 큰 변화는 클라우드 컴퓨팅에 대한 인식이다.   초기에 클라우드 컴퓨팅은 애플리케이션을 소비하는 또 하나의 방식 정도로 보였다. 지금은 SaaS라고 불리는 이들 애플리케이션은 영업 관리나 회계, 재고 관리 등의 업무를 맡았다. 클라우드는 그다지 혁명적인 것으로 보이지 않았는데, 사실 이런 식의 애플리케이션 소비는 원시적인 형태이긴 해도 수십 년 전부터 있었기 때문이다. 하지만 스토리지나 컴퓨트, 데이터베이스 같은 원격 자원을 소비할 수 있는 역량, 그리고 애플리케이션의 부분 부분을 필요할 때 필요한 만큼 소비할 수 있는 역량은 새로운 것이었다. 2008년경 클라우드 컴퓨팅을 폭발적인 성장으로 이끈 것은 바로 이것이었다.  이제 많은 기업이 클라우드 컴퓨팅이 어디서 성공하고 어디서 실패했는지 평가할 수 있을 만큼 다양한 종류의 클라우드 컴퓨팅을 충분히 경험했다. 2022년의 끝이 보이는 지금, 필자의 평가는 다음과 같다.   클라우드 컴퓨팅의 주요 성공 3가지 보안. 보안은 5년 전부터 전통적인 시스템보다 클라우드에서 더 좋아졌다. 다만 이를 제대로 알아차리지 못했을 뿐이다. 이런 발전은 대부분 클라우드 보안에 투여된 막대한 연구개발 자금 덕분이다. 단점이라면, 이렇게 혁신에 투여된 비용의 대부분은 전통적인 보안 솔루션을 위한 예산에서 가져온 것이라는 점이다. 기업이 보유한 데이터센터 시스템은 모든 솔루션 업체의 개발 영역에서 점점 뒷전으로 밀려나고 있다. 비즈니스 민첩성. 필자는 항상 비용 때문에 클라우드로 이전한 기업이 민첩성 때문에 계속 클라우드를 이용한다...

멀티클라우드 복잡성 스티커쇼크 2022.09.21

블로그 | 클라우드 비용은 인플레이션 중?

가트너의 2월 보고서에 따르면, 올해 클라우드에 대한 투자가 5,440억 달러에 이를 전망이다. 지난 해보다 21% 증가한 수치이다. 과연 좋기만 한 소식일까? 코로나19 팬데믹은 기업이 IT 인프라를 상대적으로 안전한 퍼블릭 클라우드로 급하게 이전하는 계기가 됐다. 또한 퍼블릭 클라우드 서비스 업체 역시 팬데믹 기간에 맡은 바 임무를 잘 수행했으며, 이제 클라우드는 많은 기업에 필수불가결한 선택지가 됐다.   이렇게 기업 데이터센터가 하나둘 문을 닫는 한편, 스티커 쇼크(Sticker Shock, 예상 이상의 비싼 가격으로 소비자가 받는 충격)를 받은 많은 CFO와 CIO가 클라우드에 비용이 왜 이렇게 많이 드는지 파악하려 애를 쓰고 있다.  많은 경우, 클라우드 여정을 시작할 때 예견된 일이었다. 과연 무슨 일이 일어난 것일까? 가격 인상도 일부 원인이겠지만, 필자가 조사한 예상치 못한 요금 고지서의 대부분은 클라우드 비용 지출에 대한 원칙의 부재와 부적절한 통제 때문이다. 마치 한 여름에 에어컨 온도를 18도로 맞춰 놓고는 전기 요금이 많이 나왔다고 불평하는 셈이다.  최근 발표된 아노도트의 2022년 클라우드 비용 보고서에 따르면, 53%의 기업이 클라우드 비용 낭비의 가장 큰 원인이 클라우드 사용량에 대한 인사이트가 부족하기 때문이라고 답했다. 클라우드 요금에 당황하거나 클라우드 비용과 관련된 소동을 경험한 적이 있다는 응답도 37%를 기록했다.  결론적으로 말해, 비용을 어떻게 추적하고 통제할지를 명확하게 생각하지 않고 무작정 클라우드에 뛰어든 셈이다. 많은 전문가가 클라우드 비용을 감시하고 추적하고 통제할 건강한 클라우드 핀옵스 프로그램이 없다는 점을 지적한다. 현재 가장 근본적인 문제는 요금 고지서를 받기 전에는 클라우드 비용을 거의 파악하지 못한다는 점이다. 핀옵스 프로그램이 있는 기업의 클라우드 비용 관리 점수가 10점 만점에 9점이라면, 이들 기업은 1점이나 2점 정도이다. 사실 대부분 기업이...

클라우드옵스 핀옵스 최적화 2022.09.19

글로벌 칼럼 | 클라우드핀옵스 프로그램에 필요한 3가지

클라우드 컴퓨팅 비용이 전체 IT 비용의 20%에 육박하고 있다. 그리고 클라우드 비용이 낭비되고 있음을 깨닫는 데는 깜짝 놀랄 만한 클라우드 요금 고지서 한 장이면 충분하다. 최근 기업이 클라우드 비용을 한층 더 꼼꼼하게 검사하고 클라우드 비용과 관련해 더 엄격한 원칙을 요구하는 이유이다. 핀옵스(Finops)는 클라우드 비용을 모니터링하고 최적화하는 역량을 제공한다. 이 때문에 어떤 클라우드 배치에서도 큰 비중을 차지하는 요소로 자리 잡고 있다.   핀옵스는 유용하지만, 모든 클라우드 핀옵스 프로그램이 다 똑같은 것은 아니다. 흔히들 놓치거나 잘못 알고 있는 핀옵스 기능에 대해 알아보자. 비즈니스 가치에 대한 이해. 많은 클라우드 핀옵스 프로그램과 사용자는 어떤 식이든 비용을 절감하는 것을 좋다고 생각한다. 더 좋은 결과를 낼 수 있기 때문이다. 하지만 비즈니스 가치 창출을 고려하지 않으면 문제가 생긴다. 일부 클라우드 비용 절감은 의도치 않게 중요한 정성적 비즈니스 가치를 떨어뜨릴 수도 있다. 예를 들어, 핀옵스가 너무 높은 비용 때문에 클라우드 기반 AI 활용을 제한할 것을 권고할 수도 있다. 이들 핵심 시스템이 AI에 대한 투자로 100배의 수익을 올린다는 것을 알지 못한 채 말이다. 이 경우 핀옵스팀이 아낀 0.1달러는 실제로 10달러어치의 실현하지 못한 비즈니스 가치가 된다. 물론, 실현하지 못한 비즈니스 가치의 기준은 정의하기도 추적하기도 어렵다. 핀옵스 프로그램과 핀옵스팀은 클라우드 비용과 절감 방법에 대한 기초적인 이해 이상의 것이 필요하지만, 비즈니스 가치와 특정 비용의 관계에 대한 이해 역시 필요하다. 인적 비용에 대한 고려. 클라우드 비용에 인적 비용 역시 고려해야 하지만, 그렇지 않은 경우가 많다. 만약 클라우드 비용을 삭감한 결과, 같은 효과를 얻기 위해 더 많은 인력과 시간이 필요하다면 부정적인 효과만 얻는 셈이다. 핀옵스팀이 이런 문제를 발견하려면 비용 조정 전후로 같은 비즈니스 프로세스에 인력이 얼마나 드는...

핀옵스 클라우드옵스 비즈니스가치 2022.09.15

서비스나우 하이퍼 AI옵스가 하이브리드 클라우드 운영의 게임체인저인 이유 - Tech Summary

클라우드 도입 단계를 넘어 확산 단계에 이른 가운데, 다수의 기업들이 여러 현실적인 클라우드 운영 문제를 해결하려 모색하고 있다. 클라우드옵스, AI옵스라고 불리는 기술 트렌드에 대한 관심이 자연스럽게 늘어난 배경이다. 그러나 데이터를 활용한 운영 자동화라는 현실은 그리 녹록치 않다. 파편화된 서비스, 파편화된 데이터, 파편화된 도구로 인한 한계 때문이다. 단일 플랫폼, 단일 데이터 모델, 단일 아키텍처에 기반하고 AI 머신러닝 엔진을 탑재한 서비스나우의 ‘하이퍼 AI옵스'에 대해 알아본다. 주요 내용 AIOps에 쏠리는 관심, 그러나… 복잡한 클라우드를 관통한다··· 서비스나우의 하이퍼 AI옵스 제안  -> 서비스나우 하이퍼 AI옵스의 6가지 프로세스 AI 엔진 기반 단일  AIOps 플랫폼 + ITSM과 ITOM 솔루션의 시너지

서비스나우 클라우드옵스 AI옵스 2022.06.17

"클라우드의 가치를 100% 실현한다" 클라우드옵스 안내서

소프트웨어 제품의 개발에 관여한 적 있다면 ‘데브옵스’라는 말에 익숙할 것이다. 소프트웨어 개발과 IT 운영을 결합한 일련의 관행인 데브옵스는, 개발 수명 주기를 단축하고 지속 배포 및 고품질 제품을 공급하는 것을 목표로 한다. 클라우드 운영과 연관된 개념인 ‘클라우드옵스(CloudOps)’는 기업들이 애플리케이션 개발과 워크로드를 클라우드로 점점 더 이전하면서, 그리고 클라우드 비용이 한층 복잡해지면서 출현했다. 클라우드옵스가 무엇이고, 조직에게 어떤 혜택을 줄 수 있는지, 그리고 기업 내에서 클라우드옵스를 구현할 때 유념해야 할 점은 무엇인지 살펴본다.   클라우드옵스란?  클라우드옵스는 클라우드 환경에서 실행되는 IT 서비스와 워크로드의 전달, 최적화 및 성능을 관리하는 운영 프랙티스이다.  기업이 멀티클라우드, 하이브리드 클라우드, 또는 프라이빗 클라우드 전략을 운영함에 있어 클라우드옵스는 클라우드 기반 프로세스를 위한 절차 및 베스트 프랙티스를 확립하기 위해 구현된다. 이는 데브옵스에 의한 애플리케이션의 개발 및 배포와 비슷한 성격을 가진다. 클라우드 운영을 위한 다계층 프레임워크  컨설팅 기업 캡제미니 아메리카스(Capgemini Americas)의 부사장이자 클라우드 우수성 센터의 책임자인 제이슨 해치는 “기업이 자사 클라우드 생태계의 여러 측면을 전반적으로 관리하는 데 도움을 주는 여러 계층으로 된 프레임워크가 클라우드옵스(Holistic CloudOp)의 큰 그림이다”라고 설명했다. 프레임워크 계층 중 하나는 거버넌스 계층이다. 여기에는 클라우드 비용을 제어하고 예산을 관리하는, 핀옵스(FinOps)라고도 알려진 재무 업무 등의 활동을 포함한다. 해치는 “거버넌스 계층에는 무엇이 어떻게 클라우드에 배치될 수 있는지에 관한 아키텍처 표준이 담겨 있어야 한다. 또 이들 표준을 프로그램적으로 강제하는 방법을 있어야 한다”라고 말했다.   다른 프레임워크 계층으로는 클라우드에서...

클라우드옵스 데브옵스 클라우드 최적화 2022.05.27

블로그 | '선제적' 클라우드 옵스, 실제로 얼마나 유용할까

선제적(Proactive) 옵스 시스템이 많은 장점을 가진 것은 분명하다. 문제가 파괴적인 상황에 이르기 전에 사람의 개입 없이 문제를 해결한다. 예를 들어 AI옵스 툴 같은 옵스 관측 툴이 스토리지 시스템이 일시적인 I/O 문제를 유발하는 것을 확인했다고 하자. 이는 곧 스토리지 시스템이 조만간 심각한 장애를 일으킬 가능성이 크다는 것을 의미한다. 이런 상황에서는 미리 정의된 자동 회복 프로세스를 이용해 데이터를 자동으로 다른 스토리지 시스템으로 옮기고, 시스템은 작동을 멈춘 후 유지보수가 필요한 장비로 분류한다. 다운타임은 발생하지 않는다.   이런 형태의 선제적 프로세스와 자동화 작업은 매시간 수천 번 실행된다. 클라우드 서비스와 애플리케이션, 네트워크 또는 데이터베이스에서의 장애로 인한 서비스 중단이 줄어든 것을 보고서야 이런 작업이 작동 중임을 알 수 있을 뿐이다. 다운타임을 '0'에 가깝게 줄이는 데 있어 이런 기술은 큰 도움이 된다. 그러나 모든 기술에는 장점이 있으면 단점도 있기 마련이다. 전통적인 대응적 옵스 기술은 단순하게 작동한다. 장애가 발생하면 그 이후에야 문제를 해결하기 위해 관리자에게 알리는 등 일련의 이벤트를 시작한다. 무언가 서비스가 중단되면 근본원인을 빠르게 찾아 자동화된 프로세스 혹은 수작업 패치를 통해 수정한다. 이런 대응적 옵스의 약점은 다운타임이다. 대부분의 경우 완전하게 작동을 멈추기 전까지 문제가 있음을 알지 못한다. 보통 스토리지 I/O 등 리소스와 서비스에 대한 세부적인 부분을 모니터링하지 않고, 작동하는가 혹은 작동하지 않는가 오직 가부에만 집중한다. 필자는 클라우드 기반 시스템에서 다운타임이 발생하는 것을 원치 않으므로, 대응적 옵스는 선제적 옵스와 달리 피해야 할 것처럼 보인다. 그러나 필자가 경험한 많은 경우 선제적 옵스 툴을 구매해도 이 툴의 관측 시스템은 선제적 자동화에 필요한 상세한 정보를 제공하지 않을 가능성이 크다. 그 이유는 다음과 같다. 스토리지와 컴퓨트, 데이터베이스...

클라우드옵스 2022.05.23

블로그 | 당신의 클라우드옵스 계획은 너무 늦었다

필자는 종종 워터폴 소프트웨어 개발 라이프 사이클 시대를 떠올린다. 당시엔 각 작업이 개별적으로 시작해 종료됐다. 한 작업이 끝난 결과물이 다른 문서화나 코드의 시작점이었다. 시간이 오래 걸리는 개발 방식이었고 방향을 바꾸기가 사실상 불가능했지만, 관련된 다른 계획을 세우기에는 훨씬 수월했다.   하지만 그런 시절은 끝났다. 오늘날 클라우드 개발 혹은 동시 개발 방식에서는 반복적이고 민첩하게 작업이 진행되고 언제든 방향을 바꿀 수 있다. 매우 강력한 데브옵스 툴 체인을 통해 자동화되면서 유동적인 개발 방식이 만들어졌다. 이런 변화는 올바른 방향이라고 생각한다. 하지만 동시에 일부 악화한 부분이 있다. 운영 계획이 대표적이다. 개발이 끝날 때까지 마치지 못하는 경우가 비일비재하고 아예 시작하지 못하기도 한다. 개발자는 코드와 데이터 구조를 운영팀에 넘기고 운영팀은 이를 장기적으로 잘 운영할 방법을 빠르게 찾아야 한다. 그런데 현실적으로 많은 운영 혹은 클라우드옵스 담당자가 현재 공석이다. 이 자리가 점점 기피 IT 업종이 되고 있기 때문이다. 그러나 운영 계획은 반드시 개발 과정의 초기, 최소한 설계 단계에서 시작돼야 한다(보안과 거버넌스 계획 역시 이 단계에서 함께 고민해야 하지만 여기서는 이 부분은 논외로 한다). 운영 계획을 개발 초기에 세워야 건강한 운영 관행이 시스템에 녹아들어 갈 수 있다. 새로 만든 시스템이든 클라우드로 이전한 시스템이든 마찬가지다. 이렇게 해야 프로세스와 스토리지 시스템이 장애나 성능, 사용성 등 일반적인 운영 문제를 겪을 수 있는 가능성을 줄일 수 있다. 운영 계획이 부실하거나 아예 없으면 문제에 직면할 가능성이 커지는 정도가 아니다. 개발팀에 다시 코드와 데이터 구조를 돌려보내기 전에 상당히 많은 문제에 고통받는다. 필자가 개발자와 애플리케이션 디자이너, 아키텍트 등에게 코드를 작성하거나 전환하기 전에 운영 계획을 먼저 마련하라고 하면 그들은 마치 필자가 에베레스트산을 오르라고 한 것 같은 표정으로 쳐다본다....

클라우드옵스 데브옵스 ops 2022.05.18

IDG 블로그 | "뻔하지 않은" 클라우드 컴퓨팅 예측 2가지

매년 12월이면 필자의 받은 편지함에는 홍보회사에서 보내온 메일이 한가득이다. 모두 클라이언트에서 내놓은 내년 전망을 홍보하는 메일이다. “내년에도 클라우드 보안은 CIO의 우선순위 목록에 있을 것”이라는 메일을 몇 통이나 받았는지 모른다. 너무도 당연해서 말할 필요도 없는 것들이다. 그런 면에서 2022년 클라우드 예측의 많은 수가 똑같이 바보 같다.   하지만 현실 세계에서는 이렇게 평범한 예측은 아무런 도움이 되지 않는다. 가치 있는 예측은 클라우드 컴퓨팅의 세부적인 측면에 초점을 맞춘다. 기업이 운영이나 개발, 거버넌스, 보안 등등 구체적인 기술을 구현하면서 IT 책임자는 어떤 변화가 일어날지, 해당 기술의 잠재력은 어느 정도인지 알아야만 한다. 필자의 클라우드 컴퓨팅에 대한 예측이 극히 좁은 영역에 중점을 두고자 하는 이유이다. 필자의 2022년 클라우드 예측은 거버넌스와 클라우드옵스에 관한 것이다. 거버넌스. 멀티클라우드의 부상과 클라우드 복잡성 문제를 키우는 변화가 2022년에도 계속될 것이다. 거버넌스는 과도하게 복잡해진 클라우드 플랫폼을 통제해야 하는 기업의 중점 사항이 될 것이다. 그렇다고 거버넌스 전반이 집중 조명을 받지는 않을 것이다. 좀 더 우선순위가 높은 문제이자 이미 많은 기업이 직면해 있는 문제에 중점을 두게 될 것인데, 바로 비용 거버넌스이다. 재무 운영, 즉 핀옵스(FinOps)와 연관되기 때문이다. 2021년 대부분 대기업에서 클라우드 비용은 통제를 벗어났다. 클라우드 서비스 업체가 가격을 올린 것도 아니었다. 하지만 클라우드 서비스를 사용하는 직원이 책임을 지지 않았다. 다수의 비용 거버넌스 솔루션이 누가 언제 어디서 왜 어떻게 클라우드 서비스를 소비하는지 지켜보는 일을 훌륭하게 해낼 수 있다. 이들 툴은 훌륭한 보고서와 대시보드도 제공한다. 하지만 안타깝게도 핵심적인 문제를 처리하지 못하는데, 바로 동적인 반응과 대응 기능이다. 예를 들어, 쓸모 있는 시간을 넘어서 실행되고 있는 클라우드 서비스나 적절한 ...

멀티클라우드 복잡성 거버넌스 2021.12.20

IDG 블로그 | 클라우드옵스의 벽에 부딪혔을 때 해야 할 일

신임 CIO의 수요일 아침 9시. IT 운영 책임자와 긴급 줌 회의를 갖는다. 화면에 나타난 얼굴은 침울한 표정이며, 이유는 회의의 목적을 설명하면서 분명해진다. IT 운영팀은 올해 100만 달러의 예산을 받았는데, 예기치 않은 비용 때문에 40만 달러를 초과 사용해야 할 것으로 보인다. 최근 퍼블릭 클라우드로 이전한 일군의 애플리케이션과 데이터베이스를 운영하는 데 필요한 운영 인력과 툴 때문이다.   무슨 일이 일어난 것일까? ‘클라우드옵스의 벽(Cloudops wall)’에 부딪힌 것으로 보인다. 클라우드에 배치한 시스템 운영 비용을 20~30% 낮게 잡은 것이다. 많아도 온프레미스 시스템보다 10% 더 잡은 정도일 것이다. 실제로 업계에서는 운영 비용이 줄어들 것이라고 말한다. 하지만 현실은 몇 가지 일이 일어나기 마련이다. 첫째, 코로나19 팬데믹으로 많은 기업이 다음에 이전할 계획이었던 시스템을 클라우드로 옮겼다. 처음에 옮기지 않은 것은 더 복잡하고 설계도 좋지 않았기 때문이다. 게다가 이들 시스템은 새로운 방식으로 동작한다. 예를 들어, 데이터를 소비하는 클라우드 기반 데이터베이스는 같은 데이터센터에 있는 전통적인 데이터베이스와는 다르다. 둘째, 클라우드 마이그레이션이 속도전으로 이루어졌기 때문에 많은 실용적인 단계를 압축하거나 건너뛰었다. 클라우드 네이티브 서비스를 이용하는 데 필요한 리팩터링이나 일부 이전 시스템의 컨테이너화도 빼먹고 더 빠르고 저렴한 리프트 앤 시프트 프로세스를 선택했다. 마지막으로, 가장 중요한 문제는 회사 내의 누구도 이런 종류의 시스템을 대상으로 클라우드옵스를 수행해 본 적이 없다는 것이다. 예를 들어, 메인프레임 기반 시스템을 퍼블릭 클라우드 이전하는 것은 조금 더 현대적인 LAMP 스택을 이전하는 것과는 아주 다르다. 이런 기술력이 없다 보니, 계획 수립의 대부분이 어림짐작으로 이루어질 수밖에 없다. 클라우드옵스의 벽 문제를 바로잡는 몇 가지 방법을 소개한다. 첫째, 클라우드로 이전할 때 리팩...

클라우드옵스 리팩터링 최적화 2021.09.15

IDG 블로그 | 클라우드옵스 기술이 해야만 하는 6가지

클라우드옵스(CloudOps)가 무엇인지는 아직도 정의 중이며, 핵심 문제를 해결하는 데 필요한 기술이 무엇인지도 마찬가지이다. 이럴 때는 다른 모든 클라우드 컴퓨팅 환경과 마찬가지로, 현재 동작 중인 클라우드옵스 솔루션을 핵심 구성요소로 분해해 보는 것이 도움이 된다. 또한 어떤 기술이 어떤 가치를 가져오는지를 정의해 보는 것도 좋다. 이를 위해 클라우드옵스 툴이라면 반드시 갖춰야 할 역량 6가지를 뽑았다.    데이터를 관찰하고 모은다. 추가 분석과 실행을 위한 패턴을 찾는 데 필요하다면, 규모와 관계없이 많은 시스템으로부터 데이터를 모으고 관찰해야 한다. 여기에는 몇 가지 구성요소가 포함되는데, 커넥터나 에이전트를 이용해 관리 하의 시스템과 커뮤니케이션하는 기능, 안정적인 방법으로 일부 중앙화된 클라우드옵스 시스템으로 데이터를 되가져오는 기능 등이 필요하다. 유의미한 방식으로 대량의 시스템 데이터를 연계한다. 여기에는 데이터의 소스와 같은 패턴을 판단하는 기능이나 심도 있는 분석을 하기 전에 데이터를 그룹으로 묶는 기능 등이 필요하다. 문제와 근본 원인을 판단하기 위한 패턴을 분석한다. AI옵스나 범용 클라우드옵스 툴이 실제로 비용을 절감하는 중요한 요소이다. 취합하고 연계한 데이터에서 패턴을 찾아내고, 고장 난 네트워킹 장비와 같은 현재의 문제를 알려주는 패턴을 판단할 수 있어야 한다. 더 나아가 발생할 가능성이 큰 문제를 예측한다. 선제적인 클라우드옵스는 큰 문제가 발생하는 것을 막을 수 있다. 예를 들어, I/O 오류가 나고 있는 클라우드 스토리지 시스템을 파악할 수 있는데, 이런 오류는 장애가 임박했다는 것을 나타낸다. 데이터 관찰을 통해 발견한 것을 운영팀과 공유한다. 프로세스도 자동화해 자동으로 대응하고 문제를 바로잡아야 한다. 하나는 뭔가 잘못되고 있다는 것을 알려주는 것이고, 나머지는 이 과정에서 오류를 바로 잡을 사람에게 확실히 알려지도록 하는 것이다. 빠르게 발전하고 있는 자동화된 티켓팅 시스템이나 자체 치유...

클라우드옵스 관찰가능성 자동화 2021.06.30

IDG 블로그 | 멀티클라우드에 가장 효과적인 클라우드옵스 툴

AI옵스 툴을 포함한 클라우드옵스 툴이 주목받고 있다. 이 영역에는 기본적으로 세 가지 선택지가 있다.    온디맨드 방식의 비네이티브 툴(옵션 1)은 호스팅 서비스에서 구동하는 AI옵스 툴 대부분이 포함된다. 툴 선택지가 넓고 다양해서 가장 선호하는 배치 모델이다. 온프레미스 시스템을 더 많이 모니터링하고 제어해야 한다면, 온프레미스 호스팅 방식(옵션 2)을 사용하는 것이 좋다. 이 방식은 데이터가 개방된 인터넷을 통해 중앙 호스팅 서비스로 다시 흘러갈 필요가 없기 때문이다. 때로는 운영 툴을 양쪽에서 구동하는 것도 설득력 있는 방식이 될 수 있고, 일부 툴은 이런 배치 환경을 지원하기도 한다. 확실한 툴이라면, 어떻게 배치하는지는 문제가 되지 않을 것이다. 클라우드 네이티브 툴(옵션 3)은 특정 퍼블릭 클라우드 서비스 업체가 보유한다. 자사의 네이티브 클라우드 서비스를 모니터링하고 제어하기 위해 만든 툴이지만, 다른 클라우드의 서비스도 운영할 수 있다. 멀티클라우드 환경을 위한 이런 지원은 멀티클라우드 구성이 증가하고 있는 기업에는 합리적인 선택이다. 하지만 이런 툴이 가진 현재의 역량은 물론, 앞으로 멀티클라우드 배치가 점점 더 복잡해지고 이기종 환경이 될 미래의 요구를 만족할 수 있는지도 생각해야 한다. 필자는 현재 시점에서는 네이티브 툴을 사용하는 것은 좋은 선택이라고 본다. 대부분 기업은 여러 클라우드 서비스 업체를 배치할 때 80/20 법칙을 적용한다. 즉 80%의 애플리케이션과 데이터는 특정 클라우드에 두고, 나머지 20%를 다른 여러 클라우드에 배치하는 것이다. 예를 들어, 마이크로소프트 애저 클라우드에 80%, AWS에 15%, 구글 클라우드에 5%를 배치하는 식이다.  이 때문에 특정 클라우드의 네이티브 운영 툴을 사용하면, 중심이 되는 클라우드 네이티브 서비스를 더 잘 관리할 수 있으면서 다른 퍼블릭 클라우드를 지원하는 멀티클라우드 툴로도 활용할 수 있다. 운영에 어떻게 접근하느냐에 따라 여러 가지 툴...

클라우드네이티브 클라우드옵스 AI옵스 2021.06.23

IDG 블로그 | 클라우드 운영은 100% 자동화할 수 있는가?

자동화가 발전하고 인간이 프로세스에서 물러나면서 몇 년 내에 거의 100%의 클라우드옵스 및 섹옵스 자동화를 이룰 수 있을 것이다. 여러 프로젝트를 진행하면서 눈에 띄는 동향이 있다. 바로 AI옵스나 보안 운영 플랫폼 같은 운영 툴을 이용해 클라우드, 하이브리드 클라우드, 멀티클라우드 배치를 선제적으로 운영하는 데 필요한 대부분을 자동화하는 것이다. 이는 일상적인 관리와 모니터링 작업부터 문제 해결을 위해 서버를 끄고 켜는 작업까지 모든 것을 자동화하는 것을 의미하며, 머신러닝이 주로 사용된다. 바로 AI옵스의 AI이다.   아직 운영 인력을 재교육할 준비가 된 기업은 없지만, 원인 진단이나 자율 치유 프로세스, BCDR 영역은 확실히 발전하고 있다. 클라우드 운영 엔지니어의 일상을 채우는 다른 서비스도 사람에게 맡기는 것보다 더 안정적으로 만들기 위해 자동화할 수 있다. 우리는 현재 학습 능력이 있는 툴을 다루고 있으며, 이들 툴은 운영 경험을 쌓을수록 좋아질 것이고, 결국에는 사람보다 일을 더 잘할 수 있을 것이다. 클라우드옵스 자동화는 자율 주행과 비슷하다. 이 기술이 자동차를 운전할 수 있다는 것을, 아마도 사람보다 더 잘 운전할 수 있다는 것을 알지만, 여전히 두렵게 느껴진다. 클라우드옵스 자동화는 자동차 운전보다 훨씬 복잡하지만, 여러 문제 중 많은 수가 극복될 것이다. 결국에는 클라우드를 더 잘 운영할 수 있는 자동화된 프로세스가 구현될 것이고, 위험을 사전에 인지하는 보안 시스템은 날이 갈수록 좋아질 것이다. 그렇다면 우리는 클라우드옵스 자동화를 기꺼이 받아들일 수 있을까? 운전대에서 손을 놓을 수 있을까? 필자는 이들 기술이 폭넓게 채택되는 데 3~5년이 걸릴 것이라고 생각한다. 대기업이 워크로드의 20~30%를 퍼블릭 클라우드로 이전하는 데 10년이 걸렸다는 점을 고려하면, 생각보다 오래 걸릴 수도 있다. 클라우드옵스와 섹옵스 자동화의 결정적인 성공 요인은 전통적인 방식, 즉 사람보다 훨씬 나은 성과를 가져다주는 것이다....

클라우드옵스 섹옵스 AI옵스 2021.06.07

IDG 블로그 | 다시 사무실로 돌아와 클라우드를 사용하는 방법

우리는 지난 해부터 코로나19 팬데믹을 겪고 있지만, 언젠가는 이 사태가 종식될 것이라는 사실만은 확실하다. 원격 근무는 원래 코로나19 팬데믹에 대한 대응으로 등장한 것은 아니다. 여러 해 동안 다양한 용도로 사용되었고, 그 중 하나가 일정 기간 동안 많이 사용된 것이다.    여러 측면으로 볼 때, 기업은 알지 못하는 사이에 99%의 원격 근무를 준비하고 있었다. 클라우드 컴퓨팅 프로젝트를 완료했거나 진행 중인 기업은 자사 비즈니스의 위험성이 자체 데이터센터에 시스템을 배치했을 때보다 몇 배는 낮아진 것을 알 수 있다. 봉쇄 조치가 내려지면서 일부 데이터센터에는 물리적인 접근이 제한되었고, 많은 시스템이 물리적으로 유지할 수 없게 되면서 장애가 일상화되기도 했다. 이로 인해 퍼블릭 클라우드 사용에 무조건 반대하던 사람들이 입을 다물었다. 필자는 너무나도 완고하던 CIO들이 지난 여름을 지나면서 마음을 바꾸는 것을 봤다. 퍼블릭 클라우드 매출의 성장세를 보면, 이런 변화가 일시적인 유행이 아니라는 것을 알 수 있다. 급격한 패러다임 변화라고 봐야 한다. 이제 우리가 처리해야 할 다음 위기는 사무실로의 복귀가 될 것이다. 위기가 아니라고 생각하는가? 이전과는 사용 패턴이 또 한 번 달라진다. 한때 직원을 노트북이나 휴대폰과 함께 집으로 보냈을 때 즉각 대응이 필요했던 것처럼, 이들 직원이 다시 물리적인 사무실로 돌아오는 것도 잘 수용해야만 하기 때문이다. 그렇다면, 바뀌는 것은 무엇일까? 첫째, 기업이 사무실 공간을 없애고 임시 공간을 사용할 수 있다. 직원은 사무실 건물에 출근해서 자리와 회의실을 예약하고 할당된 곳에서 일해야 한다. 네트워크 트래픽과 클라우드옵스도 이런 사무실에서 다시 관리해야 할 필요가 있는데, 이번에는 시간대에 따라, 요일에 따라 사용자가 많이 달라질 것이다. 둘째, 직원의 이동성이 커진다. 코로나19 팬데믹 기간에 직원은 집에서만 일했다. 하지만 규제가 걷히고 사람들이 맘대로 외출할 수 있으면, 원격 근무...

사무실 복귀 클라우드옵스 2021.02.03

IDG 블로그 | 멀티클라우드 프로젝트를 망치는 2가지 실수

어떻게 보면 멀티클라우드는 쉽다. 그저 하나 이상의 퍼블릭 클라우드를 배치하고 관리하면 된다. 하지만 안타깝게도 지금까지 그렇게 간단하지 않았다. 많은 기업이 멀티클라우드 아키텍처를 배치하면서 몇 가지 하지 않아도 될 실수가 계속 저질러지고 있기 때문이다. 약간만 이해한다면, 충분히 피할 수 있는 실수 두 가지를 소개한다.   클라우드옵스를 염두에 두지 않고 멀티클라우드를 설계하고 구축한다. 많은 기업이 이런 멀티클라우드 아키텍처를 장기적으로 어떻게 관리해야 하는지 명확한 이해없이 두세 곳, 때로는 그 이상의 퍼블릭 클라우드를 배치한다.  멀티클라우드 배치가 프로덕션 환경으로 옮겨질 때면 엄청난 수의 클라우드 서비스가 된다. 여러 퍼블릭 클라우드에서 리던던시를 위한 서비스를 이용하면서 생겨난 것들로, 클라우드옵스팀이 모두 처리하기에는 너무 많다. 클라우드옵스팀은 이 모든 서로 다른 클라우드 서비스를 운영하지도 못하고 운영해서도 안되며, 서비스 품질도 엉망이 된다. 보안과 거버넌스 관점에서도 이런 배치는 너무 위험한 방법이 아닐 수 없다.  이런 실수를 피하는 방법이 있다. 우선, 운영상 필요조건을 기꺼이 갖출 생각이 없다면, 멀티클라우드를 하지 않는 방법이 있다. 단일 클라우드 배치를 고수하는 것이 좋다. 물론 이렇게 하면 최고의 서비스만 골라 쓸 수 없고, 클라우드의 가치도 줄어든다. 올바른 접근법은 거의 모든 것을 자동화하고 추상화를 이용해 복잡성을 관리하는 것이다. 모든 것을 클라우드 네이티브로 선택한다. 여러 퍼블릭 클라우드에 걸쳐 사용할 수 있는 툴이 가장 유용하다는 것을 잊지 말기 바란다. 한 클라우드에서 사용하는 인터페이스와 자동화를 멀티클라우드 환경의 다른 클라우드에서도 사용할 수도 있다. 더 이상 확실할 수 없는 선택 같지만, 멀티클라우드로 이전하는 많은 기업이 특정 퍼블릭 클라우드가 제공하는 네이티브 툴을 고수하고 있다. 특정 퍼블릭 클라우드를 위한 관리 및 모니터링 툴을 선호하는 기업은 각각의 퍼블릭 클...

멀티클라우드 클라우드옵스 자동화 2020.12.31

IDG 블로그 | 클라우드옵스가 잘 안되는 이유

클라우드 운영, 즉 클라우드옵스(CloudOps)는 클라우드 컴퓨팅 마이그레이션과 개발에서 장기전에 해당하는 부분이다. 클라우드 기반 솔루션을 배치한 직후부터 시작되며, 이후로 긴 시간 클라우드를 운영한다. 또한 클라우드옵스는 마이그레이션이나 개발 프로젝트의 성공은 물론, 사용자와 고객 경험의 성공도 좌우한다.   그런데 현재 클라우드옵스에서 몇 가지가 잘못되고 있어 주의가 필요하다. 첫째는 관리부터 모니티링까지 운영 툴이 너무 많다. 이렇게 많은 툴은 운영상의 복잡성을 만들어낸다. 또 다른 문제는 기업이 클라우드옵스를 추진하는 데 필요한 자원을 과소평가한다는 것이다. 클라우드 마이그레이션 대부분은 서로 다른 멀티클라우드 배치로 옮기는 것이기 때문에 그동안의 관리보다 세 배의 자원이 필요하지만, 운영 인력의 규모는 똑같은 상태로 남아 있다. 셋째는 여러 클라우드에 걸쳐 사용할 수 있는 보안 솔루션이 없다는 것이다. 보통 각 퍼블릭 클라우드가 제공하는 네이티브 클라우드 서비스는 확장할 수 없다. 여기서 위험과 취약점이 나타나기 시작한다. 보안은 나중에 추가하는 것 이상의 관심이 필요하다. 이 세 가지 문제를 한 번에 하나씩 시간을 들여 생각하는 동시에, 공통적이고 총체적인 솔루션을 찾아야 한다. 다음과 같이 몇 가지 해법을 제시한다.  운영 작업과 툴의 공통성을 모색한다. 운영의 복잡성을 줄이기 위해 상당수의 툴은 표준화해야 한다. 여러 클라우드와 플랫폼에 적용하는 공통 보안 툴과 AI옵스 툴 등의 공통 관리 및 모니터링 툴이 필요하다. 약간의 계획만으로도 클라우드옵스 툴의 수는 절반으로 줄일 수 있다. 툴 수를 줄이면 위험성도 낮아지고 운영을 위해 필요한 인력도 줄어든다. 하지만 간단하지는 않다. 이 접근 방식은 운영 프로세스와 원칙을 바꿔 놓을 것이다. 목표는 가장 적은 수의 툴과 인력이 필요한 가장 최적화된 솔루션을 찾는 것이다. 동시에 솔루션을 통해 운영의 효율성과 가동시간을 높여야 한다. 이런 공통성 접근법을 진지하게 받아들...

클라우드옵스 공통성 2020.10.28

IDG 블로그 | AI옵스 툴이 너무 똑똑하면 생기는 일

AI옵스는 우리를 클라우드 컴퓨팅 운영을 위한 약속의 땅으로 데려가지만, 최소한 어떻게 따라가야 하는지는 알아야 한다. AI나 머신러닝을 이용하는 증강 기술 역량은 한계가 없는 것처럼 보인다. 이제는 AI 기반의 분석이나 지능형 사물 인터넷, 엣지의 AI, 그리고 AI옵스 툴까지 이용하고 있다.   AI옵스 툴은 본질적으로 지능형 자동화를 수행한다. 여기에는 자체 치유와 선제적 유지보수 등이 포함되며, 나아가 보안이나 거버넌스 시스템과의 공조를 통해 침해와 같은 성능 문제를 찾아내는 등의 작업을 수행할 수도 있다. AI옵스의 디스커버리 역량, 즉 지속적으로 데이터를 취합하고 해당 데이터를 이용해 지식 엔진을 학습하는 역량도 고려해야 한다. 이를 통해 지식 기반은 한층 더 실체적인 지식을 갖추게 된다. 관리하는 시스템이 어떻게 동작하고 어떻게 동작할 것인지를 더 잘 안다면, 문제를 더 잘 예측하는 역량이 생기고 문제를 바로잡고 보고하는 작업도 선제적으로 수행할 수 있다. AI옵스 자동화의 또 다른 이점은 다음과 같다.   클라우드옵스 프로세스에서 인력을 배제하고, 수작업 개입이 필요할 때만 경보로 알려준다. 운영 인력을 줄이고 비용을 절감할 수 있다. 장애 티켓의 자동 생성과 지원 운영팀과의 직접적인 인터랙션으로 모든 수작업과 비자동화 프로세스를 없앨 수 있다. 문제의 근본 원인을 찾아 바로잡을 수 있으며, 자동화된 메커니즘을 이용해 자체 치유 환경을 구현할 수 있다. AI옵스 디스커버리의 이점은 다음과 같다.   AI옵스를 데브옵스나 거버넌스, 보안 운영 등의 다른 기업용 툴과 통합한다. 추세를 파악해 운영팀이 선제적으로 대응할 수 있도록 지원한다. 관리하는 자원에서 나오는 대량의 데이터를 검사해 의미 있는 요약 정보를 제공하며, 이렇게 간추린 데이터를 기반으로 자동화된 조처를 취한다. AI옵스는 강력한 기술이다. 이런 AI옵스와 관련 툴의 강점을 제대로 이용하는 데는 몇 가지 장애물이 있다. 가장 큰 ...

클라우드옵스 AI옵스 자동화 2020.09.28

IDG 블로그 | 클라우드 컴퓨팅의 관찰 가능성에 관한 몇 가지 고찰

관찰 가능성은 애플리케이션과 데이터, 인프라를 좀 더 총체적인 가치를 제공하는 방식으로 감시할 수 있는 접근법이다.   관찰 가능성(Observability)이란 용어와 개념이 완전히 새로운 것은 아니다. 관찰 가능성은 엔지니어링과 제어 이론의 세계에 제일 처음 등장했다. 누구에게 묻느냐에 따라 정의는 다르겠지만, 일부 공통적인 규칙과 이해가 나타나고 있는데, 대부분 AI옵스와 클라우드옵스 분야의 일부 선도자가 만들어낸 유행어이다.  본질적으로 관찰 가능성은 외부의 모든 데이터와 상태에 관한 지식으로부터 내부 시스템의 상태를 얼마나 잘 추론할 수 있느냐를 의미한다. 사용자가 직접 수행하는 작업인 모니터링과는 약간 다른데, 관찰 가능성은 시스템 속성의 하나이다. 이런 식의 설명이 혼란스럽다면, 좀 더 실용적인 정의도 있다. “관찰 가능성이란 개념과 이 개념을 지원하는 툴을 이용할 수 있는 역량”이다. AI옵스 툴 같은 대부분 모니터링 및 운영 툴은 관찰 가능성에서 일정한 역할을 한다. 하지만 어떤 면에서 필자에게는 모니터링이란 오래된 술을 관찰 가능성이란 좀 더 멋진 병에 담은 것에 불과하다. 구체적인 의심을 가지고 본다는 말이다. 긍정적인 측면에서는 점점 더 많은 툴이 관찰 가능성이란 개념에 맞춰 만들어지고 있다. 보안이나 데이터베이스, 네트워크 모니터링 같은 복잡한 운영 데이터를 다루는 기타 모니터링 플랫폼 뿐만 아니라 새로 등장하는 AI옵스나 클라우드옵스 툴세트 대부분이 그렇다. 관찰 가능성의 목적은 이런 데이터 지점 모두를 총괄적으로 이용하는 것으로, 대부분 기업이 요즘에는 하지 않는다. 관찰 가능성은 현대적인 시스템의 관리와 모니터링에 중요하다. 이는 현대적인 애플리케이션과 이런 애플리케이션이 전달되는 속도를 다루고 있다는 점을 생각하면 쉽게 알 수 있다. 많은 적용하는 프랙티스인 애플리케이션을 배치하고 난 후 모니터링과 관리를 추가하는 방식은 그리 쉽게 확장할 수가 없다. 관찰 가능성 개념의 또 다른 부분은 애플리케이션의...

관찰가능성 Oservability 클라우드옵스 2020.09.09

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.