NagisaWorksでは時折世間を陥れる虚構新聞のシステム全般を担当しております。このシステム、様々な制約により少々ユニークなものになっていますので、今回このシステムについて少しお話をします。

まず制約条件/目標として以下が挙げられます。
1.とにかく低コスト
2.運用が虚構新聞社内のみで行えること
3.でもそこそこに速く
4.web/app両対応

1.とにかく低コスト
虚構新聞はSAKURA internetのサーバー、種別としてはさくらのレンタルサーバーを使用しています。
これは元々使っていたという理由からなのですが、新しいシステムでもそのまま使用することにしています。
ネットワークとしてかかる費用はこれだけのはずですので、とにかく安い。
PVの割にこれほど安いものを使用しているサービスも少ないかと思われます。
まぁケチっているわけでもなさそうなので、インカムの問題でしょうか。

2.運用が虚構新聞社内のみで行えること
運用に回して頂ける費用はありませんので、虚構新聞社内のみで記事をデータ化し、webやアプリに反映して頂かなければなりません。
幸いにして虚構新聞社はとても勤勉なので運用方法を簡素化し、マニュアル化を徹底することで対応していただいております。

3.でもそこそこに速く
先程の通りサーバーはとても安いだけあって貧弱です。
よくあるCMS系のシステムだと、このようなサーバー1台でこのPVをさばくことは難しいです。ですので、動的作成されるページを一切排除し、静的ファイルのみの配信としています。
結果としてサーバーの貧弱度を考えるとかなりのパフォーマンスが出ているかと思われます。広告が遅いのでそう速くは見えないかもしれませんが、記事自体は20〜30msecで出ているかと。少しのお金を足して構成変えれるならもうちょっと快適にできる余地はありそうです。
たまに集中により落ちることはあるのでCDNを使いたいところですが、低コストの関係、また社主が楽しんでいるようにも見えますので、今のところあえてそのあたりの事は行わないことにしています。

4.web/app両対応
虚構新聞はweb（レスポンシブによりpc,mobile対応）、iPhoneアプリ、Androidアプリ（全部まとめてこちらで作成しております）が提供されています。
これら記事の通知なども含め全て運用のみで行えるようにしています。

CMSの構成

コンテンツマネジメントシステム(以下CMS)
サーバーは上記のもの1台のためサーバーでCMSを行うことは出来ませんので、クライアントで動作するCMSを作成し、ワンコマンドで記事から各データの生成、及び差分をサーバーへアップロードという構成を取っています。

ページを見て頂くと、一見最新の記事さえ更新すればよいかと思えますが、
実際には１つの記事が作成されると、記事間のリンク、カテゴリの仕分け、見出し分の分割、アプリ用のデータなど様々なページ/データの更新が必要となります。
ページ用に専用のテンプレートエンジンを、記事自体は専用のテキストフォーマットにて作成して頂いております。

記事のフォーマット出来るだけ書きやすいよう、":"行頭で種別、それ以外は内容といった形にしています。（大昔にこんなフォーマットがあった気がするのですが名称は忘れました）

例）

:serial
2018050701
:group
経済
:genre
産業
:date
2018.05.07
:title
「文字入力の革命」　ボタン１つのキーボード発表
:image
images/key.jpg
:image_width
400
:image_title
ＫＥＹを内蔵したノートパソコン
:content
　ＩＴベンチャーのＪＣＮ研究所は４日、ボタンひとつですべての文字が入力できるキーボード「ＫＥＹ（キー）」を発表した。会場では「タイプライター以来の文字入力革命」をうたうキーを使った実演も行われた。
....

podcastや漫画のインデックス等もCMSで一括処理します。
漫画の画像についてはアプリのみ機械学習により精細化が行われています。

このCMSはデータベースなど使用せず全記事のインデックスをオンメモリで処理しています。
記事数が現在1000件程度、虚構新聞の発行頻度が週に2回程度の頻度を鑑みますと年100件程度の増加、2倍になるまで10年はかかりそうなので十分に耐えうるでしょう。1万記事ぐらいまで来たらデータベースを考えましょう。
webページ自体は静的ファイルによる配信となりますが、ランキングなど動的にならざるをえない部分にはjsを使用しています。

アプリについては、全ての記事のインデックスデータをパッケージングしたものを毎回ダウンロードしています。ちょっと大きそうに思えるのですが、データの最適化・gzipでの圧縮などを行い、60KB程度のデータとなっています。
画像1枚表示するほうが遥かに通信量が多いですね。
リスト関連の通信はこの1回のダウンロードのみです。
記事自体はCMSで作成されたアプリ用の記事のページを表示しています。

新着記事のお知らせ等、アプリの通知においてはFirebaseのCloud Messagingを使用しています。
通知となるとデバイストークンの管理などが必要になるのですが、全てCloud Messagingに任せています。
特性上、記事の更新を全員に出せば良いのでトピック機能を用いて1クエリで全てのデバイスへの通知を行っています。
通知はクライアントからでもよいのですが、フィードバックのアナリティクスを取りたかったのでGoogleAppEngineに設置したwebシステムからCloud Messagingを叩いています。
システム名は「おまかせきょうこさん」です。響子さんではなくこちらのイメージだそうです。

たまに広告などの場所変え等の依頼でテンプレートを変更することはありますが、基本的にメンテナンスフリーで虚構新聞社内のみで日々の発行を行って頂いております。
システム自体はリプレース以来現在までノーメンテナンスで稼働しています。

最後に

システムとしてはほぼ静的サーバーとクライアントでのスクリプトが用意されているだけです。
細かな部分の設計はありますが、システム的にはわざわざこのような場所にて特筆すべきことなど無い、実に単純なものとなっています。
（noteの使い心地サンプルとして用意しただけで、、その感想はまぁ・・後日いびるネタとして観察しておきます）
CMSを考えるとwordpressのようなパッケージング導入＆カスタマイズを考えたり、システム自体を設計/構築する方向となると、webシステム上でのコンテンツ管理システム、データベース、様々なページクエリやリンキングのための動的ページ生成、アプリのためのREST-APIの整備、通知システムのためのトークン送受信システム、そしてクラウドのサーバー構築・管理など、
巷によくあるお話を杓子定規に捉えるとそんな構成要素を考えたりしてしまいます。
そして運用や保守に多くの人的コストをかけたり、その中で技術的解決や向上などを頑張ったりします。
その前に、本当にそんな構成/設計でなければ目的が達成出来ないのでしょうか。
いくら予算があったり人員がいたり努力するといっても、愚策な構成/設計の元では無駄に労力が消費され、往々にしてその分トラブルが増たりなど結果がよくなるわけではありません。
また改善という名目を冠しながら、方向を間違えた努力により難解になり、気がついた時にはもう手の施しようが無くなっている事例もよくあります。
一旦構成/設計を決めると覆すのは難しいので、まず要求と今現在使える技術をよく考慮し、最小限の労力で結果を得る方法を考えましょう。

さて、今回は可能な限りの低コストでどうやるかというアプローチによるところですが、豊富な予算があったりする話だと結果より努力に支払いされることが多いので、うまくバランス取って肉食いに行きましょう。

というお話。