SRE課で、主にBacklogのSREを担当しているMuziです。
ヌーラボでは、2019年から2020年にかけて、Backlogで利用しているEC2インスタンスをAmazon Linux 1からAmazon Linux 2に移行しました。
今回の記事では、このAmazon Linux 2への移行作業をEC2インスタンスの種類ごとにバラバラのトイルとして扱うのではなく、それらのトイル全体をプロジェクトとして扱うことで結果的にうまくいったという話をご紹介します。
ちょっとした工夫レベルの話ですが、みなさんのトイルへの取り組みの参考になれば幸いです。
※注：この記事ではAmazon Linux 2への移行に関する技術的な詳細には触れません。プロジェクトの進め方についての読み物とお考えください。
目次
きっかけ：Amazon Linux 1のサポート期間終了
これまで、Backlogで利用しているEC2インスタンスでは、主にAmazon Linux 1を採用していました。
2018年6月にAmazon Linux 2の正式版が公開され、Amazon Linux 1は2年後の2020年6月30日にサポート期間終了（End of Life、EOL）することが発表されました。その後、このEOLは、顧客からの要望で2020年12月31日に延長されました。
Amazon Linux 1と2は、いずれも名前に”Amazon Linux”と付いていますが、Amazon Linux 2に移行するためにはインスタンスの作り直しが必要で、完了には時間がかかることが予想されました。
Backlogでは、Play化プロジェクトなどの大きなプロジェクトが終了したあとの、2019年10月からAmazon Linux 2への移行を開始しました。すべての移行が完了したのはEOL直前の2020年11月でした。
Backlogのシステム構成
Amazon Linux 2への移行にそれだけの時間がかかってしまった背景を共有するために、まずBacklogのシステム構成を簡単にご紹介します。
Backlogのシステム構成
サービスクラスター
Backlogでは、課題登録やGitなどのさまざまな機能を提供するために必要なEC2インスタンスやデータベースなどをまとめたサービスクラスターを複数運用しています。
各サービスクラスターには、複数の異なる役割（以下、ロール）を持つEC2インスタンスが含まれます。これらのEC2インスタンスが、今回のAmazon Linux 2への移行対象です。インスタンスの設定はロールごとに共通のため、移行もロール単位で行いました。参考までに大まかな規模感を示すと、サービスクラスター数×ロール数で200以上とお考えください。
これらのサービスクラスターは、Backlogの長い歴史のなかで、利用者数の増加に伴って増設されてきました。そのため、サービスクラスターには作成日が古いものから新しいものまで混在しており、その作成時期によってネットワーク構成などに細かな違いが生じてしまっていました。
共通クラスター
Backlogのシステムには、複数のサービスクラスターで共通して必要とされるEC2インスタンスやデータベースなども存在します。これらはBacklog全体、またはAWSリージョンごとに共通のクラスター（以下、共通クラスター）に配置されています。
共通クラスターはサービスクラスターと違い、一度作ると新たに作られる機会はほぼありません。そのため、一部のインスタンスは、Infrastructure as Code（IaC）のための設定ファイルが無い、あるいは設定ファイルはあるが古くなって実行できない状態でした。
開発環境
Backlogの開発環境として、サービスクラスター1個と、共通クラスター1個が存在します。この環境で、Amazon Linux 2移行後の動作検証を行いました。
サービスクラスター上の各ロールについては、開発環境がほぼ整備されていました。しかし、共通クラスター上のロールについては、IaCのための設定ファイルがなく、開発環境が未構築のものも残っている状態でした。
Amazon Linux 2移行のタイムライン
Amazon Linux 2への移行は2019年10月に開始し、2020年11月に終了しました。この期間中に関わっていたメンバーと、移行対象のインスタンスを大まかに表すと、以下の図のようになります。
Amazon Linux 2移行のタイムライン
当初は少人数で進めていましたが、2020年2月時点で必要な工数を見積もり直し、3月からはプロジェクト専任者を増やして再出発しました。以下では、進め方を見直すことにした経緯や、その前後での変化についてご紹介していきます。
当初の進め方
当初、BacklogのSREチームは、Amazon Linux 2への移行タスクを、OSやミドルウェアのセキュリティアップデートのようなトイルとして扱っていました。つまり、SREのなかで手が空いた人が取るトイルという位置づけでした。
ただし、最初はAmazon Linux 2の移行経験があるSREに対応してもらい、移行作業の進め方を固めるのがいいだろうという判断から、Typetalk SREの二橋に参加してもらいました（他の作業との兼務で、週2日参加）。この二橋がメインで作業し、Backlogのプロビジョニングに詳しい山崎がサブとしてレビューを担当しました。この段階で、Amazon Linux 2移行に伴うsystemdの導入などの、基本的な作業は固まりました。
2020年1月末の時点では、完了したロール2件、着手中のロール1件という進捗でした。この時点の進捗から、メインとサブの作業者2名は、このままではEOLに間に合わないとアラートを上げ始めました。
当初の進め方
プロジェクト化
2020年2月に私（Muzi）が参加して、まずAmazon Linux 2移行完了に必要な工数の見積もりを行いました。この見積もりには、1月までにかかった作業時間だけではなく、前述したBacklogのロール数の多さや、サービスクラスターの様々な課題を考慮しました。
この見積もり結果をもとにチーム内で議論した結果、年内に移行を完了させるためには専任者によるプロジェクト化が必要と判断され、3月からAmazon Linux 2 移行プロジェクト（社内での通称は Amzn2 PJ）を開始しました。
プロジェクトは、メイン担当者3名とサブ担当者1名という体制でした。私はプロジェクトマネージャー兼メイン担当者としてプロジェクトに加わりました。
メイン担当者は3名ともBacklog SRE（私、山崎、中野）で、インシデント対応などの臨時タスクを取ることはありましたが、ほぼ移行タスクに専念できました。レビューはプロジェクト内で相互に行い、お互いの作業内容の良い点を取り入れ合いました。
また、サブ担当者はSRE課に所属する開発者の渡邉（Goに強い）で、他の仕事を兼務しつつ、移行タスクのなかで必要になったツール多数を実装してくれました。
Amazon Linux 2移行プロジェクト
プロジェクトの進め方
見積もりの精度を徐々に高める
プロジェクトの進め方としては、まず、ロールバックが必要になった場合に作業時間への影響が大きいロールを優先しました。具体的には以下のロールです。
- サービスクラスター内のロール
- 理由：サービスクラスターごとに段階的リリースする必要があり、かつ共通クラスター内のロールよりもインスタンス台数が多い
- サービス停止を伴うメンテナンスが必要なロール
- 理由：サービス停止を伴うメンテナンスの実施間隔に制約があるため、サービスクラスターごとに段階的リリースすると1ヶ月以上かかる
これらのロールを優先した理由は、プロジェクトを進める中で見積もりの精度を徐々に高め、必要に応じてさらなる人員追加などの判断をしたかったからです。今回の移行では対応すべきロール数が非常に多かったため、2月の見積もり時点では正確な見積もりは不可能と考えていました。
また、サービスクラスター内のロールの移行がほぼ完了した8月末には、共通クラスター内のロールについて再見積もりを行いました。この頃には見積もりの仕方が固まってきていたため、再見積もりは私1人ではなくプロジェクト内で分担することができました。
段階的リリースを行う
2020年12月末のEOLに間に合う範囲で、信頼性を高めるための作業を重視しました。
まず、サービスクラスター内のロールに関しては、段階的リリースを行いました。つまり、最初は1個のクラスターでインスタンスを移行し、数日のインターバルを経て、問題がなければ次のクラスターを移行しました。インターバル中に少しでも問題があれば一旦ロールバックしました。
ただ、すべてのクラスターで直列に作業すると時間がかかりすぎたため、最終的に、最初のクラスター以外の作業は2〜4並列で進めるようになりました。
また、複数のロールの移行作業を並行する必要があったため、移行作業に起因した問題を調べやすくするための工夫も行いました。
「Amazon Linux 2版のインスタンスのサービスイン」だけでなく、「Amazon Linux 1版のインスタンスの削除」も思わぬトラブルの原因になりえます。そのため、以下の図のように、サービスイン日と削除日をそれぞれ並べた表をメンテナンスしました。
作業予定日および実施日のチェックシート
IaCのための設定ファイルおよび開発環境の整備を並行する
「Backlogのシステム構成」の節で紹介したように、従来のシステムにはいくつか問題があり、開発環境でAmazon Linux 2版のテストに成功しても、本番環境での信頼性を保証できない部分がありました。
今回のOS移行は、これらの問題を解決する絶好の機会だったため、スケジュールの許す範囲で、以下のような設定・開発環境の整備も並行して進めました。
- そのロールのプロビジョニングが自動化されていない場合は、設定ファイル（Terraform, Ansibleなど）を新たに作成する
- そのロールのテスト手段がない場合は、自動テストの設定（Serverspec など）またはテスト手順を新たに作成する
- 開発用のサービスクラスター、または共通クラスターにそのロールのインスタンスがない場合は、新たに構築する
もちろん、これはAmazon Linux 2移行が終わるまでの時間とのトレードオフになるため、すべての問題は解決できませんでした。しかし、このときに解決できなかった問題はBacklog上に課題として登録しており、Amzn2 PJ終了後に少しずつ対応できています。
プロジェクトのふりかえり
プロジェクトメンバーの努力と、プロジェクト外のメンバーが他のタスクを引き受けてくれたおかげで、Amazon Linux 2への移行は2020年11月に無事完了しました。また、同月末に関係者全員でプロジェクトのふりかえりを行いました。
移行完了がEOLの1ヶ月前ギリギリだったこともあり、個人的には、もっと前から移行に着手して、プロジェクト化せずに済ませたほうがよかったのではないかと考えていました。
しかし、私にとっては意外なことに、メンバーからはプロジェクト化してよかったという意見が多く聞かれました。
- プロジェクトの期間は長かったが、移行をトイルとして扱ってもっと長くなるよりは、1回で集中できたので良かったのではないか
- 移行作業にチームで取り組んだのはよかった。工数的なメリットに加えて、お互いレビューできる状態で進められたのはよかった
- みんなが、テストやドキュメントなど、次につながる資産を残せたのはすばらしい
考えてみれば、確かに、担当およびレビュアーをプロジェクトメンバーに絞ることで、知識やノウハウの共有がうまく進みました。また、プロジェクトが進むにつれて設定が改善されていき、プロジェクト前半に移行したロールについてもさかのぼって改善された部分がありました。
改善点としては、今回はプロジェクト期間が長かったので、一区切りできた時点（今回の場合はサービスクラスター上のインスタンスの移行が終わった時点）でプロジェクトマネージャーを変えてもよかったかもしれないという意見がありました。
まとめ
Amazon Linux 2への移行作業をEC2インスタンスの種類（ロール）ごとにバラバラのトイルとして扱うのではなく、それらのトイル全体をプロジェクトとして扱うことで、結果的に大きなメリットがありました。特に、作業時間の見積もりと、知識やノウハウの共有の点でのメリットが大きかったです。
また、移行作業のなかで、従来のシステムで整備が不足していたIoCの設定ファイルや、開発環境について整備することができました。
今後、同じような規模の移行作業があっても、さらに短期間で実施できるようになったと考えています。例えば、OSの移行ではなく、EC2インスタンスをインテルプロセッサからARMベースのAWS Graviton2に移行するような場合（Typetalkでの参考事例）にも活かせるのではないでしょうか。
今回の記事が、似たような作業をされるSREの方々の参考になれば幸いです。
