クラウド-それは何で、なぜですか？

最近、Windows Azureクラウドで実行されるABBYY Cloud OCR SDKサービスを開始し 、同時に100,500のエクスペリエンスを獲得しました。 たとえば、多くの人々が「クラウド」という言葉を使用し、「クラウドはファッショナブルである」と聞いたが、クラウドが何であるか、そして最も重要なのはなぜクラウドでサービスを行うのかを理解している人はほとんどいなかった 「クラウド」という言葉はどこでも使用されており、都市伝説に成長し始めているようです。



たとえば、次のビデオをご覧ください。







金髪がきれいに見え、心地よい声を持っているという事実だけに集中すれば、多くを失うことはありません。



パブリッククラウドとは何か、ソフトウェア作業にそれを使用するのが理にかなっている理由を詳細に検討してみましょう。「すぐにすべてがクラウドに移行する」というのは本当ですか。

あなたの顧客のための前例のない機会。

まず、クライアントにとって「クラウド内」サービスと「クラウド内ではない」サービスの違いは何ですか。



「クラウド」サービスには、すべてのユーザーにとってのアクセシビリティというユニークな特性があると考えられています。 雲はそれとは何の関係もありません。 私たちのサービスはクラウドで動作し、ユーザーにとっては通常のWebサイトのように見えます（一部のリクエストは通常​​のWebページを提供します）。たとえば、通常のWebページのように見えるユーザーアカウントを持っています。



比較のために、 Stack Exchange （ Stack Overflowサイトで最もよく知られている）またはYandex.Mailを見てください。ユーザーにとってはまったく同じに見えます。 また、すべてのユーザーがどこからでも利用できます。 また、HTTP経由でリクエストを受け入れるWebサーバーもあります。また、クライアントのオペレーティングシステム、マシンのアーキテクチャ、プログラムの記述言語を気にしません。



サービスの曇りにより、「どこからでもユーザーデータにアクセスできる」という主張を見つけることができます。 はい。サービスのユーザーは、どこからでもサービスに画像をアップロードして、どこからでも結果を取得できます。 ちなみに、Stack ExchangeまたはYandex.Mailのユーザーは、これらのサービスをどこからでも使用できます。質問をしたり、回答を受け取ったり、手紙を送受信したりできます。



機能的には、クラウドサービスはユーザーにとって違いはありません。 クラウドではなくクラウドにあるIPアドレスは、リクエストを受け入れて処理するサーバー（通常はWebサーバー）です。 IPアドレスの特定の範囲からサーバーへのアクセスを制限する設定がなく、クライアント自体が偏執的なファイアウォールに座っていない場合、サービスはどこからでもどのデバイスからでもアクセスできます。 ここでは曇りは効果がありません。

クラウドサービス向けのクラウドサービス

また、クラウド内のサービスは、クラウド内の他のサービスとやり取りできるように作られていると考えられています-プレスリリースの著者が最近書いたように、「クラウドサービスの開発者が使用する」シリーズの何か。 特に妄想的なプレゼンテーションでは、ペグが素朴なスケッチクラウドでつつかれた写真を見つけることができます-これはクラウドであり、その中にサービスがあり、そこで相互作用します。



サービスの観点から見てみましょう。 サービスを開発する目的は、世界中のどこからでもプログラムでアクセスできるサービスを提供することです。これにより、プログラム内のテキストを光学的に認識できないサードパーティ開発者は、認識にサービスを使用するソフトウェアを開発できます。 たとえば、小切手を撮影し、小切手からデータを抽出して、同じスマートフォン上の予算プログラムに保存するスマートフォン用のプログラム。 キャプテンエビデンスは、スマートフォンがクラウドにないことを示唆しています。 私たちのサービスは、「クラウドサービスの開発者」だけでなく、テキスト認識にサードパーティのサービスを使用する準備ができているプログラムの開発者向けです。 クラウドでは、これらのプログラムは機能するかどうかに関係なく、重要ではありません。サービスは気にしません。



クラウドサービスは、多数の外部リクエストを処理するサービスであると考えられています。 通常は必要ですが、必要ではありません。 サービスで素数の因数分解を開始し、ソースデータを外部のどこかに保存して、サービスがそこからそれらを取得し、結果を外部FTPサーバーにアップロードすることを誰も気にしません。

クラウドサービスのクラウドアーキテクチャ

さらに、クラウドで実行されるサービスは構造が根本的に異なると考えられており、その開発にはクラウドで機能しないサービスと比較して根本的に異なるアーキテクチャが必要です。 いくつかの違いがありますが、それらは二次的なものです。



ユーザーから画像を受け取り、処理にキューを入れて（認識に時間がかかるため）画像を処理し、処理後にユーザーに結果をダウンロードするためのリンクを提供するWebサービスを作成する必要があるとします。 どうしますか？ ほとんどの場合、受信した画像ごとに内部ストレージ（ほとんどの場合データベース）に「タスク」を作成し、一意の識別子を付け、別のストリームまたは別のプロセスで画像を認識し、次のリクエストで「そのようなタスクの具合はどうですか」結果へのリンクを返しました。 これは、このようなサービスの完全に明らかなアーキテクチャであり、曇りもそれとは関係ありません。



クラウドは「クラウドオペレーティングシステム」を使用すると考えられています。 通常、これは単に「通常のオペレーティングシステム」と呼ばれます。 Windows Azureでは、これはWindows Server 2008 R2で、ナットがわずかに締め付けられています（たとえば、一時フォルダーが非常に小さい）。 このような環境のすべての「クラウド」は、追加のサービス（たとえば、ユーザーサービスが実行されているマシンに関連付けられていない長期データストレージ）によって作成されます。



しばらく前に 、FineReader EngineがWindows Azureでの作業をサポートするようになったことを伝えました。 この改訂では、FRE全体を完全に書き換える必要はありませんでした。プラットフォームの制限を考慮し、それらを少し修正し、テストし、ドキュメントを更新し、サポートを継続することを約束しました。 骨の折れる重要な仕事ですが、それ以上のものはありません。

前例のない信頼性

また、小数点以下に9を多く提供するクラウドクラウドプロバイダーも存在するため、クラウドサービスの方が確かに信頼性が高いと考えられています。 個別に9つの信頼性があります。



まず、Ninesの契約（SLA-サービスレベル契約）の細字部分を読む必要があります。 これらの9が意味するもの、それらが影響するサービスの特定のプロパティ、プロバイダーの責任は正確に述べられています。



通常、プロバイダーの責任はあなたが支払った比較的小さなお金に過ぎず、サービスが機能していない間、あなたの会社はより多くのお金を失い、評判を損なう可能性があります。 はい、プロバイダーが答えますが、これはあなたが気分を良くしないかもしれません。



人生の同様の例：建物内で平均して年に1回、電源が1秒間オフになるため、コンピューターが再起動します。 電力会社の観点から見ると、これは年間で悲惨な秒です（何が9つありますか？）、そしてあなたの観点から見ると、これは各従業員の数分間の仕事の損失です。彼は何で立ち止まりましたか。 ナインはたくさんありますが、これはあなたにとってそれを簡単にするものではありません。



この契約は、特定のサービスの可用性を保証できます（たとえば、ソフトウェアが実行される仮想マシンが接続され、ネットワークに接続されること）-長期間にわたって障害が発生した場合、たとえば、これらの仮想マシンを管理するためのセカンダリ管理サービスが発生する場合があります-引き続き機能し、新しいものを起動したり、再構成したりすることはできません。 開始したばかりの非常に重要で寛大な広告キャンペーンのピーク負荷に対応するために、サービスのスループットを100倍に増やす必要がありました。 契約はこの二次的なサービスについて何も述べていないため、プロバイダーは契約に違反していません。



クラウドでのホスティングから、サービスの信頼性は多少なりとも保証されません。 誰もリスクをキャンセルせず、リスクだけが異なります。

それは何ですか？

obs蔽が小さくなったので、パブリッククラウドとは何かという質問に戻りましょう。 これは、計算能力と従量制のデータウェアハウスを提供するリモート制御サービスです。 容量を使用してソフトウェア（サービス）を操作し、ストレージ-このソフトウェア（サービス）が機能するデータを保存します。



提供されている施設をさまざまなレベルで制御できます。 たとえば、特定のOSを備えた仮想マシンを割り当てて割り当て、リモートアクセスを許可することにより、必要に応じて仮想マシンを構成し、引き続き自由に使用できます。 または（Windows Azureのように）サービスの実行可能コードと「これをそれぞれ2コアの5台のマシンで実行する」という構成ファイルを含む特別なアーカイブをダウンロードできます。クラウドサービスインフラストラクチャ自体が適切な仮想マシンを見つけ、展開、起動、それらにOSを設定し、そこにアーカイブを展開し、エントリポイント（タイプmain（）の固定機能）に制御を移し、何かが壊れているかどうかを監視します。その場合、同じものでサービスを再起動します（マシンがクラッシュした場合）別の車。 最初のケースでは、より多くのコントロールがあり、2番目のケースでは、より多くの追加の特典があります。

利益はいくらですか？

柔軟性と任務の委任の利益。 サービスを実行するマシンの数を増やす必要がありますか？ マウスを数回クリックするだけで、約10分待機します。すでに新しい仮想マシンが見つかったので、それらでサービスを起動しました。 拒否する必要がありますか？ 同じこと。



ストレージについても同じです。 リポジトリが必要です。マウスを数回クリックすると、リポジトリが提供され、アドレスとアクセスキーが提供されます。 ストレージは通常ゴム製で、支払いは実際の使用量によって異なります。



たとえば、プロバイダーは、データベースサーバーを提供することができます。これも「どこか」で、使用量に対する支払いも行います。 Windows Azureでは、これは、特別に構成され、SQL Server 2008と呼ばれるSQL Azureに基づいています。



新しい機能を試す必要がありますが、サービスを中断する危険性はありますか？ そうすることができます。 別のリポジトリと別のデータベースを作成します。 新しいストレージと新しいベースでサービスを構成し、追加で割り当てられた仮想マシンに展開します。 ストレージとデータベースに大量のデータがある場合、彼らは試して、マシンを解放しました。また、それらにお金を払わないように削除することもできます。



最後に、自動アセンブリは、このために特別に割り当てられた仮想マシン上のクラウドにサービスを直接展開し、そこでテストを実行します。 各アセンブリで、マシンは新たに割り当てられ、アセンブリ後に解放されます。そのため、週末や夜間、コードに変更がなければ、代金は支払われません。 コードは、動作する環境とまったく同じ環境でテストされます。



このような柔軟性は非常に便利です。 これはクラウドの明るい面であり、主に価値があります。 それは必要です-あなたはそれを借りる、それをしないでください-あなたはレンタルを停止し、両方とも数回のクリック（またはプログラムのリクエスト）を必要とし、それほど長く待たない。



どんな規模の会社にとっても便利です。 簿記を通じて各ハードウェアを購入する必要はありません。予備の機器を購入する必要はありません。管理のダウンタイムを大幅に削減し、柔軟性を高めることができます。



さらに、責任の一部をプロバイダーに移します。 サーバーを購入したり、ラックを組み立てたり、電気接続をしたり、機器を置く場所を必要とせず、OSを構成することもできません（クラウドに依存します）。 以下で、これについては責任の移動について説明していますが、責任については説明していません。

いつものように、ダークサイドがあります

クラウドの暗い面は、多くのものが影響を受けないことです。 Stack Exchangeチームのブログを信じているなら、彼らのサービスはクラウドではなく、クラウドプロバイダーが提供する制御レベルに満足していないため、自社の機器で動作します。



たとえば、仮想マシンは標準であり、実際のハードウェアの特性さえ知らない場合があります。 ほとんどの場合、Windows Azureで1つのシングルコアノードにサービスを展開すると、実際にはHyperVの16コアサーバーで実行される仮想マシンが提供されます。 何かを微調整して生産性を15％向上させることもできますが、それについては何もできません。



法律または契約の厳格な要件に偏執的または拘束されている場合、一般的にアイロンをほとんど制御できないことに満足できない場合があります。 たとえば、そこに企業秘密を含むドキュメントをアップロードした場合、それらは大量のハードドライブにコピーされますが、それらの削除の保証には影響しません。 はい、プロバイダーが約束しますが、これを確認することはできません。



信頼性についても同じことが言えます。 たとえば、ある時点でラックが空調システムの引き裂かれたチューブからの凝縮液であふれないことを確認することはできません。 サーバーがオフィスまたはコロケーションにある場合は、おかしく見えても、機器の上のスペースから水を排出するなど、何かをすることができます。 ここでは何もできません。機器がどこにあるか、そこにしっかりと固定されているかどうか、マウスがそれを迂回するかどうかを制御することはできません。 あなたが予見できる（または、うまく行われていない仕事を予見して後悔を感じない）すべてのクレイジーなイベントは、現在完全にあなたのコントロールの外にあります。



クレイジーなイベントは非常に異なります。 データセンターでの実際の障害の例を次に示します。



失敗 。 車はデータセンター近くの電力線サポートに衝突し、高電圧線が破損してデータセンターに給電する変電所の前の地面に落ちました。 バックアップ電源への移行が開始されました。 地面にあるワイヤから電流が地面に流れ、データセンターでは、保護回路が地面への電流の漏れに反応し、データセンター全体をオフにしました。



別のFAIL 。 おそらく、落雷のために、データセンターに供給する変圧器が故障し、バックアップ電源への移行が始まったと思われます。 何らかの理由で、発電機を同期できず（おそらく、同期を実行する機器に電源が供給されていなかった）、データセンターはバックアップ電源に切り替えられず、すべての機器がオフになりました。



これらのケースは数百および数千のクラウドユーザーに影響を与えているため、これらのケースを認識していることに注意してください。 オフィスに設置されたサーバーで同様のイベントがいくつ発生するかはわかりません。



もちろん、オフィス内のサーバーでも同様のことが起こりますが、この場合、あなたの過失の一部があります-彼らは予見ではなく、提供できたかもしれません。 あなたは悪い仕事を恥ずかしく思うでしょう。 機器が「どこか」にある場合、そのような機会はなく、プロバイダーを信じざるを得ません。



これは悪くありません。これを明確に理解する必要があります。 クラウドでサービスをホストすることで、サービスの実行可能性に対する責任ではなく、責任の大部分をプロバイダーに移します。 クラウドは自動的に信頼性が向上することを意味せず、自動的に信頼性が低下することを意味しません。 重要なサービスについては、さまざまなデータセンターでの複製と負荷の再分散が必要になるため、リスク評価が必要です。 データセンター間でのデータの複製と同期のすべてのコストを考慮すると、値札が気分を害する可能性が非常に高くなります。

クラウドサービスのクラウドアーキテクチャ

最後に-クラウドサービスの特別な要件について。 そのような要件があります-何かがいつでも壊れる可能性があることを準備する必要があります。 極端なものが好きなら、Netflixのように、ランダムな瞬間にサービスの何かを壊すサービスを作成できます 。 特に、一時的な短期的な障害に備える必要があります。 たとえば、SQL Azureとの接続が一時的に消失する場合があります。コードがパニックになったり壊れたりすることはありませんが、少し待ってから再試行してください。



通常、プログラムでユーザーを悩ますことを覚えておいてください-分散システムでのすべての種類の「サーバーを見つけることができませんでした。ここでチェックする価値がある18ポイント」は絶対に正常です。 「サーバーの応答なし」というブラウザメッセージの後のユーザーは通常F5を押します。サービスはアクションを繰り返すだけです。 このため、アクションを繰り返し実行しても害がないことが重要です。これはスマートワードのべき等性と呼ばれます。 この機能を考慮に入れない場合、サービスはナンセンスのために最も不適当な瞬間に失敗します。



同様に、サービスは、すべてのノードまたはいくつかのノードでいつでも停止できるという事実に備えて準備し、その後、データを損傷せずに再開する必要があります。サービスを再起動した後、最新のデータの損失は最小限に抑える必要があります何も起こらなかったかのように作業を続けることができます。 これは、たとえば、Windows Azureにソフトウェア更新プログラムを自動的にインストールするときに発生します。ノードが順番に停止し、更新済みのソフトウェアがインストールされたノードでサービスが開始されます。



要件はかなり大きくなりますが、実行可能です。マーフィーだけがサービスに来ることがよくあります。 小さなFAILが壮大な失敗になるかどうかはあなた次第です。



クラウドは、「スケーラブル」、「アクセシビリティ」、「移行」、「生産性」、「トレンド」という単語の集まりではなく、マーケティングテキストでランダムな順序で使用されます。 これは、コンピューティングパワーの所有権の単なるモデルです。 場合によっては、このモデルは非常に便利です。



ところで、クラウドで作業する開発者向けのサービスがあります 。



ドミトリー・メッシェリャコフ、

開発者製品部門