Tweet
Tweet

Slide 1

Slide 1 text

2024/07/10 StRE#1 スタートアップ企業のSREに立ちはだかる壁と乗り越え方 株式会社ニーリー プラットフォーム開発部 SREチーム 大木建人 NEALLE 信頼性とアジリティの両輪で進む スタートアップSRE 1

Slide 2

Slide 2 text

ことスタートアップのSREは スピード感を持って成長するプロダクトと伴走すること が多々あると思います。 そのようなプロダクトと向き合い、 どのようにして伴走するのかは 大きな課題だと思います。 その中で我々はどのように伴走してきたのか の話をしたいと思います。 1｜会社概要 2

Slide 3

Slide 3 text

その中でテーマとして、 「信頼性とアジリティの両立」がありました。 1｜会社概要 3

Slide 4

Slide 4 text

About Me 1｜会社概要 4

Slide 5

Slide 5 text

5 氏名 所属 経歴 大木 建人 ／ Kento Ogi 株式会社ニーリー プロダクト統括本部 プラットフォーム開発G SREチーム 趣味 夏はボルダリング🧗 冬はスノーボード🏂 2018-2020 　大学で強化学習の研究 & インターンでAWSにハマる 2020-2023 　新卒で合同会社DMM.comへ入社 SRE 2023- 　株式会社ニーリー SRE 自己紹介 @2357gi @2357gi

Slide 6

Slide 6 text

6 プロダクト紹介

Slide 7

Slide 7 text

7 爆速成長中💪 プロダクト紹介

Slide 8

Slide 8 text

1｜会社概要 8 最初は最速でローンチするためにオフショアで開発 AWS上にElastic Beanstalkで作成 運用でカバーする箇所は残ったが、 スピード感を持ってローンチすることができた 自社開発に移行 AWS環境の諸々を修正したり、 自社開発体制を整えたりしていた

Slide 9

Slide 9 text

1｜会社概要 9 リリースは、隔週に一度の深夜に社員が持ち回りで行っていた。 月イチでリリース当番が回ってくる、なかなか辛い体制だった。 また、デプロイフローもscript手実行によるファイルばら撒き Elastic Beanstalkのお守りもなかなか大変！！ リリース辛すぎる！！！ 明確なペイン！！！！！ SREingよりも先に、 インフラのブラッシュアップや最適化を優先して実施することに

Slide 10

Slide 10 text

10 ・Elastic Beanstalkの設定ファイルの肥大化 ・なんならEC2にRedisまで乗っている ・スケールアウトするとバッチが多重起動 ・SQLがボトルネックになりパフォーマンス問題が多発 などなど... Elastic Beanstalkのお守りが大変 を深ぼると...

Slide 11

Slide 11 text

11 ・Elastic Beanstalkの設定ファイルの肥大化 ・なんならEC2にRedisまで乗っている ・スケールアウトするとバッチが多重起動 ・SQLがボトルネックになりパフォーマンス問題が多発 などなど... → ドラスティックにアーキテクチャの変更を決定 ECSへとお引越し！ 合わせてGithub ActionsによるCDも整備！ Elastic Beanstalkのお守りが大変 を深ぼると...

Slide 12

Slide 12 text

1｜会社概要 12 リリースタイミング ダウンタイム n年前 隔週の深夜 あり スタートアップ、ガンガンプロダクトアップデートさせたい 開発のフロー効率をあげたいという強い要望はあった CDは整備されても、リリースは隔週に一度の深夜だった 例えば、当時SEO対策のためにwebページの修正が頻繁に行われており、 その反映が隔週に一回なのはかなりしんどかった

Slide 13

Slide 13 text

1｜会社概要 13 リリースタイミング ダウンタイム n年前 隔週の深夜 あり 新しいリリース方式 いつでも なし デプロイフローの整備も実施 リリース内容によっては、 いつでもダウンタイムなしで リリースできるように！ リリース回数グラフ 青が深夜リリース方式、赤が新しいリリース方式

Slide 14

Slide 14 text

14 ECS化によりscript手実行でのデプロイも Github ActionsによるCDへ進化 デプロイ作業が楽になった また、デプロイフローの信頼性も向上した 明確なペイン！！！！！の解消！！！

Slide 15

Slide 15 text

15 デプロイフローの信頼性も向上したし、 アーキテクチャも綺麗になったし、 フロー効率あげるぞ！アジリティの向上に繋げるぞ！！

Slide 16

Slide 16 text

16 デプロイフローの信頼性も向上したし、 アーキテクチャも綺麗になったし、 フロー効率あげるぞ！アジリティの向上に繋げるぞ！！ 開発サイクルを早くして！ フロー効率向上！アジリティ向上！！

Slide 17

Slide 17 text

1｜会社概要 17 しかし... リリースには魔物が潜んでいる ゴゴゴゴゴ....

Slide 18

Slide 18 text

1｜会社概要 18 リリースで障害を起こしちゃった経験がある人いますか？ リリースで障害を起こしちゃった人を見たことがある人いますか？ ゴゴゴゴゴ....

Slide 19

Slide 19 text

1｜会社概要 19 リリースで障害を起こしちゃった人を 見たことがない人いますか？ ゴゴゴゴゴ....

Slide 20

Slide 20 text

1｜会社概要 20 どれだけ信頼性が高いリリースフローであれど、 どれだけテストをすれど、 リリースをする限り魔の手からは逃れられない ゴゴゴゴゴ....

Slide 21

Slide 21 text

1｜会社概要 21 どれだけ信頼性が高いリリースフローであれど、 どれだけテストをすれど、 リリースをする限り魔の手からは逃れられない アジリティを高くすると信頼性が侵される.....? ゴゴゴゴゴ....

Slide 22

Slide 22 text

1｜会社概要 22 Q.アジリティを高くすると信頼性が侵される.....? A. 確かにリリースによってメトリクスの悪化が引き起こされる ことがあった →信頼性の低下に繋がっている ゴゴゴゴゴ....

Slide 23

Slide 23 text

1｜会社概要 23 信頼性 アジリティ 信頼性とアジリティは事業のフェーズによって重要度が変わる 我々の場合はまずアジリティの向上が重要だった デプロイフローのテコ入れを行い、 アジリティの向上に繋げることができた

Slide 24

Slide 24 text

1｜会社概要 24 信頼性 アジリティ しかし、 デプロイ回数が増えたことにより、 リリースによるレイテンシの悪化などが増加した

Slide 25

Slide 25 text

1｜会社概要 25 信頼性 アジリティ しかし、 デプロイ回数が増えたことにより、 リリースによるレイテンシの悪化などが増加した 信頼性にも向き合い、バランスを取る時が来た

Slide 26

Slide 26 text

1｜会社概要 26 アジリティはわかりやすい ・デプロイ回数 ・リードタイムモニタリング アジリティ

Slide 27

Slide 27 text

1｜会社概要 27 信頼性の定量的指標って何？ 変更障害率？ メトリクスの悪化？ 選ばれたのは... 信頼性

Slide 28

Slide 28 text

1｜会社概要 28 信頼性の定量的指標って何？ 変更障害率？ メトリクスの悪化？ 選ばれたのは... SLI/SLO 信頼性

Slide 29

Slide 29 text

SLIを設定するときに 最初はCUJで策定することを考えた しかし、BtoBtoCサービスは CUJが複雑になってしまい、策定に難航した 1｜会社概要 29 信頼性

Slide 30

Slide 30 text

そこで、一旦ALBのメトリクスでのみSLIを設定した まずはスモールスタートでのSLI運用を開始した 1｜会社概要 30 信頼性 SLIを設定するときに 最初はCUJで策定することを考えた しかし、BtoBtoCサービスは CUJが複雑になってしまい、策定に難航した SLIを決める

Slide 31

Slide 31 text

SLI： バックエンドALBの可用性 5xx系の割合 1｜会社概要 31 信頼性

Slide 32

Slide 32 text

SLI： バックエンドALBの可用性 5xx系の割合 SLO： 現状の値を元に策定 理想の値を設定せず、 まずは運用できるものを目指した 1｜会社概要 32 信頼性

Slide 33

Slide 33 text

SLI/SLO、そして各種システムメトリクスが纏まったダッシュボードを作成し、 1.毎朝ダッシュボードを確認する 2.違和感があったら調査を行う といった運用を回すことができた 1｜会社概要 33 SLI/SLOの運用

Slide 34

Slide 34 text

SLI/SLOの運用として、 SLI/SLO、そして各種システムメトリクスが纏まったダッシュボードを作成し、 1.毎朝ダッシュボードを確認する 2.違和感があったら調査を行う といった運用を回すことができた デプロイに伴うレイテンシの悪化などにも 素早く気づき対応を行うことができた 1｜会社概要 34

Slide 35

Slide 35 text

数ヶ月後... SLI/SLOを施行し、何回かの見直しも実施した 運用もこなれてきたので、 CUJを元にしたSLIを設定することに。 1｜会社概要 35

Slide 36

Slide 36 text

私たちがサービスを提供する相手は ・不動産管理会社さん ・借主さん ・ニーリー社員 の3方向なので、それぞれに対するCUJを設定。 1｜会社概要 36

Slide 37

Slide 37 text

・借主さん 駐車場を探し、契約を行うことが目的 その目的を達成するUJをCUJとする ・不動産管理会社さん 駐車場と契約者を管理することが目的 その目的を達成するUJをCUJとする ・ニーリー社員 部署も幅広く、また機能も多いため悩ましい 1｜会社概要 37

Slide 38

Slide 38 text

・ニーリー社員 部署も幅広く、また機能も多いため悩ましい 全ての機能を見ると大変、重要なものだけ絞りたい 機能一覧 x 部署一覧 のマトリクスを作成 複数の部署で使用している機能を クリティカルな機能だと判断 それを我々にとってのCUJと定義 1｜会社概要 38

Slide 39

Slide 39 text

・不動産管理会社さん ・借主さん ・ニーリー社員 3方向に対してCUJを設定することを実現！ 現在CUJベースのSLI/SLOを絶賛運用中 1｜会社概要 39

Slide 40

Slide 40 text

1｜会社概要 40 SREとして信頼性とアジリティの向上の両方が求められる バランスを取るための信頼性の定量的指標としてのSLI/SLO SLI/SLOも最初から全てCUJで設定するのではなく、 スモールスタートで運用していくのがおすすめ スタートアップは特にアジリティが求められる SREとしては信頼性、アジリティ両方に向き合いながら いい感じにやっていこうね まとめ おしまい

Slide 41

Slide 41 text

1｜会社概要 41 おしまい テックブログ/Noteに深ぼった話があるので 合わせてぜひ読んでみてください