마이크로 서비스를 구축하기 위해 기술을 도입하는 것은 부인할 수 없는 일이며, 그럴 만한 이유가 있습니다. 소규모 구성 요소는 현대적인 제공 방식 및 목표와 잘 결합됩니다. Gartner에 따르면 비즈니스 리더 3명 중 2명은 경쟁력을 유지하기 위해 디지털화의 속도를 높여야 한다고 생각합니다. 이에 따라 기업은 소프트웨어 제공 속도를 높이기 위해 노력하고 있습니다. 또한 작은 변경 세트와 블라스트 반지름으로 더 작은 구성 요소를 만드는 것도 좋은 방법입니다. 구성 요소를 테스트하고, 안전하게 보호하고, 안전하게 배포하고, 다른 구성 요소와 독립적으로 확장하는 것이 더 쉽기 때문입니다. Puppet Labs에 따르면 소규모 구성 요소를 DevOps 작업 방식과 결합하면 구축 빈도가 46배 높아지고 장애율이 5배 낮아집니다. 이러한 이점이 매력적이지만, 현실은 마이크로 서비스 구축에는 복잡성과 새로운 과제가 수반된다는 점입니다. 그리고 마이크로 서비스를 사용하는 것이 최신 트렌드이긴 하지만, 우리는 쉽게 변경하고, 기능을 추가하고, 이해하고, 작동시키는 단석의 장점을 무시해서는 안 됩니다. 저는 우리가 모노리석을 계속 만들 것을 제안하는 것이 아닙니다.
몇 년 동안 “서비스”와 “서비스 지향 아키텍처”에서 “마이크로 서비스”로 발전했습니다. 이러한 용어의 변화는 서비스를 구축할 때 크기가 중요하다는 것을 의미할 수 있습니다. 그리고 저는 그것이 일반적으로 사실이라고 믿습니다. 하지만 마이크로는 얼마나 작을까요? 서비스에 적합한 크기를 찾는 것은 과학이 아니라 예술이며, 우선 순위의 결과여야 합니다. 우리는 무엇보다도 고객에게 초점을 맞추고자 하며, 고객을 유지하기 위해서는 비즈니스 민첩성과 혁신을 향상시켜야 합니다. 그러기 위해서는 가치를 더 자주 제공하고 고객의 피드백과 변화하는 요구에 적응할 수 있어야 합니다. 피드백에 가장 잘 대응하려면 고객(내부 및 외부)이 사용하는 제품을 소유할 인력(팀)이 고객 문제에 친숙해져야 합니다. 그러면 팀이 문제를 해결하고 고객을 대신하여 발명할 수 있도록 권한을 부여하고 인센티브를 제공할 수 있습니다.
제품 또는 서비스를 소유하기 위해, 우리는 일반적으로 제품 또는 서비스의 단일 구성요소를 담당하는 소규모 팀(일반적으로 5명에서 10명)으로 구성됩니다. 구성 요소는 아이디어화부터 운영까지 팀이 완전히 소유할 수 있을 정도로 작아야 합니다. 단일 2피자 팀이 여러 구성 요소를 소유할 수 있을 정도로 구성 요소가 단순하다면 그렇게 할 수 있습니다. 그러나 복잡성이 증가함에 따라 이러한 구성 요소를 의도적으로 단순화하여 크기를 줄이거나 여러 구성 요소로 분할하여 각 구성 요소를 단일 팀이 완전히 소유할 수 있도록 해야 합니다.
What’s in a name?
단일체에 대한 정의와 상관없이, 우리가 지금 움직이고 있는 것은 너무 많은 것을 시도하고 속도를 억제하는 긴밀하게 결합된 애플리케이션이라는 것에 동의할 수 있을 것 같습니다. “마이크로 서비스”, “매크로 서비스” 또는 “서비스”라고 불러도 상관 없습니다. 12단계 앱 방법론은 현대 응용프로그램의 구조, 구성 및 업무 분리의 좋은 출발점을 제공합니다. 종속성 관리, 환경별 구성, 배포 등에 집중함으로써 애플리케이션 운영 및 변경이 더욱 쉬워집니다.
진행하면서 배우기
빠른 실험과 학습이 가능한 환경을 구축하기 위해 노력함에 따라 소프트웨어를 신속하게 구축 및 릴리스해야 합니다. 서버리스(Serverless)는 기업이 비즈니스 논리에만 집중하고 클라우드 공급자의 빌딩 블록을 활용하여 쉽게 솔루션을 구축할 수 있도록 지원함으로써 이를 실현하는 데 도움을 주고 있습니다. 하지만 때때로 문제는 복잡합니다. 초기에는 현재 구축 중인 구성요소의 사용자 요구, 데이터 라이프사이클, 확장 프로파일 또는 사용 패턴에 대한 완전한 이해나 감상이 부족한 경우가 많습니다. 각 구성 요소는 이동 중인 것으로 간주해야 합니다. 구성 요소는 폐기될 때까지 계속 개선되어야 합니다. 우리는 그 과정에서 배우고 개선해야 합니다. 서버 없는 서비스나 마이크로 서비스에 대한 모든 이야기는 처음부터 가능한 한 작게 만들도록 강요할 수 있지만, 저는 거친 방식으로 시작하여 시간이 지남에 따라 최적화하고 단순화하는 데 초점을 맞추는 것이 훨씬 더 쉽다고 생각합니다. 소유권을 중심으로 팀을 구성하고 시간이 지남에 따라 구성 요소를 소유 및 개선하여 고객 가치를 보다 효과적으로 제공할 수 있습니다. 가능한 모든 사용 사례를 포괄하는 완벽한 세분화된 서비스셋은 구축에 시간이 걸리고 스마트한 기반처럼 보일 수 있습니다. 하지만 이러한 서비스가 필요한지 어떻게 알 수 있습니까? 대신 시간이 지남에 따라 반복, 축소, 리팩터링을 통해 실제로 필요한 구성 요소를 구축할 수 있어야 합니다.
끊임없이 작은 반복을 반복하고 크기에 대한 걱정은 그만 두세요. 소유권과 개선을 약속하고 서비스를 구축합니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
본 문서는 Considering Size and Scope of Services 내용에 기반하여 작성 되었습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
