마이크로서비스

위키백과, 우리 모두의 백과사전.

마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍처에서 서비스들은 섬세(fine-grained)하고 프로토콜은 가벼운 편이다. 애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어 준다.[1] 규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다.[2] 또, 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용한다.[3] 마이크로서비스 기반 아키텍처는 지속적 배포와 전개(디플로이)를 가능케 한다.[1][4]

개요[편집]

마이크로서비스의 속성과 관련하여 아직 산업적인 합의는 없으며 공식적인 정의도 없다. 자주 인용되어 정의되는 특징들 가운데 일부는 다음을 포함한다:

  • 마이크로서비스 아키텍처(microservice architecture, MSA)의 서비스들[5]은 HTTP와 같은 기술 불가지론적인 프로토콜을 사용하여 목표를 달성하기 위해 네트워크를 통해 통신하는 프로세스들인 경우도 있다.[6][7][8] 그러나, 서비스들은 공유 메모리와 같은 다른 종류의 프로세스 간 통신 메커니즘을 사용할 수도 있다.[9] 서비스들은 이를테면 OSGI 번들에서처럼 동일한 프로세스 내에서 실행할 수 있다.
  • 마이크로서비스 아키텍처의 서비스들은 독립적인 전개(deploy)가 가능하다.[10][1]
  • 서비스의 교체가 쉽다.
  • 서비스는 기능별로 분류된다. (예: 사용자 인터페이스 프론트엔드, 추천, 로지스틱스, 청구서 발부 등)
  • 서비스는 최적의 조건에 부합하는 바에 따라 각기 다른 프로그래밍 언어, 데이터베이스, 하드웨어, 소프트웨어 환경을 사용하여 구현할 수 있다.[1]
  • 서비스들은 규모가 작고, 메시지 전달이 가능하며 컨텍스트별로 묶이며 자율적으로 개발되며 독립적으로 전개할 수 있으며 분산적이며 빌드가 되며 자동화된 프로세스들로 출시된다.[10]

마이크로서비스 기반 아키텍처는:

역사[편집]

2011년 5월 베니스에서 개최된 소프트웨어 아키텍처의 워크숍에서 "마이크로서비스"(microservice)라는 용어를 사용하여 참여자들이 공통의 아키텍처 스타일을 본바, 즉 참여자 중 다수가 최근 탐구했던 바를 기술하였다. 2012년 5월, 동일 그룹은 "마이크로서비스"를 가장 적절한 이름으로 결정하였다. 제임스 루이스는 2012년 3월 33rd Degree in Kraków in Microservices - Java, the Unix Way에서 사례 연구로 이 아이디어 가운데 일부를 발표했는데, 이는 프레드 조지가 거의 같은 시기에 했던 내용과 같다. "섬세한 SOA"(fine grained SOA)으로 이러한 접근을 설명한 넷플릭스의 에이드리언 콕크로프트는 웹 규모로 이 스타일을 개척했는데, 다른 사람들 다수(Joe Walnes, Dan North, Evan Bottcher, Graham Tackley)가 이 문서에서 언급한 바와 같다.[15]

철학[편집]

마이크로서비스 아키텍처의 철학은 필연적으로 "한 가지 일을 하되 잘하라"(Do one thing and do it well)는 유닉스 철학과 상응한다. 다음과 같이 기술된다:[16][17][18]

  • 서비스의 크기는 작다 - 하나의 기능을 수행하는데 섬세(fine-grained)하다.
  • 조직 문화는 테스트 및 전개의 자동화를 받아들여야 한다. 이를 통해 관리 및 운용상의 부담을 완화하며 다른 개발팀들이 코드의 전개 가능한 단위를 독립적으로 작업할 수 있게 한다.[19]
  • 문화와 디자인 철학은 안티프래질 시스템과 비슷하게 실패와 고장을 받아들여야 한다.
  • 각 서비스를 유연하고 회복력 있고 구성할 수 있으며 최소한이고 완전하다.[18]

기술[편집]

컴퓨터 마이크로서비스들은 각기 다른 프로그래밍 언어로 구현할 수 있으며 각기 다른 인프라스트럭처를 사용할 수 있다. 그러므로 가장 중요한 기술적 선택은 마이크로서비스가 서로(동기, 비동기, UI 연동) 통신하고 프로토콜이 통신을 위해 사용되는 방식(REST, 메시징, ...)을 의미한다. 전통적인 시스템에서 프로그래밍 언어와 같은 대부분의 기술적인 선택들은 시스템 전반에 영향을 미친다. 그러므로 기술 선택을 위한 접근법은 상당히 다르다.[20]

비평[편집]

마이크로서비스의 접근은 수많은 문제의 비평에 종속된다:

  • 서비스들은 정보의 장벽을 형성한다[21]
  • 네트워크상의 서비스 간 호출은 모놀리식 서비스 프로세스 내의 프로세스 내 호출과 비교해 네트워크 레이턴시, 메시지 처리 면에서 비용이 더 많이 든다[6]
  • 테스트와 전개는 더 복잡하다[22]
  • 서비스 간에 책무를 이동하는 일은 더 어렵다.[1] 서로 다른 팀 간의 커뮤니케이션을 수반하거나 다른 언어로 기능을 재작성하거나 이를 다른 인프라스트럭처로 맞추는 일이 수반될 수 있다[6]
  • 서비스들의 규모를 주된 구조적 메커니즘으로 바라보면 너무 많은 서비스를 생성하는 결과를 낳을 수 있다(내부 모듈화의 대안이 더 단순한 디자인으로 이어질 때).[23]

같이 보기[편집]

각주[편집]

  1. ↑ 가 나 다 라 마 바 Chen, Lianping (2018). 《Microservices: Architecting for Continuous Delivery and DevOps》. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE. 
  2. ↑ Richardson, Chris. “Microservice architecture pattern”. 《microservices.io》 (영어). 2017년 3월 19일에 확인함. 
  3. ↑ Chen, Lianping; Ali Babar, Muhammad (2014). 《Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development》. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE. 
  4. ↑ ceracm (2017년 1월 4일). “Microservices-based architectures enable continuous delivery/deployment”. 《Eventuate.IO》. 2017년 3월 20일에 원본 문서에서 보존된 문서. 2017년 3월 19일에 확인함. 
  5. ↑ Nicola Dragoni; Saverio Giallorenzo; Alberto Lluch Lafuente; Manuel Mazzara; Fabrizio Montesi; Ruslan Mustafin; Larisa Safina. “Microservices: yesterday, today, and tomorrow” (PDF). arXiv:1606.04036. Bibcode:2016arXiv160604036D. 2017년 5월 2일에 확인함. 
  6. ↑ 가 나 다 라 마 Martin Fowler. “Microservices”. 2018년 2월 14일에 원본 문서에서 보존된 문서. 
  7. ↑ Newman, Sam. 《Building Microservices》. O'Reilly Media. ISBN 978-1491950357. 
  8. ↑ Wolff, Eberhard. 《Microservices: Flexible Software Architectures》. ISBN 978-0134602417. 
  9. ↑ “Micro-services for performance”. 《Vanilla Java》. 2017년 3월 19일에 확인함. 
  10. ↑ 가 나 Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O’Reilly 2016
  11. ↑ “IFS: Microservices Resources and Positions”. 《hsr.ch》. 2016년 12월 28일에 확인함. 
  12. ↑ Nicola Dragoni; Schahram Dustdar; Stephan T. Larsen; Manuel Mazzara. “Microservices: Migration of a Mission Critical System” (PDF). arXiv:1704.04173. Bibcode:2017arXiv170404173D. 2017년 5월 2일에 확인함. 
  13. ↑ Nicola Dragoni; Ivan Lanese; Stephan Thordal Larsen; Manuel Mazzara; Ruslan Mustafin; Larisa Safina. “Microservices: How To Make Your Application Scale” (PDF). arXiv:1702.07149. Bibcode:2017arXiv170207149D. 2017년 5월 2일에 확인함. 
  14. ↑ Manuel Mazzara; Kevin Khanda; Ruslan Mustafin; Victor Rivera; Larisa Safina; Alberto Sillitti. “Microservices Science and Engineering” (PDF). arXiv:1706.07350. Bibcode:2017arXiv170607350M. 2017년 11월 14일에 확인함. 
  15. ↑ James Lewis; Martin Fowler. “Microservices”. 
  16. ↑ Lucas Krause. 《Microservices: Patterns and Applications》. ASIN B00VJ3NP4A. 
  17. ↑ Lucas Krause. “Philosophy of Microservices?”. 2016년 11월 12일에 원본 문서에서 보존된 문서. 2018년 9월 27일에 확인함. 
  18. ↑ 가 나 Jim Bugwadia. “Microservices: Five Architectural Constraints”. 2016년 3월 3일에 원본 문서에서 보존된 문서. 2018년 9월 27일에 확인함. 
  19. ↑ Li, Richard. “Microservices Essentials for Executives: The Key to High Velocity Software Development”. 《Datawire》. Datawire, Inc. 2016년 10월 21일에 확인함. 
  20. ↑ Wolff, Eberhard. 《Microservices - A Practical Guide》. ISBN 978-1717075901. 
  21. ↑ Jan Stenberg (2014년 8월 11일). “Experiences from Failing with Microservices”. 
  22. ↑ “Developing Microservices for PaaS with Spring and Cloud Foundry”. 
  23. ↑ Tilkov, Stefan (2014년 11월 17일). “How small should your microservice be?”. 《innoq.com》. 2017년 1월 4일에 확인함. 

추가 문헌[편집]

원본 주소 "https://ko.wikipedia.org/w/index.php?title=마이크로서비스&oldid=34888929"