今から購入を伴うメディアサイトを作るとしたら、どんなアーキテクチャを採用するか

> **NOTE** 思考実験なので想像に過ぎないが、より良いアイデアをお持ちの方は、ぜひご教授ください。

 

想像してみる。

 

今はだれもがスマホを持っていて、SNSを読み、バズった記事にアクセスが殺到する。

死にゆくサービスも多くある一方で、生き残ったサービスはその場しのぎに書いた負債の利子の返済に苦しめられる。

RDBのスケールアップの限界と戦う。

 

これからもスマホをはじめとしたデバイスからの通信量は増え続けるだろう。

そんな今の時代、購入を伴うメディアサイトを立てるとしたら、どんな構成を採用すべきか?

 

> 購入を伴うとは、ここでは求人への応募や賃貸の内見応募、ECでの商品購入、定期購読料の契約、飲食店の予約などの、サイトの収益の源となる行動のこととする。

> つまりいわゆるニュースサイトのような広告収益モデルではないメディアサイトの話。

 

## やりたきこと

スパイクアクセスに耐えられること。

言語の流行り廃りに耐えられること。

開発速度を保ち続けられること。

 

## Wordpressはどうだろう?

この記事を書きはじめてすぐは、自前で全部書くならどんな構成にするか?としか考えられていなかったが、そういえばWordpressというものがあったなと思いついたので考えてみる。

ここではWordpressを取り扱うが、実際にはメディアサイトの雛形となるいろいろなパッケージ全般が考慮対象だろう。

 

### スパイクアクセスに耐えられるか?

ググったらあっさり出てきた。

https://engineer.blog.lancers.jp/2017/03/awswordpressのスケールアウト/

AWS上で動かすためにいろいろ引っぺがしたら良いらしい。なるほどー。

 

http://xn--o9j0bk9rwb2ftig7dzeb2881pquxd.com/rentalserver/post-512/

こんなのもあるらしい。これだけベンダー依存するのはちょっと心配な気はする。

 

### 言語の流行り廃りに耐えられるか?

PHPくらい枯れた言語とWordpressみたいな古株パッケージなら、バージョンアップをサボらなければしばらくはなんとかなりそうに思える。

機能が増え過ぎて、もうこれWordpressっていうより半分以上自前のPHPサイトだよ、ってなった時、それでもバージョンアップに耐えられるコードを書く必要はありそうだが、それはどの言語でも必要なコストだ。

あるとすれば、Wordpressとそれ以外のコードを疎結合にして別々にバージョンアップできるようにしておいた方がよい気がする。

たとえばコンバージョンにからむ部分はWordpressとは別のサブドメインやURLに切り出しておけば良さそう。

あるいはログイン機構は別に持って、他のサービスが認証基盤にアクセスしに行く、とか。

 

### 開発速度を保ち続けられるか?

正直まだPHPを書いた経験が少ないのでなんとも言えない。

…が、PHPはテンプレートエンジンとして作られたのだし、今は型システムやパッケージマネージャーもあって立派な言語になったけど、あんまり巨大なシステムを書くのにマッチする言語ではないような気はする。

が、単なる経験不足と好みを孕んでる確信があるので、何で書くかはあまり大事じゃないんだろう。

探せばJavaRubyのメディアサイトのパッケージだってあるだろうし。

 

## 自前

こっちは最初に、自分ならどうするだろうかと考えた方の選択肢だ。

 

とはいえ上で考えたことでだいたい話は終わってしまう。

 

メディア部分も自分で書いて、言語が廃れても逃げ出せるように小さいサブシステムに保つ。

必要ならRDB以外も検討する。

 

### 管理画面をどうするか

ここまで考えて思いついたのだが、Wordpressにはセットで付いていた管理画面はどうしようか。

別に我々は必ずセットにする必要などないので、別システムに持っておいても問題ないが…

 

ここでDBを共有してしまってはサブシステムを小さく保ちたいのに変に結合してしまう。

ここは、メディアサイト本体にAPIを用意して、管理者の認証認可とAPIをキックするだけの管理サイトを用意するのはどうだろう。

それなら、外に公開するサイトには特定のURLを404で返すように設定しておいて、内部向けに用意した1つのインスタンスだけはすべてのURLを公開するようにしてサブシステム間の結合を疎に保てそうだ。

こうしておけばDBを1つのサブシステムで占有できるし、サブシステムを小さく保てるから保守も書き換えもやりやすそうだ。

 

関心ごとが違うサブシステムを適切に疎結合にするならば、ログインが必要ならそのまわりも外に出せるし、お金を扱うのも外に出せる。

 

ただし各サービスを別々に互いのエラーに寛容に作らねばならないのは、開発スピードをある程度落としそうだ。

未来に抱え込む負債を減らせるなら、そのコストは充分ペイすると思うが…どうなんだろう。

 

結局は想像だ。