$4 VPS에서 얼마를 얻을 수 있습니까?

가상화 제품은 성능이 훨씬 더 나쁩니다(2019년 실험 참조: httpsjan.rychter.com/enblog/cloud-server-cpu-performance 및 비용이 더 많이 듭니다. 차이점은 "필요에 따라 확장"할 수 있다는 것입니다. 필요하지 않은 것으로 나타났습니다. 적어도 내 경우에는 확장이 필요하더라도 새 서버를 가져오는 데 몇 초가 아니라 몇 시간이 걸린다는 점에서 여전히 그렇게 할 수 있습니다. 음, 몇 초 안에 확장할 필요가 없습니다.

제 경우에는 전체 프로덕션 환경과 복제된 스테이징/대기 환경에 대한 전체 월 청구액이 일정하고 단순하며 예측 가능하고 AWS에 지불해야 하는 비용에 비해 매우 낮습니다.

주목할 가치가 있는 한 가지는 물리적 서버를 가상 서버처럼 취급한다는 것입니다. 모든 것이 ansible을 통해 관리되며 모든 것을 처음부터 다시 만들 수 있습니다. 사실 저는 Digital Ocean에서 또 다른 "devcloud"환경을 사용하고 있으며 나머지 설정을 수행하는 ansible로 전달되기 전에 terraform을 사용하여 스핀업됩니다.

저는 VendorOps와 kubernetes와 같은 복잡한 도구가 지난 10년 동안 등장한 복잡성 상인들에게 선호되고 있다고 생각합니다. 이력서에 멋지게 보이고 기술 리더에게 잘못된 성취감을 줍니다.

한편 대부분의 신생 기업보다 더 중요한 Stackoverflow는 전용 시스템을 사용하고 있습니다.

1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc..

이 공간의 추세는 추상화의 최상위 계층으로 직접 점프하는 것 같습니다. 기본 사항을 건너뛰고 $buzzword 도구, 라이브러리 및 제품을 가리킴

여러분은 이것을 다른 형태로 엿볼 수 있습니다. 하나는 X를 배우기 위해 얼마나 많은 X를 알아야 하는지와 같은 질문을 하는 소셜 미디어 스레드입니다. 여기서 X는 기본적이고 아마도 매우 안정적인 기술 또는 분야이고 Y는 일상적인 도구 또는 제품 또는 서비스입니다.

CORBA가 거기에 속합니다. 그리고 아마도 시맨틱 웹에 관한 것일 수도 있습니다. 확실히 XML!
XML은 훌륭합니다. 믿을 수 없다면 JSON 구문 분석의 어려움에 관심을 가질 수 있습니다. httpseriot.ch/projects/parsing_json.html
그리고 YAML을 시작하지 마십시오 ..

클라우드에 있는 증분 비용은 관리 데이터베이스, 자동 스냅샷, 호스팅 로드 밸런서, 플러그 앤 플레이 블록 스토리지 등을 보유하는 데 전적으로 가치가 있습니다.
우리 제품이 좋은지 걱정하고 싶고, 한밤중의 하드웨어 고장, 새 서버를 돌리고 제대로 작동하지 않는 것에 대해 걱정하고 싶습니다. 단일 상자로 구성 관리를 사용할 인센티브가 없기 때문입니다. OOM 또는 전체 디스크를 유발하고 해당 작업 VM 대신 모든 것을 중단하고 1000일 동안 가동된 시스템을 다시 시작하는 것에 대한 두려움 등

나에게 클라우드의 매력은 필요하지 않을 때의 FAANG 확장성 유행이 아니라 자동 OS 패치, 자동 로드 밸런싱, NAT 서비스, 중앙 집중식, 분석 가능한 로그, 내가 관리할 필요가 없는 데이터베이스 서비스입니다. 서비스에 대한 박스 롤링 업그레이드, 암호화 키 및 비밀 관리, 물론 객체 스토리지. (이것들은 우리가 스타트업에서 사용하는 모든 것입니다)
사지에 가서 특정 규모에 도달하면 전용 서버가 매우 실행 가능하고 비용 효율적일 수 있다고 말하고 싶습니다. 당분간 클라우드 비용은 내 스타트업에 그만한 가치가 있습니다.

환경 구성을 코드로 수행하는 경우 대상이 전용 서버, vm 또는 api를 통해 구성된 일부 클라우드 특정 설정인지는 궁극적으로 중요하지 않습니다.

어떤 것이든 중요하지 않습니다. 요점은 단순히 명령을 실행하여 새 상자를 만들거나 오작동하는 상자를 정상 상태로 되돌릴 수 있는 상자가 있다는 것입니다.

물론, 이를 구동하는 Go(o)의 실제 더미는 개선될 수 있습니다(실제로 개선되고 있습니다).

그렇긴 하지만 엄밀한 사실은 귀하의 접근 방식이 옳다는 것입니다. 거의 모든 비즈니스(신생 기업!)는 가치 제공, 실제 틈새 시장 식별 등에 초점을 맞추는 대신 과도하게 구축합니다. VC 자금이 부풀려진 신생 기업은 부하를 감당하고 확장할 수 있는 타사에 의존하기를 원하며 SLA 및 기타 광고를 해야 합니다.)
쿠버네티스는 환상적입니다! 잠재적으로 경쟁하는 비즈니스가 Kubernetes를 사용하여 시작하는 것을 볼 때마다 더 이상 걱정할 필요가 없다는 것을 알기 때문에 즉시 안도합니다. 그들은 믿을 수 없을 정도로 복잡한 기술 스택에서 추적할 수 없는 문제를 해결하려고 노력하고 트래픽이 2/3배 더 큰 비즈니스를 위해 설계된 시스템이 부과하는 한계를 해결하려고 노력하면서 해결할 수 없는 기술적 문제 더미에서 사라질 것입니다. 또한 그들의 COGS는 내 것보다 훨씬 높을 것입니다. 즉, VC 자금을 통해 소진되지 않는 한 제품 가격을 더 높게 책정해야 합니다(이 경우 팬의 플래시입니다).

두루두루 좋은 물건

Ansible은 필수적이며 정적 상태를 향해 작동할 수 있습니다. 문제가 발생하면 SSH 연결이 끊어지고 수많은 파이썬 오류가 발생하며 영원히 포기합니다. 인벤토리가 있더라도 선언적이지 않습니다.
k8s는 선언된 상태를 향해 진행을 시도하는 제어 루프입니다. 실패는 문제가 되지 않으며 다시 시도합니다. 자체 상태를 지속적으로 확인하고 이를 보고할 수 있는 멋진 API가 있으며 많은 구체화된 개념 덕분에 배포된 구성 요소 간에 이상한 충돌이 발생하기가 더 어렵습니다. (Ansible과 여러 플레이북을 통합하는 것은 쉬운 일이 아닙니다.)
httpsgithub.com/spantaleev/matrix-docker-ansible-deploy
그리고 k8s가 너무 많은 유산을 입히더라도 핵심 아이디어가 더 슬림하게 나타날 것입니다. (예: httpsgithub.com/aurae-runtime/aurae )
그리고 이제 사람들이 더 간단한 비표준 구현을 사용하도록 제안합니까?
따라서 최소한의 복잡성 솔루션을 구현하거나 "기성품"을 사용할 수 있습니다.

k8s는 복잡하고 그 중 일부는 귀하의 상황에 확실히 필요하지 않지만 다소 일반적이고 유연하며 잘 지원되는 등입니다.

>사람들이 더 간단한 비표준 구현을 사용하도록 제안하고 있습니까?
내가 제안한 것은 k8s 프로젝트/소프트웨어가 실패하기에 너무 커지면 사람들이 대안으로 전환할 수 있다는 것입니다. 운 좋게도 k8s 개념과 API는 오픈 소스이므로 다른 프로젝트에서 구현할 수 있으며 k8s를 선택하는 것이 Oracle과 같은 벤더 종속이 아님을 설명하기 위해 그러한 예를 들었습니다.

저는 항상 클라우드 제공업체로부터 실질적으로 무료로 얻을 수 있는 모든 훌륭한 기능에 대해 듣습니다. 그 물건이 실제로 설정하고 사용하기 쉬운가요? 클라우드 서비스에서 LAMP 스택을 설정하려고 할 때마다 너무 혼란스럽고 두려운 과정이어서 결국 포기했습니다. 조금만 더 힘내면 구름천국에 갈 수 있을까?
"이런 종류의 사양으로 여기에 클러스터링된 MySQL을 원합니다"라고 말할 수 있는 것이 직접 수행하는 것보다 훨씬 낫습니다(시간적으로). 업데이트도 시스템에 잘 정리되어 있으므로 올바른 순서로 장애 조치/재시작이 발생하는지 수동으로 확인하는 대신 "최신 업데이트를 적용하십시오"라고 말하고 싶습니다.

그래서 당신은 일을 단순화하기 위해 돈을 지불하지만, 그 단순화로부터의 이득은 더 큰 프로젝트에서만 시작됩니다. 사용자가 오류 페이지를 받는 동안 다시 시작할 수 있는 단일 서버에 무언가가 있는 경우 그럴 가치가 없을 수 있습니다.

클라우드는 쉽지 않지만 대부분의 빅 데이터 센터 게시는 멀티 벤더 인터넷 연결과 마찬가지로 효율성 수준에 가까운 작은 서버 룸의 냉각 및 전력 효율성을 얻기 위해 노력하고 있습니다.

클라우드를 사용하면 클라우드가 실행되는 데이터 센터 운영자가 관리하기 때문에 그런 종류의 모든 것이 사라집니다. 그러나 사람들이 잊는 것은 종종 클라우드보다 더 나은 비용/가치를 제공하는 구식 코로케이션 서비스에도 해당된다는 것입니다.
AWS 또는 Azure와 같은 항목을 관리하는 것은 확실히 더 어렵습니다. 소규모 소규모 vpc 공급자가 숨기거나 단일 홈 서버로는 실제로 얻을 수 없는 추상화가 많이 발생하기 때문입니다. SAN 기반 스토리지를 갖춘 vmware 서버 랙 상당클라우드의 경우 가상 서버 등을 구성하기 때문에 구성해야 할 것이 더 많습니다.PC를 휴대하는 대신 상자를 사용하려면 "구성"해야 합니다.DO 데이터베이스에는 원하는 대로 구성할 수 있는 백업이 있으며 이를 DO 공간(예: S3)에 저장합니다.DB 사용자 관리가 쉽습니다.Redis용 캐시 서버도 있습니다로드 밸런서를 추가하고 이를 다양한 웹 서버에 연결할 수 있습니다시간이 많이 걸린 것 같아요 2개의 웹 서버, DB 서버, 캐시 서버, 로드 밸런서, 스토리지 서버를 설정하고 몇 가지 간단한 양식을 사용하여 필요에 따라 모두 연결하는 데 약 30분이 소요됩니다.정말 최고입니다더 많은 정보나 의견이 있으면 공유해주세요인터넷에 관한 많은 기사가 있습니다. Linux 서버를 강화하는 데는 단계를 수행하는 데 30분 이상이 걸렸습니다. 실제로 각 작업이 수행하는 작업, 이것이 중요한 이유, 기본 취약점이 무엇인지 배우고 이해하려고 하면 훨씬 더 오래 걸립니다. 내 특정 사용 사례에 맞게 일부 설정을 사용자 정의해야 하는 방법온라인에서 예제 설정 스크립트를 찾을 수 있다고 확신합니다(자동 업데이트 구성, 방화벽, 애플리케이션 등이 중요해야 함) 'curl $URL'을 실행한 다음 'chmod +x $FILE'및 'bash $FILE'을 실행합니다.구성 관리가 필요하지 않았습니다(제 생각에는 중요한 공급자의 백업 서비스를 사용합니다)다음과 같습니다: httpsraw.githubusercontent.com/potts99/Linux-Post-Install..(httpswww.reddit.com/r/selfhosted에서 확인) /comments/f18xi2/ubuntu_d )장기 실행 VM에 대해서도 분명히 같은 말을 할 수 있으며 이는 규율 있는 팀을 보유하여 해결할 수 있지만 일반적으로 단일 장기 실행 전용 VM이 있는 환경에서 더 가능성이 높다고 생각합니다. machineHetzner는 관리되는 데이터베이스를 제외하고 이 모든 것을 갖추고 있습니다httpswww.hetzner.com/managed-server웹호스팅 패키지에는 1도 포함됩니다. .무제한 DB(MySQL 및 PostgreSQL)httpswww.hetzner.com/webhosting/자동 백업 및 장애 조치 기능이 있나요?>예약된 일일 백업 또는 서버 유형에 백업이 포함된 경우 모든 데이터는 매일 백업되며 최대 14일 동안 보관됩니다.konsoleH 관리 인터페이스를 통해 백업 복구(복원)가 가능합니다.하지만 관리되는 서버의 데이터베이스는 해당 서버에서 실행되는 앱에서 사용하기 위한 것이라는 인상을 받았습니다. 따라서 실제로 장애 조치 개념이 없습니다.httpswww.hetzner.com/legal/managed-server/단일 서버의 단일 드라이브 장애로 인해 프로덕션이 발생해서는 안 됩니다. 중단독립형 배포에서 많은 구성 문제를 추적할 수 있습니다.해당 글꼴 파일이나 JRE를 실제로 전체 서버에 설치해야 합니까, 아니면 배포에 번들로 포함할 수 있습니까?우리 배포에서는 온프레미스 및 EC2 대상을 사용합니다.배포 스크립트는 다르지 않습니다. 호스트의 IP만이제 S3를 100% 사용할 수 있는 용도로 사용할 수 있는지 말씀드리겠습니다.동일한 기능 세트를 갖춘 온프레미스 대안은 없습니다.DevOps의 요점은 "애완동물이 아닌 소"입니다. 실패 지점을 찾기 위해 일주일에 한 번씩 서버에 글머리 기호를 추가하세요.Discord/Slack에 접속하여 보고 있던 문제 중 일부를 제기해 주시면 감사하겠습니다. 최소한 Dokku를 사용하는 다른 사람들에게 더 나은 경험을 제공하십시오.저에게 연락주세요(제 별명은 `savant`입니다)서문에 저는 Docker에 대한 실무 지식만 있는 애플리케이션 개발자라고 말씀드리겠습니다.저는 인프라에 능숙하지 않으며 제가 고생한 애플리케이션에는 독특한 배포 매개변수가 있습니다. 빌드 시 정적 HTML 크롤링의 여러 기가를 구문 분석하여 빌드 후 정적 Postgres 데이터베이스를 채우는 Python 앱입니다. 그러면 Flask 웹앱이 해당 데이터베이스에 대해 서비스를 제공합니다. HTML 파싱은 빠르게 발전하므로 채워진 DB 데이터는 애플리케이션 이미지의 일부로 번들되어야 합니다.  IIRC, DB가 영구적이지 않고 대신 앱의 또 다른 임시 부분일 때 Dockerfile을 구성하는 데 어려움을 겪었지만 극복할 수 있는 것처럼 보였습니다. 더 큰 문제는 특히 DigitalOcean과 내 로컬 환경에서 정상적으로 작동하는 방식으로 이상적으로는 캐시될 때 각 빌드에 대해 거의 변경되지 않는 데이터를 S3에서 가져오는 것을 피하는 방법인 것 같습니다. 나는 올바른 Docker 이미지 레이어 캐싱이 문제를 해결할 것이라고 생각하지만, 내 지식과 인내심의 한계에 꽤 빠르게 도달했습니다.  Dokku의 DX는 평범한 일을 하는 사람들에게 좋은 것 같습니다. :) 0. httpscoolify.io/ 게다가 가장 최신의 멋진 장난감을 남의 돈으로 가지고 놀고 싶지 않은 사람이 어디 있겠습니까? 유연성(또는 플럭스/피벗 처리)이 주요 동인이 되고 규모/비용이 지배하기 시작하면 여정 후반에 클라우드에서 (일부) 항목을 이동해야 한다는 주장이 확실히 있습니다.  물론, Hetzner에서 작동하는 것을 얻을 수 있지만 더 많은 질문에 답할 준비가 되어 있어야 합니다.  다른 방법이 훨씬 더 나을 수 있는데 이러한 비즈니스 "요구 사항"이 소프트웨어를 설계하고 호스팅하는 방법을 지시한다는 사실이 다시 한 번 슬프지만 이것을 요구하는 기업의 마지막 지점에 동의했습니다. 재해 복구는 매우 현실적인 문제입니다. 그래서 정기적으로 테스트합니다. 초토화 시나리오에서는 1시간 이내에 보조(스테이징) 시스템 또는 테라포밍된 클라우드 시스템을 가동하고 실행할 수 있습니다. 내 사업에는 그것으로 충분하다. 
우리는 성장 호황을 겪었고 이전의 모든 사람들과 마찬가지로 많은 돈과 절박한 기대를 안고 경험이 없는 사람들이 많았다는 것을 의미했습니다. 화물 숭배와 착취적 마케팅을 위한 레시피

그러나 성장은 둔화되고 돈은 점점 더 비싸지고 있으므로 속도를 늦추고 흥미로운 새로운 변형으로 이전 교훈을 다시 배우기 시작하십시오. (Like Here: 베어 메탈 스케일링 관리 및 컨테이너 및 오케스트레이션 사용)
그리고 전체 주기는 다음 호황에서 반복될 것입니다. 그게 지금 우리 산업이야

견고한 전용 서버는 공유 하드웨어에서 장애가 있는 VPS보다 99% 더 유용하지만 제공하는 모든 리소스가 필요하지 않으면 분명히 비용이 증가합니다.

예 - 그러나 "멋진 애들이 지금 하고 있는 일을 하라"는 열망은 적어도 일반적으로 "관리자"라고 불리는 사람들과 "직원"으로 불리는 사람들에게 강합니다.

결과 A) 막대한 마이크로 서비스/클라우드 지출이 잘못되었습니다. 최소한 모범 사례를 따르고 있었습니다. 이러한 일이 발생하면 어떻게 해야 합니까?

결과 B) Hetzner 서버를 사용했는데 문제가 발생했습니다. 음, 마이크로서비스를 사용했어야 했습니다. 새로운 일자리를 찾는 것을 즐기세요.

따라서 관리자가 마이크로서비스/클라우드를 선택하도록 권장합니다. 회사 입장에서는 옳지 않은 결정일지 몰라도 경영자 입장에서는 옳은 결정이고 결정은 경영자 자신이다

(어려운 방법으로 알게 된 것처럼 확장 기능을 원하고 작동하는 소프트웨어를 작성하는 컨설턴트가 되는 것도 마찬가지입니다.)
창립자와 다른 모든 사람 사이에는 단절이 있습니다.

설립자들은 매년 10배 이상 성장할 것이라고 믿습니다.

현실은 실패할 확률이 90%라는 것입니다.

90%의 시간 - 당신은 무엇이든 실패해도 괜찮습니다

성공할 확률의 10% 중 일부는 클라우드 없이도 괜찮습니다. 최소한 몇 년 동안은 성공하고 필요한 경우 전환할 시간이 충분합니다.

나는 하나의 가능한 설정만 가지고 있으며 가상화된 서버와 물리적 서버 모두에서 작동할 수 있습니다. 차이 없음. 유일한 차이점은 가상화 서버를 먼저 terraform으로 설정해야 하고 물리적 서버를 먼저 주문하고 해당 IP를 구성 파일(인벤토리)에 입력해야 한다는 것입니다.

물론 다른 많은 클라우드 서비스에 의존하지 않도록 주의하기도 합니다. 예를 들어 서버 간 통신을 위해 VpnCloud(httpsgithub.com/dswd/vpncloud)를 사용합니다. 부수적인 이점으로 언제든지 인프라 공급자로 전환할 수 있는 유연성도 제공됩니다.
내 요점은 가상화된 오퍼링에는 용도가 있지만 월 $10의 취미 VPS와 폭발적으로 성장하는 B2C 비즈니스를 가진 회사 사이에는 (엄청난) 격차가 있다는 것입니다. 대부분의 새로운 비즈니스는 실제로 그 격차에 속합니다. 수익성 있는 B2B SaaS에서 하키 스틱의 기하급수적 성장을 기대하지 않습니다. 여기에서 일반적인 기본 선택인 "AWS 사용"에 대해 질문해야 합니다. 저는 매출원가와 마진에 관심이 있으므로 이 선택을 매우 신중하게 검토합니다.

당신은 소프트웨어 회사가 아닙니다. 근본적으로 당신은 스프로킷을 만들고 판매합니다.

여기서의 의견은 "서버를 구입하고 유지 관리"(PaaS는 나쁘다)하기 위해 큰 엔지니어링/IT 직원을 고용한 다음 "직접 코드를 작성"(SaaS는 나쁘다) 또는 현재 여기에서 인기 있는 모든 것(마지막 스레드는 여기에서 "Git 없이 SFTP를 통해 PHP를 사용하면 더 필요합니다"lol)
그러나 저는 기업이 한 가지만 잘 수행하고 핵심 역량 이외의 항목을 놓고 경쟁(수동으로 수행)하는 것을 피해야 한다고 생각합니다. 이 경우 Sprocket Masters는 자신의 하드웨어를 관리하려고 시도해서는 안 되며 확장, 보안, 가동 시간, 규정 준수 및 모든 작은 세부 사항을 처리하기 위해 제공업체에 의존해야 한다고 생각합니다. 나는 또한 그들의 소프트웨어가 가능한 한 사내에서 거의 사용하지 않는 늪지 표준이어야 한다고 생각합니다. 그들은 소프트웨어 상점이 아니며 가능한 한 적은 코드를 작성해야 합니다.

현실적으로 Widget Masters는 모든 작업을 수동으로 수행하기로 결정하지 않는 한 다소 작은 직원으로 이러한 사이트를 실행할 수 있습니다. 이 경우 훨씬 더 많은 직원이 필요할 것입니다.

그러나 내가 본 것과 이전 포스터에서 이야기한 것 같은 것은 기술이 비즈니스의 핵심인 비즈니스이며 종종 이해가 되지 않고 시간을 절약하는 대신 시간이 걸리는 것 같습니다. AWS 전문가가 있는 데에는 이유가 있습니다. 사소한 일이 아닙니다. "실제"서버도 사소하지는 않지만 클라우드 서비스보다 반드시 어려운 것은 아닙니다.

그러나 이러한 기관은 물리적 하드웨어를 유지 관리하기 위한 직원도 원하지 않습니다.

그러나 Sprocket Masters는 단순히 긴급 상황에 대응하기 위해 값비싼 클라우드 컨설턴트를 보유해야 합니다.

클라우드 문제를 처리할 직원이 있는 경우 대신 서버를 임대할 수도 있습니다.

저는 개인적으로 초기에 비즈니스를 위해 전용 서버를 운영했지만 확장하고 확장함에 따라 비용이 상승하더라도 클라우드 공급자와 함께 다양한 서비스를 신속하게 프로비저닝하는 것이 훨씬 쉬워졌습니다. 말할 것도 없이 잠재 고객에게 "AWS와 같은 클라우드"를 사용한다고 말하는 것이 "오, 우리는 어떤 회사에서 운영하는 데이터 센터에서 이 기계를 임대합니다"(실제로 더 나을 수 있지만 고객은 대부분 그것을 얻지 못할 것입니다)보다 훨씬 쉽습니다. . 감사, 규정 준수 및 기타

많은 사람들에게 그보다 훨씬 적습니다. 저는 몇 번 입소문이 난 소규모 사이드 프로젝트[1]를 실행하고(24시간 정도에 30,000회 조회) 이 프로젝트는 단일 코어 CPU 웹 서버에서 실행되고 마찬가지로 단일 CPU 코어에서 관리되는 Postgres에서 실행됩니다. 전체 활용도에 근접하지도 않았습니다.
1: httpsaihelperbot.com/ 그 중 일부를 람다 함수로 전환할 수 있나요? 아니면 ECS로 전환하시겠습니까? 아니면 즉시 다른 클라우드 서비스로 전환하시겠습니까? 아마도. 하지만 제가 이 댓글을 작성하는 데 소비한 시간은 이미 그러한 전환을 위해 절약한 6개월치의 금액입니다. "버튼을 누르면 100% 안정적으로 번역된 서비스를 받으실 수 있습니다"보다 더 어렵다면 정당화하기 어렵습니다.  그 중 일부는 현재 클라우드가 이런 종류의 일을 가능하게 하는 다른 서비스를 제공하기 때문이기도 합니다. 기본 메시징을 위해 Kafka 클러스터를 실행할 필요가 없으며 모두 메시지 버스가 함께 제공됩니다. 나는 그것을 사용합니다. 호스팅 DB 옵션을 사용합니다. S3 또는 이에 상응하는 제품 등을 사용합니다. EC2 인스턴스에서 실행하기 위해 한 달에 한 자릿수 달러를 지불하고 있는데 남은 것은 다른 패러다임에 빠져들려고 애쓰는 번거로움을 겪을 가치가 거의 없다는 것을 알았습니다.  모든 사람이나 모든 프로젝트가 이것을 할 수 있는 것은 아닙니다. 나는 이것을 최종 목표로 삼지 않습니다. 작동하지 않으면 즉시 적절한 조정 조치를 취합니다. 나는 이것을 기반으로 어떤 것을 다시 설계하라고 제안하는 것이 아닙니다. 나는 단지 멸시받을 선택이 아니라는 것을 말하고 있습니다. 유연성이 뛰어나고 청구 비용이 매우 일관됩니다. 즉, 트래픽이 갑자기 50배 증가하면 단순히 수백 달러를 청구하는 대신 시스템이 눈에 띄게 질식하고 스퍼터링을 시작한다는 사실입니다. more는 버그라기보다는 기능입니다. 일반적으로 일부 클라우드 서비스에는 편리하지만 귀하에게는 편리하지 않을 수 있는 패러다임으로 변형하기 위해 노력하지 않습니다.  이러한 환경 중 하나를 관리해야 했던 적이 있습니까? 문제는 2명 이상의 기본적인 확장성과 적절한 개발을 원한다면 상당한 요인으로 과잉 프로비저닝을 해야 한다는 것입니다(절감액이 무효화될 수도 있음).  필연적으로 맞춤형 솔루션을 얻게 될 것입니다. 이는 새로운 합류자가 시스템을 숙달하는 데 더 어려움을 겪게 되고 회사를 떠나는 중요한 사람들이 인프라에 대한 친밀한 지식을 가져오게 될 것임을 의미합니다. 소 대신 애완동물로 돌아왔습니다. 일부 서버는 특별합니다. 잠시 후 자동화는 "여기저기에 많은 글루 쉘 스크립트"를 의미하고 OS 업그레이드는 인프라의 절반이 한동안 KO되거나 OS 업그레이드를 전혀 수행하지 않음을 의미합니다.  그리고 운 좋게도 규모를 확장해야 하는 경우 불쾌한 놀라움을 발견할 수도 있습니다.  그리고 네트워킹 측면에서 시작하지 마십시오. 전체 랙을 임대하고 네트워킹 하드웨어를 직접 설치하지 않는 한 원하는 만큼 얻을 수 있습니다. 기능이나 성능면에서 매우 열악할 수 있습니다. 멋진 작업을 수행하지 않는다고 가정합니다.  100.0000% 가동 시간을 원한다면 물론입니다. 하지만 당신은 보통 그렇지 않습니다. 그런 종류의 가동 시간을 원하는 회사에는 일반적으로 이를 전담하는 팀이 있습니다.  그리고 수직으로 확장하는 경우 베어메탈에서도 확장이 잘 작동합니다. 단일 서버에서 얻을 수 있는 전력 및 처리량의 양을 알고 계십니까? 화자가 "수평적 스케일링"을 의미할 때 "스케일링"에 대해 계속 듣는 것은 우려스럽습니다.  요구 사항이 "확장"인 경우 수직 확장으로 인해 훨씬 ​​더 멀리 갈 수 있습니다.  귀하의 요구 사항이 "요구에 따른 수평 확장"이라면 클라우드 제공업체가 도움을 줄 것입니다. 하지만 그런 종류의 확장이 필요한 곳은 거의 없습니다.  베어메탈에서 100% 가동 시간이 저렴하다는 말이 아니라 100% 가동 시간이 종종 필요하지 않다는 뜻입니다.  업계에는 트렌드와 키워드를 쫓는 사람들이 많기 때문에 가장 중요한 것은 해당 키워드를 이력서에 추가하는 것입니다.  확장성을 목표로 하는 IME는 대부분의 서비스/응용 프로그램/무엇이든 매우 잘못되었습니다. 그리고 일반적으로 "확장 가능한"솔루션에 너무 많은 오버헤드를 지불하므로 이를 보완하기 위해 확장해야 합니다.  정말 의심 스럽습니다.거의 모든 AWS 지지자들에게서 볼 수 있는 주제 중 하나는 AWS가 실제로 귀하에게 제공하는 보장이 무엇인지에 대한 상당한 망상입니다.  응, 물론이지. IBM 제품을 구매한다고 해고되는 사람은 없습니다.  글쎄요, 만약 대기업이 의사결정 능력을 갖고 있다면 그들은 무적일 것이고 다른 일을 하는 것은 전혀 가망이 없을 것입니다. 그렇군요 공익이군요  출처: 거의 30년간의 작전  지금까지 나는 회사를 위해 더 많은 돈을 지출하면 더 많은 급여를 받을 수 있다는 사실을 깨닫지 못했습니다.  다리미로 동등한 신뢰성을 얻는 것은 "두 개의 전용 서버"를 임대하는 것보다 훨씬 비쌉니다. 이제 하나의 서버와 백업 솔루션이면 괜찮을 수 있으며 이는 공평합니다. 그러나 초기 설정을 위한 짧은 계약과 유지 관리가 필요하지 않더라도 이 모든 것을 생성하는 시스템애드는 클라우드 가격 차이를 훨씬 뛰어넘을 것입니다. 특히 혼합된 데이터베이스가 있고 해당 데이터에 관심이 있는 경우에는 더욱 그렇습니다.  오늘날 클라우드도 비슷합니다. 움직이는 부분이 적기 때문에 출시 시간이 더 빠릅니다. 경제가 침체되고 성장이 둔화되면 빈 카운터가 나타나 자신의 일을 합니다.  매번 일어나는 일이야  이는 기업과 클라우드 팀에서 AWS를 더욱 풍부하게 만듭니다. 배포를 확장하거나 축소해야 하는 경우 몇 초 내에 EC2 인스턴스를 자동으로 프로비저닝하고 프로비저닝 해제하는 것은 간단합니다. 이것이 바로 베어메탈 서버와 근본적으로 다른 점입니다. 
이제 필요한 것보다 몇 개 더 많은 전용 서버를 프로비저닝하는 것이 AWS와 비교할 때 여전히 비용 효율적일 수 있다는 것을 부인하지는 않지만 정말 예측할 수 없는 워크로드가 있는 경우 유지하기가 쉽지 않습니다.

수요 곡선을 충족하기 위해 VM을 가동 및 종료하는 경우 아키텍처에 심각한 문제가 있는 것입니다.

어떻게 stackoverflow가 ~8개의 전용 서버를 사용하여 전 세계에 서비스를 제공하고 글로벌 고객 요구를 충족하기 위해 VM을 가동 및 종료할 필요가 없는지 생각해 본 적이 있습니까?
--
컴퓨팅 인프라를 계획할 때 클라우드 공급업체의 선전에 넘어가지 않고 기본으로 돌아가는 것이 중요합니다.
직접 말씀하셨습니다. 모든 애플리케이션이 전 세계에 서비스를 제공할 필요는 없으므로 사람들이 잠들면 수요가 낮아집니다.

글로벌 애플리케이션의 경우에도 특정 지역에서 애플리케이션과 데이터를 호스팅해야 하는 규정이 있습니다. 유럽, 호주 및 미국의 고객이 사용하는 애플리케이션을 상상해 보십시오. 그들은 지역 데이터 센터에서 서비스를 받아야 하며 한 클러스터는 다른 클러스터가 실행 중일 때 대부분 휴면 상태가 됩니다(시간대 때문에). 전용 서버를 사용하면 리소스의 60-70%를 낭비하게 되지만 EC2/Fargate와 같은 것을 사용하면 지역이 잠자고 있을 때 거의 0으로 축소할 수 있습니다.

광기에 대한 방법이 있습니다. 여기서는 "직업 보안 기반 개발"이라고합니다.

직업에 위협이 되기 때문에

자체 호스트 또는 가족/친구/협회/하이킹 클럽을 위한 작은 인스턴스를 호스트할 수 있는 기술적 능력이 있는 사람들이 많이 있습니다. 적절하게 만들고 싶기 때문에 약간의 추가 비용을 지출해도 되는 이 작은 마진이지만 그렇게 많은 비용을 지불하고 힘든 유지 관리에 시간을 보내는 것을 정당화할 수는 없습니다. 공유된 Nextcloud 또는 작은 웹사이트가 있는 작은 VPS는 많은 경우에 필요한 전부입니다.

이를 위해 침실에서 약간의 Raspberry Pi 400을 사용하기도 합니다.

httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4..

나는 지금까지 거의 10년 동안 내 물건을 직접 호스팅했습니다. 아무도 내 설정에서 DDoSing을 시도하지 않았습니다. 왜 그럴까요? 그들이 얻을 수 있는 이점은 무엇입니까? 나는 영향을 받는 거의 유일한 사람이 될 것이고 그들이 멈추면 회복하는 데 오래 걸리지 않을 것입니다.

인터넷 랜도는 고사하고 DDoS 개인 상자에 대한 인센티브가 거의 또는 전혀 없습니다.

십대의 능력을 지나치게 과대평가하고 있습니다.

IP를 반복해서 ping하는 것만으로는 실제로 많은 작업을 수행할 수 없습니다. 대상 네트워크의 IPS 측면에 따라 DoS 공격이 있을 수 있지만 실제로 공격할 기회를 얻기 전에 컴퓨터를 바이러스로 감염시킬 가능성이 더 높습니다.

저는 개인적으로 GTA 5에서 어떻게든 사기꾼에 대한 그 중 하나를 받는 쪽이었습니다. 확실히 발생하고 재미가 없습니다.
수정: 자동으로 실행되는 것 같습니다. 이것은 내가 조금 조사해야 할 흥미로운 것입니다. 내 작은 서버에 대한 추가 복잡성일 수도 있지만 몇 가지 용도를 염두에 두고 있습니다.

기술적으로 내 홈랩도 정적 공용 IP에 있습니다. 이것은 "실제로 필요한 것"이라기보다는 "이것을 할 수 있을까"에 대한 연습에 더 가까웠지만 여전히 멋지고 매우 기쁩니다.

유일한 끊김은 터널을 활성 상태로 유지하도록 Wireguard를 구성해야 한다는 것이었습니다. 그렇지 않으면 때때로 VPS가 들어오는 트래픽을 수신하고 실험실이 잠시 동안 도달하지 않으면(그 이유는 무엇입니까?) 터널이 다운될 것입니다. 프록시 연결이 됩니다. 고맙게도 그것은 내장 기능입니다

따라서 jekyll 또는 GitHub 페이지 사이트에 RSS/Atom 피드를 추가하는 것은 매우 간단해 보입니다.

1. httpsgithub.com/jekyll/jekyll-feed
2. httpsdocs.github.com/en/pages/setting-up-a-github-pages-s..

3. httpspages.github.com/versions/
아톰 2c/4t, 4GB 램, 1tb 드라이브, 100mbit
이 시점에서 몇 년의 가동 시간
중단되지 않은 경우: 일부 업그레이드가 예정되어 있을 수 있습니다.
커널 보안 업데이트는 중요합니다.


Atoms는 Linux에서도 참을 수 없을 정도로 느립니다. 물론 웹 사이트 등을 제공하는 데는 충분하지만 수행하지 않는 것만으로도 얼마나 많은 전력을 사용하는지 당혹 스럽습니다.

정확히. 이러한 10달러 미만의 VPS 인스턴스는 장기 계약을 체결하거나 자체 서버 관리를 처리하고 싶지 않은 소규모 프로젝트에 적합합니다.

마진이 매우 적은 실제 비즈니스를 운영하고 있고 서버 문제가 (언제) 발생하면 처리할 수 있는 자유 시간이 전 세계에 있다면 ~$50 전용 서버를 살펴보는 것이 흥미로울 수 있습니다.

그러나 실제 비즈니스를 운영하고 있다면 전용 서버 관리를 돕기 위해 다른 숙련된 개발자를 고용하는 것보다 월 $10,000 AWS 청구서가 더 저렴합니다.

이것은 HN과 같은 곳에서 클라우드 비용에 대한 논의에서 일반적으로 놓치는 것입니다. 예, 클라우드는 비싸지만 맞춤형 인프라 관리를 돕기 위해 단일 시스템 관리자/개발자를 추가로 고용하는 것조차 엄청나게 비싸고 유연성이 훨씬 떨어집니다. 그렇기 때문에 이론상 충분한 시간 투자로 월 $50의 서버에 맞춤형으로 구축할 수 있는 클라우드 호스팅 솔루션에 가상의 월 $5000를 지출하는 것이 여전히 큰 도움이 될 수 있습니다. 엔지니어는 비용이 많이 들고 시간은 제한되어 있습니다.

어, 실례합니다만 이 DevOps 직원에게 얼마를 지불하고 있습니까? 이것은 매우 미국적인 관점, 심지어 계곡 지역처럼 보입니다. 유럽에서는 남자를 고용하는 것이 더 저렴할 것입니다.

풀로드 고용 비용은 월급으로 집에 가져가는 것보다 훨씬 높습니다. 사실 유럽은 더 심합니다. 다음 차트를 살펴보십시오. httpsaccace.com/the-true-cost-of-an-employee-in-europe/
영국에서 누군가에게 1000유로를 지불하면 회사는 총 1245유로의 비용이 듭니다.

루마니아에서 누군가에게 1000유로를 지불하면 회사는 총 1747유로의 비용이 듭니다.

따라서 120,000달러의 전체 비용으로 EU 데브옵스 직원의 경우 68,000달러의 급여만 받을 수 있습니다.

하지만 한 명의 데브옵스 사람만 가질 수는 없습니다. 그들 중 한 명이 휴식을 취하거나 휴가를 갈 수 있도록 하려면 최소 2개가 필요합니다.

약 3시간 후에 연결해 드릴 수 있습니다.

AWS는 다른 서비스(S3,SES,SQS 등)에 대해 매우 비용 효율적이지만 가상 머신은 좋은 거래가 아닙니다. RAM이 줄어듭니다.& CPU, 가상화 오버헤드로 인해 훨씬 ​​더 많은 비용을 지불

특히 Postgres의 경우 pgbench로 몇 가지 테스트를 실행하면 가상화에 대해 지불하는 페널티를 실제로 확인할 수 있습니다.

어쩌면 자신만의 인프라를 구축할 수 있는 시스템 관리자 기술이 잃어버린 예술이 되어버릴 수도 있습니다. 그렇지 않으면 사람들이 더 낮은 성능에 5배의 비용을 지불하는 것을 그토록 좋아하는 이유를 설명할 수 없습니다.

Hetzner는 유럽에서는 저렴하고 신뢰할 수 있습니다. 북미에 계시다면 OVH를 살펴보십시오. 특히 SoYouStart라는 비용 절감 대안이 있습니다. 65달러에 4/8 4.5ghz, 64 RAM 및 NVME 드라이브를 구입할 수 있습니다.

(저는 OVH와 아무런 관련이 없습니다. 저는 단지 100대에 가까운 서버를 보유한 고객일 뿐이며 제게는 아주 잘 맞았습니다)
제가 늙었다는 점도 말씀드리고 싶습니다. 헤헤, 제가 처음으로 맡은 일 중 하나는 현장에 적당한 크기의 데이터 센터가 있었습니다. SAN, 테이프 드라이브(당시 서버의 자동 테이프 회전기 등)를 처리하는 것은 엄청난 PITA였습니다. 위치 중복성을 위해 테이프를 포장하여 다른 사무실로 배송하는 것은 항상 재미있었습니다.

제가 관리하는 특정 애플리케이션은 실제로 낮은 GHz로 인해 어려움을 겪고 있으며 모든 데이터가 메모리에 저장되어 있지 않습니다. EC2에서 벤치마크를 실행해 본 결과, 약 5초 안에 완료되는 특정 보고서는 비용이 약 10배 더 비싼 유사한 EC2 인스턴스에서 1분 이상 걸릴 수 있습니다. 이 응용 프로그램에는 실제로 원시 CPU가 필요합니다. 네, 그렇습니다. 우리는 모든 쿼리, 인덱스 등을 최적화한 꽤 큰 규모의 엔지니어링 팀을 보유하고 있습니다.

복제, 백업 등은 제가 다 설정했는데 솔직히 별 문제는 아니었습니다. Postgres 책에는 구성, 지속적(및 자동) 테스트 방법 등을 매우 간단하게 설명하는 몇 개의 짧은 장입니다.

SAN이 악몽이라는 점에는 동의합니다. 이것이 바로 내가 모든 WAL(PG 백업 파일)을 S3(결국 Glacier)로 보내는 이유입니다. 그렇게 하면 해당 파일을 잃어버릴까 걱정할 필요도 없고 비용도 훨씬 저렴해집니다.

이러한 종류의 구성은 단일 엔지니어가 설정하기에는 너무 복잡하고 끝없는 유지 관리가 필요하다는 오해가 있다고 생각합니다. 실제로 일주일 이내에 모든 설정을 완료할 수 있으며 Postgres를 업그레이드하려는 경우에만 유지 관리가 필요합니다(일부 설정이 변경되었을 수 있음). 연간 유지 관리 시간은 약 5시간 정도 소요될 것으로 예상됩니다.

라스트 마일 배송을 지속적으로 개선하고 광섬유 액세스를 확장함에 따라 셀프 서비스 인프라는 점점 더 실용적이 될 것으로 보입니다. 클라우드가 자기를 잠식하게 될까요? 확실히 어쩌면

클라우드가 제공하는 이점은 로컬 ISP와 특별 거래를 하지 않고도 데이터/워크로드를 코어에 바로 배치할 수 있는 능력이며, 최소한 20피트 컨테이너가 가득 차 있지 않는 한 훨씬 더 많은 탄력성을 제공할 수 있다는 것입니다. 서버 규모 컴퓨팅 요구 사항

httpswww.cloudflare.com/products/tunnel/
httpsgithub.com/cloudflare/cloudflared
httpsdevelopers.cloudflare.com/cloudflare-one/connections..

편집: 누구나 자체 호스팅에 관심이 있다면 cloudflared를 사용하면 간단합니다. Flask 기반 웹사이트를 제공하는 맞춤 펌웨어에서 Ubuntu를 실행하는 2017 Google Pixelbook이 있습니다. 게스트 Wi-Fi 네트워크에 연결된 동안 내 책상에서 충전 중입니다. 100/100 모바일 PageSpeed ​​점수를 받았으며 완전히 로드하는 데 0.8초가 걸립니다.

DO에서는 신뢰할 수 있는 회사의 이점, 확장성, 자동 백업 등을 모두 얻습니다. 변경할 방법이 없습니다.

Hetzner 클라우드는 이제 미국에 두 곳의 위치를 ​​보유하고 있습니다. 하지만 여전히 미국 전용 서버는 없습니다. 이는 현실화될 것입니다. 현재 클라우드 서비스 자체가 이미 주요 클라우드 제품 가격의 ~30% 수준에 불과하더라도..

귀하와 마찬가지로 저도 임대한 물리적 서버에서 서비스를 실행합니다. 저는 Versaweb을 사용했는데, 그 기계가 너무 오래됐어요. 나는 이전에 Hetzner를 좋아하지 않았습니다. 왜냐하면 Hetzner가 실행 중인 작업을 방해한다는 나쁜 소식을 들었기 때문입니다.

그러나 Versaweb 인스턴스가 막 종료된 12월에 해당 솔루션으로 옮겼습니다. 아마도 노후된 SSD일 것입니다. 이제 Versaweb에 지불한 금액의 50%를 지불하고 있으며 이러한 Postgres 인스턴스를 6개 실행할 수 있습니다.

그렇다면 멋진 클라우드 UI, 자동 업그레이드 및 백업 등을 갖춘 관리형 서비스에 800달러 중 700달러를 지불할 가치가 있는지 궁금합니다.

1인 전시나 소규모 스타트업의 경우에는 그렇지 않다고 생각합니다. 사용 가능한 서비스를 사용하고 백업을 S3 또는 더 저렴한 서비스에 덤프하는 것이 더 저렴합니다.

나는 회사 A가 우리의 송장 발행 시스템에 잘 맞는 방식으로 분기별 송장을 보내려고 했기 때문에 회사 B가 정확히 동일한 서비스에 대해 청구하는 것보다 4배나 많은 급여를 받는 회사 A에서 일했습니다. 기업의 경우 여기저기서 수백 달러를 절약하는 것은 추가 마찰을 일으키는 번거로움을 겪을 가치가 없는 경우가 많습니다.

거기에는 암묵적인 비용이 있습니다. 그 중 한두 가지만 해당된다면 관리형 서비스를 이용하세요.

확장을 시작하면 이를 절약할 관리자 유형의 직원을 확보하세요.
그렇지 않으면 저널링된 PITR 백업을 항상 신속하게 복원할 수 있다는 것을 100% 확신하기 위해 매우 경험이 풍부한 사람을 고용/계약하거나 한 달 이상의 내 시간(사용할 수 없었음)을 바쳐야 합니다.

다른 곳에서는 클라우드 비용을 크게 절약할 수 있지만 신뢰할 수 있는 관리형 PostgreSQL은 꽤 쉬운 선택이었습니다(초급 수준 가격표가 예상보다 높더라도).

한 시간 분량의 생산 데이터를 잃어버릴 여유가 없는 초기 스타트업은 어쨌든 생존하기에는 너무 취약할 것입니다.

그것은 초기 시작입니다. 서비스에 대한 중단보다 더 큰 중단이 있을 것이고 생산 데이터가 한 시간 동안 손실된 후 도망가는 모든 고객은 어쨌든 제품의 가치를 충분히 평가하지 않았습니다.

(내가 생각하고 있던 특정 스타트업에서 보존이 적용된 S3에 대해 자동으로 빈번한 DB 온라인 덤프가 이미 있었지만 이 특정 시나리오에는 충분하지 않다고 생각했습니다. 하지만 PITR/저널링은 그렇지 않으면 몇 백 명을 절약하기 위해 몇/몇 년 안에 9자 이상의 출구를 가질 수 있는 비즈니스의 성공에 대한 새로운 단일 실패 지점 도박을 추가할 것입니다.)
또한 요구사항이 덜하지만 고객/사용자 데이터에 대한 의무에 대해 무심한 초기 스타트업 중 일부는 여전히 최소한의 기본 관행을 소홀히 하고 있다고 생각합니다.

감사할 수 있는 한 가지 직관적인 방법: HN에 대한 비즈니스 뉴스 기사를 상상해 보세요. 스타트업 설립자의 이름이 첨부된 일부 스타트업 운영에 대해 공이 떨어졌고 스토리에 따르면 그들은 좋은 백업이 없었다는 것이 밝혀졌습니다. 회사가 주변에서 충돌하면서 잠을 많이 못 잤을 수도 있는 공동 창업자들은 "고객 데이터는 초기 스타트업에서 그다지 중요하지 않습니다. 만약 그렇다면 우리는 너무 취약할 것입니다."(공동 창업자가 그 사람의 노트북을 던지기 전에 입력했습니다.) 타이핑을 멈추기 위해 방을 가로질러). 보기 좋지 않을텐데

나는 이것을 마지막에 다룰 것이다.

>HN에 대한 비즈니스 뉴스 기사를 상상해 보세요. 스타트업 창업자의 이름이 첨부된 일부 스타트업 운영에 대해 공이 떨어졌고 이야기에 따르면 그들은 좋은 백업이 없었습니다.

ITIM 그리고 그들이 마지막 시간을 백업하지 않은 것으로 밝혀졌습니다.
나는 당신의 시나리오에 있는 모든 것, 심지어 자르지 않은 부분까지 상상할 수 있으며, "한 달 동안 우리를 사용해 온 우리의 스타트업 고객들은 데이터의 마지막 한 시간을 잃어버리자 즉시 모두 떠났습니다"를 읽지 않는 한 모든 것이 정상으로 보입니다.

정말 상상도 못할 시나리오

물론 데이터 손실이 1시간도 되지 않는다는 장점이 있는 비즈니스도 있습니다.
IOW, 고객은 데이터 손실이 없기 때문에 이를 사용합니다: 온라인 문서 공동 작업[1], 예를 들어[2]. 마지막으로 입력한 데이터 중 한 시간이 손실되는 붕괴가 발생하면 영향을 받는 모든 현재 사용자가 즉시 도망칠 것으로 예상합니다.

[1] 개인적으로 편집 중인 현재 문서를 localstorage에 복제하여 위험을 완화하고 싶지만

[2] 어쩌면 증권 거래소도 마지막 데이터를 유지하기 위해 시스템이 필요할까요? 또 뭐?
더 큰 팀의 경우에도 데이터베이스를 잘 관리할 수 있는 능력이 있다고 가정하면 데이터베이스를 직접 관리하는 것이 합리적일 수 있습니다. 관리형 서비스에는 잘못될 수 있는 일이 너무 많으며 블록 스토리지 또는 개체 스토리지와 같은 방식으로 기본 구현을 숨기지 않습니다.

최고 성능은 확실히 더 나쁩니다. 서버 프로비저닝에서 많은 자동화를 갖는 것은 확실히 맞습니다. 제가 물리적 서버에서 하지 않은 일입니다.

나는 내 애완 동물 프로젝트를 위한 루트 서버를 가지고 있었지만 솔직히 그것은 말이 되지 않습니다. 나는 높은 트래픽을 실행하지 않고 내 컴퓨터에서 집약적인 SaaS를 계산합니다. 정적 웹사이트와 일부 프로젝트일 뿐입니다. 모든 데이터를 저장할 수 있는 1TB의 스토리지 박스를 포함하여 월 비용이 24로 줄었습니다.

실제 하드웨어와 관련된 모든 시나리오의 주요 문제는 하드웨어와 Linux/UNIX 시스템 모두에 능숙한 직원이 필요하다는 것입니다. 많은 사람들이 자신의 이력서에 있다고 주장하지만 직장에서 한 번도 수행할 수 없습니다(어쨌든 내 경험으로는). 제 생각에는 클라우드 세계가 폭발적으로 증가한 주요 이유 중 하나는 바로 그러한 팀을 구축하는 데 드는 비용과 구축의 어려움이었습니다. 또한 애플리케이션 개발자와 시스템 담당자 사이에는 다소 자연스러운(그리고 필요한) 마찰이 있습니다. 시스템 담당자는 항상 반발하고 더 많은 보안, 더 많은 프로세스 및 더 적은 배포를 주장해야 합니다. 개발팀은 항상 더 많은 유연성, 더 많은 릴리스, 더 적은 프로세스를 주장해야 합니다. 좋은 경영진은 그 둘 사이의 중간 경로를 공격해야 합니다. 불행히도 무능한 관리자는 종종 시스템 인력을 제거하고 AWS 땅으로 옮기기로 결정했습니다.

마지막으로 클라우드 아키텍처는 클라우드 공급자의 과도한 프로비저닝이 필요하고 많은 추상화 계층으로 인해 전반적으로 더 많은 컴퓨터 성능이 필요하기 때문에 지구에 좋지 않다는 점에 주목하고 싶습니다. 모든 프로젝트는 이러한 낭비에 대해 거의 책임이 없지만 집합체로서의 전체 글로벌 클라우드는 매우 낭비적입니다. 이것은 나를 귀찮게 하고 분명히 내 관점에서 감정적 편견으로 작용할 가능성이 있습니다(위의 모든 것에 대해 너무 많은 양의 소금).
수입 전에 물리적 서버를 임대할 수 있는 수단을 개발할 수 있다는 주장이 제기될 수 있으며, 그런 다음 그것이 합리적일 때 표준 감가상각을 사용할 수 있습니다.

예를 들어, 중복성을 위해 서로 다른 colo 시설에 절대적으로 오버프로비저닝된 $100,000의 물리적 1U 머신 4대로 구성된 매우 유능한 그룹을 배포할 수 있습니다. 여기에는 XYZ 클라우드 서비스, DNS, 애니캐스트 등 원하는 대로 로드 밸런싱 및 페일오버를 위한 모든 종류의 트릭이 있습니다. 전 세계에서 데이터 센터를 운영하는 다양한 colo 시설을 이용하여 공급업체에서 하드웨어를 배송한 다음 시설을 보거나 하드웨어를 만지지 않고도 Ansible 또는 원하는 모든 것을 프로비저닝할 수 있습니다.

따라서 이제 대부분의 클라우드 제공업체(특히 I/O의 경우) 주변을 절대적으로 돌릴 중복된 물리적 하드웨어, 가능한 모든 대역폭과 같은 고정 비용(클라우드 서비스의 800% 마크업이 없는 등)이 있으므로 더 이상 기다릴 필요가 없습니다. 불가피한 $50,000 클라우드 청구서 또는 한 달이 아닌 하루 만에 구성된 클라우드 예산을 초과하게 된 원인을 추적하려고 시도하는 경우(공황 상태에서). 아 btw, $BIGCLOUD에서 제공하는 가상 머신 이외의 서비스를 프로비저닝하고 활용하기 위해 구피 독점 API에 자신을 가두는 것이 아닙니다.

ML을 수행하는 경우 자체 하드웨어 또는(또는 가끔 클라우드)에서 훈련하고 NVIDIA A10과 같은 장치로 24/7 추론을 실행할 수 있습니다. GPU 인스턴스를 위한 지속적인 클라우드 임대는 믿을 수 없을 정도로 비싸고 하드웨어 구매에 대한 ROI는 일반적으로 몇 개월 범위에 있습니다(또는 섹션 179로 거의 즉시 앞서갑니다). 예를 들어 최근에 우리가 제공하는 모델에 대해 Nvidia A10으로 벤치마크를 수행했으며 FP32에서 10ms 미만의 대기 시간으로 초당 700개 이상의 추론 요청을 수행할 수 있습니다. 2800 req/s(추가 조정 가능)인 4개의 정상 인스턴스에 걸쳐 섀시당 단일 A10 사용

그런 다음 정말 커지면 캐비닛과 그 이상을 얻을 수 있습니다. 언급한 하드웨어 오류 측면에서 내가 말할 수 있는 것은 이중 PS RAID 아웃 등 하드웨어가 (내 경험상) 매우 안정적이라는 것입니다. 공급업체는 교체를 위한 놀라운 SLA를 포함할 것입니다. 실패를 알리면 기술자를 보냅니다.< colo 시설로 직접 8시간 이동하여 디스크, PS 등을 깜박이는 표시등으로 교체

내 경험으로는 하나의 (훌륭한) FTE 리소스가 여러 캐비닛 규모까지 쉽게 관리할 수 있습니다. 요점은 현재 문제는 이들 중 많은 사람들이 대형 클라우드 제공업체에 의해 납치되어 (시장에서) $에서 수십 개(더는 아니더라도) 제품/서비스를 사용하는 경계선 어리석음을 탐색할 수 있는 리소스로 대체되었다는 것입니다. 빅클라우드

나는 또한 이 구성이 대부분의 $BIGCLOUD보다 실제로 훨씬 더 안정적이라는 것을 발견했습니다. 더 이상 $BIGCLOUD 중단으로 인해 그들이 인정조차 하지 않는(그리고 당신이 절대적으로 통제할 수 없는) 무슨 일이 일어나고 있는지 궁금해하지 않아도 됩니다. 통신 및 의료 분야의 배경에서 온 나는 클라우드 제공업체로 인해 가동 시간이 실제로 얼마나 악화되었는지 완전히 열광했습니다. 일반적으로 고객에게 "오 오늘 인터넷에 문제가 있습니다"라고 말할 수 있습니다. 왜냐하면 고객은 이에 대한 헤드라인을 보게 될 것이기 때문입니다.

[0] - httpswww.section179.org/section_179_deduction/
[1] = httpswww.section179.org/section_179_leases/
새 프로젝트를 시작하거나 새로운 것을 호스팅하려고 하면 몇 분이 걸리고 스크립트가 있습니다. 배포가 빠르고 유지 관리가 적으며 비용 대비 훨씬 더 많은 것을 가지고 있습니다.

관심이 있는 사람을 위해 이것은 내가 사용하는 것의 대략적인 컷입니다.
* 모든 것을 관리할 수 있는 Ansible
* 언젠가 교체할 수 있는 일부 DNS 항목에 대한 약간의 terraform
* 백업용 restic, 다시 ansible에 의해 제어됨
* vpn용 테일스케일(집에서 파이를 실행하고 있는데 중요한 것은 없지만 테일스케일을 사용하면 쉽고 안전함)
* 거의 모든 것을 위한 docker-compose
기본 앱은 Clojure이므로 기본 JVM을 실행합니다. 데이터베이스는 완전히 분산되어 있으며, RethinkDB는 현재 FoundationDB로 이동 중입니다.

중요한 것은 어떤 것도 수동으로 관리하지 않는 것입니다. 다른 클라우드 서버와 마찬가지로 물리적 서버를 취급합니다. 물리적이든 가상화든 중요하지 않습니다.

나는 $5-10 vps가 효과가 있었을 때 경험이 적은 많은 사람들이 hetzner 및 이와 유사하게 초과 지불하는 것을 보았습니다.

예, 그 시점에서 자체 하드웨어를 지원하고 있습니다. 아니요, 큰 두통이 아닙니다.

이것에 대한 가장 큰 추가 비용은 더 많은 IPv4 주소를 임대하는 것입니다.

무엇을 만들든 0명의 사용자로 시작하며 전체 실제 시스템은 0 로드에 대해 완전히 과도합니다. VPS를 한 쌍의 실제 머신으로 업그레이드한 다음 소규모 임대 클러스터로 업그레이드한 다음 데이터 센터로 업그레이드합니다(누군가가 이를 약화시키지 않는 경우). 이들 모두는 가격 대비 예측 가능한 비용과 최고의 성능을 제공합니다.

콜로에서 소유하고 있는 모든 것 역시 한 달에 더 비쌀 것입니다. 고정 IP에 대한 비용을 지불할 수 있는 연결이 있을 때 일반적으로 월 $5였습니다.
지금은 꽤 저가형 서버를 임대하고 있는데 월 30달러입니다. 필요한 것이 훨씬 많지만 좋네요. 그리고 그들은 지원 등을 개선하기 위해 가격을 인상하면서 내 OS에 대한 지원을 중단하지 않았습니다. (처음에는 교체가 필요한 일부 이상한 하드웨어가 있었지만)
당신이 지적했듯이 베어 메탈이 갈 길입니다. 클라우드와 반대되는 방식으로 작동합니다. 처음에는 작업량이 조금 더 많지만 마지막에는 훨씬 적은 비용이 듭니다.

추가 정보 httpseuropa.eu/youreurope/business/taxation/vat/cross-bor..

Postgres를 설정하고 관리하는 것은 고통스럽습니다. 이 모든 것을 해결하는 더 간단한 방법이 있으면 좋을 것입니다.

1. VM이 다운될 때 구성을 재현할 수 있도록 강제합니다.

2. AWS에서는 고통을 줄여주는 대폭 할인을 받을 수 있습니다.

3. 귀하의 자료가 이미 클라우드에 있으면 더 저렴하고 빠른 VM 위에 액세스할 수 있는 다른 자료
4. 내부에 어떤 특수한 항목이 있는지 직원을 교육하거나 문서화하는 것보다 문서화된 시스템 구성(예: AWS 문서)을 갖는 것이 더 쉽습니다. 새로운 사람을 채용할 때 특히 유용합니다.

5. 현장에 공간이나 여분의 전원/인터넷 등이 필요하지 않습니다. 사람들이 노트북을 사용할 수 있을 만큼 충분합니다.

그 전에는 VPS를 사용했지만 더 나은 거래였고 CPU 제한에 부딪히지 않았기 때문에 중지하고 실제 VPS로 전환했습니다.

디스크 모니터링은 그리 어렵지 않습니다. 하드 드라이브의 경우 한 시간에 한 번씩 smartctl을 실행하고, 재할당되거나 보류 중인 섹터가 빠르게 증가하거나 100에 도달하면 경고합니다. SSD의 경우 손가락을 교차시키십시오. 수천 명의 경험에 따르면 버스에서 사라지고 다시는 볼 수 없을 때까지 훌륭하게 작동하는 경향이 있습니다. 시간당 전력이 매우 유사한 동일한 모델 장치에 데이터를 저장하지 않는 데이터 복구 계획을 세우십시오. 상관된 펌웨어 오류는 실제입니다.

Hetzner에는 결국 전용 서버를 주문하기 위한 API와 OS 설치를 위한 API(또는 원하는 이미지를 복구하고 플래싱하기 위해 재부팅하기 위한 API)가 있습니다.
상업용 옵션을 조사하고 있었다면 상업용 isp 솔루션, 고정 IP, 좋은 IT 하드웨어를 사용하여 사무실에서 "트렁크"를 분류했을 것입니다. 그러나 클라이언트가 호스팅을 필요로 하는 경우 바로 이 순간에 제가 아는 바로는 d 항상 바로 vps 대여하러 가세요

나는 그 당시 주니어 개발자에 가까웠기 때문에 아마도 그랬을지도 모르지만 전혀 그리워하지 않습니다. 이론적으로는 나는 당신의 말에 동의하지만 Google Cloud Run과 같은 것에 Dockerfile을 배포하는 것이 훨씬 쉽습니다. 네, 저는 제가 직접 VPS를 관리하는 것보다 더 많은 비용을 지불하고 있지만, 이는 절약된 개발 시간으로 상쇄되는 것 이상이라고 생각합니다.

- 물리적 하드웨어에 문제가 있습니다. 팬 오류 ->내 VM이 다른 호스트로 실시간 마이그레이션되지만 눈치 채지 못하거나 신경 쓰지 않습니다.
- 물리적 하드웨어 폭발 ->내 VM이 다른 호스트에서 다시 시작됩니다. 알아차릴 수도 있지만 상관하지 않습니다.
 VM을 사용하면 재해 계획이 훨씬 쉬워집니다(소가 아닌 애완동물도 포함).

초보자에게는 가장 저렴한 것이 작업을 완료합니다.

클라우드 컴퓨팅이 발전함에 따라 이러한 서비스가 더욱 보편화될 것이라고 확신합니다.

클라우드 컴퓨팅에는 또 다른 측면이 있습니다. 중대형 기업은 비용 계산 시 클라우드 컴퓨팅을 한 자릿수 비율로 계산합니다. 즉, 관리자와 팀이 내리는 결정은 종종 "내 설정이 비싸거나 저렴하지 않은지"보다는 안정성과 확장성(프레젠테이션에 표시)을 찾습니다.

고용주는 클라우드를 종교적인 목적이 아닌 비즈니스/금융 목적으로 채택했습니다. 우리는 종종 클라우드에 새 빌드를 배치하고 나중에 적절한 경우 데이터 센터로 마이그레이션합니다.

온프레미스 앱의 비용은 약 40% 저렴합니다. 클라우드에서 더 비용 효율적인 앱은 그대로 유지

AWS/GCP/Azure가 유럽에서 그다지 비용 경쟁력이 없는 제품인 경우라고 생각합니다. 내가 보지 못하는 것은 미국에 대한 증거입니다.

같은 사양이면 당연히. 나는 가상이 양쪽 끝에서 의미가 있다고 생각합니다. 큰 N에 대한 동적 확장성이 중요하거나 실제로 물리적 상자의 작은 부분만 필요합니다. 월 5회 find를 실행하는 것에 대해 월 45달러를 지불하는 것도 현명하지 않으며 서버를 사용하기 위해 여러 항목을 함께 묶지 않아도 되는 더 많은 유연성을 제공합니다.

어떤 경우에도 백업을 유지하십시오. 바람직하게는 다른 공급자 또는 적어도 다른 물리적 위치에 있습니다. 그리고 물론 테스트

그리고 좋은 백업 체계를 관리하고 데이터/앱을 모니터링하고 있다면 드라이브 모니터링이 더 큰 어려움입니까?
--
[1] 실제로 복원 프로세스를 다른 위치로 자동화하는 경우(내가 약간의 비트에 대해 수행함) 완료되면 해당 버튼을 누르고 DNS를 업데이트하고 RAM+코어를 조금 더 할당할 수 있습니다(내 테스트 미러는 실제 사용 패턴을 제공할 필요가 없으므로 라이브 VM보다 작습니다.)

내가 나 자신과 고객을 위해 하는 일입니다. 엄청난 양의 도쉬를 절약합니다

업데이트를 원하더라도 최신 버전을 docker-compose 템플릿으로 가져오고 ansible 플레이북을 다시 실행하는 경우일 뿐입니다. 분명히 업그레이드에 더 많은 것이 필요하다면 그렇게 하겠지만 다른 설정 작업과 다르지 않습니다.

아마도 내가 수동으로 수행하는 유일한_필요한_ 작업은 내 백업을 테스트하는 것입니다. 그러나 각 프로젝트에 대한 스크립트가 있으므로 SSH를 켜고 한 줄짜리를 실행하고 결과를 확인하면 완료됩니다. 대략 한 달에 한 번 정도 하는데 백업이 실패하면 이메일도 받습니다.
따라서 시간이 전혀 없을 수 있습니다. 반정기적으로 업데이트를 받는 경우 일반적으로 한 달에 1-2시간 정도입니다. 하지만 호스팅하고 관리하는 항목이 많을수록 확장됩니다.

즉, 유일한 차이점은 ansible 인벤토리 파일의 출처입니다. 정적 IP 목록이거나 terraform에서 가져온 것입니다.

ECC RAM을 원하는 경우 월 60개로 표시되며 더 강력한 8코어 CPU로 업그레이드됩니다.

그럼에도 불구하고 "완전한 프로덕션 환경과 중복된 스테이징/대기 환경"(회신한 사람 인용)에 대해 이야기하는 경우 60/월 *(2 또는 3)은 스타트업의 AWS에 비해 여전히 매우 저렴합니다. 내가 본 청구서

사용 사례는 다양하지만 AWS/GCP/Azure가 모든 문제에 대한 답이 아니라는 데 동의하는 경향이 있습니다.

애플리케이션을 4달러 VPS에 맞출 수 있는 사람에게는 베어 메탈보다 분명히 저렴할 것이지만 클라우드는 많은 경우에 매우 비쌉니다. 베어메탈이 모든 문제에 대한 답은 아니지만 업계의 많은 사람들은 베어메탈이 정답이 될 수 있음을 인식하지 못하는 것 같습니다.