2025年 crowdworks.jp の SRE チームでやったこと - クラウドワークスエンジニアブログ

この記事はクラウドワークスグループ Advent Calendar 2025 シリーズ1 13日目の記事です。

こんにちは。クラウドワークス SRE チームの田中（@kangaechu）です。本記事では、2025年にSREチームが取り組んだ主要な活動をご紹介します。今年は、WAFや検索基盤の移行といった「守りの強化」に加え、長年運用してきたデータベースのモダナイズなど、クラウドワークスの信頼性を引き上げるための様々な挑戦を行いました。

なお、イラストはNano Banana Proで生成してます。 2025年のLLMによる画像表現の精度を後年に楽しめそうなのですこしおかしいところがあってもそのままにしています。参考程度にお楽しみください。

2024年の振り返り

昨年までの取り組みについては、以下の記事をご参照ください。 engineer.crowdworks.jp

WAF マネージドルールの導入

2025年9月30日のAWS WAF Classic (v1) サービス終了に伴い、crowdworks.jp では2024年中にAWS WAF v2への移行を完了していました。しかし、移行作業はそこで終わりではありません。 2025年は、運用コストの最適化を目指し、WAFのマネージドルールの見直しに着手しました。

これまでcrowdworks.jpでは、AWS Marketplaceで提供されているサードパーティ製のマネージドルールを利用していましたが、AWSが提供するマネージドルールセット（AWS Managed Rules）への移行を決定しました。

WAF移行における最大の懸念点は、ルールセットの変更による「誤検知（False Positive）」や「検知漏れ」のリスクです。このリスクを最小限に抑えるため、以下のステップで慎重に移行を進めました。

並行稼働: AWSが提供するマネージドルールセットを追加
COUNTモード運用: ルールのアクションをBLOCKではなくCOUNT（検知のみ）に設定し、既存ルールと並行稼働
ログ分析: 一定期間のモニタリングを通じて、カバー率や誤検知の有無を精査

結果として、サードパーティ製ルールと完全に同一のカバー範囲ではありませんが、主要な攻撃ベクトルはAWSマネージドルールで十分に防御可能であると判断し、切り替えを完了しました。

OpenSearch 移行

crowdworks.jp の仕事検索・ワーカー検索機能において、長年利用してきた Elastic.co の Elasticsearch Service から、Amazon OpenSearch Service へ移行しました。

背景

以前の構成では、運用上いくつかの課題を抱えていました。

EOLサイクルの速さ : Elasticsearchのバージョンアップサイクルが早く、追従コストが高い
ライブラリの制約 : Rails アプリケーションで使用していた elasticsearch-rails gem のバージョン依存により、本体のアップデートが阻害されていた
モニタリングの課題 : Elastic.co のデフォルトではログやメトリクスの保存期間が24時間と短く、長期保存や詳細な障害調査に追加コスト・工数が必要だった
サポート体制 : AWSサポートとの一元化によるメリットを享受したかった

移行のプロセス

移行に向けた準備は2023年から開始していました。バックエンドエンジニアチームの協力のもと、検索クライアントをOpenSearchに対応している searchkick へリプレイスしました。

engineer.crowdworks.jp

2025年に入り、OpenSearch v2.17（当時の最新版）への移行を実施しました。 ElasticsearchとOpenSearchへのダブルライト（二重書き込み）を行う期間を設け、検索結果やパフォーマンスに差異がないことを検証した上で、ダウンタイムなく切り替えを完了させました。

SLI/SLO の再定義とCUJへのフォーカス

crowdworks.jpでは2018年にSLIダッシュボードを作成し、週次にエンジニア全体でSLI/SLOの確認を行っています。

しかし、SLI/SLOの定義や運用には課題が残っていました。

SLOの定義が曖昧なため、過去との比較でしか評価できない
サービス全体のSLIしか定義していないため、ユーザにとって重要な部分のSLIが把握できていない
ヘビーユーザの体験を十分に反映していない

そのため、まずはヘビーユーザの体験が一般のユーザとどのエンドポイントでどれくらい異なるかを分析しました。また、CUJ （Critical User Journey）を定義し、定義したCUJに対してバックエンドエンジニアチームと協力してSLI/SLOの再定義をし始めているところです。最終的にはCUJごとにSLI/SLOを定義し、担当チームが自分たちのCUJのSLI/SLOを把握・改善できるようにすることを目指しています。

Aurora MySQL周りの改善

crowdworks.jp は2011年のサービス開始からデータベースサーバとしてMySQLを利用しており、2024年には Aurora MySQL への移行を実施しました。しかし、パラメータなどは過去の古い設定が残ったままでした。 2025年は、長期的な安定稼働を見据え、データベース設定のモダナイズを進めました。

具体的には以下のような改善を行いました。

不要なインデックスの削除

10年以上の運用で蓄積された「使われていないインデックス」を削除しました。これは後述するテーブル再構築（ROW_FORMAT変更）の時間を短縮するための前準備でもあります。詳細は以下の記事で解説しています。

engineer.crowdworks.jp

パラメータの見直し

過去の経緯で設定されていたパラメータを一つひとつ見直し、現在のAuroraの推奨値やデフォルト値に戻しました。これにより、SREチーム内でのDB挙動への理解が深まり、ブラックボックス化を解消できました。

ROW_FORMAT を DYNAMIC へ変更

古い設定により、テーブルの ROW_FORMAT が COMPACT になっているものが多数ありました。これを現在のデフォルトである DYNAMIC へ変更しました。

ROW_FORMATを変更する主な理由は以下の2点です。

1. 可変長カラムのデータ格納効率が悪い

TEXTやBLOB、長いVARCHARなどの可変長データを格納する際の格納方式が異なります

COMPACT: 最初の768バイトをメインのデータページ（B-treeノード）に格納、残りをオーバーフローページに格納
DYNAMIC: データ本体はすべてオーバーフローページに格納し、メインのデータページには20バイトのポインタを格納

これにより、キャッシュ効率やI/O効率が悪化することが懸念されます。

2. インデックスキー長の制限

インデックスのキー長に関する制限が異なります。

COMPACT: 最大768バイト
DYNAMIC: 最大3072バイト

インデックスにVARCHARやTEXTなどを入れることはあまりないかもしれませんが、文字コードにutf8mb4を使用する場合、VARCHAR(255)であっても 255 * 4 = 1020 バイトとなり、768バイトを超えてしまいます。また、複数のカラムを組み合わせたインデックスの場合にも影響が出る可能性があります。

ROW_FORMAT の変更にはテーブルの再構築（ALTER TABLE ... FORCE）が必要です。 crowdworks.jpのすべてのテーブルをDYNAMICに変更するためには約2日間のメンテナンス時間が必要となったため、AWS Blue/Green Deploymentを活用し、ダウンタイムなしでの移行を実施しました。

レプリケーション周りで問題が発生しましたが、ユーザ影響なく移行を完了することができました。（詳細は別記事で書くかもしれません）