デカップルド・アーキテクチャという聞き慣れない言葉についてお話します。

デカップルド？

デカップルド・アーキテクチャという言葉をご存知でしょうか？

アーキテクチャは「建築」や「（論理）構造」などの意味で一般的にも使われる馴染みのある言葉です。コンピュータ・テクノロジーの分野では後者の意味で使います。

では「デカップルド」とはなんでしょうか？
辞書を調べると「切り離された」「脱共役の」などと出てきます。脱共役と言われても少しわかりにくいですが、とにかく何かと何かが切り離された状態にある、と言っているようです。

「デカップルド・アーキテクチャ」という言葉は、しばしばヘッドレスCMSを説明する場面で使われます。本コラムでも何度か言及していますが、ヘッドレスCMSとは、本来なんの関係もないWEBサイトとCMS本体を、CMS本体のAPIを介して接続し、あたかもひとつのWEBシステムのように稼働させる仕組みです。この仕組のおかげで、CMSの後付や部分的CMS化など、従来のCMSではできなかったことができるようになりました。この関係性が「デカップルド・アーキテクチャ」という概念にぴったり合うのです。

疎結合

昔からシステムの設計において、「密結合より疎結合」ということはずっと言われてきました。部品と部品は密に結合しているよりも、ゆるやか（疎）に結合している方がお互いの依存度が少ないため、メンテナンス性に優れ、改修や使い回しがきくのです。
デカップルドとは、まさにこの「疎結合」を言い換えた言葉でもあります。

スケーリング

WEBシステムにおいても、ユーザの目に触れる表の「WEBサイト」と、裏の仕組みである「CMS」を「デカップルド」の状態にしておくと、のちのちの取り回しが非常に楽になります。特にスケーリングを考えたとき、サーバ構成を「デカップルド」にできることがヘッドレスCMSの最大の強みでもあります。
仮に、

• WEBサイトを格納するWEBサーバ
• POSTEASE を格納するCMSサーバ
• POSTEASE で利用するデータベースを格納するデータベースサーバ

といったように、３台のサーバ構成でWEBサイトを構築したとします。これはまさに「デカップルド」なサーバ構成ですが、アクセス増があったとき、たとえばWEBサーバはスケールアウト（増設）、CMSサーバとデータベースサーバはスケールアップ（増強）といったような、個別対応が可能になります。これはWEBサイトとCMS本体が一体化している従来の動的なCMSではなかなか難しいことです。
さらに POSTEASE は javascript を利用したフロントエンドでの実装も可能ですので、WEBサイトを Amazon S3 のような高SLAが保証された静的ホスティングサーバ上で稼働させることも可能です。週間アクセスが数百万にのぼるような案件でも、POSTEASE のようなヘッドレスCMSであれば簡易なサーバ構成で捌くことが可能になります。

デカップルドとAPI

「デカップルド」と「API」は切っても切り離せない関係です。
お互いに「切り離された」システム同士を結合させるための、一番合理的な仕組みがAPIです。つまりデカップルドな個々のシステムをつなげて、ひとつの大きなシステムとして稼働させる役割を果たすのに、APIは必須なのです。
APIは昔からある技術ですが、近年API革命という言葉が言われるように、APIの需要は非常に高まっています。これからは個々のシステムがAPIを介してつながり、顧客により高いサービスを提供する「APIインテグレーション」の時代になります。
ヘッドレスCMSもまさにその流れの中にあります。

いかがでしたでしょうか。
デカップルド・アーキテクチャはヘッドレスCMSの構造を表す概念そのものでした。
そしてAPIはデカップルド・アーキテクチャを実現するために必須の技術です。

ヘッドレスCMSの先駆けとしてこれからも発展していく POSTEASE にどうぞご期待ください。