[AWS Heroes 특집] 마이크로서비스로 전환을 위한 작은 조언
이 글은 AWS Community Hero Markus Ostertag가 기고했습니다. 뮌헨에 위치한 애드테크 회사, Team Internet AG의 CEO인 Markus 는 언제나 클라우드를 활용할 최상의 방법을 모색하며, 최신 기술을 적극적으로 활용하고 있으며, 2014년 공동 설립한 뮌헨 AWS 사용자 그룹과 AWS 행사에서 발표자로도 자주 초빙되었습니다.
IT 분야는 물론, 모든 비즈니스 부분에서 언제나 업무에 적합한 올바른 도구나 서비스를 선택하는 것은 굉장히 어려운 과제입니다. 이 글에서는 저희 Team Internet이 더 나은 솔루션을 구축하고 문제를 보다 효율적으로 해결하기 위해 다양한 AWS 도구를 활용하는 데 사용한 몇 가지 조언을 공유하고자 합니다.
새로 만들것인가?
IT 엔지니어, 설계자 또는 개발자가 맡은 일상적인 업무는 문제에 대한 솔루션을 구축하거나 비즈니스 프로세스를 소프트웨어로 전환하는 일입니다. 이를 위해 보통 기존의 아키텍처나 리소스를 사용하고 여기에 “추가 기능”을 구축하곤 합니다.
마이크로서비스가 출현하면서 작업의 모듈화와 분리에 확장성이 얼마나 중요한지 깨달았습니다. 그래서 전혀 다른 유형의 소프트웨어 아키텍처를 구축하게 되었습니다. 실제로 기존 Amazon EC2 인스턴스의 동일한 데이터베이스와 같이 기존의 리소스를 사용하려고 했습니다. 새로 구축하는 것보다 더 간편하다고 생각했기 때문입니다.
“마이크로서비스”는 어떨까?
Team Internet은 마이크로서비스라는 용어를 사용하지는 않지만, 다양한 사용 사례에서 유사한 스택과 빌딩 블록에 대해 이야기합니다. 우리의 접근 방식은 데이터베이스 및 처리해야 하는 특정 과제에 요구되는 기타 리소스를 포함하여 모든 면에서 마이크로서비스의 개념과 일치합니다.
“단순히” 소프트웨어 및 코드를 다른 모듈로 분할하는 것을 의미하지 않습니다. 전체 인프라는 서로 다른 요구에 따라 구분됩니다. 그리고 전체 아키텍처에서 이러한 각 부분이 스택에 해당하며, 스택은 전체 시스템에서 가능한 서로 독립적입니다. 인프라의 다른 스택이나 부분과 느슨하게 통신합니다.
이 접근 방식의 혜택 = 독립성과 유연성
- 부분 기능의 선택적 구축 가능: 모든 사용 사례에 대해 특정 과제에 가장 적합한 구성 요소나 서비스를 선택할 수 있으며, 제한 사항에 구속되지 않아도 됩니다. 특히, 데이터베이스에서 가장 효과적입니다. 해당 용도로 구축되지 않은 DBMS로 요구 사항을 짜맞추는 대신, 전체 팔레트에서 선택하면 되기 때문입니다. 많은 쓰기 작업과 많은 읽기 작업 또는 구조화된 데이터와 구조화되지 않은 데이터와 같은 서로 다른 워크로드 요구를 구별할 수 있습니다.
- 상황에 따라 다시 구축 가능: 느슨하게 연결되었기 때문에 탄력적으로 전체 스택을 다시 구축할 수 있습니다. 이 특성을 통해 팀은 새로운 아이디어나 서비스로 개념 증명을 구축하고 프로덕션 시스템을 간섭하거나 저해하지 않고도 프로덕션 워크로드에서 병렬로 실행할 수 있습니다.
- 비용 절감: 여러 리소스를 실행하여 발생하는 운영상의 오버헤드는 AWS에서 처리하므로(“구분되지 않은 부담이 큰 작업이 없음”), 사용자 입장에서는 서비스 요금만 확인하면 됩니다. AWS에서 대부분의 요금 체계가 스택을 지원합니다. 데이터베이스의 경우 처리량(Amazon DynamoDB) 또는 인스턴스 기반(Amazon RDS 등)으로 비용을 지불합니다. 처리량 수준에 기반하는 경우 오버헤드 없이 하나 이상의 테이블에서 처리량을 분할하면 되므로 매우 간단합니다. 인스턴스 수준에 기반하는 경우 가격은 선형 함수로 계산되므로, r4.xlarge는 r4.2xlarge 요금의 절반에 해당합니다. 2개의 r4.xlarge를 실행하고 워크로드를 분할하는 방법을 채택해 보십시오!
- 탄력성을 위한 설계: 이 접근 방식은 기본적으로 아키텍처의 안정성과 탄력성을 강화하는 데도 유용합니다. 스택은 서로 독립적이므로 확장은 보다 세분화된 단위로 가능합니다. 더 큰 시스템에서 확장하는 경우 상위 “보안 버퍼”가 종종 제공되며, 전체 시스템의 작은 부분에만 장애(하드웨어, 소프트웨어, 두 개 키 누름 등)가 국한됩니다.
- 자율적인 오너쉽 제공: 현재 이 방법을 사용할 경우 이점은 팀의 소유권과 책임에 긍정적인 영향을 준다는 점입니다. 이러한 스택을 통해 문제를 정확하고 쉽게 식별하고 해결할 수 있으며 어떤 스택을 누가 책임지는지 투명하고 확실하게 표시할 수 있습니다.
지속적으로 단점을 보완하라!
모든 접근 방식에는 단점이 있습니다. 이러한 시스템을 구축하려면 추가적인 개발과 아키텍처 관련 작업이 필요합니다.
그래서 언제나 서로 느슨하게 안정적으로 연결된 프로세스와 독립된 스택의 완벽한 시스템 구축을 목표로 정하였습니다. 하지만 실제로 규칙을 어기기도 했습니다. 그렇지만 이 접근 방식은 더 나은 시스템을 구축하고 적어도 혜택을 사라지는 지점을 정확히 파악하는 데 도움이 되었습니다. 여기에서 제공하는 설명과 통찰력이 작업에 적합한 도구를 선택하는 데 도움이 되었기를 바랍니다.
– Markus Ostertag;
AWS 기반 마이크로서비스 구축에 대한 더 자세한 것은 한국어 기술 백서(PDF)를 참고하세요!
Source: [AWS Heroes 특집] 마이크로서비스로 전환을 위한 작은 조언
