まずTopotalにご相談いただいた背景を聞かせてください。

FiTでは、次世代型フィットネスジム「LifeFit」を運営しております。「LifeFit」は、アプリで最短1分・24時間いつでもジムの利用が開始でき、リーズナブルな料金体系で、チケットを購入するだけですぐに利用できる次世代型フィットネスジムです。初期費用や登録手数料などは一切不要で、今までジムに通えなかった、または継続できなかった方々も利用しやすいシステムと料金体系で、気軽にご利用いただけます。2022年1月に1店舗目をオープンし、2024年5月には オープン予定の店舗含め50店舗まで拡大しています。 アプリの利用者も昨年比で5倍以上のユーザー様にご利用いただいています。

ビジネスが急成長していることで、アプリのシステム基盤であるAmazon Web Service LightSail（以下LightSail）の課題が顕在化してきました。LightSailは低コストで素早くサービスの構築・提供できますが、ビジネスの急成長に合わせた柔軟な設計やシステム監視ができません。具体的な問題は4つありました。

1つ目はスケーリングの問題です。ユーザー数やトラフィックの増加に対して自動でスケーリングできないため、負荷が高くなりやすい環境になっていました。

2つ目は監視の問題です。ログの保存期間が3日と短く、障害発生時の調査が困難な状況でした。加えてログの永続化もできていない状態であり、監視体制が十分ではありませんでした。

3つ目は、冗長化ができないという問題です。データベースのスケーリングやアクティブ・スタンバイ構成もできないため、いずれかのサーバーが停止するとシステム全体が停止してしまう状況でした。

最後に、リリース時にダウンタイムが必ず発生するという問題です。店舗オーナー様が重要なステークホルダーですから、ダウンタイムがある場合には店舗オーナー様との調整が必要になります。LightSailの環境では、リリースのたびに店舗オーナー様と調整しなければならない状況でした。この問題はリリース頻度にも影響していました。開発した機能をすぐに提供したいですし、セキュリティの緊急パッチやバグフィックスなどにも迅速に対応したいと考えていました。しかし、先ほどの理由から定期的なリリース以外を行うことはできませんでした。

これらの問題を解決するために、LightSailからECSへ移行することを決めました。しかし、社内のメンバーだけではリソースが不足しておりなかなか進まない状況でした。そこでTopotalさんのSREにご相談しました。

Topotalが参画して、どのような変化がありましたか？

大きな変化は2つで、ECSへの移行とデプロイの頻度です。

ECSへの移行は、社内リソースの不足によりなかなか進んでいませんでした。その状況で4月からTopotalさんが参画し、5月から移行作業に着手いただき、10月には移行が完了しました。半年もかからずにLightSailからECS環境への移行が実現できたことが最も大きな変化でした。しかも特に問題も起きずに無事完了した点もたいへん助かりました。

デプロイやリリース作業は、特定のメンバーだけが行う状況でした。社内リソースは事業ドメインの開発に注力したいと考えていたので、デプロイやリリースに関する自動化やToil（手作業の繰り返し）の解消は後回しにしていました。ただ、移行後は弊社の開発規模を考え、全員で開発も運用も担っていきたいと考えていました。 それもあって、今回移行プロジェクトの初期段階にTerraformやtfactionを使った自動化、アプリケーション側のデプロイパイプライン、加えて手順書などのドキュメントの整備をしていただきました。

移行プロジェクトの初期段階から整備していただいたおかげで、移行前から開発チームのコストをほとんどかけずに日々の開発を行えているのは、本当に助かっています。移行後のいまではデプロイの頻度も多くなり、週に3回のデプロイをすることもあります。

開発チームの規模を考えると、誰かひとりに運用業務を任せることはリソースの配分としても難く、その人の負担も大きくなってしまいますよね。Topotalさんがドキュメントも含めて準備してくれた環境のおかげで、運用業務に対する意識が開発チーム全体で変わっていき、システムの開発と運用の両輪を開発チーム主導で回していけるようになってきたと感じています。

移行作業の中でどのような部分をTopotalにお願いしていましたか？

社内リソースだけではインフラのリプレースに注力するのは難しい状況だったので、Topotalさんにプロジェクト全体を主導して進めていただきました。

移行作業を進める中で難しい点はスケジュールに合わせてタスクを進捗させることでした。スケジュールはあらかじめ店舗オーナー様と調整が完了しているため、スケジュールの変更はできない状況でした。適切にスケジュールに合わせタスクの進捗と管理を行う必要があったので、その部分をTopotalさんに主導してもらう体制で進めていきました。

定例の中で、「このスケジュールでいくなら、このマイルストーンまでにはここまで終わらせておかないといけないよね」と1つひとつ認識を揃えながら進めました。その結果、私たちがやることは最終的な意思決定のみで済みました。

意思決定が必要な局面ではTopotalさんが選択肢とメリット・デメリットを提示してくれました。 それぞれの選択肢にはこういうメリット・デメリットがあって、こちらを選べばこのくらいの期間が必要になる、こちらにはこういうリスクが伴うなどの判断に必要な情報を漏れなく洗い出してきてくれます。 これにより、意思決定が非常にスムーズにできましたし、プロジェクト全体もスムーズに進められたと感じています。

具体的な例を挙げると、ダウンタイムなしで移行するのか、それともメンテナンスを入れて一気に移行するのかといった選択を迫られる場面がありました。 その際もTopotalさんからは、「ダウンタイムなしでもできるけれども、その代わり1か月ほど余分に時間がかかる。一方、ダウンタイムありで移行する場合は1か月早く完了できるが、その代わりメンテナンス作業が必要になる」といった具合に、選択肢とそれぞれのトレードオフが示されました。

私にとってはこの部分が非常に印象に残っています。こうした情報を適切に提示していただいたおかげで、意思決定がとてもスムーズにできたと感じています。

一般的には移行前後でよくシステム障害が起きますが、今回は問題なく移行できました。どういった工夫をしたのでしょうか？

システム障害は店舗オーナー様やアプリのユーザー様と多くのお客様にご不便をおかけすることになるため、移行作業を問題なく終わらせる必要がありました。

ですので、今回リスクを最小限にするためにステージング環境でのリハーサルをやりましたね。TopotalさんとGoogle Meetをつなぎっぱなしにして、本番当日とまったく同じ手順で一通りの作業を実施しました。そのリハーサルの中で、「ここは考慮しないといけないよね」とか「これは漏れていたね」といったいくつか改善点が明らかになりました。

リハーサルによって改善点を事前に洗い出すことができたことで、改めて事前準備の重要性を実感できました。そのおかげで万全の状態で本番当日を迎えられました。リハーサルには多少の時間を要しましたが、本番の移行作業をスムーズに進められたのですから時間を有効に使えたと言えます。

本番ではリハーサルと同じ手順を踏めばよいので迷うことなく安心して作業を進められ、事故なく移行を完了しました。やって本当に良かったなと思っています。

移行後は支援の内容や期待役割にも変化がありましたか？

現在Topotalさんの役割は、SREチームとしてシステム全体を見渡し、課題を抽出し、改善を進めていく役割になっています。これは、移行が完了したことで、移行後の整理やセキュリティ、分析基盤の相談などと課題が多岐にわたっているためです。ふわっとした課題も定例会やチャットを通じて、壁打ちの相談をしながら進めています。ポストモーテム文化をどのように組織に根付かせていくか、現在の事業フェーズにおいてセキュリティにどこまで投資すべきか、などを一緒に考えていただいています。

つまり、Topotalさんの役割は移行プロジェクトのリードから、SREの専門家としてシステム全体の課題解決に向けた相談役へとシフトしつつあるのです。私たちの組織やフェーズの変化に合わせて、Topotalさんに必要な支援の形を柔軟に変えていただいている印象を受けています。

印象的な活動としては、移行後の整理と分析基盤、運用改善ですね。

移行後の整理では、コストのことを考えて使わないリソースを積極的に削除していくという判断を実施いただきました。 移行に伴って使わなくなったリソースを残していたんですよね。リソースを消すのにためらいがありましたし、コストを許容できるのであれば残しておいた方が安心だと判断していました。しかし、Topotalさんは「もう使わないんだったら、削除していいよね」という判断をしてくださいました。冷静に考えればもう使うことはないわけですから、スナップショットを取っておけば問題なく消せるはずです。こういった点も提案いただけて、非常にありがたいと感じています。

分析基盤の対応では、分析基盤の対応にかけるリソースやコストを私たちの状況を考えてご提案いただけました。

運用改善は、Topotalさんに本当にまるっとやっていただいています。たとえば、定例の中でダッシュボードを見て、課題感や改善点を一緒に確認するんです。「このアラートだとちょっとノイズになって、アラートがあがりすぎるから調整した方がいいですね」とか議論して改善タスクを決めます。次の定例では改善が進んでいるといった状況です。

一つひとつの対応が私たちのことを考えて提案いただいていると感じますし、その改善の実行も早くとても助かっています。

定例会では開発チームのメンバーも、Datadogのダッシュボードを見て改善していく体制になっています。どのようにしてこの体制になったのでしょうか。

開発チーム全体でインフラ運用していく意識を持つために、Topotalさんが主導して課題をあげて開発チーム全体を巻き込んでくれたことが大きいと感じています。その1つとしてDatadogのダッシュボードは開発チームに良い影響を与えてくれました。

弊社のシステムはマイクロサービスアーキテクチャを採用しています。

各サービスごとのトラフィック量を見てみると、一部のサービスについてはアウトバウンドからのリクエストがないサービスとわかったんです。そうなると、そのサービスについては外部に対してポートを開けておく必要がないですし、ロードバランサーに接続しておく必要もありません。さらに、サービス間の内部トラフィックも発生していないようであれば、そのサービス自体を停止してしまってもいいかもしれません。

日頃ダッシュボードを見ることでこういった発見を開発チーム全体でできるようになりました。各々が発見できるようになったことで、開発チーム全体で改善のアクションにつなげられていると感じています。

最後にTopotalへひとことお願いします

弊社は多くの方に運動機会を提供するために、これからも事業を拡大していきます。その中でアプリの機能拡充や店舗数・ユーザー数の拡大に対応できるシステムの運用はとても重要です。

トラフィックが増加した際のパフォーマンスの維持やインフラ周りの技術的な課題などにも向き合っていく必要があります。他にも開発チームの規模も大きくしていく必要もあります。

私たちの会社や事業フェーズに合わせてその時々で必要とするSREの役割は変化していくはずです。そうした変化に合わせたご支援をいただきたいと思っています。

本日はありがとうございました。