AWS Summit 2023 Day.2

By Jimmyberg
aws awssummit awssummit2023

Session. Key Note: 세상은 비동기 + 이벤트 기반이다.

인간의 생활 속은 이미 비동기 기반의 이벤트 연속이다. 동기 기반의 삶이라면, 아마도 다른 버티지 못할 것이다.

MSA 라는 시스템 아키텍처를 처음 제안한 AWS 의 많은 아키텍처 개발자들은 MSA 기반의 시스템 아키텍처를 넘어 이벤트 기반 아키텍처로 변화해야 한다고 한다. 더이상 하나의 서버 시스템에 묶여 확장성과 변경에 대한 두려움에서 벗어나야 한다는 것이다.

그러기 위해, 제안하는 것인 Sever-less 서버리스 기반의 시스템 아키텍처이며, 서버리스 서비스를 활용한다면, 이벤트 기반 아키텍처 구성이 가능하다고 한다.

Sever-less 서버리스 서비스

서버리스 서비스는 아래와 같은 장점을 제공한다.

  • 시스템 통합 용이
  • 시스템 구축 시간 단축
  • 점진적인 PoC (Proof of Concept)를 통해 클라우드 전환 가능

AWS 에서는 이런 서버리스 서비스를 AWS Lambda 를 포함한 클라우드 컴퓨팅 뿐만 아니라 DB, 스토리지 서비스도 제공하고 있다.

서버리스 이벤트 기반 아키텍처 장점

  • 세계화 글로벌 시대에 맞춰 서비스를 제공하기 위해서는 온프레미스의 단점은 너무 크다.
    • 네트워크 단절, 제한적인 리소스, 낮은 확장성
  • 다양한 정보와 이벤트에 맞춰 유연하고 확장 가능한 클라우드와 서버리스 기반 아키텍처가 필요하다.
    • 세계 각지에 있는 사용자 위치에 따른 데이터 저장, 조회, 처리를 AWS 클라우드로 해결한 Flitto
3-Tier 아키텍처에서 벗어나 ✨이벤트 기반 아키텍처✨ 로 전환이 필요한 시점이다.

Session. 오픈소스 데이터베이스로 탈 오라클! Why not?

클라우드 네이티브가 서비스의 강점이 되어가고 있지만, 온프레미스 시스템에서 클라우드로 전환할 때 제일 큰 문제 중 하나는 바로 데이터베이스 마이그레이션 이다. (Oracle 과 같은 데이터베이스를 벗어나기란 쉽지 않은 건 사실이다.)

하지만, Monolithic 모놀리식 아키텍처에서 MSA 아키텍처로 변해간 것 처럼, 다양한 비즈니스 도메인에 대한 데이터가 점점 방대해져가고, 서로 다른 데이터 형식과 저장/가공 방식이 필요한 이상, RDBMS 로만 서비스를 운영한다면 경쟁력이 떨어질 것이다.

그렇다면, 온프레이스 기반의 RDBMS 를 벗어나 완전 관리형 클라우드로 전환하는 것이 제일 좋겠지만, 그게 힘들다면 오픈소스 기반 DBMS 로 전환 또는 다양한 형식의 데이터를 다르게 저장하고 처리할 수 있도록 다중 DB 저장 처리 방식으로 전환이 필요할 것 같다.

데이터 현대화 아키텍처

SKT 의 탈 오라클 과정

SKT 에서도 클라우드 전환을 위한 단계 중 제일 큰 문제는 오라클DB 를 벗어나 목적 지향 데이터베이스로 전환하는 것이었다고 한다.

목적 지향 데이터베이스 전환 과정

탈 오라클 을 위한 단계는 다음과 같다.

  1. 설계
    • 요구사항과 현재 시스템의 특성을 충족하는 오픈소스 DB 분류
    • 충분한 성능 테스트 과정을 거쳐 DB 선택
  2. 개발
    • SQL 가이드 문서를 공통적으로 작성하고 개발자들에게 가이드하여 장애 이슈 최소화
  3. 데이터 이전
    • AWS DMS 서비스를 이용하여 DB 마이그레이션 진행
    • Source DB 와 Target DB 의 데이터 타입 등 처리 방식에 대한 차이는 DB Link 를 활용하여 차이를 최소화
    • 👍 Oracle > DB Link > 중계 서버 > DMS > Aurora DB
  4. 운영 최적화
    • 새로운 DB 의 성능 테스트를 통해 DB CPU 선택 등 DB 환경 구성 변경
    • Aurora 오로라 DB 선택한 SKT 는 Graviton CPU 권장
    • 초기에는 비용적인 이슈가 있어보일 수 있지만, 최적화를 통해 많은 비용 절약

오픈소스 DB 비용 차이

Session. Amazon Neptune 및 Elastic 을 이용한 추천 서비스 및 검색 플랫폼 구축하기

Neptune 추천 서비스 구축 메디스트림(인티그레이션)

한의원의 다양한 의료 서비스를 지원하고 있는 메디스트림 서비스도 키워드 기반 추천 서비스 기능을 제공해주기 위해 Graph 기반 완전 관리형 데이터베이스는 Neptune 를 선택한 이유 중 하나가 비정형 데이터 처리하기 위함이라고 한다.

추천 서비스 기능에 대한 요건은 하나의 키워드를 검색하였을 때, 자료 & 영상 & 서적 & 의료 기기 등 성격이 다양한 정보를 제공하는 것이었다. 각 정보들은 서로 다른 성격이지만, 같은 키워드로 연결 관계를 가진 상태 저장되는 구조를 설계해야 한다.

하나의 키워드에 대한 그래프 형식으로 다양한 데이터를 연결하는 구조로 그래프 데이터베이스를 구축하는 과정은 아죽 복잡하고, NLP, ETL 와 같은 자연어 처리 등 많은 작업 소요 시간이 필요하여 결코 행복하지않은(?) 작업이었다고 한다.

EKS 에서 Elastic 이용한 검색 플랫폼 구축

무신사와 같은 검색 기능이 많은 서비스는 검색 플랫폼 자체를 모듈화하고, 필요한 서비스에 인프라 연동하는 방식을 사용하고 있었다.

무신사의 검색 플랫폼의 변화는,

  1. 온프레미스 ES 직접 구축하고 운영
  2. 온프레미스 ES 모듈화하고 각 서비스별 클러스터를 구성하여 검색 인프라를 제공
  3. (최종) k8s 기반의 ECK Elastic Cloud 환경을 구축하고, 클라우드 ES 클러스터 인프라 제공 자동화

ECK Elastic Cloud on Kubernetes

  • Elastic operator 를 제공하는 서비스로 ES 와 Kibana 를 설치/연결 등 제어하는 역할
  • 스케일링 제어도 설정 파일 수정으로 가능
  • Load Balances 를 통해서 ECK 로 만들어진 ES 클러스터 접근을 제어

RBAC Role Based Access Control

  • k8s 사용자와 IAM 사용자를 1:1 매핑하여 특정 namespace 의 리소스를 제어할 수 있도록 환경 구축

ECK 전환 그 이후,

장점
  • 간결한 배포
  • 빠르고 우연한 확장과 축소
  • k8s 생태계 활용
단점
  • k8s 운영 부담

Session. MongoDB Atlas와 함께하는 Developer Data Platform

2019 MongoDB Recap

  • JSON 이란 포맷이란 데이터 자료구조가 개발자 친화적이며, 직관적인 데이터 구조
  • 무중단 서비스 이용 가능
  • 자동 파티셔닝을 통한 샤딩 처리
  • 온프레미스, 클라우드, 하이브리드 플랫폼 구분없이 MongoDB 적용 가능

Evolution of MongoDB

  • 클라우드 기반의 데이터 플랫폼 지속적인 투자를 통해 매년 릴리즈 버전 배포
  • 5.0+ 부터는 많은 릴리즈 버전에 대해 우려를 감소하기 위해 이전 버전 API 지원하는 기능 추가
  • 자동 샤딩 처리에 대한 요구 사항을 계속 반영
  • 버전별로 수많은 기능들이 추가됨..
  • 단순 데이터 저장소로 뿐만 아니라 검색, 조회 성능 최적화 등 플랫폼적인 개념의 개선

MongoDB Atlas : Developer Data Platform

  • 다양한 데이터 구조의 모델을 지원하지만 단일 API 조회 쿼리를 제공
  • NoSQL + Transaction 기능까지 3.0+ 부터는 지원
  • ES 와 같은 애널라이저 기능도 지원하기 때문에 검색 엔진으로 역할 수행 가능
  • 보안과 글로벌 멀티 플랫폼을 기반으로 이 모든 것을 지원

Atlas Database Cluster

  • Atlas Search
    • 하나의 데이터베이스 안에서 검색 엔진을 지원하기 위한 기능
    • 풍부한 검색 쿼리 지원
    • 노리 애널라이저와 같은 분석기도 지원
  • Online Archiving : Automated Data Tiering
    • 커지는 블락 스토리지(MongoDB) 있는 데이터를 오브젝트 스토리지로 분리 보관하고, 검색 쿼리도 이중화하여 접근 처리 가능
  • Atlas Data Federation
    • MongoDB 클러스터와 오브젝트 스토리지를 하나의 데이터베이스처럼 묶어주는 기능
  • Atlas Chars : Powerful & Effective Visualization
    • MongoDB 에서만 VI 툴 기능 제공
  • Atlas Device sync
    • 다양한 디바이스끼리 sync 를 맞추기 위한 기능
  • Atlas App Service
    • 데이터베이스 변경 또는 이벤트 처리를 기준을 람다처럼 기능 자동화

DIRT Data & Innovation Recurring Tax

  • 다양한 산업군으로 다양한 플랫폼으로 개발자의 다양한 경험은 부담
  • 데이터 통합 중요도도 높아지지만 데이터 중복 발생도 높아짐
  • 이런 부분을 해결하기 위해서,
  • 개발자 경험을 통합
  • 어려운 운영/보안 업무 모델을 반복 가능하도록 쉽게 제공
  • 자동화/투명한 데이터 이동 제공
  • 데이터 중복 감소

Session. 클라우드의 경계를 허무는 AWS Hybrid Cloud Services

AWS Global Infrastructure for Hybrid

  • 전세계적인 AWS 클라우드 서버 리전 (꾸준히 증가 - 31개 리전 운영 중 - 5개 추가 예정)
  • Local Zones : 리전 기준의 AWS 네트워크 지원
  • Wavelength : 리전이 없는 대도시에도 전세계 통신사 연계하여 AWS 네트워크 지원
  • Outposts : 온프레미스와 연동을 위한 AWS 네트워크 지원

Why Hybrid?

  • 지연에 민감한 서비스에 대해 리전 선택 요건
  • 로컬 데이터를 실시간 처리 요건 : 온프레미스에서 대용량 데이터 처리하고 클라우드로 이동
  • 데이터 상주 규정 : 금결원 규정과 같은 법률 규정 때문에 클라우드 전환이 불가한 이유
  • 온프레미스의 단점
    • 인프라 구성에 대한 시간
    • 서비스 제공 time to market 감소로 빠른 비즈니스 혁신 불가
    • 온프레미스와 클라우드의 기술적인 스택 차이
    • 이런 단점을 보완하기 위해 Hybrid 서비스를 제공
  • Hybrid 자동차와 같이 운전하는 방법은 동일하게 서비스를 운영할 수 있도록 지원

AWS Local Zones, Wavelength, Snowball Family

  • Local Zones
    • 리전이 없는 곳에 Local Zones 제공하여 리전에 연결되어 지연을 감소할 수 있도록 제공
    • 연결된 리전에 만든 AWS 인스턴스를 그대로 Local Zones 로 동기화
    • 각 로컬에 있는 인터넷 게이트웨이를 통해서 각 국가 디바이스와 네트워크 연결
    • 리전에 비해 높은 비용이란 단점
    • 리전과 다르게 Local Zones 에서 사용할 수 있는 AWS 인스턴스는 한계
  • Wavelength
    • 한국은 SKT 데이터센터에 AWS Wavelength 구축
    • Wavelength 는 통신망을 통해서 바로 연결하고자 하는 기기와 네트워크 연결
  • Snowball Family
    • 이동/격오지/단절된 네트워크 환경에서도 AWS 네트워크 연결 가능하도록 제공

AWS Outposts Rack

  • 어디에서나 설치가 가능한 인프라
  • 리전에서 구성되어있는 물리적인 서버 설비 기기를 직접 설치하는 방법 (엄청 비싸겠다)
  • Outposts 도입 단계
    1. 먼저, 아키텍처/워크로드 검증 절차 진행
    2. AWS console 에서 바로 주문 가능
    3. 운영 방식에 대한 교육 실행
    4. 약 6주 정도면 설비 기기 배송 완료
    5. 1주 정도 프로비저닝 단계 진행
  • 컴퓨팅, 스토리지, 데이터베이스, 네트워킹, 마이그레이션 등 리전의 한계적인 기본 서비스 제공
  • 리전과 동일한 EC2 인스턴스와 EBS 볼륨 제공하지만, 기본적인 서비스만 제공
  • AWS 리전과 Outposts 는 Service Link 를 통해서 안정적으로 네트워크 통신
    • 서비스 링크의 대역폭은 최저 500mbps 이고 그 이상도 설정 가능
    • 모든 통신 데이터는 암호화되어 전달
  • Outposts 와 온프레미스 인프라는 로컬 네트워크로 통신
    • Outposts 내부에 있는 스위치와 온프레미스 연결용 스위치를 통해 온프레미스 인프라와 네트워크 통신
    • 그 안에서는 네트워크 보안은 내부 규정
  • 리전 콘솔에서만 Outposts 인스턴스 제어 가능
  • AWS Organization 서비스를 이용하여 Outposts 접근/제어할 수 있는 AWS 계정 관리 가능
  • Outposts 내에서 사용하는 인스턴스에 대해서 비용 지불 & 리전과 통신하는 비용 지불 (로컬 네트워크 사용한다면 또 다름)
  • Outposts 하드웨어 문제가 발생한다면 AWS 지원
  • NSK Nitro Security Key 발급을 하고 물리 장치 안에 있는 데이터를 암호화 관리
    • 물리 장치 고장이라면 NSK 폐기하여 장치 안 데이터도 무용지물

AWS Outposts Server

  • 물리 서버 한대만 지원
  • Rack 다르게 많은 서비스 제약

AWS Summit 2023 공식 페이지