모놀리식 아키텍처 vs. 마이크로서비스 아키텍처: 마이크로서비스는 가고, 모놀리스가 돌아왔다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

모두 진정하세요. 심호흡을 한 번 하고, 인터넷에서 벌어지고 있는 마이크로서비스 대 모놀리스 논쟁의 한가운데로 천천히 들어가 보겠습니다.

핵심 내용:

최근 Amazon은 마이크로서비스를 버리고 모놀리식 아키텍처를 채택해 비용을 90% 절감한 결정을 다룬 사례 연구를 발표했습니다. 이 사례 연구가 공개되자 인터넷에서는 마이크로서비스와 모놀리식 아키텍처를 기술적 링 위에 올려놓고 비교하는 논평과 풍자적인 트윗이 쏟아졌습니다.

현실:

심한 기술적 데자뷔를 겪고 있다고 느끼신다면, 그 느낌이 틀리지 않습니다. 이는 2009년경 서비스 지향 아키텍처(SOA)가 Anne Thomas Manes가 SOA의 죽음을 선언했을 때 처했던 상황과 같습니다. 원문은 인터넷에서 사라진 듯해, 해당 링크는 Manes의 게시물에 대한 David Linthicum의 논평으로 연결됩니다.

물론 Manes의 표현에는 과장과 다소의 빈정거림이 섞여 있었습니다. 우리 모두 잘 알다시피 서비스 지향 아키텍처는 사라지지 않았기 때문입니다. 이는 얼마 지나지 않아 마이크로서비스라는 이름으로 부활했고, 인터넷 곳곳에서 쏟아지는 탄식에서 알 수 있듯이 설계자들은 여전히 성능에서 ‘네트워크’가 얼마나 큰 역할을 하는지 깨닫지 못하고 있습니다.

SOA가 ‘죽은’ 데에는 두 가지 이유가 있습니다:

1. 서로 경쟁하며 비대해진 XML 기반 표준들로 인해 아키텍처가 지나치게 복잡해졌습니다. WSDL, SOAP, UDDI를 좋게 기억하는 사람은 아무도 없습니다. 단 한 명도요.
2. 물리 법칙과 상호 운용성 표준에 따라 네트워크 패킷의 전송 속도는 빛의 속도로, 크기는 1,500바이트로 제한됩니다.

첫 번째 과제는 극복했을지 모르지만, 두 번째 과제는 어떨까요? 두 번째 과제에 대한 유일한 해법은 지금까지도, 그리고 앞으로도 서비스 간 데이터 전송에 걸리는 시간을 정확히 이해하면서 서비스 설계의 세분화 수준을 섬세하게 조율하는 것입니다.

데이터 전송에는 비용이 듭니다. 시간도 걸립니다. 서비스 간 통신에 ‘비용이 전혀 들지 않는’ 경우란 없습니다. 패킷을 네트워크에 올리고 전송한 다음, 네트워크에서 꺼내 최종적으로 처리하기까지 모두 시간이 걸립니다. 전송 계층의 통신에도 시간이 소요된다는 점을 잊어서는 안 됩니다. 소켓을 열고 요청을 수락하는 데도 비용이 들며, 페이로드를 서비스가 처리할 수 있는 형태로 직렬화하고 역직렬화하는 데 걸리는 시간 역시 무시할 수 없습니다.

이제 그 총비용에 사용하려는 서비스 수를 곱해 보세요.

시스템을 더 세분화하여 설계할수록 요청을 처리하는 데 더 많은 시간이 걸립니다. 즉, 요청을 처리하는 데 걸리는 총시간은 해당 요청이 거쳐야 하는 서비스 수에 따라 달라집니다.

세분화 수준이 높아질수록 처리 시간은 길어집니다. 서비스가 많아질수록 네트워크 혼잡도 심해지며, 네트워크 카드와 장치가 패킷의 순서를 맞추고 재전송을 요청하는 과정에서 결국 처리 시간이 늘어납니다.

따라서 SOA와 마찬가지로 마이크로서비스도 지나치게 세분화된 설계 패턴으로 인해 문제를 겪을 수 있으며, 실제로 그렇게 될 것입니다.

Amazon은 마이크로서비스를 대체하기 위해 모놀리식 아키텍처를 선택했습니다. 이는 Amazon의 사용 사례에서는 모놀리식 아키텍처가 최선의 선택이었다는 뜻입니다. 그렇다면 마이크로서비스는 이제 끝난 걸까요?

아닙니다. 대신, 여기서 두 가지 핵심 사항을 짚어야 합니다:

• 첫째, Amazon의 사례를 참고해 서비스에 의존하는 시스템을 설계할 때는 더욱 신중하고 사려 깊게 접근해야 하며, 역할을 지나치게 많은 소규모 서비스로 분산할 경우 성능에 어떤 영향을 미치는지 확실히 이해해야 합니다.
• 둘째, 모놀리식 아키텍처도 실용적인 애플리케이션 아키텍처 선택지라는 점을 기억해야 합니다. 기업 애플리케이션 포트폴리오의 60%가 ‘전통적인’ 아키텍처를 기반으로 한 애플리케이션으로 구성되어 있는 데에는 이유가 있으며, 조직의 16%는 이러한 애플리케이션을 폐기할 계획이 없습니다.

애플리케이션 아키텍처는 그 자체로 좋거나 나쁜 것이 아니며, 모든 사용 사례에 적합한 것도 아닙니다. 조직은 단지 유행한다는 이유로 가장 ‘현대적인’ 아키텍처를 선택하기보다, 한발 물러서서 무엇을 달성하려는지, 그리고 어떤 아키텍처가 그 목적에 가장 적합한지 신중하게 고려해야 합니다.

미래는 하이브리드 IT라고 할 때, 이는 단순히 멀티 클라우드와 온프레미스 배포가 혼합된 환경만을 의미하지 않습니다. 기업의 애플리케이션 포트폴리오 역시 가까운 미래까지 전통적 아키텍처와 현대적 아키텍처가 혼재하는 하이브리드 형태로 유지될 것이라는 의미이기도 합니다. 그렇기 때문에 F5 포트폴리오는 온프레미스든 퍼블릭 클라우드든, 또는 두 환경 모두에서든 모든 애플리케이션을 계속 지원합니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물