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

2020年12月5日(土)に開催されたNuConの登壇資料です。

▼NuCon2020 公式サイト
https://nucon.nulab.com/2020/

▼発表アーカイブ
https://www.youtube.com/watch?v=KXogZS5awbc&t=4621s

Transcript

1. © 2020 Nulab Inc. ヌーラボのSREは 歴史の⻑いプロダクトを どのように改善しているか？ 株式会社ヌーラボ サービス開発部 SRE課 吉澤 政洋
2. © 2020 Nulab Inc. ⾃⼰紹介 • 吉澤 政洋 (@muziyoshiz) • 英語名Muzi（ムジ）。テックブログもMuzi名義で書いてます • ⼊社時に名前が先⼈とかぶってたので、昔からのハンドルネームで… • Backlogを担当するSite Reliability Engineer (SRE) • メーカーの研究所勤務時にサービス開発および運⽤管理に興味を持ち、 転職してWeb系のソフト開発を経験 • 2017年8⽉にヌーラボへ⼊社すると同時に、SREへ転⾝ • SRE LoungeおよびSRE NEXTスタッフ 
3. © 2020 Nulab Inc. 今⽇話したいこと • ヌーラボのSRE組織とその変遷 • 歴史の⻑いプロダクトを改善するプロジェクトの事例 • 継続的な改善に向けた取り組み 
4. © 2020 Nulab Inc. ヌーラボのSRE組織とその変遷
5. © 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 このあたりまで
6. © 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 ⼊社
7. © 2020 Nulab Inc. SRE組織の試⾏錯誤の時期 • SREを開発チーム所属にするか、 開発チームとは別のSREチーム所属にするか？ • 開発チーム所属にすると開発者との連携は密になるが、 SRE主導の改善活動は後回しになりがち • SREをプロダクトチーム所属にするか、 全プロダクト共通のチーム所属にするか？ • SRE業務にはプロダクトの知識が必須だが、 プロダクトチーム所属のままではSRE同⼠の連携が進まない 
8. © 2020 Nulab Inc. 参考：2018年頃までの状況 • SRE Lounge #5 での発表「BacklogにおけるSREの事例」  https://speakerdeck.com/nulabinc/sre-lounge-number-5
9. © 2020 Nulab Inc. 2019年以降のSRE組織 • 2019年1⽉に、プロダクト横断のSRE課を設⽴ • 普段の運⽤と並⾏して、SRE課提案の改善プロジェクトを推進 • 各SREは主担当のプロダクトを持つが、横の連携も少しずつ進める  サービス開発部 Backlog課 Typetalk課 Cacoo課 SRE課 Apps課
10. © 2020 Nulab Inc. SRE課のなかのチーム構成 • 運⽤管理を⾏う従来からのSREに加えて、 改善のための開発を⾏う開発者もSRE課に所属 • 1ヶ⽉以上かかる改善活動についてはプロジェクトを編成  課題検索機能 のリプレイス プロジェクト Web operationチーム （運⽤管理） Amazon Linux 2移⾏ プロジェクト 本プレゼン で紹介 SRE 開発者
11. © 2020 Nulab Inc. 改善プロジェクトの編成 • SRE課は、プロダクトチームのプロダクトバックログとは別に、 改善活動のプロダクトバックログを持つ • 管理はもちろん • プロダクトバックログのなかで優先度の⾼いものから着⼿ • 優先度の⾒直しは⽉1の打合せで実施 
12. © 2020 Nulab Inc. 改善プロジェクトの事例紹介 • Backlogの課題検索機能のリプレイスプロジェクト • 2019年8⽉〜2020年2⽉のプロジェクト • SREと開発者がチームを組んで、要件定義からリリースまで⾏った • ⾃分の⼊社（2017年）よりずっと前から認識されていた問題だったが、 SRE課の結成後に着⼿できるようになった • プロジェクト終了後も改善が続いている 
13. © 2020 Nulab Inc. Backlogの課題検索機能の リプレイスプロジェクトの背景
14. © 2020 Nulab Inc. Backlogとは？ • オールインワン型のプロジェクト管理＆コラボレーションツール  λεΫ؅ཧ • λεΫͷ؅ཧ͕Ͱ͖Δ͔ʁ • λεΫ͔ΒࣗಈతʹΨϯτ νϟʔτ͕࡞੒Ͱ͖Δ͔ʁ จॻ؅ཧ • จॻΛΦϯϥΠϯ্Ͱ࡞੒ͯ͠ ڞ༗Ͱ͖Δ͔ʁ ϑΝΠϧ؅ཧ • ϑΝΠϧΛڞ༗Ͱ͖Δ͔ʁ • 8FC%"7Λ࢖ͬͯ1$͔Β௚ ઀ϑΝΠϧʹΞΫηεͰ͖Δ ͔ʁ ιʔείʔυ؅ཧ • (JUͰιʔείʔυ͕؅ཧͰ͖Δ ͔ʁ • 4VCWFSTJPOͰιʔείʔυ͕ ؅ཧͰ͖Δ͔ʁ ϞόΠϧରԠ • ެࣜͷϞόΠϧΞϓϦ͕ఏڙ͞ Ε͍ͯΔ͔ʁ ηΩϡϦςΟ • άϩʔόϧ*1ΞυϨεʹΑΔ αʔϏε΁ͷΞΫηε੍ݶ౳ͷ ઃఆ͕Ͱ͖Δ͔ʁ • ΞΫηεϩάͷఏڙαʔϏε͕ ͋Δ͔ʁ ֦ுੑ • "1*͕ఏڙ͞Ε͍ͯΔ͔ʁ • ৘ใͷߋ৽࣌ʹ֎෦γεςϜʹ ௨஌͢Δ࢓૊Έ 8FCIPPLͳͲ ͕ఏڙ͞Ε͍ͯΔ͔ʁ • ֎෦γεςϜͳͲ͔Βϝʔϧܦ ༝ͰλεΫΛ࡞੒Ͱ͖Δ͔ʁ
15. © 2020 Nulab Inc. Backlogとは？ • オールインワン型のプロジェクト管理＆コラボレーションツール  จॻ؅ཧ • จॻΛΦϯϥΠϯ্Ͱ࡞੒ͯ͠ ڞ༗Ͱ͖Δ͔ʁ ϑΝΠϧ؅ཧ • ϑΝΠϧΛڞ༗Ͱ͖Δ͔ʁ • 8FC%"7Λ࢖ͬͯ1$͔Β௚ ઀ϑΝΠϧʹΞΫηεͰ͖Δ ͔ʁ ιʔείʔυ؅ཧ • (JUͰιʔείʔυ͕؅ཧͰ͖Δ ͔ʁ • 4VCWFSTJPOͰιʔείʔυ͕ ؅ཧͰ͖Δ͔ʁ ϞόΠϧରԠ • ެࣜͷϞόΠϧΞϓϦ͕ఏڙ͞ Ε͍ͯΔ͔ʁ ηΩϡϦςΟ • άϩʔόϧ*1ΞυϨεʹΑΔ αʔϏε΁ͷΞΫηε੍ݶ౳ͷ ઃఆ͕Ͱ͖Δ͔ʁ • ΞΫηεϩάͷఏڙαʔϏε͕ ͋Δ͔ʁ ֦ுੑ • "1*͕ఏڙ͞Ε͍ͯΔ͔ʁ • ৘ใͷߋ৽࣌ʹ֎෦γεςϜʹ ௨஌͢Δ࢓૊Έ 8FCIPPLͳͲ ͕ఏڙ͞Ε͍ͯΔ͔ʁ • ֎෦γεςϜͳͲ͔Βϝʔϧܦ ༝ͰλεΫΛ࡞੒Ͱ͖Δ͔ʁ λεΫ؅ཧ • λεΫͷ؅ཧ͕Ͱ͖Δ͔ʁ • λεΫ͔ΒࣗಈతʹΨϯτ νϟʔτ͕࡞੒Ͱ͖Δ͔ʁ ここの話
16. © 2020 Nulab Inc. Backlogの課題検索機能 • 課題＝タスクやチケットのことを表すBacklogの⽤語 • 課題の件名、詳細、コメントに対するキーワード検索 
17. © 2020 Nulab Inc. Backlogの課題検索機能 • カスタム属性（ユーザーが追加可能な課題の属性） に対する検索 
18. © 2020 Nulab Inc. リプレイス前の実装 
19. © 2020 Nulab Inc. リプレイス前の実装  ①課題の追加・ 更新時に ジョブを登録
20. © 2020 Nulab Inc. リプレイス前の実装  ①課題の追加・ 更新時に ジョブを登録 ②インデックス ファイルを更新
21. © 2020 Nulab Inc. リプレイス前の実装  ①課題の追加・ 更新時に ジョブを登録 ②インデックス ファイルを更新 ③インデックス ファイルを配布
22. © 2020 Nulab Inc. リプレイス前の実装  ①課題の追加・ 更新時に ジョブを登録 ②インデックス ファイルを更新 ③インデックス ファイルを配布 ④検索時はEBSボ リューム上のファ イルを使⽤
23. © 2020 Nulab Inc. リプレイス前の実装の問題点 1. スケーラビリティ 2. 可⽤性 3. ハードウェアコスト 4. 運⽤コスト 
24. © 2020 Nulab Inc. リプレイス前の実装の問題点  1. スケーラビリティ インデキシングサーバーと インデックスファイルが スケールアウトを阻害する
25. © 2020 Nulab Inc. リプレイス前の実装の問題点  2. 可⽤性 インデックスファイルの 同期の遅延・失敗が 多発する
26. © 2020 Nulab Inc. リプレイス前の実装の問題点  3. ハードウェアコスト AZ間通信および 巨⼤なEBSボリューム の費⽤が⾼額
27. © 2020 Nulab Inc. リプレイス前の実装の問題点  4. 運⽤コスト インデックスファイルの 破損・同期失敗時に ⼿作業での復旧が必要
28. © 2020 Nulab Inc. 個々の問題点より⼤きなもの • Backlogの新サービス追加やマイクロサービス化の⾜かせに なっていた • 検索機能を持つサービスにはインデックスファイルを置く必要がある ため、システム構成の選択肢が狭まっていた • SRE課は、モノリシックアプリケーションを分割して 開発チームごとの責任範囲を明確にし、 開発から運⽤まで、その開発チームの判断で動きやすくしたい 
29. © 2020 Nulab Inc. 問題に着⼿できるようになった理由 • SRE課の結成によって、SRE課のメンバーだけで開発プロジェ クトを進められるようになった • SRE課の結成前の2018年にも約1ヶ⽉着⼿したが、そのときは 他のタスクを優先することになり頓挫した • 2019年7⽉にTomcatからPlay Frameworkへの移⾏が完了した ことで、課題検索機能を修正しやすくなった • Playへの移⾏が完了する前は、Tomcat版とPlay版の両⽅を修正する 必要があった 
30. © 2020 Nulab Inc. 参考：Backlog Play化プロジェクト • 「Backlog Play 化プロジェクト」で検索  https://backlog.com/ja/blog/how-sre-resolved-the-problems-on-large-scale-replacement-with-play-framework/
31. © 2020 Nulab Inc. Backlogの課題検索機能の リプレイスプロジェクトの進め⽅
32. © 2020 Nulab Inc. プロジェクトの⽴ち上げ • SRE課から提案し、承認を得てプロジェクト開始 • SRE1名 • MuziはSRE兼プロジェクトマネージャーとして参加 • 積年の問題を解決するためにプロジェクトを提案し、志願 • 開発者1〜2名 • プロジェクト前半（要件定義・設計・実機検証）は2名 • プロジェクト後半（実装・テスト）は1名 
33. © 2020 Nulab Inc. キックオフ • インセプションデッキで⽬的を絞り込み • トレードオフ・スライダーで重視する点について合意 
34. © 2020 Nulab Inc. 問題解決のためのアプローチ • 開発スコープの限定 （既存機能を実現し、早急にリプレイスすることを最優先） • スケールアップ可能なElasticsearchクラスタの導⼊ • マネージドサービスの利⽤ 
35. © 2020 Nulab Inc. 開発サイクル • 1スプリントを2週間としてスクラムのイベントを採⽤ • 朝会、スプリントプランニング、スプリントレビュー • 朝会以外はマネージャー1名およびスクラムマスター1名も参加 • 段階的なリリースが難しい機能で、 ほとんどウォーターフォール型の開発になった • 現在の仕様の調査 ：1〜2ヶ⽉（プロジェクト開始前） • 要件定義・設計・実機検証：5スプリント • 実装 ：3スプリント • テスト ：2スプリント • 新旧実装の並⾏稼動 ：約2ヶ⽉  約5ヶ⽉
36. © 2020 Nulab Inc. 新しい課題検索機能とその効果
37. © 2020 Nulab Inc. リプレイス後のシステム構成 
38. © 2020 Nulab Inc. リプレイス後のシステム構成  ①課題の追加・ 更新時に ジョブを登録
39. © 2020 Nulab Inc. リプレイス後のシステム構成  ①課題の追加・ 更新時に ジョブを登録 ②Elasticsearch API 経由でインデックス を更新
40. © 2020 Nulab Inc. リプレイス後のシステム構成  ①課題の追加・ 更新時に ジョブを登録 ②Elasticsearch API 経由でインデックス を更新 ③Elasticsearch API 経由でインデックス を検索
41. © 2020 Nulab Inc. Amazon Elasticsearch Serviceの採⽤理由 • 今回の機能要件および性能要件を満たすことができた • ヌーラボでは元々AWSを使っているため、課⾦をAWSで⼀元化 できた • ヌーラボはAWSのエンタープライズ契約を⾏っているため、 Amazon ESに詳しいテクニカルアカウントマネージャー （TAM）の協⼒を得られた 
42. © 2020 Nulab Inc. リプレイスの効果  1. スケーラビリティ 無停⽌でのスケールアップ・ スケールアウト 2. 可⽤性 インデックス更新の 遅延・失敗の解決、 3 AZでの冗⻑化 3. ハードウェアコスト AZ間通信および EBSボリュームの削減 （50万円〜/⽉の削減） 4. 運⽤コスト ⼿作業での 復旧作業が不要に
43. © 2020 Nulab Inc. リプレイスの最も⼤きな効果  インデックスファイルが不要 になり、アプリケーション サーバのコンテナ化や分割が 容易になった！
44. © 2020 Nulab Inc. 実装のポイント：パフォーマンス • ネットワーク遅延の短縮 • AWSリージョンごとにElasticsearchクラスタを構築 • クエリのチューニング、filter_pathパラメータの使⽤などにより、 取得するデータ量を削減 • ヒープメモリの使⽤量削減 • インデックスをスペース単位で作成していたものを、 サービスクラスタ単位で作成するように変更し、シャード数を削減 • ⼤多数のユーザーに影響が出ない範囲で、データサイズの上限（課題 の⽂字数上限など）を⾒直し 
45. © 2020 Nulab Inc. 実装のポイント：セキュリティ • IAMロールでの認証・認可（AWS署名） • Amazon ESはBasic認証に⾮対応 • インデックス単位の認証・認可 • rest.action.multi.allow_explicit_indexをfalseに設定 （Kibanaが使えなくなる） • Kibanaの代わりにawscurl （AWS署名機能を持つcurlライクなツー ル）を⽤いた運⽤⼿順を整備 
46. © 2020 Nulab Inc. 実装のポイント：運⽤ツール • Bulk indexingツールの新規開発 • ElasticsearchのBulk APIを呼び出すことで、 ⼤量の課題を⾼速にインデキシングできるツールを開発 • 本番環境のデータでテストを繰り返してチューニング • 万が⼀、すべてのインデックスが壊れても、約6時間で復旧できる （※Backlogで⼀番⼤きなサービスクラスタの場合） • 従来は、1⽇〜1週間かかる作業だった 
47. © 2020 Nulab Inc. 参考：2020年3⽉公開のテックブログ • 技術的な詳細は、テックブログをご参照ください  https://backlog.com/ja/blog/case-of-sre-featuring-issue-search-replacement/
48. © 2020 Nulab Inc. 旧システムからの移⾏（1） • 設定ファイルで新旧の検索機能を切替可能にし、 少しでも問題発⽣したら切り戻し  インデキシング 機能の並列実⾏・ 切り替え 検索機能の 切り替え
49. © 2020 Nulab Inc. 旧システムからの移⾏（2） • サービスクラスタ1個あたり3〜4週間の並⾏稼動を⾏い、 約2ヶ⽉で全体を移⾏完了 
50. © 2020 Nulab Inc. 継続的な改善に向けた取り組み
51. © 2020 Nulab Inc. SRE課と継続的な改善 • ⼀度改善した機能に問題が起こった場合、改善活動のプロダク トバックログにその問題を追加し、優先度を議論する • SRE課の裁量で優先度を決定できるため、継続的な改善が スムーズにできている 
52. © 2020 Nulab Inc. 課題検索機能に残っている潜在的な問題 • 早急なリプレイスを最優先としたため、 UIの変更を必要とするような改善はまだ実施できていない • UIを変更・⼀部制限しなければ解決しない、 重い検索クエリがいくつかあることがわかっている • Elasticsearchの使い⽅に改善の余地がある • インデックス定義の改善、クエリの改善など • Force mergeできるインデックス定義になっていない  サービスレベルが悪化したら優先度の⾒直しが必要
53. © 2020 Nulab Inc. 継続的な改善に向けた取り組み • サービスレベルの監視 • CloudWatchでの、AWSの推奨項⽬の監視 • 応答時間の99パーセンタイル、90パーセンタイルの監視 • ⽬標を下回った場合はアラート • アラートの発⽣が多い場合は原因調査 • スロークエリログの監視 • CloudWatch Logs Insightでの可視化 • AWS TAMとの定期的な議論 • SRE課のプロダクトバックログの定期的な⾒直し 
54. © 2020 Nulab Inc. 現在進⾏中の改善 • Elasticsearchクラスタのインスタンスタイプの変更 • 本番環境での半年以上の運⽤を通して、ReadIOPSネックでの障害が 徐々に増えてきた • EBS gp2 → io1 への変更で改善できたが⾼価 • データノードをc5インスタンスから、同価格帯のi3インスタンスに 切り替えることで、vCPU数は減るが、IOPS上限は⼤幅に上がる • 本番環境でc5クラスタとi3クラスタを並⾏稼動して性能評価し、 その結果次第でi3クラスタへの切り替えを⾏う予定 
55. © 2020 Nulab Inc. まとめ
56. © 2020 Nulab Inc. まとめ • ヌーラボでは、2019年1⽉にプロダクト横断のSRE課を 設⽴しました • SRE課はプロダクトチームのプロダクトバックログとは別に、 改善活動のプロダクトバックログを持っています • SRE課にはSREと開発者が所属し、改善活動のプロダクト バックログに基づいてプロジェクトを提案・推進しています • 改善プロジェクトの実例として、Backlogの課題検索機能の リプレイスプロジェクトを詳しくご紹介しました 
57. © 2020 Nulab Inc. We are hiring!  https://nulab.com/ja/about/careers/
58. © 2020 Nulab Inc. We are hiring!  https://www.wantedly.com/companies/nulab