リリースしたばかりの最新WEBサービスの使用技術ついてご紹介したいと思います(最新ではありますが最先端技術ではありません)。
サービス
スカウトミー
https://scoutme.biz
ITエンジニア専門のスカウト転職サービスです。
求人票の掲載も人材紹介も一切なく、登録エンジニアは採用企業自らが直接送るスカウトメールをひたすら待ちます。
※今は転職を考えていないという人も登録可能ですので、自分の価値を確かめる為にも是非!
開発チーム構成
- エンジニア:1名
- デザイナー:1名
- ディレクター兼デザインアドバイザー:1名
開発期間
2017年2月にキックオフし、9月現在、スタート時の機能は一通り実装終えました。特に残業をしたり無理をするようなことはありませんでしたので、開発実期間は8ヶ月程度といったところです。
採用技術
- 典型的なLAMP
- nginx(画像サーバ兼リバースプロキシ)
- Apache + mod_php
- PHP
- FuelPHP
- PHPUnit
- MySQL
- HTML5/CSS3(1カラムレスポンシブ)
- Bootstrap
- Sass(Gruntコンパイル)
- Font Awesome
- jQuery
- Handlebars(一部クライアントサイドレンダリングに使用)
- さくらのクラウド1台
- バックアップ用VPSサーバ(さくら/カゴヤ)
- シェルデプロイ
- vim + screen
- git
- 監視(シェル/さくら)
- 外部サービス
- PAY.JP
- Twilio
以上、非SPAなサーバレンダリングWEBサービスです。
上から順に説明していきたいと思います。
WEBサーバ
長年、使い慣れているApacheだけにしたかったのですが、サムネイル処理を含めた画像サーバはnginxがもはやスタンダードという事で、nginxをリバースプロキシにして、Apacheはアプリケーションサーバとして無理やり残して、ました。この構成で2年ほど別サービスを運用して来ましたが特に問題は起きていません。
PHP
TogetterがPHP7に移行した記事を見て2016年4月頃に検証したのですが、当時、こちらの環境ではsession_regenerate_id()が正しく動作しなかったため採用を見送り、そのままPHP5.6系で現在に至りました(もう直ってる?)。
Togetter PHP7移行
https://togetter.com/li/954428
書いたプログラムのステップ数は、2017年9月現在1.9万行。
$ find {fuel/app/classes/,fuel/app/views/,fuel/app/tasks} -type f | xargs wc -l
19110 合計
FuelPHP
別サービスで2年ほど運用実績があったので、そのままフレームワークとして採用しました。バージョン1.8を使用。
ただし、素のFuelPHPには問題が多かった為、パッチを5~10機能分あてています(セキュリティの関係上、こちらでは公表できません)。
(追記)はてブでコメントありましたがissueには報告済です。
また、FuelPHPの柔軟性を最大限活かしつつ、Ruby on RailsのアセットパイプラインやMailer Class、そして独自の思想を取り入れて改造しています。
テストは、PHPUnitを使用しています。ミッションクリティカルなインターフェイスのINPUT/OUTPUTを中心に書いています。
MySQL
WEBサーバと同一ホストで稼動させています。レプリケーションはしていません。なお、バックアップはWEB/DBデータ共にフルスナップショットをカゴヤ(大阪)とさくら(東京)のVPSサーバに分散させています。
勿論、S3でもいいのですが、既に長年バックアップサーバとして稼動しているVPSがあった為、そのまま使用した次第です。
テーブル数は現在マスターを除いて26個。これから運用していく中で増えていくとは思うのですが、まずは中小規模システムといったところ。
HTML5/CSS3
開発効率を重視し、1カラムレイアウトのレスポンシブにしています。PC/スマホ/タブレットでほぼ出し分け処理なく済ませています。
Bootstrap
もはや説明不要のフレームワーク。あらゆるプロジェクトで重宝しています。
Sass
特別な事はしていませんが、色はテーマカラーをリリースまでに何度も変更する可能性がある為、必ず設定ファイル化するよう心掛けました。コンパイルは最初に覚えたGruntをずっと使っています。
Font Awesome
Bootstrap標準WEBフォントglyphiconは使用しないので、無駄にダウンロードされないよう設定しました。
ちなみにサイト内の画像は、イメージ写真3枚とロゴのみ。一昔前のようにアイコン職人さんがいなくてもプログラマだけでほぼ全ての開発が出来る、いい時代になりました。
jQuery + Handlebars
開発スピードを追求して、サーバサイドレンダリング + JQueryでUIは作りました。いくつかの場所ではサーバサイドではなくHandlebarsでクライアントレンダリングしています。
RESTful Web API
将来的にもスマホアプリを提供する予定はなく、また、元々開発スピードを最重視したため、RESTful Web API化はしていません。ただし、POST処理は「戻るボタン問題」に辟易としていたので、ここ5年ぐらいは開発するサービスを全てajax経由としjson API化しています。従って、万が一、マイクロサービス化することになっても比較的容易に移行できるようになっています。
さくらのクラウド
以下が採用理由です。
- 過去、安定性の追求と、やっぱり新規サービスということで気合をこめてさくらの専用サーバでリリースしたことがあったのですが、結果的に閑古鳥が鳴いてしまい無駄な投資となってしまった(と言っても、さくらの専用サーバは初期費用約10万円/月額約1万円~とリーズナブルなのですが)。
- AWSは、データ転送料従量課金がやっぱり及び腰に。
- さくらのクラウドは、既に別サービスで2年ほど運用実績があり、安定もしていたので無問題で採用。データ転送は100Mbps共有回線ですが、増強や占有化も簡単に出来たはずです( http://cloud.sakura.ad.jp/specification/network/ )
デプロイ
シェルスクリプトで運用しています。
スタートアップの最小最速デプロイツール
https://qiita.com/uratch/items/c72b25d54ad92024e28d
開発環境
vim + screenで、ctrl / model / view とか名前付けして開発しています(10年以上、変わっていません。)
git
バージョン管理はgitです。DBサーバ同様にスナップショットを2拠点にバックアップしています。
監視
- 別サーバから簡単なシェルスクリプト(http)
- さくらのクラウド無料監視(ping)
外部サービス
クレジットカード決済
PAY.JP を採用しました。実運用はこれからですが少なくとも導入実装は非常に簡単でした。
携帯電話番号認証
Twillio APIを採用しました。こちらもシンプルで簡単でした。
以上、スカウトミーの使用技術の裏側となります。
それではスカウトミーをよろしくお願いします!