KPI実現のためにAmazon Auroraを採用

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

レビュー投稿日の情報になります

株式会社ココナラ / ゆーた

開発部長 / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

最終更新日2024/11/05投稿日2024/11/05

利用プラン

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

ー

10名以下

2023年10月

B to C

C to C

利用プラン	ー
利用機能	ー
ツールの利用規模	10名以下
ツールの利用開始時期	2023年10月
事業形態	B to C C to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

※Amazon Auroraへの移行を実施した際の工夫ポイントとして記載します

SQLの新旧環境での比較は手で実施するのがとても難しかったため、「Insight SQL Testing」というツールを採用した。
- https://go.insight-tec.com/cloud-verup-lp-testing/
8億本実行されていたSQLを仕分けして、以下を対象に網羅性を担保したテストを実施した。
- 連続24時間分
- 週次・月次定期バッチ処理の時間分
- 月次社内処理の時間分

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

設定しているKPIの達成が難しい状況
- もともとデータベースとして、Amazon RDS（マルチAZクラスタ）を採用していた
- 全社のKPIとして「リクエスト成功率が99.96%以上」を定めていたが、Amazon RDS（マルチAZクラスタ）の SLAは99.95%でそもそもコントロールできないところで達成が難しい状況 になっていた
IOPS（1秒あたりのI/Oアクセスの数）の限界が迫っていた
- Amazon RDSのインスタンスサイズは適切なものを利用していたので、CPUやメモリなどは問題なかったが、IOPSの上限に抵触しそうになった
- 暫定的にデータベースのデータ量と無関係に ストレージを拡張することで、IOPSの上限を上げていった が、一時しのぎであった
- このままではいずれ暫定策では頭打ちになる将来が見えていた

どのような状態を目指していたか

全社のKPIとして設定している「リクエスト成功率が99.96%以上」を実現できる状態。
- 上記にアーキテクチャー面からも達成できる状態を目指していた
IOPSの上限が開放された状態。

比較検討したサービス

Amazon Aurora
Amazon RDS
その他クラウド、オンプレのデータベース

比較した軸

会社で定めているKPIを達成できるか？
Amazon RDSで頭打ちとなりつつあったIOPSのスケーラビリティを担保できるか？
QCD観点でバランスが良い対策になっているか？

選定理由

「重要視していた点」を満たせる見立てがたった。
- Amazon Aurora（マルチAZクラスタ）のSLAは99.99%
- IOPSの上限が開放できる
- Amazon RDSよりは費用が上がるが、それでも現実的な範囲内に収まる
中長期的に利活用できるアーキテクチャーと判断できた。
- 1年〜 2年でまたスケーラビリティが担保できないアーキテクチャーだと採用できないが、Amazon Auroraはそのようなことはないと判断できた

導入の成果

改善したかった課題はどれくらい解決されたか

KPI / スケーラビリティともに想定された効果を得られることができた。
- Amazon RDS（マルチAZクラスタ）からAmazon Aurora（マルチAZクラスタ）へ移行することで、以下を達成した
  - データベースのSLAが99.95%から99.99%に向上したことによる自社でコントロールできないボトルネックの解消
  - IOPSの上限が撤廃されたことによるボトルネックの解消

どのような成果が得られたか

上記の通り、KPIを達成することができた。
- 利用者の機会損失発生頻度と今後向き合うべきリスクへの対策を行えた
副次的効果として、今まで余剰に課金していたストレージ容量についても適正にすることができた。
- コスト最適化を進められた

導入時の苦労・悩み

Amazon Auroraへ移行するとともに、EOL期限の近かったMySQL5.7 → MySQL8.0への移行をあわせて実施したため、移行前後のSQL実行結果比較やレイテンシーの変化などを調査することに時間を要した。
- 「ツールを検討されている方へのアドバイス」にも記載したが、ツールを使うことでそこを回避できたが、もしそのツールと出会えなかったらサンプリングして取り組まざるを得なかった
移行方式として、「ブルーグリーンデプロイ」を採用したが、かなりファーストユーザーに近かったため、そこの不具合にスケジュールが引っ張られることがあった。
- 数回AWS社と調整して、改善してもらうことがあった
- https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments-overview.html

導入に向けた社内への説明

上長・チームへの説明

もともと課題については経営層にも数回共有していたため、最大の技術課題として一大プロジェクトを立ち上げ、走り出すところは特に問題なし。
- 対応を行う数年前からIOPSの限界については論点に上がっていた
フィードバックがあったのは以下の2点のみで、そこに対して机上検証・実機検証を進めていった。
1. 移行に際して、メンテナンスの回数を必要以上に多くしたくない
2. 切り戻しなどのユーザー影響は発生しないように十分に検証してほしい

活用方法

ココナラスキルマーケットおよびココナラ経済圏の全てのシステムのデータベースとして採用している。
- 470万名以上会員登録されているプロダクトを24/365で支えてくれている

よく使う機能

ー

ツールの良い点

※Amazon RDSとの比較です

高可用性が実現できる。
- シンプルにフェイルオーバーの時間が短くなる
- フェイルオーバー優先順位、バックトラック有効化も可能
パフォーマンス、耐久性も高い。

ツールの課題点

※Amazon RDSとの比較です

コストが割高になる場合がある。
- ストレージ容量やリクエスト量、プロダクトが求めるSLA / SLOなどにより、意思決定が必要
利用可能なDBエンジン / バージョンが少ない。
- ココナラはMySQLを採用しており、バージョンもAmazon Auroraで利用可能なものへ移行したので問題にはならなかった

ツールを検討されている方へ

AWSでどのDBを採用するか検討している方へ

高可用性・高信頼性を実現するためのアーキテクチャーとしてはAWS上で採用する最適解と言える。
一方でコストが割高になるので、サービスに求められる信頼性をベースにAmazon AuroraかAmazon RDSを選択すると良い。

Amazon RDSを採用していて、Amazon Auroraへの移行を検討している方へ

Amazon Auroraへの移行について、イベント登壇資料を公開しているので、ぜひ参照してほしい。
- https://speakerdeck.com/coconala_engineer/sukerabiriteinoke-ti-jie-jue-nixiang-ketakokonaranodetabesuyi-xing-zhan-lue
- https://speakerdeck.com/coconala_engineer/che-di-jie-shuo-insight-sql-testingwohuo-yong-sitadetabesuyi-xing-noshi-jian-pointo

今後の展望

クラウドサービスを使っている限り、「基盤のメンテナンス」は切っても切れないイベントになる。
- 全てがライブマイグレーションになれば、みんなHappyだが、現時点では難しい
ココナラは 「全てがそろうスキルマーケット」 を目指しているので、極力システムメンテナンスが発生しない世界を実現するため、これからも新たな仕組みの机上 / 実機検証を続けていく。
そのための手段として、RDS ProxyやTiDBを採用検討を行う。 高可用性を求める旅はまだまだ続いていく。

株式会社ココナラ / ゆーた

開発部長 / EM / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

電力会社でエンジニアのキャリアをスタート。リクルートテクノロジーズ（現リクルート）でプロダクトインフラ組織のチームリーダーを経て、アドテク企業でプロダクトインフラ組織のグループマネージャーを歴任。 2020年にココナラへジョイン、現在はHead of Informationの役割で、日々活動中。 2023年から技術広報 / エンジニアブランディングにも取り組んでいる。