강대명 - 인프라 어디까지 구축해봤어?

요약

Kubernetes 기초

Kubernetes 큰 주제 아래에서 세부 개념과 실습 절차를 연결하기 위한 노트입니다.

핵심 포인트

  • Kubernetes 기초
  • 인프라 어디까지 구축해봤어?
  • 어떤 인프라 구성이 좋은 구성일까요?
  • Cloud vs On-prem
  • 모니터링이 중요하다!

지식 그래프

정리 내용

인프라 어디까지 구축해봤어?

강대명 특강 09.21 우리 서비스는 장애에 강건하고 확장이 가능할까요?

어떤 인프라 구성이 좋은 구성일까요?

  • 보통의 좋은 인프라
    • 장애에 강건
    • 확장이 쉬운
    • 관측이 쉬운
    • 비용이 적은

Cloud vs On-prem

  • On-Prem → 실제 장비를 보유하고 구동하는 회사
    • 충분한 하드웨어를 여유롭게 보유하는 회사
    • 좋은 SE(system-engineer)를 채용하는 회사
  • Cloud
    • 특정 분야 외는 cloud를 써야한다.

모니터링이 중요하다!

  • cloudwatch ← aws
  • 규모가 작은 회사는 가장 크리티컬한 에러를 잘 찾아야한다.

300개의 request를 처리하려면?

  • 클라우드나 k8s를 서버수를 맞춰줘야한다 항상 넉넉하게

확장이 좋은 인프라

  • 피크타임에 맞춰서 인프라를 확장해야한다

DBMS 장애

  • DBMS Primary와 DBMS replica

Infrastructure as Code(IaC)

  • 테라폼 같은걸 사용하여 변경내용 (인프라내부)을 확인하고 관리
  • 변경 낸역을 관리한다 → 변경이나 복원이 쉽다
  • Github 과 연동되는 Atlantis

대규모 서비스의 종류

  • 트래픽 번위가 예측되는 경우
    • 카톡/라인 등의 새해 이벤트
    • Black Friday 등등
  • 트래픽 범위 예측되지 않는 경우
    • Auto-Scaling이 커버 되는경우
    • Auto-Scaling이 커버 되지 않는 경우
      • 평소와 피크차이가 몇백배이상인 경우
      • 미리 서버를 늘리는 수 밖에..

대규모 서비스 데이터 이슈

  • sharding 샤딩 데이터 분산 저장
  • Database Partitioning (수직분산, 수평분산)
    • 이슈 특정 키를 어떻게 나눠서 DB서버를 나눌것인가
      • == 특정 Key를 어떻게 찾을 것인가?
    • 데이터 리디스크립션? ← 서버 확장 시 데이터의 재정렬이 필요함
    • range 샤딩의 단점 → 문제점 찾아보기

range 샤딩

  • 추가하기 쉽다
  • 서비스 부하의 불균형
    • 보통 서비스 초기고객은 충성고객
    • 이벤트를 했을 때 들어오는 고객은 몇 프로만 남고 금방 서비스를 떠난다.

range의 단점 해결

  • 특정 서버의 로드가 낮다면 range 구간의 신규유저를 해당 서버에 저장
    • 신규유저가 너무 많다면 특정구간이 터짐
  • 규칙에 대한 이해가 필요

샤딩 단점

  • RDBMS 자체적으로 샤딩을 구현하면 생기는 단점
    • JOIN연산 불가
    • Application 레벨에서 데이터들을 필터링해서 가져온 다음 직접 Join을 구현

미래를 위해 고민하면 좋은점

  • 데이터 샤딩 규칙
    • 안되면 그냥 range
    • 코드가 range샤딩을 지원하는 구조 → JOIN쓰지마
    • SQL Join을 최소한
  • 인프라 Naming
    • AWS 서울 리전만 쓰다가 미국사업 진행..?
      • 같은 이름의 서버가 필요하다면
      • {name}-{region}등 구분이 필요
      • 서버 이름만 보고도 어떤 일을 하는 서버인지 알 수 있게..
      • VPC의 CIDR규칙등…

Q&A

기업의 클라우드 전환의 핵심은?

  • 확장성, 접근성이 핵심
  • 개발적 측면 → API 서비스 python 장고를 통해 대규모 서비스 백엔드 구현이 가능할까요?
  • 어떤 언어를 쓰던 구축하는데 크게 이슈는 없다 ← 언어가 핵심이 아니다.
  • 파이썬을 → 자바, 루비를 쓰면 조금더 성능이 좋아지겠지만
  • DB가 더 중요하다 아키텍처를 설계할 때 참고한 사이트
  • 큰 회사의 컨퍼런스 (페북, 구글, 넷플릭스)

TMI

  • 서울 → 김해 7ms
  • 미국 동부 → 서부 140ms

출처