HighLoad ++ 2016カンファレンスで、Oleg ObleukhovがInnoGamesで計画および実装した管理者の介入を必要としないアーキテクチャについて話しました。



みなさんこんにちは。 私についてほんの一言。 私の名前はオレグで、それ以前はヤンデックスで働いていましたが、サンクトペテルブルクの素晴らしい街に住んでいました。 今、私はドイツに移り、InnoGamesで働いています。 同社はオンラインゲームを開発しています。 1億5,000万人のユーザーのアカウントで-もちろん、Yandexよりもかなり小さな会社です。 そして、今日は、その量を知らずに、負荷データなしで高負荷のサービスを作成する方法についてお話します。



始める前に。 皆さんは私のことを知っています。聴衆について少し知りたいです。 本番でDockerを使用する人は手を挙げてください。 まあ、部屋の3分の1は、良いです。 そして今、手を挙げた人から、本番でDockerを使用することに満足している人を育てますか？ 大幅に少ない。 そして今、さらに複雑な質問です。 本番環境でDockerを使用することに満足している人は、システム管理者またはエンジニアである人、または開発者ではない人に手を挙げてください。 ３つ見えます。 わかった



実際、今日はDockerについては説明しません。 ただし、CRMについては説明します。 それが何であるか、なぜこのシステムが必要なのかを説明します。







画面で見ることができるように、これは最も人気のあるゲームの1つであるForge of Empiresのスクリーンショットです。 それはそれがどのように見えるかについてです。 プレイヤーがForge of Empiresをプレイすると、このプレイヤーのアクション（たとえば、「建物を建てる」または単に「追加のお金、内部通貨の「支払い」をクリックする」）がストアに送信されます。 これらすべてのアクションが記録されます。 しばらくの間、約4,000億のそのようなイベント（すべてのユーザーのすべてのクリック）がストレージに蓄積されました（これはもちろんHadoopです）。 これは25テラバイトに相当するディスクにあり、レプリカファクターやその他すべてをカウントしません。



なぜこのデータが必要なのですか？ このデータからユーザーの行動パターンを構築できます。 今日、何らかの行動をとるユーザーにどのような行動をするかを発表するため、他には何もしない特別なマネージャーグループがあります。 これは、いわゆるニアタイムキャンペーンまたは内部広告です。







こんな感じです。 たとえば、支払いウィンドウを閉じると、すぐに「一般的に、今どのように支払いますか。国内通貨よりも40％多い」というバナーが表示されます。 もちろん、他の行動パターンもあります。 たとえば、ユーザーがすぐにゲームを離れるかのように振る舞う場合、ユーザーのアクセス頻度が少なくなり、ゲーム内のアクションが少なくなります。 ユーザーを失うことは悪いことです。多くの場合、ユーザーが来るのに十分な費用がかかります。 これらのユーザーを維持する必要があります。



なぜこのシステムが必要なのですか？ ユーザーにプレイを許可し、必要なときに支払いを許可しないのはなぜですか？



まあ、もちろん、お金のために。 このサービスは、1年ほど前に機能していません。 統計によると、ユーザーに次のように表示するだけで、収益が2倍になるか、さらには増加することが確認されています。ユーザーはより喜んで支払います。



2つ目の非常に優れた機能は、ゲームのユーザーを遅らせることです。 つまり、ユーザーがゲームを離れたいように振る舞う場合、次のように伝えます。「いいえ、いいえ、いいえ、滞在してください。無料でボーナスを提供します。 たぶん割引ではなく、完全に無料です。 もちろん、各ユーザーは私たちにとって非常に重要です。



まあ、非常に、非常に重要なプロパティは、新しいプレーヤーの魅力です。 ユーザーが満足している場合、彼はとても幸せで、割引や無料のダイヤモンドを受け取り、「Forge of Empiresをプレイします。 とてもクールで、無料のダイヤモンドを入手できます。 特定のアクションを実行する必要があるのは、あなただけです。



すでに述べたように、約1年前、このサービスのアーキテクチャを形成するタスクを取得しました。 私にとっては、それはブラックボックスでした。 彼らは私に言った：「オレグ、私たちには最も人気のあるゲームが3つあります。」 もっとありましたが、これらは最も人気があります-Forge of Empires、Elvenar、Grepolis。 当時のこれらすべてのゲームはすでにイベントをHadoopに送信していました。誰かがプレイした場合のクリック数は次のとおりです。 一般に、これらのクリックはすべてHadoopに分類され、1日あたり約5億回クリックされます。 これはかなりの量です。



そのため、何らかのシステムを作成し、それを形成し、これらのイベントを引き出すアーキテクチャを作成し、何らかの方法でそれらをフィルタリングし、監視し、補足し、ゲームに送信してユーザーに割引を与える必要がありました。







こんな感じです。



最も重要な基準の1つは、できるだけ早くこのメッセージ、この割引を提供する必要があるということです。 たとえば、ユーザーは支払いウィンドウを閉じましたが、まだ暖かく、彼は再び考えます。「えー、私は買いたかったけど、高価なものだ」 そして、私たちは彼を叩きました-割引。 素晴らしいですか？ わあ！ それが基準の一つでした。



このシステムを作る必要があると言われたとき、エンジニアとしてどんな質問がありましたか？

• このシステムのアーキテクチャはどうあるべきですか？ コードがなかったので、何もありませんでした。 開発者と一緒にすべてを行う方法を考えていました。
• 信頼性があるべきですか？ つまり、配信速度は非常に重要です。 しかし、土曜日の夜に破損した場合、修復するために実行する必要がありますか？ または、月曜日まですべて放置して、静かに眠ることができますか？
• そして最も重要な質問：このシステムはどのくらいの負荷をかけるべきでしょうか？ ご存知のように、1日5億回のイベントが絶え間なく流れています。 しかし、それらのうちどれだけを取り、処理し、システムを介して実施し、ゲームに配るべきでしょうか？

建築

私たちが持っているサービスのアーキテクチャーについて少し掘り下げましょう。







あまり目立たない小さなロゴは、最も人気のあるゲームの1つであるForge of Empiresです。 このゲームは、他のいくつかのゲームとともに、Apache Stormの5億イベントすべてを管理します。 あなたの多くはそれが何であるかを知っています-私は説明しません。



CRMには、いわゆるフロントエンドがあります。フロントエンドでは、同じマネージャーが次のように話します。 私たちがとても親切だからです。」 彼らはこのフロントエンドで動作します。 すべてのデータはデータベースに書き込まれ、そのようなテンプレートや割引を使用すると、バナーは次のようになります。 これらはすべてデータベースに保存されます。 つまり、何らかのデータベースが必要です。



フィルターで除外されるデータは、KafkaのApache Stormから私たちの側であるシステムに届きます。 もちろん、これは例外なくHadoopに飛んでいきます。 彼らが言うように。 そのため、このデータを使用できます。



次に、サービスの側面に、いわゆるコンシューマがあります。これは、Kafkaからこのデータを読み取り、何らかの方法でフィルタリングし、補完し、何らかの方法で一般化し、動作を調べ、キュー内のすべてを詰め込みます。 これはすべて信頼性のために行われます。 次に、データベースをチェックし、イベントを補足し、そこにバナーを追加し、そこから何かを削除し、それをすべてゲームに送信するプロデューサーがいます。







この写真でも何が見えますか？

• マイクロサービスを使用します。 実際には、多くの小さなコンポーネントがあります。 それらはすべてここに表されているわけではありませんが、これは全体像であるため、明確です。
  
  
• 負荷は順次増加しています。 今日、マネージャーは気分が良く、「しかし、すべてのユーザーに割引を与えましょうか？ 現在、数百万人、数千万人のユーザーがオンラインでプレイしているすべての人に割引を提供しますか？」当然、Apache StormからKafkaへのデータの流れが増加し、Kafkaからシステムの側に移動します。システムのすべてのコンポーネントで、負荷が大幅に増加します。
  
  
  
  5億のイベントすべてが私たちに届くと、すべてが非常に重くロードされます。 マネージャーは機嫌が悪く、「今日は誰にも値引きをしたくありません。みんなびっくりしました。」 負荷はまったくなく、サーバーは何もしません。
  
  
• コンポーネントは高信頼性でなければなりません。 たとえば、Kafkaの消費者が真夜中に故障すると、すべてが停止し、Kafkaがオーバーフローし、大量のデータが失われます。 一般に、それは非常に悲しいことであり、それから私達は私達自身の手でそれをすべて回復しなければなりません。
  
  
• さて、実際にコンポーネントの数は何ですか？ いい質問ですね なぜなら、どのコンポーネントにどの時点でより多くの負荷がかかるかが明確ではないからです。
  
  

ホールでアイデアを得たのは、100台の仮想マシンを起動し、常に稼働させ続けてみませんか？ 生命の場合だけで、負荷が来れば-私達はそれらをすべて飲み込みます、そうでなければ-彼らは立ち、何もしません。 誰もがそのような考えを持っていますか？ 実際には良いアイデアだからです ここに座っている一人の健康な人がいます。



すでに述べたように、会社はドイツにあります。 これはロシアにはあまり関係ないかもしれませんが、電気代は支払っています。 独自のデータセンターがあります。 測定を行うと、空の仮想マシンは、ペイロードがまったくないため、12ワットの電力を消費することがわかります。 動いているからといって。 これは1つの測定チャートです。 私はそのような束を作りました-それのために私の言葉を受け取ります。







必要ですか？ 100台の仮想サーバーを起動すると、それらは何もしない、まったく何もしないという理由だけで、月額100ユーロを消費します。 それとも、より大きなシステムをお持ちですか？ 1000台のサーバー、このようになります。







データセンターの空気を温めるだけです。 なぜこれが必要なのでしょうか？



ここで何ができますか？ この状況から抜け出す方法は？ そう！ 自動スケーリングを使用します！ どうして？



システムが何もしない場合（たとえば、マネージャーが今日有害であり、誰にも割引を与えないことを決定した場合）、必要最小限の高可用性のみをサポートします。 少なくとも2つのコンポーネントをリリースしました。



多くの企業がこれを行っています。 私はこれなどのためにAmazonソリューションがあるという事実については話していない。 Facebookでもできます。 彼らは最近、たとえば、ハードドライブを物理的にシャットダウンする方法に関する記事を公開しました。 多くの企業は、サーバーを無駄にしないように、この方法で電力またはリソースを節約しようとしています。



必要に応じて、負荷が発生した場合、同じコンポーネントの追加のインスタンスをいくつか起動しないのはなぜですか？ Kafkaからイベントコンシューマーを起動するだけで、すべてがうまくいきます。 そして、これが十分でない場合：たくさんのコンポーネントを起動しましたが、十分な仮想マシンがありませんか？ 仮想マシンを追加しましょう。問題は何ですか-これもそれほど難しくありません。



まあ、いいボーナスとして。 システム管理者とエンジニアは私を理解します-システムはそれ自体を癒します。 何らかの理由でいずれかの種のすべての成分が死んだ場合、システムはこれらの成分を開始します。 必要に応じて、サーバーを起動します。 それはあなたを眠れぬ夜から、あなたの妻とのquarや夜の仕事から生じるかもしれない他の問題から救うでしょう。

起源

自動スケーリングがどのように機能するかを理解するには、起源に目を向け、その時点で何があったかを理解する必要があります。



3つのデータセンターがありました（現在もあります）。 数千の仮想マシンと数百のハイパーバイザーマシンがあります。 主に仮想マシンに使用します。 主にライブマイグレーションが原因で、XenからKVMへの移行が完了しました。



私たちはかなり現代的な会社です。 さまざまなクラウドソリューションをテストしています。 今後は、独自のデータセンターを使用するよりもはるかに高価であると言えます。 自動スケーリングが機能しなくなり、Amazonで1000台の仮想マシンが起動した場合、壊れてしまい、CRMの割引は役に立ちません。



Dockerを使用しますが、実稼働環境でも使用します。 しかし、私は手を挙げませんでした;彼にとても満足していません。 ほとんどの場合、彼は私たちに適さず、ライブマイグレーションもありません。 なぜ必要なのか、後で説明します。



当時、すでに独自のクラウドソリューションがありました。 実際、特別なものは何もありません。Pythonで書かれたWebインターフェースだけです。それについて説明します。



Graphite、Puppet、Nagiosなど、かなり原始的なオープンソースソリューションを使用しています。 しかし、ハイライトが1つあります。Pythonで書かれた同僚は、BrassMonkeyという名前のシステム管理者です。



したがって、すべてのサービスの負荷を何らかの形でバランスさせる必要があります。 たくさんのコンポーネントがあり、さらに1万個の新しいコンポーネントが表示される可能性があることを覚えています。 そして、それらの負荷を積極的にバランスさせる必要があります。 新しいものを選択した場合、すぐにバランスを取ります。



ご覧のとおり、複数のホストがあり、各ホストには一定数のマイクロサービスが実行されており、これらの各マイクロサービスにはループバックインターフェイスにパブリックIPアドレスがあります。



FreeBSDとパケットフィルターで負荷分散を実行します。 ファイアウォールは、比較的言えば、負荷を分散できます。 とても簡単に機能します。 ハードウェアロードバランサーがあり、同じIPで仮想ロードバランサーを持ち上げました。 負荷はインターネットから発生し、これはすべて安全にサーバー、コンポーネントに送信されます。



しかし、サービスNがサービス1に接続したい場合はどうなりますか？







スライドは次のとおりです。Linuxはデフォルトで、最短パス、つまりローカルネットワークスタックを直接使用することを推奨します。 サービス1が停止するとどうなりますか？ もちろん、この接続はすべて切断されます。 サービスNはそれについて決して知ることはありません。 何も機能せず、ログに登るまで、その理由を理解できません。



この問題を解決するために、小さなハックを作成しました。 通常、このIPに関連するすべてのトラフィックは常に送信されます。 これにより少し遅くなりますが、サーバーは同じラック内にあります。 ほとんどの場合、仮想マシンは同じハイパーバイザーで実行されます。 それはそれほど難しくなく、怖くない。



これを行うのは非常に簡単で、魔法は必要ありません。 Linuxでは、デフォルトでホストにIPを追加すると、ローカルルーティングテーブルにルートを追加します。「常にこのIPにローカルにトラフィックを送信します。 このルートを削除し、テーブルを追加して、「そして、常に外部インターフェイスを経由します」と言うだけです。 それだけです。 トラフィックを送信するのに必要なのはそれだけです。 常にヘルスチェックを行い、サービスの状態を常に把握しており、何か問題が発生した場合は、別のホストに簡単にリバランスできます。 問題ありません。







CRMでこの負荷分散を使用し、多くのホストがあり、マイクロサービスを実行しています。 ご覧のとおり、各ホストには、可能なすべてのマイクロサービスの完全なセットが必要ではありません。 それらは完全に異なる場合があります。 そして、それらの前にロードバランサーがあります。 これらはすべて安全にバランスが取れています。



LBプールがアセンブルされ、ロードバランサーがマイクロサービスNがないホストHでアセンブルされるとどうなりますか？ 負荷は、そこに現れるまでバランスが取れません。 すべてが非常にシンプルで簡単です。 また、直接接続したい場合は、上記では説明していませんが、接続せず、ロードバランサーを介して接続します。



ロードバランサーはほぼどこでも組み立てられています。 すでに話したデータベースがあります。 この場合、MariaDBを使用します。完全に同期したGaleraクラスターがあります。 システム管理者と協力することは非常に便利です。 大きな負荷はありません。動作させてください。 負荷はまったく同じ方法でバランスが取られます。 たとえば、より多くの負荷が必要な場合は、いつでもホストをスローして追加し直すことができます。



コンポーネントは、ロードバランサーを介して直接接続されます。 あなたが見たまさにそのキューのために組み立てたのとまったく同じシステム。 RabbitMQを使用します。

自動スケーリング

私たちはすでに準備が整っており、CRMアーキテクチャに関するすべてを完全に理解しています。オートスケーリングについてお話しましょう。



ハイパーバイザーがあり、それらの多くがあり、それらの多くがそれぞれで仮想マシンを実行しています。 各仮想ホストで、多くのマイクロサービスを開始しました。 どういうわけか、プロセッサとメモリの使用量に関するデータを送信する必要があります。



Graphiteに発送します。 ただし、Graphiteは信頼性に欠ける場合があるため、ときどき再起動するか、何か悪いことをする必要があります。 信頼性の高い動作を実現するには自動スケーリングが必要なので、常にGraphiteに到達するためのメトリックが必要です。そうしないと、システムが狂ってしまいます。 合格しました。



これを行うには、特別なGrafsyクライアントが必要です。GitHubで見つけることができます。 このGrafsyは、すべてのメトリックを確実にGraphiteに送信します。



グラファイトについて話します。 この部屋の他の人たちと同じように、私たちはGrafanaを使用しています。Graphiteを使用する人はいません。 Graphiteの使用に関する興味深い詳細を次に示します。







恥の壁として使用します。 ここには、当社のすべてのシステム管理者がいます。 監視システムで人が抱えている問題の数を示します。 それは実際にきれいに整頓するのに役立ちます。 そこにこのデータを送信するだけで、誰もがそれを見ることができます。 何かの場合：「ねえ、それを修正してください！」



Graphiteと言えば、ホストは2つしかありませんが、ホストはかなり大きいです。 約400ギガバイトのRAMが搭載されています。 ウィスパーを使用します。 なぜささやきますか？ これはかなり古いファイルデータベースであることは誰もが知っています。 かなり大きな負荷があるため、これを使用します。 これは1秒あたり5万（またはそれ以上）のメトリックであり、非常に多くなります。 ClickHouseまたはCassandraに移行しようとしましたが、彼らが言うほどクラウドレスではありません。 Whisperよりも約2倍遅くなります。



すべての仮想ホストで実行されているGrafsyクライアントを使用します。 彼は自分自身にメトリックを取得します。 何らかの理由でGraphiteが使用できない場合、これらのすべてのメトリックを後で再送信します。 このクライアントの本質は非常にシンプルです。 それは非常に軽く、文字通り2メガバイトのメモリを必要とし、すべてのサーバーで動作します。 より多くの機能があります。 GitHubをご覧ください 。



また、特別な通知機能も使用します。これは、Grafana Webインターフェースで何かを行うことを約束しているが、まだ実行していないためです。 Grafanaのグラフで何かが変更された場合、そのことを通知することをずっと前に約束していました。 しかし、これはまだ行われていません。 ディスク容量が増えた場合、監視で確認しただけで確認できますが、グラファイトでは確認できません。 このような単純なデーモン、さらにはスクリプトがあります。 彼はGitHubにも参加しています 。 彼はあなたとあなたの監視システムに通知します。 それは非常に普遍的であり、多くの異なる監視システムに通知できます。



IGCcollectを使用して統計を収集します。 このIGはInnoGamesから形成されています。 GitHubにもあります 。







すべてのメトリックがGraphiteに到着すると、Nagiosに通知されます。 プロセッサの消費量を増やす場合は、同じ通知機能を使用してNagiosに通知します。







Nagiosについて一言。 私たちは皆、IcingaとThrukをWebインターフェースとして使用しています。 Nagiosは多くの興味深いタスクにも使用されます。たとえば、実際にはIPアドレスを持たない偽のホストなどです。何もせず、単なるダミーのバカです。 それらはNagiosにあり、バックアップの検証など、いくつかのチェックを行います。 バックアップを作成するだけでなく、別の場所で個別に解凍し、すべてが正常であることを通知します。 これは、特別なホストタイプの「アグリゲーター」と呼ばれます。 将来的には、自動スケーリングに使用します。



Nagiosも非常に大きく、1つのホストから1秒あたり約450のチェックを実行します。異なるデータセンターに2つのホストがあります。



次に何が起こりますか？ Nagiosが何らかの方法で、たとえば、あるコンポーネントによるプロセッサの使用量が多すぎるという情報を受信すると、強力で強力なBrassMonkeyが登場します。 私が言ったように、これは私たちの同僚です。 システム管理者。 彼について少し話しましょう。 これはどのように見えるかです。







日常的なタスクを解決するために長い間使用されてきました。 たとえば、サーバーを再起動します。 真夜中に、何らかの理由で仮想マシンがフリーズしました。 BrassMonkeyは、電話を受ける代わりに、この仮想マシンを起動して再起動するだけで問題ありません。



同じことが、デーモンの再起動、ある種の日常的なタスクでも起こります。 彼の仕事のアルゴリズムは非常に単純です。 彼はNagiosに行き、「聞きなさい、仲間、少なくとも私のために何かありますか？」そうであれば、システム管理者に通知し、実際にいくつかのアクションを実行します。 しかし、当然、彼はもっと多くのことを行うことができます：自動スケーリング！



たとえば、BrassMonkeyがビジネスを開始すると、プロセッサ時間の消費量がある程度増加する何らかのイベントに反応し、Serveradminに接続します。これは、先ほど述べたクラウドソリューションと同じです。







実際、このServeradminはインフラストラクチャ内のすべてを管理します。 彼ができる最も重要なことは、単一のコマンドで問題なく新しい仮想マシンを作成するか、たとえば既存の仮想マシンにコンポーネントを追加することです。 必要なのは、BrassMonkeyがServeradminに何かをするように要求することだけです。



これが、Serveradminの外観です。







さらに多くの属性がありますが、それらを見る必要はありません。 彼の主な仕事は、単一の真実の源になることです。 その中にあるすべての情報には、すべてのインフラストラクチャが含まれています。 ホストが存在する場合、そのホストについてのすべてがそこに記述されます。 常に最新の情報が必要です。



ホストの役割を変更する場合は、Webインターフェースを介して属性内のPuppetクラスをすぐに変更します。 つまり、「さて、あなたはもはやWebサーバーではなく、あなたはデータベースです」と言うのです。 1つの属性を変更するだけで完了です。



もちろん、DNSなどの些細なことを管理し、サーバーがどのバランサーの下にあるかを管理します。 そして、最も興味深いことに、仮想マシンの場所を制御します。 Webインターフェイスに移動し、そこで仮想マシンの場所を変更できます。 この属性はxen_hostと呼ばれます-歴史的には、Xenを使用していました。 属性を変更すると、同じKVMライブ移行を使用して、ダウンタイムなしでマシンが自動的に移行されます。 あなたの記憶はその場でゴージャスに同期されます。 そしてもちろん、彼はNagiosのチェック、Graphiteのグラフィックスなどの基本的なことを管理しています。







これは、自動スケーリングとCRMを監視するためのダッシュボードの外観です。 多くのグラフ、あなたにとって興味深いグラフ-右上の3つ。 彼らは私たちのシステムの能力を示しています。 プロセッサの使用（現在はプロセッサがまったく使用されていない）、メモリ使用量、およびコンポーネントを起動する仮想マシンのスロット数があることがわかります。



すべてを監視します。すべてグラファイトに送られます。これはすべてNagios、BrassMonkeyを通じて行われ、すべてが美しいです。 すべてがどのように機能するかを見てみましょう。 実際の例。







これがアグリゲーターの外観です。Nagiosの同じ仮想ホストでは、重要なCRMフロントエンドコンポーネントがあることがわかります。 何らかの理由で、おそらく夜中にコンポーネントの1つが死にました。 どうなるの？







BrassMonkeyはゲームに参加し、いくつかの分析を行い、既に存在するホストの1つに問題なく新しいコンポーネントを追加したと書きます。



次の場合。 負荷を増やしました。 Kafkaから多数のイベントが到着し、CRM-event-consumerでの平均コンポーネント負荷が約70％増加しました。これは、重大なしきい値を超えています。







繰り返しますが、これはGraphiteのグラフで見ることができます。 2つのグラフが表示されます。左側はすべての仮想マシン上のコンポーネントによるプロセッサ消費量であり、右側はそれらのコンポーネントの数です。 18:10頃、負荷が大幅に増加し始め、一部のデータが到着し始め、コンポーネントが機能し始めたことがわかります。彼女は容認できる立場にあり、何もしませんでした。次に、この負荷がクリティカルしきい値を超え、18：23頃に最初の追加コンポーネントが追加されました。さらに、負荷は増大し続け、システムは2番目のコンポーネントを追加します。状況が解決されたため、そこで停止します。負荷が下がります。



少し時間がかかりましたが、負荷が増加した場合でも同じコンポーネントを維持しました。これはかなり良い習慣です、Facebookもアドバイスしています。あなたが記事を読んだ場合、Netflixはそれらを自動スケーリングするので、彼らはまた言っている：事前に予測してから、コンポーネントの数をゆっくり減らしてください。念のためにそれらを保持します。



また、プロセッサ消費のグラフで、最初はコンシューマ、コンシューマイベントの負荷は増加しましたが、プロデューサの負荷は増加したことがわかります。つまり、プロデューサーもしばらくしてからゲームに参加しました。イベントをフィルタリングして追加する必要があり、何らかの魔法が起こっていたからです。しかし、プロデューサーは私たちのしきい値を超えなかったため、プロデューサーとは何もしませんでした。



BrassMonkeyのログを見ると、BrassMonkeyはある時点で停止することを決定したことがわかります。これは、各コンポーネントに必要な量に独自の制限があるためです。このコンポーネントにはより多くのプロセッサを消費する必要があり、もう1つはより多くのメモリ、3番目のディスクが必要です。



システムが狂わないように、朝に起きないように、そして問題がないように、いくつかの制限があります。私たちは、BrassMonkeyが仮想マシンのディスクを増やすために働いた状況がありました。デフォルトの仮想マシンは10ギガバイトでした。朝目が覚めたとき、彼女は400ギガバイトでした。 XFSは簡単に増加しますが、まったく減少しないため、これは非常に不快でした。



最愛のServeradminを見ると、Serveradminが制御するPuppetクラスと同じ属性も4つのコンポーネントであることがわかります。私たちは時間ではありません。







負荷が低下すると、次に何が起こりますか？写真で見たように、ある時点で彼女は眠っていました。プロセスの消費に最小制限があるという警告が表示されます。条件付きで何もしません。ただ過ごし、空気を温めます。 BrassMonkeyのログを見ると、彼は次のようにも言っていることがわかります。「分析後にいくつかのコンポーネントを取得しましょう。」







このような自動スケーリングを機能させるには、何をする必要がありますか？







どこにでもあるオープンソースのソリューションに加えて、何かを書く必要があります。



メトリックを確実に配信するには、Grafsyクライアントが必要です。何らかの理由でGraphiteを壊した場合-たとえば、Whisperを使用し、レプリケーションを十分にハードにします-停止するだけで、Grafsyは数日、場合によっては数週間、場合によってはメトリックを蓄積し、それらはすべて一緒に送信します。したがって、それらを失うことはありません。



まだ同じ通知機能を記述する必要があります。しかし、彼らは言うように、すでに書かれています、神に感謝します。彼はあなたに通知します、あなたはさまざまな監視システムにそれを使用することができます、すべてはそこで非常に簡単です。



これについてはお話ししませんでしたが、ご存知のように、データベースクラスターとキュークラスター、この場合はRabbitMQがあります。また、クラスター内のノードが動作していることを確認する必要があります。無生物の場合、負荷のバランスを取るべきではありません。しかし、MySQL、MariaDBで何をすべきでしょうか？ telnetまたはお気に入りのユーティリティを使用して接続するだけで、「このノードは実行中です」と彼女は言います。



そのデータが関連していない場合はどうなりますか？ ClusterHCは、すでにモジュラーシステムであるという点で興味深いです。モジュールも簡単に追加できます。彼は、クラスターが同期しているという事実について、MySQLとRabbitMQをチェックできます。すべてがとても美しいです。



同じMySQLに対して、ユーザーマネージャーを使用します。 Puppetモジュールを試しましたが、ひどいので、使用しないでください。mmduを試してください。ホストをクラスターに含めるには、初期設定が必要です。一部のユーザーが存在する必要があります。これは、このユーティリティで非常に簡単に実行できます。彼女は、構成ファイルからすべてを簡単に作成します。



これらのユーティリティはすべてGoで記述されています。 BrassMonkeyがあることを思い出してください。BrassMonkeyには、何をどのような場合に実行するかを示すモジュールが必要です。 Pythonで書かれています。



アーキテクチャの決定では、何かをしなければなりませんでした。コンポーネントまたは仮想マシンの数など、増加する必要があるものを測定する方法を決定する必要がありました。積分と微分の2つの方法があります。負荷の増加を予測することはできますが、「オーケー、そのような時間の平均負荷は、そのような時間に等しい」と言うことができます。



差動パスを試しました。非常に悪い、あなたは常に予測しているからです。システムがすでに処理している可能性のあるデータストリームがあり、既に何かをスケーリングする必要はなく、一定の誤検知があります。これは非常にいので、私たちは不可欠な道にとどまることにしました。



1つのコマンドで仮想マシンを作成する必要があります。簡単に聞こえますが、Puppetを使用する人は、少なくとも何らかの形でPuppetを5〜6回実行して動作させる必要があることを知っています。それを非常に良い形にする必要があります。



まあ、非常に重要なポイント。これは開発者にとってより重要です。複数のコンポーネントを同時に動作させる必要があります。開発者と仕事を始めたときに最初に出会ったのは、コンポーネントがリソースを奪い合っているだけなので、常にデッドロックが発生していたからです。



これらはすべてかなり明白なものであり、魔法はありません。システムを適切に保つ必要があります。

まとめ

これらすべてから結論を導きたいのは何ですか？



実際に、独自の自動スケーリングを行うことはそれほど難しくありません。高価なAmazon、Google、Microsoft Azureを使用する必要はありません。これはすべて、独自のリソースを使用する場合の少なくとも3倍の費用がかかります。トレンドを追いかける必要はありません。



私は私が強く主張すると言うことができます：多分あなたはすでにこのためのすべてを持っていると思います。ほとんどの場合、他のシステムやテクノロジーに移行する必要はありません。現在の仮想化を使用するだけです。これはすべて行われています。



会社のリソースを節約できます。ハードウェアマシンのささいな電力、ディスクスペース、およびスロットを節約することに加えて、独自のリソースを節約できます。真夜中にすべてを修正する必要がないからです。システム自体が修復されるため、システム管理者は満足します。



さて、私にとって重要なポイントは、ここにこの痛みがあります。これは、開発者が適切なアプリケーションを作成するために必要なものです。この前のプレゼンテーションは、適切なコードに関するものでした。これで適切なアプリケーションができました。それはかなり明白に聞こえます。

GitHubに記載されているすべてのユーティリティを見つけることができます。



→ 当社のGitHub

→ My GitHub



詳細については、当社のWebサイトをご覧ください 面白いかもしれません。 ありがとう





負荷の量を知らずに負荷の高いサービスを作成する方法