#devspace

첫 오프라인 써밋에 참가하다!

그동안 코로나로 인해서 온라인으로만 진행되었는데 올해 드디어 현장에서 열린 AWS Summit Seoul 2023에 다녀왔다!

이번 AWS Summit Seoul 2023은 5월 3일, 5월 4일 이틀동안 열렸고, 장소는 코엑스였는데 코엑스 전체를 대관할 정도로 대규모로 진행되었다.

너무 너무 가고 싶었는데 마침 팀원 분들께서 가게 되어서 데리고 가주셨다! 개인적으로 이번이 첫 오프라인 컨퍼런스, 써밋이었는데 멋진 경험을 할 수 있어서 정말 감사했다.

괜히 조기 마감 된게 아님을 실감할 수 있을 정도로 정말 많은 사람들이 있었는데, 대학생부터 주니어, 시니어까지 다양한 연령대와 데이터베이스, AI, 인프라, 시스템 등의 직종이 모인 것 같았다. 아무래도 오랜만의 오프라인 행사여서 그런지 많은 분들이 참석하셔서 뜨거운 관심과 열기를 느낄 수 있었다.

어떤 내용들이 구성되어 있나?

오전 9시 30분에 시작해서 오후 6시에 끝나는 일정으로

하루에 베뉴 별로 6개의 세션이 동시에 진행되어 원하는 강연을 골라서 보는 방식이었다.

Day 1은 산업 업종별 강연으로 AWS를 사용하고 있는 회사에서 어떻게 다루고 있는지, 업종 별로 사용에 어떤 특징이나 차이점이 있는지 알아볼 수 있는 시간들로 구성되어 있다.

Day 2는 기술 주제별 강연으로, 입문/중급/심화 기술로 나뉘어 AWS의 새로운 기술과 다양한 분야의 클라우드 전문가들의 강연을 듣고 배울 수 있는 시간들이었다.

나는 Day 2에 참석했고, 데이터베이스와 관련되면서 흥미로운 주제로 골라서 아래와 같이 듣기로 계획하였는데,

11:10~11:50 : 오픈소스 데이터베이스로 탈 오라클! Why not?

13:10~13:50 : 갤럭시 규모의 서비스를 위한 Amazon DynamoDB의 역할과 비용 최적화 방법

14:20~14:50 : 성공적인 AWS RDS 마이그레이션을 위한 여정과 필수 고려사항

15:20~16:00 : AWS에서 최소한의 비용으로 구현하는 멀티리전 DR 자동화 구성

아쉽게도 두번째 13:10 세션은 참석하지 못 했다.. 인기가 너무 많았는지 스탠딩 좌석까지 모두 마감되었다고 해서 입장이 불가능했다..

세션 간 쉬는 시간이 2~30분 정도 되기 때문에 인기 있는 세션은 최소 10분 전에는 가서 미리 줄을 서야 되겠다는 교훈을 얻을 수 있었다 😂

입장

코엑스 B홀에서 사전신청한 사람들한테 이름이 적힌 카드 목걸이를 준다. 이걸로 베뉴 들어갈 때마다나 부스 방문할 때마다 태깅하고 그러니까 계속 쓰게 된다.

또 처음에 기조연설 들어갈 때 선착순으로 런치박스 먹을 수 있는 고무밴드도 나눠주니까 받아놨다가 바꿔 먹을 수 있다.

기조연설

먼저 9시 30분~10시 40분에 기조연설이 진행되는데 3층 오디토리움에서는 강연자가 직접 강연하는 모습을 볼 수 있다. 그 외에는 지하 1층, 1층, 2층에서 강연 장면을 실시간으로 화면으로 만나볼 수 있다. 너무 시간에 맞춰 가면 3층 오디토리움이 마감되었다고도 해서 현장의 모습을 확인하고 싶다면 조금 넉넉히 가는 것이 좋을 것 같았다.

본격적으로 기조연설이 시작되기 전에 쇼트 영화 같은 영상을 시청했다. 아마존 CTO인 버너 보겔스가 연기를 한 것도 재밌었고, 내용 자체도 생각보다 너무 재밌었는데 주제는 비동기에 대한 내용이었다.

실제 세상은 비동기적(asynchronus)으로 동작하고 있고 그래야만 하는데, 그렇지 않고 동기적으로 동작한다면 어떻게 되는지를 그리는 내용이다.

버너 보겔스는 평소에도 비동기적에 대해 강조하는 걸 볼 수 있는데 AWS Re:Invent 2022 기조연설에서 한 말을 따오자면

"실제 세계는 비동기적이다. 동기적인 것은 하나도 없다. 많은 일이 항상 일어나고 있다. 자연은 비동기식으로 작동한다. 컴퓨터 시스템도 비동기식으로 만들어지는 게 자연스럽다. 이벤트 드리븐 아키텍처로 느슨하게 결합된 시스템(Loosely coupled systems)을 만들어야 한다." 라고 한 적도 있다.

Day 2 기조연설자는 아래와 같았는데

특히, Flitto 강동한 CTO님을 뵐 수 있어서 좋았다.

Flitto는 번역 통합 서비스를 제공하는 스타트업인데, 평소에도 참 멋진 CTO님과 문화가 있는 회사라고 생각하고 있었다.

한국은 Node.js 불모지라고 불릴 정도로 Node.js를 주로 사용하는 기업이 많지 않은데, 그 속에서도 Node.js로 운영을 하고 있고 결국 성공을 하신 그런 분이시다..

그리고 LG U+ 송주영 연구위원님도 짧은 순간 뵌 거였지만 정말 괜히 최연소가 아니구나 싶을 정도로 말씀을 너무 잘 하시고, "딱 이 5가지만 기억하세요" 하면서 원칙들을 딱 딱 알려주실 때 멋지다고 생각했다..

딱 이 5가지라는 건, DevOps에서 중요한 5가지 단계인데

1. Security
2. Reliability
3. Automation
4. Organization
5. Governance

1번부터 피라미드 모양으로 기반이 되어 쌓아 올라간다고 생각하면 된다고 한다.

윤석찬 수석 테크 에반젤리스트께서 AWS 기반 아키텍처와 다양한 도구, 서비스를 소개해주셨고

나머지 내용은 윤석찬 수석 테크 에반젤리스트께서 강동한님과 송주영님께 Q&A 하는 방식으로 진행되었다.

내용을 간단하게 정리해보자면

• 스타트업에서 AWS를 사용하면 좋은 점
  • 클라우드를 이용하면 서버리스를 구성하기 좋고, 비용도 절감할 수 있음
• 서비스를 글로벌하게 제공하면서 겪은 점들
  • 인프라를 어떤 리전에 구축할 지도 고려해봐야 함
  • 거주 지역 / 기기 접속 위치 / IP 위치 등 어떤 점을 기준으로 잡을 지 정하는 것이 쉽지 않음
  • AWS의 글로벌 서비스를 이용하면 쉽게 해결할 수 있음(AWS DynamoDB 글로벌 테이블 등)
• 보안에 대해서
  • 보안에 대해 정의하고 가자면, 보안이란 접근 통제, 암호화, 마스킹, 감시, 추적, 인증과 권한 관리 등이다.
  • 보안 모범 사례를 하나 잡고 따라가면 좋음
  • 놓치기 쉬운 부분인데 예를 들면 데이터베이스 연결 정보 등을 평문으로 박지 않도록 주의하기(AWS Secrets Manager 등 활용 가능)
• 빼놓을 수 없는 비용 문제
  • 스팟 인스턴스를 적극적으로 활용해보기
  • 온디맨드하게 사용하기
  • 리전 마다 서비스 과금이 다르기 때문에 레이턴시가 크게 중요하지 않은 작업이라면 저렴한 리전으로 사용하기
• 인프라 운영에 대해서
  • 모든 인프라를 코드화해서 자동화하는 것 추천(IaC)
  • 이 인프라를 Why/When/What 만들었는지 늘 추척할 수 있어야 함
  • 온디맨드하게 사용하기, 예를 들면 단순히 오토 스케일링을 설정해 놓는 것이 아니라 필요할 때마다 하루에 몇 번이라도 자동으로 정책을 수정할 수 있어야 함
  • 스팟 인스턴스, Graviton 등을 활용하기

점심

런치 박스를 받으면 요런 구성으로 되어 있다. Day 1 거는 다른 것 같던데 샐러드 과일 쿠키까지 이것저것 있어서 좋았다.

각 베뉴마다 나눠주는 거 같은데 고무밴드랑 교환해서 받으면 원하는 곳에서 먹으면 된다.

EXPO

MongoDB, Redis, Redhat, SKT, LG CNS, Megazone Cloud 등 많은 기업들이 부스를 운영했다. 세션을 안 듣는 시간이나 쉬는 시간 같을 때 들리면 되는데 이것저것 체험해보고 상품을 받거나 기업들과 서비스 상담을 해볼 수도 있다. 부스를 돌면서 설문조사 많이 하고, 가방이랑 시계, 무선 충전 거치대 등을 받아왔다. 사람들도 엄청 많고, 같이 다니면서 체험하는 과정 자체가 넘 즐거웠다.

끝으로..

첫 오프라인 써밋을 이렇게 대규모로 열리는 곳에 함께 참여할 수 있어서 뜻 깊은 시간이었다. 정말 멋지고, 대단하고, 똑똑한 사람들이 참 많다는 것을 다시금 느끼고 더 열심히 정진해야겠다는 동기 부여를 확실히 받을 수 있었다.

자세한 내용은 아래 홈페이지에서 확인할 수 있고, 발표된 강연 자료와 영상은 6월 중에 공개될 예정이라고 하니

다시 확인하고 싶거나 놓쳤던 강연을 보면 좋을 것 같다 :)

https://aws.amazon.com/ko/events/summits/seoul/agenda/

AWS에서 최소한의 비용으로 구현하는 멀티리전 DR 자동화 구성

Day 2 | Session 4 | 15:20 - 16:00
안준환 솔루션즈 아키텍트, AWS
Yongzhe Ren 솔루션즈 아키텍트, AWS

재해복구에 대한 대비는 온프레미스를 이용할때나, 클라우드를 이용할때나 항상 중요하다. 이 세션에서는 AWS Backup을 활용하여 최소한의 비용으로 클라우드 환경에서 운영 중인 시스템에 대한 멀티 리전 재해 복구를 자동화하는 방안을 살펴본다. 더불어 온프레미스에서 운영중인 시스템에 대한 재해복구를 비용 효율적으로 자동화하기 위해 어떻게 AWS Elastic Disaster Recovery를 활용할 수 있는지도 알아본다. AWS 서비스를 활용해 대부분의 시간동안 유휴 상태인 복구 사이트에 대한 비용을 최소화하면서도 재해복구를 자동화할 수 있다.

✅ 목차

1. AWS에서의 재해복구
2. AWS Backup을 이용한 멀티리전 재해복구
3. AWS Elastic Disaster Recovery를 이용한 온프레미스 재해복구

1. AWS에서의 재해복구

Disaster Recovery

• 비즈니스 지속성
• 희귀하지만 대규모 장애상황
  • 자연재해
  • 기술적 이슈
  • 휴먼 액션
• 개별 장애에 대한 목표 측정
  • 복구 시간(RTO)
  • 복구 시점(RPO)

복구시점 및 복구시간 목표

클라우드에서의 재해 복구 전략

복구시간 목표 - RTO

Backup & Restore는 서비스 중단 기간이 길어지더라도 수용 가능한 경우에 적용한다.

복구시점 목표 - RPO

재해가 비즈니스에 미치는 영향을 고려해야 한다. 예를 들어 대규모 금융 트랜잭션을 처리한다면 짧은 기간 중단되더라도 리스크가 매우 크지만, 신입사원 교육용 시스템 같은 경우면 중단되더라도 수용 가능할 것이다.

• 중단이 매우 크리티컬하고, 고비용 투자가 가능하다면 → Multi-Site A/A
• 중단되어도 비즈니스에 영향이 없다면 → Backup & Restore
• 재해에 의한 데이터 손실은 Pilot light와 warm standby가 거의 같음
  • 빠른 복구 → 웜 스탠바이
  • 데이터 손실만 없으면 된다 → 파일럿 라이트

2. AWS Backup을 이용한 멀티리전 재해복구

재해복구를 위한 백업 대상

메타데이터는 인프라 구성 정보로, 완벽하게 원래대로 복원하기 위해서는 메타데이터 백업도 필요하다.

메타데이터를 어떻게 추출해서 백업할 것인지는 온프레미스와 클라우드 환경에 따라 달라진다.

• 온프레미스
  • CMDB(구성관리데이터베이스)
  • 호스트, 어플라이언스 설정 정보가 다 들어있음
  • 수기, 엑셀 파일, 전용 시스템 등
• AWS 클라우드
  • CMDB: 온프레미스와 동일하거나 클라우드와 연동
  • AWS API: API로 설정된 상태를 읽어오고, 구성 정보로 할 수 있음
  • IaC: 인프라 자체를 코드로 관리함
    • AWS CloudFormation, Terraform, AWS Cloud Development Kit

Backup & Restore 기반 재해복구 자동화

• 재해가 발생하면 DR 리전에 백업해둔 데이터와 메타데이터를 조합해 원본 데이터와 동일하게 복구
• 자동화가 필요하다면 각각 구현해야 하고, AWS Backup 서비스를 활용할 수 있음

AWS Backup 개요

• AWS Backup 이란?
  • 완전관리형 정책 기반 백업 서비스
  • 여러 AWS 서비스들에 걸쳐 자동화된 중앙 집중식 관리를 지원하는 백업 서비스
  • 컴퓨트, 블록 스토리지, 파일 스토리지, 오브젝트 스토리지, 데이터 전송, 데이터베이스, 애플리케이션, 관리, 하이브리드

재해복구 자동화 구현 예

• 모든 데이터와 메타데이터를 DR 리전에 복제
• CodeBuild 등 CI/CD 도구를 이용해 자동 복구 가능

1. Iac 관리 및 백업

2. IaC 코드 의존성 분리

3. 관리형 리소스에 대한 간접 접근

4. 재해 복구 태스크의 실행 독립성 확보

5. 재해복구 시스템의 지속적인 검증 및 보완

3. AWS Elastic Disaster Recovery를 이용한 재해복구

클라우드 재해 복구 장점

클라우드 재해 복구의 비즈니스 효과

1. 견고한 운영 체계: 최상위 복구 목표를 기반으로 안정성과 가용성 달성
2. 운영 효율성: 중복 인프라 및 라이선스의 필요성을 줄임으로써 비용 절감 확보
3. 비즈니스 연속성에 대한 확신: 운영 환경에 영향이 없는 쉬운 재해 복구 테스트를 수행해 가동 중지 시간 및 데이터 손실 최소화

AWS Elastic Disaster Recovery란?

다양한 고객의 요건에 맞는 안정적이고, 확장 가능하며, 안전한 스토리지 서비스 포트폴리오 제공

• 유연성
  • 모든 소스에서 복제
  • 다양한 OS, 응용 프로그램 및 데이터베이스 지원
  • 유휴 복구 사이트 리소스를 제거하고 필요한 만큼만 지불
• 신뢰성
  • 견고하고 예측 가능한 연속 복제 기능
  • RPO: 수초, RTO: 수분
  • 랜섬웨어, 충돌 및 인적 오류에 대한 보호
• 자동화
  • 최소한의 기술 요구사항
  • 운영에 영향을 주지 않는 DR 테스트
  • 테스트, 복구, Fail Back의 통합 프로세스 지원

AWS EDR 사용 패턴

AWS EDR 작동방식

AWS EDR 지원 대상

AWS EDR 아키텍처

데모 아키텍처

Summary

참고 자료

• AWS Backup 및 AWS EDR 관련 워크샵 자료
  • AWS Backup 워크샵
  • AWS DRS 워크샵
• AWS 클라우드에서의 재해복구 백서 및 안내서 자료
  • AWS 재해복구 백서
• AWS Skill Builder 무료 온라인 트레이닝
  •  AWS Skill Builder

성공적인 AWS RDS 마이그레이션을 위한 여정과 필수 고려사항

Day 2 | Session 3 | 14:20 - 14:50
서호석 컨설팅팀 상무, 에티버스

AWS RDS로의 성공적인 마이그레이션을 위해 각 스텝 별 준비 사항을 소개한다. 마이그레이션 과정에서 고려, 숙지해야 할 항목들을 공유하여 성공적인 이관을 준비하는 여정, 에티버스 세션과 함께 하시기 바란다.

1. Amazon DB Services

Amazon RDS와 Aurora

Amazon RDS Custom For Oracle

2. DB Migration Steps

General Steps For DB Migration

Access Inspection Lists

3. DB Migration Considerations

Amazon RDS로의 마이그레이션을 위한 준비사항

4. DB Migration Tools

OS Commands

DBMS Provided Tools

Change Data Capture Tools

5. DB Migration Cases

OnPremise MS-SQL To Amazon RDS MySQL

OnPremise Oracle DB To Amazon RDS Oracle

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

Day 2 | Session 1 | 11:10 - 11:50
김지훈 WWSO 솔루션즈 아키텍트, AWS
박승전 Project Manager, SK Telecom

아직 많은 기업들이 상용 데이터베이스로 인해 발생하는 높은 비용으로 고통받고 있다. 이를 돕기 위해 AWS는 오픈 소스를 기반으로 한 다양한 워크로드의 특성에 맞는 데이터베이스 서비스를 제공하고 있다.

이번 세션에서는 AWS의 워크로드 특성에 따른 목적에 맞는 다양한 데이터베이스 서비스가 어떤 것이 있는지 알아보고, 기존 오라클 데이터베이스를 기반으로 구성된 서비스에 AWS의 데이터베이스를 도입하여 탈 오라클에 성공한 고객 사례를 소개한다.

데이터 현대화 아키텍처

전통 방식에서 마이크로 서비스 아키텍처, 분산 아키텍처로 변화하고 있다.

AWS의 현대화는 모놀리식에서 MSA로 변화하고 있는데,

모놀리식은 중앙 DB + 종속 팀

MSA는 독립 DB + 2 피자 팀이라고 할 수 있다.

데이터베이스 현대화

1. 관리형 데이터베이스로 이동 : 자체 관리형 → AWS 관리형
2. 오픈 소스 데이터베이스로 이동 : 상용 → 오픈 소스
3. 목적 지향 데이터베이스로 현대화 : 모놀리식 → 마이크로 서비스

1 단계: 관리형 데이터베이스로 이관

기존에는 관계형 데이터베이스를 사용하다가 관리형 데이터베이스를 도입한다.

운영 부담의 감소와 플랫폼 기능의 장점 활용으로 인해 민첩성, 관리 편의성, 비용 효율성이 상승할 수 있다.

이 때 Amazon RDS나 Aurora와 같은 클라우드 네이티브 데이터베이스 도입을 고려할 수 있다.

2 단계: 캐시 및 영구 인메모리 데이터

캐시 및 영구 인메모리 데이터로

• Amazon RDS나 Aurora와 같은 클라우드 네이티브 데이터베이스
• 빈번한 액세스 데이터 캐싱에는 Amazon ElastiCache
• 지속적이고 내구성 있는 인메모리 데이터 스토리지로는 Amazon MemoryDB

등을 활용해 스케링일 문제를 해결하고, 성능을 향상시킬 수 있다.

3 단계: 비 관계형 데이터 쿼리

• 키-밸류, 글로벌 액세스 가능한 데이터 세트로는 Amazon DynamoDB
• 도큐먼트 형태 데이터 세트는 Amazon DocumentDB
• 와이드 컬럼 데이터 세트는 Amazon Keyspaces

를 활용해 모놀리스 구조를 분해하고 민첩성, 확장성, 성능을 향상시킬 수 있다.

4 단계: 전문화된 데이터 상호 작용

워크로드 특성에 맞는 전문화된 데이터베이스를 선택하여 사용할 수 있는데 전문 데이터 세트로는 소셜 그래프, 추천 엔진, 시간 별 데이터, 로그 등이 있다.

이에 사용할 수 있는 데이터베이스로는

• 그래프 및 고도로 연결된 데이터는 Amazon Neptune
• 그래프 DB나 IoT 센서 데이터를 시간대 별로 저장할 수 있는 Amazon Timestream
• 원장 데이터 기록 시스템인 Amazon QLDB

를 활용할 수 있다.

Summary

탈 오라클 사례: SK Telecom TANGO의 클라우드 전환계획

TANGO란?

• T-Advanced Next Generation Oss
• SKT 망 관리 시스템
• 주요 기능: 장비 관리, 감시, 분석, 망 설계 구축
•  구성: 총 5가지 기능
  • Operation: 성능, 고장 감시
  • Inventory: 장비관리
  • Platform: 공통기능
  • Analytics: 분석
  • Engineering & Construction: 설계 및 구축
  • 이 중 O, I, P가 클라우드 전환 대상이고 A와 E&C는 On Premise를 유지한다.

클라우드 전환 목표

단순한 이전이 아닌 앱의 리팩토링을 통해 성능, 비용 및 안정성 개선을 목표로 한다.

• 클라우드 네이티브 개발: MSA/컨테이너 기반 개발 → 확장성/가용성 향상
• 서비스 구조개선(리팩토링): 앱 구조 개선 → 단위 성능/속도 향상
• 오픈소스 DB 전환: 탈 오라클 → 비용절감/종속성 제거
• TCO 구조 혁신: 중복 기능/데이터 제거 → 투자비/운영비 최소화

현재 DB의 구조적 이슈

현재 DB는 모놀리식 구조이고, 이로 인해서 발생하는 이슈는 다음과 같다.

• 환경 변화
  • 망 진화로 인한 관리 대상 장비 및 데이터 증가
  • 자동화 및 데이터 분석 등 연동 요구 데이터 증가
• 확장성 한계
  • 수직적 확장에 의존
  • 수평적 확장을 위해서는 DB 및 앱 재설계 필요
• 성능 이슈
  • 처리 및 연동 데이터 증가에 따른 성능 이슈 발생
  • AI 기반 앱 진화에 어려움 발생
• 비용 증가
  • 시스템 확장에 따른 S/W 라이센스 비용 부담 증가
  • 단일 솔루션 의존성 경감 필요

이러한 이슈들을 해결하기 위해서 오픈소스 데이터베이스로 전환하기로 결정했다.

오픈소스 DB 전환 여정

01 전환 단계별 검토 필요 항목

02 적합한 데이터베이스 선택

03 성능 확보 및 확장성을 고려한 DB 분산 설계

04 SQL 전환 가이드 작성 및 활용

05 데이터 마이그레이션

06 Graviton 적용을 위한 테스트 결과

Graviton 활용은 거의 필수적이라고 할 수 있다.

07 비용 최적화

Lesson Learned

향후계획 (23년)

애플리케이션 구조 개선 및 S3 활용 확대를 통한 비용 절감추진

1. TANGO의 클라우드 전환 지속 추진(3G, LTE, IP 감시 기능 등) : 오픈소스 DB 전환 확대
2. 비용 절감을 위한 애플리케이션 구조 최적화 : 캐쉬 활용 및 사용성이 적은 DB는 S3로 전환 확대
3. 서버리스 DB 활용 방안 검토중 : 사용률이 낮고, 절체 시간에 민감하지 않은 Slave DB에 적용 예정