Web開発者であり、非常勤のシステム管理者である旧友を覚えていますか？ :) 5月22日に、彼は他の多くの読者と同様、
セミナー「負荷の高いWebプロジェクトの開発：1日あたり何百万ものヒットに耐え、すべてが機能し何も起こらないようにする方法」に参加しました。
その後、私たちに思われるように、彼が生きるのは少し簡単になり、大きな「重い」プロジェクトの開発と保守がより理解しやすくなりました。
* * *
セミナーの登録のほぼ半数（および、明らかに学生自身）はHabrからでした。 トピックが需要にあったことを非常に嬉しく思います。
個人的にもツイッターでも、多くの人がプレゼンテーションやビデオを公開するかどうか尋ねました...
はい、もちろんです！
すべての資料を皆様と共有できることを嬉しく思います！
1.「高負荷Webサービス開発プラットフォーム：デバッグツールとスケーラビリティ」 （Alexander Demidov、1C-Bitrix）
Webプロジェクトの垂直スケーリング（既存のサーバーのメモリ、CPU、ディスクを増やすことによる）の可能性は、物理的な特性によって常に制限されます。 そして遅かれ早かれ、開発者は水平スケーリングを実装するという課題に直面します-複数のサーバーにプロジェクトを分散させること。 従来のWebサイトはこのために設計が不十分です。ほとんどの場合、水平スケーリングはプロジェクトコードの改良を意味します。 レポートでは、開発プラットフォームでスケーラビリティを直接提供し、それによってWeb開発者の作業を楽にする方法を説明します。 さらに、潜在的なボトルネックのデバッグ、監視、および検索ツールをサイト内で直接使用できること、外部サービスを補完する方法を検討します。2.「負荷の高いプロジェクトのシステムランドスケープの構築」 （Vitaly Gavrilov、「Lenvendo」）
負荷の高いインターネットプロジェクトの可用性を確保するシステムランドスケープの構築に関するアクションプランと専門家のアドバイス：
- ハードウェア、選択する理由と理由。
- スケーラブルなソリューションを構築するためのオプション。
- データベースの負荷分散とフォールトトレランスを確保するための手法。
- ネットワークトラフィックの分散の例。
- バックアップ。
3.「負荷の高いWebプロジェクトの開発における負荷テストのための独自の方法論の適用」 （Mikhail Tokovinin、QSOFT）
- QSOFTの負荷テスト方法
- 開発段階でのプロジェクトの調整と最適化
- 設計段階での負荷制限の評価
4.「運用、パフォーマンス監視、バックアップ」 （Ilya Pyatin、LineMedia）
- クラッシュする前にサーバーを上げる方法は？
- 初日に100,000人のユーザーが来た場合のプロジェクトの立ち上げ方法
- 常にバックアップすることは本当に必要ですか？
- 負荷が低い場合にクラスターが必要なのはなぜですか？
- クラウド内のクラスター、賛否両論。
5.「プロアクティブな監視と傾向分析」 （Alexander Serbul、1C-Bitrix）
複数のアプリケーションサーバー、バランサー、およびフェールセーフリレーショナルストレージ構成を持つWebクラスターは複雑です。 アプリケーションを適切に構成することに加えて、成功を収めるためには、悪魔は詳細に隠れているため、適切な監視および予測システムを作成および維持し、数と傾向を理解する必要があります。 最初に必要なnagiosテスト、どのmuninグラフに注意する必要があるか、ログを分析する理由と方法、緊急ハンドラー（nagios）の作成方法、およびWebクラスターのバランスを保つ方法-これらおよび他の多くの質問を検討します。6.「クラウドマジックの公開」 （ニコライドヴァス、Clodo.ru）
テクノロジー主導のマーケティングにより、クラウドインフラストラクチャに対する一連の期待が生まれています。 これらの期待は次のとおりです。
- リソースの消費に対する支払い、月額料金および長期契約の不在;
- 無制限のスケーラビリティ。
- リクエストに応じて、必要に応じて任意の量のリソースを自動的に取得する機能。
- 鉄からの引き抜きによる耐障害性。
現実はマーケティングの期待とは大きく異なります。 クラウド内のクライアントにとって、まったく異なる側面が重要であることがわかりました。 特に：
- 節約は「公正な」消費価格設定よりもはるかに重要です。
- ほとんどの場合、スケーリングは期待どおりに機能せず、ホスティングの単純な変更では達成されません。
- フォールトトレランスはそれ自体では達成されません。ホストがフォールトトレランスを提供できない層があります。
- 「オンデマンドのリソース」は真理です。すべての必要なリソースを要求して受信できるわけではありません。
このレポートは、一般的なクラウドの神話を調整し、費用対効果、パフォーマンス、復元力を達成する方法を説明し、達成が非常に難しいものをリストしています。
7.「Bitrix24プロジェクトのアーキテクチャ：すべてが落下せずに飛ぶようにする方法」 （Alexander Demidov、1C-Bitrix）
「クラウド」プロバイダーが解決する必要がある最も重要なタスクの1つは、サービスユーザーの信頼を得ることです。 たとえば、CRM、イントラネットシステム、メールなどのビジネスアプリケーションについて話している場合、そのようなサービスは常に利用可能であるべきです-週7日、1日24時間。 不安定な操作、クラッシュ、ページの読み込み中、スケジュールされたメンテナンス作業中に閉じられたプロジェクト-は許可されません。 さらに、各クライアントのすべてのデータを可能な限り保護する必要があります。 SaaSサービスプロバイダーは、すべてのユーザーに最も安全な環境を提供する必要があります。 ライブワーキングBitrix24サービスを例として使用して、レポートはプロジェクトアーキテクチャ、負荷に応じた自動スケーリングの原理、クラウドストレージとの統合のメカニズム、Amazonサービスの使用の詳細、地理的に分散したWebクラスターでのMySQLデータベースの使用の微妙さを説明します。* * *
セミナー後に収集したアンケートへのコメントの中で、最も有用な質問への回答で、彼らはしばしば「雰囲気」と「経験」と書きました。
とても便利なイベントがありました。 :)参加してくれた皆さん、ありがとう！