자료실

마이크로서비스에 대한 모든 것 - 1부

 


마이크로서비스에 대한 모든 것 - 1부


마이크로서비스 기반 개발이 갈수록 보편화되면서 많은 개발자가 마이크로서비스란 무엇이며, 데이터베이스 전문가에게 의미하는 바가 무엇인지 질문하고 있습니다. 총 3편으로 구성된 이 블로그 연재에서는 마이크로서비스의 정의와 전통적인 아키텍처와의 차이점, 그리고 서비스형 인프라(IaaS), 서비스형 데이터베이스(DBaaS), 서비스형 플랫폼(PaaS) 환경에 구축된 마이크로서비스의 성능에서 고려해야 하는 사항은 무엇인지 알아보겠습니다.


마이크로서비스란?

마이크로서비스란 무엇일까요? 많은 정의가 있지만, 여기서는 마이크로서비스를 일종의 연방 모델로 상호작용하는 여러 독립적인 서비스라고 정의하고자 합니다. 각 서비스는 서로 느슨하게 결합되지만, 관리나 유지, 테스트, 배포는 어느 정도 독립적으로 가능합니다. 마이크로서비스는 대체로 특정 비즈니스 기능 또는 애플리케이션 기능 영역을 기반으로 한 서비스입니다.


데이터베이스 관점에서 볼 때, 데이터 스토어가 사용되고 애플리케이션과 상호작용하는 방법은 전통적인 애플리케이션 아키텍처와는 매우 다를 수 있습니다. 일반적으로 마이크로서비스에서는 자체 데이터베이스 또는 데이터 스토어에 각 서비스가 구축됩니다. 실제로 관계형 데이터베이스에서 애플리케이션이 구축되는 방식과는 상당히 다릅니다. 전통적인 애플리케이션 아키텍처에서 애플리케이션은 보통 데이터 프로세스 관리, 조작, 조율에 사용되는 테이블, 쿼리, 프로시저 및 트리거와 함께 단일 데이터베이스에 구축됩니다.


전통적인 개발 패턴에서는 데이터베이스 내의 저장 프로시저로 데이터 요소의 비즈니스 로직과 조작을 수행했습니다. 이런 방법에는 많은 장단점이 있는데, 깊게 살펴보지는 않을 것입니다. 다만 전통적인 모델은 애플리케이션을 업그레이드하고 변경할 때 어려움을 겪습니다. 데이터베이스에 구축된 저장 프로시저에 대한 의존도가 높은 만큼 업그레이드 차원으로 애플리케이션이나 UI를 변경하려면 저장 프로시저를 다시 빌드하거나 다시 작성해야 하는 경우가 많기 때문입니다.


또한 이런 데이터베이스의 저장 프로시저 때문에 개발자는 애플리케이션과 데이터베이스 계층에 비즈니스 로직을 각각 생성해야 했습니다. 이 작업을 간소화하기 위해 개발자는 데이터베이스보다 애플리케이션 계층에 비즈니스 로직을 구축하는 데 더 중점을 두기 시작했지만, 완전히 분리할 수는 없었습니다. 데이터베이스에서 비즈니스 로직을 제거하더라도 여전히 많은 테이블이 상호 관계를 유지합니다. 관계형 데이터베이스 모델의 상호종속성으로 인해 QA가 절대적으로 중요해집니다. 애플리케이션에서 한 부분이 변경됐을 때 전혀 관계되지 않은 다른 곳에서 회귀 현상이 나타날 수도 있기 때문입니다. 애플리케이션이 하나의 데이터베이스 플랫폼에 의존하는 상황에서 애플리케이션 기능이 점점 많아지게 되면 이런 문제는 필연적으로 발생합니다. 트랜잭션 규모가 큰 애플리케이션에서는 문제가 더욱 심해집니다.


이런 문제에 대처하기 위해 개발 패턴이 바뀌고 있으며, 많은 애플리케이션 팀이 마이크로서비스 기반 아키텍처로 애플리케이션을 구축하고 있습니다. 마이크로서비스에서 각 서비스는 독립적이며 다른 서비스와 느슨하게 결합합니다. 이 느슨한 결합은 서비스 간 핸드셰이킹을 지원하는 API로 이뤄집니다. 이는 각 서비스가 상당히 독립적이며, 다른 서비스에 회귀 현상을 유발하지 않으면서 각 서비스를 별도로 릴리스할 수 있음을 의미합니다. QA 관점에서 매우 유리할 수 있고 개별 서비스의 릴리스 주기를 더 짧게 설정할 수 있습니다. 느슨한 결합 덕분에 애플리케이션 개발 시 각 서비스가 자체적으로 생존 및 발전할 수 있는 연방 모델을 생성하는 것입니다.


마이크로서비스가 무엇인지 더 살펴보면, 각 서비스가 자체 데이터베이스 위에 구축된다는 특징을 알 수 있습니다. 전통적인 아키텍처에서는 여러 서비스를 제공하는 단일 애플리케이션이 하나의 데이터베이스에 위치하지만, 각 마이크로서비스는 개별적으로 분리된 데이터베이스에서 실행됩니다. 마이크로서비스 데이터베이스에 상호 관련된 테이블이 있을 수 있지만, 전통적인 아키텍처의 애플리케이션보다 규모는 훨씬 작습니다.


서비스가 자체 데이터베이스를 보유하는 아키텍처에서는 기능 간 상호종속성도 많이 제거되므로, 각 서비스를 독립적으로 개발할 수 있습니다. 애플리케이션과 데이터베이스의 상호작용도 API를 통해 수행되기 때문에 비즈니스 로직 대부분은 데이터베이스가 아닌 애플리케이션에 위치합니다. 모든 종류의 절차적 언어 로직은 해당하는 특정 마이크로서비스에만 영향을 미치며, 애플리케이션 환경 내의 다른 마이크로서비스에는 영향을 미치지 않습니다.


마이크로서비스 개발 모델은 대체로 새로운 클라우드 네이티브 애플리케이션과 연결되지만, 마이크로서비스라는 개념은 클라우드 기반 환경에만 적용되는 것이 아닙니다. 마이크로서비스 아키텍처가 대부분 클라우드에 배포된 상황 속에서, 고려해야 할 몇 가지 배포 방식이 있습니다.


IaaS에서 각 서비스는 자체 데이터베이스에 배포되며 API를 사용하여 다른 서비스와 상호작용합니다. 이런 모델에서의 개발은 일반적으로 컨테이너를 도입하고 쿠버네티스를 사용하여 애플리케이션을 조율하는 방식으로 접근합니다. 확장을 실현하는 동시에 애플리케이션에 대한 폭넓은 제어 기능을 제공할 수 있는 접근법입니다.


아마존 관계형 데이터베이스(AWS RDS), 아마존(AWS Aurora), 애저 SQL 데이터베이스(Azure SQL DB), 애저 코스모스(Azure Cosmos)와 같은 DBaaS 플랫폼을 사용하면 데이터베이스 업그레이드 및 패치, 백업과 관련된 다양한 일상적인 작업을 DBaaS 제품에서 직접 처리할 수 있습니다.


마이크로서비스 구조는 단일 데이터베이스의 단일 애플리케이션 내에서 테이블, 기능 같은 요소 간 종속성이라는 짐을 덜 수 있게 해줍니다. 하지만 이 같은 유형의 애플리케이션을 관리할 때 새로운 문제가 발생할 수 있습니다.


지금까지 ‘마이크로서비스란 무엇인가’라는 질문에 답했습니다. 2부와 3부에서는 마이크로서비스 기반 애플리케이션 성능을 모니터링할 때 고려해야 할 점과 과제에 대해 살펴보겠습니다.


데이터베이스, 마이크로서비스에 대해 궁금한 점이 있으시면 언제든 퀘스트소프트웨어 코리아로 문의 주시기 바랍니다.


퀘스트소프트웨어코리아(주)

서울특별시 강남구 테헤란로 445 본솔빌딩10F
전화 번호 02-3420-9000 | 팩스 번호 02-569-3600

전자 메일 KoreaMarketing@quest.com 


Copyright © Quest. All Rights Reserved.

Hosting by I'MWEB


퀘스트소프트웨어코리아(주) 서울특별시 강남구 테헤란로 445 본솔빌딩10F
전화 번호 02-3420-9000 | 팩스 번호 02-569-3600 | 전자 메일 KoreaMarketing@quest.com


Copyright © Quest. All Rights Reserved.

Hosting by I'MWEB