대용량 아키텍처와 성능 튜닝: 레퍼런스 아키텍처 1

jiffydev·2021년 8월 18일
0

레퍼런스 아키텍처는 아키텍처 설계 시 참고할 수 있는 아키텍처를 뜻한다.

1. SOA

SOA(Service Oriented Architecture)는 현대 서버 아키텍처에 큰 영향을 준 아키텍처이다.

기본 개념

SOA에서 중요한 요소는 서비스와 이 서비스를 조합하여 기능을 구현하는 것이다.
이를 통해 기존에는 각각의 독립된 업무 시스템이었던 것들이 하나의 SOA 시스템으로 구성될 수 있다.

이는 '소프트웨어의 재사용'이라는 관점에서는 전부터 존재하는 개념이었지만 이를 위한 관련 기술의 난이도가 낮아지고 난 후에야 널리 적용될 수 있었다.

SOA에서 서비스의 정의

서비스를 정의할 때 가장 큰 특징은 '기업의 업무를 표현한다'는 점이다.

  • 서비스의 구성
    크게 3가지로 구성된다.

    • 서비스 인터페이스
      서비스 내 하나의 업무 기능
    • 서비스 규약
      서비스를 사용하기 위한 규약을 정의
    • 서비스 구현체
      규약에 대한 실제 구현체
  • 서비스의 특성

    • 수직적 분할을 통해 각 서비스를 독립적으로 개발할 수 있고, 서비스간 의존성을 줄일 수 있다.
    • 인터페이스는 표준 기술로 구현되어야 하며, 서비스는 시스템 내에서 기술에 종속되지 않아야 한다.
    • 각 서비스 컴포넌트는 느슨하게 결합되어 있으므로, 한 서비스의 구현 내용이 변경되더라도 다른 서비스에 영향을 주지 않는다.
    • 서비스 컴포넌트간에 조합을 통해 애플리케이션을 구성한다.
    • 서비스의 구성 단위는 업무 단위로, 개발 조직이 아니더라도 서비스의 기능을 이해할 수 있어야 한다.
    • 시스템의 규모가 증가하더라도 기능이 중복되지 않도록 검색이 가능해야 한다.
  • 서비스의 종류

    • 비즈니스 서비스는 비즈니스 로직과 비즈니스 데이터로 구성
    • 중재 서비스는 서비스간 연결 시 발생하는 차이점 보완
    • 프로세스 지향 서비스는 비즈니스 서비스를 조합하여 하나의 업무 프로세스를 구현
    • 애플리케이션 서비스는 기술적인 서비스
    • 퍼블릭 엔터프라이즈 서비스는 외부 SOA 시스템으로 제공되는 서비스
  • SOA 아키텍처 모델

    • Fundamental SOA
      가장 기본적인 형태. 목적은 기존의 시스템을 각각 서비스화하는 것과 독립된 시스템을 통합하여 운영하는 것.

    • Networked SOA
      시스템이 커지면서 의존성으로 인해 서비스간 수정이 필요하게 되는데, 이로 인한 경직성을 해결하기 위해 중앙 버스(Enterprise Service Bus, ESB)에서 서비스간 연결 복잡도를 해결하고, 중재 서비스를 통해 서비스 변경 시 차이를 보완.

    • Process Oriented SOA
      복잡한 업무 프로세스를 BPM(Business Process Management)기반으로 SOA를 구현하여 서비스를 조합함으로써 코딩 없이도 업무 프로세스를 조정.
      추가적으로 BPA(Business Process Analysis), BAM(Business Activity Monitoring) 통해 분석/모니터링하여 SOA 시스템을 최적화한다.

  • SOA 아키텍처 모델의 구현
    위 모델을 구현함에 있어 고려해야 할 사항은 다음과 같다.

    • 서비스화
      기존 시스템을 서비스화할 때, 레거시 시스템에 대한 웹서비스를 제공하는 서비스 어댑터를 사용한다.
      다만 서비스화를 하기 전에 기존 시스템의 기능을 업무 단위의 큰 단위 컴포넌트로 묶은 후 서비스화한다.
    • 스펙과 범위
      웹 서비스 스펙 중 트랜잭션이나 Reliable Messaging의 경우 서비스 어댑터를 통한 서비스화 시 지원되지 않을 수도 있다. 따라서 서비스를 정의할 때 이런 기능들을 어떻게 구현할지 먼저 고려해야 한다.
    • 보안
      암호화 시 전체를 암호화할지, 일부만 암호화할지 결정.
    • 모니터링
      각 서비스에 대한 모니터링과 성능 측정 기능을 미리 구현
    • 서비스 검색
      이미 개발된 서비스를 재사용하기 위해 서비스를 검색할 수 있어야 하며, 서비스의 메타정보도 검색할 수 있어야 한다.
    • 애플리케이션 프론트엔드
      최종 사용자에게 업무 기능을 제공하는 부분.
  • SOA 수행 방법론
    SOA 시스템을 수행하는 방법은 여러가지가 있다.

    • 기업 전략
      기업의 경영 전략에 따라 기업의 핵심 업무를 SOA화하게 된다.
    • 비용 집행
      기존 IT 시스템과 다르게 SOA는 초기 인프라 구축에는 비용이 많이 들지만, 그 후로는 기존 서비스를 다시 사용하기 때문에 개발 비용이 지속적으로 감소하게 된다.
    • 제어와 통제
      SOA 시스템이 확장될수록 중앙 관리 및 통제 제어가 필요해진다.
      이를 수행하는 조직을 거버넌스라 하며, IT 조직과 비즈니스 조직 간의 중계 역할을 하게 된다.
    • 프로젝트 관리
      SOA 프로젝트는 반복, 점진적인 개발을 통해 진행된다.

2. 마이크로 서비스 아키텍처(MSA)

MSA는 최근의 대규모 분산 웹 시스템의 아키텍처 스타일로 주목받고 있다.
하지만 MSA에 대해 알아보기 전에 이와 대비되는 모노리틱 아키텍처에 대해 먼저 살펴보자.

모노리틱 아키텍처


모노리틱 아키텍처는 전통적인 웹 시스템 개발 스타일로, 한 애플리케이션 내에 모든 로직이 들어있는 구조이다.
전체 애플리케이션을 하나로 처리하기 때문에 개발/배포/테스트가 간편하다는 장점이 있다.

하지만 애플리케이션의 규모가 커질수록 빌드, 배포시간이 오래 걸리는 것은 물론, 구조가 복잡해지면서 이를 모두 이해하는 사람이 줄어들고, 이로 인해 협업도 쉽지 않다.

MSA

MSA는 대용량 웹 서비스가 늘어나면서 필요성이 대두된 아키텍처로, SOA에 근간을 두고 있다.

  • 서비스
    MSA에서는 각 컴포넌트를 서비스로 정의하고, 그 안에 데이터부터 비즈니스 로직까지 독립적인 구조로 기능을 제공한다.
    서비스의 경계는 구문 또는 도메인의 경계를 따르며, 각 서비스를 섞어서 정의하지 않는다.

  • 구조
    독립적인 서비스(컴포넌트)가 API를 통해 타 서비스와 통신한다.

  • 데이터 분리
    서비스별로 독립적인 데이터베이스를 사용하는데, 다른 컴포넌트와 API 통신을 통해 데이터를 가져와야 한다는 특성상 성능상 문제가 발생할 수 있다.

  • API Gateway

    API Gateway는 프록시 서버처럼 API 앞단에서 모든 API를 통합하는 미들웨어이다.
    MSA에서 수행하는 주요 기능으로는 다음과 같은 것들이 있다.

    • 엔드포인트 통합 및 토폴로지 정리
      MSA에서는 각 서비스가 다른 서버에 분리/배포되기 때문에 API 주소가 모두 다르다.
      이로 인해 컴포넌트간 호출 구조가 복잡해지게 되는데, 이를 해결하기 위해 API Gateway가 서비스 버스처럼 기능하여 호출 구조를 단순화시킬 수 있다.
    • 오케스트레이션
      오케스트레이션은 여러 개의 서비스를 묶어서 새로운 서비스를 만드는 개념이다.
      API Gateway에서도 이런 기능을 구현할 수 있는데, 대신 성능상의 부담이 있으므로 MSA에 대한 이해와 API Gateway자체에 대한 기술 이해도가 높아야 제대로 구현할 수 있다.
    • 공통 기능 처리
      인증이나 로깅처럼 공통적으로 사용하는 기능을, API Gateway를 통해 중복 구현을 방지할 수 있다.
    • 중재
      API Gateway에서 메시지 변환이나 프로토콜 변환, 메시지 라우팅과 같은 중재 기능을 사용할 수 있지만, 최대한 API Gateway를 가볍게 가져간다는 설계 원칙하에, 이러한 중재 기능은 심사숙고가 필요하다.
  • 배포
    각 서비스가 물리적으로 완벽하게 분리되기 때문에 변경이 발생해도 변경된 부분만 배포하면 돼서 빠르게 배포할 수 있다.

  • 확장성
    특정 서비스에 부하가 커질 경우, 그 서비스에 대해서만 확장하면 되므로 유연하게 확장이 가능하다.

MSA의 문제점

MSA라고 해서 완벽한 것은 아니다.

  • 성능
    MSA는 서비스 간 호출을 API 통신을 이용하기 때문에 그만큼 추가로 시간이 소요된다.

  • 메모리
    각 서비스가 독립된 서버에 배치되기 때문에 중복되는 모듈이 존재하고, 이로 인해 메모리 사용량이 늘어난다.
    다만 이 문제는 인프라가 향상되면서 크게 문제가 되지는 않게 되었다.

  • 테스팅의 어려움
    특정 사용자 시나리오나 기능을 테스트 하려면 여러 서비스에 걸쳐서 테스트를 진행해야 하기 때문에 테스트 환경 구축이 어렵고, 테스팅 복잡도도 올라간다.

  • 운영 관점의 문제
    서비스별로 다른 기술을 사용할 수 있고, 시스템이 서비스 단위로 쪼개지기 때문에 운영해야 할 시스템의 개수가 늘어난다.

  • 서비스 간 트랜잭션 처리
    모노리틱 아키텍처에서는 트랜잭션에 문제가 있더라도 쉽게 롤백이 가능하다.
    하지만 MSA에서는 롤백이 어렵기 때문에, 기본적으로 트랜잭션 보장이 중요한 비즈니스라면 모노리틱 아키텍처로 접근하는 것이 좋다.

거버넌스 모델

거버넌스는 시스템을 개발하는 조직의 구조나 프로세스를 정의한 것이다.
전통적인 중앙집중형 거버넌스 모델은 나날이 급변하는 기술의 발전을 민첩하게 따라잡기 어렵기에,
현대 웹 개발에서는 각 팀에 독립적인 프로세스와 기술 선택 권한을 부여하는 분산형 거버넌스 모델이 주가 되고 있다.
분산형 거버넌스 모델을 수행할 경우 이에 맞는 팀 구조가 필요하다.

  • Cross Functional Team
    기존의 역할별 팀(개발팀, 디자인팀 등)은 팀 간 커뮤니케이션에 시간이 걸려서 운영 속도가 떨어지게 된다.
    이를 대체하는 Cross Functional Team은, 각 서비스별로 개발에 필요한 모든 역할을 하는 팀을 구성함으로써 기획 단계에서부터 설계, 개발, 운영이 가능해진다.

  • DevOps
    개발(Development)과 운영(Operation)을 하나의 조직에 합친 것으로, 피드백을 빠르게 수용하여 서비스 개선에 반영할 수 있는 모델이다.
    다만 충분히 준비가 되지 않은 상태에서 도입하면 운영상 장애를 유발하므로 팀의 성숙도에 좌우된다.

  • Project vs Product
    분산형 거버넌스 모델에서는 팀마다 다른 프로세스로 개발하기 때문에 팀의 연속성이 중요하다.
    따라서 프로젝트가 끝나면 해산하게 되면 프로젝트 중심의 팀보다, 요구사항 분석부터 개발, 운영까지 상품에 대해 책임을 지게 되는 상품 중심의 팀을 구성해야 한다.

  • Alignment
    분산형 거버넌스 모델의 팀은 각자가 독립적인 기능을 수행하지만 개발하는 서비스는 상호 의존적이다.
    따라서 팀의 개발 속도를 맞추기 위해 Alignment를 통해 팀의 능력을 균형있게 맞춰야 한다.

3. DevOps

전통적인 개발과 운영의 관계는 칼같이 나누어져 있었다.
개발에서 시스템 개발을 끝내면 시스템은 운영팀으로 넘어가, 그 이후로는 개발팀이 손댈 일은 없었다.
하지만 이와 같은 체계로 인해 문제가 발생하게 되었다.

문제 1. 책임 전가

시스템을 운영하다 보면 장애는 반드시 발생하게 되어 있는데, 개발팀은 애플리케이션에 대해서는 잘 알지만 그 밑의 인프라는 잘 모르고 운영팀은 그 반대이다.
따라서 장애가 발생해도 서로 자기 분야가 아니라며 떠넘기게 되고,
이로 인해 해결에 시간이 걸리게 된다.

문제 2. 운영 이슈 전달

개발팀은 개발이 끝나면 서비스에 대해서는 관심을 두지 않는다.
운영팀에서는 항상 고객의 요구사항을 듣게 되고, 이를 개선하려 하지만 운영팀이
요구사항을 정의할 권한을 가지고 있지 않아 정식으로 요청할 수 없다.
개발팀에게는 이런 요구 사항이 추가적인 일이 되므로 최대한 거부하고자 한다.

문제 3. 변경사항 배포

요즘의 서비스들은 요구사항에 최대한 빠르게 대응하기 위해 잦은 배포가 필수적이다.
하지만 많은 변경으로 인해 잦은 장애가 발생하고, 운영팀은 애플리케이션에 장애가 발생해도 긴급 배포가 어려운 경우가 많아 이를 꺼리게 된다.


이러한 문제들을 해결하기 위해 나온 것이 개발과 운영을 합쳐버리는 DevOps이다.
DevOps의 개념은 전부터 있었지만 개발과 운영간의 기술장벽이 컸기에 실천하기는 어려웠다.
하지만 오픈소스 도구들도 많이 나왔고, 특히 클라우드 컴퓨팅이 등장하면서 인프라를 구성하기가 전보다 훨씬 쉬워진 덕분에 운영을 겸할 수 있는 환경이 조성될 수 있었다.

일견 DevOps를 개발과 운영 모두 가능한 '사람'으로 생각할 수 있지만,
DevOps는 사실 하나의 '문화'라고 할 수 있다.
DevOps가 하나의 방법을 제시할 수 있지만 결국 이를 수행하기 위한 방법은 팀에서 정의해야 한다.

DevOps의 특징

  • Cross Functional Team
    하나의 팀에 각각 다른 역할을 할 수 있는 팀원을 배치하고, 그 팀에서는 서비스의 기획, 운영, 영업까지 맡을 수 있도록 한다.

  • Widely Shared Metric
    팀 전체가 기준으로 삼을 수 있는, 서비스에 대한 공통 지표를 찾는다.
    이를 통해 팀 전체가 서비스 상태를 인지하고 협업을 통해 개선 작업을 진행할 수 있게 된다.

  • Automating Repetitive Tasks
    CI/CD를 이용해 반복적인 빌드, 배포, 테스트 작업을 자동화한다.

  • Post-mortem
    장애나 이슈가 있으면 처리 후 그 내용을 팀에 공유한다.
    이를 통해 발생한 문제의 심각성을 이해하고 궁극적인 원인을 파악함으로써 같은 실수를 반복하지 않도록 한다.

  • Regular Release
    정기적인 릴리스를 통해 언제 어떻게 협업할지를 명확하게 한다.
    또한 짧은 주기의 릴리스를 통해 빠르게 서비스 기능을 개선하고 고객의 요구사항도 반영할 수 있다.

DevOps 기반의 개발팀


세부적인 것은 다를 수 있지만 기본적인 구조는 위와 같다.

Program Manager는 전체 서비스 기획, 이해관계자와의 커뮤니케이션 등 프로젝트 전반을 담당한다.
Product Manager는 서비스 기획과 요구사항 정의 및 그에 따른 우선순위를 결정한다.
UX는 Product Manager와 함께 서비스의 UX디자인을 정의하고 개선한다.
Scrum Master는 일정관리, 개발 리소스 관리 등을 담당한다.
User Researcher는 Product Manager와 비슷하지만 한발 먼저 제품이 나아갈 방향을 정하고, 비즈니스 관점에서 서비스를 바라본다.

DevOps 기반 개발 사이클


DevOps는 결국 한 팀 내에서 개발, 테스트, 배포, 운영이 모두 이루어지는 것이고,
위와 같은 사이클이 빠르게, 연속적으로 연결되어 있다.

필요 역량

DevOps 팀의 개발자가 되려면 다음과 같은 역량을 기본적으로 가지고 있어야 한다.

  • 코딩 능력
    당연하지만 개발이 기본이기 때문에 코딩 능력은 필수이다.

  • 협업, 의사소통 능력
    DevOps 자체가 팀 내에서의 협업이 반드시 필요하다. 또한 개발과 운영간의 소통문제를 해결하기 위해 나타난 것이기 때문에 의사소통 능력도 중요하다.

  • 프로세스를 이해하고 재정의할 수 있는 능력
    DevOps는 정해진 것이 없다고는 했지만 테스트, 배포, 요구사항 정의는 모두 프로세스이므로
    해당 팀에 맞게 만들어 나가야 한다.

주의점

  • DevOps팀을 새로 만들지는 말 것
    DevOps는 개발과 운영을 합침으로써 커뮤니케이션 부담을 줄이는 것이 목표이다. 팀을 새로 만들게 되면 그만큼 부담은 더 커진다.

  • DevOps 엔지니어를 채용하지 말 것
    DevOps는 문화이다. DevOps 엔지니어를 채용한다는 것은 문화를 돈으로 산다는 것인데
    그렇게 한다고 팀 내에 문화가 정착될 가능성은 희박하다.
    따라서 조직 전체가 공감하는 형태로, 능동적으로 임해야 DevOps를 도입할 수 있다.

  • 개발자가 개발&운영? 별도의 운영자?
    둘 다 할 수 있는 사람은 많지 않고, 개인의 선호도 있다.
    결국 역할을 나누되 협업할 수 있도록 환경을 조성하는 것이 무엇보다 중요하다.

  • DevOps는 소규모 조직에 유리
    소규모 스타트업의 경우, 사람이 없어 의도치 않게 엔지니어가 개발과 운영을 동시에 수행하게 된다.
    자연스럽게 DevOps팀이 구성될 수 있다.
    하지만 큰 조직의 경우 문화를 바꿔야 하기 때문에 그만큼 인내심이 필요하고 장기적인 시선으로 볼 필요가 있다.

profile
잘 & 열심히 살고싶은 개발자

0개의 댓글