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

8장까지 포스팅을 하면서 너무 딥다이브한 것 같아 이번 포스팅은 가볍게 써보고자 합니다. 그렇지만 다음장부턴 또 고민해야 할 포인트들이 많지 않을까요?(홀홀홀..) 포스팅 내용을 도식화 할 만큼 이해하는 과정과 나만의 도식화.. 너무 고통스럽지만 짜릿하잖아요 흐흐

💡 ‘내 생각’ 부분은 스터디때 바로바로 적었던 내용이라 올바른 정보가 아닐 수 있음을 전달드립니다. 또한 스터디 내용을 복습한 것이므로 정확하지 않을 수 있음을 안내드립니다.

 

---

 

Chapter 8. 컴포넌트 기반 사고

💡 지난주 스터디 시간상 진행되지 못한 진도가 이번 회차때 진행되어 함께 포스팅합니다.

아키텍처 분할

소프트웨어 아키텍처 제1법칙에 따르면 소프트웨어는 만사가 다 트레이드오프이다. 선택한 아키텍처에서 컴포넌트를 만드는 방법 또한 마찬가지이다. 책에서는 아키텍처를 분할하는 것을 ‘최상위 분할(top-level partitioning)’이라 부르며 분할 기준으로 대표적인 2가지 스타일이 있다고 설명한다.

그림 8-4 최상위 아키텍처 분할하는 두 가지 방법

• 레이어드 아키텍처, 모듈러 모놀리스가 어떤 기준으로 파티션 되었는지 알아야 한다.
  • 레이어드 아키텍처 : 기술적인 능력에 따라 구성하며 대표적으로 MVC 디자인 패턴, 콘웨이의 법칙(8장 147p)
  • 모듈러 모놀리스 : 단일 배포 단위, 도메인 중심으로 분할(DDD), 그림 8-5(148p)
• 레이어드, 모듈러 모두 장단점이 있기 때문에 선택에는 트레이드 오프가 있다.
• 최근 몇년간에는 분산 아키텍처, 모놀리식 모두 도메인 분할을 적용해가는 추세

 

Q1. 트레이드오프를 따져봅시다. 도메인 분할의 장단점은 무엇일까요? 기술적 분할의 장단점은 무엇일까요?

오늘도 한 페이지 - 최상위 아키텍처 분할의 트레이드오프

내 생각

기술적 분할

• 장점
  • 유저 정의 코드를 확실히 분리할 수 있다.
  • 기능 구현 유형별 코드를 분리할 수 있다.ㅌ
• 단점
  • 강한 커플링(의존성)이 발생할 수 있다.
  • 커플링에 따른 부수 효과가 전파될 수 있다.

도메인 분할

• 장점
  • 가장 자주 발생하는 변경들을 도메인으로 관리할 수 있다.
  • 기능 구현 레벨이 아닌 비지니스 기능에 가깝게 분할할 수 있다.
• 단점
  • 유저 정의 코드가 도메인마다 필요하다면 서브 컴포넌트로 각각에 정의해두어야 한다.

멘토

• 혼자서 빠르게 개발해야 할 때는 레이어드로 개발할 수 있지만, 대규모로 도메인이 3개 이상 넘어가는 경우, 2~3개 이상의 상호작용이 생기는 경우, 사람마다 어떤 도메인이 어떤 도메인을 호출해야하는지에 대한 생각은 다르기 때문에 이해도를 맞추는 과정을 위해서 도메인 분할 위주로 작업하는 경우가 많다.
• 기술적 분할은 데이터 수준에서 결합도가 높다
• 콘웨이의 법칙처럼 레이어드 중심으로도 팀을 꾸릴 수도 있지만 역으로 도메인 중심으로도 팀을 꾸릴 수 있다.

 

 

Chapter 9. 아키텍처 스타일 - 기초

아키텍처 스타일의 분류

아키텍처 스타일은 크게 전체 코드를 단일 단위로 배포하는 ‘모놀리식’과 원격 액세스 프로토콜을 통해 여러 단위로 배포하는 ‘분산형’ 두 종류이다. 완벽한 분류는 없겠지만 이 책에서는 두 종류에 해당하는 아키텍처들을 소개한다. 각 아키텍처에 대한 자세한 내용은 다음 포스팅에서 다룬다.

 

모놀리식

• 레이어드 아키텍처(10장)
• 파이프라인 아키텍처(11장)
• 마이크로커널 아키텍처(12장)

분산형

• 서비스 기반 아키텍처(13장)
• 이벤트 기반 아키텍처(14장)
• 공간 기반 아키텍처(15장)
• 서비스 지향 아키텍처(16장)
• 마이크로서비스 아키텍처(17장)

모놀리식보다 성능, 확장성, 가용성 측면에서 훨씬 강력한 분산형은 매력적인 아키텍처이다. 하지만 이 아키텍처 스타일을 선택하게 된다면 분산형 아키텍처가 풀어야할 공통적인 난제도 함께 갖고 가게된다. 그렇다면 어떤 난제들이 있을까? 이 난제들을 소통 주제로 삼아 이야기해보자.

 

Q2. 다음 중에서 분산 아키텍처를 적용할 때, 맞는 사실들은 무엇일까요? 틀리다면 왜 틀릴까요?

오늘도 한 페이지 - 분산 아키텍처의 난제

내 생각

true: 5, 6

• ‘5. 토폴로지는 변한다’ : 토폴로지란 네트워크 요소들을 물리적으로 연결해 놓은 것인데 ‘물리적’인 것은 분명 교체, 수리, 확장 등 작업이 수반되기 때문에 변하지 않는다는 말은 틀렸다.
• ‘6. 관리자는 여러 명이다’ : 아키텍트가 협의할 사람이 한명뿐이라면 토폴로지가 변하는 일은 없어야 한다.

false: 1,2,3,4,7,8

• ‘1. 네트워크는 신뢰할 수 있다’ : 컴퓨터 사양이 좋아지면서 네트워크의 신뢰도도 높아가고 있지만 1+1=2와 같이 절대적인 명제가 아닌 폭증, 쇠퇴가 발생할 수 있는 논리, 물리적인 것들은 신뢰할 수 없다.
• ‘2. 지연은 0이다’ : 로컬에서 api 호출은 0으로 보일 수 있으나 운영에 배포된 이상 100% 신뢰할 수 없는 네트워크 위에서 지연이 0이다라는 가정은 할 수 없다. 단적으로 대용량 트래픽 발생시 네트워크는 당연히 지연될 수 밖에 없다.
• ‘3. 대역폭은 무한하다’ : 일정 시간 동안 전송 가능한 데이터의 양은 즉 네트워크의 최대 전송 속도인데 특정 api가 요청 당 많은 데이터를 반환한다면 다중 요청이 들어가야 할 경우 반드시 2번의 경우인 지연이 발생활 것이고 1번 네트워크도 신뢰할 수 없게 된다.
• ‘4. 네트워크는 안전하다' : 최근 개인 정보 유출 사태가 일어난 인쿠르트처럼 보안은 각기 배포되는 분산 아키텍처에서 훨씬 더 어려운 미션이므로 네트워크는 신뢰할 수 없으며 안전하지도 않다.
• ‘7. 전송 비용은 0이다’
• ‘8. 네트워크는 균일하다’ : ‘5. 토폴로지는 변한다’의 사실에서 말하는 토폴로지는 더 넓고 추상적인 개념을 말하는 것이겠지만 물리적 네트워크 장비도 포함한다고 생각한다. 때문에 한 회사에서 네트워크에 필요한 하드웨어 제품을 모두 공수해오지 않는이상(그렇다고 균일하다는 건 아니지만) 네트워크는 균일할 수가 없다.

멘토

• ‘7. 전송 비용은 0이다’이 틀렸다는 근거로 ‘물리적인 비용이 발생하기 때문에 전송 비용은 0이다’ 말하는 것보다 물리적인 비용이 구체적으로 어떤 것인지 함께 설명하는 것이 좋다.
• ‘8. 네트워크는 균일하다’가 틀렸다는 근거로 ‘분산 시스템은 서로 다른 구성을 가지고 있기에 네트워크는 균일하지 않다’ 말하는 것보다 다른 구성이라는게 어느차원에서 다르다는 것인지 구체적으로 설명하는 것이 좋다.
  • 대부분의 회사 인프라들이 여러 벤더의 네트워크 하드웨어로 구성되어 있다.
  • 같은 서버라고 해도 어떤 벤더에서 나온 것인지에 따라 다를 수 있다. 왜냐하면 OS에서 필요한 표준들을 다 구현했다 하더라도 구현하는 주체는 사람이기 때문에 휴먼 에러가 발생할 수 있다. 또한 같은 회사꺼라 하여도 버전마다 다를 수 있다.
  • 때문에 서버 어플리케이션으로는 문제가 없는데 패킷 유실이 왜 일어나지? API 중간에 실패가 일어나지? 싶어서 확인하다보면 벤더가 다름으로써 발생하는 호환 문제(리눅스 내에 특정 라이브러리에 버그가 있는데 이 라이브러리를 쓰는 특정 벤더 프로그램 때문에 문제)가 발생할 수 있다.
• ‘4. 네트워크는 안전하다' 는 자연에 의해서도 문제가 생길 수 있기 때문에 안전하지 않다. 때문에 서비스간 타임아웃, 서킷브레이커 같은 메커니즘이 존재한다. MSA 처럼 시스템이 네트워크에 의존할수록 불안정성이 커지게 된다.
• ‘2. 지연은 0이다’ 는 로컬 메모리로 호출해도 시간이 걸리기 때문에 지연은 0이 될 수가 없다.
  • 지연 시간을 모니터링 해야 한다
  • 지연 시간 평균 시간 확인 필요
  • 아웃라이어 개수 확인 필요
• ‘3. 대역폭은 무한하다’
  • 서비스 통신간에 대역폭이 발생하게 된다
  • 특성 네트워크 회선에 허용되어 있는 용량이 있기 때문에 무한하지 않다
• ‘5. 토폴로지는 변한다’
  • 토폴로지는 통신할 때 지나가는 구성요소(라우터, 스위치 등)을 말한다
  • 서비스 도착지점만 지정하는 것이지 어느 경로(라우터, 스위치..)를 통해 도착지점을 가라고 경로를 지정하지는 않는다. 때문에 이 경로가 변할 수 있는 것은 자명한 사실이다.
• ‘6. 관리자는 여러 명이다’
  • 콘웨이의 법칙에 따라 나누게 되면 당연히 관리자는 여러 명이 된다.

 

Q3. 분산 아키텍처에서는 추가로 어떤 것들을 고려해야 할까요?

오늘도 한 페이지 - 분산 아키텍처의 추가 고려 사항

내 생각

분산 아키텍처의 가장 큰 장점인 확장성, 성능, 가용성을 얻는 대신 데이터의 무결성을 잃게된다. 그 이유는 분산 환경에서 장애가 발생하면 어떤 시스템에서 발생했는지 추적과 트랜잭션을 명확히 할 수 없기 때문이다. 때문에 추가로 고려해야 할 이슈는 로깅과 트랜잭션이다.

 

멘토

• 데이터 동기화의 일관성 문제
  • 모놀리스로 하면 메소드 단위로 호출이 되고 트랜잭션에 한 세션에 묶어서 보낼 수 있지만 분산 아키텍처처럼 api로 나눠져 있으면 위의 것들이 안됨. 이는 즉 분산 트랜잭션 이슈로 볼 수 있음.
• 레이턴시 문제때문에 모듈러 모놀리스도 많이 쓰이게 됨.
• 계약 관리 및 버저닝
  • 버전관리 이슈를 지칭
• 분산 트랙잭션
  • 분산 아키텍쳐는 일관성을 만족하기에는 불가능하고, 최종적 일관성을 맞추는 것을 목표로 한다.
  • 최종적 일관성을 맞추기 위해 100%는 아니지만 확률을 높이기 위한 방법으로 ‘BASE 트랙잭션’을 사용한다.
  • 100% 맞추기 위해 재처리, 배치를 돌려서 전체 체크를 하는 방법을 고려해볼 수 있다.
• 보상 업데이트
  • API 호출을 실패했을 때 어떻게 할 것인지 미리 지정하는 것
  • 하지만 보상 트랜잭션이 실패했을 때 어떻게 복구할 것인지에 대한 고민도 필요
• 분산 로깅
  • msa같은 경우에는 특정 게이트웨이에서 api를 호출하게 된다. 하지만 이럴 경우 이 게이트 웨이가 SPOF가 되게 된다.
  • 게이트웨이를 통해서 호출한 api중 어떤 api가 실패했는지 알 수가 없다. 때문에 이 흐름을 추적해야 하는데 이때 분산 로깅 이슈가 발생한다. 이 로깅을 어떻게 한번에 추적할 것인가?가 과제가 된다.
  • 포괄적인 상호작용 로그가 없이는 디버깅이 어려워지는 문제 발생

 

---

 

마무리

처음 8장을 공부할때 아키텍처를 분할한다는 것과 9장에서 아키텍처 스타일(패턴)을 유사한 개념으로 바라봐서 헷갈렸는데 여태까지 공부한 개념을 써보기위한 새로운 프로젝트를 설계해보니 조금은 알것같다. 8장에서 말했던 아키텍처 분할이란 코드 분할 방법을 결정짓기 위한 분할법인 것이고(근본 아키텍처 스타일에 영향을 미침) 아키텍처 스타일이란 코드 배포 단위를 결정하기 위한 스타일을 지칭하는 것으로 이해할 수 있을 것 같다.

앞으로 더 공부해 나가다보면 이 생각이 잘못되었다는 것을 알거나, 저자가 말하고 있는 의미와 유사한 접근이였구나 둘중 하나를 알게되겠지? 추상적인듯 아닌듯 어렵다. 그래도 그동안 실무하면서 문제는 인지했지만 어떻게 접근해야할지, 뭐가 원인이였는지, 어떤 방향으로 점진적 발전을 해나가야할지.. 이제서야 접하게되어 아쉽고, 그때 적용해보았으면 좋았을 걸 싶다.

근데 어쩌겠는가 지나갔으니 앞으로는 적용해나가봐야징~ 그래서 새로운 프로젝트 하지롱~ 헤헤 재밌겠당~ㅂ~