devops

[C813] 마이크로서비스를 구성할 때, 데이터베이스를 꼭 분리해야 하나요? 데이터가 한 곳에 모여있지 않고 중복되어도 괜찮은가요? 모범 사례를 알아보고, 이유를 함께 적어주세요. 서비스별로 데이터베이스를 사용시 이점 (microservices.io) 서비스가 더욱 느슨하게 결합되는 데 도움이 된다. 한 서비스의 데이터베이스를 변경해도 다른 서비스에는 영향을 미치지 않는다. 각 서비스는 필요에 가장 적합한 데이터베이스 유형을 사용할 수 있다. 예를 들어 텍스트 검색을 수행하는 서비스는 ElasticSearch를 사용할 수 있습니다. 소셜 그래프를 조작하는 서비스는 Neo4j를 사용할 수 있다. 서비스별로 데이터베이스를 사용시 단점 여러 서비스에 걸친 비즈니스 트랜잭션을 구현하는 것은 간단하지 않다. 분산..

REST(Representational State Transfer) REST는 HTTP로 소통하는 프로세스 간 통신 규약이다. REST API는 웹에서 사용되는 데이터나 자원을 HTTP URI로 표현하고 HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식이다. 현대 HTTP 메시지의 body는 JSON 형태로 다루는 것이 기본이다. (이 때 HTTP 헤더의 Content-Type 값은 application/json으로 설정) REST의 장점 curl 등의 도구로 간편하게 테스트 가능 요청/응답 통신 지원 시스템 아키텍처가 단순 REST의 단점 요청/응답만 지원 메시지를 주고받기 위해서 클라이언트와 서버가 실행되어야 함 요청 한번에 여러 리소스 조회는 어려움 메소로만으론 한번의 요청에 다양한 작업들을 하..

마이크로서비스도 하나의 프로세스 단위로 실행되기 때문에, 프로세스 통신이라고 보는게 맞다. IPC(Inter-Process-Communication)은 개발 도메인보다 더 대중적으로 쓰이는 용어다. 프로세스 간 통신 서비스와 서비스가 통신하려면 인터페이스가 존재해야하고, 인터페이스가 요구하는 데로 커뮤니케이션해야한다. 동기/비동기 HTTP 프로토콜은 기본적으로 TCP 연결(혹은 UDP)을 만들고 이 위에서 요청에 따라 즉시 응답오는 형태로 구현이 되어 있다. 세상에는 요청에 따른 응답이 즉시 도착하는 커뮤니케이션만 존재하지 않는다. + HTTP는 동기? 비동기? HTTP는 동기적인 매커니즘으로 분류한다. 서로 통신하는 PC는 모두 켜져 있어야하며, 클라이언트는 서버가 응답을 해줄 것이라고 기대하기 때문이..

서버리스 의미 서버리스는 서버가 없다는 뜻이 아닌, 개발자가 서버를 관리할 필요없이 Application을 빌드하고 실행할 수 있도록 하는 Cloud native 개발 모델이다. 서버가 존재하지만, 직접적인 관리가 필요하지 않기 때문에 추상화되었다고도 볼 수 있다. 마이크로서비스와 서버리스의 관계 마이크로서비스는 독립적인 작은 서비스 단위로 배포와 업데이트가 가능하며, API 게이트웨이가 사용자 또는 마이크로 서비스간 API 통신을 지원하는 것이 특징이다. 서버리스는 별도의 서버 구축필요 없이 어플리케이션 개발과 배포를 지원하는 클라우드 컴퓨팅 서비스다. 서버리스는 마이크로서비스 구조의 개발을 위해서 아주 적합한 형태의 컴퓨팅 서비스다. 여러 Function을 구성하고 이들을 독립적인 API로 구성해서 ..

도메인(Domain) 도메인 지식이란 어떤 산업과 분야를 이해하기 위해 필요한 지식을 의미한다. 여기서 도메인은 지식, 영향력, 활동 영역으로 개발에서는 S/W로 해결하려는 문제 영역을 말한다. 도메인 주도 설계(DDD) 하나의 도메인 모델에 대한 이해관계가 각자 다름을 인정하고, 각팀에 적합한 하위 도메인을 설정. 해당 하위 도메인에 대한 맥락을 알고 있는 사람이 따라야할 비즈니스 규칙에 대한 경계를 설정하는 설계방식이다. 도메인 자체와 도메인 로직에 초점을 두고, 데이터 중심의 접근법에서 벗어난다. 보편적 언어를 사용한다. 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해가능한 문서와 코드로 구축하는 과정이다. 이로써 통일된 방식으로 소통이 가능해진다. 소프트웨어 엔티티와..

서버리스(Serverless) 서버리스는 적은 예산으로, 빠르고, 쉽게 확장할 수 있으며 관리와 운영을 혼자서도 충분히 할 수 있게 해준다. 서버리스가 단순히 서버가 없는 것이 아닌, 서버에 대한 고민을 안할 수 있게 해주는 것이다. 컴퓨팅 진화 과정 이전에는 어플리케이션을 배포하기 위해서 직접 로컬 서버를 구매해서 구성해야 했다. 그래서 개발자 혹은 기업은 하드웨어와 소프트웨어 모두 구축하고 관리해야하는 불편함이 있었다. 하드웨어를 직접 관리하는 것도 나름의 장점이 있으나, 많은 비용과 부품 관리를 위한 전문지식도 필요했다. 이런 관리의 어려움을 해결해 준 것은 AWS의 EC2 서비스다. EC2로 인해서 하드웨어 관리의 불편함을 해소할 수 있게되었지만, EC2로 구성한 서버의 소프트웨어도 보안과 백업,..

마이크로 서비스 아키텍처란? 유지보수에 유리하고 테스트가 가능해야한다. 느슨하게 결합되어야 한다. 독립적으로 배포할 수 있어야한다. 비즈니스 역량을 중심으로 구성해야 한다. 작은 팀 단위로 소유되어야 한다. 서비스의 컴포넌트화 컴포넌트는 독립적으로 대체하거나 업그레이드가 가능한 S/W 단위다. 여기서 컴포넌트화는 시스템을 구성 요소별로 나누고 이를 연결해서 구축하는 것을 말한다. 쉽게말해서 S/W를 여러 서비스로 분리하는 것이다. 모놀리식 vs 모듈식(Microservice)의 팀 분류 기존에는 UI팀, 미들웨어 팀, DB팀으로 나누어서 구성하기 때문에 S/W의 단순한 변경이 필요한 경우 팀 간의 협업 비용과 시간이 증가한다. 그러나 비즈니스 수행 능력(업무 도메인)에 따른 팀분류의 경우, 팀이 하는 일..

ECR 레포지토리에서 Docker 토큰 인증할때, 아래와 같은 오류가 발생한다. Error saving credentials: error storing credentials - err: exit status 1, out: `status code not OK but 401: {"detail":"Incorrect authentication credentials"}` docker의 설정 json 파일을 삭제하고 다시 입력하면 된다. cd ~/.docker rm config.json 출처 https://stackoverflow.com/questions/64455468/error-when-logging-into-ecr-with-docker-login-error-saving-credentials-not

블루/그린 배포 어플리케이션과 마이크로서비스의 이전 버전에 있던 사용자 트래픽을 이전 버전과 동일한 새 버전으로 점진저긍로 이전하는 어플리케이션 릴리스 모델이다. 블루/그린 배포가 필요한 이유는 배포를 자동화할 때 겪는 어려움 중 하나인 Software를 최종 테스트 단계에서 실제 프로덕션 단계로 전환하는 컷오버다. 일반적으로 다운 타임을 최소화하려면 이 작업을 신속하게 수행해야 한다. * 컷오버(Cutover) : 기존에 운영되던 환경을 중단시키고 새 구축환경으로 오픈하는 것 * 다운타임(Downtime) : 시스템을 이용할 수 없는 시간 블루/그린 배포의 장점 동일하게 구성된 환경을 추가하여 서비스 가동 중단 시간을 최소화할 수 있다. 서비스되고 있는 환경(blue or green)에 문제 발생 시 ..

배포 자동화 배포 자동화는 한 번의 클릭, 명령어 입력을 통해서 전체 배포 과정을 자동화하는 것을 말한다. - 수동적이고 반복적인 과정을 자동화시켜 시간을 절약할 수 있다. - 휴먼 에러(Human Error)를 방지할 수 있다. 배포 자동화 파이프라인 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 파이프라인이라고 한다. 파이프라인은 전체 배포 과정에서 여러 단계로 분리한다. 각 단계는 파이프라인 안에서 순차적으로 실행되며, 단계마다 주어진 작업을 수행한다. 1. Source 단계 : 원격 저장소에 관리되는 소스코드에 변경 사항이 일어나게 되면 이를 감지하여 다음 단계로 전달하는 작업을 한다. 2. Build 단계 : Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가..