MIXI DEVELOPERS NOTE
♻️

XFLAG ID基盤のモダン化とMIXI IDへの移行

2024/08/01に公開

はじめに

開発本部MIXI M事業部の@k-asmです。

2024年4月18日に、モンスターストライクのプレイデータバックアップに利用していた「XFLAG ID」の新規登録を停止し、新たに「MIXI ID」の新規登録が始まる旨のアナウンスがありました。

https://www.monster-strike.com/news/20240418_7.html

XFLAG IDとは、モンスターストライクのバックアップやモンストTICKETなど、MIXIのサービスを利用する際に利用されていた共通ID基盤です。XFLAG IDの機能開発は2018年を境に止まっており、必要最低限の開発をしながら運用している状態でした。

この度MIXI M事業部では、XFLAG IDの開発・運用基盤のモダン化を行いました。それに続けて、XFLAG IDから、新しい全社的なID基盤であるMIXI IDへの漸進的な移行を進めました。

XFLAG ID基盤のモダン化

XFLAG IDがどのような状態だったか

先述した通り、XFLAG IDは2018年から開発が約6年間止まっている状態でした。そのため、基盤のモダン化作業が始まった際は以下のような環境で動作していました。

  • アプリケーション
    • Elixir 1.6.6
      • 2018年当時から更新されていない状態
    • Erlang OTP 21.0
      • 2018年当時から更新されていない状態
    • 依存ライブラリは開発が止まってからほぼ更新されていない状態
  • AWSインフラ基盤
    • アプリケーションはAmazon Linux 1のEC2インスタンスで動作
    • ELBは全てClassic Load Balancer
    • 本番環境と開発環境で共通のVPCを利用
  • CI/CD
    • EC2インスタンス上のJenkinsを利用
    • デプロイは踏み台サーバからCapistranoを利用
  • 構成管理
    • Ansible, miam, piculet, Terraformなど複数のツールを組み合わせて管理

XFLAG ID基盤のモダン化後

モダン化後のXFLAG ID基盤及びMIXI IDの開発・運用はMIXI M開発チームで行う座組になっています。MIXI M開発チーム内での運用負荷・学習コストを減らすため、モダン化後の構成は、MIXI MおよびMIXI IDとほぼ同じにしました。

  • アプリケーション
    • Elixir 1.16
      • モダン化環境リリース時の最新バージョン
    • Erlang OTP 26.2
      • モダン化環境リリース時の最新バージョン
    • 依存ライブラリはすべて最新バージョンまでアップデート
  • AWSインフラ基盤
    • アプリケーションは全てコンテナ化を行い、ECS on Fargateで管理
      • 作業用インスタンスを除いてEC2インスタンスを全て撤廃
      • OSはAmazon Linux 2023にアップデート
    • ELBは全てApplication Load Balancerに統一
      • Classic Load Balancerを全て撤廃
    • VPCを本番環境と開発環境で分離
  • CI/CD
    • CodePipeline及びGithub Actionsを利用
      • Jenkinsは撤廃
  • 構成管理
    • 新環境の構成管理はCDK(CloudFormation)で行う
      • 従来利用していたAnsible, miam, piculet, Terraformは撤廃

今回のモダン化は開発基盤・運用基盤を共に大きく刷新するものでしたが、基本的に「アプリケーションサーバのバージョンアップ」という形を取り、データストア周りに変更は入れませんでした。後述しますが、これによって環境切り替え作業をノーメンテナンスで行うことができました。データストアは、モダン化前から引き続いて、Amazon RDS for MariaDBを利用しています。

モダン化の影響調査

モダン化に伴って、Elixirのバージョンを1.6から1.16へ、Erlang OTPのバージョンを21系から26系へ、と大幅に刷新しました。これに伴い依存するライブラリのバージョンも大きく上がり、一部のライブラリは置き換えが必要となりました。

代表的なものを以下に記載します。

  • Phoenix Frameworkのアップデート
    • コードマイグレーションが必要となるため、changelogに記載されたupgrade instructionsに従って作業する
  • Ecto 3.x へのアップデートに伴う変更
    • utc_datetimeという型がマイクロ秒精度から秒精度に変更された
    • @timestamp_optsのオプション値が変更された
    • Ecto.Changeseterrorsフィールドにconstraintの結果が入ってくるようになった、 etc
  • DBConnection 2.x へのアップデートに伴う変更
    • コネクションプール管理に利用しているライブラリがpoolboyから内製に変更されたことで、設定値の後方互換性が失われた
  • mariaexからMyXQLへの移行
    • mariaexは6年ほど更新が止まっているため、継続的に更新が行われているMyXQLに移行
  • HTTPotionからHTTPoisonへの移行
    • HTTPotionはdeprecatedとなっているため、MIXI Mで利用しているHTTPoisonに移行

他、バージョンが上がる依存ライブラリは全て影響調査を行いました。Elixirのライブラリはsemantic versioningを採用していることが多く、またchangelogを記載する文化が根付いているため、それほど大きい工数をかけることなく調査できました。

XFLAG IDのコード規模はそれほど大きくなく、テストがよく書かれていたことも影響調査に役立ちました。

モダン化の作業手順

モダン化後の環境説明の項目で少し言及しましたが、今回の環境モダン化ではデータストア周りの変更は入れておらず、アプリケーション動作の面でも新旧環境で差分が無いように調整しました。

そのため、新しい環境と古い環境が混在して動作していてもサービス的には問題なく、DNS変更による環境切り替え作業をノーメンテナンスで行うことができました。

モダン化作業は以下のように進めました。

  1. 現在動いている環境とは独立したモダン化用の新環境を構築し、モダン化したアプリケーションをデプロイする
  2. 開発環境のDNSを新環境の方を向くように切り替える
  3. 開発環境でQAを行い、モダン化に伴うデグレーションがないことを確認する
  4. 本番環境のDNSを新環境の方を向くように切り替える
  5. 旧環境のトラフィックがほぼゼロになったことを確認して、旧環境のインスタンスを停止する

DNSキャッシュの影響で旧環境のトラフィックが完全にゼロになることはないため、旧環境はトラフィックが極小になったことを確認した後、日時を定めて停止しました。

XFLAG IDからMIXI IDへの移行

MIXI IDは2024年4月よりスタートした、MIXIの新たな全社的なID基盤です。MIXI IDのサービス開始に伴い、今までXFLAG IDを利用していたサービスは全てMIXI IDでも利用できるように対応が行われました。

方針

XFLAG IDを利用しているサービスは多岐に渡っているため、MIXI ID移行は「漸進的に」進める方針となりました。XFLAG IDの新規登録は停止しますが、既存のXFLAG IDは今まで通り利用できます。

また、MIXI ID移行に伴い、サービス側でのAPI変更や接続先の変更は行わない方針としました。サービス側からはユーザーがXFLAG IDを利用しているかMIXI IDを利用しているか意識することはありません。今まで通りAPIを利用することで、透過的にMIXI IDを利用できるようにしました。

MIXI IDの利用フローについて

XFLAG ID利用サービス側から見た、XFLAG IDとMIXI IDの利用フローを以下に示します。

XFLAG IDを利用する場合

まず、従来通りXFLAG IDを利用する時のフローです。

XFLAG ID利用フロー

XFLAG ID利用サービスは認可リクエストを生成し、ユーザーのブラウザ上でXFLAG IDのWeb画面を表示させます。ユーザーはXFLAG IDで認証した後に、XFLAG ID利用サービスがXFLAG ID基盤のリソースを利用する旨の認可をします。

認可することで取得できた認可コードをXFLAG IDのTokenエンドポイントにリクエストすることで、XFLAG IDのアクセストークンを取得します。このアクセストークンを利用してAPIリクエストを行います。

MIXI IDを利用する場合

次にMIXI IDを利用する時のフローです。一部簡略化して示しています。

MIXI ID利用フロー

ユーザーのブラウザ上でXFLAG IDの認可リクエストを行い、Web画面を表示させるところまでは同じです。ユーザーがMIXI IDで認証する旨を選択すると、MIXI IDの認可リクエストが生成され、リダイレクトします。

ユーザーのブラウザにはMIXI IDのユーザー認証画面が表示されるため、ユーザーはMIXI IDで認証し、XFLAG ID利用サービスが、MIXI ID基盤及びXFLAG ID基盤のリソースを利用する旨の認可をします。

認可することで認可コード等のパラメータを取得できます。このパラメータ群をXFLAG IDのTokenエンドポイントにリクエストすると、XFLAG IDのTokenエンドポイントはプロキシ的に動作し、MIXI IDのTokenエンドポイントにパラメータを受け渡します。

MIXI IDのTokenエンドポイントからはアクセストークンと共にIDトークンを返却します。IDトークンを検証し、問題ないならばXFLAG IDの新規作成、もしくは作成済みのXFLAG IDを取得し、MIXI IDと紐付けます。

このように、MIXI IDで認証しても内部的にXFLAG IDを生成することで、後方互換性を担保しています。

XFLAG IDのTokenエンドポイントはアクセストークンを返却し、このアクセストークンを使ってAPIリクエストを行います。

おわりに

関係各所に多大なご協力をいただき、スムーズおよび迅速に、環境のモダン化及びMIXI IDの導入ができました。

MIXI IDを導入するための開発を進める前に、XFLAG ID環境のモダン化を行ったことで、開発・テスト・デプロイの工程を迅速に回すことができ、開発工数を削減できました。

また、XFLAG ID環境の構成を、すでに運用しているMIXI M環境の構成と合わせることで、運用工数の削減にも繋がっていると感じます。

MIXI IDは今後全社的なID基盤として開発を続け、利用を広げていく予定です。

MIXI DEVELOPERS NOTE
MIXI DEVELOPERS NOTE

Discussion