早期のアーキテクチャ最適化

ITSummaのEugene PotapovとAnton Baranovは、予定よりも早く最適化について話します。 これは、 Highload ++レポートの転写です。



24時間体制のサポートとWebサイトの管理に取り組んでいます。 2008年からイルクーツクで活動しています。 現在、スタッフは50人です。 イルクーツクのメインオフィス、サンクトペテルブルクとモスクワにオフィスがあります。 現在、200を超えるアクティブなクライアントがおり、1日あたり100を超えるアクティブなチャットが行われています。 お客様の問題について、月に約15万件のアクティブなアラートを受け取ります。 クライアントには、さまざまな企業があります。有名な企業は、Lingualeo、AlterGeo、CarPrice、Habrahabr、KupiVip、Our Ra​​dioです。 多くのオンラインストアがあります。 私たちの職業：私たちは、災害が発生したという事実に15分以内に対応し、迅速にそれを修正しようとする必要があります。

トラブルの原因はどこにあるのか、これらの問題はサーバーにありますか？

• 主な理由は、アプリケーションの新しいバージョンです。 サイトの新しいバージョンを投稿し、コードを更新しました-何かが壊れ、すべてが機能しなくなったので、修正する必要があります。
• 2番目は、負荷とスケーリングの増加に関連する問題です。 または、これは非常に急速に成長しているプロジェクトであり、あなたはそれについて何かをする必要があります。 それとも、マーケティングキャンペーンを企画したプロジェクトですか。ブラックフライデー、多くの人が来て、準備ができていなかったため、すべてが故障しました。
• 統計的に事故の3番目の原因は非常に興味深いです。 これらは、プロジェクトアーキテクチャの計画におけるエラーによる事故です。 つまり、発生した問題は、コードのエラーではなく、トラフィックが来てすべてが落ちたためではなく、プロジェクトのアーキテクチャがエラーにつながるように設計されたためです。

アーキテクチャ計画エラー

他の業界を見ると、今日では建物の建設後に崩壊することはありません。 これが発生した場合、それは非常にまれです。 水道管を敷設した後、すぐに破損することはありません。 ITでは、これは頻繁に起こります。 いくつかのアーキテクチャが構築されており、リリースされたときに、以前の条件に適合しないか、非常に長い時間がかかる、または他の問題が発生することがわかりました。



IT業界自体は非常に新しいものであり、古い慣習はありません。また、新しいソリューションはさらに複雑になり、これらのソリューションの運用の信頼性が低下します。 ソリューションが複雑になるほど、運用が難しくなります。



いわゆるルサー法があります。 1940年代、ドイツは英国でV-2ミサイルを発射しました。 確かに飛んだ人もいなかった人もいました。 彼らは理由を調査することにしました。 多くの異なるコンポーネントがあり、このシステムを複雑にすると、システムの複雑さ（つまり、耐えられないリスク）は、システムがクラッシュする可能性ではなく、このシステムの可能性ではないことが判明しました。このシステムのコンポーネントの一部ではなく、各コンポーネントのリスク確率の積です。







1つのコンポーネントに関連する事故の確率が5％で、他のコンポーネントが20％の場合、全体的なリスクは20％ではなく24％になります。 すべてが非常に悪いでしょう。 コンポーネントの数が多いほど、問題が多くなります。

複雑さを作成する理由

オフラインシステムを構築し、「今、それをより難しくする方法を考えます」と言うエンジニアを毎日見かけるわけではありません。 そして、開発中、運用中、人を交代したり、新しいチームに参加したりするときに多くの状況が見られ、それがなぜ面白いのかを除けば、なぜこれが行われたのかはっきりしないシステムがあります。

• 最初のオプションは、この問題に対する独自のソリューションです。 この問題を解決する方法、対処方法はどこにもありません。 私たちはそれを解決する方法を見つけ始め、熊手を踏んで、これをやり直す必要があることを理解しています。
• 解決策が存在することもありますが、それはわかりませんが、見つける方法はありません。 彼らは航空機業界のエンジニアで長い間勉強しており、ITのテクノロジーは急速に変化しているため、大学は実績のある既製のプラクティスを準備することができません。 私たちはすべてを新たに研究しなければなりません。 時々、既に実装されていて、知られていないある種のソリューションを作成するときに、すべてを新たに思い付くことがあります。 したがって、システムは複雑であり、システムを危険にさらすとすべてが悪くなります。
• 非常に頻繁に発生する興味深いケース。 ITは、人々が仕事に非常に興味を持っている数少ない職業の1つです。 あなたが試すことができる非常に興味深い技術がたくさんあります、あなたが見たい多くのことがあります。 たとえば、プロジェクトにdockerを挿入してみましょう。 多くの人が、どこでそれを試すべきかを正確に把握しようと試みています。 その結果、純粋に興味のない解決策を試したいという欲求は、特定の困難を生み出します。 たとえば、配管工がパイプを敷設することは考えていません。多分私はそれを4回ラップするでしょう、突然水がまだ蛇口に行くのだろうかと思います。 IT部門では、これを頻繁に見ます。

その結果、このソリューションまたはそのソリューションを作成するとき、すべてがクールになると思いますが、はるかに複雑になることがわかります。







私たちが人生から見た例に基づいて、私たちは私たち自身の実践を望んでいます。 物事を踏んではならないことと、それと一緒に暮らす方法を助けようとする。



プロジェクトの開発を3つのカテゴリに分けて検討してください。 つまり、彼は最初から、彼が非常に小さいとき、またはプロジェクトのアイデアが、国中、世界中で知られているある種の大きな負荷の高いプロジェクトに発展しているとき、どのようになっていますか。



プロジェクトを作成するとき、原則として、25人の加入者がいるソーシャルネットワークでの最初の広告キャンペーンの開始後、トラフィックは3000〜5000 RPSになると想定します。

能力がこの出席に耐えられるように、何らかの形でこれに備える必要があります。 ここで、マーケティング担当者が隅々にあるクラウドについて語るのは、何の意味もありません。 クラウドは非常に信頼できます。 これはとても良いことです。 文字通りどこでも聞こえます。



この神話を払拭するために、アップタイムAmazonの統計を引用しました。







Amazonのクラウドは、世界で最も急速に成長しているものの1つであり、最大のものの1つでもあります。 ご覧のとおり、この世界には理想的なものはありません。 Amazon'aでさえ、何らかの理由で失敗しています。



クラウドはスケーラブルであると常に言われています。 1 GBから1コアから多数のコア、GBメモリのヒープまで、1つのコアからプロジェクトのあるサーバーを簡単に拡張できます。 実際、クラウドは他のすべてのものが配置されているように物理マシン上に配置されているため、これはすべて神話です。 制限があり、このマシンのRAMの量とこのマシンのコアの数で構成されます。 遅かれ早かれ、クラウドでは必要なサイズに拡張できないという事実に遭遇します。 プロジェクトの最も理想的なオプションは、立ち上げ時であっても、この世界でこれほど信頼性が高くシンプルなものを思い付かない、別個の専用サーバーです。 今では鉄は非常に安価であり、少しのお金であなたはかなり良い専用サーバーを買うことができます。

専用サーバーにはどのような問題がありますか？

ある時点で、プロジェクトが成長しており、ロードを待っていることを理解しています。 私たちは、発生する質問に直面しています。 これは、プロジェクトの水平スケーリングと冗長性です。 メインサーバーがクラッシュした場合でも、プロジェクトが引き続き機能することを確認する必要があります。

そのような場合はどうしますか？

複数のWebインスタンス間のプロジェクトトラフィックのバランスを取ります。 また、複製され、負荷が分散される複数のデータベースサーバーインスタンスを作成します。



この場合の主な間違いは、すべてのWebサービスが同じラックにあることです。 つまり、1つの例外を除いて、すべてに対して保証された複数の物理Webサーバーがあります。 これはすべて1つのデータセンターにあり、ほとんどの場合、同じラック内にあります。 もちろん、データセンターが落ちた場合、これは何に対しても保護しません。



この場合、バックアップインスタンス、バックアップサーバーは別のデータセンターに配置する必要があると判断します。 理解しなければならない2番目の議論の余地のない真実。 何らかのイベントが発生したときにトラフィックを使い果たすことができるバックアップインスタンスがある場合、バックアップがあることはわかりません。 理解するべき最も重要なことは、仮想化は苦痛の軽減よりも痛みであることです。 原則として、仮想化には具体的な問題があるため、それらを操作することはお勧めしません。







複数のデータベースサーバーインスタンスを使用する場合、どのような問題がありますか？

最も一般的な問題は、たとえば、マスターへの書き込みがある場合、スレーブからの読み取りです。 マスターに何かを書いたとき、その時点でアプリケーションはスレーブから何かを読みましたが、変更はまだ複製されておらず、スレーブはマスターに何かを書いたことをまだ知りません。 この場合、スレーブから無関係なデータを取得します。



この場合、次のものが必要であることを理解します。

• レプリケーションステータスの監視（機能するかどうか）
• レプリケーションの遅延を監視し、レプリケーションが存在する状況がありますが、ニュアンスと要因により、1日以上の遅延があります
• レプリケーションの一貫性の監視（スレーブ上のデータとマスター上のデータが一致する）

同期レプリケーションは、すべてが正常であることを確信するための十分な基盤ではありません。



一般に、データの完全性に問題があるため、何かをマスターに書き込んでからスレーブで読み取るという考えは、完全に良いとは言えません。 しかし、私たちはしばしばこれを見るので、どういうわけかそれを避けたいです。



複数のWebノード間のWebプロジェクトで負荷分散を使用する場合、さまざまな問題が発生する可能性があります。 たとえば、単一のロードバランサーが入力ポイントとしてよく使用されます。つまり、Aレコードがそれをポイントし、それを通るトラフィックはWebノード間でバランスが取られます。 この場合、バランサーが障害ポイントです。 Webノード間で負荷のバランスを取る人がいないため、プロジェクトが崩壊するとプロジェクトは崩壊します。



そのような繊細で繊細な瞬間があります。 Webノード間のトラフィックバランシングは、フェイルオーバーを考慮して設定する必要があります。 つまり、バランスを取るときに、バランスを実行するアプリケーションは、Webノードの1つが失敗した場合に常にWebノードをポーリングし、バランスプロセスから除外する必要があります。 そうしないと、プロジェクトの半分がロードされ、半分がロードされていない場合に、悪い状況になることがあります。 したがって、リソースの半分は3時間前に落ちたWebノードでバランスが取れていました。

ファイルをどうするか？

今日、プロジェクトに関するメディア、写真、ビデオがたくさんあるとき。 すべてのweb-nodに接続され、各web-nodが個別にファイルを操作、書き込み、読み取りできる共通のストレージが必要です。 この場合、彼らは何をしますか？



最もシンプルで最も理解しやすいソリューションはNFSの使用であると思われます。このテクノロジーは長年使用されており、多く使用されています。 同期に問題はなく、セットアップはそれほど簡単ではありません。 多くの場合、彼らはこの技術を使い始めます。



NFSにはグローバルな問題があります。 サーバー間、このNFSがマウントされているNFSマスターWebノード間で接続している場合、接続は切断されます。 または、たとえば、NFSマスターを再起動する必要がある場合、Webノードも再起動する必要があります。 なんで？ なぜなら、マウントがフリーズし、サーバーが物理的に再起動されるまでこの時点では何もできないからです。 これは長年にわたるNFSの問題であり、ユビキタスであり、NFSのフレームワーク内でこれに対する適切な解決策はありません。



別に興味深いトピックは、プロジェクトの展開がどのように編成されるかです。 実際、1〜2台のサーバーがあります。シンプルなgit pull'aのコードと、以前のバージョンのプロジェクトを1か所に保存し、新しいバージョンにデプロイして全員のリンクを変更するシンプルなスクリプトのコードを置くのは簡単です。 しかし、git pullはあまり面白くありません。 CIははるかに興味深いものです。 私たちのクライアントの間では、小さなプロジェクトが必要とするよりも早くCIを実装しようとすることが非常に多くあります。 継続的な統合/配信を備えた高度な展開システムを作成するには、多くのリソースが必要であり、複雑さが増します。



まず、最もよくある間違いは、クールな展開システムです。 人々は新しいコードをアップロードし、1つのボタンでコードをロールバックすることはできません。通常のリレーショナルデータベースを持っている場合、移行の一環として、これらの移行によりデータベースの新しいバージョンが古いコードで動作しなくなる可能性があることを考慮しません。 展開をレイアウトした後、すべてが壊れているため、早急にロールバックする必要があることがわかりました。 古いコードにロールバックしているため、古いコードは新しいデータベースでは機能しませんが、データの書き込みは継続されます。 どうにか生き残るために、新しいバージョンを再び配置しています。古いバージョンのデータがすでに記録されており、新しいバージョンのデータも記録されており、すべてが混同されており、生き方が明確ではありませんでした。 このシステムの作成、実装、および保守にはオーバーヘッドがあります。



実際、新しいシステムを導入していますが、それが機能することを確認する必要があります。 彼女自身がコードを投稿せず、クライアントの一部がそうであったようにwwwrootを空の場所に変えないことを確認してください。 ある種の計算システムを作成し、それが適切に機能することを確認しなかった場合、展開中の追加の複雑さ、実稼働環境への同じロールバック。 ロールバックしたことを確認する方法は？ 時間を選択する必要があり、このプロジェクトがお金をもたらし始め、誰もプロジェクトを危険にさらしたくない場合、誰もがすべてがうまくいくと考え、必要に応じてロールバックできます。 その結果、問題が発生します。ロールバックの可能性を確認し、すべてが機能することを確認する必要があります。 この段階ではシンプルなソリューションに固執し、スクリプトを使用して新しいバージョンのコードをアップロードし、そのまま使用することをお勧めします。



プロジェクトが中規模になり、すでにかなり大きくなったが、大きくもなっていないという事実に至った段階で。 私たちの質問は醸造です。NFSで何をする必要がありますか。



手元にあるものから、これはCEPHです。 それは使用することができます、すべては順調です、レビューは肯定的です。 しかし、CEPH設定のささいなこと、ニュアンス、微妙さがわからない場合、CEPHの構成は非常に複雑です。出力では、このファイルシステムが期待どおりに機能しないという事実に遭遇する可能性があります。 それを扱う方法を学ぶためには、多くの人的資源、多くの時間を費やす必要があります。 したがって、たとえばMOOSEFSなどの軽いものを使用できます。 どうして？



すべてが完璧であり、基本的に構成され、一部のデータがそこに蓄積され、ストレージはファイルの保存のみに予約されているいくつかのうなずきに広がり、すべてがどこにでもマウントされ、すべてが正常に動作し、すべてが正常に動作します。 しかし、突然の停電。 データセンターでメインチャネルが切断され、ジェネレーターがピックアップされましたが、サーバーが切断されないように、必要以上に少し遅れました。

ここで何が起こっていますか？

数十テラバイトの静的データが複数のサーバーに分散しており、停電後、起動後などに相互に同期する必要がある状況があります。 2日が経過し、多くのファイルが考えられます。もう少し待つ必要があると思います。4日が経過し、MOOSEFS同期が90％低下し、再び同期が開始されました。 プロジェクトはすでに静的なしで5日間ですが、これはあまり良くありません。 私たちは問題の解決策を探し始めています。 中国語のフォーラムで問題の解決策を見つけました。スレッド内の3つの投稿は、同様の状況でこのファイルシステムを修正する方法に当てられています。 すべてが中国語で、すべてがわかりやすく、サンプルの設定があり、すべてがよく描かれています。



オンライン翻訳者は少し誤解していますが、ほとんどの場合はすべて順調です。 このようなサポートがあるファイルシステムを使用することはできません。 そのため、私たちは今でもMOOSEFSと協力しており、停電が発生した場合に祈り、泣きます。 代替品を選択する問題は未解決のままです。



この時点で、多かれ少なかれデバッグ済みの展開システムがすでにあります。 スクリプトでも、CIでも、すべて機能します。 ただし、展開エラーがあり、実稼働環境でスリップする場合があります。 コードのバグが原因で、prodが500エラーで横たわっていることがあります。 これは何に関連しているのでしょうか？



たとえば、微妙なニュアンスのために、開発環境と製品環境にデータベースがあります。 データベースのprod環境には10ギガバイトのデータがあり、dev環境には50メガバイトのデータがあります。 たとえば、dev'eでは、私たちが使用しているタブレットには10​​00件のレコードがあり、prod'eでは100万件のレコードがあります。 したがって、リクエストがdev'eで実行されると、100分の1秒で完了し、prod'eでは数十秒かかる場合があります。



もう一つの微妙な点。 開発環境でコードをテストするとき、このコードのテストのみが機能する環境でコードをテストします。 サイドロードはありません。 prod'eには常に負荷がかかります。 したがって、prod'eに負荷をかけずにdev'eで受け取った結果が異なる可能性があることを常に考慮する価値があります。 つまり、新しいコードからの負荷がシステムの総負荷と一致する場合、結果が満足できない場合があります。



また、頻繁に発生します。 すべてが開発者でテストされ、すべてが機能し、データベースが同じであり、すべてが正常であり、すべてが正常に動作し、負荷が揺れないはずです。モジュールまたは拡張機能がインストールされていないため、設定はどこかに記載されていません。さまざまなソフトウェア構成があります。これも検討する価値があります。



これはあまり一般的ではありませんが、発生します。たとえば、スクリプトは1つのコアの開発サーバーで実行されます。たとえば、4 GHzで、すぐに処理され、すべて問題ありません。しかし、多くのprod'eコアがありますが、それらはすべて2 GHzであり、1つのコアでのコードの実行時間はdevサーバーと同じではありません。devサーバーとprodサーバーのハードウェア構成の違いにおけるこのようなニュアンスも考慮に入れ、割引する必要があります。

つまずきはデータベースの負荷が高いことです

これは、私たちの実践で最も一般的なタスクの1つです。データベースの負荷を取り除く方法は？



頭に浮かぶ最初のものは、より強力な鉄を置くことです。より強力なプロセッサ、より多くのメモリ、より高速なディスク、および問題はそれ自体で解決されます。そうでもない。遅かれ早かれ、この鉄にぶつかり、何らかの天井が来るからです。



サーバーの調整。この問題に対する優れた解決策は、プログラマーがシステム管理者のところに来て、データベースサーバーが最適に構成されていないと言うときです。これらの設定を微調整すると、すべてが形成され、リクエストがより速く実行され、すべてが良くなります。

すべての問題は、別のDBMSに切り替えることで修正されます。つまり、たとえば、MySQLの速度が低下します。PostgeSQLに切り替えると、MariaDBに切り替えると、これらの問題をすべてクラスとして修正し、すべてが迅速に、完全に動作するようになります。探すべき問題は、DBMSを調べることではなく、論理的に深く掘り下げることです。

つまずきのブロックを理解するために何をしているのでしょうか？

データベースがかなり大きな負荷を生成し始め、鉄が対処できない理由は何ですか。どのリクエストが最も長く実行されるかを理解し始めるために、統計を収集する必要があります。リクエストを分析するために、リクエストのプールを蓄積しました。一般的な機能などを識別するためのクエリを作成します。



クエリの数に関する統計をコンパイルすることも必要です。たとえば、真夜中までにデータベースを3から4にスローダウンするだけの場合、おそらく現時点でインポートが発生し、データベース内の挿入数が桁違いに増加します。データのクラスタリングも検討する価値があります。鮮明な例として、統計を含む表があります。昨年保存されたとしましょう。私たちは常にサンプルを作成しています。これらのサンプルの95％は先週にのみ関係しています。おそらく、このテーブルのデータをクラスター化して、それぞれが特定の月のデータを保存する12の異なるラベルを作成するのが理にかなっています。この場合、選択を行うとき、1つのプレートからデータを取得し、条件付きで12倍少ないレコードがあります。

最も興味深いのは、大規模なプロジェクトで何が起こるかです

よく見られる技術的なエラーはありませんが、いくつかの傾向があります。このプロジェクトは成長しました。私は実験したいと思っています。すべてを単独で動作させたいのです。



私たちが最初に目にするのは、新しい技術に対する技術専門家の愛です。プロジェクトは大きく、すべてが明確に機能し、タスクは定期的です。本当に新しいものを思いつきます。人々は働きたいので、興味がありました。技術サポートチャットゲームでは、人々が何らかの技術を使用したいが、何に使用するのかわからないという、いくつかの引用があります。プロジェクトでdockerとconsulを使用します。 docker'yにサービスを分散させ、領事を通じて誰がどこに行くかを理解します。領事をドッカーの1つに入れます。領事が倒れた場合、すべてを失いますが、あなたはそれと一緒に暮らすことができます。

chefのみを使用して設定を更新しましょう。設定を急ぎ、chefクライアントが落ちた場合、chefクライアントを最初に設定する必要がありますが、設定を一元的に更新できます。ただし、サーバー上で何かを個別に更新することは困難ですが、それは良いことです。



クラスターを作りましょう。これは、人々が何かからクラスターを作りたいときに面白いジョークです。RabbitMQのクラスターを作成して、そこからデータを読み取りましょう。すべてがフォールトトレラントになります。RabbitMQのいずれかがクラッシュした場合、2番目のRabbitMQが生きます。実際には存在しますが、心配する必要はありません。

新技術への愛

テクノロジーにテクノロジーを使用することはできません。ある程度停止しますが、停止しないと確信しています。なぜなら、私たち全員が新しいことを試してみたいと思うからです。



大規模なプロジェクトでは、単純なアクションははるかに複雑になります。新しいソフトウェアを常に使用したいことがわかっている場合、1つのサーバーで問題がなかった古いプロジェクトの場合、新しいサーバーではすべてを更新するのは難しく、2時間もかかりませんが、特に数週間かかることがあります、それを更新する方法を考え出したよく調整されたチームではなく、開発者が本番環境でこれを行うことにした場合。



ファッショナブルになりつつある2番目の痛みを伴うことは、自動化が機能し、管理者が必要ないという信念です。クラスターはフォールトトレラントであり、すべてのWebサーバー間でバランスを取り、ロードバランサーが機能します。アマゾンウェブサービスでこれを行うと、リージョン全体が低下し、すべてのバランサー、すべてのインスタンスが低下し、すべてが悪化します。



「事故が発生した場合、それ自体のバランスを取り直します。」自動バランス調整を行うときに頻繁に発生することは、ある場所から別の場所にスローする必要があるという事実につながりますが、何らかの理由で、すでにスローダウンしている同じコードにスローされるか、すべて一緒にスローダウンするインスタンス間でスローされ始める、またはどこにもありません。プロジェクトは、存在しないシステムに入り始めます。



当社の技術スタックは、この状況を完全に排除します。 stackoverflow、reddit'e、Habrahabrについて読んだソリューションは嘘をつきません。



ちょうど2年前、多くの企業がOpenStackを使用することを望んでいたOpenStackの使用に関するレポートをここで作成しました。便利に。残念ながら、インスタンスを起動して削除する当時のOpenStackでは、その後、いくつかのOpenStackデーモンを再起動するまで起動または削除しないことはできません。



これがどの時点で起こるのか興味がありました。動作するものとしないものがあります。OpenStackが私たちにとってうまく機能していると言った人たちは、フルタイムで4人をサポートしています。彼らは定期的にOpenStackが動作することを確認し、動作しない場合はすぐに修復を開始します。この技術またはその技術が機能すると言う人々は、この技術を使用するのに十分なリソースを持っているか、この技術が壊れて信じることができないか、それからお金を稼ぐかもしれません港湾労働者は巨大な投資を取得します。

それと一緒に暮らすには？

私は、それ自体が落ちないかもしれず、どういうわけか壊れず、それ自体が再調整されると信じないことを好みます。さらに、私たちは偏執症になる方法について助言することはできません。



大規模プロジェクトの作業で非常に興味深いこと。計算は継続的であり、ビジネスは絶え間ない変更を望んでいます。私たちは生きる良いプロジェクトを作りました。遅くするものはあまりないので、定期的な最適化を忘れています。いずれかの計算のクライアントの1つは、最終的に1つのページで8,000のSQLクエリを生成する計算を行いました。



頻繁な展開。それらは非常にプライベートであるため、変更は表示されません。



実際には何が得られますか？







過去数時間のチャートを見ると、3つの展開がありました。最初の展開ではほんの少しで、450ミリ秒の回答に300ミリ秒が追加され、次の展開ではさらに240ミリ秒が追加され、次の展開では既に合計650ミリ秒になりました。

私たちはすでに2番目の答えを得ました、すべてが悪いです

大規模なプロジェクトでは、最終的にすべてが本番環境で実行されるかどうかをチェックしません。展開のテストだけでなく、何らかのテストで負荷を増やします。実際、多くの人がこれを行い、その方法を学びたいと思っていますが、実際にそれを行う人はほとんどいません。多くの大規模プロジェクトが、少なくともメジャーバージョンのコード計算をロードテストすることを学べば、クールです。

結論の代わりに

• すべてが新しいというわけではありません。
• 興味深いものすべてが必要というわけではありません。
• すべてのクールな機能が役立つわけではありません。

多くの知恵には多くの悲しみがあります。なぜなら、新しいテクノロジーはクールだからです。時々、新しいものを恐れてはいけません。



大規模プロジェクトでの展開における妄想の追加。トラフィックが多い場合、展開をテストする機会がありますか？新しいコードをサーバーにロールアウトすると、条件付きで10％の訪問者の一部を誘導し、ユーザーがボタンを突くなどの事実から急激な負荷ピークがあるかどうかを確認できます。クライアントの分離を行い、フォーカスグループとして一部を送信する場合、新しいコードに送信します。これは非常に広く使用されており、クライアントの主要部分のかなりの問題を回避するのに役立ちます。 100％よりも10％でテストする方がはるかに優れています。





エフゲニー・ポタポフとアントン・バラノフ-早期のアーキテクチャ最適化