AWS로 컨테이너 기반의 마이크로서비스 운영하기 + 실습

AWS 기반 마이크로 서비스 

 https://events-aws.qwiklabs.com/live

들어가서 로그인 해서 만들면 됩니다.

시작하여 event-aws.qwikilabs.com 모습이다

이게 개요이다. ->  

Docker를 배웠다는 가정하레 바로 MicroService가 뭔지 배운다.

마이크로 서비스가 좋은지 어떤 관점에서 좋은지 배운다.

얼굴 사진을 업로드하면 얼굴 형태를 인식해서 얼굴 인중에 mustache 붙여준다  이걸 예시로 보여줬다.(Web Server)

옛날에는 거대한 하나라는 모놀리스 어플리케이션을 구축했습니다.

정보시스템이 발전하면서 올인원  이렇게 종합된 형태로 구축을 했습니다. 

복잡성 제어가 불가능해집니다.. -> exponential -> 그래서 마이크로 서비스가 나왔습니다.

변경을 하나를 해야하면 모든 전체를 테스트해야 합니다.

마이크로 서비스는 독립적으로 작동한다.-> 선형

마이크로 서비스 정의입니다. 여러 서비스가 네트워크를 통해 서로 교신하여 목표를 달성합니다.

각 서비스를 독자접으로 업데이트 또는 교체 할 수 있지만 애플리케이션에는 영향을 미치지 않습니다.

그리고 각 서비스는 서로의 API를 통해 교신합니다.

제일 큰 이점은 독자적으로 서비스를 확장할 수 있다. 

각각 기능을 분리하고 데이터 저장소를 각자 가지고있다. -> 중복되는 데이터가 생겨난다(기존과 다르게) -> 중복을 허용하되 서로서로 싱크를 맞춰주는 걸로 합니다.

마이크로 서비스를 통해 고객의 소리를 듣고 빠르게 구현할 수 있습니다. 

모놀리스를 분해하고, 애플ㄹ케이션을 다른 방식으로 재구성할 수 있습니다.

구조를 보면 일단 DataStore을 가지고있어야 합니다. 여러가지 저장 서비스 중에 아무거나 쓰면 됩니다.

그리고 돌아갈 Application이 있어야 합니다. 

마지막으로 API가 필요합니다. API는 세상과의 계약이라고 합니다. API를 통해 이 Application을 호출하는 것입니다.

외부와의 계약 

마이크로 서비스는 공유 데이타가 스토어가 없으므로 소트프웨어 결합을 방지할 수 있습니다. 

남이 어떻게 만들었는지 관심없고 api로 공표하여 실행하면 된다.

마이크로 서비스로 통해 독자적으로 존재합니다.

실제 Amazon도 여러가지 마이크로 서비스로 존재합니다.

사용자 입장에서 응축된 존재로 있어서 상관없습니다.

뒤에서 보면 매우 더럽습니다.

아마존은 수천개의 팀이 각자의 마이크로 서비스 아키텍쳐를 만들어서 지속적으로 배포합니다. 1년 5천만번를 배포하합니다. 엄청 빨리 배포한다고 보면 됩니다.

MicroService를 운영할 때는 원칙이 있습니다.

1. -> PUBLIC API에 의존한다 서로의 PUBLIC API로만 통신을 한다고 보면됩니다.

퍼블릭 API끼리 사용을 합니다.

위에 보시다시피 바로 DB에 접근하는 건 허용 안됩니다. 퍼블릭 API를 사용해야 합니다. 다른 의미로 또 안되는 이유가 자신의 서비스 내에 데이터를 복제해야 할 수도 있습니다. 왜냐하면 공유 DB가 아니기 때문입니다.

일관성이라고 생각하면 됩니다.

퍼블릭 API는 마이크로 서비스와 클라이언트 간의 계약이므로, 일단 배포되면 클라이언트가 해당 서비스에 의존하는 한 유지되어야 합니다.

그래서 모든 API를 하위 호환 방식으로 보유해야합니다.

퍼블

해당 작업에 적합한 도구를 사용합니다. 일단 각 서비스는 자체 데이터 스토어를 보유하고 있기 때문에 그에 맞게 적당한 도구를 사용해야 겠죠?

각자 필요하게 예로 들면 AMazon ES를 추가하거나 DynamoDB를 추가하면 됩니다.

아니면 예로들 면 Micro Serivce B는 자바 프레임워크를 설치하면 됩니다. 

아니면 다른 언어 프레임워크를 쓰면 됩니다.

마이크로 서비스끼리 통신을 할때 권한 부여 , 인증 등등 여러가지를 해야합니다. e.g. S3, Vault, Keywhiz

필요할 때 써줘야한다.

모니터링 추척 해줘야한다. 클라이언트에게 어떤 형태의 서비스 수준 예상치를 제공하려면 가시성, 모니터링(통찰)이 필요합니다.

항상 무엇이든 혁신적인 변화이어야 합니다.

팀 간 커뮤니케이션에 관한 것입니다.

소프트웨어 아키텍처뿐 아니라 소프트웨어 팀을 조직하는 방식까지 바꿔야 한다는 것을 뜻합니다.

자동화된 테스트도 해야한다고 합니다.

아니면 시간이 쌓인다고 합니다.

그래서 왜 Docker가 나왔냐 방금까지 말한 이유랑 관련이 있습니다.

먼저 컨테이너가 뭐인지 봐야합니다. 컨테이너는 Linux Kenrel의 몇 가지 구성 요소를 활용하여 프로세스를 격리합니다. 이중 가장 중요한 기능은 croups와 namespace입니다. 이 둘을 활용하여 격리를 제공하며, 이를 통해 궁극적으로 프로세스가 컨테니어 내부에서 실행되는 것만 인식하고 실제 호스트상에 무엇이 실행되고 있는지 알지 못하게 합니다.

Cgroups? ==>

리소스 제한 및 할당, 프로세스 우선순위 및 프로세스 어카운팅 등과 같은 작업을 처리하고 네임스페이스는 프로세스, 파일 시스템 탑재, 사용자 ID등의 격리를 처리함으로써 완벽한 격리를 제공합니다.

가상 머신과 비슷하겠지만 가장 큰 차이점은 하이퍼바이저가 필요 없다는 것입니다. 컨테이너는 적절한 Kernel 기능이 지원되고 Docker 데몬이 있는 어떤 linux 시스템에서나 실행 할 수 있습니다. 이러한 특성으로 컨테이너는 휴대성이 매우 뛰어납니다. 노트북, VM, EC2 인스턴스 및 베어 메탈 서버 어디에든 호스팅할 수 있습니다. 하이퍼바이저가 필요 없다는 것 성능 오버헤드가 거의 발생하지 않는 다는 뜻입니다. 프로세스가 kernel과 직접 통신하며, 대체로 컨테이너 사일로에 대해서는 인식하지 못합니다.

Docker는 컨테이너 기술과 동의어 입니다. 도커는 전체 플랫폼을 제공하며,  docker run과 docker ps의 명령어로 컨테이너를 관리하거나 시작할 수 있습니다. 

\\

Docker 이미지는 파일 모음입니다.

기본 이미지(ubuntu,frdorea) 위에 자체 사용자 정의 이미지를 구축하게 됩니다. 

이미지는 계층을 이룹니다. 

Docker과 rootfs를 탑재하면 기존 Linux boot처럼 읽기 전용으로 시작합니다. 

각 docker 이미지는 실제로는 이미지 스택입니다. 

LXC= 여러 개의 격리된 Linux 시스템을 싱해나는 Linux Container, Linux Kernel은 가상머신을 시작할 필요가 없는 리소스 격리(CPU,메모리,블록 I/O, 네트워크 등)를 위한 cgroups를 구성합니다.

Aufs 여러 디렉토리를 통합하여 병합된 단일 디렉터리를 제공하는 스택 가능한 통합 파일 시스템(Unionfs)

Brtfs B- 트리 파일 시스템 =GPL 라이선스가 있는 Linux용 COW 파일 시스템

Docker 파일에서 샐행하는 각 명령 또는 추구하는 각 유틸리니틑 고유한 계층을 생서합니다. docker image를 생성합니다.

여러가지로 Docker를 실행할 수 있습니다. Docker가 MicroService와 관련시켜보겠습니다.  Docker Container는 독립형이고 외부 종속성 없이 구축되어있습니다. Linux 에서 실행된다면, Docker에서 실행되는 것이다 라는 말은 프로그래밍 언어를 비롯하여 많은 기술적 선택의 자유를 줍니다. 즉 MicroSerivce에 적합하다고 할수 있습니다.

그래서 나온게 Amazon Container Service입니다.

특징은보시다시피 좋습니다.

Docker는 좋은 도구이지만 수백 개의 컨테이너를 확장하는 일은 쉽지 않습니다. 클러스터를 관리는 어렵습니다. 왜냐면 시스템의 모든 상태를 알아야 합니다.  이럴 때 필요한 Amazon Container Service입니다.

이런 문제들을 해결해주는게 Amazon Container Service입니다.

컨테이너를 사용하면 전체 상태에 대한 프로그래밍 방식 액세스를 제공하고 애플리케이션 요구 사항에 따라 컨테이너의 일정을 수립할 수 있으므로 클러스터 관리자나 구성관시리 시스템을 실행하고 관리할 필요가 없습니다.

맞춰서 자원(컨테이너)를 물리적인 하드웨어에 넣어줍니다 

ECS를 통해 리소스 필요와 가용성 요구 사항 간에 균형을 유지하는데 도움이 되도록 컨테이너의 일정을 예약합니다. 

API를 통해 손쉽게 통합 또는 확장할 수 있습니다.

이 회사들의 배포 프로세스에 연결 될수 있습니다.

확장성이 뛰어난 서비스를 가져서 컨테이너 수십만 개의 일정을 잡을 수 있다.

이렇게 마이크로 서비스에 최적의 조합인 ECS에 대해 알수잇습니다. Docker Container가 실행될 클러스터를 생성할 수 있습니다.

이 클러스터는 AWS에서 관리하므로, 사용자는 리소스 할당, 가용성 또는 컨테이너 배치에 대해 걱정할 필요 없습니다.

확장도 쉽게 되고 

로드 밸런싱이 통합되어 있으며 , ECS에서 시간이 많이 소요되는 획일적인 작업을 처리하므로, 사용자는 서비스와 제품에 집중할 수 있습니다.

실습

클라우드 포메이션 들어가면 이 ㄱ스택이 보인다 여기서 2번째 꺼를 선택한다

output에서 publicdnsname을 받는다

그리고 인스턴스에 연결을한다

현재 Dockerfile에서 Docker 이미지를 구축합니다. 마지막에 점을 주의해야 합니다.

그러면 막 뭐가 만들어집니다.

여기서 -p는 컨테이너의 8000번 포트를 호스트상의 8000번 포트에 결합한다는 뜻입니다.

-d 는  백그라운드에서 돌린다는 말입니다.

ec2의 인스턴스의 dns 이름을 복사하여 브라우저의 주소 막대에 붙여넣기만 하면 됩니다. 그러면 저 웹서비스가 보입니다. 왜냐면 가동이 됬거든요.

컨테이너 중지를 해봅니다.

---

---

소스 디렉토리로 이동합니다

docker-compose를 하면 3개를 동시에 킬수있다고 한다.

ps를 보면 이렇게 3개가 뜹니다. 3개의 docker가 실행됬다고 알수있습니다.

이렇게 웹서버도 가동 된걸 알수있습니다.

이렇게 3개의 docker가 꺼집니다.

2번째것도 push 해줍니다

info 도 한 결과입니다.