こんにちは、ツクリンクでSREエンジニアをやってるida.です。
私がツクリンクに入社してまもなく2年が経とうとしていますが、SREチームもそれと同時に立ち上がったチームで、2周年を迎えようとしています。
時が経つのは早いもので、この2年間でSREチームが取り組んできたことを整理し、3年目以降の方針を見つめ直したいと思います。
SREチームとは
SREはSite Reliability Engineeringの略で、日本語ではサイト信頼性エンジニアリングと訳されます。Googleが提唱した概念で、ソフトウェアエンジニアリングの手法を用いてシステムの信頼性を担保する役割を担います。
私もツクリンクへの入社前はアプリケーションエンジニア、クラウドエンジニア、インフラエンジニア、情シスとして働いていましたが、SREチームに属するのは初めての経験でした。
SREチームの責務定義
ツクリンクのSREチームでは、責務を以下の6つの柱をもとに整理しました。
- 信頼性の維持・インフラ監視
- セキュリティ対応
- 障害対応
- コスト最適化
- サービス・開発効率化
- インフラ開発
これらの柱と達成すべきKPIを定め、KSF（Key Success Factor）にタスクを落とし込むことでロードマップを作成しました。このロードマップによって、チーム内外に対して明確な方針を示すことができるようになりました。
2年間の主な取り組み
タスク管理体制の構築
まず、チーム運用面でタスク管理体制を整理しました。SRE立ち上げ前の前身のインフラチームは1名体制で個人管理しやすい形式で運用されていましたが、2名体制への拡大と責務の拡大に伴い、Notionでタスク管理体制を構築しました。どのタスクを誰がいつまでに実行するかを可視化し、チーム外のメンバーも進捗状況を把握できるようにしました。
開発環境の標準化
各自のローカルに各種ツールをインストールして開発を行うとバージョンに差が出てきたり、オンボーディングにも時間がかかるのでDocker環境を整備し、開発環境の標準化を行いました。これにより、チームメンバー間での環境差異を解消し、開発効率の向上を図りました。
詳しくはこちらで公開しております。
インフラ基盤の刷新（Heroku から AWS への移行）
2023年9月まではHeroku上でツクリンクを運用していましたが、リソースの調整や耐障害性等の課題があり、AWS移行を実施しました。同時にIaC（Infrastructure as Code）化にも取り組み、全てのインフラをTerraformで管理できるようにしました。
AWS移行については、EMのあっきーさんがスライドにまとめてくれています。
昨今の技術の発展を見ていると、IaC対応しておいて良かったなと改めて思います。マネジメントコンソールで手動対応していたら、現在のような迅速な対応は困難だったと思います。
スロークエリの改善
移行当初は内部の管理システムも含め、5秒を超えるスロークエリが多数存在していました。リクエストの分析を行いスロークエリを洗い出した後、優先度をつけてクリティカルなリクエストから順次解消していきました。結果として、ユーザー体験の大幅な改善を実現しました。
メール認証システムの強化
GoogleやYahooが発表したメール認証強化を受け、メール配信の信頼性向上のため、SPF、DKIM、DMARC対応を実施しました。これにより、メールの到達率向上とセキュリティの強化を両立しました。
監視・アラート体制の再構築
AWS移行に伴い監視ポイントが増加したため、監視体制を一から再構築しました。AWS CloudWatchとPagerDutyを活用したアラート体制を構築し、24時間365日の監視体制を整備しました。これにより、障害の早期発見と迅速な対応が可能になりました。
脆弱性診断の実施と対応
サービスからの情報漏洩を防ぐため、外部の専門機関による脆弱性診断を定期的に実施しました。診断結果の指摘事項に対して優先度をつけて対応することで、セキュリティレベルの継続的な向上を図りました。
AWSアカウント、権限管理の最適化
AWS Identity Centerを導入し、アカウント管理の一元化を実現しました。また、最小権限の原則に基づいた権限設計により、セキュリティリスクの最小化を図りました。
WAFルールの最適化
ツクリンクへは想定外のbotからのアクセスやスクレイピングアクセスがたまに集中して発生しアクセス過多がたまに発生していました。そこでAWS WAFを活用し、Webアプリケーションへの過剰のアクセスや攻撃を防御するルールを最適化しました。定期的なルール見直しにより、新しい攻撃手法に対応できる体制を整えました。
バックアップ管理の強化
データベースのバックアップ戦略を見直し、復旧時間目標（RTO）と復旧ポイント目標（RPO）を明確に定義しました。また、復元手順書を整備し、障害発生時の迅速な復旧を可能にしました。
プレビュー環境の構築
Pull Requestごとに自動でプレビュー環境が構築される仕組みを整備しました。これにより、開発者は実際の環境で動作確認を行えるようになり、品質向上と開発効率の向上を同時に実現しました。
こちらについて詳しくは以下で公開しております。
CI/CDパイプラインの最適化
CI/CDに時間がかかっており、リリース作業のボトルネックになっていたのでワークフローや処理を見直しました。並列処理の活用やキャッシュの最適化を行うことで、従来50分かかっていたリリースワークフローが20分に短縮しました。これにより開発者の待機時間を大幅に削減し、開発サイクルの高速化を実現しました。
コスト最適化
サービス運用コストと開発ツールのコストを可視化し、継続的な監視体制を構築しました。余剰リソースの削減や料金プランの見直しにより、AWSの利用コストを月額$1,500程度削減することができました。
（従量課金制恐ろしい。。）
フロントエンドアーキテクチャの刷新
2024年にフロントエンドとバックエンドの分離を行うため、フロントエンドのアーキテクチャ設計と構築を実施しました。
フロントエンドの分離については以下で詳しく触れられています。
アーキテクチャ設計では複数のサービスを検討しましたが、運用性とコストを総合的に判断し、既存のECS構成を拡張する形で実装しました。
検討内容について詳細は以下の記事で詳しく紹介しています。
スケジュールされたタスクの信頼性向上
ECSのスケジュールされたタスクで動作していたバッチ処理において、起動エラー時の人知れぬ停止という課題がありました。当時は起動エラーが発生する度にオンコールで対応してました。
ちなみに、当時は以下のような形で監視して対応してました。（懐かしい）
この課題を解決するため、AWS Step FunctionsからECSタスクを起動する構成に変更しました。これにより、起動エラー時の自動再試行が可能になり、現在までオンコール対応は発生していません。
インフラ基盤の技術スタック更新
Terraformを1.5系から1.10系へバージョンアップ、AWS Providerを4.16系から5.92系にメジャーバージョンアップしました。これにより、新しい機能の活用と安定性の向上を実現しました。
2年間の成果と今後の展望
達成した成果
SREチームとして2年間活動した結果、以下の成果を達成することができました。
- サービス稼働率100%: 直近1年間でSRE起因のインシデントやサービス停止は発生せず、安定稼働を維持
- 運用体制の確立: 責務の明確化とロードマップを用いた方針共有により、チーム内外での連携が円滑に
- 技術基盤の近代化: Heroku→AWS移行とIaC化により、スケーラブルで保守性の高いインフラを構築
- 開発効率の向上: CI/CD最適化により、デプロイ時間を60%短縮
- コスト最適化: 月額$1,500のコスト削減を実現
今後の改善ポイント
一方で、以下の課題も明確になっています。
属人化の解消
権限管理の最適化や休日・夜間のアラート対応体制の見直しにより、特定のメンバーに偏った業務を分散化していく必要があります。
AI活用による効率化
昨今のAI技術の発展を受けて、運用業務の自動化や効率化をさらに推進していく予定です。
継続的なコスト最適化
開発規模の拡大に伴うCI/CDツールのコスト増加に対して、ツールの見直しや実行内容の最適化を図っていきます。
セキュリティ強化
過去2回の脆弱性診断を通じて見えてきた課題について、AWSマネージドサービスやサードパーティ製ツールの導入を検討し、セキュリティレベルのさらなる向上を図ります。
今後の取り組み予定
残りのリソースを活用して、以下の技術的負債の解消と新機能の導入を進めていく予定です。
- 検証環境、管理システムのSAML認証導入によるセキュリティ強化
- 生成AIを活用した開発体験（DX）の向上
- ボトルネックとなっている処理のリアーキテクチャ
おわりに
2023年にSREチームを組織してからの2年間を振り返ると、チームの立ち上げから運用基盤構築、責務の拡大まで、私自身の成長とともにチームも成長させることができたと感じています。
SREチームとしての基盤は整ってきましたが、本来の使命である信頼性の維持はもちろん、セキュリティの強化や業務効率化など、まだまだ改善できる領域があります。これからもチーム一丸となって、プロダクトの成長に貢献していきたいと思います。
Discussion