ハイブリッドクラウドとマルチテナントのビッグデータプラットフォームの容量とコンプライアンスに関する考慮事項

導入

近年、データに基づく洞察の重要性が徐々に認識されるようになりました。このアプローチは、戦略的な意思決定を強化し、投資収益率を向上させることができるためです。ビッグデータを安全にアーカイブするために、データレイクとデータウェアハウスの構築にも重点が置かれています。その結果、ビッグデータを使用して、さまざまなデータエンジニアリング、データサイエンス、ビジネス分析、運用分析の取り組みをサポートし、運用効率の向上、運用コストの削減、ビジネス戦略の策定など、企業の利益に貢献できるようになります。しかし、人間が日常的に消費および生成するデータの急激な増加には、ビッグデータ プラットフォームにおける適切に構造化された容量ガバナンス アプローチが必要です。

導入

容量ガバナンスとスケーラビリティ エンジニアリングは相互に関連した分野であり、ビッグ データ プラットフォームのスケーラビリティ戦略を開発するには、コンピューティング、ストレージ容量の要件、インフラストラクチャのプロビジョニング、およびそれらの相互関係を包括的に理解する必要があります。さらに、技術的なリスクやセキュリティ コンプライアンスへの対応も、キャパシティ ガバナンスで考慮する必要がある重要な側面です。

他のアプリケーションと同様に、ビッグデータ アプリケーションは顧客の個人情報を使用する場合があります。   (PII) データを保護して、企業の主要なビジネスおよび戦略上の決定に影響を与えます。同様に、ビッグデータ アプリケーションは、データ セキュリティとサービスの信頼性に関する最新の標準に常に準拠する必要があります。すべての IT ハードウェアおよびソフトウェア コンポーネントは、最新のセキュリティ パッチとバグ修正で定期的に更新する必要があります。導入されているインフラストラクチャに関係なく、ビッグデータ プラットフォームの各コンポーネントを継続的にスキャンして、コンポーネントを迅速に識別し、コンポーネントの潜在的な技術的問題やセキュリティ リスクを解決できるようにする必要があります。

上図は、ビッグデータ プラットフォーム容量ガバナンス フレームワークの機能アーキテクチャです。図の右端の部分は、テクノロジー ユーザーのインフラストラクチャまたは供給フローを表します。図の左端の部分は、需要ベースとビジネス モデル ベースの学校を表しています。このスクールの代表者はビジネス ユーザーであり、ソリューションの技術的な詳細に深く立ち入ることなく、ビジネス上の問題を解決することに重点を置いています。図の特定時点の部分は、需要 (左側) に基づいて供給 (右側) を管理するツールとテクニックを使用するビッグ データ フレームワークを表しています。

記事を短くするために、特定のドメインの問題を解決できるマイクロサービスなどの成熟したツールがすでに存在するため、技術アーキテクチャは議論の範囲から除外します。始める前に、明白な質問をする必要があります – この問題に関するソリューションを構築する価値はあるのでしょうか?容量とコンプライアンスの問題に対処できるツールは市場にありますか?時間の経過とともに、多数の監視、APM、分析ツールを使用した結果、ガバナンス プラットフォームを構築する必要がある場合、各ツールが異なる特定の領域の問題を解決するため、複数のツールを統合する必要があることがわかりました。上記の結論の前提は、車輪の再発明ではなく、成熟したツールを使用することです。

例えば、   YARN 上で実行される Spark アプリケーションの監視、ログ分析、パフォーマンス管理のためのツールは、Kubernetes コンテナにデプロイされたときに同じ機能を実現するために使用されるツールとはまったく異なります。同じ機能を実装していますが、異なるプラットフォームで実行されます。同じことが地元にも当てはまる パブリック クラウドにはローカル監視ツールと自動スケーリングも必要となるため、VMware の監視、APM、自動スケーリング ツールはパブリック クラウド内の VM に最適です。   API。移行の理由は、機能や環境が同一であり、パブリッククラウドが無数の VMware で構成されていることです。

データサイエンスまたは  AI 産業化プロジェクトは必ずしも MapReduce/Spark/ビッグデータを指すわけではありません。一部のプロジェクトには、システム インターフェイス、従来のソフトウェア、またはマイクロサービス アプリケーションも含まれます。 DevOps ツールと基盤となるデプロイメント プラットフォームを選択するだけです。

金融機関にとって、ビッグデータ プラットフォームの継続的なコンプライアンスと高可用性を確保することは非常に重要です。計算ストレージ リソース (供給)、4 つの V (容量、速度、多様性、正確性)、ワークロードの性質 (処理)、SLA、およびデータ機密性要件 (需要/BAU) を総合的に理解する必要があります。上記の要素を考慮した上で初めて、ビッグデータ プラットフォームの高可用性と容量の冗長性を確保しながら、特定のビジネス シナリオに適したスケーラブルなソリューションを構築できるようになります。

配送方法:

データの収集と探索から傾向の特定と分析の実行まで、成熟度マトリックスに従って、分析を通じてインテリジェントな運用をサポートします。この目標を達成するには 7 つの段階があります。

1. 包括的な在庫

包括的なクロスプラットフォーム インベントリを構築し、VM インフラストラクチャ レベルのインベントリをネイティブ監視ツールから簡単に利用できるようにします。コンテナ化されたプラットフォームとさまざまなパブリッククラウド  API と監視モードには違いがあります。さらに、   VM レベルのインベントリでは不十分です。プラットフォームでは、さまざまなコンポーネントで構成される複数の社内ミドルウェア、ベンダーサポート ミドルウェア、およびオープンソース ミドルウェアが使用されるため、これらのミドルウェアのインベントリを作成する必要があります。これらのミドルウェアのロール タグ付けを実行するには、パブリッシャー、オブザーバー、サブスクライバーを実装し、これらのミドルウェアを仮想マシン、コンテナ化 (Kubernetes/Openshift)、またはパブリック クラウド プラットフォームにデプロイする必要があります。

2. インフラの利用、消費動向と分析

ハイブリッド クラウド インフラストラクチャ全体に展開されているロールを理解したら、インフラストラクチャの使用率を使用してデータをより細かい粒度に分類し、そのメトリックを定義する必要があります。

さらに、監視データでは次の 2 つの問題に対処する必要があります。

ポイントインタイムのインシデント管理には、迅速な識別、通知、解決が必要です。   CPU、RAM、ネットワーク容量の問題。インシデント管理ダッシュボードのサンプリング頻度は、リアルタイムに近い必要があります。

時系列データは容量マトリックスの集計であり、集計データには 5 分間のサンプリング集計から時間ごと、日ごと、週ごと、月ごとのサンプリング集計までのラベルが付けられます。このコンポーネントのサンプリング頻度により、長期的な容量使用率とサービスの動作状況を分析する能力が向上します。

上記のデータはテクノロジー/インフラストラクチャの利用データであり、このデータの上にマルチテナントの占有データを重ね合わせることで、データセット、作業、プロジェクト/プログラム、ビジネスユニットごとにテナントの占有に関する累積情報が生成されます。

3. 需要分析と予測

テナント占有データがインフラストラクチャの使用率から得られる場合、ストレージ、コンピューティング、プロジェクト サイズ レベルでの成長傾向を特定できます。個々のデータセット/テナントの相対的な成長に基づいて、上位の占有者、最も急速に成長しているデータセット/テナント、上位の (計算上の) 無駄、および重要でないノイズの多い近隣を特定できます。

4. パフォーマンスの最適化

最も無駄に​​なっているリソースを特定し、ビジネス ユニットと連携してリソースを最適化し、無駄を削減しながら、適切な冗長性を確保し、サービスの信頼性を向上させます。各時点で、ジョブ プログラムによってクラスターにスケジュールされたジョブは数千に上り、各キューには、毎日、毎週、毎月、またはアドホック スケジュールで実行される送信済みジョブが数百個含まれています。これらの操作を実行する際には、最大限を特定して調整する必要がある。   CPU と RAM が無駄に使用され、重要でないジョブが重要でない時間またはピーク時以外の時間に実行されるようにスケジュールされます。

5. 高可用性、容量冗長性、拡張性

ビジネスに不可欠なワークロードを特定し、その運用に冗長な容量を提供し、重要でないワークロードをオフピーク時間に調整する行為は、サイト信頼性チームの主要パフォーマンス指標の 1 つと見なされます。ミドルウェアの高可用性を確保することに加え、サイトの信頼性の問題を特定し、ピーク時のトラフィックの急増に対応するためのプラットフォーム コンポーネントの個別および全体的なスケーラビリティを確保することは、一定期間にわたって運用データを監視および観察することによってのみ実現できます。

すべてのミドルウェア コンポーネントにとって、ワーカー レベルとマスター レベルの両方での高可用性は、特にビジネス クリティカルなクラス 1 アプリケーションにとって基本的な要件です。内部アプリケーションの場合、徹底的かつ一貫性のあるコード分析、ユニット統合パフォーマンス テストの結果、依存関係のアクセス許可、脆弱性スキャン データを各コンポーネント レベルで収集する必要があります。マネージド サービスの場合、パブリック クラウドでは、それぞれのクラウド インフラストラクチャ プロバイダーとサービス レベル契約を確立する必要があります。外部ソフトウェアプロバイダーは、同じソフトウェアサポート、パッチ適用、インシデント管理サポートを確保する必要がある。  サービスレベル保証。

6. 自動拡張、自己修復、コスト最適化

成熟の最終段階では、キャパシティガバナンスフレームワークがより介入的になり、意思決定エンジンは  SRE チームはスケジュール、週次および月次計画を作成し、また、環境の重要度、サービス レベル契約、および変更の影響に応じて、人間の介入なしに一部のサービスを自動的に修復またはクリーンアップすることもできます。最後に、上記で収集したデータと分析を管理して、各ミドルウェア コンポーネントに対して最高のパフォーマンスと最もコスト効率の高いインフラストラクチャを決定する必要があります。

このデータは、自動スケーリングポリシー、自己修復（特に非  HA コンポーネント、パフォーマンスとコストの最適化レポート、推奨モデルなどがあります。

7. 技術的リスクと継続的なコンプライアンス

高性能で安全かつ準拠したシステムを調達してセットアップするだけでは不十分であることが判明しました。各コンポーネントが、どのプラットフォームに展開されているかに関係なく互換性を維持し、継続的な脅威や脆弱性の影響を受けないようにする必要があります。

サービスの中断は金銭的損失や規制上の罰則につながる可能性があるため、テクノロジーリスクとコンプライアンスは金融業界におけるサービス提供の最も重要な側面の 1 つです。  猫1  このタイプのアプリケーションは典型的な例です。プロジェクトを本番環境に導入した後も、コストはそこで止まらないので、行動を起こす前によく考えてください。

• 古くなったハードウェアを交換します。サポートソフトウェアクラスには継続的な更新が必要です。サポートが終了したライセンスは速やかに更新する必要があります。
• さまざまなプラットフォームに展開されたさまざまなコンポーネントは、さまざまな  TCPと他のポートは、必要なネットワーク領域の分離、伝送を確保するために均一にスキャンする必要がある。   (SSL) および静的 (暗号化) 標準。
• 各ミドルウェア サブコンポーネント/マイクロサービスは、重大な脆弱性 (最近の log4j 脆弱性など) がないか定期的にスキャンする必要があります。サーバーを最新のオペレーティング システムとセキュリティ パッチで更新する必要があります。
• 災害復旧とミドルウェア層の高可用性を確認し、単一障害点を検出して排除し、再起動を必要とするパッチを適用するには、サーバーを定期的に再起動する必要があります。
• クラウド向け  EC2インスタンスを更新する必要がある  AMI、資格情報と暗号化キー、および SSL 証明書を置き換える必要があります。
• 動的な需要のピーク時の月間テナント増加と時間単位の使用率に対応するには、容量の冗長性をスキャンして確保する必要があります。

1. 需要/BAUフロー

ビジネス要件はさまざまな側面から分析され、最終的にはビッグデータ ツールセットと展開インフラストラクチャをユースケースのソリューションと組み合わせた技術アーキテクチャを形成します。

ユースケースの開発に必要なツールの種類とデータ量は、システム内のデータの性質と、データの抽出、計算、レポートの要件によって決まります。たとえば、ストリーミング ジョブでは、小さなメモリ フットプリント (およびストリーミング ワークロードを処理するための適切なコンピューティングとネットワーク帯域幅) で継続的なストリーミング データを処理する必要があります。一方、歴史的データ バッチ/ETL  抽出では、大量のメモリ使用量とネットワーク トラフィックの急増を考慮する必要があります。さらに、データ分析とレポート生成のワークロード要件では、CPUと データセットのサイズとクエリの複雑さに応じて、メモリは一時的に使用される場合があります。

需要サイズモジュール:

需要サイジング モジュールは、データ容量 (予測可能および予測不可能) に対するワークロード需要を簡素化するため、インフラストラクチャ データ容量の供給と可用性のみを考慮する必要があります。このモジュールは、容量の拡大と管理要件に関係者を関与させるフィードバック ループを形成します。

ビジネス要件、技術要件、運用上のスケーラビリティ:

ビジネス ユーザーにとっての機能要件は、データ セットをデータ レイクに転送またはバッチ抽出し、データ エンジニアリングに適用することです。あるいは、このデータを使用して戦略的なレポートを生成したり、データセット上で推奨モデル ウェアハウスをトレーニングしたりすることもできます。

より広い意味では、需要を 1. 構造化された容量需要、2. 動的容量需要の 2 つのカテゴリに分類します。これらを見てみましょう。

1a 構造容量要件:

構造的な容量要件とは、ピーク時のトラフィックの急増に対処するために、必要な最小保証容量を提供したり、ワークロードに適切な冗長性を維持したりするために、容量のサイズ設定とジョブのスケジュールを予測する必要があることです。これらのワークロードには、ソース システムからのストリーミング負荷を予測するストリーミング ジョブが含まれます。同様に、モデルが最終的に展開されると  API では、モデル API の容量を事前に設定することもできます。

1b 動的容量要件:

動的容量要求は、容量サイズを事前に予測できず、ジョブの実行には固定スケジュールがないため、探索フェーズのジョブで構成されます。これには、データ エンジニアが取り込みジョブやコンピューティング ジョブを構築する非本番開発環境や、データ サイエンティストがモデルを本番環境にリリースする前に直接トレーニングする実験環境が含まれます。これらのワークロードは営業時間中にアクティブになるため、トラフィックの急増に対処するためにピーク使用期間中に容量の冗長性が必要であり、コストを節約するためにオフピーク時間帯に容量を再利用する必要があります。

測定単位とスケール:

プラットフォーム全体のスケーラビリティを考える際には、次の 3 つの重要な要素を考慮する必要があります。

ストレッチユニット：例えば、   Openshift では、コンテナのスケーラビリティを定義できます。   VPC では VMWare、AWS では EKS クラスター、ec2 インスタンス、s3 バケットになります。

測定単位: スケーラブルな単位が測定単位に最も近い場合は、その測定単位を使用します。例えば、   EMRでは、スケーリング単位は  ec2インスタンスですが、これはマルチテナントクラスタなので、測定単位は依然としてSparkジョブによって使用されるCPU時間またはメモリ時間数です。

販売/購入単位: 価格タグを付けることができるエンティティです。ビッグデータ プラットフォーム自体がリソース マネージャーであるため、リソースも混在しています。チームごとに個別のクラスターを構築すると、クラスター全体を拡張できますが、各ジョブが消費するリソースの量という疑問に答える必要があります。これは、ユニットの販売/購入によって測定できます。

需要分析サイクル（フォワードキャパシティプランニング）：

データ サイエンス/データ エンジニアリング プロジェクトを構築するときは、ユース ケースを理解し、ツールを選択し、キャパシティ プランニングを考慮することが不可欠です。ソース システムの 4 つの V を十分に理解しているにもかかわらず、ターゲット データセットの実際のフットプリントは推定することしかできません。さらに、クラスタ上でスケジュールベースまたはアドホックベースで継続的にデータ取り込みと計算ジョブが実行されるため、増加傾向、たとえば増加傾向の組み合わせに基づいて容量を予測する必要があります。  将来的に T1、T2、T3 データセットに必要な容量、および各カテゴリごとに抽出して計算する必要があるデータセットの容量。

2. 処理/ミドルウェアフロー

図の中央には、さまざまなビッグデータ ミドルウェアがあります。このストリームはビッグデータの専門家に最も近いものであり、   ＳＲＥ  リーダーたち。この図は、機能に基づいてコンポーネントを分類します。

最大の部分は分散コンピューティング層で、これには Hadoop/Spark フレームワーク (Cloudera CDH/CDP、Databricks、Kubernetes 上の Spark など)、クエリ エンジン (Presto/Impala など)、ストリーミング エンジン (Kafka) が含まれます。   。これらのコンポーネントを一つずつ見ていきましょう。

2a 2b 2c 基本サービス（監視とログ集約、データガバナンス、データセキュリティ）：

プラットフォーム内のワークロードに対して、環境やクラスター全体にわたって基本的なサービスを提供するツールがあります。これには、ログ集約、データ検出/データガバナンス、データセキュリティなどの機能が含まれます。ツールは環境間で動作し、ビッグデータ プラットフォームの持続可能で安全かつ信頼性の高い運用を保証します。

2e 分析/データ サイエンス ワークロード:

その使用パターンと容量要件は、運用クラスター上のデータ取り込みジョブや計算ジョブとは異なります。データ サイエンティストは、モデルのトレーニングのために、特定の大規模なデータセット セットを分散処理エンジンにインポートする必要がある場合があります。このプロセスはモデルがトレーニングされるまで継続されますが、当然ながらこれには比較的長い時間がかかります。モデルのトレーニングはスケジュールに従う必要はありません。通常の営業時間中はクラスターの負荷が高くなりますが、オフピーク時にはアイドル状態になり、モデルのトレーニングに使用できます。

さらに、分析/データ サイエンスのワークロードでは、モデルのトレーニング プロセスで顧客の運用データに直接アクセスする可能性があるため、クラスター データのセキュリティとアクセス制御に対する要件が比較的高くなります。したがって、データ漏洩や個人を特定できる情報の漏洩を防ぐために、トークン化、データの保存、取得、およびデータ漏洩防止のための厳格なメカニズムを確立する必要があります。   (PII) データが盗まれました。

2f 開発者/非本番環境ワークロード:

運用環境でのデータ抽出および計算操作の場合、データは合成またはサニタイズされます。通常、開発環境は共有されており、実稼働環境よりも容量が小さくなります。   SLA もそれほど強力ではありません。基本的に、ビッグデータ ソリューションは実際の生産データの 4 つの V に依存しているため、ジョブの実際のフットプリントとパフォーマンスは生産エリアでのみ検証できます。通常は別の  QA環境。この環境は、ビジネス ロジック、データ ガバナンス、データ セキュリティ、ビュー統合テストからのジョブを検証するために使用されます。

2g オペレーション/ETL/バッチ ワークロード:

運用ワークロードは、保証されたサービスレベル契約を満たす必要があるワークロードです。  抽出ジョブまたは計算ジョブの SLA。これらのサービスの中断は、当社の通常業務に影響を及ぼす可能性があります。   (BAU) 運用上または戦略的なビジネス上の意思決定。ジョブの全体的なコンピューティング、ストレージ、データ セキュリティ、および時間的敏感性を理解し、SLA への影響を防ぐために十分な容量と冗長性があることを確認する必要があります。

2時間の分散クエリ処理/可視化レイヤーのワークロード

多くのビジネス レポートでは、基礎となるデータセットを変更する必要がなく、メモリ内での大規模なデータセットの処理のみが必要です。ビッグデータ用の分散クエリ処理エンジンはいくつかあります（例えば、   Trino/Apache Presto、Apache Impala、Apache Drill、SparkSQLなどのプラットフォームは、スーパーセット、Tableau、Qlikview、カスタムダッシュボードなどのレポート作成や視覚化ツールに使用でき、   SQL インターフェイスは、視覚化/チャート作成ライブラリに表示されます。

ストレージ仮想化に関する注意事項:

多くの組織は、オブジェクト ストレージを活用して、より安価なデータ アーカイブを実現したいと考えています。しかし、   CAP 定理に関する限り、S3 は他の 2 つを保証するために一貫性を犠牲にします。同時に、パブリッククラウド S3 を考慮すると、大量のビッグデータ コンピューティング負荷をネットワーク チャネルに直接かけると、システムの信頼性に一貫性がなくなります。さまざまなツールがストレージ仮想化を提供していますが、実際には、仲裁層を通じてエンド ユーザーにクエリ インターフェイスを提供しているため、パターンを確立することは困難です (ユーザーがインターフェイスを使用してクエリを実行するタイミングが不明であるため)。ユーザーのクエリ操作が営業時間中に行われない限り、この期間中の容量の使用率を向上させるか、容量を分離して割り当て、ユーザーにスケジュールされたクエリ サービスを提供することができます。同時に、容量要件はプロジェクト レベルの分離と対応する容量の冗長性を通じて処理できます。

2i ストリーミングワークロード、処理ワークロード

新しいプロジェクトでは、ストリーミング データ抽出を通じて運用データやビジネス データをデータ ウェアハウスにインポートすることがよくあります。 Apache Kafka、Apache Storm、Spark Streaming、AWS Kinesis は、よく使用されるデータ取り込みツールです。 Kafka プラットフォームには、高可用性、マルチテナント、容量管理機能のためのツール セットが付属しています。ネットワークとソースシステムの性質に応じて、ほとんどの場合、ストリーミングジョブは ストリーミング エンジンはレプリケーションと弾力性 (水平スケーリング) の問題を効果的に解決するため、CPU/RAM の使用量が急増することはありません。

2j 永続層、ストレージトラバーサルおよび占有

データセットの最終的なサイズ (ストレージ層に保存される) は、ソース システムの性質とサイズ、圧縮タイプ、レプリケーション要件、トークン化と暗号化、および取り込み/計算ジョブの性質によって異なる場合があります。したがって、永続化レイヤーをトラバースしてデータセットの実際のサイズを特定し、それをコンピューティング ジョブ、テナント、およびソース システムに関連付ける必要があります。

ストレージ トラバーサル モジュールは、この関連付けを確立し、メタデータとマルチテナント構造を通じてサイズを接続し、データ セットの増加傾向を導き出すように作成されています。最終的には、データセットの成長の性質とサイズを予測できるようになり、必要に応じてストレージ層の冗長性を確保できるようになります。

糸（または 将来の Spark-on-Kubernetes スケジューラの容量管理:

本質的に、ビッグデータフレームワークにおける計算ワークロードの容量管理は、   YARN 容量スケジューラ。 Spark コミュニティは、Kubernetes 上の Spark に同じ機能をもたらすために懸命に取り組んでいます。基本的に、特定のキューには最低限の保証容量があり、クラスターの負荷が高い場合でもキューの容量が保証され、他のジョブがキューに優先的に提供されます。一方、通常のクラスター負荷でも割り当てられないリソースに制限がある場合があるため、最大容量を設定する必要があります。

最低保証容量と最大限度の差は共通プールから生じます。ピーク時には、重要でない仕事の需要が高ければ、  最大制限値。合理的な最小値と最大値を持つ重要なジョブが影響を受ける可能性があります。たとえば、Apache Hadoop 2.4.1 — Hadoop Map Reduce Next Generation-2.4.1 — Capacity Scheduler などです。

例えば、上記はオペレーションクラスタの例です  YARN キューの 1 つ。赤い線は、最小保証容量が 100 vCore であることを示しています。最大値は約 270 vCore に制限されます。最小保証容量と最大制限の差は共通プールから生じ、その時点で Yarn に負荷がかかっている場合、そのリージョン内のジョブを優先することができます。現在、キューには 1 日に実行される数千のジョブが含まれる可能性があり、最大の無駄を特定して最適化する方法については、別の記事で説明する必要があります。

基本的に私たちがやりたいのは  VM インフラストラクチャのコストは、キュー割り当てのコストに近くなります。一度  CPU または RAM はジョブに割り当てられ、YARN の観点からは占有/使用中とみなされます。

しかし、私たちの目標は、フリート内で使用/割り当てられているものに近いコンテンツを入手し、ワークロードの急増に対応できるように適切な冗長性を確保することです。この割り当てを適用する際には、割り当てられた使用率に近づくように継続的に測定も行います。このプロセスでは、割り当て不足 (クラスターへの予期しない流入を避けるため) と割り当て過剰 (無駄を避けるため) の両方が回避されます。さらに、ピーク時に重要でないジョブをスケジュールしないようにすることで、  時間的に重要なジョブの SLA に影響が出ます。容量とスケジュールの最適化にはさまざまな戦略が必要です。

ＳＲＥ  カレンダーとコンプライアンス、日次、週次、月次勤務表

各生産変更要求には、   L1サポートおよびサイト信頼性エンジニアリング（SRE）チームは、当社の開発および  DevOps チームの準備は整いました。 SRE チームは、特に本番環境において、ダウンタイムやサービスの中断を明確に理解し、BAU チームに通知する必要があります。

一方、コンプライアンス ヒートマップは、主要な技術的リスク成果物の包括的なビューを提供します。

SRE カレンダーは、SRE チームに上記の技術的リスクのアクション項目をスケジュールする場所を提供します。また、開発チームは、ソフトウェアのリリース、アップグレード、パッチ適用中に、L1 サポート チームや SRE チームと BAU ダウンタイムを予約して調整することもできます。

3. 供給/インフラフロー

このカテゴリーは  Mirco Hering 著「現代企業のための DevOps」。によると  DevOps が対応するプラットフォームとどのように相互作用するかによって、インフラストラクチャのプロビジョニングは主に 3 つのフローに分けられます。これら 3 つのインフラストラクチャ ドメインは、高可用性、プロビジョニング/デプロイメントの自動化、および自動スケーリングを実装する方法が異なります。インフラストラクチャ運用を実装し、テクノロジのリスクとコンプライアンスを管理するためのさまざまなモデルもあります。

3a ローカルインフラストラクチャ

一部の組織は、インフラストラクチャのメンテナンスをパブリック クラウド プロバイダーにアウトソーシングし、競争力のある価格設定を期待しています。しかし、   IT インフラストラクチャはより安価になり、エネルギー効率も向上しています。顧客データをパブリッククラウドに移行、保存、取得するコストが急増しており、企業の顧客データが侵害されたり、   PII データ盗難のリスク - 多くの組織は、コスト効率の高い機能を仮想プライベート クラウド自体に組み込むことを好みます。

3b コンテナ化された（クラウドネイティブ）インフラストラクチャ

ガートナーによると この研究は2021年までに  2018年、世界の98%の インフラストラクチャはコンテナにデプロイされます。 Kubernetes/Openshiftの使用  Docker などのコンテナ オーケストレーターは、アプリケーションをコンテナにデプロイします。これにより、オペレーティング システム レベルのより深い分離、効率的な構成管理、自動スケーリング、高可用性、保守性、自己修復機能などの高度な機能が提供されます。

イーブンスパーク コミュニティはSparkの  Kubernetes の紹介。動的なリソース割り当てとキュー管理はまだ開発中ですが、一部の組織ではこれを本番環境で使用しています。

3c パブリッククラウド (IAAS/PAAS/SAAS)

パブリック クラウドはプロビジョニングや拡張が簡単ですが、無駄が生じる可能性もあります。ユースケースに最も適したソリューションを使用しないと、リソースを無駄にしてしまう可能性が高くなります。各パブリック クラウドでは、マネージド サービスを使用するのが最適です。例えば、   Argo パイプラインを使用してバニラ Kubernetes クラスターを起動できますが、より優れた統合のために EKS が推奨されます。同様に、自己展開型  Jupyterhub および Hadoop + Spark のデプロイメントと比較すると、Sagemaker + EMR が推奨される組み合わせになります。パブリック クラウドを IAAS または PAAS のみに使用する場合でも、ビジネス ワークロードをパブリック クラウド サービス上のローカルにホストされるサービスとして再設計する場合でも、包括的な資産インベントリを作成し、その上に消費データを重ね合わせる必要があります。

インフラ供給フィードバックループ

クラスター アプリケーションでコンピューティング ジョブと抽出ジョブが追加され、増加し続けるにつれて、容量フィードバックを通じて容量の冗長性を確保する必要があります。占有率と成長の分析に加えて、これもビジネス ユーザーにも伝える必要があります。需要と供給の相互作用関係は、上記の需要スケール モジュール図で説明されているさまざまな前方および後方フィードバック作業を通じて明らかにされ、分析されます。

結論は

サイトの信頼性、高可用性、コンプライアンスを維持しながら、容量ガバナンス フレームワークを構築するには、仮想プライベート クラウドが必要です。  当社は、仮想プライベートクラウド (VPC) のさまざまなインフラストラクチャ製品に DevOps とサイト信頼性エンジニアリング (SRE) を実装し、これらの原則と経験を組み合わせて、コンテナ化、パブリッククラウド プラットフォーム、ビッグデータ製品の作業に適用します。ビジネス ユーザーの視点、プラットフォームのマルチテナント構造、通常業務 (BAU) のサービス レベル契約も十分に考慮する必要があります。   (SLA)、データ セキュリティ、および稼働時間の要件。時間をかけて構築されたキャパシティガバナンスフレームワークは、洞察を提供し、  チームは SRE チームの能力を高め、容量の最適化を通じてインフラストラクチャ コストを数百万ドル節約することができました。

翻訳者について

51CTO コミュニティ エディター兼シニア アーキテクトの Cui Hao 氏は、ソフトウェア開発とアーキテクチャで 18 年の経験があり、分散アーキテクチャでは 10 年の経験があります。元HPの技術専門家。彼は情報を共有することに積極的で、60 万回以上読まれている人気の高い技術記事を多数執筆しています。 『分散アーキテクチャの原則と実践』の著者。

ハイブリッド クラウド、マルチテナント ビッグ データ プラットフォームの容量とコンプライアンス (Amit Thakur 著)

リンク: https://dzone.com/articles/capacity-compliance-hybrid-cloud-multi-tenant-platforms