Okdeskクラウドサービスの開発を開始したとき、同じアプローチから進めました。 この製品は、「最小限の実行可能なインフラストラクチャ」、つまりアプリケーションとDBMSがインストールされた西部のデータセンターの仮想マシンに光を当てました（時間が経つにつれて、検索エンジンは隣接する「仮想マシン」に移動しました）。 このファームの周囲では、ping-adminおよび別のプロバイダーのクラウドへの定期的なバックアップを介して最小限の監視が構成されていました。
記事では、移動の理由、データセンターの切り替え方法の選択、データセンターの選択と最初の結果について。
このインフラストラクチャを使用して、「転倒なし」を管理し、99.97％ （計画を含む年間2時間のダウンタイム）でサービスの可用性を示しましたが、 「ブレーキ」または「ダウンタイム」に関する苦情は常に受けませんでした。 」
しかし、顧客ベースの成長に伴い、仮想マシンの収益とパワーが増加しただけではありません。 成長と緊張。 夢はどんどん落ち着きを失い、子供と一緒に散歩中、内務官はインフラの問題に関する電話での信号を待っていました。 Okdeskのアクティブな顧客の数が100に近づくと、そのように生きることは不可能であることが明らかになりました。 「最低限実行可能なインフラストラクチャ」は使い果たされています。深刻なインフラストラクチャの問題により、単純なサービスは2時間以上かかる可能性があります。 そして、1つのこと-サーバーが10個のクライアントに対して2時間「嘘をつく」場合と、まったく別のこと-何百人もアクセスできない場合。 最初のものはどうにか生き残り、2番目のものはサービスのパフォーマンスよりも評判を回復するのがはるかに困難になります。
そこで、Okdeskにより信頼性の高いインフラストラクチャを実装することにしました。 そして、それが何から来たのか...
最初にビジネス要件
クラウドサービスインフラストラクチャの設計を開始する場所 いいえ、現代のアプローチと技術の研究ではありません:)ビジネス要件の定義から始める必要があります。
Okdeskは、サービスビジネスで顧客の要求を管理するためのSaaSです。 そして、それは消費者にとってビジネスに不可欠なシステムを意味します。 これに基づいて、次の要件を策定しました。
- データセンターに問題がある場合（ローカル-特定のサーバーに障害が発生した場合、およびグローバル-データセンター全体へのアクセスが消失または低下した場合）、クライアントから見た非アクティブ時間は15分を超えてはなりません。 メインデータセンターの問題を解決するときに、生産性のわずかな低下が許容されます。
- 事故の場合、その結果として本番DBMSが回復不能に失われるため、事故の数秒以上前にクライアントデータが失われることは許可されません。
上記の2つの要件は、インフラストラクチャの設計と最終的なソリューションの選択の指針となりました。
実装要件から
一般的なアプローチ
私たちは車輪の再発明を開始しませんでした。最初のステップでは、次のアプローチを採用しました。 メインデータセンターでは、アプリケーションとDBMSが2つの物理サーバーにインストールされます。 バックアップデータセンターには、DBMSとアプリケーションを備えた1つの物理サーバーがあります。 データレプリケーションは、バックアップデータセンターのDBMSとメインデータセンターのDBMSの間で構成されます。 メインデータセンターで事故が発生した場合、トラフィックをバックアップデータセンターにリダイレクトします（次のセクションを参照）。計画に従ってトラフィックを切り替える時間は5分を超えてはなりません（トラフィックを切り替える決定は人によって行われるため、この5分には時間が含まれません）事件に対する反応）。
次のステップでは、アプリケーションの負荷がより強力なサーバーを必要とする場合（計算によると約4〜6か月後）、クラスターモデル（アプリケーションとバランサー+ノード）に移行する予定です。 1つの強力なサーバーを使用できますが、安価です。 ただし、1つの大きなサーバーで障害が発生した場合、トラフィックをバックアップデータセンターに切り替える必要があります（数分間サービスが利用できなくなります）。 しかし、バックアップデータセンターでは、すべてが正反対です。 成長するにつれて、バックアップサーバーの容量を増やす予定です。メインデータセンターとバックアップが同時に「落下」するリスクは最小限であるため、少しの節約でも問題ありません。
データセンターを切り替える方法は？
わかったように、ドメイン名に割り当てられたIPアドレスの高速切り替えを整理する最も一般的な方法は3つあります。
- VRRP
- TTLが短いDNSホスティング業者
- Webサービス（cloudflareなど）。
それぞれの方法の長所と短所について説明しましょう。
VRRP
長所：
-高速スイッチング。
-低コスト。
短所：
-すべてのデータセンターで提供されるわけではありません。
-変更が必要な場合、データセンターによって構成され、プロセスが遅れる場合があります。
-予約がどの程度うまくいっているかは明確ではありません。
TTLが短いDNSホスティング業者（たとえば、Amazonのroute53）
長所：
-作業の論理を完全に制御。
-低コスト。
-ゾーンが委任される複数のDNSサーバー：冗長性について話すことができます。
短所：
-一部のDNSサーバーは、ゾーン所有者から送信されたTTLを無視します。 情報によると、このような永続的なサーバーの数は非常に少ないです。 しかし、それらはそうです（つまり、すべてのユーザーがIPを切り替えてもすぐに動作できるわけではありません）。
Webサービス（例としてのCloudflare）
長所：
-簡単なセットアップ;
-IPアドレス間のほぼ瞬時の切り替え。
短所：
-別の理論的な故障点が表示されます。 私たちの観点から、この点で、条件付きクラウドフレアはAmazon dnsまたはvrrpよりも失敗する可能性が高くなります。
-なぜなら サービスへのすべてのリクエストはcloudflareを経由し、ユーザーは主にCISにいます。これにより、サーバーからの応答時間が長くなります。
その結果、Amazonからルート53で停止することにしました。 解決策は完璧ではありませんが、常に何かを犠牲にしなければなりません。 同時に、他の可能なオプションの研究を続けます。
モニタリング
歴史的な理由により、当社の監視は次のコンポーネントで構成されています。
- Ping-admin-指定されたアドレスにhttp要求を行う方法を知っており、応答に問題がある場合は、指定された番号にSMSと呼び出しを送信します。 安価で簡単にセットアップできます。 開始時の最小監視としては悪くないので、開始したばかりで、サービスが機能しているかどうかを常に知りたい人にアドバイスできます。
- Monit-サーバーにインストールされ、空き領域の量、CPU負荷、空きRAMのサイズなどの基本的な指標を監視します。 無料ですが、UNIXシステムに関する最小限の知識とマニュアルを読む能力が必要です。
- Scoutapp-パフォーマンスとプログラムコードのボトルネックの観点からアプリケーションをプロファイリングします。 さまざまなタイムスライスのデータを分析し、個々のクエリを解析できます。
- クライアントサーバーユーティリティ（monitの後に表示される）は、多数のサーバー特性を制御し、ビジネスパラメーター（たとえば、一定期間にわたるデータベース内の新しいオブジェクトの数）の変更を制御でき、美しいグラフを描画して通知を送信できます。
監視の一部の機能は複製されますが、これはおそらく、優れていると劣る場合です。
データセンターの選択
データセンターを選択する際、次の要件から進めました。
- ロシアのサイトの存在（個人データの保護に関する法律を遵守するため）;
- 一般に少なくとも2つのサイトの存在。
これらの要件に基づいて、 SelectelとServersを選択しました。
各プロバイダーには長所と短所があります。
セレクター：
長所：
-専用サーバーの幅広いラインアップ。
-リーズナブルな価格。
-市場で長年、多くが追加します。 サービス（たとえば、Servers.ruにないvrrp）。
-Vkontakteはクライアントの1つです。これにより、プロバイダーがテクノロジーの最前線に立つように動機付けられることが期待できます。
短所：
-最近、私たちは、安定性の問題に関する知人や同僚からの多くのメッセージを観察しています。
サーバー：
長所：
-複数の国のデータセンター、異なるDCのサーバーを「すぐに使える」1つのネットワークに結合できます（つまり、これは追加サービスではありません）。 これまでのところ、CISでの主な事業と外国DCの存在はそれほど重要ではありません。 しかし、近い将来、他の市場に参入する予定であるため、あるプロバイダーのインフラストラクチャを使用することは大きな助けになります。
-新しいブランドのサーバーDell。
-サポート（回答はすぐに届きます）と販売（たとえば、問題なく標準構成の変更に同意できるディスクまたはメモリの追加）の両方で、柔軟性と顧客重視。
短所：
-サーバー構成には大きなギャップがあります。 したがって、たとえば、最も単純な構成には、4つのコアを持つ1つのプロセッサと、16のコアを持つ次の2つのプロセッサが含まれます（価格の2倍の差があります）。
-ceteris paribus、価格は高いです。
その結果、サーバーを選択しました。これは、不安定な運用のリスクと比較して、絶対的な観点でのホスティング価格の差がわずかであることが判明したためです。
中間結果
移動の結果、私たちは落ち着いて眠り始めただけでなく、パフォーマンスを大幅に改善しました。 たとえば、平均応答時間は4倍減少しました
Okdeskのお客様は、データの安全性と可用性について引き続き心配する必要はありません。
psの記事の一部として、インフラストラクチャの技術的な側面については掘り下げませんでした。 技術的ソリューションの選択は、ビジネス要件に基づいて行う必要があることを強調したかったのです。 可能であれば、技術的な側面に関する質問にコメントで回答します。