우주의 IT 소행성

5장, 컨테이너, 쿠버네티스, 서버리스

Key Point / 도커  & 쿠버네티스

- 도커(Docker)에서 설명하는 컨테이너에 대한 설명은 다음과 같다

컨테이너란 코드와 모든 의존 관계를 패키지화한 소프트웨어의 표준적 단위로, 애플리케이션이 실행되는 기존 컴퓨팅 환경은 물론 다른 컴퓨팅 환경에서도 신속하고 확실하게 실행되게 해준다.

- 즉 컨테이너랑 의존 관계를 포함하는 '패키지'의 일종으로, 다양한 OS에서 실행할 수 있게 해주는 것이다.

- 환경에 의존하지 않고 안정적으로 실행할 수 있고, 하나의 서버 리소스를 효율적으로 사용하며, 컨테이너 구성 파일을 배포 작업의 일부로 사용할 수 있다는 큰 장점이 존재한다.

- 리눅스 네임스페이스 (Linux Namespace) : 프로세스 간에 전역 시스템 리소스를 분리하는 커널의 기능, 시스템 리소스를 각각의 네임스페이스로 나누는 역할을 한다.

- 컨테이너 이미지 : 애플리케이션을 실행할 때 필요한 모든 것이 담긴 소프트웨어 패키지. 하지만 일반적인 패키지처럼 하나의 바이너리 파일로 존재하는 것이 아니다.

- 도커 이미지는 여러 개 읽기 전용 레이어로 구성되며, 개발 레이어는 재사용할 수 있다. 이미지 레이어와 스토리지 드라이버(overlay2 권장)로 실제 수정 작업과 레이어 관리가 진행된다.

- 도커 이미지는 Dockerfile 내에 이미지 작성 순서를 기록하는 것이 일반적

- 유니온 파일 시스템 (Union File System, UnionFS) : 다른 파일 시스템을 겹쳐서 하나의 파일 시스템으로 보여 주는 커널 기술, OverlayFs에 대한 스토리지 드라이버가 바로 Docker에서 권장하는 overlay2

- 컨테이너느 기본적으로 '머신 한 대'의 리소스를 효율적으로 관리하는 도구이다. MSA의 규모가 커지고 복잡해지면, 각 서비스를 구현하는 컨테이너의 수도 늘어난다. 언젠가 '머신 한 대'로 모든 컨테이너를 운영하기 어려운 지점이 오는 것이다. 이 경우 컨테이너 오케스트레이션 (Container Orchestration)을 통해 리소스를 효율적으로 관리할 수 있따.

- 컨테이너 오케스트레이션 (Container Orchestration) : 규모가 크고 동적인 황경에서의 컨테이너 생명 주기를 관리. 가용성, 이중화가 갖춰진 컨테이너 작성과 배포, 부하에 따른 스케일 아웃/인, 분산, 호스트(서버) 및 컨테이너의 상태를 확인할 수 있다.

- 컨테이너 오케스트레이션 도구로 쿠버네티스 (Kubernetes, k8s), 도커 스웜(Docker Swarm), 메소스(Mesos), 노매드(Nomad)가 있다. 현재 가장 많이 사용되는 것은 쿠버네티스이다.

- 쿠버네티스는 오픈소스 플랫폼으로 YAML을 통해 선언적 설정으로 복잡한 컨테이너 서비스의 배포를 쉽게 자동화할 수 있다. 또한 해당 생태계에서 제공되는 오픈소스나 사용 버전의 다양한 툴과 서비스를 활용할 수 있다.

- 쿠버네티스의 주요 기능 : 서비스 검색, 부하 분산, 저장소 오케스트레이션, 자동 롤아웃/롤백, 리소스 관리 및 일정 제어, 자가 복구, 시크릿과 설정 관리 (Password, Token, SSH ...)

- 쿠버네티스 아키텍처 : 제어 플레인(Control Plane) 컴포넌트와 실제 pod를 호스트하는 (워커) 노드 컴포넌트로 구성, 최소 배포 단위로 하나 이상의 컨테이너가 구성된다.

- 제어 플레인 컴포넌트 (Control Plane Component) : 클러스터 내 노드와 포드를 관리. 클라우드 벤더의 k8s 서비스를 사용하면 벤더 측에서 제어 플레인을 관리하므로 사용자는 이 기능을 인식할 필요가 없다.

- 노드 컴포넌트 (Node Component) : k8s 클러스터에는 적어도 하나의 노드가 존재하며, 모든 노드를 실행하고, 실행 중 포드를 유지하고, 실행 환경을 제공한다.

- k8s 클러스터와 클라이언트는 모두 쿠버네티스 API를 사용해 커뮤니케이션한다. 제어 플레인의 API 서버가 JSON 형식의 RESTFul API를 받아 클러스터와 클라이언트를 연결하는 단일 인터페이스 역할 수행

- Pod, Deployment, Service 등 다수의 API 객체 존재

- 포드 (Pod) : 쿠버네티스로 작성 및 관리할 수 있는 최소 배포 단위, 포드 내 컨테이너는 IP 주소와 저장소 볼륨을 공유하며, 보통 디플로이먼트나 잡처럼 별도의 API 객체가 간접적으로 생성한다. 원자성 처리로, 포드를 완전히 생성하거나 말거나 둘 중 하나로 어중간한 상태는 존재하지 않는다.

- 디플로이먼트 (Deployment) : k8s의 중요 역할 중 하나가 포드를 선언된 대로 적절하게 지속 운영하는 것. 이 때 필요 포드 수를 관리하는 것이 레플리카셋 (ReplicaSet) 이라는 API 객체. 디플로이먼트는 레플리카셋의 롤아웃을 관리하여 선언적 업데이트를 제공

- 서비스 : 일련의 포드를 네트워크 경유로 접속하게 공개하는 API

- 컨피그맵 : 타 API 객체가 사용할 때 필요한 설정을 저장하는 API, key-value 형식

- 컨테이너 오케스트레이션의 특징 : 인프라를 사용자가 관리하고, 특정 제공사에 종속되는 벤더 종속을 피하고, 이동성이나 재사용성을 높이고 싶은 경우 장점을 가지나, 보안 관리 및 인프라 운용이 필요하다는 단점이 있다.

Key Point / 서버리스

-  서버를 관리할 필요가 없는 애플리케이션을 구축해서 실행, 서버가 불필요한 것이 아닌 서버 구축, 유지, 관리, 업데이트, 확장, 용량 관리에 시간과 리소스를 투입할 필요가 없다는 의미. 개발자는 비즈니스 로직 작성에 집중할 수 있고, 운영 엔지니어는 더 중요한 일을 할 수 있다.

- 서버리스에선 로직 일부에 외부 서비스를 이용, 정적 플로와 동적 콘텐츠 생성이 이루어지고, 클라이언트를 이를 호출해 다양한 서비스 간 상호 작용을 조정할 수 있다.

- BaaS(Backend-as-a-Service) : 애플리케이션 핵심 기능의 일부를 외부 API 서비스로 교체하는 것, 이용자는 확장 및 운영을 고려하지 않고 이용할 수 있음, 전형적으로 SPA(Single Page Application)이나 Rich 클라이언트를 사용. BaaS로 구글 파이어베이스나 Auth0등이 있다.

- FaaS(Functions-as-a-Service) : 이벤트 주도 (event-driven) 컴퓨팅을 제공하는 서비스, 이벤트나 HTTP 요청에 의해 실행되는 함수를 사용하여 코드를 실행 및 관리. 작은 코드 단위를 배포하여 필요에 따라 개별 처리로 실행. 서버나 인프라를 관리할 필요가 없고 확장도 자동, AWS Lambda, Azure Functions, Google Cloud Functions 등이 잇다.

- 서버리스가 유효한 경우

    - 비동기, 병행 또는 독립된 작업 단위로 병렬화하기 쉬운 작업

    - 요구 빈도가 낮으면서 산발적인 작업

    - 확장 요건의 범위가 넓고, 예측 불가능한 작업

    - 스테이트리스(Stateless)이고, 생명 주기가 짧은 작업

    - 비즈니스 요건이 빈번하게 변화하고, 개발도 그에 맞추어 빠르게 진행해야 하는 작업

- 서버리스의 장점 : 비용 절감, 쉬운 유지 및 관리

- 서버리스의 단점 : 상태 관리 번잡, 지연 시간 발생, 로컬 테스트 어려움, 콜드 스타트, 툴/실행 환경 제약, 벤더 종속

- 서버리스의 특징 : 인프라 관리나 범용 서비스를 플랫폼에 위임하여 이벤트 주도 함수에 집중 개발할 수 있음, 배포 후에도 코드가 실제 실행되는 시간만 과됨, 그러나 현재 플랫폼이나 커뮤니티가 미성숙하며 기존 서비스를 마이그레이션 하기엔 난이도가 높다는 단점이 있다.

6장, 서비스 메시

Key Point

- 다수의 서비스로 구성되는 MSA는 초분산 시스템이므로 서비스를 잘 관리하지 않는다면 필요한 리소스가 너무 커져 감당할 수 없을 수도 있다. 이 때 사용되는 방법이 바로 서비스 메시 (Service Mash) 이다.

- MSA는 컨테이너나 서버리스처럼 런타임상에서 실행되는 경우가 많고, 플랫폼상에서는 서비스 배포나 재시작 떄마다 IP 주소가 수시로 변경된다. 따라서 호출단에서는 항상 호출을 원하는 서비스 IP 주소를 파악할 수 있어야 한다.

- IP 주소 뿐만 아니라, 다양한 버전의 동시 운영시와 같이 목표 서비스의 상세 정보에 대해 파악할 수 있어야 한다.

- 관찰 가능성 (Obeservability) : 서비스 출력을 통해 내부 상태를 파악할 수 있는 것으로, 서비스가 정상적으로 동작하는지 파악하기 위해 중요한 역할을 한다.

- 장애의 분리 (Fault Isolation) : 특정 서비스에서 발생한 장애가 시스템 전체에 영향을 끼치지 않고, 특정 처리로 영향이 제한되도록 하는 것

- 서비스 메시 (Service Mash) : 서비스 간 상호 통신이 그물 형태 (Mash)로 연결되어 있어 MSA간 통신을 관리하는 구조

- 서비스 간 모든 통신이 통과하는 계층으로 서비스에 부속되는 경량 프록시를 둔다. 이 프록시는 서비스 검색이나 트래픽 제어, 관찰 가능성, 장애의 분리, 보안 등을 관리하는 기능을 한다.

- 서비스 메시는 제어 플레인과 데이터 플레인이라는 두 가지 컴포넌트로 구성된다.

- 제어 플레인 (control plane) : 서비스 메시를 관리, 서비스 검색 등 관리에 필요한 정보를 보관하거나 구성 변경 등의 관리 명령을 내림

- 데이터 플레인 (data plane) : 제어 플레인에서 내린 지시를 받아 서비스 통신을 제어하거나 관리에 필요한 정보를 제어 플레인에 전송

- 데이터 플레인은 서비스 구현 시 내장되는 것이 아니라 사이드카 패턴으로 각 서비스에 부속되는 형태로 존재한다.

- 사이드카 패턴 (Sidecar Pattern) : 보조적 기능을 서비스와 분리하여 별도의 컴포넌트로 배포하는 분산 시스템의 설계 패턴 중 하나

- 서비스 메시에서는 사이드카로 프록시를 사용하고, 구현 언어에 의존하지 않으며 서비스와 관련된 모든 통신을 제어 가능하다, 서비스 메시릴 실현하기 위해 서비스를 변경하지 않아도 되고, 서비스 개발팀은 비즈니스 로직 개발에 전념이 가능하다.

- 정라하자면 서비스 메시를 사용하여 MSA를 관리할 때 서비스 검색과 부하 분산, 트래픽 제어, 서킷 브레이커, 분산 추적을 위한 원격 측정 데이터 수집, 보안 기능을 누릴 수 있다.

- 서킷 브레이커 (Circuit Braker) : 특정 서비스에 장애가 발생했을 때 영향 범위를 가능한 최소화하기 위한 구조. 특정 서비스에 장애가 발생하면 그 서비스를 호출하는 서비스에도 장애가 발생하며 연쇄적으로 이어진다. 결국 시스템 전체에 장애가 이어지게 된다. 장애 종류에 따라 오류가 즉각 전해지는게 아닌 타임아웃을 기다려야 하는 경우도 있는데, 연결된 모든 서비스에서 타임아웃을 기다린다면 시스템 전체에 지연이 발생된다. 따라서 장애 발생 감지시 바로 서비스 접근을 차단하고 오류를 반환하여 시스템 전체 지연을 방지하고, 서비스 회복 감지시 서비스 접근을 정상화시킨다.

- 트레이스 (trace) : 각 서비스가 어떤 순서로 호출되고, 어떻게 처리되어 다른 서비스로 연결되는지 파악할 수 있는 것, 복잡하게 연계된 서비스 내에서 문제가 발생한 위치를 찾을 때 도움이 된다. 데이터의 측정 시간과 양을 적절히 조절하여 DB 저장소의 부하나 필요한 로그의 양을 필요에 맞게 조정해야 한다.

7장, 마이크로서비스의 개발과 운영

Key Point

- 대규모 분산 시스템의 과제

1. 해석 툴이 있지만, 객체 간 의존 관계 파악이 어려워 서비스 및 시스템의 전체 구조 파악이 어렵다.

2. 새 기능을 추가/변경하여 릴리스할 때 버그를 발견하면 해당 부분을 고칠 때 까지 전체 릴리스를 중지해야 한다. 수정에 의한 상호 시스템간 의존 관계를 엄격하게 확인해야 하는 부담이 있다.

3. 개발자가 배포시 불안에 떨어야 하고 (ㅠ), 다수 관계자들에게도 부담이 된다. 의존 관계가 크고 개발팀간의 커뮤니케이션 관계 측면에도 문제가 많다.

4. 규모가 커질수록 전체 빌드와 결합에 시간이 많이 걸린다.

5. 시간이 많이 걸린 성과물은 많은 공간이 필요하고, 이는 이식성의 저하를 불러일으킨다. 컨테이너에겐 치명적인 문제이며, PaaS서비스에서는 어쩔 수 없이 가상 머신을 사용해야 하는 등 서비스 선택 폭이 저하된다.

- 대규모 분산 시스템을 MSA로 구성한 경우의 장점

1. 서비스 단위로 배포가 가능하여 버그 수정이나 기능 릴리스가 쉽다.

2. DDD (도메인 주도 개발) 설계를 활용하므로 책임 범위나 서비스 간 의존 관계를 명시적으로 나눌 수 있다.

3. 각 서비스 담당 범위에서 책임 권한이 확실하다면 자유 개발 후 배포가 가능하다. 팀의 기술 수준이나 언어, 프레임워크 등 기술력에 맞게 개발을 진행할 수 있고, 어떤 서비스는 Python, 어떤 서비스는 Java와 같이 작성할수도 있다.

4. 서킷 브레이커를 구현한다면 장애가 발생해도 파급되는 영향을 최소화할 수 있다.

6. 약한 결합이 주는 장점으로, 릴리스한 서비스가 전체에 영향을 주고 있다면 즉시 분리하여 원상태로 되돌릴 수 있다.

- 대규모 분산 시스템을 MSA로 구성한 경우의 주의점

1. 각 MS 자체는 단순하지만 전체적으로 시스템 동적 부품이 늘어나므로 파악이 어려워진다.

2. 서비스가 나누어지므로 서비스간 통신 구현이 필요, 이로인해 네트워크 폭주나 대기 시간이 발생할 수 있다.

- 가장 효과적인 데브옵스를 실천하기 위해서는 조직 미 팀마다 성숙한 문화를 가지고 있어야 한다. OKR, KPI, KGI를 정하고 이를 기준으로 팀 및 개인의 목표를 위해 전 팀이 협력하여 서비스나 제품 품질을 높이고 성공 경험을 많이 쌓는 것이 중요하다.

- MSA는 빠른 릴리스 주기를 주 장점으로 들 수 있지만, 운영팀에서 얻은 피드백과 메트릭스 과제, 제품팀에서의 추가 기능 제안에 대해 유연한 대응을 장점으로 들 수 있다.

- 데브옵스가 무조건 옳고 좋은 만능 해결책은 아니다. 각 조직 문화나 비즈니스 속도감, 데브옵스 이해도, 툴을 포함한 기술 숙련도에 맞추어 커스터마이징 하여 적용하는 것이 좋다. 중요한것은 상향식이냐 하향식이냐가 아니라, 데브옵스를 실현하고 싶다는 의지를 잃지 않는 것이다.

정리

이곳 저곳에서 MSA, 쿠버네티스, 도커, 분산 환경, 퍼블릭 클라우드에 대한 관심과 트렌드가 집중되고 있다. 지금까지 개인적으로 개발 공부를 하고, 협업도 해보고, 프로젝트를 진행하며 MSA의 조각 조각들을 구현하고 운영한 경험은 있으나, 이론적으로 봤을때 전체 서비스가 어떻게 구성되고, 이를 실무에서 어떻게 유관부서와의 긴밀한 협력을 통해 런칭하는지는 미숙하였다. 이 책을 통해 큰 틀에서의 MSA 구조를 이해하고, 세부적인 서비스 관리 방법을 알 수 있게 되었다.

서론

- 마이크로서비스를 단순히 '아키텍처'로만 보는 것이 아니라 더 포괄적인 '아키텍처 패턴'으로 보는 것
- 이 책은 마이크로서비스를 클라우드 네이티브 컴퓨팅 전체를 포함하는 아키텍처 스타일로 정의하고 있으므로, 마이크로서비스와 관련된 클라우드 네이티브 기술에 대해 설명한다.

- 아키텍처 스타일을 적용해 마이크로서비스를 모델화하면 소프트웨어의 구조 설계에 해당하는 마이크로서비스 아키텍처가 중심에 자리한다. 그리고 그 주변에 있는 인프라 / 실행 환경, 개발 / 운영 환경, 개발 / 운영 기법, 애플리케이션 통합 기술이 마이크로서비스 아키텍처를 지탱하는 형태가 된다.

1 장, 디지털 전환 : 마이크로서비스가 중요해진 배경

Key Point

- 디지털 전환 (Digital Transformation, DT or DX)

- '최신 IT 기술'을 활용하는 것 보다 더 중요한 것은 '비즈니스를 근본적으로 이해하고, 혁신하는 것'에 있다.

-  (투자적 측면) 최신 기술을 사용해서 인프라 표준화를 도모하고 환경 구축, 운영의 효율화와 속도 향상을 목표로 한다. 구체적으로는 표준 기술로 컨테이너에 의한 가상화를 검토한다. 컨테이너와 쿠버네티스 등의 컨테이너 오케스트레이션을 사용해 인프라를 구축, 운영하므로 특정 클라우드 서비스에 종속되지 않고 공통 인프라를 구축할 수 있다.

- (기술적 측면) 마이크로서비스와 테스트 자동화를 근간으로 한 DevOps를 실현하므로써, 개발 / 변경만 신속하게 하는 것이 아니라 자동화를 통해 오류를 줄여 서비스 품질을 향상시킨다.

- (HR 측면)  

2장, 클라우드 네이티브 컴퓨팅과 마이크로서비스

Key Point

- REST (REpresentational State Transfer)

- SaaS가 성공하면서 다음으로 주목을 받은 것이 SaaS 회사의 IT 시스템 구현 및 운영이다. SaaS 회사는 그간 축적해둔 방대한 트랜잭션을 바탕으로 확장성과 높은 가용성, 안전한 엔드 유저 시스템을 구축할 수 있다고 본 것이다. 여기서부터 서버나 네트워크 등의 컴퓨팅 플랫폼을 클라우드 서비스로 제공하는 IaaS(Infrastructre-as-a-Service)가 등장한다.

- 2006년에 유통 대기업인 아마존(Amazon)이 아마존 웹 서비스(AWS)를 시작했다. AWS와 마이크로소프트를 시작으로 많은 IT회사가 IaaS 시장에 진출하여 대 성공을 거두었고, 자연스레 이와 관련된 서버나 네트워크 가상화 기술, 서버 구성 및 배포 자동화 기술이 새롭게 개발, 추가 되었으며, 기반 구축의 속도 및 품질 향상을 도모할 수 있었다.

- IT 시스템은 인프라(기반)과 애플리케이션(서비스)으로 구성되어 있다. 인프라를 혁신하는 것은 어플리케이션 혁신에 영향을 주며, 그 반대도 마찬가지이다. 클라우드 컴퓨팅을 사용한 인프라 기술 혁신은 파급적인 영향력을 보여주었는데, 그 중 하나가 바로 PaaS다.

- Paas(Platform-as-a-Service), 소프트웨어나 네트워크를 서비스로 제공하는 IaaS에 비해, PaaS는 미들웨어부터 하위 계층의 컴퓨팅 스택을 서비스로 제공한다. 개발자는 OS나 미들웨어 등의 도입과 구성을 신경 쓰지 않고 개발에 집중할 수 있는 것이 가장 큰 장점이다. 
(Ex : Heroku, Cloud Foundry, Google App Engine, AWS Elastic BeansTalk, Ms Azure App Service...)

- 개발 및 운영의 혁신으로 지속적 통합 (CI, Continuous Integration), 지속적 전달 (CD, Continuous Delivery), DevOps, Agile 개발 프로세스가 주목을 받기 시작하였고, 클라우드 컴퓨팅을 형성하는 기법으로 자리잡았다. (애플리케이션 개발 및 운영 속도의 향상과 유연성을 실현하기 위해서)

- IaaS에 의해 인프라 구축이 비약적으로 빨라졌고, 인프라 위에 서비스 개발과 운영에 속도와 유연성을 주기 위해 CI/CD, DevOps 등의 기법이 클라우드 컴퓨팅을 형성하는 기술로 도입.

- 마이크로서비스란, 인프라 구축의 빠른 속도에 맞추어 서비스 개발과 운영 (변경 작업)을 적시에 진행하기 위한 설계, 개발, 운영 기법을 모은 것이다. 독립적으로 개발 및 실행되는 소프트웨어 컴포넌트를 여러 개 조합해서 하나의 서비스로 만드는 소프트웨어 구조에 있다. 각 서비스는 개별적으로 개발되며, 각각 독립적으로 특정 환경에 배포할 수 있는 구조를 가지고 있다. 개별 서비스를 교체하므로 서비스를 간단히 변경할 수 있는 구조이다.

- SaaS -> IaaS -> PaaS로 서비스 계층 혁신이 이루어지고 있다.

- 클라우드 네이티브 컴퓨팅의 목적은 "확장 가능한 서비스를 구축/운영하는 것과 IT 시스템에 최소한의 인력으로 자주, 그리고 계획한 만큼 임팩트가 있는 변경을 추가하는 것" 이다. 이 외에도 비즈니스적 측면에서의 목표가 있으며, 다양한 클라우드를 활용하여 느슨하게 결합된 서비스를 만들어야 한다. 구체적으로 컨테이너, MSA, 오픈소스 사용 등이 있다.

3장, 마이크로서비스 아키텍처의 기본

Key Point

- MSA의 서비스 구조는 객체 지향에서 객체와 유사

- 레이어 아키텍처 : 특정 기준에 근거하여 여러 계층(레이어)을 만들고 그 계층 구조를 따라 소프트웨어 컴포넌트나 기능을 분류, 관리하는 접근법

    - 레이어 아키텍처로 도메인 주도 설계 (Domain Driven Design, DD)의 4계층 적용이 가능하다

    - 1. 최상위 사용자 인터페이스 계층

        - 렌더링, 요청 / 응답 전송, 데이터 변환 및 이를 담당하는 서비스 배치

    - 2. 애플리케이션 계층

        - 서비스 조율, 도메인 객체 접근, 트랜잭션 관리

        - MSA 에서는 하나의 사용자 요청을 처리하기 위해 도메인 서비스를 여러 번 호출한다. 매번 클라이언트의 서비스 호출로 서비스 지               연이 일어날 수 있기에,  해당 계층의 서비스가 클라이언트 대신 여러 도메인 서비스를 호출하여 네트워크의 양방향 통신을 1회로 줄             여 성능을 향상시킬 수 있다. (Gang of Four, GoF 디자인 패턴의 파사드(facade)에 해당)

    - 3. 도메인 계층

        - 도메인 상태와 동작(비즈니스 로직)을 구현하는 도메인 서비스 배치

    - 4. 인프라 계층

        - 외부 리소스가 타 계층에 접근 가능하도록 지원. DB나 메시징 등 외부 시스템 연동시 사용

- 레이어 아키텍처는 간단하면서 이해하기 쉬워 기능 분할이나 구조화가 쉽고, 소프트웨어 컴포넌트를 조합해 개발하는 설계 방식에 적합하다. 그러나 확장성이 약하다는 단점이 있다. (추상적인 것이 구체적인 것에 의존하기에)

- 레이어 아키텍처의 단점을 보완하기 위해 제어 반전 (Inversion of Control, IoC)라는 개념이 대두

- 구체적으로 콜백이나 의존성 주입 (Dependency Injection, DI)의 기법이 있으며, 이는 객체지향에서 폭넓게 사용되고 있으며, 스프링도 원래는 DI 컨테이너로 시작했다.

- 헥사거널 아키텍처 (hexagonal architecture) : 불특정한 데이터 입출력에 대응할 수 있도록 확장성을 가지는 육각형 형태의 아키텍처

- 도메인(비즈니스 로직)을 중심으로, 주변에 도메인을 호출하는 입력과 실행되는 출력 측이 있다.

- 데이터베이스 간 동기화를 위한 솔루션으로 사가(Saga)가 있다. 사가란 로컬 트랙잭션 이벤트, 보상 트랜잭션 등을 사용해 여러가지 리소스 간 동기화를 취하는 디자인 패턴

- 데이터 결합 : 분산 데이터베이스 환경이 가진 문제 중 하나, 여러 DB에 나누어진 데이터를 하나의 뷰로 구성해서 클라이언트에 제공하려면?

- API 컴포지션 (API Composition) : 도메인 계층의 집약 서비스와 인프라 계층의 레포지토리 서비스를 통해 복수의 DB로부터 얻은 데이터를 APP 계층에서 인메모리로 결합하는 디자인 패턴, 운영 환경 메모리에 부하가 집중되는 단점

- CQRS & 이벤트 소싱 (Event sourcing) : 서로 독립된 디자인 패턴이지만 조합해서 사용되는게 일반적, 데이터 결합 해결책이 될 뿐만 아니라 결과 일관성을 구현하는 새로운 데이터 접근패턴

- CQRS (Command Query Responsibility Segregation, 명령 질의 책임 분리) : 데이터 접근 처리를 갱신형/참조형으로 구분하고 각각의 독립된 서비스 컴포넌트와 저장소를 두는 디자인 패턴. 갱신형 처리에는 영구적 데이터 저장소를 만들어 기능과 신뢰성을 높이고, 참조형 처리에는 고속 검색 기능을 가진 데이터 스토어를 배치

- 이벤트 소싱 : CQRS에서는 갱신형 저장소와 참조형 저장소를 동기화해주는 구조가 없는데, 이를 이벤트 소싱이 해결한다.

- MSA 자체에는 개발 속도를 향상시키는 구조가 없다. 초기 셋업이나 프로젝트 시작시엔 기존 워터폴 형태보다 더 많은 리소스를 요하며, 시간도 많이 걸린다. 이런 MSA를 적용하면서 신속한 개발을 위해 애자일 개발 프로세스를 도입하는 것이다.

- MSA의 모델링을 애자일 개발 프로세스를 사용해서 진행할 때 친화성 좋은 소프트웨어 설계 방식이 DDD, 도메인 주도 개발이다. 도메인 모델을 설계 및 개발 작업의 중심에 두고 반복적으로 변경하고 고도화하며 프로그램을 구현하는 것이다.

- MSA 설계 시 '마이크로'라는 이름 때문에 '반드시 작게 만들어야 하는 것 아닌가' 라는 강박 관념에 사로잡힐 수도 있다. 그러나 MSA에선 의외로 세분화 정도는 문제가 되지 않는다. 유연한 서비스 개발 및 운영이 실현된다면 세분화 정도는 크든 작든 상관 없다. 어차피 세분화 정도나 최적화 정도는 시스템을 운영해봐야 비로소 알 수 있는 것이다. 서비스화는 크게 시작하고 릴리스 후에 주기에 따라 작은 서비스로 분할하는 방법을 추천하는 경우도 많다.

- 모노리스 우선 (Monolith First) : 첫 스프린트에서 핵심 서비스를 모노리스로 설계/개발/릴리 한 뒤 이후 부터 기존 서비스나 신규 기능을 서비스화 하는 방식

4장, 마이크로서비스 패턴

Key Point

- 데이터 관리 패턴

    - MSA에서는 분산 데이터베이스를 권장 (약하 ㄴ결합)

    - 데이터 동기화 : 분산 데이터베이스 간 데이터 동기화는 어떻게 구현할 것인가

    - 데이터베이스 배치 모델 : 어떤 기준에 근거해서 데이터베이스를 배치할 것인가

    - 데이터 결합 : 분산 데이터베이스에 흩어져 있는 데이터를 어떻게 집약할 것인가

- 서비스별 데이터베이스

    - 장점 : 유연하고 빠른 서비스 변경, 요건에 맞는 최적의 데이터베이스 제품 및 기술 선택

    - 고려 : 결과 일관성, 여러 DB간 데이터 동기화 구조, 여러 DB에 걸쳐있는 데이터를 검색 및 집약하는 구조

- 공유 데이터베이스

    - 통합된 하나의 DB 인스턴스를 복수의 서비스 및 App, 시스템이 공유할 수 있는 DB 배치 패턴

    - 지금까지 우리가 사용해 온 친숙한 DB 배치 모델이라 할 수 있다.

    - 모든 데이터가 단일 데이터베이스에 저장되고, 복수의 데이터 갱신 시 로컬 트랜잭션을 사용, ACID를 유지하고 데이터 일관성 확보

    - 단점 : 유연성 떨어짐, 신속한 변경 불가, 단일 DB에 처리가 집중되고 비관적 락에 의한 성능 저하, 확장시 서버를 스케일업 해서 대응

- 코레오그래피 (choreography)

    - DB에 접속하는 서비스가 각각 메시징 제품을 통해 데이터를 동기화

    - 각 서비스가 자립/능동적으로 사가 프로세르를 돌리는 것이 크레오 그래피

    - 구조가 단순하나, 각 서비스와 DB 간 연계를 한 눈에 파악하기 어렵고, 진행 상태를 확인하기 어렵다. 관심사 분리가 저해된다.

- 외부 API 패턴

    - MSA에서 비즈니스 애플리케이션을 설계 및 개발할 때 다양한 클라이언트와 연동하기 위한 패턴

    - MSA에선 하나의 애플리케이션이 여러 개의 서비스로 구성된다, 하나의 작업을 하기 위해 여러 개의 서비스를 호출해야 한다.

    - 이 때, 외부에서 접속할때 발생하는 문제점 (서로 다른 프로토콜 간 통신, 네트워크 지연 등)을 해결해야 한다.

    - 통신 프로토콜 교환 및 교차, 통신 횟수 최소화, 호출 횟수 최소화 등의 해결방안이 필요

    - API 게이트웨이 패턴

         - 도메인 경계에 클라이언트 처리를 담당하는 전용 서비스 API를 설치하는 것

         - 클라이언트 대신에 주문용 API 게이트웨이가 여러 서비스를 대신 호출하는 것

         - 클라이언트와 서비스 간에 API 게이트웨이라는 하나의 완충제를 마련하여 영향을 최소화 할 수 있음

         -  DDD의 GoF 디자인, Facade에 해당된다.

- 통신 패턴

    - REST는 요청/응답 및 동기형 통신 고유의 다양한 문제가 있음. 이를 해결하기 위해 다양한 프로토콜과 통신 상태가 필요하여 멱등성(실행 횟수와 무관하게 언제나 같은 결과를 보장하는 특성)도 고려해야 한다.

    -  원격 프로시저 호출 (Remote Procedure Invocation, RPI)

         - 쉽고 간단하며 범용적이나, 동기형 통신으로 확장성이 약하고 복잡+오래 걸리는 처리에는 부적합.

         - 로직이 복잡하고 지연시 응답 연장, 서버 리소스 고갈로 인한 장애 파생

    - 메시징 (messaging)

         - 발행자와 구독자(컨슈머)가 이벤트(메시지)를 통해 통신하는 모델

         - MOM 또는 메시지 브로커를 통해 이벤트나 메시지를 비동기적으로 전달한다.

         - 메시징 패턴을 활용하므로 일방향&비동기형, 요청/응답&동기형, 요청/응답&비동기형 등 통신 형식을 취할 수 있다.

    - 도메인 특화 프로토콜

         - 특정 상황에 맞는 고유 프로토콜을 적용하는 디자인, 메일 전송 같은 경우 SMTP, POP, IMAP 등

    - 멱등 (Idempotent) 소비자

         - 의도하지 않는 운영이나 작업 시에도 멱등성을 보장하는 통신 패턴

         - DB와 간단한 확인 로직을 조합하여 멱등 소비자를 구현할 수 있다.

Apple developer Program (애플 개발자 등록) 도중 등록을 완료할 수 없다는 창이 떴다.

조치 방법이나 어떠한 내용도 적혀있지 않은 불친절한 안내 문구

애플 고객센터에 해당 내용과 스크린샷을 포함하여 문의를 보냈으나..

무슨 말장난하는건지..

결국 이런 저런 시도 끝에 해결했다.

인과관계가 확실치 않으나, 일단 내 경우의 해결 방법을 공유하고자 한다.

1. Apple Safari 브라우저 + 시크릿 모드 접속

2. 약관 스크롤 끝까지 다 내려 읽기