클라우드 서비스의 '기술부채' 다루기

클라우드 서비스를 개발하다 보면, 수평적 확장성(horizental scaleability)과 단일 장애지점(Single Point Of Failure) 없애기 위해 비용(시간과 노력)이 발생하는 경우가 종종 있습니다.

Scale up해서 돈으로 해결하거나, 일단 쉽게 구현하고 뒤로 미루게 됩니다. 이것이 기술부채로 차곡 차곡 쌓입니다. 늦지 않게 이 부채를 해결해야 파산하지 않을 텐데…

IoT 클라우드 플랫폼을 만든 경험이 있습니다. 동시 접속 디바이스 숫자 기준으로 기술부채를 해결해 나갔습니다. 요구사항에대해서 디바이스 수 기준의 태그를 붙여서 그 시점전에는 심적 부담없이 과감히 무시했었습니다.

  • 1만대 태그

    • redis sentinel, app service active/stand by
  • 10만대 태그

    • mongo sharding, app clustering
    • job queue
  • 100만대 태그

    • redis clustering

Gitple 서비스는 아주 초기라서 부채 좀 남겨 두고 있지만, 앞으로 동시 접속 상담 고객 수와 상담사 수 기준으로 부채를 갚아갈 예정입니다.

공유하기