'microservice'에 해당되는 글 35건

Chapter 01. Microservices :: 2018/12/11 10:09

[Author : Sam Newman]


수년 동안 우리는 시스템을 구축할 수 있는 더 좋은 방법을 찾고 있습니다. 이전에 무엇을 했는지, 새로운 기술을 채택하고, 기술 회사의 새로운 물결이 어떻게 고객과 개발자들이 모두 행복하게 하는 IT시스템을 만들기 위한 다양한 방법을 운영하는지를 관찰했습니다.

 

Eric Evans의 책 Domain-Driven Design(Addison-Wesley)은 우리 코드에서 실제 세계를 표현하는 중요성을 이해하고, 우리 시스템을 더 좋은 방법으로 모델링하는 것을 보여주었습니다. 지속적인 배포(continuous delivery) 개념은 소프트웨어를 보다 효과적이고 효율적으로 상용 환경에 가져오는 방법을 보여주었고, 모든 체크인을 릴리즈 후보로 다루어야 한다는 아이디어를 우리가 가지게 했습니다. 웹이 어떻게 동작하는지에 대한 이해는 기계와 기계 사이에서 대화하는 더 좋은 방법을 개발하게 했습니다. Alistair Cockburn 6각형 아키텍처 개념은 비즈니스 로직이 숨어 있는 Layered Architecture에서 우리가 멀어지게 했습니다. 가상화 플랫폼은 인프라 자동화를 통해 머신의 규모를 다루는 방법을 우리에게 제공하여 프로비저닝과 리사이즈를 가능하게 했습니다.

 

아마존과 구글과 같은 일부 대규모의 성공적인 조직들은 서비스의 전체 수명 주기를 소유한 소규모 팀의 견해를 지지했습니다. 그리고 더 최근에, Netflix는 불과 10년 전만 해도 이해하기 힘든 거대한 규모의 단단한 시스템을 구축하는 방법을 공유했습니다.

 

- Domain-Driven Design

- Continuous Delivery

- On-Demand Virtualization (주문형 가상화)

- Infrastructure automation

- Small autonomous teams

- Systems at scale

 

마이크로서비스가 이 세상에 등장했습니다.

 

사실 마이크로서비스는 전에 발명되거나 설명된 것은 아닙니다. 실제 세상에서 사용함으로써 트렌드나 패턴으로 등정했습니다. 그러나 마이크로서비스는 이전에 있었던 모든 것들 때문에 존재합니다.

 

이 책을 통해서 마이크로서비스를 구축, 관리, 발전시키는 방법에 대한 그림을 그리는데 도움을 주어 이러한 최우선 업무에서 뛰어나게 할 것입니다.

 

많은 조직에서 잘 나누어진 마이크로서비스 아키텍처를 채택함으로써 소프트웨어를 빠르게 제공하고 새로운 기술들을 채택할 수 있었습니다.

 

마이크로서비스는 우리에게 더 자유롭게 반응하고 다른 의사 결정을 내려서 우리 모두에게 영향을 미치는 피할 수 없는 변화에 더 빠르게 대응할 수 있게 합니다.

 

What Are Micoservices?

 

마이크로서비스는 함께 동작하는 작고, 자율적인 서비스입니다. 이 정의를 좀 더 세분화하고 마이크로서비스를 다르게 하는 특성들에 대해서 고려해 보겠습니다.

 

Small, and Focused on Doing One Thing Well

(작고, 한가지를 잘하는 것에 집중)

 

코드베이스는 우리가 새로운 기능들을 추가하는 코드를 작성할 때 커집니다.  시간이 지남에 따라, 코드베이스가 커지기 때문에 어디를 변경해야 하는지 알기 어려워질 수 있습니다. 명확하고, 모듈화된 단단히 짜여 하나로 된(monolithic) 코드베이스 추진에도 불구하고, 이러한 제멋대로인 프로세스 내 경계가 너무 자주 파괴됩니다. 유사한 함수와 관계된 코드가 널리 퍼지기 시작하고, 버그 수정이나 프로그램 구현이 더 어려워집니다.

 

모놀리스 시스템에서 우리는 종종 추상화를 하거나 모듈화를 하여 코드가 더 응집되어 있는지를 확인하려고 노력함으로써 이러한 세력에 대항하여 싸웁니다.

 

관련 코드를 그룹으로 묶는 응집(Cohesion)은 마이크로서비스에서 중요한 개념입니다. 이것은 Robert C. Martin '단일 책임 원칙의 정의(Definition of the Single Responsibility Principle)'에 의해 강화되었습니다. "동일한 이유로 변경되는 것들을 함께 모아서 다른 이유로 변경되는 것들을 분리하라"라고 말하고 있습니다.

 

마이크로서비스는 독립적인 서비스에도 동일한 접근방식을 사용합니다.

우리는 주어진 기능 조각에 대한 살아있는 코드가 어디에 있는지를 명확하게 함으로 서비스 경계를 비즈니스 경계에 초점을 맞춥니다. 그리고 이 서비스가 분명한 경계에 초점을 유지함으로써, 서비스가 너무 커지는 유혹을 피할 수 있습니다. 이것이 소개할 수 있는 연관된 모든 어려움입니다.

 

제가 자주 묻는 질문은 작은 것이 얼마나 작습니까?라는 것입니다.

코드 라인수가 문제라면, 일부 언어는 다른 언어보다 더 표현력이 우수하므로 더 적은 라인에서 더 많은 일을 수행할 수 있습니다. 또한, 많은 코드 라인은 여러 의존성을 끌어낼 수 있다는 사실도 고려해야만 합니다. 더욱이, 도메인 중 일부는 당연히 복잡해서 더 많은 코드가 필요할 수 있습니다.

 

호주 RealEstate.com Jon Eaves는 특별한 맥락에서 의미가 있는 경험과 상식에 입각하여 마이크로서비스는 2주만에 다시 작성할 수 있는 어떤 것으로 특징지었습니다. 제가 드릴 수 있는 흔한 또다른 대답은 충분히 작고, 더 작아질 수 없다는 것입니다.

 

컨퍼런스에서 발표할 때, 너무 크고 쪼개고 싶어하는 시스템을 가진 사람이 누구냐고 거의 항상 묻습니다. 거의 모든 사람들이 손을 듭니다. 우리는 너무 큰 것이 무엇인지 잘 알고 있는 것처럼 보이기 때문에 코드 한 조각이 너무 크다고 더 이상 느껴지지 않을 때, 그것은 충분히 작다고 주장할 수 있습니다.

 

얼마나 작은가에 대해 대답하는데 도움이 되는 강력한 요소는 얼마나 서비스가 팀 구조와 맞춰져 있는가 입니다. 만약 코드베이스가 작은 팀이 관리하기에는 너무 크다면, 부수는 것을 생각해 보는 것이 매우 현명합니다. 나중에 조직 조정에 대해서 더 이야기할 것입니다.

 

작은 것이 충분히 작아졌을 때, 이런 측면에서 생각하고 싶습니다. : 서비스가 더 작아질수록 마이크로서비스의 장점과 단점을 극대화할 수 있다.

 

서비스가 더 작아질수록, 독립성 관점에서 장점이 증가합니다.

하지만, 점점 더 많은 가동부(moving parts)를 가지고 있음으로 드러나는 복잡성도 또한 커지는데 이 책을 통해서 탐구할 것입니다. 이러한 복잡성을 더 잘 처리할수록, 점점 더 작은 서비스를 위해 노력할 수 있습니다.

 

Autonomous

(자율적인?)

 

마이크로서비스는 분리된 개체입니다. PAAS(Platform As A Service)에 격리된 서비스로 배포되거나 그 자체로 OS(Operating System) 프로세스일 수 있습니다. 비록 오늘날 머신의 정의가 꽤나 흐릿하지만 동일한 머신에 여러 개의 서비스를 패키지하는 것을 피하려고 합니다. 나중에 논의하겠지만, 비록 이러한 격리로 인해 약간의 오버헤드가 추가될 수 있지만, 단순성의 결과는 분산 시스템의 추론을 훨씬 더 쉽게 하고, 더 새로운 기술들이 이러한 형태의 배포와 관련된 많은 문제들을 완화할 수 있습니다.

 

서비스 간의 모든 커뮤니케이션은 서비스 간의 분리를 강화하고 긴밀한 결합의 위험을 피하기 위해서 네트워크 호출을 통해 이루어집니다.

 

이러한 서비스는 서로 독립적으로 변경될 수 있어야 합니다. 그리고 소비자의 변경 요구 없이 스스로 배포되어야 합니다. 우리의 서비스가 무엇을 노출해야 하고, 무엇을 숨겨야 하는지를 생각할 필요가 있습니다. 너무 많이 공유하면 소비하는 서비스가 내부 표현과 연결되게 됩니다. 이것은 자율성을 감소시켜서 변경 사항이 발생할 때, 소비자와의 추가적인 조정이 필요하게 됩니다.

 

서비스는 API(application programming interface)를 노출하며, 협업 서비스들은 이러한 API를 통해 우리 서비스와 통신합니다. 우리는 또한 어떤 기술이 소비자와 연결되지 않도록 하는데 적합한지에 대해 생각할 필요가 있습니다. 이것은 기술 선택에 제약을 주지 않기 위해서 기술과 무관한 API를 선택하는 것을 의미할 수 있습니다. 이 책에서 좋은, 연결되어 있지 않은 API의 중요성에 대해서 몇 번이나 다시 돌아올 것입니다.

 

디커플링(decoupling)이 없으면-분리되지 않으면, 모든 것이 무너집니다. 황금률 : 다른 것은 변경 없이 서비스 그 자체만을 변경하고 배포할 수 있는가? 대답이 'no'라면 우리가 이 책을 통해서 논의하고자 하는 많은 장점들이 달성하기 어렵게 될 것입니다.

 

디커플링을 잘 하기 위해서는 서비스를 올바르게 모델링하고 API를 올바르게 얻어야 합니다. 그 부분에 대해서 많은 이야기를 할 것입니다.

 

Key Benefits

(주요 이점들)

 

마이크로서비스의 이점은 많고 다양합니다. 이러한 많은 장점들은 분산 시스템의 문에 놓여질 수 있습니다. 그러나 마이크로서비스는 첫째로 분산 시스템과 SOA 개념을 얼마나 멀리 가지고 가는지에 따라 이러한 장점들을 더 많이 달성하는 경향이 있습니다.

 

Technology Heterogeneity

(기술 이질성)

 

여러 개의 협업하는 서비스들로 구성된 시스템에서 각각의 내부에 서로 다른 기술을 사용하기로 결정할 수 있습니다. 이것은 더 표준화되고, 종종 마지막에 최하위의 공통분모가 되도록 하는 널리 적용되도록 만든(one-size-fits-all) 접근방법을 선택하는 것보다 각각의 작업에 적합한 올바른 툴을 정할 수 있게 합니다.

 

시스템의 일부가 성능을 개선할 필요가 있다면, 필요한 성능 수준을 더 잘 달성할 수 있는 다른 기술 스택을 사용하기로 결정할 수 있습니다. 또한 시스템의 다른 부분의 변경에 필요한 데이터를 어떻게 저장할지를 결정할 수 있습니다. 예를 들면, 소셜 네트워크의 경우, 소셜 그래프의 상호 연관성을 높게 반영하기 위해 사용자의 상호작용을 그래프 기반 데이터베이스에 저장할 수 있습니다. 그러나 아마도 사용자가 만든 게시물은 문서 기반 데이터 저장소에 저장할 수 있으므로, 그림 1-1에 보이는 것처럼 이기종 아키텍처가 떠오르게 됩니다.

 

사용자 삽입 이미지

 

마이크로서비스를 통해 기술을 보다 빠르게 받아들일 수 있고, 새로운 발전이 어떻게 우리를 도와주는지를 이해할 수 있습니다. 새로운 기술을 시도하고 채택하는데 있어서 가장 큰 장벽 중 하나는 그와 관련된 위험입니다. 모놀리틱(monolithic) 어플리케이션에서 새로운 프로그래밍 언어, 데이터베이스, 혹은 프레임워크를 시도하고 싶다면, 그 변화는 시스템의 많은 부분에 영향을 미치게 됩니다. 여러 서비스로 이루어진 시스템에서는 새로운 기술을 시도해 볼 수 있는 여러 새로운 장소가 있습니다. 잠재적인 부정적 영향을 제한할 수 있다는 것을 알기 때문에 아마도 가장 위험이 적은 서비스를 선택해서 기술을 사용할 것입니다. 많은 조직에서는 신기술을 보다 빠르게 흡수하여 실제 이점으로 활용할 수 있는 능력을 알고 있습니다.

 

물론, 여러 기술을 채택하는 것은 오버헤드 없이 이루어지지 않습니다. 어떤 조직에서는 언어 선택에 제한을 가하기도 합니다.

 

예를 들어, Netflix Twitter에서는 시스템의 안정성과 성능을 잘 알고 있기 때문에, 대부분 JVM(Java Virtual Machine)을 플랫폼으로 사용합니다.

 

또한, 그들은 대규모 운영을 더 쉽게 하는 JVM을 위한 라이브러리와 도구들을 개발하여 사용하고 있습니다. 그러나 Java 기반이 아닌 서비스나 클라이언트는 더 어려워집니다. Twitter Netflix 모두 모든 작업에 하나의 기술 스택만을 사용하는 것은 아닙니다.

 

다른 기술을 혼합하는 것에 대해 고려하는 또 다른 대위법은 크기입니다. 실제로 2주 안에 마이크로서비스를 다시 작성할 수 있다면, 새로운 기술의 채택에 대한 위험을 완화할 수 있을 것입니다.

 

이 책에서 볼 수 있듯이, 마이크로서비스에 관련된 많은 것들처럼 올바른 균형을 찾는 것이 전부입니다. Chapter 2에서 진화적인 아키텍처에 초첨을 맞춘 기술을 어떻게 선택하는지를 논의하고, 통합(integration)을 다루는 Chapter 4에서 서비스가 어떻게 과도한 커플링(coupling) 없이 서로 독립적으로 기술을 진화시킬 수 있는지를 배우게 될 것입니다.

 

Resilience

(회복력? 복원력?)

 

탄력(resilience) 공학의 핵심 개념은 칸막이(bulkhead)입니다. 시스템의 한 구성 요소가 실패했을 경우, 그 장애가 종속되어 있지 않으면 그 문제를 격리할 수 있습니다. 그리고 시스템의 나머지는 계속 동작할 수 있습니다. 서비스의 경계는 명확한 칸막이가 됩니다. 모놀리틱(monolithic) 서비스에서는 서비스가 실패하면 모든 동작이 멈춥니다. 모놀리틱 시스템에서는 장애 가능성을 줄이기 위해 여러 시스템에서 실행할 수 있습니다. 그러나 마이크로서비스에서는 서비스의 전체 장애를 처리하고, 기능성을 적절히 떨어뜨리는 시스템을 구축할 수 있습니다.

 

그러나 조심해야할 필요가 있습니다. 마이크로서비스가 이러한 향상된 복원력을 적절하게 채택할 수 있도록 하기 위해서는 분산 시스템에서 다루어야 하는 새로운 장애 요인에 대해 이해할 필요가 있습니다. 머신처럼 네트워크에서 실패할 수 있습니다. 이것을 어떻게 다루는지를 알아야 합니다. 그리고 그 장애가 소프트웨어의 최종 사용자에게 어떤 영향을 주는지도 알아야 합니다.

 

Chapter 11에서 복원력을 더 잘 다루고, 실패 모드를 처리하는 방법에 대해서 이야기할 것입니다.

 

Scaling

(확장)

 

대규모의 모놀리틱(monolithic) 서비스에서 우리는 모든 것을 함께 확장해야 합니다.

시스템 전체 중 하나의 작은 부분은 성능에 제약이 있지만, 그러한 동작이 하나의 거대한 모놀리틱 어플리케이션에 고정되어 있다면 모든 것을 하나의 조각으로 확장하도록 처리해야 합니다. 더 작은 서비스들은 확장이 필요한 서비스만 확장할 수 있기 때문에, 그림 1-2처럼 더 작고 덜 강력한 하드웨어에서 시스템의 다른 부분들을 실행하도록 할 수 있습니다.

 

사용자 삽입 이미지

 

온라인 패션 소매업체인 Glit은 이러한 정확한 이유로 마이크로서비스를 채택했습니다. 2007년에 모놀리틱 Rails 어플리케이션으로 시작해서, 2009년에 Glit의 시스템은 부하에 대처할 수 없었습니다. 시스템의 핵심 부분을 분리함으로써 Glit은 트래픽 급증을 더 잘 처리할 수 있었고, 오늘날 450개가 넘는 마이크로서비스가 있습니다. 각각의 서비스는 여러 개의 분리된 머신에서 실행되고 있습니다.

 

아마존 웹 서비스(Amazon Web Services)에서 제공하는 것과 같은 주문형(on-demand) 프로비저닝 시스템을 채택할 때, 필요한 부분에 대한 요구에 대해 확장을 적용할 수 있습니다. 이를 통해 비용을 보다 효과적으로 제어할 수 있습니다. 하지만 종종 아키텍처적인 접근 방법이 항상 즉각적인 비용 절감과 밀접한 연관이 있는 것은 아닙니다.

 

Ease of Deployment

(쉬운 배포)

 

한 줄을 백만 라인의 모놀리틱 어플리케이션으로 변경하는 것은 변경 사항을 릴리즈(release)하기 위해서 전체 어플리케이션을 배포해야 합니다. 그것은 커다란 영향을 미치는, 고위험의 배포일 수 있습니다. 실제로, 큰 영향을 미치고 고 위험을 가지는 배포는 이해할 수 없는 공포로 인해 드물게 발생합니다. 불행하게도, 이것은 우리의 변경 사항들이 우리의 새로운 버전의 어플리케이션이 다수의 변경 사항을 가진 제품화가 될 때까지 릴리즈 사이에 쌓이면서 점점 커지는 것을 의미합니다. 릴리즈 사이에 델타(변경사항)가 더 클수록 무엇인가가 잘못된 위험이 더 높아집니다!

 

마이크로서비스에서는 단일 서비스를 변경할 수 있습니다. 그리고 나머지 시스템에 독립적으로 배포할 수 있습니다. 이를 통해 코드를 더 빠르게 배포할 수 있습니다. 만약 문제가 발생하면, 개별 서비스로 신속하게 격리될 수 있고, 빠른 롤백을 쉽게 달성할 수 있습니다. 그것은 고객에게 더 빠르게 새로운 기능을 제공할 수 있음을 의미합니다. Amazon Netflix같은 조직들이 왜 이러한 아키텍처를 사용하는지의 주된 이유 중 하나입니다. 마이크로서비스는 가능한 많은 방해물을 제거하여 소프트웨어가 밖으로 나갈 수 있게 합니다. 이 공간에서의 기술은 지난 2년 동안 크게 변화했습니다. 그리고 Chapter 6에서 마이크로서비스 세계에서 배포에 관한 주제를 더 깊게 살펴볼 것입니다.

 

Organizational Alignment

(조직적 조정)

 

우리중 많은 사람들이 대규모 팀과 코드베이스와 관련된 문제들을 경험했습니다. 이 문제는 팀이 분산될 때 더 심해질 수 있습니다. 우리는 또한 더 작은 코드베이스에서 작업하는 더 작은 팀이 더 생산성이 높은 경향이 있다는 것을 알고 있습니다.

 

마이크로서비스는 아키텍처를 조직에 더 잘 연계할 수 있게 합니다. 그리고, 하나의 코드베이스에서 작업하는 사람의 수를 최소화하여 팀의 크기와 생산성 측면에서 최고의 결과를 얻을 수 있게 합니다. 우리는 팀 간의 서비스 소유권을 옮겨서 하나의 서비스에 대해 일하는 사람들을 같은 곳에 있도록 할 수 있습니다. Chapter 10에서 Conway의 법칙을 논의할 때 이 주제에 대해서 훨씬 더 자세히 설명할 것입니다.

 

Composability

(결합성)

 

분산 시스템과 SOA에서의 주요 약속 중 하나는 기능을 재사용하는 기회를 열어놓는 것입니다. 마이크로서비스에서는 기능을 다른 목적에 대해서 다양한 방법으로 사용하게 합니다. 소비자가 우리 소프트웨어를 어떻게 사용하는지에 대해 생각할 때 특히 중요할 수 있습니다. 데스크톱 웹 사이트나 모바일 어플리케이션에 대해서 좁혀서 생각할 때, 시간은 흘러갑니다. 이제 우리는 웹, 네이티브 어플리케이션(스마트폰 등에 직접 설치해야 하는 어플리케이션), 모바일 웹, 티블릿 앱, 혹은 웨어러블 디바이스에 대해 서로 결합을 짜내기 위한 무수한 방법을 생각할 필요가 있습니다.

 

조직이 좁은 채널 측면에서 생각이 고객 참여의 전체론적인 개념으로 옮겨감에 따라 계속되게 할 수 있는 아키텍처가 필요합니다.

마이크로서비스로 외부 당사자가 처리할 수 있도록 우리 시스템의 경계선들을 오픈하는 것에 대해 생각해 보십시오. 상황이 바뀜에 따라 우리는 다른 방식으로 물건들을 만들 수 있습니다. 모놀리틱 어플리케이션에서는 밖에서 사용할 수 있는 하나의 거칠게 나누어진 경계가 있는 경우가 많습니다. 더 유용한 것을 얻기 위해 그것을 깨고 싶다면, 해머가 필요할 것입니다! Chapter 5에서 기존의 모놀리틱 시스템을 분해하고, 재사용 가능하게 바꾸고, 마이크로서비스로 재구성할 수 있는 방법에 대해서 논의할 것입니다.

 

Optimizing for Replaceability

(대체 가능성의 최적화)

 

만약 여러분이 중간 규모 이상의 조직에서 일하고 있다면, 구석에 있는 크고 끔직한 레거시 시스템에 대해서 알고 있을 가능성이 있습니다. 누구도 만지고 싶지 않은 것. 여러분의 회시가 어떻게 운영되는지에 대해서 필수적인 어떤 것이지만, 이상한Fortran(포트란) 변수로 작성되어 있고, 25년전에 끝난 하드웨어에서만 실행됩니다. 왜 대체되지 않았을까요? 당신은 이유를 알고 있습니다. : 너무 크고 위험한 일이기 때문입니다.

개별 서비스가 작으면, 다 나은 구현으로 대체하거나 심지어 전부 지우는데 들어가는 비용을 관리하는 것이 훨씬 더 쉽습니다. 하루에 얼마나 자주 너무 걱정하지 않고 100줄 이상의 코드를 지우고 있습니까? 크기가 유사한 마이크로서비스가 종종 있기 때문에, 서비스를 완전히 재작성하거나 삭제하기 위한 장벽은 매우 낮습니다.

마이크로서비스 접근 방법을 사용하는 팀들은 필요할 때 서비스를 완전히 다시 작성하고, 더 이상 필요 없을 때 서비스를 죽이는데 익숙합니다 코드베이스가 수 백줄에 불과하면, 사람들이 감정적으로 애착을 갖기 어렵습니다. 그리고 대체하는 비용이 매우 적습니다.

 

What About Service-Oriented Architecture?

 

SOA(Service-Oriented Architecture)는 여러 서비스가 일부 기능 집합을 제공하기 위해 협력하는 설계 접근 방법입니다. 여기서 서비스는 일반적으로 완전히 분리된 운영 체제 프로세스를 의미합니다. 이러한 서비스들 사이의 통신은 프로세스 경계 내에서의 메소드 호출보다는 네트워크 호출을 통해 이루어집니다. SOA는 대규모의 모닐리틱 어플리케이션의 문제점을 해결하기 위한 접근 방법으로 등장했습니다.

SOA는 소프트웨어의 재사용성을 촉진하기 위한 목적으로 하는 접근 방식입니다. 예를 들면, 두개 이상의 최종 사용자 어플리케이션은 모두 동일한 서비스를 사용할 수 있습니다. 서비스의 의미가 너무 많이 변하지 않는 한, 이론적으로 아무도 모르게 하나의 서비스를 다른 서비스로 대체하는 것이 가능하기 때문에 소프트웨어를 유지하거나 재작성하는 것이 더 쉽습니다.

SOA는 매우 현명한 아이디어입니다. 그러나, 많은 노력에도 불구하고, SOA를 잘 수행하는 방법에 대한 좋은 합의가 부족합니다. 개인적인 견해로는 산업계의 상당수는 문제에 대해 충분히 전체적인 관점에서 들여다보지 못했고, 이 영역에서 다양한 벤더들이 내놓은 이야기들에 대한 강력한 대안을 정하지 못했습니다.

SOA의 문앞에 놓인 많은 문제들은 통신 프로토콜(예를 들면, SOAP), 벤더들의 미들웨어, 서비스 세분화에 대한 가이드 부족, 혹은 시스템을 분할하는 장소 선택에 대한 잘못된 가이드와 같은 실제적인 문제들이었습니다. 우리는 책의 나머지 부분에서 각각에 대해서 다룰 것입니다. 냉소적인 사람은 벤더들이 SOA 운동을 더 많은 제품들을 팔기 위한 방법으로 선임(어떤 경우에는 주도)했음을 암시할지도 모릅니다. 그리고 그러한 똑같은 제품들은 종국에 SOA의 목표를 훼손시켰습니다.

 

SOA에 대한 기존 지혜의 대부분은 큰 어떤 것을 작게 나누는 방법을 이해하는데 도움이 되지 않습니다. SOA는 얼마나 큰 것이 너무 큰 것인가를 이야기하는 것이 아닙니다. SOA는 실제 세상에서, 서비스가 과도하게 결합되지 않도록 하는 실질적인 방법에 대해서 충분히 이야기하지 않습니다. 언급되지 않은 것들의 수는 대부분 SOA와 연관된 위험이 발생한 곳입니다.

 

마이크로서비스 접근 방법은 SOA를 더 잘 수행할 수 있는 시스템과 아키텍처에 대한 더 나은 이해를 바탕으로 실제 세상에서 사용함으로 드러났습니다. 따라서 XP Scrum Agile 소프트웨어 개발에 대한 특정 접근법인 것과 같은 방식으로 마이크로서비스가 SOA에 대한 특정한 접근방법으로 생각해야 합니다.

 

Other Decomposition Techniques

(기타 분해 기법)

 

여러분이 그것에 관심을 기울이기 시작할 때, 마이크로서비스 기반 아키텍처의 많은 유익한 점들은 어떻게 문제를 해결하는지 더 많은 선택의 경우를 준다는 granular nature(낱개 특성)과 사실로부터 나옵니다. 하지만, 유사한 분해 기법으로 동일한 유익을 얻을 수 있을까요?

 

Shared Libraries

(공유 라이브러리)

 

사실상 모든 언어에 내장된 매우 표준적인 분해 기법은 여러 라이브러리로 코드베이스를 분해하는 것입니다. 이러한 라이브러리들은 3rd party가 제공하거나 조직 내에서 만들 수 있습니다. 라이브러리들은 팀과 서비스들 간에 기능을 공유할 수 있는 방법을 제공합니다. 예를 들어, 제가 유용한 콜렉션 유틸리티 집합을 만들거나 재사용할 수 있는 통계 라이브러리를 만들 수 있습니다.

 

팀은 이러한 라이브러리들을 기준으로 조직할 수 있고, 라이브러리들은 재사용 할 수 있습니다. 하지만, 몇 가지 단점이 있습니다.

 

첫번째로 진정한 기술 이질성을 잃어버립니다. 라이브러리는 전형적으로 동일한 언어로 되어 있어야 하거나, 최소한 동일한 플랫폼에서 실행되어야 합니다. 두번째, 시스템의 일부를 서로 독립적으로 확장하는 용이성이 감소합니다. 다음으로는 동적으로 링크된 라이브러리를 사용하지 않으면, 전체 프로세스를 재배포하지 않고서 새로운 라이브러리를 배포할 수 없으므로, 변경 사항을 독립적으로 배포할 수 있는 능력이 줄어듭니다. 그리고 아마도 시스템의 탄력성을 보장하기 위해 구조적인 안전 조치들을 세우기 위한 분명한 솔기가 부족할 수도 있습니다.

 

공유 라이브러리들은 그들만의 장소를 가지고 있습니다. 조직 전체에서 재사용하고 싶어서 비즈니스 도메인에 특정되지 않는 일반적인 작업에 대한 코드를 스스로 만든다면, 재사용 가능한 라이브러리에 대한 분명한 후보자가 될 수 있습니다. 비록 그렇다고 할지라도, 여러분은 충분히 주의해야 합니다. 서비스간 통신에 사용되는 공유 코드는 Chapter 4에서 논의할 예정인, 연결되는 지점(point of coupling)이 될 수 있습니다.

 

서비스들은 공통 코드를 재사용하기 위해 3rd party의 라이브러리들을 매우 많이 사용할 수 있고, 그렇게 해야만 할 것입니다. 하지만, 그것들은 우리를 거기에 데려다 주지 않습니다.

 

Modules

(모듈)

 

어떤 언어들은 간단한 라이브러리들을 넘어서는 자체의 모듈식 분해 기법을 제공합니다. 실행 프로세스에 모듈을 배포할 수 있도록 모듈의 라이프사이클 관리를 허용하기 때문에 전체 프로세스를 다운시키지 않고 변경 작업을 수행할 수 있습니다. OSGI(Open Source Gateway Initiative)는 하나의 기술 특화된 모듈식 분해 접근 방식을 요구합니다.

Java 자체는 모듈에 대한 진정한 개념을 가지고 있지 않습니다. 따라서 Java 9가 언어에 추가된 것을 보여줄 때까지 적어도 기다려야만 합니다.

OSGI Eclipse Java IDE에 플러그인을 설치하기 위한 프레임워크로 나타났습니다. 지금은 라이브러리를 통해 자바에 모듈 개념을 새로 장착하는 방법으로 사용되고 있습니다. OSGI의 문제는 언어 자체에서 충분한 지원 없이는 모듈 라이프사이클 관리와 같은 것을 억지로 실행하려고 하는 것입니다. 이러한 결과로 적절한 모듈 분리를 제공하기 위해서 모듈 작성자가 더 많은 일을 해야 합니다. 프로세스 경계 내에서 모듈이 서로 지나치게 결합하는 것은 모든 종류의 문제를 야기하는 함정에 훨씬 더 쉽게 빠집니다. OSGI에 대한 경험에서 산업계 내 동료들과 어울릴 때, 아무리 좋은 팀이라도 OSGI가 보장하는 이익보다 훨씬 더 큰 복잡성의 원인이 되기 쉽다는 것입니다.

 

Erlang은 모듈이 언어 런타임 내에 구워지는 다른 접근 방법을 따릅니다. 이처럼 Erlang은 모듈식 분해에 대해 매우 성숙한 접근 법입니다. Erlang 모듈은 문제없이 중단, 재시작, 업그레이드 될 수 있습니다. Erlang은 주어진 시간 대에 두개 이상의 모듈 버전이 실행되는 것을 지원합니다. 따라서 더 우아한 모듈 업그레이드가 가능합니다.

Erlang 모듈의 능력은 실제로 인상적이지만, 이러한 기능을 갖춘 플랫폼을 사용할 만큼 충분히 운이 좋을지라도, 일반적인 공유 라이브러리와 마찬가지로 동일한 단점이 있습니다.

우리는 새로운 기술들을 사용하는 능력이 엄격히 제안되어 있으며, 독립적으로 확장할 수 있는 방법에 대해서도 제한적이고, 지나치게 커플된(coupled) 통합 기술 (integration techniques) 쪽으로 표류할 수 있고, 구조적인 안전 조치를 위한 이음새가 부족합니다.

 

공유할 만한 가치가 있는 마지막 관찰이 하나 있습니다. 단일 모놀리틱 프로세스 내에 기술적으로, 잘 정리된, 독립적인 모듈을 만드는 것이 가능해야 합니다. 하지만, 거의 이러한 일은 일어나지 않습니다. 모듈은 그 자체로 나머지 코드들과 밀접하게 결합하여 주요 장점 중 하나를 버립니다. 프로세스 경계를 분리하는 것은 이 점에 있어서 청결한 위생을 실행합니다. (혹은 최소한 잘못된 것을 더 하기 어렵게 합니다!)

 

물론, 이것이 프로세스 분리의 주요 요인이라고 제안하지는 않겠지만, 프로세스 경계 내에서 모듈 분리의 약속이 현실 세계에서는 거의 제공되지 않는 다는 점이 흥미롭습니다.

 

따라서, 프로세스 경계 내에서 모듈식 분리는 시스템을 서비스로 분해하는 것 뿐만 아니라 행하고자 하는 어떤 것일 수도 있지만, 그 자체로 모든 것을 해결하는데 도움이 되는 것은 아닙니다. 만약 순수한 Erlang Shop이라면 Erlang의 모듈 구현 품질은 당신에게 매우 먼 길을 가져다 줄 수 있습니다. 하지만, 여러분 중의 많은 사람들이 그 상황에 있지는 않을 거라고 생각합니다. 우리에게 남은 것은, 모듈이 공유 라이브러리와 동이한 유익을 가져다 주는 것으로 보아야 한다는 것입니다.

 

No Silver Bullet

(은 총알은 없다)

 

끝내기 전에, 마이크로서비스는 무료 점심이나 은 총알이 아니고, 황금 망치처럼 나쁜 선택을 해야 한다는 것을 말하고 싶습니다. 마이크로서비스는 분산 시스템과 관련된 모든 복잡성을 가지고 있습니다. 그리고 비록 우리가 분산 시스템을 어떻게 잘 관리하는지에 대해 많이 배운다고 할지라도 (이 책에서 다룰 것입니다.) 여전히 어렵습니다. 만약 여러분이 모놀리틱 시스템 관점에서 출발한다면, 배포, 테스트, 모니터링을 훨씬 더 잘 처리하여 지금까지 우리가 살펴본 장점들을 풀어서 활용해야 합니다. 또한,시스템을 어떻게 확장하는지, 복원력이 있는지 어떻게 확인하는지에 대해 다르게 생각할 필요가 있습니다. 분산 트랜잭션이나 CAP 이론이 두통을 선사해도 놀라지 마십시오.

 

모든 회사, 조직, 시스템은 다릅니다. 마이크로서비스가 여러분에게 적합한지 아닌지, 마이크로서비스를 얼마나 적극적으로 채택할 수 있는지에 여러 가지 요소들이 작용할 것입니다. 이 책의 각 장들을 통해서 꾸준한 경로를 계획하는데 도움이 되는 잠재적 함정을 강조하는 가이드를 제공하려고 노력할 것입니다.

 

Summary

 

바라건데, 이제부터 여러분은 마이크로서비스가 무엇인지, 다른 구성 기술들과 다른 점이 무엇인지, 주요 장점 중 일부가 무엇인지 알고 있습니다. 다음 각 장에서는 어떻게 이러한 장점들을 달성하는지, 일반적인 함정을 어떻게 피하는지에 대해서 더 자세히 다룰 것입니다.

 

다루어야 할 많은 주제들이 있지만, 어딘가에서부터 시작해야 합니다. 마이크로서비스가 소개하는 주요 과제 중 하나는 우리 시스템의 진화를 가이드하는 사람들 : 아키텍트들의 역할에 변화가 있다는 것입니다. 다음에 우리는 이 새로운 아키텍처를 최대한 활용할 수 있도록 이 역할에 대한 몇 가지 다른 접근 방법을 살펴볼 것입니다.

 


2018/12/11 10:09 2018/12/11 10:09
Trackback Address :: http://www.yongbi.net/trackback/812
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Name
Password
Homepage

Secret

7. Refactoring a Monolith into Microservices - 04 Summary :: 2017/04/25 22:06


Summary
(요약)

기존 어플리케이션을 마이크로서비스로 마이그레이션하는 과정은 어플리케이션 현대화의 한 형태이다. 어플리케이션을 처음부터 다시 작성하여 마이크로서비스로 옮기면 안 된다. 대신에, 어플리케이션을 일련의 마이크로서비스로 점차적으로 리팩토링해야 한다. 여기에 사용할 수 있는 3가지 전략이 있다. 새로운 기능을 마이크로서비스로 구현한다. 비즈니스 컴포넌트와 데이터 액세스 컴포넌트에서 프리젠테이션 컴포넌트를 분리한다. 기존의 모듈을 monolith에서 마이크로서비스로 변환한다. 시간이 지날수록 마이크로서비스의 수는 증가하고, 개발팀의 민첩함과 속도는 증가할 것이다.

more..


2017/04/25 22:06 2017/04/25 22:06
Trackback Address :: http://www.yongbi.net/trackback/785
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Name
Password
Homepage

Secret

7. Refactoring a Monolith into Microservices - 03 Overview : Extract Services :: 2017/04/25 21:59


Strategy 3 – Extract Services
(세번째 전략 : 서비스 추출)

세번째 리팩토링 전략은 monolith 내 기존 모듈들을 독립형 마이크로서비스로 변환하는 것이다. 모듈을 추출하여 서비스로 변환할 때마다, monolith는 작아진다. 일단 충분히 모듈로 변환하고 나면, monolith는 문제가 되지 않을 것이다. Monolith는 완전히 사라지거나 또다른 서비스가 될 만큼 충분히 작아지게 된다.

Prioritizing Which Modules to Convert into Services
(서비스 변환 대상 모듈 우선 순위화)

크고 복잡한 monolithic 어플리케이션은 수십, 수백개의 모듈들로 이루어져 있다. 그리고 그 모듈들은 모두 추출 대상이다. 우선 변환할 모듈을 알아내는 것은 도전적인 일이다. 좋은 접근 방법은 쉽게 추출할 수 있는 몇 가지 모듈로 시작하는 것이다. 이것은 일반적으로 마이크로서비스와 특히 추출 프로세스에 대한 경험을 제공해 준다. 그 이후에, 가장 큰 이익을 주는 모듈들을 추출해야 한다.

모듈을 서비스로 변환하는 것은 일반적으로 시간이 많이 걸린다. 여러분은 얻을 수 있는 이익을 기반으로 모듈에 대한 순위를 매기기를 원한다. 일반적으로는 자주 변경되는 모듈을 추출하는 것이 유익하다. 한번 모듈을 서비스로 변환하고 나면, monolith와는 독립적으로 개발하고 배포할 수 있기 때문에 개발을 가속화하게 될 것이다.

Monolith의 나머지와 크게 다른 리소스 요구사항을 가지는 모듈을 추출하는 것도 유익하다. 예를 들면, 인메모리 데이터베이스를 가진 모듈을 서비스로 변환하고, 대용량 메모리를 가진 호스트에 배포할 수 있다. 이와 유사하게, 계산하기에는 비싼 알고리즘을 구현하는 모듈을 추출하는 것은 많은 CPU를 가진 호스트에 배포할 수 있기 때문에 가치가 있다. 특정 리소스 요구사항을 가진 모듈을 서비스로 변환함으로써, 어플리케이션을 훨씬 쉽게 확장할 수 있다.

어느 모듈을 추출할지를 알고 나면, 이미 존재하는 대략적인 경계(이음새로 알려진)를 찾는 것이 유용하다. 모듈을 서비스로 더 쉽고 값싸게 한다. 그러한 경계의 한 예로는 비동기 메시지를 통해 나머지 어플리케이션과 커뮤니케이션하는 모듈을 들 수 있다. 상대적으로 싸고 쉽게 모듈을 마이크로서비스로 변환할 수 있다.

How to Extract a Module
(어떻게 모듈을 추출하는가)

모듈을 추출하는 첫번째 단계는 모듈과 monolith 사이에 대략적인 인터페이스를 정의하는 것이다. Monolith는 서비스가 소유한 데이터를 필요로 하고, 그 반대의 경우도 마찬가지이기 때문에 대부분 양방향 API일 것이다. 모듈과 나머지 어플리케이션들 사이의 얽혀 있는 의존성과 잘 정리되어 있는 상호작용 패턴 때문에 양방향 API를 구현하는 것은 종종 어려운 일이다. Domain Model 패턴을 사용하여 구현된 비즈니스 로직은 도메인 모델 클래스 간의 수많은 연관성 때문에 리팩토링하기에 특히 어렵다. 이러한 의존성을 깨기 위하여 종종 중요한 코드를 변경해야만 할 필요가 있다. 다음 다이어그램은 리팩토링에 대해서 보여준다.

대략적인 인터페이스를 일단 구현하고 나면, 모듈을 독립적인 서비스로 변환할 수 있다. 이렇게 하기 위해서, monolith와 서비스가 Inter-Process Communication(IPC : 프로세스간 통신) 메커니즘을 사용하는 API를 통해 서로 통신할 수 있는 코드를 작성해야만 한다. 다음 다이어그램은 리팩토링 전, 도중, 후의 아키텍처를 보여준다.


사용자 삽입 이미지



이 예제에서, 모듈 Z는 추출할 후보 모듈이다. 그 구성요소들은 모듈 X에서 사용되고, 모듈 Y를 사용한다. (즉, X 모듈에서는 Z 모듈의 구성요소를 사용하고, Z 모듈의 구성요소들은 Y 모듈을 사용한다.) 첫번째 리팩토링 단계는 대략적인 API 쌍을 정의하는 것이다. 첫번째 인터페이스는 모듈 Z를 호출하기 위해서 모듈 X에서 사용하는 인바운드 인터페이스이다. 두번째는 모듈 Y를 호출하기 위해 모듈 Z에서 사용하는 아웃바운드 인터페이스이다. (인바운드 : 모듈 Z의 입장에서 요청이 들어오는 방향, 아웃바운드 : 모듈 Z의 입장에서 요청이 나가는 방향)

리팩토링의 두번째 단계는 모듈을 독립적인 서비스로 변환하는 것이다. 인바운드, 아웃바운드 인터페이스는 IPC 메커니즘을 사용하는 코드로 구현된다. 서비스 검색과 같은 Cross-Cutting Concern(AOP에서 여러 비즈니스 로직에 공통으로 필요하여 별도 모듈로 쉽게 분리할 수 없는 요구사항. 예:보안, 로깅, 트랜잭션, 등)을 다루는 Microservice Chassis framework와 모듈 Z를 결합하여 서비스를 빌드할 필요가 있다.

일단 모듈을 추출하고 나면, monolith와 다른 서비스들과는 별도로 개발, 배포, 확장하 ㄹ수 있는 또다른 서비스를 가지게 된다. 서비스를 처음부터 재작성하게 될 수도 있다. 이 경우에는, 서비스와 monolith를 통합하는 API 코드가 2개의 도메인 모델 사이를 변환하는 Anti-Corruption Layer(반부패 계층)이 된다. 서비스를 추출하는 경우마다 마이크로서비스의 방향으로 또 한 걸음 나아가는 것이다. 시간이 지날수록 monolith는 작아지고, 마이크로서비스는 늘어날 것이다.

2017/04/25 21:59 2017/04/25 21:59
Trackback Address :: http://www.yongbi.net/trackback/784
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Name
Password
Homepage

Secret

7. Refactoring a Monolith into Microservices - 02 Overview : Split Frontend and Backend :: 2017/04/23 21:47


Strategy 2 – Split Frontend and Backend
(두번째 전략 - Frontend와 Backend의 분리)

Monilithic Application을 축소시키는 전략은 비즈니스 로직과 데이터 액세스 레이어에서 프리젠테이션 레이어를 분리하는 것이다.

일반적으로 엔터프라이즈 어플리케이션은 최소한 3가지 다른 유형의 컴포넌트들로 이루어져 있다.

프리젠테이션 레이어 - HTTP 요청을 처리하고, (REST) API나 HTML 기반 Web UI를 구현하는 구성 요소. 정교한 사용자 인터페이스를 가지고 있는 어플리케이션에서 프리젠테이션 계층은 종종 상당한 코드로 구성되어 있다.
비즈니스 레이어 - 어플리케이션의 핵심 영역이며, 비즈니스 규칙을 구현하는 구성 요소.
데이터 액세스 레이어 - 데이터베이스나 메시지 브로커와 같은 인프라 구성 요소들에 액세스하는 구성 요소

일반적으로 프리젠테이션 로직 영역과 비즈니스, 데이터 액세스 로직 사이는 분명하게 분리되어 있다. 비즈니스 계층은 비즈니스 로직 컴포넌트들을 캡슐화하는 하나 이상의 facade(진입점 역할을 하는 인터페이스)로 이루어진 대단위 API를 가지고 있다. 이 API는 monolith를 2개의 더 작은 어플리케이션으로 나눌 수 있는 자연적인 솔기이다. 한 개의 어플리케이션은 프리젠테이션 레이어를 가지고 있다. 다른 어플리케이션은 비즈니스와 데이터 액세스 로직이 포함되어 있다. 이렇게 분리한 후, 프리젠테이션 로직 어플리케이션은 비즈니스 로직 어플리케이션을 원격으로 호출하게 된다. 다음 다이어그램은 리팩토링 전후의 아키텍처를 보여주고 있다.

사용자 삽입 이미지



이 방법으로 monolith를 분할하는 것은 2가지 주요 장점이 있다. 서로간에 독립적으로 2개의 어플리케이션을 개발, 배포, 확장할 수 있다. 특히, 프리젠테이션 레이어 개발자는 사용자 인터페이스를 빠르게 반복하여 개발할 수 있다. 그리고 예를 들면, 쉽게 A|B 테스트를 수행할 수 있다. 이 접근방법의 또다른 장점은 개발한 마이크로서비스에서 호출할 수 있는 원격 API를 제공한다는 것이다.

그러나, 이 전략은 단지 부분적인 해결책일 뿐이다. 한 두개의 관리할 수 없는 monolith 어플리케이션에 대한 해결책일 공산이 크다. 나머지 monolith를 제거하기 위해서는 3번째 전략을 사용하는 것이 필요하다.

2017/04/23 21:47 2017/04/23 21:47
Trackback Address :: http://www.yongbi.net/trackback/783
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Name
Password
Homepage

Secret

7. Refactoring a Monolith into Microservices - 01 Overview : Stop Digging :: 2017/04/18 11:43


이번 기사는 Microservice로 Application을 작성하는데 있어서 7번째이자, 마지막 글이다. 첫번째 글에서는 Microservice Architecture 패턴에 대해서 소개하고, Microservice를 사용하는 장단점에 대해서 논의했다. 다음 글에서는 API Gateway 사용, Inter-process communication, 서비스 검색, Event-Driven 데이터 관리, Microservice 배포 등의 다양한 측면에 대해서 논의했다. 이번 글에서는 monolithic application을 microservice로 마이그레이션(전환)하는 전략에 대해서 살펴 보려고 한다.

이 시리즈 기사들을 통해서 microservice architecture와 장단점, 언제 사용하는지에 대해 이해할 수 있도록 돕고자 한다. Microservice Architecture가 여러분의 조직에 적합할 수도 있다.

그러나, 크고 복잡한 monolithic application을 작성하는 정말 좋은 기회가 있다. Application 개발과 배포에 대한 일상적인 경험은 느리고 고통스럽다. Microservice는 머나먼 너바나(열반, 해탈)처럼 보인다. 다행스럽게도 Monolithic Hell에서 벗어나는데 사용할 수 있는 전략이 있다. 이 기사에서는, Monolithic Application을 Microservice로 점진적으로 리팩토링하는 방법에 대해서 설명할 것이다.

Overview of Refactoring to Microservices
(Microservice로 리팩토링하기 개요)

Monolithic Application을 Microservice로 변환하는 과정은 Application 현대화의 한 형태이다. 개발자들이 수십년동안 해왔던 일이기도 하다. 결과적으로, Application이 Microservice로 리팩토링할 때, 재사용할 수 있는 몇 가지 아이디어들이 있다.

사용하지 않는 전략 중 한가지는 "Big Bang" 재개발이다. Big Bang은 아무런 사전 준비 없이 새로운 Microservice 기반 Application을 개발하는데 모든 역량을 집중해야 한다. 호소력 있는 것처럼 들리지만, 극도로 위험하고 실패로 끝나기 쉽다. Martin Fowler가 리포트에서 말하는 것처럼, "Big Bang 재개발을 보장하는 유일한 방법은 Big Bang 뿐이다."

Big Bang 재개발 대신에, Monolithic Application을 점진적으로 리팩토링해야 한다. 점차적으로 Microservice를 구성하는 신규 Application을 개발하여 monolithic application과 함께 실행한다. 시간이 지나면, monolithic application으로 구현된 기능의 양은 완전히 사라지거나 또다른 microservice가 될 때까지 줄어든다. 이 전략은 고속도로에서 시속 70마일로 운전하는 도중에 자동차 정비하는 것과 유사한 도전이지만, Big Bang 재개발보다 훨씬 덜 위험하다.

Martin Fowler는 이러한 Application 현대화 전략을 Strangler Application(교착 상태 응용 프로그램)이라고 한다. 그 이름은 열대 우림에서 발견되는 strangler vine (a.k.a strangler fig - 알려진 것처럼, 다른 나무에 기생하여 그 나무를 감고 올라가 말려 죽이는 나무의 한 종류. 직역하면, 교살 포도 나무)에서 비롯되었다. 가끔은 나무가 죽어서 포도 나무 모양을 남긴다. Application 현대화도 같은 패턴을 따른다. Legacy Application 주위에  Microservice로 구성된 새로운 Application을 구축하고, 결국 Legacy Application은 사라질 것이다.

사용자 삽입 이미지


이제, 다른 전략을 살펴보자.

Strategy 1 – Stop Digging
(첫번째 전략 - 채굴 금지)

홀의 법칙(Law of Hole)은 구멍에 있을 때마다 채굴하는 것을 멈춰야 한다는 것을 알려주고 있다. 이것은 monolithic application을 관리할 수 없을 때, 따라야할 훌륭한 조언이다. 다른 말로 하면, monolithic application을 더 크게 만드는 것을 멈춰야만 한다. 이것은 신규 기능을 구현할 때, monolithic에 코드를 추가하지 않아야 한다는 것을 의미한다. 대신에 이 전략의 커다란 아이디어는 독립형 microservice에 새로운 코드를 넣는 것이다. 다음 다이어그램은 이러한 접근법을 적용한 시스템 아키텍처를 보여준다.

사용자 삽입 이미지


새로운 서비스와 legacy monolith 뿐만 아니라, 2가지 구성 요소들이 있다. 첫번째는 HTTP 요청을 처리하는 Request Router이다. 앞서 기사에서 설명한 API Gateway와 유사하다. Router는 새로운 기능에 대한 요청을 새로운 서비스로 보낸다. Legacy 요청은 monolith로 전송한다.

다른 구성 요소는 Glue Code이다. "Glue Code"는 Monolith에 통합되어 있다. 서비스는 격리되어 있지 않고, 종종 Monolith에서 보유하고 있는 데이터에 접근해야 한다. Monolith나 서비스 혹은 양쪽 모두에 있는 "Glue Code"가 데이터 통합을 담당한다. 서비스는 Monolith에 있는 데이터를 읽거나 쓰는데 Glue Code를 사용한다.

서비스가 monolith 데이터에 접근하는데 3가지 전략이 있다.

1. Monolith에서 제공하는 원격 API 호출
2. Monolith의 데이터베이스에 직접 접근
3. Monolith의 데이터베이스와 동기화된 자체 복사본 데이터 유지

Glue Code는 때때로 Anti-corruption Layer(반부패 계층)로 불리기도 한다. 왜냐하면 본래의 도메인 모델을 가진 서비스가 Legacy Monolith 도메인 모델이 갖는 개념에 의해 오염되는 것을 Glue Code가 방지하기 때문이다. Glue Code는 2가지 다른 모델들 사이에 변환된다. Anti-corruption Layer라는 용어는 읽어야만 하는 책, 이후 백서로 개량된 Eric Evans의 Domain Driven Design에서 처음 나타났다. Anti-corruption Layer를 개발하는 것은 사소한 일이 될 수도 있다. 그러나, monolithic hell에서 벗어나기 원한다면, 하나를 창조하는 것이 필수적이다.

가벼운 서비스로써 새로운 기능을 구현하는 것은 몇 가지 장점이 있다. Monolith가 더 관리할 수 없게 되는 것을 방지한다. 서비스를 monolith와 독립적으로 개발, 배포, 확장할 수 있다. 신규로 만드는 서비스마다 Micorservice Architecture의 장점을 경험할 수 있다.

그러나, 이러한 접근 방법이 monolith의 모든 문제점을 해결하는 것은 아니다. 이러한 문제들을 해결하려면 monolith를 분해할 필요가 있다. 그렇게 하기 위한 전략을 살펴 보자.

2017/04/18 11:43 2017/04/18 11:43
Trackback Address :: http://www.yongbi.net/trackback/782
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Name
Password
Homepage

Secret
< PREV |  1  |  2  |  3  |  4  |  5  |  ...  7  |  NEXT >