1. 애자일 방법론
사용자마다 독립적인 환경에서 개발해도 모두 동일한 결과가 보장되며 성능을 보장하며 가용 리소스를 최대한 확보할 수 있는 인프라 환경 => 컨테이너 인프라 환경
2. 컨테이너 인프라 환경
컨테이너를 중심으로 한 인프라 환경
하나의 운영 체네 커널에서 다른 프로세스에 영향을 받지 않고 독립적으로 실행되는 상태
각 가상머신마다 독립적인 운영체제를 가지고 있는 방식과 달리 운영체제를 공유하고 있어 자원을 더 효율적으로 사용할 수 있다.
3. 모놀리식 vs 마이크로 서비스
모놀리식 아키텍처 (Monolithic Architecture)
하나의 어플리케이션에 여러 가지 기능을 가진 서비스들이 통합돼 있는 구조
모놀리식 아키텍처은 초기 구성이 용이하며 개발이 단순하며 코드 관리가 간편하지만
코드 규모가 점점 커지게 되고 운영을 유연하게 하지 못한다는 단점이 있다.
예를 들어 A , B, C 코드에서 A코드만 바꾸더라도 전체 코드 다 배포 해야한다.
또한 A코드만 개발하는 팀이여도 전체 코드를 다 가지고 있어야한다. (실제로 코드가 엄청나게 커지면 인텔리제이가 뻗을정도로 메모리를 많이먹는다고한다.)
개발 뿐만 아니라 서버 운영해서도 마찬가지다. A 서비스의 트래픽이 폭발적으로 늘어 서버를 증설해야하는 상황에서
B , C는 증설이 필요없는 상황이지만, 코드가 통합되어있어 같이 증설되어야한다. 뿐만 아니라 특정 서비스에서 에러가 날 경우 그 서비스뿐만 아니라 전체 장애로 이어질 가능성이 생긴다. (Out Of Memory, GC 등등)
마이크로서비스 아키텍처 (Micro Service Architecture : MSA)
하나의 큰 기능이 여러 가지의 독립적인 서비스들로 구성되어있는 구조
장점 : 서비스간 영향범위가 줄어들어 장애에 유연하게 대응이 가능하다.
특정 서비스만 확장하거나 축소할수있다. (Scale-In, Scale-out)
단점 : 어플리케이션 복잡성이 매우 높아진다.
네트워크간 호출횟수가 증가하며 어플리케이션 성능에 미칠수 있다.
(한 컴퍼넌트가 느려지거나 에러가 생기면 그 컴퍼턴트를 호출하는 컴퍼넌트에 그 장애가 전파되는 특징을 가진다.)
마이크로 서비스 아키텍처는 컨테이너 인프라 환경과 매우 궁합이 잘 맞는다.
컨테이너 인프라 환경에서는 각 서비스를 컨테이너 단위로 배포하고 확장할 수 있다.
3. 컨테이너 인프라 환경을 지원하는 도구
- 도커
어플리케이션을 컨테이너로 만들고 관리해주는 것을 도와주는 툴
도커로 어플리케이션을 실행하면 운영체제에 상관없이 어느 환경에서도 동일한 결과가 보장된다.
- 쿠버네티스
컨테이너의 자동배포와 배포된 컨테이너에 대한 동작 보증, 부하에 따른 동작 확장(스케일 인-아웃) 를 담당한다.
마이크로서비스 아키텍처에서 필요한 API 게이트웨이, 서비스 디스커버리, 이벤트 버스, 인증 등의 긴으을 제공하고 이를 내 외부 네트워크와 연결해준다.
- 젠킨스
CI(지속적인 통합), CD (지속적 배포)를 지원하는 툴
- 개발된 프로그램의 빌드, 테스트, 패키지화, 배포단계를 자동화 시켜 배포를 용이하게 해준다.
- 프로메테우스, 그라파나, 키바나 (Kibana)
모니터링을 위한 도구
마이크로서비스는 서비스가 파편화되어 모니터링의 복잡도가 올라가게 되는데 프로메테우스, 그라파나 팔라스 등을 이용하면 더 쉽게 모니터링을 지원할수 있다.
프로메테우스를 어플리케이션 actuator를 등록하면 어플리케이션으로 부터 상태 데이터를 지속적으로 수집하고, 그라파나를 이용하여 프로메테우스로 수집한 데이터를 시각화 할수 있다.
또한 ELK (Elastic Search, LogStash, Kibana)로 어플리케이션의 로그파일을 수집하고 검색하고 시각화 할수 있다.
이를 정리하면 다음과 같다.