# 2022년도 3일 밖에 남지 않았습니다. Red Hat Developer (developers.redhat.com)에서 2022년 올 한해 가장 인기 있었던 기사들을 게재합니다. # Rank#2. 마이크로서비스를 위한 5가지 설계 원칙 모놀리식(Monolithic) 애플리케이션(이하 'App')의 단점을 해결하기 위해 마이크로서비스가 점차 대중화되고 있습니다. 1. 모놀리식 App이란? 모놀리식은 하나의 기능을 변경할 때 App의 다른 부분도 다시 코딩하지 않고는 하기 어려운 긴밀하게 통합된 App 아키텍처를 의미합니다. 모놀리식 App의 구성 요소는 여러 시스템에 분산될 수 있지만 여전히 서로에 대한 의존도가 높습니다. 새 기능을 추가하면 코드 전체에 파급 효과가 있을 뿐만 아니라 변경 사항을 배포하려면 전체 App을 다시 테스트하고 다시 배포해야 합니다. 이러한 업그레이드는 특히 App에 수십만 또는 수백만 명의 사용자가 있는 경우 노동 집약적이고 위험할 수 있습니다. IT 부서가 6개월마다 소프트웨어를 릴리스할 수 있는 사치를 누렸을 때 이러한 유형의 업그레이드 프로세스는 견딜 수 있었습니다. 그러나 현대 비즈니스에서는 매주, 매일 또는 더 자주 강제 릴리스를 요구하므로 모놀리식 App을 업그레이드하는 데 내재된 노동력과 위험을 견딜 수 없게 됩니다. 무언가가 바뀌어야 합니다. 그 변화가 마이크로서비스 지향(Oriented) App(MOA)으로의 전환입니다. 2. MOA이란 무엇입니까? MOA는 논리를 느슨하게 결합된 방식으로 여러 컴퓨팅 장치에 분산되는 잘 캡슐화된 작은 서비스로 나눕니다. 각 서비스는 네트워크의 고유한 IP 주소가 부여되며 개발언어에 구애받지 않는 공용 인터페이스를 노출합니다. 가장 널리 사용되는 언어 불가지론적(agnostic) 인터페이스 유형은 REST API이지만 통신을 위한 다른 모델도 있습니다. 또한 마이크로서비스는 일반적으로 컨테이너로 기동되어 배포됩니다. 각 마이크로 서비스는 잘 캡슐화되어 있으므로 부작용을 최소화하면서 코드를 빠르게 업데이트할 수 있습니다. 이를 통해 유지 관리가 더 쉬워지고 확장 속도가 빨라집니다. 3. 마이크로서비스를 위한 5가지 설계 원칙 MOA의 이점은 상당할 수 있지만 대가가 따릅니다. MOA를 효과적으로 구현하려면 마이크로서비스 설계에 대해 알아야 합니다. 마이크로서비스 애플리케이션은 다음 다섯 가지 원칙을 따라야 합니다. 1) 하나의 관심(Single concern) 2) 명확한 독립체(Discrete) 3) 이동 가능(Transportable) 4) 자체 데이터 전달(Carries its own data) 5) 본질적으로 일시적(Inherently ephemeral) 각 원칙의 세부 사항을 살펴보겠습니다. 1) 하나의 관심 Single concern이란 마이크로 서비스가 한 가지만 수행해야 한다는 것을 의미합니다. 예를 들어 마이크로 서비스가 인증을 지원하려는 경우 인증만 수행해야 합니다. 이는 해당 인터페이스가 인증과 관련된 액세스 포인트만 노출해야 함을 의미합니다. 그리고 내부적으로 마이크로 서비스에는 인증 동작만 있어야 합니다. 예를 들어, 인증 응답에서 직원 연락처 정보를 제공하는 것과 같은 부수적 동작이 없어야 합니다. Single concern만 있으면 마이크로 서비스를 더 쉽게 유지 관리하고 확장할 수 있습니다. 2) 명확한 독립체 마이크로서비스는 환경과 명확한 경계를 구분해야 합니다. 이 원칙에 대해 생각하는 또 다른 방법은 마이크로서비스가 잘 캡슐화되어야 한다는 것입니다. 이는 마이크로 서비스의 Single concern과 관련된 모든 논리 및 데이터가 단일 배포 단위로 캡슐화되어야 함을 의미합니다. 개별 배포를 위한 단위의 예로는 Linux 컨테이너, WebAssembly 바이너리, .NET DLL, Node.js 패키지 및 Java JAR 파일 등이 있습니다. 또한 별도의 마이크로서비스는 별개의 소스 제어 리포지토리에서 호스팅되며 자체 CI/CD(지속적인 통합/지속적인 제공) 프로세스의 적용을 받습니다. 마이크로서비스는 배포 후 더 큰 애플리케이션의 일부가 됩니다. 그러나 개발에서 테스트, 릴리스에 이르기까지 각 마이크로 서비스는 다른 모든 마이크로 서비스와 격리됩니다. 마이크로서비스가 분리되면 쉽게 이동할 수 있습니다. 3) 이동 가능한 마이크로서비스 이동 가능한 마이크로서비스는 약간의 노력으로 한 런타임 환경에서 다른 런타임 환경으로 이동할 수 있습니다. 아마도 현재 이동 가능한 마이크로서비스의 최적 형태는 Linux 컨테이너 이미지일 것입니다. 일반적으로 Linux 컨테이너 이미지는 Red Hat Quay.io와 같은 이미지 리포지토리에서 호스팅됩니다. 컨테이너 이미지는 해당 이미지 리포지토리의 모든 대상을 대상으로 지정할 수 있으므로 다양한 애플리케이션에서 이미지를 사용할 수 있습니다. 이는 마이크로서비스가 모든 대상으로 전송될 수 있는 개별 배포 단위로 캡슐화되기 때문에 가능합니다. 캡슐화는 구성 및 배포를 제외한 모든 작업을 개발자로부터 분리합니다. 이 전송 가능한 기능은 또한 자동화된 또는 선언적 배포 프로세스에서 마이크로서비스를 더 쉽게 사용할 수 있도록 합니다. 4) 자체 데이터 전달 마이크로 서비스에는 다른 모든 마이크로 서비스와 격리된 자체 데이터 스토리지 메커니즘이 있어야 합니다. 다른 마이크로 서비스와 데이터를 공유할 수 있는 유일한 방법은 마이크로 서비스가 게시하는 공용 인터페이스를 이용하는 것입니다. 이 원칙은 데이터 공유에 몇 가지 원칙을 부과합니다. 예를 들어 각 마이크로 서비스에서 사용하는 특정 데이터 스키마는 잘 문서화되어야 합니다. 5) 본질적으로 일시적 마이크로서비스가 일시적이라는 원칙은 대상에 대해 필요에 따라 부작용 없이 쉽고 빠르게 만들고, 파괴하고, 보충할 수 있음을 의미합니다. 표준 운영에 대한 기대치는 때때로 발생하는 시스템 오류 또는 확장 요구로 인해 마이크로서비스가 항상 나타났다 사라지는 것입니다. 이 시나리오는 확장 수요를 수용하기 위해 HPA(Horizontal Pod Autoscaler)를 사용하는 Kubernetes 환경에서 일반적입니다. HPA는 순간적인 요구에 따라 컨테이너를 생성하고 파괴합니다. 컨테이너가 생성될 때마다 IP 주소가 동적으로 할당됩니다. 포트 번호가 동적으로 할당되는 상황도 있습니다. 이것이 임시(ephemeral) 컴퓨팅의 영향입니다. 보다 상세한 내용은 아래 링크를 참고하십시요. 감사합니다.