• Why Microservices?

  • 왜 마이크로서비스일까?

  • Companies like Netflix, Amazon, and others have adopted the concept of microservices in their products. Microservices are one of the hottest topics in the software industry, and many organizations want to adopt them. Especially helpful is the fact that DevOps can play very well with microservices.
  • 넷플릭스, 아마존 같은 회사들은 그들의 제품에 마이크로서비스 개념을 적용 했습니다. 마이크로 서비스는 소프트웨어 산업에서 가장 뜨거운 주제 중 하나이며 많은 기업들이 마이크로서비스를 도입하고 싶어합니다. 특히 마이크로서비스는 데브옵스와 매우 잘 어울립니다.
  • But what is a microservice? Why should  an organization adopt them?
  • 하지만 마이크로서비스란 무엇일까요? 기업들이 마이크로서비스를 적용해야 하는 이유가 무엇일까요?
  • To understand them, let's first take a look at monolithic software.
  • 마이크로서비스의 정의와 적용해야하는 이유를 이해하기 위해서 먼저 단일형(monolithic) 소프트웨어를 살펴보겠습니다.
  • In monolithic software, we mainly use a three-tier architecture:
  • 단일형 소프트웨서는 주로 3계층(3-tier) 아키텍쳐를 사용 합니다.
  • - Presentation layer
  • - 프리젠테이션 계층
  • - Business layer
  • - 비즈니스 계층
  • - Data access layer
  • - 데이터 접근 계층
  • Say a traditional web application client (a browser) posts a request. The business tier executes the business logic, the database collects/stores application specific persistence data, and the UI shows the data to the user.
  • 전통적인 웹 애플리케이션 클라이언트(브라우저)가 요청을 전송했다고 가정해 봅시다. 비즈니스 계층은 비즈니스 로직을 실행하고, 데이터베이스에서 특정 데이터를 불러오고/저장하고, UI를 통해 데이터를 사용자에게 보여줍니다.
  • However, there are several problems with this type of system. All code (presentation, business layer, and data access layer) is maintained within the same code base. Although logically we divide the services like JMS Service and Data-Access Service, they are on the same code base and deployed as a single unit.
  • 그러나 여기에는 3계층 시스템이 갖는 몇 가지 문제점이 있습니다. 모든 코드(프리젠테이션, 비즈니스, 데이터 접근)가 같은 코드베이스를 통해 관리 됩니다. 비록 논리적으로는 우리가 JMS 서비스, 데이터-접근 서비스 처럼 나누어 생각할 수 있지만 같은 코드베이스에 위치하며 하나의 단위로 배포 됩니다.
  • Even though you created a multi-module project, one module is dependent on another and, moreover, the module needs dependent modules in its class path. Although you use a distributed environment, it runs under single process context
  • 개발자가 다중 모듈 프로젝트로 만들었다고 할지라도 하나의 모듈이 다른 모듈에 의존적이며 게다가 의존성이 있는 모듈은 같은 클래스 경로에 위치해야 합니다. 비록 분산 환경을 사용하고 있다하더라도 프로그램은 단일 프로세스 컨텍스트 아래에서 동작합니다.
  • So, in a single process, different services are communicating with each other. To achieve this, all artifacts and their required libraries (jars) are required in each application container.
  • 따라서 다른 서비스들이 단일 프로세스 안에서 서로 커뮤니케이션을 합니다. 원활한 커뮤니케이션을 위해서는 모든 아티팩트(artifiact)와 필요한 라이브러리가 각각의 응용프로그램 컨테이너에 들어있어야 합니다.
  • Say a JMS service want to use the data access layer. The JMS container needs the data access layer jars and the jars upon which the data access layer is dependent (second level dependencies).
  • JMS 서비스가 데이터 접근 계층을 사용하기 원한다고 가정해 봅시다. JMS 컨테이너는 데이터 접근 계층의 jar과 데이터 접근 계층이 의존하고 있는 jar들(2단계 의존성)이 모두 필요합니다.
  • In this concept, there are lots of pain points, and the architecture is very rigid in nature.
  • 계념적으로 많은 에로사항(pain points)이 존재하며 사실상 아키텍쳐측면에서 매우 융통성이 없습니다.
  • Here are some of the problems you face with a monolith.
  • 단일형 스프트웨어를 개발할때 직면할 수 있는 몇가지 문제점들을 나열 해보겠습니다.
  • Problem 1

  • 문제점 1

  • As there is one codebase, it grows gradually. Every programmer, whether it's a UI Developer or a business layer developer, commits in same code base, which becomes very inefficient to manage. Suppose one developer only works in the JMS module, but he has to pull the whole codebase to his local and configure the whole module in order to run it on a local server. Why? He should only concentrate on the JMS module, but the current scenario doesn't allow for that.
  • 하나의 코드베이스인체로 코드가 점차적으로 증가합니다. UI 개발자, 비즈니스 계층 개발자를 불문하고 모든 개발자는 같은 코드 베이스 내에서 커밋을 하며 코드를 관리하는 것이 매우 비효율적이 되어버립니다. 개발자가 오직 JMS 모듈 안에서 개발을 하고 있다고 가정해봅시다. 하지만 개발자는 코드베이스 전체를 그의 로컬 컴퓨터에 받은 후 로컬 서버에서 실행할 수 있게 전체 모듈을 설정해야 합니다. 왜 그래야만 할까요? 개발자는 JMS 모듈에만 집중해야 하지만 현재 시나리오에서는 JMS 모듈에만 집중하는 것이 불가능합니다.
  • Problem 2

  • 문제점 2

  • As there is one code base and modules are dependent on each other, minimal change in one module needs to generate all artifacts and needs to deploy in each server pool in a distributed environment.
  • 하나의 코드 베이스에서 모듈은 서로 의존적이기 때문에 한개의 모듈안에서 최소의 변경 사항도 모든 아티팩트를 생성하고 분산된 각 서버풀에 배포 해야합니다.
  • Suppose in a multi-module project that the JMS module and business module are dependent on the data access module. A simple change in the data access module means we need to re-package the JMS module and business module and deploy them in their server pool.
  • JMS 모듈과 비즈니스 모듈이 데이터 접근 모듈에 의존성이 있는 멀티-모듈 프로젝트가 있다고 가정해봅시다. 데이터 접근 모듈의 간단한 변경사항 하나도 개발자가 JMS모듈과 비즈니스 모듈을 재패키지하고 서버풀에 배포해야합니다.
  • Problem 3

  • 문제점 3

  • As monolithic software uses a three-tier architecture, three cross-functional teams are involved in developing a feature. Even though a three-tier architecture allows for separation of responsibility, in the long-run, the boundaries are crossed and the layers lose their fluidity and become rigid.
  • 세 개의 다기능 팀이 3-티어 아키텍쳐를 사용하는 단일체 소프트웨어에 추가 될 한가지 기능 개발에 참여하고 있습니다. 비록 3-계층 아키텍쳐가 책임의 분리를 제공함에도 불구하고 장기적인 관점에서는 경계는 서로 겹치게되고 계층은 유연함을 잃고 경직되게 됩니다.
  • Suppose an inventory management feature has been developed. The UI, business layer, and data access layer have their own jobs. But everyone wants to take control of the main business part so that when defects come up, they can solve them and are not dependent on another layer's developer. Due to this competition, those boundaries end up being crossed, which results in inefficient architecture.
  • 재고 관리 기능이 개발되었다고 가정해봅시다. UI, 비즈니스 계층, 데이터 접근 계층은 각자 맡은 일이 있습니다. 하지만 모든 계층에서 자신의 주 업무 부분을 제어하길 원합니다. 다시 말하면 결함이 발생하는 경우 맡은 각자의 계층에서 다른 계층의 개발자에 의존하지않고 문제를 해결할 수 있기를 원합니다. 이러한 경쟁 때문에 경계는 끝내 서로 겹치게되며 결과적으로 비효율적인 아키텍쳐가 됩니다.
  • Problem 4

  • 문제점 3

  • In many projects, I have seen that there is a developer team and another support team. The developer team only develops the project, and after it's released, they hand it over to the support team. I personally don't support this culture. Although some knowledge transfer happens during the handover, it doesn't solve the problem. For critical incidents, the support team has to get help from the developer team, which hurts their credibility.
  • 많은 프로젝트에서 필자는 개발팀과 다른 여러 지원팀으로 나뉘어 있는것을 보았습니다. 개발팀은 오직 프로젝트 개발하고 프로젝트 출시 이후에는 지원팀에 프로젝트를 인계합니다. 개인적으로 이러한 문화에 찬성하지 않습니다. 비록 약간의 지식은 인계하는 동안에 전달되겠지만 그것만으로는 문제를 해결하기에는 부족합니다. 심각한 문제의 경우 지원팀은 개발팀으로부터 도움을 받아야 하며 이는 지원팀의 신용에 상처를 나게합니다.
  • Problem 5

  • 문제점 5

  • As our system is monolithic, so is our team management. Often, we create teams base on the tier — UI developers, backend developers, database programmers, etc. They are experts in their domains, but they have little knowledge about other layers. So when there's a critical problem, it encompasses each layer, and the blame game starts. Not only that, but it takes additional time to decide which layer's problem it is and who needs to solve the issue
  • 시스템이 단일체 구조이기 때문에 팀 관리 또한 단일체 구조가 됩니다. 보통 계층을 기반으로 UI 개발자, 백엔드 개발자, 데이터베이스 프로그래머, 등으로 팀을 구성합니다. 팀 멤버들은 해당 도매인 내에서는 전문가이지만 다른 계층에 관해서는 약간의 지식만을 가지고 있습니다. 심각한 문제가 발생했을때 (자신이 맡은)각 계층을 둘러싸고 비난 게임이 시작됩니다. 비단 그뿐만 아니라 어떤 계층에 문제가 있는지와 누가 해당 문제를 해결해야 하는지를 결정하기 위한 추가적인 시간이 들어가게 됩니다.
  • Netflix and Amazon address these problems with a solution called microservices.
  • 넷플릭스와 아마존은 이러한 문제들을 위해 해결책으로 마이크로서비스를 언급합니다.
  • Microservice architecture tells us to break a product or project into independent services so that it can be deployed and managed solely at that level and doesn't depend on other services.
  • 마이크로서비스 아키텍쳐는 다른 서비스에 의존성이 없고 배포와 관리를 단독으로 할 수 있는 수준에서 제품 또는 프로젝트를 독립적인 서비스로 나누라고 이야기합니다.
  • After seeing this definition, an obvious question comes to mind. On what basis do I break down my project into independent services?
  • 이 정의를 보고난 후에 분명이 마음속에 드는 질문이 하나 있을겁니다. 어떤 기준으로 프로젝트를 독립적인 서비스로 나누어야 할까요?
  • Many people have the wrong idea about microservices. Microservices aren't telling you to break your project down based on the tier, such as JMS, UI, logging, etc.
  • 많은 사람들이 마이크로서비스에 대한 잘못된 생각을 가지고 있습니다. 마이크로서비스는 여러분의 프로젝트를 JMS, UI, 로깅, 기타처럼 계층을 기반으로 프로젝트를 나누라고 말하지 않습니다.
  • No this is absolutely not. We need to break it down by function. A complete function and its functionality may consist of UI, business, logging, JMS, data access, JNDI lookup service, etc.
  • 아닙니다. 분명하게 계층기반으로 나누라고 말하지 않습니다. 기능을 기반으로 프로젝트를 나누어야 합니다.
  • The function should not be divisible and not dependent on other functions.
  • 기능은 나누어질수 없으며 다른 기능에 의존성이 없어야 합니다.
  • So If the project has Inventory, Order, Billing, Shipping, and UI shopping cart modules, we can break each service down as an independently deployable module. Each has its own maintenance, monitoring, application servers, and database. So with microservices, there is no centralized database — each module has its own database.
  • 따라서 프로젝트가 만약 재고, 주문, 결재, 배송 그리고 장바구니 UI 모듈을 가지고 있다면, 우리는 각 서비스를 독립적으로 배포가능한 모듈로 나눌수 있습니다. 각 서비스는 각자의 관리, 모니터링, 어플리케이션 서버, 데이터베이스를 가지고 있습니다. 그래서 마이크로 서비스를 사용하면 중앙화된 데이터 베이스가 없습니다 - 각 모듈이 자신의 데이터베이스를 가자기고 있습니다.
  • And it could be a relational or a NoSQL database. The choice is yours based on the module. It creates a polyglot persistence.
  • 그리고 데이터 베이스는 관계형 또는 NoSQL 데이터베이스일 수 있습니다. 여러분의 모듈에 따라 선택하면 됩니다. 선택에 따라 폴리글랏 퍼시스턴스가 생성됩니다.
  • The most important aspect of microservice culture is that whoever develops the service, it is that team's responsibility to manage it. This avoids the handover concept and the problems associated with it.
  • 마이크로서비스 문화의 가장 중요한 특성은 서비스를 개발한 사람이 누구든지간에 서비스 관리는 팀의 책임이라는 것입니다. 이 특성은 인계라는 개념을 없애고 인계와 연관된 문제들을 방지합니다.
  • Microservice Benefits and Shortcomings

  • 마이크로서비스의 장점과 단점

  • Benefit 1

  • 장점 1

  • As in monolithic software, you only develop in one language, say Java, as the code base. But with microservices, as each service is independent and each service is a new project, each service can be developed in any language that is best fits for the requirement.
  • 단일체 소프트웨어에서는 코드 저장소로써 개발자는 오직 하나의 언어(예를들면 자바)로 개발합니다. 하지만 마이크로서비스에서는 각 서비스는 독립적이고 새로운 프로젝트이며 요구사항에 맞는 어떠한 언어든지 사용해서 개발될 수 있습니다.
  • Benefit 2

  • 장점 2

  • The developer is only concentrated on a particular service, so the code base will be very small, and the developer will know the code very well.
  • 개발자는 오직 특정 서비스만 집중하기 때문에 코드 저장소는 매우 작을 것이고 개발자는 코드를 잘 알고 있을 것입니다.
  • Benefit 3

  • 장점 3

  • When one service needs to talk with another service, they can talk via API, specifically by a REST service. A REST service is the medium to communicate through, so there is little transformation. Unlike SOA, a microservice message bus is much thinner than an ESB, which does lots of transformation, categorization, and routing.
  • 서비스가 다른 서비스와 통신할 필요가 있을때 API를 통해(구체적으로 REST 서비스에 의해) 서비스들은 통신할 수 있습니다. REST 서비스는 커뮤니키에션을 위한 중개자이기 때문에 매우 작은 변환만 있습니다. SOA와는 다르게 마이크로 서비스 메시지 버스는 아주 많은 변환, 분류, 라우팅을 하는 ESB보다 훨씬 더 얇습니다.
  • Benefit 4

  • 장점 4

  • There is no centralized database. Each module has its own, so there's data decentralization. You can use NoSQL or a relational database depending on the module, which introduces that polyglot persistence I mentioned before.
  • 중앙화된 데이터베이스가 없습니다. 각 모듈은 각자의 데이터베이스를 가지고 있기 때문에 데이터는 분산 되어있습니다. 개발자는 모듈에 따라 NoSQL 또는 관계형 데이터베이스를 사용할 수 있다는 사실은 전에 언급한 폴리글랏 퍼시스턴스를 데뷔시킵니다.
  • A lot of people think SOA and microservices are the same thing. By definition, they look the same, but SOA is used for communicating different systems over an ESB, where the ESB takes a lot of responsibility to manage data, do categorization, etc.
  • 많은 사람들이 SOA와 마이크로서비스가 같은것이라고 생각합니다. 정의에 따르면 같아 보이지만 SOA는 데이터를 관리하고 분류하는 등 많은 책임을 가진 ESB를 통해 서로 다른 시스템간에 통신을 위해 사용되었습니다.
  • But microservices use a dumb message bus which just transfers the input from one service to another, but its endpoint is smart enough to do the aforementioned tasksIt has a dumb message bus, but smart endpoints.
  • 하지만 마이크로서비스는 입력을 한 서비스에서 다른 서비스로 전송만하는 우둔한 메시지 버스(dumb message bus)를 사용하지만 메시지를 받는 엔드포인트는 전에 언급한 작업들을 할 수 있을 정도로 똑똑합니다. 마이크로서비스는 우둔한 메시지 버스를 가지고 있지만 똑똑한 엔드포인트가 있습니다.
  • As microservices communicate through REST, the transformation scope is very small — only one service is dependent on another service via API call.
  • 마이크로 서비스는 REST를 통해 통신을 하며 변환 범위는 API를 통해 호출하는 다른 서비스에 의존하는 오직 하나의 서비스로 아주 작습니다
  • But Microservices Have Shortcomings, Too

  • 하지만 마이크로서비스 또한 단점을 가지고 있습니다.

  • As every functional aspect is an individual service, so in a big project, there are many services. Monitoring these services adds to the overhead.
  • 모든 기능적 특성은 개별 서비스이며 따라서 큰 프로젝트에는 많은 서비스들이 있습니다. 이러한 서비스들을 모니터링하는 것은 오버헤드를 증가시킵니다.
  • Not only that, but when there's a service failure, tracking it down can be a painstaking job.
  • 그뿐만이 아니라 서비스가 장애가 나는 경우 장애를 추적하는 것은 힘든 작업이 될 수 있습니다.
  • Service calls to one another, so tracing the path and debugging can be difficult, too.
  • 서비스는 다른 서비스를 호출하기 때문에 경로를 추적하고 디버깅하는 것 또한 어렵습니다.
  • Each service generates a log, so there is no central log monitoring. That's painful stuff, and we need a very good log management system for it.
  • 각 서비스는 로그를 생성하기 때문에 중앙 로그 모니터링은 없습니다. 이는 매우 고통스러운 부분이며 장애를 대비해 아주 좋은 로그 관리 시스템을 필요로 합니다.
  • With microservices, each service communicares through API/remote calls, which have more overhead than with monolothic software's interprocess communication calls.
  • 마이크로서비스에서는 각 서비스는 단일체 소프트웨어의 프로세스간 통신에 비해 좀 더 큰 오버헤드를 가진 API/원격 호출을 통해 통신합니다
  • But in spite of all of those detriments, microservices do real separation of responsibilities.
  • 이러한 모든 결점에도 불구하고 마이크로서비스는 실제로 책임의 분리를 이뤄냅니다.
0 Comments