高負荷の状況でPHPコードをデプロイする5つの方法

学校で高負荷が教えられた場合、この主題の教科書はそのような仕事を持っているでしょう。 「Nソーシャルネットワークには2,000台のサーバーがあり、その上に各PHPコード900 MBの150,000個のファイルと50台のマシンのステージングクラスターがあります。 コードはサーバーに1日に2回展開され、コードはステージングクラスターで数分ごとに更新されます。追加の「修正プログラム」があります。完全な計算を待たずに、サーバーのすべてまたは選択した部分に順番に配置された小さなファイルセットです。 質問：そのような条件は高負荷と見なされ、それらを展開する方法は？ 少なくとも5つの展開オプションを作成します。」 私たちは、hyload問題の本についてのみ夢を見ることができますが、すでに、 Yuri Nasretdinov （ youROCK ）が間違いなくこの問題を解決し、「5」を獲得することがわかっています。





ユリは単純なソリューションに留まらず、「コードデプロイ」コンセプトの概念を開示し、大規模なPHPデプロイメントの従来の代替ソリューションについて話し、そのパフォーマンスを分析し、MDKデプロイメントシステムを提示したレポートを追加しました。

「コードのデプロイ」の概念

英語では、「展開」という用語は軍隊を警戒させることを意味し、ロシア語では「コードを戦闘に投入する」ということもありますが、これは同じことを意味します。 すでにコンパイルされているコードまたは元のコード（PHPの場合）を使用して、ユーザートラフィックを処理するサーバーにアップロードし、魔法によってコードのバージョンを別のバージョンに切り替えます。 これらはすべて、「コードのデプロイ」の概念に含まれています。



通常、展開プロセスはいくつかの段階で構成されます。

• リポジトリからコードを取得するには、クローン、フェッチ、チェックアウトなど、好きな方法を使用します。
• アセンブリ-ビルド 。 PHPコードの場合、ビルドフェーズが欠落している可能性があります。 私たちの場合、これは原則として、翻訳ファイルの自動生成、静的ファイルのCDNへのアップロード、およびその他の操作です。
• エンドサーバーへの配信 -展開。

すべてがアセンブルされた後、即時展開のフェーズが始まります- コードは運用サーバーに注がれます 。 Badooについては、このフェーズについて説明します。

Badooの古い展開システム

ファイルシステムイメージのあるファイルがある場合、それをマウントする方法は？ Linuxでは、 中間ループデバイスを作成し、それにファイルを添付する必要があります。その後、このブロックデバイスは既にマウントできます。



ループデバイスは、Linuxがファイルシステムイメージをマウントするために必要な松葉杖です。 この松葉杖が必要ないOSがあります。







簡単にするために「ループ」とも呼ばれるファイルを使用して、展開プロセスはどのように行われますか？ ソースコードと自動生成されたコンテンツが配置されているディレクトリがあります。 ファイルシステムの空のイメージを取得します。現在はEXT2であり、以前はReiserFSを使用していました。 ファイルシステムの空のイメージを一時ディレクトリにマウントし、そこにすべての内容をコピーします。 本番に入るために何かが必要ない場合、すべてをコピーするわけではありません。 その後、デバイスをアンマウントし、必要なファイルが配置されているファイルシステムのイメージを取得します。 次に、 画像をアーカイブしてすべてのサーバーにアップロードし 、そこで解凍してマウントします。

他の既存のソリューション

まず、 Richard Stallmanに感謝しましょう。彼のライセンスがなければ、私たちが使用するユーティリティのほとんどは存在しなかったでしょう。







私は従来、PHPコードをデプロイする方法を4つのカテゴリーに分けていました。

• バージョン管理システムに基づいて、svn up、git pull、hg up。
• rsyncユーティリティに基づいて -新しいディレクトリまたは「トップ」に。
• 1つのファイルをデプロイします -phar、hhbc、loopに関係なく。
• Rasmus Lerdorfが提案した特別な方法は、 rsync、2つのディレクトリ、およびrealpath_rootです。

各メソッドには長所と短所の両方があります。そのため、それらを放棄しました。 これら4つの方法をより詳細に検討してください。

svn upバージョン管理システムに基づく展開

私は偶然ではなくSVNを選択しました-私の観察によれば、この形式ではSVNの場合に展開が正確に存在します。 システムは非常に軽量で 、 簡単かつ迅速に展開を実行できます-svnを実行するだけで完了です。



ただし、この方法には大きなマイナス点が1つあります。svnupを実行し、ソースコードを更新する過程で、リポジトリから新しいリクエストが来ると、リポジトリに存在しないファイルシステムの状態が表示されます。 新しいファイルの一部と古いファイルの一部があります。これは非原子的な展開方法で、高負荷には適していませんが、小さなプロジェクトにのみ適しています。 それにもかかわらず、私はまだこの方法で展開されているプロジェクトを知っています。

rsyncユーティリティに基づく展開

これを行うには2つのオプションがあります。ユーティリティを使用してファイルをサーバーに直接アップロードし、「上に」アップロードする-更新します。

新しいディレクトリへのrsync

最初にすべてのコードをサーバーにまだ存在しないディレクトリに完全に注ぎ込み、それからトラフィックを切り替えるため、このメソッドはアトミックです -誰も中間状態を見ません。 この場合、150,000個のファイルを作成し、150,000個のファイルがある古いディレクトリを削除すると、ディスクサブシステムに大きな負荷がかかります 。 私たちはハードディスクを非常に積極的に使用しており、そのような操作の後、1分間のサーバーはあまり気分が悪くなります。 2000台のサーバーがあるため、900 MBを2000回アップロードする必要があります。



このスキームは、最初に特定の数の中間サーバー（たとえば50）にアップロードしてから、残りのサーバーに追加すると改善できます。 これにより、ネットワークで発生する可能性のある問題は解決されますが、膨大な数のファイルを作成および削除する問題はどこにも消えません。

上のrsync

rsyncを使用した場合、このユーティリティはディレクトリ全体を埋めるだけでなく、既存のディレクトリを更新することもできます。 変更のみを送信するのはプラスですが、バトルコードを提供する同じディレクトリに変更をアップロードするため、何らかの中間状態もあります。これはマイナスです。



変更の送信は次のように機能します。 Rsyncは、デプロイが実行されるサーバー側と受信側でファイルのリストを作成します。 その後、すべてのファイルからstatをカウントし、リスト全体を受信側に送信します。 展開を進めているサーバー上で、これらの値の違いが考慮され、どのファイルを送信するかが決定されます。



私たちの条件では、このプロセスには約3 MBのトラフィックと1秒のプロセッサー時間がかかります。 これは大したことではないようですが、2,000台のサーバーがあり、すべてが少なくとも1分間のプロセッサ時間になります。 これはそれほど簡単な方法ではありませんが、rsyncを使用してすべてを送信するよりも確実に優れています。 どうにかして原子性の問題を解決し、ほぼ完璧になります。

単一ファイルを展開する

アップロードするファイルが1つであっても、BitTorrentまたはUFTPユーティリティを使用すると比較的簡単に実行できます。 1つのファイルは解凍が簡単で、Unixでアトミックに置き換えることができます。また、ファイルからMD5またはSHA-1の量を計算することにより、ビルドサーバーで生成され、宛先マシンに配信されるファイルの整合性を簡単に確認できます（rsyncの場合、宛先サーバーに何があるかわかりません）



ハードドライブの場合、シーケンシャルレコーディングは大きなプラスです。約10秒で、空いているハードドライブに900 MBのファイルが書き込まれます。 ただし、これらの同じ900 MBを記録し、ネットワーク経由で転送する必要があります。

UFTPに関する叙情的な余談

このオープンソースユーティリティは、元々、たとえば衛星ベースのネットワークを介して、ネットワーク上で長い遅延のあるファイルを転送するために作成されました。 しかし、UFTPはマルチキャストに基づくUDPプロトコルを使用して動作するため、多数のマシンへのファイルのアップロードに適していることが判明しました。 単一のマルチキャストアドレスが作成され、ファイルを受信するすべてのマシンがサブスクライブし、スイッチがパケットのコピーが各マシンに配信されるようにします。 そこで、データをネットワークに送信する負担をシフトします。 ネットワークがこれを処理できる場合、この方法はBitTorrentよりもはるかにうまく機能します。



クラスターでこのオープンソースユーティリティを試すことができます。 UDP上で動作するという事実にもかかわらず、NACKメカニズム（配信時に失われたパケットの再転送を強制する否定応答）があります。 これは展開する信頼できる方法です。

単一ファイルの展開オプション

tar.gz



両方のアプローチの欠点を組み合わせたオプション。 ディスクに900 MBを順番に書き込む必要があるだけでなく、その後、同じ900 MBをランダムに読み書きしてもう一度書き込み、150,000個のファイルを作成する必要があります。 この方法は、rsyncよりもパフォーマンスがさらに劣ります。



ファー



PHPは、phar形式のアーカイブ（PHPアーカイブ）をサポートし、コンテンツの提供方法とファイルのインクルード方法を知っています。 ただし、すべてのプロジェクトを1つのpharに入れるのが簡単なわけではありません。コードの適合が必要です。 このアーカイブからのコードが機能しないという理由だけで。 さらに、アーカイブ内の1つのファイルを変更することはできません（ 将来のYuri：理論的には、まだ可能です）。アーカイブ全体をリロードする必要があります。 また、pharアーカイブはOPCacheで機能するという事実にもかかわらず、デプロイするときにキャッシュを破棄する必要があります。そうしないと、古いpharファイルからOPCacheにガベージが発生します。



hhbc



このメソッドは、HHVMのネイティブであるHipHop Virtual Machineであり、Facebookで使用されています。 これはpharアーカイブのようなものですが、ソースコードは含まれていませんが、HHVM仮想マシン（FacebookのPHPインタープリター）のコンパイル済みバイトコードは含まれていません。 このファイルの内容を変更することは禁止されています。新しいクラス、関数を作成することはできません。また、このモードのその他の動的機能は無効になります。 これらの制限により、仮想マシンは追加の最適化を使用できます。 Facebookによると、これによりコード実行速度が最大30％向上する可能性があります。 これはおそらく彼らにとって良い選択肢です。 ここで1つのファイルを変更することも不可能です（ 将来のYuri：sqliteベースであるため、実際には可能です）。 1行変更したい場合は、アーカイブ全体を再度やり直す必要があります。



この方法では、 evalおよび動的なincludeの使用は禁止されています。 これはそうですが、完全ではありません。 Evalは使用できますが、新しいクラスまたは関数が作成されず、このアーカイブの外部にあるディレクトリからインクルードすることはできません。



ループ



これは古いバージョンであり、2つの大きな利点があります。 まず、通常のディレクトリのように見えます。 ループをマウントすると、とにかくコードのために-開発環境と本番環境の両方でファイルを処理します。 2番目の-ループは読み取りおよび書き込みモードでマウントでき、実稼働のために何かを緊急に変更する必要がある場合は1つのファイルを変更できます。



しかし、ループには短所があります。 まず、Dockerで奇妙に動作します。 これについては後で説明します。



2番目-最後のループでdocument_rootとしてシンボリックリンクを使用すると、OPCacheで問題が発生します。 パスにシンボリックリンクを含めるのはあまり得意ではなく、使用するファイルのバージョンを混乱させ始めます。 したがって、デプロイ時にOPCacheをリセットする必要があります。



もう1つの問題は、ファイルシステムをマウントするにはスーパーユーザー特権が必要なことです。 また、マシンの起動/再起動時にそれらをマウントすることを忘れないでください。そうしないと、コードの代わりに空のディレクトリが存在します。

ドッカーの問題

ドッカーコンテナーを作成し、その中に「ループ」または他のブロックデバイスがマウントされるフォルダーをスローすると、2つの問題が同時に発生します。新しいマウントポイントがドッカーコンテナーに落ちないこと、および作成時に存在した「ループ」 Dockerコンテナは 、Dockerコンテナによって占有されているため、 マウント解除できません 。



当然、これは通常、展開と互換性がありません。ループデバイスの数が制限されており、新しいコードがコンテナにどのように分類されるかが不明だからです。



たとえば、ローカルNFSサーバーを起動したり、SSHFSを使用してディレクトリをマウントしたりするなど、奇妙なことをしようとしましたが、さまざまな理由でこれが定着しませんでした。 その結果、cronでrsyncを最後の「ループ」から現在のディレクトリに登録し、1分ごとにコマンドを実行しました。

rsync /var/loop/<N>/ /var/www/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで/var/www/



は、コンテナに昇格されるディレクトリです。 しかし、Dockerコンテナを備えたマシンでは、PHPスクリプトを頻繁に実行する必要がないため、rsyncはアトミックではなく、私たちに適しています。 それでも、この方法はもちろん非常に悪いです。 Dockerでうまく機能する展開システムを作成したいと思います。

rsync、2つのディレクトリおよびrealpath_root

この方法は、PHPの作成者であるRasmus Lerdorfによって提案されたもので、彼は展開方法を知っています。



アトミックデプロイを作成する方法と、私が説明した方法のいずれかを使用しますか？ シンボリックリンクを取得し、document_rootとして登録します。 各時点で、シンボリックリンクは2つのディレクトリのいずれかを指し、rsyncを近隣のディレクトリ、つまりコードが指し示していないディレクトリに作成します。







しかし、問題が発生します：PHPコードは、どのディレクトリで起動されたかを知りません。 したがって、たとえば、configの最初のどこかに書き込む変数を使用する必要があります。これにより、コードが実行されたディレクトリと新しいファイルが含まれるディレクトリが修正されます。 スライドでは、 ROOT_DIR



と呼ばれROOT_DIR



。



本番環境で使用するコード内のすべてのファイルにアクセスするときに、この定数を使用します。 アトミックプロパティを取得します。symlinkを切り替える前に到着したリクエストには、何も変更していない古いディレクトリからのファイルが引き続き含まれ、symlink切り替え後に来た新しいリクエストは新しいディレクトリから動作を開始して処理されます新しいコード。







ただし、これはコードで記述する必要があります。 すべてのプロジェクトがこれに対応できるわけではありません。

ラスマススタイル

Rasmusは 、コードを手動で変更して定数を作成する代わりに、Apacheをわずかに変更するか、nginxを使用することをお勧めします。







document_rootには、最新バージョンへのシンボリックリンクを指定します。 nginxをお持ちの場合は、 root $realpath_root



登録できます。Apacheの場合は、スライドに表示される設定を持つ別のモジュールが必要です。 これは次のように機能します。リクエストが到着すると、nginxまたはApacheがパスからrealpath（）を検討し、シンボリックリンクから保存し、このパスをdocument_rootとして渡します。 この場合、document_rootは常にシンボリックリンクのない通常のディレクトリを指し、PHPコードはどのディレクトリから呼び出されるかを考慮する必要がない場合があります。



この方法には興味深い利点があります-OPCache PHPへの実際のパスはシンボリックリンクを含みません。 リクエストが届いた最初のファイルでさえ、すでにいっぱいになっていて、OPCacheに問題はありません。 document_rootが使用されるため、これはどのPHPプロジェクトでも機能します。 何も適応する必要はありません。



fpmのリロードは不要です。デプロイ中にOPCacheをリセットする必要はありません。これは、すべてのファイルを再度解析する必要があるため、プロセッササーバーの負荷が高い理由です。 私の実験では、OPCacheを約30分リセットすると、プロセッサの消費が2〜3倍増加しました。 それを再利用するのは良いことであり、この方法でそれを行うことができます。



今、短所。 OPCacheを再利用せず、2つのディレクトリがあるため、各ディレクトリのメモリにファイルのコピーを保存する必要があります-OPCacheでは、2倍のメモリが必要です。



奇妙に思われる別の制限があります-max_execution_timeごとに複数回デプロイすることはできません 。 そうしないと、rsyncがディレクトリの1つにアクセスしている間、そのディレクトリからのリクエストを処理できるため、同じ問題が発生します。



何らかの理由でApacheを使用する場合は、Rasmusも書いたサードパーティのモジュールが必要です。



ラスマスは、このシステムは優れていると言います。私もあなたにお勧めします。 99％のプロジェクトでは、新しいプロジェクトと既存のプロジェクトの両方に適しています。 しかし、もちろん、私たちはそのようなものではなく、独自の決定を書くことにしました。

新しいシステム-MDK

基本的に、私たちの要件はほとんどのWebプロジェクトの要件と変わりません。 ステージングとプロダクションでの迅速な展開 、 低リソース消費 、OPCacheの再利用、および高速ロールバックが必要です。



ただし、他の要件とは異なる2つの要件があります。 まず、 アトミックにパッチを適用する機能です。 パッチは、本番環境で何かを支配する1つまたは複数のファイルの変更と呼ばれます。 早くやりたいです。 原則として、Rasmusが提供するシステムはパッチタスクに対処しています。



また、数時間実行できる CLIスクリプトもありますが 、それらは引き続きコードの一貫したバージョンで動作するはずです。 この場合、上記のソリューションは、残念ながら私たちに合わないか、多くのディレクトリが必要です。



可能な解決策：

• ループxN（-staging、-docker、-opcache）;
• rsync xN（-production、-opcache xN）;
• SVN xN（-production、-opcache xN）。

ここで、Nは数時間で発生する計算の数です。 それらを何十個も持つことができるので、コードの追加コピーのために非常に大きなスペースを費やす必要があります。



そのため、新しいシステムを思いついてMDKと呼びました。 これは、 マルチバージョン展開ツールであるマルチバージョン展開キットの略です。 以下の仮定に基づいてそれを行いました。



ツリーストレージアーキテクチャはGitから取得しました。 スクリプトが機能するコードの一貫したバージョンが必要です。つまり、スナップショットが必要です。 スナップショットはLVMでサポートされていますが、BtrfsやGitなどの実験的なファイルシステムでは非効率的に実装されています。 Gitからスナップショットの実装を取りました。



file.phpからfile.php。<version>にすべてのファイルの名前を変更しました。 持っているファイルはすべてディスクに保存されているため、同じファイルの複数のバージョンを保存する場合は、そのバージョンにサフィックスを追加する必要があります。



私はGoが大好きなので、スピードのためにGoでシステムを作成しました。

Multiversion Deployment Kitの仕組み

Gitからスナップショットのアイデアを取り入れました。 それを少し単純化し、MDKでの実装方法を説明します。



MDKには2種類のファイルがあります。 最初はカードです。 以下の図は緑色でマークされており、リポジトリ内のディレクトリに対応しています。 2番目のタイプは直接ファイルで、通常と同じ場所にありますが、ファイルバージョンの形式のサフィックスが付いています。 ファイルとマップは、その内容に基づいてバージョン管理されます。この例では、単にMD5です。







ルートマップが他のマップのファイルの特定のバージョンを参照し、それらが他のファイルとマップを参照し、特定のバージョンを修正するファイルの階層があるとします。 何らかのファイルを変更したいのです。







おそらく同様の写真を見たことがあるかもしれません：ネストの第2レベルでファイルを変更し、対応するマップ-map *で、3つの*ファイルのバージョンが更新され、その内容が変更され、バージョンが変更されます-バージョンもルートマップで変更されます。 何かを変更すると、常に新しいルートマップが取得されますが、変更しなかったファイルはすべて再利用されます。



リンクは以前と同じファイルに残ります。 これは、任意の方法でスナップショットを作成する主なアイデアです。たとえば、 ZFSでは 、ほぼ同じ方法で実装されます。

MDKがディスク上にある方法

ディスク上にあります： 最新のルートマップへのシンボリックリンク-Webから提供されるコード、ルートマップのいくつかのバージョン、場合によっては異なるバージョンのいくつかのファイル、およびサブディレクトリには対応するディレクトリのマップがあります。



私は質問を予見します：「 そして、これはどのようにウェブリクエストを処理しますか？ユーザーコードはどのファイルに来るでしょうか？ 」



はい、私はあなたを欺いた-バージョンなしのファイルもあります。index.phpのリクエストを受信し、ディレクトリにそれがない場合、サイトは機能しません。







すべてのPHPファイルには、 スタブと呼ばれるファイルがあります。これらのファイルには、これらのカードの操作方法を知っている関数が宣言されているファイルからのファイルと、目的のバージョンのファイルからのファイルの2行が含まれているためです。

 <?php require_once "mdk.inc"; require mdk_resolve_path("a.php");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、バージョンなしでa.phpファイルからb.phpを除外した場合、require_onceが書き込まれているため、システムはどのルートカードから開始したかを記憶し、それを使用するため、最新バージョンにシンボリックリンクされません一貫したバージョンのファイルを取得します。



残りのファイルについては、最新バージョンへのシンボリックリンクがあります。

MDKを使用して展開する方法

モデルはgit pushに非常に似ています。

• ルートマップのコンテンツを送信します。
• 受信側では、どのファイルが欠落しているかを調べます。 ファイルのバージョンはコンテンツによって決定されるため、もう一度ダウンロードする必要はありません（ 将来のユーリ：短縮されたMD5の衝突が発生する場合を除きます。
• 不足しているファイルを要求します。
• 2番目のポイントに進み、さらに円を描きます。

例

サーバーに「one」という名前のファイルがあるとします。 ルートマップを送信します。







ルートマップの破線の矢印は、存在しないファイルへのリンクを示しています。 それらがマップ上にあるため、それらの名前とバージョンを知っています。 サーバーにリクエストします。 サーバーが送信すると、ファイルの1つがカードでもあることがわかります。







見てください-単一のファイルはありません。 再度、不足しているファイルをリクエストします。 サーバーはそれらを送信します。 残りのカードはありません-展開プロセスが完了しました。







ファイルが150,000個の場合はどうなるか簡単に推測できますが、変更されています。 ルートマップで1つのマップが欠落していることがわかります。ネストのレベルを確認して、ファイルを取得しましょう。 計算の複雑さという点では、プロセスはファイルを直接コピーすることとほとんど変わりませんが、同時にコードの一貫性とスナップショットが保持されます。



MDKには欠点はありません:) 1週間以内にデプロイされたすべてのファイルを残すことができるため、 小さな変更を迅速かつアトミックにデプロイでき 、 スクリプトは数日間機能します。 それらはかなり十分なスペースを占有します。 OPCacheを再利用することもでき、CPUはほとんど何も食べません。



監視は非常に困難ですが、可能です。 すべてのファイルはコンテンツごとにバージョン管理されており、すべてのファイルを調べて名前とコンテンツを確認するcronを作成できます。 ルートマップがすべてのファイルを参照していること、破損したリンクがないことを確認することもできます。 さらに、展開中に整合性がチェックされます。



古いカードはすべて揃っているため、変更を簡単にロールバックできます 。 カードを投げるだけで、すぐにすべてが揃います。



私にとって、さらにMDKがGoで記述されているという事実は、 MDKがすばやく動作することを意味します。



私は再びあなたを欺いた、まだ短所があります。 プロジェクトをシステムで動作させるには、コードを大幅に変更する必要がありますが、一見すると思われるよりも簡単です。 システムは非常に複雑です。Badooなどの要件がない場合は、実装をお勧めしません。 また、とにかく、遅かれ早かれ場所は終了するので、 ガベージコレクターが必要です 。



ファイルを編集するための特別なユーティリティを作成しました-スタブではなく実際のファイル、たとえばmdk-vim。 ファイルを指定すると、目的のバージョンが検出されて編集されます。

数字のMDK

ステージングに50台のサーバーがあり、その上に3〜5秒間展開します。 rsync以外のすべてと比較すると、非常に高速です。 本番環境では、約2分 、 5〜10秒の小さなパッチを展開します。



何らかの理由で、すべてのサーバー上のコードでフォルダー全体が失われた場合（これは決して発生しないはずです）、 完全アップロードのプロセスには約40分かかります。 夜はトラフィックが最小でしたが、それは一度起こりました。 したがって、誰も怪我をしませんでした。 2番目のファイルは5分間サーバーのペア上にあったため、言及する価値はありません。



システムはオープンソースではありませんが、もし興味があれば、コメントを書いてください-レイアウトされるかもしれません（ 将来のゆり：この記事を書いている時点ではまだシステムはオープンソースではありません ）。

おわりに

ラスマスに耳を傾け、彼は嘘をついていません 。 私の意見では、そのrsyncメソッドとrealpath_rootが最適ですが、ループも非常にうまく機能します。



頭で考えてください 。プロジェクトに必要なものを見て、十分な「トウモロコシ」がある宇宙船を作ろうとしないでください。 ただし、同様の要件がある場合は、MDKに似たシステムが適しています。

HighLoad ++で説明されたこのトピックに戻ることにしましたが、おそらく高いパフォーマンスを達成するための多くのレンガの1つにすぎなかったため、十分な注意が払われませんでした。 しかし今、完全にPHPに特化した専門のPHPロシア会議が開催されています。 そして、ここで私たちは本当に完全に抜けます。 パフォーマンス 、 標準 、およびツールについて、 リファクタリングを含む多くのことについて徹底的に話します。



会議プログラムの更新で電報チャンネルを購読し、5月17日に会いましょう。