この記事は クラウドワークス Advent Calendar 2022 の 2日目の記事です。
こんにちは。crowdworks.jp の SRE チームに所属している高橋です。 この記事では crowdworks.jp の SRE チームが2022年にやったことを記載していきます。やっていることは色々で、まとまりはありませんが、そこら辺はご容赦ください。
目次
2021年のふりかえり
去年までにどのようなことをしてきたかは、こちらの記事をご参照ください。
2022年にやったこと
crowdworks.jp の SRE チームメンバーが執筆したエンジニアブログ（再掲）
Atlantis で Terraform のドリフト検出
Terraform のドリフト検出で Atlantis を利用した方法を紹介しています。
詳しくは記事をご覧ください。
WordPress を静的ホスティングサービスの Shifter へ移行しました
WordPress を Shifter に移行した際の移行理由や移行作業内容を詳しく紹介しています。
WordPress の運用にお困りの方はご覧ください。
Terraform AWS プロバイダ v4 アップグレードツールを作ろう
Terraform AWS プロバイダ v4 のアップグレードが行われ、S3 バケット関連で破壊的な変更が入りました。アップグレード作業を手作業で対応するのは大変なため、Terraform のリファクタリング用のライブラリを作ってアップグレード作業を行いました。
AWS プロバイダ v4 アップグレードツールの仕組みを詳しく紹介していますので、Terraform AWS プロバイダ v4 のアップグレードに対応していない方は、是非ご覧ください。
AWS Athena で ALB のログを過去分も検索する
AWS の公式ドキュメントの通り Athena の設定をすると ALB の過去ログが検索できないため、正規表現を駆使して過去ログを検索できるようにした際の方法を記載しています。
詳しくは記事をご覧ください。
スロークエリ改善
背景
一部のヘビーユーザー様の場合に、1日に数十件程度のリクエストタイムアウトが発生していました。そして、リクエストタイムアウトの主な原因は特定のスロークエリでした。
調査時の設定内容や状況は以下の通りです。
- 利用している DB: RDS MySQL 5.7
- DB リクエスト数: 3.4k req/s（日中のピーク時は 7~9k req/s）
- スロークエリの条件: 500ms 以上
- リクエストタイムアウトの定義: 60s 以上
- メッセージ件数が一般的なユーザの30倍程度
スロークエリに関しては、アプリケーションレイヤーの問題ではありますが、SRE チーム では将来的にデーターベースをよりスケーラビリティの高い MySQL 互換の Aurora に移行するための変更を検討しています。そのため、SRE チームとしてデータベースへの理解を深め、安定的に維持管理可能な状態を目指すためにスロークエリの削減を行うこととしました。
やったこと
スロークエリの傾向を分析した結果、上位10件のスロークエリの割合は全体のスロークエリの48.7%程度で、特定のクエリがボトルネックというわけではなく、満遍なく遅いクエリがたくさんある状態でした。そのため、比較的件数の多いクエリから優先的に改善を行うことにしました。
スロークエリ改善ではチーム内でノウハウを蓄積するために、モブプログラミング形式でバフォーマンス分析やチューニング作業を行いました。その作業内容をざっくりと説明していきます。
Amazon Athena でスロークエリのログを検索した結果から上位のスロークエリを対象にスロークエリごとに以下の作業を行いました。
- 該当のソースコードを確認
- Amazon Athena で該当のソースコードのファイル名と行を指定して duration の降順で SQL を抽出してスロークエリ原因の SQL を確認
- DB で対象の SQL の実行計画を確認
- Datadog のデータベース モニタリング機能を活用して、パーセンタイルを見ながら、どのくらい効果がありそうかを確認
- INDEX を変更して改善できそうかを検証
- SQL レベルでチューニングできたら、該当のソースコード（Active Record）を確認して、チューニングしたSQLを再現できるように修正
- 修正方針を決めたら、変更PRを作成
- 変更PRをリリースして、改善されているかを Datadog から確認
最終的な成果としては、合計で8%のスロークエリを削減しました。尚、8月時点では、16%程度の改善が見込めそうではありましたが、問題となっているスロークエリを地道に改善していく一方で、システム全体で見たクエリ実行数のトレンドは増加傾向にあり、DB 負荷も上昇傾向であったため、スロークエリ件数の改善幅が9月時点で8%に低下してしまいました。思ったようには改善できませんね。
副次的な効果として、ビジネスクリティカルなバッチ処理の実行時間が20〜30分程度かかるものが10分程度に短縮し、月末のバッチ処理中にオンライン処理がロック待ちエラーになる頻度も減って、ユーザーとシステム双方に良い影響があったのは喜ばしいことです。
バージョンアップ祭り
背景
crowdworks.jp では Ruby on Rails をメインに様々なサブシステムを組み合わせてサービスの提供をしています。
SRE チームは crowdworks.jp をご利用いただくユーザーの皆様に安心してサービスをご利用いただけるように、定期的に利用しているソフトウェアのバージョンを確認しています。
古いバージョンのソフトウェアを利用し続けることはセキュリティ上のリスクとなりうるため、優先度を決めながらソフトウェアのバージョンアップ対応を行なっています。
やったこと
バージョンアップ対応自体はソフトウェアを利用し続ける限り必要な作業ですが、今年は、ちょっと多めにバージョンアップ対応を行なっています。主にバージョンアップ対応したものは以下になります。
- Debian 10 EOL対応
- Node.js 12 EOL対応
- Alpine Linux 3.12 EOL対応
- Go 1.16 EOL対応
- Postgres 12系のマイナーバージョンアップ対応
- DMS 3.4系のマイナーバージョンアップ対応
- MySQL 5.7系のマイナーバージョンアップ対応
箇条書きにしてみると少なく見えますが、実際は各種システムごとに上記のバージョンアップ対応を実施しているため、かなりのリソースを割いて作業をしています。
バージョンアップ対応は、単純なバージョンアップ作業にとどまらず、運用負荷の低減やセキュリティ向上のためのシステム構成見直しなどを含めて実施しており、もはや式年遷宮をしているようです。
式年遷宮は数十年に一度ですが、ソフトウェアは毎年作業が必要なところが大変ですね。
GitHub Actions と CircleCI の OIDC 対応（AWS アクセスキー廃止）
背景
GitHub Actions と CircleCI で OIDC の機能が提供されたため、crowdworks.jp も OIDC 対応をすることにしました。
GitHub Actions の OIDC 対応の記事はこちらです。
CircleCI の OIDC 対応の記事はこちらです。
やったこと
今までは、GitHub Actions と CircleCI の CI で実行時に CI 用のユーザーを AWS 上に作成して利用していましたが、OIDC での認証方式に変更しました。
OIDC 対応のメリットは以下をご参照ください。
https://docs.github.com/ja/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connectdocs.github.com
小まめなセキュリティ対策によって、crowdworks.jp の安全性を日々高めています。
Lambda のデプロイツールを lambroll に変更
背景
皆さんは、AWS Lambda のデプロイツールにはどのようなツールを利用していますでしょうか。デプロイツールを使わなくても AWS Lambda 上で管理すればいいじゃないですかという意見もありますが、我々は GitHub でコード管理したいですし、CI によってデプロイがしたいのです。
今までは、AWS Lambda のデプロイツールには Apex や Serverless Framework を利用していました。
Apex は 長い間メンテナンスされなくなり、現在はアーカイブされています。
代替ツールとして、Serverless Framework を試してみましたが、Serverless Framework はフルスタックなフレームワークという印象があり、Terraform との使い分けがしにくいという課題がありました。
そこで、我々は lambroll というツールを使うことにしました。lambroll はデプロイに特化していたり、修正するリソースを Terraform に寄せられるという都合上、運用しやすいため lambroll を採用しました。
lambroll についての詳細は、こちらです。
やったこと
Lambda のデプロイツールを lambroll に変更しました。
また、Lambda 関数は、Lambda 関数ごとにリポジトリを作成しておりましたが、認知負荷の軽減とデプロイ関連の処理を共通化してメンテナンスコストを下げるために、モノレポで管理するように変更したりもしました。
Lambda の CI/CD 環境が整備されたことによって、より変更がしやすい状態に変えることが出来ました。
ドキュメント運用の設計支援
背景
crowdworks.jp では、過去に社内のドキュメント作成促進のために、とにかくアウトプットすることを目的に、どのような内容でもOKなドキュメントが作成された経緯があり、社内にドキュメントが大量にあります。
ドキュメントの作成者が在籍している場合は各々で整理することもできますが、退職済みの方々のドキュメントは編集したり、アーカイブしにくい問題がありました。
そして、私がクラウドワークスに入社してからエンジニア向けのドキュメントを読み進めていく中で、プロダクト開発や運用関連のドキュメントが散在しており、適切な情報を探すのが大変なところに課題を感じていました。
そのため、「SREの探求 19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合」で記載されていることを参考にドキュメントツールの整理やドキュメント作成時のルールを検討することにしました。
ソフトウェア業界では全体的に、エンジニアリングドキュメンテーションに対する信頼感が低いものです。 Stack Overflowが2016年に実施した開発者調査( https://insights.stackoverflow.com/survey/2016#work-challenges-at-work )では、開発者が直面する課題の第２位がドキュメンテーションでした。
ドキュメントの作成や保守はつまらない仕事で、人事考課や昇進のプロセスでも評価されず報われないという意識がある場合には、予算すなわち時間の確保が難しくなります。
SREの探求 19章 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合から抜粋
やったこと
ドキュメント運用に関しては、エンジニア全体の問題であり SRE チームのみで対応するのは困難なため、EM と協力しながらプロジェクト的に作業を進めました。
実際にやったことは以下の通りです。
１. 現状のドキュメントツールの対象を洗い出して、利用方法を確認
歴史的経緯もあってドキュメント作成可能なツールは複数ありました。
具体的には、メインで利用しているドキュメントツールに加えて、共同作業が可能なドキュメントツールやグループウェアツールに付属しているドキュメントツール、そして、過去に利用していたドキュメントツールのアーカイブ（多くの情報は移行済み）などがありまして、チームや個人ごとに利用しているツールが異なっていたため、まずは対象を洗い出すことにしました。
２. 現状のドキュメントで中身の薄い内容のドキュメントを削除したり、アーカイブ
過去に社内のドキュメント作成促進のために中身の薄いドキュメントが作成されていたため、認知負荷が高くなっていました。
認知負荷の軽減のために対象の記事の削除を行なったり、アーカイブを実施しました。
３. 現状のドキュメントを分類するためにタグ付け
タグ付けされていないドキュメントを探すには現状のツールでは、検索機能を使って見つけるか、他のドキュメントにリンクされているドキュメントを見つける必要があり、読みたいドキュメントを探すのに手間取っていました。
そのため、過去のドキュメントを一つずつ確認しながら手作業でタグ付け作業を行いました。
タグ付けをする際にドキュメント作成者ではないので、タグ付けの判断基準に困るかもしれませんが、ドキュメントの編集者としてロールを獲得したので自己判断でタグ付けを行いました。
４. 入社時のオンボーディングで読んでほしいドキュメントに容易にアクセスできるようにポータルを作成したり、リンクを追記
入社したての人は、どの資料に目を通すべきか判断しにくいです。毎回検索して対象のドキュメントを見つけるのは効率が悪いため、読んでほしいドキュメントのポータルを作成したり、オンボーディングで必ず目を通すドキュメントにリンクを追記したりしました。
５. 利用頻度の低いツールやクローズドな情報になりやすいツールは、共同編集が出来て社内でオープンな情報になるツールに変更
同じ事業部でありながらチーム内に閉じていて、チームに所属していない人の場合に、対象のドキュメントにアクセスするには毎回権限を付与してもらう必要があり、不便に感じていました。
そのため、よりオープンで共同編集可能なツールに変更することにしました。
上記の作業は4月頃には完了していますが、ドキュメント運用は長期的な視点ではないと成果の判断をしにくいところがあると感じています。
しかし、数ヶ月たった今、ドキュメント運用の状況をふりかえってみると、ドキュメント運用のルールはイマイチ浸透できていない課題がありますが、オンボーディング用のドキュメントや新しいツールの活用では一定の効果があったのではないかと解釈しています。
さよなら sider.review いままでありがとう
背景
crowdworks.jp では、2016年3月頃から linter として sider.review を利用していました。
上記の記事にあるとおり、sider.review は今年いっぱいでサービス提供終了のお知らせがございました。
そのため sider.review で実行している linter を GitHub Actions に移行することになりました。
やったこと
sider.review で有効にしていた機能は以下になります。
- RuboCop
- Reek
- Querly
- Brakeman
- Misspell
- Secret Scan
RuboCop は GitHub Actions でも実行していたため、その他の機能を GitHub Actions で実現できるように移植しました。
Reek、Querly、Brakeman、Misspell の機能は reviewdog を利用して PR 差分のみ指摘を行うように変更しました。また、Secret Scan は実装が公開されていなかったため、代替ツールとして Secretlint を利用しました。
各種 lint を YAML ファイルで定義していく手間を考えると、sider.review が便利なことを改めて実感できました。長い間、linter 機能をご提供いただき大変ありがとうございました。
まとめ
SRE チームは crowdworks.jp のインフラを支えていることもあり、チームの中では最も歴史が長いチームです。比較的規模の大きいタスクから細かいタスクまで日常的に対応し続けることで crowdworks.jp の信頼性を日々高めています。
細かいタスクを上げるとキリがありませんが、来年も継続して安定的にサービスの維持に向けた活動を行なっていきます。
We're hiring!
クラウドワークスでは、各種サービスや各種ポジションでエンジニアを募集しています。 ご興味のある方は以下のリンクからご応募ください！
