こんにちは。SREチームの宮後（みやうしろ）と菊地です。

現在、多くの企業でSREチームが組織化され、さまざまな取り組みがおこなわれているかと思います。私達ニーリーにもSREチームが存在し、現在発足から2年目を迎えています。今回はニーリーのSREチームが発足からどのように歩んできたのかを紹介したいと思います。

チームのミッション紹介

まずは私達SREチームのミッションを紹介します！
ニーリーのSREチームでは次の２つをミッションに掲げて活動しています。

• 信頼性とアジリティの両立

• SLI/SLOの策定・測定に対して責任を持ち、開発チームとともに運用する

信頼性とアジリティの両立

SREの正式名称であるSite Reliability Engineeringの名前の通り、SREチームはサービスの信頼性を重視して活動しています。しかし、現在ニーリーは価値を素早く提供しサービスを拡大させていくフェーズにあります。そのため、過剰な信頼性を追求するあまり、アジリティを損なってしまっては事業成長にとって致命的なものとなります。信頼性はもちろん重要ですが、アジリティも同じくらい重要であると捉えて、この２つをバランスよく高めていくことがSREチームの重要なミッションだと考えています。

SLI/SLOの策定・測定に対して責任を持ち、開発チームとともに運用する

SREのプラクティスとして多くの方が最初に思い浮かべるのはSLI/SLOだと思います。私達も例に漏れずSLI/SLOを策定し運用しています。現在はSREチームの中で運用をしているのですが、運用を続ける中で開発チームも巻きこんで運用をおこなう必要性を感じ始めました。例えば、とある開発チームの変更でSLIが低下した際に、SREチームに閉じて運用をしていると原因の特定に時間を要してしまいます。また、SREチームだけで対処をしてしまうと開発者が原因に気づく機会を奪ってしまい、別のところで同じ事象を発生させてしまうかもしれません。
SLI/SLOはSREのプラクティスですが、開発チームを巻きこんで運用することでより信頼性の向上につながると考えています。

SREチーム発足までの背景

SREチームは2022年2月から活動を開始し、2022年3月にフルタイム4名、パートタイム2名の6名体制で正式なチームとして発足しました。

Park Directは始めはオフショアで開発されており、ローンチした後に内製化が行われました。アプリケーションの内製化は比較的スムーズに内製に寄せきることができたのですが、インフラはかなりの部分がブラックボックス化しており、なにか問題が起きたときに場当たり的な対応が行われているだけという状況でした。2021年末からホワイトボックス化に取りかかり、その中で多くの課題が見えてきました。当初はいわゆる「インフラチーム」のような立ち位置で立ち上げることを考えていたのですが、見えてきた課題の中には運用トイル、モニタリング、CI/CD、IaCといったSREのプラクティスに重なるものが多かったため、思い切って最初から「SREチーム」という名前で立ち上げました。今振り返ると、活動開始直後からDatadogのトライアルを始めるなどSREっぽい動きをしており、命名は間違っていなかったなと思います。

発足後はメンバーの入れ替わりはあったものの、5〜6名の体制を維持しており2023年11月時点では6名体制で活動しています。

チーム発足からこれまでの歩み

SREチームでは3ヶ月毎にメンバー全員で課題を出し合い、次の3ヶ月に取り組む内容を決めて対応するというissueドリブンな活動をしています。チーム発足から2年目を迎えたので、これまでどのような課題があり、どんな活動をしてきたのか少し紹介します。

インフラ改善に乗り出した１年目

1年目はチーム発足の背景にあったインフラのホワイトボックス化を進めていきました。ホワイトボックス化にあたり発覚した課題を少し載せてみましたが、小さなものから大きなものまで多岐に渡って課題が散在している状況でした。

• バックエンドで利用しているRedisがフロントエンドと同じEC2環境にのっている

• SQLがボトルネックになりパフォーマンス問題が多発

• スケールアウトするとスケジュール実行されるジョブが複数起動してしまう

• ElasticBeanstalkの設定ファイル（ebextensions）の肥大化により内容把握が困難だった

• 言語ランタイムのサポートが切れてしまっている

• etc…

今振り返るとすごくカオスな状況でしたね（笑）
これらの課題を一つずつ解決していくために試行錯誤を繰り返すのではコストが掛かりすぎると判断し、最終的にはドラスティックにインフラ構成をリアーキテクチャすることにしました。
リアーキテクチャ後は次のような構成となり多くの課題が解決されたことでシステムの信頼性は飛躍的に向上したと実感しています。

このリアーキテクチャ以外にも、以下のような優先度の高いトピックに取り組みました。振り返ってみると怒涛の1年目でした・・・。

• Datadog導入

  • トライアルと導入

  • アラートをCloudWatchから移行

• トイル撲滅

  • メンテナンスモードのツール化

  • Lambdaのエラー手動対応を効率化

• パフォーマンス測定・チューニング

  • DBのレコード数を増幅して影響の大きい機能を特定

  • 影響の大きい機能のパフォーマンスチューニング

• AWSの統制強化

  • 監査ログ導入

  • IAMロール分割、最小権限化

• CI/CD

  • フロントエンドが手動スクリプト実行でビルド・デプロイしていたのをCI/CD化

• DBのAurora移行

  • RDS for PostgreSQLからAuroraへ移行

SREミッションをより意識した２年目

1年目の取り組みでインフラの大きな課題は解決できたので、2年目からはよりチームミッションを意識した活動をはじめました。そこで、信頼性とアジリティに関わる取り組みを少し紹介します。

信頼性に対する取り組み

冒頭で述べたとおり、SREは信頼性の測定に責任を持つチームとして発足したのですが、1年目に信頼性を測定する（すなわちSLI/SLOを運用する）ところまでは行けませんでした。『SRE サイトリライアビリティエンジニアリング』（SRE本）や『サイトリライアビリティワークブック』を読むと「SREを始めるにはまずSLI/SLOを設定しなければならない」という気がしてくるのですが、1年目はリアーキテクチャを始めとするインフラの課題に取り組まなければなりませんでしたし、そもそもSLI/SLOを決めるために必要なオブザーバビリティが確保できていませんでした。

1年間で前述のような最優先課題が片付き、またDatadogに十分なメトリクスとログを集めることができるようになったので、「そろそろSLI/SLOを決めて運用しよう！」という話になり、一年越しでロードマップに積むことができました。

まずSRE本を参考にSLI/SLOを策定することで、信頼性を可視化し目標値を定義することからはじめました。

まずは計測しなければ始まらないので、ALBのメトリクスを使ってリクエストの成功率とレイテンシーの計測をおこない推移を確認しました。そこから数回に渡って計測箇所や粒度、閾値の見直しなどをおこないながら運用を続けています。

また、運用開始後はSREチームで毎朝SLOを含めたシステムメトリクスを確認するようになり、不穏な兆候を見つけたらすぐに対応することで信頼性の担保に寄与できるようになりました。

現在はよりユーザ満足度に近いSLI/SLOを策定すべく、クリティカルユーザージャーニーを定義し、そこからSLI/SLOを再定義することに挑戦しています。
この辺の詳しい内容はまた別の記事で紹介します！

アジリティに対する取り組み

SREのもう一つミッションであるアジリティに対する取り組みとして、開発者が任意に専用の（私達はfeature環境と呼んでいる）環境を構築できる仕組みを作りました。

ニーリーではdevelop環境、staging環境、production環境の3環境をAWS上に構築しています。開発者がローカル環境で開発/テストし、develop環境デプロイ後にQAがテストという流れで開発しています。しかし、3環境+ローカル環境での開発では次のような課題や要望がではじめました。

• develop環境デプロイ後でなければQAがテストできない（開発者とQAによるパラレルテストができない）

• 大規模な改修のテストをdevelop環境とは別の環境で実施したい

• AWS上でしか検証できない事象を、develop環境以外で検証したい

これらの課題や要望を受け、SREチームではPull Requestの単位で独立して動作するfeature環境を構築する仕組みをつくることで解決しました。現在、feature環境は開発者やQAに毎日利用してもらっていて嬉しい限りですが、想定よりコストがかかっているという悲しい面もでてきたので鋭意コスト削減を進めています(^_^;)。ただ、feature環境の導入によりテストのシフトレフトへの寄与や検証の効率性も向上してきているので、アジリティ向上に大きく貢献できていると感じています。feature環境の具体的な実現方法についてはまた別の記事で紹介したいと思います。

現在の取り組み

現在、SREチームでは信頼性やアジリティに対する対応を継続しつつ、マルチプロダクトの運用を見据えた対応をおこなっています。
ニーリーはPark Directとは別に法人向けにPark Direct for Businessというサービスを展開しています。Park Direct for BusinessはPark Directと同様にサービスを拡大するフェーズにありますが、Park Directに比べてシステムに対する知識が属人化していたり、オブザーバビリティが不十分で確認できるシステムデータが少ないといった課題があります。

SREチームではこれらの課題に対処するために、まずはシステム構成図を作成してメンバー全員が現状を理解することから始めています。図示することで見えてなかった課題に気づくことができたので今後の改善につなげていきたいと思います。

現状把握とは別に、クリティカルな事象に対する監視の強化も進めています。Park Directでももちろん監視を設定していますが、いわゆるオオカミ少年アラートが多発していたことを受けて監視設定の基準の見直しをおこないました。Park Direct for Businessも同様の基準で監視強化を進めていく予定ですので、今後の新規プロダクト誕生に備えて監視の型化をおこなっていければと考えています。

その他にも、AWS IAM Identity Centerによる複数AWSアカウントのIAMユーザとポリシー一元管理などマルチプロダクトの運用を見据えた対応をおこなっています。

今後やりたいこと

SREチームではチーム発足から現在に至るまでさまざまなことにスピード間をもって対応してきました。しかし、このタイミングでスキルイネイブリングに対して課題感を持ち始めています。

スキルイネイブリングは一般的に「個々のメンバーが必要なスキルや能力を向上させ、成長させるプロセス」を指すかと思います。

SREチームの各メンバーはそれぞれ得意領域を持っており、スピードを意識してきたことでどうしても得意なタスクに偏って対応する状態になっています。今までは信頼性に関わるクリティカルな課題が多数存在していたので致し方ない部分はあったと思います。しかし、以前と比較してシステムが安定してきたこのタイミングで、各メンバーが他領域のスキルを獲得しやすくなるようなスキルイネイブリングの仕組みづくりをおこなっていきたいと考えています。例えば普段の業務の中で不得意な領域のタスクを担当し、他メンバーのサポートを受けながら熟していくなどして挑戦しやすい環境を作っていければと思っています。

また、他にもシステム面で以下のような取り組みも実施していく予定でいます。

• バックエンドのパフォーマンス改善

• 社内で利用しているBIツールのRedashの信頼性向上

• Four Keysの一つであるサービス復元時間の計測

• インフラ関連の監査ログの整備

• インフラ関連のセキュリティ強化

最後に

SREチームは信頼性とアジリティの両立をミッションに活動しています。
ニーリーの事業は急成長を続けており、今後は新規プロダクトも増え横にも縦にも成長していくと思います。そんな中、信頼性とアジリティを両立させることは難しくもありますが、やりがいのあるミッションだと感じています。今後さまざまな課題に挑戦していくのでニーリーに少しでも興味をもっていただけたら、気軽にお声がけください！

株式会社ニーリー　プロダクト開発本部　プラットフォーム開発グループ
宮後 啓介　Keisuke Miyaushiro
2011年に株式会社日立ソリューションズに新卒入社。Web系業務システムのスクラッチ開発に従事。2017年2月にヤフー株式会社に入社。Yahoo!メール、PayPayフリマのサービス開発やSWATとして複数サービスの開発支援に従事。2023年3月に株式会社ニーリーに入社。

株式会社ニーリー　プロダクト開発本部　プラットフォーム開発グループ　SREチーム/QAチームリーダー　
菊地 弘晃　Hiroaki Kikuchi
2017年、DMM.comに新卒入社。動画配信事業部にてVR動画、4K動画のローンチに携わるほか、動画分散エンコードシステムの開発、動画プレイヤーのUI/UX改善などを担当。2021年11月に株式会社ニーリーにジョイン。Park Direct開発部SREチーム/QAチームのリーダーとして従事。

herp.careers O01【エンジニア】オープンポジション

株式会社ニーリー

募集要項をみる

■開発メンバーとのカジュアル面談はこちら

・三宅 克英（取締役CTO）
モビリティSaaSのプロダクトグロースについてお話しましょう

・菊地 弘晃
Mobility SaaSを一緒に開発しませんか？