Netlifyのインフラストラクチャチームがどのようにしてデプロイ速度を上げながら可観測性を向上させたか

Netlifyのインフラストラクチャチームは、どのようにして顧客のデプロイ速度を最大2倍に向上させたかの話を共有した。これは、デプロイアルゴリズムを最適化し、プロセス中のシステムの可観測性を向上させることによるものである。

Netlifyは、Webアプリケーションと静的Webサイトのホスティングサービスとバックエンドサービスを提供する。Netlifyは、ユーザが提供したコンテンツから静的ファイルを生成し、複数のクラウドベンダーを跨ってコンテンツ配信ネットワークを介してそれらを提供する。50000以上のファイルの大規模なデプロイでパフォーマンスの問題が発生した。その理由はMongoDBに格納されている内部データ構造での再帰的なクエリである。インフラストラクチャチームはこれを最適化し、この実施の一環として、システムの可観測性も向上させた。

内部的には、ユーザコンテンツのデプロイについてのNetlifyのコアは、Merkleツリーを中心に構築されている。Merkleツリーは、各リーフノードがデータのハッシュでラベル付けされるデータ構造である。そして、すべての非リーフノードがその子ノードのラベルのハッシュでラベル付けされる。ファイルコンテンツのハッシュは、Netlifyのバックエンドのコンテンツの変更を検出するためにツリーのファイル名として使用される。デプロイは、変更と既存のコンテンツに基づいて「それらのハッシュを計算し、新しいツリーを生成する」。MongoDBに内部的に保存されているツリーは、デプロイが顧客によって開始したときに最初に作成されていた。その後、顧客のファイルがアップロードされると、デプロイの進行状況を追跡するためにツリーがスキャンされて更新された。これによりパフォーマンスの問題が発生した。MongoDBでのロックの競合が原因であり、特に大規模なデプロイメントの場合に発生する。

パフォーマンスを向上させるための最初のステップは、プロセスの可視性を向上させるための機器を導入することであった。これにより、ファイルのアップロードごとに操作が繰り返されていることがわかった。チームは、デプロイの進行状況の追跡をコアツリーから分離することを決定した。また、ツリー全体を事前に作成するのをやめ、代わりに情報を個別に保存して、最後に最終的なツリーを作成する。

InfoQは、より詳細に理解するために、NetlifyのシニアソフトウェアエンジニアであるIngrid Epure氏に連絡を取った。

チームは、いくつかの初期の問題を抱えつつも、新機能を本番環境にデプロイした。彼らは、信頼性と可視性を確保するために、テストとテレメトリの広範なリストを持つことにフォーカスした。ただし、最初に直面した問題のために、いくつかのチェックポイントを追加し、十分な自信が持てるようになるまでチェックポイントを繰り返した。Epure氏によると、これらのチェックポイントには、テレメトリ（メトリック収集）を使用して問題を正確に特定することや、ガードレールを追加してビルドを最終的に安定した状態にすることが含まれる。

#monitoring jp #devops #ニュース

What is GEEK

Buddha Community

Netlifyのインフラストラクチャチームがどのようにしてデプロイ速度を上げながら可観測性を向上させたか

Netlifyのインフラストラクチャチームは、どのようにして顧客のデプロイ速度を最大2倍に向上させたかの話を共有した。これは、デプロイアルゴリズムを最適化し、プロセス中のシステムの可観測性を向上させることによるものである。

Netlifyは、Webアプリケーションと静的Webサイトのホスティングサービスとバックエンドサービスを提供する。Netlifyは、ユーザが提供したコンテンツから静的ファイルを生成し、複数のクラウドベンダーを跨ってコンテンツ配信ネットワークを介してそれらを提供する。50000以上のファイルの大規模なデプロイでパフォーマンスの問題が発生した。その理由はMongoDBに格納されている内部データ構造での再帰的なクエリである。インフラストラクチャチームはこれを最適化し、この実施の一環として、システムの可観測性も向上させた。

内部的には、ユーザコンテンツのデプロイについてのNetlifyのコアは、Merkleツリーを中心に構築されている。Merkleツリーは、各リーフノードがデータのハッシュでラベル付けされるデータ構造である。そして、すべての非リーフノードがその子ノードのラベルのハッシュでラベル付けされる。ファイルコンテンツのハッシュは、Netlifyのバックエンドのコンテンツの変更を検出するためにツリーのファイル名として使用される。デプロイは、変更と既存のコンテンツに基づいて「それらのハッシュを計算し、新しいツリーを生成する」。MongoDBに内部的に保存されているツリーは、デプロイが顧客によって開始したときに最初に作成されていた。その後、顧客のファイルがアップロードされると、デプロイの進行状況を追跡するためにツリーがスキャンされて更新された。これによりパフォーマンスの問題が発生した。MongoDBでのロックの競合が原因であり、特に大規模なデプロイメントの場合に発生する。

パフォーマンスを向上させるための最初のステップは、プロセスの可視性を向上させるための機器を導入することであった。これにより、ファイルのアップロードごとに操作が繰り返されていることがわかった。チームは、デプロイの進行状況の追跡をコアツリーから分離することを決定した。また、ツリー全体を事前に作成するのをやめ、代わりに情報を個別に保存して、最後に最終的なツリーを作成する。

InfoQは、より詳細に理解するために、NetlifyのシニアソフトウェアエンジニアであるIngrid Epure氏に連絡を取った。

チームは、いくつかの初期の問題を抱えつつも、新機能を本番環境にデプロイした。彼らは、信頼性と可視性を確保するために、テストとテレメトリの広範なリストを持つことにフォーカスした。ただし、最初に直面した問題のために、いくつかのチェックポイントを追加し、十分な自信が持てるようになるまでチェックポイントを繰り返した。Epure氏によると、これらのチェックポイントには、テレメトリ（メトリック収集）を使用して問題を正確に特定することや、ガードレールを追加してビルドを最終的に安定した状態にすることが含まれる。

#monitoring jp #devops #ニュース