5부 아키텍처 - (1) 아키텍처란?

아키텍처란?

 

소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다.

그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다.

아키텍처의 주된 목적은 (1)시스템의 생명주기를 지원하는 것이다. 즉, 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다.

또한 궁극적인 목표는 (2)시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데 있다.

---

1) 개발

 

시스템 아키텍처는 개발팀들이 시스템을 쉽게 개발할 수 있도록 뒷받침해야만 한다.

 

팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다.

- 개발자가 다섯 명으로 구성될 정도로 작다면, 모노리틱 시스템으로도 충분

- 큰 프로젝트라면, 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않음

 

2) 배포

 

소프트웨어 아키텍처는 시스템을 단 한번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 한다.

 

개발 초기 단계에서 MSA를 사용하자고 결정했지만 배포할 시기가 되자 수많은 마이크로서비스를 서로 연결하기 위해 설정하고 작동 순서를 결정하는 과정에서 오작동이 발생할 원천이 될 수도 있다.

 

3) 운영

 

좋은 소프트웨어 아키텍처는 시스템을 운영하는 데 필요한 요구를 알려준다.

즉, 시스템 아키텍처가 개발자에게 명백하게 시스템의 운영 방식을 잘 드러내준다면 좋은 아키텍처라고 생각할 수 있다.

 

4) 유지보수

 

주의를 기울여 신중하게 아키텍처를 만들면 유지보수 비용(새로운 기능 추가, 그에 따라 발생하는 결함)을 크게 줄일 수 있다.

 

5) 선택사항 열어 두기

 

이 챕터에서 제일 많이 얘기하는 부분이다.

 

소프트웨어를 soft 하게 만드는 것은 구조적 가치이며, 이 구조적 가치는 최대한 선택사항을 많이 열어두어야 한다.

소프트웨어는 유연성이 중요한데, 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 상호 연결되는 방식에 상당히 크게 의존한다.

 

모든 소프트웨어 시스템은 정책과 세부사항으로 분리할 수 있다. 소프트웨어를 부드럽게 유지하는 방법은 중요치 않은 세부사항을 가능한 한 많이 열어두는 것이다.

 

예를 들어, 데이터베이스인 경우 개발 초기부터 MySql, Oracle 등등 어떤 DB를 사용할지 결정하지 않는다. Mock 스텁으로 만들어서 개발 한뒤, 천천히 생각한다.

 

Detail을 더 오랫동안 열어 둘 수 있다면 더 많은 실험을 해볼 수 있고 더 많은 것을 시도할 수 있다.

 

뛰어난 아키텍트라면 이러한 결정이 아직 내려지지 않은 것처럼 행동하며, 여전히 결정을 가능한 한 오랫동안 연기하거나 변경할 수 있는 형태로 시스템을 만든다.

 

→ 유연하게 대체 변경가능해야 한다.

6) 장치 독립성

 

소프트웨어는 장치에 의존하면 안된다.

 

---

결론

 

좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합되지 않도록 엄격하게 분리한다. 세부사항에 대한 결정을 가능한 한 오랫동안 미룰 수 있는 방향으로 정책을 설계한다.

 

---

✔ 개인노트

현재 MSA 프로젝트를 진행하면서 구상했던 아키텍처를 생각해보면, 처음부터 이러한 고민을 하지 않았던 것 같다. 레디스, 카프카 와 같은 Detail을 미리 결정해버렸고, 아키텍트의 목적을 분명시 하지 않아서 많이 헤멨다.

특히 레디스 는 Key-Value 형 데이터베이스인데, 타 팀에서 원하는 데이터에 따라 Key를 무한정 만들어야 하는 딜레마에 빠져서 정말 레디스를 DB로 써야 하나에 대한 의문을 수도 없이 가졌던 것 같다.

 

다시 우리팀은 목적을 분명시 했다.

MSA의 목적은 서비스 단위의 컴포넌트를 서로 분리하고 다른 영역과의 종속성을 끊어내는 것이다.

 

현재 우리팀에서 이루고자 하는 목표는 다음과 같다.

- 상품 정보가 변경되면 타 영역에 변경된 내용을 알린다.

- 실시간성 상품정보 API를 제공한다.

 

처음 아키텍트를 설계했다면 카프카&레디스를 고려하지 않고 다른 Detail 세부사항을 고려했을 것이다.

빠른 시간안에 실시간성 상품정보 API를 제공하기 위해 데이터 정합성, 속도를 고려한다면 어떤 아키텍처를 설계해야 할지에 대해 생각했을 것이다.