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.

아키텍처

IDG 블로그 | 클라우드 아키텍처도 빠른 변화에 대비해야 한다

설립 5년차의 중견 바이오테크 회사가 있다고 가정해 보자. 편의를 위해 회사 이름은 미드코(MidCo)라고 정했다. 이 회사는 혈액 및 근육 샘플의 자동화된 테스트가 전문이다. 유망한 분야라 첫 5년 동안 사업은 성장했다. 하지만 스타트업 경쟁업체가 AI를 이용하는 좀 더 첨단화된 제품을 생산해 더 저렴한 가격에 판매하면서 미드코는 망해가고 있다.   미드코의 IT 부서는 더 최적화된 검사 기술을 더 나은 가격에 만들기 위해 연구개발과 마케팅에서 요구하는 변화를 따라가지 못한다. 게다가 일부 미드코의 특허 제품은 기존 클라우드 기반 시스템의 한계 때문에 생산 단계에 들어가지도 못했다. 미드코의 시스템은 몇몇 공급업체만 통합하고 다양한 서드파티 부품 업체를 이용하지 못하는데, 이 때문에 부품 공급 부족이나 공급업체 변경 등과 관련해 최적화된 공급망을 확보할 수 없다. 미드코가 망하는 이유는 나쁜 운이나 점점 치열해지는 시장 경쟁이 아니다. 초기에 클라우드 기반 솔루션을 만들면서 주요 시스템에 빠른 변화를 수용할 수 있는 역량을 통합하지 못했기 때문이다. 이런 제약은 회사가 성장하면서 점점 더 큰 문제가 되었는데, 시장이 누구도 예상하지 못한 속도로 빠르게 변했기 때문이다. 요즘은 미드코 같은 회사가 일반적이다. 이런 문제는 너무 많은 사일로 시스템을 통합하지 않은 채 운영하는 구식 기업에서나 있을 것이라고 생각하기 쉽다. 하지만 설립하지 10년 미만에다 클라우드 기반 시스템만을 사용해 온 곳도 많다. 이런 회사가 왜 망하는 것일까? 클라우드 컴퓨팅은 자동으로 최고의 민첩성과 최적화된 비용을 제공한다고 생각하는 사람이 많다. 하지만 현실은 전혀 그렇지 않다. 클라우드이건 아니건 빠른 변화에 적응할 수 있는 시스템을 구축해야만 한다. 많은 경우, 기존 클라우드 시스템에 관련 기능을 통합하는 것은 전통적인 시스템을 업그레이드하는 것만큼이나 어렵다. 그리고 이런 변화 기능 없이는 중견 기업은 파괴적인 경쟁자가 등장하면 바로 치명타를 맞는다. 일반 사용...

아키텍트 아키텍처 민첩성 1일 전

IDG 블로그 | 새로운 최적화 렌즈로 보는 클라우드 아키텍처

이제 클라우드 컴퓨팅 아키텍처의 성공을 정의하는 방법도 한층 성숙해져야 한다. 클라우드 아키텍처에는 걸려있는 것이 너무 많다. 제대로 최적화되지 않고 비용이 많이 드는 클라우드 아키텍처는 동작하기는 하겠지만, 기업은 매주 수백만 달러의 손해를 볼 수도 있다. 12가지 기술이면 더 잘 동작할 수 있는데, 30가지 기술이 사용되고, 변화를 염두에 두지 않은 설계로 비즈니스 민첩성이 손상된다.    클라우드 아키텍처가 좀처럼 최적화되지 않는 이유는 무엇일까? 클라우드 아키텍트가 계획과 설계 단계에서 클라우드 아키텍처 교육 과정에서 배운 대로 하거나 다수의 레퍼런스에서 읽은 것을 적용한다. 이전 클라우드 아키텍처 프로젝트나 선임자에게 배운 팁을 적용하기도 한다. 이 모든 가이드는 아키텍트를 일련의 범용적인 레퍼런스 모델과 프로세스, 기술 스택 등으로 이끄는데, 이들은 모두 기업의 특정 비즈니스 요구사항을 해결할 수 있도록 수정해야만 한다. 이런 접근법이 필요 이상의 비용을 지출하도록 하는 최적화되지 않은 아키텍처를 낳는 것이다. 왜 이렇게 된 것일까? 이 질문에 답하기 위해 우리 자신을 되돌아볼 필요가 있다. 최적화된 클라우드 아키텍처는 실제로 어떤 의미일까? 필자는 ‘IDG 블로그 | 클라우드 아키텍처 최적화 쉽게 이해하기’란 글을 통해 클라우드 아키텍처 최적화 프로세스를 정의한 바 있다. 그리고 이용하기 좋은 높은 수준의 모델도 제시했다. 필자의 클라우드 아키텍처 교육 과정도 이런 개념을 포함하도록 보강했다.  다음으로는 과거에는 모든 요소가 함께 동작하는 데 중점을 두었다는 것을 알아야 한다. 당시에는 얼마나 잘 동작하고 솔루션이 얼마나 복잡해지는가에는 큰 비중을 두지 않았다. 성공의 척도는 “동작하는가?”였지 “얼마나 잘 동작하는가?”는 아니었다. 개발 과정에서 클라우드팀은 클라우드 아키텍처와 마이그레이션, 새로운 개발에 대한 접근법에 온전히 집중했다. 메타 클라우드 아키텍처 같은 넓은 관점과 마이크로 클라우드 아키텍처 같...

클라우드 아키텍처 최적화 2022.01.17

마이크로서비스 아키텍처를 사용해야 하는 이유

현재 운영 중인 애플리케이션은 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

마이크로서비스 아키텍처 컨테이너 2021.11.16

IDG 블로그 | 클라우드 보안과 아키텍처팀이 더 친해야 하는 이유

베스트 프랙티스와 표준에 대한 논의 없이는 컨테이너와 마이크로서비스가 클라우드 네이티브 애플리케이션의 새로운 보안 취약점이 될 것이 분명하다. 클라우드에서 애플리케이션과 데이터 침해에 대한 사후 부검을 진행해 보면, 문제는 커뮤니케이션인 것으로 드러나는 경우가 적지 않다. 주로 컴퓨터와 컴퓨터의 커뮤니케이션이 아니라 클라우드 기반 시스템을 설계하는 인간과 클라우드 보안을 책임지는 인간 간의 커뮤니케이션에 문제가 있다.   컨테이너나 쿠버네티스, 마이크로서비스 같은 현대적인 메커니즘을 사용하는 애플리케이션은 종종 이런 메커니즘 때문에 노출되는 보안 취약점을 놓치곤 한다. 필자가 즐겨 사용하는 비유는 건축가가 세계 최고의 스마트 빌딩을 설계했지만, 잠금장치를 설치하지 않은 것이다. 잠금장치는 건물을 설계할 때 만들어야 하는 것이지 사후에 추가하는 것이 아니다. 그런데 클라우드 시스템 보안 세계에서는 이런 일이 종종 발생한다. 문제의 본질은 이런 클라우드 네이티브 솔루션을 만드는 사람들이 믿고 의지할 만한 베스트 프랙티스와 표준의 부족이다. 이제서야 아키텍처팀과 보안팀이 표준과 베스트 프랙티스와 관련해 더 잘 공조할 수 있는 약간의 지침이 등장하고 있다. 대표적인 예는 클라우드 보안 연합의 애플리케이션 컨테이너 및 마이크로서비스 워킹그룹이 개발한 마이크로서비스 아키텍처 패턴(Microservices Architecture Pattern)이다. 이 지침은 애플리케이션 개발자와 아키텍트, 그리고 애플리케이션 컨테이너와 마이크로서비스 보안을 책임지는 모두에게 마이크로서비스 아키텍처 패턴을 설계하고 개발하고 배치하는 접근 방법을 제공한다. 쉽게 말해, 이 지침은 마이크로서비스를 독립적으로 운영하면서 다른 마이크로서비스와 커뮤니케이션하는 방법을 알려준다. 마이크로서비스는 최신 클라우드 기반 시스템의 공통 애플리케이션 요소로 진화했다. 물론, 애플리케이션 구성요소는 공격 벡터가 되어서는 안된다. 설계와 보안이 합쳐져야 한다. 기본 개념은 클라우드 네이티...

아키텍처 베스트프랙티스 공격벡터 2021.09.06

IDG 블로그 | 설계보다 중요한 멀티클라우드의 운영 지속성

좋은 멀티클라우드 아키텍트를 만나기 어려운 시절이다. 스스로 멀티클라우드 아키텍트라 부르는 사람 대부분은 실제로 단일 퍼블릭 클라우드 전문가일 뿐이다. 멀티클라우드로 급격하게 쏠리는 시장의 관심을 따라온 사람들이다. 이런 현상을 “멀티클라우드 워싱(Multicloud Washing)”이라고 부른다.   거의 완벽하게 최적화된 멀티클라우드 솔루션을 만들기 위해서는 각각의 퍼블릭 클라우드가 가지고 있는 것보다는 퍼블릭 클라우드 사이에 무엇이 있는지에 더 집중해야 한다. 또한 대부분 클라우드 아키텍트에게는 아직 없는 새로운 수준의 이해가 필요하다. 이런 변화는 향후 몇 년 동안 빠르게 진행될 것이다. 멀티클라우드 아키텍처의 구성과 구축, 배치와 관련된 몇 가지 원칙이 부상하고 있다. 핵심은 최종 운영에 대한 초점을 잃어버리지 않는 것이다. 운영은 대부분 멀티클라우드 설계가 어려움을 겪는 부분이다. 멀티클라우드를 정의하는 한 가지는 기술의 복잡한 조합이다. 여기에는 보안이나 거버넌스, 모니터링, 데이터 관리 등등의 공통 서비스도 포함된다. 멀티클라우드를 정의하는 또 하나는 이 모든 것을 장기적으로 운영하는 방법이다. 여기에는 자원과 비용이 든다. 많은 경우, 멀티클라우드 구성을 운영할 수 있도록 만드는 비용은 멀티클라우드가 비즈니스에 가져오는 가치보다 비싸다. 이유는 여러 가지겠지만, 대부분은 복잡성 때문이다. 너무 많은 종류의 기술과 업체, 접근방식은 과도하게 복잡한 멀티클라우드 솔루션이 되고, 곧 비현실적인 운영 방식과 자원 요구사항으로 이어진다. 필자는 멀티클라우드 접근법을 운영 가능하도록 만드는 비용이 기존 상태보다 5배나 더 들어간 사례도 알 고 있다. 이런 문제는 실제 배치가 완료되기 전까지는 아무도 몰랐으며, 황급하게 좀 더 합리적인 수준의 운영이 가능하도록 만들기 위해 멀티클라우드에 사용된 기술을 평범하게 만들어야만 했다. 좀 더 민첩한 기술을 보유할 기회를 놓친 것은 물론, 수백만 달러의 추가 손실을 피할 수 없었다. 이제 멀티클...

멀티클라우드 설계 운영 2021.08.25

IDG 블로그 | 클라우드에 메타 아키텍처와 마이크로 아키텍처가 모두 필요한 이유

전통적인 온프레미스 애플리케이션을 퍼블릭 클라우드로 이전하는 데 몇 년의 시간을 투여했고, 그 결과 애플리케이션과 데이터의 15%를 이전했다고 하자. 어떻게 보든 상당한 수치다. 하지만 이사회는 더는 이런 성취에 중점을 두지 않는다. 이제 경영진은 클라우드 마이그레이션 과정에서 내린 몇 가지 결정을 재평가하는 회의를 소집할 것이다. 클라우드 마이그레이션 과정에서 한 클라우드 서비스 업체가 ‘선호하는 클라우드’로 결정됐는데, 이 업체의 솔루션이 ‘언제나 정답’인지 알고 싶다는 것이다.   누구나 알고 있는 사실이 있다. 단일 서비스 업체가 최고 혹은 최적의 해법인 경우는 드물다. 다른 클라우드 서비스 업체의 네이티브 시스템에서 최고의 기능만 골라서 이용할 수 없기 때문이다. 어떤 업체는 AI 플랫폼이 뛰어나고 다른 업체는 데브옵스가 좋고, 또 다른 업체는 지난 해 감사 실패로 물었던 벌금 50만 달러를 절감할 수 있는 컴플라이언스 시스템을 지원하는 식이다.  무슨 일이 있었는지도 분명하다. 클라우드 아키텍처를 넓게 보지 않고 좁게만 봤다. 그래서 단일 클라우드 서비스 업체에 맞춰 교육과 훈련을 받은 인력만 채용했다. 이제 해당 클라우드가 제공하는 서비스를 위한 기술 인력은 확보했지만, 다른 클라우드 서비스 업체의 네이티브 서비스를 위한 기술력을 확보할 기회는 잃어버렸다. 아마 클라우드팀은 메타 클라우드 아키텍처를 알지 못할 것이다. 넓은 클라우드 아키텍처나 멀티클라우드에 대한 확실한 이해도 없을 것이며, 좁은, 단일 클라우드 접근법만을 잘 알고 있을 것이다. 물론 클라우드 프로젝트 책임자만의 잘못은 아니다.  이 문제가 필자의 레이더에 처음 걸린 것은 몇몇 괜찮은 클라우드 아키텍트가 인력을 찾는 데 어려움을 겪고 있다고 불만을 토로하면서부터다. 대부분 기업이 단일 클라우드 플랫폼에 중점을 두고, 이들 특정 플랫폼의 아키텍처나 개발, 보안 등에서 자격 인증을 받은 인력만 새로 채용하려 한다는 것이다. 필자는 여러 해 동안 더 ...

클라우드 아키텍처 멀티클라우드 2021.08.17

IDG 블로그 | 클라우드 아키텍처 감사에 대응하는 올바른 자세

필자는 누군가가 설계한 기업 클라우드 솔루션을 검토할 때 최선을 다한다. 누군가의 아기를 못생겼다고 말하는 것은 무례한 일이고, 아기가 못생긴 데는 충분한 이유가 있을지도 모른다. 필자는 절대 결론을 바로 내리지 않으며, 전체 그림을 이해할 때까지는 편견을 배제하려 노력한다.   선택한 기술의 중요성과 잠재적인 영향, 선택 이유, 어떻게 구성하는지 등이 어렴풋이 드러난다. 필자의 직업적 특성 상 꼭 써야 할 비용의 두 배를 쓰고 핵심 비즈니스 기능을 방해하는 비효율적인 클라우드 솔루션을 사용하는 기업을 만나는 경우는 드물지 않다. 잘못된 기술 선택에 발목이 잡혀 실적이 떨어지는 기업도 적지 않게 만난다. 경쟁사는 시장을 허물고 먹을거리를 다 가져가는데 말이다. 그래서 아키텍처 감사가 시작된다. 당연히 CEO나 CFO가 이런 감사를 요청하고, 때로는 이사회가 요청하기도 한다. CIO나 CTO, 아니면 기업 IT 부서의 책임자가 이런 요청을 하는 경우는 매우 드물다. 하는 쪽이나 받는 쪽이나 모두 성공적으로 클라우드 아키텍처 감사를 진행할 수 있는 몇 가지 팁을 소개한다. 책임 공방을 벌이지 말라. 목표는 잘못을 찾는 것이 아니라 현재의 솔루션을 좀 더 비용 및 기술 효율적으로 만들 방법을 찾아 더 큰 비즈니스 이점을 만들어내는 것이다. 의사결정이 내려진 맥락을 이해하라. 예를 들어, 전반적인 기능이 부족한 현재의 보안 솔루션이 선정된 이유는 자동화된 컴플라이언스를 지원하기 때문일 수 있다. 대안 기술을 모색하라. 물론 대안 기술을 이용하는 비용과 위험성도 함께 고려해야 한다. 많은 경우, 선택된 기존 기술이 최적의 해법은 아니지만, 이를 교체하는 데 드는 비용은 잠재적인 이점보다 더 크다. 양쪽 모두 틀릴 수 있다. 아키텍처 평가에서 데이터 유출 위험을 낮추기 위해 암호화 수준을 높여야 한다는 권고안이 나왔다. 하지만 이 권고안은 성능에 미치는 영향을 계산하지 않았고, 권고안대로 하면 데이터베이스가 사용할 수 없는 상태가 될 수도 있다. ...

아키텍처 리뷰 감사 2021.08.02

IDG 블로그 | 클라우드 아키텍처에서 공유할 수 있는 솔루션 패턴 찾기

규모가 크고 복잡한 멀티클라우드 마이그레이션의 일부로 제조 부서를 지원하는 시스템을 위한 데이터 아키텍처를 막 완성했다고 하자. 모든 데이터베이스를 일반화했고, 고객이나 주문서, 제품 등의 모든 중요 데이터 속성에 대한 SSOT(Single Source of Truth)를 만들었다.   스스로 자부심을 느끼며 줌 화상회의를 열어 다른 부서에도 이런 접근법과 아키텍처, 툴 사용에 대해 설명한다. 그런데 다들 팔짱을 낀 채 심각한 표정이다. 이유인즉슨, 자신들도 마이그레이션을 위해 SSOT를 찾는 것은 물론, 일반화된 데이터 모델을 위해 독창적인 접근법을 이용하고 있다는 것이다. 이런 상황을 완전히 예방할 수는 없지만, 두 부서가 커뮤니케이션을 하고 협업을 했다면 좀 더 반복 가능한 방법으로 이 문제를 해결할 수 있었을 것이다. 하지만 두 팀은 사일로 안에서 일을 하며 자신들이 하는 일을 공유하는 것으로 다른 팀에 간섭하는 일을 하지 않았고, 그래서 하이브리드 멀티클라우드 배치를 위한 반복 가능한 솔루션을 제공해 비용과 위험을 줄일 수 있는 공통 아키텍처 패턴을 절대 찾을 수 없었다. 많은 사람이 이런 상황을 해결하기 쉬운 문제로 본다. 커뮤니케이션과 협업만 하면 해결된다는 것이다. 하지만 하나 이상의 복잡한 클라우드 아키텍처 프로젝트를 진행 중인 규모가 큰 기업에서는 늘 일어나는 문제이다. 프로젝트는 부서를 기준으로는 사일로 방식으로 진행되고, 팀은 다른 프로젝트가 있다는 사실조차도 알지 못한다. 이 문제의 핵심은 우리가 클라우드 아키텍처를 세우면서 복잡한 문제를 해결하는 역량은 뛰어나지만, 이런 패턴을 공유하는 역량은 부족하다는 것이다. 코로나19 팬데믹과 갑작스레 증가한 원격 근무를 탓할 수도도 있지만, 그보다는 지식 관리 인프라와 교육 훈련의 부족, 공유 문화의 부재가 더 큰 원인일 것이다. 일각에서는 자원의 결합과 변화를 통해 좀 더 협업적인 조직을 만드는 방법도 찾고 있지만, 경영진이 전면에 나서 문화적 변화를 이끌지 않고는 문제가 ...

아키텍처 패턴 공유 2021.06.03

IDG 블로그 | 클라우드 아키텍처에서 가치란 무엇인가

코로나19 팬데믹 덕분에 필자는 자전거를 재조립하고 수리하는 방법을 배우기 시작했다. 물류가 원활하지 않아 새 자전거를 사기도 어렵고 비쌌기 때문이다. 체육관도 문을 닫으면서 친구와 가족들의 자전거가 다시 달릴 수 있도록 고치기 시작했다.   자전거 부품은 가치의 개념을 이해하기 좋은 모델이다. 자전거 바퀴는 50달러짜리부터 1,000달러짜리 풀카본 바퀴까지 다양하다. 문제는 자신의 필요에 따라서 어떤 부품이 최고의 가치를 가지는지 평가하는 일이다. 진정한 가치를 어떻게 찾아야 하는가? 가치란 많은 의미를 가진 단어이다. 하지만 클라우드 컴퓨팅 아키텍처에서 가치는 다음과 같이 정의할 수 있다. “가치는 사용된 돈과 그 돈을 사용함으로써 얻는 상대적인 혜택 간의 균형이다.” 클라우드 아키텍처에서 비용을 너무 적게 사용하거나 너무 많이 사용하는 것은 최적화된 선택이 아닐 가능성이 크다. 클라우드 솔루션을 최적화하고 비용과 비즈니스에 영향을 미치는 핵심 혜택 간의 균형을 맞추기 위해서는 두 극단 사이에서 어떤 지점을 찾아야 한다.  다음 그림은 이런 특성을 시각적으로 잘 보여준다. 오른쪽 위로 향하는 파란 색의 직선은 클라우드 자원에 사용하는 비용의 규모가 증가하는 것을 나타낸다. 주황색의 불규칙한 선은 기업이 얻는 혜택으로, 중앙 지점까지는 비용과 함께 높아지다가 기울기가 둔화된다. 일정 지점에서 비용 투자가 같은 비율의 비즈니스 혜택으로 돌아오지 않는다는 의미이다.    클라우드 아키텍처 분야에서 아직은 잘 알려지지 않은 몇 가지 특성 중 하나이다. 기술적으로는 동작하지만 비용과 가치는 최적화되지 않은 클라우드 기술 구성과 솔루션이 많다. 이런 아키텍처는 비즈니스가 얻을 수 있는 혜택 면에서 너무 많은 비용이 든다. 메인프레임과 같은 기존 자산을 최적화하지 않고 인기 있고 주목받는 솔루션을 억지로 도입한 기업에서 흔히 볼 수 있다. 비용은 점점 더 증가할 것이고 가치는 그만큼 크지 않을 것이다. 복잡성은 가치...

클라우드 아키텍처 최적화 2021.05.20

IDG 블로그 | 모두가 저지르는, 하지 말아야 할 클라우드 아키텍처 실수 3가지

필자가 일을 의뢰한 기업과 갈등을 겪은 단 한 번은 의뢰주가 꽤 큰 실수를 저지른 필자 팀의 초보 IT 아키텍트를 처벌하려고 했을 때이다. 데이터베이스 중 하나가 기존에 있던 미들웨어 계층과 호환되지 않은 것이다. 분명 이 실수 때문에 시간과 비용을 더 들었다. 하지만 이런 실수는 클라우드 컴퓨팅이 포함된 IT 시스템을 구성할 때 거의 피할 수 없는 것이기도 하다. 필자는 이런 실수를 혁신 과정에 불가피한 것으로 본다. 새로운 것을 시도해 보지 않는다면, 그래서 그들 중 일부가 제대로 동작하지 않는다는 것을 찾아내지 않는다면, 아무것도 개선할 수 없다. 필자는 상사에게 다른 일을 찾자고 졸랐고, 결국 그렇게 했다.   만약 실수가 혁신적이고 새로운 아키텍처의 부산물이라면, 이제 자주 저질러지는 실수를 살펴봐야 한다. 클라우드 아키텍처는 이제 이런 실수를 이해하고 피할 수 있어야 한다. 흔한 실수 세 가지를 살펴보자. 1. 과도한 분산. 애플리케이션과 데이터 구성요소를 분리할 수 있다는 이유만으로, 그리고 이들을 네트워크 연결된 시스템을 통해 곳곳에서 구동할 수 있다는 이유만으로 분산해서는 안된다. 클라우드 아키텍처는 특히 이런 실수에 취약한데, 모든 종류의 플랫폼을 서로 다른 클라우드에 프로비저닝하기도, 이들을 연결하기도 쉽기 때문이다. 하지만 그 결과는 잘 알려진 것처럼, 열악한 지연과 안정성이다. 좋은 아키텍처의 법칙 중 많은 것이 여전히 유효하다. 특히 같은 애플리케이션과 데이터 저장소를 위한 프로세싱과 데이터 스토리지를 최대한 가까이 위치시켜야 한다. 보통은 인트라클라우드를 의미하지만, 같은 클라우드 상에서는 인트라플랫폼이 될 수도 있다. 2. 보안이 마지막 단계. 보안은 한때 프로세스의 마지막에 추가하는 것이었다. 하지만 클라우드 프로젝트에서도 이렇게 하면, 잘해야 최적화되지 않은 보안 시스템이 되고, 최악의 경우 전혀 안전하지 않은 보안 시스템이 된다. 클라우드 컴퓨팅 세계에서 보안은 나중에 생각할 수 있는 것이 아니다. 비록 ...

아키텍처 실수 분산 2021.04.26

IDG 블로그 | 멀티클라우드 아키텍처 3대 실수

멀티클라우드 아키텍처의 최적화는 쉽게 말해, 비용을 최적화하는 것은 물론, 비즈니스 요구사항에 맞춰 아키텍처를 최적화할 수 있도록 기술을 구성하는 역량이다. 클라우드 기술에 사용하는 비용 한푼 한푼이 극대화된 가치로 비즈니스로 되돌아오도록 하는 것이다.   사실 온전히 최적화된 클라우드 아키텍처는 드물다. 필자는 주된 원흉으로 복잡성에 대한 편향을 지적한 바 있다. 하지만 근본 원인은 배치와 운영이 이루어진 다음에야 아키텍처 최적화에 관해 생각하기 때문이다. 사실 그때는 너무 늦다. 그렇다면, 멀티클라우드 아키텍처는 어떨까? 온전히 최적화되지 못하는 상태에 이르지 못하는 주된 원인은 무엇일까? 세 가지 주된 원인과 그 해법을 소개한다. 너무 많은 기술을 이용한다. 과잉은 복잡성의 사촌이다. 멀티클라우드 아키텍트와 개발팀은 종종 가능한 한 많은 기술을 멀티클라우드에 넣으려 애쓰곤 하는데, 주로 ‘구체화할 수도 있는’ 모든 종류의 요구사항에 대응하는 식이다. 필요한 것은 하나의 서비스 거버넌스 기술일 텐데, 세 가지를 사용한다. 스토리지 서비스도 하나면 충분한데, 일곱 가지를 사용한다. 결국은 더 많은 비용을 들이고도 비즈니스는 추가 가치를 얻지 못한다. 모든 아키텍트는 아직 도달하지 않은 미래를 대비해 아키텍처를 구축하기 때문에 매우 어려운 문제이다. 아키텍트는 내장 미러링 기술을 갖춘 데이터베이스를 선택하는데, 나중에 완전히 분산된 데이터베이스 환경으로 이전할 수도 있기 때문이다. 하지만 몇 년은 뒤의 일이다. 따라서 데이터베이스의 종류는 정말로 충분한 이유가 없다면 2~4개 정도이다. 최적화된 상태에 근접하기 위해서는 ‘최소한의 실행 가능성’에 맞춰 구축해야 한다는 것을 잊지 말기 바란다. 구체적인 요구사항에 맞춰 구축하지 않는다. 요구사항이란 엄격하고 구체적이며 즉각적인 것으로, 이해하기도 쉽다. 주로 멀티클라우드 아키텍처가 어떤 것이 될지 결정하기 때문이다. 실제로 요구사항이 아키텍처가 해결해야 하는 문제의 패턴을 개략적으로 그려준다....

멀티클라우드 아키텍처 최적화 2021.04.12

IDG 블로그 | 멀티클라우드 아키텍처 분해의 단순화

아키텍처란 주장과 같다. 모두가 자신만의 편견을 기반으로 한 각자의 주장이 있다. 어떤 아키텍처는 오픈소스 솔루션만을 사용할 것으로 고집하고, 특정 퍼블릭 클라우드나 데이터베이스를 고집하기도 한다. 이들 편향성은 종종 어떤 솔루션을 채택하고, 그 선택이 얼마나 좋고 나쁜지를 결정하는 동인이 된다. 문제는 이런 편견을 기반으로 구성요소나 기술을 선택하면, 흔히 비즈니스의 핵심 요구사항을 더 잘 만족하는 기술을 고려하지 않는다는 것이다. 비슷하기는 하지만 절대 100% 최적화되지 않는 아키텍처는 이렇게 만들어진다.    최적화란 비용은 최소로 유지하면서 효율은 극대화하는 것을 말한다. 똑같은 문제를 10명의 클라우드 아키텍트에게 풀어보라고 하면, 10가지 서로 다른 해법이 나오는 것은 물론, 비용도 많으면 1년에 수백만 달러까지 차이가 날 것이다. 게다가 이 10가지 해법은 어쨌든 돌아간다. 최적화가 덜 된 아키텍처라도 기술 계층의 형식으로 비용을 투여하면 성능이나 탄력성, 보안 등의 문제를 완화할 수 있다. 이들 모든 계층은 완전히 최적화된 멀티클라우드 아키텍처와 비교해 10배나 많은 비용이 든다.  그렇다면 최적화된 멀티클라우드 아키텍처를 어떻게 구축할 것인가? 멀티클라우드 아키텍처 분해가 최상의 접근 방법이다. 새로운 문제를 해결하는 데 오래 전부터 사용하던 기법이다. 모든 계획된 솔루션을 기능 단위로 분해하고, 각각을 자체 이점으로 평가해 핵심 구성요소가 최적인지를 알아보는 방법이다. 예를 들어, 도입할 계획인 데이터베이스 서비스만 보는 것이 아니라 해당 데이터베이스 서비스의 구성 요소, 즉 거버넌스와 데이터 보안, 데이터 복구, I/O, 캐싱, 롤백 등을 살펴본다. 데이터베이스만 괜찮은 것이 아니라 서브시스템까지 잘 맞도록 하는 것이다. 간혹 서드파티 제품이 더 나을 때도 있다. 컴퓨트, 스토리지, 개발, 운영 등의 각 구성요소를 해부해 핵심 문제를 해결할 수 있는지, 멀티클라우드 아키텍처의 사용례를 제대로 지원할 ...

멀티클라우드 아키텍처 분해 2021.03.08

IDG 블로그 | 멀티클라우드 아키텍처에 반드시 있어야 하는 3가지

대부분 클라우드 아키텍트는 자신이 사는 세상이 갑자기 이기종 환경이 되었다는 것을 알게 된다. 한때는 퍼블릭 클라우드 서비스 업체 한 곳에만 집중할 수 있었는데, 지금은 혼합체 안에 최소한 서너 곳의 퍼블릭 클라우드가 있다. 이에 따라 아키텍처 패턴은 인트라 클라우드(Intra Cloud)에서 인터 클라우드(Inter Cloud)로 바뀌었는데, 바로 복잡성과 위험성이 도사리고 있는 지점이다.   결과적으로 아키텍트라면, 필자를 포함해 모두가 대다수 기반 서비스를 포괄할 수 있도록 확인하는 과정을 함께 마련하고 있다. 마치 비행사가 비행 전 점검 목록을 사용하는 것 같다. 여기에는 크로스 클라우드 거버넌스와 보안, 운영 등등이 포함되어 있다. 하지만 성공적인 멀티클라우드를 위해 필수적인 몇 가지를 빠뜨리곤 하는데, 가장 중요한 세 가지를 소개한다. 중앙집중화된 크로스 클라우드 사용자 계정 관리. 멀티클라우드를 제대로 구현하려면, 퍼블릭 클라우드 서비스 업체의 그룹을 가능한 한 하나의 클라우드로 취급해야 한다. 공통의 사용자 관리 계층이 있어서 각 클라우드와 이른바 ‘네이티브’하게 상호작용하는 단일 제어점에서 사용자 계층을 추가하고 삭제하고 변경할 수 있어야 한다.  중앙집중화된 계정 관리는 사용자 관리를 한층 덜 번거롭게 만드는 것 외에도 각 클라우드 서비스 업체에 보여주는 ID를 일관성 있게 만들어 보안도 개선한다. IDAM 시스템도 한층 더 일관성을 갖게 되며, 이에 따라 클라우드 보안 역시 좀 더 안전해진다. 크로스 클라우드 자원 관리. 이 범주는 AI옵스 툴, 클라우드 관리 플랫폼 툴 등 스토리지나 컴퓨트, 프로비저닝 같은 자원 사용을 모니터링하는 어떤 것도 될 수 있다. 특히 중요한 것은 자동화된 디프로비저닝(Deprovisioning)으로 사용하지 않는 자원을 자원 풀로 되가져오는 것이다. 퍼블릭 클라우드 서비스 업체가 이런 자원에 과금하는 것을 막을 수 있다. 필자는 엄청난 양의 클라우드 자원을 할당하고는 중단하지 않아 ...

멀티클라우드 아키텍처 일관성 2021.02.15

IDG 블로그 | 비용과 확장성을 최적화하는 클라우드 아키텍처 3가지

클라우드 기반 플랫폼의 가장 잘 알려진 이점은 사용한 만큼 내는 비용과 거의 무제한에 가까운 자원으로 확장할 수 있는 역량이다. 수요가 있기 전에 자원을 미리 구매할 필요도 없으며, 물리 하드웨어와 소프트웨어가 얼마나 필요할지 추정할 필요도 없다. 하지만 기업 IT 부서는 클라우드 컴퓨팅에서 확장성과 비용은 서로 연결된 개념이라는 것을 알아야 한다. 자원을 더 많이 사용할수록, 더 많은 비용을 내야 한다. 따라서 클라우드 비용은 자원 자체의 가격만큼이나 아키텍처 패턴에 따라 달라진다.   클라우드 기반 시스템을 구축할 때, 클라우드 아키텍처는 정말로 수많은 정답을 만들어 낸다. 물론 잘못된 결정을 내린다고 처벌을 받지는 않는다. 단지 덜 최적화될 뿐이다. 어떻게든 동작만 하면, 확장성과 비용을 완벽하게 최적화한 아키텍처보다 2배나 많은 비용을 낸다는 사실을 감춰준다.  아키텍처는 특정 클라우드 플랫폼에 최적화하기 위해 애플리케이션을 리팩터링하거나 다시 작성할지를 결정할 때 매우 중요한 요소이다. 아니면 마이크로서비스나 이벤트 지향, 컨테이너, 컨테이너 오케스트레이션 등 핵심 구현 기술을 선택할 때도 중요하다. 이런 결정이 모여 월말에 받아보는 클라우드 요금 고지서의 숫자가 결정된다.  그렇다면, 클라우드 아키텍트가 비용과 확장성 측면에서 생각해야 할 것은 무엇일까? 몇 가지 범용적인 아키텍처 패턴을 소개한다. 클라우드 기반 애플리케이션을 애플리케이션에 필요한 모든 클라우드 서비스의 최적화에 맞춰 튜닝하는 법을 배운다. 다시 말해, 애플리케이션을 데이터를 처리하고 기능을 수행하는 데 최소의 자원을 사용하도록 최적화해야 한다.  이런 아키텍처 최적화는 컴퓨팅의 초창기, 즉 8KB 메모리를 탑재한 1970년대 장비를 다룰 때는 흔한 일이었다. 요즘 개발자는 애플리케이션을 작성할 때 이런 미니멀리즘 접근법으로 최적화하는 데 익숙하지 않다. 하지만 이렇게 하기만 한다면, 애플리케이션은 더 빨리 무한대로 확장하는 비용 증가...

확장성 아키텍처 리팩터링 2021.01.20

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

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

Copyright © 2022 International Data Group. All rights reserved.