はじめに
こんにちは。ブランドソリューション開発本部WEARバックエンド部SREブロックの和田です。
普段はWEARのSREチーム（以下、WEARSRE）に所属し、開発や運用に加えて、ここ3年ほどはマネージャーとしてチーム運営にも携わっています。
WEARSREは発足以来、クラウドを活用した課題解決に取り組んできました。その一方で、10年以上稼働し続けているオンプレミス環境の運用については、長らく他部署に任せきりの状態が続いていました。
プロダクト専任のSREチームでありながら、システム全体にアプローチできていない。この矛盾を解消すべく、私たちはオンプレミス環境への関与を少しずつ拡大し、最終的に自チームでの運用を実現しました。
本記事では、これら一連の取り組みを振り返りつつ、チームの成長と現場で得られた気づきをご紹介します。
目次
これまでの取り組み
WEARはサービス開始から10年以上が経過したプロダクトであり、元々はオンプレミス環境のみで構築されていました。IISを中心とした多数のWindows Serverで構成され、サービス成長と共に基盤の仮想化や増設を繰り返しながら拡大を続けてきました。
こうした状況下、システムの効率化を目指したパブリッククラウドの部分的な導入が始まり、大規模な案件をトリガーにクラウド化が加速していきます。これに合わせて発足したのがWEARSREであり、当初はクラウド環境の課題解決を主軸に活動していました。
主要な取り組みとして、膨大なトラフィックを支える画像配信システムの刷新や、APIを含む様々なワークロードの基盤共通化を実施しました。その結果、クラウド環境の大部分は再構築されました。2023年以降はクラウド環境における大規模刷新に一区切りをつけ、整備した基盤を日々改善するフェーズに入っています。
取り残されたオンプレミス環境
クラウド環境の整備が進む一方で、WEARの大部分を占めるオンプレミス環境にはアプローチができていませんでした。ここには、ユーザーデータを保持する基幹DBや主要API、100以上のバッチといったプロダクトの心臓部が稼働しています。クラウド環境に対してWEARSREが取り組む一方、これらの重要な領域は、「クラウド化が完了するまでの間、運用は従来の担当部署が継続する」という役割分担になっていました。
WEARSREがこの領域に関与できていない状況は、「組織的な負荷」と「ハイブリッド環境特有の技術的課題」という2つの構造的な問題を生んでいました。
「組織的な負荷」としては当該部署への業務負荷が常態化していました。これは、あくまで移行完了までの「暫定措置」であったはずの他部署による運用・保守が長期化したことによるものです。また、部署を跨ぐがゆえの詳細なヒアリングや日程調整といったコミュニケーションコストもかかっていました。
一方で「ハイブリッド環境特有の技術的課題」も無視できないほど肥大化していました。これは、WEARのシステム基盤がクラウド・オンプレミス環境間で密接に依存していることに起因しています。オンプレミス側で問題が発生しても、体制上の切り分けによりWEARSRE単独では深部に踏み込めず、解決が難しい場面もありました。
これらの問題に拍車をかけたのは「いずれリプレイスされる」という曖昧な見込みです。いずれはなくなるものという観点からオンプレミス環境の直接的な改善が見送られがちとなり、更に事態を悪化させていました。また、当初は活発だったクラウド化に向けたリプレイスの動きもトーンダウンしており歯止めがかからない状況でした。
今後のサービス成長を鑑みると、前述した課題がボトルネックになるであろうことは明白でした。課題を解決するため、従来の体制の見直しも含めWEARSREがきちんとオンプレミス環境と向き合うことが必須であると考えました。
解決策
オンプレミス環境と向き合うにあたって、解決すべき課題はたくさんありました。段階的に課題解決するため、大きく分けて「オンプレミス環境の現状把握」「WEAR基幹DBの更改」「フォロー体制下での運用・保守の引き継ぎ」の3フェーズで進行しました。
1. オンプレミス環境の現状把握
「オンプレミス環境への関与を深める」と意気込んだものの、当時はその全容が全く見えていない状態でした。開発頻度が低いために有識者は不在で、中には名前すら聞いたことのないシステムも存在します。頼みの綱であるドキュメントも長らく更新されておらず、実態と合致しているか確証が持てない状態でした。
そこで、まずはオンプレミス環境の全体像を正確に把握すべく、以下の3点を中心に調査を開始しました。
- OSのライフサイクルやハードウェア保守期限の洗い出し
- 各システムの仕様、システム間の依存関係の洗い出し
- 各システムの移行計画や開発状況の確認
続いて、これらの情報をもとに、各システムを3つに分類しました。
- 計画的に廃止可能なシステム: 開発チームによる移行計画が進んでおり、将来的に運用が不要となるシステム。短期的にはOS更新や保守延長が必要だが、長期的にはシステム運用そのものの廃止を見込んでいる。
- 廃止方針だが計画未定のシステム: 廃止を検討しているものの、複雑な外部依存により具体的な計画が立てられないシステム。改修頻度が低く利用も縮小傾向にあるため、サーバー台数の最適化やクラウドリフトによる延命を検討する。
- オンプレミス継続を選択したシステム: コスト対効果等の観点から、意図的にオンプレミス維持を判断したシステム。過去にクラウド化を検討した経緯はあるが、移行コスト等を総合的に判断し、現状環境での継続運用を決めている。
分類を進めていくと、従来の廃止ロードマップだけではカバーしきれない複雑な依存関係が見えてきました。そのため、対象システムを持つ各開発チームと綿密な協議を重ねました。その過程で、廃止計画の練り直しや、凍結されていた廃止対応の再始動が進み、具体的なアクションへとつながりました。こうした現場の協力もあり、オンプレミス環境の解像度は向上し、注力すべきポイントが明確に見えてきました。
2. WEAR基幹DB更改への挑戦
「オンプレミス環境の現状把握」の中で浮上した最大の課題は、WEAR基幹DBにおけるSQL ServerのEOLとハードウェア保守期限が同時に迫っていたことです。これにより、ハードウェア刷新を含む大規模なDB更改への対応が急務となりました。
WEAR基幹DBはユーザーデータを保持し、ほぼ全システムが依存する最大規模のミドルウェアであり、オンプレミス保守の中でも最も困難な対応が予想されます。加えて、5年前に実施した前回更改時とは異なり、現在はクラウドとオンプレミスが複雑に依存し合っています。
このようなハイブリッド環境下で、従来の環境ごとの業務分担を維持することには無理がありました。そこで、WEARSREが旗振り役となり、他部署と連携しながら計画から実行までを進める方針をとりました。この決断ができた背景には、オーナーシップを持って推進する我々に対し、専門的な知見が必要な場面で都度フォローしてくれる他部署の心強いバックアップがありました。
ここではDB更改の詳細については割愛しますが、この体制ならではの取り組みを2点紹介します。
1. オンプレミス環境を含めた検証環境の整備
今回のDB更改は、新サーバーへのデータ移行（ダンプ・リストア）を伴うため、当日はWEARをメンテナンスモードにし、切り替え作業と入念な動作検証を経て再開する計画でした。
当初は準備として、DB参照先の切り替え手順確認や、発行クエリの互換性調査を中心に進めていました。クエリの互換性調査ではDMA（Data Migration Assistant）を使用し、一定期間内に発行されたクエリの中から、互換性を満たしていないものを洗い出しました。
DMAを用いたクエリ互換性の検証については以下の記事をご参照ください。
DMAにより修正すべきクエリは特定できましたが、こうした静的な調査だけでは、切り替え後の挙動を完全に保証しきれません。切り戻しが困難な移行であるため、実環境での動作確認が不可欠です。そのため、オンプレミスとクラウドを網羅した検証環境の整備に踏み切りました。
検証環境の構築には、双方のシステムを再現し新DBへ接続する必要があります。クラウド側は比較的スムーズに進みましたが、技術的なハードルが高かったのはオンプレミス環境の再現です。他部署のサポートを仰ぎつつ、ブラックボックス化していた仕様や細かいパラメータ設定を一つひとつ洗い出す地道な作業が続きました。
結果として、サービス全域のリグレッション試験を実施できる環境が完成し、この過程でWEARSRE内にアプリケーションセットアップを自走できるナレッジも蓄積されました。完成した検証環境は、当日の予行演習や構成変更後の負荷試験など、多岐にわたり活用されました。
2. 外部連携APIの無停止による更改
5年前の更改時との大きな違いとして、外部事業者に提供する「WEAR Connect API」の存在がありました。これは、コーディネート画像を中心としたWEARのデータを外部事業者のECサイト等で活用していただくためのAPIです。
通常、DB更改時のダンプ・リストア中は全システムを停止しますが、当該APIの停止は利用企業のECサイト運営に直接影響します。先方の事業影響を最小限に抑えるため、今回は「APIを停止させない」方法を模索しました。
着目したのは、「レプリケーション停止された状態でしばらく稼働し続けるRODB群」です。WEARの基幹DBはSQL Serverのパブリッシャの役割を担うMAINDBと、サブスクライバの役割を担う複数台のRODBで構成されています。更改手順の中には、MAINDBをダンプする前にRODBに向けたレプリケーションを停止する手順が存在します。その後、RODBに変更予定はなく、そのまま廃止される予定でした。これらを有効活用することで無停止を実現できるのではないかと考えました。
結果的には、以下の条件が揃っていたため、RODBを活用した無停止運用が可能だと判断しました。
- API仕様: 外部事業者のECサイト運営で必須なのは「参照系API」のみ。更新系APIは一時停止可能。
- データの一貫性: MAINDBのレプリケーションを停止しても、停止直前までのデータがRODBに残っていればサービス提供に支障はない。
- 非機能要件: MAINDBに比べRODBのスペックは劣るが、API側のキャッシュ機構で負荷を吸収できる見込みがある。
実装としては、クラウド上にnginx TCP Load Balancerを構築し、参照系の通信をRODBへオフロードさせる構成に変更しました。当日は各作業フェーズに応じて、適宜DBの参照先を変更することで、外部事業者に影響を与えることなく更改を終えることができました。
なお、nginx TCP Load Balancerを活用した手法はZOZOTOWNでも採用されています。詳細は以下の記事をご参照ください。
3. フォロー体制下での運用・保守の引き継ぎ
WEAR基幹DB更改後も、約1年間は他部署によるフォロー体制を維持し、実務を通じたナレッジを獲得していきました。現在では以下のような業務をWEARSREだけで完結できるようになっています。
- インフラ管理: ハードウェアの予算策定、見積もり、OS/MWのバージョン管理
- ネットワーク: 開発案件に伴う物理・論理構成の設計
- 障害対応: オンコール対応、復旧指揮、メンテナンス対応
こうした実績の積み重ねにより、フォローアップのための定例会はその役目を終えました。現在は、WEARのオンプレミス環境に関するあらゆる問い合わせや、依頼をWEARSREが一手に引き受けています。
今後の展望
まずは、引き続きWEARSREが主体となりオンプレミスの運用・保守を安定して実施していきます。ここには、アプリケーションやミドルウェアの安定稼働の実現だけでなく、サーバー機器の選定・発注・老朽化対応といったオンプレミス特有の物理的なインフラ管理業務も含まれます。本記事で取り上げた基幹DB更改だけでなく、今後も様々な保守案件を控えています。これらを引き継ぎ後も品質を落とすことなく確実に推進し、プロダクトの安定稼働に貢献します。
次に、新たに迎え入れたオンプレミス環境の解像度を高め、より効果的かつ現実的な解決策を提案できるチームを目指します。当初は、「全てのシステムを新しい言語で書き換え、すべての基盤をクラウド化する」という方針を掲げていました。しかし、その前提を見直すべき時期に来ていると考えています。単一的なクラウド移行に固執するのではなく、コスト、パフォーマンス、移行リスクなどを総合的に鑑み、「プロダクトにとって何が真に最適か」を追求することが重要です。それぞれの環境の強みを最大限に活かしたハイブリッドなアプローチで、WEARのさらなる成長を技術面から牽引していきます。
終わりに
当初はシステムの実態が掴めず、現状把握に多くの時間を要しました。しかし、保守案件を積み重ねるにつれて、他部署からの問い合わせや機能開発で発生するインフラの構成変更を多角的に提案できるようになりました。これはチームとして大きな成長だと実感しています。
また、私個人の学びとしては、システムの刷新を急ぐあまり、オンプレミス環境の現状把握と課題解決が後手に回ってしまった点は反省すべき点です。新旧の環境を切り離して捉えてしまっていましたが、移行期間中もサービスは等しく稼働し続けます。たとえ過渡期の環境であっても、現在進行形でサービスを支えているのはそのシステムです。本件を通じて改めてそのことを実感しました。
本取り組みは、WEARSREだけの力で成し遂げられたものではありません。長年にわたり運用を支え、移行期間中も親身になってフォローしてくださった他部署の皆様に、深く感謝いたします。また、これまではクラウド技術を主軸としてきた私たちにとって、オンプレミス環境への本格的な介入は大きな挑戦でした。それでも、この変化を前向きに受け入れ、未知の領域にもかかわらず積極的に課題に取り組んでくれたWEARSREのメンバーを誇りに思います。
これからもチーム一丸となって、WEARの信頼性向上に努めてまいります。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
