AWS が柔軟なサービスをどのように調理するか。 サーバーとデータベースのスケーリング

クラウドは魔法の箱のようなものです。何が必要かを尋ねると、リソースがどこからともなく現れます。 仮想マシン、データベース、ネットワーク - これらはすべてあなただけのものです。 他にもクラウドのテナントはいますが、あなたの宇宙ではあなたが唯一の支配者です。 必要なリソースを常に受け​​取ることができ、誰にも考慮される必要がなく、ネットワークがどうなるかを独自に決定できます。 クラウドにリソースを柔軟に割り当て、テナントを相互に完全に分離するこの魔法はどのように機能するのでしょうか?

AWS クラウドは、2006 年から進化を続ける超超複雑システムです。 この開発の一部が行われました ヴァシリー・パンチューキン - アマゾン ウェブ サービス アーキテクト。 アーキテクトとして、彼は最終結果だけでなく、AWS が克服する課題についても内部を観察しています。 システムの仕組みを理解すればするほど、信頼も高まります。 したがって、Vasily は AWS クラウド サービスの秘密を共有します。 以下に、物理 AWS サーバーの設計、柔軟なデータベースのスケーラビリティ、カスタム Amazon データベース、および仮想マシンのパフォーマンスを向上させながら同時に価格を下げる方法を示します。 Amazon のアーキテクチャ的アプローチの知識は、AWS のサービスをより効果的に使用するのに役立ち、独自のソリューションを構築するための新しいアイデアを得ることができるかもしれません。

講演者について: ヴァシリー・パンチューキン (めんどり) は、.ru 企業の Unix 管理者としてスタートし、6 年間大規模な Sun Microsystem ハードウェアに取り組み、11 年間 EMC でデータ中心の世界を説きました。 それは自然にプライベート クラウドに進化し、2017 年にパブリック クラウドに移行しました。 現在、彼は AWS クラウドでの生活と開発を支援するための技術的なアドバイスを提供しています。

免責事項: 以下の内容はすべて Vasily の個人的な意見であり、アマゾン ウェブ サービスの立場と一致しない可能性があります。 ビデオ録画 記事の基になっているレポートは、YouTube チャンネルでご覧いただけます。

なぜ私が Amazon デバイスについて話しているのでしょうか?

私の最初の車はマニュアルトランスミッションでした。 車を運転して完全にコントロールできるという感覚があり、とてもよかったです。 また、その動作原理を少なくとも大まかに理解できたことも良かったです。 当然、箱の構造は自転車の変速機のような非常に原始的なものを想像していました。

交通渋滞に巻き込まれたことを除いて、すべてが素晴らしかったです。 座って何もしていないように見えますが、ギアを変えたり、クラッチ、アクセル、ブレーキを踏み続けていると、本当に疲れてしまいます。 家族がオートマチック車を購入したことで、交通渋滞の問題は部分的に解決されました。 運転中、何かを考えたり、オーディオブックを聞いたりする時間がありました。

自分の車がどのように機能するのか完全に理解できなくなったため、私の人生に別の謎が生じました。 現代の自動車は複雑な装置です。 車は、アクセルの踏み方、ブレーキ、運転スタイル、道路の質など、数十の異なるパラメーターに同時に適応します。 もう仕組みがわかりません。

Amazon クラウドに取り組み始めたとき、私にとってもそれは謎でした。 車に乗っているドライバーは XNUMX 人ですが、AWS には何百万人ものドライバーがいるため、この謎だけが桁違いに大きくなります。 すべてのユーザーが同時にハンドルを切り、アクセルを踏み、ブレーキを踏みます。 彼らが行きたいところに行くのは素晴らしいことです。私にとっては奇跡です。 このシステムは各ユーザーに自動的に適応し、拡張し、柔軟に調整するため、ユーザーはこの宇宙で一人であるかのように感じられます。

その後アマゾンで建築家として働くようになってから、その魔法は少し解けました。 私たちがどのような問題に直面し、どのように解決し、どのようにサービスを開発しているのかを見てきました。 システムがどのように機能するかについての理解が深まるにつれて、サービスに対する信頼が高まります。 そこで、AWS クラウドの内部にあるものの全体像を共有したいと思います。

何について話しましょうか

私は多様なアプローチを選択しました - 話す価値のある興味深いサービスを 4 つ選びました。

サーバーの最適化。 物理的に具現化された一時的なクラウド。ブーンと音を立て、熱くなり、ライトで点滅する物理サーバーが存在する物理データセンター。

サーバーレス機能 (Lambda) はおそらくクラウド内で最もスケーラブルなサービスです。

データベースのスケーリング。 独自のスケーラブルなデータベースを構築する方法について説明します。

ネットワークのスケーリング。 最後の部分では、ネットワークのデバイスを開きます。 これは素晴らしいことです。すべてのクラウド ユーザーは、自分がクラウド内に一人でいて、他のテナントがまったく見えないと信じています。

注記。 この記事では、サーバーの最適化とデータベースのスケーリングについて説明します。 次の記事ではネットワークのスケーリングについて検討します。 サーバーレス機能はどこにありますか? 彼らについては別の記録が公開されました。」小さいけど賢い。 Firecracker のマイクロ仮想化を開梱する」 いくつかの異なるスケーリング方法について説明し、仮想マシンとコンテナーの最高の品質の共生である Firecracker ソリューションについて詳しく説明します。

サーバー

雲は儚いものです。 しかし、この一時性には依然として物理的な具体化、つまりサーバーが存在します。 当初、彼らの建築は古典的でした。 標準の x86 チップセット、ネットワーク カード、Linux、仮想マシンが起動された Xen ハイパーバイザー。

2012 年、このアーキテクチャはそのタスクに非常にうまく対処しました。 Xen は優れたハイパーバイザーですが、大きな欠点が XNUMX つあります。 彼はもう十分だよ デバイスエミュレーションのオーバーヘッドが高い。 新しい、より高速なネットワーク カードまたは SSD ドライブが利用可能になると、このオーバーヘッドが大きくなりすぎます。 この問題にどう対処すればよいでしょうか? 私たちは XNUMX つの分野に同時に取り組むことにしました - ハードウェアとハ​​イパーバイザーの両方を最適化する。 その任務は非常に深刻です。

ハードウェアとハ​​イパーバイザーの最適化

一度にすべてをやってもうまくいきません。 「良い」とは何かということも当初は明確ではありませんでした。

私たちは進化的なアプローチをとることにしました。アーキテクチャの重要な要素を XNUMX つ変更して、それを本番環境に投入しました。

私たちはすべての熊手を踏み、苦情や提案に耳を傾けます。 次に、別のコンポーネントを変更します。 そのため、ユーザーやサポートからのフィードバックに基づいて、アーキテクチャ全体を少しずつ根本的に変更します。

変革は 2013 年に最も複雑なものであるネットワークから始まりました。 で S3 インスタンスでは、特別なネットワーク アクセラレータ カードが標準のネットワーク カードに追加されました。 文字通り、フロントパネルの短いループバックケーブルで接続されました。 あまりきれいではありませんが、雲に隠れて見えません。 しかし、ハードウェアとの直接対話により、ジッターとネットワーク スループットが根本的に改善されました。

次に、ブロック データ ストレージ EBS (Elastic Block Storage) へのアクセスを改善することにしました。 ネットワークとストレージを組み合わせたものです。 問題は、ネットワーク アクセラレータ カードは市場に存在していましたが、ストレージ アクセラレータ ハードウェアを単純に購入するという選択肢がなかったことです。 そこで私たちはスタートアップに目を向けました アンナプルナラボ、私たちのために特別な ASIC チップを開発してくれました。 これらにより、リモート EBS ボリュームを NVMe デバイスとしてマウントできるようになりました。

事例では C4 私たちは XNUMX つの問題を解決しました。 XNUMX つ目は、有望ではあるが当時は新しい NVMe テクノロジーの将来のための基盤を実装したことです。 次に、EBS へのリクエストの処理を新しいカードに移すことで、中央プロセッサの負荷を大幅に軽減しました。 それがうまくいったため、現在、Annapurna Labs は Amazon の一部となっています。

2017 年 XNUMX 月までに、私たちはハイパーバイザー自体を変更する時期が来たことに気づきました。

新しいハイパーバイザーは、変更された KVM カーネル モジュールに基づいて開発されました。

これにより、デバイス エミュレーションのオーバーヘッドを根本的に削減し、新しい ASIC と直接連携できるようになりました。 インスタンス S5 これらは、内部で実行される新しいハイパーバイザーを備えた最初の仮想マシンでした。 私たちは彼に名前を付けました Nitro.

タイムライン上のインスタンスの進化。

2017 年 XNUMX 月以降に登場した新しいタイプの仮想マシンはすべて、このハイパーバイザー上で実行されます。 ベアメタルインスタンスにはハイパーバイザーがありません, しかし、特殊なニトロカードを使用するため、ニトロとも呼ばれます。

その後 1 年間で、Nitro インスタンスの種類の数は、A5、C5、M3、TXNUMX など、数十を超えました。

インスタンスの種類。

最新のニトロマシンの仕組み

これらには、Nitro ハイパーバイザー (前述)、セキュリティ チップ、Nitro カードという XNUMX つの主要コンポーネントがあります。

セキュリティチップ マザーボードに直接統合されています。 ホスト OS のロードの制御など、多くの重要な機能を制御します。

ニトロカード - XNUMX種類あります。 これらはすべて Annapurna Labs によって開発され、一般的な ASIC に基づいています。 ファームウェアの一部も共通です。

ニトロカードはXNUMX種類。

カードの XNUMX つは、 通信網VPC。 これは、仮想マシンでネットワーク カードとして表示されるものです。 ENA - エラスティック ネットワーク アダプター。 また、物理ネットワーク経由でトラフィックを送信するときにトラフィックをカプセル化し (これについては記事の後半で説明します)、セキュリティ グループ ファイアウォールを制御し、ルーティングやその他のネットワークの処理を担当します。

一部のカードはブロック ストレージで動作します EBS サーバーに組み込まれているディスク。 ゲスト仮想マシンには次のように表示されます。 NVMeアダプター。 また、データの暗号化とディスクの監視も担当します。

Nitro カード、ハイパーバイザー、セキュリティ チップのシステムが SDN ネットワークに統合されているか、 ソフトウェア定義ネットワーク。 このネットワークの管理を担当します (コントロール プレーン) コントローラカード.

もちろん、私たちは新しい ASIC の開発を続けます。 たとえば、2018 年末に、機械学習タスクをより効率的に処理できる Inferentia チップをリリースしました。

Inferentia 機械学習プロセッサ チップ。

スケーラブルなデータベース

従来のデータベースは階層構造になっています。 大幅に単純化するために、次のレベルが区別されます。

• SQL — クライアントとリクエスト ディスパッチャーがそれに取り組みます。
• 規定 トランザクション - ここでは、ACID などすべてが明確です。
• キャッシング、バッファプールによって提供されます。
• ロギング — REDO ログを使用した作業を提供します。 MySQL では、これらは Bin Log と呼ばれ、PosgreSQL では Write Ahead Logs (WAL) と呼ばれます。
• ストレージ – ディスクへの直接録音。

階層化されたデータベース構造。

データベースを拡張するには、シャーディング、Shared Nothing アーキテクチャ、共有ディスクなど、さまざまな方法があります。

ただし、これらの方法はすべて、同じモノリシック データベース構造を維持します。 これにより、スケーリングが大幅に制限されます。 この問題を解決するために、私たちは独自のデータベースを開発しました- アマゾンオーロラ。 MySQL および PostgreSQL と互換性があります。

アマゾンオーロラ

主なアーキテクチャ上のアイデアは、ストレージ レベルとログ レベルをメイン データベースから分離することです。

将来的には、キャッシュ レベルも独立させたと言えます。 アーキテクチャはモノリスではなくなり、個々のブロックをスケーリングする際にさらなる自由度が得られます。

ロギング レベルとストレージ レベルはデータベースとは別のものです。

従来の DBMS は、データをブロックの形式でストレージ システムに書き込みます。 Amazon Aurora では、言語を話すことができるスマート ストレージを作成しました やり直しログ。 内部では、ストレージがログをデータ ブロックに変換し、その整合性を監視して自動的にバックアップします。

このアプローチにより、次のような興味深いものを実装できます。 クローン作成。 すべてのデータの完全なコピーを作成する必要がないため、基本的により高速かつ経済的に動作します。

ストレージ層は分散システムとして実装されます。 非常に多数の物理サーバーで構成されています。 各 REDO ログは同時に処理され、保存されます シックスノット。 これにより、データ保護と負荷分散が確保されます。

読み取りスケーリングは、適切なレプリカを使用して実現できます。 分散ストレージにより、データの書き込みに使用されるメイン データベース インスタンスと残りのレプリカの間の同期が不要になります。 すべてのレプリカで最新のデータを利用できることが保証されます。

唯一の問題は、古いデータをリードレプリカにキャッシュすることです。 しかし、この問題は解決されつつある すべてのREDOログの転送 内部ネットワーク経由でレプリカに送信します。 ログがキャッシュ内にある場合、そのログは不正確としてマークされ、上書きされます。 キャッシュにない場合は、単に破棄されます。

倉庫を整理しました。

DBMS 層を拡張する方法

ここで、水平方向のスケーリングははるかに困難です。 だから、人里離れた道を進んでみましょう 古典的な垂直スケーリング.

マスター ノードを介して DBMS と通信するアプリケーションがあると仮定します。

垂直方向にスケーリングする場合、より多くのプロセッサとメモリを搭載する新しいノードを割り当てます。

次に、アプリケーションを古いマスター ノードから新しいマスター ノードに切り替えます。 問題が発生します。

• これには、アプリケーションの大幅なダウンタイムが必要になります。
• 新しいマスター ノードにはコールド キャッシュが存在します。 データベースのパフォーマンスは、キャッシュがウォームアップした後でのみ最大になります。

状況を改善するにはどうすればよいでしょうか? アプリケーションとマスターノードの間にプロキシを設定します。

これは私たちに何をもたらすのでしょうか？ これで、すべてのアプリケーションを新しいノードに手動でリダイレクトする必要がなくなりました。 切り替えはプロキシの下で実行でき、基本的に高速です。

問題は解決されたようです。 しかし、いいえ、キャッシュをウォームアップする必要性にまだ悩まされています。 さらに、プロキシが潜在的な障害点になるという新たな問題も発生しています。

Amazon Aurora サーバーレスによる最終ソリューション

これらの問題をどのように解決したのでしょうか?

代理人を残しました。 これは個別のインスタンスではなく、アプリケーションがデータベースに接続する際に経由するプロキシの分散フリート全体です。 障害が発生した場合は、どのノードもほぼ瞬時に交換できます。

さまざまなサイズのウォーム ノードのプールを追加しました。 したがって、より大きなサイズまたはより小さなサイズの新しいノードを割り当てる必要がある場合は、すぐに使用できます。 ロードされるまで待つ必要はありません。

スケーリングプロセス全体は特別な監視システムによって制御されます。 監視では、現在のマスターノードの状態を常時監視します。 たとえば、プロセッサの負荷が臨界値に達したことを検出すると、ウォーム インスタンスのプールに新しいノードを割り当てる必要があることを通知します。

分散プロキシ、ウォーム インスタンス、モニタリング。

必要な電力を備えたノードが利用可能です。 バッファ プールがそこにコピーされ、システムは安全に切り替わる瞬間を待ち始めます。

通常、切り替える瞬間はすぐにやって来ます。 その後、プロキシと古いマスター ノード間の通信が一時停止され、すべてのセッションが新しいノードに切り替えられます。

データベースの操作が再開されます。

グラフは、サスペンションが実際に非常に短いことを示しています。 青いグラフは負荷を示し、赤いステップはスケーリングモーメントを示します。 青いグラフの短期的な落ち込みは、まさにその短い遅延です。

ちなみに、Amazon Aurora を使用すると、コストを完全に節約し、週末など使用していないときはデータベースをオフにすることができます。 負荷を停止した後、DB は徐々に電力を低下させ、しばらくの間電源をオフにします。 荷重が戻ると再びスムーズに上昇します。

Amazon デバイスに関する次の部分では、ネットワークのスケーリングについて説明します。 購読する 郵便物 記事を見逃さないように、ぜひ注目してください。

На HighLoad ++ ヴァシリー・パンチュキンが報告する予定だ」ヒューストン、問題があります。 障害に備えたシステム設計、社内 Amazon クラウド サービスの開発パターン」 Amazon 開発者は分散システムのどのような設計パターンを使用しているのか、サービス障害の原因は何か、セルベースのアーキテクチャ、定常作業、シャッフル シャーディングとは何か、興味深いものになるでしょう。 カンファレンスまであと一ヶ月を切りました～ チケットを予約する。 24月XNUMX日最終値上げ。

出所： habr.com