BLOG

IT 과제에 적합한 툴 선택하기
작성일: 2018-12-26

Voiced by Amazon Polly

(원문에서 다운로드받으세요)

 

이 글은 AWS Community Hero Markus Ostertag의 글입니다. Markus는 뮌헨에 본사를 둔 첨단 기술 회사 팀 인터넷 AG의 CEO로서 항상 클라우드를 활용하는 가장 좋은 방법을 모색하고 있으며, 최첨단 기술을 다루는 것을 좋아하고, 2014년에 공동 설립한 AWS 이벤트와 AWS 사용자 그룹 뮌헨에서 자주 연설하고 있습니다.

 

업무에 적합한 툴이나 서비스를 선택하는 것은 IT에서 매일 모든 종류의 비즈니스에서 큰 도전과제입니다. 이 글을 통해, 팀 인터넷에서는 AWS의 거대한 “도구 상자”를 활용하여 더 나은 솔루션을 구축하고 문제를 보다 효율적으로 해결하기 위해 사용한 몇 가지 전략과 예를 공유하고자 합니다.

 

기존 리소스를 사용하거나 새로운 리소스를 구축하시겠습니까? 어려운 결정입니다.

IT 엔지니어, 설계자 또는 개발자의 일상적인 업무는 문제에 대한 솔루션을 구축하거나 비즈니스 프로세스를 소프트웨어로 전송하는 것입니다. 이를 달성하기 위해, 저희는 대개 이미 존재하는 구조나 자원을 사용하고 그것에 대한 “추가 기능”을 구축하는 경향이 있습니다.

 

마이크로서비스의 증가와 함께, 저희 모두는 모듈화와 디커플링이 확장 가능하다는 데에 중요하다는 것을 배웠습니다. 이것은 저희를 다른 종류의 소프트웨어 아키텍처로 이끌었습니다. 실제로 기존(완전히 사용되지 않을 수도 있음) Amazon EC2 인스턴스의 동일한 데이터베이스처럼 이미 존재하는 자원을 사용하는 경향이 있는데, 이는 새로운 것을 구축하는 것보다 쉬워 보이기 때문입니다.

 

다음 레벨의 마이크로서비스로 쌓으시겠습니까?

팀 인터넷에서는 마이크로서비스의 어휘를 사용하지 않고 다양한 사용 사례를 위한 스택과 구성 요소에 대해 말하는 경향이 있습니다. 저희의 접근법은 저희가 다루어야 할 특정한 문제에 필요한 데이터베이스와 다른 자원들을 포함한 모든 것에 마이크로서비스의 아이디어를 맞추는 것입니다.

 

소프트웨어와 코드를 다른 모듈로 “단순히” 나누는 것이 아닙니다. 전체 인프라는 서로 다른 요구에 따라 분리됩니다. 전체 아키텍쳐의 각 부분들은 전체 시스템의 다른 모든 부분들로부터 가능한 한 독립적인 저희의 스택입니다. 그것은 오직 인프라의 다른 스택이나 부분들과 느슨하게 통신합니다.

이러한 사고방식의 이점 = 독립성과 유연성

  • 올바른 부품 선택. 모든 사용 사례에 대해, 저희는 특정 과제에 가장 적합하고 한계를 해결할 필요가 없는 구성요소 또는 서비스를 선택할 수 있습니다. 이것은 특히 데이터베이스에 대한 사실인데, 저희가 그것을 위해 구축되지 않은 DBMS에 요구 조건을 짜내는 대신에 전체 팔레트에서 선택할 수 있기 때문입니다. 저희는 쓰기 집약적인 워크로드 vs 읽기 집약적인 워크로드 또는 구조화된 워크로드 vs 구조화되지 않은 데이터와 같은 워크로드의 다양한 요구사항을 구분할 수 있습니다.
  • 마음대로 재건. 저희는 그들이 느슨하게 연결되어 있기 때문에 전체 스택을 재건하는 데 융통성이 있습니다. 이 때문에, 팀은 새로운 아이디어나 서비스로 개념 증명을 구축하고 생산 시스템을 방해하거나 손상시키지 않고 생산 작업 부하에서 병렬로 실행할 수 있습니다.
  • 비용 절감. 여러 리소스를 구동하는 운영 오버헤드는 AWS(“차별되지 않은 힘든 일 없음”)에 의해 수행되므로, 서비스 가격을 살펴보기만 하면 됩니다. AWS의 대부분의 가격 체계가 스택을 지지하고 있습니다. 데이터베이스의 경우 처리량(Amaz DynamoDB) 또는 인스턴스당(Amazon RDS 등)을 지불하십시오. 처리량 수준에서는 오버헤드 없이 한 테이블에서 수행한 처리량을 여러 테이블로 분할하기만 하면 됩니다. 인스턴스 수준에서 가격은 선형이므로 r4.xlarge는 r4.2xlarge의 절반 가격입니다. 그렇다면 두 개의r4.xlarge를 실행하고 워크로드를 분할하는 것은 어떨까요?
  • 복원력 설계. 또한 이 접근방식은 기본적으로 아키텍처가 더 안정적이고 복원력이 뛰어난 데 도움이 됩니다. 서로 다른 스택은 서로 독립적이므로, 규모 조정이 훨씬 더 세분화됩니다. 대형 시스템의 확장에서는 흔히 높은 “보안 버퍼”를 제공하는데, 고장(하드웨어, 소프트웨어 등)은 전체 시스템의 작은 부분에서만 발생합니다.
  • 소유권 취득. 저희가 이 방법을 사용함에 따라 저희가 지금 보고 있는 좋은 부작용은 저희 팀의 소유권과 책임에 긍정적인 영향입니다. 이러한 스택 때문에 문제를 정확히 파악하고 해결하는 것이 더 쉬울 뿐 아니라, 누가 어떤 스택을 담당하는지 명확하고 명료하게 알 수 있습니다.

 

업무에 적합한 툴을 사용하더라도 많은 노력이 필요한 혜택

모든 접근에는 단점이 있습니다. 여기서, 그러한 시스템을 구축하기 위해서는 분명히 추가적인 개발과 아키텍처 노력이 필요합니다.

 

따라서, 저희는 항상 우리의 마음 속에 독립적인 스택과 그 두 가지 사이에 신뢰할 수 있고 느슨하게 결합된 과정을 가진 완벽한 시스템의 목표를 갖기로 결정했습니다. 실제로, 저희는 가끔 저희 자신의 규칙을 어기고 여기저기서 부정행위를 합니다. 설사 그렇다 하더라도, 이러한 접근법을 갖는 것은 저희가 더 나은 시스템을 구축하는 데 도움이 되고 적어도 어느 시점에 저희가 이익을 잃을 위험을 감수하는지를 정확히 아는 데 도움이 됩니다. 저는 여기에 있는 설명과 통찰력이 여러분이 그 일에 적합한 툴을 선택하는데 도움이 되기를 바랍니다.

 

원문 URL : https://aws.amazon.com/ko/blogs/aws/pick-the-right-tool-for-your-it-challenge/

** 메가존클라우드 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.