はじめに
先日、Laravel JP Conference 2019に参加してきました。今回は参加したセッションの紹介記事となります。
laravelでパッケージ開発
パッケージ開発のやり方と利点についての発表です。
発表者は後藤知宏(@_mikakane)さん
資料はこちら
パッケージ開発は簡単
パッケージ開発というと難しそうというイメージがあるかもしれませんが、再利用を前提としないでプロジェクト内で使用する前提であれば多くの設定を省略することができ、簡単に開発できるようになっています。
パッケージでできること
通常のLaravelでできることはたいていできます。
- DIコンテナへのモジュールの登録
- artisanコマンドの作成
- ルートの作成
- migration
パッケージ化することのメリット
アプリケーションの特定の機能をパッケージ化して分けると以下のようなメリットがあります。
- 関連するファイルのかたまりをディレクトリにまとめることでappディレクトリがスッキリし、ファイルを探しやすくなる
- 別のシステムで再利用したいと思ったときに切り分けやすくなる
- 名前空間を分けることで別のシステムと統合しようとしたさいにクラス名が被りにくい
パッケージ化する上での注意点
機能を別パッケージとして分ける上でappでしかできないことに注意しましょう。appでしかできないこととしては以下のようなことがあります。
- Exception Handlerの制御
- 読み込むService Providerの制御
- ルートのConfigの制御
- .envの管理
アプリケーションの根本的な制御は、appで行い、各種ロジックはパッケージで行うのが良いでしょう。
Laravelのデプロイ戦略。VPSからDocker、Kubernates、サーバレスまで
デプロイの種類、アンチパターン、Laravelでの注意点や周辺ポイントについての発表です。
発表者は鶴島 剛(@t_tsuru)さん
資料はこちら
理想のデプロイとは
Laravel職人にとっての理想のデプロイとは、例えば以下のような条件があります。
- 開発時に本番環境のことを考えなくて済む
- 運用の負荷を極力減らす
- 急に大きなトラフィックが来ても対応できる
- できるだけ安く
- できるだけ速く
- セキュアなインフラにしたい
- 新しいPHPを使いたい
デプロイの種類
デプロイの種類をざっくり分類すると以下の3種類に別れます。
- 先祖代々続く、サーバへのデプロイ（手順書、SCPでアップロード）
- PaaS（設定ファイルで設定をおこないcliで一発）
- Docker（docker-composeのようにタスクを定義）
1台からスケールできるサービス
あるエンジニアが一人だけのスタートアップで、Laravelを利用してサービスをEC2でリリースしたというシナリオで、問題点とどうすればよかったかを紹介しています。重要なポイントは以下のとおりです。
- 早期にオートスケール対応を見据える
- CI/CDの構築
- クラウドネイティブへの理解
- インフラの見通しをつける
Laravelをオートスケールさせるポイント
1台のサーバで稼働する前提で作らないこと、永続データはすべて切り離せる状態を作ることが重要です。例えば、
- .envやDockerの環境変数を使うなどして設定を分離する
- LaravelのStorageを使ってアップロード先を容易に変更できるようにする
- SessionにはRedisやmemcachedを利用する（AWSならDynamoDBのオンデマンドキャパシティモードがおすすめ）
- Databaseははじめからreadとwriteの設定を使う
- Queuesを使って1msでも早くレスポンスを返す
- デーモン化やQueueで実行するなどして、タスクの失敗を管理する
Laravelで学ぶ、ウェブアプリケーションチューニングの基本
具体的なパフォーマンス改善方法に関する発表です。
発表者は富所 亮(@hanhan1978)さん
資料はこちら
遅いとは
「遅い」は主観であり個人差があるため比較できない。改善のためには、コンテキストや数値を明確化する必要があります。
全体を見る
ウェブアプリケーションは様々な要素で構成されています。まずは、自分の領域の狭さを知る必要があります。
パフォーマンスを科学する
ウェブアプリケーションのレイテンシーはユーザ側/サーバ側のネットワーク、ユーザ側/サーバ側のプロバイダ、光ファイバー等の伝送媒体に分けることができます。例えば大陸間のネットワーク通信のような原因で遅い場合は、ウェブアプリケーションでは改善できないのでCDNなどのソリューションが必要となります。
ウェブアプリケーションが問題なら
ウェブアプリケーション全体のレイテンシーを確認して、ウェブアプリケーション単体の応答時間に原因があるとわかってはじめてチューニングを開始できます。
しかし、ウェブアプリケーション単体のレスポンスが悪かったとしても本当にウェブアプリケーションが悪いとは言い切れません（同一サーバ上の別プロセスがリソースを消費しているケースが有る）
サーバメトリクスを確認する
メモリ使用量、CPU使用率、ディスクIO、ネットワークIOなどの継続的な計測が必要です。この段階では、プロセス単位でのCPU使用率やメモリ使用量などから、どのプロセスがボトルネックになっているのかを特定します。
ウェブアプリケーションの処理を特定する
ウェブサーバのログからレスポンスタイムが遅いURLを探します。
プロファイリングする
コードの実行にどの処理がどのくらい時間がかかっているかを測定します。
改善ループを回す
レイテンシーの中でボトルネックになっている処理をチューニングしていきます。ここではボトルネックの改善→レイテンシーの確認を繰り返しループさせます。
LaravelでのAPI開発を爆速にするためにやっていること
Laravel＋Vue.jsでAPI開発を効率化させる方法の発表です。
発表者は松本 宏太(@kotamats)さん
資料はこちら
フロント、API別リポジトリ化
Vue.jsのコードとLaravelのコードが同一リポジトリに存在する場合、デプロイに時間がかかるためフロントを少し修正した場合でも毎回デプロイに時間がかかっていた。リポジトリを分けることでデプロイが早くなりました。
SPA＋API化する際の注意点
Vue.jsとLaravelのリポジトリを分ける上で、以下のような注意点があります。
- blade下で使っている場合は剥がす必要がある
- もちろんルーティングもLaravelから剥がす
- 認証形式をセッションからトークンベースへ
- laravel-mixは使わない方向で
- デプロイフローを変える必要があるので、インフラに気をつける
APISpecの自動生成
Laravel標準のAPIテストが優秀。拡張してspecファイルを出力するようにした自前のプラグインを使っている。
ServiceProvider, ServiceContainer入門
Laravelの重要な機能であるServiceProviderとDIに関する初学者向けの発表です。
発表者は前田 和人(@chiroruxxxx)さん
資料はこちら
さいごに
Laravel JP Conference 2019の参加レポートでした。どのセッションも面白く、特にパッケージ開発は取り入れていきたいと思いました。
おすすめ書籍
