この記事は クラウドワークス Advent Calendar 2024 シリーズ2 17日目の記事です。
こんにちは。クラウドワークス SRE チームの田中（@kangaechu）です。 この記事では クラウドワークス の SRE チームが2024年にやったことを記載していきます。 2024年も様々な挑戦を通じて、クラウドワークスの信頼性を向上させるための多岐にわたる改善を行いました。本記事では、それらの活動をご紹介します。
2023年の振り返り
去年までにどのようなことをしてきたかはこの記事を参照ください。
2024年にやったこと
Gmailガイドライン対応
2023年10月にGoogleとYahooが相次いでメール送信者に対するガイドラインを発表しました。
Postmaster @ Yahoo & AOL — More Secure, Less Spam: Enforcing Email Standards...
ガイドラインではメール送信者に対し、複数の要件を満たす必要があるとの記載がありました。
この要件を満たさない場合、メールが配信されなかったり、迷惑メールに分類される可能性があります。 クラウドワークスでは会員登録やパスワード変更、仕事の状況などに応じたメールを送信しています。 これらのメールが正しく送信されなくなった場合、サービスに与える影響は非常に大きいです。 また、ユーザ視点で見るとクラウドワークスを詐称するメールが届き、フィッシングなどの詐欺被害に遭うといったようなことも考えられます。 クラウドワークスのサービスの信頼性を高め、安心して使っていただくためにもこれらの対応は必須となります。
また、株式会社クラウドワークスではクラウドワークス以外にも人材マッチングのクラウドワークス エージェントや工数管理のクラウドログ、AI副業ツールであるクラウドワークスAIなど、複数のサービスを運営しています。、それぞれのサービスが独自のドメインを運用し、それらのドメインからメールを配信しています。また、一つのドメインから複数のメールツールを使用してメール送信するケースもありました。その総数、60以上。 全てのサービス・メールツールの担当者が技術に詳しい、というわけではありません。
そのため、まずはサービスとメールツールの一覧を作成し、それらの管理者に対し期日までの対応をお願いしていきました。 メールツールによっては期日ギリギリにSPF/DKIMに対応するというところもあり肝を冷やしましたが、どうにか期日までに対応が完了しました。
その後、多くのサービスでDMARCのポリシーをrejectに変更することができました。
メールの送信元ドメイン、IPアドレス、DMARCレポートなどを確認するためにdmarc-visualizerを使ってみたり、
Googleの迷惑メール率を毎日確認し、閾値を超えていたらDatadog経由でSlackに通知する仕組みを作ったりと、運用しやすい仕組みづくりもあわせて行いました。
個人的にはこの対応後、メールヘッダーをよく見るようになったり、他企業のSPF/DKIM/DMARC対応がどうなっているかを見たりするようになり、メールへの興味が深まりました。
Zero ETL Integration（中断）
クラウドワークスでは、MySQLのテーブルをAWS DMS（Data Migration Service）経由でRedshiftにニアリアルタイムで同期し、データ分析を行なっていました。 ただ、DMSでレコード件数やデータサイズが大きいテーブルを再同期すると完了までに半日以上かかってしまう問題がありました。 また、DMSインスタンスの管理やDBの変更時にDMSの再同期が必要となるなどの課題がありました。 それらを解決する為にAurora MySQLとRedshiftのZero ETL Integrationが利用出来るのはないかと考え、検証・導入を行っていました。
Zero ETL IntegrationのソースDBであるAuroraでSAVEPOINTなどのDDL (Data Definition Language) を大量に実行するとレプリケーション遅延が発生することがわかりました。 回避が難しいため、Zero ETL Integrationは後回しにし、DMSを使い続けるという判断にしました。
詳細は以下の記事をご覧ください。
AWSによるZero ETL Integrationの改善により、DDLを多用しても同期遅延が発生しなくなったら再度移行をトライしたいです。
残念。
Aurora化
2024年12月にクラウドワークスのマスタデータベースをAuroraに移行しました。
これはZero ETL Integrationの検証とも関連しています。 Amazon AuroraとAmazon RedshiftへのZero ETL Integrationは2023年11月、Amazon RDS for MySQLとAmazon RedshiftへのZero ETL Integrationは2024年9月に一般提供が開始されました。 検証開始時点ではAmazon RDS for MySQLとAmazon RedshiftへのZero ETL Integrationは一般提供されていなかったこともあり、Auroraを使用したZero ETL Integrationの検証を行いました。
そのため、Zero ETL Integrationの検証ではRDS for MySQLのレプリカにAuroraを使用し、検証もあわせて行なっていました。 Zero ETL Integrationの移行は中止しましたが、Auroraに対する知見はあるため、マスタデータベースのAurora化を先行して行うこととしました。
Aurora化はここ数年来の懸案事項であり、以下を目論んでいます。
- パフォーマンス（スループット）の向上
- リーダエンドポイントを使用することによるコスト削減
- ストレージの容量やIOPSがオートスケーリングすることによるコスト・運用面負荷低減
- Zero ETL IntegrationによるRedshiftへのレプリケーション構成の簡素化（将来的に実施予定）
移行はMySQL 8.0.36とAurora 3.07でバージョンを合わせて行いました。 昨年にMySQL 8.0へのバージョンアップを行ったことにより、パラメータなどに対する知見が残っていたため、移行にかかる事前学習を減らすことができました。 1ヶ月程度の検証期間を経て12月上旬にAurora移行を行い、無事に移行が完了しました。 事前にZero ETL Integrationの検証の中で、ある程度Auroraの検証を行なっていたので検証期間を短くすることができました。
ビビりながら移行を行なった記録です。
WAF v1→v2移行
2024年9月にAWSよりWAF v1の終了が発表されました。
それによると、2025年9月30日にAWS WAF Classic (v1)のサービス終了がされるということです。
クラウドワークスではWAF v1を使用していましたが、v2に向けて2024年5月頃より調査を開始しました。 クラウドワークスではWAF v1 + Marketplaceで提供されている他社のマネージドルールという構成で運用していました。 移行の第1段として、WAF v1→v2への移行を行い、第2段で必要であればマネージドルールの変更を行うという方式としました。 2024年7月にv1→v2の移行を完了し、現在はマネージドルールの変更についての調査・検討などを行なっています。
まとめ
2024年はデータベースやファイアウォールなど、システムの根幹に関わる改善ができました。 また、上記で挙げたもの以外にもコスト削減やデプロイ用のbotの修正などさまざまな対応を行うことができました。
クラウドワークスの信頼性をさらに高めるため、来年も継続して活動を進めていきます。
クラウドワークスではSREを含むエンジニアを募集しています。興味のある方は以下のリンクからご応募ください。 https://crowdworks.co.jp/careers/mid_career/
