2023 AWS SUMMIT SEOUL 후기

Hyeona·2023년 5월 6일

Conference aws

📝 다양한 활동 후기

목록 보기

1/1

🖥️ AWS Summit

일시 : 2023.05.03(수) ~ 2023.05.04(목)
장소 : 서울 코엑스 컨벤션 센터

AWS summit은 코로나19 이후 정말 오랜만에 오프라인으로 열린 오프라인 컨퍼런스입니다.

2019년에 학과에서 친한 선배가 참석하시는 걸 보고 정말 가보고 싶고 궁금했던 컨퍼런스인데,
2020년 코로나19가 창궐하면서 온라인으로만 열리게 되었습니다.

그 이후 컨퍼런스는 잊은 듯이 살았었는데, 2021년 SSDC에 발표자로 참석한 이후에 컨퍼런스들에 관심을 많이 가지게 되었습니다.

필자의 2021 SSDC 발표 후기

그리고 정말 오랜만에,,, AWS Summit이 오프라인으로 열렸습니다!!!!!
사전에 신청을 해두었는데, 직전 날 문자가 올 때까지 잊고 있었습니다ㅋㅋ 🤣ㅋㅋ

하지만 문자받자마자 가야겠다 결심했죠!!
결과에 쓰긴하겠지만, 저는 1일차(3일)만 참여를 했습니다!

✍🏻 접수

접수는 3월 7일에 메일이 오면서 시작했었습니다.
광고성 메일은 쉽게 차단하는데 AWS는 광고도 받아보고 있었습니다.
그렇게 기다렸다면서 왜 잊었냐고 하시면, 3월 초에 접수하고 2개월 간 현생을 살았다고 해명해봅니다 ㅎㅎ

혹시라도 AWS 메일링을 희망하시면 여기에서 신청해주시면 되겠습니다.
실제로 이 때문이였는지, 빠르게 조기 마감이 되었다고 합니다.

AWS SUMMIT SEOUL

📚 필자의 사전 배경

필자는 현재 취업준비생(무직)으로 참여했고, 주변에 함께 가자고 권유할 때 가장 많이 걱정하는 것이 ‘가서 아무것도 알아듣지 못할거같은데’라는 고민이였던 것 같습니다.

그렇다면, 필자는 AWS를 어디까지 이해하고 사용해보았나? 그래서 얼만큼 이해했는가?면 다음과 같습니다.

AWS EC2
AWS S3
Route 53

깔끔하죠..? ㅎㅎ

Instance를 재정상태에 맞추어 선정해서 개설해서 인아웃바운드 세팅, 도메인 연결과 s3 세팅 말고는 크게 사용해본 적이 없습니다.
Database 역시 RDS가 아닌 EC2내 mysql를 직접 설치해 cli로 관리하는 식으로 했습니다.

이 말인 즉슨, 네 크게 아는 바는 없습니다 ㅎㅎ

말그대로 AWS를 통해서 “배포”라는 것을 처음 경험하고 이에 큰 매력을 느껴서 시작을 한 케이스입니다.
(재정적인 부담으로) 이론적인 서버 구조와 진행에 대해서 고민하고 공부하며, 관련 커뮤니티를 보는 관심이 매우 많은 사람입니다.

지금 운영하고 있는 AWS EC2가 있고, 지금도 새롭게 설계하고 있는 서비스가 있지만
따지자면 클라우드 응애입니다.

매우 좋아하는 응애…ㅎㅎ

자, 그럼 사설은 이제 접고 어땠는지 한 번 후기를 남겨보도록 하겠습니다.

🎉 Summit 당일

매일 8시 30분 전후로 겨우 일어나던 제가… 일찍 일어나서 챙겨서 출발했습니다.
(그래도 기조연설 시작하고 5분 뒤에 도착했다는…)

컨벤션에 들어가자마자 길을 잃을까 걱정했는데, 스탭분들이 너무 친절하게 팻말을 들고 있어주시더라구요.
진짜 덕분에 혼자 갔지만, 잘 찾아갔습니다 ㅎㅎㅎ

정말 길에 이어진 AWS를 보고 마음이 웅장했습니다.

🏃🏻‍♀️ 입장

사전 등록자들에게 메일 + 문자로 꼼꼼하게 QR 코드를 보내주십니다.
이 내용을 입장 시 확인하면, 태깅 가능한 카드를 주시는데, 이렇게 나옵니다.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
이렇게 나올 줄 몰랐습니다.
상단엔 소속(회사) 중앙엔 이름, 하단엔 직급인데,
막 신청할때 출퇴근을 안하는 행복에 잔뜩 빠져있어서 소속도 직급도 없는 저는 통계 자료인 줄 알고 솔직히 썼다가..ㅋㅋㅋ
이름에 써주는거면 말씀해주시지 ㅠㅠㅠㅠㅠㅠㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
누가 보면 취업박람회오는 줄 알것다~~하면서 웃으면서 다녔습니다…ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
혹시라도 다음에 누가 접수하신다면 참고하세요 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅋㅋㅋㅋㅋㅋㅋㅋㅋ
미래의 나도 꼭 참고하길..ㅠㅠㅠ

🎙️세션

모든 세션을 듣지는 않고, 듣고 싶은 세션만 들으면서 Expo도 관람하고,
반갑게 오랜만에 만난 지인도 만나는 (대화합의 장인) 시간을 가졌어요. 🥰

하지만, 세션에 대한 내용도 너무 귀중하고 좋았습니다.
제가 이해한 내용을 바탕으로 작성한 메모를 공유드리고자 합니다. 필요한 분들이 있다면 봐주시고, 잘 못된 것이 있다면 공유해주세요!

추가적으로 저도 메모를 다시 보면서 요약할 겸 이미지를 만들어보았어요! 이해에 더 원활한 보조 자료가 되면 좋겠습니다.

1. 기조연설

한 줄 요약 : 해당 기조연설은 앞으로의 현재의 개발 흐름과 미래를 위한 AWS의 발전 방향성을 엿볼 수 있는 세션이였습니다.

Title : 강력한 데이터 전략의 핵심요소
Speaker : Nandini Ramani

포괄성
- 현재 AWS는 누구나 사용할 수 있는 Generative AI(생성 AI) 파운데이션 모델을 통해서 진행하고 있음
  - 목표를 위해 Amazon Bedrock을 발표하였으며, 이 파운데이션 모델을 사용하여 생성 AI 애플리케이션을 구축하고 확장하는 가장 쉬운 방법으로 말할 수 있음.
- 인프라 관리 없이 API를 통해 파운데이션 모델 기반의 생성 AI 애플리케이션 개발을 가속화하고 있으며, 누구든지 이를 활용해 발전하는 것을 권장함
- AI21 Labs, Anthropic, Stability AI 및 Amazon에서 적합한 기능을 제공하고자 함
통합성
- 데이터를 사용하기 위해서는 추출(Extract) > 변환(Transform) > 로딩(Load)의 과정을 수행함.
  - 이 과정을 ETL이라고 부름
  - 현재 데이터를 사용하는 속도에 비해서, 추출/변환하는 과정의 리소스를 굉장히 많이 사용하는 편임.
  - 따라서 이러한 리소스를 줄이고 애플리케이션 개발에 초점을 맞추는 것이 목표임.
  - 이는 AWS 데이터 서비스를 통해 밀접한 데이터 통합을 할 수 있는 흐름을 만들고 있음
- Zero ETL 시대 : 신속하고 손쉽게 접근하면서 연동할 수 있는 것이 지금의 비전
거버넌스
- 데이터들은 적절한 시기에 적절한 권한을 가진 사람에게 적절하게 제공하는 것이 중요함.
- AWS 거버넌스 도구 기본 제공
  - AWS lask formation S3 기반의 데이터 관리
  - Amazon sagemaker ml governance : 종단 간의 ML 개발을 위한 거버넌스
  - Amazon datazone : 기업 내의 데이터 분류, 검색, 공유 및 관리
    - 가장 최근에 Preview로 공개함
    - GUI 기반의 좋은 가시성을 보여주며, 권한과 접근/로그 등의 다양한 내용을 진행함
    - 현재 이를 통해 더 좋은 내용을 적극적으로 진행할 수 있음
- 종단과 종단 간의 데이터 전략을 구축되어야 함

2. 카카오 채팅 서비스

한 줄 요약 : 목표 데드라인에 맞춘 빠른 개발과 함께 의사결정을 할 수 있는 경험을 공유해주셨습니다.

Title : 천만 사용자를 위한 카카오의 AWS Native 글로벌 채팅 서비스
Speaker : 김영욱 AWS 솔루션즈 아키텍트, Walter Kakao 실장

시작 전 꼭 확인하고 갈 점
- 글로벌 서비스 구축에 대한 고려사항과 불확실한 내용 등의 사례를 공유함
- 카카오톡이 아닌 카카오 중 하나의 사례로 진행함
글로벌 채팅 서비스 요구사항과 구축 전략
- 요구사항과 전략 : 비즈니스의 문제를 해결하는데 걸림돌을 줄여야 함
  - 글로벌 서비스 출시 : 한국을 넘어선 세계화 진행
  - 중요한 것에 집중하기 : 소수의 인원이 선 수행을 해보는 과정을 위해서 중요한 것에만 집중하기로 함 ⇒ 빠르고 바른 의사 결정
- 3가지 전략
  - 글로벌 인프라스트럭처
    - 리전의 구별을 통해, 속해 있는 사용자에게 빠른 전달을 진행할 수 있음
    - 만약에 데이터센터를 갖고 있다면, 직접 연결해 더욱 빠르게 진행할 수 있음
    - AWS 네트워크 설계
      - 언제나 데이터 센터가 안정하게 운영하게 되는 것이 중요하게 생각될 것이다.
      - 복잡한 연결은 하나의 부재에도 정상적으로 운영이 될 수 있다는 의미를 갖고 있는 것이다.
  - 서버리스 : 전세계를 진행하면서 운영의 부담을 줄일 수 있기 위해
    - IT의 자원 유지보수는 클라우드에게 양보하는 것이 중요했다.
    - 실제는 진행하고자하는 개발자를 모집하거나 꾸준히 진행하는 것에 어려움이 있었다.
    - 따라서 이를 AWS에 많은 기능을 통해 서버가 없는 것처럼 가볍게 실 서비스를 가져갔다.
    - 주요 서버리스
      - Lambda
        
        이벤트 소스에서 변경이 오면 요청을 통해 상태를 변경해 배포/운영 등을 작업처리한다.
        
        지금은 더 독립적으로 진행하며, 실행 이후에 자동으로 정리하기에 비용측면에서도 이득이이있었다.
      - DynamoDB
        
        채팅의 정보는 빠르게 생성되고 전송되어야하기에, 이를 기준으로 선정하였다.
        
        key-value를 기준으로 진행하는 것이며 일정한 작업시간 (O(1))을 갖고 있다.
      - IoT Core
        
        다양한 클라이언트의 자연스러운 연결을 위해 필요한 부분이다.
        
        이는 실제로 연결과정에서의 인증을 확인받아야하며, 이벤트를 처리하는 등이 필요하다.
  - 프로토타이핑 : 진행 판단 기준을 위해 실행
    - 포로토타입
      - 최종사용자 경험과 유사한 직관적인 제품 구현
      - 비즈니스 성과 예측 용이
      - 의사결정을 위한 적절한 비용 투자
    - AWS에 프로토 팀이 따로 있기에 이를 통해서 실제 상황을 예측하고, 의사결정을 내릴 수 있다.
    - 이 과정을 통해서 예상치 못한 부분들을 확인할 수 있었다.
카카오의 글로벌 채팅 서비스 구축 사례
- 핵심
  - 카카오의 많은 서비스 중 일부에 대한 이야기
  - AWS로 구축할 수 있는 채팅의 한계에 대한 호기심
- 채팅 서비스의 요청사항
  - announcing Web socket apis in amazon api gateway
    - restful api 에서의 확장
    - 웹 소켓 : 실시간 처리에 대한 새로운 가능성
    - 매력적인 단순한 구조 : 개발에서 배포까지
  - sample chatting architecture XMPP
    - scale-out 가능한 구조가 되기 위해서 메시지 공유 가능한 브로커와 로드 밸런서 등 추가 필요
  - Simple is the BEST
    - AWS 서비스를 활용하여 관리 포인트 감소
  - 예전과 다른 채팅 요구사항
    - 예전 : 접속 상태 확인, 메시지 즉시 전달 → 조금 더 근본적인 이야기
    - 현재 : 메시지 보관, 답글 달기, 공지, “좋아요” 달기 → 채팅을 더 활용적으로 사용하기(게시판의 역할까지 겸용하고 잇음)
  - 기능 제공 전략 : 스케일 아웃이 가장 핵심으로 진행하였다.
    - 빠르게 확장 가능한 컴퓨팅
    - 빠르게 상태를 업데이트할 수 있는 데이터베이스
    - 실시간 갱신 정보를 위한 Pub/Sub
      
      ⇒ 상태가 없는 서버, 실시간 갱신이 가능한 데이터베이스, 그 외는 클라우드기술을 쓰면서 빠르게 확장가능할 수 있도록 진행하고자 함
- 구현
  - 안티 패턴 배제 : 이전의 설계 경험을 바탕으로 대규모 시스템과 맞지 않는 패턴 사용 자제
    - 오라클과 MySQL은 pk에 자동으로 id가 등록되지만, dynamoDB는 이런 것이 없음
  - AWS 솔루션스 아키텍트 협업 : 프로젝트 초기부터 AWS팀과 협업하여 서비스에 최적화된 솔루션 검토
  - 기술과 기획의 타협 : 엔지니어링 비용과 고객 만족 사이이 적절한 가성비
- 결과
  - 서비스 런칭, 성공적 : 아무런 오류 없이 서비스 런칭
  - 드라마틱한 관리 비용 감소 : 맨먼스(MM) ~~ 0
  - 요청 쇄도 : 다른 서비스에서도 채팅 적용 요청 급증
- 추가도전
  1. 글로벌 지원 요구
    - 여러 리전에 접속한 유저들의 채팅 지원
      - 분석 결과 : 대부분의 트래픽은 리전 안에서 발생하지만, 리전을 넘어서 채팅하는 경우도 드물게 발생
      - 아키텍처 개선 : 기존과 동일한 구조를 사용하지만 리적을 넘는 통신과 그롤벌 데이터베이스 동기화 지원
        
        ⇒ 리전 확장, 스토리지 지원
    - 글로벌 아키텍처
      - 선택한 근본적인 해결 방법
        
        리전 간 API 호출 시 낮은 지연 시간 : Amazon API Gateway
        
        다른 리전의 정보는 API를 통한 접근 : AWS Lambda
        
        리전 간 데이터 동기화 : Amazon DynamoDB Gobal Table
        
        → 의존은 최소화하는 방향으로 진행
      - 글로벌 확장 결과
        
        간단한 구축 : 이미 구축했던 AWS 환경 위에서 Route 53 기능 추가
        
        드라마틱한 관리 비용 감소 : 관리비용은 0에 수렴
        
        용도 확장 : 서비스 런칭 이후 다른 용도로 활용
        
        중국은 조금 특이해, 진행하기 위해서는 다른 서비스 앞에 붙어서 프록시 하는 역할을 진행했어야 했었음
  2. 카카오에서 서비스 (대규모 서비스 대응)
    - 요구사항
      - 높은 사업 목표(글로벌 사용자 DAU 1천만, MAU 1백만 이상) + 낮은 숙련도(AWS Native에 대한 경험 부족)
    - 문제해결
      - 높은 사업 요구치 : 쿼드 안에서 동작 가능하도록 설계, 급증하는 요청에 대비하기 위한 스트림 파이프라인(큐의 역할) 마련, 성능 테스트를 통해 검증
      - AWS에 대한 숙련도 : 프로토타이핑과 immersion day를 통한 개발자 숙련도 증가
      - AWS의 지원 : 아키텍처 리뷰, 성능 테스트, 쿼터 상향 신청 방법 등 AWS 팀의 지원
        
        ⇒ 천만 사용자를 위한 AWS Native 채팅 서비스
    - 글로벌 아키텍처 개선
      - 초기 : Amazon API Gateway + AWS Lambda + Amazon DynamoDB
      - 추가 : AWS IoT Core(MQTT) + Amazon Kinesis Data Stream
      - 심화 : Amazon Cognito + AWS Web Application Firewall (WAF) + AWS Cloud Developement Kit (CDK)
        
        ⇒ 이를 함께 쓰면서 효과적인 시너지를 냄
- 그럼에도 AWS Native를 사용한 이유
  - 코드 기반 운영 자동화
  - 소프트웨어 수명주기 : 개발 기간 < 운영 기간
  - 빠른 속도로 요구사항 수용
  - 글로벌 지원
마무리
- 클라우드 네이티브 접근 방식의 이점
  - 효율성 증가
  - 비용 절감
  - 가용성 보장
- 데이터센터, 인프라, 플랫폼, 안정성의 관리 부담은 덜고 핵심 비지니스 가치에 역량을 집중하는 것이 핵심

3. 삼성전자/쿠팡 대규모 처리

한 줄 요약 : 대규모 트래픽을 처리하는 서버 구조의 단계적인 변화와 성과도 직접 볼 수 있었습니다.

Title : 삼성전자/쿠팡의 대규모 트래픽 처리를 위한 클라우드 네이티브 데이터베이스 활용
Speaker : 김영진 AWS 솔루션즈 아키텍트, 권용석 삼성전자 프로, 김티나 쿠팡 DBA

현대 어플리케이션의 특징
- 이미 사용자가 수백명을 넘어가며, 데이터 볼륨 역시 큰 경우! ⇒ 이는 하나의 관계형 데이터 베이스를 사용하지 않음, 따라서 하나의 엔드포인트를 사용해 리전 등을 통해 다른 결과를 보여줌 이뿐만 아니라 하나의 디바이스가 아닌 다양한 미디어를 통해 전달함.
- 자체 디비의 어려움
  - 하드웨어 및 소프트웨어 설치, 구성, 패치, 백업
  - 성능 및 고가용성 문제
  - 컴퓨팅 및 스토리지를 위한 용량 계획 및 확장 클러스터
  - 보안 및 규정 준수
- 목적에 맞는 데이터 베이스를 사용할 수는 없을까?로 시작한 고민들…
삼성전자의 선택 : Shared Repository Architecture style 디자인 전략
- 적절한 시스템을 선정하는 것은 굉장히 중요하면서도 어려운 이야기..
- Rich Communication Service(차세대 메시지 플랫폼 : GSMA, TTA)
  - 이러한 RCS를 표준화로 만들어진 플랫폼으로 Chatbot Platform, NNI, Capability Discovery, Group Messaging, Instant messageing, File Transfer, SBC 등의 다양한 내용을 제공함 ex) 카드 결제 문자 등
  - 배경 : RCS 1.0 마이그레이션해서 “Lift and Shift “ 전환, 모놀리식, 클러스터당 1000000명의 사용자, 각 사업자에 대해 10~20개의 클러스터를 사용함 ⇒ 문제점 : 한 클러스터를 사용하면 다른 클러스터를 사용하기 어려웠음
  - 2.0 재설계 : 진행하며 마이크로 서비스 아키텍처를 진행했다. 하위 도메인으로 분리함 ⇒ 의존도를 낮추면서 정합적을 높이는 과정을 진행하는 것을 공유 저장소 아키텍처라고 함. 이는 정합성과 성능의 이슈에 초점을 맞춘 내용
- 핵심 2가지 문제
  1. 챗봇 브랜드 정보 제공 서비스 : 읽기 성능 품질 요구가 최우선인 경우
    - 대표적인 성격
      - 도메인 성격 : 매우 많은 읽기, 매우 적은 쓰기
      - 서비스 성격 : 높은 읽기 성능 품질 요구(응답시간) 클라이언트 캐시가 구현되어 있음 ⇒ 정합성이 떨어져도 속도의 면에서 확인하고 수용할 수 있는 불일치성이 있다는 것을 이야기 함. 오로라같은 디비를 사용해서 진행할 수 있음
    - 사용자에게 가장 빠르게 진행하는건 대상 기능과 연관된 메모리에서 읽어오는 것이 가장 빠름. 그렇기에, Local 에서는 Last Cach에서는 이를 인식하기가 늦기에 정합성 파괴의 시간이 늘어남. 이를 엘라스틱을 통해 최소화했음. → 이 역시 정합성의 파괴의 시작을 예측할 수 있어야하고, 요구사항에 만족하는 범주에서일때믄 수용해야함.
  2. 가입자 연결 정보 제공 서비스 (정합성 품질 요구가 최우선인 경우)
    - 대표적인 성격
      - 도메인 성격 : Handover, WIFI 전환 등 이동통신단말의 잦은 주소 변경 정형 데이터
      - 서비스 성격 : 메시지 누락, 오 전송에 매우 민감, 연결 정보 획득 성능이 메시지 송신 성능에 영향을 줌 ⇒AWS DynamoDB나 오로라를 사용할 수 있지만, 정확성 품질을 확실하게 받지는 않음.
    - 이미 있는 기능 써보기
      - DynamoDB - Strong consistency read
      - Aurora - Consistency lock
        
        → 하지만 이는 업데이트 될때마다 읽는 과정이 있어서 더 정제가 필요해야했음. 이를 통해 ElastiCache를 추가해서 더욱 좋은 결과를 보고자 함.
        
        따라서 이는 결과적으로 DynamoDB Strong consistency read + ElastiCache + Data Provider Service + Elastic Cache Consistency lock을 직접 구현하는 방식으로 진행함.
- 결과
  - 성능(처리량) : 개인 5배, 기업 10배 향상되었음
  - 비용 : 30% 절감
  - 장애 : 장애 발생율 RCS 1.0 대비 13%
    
    ⇒ 목적에 맞는 Managed Service와 도메인 특성을 반영한 전략이 결합되어 견고한 서비스를 만듦
- 이제는…
  - RDBMS의 설계를 더 최적화하거나 로드밸런싱을 했던 기간을 거쳐서 AWS과 같은 툴이 생김. 앞으로는 이런 기술을 활용해서 더 넓은 기술로 확장되어야하는 것이 숙제라고 생각함.
대용량 트래픽, 쿠팡의 DB 엔지니어가 클라우드를 사용하는 방법
- MSA를 목표로 진행한다.
  - 더 세분화 된 마이크로 서비스 아키텍처
    - 하나의 노드가 수용할 수 있는 트래픽은 한정되어 있음
    - 마이크로 서비스 아키텍처를 기반하여 서비스 되고 있지만, 그럼에도 불구하고… 불가는하거나 더 세부적으로 되어야하는 경우들이 있음
    - 점차 DML, DDL, ACL 작업 요청 증가가 기하급수적으로 늘어났음
- 스마트 지원 서비스 (새롭게 도입하고자 함)
  - 목적
    - 반복되어 요청되는 작업을 자동으로 수행해주는 것으로 함.
    - 스마트 지원 서비스는 관리자와 사용자 모두에게 편해야 함.
    - 신뢰 가능한 서비스여야 함.
    - 스마트 지원 서비스가 입무를 진행함에 또 다른 허들이 되어서는 안됨.
  - 도입 조건
    - 신뢰가능한 메타 정보 제공 : 최신의 서버 구성 정보 제공
    - 장애에 대한 즉각적인 대응
      - 예측 가능한 장에에 대한 방어 프로세스
      - 모니터링, 에러 로그
    - 커뮤니케이션 최소화 (런칭 후 가장 많은 비용이 소비되는 부분)
      - 데이터베이스 표준화
      - 쉬운 서비스 가이드 문서 및 Q&A
      - 에러 패턴 정리
  - 예제
    - DML작업 수행
      - 한달에 400~500건의 요청을 수행함
      - 이는 책임자를 통해서만 승인이 가능하며, 승인을 위한 절차를 무수히 많이 수행했어야했다.
        
        절차 : 데이터베이스 엔지니어에게 업무 요청서 작성 → 롤백 데이터 생성 → DML 수행 → 변경된 데이터 확인 → 업무 요청서 완료 처리
        
        이 절차를 담당자가 진행하면, 급한 에러와 다음 업데이트 등의 이유로 더 불편하고 즉각적이지 못했다. 이 절차를 스마트 지원 서비스로 묶어서 발전시켰다.
    - DDL 작업 수행
      - 한달에 약 300건의 요청을 수행
      - 이는 많은 담당자가 있고, 에러의 위험이 많은 곳에 있는 곳이다.
        
        절차 : 업무 요청서 작성 → 리뷰 → 커뮤니케이션 → DBA → DDL 수행 → 변경된 스키마 확인 → 업무 요청서 완료 처리
        
        최소한 2일이 소모되었으며, 대용량의 DDL이 들어오면 책임자의 피로가 컸다. 이부분 역시 스마트 지원 서비스로 묶어서 발전시켰다.
  - 결과는?
    - 각 클러스터에 따라 진행하는 바가 중요하므로 1건으로만 제한하도록 했다
    - 각 벨리데이션을 체크하고, 성능을 확인하면서, 스케줄러까지 플랫폼으로 작성하면서 이에 대한 업무 피로도나 추가 업무 수행이 많이 줄어들게 되었다.
- 서비스 안정화 방법
  - 세션 관리
    - 트랜잭션 모니터링
    - 오래 수행되는 쿼리 모니터링
    - 서버의 일정 성능을 보장하기 위하여
  - 데이터 사이즈 관리 : 데이터 사이즈가 큰 데이터를 기준으로 자동 백업
  - 쿠팡의 블루/그린 서비스
    - 목적 : 데이터 베이스 가용성 확보
    - 가용성
      - 서버 버전 패치
      - 데이터베이스 마이그레이션
      - 대용량 테이블 변경
      - 유지/보수
    - 실제 적용 : 역동기화 등이 내용을 통해 진행했음
- 쿠팡의 목표 : 고객 중심의 고민
특수 목적 데이터베이스를 선택 시 고려해야 할 요소 정리
- 어플리케이션 워크로드
- 데이터의 형태
- 어플리케이션 성능 요구사항
- 운영부담
⇒ 개발자는 이제 특별히 구축된 다양한 데이터베이스를 사용하여 고도로 분산된 애플리케이션을 구축

4. AWS 자격증 시험 준비

본 세션은 Expo 내의 세션이였습니다.
사이에 실제 문제를 보고, 풀어보는 시간이 있었지만 이는 생략합니다.

Agenda
- 시험 안내 및 학습해야할 내용
- 도메인 주요내용 확인
  - 보안 아키텍처 설계(30%)
  - 복원력을 갖춘 아키텍처 설계(26%)
  - 고성능 아키텍처 설계(24%)
  - 비용에 최적화된 아키텍처 설계(20%)
- 합격을 위한 팁
시험 안내
1. 이 시험이 응시자에게 확인하는 내용은?
  1. 현재 비즈니스 요구 사항과 향수 예상되는 요구사항을 충족하도록 AWS 서비스를 통합하는 솔루션 설계
  2. 안전하고 복원력이 뛰어나며 성능이 우수하고 비용에 최적화된 아키텍처 설계
  3. 기존 솔루션 검토 및 개선 사항 결정
2. 취득하면 무엇이 좋은지?
  1. AWS 서비스 전반의 기술에 대한 지식과 기술을 입증
  2. 이해관계자 및 고객 상호 작용에서 신뢰와 자신감을 얻을 수 있음
  3. 개인의 경력 프로필과 소득을 높임
3. 시험 안내서의 내용
  1. 과락은 없고 1000점 만점중 720점 이상 합격
  2. 130분, 65문항(문항당 2분)
공략법
1. 답변 옵션을 보기 전에 먼저, 질문을 읽고 이해해야함
2. 핵심 문구 및 수식 어구를 파악해야하기
3. 주제에 관해 알고 있는 내용을 기반으로 답변 옵션 중 일부를 제거하기
4. 확인된 핵심 문구 및 수식 어구를 염두에 두고 나머지옵션을 비교해야 하기
5. “가장…”이란 문구에 유의하기

🗨️ 종합 의견

대체적으로 들은 세션의 내용은 실제 현업에서 진행되는 클라우드 서버의 활용도 느낄 수 있었지만, AWS와 협업을 활발히 한다는 사실이 더 두근거리게 만들었습니다.
회사에서 하지 못한다해도, 개인적으로도 저렇게 해보고 싶다라는 막연한 목표가 생긴 느낌이였어요.

사실 세션은 기조연설을 포함해 4개 밖에 못 들었지만, 계속 앉아있으려니 쥐가 나려했습니다.
보고싶은 세션이 더 있었지만, 우선 안 일어나면 허리가 아작나겠다 싶어서 Expo에 다녀오려고 했어요.(그리고 놀랍게도 그게 마지막이였습니다…)
세션 외에도 많은 후기가 있어서 이것도 이야기 해보고 싶네요.

🍚 점심 제공

기조연설 쯔음 입장했더니 Lunch 팔찌를 얻을 수 있었습니다.
현장에 가기 전에 밥은 어떻게 먹지~ 근처에 편의점이나 가야지 아님 그냥 굶지 뭐 하고 갔는데, 꽤 기분이 좋았어요 ㅎㅎ
안 잃어버리려고 손목에 꼬옥 차고 다녔습니다.
첫 세션이 마치자마자, 앉은 그 자리에 도시락을 나눠주었습니다.

그냥 플라스틱 도시락을 생각했는데, 너무 퀄리티가 좋았습니다.
무료 도시락이 이정도라고? 호텔에서 준다고? 라면서 생각보다 큰 충격을 받으면서 받아먹었어요.

하지만, 철저한 한국인 입맛이였던 전 느끼해서 빵빵빵빵빵은 다 먹진 못하고, 과일과 샐러드 위주로 먹었습니다 ㅋㅋ

치즈도 안먹지만, 대접해주는 느낌에 감동이였어요.

🔵 Enjoy

이름을 어떻게 정해야할까 고민했는데, 재밌게 즐겨서 Enjoy해보았습니다 ㅋ

세션을 보러가는 길에는 큰 부스들이 있었어요.

Summit의 참여횟수 : 스티커 제공
Answer : 밸런스 게임 진행
단어찾기 : 어려워서 패스…ㅋㅋ

가볍게 즐길 수도 있는데, 재미있는 질문도 많고 스탭 분들도 친절해서 너무 감사했어요.

🗃️ Expo

접수 확인 옆에는 Expo가 있었어요. AWS와 AWS를 적극적으로 활용하고 있는 회사를 체험하고 확인할 수 있는 공간이였어요.

파트너사 부스

Slack, 롯데정보통신, 메가존클라우드처럼 반가운 기업들도 있고, MongoDB나 Redis, RedHat 처럼 꼭 써보고 싶은 곳들도 있었어요.

대부분의 부스들이 직장인을 전제하에 설문을 받거나 질문을 하셔서 취준생을 조금 의기소침했지만, 그럼에도 충분히 재미있게 즐길 수 있었어요.

아쉬운 점이라고 하면, 회사들 마다 미니세션이나 테크톡을 할 수 있는 부스도 있었지만, 대다수 이벤트에만 중심이 맞춰져 있어서 기술적인 인사이트를 얻기는 조금 어려웠던 것같아요.
AWS 부스

다양하게 상담받을 수 있는 채널도 있고, AWS 커뮤니티를 소개해주는 곳도 있었어요.
그리고 크레딧 관련해서 이야기하는 코너도 있었는데, 개인적으로 10년짜리 퍼스널브랜딩 사이트를 개발하고 있어서 이것도 상담을 친절하게 해주셨어요.

무엇보다, AWS의 모델을 이용해 인터렉티브하게 사용할 수 있는 부스들도 있었습니다.

하나는 농구 부스였습니다. 공의 궤도를 인식하고 책정해서 점수를 매겨 등수로 선물을 주는 곳이였습니다. 하지만, 농구는 젬병이기에 선출이였던 짝꿍을 데려올 껄 생각만 했죠..ㅎㅎ

참여했던 부스는 Emotion Gardens입니다.
AWS의 Generative AI를 통해서 표정을 확인해 만들어주고, 추가적인 추천을 활용해 그림을 추천해주는 체험형 부스였습니다.
이미지도 제 얼굴을 찍어서 나올 결과입니다!
QR코드로 받을 수 있고 이미지도 받아서 재미있는 부스였어요.

👝 최종후기

다양한 부스에 참여하고 하면서, 퀴즈를 맞추고 굿즈도 얻고 기업부스에서 선물도 받고 했습니다.
그리고 개발자라면 누구든 좋아하는 스티커도 왕창 얻었네요 ㅎㅎㅎ

AWS 텀블러는 무려 2개나..! ㅋㅋㅋ 물 많이 먹으면서 개발에 전념하겠습니다.

종합적으로 말하자면, 재직자가 아닌 취준생이든 대학생이든 관심이 있는 사람이라면 충분히 참여하기 좋았습니다.
인사이트도 많이 얻고 실제 현업에서 어떻게 활용하는지에 대해서도 배울 수 있었습니다.

물론, 어려운 용어들은 있었지만 발표자님들이 굉장히 풀어서 설명을 해주시기에 이해에는 무리가 없었습니다.
(무리는 제 엉덩이와 허리 뿐…)

1일차만 간 이유는, 처음부터 듣고싶었던 세션들이 1일차에 있었고 2일차는 세션을 고민하는 중이였습니다.
1일차를 다녀오니 Expo도 다 보았고, 체력이 너무 떨어진 상태인데 2-3일 뒤에 코딩테스트라 체력관리를 위해 생략했어요.
정말 다리랑 허리가 무너지는 줄 알았거든요…ㅎㅎ