スケーラビリティの課題解決に向けたココナラのデータベース移行戦略

by coconala_engineer

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright coconala Inc. All Rights Reserved. ひとことで言うと、スケーラビリティが確保できていなかった 8 設定したKPIより、AWS RDSのSLAの方が低い KPIとして設定している目標はリクエスト成功率が99.96%以上。一方で、Amazon RDS（マルチAZ クラスタ）のSLAは99.95%となっており、そもそも自社でコントロールできないところで、KPI達成が難しい状況 … イコール、意図せずKPIとして無理がある設定になっていた。

Slide 9

Slide 9 text

Copyright coconala Inc. All Rights Reserved. IOPS（1秒あたりのI/Oアクセスの数）も限界が迫っていた 9 このままだと、近い未来にIOPSの上限に抵触する Amazon RDSのインスタンスサイズは適切なものを利用していたので、CPU やメモリなどは問題なかったが、 IOPSの上限に抵触しそうになった。暫定的にデータベースのデータ量と無関係にストレージを拡張することで、IOPSの上限を上げていったが、一時しのぎであった。

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright coconala Inc. All Rights Reserved. Amazon Auroraへの移行 12 定めたKPIの達成に向けてAmazon Auroraを採用 Amazon Aurora（マルチAZクラスタ）のSLAは99.99%なので、定めているリクエスト成功率（99.96%）よりも高い。また、IOPSの上限も撤廃されるため、2つの課題を一気にクリアできることを期待して、Amazon Auroraへ移行することを意思決定した。 Amazon Aurora Amazon RDS

Slide 13

Slide 13 text

Copyright coconala Inc. All Rights Reserved. DB移行は一大プロジェクトなので、マイルストーンを設定し、経営層と合意形成 13 MySQL5.7 EOL期限をデッドラインとして、計画を策定経営層に「技術課題として、一番リスクと難易度が大きいもの」とインプットするために対応するタスクの整理と、マイルストーン設定から着手。 MySQL5.7 EOL期限から逆算して、1年半がかりのプロジェクトを立ち上げ、ナレッジを徐々に蓄積できるように5つのデータベースを影響が少ないところから順に対応していく計画とした。

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyright coconala Inc. All Rights Reserved. データベース移行はやっぱり事前の準備が大事 18 集められる情報は集めて、自社としての最適解を見つける「データベース移行」といっても、システム構成やシステム特性によって、考慮するポイントはさまざま。類似したアーキテクチャーを採用しているシステムの情報を参考に「自社のベストプラクティス」を探すことが重要。なんといっても、数年に一度は必ず訪れるイベント・・・

Slide 19

Slide 19 text

Copyright coconala Inc. All Rights Reserved. システムメンテナンスの無い世界を目指していきたい 19 無停止でメンテナンスイベントをこなす最適解を見つけるクラウドサービスを使っている限り、「基盤のメンテナンス」は切っても切れないイベントになる。（全てがライブマイグレーションになれば、みんなHappyだけど…）ココナラは「全てがそろうスキルマーケット」を目指しているので、極力システムメンテナンスがない世界を実現するための机上 / 実機検証を続ける。