本ブログについて
朝日ネットのoshikawaです。これまで開発部のエンジニアがブログ記事を執筆していましたが、今年度は開発部だけではなく、インフラ、ネットワーク、サービス運用といった朝日ネットの技術部門全域に拡げてお送りします。
はじめに
当社クラウド基盤上にてCentOSで運用する約200ホストのサービスを足掛け1年ほどかけアップデートした話です。
背景
サービス運用開始以来32bit版のCentOSで運用していましたが、OSのEOL1が迫っていることや何より32bit OSのため性能上の問題に直面しており、日々開発、運用効率の悪化とモチベーション低下を招いていました。
もちろん移行の必要性は認識されており、移行を目的としたCI環境を準備する取組が行われたりもしましたがアップデートは実現しませんでした。ビジネス要求の案件が多すぎて手が回らないことや、そもそもアップデートのためのスケジューリングが出来ていなかったことが原因です。また下記の理由によりバージョンアップ作業、動作検証は困難を極めると予想されていました。
- 作業方法の課題：事情により直接のアップデートパスがないため一斉アップデートはできない
- 作業コストの課題：各ホストごとに別々のサービス利用者がおり、200ホスト分のスケジュール調整が必要
- 検証コストの課題：コードベースが同じだがホストごとに機能の組み合わせや外部システムとの連携もそれぞれ異なる
アプローチ
上記課題の解決を図りつつEOLまでに全ホストのアップデートを完了させるためのスケジュールを立てることとしました。スケジュールを立てるにあたり考慮したのは以下の部分です。
- 専属メンバーをアサインし準備と課題解決にあたる
- アップデート作業にあたりサービス停止が必要なため、比較的調整が容易な長期休暇期間を作業ターゲットとする
- システム構成が単純なホストから少しづつはじめることで移行リスクを削減する
手順も確立しておらずどうしても手探りで進める部分が多いため、片手間ではなくプロジェクト専属メンバーのアサインは必須でした。そこで事前にビジネス要求の案件を整理、調整の上で稼働を確保することとしました。ねらいと全体スケジュールを整理の上で調整に臨みました。
3番目は具体的には約200のホストを構成（機能、外部連携、ホスト・ストレージ・ネットワーク構成など）の複雑さをもとにA～Dの4つに分類し、最初の移行作業は分類A（=最も構成が単純なホスト群）のアップデートのみとし、以降は順次 B、C、D（=最も構成が複雑なホスト群）をアップデートするというものです。リスク回避以外にも簡単なところから手を付けることで取っ掛かりを良くするためです。結果としてこのあとの想定スケジュールにある通り、足掛け1年半に渡る長期間のプロジェクトとなりました。
想定スケジュール
計画策定時点での想定スケジュールは以下です。まずは翌年1月からの移行開始に向けた準備と検証がメインターゲットとなりました。
| 年月 | 期間 | 作業内容 |
|---|---|---|
| 20XX年10月 | 1ヶ月 | 全体計画、課題の洗い出し・スケジューリング |
| 20XX年11月 ～20XX+1年1月 |
3ヶ月 | 課題解決、移行準備作業 |
| 新OS環境の構成、管理方法の決定（Ansible 導入など） | ||
| 自動テスト環境の整備 | ||
| 移行作業の検証 | ||
| 移行スケジュール調整 | ||
| 20XX+1年1月 | 1ヶ月 | 分類A ホストの移行準備、検証と社内ホストの移行 |
| 20XX+1年2～3月 | 2ヶ月 | 分類A ホストの移行作業 |
| 20XX+1年3月 | 1ヶ月 | 分類B ホストの自動テスト環境整備 |
| 20XX+1年4月 | 1ヶ月 | 分類B ホストの移行準備、検証 |
| 20XX+1年5月 | 1ヶ月 | 社内ホストの移行作業、夏移行予定の日程調整 |
| 20XX+1年6月 | 1ヶ月 | 分類C, D ホストの移行準備、検証 |
| 20XX+1年7～9月 | 3ヶ月 | 分類B, C ホストの移行作業 |
| 20XX+1年7～11月 | 5ヶ月 | 分類D ホストの移行準備、検証 |
| 20XX+1年12月 | 1ヶ月 | 分類D ホストの移行作業 |
| 20XX+2年2月 | 1ヶ月 | 分類D ホストの移行作業（予備） |
準備
アップデート方法の決定
前述の通りアップデートパスがないためそもそもアップデート自体が困難と思われましたが、もともと用意されていたアプリケーションレベルの日次バックアップを流用することで「旧ホストからデータバックアップし、新ホストにリストアする」ことで移行できることが分かりました。これによりOSバージョンアップ作業ではなく、新ホストへのデータ移行作業となりました。表題はこの理由によります。
データ移行作業となったことで各ホストの作業時間はほぼデータ量依存であり、各ホストの作業時間の予測とスケジュール調整を容易としました。幸いなことに最初の移行ターゲットである 分類A はデータ量もさほど大きくないため作業時トラブルのバッファ込でも高々数時間程度で終わると予想されました。
また検討過程の中で移行作業は原則プロジェクトメンバー以外で行うこととし、そのための準備もタスクとして追加しました。途中でのタスク追加となり当初は少なからず反発もあったのですが、結果として作業を外部に委託できることでプロジェクトメンバーは作業時のフィードバック対応と次の課題解決に専念することができました。
動作検証
CI環境2を整備し運用上問題がない程度のカバレッジを確保していたので、移行先のOS環境についてもCIを整備し並行運用することとしました。CIでのエラーを修正することにより新規に作成する新OS環境では問題が起きないであろうことがほぼ担保されました。トラブルが起きるとしても「特殊なデータを含む移行の場合のみ」と限定されることでリスク削減、トラブルシュート時のフォーカス限定に繋がりました。
移行作業開始
予定通りもっとも簡単な 分類A のホストより移行を開始しました。移行作業で細かなトラブルはいくつかあったのですが、こちらも予定通り完了することができました。一部のホストとは言え、実際に移行が完了したという事実、成功体験が自信に繋がりました。
またもっとも単純な構成とは言え、実は移行作業パターンが網羅できたことや本番環境ではデータ移行時間が予想よりも短いことが分かったため、作業メンバーを増員して移行スケジュールを前倒しして進めることとしました。実際には上記想定スケジュールの20XX+1年の9月末にはほぼ全てのホストの移行作業を完了しました。
重ねた省力化の工夫
移行作業用のプログラムを開発し、作業ステップごとのログをRedmineチケットにコメントの形で貼ってもらっていたのですが、数をこなす中でコメントコピペもダルいというもっともなフィードバックがあったので、自動投稿3を追加することで作業ステップの成否に専念してもらうことが出来ました。
また当初はスケジュール調整を私が行っていたのですが、稼働人数と調整ルールを言語化、共有することで実際のスケジュール調整も外部（営業部門など）に委託することで進捗管理やトラブル対応に専念できるようになりました。
まとめ
プロジェクトを進めている時は日々課題に追われるように感じたこともありますが、振り返ってみると様々な教訓を得たように思います。言葉にすると当たり前のことばかりなのですが、実践できてないことが多いなあと反省することも多いです。段取りが悪くメンバーにいらぬ負荷をかけたこともあり、プロジェクトメンバーや協力いただいた方々には感謝しかありません。
- なるべくタスクを細かく分割して取っ掛かりを良くする
- 小さな成功体験の積み重ねが自信とモチベーションを生む
- 可能な限り作業を自動化することにより人間のフォーカスを常に限定する
- 人の注意力は有限なため大事な所にだけ使う
- 手順が複雑化する際は機械化によるアプローチを検討
- 手数で解決できる事を切り出すことでスケール化の実現とメンバーの時間と頭を確保
- なによりもプロジェクトメンバーがルーチンワークで埋もれるのは損失
- リソースを確保するためのスケジュールやシナリオ作りは重要
- 特に息の長いスケジュールが予想される場合はなおさら
採用情報
朝日ネットでは新卒採用・キャリア採用を行っております。
