このすみノート

Webエンジニアが技術や趣味を書くブログです。

esa.ioの育て方の講演を観れなかったので、スライドから内容を紐解いてみる

はてなブックマークを見ていたら、とても気になるスライドがありました。

esa.ioの育て方 // Speaker Deck

「現地で直接見たかった!」と思えるくらい、興味深いスライドでした。

残念ながら既にイベントは終了してしまったようですが、スライドだけでも色々と得られそうな点がありましたので、ブログにまとめてみます。

esa.ioとは?

まず初めに「esa.io」について簡単に紹介します。

esaは「情報を育てる」という視点で作られた
自律的なチームのためのドキュメント共有サービスです。

esa.io

私なりの言葉でコンセプトを表現してみるならば「情報を育てるためのツールです。マークダウンによる気軽な情報発信と、ボトムアップからの情報発信により、組織の活性化を実現します」となります。

私のように、普段からマークダウンでブログを書いているようなユーザにとっては、かなり相性が良いサービスであることは間違いありません。

サービス規模によって選択する適材適所のインフラ構成

スライドの前半でまず印象に残ったのは、インフラ構成です。

  • サービス稼働当初は、Herokuでサーバを立ち上げることによって、インフラの手間を極限まで削減し、サービス開発に注力する
  • サービスが成長してきた段階で、ユーザ数と今後の拡大予測に見合ったインフラ(AWS)へと載せ替える

インフラは最初にしっかりと組んでしまい、その後は不変であると思われがちですが、AWSも、RDSやElastiCacheなど複数のサービスを組み合わせると、コストが無視できないレベルに増えてきます。

ユーザ数に見合った最適なインフラの実現は、コスト面でもインフラに割くリソース面でも、参考になりそうです。

サブシステムにSinatraを採用している

個人的に気になったのは、esaの本体ではないサブシステム(UMLコンテナ、決済コンテナ)に、Sinatraを採用しているところです。

Railsはもちろん素晴らしいフレームワークですが、シンプルな機能のシステムには、個人的にはRailsは冗長であると思うのです。Sinatra + RubyGemsライブラリの組み合わせでも、十分にWebシステムを開発することはできます。

私的には、アーキテクチャにおいてマイクロサービスが流行したように、今後は、マイクロフレームワークとライブラリを組み合わせるスタイルの開発が、主流になっていくのではないかと予想しています。

マイクロフレームワークのほうが、動作が早かったり、身動きが取りやすかったり、適材適所にライブラリを選べるといった利点は、往々にしてあります。

システム規模に合わせたフレームワーク選定が出来ているという点は、ぜひ見習いたいです。

カテゴリ機能の経路列挙モデル

私が思う「経路列挙モデル」の利点は、DBのテーブル構成、および問い合わせクエリのSQLがシンプルになるところです。

  • DBのインデックス機能を活用しにくい
  • 経路上流の変更に弱い(上位カテゴリほど多くのレコードに登場するので、変更レコード数が多くなる)

・・・のようなデメリットは考えられますが、カテゴリが爆発的に増えることは考えにくいので、シンプルな構成を選択したということでしょうか?

経路列挙モデルを採用した理由がスライドには書いてなかったので、ここは現地で見たかったです!

f:id:konosumi:20180227015511j:plain

外部公開機能

外部公開機能で注目すべき点は、静的ファイルを「S3 + CloudFront」で配信することで、完全に本体から切り離している点です。

URLを知っていればアクセスできるという静的コンテンツであり、プログラムによるユーザ認証が不要であるというメリットを活かした、賢い構成です。

認証を独自で実装しない

認証システムにGoogle OAuthを採用することで、ログイン周りの開発コストを節約しています。

認証周りよりも、サービスの本質的な部分の開発に多く時間をあてたほうが、特に開発初期の段階では幸せになれそうです。私も個人サービスは開発したいと考えているので、その際には参考にさせていただきます。

スピード感のある開発体制

ユーザからフィードバックを受け取って、30分後には修正版をリリースすることを目指すという開発体制は、簡単に真似できるものではありません。

「開発スケジュールもノルマもない」という点においては、スケジューリングや統制管理をする時間があったら、その時間もクリエイティブな活動(開発)にあてたほうが良いという意味で解釈しました。

ユーザ志向の発想が根付いていれば、無理にスケジュールを切らなくても、自然と早く良いモノを出したいという欲求が生まれるわけですね。

さいごに

もしかしたら、今回のスライドに私が心を惹かれてしまった理由は、サービスの運営から開発・インフラまで、全てを見ることができるそのフルスタック力にあるのかもしれません。

少し大げさな表現かもしれませんが、人月の神話に書いてありそうな「1000人の開発者よりも10人のスーパーエンジニア」である組織とは、こういう組織のことを言うのかもしれませんね。とても参考になるスライドでした。

次回がもしあれば、ぜひとも現地で聞きたいので、まずはesaのtwitterをフォローすることから始めることにします。