広告熱意の流れに数時間苦労した後、「クラウド」の基礎となるテクノロジーに対処しようとする技術者は誰でも、これらのクラウドが同じVDSであることに気付くでしょう。 彼は正しいでしょう。 現在作成されているクラウドは、通常の仮想マシンです。
ただし、クラウドはマーケティングであり、VDSに名前が変更されただけではありません。 「クラウド」という言葉（正確には「クラウドコンピューティング」というフレーズ）には、独自の技術的な真実があります。 マーケティング担当者が言うほど哀れで革新的なものではありませんが、存在します。 数十年前に発明されましたが、インフラストラクチャ（主にインターネットおよびx86仮想化技術）が大規模に実装できるレベルにまで成長したのは今だけです。
そのため、最初に、一般的にクラウドの必要性を生み出した理由について：
通常のVDSで提供されるサービスは次のようになります（プロセッサ、メモリ、ディスクの任意のリソースをこのグラフの代わりに使用できます）。
注：これは毎週のスケジュールです。 リソース消費制限（バースト、猶予期間）を一時的に増加させる既存の技術では、このような長い間隔でこの問題を解決することはできません。 つまり マシンには、最も必要なときにリソースが不足しています。
2番目の問題-リソースが実際に支払われなければならなかったが、使用できなかった大きな間隔（青色）を見てください。 夜間の仮想マシンは、それほど多くのリソースを必要としません。 彼女はアイドルです。 そして、それにもかかわらず、所有者は全額を支払います。
問題が発生します。問題なくピークを生き延びるために、人は平均で必要以上のリソースを注文せざるを得ません。 それ以外の時間は、リソースはアイドル状態です。 プロバイダーは、サーバーがロードされていないことを認識し、現在よりも多くのリソースを販売し始めます（これは「オーバーセル」と呼ばれます）。 ある時点で、たとえば、複数の顧客のピーク負荷のために、プロバイダーはその義務に違反します。 彼は各1 GHzの70人を約束しましたが、40（2.5 * 16コア）しかありません。 良くない
ストリップを正直に（オーバーセルなしで）販売することは、不採算です（そして、非市場価格が得られます）。 オーバーライド-サービス品質を低下させ、契約条件に違反します。
この問題はVDSや仮想化に関連するものではなく、一般的な問題です。つまり、アイドルリソースを正直に販売するにはどうすればよいのでしょうか。
この問題に対する答えは、「クラウドコンピューティング」というアイデアでした。 言葉は、ファッショナブルではありますが、マシンタイムが売られていた大きなメインフレームの時代に遡ります。
クラウドコンピューティングは同じことを行います-実際の消費に関係なく支払われる制限とクォータの代わりに、ユーザーは制限なしにリソースを使用する機会が与えられ、実際の消費に対する支払いが行われます（実際に使用されたもののみ） これが「クラウド」の本質です。
「3 GBディスクの500 MHz 500 MBメモリ」を販売する代わりに、ユーザー（または彼の仮想マシン）に必要なものがすべて与えられます。 必要なだけ。
3月8日までにリソース消費がピークに達し、その後、デッドシーズンが発生しますか？ または、これらのピークがいつ発生するかを予測することはできませんか？ 遅れとお金の無駄遣いの間の妥協点を探す代わりに、異なる支払いモデルが提案されます：消費されたものは支払われます。
リソース会計
マシン時間も考慮されます（ティック単位でカウントできますが、古いスタイルで実行するのが理想的です：マシン時間の秒数をカウントします）。もちろん、3つのコアが50％の負荷で脱穀された場合、これは毎秒1.5秒のマシン時間です。 3％の負荷がある場合、1分間で2秒のマシン時間しか消費しません。
メモリは「オンデマンド」で割り当てられます-そして、ホストとあなたの欲の能力によってのみ制限されます。 また、時間ベースで支払われます-1メガバイトのメモリコストが毎秒非常に高くなります。 （実際、古いVDSでは「1か月あたりのメガバイト数」を支払いましたが、ほとんどの場合アイドル状態でした）。
ディスク領域もオンデマンドで割り当てられます-メガバイト/秒ごとの支払い。 一時的なテラバイトダンプの場所が必要な場合、1か月間テラバイトを支払う必要はありません-1時間半で十分です（主なことは、後で余分なものを消去することを忘れないことです）。
ディスク容量
ディスク領域は複雑なリソースです。「ストレージ」だけでなく「アクセス」でもあります。 消費は、消費された場所（メガバイト秒）、iops（ピース）、および記録された読み取りの量の両方に対して行われます。 各コンポーネントには費用がかかります。 1つのリソースに対してお金が3回使用されるため、実際には価格は3つに分割されます。
そして、ここからが始まりです。ファイルを置いたが、触れていない人は、積極的に使用してクライアントに還元する人よりも低額です。 また、使用方法が異なる場合があります-メガバイトで10回読み取り、「キロバイトで10回読み取り」-違いがあります。逆に、メガバイトあたり10リクエストで10MBファイルを読み取ります。また、記録と混同...
従量課金モデルは、消費者とサービスプロバイダーの両方にとって最も誠実です。消費者は消費した分だけ支払いますが、サプライヤーはすべてのリソースを消費している「脂肪」の顧客からの刺激を受けなくなります。 消費リソース-販売リソース。 さらに、逆の原則も適用されます。未使用のリソースは支払われません。 ホスティング事業者が「オンデマンド」でプロセッサを全員に提供することができなかった場合（輻輳が発生した場合）、購入したいものよりも売れなかったため、試行錯誤や長い通信なしで自動的にお金を失います。 クライアントは、混雑のためにトラブルを感じますが、少なくとも満足を得るでしょう、彼らはこの時間をより少なく支払うでしょう...この混雑の問題は、さらに美しく、曇った解決策を持っていますが、次回はそれについてです。
RAM
たとえば、メモリ使用量のグラフ。 注意してください-オレンジ色の領域は、「減速」するだけでなく、oom_killerが機能する領域です。 すべての結果で。 支払いが消費である場合、これらのピークはそれほど高価ではありませんが、問題なく「ピーク」状況を解決します。
そして、もう一度見てください。私は絶対に支払いたくない巨大なアイドルリソースです。 結局のところ、このメモリは使用されていませんか？ いや では、なぜそれを支払うのですか？
クラウドを使用すると、必要なときにメモリを使用できます。 また、メモリが不要になったときに返してください。 また、他のリソース（メモリ/ディスクのパフォーマンス）とは異なり、メモリが不足すると速度が低下しますが、メモリは重要なリソースです。 彼らは記憶を与えませんでした-接続が閉じられたため、誰かがnginx'a「悪いゲートウェイ」から幸福のページを見たか、単に何も見ませんでした...
ネットワーク
ところで、この原則はネットワークに適用されます。 私たちは皆、アリムで家に帰るのに慣れています（固定最大速度で無制限にアクセスできます）。 しかし、仕事は家ではありません。 そして、30 MBの狭い帯域にお金を払うのは残念です。100MBは高価です（最初のチャートを参照）。 そして、おそらく500MB未満にさらに単一のピークがありますが、めったにありませんか？ この状況になるには？ 安いトラフィックは、1か月あたりの実際のトラフィック量が同じで、狭い万力に挟まれたバンド（anlim）よりも安く、より良いサービス品質を提供します。 ほとんどの人は、「有料のトラフィックは高価です」という事実に慣れています（opsosのおかげです）。 そうでない場合は？ ギガバイトのトラフィックが80セントかかる場合はどうでしょうか？ （3桁安い？）
仮想マシンが100ルーブル未満しか食べない場合、トラフィックに何百（何千）ルーブルを支払うのはなぜですか？
ところで、ローカルネットワークにも同じことが当てはまります。 はい、ギガバイトのトラフィックには1ペンスかかります。 しかし、彼は？ そのため、高速スイッチがインストールされているため、リソースを消費します...したがって、支払いが必要です。
偽の雲
「通常のVDS」では、ユーザーがリソース消費の制限を設定できる場合があります。 たとえば、500MHzが足りず、600を入れて、ここに滑らかなスライダーがあり、自分で制限を設定します。 ただし、これは問題の解決策ではありません。 ええ、はい、500の代わりに600をベットします。 同じVDSで、ダウンタイムの同じ（または大きな）ダウンタイムの領域がありますが、私たちはそれを受け取りません。 クライアントにサービスを提供するサーバーに必要なリソースの数（予測できない数）を正確に知ることはできません。 したがって、「消費時」の支払いはより公平です。
これを類推することができます：キャブレターを持っている車があります。 そして、吸引ハンドル。 燃料供給を調整する必要があります。 いっぱい？ いっぱいですか？ ひどく乗ります。 また、噴射エンジンを搭載した車には、必要なだけのガスを消費するものがあります。
これは、クラウドとペダル駆動のVDSの違いです。 あなたはそれほど多くのガソリンを必要としません-彼らは（あなたの費用で！）エンジンに注ぎます。 あなたは上り坂をcっています、あなたは追加する必要があります-与えないでください。 より正確には、彼らは与えますが、手で、手で...類推から見上げます：車では、少なくとも、あなたは運転しています。 また、VDSでは、リソースの消費を24時間監視していますか？
エンタープライズとホスティング
書かれたものはすべてホスティング業者に関係しているように見えるかもしれません。 そうではありません。 ホストの位置とエンタープライズサーバーの彼自身のフリートの管理者の違いは、プロバイダーがお金で運営し、管理者が利用可能なリソースで運営することです。 リソースの共有使用に関するすべての考慮事項は、「プライベート」クラウド内のサーバーに適用されます。 スクエアネスト方式を使用してメモリをバックアップする代わりに、共有プールを使用すると、仮想マシンの密度がはるかに高くなり、「ああ、SQLが落ちました。メモリ制限を誤って設定しました」という問題を解決します。
完璧なクラウド
理想的なクラウドに必要なリソースを書き出そうと思います。
- 要求に応じてCPUリソース。 おそらく、現在のサーバーのリソースが不十分になり始めた場合、追加のコアの動的な接続により、より空き/高速なサーバーへの仮想マシンの自動移行が行われます。 ティックのプロセッサ時間の支払い（またはビジー状態のプロセッサの秒）。
- 消費リリース時に支払われる無制限のメモリ（キロバイト秒または複数の単位で計算）。
- 同じ原則に従って考慮されるディスク容量：ギガバイト時の支払い。 テラバイトのアーカイブを2時間置きました-2000ギガバイト時間を支払いました。 （主なことは、消去しすぎることを忘れないことです）1日に2GBを入れます-有料の48ギガバイト時間。
- ディスク操作-個別、ディスクトラフィック-ギガバイト単位
- ネットワークは無制限で、速度はギガビット単位であり、上位10位です。 トラフィックの支払い。
- 仮想マシンをオフにし、ディスクの「デッドウェイト」コンテンツに対してのみ支払う完全な法的権利
- 仮想マシンをエクスポート/インポートする機能
- 1つのアカウントに複数の仮想マシンを持つ機能
- リアルタイムまたは近い時間でのリソース消費のチャート