LIVESENSE ENGINEER BLOG

リブセンスエンジニアの活動や注目していることを発信しています

その時基盤が動いた 〜オンプレ オフィス移転で死す〜

これは Livesense Advent Calendar 2022 DAY 21 の記事です。

リブセンス インフラエンジニアのsheep_san_whiteです。お酒とロードバイクが大好きなおじさんです。

さて、リブセンスでは今年3月にオフィス移転を行いました。 オフィス移転に伴い開発環境のAWS移行など大きめのイベントがあったので、年を跨ぐ前に記事にします。

移行前の開発環境について

実はリブセンスでは、開発環境が長らくオフィスフロアの小部屋(以降マシン室と記載)に設置されていました。 本番環境でリプレースした際に余ったサーバを持ち帰り、将来的な本番環境の基盤検証も兼ねてOpenStackを構築し運用していました。

移転直前だと稼働中の物理サーバ42台、OpenStackインスタンス212台規模の開発環境が存在していました。 物理サーバの移設、もしくはAWSなど他の基盤への移行・物理サーバの廃棄が必要となるので、オフィス移転が発表された直後は大騒ぎになりました。

余談ですが、初期の開発環境はオフィスフロア内のマシン室に大型の家庭用エアコンを設置した簡素な開発環境でした。 年々開発環境の台数が増え、マシン室の室温が上昇してきたことで空調のパワーが足りず、ドアを開け放ってサーバを冷却していたのですが、ある日突然エアコンから水が垂れて大騒ぎになったことがあるのも今ではいい(?)思い出です。

※事件後に業務用エアコンを導入したことで、しっかり冷却されるようになりました。

AWS移行を見越して事前にやっておいたこと

インフラグループでは2020年初頭に3ヶ年計画でAWS移行のロードマップを策定して以来、たびたび軌道修正しながら着々とAWS移行を進めてきました。

そのなかでマッハバイトの本番環境をAWS移行する際、オンプレとの接続が必要なことを見越してTransitGateWayで以下の環境を相互に接続してありました。

  • オンプレミス本番環境とマッハバイトAWS本番環境アカウント
  • オンプレミス開発環境とマッハバイトAWS開発環境アカウント

幸いなことに接続が完了したのが2021年09月だったので、突然オフィス移転がアナウンスされても開発環境のAWS移行をスムーズに行うことができました。

AWS移行までの流れ

それではAWS移行の流れを時系列を追って書いていきます。

2021年11月24日 ボスの不穏な発言と謎の頭出し

突然ボスが「休める時は休んでおくように」と言い始め、週次ミーティングで「詳しくは明後日以降で話すよ」と謎の頭出しをしました。 参考までに当時の週次ミーティングのスクリーンショットを掲載しますが、この時点でだいぶ不穏です。怖いですね。

ボスからの謎の頭出し

2021年11月25日 全社月次ミーティングでオフィス移転が発表される

週次ミーティングの翌日行われた全社月次ミーティング中、オフィス移転が発表され「あれ?これオフィスの開発環境どうするの?」とSlackでざわつき始めました。 この時点の発表で、オフィス移転まで数ヶ月と期間が短いので地獄になることがわかります。

ざわつくSlackチャンネル その1

ざわつくSlackチャンネル その2

2021年11月29日 インフラグループ内で移行プランを検討する

移行プランについてインフラグループ内で話し合ったところ、以下の案が上がりました。

  • 案1 本番オンプレ環境にラックを増設して開発環境を移設する
  • 案2 移転先のオフィスに移設する
  • 案3 APサーバなど軽めのものをAWS移行、リソースをたくさん使うDBなどはオンプレ本番環境に移設する
  • 案4 AWSに移行する

結論から書くと、タイトルに有る通り「案4 AWSに移行する」を選択しました。 「将来のマッハバイトのAWS移行の準備も兼ねられる」というメリットが一番大きく、ただのオフィス移転に伴うAWS移行ではなく技術的な投資であるため採用しました。

また、マッハバイトの開発環境では下記複数の環境が存在しており、全て移行するとコストと工数が跳ね上がるためステージング環境のみに移行対象を絞ることとなりました。

  • ステージング環境(リリース前の検証環境)
  • 長期検証・プレビュー環境
  • バージョンアップ検証環境
  • サブシステムを絞った一時的なプレビュー環境

各移行案の詳細は以下に記載します。

案1 本番オンプレ環境にラックを増設して開発環境を移設する
  • Pros
    • ベストケース(楽観的なケース)であれば、物理的な引っ越しだけで作業が完了できる
  • Cons
    • コスト
      • ラックの追加契約によりコストが増加する
      • 開発環境のサーバは古いものなので、故障交換のコストが高くなる可能性がある
      • ほぼフルリモート体制になった時にメンバーが必ずしも対応できる保証はない
    • リードタイム
      • ラックの契約にかかる時間が必要で、作業着手が遅れる
      • 既に稼働しているサーバー群を持っていく形のため、事前に準備ができない
      • 引っ越し〜全てのセットアップが終わって復旧するまで、開発環境が消滅する
      • ノートラブルで引っ越しできたとして、3日。妥当なところでは1週間、長ければもっと長期に渡って停止すると思って良い
        • 言い換えるなら、1週間の停止を飲めるならお金だけの問題で引っ越しできる
    • 運用コストの先送り
      • やがて大きなトラブルを引いたりバージョンアップが必須になったときに、大きな工数を必要とする原因となりうる
案2 移転先のオフィスに移設する
  • Pros
    • 案2と同じく開発環境をまるごと移設するので、ベストケース(楽観的なケース)であれば、物理的な引っ越しだけで作業が完了できる
  • Cons
    • 試算したところ、想定より予算感が高めになった
    • ネットワーク周りが読めない
    • リードタイムが読めない
案3 APサーバなど軽めのものをAWS移行、リソースをたくさん使うDBなどはオンプレ本番環境に移設する
  • Pros
    • AWSだけに比べると金額が安くなる
    • オンプレミス・開発環境の仕組み等をそのまま流用できる
  • Cons
    • リソースが足りるか不明
案4 AWSに移行する

オンプレ開発環境のサーバを全てAWSに移行する案です。 この中でも、オンプレ開発環境を主に利用しているのはインフラグループとマッハバイトだったため、どちらが管理するAWSアカウントに移行するかも議論されました。

案4-A インフラグループ管理のAWS開発環境に移行する

  • 概要
    • インフラグループ管理のAWS開発環境に移行する
  • Pros
    • マッハバイト側との調整/マッハバイト側に依頼するレビューが少なくて済む
    • マッハバイト側の環境は綺麗なまま保たれるため、キレイな引っ越しに備えられる
  • Cons
    • TransitGateWayが設定されていないので、孤立する / 設定が必要

案4-B マッハバイト AWS開発環境に移行する

  • Pros
    • TransitGateWayが設定されている
      • 現状マッハバイトのステージング環境とオフィス環境は通信できるようにしているので、マッハバイト以外の環境だとマッハバイトとの接続を確立する必要がある
    • 将来のマッハバイトのAWS移行の準備も兼ねられる
  • Cons
    • マッハバイトの将来のAWS本番環境の構成と全く別の開発環境として構築されてしまう

2021年12月02日 AWSソリューションアーキテクトからAWS Application Migration Service(MGN)というソリューションを共有される

ベターなプランは「AWS移行である」との見解で一致したものの、レガシーなものが色々あるので不安が拭えない状況です。 AWSに移行できるのか判断できないので、オンプレミスと同様のプロビジョニングが行えるか検証することになりました。

いざ検証を始めてみたものの、早速AWSにAMIが公開されていないものに引っかかりました。ツラい。OSバージョンを上げてしまうのは、本番環境との差異を考えると割けたい解決方法です。

そこでソリューションアーキテクトに良いソリューションが無いか相談したところ、以下の回答が得られました。

OSがサポートされていればAWS Application Migration Service(MGN)がお使い頂けるかもです。

https://aws.amazon.com/jp/application-migration-service/

サポートOSはこちらです。

https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html

移行の対象イメージからVMを起動し、MGNのエージェントをインストールする感じになるかと思います。

このAWS MGNを元に、オンプレのOSベースイメージ作成を検証することにしました。

MGNでのOSベースイメージ作成について

MGNでEC2上にOSベースイメージを作成する際、以下の作業が必要となります。

  1. マイグレーション実行用のIAMユーザ作成
  2. 対象OSへのエージェントインストール
  3. マイグレーションの実行
  4. オンプレのOSベースイメージでEC2インスタンスが起動する

今回は上記を実行した後、EC2インスタンスからAMIを作成しました。 OSレイヤはAnsibleで構成管理していますが、このAMIを作って初めてプロビジョニングの準備が整います。

これで移行がなんとかなりそうなことが分かりました。

MGNで作成したOSベースイメージ利用でのハマりどころ

  • OSバージョンとインスタンスタイプの組み合わせによっては、Nitro世代のインスタンスで起動できないことがありました
    • これは拡張ネットワーキングの対応可否によるもので、パッケージの依存関係解消が難しかったため一部Nitro世代インスタンスタイプでの起動を見送りました
  • MGNエージェントでのマイグレーション実行時、OSによって処理が中断してしまうことがありました
    • kernel系パッケージをバージョンアップすることにより回避できました
      • 幸いなことに本番環境で稼働実績のあるバージョンに上げるだけで済んだのですが、環境によってはMGNでも厳しいパターンがあるかもしれないです

2021年12月〜2022年2月 サーバのプロビジョニングを繰り返し、修正する日々

MGNでオンプレのサーバと同等のOSベースイメージが作れるようになった後は、ひたすら用途別にEC2インスタンスを作成し、Ansibleによるプロビジョニングを適用・修正する日々でした。 ネットワーク周りで多少の修正が必要ではあったものの、オンプレ同様のサーバを一通り構築することが可能になりました。

序盤は上手くいかない物が多くツラかったのですが、ある程度流れができてくるとあとはAnsible playbookの適用を進めるだけなので、後半は気持ちが楽になりました。

また、Livesense Advent Calendar 2022 DAY 7の記事で紹介された s3get もこの中で生まれたものです。 古いOSとOpenSSLを使い続けるのはツラすぎます。

made.livesense.co.jp

ちなみに、この時点でいきなりマネージドサービスへ切り替えることは開発環境と本番環境で差分が発生してしまい統制上問題があるためリフトをメインで進めました。

2022年03月08日 オンプレ開発環境データベースからAWS開発環境へのデータ移行完了

日々本番環境のデータベースから個人情報をマスキングし、開発環境で参照するためのデータを生成していますが、開発環境にしか無いデータというものが存在します。 そのため、この日を停止点とし開発環境データベースで最終ダンプファイルを取得・AWS側にリストアしました。

この時点で、オンプレ開発環境のAPからAWS開発環境のDBを参照するハイブリッド構成となっています。

2022年03月10日 開発環境 AWS移行完了

APサーバのDNSをオンプレ開発環境からAWS開発環境へ切り替えて、無事AWS移行を完了しました。

2022年04月11日 オンプレ開発環境の撤去

AWS開発環境に移行が完了したものの、物理サーバやネットワーク機器はまだオフィスのマシン室に存在したため、撤去を行いました。 当日はインフラグループに限らず、他部署から多数の応援が来てくださり、みんなで撤去作業を行いました。

サーバ撤去の様子

余談ですが、普段地方に住んでいるインフラグループのメンバーも駆けつけてくれました。 作業後にピッツァとワインで打ち上げをしましたが、久しぶりにじっくり対面で話せてとても楽しい会でした。

撤去後のサーバたち

終わりに

今回はインフラグループ観点で本記事を書きましたが、AWS移行・開発環境撤去についてはマッハバイトの方やバックオフィスの方など様々な方にご協力いただきました。

この場を借りてお礼を申し上げます。ありがとうございました。


リブセンスでは2022年12月現在、マッハバイトの本番環境をAWS移行する準備が着々と進んでいます。

主なものを挙げると、以下のものがあります。

  • サブシステムのAWS移行
  • データベースをAWS移行する際に障害となりうる実装の廃止
  • データストアの改修
  • レガシー基盤のコンテナ化

オフィス移転に際し、ただの開発環境移行ではなくマッハバイトのAWS移行への投資を行なったことが功を奏し、着実に前進したことが感じられる1年でした。

2022年下半期で準備を進めていた大きめの移行がいくつか残っているので、来年もまたみんなで美味しいお酒が飲めるよう頑張っていきたいです。