[ Concept ] 스프링 클라우드

○ The Twelve-Factor App

    - SaaS(Softeare as a Service)

      1) 설정 자동화 절차를 체계화(Declarative)해 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용 최소화

      2) 운영체제에 따라 달라지는 부분을 명확히 하고, 실행 환경 사이의 이식성 극대화

      3) 최근 등장한 클라우드 플랫폼에 적합, 서버와 시스템의 관리 불필요  

      4) 개발 환경과 운영 환경의 차이를 최소화, 민첩성 극대화, 지속 배포 가능

      5) 툴, 아키텍처 및 개발 방식 크게 변경하지 않고 확장 가능(Scale Up)

    - Twelve-Factor App

      1) 코드베이스 : 애플리케이션당하나의 코드베이스만 존재

                               이를 CI/CD(Continuous Integration/Continuous Delivery) 통해 다양한 환경(개발, 테스트, 운영)에 배포 

      2) 종속성 : Maven과 같은종속성 관리 도구 사용

      3) 설정 : 설정과 코드를 명시적으로 분리해실행 환경에 맞는 설정으로 유연하게 변경 가능토록 함

      4) 벡엔드 서비스 : 네트워크 통해 사용하는 외부 서비스를 리소스로간주

                                    설정 시스템에 저장된 값을 읽어 해당 리소스에 접근

      5) 빌드, 릴리즈, 실행 : CI/CD 통해 빌드와 릴리즈 단계 분리

      6) 프로세스 : 애플리케이션을 하나 또를 여러 개의 무상태(stateless) 프로세스로 실행

      7) 포트 바인딩 : 앱은 독립적이어야 함, 실행 환경에 대한 런타임 인젝션에 비의존

                                 각 서비스는HTTP 환경으로 제공

                                 API를통해서만 접근

                                 데이터는 공유하지 않음

      8) 동시성 : 확장과 지원 사용량개선을 위해 각 서비스와 함수는 독립적이고 수평적으로 동작

      9) 폐기 가능 : 빠른 시작과그레이스풀 셧다운(Graceful shutdown)을통한 안정성 극대화

      10) 개발/프로덕션환경 일치 : 개발, 스테이징 프로덕션환경을 최대한 비슷하게 유지

      11) 로그 : 분산 시스템에서 로그를 관리하는 것이 중요함, 로그를 이벤트 스트림으로 취급

      12) Admin 프로제스 : admin/maintenance 작업을 일회성 프로세스로 실행

 

○ CNCF(Cloud Native Computin Foundation)

 

○ 스프링 클라우드

    - 분산/버전 설정(Spring Cloud Config)

      1) 애플리케이션 동작할 때 설정 파일 읽어서 처리하는 것이 일반적임

      2) 그러나 클라우드 환경에서 마이크로서비스를 지원하는 경우 환경 자체의 값들이 자유롭게 변경/처리 돼야 함

      3) 즉 중앙저장소에서 모든 설정값을 관리하고 개별 서비스는 설정값을 해당 저장소에 문의해 가져와야 함

      4) 스프링 클라우드 Config는 '외부화된 구성(Config)'에 대해 서버 및 클라이언트측 지원 제공

      5) 기본적으로 설정은 키-값(Key-Value) 쌍으로 되어 있음, 필요 시 암호화 가능

    - 서비스 등록 및 조회

      1) 클라우드 환경에서는 '어디에'가 실시간으로 변경되고 '어떻게'까지 자유롭게 바뀔 수 있음

      2) '어디에' : 서비스 등록 및 조회

      3) 각가의 서비스는 중앙저장소에 자신의 정보와 제공하는 '서비스의 이름' 등록

      4) 서비스 내에서 다른 서비스를 호출할 때는 이 서비스 이름으로 '어디에' 문의해야 할지 정보 가져와 호출

      5) 서비스 이름이 키가 되고, 호출 위치가 값이 됨

      6) Spring Cloud Neflix(Eureka), Spring Cloud Consul(Hashicorp's Consul),

          Spring Cloud Zookeeper(Apache Zookeeper)의 프로젝트에서 개별 솔루션과의 연동 지원

    - 라우팅

      1) 라우팅 : 특정 네트워크 내부에서 목적지를 찾아가는 과정

      2) API 게이트웨이 : 다양한 네트워크를 사용하는 모듈 사이에서 중계와 필요한 변환 및 추가 처리 작업하는 모듈

      3) 외부에 노출하는 포인트를 하나로 만들어 관리 편리, 인증 혹은 SLL 처리 담당해 게이트웨이 내부 모듈 간단히 생성

      4) 필터 추가 가능

    - 서비스 간 호출

      1) 일대일 호출 : 직접 서비스 주소를 찾아 호출하거나 클라이언트사이드 부하분산 솔루션인 리본(Ribbon)을 활용

      2) 일대다 호출 : 다시 설명할 분산 메시징 활용 가능

    - 부하 분산

      1) 클라우드 환경에서는 동일한 서비스를 처리하는 인스턴스 많을 수 있음

      2) 이 중에서 적합한 인스턴스로 호출하는 것, 부하를 분산시키는 것이 중요

    - 서킷 브레이커(Circuit Breakers)

      1) 동일한 서비스를 제공하는 여러 인스턴스 중 하나에서 장애가 발생할 경우 해당 인스턴스에

          계속 요청을 보내 타임아웃까지 기다리는 것은 전체 시스템에 부하를 주게 됨

      2) 따라서 장애가 발생한 인스턴스로 가는 요청을 '중단'시킬 필요가 있음

    - Global Locks, Leadership Election and Cluster State

      1) 클라우드 네이티브 환경에서 특정 리소스에 하나의 모듈만 접근해야 하는 경우 종종 발생함

      2) 글로벌 락 : 해당 리소스에 접근한 모듈이 잠금을 생성

                             이후 접근한 모듈이 잠금 상태라면 대기

                             잠금이 없다면 자신이 잠금을 잡는 방식

                             각각의 인스턴스가 개별로 동작하므로 이런 잠금은 하나의 시스템이 아닌 전체를 대상으로 관리

      3) 리더십 일렉션 : 전체 시스템에서 하나의 키를 이용해 잠금을 관리 가능하고

                                    리더 역시 특정 키를 조회해 값이 없으면 조회한 모듈이 자신으로 값을 설정

                                    값이 있으면 해당 모듈을 리더로 판단

    - 분산 메시징

      1) 메시지 큐(Message Queue) 이용하거나 게시 및 구독 모델 사용해 분산 메시징 지원 가능

      2) 컨슈머 크룹을 활용해 중복 처리를 방지

           파티셔닝 기능 활용 가