Red Hat Summit 2024から、20万台のCentOS 7をRHEL 9に移行したSalesforceのセッションを紹介

Red Hat Summit 2024から、Salesforceが自社のCentOSサーバー20万台をRHEL 9にマイグレーションしたユースケースを解説したセッションを紹介する。セッションのタイトルは「Mass migration magic: 200K machines from CentOS to RHEL 9 with Salesforce」というもので、プレゼンターであるSalesforceのエンジニア4名が順番に登壇して説明を行うという内容だった。プレゼンテーションを行ったSalesforceのエンジニアはAnish Bhatt氏、Ivan Garcia氏、Varun Gupta氏、Kevin Naderkhani氏の4名で、このうちのBhatt氏はこの移行に関する解説をSalesforceのブログに書いた著者でもある。

●参考：Automation at Scale: Migrating 200,000 Machines from CentOS 7 to RHEL 9

ちなみにRed Hatのプレスリリースにもこのユースケースに関する内容が存在するが、そこではCEOのMatt Hicks氏のコメントも記載されている。

●参考：Salesforce Standardizes Global Hybrid Cloud Infrastructure on Red Hat Enterprise Linux

過去25年に渡るSalesforceの機能強化や買収について振り返るスライド

まず過去を振り返るスライドではSalesforceの機能強化だけではなくHeroku、MulesoftやSlack買収についても触れているのが興味深い。

ここで保持するサーバー約20万台を紹介。16ヶ国にデータセンターを展開中

しかしチャレンジというスライドでは、複数のCPUアーキテクチャー、100を超えるインスタンスのタイプ、1年間に1300万回のOSのアップデートを実施していることを解説し、20万台のサーバーのメインテナンスが大きな労力を必要としていたことを説明した。

20万台のサーバーには複数のCPUアーキテクチャー、100を超えるインスタンスが存在

そして移行元となったCentOS 7のEOL（End of Life）が2024年6月30日に設定されていたため、どうしてもそれまでに移行を完了させたいという意図があったことも紹介された。

CentOS 7からの移行は2024年6月末日までに完了させたいという目標設定

そしてCentOSの移行先として選択されたのが、Red Hat Enterprise Linux（RHEL）9というバージョンだ。

移行のためのチーム作りだけではなくプログラムの進行のモニタリングまで

ここでは移行のための組織作りだけではなく、カバーする範囲や移行の進行をどのようにトラッキングするのかなどについても検討されたことが示されている。

問題点としてカスタムメイドのOSイメージが複数存在することや複数のリポジトリーなどが挙げられているが、併せて、技術的な負債の存在やビジネスオーナーの独り善がり的な態度なども移行をスムーズに進めることへのハードルとして発見されたことなどが解説された。

技術的負債もビジネスオーナーのエゴも失敗に通じる要因となる

移行のための具体的なプロセスを解説したスライドでは、20万台のサーバーの移行のためには何よりも自動化が不可欠であることを解説。前回のCentOSへの移行の際に多くのマニュアル操作が必要だったという経験から、移行の自動化が大きなチャレンジだったことがわかる。

20万台のサーバー移行には自動化が必須

移行前のサーバーをプールとしてデータ化し、モニタリングの停止からシステム自体の停止を経てRHEL 9への更新、データの復旧から移行済みサーバーのプールへの登録と一連の作業が抽象化されていることを解説するスライドを使って説明。

Salesforceのサーバーに「必要なのは家畜でペットではない」と説明

サーバーの抽象化とデータの分離などを行うことで、サーバーをペットのように扱うのではなく家畜のように扱いたいというのがこのOS移行の際のテーマだったことが説明されている。

また自動化についても構成管理の自動化、オーケストレーションの自動化に加えて、サービスが正しく実行されているのかを確認するヘルスチェックまで含んでいることも解説された。

OSのリビルドは自動化されヘルスチェックも自動的に実行される

またヘルスチェックの項目について解説したスライドではハードウェア、ファームウェア、サービス、ネットワークの状態などを含めてチェックが行われ、最低限の数値を下回るようになったサーバーやサービスは自動的に停止され報告が行われるという。また移行はパラレルに実行されることが大前提として設計されていることも重要なポイントだ。

ヘルスチェックの概要

移行のためのステップは宣言的に行われるように設計され、移行後の構成をゴールとして並行的に実行され、ひとつのホストが移行を完了したら、自動的に次の移行対象のサーバーが選択されるという。

移行のプロセスは自動化され、宣言的なゴールに向かって並列実行される

移行が必要なコンテナについても軽く触れているが、仮想マシンに比べて容易だったこと、Red Hatが提供したパッケージを使うことで異なるアーキテクチャー間でシステムの移行が行えたことを説明した。

コンテナの移行は比較的容易だったと説明

自動化された移行プログラムではあるが、古いアーティファクトに残っていたOSのアップデートパッケージを消去することでダウングレードが行われないこと、古いアップデートがOSに適用されないことなどをポリシーとして定義したことなども解説した。

古いパッケージを消去することとポリシーを定義することが重要

最後に今回の移行プログラムで学んだことを紹介。

CentOS 7のEOLまでの経験からの学びを紹介

エンタープライズ向けのシステムを移行させるのは難しく、特に人的な要因が絡むとさらに難しくなること、ゴールの設定を最初からちゃんと行うこと、ビジネスオーナーを含む社内コミュニケーションが必須であること、常に質問を投げられるような仕組みを作っておくことなどを挙げてセッションを終えた。

SaaSのリーディングベンダーとして経験も豊富なSalesforce.comをもってしても、構築当時は最先端のシステムが時間の経過とともにレガシーになってしまうこと、テクノロジーだけではなく人的な要素も含めて移行プログラムを設計する必要があることを強調した内容となった。具体的な数値や利用したツール、テクノロジーなどについては公開されなかったが、自動化のポイントは押さえた内容となった。