以下は、第1章からの引用です。 データベース スケール パフォーマンス (無料で入手可能なオープンアクセスの本) ジョアンの非常に幻想的な冒険を、あまりにも現実的なデータベースのパフォーマンスの課題と一緒にフォローしてください. あなたは笑うでしょう. あなたは泣くでしょう. あなたは私たちがこの「チーズの物語」を深く技術的な本にどのように取り組んだのか疑問に思うでしょう。 データベース スケール パフォーマンス 「ハイブリッドクラウド」、「サーバーレス」、「エッジファースト」などの印象的なバズボードに魅せられて、ジョアンはすぐに新しい会社に加わり、彼らのテクノロジースタックを追い詰め始めた。彼女の最初のプロジェクトは最近、顧客数と同じペースで拡大しないデータベースシステムの内部実装から、業界標準のデータベース管理ソリューションの1つに移行を開始しました。 SQLの世界で知られている保証。 酸素 現在、毎年登場する新しいデータ保護法がいくつかあるため、同社の取締役会は、一般的なクラウドベンダーのいずれかを使用して機密情報を保管する代わりに、独自のデータセンターを維持することを決定しました。 非常に高いレベルでは、同社の主な製品は、たったの2つの層で構成されていました。 フロントエンドは、実際に自分のブラウザで実行され、システムの残りの部分と通信して情報を交換し、持続するユーザーの入力ポイントです。 一般に「バックエンド」として知られていますが、実際には負荷バランス、認証、認証、複数のキャッシュレイヤー、データベース、バックアップなどが含まれています。 Joanの最初の入門タスクは、データベースからさまざまな統計を収集し、まとめ、そのサービスをエコシステム全体に統合するための非常に単純なサービスを実装することで、データベースからリアルタイムでデータを取得し、DevOpsチームがライブで統計を点検できるようにすることでした。 経営陣に印象を与え、この四半期でJoanを雇うことが彼らの最良の決定であることを確信させるため、Joanは最初の日にコンセプトの実装を実施することに決めました! 会社の無言のポリシーは、Rustでソフトウェアを書くことだったので、彼女は短いcrates.io検索からデータベースの最初のドライバーを手に入れ、自己組織のハッカソンに座りました。 ラストのエルゴノミーに焦点を当てたエコシステムが優れた開発者体験を提供することにより、一日が本当にスムーズに進みました。しかし、ジョアンは最初の喫煙テストを本物のシステムで実行しました。彼女は、データベースクラスター全体が健全で操作可能な状態であると報告されていたにもかかわらず、3回のリクエスト(平均)のうちの1つがエラーに終わると、失望と無力感に変わりました。 残念ながら、ドライバーのジョアンは急いで彼女の仕事の基盤を選んだが、オープンソース自体は、事前コンパイルされた、遺産のCコードに対する薄い包装にすぎず、発見されないソースだった。 そして、彼女は教育を受けた推測をし、 . 会社が使用するデータベースでは、キーは、適切なノードへの後のルートリクエストにハッシュされます. If a hash value is calculated incorrectly, a request may be forwarded to the wrong node that can reject it and return an error instead. ハッシュ値が間違って計算された場合、リクエストは、それを拒否し、代わりにエラーを返します。 Wiresharkについて バグはハッシュキーの実装に存在する必要があります。 ソースコードが欠けているため、この主張を検証できなかったジョアンは、最初に選ばれたドライバを捨て、データベースベースのベンダーがサポートする、公式にサポートされているオープンソースドライバの1つにソリューションを再実装し、強力なユーザーベースと定期的に更新されたリリースススケジュールを採用しました。 Joan's Diary of Lessons Learned Part I ジョアンの日記 初期のレッスンには、 ドライバを慎重に選択してください. それはあなたのコードのパフォーマンス、強度、信頼性の中心です。 ドライバーにもバグがありますが、それらを避けることは不可能です。 正当な理由がない限り、正式にサポートされているドライバー(存在する場合)を優先してください。 オープンソースのドライバーには利点があります: 彼らはコミュニティによって検証されるだけでなく、コードの深い検査も可能にし、ドライバーコードを修正してデバッグのためのさらなる洞察を得ることもできます。 確立されたリリースススケジュールを持つドライバーに頼るのは、合理的な期間内にバグ修正(セキュリティの脆弱性を含む)を受ける可能性が高いためです。 Wiresharkは、ネットワークパッケージを解釈するための素晴らしいオープンソースのツールです。 入門任務は最終的に成功し、ジョアンは最初の真の任務を受ける準備を整えました。 『TUNING』 入門タスクで得た経験に武装し、ジョアンは彼女の新しい任務にどのように接近するかを計画し始めました:悪意のあるアプリ. One of the applications notoriously caused stability problems for the whole system, disrupting other workloads each time it experienced any problems. The rogue app was already based on an officially supported driver, so Joan could cross that one out of the list of potential root causes. アプリの1つは、システム全体の安定性の問題を引き起こし、他のワークロードを妨げました。 この特定のサービスは、古いシステムからバックアップされたデータを新しいデータベースに注入することに責任がありました。会社が急いでいなかったため、アプリケーションは低優先順位で書かれ、ユーザーのワークロードに干渉しないようにしました。残念なことに、数日ごとに何かが異常を引き起こし続けました。通常平和的なアプリケーションは、自らのデータベースにサービス拒否攻撃を実行しようとし、バックエンドが他のエコシステムの部位に問題を引き起こすのに十分に過剰なものになるまで、要求に浸透しているように見えました。 ジョアンがグラファナのダッシュボードで提示されたメトリクスを観察し、このアプリケーションによって生成されたリクエストの割合が異常の時点で急激に増加し始めたことを明確に示唆する一方で、彼女は地球上でこのワークロードがどうやってそのように振る舞うことができるのかと疑問に思った。 コラボレーションは、オンボードセッションでオンサイトコーチと共に会社の「精神と文化の基礎」の一つとして広く宣伝されていたため、彼女は同僚のトニーとこの問題を議論するのが最善だと決めました。 「見てください、トニー、私はこれに頭を巻き込むことができません」と彼女は説明しました。 「このサービスは、すでに100個が飛行中であるときに新しいリクエストを送信しません。 「大丈夫、ありがとう、トニー、あなたは親愛なる人です。 いつだって!」と彼女は結論を出し、コードを修正するために戻った。 ゴムダック 根源の原因を発見した観察はかなり単純だった:リクエストは、データベースサーバーがそのような応答を送信したことがないため、実際にはタイムアウトエラーを返しませんでした。リクエストは単にドライバーによってタイムアウトと認定され、廃棄されました。しかし、ドライバーが特定のリクエストに対する応答を待たないという唯一の事実は、データベースがそれを処理していることを意味しません! 代わりに、リクエストは単に停滞し、予想以上に時間がかかり、ドライバーだけがその応答を待つことを諦めました。 その知識を持って、クライアント側で100件のリクエストが終了すると、アプリケーションは間違って、これらのリクエストがもはや進んでいないと考えて、幸いにも100件のリクエストをデータベースに提出し、飛行中のリクエストの合計数(すなわち共通貨幣)を200件に増やす可能性があります。 Joan's Diary of Lessons Learned Part II ジョアンの日記 レッスンは続く: クライアント側のタイムアウトはプログラマーにとって便利ですが、サーバー側のタイムアウトと悪影響を及ぼす可能性があります。 指のルール:クライアント側のタイムアウトはサーバー側のタイムアウトの約2倍の長さを作り、異なることをする極めて良い理由がない場合があります。 いくつかのドライバーは、クライアント側のタイムアウトがサーバー側のタイムアウトよりも小さいことを検出する場合、警告を発行する可能性があります、またはサーバー側のタイムアウトを調整することもできますが、一般的には二重チェックするのが最善です。 固定一致しているように見えるタスクは、特定の予期せぬ条件下でピークを引き起こす可能性があります。ログやダッシュボードをチェックすることは、そのようなケースを調査するのに役立ちますので、データベースクラスターとすべてのクライアントアプリケーションの両方で観測可能なツールが利用可能であることを確認してください。 クライアント側のタイムアウトが適切に変更されると、アプリケーションは頻繁に少なくなり、より小さな範囲で窒息したが、それはまだ分散システムの完璧な市民ではなかった。 時々、被害者データベースノードを選択し、それをあまりにも多くのリクエストで悩ませ続けたが、他の7つのノードが大幅に負荷が少なかったという事実を無視し、またワークロードを処理するのに役立つことができた。 他の時点では、その共通性はコンフィギュレーションによって予想されるよりも正確に200%大きいと報告されました。 二つの異常が間に合うたびに、貧しいノードはすべてのリクエストを処理することができず、それらの一部を放棄しなければならなかった。 運転手のド フォーマットし、合理的に最新の状態を維持し、ジョアンはそれらの痛みを軽減するのに役立ちました。 mdbook 最初の問題は単に非デフォルト負荷バランスポリシーの誤った構成であり、データベース自体が時々更新するエウリスティクスと統計に基づいて、利用可能なすべてのデータベースのノードの中から「最小限にロードされた」データベースノードを選択することにあまりにも苦労しました。 残念ながら、このポリシーはまた「最善の努力」であり、データベースから来る統計が常に正当であるという事実に依存していましたが、ストレスがかかるデータベースノードは、更新された統計を時間内に返さないように過剰に負荷を負う可能性があります! ドライバーは、この特定のサーバーが実際には忙しくないと誤って信じました。 二つ目の問題(仮想通貨の一時的な倍増)は、もう一つの誤解によって引き起こされた:過剰な投機的なリターンポリシー。データベースからの承認を得ることなく、事前に設定された期間を待った後、ドライバーは、成功する確率を最大化するためにリターンをリターンします。このメカニズムは、リターンの成功率を高めるのに非常に有用です。しかし、元のリターンも成功した場合、それは投機的なリターンが無駄に送られたことを意味します。利点と欠点をバランスを取るために、リターンは、リターンリターンだけがリターンリターンするように設定されなければなりません。そうでなければ、ジョアンの場合と同様に、リターンリターンは、リター Whew, nothing gives a simultaneous endorphin rush and dopamine hit like a quality debugging session that ends in a stunning success (except writing a cheesy story in a deeply technical book, of course). 素晴らしい仕事、ジョアン! 結末です。 あなたがこれまで達成し、チーズなデータベースのパフォーマンスストーリーを十分に得られない場合は、貧しい古いパトリックに何が起こったかをご覧ください。 「もしあなたがこのユーモアの感覚を評価するなら、ピーターの作品を見てください。 . Editor’s note: A Tale of Database Performance Woes: パトリックの不幸なグリーン・フェドラス エンジニアリングのブログ記事を書くための新しい本
