[SAA] 마이크로서비스 아키텍처

Micro Services architecture

• 마이크로 서비스 아키텍처로 전환하고 싶을 때
• 많은 서비스가 REST API를 통해 상호작용하며 서로 소통하는데 REST API를 사용
• 마이크로 서비스의 아키텍처는 모습과 형태가 달라 뭐든 원하는대로 할 수 있음
• 서비스 개발 수명 주기를 줄이고자 마이크로 서비스를 사용
• 각 서비스가 독립적으로 확장하며 코드 레포지토리를 갖추길 원한다면 마이크로 서비스 아키텍처를 사용

Micro Services Environment

• 마이크로 서비스는 보통 DNS 이름이나 URL이 있음
• 예) service1.example.com
  사용자는 첫 마이크로 서비스와 HTTPS를 통해 통신하며 Elastic Load Balancer가 ECS와 통신하고 난 뒤 DynamoDB와 통신
  정보를 얻으려면 DNS 쿼리를 Route 53에 보내 별칭 레코드를 받고 나서 서비스와 상호작용이 가능
• 예) service2.example.com
  사용자가 두 번째 마이크로 서비스를 마련하려면 전형적인 서버리스 용 아키텍처를 사용해 Lambda와 ElastiCache를 사용
  두 번째 마이크로 서비스의 람다 함수가 첫 번째 마이크로 서비스의 Elastic Load Balancing에 호출을 보내 상호작용 가능
  이를 통해 첫 마이크로 서비스에서 정보를 얻고 응답을 생성
• 예) service3.example.com
  사용자는 ELB를 사용하는 세 번째 마이크로 서비스를 마련하기 위해 서버리스가 아닌 EC2 오토 스케일링과 RDS 사용
  EC2 인스턴스가 결정을 내리기 전에 두 번째 마이크로 서비스를 호출
  
  

  

Discussions on Micro Services

• 마이크로 서비스에는 두 가지 패턴이 존재

1. 동기식 패턴
   다른 마이크로 서비스를 명시적으로 호출
   예) API Gateway와 로드 밸런서는 다른 마이크로 서비스에 HTTPS 호출을 보내기 적합
2. 비동기식 패턴
   SQS에 메시지를 남기지만 응답을 언제 받을지, 내용이 뭔지, 무슨 일이 일어날지 개의치 않는 것
   예) S3처럼 SQS, Kinesis, SNS Lambda에 트리거로 작용

• 마이크로 서비스의 문제는 새로운 마이크로 서비스를 생성할 때마다 오버헤드가 발생함
  이로 인해 서버 밀도나 사용률을 최적화하는데 어려움을 겪기도 하며
  여러 버전의 마이크로 서비스를 동시에 가동하려면 복잡
  또한, 여러 서비스와 통합하려다 클라이언트 코드 요구사항이 급증하기도 함
  이러한 문제를 서버리스 패턴으로 어느정도 해결 가능
  예1) API Gateway나 Lambda를 이용해 자동으로 확장한 후, 사용량만큼 돈을 지불
  예2) API Gateway에서 API를 쉽게 복제하고 재생산하여 API Gateway를 위한 Swagger 통합으로 클라이언트 SDK 생성