この記事は ヌーラボブログリレー2023 for Tech Advent Calendar 2023 – Adventar 24 日目の記事です。昨日の記事は Makoto Fukuda さんの イベントで撮影スタッフを依頼される時に思うこと でした。 こんにちは、SRE 課 Backlog Platform Engineering チームで Backlog のプラットフォームとして Kubernetes(Amazon EKS ※以下 EKS と記載) クラスターの開発運用をしている大野、吉岩です。この記事では EKS クラスターの運用で重要な要素の一つであるクラスターの継続的なアップデートを実現するために、私達がどのようにアップデートに取り組んでいるかについて書いています。 Backlog で利用している EKS クラスターについてはアプリケーションのコンテナ化の発表で触れていますが、E

SRE課で、主にBacklogのSREを担当しているMuziです。 物理サーバやインスタンスで動作していたアプリケーションを、Kubernetesクラスタに移行する際には、いままで暗黙的に存在していた前提に目を向ける必要があります。そのような前提を無視すると、アプリケーションは動作したとしても、可用性が悪化する可能性があるためです。 私たちがBacklogをEC2インスタンスからKubernetesクラスタに移行した際にも、可用性の悪化に繋がる問題に対処する必要が生じました。今回は、そのような問題の一つであるGraceful Shutdownに関する注意点を、私たちの実体験をもとにご紹介します。 なお、以下の内容はAmazon EKSのKubernetesバージョン1.22で確認しました。Amazon EKSに固有の話題も含みますが、Kubernetes全般に共通する部分も多いかと思います

SRE課で、主にBacklogのSREを担当しているMuziです。 Backlogでは2019年8月から、アプリケーションの障害については、開発チーム自身が対応できるオンコール体制を取っています。これにより、サービス影響の少ないアプリケーション障害については開発チーム自身で対応できるようになりました。 しかし、サービス影響の大きいものについては依然としてSREの対応が必要な状況が続いていました。この問題を解決するために、インシデント対応をするオンコール担当者のためのチェックリスト（以下、インシデント対応チェックリスト）を新たに考案し、今年の7月から導入しました。 今回の記事では、このインシデント対応チェックリストの詳細に加えて、導入に至った背景からその効果までご紹介します。開発チームへの運用ノウハウの移管について悩んでいる方の参考になれば幸いです。 Backlogのオンコール体制 元々、B

DOZAN11(元 三木道三)とXamarin開発の第一人者が語る、アーティストと開発者の協創とコミュニケーションのヒント スマートフォン向け音楽自動生成&動画作成アプリ「mupic」は、画像の色を解析して、その配色や明るさなどから出来たオリジナルの楽曲が付いた動画を保存できるプロダクト。このアプリケーションの開発を手がけたのは「Lifetime Respect」で爆発的なヒットをした三木道三ことDOZAN11氏とXamarin開発の国内第一人者でもある青柳臣一氏が代表取締役を務める「株式会社ディーバ」。 mupicの開発秘話から垣間見えた、アーティストと開発者、ユーザーとの「協創」の精神。それを実現するための「コミュニケーションのヒント」についてお話をお伺いした。 ■プロフィール（写真左から） DOZAN11：96年、「三木道三」名義でジャマイカ拠点のレーベルからデビュー。2001年に発

これは SRE Advent Calendar 11日目の記事です。 こんにちは、Backlog の SRE を担当している吉澤（Muzi と呼ばれている人）です。 本記事では、SRE Lounge #5 で講演した際に、時間の都合で省略した「ヌーラボ社内での Backlog のサービスレベル計測とその結果の活用」についてご紹介します。 長年運用されてきたサービスを改善するために、SRE ができる取り組みの一例としてご参考ください。 SRE とは？ SRE とは、Site Reliability Engineering の略です。これは Google で初めて提唱された概念で、その提唱者自身は著書「SRE サイトリライアビリティエンジニアリング」（いわゆる「SRE 本」）のなかで以下のように述べています。 Google 内で規定されることになったサイトリライアビリティエンジニアリングとは、