この記事は クラウドワークス Advent Calendar 2023 シリーズ1 6日目の記事です。
こんにちは。crowdworks.jp SRE チームの田中（@kangaechu）です。 この記事では crowdworks.jp の SRE チームが2023年にやったことを記載していきます。 やっていることは色々で、まとまりはありませんが、そこら辺はご容赦ください。
2022年の振り返り
去年までにどのようなことをしてきたかはこの記事を参照ください。
2023年にやったこと
CircleCI インシデント対応
2023年1月4日、まだお正月気分が抜けていない中、CircleCIのインシデントが発生しました。
crowdworks.jp ではCircleCIをさまざまなリポジトリで使用しており、アーカイブ済みのリポジトリを含めると700超のデプロイキー・環境変数をCircleCIに保持していました。 重要なキーについては当日中の対応を行いました。またcrowdworks.jp のエンジニアにも作業を依頼し、1週間程度で対応を終えることができました。
また、2022年の時点でCircleCIとAWS間の認証をアクセスキーからOIDCに変更していたことが影響範囲の減少につながりました。
インシデント対応は突然発生する優先度の高いイベントで辛いですが、OIDC化のようなこまめなセキュリティ改善対応が実を結んだのは嬉しいですね。
RundeckのECS化
crowdworks.jpでは、2017年頃からバッチジョブのスケジューラとしてRundeck v2系を使用してきました。 バージョンアップの優先度が上がらないままRundeck v2系のままで運用を続けていましたが、 2022年3月にRundeck v4系がリリースされたこともあり、Rundeckをアップグレードしました。 ついでに構成をEC2からECSへ変更しました。
詳細はこちらのブログを参照ください。
Railsで使用しているMemcachedをRedisに寄せる
課題
crowdworks.jpでは、AWS上でRailsアプリケーションを運用しており、セッションやキャッシュを保持するKVSとして以前はMemcachedとRedisの両方を利用していました。 しかし、以下の課題を抱えていました。
1. Memcachedでは停止時にデータが揮発する
Memcachedは再起動や停止時にデータが揮発します。 スケールアップやバージョンアップなど、ElastiCacheには停止を必要とする処理があります。 その度にセッションの情報が揮発するとユーザは再ログインが必要となるなど、体験が悪化します。 開発者にとっても変更しやすいシステムの障壁となるような構成はできるだけ避けたいと考えていました。
2. Memcached単体ではマルチAZ構成でデータのレプリケーションができない
検討当初、Memcachedはクラスター構成をとっておらず、AZごとにノードが起動している状態でした。 また、クラスター構成にした場合であっても、Memcachedのみではデータのレプリケーション構成とすることができません。 AZ障害でMemcachedが1ノード停止すると、停止したノード分のデータは消失します。 障害に強い構成にし、障害時でもできる限りデータを保持するような構成としたいです。
3. Memcached/Redisともにバージョンアップをしていない
Memcached/Redisともに2018年頃からアップデートの優先度が下がっており、放置しても動き続けていたため、いわゆる「なんもわからんが動いているシステム」となっていました。 セキュリティアップデート以外の更新がされておらず、改善が回らない状況となっていました。 このままMemcached/Redisを両方使い続けるのは運用負荷が高く、これからもバージョンアップされないシステムとなる可能性があります。
4. MemcachedとRedisの使い分けが曖昧
crowdworks.jpのRailsアプリケーションではMemcachedとRedisを併用していましたが、実際は雰囲気で使い分けているようでした。 「Memcachedでなければ性能要件が満たせない」というようなこともないため、両方運用し続ける必要はないと判断しました。
対応
変更前はMemcached x 5台、Redis x 1セットという構成をRedis x 2セットに変更しました。 Redisを2種類準備したのは、データの優先度により格納するクラスタを分離したからです。 具体的には「セッション情報など、Evictionによるデータ損失を許さないクラスタ」と「キャッシュなど、Evictionによるデータ揮発をある程度許容するクラスタ」に分離しました。
アプリケーション側の切り替えも必要でしたが、バックエンドエンジニアのBugfireがデータ移行をガンガン進めてくれたので助かりました。
結果
Redisバージョンを最新化し、新機能が享受できる環境を作ることができました。 また、RedisとMemcachedを併用していた環境からRedisに片寄せすることで、バージョンアップなどによる運用コストの低減につなげることができます。 また、インスタンスも最新世代が使えるようになり、台数も減らすことができたことでコストの低減にもつながりました。
MySQL 8.0 アップデート
crowdworks.jpでは AWS RDS MySQL 5.7を使用していました。 しかし、MySQL 5.7のEOLが2023年10月だったため、8.0へのアップデートを実施しました。
詳細はこちらのブログを参照ください。
大きな問題もなく移行が完了しました。次はAuroraだ！
Redshift AQUA化
crowdworks.jpではデータ分析基盤としてRedshiftを使用しています。 RedshiftのクエリにはRedashを使用しており、さまざまな部門の利用者がデータによる現状把握、合理的な意思決定、顧客のインサイト把握、機械学習などに活用しています。 しかし、crowdworks.jpのサービス成長に伴いデータ量が増えたり、データ分析基盤の活用の幅が増えてきたことでRedshiftのリソース不足が時折発生していました。
Redshiftには第2世代のインスタンスを使用していましたが、第3世代のインスタンスに更新することにより、AQUA（Advanced Query Accelerator）による最新機能の恩恵を受けることができます。 AQUA化によるクエリパフォーマンスの最大10倍向上は嬉しいですね。 また、現在AWS DMS (Database Migration Service) でMySQLからRedshiftに同期しているのですが、 2023年11月7日に一般提供が開始されたAmazon Aurora MySQL zero-ETL integration with Amazon Redshift を使用することで、DMSが不要になりそうです。
ということで、Redshift AQUA化を行いました。 分析クエリの実行時間が（10倍ではないですが）軒並み速くなったのは嬉しいところです。
データ分析基盤にはまだまだ改善できるところが多くありますので、引き続き手をかけていきたいです。
メール
GoogleとYahooが相次いでメール送信者に対するガイドラインを発表しました。
Postmaster @ Yahoo & AOL — More Secure, Less Spam: Enforcing Email Standards...
ガイドラインにはメール認証の有効化・購読解除機能・メールのスパムレートが含まれています。 crowdworks.jpではユーザの体験を最大化し、スパムの少ないインターネット環境を目指してこれらの設定を積極的に進めていきます。
SRE NEXT 2023
クラウドワークスは2023年9月29日に開催されたSRE NEXT 2023で、Bronze sponsorとして協賛しました。 当日はクラウドワークス内の複数サービスから複数のSREチームメンバーが集結し、お揃いのTシャツを着て楽しみました。 次回は成果を登壇して発表することを目標に、引き続き活動を進めていきます。
まとめ
2023年はCircleCIのインシデントに始まり、Google/Yahooのメールガイドライン対応に終わる外部影響の多い1年だったかもしれません。 その中で、ElastiCacheをRedisに寄せたり、MySQLのバージョンを8.0に更新するなど、根幹となるシステムの改善に手をつけれられたかなと思っています。
crowdworks.jpの信頼性をさらに高めるため、来年も継続して活動を進めていきます。
