[육각형 개발자] 아키텍처 고민하기

아키텍처 고민하기

• 마이로서비스는 아키텍처의 한 종류이며, MVC, MVP 또한 아키텍처다.
• 차이점이라 하면 시스템 수준의 아키텍처와 클래스 수준의 아키텍처의 차이다.
• 어디까지가 아키텍처고 어디까지가 상세 설계에 속하는지 명확하게 구분하기는 어려우나, 아키텍처는 설계 과정에서 나오는 결과물이라는 것이다.

아키텍처를 결정하는 요인

• 특정 아키텍처가 유행한다고 선택하면 안된다.

기능 요구 사항과 품질속성/비기능 요구사항을 고려해야 한다!

 

✏️ 기능 요구사항

기능 요구사항이란 소프트웨어로 해결하고자 하는 문제와 관련이 있다.

기능 요구사항은 아키텍처에게 영향을 준다.

 

✏️ 품질속성/비기능 요구사항

품질 속성의 예로는 성능과 확장성이 있다.

어떤 품질 속성은 업무 도메인에서 도출된다. (법률 조건)

품질속성은 대부분 요구사항에 없더라도 경험을 토대로 자연스럽게 도출된다. (ex. 가용성, 인증, 인가)

당연하다고 생각하는 품질 속성도 경험이나 역량에 따라 놓칠 때가 많다.

경력이 많지 않은 개발자는 기능 구현에 몰두하다가 품질 속성의 중요성을 인지하지 못하는 경우도 있다.(ex. 보안)

또한 유지보수성도 매우 중요하다. 유지보수성이 나쁘면 시스템을 변경하고 개선하는데 비용이 증가하며 결국 서비스의 경쟁력이 떨어진다.

 

트레이드 오프

품질 속성을 높이면 시스템의 복잡도가 증가한다.

가용성, 성능, 확장성, 보안, 신뢰성, 유지보수성, 지역화, 연속성 등 아키텍처와 관련된 품질 속성은 다양하다. 모든 품질 속성을 높이는 것은 불가능에 가까우며, 각 품질 속성을 높이면 시스템의 복잡도는 배 이상 증가한다.

 

심지어 서로 영향을 주는 품질 속성도 존재한다. 보안 품질 속성을 높이면 성능 품질 속성도 떨어진다.

품질 속성은 비용과도 연결된다. 가용성을 높이는 방법 중 하나는 구성 요소를 이중화 하는 것이다.

 

성능도 비슷하다. 데이터베이스 성능을 높이려면 장비 스펙을 올리면 되는데 비용은 몇 배 이상 증가한다.

품질 속성을 높이면 복잡도와 비용이 증가하고 서로 상충하는 품질 속성도 존재하기 때문에 아키텍처를 선택할 때 높이고자 하는 품질 속성 간의 절충이 필요하다. 절충하는 과정에서 하나를 얻으면 하나를 잃게 된다. 감당할 수 있는 수준의 복잡도, 사용자 규모 대비 적절한 인프라 비용, 시스템에 기대하는 최소 품질을 고려해서 아키텍처를 결정해야 한다.

 

모든 면에서 최고인 아키텍처를 추구해서는 안된다.

모든 게 완벽한 아키텍처가 아닌 가장 나쁘지 않은 아키텍처를 선택해야 한다.

 

주요 품질 속성

가용성, 성능, 확장성, 탄력성, 견고성, 결함 허용, 신뢰성/안전성, 유지보수성, 지역화, 테스트 가능성, 합법성, 보안, 배포 가능성, 추적성

아키텍처가 중요한 이유

• 아키텍처는 시스템의 골격 역할을 한다.
  • 만들려는 시스템에 따라 적합한 아키텍처가 존재한다.
  • 데이터 일관성이 중요한 API서버의 아키텍처(트랜잭션 처리)/채팅을 위한 아키텍처(비동기 메시징 처리)
• 아키텍처는 품질 속성에 영향을 미친다.
  • 선택한 아키텍처에 따라 높일 수 있는 품질 속성이 있고 아닌 속성이 있다.
• 아키텍처는 (대부분) 기능과 직교한다.
  • API 서버를 비동기 프레임워크로 구현하면 일부 성능 지표를 높일 수 있지만, 관리자를 위한 백오피스 기능이나 CPU 연산이 많은 작업에 적합하지 않다.
• 아키텍처는 시스템을 제한한다.
  • 인증,인가를 위해 어떤 구조를 선택했는지에 따라 관리할 수 있는 인가범위가 달라진다.

시스템의 규모가 클 수록 위에서 언급한 4가지 이유로 아키텍처를 신중하게 결정해야 한다.

아키텍처 변경

재미로 할 일은 아니다. 또한 빅뱅방식이라고 해서 모든걸 다시 개발하는 방식도 있다만, 새 시스템을 만드는 도중에도 기존 시스템에 새 기능이 추가되거나 기존 기능이 변경되기 때문에 기존 시스템과 새로 만드는 시스템 간 기능 구현을 계속 동기화해야하는데 이 과정에서 변경된 기능이 누락되기도 한다.

시간도 오래걸린다.

따라서 현실적인 방법은 점진적으로 구조를 변경하는 것이다. 동기 연동을 비동기연동으로 바꾸어 각 서비스 간 자율성을 높이고 서비스 간의 영향을 감소시켜서 서비스의 독립성을 높여야 한다.

패턴 익히기

설계 결과물은 이전에 경험한 구조나 간접 경험한 구조를 바탕으로 만들어진다.

특정 맥락에서 반복되는 문제 해결법을 패턴이라고 부른다.

대표적인 패턴

• 아키텍처 패턴
  • 아키텍처 패턴은 아키텍처 수준에서의 패턴을 말한다.
• 디자인 패턴
  • GoF 디자인 패턴: 전략패턴, 커맨트패턴, 템플릿 메서드, 팩토리 메서드 패턴 등 개발 과정에서 자주 사용할 수 있는 패턴이 있다.
• 기업 통합 패턴
  • 파일 전송부터 메시징에 이르기까지 시스템 간 통합을 위한 패턴이다.
• 결함 허용 패턴
  • 제아무리 완벽하게 구현해도 어딘가에 구멍이 있기 마련이고, 내가 만든 시스템이 완벽하더라도 연동하는 다른 시스템에 문제가 생길 때도 있다.
  • 따라서, 문제를 완전히 없애기보다는 문제가 생겼을 때 알맞게 대처하는 방법을 찾아야 한다.
  • 이때 사용하는 패턴이 결함 허용 패턴이다.

📎결함 허용 패턴

에러 발견, 에러 복구, 에러 완화 등 어떻게 처리할지에 대한 패턴

ex. 하트비트, 재시작, 재시도 제한, 서킷 브레이커 등

패턴을 잘 선택하면 설계 시간을 단축해주며, 원활하게 소통할 수 있게 해준다.