6_Architecture.md

6_Architecture

Architecture

시스템 아키텍처

• 소프트웨어 시스템의 구조와 구성 요소들 사이의 상호작용을 설계하는 과정
  • 기능, 성능, 확장성, 가용성, 유지보수성, 보안 등을 고려
• 예시
  • 단일 계층 아키텍처
    • 전체 시스템이 단일 계층으로 구성되는 구조
    • 간단한 애플리케이션에서 사용되며, 데이터베이스, 비즈니스 로직 및 사용자 인터페이스가 한 곳에 집중
  • 클라이언트-서버 아키텍처
    • 클라이언트는 사용자 인터페이스를 담당하고, 서버는 데이터 처리와 비즈니스 로직을 처리
    • 대규모 애플리케이션에서 주로 사용
  • 계층형 아키텍처
    • 시스템을 여러 개의 계층으로 분리하여 설계하는 구조
    • 각 계층은 특정한 역할을 수행
    • 상위 계층은 하위 계층에게 서비스를 제공
    • 일반적으로 데이터베이스 계층, 비즈니스 로직 계층, 사용자 인터페이스 계층 등으로 구성
  • 마이크로서비스 아키텍처
    • 애플리케이션을 여러 개의 작은 서비스로 분리하여 독립적으로 개발, 배포, 운영
    • 각 서비스는 특정한 비즈니스 기능을 수행하며, 서비스 간에는 API를 통해 통신
    • 확장성과 유연성이 요구되는 대규모 시스템에서 주로 사용

클라이언트-서버 아키텍처

• 특징
  • 클라이언트
    • 사용자가 애플리케이션과 상호작용하며 사용자 인터페이스를 제공
    • 서버에 데이터를 요청하고 응답을 받아와 사용자에게 보여줌
  • 서버
    • 클라이언트의 요청에 따라 데이터 처리, 비즈니스 로직 수행, 데이터베이스 액세스 등의 작업을 수행
    • 결과를 클라이언트에게 반환
• 예시
  • 웹 애플리케이션은 일반적인 클라이언트-서버 아키텍처의 예시
  • 웹 브라우저가 클라이언트 역할을 하고, 웹 서버가 서버 역할
    • 웹 브라우저는 사용자 인터페이스를 제공하고, 웹 서버는 클라이언트의 요청을 처리하여 필요한 데이터를 제공
  • 그 외에 모바일 애플리케이션, 게임 서버에서도 활용
• 단점
  • 네트워크 부하: 클라이언트 수가 많고 동시에 많은 요청이 발생하는 경우 서버의 부하가 증가
  • 단일 장애점: 서버가 중단되면 해당 서버와 연결된 클라이언트는 서비스에 접근할 수 없음. > 전체 시스템의 가용성이 저하될 수 있음
  • 확장성: 서버에 대한 확장성을 유지하기 위해서는 적절한 로드 밸런싱 및 서버 클러스터링 등의 방법이 필요
  • 버전 관리: 클라이언트와 서버 간의 인터페이스가 변경되면, 이를 관리하기 위해 클라이언트와 서버의 버전을 일치 > 호환성 문제가 발생할 수 있음

마이크로서비스 아키텍처

• 특징
  • 작은 서비스
    • 각 서비스는 특정한 비즈니스 기능을 수행하며, 개별적으로 독립적으로 배포되고 확장
    • 예를 들어, 사용자 관리, 상품 카탈로그, 주문 처리 등 각각의 기능을 수행하는 서비스로 분할 가능
  • 독립적인 배포와 확장
    • 각 서비스는 개별적으로 배포/업데이트 > 전체 애플리케이션을 다시 배포할 필요가 없음
  • 경계의 명확성
    • 각 서비스는 명확한 인터페이스(API)를 제공하고, 다른 서비스와의 통신은 네트워크를 통해 이루어짐
  • 분산 시스템
    • 각 서비스는 독립적인 데이터베이스 또는 데이터 저장소를 가질 수 있음
    • 서비스 간의 데이터 동기화와 일관성을 유지하기 위해 이벤트 드리븐 아키텍처나 메시지 브로커 등을 활용 가능
• 예시
  • 전자 상거래 애플리케이션
  • 사용자 관리, 상품 카탈로그, 주문 처리, 결제 등 다양한 기능을 포함 > 각각의 기능을 독립적인 서비스로 분할
    • 사용자 관리 서비스는 사용자 등록, 로그인, 프로필 관리 등을 담당
    • 상품 카탈로그 서비스는 상품 조회, 검색, 장바구니 관리 등을 담당
  • 각각의 데이터베이스를 가지고 있으며, 사용자 관리 서비스와 상품 카탈로그 서비스는 API를 통해 통신
• 단점
  • 복잡성: 서비스 간의 통신, 데이터 동기화, 분산 시스템 관리 등에 복잡성이 증가
  • 네트워크 부하: 여러 개의 서비스가 네트워크를 통해 통신하므로 네트워크 부하가 증가
  • 분산 데이터 관리: 각 서비스가 독립적인 데이터베이스를 가지고 있을 경우 데이터 일관성과 동기화를 관리
  • 운영 및 모니터링: 여러 개의 서비스로 구성된 시스템을 운영하고 모니터링하는 것은 복잡성

확장성과 가용성

• 확장성
  • 수평적 확장성
    • 시스템의 부하를 분산시키기 위해 여러 서버 인스턴스를 추가
    • 로드 밸런싱, 클러스터링, 컨테이너화 등의 기술을 활용
  • 수직적 확장성
    • 단일 서버의 성능을 향상
    • 서버 자원(메모리, CPU 등)을 추가하거나 업그레이드
• 가용성
  • 항상 사용 가능하고 중단 없이 작동
  • 여러 대의 서버를 사용하고 장애 복구 메커니즘(예: 장애 허용, 복제, 오류 처리)을 구현
  • 높은 가용성 아키텍처: 여러 가용 영역에 서버를 분산 배치하고, 자동화된 장애 복구 메커니즘을 구축
  • 모니터링 및 로깅, 자동화된 배포와 스케일링, 예방적인 관리와 유지보수, 백업과 복원

확장성과 가용성 확보 매커니즘

로드 밸런싱

• 여러 서버 인스턴스 사이에서 들어오는 트래픽을 분산시켜 서비스의 부하를 고르게 분담하는 메커니즘
  • 시스템의 처리량을 증가시키고 응답 시간을 최소화
  • 네트워크 장치를 사용하여 수행
• 이점
  • 부하 분산: 로드 밸런서는 트래픽을 여러 서버로 분산시켜 서비스의 부하를 고르게 분담
  • 고가용성: 로드 밸런서는 서버의 장애를 감지하고 이를 우회하여 트래픽을 안정적으로 처리
  • 확장성: 새로운 서버 인스턴스를 추가하여 시스템을 확장할 때 로드 밸런서를 사용하면 효율적으로 트래픽을 분산
• 알고리즘
  1. 라운드로빈 (Round Robin)
     • 가장 기본적으로 사용되는 알고리즘
     • 과정
       1. 서버 목록 준비: 이는 물리적인 서버의 IP 주소 또는 가상의 서버의 엔드포인트로 구성
       2. 현재 서버 인덱스 초기화: 로드 밸런서는 현재 처리할 서버의 인덱스를 추적하기 위해 변수를 초기화. 초기값은 보통 0.
       3. 요청 분배: 현재 서버 인덱스에 해당하는 서버로 요청을 전송 (예를 들어, 인덱스가 0이면 첫 번째 서버로 요청이 전달)
       4. 인덱스 업데이트: 이는 다음 요청을 위해 다음 서버로 이동하기 위한 작업. 인덱스는 순환적으로 업데이트되며, 마지막 서버에 도달하면 다시 처음 서버로 돌아감
     • 단점
       • 서버 부하 불균형: 각 서버의 처리능력이 다르거나 요청의 처리 시간이 다르면 서버 간 부하가 불균형하게 분산 (일부 서버에 많은 요청이 몰릴 수 있음)
       • 서버 상태 무시: 따라서 서버의 현재 부하나 가용성 상태를 고려하지 않으며, 모든 서버에 동일한 비중으로 요청이 분배
       • 트래픽 예측 어려움: 특정 시점에 트래픽이 급증하는 경우에도 미리 대비할 수 있는 기능이 없음
  2. 가중치 기반(Weighted Round Robin)
     • 서버에 가중치(Weight)를 할당하여, 가중치에 따라 요청을 분배
       • 가중치가 높은 서버가 먼저 선택되고, 순차적으로 가중치를 감소시키며 서버를 선택
       • 가중치가 높을수록 해당 서버에 더 많은 요청이 분배
     • 단점
       • 서버의 가중치를 부적절하게 설정하면 부하 분배가 원활하지 않을 수 있음
       • 서버의 상태 변화를 실시간으로 반영하지 않음
  3. 최소 연결 수(Least Connection)
     • 현재 연결 수가 가장 적은 서버에 요청을 분배하는 방식
     • 단점
       • 서버의 연결 수를 실시간으로 확인해야 하므로, 로드 밸런서에 부가적인 리소스
       • 서버의 연결 수만을 고려하기 때문에, 서버의 처리 능력이 동일한 경우에만 효과적으로 동작
         • 서버 능력 차이가 크다면 고려하기 어려움
  4. 최소 응답시간 (Least Response Time)
     • 서버 응답 시간이 가장 빠른 응답 시간에 요청을 분배
       • 성능이 우수한 서버에 더 많은 트래픽
     • 단점
       • 서버의 응답 시간을 정확하게 모니터링
       • 서버 간의 응답 시간 차이가 큰 경우 효과적
• 대규모 트래픽
  • 로드 밸런서의 확장: 로드 밸런서 자체를 확장하여 처리 능력을 향상. 이는 추가 로드 밸런서 노드를 도입하거나, 성능 강화를 위해 고성능 로드 밸런서로 교체하는 것을 포함
  • 애플리케이션 서버 확장: 로드 밸런서 앞에 있는 애플리케이션 서버를 확장하여 부하를 분산
  • 부하 분산 전략 조정: 로드 밸런서의 부하 분산 전략을 조정하여 특정 애플리케이션 서버에 대한 부하를 줄이고, 다른 서버로의 분산을 증가

캐싱

• 데이터나 계산 결과를 임시로 저장하여 빠르게 액세스할 수 있는 메모리 또는 저장소
  • 데이터베이스, 웹 서버, 애플리케이션 등에서 사용
  • 부하 분산: 많은 요청이 동일한 데이터에 대한 액세스를 요구할 때, 캐시는 원본 시스템의 부하를 줄여줌으로써 시스템 성능을 향상
• 예시
  • 웹 캐싱: 웹 페이지의 정적 리소스(이미지, CSS, JavaScript 등)를 클라이언트의 브라우저에 저장하여 동일한 웹 페이지에 대한 재액세스 시 웹 서버로의 요청을 줄임
  • 데이터베이스 캐싱: 데이터베이스에서 빈번하게 조회되는 데이터나 쿼리 결과를 메모리에 저장하여 데이터베이스 액세스 시간을 단축
• 단점
  • 일관성 유지: 캐싱은 데이터의 중복 저장이 발생할 수 있으므로, 동기화를 통한데이터의 일관성을 유지 필요
  • 메모리 사용: 캐시 용량을 적절히 조절해야 하며, 대용량 데이터의 경우 적절한 캐시 전략을 선택
  • 캐시 오버헤드: 캐시를 사용하면 캐시 관리와 갱신에 대한 오버헤드가 발생
• CDN (Content Delivery Network)
  • 전 세계에 분산된 서버 네트워크를 통해 콘텐츠를 빠르고 안정적으로 전달하는 기술
  • 주로 정적인 콘텐츠(이미지, 동영상, 문서 등)를 처리
  • 방식
    • 가까운 엣지 서버에서 콘텐츠를 제공하므로 지연 시간이 감소하고 대역폭 사용량이 줄어듬
    • 콘텐츠의 변경 여부를 확인하여 업데이트된 콘텐츠만 캐싱하고, 캐시된 콘텐츠의 유효기간을 관리하여 적절한 시점에 갱신
  • Cloudflare, Akamai, Fastly, Amazon CloudFront 등에서 제공

Proxy

• 클라이언트와 서버 간의 통신을 중계하는 서버
  • 클라이언트가 서버에 직접 요청을 보내는 대신 프록시 서버를 통해 요청하고, 프록시 서버는 해당 요청을 대신 수행하여 결과를 클라이언트에게 전달
• 용도
  • 익명성 보장: 클라이언트의 신원을 숨김으로써 개인 정보 보호와 익명성 유지를 위해 활용
  • 캐싱: 클라이언트의 요청에 대한 응답을 캐싱하여 동일한 요청에 대한 반복적인 트래픽을 줄일 수 있음
  • 보안 강화: 방화벽 기능을 제공. 악성 코드, 악의적인 트래픽, 보안 위협 등을 탐지하고 차단
  • 로드 밸런싱: 프록시 서버는 여러 대의 서버에 요청을 분산시켜 로드 밸런싱을 수행
• 예시

오토스케일링

• 클라우드 환경에서 자동으로 컴퓨팅 리소스를 확장하거나 축소하는 기능
  • AWS(Amazon Web Services), Azure, Google Cloud Platform 등은 오토 스케일링을 지원하는 기능을 제공
• 원리
  • 모니터링: 애플리케이션 또는 시스템의 상태를 모니터링하고, 트래픽, CPU 사용률, 메모리 사용률 등의 지표를 수집
  • 트리거 설정: 모니터링된 지표를 기반으로 자동 확장 및 축소를 트리거할 임계값을 설정 (예. CPU 80% 초과)
  • 리소스 확장: 설정된 트리거에 따라 필요한 경우 새로운 서버 인스턴스를 자동으로 생성하여 리소스를 확장
  • 리소스 축소: 트래픽이 감소하거나 부하가 낮아질 경우, 설정된 트리거에 따라 더 이상 필요하지 않은 서버 인스턴스를 자동으로 종료하고 리소스를 축소
• 장점
  • 자원 활용 최적화: 필요한 시점에 자원을 동적으로 확장하고 축소하여, 실시간으로 변하는 트래픽에 대응하여 자원을 효율적으로 활용
  • 가용성 향상: 장애 발생 시 자동으로 대체 인스턴스를 생성하여 서비스의 중단 시간을 최소화
  • 비용 절감: 트래픽이 적을 때는 자동으로 리소스를 축소하여 비용을 절감
• 단점
  • 복잡성: 오토 스케일링을 구성하고 관리하기 위해서는 트리거 설정, 리소스 프로비저닝, 로깅 및 모니터링 등 다양한 작업이 필요
  • 지연 시간: 트래픽이 급격하게 증가할 경우, 리소스가 즉시 확장되지 않고 일정 시간 동안 대기
  • 예상치 못한 비용: 정확한 예측 없이 사용하면 예상치 못한 비용이 발생할 수 있음

비동기 처리

• 작업을 순차적으로 실행하는 대신, 작업이 완료될 때까지 기다리지 않고 다른 작업을 동시에 처리하는 방식
• 예시
  • I/O 작업이 포함된 작업: 네트워크 요청, 데이터베이스 조회, 파일 입출력 등의 I/O 작업은 상대적으로 오랜 시간이 걸리는 작업을 병렬적으로 실행하여 전체적인 처리 시간을 단축
  • 대규모 동시성 처리: 비동기 처리를 통해 동시성을 높여 동시 다발적인 요청에 효율적으로 응답
  • 이벤트 기반 시스템: 이벤트 기반 시스템은 외부 이벤트(사용자 입력, 센서 데이터 등)가 발생하면 해당 작업을 비동기로 처리하여 시스템의 반응성을 높일 수 있음
• 메시지큐나 이벤트 버스
  • 메시지 큐를 통해 비동기 작업을 메시지로 전달하고, 이벤트 버스를 통해 이벤트를 발행하고 구독하는 방식으로 비동기 처리를 구현
    • RabbitMQ, Apache Kafka 등의 메시지 큐, EventBus, RxJava 등의 이벤트 버스
• 위치
  • 메시지큐 > 로드 밸런서
    • 비동기적인 처리: 메시지 큐를 통해 요청을 비동기적으로 처리할 수 있어서 클라이언트는 즉시 응답않아도 됨
    • 유연성과 확장성: 메시지 큐를 사용하여 요청을 처리하면 애플리케이션 서버의 부하를 분산
    • 처리 순서 주의: 메시지 큐를 통해 비동기적으로 처리되는 경우, 요청의 처리 순서가 보장되지 않을 수 있음
  • 로드 밸런서 > 메시지큐
    • 실시간 처리: 클라이언트의 요청을 먼저 처리한 후 필요한 결과를 메시지 큐에 전송할 수 있음. 이는 실시간 처리가 필요한 상황에서 유용하며, 애플리케이션의 응답 속도를 향상
    • 복잡성: 로드 밸런서와 메시지 큐를 함께 사용하면 시스템의 구성이 복잡. 이에 따라 설정, 관리, 디버깅 등의 작업이 복잡해질 수 있습니다.

데이터베이스 분산

• 데이터베이스 시스템을 여러 개의 노드로 구성하여 데이터를 분산 저장하고 처리하는 방식
  • 노드 장애 발생 시에 다른 노드로 작업을 이전 > 안정성, 가용성 데이터의 안정성, 가용성, 확장성 등을 개선
• 구조
  1. 논리적인 구조
     • 여러 개의 노드에 데이터를 어떻게 분산
     • 데이터의 일관성과 격리 수준을 어떻게 유지할 것인지 등을 정의
     • 샤딩(Sharding), 복제(Replication), 파티셔닝(Partitioning) 등
       • 샤딩
         • 데이터를 수평적으로 분할하여 여러 개의 논리적인 샤드(shard)로 분산 저장 (1100 > 샤드1, 101200 > 샤드2)
         • 수평적 확장성을 제공하여 대용량 데이터 처리가 가능
         • 샤드 경계를 넘어갈 경우 조인이 필요하고 성능이 저하
         • 기준을 변경하는 경우 추가 작업 필요
       • 복제
         • 데이터를 여러 개의 노드에 복제하여 저장하는 방식
       • 파티셔닝
         • 여러 개의 논리적인 파티션(partition)으로 분할하여 저장 (날짜 기준으로 분류)
         • 데이터를 빠르게 검색하고, 필요한 데이터만 처리하는 것에 유리
         • 조인 작업이 필요한 쿼리의 성능이 저하
         • 파티션 단위의 장애 발생 시 해당 파티션의 데이터에 접근할 수 없음
  2. 물리적인 구조
     • 노드 간의 네트워크 연결과 데이터의 저장 위치 등을 정의하는 개념
     • 여러 개의 노드가 네트워크를 통해 연결되어 클러스터를 형성하고, 데이터가 분산 저장되는 방식을 결정
     • 마스터-슬레이브 구조, 분산 데이터베이스 클러스터 등
       • 마스터-슬레이브(Master-Slave) 구조
         • 마스터 노드는 쓰기 작업을 처리하고 데이터를 변경하며, 슬레이브 노드들은 마스터 노드의 데이터를 복제하여 읽기 작업을 처리
         • 마스터 노드에 장애가 발생하더라도 슬레이브 노드가 마스터 역할을 대체할 수 있어 시스템의 가용성을 향상
         • 단점
           • 쓰기가 마스터에 집중되어서 쓰기 성능이 제한
           • 마스터 노드 장애 시간동안 데이터 일관성이 유지되지 않을 수 있음
       • 분산 데이터베이스 클러스터(Distributed Database Cluster)
         • 각 노드는 데이터를 독립적으로 저장하고 처리할 수 있으며, 클러스터 전체에서 데이터의 일관성과 가용성을 유지
         • 병렬 처리를 통해 데이터베이스 작업의 처리량과 성능을 향상
         • 노드 간에 데이터를 복제하거나 분산된 데이터를 조합하여 처리할 수 있어 가용성과 신뢰성을 보장
         • 단점
           • 동기화 및 복제 매커니즘 구현에서 복잡성이 높음
           • 장애 복구가 복잡함
• 단점
  • 설계와 운영에 복잡성
  • 일관성과 격리 수준을 유지하기 위해 추가적인 동기화와 트랜잭션 관리가 필요

대용량 데이터 처리

• 많은 양의 데이터를 효율적으로 저장, 검색, 분석하고 처리하는 것을 의미
• 방안
  • 분산 데이터베이스
    • 대용량 데이터를 여러 노드에 분산하여 저장하고 처리
    • 샤딩, 복제 또는 파티셔닝 등의 방법으로 분산
  • 병렬 처리
    • 여러 개의 병렬 작업으로 분할하고 동시에 실행
    • 분산 컴퓨팅 프레임워크나 병렬 처리 알고리즘을 사용
  • 인덱싱과 색인화
    • 대용량 데이터에서 효율적인 데이터 검색을 위해 인덱싱과 색인화 기술을 활용
  • 데이터 압축과 압축 해제
    • 압축을 통해 데이터의 용량을 줄이고 저장 공간을 절약하며, 데이터 전송 시 대역폭을 절약
  • 배치 처리
    • 데이터를 일정한 단위로 나누어 처리하고, 병렬로 처리하거나 분산 환경에서 실행하여 처리 속도를 향상
    • 스케줄링하고 모니터링하기 위해 배치 처리 프레임워크나 도구를 사용
  • 데이터 파이프라인
    • 데이터 수집, 변환, 저장, 분석 등의 작업을 연결하여 데이터 처리 과정을 자동화하고 최적화

클라우드 서비스 유형

Infrastructure as a Service, IaaS

• 가장 기본적인 클라우드 서비스 유형으로, 가상화된 컴퓨팅 리소스를 제공
  • 가상 머신, 스토리지, 네트워킹 등의 인프라 리소스를 필요에 따라 프로비저닝하고 관리
  • 예. Amazon Web Services (AWS)의 EC2, Microsoft Azure의 Virtual Machines 등
• 사용자는 인프라 관리에 대한 부담을 줄이고, 필요한 리소스를 유연하게 프로비저닝 가능

Platform as a Service, PaaS

• 개발자가 애플리케이션을 개발, 테스트 및 배포하기 위한 플랫폼 환경
  • 애플리케이션 개발에 필요한 운영체제, 미들웨어, 데이터베이스 등의 환경을 선택
  • 인프라 관리에 대한 부담을 줄여 개발에 집중
  • 예. Google Cloud Platform의 App Engine, Heroku, Microsoft Azure의 App Service 등
• 개발자는 인프라 관리에 대한 부담을 덜고, 애플리케이션 개발에 집중 가능

Software as a Service, SaaS

• 최종 사용자에게 웹 브라우저나 모바일 앱을 통해 애플리케이션을 제공하는 서비스 형태
  • 애플리케이션을 설치하거나 관리할 필요 없이 인터넷을 통해 서비스를 이용
  • 예. Google Workspace, Salesforce, Dropbox, Microsoft 365 등