엔지니어링 전략 수립

20장. 서비스 아키텍처 전략

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

2005년 마이크로서비스가 처음 도입된 이후, 마이크로서비스 아키텍처, 모놀리식 서비스 아키텍처 또는 이 둘의 하이브리드 중 하나를 채택하는 것에 대한 논쟁은 대부분의 엔지니어링 조직에서 가장 되돌릴 수 없는 결정 중 하나가 되었습니다. 다른 데이터베이스 기술로 마이그레이션하는 것조차 일반적으로 모놀리스에서 마이크로서비스로 또는 마이크로서비스에서 모놀리스로 이동하는 것보다 비용이 적게 듭니다.

업계는 여러 면에서 이 논쟁을 완전히 마무리했습니다. 2010년대 대부분의 하이퍼스케일러는 다년에 걸친 모놀리스에서 마이크로서비스로의 마이그레이션에 참여했지만, 2017년 켈시 하이타워의 유명한 트윗은 "사람들이 분산형 모놀리식 애플리케이션의 단점을 발견한 후 모놀리식 애플리케이션이 다시 유행할 것"이라고 예측했습니다.

대중의 정서가 일반적으로 마이크로서비스를 외면하고 있지만, 많은 엔지니어링 조직은 두 가지를 모두 가지고 있으며, 종종 이전에 불완전한 마이그레이션 노력의 잔재가 남아 있는 경우가 많습니다. 이 서비스 아키텍처 전략에서는 가상의 조직이 두 가지 접근 방식을 모두 사용하고 있으며 앞으로 나아갈 길을 결정하려고 하는 경우를 살펴봅니다. 이 조직을 이론적 규정 준수 회사라고 부르겠습니다.

이 문서 읽기

이 장에는 2022년에 작성된 문서 20-1: 모놀리스를 분해해야 할까요? 단 하나의 문서가 포함되어 있습니다.

이 문서에서 제시하는 전략을 적용하는 것을 목표로 이 문서를 읽는다면 맨 위부터 시작하여 끝까지 읽어보세요. 반면에 이 문서에 담긴 생각을 이해하는 것이 주된 목표라면 탐색, 진단 등의 섹션을 역순으로 읽으세요. 11장에서는 읽기와 사고를 분리하는 이 접근 방식을 설명하고 전략 문서의 일반적인 구조를 자세히 설명합니다. 제 해설은 각주에 나와 있습니다.

문서 20-1: 모놀리스를 분해해야 할까요?

정책

서비스 아키텍처에 대한 정책은 여기에 문서화되어 있습니다.¹ 이 정책에 대한 모든 예외( )는 반드시 로컬 스태프 플러스 엔지니어에게 에스컬레이션하여 승인을 받은 다음, 해당 스태프 플러스 엔지니어와 함께 CTO에게 에스컬레이션해야 합니다. 정책에 대한 질문이 있는 경우 #eng-strategy 으로 문의하세요.

정책은 다음과 같습니다:

• 사업부는 항상 자체 코드 저장소와 모놀리스 안에서 운영되어야 합니다. 다양한 서비스를 제공하지 않아야 합니다. 다른 사업부의 모놀리스에서 작업하는 경우는 거의 없어야 합니다. 미묘한 경우가 있을 수 있으므로 이러한 경우에는 이 정책에 더 가까워지는 결정을 선호하세요.

• 사업부 모놀리스 간의 새로운 통합은 gRPC를 사용하여 수행해야 합니다. 여기서는 새로운 통합에 중점을 두며, 다른 구현(HTTP/JSON 등)을 사용하는 기존 통합을 마이그레이션하는 것은 바람직하지만 시급하지는 않습니다.

  기존 엔드포인트에 대한 변경과 같이 ...