분산 아키텍처 설계시 유의 사항: 전제 오류부터 잡자

 

소프트웨어 아키텍처 101 - YES24

 

전제 오류 (fallacy)

어떠한 계획/설계를 하던지 간에 우리는 당연시하거나 가정하는 전제들이 있다.

책에서는 특히 분산 아키텍처 설계시 놓칠 수 있는 '오류(fallacy)'들을 소개하고 있다.

여기서 오류라 함은 옳다고 믿거나 가정하지만 사실은 틀린 것을 의미한다.

사실 아키텍처를 설계하는 사람이 이러한 오류에 빠질 수 있다는게 말이 안된다는 생각이 들면서도, 사람이기에 실수할 수 있다는 부분과, 아키텍트가 아니지만 이러한 부분에 대한 지식이 부족한 사람이 아키텍처 설계에 동참하는 경우도 있으므로 이러한 오류들에 대해 정리해두는 편이 좋겠다는 생각이 들었다.

 

오류1. 네트워크는 믿을 수 있다

분명 네트워크는 더욱 발전해 나가며 신뢰성이 높아져 가고 있다.

하지만, 소프트웨어적이나 하드웨어/물리적으로 완벽한 네트워크란 없다. 특히 Inter-Network 상에서는 더 그렇다.

즉, 모종의 이유로 네트워크에 장애가 생기는 것부터 물리적으로 완전히 끊기는 상황까지 여러 상황이 발생할 수 있다.

특히, 분산 아키텍처 특성상 네트워크에 의존하게 되는데, 네트워크를 온전히 신뢰한다는 생각으로 설계를 하면 다양한 문제를 직면하게 될 것이다. (타임아웃 처리 or 서킷 브레이커 설치 등)

 

오류2. 레이턴시는 0이다

CPU부터 메모리 처리까지 그 종류에 따라 레이턴시가 존재한다. 물론 대부분은 찰나의 순간이지만, 그렇다고 레이턴시가 0은 아니다. 심지어 분산 아키텍처는 네트워크 통신에 의존하는데, 네트워크가 아무리 빨라봐야 앞서 말한 것들에 비하면 비교불가할 정도로 느리다. 즉, 동일한 동작에 대해 로컬처리보다 원격처리에 대한 레이턴시가 더 클 수 밖에 없으며, 절대 0이 될 수 없다. 항상 이 점을 기억하고 "자신의 운영 환경의 평균 왕복 레이턴시(average round-trip latency)"를 측정해볼 수 있어야 한다. 아무튼 핵심은 레이턴시가 0이라고 절대 생각하지 말라는 것이다.

 

오류3. 대역폭은 무한하다

어떠한 통신을 사용하든 대역폭(bandwidth)은 존재한다. 그리고 그것은 유한하며 각각 다 다르다. 따라서 설계할 때에는 이러한 대역폭을 고려하여 통신 인터페이스를 선택할 수 있어야하며, 규모/확장성 등을 고려하여 송수신에 불필요한 데이터를 줄이는 등의 것들이 필요하다. 사실 이것은 분산 아키텍처가 아니더라도 중요하게 생각해야 하는 부분이며, 애초에 최소한의 데이터 구성을 하는 것이 중요하다. (스탬프 커플링 방지 등)

 

오류4. 네트워크는 안전하다

이건 누구나 동의할 것이다. 순간 깜빡하더라도 다시 생각해보면 이해할 수 있다.

이를 위해 '보안'을 신경써야 하는데, 분산 아키텍처 특히 MSA(Micro Service Architecture) 같은 경우는 모든 엔드포인트에 이러한 장치가 들어가야 하므로 성능 저하를 일으킬 수 밖에 없다. 즉, 이러한 특성도 고려하여 트레이드오프를 고려하여 적절한 아키텍처를 설계/선정하는 것이 합리적이다.

 

오류5. 토폴로지는 절대 안 바뀐다

Inter-Network, 즉 네트워크 사이에는 라우터, 허브, 스위치, 방화벽, 어플라이언스 등의 토폴로지가 구성되어 있다. 그리고 그 네트워크 범위가 크면 클수록 수많은 토폴로지들이 존재하는데, 이것이 불변한다고 생각하는 것은 매우 잘못 된 생각이다. 이들은 언제든 말도 없이 변할 수 있다!

 

오류6. 관리자는 한 사람뿐이다

회사 규모에 따라서는 관리자가 한 사람인 경우도 있다. 하지만, 그렇지 않다면 관리자는 여러 사람일 수 있다. 총 관리자가 있겠지만 협업을 해본 사람들은 알 것이다. 총 관리자가 모든 것을 알고 있는 것은 아니다. 따라서 이러한 점을 고려해서 대화해야할 사람들을 잘 파악해서 소통해야 한다. 특히 분산 아키텍처의 경우 관리 포인트가 그만큼 나눠져 있을 가능성이 높기 때문에 더욱 유의해야 한다.

 

오류7. 운송비는 0이다

"레이턴시 0이다"라는 말과 비슷한 말인가라는 생각을 할지 모르겠지만, 여기서 말하는 운송비는 actual cost 이다.

즉, 분산 아키텍처 특성상 네트워크를 사용하고 그것들이 분할되어 있기때문에 더 많은 리소스가 필요할 수 밖에 없다. 따라서 아키텍처 설계에 있어서, 이러한 비용도 매우 중요하게 생각해야 한다. 이익을 위해 비용 감축은 당연한 것이지만, 이 당연한 것을 고려하지 않고 설계하게 되면, 생각보다 더 많은 비용이 발생할 수 있다는 것을 명심하라는 것이다.

 

오류8. 네트워크는 균일하다

토폴로지가 다양하다는 것은 네트워크 사이의 구성이 다양하다는 말이다. 그리고 이 말은 네트워크가 균일하지 않다는 말과 자연스럽게 이어진다. 결국 네트워크는 물리적인 연결이다. 그것이 유선이든 무선이든 여러 방식들로 서로 연결되어 통신한다. 그리고 이러한 물리현상을 이용하기 위해서는 하드웨어가 필요한데, 이 하드웨어를 만드는 회사가 얼마나 다양한가? 관심이 없어서 잘 몰랐다하더라도 스마트폰을 떠올리면 된다. 삼성 폰과 애플 폰이 호환이 되는가? 안타깝게도 그렇지 않다. 물론, 네트워크의 경우는 수많은 국제 표준이 있으니 균일할 수 있지 않을까 라는 생각을 할 수도 있겠지만, 네트워크 하드웨어가 제공하는 모든 기능을 표준으로 정의해 놓은 것은 아니다. 심지어 어떤 표준은 일부 추상적이어서 내부는 제조사마다 다르게 만들 수 있다. 단순하게는 이러한 표준부터 소프트웨어 ~ 물리적 특성에 이르기까지 네트워크는 '절대 균일할 수 없다'.

---

정리: 대충 넘겨짚지 말고 고민하자

위에서 다룬 오류들은 사실 CS에 대한 지식만 잘 갖추고 있다면, 당연한 오류들이다. 하지만 사람인지라 망각할 수도 있고 놓치는 실수를 할 수도 있다. 따라서 아키텍처 설계를 할 때는 가능한 이해관계자들과 충분한 대화와 검토를 하는 것이 좋다. 누군가는 아키텍처 설계는 아키텍트만 하는것이 아니냐! 라고 할 수 있다. 하지만, 과연 그런가? 아키텍트가 없는 회사도 있으며, 아키텍트가 있다고 하더라도 결국 그 설계 기반 위에 개발을 하고 비지니스를 풀어나가야할 사람들은 우리 모두이다. 즉, 집단지성을 활용하여 보다 효율적인 아키텍처를 설계한다면 결국은 모두가 좀 더 행복한 결말을 맞이할 수 있을 것이다 :)