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