• [ 배경 ]
    • 2023년에도 마찬가지로 재직중인 회사의 사내에서 aws 솔루션 아키텍트 분들이 오셔서 AWS ECS 관련 필요성과 사용법, 실습등의 강의를 진행해주셨다.
    • 가상화의 필요성과 서버를 클라우드에 배포할때 서버 개수가 적다면 ECS나 EKS같은 서비스는 필요 없을 것이다. 하지만 내가 담당하고 있는 서버는 글로벌을 타겟으로 하고,  주기적인 업데이트와, 트래픽이 들쭉날쭉한 서비스여서 운영시 유동적인 변화에 대응해야 했다.
    • 그리하여 아키텍처 패턴, 운영모델, 소프트웨어 딜리버리에 대해 고민하게 되었고 해당 강의를 수강하게 되었다.

  • [ 과정 ] 
    • 마이크로 서비스 아키텍처의필요성에 대해 먼저 이해가 필요하였다.

  • 운영해야할 컴포넌트들이 많고 복잡해진다면 Compute, Databases, Storage, Messaging, Analytics 등의 layer에서 수정이 일어날때마다 의존성이 결합될 확률이 높아진다. 
  • 따라서 고가용성, 비용, 인프라 관리, 트래픽 부하 관리 등을 위해서 Micro Service Architurce 도입은 선택이 아닌 필수이다.

  • 하지만, 마이크로 서비스 아키텍처로 개발한다면 필연적으로 서비스가 많아질 수 밖에 없는데 빌드, 테스트, 배포, 모니터링의 레이어를 구분하며 각각 운영하다 보면 곤란한 상황이 생긴다.
  • 위의 곤란한 문제 상황을 해결하기 위한 방법으로는
    • SW 단위의 배포
    • Lightweight, portable, consistent
    • 어디든 배포하고 실행 가능
    • 무엇이든 배포하고 실행 가능
    • 운영과 개발간의 일관성

  • 즉, 가상화 컨테이너 기술로 환경을 격리시켜 일관성을 유지하면 된다.
    • 재사용성
    • 가벼운 가상화 기술
    • 높은 이식성
    • 효율적인 리소스 사용
    • 개발 생산성 향상
  • 하지만 컨테이너 대수가 많아진다면 운영자가 실수할 수도 있고 그외에도 아래와 같은 문제가 발생할 수 있다.
    • 컨테이너를 호스트에 어떻게 배포하지?
    • 컨테이너 내부/외부 통신은 어떻게 하지?
    • 시크릿 관리는 어떻게 하지?
    • 컴퓨팅 자원 풀을 최적화 할 수 있는 방법은 무엇일까?
    • 컨테이너의 생명 주기를 어떻게 관리하지?
    • 무중단, 블루/그린 배포는 어떻게 할 수 있을까?
  • 그리하여 나온 개념이 컨테이너 오케스트레이션 이다. aws에선 대표적으로 ecs, eks 서비스가 있다.

  • 실습에서 배운 최종적인 아키텍처는 아래와 같다.


[ 결과 ]

  • 컨테이너 필요성 탐구
  • Amazon ECS 구조 및 필요성 탐구
  • Amazon ECS 네트워킹 및 모니터링 방법 탐구
  • Amazon ECS Service Task 배포 전략 탐구
  • 관리 업무로 인한 오버헤드 경감 & 필요한 만큼만 지불 & 쉬운 연동

+ Recent posts