개발자의 기록장 블로그

정의CI/CD란 지속적으로 코드를 통합하고 연속적인 배포를 한다는 것으로 빠른 개발과 배포를 하기 위한 운영 기법이다.코드를 짜고, 빌드를 해서 테스트를 하고 배포하는 과정에서 기존에는 개발자들이 수동으로 작업을 해주어야했다.이런 일련의 흐름을 자동화하기 위한 움직임이 DevOps 관점에서 CI/Cd인 것!Git base CI/CD Pipeline Diagramcode commit은 github이고, code build는 깃 액션이다. 뭘 사용하든 상관없다.다만 K8S 배포 파일 ( 구축 레벨의 코드 )와 소스 코드의 레포지토리는 분리해서 관리하자. 개발팀이 코드를 깃저장소에 푸쉬하고, 깃 액션에서 이를 확인해 빌드한다. 빌드를 끝마치면 이미지 파일을 푸쉬함과 동시에 PR요청을 보내고, PR 리뷰팀이 이..

Why Kubernetes?컨테이너는 가볍고, 빠르고, 휴대성이 좋다는 장점이 있다.이 장점 때문에 많은 수의 컨테이너로 서비스 규모를 키울 수 있고 스케일 아웃을 통해 다중 트래픽 분산 또한 수월하게 할 수 있다. 하지만 이러한 컨테이너 수의 증가는 결국 관리의 어려움을 가져오게 된다.개발자 관점에서는 다양한 이점을 가졌지만 운영자 관점에서는 다양한 문제가 존재하는 것!컨테이너가 외부 호스트 또는 외부 호스트의 컨테이너와 통신하려면 NAT를 거쳐야 함서비스 고가용성과 분산 자동화는 어떻게 할 것인가?자원의 여유가 있는 호스트를 찾고 그 호스트에 컨테이너를 적절하게 배포해야함컨테이너에 문제가 생기면 버리고 새로 생성해주어야 함트레픽의 양에 따라 컨테이너의 양을 자동으로 조절해주어야 함등등등 이런 문제점을..

Why container ?호스트 OS에 프로세스로 배포를 하면 하나의 프로세스의 죽음이 다른 프로세스의 죽음으로 이어질 수 있다.같은 자원을 격리없이 공유하고 사용하기 때문에. 이를 위해 가상화 머신이 등장했고 네임스페이스 등으로 자원을 격리해 어플리케이션을 분리시켰다.하지만 가상 머신에는 GuestOS가 설치돼야 했고, 이는 머신을 무겁게 해 가볍게 사용할 수 없었다.이를 리눅스의 프로세스 격리기술인 컨테이너를 통해서 해결했다.컨테이너 기술의 핵심은 HostOS의 커널을 컨테이너 프로세스로 자원을 분할해 주는 Container Runtime 이다.대표적으로 도커가 컨테이너 런타임이다.컨테이너 기본 구조장점인프라를 의식하지 않고 경량의 컨테이너를 빠르게 수정/삭제/생성/배포 할 수 있다.이미지 기반으로..

DevOps란?백엔드 개발과 프론트 개발을 모두 한다고 데브옵스 개발자는 절대 아니다.나만의 정의DevOps는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있는 역량을 향상시키는 문화, 철학, 방식 및 도구를 아우르는 단어이다. 즉 Business Agility 를 확보하기 위함이며 이는 MSA 가 추구하는 지향점을 DevOps가 함께 바라보고 있다는 것이라고 생각한다.영역Product ( Tool / Service )버전 관리컨테이너자동화된 인프라 (Infrastructure as Code )CI/CDProcessAgilePeople / Organization개발 내재화독립적인 팀개발 팀과 운영 팀의 협력CNCF ( Cloud Native Computing Foundation )CNCF 는 DevOp..

API First Desgin 은 MSA 설계를 진행하며 서비스를 어떤 기준으로 나눌 것인가? 에서 시작해 각 서비스들이 어떤 기능을 제공할 수 있고, 서비스의 제공 API에 따라 크기나 트랜젝션 범위를 설정할 수 있기 때문에 API를 우선적으로 디자인 하라는 MSA 모델링 관점에서 중요한 내용이다.API First Design이란?협업하는 개발 프로세스에서 API를 첫 번째 우선 순위로 가져가는 것 좋은 설계를 하기 위해서는 개발 팀의 아키텍처를 지속적으로 살펴야하며 클린코드를 짜는 것에 집중해야 한다.릴리즈가 반복될 수록 코드의 양이 많이지고, API의 수도 늘어난다.이 상황에서 클라이언트도 늘어난다면 우리는 더 많은 API를 필요로하게 된다.그렇기 때문에 서비스를 운영하면서 변경 사항이 생기고 백로..

Q. 서비스를 어떻게 나누었나?기획 단계에서 유저 스토리를 작성했습니다.사용자가 무엇을 원하는지에 대한 요구사항서를 작성한 것인데 이에 따라 스토리 보드를 그려가며 모놀리딕한 형식으로 서비스 플로우를 구성했습니다.이슈 넘버로 기능을 명시했고 플로우가 끊기는 부분으로 덩치를 나누었습니다. 이 과정을 통해 저희 팀은 후보 서비스 도출을 진행했습니다. 해당 플로우를 바탕으로 와이어프레임을 제작했습니다. 와이어 프레임을 제작해나가면서 사용자 관점에서 어플리케이션을 사용할 때 서비스 레벨로 분리되는 부분들이 보였습니다. 분리 기준은 한 서비스의 장애에 있어서 독립적으로 운용이 가능한가? 서비스 간 분산 트렌젝션을 진행할 때 데이터간 일관성/정합성에 큰 무리가 가지 않는가? 로 정했습니다.도메인 친화적으로 서비스 ..

Top - Down Approach설계의 목적과 분석부터 시작한다.Discover 단계MSA 설계와 프로토타이핑을 진행한다.Delivery 단계API 설계어플리케이션 분산 설계마이크로 서비스 개발CI/CD 테스트마이크로 서비스 테스트CI/CD를 제외한 4가지를 반복적으로 진행한다.Bottom-Up Approach일반적인 회사에서는 이 방식을 사용한다.현행 시스템에 대한 분석부터 시작한다.Delivery 단계API 설계어플리케이션 분산 설계마이크로 서비스 개발 -> 기존 서비스 리팩토링 단계CI/CD 테스트마이크로 서비스 테스트DevOps 단계 추가서비스 모델링분석후보 서비스 도출비지니스 도메인 분석을 통한 후보 서비스 식별후보 서비스 평가 항목신속하고 독립적인 배포가 가능한가?트랜잭션의 폭증에 스케일 아..

MSA의 정의MSA를 정의하는 방법은 여러가지 관점이 존재한다.서비스 크기별로 정의할 수도 있고 운영 방식으로도 정의할 수 있고 데이터 참조 관계로도 정의할 수 있다.서비스 크기별로는 하나의 프로젝트로 관리되는 기존 모놀리딕 방식의 서비스를 독립적으로 확장/배포가 가능한 마이크로 서비스로 분해해 운영하는 것이 MSA다 라고 할 수 있다.운영 방식으로는 각 회사의 부서별로 서비스를 담당하며 여러 서비스들과 통신과 데이터 관리를 진행하는데 각 서비스는 독립적으로 진행된다. 예로 결제 서비스가 다운됐다 하더라도 회원가입 서비스는 진행 가능한 것처럼. 이런 식으로 운영을 서비스별로 잘게 나눠서 아키텍처를 구성하는 것이 MSA라고 할 수 있다.데이터 참조 관계로는 복잡한 하나의 큰 데이터 베이스에서 각 테이블별로..