はじめに

こんにちは、hacomono で SRE リーダーをしているありかわです。

今年の2月頭に SteamDeck 有機EL 版を手に入れてたくさんのゲームを買ったものの、最近はインテリアの3Dパース作成に沼ってしまいゲームは全くの手つかず状態になっています。

もし興味のある方は「homestyler」というサービスを使えば、初心者でもびっくりするくらい高性能な3Dパースを作れて、細かい部分にも手が届くのでオススメです。

話はそれましたが、今回は2022年の12月に入社してからずっと携わっているマルチテナント移行について書いていきたいと思います。

TL;DR

マルチテナントのアーキテクチャは構築できたけど既存顧客はシングルテナントに残ってるよ
2023年の1年間でたくさん移行したよ
- Service count = 顧客数（= VPC, RDS）
- Instance count = EC2
補足）マルチテナント環境で稼働中の顧客は1300社ほどあるので、全体の80％近くはマルチテナントで運用している
シングルテナントは顧客毎にインフラ構成が異なるから移行が辛いよ
まだまだ続くよ、これからも

この記事で書くこと

hacomono におけるマルチテナント移行の背景
マルチテナント移行するにあたっての課題と対策
現在の状況と今後の課題

この記事で書かないこと

マルチテナント移行で利用した技術要素の具体的な利用方法やハマりポイント

マルチテナント化の現状

多くの企業が直面している大きな課題の一つに、シングルテナント環境からマルチテナント環境への移行があります。

すでに hacomono を新規で利用される顧客に関しては、マルチテナント環境上で稼働することになっており、安定的な運用を実現しております。
hacomono のシングルテナントやマルチテナントのアーキテクチャに関して、詳しくは hacomono の VPoPE であるやじまの記事をご一読ください。 techblog.hacomono.jp

新規で利用される顧客はマルチテナントで稼働する状態にはなったのですが、すでにシングルテナントでサービスを提供している顧客は依然として残っているため、既存顧客のマルチテナント移行の必要性が出てきました。

マルチテナント移行の背景にある動機

1. サービス安定性の向上

シングルテナント環境では、安定しないアーキテクチャや、構築時期による顧客毎の環境の差異により、様々な要因がきっかけでサービスダウンが発生しやすい状況となっています。

2. 運用効率の向上

サービスがダウンして障害対応するものの、環境の差異によって調査する内容、対応する内容が異なることが多く時間を取られています。
また、デプロイ自体も安定しないことがあり、多くの時間をかけてデプロイ対応するような重労働作業になっているのが実情となります。

3. インフラコストの削減

2023年の初頭、hacomono は冒頭で紹介したように1800近くの EC2 インスタンスとそれに関わる RDS やその他のサービスをシングルテナントで運用しており、このインフラコストの圧迫が次のイノベーションへの阻害要因となっています。

4. 技術的モチベーションの向上

古いアーキテクチャに基づいたシングルテナント環境は、エンジニアのモチベーションを下げる一因にもなっているため、マルチテナント環境への移行は、新しい技術へのアップデートを意味し、モチベーション向上にも繋がると考えています。

直面した課題とその対処法

1. 顧客環境の多様性

シングルテナントで稼働している顧客はそれぞれ異なるインフラ構成となっており、この問題が移行プロセスを複雑にさせています。
この多様性に対応するため、まずはどのようなパターンが存在するのかの洗い出しと、それに対する実現可否の検証が必要不可欠でした。

調査の結果、一例ではありますが下記のような構成パターンが存在していました。

本番環境・検証環境
冗長構成あり・なし
カスタムドメインあり・なし
BIあり・なし
個別要件によるカスタマイズ
- 独自のAPIやバッチの実装
- 外部連携
- セキュリティ要件
- etc…

このような様々な構成パターンにおいてもマルチテナント移行を実施するために、移行による全ての手順を GitHub Actions のワークフローによる自動化で実現しました。
現状は以下のようなワークフローになっています。

これとは別に、前日に実施する準備用のワークフロー、移行後に問題が生じた際に切り戻しをするワークフロー、移行に利用したリソースのお掃除をするワークフローに関してもすべて自動化を実現しています。

2. DMSを利用した大規模なデータ移行

DMS を利用した何百社ものデータ移行は新たな挑戦であり、リソースの上限に達しないか、どの程度並列で実行が可能か、メンテナンス時間をどの程度設ければよいか、失敗した場合のリカバリーはどうするか等、検討することがたくさんありました。

DMS を利用した移行の構成図としては下記のようにとてもシンプルなのですが、本番稼働中のサービス影響を少なくすることを最優先事項として慎重に進める必要がありました。

1つ目の対策としては「段階的な移行」です。

プレ移行は検証環境のみ
1次移行は本番環境から数社のみ
2次移行は単純な構成のみ
etc…

上記のようにリスクを管理しながら、各フェーズでの学びを次のステップに活かすため、マルチテナント移行が比較的実施しやすい顧客からスタートし、複数のフェーズに分けて移行しました。
各フェーズ毎に KPT で振り返って、次のアクションを決めるサイクルがとてもうまく回りました。

2つ目の対策としては「事前準備と移行検証の徹底」です。

移行対象と同等な本番構成の環境を構築して移行検証を実施
移行対象をスプレッドシートで管理して GitHubActions のワークフローのコマンドも自動生成し、一括実行を容易に
当日の手順書も整備しダブルチェックを容易に

上記のような流れで進めることで、事前にAWSのリソース上限に引っかかるものを検知し申請できたり、移行にかかる時間、ダウンタイムが発生する時間を予測することができました。

例）移行対象の管理と当日の手順書とタイムスケジュール

今後のマルチテナント移行

これまでの段階的な移行により、移行フローの品質や速度がその度に改良され、また移行後のマルチテナント環境でのサービス運用も問題なく実現できております。
今後はより大きな顧客も移行対象として推進していき、2024年度中には「個別要件により独自にカスタマイズした顧客を除く環境」はマルチテナント環境へ移行したいと考えています。

まだ先にはなるのですが、個別要件により独自にカスタマイズした顧客環境をマルチテナント環境に移行するには、早い段階から調査やヒアリングを通して下記のような点を各社毎に洗い出して進めていく必要があります。