[Seminar] AWS Summit 2023 Seoul 1일차 [2/2]

점심시간을 꿀맛으로 먹고, 이제 오후 세션을 들었다. 오후에는 일부 솔루션 소개타임도 있었고,

실제 회사의 사례를 기반으로 한 발표도 있었는데 솔루션 소개타임은 스킵하였다.

 - 다른 스타트업과 다 마찬가지로.. 신규 솔루션 도입을 현재 어려운 상황이다 ㅜㅜ

 

삼성전자/쿠팡의 대규모 트래픽 처리를 위한 DB 사용

재직중인 회사에서 자주 문제가 발생하는 것이 Elasticache, RDS Connection Full 문제다..

그래서 타사에서는 어떻게 사용하고 있는지 궁금하고 좋은 아키텍처를 알아보기 위해서 들었던 세션이였다.

 

삼성전자

삼성전자에서는 채팅플러스라는 서비스를 만들었는데, 처음에는 모놀리식 구조로 되어 있어서 매우 많은 클러스터가 필요했고, 서비스 사용량이 증가함에 따라 클러스터 자체 용량을 늘려야하는 문제점이 있었다고 한다.

 

그래서 2022년에 이를 MSA 구조로 변경하는 작업을 하였고 MSA 구조로 전환됨에 따라서 사용량이 많을때는 전체 클러스터가 아니라 필요한 서비스만 증설하는 방향으로 효율적으로 사이즈를 늘릴 수 있어서 비용적으로 많이 절감하였다고 한다.

 

하지만, MSA로 전환되면서 데이터 호출에 대한 문제점이 생겼고 이를 공유 저장소 아키텍처로 전환하면서 문제를 해결하였다고 한다.

즉, 공유 저장소라고 모든 MSA의 정보를 저장하는 데이터베이스를 만들고 해당 데이터베이스를 관리하는 MSA 서비스를 만들어서

해당 서비스를 통해서 데이터를 호출하는 구조이다. 이때 데이터베이스를 RDS를 사용할지, ElastiCache를 사용할지에 대해서 사업 구조와 요구조건에 따라서 결정하였다고 한다.

 

데이터의 쓰기보다 읽기가 많은 경우

재직중인 회사에서는 모두 위와 같은 방식을 채택하고 있다. 현재는 이전의 만들어진 시스템 구조라서 별 대수롭지 않게 생각했는데 어떤 작업이 더 많은지에 따라서, 성능과 정합성에 따라서 데이터베이스 시스템을 달리 선택할 수 있구나. 새로운 시야로 보게 되었다.

 

데이터의 정합성이 우선인 경우

 

데이터의 정합성을 우선하는 경우이다.

RDS + Elasticache는 빠르게 읽을수는 있지만, Cache이고 RDS Read instance로 읽기 복제 지연이 발생하기 때문에 다소 정합성이 떨어질 수는 있다. 이런 상황에서는 DDB + Aurora를 사용한다고 한다.

- DDB를 단순히 AWS Managed DB로만 생각했는데 이런 시각으로 보는것도 한 방법인것 같다.

 

재직중인 회사에서는 특히 DDB만으로 운영하는 시스템이 있는데, 정합성을 위해서 선택한것일까?하는 의구심이 생긴다.

 

쿠팡

쿠팡은 사실상 사업이 커짐에 따라 DB 작업이 많아졌고, 이를 DBA 시스템을 통해 자동화했다는 내용이 주였다.

물론 이러한 시스템이 있으면 좋으나, 당장 구성할 수 없고 내 입장에서도 조금 벗어나는 주제라고 생각해서 특별히 정리하진 않았다.

 

스타트업의 빠른 성장, 안정적인 운영 서비스 운영 노하우는?

재직중인 회사가 스타업인만큼, 다른 스마트업에서는 어떻게 인프라를 운영하고 개발을 하는지 궁금해서 들은 세션이였다.

비마이프렌드와 스캐터랩에서 발표하였는데, 나름 사업 규모도 비슷하고 특히 발표자가 데브옵스 엔지니어여서 좋은 내용이 많이 있을것 같았다. 그리고 실제로도 현재 팀에서 고민하고 있던 부분 그리고 도입하려고 했던 시스템이 많이 있었다.

 

Bemyfriends

Bemyfriends에서 빠른 노드 증설을 위해 Karpenter를 사용한다고 한다.

재직중인 클러스터에도 모두 Karpenter를 사용하고 있고, 이를 CAS와 비교하는 게시물도 작성했는데 확실히 Karpenter는 좋은 오픈소스이다. Spot Instance를 사용하는 관점에서도 좋고/Consolidation 옵션을 통해 사용량이 적은 노드도 Drain 하기 때문에 아주 비용 효율적이다.

 

Bemyfriends에서는 아래 기술을 서비스에 사용한다고 한다.

• NetworkPolicy
  • 재직중인 회사에서도 사용하고 있는데 Pod끼리 통신을 제어할 때 사용하고 있다.
  • 그치만 여러 커뮤니티와 주변의 이야기를 들어보면 많이 사용하는 시스템은 아닌것 같다.
  • NetworkPolicy를 사용하기 위해서는 Calico를 사용해야 하는데 Node ENI에 영향을 주다보니 처음 설치에도 고생이 많았고
  • 클러스터 업데이트할 때도 고생이 많았어서 굳이 필요할까..? 의문을 품고 있는 시스템이다.
• Secret Manager
  • 비밀정보를 관리 및 사용하기 위해서 사용한다고 한다. 재직중인 회사에서는 Vault를 사용하고 있다.
  • 과거에는 Vault가 대세였으나, 현재는 External Secrets으로 다양한 시스템이 나온것으로 알고있다.
  • 안그래도 Vault가 정답일까? 더 좋은 방안이나 시스템은 없을까? 고민을 하고 있었는데 다른 External Secrets도 알아보면 좋겠다.
• Argo CD + Istio
  • Argo CD!! 현재 도입하려고 PoC하고 있는 시스템이다.
  • 현재는 Github을 통해서 CI/CD 과정을 다 하고 있는데 그렇기 때문에 배포전략이나 복구/백업에 많은 어려움이 있다.
  • 타사를 보니깐 보통 Argo CD 또는 Spinnaker를 많이 사용하고 있는데 확실히 Argo CD의 사례가 많다.
  • 특히 현재 Istio을 이용해서 MSA Route를 구현하고 있는데 이부분에서도 닮은 점이 많아서 유익한 시간이였다.
• Keda + Karpenter
  • Karpenter! 가장 최근에 도입하였고, 도입 효과를 가장 많이 본 시스템이다.
  • Karpenter를 통해 Spot Instance를 효율적으로 도입할 수 있었고, 도입 전 EC2 비용이 최대 70%정도 감소했다.
  • Karpenter는 Overprovisioning이 안되서 Keda와 많이 사용한다고 들었는데, 실제로 현재 Keda는 사용하지 않고 있다.
  • 조금 더 시간적으로 여유가 된다면 Keda 도입도 고려해보고 싶다.

 

하루종일 세미나를 들으니깐 생각보다 피곤한 하루였다. 3년만에 열린 AWS Summit이니깐 지치지말고 내일까지만 힘내보자!!

 

1일차 Summit 내용 끝!

끝!