今日、Yandex.Cloud はすべての人が利用できるようになりました 。 これで、すべてのユーザーがクラウドにアクセスして必要なリソースを展開し、Yandexテクノロジーにアクセスできるようになります。 たとえば、機械翻訳および音声認識と合成。
今日はYandex.Cloudを紹介し、内部での配置方法を説明します。 このカットでは、プラットフォームの歴史、チーム、アーキテクチャについて少し学びます。
ちょっとした歴史
Yandexクラウドプラットフォームがそれほど前に初めて公開されたという事実にもかかわらず、プロジェクトは長い間社内で開発されており、いくつかのフェーズを乗り切ることに成功しました。その基盤を形成した多くの技術は、Yandexの内部インフラストラクチャで時の試練に合格しました。 開発は昨年開始され、最初の外部ユーザーは2018年4月にプラットフォームのテストを開始しました。 さまざまな規模のWebサービス、SaaS開発者、企業など、約100社が参加する閉鎖的な体制でした。 9月に公開Webサイトを開きましたが、待機リストからのみクラウド自体にアクセスできました。12月には、誰でもアクセスできるようになりました。
製品開発計画が策定された当初、クラウドが持つべき特性と、それに基づいたテクノロジーについていくつかの戦略的決定を下す必要がありました：使用することが推奨されるオープンソースソリューション、内部Yandexテクノロジースタックから取得可能、およびパブリックプラットフォーム専用に開発する必要があるもの。 最も重要な問題の1つは、OpenStackに関連していました。
この時点で、数千のホストからなるOpenStack上のクラスターは、Yandexで数年間正常に動作していました。 可能なソリューションの1つは、このテクノロジーを使用してクラウドを作成することです。特に、プラットフォームの市場への参入を大幅に加速するためです。 しかし、多くの議論と白熱した議論の後、私たち自身の発展を支持して決定が下されました。 長所と短所が表明されましたが、次の議論が決定的になりました。
まず第一に、OpenStackはプライベートシングルテナントクラウド向けのソリューションです。 歴史的には、スケーラブルなマルチテナントプラットフォームを構築するように設計されていません。 2番目のポイント：このテクノロジーは、 ハイパーコンバージドアーキテクチャとの互換性が不十分です（すべてのハードウェアリソースが1つの大きなプールを形成し、仮想インフラストラクチャが既にその上に構築されている場合）。 3つ目-OpenStackのサポートと変更に関するすべての困難を経験し、クラスターの運用中に明らかになり、将来のユーザーのクライアントエクスペリエンスを危険にさらしたくありませんでした。 もちろん、私たちが出した質問に対する明確な答えはありませんでしたが、情報に基づいた決定を下す必要がありました。 選択が行われ、プラットフォームは独自の方法で進みました。
冒頭にも置かれた、付随するアーキテクチャ上のアプローチに注目する価値があります。 統合ハードウェアリソースの単一プールを使用することは、基本的な決定事項の1つです。 このアプローチにより、プラットフォームを簡単に拡張し、利用可能なリソースの量を簡単に増やすことができます。 さらに、プラットフォームはセルフホスティングの原則に基づいて構築されることを決定しました。 つまり、サービスサービスを含むすべてのクラウドサービスは、単一のハイパーコンバージドインフラストラクチャ上で「存続」する必要があります。 つまり、Yandex.Cloudには専用の管理サーバーがありません。 すべてのプラットフォームサービスは、外部ユーザーと同じ仮想マシンに展開されます。
セルフホスティングにより、クラウドの構造を非常に柔軟に管理し、1台のサーバーから数千台のマシンを備えたデータセンター全体まで、最小限のコストで追加のインフラストラクチャを自動的に接続できます。 さらに、ユーザーと同じ条件で作業しているため、カスタマーエクスペリエンス全体を体験できます。
そして、プラットフォームの基礎となる3番目の原則：すべてのサービスのメタデータとシステム情報の単一のリポジトリの存在。 このために、内部開発が使用されます。Yandexデータベース（YDB、ClickHouseと混同しないでください）を使用すると、非常に信頼性が高く、効率的で柔軟なデータを配置できます。 したがって、メタデータリポジトリは、他のすべてのYandex.Cloudサービスの基本的な内部サービスになりました。
プラットフォームの組織の基本原則は互いに密接に関連しており、アーキテクチャとその後の多くの技術的ソリューションを大きく決定していることに気づいたでしょう。 これにより、既存および将来のすべてのクラウドサービスの開発を長期的に計画できるスケーラブルなプラットフォームを作成する機会が与えられました。
建築
一般に、アーキテクチャは次のようになります。
クラウドのコアは、すでに述べた共有メタデータストレージ（ストレージレイヤー）です。 特別なレプリケーションメカニズムを使用するYDBは、クラウドで利用可能なすべてのハードウェアストレージをカバーします。 同様のメカニズムがネットワークブロックストレージ（NBS）に適用されます。 YDBと一緒に、クラウド内の他のすべてのサービスで使用される共通のデータストレージシステムを形成します。
Yandex Compute Cloudサービスは、ストアの上に構築されています。 これにより、外部ユーザーとプラットフォームの内部コンポーネントの両方で使用される仮想マシンを管理できます。 ハイパーバイザーはKVMで、エミュレーターはQEMUです。 その結果、デバイスの仮想化にVirtIOドライバーが選択されました。 仮想マシンとハードウェアインフラストラクチャのバンドルの重要な部分は、スケジューラです。 次の仮想マシンを展開する物理サーバーを決定するのは彼です。
これらのコンポーネントは、プラットフォームのIaaS部分であり、 Yandex Virtual Private Cloudサービスも含まれています 。 ネットワークサービスは、オープンソースのOpenContrailプロジェクトに基づいています。
この層のもう1つの重要なコンポーネントは、スナップショットメカニズムです。 それはあなたが写真やディスク画像を撮ることができます。
より高いレベルは、すべてのYandex.Cloudユーザーがアクセスできるプラットフォームサービスです。 これらはクラウド内のデータベースを管理するためのサービスであり、そのクラスターは仮想マシン（ClickHouse、MongoDBおよびPostgreSQLの管理対象データベース）にデプロイされます。 S3互換オブジェクトストレージ 翻訳 、 合成、音声認識サービスも同様です。
クラウドのすべてのレイヤーをカバーする他の2つの重要なサービスがあります。 これらは、 請求とIDおよびアクセス管理 （IAM）です。 1つ目は、消費されたリソースの関税と支払いに関するすべての業務を担当します。 2番目は、ロールベースのアクセス制御を実装します。リソースへのアクセス ：各ユーザーには、許可された操作を記述する1つまたは別のロールを割り当てることができます。 たとえば、編集者の役割では、リソースを作成、削除、編集できますが、リソースへのアクセスを制御することはできません。
これはYandex.Cloudデバイスのかなり一般的な説明ですが、大規模なプラットフォームのさまざまな部分が互いにどのように相互作用するかを理解することができます。 プラットフォームの構造をさらに深く掘り下げたい場合は、 クラウド会議の記録 について確認することをお勧めします。 このイベントで特に注目されたのは、ネットワークとYandexデータベースです。
チーム
最後に-チームについてのいくつかの言葉。 過去1年間で大幅に増加し、 成長を続けています 。 現在、すでに150人以上で構成されており、Yandex.Cloudに直接参加していないが、その成果がプラットフォームでも使用されている多数のグループはカウントされていません。 もちろん、専門家の大部分は開発者です。 それらは、仮想マシン、クラウドデータベース、課金、ネットワークなど、1つまたは別の領域に従事するユニットに分割されます。クラウドセキュリティとそれに格納されるすべての問題に特化した別のグループがあります。 さて、そしてもちろん、サポート、ユーザーによって提起された質問にすばやく答える準備ができています。
それだけです。 近い将来、当社のプラットフォームのさまざまなサービスを使用した作業の詳細に関するいくつかの記事を公開します。 それまでの間、Yandex.Cloudを無料でご利用いただけます。 新しいユーザーはそれぞれ4000ルーブルを受け取り、プラットフォームに精通します。 この量は、1テラバイトのオブジェクトファイルストレージを備えた標準のLAMPバンドルに基づいて、中規模のWebプロジェクトを1か月間クラウドに配置するのに十分です。 または、機械翻訳をモバイルアプリケーションまたはWebサイトに接続して、900万文字を超えるデータの配列を翻訳するため。