天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

<ユーザベース×ログラス共同開催> SaaSプロダクトを支えるSREの取り組みに参加してきた

uzabase-tech.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

今回は「SaaSプロダクトを支えるエンジニアの自社の取り組み」をテーマに、自社SaaSプロダクトを持つユーザベースとログラスの事例を2つのセクション、2つのLTでお届けします。「SaaS企業のSREに興味・関心がある」や「インフラの取り組み事例を知りたい」等、プロダクトの運用の課題に向き合いサービスの価値を向上に挑む2社の取り組みについて興味がある方、ぜひ参加をお待ちしております。最後にQ&Aのお時間も設けておりますので、講演者に対する質問もお待ちしております!

会の様子

BtoB のSaaS プロダクトを提供するログラスでのクラウドインフラの立ち上げと関わり方

最初に勝丸さんから、ログラスさんでプロダクトのサービス価値を最短で顧客に届けるために、PMF前の初期フェーズでどのようなインフラ構築をしてきたのか?という話がありました。

サービス立ち上げ当初は、運用よりも機能開発ということで、インフラの観点からやりたいことはあったものの放っておけるようなインフラ構築を目指したそうで、ECS(Fargate)とAurora PostgreSQLを選択したそうです。
また、PMFした後に壊しやすいようにインフラはTerraform化し、k8sは不採用としたそうです。なお、CI/CDはCodepipelineを採用したというお話でした。
一方で、最低限のセキュアは担保したいと考えたそうで、AWS環境の分割をしたりログを1バケットに集約したり、DBのPWなどをすべてSSMに追いやったそうです。(コードにPWをベタ書きしないようにした)

プロダクトや組織が拡大する中での、ログラスにおけるクラウド・インフラに対する取り組み

勝丸さんの続きという形で、プロダクトや組織が拡大していく中でクラウド/インフラをどのように構築し直していったのか?という話を聴いていきました。

ログラスさんでは、ハニービーチーム(=各開発チームからボールが落ちてしまいそうな部分を特定の専門性を持った人がカバーしていくチーム)がクラウド/インフラの改善を行っているそうですが、初期フェーズからインフラの基本構成を大きく変えることはしておらず、ちょこちょこ構成の拡張をしているのがメインだということでした。この拡張自体はものすごい量が行われているそうですが、具体的には以下のような取り組みをしているそうです。

  • BGデプロイを実装し、安全なリリース方法を導入
  • AWS Aurora PostgreSQLのバージョンアップ
  • 開発支援/運用支援(専門性を生かしたサポート)
  • 定型作業や社内問い合わせの一次受け

これらの取り組みをしたことで、開発者からは開発に集中できるようになったというフィードバックや、サービス信頼性の向上というフィードバックなど、ポジティブなフィードバックを多数いただけたということでした。

カスタムコントローラを利用したスパイクに耐えるオートスケーリングの仕組みを構築

続いてユーザーベースの杉山さんから、SREとしてどのような取り組みをしているのか?というお話がありました。

ユーザーベースさんでは、必要十分なキャパシティを確保するために、改善効果が得にくいものの簡単に導入できるスケールアウトを導入したそうです。

具体的にはk8s標準のHPA(水平スケーリング)を利用したということですが、HPAは急激なリクエストの増加に合わせてスケールすることは困難なため、リクエストが増加する前にスケールしておく必要があるということで、メトリクスを用意し、閾値を超えたタイミングでReplicasを動的に変更する仕組みを導入したそうです。

技術的にはカスタムコントローラを活用したそうで、

  • 掃除のしやすさ
  • 拡張容易性
  • 監視性

を意識しながらカスタムHPAを実装したということでした。

SLOとあるサービスのお話

最後に酒井さんから、実際に稼働しているサービスを例に、SLOを策定したプロセスの発表がありました。

当初はSLOを決めていなかったそうですが、アラートが飛びすぎて大変だったり改善アクションをやる必要があるかの判断を明確な根拠を持って行うことが難しいことなどに課題感を持ったそうで、SLOがあった方がいいよね、という話になったということでした。

SLOの取り決めは、

  1. 現状把握/展開準備
  2. 開発チームへの共有
  3. PdMと共有
  4. 合意されたSLOの決定と監視設定の決定
  5. SLOの調整
  6. SLO運用の自立化(SLOを開発メンバーのものにしてもらう)

というステップで行ったそうです。

SLOを決めたことで、当初の課題感は一定解決され、実現したい状態に近づくことができたものの、

  • バーンレートで影響が低いケースを拾うことはある
  • 機能開発スケジュールとのバランスを考えるのが難しい
  • 利用者によってレイテンシーの幅が大きい場合の最適なSLOが難しい

という部分はまだ残課題としてあるということでした。

会全体を通した感想

PMF前後でクラウド/インフラがどのように変化するのか?という話を実サービスの事例をもとに聴くことができたのが非常によかったです。

また、どの発表も話の具体性が高かったのも個人的には満足でした。