ローンチ前！MySQLの検討事項リスト14

Webサービスを開発していく上で、RDBMSを利用するのであれば現在圧倒的にMySQLを利用する会社・エンジニアが多いと思います。ただし、割と何も考えずにMySQLをデフォルトのまま利用してローンチして、その後障害ばかりというのがよくあるケースです。とはいえ現在AWSを使うことが圧倒的に多いため、RDSをそれほどいじらずそのまま使ってもそれほど問題ないケースも多いですが、本来インフラ面で考えておかないといけない基本的な項目をリスト化してみました。

サービス用途の確認

まずはサービスで何のためにMySQLを使うのか考えましょう。本当にMySQLが必要でしょうか。実はNoSQLで十分であったりむしろNoSQLの方がよいことも多いです。そもそもAWSを利用している場合はAuroraやMariaDBを利用する選択肢もありますが、詳しくない場合はシンプルにMySQLがよいでしょう。

ストレージエンジンの選択

MySQLを使うことにしたら、どのストレージエンジンを利用するか考えましょう。現在のMySQLではInnoDBがデフォルトですが、古いバージョンではMyISAMです。また、MEMORY、BLACKHOLEなどのストレージエンジンを使うケースがあるかもしれません。変わったものではCSV、MERGEストレージエンジンなどもあります。基本的にはInnoDBから変更する必要はありませんが、本当に高速化のみを考えている場合、MyISAMを利用してもよいケースがあるでしょう。

MySQLのバージョンの選択

2017年現在GA版ではMySQL5.7が最新です。公式サイトからダウンロードできる最新版を利用するのが一般的ですが、企業で利用する場合はある程度不具合の情報が出ている少し前くらいのバージョンを利用していることも多いです。また、自社で運営しているサービスが既にMySQL5.5や5.6で稼働していて、アプリケーションもそれを元に作られている場合などは、事前に問題がないか確認をしておく必要があります。RDSを利用する場合はそもそも最新の安定版はなく、デフォルトでは1つ前にメジャーバージョンがデフォルトで選択されるようになっていますので、詳しくない場合はそのままでよいでしょう。

パラメータの検討

my.cnfの設定を検討しましょう。ここでは詳しくは述べませんが、innodbbufferpool_sizeをメモリの6割～8割くらいを割り当てるという最低限のことだけはやっておきましょう。RDSの場合はそれほど意識しなくてもいいです。

ある程度のベンチマーク

想定している性能が出るのか、sysbenchやtpcc-mysqlなどのツールを利用してベンチマークテストを実施するのが本来あるべき姿です。Webサービスは速度が非常に大事なので、リリースした後に性能が出なかったなどのことがないようにしましょう。

データサイズの確認

MySQLの使うデータ領域がどのくらいのサイズになるのかを事前に確認しておきましょう。きちんと事前に設計しておかないと、オンプレの環境でもRDSでも後で困ったことになります。データベースは一度リリースされてしまうと移動をするのは意外と大変です。メンテナンスは簡単には入れられません。

レプリケーションの確認

レプリケーション設定をきちんと設定しましょう。一般的なシステムであればレプリケーション設定やレプリカ設定は必須です。

準同期の検討

MySQLの通常のレプリケーションはあくまでも非同期です。完全同期はできませんが、プラグインの設定をすることで順同期設定は可能です。スレーブが遅延すると問題がある場合やフェイルオーバーの設定を行う場合は順同期設定を行なうことが必要です。

テーブル構成の確認

そもそもテーブル構成やインデックス構成が適切になっているか確認しましょう。正規化しすぎるのも問題です。

バックアップ構成

バックアップをどのように取得するか検討しましょう。mysqldump、perconaのxtrabackup、mysqlを停止してのスナップショット取得など方法は様々です。リカバリを考えるとバックアップ用スレーブを利用したxtrabackupやファイルコピーなどがよいでしょう。

リカバリポイントの確認・共有

バイナリログのバックアップなども含め、バックアップをどの周期で取得していてどのタイミングまで何分単位で戻せるのかを事前に確認し、ビジネス部門へ共有しておきましょう。きちんと共有しておかないと障害時にシステム部門の責任が問われます。

オペミス対策

システム部門以外の人員がオペミスなどをしないよう、mysqlのユーザの権限をしっかり分離しておきましょう。オペミスで最も恐いのはうっかりデータを間違って更新してしまったり、削除してしまうケースです。バイナリログがあればおそらくはリカバリできますが、そのようなことが発生しないような検討を事前にしておくことも大切です。

マスター・スレーブへの振り分け方法検討

通常は書き込み用のマスター、読み込み用のスレーブやリードレプリカを準備します。読み込み用のスレーブは複数台用意することは可能ですが、マスターは1台だけですので、書き込みが多いシステムではマスターを分散するよう設計することも検討しましょう。

フェイルオーバーの設定

可用性が求められるシステムの場合、RDSでmultiazを使う方法もありますが、通常ではMySQLに搭載されているmysqlfailoverコマンドを利用したり、MHAなどのツールを利用してフェイルオーバーが可能なよう設定しておくのが理想的です。

まとめ

ここで挙げたのはほんの一部で、本当はもっとMySQLの利用で考えることはたくさんありますが、少しでも検討事項を多くしておくことはローンチ後の安定につながります。