Miniservices : MSA에 대한 현실적 대안

 

마이크로 서비스가 현재 프로덕트를 만들때 가장 인기 있는 트렌드 중 하나라는데 이견이 없습니다. 하지만 모든 상황에서 마이크로 서비스가 적합한지에 대해서는 의문이 듭니다.

제가 블로그에 그동안 많이 언급했던 마이크로 서비스 아키텍처에 대해 마틴 파울러는 다음의 조건을 충족해야 한다고 언급합니다.

• 독립적으로 배포 가능하고 확장이 가능해야 함
• 단일 책임
• 느슨한 결합

하지만, 현실은 만만치 않습니다. Legacy가 있는 경우에는 더욱 그렇습니다.

오늘 소개하려고 하는 미니 서비스는 “마이크로 서비스 그룹이 작은 패턴으로 모인 것”과 같습니다.

위의 그림에 미니 서비스가 중간에 위치한 것을 알 수 있습니다. 흔히들 모놀리스는 레거시라고 하며, 마이크로 서비스는 복잡하고 어렵다라고 합니다.

미니서비스 아키텍처는 여러 책임과 공유 데이터 저장소가 있는 아키텍처입니다. 서비스와 구현 세부 정보가 완전히 분리된 마이크로서비스와 달리 미니서비스는 라이브러리와 데이터베이스를 공유할 수 있습니다.

미니서비스 아키텍처 특징

• 관련 서비스는 동일한 데이터베이스를 공유할 수 있습니다.
  • 서로 관련된 모듈이 데이터베이스를 공유할 수 있습니다. 예를 들어서 미니서비스는 이미지 처리, 이미지 렌더링 또는 애플리케이션에 대한 기타 관련 기능을 포함한 여러 기능을 수행할 수 있습니다.
• 서비스 간 통신은 REST API를 통해 이루어집니다.
• 관련 서비스는 배포에 사용되는 코드베이스 및 인프라를 공유할 수 있습니다.

미니서비스 사용 이점

미니서비스는 확장성, 내결함성 및 견고성을 포함한 마이크로서비스 아키텍처의 모든 이점을 상속합니다.

• 향상된 성능
  • 도메인 간의 서비스, 상호 연결 및 네트워크 트래픽의 수를 줄임으로써 애플리케이션 성능을 향상 시킵니다.
• 공유 유지 관리 오버헤드
  • 다양한 관련 기능을 처리하는 서비스를 통해 마이크로서비스와 관련된 유지 관리 오버헤드가 감소합니다.
• 개발자 친화적
  • 미니서비스는 종종 각 개별 서비스를 전담하는 소규모 개발팀을 구성할 여력이 없는 회사에 더 적합합니다.

미니서비스 한계

종단간 테스트는 단일 서비스와 관련된 종속 항목 수로 인해 미니서비스에서는 어려울 수 있습니다. 그렇기에 효율적인 오류 처리 관련하여 복잡성을 증가 시킬 수 있습니다.

마이크로서비스와 미니서비스

미니서비스는 데이터 저장 및 인프라 공유를 허용한다는 점에서 마이크로서비스와 다릅니다. 미니서비스는 마이크로서비스에 대한 보다 실용적인 접근 방식으로 꾸준히 추진력을 얻고 있습니다.

각 아키텍처별로 장점과 한계가 존재하기에 아키텍처를 선택전 철저하게 분석 및 조사를 하는 것이 중요합니다.

미니서비스란?

이런 상황에서 우리가 행복해지는 무엇일까요? 다음은 레거시가 존재하는 상황에서 미니서비스 아키텍처를 선택해야 하는 이유입니다.

1. 재사용성

미니서비스는 재사용 가능한 코드를 생성하기가 수월합니다. 미니서비스는 프로젝트가 제공해야 하는 모든 도메인간 기능에 쉽게 접근할 수 있도록 합니다. Shared 방식을 활용하기에 모든 서비스가 항상 최신 버전의 기능을 참조합니다. copy-past 코드가 없습니다.

2. 단순성

기존 모놀리스는 경량화하는데 초점을 두고 있기에 우리가 구축하는 애플리케이션의 아키텍처를 관리하는데 이보다 좋은 방법은 없습니다.

애플리케이션 아키텍처는 코드 표준을 생각하고, 구성하고, 적용하는 프로세스로 진행됩니다. 아래의 다이어그램은 다계층 코드 구조를 보여줍니다. domain1은 추가 기능을 위해 domain2의 컨트롤러를 호출합니다.

미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.

3. 분리 그리고 빠른 속도

모든 서비스는 애플리케이션 수준에서 “결합”됩니다. 마이크로서비스처럼 도메인 사이를 이동시 네트워크 트래픽을 걱정할 필요가 없습니다. 아키텍처 구조에 스며들었던 대기열도 발생하지 않습니다.

4. DevOps

각 미니서비스를 독립적으로 배포하여 탄력적으로 만들 수 도 있지만, 그것이 필요한것인지 고민할 필요가 있습니다.

5. 쉬운 디버깅

단일 프로젝트 또는 도메인에 대한 모든 미니서비스를 로컬에서 쉽게 실행 할 수 있습니다. 로그는 쉽게 통합되고 캡쳐되기에 기본적인 디버깅을 수월하게 할 수 있습니다.

6. 네크워크 트래픽 감소

Network Hop이 적을 수록 대기 시간이 줄어들며, 성능이 향상됩니다. 미니서비스는 코드 기반으로 미니서비스간 통신을 허락하거나 혹은 네트워크를 통해 통신을 하도록 선택할 수 있습니다. 어느 방식을 선택하던 런타임을 줄일 수 있는 옵션이 존재합니다.

7. 빠른 개발

각 마이크로서비스별 별도의 데이터베이스를 두는 것이 효율적일지 고민해봐야할 문제입니다. 데이터베이스를 중앙 집중화해도 문제가 없다면, 이렇게 진행하는 것도 방법입니다.

이렇게 하게 될 경우에는 코딩 표준, 원칙, 좋은 코드 작성이 핵심입니다.

8. 공유 간접비

“미니”의 기본 목표와 원칙은 필요한 비즈니스 로직의 양을 최소화 하지만, 분리되는 형태의 아키텍처에 충실하다는 것입니다. 또한 코드를 쉽게 재사용할 수 있는 기능이 제공됩니다.

9. 필요한 경우 마이크로서비스화

미니서비스를 올바르게 수행하려면, 합당한 경우에만 커플링을 식별해야 합니다.

마이크로서비스와 미니서비스는 분리될 수 있습니다. 미니서비스로 구축하고 진행하다가 특정 서비스의 경우 마이크로서비스로 분리가 가능합니다. 이미 앞써서 코드 표준을 지켰기에., 미니서비스와 연동에 대한 부분만 네트워크 접근 방식으로 변경하면 됩니다.

결론

미니서비스는 대부분의 서비스가 매우 느슨하게 결합되는 경향이 있는 애플리케이션에 적합합니다. 마이크로서비스가 원하는 아키텍처라고 해도 미니서비스로 시작하는 것이 프로젝트를 위한 더 나은 출발점이 될 수 있습니다.

자, 우리팀은 어떤 선택을 할까요? 정리되면 공유하도록 하겠습니다.

References:

• https://www.bmc.com/blogs/microservices-vs-miniservices/#
• https://medium.com/@tommanion_47885/miniservices-are-how-to-move-fast-e29139d1f13c

Read More

 마이크로 서비스(MSA) 전환시 알아야 할 것

어떤 서비스를 만들때에 Monolithic으로 만들어야 할지? Monolithic으로 만들고 Microservices로 구성해야 할지? 아니면 처음부터 Microservices로 구성해야 하는지에 대한 고민이 생긴다.

Microservices는 최근 급속히 발전하는 많은 기업이 소프트웨어 아키텍처로 이동할 것을 고려하고 있다.

Microservices 또는 Serverless로의 이동은 잘 만들면 금융, 소매, 마케팅, 데이터 분석 및 기타 여러 산업에서 효율성을 가져 올 수 있다.

위 그래프는 2017년에 도입되었거나 2018년도에 도입해야 하는 최우선 기술들을 표현한 그래프이다.

제품이나 서비스가 잘못 설계되었을 경우, Microservices를 적용한다고 하여 품질이 향상되지는 않는다. (그 이유는 똥을 분리해봐야 똥이기 때문이다.)

마이크로서비스를 적용해야 하는 경우

위의 똥 그림 때문이라도 이글을 읽는 당신은 마이크로서비스에 대해서 이해를 해야 한다.

Microservices 제품은 API를 통해 상호 작용하는 형태의 분리된 구성으로 소프트웨어를 설계하는 아키텍처에 대한 방법이다.

• 기능을 분리하는 동안, 여전히 일부 중복되는 기능과 코드가 존재한다.
• 주요 기능을 수행하는 것 이외에, 마이크로서비스는 API를 통해 다른 모듈과의 연결을 지원한다.
• 마이크로서비스는 개별적으로 개발이 될 수 있지만, 상호 의존성에 대한 부분이 존재하고 이는 출시 전에 테스트가 심도있게 되어야 한다. 특정 마이크로서비스의 일부 기능은 다른 마이크로서비스에서 사용할 수 있기에 특정 서비스가 업데이트되면 다른 서비스에 영향을 줄 수 있기 때문이다.

기술적으로 분리를 하더라도 마이크로 서비스는 여전히 상호간 의존하기 때문에, 이 의존성을 낮추기 위해서는 몇가지 기능을 복제해야 하는 상황이 발생할 수 있다.

이런 상황에 대한 부분은 아래와 같다.

• 제품의 일부가 개별적으로 재부팅 할 수 있어야 하며, 이는 복원력을 향상 시킬 수 있다.
• 많은 기능이 의무적인 상호 작용의 수를 줄이기 위해서 분리 되거나 하여 개발의 복잡성을 줄일 수 있어야 한다.
• 새로운 기능의 시장 출시 시간을 단축할 수 있어야 한다.

개발시에 위와 관련된 고민 사항들도 있지만, 운영의 복잡성도 상당하다는 점을 알고 있어야 한다.

즉, 기존의 Monolithic을 분할하게되면 운영의 복잡성을 증가한다는 것을 인지해야 한다.

그리고, 해당 기업의 IT부서가 이러한 시스템을 설계, 구현 및 유지 관리 할 수 있는 전문 지식을 가지고 있어야 한다.

만약, 이런 부분들이 고려되어 있지 않다면 마이크로서비스를 전환하는 것이 불행한 작업이 될 것이다.

Read More

MSA(마이크로 서비스 아키텍처)에 대해서 생각해보기

 

마이크로 서비스는 왜 그렇게 인기가 있을까?

아래는 가상 비디오 공유 플랫폼이 Monolithic 형태로 구현 된 후에 마이크로 서비스 형태로 구현되는 방식이다.

위의 시스템의 차이점은 하나의 큰 덩어리와 작은 단위라는 점이다.

• 독립 개발: 작고 독립적인 구성 요소는 그에 맞춰진 작고 독립적인 팀으로 구성할 수 있다.
• 독립 배포: 각 구성 요소는 독립적으로 확장 할 수 있다. 새로운 서비스가 출시 되면 모든 구성 요소를 배포하지 않고 해당 구성 요소만 배포가 가능하다.
• 재사용성: 구성 요소들은 작고 특정한 기능을 수행한다. 다른 서비스 또는 제품에 쉽게 적용할 가능성이 높다.

대단한 것 같은데, 왜 이전에는 사용하지 않았나?

컨테이너 기술의 인기가 폭발적으로 증가함에 따라 MSA는 기술적 관점에서 구현하기에 훨씬 실용적으로 되었다. 과거에는 컨테이너 기술의 인기가 높지 않았기에 그러지 않았을까?

마이크로 서비스의 문제점은 무엇인가?

마이크로 서비스가 너무 방대해지게 된다면 어떤 문제점들이 발생하는지 알아보자.

개발자의 복잡성 증가

일반적으로 개발자는 로컬 PC에서 개발을 진행하기에 Monolith 처럼 단일 프로그램을 실행하는 것 보다 훨씬 복잡해진다. Docker Compose를 이용하여 부분적으로 완화 될 순 있지만, 시스템을 구성하는 서비스가 증가할수록 개발자가 직면하게 될 문제는 늘어나게 된다.

운영자의 복잡성 증가

서비스를 유지 관리하는 팀의 경우 복잡성이 증가한다. Monolith의 방식처럼 몇 개의 실행중인 서비스를 관리하는 것 대비 수십, 수백 또는 수천 개의 실행중인 서비스를 관리해야 한다. 많은 서비스와 연동 경로로 인해 운영 복잡성이 증가하게 된다.

Devops 복잡성 증가

문제는 많은 조직이 여전히 분리된 개발 및 운영팀으로 운영되고 있다는 사실이다. 이런 조직은 마이크로 서비스 채택에 어려움을 겪을 가능성이 훨씬 높다는 것이다.

이런 단점을 극복하고자 Devops를 채택한 조직도 어렵긴 마찬가지다. 컨테이너 오케스트레이션 시스템 관점에서 진화하는 시스템을 이해하는 것은 매우 어렵다. 개발자와 운영자가 좋은 소프트웨어를 만드는 마음이 강하더라도 말이다.

전문 지식이 필요

전문가가 해당 프로젝트를 수행하면 그 결과는 훌륭할 것이다. 효과적인 자동화, 모니터링, Orchestration등을 통해 모든 것이 가능하다. 그러나 이런 도전은 기술이 아니다. 가장 중요한 점은 효과적으로 사용할 수 있는 사람들을 찾는 것이다.

이런 Skill set은 현재 시장에서 수요가 많기 때문에 찾기가 어려울 수 있다.

실제 시스템은 경계가 잘못 정의된 경우가 많다

마이크로 서비스의 이점을 설명하기 위해 사용한 많은 자료에는 독립 구성 요소에 대한 이야기가 많다. 하지만 대부분의 경우 구성 요소들은 단순히 독립적이지 않다.

경계가 잘 정의되어 있지 않으면, 이론적인 관점에서 서비스를 독립적으로 배포 할 수 있다고 해도 서비스간의 상호 종속성으로 인해 결국 서비스 집합을 하나의 그룹에 배포해야 하는 상황이 발생한다.

즉, 새 기능을 배포하려면 여러 서비스를 동시에 배포해야 하기 때문에 실제로는 독립적으로 배포할 수 있는 시스템은 거의 없다.

의사 소통의 복잡성

서로에 의존하는 대규모 서비스를 구축할때에는 많은 서비스간 의사 소통이 발생 할 수 있다. 그리고 이로 인해서 몇 가지 문제가 발생한다.

첫째, 네트워크 호출이 실패 할 것을 예상해야 한다. 즉, 하나의 서비스가 다른 서비스를 호출 할때 최소한 여러번은 재시도를 해야하는 것을 의미한다. 이제는 서비스가 잠재적으로 많은 서비스를 호출해야 하기에 복잡한 상황에 처하게 된다.

사용자가 비디오 공유 서비스에서 비디오를 업로드한다고 가정하자. 업로드 서비슬르 실행하고, 데이터를 Transcode 서비스에 전달하고, Subscription을 업데이트하고, 권장 사항을 업데이트해야 할 수 있다. 이 모든 호출에는 일종의 Orchestration이 필요하다.

해당 작업이 실패하면 다시 시도해야 한다.

위의 재시도 논리는 관리하기가 어려울 수 있다. 동기적으로 일을 시도하는 것은 종종 끝나지 않고 많은 실패 지점이 존재하기 때문이다. 이 경우에 보다 안정적인 솔루션은 비동기 통신을 사용하여 통신을 처리하는 것이다. 비동기 패턴은 본질적으로 시스템을 stateful 상태로 만든다. 분산 처리에서 Stateful 시스템을 만드는 것은 어렵다.

버전 관리는 어려울 수 있다.

노드 모듈, Java 모듈, C 라이브러리등 소프트웨어 시스템의 종속성 관리는 매우 어렵다. 독립 구성 요소간의 충돌 및 여러 문제를 처리하기가 매우 어렵다.

분산 트랜잭션

트랜잭션 무결성이 필요한 상황에서 마이크로 서비스는 매우 고통스러울 수 있다.

분산 상태는 매우 다루기가 어렵기에 이 문제를 해결하기 위해서는 마이크로 서비스 모델에서 구현하는데 드는 비용이 매우 클 수 있다.

네트워킹 악몽

마이크로 서비스를 사용할 때 일반적으로 많은 노드에 분산 된 많은 서비스가 존재하고 이는 일반적으로 훨씬 복잡한 네트워킹 배치가 될 것이라는 것을 의미한다. 서비스 간 로드 밸런싱, DNS가 더 많이 사용되는 것, 가상 네트워킹 계층 등이 네트워킹의 복잡성을 숨기기 위해 시도한다.

결론, 마이크로 서비스와 아키텍처를 혼동하지 말자

마이크로 서비스는 구성 요소의 또 다른 패턴 또는 구현일 뿐이며 그 이상은 아니다. 마이크로 서비스가 시스템에 존재한다고 해서 시스템의 아키텍처가 해결되었다는 것을 의미하지 않는다.

마이크로 서비스는 시스템 고유의 설계가 아니라 패키징 및 운영과 관련된 기술 프로세스와 관련이 있다. 구성 요소에 대한 적절한 경계는 시스템에서 가장 중요한 과제 중 하나이다.

Docker 컨테이너 여부 및 서비스 크기에 관계없이 항상 시스템을 함께 배치하는 방법에 대해 신중하게 생각해야 한다. 이에 대한 정답은 없으며 어려운 점을 해결하기 위한 많은 옵션은 존재한다.

Read More

Microservice의 ROI를 측정을 위한 매개변수

 

마이크로서비스 개발을 위한 ROI를 알고자 하는 CIO/CTO가 상당히 많습니다. 그들 중 일부는 수익대비 비용으로 측정하려고 노력하고 있습니다.

이런 사항들은 CIO/CTO가 고민해야 할 관심사이고 비즈니스에 미치는 영향이 중요하고 변경된 개발 사항이 매출 증가로 이어져야 하기 때문입니다.

그러나 개발은 다른 고려 사항을 염두하고 시작해야 합니다.

고객 및 이해 관계자를 행복하게 만드는 것은 중요한 행동이며 더 좋은 비즈니스 결과로 이어지게 됩니다. MSA(Microservice Architecture)는 즉각적인 영향을 줍니다. 마이크로서비스 구현시 ROI를 측정하는 가장 좋은 방법은 아래의 매개 변수를 고려해야 합니다.

1. 다국어 기술 환경 수용
2. 신속한 애자일 환경 제공 — 최단 시간내에 가장 빨리 기능을 전달
3. 빠르게 운영환경으로의 이동
4. 응용 어플리케이션의 크기 조정 — Heavy한 어플리케이션은 많은 양의 자원을 사용합니다.
5. 제품/기능/서비스가 복잡하거나 얽혀 있는 경우
6. Resilience/Fault Tolerance가 중요한지

마이크로서비스 아키텍처의 특징은 민첩한 방식의 지속적인 Deploy입니다.제품/서비스가 고객에게 다가 갈수록 피드백을 빨리 받을 수 있기 때문입니다.

결국 기업은 올바른 피드백이 실행되기를 기다리고 있고, 이 피드백을 빨리 반영한 제품/서비스를 출시해야 하기 때문입니다.

짧고 긴밀한 피드백 주기는 모든 제품/서비스 회사에게 주는 선물입니다.

MSA는 이를 달성하는데 도움을 줍니다.

Read More

MSA(마이크로 서비스 아키텍처)에서 단일 데이터베이스를 분리해야 하는 이유

기존 Monolithic 서비스를 분해하여 Micro Service 아키텍처를 사용할 경우 데이터베이스에 중점을 두는 것이 중요합니다. 어플리케이션과 연계된 데이터베이스를 여러개의 작은 데이터베이스로 분할하는 확실한 전략이 필요합니다.

즉, 기존에 사용하던 Monolithic의 통합 데이터베이스를 분리해야 합니다.

마이크로 서비스 아키텍처는 각 마이크로 서비스가 자체 도메인 데이터가 있는 별도의 데이터베이스를 가지도록 설계해야 합니다. 이렇게 해야 마이크로 서비스를 독립적으로 배포하거나 확장 할 수 있기 때문입니다.

기존 Monolithic 서비스에는 단일 데이터베이스가 있고 데이터는 다른 컴포넌트간에 공유됩니다. 데이터가 단일 저장소에 관리되기 때문에 개발이 더 간단하다는 장점이 있지만, 데이터베이스 설계에는 여러 가지 문제가 존재합니다.

단일 데이터베이스 설계의 문제점

위의 그림처럼 Monolithic 데이터베이스를 사용하는 설계는 서비스 변경 사항을 독립적으로 배포 할 수 없도록 상호간의 밀접한 결합 방식을 통해 무능력하게 만듭니다. 동일한 데이터베이스에 엑세스하는 여러 서비스가 있는 경우 모든 서비스간에 스키마 변경 사항을 조정해야 합니다.(어디서 어떤 데이터를 사용하는지 알 수 없기에…) 변경 사항을 적용 할 때 추가 작업에 대한 지연이 발생할 가능성이 큽니다.

단일 데이터베이스를 수평 확장 할 수 있는 옵션만 있기에 어플리케이션 단에서 개별 서비스를 확장하는 것이 어렵습니다.

어플리케이션 성능을 향상 시키고자 할때, 단일 데이터 베이스를 사용하면 여러 개의 큰 테이블을 조인하여 필요한 데이터를 가져와야 하기에 데이터 검색이 어려워집니다.

그리고 가장 큰 문제는 모든 어플리케이션에서 관계형 데이터베이스만 사용하도록 제한하게 됩니다. No-SQL 데이터베이스가 특정 서비스에 더 적합할 수 있어도 제한으로 인해 사용할 수 없게 됩니다.

마이크로서비스 아키텍처에서 데이터를 처리하는 방법

각 마이크로 서비스는 자체 데이터베이스를 가지고 있어야 하며 해당 마이크로 서비스와 관련된 데이터를 모두 포함해야 합니다. 이렇게 하면 각 서비스를 독립적으로 배포 할 수 있습니다. 각 서비스마다 독립적인 데이터베이스를 소유할 수 있게 됩니다.

마이크로 서비스의 설계 사상은 도메인 기반이어야 하며 한정된 컨텍스트를 가져야 합니다. 데이터 우선 접근 방식보다 코드 우선 접근 방식을 따라야 합니다. 따라서 가장 먼저 모델을 설계해야 합니다. 이 작업은 새로운 요구 사항이나 프로젝트를 시작할 때 데이터베이스 테이블을 먼저 설계하는 전통적인 사고 방식과는 근본적으로 다른 접근법입니다. 항상 비즈니스 모델의 무결성을 유지하려고 노력해야 합니다.

데이터베이스를 디자인할때 어플리케이션 기능을 살펴보고 관계형 스키마 필요 여부를 결정해야 합니다. No-SQL에 대한 가능성도 열어 두어야 합니다.

데이터베이스는 각 마이크로 서비스에 대해 개별적으로 취급되어야 합니다. 다른 마이크로 서비스는 다른 마이크로 서비스의 데이터베이스 내부에 저장된 데이터를 직접 수정할 수 없습니다.

아래의 그림에서 Order Service는 가격 데이터베이스를 직접 업데이트 할 수 없으며 해당 마이크로서비스의 API를 통해서만 엑세스가 가능해야 합니다. 이를 통해 서로 다른 서비스간에 일관성을 유지할 수 있습니다.

이벤트 중심 아키텍처는 서로 다른 서비스간에 데이터 일관성을 유지하는 패턴입니다. 작업을 완료하고 시스템 리소스를 차지하기 위해 ACID 트랜잭션을 기다리는 대신 메세지를 대기열로 Offload하여 어플리케이션을 보다 유용하고 효율적으로 만들 수 있도록 고려 해야 합니다. 이는 서비스 간의 Loosely Coupled를 제공합니다.

Queue에 대한 메시지를 이벤트로 처리 될 수 있으며 Pub-Sub 모델을 사용할 수 있습니다.

Monolithic에서 마이크로서비스로의 여정중 데이터베이스 변경 사항을 처리하는 것은 쉽지 않지만, 꼭! 넘어야 하는 부분입니다.

Source: https://dzone.com/articles/breaking-the-monolithic-database-in-your-microserv

Read More

Back-end for Front-end Pattern (BFF)

소프트웨어 구성의 진화

완전하게 분산된 아키텍처가 실행되기 전에는 일반적으로 하나 이상의 계층으로 어플리케이션을 작성합니다.

이러한 아키텍처는 매우 복잡할 순 있지만, 전반적으로 다른 어플리케이션간에 선을 그려서 시작지점과 끝지점을 명확하게 구분할 수 있었습니다. 각 어플리케이션마다 데이터 사본과 공통 비즈니스 프로세스가 중복되고 시간이 지남에따라 데이터를 공유하고 비즈니스 로직을 재사용 할 수 있는 어플리케이션이 필요했으며 단순했던 아키텍처는 약간 복잡해졌습니다.

더 많은 재사용과 통합이 필요함에 따라 집단적 사고 방식은 “서비스”라는 매우 추상적인 개념에 정착했습니다.

단순한 사용자 인터페이스였던 LOB(Line-of-Business)시스템이 점점 증가하여 UI기반의 시스템으로 작성되고 있습니다.

모노리틱 파괴

2011년 SoundCloud의 웹사이트는 아래와 같았습니다.

모두 하나의 시스템에 존재했었습니다.

SoundCloud의 경우 Back-end 시스템을 매우 간단한 형태로 생각을 했었습니다.

위의 사고 방식은 큰 상자를 하나의 모놀리틱으로 구현하는 것을 의미합니다. 사실 하나의 큰 상자는 아래처럼 되어 있습니다.

사실 SoundCloud는 하나의 시스템을 가지고 있지 않았고, 여러 구성요소가 존재하는 플랫폼을 가지고 있었고, 이 아키텍처에 대한 문제점을 발견하고 마이크로서비스를 사용하기로 결정했습니다. 그래서 아래와 같이 아키텍처를 변경했습니다.

위의 아키텍처를 수립할때 가장 중요한 점은 새로운 기능에 대한 출시일 단축이었습니다. 그리고 위의 아키텍처 수립당시에는 거의 모든 사용자는 웹에서 서비스를 사용했었습니다. 그러나 사용자층은 웹보다 모바일을 많이 사용하기 시작했습니다. SoundCloud는 안드로이드와 iOS를 위한 모바일 클라이언트를 제공하고 있었습니다. 기존 웹 어플리케이션과 마찬가지로 API를 통해 모바일 클라이언트를 지원했습니다.

SoundCloud의 과제

자체 API를 바탕으로 제품을 구축하는 것이 API가 높은 품질을 유지하고 항상 최신 상태를 확인할 수 있는 가장 좋은 방법으로 인식되었습니다. SoundCloud는 이 접근 방식에 대해 몇가지 문제점을 발견했습니다. 첫번째 문제는 제품 개발에 대한 근본적인 문제였습니다.

단일 프로필 페이지를 생성하려면 아래와 같이 여러 API를 호출해야 합니다.

• GET /tracks/1234.json (저자)
• GET /tracks/1234/related.json (관련 트랙 추천)
• GET /users/7123.json (트랙 작성자 정보)
• GET /users/me.json (현재 사용자 정보)
• …

위의 API들을 병합하여 사용자 프로필 페이지를 만들게 됩니다. 위의 아키텍처에서는 네트워크 병목 현상이 존재 했었고 새로운 것을 추가할때마다 모든 클라이언트가 쉽게 사용할 수 있도록 많은 시간을 투자해야 했습니다.

Front-end를 위한 Back-end

위의 아키텍처로 수립한지 약 1년후, SoundCloud는 새로운 iOS 어플리케이션을 개발하기 위한 준비를 시작했습니다.이것은 사용자 환경을 변화시키는 대규모 프로젝트였고, 아키텍처팀은 위의 문제들이 프로젝트의 방해물이 된다는 것을 알았습니다. 아키텍처를 다시 고민해야 하는 시점이었습니다.

Google의 첫번째 제안 솔루션은 모바일 및 웹용으로 서로 다른 API를 사용하는 것입니다. 이 아이디어는 클라이언트가 API를 소유하고 있는 팀을 가지고 있으면, 상호간의 조정이 필요하지 않으므로 훨씬 빨리 움직일 수 있다는 것입니다.

궁극적으로 코드를 단순화하고 성능을 향상 시켰습니다. BFF는 어플리케이션의 API가 아니라 클라이언트 프로그램의 일부라는 사실을 발견했습니다.

결론

SoundCloud는 생산성을 더욱 향상시키는 방법을 연구하기 시작했습니다. 모든 어플리케이션에 동일한 사용자 프로필 페이지가 존재했기 때문에 모든 BFF가 데이터를 가져와서 병합하는 과정중에 많은 중복코드가 있었습니다. 그래서 API를 묶어서 비즈니스 로직을 제공하는 서비스가 필요했습니다.

시간이 지남에 따라 이런 상황이 점점 더 많이 발견되었고, 아키텍처는 이 부분을 포용하면서 변화되었습니다.

Sources

• http://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html

Read More