LOST によって sophiagworld

この記事には、エンジニアが何百万ものユーザーがアクセスする大規模なサービスを扱うのに役立つ一般的なパターンがいくつか含まれています。 

著者の経験では、これは完全なリストではありませんが、確かに 効果的な アドバイス。 それでは、始めましょう。

サポート付きで翻訳しました Mail.ru クラウド ソリューション.

エントリーレベル

以下に挙げる対策は比較的簡単に実施できますが、大きな効果があります。 これまでに試したことがない場合は、大幅な改善に驚かれるでしょう。

コードとしてのインフラストラクチャ

アドバイスの最初の部分は、インフラストラクチャをコードとして実装することです。 これは、インフラストラクチャ全体をプログラムでデプロイする方法が必要であることを意味します。 複雑に聞こえますが、実際には次のコードについて話しています。

100 台の仮想マシンの導入

• Ubuntuを使用した場合
• それぞれ 2 GB RAM
• 次のコードがあります
• これらのパラメータを使用して

バージョン管理を使用して、インフラストラクチャへの変更を追跡し、すぐに元の状態に戻すことができます。

私の中にある現代主義者は、Kubernetes/Docker を使用して上記のすべてを実行できると言っていますが、それは正しいです。

さらに、Chef、Puppet、または Terraform を使用して自動化を提供できます。

継続的な統合とデリバリー

スケーラブルなサービスを作成するには、プル リクエストごとにビルドおよびテスト パイプラインを用意することが重要です。 テストが非常に単純であっても、少なくとも、デプロイしたコードがコンパイルされることを保証します。

この段階では毎回次の質問に答えます。 私のアセンブリはコンパイルされてテストに合格しますか? それは有効ですか? これはハードルが低いように思えるかもしれませんが、多くの問題を解決します。

このダニを見ることほど美しいことはありません

このテクノロジーについては、Github、CircleCI、または Jenkins を評価できます。

ロードバランサ

したがって、ロード バランサーを実行してトラフィックをリダイレクトし、すべてのノードに均等な負荷がかかるようにするか、障害が発生した場合でもサービスが継続されるようにします。

通常、ロード バランサーはトラフィックを適切に分散します。 ベスト プラクティスは、単一障害点を作らないようにオーバーバランスにすることです。

通常、ロード バランサーは使用するクラウドで構成されます。

リクエストの RayID、相関 ID、または UUID

次のようなメッセージが表示されるアプリケーション エラーに遭遇したことはありませんか。 「何か問題が発生しました。 この ID を保存してサポート チームに送信してください。」?

一意の識別子、相関 ID、RayID、またはそのバリエーションは、ライフサイクル全体にわたってリクエストを追跡できるようにする一意の識別子です。 これにより、ログ内のリクエスト パス全体を追跡できるようになります。

ユーザーがシステム A にリクエストを送信し、次に A が B に連絡し、B が C に連絡してそれを X に保存し、その後リクエストが A に返されます。

仮想マシンにリモート接続してリクエスト パスをトレースしようとすると (そして、どの呼び出しが行われているかを手動で関連付けようとすると)、気が狂ってしまうでしょう。 一意の識別子を持つと作業がはるかに楽になります。 これは、サービスが成長するにつれて時間を節約するためにできる最も簡単な方法の XNUMX つです。

平均レベル

ここでのアドバイスは以前のアドバイスよりも複雑ですが、適切なツールを使用すると作業が容易になり、中小企業でも投資収益率が得られます。

集中ログ

おめでとう！ 100 台の仮想マシンをデプロイしました。 翌日、CEO がやって来て、サービスのテスト中に発生したエラーについて苦情を言いました。 上で説明した対応する ID が報告されますが、クラッシュの原因となったマシンを見つけるには 100 台のマシンのログを調べる必要があります。 そしてそれは明日のプレゼンテーションまでに見つけなければなりません。

これは楽しい冒険のように聞こえますが、すべての雑誌を XNUMX か所で検索できることを確認するのが最善です。 私は、ELK スタックの組み込み機能を使用して、ログの一元化の問題を解決しました。ELK スタックは、検索可能なログ収集をサポートしています。 これは、特定のジャーナルを見つける問題を解決するのに非常に役立ちます。 ボーナスとして、グラフやその他の楽しいものを作成することもできます。

ELKスタック機能

監視エージェント

サービスが起動して実行されるようになったので、サービスがスムーズに実行されることを確認する必要があります。 これを行うための最良の方法は、複数回実行することです エージェント、並行して動作し、動作することと基本的な操作が実行されることを確認します。

この時点で次のことを確認します 実行中のビルドは快適で、正常に動作します.

小規模から中規模のプロジェクトの場合、API の監視と文書化には Postman をお勧めします。 しかし、一般的には、障害がいつ発生したかを知り、タイムリーに通知を受け取る方法を確保したいだけです。

負荷に応じた自動スケーリング

とてもシンプルです。 リクエストを処理している VM があり、メモリ使用量が 80% に近づいている場合は、リソースを増やすか、クラスターに VM を追加できます。 これらの操作の自動実行は、負荷時の弾性力の変化に優れています。 ただし、費やす金額には常に注意し、適切な制限を設定する必要があります。

ほとんどのクラウド サービスでは、より多くのサーバーまたはより強力なサーバーを使用して自動スケールするように構成できます。

実験システム

アップデートを安全にロールアウトするための良い方法は、1% のユーザーに対して XNUMX 時間何かをテストできるようにすることです。 もちろん、そのようなメカニズムが実際に動作しているのを見たことがあるでしょう。 たとえば、Facebook は、視聴者の一部を異なる色で表示したり、フォント サイズを変更したりして、ユーザーが変化をどのように認識するかを確認します。 これをA/Bテストと呼びます。

新しい機能をリリースする場合でも、実験として開始してから、どのようにリリースするかを決定することができます。 また、サービスの低下を引き起こしている機能に基づいて構成を「記憶」したり、その場で変更したりすることもできます。

上級レベル

ここでは、実行するのが非常に難しいヒントを紹介します。 おそらくもう少しリソースが必要になるため、中小企業はこれを管理するのが難しいでしょう。

ブルーグリーン展開

これを私は「Erlang」展開方法と呼んでいます。 Erlang は、電話会社が登場したときに広く使用されるようになりました。 電話のルーティングにソフトスイッチが使用され始めました。 これらのスイッチ上のソフトウェアの主な目的は、システムのアップグレード中に通話が切断されないようにすることでした。 Erlang には、前のモジュールをクラッシュさせることなく新しいモジュールをロードする優れた方法があります。

この手順は、ロード バランサーの存在に依存します。 ソフトウェアのバージョン N があり、バージョン N+1 を展開するとします。 

あなた できた サービスを停止し、ユーザーにとって適切なタイミングで次のバージョンをロールアウトし、ダウンタイムを発生させます。 しかし、あなたが持っていると仮定してください 本当に 厳格な SLA 条件。 つまり、SLA 99,99% はオフラインにできることを意味します のみ 年間で52分短縮されます。

このような指標を本当に達成したい場合は、同時に XNUMX つのデプロイメントが必要です。 

• 今あるもの（N）。
• 次のバージョン (N+1)。 

回帰を積極的に監視しながら、トラフィックの一部を新しいバージョン (N+1) にリダイレクトするようにロード バランサーに指示します。

ここでは、正常に動作する Green N デプロイメントを示します。 このデプロイメントの次のバージョンに移行しようとしています

まず、非常に小さなテストを送信して、N+1 デプロイメントが少量のトラフィックでも機能するかどうかを確認します。

最後に、デプロイが完了するまで最終的に実行される一連の自動チェックがあります。 もし、あんたが とてもとても 注意してください。悪いリグレッションが発生した場合に迅速にロールバックできるように、N デプロイメントを永久に保存することもできます。

さらに高度なレベルに進みたい場合は、Blue-Green デプロイメントのすべてを自動的に実行させます。

異常の検出と自動軽減

ログを一元化し、ログを適切に収集している場合は、すでにより高い目標を設定できます。 たとえば、障害を積極的に予測します。 関数はモニターやログで追跡され、さまざまな図が作成されます。何が問題になるかを事前に予測できます。

異常が検出されると、サービスが提供するいくつかの手がかりの調査を開始します。 たとえば、CPU 負荷の急増はハード ドライブの故障を示している可能性があり、リクエストの急増はスケールアップが必要であることを示している可能性があります。 この種の統計データにより、サービスをプロアクティブに行うことができます。

これらの洞察を利用すると、あらゆる次元でスケールし、マシン、データベース、接続、その他のリソースの特性を積極的かつ事後的に変更できます。

それだけです！

この優先順位のリストは、クラウド サービスを構築する場合に多くの問題を回避します。

元の記事の著者は、読者にコメントを残して変更を加えるよう呼びかけています。 記事はオープンソースとして配布され、著者によるプルリクエストが行われます。 Githubで受け付けます.

このトピックに関して他に読むべきもの:

1. Go と CPU キャッシュ
2. 著作権侵害の精神を備えた Kubernetes と実装用のテンプレート
3. Telegram の Kubernetes に関する私たちのチャンネル

出所： habr.com