Twelve-Factor Appの考え方から、アキッパのプロダクトの課題を考える Part1
アキッパでバックエンドのリードエンジニアをしている村上です。
アキッパのプロダクトはイケてないところが多いんだと、採用やその他色んな場面で自虐する事がありますが、具体的にどこがイケてないのか!?
何か指標となるものと比べてみたいと思いまして、今回は、以下のTwelve-Factor AppというWebアプリケーション等を開発する上での12個のベストプラクティスと、アキッパの現状とを比べてみたいと思います。
いきなり脱線ですが、12っていう数字がかなり好きです。
今回のような記事を何回に分けて書こうかな…とぼんやり考えながら書き始めているのですが、12の約数は1、2、3、4、6、12という豊かなラインアップがあり、これはすなわち、1回 or 2回 or 3回 or 4回 or 6回 or 12回のどれでも分割できるわけですね!なんて柔軟な数字なんでしょう。
このシリーズは何回に分けてやろうかなと考えながら、書いていきます!
(すぐ下の目次で答えが見えてますがw)
I. コードベース
https://12factor.net/ja/codebase
色々書いてるのですが、アプリケーションとGitリポジトリの関係は1対1が原則だよ的な事で、そんなの当たり前では?と思うのですが、以下の違反内容の記述に着目してみます。
アキッパでは、ドライバーさんにお使いいただくフロントサイト、オーナーさんにお使いいただくオーナーサイト、アキッパの運用担当にお使いいただく管理サイト等、複数のWebサイトを運用しています。
リポジトリが分かれているものもあるのですが、今メインで運用しているLaravelフレームワークを採用したリポジトリでは、複数のサイトのプログラムが全て乗っている状態となってしまっています…。
早速Twelve-Factorの考えに違反しちゃっていました。
アキッパの各サイトから参照するデータベースは同じだという事でもあり、LaravelのEloquentモデルはもちろん、その他色々共通して使うプログラムもあるだろうという事で、同じリポジトリで開発をしているのですが、これがTwelve-Factor的にはアンチパターンのようです。
こういう共通処理は、ライブラリという形で切り出しておき、PHPであればComposerとかで指定したバージョンをインストールできるような状態にして共有させるというやり方がよいんですかね。
同じリポジトリにしちゃっている事でのリアルな困り事として、
現在、アキッパでは、ドライバー様向けのプロダクトを開発するチームと、オーナー様向けのプロダクトを開発するチームが分かれているのですが、リポジトリが同じなので、それぞれのリリース時期などを考慮して、メインのブランチへのマージタイミングをどうするかといった事を、チーム横断で状況を確認しながら調整する必要が生じています。
まだエンジニアが10人ぐらいだからなんとかなってる気がしますが、これ以上エンジニアが増えていくと、リポジトリが1つである事がネックでリリーススピードが鈍化していまうという事になりそうだな…という懸念があります。
II. 依存関係
https://12factor.net/ja/dependencies
何言ってるのか難しい日本語ですね。
PHPでいうと、Composerというパッケージ管理システムがあり、Laravelフレームワークを使っていれば、おのずと、必要なライブラリはcomposer.jsonに追記し、composer installでインストールし、vendorディレクトリにパッケージがダウンロードされるようになってますが、要は、こういう仕組みに則り、自分で手動でダウンロードして配置するみたいな事はしないでね!という事かと解釈しました。
これについては、一応アキッパはクリアでしょうか。
(Laravelじゃない古いフレームワークを使ってる古いリポジトリは、その限りではないですが…)
ただ、以下のような記述もありまして、これはどうなんだろう…
ImageMagic的なものは使う事あります。確かに将来的に使えない状況になる可能性はあると思いますが…
アプリケーションに組み込むってどういう事…?
ま、いっか。アキッパのプロダクトは考えないといけない事が他にたくさんあるんで、深追いするのはやめとこう笑
III. 設定
https://12factor.net/ja/config
これはわかりやすい話しなので、特に解説不要でしょう。
Laravelであれば、プロジェクト直下にある.envに、環境に応じて変わる設定を記述しています。
アキッパでは、環境毎の.envの内容を特定のディレクトリに配置していて、デプロイの際に、その環境に応じたファイルをプロジェクト直下の.envにリネームして配置するといった事をしています。
これも一応アキッパはクリアしてるかと思います。
IV. バックエンドサービス
https://12factor.net/ja/backing-services
上記の例で言うと、データベース、キャッシュについては、エンドポイントを設定ファイルで切り替えるだけで、アプリケーションのコードを修正する必要はないようになっていますが、他はどうでしょう…。
例えば、アキッパでは、メール送信はSendGridを、ストレージではAmazon S3を主に用いていますが、これを別の手段に変えた場合には、アプリケーションの修正が必要になってくるようにはなってしまっています。
今のアキッパで採用しているLaravelのデザインパターンは以前以下でご紹介しましたが、
SendGridだとかAmazon S3だとかの技術詳細と、ビジネスロジックは切り離しているので、この技術詳細が差し替わっても、基本的にはビジネスロジック側の修正は不要になっています。
なので、一応ギリギリOKかな…という事にしておこう。
振り返り
12個あるベストプラクティスのうち、とりあえず4個を確認してみました。
ざっと振り返ると…
コードベース
複数アプリケーションを同一リポジトリで開発しているのでNG
依存関係
Laravel(というかComposer)を利用しているのでOK
設定
Laravelの.envによる設定変更を利用しているのでOK
バックエンドサービス
データベース、キャッシュサーバはOK
メール送信、ストレージ等は、レイヤードアーキテクチャーにより許容範囲なのでOKという事にしておこう
今回見た4つのベストプラクティスと比較したら、複数アプリケーションを同一リポジトリで運用するアンチパターンを踏んでしまっているという事がわかりました。
これは、すぐに改善する事が難しい問題なので、なかなか痛い問題です…。
数年前に、Laravelでアキッパをリニューアルするぜっていうときに、このTwelve-Factor Appの考え方を知っていれば、あそこはこうしたのに…っていうのが結構あります。
これからWebサービスを構築しようとされる方は、是非ご一読を!
今回書ききれなかった他のベストプラクティスもあるんで、次回も「Twelve-Factor Appの考え方から、アキッパのプロダクトの課題を考える」シリーズを書きたいと思います。
この記事が気に入ったらサポートをしてみませんか?