그전에 인프라는 뭔지 알고싶다면

개발자의 기본 "인프라" 란 ?

어떤것들을 고려해야할까

• 이렇게 API 서버 하나가 터져도 돌아갈 수 있는 인프라를 구성해야함.

  

• request가 늘어나면 서버 몇대가 필요한지 고려해야함.

  • request가 늘어났는데 서버 하나가 터진다면?
  • 트래픽은 일정하지 않기 때문에
    • 언제는 많이 들어오고 언제는 적게 들어온다.
    • peak를 버티기 위해 넉넉하게 서버개수를 놔두면?
    • 돈낭비가 심함.
    • 그럼 peak때 서버 증설이 쉽도록 아키텍쳐를 짜주면 좋다.
      • 이래서 확장성이 매우 중요
      • 이러면 On-Prem에서 Capacity 이슈가 발생.
    • On-Prem에서의 Capacity 이슈
      • Peak 타임을 버틸 수 있는 것보다 조금 더 장비를 사전에 추가해놔야됨.
      • 클라우드는 리소스를 늘리기 좀 더 쉽지만
      • On-Prem에서는 장비의 증설은 미리 계획하고 예측해야함.
        • 사용량 모니터링 필수
        • 장비 증설에 몇 달 걸림.
    • 하지만 결국 이 이슈를 해결하기 위해서는 클라우드든 On-Prem이든 쉽게 장비를 추가할 수 있게 서비스를 설계해야 함.
  • 클라우드나 kubernetes같은 걸 쓰면 서버 수를 증가하거나 맞춰줌.

DBMS가 장애가 난다면?

Data Replication

• 복구되면 Replica data 다시 DBMS에 담는다.

Infrastructure as Code

• On-prem은 ImC(immutable infrastructure)라는 툴들을 사용해서 정형화를 시킴.

  e.g.)terra-form

  변경시에 히스토리가 남는다. → 가장 중요

  변경 내역을 관리한다는 말은 변경이나 복원이 쉽다는 말

대규모 서비스로

대규모 서비스의 정의

1. 트래픽 범위가 예측이 되는 경우
   • 계획된 트래픽 증가
     • 카톡/라인 등의 새해 이벤트
     • Black Friday, Cyber Monday, 광군절 등
2. 트래픽 범위가 예측이 되지 않는 경우
   • 예를들면 게임이 얼마나 뜰지 예측이 안되는 경우
   • Auto-scaling이 커버가 되는 경우
   • Auto-Scaling이 커버가 되지 않는 경우
     • 평소와 피크 차이가 몇 백배 이상인 경우
     • Auto-Scaling도 in-minute traffic 같은 경우는 커버가 안됨.
     • 미리 서버를 늘려놓는 방법 밖에 없다.

• 세상의 기술이 발전해서 대부분의 트래픽은 돈으로 감당 가능.