フェイルオーバー: 完璧主義と怠惰が私たちをダメにします

夏になると、購買活動と Web プロジェクトのインフラストラクチャの変化の激しさの両方が伝統的に減少すると、Captain Obvious 氏は語ります。 それは、IT スペシャリストであっても休暇を取ることがあるためです。 そしてCTOも。 現職に留まる人々にとってはなおさら難しいが、今はそれが問題ではない。おそらくだからこそ、既存の予約制度についてゆっくりと検討し、改善する計画を立てるには夏が最適な時期なのだろう。 そしてエゴール・アンドレーエフの経験から 管理部門、彼はカンファレンスで話しました 稼働日.

バックアップ サイトを構築するときに陥る可能性のある落とし穴がいくつかあります。 そして、それらに巻き込まれることは絶対に不可能です。 そして、他の多くのことと同様、これらすべてにおいて私たちをダメにするのは、完璧主義と怠惰です。 私たちはすべてを完璧にやろうとしていますが、完璧にやる必要はありません。 特定のことだけを行う必要がありますが、それらを正しく実行し、適切に機能するように完了してください。

フェイルオーバーは、楽しい楽しいものではありません。 これはまさに XNUMX つのことを実行する必要があります。ダウンタイムを削減して、サービスや企業の損失を少なくすることです。 そして、すべての予約方法において、次のような文脈で考えることをお勧めします。「お金はどこにあるのか?」

最初の罠: 大規模で信頼性の高いシステムを構築し、冗長性を確保すると、事故の数が減ります。 これはひどい誤解です。 人員削減をすると、事故が増える可能性があります。 すべてを正しく行えば、全体としてダウンタイムが削減されます。 事故は増えるだろうが、発生するコストは低くなるだろう。 予約とは何ですか? - これはシステムの複雑さです。 複雑な機構はすべて悪いものです。より多くの歯車、より多くの歯車、つまりより多くの要素があるため、故障の可能性が高くなります。 そして本当に壊れてしまいます。 そして、壊れる頻度も高くなります。 簡単な例: PHP と MySQL を使用した Web サイトがあるとします。 そしてそれは緊急に予約する必要があります。

Shtosh (c) 2 番目のサイトを使用して、同一のシステムを構築します... 複雑さは 3 倍になります。エンティティが 5 つあります。 また、あるサイトから別のサイトにデータを転送するための特定のロジック (データ レプリケーション、静的データのコピーなど) も展開します。 したがって、レプリケーション ロジックは通常非常に複雑であるため、システム全体の複雑さは 10 倍ではなく、XNUMX、XNUMX、XNUMX 倍になる可能性があります。

第二の罠: 本当に大規模で複雑なシステムを構築するとき、私たちは最終的に何が得たいかを空想します。 出来上がり: 私たちは、ダウンタイムなしで動作し、XNUMX 秒 (またはさらに良い場合は瞬時) で切り替わる、非常に信頼性の高いシステムを手に入れたいと考えています。そうすれば、夢の実現が始まります。 ただし、ここにはニュアンスもあります。希望するスイッチング時間が短くなるほど、システム ロジックはより複雑になります。 このロジックを複雑にすればするほど、システムが故障する頻度が高くなります。 そして、非常に不快な状況に陥る可能性があります。私たちはダウンタイムを短縮するために全力を尽くしていますが、実際にはすべてをより複雑にしており、何か問題が発生した場合、ダウンタイムは最終的に長くなる可能性があります。 ここで、「うーん…予約しないほうがいいだろう」と考えてしまうことがよくあります。 単独で動作し、ダウンタイムが理解できる範囲で動作するほうがよいでしょう。

どうやってこれと戦うことができますか？ 私たちは自分自身に嘘をつくのをやめ、今ここで宇宙船を建造するつもりだと自分に媚びるのをやめる必要がありますが、プロジェクトがどれくらいの期間嘘をつき得るかを十分に理解する必要があります。 そして、この最大時間内で、システムの信頼性を高めるために実際にどのような方法を使用するかを選択します。

「W からのストーリー」の時間です...もちろん、人生からの話です。

例その XNUMX

N 市にある Pipe Rolling Plant No. 1 の名刺 Web サイトを想像してください。そこには大きな文字で「PIPE ROLLING PLANT No. 1」と書かれています。 そのすぐ下には、「私たちのパイプは、N で最も丸いパイプです。」というスローガンがあります。 そして以下は CEO の電話番号と名前です。 ご予約が必要であることを承知しておりますが、これは非常に重要なことです。 それが何で構成されているかを理解してみましょう。 HTML-statics - 総支配人が実際に浴場のテーブルでパートナーと何らかの次の取引について話し合っている数枚の写真です。 私たちはダウンタイムについて考え始めます。 思い浮かぶのは、XNUMX分間はそこに横たわる必要がある、それ以上はだめだ、ということです。 そして、疑問が生じます。私たちのこのサイトから全体でどれくらいの売上があったのでしょうか? いくら～いくら？ 「ゼロ」とはどういう意味ですか？ それはつまり、将軍は昨年、XNUMX回の取引すべてを同じテーブルで、一緒に銭湯に行ってテーブルに座る相手と同じ人たちと行ったからである。 そして、たとえサイトが XNUMX 日放置されていたとしても、恐ろしいことは何も起こらないことを私たちは理解しています。

紹介情報に基づいて、この話を上げる日があります。 冗長性スキームについて考えてみましょう。 そして、この例では最も理想的な冗長性スキームを選択します。つまり、冗長性を使用しません。 このすべては、管理者なら誰でも、休憩を挟んで XNUMX 分以内に上げることができます。 Web サーバーをインストールし、ファイルを追加するだけです。 それが動作します。 何も監視する必要はなく、特別な注意を払う必要もありません。 つまり、例 XNUMX の結論は非常に明白です。予約する必要のないサービスは予約する必要がありません。

例その XNUMX

会社ブログ: 特別な訓練を受けた人がニュースを書いたり、展示会に参加したり、また新製品をリリースしたり、など。 これが WordPress を備えた標準的な PHP であり、小さなデータベースと少しの静的要素があるとします。 もちろん、どんな状況でも横になってはいけないことをもう一度思い出します。「50分以内！」それだけです。 しかし、さらに考えてみましょう。 このブログは何をするものですか? 人々は、いくつかのクエリに基づいて、Yandex や Google から有機的にそこにやって来ます。 素晴らしい。 売上は関係ありますか？ エピファニー：そうではありません。 広告トラフィックは、別のマシン上にあるメイン サイトに送信されます。 予約スキームを考えてみましょう。 良い意味で数時間で上げないといけないので、その準備をしておくと良いでしょう。 別のデータセンターからマシンを取得し、そこに環境 (Web サーバー、PHP、WordPress、MySQL) を展開し、そこに残しておくのが合理的です。 すべてが壊れていると理解した時点で、XNUMX つのことを行う必要があります。mysql ダンプを XNUMX メートル展開します。XNUMX 分以内にそこに飛びます。もう XNUMX つは、バックアップから一定数の写真をそこに展開します。 これも、いつまで続くかは神のみぞ知るです。 したがって、XNUMX分以内に全体が上昇します。 レプリケーションはありません。さもなければ、自動フェイルオーバーです。 結論: バックアップからすぐに展開できるものはバックアップする必要はありません。

例 XNUMX はさらに複雑です

オンラインストア。 オープンハートの PhP には少し調整が加えられていますが、mysql にはしっかりしたベースがあります。 かなり多くの静的データ (結局のところ、オンライン ストアには美しい HD 画像などがあります)、セッションには Redis、検索には Elasticsearch が使用されます。 私たちはダウンタイムについて考え始めます。 そしてここで、もちろん、オンラインストアは一日中苦痛なく横たわることができないことは明らかです。 結局のところ、嘘が長くなればなるほど、より多くのお金を失うことになります。 スピードを上げる価値はある。 いくら？ XNUMX時間横になったら誰もおかしくないと思います。 確かに、私たちは何かを失いますが、一生懸命働き始めれば、状況は悪化するだけです。 XNUMX 時間あたりに許容されるダウンタイムのスキームを定義します。

どうすればこれらすべてを予約できるのでしょうか？ どのような場合でも車が必要です。100 時間の時間は非常に短いです。 Mysql: ここではすでにレプリケーション、ライブ レプリケーションが必要です。500 時間では XNUMX GB はダンプに追加されない可能性が高いためです。 静止画、写真: 繰り返しますが、XNUMX 時間以内に XNUMX GB を追加する時間がない場合があります。 したがって、写真をすぐにコピーすることをお勧めします。 Redis: ここが興味深いところです。 Redis ではセッションが保存されます。セッションを取り出して埋めるだけでは済みません。 これはあまり良いことではありません。すべてのユーザーがログアウトされ、バスケットが空になるなどです。 ユーザー名とパスワードを再入力する必要があり、多くの人が途中で購入をやめてしまう可能性があります。 繰り返しますが、コンバージョンは低下します。 一方、Redis は直接最新であるため、最後にログインしたユーザーもおそらく必要ありません。 そして、適切な妥協案は、Redis を使用して、昨日のバックアップから復元することです。または、XNUMX 時間ごとに実行する場合は XNUMX 時間前のバックアップから復元します。 幸いなことに、バックアップからの復元は XNUMX つのファイルのコピーを意味します。 そして最も興味深い話は Elasticsearch です。 MySQL レプリケーションを知った人はいるでしょうか? Elasticsearch レプリケーションを知っている人は誰ですか? そしてその後、誰にとっては正常に動作しましたか? 私が言いたいのは、私たちのシステムの中に特定の実体が見えるということです。 便利そうに見えますが、複雑です。
私たちの同僚のエンジニアはそれを扱った経験がないという意味で複雑です。 またはネガティブな経験があります。 あるいは、これはまだニュアンスや生々しさを伴うかなり新しいテクノロジーであることも理解しています。 私たちは考えます...くそー、エラスティックも健全です、バックアップから復元するのにも長い時間がかかります、どうすればよいでしょうか? この場合、elastic は検索に使用されることを理解しています。 私たちのオンラインストアはどのように販売されていますか? 私たちはマーケターのところに行き、人々がどこから来たのかを尋ねます。 彼らはこう答えます。「Yandex Market からの 90% が製品カードに直接送られてきます。」 そして、彼らはそれを買うか買わないかのどちらかです。 したがって、10% のユーザーが検索を必要としています。 そして、特に異なるゾーンの異なるデータセンター間での柔軟なレプリケーションの維持には、実際には多くの微妙な違いがあります。 どの出口ですか？ 予約サイトからエラスティックを取得し、それに対して何も行いません。 問題が長引けば、いつか引き上げるだろうが、それは確実ではない。 実際、結論はプラスマイナスを問わず同じです。繰り返しになりますが、お金に影響を与えないサービスは予約しません。 図をより単純にするため。

例 XNUMX はさらに困難です

インテグレーター: 花を売ったり、タクシーを呼んだり、商品を売ったり、一般的には何でもします。 多くのユーザーにとって年中無休で機能する深刻な機能です。 本格的な興味深いスタックでは、興味深いベース、ソリューション、高負荷があり、そして最も重要なことに、24分以上横になると痛いです。 人々が買わないだけでなく、これがうまくいかないとわかると腹を立て、まったく戻ってこなくなる可能性があります。

わかりました。 五分。 これについてはどうするのでしょうか？ この場合、大人と同じように、私たちもすべての資金を使って実際のバックアップ サイトを構築し、すべてを複製し、おそらくこのサイトへの切り替えを可能な限り自動化することさえあります。 これに加えて、忘れずに重要なことを 53 つ行う必要があります。それは、実際にスイッチング規則を作成することです。 すべてを自動化している場合でも、規制は非常にシンプルになる場合があります。 一連の「これこれの Ansible スクリプトを実行する」、「ルート XNUMX でこれこれのチェックボックスをクリックする」などですが、これはある種のアクションの正確なリストである必要があります。

そして、すべてが明確に見えます。 レプリケーションの切り替えは簡単な作業であり、そうでない場合は自動的に切り替えられます。 DNS のドメイン名の書き換えも同じシリーズです。 問題は、そのようなプロジェクトが失敗するとパニックが始まり、最も屈強なひげを生やした管理者でもパニックに陥りやすいことです。 「ターミナルを開いて、こちらに来てください。サーバーのアドレスはこのままです」という明確な指示がなければ、蘇生に割り当てられた 5 分の制限時間を守ることは困難です。 さらに、これらの規制を使用すると、たとえばインフラストラクチャの変更を記録し、それに応じて規制を変更することも簡単になります。
予約システムが非常に複雑で、ある時点で間違いを犯した場合、バックアップ サイトを破壊し、さらに両方のサイトのデータをカボチャに変える可能性があります。これはまったく悲しいことです。

例そのXNUMX、完全なハードコア

世界中で何億人ものユーザーがいる国際的なサービスです。 どの時間帯も最高速度で高負荷で、まったく横になることはできません。 ちょっと待ってください - そしてそれは悲しいでしょう。 何をするか？ もう一度、完全なプログラムに従って予約してください。 前の例で説明したことはすべて実行しましたが、さらにもう少し実行しました。 理想的な世界、そして私たちのインフラストラクチャーは IaaC Devops のすべての概念に従っています。 つまり、すべてが git にあり、ボタンを押すだけです。

何が欠けている？ 53 - 演習。 彼らなしでは不可能です。 私たちにとってすべてが完璧であるように思えます。私たちは通常、すべてを制御下に置いています。 私たちがボタンを押すと、すべてが起こります。 たとえそうであったとしても、そして私たちはそのようには起こらないことを理解していますが、私たちのシステムは他のいくつかのシステムと対話します。 たとえば、これはルート 3 からの DNS、SXNUMX ストレージ、いくつかの API との統合です。 この推測的な実験ではすべてを予測することはできません。 そして、実際にスイッチを押すまで、それが機能するかどうかはわかりません。

おそらくそれだけです。 怠けたり、やりすぎたりしないでください。 そしてアップタイムがあなたとともにありますように!

出所： habr.com