입문

여기 기사는 CA21 Advent Calendar 2020 12일째 기사입니다!
이번에는 며칠 전 내정자 간의 행사로 AWS CDP 도장 in21(회사 내에서 열리는 AWS CDP 도장 21을 졸업하는 파생 행사)을 개최했는데 그때 느낀 점과 배운 점을 간단히 정리하고 싶습니다!

AWS CDP 도장은 무엇입니까?

실천 형식의 시나리오에 따라 AWS 시스템 설계에 없어서는 안 될 CDP(Cloud Design Pattern)를 설계하고 체험한 세미나 형식의 학습회입니다.

개최 경과

네트워크 에이전트에서는 AWS의 솔루션 프로그래머들이 상주하며 매주 2, 3일 정도의 아키텍처 등에 대한 자문회가 열린다.
그리고 그 중 업무 시간에 다양한 한슨과 행사가 사내를 위한 행사로 열렸다.
이 행사들은 부서를 분배하는 상사나 단체의 허가 아래 업무 시간 내에 자유롭게 참가할 수 있다.(일의 하나로aws의 사람들이 나에게 많은 것을 가르쳐 줄 수 있어서 나는 개인적으로 매우 기쁘다 w)
과거에 했던 것들로.

Well-Architected 프레임워크 강좌

AWS Amplify Hanson 강좌

AWS GameDay( https://developers.cyberagent.co.jp/blog/archives/26934/ )

등등
그리고 이번에 사내 활동으로 AWS CDP道場 하게 되었습니다.
나 자신의 업무는 매우 바빠서 참가하기가 매우 어렵다😭
그래서 참가하지 못했다.
근데 제가 참가한 두 동기들한테 물어봤어요.
"너무 좋아요!"
이런 목소리를 얻었기 때문에 어쨌든 내정자와 함께 aws 구조를 고려한 회의를 열고 싶어서 개최하기로 했습니다.
또한aws의 사람에게 이 뜻을 말하게 하였는데, 그날 사용한 자료는 곧 얻을 수 있었다
그걸 바탕으로 행사를 했어요.

시간표

이날 일정은 이런 일정에 따라 진행됐다.
제목을 발표한 후 바로 구조 설계를 시작하려면 1시간 안에 구조를 고려하고 그림을 정리해야 하기 때문에 매우 어렵다.

이번 제목.

이번 제목은 상술한 조건을 만족시킨다
서비스를 고려한 인프라입니다.
일의 기능이 많으면 당연히 말할 필요가 없다
채팅 트래픽 10만 req/s, 데이터 트래픽 10GB/s의 처리 속도도 매우 높다

우리 팀의 구조

이러한 요구 사항을 확인한 후 한 시간 동안 저는 팀 구성원과 함께 체계 구조도를 고려했고 최종적으로 다음과 같이 설정했습니다.

요소도 상당히 많고 난잡하기 때문에 이번에는 대략 6곳에 대해 간단하게 설명하고 싶다.
① 주요 애플리케이션 서버
이번 주요 애플리케이션 서버는 ECS입니다.
가장 큰 원인은docker를 사용하면 현지 환경과 생산 환경의 환경 차이를 줄일 수 있기 때문이다.또 다른 선택으로 EKS(kubernetes)도 선택했지만 버전 업그레이드 속도의 어려움과 학습 원가의 높낮이를 따라가지 못해 이번에는 배제했다
② 데이터베이스
이번 사용자 정보 등은 아마존 오로라, 채팅 등은 아마존 다이나모 DB로 구성된다.
어플리케이션에 여러 개의 DB의 종류가 있어서 사용하기가 좀 번거로운 것 같지만 이번 필수 조건은 チャット流量10万req/s이기 때문에 RDB는 처리가 늦어질까 봐 이번 채팅의 DB만 사용하기로 했습니다.
③CI/CD
github action, code build, code deploy 등을 사용하여 CI/CD 파이프라인 구축
④ 불필요한 데이터 처리
이번 필수 조건은 메시지 저장 기간은 1년이지만 채팅 앱에서 1년이 지나면 데이터가 완전히 삭제된다는 것이다. 이런 방법은 문제가 있다.DynamoDB의 생명주기 정책을 사용하면 1년 후의 채팅 데이터는 삭제가 아니라 S3Glacier라는 s3보다 저렴한 저장소에 저장된다
⑤ 읽어들이기 기능
검색 기능에 관해서awsbatch와lambda를 사용하여 새로운 채팅 데이터를 일정한 주파수로 Elasticsearch의 구조에 추가하여 대응하였다.
검색 기능의 즉각성은 줄어들지만 대량의 데이터를 계속 보내는 상태가 Elasticsearch에 과도한 부하를 줄 수 있음을 감안하여 이렇게 처리했다
⑥ 알림 기능
마지막 알림 기능은 SQL에서 알림 데이터를 수집하고 lambda로 윤문하며 SNS로 알림을 보내는 구조입니다.SQL을 사용하는 이유는 알림 처리에 상당한 부하가 필요하기 때문에 처리가 어느 곳에서 막히더라도 알림 기능은 전체적으로 사망할 수 있다.
지금까지 우리 팀의 발표였습니다.
물론 우리도 이것이 가장 좋은 구조라고 생각하지 않고 다른 팀의 발표를 재고하고 듣는 과정에서

보안 주변 구조를 아키텍처 맵에 반영하지 못했습니다

Kinesis를 버퍼 전송 서비스로 사용하지 않음

등 아직 고려할 점이 많다.

총결산

이 같은 형식으로 나머지 3개 팀은 발표, 각 팀의 발표에 대한 질문 답변 등을 진행했다.
팀이 안전 주위를 고려하여 메인 서버에서 EKS(kubernetes)를 사용하는 것은 나 자신에게 매우 많은 학습의 기회가 되었다.참가자들도 설문조사를 했는데 전반적으로 평가가 높았고 기회가 된다면 직원들도 휘말려 다양한 행사를 열었으면 좋겠다!
그래도 내정자 때부터 이런 느낌이 들었는데 서로 기술을 향상시키는 환경에서 정말 행복했어요!