클라우드 인프라와 MSA의 관계

비즈니스 Agility

비지니스 애자일리티(Business Agility): 기업이 민첩하고 유연하게 변화에 대응하고 새로운 기회를 채택하며 경쟁력을 유지하거나 향상시키기 위한 능력

• 변화된 비즈니스 환경에 민첩하게 대응하기 위해서는 자주 서비스 변경이 일어나야 한다.
• = IT 시스템 배포 속도가 비즈니스 변화 속도라고 볼 수 있다

그렇다면? 배포를 빈번하고 빠르게 할 수 있는 능력은 어떻게 가질 수 있는가? 답은 클라우드 인프라와 관계가 있다.

 

클라우드 인프라의 등장

• 과거의 인프라 구축은 많은 시간이 소요 됐다.
  • 서버실 공사 -> 서버 장비 구입 -> 운영체제, SW 설치 등등
• 클라우드 인프라
  • 원하는 만큼, 필요한 시점에 제공 되는 컴퓨팅 서비스
  • 사용자는 별도의 서버실 공사 없이, 그냥 사용한 만큼만 비용을 지불하면 된다!
  • 원하는 시점에 서버를 증설할 수도, 사용하지 않는 서버는 편하게 없앨 수도 있다.

 

---

 

클라우드 인프라와 MSA

• 이처럼 클라우드 인프라의 등장으로 리소스를 편하게 증가 시킬 수 있는 환경이 갖춰졌다.
• 리소스 증가가 필요할 때 사용자가 몰리는 기능과, 몰리지 않는 기능을 구분하지 않고 전체 리소스를 한번에 모두 증가시키는 것은 효율적이지 않다.
• 전체 시스템을 한꺼번에 확장하는 것보다, 사용량이 몰리는 일부 기능의 리소스만 변경되게 하는 것이 효율적이다.
• 그렇게 하기 위해선 시스템을 한 덩어리가 아니라 일부만 변경될 수 있도록 조각 조각으로 구성해야 한다.

 

수직확장과 수평확장

수직확장 : 스케일업
수평확장 : 스케일아웃

 

모노리스 시스템

• 한 덩어리로 구성된 시스템 -> 앞서 말했듯이 클라우드 인프라에서 사용하기에는 적합하지 않다.
• 변경 시 전체 배포가 필요하고, 하나가 실패하면 전체 시스템이 실패된다. 그리고 확장할 때도 전체를 확장해야 한다.
• 장점 : 어플리케이션 쉽게 변경 가능. 작은 규모의 프로젝트에는 적합

 

 

 

마이크로 서비스

• 클라우드 네이티브 어플리케이션
• 수평 확장을 위한 가장 효율적인 시스템 유형
• SOA를 극대화 시킨 아키텍쳐
• 독립적으로 수정, 배포, 확장이 가능한 시스템
• 실패하더라도 전체의 실패로 이어지지 않는다.
• 데이터 저장소 분리

 

마이크로 서비스 성공을 위한 조건 + 콘웨이법칙

• 특정 도메인에 자율적인 권한과 책임을 지는 DevOps 조직
• 클라우드 인프라
• CI/CD 자동화
• 에자일 프로세스
• 사후 부검 : 장애 발생 시, 누군가를 비난하는 문화가 아니라 프로세스적인/자동화적으로 개선할 점을 찾는 방식으로 분석이 필요하다.

콘웨이법칙

• 시스템 구조는 설계하는 조직의 커뮤니케이션 구조와 닮는다.
• 아키텍처만 변화하는 것이 아니라 프로세스, 조직, 역량, 개발 문화가 변화 되어야 함

 

마이크로 서비스는 만병 통치약인가?

NO SILVER BULLET : 은 총알은 없다

• 아키텍쳐는 정답이 없는 분야
  • 컨테이너, 쿠버네티스를 사용하면 MSA를 하는 것인가?
  • 클라우드 인프라 위에는 무조건 마이크로 서비스가 올라가야 하는가?
  • 마이크로 서비스로 구축하면 시스템이 유연해지고 확장성이 높아질까?
• 안정성이 중요하고, 트랜잭션이 중요한 서비스라면 모노리스가 더 좋을 수도 있다
  • 각각의 인스턴스가 나눠져 있기 때문에 분산 트랜잭션이 필요하고
  • 인스턴스끼리 API 통신이 필수적이기 때문에 이때 네트워크 비용이 발생한다. 네트워크 레이턴시는 제로가 아님을 명심하자
  • 굳이 MSA까지 안가더라도, 어느정도 확장성/배포성을 확보할 수 있다는 점을 명심하자

 

마이크로 서비스 단점

• 마이크로 서비스는 고도의 디커플링을 요구한다. 재사용은 커플링을 유발하기 때문에, 재사용보다는 코드의 중복을 선택한다
• 잦은 네트워크 호출이 필요해 성능이 좋은편은 아니다. 보안 처리, 분산트랜잭션 등 개발 난이도와 복잡성이 높아진다
• 저장소의 완벽한 격리가 필요하다. 통합 데이터 모델링 사상과 상충되며, 데이터 중복/복제가 고려되어야 한다.

 

(예시) 클라우드 인프라에서 하나의 기능이 배포 되고 사용되는 과정

1. 소스를 GIT에 올린다
2. 소스코드가 올라가면 빌드 도구가 빌드를 수행한다
3. 컴파일이 되고, 테스트코드가 돌아가고, 패키징이 되고 .. 이러한 과정 후에 컨테이너라이징이 된다.
4. 컨테이너 이미지를 이미지 스토어에 업로드한다. (도커허브 같은)
5. 환경에 따라 환경 설정 파일을 가져와 배포한다.
6. 클라이언트가 서버를 호출한다.
7. 컨테이너는 수평 확장 되어 있을 수 있다. 그렇기 때문에 하나의 IP로 찾아가기 힘들다! 이때 라우터가 필요하다
8. 서비스디스커버리가 DNS 역할을 수행한다
9. 그 외에 인증/인가, 트레이싱 서비스, 로깅 서비스, 서킷 브레이커가 작동한다.

 

📋 결론

---

1. 클라우드 인프라의 등장으로 잦은 배포가 가능해졌다.
2. 잦은 배포는 서비스의 민첩도와 관련이 있다.
3. 잦은 배포 시 하나의 큰 서비스를 모두 배포하는 것은 비효율적이다. = 변경 사항이 있는 부분만 변경하는 것이 훨씬 빠르고 좋다
4. 또한 클라우드 인프라의 등장으로 편리한 리소스 증가가 가능해졌다.
5. 이때도 하나의 큰 서비스를 대상으로 리소스를 전체 증가시키는 것은 비효율적이다.
6. 마이크로 서비스로 서비스를 분리하자!
   • 클라우드 네이티브 어플리케이션
   • 데이터 저장소 분리
     • 각각의 마이크로 서비스는 API로 통신한다.
   • 수평 확장에 효율적
7. 하지만 마이크로 서비스가 만병 통치약은 아니다.
   • 하나의 서비스가 여러개의 작은 서비스로 나눠지면서 발생하는 문제들도 존재한다.
   • 그런 문제를 해결하기 위한 여러가지 패턴도 나오게 된다.
   • 안정성이 중요하고 데이터 정합성이 중요한 서비스라면 모노리스 서비스가 더 좋을 수도 있다.
   • 각각의 인스턴스가 나눠져 있기 때문에 분산 트랜잭션이 필요하고, API 통신에서 네트워크 레이턴시가 필연적으로 발생한다.
   • 마이크로 서비스는 고도의 디커플링을 요구한다. 코드의 재사용보다 코드의 중복을 선택하는 아키텍쳐다.

 

 

https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard

https://www.itbiznews.com/news/articleView.html?idxno=90150