Symfony 7.4 のリリースは、PHP 開発者にとって、特に私たちが高性能でクラウドネイティブなアプリケーションを構築している人々にとって重要な瞬間です。Changelog は、通常の開発者体験 (DX)の改善とパフォーマンスの改良に包まれていますが、一つの機能はインフラストラクチャチームとバックエンドのためのゲーム変革として顕著です。 . Share Directory 長年にわたり、我々は複数のサーバー環境で「キャッシュ・ディレマ」と戦ってきた。我々はハッキング・スクリプトを書き、複雑なNFS マウントを管理し、パフォーマンスの罰金を受け入れ、すべてアプリケーションの状態を同期させました。 このアーティストでは、新しい ディレクトリ、解決する重要な問題を理解し、Symfony 7.4、Doctrine、Flysystemを使用して強力で生産準備の構成を実装します。 var/share The “Cache Dilemma”: A History of Performance Bottlenecks(「キャッシュ・ディルマ」:パフォーマンス・ボトルネックの歴史) シェアディレクトリのエレガンスを評価するには、まず過去の痛みを再確認しなければなりません。 ディレクトリは歴史的に、非常に異なる2種類のデータのダンピング地となっています。 var/cache 
 
 
 System Cache: This includes the compiled service container, URL matching routes, optimized Twig templates and class maps. This data is immutable (or should be) after the cache:warmup phase. It is specific to the version of the code currently running. これらのデータは、現在実行中のコードのバージョンに特有です。 アプリケーションキャッシュ:これには、Cache.app プール、API 応答、シリアル化されたオブジェクト、および潜在的に一時的なファイルストレージが含まれます。このデータは波動的で共有されます。 クラスターにおける問題 Symfony アプリを 10 個の Pods を持つ Kubernetes クラスターにデプロイしていると想像してください。 
 
 
 Scenario A (Local Cache):You keep var/cache local to each pod.Result: The System Cache is fast (local SSD). However, the Application Cache is fragmented. If a user hits Pod 1, their data is cached there. If their next request hits Pod 2, the cache is missed and the database is hit again. データの一貫性は失われます。 シナリオ B (Shared Storage):You mount var/cache to a shared volume (NFS, EFS).Result: The Application Cache is consistent across all pods. Great! But now, every time Symfony needs to load a class or check a route (System Cache), it has to cross the network to read from the shared storage. This introduces significant I/O latency, often slowing down response times by 10–20% simply due to file system overhead. シンフォニーがクラスをロードしたり、ルートをチェックしたりするたびに、共有ストレージから読むためにネットワークを横断する必要があります。 わたしたち は 間 で 選択 し まし た。 そして . consistency performance Share Directory (var/share) を入力する Symfony 7.4 では、この問題を解決するための専用の建築コンセプトを導入しています。 . Share Directory この機能は、アプリケーションで共有されたファイルからシステム特有のファイルの位置を正式に切り離します。 
 
 
 var/cache: システムキャッシュのホームとして残ります. それはサーバーのローカルに留まります(K8sの定義におけるエフェミラルストレージ)。 var/share: This directory is designed to be mounted on shared storage (like NFS, AWS EFS, or a persistent volume). このディレクトリは、共有ストレージ(NFS、AWS EFS、または持続的なボリュームなど)にマウントされるように設計されています。 この分離により、両方の世界のベストを手に入れることができます:燃え上がる速さ、ローカルシステムキャッシュと一貫した共有アプリケーションの状態。 実施ガイド 私たちはSymfony 7.4アプリケーションを構築し、Share Directoryを3つの一般的な使用ケースに活用します。 
 
 
 
 シェアアプリケーションCache 共有ファイルストレージ(アップロード) Shared SQLite Database (for simple state) (シンプルな状態のための) 前提条件と設置 PHP 8.2 以上を実行しており、Symfony CLI がインストールされていることを確認してください。 symfony new my_app --webapp
cd my_app
composer require symfony/framework-bundle:^7.4
 基本構成 新しいSymfony 7.4のインストールでは、フレームワークはすでにこのコンセプトを知っています。 file. You will see a new environment variable. 次の環境変数が表示されます。 .env # .env
APP_SHARE_DIR=$APP_PROJECT_DIR/var/share
 ハウッドの下、The class now implements a 既存のアプリケーションをアップグレードしている場合は、これを手動で追加するか、デフォルトのフォールバック(バックバック互換性のためのキャッシュディレクトリを指す)に頼る必要があります。 Kernel getShareDir() この構造をアップグレードされたアプリで実行するには、アップデート 必要に応じて、または単に環境変数を定義します。 Kernel.php Shared Cache Poolsの設定 最もすぐれた勝利は、アプリケーションキャッシュを共有ディレクトリに移動することです. デフォルトでは、Symfonyのファイルシステムキャッシュアダプタは、 私たちはこれを移すために、 . var/cache/pools var/share/pools オープン . We will configure the default app cache to use the new パラメータ config/packages/cache.yaml %kernel.share_dir% # config/packages/cache.yaml
framework:
    cache:
        # distinct_id helps avoid collisions if multiple apps share the same storage
        prefix_seed: 'my_app_%env(APP_ENV)%'

        # Default app cache
        app: cache.adapter.filesystem

        # System cache (stays in var/cache, FAST!)
        system: cache.adapter.system 

        # Configure filesystem adapter to use the share directory
        default_redis_provider: 'redis://localhost'
        
        pools:
            # We explicitly tell the 'cache.app' pool to use the share directory
            cache.app:
                adapter: cache.adapter.filesystem
                provider: ~
                # The 'directory' option is available for the filesystem adapter
                # We use the new container parameter
                default_lifetime: 3600
                provider: 'cache.default_marshaller' 
                
services:
    # We need to configure the specific directory for the filesystem adapter
    # Since we can't easily pass the directory in the simplified YAML above for the main adapter,
    # we can define a custom adapter or rely on the global default if Symfony 7.4 automates it.
    
    # However, for explicit control, let's define a shared pool:
    cache.adapter.shared_filesystem:
        parent: 'cache.adapter.filesystem'
        tags: ['cache.pool']
        arguments:
            $directory: '%kernel.share_dir%/pools'

framework:
    cache:
        app: cache.adapter.shared_filesystem
 標準の Symfony 7.4 では、デフォルトのファイルシステム アダプタがまだデフォルトで動作する場合があります。 サービスを明示的に作成することによって、 指摘する 私たちは、当社のアプリケーションキャッシュが正しい場所に保存されていることを確認します。 cache_dir cache.adapter.shared_filesystem %kernel.share_dir%/pools これを確認するには、キャッシュをクリアして加熱してください。 php bin/console cache:clear
php bin/console cache:pool:clear cache.app
 次に、いくつかのキャッシュエントリを生成します(例えば、ページを訪問することによって)。 ls -la var/share/pools
 キャッシュ アダプタによって作成されたフォルダ構造を見る必要があります。 Flysystemとの共有ファイルストレージ クラスター内のユーザーアップロードの処理は、共有ストレージのための古典的な用例です。 ストレージアダプターをマップする . league/flysystem-bundle var/share/storage Installation: composer require league/flysystem-bundle
 オープン . Configuration: config/packages/flysystem.yaml # config/packages/flysystem.yaml
flysystem:
    storages:
        default.storage:
            adapter: 'local'
            options:
                # Use the new kernel parameter
                directory: '%kernel.share_dir%/storage'
 今、このストレージを使用してファイルアップロードを処理するサービスを作成しましょう。 依存症の注射 PHP 8 Attributes namespace App\Service;

use League\Flysystem\FilesystemOperator;
use Symfony\Component\DependencyInjection\Attribute\Target;
use Symfony\Component\HttpFoundation\File\UploadedFile;

class FileManager
{
    public function __construct(
        #[Target('default.storage')]
        private readonly FilesystemOperator $storage
    ) {}

    public function uploadUserFile(UploadedFile $file, string $userId): string
    {
        $filename = sprintf('%s/%s.%s', $userId, uniqid(), $file->guessExtension());

        $stream = fopen($file->getPathname(), 'r');
        
        // Write to var/share/storage/...
        $this->storage->writeStream($filename, $stream);

        if (is_resource($stream)) {
            fclose($stream);
        }

        return $filename;
    }
    
    public function getFileContent(string $filename): string
    {
        return $this->storage->read($filename);
    }
}
 これを Kubernetes にデプロイすると、持続的なボリューム要求(PVC)を配置します。 Pod A がファイルをアップロードする場合、それは PVC に書き込まれ、Pod B はそのファイルを同じパスですぐに読み取ることができます。 /app/var/share Shared SQLite Database (The “Lite” Cluster) (シェアされたSQLiteデータベース) 通常、重い同時書き込みには推奨されていませんが、SQLite を使用して 読み取りが重く、書き込みが低いデータ、または完全なMySQL/PostgreSQL設定なしで展開を継続する必要がある単純な内部ツールボードのための素晴らしいパターンです。 var/share オープン . Configuration: config/packages/doctrine.yaml doctrine:
    dbal:
        # Use the standard SQLite driver
        driver: 'pdo_sqlite'
        # Point the path to the share directory
        path: '%kernel.share_dir%/db/app.sqlite'
        charset: UTF8
 ディレクトリが存在することを確認する: mkdir -p var/share/db
 今、あなたが移住を実行するとき: php bin/console doctrine:migrations:migrate
 THE ファイルは共有ディレクトリで作成されます. クラスター内のすべてのサーバーがこの単一のファイルから読み取ります。 .sqlite SQLite over NFS (Network File System) でロックアップの問題が発生する可能性があります. 共有ストレージ ソリューションがファイルロックを正しくサポートしていることを確認する (たとえば、適切なマウント オプションを備えた AWS EFS など)、または非常に低い書き込み頻度のシナリオでこれを予約してください。 Warning: DevOps:デプロイ戦略 この機能を完全に活用するには、デプロイが表示されます(例えば、 「Kubernetes」 )を更新する必要があります。 docker-compose.yml deployment.yaml Docker Compose サンプル ここでは、生産環境を現地でシミュレートする方法です。 services:
  app_1:
    build: .
    environment:
      APP_SHARE_DIR: /app/var/share
    volumes:
      - shared_data:/app/var/share

  app_2:
    build: .
    environment:
      APP_SHARE_DIR: /app/var/share
    volumes:
      - shared_data:/app/var/share

volumes:
  shared_data:
 この設定では: 
 
 
 システムキャッシュ(var/cache)は、コンテナ内部(高速、孤立)にあります。 Shared Data (var/share) は、app_1 と app_2 の間で共有された名称のボリュームです。 Kubernetes(K8s)戦略 Kubernetes では、PersistentVolumeClaim を使用します。 apiVersion: apps/v1
kind: Deployment
metadata:
  name: symfony-app
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: php
          image: my-symfony-app:7.4
          env:
            - name: APP_SHARE_DIR
              value: "/var/www/html/var/share"
          volumeMounts:
            - mountPath: "/var/www/html/var/share"
              name: shared-storage
      volumes:
        - name: shared-storage
          persistentVolumeClaim:
            claimName: efs-pvc
 Verification: 
 
 
 
 
 
 Exec into Pod 1: kubectl exec -it symfony-app-pod-1 — bash ファイルを作成する: touch var/share/test.txt Exec into Pod 2: kubectl exec -it symfony-app-pod-2 — bash チェックファイル: ls var/share/ test.txt を参照してください。 移行ガイド: 7.4 にアップグレード 古いアプリケーションを維持している場合は、Share Directory を採用するには、いくつかの慎重なステップが必要です。 
 
 
 
 
 Update Composer: Composer.json を更新して symfony/*: 7.4 を有効にします。 Update .env: APP_SHARE_DIR を .env および .env.test に追加します。 更新 .gitignore: 一般的には、共有ディレクトリのコンテンツをコミットする必要はありませんが、 gitkeep を保持したい場合があります。 Refactor Paths: hardcoded references to kernel.cache_dir or var/cache. If the code was using the cache directory to store data that should be persisted or shared (such as generated PDF reports, temporary exports), change it to use %kernel.share_dir% (生成されたPDFレポート、一時輸出など) 結論 シンフォニア 7.4 これは単なる新しいフォルダ構造ではなく、成熟のシグナルであり、現代のPHPアプリケーションがクラスターを越えてクラウドに存在し、フレームワークと戦うことなく水平にスケールする必要があることを認識しています。 Share Directory 養子縁組 インフラストラクチャの構成を簡素化し、システムキャッシュのパフォーマンスを向上させ、アプリケーションの状態のための明確で標準化された場所を提供します。 var/share 非重要なマイクロサービスを今すぐ Symfony 7.4 にアップグレードします。 ディレクトリで、システムキャッシュの複雑な NFS マウントを削除し、平均応答時間の減少を見てください。 Ready to scale? var/share この記事はあなたのアップグレードパスを明確にするのに役立ちましたか? [LinkedIn: より良いソフトウェアを一緒に作りましょう。 Keep in touch! https://www.linkedin.com/in/matthew-mochalkin/ https://www.linkedin.com/in/matthew-mochalkin/

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

Symfony 7.4 シェアディレクトリが Kubernetes アプリのキャッシュ問題を解決

About Author

コメント

ラベル

この記事は

Related Stories

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

ユニークなエコシステムを支えるビットコインUTXOのモデル

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

ユニークなエコシステムを支えるビットコインUTXOのモデル

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps