こがぶろ – プログラムを中心にいろいろなことを記事にしていきます！

MySQLのチューニングについてまとめる

投稿日: 2017年10月13日2017年10月14日投稿者: こが

こんにちは、こがです。

今回はメモがてらMySQLのチューニングについて、自分で調べながらメモとして記事を書いていこうと思います。
また、色々とチューニング方法を書いていきますが、動作環境はこれ！っていうのはありません。
たぶん現在の環境で動いているものであれば動くとはおもいますが。

SQL・テーブル設計周りのチューニング

スロークエリを見つける

まずはじめに行うべきはスロークエリになっている部分の改善でしょう。

スロークエリを見つけるにはMySQLの設定が必要です。
my.cnfに以下の設定をし、再起動します。
また、ログの保存先やスロークエリとするlong_query_timeの値は適宜変えてください。

[mysqld]
slow_query_log=ON
slow_query_log_file = /tmp/mysql-slow.log
long_query_time = 0.5

こうして書き出したログはmysqldumpslowコマンドを利用することで集計することが出来ます。
例えば時間を元に集計する場合は-s tをつけて以下のようにします。

mysqldumpslow -s t /tmp/mysql-slow.log

参考リンク：
Mysql slow queryの設定と解析方法
http://masayuki14.hatenablog.com/entry/20120704/1341360260

実行計画を確認する

スロークエリを割り出したことで、直していくべきクエリがどれか判明しました。
しかし、そのクエリがどうして重たいのか？などは分からない場合も多くはありません。
その場合にはEXPLAINを利用して、MySQLの実行計画を確認してみると良いでしょう。

SELECT * FROM t1; // こんなSQLが有ったとして
EXPLAIN SELECT * FROM t1; // 先頭にEXPLAINをつけるだけ

この結果を見ることでインデックスはしっかり利用されているか？無駄に行フェッチをしていないか？
など色々な問題点を確認することが出来ます。

参考リンク：
MySQLのEXPLAINを徹底解説!!
http://nippondanji.blogspot.jp/2009/03/mysqlexplain.html

インデックスを適切に利用する

MySQLではインデックスを利用する上でいくつかの制限があります。
その制限をちゃんと把握しておくことが必要になります。

1. インデックスは同時に一つしか使われない

例えばプライマリキー/インデックスA/インデックスBがあるとき、
インデックスAとインデックスBはもちろんのこと
プライマリキーとインデックスAや、プライマリキーとインデックスBを同時に利用してくれない。

2. インデックスのカラムの順番とWHERE句で指定されているカラムの順番が一致している必要がある

インデックスにcol1,col2の順で設定されている場合にはWHERE句で指定する順番もcol1,col2の順番でないとインデックスを利用してくれない。

上記の注意点以外にもInnoDBはクラスタインデックスであることや、セカンダリインデックスにはクラスタインデックスののキーが含まれています。

InnoDBのクラスタインデックスについて

参考リンク：
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い
http://techlife.cookpad.com/entry/2017/04/18/092524

カバリングインデックス

必要なデータをインデックスに含まれるように設定しておくことでデータのフェッチを早くする手法です。
注）むやみにインデックスにデータを追加するのは逆にパフォーマンスの低下を招きます

参考リンク：
MySQLのインデックスを学ぶ (1)
http://d.hatena.ne.jp/a666666/20100920/1284992435

遅いJOINを速くする

JOINはよく遅いと言われます。それはなぜでしょうか。

Nested Loop Join

MySQLでは簡単に言うと、このNLPしか実装されていません。
では、Nested Loop Joinはどのような仕組みで動いているのでしょうか。

Nested Loopというくらいですから入れ子のループが回って動いています。
テーブルAの一行をフェッチして、テーブルBからマッチングするものを探して、またテーブルAの一行をフェッチして・・・・を繰り返していきます。
計算量としてとても大きくなりそうだというのはすぐ分かって頂けると思います。
テーブルAが100行増えればテーブルBを100回走査しないといけなくなりますからね・・・。
いわゆる計算量OがテーブルA×テーブルBであることがおわかり頂けると思います。

つまり速くするためには、このかけ算の結果を小さく出来れば良いという形になります。

実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法
https://qiita.com/yuku_t/items/208be188eef17699c7a5

パーティショニング

データを1カ所ではなく、特定の条件に基づいて振り分けを行い別々に保存する仕組みです。
上手に設定を行うことでパフォーマンスを上げることが出来ます。
またログデータなど一部のデータをまとめて消したりする際にも役に立ちます。

ただし、振り分けを行う為には条件とするデータがプライマリキーに含まれている必要があります。

MySQL パーティショニングまとめ
https://qiita.com/taroshin/items/608076c9f8e09497c4b1

MySQLの設定によるチューニング

メモリ周りの設定を行う際には、グローバルバッファとスレッドバッファの違いに気を付けましょう。
また、確保量が実際のメモリをオーバーしないように注意しましょう。

InnoDBの設定

innodb_file_per_table
InnoDBのデータをテーブルごとにディスクに保存します。
テーブルごとにデータが記録されるのでパフォーマンスが上がります。

innodb_buffer_pool_size
InnoDBにおいて、データとインデックスを保持するバッファです。
メモリ全体の80%程度と良く言われます。

innodb_log_file_size
書き込みが高負荷のシステムでは大きくすると良い。
このファイルがいっぱいになると更新データのディスクへのフラッシュが行われる。

クエリキャッシュの設定

query_cache_type
クエリキャッシュを行うタイプ

0:キャッシュしない
1:全ての参照系のクエリをキャッシュする（SELECT SQL_NO_CACHEで始まるクエリはキャッシュしない）
2:SELECT SQL_CACHEで始まるクエリをキャッシュする

query_cache_size
クエリキャッシュするメモリ量

参考リンク：
雑なMySQLパフォーマンスチューニング
https://www.slideshare.net/yoku0825/mysql-57449062

MySQL パフォーマンスチューニング
http://momota.github.io/blog/2017/04/20/mysql/

5分でできる、MySQLのメモリ関係のチューニング！
http://dsas.blog.klab.org/archives/50860867.html

MySQL クエリキャッシュの概要と導入・評価方法
https://weblabo.oscasierra.net/mysql-query-cache/

終わりに

MySQLの設定チューニングに関してはとりわけ大事な部分にとどめました。
多くの部分は参考リンクでも語って頂いてるのでそちらにお任せするのが良いと判断しました。

ただ、MySQLのチューニングもそうですがそれよりもアプリ側でのテーブル設計やSQLが重要だと思っています。
ここに書いたことを少しでも多くの方の役に立ったらなと思います。

今日はこのへんで。ではでは。

WEBページのCritical Path CSSによるUXの改善

投稿日: 2017年9月14日投稿者: こが

こんにちは、こがです。

今日は、最近徐々に流行ってきているCritical Path CSSについて話をしようと思います。
たぶん結構な人がCritical Path CSSとはなんぞや？だと思います。僕自身も名前自体は最近知りました。
さて、これは一体どういうものか？というお話をしていこうと思います。

Critical Path CSSで解決できること

まずはじめに、このCritical Path CSSを利用して解決出来ることは何か？とそれによるメリットについて
それは、ユーザーに対して体感としてページのロードを実際よりも短く感じてもらうことです。

いまいちパッとしないですね？僕の説明が下手ですいません・・・・
誤解を恐れずに言うのであれば、ページのロードによって画面が真っ白の状態や遷移前のページの表示のままでいるのを短くしよう。
そうすればユーザーへ早くコンテンツを届けることができるということになります。　

Critical Path CSSとは何か

Critical Path CSSとは、WEBページの上でユーザー（ブラウザ）が一番最初に目にする（表示される）部分で利用されるCSSのことです。
つまり、Critical Path CSSが読み込まれるまではページの表示がされないということです。
逆に言えばCritical Path CSSを早く読み込むことが出来ればそれだけ早い状態でページの表示準備が出来ることになります。
もちろんスクリプトの読み込みなどのレンダリングブロックによって実際の表示タイミングは左右されますがそれだけページの表示には重要な部分になります。

じゃあ実際にどうするの

することは至って単純です。
Critical Path CSSに該当するCSSをインライン、つまりHTMLに直接記述します。　　
とは言っても、直接自分の手でHTMLを編集してCSSを弄るというのは現実的ではありませんし、また全体としてCSSを管理するのにも手間が増えてしまいます。

まずCritical Path CSSのインライン化ですが、今ではaltCSS等を利用するのがメジャーになっていると思います。
なので特にWebpackなんかのバンドルツールやGulpなどのタスクランナー等で処理しているのではないでしょうか？
インライン化などについても上述のツールを用いることで簡単に行うことが出来ます。
自分は、gulp-inline-sourceというプラグインを利用してインライン化を行っています。

CSSの管理方法としてフルCSSからCritical Path CSSを抜き出して生成してインライン化をしていくというのが一般的なフローになっていくのではないでしょうか。
Critical Path CSSの生成についても手動行うのはとっても厳しいものがあります。
この点もWEBツールやプラグイン等を利用することで簡単に行うことが出来ます。
NodeプラグインではCriticalだったり、WEBでもCritical Path CSS Generator等でググると出てきます。

本当に早くなるのか

これはケースバイケースという感じはします。
CSSやJSのフレームワークを使うのが一般的になってきたりしている昨今では少なからず効果を体感することが出来るのではと思っています。
実際に大手のWEBサイトではこのCritical Path CSSをインライン化して読ませるだけでなく、色々なテクニックを利用してUXを上げる工夫をしています。
今回のインライン化をすることによってUXを改善できれば良いなと思います。

今回はこんな感じで。
ではでは

GCEでGitlabを立ててみた話 – 2017.09 –

投稿日: 2017年9月8日投稿者: こが

こんにちは、こがです。　　
　　
業務でGitlabを立てることになったので、またまたCompute Engine上に立ててみました。
今回初めてGitlabを立てたのですが、インストールがとっても楽チンでした。
そんなGitlabのインストールで行ったことをメモっていきます

公式サイトのInstallationを参考にインストールを進めていきます。
Installation methods for Gitlab

今回の環境としては以下の通りです。
CPUx1/メモリ3.75GBのn1-standard-1を利用し、OSにはUbuntu16.04 LTSを選択しました。

インストール

公式サイトの通りに順番に項目をこなしていきます。
途中で公式サイトには無い設定として、Gitlabで利用するURLの設定を行っているので注意してください。
また、ステップ1の項目は今回不要でしたので行っていません。
ということでステップ2からです。

リポジトリの登録

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

ローカルへGitlabをインストール

sudo apt-get install gitlab-ce

外部へ公開されるURLの設定

sudo vim /etc/gitlab/gitlab.rb

/etc/gitlab/gitlab.rbを開いてexternal_urlをおのおのアクセスする際に利用するIPアドレスなりドメインなりに変更します。　　
後からでもこの項目は設定出来ますが、以下のコマンドを実行する必要がありますがこのタイミングで行うことでまとめてやってもらいます。

Gitlabの環境設定

sudo gitlab-ctl reconfigure

これでGitlabのインストール作業は終了です。
ここからはブラウザ上で作業を行っていきます。

初期設定

まずは最初にアクセスする際に行うのがrootアカウントのパスワード設定です。
自分の環境ではセキュリティリスクになると思ってすぐ消すので適当にパスワード設定しました。
というこですぐにアカウント関連の設定をしましょう。

新規アカウントの作成・rootアカウントの削除

まずは新規アカウントを作成します。
まずはrootアカウントでログインし、右上のAdmin Areaを選択し、少し分かりづらいですがOverviewからUsersへと進んで右側にあるNew Userを選択します。
アカウント名とメールアドレス、そしてアクセスレベルを設定してCreate Userを選択しアカウントを作成します。
初期設定の状態ではメールが利用出来ないので、作成したユーザーをEditからもう一度編集してパスワードを設定します。
これで新規アカウントの設定は完了です。
　　
次にrootアカウントを削除するために、作成したアカウントでログインし直します。
先ほどと同じようにAdmin Area->Overview->Usersと進みます。
そして、rootアカウントの削除を右のボタンから選択して削除をします。

サインアップの無効化

さらにサインアップを無効化しておきます。

やり方は、同じようにAdmin Areaを選択、右の歯車からSettingsを選択し、Sign-up RestrictionsにあるSign-up Enabledのチェックを外し設定を保存します。

終わりに

色々と他にも設定項目はあると思いますが、こんな感じだと思います。
また、アカウントの認証周りは2段階認証が使えるので有効にしておくのも良いと思います、というより是非とも有効にしましょう。
　　
今回は、この辺にしておきたいと思います。
ではでは。

【無料】GCEでWordPress【だドン】

投稿日: 2017年8月20日投稿者: こが

こんにちは、こがです。

GCEの無料枠を使ってWordPressを立ち上げたので、それをメモがてら書いていきたいと思います
（ここにそんなのを書いてしまうなんて、とってもセキュリティリスク高い・・・）

セットアップ手順

ダッシュボード

まずは、ダッシュボードにアクセス！！
まあこれしないとはじまらないですからね・・・。
コンソール

Click to Deploy

今回は”Click to Deploy”でサクッとWordPressを立てていきたいと思います！
Click to Deployどこやねん！って僕はなったんですが（みんなはならないって？
コンソールの上に表示されている検索ボックスから簡単にClick to Deployできます！
検索ボックスに”WordPress”と入れてみてください。
出てきましたよね？色々と出てきますが、僕は通常のWordPressを選択しました。

詳細設定

この画面では、名前やスペックなどを設定していきます。
特に注意して欲しいのが、マシンスペックがn1-standard1に設定されていることです。
この状態では無料枠として利用する事が出来ません、必ずf1-microを選択してください。
また大丈夫だとは思いますが、リージョンに関してもUSリージョンであるか確認しておくと良いでしょう。
それに加えて、無料枠ではディスクサイズが30GBまでは無料ですので設定しておくと後々困らなくて済みそうです。

以上でWordPressが無事に立ち上がります。
WordPressのセキュリティなどしっかり設定をして楽しいWordPress/GCEライフを送りましょう！

終わりに

マシンが稼働しているのはUSリージョンととてもではないですが、日本からでは遠いですね。
なのでCloud CDNを利用しておくと良いと思います。
余力があればこの部分はまたの機会にしておきたいと思います。

ではでは

ブログ開設（移転）しました

投稿日: 2017年8月20日投稿者: こが

こんにちは、こがです

せっかく利用してるドメインをフルに活用すべく、はてなブログからWordPressに乗り換えてみました。

これを契機にブログももうちょっと頑張れたらなと思うのでしたまる。

どうぞこれからもよろしくお願いします。