公開日:2018.8.29ItoWataruTweetエンジニアの伊藤です。稼働させた際にチューニングポイントとなった箇所を紹介いたします。この記事で取り上げるモデルケースはシンプルにこれだけです。MySQLご自分でチューニングされる方を前提に話を進めていきますが、弊社では本記事で紹介する対応をサービスとして提供しておりますので、ぜひご活用ください!一番お伝えしたかったことは書けましたのでもう思い残すことはありませんが、始めていきます。等)は、本記事のスコープから外しインフラ・アプリケーションサーバレベルまでに絞っております(もちろん結果的に寄与する部分はあります)。チューニングの目標値を決めるチューニングに終わりはありません。故に、どこまでが必要なことでどこからが拘りになってしまうのか始めに線を引くことをオススメいたします。ゴールを決めましょう(ご存知の方は読み飛ばして次に進んでください)。俳優の阿部寛さんのホームページの域まで到達できればやりきった!と言えるかも知れませんが、現実的には難しいものです。機能やデータが増える度に応答性能は劣化していくのが世の常ですので、元初の目標値を設定することは今後の運用上においても重要です。達成できればゴール負荷タイミングが決まっているのであれば「その時間帯のみ目標値を達成する」でもよいのように押さえていくことで、目標値が求められますね。2台で達成できないとすれば大分遅いように感じます。それぞれに分けて考えていきます。帯域は多くの場合、問題にならないので割愛します。基づいたサイジングが出来ないようです(困ったので同僚に相談したところ「それはオンプレ脳だぞ」と諭されるアットホームな職場です)。数が足りないと考えられます(後述)。使い切って問題ありません。いう配分で問題ありません。ファットになりがちな為、以下のようにサイジングするのがよいでしょう。サーバでの運用と同じ考え方で問題ありません。辺りが消費するメモリサイズの見積もりを増やしてください。