초기 아키텍처를 설계하면서 느끼는 어려움들을 기록합니다.

    

    

설계 단계에서의 성능과 구조, 그것이 문제로다.

    

이번 프로젝트는 나에게 있어서 무에서 유를 창조한다고 느낄만큼 처음부터 끝까지 하나같이 쉬운게 없다. 저번 주에 요구사항에 맞는 프로젝트 기획안을 만들고나서 팀원들에게 발표하고, 초기 아키텍처 설계 단계에 나선 지금에 와서 계속해서 헷갈리는 부분이 존재한다. 바로 수직적 확장 vs 수평적 확장의 설계문제이다.

이를 성능과 구조 사이의 갈등이라고도 말하고 싶다.

    

우선 내 프로젝트의 성능 목표는 이러하다. 이 성능 목표도 AWS 비용(n빵)에 따라 조절이 필요할 수도 있지만 우선 초기 성능목표는 이러하다.

< 성능 목표 >

• 응답시간(Response Time) - 2초 이내
• 동시 사용자(Concurrent User) - 30,000
• Think Time - 20~30초(가변적)
• 액티브 사용자(Active User) - 대략 1875 ~2730
• TPS - 대략 938 ~1365

    

수 많은 아키텍처 디자인패턴을 구글링, 유튜브를 통해 찾아 보았지만, 자기들 서비스에 부합한 아키텍처라면서 솔루션입니다~! 하고 소개한다. 보다보면 고개를 끄덕끄덕이지만,

‘그래서 이 인스턴스 타입을 바꾸고 DB는 성능을 높였고, 이 부분은 ASG, NLB를 추가해서 수평확장 분산 뭐시기..알겠는데.. 구체적인 근거와 상황은 뭐시당께요..?! 내 프로젝트에 도입할 기준을 알고싶다~!’ ㅡ 나만이런건가..

    

최대한 기본적인 아키텍처를 초기에 설계하고 운영하면서 점차 Scale up, out 혹은 비용면에서 제거해가거나 줄여나간건가..? 보통 서비스가 엄청난 유저 수를 예상하고 설계되지는 않으니깐?

    

만약 이런 방식으로 진행된다고 하면 문제는 우리 프로젝트는 어느 정도의 꽤 많은 유저 수를 예상하고 진행한다. 순간적으로 치솟는 트래픽을 테스트하고 모니터링하는 Peak Traffic Test이기 때문에 고가용성과 확장성을 보장해야한다.

    

난간에 부딪혔다. 대충 우리의 성능 목표에 벤치마킹할만한 사례를 찾기가 힘들다. 애초에 DAU, MAU같은 수치를 10명, 100명, 1000명 이렇게 단계적으로 잡고 아키텍처를 확장시키는 방식으로 했어야했나 싶지만 사실 이러기에는 우리에게는 시간과 돈이 부족하다. 그렇지만 어떻게든 해내고싶다. 현재는 성능 목표를 기준으로 어느 정도의 타이트한 설계로부터 모니터링하면서 조금씩 늘려가는 방식을 생각 중이다.

    

비용 / 보안 / 성능 / 운영 및 관리 등 여러 측면에서 동시에 따져봐야 한다. 이거참 머리아픈일이다. 재미를 느껴서 다행이다.

    

여기에 나아가 Devops 관점에서는 개발자들이 어떤방식으로 코드 혹은 빌드 관리를 하는지, 배포관리를 편하게 해야할지에 대한 고민을 해야한다. 또 그 문화를 확립해야한다. 이러한 것은 인프라차원에서 어떻게 고려해야 하는 것 일까