角待ちは対空

おもむろガウェイン

Legacy Meetup Kyotoで「レガシーシステムとインフラオーナーシップ 」という発表した

Tech

Sansan株式会社さん主催のLegacy Meetup Kyotoで発表させてもらいました。

sansan.connpass.com

発表資料は以下のものです。

docs.google.com

会場はSansan Innovation Labだったのですが、めちゃくちゃおしゃれでサンダルで行って申し訳ない気持ちになりました。

Hatena Engineer Seminar #11で「MySQL自前運用やめてAurora導入する話」した

Tech

当日お越しいただいた皆さんありがとうございます。

イベント詳細。

developer.hatenastaff.com

テーマはクラウド活用ということで最近やってる仕事からAurora化について話した。

発表資料。

drive.google.com

補足

発表はモチベーションとマネージドサービス導入の必要性、課題部分に焦点当ててたので技術的な話が殆ど無い。のでこれを機会に補足したいと思う。

ちなみに口頭で補足したことしては

  • AuroraはMySQL互換なだけだがあえてMySQLと読んでる場面がある
  • チームによって運用体制は違うのでこれが全てではない

Auroraという技術選択について

我々の要件としては以下のようなものがあった。

  • とにかく運用コストを下げたい
  • アプリケーション変更は極力したくない

逆に普通はあるだろうが我々にとってそんなに重要でないことは

  • パフォーマンス
    • MySQLしばき倒すほどは使ってない
  • 将来性
    • 積極的な開発予定はないのでMySQL5.6相当の機能が使えれば十分

検討したのは以下のような観点。

  • RDS for MySQLとどちらを選ぶか
    • 一番重要なのはAuroraはMySQL互換のサービスであってMySQLではない
      • あくまでマネージドMySQLであるRDS for MySQLとは一線を画す
      • パフォーマンス面などで差異が出る可能性がある
    • RDS for MySQLはMySQLのバージョンアップに追従しているがAuroraは現状5.7互換までしかでていない
      • さらにAurora独自の機能は5.6互換のほうにしかない場合がある
    • MySQLもバージョンアップで性能が上がるし魅力的な機能がどんどん入る
  • Aurora内でも5.6互換、5.7互換、サーバーレスなどいろいろ種類がある
  • binlogについて
    • Auroraもbinlogがだせる
    • がパフォーマンスは劣化するという情報
      • 公式情報だが数年前の情報なので改善されている可能性もある
    • いざとなればbinlogだせればどうにでもなる or パフォーマンス劣化するなら使えない手段かはサービス次第
      • 我々としてはbinlogだせるので最悪脱出可能と捉えた
    • binlogベースの非同期レプリケーションはMySQLの武器なのでそのへんなれてる人間にとってはかなりネガティブ
  • MySQLの重要性については一昔前より下がってると思う
    • なんでもMySQLにやらせてしばき倒す時代ではない
    • 必要であればNoSQLやEsを導入すべき

以上のような観点と要件照らし合わせた結果Auroraを選択した。ストレージはクラスタで一つで共有され同期的、というのは慣れないアプリケーションエンジニアが扱うのにわかりやすい(弱点でもあるけど)。またBuffer Poolの暖気もAuroraに任せられる。

移行時の技術的な課題

  • SQLモード
    • AuroraというよりはRDS全般だがMySQLのデフォルトよりゆるいので確認を
    • パフォーマンス系のパラメータは一旦デフォルト値でいいがそれ以外のパラメータについては確認しましょう
  • タイムゾーン
  • FOのやり方の変更
    • 既存の自前運用はVRRPでのVIPの付け替え
    • AuroraはDNSによるFO
    • コネクションをキャッシュしている場合、FO時にうまく切り替わらない
  • データ移行
    • mysqldumpのデータを素朴に突っ込む以外にxtrabackupによる復元もサポートされている
    • xtrabackupの復元で行きたかったがうまく行かなかったので諦めた
      • 最大のネックだったのが一回一回のトライに時間がかかるので試行錯誤が辛かった
      • xtrabackupによる復元が失敗するとクラスタの作成からやり直しになる。また移行に失敗したクラスタはサポートに連絡しないと消せない
      • 物理移行なだけあって細かい制限があるのでドキュメント読み込むこと Amazon Aurora MySQL DB クラスターへのデータの移行 - Amazon Aurora
    • AWS Database Migration Serviceは検討しなかった

発表でも補足したが技術的にはそんなに苦労はしなかった。理由としては

  • 一番たいへんなパフォーマンス検証については重要でなかったのでなぁなぁで済ませた
    • sysbench回してみたり、本番の参照だけ向けてみて大丈夫そうか確認したくらい
  • 事前にMySQLのアップデート作業は死ぬほどやってたので慣れてた

というのがある。

ドキュメントみてAuroraってそうなのねって感じの知識の獲得は当然やるとして、それ以外に大変な課題みたいのはなかった。Auroraに対応したアプリケーションの変更もなかった(もともとコネクションのキャッシュしてなかったので)。