※この記事は「Zenn ツクリンクでSREチームを組織して2年経った現在地と3年目に向けて」をリライトしたものとなっています。
こんにちは、ツクリンクでSREエンジニアをやってる泉田です。
私がツクリンクに入社してまもなく2年が経とうとしていますが、SREチームもそれと同時に立ち上がったチームで、2周年を迎えようとしています。
時が経つのは早いもので、この2年間でSREチームが取り組んできたことを整理し、3年目以降の方針を見つめ直したいと思います。
SREはSite Reliability Engineeringの略で、日本語ではサイト信頼性エンジニアリングと訳されます。Googleが提唱した概念で、ソフトウェアエンジニアリングの手法を用いてシステムの信頼性を担保する役割を担います。
私もツクリンクへの入社前はアプリケーションエンジニア、クラウドエンジニア、インフラエンジニア、情シスとして働いていましたが、SREチームに属するのは初めての経験でした。
ツクリンクのSREチームでは、責務を以下の6つの柱をもとに整理しました。
これらの柱と達成すべきKPIを定め、KSF（Key Success Factor）にタスクを落とし込むことでロードマップを作成しました。このロードマップによって、チーム内外に対して明確な方針を示すことができるようになりました。
まず、チーム運用面でタスク管理体制を整理しました。SRE立ち上げ前の前身のインフラチームは1名体制で個人管理しやすい形式で運用されていましたが、2名体制への拡大と責務の拡大に伴い、Notionでタスク管理体制を構築しました。どのタスクを誰がいつまでに実行するかを可視化し、チーム外のメンバーも進捗状況を把握できるようにしました。
各自のローカルに各種ツールをインストールして開発を行うとバージョンに差が出てきたり、オンボーディングにも時間がかかるのでDocker環境を整備し、開発環境の標準化を行いました。これにより、チームメンバー間での環境差異を解消し、開発効率の向上を図りました。
詳しくはこちらで公開しております。
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 Identity Centerを導入し、アカウント管理の一元化を実現しました。また、最小権限の原則に基づいた権限設計により、セキュリティリスクの最小化を図りました。
ツクリンクへは想定外のbotからのアクセスやスクレイピングアクセスがたまに集中して発生しアクセス過多がたまに発生していました。そこでAWS WAFを活用し、Webアプリケーションへの過剰のアクセスや攻撃を防御するルールを最適化しました。定期的なルール見直しにより、新しい攻撃手法に対応できる体制を整えました。
データベースのバックアップ戦略を見直し、復旧時間目標（RTO）と復旧ポイント目標（RPO）を明確に定義しました。また、復元手順書を整備し、障害発生時の迅速な復旧を可能にしました。
Pull Requestごとに自動でプレビュー環境が構築される仕組みを整備しました。これにより、開発者は実際の環境で動作確認を行えるようになり、品質向上と開発効率の向上を同時に実現しました。
こちらについて詳しくは以下で公開しております。
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系にメジャーバージョンアップしました。これにより、新しい機能の活用と安定性の向上を実現しました。
SREチームとして2年間活動した結果、以下の成果を達成することができました。
一方で、以下の課題も明確になっています。
属人化の解消
権限管理の最適化や休日・夜間のアラート対応体制の見直しにより、特定のメンバーに偏った業務を分散化していく必要があります。
AI活用による効率化
昨今のAI技術の発展を受けて、運用業務の自動化や効率化をさらに推進していく予定です。
継続的なコスト最適化
開発規模の拡大に伴うCI/CDツールのコスト増加に対して、ツールの見直しや実行内容の最適化を図っていきます。
セキュリティ強化
過去2回の脆弱性診断を通じて見えてきた課題について、AWSマネージドサービスやサードパーティ製ツールの導入を検討し、セキュリティレベルのさらなる向上を図ります。
残りのリソースを活用して、以下の技術的負債の解消と新機能の導入を進めていく予定です。
2023年にSREチームを組織してからの2年間を振り返ると、チームの立ち上げから運用基盤構築、責務の拡大まで、私自身の成長とともにチームも成長させることができたと感じています。
SREチームとしての基盤は整ってきましたが、本来の使命である信頼性の維持はもちろん、セキュリティの強化や業務効率化など、まだまだ改善できる領域があります。これからもチーム一丸となって、プロダクトの成長に貢献していきたいと思います。
/assets/images/1114/original/cf19364c-1cc3-4cce-97d5-57fbb0d8cafb?1570003494)
/assets/images/1114/original/cf19364c-1cc3-4cce-97d5-57fbb0d8cafb?1570003494)
/assets/images/1114/original/cf19364c-1cc3-4cce-97d5-57fbb0d8cafb?1570003494)
/assets/images/1114/original/cf19364c-1cc3-4cce-97d5-57fbb0d8cafb?1570003494)
