21탄-7.AWS-버즈빌-EKS 활용한 마이크로 서비스
Devops팀 , 리워드 광고 플랫폼
<1> 버즈빌 서비스
<2> 레거시의 정의 ?
<3> 마이크로 서비스 아키텍처 도입
<4> 기존 구성의 문제점
<5> 2021년 10월 현재 버즈빌은?
<6> Istio-Service Mesh
<7> 레거시 애플리케이션의 현대화 방법
<8> 마이크로 서비스 아키텍처 도입을 위한 검토
<10> 개인 정리
<1> 버즈빌 서비스
리워드라는 도구로 광고주가 원하는 성과를 극대화하고, 퍼블리셔의 지면을 수익화할 수 있도록
돕는 보상형 광고 플랫폼
<2> 레거시의 정의 ?
새로운 기술이나 비즈니스 요구사항을 수용하기 힘든 것.
유지보수 비용이 높음.
<3> 마이크로 서비스 아키텍처 도입
1
현재 AWS 환경의 클라우드에서 서비스 중
쿠버 네티스 사용
서비스 메쉬인 ISTIO 활용하여 마이크로 서비스 간 인증, 로드밸런싱, 복잡한 트래픽 규칙 등을 관리
서비스 간 커뮤니케이션은? gRPC 사용 + potobuf를 통해 RPC를 미리 정의할 수 있다.
2
각 컴포넌트는 독립적으로 배포되고, 확장이 가능해야 한다.
예를 들어 광고 추천을 위해 타사로부터 사용자 이벤트를 받는 모듈이 있는데 자사 트래픽과 상관없이 이벤트가 폭증하는 경우.
이벤트 수집 기능이 마이크로 서비스로 개발되어 분리된 경우 전체 서비스가 아닌 이벤트 수집 서비스만 확장할 수 있게 된다.
3
특정 모듈의 장애가 전체로 전파되는 문제도 방지할 수 있다.
예를 들어 외부 광고 네트워크를 연동하는 서비스가 장애로 일시적으로 동작하지 않더라도, 장애 반경을 네트워크 광고로 한정하고
직접 운영하는 광고 서버는 동작하여 광고를 계속하여 송출할 수 있도록 할 수 있다. (방어 로직을 구현하기 쉽다)
<4> 기존 구성의 문제점
1
기존 구성
External ALB --------- Serivice A
---------- Service B ----------------Internal ALB -------------- Service C
부하는 CPU 모니터링하여 Auto Scaling Group으로 Scale out / in 하고 있다.
2
기존 구성 문제점?
마이크로 서비스가 추가할 때마다 서비스 디스커버리 , 오토스케일링 , 로드밸런서가 늘어나는 구조이다.
서비스별로 사용하는 서버가 틀려 각기 다른 Launch config를 관리해야 한다.
3
기존 구성 문제점 해결?
컨테이너로 배포
쿠버 네티스 도입
외부에서 유입은 인그레스로 서비스
내부 서비스들에 대한 디스커버리나 로드밸런싱도 서비스 사용한다.
디플 리카로 쉽게 배포 가능
여유공간이 있는 노드에 알아서 스케쥴링되고 배포된다.
4
쿠버 네티스 단점
클러스터 관리에 드는 운영 코스트가 존재한다.
초기 kops 사용했지만 관리 이슈
특히 버전 업그레이드마다 마스터 그룹 롤링 시 크고 작은 이슈가 발생했다.
etcd major 버전이 2-> 3으로 올라가는 등의 변화가 있을 때엔 주의가 필요했다.
5
쿠버 네티스 단점 해결?
EKS로 전환함.
컨트롤 플래인이 완전 자동화되는 장점.
콘솔에서 클릭만 하면 컨트롤 플레인의 버전이 자동으로 올라간다.
1.18 이후에는 server-side apply 기능이 추가되면서 kube-proxy , VPC CNI, Core DNS 등이 애드온 관리된다.
관리형 서비스 도입으로 운영 코스트를 줄이는 게 중요하다!!!
<5> 2021년 10월 현재 버즈빌은?
프로비저닝? 테라폼으로 EKS 관리하고 있다.
스케일링? SPot 활용으로 비용 절감함.
로그? fluentd -> s3 , firehose, 빠르게 로그를 조회하기 위해 Loki stack 사용, redshift
모니터링? 그라파나, 프로메테우스 , 데이터 독
보안 관리? Sealed-Screts , AWS secret Manager
현재는 Iam roles for service Account (IRSA) 사용한다. - 예전에는 kiam이나 kube2 iam 사용.
각 서비스에서 AWS 서비스에 접근해야 하는 경우가 많다.
Pod에 AWS접근권한 제공 필요.
워커 노드에 EC2 인스턴스 프로필이나 액세스 키 사용은 보안상 문제가 있어 사용하지 않아야 한다.
<6> Istio-Service Mesh
1
Istio-Service Mesh는 서비스 간 트래픽 흐름 관리 , 보안, 모니터링에서 유용한 부분이 많다.
Istio는 모든 파드에 envoy라는 사이드가 프락시를 함께 배치하여 서비스 간의 트래픽을 가로채서 다양한 트래픽 관리 기법을 적용할 수 있다.
단지, Istio는 버전이 빨리 올라가고, 세세한 트래픽 관리가 필요할 때 도입하자.
Circuit breaker, timeout, retry
카나리 배포, 트래픽 미러링, A/B 테스트 가능
2
보안 : mTLS , AuthN, AuthZ
<7> 레거시 애플리케이션의 현대화 방법
점진적인으로 이전하기를 권장한다.
1
기존 레거시 애플리케이션을 그대로 컨테이너 기반 환경으로 옮기기 - Lift and Shift
dockfile
Helm chart - 방화벽, 보안 그룹 설정으로부터 네트워크 인터페이스 확인
2
클라우드 네이티브 환경을 운영하면 점진적인으로 이전하기를 권장한다.
Twelve-Factor App 접근법 참고하자.
3
자주 개발되는 서비스를 우선적으로 마이크로 서비스로 분리하자.
(이 부분은 당근 마켓 채팅 서비스 분리하는 방법과 같다.)
<8> 마이크로 서비스 아키텍처 도입을 위한 검토
1
공통적으로 해결해야 하는 문제에 대해 인프라나 플랫폼 적인 준비를 많이 해야 한다.
팀, 전사 표준을 잘 정의해서 서비스 개발 비용 최소화, 관련 부서와 합의해야 한다. 일관성을 지니도록 하는 것이 중요하다.
컨테이너 오케스트레이션, 복잡한 CI/CD 파이프라인, 인증, 로깅, 분산 트레이싱 , 공용 라이브러리 등 개발하고 관리하는 부분이 필요하다. 데이 옵스 조직이 필요할 수 있다.
2
서비스 처음 시작이고, 시작부터 완벽한 구조가 필요한 부분이 아니라면 변경에 유연한 구조로 모노리스로 시작을 추천한다.
많은 비즈니스가 타임 투 마켓이 중요하다. MSA의 운영 오버헤드를 미처 고려하지 않아 중요한 비즈니스 기회를 놓칠 수도 있다.
인터페이스가 견고하게 정의되는 시점에서 마이크로 서비스를 분리해도 된다.
충분히 준비된 후 마이크로 서비스 도입을 고려
3
레거시 애플리케이션 현대화는 ?
한 번에 이상적인 아키텍처로 전환하기보다는 점진적인 접근 고려.
개발 운영하는 구성원이 판단.
<10> 개인 정리
1
마이크로 서비스의 장점을 잘 설명해준다.
각 컴포넌트는 독립적으로 배포되고, 확장이 가능
특정 모듈의 장애가 전체로 전파되는 문제도 방지할 수 있다.
2
Istio-Service Mesh에 대해 잘 설명해준다.
3
Lift and Shift부터 현대화까지 자세한 내용을 설명해준다.
실무적인 내용이다.]
온프라미스 쿠버 네티스를 AWS EKS로 이전하는 경우 실무적으로 좋은 내용이 많아 추천한다.
https://kr-resources.awscloud.com/aws-modern-applications-innovate-kr?trkCampaign=innovate-mad-apj&trk=8159fdbd-621c-485c-97ab-e8cd038a5dff&sc_channel=em&mkt_tok=MTEyLVRaTS03NjYAAAGHz34lWJNa6J-wTjB48cYn9hm8C3prCsMi3GiZf9mvALKI976ZXQdaF7neFDqB1zdeb-wkkC6gvBSxzQ7fgYLUBbo9yXJJhZFVpvuasfTlJ9V1gDAQQ1rB
모음
https://brunch.co.kr/@topasvga/2790
