모니터링 : 애플리케이션이 사용할 수 있는 원격 측정을 확인하고 실패 상태에 대한 경고를 정의하는 것관측 가능성 : 단순한 모니터링을 넘어 시스템에 대해 던질 수 있는 질문을 미리 정해놓지 않은 상태에서 어떠한 질문이라도 할 수 있는 상태에 도달하는 것을 목표로 한다.제품 팀은 애플리케이션이 관련 정보를 노출하도록 해야 한다.플랫폼 팀은 이 정보를 사용하고 애플리케이션의 운영에 대해 질문할 수 있는 인프라를 제공해야 한다. 1. 스프링 부트, 로키 및 플루언트 비트를 사용한 로깅`로그(이벤트 로그)` : 소프트웨어 애플리케이션이 시간이 지남에 따라 발생한 일들에 대한 불연속적인 기록로그는 ‘이벤트가 언제 발생했는가?’ 라는 질문을 위해 필요한 타임스탬프 그리고 이벤트와 그 콘텍스트에 대한 세부 정보로 이..

액세스 제어 시스템은 사용자가 식별되고 필요한 권한이 있는 경우에만 리소스 접근을 허용한다.이를 위해서는 식별, 인증, 권한의 세 가지 중요한 단계를 따라야 한다.식별 : 사용자가 자신의 신분을 주장할 때 발생한다. 물리적 세계에서는 자신의 이름을 말하면서 소개할 때 일어난다. 디지털 세계에서는 유저명이나 이메일 주소를 제시할 것이다.인증 : 사용자가 주장하는 신분을 여러 가지 요소들, 예를 들면 암호, 인증서, 토큰 같은 것을 통해 검증하는 일이다. 사용자의 신원을 확인하기 위해 여러 가지 요소를 사용하면 다중 요소 인증이라고 한다.권한 : 항상 인증 후에 발생하며 사용자가 주어진 상황에서 무엇을 할 수 있는지 확인한다. 1. 스프링 보안 기초스프링 보안 : 스프링 애플리케이션 보안의 표준, 명령형 및..

보호되어 있는 글입니다.

클라우드 네이티브 애플리케이션은 느슨하게 결합되어 있어야 한다.어떤 애플리케이션이라도 다른 애플리케이션의 변경없이 구현을 변경할 수 있다.주문 서비스에 영향을 미치지 않고 리액티브 패러다임을 사용해 카탈로그 서비스를 다시 구현할 수 있다.REST API와 같은 서비스 인터페이스를 사용하면 구현 세부 사항을 숨기고 느슨한 결합이 개선된다.하지만, 지금까지 만든 애플리케이션들이 어떻게 상호작용하는지 생각해보면, 시스템에 다른 구성 요소가 필요하다는 것을 알 수 있다.주문 서비스가 책을 성공적으로 주문하려면 카탈로그 서비스가 필요하다.주문 서비스와 카탈로그 서비스가 동시에 사용 가능한 상태여야만 시스템 요구 사항을 충족할 수 있다.이벤트 중심 아키텍처는 이벤트를 생성하고 소비함으로써 상호작용하는 분산 시스템을..

스프링 리액티브 스택을 토대로 폴라 북숍 시스템을 위한 API 게이트웨이를 구현한다.API 게이트웨이 : 마이크로서비스와 같은 분산 아키텍처에서 클라이언트가 직접 내부 API를 연결하지 않도록 하기 위해 일반적으로 사용하는 패턴시스템에 이러한 진입점을 설정해놓으면 보안, 모니터링 및 복원력과 같이 공통으로 발생하는 이슈를 다루는 데에도 사용할 수 있다.시스템의 복원력을 향상하기 위해 스프링 클라우드 서킷 브레이커를 사용해 서킷 브레이커를 설정하고 스프링 데이터 레디스 리액티브를 통해 사용률 제한기를 정의한 후에 재시도 및 타임아웃을 활용한다. 1. 에지 서버와 스프링 클라우드 게이트웨이`스프링 클라우드 게이트웨이` : 스프링 웹 플럭스 및 프로젝트 리액터를 기반으로 API 게이트웨이를 제공하기 위해 구축..

이 시스템의 또 다른 필수 기능은 도서 구매 기능이다.새로운 구성 요소는 데이터베이스뿐만 아니라 카탈로그 서비스도 연결한다.요청당 스레드 모델에서는 각 요청을 처리하기 위해 하나의 스레드를 할당하는데 이때 스레드는 해당 요청만 처리한다.요청을 처리할 때 데이터베이스 또는 서비스 호출을 해야 하는 경우 스레드는 호출을 한 후 응답을 기다리면서 유휴 상태가 되고 스레드는 블로킹된다.유휴 시간동안 해당 스레드에 할당된 리소스는 다른 용도로는 사용할 수 없기 때문에 이 리소스를 낭비하게 된다.리액티브 프로그래밍 패러다임은 이 문제를 해결하고 I/O 연산이 많은 애플리케이션에서 확장성, 탄력성, 비용 효율성을 개선한다. 리액티브 애플리케이션은 비동기적이고, 비차단 방식으로 작동하므로 계산 리소스를 보다 효과적으로..

1. 도커에서 쿠버네티스로의 이동도커 컴포즈를 사용하면 네트워크와 스토리지 설정을 포함해 한 번에 여러 컨테이너의 배포를 관리할 수 있다. → 하지만 한 대의 머신에 대해서만 사용할 수 있다.도커로는 개별 머신에 배포하지만 쿠버네티스로는 컨테이너를 여러 머신으로 이루어진 클러스터에 배포함으로써 확장성과 복원력을 가질 수 있다.쿠버네티스 클라이언트는 API를 통해 쿠버네티스 컨트롤 플레인과 상호작용하는데, 컨트롤 플레인은 쿠버네티스 클러스터에 객체를 만들고 관리한다. → 여전히 단일 개체에 명령을 보내지만, 이 명령은 하나의 머신이 아닌 여러 머신에 대해 수행된다.주요 구성 요소`클러스터` : 컨테이너화된 애플리케이션을 실행하는 노드의 집합. 컨트롤 플레인을 가지고 있고 하나 이상의 작업자 노드로 이루어진..

지금까지 REST API 노출하고 컨테이너로 실행되는 PostgreSQL 데이터베이스를 통해 데이터를 저장하는 카탈로그 서비스 애플리케이션을 개발했다.쿠버네티스 클러스터로 배포하기 전에 컨테이너 이미지로 패키징하고 수명주기를 관리하는 법을 알아야 한다.여러 개의 컨테이너로 작업할 때는 도커 CLI가 효율적이지 않기 때문에 도커 컴포즈를 활용해 여러 컨테이너와 컨테이너의 라이프사이클을 관리한다. 1. 도커에서 컨테이너 이미지로 작업하기도커 엔진은 클라이언트/서버 구조를 가지고 있다.도커 CLI는 도커 서버와의 상호작용을 위해 사용하는 클라이언트다.도커 서버는 도커 데몬을 통해 도커의 모든 리소스를 관리한다.서버는 컨테이너 저장소와도 연결해 이미지를 업로드하고 다운로드할 수 있다. [1] 컨테이너 이미지 이..

영구 저장 메커니즘이 없기 때문에 애플리케이션을 종료하면 카탈로그에 추가한 책들은 사라져버린다.상태 state : 서비스를 종료하고 새로운 인스턴스를 만들 때 보존되어야 하는 모든 것데이터 서비스는 시스템의 한 구성 요소로 상태를 갖는다.ex. 데이터 저장소 : PostgreSQL, 카산드라, 레디스 / 메시징 시스템 : 래빗MQ, 카프카 1. 클라우드 네이티브 시스템을 위한 데이터베이스데이터 서비스를 직접 관리할지, 클라우드 공급자가 제공하는 것을 사용할지 [1] 클라우드에서의 데이터 서비스데이터 서비스 : 상태를 저장하고자 설계된 클라우드 네이티브 아키텍처의 구성 요소애플리케이션이 상태를 갖지 않도록 설계한다는 것은 결국 클라우드에서 저장과 관련한 복잡한 문제를 적은 수의 구성 요소로만 한정한다는 의..

0. 외부화 설정 관리configuration은 15요소 방법론에 의하면 배포 간 변경될 수 있는 모든 것으로 정의된다.ex. 크리덴셜, 리소스 핸들, 지원 서비스의 URL 등클라우드 네이티브 애플리케이션의 핵심 중 하나는 환경이 달라지더라도 애플리케이션 아티팩트는 동일하다는 점이다.하나의 애플리케이션 —(패키징)—> 빌드 —(결합)—> 프로덕션 설정, 스테이징 설정 .. —(배포)—> 프로덕션, 스테이징 ..스프링에서는 설정 데이터가 속성(키-값 쌍) 형식으로 추상화되는데 속성 파일, JVM 시스템 속성, 시스템 환경 변수와 같이 여러 유형의 다른 소스를 통해 정의할 수 있다. [1] 설정 전략 : 애플리케이션과 함께 패키징된 속성 파일이 파일은 애플리케이션이 지원하는 설정 데이터의 명세서 역할을 할 ..