4 ドルの VPS からどれくらい利益が得られますか?

仮想化製品のパフォーマンスは大幅に低下します (私の 2019 年の実験を参照してください: httpsjan.rychter.com/enblog/cloud-server-cpu-performance とコストが高くなります。違いは、「オンデマンドでスケール」できることですが、これは必要ではないことがわかりましたが、少なくとも私の場合は、スケールする必要がある場合でも、それは可能ですが、新しいサーバーを取得するのに数秒ではなく数時間かかるというだけです。まあ、数秒でスケールする必要はありません私の場合、完全な運用環境と複製ステージング / スタンバイ環境に対する月々の請求額は一定で、シンプルで、予測可能であり、AWS に支払う必要がある金額と比較して非常に低く、パフォーマンスにはまだ十分な余裕があります。注目すべき点の 1 つは、私が物理サーバーを仮想サーバーと同じように扱っていることです。すべてが Ansible を通じて管理され、すべてを最初から再作成できます。実際、私は Digital Ocean で別の「devcloud」環境を使用しています。その環境は、残りのセットアップを行う ansible に渡される前に、terraform を使用してスピンアップされています。 VendorOps や kubernetes などの複雑なツールは、過去 10 年間に出現した複雑さを売りにする業者によって好まれているのではないかと思います。履歴書に見栄えがよく、技術リーダーに誤った達成感を与える一方、Stackoverflow はおそらくほとんどのスタートアップよりも重要だが、専用マシンで順調に進んでいる 1: httpsstackoverflow.blog/2016/02/17/stack-overflow-the-arc.. この分野のトレンドは、抽象化の最上位層に直接ジャンプすることのようです。基本的なことは省略し、$buzzword ツール、ライブラリ、製品を紹介しますこれはさまざまな形で垣間見ることができます。 1 つはソーシャルメディアのスレッドで、Y を学ぶには 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は素晴らしいです！競合する可能性のあるビジネスが Kubernetes を使い始めているのを見ると、もう心配する必要がないことがわかり、すぐに安心します。彼らは、信じられないほど複雑な技術スタックの中で追跡できない問題を解決しようとしたり、トラフィックが 2/3 も大きいビジネス向けに設計されたシステムによって課せられた制限を回避したりしながら、解決不可能な技術的問題の山の中に消えようとしています。また、彼らのCOGSは私よりもはるかに高いでしょう。つまり、VCの資金を使い果たしている場合を除き、製品の価格を高くする必要があることを意味します（その場合、彼らは鍋の中でのフラッシュです）あちこちに良いものがある Ansible は命令型であり、静的な状態に向けて動作することができ、それだけです。問題が発生すると、SSH 接続が切断され、大量の Python エラーが発生し、永久に諦めてしまいます。目録があっても宣言的とは程遠い k8s は、宣言された状態に向かって前進しようとする制御ループです。失敗しても問題はありません。再試行されます。自身の状態を常にチェックし、それを報告するための優れた API を備えています。また、多くの具体化された概念のおかげで、デプロイされたコンポーネント間で奇妙な衝突が起こりにくくなっています。 (ただし、複数の Playbook を Ansible と統合するのは簡単ではありません。) httpsgithub.com/spantaleev/matrix-docker-ansible-deploy そして、たとえ k8s がレガシーらしさを強調しすぎたとしても、核となるアイデアをよりスリムに表現するものが今後登場します。 (例: httpsgithub.com/aurae-runtime/aurae ) そして今、あなたは人々がより単純な非標準実装を使用することを提案していますか? したがって、もちろん、複雑さを最小限に抑えたソリューションを実装することも、「既製」のものを使用することもできます。 k8s は複雑であり、その一部はあなたの状況には明らかに不必要ですが、かなり汎用性があり、柔軟性があり、サポートが充実しているなどの特徴があります。 >より単純な非標準実装を使用することを勧めているのでしょうか? 私が提案したのは、k8s のプロジェクトやソフトウェアが失敗するには大きすぎる場合、人々は代替案に切り替えることができるということです。幸いなことに、k8s の概念と API はオープンソースなので、他のプロジェクトに実装できます。k8s の選択が Oracle のようなベンダーロックインではないことを説明するために、このような例を挙げました。クラウドプロバイダーからは、素晴らしいものが実質無料で手に入るという話をよく聞きます。実際、そのようなものはセットアップも使用も簡単ですか?クラウドサービス上に LAMP スタックをセットアップしようとするたびに、非常に複雑で恐ろしいプロセスだったので、結局あきらめてしまいました。もう少し頑張ればクラウドヘブンに行けるのではないかと思っている「このような仕様のクラスター化された MySQL が必要です」と言えることは、自分で行うよりも (時間の点で) はるかに優れています。アップデートもシステムに適切に組み込まれているため、フェールオーバー/再起動が正しい順序で行われることを手動で確認するのではなく、単に「最新のアップデートを適用する」と言っているだけです。つまり、物事を簡素化するためにお金を払うことになりますが、その簡素化による利益は大規模なプロジェクトでのみ発揮されます。ユーザーにエラーページが表示されている間に再起動できる機能が 1 つのサーバー内にある場合は、価値がない可能性があります。クラウドは簡単ではありませんが、小規模なサーバールームの冷却効率と電力効率を効率レベルに近いレベルにまで高めることは困難ですが、大規模なデータセンターでのパブリッシュは、マルチベンダーのインターネット接続と同様に不可能に近いです。クラウドでは、そのクラウドを実行しているデータセンター運営者によって管理されるため、そのようなことはすべてなくなりますが、人々が忘れているのは、クラウドよりも優れたコスト/価値を提供している昔ながらのコロケーションサービスにも同様であるということです。 AWS や Azure のようなものを管理するのは確かに困難ですが、小規模な vpc プロバイダーが隠れていたり、単一のホームサーバーでは実際には得られない抽象化が大量に流出するため、いくつかのサーバーを実行するという規模では難しくありません。 SAN ベースのストレージを備えた VMware サーバーに相当するラック数クラウド関連の場合は、仮想サーバーなどの設定が必要になるため、さらに多くの設定を行う必要があります。 PC を箱に入れて部屋に持ち込むのではなく、利用できるように「設定」する必要があります。 DO データベースには、好みに合わせて構成できるバックアップがあり、DO スペース (S3 など) に保存できます。 DBのユーザー管理も簡単です。 Redis用のキャッシュサーバーもありますロードバランサーを追加して、さまざまな Web サーバーに接続できます。 2 つの Web サーバー、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 にも同じことが言えます。これは規律あるチームを持つことで解決できますが、一般的には、長時間実行される専用マシンが 1 台ある環境で発生する可能性が高いと思います。 Hetzner には、マネージドデータベースを除くすべての機能が備わっています。 httpswww.hetzner.com/管理対象サーバーウェブホスティングパッケージには、1..無制限の DB (MySQL および PostgreSQL) も含まれています。 httpswww.hetzner.com/webhosting/ 自動バックアップとフェイルオーバーはありますか? >予約された毎日のバックアップ、またはサーバーのタイプに含まれるバックアップでは、すべてのデータが毎日バックアップされ、最大 14 日間保持されます。 konsoleH管理インターフェース経由でバックアップの復元（復元）が可能しかし、管理対象サーバー上のデータベースは、そのサーバー上で実行されているアプリによって使用されることを目的としているという印象があるため、実際にはフェイルオーバーの概念はありません。 httpswww.hetzner.com/legal/managed-server/ 単一サーバー上の単一ドライブに障害が発生しても、運用停止が発生することはありません。構成上の問題の多くは、自己完結型の展開にまで遡ることができます。そのフォントファイルまたは JRE は本当にサーバー全体にインストールする必要がありますか、それとも展開にバンドルできますか? 当社のデプロイメントでは、オンプレミスおよび EC2 ターゲットを使用します。デプロイメントスクリプトは変わりません。ホストの IP が異なるだけです。さて、何かに S3 を使用できるかどうかは、100% 使用するつもりです。同じ機能セットを備えたオンプレミスの代替手段はありません DevOps のポイントは「ペットではなく牛」です。週に 1 回、サーバーに箇条書きを入れて、障害点を見つけます。少なくとも Dokku を使用している他のユーザーのエクスペリエンスを向上させるために、Discord/Slack に参加して、発生している問題のいくつかを提起していただければ幸いです。遠慮せずに私に連絡してください（私のニックネームは「サヴァン」です）前置きして、私は Docker の実践的な知識しかないアプリケーション開発者であることを言っておきます。私はインフラに関してそれほど熟練しているわけではなく、私が苦労したアプリケーションには独特のデプロイメントパラメータがありました。これは、ビルド時に数ギガの静的 HTML クロールを解析して、ビルド後に静的な Postgres データベースにデータを取り込む Python アプリケーションです。次に、Flask Web アプリがそのデータベースに対して機能します。HTML 解析は急速に進化するため、入力された DB データはアプリケーションイメージの一部としてバンドルする必要がありますIIRC、構造化に苦労しましたDB が永続的ではなく、アプリの単なる一時的な部分であったときの Dockerfile ですが、それは克服できるように見えました。より大きな問題は、特に DigitalOcean と私のローカル環境全体で正常に動作する方法で、理想的にはキャッシュされるのに、ビルドごとにほとんど変更されないデータを S3 から取得することを回避する方法であるように見えました。適切な Docker イメージレイヤーキャッシュがこの問題に対処すると推測しますが、私の知識と忍耐力は急速に限界に達しましたDokku の DX は確かにそうです普通のことをしている人には最適です。:)0. httpscoolify.io/さらに、他人のお金で最新の最もクールなおもちゃで遊びたくない人がいるでしょうか？柔軟性 (またはフラックス/ピボットへの対応) が主な推進要因ではなくなり、スケール/コストが支配的になり始めると、旅の後半で (一部の) ものをクラウドから移動するという議論が間違いなくあります。確かに、Hetzner で何かを動かすことはできますが、さらに多くの質問に答える準備をしてください企業が求める最後の点については同意しましたこれもまた悲しいことですが、別の方法の方がはるかに優れている可能性があるにもかかわらず、これらのビジネス「要件」がソフトウェアを構築してホストする方法を決定するのです。災害復旧は非常に現実的な問題です。だからこそ私は定期的にテストを行っています。焦土のシナリオでは、1 時間以内にセカンダリ (ステージング) システムまたはテラフォーミングクラウドシステムを稼働させることができます。私のビジネスではそれだけで十分です私たちは成長ブームを経験しましたが、これまでのすべての企業と同様に、多くの経験の浅い人々が多額の資金と緊急の期待を与えられることを意味していました。それは貨物の養殖と搾取的なマーケティングのレシピですしかし、成長は鈍化し、資金はより高価になっているので、ペースを落として、エキサイティングな新しいバリエーションで古い教訓を再学習し始めてください。 (例: ベアメタルのスケーリングとコンテナーおよびオーケストレーションの管理) そしてこのサイクル全体が次のブームで繰り返されます。それが今のところ私たちの業界です堅牢な専用サーバーは、99% の場合、共有ハードウェア上の機能不全の VPS よりもはるかに便利ですが、提供されるリソースをすべて必要としない場合は明らかにコストが高くなります。はい、しかし、「今、クールな子供たちがやっているようなことをしたい」という願望は、通常「従業員」ではなく「マネージャー」と呼ばれる人々の間でも少なくとも同じくらい強いです。結果 A) マイクロサービス/クラウドへの巨額の支出がうまくいかない、少なくともベストプラクティスに従っていた、これらのことが起こる、どうすればよいか結果 B) Hetzner サーバーを使用したところ、何か問題が発生しました。そうですね、あなたはマイクロサービスを使用するべきでした。新しい仕事を探すのを楽しんでください。したがって、管理者にマイクロサービス/クラウドの選択を奨励します。会社にとっては正しい決断ではないかもしれないが、マネージャーにとっては正しい決断であり、決断を下すのはマネージャーである (コンサルタントとして拡張機能を欲しがったり、機能するソフトウェアを作成したりすることも同様です。これは私が苦労してわかったことです。) 創業者と他の人々の間には断絶がある創業者は毎年 10 倍以上になると信じている現実には、90％の確率で失敗する 90% の確率で、何に失敗しても大丈夫です成功する 10% のうちの数% は、クラウドなしでも問題ありません。少なくとも数年間は成功しており、必要に応じて切り替える時間は十分にあります。 Ansible セットアップは 1 つだけあり、仮想サーバーと物理サーバーの両方で機能します。変わりはない。唯一の違いは、仮想サーバーは最初に terraform でセットアップする必要があり、物理サーバーは最初に注文してその IP を構成ファイル (インベントリ) に入力する必要があることです。もちろん、他の多くのクラウドサービスに依存しないように気をつけています。たとえば、サーバー間の通信には VpnCloud (httpsgithub.com/dswd/vpncloud) を使用します。副次的な利点として、いつでもインフラストラクチャプロバイダーに切り替えることができる柔軟性も得られます。私の主なポイントは、仮想化サービスには確かに用途があるものの、月額 10 ドルの趣味用 VPS と、爆発的に成長する B2C ビジネスを抱える企業との間には (大きな) ギャップがあるということでした。実際、ほとんどの新規ビジネスはそのギャップに陥っています。収益性の高い B2B SaaS では、ホッケースティックのような指数関数的な成長は期待できません。ここで、「AWS を使用する」という通常のデフォルトの選択に疑問を持たなければなりません。私は COGS とマージンを気にしているので、この選択を非常に慎重に検討しますあなたはソフトウェア会社ではありません。基本的にはスプロケットを製造して販売しています。ここでの意見は、「サーバーの購入と保守」（PaaS は悪い）のために大規模な技術/IT スタッフを雇い、その後「自分で AOF コードを書く」（SaaS は悪い）か、または現在ここで人気のあるものなら何でもするだろう（最後のスレッドはここでした）「Git を使わずに SFTP 経由で PHP をプッシュすると、もっと必要になるでしょう」(笑)) しかし、企業は One Thing Well を実行し、コアコンピテンシー以外のことで競争しようとする (手作業で行う) ことは避けるべきだと私は信じています。この場合、Sprocket Master は自分でハードウェアを管理しようとせず、スケーリング、セキュリティ、稼働時間、コンプライアンス、その他すべての細かい点を処理するプロバイダーに依存すべきであると私は間違いなく思います。また、彼らのソフトウェアはできる限り社内で使用せず、標準的なものであるべきだと思います。彼らはソフトウェアショップではないので、できるだけ少ないコードを書くべきです現実的には、ウィジェットマスターは、すべてを手動で行うことにしない限り、かなり少ないスタッフでこれらのサイトを運営できます。その場合、おそらくはるかに多くのスタッフが必要になるでしょう。しかし、私が目にしたこと、そして前の投稿者が話していたと思うことは、テクノロジーがビジネスの中心にあるビジネスであり、そこではテクノロジーがあまり意味をなさないことが多く、時間を節約するどころか時間を費やしているように見えます。 AWS の専門家がいるのには理由があります。それは簡単なことではありません。「リアル」サーバーも簡単ではありませんが、必ずしもクラウドサービスよりも難しいわけではありませんしかし、これらの代理店は、物理的なハードウェアを保守するための人員も必要としたくありません。しかし、Sprocket Masters は、緊急事態に対応するためだけに、依然として高価なクラウドコンサルタントを雇用する必要があります。クラウドの問題に対処するスタッフを配置する場合は、代わりにサーバーをレンタルした方がよいでしょう。私自身、初期の頃はビジネス用に専用サーバーを実行していましたが、事業が拡大し規模が拡大するにつれて、コストは上がっても、クラウドプロバイダーを利用してさまざまなサービスを迅速にプロビジョニングすることがはるかに簡単になりました。言うまでもなく、見込み顧客に「AWS のようなクラウド」を使用していることを伝えるほうが、「ああ、これらのマシンをどこかの会社が運営するデータセンターでレンタルしています」と伝えるよりもはるかに簡単です (実際にはその方が良い場合もありますが、顧客はほとんどそれを理解しません) 。監査、コンプライアンス等多くの人にとっては、それよりもはるかに少ないです。私は小規模なサイドプロジェクト [1] を実行していますが、これは数回話題になり (24 時間ほどで 30,000 ビュー)、シングルコア CPU の Web サーバー上で実行されており、マネージド Postgres も同様にシングル CPU コア上で実行されています。完全に活用されていません 1: httpsaihelperbot.com/ それらの一部をラムダ関数に切り替えることはできますか? それとも ECS に切り替えますか? それとも、定期的に他のクラウドサービスに切り替えますか? 多分。しかし、私がこのコメントを書くのに費やした時間は、すでにそのような切り替えのための約6か月分の節約に相当します。「ボタンを押すだけで 100% 信頼性の高い翻訳サービスを受ける」よりも難しい場合、それを正当化するのは困難です。これは、現在クラウドがこの種のことを可能にする他のサービスを提供しているためでもあります。基本的なメッセージングのために Kafka クラスターを実行する必要はありません。それらにはすべてメッセージバスが付属しています。それを使っています。ホスト型 DB オプションを使用します。 S3または同等のものなどを使用しています。 EC2 インスタンス上で実行するために月に 1 桁のドルを支払っている場合、残ったものは、他のパラダイムに自分を押し込む手間をかける価値がほとんどないことに気づきました。誰もが、あるいはすべてのプロジェクトがこれを実行できるわけではないことは間違いありません。私はこれを最終目標として固執しているわけではありません。それが機能しない場合は、すぐに適切なスケーリングアクションを実行します。これに基づいて何かを再構築することを提案しているわけではありません。私が言いたいのは、それは軽蔑される選択肢ではないということです。非常に柔軟性があり、請求は非常に一貫しています (別の言い方をすれば、トラフィックが突然 50 倍になると、単に数百ドルを請求するのではなく、システムが異常に詰まり、スパッタリングし始めるという事実です)私にとって、これはバグというよりも機能です)、また、通常、一部のクラウドサービスにとっては便利でも、自分にとっては便利ではない可能性があるパラダイムに自分自身をねじ曲げる必要はありません。これらの環境の 1 つを管理する必要があったことがありますか? 問題は、基本的な複数人用のスケーラビリティと適切な DevOps を取得したい場合は、かなりの要素でオーバープロビジョニングする必要があるということです (おそらく節約が無効になる可能性があります)。最終的にはオーダーメードのソリューションになることは避けられません。つまり、新しい入社者はシステムを使いこなすのに苦労し、会社を辞めた重要な人材はインフラストラクチャに関する詳しい知識を持ち帰ることになります。牛ではなくペットに戻りました。一部のサーバーは特殊で、しばらくすると自動化は「あちこちに大量のグルーシェルスクリプト」を意味し、OS アップグレードはインフラの半分がしばらく停止するか、OS アップグレードをまったく行わないかのどちらかを意味します。幸運な場合には、スケールアップする必要があります。不快な驚きが見つかるかもしれませんそして、決して私にネットワーク側の話をさせないでください。ラック全体を借りて独自のネットワークハードウェアを配置しない限り、得られるものは得られます。特別なことをしていないと仮定すると、機能またはパフォーマンスのいずれかが非常に悪い可能性があります 100.0000% の稼働率が必要な場合は、もちろんです。しかし、通常はそうではありません。このような稼働時間を望む企業は通常、それを専門とするチームを抱えています。また、垂直方向にスケーリングすると、ベアメタルでもスケーリングがうまく機能します。単一サーバーから得られる電力とスループットの量をご存知ですか? 話者が「水平スケーリング」を意味しているのに、「スケーリング」について何度も聞かれるのは憂慮すべきことです。要件が「スケーリング」である場合、垂直スケーリングは遠くまで行きます。要件が「オンデマンドの水平スケーリング」である場合、クラウドプロバイダーが確かに役に立ちます。しかし、そのようなスケーリングが必要な場所はほとんどありませんベアメタルで 100% の稼働時間が安いと言っているのではなく、100% の稼働時間は頻繁に必要ないと言っているのです。なぜなら、この業界にはトレンドやキーワードを追いかけている人がたくさんいて、それらのキーワードを履歴書に追加することが最も重要だからです。スケーラビリティを目的とした IME は、ほとんどのサービス/アプリケーションなどにとって非常に間違っています。そして通常、「スケーラブルな」ソリューションには多大なオーバーヘッドを支払うため、それを補うためにスケールする必要があります。これには本当に疑問を感じます。ほぼすべての AWS 支持者に見られるテーマの 1 つは、AWS が実際に提供する保証についてのかなりの妄想ですそうですね、確かに。IBM から製品を買ったからといって解雇される人はいないまあ、大企業に意思決定能力があれば無敵であり、他のことに取り組むのは絶望的でしょう。全て。つまり、そうです、それは公共財です出典: ほぼ 30 年間の運用これまでのところ、もっとお金をかければそれに気づくことはありません会社の給料も上がるのでアイロンで同等の信頼性を得るには、「2 台の専用サーバー」をレンタルするよりはるかに高価です - 今なら 1 台のサーバーとバックアップソリューションで大丈夫かもしれません、それは公平です。しかし、初期セットアップとメンテナンスなしの短期契約であっても、これらすべてを作成するためのシステム管理システムは、特にデータベースが混在していてそのデータを気にする場合には、クラウドの価格差をはるかに超えることになるでしょう今日、クラウドも同様です。可動部分が少ないため、市場投入までの時間が短縮されます。経済が低迷し、成長が鈍化すると、豆売りがやって来て自分の仕事をするそれは毎回起こるこれは AWS をより豊かにするだけですデプロイメントをスケールアップまたはスケールダウンする必要がある場合、数秒以内に EC2 インスタンスを自動的にプロビジョニングおよびプロビジョニング解除するのは簡単です。それがベアメタルサーバーと根本的に異なる点です AWS と比較した場合、必要な数よりも多くの専用サーバーをプロビジョニングするほうがコスト効率が高い可能性があることは否定しませんが、本当に予測不可能なワークロードがある場合、それを維持するのは簡単ではありません需要曲線を満たすために VM をスピンアップしたりシャットダウンしたりしている場合、アーキテクチャに重大な問題があります。 stackoverflow が世界全体にサービスを提供するために最大 8 台の専用サーバーを使用し、世界的な顧客の需要を満たすために VM をスピンアップおよびシャットダウンする必要がないのはなぜなのか、考えたことはありますか? -- コンピューティングインフラストラクチャを計画するときは、基本に立ち返り、クラウドベンダーのプロパガンダに騙されないことが重要ですあなた自身が言いました。すべてのアプリケーションが全世界にサービスを提供する必要があるわけではないため、人々が寝るときは需要が低下します。グローバルアプリケーションであっても、アプリケーションとデータを特定のリージョンでホストする必要がある規制があります。ヨーロッパ、オーストラリア、米国の顧客が使用するアプリケーションを想像してください。これらは地域のデータセンターからサービスを提供する必要があり、一方のクラスターは (タイムゾーンの関係で) 実行中、もう一方のクラスターはほとんどスリープ状態になります。専用サーバーを使用すると、リソースの 60 ～ 70% が無駄になりますが、EC2/Fargate などを使用すると、リージョンがスリープしているときにほぼ 0 までスケールダウンできます。この狂気を解決する方法があり、ここではそれを「雇用安全主導型開発」と呼んでいます。それは彼らの仕事を脅かすものだから自己ホストしたり、家族/友人/協会/ハイキングクラブのために小さなインスタンスをホストしたりする技術的な才能を持った人々が大勢います。このわずかなマージンは、きちんとしたものにしたいので多少の追加費用は問題ありませんが、多額の費用を払ってハードなメンテナンスに時間を費やすことは正当化できません。多くの場合、共有 Nextcloud または小規模 Web サイトを備えた小規模な VPS だけで十分ですこのために、私は寝室で小さな Raspberry Pi 400 も使用しています。 httpsjoeldare.com/private-analtyics-and-my-raspberry-pi-4.. 私は 10 年近く自分のコンテンツを自己ホストしてきました。私のセットアップに DDoS 攻撃を試みた人は誰もいません。彼らはそこからどんな利益を得られるでしょうか？影響を受けるのはほぼ私だけであり、一度止めてしまえば回復するのにそれほど時間はかからないでしょうインターネットランドではもちろんのこと、個人のボックスに対して DDoS を行うインセンティブはほとんどありません。あなたは十代の若者の能力を大幅に過大評価しています IP に何度も ping を送信するだけでは、あまり効果がありません。ターゲットネットワークの IPS の機能によっては、おそらく DoS 攻撃が考えられますが、それでも、実際に攻撃する機会を得る前に、コンピューターがウイルスに感染する可能性が高くなります。私は個人的に、GTA 5 で何らかの方法で詐欺師からそのような被害に遭ったことがあります。それは間違いなく起こりますが、楽しくありません編集: これは自動的に行われるようです。これは興味深いことなので、少し調べてみたいと思います。おそらく私の小さなサーバーにとっては余分に複雑なだけかもしれませんが、いくつかの用途を念頭に置いています技術的には、私のホームラボも同様に静的パブリック IP 上にあります。これは「実際に必要」というよりも「これができるかどうか」の練習でしたが、それでもクールで、とても満足しています唯一のハングアップは、トンネルを有効に保つように Wireguard を設定する必要があったことです。そうしないと、VPS が受信トラフィックを受信することがあり、ラボがしばらく連絡をとらなかった場合 (なぜそうなってしまうのでしょうか?)、トンネルがダウンしてしまいます。そして、プロキシ接続が行われます。ありがたいことに、それは組み込み機能ですつまり、jekyll または GitHub Pages サイトに 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 ram、1tb ドライブ、100mbit 現時点で数年の稼働時間中断されない場合: アップグレードが予定されている可能性があります。カーネルのセキュリティ更新は重要です Linux であっても、Atoms は耐えられないほど遅いことがわかりました。もちろん、ウェブサイトなどにサービスを提供するのには十分ですが、パフォーマンスが低下するだけでどれだけの電力が消費されるかは不可解です。その通り。これらの 10 ドル未満の VPS インスタンスは、長期契約を締結したくない、または独自のサーバーの管理に対処したくない小規模プロジェクトに最適です。実際に利益が非常に薄いビジネスを運営していて、サーバーの問題が発生した場合に対処するための自由時間が十分にある場合、これらの ~50 ドルの専用サーバーを検討してみると面白いかもしれません。しかし、実際にビジネスを経営しているのであれば、月額 10,000 ドルの AWS 請求でも、専用サーバーの管理を手伝ってもらうために別の熟練した開発者を雇うよりも安いでしょう。これは、HN のような場所でのクラウドのコストに関する議論で一般に見落とされているものです。はい、クラウドは高価ですが、カスタムインフラストラクチャの管理を支援するためにシステム管理者/開発者を 1 人追加で雇うだけでも、信じられないほど高価であり、柔軟性もはるかに低くなります。そのため、十分な時間を投資すれば、理論上は月額 50 ドルのサーバー上にカスタム構築できるクラウドホスト型ソリューションに仮に月額 5,000 ドルを費やしても、依然として非常にお得になる可能性があります。エンジニアの費用は高く、時間も限られているああ、すみませんが、この DevOps 担当者にはいくら払っていますか?バレーエリアも含めて、これは非常にアメリカ的な視点のように思えます。ヨーロッパでは男を雇ったほうが安いだろうフル装備の雇用コストは、手取りの給料よりもはるかに高くなります。実はヨーロッパではもっとひどいんです。これらのグラフをご覧ください: httpsaccace.com/the-true-cost-of-an-employee-in-europe/ 英国で誰かに 1,000 ユーロを支払うと、会社には合計 1,245 ユーロの費用がかかりますルーマニアで誰かに 1000 ユーロを支払うと、会社には合計 1747 ユーロの費用がかかりますつまり、120,000 ドルのフル装備コストでは、EU の Devops 担当者の給与は 68,000 ドルにしかならない可能性があります。ただし、devops 担当者を 1 人だけにすることはできません。そのうちの 1 人に休憩を取らせたり、休暇に出かけたりしたい場合は、少なくとも 2 人必要です 3時間くらいでお付き合いできます AWS は他のサービス (S3、SES、SQS など) に関してはコスト効率が非常に優れていますが、仮想マシンに関してはそれほど有利ではありません。 RAMが少なくなります& CPU には仮想化のオーバーヘッドがあり、より多くの費用がかかります特に Postgres の場合、pgbench でいくつかのテストを実行すると、仮想化に対して支払うペナルティが実際にわかります。おそらく、独自のインフラストラクチャを構築できるシステム管理者のスキルは失われつつある芸術になりつつあります。そうでない場合、なぜ人々がパフォーマンスの低下に対して 5 倍の料金を支払うことにそれほど夢中になるのか説明できません。 Hetzner はヨーロッパでは安価で信頼性が高く、北米にいる場合は OVH を検討してください。特に、SoYouStart と呼ばれるコスト削減の代替品がそうです。 4/8 4.5ghz、64 RAM、NVME ドライブを 65 ドルで入手できます (私は OVH とは何の関係もありません。私はほぼ 100 台のサーバーを所有する単なる顧客ですが、私にとってはうまくいきました) また、私は年寄りなので、最初の仕事の 1 つで、敷地内にそれなりの規模のデータセンターがあったことにも注意してください。 SAN やテープドライブ (当時はサーバーだった自動テープローテーターなど) を扱うのは非常に大きな PITA でした。テープを梱包して、場所の冗長性を確保するために別のオフィスに発送するのはいつも楽しかったです。私が管理している特定のアプリケーションは、GHz が低く、メモリ内にすべてのデータが存在しないという問題に非常に悩まされています。 EC2 でベンチマークを実行したところ、〜5 秒で終了する特定のレポートが、約 10 倍のコストがかかる同等の EC2 インスタンスでは 1 分以上かかる場合があります。このアプリケーションには実際に未加工の CPU が必要です。はい、私たちにはすべてのクエリ、インデックスなどを最適化したかなり大規模なエンジニアリングチームがあります。レプリケーションやバックアップなどに関しては、すべて私が設定しましたが、正直なところ、大したことではありませんでした。 Postgres 本の 2 つの短い章では、構成方法、継続的 (および自動) テストの方法などをすべて非常に簡単に説明しています。 SAN が悪夢であるという意見には私も同意します。そのため、私はすべての WAL (PG バックアップファイル) を S3 (そして最終的には Glacier) に送信します。そうすれば、ファイルを失うことを考える必要がなく、非常に安価ですこの種の構成は 1 人のエンジニアがセットアップするには複雑すぎて、終わりのないメンテナンスが必要であるという誤解があると思います。実際には、すべてのセットアップは 1 週間もかからずに行うことができ、実際にメンテナンスが必要になるのは、Postgres をアップグレードするときだけです (一部の設定は変更されている可能性があります)。年間メンテナンスに5時間くらいかかると思いますラストワンマイル配送の改善とファイバーアクセスの拡大が続くにつれて、セルフサービスインフラストラクチャはますます実現可能になると思われます。クラウドは自己共食いをするようになるでしょうか?たぶんねクラウドが得られるのは、ローカルの ISP と特別な取引をする必要がなく、データ/ワークロードをコアに配置できることです。少なくとも複数の 20 フィートのコンテナが満杯でない限り、おそらくはるかに高い復元力を備えています。サーバーの数コンピューティングニーズの規模 httpswww.cloudflare.com/products/tunnel/ httpsgithub.com/cloudflare/cloudflared httpsdevelopers.cloudflare.com/cloudflare-one/connections.. 編集: セルフホスティングに興味がある人は、cloudflared を使用すると簡単です。私は、Flask ベースの Web サイトを提供するカスタムファームウェアで Ubuntu を実行している 2017 Google Pixelbook を持っています。ゲスト Wi-Fi ネットワークに接続しているときにデスクで充電します。 Mobile PageSpeed スコアは 100/100 で、完全に読み込むまでに 0.8 秒かかります。 DO からは、信頼できる会社、拡張性、自動バックアップなどのメリットをすべて享受できます。変更する方法はありません。 Hetzner クラウドは現在、米国に 2 か所ありますが、米国には専用サーバーがまだありません。それらは本格的です。たとえ現在のクラウド製品自体がすでに主要なクラウド同等の価格の最大 30% であるとしても。あなたと同じように、私もレンタルした物理サーバーからサービスを実行しています。以前は Versaweb を使用していましたが、マシンが古すぎます。以前はヘッツナーが好きではありませんでした。なぜなら、ヘッツナーがあなたの実行に干渉するという悪い噂を聞いていたからです。しかし、12 月に私の Versaweb インスタンスが壊れたばかりで、おそらく SSD が古くなったので、そこに引っ越しました。現在、Versaweb に支払った金額の 50% を支払っており、このような Postgres インスタンスを 6 つ実行できますそうなると、派手なクラウド UI、自動アップグレードやバックアップなどを備えたマネージドサービスに 700 ドルや 800 ドルを支払う価値があるのかと疑問に思う人もいるでしょう。 1 人のショーや小規模なスタートアップの場合はそうではないと思います。利用可能なサービスを使用してバックアップを S3 またはその他の安価な場所にダンプする方が安価です私は以前 A 社で働いており、全く同じサービスに対して B 社が請求した金額の 4 倍の給料を喜んで支払っていました。それは、A 社が当社の請求システムとうまく連携した方法で四半期ごとに請求書を送ってくれたからです。企業にとって、あちこちで数百ドルを節約することは、余分な摩擦を引き起こす手間に値しないことがよくあります。そこには暗黙のコストが存在します。そのうちの 1 つまたは 2 つだけであれば、マネージドサービスを利用してください。規模を拡大し始める場合は、管理者タイプの従業員を雇ってコストを節約しましょうそうでなければ、ジャーナルに記録された PITR バックアップを常に迅速に復元できることを 100% 確実にするには、非常に経験豊富な人材を雇用/契約するか、1 か月以上の時間を費やす必要があります (その時間がありませんでした)。他の場所ではクラウドコストを大幅に節約できますが、信頼できるマネージド PostgreSQL を選択するのは非常に簡単でした (エントリーレベルの価格が予想より高かったとしても) 1 時間の実稼働データを失うわけにはいかない初期のスタートアップは、おそらく脆弱すぎて生き残ることはできません。これは初期のスタートアップです - サービスの中断よりも大規模な中断が発生するでしょうし、本番データの 1 時間の損失後に逃げる顧客は、とにかく製品を十分に評価していないだけです (私が考えていた特定のスタートアップでは、保持を強制した S3 への自動化された頻繁な DB オンラインダンプがすでにいくつか用意されていましたが、この特定のシナリオには十分ではないと思いました。しかし、次の方法で回復できるかどうかはわかりませんでした。 PITR/ジャーナリングは、ビジネスの成功に賭ける新たな単一障害点を追加することになります。そうでなければ、数百ドルを節約するために、数年以内に 9 桁を超える数字で撤退する可能性があります。) また、ニーズはそれほど厳しくないものの、顧客/ユーザーのデータに対する義務については無頓着な初期のスタートアップの一部は、依然として最低限の基本的な慣行を怠っているのではないかと思います。おそらく、直感的に理解する方法の 1 つは、HN で、いくつかのスタートアップ事業がボールを落とすというビジネスニュース記事を想像してみてください。スタートアップの創業者の名前が付けられています。そして、その記事には、彼らが適切なバックアップを持っていなかったことが判明したと書かれています。会社が大混乱に陥っているため、おそらくあまり寝ていないと思われる共同創業者は、「初期のスタートアップでは顧客データはそれほど重要ではありません。もしそうだとしたら、私たちは脆弱すぎるでしょう」と答えます（共同創業者がその人のラップトップを投げる前に入力）彼らの入力を止めるために部屋の向こう側に移動してください）。それは見栄えが良くないでしょうこれについては最後に説明します >HN で、一部のスタートアップ事業が失敗に終わったというビジネスニュース記事が、スタートアップの創業者の名前とともに掲載され、その記事には、彼らが適切なバックアップを持っていなかったことが判明したと書かれていると想像してください。 ITYM、最後の 1 時間をバックアップしていなかったことが判明私は、あなたのシナリオのすべてを、切り取られていない部分も含めて想像することができます。「1 か月間当社を利用してきたスタートアップのクライアントが、データの最後の 1 時間を失ったときにすぐに全員退職した」という記事を読まない限り、すべてが正常であるように思えます。そのシナリオは本当に想像できないもちろん、データの損失が 1 時間も発生しないという点で、これを使用するメリットがある企業もあります。なるほど、お客様はデータを失わないためにこれを使用しています: たとえば、オンラインドキュメントコラボレーション[1][2]。最後に入力されたデータが 1 時間失われるメルトダウンが発生した場合は、影響を受けたすべての現在のユーザーがすぐに逃げることを期待してください。 [1] ただし、個人的には、編集中に現在のドキュメントをローカルストレージに複製することでリスクを軽減したいと考えています。 [2] おそらく証券取引所にも、最後の 1 時間のデータを保持するシステムが必要なのではないでしょうか?ほかに何か？大規模なチームであっても、データベースを適切に管理する能力があるのであれば、データベースを自分で管理することは理にかなっていると思います。マネージドサービスには問題が発生する可能性が非常に多くありますが、ブロックストレージやオブジェクトストレージのように基盤となる実装が隠蔽されることはありません。ピーク時のパフォーマンスは確かに悪くなりますが、とにかく何かの実行に時間がかかっても、私はあまり気にしません。サーバーのプロビジョニングをできるだけ自動化するという点では確かに正しいですが、これは私が物理サーバーではしなかったことです。以前は自分のプロジェクト用にルートサーバーを使用していましたが、正直言って、それは意味がありません。私のマシンでは高トラフィック、大量の SaaS の計算を実行していません。それは単なる静的な Web サイトといくつかのプロジェクトです。すべてのデータを保存するための 1 TB のストレージボックスを含め、月額費用は 24 ドルに抑えられます実際のハードウェアが関係するシナリオにおける主な問題は、ハードウェアと Linux/UNIX システムの両方に精通したスタッフが必要であることです。多くの人は、履歴書に書いていると主張しても、一度も仕事に就くことができません（私の経験ではとにかく）。私の意見では、クラウドの世界が爆発的に拡大した主な理由の 1 つは、まさにそのようなチームを構築することの難しさと、構築にかかる経済的コストでした。さらに、アプリケーション開発者とシステム担当者の間には、ある程度自然な (そして必然的な) 摩擦が生じます。システム担当者は常に反発し、セキュリティの強化、プロセスの増加、導入の削減を主張する必要があります。開発チームは、柔軟性の向上、リリースの増加、プロセスの削減を常に主張する必要があります。優れた経営者は、この 2 つの中間の道を選択する必要があります。残念なことに、無能なマネージャーはシステム担当者を解雇し、物事を AWS の土地に移すことを決定することがよくあります。最後に、クラウドアーキテクチャは、クラウドプロバイダーによるオーバープロビジョニングが必要であり、抽象化の層が多いため、全体的により多くのコンピュータパワーを必要とするため、地球にとって悪影響を及ぼします。どのプロジェクトにもこの無駄はほとんどありませんが、グローバルクラウド全体は集合体として非常に無駄です。これは私を悩ませており、明らかに私の見解における感情的な偏見の要因である可能性があります（上記のすべてに対して非常に大量の塩が必要です）物理サーバーを収入前にレンタルする手段を開発すれば、それが理にかなっている場合には、標準減価償却を使用するか、または、179 条の買い切りおよび/または 179 条のリースを適用できるという主張も考えられます。たとえば、冗長性を確保するために、完全にオーバープロビジョニングされた 10 万ドルの物理 1U マシン 4 台からなる信じられないほど有能なグループを、異なるコロニー施設に導入できます。ここには、XYZ クラウドサービス、DNS、エニーキャストなど、必要なものを使用してロードバランシングとフェイルオーバーを行うためのあらゆる種類のトリックがあります。世界中でデータセンターを運営しているさまざまな施設を訪問し、ベンダーからハードウェアを出荷し、施設を見たりハードウェアに触れたりすることなく、Ansible や好きなものを使ってプロビジョニングすることができます。これで、ほとんどのクラウドプロバイダー (特に I/O) を完全に実行できる冗長物理ハードウェアと、全帯域幅 (クラウドサービスの 800% のマークアップがないなど) などの固定コストが手に入り、もう待つ必要はありません。避けられない 50,000 ドルのクラウド請求に備えて、または設定したクラウド予算を 1 か月ではなく 1 日で超過した原因を (パニックになって) 追跡しようとしています。ああ、ところで、$BIGCLOUD が提供する仮想マシン以外のサービスをプロビジョニングしたり利用したりするために、間抜けな独自の API に自分自身を閉じ込めているわけではありません。 ML を実行している場合は、独自のハードウェアまたは (または場合によってはクラウド) でトレーニングし、NVIDIA A10 などを使用して推論を年中無休で実行できます。 GPU インスタンスの継続的なクラウドレンタルは信じられないほど高価で、ハードウェア購入の ROI は通常、数か月の範囲です (または、第 179 条の適用によりほぼすぐに先になります)。例として、私は最近、Nvidia A10 を使用してサービスを提供しているモデルのベンチマークを実行しましたが、FP32 では 10 ミリ秒未満のレイテンシで 1 秒あたり 700 を超える推論リクエストを実行できます。 4 つの正常なインスタンスにわたるシャーシごとに 1 つの A10 を使用すると、2800 req/s になります (さらに調整できる可能性があります) そして、本当に大きくなったら、キャビネットなどを手に入れることができます。前述のハードウェア障害に関して、私が言えるのは、デュアル PS の RAID アウトなどのハードウェアは (私の経験では) 非常に信頼性が高いということだけです。過去にハードウェアのフルキャビネットを複数台使用していたので、ハードウェア障害はほとんどありませんでした。ベンダーには、交換用の信じられないほどの SLA が含まれます。障害について通知すると、技術者が派遣されます。< コロラド施設に直接8時間移動し、ライトが点滅しているディスク、PSなどを交換します。私の経験では、1 人の (優れた) FTE リソースが複数のキャビネット規模までこれを簡単に管理できます。あなたの指摘で言えば、現在の問題は、これらの人々の多くが大手クラウドプロバイダーにさらわれ、1ドルから数十（それ以上ではないにしても）の製品/サービスを使用するという、ばかばかしい境界線を乗り越えることができるリソースに（市場で）置き換えられているということです。ビッグクラウドまた、この構成は実際にはほとんどの $BIGCLOUD よりもはるかに信頼性が高いこともわかりました。 $BIGCLOUD の停止が彼らにさえ認められず (そしてあなたにはまったく制御できない)、何が起こっているのか疑問に思う必要はもうありません。通信とヘルスケアのバックグラウンドを持つ私にとって、クラウドプロバイダーの稼働率が実際にどれほど悪化しているかは全く理解できません。通常、顧客はおそらくそれについての見出しを見ているでしょうから、「ああ、今日インターネットに問題が発生しています」と伝えるだけで済みますが、多くのアプリケーションではそれはまったく受け入れられません。 [0] - httpswww.section179.org/section_179_deduction/ [1] = httpswww.section179.org/section_179_leases/ 新しいプロジェクトを立ち上げたり、何か新しいものをホストしてみたりしたい場合は、数分あればスクリプトが手に入ります。導入は迅速で、メンテナンスは低コストで、はるかに多くのお金が得られます。興味のある方のために、これは私が使用しているものの概略です: * Ansible ですべてを管理 * いつか置き換えられるかもしれないいくつかの DNS エントリ用の小さな Terraform * バックアップ用の Retic、やはり ansible によって制御されます * vpn 用のテールスケール (家でいくつかの pi を実行しています。テールスケール以外に大したことはありませんが、簡単かつ安全です) * その他ほとんどすべての docker-compose メインのアプリは Clojure なので、ネイティブ JVM を実行します。データベースは完全に分散されており、RethinkDB は現在 FoundationDB への移行に取り組んでいます。重要なことは、何も手動で管理しないことです。物理サーバーを他のクラウドサーバーと同様に扱います。物理的か仮想化かは関係ありません経験の少ない人が、5 ～ 10 ドルの vps で十分に機能するのに、hetzner などに過剰な料金を払っているのを見てきました。はい、その時点では独自のハードウェアをサポートしています。いいえ、それほど大きな頭痛ではありませんこれに対する最大の追加コストは、より多くの IPv4 アドレスをレンタルすることですが、利用可能なアドレスが非常に少ないため、Hetzner は現時点でかなりの金額を請求しています。作成するものはすべてユーザー 0 から始まり、実際のマシン全体では負荷が 0 になると完全に過剰になります。 VPS を 1 組の実マシンにアップグレードし、次に小規模なレンタルクラスターにアップグレードし、次にデータセンターにアップグレードします (誰かがそれを侵害しない場合)。これらはすべて、料金が予測可能で、価格に見合った最高のパフォーマンスを備えていますコロで所有しているものはすべて、月額料金も高くなります。静的 IP の料金を支払うことができる接続を持っていたとき、通常は月額 5 ドルでした私は今、かなりローエンドのサーバーを借りていますが、月額 30 ドルです。必要なものがすべて揃っていますが、それは素晴らしいことです。そして、サポートなどを改善するために価格を引き上げながら、私のOSのサポートを終了しませんでした。 (ただし、最初は交換が必要な不安定なハードウェアがいくつかありました) ご指摘のとおり、ベアメタルが最適です。クラウドとは逆に機能します。最初は少し手間がかかりますが、最後には費用が大幅に削減されます。詳細については httpseuropa.eu/youreurope/business/taxation/vat/cross-bor.. Postgres のセットアップと管理は面倒ですが。これをすべて正しく行うためのより簡単な方法があればいいのですが 1. VM がダウンするため、構成を強制的に再現可能にします 2. AWS では大幅な割引が受けられるため、負担が軽減されます 3. VM 上でアクセスできるその他の機能は、すでにクラウドにあるとより安価/高速になります。 4. 社内に特別なものがあるかどうかを従業員に訓練したり文書化するよりも、文書化されたシステム構成 (例: AWS ドキュメント) を持つ方が簡単です。特に新人の採用に役立ちます 5. 敷地内にスペースや冗長電源/インターネットなどは必要ありません。人々がラップトップを実行できるようにするのに十分なその前は VPS を使用していましたが、VPS を使用しなくなり、物理 VPS の方が有利であり、CPU 制限に遭遇することもなかったため、物理 VPS に切り替えました。ただし、ディスクの監視はそれほど難しくありません。ハードドライブの場合は、smartctl を 1 時間に 1 回実行し、再割り当てまたは保留中のセクターが急速に増加するか、100 に達するとアラートを出します。SSD の場合は、慎重に行ってください。数千人を対象とした私の経験では、バスから姿を消し、二度と見られなくなるまではうまく機能する傾向があります。稼働時間が非常に近い同じモデルのデバイスにデータを保存しないデータ復旧計画を立てる。稼働時間に関連するファームウェアエラーが実際に発生する結局のところ、Hetzner には専用サーバーを注文するための API と、OS をインストールするための API (または、必要なイメージをレスキューしてフラッシュするために再起動するための API) が用意されています。商用オプションを検討している場合は、おそらく商用 ISP ソリューション、静的 IP、優れた IT ハードウェアを備えた「トランク」をオフィスで整理することになると思いますが、現時点で私が知っている限りでは、クライアントがホスティングを必要とするかどうかはわかりません。」いつもすぐに vps をレンタルします当時私はどちらかというとジュニア開発者だったので、もしかしたら苦手だったのかもしれませんが、まったく懐かしくはありません。理論的にはあなたの言っていることに同意しますが、Dockerfile を Google Cloud Run などにデプロイするのは非常に簡単です。はい、自分で VPS を管理する場合よりも高い料金を払っていますが、これは開発時間の節約によって相殺される以上のものだと思います - 物理ハードウェアに問題がある。例:ファンの障害 ->VM が別のホストにライブマイグレーションされますが、気付かないか気にしません - 物理ハードウェアが爆発する ->VM が別のホストで再起動する、気づくかもしれないが気にしない VM を使用すると、災害計画がはるかに簡単になります (牛ではなくペットの場合でも) 初心者にとっては、安価なもので作業が完了しますクラウドコンピューティングが進化するにつれて、これらのサービスはより一般的になると確信していますクラウドコンピューティングには別の側面もあります。中規模から大企業は、コスト計算においてクラウドコンピューティングを 1 桁のパーセンテージとしてカウントします。これは、マネージャーやチームが行う決定は、多くの場合、「セットアップが高いか安いか」ではなく、(プレゼンテーションに反映される) 信頼性と拡張性を求めていることを意味します。私の雇用主は、宗教的なものではなく、ビジネス/財務上の遊びとしてクラウドを採用しました。多くの場合、新しいビルドをクラウドに配置し、後で必要に応じてデータセンターに移行します。オンプレミスのアプリのコストは約 40% 削減されます。クラウドでのコスト効率が高いアプリはそこに留まりますヨーロッパでは AWS/GCP/Azure はコスト競争力があまり高くないのが現状だと思います。私が見ていないのは、米国にとってその証拠だ同じスペックなら、確かに。仮想化は両端で意味があると思います。大きな N に対する動的なスケーラビリティが重要であるか、実際に必要なのは物理ボックスのほんの一部だけです。 find を月 5 で実行するものに月 45 を支払うのも賢明ではありません。また、サーバーを使用するためだけに物事をまとめないようにするための柔軟性が高まります。いずれの場合もバックアップを保管してください。できれば別のプロバイダー、または少なくとも物理的に異なる場所にあります。そしてもちろん、テストしてくださいまた、適切なバックアップ体制を管理し、とにかくデータ/アプリを監視している場合、ドライブの監視はさらに大きな困難を伴うのでしょうか? -- [1] 実際、別の場所への復元プロセスを自動化する場合 (私は少しの間やりました)、そのボタンを押すだけで完了したら DNS を更新し、おそらくもう少し多くの RAM + コアを割り当てることができます (私のテスト)ミラーは実際の使用パターンに対応する必要がないため、ライブ VM よりも小さいです) まさに私が自分自身とクライアントのために行っていることです。大量の摂取量を節約更新したかったとしても、最新バージョンを docker-compose テンプレートに取り込み、ansible Playbook を再実行するだけです。もちろん、アップグレードにそれ以上のことが必要な場合はそれでも構いませんが、作業という点では他のセットアップと何ら変わりません。おそらく手動で行う必要がある唯一のことは、バックアップをテストすることです。ただし、プロジェクトごとにそれを実行するスクリプトがあるので、SSH 接続してワンライナーを実行し、結果を確認するだけで完了です。おおよそ月に 1 回程度実行しますが、バックアップが失敗した場合にもメールが届きます。したがって、まったく時間がないということはあり得ません。半定期的に更新する場合、通常は月に 1 ～ 2 時間程度です。しかし、それはホストし管理するものが増えれば増えるほど拡大します言い換えれば、唯一の違いは、Ansible インベントリーファイルがどこから来たのかということです。 IP の静的リストであるか、Terraform から取得されたものです。 ECC RAM が必要な場合は、60/月になるようです。さらに、より強力な 8 コア CPU にもステップアップします。いずれにせよ、「完全な運用環境と二重のステージング / スタンバイ環境」について話しているのであれば (返信した人の言葉を引用すると)、月額 60 * (2 または 3) は、どのスタートアップの AWS と比較しても非常に安いです。私が見た請求書ユースケースはさまざまですが、AWS/GCP/Azure がすべての問題の解決策ではないことに同意する傾向がありますアプリケーションを 4 ドルの VPS に適合させることができる人にとって、それは明らかにベアメタルよりも安くなりますが、多くの場合、クラウドをスケールアップすると非常に高価になります。ベアメタルがすべての問題に対する答えであるわけではありませんが、業界の多くの人々は、ベアメタルが正しい答えになり得ることを理解していないようです。