만들고 쪼개고 만들고 쪼개고 만

...만들다보면 커지고, 커져버리니 쪼개고, 쪼갰는데 다시 슬금슬금 커지고 그러면 다시 쪼개고, 

---

프로젝트라 함은 여러명이 힘을 합쳐 하나의 결과물을 만드는 만큼, 그 결과도 혼자의 양보다 거대해지는 법이다. 세상은 넓고 사람은 많아서 혼자서도 뚝딱뚝딱 프로젝트를 해내는 사람들도 있지만, 어쨌든 결과물이 백에서부터 눈에 보이는 부분까지 크게 구성되어있다는 점은 달라지지 않는다.

모놀리식 아키텍쳐, NGINX에서 가져옴

큰 프로젝트는, -작은 프로젝트라고 하더라도- 완성된 프로젝트라면 여러 기능들이 합쳐져서 종합적으로 작동하게 되고, 개별 기능을 구현하고 그 기능들을 잘 모아서 문제없이 굴러가게끔 하는 것이 OOP스러운 접근 방식이었다. 그런데 결국 하나로 엮인 채, 빌드와 컴파일을 거치고 나면 모듈들은 설계 상에서만 분리되어있었을 뿐, 실제로 실행되는 순간에는 하나의 덩어리로 동작한다.

문제는

모듈 중에 하나라도 고장이 나면 전부가 멈춰버린다는 것이다. 아니 사람이 걷는데 다리하나가 사라지면 넘어지는게 당연하지, 하고 생각할 수도 있지만, 우리가 만드는 프로젝트는 그런 고기능 범용 프로그램이 아니라는 것을 생각하자. 

아메바는 반으로 잘려도 움직이잖아~ 가 더 맞는 이야기일지도 모르겠다.

더더욱 서비스가 커질수록 약점이 많아지는 꼴이 되어간다.

https://www.nginx.com/blog/introduction-to-microservices/#Marching-Towards-Monolithic-Hell

Introduction to Microservices | NGINX

하나하나의 모듈이 전부다 취약점이 되어버리기 때문이다. 게다가 한번에 덩치를 움직이려하니 필요한 컴퓨팅 능력과 크기도 커지게 된다. 물론 프로젝트마다 다르긴 하다. 게임개발 같은 경우에는 필연적으로 모노리식으로 빌드되므로, 당연히 그래야하기도 하고.

마이크로서비스

하나가 망가져도 어찌어찌 다른 기능은 굴러가게 되어있다

이런 식으로, 알림기능이 고장나도 나머지 기능은 굴러간다던지, 최대한 생존성을 높이는 방향으로 진화한 형태다. 

Each backend service exposes a REST API and most services consume APIs provided by other services.

각각의 백엔드는 분리되고 개별적인 서비스로 구성된다. 그리고 REST로 서로 통신하는 것이다. 겁나 복잡할거 같다. 덕분에 직접적인 기능의 노출을 피하고 여러방면의 검증을 거치는 것도 가능하다.

마이크로서비스의 복잡도는 3차원적으로 설명 가능하다

잘게 쪼갤수록 컴퓨팅 리소스도 적어지고, 위험 부담도 낮아진다. 그만큼 귀찮을 것 같긴 하지만, 합리적인 수준의 안정성을 추구하는 개발자라면 당연히 추구하게 되는 결과이기도 하다. 게다가 기능구현을 전부 분리해서 독립된 서비스로 만들게 되면 추후의 재활용성도 높아진다. 개꿀이니 처음에 좀 고생하자, 하고 생각하는 것도 이해는 된다.

The Benefits of Microservices

First, it tackles the problem of complexity. It decomposes what would otherwise be a monstrous monolithic application into a set of services. While the total amount of functionality is unchanged, the application has been broken up into manageable chunks or services.

전체 기능 크기는 유지하면서도, 복잡하지 않게 기능단위의 서비스를 개별적으로 나눠 관리가능하다

Second, this architecture enables each service to be developed independently by a team that is focused on that service.

개개의 기능이 독립적이므로 따로 개발가능하고, 협업에 편하다. 게다가 새로운 기술이 나오게 된다면 그 서비스 개별로 업데이트하거나 업그레이드하는 것도 가능하다.

Third, the Microservices Architecture pattern enables each microservice to be deployed independently.

개별적으로 실행가능하다. 동시에 개별적으로 종료도 할 수 있어서 특정 기능만 멈춰서 수리할 수도 있고, 모든 서비스가 정상이어야 작동하는 모노리식보다 수월한 실행이 가능해진다.

Finally, the Microservices Architecture pattern enables each service to be scaled independently. You can deploy just the number of instances of each service that satisfy its capacity and availability constraints.

각각의 서비스를 부하에 맞춰 스케일 업하거나 다운하는 것도 자유로워진다. 전체 프로젝트를 키우고 줄이는 것보다 효율적이고, 로드밸런서의 역할이 부각된다. 반대로 로드밸런서가 효율적이라면 얼마든지 실시간으로 개선가능하다는 점이기도 하다.

단점은 없을까

The term microservice places excessive emphasis on service size. In fact, there are some developers who advocate for building extremely fine‑grained 10–100 LOC services. While small services are preferable, it’s important to remember that they are a means to an end and not the primary goal.

목적과 수단의 역전 현상이 일어날 수 있고, 그저 마이크로서비스를 하기 위해 서비스를 처음부터 조각조각 찢어놓는 것은, 결과적으로 프로젝트의 미완으로 이어질 가능성이 훨씬 크다. 뭐든지 완성해야 평가 가능한 법이다.

Another major drawback of microservices is the complexity that arises from the fact that a microservices application is a distributed system. Developers need to choose and implement an inter‑process communication mechanism based on either messaging or RPC. 

그 자체로 겁나 귀찮고 복잡해 보이는 것이 실제로 겁나 귀찮고 복잡하다는 점이다. 인공지능을 만들겠다고 바텀업으로 뉴런한개씩 만들어 붙이는 꼴에, 그 사이의 무수한 REST요청을 처리하려면 엄청난 디버깅을 거쳐야 할것이다. 게다가 나누는 것에 집중하면 성능이 낮아진다. 내부적으로 처리되는 함수와, 요청응답을 거치는 api의 차이는 상당하다.

Another challenge with microservices is the partitioned database architecture. Business transactions that update multiple business entities are fairly common. These kinds of transactions are trivial to implement in a monolithic application because there is a single database. In a microservices‑based application, however, you need to update multiple databases owned by different services. 

서비스 갯수만큼... 까지는 아니더라도 상당한 수의 데이터베이스를 동시에 가동해야하고, 문제는 이제 그놈들이 각각 따로 놀것이라는 점이다. 서로 연동해야하고 참조해야하는 데이터가 데이터베이스 바깥의 다른 데이터베이스에 있다....그저 눈물이 앞을 가릴 뿐이다.

Another major challenge with the Microservices Architecture pattern is implementing changes that span multiple services. For example, let’s imagine that you are implementing a story that requires changes to services A, B, and C, where A depends upon B and B depends upon C. 
In a Microservices Architecture pattern you need to carefully plan and coordinate the rollout of changes to each of the services.

왜 괜히 프로젝트의 완성이 아니라 완성도를 위한 기술인지 보인다. 단점이 한도 끝도 없이 나온다. 서로 종속적인 관계의 서비스를 마이크로서비스의 형태로 이식하기 위해서는 아마 정신이 나가버릴 것이다. 뭐가 먼저인지 서비스가 알고 기다릴리가 없다. 알아서 종속된 놈이 켜졌는지 어쨌는지 부모가 확인할 리도 없다. 추가적인 로직이 필수적이다.

Deploying a microservices‑based application is also much more complex. 

a microservice application typically consists of a large number of services. For example, Netflix has over 600 according to Adrian Cockcroft. Each service will have multiple runtime instances. That’s many more moving parts that need to be configured, deployed, scaled, and monitored.

넷플릭스가 서비스 600개..!?

거기에 개별로 서비스마다 인스턴스가 곱하기 3...?

그거를 관리해...?

눈알이 몇개인데요??? 

그만알아보고 싶어진다

실행시키는 것만으로도 고역이다. 거의 쇳덩어리가 하늘을 나는 수준의 기적아닐까. 

장점만 있는 기술은 없는 법이다.