ヌーラボのSREは歴史の長いプロダクトをどのように改善しているか？ / NuCon 2020 SRE Session #1

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2020 Nulab Inc. ⾃⼰紹介 • 吉澤政洋 (@muziyoshiz) • 英語名Muzi（ムジ）。テックブログもMuzi名義で書いてます • ⼊社時に名前が先⼈とかぶってたので、昔からのハンドルネームで… • Backlogを担当するSite Reliability Engineer (SRE) • メーカーの研究所勤務時にサービス開発および運⽤管理に興味を持ち、転職してWeb系のソフト開発を経験 • 2017年8⽉にヌーラボへ⼊社すると同時に、SREへ転⾝ • SRE LoungeおよびSRE NEXTスタッフ

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2020 Nulab Inc. ヌーラボの歴史 • 最も歴史の⻑いBacklogのβ版リリースは2005年 • その後Cacoo、Typetalkがリリースされた • 2015年頃まではエンジニアも少なく、全員が開発と運⽤を兼任ベータ版リリース Backlogの歴史 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 このあたりまで

Slide 6

Slide 6 text

© 2020 Nulab Inc. SRE組織の始まり • 2015年にインフラ専任のエンジニアが初⼊社 • いまのSRE課課⻑の松浦 • サービスの成⻑とともに、SREも徐々に増員 • BacklogのSREは1〜2名/年のペースで増員し、徐々にチームの形へ • Backlog以外は、SREが1〜2名の状態が続くベータ版リリース Backlogの歴史 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 Backlog SREの歴史 Muzi ⼊社

Slide 7

Slide 7 text

© 2020 Nulab Inc. SRE組織の試⾏錯誤の時期 • SREを開発チーム所属にするか、開発チームとは別のSREチーム所属にするか？ • 開発チーム所属にすると開発者との連携は密になるが、 SRE主導の改善活動は後回しになりがち • SREをプロダクトチーム所属にするか、全プロダクト共通のチーム所属にするか？ • SRE業務にはプロダクトの知識が必須だが、プロダクトチーム所属のままではSRE同⼠の連携が進まない

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© 2020 Nulab Inc. Backlogとは？ • オールインワン型のプロジェクト管理＆コラボレーションツール λεΫ؅ཧ • λεΫͷ؅ཧ͕Ͱ͖Δ͔ʁ • λεΫ͔ΒࣗಈతʹΨϯτ νϟʔτ͕࡞੒Ͱ͖Δ͔ʁ จॻ؅ཧ • จॻΛΦϯϥΠϯ্Ͱ࡞੒ͯ͠ ڞ༗Ͱ͖Δ͔ʁ ϑΝΠϧ؅ཧ • ϑΝΠϧΛڞ༗Ͱ͖Δ͔ʁ • 8FC%"7Λ࢖ͬͯ1$͔Β௚ ઀ϑΝΠϧʹΞΫηεͰ͖Δ ͔ʁ ιʔείʔυ؅ཧ • (JUͰιʔείʔυ͕؅ཧͰ͖Δ ͔ʁ • 4VCWFSTJPOͰιʔείʔυ͕ ؅ཧͰ͖Δ͔ʁ ϞόΠϧରԠ • ެࣜͷϞόΠϧΞϓϦ͕ఏڙ͞ Ε͍ͯΔ͔ʁ ηΩϡϦςΟ • άϩʔόϧ*1ΞυϨεʹΑΔ αʔϏε΁ͷΞΫηε੍ݶ౳ͷ ઃఆ͕Ͱ͖Δ͔ʁ • ΞΫηεϩάͷఏڙαʔϏε͕ ͋Δ͔ʁ ֦ுੑ • "1*͕ఏڙ͞Ε͍ͯΔ͔ʁ • ৘ใͷߋ৽࣌ʹ֎෦γεςϜʹ ௨஌͢Δ࢓૊Έ 8FCIPPLͳͲ ͕ఏڙ͞Ε͍ͯΔ͔ʁ • ֎෦γεςϜͳͲ͔Βϝʔϧܦ ༝ͰλεΫΛ࡞੒Ͱ͖Δ͔ʁ

Slide 15

Slide 15 text

© 2020 Nulab Inc. Backlogとは？ • オールインワン型のプロジェクト管理＆コラボレーションツール จॻ؅ཧ • จॻΛΦϯϥΠϯ্Ͱ࡞੒ͯ͠ ڞ༗Ͱ͖Δ͔ʁ ϑΝΠϧ؅ཧ • ϑΝΠϧΛڞ༗Ͱ͖Δ͔ʁ • 8FC%"7Λ࢖ͬͯ1$͔Β௚ ઀ϑΝΠϧʹΞΫηεͰ͖Δ ͔ʁ ιʔείʔυ؅ཧ • (JUͰιʔείʔυ͕؅ཧͰ͖Δ ͔ʁ • 4VCWFSTJPOͰιʔείʔυ͕ ؅ཧͰ͖Δ͔ʁ ϞόΠϧରԠ • ެࣜͷϞόΠϧΞϓϦ͕ఏڙ͞ Ε͍ͯΔ͔ʁ ηΩϡϦςΟ • άϩʔόϧ*1ΞυϨεʹΑΔ αʔϏε΁ͷΞΫηε੍ݶ౳ͷ ઃఆ͕Ͱ͖Δ͔ʁ • ΞΫηεϩάͷఏڙαʔϏε͕ ͋Δ͔ʁ ֦ுੑ • "1*͕ఏڙ͞Ε͍ͯΔ͔ʁ • ৘ใͷߋ৽࣌ʹ֎෦γεςϜʹ ௨஌͢Δ࢓૊Έ 8FCIPPLͳͲ ͕ఏڙ͞Ε͍ͯΔ͔ʁ • ֎෦γεςϜͳͲ͔Βϝʔϧܦ ༝ͰλεΫΛ࡞੒Ͱ͖Δ͔ʁ λεΫ؅ཧ • λεΫͷ؅ཧ͕Ͱ͖Δ͔ʁ • λεΫ͔ΒࣗಈతʹΨϯτ νϟʔτ͕࡞੒Ͱ͖Δ͔ʁ ここの話

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2020 Nulab Inc. 問題に着⼿できるようになった理由 • SRE課の結成によって、SRE課のメンバーだけで開発プロジェクトを進められるようになった • SRE課の結成前の2018年にも約1ヶ⽉着⼿したが、そのときは他のタスクを優先することになり頓挫した • 2019年7⽉にTomcatからPlay Frameworkへの移⾏が完了したことで、課題検索機能を修正しやすくなった • Playへの移⾏が完了する前は、Tomcat版とPlay版の両⽅を修正する必要があった

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2020 Nulab Inc. 開発サイクル • 1スプリントを2週間としてスクラムのイベントを採⽤ • 朝会、スプリントプランニング、スプリントレビュー • 朝会以外はマネージャー1名およびスクラムマスター1名も参加 • 段階的なリリースが難しい機能で、ほとんどウォーターフォール型の開発になった • 現在の仕様の調査：1〜2ヶ⽉（プロジェクト開始前） • 要件定義・設計・実機検証：5スプリント • 実装：3スプリント • テスト：2スプリント • 新旧実装の並⾏稼動：約2ヶ⽉約5ヶ⽉

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© 2020 Nulab Inc. 実装のポイント：パフォーマンス • ネットワーク遅延の短縮 • AWSリージョンごとにElasticsearchクラスタを構築 • クエリのチューニング、filter_pathパラメータの使⽤などにより、取得するデータ量を削減 • ヒープメモリの使⽤量削減 • インデックスをスペース単位で作成していたものを、サービスクラスタ単位で作成するように変更し、シャード数を削減 • ⼤多数のユーザーに影響が出ない範囲で、データサイズの上限（課題の⽂字数上限など）を⾒直し

Slide 45

Slide 45 text

© 2020 Nulab Inc. 実装のポイント：セキュリティ • IAMロールでの認証・認可（AWS署名） • Amazon ESはBasic認証に⾮対応 • インデックス単位の認証・認可 • rest.action.multi.allow_explicit_indexをfalseに設定（Kibanaが使えなくなる） • Kibanaの代わりにawscurl （AWS署名機能を持つcurlライクなツール）を⽤いた運⽤⼿順を整備

Slide 46

Slide 46 text

© 2020 Nulab Inc. 実装のポイント：運⽤ツール • Bulk indexingツールの新規開発 • ElasticsearchのBulk APIを呼び出すことで、⼤量の課題を⾼速にインデキシングできるツールを開発 • 本番環境のデータでテストを繰り返してチューニング • 万が⼀、すべてのインデックスが壊れても、約6時間で復旧できる（※Backlogで⼀番⼤きなサービスクラスタの場合） • 従来は、1⽇〜1週間かかる作業だった

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© 2020 Nulab Inc. 課題検索機能に残っている潜在的な問題 • 早急なリプレイスを最優先としたため、 UIの変更を必要とするような改善はまだ実施できていない • UIを変更・⼀部制限しなければ解決しない、重い検索クエリがいくつかあることがわかっている • Elasticsearchの使い⽅に改善の余地がある • インデックス定義の改善、クエリの改善など • Force mergeできるインデックス定義になっていないサービスレベルが悪化したら優先度の⾒直しが必要

Slide 53

Slide 53 text

© 2020 Nulab Inc. 継続的な改善に向けた取り組み • サービスレベルの監視 • CloudWatchでの、AWSの推奨項⽬の監視 • 応答時間の99パーセンタイル、90パーセンタイルの監視 • ⽬標を下回った場合はアラート • アラートの発⽣が多い場合は原因調査 • スロークエリログの監視 • CloudWatch Logs Insightでの可視化 • AWS TAMとの定期的な議論 • SRE課のプロダクトバックログの定期的な⾒直し

Slide 54

Slide 54 text

© 2020 Nulab Inc. 現在進⾏中の改善 • Elasticsearchクラスタのインスタンスタイプの変更 • 本番環境での半年以上の運⽤を通して、ReadIOPSネックでの障害が徐々に増えてきた • EBS gp2 → io1 への変更で改善できたが⾼価 • データノードをc5インスタンスから、同価格帯のi3インスタンスに切り替えることで、vCPU数は減るが、IOPS上限は⼤幅に上がる • 本番環境でc5クラスタとi3クラスタを並⾏稼動して性能評価し、その結果次第でi3クラスタへの切り替えを⾏う予定

Slide 55

Slide 55 text

Slide 56

Slide 56 text

© 2020 Nulab Inc. まとめ • ヌーラボでは、2019年1⽉にプロダクト横断のSRE課を設⽴しました • SRE課はプロダクトチームのプロダクトバックログとは別に、改善活動のプロダクトバックログを持っています • SRE課にはSREと開発者が所属し、改善活動のプロダクトバックログに基づいてプロジェクトを提案・推進しています • 改善プロジェクトの実例として、Backlogの課題検索機能のリプレイスプロジェクトを詳しくご紹介しました

Slide 57

Slide 57 text

Slide 58

Slide 58 text