brunch

You can make anything
by writing

C.S.Lewis

by Master Seo Dec 20. 2022

30탄-3. (요약) AWS 현대화 기업 사례 2022

<1> 이마트 -  리뷰 서비스 클라우드로 변경

<2> 리씽크 - 서버리스  기반 온라인 쇼핑몰

<3> 잡코리아 - CI/CD 자동화  아키텍처 

<4> SOCAR  - SAP (S/4 HANA)

<5> LG 그룹의 MSA

<6> 카카오페이 – 금융권 앱 현대화 : EKS + NLB + istio + API gateway

<7> 버즈빌 , EKS 활용한 마이크로 서비스 운영

<100>  자세히  보기



<1> 이마트 -  리뷰 서비스 클라우드로 변경


1

리뷰 서비스

텍스트 및 사진으로 상품에 대한 평가를 남김

상품에 대한 전반적인 만족도를 표시, 구매 전환율 높아짐.

기존 온프라미스 시스템을 클라우드로 변경하는 작업


2

변경 전  아키텍처?

모바일앱------백앤드----------- 오라클 / REDIS 사용


3

변경 후 아키텍처?


모바일앱----백앤드---------다이나모 디비 / Elastic Cache for Redis -----------Dynamo Stream ------- 람다----- S3 저장


리뷰 서비스는 다이나모 디비 , 엔드유저 사용자가 모바일 앱을 통해 백엔드로 접근, 리뷰 주요 데이터는 다이나모 디비에 저장된다. 

복잡한 연산은 람다로 처리, 레디스에 저장되는 데이터는 MateralizedView의 형태로 저장되기 위해 AWS람다 함수에 의해 미리 계산된다.

오픈 서치 서비스도 사용


처음엔 , 백앤드만 우선 클라우드로 분리

aws에 대한 경험이 많지 않았기 때문에 단계적으로 진행함.



<2>  리씽크 - 서버리스  기반 온라인 쇼핑몰


1

기존 인프라 환경의 한계점

기존 물리 서버로 운영 중

서버 증설이 느림

론칭 대비 5배 응답속도 지연


2

아키텍처?

요청--------CloudFront---API Gateway-----람다--------CloudSearch , S3, Dynamo DB , Aurora Serverless V2 , SQS


3

해결하려고 한 문제? 스케일 아웃과 속도 개선

서버리스 설루션을 선택

고객이 필요한 시점에 결과물을 내놓는 게 중요하다.

적은 인원으로 인프라 고민하기보다는 기존의 모범사례를 사용했다.

정적 사이트는 S3 사용함. CloudFront로 연계함.


4

람다를 활용한 온디맨드 이미지 리사이징  아키텍처 ?


첫 번째 요청--------CloudFront -----람다 ---------s3

두 번째 요청은 CloudFront에서 처리


상품 카탈로그에서 필요한 썸네일을 AWS Lambda와 CloudFront를 통해 최적화함.

동일한 썸네일을 요청 시 CloudFront에 캐싱되어 있어 빠른 응답으로 썸네일 제공

마이그레이션 시 뷰와 비즈니스 레이어를 한 번에 변경하면 검증이 어려울 것으로 판단하여 , 구현하기 쉬우면서 고객에게 임팩트를 크게 주는 비즈니스 변경을 먼저함.


5

해결하려고 한 문제? 스케일 아웃과 속도 개선

클라우드 서치를 통해 상품 POOL을 구축하고, 상황에 맞게 다이나모 디비와 CloudFront를 캐시로 활용하여 해결함

기존 상품 카탈로그를 RDB로 처리하면서 쿼리 비용 증가하여 서버리스 검색엔진 사용


서버리스 설루션을 활용한 성능개선

상품 POOL 구축 - Cloud Search

상황에 맞는 캐시 레이어 - 다이나모 디비, 클라우드 프런트



<3> 잡코리아 - CI/CD 자동화  아키텍처 


1

AWS 클라우드 도입으로 안정되고 검증된 개발/운영 도구들과 플랫폼 환경을 확보함

EKS, ECR, MSK, Elastic Cache, KMS, Direct Connect, RDS 등

EKS를 기반으로, 기능별로 나누어진 서비스들이 컨테이너로 운영될 수 있도록 환경을 조성하고 서비스 사이의 연계를 위해 istio를 도입함.

자동화된 CI/CD툴을 사용하여 개발자가 Gitops를 통해 쉽게 배포할 수 있는 환경을 제공하고자 하였습니다.


2

서비스는 총 4개의 계정(MGMT/DEV/STG/PRD)으로 구성되어 있습니다.

MGMT는 DEV/STG/PRD에서 공통으로 필요한 자원들을 구성 관리하는 계정

젠킨스/소나 큐브/하버/ECR 등 설치, Paker/Ansible을 이용한 골든 이미지 생성

DEV/STG/PRD는 모두 동일한 형태로 구성. EKS와 DB 간 방화벽 서브넷 구성.


3

CI/CD 자동화  아키텍처?


개발자 영역  --------------자동화 영역


개발자---비트 버킷 ------------------------------젠킨스--------ECR---EKS  / Argo CD 


내부 승인 프로세스와 연계하여 젠킨스를 사용한다.

아르고 CD는 BitBucket을 폴링 하고 있다가 배포 리파지토리의 상태가 변경되면 ECR로부터 컨테이너 이미지를 읽어 들여 EKS내부에 워크로드를 생성하여 줍니다.



4

인프라 구성 자동화 + 이미지 관리 + 보안 아키텍처?


인프라 관리자--인프라 구성---테라폼----코드화 된 인프라 적옹------ 개발 , STG , PRO 생성

                                                                                      골든 이미지는 Packer , Ansible 사용


테라폼 사용 중

EC2서버 및 EKS Node에 보안정책 및 백신 툴 설치가 필수로 요구되어 Packer와 Ansible을 이용해서 자동으로 골든 이미지를 생성하는 환경

패커로 커스텀 서버 생성 , 생성된 서버에 Ansible을 이용해 커스텀 설정을 적용

패커에서 이미지 생성 및 지정된 계정을 공유, 임시 서버를 삭제



5

IaC를 통한 인프라 관리 및 프로비저닝?


내부 BitBucket에서 만들어져 있는 깃 소스가 트랜싯 게이트웨이를 통해 내부로 들어옴

배스천에 있는 패커를 통해 이미지 빌더가 이루어진다.

만들어진 AMI 이미지가 골든 이미지 , AMI가 서비스에 사용됨.



<4> SOCAR  - SAP (S/4 HANA)


1

쏘카는 스마트폰으로 간편하게  원하는 시간에 원하는 방식으로 차량을 이용할 수 있는 카셰어링 서비스이다.

전국 1만 7천대의 차량으로부터 수집되는 데이터 기반으로 8백만 명의 사용자들에게 새로운 이동 경험을 제공하고 있다.


2

아키텍처?


오로라 --------- 데이터 그루----S3-----------Appflow------oDATA -------- SAP (S/4 HANA)


SAP로 데이터를 전송하는 방식으로 진행함

오로라에 있는 데이터를 글루를 사용해 csv 혹은 json형태의 파일로 S3 버킷에 export 시킴



<5> LG 그룹의 MSA


1

LG CNS는 공통의 인프라 위에 SaaS 서비스를 제공하는 것을 지향한다.

AWS Landing Zone이라는 멀티 어카운트 관리 아키텍처를 적용했다.

프런트엔드 서비스, 세션 서비스, 백엔드 서비스, 데이터 서비스, 인터페이스 서비스가 각 마이크로 서비스로 구현되어 있다.


2

인프라를 코드로 배포하기?


devops 엔지니어 , VisualCode-----git push-----S3 -----web hook----jenkins  / ECS ---------클라우드 포메이션 / 테라폼/테러 스캔----  AWS 리소스 만들기--  kinesis -------ElasticSearch-------kibana


Slack으로 노티


소스의 버전 관리는 BitBucket을 사용한다. 젠킨스에서 체크아웃을 한다.

테라폼을 사용하며, CI/CD 파이프라인에서 배포하게 되면 자원이 생성된다.

빌드 후 슬랙을 통해 결과가 전달된다.

보안을 위해 테라스캔을 사용한다.


3

프런트, 세션, 백엔드는 클라우드 포메이션으로 개발자가 배포한다.

데이터, 인터페이스 등 공통으로 사용하는 건 테라폼으로 데브옵스 엔지니어가 배포함

개발자는 SAM을 사용한다.




<6> 카카오페이 – 금융권 앱 현대화 : EKS + NLB + istio + API gateway


1

기존 구성

Proxy 사용 중


2

Public / Private 물리적으로 분리

VPC to VPC 통신 필요

NLB = EIP 보장

API Gateway

깃 옵스 툴인 아틀란티스를 사용하고 있다.

테라폼을 사용하고 있다.

모든 배포 이력은 git pr에 태그 정보를 통해 관리된다.

젠킨스, Spinaker를 사용해 배포한다.


3

최종 아키텍처

EKS + NLB + Gateway  


게이트웨이는 Istio로 구현

Vpc 간에는 방화벽, nacl, 보안 그룹으로 관리한다.

모든 구간의 고가용성 통신은 nlb를 통해서 한다.


4

Istio, Traffic Management?

Istio는 서비스 메쉬로 거대한 기술의 영역을 구현하는 오픈 소스 기술

Envoy proxy를 통해 다양한 기능들을 제공하고 있다.

전체 컨테이너 네트워크를 관리하는 기술로 실패 시, 서비스 영향이 크다.


5

API Gateway on EKS?

모바일 디바이스, 제휴사 또는 내부 애플리케이션, 어드민과 같은 백오피스 등 다양한 프로토콜과 요청을 NLB를 통해 EKS위에 구성된 istio ingressgateway envoy컨테이너가 처리하게 된다. 

다른 vpc나 온프라미스와 통신이 가능하다.

EKS Custom cidr 확정은 사전에 고려하세요.




<7> 버즈빌 , EKS 활용한 마이크로 서비스 운영


1

기존 운영 단점?

마이크로 서비스가 추가할 때마다 서비스 디스커버리 , 오토스케일링 , 로드밸런서가 늘어나는 구조이다.

서비스별로 사용하는 서버가 틀려 각기 다른 Launch config를 관리해야 한다.


2

쿠버 네티스 도입

초기 Kops로 쿠버 네티스 관리했다.

업그레이드마다 문제

테라폼으로 쿠버 네티스 관리하고 있다.



<100>  자세히  보기


https://brunch.co.kr/@topasvga/2790




다음 과정

https://brunch.co.kr/@topasvga/2874



감사합니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari