We’re sorry we missed you at re:Invent, but we can still meet!

ハイパフォーマンスなシステム構築のための4つのヒント

パフォーマンスを重視する場合は、以下のベストプラクティスを念頭に置いてください。

Daniela Miao headshot
Daniela Miao
Author
Khawaja Shams headshot
Khawaja Shams
Author

Share

高性能なシステムを構築し、維持するのは大変なことです!ここでは、Momentoでパフォーマンスを維持・向上させるために実践している4つのプラクティスを紹介します。

中央値や平均値ではなく、テール・レイテンシーに注目する

パフォーマンスに敏感なソフトウェアやサービスを構築する場合、P50や平均レイテンシを宣伝したくなるのが常です。これらの数値は一般的にP99やP999よりもはるかに良く見え、P99やP999でレイテンシが指数関数的に上昇し、平均の10倍から100倍に達するのをよく目にします。残念ながら、P50のレイテンシは典型的な(あるいはP50の)顧客体験を代表するものではありません。キャッシュが飼いならされていないテールレイテンシは、実際にはコアデータベースよりも悪くなる可能性があり、キャッシュの目的を完全に破ってしまうことがよくあります。最新のアプリケーションは、同じバックエンドに複数のコールを行うことが多く、時には数十回に及ぶこともあります。これは、顧客が最も遅いリクエストの応答を待つため、テールレイテンシの影響を著しく増大させます。

新しい技術やテクニックを迅速に評価するために、テストハーネスに投資する

しっかりとしたテストハーネスがあれば、チームは幅広いパフォーマンス最適化を迅速に評価することができます。Twitter社では、Brian Martin氏がRPCサービスをベンチマークする汎用ツールrpc-perfを構築し、Twitter社のキャッシングサービスの評価に広く使用されています。rpc-perfは、高解像度のレイテンシメトリクス、MemcachedやRedisを含む複数のプロトコルのサポート、強力なテスト設定、レイテンシのウォーターフォール可視化などの機能を備えています。

Momentoのgrpcプロトコルのサポートをrpc-perfに追加し、OpenTelemetryと統合することで、パフォーマンス・ベンチマークの結果をGrafanaとLightStepで可視化できるようになりました。私たちはまた、rpc-perfインスタンスのフリートを迅速にデプロイして、Momentoに向けてアットスケールの負荷を送信し始めるためのInfrastructure-as-Codeを持っています。私たちは、新しい変更が本番稼動に入る前にパフォーマンスへの影響を検証するために、デプロイメントにパフォーマンス検証段階を積極的に追加しています。

システム内の各コンポーネントのサービスレベル目標(SLO)を設定する

SLOは、各試験で求める成果の根拠となる重要なものです。SLOは2つの方法で使用します。第一に、各コンポーネントがサービスを開始するために満たすべき最低限の基準です。これは例えば、コードの変更やエンジンのアップグレードに適用されます。第二に、私たちはSLOのマイルストーンに到達するよう努力します。これらのマイルストーンが達成されれば、それを新たな最低SLOとします。このようなアプローチにより、私たちはバランスの取れた現実的なイノベーションのペースと、より長い期間をかけて顧客に提供したい反復的なパフォーマンス向上を実現することができます。

継続的な完成度テスト

テストハーネスとSLOは、メジャーアップデートやチューニングの有効性を評価するのに最適です。残念ながら、どんなに小さなデプロイメントであっても、それぞれのデプロイメントにはパフォーマンスを低下させる重大なリスクがあります。CICDパイプラインにパフォーマンスまたはソークステージを設けることで、リグレッションがプロダクションに到達しないようにすることができます。また、パフォーマンスカナリアは、プロダクションでのリグレッションを迅速に検出するのに役立ちます。

GoogleのTau T2A VMのためのPelikanの最適化に関するディープダイブで、私たちがこのフレームワークをどのように採用したかについてお読みください。

Share