これは Wiz シニア ソフトウェア エンジニアSagi Tsofan によるものです
Amazon Web Technologies との共著の注目記事。
Wiz ではスケールがすべてです。当社のプラットフォームは、毎日数百億のクラウド リソースのメタデータとテレメトリ データを取り込みます。当社のエージェントレス スキャナは大量のデータを収集するため、非常に効率的に処理する必要があります。会社が成長するにつれて、私たちはいかに効率的に維持し、拡大していくかという大きな課題に直面しています。この記事では、Amazon ElastiCache を使用する際の技術的な課題と解決策について説明します。これにより、ビジネス効率が向上するだけでなく、お客様に生み出す価値も向上します。
Wiz が 2020 年にリリースされたとき、私たちはセキュリティ チームがクラウド リスクを軽減できるよう支援することに着手しました。当社は短期間で大きな進歩を遂げ、資金調達、評価額、ARR の記録を破り、史上最速で成長する Software-as-a-Service (SaaS) 企業となり、ARR のマイルストーン 1 億ドルを達成しました。
Wiz プラットフォームは、顧客にクラウド環境の状態に関する最新のビューを提供します。これは、新しいクラウド リソースの作成、既存のクラウド リソースの変更、既存のクラウド リソースの削除など、すべての変更ができるだけ早く Wiz プラットフォームに反映されることを意味します。
下の画像は、Wiz プラットフォームにおける顧客のクラウド アカウントの現在のビューを示しています。
このビューをお客様に提供するために、お客様のクラウド アカウントを頻繁にスキャンするエージェントレス スキャナーを実装しました。スキャナーの主なタスクは、顧客のクラウド アカウント内にあるすべてのクラウド リソースをカタログ化することです。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスから Amazon Identity and Access Management (IAM) ロール、Amazon Virtual Private Cloud (Amazon VPC) ネットワーク セキュリティ グループに至るまで、すべてがログに記録されます。
スキャン結果は Wiz バックエンドに記録され、これらすべてのクラウド リソースはデータ パイプラインを通じて取り込まれます。次の図は、Amazon ElastiCache を導入する前のこのプロセスのステップを示しています。
パイプラインは次のステージで構成されます。
クラウド スキャナ サービスはスケジュールに従ってトリガーされ、顧客アカウントの新しいスキャンを開始します。
このスキャナは、顧客のクラウド アカウント内のすべてのクラウド リソースを列挙し、それらのリソースに関する情報を Amazon Simple Notice Service (Amazon SNS) トピック経由で Amazon Simple Queue Service (Amazon SQS) に公開します。
その後、取り込みプログラムは、SQS キューからこれらのメッセージを消費します。
メッセージごとに、関連するクラウド リソースのメタデータを使用して、実行コンポーネントに対してリモート プロシージャ コール (RPC) が実行されます。
クラウド リソースの更新を Amazon Aurora PostgreSQL 互換データベースに挿入し、クラウド リソースのメタデータ全体 (最後に確認されたタイムスタンプと現在のスキャン実行 ID を含む) を更新するのは実行者の責任です。これは、後で不要になったクラウド リソースを削除するために使用します。顧客アカウントに表示されます。
チャレンジ
同時顧客、クラウド プロバイダー、アカウント、サブスクリプション、ワークロードの数、および同時に実行される数千の同時スキャンを考慮すると、課題が生じます。
Wiz プラットフォームは、毎日数百億件のクラウド リソースの更新を取り込みます。以前は、最後のスキャン以降リソースが変更されていない場合でも、各スキャン後に各クラウド リソースのレコードを更新していました。これを行うのは、リソース レコード内の最後に確認された実行 ID 値を更新することで、ステップ 5 でデータベースからどのリソースを削除する必要があるかを覚えておく必要があるためです。これにより、データベースにさらに多くの負荷がかかります。
各スキャン後にどのクラウド リソースを削除する必要があるかを計算し、データベースへの書き込み数を減らす、より効率的な方法を検討する必要があります。
以下のグラフは、更新によって挿入されたクラウド リソースの合計量をステータスごとにグループ化して示しています。この顧客の場合、クラウド リソースの 90% は変更されていません。
目標
過去数か月にわたって、取り込みパイプラインを最適化するための変更を実装してきました。私たちの主な目標は、クラウド リソースを変更せずに更新を回避することで、データベースの書き込み回数を大幅に削減することです。これは、次の目標を達成するのに役立ちます。
データベースからの負荷が軽減され、クエリのパフォーマンスが向上し、クエリの待ち時間が短縮されます。
PostgreSQL トランザクション ID の使用量を減らし、自動バキュームの頻度を減らしてトランザクション ID のロールバックを回避します。
CPU、読み取り、書き込み、スループット、IO の使用量を削減します。
DB インスタンスタイプを適切にサイズ設定してコストを最適化する
Amazon ElastiCache が役に立ちます
Redis 用 Amazon ElastiCache は、フルマネージドの Amazon クラウド テクノロジー サービスです。これは、ミリ秒未満の応答時間を必要とする最も要求の厳しいアプリケーションをサポートする、拡張性が高く安全なメモリ内キャッシュ サービスです。また、組み込みのセキュリティ、バックアップとリカバリ、リージョン間のレプリケーションも提供します。
Redis の組み込み機能とデータ構造のネイティブ サーバー側サポートを利用して、スキャナーの実行ごとに削除する必要があるクラウド リソースを保存および計算することにしました。
これは、データを追加または削除したり、他のコレクションと比較したりできる、一意の文字列の順序付けされていないコレクションである Set データ モデルを使用することで実現できることがわかりました。
スキャナーはクラウド リソースを監視するたびに、その一意の識別子を (SADD コマンドを使用して) 現在のスキャン実行コレクションに追加します。これにより、スキャン実行ごとに独自のコレクション キーが設定され、最終的には現在のスキャン実行が含まれます。 監視されたすべてのクラウド リソース IDその期間中。
スキャナーが完了し、どのクラウド リソースを削除するかを計算したら、(SDIFF コマンドを使用して) 以前の一連のスキャン実行と比較します。この比較の出力は、データベースから削除する必要がある一連のクラウド リソース ID です。Set データ型に対する ElastiCache のネイティブ サポートを使用することで、比較プロセス全体をデータベースから ElastiCache エンジンにオフロードできます。
基本的な例を見てみましょう。
スキャン 13 は、A、B、C、D、E の 5 つの (新しい) クラウド リソースをコレクションに公開します。
スキャン 14 は、4 つのクラウド リソース (一部は新規、一部は既存) をコレクションに公開します: A、B、G、および H
これら 2 つのスキャンの違いは C、D、E になります。つまり、これらはもう存在しないため、データベースから削除する必要があるクラウド リソースです。
Redis のコレクションには、以下に示すようにデータが設定されます。この投稿では、Redis CLI を使用してコレクションを設定および比較する方法を説明しました。
> sadd snapshot_scan_run_13 A B C D E
(integer) 5
> sadd snapshot_scan_run_14 A B G H
(integer) 4
> smembers snapshot_scan_run_13
1) "D"
2) "C"
3) "B"
4) "A"
5) "E"
> smembers snapshot_scan_run_14
1) "H"
2) "B"
3) "G"
4) "A"
> sdiff snapshot_scan_run_13 snapshot_scan_run_14
1) "D"
2) "C"
3) "E"左にスワイプするとさらに表示されます
取り込みパイプラインに 2 つの新しいステップを追加する必要があります (下の画像の赤色で示されています)。
スキャナーは、観察されたクラウド リソース ID を ElastiCache のコレクションに入力します。
実行プログラムは、最後のスキャン以降の実際のクラウド リソースの変更を特定した場合にのみ、クラウド リソースの更新をデータベースに挿入します。
結果のスキーマは次の図のようになります。
スキャナーはアカウントの検出を完了すると、Amazon SNS および Amazon SQS を通じて「完了」メッセージを送信します。次に、実行プログラムは、Redis の SDIFF コマンドを使用してスキャン間の差異の計算を開始し、結果の ID をデータベースから削除します。次の図は、削除プロセスのアーキテクチャを示しています。
結果
変更全体を運用環境にデプロイすると、すぐにデータベースの改善が見られました。CPU とメモリの使用量が大幅に削減され、DB インスタンスのサイズを適切に設定できるようになりました。
これで、クラウド リソースの 90% がスキップされ、データベースにはまったく書き込まれなくなります。
また、Amazon Cost Explorer コスト管理サービスの次のグラフに示されているように、変更を行った後、対応する IO とコストの削減も観察されました。
課題と学んだ教訓
この大規模なインフラストラクチャの変更中に、多くの課題に直面しましたが、そのほとんどがスケーリングの問題でした。
論理スライス
当社のスキャナーは、スキャンごとに数億のクラウド リソースを列挙します。各 Redis コレクションには最大 40 億のアイテムを保存できます。ただし、2 つの非常に大きなコレクションに対して SDIFF コマンドを実行すると、CPU とメモリが大量に消費されます。この例では、エントリが多すぎるコレクションで SDIFF を実行すると、比較が完了する前にワークフローがタイムアウトになりました。
ElastiCache サービス チームからの推奨に従い、コレクションを論理的にシャーディングすることにしました。数億のエントリを含む 1 つの巨大なコレクションを使用する代わりに、ElastiCache の分散特性を利用して、クラウド リソース ID の一部を含む小さなコレクションに分割します。ElastiCache サービス チームは、各コレクションに約 150 万件以下のエントリを入力することを推奨しています。これにより、ワークロードに許容可能なランタイムが提供されます。
削除プロセスでは、複数のシャード セットをマージし、それらの差分を計算する必要があります。以下の図は、ElastiCache のシャード化されたコレクション構造を示しています。2 回のスキャン反復で、各スキャンで複数のコレクションにわたって観察されたクラウド リソース ID がシャード化されます。
ここで、常に同じシャードのセットを比較し、各クラウド リソースを同じシャードに保存することを保証する必要があります。そうしないと、比較結果が破損した差分結果となり、クラウド リソースが不必要に削除されることになります。これは、クラウド リソースごとにシャードを決定的に計算することで実現されます。
クラスターモードが有効になっています
私たちはスキャンを頻繁に行うため、コレクションも数多くあり、それぞれに何百万ものアイテムが含まれています。すぐに最大メモリ サイズに達してしまうため、この量のデータを 1 つの ElastiCache ノードに収めることはできません。
コレクションをさまざまなシャードに分散し、ElastiCache インスタンス クラスのタイプを変更せずにメモリを随時拡張できる方法が必要でした。
クラスター モード (CME) を有効にして ElastiCache に移行することにしました。これにより、より多くのメモリが必要なときにクラスターに新しいシャードを簡単に追加できるようになります。
「クラスターモードが無効」から「クラスターモードが有効」への移行プロセスには、新しい SDK ライブラリの使用と、同じシャード内のキーグループの場所を制御するためのキャッシュキーのタグ付けが含まれます。
パイプライン
Redis パイプラインは、個々のコマンドからの応答を待たずに複数のコマンドを一度に実行することでパフォーマンスを向上させるために使用されます。
スキャン中に ElastiCache に送信されるコマンドを保存してバッチ処理するパイプライン メカニズムを採用し、クライアントとサーバーの往復を削減します。
これにより、ElastiCache クラスターで 1 秒あたりに実行されるオペレーションの数を減らすことができます。
要約する
Amazon Aurora PostgreSQL互換エディション データベースの前に ElastiCache を追加することで、アプリケーション全体のパフォーマンスが向上し、データベースへのストレスが軽減され、データベース インスタンスのサイズを適切に設定できるようになり、より多くの顧客の負荷をスケーリングして処理しながら TCO を節約できました。
ElastiCache を使用して、最終結果を Amazon Aurora PostgreSQL 互換バージョンのデータベースに保存する前にデータベースの一括更新を排除します。その過程で、各データベース エンジンの強みを活用します。Redis は高速データを保存するための優れたツールですが、PostgreSQL は長期保存と分析に適しています。
ElastiCache は、取り込みパイプラインの重要なコンポーネントです。これにより、より多くのスキャンとクラウド リソースの取り込みを処理できるように大幅に拡張できるようになります。これにより、データベースのパフォーマンスを向上させ、インスタンスの種類を減らし、全体のコスト (ElastiCache のコストを含む) を 30% 削減することができました。さらに、ElastiCache リザーブドノードを使用してコストをさらに削減しました。
元の URL:
https://aws.amazon.com/blogs/database/how-wiz-used-amazon-elasticache-to-improve-performance-and-reduce-costs/
この記事の著者
Sagi Tsofan は 、Wiz エンジニアリング チームのソフトウェア エンジニアであり、製品インフラストラクチャとスケーリング領域に重点を置いています。彼は大規模分散システムの構築に 15 年以上の経験があり、Wiz、Wix、XM Cyber、IDF などの企業向けの拡張性の高いソリューションの開発と構築に関して深い理解と広範な経験を持っています。画面の前にいないときは、テニスをしたり、旅行したり、友人や家族と時間を過ごしたりすることを楽しんでいます。
Tim Gustafson は、Amazon Cloud Technologies のチーフ データベース ソリューション アーキテクトであり、オープンソース データベース エンジンと Aurora に重点を置いています。Amazon ウェブサイト サービスのデータベースで顧客を支援していないときは、Amazon ウェブサイト サービスで独自のプロジェクトを開発することに時間を費やして楽しんでいます。
聞いたので、下の 4 つのボタンをクリックしてください
バグに遭遇することはありません！
