データベースの容量計画

公開: 2016-06-21

注：この投稿は、キャパシティプランニングに関するJuliaEvansの最近の投稿に触発されています。

RDBMS

まず、いくつかの基本ルールを確立しましょう。はい…この投稿は、一度に1人のライターと2つ以上のリードレプリカでMySQLを使用する私たちを対象としています。ここで説明する内容の多くは、マルチライターのクラスター化されたデータストアには異なる方法で適用されるか、まったく適用されませんが、それらには独自の妥協点と警告があります。だから…あなたのマイレージは間違いなく変わるでしょう。

ただし、このブログ投稿は、セルフホストの物理ホストを使用しているか、魔法のようなリザーブドインスタンスとほぼインスタントプロビジョニングを使用できるAWSにいるかに関係なく適用されます。「クラウド」にいることで、インフラストラクチャの能力と制限を知ることができなくなり、チームと顧客に対するその責任を免れることはできません。

シャーディング

私は以前の投稿の1つでこれの大きなストロークをすでに取り上げましたが、主に機能的または水平方向のシャーディングの利点に焦点を当てました。はい、それは絶対的な前提条件です。データベースレイヤーへのアクセスに使用するものによって、拡張する必要のある柔軟性が決まるためです。

まったく新しい会社の場合、1日目に機能的なシャーディングは必要ないかもしれませんが、成長したい場合（そして成長したいと思う場合）は、分割できないオープンソースのORMを使用しないでください。将来的には機能ベースのデータ。単一のスキーマ内のすべてのリレーショナルデータを使用して会社を立ち上げない場合も、ボーナスポイントが得られます。

読み取りと書き込みを分割する機能

これはあなたができる必要があることですが、必ずしも石のルールのセットとして強制する必要はありません。書き込みをすぐに読み取る必要があり、ラグ/結果整合性などの許容度が低いユースケースがあります。これらは問題ありませんが、同じアプリケーションでは、結果整合性のより長い期間に耐えることができる読み取りのシナリオもあります。そのような読み取りが大量にある場合、本当に必要がないのであれば、そのボリュームをシングルライターに送信する必要がありますか？自分に有利に働き、成長期のすぐに、コードでの読み取りまたは書き込みIPの使用を制御できることを確認してください。

次に、実際のキャパシティプランニングの思考プロセスについて説明します。データベースクラスタが追いついていないのですが、どうすればよいですか。

システムのボトルネックを特定する

書き込みまたは読み取りでボトルネックになっていますか？
問題は高いCPUとして現れていますか？
IO容量として展示されていますか？
明確な読み取りクエリの原因がない場合、レプリカのラグが大きくなっていますか？
ロックですか？
それがどれであるかをどうやって知ることができますか？

これらのそれぞれは、それ自体で投稿にすることができます。私が言いたいのは、どの部分がボトルネックであるかを見つけるには、システムとDB固有のメトリックに精通している必要があるということです。

ベースラインが必要です

少なくとも数週間前から視覚化できる基本的なシステムメトリックがあることを常に確認してください。多くのツールがこれを提供します（Cacti、Munin、Graphiteなど）。主にバインドされているシステムメトリックがわかったら、ベースライン値とピーク値を確立する必要があります。そうしないと、現在の問題が新しいアプリケーションに起因するバグであるか、実際の成長であるかを判断することは、あなたが望むよりもはるかにエラーが発生しやすくなります。

ただし、基本的なサーバーメトリックはこれまでのところしか実行できません。ある時点で、コンテキストベースのメトリックも必要になることがあります。クエリのパフォーマンスとアプリ側で認識されるパフォーマンスは、アプリケーションがクエリへの応答時間と見なすものを示します。このコンテキストの重い追跡を行うための多くのツールがあります。風速計のようなオープンソースやVividCortexのような商用ツールもあります（SendGridで使用しています。ここで説明します）。アプリの観点からこれらのメトリックを追跡し、statsdメトリックとしてスローするだけでも良い最初のステップになります。ただし、早い段階で、アプリが認識するのは顧客が認識するものであるという事実に慣れる必要があります。そして、あなたは最初に知る方法を見つけなければなりません。

あなたのビジネスのトラフィックパターンを学ぶ

あなたは特定の平日（例えばマーケティング）の極端なピークの影響を受けやすいビジネスですか？ゲームのようにトラフィックを3倍または4倍にする定期的なローンチはありますか？これらの種類の質問は、予約されたヘッドルームをどれだけ維持する必要があるか、または弾力性のある成長に投資する必要があるかどうかを左右します。

使用中の容量に対する生のトラフィック数の比率を決定します

これは、「コードの最適化を行わなかった場合、現在のデータベースインスタンスで何通のメール/販売/オンラインユーザー/何でも提供できるか」に対する答えにすぎません。

理想的には、これは1年の成長を計画するための数学を単純な数学の方程式にする特定の値です。しかし、人生は決して理想的ではなく、この値は季節や、新しい主要顧客の登録などの完全に外部の幸せな要因によって異なります。初期のスタートアップでは、この数値はより速く動く目標ですが、会社が初期の頃からより予測可能なビジネスの成長パターンを持つより確立されたビジネスに移行するにつれて、安定するはずです。

本当にもっとマシンを購入する必要がありますか？

これが本当に容量であるかどうかを判断する方法を見つける必要があります。同時書き込みロードをサポートするために書き込みを分割するか、読み取りレプリカを追加する必要があります。コードベースのパフォーマンスのボトルネック（最近のデプロイからのこの新しいクエリでは、結果が実際に安価なものにキャッシュされ、データベースに勝るものはありません）。

どうやってそれをしますか？あなたはあなたの質問に精通する必要があります。そのための赤ちゃんのステップは、innotop、遅いログ、およびPerconaToolkitのpt-query-digestの組み合わせです。これを自動化するには、DBログを中央の場所に転送し、ダイジェスト部分を自動化します。

ただし、これも全体像ではありません。しきい値を下げすぎると、ログのパフォーマンスが低下します。選択性の低いサンプリングで生活できる場合は、アプリケーションとデータストア間の会話全体を検出する必要があります。オープンソースの土地では、tcpdumpのように基本的なものにすることも、Datadog、New Relic、VividCortexなどのホストされた製品を使用することもできます。

電話を掛ける

キャパシティプランニングは、90％が科学で10％が芸術である可能性がありますが、その10％は、私たちができる限り多くのことを目指して努力すべきではないという意味ではありません。エンジニアとして、不足している10％に固執することがありますが、その作業を行った場合、その90％によって、スタックの状態、パフォーマンスの最適化、および計画能力のより効率的な使用について、より良いアイデアを得ることができます。慎重に増加するため、最終的には当社製品の投資収益率が大幅に向上します。