Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ヌーラボの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

3e77f9dbec6a87756d1dbdddab283aee?s=128

Nulab Inc.
PRO

December 05, 2020
Tweet

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