brunch

매거진 스타트업과 개발자를 위한 짧은글들

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신현묵 Jan 03. 2017

데이터 중심의 소프트웨어 개발, #2

스마트폰과 MSA의 중심, 그 Risk

스마트폰은 특히 서버사이드 개발에 엄청난 영향을 주게 되었다. 다음의 간단한 사례를 생각해보자.

사용자는 지하철을 타고 가면서 '모바일 게임'을 하고 있다.
하지만, 다음 정류장에서 급하게 내리면서 사용자는 '모바일 게임 클라이언트'를 제대로 종료하지 않고 그냥 주머니에 넣어버리고 내렸다.

이때에 서버는 해당 사용자가 계속 사용 중이라는 것을 알 수 있을까?
세션유지는? 어떻게? 이런 사용자가 수백만?!!!

그리고, 정말 심각한 것은 '모바일 게임'이라면 사용자의 스마트폰 사용량을 추정하거나 예측할 수 없다는 점이다.

정말 많은 스마트폰들이 게임 서버에 접속될 것이고, 특정 시간대에만 폭주를 할 것이다. 그리고, 특정시간대에는 사용하고 있지 않은 서버들이 엄청나게 놀게 될 것이라는 점이다. 이제, 서버 개발자는 이러한 구조를 예측해야 하는 시대이다.

그런 환경에 대응하기 위해서 기존의 Monolithic Architecture는 MSA(Micro Service Architecture)로 변해왔다. 이 환경은 현재 보편화된 클라우드 서버와 너무도 잘 어울리도록 디자인된다.

기존의 Monolithic Architecture는 하나의 Tomcat위에 여러 개의 Web-Application들이 하나의 WAR의 형태로 묶여 올라가 있는 형태로 디자인되었었다. 그리고, 적당한 가용성을 가지도록 디자인되고, 일반적인 성능을 고려하여 적당한 HW리소스 위에서 동작된다.

서버 개발자는 최대 사용량을 고려한 Active-Active구조나, 보조적인 수단으로 Active-StenBy구조만 가지고 있으면 충분하게 서비스를 할 수 있었다.

하지만, '모바일'을 대상으로 하는 서비스는 그런 형태로 디자인하면, 엄청난 리소스를 투입하거나, 적당한 기능을 제공하는 형태로 동작되어야 한다. 물론, 이런 문제를 빠르게 대처하기 위해서 클라우드 환경으로 전환하고 적절한 방법으로 VM을 늘리면서 이러한 서비스를 감당하도록 시스템 관리자가 관리를 하는 방법을 사용할 수 있기도 하지만, 사실상 기하급수적으로 늘어나는 수백만, 수억 명의 사용자를 감당하기 위해서는 기존의 방법으로는 도저히 해결할 수 없다.

그래서, MSA(Micro Service Architecture)가 등장했다. 이 방식은 잘게 쪼개진 Tomcat안에 탑재된 웹 애플리케이션들이 적절한 VM위에서 배분될 수 있는 load balancer만 있으면, 무수히 많은 사용자들도 대부분 커버할 수 있는 환경으로 전환할 수 있도록 지원된다.

서버 개발자들은 가능한 작은 규모의 MSA들을 구성하기 시작하였고, AWS나 애저, 알리바바 클라우드 위에서 충분한 가용성을 획득하여 서비스를 진행할 수 있게 되었다.

하지만, 이 또한 MSA는 새로운 다음과 같은 문제점들을 도출하게 되었고, 서버 개발자들은 다음과 같은 새로운 고민거리들에 대해서 머리를 싸매기 시작했다.

그 첫 번째는 '성능'이슈이다.

MSA 기반으로 동작하는 VM의 가격이나 구성 등에 대해서 적절한 형태로 분배를 해야 하는 이슈이다. 도대체 어느 정도 규모와 어느 정도 환경으로 동작 환경을 구성해야 하며, 적절한 메모리와 CPU의 값의 '지수화'는 어느 정도 필요한 것인가?

또한, DB서버나 NoSQL로 동작되는 데이터 스토리지의 '성능'에 대한 적절한 '지수'와 '수치'를 어떻게 도출해야 하는 것인가이다.

또, 심각한 문제 두 번째는 '테스팅'이슈에 해당된다.

MSA는 분명, 클라우드 위에서 매우 원활한 가용성을 확보하게 해주지만, 서비스들이 물리적인 환경에서 잘게 쪼게 지게 되면서 '테스트'환경에서 모든 것을 커버할 수 있는 '통합 테스트'를 할 수 없게 되었다는 점이다.

또한, MSA는 매우 많은 API Service 체계를 만들게 되며, 복잡하고 중첩된 '웹 서비스 트랜잭션'으로 구성될 수밖에 없게 된다.

API 서비스가 SQL을 호출하고, 영향받은 환경에서 API를 다시 호출되는 순환구조를 탄생하게 하거나, 특정 시점에서 서비스가 적재되고, 리소스의 반환 시점이 틀어지게 되면 전체 서비스에 악영향을 줄 수 있는 환경에 대해서 충분하게 예측하여 '테스팅'을 할 수 없게 된다는 점이다.

이러한 '서비스 간 트랜잭션 처리'의 문제는 작은 서비스, 큰 서비스, 트랜잭션의 영역 범위에 대해서 매우 골치 아픈 범위까지 문제의 범위가 커지게 된다.

그리고, 세 번째 심각한 문제는 '팀의 거번넌스(govenance) 모델'이 중요한 화두로 떠오르게 된다.

매우 당연하게 DevOps환경에서 하루에 한 번 이상의 배포가 이루어지며, 한 명의 개발자가 여러 서비스에 영향을 주는 '서비스'를 실제 운영 중인 서비스에 배포되게 된다는 점이다. 누가 누구에게 승인을 받을 것이며, 관련된 의사결정 과정에서의 불협화음이나 문제들에 대해서는 과연 누가 일일이 해결해야 하는 것인지에 대해서 심각하게 고민하게 된다.

팀의 구조와 팀의 의사결정구조, 팀의 구성 형태에 대해서까지 MSA는 절대적인 영향을 주게 된다.

현재의 개발환경을 다음의 단어로 정리할 수 있다.

You Build, You run-DevOps

개발팀은 Sefl-organized team의 형태로 구성되고, 운영되지 않으면, 급속도로 변해가는 웹서비스를 감당할 수 없게 된다. 그래서, 스마트폰과 MSA, 클라우드 환경에서는 Availability, performance의 두 단어가 가장 중요한 화두로 떠오를 수밖에 없다.

매우 당연하게, DevOps와 Growth Hacking은 이러한 환경에서 추구해야 할 기본적인 목표가 된다?