※このブログはヌーラバー Advent Calendar 2020の15日目の記事です。明日はKiyoshi Watanabeさんの記事です。
SRE課で、主にBacklogのSREを担当しているMuziです。
今回の記事は、NuCon 2020での発表「ヌーラボのSREは歴史の長いプロダクトをどのように改善しているか？」の内容をもとに、時間の都合で触れられなかった細かい説明を補足したものです。SRE組織を持つ会社の方や、これからSRE組織を作りたい方の参考になれば幸いです。
テキストを読むより音声のほうがいい！という方は、以下のアーカイブをご覧ください。特にSREの話に興味のある方は1:17:00からどうぞ。私の講演含め、そこからSRE課のセッションが3本続きます。
NuCon 2020のアーカイブ動画（1:17:00〜）
NuCon 2020の発表資料
目次
ヌーラボのSRE組織とその変遷
SRE組織の始まり
ヌーラボで最も歴史の長いサービスであるBacklogは、2005年にリリースされました。その後、CacooやTypetalkという新しいサービスのリリースも続きましたが、2015年頃まではいまよりもエンジニア数が少なく、全員が開発と運用を兼任していました。
SRE組織の始まりは、2015年にインフラ専任のエンジニアが初めて入社したことでした（現在のSRE課課長の松浦）。その後、サービスの成長とともにSREも徐々に増員しました。私も2017年8月にSREとして入社しました。
BacklogのSREは1〜2名/年のペースで増員し、徐々にチームの形になっていきました。その一方、Backlog以外のサービスは、SREが1〜2名の状態が長く続きました。
ヌーラボのSRE組織の歴史
SRE組織の試行錯誤の時期
SREが徐々に増えてきた2017〜2018年頃は、SRE組織の試行錯誤の時期でした。そのなかで特に大きな論点は以下の2点だったと記憶しています。
- SREを開発チーム所属にするか、開発チームとは別のSREチーム所属にするか？
- SREをプロダクトチーム所属にするか、全プロダクト共通のチーム所属にするか？
まず前者の、SREを開発チーム所属にするかどうかについて。
Backlogでは、2018年に、SREを開発チーム所属にするマトリックス型の組織を試しました。このときは、SREと開発者の垣根を超えた情報共有の役割をSREが担うことで、MTTRが改善するなどのメリットがありました。しかし、意思決定がどうしても開発中心になり、SRE主導の改善活動のスピードが下がるというデメリットも発生しました。
このマトリックス型の組織への挑戦については、SRE Lounge #5で発表した資料を公開しておりますので、詳細についてはこちらをご参考ください。また、個人ブログの記事（SRE Lounge #5 にて Backlog における SRE の事例について講演しました）にて、質疑応答の内容などを補足しています。
そして後者の、SREをプロダクトチーム所属にするかどうかについて。
SRE業務にはプロダクトの知識が必須のため、全SREが全プロダクトを分担するような体制は難しい、と思っています。これはどの会社のSREもそうなのではないでしょうか。
しかし、SREがプロダクトチーム所属のために、SRE同士の連携がなかなか進まないという課題意識が、特にマネージャー層のなかにありました。例えば、Backlogにある大規模サービスの運用管理のノウハウをCacooやTypetalkに活かすことや、比較的小規模なCacooやTypetalkで試してうまくいった新しい技術をBacklogに横展開することが、あまり起こらない状況でした。
2019年以降のSRE組織
このような問題への対策として、ヌーラボでは、2019年1月にプロダクト横断のSRE課を設立しました。
2019年以降のSRE組織
SRE課は、普段の運用と並行して、SRE課提案の改善プロジェクトを推進する部署です。前述の通り、SRE業務にはプロダクトの知識が必須のため、各SREは主担当のプロダクトを持ちます。しかし、プロダクトをまたいだ横の連携も少しずつ進めることも、SRE課のミッションとして定義されました。
また、このSRE課が設立されたタイミングで、運用管理を行う従来からのSREに加えて、改善のための開発を行う開発者も数名、SRE課に配属されました。
SRE課では、以下のようなプロセスで、着手する改善活動を決定しています。
- SRE課は、プロダクトチームのバックログとは別に、改善活動のプロダクトバックログを持ち、このプロダクトバックログに基づいて改善活動を決める
- SRE課のメンバーは、このプロダクトバックログにいつでも項目を追加でき、月1回の「プロダクトバックログ棚卸し」打合せでレビューと優先度の見直しを行う（この管理はBacklogの「ボード」機能を利用）
- 1ヶ月以上かかる改善活動については、SREと開発者の両方からメンバーを募り、改善プロジェクトを編成する
SRE課のなかのチーム構成
特にBacklogは歴史の長いプロダクトのため、細かい問題は無数にあり、SRE課の限られた人数ではそのすべてを一度に解決することはできません。そのため、このようなプロセスで、メンバー間で優先度が高いという合意が得られたものから順に、改善に取り組んでいます。
事例紹介：Backlogの課題検索機能のリプレイスプロジェクト
SRE課の設立によって、SRE主導の改善活動のスピードは実際に上がったと実感しています。
その一例として、2019年8月〜2020年2月に行った「Backlogの課題検索機能のリプレイスプロジェクト」をご紹介します。このプロジェクト（以下、リプレイスプロジェクト）では、SREと開発者がチームを組んで、要件定義からリリースまで行いました。
この課題検索機能に問題があることは、私の入社（2017年）よりずっと前から認識されていましたが、SRE課の結成後に着手できるようになりました。また、リプレイス後のシステムを一度開発して終わりではなく、SRE課で継続的に改善を進めています。その点でも、SRE課の紹介に適した事例かと思います。
なお、このリプレイスプロジェクトについては、2020年3月のBacklogブログの記事「SREの活動事例紹介 〜 Backlogのマイクロサービス化に向けた課題検索機能のリプレイス」にて、詳しくご紹介しました。技術的な詳細に興味のある方は、こちらのブログ記事をご覧ください。以下ではSRE組織に関する話にフォーカスしてご紹介します。
リプレイスプロジェクトの背景
Backlogの課題検索機能は、Backlogのリリース当初から存在する主要機能の一つです。リプレイス前はインデキシングサーバー（図の右側）がインデックスファイルを生成し、これを全アプリケーションサーバー（図の左側）に配布するというシステム構成でした。
リプレイス前のシステム構成
リリース当初の、まだユーザー数が少ない時期は問題なく動作していましたが、ユーザー数の増加に伴って以下のような問題が発生し始めました。
- スケーラビリティ：インデキシングサーバーとインデックスファイルがスケールアウトを阻害
- 可用性：インデックスファイルの同期の遅延・失敗が多発する
- ハードウェアコスト：インデックスファイルを同期するためのAZ間通信、および巨大なEBSボリュームの費用が高額
- 運用コスト：インデックスファイルの破損・同期失敗時に、サポートチームとSREの稼働が発生
SRE課の長期的な目標としては、現在のモノリシックなアプリケーションを分割して、開発チームごとの責任範囲を明確にし、開発から運用まで、その開発チームの判断で動きやすくしたいと考えています。しかし、上記の問題が合わさって、課題検索機能は、Backlogの新サービス追加やマイクロサービス化の足かせになっていました。
リプレイスプロジェクトの進め方
改善活動のプロダクトバックログに基づいてSRE課から提案し、承認を得てプロジェクトを開始しました。
メンバーは、SRE課に所属するSRE 1名と開発者1〜2名（プロジェクト前半は2名、後半は1名）の小さなプロジェクトチームでした。自分は、SRE兼プロジェクトマネージャーとして参加しました。
今回のプロジェクトの目的は既存機能のリプレイスで、機能要件（外部要件）はほとんど動かせませんでした。そのため、ウォーターフォール型の開発プロセスに、アジャイルのプラクティスをいくつか適用するような形になりました。
1スプリントを2週間としてスクラムのイベント（朝会、スプリントプランニング、スプリントレビュー）を採用し、朝会以外はマネージャー1名（SRE課課長）およびスクラムマスター1名（Backlog課）にも参加してもらいました。
プロジェクトの流れと、実際にかかった期間はおおよそ以下の通りです。
- 現在の仕様の調査：1〜2ヶ月（プロジェクト開始前）
- キックオフ
- 要件定義・設計・実機検証：5スプリント
- 実装：3スプリント
- テスト：2スプリント
- 新旧実装の並行稼動：約2ヶ月
- ふりかえり
リプレイスプロジェクトの効果
リプレイス後のシステム構成では、Amazon Elasticsearch Service（以下、Amazon ES）を採用しました。このAmazon ESに合わせて、既存のアプリケーションサーバー、ジョブワーカー、および運用管理プロセスなどの修正を行いました。
リプレイス後のシステム構成
これにより、前述の問題は以下のように解決されました。
- スケーラビリティ：Amazon ESの機能で、無停止でのスケールアップ・スケールアウトが可能になった
- 可用性：インデックスファイルの同期がなくなり、インデックス更新の遅延・失敗が起こらなくなった。3 AZで冗長化されて、耐障害性が向上した
- ハードウェアコスト：AZ間通信、および巨大なEBSボリュームの費用が削減された（50万円〜/月の削減）
- 運用コスト：インデックスファイルの破損・同期失敗が起こらなくなり、サポートチームとSREの稼働が減った
また、リプレイスの最も大きな効果として、アプリケーションサーバー上のインデックスファイルが不要になり、アプリケーションサーバーのコンテナ化や分割が容易になりました。
技術的な詳細については、繰り返しになりますが過去のテックブログ（SREの活動事例紹介 〜 Backlogのマイクロサービス化に向けた課題検索機能のリプレイス）をご参考ください。
継続的な改善に向けた取り組み
SRE課では、一度改善した機能に問題が起こった場合、改善活動のプロダクトバックログにその問題を追加し、優先度を議論します。このように、SRE課の裁量で優先度を決定できるため、継続的な改善を素早く行うことができていると感じています。
前述の課題検索機能での、改善の実例をご紹介します。
課題検索機能に残っている潜在的な問題
リプレイス後の課題検索機能には、いまのところユーザー操作に大きく影響しないものの、未解決の問題がいくつか残っています。
まず、今回のリプレイスプロジェクトでは旧システムの早急な廃止を最優先としたため、UIの変更を必要とするような改善はまだ実施できていません。UIを変更または一部制限しなければ解決しない、重い検索クエリがいくつかあることがわかっています。
もう一つ、Elasticsearchを製品で採用したのは今回が初めてだったため、Elasticsearchの使い方に改善の余地があることが後からわかりました。例えば、インデックス定義の改善や、クエリの改善が可能な余地が残っています。また、Force mergeできるインデックス定義になっていないために、時間経過とともにセグメント数が増えて、応答時間が悪化する可能性があります。
これらは、改善活動のプロダクトバックログのなかで、まだ優先度が低いため着手されていません。しかし、サービスレベルが悪化したら、優先度を見直す必要があります。
継続的な改善に向けた取り組み
優先度を必要に応じて見直すためには、まず、サービスレベルの監視が必要です。
課題検索機能に関しては、まずAWSが公開している推奨CloudWatchアラームを設定しています。加えて、重い検索クエリがあることがすでにわかっているため、応答時間の99パーセンタイル、90パーセンタイルに対するCloudWatchアラームを設定しています。応答時間が目標を下回った場合は、PagerDutyにアラートが送信されます。
アラートの発生頻度が高い場合は、原因調査を行います。このとき特に役立つのが、Elasticsearchのスロークエリログです。私達はCloudWatch Logs Insightで調査用のクエリを事前に作成しておき、アラート発生時はそれを使って応答時間上位のクエリの傾向を調べています。
このように集めた情報を元に、AWS TAMとの定期的な議論を行っています。そして、その結果をもとに、改善提案のプロダクトバックログへの項目の追加や、優先度の見直しをしています。
現在進行中の改善
このようなプロセスを通して、現在進めている改善を一つご紹介します。
現在、私達は課題検索機能で使用しているElasticsearchクラスタのデータノードのインスタンスタイプの変更を試しています。
本番環境での半年以上の運用を通して、特定の重いクエリによるReadIOPSの増加が原因で、クラスタ全体の応答時間が悪化するという障害が徐々に増えてきました。これは、前述のCloudWatchでの監視と、AWSサポートに依頼して行って頂いた調査から判明しました。
低リスクですぐにできる対策として、まず、データノードのEBSボリュームをgp2からio1に変更し、IOPS上限を上げることを提案・実施しました。これにより、障害の発生頻度を下げることができたのですが、io1ボリュームは高価で、かつ一度上げたIOPS上限にも近いうちに再び到達する可能性が出てきました。
そこで、データノードを現在のc5インスタンスから同価格帯のi3インスタンスに切り替えることを、新たに提案しました（プレゼンではm5と話してしまいましたが、正しくはc5でした）。しかし、c5から同価格帯のi3に変更するとIOPS上限は大幅に上がるものの、vCPU数は減ってしまいます。つまり、インスタンスタイプの変更後に別の性能問題が発生するリスクがありました。
そのため現在は、従来のc5のクラスタと、新しいi3のクラスタを並行稼動し、性能検証を進めています。1ヶ月ほど並行稼動し、その結果次第でi3クラスタへの移行を行う予定です。ちなみに、この並行稼動のための機能は元々なかったため、SRE課の開発者がアプリケーション側への機能追加を行いました。
NuCon 2020の発表で触れなかった話題
最後に、NuCon 2020の発表では、時間の都合で触れられなかった話題をいくつか紹介します。
SREを開発チームの外に出したデメリット
SREを開発チーム所属にするか、開発チームとは別のSREチーム所属にするかを検討した結果、現在はSREチーム（SRE課）所属にしているという話をしました。ここまではそのメリットを中心にお話ししましたが、SREから開発チームの細かい状況がわかりづらくなるというデメリットは確かにありました。
しかし、Backlogに関して言えば、開発チームとSREの間で定期的な情報共有を行うことで、このメリットはある程度緩和できていると感じています。
まず、Developers Meetingに開発者とSREが参加するミーティング（Developers Meeting）を週1で開催し、直近〜数カ月以内のリリース予定の共有や、現在起きている問題についての議論などを行っています。また、開発者とSREに加え、プロダクトマネージャーの白川が参加するプロダクト相談会を隔週で開催しています。安定性やセキュリティに関わる開発のうち、プロダクト目線での判断が必要なものはこの相談会で提案し、意見をもらっています。
プロダクトをまたいだ横の連携
「2019年以降のSRE組織」の節で、SRE課はプロダクトをまたいだ横の連携を進める役割も持っているということをご説明しました。しかし、この横の連携の具体例については発表内で触れなかったため、気になった方もいるかもしれません。
この横の連携については、正直言って私よりももっと貢献しているメンバーが大勢いるため、そのメンバー自身に別の機会に発表してほしいと思っています。今後のイベント（NuCon 2021？）での発表にご期待ください。
まとめ
今回の記事では、ヌーラボにおけるSRE組織の試行錯誤の歴史と、それらを踏まえた現在の組織・プロセスをご紹介しました。また、現在の組織・プロセスの適用事例として、私がプロジェクトマネージャーとして参加していた、Backlogの課題検索機能のリプレイスプロジェクトについてもご紹介しました。
SREを開発チーム所属にするか、開発チームとは別のSREチーム所属にするか、についてはいろいろな会社で議論になっていると伺います。その会社やプロダクトの状況に応じて、どちらの組織体制が望ましいかは異なると思いますが、今回の記事がそのような悩みを解決するための参考になれば幸いです。
また、今回ご紹介したヌーラボのSRE組織での働き方に興味がある方は、ぜひ「ヌーラバーの話を聞いてみたい」からお問い合わせください。
