SREチーム発足と今期の取り組みについて

はじめに

皆様、はじめまして。Findyでプロダクト開発部/SREとしてジョインしました安達（@adachin0817）と申します。今年の6月に入社し、ちょうど3ヶ月が経ちました。本日は、SREチームの立ち上げに関する0から1のプロセスと、今期の取り組みについてご紹介させていただきたいと思います。

SREチーム発足

2023年までは、バックエンドチームがインフラを担当していました。しかし、サービスの拡大に伴い、バックエンドチームのリソースが不足し、SRE的な改善が十分に行えない状況が続いていました。そこで、昨年からSREの大矢とチームリーダーの下司（@gessy0129）がジョインし、現在は3名体制で活動しております。

SREチームの位置づけとミッション

SREチームは横断的なSRE活動をしており、これを「横断SRE」と指しています。一方で、各プロダクトにおいてSRE的な役割を担っていたメンバーは「Embedded SRE」と呼ばれ、引き続き改善活動を担当しています。

SREチームは現在、チームを作り上げていく段階にあり、まだまだやることが多く残されています。こうした背景を踏まえ、SREチームの短期および中期におけるミッションを設定しました。

短期ミッション
- 「ファインディの事業成長を支えるための、SRE組織のあり方の確立」
中期ミッション
- 「社員全員が事業成長に集中できような仕組みを構築し、提供する」
SREの存在意義
- SREは道を作るために存在する
- リスクを受け入れ、管理する
- SLOを計測する
- トイルの削減
- モニタリングする
- 自動化する
- 他プロダクトの支援

SREチームの業務の進め方

アジャイル開発手法を採用しており、各メンバーにはそれぞれIssue（タスク）が割り当てられます。一週間イテレーションで管理し、Issueのクローズを目指しています。毎朝、GitHubのProjectsを使用してカンバンボードを確認し、今日のタスクや困っていることを共有や、雑談をしています。また、毎週金曜日にはチーム全体で振り返りを行い、Findy Team+を活用しながら内容をKibelaに記録し、全員が閲覧できるようにしています。さらに、隔週でEmbedded SREチームとのお茶会も実施しており、取り組みたいことを共有する場を設けています。

カンバン/ステータス

ステータス	内容
To Do	Issueを作成した状態、未着手
Parent In Progress	親子関係のあるIssueの親
In Progress	進行中のIssue
Done	対応が完了したIssue

では、今期SREチームの取り組みについてご紹介していきたいと思います。

今期の取り組みについて

全環境のTerraform import化

これまで全ての環境がTerraformで完全にコード管理されていない状態でしたが、現在は全リソースをコード化することで一元管理を実現し、環境間での設定の整合性が保たれるようになりました。まずは既存の設定を棚卸しし、リソースをインポートすることで、今後の変更や拡張がより容易になっています。さらに、Terraform Cloudを活用しながら、今後はmodule化を進めて、効率的でスケーラブルなインフラ管理を目指しています。

Findy Toolsのインフラ改善

私が入社してからFindy Toolsのインフラ改善として、いくつか対応していきました。まずは、RDSのSSL/TLS証明書更新とAuroraのマイナーバージョンアップを開発環境から本番環境まで3日で実施しました。次に監視とオブザーバビリティの強化では、元々はインフラリソースをモニタリングしておらず、SentryのエラートラッキングとAPMのみでした。そこでDatadogでのインフラリソース(ECS、外形監視、CloudFront、RDS、イベントログ、WAF)、APMなどを対象に、アラートをTerraformで管理し、ダッシュボードを手動で運用するようになりました。普段見えていなかった部分がオブザーバビリティの向上によって可視化されていきました。

また、SLI/SLOの策定を進め、ページ表示速度やリクエスト成功率の目標を設定し、エラーバジェットとバーンレートの管理を進めていきました。SLOの振り返りは隔週で実施しており、アラートが発生した際に、開発メンバーと改善案を話し合えることは非常に重要だと感じています。

最後に、Rails serverやNode.js、MySQL8の開発環境の構築を改善し、Justfileを活用して自動化を進めました。JustはMakefileと比較すると、シンプルで直感的な構文で、シェルスクリプトに似ています。また、依存関係の管理が簡単なため、学習コストも低いです。これにより、開発メンバーはスピーディーに構築できるようになりました。以下フロントエンドのJustfileになります。

Frontend Justfile

# Justfile for setting up development environment

# Install Homebrew and essential packages
install_homebrew:
    @echo "Installing Homebrew if not already installed..."
    @if ! command -v brew >/dev/null 2>&1; then \
        /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"; \
    else \
        echo "Homebrew is already installed."; \
    fi

install_essential_packages:
    @echo "Installing essential packages..."
    brew install coreutils curl git

# Configure Git
configure_git:
    @echo "Configuring Git..."
    git config core.ignorecase false

# Install asdf and Node.js
install_asdf:
    @echo "Installing asdf if not already installed..."
    @if ! command -v asdf >/dev/null 2>&1; then \
        brew install asdf; \
        echo -e "\n. $(brew --prefix asdf)/libexec/asdf.sh" >> ${ZDOTDIR:-~}/.zshrc; \
    else \
        echo "asdf is already installed."; \
    fi

install_nodejs:
    @echo "Installing Node.js..."
    @if ! asdf plugin list | grep -q 'nodejs'; then \
        asdf plugin add nodejs; \
    else \
        echo "Node.js plugin is already added."; \
    fi
    asdf install nodejs
    asdf reshim nodejs

# Install mkcert and create certificates
install_mkcert:
    @echo "Installing mkcert if not already installed..."
    @if ! command -v mkcert >/dev/null 2>&1; then \
        brew install mkcert; \
        mkcert -install; \
    else \
        echo "mkcert is already installed."; \
    fi

create_certificates:
    @echo "Creating local certificates..."
    mkcert -cert-file localhost.pem -key-file localhost-key.pem localhost 0.0.0.0 hoge-web

# Install npm packages
install_npm_packages:
    @echo "Installing npm packages..."
    npm ci

# Run all tasks
all: install_homebrew install_essential_packages configure_git install_asdf install_nodejs install_mkcert create_certificates install_npm_packages

これらの改善については、7月の弊社DevRelイベントでLTを行いましたので、まだご覧になっていない方はぜひスライドをご確認ください。

findy.connpass.com

speakerdeck.com

AWSセキュリティ周り向上

AWSセキュリティの強化策として、Security Hubの実装を検討しましたが、予想以上の導入工数と既存ダッシュボード機能の現状を考慮した結果、我々の要件により適した別のアプローチを模索することにしました。複数のSaaSセキュリティサービスを検討し、最終的にShisho Cloudを選定しました。Shisho Cloudは使いやすさとコスト面で現在のファインディ社の課題にマッチしており、現在はAWSセキュリティポリシーガイドラインを作成し、Embedded SREチームと協力して対応を進めています。

「Findy Team+」オブザーバビリティ周り強化

Findy Toolsで培ったオブザーバビリティやSLOの経験を活かし、Findy Team+のSRE支援も行いました。元々設定されていたDatadogのアラートはTerraformで管理されていなかったため、まず棚卸しをし、全てをTerraformでimport化しました。しきい値などは次のように環境変数で管理し、テンプレート化することで他のプロジェクトにも適用可能にしました。SLOの策定にはまだ改善の余地がありますが、今後はミッションクリティカルな領域にも取り組んでいき、開発メンバーと振り返りを実施していく予定です。

rds.alert.tf

resource "datadog_monitor" "rds_cpu_alert" {
  name               = "[${var.service_name}]rds_cpu_alert"
  type               = "metric alert"
  query              = "avg(last_5m):avg:aws.rds.cpuutilization{rds:${var.service_name}-${var.environment}} by {dbinstanceidentifier} > ${var.rds_cpu_critical_threshold}"
  escalation_message = "RDS CPU usage for ${var.service_name}_${var.environment} instance has exceeded ${var.rds_cpu_critical_threshold}%"
  notify_no_data     = false
  notify_audit       = false
  timeout_h          = 1
  include_tags       = true

  monitor_thresholds {
    critical = var.rds_cpu_critical_threshold
  }

  message = <<-EOT
    @${var.slack_channel}
  EOT

  tags = local.combined_tags
}