아키텍처 및 시스템 설계 by CTO

개발을 할때 가장 처음 하는 일이 있다.

- 기획 리뷰

- 요구사항 분석

- 그리고 시스템 아키텍처 설계 이다!!!

 

기획 리뷰, 요구사항 분석은 CTO가 아니더라도 대부분의 애자일한 조직에서 개발자가 수행해야할 일 들중 하나이다. 하지만, 시스템 아키는 다르다.

 

왜?

아키를 처음 제대로 설계하지 않게 되면, 모든 개발자가 영향을 받게되고, 이 영향이 개발비용 증가로 이어질 수 있다.

여기서 말하는 비용은 시간적 비용과 비용적 지출 모두를 뜻하는 말이다.

 

"토이 호어"라는 사람이 한말 중 유명한 말이 있다.

https://ko.wikipedia.org/wiki/%ED%86%A0%EB%8B%88_%ED%98%B8%EC%96%B4

토니 호어 - 위키백과, 우리 모두의 백과사전

 

(대략 정리해보면)

소프트 웨어를 설계하는 방법에는 두가지가 있는데

1. 너무 단순해서 결함이 없도록 만드는 방법
2. 너무 복잡해서 결함이 쉽게 드러나지 않도록 하는 방법

 

사람들은 1번이 쉽다고 오인할 수 있지만, 실제로는 1번이 더 어렵다!!

 

왜냐고??

서비스 규모가 커지면 다양한 비지니스 사례가 발생할 텐데, 이 다양한 사례들이 매우 복잡하기 때문에

1번 처럼 만들려면, "복잡한 것" 을 완벽하게 이해한 뒤 "단순"하게 만드는 "능력"이 있어야 하기때문이다.

 

복잡한 것을 복잡한 대로 구현하는 것은 시간적 노력이 가해지면 가능하다.

하지만 복잡한 것을 단순한 형태로 바꾸는 것은 재능의 영역이다.

(물론, 복잡한 것이 본인한테는 단순하게 느껴져서, 그대로 적용한 사람도 있는데 이는 안타깝지만, 본인 스스로가 외로운 개발자의 삶을 선택하는... 또 하나의 길이다.)

 

따라서, 일반적인 기준에서 단순화하는 능력을 길러야 한다.

어떻게? 

 

사물을 보면서 복잡한 사물 중 핵심만 추려되는 !! 능력이 필요한 것이다.

(아, 너무 추상적이야...)

 

자 이제 본론으로 넘어가서

그럼 어떤기준으로 아키를 설계해야한는가?

아래와 같이 간략하게 정리해 보았다.

 

1. 나누는 기준을 명확히 할 것!(관심사 분리)

2. 분리된 서비스 간의 강결합이 없어야 할 것!(느슨한 결합)

3. 서비스의 모든 use case를 충족해야할 것(100만 user 가 한번에 시도시 정상작동)

4. 적절한 인프라 비용

5. 장애대응 정책과 적용

 

간단하게 도메인 관점에서 서비스를 분리하고 각 서비스 끼리는 MQ 를 통해 통신하게 하면된다.

여러 도메인으로 분류된 서비스는 K8S 를 사용하여 하나의 인프라 클러스터 에 담게하고 HPA 등으로

적절하게 사용량을 자동 조율하는 메카니즘으로 가게되면 적절한 인프라 비용을 유지할 수 있다.

 

K8S 내 장애발생시 시간기준? 오류발생? 기준등을 명확히 하여

POD을 새로띄울지 말지에 대해서도 세팅해 놓으면, 장애대응에도 대처 할 수 있다.

 

비지니스 usecase가 다양하고 이용고객이 많아서 다양한 사례가 발생한다 하여도,

왠만한 것은 커버 가능 할 것이다.