K8s 上で laravel を 快適に 運用する方法 尾山貴康 　2023年9月27日 (水) 1

氏名　 ： 部署　 ： 自己紹介 尾山 貴康 2 ● コロプラ（8年目） ● 日々の業務 ○ 社内ライブラリのメンテ ○ OSSへのコントリビュート ○ コンテナのチューニング 技術基盤本部 第3バックエンドエンジニア部 サーバー基盤グループ PEチーム

基盤開発チームではゲーム開発側に極力ゲームのロジックに 集中してもらえるように様々なをサポートしています ● 大規模なトラフィックに耐えられる設計の検証と実装 ● 共通処理や便利機能などのライブラリー化 ● バージョンアップのフォロー ● 共通コンテナや Kubernetes 設定の整備 3

目次 4 ● Kubernetes で使用しているPHPコンテナの紹介 ● アプリに入れている Kubernetes 向けの工夫

社内専用のPHPコンテナ ● Alpine Linux ベースのコンテナにゲーム開発に必要なものを詰め込んだもの ● プロジェクト側ではこのイメージをベースに固有のものをいれていく ● 簡単に拡張したり調整できるような工夫が入っている ● そのなかでも特徴的なものを5つ紹介 5

自社コンテナの特徴１ ● docker-php-ext-install の pecl 版 ● pecl install の代わりにこれを使う ● pecl install との違い ○ インストールオプションが渡せる ■ redis の --enable-redis-igbinary など ○ バイナリのデバッグシンボルを strip する ■ grpc などは 140MB → 7MB docker-php-pecl-install というスクリプトの追加 6

自社コンテナの特徴２ PHP の設定ファイル (.ini) の一部を環境変数で指定可能にしている opcache.validate_timestamps=${PHP_OPCACHE_VALIDATE_TIMESTAMP} FROM colopl/php:latest AS local-build ENV PHP_OPCACHE_VALIDATE_TIMESTAMP=on ローカルでは validate_timestamps を on それ以外は off など簡単に切り替え可能 opcache.ini Dockerfile 7 余談）PHP 8.3 からはデフォルトフォールバックも使えるらしい opcache.validate_timestamps=${PHP_OPCACHE_VALIDATE_TIMESTAMP:-off}

自社コンテナの特徴 3 ● ENTRYPOINT に docker-entrypoint.sh を登録する ● /etc/entrypoint.d というパスにある スクリプトを上から順番に実行するスクリプト ● ENTRYPOINT を上書きせずに処理を追加できるので便利 ● nginx のオフィシャルコンテナのを参考にした ※ K8s の preStop 時に同じことをする docker-exitpoint.sh も配置しています entrypoint.d によるマルチステップな起動 8

自社コンテナの特徴 4 ● ヘルスチェック系 ● メトリクス系 Kubernetes で必要なエンドポイントを追加している 9

自社コンテナの特徴 4 ヘルスチェック系 /var/www/readyz.php if (@file_exists('/run/nginx.health') === false) { header('HTTP/1.1 404 Not Found'); } touch /run/nginx.health /etc/entrypoint.d/99-ready.sh 10 ● livez ● readyz readyz の仕組み

● 以下をデフォルトで提供 ○ nginx ○ php-fpm / opcache / apcu 自社コンテナの特徴 4 メトリクス系 11

● メトリクス取得フロー ○ /metrics を叩く ○ /var/www/metrics/all.php が実行される ○ /var/www/metrics 配下の php ファイルが include される ● 独自のメトリクスを追加したかったら /var/www/metrics に php ファイルを追加するだけでOK 自社コンテナの特徴 4 メトリクスも拡張可能 12

自社コンテナの特徴 5 13 Supervisor を使って複数のプロセスを管理 ● アプリの役割に応じて 起動したいものを /etc/supervisor.d に追加 ● デフォルトでは nginx / php-fpm を起動 ● G社的にはアンチパターンらしい1 ● Docker 社は推奨している2 ● G社の言いたいことはわかるが 利便性＆パフォーマンス優先 1. https://cloud.google.com/architecture/best-practices-for-building-containers#package_a_single_app_per_container 2. https://docs.docker.com/config/containers/multi-service_container

アプリ側に入れている工夫 1 Server Roles ● バックエンドアプリの役割は API への Request 処理だけではない ○ キューの処理 / バッチ処理 / 管理ツール など ● 同じコードをデプロイするが役割によって起動するものが違う ○ キューワーカー → php artisan queue:work ○ バッチ処理 → supercronic (cron) 14

Server Roles ● 弊社では役割を環境変数に定義しコンテナ内で区別できるようにしている ○ ROLES=[cron,queue] ● 具体的には各役割毎に K8s の Deployment 定義を分けている ○ app, queue, cron, tool, etc... ● Deployment に ROLES を定義してコンテナに渡す アプリ側に入れている工夫 1 15

Server Roles 活用例 ● Role が cron の時だけ supercronic を supervisor に登録 ● Role が queue の時だけ artisan queue:work を supervisor に登録 ● Role が tool の時だけ管理ツール用の route を出力 アプリ側に入れている工夫 1 16

アプリ側に入れている工夫 2 app:prepare コマンド 17 使い方 ● entrypoint.d に app:prepare を呼び出すスクリプトを追加しておく ● プロジェクト側でApplicationPreparing にフックして起動時に実行したい 処理を追加する container 起動時に app:prepare というコマンドが実行される app:prepare コマンドとは？ ● ApplicationPreparing というイベントを発行するだけのコマンド

アプリ側に入れている工夫 2 app:prepare コマンド 18 ApplicationPreparing イベントで行っていることの一例 ● Twemproxy (sidecar) の疎通待ち ● Cloud Spanner のコネクションプールの初期化 ※ app:shutdown もある

19 Fin