リリース後に発生した問題と対応
2024年12月16日のリリース時には想定を上回るリクエストが来たが、各コンポーネントをスケールアウトすることで無事に稼働を続けることができた。お正月などの一時的な負荷が見込まれる場合も、コンポーネントをスケールアウトすることで問題なく運用を継続している。姜氏は「リリースして期間は短いですが、今のところサービスを無停止で運用できています。一度だけTiDBインスタンスのノード障害が発生しましたが、そのときもサービス影響なく対応することができました」と報告した。
リリース後に発生したSlow Queryについても言及。Secondary Indexを使ったクエリで、Indexの先頭カラムで対象を絞り、2番目のカラムでソートする場面で問題が発生した。「IN句の要素が一つの場合はソートが効いたのですが、複数要素が指定されるとソートが効かなくなりました。対象が数十万件になることもあるため、Slow Queryになってしまいました」と姜氏。この問題は調査中だが、現状ではアプリケーション側でループ処理を行うことで回避している。
また、TiDBのMVCC（多版型同時実行制御）機能に関連した別のSlow Queryも発生。短期間で更新を繰り返すことで想定より多くのバージョンが生成され、検索処理が重くなる問題だ。「total_keysが過去のバージョンを含むキーの合計数で、total_process_keysが実際に処理されたキー数。この割合が大きいと読み込み処理のコストが高くなります」と説明した。
リリース後のTiDBクラスター運用は、tiupコマンドを使って実施されている。スケールアウト／スケールイン、バックアップ、データダンプなどの操作が問題なく行えているという。データベースのダンプ取得は、tiup dumplingコマンドを使用してAmazon S3にエクスポートし、BigQueryに登録。この一連の操作はAmazon ECSのスケジュールドタスクとして自動化されている。
バックアップも同様に、tiup brコマンドでフルバックアップとログバックアップを行い、Amazon ECSのタスクとして定期実行している。なお、日々の運用監視はTiDB DashboardとGrafanaで実施。Slow Queryの調査にはTiDB Dashboardを活用し、基本的なメトリクス監視に加え、リージョンの状態やキーのスキップカウントなどの監視はGrafanaで行われている。
姜氏は「少ない人数の開発チームですが、TiDB Clusterを導入し、今もサービス開発と運用を行っています」と振り返った。TiDBは無停止で運用を継続でき、急激な負荷にもスケールアウトで対応することができた点を評価。監視ツールが一通り付属することも、少人数チームにとって大きなメリットだったという。
最後に今後の展望として、「TiCDCを使ってチェンジイベントをメッセージとして送信し、非同期処理に使いたいと考えています。現在のシステムではSQSのパブリッシュに失敗した場合のトランザクション実装が一部複雑になっているため、ここを単純化できると考えています」とコメントした。
mixi2のケースは、NewSQLを採用してSNSを構築・運用した貴重な事例だ。特に小規模チームでも高いスケーラビリティと可用性を実現できることを示した点は、同様の課題を抱える多くの開発者にとって参考になるだろう。
