ku-sukeのブログ

Just another hatena blog

microserviceはしんどそうだけど、2層くらいはいいよ

今年携わっているクライアントのシステムを2層化するように進めているんだけど、けっこうアリだなと思うようになってきたので書き留めてみる。

 

■2層システムとは

最近microserviceが話題になってるんですが、役割ごとに多数分割するのではなく、MVCでいうところのMとVCの2つに分割する感じです。

 

図を後で書く

 

■2層システムのそれぞれの役割

バックエンド(データレイヤーとか呼んでる)は、業務要件に適したモデルをJSON APIで提供します。出力だけじゃなく会員登録や各種CRUDができるようにします。

 

逆に、フロント側は原則データベースを持たず、REST APIを用いてウェブアプリケーションを構築します。場合によっては1画面複数APIを叩くので、適宜キャッシュや非同期処理ができるといいですね。

 

■2層システムに分ける意義、幸せなこと

・システムの寿命というかライフサイクルが違う

 一般的にプレゼンテーション層というのは、自社のビジネスではなく世の中の進化に左右されがちです。やれGoogleアルゴリズムを変えたとか、スマホの比率が急に増えたとか、AppIndexingでWebと同じ内容をアプリでも提供した方がいいとか、アドテクなどマーケ系システムのJSと連携したりとかです。

 

その反面、サービスがひと通り立ち上がったあとのビジネスロジック層というのは、それほど頻繁に変わらないし、変わる場合も自社の年間や四半期の経営計画に沿っておちついて計画できます。

 

それらのライフサイクルというところで分断することで、たとえば表側はNodeJSなどスクリプト言語の軽量なものでかき、長期間コードベースを維持するくらいならさくっと捨てて書きなおしたりしつつ、バックエンドはとにかくパフォーマンスと可用性を重視して、GoやJava/Scalaなどで書くといった具合の技術の選定がしっくりきやすいと個人的に感じています。

 

また、フロント側にデータベースを持たせなければ、サーバのセキュリティ要件をやや緩和しやすくなるきがしますし、バックエンド側をオンプレに置いてhttpsポートだけ開けて、フロントはGAEなどクラウド化するというのもやりやすそうですね。


・業務知識レベルに応じた分業がしやすい

もうひとつ、ある程度の規模のウェブアプリケーションとなると、人の入れ替わりでブラックボックス化しやすいという問題があります。ドキュメントをメンテしたとしても巨大で、外注さんに来てもらってもなれるまで時間がかかったりします。

 

そこで、業務知識も必要なビジネスロジック部分は、ある程度なれた人間を中心に構成し、ミスのないように設計実装をします。そうして出来上がったAPIをドキュメントも含めパッケージングすることで、歴の浅い人や外注さんがプレゼンテーション側を担当し「そこだけ見れば良い」という状況をある程度作り出すことが可能になります。

 

もちろんマイクロサービス的な保守コストの増加というのは少しはあるのですが、それを上回るメリットがあると感じていますし、APIのバージョニングを用いることで、/v1/は2016年までメンテ、/v2/は2017年までということが計画しやすくなります。

TVなどなかなかアップデートされない機器向けに提供する場合を想定し(/v12-lts/のような)5年間の維持を約束するバージョンも提供してもいいかもですね。

 

微妙に、API化するほどじゃないけど、フロント側にデータベース持たせたくないなぁとかいう要件がちらほら出てくるので、当然ながら銀の弾丸ではないのですが、すでにあるていどビジネスが立ち上がっているウェブアプリケーションには結構おすすめだなと思いました。