This post is also available in the following languages. Korean, English

従来のCMSからLandPress ContentにCMSを移行する理由

Healin Yoon2023-08-25

LINE UIT組織でLandPress Contentのバックエンドを開発しています。

LINEでは2年前、従来のヘッドレスCMSの構造とパフォーマンスを改善した新しいヘッドレスCMS、LandPress Contentを社内向けに公開しました。その後、従来のCMSを使用していた多くのLINEサービスがLandPress Contentとして再開発されはじめました。今回の記事では、従来のCMSからヘッドレスCMSに移行する際の注意点や移行後の改善点について紹介します。

ヘッドレスCMS登場の背景

まず、ヘッドレスCMSが登場した背景を見てみましょう。

従来のCMSの問題点

従来のCMSは、下図のようにフロントエンドとバックエンドの組み合わせで一体化されたように動作します。その代表例としてWordPressとMovableTypeがあります。

「フロントエンドとバックエンドの両方を提供するなんて本当に便利ですね！」と思うかもしれません。しかし、サイトを運営する上でこのようなモノリシック（monolithic）構造は以下のような多くの問題を引き起こします。

パフォーマンスとセキュリティ：モノリシック構造は大容量でコンピューティングリソースを多く消費するため、パフォーマンスが低く、最適化が難しいです。また、セキュリティの観点から見ると、攻撃の対象になる露出部分が大きいため、プラグインなどでセキュリティ問題が頻繁に発生します。
開発者経験：フロントエンドとバックエンドの組み合わせが強いため、新しい技術の適用や拡張が難しいです。標準となっている最新のフレームワークを適用することも不可能で、そのためメンテナンス費用も増加します。
ユーザー経験：従来のCMSを使用すると、ユーザーはコンテンツ管理意外にも考えることが多いです。また、不要な機能や構成による問題の管理のため、エネルギーが無駄になることも頻繁にあります。

ヘッドレスCMSとは

このような従来のCMSの問題を補うためにヘッドレスCMSが登場しました。ヘッドレスCMSとは「ヘッド」がないCMSで、この「ヘッド」はフロントエンドのことを意味します。ヘッドレスCMSは、フロントエンドレイヤーがCMSから分離されており、フロントエンドとバックエンドがAPIを介して通信します。

このヘッドレスCMSの構造は、モノリシック構造で発生する多くの問題を解決できます。

パフォーマンスとセキュリティ：フロントエンドとバックエンドが分離されており、はるかに容易にパフォーマンスを最適化でき、セキュリティ問題の予防や対応に効果的です。
開発者経験：プロジェクトや開発者の傾向に合わせて開発プラットフォームや開発言語を自由に選択でき、新しい技術に対応できます。
ユーザー経験：コンテンツ管理者は、コンテンツ管理だけに集中できます。

LINEのヘッドレスCMS、LandPress Contentを開始

LINEでは、LandPress ContentというヘッドレスCMSを独自に開発して社内むけに運営しています。前述のようにヘッドレスCMSにはメリットが多く、従来のCMSでローンチした多くのサービスがLandPress Contentで再開発されており、自然とデータ移行のニーズが発生しました。

昨年、ご覧のLINE EngineeringサイトをWordPressからLandPress Contentに再開発しました。当時、LandPress Contentが提供するAPIを活用してデータを移行しました。それに続き、今年はMovableTypeをLandPress Contentに移行したいという依頼が多く届いています。そこで、「MovableTypeユーザー向けにLandPress Content移行ツールを作成したらどうかな？」と考え、移行ツールの開発を始めました。

従来のCMSからLandPress Contentへの移行

LandPress Contentに移行するツールをどのように開発したか、ステップごとに説明します。

データ構造を把握する

MovableTypeをLandPress Contentに移行するには、まずMovableTypeとLandPress Contentの構造と各構造との違いを理解する必要があります。下図は、MovableTypeとLandPress Contentの構造を簡単に比較したものです。最も著しい違いは、「データ構造が固定されているか、それともデータ構造をユーザーが作るか」です。

MovableTypeの構造

MovableTypeには、Siteの下にArticletとPageという固定コレクションがあります。ArticleとPageは、固定されたフィールドとカスタムフィールドで構成され、それぞれにアイテムを分類するためのCategoryとFolderがあります。理解を助けるために、MovableTypeでArticleとPageコレクションにアイテムを追加する画面を示します。

LandPress Contentの構造

LandPress Contentの構造はどうでしょうか。LandPress Contentは、Projectの下に固定されたコレクションとフィールドがないため、ユーザーに必要なコレクションタイプとフィールドタイプを選択してデータ構造を構成できます。以下は、LandPress Contentコレクションにアイテムを追加する画面です。ユーザーが目的に合わせてコレクションタイプとフィールドタイプを構成してアイテムを追加できます。

ブログ向けのCollectionタイプのコレクションを作成した後、アイテムを追加する画面

FAQ向けののCollectionタイプのコレクションを作成した後、アイテムを追加する画面

メインページ向けのSingleタイプのコレクションを作成した後、アイテムを追加する画面

データマッチング

次は、互いに構造が異なるMovableTypeとLandPress Contentデータをどのようにマッチングしたかについて説明します。従来のMovableTypeデータをLandPress Contentでも便利に使用できるよう、以下のとおりマッチング構造を設計しました。

構造の設計にあたり、以下の点に特に注意を払いました。

MovableTypeのフィールドタイプをLandPress Contentのフィールドタイプに適切にマッチする
MovableTypeのCategoryとFolderをLandPress Content構造に変更する

フィールドタイプ

フィールドタイプは、以下のようにマッチしました。ほとんど直感的に理解できると考え、説明が必要だと判断した部分にのみ説明を追加しました。

MovableTypeフィールド	LandPress Contentフィールド	説明
Editor	Editor
Single-Line Text	Text	MovableTypeのSingle-LineとMulti-Line textはすべてLandPress Content textフィールドでマッチしました。 LandPress Contentのtextフィールドは、最大65,535文字まで入力可能であり、空白または改行などを入力できます。
Multi-Line Text	Text
URL	Text
Date and Time	Date
	Datetime
	Time
Drop Down Menu(select)	Enum(single)	MovableTypeのselectフィールドとradioフィールドは、リストから1つの値を選択できます。 LandPress Contentのenumフィールドは、リストから1つまたは複数を選択するように設定でき、移行する場合は1つを選択するように設定しました。
Radio Buttons(radio)	Enum(single)
Checkbox(checkbox)	Boolean	MovableTypeのCheckboxは「選択する」と「選択しない」に分かれています。Boolean動作と一致するため、LandPress Contentのbooleanフィールドにマッチしました。
Embed Object	Text
Asset(audio, video, image, file)	Media(audio, video, image, file)	MovableTypeのassetは、LandPress ContentのMedia Libraryにマッチングしました。

CategoryとFolder

MovableTypeのCategoryやFolderは、それぞれArticleやPageと関係あるデータです。この関係をLandPress Contentでも維持できるようにLandPress ContentのRelationフィールドを活用して関連付けを行いました。

LandPress ContentのRelationフィールドは、コレクション間の1:1または1:N、N:Mの関係をサポートします。CategoryとArticleはN:M、FolderとPageは1:Nの関連付けとなりました。このように関係を設定すると、CategoryやFolderをArticleやPageから分離して簡単に管理し、便利に使用できます。なかなか素晴らしくないですか。この構成は、LINE Engineeringサイトのブログの本文とタグにも同じく適用されています。

データの抽出

データマッチングを完了したら、次はMovableTypeでデータをどのように抽出するかを考えます。2つの選択肢があります。XMLでデータを抽出することも可能で、MovableTypeのData APIを活用することも可能です。

昨年、LINE EngineeringサイトをWordPressからLandPress Contentに移行した際は、XMLでデータを抽出して移行しましたが、以下のような不便がありました。

特定のデータは、XMLに含まれないことがある
データのサイズによってXMLの抽出に時間がかかりすぎる
一部のサイトのみを選択して移行することが難しい
XMLデータをパーシングするプロセスがあまりにも不便

以上を踏まえ、今度はMovableTypeのAPIを活用して以下の手順でデータを抽出することにしました。

MovableTypeの認証の取得
Siteリストの取得と移行するSiteの選択
Siteからのメディア抽出
MovableTypeのデータ構造の抽出
- Article、Page、Category、Folderのデフォルトフィールドの抽出
- Article、Pageのカスタムフィールドの抽出
アイテムの抽出

データの抽出で発生した2つの問題

しかし、いざデータを抽出しようとしたら、認証問題が発生しました。MovableTypeのバージョンごとにAPI仕様が異なることによる問題でした。これに対応するには、MovableTypeバージョンを選択して移行できるように変更する必要があり、ユーザーが選択したバージョンに応じて異なるMovableType APIのエンドポイントを適用する方法で解決しました。

MovableTypeのバージョン	APIのバージョン	APIのエンドポイント
Movable Type 7 r.53xx	v4.0	http(s)://path/to/mt-data-api.cgi/v4/
Movable Type 7 r.54xx	v5.0	http(s)://path/to/mt-data-api.cgi/v5/

また、ネットワーク問題もありました。LINEはグローバル企業なので、サービスごとにネットワーク環境がことなる場合があるため、MovableTypeからLandPress Contentに直接データを送信することは不可能でした。そのため、ユーザーのPCからデータを移行できるツールを開発しました。

移行ツールの開発

移行は、以下の手順で行います。

MovableType siteの抽出 → LandPress Content projectの作成
MovableType assetの抽出 → LandPress Content media libraryへの移行
MovableTypeのデータ構造を抽出 → LandPress Content collection、field構造の作成
MovableType itemの抽出 → LandPress Content itemへの移行

ここで注意することは、CategoryやFolder、AssetをArticleとPageアイテムより先に移行する必要があるという点です。ArticleとPageアイテムを移行する際、フィールド値をマッチングする必要があるためです。順番をしっかり決めることが重要です。

順番を考慮して移行機能を完成し、ユーザーがCLIで移行ツールを使用できるように機能を追加しました。CLIインターフェースはCommander.jsを活用し、Consolaで案内を表示して移行に必要な情報を入力してもらいます。ユーザーは移行するサイトのリストを選択し、移行の過程を見るだけになります。ほとんど大量のデータを移行するため、CLI-Progressを使って進捗状況を提供しました。

ヘッドレスCMSへの移行後の改善点

ここまで、移行ツールの開発について紹介しました。「機能に大差はないように見えるけど、わざわざ移行する必要があるのかな」と思うかもしれません。では、従来のCMSからLandPress Contentへの移行後はどのような点が改善されたかについて説明します。

パフォーマンスの面

ヘッドレスCMSを使用した後、あらかじめビルドして最適化した静的ウェブページを提供でき、サイトのパフォーマンスが向上されました。また、LandPress Contentは大容量トラフィックも処理できるように開発したプラットフォームであるため、静的データと動的データの両方のリクエストを問題なく処理できます。その結果、必要な部分でのみAPIを活用して動的なデータのリクエストを処理することができ、開発と管理がより便利になります。また、LandPress ContentはCDNを介して世界中どこでも最適なネットワーク通信をサポートするため、サイトを均一で安定的に運営できるようになりました。

セキュリティの面

従来のCMSとは異なって、フロントエンドとバックエンドのレイヤーが分離されており、セキュリティ問題を事前に防ぎ、迅速に対応することが可能です。何よりも、従来のCMSはさまざまな機能を補うためにプラグインを使用する必要がありました。これらのプラグインでセキュリティ問題が発生し、データを安全に管理することが困難でした。

しかし、LandPress Contentに移行したことで、この問題から解放されました。LandPress Contentは、コンテンツ管理に最適化されたさまざまな機能を提供するため、プラグインを使用する必要がありません。また、LandPress Contentが提供するCORS（cross origin resource sharing）や個人情報の暗号化設定、APIリクエスト時に特定のフィールドへの応答を除外する機能などを活用し、より安全にデータを管理できます。

開発者経験の面

従来のCMSはモノリシックでメンテナンスが困難でしたが、ヘッドレスCMSを使用することでフロントエンドとバックエンドが分離され、2つのレイヤー間の混雑による問題が解消されました。また、ヘッドレスCMSはフロントエンドに依存しないため、サイトの変更にも柔軟に対応でき、新機能の追加や新技術への対応にかかるコストを削減できるほか、すべてのフロントエンドフレームワークを利用できるため、プロジェクトに最適なフレームワークを選択することができます。これらのメリットから、現在ReactやVueなどの最新のフロントエンドフレームワークとともに、LandPress Contentを利用するサイトが開発されています。

コンテンツ管理の面

従来は、コンテンツを管理する際、使用もしない機能で複雑になったCMSの管理画面を使用しましたが、これからは直感的なUIでコンテンツ管理にだけ集中できます。また、プロジェクトに応じて最適化されたデータ構造を構成できます。コンテンツタイプによってコレクションタイプとシングルタイプを選択し、モジュール単位でさまざまなタイプのフィールドを自由に追加できます。コンポーネントやフィールドグループを使用することで、繰り返し使用されるデータフィールドの構造を再利用することもできます。

おわりに

ここまで、移行ツールの開発の話とLandPress Contentに移行した後の変化について紹介しました。前述の多くのメリットから、LandPress Contentを使用した多くのプロジェクトがサービス環境でも使用されています。以下は、実際にサービスしているウェブサイトの画面とLandPress Contentの画面です。各プロジェクトの特性やニーズによって構成が異なっていることが分かります。