[소프트웨어 아키텍처 101] 9. 아키텍처 스타일 기초

인상깊은 부분/내 생각

실무에서 순수하게 모놀리식을 쓰는 경우가 많을까?

s3, serverless, firebase 등을 활용하는 순간 내 시스템 배포는 모놀리식 이어도 전체적인 모습은 분산 아키텍처를 사용하게 되는 거 아닐까?
이 경우 분산아키텍처에서 고려해야하는 요소들을 제3자(네트워크를 이용하는) 연동 파트에서도 고려해야한다.
비중의 문제인걸까? 완전한 모놀리식은 보기 어려운 것 같다.
으음! 아키텍처 차원에서는 모놀리식이라고 보는게 맞으려나? 내가 컨트롤할 수 있는 영역을 어떻게 바라보고 다루느냐도 중요하니까..

분산 아키텍처에서의 트랜잭션

최종일관성을 기반으로 트랜잭셔널 사가와 BASE 기법을 사용한다.
확장성, 성능, 가용성을 얻는 대가로 데이터 일관성과 무결성을 희생하는 트레이드오프인 셈이다

---

요약

• 아키텍처 스타일은 아키텍처 패턴이라도 부르며, 다양한 아키텍처 특성을 다루는 컴포넌트의 명명된 관계를 기술함9.1 기초 패턴 (기본적인 패턴)
• 소프트웨어 아키텍처의 역사를 통틀어 끊임없이 나타나고 있는 패턴들
• 9.1.1 진흙잡탕
  • 뭐 하나 뚜렷한 아키텍처 구조가 전무한 상태
• 9.1.2 유니터리 아키텍처
• 9.1.3 클라이언트/서버
  • 프론트엔드와 백엔드로 기술적으로 기능을 분리한 2티어 또는 클라이언트/서버 아키텍처
  • 데스트콥 + 데이터베이스 서버
    • 표준 네트워크 프로토콜을 통해 접속가능한 스탠드얼론 데이터베이스 서버와 궁합이 좋음
    • 프레젠테이션 로직은 데스트콥에 두고 계산량이 많은 액션은 사양이 탄탄한 데이터베이스 서버에서 실행
  • 브라우저 + 웹서버
  • 3티어
    • 1990년대 후반 인기를 끈 3티어 아키텍처
    • 고성능 데이터베이스 서버를 사용하는 데이터베이스 티어, 애플리케이션 서버가 관리하는 어플리케이션 티어, 그리고 처음에는 HTML로 시작하여 기능이 점점 많아진 프론트엔드 티어
    • 3티어 아키텍처는 분산 아키텍처에 적합한 공통 객체 요청 브로커 아키텍처(Common Object Request Broker Architecture), 분산 컴포넌트 객체 모델(Distributed Component Object Model)과 같은 네트워크 수준의 프로토콜과 잘 맞음9.2 모놀리식 대 분산 아키텍처
• 아키텍처 스타일의 두가지 종류
  • 모놀리식 : 크게 전체 코드를 단일 단위로 배포하는 모놀리식
    • 레이어드 아키텍처 (10장)
    • 파이프라인 아키텍처 (11장)
    • 마이크로커널 아키텍처 (12장)
  • 분산형 : 원격 액세스 프로토콜을 통해 여러 단위로 배포하는 분산형. 모놀리식 아키텍처 스타일에 비해 성능, 확장성, 가용성 측면에서 훨씬 강력하지만 무시할 수 없는 트레이드오프가 존재함
    • 서비스 기반 아키텍처(13장)
    • 이벤트 기반 아키텍처 (14장)
    • 공간 기반 아키텍처 (15장)
    • 서비스 지향 아키텍처 (16장)
    • 마이크로서비스 아키텍처 (17장)
• 분산 컴퓨팅의 오류
  • 9.2.1 분산 컴퓨팅의 오류 #1 : 네트워크는 믿을 수 있다
    • 네트워크 신뢰도는 점점 좋아지고 있지만 아직도 못미덥다
    • 그래서 타임아웃 장치나 서비스 사이에 [[서킷 브레이커(circuit breaker)]]를 마련하는 것
    • MSA처럼 네트워크에 의존할 수록 시스템의 신뢰도는 잠재적으로 떨어질 가능성이 있음
  • 9.2.2 분산 컴퓨팅의 오류 #2 : 레이턴시는 0이다
    • 아키텍트는 어떤 분산 아키텍처를 구축하든지 간에 평균 레이턴시를 반드시 알아야한다
    • 특히 MSA(17장)은 서비스가 잘게 나뉘기 때문에 서비스 간 통신량도 만만치 않음
    • 평균 레이턴시도 중요하지만 95~99번째 백분위수를 이해하는 것은 더 중요함
    • 평균 레이턴시가 60밀리초에 불과해도 95번째 백분위수는 400밀리초일 수 있음. 보통 이런 긴 꼬리 레이턴시가 분산 아키텍처의 성능을 저해하는 주범이 됨
  • 9.2.3 분산 컴퓨팅의 오류 #3 : 대역폭은 무한하다
    • MSA에서 시스템이 자잘한 배포 단위(서비스)로 쪼개지면 이 서비스들 간에 주고받는 통신이 대역폭을 상당히 점유하여 네트워크가 느려지고, 결국 레이턴시(오류#2)와 신뢰성(오류#1)에도 영향을 미친다
    • [[스탬프 커플링(stamp coupling)]] : 스탬프 커플링은 분산 아키텍처에서 상당히 많은 대역폭을 차지한다. 분산 아키텍처 서비스 또는 시스템 간에 최소한의 데이터만 주고받도록 하는 것이 최선의 해결 방법이다.
  • 9.2.4 분산 컴퓨팅의 오류 #4 : 네트워크는 안전하다
    • 가상사설망(VPN), 실뢰할 수 있는 네트워크, 방화벽 이외의 나머지 네트워크는 안전하지 않다.
    • 알려지지 않은, 또는 악의적인 요청이 해당 서비스로 유입되지 않게 철저한 보안 대책을 강구해야 한다
    • 모든 엔드포인트에, 서비스 간 통신에도 보안이 적용돼야 하므로 MSA나 서비스 기반 아키텍처처럼 고도로 분산된 동기 아키텍처에서 당연히 성능이 떨어질 수 밖에 없다
  • 9.2.5 분산 컴퓨팅의 오류 #5 : 토폴로지는 절대 안 바뀐다
    • 네트워크를 구성하는 모든 라우터, 허브, 스위치, 방화벽, 네트워크, 어플라이언스 등 전체 네트워크 토폴리지가 불변할 것이라는 가정은 섣부른 오해이다
    • 아키텍트는 운영자, 네트워크 관리자와 항시 소통하며 무엇이, 언제 변경되는지 알고 있어야한다.
  • 9.2.6 분산 컴퓨팅의 오류 #6 : 관리자는 한 사람뿐이다
    • 대기업의 경우 네트워크 관리자만 해도 보통 수십 명에 이른다. 레이턴시나 토폴로지 변경 문제는 누구와 상의해야할까?
    • 그래서 분산 아키텍처는 복잡할 수 밖에 없고 모든 것을 정상 궤도에 올려놓으려면 상당히 많은 조율 과정이 필요하다
    • 반면, 보놀리식은 단일 단위로 배포하기 때문에 이 정도의 소통과 협력까지는 필요하지 않다.
  • 9.2.7 분산 컴퓨팅의 오류 #7 : 네트워크 운송비는 0이다
    • 여기에서 운송비란, 단순 레이턴시가 아니라 'REST 호출'하는 데 소요되는 진짜 비용을 의미함
    • 분산 아키텍처는 하드웨어, 서버, 게이트웨이, 방화벽, 신규 서브넷, 프록시 등 리소스가 더 많이 동원되므로 모놀리식 아키텍처보다 비용이 훨씬 더 든다.
  • 9.2.8 분산 컴퓨팅의 오류 #8 : 네트워크는 균일하다
    • 온갖 종류의 하드웨어가 서로 다 잘 맞물려 동작하는 것은 아니다
    • 모든 상황과 부하, 환경에서 100% 완벽하게 테스트를 마친 것은 아니므로 실제로 간혹 네트워크 패킷이 유실되는 사고도 심심찮게 일어난다
• 9.2.9 다른 분산 아키텍처 고려 사항 : 분산 아키텍처를 설계할 때 맞딱드리게 될 이슈 및 해결해야할 난제들
  • 분산 로깅 : 분산 아키텍처는 로그 종류만 해도 수백 가지에 달하고 위치도 제각각, 포맷도 제각각이라서 문제를 집어내기가 참 어렵다
  • 분산 트랜잭션
    • 모놀리식 아키텍처에서는 퍼시스턴스 프레임워크가 대신 실행하는 표준 커밋/롤백 기능인 ACID 트랜잭션을 걸어 데이터 일관성과 무결성을 강제한다.
    • 하지만 분산 아키텍처는 사정이 다르다.
    • 분산 아키텍처는 최종 일관성(eventual consistency) 이라는 개념을 바탕으로 별도로 분리된 배포 단위에서 처리된 데이터를 미리 알 수 없는 어느 시점에 모두 일관된 상태로 동기화한다. 확장성, 성능, 가용성을 얻는 대가로 데이터 일관성과 무결성을 희생하는 트레이드오프인 셈이다
    • 분산 트랜잭션을 관리하는 방법으로 트랜잭셔널 사가(transactional saga), BASE 분산 트랜잭션이 있음
  • 계약 관리 및 버저닝
    • 계약은 클라이언트와 서비스 모두 합의한 행위와 데이터이다
    • 분리된 서비스와 시스템을 제각기 다른 팀과 부서가 소유하기 때문에 계약 유지보수가 특히 어렵다
    • 버전 구식화(deprecation)에 필요한 통신 모델은 더 더욱 복잡하다.