フォーム読み込み中
本記事では、ソフトバンクがAzureマイグレーションを支援した年間数百テラバイトクラスの転送量を誇る大規模Webサーバ環境を例に挙げて、具体的にマイグレーションで考慮すべき事項を紹介します。
近年WEBシステムマイグレーションを検討する際、マイグレーション先としてパブリッククラウドを第一候補とする事例は少なくありません。
マイグレーションを検討する理由はさまざまありますが、オンプレミス環境の老朽化や、OSの保守サポート期限がトリガーになる事が多い傾向です。
今回マイグレーションを実行された企業様(エンターテインメント業界・従業員数: 100名様)は、年間転送量数百テラバイトを越える巨大なBtoC Webシステムを運用されています。
Microsort Azure(以下、Azure)はWindows Serverや Azure Virtual Desktopサービスといった、Windowsのイメージが先行しがちですが、こうしたWEBシステムを支えるLinuxサーバや、MySQLやPostgreSQL等のRDBMSについてもマネージドサービスを提供する等、非常に高い実力を持っています。
マイグレーションにあたり「CDNとトラフィックルーティング」「Linuxサーバリホスト」「PostgreSQLリファクタリング」の3点に注目し、どのような考慮事項があるのか、実例に基づいてご紹介いたします。
今回の移行対象サービスにおけるトラフィック流量が年間数百テラバイトを越えるレベルである事は前述の通りですが、BtoC Webシステムの特徴としてトラフィック流量は常にスパイクの可能性がある事を考慮しなければいけません。
移行前の環境上でもすでにCDNサービスを導入済みでしたが、静的コンテンツについては引き続きEdge応答する事が、パフォーマンスとコスト両面の最適化につながると判断し、Azure環境上でも引き続きCDNサービスを利用する事に決定しました。
Azureでは複数のCDNサービスが提供されており、スタンダードSKUではVerizon (S1)/Akamai (S2)/Microsoft (クラシック) (S3)の3種が、プレミアムSKUではVerizonの1種が利用可能です。
詳細は別記事「Azureで「お問い合わせフォーム付きサイト」をサーバレスで作ってみた!前編」の 「3.2 Azure CDNのデプロイ」を参照してください。
本システムは、URL Rewrite機能が必須でしたので、プレミアムSKUが必須という状況でしたが、URL Rewrite機能の中にHTTPヘッダやCookie判定を複合的に行う高度な処理が含まれている事が分かりました。
限られた移行期間とリソースの中で、CDN移行を行う事は高リスクであると判断し、今回のマイグレーションスコープからは外すという判断をしました。
パブリッククラウドにリフト/シフトするというシチュエーションでは、つい全てパブリッククラウド上のサービスやコンポーネントを使わなければならないと錯覚してしまいがちですが、決してそんな事はありません。
今回マイグレーションに関わるリスク低減の為、あえてCDNは従来据え置きのままとし、Originとして複数リスナーを持つ ApplicationGatewayを用意し、従来CDNのOrigin変更のみでトラフィックルーティングの切り替えができる構成をとりました。
ありがたい事にこの構成の場合、切り戻しが必要になった場合も、従来CDNのOrigin変更のみで切り戻しができる事から、実際にリリースにあたったチームはリラックスして作業に臨むことができていました。
今回移行対象となったLinuxサーバは、Webサーバの他に、CMS機能を提供するコンテンツ管理サーバ、画面情報に挿入する特殊コンテンツの生成やAPIを提供するアプリケーションサーバ等、用途ごとに個別のゲストOSが仮想環境上に構築された状態となっていました。
いずれのホストも、本番環境ではRed Hat Enterprise Linux(RHEL) 7系、ステージング/開発環境ではCentOS 7系のOSが稼働していましたが、今回のマイグレーションに合わせて、同一ディストリビューションで最もOS保守サポートが長いバージョンを採用するという方針で検討を進めていました。
一方、ちょうど検討を進めていた時期にCentOS7の後続バージョンとなるCentOS8の保守サポートが 2021/12/31に短縮される事が明らかになりました。
加えて、後継となる CentOS Stream 8についてはアップストリーム版である事から、ステージング/開発という用途には適さず、別ディストリビューションを検討する必要が生じました。
RHEL互換かつダウンストリームという観点から、Azure MarketPlace上でも提供されている「Alma Linux」や「MIRACLE LINUX」の検討を行いましたが、今回のマイグレーションではCMSアプリケーションに大幅な変更を加える事が決まっていた為、ステージング/開発環境におけるOSレイヤでの完全な互換性を求められていた事情があり、これらのディストリビューションを採用する事は、大変高いハードルでした。
暗中模索の中急浮上したのが、Pay as you go(PAYG)課金利用を前提に、全ホストで「RHEL8」を利用するというアイデアです。
PAYGは 「Azure 上の Red Hat ワークロード」 にある通り 従量課金型の利用方式で、Azure利用料と合算されて、OSライセンス利用料が請求されるプランです。
また、OSサポートについては、Microsoftを通じて提供されます。
この方式の優れた点は、従量課金制が実際のVM稼働時間に応じた課金となる点です。
ステージング/開発環境は、必要に応じてVM起動するという要求でしたので、稼働時間を09:00-17:00の平日(20日間/月)のみに限定すると、24時間稼働する場合と比べてOSライセンスコストが25%以下に抑えられる試算になりました。
全VMにRHELを採用する事で、当初予定よりもコストはかかる事になりましたが、PAYG課金モデルを適用する事で弾力性のあるアプローチが出来た事はまさにパブリッククラウドならではの解決策です。
今回OSのベースが全てRHEL8系に統一された事により、ベースイメージの統一化が図れましたので、OS基本設定が完了したVirtual MachineイメージをAzure Backup機能を利用して、別Virtual Machineとして展開する事により、多数のホストを水平展開する事に成功しました。
この他に、ログ転送機能は従来Syslogサーバ向けに転送していた内容を、Azure Log Analyticsサービスに切り替えたり、非機能要件としてのデータセンター冗長機能を可用性ゾーンで実現する等、Azureならではの機能を活かしながら展開を進めています。
一方、オンプレミス環境で実装するクラスタ機能等は、そのままパブリッククラウド環境上に持ち込めないケースもあります。
今回のサーバ構成では、一部のAct/Stb冗長をクラスタ用ソフトウェアを用いて実現している箇所があり、Azure Vnetがサポートしないブロードキャストやマルチキャスト通信を利用せず、ユニキャスト通信で実現するよう調整するなど、パブリッククラウドマイグレーションならではの考慮事項もありました。
今回のシステムには、主に会員情報等を保存する為のPostgreSQL Databaseがあり、こちらについてはリファクタリングの対象でした。
可用性要件の観点から、複数の可用性ゾーンにまたがったマネージドサービスが第一候補となり、2021/11/30に一般提供が開始されたばかりの Azure Database for PostgreSQL - Flexible Serverを移行対象として選定しました。
データやスキーマの移行に備え、従来システム側をマイナーバージョンも含めて一致させる作業を事前に実施しました。
これに加え、PaaS型サービスの為スーパーユーザロールをMicrosoftのみが保有しているという特殊事情がある為、dumpデータのリストア時に例えば「OWNERへの権限変更」が含まれてしまう場合に、スーパーユーザロールがなくエラーになってしまうようなケースにも遭遇しました。
これは、pg_restore コマンドの実行を、OWNERとなるべきユーザで実行する事と、 --no-ownerオプションを付与し、権限変更のクエリを発生させない等のひと手間が必要です。
その他、Azure Databaseでは、pg_configにあたるコンフィグレーションは「Server parameters」から変更を行います。
TimeZoneが標準設定ではUTCになっているので、日本国内のシステムだとJSTで運用されているケースが一般的だと思いますので、これを変更する事も必要です。
尚、TimeZoneの変更のみでは、各データベースへの設定変更が反映されないケースがあるようなので、その場合は個々にALTERで変更をかけていく必要があります。
postgres=> ALTER DATABASE postgres RESET timezone;
postgres=> ALTER DATABASE postgres SET timezone TO 'Asia/Tokyo';
その他、例えばクエリログを取得したい場合には診断設定上で「PostgreSQL Server Logs」を有効化し、「Server parameters」から、shared_preload_librariesの pgauditを有効化する事(インスタンスの再起動が必要)、 pgaudit.log内の設定値「DDL」を有効化する事で取得できるようになります。
診断設定の出力先はLog Analyticsを指定して、ログの検索性を上げたり、アラートに利用する他、コストを節約したい場合はBLOBストレージに出力する事も可能です。
こうしたAzure PaaSとしての挙動は、トライアンドエラーを繰り返しながら実際に環境構築をする事が一番の近道です。
実際にこの案件でも本番カットオーバーまでの期間は、インスタンスサイズを小さくして課金を抑制しながら、既存環境のアセスメントと平行しPaaSサービスにフィットするようマイグレーションを進めました。
機器発注の兼ね合いから現状アセスメントを完璧に遂行した後に、マイグレーション計画を策定しなければ行けなかったオンプレミス全盛とは異なり、トライアンドエラーが許されるのがパブリッククラウドの利点です。
クラウドのアジリティ(迅速性)を享受する為に必要なマインドセットは「まずは試してみる」という事につきます。
ソフトバンクは、お客さまの「まずは試してみる」に日々伴走させていただきながら、豊富なナレッジを蓄積し、クラウド推進パートナーとして高い実力を持っています。
パブリッククラウドに関する導入課題等ございましたら、ぜひソフトバンクへお声がけください。
条件に該当するページがございません