https://tech.andpad.co.jp/entry/2025/12/19/100000

ANDPADアドベントカレンダー2025 19日目です！

開発本部SREチームの谷合です。
ｱｻﾋｨｽｩﾊﾟｧﾄﾞｩﾙｧｧｧｧｲが好きなエンジニアとして活動しています。
私からは、今年を振り返る意味でも、アンドパッドのSRE・DBRE・CREのご紹介と活動成果発表をします！

アンドパッドのSREチーム

(以降、弊社の呼称はアンドパッド、プロダクトはANDPADと明記します)

まず私の所属するSREチームがどのようなチームなのかをご紹介させてください。
アンドパッドのSREチームは開発本部の中に組み込まれているチームです。
ANDPADプロダクトを開発する各チームを横断で支援しています。

また、アンドパッドはマルチプロダクト戦略を採用しており、非常に多くの製品ラインナップがあります。
そのためSREチームは実に様々なチームの開発者メンバーと関わり、そのプロダクトの信頼性向上や、プロダクト共通のシステムの開発および運用を行っています。

andpad.jp

利用しているツールも多岐に渡り、以下のようにクラウドはAWSを中心にEKSやECSを運用しています。また、バックエンドにはRubyやGo言語が採用されているので、社内でも活発に学習の機会が存在します。

クラウドサービス： AWS, Google Cloud, Elastic Cloud
コンテナ：Kubernetes (EKS), ECS on Fargate, Linkerd, Cloud Run
バックエンド：Ruby, Go, Ruby on Rails, Sidekiq, Fluent Bit
CI/CD：Autify, CircleCI, GitHub Actions, CodeBuild, CodePipeline, CloudBuild, Bitrise, fastlane
オブザーバビリティ：Datadog, Bugsnag, Sentry
IaC：Terraform, CloudFormation, SAM
コミュニケーション：Slack, GitHub, JIRA, Confluence, esa

上記のように扱う技術領域が広いことから、SREとして業務の難しさはあるものの、非常に挑戦しがいのあるチームであると言えます。

これらは以下のスライドで語られているので、是非ご覧いただけると嬉しいです。 speakerdeck.com

上記スライドにも出てきますが、SREチームのミッションとして、開発組織が全力疾走するのに安全で丈夫な道が必要。アンドパッドSREはその道をつくるチームというものがあります。私たちは、このミッションを胸に日々開発組織の道を作っています。

SREチームとDBRE・SREチームの連携

まずは以下の図をご覧ください。

アンドパッドは SREだけでなく、DBREとCREのチームがある xREな組織を敷いています。

SREは主にプロダクトの信頼性やインフラ構築および改善が主な対応に対し、DBREはデータベースの信頼性やマイグレーション、新規構築、パフォーマンス向上に重きを置いています。また、SREから横断チームに跨って インフラコスト最適化（FinOps）が伸びていますが、これは後述します。

そんなCREと、SRE、DBREがどのように連携しているかをインシデント対応のシチュエーションを例に、軽くご紹介します。インシデント発生時はCREがインシデントコマンダーと連携し、以下の対応を行い、開発チーム、SRE、DBREが連携し、解決に当たります。

1. インシデント緊急性を精査
2. インシデント対応用Slackチャネル開設
3. インシデントコマンダーと連携し、影響調査や開発チーム、SRE、DBREなど各方面へ報告
4. インシデント対応と並行して、ポストモーテム作成
5. 解決後はポストモーテムで振り返り会開催

このようにアンドパッドでは、CREが起点となり、SREとDBRE、開発チームを巻き込んで組織的にインシデントに立ち向かいます。

今年の活動

ここからは、SRE・DBRE・CREの今年の活動をお見せできる範囲でご紹介したいと思います。

SRE

SREチームは、以下のように様々なタスクに取り組みました。

全社AWS IAMユーザをOktaを利用することでのSSO化
EKSバージョンアップにおけるオペレーション時間短縮（1時間半を10分程度に大幅短縮）
インフラコスト最適化
Linkerd ProxyのKubernetes Native Sidecar移行
アンドパッド初期からある不要な構成の除去
プロダクトのドメイン検討におけるプロセスの整備
ランタイムのEOL対応における不要AWS Lambdaの駆逐
Backstageを利用したサービスカタログ検証

どれも長期で対応して成果を出したものばかりですが、時間を掛けただけあって大きな成果が得られました。

この中で特に大きな成果のあった3つの取り組みをご紹介します。

全社AWS IAMユーザをOktaを利用することでのSSO化

これまでアンドパッドは全社的にIAMユーザを払い出して運用していました。
しかし、アクセスキー、シークレットアクセスキーの管理は個人に任されており、運用上およびセキュリティ面での大きな課題でした。
これをAWS Identity CenterとOktaを連携させ、SSO認証することで、定期的なログインパスワードのリセット、永続的なクレデンシャル管理、アカウントごとのMFAデバイス管理、などの手間などから解放されます。 profileを指定することで、AWSマネージドコンソールへのログインやAWS CLIの操作だけでなく、terraformやkubectlといったCLIコマンドも操作できるように整備しているので、非常に快適です。
ただ、まだ完全に普及できているかといったらそうではなく、これからさらなる普及を目指して行きます。

EKSバージョンアップにおけるオペレーション時間短縮（1時間半を10分程度に大幅短縮）

アンドパッドではEKSをバージョンアップする際は、以下の流れで行なっていました。

Clusterのバージョンアップ
新Managed Node Group（以降MNG）を作成
旧MNGからPodをEvict
Evictが完了するまで待つ
旧MNGを削除

これまで、クラスターのスケールダウン時（Evict処理）は、手順3～5の実行により、1クラスターあたりおよそ1時間から1時間半かかっていました。今回の改善では、以下の3つの自動化策を導入しました。

Cluster Autoscalerの設定変更
- 管理対象となるMNGの最小ノード数を0に設定し、Cluster Autoscalerがノード数を自動的に0までスケールインできるようにしました。
ノードへのTaint追加
- MNGが新しく払い出すノードに特定のTaint(NO_SCHEDULE)を自動で追加し、新規Podがそのノードにスケジューリングされないようにしました。
Deschedulerの導入
- Deschedulerを導入し、Taintに違反している（スケジューリングされている）既存のPodを自動的かつ徐々にEvict(追い出し)するようにしました。

つまり、従来人間が手動で行っていたノードの最小化とPodのEvict処理を、ClusterAutoscaler、Taint、Deschedulerの連携によって自動化しました。ここまででEKSのバージョンアップが完了します。
後日ノード数が0のManaged Node Groupを削除する対応とし、EKSのバージョンアップの時間短縮を図りました。
その時間の短縮具合が非常に素晴らしく、全体の時間を10分程度にまで劇的短縮しています。
これ以上ないアプローチでした。
最終的には以下のようにオペレーションを変更してます。

Clusterのバージョンアップ
新Managed Node Group（以降MNG）を作成
旧MNGの最小ノード数を0に変更
taintを設定し、Deschedulerが旧MNGのノードからPodをEvict
旧MNGのノード数が0になり、バージョンアップ完了
（後日）旧MNGを削除

インフラコスト最適化

さらに「インフラコスト最適化」がありますが、SREチームだけでなく開発チームと連携する横串チームとして活動しています。
大きなコスト削減の成果も出ており、後述する登壇発表を行なったり、社内表彰されたりしています。

その他の成果

これらに限らず、他の改善タスクも日々こなしており、どれもANDPADの成長には欠かせない仕事ばかりです。
これからもSREチームとして、大小様々なタスクをこなす中で、組織ないしプロダクトの成長に寄与して行ければと思います。

また、社内の仕事だけでなく、ブログや登壇といった外部発表も頑張りました！
前述したインフラコスト最適化に関する発表もありますので、是非ご覧ください！

tech.andpad.co.jp tech.andpad.co.jp speakerdeck.com

DBRE

DBREとしては、以下のタスクに取り組みました。

社内のデータベースのTerraformコード化
Aurora MySQLの認証プラグインのcaching_sha2_password 認証への移行
新規プロダクトのデータベースの成熟ロードマップの整備
SLI/SLOの整備
DatadogのDatabase Monitoringの導入 www.datadoghq.com

私自身元々データベースエンジニア出身なので、どれも「楽しそう」と見ていますww
データベースのIaC化や認証プラグインの移行など、開発チームに大きく影響がありそうなものから、新規データベースの成熟や、Database Monitoringなど意欲的なものも多く対応しています。
また、SREと同様に信頼性も大きな関心事です。DBREもSLI/SLOは常に意識して仕事しています。
今後はさらなるデータベースの探求や、SLOの運用の成熟、Observabilityの強化を行なっていきます！

先に述べたcaching_sha2_password 認証への移行の話は登壇で発表もしていますので、是非ご覧ください。 tech.andpad.co.jp speakerdeck.com

本記事では SREとの協業に焦点を当てましたが、DBREチームではデータベースのキャパシティプランニングやモニタリング、パフォーマンスチューニングなど、広範な独立した責任を担っています。

CRE

CREのメインの業務は開発部門への問い合わせ対応における一次調査となります。
SREやDBRE側からすると、良き隣人であると同時にインシデント対応時の頼れるチームです！
そんなアンドパッドのCREの成果目標の一つが「ユーザーの不安を少しでも早く解決する」です。
それに向かって今年も様々なインシデントに立ち向かっていただきました。（本当に感謝しかありません）また、日々のクライアント対応の合間を縫って、CREでANDPADの機能開発まで行なっています。
是非そのブログ記事もご覧いただけますと嬉しいです！
また、今年のSRE Kaigi 2025では並みいる強豪の中で、登壇まで果たしています。
CREの5年史、是非ブログ記事と併せてご覧ください。

tech.andpad.co.jp speakerdeck.com

参加したカンファレンス

ここからは3チームが、今年は参加したカンファレンスやイベントをご紹介します。以下、主にチームで参加したカンファレンスです。今年は、SREやPlatform Engineeringのカンファレンスを中心に、Kubeconにも参加しました。

さらにSRE NEXT 2025では、コーヒースポンサーも務めさせていただき、社外のエンジニアの方とたくさんの交流と意見交換ができました！アンドパッドが何をやっているか、どこに向かうのかを知っていただけましたら幸いです。

／
bve #srenext 2025
＼
アンドパッドコーヒーブース、終了しました！
のべ 500 人の方に飲んでいただき、ありがとうございました！
また、 2026 でお会いできることを！ pic.twitter.com/U4ZRiKei2M
— ANDPAD (アンドパッド)開発部 (@andpad_dev) 2025年7月12日

また三田エリアへのオフィス移転に伴って、 Tamachi.sreにもアンドパッドのmuziyoshizが参加しており、年明け 1/16 に開催される Tamachi.sre #2 はアンドパッドが会場スポンサーを務め、 SRE チームマネージャーのDANが「小規模SREチームで支える、Atlantisで実現するインフラ管理のセルフサービス化」を発表します。ぜひお越しください。 https://tamachi-sre.connpass.com/tamachi-sre.connpass.com そして、 SRE Kaigi 2026ではmuziyoshizが「予期せぬコストの急増を障害のように扱う――「コスト版ポストモーテム」の導入とその後の改善」というタイトルを発表します。こちらもご期待ください。 2026.srekaigi.net

さいごに

ここまで、弊社アンドパッドのSRE・DBRE・CREのご紹介と活動成果発表を行いました。
改めて書くと、色んなことやっているなといった印象と同時に、まだまだやりたいことは山ほどあるんだ！という熱い気持ちが溢れてきました。
来年もアンドパッドは止まらずに、成長をしていくでしょう。その中でSRE・DBRE・CREチームはANDPADをユーザの皆さんが安心して使っていただけるように、情熱を注いで仕事していきます。
が、それをやるためにはまだまだチームにパワーが足りません！後述する採用情報もご覧いただけると嬉しいです！

We are hiring!

アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。アンドパッドのSREチームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。

hrmos.co hrmos.co hrmos.co github.com