【Unit1 ブログリレー 6日目】 この記事はUnit1ブログリレー 6日目の記事です。前日の記事は こちら 。
エンジニアリンググループGMの木田です。
先日、数年に一度の規模のシステムメンテナンスを実施しました。メンテナンス作業自体は複数のチームが関わり、サービスの計画停止も伴う複雑な作業だったにもかかわらず、入念な準備のおかげで大きなトラブルもなく予定時間を1時間ほど前倒しで完了できました。
関係者で行った振り返りで今後も続けたいプラクティスが多く得られたので、その学びを「やってよかった」準備集として整理してお伝えします。大規模なシステムメンテナンス作業を計画している方の参考になれば幸いです。
メンテナンスのあらまし
エムスリーが運営する医療従事者向けの情報提供サイト「m3.com」を中心に、多数のWebサービスを提供しています。これらの多くは24時間365日稼働しており、メンテナンスのためにサービスを停止することは極めて稀です。
今回は、クラウド移行が進んだ結果を受けて、オンプレミスのサーバーのダウンサイジングを行うためのメンテナンスを実施しました。DBサーバー切り替えやデータ移行も伴う作業が必要であったため、約6時間のサービス停止、25以上の関連システム*1、複数チームが連携する大規模な作業でした。SREチームがリードし、複数のアプリケーションチームが参加する体制で臨みました。
Unit1では、製薬企業向けのマーケティング支援サービス「MR君」や「Web講演会」などの 「m3.com」上の主力サービスを開発・運用しており、今回のメンテナンス作業と関わりが深かったためSREチームと密に連携しながら、手順作成や検証作業で主たる役割を担いました。
大まかなタイムラインは次の通りでした。
- 1年前: SREチーム中心に計画立案開始
- 6ヶ月前 ~ 3ヶ月前: 関係者全員でキックオフ (全体概要の説明、今後の進め方の議論など)
- 3ヶ月前 ~ 1ヶ月前: 各チームでの事前準備や個別のリハーサル (影響範囲の確認、作業手順の検討、性能テストなど)
- 2週間前: 総合リハーサル (関係チーム全員で全体の流れを通して確認、手順のすり合わせ)
- 当日: 本番作業
「やってよかった」 準備作業
リハーサルは絶対に実施する。できれば複数回。
事前にQA環境でリハーサルしていたことで、具体的な進め方も理解できたし作業手順の問題点も洗い出せた。
当たり前の事ではありますが、リハーサルは重要です。何らかの形で必ず実施すべきだと考えています。 今回私たちはチームごとの手順読み合わせやデータ移行など目的別に複数回実施し、それに加えて関係チームが全員集まって本番と同じ流れ・同じメンテナンス時間で総合リハーサルも行いました。
総合リハーサルをやったことで手順の抜け漏れや不備だけではなく、当日の関係者間のコミュニケーションや情報共有も含めて手順を作り込めたことが大きな成果でした。チーム間・タスク間の依存関係もクリアになったのが当日の円滑な進行につながりました。
リハーサルでの振り返りが本番の「やってよかった」につながる
リハーサルの振り返りに基づいて本番作業時の改善点として以下のような施策を実施しました。
- 作業の実況: 作業ログの共有に加えて、"今やっていること"や"気がついたこと" の発信も含めたSlack上での実況
- 作業リストの改善: 当日不要なステップの省略、作業完了ステータスの明示
- 作業ステータスの可視化: タスク管理表を常時Zoomで画面共有し、全体の進行状況を可視化
また、上記以外にもメンテナンス表示対象画面の抜け漏れや手順の不備、スクリプトのバグなども多数検出できて、本番作業の品質向上に寄与した有意義な活動でした。
本番と同じデータ量で試す
データ移行作業のリハーサルによって新DBにデータが投入された状態で負荷試験を実施できた。限定的な条件ではあったが試験結果の性能見込みは割と近い値になっていた。
データ移行作業のリハーサルと合わせて、新DBに本番相当のデータ量が投入された状態での負荷試験も実施しました。検証環境としてはダウンサイジング後の新本番環境を使用しました。
移行後の本番環境に極力近い条件で測定したことで、机上の計算では把握できない実際のパフォーマンス特性を確認できました。
稼働中の各種マイクロサービスとの連携などまで含めた厳密に本番と同条件での試験は諸々の制約があったため、可能な範囲での検証に留めました。しかし、当日の作業時間内に収まることや切替後の負荷が十分に計画範囲内である見通しを立てられたことで、当日の安心感につながりました。
タスクと進捗状況を可視化する
動作確認項目を事前に整理・共有していたため、当日は「次は誰が何を確認するか」で迷うことがありませんでした。
タスク管理のためのGoogleスプレッドシートを用意して、各チームの担当者がリアルタイムに進捗状況を更新できるようにしていました。 Zoomの画面共有で常に進捗状況を映し出し、全員が現在の進行状況を把握できるようにしました。
メンテナンス作業のリスクを下げる
切り替え後の動作確認のための自動リグレッションテストを充実させたり、古いデータのアーカイブ・削除を事前に実施したりしました。また、監視周りが充実していたのも想定外の問題を捉える（問題が起きていないことを確認する）のに役立ちました。
これらの活動、特にテストの整備や監視の充実は本件のメンテナンスのためだけに行ったわけではなく、日頃から継続的に取り組んでいる改善活動の一環です。
普段の保守性・運用効率の向上のために行っていた活動が、大規模メンテナンス時のリスクを軽減するという副次的な効果をもたらし、結果として１時間前倒しで作業完了できた要因の１つと考えています。
作業実況を活発に共有する
・作業中はzoomと作業画面で手一杯になっていたので、後で見返せるようにログやスクショが残っていたのは有り難かった」
・Slackで活発に実況があり状況がわかりやすかったと思う
・当日作業があるメンバーはslackに書き込むのは大変なので、別にアナウンスやタイムキープをするメンバーが決まっているとよい。当日作業に限らずプロジェクト全体でコミュニケーションをリードするメンバーを決めておくのもよさそう
リハーサル・本番ともに、Zoomで会議室を立て、関係者で集まり、Slackにも作業スレッドを用意しました。Zoomに全員が参加し、画面共有で固定の進捗管理シートを映し出しながら、全体の状況を共有し、個々の作業はチーム別にSlackの作業スレッドを立てて各自が作業状況やスクリーンショットを投稿する形で進めました。
この取り組みはWorking Out Loud*2の実践例として効果的だったと感じています。特に本番作業時は当日の関係者数も多くオフィスとリモートに分かれて作業のフェーズごとに入れ替わりながら対応したため、途中参加・退出したメンバーも含めて全員が現在の状況を把握するに役立ちました。
その他準備しておいてよかったこと
上記で紹介した以外にも、準備をしておいてよかったという声が多数ありました。入念に準備をして臨んだので問題が発生しても慌てず対処できるだろうという安心感を関係者が持って臨めたのも成功要因と言えます。
- 共通メンテナンス画面の用意
- 万が一の時の切り戻し基準の事前設定
- DBのコネクション監視・可視化ツール
- ステークホルダーへの十分な周知活動
振り返りの記録からいくつか声を抜粋して紹介します。
・コネクション数がちゃんと可視化できていた
・問題発生時に慌てず対処できるように準備を入念にしていた。交代メンバーも含めた体制決め、ダッシュボードなど問題調査の手順作成、縮退案の準備、連絡先の整理など
・切り戻しの判断について基準が設けられていた。基準を設けていたのでトラブルが発生しても対応はスムーズだったはず。
・「知らなかったんですけど」のような混乱がゼロ
さらに良くするための改善点
当日は総じて順調だったのですが、さすがにアクシデントゼロとまではいかず、改善点はいくつかありました。 その場の臨機応変な対応で難なく乗り切れたものばかりでしたが、より万全を期す上で、例えば次のような準備が考えられます。
- メンテナンス作業時特有のアラート整備とテスト
- 権限周りの確認をリハーサル時に充実させる
作業当日いくつか偽陽性のアラートが発出*3しました (m3comは歴史も長く、各チーム各サービスで様々なアラートがあり、事前に全て把握することは難しいと踏んでいました) 。
また、本番環境と検証環境の権限設定の違い(本番環境の方が厳格)や、リハーサルと当日で作業担当者が交代したことでリハーサル通りの手順で作業できなかったりする場面がありました。
本番設定を厳密に再現した検証環境を構築したり、リハーサルの検証観点に手厚く盛り込んだりしておけば回避できたかもしれませんが、過剰な準備をしすぎるのも現実的ではないため、作業の規模・リスクとコストのバランスを考慮しながら計画すべきでしょう。
まとめ
大規模なメンテナンスの振り返りを通じて「やってよかった」と感じられた事前準備を振り返り参加者の声も交えて紹介しました。 こうして改めて言葉にしてみると当たり前のことばかりですが、1つ1つを確実に実践することで、大規模なメンテナンスであっても大きなトラブルなく乗り切れることを実感しました。
チェックリスト
- リハーサルの実施
- 作業状況の共有・実況体制
- 本番同様のデータ規模での性能テスト
- 作業の複雑度・難易度を下げるための工夫
- 万が一の時の対応手順・基準の設定
- アラート・権限周りのチェック
- 当日必要になるツールの準備 (共通メンテナンス画面や監視ダッシュボード、問題調査用スクリプトなど)
同様の大規模作業に取り組む際はご活用ください。
We are hiring!
次の大規模メンテナンスの計画は未定ですが、エムスリーでは信頼性の高いサービスの開発・運用を支えるエンジニアを募集中です。少しでもご興味をお持ちの方は、以下ページよりカジュアル面談等にお申し込みください！
