확장성에 대해 언제 생각해야합니까? [닫은]

재밌지 만 끔찍한 문제가 있습니다. 새로운 (iPhone) 앱을 출시하려고합니다. 내 맞춤형 백엔드에서 실행되는 턴 기반 멀티 플레이어 게임입니다. 그러나 나는 발사가 두렵다.

어떤 이유로 든, 나는 그것이 큰 무언가가 될 수 있다고 생각하고 그 인기로 인해 외로운 외로운 단일 서버 + MySQL 데이터베이스가 죽을 것이라고 생각합니다.

한편으로 나는 그것이 성장하고 있다면 더 잘 준비하고 확장 가능한 인프라를 이미 갖추어야한다고 생각합니다.

반면에 나는 세상에 나가는 것을 느끼고 어떤 일이 일어나는지보고 싶다.

나는 종종 "조기 최적화는 모든 악의 근원"과 같은 기사를 읽거나 사람들이 도구를 사용하여 킬러 게임을 지금 빌드하고 나중에 확장 성과 같은 다른 것들에 대해 걱정해야한다고 말합니다.

전문가 나 이에 대한 경험이있는 사람들의 의견을 듣고 싶습니다. 감사!

실제로 아주 쉬운 선택입니다.

지금은 사용자 수가 없으며 확장 성은 문제가되지 않습니다.

이상적으로는 수백만 명의 사용자가있는 지점에 도달하려는 경우 확장 성이 문제가됩니다.

지금은 확장 성 문제가 없습니다. 많은 사용자 문제가 있습니다. 확장 성 문제에 대한 작업을 수행하는 경우 사용자 수 문제를 해결하지 못합니다. 이는 아직없는 문제를 해결했으며 아직 가지고있는 문제를 해결하지 않았 음을 의미합니다. 가장 좋은 결과는 귀하의 제품이 그것을 만들지 않을 것이며, 귀하의 모든 작업은 아무 것도 아닙니다.

당신이 수-의 사용자 문제에 작업하는 경우, 당신은 당신이 지금이 문제를 해결하며, 다음, 당신은 확장 성이 될 수있는 다음 문제에 집중할 수 있습니다.

확장 성 문제의 좋은 점은 정의에 따라 일반적으로 비즈니스가 상당히 훌륭하다는 것을 의미하므로 확장 성 최적화에 돈을 쓸 수 있다는 것을 의미합니다. 밤새 사용자 수가 0에서 천만 명에 이르지 않고 시스템 성능을 주시하면 시간이 다가올 때 최적화 할 시간이 충분합니다.

물론 지금 당장 필요한 코드를 작성하는 동안 확장 성을 염두에 두는 것이 도움이되지만, 자신이 모르는 기능에 수십 또는 수백 시간을 소비하는 것은 의미가 없습니다. 항상 필요할 것이며, 가장 가능성이 높은 시나리오는 그렇지 않을 것입니다. 지금 당신의 주요 관심사는 배송입니다. 그 후에 무슨 일이 일어나는가? 글쎄, 당신은 나중에 그것에 대해 걱정할 수 있습니다.

최적화가 필요하다는 것을 알 때까지 최적화 할 이유가 없습니다. 최적화가 필요한지 어떻게 알 수 있습니까? 당신은 측정합니다.

서버에 일종의 웹 기반 인터페이스가 있다고 가정하면 Apache JMeter 와 같은 도구를 사용하여 많은 사용자를 시뮬레이션 할 수 있습니다 . 도구 사용법을 배우고 백엔드 스트레스 테스트를 시작하십시오. 시스템의 한계가 무엇인지 알 수있을만큼 충분히 배울 수 있어야합니다. 그런 다음 해당 정보를 보유한 사용자 수와 한 번에 실행중인 평균 수와 결합하여 확장시기를 결정할 수 있습니다.

TL; DR 첫 번째 코드 줄을 작성하기 전에 확장 성을 고려해야합니다.

먼저 첫 번째 것들. 확장 성! = 최적화

첫 번째 코드 줄을 작성하기 전에 확장 성을 고려해야합니다. 그렇다고해서 게임이 타격을받을 가능성이 큰 대규모 인프라를 구축한다는 의미는 아닙니다. 확장성에 대한 생각은 다음을 의미합니다.

• 코드가 스케일되도록 작성되었는지 확인하십시오. 확장 할 필요가없는 많은 프로젝트를 보았습니다. 결과는 사용자가 던지는 하드웨어에 관계없이 확장되지 않거나 엄청나게 비싸지는 코드베이스입니다.
• 스케일링 전략을 파악하십시오. 모든 사용자를 지원하는 방법에 대한 계획을 세우십시오. 당신은 MySQL DB를 가지고 있고, 당신은 그것을 파쇄하거나 클러스터 할 것입니다. 샤딩과 같은 전략은 아키텍처에 요구 사항을 배치하므로 미리 예측해야합니다. 덜 클러스터링. 세션을 지원하고 있으며 세션이 여러 프런트 엔드 서버와 어떻게 반응합니까? 로드 밸런서에서 고정 세션이 필요합니까?
• 구현 전략을 파악하십시오. 스케일링에 AWS를 사용 하시겠습니까? 동적 확장 성을 제공하는 제품이나 서비스를 활용할 수 있습니까? 여기에는 비용에 대한 이해도 포함됩니다.

그러나 이미 코드베이스가있는 것처럼 들립니다. 이제 문제는 언제 스케일링을 시작해야 하는가입니다. 이것은 코드에 전적으로 의존합니다.

코드가 스케일링에 적합한 경우 어려운 부분을 수행 한 것입니다. AWS 계정을 확보하고 필요에 따라 서버를 가동 할 수 있습니다.

코드가 확장되지 않거나 병목 현상이 발생 하면해야 할 일이 있습니다. 병목 현상을 식별하고 수정해야합니다. "언제"는 정말 알기가 어렵습니다. 일부 서비스는 정체되고 일부는 꾸준히 증가하고 일부는 폭발합니다. 스케일링과 같은 시점에 리소스를 던질시기를 결정하는 것은 일반적으로 비즈니스의 기능이며 위험에 대한 평가입니다.

귀하의 입장 에서 "베타"로 출시하고 사용자의 기대치를 관리 할 수 ​​있습니다. 그렇게하면 제품을 꺼내어 어떻게 전개되는지 알 수 있습니다.

따라서 확장성에 대해 두 번 생각해야합니다.

첫째, 한 줄의 코드를 작성하기 전에 숙고해야합니다. 이것은 확장 성 구멍에 자신을 쓰지 않고 두 번째로 필요한 측정을 제공하도록 코드를 계측하는 것입니다.

확장 성을 고려하는 두 번째 시간은 수용 할 수 없을 정도로 느리게 진행되는 것입니다. 즉, "너무 느린"의 의미와 부하에서 물건이 어떻게 반응하는지 알아야합니다. 드라이버 (아마도 qps)가 한 달에 N % 씩 증가하는 서비스를 사용하는 경우, 자원 사용량이로드 제곱 또는 선형로드 인 경우 "머신 리소스 소비의 95 %"와 시간이 다소 다릅니다.

턴 기반 게임을 사용하면 괜찮은 수준의 안전성을 확보해야합니다 (아마도 단일 게임 세계가 없을 수도 있고 내부에 지오메트리가있을 수도 있습니다. 회전 "문제).

구체적인 내용을 알지 못하면 확장 문제가있는 위치와이를 해결하기위한 가능한 전략에 대해 생각하는 데 하루나 이틀이 걸립니다. 그러나 이것은 중요하다. 생각하지 말고 생각하고 문서화하십시오. 수백 명의 사용자에게 시작되는 확장 성 문제가 없으면로드를 확인하고 더 많은 백엔드 리소스를 가동 할 시간이 있어야합니다.

설명에서 두 가지 가능한 결과가있는 것처럼 들립니다.

• 게임은 실패하고 당신은 상관하지 않습니다.
• 게임이 성공하면 백엔드는 부하를 처리 할 수 ​​없으며 결과는 실패합니다.

흠.

자신에게 물어볼 몇 가지 질문이 있습니다.

• 수용 가능한 성능으로 현재 백엔드를 처리 할 수있는 사용자는 몇 명입니까?
• 급격한 성장이 예상되는 경우 현재 사용자에게 미치는 영향을 제한 할 계획이 있습니까 (예 : 일시적으로 게임을 앱 스토어에서 가져 오기)
• 성공하면 얼마나 빨리 백엔드를 개선 할 수 있습니까?
• 대기의 비즈니스 영향은 무엇입니까? 스스로 먹이를 줄 수 있습니까? 위험은 무엇입니까?
• 위의 질문에 대한 답변을 바탕으로 발표가 비즈니스에 미치는 영향은 무엇입니까?

일단 당신이 이것들을 고려하면 당신의 질문에 대한 답이 분명 해져야합니다. 모든 시스템이 다르고 모든 비즈니스가 다르기 때문에 전문가가 더 많은 정보없이 무엇을해야하는지 알려줄 수 없습니다.

서버는 사용자가 대화식으로 사용합니다. 이는 대기 시간이 매우 심오한 방식으로 사용자 경험에 영향을 미친다는 것을 의미합니다. 지연 시간이 길면 항상 사용자 경험이 좋지 않습니다.

적어도 Bryan이 설명한대로 임시로드 테스트를 수행하십시오.

더 진지한 접근

일부 시뮬레이션 실행을 수행하고 네트워크 지연 시뮬레이션을 사용하거나 응용 프로그램 내부에서 sleep ()을 사용하여 사용자 경험에 어떤 대기 시간이 발생하는지 확인하십시오. 주목할만한 대기 시간, 짜증나고 사용할 수없는 대기 시간을 확인하십시오.

그런 다음 최적화 방향으로 첫 단계를 밟습니다. 서버의 SLA를 결정하십시오 (예 : 성가신 대기 시간이 최악 인 10 % 통화와 사용할 수없는 대기 시간이있는 1 % 통화). 이러한 제한을 통해로드 테스트를 사용하여 서버가 지원할 수있는 사용자 수를 확인할 수 있습니다.

대기 시간을 측정하지 않고 (또는로드 테스트 중에 서버를 수동으로 사용하는) 순수한 처리량 테스트는 측정 된 처리량 숫자가 견딜 수있는 사용자 경험을 제공하는지 여부를 알려주지 않기 때문에 유용하지 않습니다.

Gil Tene의 대기 시간 측정에 대한 훌륭한 프레젠테이션 : http://www.infoq.com/presentations/latency-pitfalls

비즈니스 요구 사항 단계에서 아키텍처, 운영, 개발, QA 및 제품 모니터링과 같은 다운 스트림 모든 요소의 성능에 대한 공통된 이해를 설정하는 데 사용됩니다. 사전에 요구되는 사항에 대한 공통적 인 이해를 확립하지 않으면 조직의 각 부분이 수명주기 동안 특정 작업에 참여할 때 성능에 대해 가정하거나 전혀 생각하지 않습니다. 신청. 폭포, 짧은 폭포, 민첩성 또는 이력서 키워드 목록에서 현재의 개발 방법론에 관계없이 모든 것이 사실입니다.

성능과 확장 성은 어렵습니다. 기능은 쉽습니다. 스케일링 코드가 잘못되면 리소스 풀에 채워지는 자원이 채워 지므로 더 큰 하드웨어를 구입하여 비용 버블을 변경하면 비효율적 인 코드를 수정하거나 더 많은 하드웨어를 구매하기 전에 지금까지만 소요됩니다. 이것을 최우선 순위로 두는 것도 비용이 많이 듭니다. 성능과 관련하여 늦게 도착한 요구 사항을 충족시키기 위해 완전히 전환해야하는 애플리케이션의 수명주기 초기에 이루어진 아키텍처 및 설계 결정이 있습니다.-고성능 스포츠카 제조업체는 알루미늄에서 성능과 관련된 전력 / 무게 비율을 달성하기위한 설계주기 후반 탄소 섬유, 이것이 툴링, 교육, 자동차 건설 등에 미치는 영향 ...

조직의 건축가, 개발자 및 운영 담당자에게 응용 프로그램의 성능 요구 사항을 문의하십시오. 이러한 정보가 비즈니스에서 캡처되지 않은 경우 동일한 그룹 내에서도 다른 개인으로부터 다른 답변을 받거나 답변이없는 경우 놀라지 마십시오. 이러한 "가정"은 항상 조직을 배치 할 때마다 돌아옵니다.