분명 여러분도 이런 경험이 있을 겁니다. 열정에 가득 차서 프로젝트를 시작하고, 그 결과물이 너무 멋져서 마치 거대한 건축물처럼 만들어버리죠. 신속하게 배치 가능 모든 것이 순조롭게 흘러갑니다. 처음에는 정말 좋습니다. 함수 간 호출이 즉각적으로 이루어지고 네트워크를 복잡하게 만들 필요도 없습니다. 하지만 코드가 너무 커져서 아주 작은 변경조차도 큰 문제가 되는 시점이 옵니다. 의존성의 악몽 그리고 이번 파병은 자살 임무처럼 보입니다.
코드베이스가 관리 불가능해지고 개발 기간이 급증할 때, 가장 중요한 질문은 "모든 것을 망가뜨리지 않고 이 상황에서 어떻게 벗어날 수 있을까?"입니다. 마이크로서비스 또는 기능 모듈 아키텍처로 전환하는 것은 단순히 코드의 위치를 바꾸는 것만이 아니라, 근본적인 해결책을 제시하는 것입니다. 사고방식의 완전한 변화 확장성과 운영 민첩성을 향상시키기 위해서입니다.
거대한 석조물의 벽: 왜 그것을 버리고 떠나야 할까요?
잘 만들어진 모놀리스는 많은 것을 견딜 수 있지만, 한계는 있습니다. 가장 큰 문제는 바로 이것입니다. 전부 접착제로 붙인 거예요.판매량 증가로 인해 결제 모듈만 확장하려는 경우, 전체 애플리케이션을 복제해야 하므로 아무도 사용하지 않는 부분에 메모리와 CPU를 낭비하게 됩니다. 게다가, 다음과 같은 문제점도 발생합니다. 기술과 연관됨특정 기능을 구현하기 위해 새로운 언어를 사용하고 싶다면, 기본적으로 프로젝트 전체를 다시 작성해야 할 것입니다.
이 외에도, 느리고 위험한 배치코드의 한 부분에 있는 오류라도 전체 플랫폼을 다운시킬 수 있기 때문에 배포에 대한 불안감이 매우 커집니다. 팀들은 버전 충돌로 서로 발목을 잡기 시작하고, 기술 부채 이러한 현상이 누적되면서 시스템은 경직되고 진화 속도가 느려집니다.
이주 경로: 전략 및 패턴
모든 것을 처음부터 다시 작성하는 "빅뱅" 방식에 섣불리 뛰어들지 마세요. 이는 재앙과 비용 초과를 초래할 수 있습니다. 이상적으로는 다음과 같은 단계를 밟아야 합니다. 돌을 조금씩 깎아내다 이러한 전술을 통해:
- 도메인 주도 설계(DDD): 핵심은 식별하는 것입니다. 한정된 맥락기술적 계층별로 나누지 말고 비즈니스 영역별로 나누십시오(예: 사용자, 주문, 청구).
- 모듈형 모놀리스: 서비스를 서로 다른 서버로 분리하기 전에 내부 코드를 재구성하십시오. 동일한 배포 환경 내에 잘 정의된 모듈을 생성하십시오. 건물을 청소하다 마지막 점프 직전에.
- 스트랭글러 피그 무늬 (스트랭글러 피그): 스타 알고리즘이라고 합니다. 모놀리식 아키텍처의 주변부에 새로운 서비스를 만들어 나가는 방식입니다. 이렇게 조금씩 새로운 기능을 추가해 나가는 거죠. 그것은 점차 기존 시스템을 감싸 안는다. 모놀리스가 완전히 사라질 때까지.
- 병렬 실행: 위험을 감수하고 싶지 않은 사람들에게 이 패턴은 모놀리식 시스템과 함께 마이크로서비스를 배포할 수 있도록 해줍니다. 기존 시스템은 여전히 기존 시스템을 제어하지만, 새로운 시스템은 동일한 정보를 처리합니다. 결과를 비교합니다. 최종 교체를 하기 전에 모든 것이 제대로 맞는지 확인하기 위해서입니다.
- 추상화를 통한 분기: 함수가 매우 깊숙이 숨겨져 있을 때 이상적입니다. 다음과 같이 생성합니다. 추상화 계층 코드가 사용하는 인터페이스입니다. 시스템이 실행 중인 상태에서 해당 인터페이스 뒤에 새 서비스를 구현하고 데이터 흐름을 변경합니다.
데이터베이스 퍼즐
마이크로서비스에 코드를 도입하는 것은 그에 비해 쉽습니다. 데이터를 분리하세요모놀리식 아키텍처에서는 하나의 거대한 데이터베이스를 사용하지만, 마이크로서비스 아키텍처에서는 각 서비스가 자체 데이터를 관리해야 합니다. 이를 구현하는 몇 가지 방법은 다음과 같습니다.
현재 데이터베이스에 접근할 수 없는 경우, 다음을 사용할 수 있습니다. 데이터베이스 뷰 각 서비스가 필요한 정보만 볼 수 있도록 하는 것이지만, 이 방식은 일반적으로 읽기 전용이라는 문제가 있습니다. 또 다른 옵션은 다음과 같습니다. 데이터베이스 래핑 서비스기본적으로 데이터베이스를 감싸고 API를 노출하는 작은 서비스를 만들어 클라이언트를 손상시키지 않고 스키마를 마이그레이션할 시간을 확보하는 것입니다.
더 복잡한 경우에는 패턴이 적용됩니다. 서비스형 데이터베이스 인터페이스 읽기와 쓰기를 분리하여 쿼리 전용 외부 데이터베이스와 서비스용 내부 데이터베이스를 생성하고 매핑 엔진을 사용하여 동기화합니다. 점진적인 데이터 마이그레이션을 원한다면 이 방식이 적합합니다. 트레이스 라이터 이 방식은 기존 데이터베이스를 기본 소스로 유지하면서 새 데이터베이스에 데이터를 기록할 수 있도록 하여 사용자를 점진적으로 이동시킬 수 있게 해줍니다.
품질 및 안전: 시스템의 보호 장치
서비스가 하나가 아니라 열 개라면, 문제가 발생할 확률이 높아집니다. 그런 상황을 감당할 여유가 없죠. 테스트의 지름길다층적인 AQA 제도를 시행하는 것이 필수적입니다. JUnit 또는 PyTest를 사용한 단위 테스트Pact를 사용한 계약 테스트부터 서비스가 서로 다른 언어로 전달되지 않도록 보장하는 것, 그리고 JMeter를 사용한 부하 테스트로 시스템이 어디에서 충돌하는지 확인하는 것까지 다양한 테스트를 수행했습니다.
배포할 때는 "클릭하고 기도하는" 방식은 잊으세요. 다음 방법을 사용하십시오. 카나리 릴리스 전체 사용자의 5%를 대상으로 기능을 테스트하고 버그가 있는지 확인하는 방법. 아니면 더 나은 방법은 전체 배포를 진행하는 것. 파란색/녹색두 개의 동일한 환경이 있습니다. 녹색 버전이 실패하면 사용자가 알아채지 못하게 순식간에 파란색 버전으로 되돌아갑니다. 기능 플래그 또한 코드를 재배포하지 않고도 실시간으로 기능을 활성화 또는 비활성화하는 데 필수적입니다.
작동성 및 지속적인 최적화
마이그레이션을 완료했다고 해서 작업이 끝나는 것은 아닙니다. 다음 단계가 필요합니다. 전체 관측 가능성Prometheus, Grafana 또는 ELK Stack과 같은 도구는 로그와 메트릭을 실시간으로 추적하는 데 필수적입니다. 그래야 고객이 전화로 알려주기 전까지는 시스템 장애를 알지 못하게 됩니다.
잊지 마세요 재해 복구증분 백업 및 지리적 이중화 스토리지를 구현하십시오. 데이터 센터에 장애가 발생하더라도 시스템은 백업을 수행할 수 있어야 합니다. 자동 장애 조치 업무가 중단되지 않도록 안전한 백업을 구축하는 것입니다.
모듈화로 가는 길은 마라톤과 같으며, 이를 위해서는 다음과 같은 요소들이 필요합니다. 꼼꼼한 계획과 실용주의가장 중요한 것은 과도한 설계의 유혹을 피하고 모든 것이 마이크로서비스일 필요는 없다는 점을 기억하는 것입니다. 때로는 잘 모듈화된 모놀리식 아키텍처가 가장 효율적인 솔루션일 수 있습니다. 궁극적으로는 비즈니스에 가장 적합한 도구를 선택하는 것이며, 항상 효율성을 최우선으로 고려해야 합니다. 시스템 안정성 및 반복 가능 능력 생산 차질에 대한 두려움 없이.