こんにちは、Backlog SREチームのmuziです。 この記事は SRE Advent Calendar 2019 の10日目、およびBacklog Play化プロジェクトブログの番外編です。 先日のブログ記事「SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】」の後半では、Play化プロジェクトの終了後に、開発チーム自身によるオンコール対応の取り組みを始めたことを軽くご紹介しました。 私を含むBacklogのSREチームは、このオンコール対応を助けるためのアラート通知システムを作り、開発者なら誰でも使える形で提供しています。この記事では、前回のブログ記事では書ききれなかった、このシステムの詳細をご紹介します。 同じような問題意識を抱えていて、これからオンコール対応を見直したい、と考えているSREや開発者の参考になれ

こんにちは、Backlogチームの小久保です。Backlogチームでは、約4年続いたBacklogをJavaからScala / Play Frameworkに移行するプロジェクトについて、2日間かけてふりかえりをしました。そのとき得られた知見を整理してみました。 長くやってきたプロジェクトを振り返ると、プロジェクトに大きな影響を与えた決断がいくつか必ずあります。その決断が正しかったのか、今後の自分たちの重要な意思決定をどう改善していけるか、しっかり考えるためにも効果的にふりかえりをすることが大切です。 本記事では、ITツールの活用方法や特定のプロセスの話は出てきませんが、Backlogチームがおこなった、長期プロジェクトを振り返るために役立ったことを整理してお届けします。 プロジェクトの内容とふりかえりをした理由 Backlog Play化プロジェクトとは、Backlogの動作環境、コード

こんにちは。Raspberry Pi4でようやくギガビットLANにネイティブ対応したことにテンションが上がっているBacklog開発チームの佐藤です。 ヌーラボでは2015年11月から2019年の7月まで、BacklogをJavaからScala / Play Frameworkに移行するという大規模なリプレイスプロジェクト（以下、Play化プロジェクト）を行っていました。 私は2017年の夏からプロジェクト完了までこのプロジェクトに参加していました。 今回の記事では、Play化プロジェクトに途中参加した立場で、プロジェクト中に起きた出来事と当時の心境、問題をどう乗り越えたのか、反省と教訓についてもお届けします。 プロジェクトに参加する前は何をしていたか 出来事：Backlogの機能改善チームからPlay化プロジェクトチームへ移動 心境：不安だがトップダウンで決まったのではなく、自分自身の意

Backlog SREチームのmuziです。2018年4月から2019年7月まで、BacklogをJavaからScala / Play Frameworkに移行する大規模なリプレイスプロジェクトに参加していました。 SREとして、このリプレイスにはかなりの困難が伴いました。特にBacklogのサービス安定性は大きな問題でした。 本記事では、こうした問題に対して、SREである私がどういうアプローチを取ったのか、そしてこのプロジェクトで得られた教訓を今後チームや組織全体でどのように活かそうとしているかをご紹介します。 正直言って、泥臭い話だらけの内容です。それでも、技術的負債を抱えたプロジェクトでSREが取れるアプローチの事例の一つとして、読者の参考になれば幸いです。 はじめに ヌーラボでは2015年11月から2019年7月まで、BacklogをJavaからScala / Play Frame

ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine（以下、JVM）上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ

ヌーラボの江口です。約8年間Backlogの開発を担当しており、BacklogをJavaからScala / Play Frameworkに移行するプロジェクトには最初から最後まで関わりました（プロジェクトの概要は時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 本記事では、BacklogのScala / Play Framework化プロジェクトで「Backlogのサーバーサイドを進化させる“土台”を作る」をテーマに、どのようにBacklogのアーキテクチャを設計・実装したのかご紹介します。 はじめに 私は2012年の入社以来、Backlogの開発を担当しています。Backlogは10年以上続くサービスであるため、度重なる機能追加や修正を行うことで複雑化し、日頃開発をする上で様々な問題を感じていました。 今回のBacklogのSca

ヌーラボの松本です。「Backlog Playプロジェクト」に2017年2月から途中参加し、プロジェクト解散の2019年7月までメンバーの一員として動いていました（プロジェクトの概要は 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 このBacklog Playプロジェクト(以下、Play化プロジェクト)では、期間によって私の役割は変わりました。 参加した当初は開発メンバーとしてコードを書いていましたが、2018年4月からプロジェクト終了の2019年7月までは、開発をしながらプロジェクトの取りまとめをしていました。 マネジメントのような役割ははじめてだったので、いろいろ未熟な点もありましたが、プロジェクトの機能リリースを早めるために、不具合対策や手戻り削減といった問題と向き合いました。 本記事では、私のPlay化プロジェクトでの役

ヌーラボの松浦です。私がSREのエンジニアリングマネージャーとしてプロジェクトのサポートに携わっているプロジェクト管理ツールのBacklogは、2019年7月にJavaからScala / Play Frameworkに完全移行をしました。 このPlay化プロジェクトは、10年がかりで改良され仕様が明文化されていなかったBacklogを、JavaからScala / Play Frameworkに移行するという壮大なプロジェクトでした。 約4年にわたる「Backlog Playプロジェクト」(以下、Play化プロジェクト) で体験した“紆余曲折”を記録に残し、後のプロジェクトにつなげるために、今回から7回に渡って、技術的な挑戦やプロジェクト管理の視点など、当時のチームメンバーが独自の目線でPlay化プロジェクトを振り返った記事を連載します。 連載第1回目の本記事では、序章としてPlay化プロジ

テクノロジー 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話【Backlog Play 化プロジェクト】